Plus de connexion réseau sous Lion

Lastrada

Membre expert
Club iGen
20 Décembre 2004
2 528
1 289
Salut.

Depuis aujourd'hui, je ne suis plus en mesure de me connecter sur le réseau local de mon boulot.
J'ai un MBP sous 10.7.3 et ce quelle que soit l'interface (ethernet ou WIFI), le câble, la borne wifi, que mon IP soit fixée manuellement ou en DHCP.


Mon PC virtuel hébergé sur la même machine lui accède sans problème au réseau. Je sais qu'il y a eu une intervention ce week end et ils ont arrêté les serveurs. De mon côté, il n'y a eu aucun changement depuis que la dernière fois ou tout fonctionnait bien (jeudi dernier). Chez moi je me connecte sans problème en wifi. (Ce midi).

Je ne sais pas comment procéder pour isoler le problème.. Le LAN est un domaine administré sous Windows... et l'admin réseau n'est pas du tout familier avec les macs.

Je pense que ma machine et mon OS fonctionnent parfaitement. Ca marchait encore jeudi soir et je n'ai rien changé depuis....

Une idée ?


C.
 
Pas tous à la fois.
 
Pas tous à la fois.


Tout seul alors? :)

Curieux...

Perso, je connecterais le Mac en ethernet, et en DHCP auto.
Je ferais un ifconfig pour voir l'état de l'interface ethernet en0

Ensuite, je débrancherais le câble ethernet, et je rebooterais la machine.
Dans une fenêtre Terminal, je ferais un tcpdump -i en0
Puis je rebrancherais le câble ethernet.
En principe, si le niveau physique est bon, on devrait voir des choses défiler dans la fenêtre Terminal, du genre ARP, découverte DHCP, requêtes DNS.
On verra alors à quel niveau ça coince.

Autrement, une idée comme ça:
Est qu'il y a un proxy sur le réseau local?
Si oui, est-il déclaré dans le mac?
 
  • J’aime
Réactions: Lastrada
Tout seul alors? :)

Curieux...

Perso, je connecterais le Mac en ethernet, et en DHCP auto.
Fait ==> Ne change rien.

Je ferais un ifconfig pour voir l'état de l'interface ethernet en0

J'essaierai demain.

Ensuite, je débrancherais le câble ethernet, et je rebooterais la machine.
Fait ==> Ne change rien.

Dans une fenêtre Terminal, je ferais un tcpdump -i en0
Puis je rebrancherais le câble ethernet.



J'essaierai demain. Mais si j'obtiens un truc comme ce qui suit, je vais pas pouvoir l'exploiter... :D


800px-Tcpdump.png



En principe, si le niveau physique est bon, on devrait voir des choses défiler dans la fenêtre Terminal, du genre ARP, découverte DHCP, requêtes DNS.
On verra alors à quel niveau ça coince.

Etant donné que la machine virutelle sous windows XP hébergée sur la dite machine se balade sans problème sur tout le réseau, que le mac soit relié via WIFI ou ethernet m'amène à penser qu'il n'y a aucun problème "physique", si je mets bien le même sens que toi derrière ce terme.



Autrement, une idée comme ça:
Est qu'il y a un proxy sur le réseau local?

Je ne sais point.

Si oui, est-il déclaré dans le mac?

Non.
 
Bonsoir,

En réalité, les manips indiquées dans mon post constituent un tout.
Il faut les enchaîner.
Renvoie la trace dans le fil (les 100 premières lignes, mais il y en aura peut-être moins). Je regarderai.

Quand ça ne marche pas, dans la conf réseau, est-ce qu'il y a une adresse IP, un masque, une passerelle, un serveur DNS d'attribués?

Etant donné que la machine virutelle sous windows XP hébergée sur la dite machine se balade sans problème sur tout le réseau, que le mac soit relié via WIFI ou ethernet m'amène à penser qu'il n'y a aucun problème "physique", si je mets bien le même sens que toi derrière ce terme.
Non.

On peut conclure que la carte réseau n'a pas de problème matériel.
Maintenant, les paramètres réseau de niveau physique associés à la carte (par ex vitesse, duplex,..) ne sont pas forcément déclarés de la même façon pour la machine virtuelle windows et pour le Mac.

La commande ifconfig donnera des indications sur l'état physique de la connexion.
 
Voici le début du tcpdump, l'intégralité dans le pdf associé + une image du ifconfig.
MACCFN:~ cflorentin$ sudo tcpdump -i en0
tcpdump: WARNING: en0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes

