2010-01-29 20 views
2

Je travaille sur un périphérique embarqué qui se connecte sur un réseau local avec RJ45 et lorsque le système envoie une requête ARP pour connaître l'adresse mac de la passerelle, pas de réponse du tout.Pourquoi je ne reçois aucune réponse d'une requête ARP?

Si j'efface la table arp sur mon Windows, Windows demande exactement la même requête ARP et obtient une réponse! J'ai reniflé le paquet et la seule différence à l'intérieur du paquet de requête est une bande-annonce 0 sur le périphérique embarqué à la fin du paquet et que l'adresse mac cible est ff: ff: ff: ff: ff où le windows un est 00: 00: 00: 00: 00: 00 (wikipedia semble dire qu'il devrait être ffffffffff)

J'ai essayé de changer l'adresse mac au cas où ma passerelle bannirait le mac à cause du spam arp mais ça ne marche pas ne change rien. J'essaie aussi avec DHCP IP et IP statique, même problème ...

de Windows paquet:

 
Frame 1 (42 bytes on wire, 42 bytes captured) 
    Frame is marked: False 
    Arrival Time: Jan 29, 2010 12:05:49.775534000 
    Time delta from previous packet: -77.580549000 seconds 
    Time since reference or first frame: 6354.738379000 seconds 
    Frame Number: 1 
    Packet Length: 42 bytes 
    Capture Length: 42 bytes 
    Protocols in frame: eth:arp 
Ethernet II, Src: 00:1e:8c:b5:d0:00, Dst: ff:ff:ff:ff:ff:ff 
    Type: ARP (0x0806) 

Address Resolution Protocol (request) 
    Hardware type: Ethernet (0x0001) 
    Protocol type: IP (0x0800) 
    Hardware size: 6 
    Protocol size: 4 
    Opcode: request (0x0001) 
    Sender MAC address: 00:1e:8c:b5:d0:00 (00:1e:8c:b5:d0:00) 
    Sender IP address: 192.168.0.14 (192.168.0.14) 
    Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00) 
    Target IP address: 192.168.0.1 (192.168.0.1) 

0000: FF FF FF FF FF FF 00 1E 8C B5 D0 00 08 06 00 01 ................ 
0010: 08 00 06 04 00 01 00 1E 8C B5 D0 00 C0 A8 00 0E ................ 
0020: 00 00 00 00 00 00 C0 A8 00 01     ..........  

paquet de dispositif embarqué:

 
Frame 1 (60 bytes on wire, 60 bytes captured) 
    Frame is marked: False 
    Arrival Time: Jan 29, 2010 12:07:04.257748000 
    Time delta from previous packet: -3.098335000 seconds 
    Time since reference or first frame: 6429.220593000 seconds 
    Frame Number: 1 
    Packet Length: 60 bytes 
    Capture Length: 60 bytes 
    Protocols in frame: eth:arp 
Ethernet II, Src: 00:04:a3:12:34:05, Dst: ff:ff:ff:ff:ff:ff 
    Type: ARP (0x0806) 
    Trailer: 000000000000000000000000000000000000 
Address Resolution Protocol (request) 
    Hardware type: Ethernet (0x0001) 
    Protocol type: IP (0x0800) 
    Hardware size: 6 
    Protocol size: 4 
    Opcode: request (0x0001) 
    Sender MAC address: 00:04:a3:12:34:05 (00:04:a3:12:34:05) 
    Sender IP address: 192.168.0.129 (192.168.0.129) 
    Target MAC address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) 
    Target IP address: 192.168.0.1 (192.168.0.1) 

0000: FF FF FF FF FF FF 00 04 A3 12 34 05 08 06 00 01 ..........4..... 
0010: 08 00 06 04 00 01 00 04 A3 12 34 05 C0 A8 00 81 ..........4..... 
0020: FF FF FF FF FF FF C0 A8 00 01 00 00 00 00 00 00 ................ 
0030: 00 00 00 00 00 00 00 00 00 00 00 00    ............  
+0

Etes-vous sûr que votre réseau n'utilise pas vlan ou quelque chose de similaire (tunneling?)? Votre paquet Windows est inférieur à 64 octets, ce qui correspond à la longueur minimale d'une trame ethernet incluant le crc. Certains nics/drivers enlèveront un tel calque et vous ne le verrez pas dans wireshark. – nos

+0

Pas de vlan. C'est juste une boite internet (freebox) avec mon pc et encastrée sur la boite avec rj45 sur la boite (qui fait office de routeur) Depuis que je renifle sur le même PC, peut-être le wireshark (packetyzer en fait) enlève la remorque. – acemtp

+0

J'ai aussi des comportements très étranges comme: - quand mon ordinateur envoie une requête ping à l'image, cela fonctionne 2 fois et après les timeouts (la LED continue à clignoter toutes les secondes) - quand il essaie d'obtenir une IP avec DHCP, il demande N fois (où N est aléatoire), obtient la réponse de la passerelle, envoie la requête, reçoit l'ACK mais ne valide pas le DHCP et demande une autre fois ... Avez-vous une idée? – acemtp

Répondre

0

En fait, il a été un problème avec le TX où la polarité a été inversée et causer ces problèmes.

J'ai inversé la polarité et maintenant cela fonctionne parfaitement.

Questions connexes