PDA

View Full Version : NetworkManager mit 2 Wlan-Geräten



Paulcat
06-Oct-2010, 07:21
Werte Forumsgemeinde,

bin Neuankömmling in diesem Forum wie auch in der Linuxwelt. Partielle Grundkenntnisse zum Umgang mit Opensuse und KDE sind mittlerweile dank permanenter Hilfe meines Freundes caerdu vorhanden. Trotzdem, jeden Tag 5-10 neue Fragen...

Nun zu meinem Problem: Mein älteres Notebook (HP nx7000) hat ein eingebautes Wlan-Gerät (ipw2100), allerdings mit altem Standard (11kb/s). Es ist eingerichtet, die Verbindungen ins heimische Netzwerk funktionieren per Networkmanager, aber eben langsam..

Also habe ich mit Hilfe dieses Forums meinen schnelleren Fritz Wlan Stick über ndiswrapper installiert, ich denke auch erfolgreich, zumindest meldet iwconfig das neue Interface als wlan0 (eth1 ist der interne Adapter)

Sind beide angeschlossen, wollen beide auch die im Networkmanager (Plasmoid Netzwerkverwaltung) hinterlegte Verbindung nutzen - natürlich mit derselben IP-Adresse, das führt zu Problemen (FritzStick lässt sich im Plamoid nicht zur aktiven "Wlan-schnittstelle" machen).

Schalte ich den internen Adapter am Laptop per geräteeigenem Schalter ab, um den Fritz Stick allein und konfliktfrei zu betreiben, werden alle "drahtlosen verbindungen" deaktiviert, also auch der FritzStick.

Die naheliegendste Lösung wäre ja, jedem Adapter eine eigene IP zuzuweisen, wie ich es von XP etc. kenne (gutes Prog dort: NetsetMan), und weiter entscheiden zu können, welches Gerät je nach Situation aktiviert werden soll.

Lässt sich das ohne ifup bewerkstelligen (ist nicht gerade die Variante, die mir handlich und flexibel erscheint, um häufiger verschiedene Verbindungen zu nutzen)?

Danke vorab für Eure Hilfe,

Paulcat

Paulcat
06-Oct-2010, 14:58
Nachtrag:
Wäre das Problem unter LXDE leichter zu lösen?

Akoellh
06-Oct-2010, 15:37
Wenn die interne Karte eh nicht verwendet werden soll, dann wäre das blacklisten des Kerneltreibers (in dem Fall also ipw2100) die einfachste Lösung.

Paulcat
07-Oct-2010, 00:06
Danke für die Antwort. "Blacklisten" sagt mir bislang noch nichts, muss ich erstmal klären. Würde aber gerne so flexibel bleiben, dass ich das interne Interface durchaus noch benutzen kann, wenn der Stick anderweitig im Einsatz ist.

Akoellh
07-Oct-2010, 02:02
Danke für die Antwort. "Blacklisten" sagt mir bislang noch nichts, muss ich erstmal klären.

Tante G wirft zu "Kerneltreiber Linux blacklist" als einen der ersten Treffer einen längeren, sehr guten Artikel aus dem Wiki einer anderen, weit verbreiteten Distro aus. Der Teil, der für Dich am interessantesten sein dürfte (wobei das nicht heissen soll, daß der Rest nicht lesenswert ist), ist distributionsunabhängig, allerdings würde ich fürs Blacklisten entweder eine eigene Konfigurationsdatei anlegen oder die 99-local.conf verwenden.


Würde aber gerne so flexibel bleiben, dass ich das interne Interface durchaus noch benutzen kann, wenn der Stick anderweitig im Einsatz ist.

Nun, das geht auch mit einem blacklist-Eintrag, man müsste den Treiber nur bei Bedarf von Hand laden (wie das geht, steht auch in besagtem Artikel).

Das Ganze geht mit etwas mehr Vorarbeit auch etwas eleganter, allerdings will ich Dir keine fertige Lösung hinklatschen (mal ganz davon abgesehen, daß ich es noch nicht könnte, weil mir die USB-ID des Sticks fehlt), wo ist da der Spaß (bzw. Lerneffekt)?

Wie interessant dieser Thread wird, hängt ab jetzt auch davon ab, wie interessant Du ihn für die Helfer machst, bisher ist es für mich ein Thread der Marke "damit will ich eigentlich wegen dieses AVM-Schrotts und ndiswrapper nichts zu tun haben" (die Gründe findet man, wenn man mal ein wenig der Linuxpolitik von AVM in den letzten paar Jahren hinterhergooglet), aber ich schlage Dir einen Deal vor.

Ich klatsche Dir mal was vor die Füße.

http://reactivated.net/writing_udev_rules.html

Schau Dir den Artikel an und wenn Du mir sagen kannst, warum er für Dein Problem so interessant ist, dann wird zumindest für mich das Problem auch wieder interessant.

Wohlgemerkt, wenn der Stick an sich Zicken macht (was bei den AVM-Dingern nicht gerade selten ist, trotz ndiswrapper und alles ist wunderbar installiert), dann musst Du jemanden finden, der sich damit herumschlagen will, was mir als Ansatz im Kopf herumschwirrt, kann (und wird wahrscheinlich) funktionieren, aber wenn der Stick selbst rumzickt, dann wird mein einziger Ratschlag sein "kauf Dir bessere, nativ unterstützte Hardware".

Also, lies Dir den Artikel mal durch und versuche zu extrahieren, was man damit auf Dein Problem angewendet wohl machen könnte, ein Satz, der mit "Wenn ich den Stick einstecke, dann könnte man damit ...." wäre das, was in die richtige Richtung geht.

Paulcat
07-Oct-2010, 13:21
Hallo Akoellh,

danke zunächst für Deine Beschäftigung mit meinem Problem trotz "dieses AVM-Schrotts und ndiswrapper". Hier nur ein kurzer Zwischenbericht, nach Anwendung der ersten Erkenntnisse/Möglichkeiten, die mir Dein empfohlener Link zum Ubuntu-Wiki-Kernelmodule gebracht haben.

Habe per "modprobe -r ipw2100" den internen Adapter zunächst mal temporär entfernt. Resultat. Networkmanager auch down. Habe dann den "AVM-Schrott" angeschlossen, NwM kam wieder, und siehe da, der FritzStick funktioniert (die Qualität der Verbindung scheint mir noch nicht optimal trotz gleicher Entfernung zum Router, aber das ist jetzt mal eine andere Baustelle).

Immerhin weiss ich nun zweierlei:
1. Die ndiswrapper-Installation war erfolgreich, mein Problem hat also offenbar nichts mit dem AVM-Stick zu tun, sondern müsste reproduzierbar sein auf jedem Rechner, dem zum internen noch ein externer Device an die Seite gestellt wird (aus welchen Gründen auch immer).
2. Der Grundgedanke, die mangelnde Entkopplung von Interface/IP-Adresse und Netzwerkverbindung bei NwM-Nutzung (i.e die Mehrfachverwendung einer IP-Adresse durch mehrere Adapter) ist für "mein" Problem verantwortlich, scheint mir bestätigt.

Immerhin, die erste Lösung ist geschaffen, noch nicht befriedigend, aber ich bin ja auch erst am Anfang, "Blacklisten, (..) eigene Konfigurationsdatei anlegen oder die 99-local.conf verwenden" stehen ebenso noch aus wie die Lektüre des Artikels zu udev-Regeln. Mal sehen...

Akoellh
07-Oct-2010, 13:44
Vergiss das mit dem Blacklisten, was Du gerade von Hand gebastelt hast, ist der erste Teil zum eleganteren Weg.

Lies den Artikel zu den udev-Regeln und behalte Folgendes im Hinterkopf:

- udev überwacht Hardwareschnittstellen

- udev reagiert auf Ereignisse

- udev-Regeln funktionieren nach dem Prinzip "wenn <Ereignis> ........ dann ... <Aktion>"

Daß Du gleich einen fertigen Regelsatz hinbekommst, ist unwahrscheinlich, aber die entsprechenden Regel(n) als Satz formuliert, solltest Du hinbekommen.

Danach machen wir Nägel mit Köpfen.

