Arch Linux

WLAN Verbindung hergestellt, aber kein Host erreichbar

hydro

Ich kann auf einem neu erworbenem Notebook mit wpa_supplicant eine Verbindung zum Router herstellen und erhalte per DHCP
eine IP. Es ist aber kein Host im Internet oder im lokalen Netz erreichbar, nicht einmal den Router kann ich anpingen.
Erst eine seltsame Prozedur erweckt das WLAN zum Leben: Rufe ich im Firefox die Webseite des Routers (D-Link DIR-615) auf,
erscheint nach einer Weile

The connection has timed out
The server at 192.168.0.1 is taking too long to respond.

Rufe ich dieselbe Seite danach erneut auf (Strg+Umschalt+R) wird sie evtl. nach weiterer Wartezeit
dann doch angezeigt - und siehe da: Alles andere funktioniert danach auch (ping, SSH, IMAP...) und das bleibt dann auch so.
Manchmal funktioniert die Prozedur auch mit einer Seite im Internet, die Fehlermeldung ist dann zunächst "Server not found".

Das Problem besteht seit der Installation von Arch Linux vor knapp 2 Wochen und wird ähnlich hier beschrieben. Es handelt sich um denselben WLAN-Chip:

$ lspci -nn | grep wireless
02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)

Zuständig ist das Modul ath9k

$ basename `readlink /sys/class/net/wlan0/device/driver/module`
ath9k

$ lsmod|grep ath9k
ath9k                  87407  0 
ath9k_common            2096  1 ath9k
ath9k_hw              347154  2 ath9k_common,ath9k
ath                    14802  3 ath9k_hw,ath9k_common,ath9k
mac80211              228527  1 ath9k
cfg80211              172260  3 mac80211,ath,ath9k

Es läuft kein Netzwerkdämon, die Verbindung wird erst einmal manuell hergestellt

# ifconfig wlan0 up
# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
network={
	proto=RSN
	key_mgmt=WPA-PSK
	pairwise=CCMP
	group=CCMP
	ssid="XXX"
	psk=XXX
}

# wpa_supplicant -B -Dwext -iwlan0 -c/etc/wpa_supplicant.conf 
# wpa_cli status
Selected interface 'wlan0'
bssid=xx:xx:xx:xx:xx:xx
ssid=XXX
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED

