Wine-Staging64 6.12 erschienen – Heftiger Bug im TCP/IP Stack

Am eigenen Leibe habe ich gerade erfahren müssen, daß das Wine-Staging64 Update auf 6.12 einen schweren Fehler im TCP/IP Stack enthält.

Wine-Staging64 6.12 erschienen – Heftiger Bug im TCP/IP Stack

Man sollte annehmen, daß es sofort beim Testen einer neuen Version auffällt, wenn man mit dem Internet keine Verbindung aufbauen kann. Tja.

Nach dem heute morgen durchgeführten Update von 6.11-5 auf 6.12-1 der experimentellen Staging Version, die zugegebenermaßen per Definition eine Entwicklerversion ist, kam es aus Sicht der Anwendung zum Ausfall des Internets, weil keine Server mehr erreicht werden können.

Das sieht dann so aus:

dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:08:05.773227 IP 192.168.0.34.57894 > 194.187.19.180.80: Flags [S], seq 2759647570, win 64240, options [mss 1460,sackOK,TS val 831085749 ecr 0,nop,wscale 7], length 0
E..<2.@.@.p....".....&.P.|.R.........h.........
1.\.........
15:08:05.773984 IP 192.168.0.34.57896 > 194.187.19.180.80: Flags [S], seq 2488347596, win 64240, options [mss 1460,sackOK,TS val 831085750 ecr 0,nop,wscale 7], length 0
E..<.y@.@..	...".....(.P.Q+..........h.........
1.\.........
15:08:05.774671 IP 192.168.0.34.57898 > 194.187.19.180.80: Flags [S], seq 3242501228, win 64240, options [mss 1460,sackOK,TS val 831085751 ecr 0,nop,wscale 7], length 0
E..<&.@.@.}....".....*.P.D.l.........h.........
1.\.........
15:08:05.794930 IP 194.187.19.180.80 > 192.168.0.34.57894: Flags [S.], seq 114763427, ack 2759647571, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 97248822 ecr 831085749], length 0
E..<?.@.y.*........".P.&..&..|.S.. ........d.......
...61.\.
15:08:05.794945 IP 192.168.0.34.57894 > 194.187.19.180.80: Flags [R], seq 2759647571, win 0, length 0
E..(..@.@......".....&.P.|.S....P...._..
15:08:05.795624 IP 194.187.19.180.80 > 192.168.0.34.57896: Flags [S.], seq 1794556337, ack 2488347597, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 97249931 ecr 831085750], length 0
E..<F.@.y.#........".P.(j....Q+... .C/.....d.......
....1.\.
15:08:05.795628 IP 192.168.0.34.57896 > 194.187.19.180.80: Flags [R], seq 2488347597, win 0, length 0
E..(..@.@......".....(.P.Q+.....P...v...
15:08:05.796216 IP 194.187.19.180.80 > 192.168.0.34.57898: Flags [S.], seq 2891142575, ack 3242501229, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 97248822 ecr 831085751], length 0
E..<?.@.y.*........".P.*.SU..D.m.. ........d.......
...61.\.
15:08:05.796218 IP 192.168.0.34.57898 > 194.187.19.180.80: Flags [R], seq 3242501229, win 0, length 0
E..(..@.@......".....*.P.D.m....P....y..

Wer das nicht lesen und verstehen kann, dem sei es kurz erklärt:

Normalerweise…

Normalerweise sendet ein TCP/IP Stack zum Aufbau einer Verbindung 1 SYN Paket zum Server, der bestätigt das mit einem SYN-ACK und dann kann der Client mit einem Push Paket Daten schicken.

Im obigen Fehlerfall sendet der Wine-Stack  sofort parallel 3 SYN Pakete mit 3 verschiedenen SessionIDs los.
Der Server schickt für alle 3 SYN jeweils den passenden SYN-ACK. jetzt hat aber der Stack als letztes die 3. SessionID benutzt, es kommt aber zuerst ein SYN-ACK für die 1.SessionID rein. Die Folge: die SessionIDs passen nicht zusammen, der Wine-Stack schickt korrekterweise ein RESET zum Server und legt auf.

Das mit den 3 SYN Paketen ist zwar vorgesehen, aber nicht parallel, sondern nach einander. Es ist nämlich der Versuch auf ein nicht beantwortetes 1. oder 2. SYN doch noch ein ACK vom Server zu bekommen, wenn z.b. durch Stau über Überlastung im Netz SYN Pakete verloren gegangen sind.  Natürlich wartet ein Stack zwischen diesen Versuchen eine Zeit lang, was aber bei 6.12. nicht der Fall ist und das ist hier der Fehler.

In den Commits für 6.12 kann man auch erahnen, wo das das Problem eingebaut wurde. Bugreport ist raus 🙂

Lösung:

Downgrade auf 6.11-5 und alles ist wieder gut 🙂

Warum schreibt man jetzt deswegen einen Blogartikel?

Weil man die Stagingversion für einige Spiele braucht um z.b. Vulkantreiber zu benutzen oder andere Anpassungen an Wine braucht, damit Spiele funktionieren. Es ist eben doch nicht eine reine Entwicklerversion 😉

 

Linux: Mysteriöse Soundstörungen auf ASROCK B550µ Pro4

Wie in dem Beitrag „Wie man von einer nachgerüsteten NVME SSD bootet“ schon erzählte, mein PC hat neue Eingeweide. Vermutlich führte ein kleiner Fehler beim Zusammenbau zu eine heftigen Fehler von Pulseaudio.

Linux: Mysteriöse Soundstörungen auf ASROCK B550µ Pro4

An Tag 1 meines neuen PCs war die Welt noch in Ordnung. Der neue Ryzen 5600X funktionierte wie gewünscht, sau schnell, leise, ohne zu murren. 3D Spiele 1a, Ton supergeil. Leider nicht lange 🙁

An Tag 2 brach nach 3 Stunden die Tonhölle los. Die Audiogeräte des Mainboard flappten(wechselten den Status) im Zehntelsekundentakt zwischen „da“ und „nicht da“ und das über Stunden! Nichts half, kein Neustart von PulseAudio, kein Reboot des PCs. Da es scheinbar nichts besonderes ist einen defekten RealTek Soundchip (ALCS1200A) auf dem Mainboard zu haben, gibt es im Soundtreiber jede Menge Anpassungsoptionen um diverse Bugs der Chips und Mainboards zu umgehen.. Half auch nichts.

Vom Fehlerbild her sah es so aus, also wenn jemand mehrfach pro Sekunde den Kopfhörer in den Port steckte und wieder abzog. Dieser schnelle Wechsel wird im IT-Denglishjargon als „Flapping“ bezeichnet, wie bei einem Kolibriflügelschlag. Damit das mit dem Kopfhörer richtig funktioniert gibt es im Mainboardconnector einen Pin namens „Jack_SENSE“. „Jack“ ist die Amibezeichnung für Buchse. Wenn der Pin also Blödsinnssignale bekommt, dann reicht der das an ALSA weiter und das reicht es an PulseAudio durch und das flappt dann wie blöde die Ports hin und her. Das ist meine Theorie.

Falsche Portbelegung als Ursache?

Daher habe ich mir die Beschaltung des Mainboardconnectors noch mal genauer angesehen und im Handbuch zum Mainboard eine explizite Anweisung gefunden.. ja, Handbuch, sowas gibts noch 😉 … die eine bestimmte Beschaltung des internen Mainboard HD-AUDIO Connectors vorsieht, für den Fall, daß man KEIN HD-AUDIO Gehäuse hat und auf AC’97 Beschaltung zurückgreifen muß ( erkennbar z.b. am Mono-Micro Eingang ).

Also änderte ich die Belegung des Connectors entsprechend der Anweisung und seit dem ist Ruhe.

Hoffen wir mal, daß es dabei bleibt.

Das könnte Euch aus interessieren:

Wie man von einer nachgerüsteten NVME SSD bootet

Wie man von einer nachgerüsteten NVME SSD bootet

Meine langjährige Linux-Notlösung ging letzte Woche eine innige Verbindung zwischen Mainboard und Netzteil ein, das führte leider zu neuer PC-Hardware, wovon Ihr jetzt allerdings profitiert 😉

Wie man von einer nachgerüsteten NVME SSD bootet

Hier eine Impression der neuen permanenten Verbindung zwischen Mainboard und Netzteil:

ATX 12V Leitung ins Mainboard

Nur mit Gewalt konnten Buchse und Stecker getrennt werden. Eine Inspektion ergab dann, daß drei Spannungswandler, die befinden sich unter dem Kühlkörper links im Bild, ein bisschen zu warm geworden sind.

Hinweis: Für alle Linux am Dienstag Teilnehmer, abweichend zum gestrigen Textchat, gibt es bei den Anweisungen für die UUIDs noch eine kleine Erweiterung wo man die ersetzen muß.

Der neue RYZEN 5600X

Weil ich mir gleich was vernünftiges kaufen wollte, kam ein ASROCK B550µ Pro4 und ein RYZEN 5600X in den Warenkorb, noch NVME SSD (Samsung 1TB), RAM und Netzteil dazu gepackt und beim Großhändler sammeln lassen.

Das Board kannte ich einem früheren Einkauf und entsprechend wußte ich, daß diese Hardware mit Linux  laufen würde. Laufen ist in dem Fall übrigens glatte Untertreibung, Rennen wäre treffender, weil die NVME SSD in dem Setup 7 GB/s lesend schafft 😀

Da ich den PC für die Arbeit brauchte, war ein funktionierendes System an Tag 1 erst einmal wichtiger, als von der NVME SSD booten zu können, also wurde die HW nur zusammen gesteckt und die alte SATA SSD gebootet. Lief sofort ohne zu murren. Der Arbeitstag neigte sich dem Ende zu, also war es Zeit die SATA SSD auf die NVME SSD zu clonen und die Umstellung zu machen.

Nun ist mein Fedora System von 2014 und dessen Bootconfig weiß noch nichts von NVME. Also muß man das erst nachrüsten und ein Initramfs bauen, daß auch passende NVME Treiber hat. Dummerweise wusste ich das nicht, als die ich die SSD geclont habe 🙁 Ergebnis: „Geil, bootet von NVME .. ähhhhhh!?!?!“ Weil der Bootprozess vor dem Entschlüsseln der LUKS Paritionen einfach stehen blieb.

Zwei Möglichkeiten

Entweder VOR dem Clonen das neue Initramfs bauen, was deutlich einfacher ist, oder nochmal von der alten SSD Booten, Initramfs neubauen und die erzeugten Files von Hand rüberkopieren.

So, oder so, sieht der richtige Weg so aus:

  1. NVME-Treiber hinzufügen

    echo „add_drivers+= \“ nvme \““ > /etc/dracut.conf.d/nvme.conf
    # initramfs für aktiven Kernel neubauen
    dracut -f
  2. Disk Clonen

booten von einem Livestick
sudo su
dd if=/dev/quelle of=/dev/nvme0n1 bs=64M status=progress

Bei einer 1 TB SSD dauert das so 21-23 Minuten, da die SATA Geräte auf den meisten PCs mit 6 Gb/s angebunden sind, was ein theoretisches Maximum von 512 MB/s erlauben würde, aber 480 MB/s sind realistischer 😉

Wenn man die alte Platte nicht mehr benutzen will ist hier Schluß, die Platte muß dann aber auch gleich vom PC entfernt oder neu formatiert werden. Wieso, wird gleich klar werden.

Oder Ihr wollt mal wissen, was der Onkel Doktor machen müßte um die neue NVME SSD parallel zur alten SATA SSD booten zu können 🙂 Wir haben die Platte geclont und damit auch alle UUIDs zur identifizierung von Partitionen und Containern. UUIDs zeichnen sich durch eine gewisse EINMALIGKEIT aus, sprich, doppelte UUIDs produzieren lustige Fehler beim Bootprozess 😀

Gestern beim Linux am Dienstag kam die Frage auf, wieso ich nach dem Clonen nicht einfach die SATA SSD platt gemacht habe: Redundanz. Fällt die NVME SSD aus, habe ich noch ein System, das garantiert bootet.

Wie man die UUIDs von LUKS und EXTx ändert

Der Einfachheit

halber nehmen wir das „Gnome-Laufwerke“ Tool zur Hand um die alten UUIDs zuermitteln, da wir da visuell sehen können, ob das auch die richtige Partition ist. Man kann das auch in der Konsole ablesen, aber das kann leicht zu Verwechselungen führen:

$ lsblk -t -f
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
nvme0n1 0 512 0 512 512 0 none 1023 128 0B 
├─nvme0n1p1 0 512 0 512 512 0 none 1023 128 0B ext4 1.0 Boot 4d2061ec-d538-4c88-aeb7-3fb0f3f4cd07 234,6M 46% /boot
├─nvme0n1p2 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 9d2595b2-a35c-48c1-a839-bb54c1a96597 
│ └─luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 0 512 0 512 512 0 128 128 0B ext4 1.0 9d2595b2-a35c-48c1-a839-bb54c1a96597 659,9G 22% /
└─nvme0n1p3 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 
  └─luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 0 512 0 512 512 0 128 128 0B swap 1 46da0d80-21fb-45b7-8567-ba047de66cb6 [SWAP]

Einfacher ist das über das GNOME Laufwerke Tool:

LUKS

Filesystem in eine LUKS Container

Schritt 1 wäre jetzt auch erst einmal neue UUIDs zu erzeugen, was unter Fedora leicht mit dem Befehl „uuidgen“ gemacht werden kann. Andere Distro haben den Befehl nur als „uuid“ im Angebot.

WARNUNG:
Die hier gezeigten Anweisungen können in den falschen Händen Schaden an Ihrem System anrichten, deswegen erfolgt alles, was Sie jetzt machen auf eigene Gefahr!

WICHTIG: Bei Verwendung von LUKS darauf achten, daß die LUKS-Partition und die darin enthaltene Partition die gleiche UUID haben!

HINWEIS: der Befehl „replace“ wird von MYSQL/MARIADB zur Verfügung gestellt! Man kann die Anpassungen auch mit einem Texteditor machen, sollte man aber zwecks Reduzierung von Fehlerqellen nicht machen.

Alternativ könnte man sed -e „s/ALTE UUID/NEUE UUID/g“ < file >file.1; mv file.1 file machen, aber dann läuft man Gefahr die Rechte und Besitzer zu ändern.

Alles was wir jetzt machen, findet auf einer LIVE DISK statt, also im ungebooteten Zustand. Die Filesysteme sind alle EXT4, für abweichende Filesystem müßt Ihr Euch selbst was ausdenken 😉

Los geht’s :

A) Die Bootpartition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p1
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p1 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

*f) Partionen wieder abmelden

*) Das Abmelden ist natürlich optional, wenn Ihr mehrere Ersetzungen machen müßte, dann können die natürlich gemountet bleiben 😉

B) jede andere Partition

Jenachdem wieviele man hat, kann man das auch alles zusammen machen!

Wichtig: Jede Partition hat ihre eigene UUID, doppelte darf es nicht geben!

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p2 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Das waren die Filesysteme, kommen wir zu den LUKS Containern. Wer kein Luks hat, der ist jetzt natürlich fertig 🙂

Bei LUKS Partitionen ist das Vorgehen im Prinzip das Gleiche, nur die Befehle sind andere, weil LUKS kein Filesystem ist, aber eins zur Verfügung stellt nach dem Aufschliessen.

C) Für jede LUKS Partition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) cryptsetup luksUUID /dev/nvme0n1p2 –uuid „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/crypttab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Damit wären wir durch und so schlimm war es dann ja auch wieder nicht 🙂

Update: Es wurden Bilder zum Gnome-Laufwerke Tool eingebaut, powered by FlameShot – Ihrem Screenshottool