Akoellh
07-Oct-2010, 15:02
Daß Du gleich einen fertigen Regelsatz hinbekommst, ist unwahrscheinlich, aber die entsprechenden Regel(n) als Satz formuliert, solltest Du hinbekommen.

Jaja, deutsche Sprache, schwere Sprache.

Etwas unglücklich ausgedrückt, mit "als Satz" formuliert meine ich im Sinne eines "Wenn XYZ passiert..... dann mache ABC...", mit Regelsatz natürlich den entsprechenden Code in "udev-Sprache".

Paulcat
08-Oct-2010, 13:31
Auch wenn ich fürchten muss, dass Dein Interesse erlahmt: Eine Eigenlösung per udev wird wohl noch etwas dauern. Das erste Einlesen klingt in der Tat sehr spannend, aber die Gesamtzusammenhänge in Linux sind mir noch zu fremd, um wirklich zu verstehen. Es wird also etwas dauern. Ursprünglich sollte das Pojekt "mein alter Lappi mit Linux" ein Pflänzchen sein, dass im Immer-mal-wieder-Verfahren in Ruhe zu einem Erkenntnisbaum wachsen kann. Die Kombination von beschränkter Zeit und Menge/Komplexität der Umstellungsprobleme dämpft im Moment etwas.

Die Anforderungsbeschreibung zur Lösung "meines" Problems (das aber wohl doch eines vom NwM ist) wäre klar:
a) wenn ndiswrapper mit fwlan hotplugged oder systemgestartet wird, muss ipw2100 disintegriert werden.
b) wenn der FritzStick unplugged wird, muss das Module ndiswrapper gestoppt und anschließend das Modul ipw2100 neu geladen werden

Meinen ursprünglichen Gedanken, eine eigene IP an der richtigen Stelle (die ich natürlich nicht kenne) zuzuweisen, kann ich wohl vergessen? Wäre ja die einfachste Lösung.

Akoellh
08-Oct-2010, 16:40
Die Anforderungsbeschreibung zur Lösung "meines" Problems (das aber wohl doch eines vom NwM ist) wäre klar:
a) wenn ndiswrapper mit fwlan hotplugged oder systemgestartet wird, muss ipw2100 disintegriert werden.
b) wenn der FritzStick unplugged wird, muss das Module ndiswrapper gestoppt und anschließend das Modul ipw2100 neu geladen werden

Genau so sieht es aus.

Um dies zu verwirklichen, muss man jetzt in Erfahrung bringen, was udev über Deinen WLAN-Stick "weiß".

Allerdings muss man auch sagen, daß udev so extrem vielseitig ist, daß mehrere Wege nach Rom führen und auch, daß man die entsprechenden Regeln entweder sehr exakt auf diesen Stick anpassen kann oder sie auch versuchen könnte sehr breit anzulegen.

Auch die auszuführende Aktion kann man entweder sehr einfach oder auch etwas "intelligenter" gestalten, aber ich schlage vor, wir fangen einfach an und je nach Interesse (auch von Querlesern des Threads, die ich hiermit auffordern möchte, ihre Vorschläge einzubringen, welche "Haken" sie z.B. bei der jeweiligen Lösung sehen) basteln wir uns Stück für Stück eine vielleicht etwas "feinere" Lösung.

Um Informationen über Deinen Stick zu bekommen machst Du nun Folgendes:

- Stick anstecken, warten, bis das Gerät wlan0 vorhanden ist (sollte wlan0 sein, falls wlan1, wlan2 .... den Befehl unten entsprechend anpassen).

- udev "fragen", was er Dir zu diesem Stick "sagen" kann


udevadm info --query=all --attribute-walk --path=/sys/class/net/wlan0Die Ausgabe kannst Du Dir natürlich zuerst mal ansehen und dann postest Du sie hier.



Meinen ursprünglichen Gedanken, eine eigene IP an der richtigen Stelle (die ich natürlich nicht kenne) zuzuweisen, kann ich wohl vergessen? Wäre ja die einfachste Lösung.

Ja, diese Lösung solltest Du vergessen, denn ich muss Dich leider enttäuschen, wenn beide Geräte Adressen aus dem selben Subnetz bekommen würden (was ja Sinn machen würde, damit man sie auch beide je nach Bedarf für Dein Heimnetz verwenden kann) und auch noch gleichzeitig aktiv wären, dann ist Ärger vorprogrammiert und zwar auf jedem OS, denn dieses kann nicht ohne weiteres (z.B. über jeweils eigene Routen mit unterschiedlichen Metriken, das geht aber nicht so einfach bei NWM, mit ifup ginge das schon) entscheiden über welches Interface die Pakete raus und rein sollen und oft genug geht dann gar nichts mehr, aber das nur am Rande bemerkt.

Paulcat
08-Oct-2010, 22:28
Ok, offensichtlich machst Du jetzt "Nägel mit Köpfen". Danke!

Hier die Ausgabe bei co-existierender eth1 (weiss nicht, ob das Einfluss auf´s Ergebnis hat, falls ja, würde ich nochmal die "modprobe -r ipw2100"-Variante machen)


udevadm info --query=all --attribute-walk --path=/sys/class/net/wlan0

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:1d.7/usb1/1-5/1-5:1.0/net/wlan0':
KERNEL=="wlan0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{dev_id}=="0x0"
ATTR{ifalias}==""
ATTR{iflink}=="5"
ATTR{ifindex}=="5"
ATTR{features}=="0x1000"
ATTR{type}=="1"
ATTR{link_mode}=="1"
ATTR{address}=="00:04:0e:ca:28:2c"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{dormant}=="0"
ATTR{operstate}=="up"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="1000"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0':
KERNELS=="1-5:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ndiswrapper"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{modalias}=="usb:v057Cp6201d0100dcFFdscFFdpFFicFFiscFFipFF"
ATTRS{supports_autosuspend}=="0"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-5':
KERNELS=="1-5"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bMaxPower}=="500mA"
ATTRS{urbnum}=="91472"
ATTRS{idVendor}=="057c"
ATTRS{idProduct}=="6201"
ATTRS{bcdDevice}=="0100"
ATTRS{bDeviceClass}=="ff"
ATTRS{bDeviceSubClass}=="ff"
ATTRS{bDeviceProtocol}=="ff"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="4"
ATTRS{devpath}=="5"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="AVM GmbH"
ATTRS{product}=="WLAN USB Device"
ATTRS{serial}=="00040ECA282C"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="81"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="1"
ATTRS{devpath}=="0"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="6"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.34.7-0.3-default ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x24cd"
ATTRS{subsystem_vendor}=="0x0e11"
ATTRS{subsystem_device}=="0x0860"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="5"
ATTRS{local_cpus}=="ffffffff"
ATTRS{local_cpulist}=="0-31"
ATTRS{modalias}=="pci:v00008086d000024CDsv00000E11sd00000860bc0Csc03i20"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
ATTRS{companion}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

Akoellh
09-Oct-2010, 03:33
Dann wollen wir mal.

Zunächst ein paar Erklärungen vorweg, dann werden die Regeln leichter verständlich:

- udev-Regeln funktionieren -wie ich schon anmerkte- nach dem "wenn ... dann"-Prinzip, d.h. man hat zwei Teile in jeder Regel. Der erste Teil setzt eine Reihe von Bedingungen, diese werden der Reihe nach abgearbeitet, nur wenn alle zutreffen, wird/werden am Schluß die gewünschte(n) Aktion(en) ausgeführt.

Stichwort "der Reihe nach"

- udev-Regeln liegen entweder in /lib/udev/rules.d (AFAIK sind das die Regeln, die udev per default schon bei seiner Installation mitbringt) oder in /etc/udev/rules.d (Regeln, die udev automatisch auf das System angepasst -also meist bei der Installation- anlegt, Regeln, die aus Fremdpaketen kommen und Regeln, die der User anlegt sollten auch dahin).

- Dateien, die udev-Regeln enthalten haben folgendes Namensschema

<Zahl>-<irgendein_Dateiname>.rules

und wie man sich denken kann, hat die Zahl eine Bewandnis, denn anhand dieser Zahlen wird entschieden in welcher Reihenfolge die Regeln abgearbeitet werden.

Es ist also nicht nur wichtig, WAS man in eine udev-Regel schreibt, es kann auch durchaus entscheidend für das Funktionieren sein, WANN die Regel abgearbeitet werden.

