wpa_supplicant startet nicht

**Alpha**

Hi!
Ich hab mir neben Gentoo auf meinem RPi3 wpa_supplicant installiert, damit ich in mein WLAN rein kann.

Mittels "iw scan" finde ich mein Netz auch.
Das Problem ist, dass irgendwas mit Sockets nicht stimmt.

wpa_supplicant kann nicht starten, weil es das control interface nicht starten kann.
Ich glaube nicht, dass das ein Problem von wpa_supplicant ist, sondern grundsätzlich etwas nicht stimmt, weil da ein Socket? nicht aufgemacht werden kann:
ctrl_iface bind(PF_UNIX) failed: Invalid argument

Auf meinem Notebook rennt mit der selben Config wpa_supplicant einwandfrei, ebenfalls Gentoo.

Der Kernel ist aus den Rasperry Pi Sourcen gebaut (4.4.5)

Code

cd /usr/share/linux
KERNEL=kernel7
make zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/*.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img

Code

Using existing control interface directory.
ctrl_interface_group=10 (from group name 'wheel')
ctrl_iface bind(PF_UNIX) failed: Invalid argument
ctrl_iface exists, but does not allow connections - assuming it was leftover from forced program termination
Could not unlink existing ctrl_iface socket '/var/run/wpa_supplicant/wlan0': No such file or directory
Failed to initialize control interface 'DIR=/var/run/wpa_supplicant GROUP=wheel'.
You may have another wpa_supplicant process already running or the file was
left by an unclean termination of wpa_supplicant in which case you will need
to manually remove this file before starting wpa_supplicant again.

Die Konfiguration ist wie folgt:

Code

# Zugriff für Gruppe "wheel" erlauben
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
update_config=1


# Battlestar Galactica (2.4 GHz, WPA2)
network={
        group=CCMP
        key_mgmt=WPA-PSK
        pairwise=CCMP
        priority=1
        proto=WPA2
        # psk="xxxxxx"
        psk=xxxxxx
        scan_ssid=1
        ssid="Battlestar Galactica"
}


# Battlestar Columbia (2.4 GHz, WPA2-EAP)
network={
        eap=TTLS
        group=CCMP
        identity="xxxxxxx"
        key_mgmt=WPA-EAP
        pairwise=CCMP
        password="xxxxxxxx"
        phase2="auth=MSCHAPV2"
        priority=2
        proto=WPA2
        scan_ssid=1
        ssid="Battlestar Columbia"
}

Alles anzeigen

mrshadowtux

Hast du die Firmware für deine WLAN-Karte geladen? Greppe mal in dmesg danach.

**Alpha**

Zitat von mrshadowtux

Hast du die Firmware für deine WLAN-Karte geladen? Greppe mal in dmesg danach.

Ja. Die Karte läuft und funktioniert. Wie ich schrieb, ein "iw scan" findet WLAN-Netze. Wäre die Firmware nicht da, wäre das Interface garnicht da.

Wenn ich das control_interface deaktiviere, startet auch wpa_supplicant und baut eine Verbindung auf. Nur brauche ich das control_interface, wenn ich mit wpa_supplicant interagieren (z.B. wie NetworkManager oder anderen Tools) will.

**Alpha**

Okay, ich habe gerade festgestellt, dass mein Logger (metalog) auch nicht läuft x_X

# metalog
metalog: Unable to bind a local socket: Invalid argument
metalog: error: Unable to bind sockets

Heißt, das Problem hat nix mit wpa_supplicant direkt zu tun. Ich hab irgendwo ein Problem mit den sockets?
Jemand eine Idee, wie ich das analysiert kriege? Tippe stark, da passt was an der Kernelconfig nicht.

**DosAmp**

Hast du Unix-Sockets im Kernel oder als Modul (CONFIG_UNIX)?

**Alpha**

Ja. CONFIG_UNIX=y ist gesetzt.

**Alpha**

Okay, ich hab die Ursache, aber ich verstehe das Problem dahinter nicht o_O

Bei meinen CFLAGS habe ich u.a. folgendes gesetzt: -mstructure-size-boundary=32
Wenn ich wpa_supplicant oder metalog ohne dies neu kompiliere, klappen die sockets alle sofort und es läuft.
Wenn ich mit der Option aktiv es erneut kompiliere, klappen die Sockets nicht mehr.

Ich habe diese Option eigentlich damals von den GCC-Devs als Empfehlung fürn Raspi (2) bekommen.. aber offenbar hat das irgendwelche Nebenwirkungen.

Code

The sizes of all structures and unions are rounded up to a multiple of the number of bits set by this option. Permissible values are 8, 32 and 64. The default value varies for different toolchains. For the COFF targeted toolchain the default value is 8. A value of 64 is only allowed if the underlying ABI supports it.
Specifying a larger number can produce faster, more efficient code, but can also increase the size of the program. Different values are potentially incompatible. Code compiled with one value cannot necessarily expect to work with code or libraries compiled with another value, if they exchange information using structures or unions.

Das ganze System ist mit der Option aber übersetzt, also kann ich mir hier irgendwie keine Kompatibilitätsprobleme vorstellen. Kennt da noch jemand weiterführende Informationen?

freaked

Öhm Deutsches Raspberry Forum könnte helfen öö

**DosAmp**

Das klingt plausibel und kann ich nachvollziehen.

Ein Adress-struct für ein Unix-Socket sieht so aus:

Code

struct sockaddr_un {
    sa_family_t sun_family;
    char sun_path[108];
};

sa_family_t ist ein 16-Bit-Integer, also kommt das struct normalerweise bei 2+108=110 Byte heraus. Wenn man aber die von dir angegebene Option -mstructure-size-boundary=32 nutzt, bläst der Compiler das struct auf das nächste Vielfache von 32 Bit, also 112 Byte auf, und wenn man im bind-Systemaufruf dann wahrheitsgemäß 112 Byte als Größe der Adresse für ein Unix-Socket übergibt, verweigert der Kernel das mit EINVAL.

Zitat

EINVAL addrlen is wrong, or addr is not a valid address for this socket's domain.

Dieses minimale C-Programm wirft einen Fehler auf Linux/arm, wenn es mit -mstructure-size-boundary=32 kompiliert wird, aber ohne (bzw. wenn man statt sizeof(testaddr) den Wert 110 hartkodiert) funktioniert es.

C

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>


#define SOCKET_PATH "/tmp/test.sock"


int main() {
        struct sockaddr_un testaddr;
        testaddr.sun_family = AF_UNIX;
        strcpy(testaddr.sun_path, SOCKET_PATH);
        int s = socket(AF_UNIX, SOCK_STREAM, 0);
        int bind_res = bind(s, (struct sockaddr *) &testaddr, sizeof(testaddr));
        if (bind_res) {
                perror("bind");
                return 1;
        }
        close(s);
        unlink(SOCKET_PATH);
        return 0;
}

Alles anzeigen

Das scheint im Übrigen ein bekanntes Problem mit Netzwerk-Stacks auf ARM zu sein.
gcc auf x86 kennt -mstructure-size-boundary schon gar nicht erst.

**Alpha**

Wow.. nice, vielen Dank für diese Erklärung!
Kommt sogar hin, weil ich in strace die 112 gesehen habe

**Blue**

[23:35:58] <Wynton> bin echt begeistert

**Alpha**

Hast jemand noch eine Idee, wieso mein fucking wpa_supplicant keine SSID sieht?

wlan0: Event SCAN_RESULTS (3) received
wlan0: Scan completed in 0.481686 seconds
nl80211: Received scan results (0 BSSes)

Mit "iw config" sehe ich ein haufen WLAN-Netze..

**Alpha**

Okay, falscher Treiber offenbar. Anstatt nl80211 muss ich wext nutzen. Dann klappts mit wpa_supplicant.

**DosAmp**

Das ist merkwürdig, weil iw das Konfigurationstool für die nl80211- und wext die alte Wireless-Extensions-API ist. Aber über letztere läuft wpa_supplicant mit aktuellen WLAN-Treibern dennoch oft besser.

**Alpha**

Keine Ahnung.. ich habe bisher nur die original config fürn RPi3 kompiliert (bcm2709_defconfig), ggf. fehlt da ja was?

wpa_supplicant startet nicht

Jetzt mitmachen!

Benutzer online in diesem Thema