RTL8188CUS und Buster eg testing

[KBDCALLS]

Und was ergibt das hier

• viewtopic.php?f=30&t=171667&p=1192626#p1192552

und

• Code: Alles auswählen

  iwlist scan

Alles bei eingesteckten Stick

PS: Verwende bitte demnächst die Codetags anstatt Quote.

Achso dmesg wird übersichtlicher

• Code: Alles auswählen

  dmesg --human

hängt man noch

• Code: Alles auswählen

  -w

an , kann man die Augabe mittverfolgen , wenns ein neues Ereignis gibt.

[smack9898]

Hallo und hier neusten updates

Code: Alles auswählen

iwlist scan

ergab

Code: Alles auswählen

 iwlist scan
-bash: iwlist: command not found

die 'freuden' wenn man mit Testing Versionen anfängt rumzuspielen.

Code: Alles auswählen

dmesg --human

Code: Alles auswählen

 sudo dmesg --human | grep rtl
[  +0.144089] r8169 0000:03:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw

Ich habe auch in der Zwischen Zeit mal zwei verschiedene VMs unter Vmware aufgezogen.
Einmal Debian 9 eg Strech und dann nochmal Debian 10 eg Buster

Unter Strech lief der Stick out of the Box.
Unter Buster habe ich mal folgendes versucht.

https://github.com/pvaret/rtl8192cu-fixes

Allerdings scheiterte es schon bei der installation, da das Packet

linux-headers-generic
aufzufinden war.

Code: Alles auswählen

 sudo apt-get install git linux-headers-generic build-essential dkms
[sudo] password for blub:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package linux-headers-generic is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'linux-headers-generic' has no installation candidate

vielleicht könnte mir jemand helfen das Fehlende Packet per Backport einzuspielen und vielleicht funktioniert es ja dann.

[KBDCALLS]

iwlist ist in den wireless-tools enthalten. Sind die nicht drauf installieren.

Poste mal

• Code: Alles auswählen

  dmesg --human -w 

Den Stick dabei enstecken und wieder entfernen. Aber das dann aber nach NoPaste Aber komplett.

[habakug]

Hallo,

wir wissen leider nicht welches Gerät verwendet wird. Bei eingestecktem USB-Gerät:

Code: Alles auswählen

# lsusb

Je nach Gerät könnte es erforderlich sein den rtl8192cu zu blacklisten:

Code: Alles auswählen

# echo -e "blacklist rtl8192cu" | tee -a /etc/modprobe.d/blacklist_rtl8192cu.conf

Dann müsste rtlxxxu geladen werden.
Das gilt natürlich auch andersrum, d.h. es sollte rtl8192cu auf die Blacklist, wenn das andere Modul verfügbar sein soll.
Verwendet man ein anderes Modul, z.B. aus einer Fremdquelle, müssten beide oben genannten Module auf die Blacklist.

Code: Alles auswählen

# ls /etc/modprobe.d/

Gruss, habakug

[KBDCALLS]

Das ist mit jetzt geade aufgefallen das Paket linux-headers-generic gibt es garnicht bei Debian , und hats auch nie geben. Das dürft eher zum Erfolg führen.

• Code: Alles auswählen

  aptitude install linux-headers-$(uname -r)

[willy4711]

[ 6422.482032] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin

Du postestst immer nur das, von dem du meinst, es posten zu müssen.
Wenn du einen USB-Stick (hier dein WLAN- Stick) einsteckst, erzählt dmesg einiges mehr, als du uns hier zu sehen gibst.
Aber selbst danach hat er ja Firmware geladen. (nämlich die rrtl8192cufw_TMSC.bin)

Also lass dmesg laufen, merke dir den Punkt, wenn du den Stick einsteckst und poste dann bitte alles war ab diesen Punkt ausgegeben wird. Dann sollte auch die ID der Hardware zu erkennen sein.

