wlan0 und udev

[scientific]

Hi Leute, erstmal ein freundliches Begrüße Sie, da ich neu im Forum bin.
Debian verwende ich schon seit 2, Linux seit 4 Jahren. Und mich plagt auch gleich mal ein gröberes Problem.

Wenn ich mit dem physischen Schalter die Wlan-Karte deaktiviere und wieder aktiviere, dann wird das Interface wlan0 nicht mehr gestartet.
Dazu hab ich schon einiges rausgefunden, was aber immer noch nicht geholfen hat.
Mein Netzwerk betreibe ich mit whereami, ifplugd und guessnet. Und ich weiß leider nicht mehr bis wann das so war, aber es hat schon eine geraume Zeit funktioniert. Ich denke einmal, ein Update hat da was zerschossen. Das war unter Lenny. Derzeit verwende ich eine Mischung aus Lenny, Squeeze, Backports und Experimental. Und es funktioniert immer noch nicht. Eher schlechter denn je.

Was ich bisher rausgefunden habe:
In /usr/share/acpi-support/state-funcs wird im sys-Verzeichnis nach einem Unterverzeichnis "wireless" gefragt. Das gibt es aber bei mir im Verzeichnis von wlan0 nicht. Somit ignoriert acpi-support meine wlan-Karte. Ob das einen Einfluss auf die Funktionalität hat, weiß ich noch nicht.

Ich bin darangegangen, dass ich mir für rfkill eine udev-Regel schreibe.

Dazu:

Code: Alles auswählen

# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1257258916.097797] change   /devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3 (rfkill)
UDEV  [1257258916.098248] change   /devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3 (rfkill)

Mit dem Pfad zu rfkill3 hab ich mir weiter Infos geholt:

Code: Alles auswählen

# udevadm info -a -p /devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3':
    KERNEL=="rfkill3"
    SUBSYSTEM=="rfkill"
    DRIVER==""
    ATTR{name}=="3945ABG"
    ATTR{type}=="wlan"
    ATTR{state}=="1"
    ATTR{claim}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0':
    KERNELS=="0000:0c:00.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="iwl3945"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x4222"
    ATTRS{subsystem_vendor}=="0x8086"
    ATTRS{subsystem_device}=="0x1021"
    ATTRS{class}=="0x028000"
    ATTRS{irq}=="29"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{modalias}=="pci:v00008086d00004222sv00008086sd00001021bc02sc80i00"
    ATTRS{numa_node}=="0"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""
    ATTRS{antenna}=="0"
    ATTRS{channels}==""
    ATTRS{flags}=="0x8015"
    ATTRS{filter_flags}=="0x0024"
    ATTRS{measurement}==""
    ATTRS{retry_rate}=="1"
    ATTRS{status}=="0x000002e4"
    ATTRS{temperature}=="-134"
    ATTRS{tx_power}=="16"

Und daraus hab ich mir zwei Regeln gebastelt, welche ich in /etc/udev/rules/00.rules abgelegt habe

Code: Alles auswählen

KERNEL=="rfkill*", DRIVERS=="iwl3945", SUBSYSTEM=="rfkill", ACTION=="change", ATTR{name}=="3945ABG", ATTR{state}=="1", RUN+="/sbin/ifup wlan0"
KERNEL=="rfkill*", DRIVERS=="iwl3945", SUBSYSTEM=="rfkill", ACTION=="change", ATTR{name}=="3945ABG", ATTR{state}=="2", RUN+="/sbin/ifdown wlan0"

Das Ergebnis:

Es rührt sich nichts.

Syslog gibt beim Ausschalten:

Code: Alles auswählen

Nov  3 16:05:10 pluto kernel: [ 6042.121439] iwl3945 0000:0c:00.0: Radio Frequency Kill Switch is On:
Nov  3 16:05:10 pluto kernel: [ 6042.121445] Kill switch must be turned off for wireless networking to work.
Nov  3 16:05:10 pluto bluetoothd[3383]: HCI dev 0 down
Nov  3 16:05:10 pluto bluetoothd[3383]: Adapter /org/bluez/3383/hci0 has been disabled
Nov  3 16:05:10 pluto bluetoothd[3383]: Stopping security manager 0
Nov  3 16:05:10 pluto kernel: [ 6042.176158] usb 3-2: USB disconnect, address 21
Nov  3 16:05:10 pluto kernel: [ 6042.177219] btusb_intr_complete: hci0 urb ffff88007bc75b00 failed to resubmit (19)
Nov  3 16:05:10 pluto kernel: [ 6042.177236] btusb_bulk_complete: hci0 urb ffff88006f9d8980 failed to resubmit (19)
Nov  3 16:05:10 pluto kernel: [ 6042.178222] btusb_bulk_complete: hci0 urb ffff88007bc75a40 failed to resubmit (19)
Nov  3 16:05:10 pluto kernel: [ 6042.178661] btusb_send_frame: hci0 urb ffff880061c8c980 submission failed
Nov  3 16:05:11 pluto bluetoothd[3383]: HCI dev 0 unregistered
Nov  3 16:05:11 pluto bluetoothd[3383]: Unregister path: /org/bluez/3383/hci0

