Fedora 34: Wenn Wifi weg ist…

Wenn das Wifi auf einem Tablet nicht mehr geht, ist man gewöhnlicherweise am Allerwertesten, aber es gibt vielleicht Hilfe für Euch.

Fedora 34: Wenn Wifi weg ist…

Mein Surface Tablet war mal wieder dran mit seinem Update, weil Netflix mit dem „alten“ Firefox von vor 3 Wochen nicht mehr spielen möchte, also gab es das sowieso fällige Fedora 34 Update. Das hätte ich besser nicht gemacht, denn nun habe ich Gnome 40+ und mein Tablet ist jetzt gehandycrapt. *sniff*

Aber bevor das neue Gnome überhaupt zum Problem werden konnte, überraschte mich Fedora 34 damit, daß mein Tablet kein Wifi mehr hatte, dabei hatte ich gar keinen neuen Kernel benutzt, sondern den gleichen Surface Kernel gebootet, wie sonst auch.

Bei näherer Betrachung stellte ich das hier raus:

Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: enabling device (0000 -> 0002)
Dez 18 13:59:00 surface kernel: mwifiex_pcie: try set_consistent_dma_mask(32)
Dez 18 13:59:00 surface kernel: mwifiex_pcie: PCI memory map Virt0: 00000000938ad086 PCI memory map Virt2: 0000000061c369a5
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: Direct firmware load for mrvl/pcie8897_uapsta.bin failed with error -2
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: Failed to get firmware mrvl/pcie8897_uapsta.bin
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: info: _mwifiex_fw_dpc: unregister device

Und jetzt steht Ihr da genauso wie ich. WTF is pcie8897_uapsta.bin? ok, eine Firmware für den Chip. Soweit so gut. Aber wieso kann der Kernel das File (das in dem Listing unten) nicht mehr laden??

[ ~]$ ls -la /usr/lib/firmware/mrvl
insgesamt 5320
drwxr-xr-x. 3 root root 4096 30. Nov 21:18 .
drwxr-xr-x. 102 root root 36864 2. Dez 09:11 ..
-rw-r–r–. 1 root root 444052 28. Okt 15:33 pcie8897_uapsta.bin.xz
-rw-r–r–. 1 root root 287784 28. Okt 15:33 pcie8997_wlan_v4.bin.xz
-rw-r–r–. 1 root root 388188 28. Okt 15:33 pcieuart8997_combo_v4.bin.xz
-rw-r–r–. 1 root root 392276 28. Okt 15:33 pcieusb8997_combo_v4.bin.xz
drwxr-xr-x. 2 root root 4096 30. Nov 21:18 prestera
-rw-r–r–. 1 root root 165260 28. Okt 15:33 sd8688.bin.xz
-rw-r–r–. 1 root root 1804 28. Okt 15:33 sd8688_helper.bin.xz
-rw-r–r–. 1 root root 330112 28. Okt 15:33 sd8797_uapsta.bin.xz
-rw-r–r–. 1 root root 164668 28. Okt 15:33 sd8801_uapsta.bin.xz
-rw-r–r–. 1 root root 377276 28. Okt 15:33 sd8887_uapsta.bin.xz
-rw-r–r–. 1 root root 439804 28. Okt 15:33 sd8897_uapsta.bin.xz
-rw-r–r–. 1 root root 370612 28. Okt 15:33 sdsd8977_combo_v2.bin.xz
-rw-r–r–. 1 root root 381952 28. Okt 15:33 sdsd8997_combo_v4.bin.xz
-rw-r–r–. 1 root root 297988 28. Okt 15:33 usb8766_uapsta.bin.xz
-rw-r–r–. 1 root root 342532 28. Okt 15:33 usb8797_uapsta.bin.xz
-rw-r–r–. 1 root root 162968 28. Okt 15:33 usb8801_uapsta.bin.xz
-rw-r–r–. 1 root root 446100 28. Okt 15:33 usb8897_uapsta.bin.xz
-rw-r–r–. 1 root root 371036 28. Okt 15:33 usbusb8997_combo_v4.bin.xz

Ja… das dauert ne Weile, deswegen langweile ich Euch ( grummel…neuer xz algo… brabbel ) nicht damit und komme zum Wesentlichen: xv -d pcie8897_uapsta.bin.xz ; reboot  \o/ GEHT \o/