Im verlinkten Artikel steht, man solle seine eigenen Regeln möglichst früh ausführen lassen, das ist zu einfach und gerade hier sehr wahrscheinlich keine gute Idee, denn ich vermute, daß dann eine andere Regel dafür sorgen könnte, daß das gerade deaktivierte Gerät später wieder aktiviert wird, und genau das will man ja nicht bzw. nur dann, wenn der Stick ausgestöpselt wird.

Als Faustregel würde ich sagen, man sollte seine eigenen Regeln im Zweifelsfall immer zweimal testen, einmal mit einer niedrigen Zahl (z.B. 10) und einmal mit einer sehr hohen Zahl (z.B. 90) als Präfix, es kann dadurch deutliche Unterschiede geben, hier wäre mein erster Tipp eine hohe Zahl, also diese regel sollte ganz am "Ende der Kette" aufgereiht werden.

Mir ist ausserdem noch ein möglicher Haken eingefallen, aber das werden wir dann sehen (und dessen Lösung wäre wahrscheinlich auch einfach).

Wie gesagt, udev arbeitet die Regeln anhand der "Vorzahlen" der Reihe nach ab, das selbe gilt aber auch für die individuellen Teile einer jeden Regel, deshalb sollte man sich auch da ein paar Gedanken machen.

Das wird zwar jetzt dazu führen, daß die nächsten Sätze etwas komisch klingen, dafür werden aber die entsprechenden Regeln in "udev-Sprache" verständlicher.

Folgendes schreibst Du in eine Datei (als root) /etc/udev/rules.d/90-external-wireless.rules (der Name ist nur ein Vorschlag aber die Zahl sollte man übernehmen), wobei es _extrem_ wichtig ist, daß jede der beiden Regeln in jeweils EINER Zeile steht, also keine Zeilenumbrüche in den Regeln sondern nur zwischen ihnen.

Regel 1 sagt Folgendes (nun kommt das schlechte Deutsch, es soll aber der Regel direkt entsprechen, deshalb auch die Kommata, wo nicht immer welche hingehören).

Wenn hinzugefügt, Wenn Gerät aus Unterklasse "Netzwerkgeräte", Wenn Gerät Hersteller-ID "057c", Wenn Geräte-ID "6201", DANN führe aus "/sbin/modprobe -r ipw2100"

In udev-Sprache heisst das (und nun wirst Du sehen, wieso die Ausgabe von udevadm info notwendig war)



ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="/sbin/modprobe -r ipw2100"

Regel 2 sieht fast so aus wie Regel 1, Unterschiede sind "Wenn entfernt" (logisch, oder?) und "Dann führe aus /sbin/modprobe ipw2100" (auch logisch, oder?).


ACTION=="remove", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="/sbin/modprobe ipw2100"

Diese beiden Regeln -ich sags nochmal- in jeweils eine Zeile in eine Datei /etc/udev/rules.d/90-external-wireless.rules abspeichern (als root und man muss sie natürlich noch anlegen, aber wie man einen Texteditor bedient, solltest Du hinbekommen, dazu muss ich jetzt wohl nichts schreiben), anschliessend den Stick abstecken und wieder anstecken und schauen, was passiert.

Dieser Regelsatz hat noch einen potentiellen Haken, wenn sie mit "Abstecken/Anstecken" im laufenden System funktioniert, dann weiß man, daß die "Vorzahl" gut gewählt ist, der nächste Test wäre dann, Kiste mit angestecktem (sic!) Stick booten und nachsehen, ob sie da auch greift.

Dieser Regelsatz sollte so funktionieren, ich habe das auch hier mit meiner Kiste getestet, wenn auch mit anderen Geräten, aber es waren auch eine interne Karte und ein WLAN-Stick, man musste dann eben die "eindeutigen Merkmale" anpassen, das Prinzip ist aber das selbe.

Genau hier ist nun auch der Punkt, wo man mich "ärgern" darf (hier noch einmal die Aufforderung an Querleser, ihr dürft gerne mitmachen) und mir sagen sollte, was die prinzipiellen Schwächen sind bzw. wie man diese Regeln -sowohl auf der "Wenn"- als auch auf der "Dann"-Seite noch verfeinern (oder auch -und das ist der Tipp von mir- "ausweiten") könnte.

Frisch ans Werk.

P.S.

Zum Thema "ärgern":

Ja ich weiß, daß man das auch auf andere Weise lösen könnte (anderes Frontend oder wirklich über ifup, ich selbst nutze auch keinen NWM mehr, sondern ifup mit einer Reihe von "Tweaks", aber der udev-Ansatz löst das ohne extra Software bzw. ohne ifup zu "pimpen" und kann auf viele andere, ähnliche Probleme angewandt werden, deshalb schreibe ich hier solche Romane, als kleine Anregung für Querleser).

Paulcat
09-Oct-2010, 12:05
Hab´s gerade sofort mal getestet, die 1.Regel funktioniert sowohl bei Hotplug als auch bei Systemstart. Sehr schön!

Das Entfernen des Sticks allerdings hat das System destabilisiert, habe den PowerButton zum Ausschalten benutzen müssen. Meine Vermutung ist allerdings, dass dies nicht ein Fehler von Regel 2 ist, , sondern mit der USB-Verwaltung zu tun hat (sprich: auch ohne udev-regel vermutlich Instabilität nach dem Abziehen).

Hier die letzten Messages vor dem roten Knopf:

2010-10-09 19:43:45 linux-x310 kernel [ 1644.766711] usb 1-5: USB disconnect, address 5
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Interface wlan0.IPv4 no longer relevant for mDNS.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Leaving mDNS multicast group on interface wlan0.IPv4 with address xxx.xxx.xxx.xxx.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Withdrawing address record for fe80::xxx on wlan0.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Withdrawing address record for xxx.xxx.xxx.xxx on wlan0.
2010-10-09 19:43:45 linux-x310 ifdown wlan0 name: WLAN USB Device
2010-10-09 19:43:45 linux-x310 kernel [ 1645.024752] ndiswrapper: device wlan0 removed
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025074] BUG: unable to handle kernel NULL pointer dereference at 00000008
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025081] IP: [<c050ed83>] transition_one_qdisc+0x3/0x30
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025094] *pde = 00000000
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025098] Oops: 0000 [#1] SMP
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025102] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5/idProduct
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025107] Modules linked in: usb_storage aes_i586 aes_generic lib80211_crypt_ccmp ip6t_LOG xt_tcpudp xt_pkttype xt_physdev ipt_LOG xt_limit vboxnetadp vboxnetflt vboxdrv af_packet ircomm_tty ircomm rfcomm sco bridge stp llc bnep l2cap snd_pcm_oss snd_mixer_oss snd_seq edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables fuse loop dm_mod ndiswrapper pcmcia smsc_ircc2 ppdev firewire_ohci snd_usb_audio snd_intel8x0m parport_pc snd_intel8x0 snd_hwdep firewire_core uvcvideo snd_usb_lib irda crc_ccitt parport crc_itu_t snd_ac97_codec yenta_socket iTCO_wdt videodev ac97_bus snd_rawmidi video snd_pcm rsrc_nonstatic 8139too sr_mod wbsd ohci1394 cdrom sg 8139cp pcmcia_core ieee1394 lib80211 snd_timer output btusb blue
2010-10-09 19:43:45 linux-x310 kernel tooth container snd_seq_device snd v4l1_compat mmc_core iTCO_vendor_support battery rfkill i2c_i801 joydev pcspkr soundcore serio_raw ac snd_page_alloc shpchp pci_hotplug button ext4 jbd2 crc16 radeon uhci_hcd ttm drm_kms_helper ehci_hcd drm i2c_algo_bit rtc_cmos sd_mod rtc_core rtc_lib i2c_core usbcore intel_agp fan processor ata_generic ata_piix ahci libata scsi_mod thermal thermal_sys hwmon [last unloaded: cfg80211]
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025231]
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025236] Pid: 6, comm: events/0 Tainted: P 2.6.34.7-0.3-default #1 0860/HP compaq nx7000 (DG705T#ABD)
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025241] EIP: 0060:[<c050ed83>] EFLAGS: 00010246 CPU: 0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025245] EIP is at transition_one_qdisc+0x3/0x30
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025248] EAX: 00000000 EBX: e7c52000 ECX: 00000000 EDX: e7c52180
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025252] ESI: 00000006 EDI: 00000000 EBP: f707c0b0 ESP: f7081f14
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025255] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025259] Process events/0 (pid: 6, ti=f7080000 task=f707c0b0 task.ti=f7080000)
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025262] Stack:
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025264] c050f866 c2007fc0 00000000 e7c52000 00000006 c0508f70 c0508c2f f7081f44
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025272] <0> f7081f44 c0508f2d f68b8200 00000000 f7081f44 f7081f44 c2008740 c087bda0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025280] <0> c0508f70 f707c0b0 c0508f88 c025a086 f707c358 02d68c5b 0000017f c08f2fc0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025288] Call Trace:
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025305] [<c050f866>] dev_activate+0x66/0x130
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025315] [<c0508c2f>] linkwatch_do_dev+0x8f/0xb0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025323] [<c0508f2d>] __linkwatch_run_queue+0x15d/0x1a0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025331] [<c0508f88>] linkwatch_event+0x18/0x20
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025339] [<c025a086>] run_workqueue+0x76/0x130
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025346] [<c025a1c3>] worker_thread+0x83/0xe0
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025352] [<c025dcd4>] kthread+0x74/0x80
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025359] [<c02037a6>] kernel_thread_helper+0x6/0x10
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025365] Code: 42 10 00 00 00 00 89 42 04 89 42 08 c7 42 0c 00 00 00 00 83 c2 10 83 f9 03 75 d8 31 c0 5b c3 89 f6 8d bc 27 00 00 00 00 8b 42 0c <f6> 40 08 01 75 05 3e 80 60 4c fb 85 c9 89 42 04 74 14 3d 40 c4
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025406] EIP: [<c050ed83>] transition_one_qdisc+0x3/0x30 SS:ESP 0068:f7081f14
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025412] CR2: 0000000000000008
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025417] ---[ end trace 3d9bca1586b77067 ]---
2010-10-09 19:46:45 linux-x310 udevd[449] worker [7051] unexpectedly returned with status 0x0100
2010-10-09 19:46:45 linux-x310 udevd[449] worker [7051] failed while handling '/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/net/wlan0'
2010-10-09 19:47:26 linux-x310 smartd[2601] Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 139 to 127


