☰

WPA_CLI zeigt den Zugriffspunkt als verbunden an, obwohl dies nicht der Fall sein sollte

tag-icon • tag-icon networking wifi wpa-supplicant 802.1x wpa-cli
WPA_CLI zeigt den Zugriffspunkt als verbunden an, obwohl dies nicht der Fall sein sollte

Ich verwende Linux-Kernel 3.3 und versuche, mit dem wpa_cliDienstprogramm den Status meiner WLAN-Verbindung zu überwachen. Ich verwende einen Edimax-WLAN-Dongle, um eine Verbindung zu einem drahtlosen Zugriffspunkt herzustellen.

Normalerweise sehe ich so etwas:

# wpa_cli status
Selected interface 'wlan0'
wpa_state=SCANNING
ip_address=XXX.XXX.XXX.XXX
address=XX:XX:XX:XX:XX:XX

Oder dasselbe, aber mit wpa_state=COMPLETED.

Durch das Parsen dieser Textausgabe kann ich sehen, ob meine drahtlose Verbindung aktiv ist oder scannt. Allerdings habe ich festgestellt, dass mein Access Point nach dem Ausschalten wpa_state=COMPLETEDimmer noch zurückgegeben wird. Mit dem Befehl:

# iwlist wlan0 scanning

Erzwingt einen Scan und wpa_stateist korrekt.

Erzwingt einen Scan und wpa_stateist gelegentlich korrekt, normalerweise jedoch nicht.

Ich frage mich, ob ich irgendwo eine falsche Konfiguration habe oder ob es eine effizientere Möglichkeit gibt, dies zu tun (ich möchte im Grunde nur sehen, ob meine Schnittstelle eine aktive Verbindung hat oder nicht). Hier ist /etc/wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
country=US


network={
    ssid="myssid"
    psk="mypsk"
    key_mgmt=WPA-PSK
    eap=
}

Ich würde es vorziehen, nicht jedes Mal einen Scan zu erzwingen, sondern das den Treiber-/Kernelmodulen zu überlassen. Ich arbeite zum ersten Mal mit WLAN unter Linux, daher denke ich, dass ich wahrscheinlich etwas falsch konfiguriert habe. Kann mir jemand den richtigen Weg weisen?

Aktualisieren:

Nach einigen weiteren Untersuchungen glaube ich, dass etwas Seltsames passiert, das dazu führt, dass der Kernel eine zwischengespeicherte Version der AP-Liste zurückgibt. Ich verwende den RTL8192cuTreiber, also habe ich mit dem Debuggen begonnen. Ich denke, mein Problem könnte damit zusammenhängenDas, aber nicht genau derselbe Fehler, da ich einen aktuelleren Kernel habe als den dort verwendeten 2.6-Kernel.

Aktualisierung 2:

Ich glaube, das Problem liegt irgendwo im Kernel. In der Datei net/mac80211/scan.c, in Zeile 214 der Funktion ieee80211_scan_rx, sehe ich ein bssidvon BSSmeinem AP erscheinen (wenn der AP mit Strom versorgt ist) und wird über ieee80211_rx_bss_put(Hier). An diesem Punkt wird es in den Scan-Ergebnissen zurückgegeben und wpa_supplicantveranlasst die MLMESchicht im Kernel, sich zu authentifizieren und eine Verbindung mit diesem AP herzustellen. Nachdem ich jedoch die AP-Stromversorgung getrennt habe, sehe ich nie, dass die MLMESchicht ihren atomic_tZugriff darauf aufgibt BSS. Dies führt dazu, dass die Verknüpfung in der Funktion am Ende eines Scans ( ), in Datei , Zeile 205 ( BSSnie aufgehoben wird .cfg80211_bss_expirecfg80211_wext_giwscannet/wireless/scan.cHier).

Muss ich mit wpa_supplicant eine Konfiguration hinzufügen, damit die MLMEEbene ihren Einfluss verringert BSS, oder handelt es sich hier eindeutig um einen Kernel-Fehler?

Ich habe bereits versucht:

# wpa_cli bss_expire_age 10
# wpa_cli bss_expire_count 2

und hat mein Problem nicht gelöst.

Antwort1

Nach einigem Suchen fand ich heraus, dass das Problem am rtlwifiTreiber des Kernels lag. Für mich sieht es so aus, als ob der rtl8192cuTreiber für die Verarbeitung verpasster Beacons verantwortlich sein sollte, indem er die Funktion aufruft ieee80211_beacon_loss, aber dieser Aufruf ist nirgends zu finden. Ich habe die Unterstützung für IEEE80211_HW_BEACON_FILTERim rtlwifiTreiber entfernt und das Problem wurde behoben.

DasPatchsind im Wesentlichen die gleichen Änderungen, die ich vorgenommen habe, und die Kommentare in diesemDateisind Teil dessen, was mich zu dieser Antwort geführt hat.

verwandte Informationen