scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Das Interface heisst dort offenbar wlx00e04c193e06 Das kann wirklich immer variieren wie es aussieht, aber es sieht doch schon etwas merkwürdig lang aus... hmmm. Wenn das immer noch nicht gehen sollte dann, könnte vllt doch der Treiber Probleme machen...
Aber eins nach dem anderen.
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Ja, diese Warnung ist bei mir auch gekommen, das hatte ich sogar in meinem ersten Versuch, die Anleitung zu schreiben, erwähnt (die leider "verloren" gegangen ist)
Aber ist denn das Symbol mit den Pfeilen erschienen rechts oben ?
Scheint ein wenig buggy zu sein in 17.10 hmm
|
sabined
(Themenstarter)
Anmeldungsdatum: 16. Februar 2011
Beiträge: 237
|
Noch einmal das schöne Spiel... Terminal 1:
tis@put:~$ sudo systemctl stop network-manager
[sudo] Passwort für musmontis:
tis@put:~$ sudo killall wpa_supplicant
tis@put:~$ wpa_passphrase O2-WLAN65 ODYPALG6NRXH4B24 >> /tmp/test.conf
tis@put:~$ iwconfig
wlx00e04c193e06 unassociated Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated
Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
lo no wireless extensions.
enp2s0 no wireless extensions.
tis@put:~$ sudo wpa_supplicant -i wlx00e04c193e06 -c /tmp/test.conf
Successfully initialized wpa_supplicant
Terminal 2:
tis@put:~$ sudo dhclient wlx00e04c193e06
[sudo] Passwort für musmontis:
Ping... Hoffnung... ping-Ergebnis:
Keine Internetverbindung
Versuchen Sie Folgendes:
Prüfen Sie Netzwerkkabel, Modem und Router
WLAN-Verbindung erneut herstellen
ERR_INTERNET_DISCONNECTED
Ich hol die Axt. Edit:
scorpion81 schrieb: Ja, diese Warnung ist bei mir auch gekommen, das hatte ich sogar in meinem ersten Versuch, die Anleitung zu schreiben, erwähnt (die leider "verloren" gegangen ist)
Aber ist denn das Symbol mit den Pfeilen erschienen rechts oben ?
Scheint ein wenig buggy zu sein in 17.10 hmm
Da ist nichts erschienen, auch kein Symbol 😕 Noch ein Edit:
Wenn ich händisch ein neues Funknetzwerk erstellen möchte, habe ich lediglich zwei "Sicherheiten" zur Auswahl, WEP 128-bit und WEP 40/128-bit, nicht WPA2, mein Router funkt aber mit WPA2-Schlüssel. Ist das vielleicht der Grund, dass nix geht?
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Hab jetzt mal in dem Ubuntu 17.10 in der Virtualbox einen angepassten Treiber für meinen Stick kompiliert, https://github.com/genodeftest/Netgear-A6210/tree/port-to-4.13 dann den Stick per USB Filterung an die Virtualbox durchgereicht, und dort lediglich (wie für meinen Stick bzw Treiber (?) erforderlich) sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf
sudo service network-manager restart eingegeben.
Dann erschien das Netzwerk, er fragte nach dem WPA2(!) Schlüssel, aber nur einmal. Dann hat er sich verbunden.
Das mit nur WEP als Sicherheitsmethode klingt aber sehr merkwürdig... Weiterhin wurde bei mir auch ein Interface "wlan0" schon automatisch angelegt, nachdem der Treiber geladen und der Stick durchgereicht wurde... Das mit diesen langen Interfacenamen ist wohl ein neues "Feature" ab Ubuntu 16.04... aber komischerweise betrifft das meinen Stick irgendwie nicht...
versteh ich nicht... sonst hätte ich das hier https://askubuntu.com/questions/826325/how-to-revert-usb-wifi-interface-name-from-wlxxxxxxxxxxxxx-to-wlanx (ein wenig kompliziert, wenn ich es nicht selbst durchprobieren kann) mal probieren können, aber es scheint Fälle zu geben wo dieser lange Name samt inbegriffener MAC-Adresse Probleme macht... Das war nu meine letzte "Hoffnung" dass das Problem mit meinem Stick (FritzWLAN AC 860) reproduzierbar ist. Hmmmmm... eine echt harte Nuss wie es aussieht...
|
sabined
(Themenstarter)
Anmeldungsdatum: 16. Februar 2011
Beiträge: 237
|
Ähm...
nm-applet
geht doch. Ich hab die beiden Pfeile einfach übersehen, sie sind so winzig und ausgegraut und haben sich hinter der Pfote meines Plüschhundes versteckt, der auf dem Monitor sitzt ☺
Also hab ich die Verbindungsdaten eingetragen, und WPA2 wird jetzt auch angezeigt, allerdings zwei Varianten, Personal und Enterprise - von beidem hab ich keinen Schimmer. Also hab ich mal Personal ausgewählt und den WPA2-Schlüssel eingetragen. Aber... es tut sich nichts. Er versucht sich zu verbinden und bricht dann ab. Edit: Erst mal tausend Dank für deine Bemühungen, ich weiß das sehr zu schätzen! Jetzt wird's noch komischer. Ich habe den Stick wütend aus dem USB-Anschluss rausgerissen, kurz überlegt und in den Hub eingesteckt. Jetzt erkennt er das Netzwerk plötzlich auf Anhieb, und noch ein paar mehr von den Nachbarn, und er fragt nach dem WPA2-Schlüssel. Aber wenn ich den eingebe, verbindet er sich auch nicht, dann kommt nach kurzer Zeit die Meldung, ich wäre jetzt offline.
Im Terminal erscheint die Meldung:
nm-applet-Message: No keyring secrets found for o2-WLAN65/802-11-wireless-security; asking user.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
😲
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Also, ich hab noch mehr mit der Virtualbox rumprobiert... dabei ist sie mir zweimal komplett abgeschmiert weil der Treiber doch etwas wackelig zu sein scheint
Musste auch den Rechner dann neu starten, weil da irgendwas "geklemmt" hat beim Re-initialisieren des Sticks. Wollte es einfach zweifelsfrei reproduzieren können. Jedenfalls, wenn man als Nutzer "Automatische Anmeldung" aktiviert hat, also nicht bei jeder Anmeldung (am Rechner) sein Passwort eingibt, dann scheint
der Gnome-Keyring nicht entsperrt zu werden. Genau einmal hatte ich dann auch die wiederkehrende Abfrage des WPA2 Schlüssels.
Man könnte das so umstellen dass man jedesmal sein Passwort eingibt bei der Anmeldung, oder
unter "Passwörter und Verschlüsselung" das Vorhängeschloss neben "Anmeldung" klicken, sein Nutzerpasswort eingeben und diesen einen Keyring entsperren. Dann müsste er sich eigentlich den WPA2 Schlüssel dort merken, wenn man ihn bei dem anderen Dialog der beim Verbinden mit dem Netzwerk hochkommt, eingibt.
Oder halt in den Eigenschaften der Verbindung (Zahnrad auf der Verbindung, erscheint dort wo der "Wartekreis" ist, wenn man da hin klickt oder wartet oder drüber hovert
mit dem Mauszeiger, jedenfalls kommt man auch auf diesem Weg in die Verbindungseigenschaften so wie es aussieht. Bin darauf hierdurch gekommen... https://unix.stackexchange.com/questions/331439/how-to-enable-wpa-wpa2-in-networkmanager da gehts zwar um Linux Arch, welches wohl den gnome-keyring nicht standardmässig installiert hat, aber bei Ubuntu ist er das. Edit: Hmm auf dem Screenshot mit dem Anmeldefenster hat die SSID ein kleines "o", beim wpa_supplicant aber ein grosses "O"... oh oh ... 😀 das könnten hier verschiedene SSIDs sein
|
sabined
(Themenstarter)
Anmeldungsdatum: 16. Februar 2011
Beiträge: 237
|
Oh, stimmt, da hat sich ein großes O in der SSID eingeschlichen gehabt. Aber das war nicht weiter tragisch, denn ich hatte beide Varianten parallel zum Testen eingerichtet. Jetzt hab ich beide komplett gelöscht und die korrekte SSID mit dem kleinen o etc. neu eingetragen, aber den Haken bei "automatisch anmelden" weggelassen, und den Schlüssel händisch in die Eingabeaufforderung eingetippt. Was soll ich sagen... Dieser Keyring macht mich wahnsinnig.
nm-applet-Message: No keyring secrets found for o2-WLAN65/802-11-wireless-security; asking user.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. Passt womöglich was mit dem Treiber nicht? Edit: Diese Bug-Beschreibung https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1579246 trifft doch meinen Nagel glatt auf den Kopf, oder seh ich das falsch? Edit 2: Habe nun die Datei etc/NetworkManager/system-connections/o2-WLAN65 geöffnet. Sie schaut so aus: [connection]
id=o2-WLAN65
uuid=3e0be555-4946-412a-b0ae-d3127fdd4069
type=wifi
autoconnect=false
permissions=user:tis:;
[wifi]
mac-address=00:E0:4C:19:3E:06
mac-address-blacklist=
mode=infrastructure
ssid=o2-WLAN65
[wifi-security]
key-mgmt=wpa-psk
psk=ODYPALG6NRXH4B24
[ipv4]
dns-search=
method=auto
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto
Ist da vielleicht irgendwas verquer?
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Hallo, das wollte ich grad vorschlagen, diese Datei mal ggf. anzupassen. Die sieht bei mir so aus:
[connection]
id=<SSID>
uuid=<eine generierte UUID>
type=wifi
permissions=
[wifi]
mac-address=00:00:00:00:00:00
mac-address-blacklist=
mode=infrastructure
ssid=<SSID>
[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=<wpa2 schlüssel>
[ipv4]
dns-search=
method=auto
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto Das mit dem Keyring hatte ich jetzt auch, mehrfache Passwortabfrage. Ich hatte versehentlich ein falsches Passwort eingegeben, dass hat er sich irgendwo gemerkt (im Keyring vllt, aber war nix zu finden dort hmm)
oder bereits falsch in der system-connections Datei. Ausserdem war ich wohl auch im automatischen Anmeldemodus. Ubuntu 17.10 wirkt irgendwie nicht richtig ausgegoren in diesem Aspekt (persönliche Meinung) Jedenfalls stand bei der wiederholten Passwortabfrage immer das falsche Passwort drin (in den Verbindungseigenschaften; es liess sich zwar ändern aber der "Anwenden" Button war deaktiviert.
Also irgendwas ist da ganz komisch... Nach einigem Hin und Her konnte ich aber doch Verbindungen herstellen, ohne nm-applet zu benutzen oder gar wpa_supplicant (der network manager ruft diesen auf).
Aber ich konnte es leider noch nicht ganz genau eingrenzen, woran es lag... hmmm Edit: der genannte Bug *sollte* eigentlich bereits gefixed sein, wenn er nicht auf mysteriöse Weise zurückgekehrt ist. Damals gings auch nicht um eine WLAN verbindung dort glaub ich, vllt wurde der nur halb gefixed oder so...
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Ok, ich hab jetzt versucht etwas systematischer vorzugehen.
Habe es denke ich nun isolieren können. Voraussetzung: Unter Einstellungen->Informationen->Benutzer auf dem Benutzer die "Automatische Anmeldung" (am Rechner) deaktivieren (oben Entsperren vorher).
Damit sollte Ubuntu nun bei jedem Start das Benutzerpasswort abfragen. Soll nur sicherstellen dass der Keyring entsperrt ist, falls er denn überhaupt genutzt werden soll.
Normalerweise sollte dafür noch ggf ein Extra Password-Prompt aufgehen, wenn er entsperrt werden soll, aber da ist irgendwas öfters im Hintergrund abgeschmiert beim Testen,
vermutlich der Keyring Daemon, whatever. Aber wir müssen ihn ja nicht benutzen Nun Schritt für Schritt: 1. sudo service network-manager stop 2. Stick rausziehen und wieder reinstecken (das habe ich zumindest in der Virtualbox gemacht, indem ich das Durchreichen deaktiviert und reaktiviert hab)
das sollte den Treiber neu laden. Alternativ könnte man versuchen mit
sudo modprobe -r <Treibermodulname> und dann sudo modprobe <Treibermodulname> den Treiber zu ent- und wieder zu laden. 2,5. (gah) sudo service network-manager start (natürlich ☺ ) 3. Dann sollten unter Einstellungen->WLAN die gefundenen Netze (nach einiger Zeit) auftauchen. 4. Die SSID wählen und dann kommt der "berühmte" Schlüsseldialog, dort den Schlüssel eintragen. 5. Wenn der Treiber keine Zicken gemacht hat inzwischen (hat er bei mir öfters, Timeouts und so Scherze) sollte er nun versuchen sich zu verbinden. 6. Sollte das nicht geklappt haben, kann man nach einiger Zeit auf das Zahnrad klicken, und dort schauen, was bei WPA2 Passwort eingestellt ist:
Rechts auf das Symbol im Passworteingabefeld klicken und wählen: Für alle Nutzer speichern → speichert es in hier unter "psk" /etc/NetworkManager/system-connections/<SSID> Für den aktuellen Nutzer speichern, (versucht es) im Keyring zu speichern, kann aber in die Buxe gehen wenn nicht entsperrt und wenn da wieder was abschmiert. Immer nachfragen, dann kommt immer der Dialog hoch. Sollte nun Für alle Nutzer gespeichert werden.
Problem an der Sache: das passiert aus diesem Dialog erst wenn die Verbindung hergestellt ist ! Zumindest ist dann erst der "Anwenden" Button aktiv.
Zur Kontrolle die system-connection datei prüfen. 7. ggf das Netzwerk als "Bekannt" setzen (Button mit den drei waagerechten Strichen, dann das Netzwerk wählen und Haken setzen) 8. Entscheidend ist nun, wenn die Verbindung nicht geklappt hat, was nun in der Datei steht
(wenn unter PSK der schlüssel steht, sollte er auch im Passwortfeld drinstehen in den Verbindungseigenschaften) 9. Dann nochmal verbinden, es kann sein dass EINMAL noch der Schlüsseldialog hochkommt... ggf die system-connections datei in einem Editor offen lassen und schauen ob sie sich
nach dem Verbindungsversuch verändert hat (die UUID kann dann anders sein und man kann wieder von vorn anfangen, quasi... wenn der Treiber rumgezickt hat) 10. ggf öfters in einem Terminal mit dmesg mal gucken, was der Treiber so "treibt", an Warnungen / Fehlern ausspuckt 11. Notfalls die Verbindung über nm-applet manuell zusammenstellen, auch dort auf Für alle Nutzer speichern gehen. 12. Himmelgrzifazgrmbl... jetzt sollte langsam die Verbindung zustande gekommen sein ☺ (evtl nochmal die Datei checken, sollte so aussehen wie ich im letzten Post gepostet hab 😉 ) Wie gesagt, selbst bei dem wackeligen selbstgebauten mt7662u Treiber hier funktionierts, dann sollte es mit einem "offiziellen" Treiber aus den Paketquellen erst recht gehen.
|
sabined
(Themenstarter)
Anmeldungsdatum: 16. Februar 2011
Beiträge: 237
|
Da bin ich wieder. Ich habe die Anleitung - danke ☺ - Schritt für Schritt befolgt. Alles lief gut bis einschließlich Punkt 7, nur, die Verbindung ist noch immer nicht zustande gekommen, ich werde nach wie vor pausenlos aufgefordert, den Schlüssel einzutippen - ohne Ergebnis. Also habe ich versucht, die o2-WLAN65-Datei unter etc/NetworkManager/system-connections/ zu öffnen, und bin fast vom Stuhl gekippt:
tis@put:~$ sudo nautilus
Invalid MIT-MAGIC-COOKIE-1 keyUnable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt
(nautilus:2761): Gtk-WARNING **: cannot open display: :0
Das ging gestern noch! Heute früh ist ein Update gelaufen, und ich vermute stark, dass das damit zu tun hat.
gksudo nautilus
funktioniert nämlich auch nicht mehr, da kommt zwar ein Eingabefenster, das sich aber nicht anwählen lässt. Unglaublich 😬
dmesg
spuckt das aus, für mich überwiegend Bahnhof, ich kann allenfalls spekulieren, was los sein könnte. Auffällig - aber vielleicht auch normal? - ist, dass die USB-Anschlüsse so oft genannt werden, und ganz unten steht hinter dem Treiber-Namen auch was von "not ready" und "not found":
[sudo] Passwort für tis:
tis@put:~$ sudo service network-manager start
tis@put:~$ dmesg
[ 0.000000] random: get_random_bytes called from start_kernel+0x42/0x4e1 with crng_init=0
[ 0.000000] Linux version 4.13.0-19-generic (buildd@lcy01-amd64-021) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)) #22-Ubuntu SMP Mon Dec 4 11:58:07 UTC 2017 (Ubuntu 4.13.0-19.22-generic 4.13.13)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-19-generic root=UUID=0084531a-ad27-406c-a1cb-481c715ea1e1 ro quiet splash vt.handoff=7
...
[ 1.278111] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.278114] ehci-pci: EHCI PCI platform driver
[ 1.278222] ehci-pci 0000:00:12.2: EHCI Host Controller
[ 1.278229] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1
[ 1.278232] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[ 1.278240] ehci-pci 0000:00:12.2: debug port 1
[ 1.278275] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe8ff800
[ 1.292043] ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00
[ 1.292080] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.292081] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.292082] usb usb1: Product: EHCI Host Controller
[ 1.292083] usb usb1: Manufacturer: Linux 4.13.0-19-generic ehci_hcd
[ 1.292084] usb usb1: SerialNumber: 0000:00:12.2
[ 1.292182] hub 1-0:1.0: USB hub found
[ 1.292187] hub 1-0:1.0: 6 ports detected
[ 1.292412] ehci-pci 0000:00:13.2: EHCI Host Controller
[ 1.292416] ehci-pci 0000:00:13.2: new USB bus registered, assigned bus number 2
[ 1.292419] ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[ 1.292427] ehci-pci 0000:00:13.2: debug port 1
[ 1.292459] ehci-pci 0000:00:13.2: irq 19, io mem 0xfe8ff400
[ 1.308039] ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00
[ 1.308073] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.308074] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.308075] usb usb2: Product: EHCI Host Controller
[ 1.308076] usb usb2: Manufacturer: Linux 4.13.0-19-generic ehci_hcd
[ 1.308077] usb usb2: SerialNumber: 0000:00:13.2
[ 1.308160] hub 2-0:1.0: USB hub found
[ 1.308164] hub 2-0:1.0: 6 ports detected
[ 1.308283] ehci-platform: EHCI generic platform driver
[ 1.308292] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.308295] ohci-pci: OHCI PCI platform driver
[ 1.308404] ohci-pci 0000:00:12.0: OHCI PCI host controller
[ 1.308408] ohci-pci 0000:00:12.0: new USB bus registered, assigned bus number 3
[ 1.308428] ohci-pci 0000:00:12.0: irq 16, io mem 0xfe8fe000
[ 1.372053] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[ 1.372054] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.372055] usb usb3: Product: OHCI PCI host controller
[ 1.372056] usb usb3: Manufacturer: Linux 4.13.0-19-generic ohci_hcd
[ 1.372056] usb usb3: SerialNumber: 0000:00:12.0
[ 1.372151] hub 3-0:1.0: USB hub found
[ 1.372157] hub 3-0:1.0: 3 ports detected
[ 1.372331] ohci-pci 0000:00:12.1: OHCI PCI host controller
[ 1.372335] ohci-pci 0000:00:12.1: new USB bus registered, assigned bus number 4
[ 1.372350] ohci-pci 0000:00:12.1: irq 16, io mem 0xfe8fd000
[ 1.436052] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 1.436054] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.436054] usb usb4: Product: OHCI PCI host controller
[ 1.436055] usb usb4: Manufacturer: Linux 4.13.0-19-generic ohci_hcd
[ 1.436056] usb usb4: SerialNumber: 0000:00:12.1
[ 1.436150] hub 4-0:1.0: USB hub found
[ 1.436156] hub 4-0:1.0: 3 ports detected
[ 1.436329] ohci-pci 0000:00:13.0: OHCI PCI host controller
[ 1.436333] ohci-pci 0000:00:13.0: new USB bus registered, assigned bus number 5
[ 1.436353] ohci-pci 0000:00:13.0: irq 18, io mem 0xfe8fc000
[ 1.500060] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[ 1.500062] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.500063] usb usb5: Product: OHCI PCI host controller
[ 1.500063] usb usb5: Manufacturer: Linux 4.13.0-19-generic ohci_hcd
[ 1.500064] usb usb5: SerialNumber: 0000:00:13.0
[ 1.500149] hub 5-0:1.0: USB hub found
[ 1.500155] hub 5-0:1.0: 3 ports detected
...
[ 1.564065] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 1.564067] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.564067] usb usb6: Product: OHCI PCI host controller
[ 1.564068] usb usb6: Manufacturer: Linux 4.13.0-19-generic ohci_hcd
[ 1.564069] usb usb6: SerialNumber: 0000:00:13.1
[ 1.564161] hub 6-0:1.0: USB hub found
[ 1.564168] hub 6-0:1.0: 3 ports detected
...
[ 1.628050] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[ 1.628051] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.628052] usb usb7: Product: OHCI PCI host controller
[ 1.628053] usb usb7: Manufacturer: Linux 4.13.0-19-generic ohci_hcd
[ 1.628054] usb usb7: SerialNumber: 0000:00:14.5
[ 1.628149] hub 7-0:1.0: USB hub found
[ 1.628155] hub 7-0:1.0: 2 ports detected
...
[ 1.628505] usb usb8: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.628506] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.628507] usb usb8: Product: xHCI Host Controller
[ 1.628508] usb usb8: Manufacturer: Linux 4.13.0-19-generic xhci-hcd
[ 1.628509] usb usb8: SerialNumber: 0000:04:00.0
[ 1.628588] hub 8-0:1.0: USB hub found
[ 1.628593] hub 8-0:1.0: 2 ports detected
[ 1.628652] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 1.628654] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 9
[ 1.628665] usb usb9: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.628677] usb usb9: New USB device found, idVendor=1d6b, idProduct=0003
[ 1.628678] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.628679] usb usb9: Product: xHCI Host Controller
[ 1.628679] usb usb9: Manufacturer: Linux 4.13.0-19-generic xhci-hcd
[ 1.628680] usb usb9: SerialNumber: 0000:04:00.0
[ 1.628746] hub 9-0:1.0: USB hub found
[ 1.628751] hub 9-0:1.0: 2 ports detected
...
[ 2.364019] usb 1-2: new high-speed USB device number 3 using ehci-pci
[ 2.512662] usb 1-2: New USB device found, idVendor=1a40, idProduct=0101
[ 2.512664] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 2.512665] usb 1-2: Product: USB 2.0 Hub
[ 2.512809] hub 1-2:1.0: USB hub found
[ 2.512910] hub 1-2:1.0: 4 ports detected
...
[ 2.913134] usb 1-2.1: New USB device found, idVendor=0bda, idProduct=a811
[ 2.913136] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.913137] usb 1-2.1: Product: 802.11ac WLAN Adapter
[ 2.913138] usb 1-2.1: Manufacturer: Realtek
[ 2.913138] usb 1-2.1: SerialNumber: 00e04c000001
...
[ 3.205858] usb 1-2.2: New USB device found, idVendor=0bda, idProduct=0161
[ 3.205860] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.205861] usb 1-2.2: Product: USB2.0-CRW
[ 3.205862] usb 1-2.2: Manufacturer: Generic
[ 3.205863] usb 1-2.2: SerialNumber: 20070818000000000
[ 3.288142] usb 1-2.4: new low-speed USB device number 6 using ehci-pci
...
[ 3.571947] rtl8812au: loading out-of-tree module taints kernel.
[ 3.572922] rtl8812au: module verification failed: signature and/or required key missing - tainting kernel
[ 3.574526] RTL871X: module init start
[ 3.574527] RTL871X: rtl8812au v4.3.14_13455.20150212_BTCOEX20150128-51
[ 3.574527] RTL871X: rtl8812au BT-Coex version = BTCOEX20150128-51
[ 3.632373] Adding 3998716k swap on /dev/sdb5. Priority:-1 extents:1 across:3998716k SSFS
[ 3.761915] RTL871X: rtw_ndev_init(wlan0)
[ 3.762151] usbcore: registered new interface driver rtl8812au
[ 3.762151] RTL871X: module init ret=0
[ 3.764809] rtl8812au 1-2.1:1.0 wlx00e04c193e06: renamed from wlan0
...
[ 5.048798] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 5.126383] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 6.482220] r8169 0000:02:00.0 enp2s0: link up
[ 6.482229] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[ 14.427287] rfkill: input handler disabled
[ 64.505659] usb 1-2.1: USB disconnect, device number 4
[ 64.521147] RTL871X: rtw_ndev_uninit(wlx00e04c193e06)
[ 64.573343] RTL871X: rtw_cmd_thread: DriverStopped(1) SurpriseRemoved(1) break at line 550
[ 64.573366] RTL871X: rtw_dev_unload: driver in IPS-FWLPS
[ 69.848275] usb 1-2.1: new high-speed USB device number 7 using ehci-pci
[ 69.957503] usb 1-2.1: New USB device found, idVendor=0bda, idProduct=a811
[ 69.957511] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 69.957515] usb 1-2.1: Product: 802.11ac WLAN Adapter
[ 69.957518] usb 1-2.1: Manufacturer: Realtek
[ 69.957521] usb 1-2.1: SerialNumber: 00e04c000001
[ 70.123016] RTL871X: rtw_ndev_init(wlan0)
[ 70.146708] rtl8812au 1-2.1:1.0 wlx00e04c193e06: renamed from wlan0
[ 78.868685] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 79.324408] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 79.520956] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 118.865264] RTL871X: rtw_set_802_11_connect(wlx00e04c193e06) fw_state=0x00000008
[ 119.409856] RTL871X: start auth
[ 119.412087] RTL871X: auth success, start assoc
[ 119.415981] RTL871X: rtw_cfg80211_indicate_connect(wlx00e04c193e06) BSS not found !!
[ 119.416003] RTL871X: assoc success
[ 119.416031] IPv6: ADDRCONF(NETDEV_CHANGE): wlx00e04c193e06: link becomes ready
[ 121.541366] RTL871X: send eapol packet
[ 122.576413] RTL871X: send eapol packet
[ 123.581710] RTL871X: sta recv deauth reason code(2) sta:b0:ea:bc:5b:a2:a6, ignore = 0
[ 131.256935] RTL871X: rtw_set_802_11_connect(wlx00e04c193e06) fw_state=0x00000008
[ 131.494676] RTL871X: start auth
[ 131.498662] RTL871X: auth success, start assoc
[ 131.503437] RTL871X: rtw_cfg80211_indicate_connect(wlx00e04c193e06) BSS not found !!
[ 131.503456] RTL871X: assoc success
[ 131.509
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Also, dieses sudo / gksudo Problem hatte ich auch, habs mittels xhost si:localuser:root im Terminal gefixed. Das ist aber keine Dauerlösung, daher hab ich noch ein Startprogramm mit genau diesem Befehl angelegt, siehe Screenshot.
Dann sollte sudo mit grafischen Programmen wieder richtig funktionieren. Zu den Treiber-Meldungen, speziell [ 119.409856] RTL871X: start auth
[ 119.412087] RTL871X: auth success, start assoc
[ 119.415981] RTL871X: rtw_cfg80211_indicate_connect(wlx00e04c193e06) BSS not found !!
[ 119.416003] RTL871X: assoc success
[ 119.416031] IPv6: ADDRCONF(NETDEV_CHANGE): wlx00e04c193e06: link becomes ready
[ 121.541366] RTL871X: send eapol packet
[ 122.576413] RTL871X: send eapol packet
[ 123.581710] RTL871X: sta recv deauth reason code(2) sta:b0:ea:bc:5b:a2:a6, ignore = 0 BSS not found und deauth reason code(2) machen mir Kopfschmerzen... das heisst dass er sich authentifizieren konnte aber das nicht mehr gültig ist hmmm
Bringt es denn was, die MAC-Adresse des Accesspoint wieder under BSSID einzutragen ? Bei mir steht da nix bzw nur Nullen drin, aber es scheint hier dann zu funktionieren, irgendwie...
Ich frag mich auch ob dieser lange Interfacename zusätzlich nicht doch Probleme macht... Er kommt hierdurch https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ zustande und dort (unten) stehen 3 Optionen, um es zu deaktivieren.
(Und fummelt man "verkehrt" am Grub herum, kanns sein dass Ubuntu nicht mehr so recht starten will.) Bei mir gibts diese udev/systemd rules Dateien gar nicht... das ist ein frisch installiertes Ubuntu 17.10 in VirtualBox.
Diese rules dateien sind vermutlich alter Mist aus früheren Versionen von Ubuntu oder werden beim Installieren in eine VM irgendwie "unterdrückt" oder so. Was steht denn in folgenden Verzeichnissen ?
/etc/systemd/network und /etc/udev/rules.d Bei mir ist da so gut wie gar nix drin... hmm. Das ist alles sehr merkwürdig. Scheint so als würde bei Ubuntu ständig irgendwie unter der Haube rumexperimentiert mit jedem Release. Mal upstart, mal systemd, mal X11, mal Wayland, mal dies mal das.... Edit: Screenshot (natürlich) vergessen 😀 Edit 2: https://www.digitus.info/de/produkte/computer-zubehoer-und-komponenten/netzwerk/wireless-netzwerk/dn-70565/ unten auf dieser Website gibts tatsächlich einen "Linux Treiber", aber der ist zum selberkompilieren gedacht, sprich veralteter Sourcecode. Der sich bei mir testweise unter 17.10 aufgrund des Kernels 4.13 natüüüürlich nicht mehr kompilieren lässt. Sollte aber im Großen und Ganzen dem Sourcepaket des rtl8812au-dkms entsprechen, das ist auch schon etwas angestaubt aber kompiliert wenigstens. Und mit sowas werben sie für "Linux Support", unglaublich... Da steht man dann erstmal im Regen.
- Bilder
|
sabined
(Themenstarter)
Anmeldungsdatum: 16. Februar 2011
Beiträge: 237
|
Merci für den Screenshot, ich hab mich gleich drauf gestürzt, und siehe da, Nautilus mag wieder starten als root! In den Verzeichnissen
/etc/systemd/network
/etc/udev/rules.d
steht nichts drin, die Ordner sind leer. Also hab ich die Datei O2-WLAN65-Datei unter etc/NetworkManager/system-connections/ geöffnet und daran angepasst
scorpion81 schrieb: 12. Himmelgrzifazgrmbl... jetzt sollte langsam die Verbindung zustande gekommen sein ☺ (evtl nochmal die Datei checken, sollte so aussehen wie ich im letzten Post gepostet hab 😉 )
und die Anleitung nochmal Schritt für Schritt befolgt, mit der MAC-Adresse rumgespielt, aber... es tut sich nichts, er verbindet sich nach wie vor nicht. Täglich grüßt das Murmeltier. Hier noch die Ausgabe von
dmesg
von eben:
...
[ 5.092908] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 5.156729] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 6.561315] r8169 0000:02:00.0 enp2s0: link up
[ 6.561324] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[ 17.343606] rfkill: input handler disabled
[ 655.283511] usb 1-2.1: USB disconnect, device number 4
[ 655.297629] RTL871X: rtw_ndev_uninit(wlx00e04c193e06)
[ 655.341695] RTL871X: rtw_cmd_thread: DriverStopped(1) SurpriseRemoved(1) break at line 550
[ 655.341704] RTL871X: rtw_dev_unload: driver in IPS-FWLPS
[ 659.345725] usb 1-2.1: new high-speed USB device number 7 using ehci-pci
[ 659.454848] usb 1-2.1: New USB device found, idVendor=0bda, idProduct=a811
[ 659.454856] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 659.454860] usb 1-2.1: Product: 802.11ac WLAN Adapter
[ 659.454863] usb 1-2.1: Manufacturer: Realtek
[ 659.454866] usb 1-2.1: SerialNumber: 00e04c000001
[ 659.605372] RTL871X: rtw_ndev_init(wlan0)
[ 659.631228] rtl8812au 1-2.1:1.0 wlx00e04c193e06: renamed from wlan0
[ 667.879962] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 668.331014] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 668.480571] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 705.088248] RTL871X: rtw_set_802_11_connect(wlx00e04c193e06) fw_state=0x00000008
[ 705.295033] RTL871X: start auth
[ 705.297634] RTL871X: auth success, start assoc
[ 705.301927] RTL871X: rtw_cfg80211_indicate_connect(wlx00e04c193e06) BSS not found !!
[ 705.301972] RTL871X: assoc success
[ 705.302284] IPv6: ADDRCONF(NETDEV_CHANGE): wlx00e04c193e06: link becomes ready
[ 705.306298] RTL871X: send eapol packet
[ 706.305807] RTL871X: send eapol packet
[ 707.304912] RTL871X: send eapol packet
[ 708.306428] RTL871X: send eapol packet
[ 742.036674] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready
[ 799.018995] IPv6: ADDRCONF(NETDEV_UP): wlx00e04c193e06: link is not ready Ich schätze, ich habe zwei Alternativen, aber ich kann nur schwer einschätzen, welche die bessere ist: 1. Ich schicke den Stick zurück mit dem Hinweis, dass er unter Linux nicht zum Laufen zu bekommen ist (den Treiber auf der Digitus-Seite hab ich mir auch angeschaut und mich gleich mit Grausen abgewendet), oder 2. Ich setze das System ganz neu auf; das ist nämlich ein Update von 16.04 auf 17.10, und das ganze System ist schon etliche Jahre alt und mit Sicherheit etwas verbastelt. Besteht denn eine Chance, dass der Stick dann läuft?
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Hmmmm, auch auf Biegen und Brechen kann ich die Generierung des langen Interfacenamens mit dem Stick und dem aktuellen Treiber hier nicht erzwingen, um dann testen zu können ob es immer noch klappt. Edit: Hab nochmal nachgesehen, wenn ich hier das rtl8812au-dkms Paket installiere, baut er mir im Endeffekt ein modul "8812au.ko", was von DKMS überwacht wird.
Was ergibt eigentlich
sudo modprobe 8812au
? In deinen dmesg logs scheint eine ganz andere Treiberversion geladen zu werden, hmmmm, nämlich rtl8812au. (mit einem neueren Builddatum)
Bei mir: "v4.3.8_12175.20140902" ?
(Der Treiber kann auch "so" geladen werden ohne dass die entsprechende Hardware da ist, aber es passiert danach dann nix weiter, logischerweise) Ich würde bezüglich des Sticks wirklich empfehlen, diese Gurke zurückzuschicken und einen Stick zu kaufen der vllt sogar out of the box unterstützt wird.
Hier https://wiki.ubuntuusers.de/WLAN/Karten/ gibts eine erste Übersicht zum Kompatiblitäts-Status verschiedener Hersteller und Chipsätze. Mitunter kann (muss aber nicht) der Kauf einer Noname / Billighardware
zum Glücksspiel mit den Treibern werden, da sich auch mal die Hardware-Revisionen ändern können, d.h. es wird als X verkauft und Y steckt drin sozusagen. Persönlich hab ich den FRITZ! WLAN Stick AC860 genommen, weil ich auch eine FritzBox 7590 besitze und in der Hinsicht schon mal ein geringeres Risiko eingehen wollte. Darüberhinaus hab ich mich zuerst auch hier bezüglich des Status der Fritzsticks informiert, und die Wahl fiel auf den AC 860, weil er laut der entsprechenden Anleitung erfolgreich zum Laufen gebracht werden konnte. Ich hab den Treiber vorab mal runtergeladen und kompiliert, um mögliche Probleme zu identifizieren. Hat wunderbar geklappt (Achtung, für den Kernel 4.13 gibt es auch eine extra angepasste Version → https://github.com/genodeftest/Netgear-A6210/tree/port-to-4.13) allerdings ist das mit etwas Arbeit verbunden, der Treiber muss kompiliert werden (in der Regel reicht ein "make" und dann ein "sudo make install" aus im Terminal mit diesem Treiberpaket), dann muss entweder der Kernel-Sourcecode nach DKMS "installiert" werden, damit er bei jedem Kernel-Update neu gebaut werden kann (hab ich noch nicht ausprobiert / eingerichtet) und zu guter Letzt muss man wenn es nach einem Kernelupdate Kompilierungsprobleme gibt, darauf hoffen, dass ein Fix bereitsteht oder schlimmstenfalls selbst den Sourcecode editieren (nach vorheriger Recherche, was wie wo anders sein muss, das klingt einfacher als es ist) Edit: Auch in dieser angepassten Version gilt, wie in der Originalanleitung, folgende Änderung in für den AVM FRITZ!WLAN AC860. VendorID und DeviceID müssen in Netgear-A6210/common/rtusb_dev_id.c wie hier gezeigt, eingetragen werden !
/****************************************************************************
* Ralink Tech Inc.
* 4F, No. 2 Technology 5th Rd.
* Science-based Industrial Park
* Hsin-chu, Taiwan, R.O.C.
* (c) Copyright 2002, Ralink Technology, Inc.
*
* All rights reserved. Ralink's source code is an unpublished work and the
* use of a copyright notice does not imply otherwise. This source code
* contains confidential trade secret material of Ralink Tech. Any attemp
* or participation in deciphering, decoding, reverse engineering or in any
* way altering the source code is stricitly prohibited, unless the prior
* written consent of Ralink Technology, Inc. is obtained.
****************************************************************************
Module Name:
rtusb_dev_id.c
*/
#define RTMP_MODULE_OS
#include "rtmp_comm.h"
#include "rt_os_util.h"
#include "rt_os_net.h"
/* module table */
USB_DEVICE_ID rtusb_dev_id[] = {
#ifdef MT76x2
{USB_DEVICE(0x0846, 0x9014), .driver_info = RLT_MAC_BASE}, /* Netgear WNDA3100v3 */
{USB_DEVICE(0x0B05, 0x180B), .driver_info = RLT_MAC_BASE}, /* ASUS USB-N53 */
{USB_DEVICE(0x0846, 0x9053), .driver_info = RLT_MAC_BASE}, /* MT7612U, Netgear A6210 */
{USB_DEVICE(0x0B05, 0x17EB), .driver_info = RLT_MAC_BASE}, /* ASUS USB-AC55 */
{USB_DEVICE(0x045e, 0x02e6), .driver_info = RLT_MAC_BASE}, /* Microsoft XBox One Wireless Adapter */
{USB_DEVICE(0x057c, 0x8503), .driver_info = RLT_MAC_BASE}, /* AVM GmbH */
{USB_DEVICE(0x0E8D, 0x7612), .driver_info = RLT_MAC_BASE},
{USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7632, 0xff, 0xff, 0xff), .driver_info = RLT_MAC_BASE},
{USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7662, 0xff, 0xff, 0xff), .driver_info = RLT_MAC_BASE},
#endif
{ }/* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, rtusb_dev_id); Als Fazit ist der Fritz stick also nur bedingt zu empfehlen. Vorteil: Wurde erfolgreich zum Laufen gebracht, Nachteil : *kann* viel Handarbeit / Ärger im späteren Verlauf bedeuten (Kernel Updates)
Und ein Neu-Aufsetzen des Systems ist grundsätzlich nicht verkehrt (persönliche Meinung), aber nur wegen eines einzelnen Sticks ? hmmm Aber ich merke auch dass hier nicht wirklich weiterzukommen ist, mit diesem aktuellen Stick.
Vielleicht weiss ja noch jemand anderes einen Rat dazu oder hat (positive) Erfahrungen mit diesem Stick gemacht ?
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Ok, ich hab jetzt noch ein bisschen tiefer gegraben... Entweder sind udev oder systemd "schuld" an dem langen Interfacenamen. Habs lokal aber nur für das Kabelgebundene Ethernet-Interface in der VM erzwingen können. Für den WLAN Treiber scheint nix "hinterlegt" zu sein hmmm (wo auch immer) Vllt liest der Treiber auch diese Konfigurationsdateien und deren Optionen und sucht sich selber den langen Namen aus. Jedenfalls, was ergibt
udevadm info -e | grep "ID_NET_*" und was steht in
/lib/systemd/network/99-default.link oder auch (falls vorhanden)
/run/systemd/network/99-default.link drin ? Gibts noch mehr Dateien in den beiden (network) Verzeichnissen ?
Und wenn ja, was steht da ? Wenn da bei der ersten Abfrage sowas wie
"ID_NET_NAME_MAC=" steht und in den Dateien evtl
bei [NamePolicy] evtl "mac" mit drin steht, könnte das die Ursache sein für die langen Interfacenamen. (Das grenzt doch schon an Hexerei, lol) Edit: Letzter Versuch...
Bringt es denn was, wenn man das hier
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rtl8812au", ATTR{type}=="1", NAME="wlan0"
in diese Datei
/etc/udev/rules.d/70-persistent-network.rules
schreibt ? /etc/udev... und /run/udev sollten Vorrang vor /lib/udev... haben.
Damit sollte der Name "wlan0" für das Interface erzwungen werden, vllt gehts ja dann... hmm.
Danach den Rechner einmal neu starten. Tipp wurde hier https://github.com/abperiasamy/rtl8812AU_8821AU_linux/blob/master/contrib/auto-install.sh entlehnt.
|
scorpion81
Anmeldungsdatum: 3. Dezember 2017
Beiträge: 29
|
Sooo, habe jetzt doch noch eine Interface-Umbenennung für meinen Treiber erzwingen können
mittels einer Datei /lib/systemd/network/98-ralink.link mit folgendem Inhalt:
[Match]
Driver="RALINK WLAN"
[Link]
Name=wlx5C4979FA5A8A
also diese elend lange Version mit Mac Adresse. Das Interface wird dann beim Laden des Treibers von wlan0 auf diesen Namen umbenannt laut dmesg. Und was soll ich sagen, mein Treiber oder der NetworkManager können das nicht verdauen... es gibt einen Crash dort laut dmesg.
Mit wlan0 funktionierts wie es soll. Jetzt stellt sich die Frage, wieso das beim Realtek Treiber passiert. Muss irgendwo ne Regel dafür sein bzw exportiert der Treiber diese Namen, und die "Standardregeln" greifen irgendwie...
|