Käme eine ergänzende udev-Regel zum sicheren Entfernen des USB in Frage?

Dir einen schönen Samstag Abend!

Akoellh
09-Oct-2010, 12:39
Das Entfernen des Sticks allerdings hat das System destabilisiert, habe den PowerButton zum Ausschalten benutzen müssen. Meine Vermutung ist allerdings, dass dies nicht ein Fehler von Regel 2 ist, , sondern mit der USB-Verwaltung zu tun hat (sprich: auch ohne udev-regel vermutlich Instabilität nach dem Abziehen).

Ich vermute mal eher etwas Anderes, schau mal genau hin, was die letzte Meldung ist, bevor der Kernel "Schluckauf" bekommt.


2010-10-09 19:43:45 linux-x310 kernel [ 1644.766711] usb 1-5: USB disconnect, address 5
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Interface wlan0.IPv4 no longer relevant for mDNS.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Leaving mDNS multicast group on interface wlan0.IPv4 with address xxx.xxx.xxx.xxx.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Withdrawing address record for fe80::xxx on wlan0.
2010-10-09 19:43:45 linux-x310 avahi-daemon[1843] Withdrawing address record for xxx.xxx.xxx.xxx on wlan0.
2010-10-09 19:43:45 linux-x310 ifdown wlan0 name: WLAN USB Device bis hierhin alles fein und dann


2010-10-09 19:43:45 linux-x310 kernel [ 1645.024752] ndiswrapper: device wlan0 removed
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025074] BUG: unable to handle kernel NULL pointer dereference at 00000008
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025081] IP: [<c050ed83>] transition_one_qdisc+0x3/0x30
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025094] *pde = 00000000
2010-10-09 19:43:45 linux-x310 kernel [ 1645.025098] Oops: 0000 [#1] SMP
Der Verdacht liegt nahe, daß ndiswrapper+AVM-Stick die Schuldigen sind, wäre nur ein weiteres Ärgernis dieser Art, Haken an der Sache, das wird Dir kein Kernelentwickler als Bugreport annehmen, da ndiswrapper zwar Open Source ist, aber eben nicht der proprietäre Windowstreiber, der da durch ndiswrapper Zugriff auf den Kern bekommt.

Warum dieser Verdacht?

Nun, ganz einfach, ich hatte dieses Problem auf meinem "Testgelände" beim Abziehen meines WLAN-Sticks nicht, dieser verwendet aber einen freien Treiber, der im Kernel schon drin ist.



Käme eine ergänzende udev-Regel zum sicheren Entfernen des USB in Frage?


Ehrlicherweise habe ich zunächst mal keine wirklich gute Idee bzw. nur eine und bin eher wenig optimistisch, daß das helfen wird.

Allerdings führt das nun auf einem kleinen Umweg zum nächsten Schritt, wie man das Ganze etwas "feiner" auf der Seite der durchzuführenden Aktion gestalten kann, zumindest einen Versuch ist es Wert, ob allerdings die Regel "schnell genug" ist, weiß ich nicht.

Zuerst die Erklärung, die allgemein gilt:

Die Aktionen "RUN" bzw. "PROGRAM" bei udev-Regeln können nur einen Befehl (das wäre das "/sbin/modprobe") und dazu gehörende Argumente (also das "iwp2100") ausführen, das hier würde also _nicht_ funktionieren:


RUN+="/sbin/modprobe -r ndiswrapper ; /sbin/modprobe ipw2100"

Aber das kann man _natürlich_ auch lösen, wenn man als diesen einen Befehl ein Skript verwendet, welches dann problemlos mehrere Befehle enthalten darf.

Also modeln wir jetzt die zweite Regel um:


ACTION=="remove", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="/lib/udev/remove_ndiswrapper_load_ipw2100.sh"Und damit da auch was passiert brauchen wir natürlich das Script "/lib/udev/remove_ndiswrapper_load_ipw2100.sh", welches (wie vorher die Regeln) als root mit einem Texteditor angelegt werden muss und folgenden Inhalt hat:


#!/bin/sh
/sbin/modprobe -r ndiswrapper
/sbin/modprobe ipw2100
exit 0

Zwei Dinge sind zu beachten:

1. Der Pfad /lib/udev/ ist absichtlich so gewählt, denn dort liegen all die anderen "Helferprogramme" von udev, es müsste sogar funktionieren, daß man dann nur das hier schreibt


ACTION=="remove", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="remove_ndiswrapper_load_ipw2100.sh"denn der "Standardpfad", in welchem udev nach Programmen/Scripten sucht, ist eben /lib/udev/, aber im Zweifelsfall klappt es mit dem absoluten Pfad immer und 100%ig.

2. Die Scriptdatei muss ausführbar sein, also am einfachsten als root (!) nach dem Anlegen der Datei /lib/udev/remove_ndiswrapper_load_ipw2100.sh folgenden Befehl ausführen.


chmod 700 /lib/udev/remove_ndiswrapper_load_ipw2100.shWas das Script macht, sollte Dir klar sein, ob es wirklich hilft, wage ich allerdings zu bezweifeln, aber zumindest weißt Du jetzt, warum ich von "AVM-Schrott mit ndiswrapper" geschrieben habe. Es ist nicht so, daß freie Treiber keine solchen Probleme haben können, das kommt auch vor, aber da hat man wenigstens die Möglichkeit eines Bugreports und die Kernelentwickler können das Problem beheben, bei ndiswrapper + Closed Source Windowstreiber können sie es nicht, selbst wenn sie es wollten.

Paulcat
11-Oct-2010, 05:00
Hallo Akoellh,

die Kombination von udev plus scripts ist schon sehr spannend. Was mir natürlich immer noch fehlt, ist ein Grundverständnis der Abläufe bei Linux, vielleicht hast Du da einen guten Link zum Einlesen (welcher Prozess startet wann und fragt welche Konfigurationsdateien oder Treiber in welchem Verzeichnis ab) .

Im Konkreten wächst und gedeiht die Sache dank Deiner Hilfe. Kurzer Zwischenstand: remove_ndiswrapper_load_ipw2100.sh funktioniert, wenn per Konsolenbefehl eingegeben, im ersten Versuch blendend, wenn auch nur mit kompletten Pfad, ist aber wohl nebensächlich. Sprich wlan0 ist raus, NwM kennt dann nur noch die eth1, und die hat Verbindung! Sehr schön!

Allerdings geht´s nur so, der unvorbereitete Abzug des Sticks destabilisiert nach wie vor. Auch udev-Regel-1 greift nicht mehr, wenn nach (vorbereitetem) Abzug der Stick erneut gesteckt wird. Man könnte nun pragmatisch sein und mit dem Erreichten leben, aber nun ist doch durch meine neuerworbenen Kenntnisse die Neugier geweckt.

Bei der Fehlersuche fokussiere ich im Moment auf 3 Punkte:
a) die Rangordnung der udev-regel. Es gibt noch eine nachfolgende (99-iwlwifi-led.rules: SUBSYSTEM=="leds", ACTION=="add", KERNEL=="iwl-phy*:assoc", RUN+="/lib/udev/iwlwifi-led.sh"), iwlwifi-led klingt nach led-support und scheint mir deshalb eher weniger wichtig.
b) eine Start-Fehlermeldung von ndiswrapper, die vielleicht Hinweise für die Probs beim Entladen gibt:
linux-x310 kernel [ 456.480220] ndiswrapper (iw_set_auth:1602): invalid cmd 12
c) eine spezielle Eigenschaft des Fritz-Sticks. Er wird zunächst als virtuelles CD-Rom eingebunden und startet dann ein autorun (self_install), dass vermutlich der Verbindungseinstellung unter Windows dient. Erst danach kommt das eigentlich wlan-Modul zum Zug. Ich vermute, dass beim Abziehen davon noch Teile aktiv sind

