In den letzten Wochen hatten wir im Netzwerk einige Probleme mit Printboxen, die immer mal wieder beschlossen haben, keinen Bock mehr auf dieses Leben zu haben und keine Verbindungen mehr akzeptierten.
Eingegrenzt habe ich das dann auf massive Broadcast-Stürme – genauer IPv6-MDNS-Responses von exakt einem Apple-Rechner. Da der User gerade im Urlaub ist konnte ich mit der Kiste mal rumspielen und das ganze ließ sich erstaunlicherweise recht zuverlässig reproduzieren.
– Safari und iTunes starten (aus irgendwelchen Gründen erzeugen Macs dann mehr MDNS-Traffic)
– warten bis der Rechner in den Ruhezustand geht (ggf mehrmals aufwecken, irgendwann klappt es)
=> BAMM, Netzwerk geflutet
Das ganze äußert sich dann so, dass die Kiste auf die IPv6-Queries antworten möchte (wir nutzen v6 nicht, das ist dann alles mit Zeroconf*), aber nur kaputte Pakete rausschickt – und das bis die Leitung saturiert ist**.
Das oben markierte DNS-Paket beinhaltet laut Header angeblich 18 Antworten, über das Kupfer kamen aber nur 15. Erst dachte ich ja, dass die Karte sich nicht an die Ethernet-MTU hält, aber in den zigtausenden von kaputten Paketen sind beispielsweise auch solche, die nur 3 Antworten enthalten sollen und deutlich unter den 1500 Byte bleiben würden – auch diese sind dann nicht in Ordnung.
Google und Co schweigen sich über dieses Problem aus***, meine aktuelle Arbeitshypothese lautet, dass Apple aus unternehmensstrategischen Gründen**** alle hardwarenahen Coder ersetzt hat durch UI-Designer – und diese Treiber programmieren im Apple-typischen Flair, also mit abgerundeten transparenten Signalflanken. Und da nun der PHY nicht dieser Philosophie folgt hat er Probleme den Anweisungen zu folgen und erzeugt kaputte Pakete (die wegen der Fehlerkorrektur erkannt und erneut versandt werden).
Oder hat jemand bessere Ideen?
*) Bonjour ex Rendezvous im Apple-Sprech
**) Lustigerweise überlebt das sogar einen Reboot, nur Ausschalten und Anschalten hilft…
***) bzw ich suchte falsch
****) function follows form aka Klickibunti