11:38:00.856000 ARP, Request who-has 192.168.168.37 tell 192.168.168.131, length 46
11:38:00.856010 ARP, Request who-has 192.168.168.37 tell 192.168.168.73, length 46
11:38:00.856023 IP6 daniel.local.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
11:38:00.856030 IP 192.168.168.85.netbios-ns > 192.168.255.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
11:38:00.858942 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from c8:2a:14:15:f8:73 (oui Unknown), length 300
11:38:00.859908 IP 192.168.168.2.bootps > broadcasthost.bootpc: BOOTP/DHCP, Reply, length 323
11:38:01.023887 STP 802.1d, Config, Flags [none], bridge-id 8000.30:46:9a:18:a9:16.8001, length 43
11:38:01.028226 ARP, Request who-has 192.168.168.55 tell 192.168.168.108, length 46
11:38:01.100823 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:38:01.100922 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
11:38:01.112719 IP 192.168.168.102.51262 > 239.255.255.250.ssdp: UDP, length 133
11:38:01.223830 ARP, Request who-has 192.168.168.37 tell 192.168.168.131, length 46
11:38:01.228301 ARP, Request who-has 192.168.168.37 tell 192.168.168.73, length 46
11:38:01.480251 IP6 :: > ff02::1:ff15:f873: ICMP6, neighbor solicitation, who has maccfn.local, length 24
11:38:01.510568 IP6 fe80::f994:d687:95a6:a620.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
11:38:01.512310 IP 192.168.168.85.netbios-ns > 192.168.255.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
11:38:01.861063 ARP, Request who-has 192.168.167.7 tell 192.168.167.7, length 28
11:38:01.862087 ARP, Request who-has 192.168.168.1 tell 192.168.167.7, length 28
11:38:01.862422 ARP, Reply 192.168.168.1 is-at 00:06:b1:16:31:df (oui Unknown), length 46
11:38:01.870113 ARP, Request who-has 169.254.255.255 tell 192.168.167.7, length 28
11:38:01.903067 IP 192.168.167.7.netbios-ns > 192.168.255.255.netbios-ns: NBT UDP
 
Dernière édition:
Bonsoir,

En réalité, les manips indiquées dans mon post constituent un tout.
Il faut les enchaîner.
Renvoie la trace dans le fil (les 100 premières lignes, mais il y en aura peut-être moins). Je regarderai.

Quand ça ne marche pas, dans la conf réseau, est-ce qu'il y a une adresse IP, un masque, une passerelle, un serveur DNS d'attribués?

Oui

On peut conclure que la carte réseau n'a pas de problème matériel.
Maintenant, les paramètres réseau de niveau physique associés à la carte (par ex vitesse, duplex,..) ne sont pas forcément déclarés de la même façon pour la machine virtuelle windows et pour le Mac.

La commande ifconfig donnera des indications sur l'état physique de la connexion.

OK
 
Bonjour,

Alors, ça cause un max sur le réseau.:)
Le Mac reçoit tous les broadcast. Normal...
Il n'y a aucun problème physique, et le mac a bien une adresse IP et un masque d'attribués.

Avant de regarder la trace plus en détail, il y a quand même quelque chose de curieux.
Le Mac a 192.168.167.7 comme adresse IP, et un masque à 16 (255.255.0.0)
La machine virtuelle windows a 192.168.168.51 comme adresse IP et un masque à 24 (255.255.255.0).

Je ne connais pas le plan IP de l'entreprise, mais j'imagine que les machines windows sont sur un plan 192.168.168.0/24.
Si c'est le cas, le Mac ne peut pas communiquer avec une machine windows.
Une machine windows doit pouvoir pinguer le Mac, mais pas l'inverse. D'où les pbs (si c'est bien un pb de masques)

Après, je ne sais pas si vous êtes en DHCP auto, ou pas.
Si vous êtes en conf manuelle, il faudrait faire un essai en configurant le Mac avec une adresse en 192.168.168.xxx/24 (xxx étant disponible sur le réseau)
Si vous êtes en conf auto, l'explication est à voir avec l'administrateur du serveur DHCP.

Si c'est pas un pb de masque, il faudrait faire:
nslookup google.fr (pour voir si on a un pb de DNS)
Traceroute google.fr (pour voir si on accède a une passerelle)
 
Bonjour,

Alors, ça cause un max sur le réseau.:)
Le Mac reçoit tous les broadcast. Normal...
Il n'y a aucun problème physique, et le mac a bien une adresse IP et un masque d'attribués.

Avant de regarder la trace plus en détail, il y a quand même quelque chose de curieux.
Le Mac a 192.168.167.7 comme adresse IP, et un masque à 16 (255.255.0.0)
La machine virtuelle windows a 192.168.168.51 comme adresse IP et un masque à 24 (255.255.255.0).