Hier mal das Ergebnis bei hotplug:


2010-10-11 08:46:01 linux-x310 kernel [ 1882.216085] usb 1-5: new high speed USB device using ehci_hcd and address 4
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348980] usb 1-5: New USB device found, idVendor=057c, idProduct=62ff
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348987] usb 1-5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348991] usb 1-5: Product: WLAN USB Device
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348994] usb 1-5: Manufacturer: AVM GmbH
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348996] usb 1-5: SerialNumber: 00040ECA282C
2010-10-11 08:46:02 linux-x310 kernel [ 1883.700587] Initializing USB Mass Storage driver...
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702420] scsi2 : usb-storage 1-5:1.0
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702767] usbcore: registered new interface driver usb-storage
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702773] USB Mass Storage support registered.
2010-10-11 08:46:03 linux-x310 kernel [ 1884.720085] scsi 2:0:0:0: CD-ROM FRITZ! WLAN selfinstall 1.00 PQ: 0 ANSI: 0 CCS
2010-10-11 08:46:03 linux-x310 kernel [ 1884.731993] sr1: scsi3-mmc drive: 52x/52x cd/rw xa/form2 cdda tray
2010-10-11 08:46:03 linux-x310 kernel [ 1884.732253] sr 2:0:0:0: Attached scsi CD-ROM sr1
2010-10-11 08:46:03 linux-x310 kernel [ 1884.732432] sr 2:0:0:0: Attached scsi generic sg2 type 5
2010-10-11 08:46:05 linux-x310 hald mounted /dev/sr1 on behalf of uid 1000
2010-10-11 08:46:28 linux-x310 kernel [ 1909.720378] usb 1-5: USB disconnect, address 4
2010-10-11 08:46:28 linux-x310 hald[1584] forcibly attempting to lazy unmount /dev/sr1 as enclosing drive was disconnected
2010-10-11 08:46:28 linux-x310 kernel [ 1909.833371] scsi 2:0:0:0: rejecting I/O to dead device
2010-10-11 08:46:28 linux-x310 hald unmounted /dev/sr1 from '/media/FRITZ!WLAN USB Stick selfinstall-2' on behalf of uid 0
2010-10-11 08:46:29 linux-x310 kernel [ 1910.960075] usb 1-5: new high speed USB device using ehci_hcd and address 5
2010-10-11 08:46:29 linux-x310 kernel [ 1911.093467] usb 1-5: New USB device found, idVendor=057c, idProduct=6201
2010-10-11 08:46:29 linux-x310 kernel [ 1911.093473] usb 1-5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
2010-10-11 08:46:29 linux-x310 kernel [ 1911.093477] usb 1-5: Product: WLAN USB Device
2010-10-11 08:46:29 linux-x310 kernel [ 1911.093480] usb 1-5: Manufacturer: AVM GmbH
2010-10-11 08:46:29 linux-x310 kernel [ 1911.093482] usb 1-5: SerialNumber: 00040ECA282C
2010-10-11 08:46:30 linux-x310 kernel [ 1911.220063] usb 1-5: reset high speed USB device using ehci_hcd and address 5
2010-10-11 08:46:30 linux-x310 kernel [ 1911.450345] ndiswrapper: driver fwlan (AVM GmbH,12/28/2006,2.0.6.1647) loaded
2010-10-11 08:46:30 linux-x310 kernel [ 1912.101310] wlan0: ethernet device 00:04:0e:ca:28:2c using NDIS driver: fwlan, version: 0x2000c6f, NDIS version: 0x501, vendor: 'AVM FRITZ!WLAN USB Stick', 057C:6201.F.conf
2010-10-11 08:46:30 linux-x310 kernel [ 1912.101348] wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
2010-10-11 08:46:31 linux-x310 ifup Service network not started and mode 'auto' -> skipping
2010-10-11 08:46:31 linux-x310 avahi-daemon[1858] Interface eth1.IPv4 no longer relevant for mDNS.
2010-10-11 08:46:31 linux-x310 avahi-daemon[1858] Leaving mDNS multicast group on interface eth1.IPv4 with address xx.xx.xx.xx..
2010-10-11 08:46:31 linux-x310 avahi-daemon[1858] Withdrawing address record for xx.xx.xx.xx on eth1.
2010-10-11 08:46:31 linux-x310 kernel [ 1913.143634] ipw2100 0000:02:02.0: PCI INT A disabled
2010-10-11 08:46:32 linux-x310 kernel [ 1913.177122] ADDRCONF(NETDEV_UP): wlan0: link is not ready
2010-10-11 08:46:32 linux-x310 ifdown eth1 name: PRO/Wireless LAN 2100 3B Mini PCI Adapter
2010-10-11 08:46:34 linux-x310 dhcpcd[5380] eth1: dhcpcd not running
2010-10-11 08:46:34 linux-x310 dhcpcd[5380] eth1: exiting
2010-10-11 08:46:34 linux-x310 dhclient Bound to *:546
2010-10-11 08:46:34 linux-x310 dhclient Error getting hardware address for "eth1": No such device
2010-10-11 08:46:34 linux-x310 dhclient
2010-10-11 08:46:34 linux-x310 dhclient If you did not get this software from ftp.isc.org, please
2010-10-11 08:46:34 linux-x310 dhclient get the latest from ftp.isc.org and install that before
2010-10-11 08:46:34 linux-x310 dhclient requesting help.
2010-10-11 08:46:34 linux-x310 dhclient
2010-10-11 08:46:34 linux-x310 dhclient If you did get this software from ftp.isc.org and have not
2010-10-11 08:46:34 linux-x310 dhclient yet read the README, please read it before requesting help.
2010-10-11 08:46:34 linux-x310 dhclient If you intend to request help from the dhcp-server@isc.org
2010-10-11 08:46:34 linux-x310 dhclient mailing list, please read the section on the README about
2010-10-11 08:46:34 linux-x310 dhclient submitting bug reports and requests for help.
2010-10-11 08:46:34 linux-x310 dhclient
2010-10-11 08:46:34 linux-x310 dhclient Please do not under any circumstances send requests for
2010-10-11 08:46:34 linux-x310 dhclient help directly to the authors of this software - please
2010-10-11 08:46:34 linux-x310 dhclient send them to the appropriate mailing list as described in
2010-10-11 08:46:34 linux-x310 dhclient the README file.
2010-10-11 08:46:34 linux-x310 dhclient
2010-10-11 08:46:34 linux-x310 dhclient exiting.
2010-10-11 08:46:43 linux-x310 kernel [ 1924.230660] ndiswrapper (iw_set_auth:1602): invalid cmd 12
2010-10-11 08:46:43 linux-x310 kernel [ 1924.835868] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
2010-10-11 08:46:43 linux-x310 avahi-daemon[1858] Joining mDNS multicast group on interface wlan0.IPv4 with address xx.xx.xx.xx.
2010-10-11 08:46:43 linux-x310 avahi-daemon[1858] New relevant interface wlan0.IPv4 for mDNS.
2010-10-11 08:46:43 linux-x310 avahi-daemon[1858] Registering new address record for xx.xx.xx.xx on wlan0.IPv4.
2010-10-11 08:46:45 linux-x310 nmbd[4219] [2010/10/11 08:46:45.688669, 0] nmbd/nmbd.c:71(terminate)
2010-10-11 08:46:45 linux-x310 nmbd[4219] Got SIGTERM: going down...
2010-10-11 08:46:46 linux-x310 SuSEfirewall2 Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
2010-10-11 08:46:46 linux-x310 SuSEfirewall2 using default zone 'ext' for interface irda0
2010-10-11 08:46:46 linux-x310 SuSEfirewall2 using default zone 'ext' for interface pan0
2010-10-11 08:46:46 linux-x310 SuSEfirewall2 using default zone 'ext' for interface vboxnet0
2010-10-11 08:46:46 linux-x310 SuSEfirewall2 using default zone 'ext' for interface wlan0
2010-10-11 08:46:47 linux-x310 SuSEfirewall2 batch committing...
2010-10-11 08:46:47 linux-x310 SuSEfirewall2 Firewall rules successfully set