Als erstes sucht der Kernel nach der ungepackten Version der Firmware, wenn es die nicht gibt, dann nimmt er auch eine gepackt. Leider gabs da wohl ein Update und der bisherige Kernel kann die XZ komponente zum Entpacken nicht mehr benutzen und damit die Firmware nicht mehr laden. Durch das Auspacken der Firmware nimmt das mehr Platz weg, aber kann wieder geladen werden. Hat man dazu Worte? 🙁

Zahn der Zeit nagt am Linuxsupport von Brother

Das bislang vorbildliche Verhalten von Brother im Bezug auf Linux zeigt leider erste Schwachstellen. Kann man die Druckerfunktion über Netz noch ohne Brothertreiber realisieren, muß man für die Scannerfunktion der MFC Serien auf BRScan von Brother zurückgreifen.

Linuxsupport von Brother schwächelt zusehens

Von dem Umstand mal abgesehen, daß von Brother genutzte SAP wohl was gegen Kontaktformularanfragen hat 🙁 , sind die Webseiten von Brother was Handbücher und Treiber betrifft eigentlich ganz brauchbar. Leider kann man das von der Scansoftware nicht mehr sagen.

Die auf dem Stand 2017 kompilierte Scansoftware Brscan braucht dringend ein Update, da die verwendete libnsl u.a. von Fedora nur noch als Legacy angeboten wird und nicht mehr zum festen Systemumfang zählt. Das führt dann leider dazu, daß auch wenn man Brscan vorschriftsmäßig über das von Brother gelieferte Softwarepaket für redhatbasierte Systeme installiert, Xsane oder SimpleScan  die Scanner im Netzwerk (und vermutlich lokal auch) nicht finden.

Schuld daran ist ein „Ich hab Dir doch gesagt, ich brauche diese nsl Library“ Fehler in Brscan. Leider eskaliert das Programm den Fehler nicht an die Oberfläche, so daß der Otto-Normal-Tux keine Chance hat, da den Fehler zu finden. Dieser wird erst sichtbar, wenn ein Admin die passenden Programme von Brother direkt in der Konsole startet. Da diese Programme nicht für den Desktop geschrieben wurden, tauchen sie natürlich auch nicht im Desktop-Menü auf. Es besteht daher keine Chance, daß ein Endanwender das je findet.

Fix für Fedora u.ä.

Jetzt kann man das noch unter Fedora, und vermutlich allen anderen RH Systemen, mit dem folgenden Befehl als Rootuser leicht beheben:

dnf install -y libnsl

Es spielt dabei keine Rolle, ob Ihr Brscan vorher oder danach installiert, das Ergebnis ist das Gleiche.

Wichtig für Netzwerkdrucker ist nur, daß Ihr bei der Frage des Installationsscripts, welches auch als Root ausgeführt werden muß, die korrekte IP des Druckers/Scanners angebt. Ein Problem könnte sich dabei ergeben, wenn Euer DHCP Server im lokalen Netz dem Scanner IPs zufällig zuordnet, statt diese dauerhaft zu vergeben.

Sollte das der Fall sein, liegt eine Config Datei im /usr-Bereich der Brscan-Software, welche die IP Angabe enthält. Die müßte man dann anpassen.

Aktive Hardwaretreiber ermitteln

Wer kennt das nicht, das Laptop läuft unrund, erkennt vielleicht den WLAN Chip nicht mehr sauber und man möchte den Treiber ersetzen.

Erste Frage: Woher weiß man, welcher Treiber überhaupt zuständig ist ?

Dazu gibt es den wirklich tollen Befehl „lshw“ , den wir hier nur auf das Netzwerk ansetzen. Er kann aber auch alle andere HW ermitteln, einfach das -C Network  weglassen.

$  lshw -C Network
  *-network                 
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 09
       serial: 40:16:7f:22:5b:43
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168f-1_0.0.5 06/18/12 ip=192.168.0.99 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:45 ioport:d000(size=256) memory:d2104000-d2104fff memory:d2100000-d2103fff
  *-network:0
       description: Ethernet interface
       physical id: 1
       logical name: virbr0
       capabilities: ethernet physical
       configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=192.168.122.1 link=no multicast=yes
  *-network:1 DISABLED
       description: Ethernet interface
       physical id: 2
       logical name: virbr0-nic
       serial: 52:54:00:0a:cf:07
       size: 10Mbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s

