staging.inyokaproject.org

Hallo,
ich experimentiere z.Z mit Ubuntu 11.10 und hostapd v0.7.3. Geräte sind Atheros 42xx PCI (ath5k), zwei USB-Adapter (TP-Link WN821Nv3.1 - ath9k_htc und TP-Link WN-822N - carl9170). Alle laufen absolut stabil.

elektronenblitz63 schrieb:

Hallo,
ich experimentiere z.Z mit Ubuntu 11.10 und hostapd v0.7.3. Geräte sind Atheros 42xx PCI (ath5k), zwei USB-Adapter (TP-Link WN821Nv3.1 - ath9k_htc und TP-Link WN-822N - carl9170). Alle laufen absolut stabil.

Was läuft da für ein Kernel?

Ich habe auf meinem Ubuntu-Server 10.04 momentan einen Ubuntu-Kernel 2.6.39-020639-generic am laufen. Kernel selbst kompilieren ist bis dato immer fehl geschlagen, weil dann die 80211 Treiber nicht mit dabei sein wollen und damit hostapd nicht zum laufen kommt. Mangels Zeit bin ich aber noch nicht hinter das Problem gestiegen, was am Ubuntu-Kernel so anders sein soll als an einem herkömlichen 2.6.39 oder 3.0.3?

Erfolgreich getestet mit dem Standardkernel,

Linux ubuntu 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 athlon i386 GNU/Linux

als auch mit einem Mainline-Kernel 3.1.0-030100rc10-generic

Die genannten USB-Adapter funktionieren nicht mit hostapd v0.6.9 unter 10.04

Die USB-Adapter habe ich momentan auch nicht im Einsatz. Nur die Ralink sPCI Karte.

Das was ich eben nicht verstehe, ein Eigenbau-Kern mit eben jener Version 2.6.39 läuft nicht. Der Ubuntu-Kern tut es aber. Und das mit Version 0.6.9 von hostapd. Auch ein Tausch von 0.6.9 zu 0.7.3 von hostapd hat hier nichts gebracht. Also momentan finde ich meinen Fehler hier nicht.

Mir stehen ja nur die ältere Atheros PCI, eine ältere Prism54 PCMCIA-Karte habe ich jetzt nicht aktuell getestet, und die beiden USB-Adapter zur Verfügung. Mit dem TL-WN821Nv3.1 hatte ich allerdings auch zuerst ein paar Probleme. Läuft hier aber inzwischen absolut stabil.

Du kannst noch einen Modulparameter testen und die Hardware-Entschlüsselung deaktivieren.

echo "options rt2800pci nohwcrypt=1" | sudo tee /etc/modprobe.d/rt2800pci.conf

elektronenblitz63 schrieb:

Du kannst noch einen Modulparameter testen und die Hardware-Entschlüsselung deaktivieren.

Ist der Hinweis evtl. sogar im modinfo zu finden?!

Gugg mal da, letzte Zeile:

wutze@tv:~$ modinfo rt2800pci
filename:       /lib/modules/2.6.39-020639-generic/kernel/drivers/net/wireless/rt2x00/rt2800pci.ko
license:        GPL
firmware:       rt2860.bin
description:    Ralink RT2800 PCI & PCMCIA Wireless LAN driver.
version:        2.3.0
author:         http://rt2x00.serialmonkey.com
srcversion:     4DCEC60A57DA07AEA6693EA
alias:          pci:v00001814d00003593sv*sd*bc*sc*i*
alias:          pci:v00001814d00003592sv*sd*bc*sc*i*
alias:          pci:v00001814d00003562sv*sd*bc*sc*i*
alias:          pci:v00001814d00003062sv*sd*bc*sc*i*
alias:          pci:v00001814d00003060sv*sd*bc*sc*i*
alias:          pci:v00001432d00007722sv*sd*bc*sc*i*
alias:          pci:v00001432d00007711sv*sd*bc*sc*i*
alias:          pci:v00001814d00003390sv*sd*bc*sc*i*
alias:          pci:v00001A3Bd00001059sv*sd*bc*sc*i*
alias:          pci:v00001462d0000891Asv*sd*bc*sc*i*
alias:          pci:v00001432d00007768sv*sd*bc*sc*i*
alias:          pci:v00001432d00007758sv*sd*bc*sc*i*
alias:          pci:v00001432d00007748sv*sd*bc*sc*i*
alias:          pci:v00001432d00007738sv*sd*bc*sc*i*
alias:          pci:v00001432d00007728sv*sd*bc*sc*i*
alias:          pci:v00001432d00007727sv*sd*bc*sc*i*
alias:          pci:v00001432d00007708sv*sd*bc*sc*i*
alias:          pci:v00001814d00003092sv*sd*bc*sc*i*
alias:          pci:v00001814d00003091sv*sd*bc*sc*i*
alias:          pci:v00001814d00003090sv*sd*bc*sc*i*
alias:          pci:v00001814d00000781sv*sd*bc*sc*i*
alias:          pci:v00001814d00000701sv*sd*bc*sc*i*
alias:          pci:v00001814d00000681sv*sd*bc*sc*i*
alias:          pci:v00001814d00000601sv*sd*bc*sc*i*
depends:        rt2x00lib,rt2800lib,rt2x00pci,eeprom_93cx6
vermagic:       2.6.39-020639-generic SMP mod_unload modversions 
parm:           nohwcrypt:Disable hardware encryption. (bool)