# dhcpcd -d wlan0 
dhcpcd[598]: version 5.5.4 starting
dhcpcd[598]: wlan0: using hwaddr xx:xx:xx:xx:xx:xx
dhcpcd[598]: wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd[598]: wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd[598]: wlan0: sending IPv6 Router Solicitation
dhcpcd[598]: wlan0: reading lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
dhcpcd[598]: wlan0: rebinding lease of 192.168.0.105
dhcpcd[598]: wlan0: sending REQUEST (xid 0x9f30e817), next in 4.26 seconds
dhcpcd[598]: wlan0: sending IPv6 Router Solicitation
dhcpcd[598]: wlan0: sending REQUEST (xid 0x9f30e817), next in 7.48 seconds
dhcpcd[598]: wlan0: acknowledged 192.168.0.105 from 192.168.0.1
dhcpcd[598]: wlan0: checking for 192.168.0.105
dhcpcd[598]: wlan0: sending ARP probe (1 of 3), next in 1.05 seconds
dhcpcd[598]: wlan0: sending ARP probe (2 of 3), next in 1.22 seconds
dhcpcd[598]: wlan0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd[598]: wlan0: sending IPv6 Router Solicitation
dhcpcd[598]: wlan0: leased 192.168.0.105 for infinity
dhcpcd[598]: wlan0: adding IP address 192.168.0.105/24
dhcpcd[598]: wlan0: adding route to 192.168.0.0/24
dhcpcd[598]: wlan0: adding default route via 192.168.0.1
dhcpcd[598]: wlan0: writing lease `/var/lib/dhcpcd/dhcpcd-wlan0.lease'
dhcpcd[598]: wlan0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd[598]: forking to background
dhcpcd[598]: forked to background, child pid 626

# ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 192.168.0.105  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 xxxx::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 18  bytes 1526 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19  bytes 2330 (2.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# iwconfig wlan0
wlan0     IEEE 802.11bgn  ESSID:"XXX" 
          Mode:Managed  Frequency:2.472 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=65 Mb/s   Tx-Power=15 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=61/70  Signal level=-49 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:18   Missed beacon:0

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    303    0        0 wlan0
192.168.0.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

# cat /etc/resolv.conf 
# Generated by dhcpcd from wlan0
# /etc/resolv.conf.head can replace this line
domain localdomain
nameserver 192.168.0.1
# /etc/resolv.conf.tail can replace this line

Sieht also alles gut aus, jedoch...

# ping -w 30 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 29009ms

Erst die oben beschriebene Prozedur führt meistens zum Erfolg. Hat jemand eine Erklärung dafür und/oder kann mir sagen, wie ich das WLAN von Anfang auch für SSH&Co nutzen kann ohne zuerst immer die Webseite des Router zu öffnen und den Timeout abzuwarten?
Die im Zusammenhang mit WEP (was ich ja nicht verwende) oft genannte Moduloption nohwcrypt=1 ergibt keinen Unterschied, Installation von compat-wireless oder Kerneldowngrade möchte ich vermeiden. Der Router funktioniert mit anderen WLAN-Clients übrigens problemlos.

GerBra

Dein Router (192.168.0.1) anwortet auch konfigurationsbedingt auf ICMP/ping? (ich denke ja...)

Das problem könnte sich auch weniger bei TCP/IP abspielen, sondern auf der Link-Ebene(wap_supplicant, Link)...
Laß dein wpa_supplicant-Auruf ggf. mal ohne -B in einem Fenster laufen (bzw. kontrolliere mit tailf /var/log/evrything.log) ob z.B. während der Ping-Versuche o.ä. der Link zum AccessPoint immer wieder wegbricht... Der "richtige, gute Link" ist bei WLan das gleiche wei bei Ethernet das kabel in NIC und Switch, ohne Link-Verbindung kein TCP/IP....

Neuere Atheros scheinen (was ich lese) öfters Probleme zu machen. Ich würde versuchen:
a) anderen Kanal verwenden
b) mit anderem Cipher/Group in der wpa_supplica,nt.conf, bzw. wpa_supplicant das selbst aushandeln lassen. Es sollte ausreichen nur SSID und PSK anzugeben).
c) linux-firmware ist installiert? (Ohne dürftest du aber soweit garnicht kommen...)
d) Warten, bis jemand mit ath9k Erfahrung/Tips dir bessere Ratschläge geben kann ;-)

hydro

Danke schonmal, ich habe derweil compat-wireless-patched installiert, was eine geringfügige Verbesserung zur Folge hatte: Mitunter wird die erste mit dem Firefox aufgerufene Internetseite auf anhieb geladen, wobei es mit Seiten, die ich schon vorher besucht hatte zuverlässiger zu funktionieren scheint. Alles andere ist aber unverändert.

GerBra schriebDein Router (192.168.0.1) anwortet auch konfigurationsbedingt auf ICMP/ping? (ich denke ja...)

Ja, funktioniert nach der ersten erfolgreichen Datenverbindung per Browser dann auch

GerBra schrieb Das problem könnte sich auch weniger bei TCP/IP abspielen, sondern auf der Link-Ebene(wap_supplicant, Link)...
Laß dein wpa_supplicant-Auruf ggf. mal ohne -B in einem Fenster laufen (bzw. kontrolliere mit tailf /var/log/evrything.log) ob z.B. während der Ping-Versuche o.ä. der Link zum AccessPoint immer wieder wegbricht... Der "richtige, gute Link" ist bei WLan das gleiche wei bei Ethernet das kabel in NIC und Switch, ohne Link-Verbindung kein TCP/IP....

Ich habe wpa_supplicant mit -d statt -B gestartet und die Ausgabe ebenso wie die von tail -f /var/log/everything.log im Auge behalten, während ich versucht haben den Router, einen anderen PC im Netz oder Hosts im Internet anzupingen oder mich per SSH zu verbinden. Es wurden dabei keine weiteren Ausgaben generiert.

GerBra schrieb a) anderen Kanal verwenden

Auf dem jetzigen Kanal 13 sind die geringesten Überlappungen mit Nachbarnetzen, ich war schon letztes Wochende vorübergehend auf Kanal 11 zurückgewechselt, was allerdings nichts geändert hatte, ich werde damit vielleicht noch weiter experimentieren.

GerBra schrieb b) mit anderem Cipher/Group in der wpa_supplica,nt.conf, bzw. wpa_supplicant das selbst aushandeln lassen. Es sollte ausreichen nur SSID und PSK anzugeben).

Ich habe jetzt nur SSID und PSK angegeben, funktioniert dann auch, ändert aber nichts. Evtl. werde ich im Router TKIP wieder erlauben.

                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK

GerBra schrieb c) linux-firmware ist installiert? (Ohne dürftest du aber soweit garnicht kommen...)

GerBra

Probleme mit ipv6 könnten ggf. noch eine Rolle spielen, würde zwar nicht zu allen beschriebenen Erscheinungen passem, abstellen könnte aber noch ein Versuch wert sein (Wiki -> ipv6)...

hydro

Ich habe jetzt zweimal mit der Kerneloption ipv6.disable=1 gebootet, das erste mal konnte auch der Browser keine Seite (auch den Router nicht) erreichen, das zweite mal ging es dann wieder, insgesamt aber keine Veränderung.

hydro

Ich hatte jetzt Gelegenheit zu einigen weiteren Untersuchungen. Wie es scheint, ist zunächst ein erhöhtes Datenaufkommen erforderlich, damit Pakete tatsächlich verschickt bzw. empfangen werden.

$ ping -c 15 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.

--- 192.168.0.100 ping statistics ---
15 packets transmitted, 0 received, 100% packet loss, time 14005ms

Es genügt, einmalig das Ping-Intervall zu verringern:

$ ping -c 15 -i 0.2 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=6 ttl=64 time=2.92 ms
64 bytes from 192.168.0.100: icmp_req=7 ttl=64 time=1.77 mskommt
64 bytes from 192.168.0.100: icmp_req=8 ttl=64 time=1.76 ms
64 bytes from 192.168.0.100: icmp_req=9 ttl=64 time=1.83 ms
64 bytes from 192.168.0.100: icmp_req=10 ttl=64 time=1.63 ms
64 bytes from 192.168.0.100: icmp_req=11 ttl=64 time=4.08 ms
64 bytes from 192.168.0.100: icmp_req=12 ttl=64 time=1.75 ms
64 bytes from 192.168.0.100: icmp_req=13 ttl=64 time=1.78 ms
64 bytes from 192.168.0.100: icmp_req=14 ttl=64 time=1.75 ms
64 bytes from 192.168.0.100: icmp_req=15 ttl=64 time=1.84 ms

--- 192.168.0.100 ping statistics ---
15 packets transmitted, 10 received, 33% packet loss, time 2829ms
rtt min/avg/max/mdev = 1.639/2.115/4.085/0.745 ms

Die ersten Pakete gehen verloren, danach steht die Verbindung, man kann dann also auch im normalen Tempo erfolgreich pingen, etc. Das ist schon mal komfortabler, als das Hantieren mit dem Browser. Übrigens tritt dieses Phänomen mit compat-wireless ebenso wie mit kernel 3.2.9 und auch mit dem lts-kernel 3.0.23 auf.