Und beim Wiedereinschalten:

Code: Alles auswählen

Nov  3 16:05:18 pluto udevd-work[8523]: '/sbin/ifup wlan0' unexpected exit with status 0x000d
Nov  3 16:05:18 pluto kernel: [ 6049.611379] Registered led device: iwl-phy0::radio
Nov  3 16:05:18 pluto kernel: [ 6049.611473] Registered led device: iwl-phy0::assoc
Nov  3 16:05:18 pluto kernel: [ 6049.611514] Registered led device: iwl-phy0::RX
Nov  3 16:05:18 pluto kernel: [ 6049.611566] Registered led device: iwl-phy0::TX
Nov  3 16:05:18 pluto kernel: [ 6050.061042] usb 3-2: new full speed USB device using uhci_hcd and address 22
Nov  3 16:05:19 pluto kernel: [ 6050.253059] usb 3-2: New USB device found, idVendor=413c, idProduct=8140
Nov  3 16:05:19 pluto kernel: [ 6050.253063] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov  3 16:05:19 pluto kernel: [ 6050.253149] usb 3-2: configuration #1 chosen from 1 choice
Nov  3 16:05:19 pluto bluetoothd[3383]: HCI dev 0 registered
Nov  3 16:05:19 pluto bluetoothd[3383]: HCI dev 0 up
Nov  3 16:05:19 pluto bluetoothd[3383]: Starting security manager 0
Nov  3 16:05:19 pluto bluetoothd[3383]: Parsing /etc/bluetooth/serial.conf failed: No such file or directory
Nov  3 16:05:19 pluto bluetoothd[3383]: probe failed with driver input-headset for device /org/bluez/3383/hci0/dev_00_24_EF_9A_90_CB
Nov  3 16:05:19 pluto bluetoothd[3383]: Adapter /org/bluez/3383/hci0 has been enabled

Ich bin schon ganz verzweifelt...

Vielleicht kann mir hier jemand weiterhelfen. Weder auf den Debian-Mailinglisten noch im Usenet konnte ich sinnvolle Hilfe erhalten.

lg jakob

[rendegast]

in /etc/udev/rules/00.rules abgelegt

Nov 3 16:05:18 pluto udevd-work[8523]: '/sbin/ifup wlan0' unexpected exit with status 0x000d
Nov 3 16:05:18 pluto kernel: [ 6049.611379] Registered led device: iwl-phy0::radio
Nov 3 16:05:18 pluto kernel: [ 6049.611473] Registered led device: iwl-phy0::assoc
Nov 3 16:05:18 pluto kernel: [ 6049.611514] Registered led device: iwl-phy0::RX
Nov 3 16:05:18 pluto kernel: [ 6049.611566] Registered led device: iwl-phy0::TX

00.rules scheint mir zu früh bezüglich des 'ifup'.
Statt /sbin/ifup ein Testskript starten, um den Status auszulesen,
zBsp. 'ifconfig -a' oder 'ls /dev/'.

Code: Alles auswählen

udevadm test ...

[scientific]

Dass die Regel offenbar zu früh greift, hab ich mir auch schon gedacht. Daher hab ich sie mal mit z65wlan beschriftet, damit sie als letztes abgearbeitet wird. War auch nicht erfolgreich. Denn da wurde die Regel gar nicht mehr berücksichtigt, weil offenbar vorher eine andere zutreffend war. Und das Evend "change" kommt "zu" früh.

Was du mit udevadm test meinst, erschließst sich mir leider noch nicht. Kannst du mir da weiterhelfen?

Ich hab auch noch die Regel z60_ifplugd.rules mit dem Inhalt

Code: Alles auswählen

SUBSYSTEM=="net", RUN+="ifplugd.agent"

entdeckt. Aber der ifplugd.agent reagiert überhaupt nicht auf das Device - keinerlei Meldungen im Syslog (ich hab schon auf debug umgestellt).

lg jakob

[rendegast]

Daher hab ich sie mal mit z65wlan beschriftet, damit sie als letztes abgearbeitet wird. War auch nicht erfolgreich.

Da wurde die Verarbeitung vermutlich schon geschlossen.
Dann früher probieren.


'udevadm test':

Testen mit 'udevadm test' (früher udevtest):