Ich habe die Hardware-Entschlüsselung mal nach Deiner Vorlage mit eingefügt. Nun heißt es wieder mal "warten" ... weil wenn es das war, leg ich mir schon mal die Feile zurecht, um den Besen fressen zu können ;o)

OK, fliegt immer noch raus. Selbiges Problem, so wie immer. Und weil es offenbar solch ein Spaß macht, eben noch ein neues (altes) Problem, welches auch nur sehr sporadisch auftritt und wirklich selten.

Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 RADIUS: starting accounting session 4ECA8893-00000066
Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: pairwise key handshake completed (WPA)
Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: received EAPOL-Key Error Request (STA detected Michael MIC failure)
Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 RADIUS: starting accounting session 4ECA8893-00000067
Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: pairwise key handshake completed (WPA)
Nov 22 01:34:56 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: received EAPOL-Key Error Request (STA detected Michael MIC failure)
Nov 22 01:34:56 tv hostapd: wlan0: IEEE 802.11 TKIP countermeasures initiated

Die Verbindung zum WLAN wurde Clientseitig getrennt. Neues anmelden am WLAN erfolgreich und ohne Probleme. Spaßeshalber den Log-Ausschnitt auch mal:

Nov 22 01:35:56 tv hostapd: wlan0: IEEE 802.11 TKIP countermeasures ended
Nov 22 01:35:57 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 IEEE 802.11: authenticated
Nov 22 01:35:57 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 IEEE 802.11: associated (aid 2)
Nov 22 01:35:57 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 RADIUS: starting accounting session 4ECA8893-00000068
Nov 22 01:35:57 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: pairwise key handshake completed (WPA)
Nov 22 01:35:57 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: group key handshake completed (WPA)
Nov 22 01:35:58 tv hostapd: wlan0: STA e4:e0:c5:0b:21:f8 IEEE 802.11: authenticated
Nov 22 01:35:58 tv hostapd: wlan0: STA e4:e0:c5:0b:21:f8 IEEE 802.11: associated (aid 1)
Nov 22 01:35:58 tv hostapd: wlan0: STA e4:e0:c5:0b:21:f8 RADIUS: starting accounting session 4ECA8893-00000069
Nov 22 01:35:58 tv hostapd: wlan0: STA e4:e0:c5:0b:21:f8 WPA: pairwise key handshake completed (WPA)
Nov 22 01:35:58 tv hostapd: wlan0: STA e4:e0:c5:0b:21:f8 WPA: group key handshake completed (WPA)
Nov 22 01:36:01 tv dhcpd: DHCPREQUEST for 192.168.103.22 from 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:01 tv dhcpd: DHCPACK on 192.168.103.22 to 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:01 tv dhcpd: DHCPREQUEST for 192.168.103.22 from 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:01 tv dhcpd: DHCPACK on 192.168.103.22 to 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:10 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 IEEE 802.11: authenticated
Nov 22 01:36:10 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 IEEE 802.11: associated (aid 2)
Nov 22 01:36:10 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 RADIUS: starting accounting session 4ECA8893-0000006A
Nov 22 01:36:10 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: pairwise key handshake completed (WPA)
Nov 22 01:36:10 tv hostapd: wlan0: STA 4c:0f:6e:92:6e:84 WPA: group key handshake completed (WPA)
Nov 22 01:36:13 tv dhcpd: DHCPREQUEST for 192.168.103.22 from 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:13 tv dhcpd: DHCPACK on 192.168.103.22 to 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:13 tv dhcpd: DHCPREQUEST for 192.168.103.22 from 4c:0f:6e:92:6e:84 via wlan0
Nov 22 01:36:13 tv dhcpd: DHCPACK on 192.168.103.22 to 4c:0f:6e:92:6e:84 via wlan0

So, Stand der Dinge ist immer noch, Abbruch der Verbindung mit der Fehlermeldung:

phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2.
Please file bug report to http://rt2x00.serialmonkey.com

Und jetzt nicht nur mit Apples iPhone sondern auch mit Android Geräten. (Android 2.n)

Aber:
Ich habe die Schlüsselintervalle in der hostapd.conf mal verändert und vermutlich extrem hoch gesetzt.

wpa_group_rekey=160000
wpa_ptk_rekey=160000
wpa_gmk_rekey=186400

Seither tritt der besagte Fehler seltener auf. Und auch die Verbindungen zu den einzelnen WLAN-Geräten ist wesentlich stabiler geworden. Bleibt die Frage, warum sind die Schlüsselintervalle Standardmässig so kurz eingestellt?

Hallo. Ein Wert beim "wpa_ptk_rekey" erzeugt ständiges abmelden/anmelden aller Stationen. Falls die TKIP-Methode nicht benutzt wird, kann die Einstellung auf 0 gesetzt werden. Evtl. noch "peerkey" setzen. Daraus ergibt sich folgendes:

wpa_group_rekey=600
wpa_gmk_rekey=86400
wpa_ptk_rekey=0

peerkey=1