Tworzę otwartą sieć ad-hoc za pomocą iwconfig(mam ten sam problem wpa_supplicantrównież). w sieci są 4 węzły, jak pokazano na poniższym rysunku. Węzły działają w Ubuntu 12.04 i Debian Squeeze i mają jądra 3.7.1, 3.5 i 3.2. Używam dwóch różnych marek klucza USB (łącze TP i ZCN), które wszystkie mają mikroukład AR9271 i ath9k_htcsterownik (tutaj jest wyjście lsusb i wyjście ethtool ).
Problem, który napotykam, polega na tym, że dwa węzły ( 10.0.0.2i 10.0.0.5), które mają dongle WiFi USB z łączem TP, mogą pingować dowolny węzeł w sieci i odwrotnie. Jednak inne węzły ( 10.0.0.6i 10.0.0.7), które mają klucz Wi-Fi ZCN, nie mogą pingować się nawzajem, ale nie mają problemu z komunikacją z modułami Wi-Fi TP-link. tcpdumppokazuje to 10.0.0.6i 10.0.0.7nie widzi ich żądania arp, np
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
ale są w stanie zobaczyć i uzyskać odpowiedź z modułów TP-link.
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
Moje pytanie brzmi: co może być przyczyną tego 10.0.0.6i 10.0.0.7nie widzi tego arp-request, że się wysyłają? Jak mogę znaleźć problem?
Jeśli dodam jeszcze kilka węzłów z kluczem Wi-Fi ZCN w sieci, węzły te również nie będą mogły ze sobą rozmawiać, ale są w porządku z łączem TP. Lub jeśli zamienię moduły Wi-Fi, węzły z ZCN zawsze mają problem, ale moduły TP-link są w porządku.
tutaj jest /etc/network/interfaces, ifconfig, iwconfig, ip a, ip r, routewyjścia
EDYCJA: Podejrzewałem, że problem jest arp_filterzwiązany, ale /proc/sys/net/ipv4/conf/*/arp_filterdotyczy 0wszystkich subdomen (*). Jeśli dodam informacje o arp 10.0.0.6i 10.0.0.7ręcznie na tych węzłach, tcpdumpi wiresharknie pokażę, że wysyłają pingsobie nawzajem. Jeśli mam pingadres rozgłoszeniowy (w moim przypadku 10.0.0.255) 10.0.0.6i mogę 10.0.0.7go usłyszeć.
EDYCJA 2: Oto pliki pcap http://filebin.net/6cle9a5iae z 10.0.0.6(moduł ZCN), 10.0.0.7(moduł ZCN) i 10.0.0.5(moduł TP-link, który nie ma problemu). oto wyniki ping z 10.0.0.6 http://pastebin.com/swFP2CJ9 Przechwyciłem pakiety jednocześnie. Link zawiera również ifconfig; iwconfig; i uname- awyniki dla każdego węzła.
kismet? Obejmie to nagłówki 802.11 na wypadek, gdyby było w nich coś dziwnego.Odpowiedzi:
Ostatnio miałem ten sam problem. Doszedłem do wniosku, że chipset AR9271 ma problem z anteną nadajnika na pokładzie. Jeśli użyjesz anteny zewnętrznej, nie będziesz mieć problemu. Ten problem występuje tylko w trybie ad-hoc.
Powodem, dla którego nie występują problemy z łączem TP, powinno być to, że moduły te wykorzystują antenę zewnętrzną, która rozwiązuje problem mikroukładu, a moduły ZCN nie powinny mieć anteny zewnętrznej.
źródło
Może to być związane z „ problemem ukrytego węzła ”, jeśli .6 i .7 nie są w bezpośrednim kontakcie radiowym, ale bez znajomości odległości nie można powiedzieć.
Również jeden lub oba chipsety mogą mieć wadliwy tryb ad-hoc, obecnie nie jest często używany i nie byłoby zaskoczeniem.
źródło