Author Archives: marius

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

Posted on by

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

Posted on by

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

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

Posted on by

Wie ZDNET gerade berichtet, haben RPM / DNF System wie Fedora, CentOS , RHEL und andere ein kleines Problem mit einer möglichen Supply-Chain-Attack.

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

RPM Pakete aus Distro Repos werden i.d.R. signiert mit dem Key der jeweiligen Distro. RPM / DNF prüfen nach dem Download die Signatur des Pakets und nur wenn die gültig ist, wird das Paket installiert oder aktualisiert.

Die Prüfung ist leider nicht vollständig, weil alte Schlüssel nicht ungültig werden, da keine Revocationliste gefragt wird, ob der Key nicht zurückgezogen oder abgelaufen ist.

Das führt zu einer Supply-Chain-Attacke die uns allen dumm auf die Füsse fallen kann, wenn jemand die Repo Mirrors knacken sollte um dort geänderte Pakete mit alten Keysignaturen zu versehen. Damit wäre die Sicherheit der ganzen Installation gefährdet. Erschweredn kommt hinzu das immer noch unsignierte Pakete akzeptiert werden, auch wenn die GPG Signaturenprüfung aktiviert ist, meinen jedenfalls die Finder der Lücke.

Zwei Workarounds sind denkbar:

  1. Mirrorliste der Repos abschalten und nur noch die Hauptserver von Fedora /CentOs/ RHEL benutzen. Temporär wäre das eine Maßnahme, aber es belastet die Hauptserver kräftig.
  2. Die alten Keys vom System entfernen, dann sind die Signaturen nicht prüfbar => Problem erst einmal gelöst, außer es lassen sich wirklich unsignierte Pakete installieren, das wäre fatal.

Quelle: https://www.zdnet.com/article/major-linux-rpm-problem-uncovered/