Könnte meine Vermutung in die richtige Richtung gehen?

Schöne Grüße,
Paulcat

Akoellh
11-Oct-2010, 06:13
die Kombination von udev plus scripts ist schon sehr spannend. Was mir natürlich immer noch fehlt, ist ein Grundverständnis der Abläufe bei Linux, vielleicht hast Du da einen guten Link zum Einlesen (welcher Prozess startet wann und fragt welche Konfigurationsdateien oder Treiber in welchem Verzeichnis ab) .

Au weia, das ist etwas viel verlangt, denn einen einzigen Link dieser Art gibt es kaum, dazu ist es viel zu viel und viel zu komplex.



Im Konkreten wächst und gedeiht die Sache dank Deiner Hilfe. Kurzer Zwischenstand: remove_ndiswrapper_load_ipw2100.sh funktioniert, wenn per Konsolenbefehl eingegeben, im ersten Versuch blendend, wenn auch nur mit kompletten Pfad, ist aber wohl nebensächlich.

Nein, nebensächlich zum Verständnis ist es nicht, denn wenn man das von Hand aufruft, ist hier der komplette Pfad notwendig.

Ich kann Dir natürlich einen kleinen Tipp fürs Selbststudium geben, suche mit der Suchmaschine Deines geringsten Mißtrauens nach der Bedeutung der Umgebungsvariable "$PATH" unter Linux/Unix, die Ausgabe von "echo $PATH" könnte Dir auch einen Hinweis geben.



Sprich wlan0 ist raus, NwM kennt dann nur noch die eth1, und die hat Verbindung! Sehr schön!

Allerdings geht´s nur so, der unvorbereitete Abzug des Sticks destabilisiert nach wie vor.

Ich war ja skeptisch, hat sich dann wohl bestätigt, daß das einfache "Herausrupfen" von ndiswrapper aus dem Kernel nicht reicht bzw. nicht schnell genug ist.


Auch udev-Regel-1 greift nicht mehr, wenn nach (vorbereitetem) Abzug der Stick erneut gesteckt wird.

Zumindest das lässt sich -überraschenderweise :-)- auch mit udev lösen, vermutlich wird das Laden nicht automatisch getriggert sondern an anderer Stelle für das Laden von ndiswrapper gesorgt (Eintrag in "MODULES_LOADED_AT_BOOT"?).

Ich gebe Dir auch hier nur einen kleinen Tipp, was Du zuletzt mit "Regel Nr.2" gemacht hast, kannst Du auch analog mit "Regel Nr.1" tun, das Script könnte man dann "/lib/udev/remove_ipw2100_load_ndiswrapper.sh" nennen und den Inhalt darfst Du Dir jetzt mal selbst überlegen, es ist eigentlich ganz einfach, wenn man sich das andere Script anschaut.


Man könnte nun pragmatisch sein und mit dem Erreichten leben, aber nun ist doch durch meine neuerworbenen Kenntnisse die Neugier geweckt.

Deshalb auch nur der Tipp für das "Ummodeln" von "Regel Nr.1", mit etwas gesunder Neugierde und der schon existierenden Vorlage "Regel Nr.2" und dem Script "/lib/udev/remove_ndiswrapper_load_ipw2100.sh" sollte das kein Problem für Dich sein.



Bei der Fehlersuche fokussiere ich im Moment auf 3 Punkte:
a) die Rangordnung der udev-regel. Es gibt noch eine nachfolgende (99-iwlwifi-led.rules: SUBSYSTEM=="leds", ACTION=="add", KERNEL=="iwl-phy*:assoc", RUN+="/lib/udev/iwlwifi-led.sh"), iwlwifi-led klingt nach led-support und scheint mir deshalb eher weniger wichtig.

Richtig, kannst Du ignorieren, hauptsächlich aus einem anderen Grund, sie betrifft nur eine bestimmte Klasse von Geräten, in welche Deine interne Karte nicht gehört, allerdings bist Du gar nicht so auf dem Holzweg gewesen, denn es sind die Nachfolger Deiner Karte, neuere Intel WLAN-Karten (ich habe so ein Ding und da ist diese Regel wichtig).



b) eine Start-Fehlermeldung von ndiswrapper, die vielleicht Hinweise für die Probs beim Entladen gibt:
linux-x310 kernel [ 456.480220] ndiswrapper (iw_set_auth:1602): invalid cmd 12

Halte ich eher für unwahrscheinlich, denn es geht um eine Meldung beim Start von ndiswrapper und für mich sieht es eher so aus, daß ndiswrapper da ein Kommando versucht, welches aber der Windowstreiber nicht kennt. Das ist aber nur geraten, wie gesagt, gerade AVM und ndiswrapper fasse ich eigentlich nicht mal mit einer Kneifzange an, einzig die Tatsache, daß es hier um etwas geht, was man auch auf beliebige andere Kombinationen aus interner und externer WLAN-Karte anwenden kann und die Fähigkeiten von udev aufzeigt, macht diesen Thread für mich interessant.



c) eine spezielle Eigenschaft des Fritz-Sticks. Er wird zunächst als virtuelles CD-Rom eingebunden und startet dann ein autorun (self_install), dass vermutlich der Verbindungseinstellung unter Windows dient. Erst danach kommt das eigentlich wlan-Modul zum Zug. Ich vermute, dass beim Abziehen davon noch Teile aktiv sind


Na das ist doch dann wieder etwas, was mich interessiert und sehr schön ins Bild passt, denn auch hier kann man etwas mit udev basteln (Surprise, Surprise).

Dazu steht auch etwas im verlinkten Thread "writing udev rules", ich zitiere das mal hier.


Additional options

Another assignment which can prove useful is the OPTIONS list. A few options are available:
all_partitions - create all possible partitions for a block device, rather than only those that were initially detected
ignore_device - ignore the event completely
last_rule - ensure that no later rules have any effect

Besonders das "ignore_device" ist hier möglicherweise der Schlüssel, das "last_rule" kann die Sache "wasserdicht" machen oder aber auch -und das ist der Haken, man muss es ausprobieren- dazu führen, daß der Stick dann gar nicht mehr als WLAN-Gerät erkannt wird. Das sollte eigentlich nicht passieren, aber "Versuch macht kluch".



Hier mal das Ergebnis bei hotplug:


