Kernel <= 5.5.9 mit USB Bug

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.

 

RDP: Remmina wird per Update brauchbar

Kleiner Nachbrenner zu RemoteDesktop mit XRDP & XFreeRDP . Vor einigen Tagen gab es ein Update von Remmina, womit es zum fast idealen RDP Clienten unter Linux wird.

Remmina wird per Update brauchbar

Vor einigen Tagen gab es ein Update von Remmina und da ich das schon im Test hatte, es aber mangels Funktion nicht einsetzbar war, habe ich Euch xFreeRDP empfohlen. Das ist auch weiterhin der Favorit, wenn  es verscriptet werden muß.am sieht im Hintegrund bereits den eingeloggten RDP Desktop und im Vordergrund die Basiseinstellungen von Remmina für diese Verbindung.

Remmina hat aber mit dem Update den Schritt auf meine Festplatte geschafft, weil es nämlich in seiner brauchbaren GUI-Oberfläche für jede Verbindung auch gleich einen SSH Tunnel anbietet. Da man auch einen Gatewayserver mit angeben kann, sind selbst komplexe RDP Setups kein größeres Problem mehr, wenn, ja wenn das Wörtchen Wenn nicht wäre.man sieht das Konfiguratiosnfenster von Remmiona das sich mit SSH Optionen beschäftigt.

Es gibt leider keine brauchbare, geschweige denn, belastbare Doku aus den man den Sinn dieser Optionen erfährt. Die Webseite zeigt zudem Screenshots, die schon lange überholt sind. Auch gibt es dort Anleitungen, die mangels der passenden Optionen nicht mehr klappen können, dafür sind Optionen ohne Contexthilfe, Mouseovertext oder sonstiger Hilfe vorhanden.

Das macht natürlich keinen so guten Eindruck. Auch wenn xFreeRDP  keine UI hat, stimmt hier wenigstens die Manpage.  Im Vollbildschirm ist gibt es eine schöne intelligente Leiste, die sich reinrollt, wenn man den Mauszeiger darüber bewegt. Die gleiche Funktionalität kennt man von TeamViewer oder der Windows-RDP Clienten. Daher kann ich das Programm jetzt zwar als sehr brauchbar einstufen, aber benutzerorientiert geht leider anders. Ich bin aber überzeugt, daß es auch ohne (aktuelle) Bedienungsanleitung gerade im Adminbereich viele Anhänger finden wird und schon hat(wie man so lesen kann). Der Verbindungsmanager ist halt unheimlich praktisch.

MS-Blog: 0,095 Spams pro Empfänger…

Mal sehen, wem das auffällt.. Microsoft hat in einem Blog zur Botnetz-Bekämpfung folgenden Satz gelassen:

„The Necurs botnet is one of the largest networks in the spam email threat ecosystem, with victims in nearly every country in the world. During a 58-day period in our investigation, for example, we observed that one Necurs-infected computer sent a total of 3.8 million spam emails to over 40.6 million potential victims.“

Das ist selbst für Microsoft sehr schwach… das wären nämlich nur 0.095 Spams pro Empfänger, was nicht geht 🙂

Eine noch schwächere Leistung hat, IMHO, allerdings Heise vollbracht, als die diese Zahlen aus dem Blog ungeprüft übernommen haben. (Stand 0:00 Uhr)

Kleine Profi Info: 3.8 Millionen Spams in 58 Tagen sind ein Witz… ich hab schon 450.000 Mails in einer Nacht gesehen, und das ist Jahre her 🙂 Bin mal gespannt, ob das noch wer berichtigt.

Nachtrag: Falls das M$ Blog 3.8 Millionen Spams an jeweils 40.6 Millionen Empfänger gemeint hatte, das wäre eine Hausnummer die ziemlich heftig wäre.  Aber davon hätte man gehört, wenn bei Leuten so viele Spams aufgelaufen wären. Das sind mehr Emails, als ich hin 20 Jahren angesammelt habe 🙂

Quelle: https://blogs.microsoft.com/on-the-issues/2020/03/10/necurs-botnet-cyber-crime-disrupt/

Quelle: https://www.heise.de/newsticker/meldung/Microsoft-und-Partner-zerschlagen-riesiges-Botnet-Necurs-4680665.html