arp-Anfragen können von bestimmten Knoten nicht gesehen werden


12

Ich erstelle ein offenes Ad-hoc-WLAN mit iwconfig(ich habe das gleiche Problem auch mit wpa_supplicant). Es gibt 4 Knoten im Netzwerk (siehe Abbildung unten). Die Knoten laufen unter Ubuntu 12.04 und Debian Squeeze und haben Kernel der Versionen 3.7.1, 3.5 und 3.2. Ich verwende zwei verschiedene USB-Dongle-Marken (TP-Link und ZCN), die alle über AR9271-Chipsatz und ath9k_htc-Treiber verfügen (hier lsusb-Ausgabe und ethtool-Ausgabe ).

Ich habe das Problem, dass zwei Knoten ( 10.0.0.2und 10.0.0.5) mit TP-Link-USB-WLAN-Dongles einen beliebigen Knoten im Netzwerk anpingen können und umgekehrt. Die anderen Knoten ( 10.0.0.6und 10.0.0.7), die über einen ZCN-WLAN-Dongle verfügen, können sich nicht gegenseitig anpingen, haben jedoch kein Problem mit der Kommunikation mit TP-Link-WLAN-Modulen. tcpdumpzeigt das 10.0.0.6und 10.0.0.7kann ihre arp-anfrage nicht sehen, zb

20:37:52.470305 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:53.463713 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:54.463622 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:55.472868 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:56.463439 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28
20:37:57.463469 ARP, Request who-has 10.0.0.7 tell 10.0.0.6, length 28

Sie können jedoch die Module von TP-link sehen und erhalten eine Antwort.

20:39:23.634459 ARP, Request who-has 10.0.0.2 tell 10.0.0.6, length 28
20:39:23.634551 ARP, Reply 10.0.0.2 is-at 64:70:02:18:d4:6a (oui Unknown), length 28
20:39:23.636687 IP 10.0.0.6 > 10.0.0.2: ICMP echo request, id 572, seq 1, length 64
20:39:23.636809 IP 10.0.0.2 > 10.0.0.6: ICMP echo reply, id 572, seq 1, length 64
20:39:24.635497 IP 10.0.0.6 > 10.0.0.2: ICMP echo request, id 572, seq 2, length 64
20:39:24.635558 IP 10.0.0.2 > 10.0.0.6: ICMP echo reply, id 572, seq 2, length 64
20:39:28.651946 ARP, Request who-has 10.0.0.6 tell 10.0.0.2, length 28
20:39:28.654021 ARP, Reply 10.0.0.6 is-at 00:19:70:94:7c:8b (oui Unknown), length 28

Meine Frage ist, was könnte der Grund sein, dass sie sich gegenseitig senden 10.0.0.6und 10.0.0.7nicht sehen können arp-request? Wie kann ich das Problem herausfinden?

Wenn ich ein paar weitere Knoten mit ZCN-WLAN-Dongle im Netzwerk hinzufüge, können diese Knoten auch nicht miteinander kommunizieren, aber mit TP-Link sind sie in Ordnung. Oder wenn ich die WLAN-Module austausche, haben die Knoten mit ZCN immer Probleme, aber TP-Link-Module sind in Ordnung. Bildbeschreibung hier eingeben

hier sind die /etc/network/interfaces, ifconfig, iwconfig, ip a, ip r, routeAusgänge

EDIT: Ich habe den Verdacht , ob das Problem arp_filterverwandten , aber /proc/sys/net/ipv4/conf/*/arp_filterist 0auf den alle Subdomains (*). Wenn ich Arp-Informationen von 10.0.0.6und 10.0.0.7manuell zu diesen Knoten hinzufüge , tcpdumpund wiresharknicht zeige, dass sie pingsich gegenseitig senden . Wenn ich pingdie Broadcast-Adresse (in meinem Fall 10.0.0.255) 10.0.0.6und kann 10.0.0.7es hören.

EDIT2: Hier sind die pcap-Dateien http://filebin.net/6cle9a5iae von 10.0.0.6(ZCN-Modul), 10.0.0.7(ZCN-Modul) und 10.0.0.5(TP-Link-Modul, das kein Problem hat). Hier sind die Ping-Ausgaben von 10.0.0.6 http://pastebin.com/swFP2CJ9. Ich habe die Pakete gleichzeitig erfasst. Der Link enthält auch ifconfig; iwconfig; und uname- aAusgänge für jeden Knoten.


Können Sie den ARP-Datenverkehr auf 10.0.0.6- und 10.0.0.7-Computern gleichzeitig im Netzwerk erfassen? Verwenden Sie tcp dump und geben Sie es als pcap-Datei frei.
Mircea Vutcovici

Vielen Dank, Mircea Vutcovici. Die pcap-Dateien finden Sie in EDIT2. Bitte lassen Sie mich wissen, wenn Sie weitere Informationen wünschen.
Johan

Nun, Sie können versuchen, statisches ARP zu verwenden und sehen, wie / ob sich das Konnektivitätsproblem ändert.
Poige

Könnten Sie einen Dump des Verkehrs von einem drahtlosen Sniffer-Tool wie posten kismet? Dies schließt die 802.11-Header ein, falls etwas Merkwürdiges an ihnen ist.
Flup

2
Angesichts der Probleme, die Sie mit den ZCN-Dongles haben, und Ihrer Anforderung, dass die Clients alle direkt im Netzwerk miteinander sprechen, würde ich sie einfach wegwerfen und durch die TPLink-Dongles ersetzen, die tatsächlich in Ihrem Netzwerk funktionieren. Oder es könnte ein Treiberproblem mit den ZCN-Adaptern sein - versuchen Sie es mit einem anderen.
August

Antworten:


1

Ich hatte vor kurzem das gleiche Problem. Ich habe herausgefunden, dass AR9271-Chipsätze Probleme mit der Onboard-Sendeantenne haben. Wenn Sie eine externe Antenne verwenden, haben Sie kein Problem. Und dieses Problem tritt nur im Ad-hoc-Modus auf.

Der Grund, warum Sie kein Problem mit der TP-Verbindung haben, sollte sein, dass diese Module eine externe Antenne verwenden, die das Problem des Chipsatzes überwindet, und dass ZCN-Module keine externe Antenne haben sollten.


1

Dies könnte mit dem " Hidden Node Problem " zusammenhängen, wenn .6 und .7 keinen direkten Funkkontakt haben, aber ohne Kenntnis der Entfernungen ist es unmöglich zu sagen.

Auch einer oder beide der Chipsätze könnten einen fehlerhaften Ad-hoc-Modus haben, er wird heutzutage nicht viel benutzt und wäre nicht überraschend.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.