2010-10-11 08:46:01 linux-x310 kernel [ 1882.216085] usb 1-5: new high speed USB device using ehci_hcd and address 4
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348980] usb 1-5: New USB device found, idVendor=057c, idProduct=62ff
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348987] usb 1-5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348991] usb 1-5: Product: WLAN USB Device
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348994] usb 1-5: Manufacturer: AVM GmbH
2010-10-11 08:46:01 linux-x310 kernel [ 1882.348996] usb 1-5: SerialNumber: 00040ECA282C
2010-10-11 08:46:02 linux-x310 kernel [ 1883.700587] Initializing USB Mass Storage driver...
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702420] scsi2 : usb-storage 1-5:1.0
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702767] usbcore: registered new interface driver usb-storage
2010-10-11 08:46:02 linux-x310 kernel [ 1883.702773] USB Mass Storage support registered.
2010-10-11 08:46:03 linux-x310 kernel [ 1884.720085] scsi 2:0:0:0: CD-ROM FRITZ! WLAN selfinstall 1.00 PQ: 0 ANSI: 0 CCS
2010-10-11 08:46:03 linux-x310 kernel [ 1884.731993] sr1: scsi3-mmc drive: 52x/52x cd/rw xa/form2 cdda tray
2010-10-11 08:46:03 linux-x310 kernel [ 1884.732253] sr 2:0:0:0: Attached scsi CD-ROM sr1
2010-10-11 08:46:03 linux-x310 kernel [ 1884.732432] sr 2:0:0:0: Attached scsi generic sg2 type 5
2010-10-11 08:46:05 linux-x310 hald mounted /dev/sr1 on behalf of uid 1000
2010-10-11 08:46:28 linux-x310 kernel [ 1909.720378] usb 1-5: USB disconnect, address 4
2010-10-11 08:46:28 linux-x310 hald[1584] forcibly attempting to lazy unmount /dev/sr1 as enclosing drive was disconnected
2010-10-11 08:46:28 linux-x310 kernel [ 1909.833371] scsi 2:0:0:0: rejecting I/O to dead device
2010-10-11 08:46:28 linux-x310 hald unmounted /dev/sr1 from '/media/FRITZ!WLAN USB Stick selfinstall-2' on behalf of uid 0Ich habe mal ein paar Dinge kopiert, absichtlich auch etwas, was zunächst hilfreich sein könnte, später aber gewisses "Bumerangpotentiel" hat, das gilt übrigens auch für die schon geschriebenen Regeln, dazu kommen wir dann später.

Wieder gilt, bevor man eine Regel für eine neues Gerät schreibt (also hier jetzt dieses virtuelle CDROM), sollte man udev befragen, was er darüber weiß.

Also Stick anstecken, kurz warten und udev "fragen".

Vorhin haben wir udevadm info über den Pfad in /sys/ aufgerufen, das ginge hier auch (wenn man den passenden Pfad findet), aber hier geht es auch einfacher, denn -im Gegensatz zu Netzwerkgeräten- hat man ein Devicefile unter /dev/.

Ein kurzer Blick in die Optionen von udevadm info


udevadm info --help
Usage: udevadm info OPTIONS
--query=<type> query device information:
name name of device node
symlink pointing to node
path sys device path
property the device properties
all all values
--path=<syspath> sys device path used for query or attribute walk
--name=<name> node or symlink name used for query or attribute walk
--root prepend dev directory to path names
--attribute-walk print all key matches while walking along the chain
of parent devices
--device-id-of-file=<file> print major:minor of device containing this file
--export-db export the content of the udev database
--help

sagt uns also, daß folgender Befehl sinnvoll sein dürfte:


udevadm info --query=all --attribute-walk --name=/dev/sr1Du kannst/solltest Dir die Ausgabe genau ansehen, wenn Du genügend Ehrgeiz hast, darfst Du mir ja ein paar Vorschläge machen, wie man für diese Regel das Gerät eindeutig "festnageln" kann.

Wie gesagt, ob das wirklich hilft das Stabilitätsproblem beim Abziehen des Sticks zu lösen, kann ich nicht sagen, da es mir aber um "was kann man mit udev so alles anstellen" geht, hast Du die Möglichkeit ein paar Dinge auszuprobieren, die Dir vielleicht helfen, wenn es allerdings doch an der "zickigen Hardware" in Verbindung mit der "Krücke"*** ndiswrapper liegt, dann kann ich Dir nicht weiter helfen.

Was man speziell mit diesem Gerät noch alles auf anderer Ebene als "Troubleshooting" versuchen kann, wird hier zusammengefasst, aber wie gesagt, nicht meine Baustelle, ich kümmere mich um die "Abteilung udev".