Code: Alles auswählen

    udevadm test /block/hdc

durchläuft die udev-Regeln für das device.
Den passenden Pfad zu finden kann manchmal etwas schwierig sein,
hier vielleicht:

Code: Alles auswählen

udevadm test /devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3

Aber der ifplugd.agent reagiert überhaupt nicht auf das Device

Scheint mir auch eine Möglichkeit, wlan ist berücksichtigt.
War /etc/init.d/ifplugd gestartet?
Und gegebenenfalls konfiguriert? (CFG=/etc/default/ifplugd)


--------------------

Derzeit verwende ich eine Mischung aus Lenny, Squeeze, Backports und Experimental.

halte ich für keine gute Ausgangssituation.

[scientific]

Daher hab ich sie mal mit z65wlan beschriftet, damit sie als letztes abgearbeitet wird. War auch nicht erfolgreich.

Da wurde die Verarbeitung vermutlich schon geschlossen.
Dann früher probieren.

Ich hab jetzt alle Möglichkeiten ausprobiert, die Regel zu platzieren. Entweder schlägt ifup wlan0 fehl, oder die Regel wird nicht berücksichtigt.

'udevadm test':

Testen mit 'udevadm test' (früher udevtest):

Code: Alles auswählen

    udevadm test /block/hdc

durchläuft die udev-Regeln für das device.
Den passenden Pfad zu finden kann manchmal etwas schwierig sein,
hier vielleicht:

Code: Alles auswählen

udevadm test /devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/rfkill/rfkill3

Ein manueller Testlauf bringt das selbe zustande, wie die auswertung des "change"-Events. Es wird die richtige Regel ausgewählt, jenachdem ob aus- oder eingeschalten wird. Das Problem ist, dass offenbar das Device wlan0 noch nicht bereit ist.

Aber der ifplugd.agent reagiert überhaupt nicht auf das Device

Scheint mir auch eine Möglichkeit, wlan ist berücksichtigt.
War /etc/init.d/ifplugd gestartet?
Und gegebenenfalls konfiguriert? (CFG=/etc/default/ifplugd)

Ifplugd ist gestartet, aber der reagiert nicht auf wlan0. Egal ob mit oder ohne Regel. Durch die Dysfunktion von ifplugd bin ich ja erst auf acpi und dann udev gestoßen, dass da etwas nicht stimmen kann.
Interessanterweise reagiert ifplugd wenn ich eine wlan-Verbindung habe (wohlgemerkt händisch gestartet - und es ist eine wpa-gesicherte Verbindung) und mittels »modprobe -r iwl3945« das Modul entlade. Dann fährt ifplugd das Interface herunter.
Lade ich das Modul wieder mit »modprobe -i iwl3945« dann fährt ifplugd das Interface wieder hoch und stellt erneut die Verbindung her.
Schalte ich dazwischen aber mit dem physischen Schalter die Karte aus und wieder ein, bleibt ifplugd regungslos. Also dürfte irgendwas mit dem rfkill nicht stimmen.
Denn wenn ich die Karte mit dem Schalter abschalte, kommen haufenweise Fehlermeldungen a la:
Nov 3 00:57:07 pluto kernel: [ 1714.102401] iwl3945 0000:0c:00.0: Radio disabled by HW RF Kill switch

Ein Entladen des Moduls beendet diese Fehlermeldungen.

--------------------

Derzeit verwende ich eine Mischung aus Lenny, Squeeze, Backports und Experimental.

halte ich für keine gute Ausgangssituation.

Das Verhalten war unter einem reinen Lenny auch nicht anders. Daher hab ich auf div. neuere Pakete aus den anderen Distributionen gewechselt.

lg jakob

[bbcshokker]

Könnte es nicht daran liegen, dass der Treiber im Lenny Kernel diesen kill switch noch nicht richtig unterstützt?
Schon einen neueren probiert? Inkl. neuerer Firmware evtl.

[Danielx]

Damit ich beim iwl3945 überhaupt eine Veränderung beim Kill-Schalter bekomme, muss das wlan0-Interface immer UP sein.
D.h. wenn das Interface DOWN ist, bekommt UDEV nichts mehr von einer Veränderung des Schalters mit.

Überprüft habe ich das mit:

Code: Alles auswählen

cat /sys/bus/pci/drivers/iwl3945/*/rf_kill

und:

Code: Alles auswählen

udevadm info -a -p /sys/bus/pci/drivers/iwl3945/*/rf_kill

Vielleicht hast du ein ähnliches Problem?

Gruß,
Daniel

[scientific]

Ich habe mittlerweile vollständig auf squeeze geupgraded. Funktioniert immer noch nicht.
Also am Modul und der Firmware kann es nicht liegen.
Aber der Killswitch wird definitiv nicht richtig unterstützt.