Es ist auch mehr als unwahrscheinlich, dass ein Gerät, dessen Firmware geladen wird, nirgends , auch bei der Ausgabe von inxi nicht erscheint.

Sehr genaue Auskunft bei zwei Netzwerk- Controllern sollte

Code: Alles auswählen

$ inxi -v 8 |grep Network: -A14

geben

[KBDCALLS]

Was ein klein wenig irritierend ist das es mehrere Firmawaredateien für ein Modul gibt.

• Code: Alles auswählen

  modinfo rtl8192cu                                                                         
  filename:       /lib/modules/4.19.0-1-amd64/kernel/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.ko           
  firmware:       rtlwifi/rtl8192cufw_TMSC.bin                                                                             
  firmware:       rtlwifi/rtl8192cufw_B.bin                                                                                
  firmware:       rtlwifi/rtl8192cufw_A.bin                                                                                
  firmware:       rtlwifi/rtl8192cufw.bin                                                                                  
  description:    Realtek 8192C/8188C 802.11n USB wireless                                                                 
  license:        GPL                                                                                                      
  author:         Larry Finger    <Larry.Finger@lwfinger.net>                                                              
  author:         Ziv Huang       <ziv_huang@realtek.com>                                                                  
  author:         Georgia         <georgia@realtek.com>     

Wird die eventuell die falsche geladen ? Deswegen wäre es interessanten was macht Stretch anders als Buster. Und das kann man nur herausfinden wenn man die ausgaben vom dmesg vegleicht.

[willy4711]

Was ist eigentlich mit firmware-realtek
Gab mal einen Thread: https://debianforum.de/forum/viewtopi ... 0&t=159157
wo mit dmesg auch die Ausgabe kam:

rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin

Hinterher stellte sich heraus, dass firmware-realtek gar nicht installiert war.
Allerdings gab es da auch die vollständige Ausgabe von dmesg

[habakug]

Hallo,

ist die Firmware-Datei nicht vorhanden, wie in dem anderen Thread, ist die Ausgabe so:

Code: Alles auswählen

[ 6053.094761] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 6053.094801] usb 1-10: firmware: failed to load rtlwifi/rtl8192cufw_TMSC.bin (-2)

Hier ist es aber:

Code: Alles auswählen

[ 6422.449194] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 6422.482032] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin

Die Datei ist vorhanden.

Gruss, habakug

[willy4711]

@habakug
Hast recht- habe ich übersehen.
Dann bleibt nur, zu warten bis mal eine vollständige Ausgabe von dmesg kommt.

Und inxi mit eingestecktem Stick.

Denn wie ich das nachvollziehe, war die Ausgabe von inxi auch ohne Stick.

Nur nochmal für smack9898 wie eine vollständige Sequenz aussehen sollte (hier allerdings Ethernet-Stick)
Eingabe als root:

Code: Alles auswählen

dmesg -w

dann erst den Stick einstecken, die Ausgabe beginnt dann wie beim mir (ähnlich)

Code: Alles auswählen

[   93.534272] usb 1-4: new high-speed USB device number 7 using xhci_hcd
[   93.689243] usb 1-4: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 1.00
[   93.689250] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   93.689255] usb 1-4: Product: AX88179
[   93.689260] usb 1-4: Manufacturer: ASIX Elec. Corp.
[   93.689264] usb 1-4: SerialNumber: 0000000000016A
[   94.049652] ax88179_178a 1-4:1.0 eth1: register 'ax88179_178a' at usb-0000:00:14.0-4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 74:da:38:a0:06:d6
[   94.049716] usbcore: registered new interface driver ax88179_178a
[   94.077315] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   94.409639] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   97.164004] ax88179_178a 1-4:1.0 eth1: ax88179 - Link status is: 1
[   97.171454] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

--- oder es kommen halt Fehlermeldungen.

noch eine Möglichkeit:

Code: Alles auswählen

# dmesg |grep -E 'rtl|IPv'

[KBDCALLS]