WLAN/Karten/AVM (http://wiki.ubuntuusers.de/WLAN/Karten/AVM)

bzw.

FRITZ!WLAN USB Stick (http://wiki.ubuntuusers.de/FRITZ!WLAN_USB_Stick)

***
P.S.
Ja, ndiswrapper ist eine Krücke, genau so wie z.B. wine eine ist, damit will ich diese Projekte NICHT abwerten, im Gegenteil, denn was sie tun müssen um überhaupt von Nutzen sein zu können, ist sehr komplex und aller Ehren wert.

Paulcat
11-Oct-2010, 11:01
Zwischenfrage: Die bisherige udev-Regel enthält im konditionalen Teil nur Bezug auf ACTIONs "add" oder "remove" des SUBSYSTEMs "net" bzw. von KERNEL "wlan0". was ist mit den Parent devices, die udevadm info meldet, also:

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0':
KERNELS=="1-5:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="ndiswrapper"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{modalias}=="usb:v057Cp6201d0100dcFFdscFFdpFFicFFiscFFipFF"
ATTRS{supports_autosuspend}=="0"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-5':
KERNELS=="1-5"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bMaxPower}=="500mA"
ATTRS{urbnum}=="91472"
ATTRS{idVendor}=="057c"
ATTRS{idProduct}=="6201"
ATTRS{bcdDevice}=="0100"
ATTRS{bDeviceClass}=="ff"
ATTRS{bDeviceSubClass}=="ff"
ATTRS{bDeviceProtocol}=="ff"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="4"
ATTRS{devpath}=="5"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="AVM GmbH"
ATTRS{product}=="WLAN USB Device"
ATTRS{serial}=="00040ECA282C"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1':
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="81"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="1"
ATTRS{devnum}=="1"
ATTRS{devpath}=="0"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="6"
ATTRS{quirks}=="0x0"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.34.7-0.3-default ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x24cd"
ATTRS{subsystem_vendor}=="0x0e11"
ATTRS{subsystem_device}=="0x0860"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="5"
ATTRS{local_cpus}=="ffffffff"
ATTRS{local_cpulist}=="0-31"
ATTRS{modalias}=="pci:v00008086d000024CDsv00000E11sd00000860bc0Csc03i20"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
ATTRS{companion}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

Werden für sie nicht eigene udev-Regeln benötigt?

Paulcat
11-Oct-2010, 11:34
Korrigiere meine Frage, offensichtlich dient der erste Teil nur der präzisen Identifikation.

Was ist mit dem modprobe-r? Werden dadurch die vom Modul verwendeten usb/pci-Subsysteme mit freigegeben?

Akoellh
11-Oct-2010, 11:37
Nein, die Regeln beziehen sich immer auf ein bestimmtes device, man kann aber -manchmal, nicht immer- Eigenschaften eines parent devices mit zur Identifizierung eines anderen Gerätes benutzen, allerdings kann das auch schiefgehen.

Das ist nicht so in einem Satz zu erklären, diese "parent devices" sind deshalb vorhanden, weil man sich meist das "Ende der Fahnenstange" anschaut, also hier z.B. das drahtlose Netzwerkgerät "wlan0", welches der Kernel anlegt und womit man nun z.B. Ethernet "sprechen" kann.

Damit es dieses gibt, müssen aber noch andere Geräte existieren, z.B. das physikalisch wirklich vorhandene WLAN-Gerät, das hängt wiederum an einem USB-Anschluss, dieser an einem USB-Controller usw. usf. etc. pp.

Das "--attribute-walk" macht genau das, was in der "--help"-Ausgabe steht:


--attribute-walk print all key matches while walking along the chain of parent deviceses "hangelt" sich an den "Geräten" entlang, egal ob diese nun physikalisch vorhanden oder nur virtuell sind.

Die Regeln beginnen mit ACTION (was wird getan?) und dann folgen mehrere Bedingungen um genau einzugrenzen für welches Gerät die am Ende stehende Aktion ausgeführt werden soll.

Genau genommen, sind die Regeln auf der Seite der Bedingungen sogar etwas "Overkill", es würden z.B. nur die beiden Attribute "Hersteller-ID" und "Geräte-ID" ausreichen, aber das ist schon fast ein wenig eine Geschmacksfrage, wie genau man es damit nimmt.

Die Regeln haben nämlich bisher noch einen Haken aber scheinbar will mich hier niemand ärgern, dann mache ich es jetzt mal selbst.

Was, wenn man noch einen weiteren "einstöpselbaren" WLAN-Adapter (USB oder PCMCIA-Karte) hat, den man z.B. auch nutzen will und wo man das selbe Problem mit der internen Karte bekommen könnte?

Für jeden eine eigene Regel schreiben? Würde gehen, ist aber etwas umständlich, oder?

Paulcat
11-Oct-2010, 12:01
Da haben wir uns wohl gerade überschnitten...

Paulcat
11-Oct-2010, 13:12
Letzter Stand der Dinge, noch ohne OPTIONS:

/etc/udev/rules.d/90-FritzStick.rules

ACTION=="add", SUBSYSTEM=="block", KERNEL=="sr1", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="62ff", RUN+="/sbin/modprobe -r sr1"
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="/lib/udev/FritzStick_1_remove_ipw2100_load_ndiswrapper.sh"
ACTION=="remove", SUBSYSTEM=="net", KERNEL=="wlan0", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="6201", RUN+="/lib/udev/FritzStick_2_remove_ndiswrapper_load_ipw2100.sh"

/lib/udev/FritzStick_1_remove_ipw2100_load_ndiswrapper.sh

#!/bin/sh
/sbin/modprobe -r ipw2100
/sbin/modprobe ndiswrapper
exit 0

FritzStick_2_remove_ndiswrapper_load_ipw2100.sh

#!/bin/sh
/sbin/modprobe -r ndiswrapper
/sbin/modprobe ipw2100
exit 0

Akoellh
11-Oct-2010, 16:44
Die beiden Scripte sind OK so, aber diese Regel hat einen Fehler:


ACTION=="add", SUBSYSTEM=="block", KERNEL=="sr1", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="62ff", RUN+="/sbin/modprobe -r sr1"Der Ansatz ist so gesehen OK, aber es gibt kein Kernelmodul "sr1", das ist in diesem Fall der Name des Gerätes (sog. "device node").

Des Weiteren ist die Regel auf der "Wenn"-Seite so OK, aber stell Dir vor, es wäre noch ein weiteres CDROM-Laufwerk vorhanden, das könnte ein weiterer USB-Stick sein, der ebenfalls ein virtuelles CDROM enthält (wie z.B. diverse Surfsticks oder auch ein USB-Massenspeicher, da sind teilweise solche virtuellen CDROM-Laufwerke drauf), dann könnte dieses (je nach Reihenfolge des Anstöpselns) /dev/sr1 heissen (/dev/sr0 ist das eingebaute CD-Laufwerk) und der Fritz-Stick wäre z.B. /dev/sr2, dann greift die Regel so nicht mehr.

Deshalb würde es Sinn machen, die "Wenn-Seite" mit einem Platzhalter zu versehen, also so:


ACTION=="add", SUBSYSTEM=="block", KERNEL=="sr*", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="62ff",Als Aktion soll das Gerät ignoriert werden und es sollen keine weiteren Regeln mehr zu diesem Gerät abgearbeitet werden.

Also zusammengefasst:


ACTION=="add", SUBSYSTEM=="block", KERNEL=="sr*", ATTRS{idVendor}=="057c", ATTRS{idProduct}=="62ff", OPTIONS+="ignore_device", OPTIONS+="last_rule"Damit wird dieses virtuelle CDROM zwar erkannt (daran kann man udev nicht hindern, würde auch keinen Sinn machen, denn udev muss ja wissen, was er damit zu tun hat), aber anschließend wird udev dafür sorgen, daß im System dieses Gerät nicht mehr vorhanden ist.

Wenn also dieses virtuelle CDROM-Laufwerk der Störenfried ist, welcher beim Herausziehen des Sticks dafür sorgt, daß ndiswrapper nicht schnell genug entladen werden kann, dann hätte man das verhindert, weil es nun dieses Gerät nicht mehr gibt.

Es war übrigens eine gute Idee hier auch "KERNEL=="sr*" zu setzen, dazu ein Beispiel aus meiner Hardwaresammlung.

Ich bin hier gerade über einen UMTS-Stick online, der auch so ein -unter Linux nutzloses- virtuelles CDROM-Laufwerk hat, allerdings ist zusätzlich auch ein Steckplatz für eine SD-Karte vorhanden.

Je nachdem, ob vorher schon einer meiner USB-Speichersticks angeschlossen ist, wird der Steckplatz für die SD-Karte als sdb, sdc usw. erkannt, das virtuelle CDROM als sr1.

Das dazugehörige "parent device" (der Surfstick) hat die USB-ID 12d1:1003, diese Regel würde beide Speichermedien "ausknipsen",


ACTION=="add", SUBSYSTEM=="block", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", OPTIONS+="ignore_device", OPTIONS+="last_rule"denn es passt auf das CDROM und den Steckplatz für die SD-Karte (beides sind blockorientierte Geräte).

Sollte ich eines Tages eine SD-Karte in dem Stick "versenken", gäbe es eine böse Überraschung, denn ich könnte damit nichts anfangen, deshalb sieht meine Regel so aus:


ACTION=="add", SUBSYSTEM=="block", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", KERNEL=="sr*", OPTIONS+="ignore_device", OPTIONS+="last_rule"

buckesfeld
13-Oct-2010, 05:58
Alles äußerst interessant und gut erklärt, den Thread hab ich gebookmarked.
Aber kann es sein, dass wicd als Network Manager ebenfalls eine Lösung wäre? Der kann IIRC recht gut mit mehrern Adaptern und Profilen umgehen.

Gruß
Uwe

Akoellh
13-Oct-2010, 09:09
Aber kann es sein, dass wicd als Network Manager ebenfalls eine Lösung wäre? Der kann IIRC recht gut mit mehrern Adaptern und Profilen umgehen.


Gut möglich, weiter vorne hatte ich das ja auch schon angedeutet ("anderes Frontend"), die udev-Regeln -um die es mir hier hauptsächlich geht, man könnte auch sagen, daß ich den Thread ein weing für ein HowTo mit Rückmeldung mißbrauche, oder er sich von alleine in diese Richtung entwickelte- sind unabhängig vom verwendeten Frontend für die Netzwerkkonfiguration.

Eigentlich soll das hier auch als Anregung für ähnliche Problem gelten (z.B. haben viele USB-Geräte mittlerweile solch ein unter Linux nutzloses, virtuelles CDROM).

Das Problem mit dem "ins Wackeln kommende System", wenn man den Stick abzieht, scheint auf Treiberebene zu liegen, also das dürfte dann wohl auch wicd (oder ifup, welches man übrigens mit SCPM auch "profilfähig" bekommen könnte) davon betroffen sein.

Ich hoffe zumindest, daß dem TE auch schon eine weile klar ist, daß es hier nicht nur um die Lösung seines Problems geht, sondern auch ein wenig darum, etwas "zu Papier" zu bringen, was man alles mit Bordmitteln auf ziemlich tiefer Ebene (und das gilt nun mal für udev) so machen kann.

Akoellh
12-Dec-2010, 11:27
Später Nachtrag für Querleser, was NetworkManager selbst noch als Konfigurationsmöglichkeit anbietet:

Man kann NWM auch sagen, er solle ein bestimmtes Netzwerkgerät anhand der MAC-Adresse komplett ignorieren, also eine andere Art des Holzhammers.

Für Details empfehle ich das Lesen der entsprechenden man-Page(s) NetworkManager.conf(5) bzw. nm-system-settings.conf(5) (je nach Version von NWM gibt es die eine, die andere oder beide) mit Hauptaugenmerk auf den Abschnitt "plugins" in [main] sowie den Abschnitt [keyfile] und dort besonders die Option "unmanaged".