☰

wpa_supplicant – erkennt, dass mein Passwort falsch ist?

tag-icon • tag-icon linux wireless-networking wpa-supplicant wpa2-psk
wpa_supplicant – erkennt, dass mein Passwort falsch ist?

Wenn ich beim Verbinden mit einem WLAN-Netzwerk ein falsches Kennwort angebe, kann dann trotzdem erkannt werden, dass die Ursache für die fehlgeschlagene Verbindung das falsche Kennwort ist (und nicht einer der vielen anderen möglichen Gründe für die fehlgeschlagene Verbindung).

Hier füge ich z. B. ein Netzwerk hinzu, gebe aber absichtlich das falsche Passwort an. Wenn ich den Status überprüfe, sehe ich nur, dass esSCANNING

# wpa_cli add_network
Selected interface 'wlan0'
1
# wpa_cli set_network 1 ssid \"MyPlace\"
Selected interface 'wlan0'
OK
# wpa_cli set_network 1 psk \"SuperSecret\"
Selected interface 'wlan0'
OK
# wpa_cli select_network 1
Selected interface 'wlan0'
OK
# wpa_cli status
Selected interface 'wlan0'
wpa_state=SCANNING
p2p_device_address=fe:c2:de:37:93:11
address=fc:c2:de:37:93:11

Wenn ich ein Skript schreibe, das wpa_cli statusnach Auswahl des Netzwerks wiederholt ausgeführt wird, kann ich sehen, dass es die folgenden Phasen durchläuft:

SCANNING
ASSOCIATING
4WAY_HANDSHAKE
DISCONNECTED
SCANNING

Gibt es also eine Möglichkeit, herauszufinden, dass die Zuordnungs-/Handshake-Phase aufgrund eines falschen Passworts fehlgeschlagen ist? Meldet das Trennungsereignis beispielsweise einen Grund, der gespeichert ist und den ich dann abfragen kann?

Antwort1

Wenn wir uns ansehenwpa_supplicant/events.c:2326wir sehen:

if (could_be_psk_mismatch(wpa_s, reason_code, locally_generated)) {
    wpa_msg(wpa_s, MSG_INFO, "WPA: 4-Way Handshake failed - "
        "pre-shared key may be incorrect");
    if (wpas_p2p_4way_hs_failed(wpa_s) > 0)
        return; /* P2P group removed */
    wpas_auth_failed(wpa_s, "WRONG_KEY");
}

Wenn diese Logik also angewendet wird, erfolgt eine Protokollierung WPA: 4-Way Handshake failed - pre-shared key may be incorrect.

Dann geht es weiter zuwpa_supplicant/wpa_supplicant.c:5136und wir sehen:

wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_TEMP_DISABLED
    "id=%d ssid=\"%s\" auth_failures=%u duration=%d reason=%s",
    ssid->id, wpa_ssid_txt(ssid->ssid, ssid->ssid_len),
    ssid->auth_failures, dur, reason);

Also hier <3>CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="MyPlace" auth_failures=1 duration=10 reason=WRONG_KEYwird geloggt.

So kann ich entweder dafür sorgen, dass wpa_supplicantes so gestartet wird, dass es seine Ausgabe in eine Datei protokolliert und dann grepfür solche Meldungen sorgt.

Oder ich kann es wpa_cliim interaktiven Modus ausführen. In diesem Modus werden alle wpa_supplicantNachrichten abonniert und ausgegeben.

Die ziemlich provisorische Lösung, die mir einfiel, bestand darin, es wpa_cliin einem Skript auszuführen und ihm vorzugaukeln, es befände sich im interaktiven Modus:

#!/bin/bash

function poke {
    while true
    do
        printf '\n'
        sleep 1
    done
}

function watch {
    (poke) | wpa_cli | while read line
    do
        case "$line" in
            *'4-Way Handshake failed'*)
                echo "incorrect key"
                return
            ;;
            *'CTRL-EVENT-CONNECTED'*)
                echo "connected"
                return
            ;;
        esac
    done
}

wpa_cli disable_network 0 > /dev/null
wpa_cli enable_network 0 > /dev/null

watch

wpa_cligibt nur dann Nachrichten aus, die es empfangen hat, nachdem eine Benutzereingabe erfolgt ist, daher pokestellt die Funktion dies bereit.

Dieses Skript aktiviert das 0. Netzwerk und schaut sich wpa_supplicantdabei an, welche Ausgaben es liefert.

Wie gesagt, das ist ein ziemlicher Hack, aber es funktioniert.

verwandte Informationen