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 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.
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.
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.
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.
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:
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).
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…
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.
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”.
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.
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/wlan0
Die Ausgabe kannst Du Dir natürlich zuerst mal ansehen und dann postest Du sie hier.
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.
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==""
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)
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?).
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).
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).
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
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.
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:
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:
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
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.
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.
Was 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.
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?
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.
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.
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.
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.
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.
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).
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.
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”.
Ich 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/sr1
Du 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”.
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.
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:
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 devices
es “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?