In Fett finden sich hier die Angaben zu den Treiber:

driver=tun driverversion=1.6
driver=bridge driverversion=2.3
driver=r8169 driverversion=2.3LK-NAPI

„tun“ ist der Tunneltreiber, also zum Aufbau von VPN Tunneln aller Art, „bridge“ ist für die Virtualisierungsbrücke, also wenn man per Boxen, VirtualBox oder KVM virtuelle Maschinen betreibt und „r8169“ ist dann endlich der RealTek Treiber für meine Netzwerkkarte. Je nach verbauter Hardware bekommt Ihr hier natürlich andere Treiber angezeigt.

Kurz Verifizieren:

# lsmod | grep r8169
r8169                  81920  0
mii                    16384  1 r8169

„lsmod“ zeigt die geladenen Kernelmodule an und nach unserem Treiber gefragt, sagt es, daß das Modul mii diesen Treiber einmal geöffnet hat. „mii“ ist ein Standard für Netzwerkkarten. Entsprechend benannt sind die mii-tools: u.a.

# mii-tool enp2s0
enp2s0: negotiated 1000baseT-HD flow-control, link ok

Die können natürlich noch viel mehr machen.

Wo findet man diesen Treiber jetzt ?

Unter /usr/lib/modules liegen sämtliche Kernelmodule nach kernels gruppiert, also suchen wir dort :

# find  /usr/lib/modules -name „*r8169*“
/usr/lib/modules/4.8.6-201.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
/usr/lib/modules/4.8.7-200.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
/usr/lib/modules/4.8.4-200.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

„ko“ steht für „kernelobject“ und „.xz“ ist ein einfacher Kompressionsalgorithmus, damit die Treiber nicht so viel Platz wegnehmen.  Jetzt darf man nicht auf die Idee kommen, daß wenn der Treiber im einen Kernel defekt ist, man einfach die Datei von einem alten Kernel kopiert, das klappt nicht 🙂 Selbst kompilieren ist angesagt, und das ist leider ein anderes Thema.

Das Ganze hier kann natürlich nur klappen, wenn der Treiber überhaupt funktioniert.

Wie bekommt man jetzt raus, welcher Treiber der richtige wäre, wenn er denn ginge ?

Der einfachste Weg: Linux Livedisk auf einen USB Stick ziehen, davon Booten und mit lshw nachsehen, was das System dazu meint. Die Treiber in den Livedisks sind i.d.R. etwas sagen wir mal „robuster“ gewählt. Ist natürlich keine Garantie. Ich empfehle auch eine Distro Livedisk zunehmen,  die entweder komplett anders ist als die auf dem System Distro installierte, oder viel neuer bzw. älter ist. Die Chance eine andere Treiberversion zu bekommen, ist dann einfach höher.

Es kommt leider mal vor, daß ein Patch für eine Chipserie eines Herstellers, den Support für ganz alte Chips entfernt oder daß die Initialparameter zum Ansteuern des älteren Chips mit Werten neuerer Chips der gleichen Serie ausgetauscht wurden. Das passiert einfach und ist keine böse Absicht des Herstellers Eurer Distro. Die Versuchen es halt auf soviel wie möglich Laptops/Mainboards zum Laufen zu bringen.

Wenn man erstmal eine funktionierende Version gefunden hat, kann man sich aus den dazugehörigen SOURCEN einen funktionierenden Treiber kompilieren und den dann auch im System laden. Idealerweise würde man den anders nennen, als den aus der Distro, so daß man den paralell installiert haben kann, ohne das er gleich wieder übergenagelt wird.

Treiber kann man im System üblicherweise beim Booten per Kernelparameter blacklisten, so das die nicht geladen werden, auch wenn sie vorhanden sind. Man trägt dann seinen eigenen Treiber in die /etc/modprobe.conf ein und der wird dann beim Start geladen. Dummerweise muß man den Treiber für jeden Kernel neu bauen. Kleiner Tip, schaut Euch mal AKMODS an, die bauen sich bei Updates selbst zusammen, wenn ein Treiber fehlt.