Übrigens die Datei /var/log/dmesg ist leer , bis auf folgenden Text. Find ich etas merkwürdig.

• Code: Alles auswählen

  (Nothing has been logged yet.)

[rendegast]

Übrigens die Datei /var/log/dmesg ist leer , bis auf folgenden Text. Find ich etas merkwürdig.

Unter sysv schreibt init-Skript bootlogd 'dmesg' nach /var/log/dmesg,
unter systemd ist bootlogd maskiert

Code: Alles auswählen

$ ll /usr/lib/systemd/system/*bootlogd* | cat
lrwxrwxrwx 1 root root 9 Nov 17 23:08 /usr/lib/systemd/system/bootlogd.service -> /dev/null
lrwxrwxrwx 1 root root 9 Nov 17 23:08 /usr/lib/systemd/system/stop-bootlogd-single.service -> /dev/null
lrwxrwxrwx 1 root root 9 Nov 17 23:08 /usr/lib/systemd/system/stop-bootlogd.service -> /dev/null

[smack9898]

iwlist ist in den wireless-tools enthalten. Sind die nicht drauf installieren.

Poste mal

• Code: Alles auswählen

  dmesg --human -w 

Den Stick dabei enstecken und wieder entfernen. Aber das dann aber nach NoPaste Aber komplett.

Ok, sorry es hat etwas länger gedauert bis ich wieder jemand an die Kiste bekam.
Aber hier ist das neuste update
http://nopaste.debianforum.de/40541

[smack9898]

[ 6422.482032] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin

Du postestst immer nur das, von dem du meinst, es posten zu müssen.
Wenn du einen USB-Stick (hier dein WLAN- Stick) einsteckst, erzählt dmesg einiges mehr, als du uns hier zu sehen gibst.
Aber selbst danach hat er ja Firmware geladen. (nämlich die rrtl8192cufw_TMSC.bin)

Also lass dmesg laufen, merke dir den Punkt, wenn du den Stick einsteckst und poste dann bitte alles war ab diesen Punkt ausgegeben wird. Dann sollte auch die ID der Hardware zu erkennen sein.

Es ist auch mehr als unwahrscheinlich, dass ein Gerät, dessen Firmware geladen wird, nirgends , auch bei der Ausgabe von inxi nicht erscheint.

Sehr genaue Auskunft bei zwei Netzwerk- Controllern sollte

Code: Alles auswählen

$ inxi -v 8 |grep Network: -A14

geben

Hier kommt noch ein weiteres bzw update.
welches villeicht ein Schritt in die richtige Richtung sein lönnte.
http://nopaste.debianforum.de/40542

[KBDCALLS]

Anscheinend ist das Trouble. mit dem Timer. Es gibt hier

• https://github.com/lwfinger/rtl8192cu

einen Fix für dieses Problem wenn ich da richtig liege. Ich würde mal testweise versuchen ob sich der Kernel von Stretch mit Buster noch verwenden läßt. Oder falls das nicht so ohne weiteres klappt einen von

• http://snapshot.debian.org

.bis maximal 4.14. Nach den Kommentaren auf Github soll der Timer Fix für Kernel ab 4.15 sein.

Ob der Treiber im Kernel selbst schon gefixt entzieht sich meiner Kenntnis.

[habakug]

Hallo,

laut Log ist der Stick betriebsbereit:

Code: Alles auswählen

wlx00ab7245994a: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 26:b1:cf:b1:95:36 brd ff:ff:ff:ff:ff:ff

Gruss, habakug

[KBDCALLS]

Hallo,

laut Log ist der Stick betriebsbereit:

Code: Alles auswählen

wlx00ab7245994a: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 26:b1:cf:b1:95:36 brd ff:ff:ff:ff:ff:ff

Gruss, habakug

No Carrier passt dazu aber nicht.

Und das ist auch etwas seltsam

• Code: Alles auswählen

  [Dec23 20:12] rtl8192cu: Chip version 0x10
  [  +0.046186] rtl8192cu: Board Type 0
  [  +0.000069] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
  [  +0.000078] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
  [  +0.072199] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin
  [  +0.512661] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
  [  +0.000676] usbcore: registered new interface driver rtl8192cu
  [  +0.277201] rtl8192cu 1-3:1.0 wlx00ab7245994a: renamed from wlan0
  [  +0.797433] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.013602] rtl8192cu: MAC auto ON okay!
  [  +0.020392] rtl8192cu: Tx queue select: 0x05
  [  +1.119886] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.023746] rtl8192cu: MAC auto ON okay!
  [  +0.012301] rtl8192cu: Tx queue select: 0x05
  [  +1.232294] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.276277] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +6.752085] usb 1-3: USB disconnect, device number 3
  [  +0.000367] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x67
  [  +0.000013] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x1e0000
  [  +0.000013] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut! status:0xffffffed value=0xd38000
  [  +0.000038] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x437
  [  +8.607211] usb 1-3: new high-speed USB device number 4 using xhci_hcd
  [  +0.149019] usb 1-3: New USB device found, idVendor=0bda, idProduct=8176, bcdDevice= 2.00
  [  +0.000012] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  [  +0.000008] usb 1-3: Product: 802.11n WLAN Adapter
  [  +0.000007] usb 1-3: Manufacturer: Realtek
  [  +0.000006] usb 1-3: SerialNumber: 00e04c000001
  [  +0.009564] rtl8192cu: Chip version 0x10
  [  +0.036845] rtl8192cu: Board Type 0
  [  +0.000109] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
  [  +0.001154] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
  [  +0.013392] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
  [  +0.017914] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin
  [  +0.132330] rtl8192cu 1-3:1.0 wlx00ab7245994a: renamed from wlan0
  [  +0.115022] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.028340] rtl8192cu: MAC auto ON okay!
  [  +0.039443] rtl8192cu: Tx queue select: 0x05
  [  +1.513282] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.020872] rtl8192cu: MAC auto ON okay!
  [  +0.012365] rtl8192cu: Tx queue select: 0x05
  [  +1.042918] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  [  +0.082380] IPv6: ADDRCONF(NETDEV_UP): wlx00ab7245994a: link is not ready
  

Der Stick wird erkannt funktioniert aber nicht.

• link is not ready

• 40541

[habakug]

Hallo,

was passiert denn nach einem

Code: Alles auswählen

# ip link set wlx00ab7245994a up

?

Gruss, habakug

[smack9898]

Ich habe jetzt mal das githhub packet eingebuden
https://github.com/lwfinger/rtl8192cu
Die Kiste neugestartet und den Stick rausziehen und wieder rein steckenlassen.

Daraufhin bekam ich folgendes zurück

Code: Alles auswählen

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Als nächstes habe ich die Kiste mit den wlan verbunden

Code: Alles auswählen

 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c0:3f:d5:66:fb:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.5/24 brd 192.168.2.255 scope global dynamic noprefixroute enp3s0
       valid_lft 13838sec preferred_lft 13838sec
    inet6 2405:6583:2300:500:9067:7b71:7b78:dbbe/64 scope global temporary dynamic
       valid_lft 13839sec preferred_lft 12039sec
    inet6 2405:6583:2300:500:c23f:d5ff:fe66:fbae/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 13839sec preferred_lft 12039sec
    inet6 fe80::c23f:d5ff:fe66:fbae/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlx00ab7245994a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:ab:72:45:99:4a brd ff:ff:ff:ff:ff:ff
    inet 192.168.188.23/24 brd 192.168.188.255 scope global dynamic noprefixroute wlx00ab7245994a
       valid_lft 863558sec preferred_lft 863558sec
    inet6 fe80::718c:b622:1a51:4ca8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Und die Verbindungen funktionieren auch nach einen weiteren Neustart von der Kiste!

Massiven vielen dank Leute!
smack9898