Je ne connais pas le plan IP de l'entreprise, mais j'imagine que les machines windows sont sur un plan 192.168.168.0/24.
Si c'est le cas, le Mac ne peut pas communiquer avec une machine windows.
Une machine windows doit pouvoir pinguer le Mac, mais pas l'inverse. D'où les pbs (si c'est bien un pb de masques)

Après, je ne sais pas si vous êtes en DHCP auto, ou pas.
Si vous êtes en conf manuelle, il faudrait faire un essai en configurant le Mac avec une adresse en 192.168.168.xxx/24 (xxx étant disponible sur le réseau)
Si vous êtes en conf auto, l'explication est à voir avec l'administrateur du serveur DHCP.

Si c'est pas un pb de masque, il faudrait faire:
nslookup google.fr (pour voir si on a un pb de DNS)
Traceroute google.fr (pour voir si on accède a une passerelle)


Pardon pour la fausse piste, mais j'ai effectivement une adresse en 192.168.167.7 attribuée en dhcp car nous avons fait un test. L'administrateur réseau m'a affirmé que je pouvais quand même voir des PC avec une classe d'IP en 192.168.168.X

On a fait ça pour être certain que le problème ne venait pas d'un conflit d'IP.
Si je me donne une IP manuelle, en 192.168.168.x le problème demeure; c'est même la situation de départ.

Voici le résultat du nslookup:
nslookup google.fr
;; connection timed out; no servers could be reached


Et celui du traceroute :
MACCFN:~ cflorentin$ traceroute google.fr
traceroute: unknown host google.fr
 
Bon,

Le routeur est en 192.168.168.1 ?
Si oui, pouvez vous le pinguer?
Le test nslookup montre que vous n'accédez pas a un serveur DNS.

Qu'avez vous dans la conf réseau du mac (adresse IP, masque, serveurs DNS, passerelle)?
 
Le routeur est en 192.168.168.1 ?

Oui


Si oui, pouvez vous le pinguer?

Non :

cflorentin$ ping 192.168.168.1
PING 192.168.168.1 (192.168.168.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
^C
--- 192.168.168.1 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss


Le test nslookup montre que vous n'accédez pas a un serveur DNS.

Qu'avez vous dans la conf réseau du mac (adresse IP, masque, serveurs DNS, passerelle)?


Serveur DNS : 192.168.168.11 et 192.168.168.2 je ne ping aucun des deux.

Voici :

EthernetSPAM:
Type: Ethernet
Nom de périphérique BSD: en0
Adresse matérielle (MAC): c8:2a:14:15:f8:73
IPv4:
Adresses: 192.168.168.110
Méthode de configuration: Manuel
Routeur: 192.168.168.1
Masques de sous réseau: 255.255.0.0
IPv6:
Méthode de configuration: Automatique
Proxys:
Liste des exceptions: *.local, 169.254/16
Mode FTP passif: Oui
 
Ben, ça devrait marcher...:confused:
Le mac devrait pouvoir pinguer le routeur et les serveurs DNS.

Il faudrait regarder les tables de routage du mac:
netstat -r

S'assurer que le ping sort bien du mac:
tcpdump -i en0 icmp
puis faire un ping vers 192.168.1.1

Après, si le ping sort bien, et qu'il n'y a pas de retour, le pb est sur le réseau entre le mac et le routeur.
L'administrateur du site trouvera certainement. Il y a peut-être un firewall, un switch avec des access-list .
Possible aussi que dans un switch du réseau, au niveau des tables ARP, l'adresse mac du Mac soit restée associée avec une ancienne adresse IP. En principe, il y a des tempos, mais bon...
Le Mac a 2 adresses mac (une pour la machine virtuelle, et une pour l'interface en0)

Si le message ICMP echo request sort, et que l'icmp echo reply ne revient pas, le Mac n'y est pour rien...
 
Dernière édition:
Il faudrait regarder les tables de routage du mac:
netstat -r

Bon

S'assurer que le ping sort bien du mac:
tcpdump -i en0 icmp

Stop. Comment je fais ça ?


Last login: Wed Mar 28 16:52:33 on ttys000
sudo tcpdump -i en0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes



S'il n'y a rien dans la fenêtre tcpdump, c'est que rien ne sort ?

puis faire un ping vers 192.168.1.1


Ne serait-ce pas plutôt un ping vers 192.168.168.1 (le routeur) ?



Après, si le ping sort bien, et qu'il n'y a pas de retour, le pb est sur le réseau entre le mac et le routeur.
L'administrateur du site trouvera certainement. Il y a peut-être un firewall, un switch avec des access-list .
Possible aussi que dans un switch du réseau, au niveau des tables ARP, l'adresse mac du Mac soit restée associée avec une ancienne adresse IP. En principe, il y a des tempos, mais bon...
Le Mac a 2 adresses mac (une pour la machine virtuelle, et une pour l'interface en0)

Si le message ICMP echo request sort, et que l'icmp echo reply ne revient pas, le Mac n'y est pour rien...

In english, please ?



Le netstart :

netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.168.1 UGSc 12 0 en0
127 localhost UCS 0 0 lo0
localhost localhost UH 7 24351 lo0
169.254 link#7 UCS 0 0 en0
192.168.0/16 link#7 UCS 4 0 en0
192.168.167.10 40:30:4:59:ce:7d UHLWIi 1 43 en0 1087
192.168.167.15 d8:d3:85:39:6d:6f UHLWIi 0 0 en0 1057
192.168.167.16 0:1c:42:b3:85:75 UHLWIi 0 0 en0 1033
192.168.168 link#8 UC 7 0 vnic0
192.168.168.1 link#8 UHRLWIi 1 22 vnic0
192.168.168.2 link#8 UHLWIi 0 45 vnic0
192.168.168.11 link#8 UHRLWIi 50 2575 vnic0
192.168.168.18 link#8 UHRLWIi 1 8 vnic0
192.168.168.110 localhost UHS 0 0 lo0
192.168.168.151 0:1c:42:0:0:8 UHLWIi 1 4 lo0
192.168.168.255 ff:ff:ff:ff:ff:ff UHLWbI 0 28 vnic0
192.168.255.255 ff:ff:ff:ff:ff:ff UHLWbI 0 14 en0

Internet6:
Destination Gateway Flags Netif Expire
:: link#8 UC vnic0


Le ping ne répond pas.
 
Je me suis mal expliqué.:confused:

Il faut ouvrir deux fenêtres Terminal.

Dans la première, il faut faire:
tcpdump -i en0 icmp

Dans la deuxième:
ping 192.168.168.1 (tu avais raison pour l'adresse)
En principe, on doit voir défiler dans la 1ère fenêtre.

Quand le ping marche, dans la première fenêtre, tu as, comme ci-dessous, quand je pingue ma box un enchaînement de messages ICMP echo request (ping aller) et de ICMP echo reply (réponse du matériel pingué)

iMac:~ Polo$ sudo tcpdump -i en0 icmp
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:02:32.713512 IP imac.home > 192.168.1.1: ICMP echo request, id 28674, seq 0, length 64
18:02:32.714050 IP 192.168.1.1 > imac.home: ICMP echo reply, id 28674, seq 0, length 64
18:02:33.713607 IP imac.home > 192.168.1.1: ICMP echo request, id 28674, seq 1, length 64
18:02:33.714117 IP 192.168.1.1 > imac.home: ICMP echo reply, id 28674, seq 1, length 64
18:02:34.713709 IP imac.home > 192.168.1.1: ICMP echo request, id 28674, seq 2, length 64
18:02:34.714220 IP 192.168.1.1 > imac.home: ICMP echo reply, id 28674, seq 2, length 64


Si le ping ne sort pas, tu n'auras rien.

Si ça sort, mais qu'il n'y a pas de réponse, tu n'auras que des ICMP echo request, et là, c'est qu'il y a un pb sur le réseau local de l'entreprise. (si bien sûr il n'y a pas d'équipement qui interdise le protocole ICMP)
Ca dédouanera le Mac.
 
Je n'ai rien dans la fenêtre tcpdump.... Donc ça viendrait du Mac ?

---------- Nouveau message ajouté à 18h28 ---------- Le message précédent a été envoyé à 18h26 ----------

J'hallucine : C'est le masque de sous réseau qui n'était pas bon. Si je passe en 255.255.255.0 : CA fonctionne.....

---------- Nouveau message ajouté à 18h33 ---------- Le message précédent a été envoyé à 18h28 ----------

Je n'ai rien dans la fenêtre tcpdump.... Donc ça viendrait du Mac ?

---------- Nouveau message ajouté à 18h28 ---------- Le message précédent a été envoyé à 18h26 ----------

J'hallucine : C'est le masque de sous réseau qui n'était pas bon. Si je passe en 255.255.255.0 : CA fonctionne.....

Ou alors quelqu'un à changé quelque chose sans me le dire; C'est rageant de ne pas comprendre ce qu'il s'est passé.
Un grand merci à Polo :D
 
Ou alors quelqu'un à changé quelque chose sans me le dire; C'est rageant de ne pas comprendre ce qu'il s'est passé.
Je pense que quelqu'un a fait quelque chose...
Si ça marche avec un masque 255.255.255.0, ça doit marcher aussi avec un masque de 255.255.0.0
L'inverse n'aurait pas forcément été vrai...
Mais c'est bien que ce soit tombé en marche...;)
 
J'ai eu le problème peu après et la seule chose qui me ramène le réseau local est la modification du masque de sous-réseau de 255.255.255.0 à 255.255.0.0. Il me faut ensuite faire l'inverse pour avoir accès à internet en gardant mon accès au réseau local.

Va comprendre.