Was mich noch stutzig macht ist ja die erwähnte Tatsache, dass in /sys/class/net/wlan0 nach einem verzeichnis "wireless" abgefragt wird (bei acpi-support) und dieses Verzeichnis ist bei mir nicht vorhanden. Wie soll also udev oder acpi feststellen, ob das Interface ein wireless-Interface ist?

lg jakob

[scientific]

Damit ich beim iwl3945 überhaupt eine Veränderung beim Kill-Schalter bekomme, muss das wlan0-Interface immer UP sein.
D.h. wenn das Interface DOWN ist, bekommt UDEV nichts mehr von einer Veränderung des Schalters mit.

Überprüft habe ich das mit:

Code: Alles auswählen

cat /sys/bus/pci/drivers/iwl3945/*/rf_kill

und:

Code: Alles auswählen

udevadm info -a -p /sys/bus/pci/drivers/iwl3945/*/rf_kill

Vielleicht hast du ein ähnliches Problem?

Gruß,
Daniel

Bei mir gibt es "rf_kill" nicht. Das sind zwei Unterverzeichnisse rfkill/rfkill*/ und darin gibt es state, power (als unterverzeichnis) usw... hab ich oben eh schon aufgelistet. Die Abfrage von dir funktionieren also nicht.

Das was du vermutest, kann leicht möglich sein. Nur wie bekomme ich das Interface wieder up, wenn ich es mit dem Schalter ausgeschaltet habe und wieder einschalte?

lg jakob

[Danielx]

Nur wie bekomme ich das Interface wieder up, wenn ich es mit dem Schalter ausgeschaltet habe und wieder einschalte?

Ja, das habe ich mich auch schon gefragt.
Am einfachsten dürfte sein, das Interface gar nicht erst DOWN zu machen, sondern nur die Verbindung zu trennen.
Bisher habe ich nämlich nicht herausfinden können, ob iwl3945 überhaupt irgendwelche Infos schickt, die man abfragen könnte, wenn das Interface DOWN ist und man den Schalter betätigt.

Gruß,
Daniel

[scientific]

Was ich jetzt rausgefunden habe:
Ein

Code: Alles auswählen

echo -n 0 > /sys/class/rfkill/rfkill2/state

Hat den selben Effekt wie wenn ich den Schalter betätige.
Ein

Code: Alles auswählen

echo -n 1 > /sys/class/rfkill/rfkill2/state

bringt im Syslog folgendes:
Nov 4 16:09:12 pluto kernel: [ 6025.203339] Registered led device: iwl-phy0::radio
Nov 4 16:09:12 pluto kernel: [ 6025.203427] Registered led device: iwl-phy0::assoc
Nov 4 16:09:12 pluto kernel: [ 6025.203472] Registered led device: iwl-phy0::RX
Nov 4 16:09:12 pluto kernel: [ 6025.203510] Registered led device: iwl-phy0::TX
Nov 4 16:09:12 pluto kernel: [ 6025.217904] ADDRCONF(NETDEV_UP): wlan0: link is not ready

operstate ist und bleibt down.

Code: Alles auswählen

cat /sys/class/net/wlan0/operstate 
down

operstate wird erst wieder up, wenn ich mit ifup das Interface neu starte...
Irgendwo muss da ja ein Schalter sein, den auch ifup betätigt, damit das Interface wieder up wird...

Wenn ich ifup aufrufe dann erscheint diese Zeile im Syslog:
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Wenn ifplugd aktiv wird (z.B. nach dem Wiedereinschalten des wlan-Schalters rfkill), dann erscheint dagegen ein
ADDRCONF(NETDEV_UP): wlan0: link is not ready
Das sind Kernel-Meldungen. wo kommen die her? Und warum wird bei ifup ein CHANGE ausgelöst und bei aktivieren des rfkill-Schalters ein UP???

Fragen über Fragen. Und keine Doku...

lg jakob

[Teddybear]

verschoben

[bmario]

andere Idee, was passiert wenn du die udev Regel so veränderst, dass es ein Script startet, was per modprobe das modul entlädt und anschliesend wieder einhängt und dann ifup macht.
Ich weiß nur leider nicht, ob du dann mit udev in eine Schleife kommst?

mario

[scientific]

Also scheinbar war damals eine gröbere Umstellung im Gange, wo einiges noch nicht aufeinander abgestimmt war und ich hab einen zu neuen Kernel für die udev-Version verwendet.

Jetzt zwei Jahre und einige Kernel- und Udev-Updates (verwende mittlerweile squeeze) funktioniert wieder alles so wie geplant.

Lg scientific