Es sind seltsame Dinge im Gange, es werden Drohungen ausgesprochen und wir müssen dieses Problem lösen.
Die Situation:
Unser Gerät (eine Netzwerkkamera) überträgt Videos über ein Netzwerk an einen Rekorder/Server (mit Live555/WIS Streamer). Das Video besteht aus UDP-Paketen.
Auf einer bestimmten Site, die einen bestimmten Server verwendet, kommt es hin und wieder (ca. 24 Stunden) vor, dass ein Thread des Live555-Streamers beim Senden von Videos blockiert. Andere Threads laufen weiter und wir haben weiterhin eine Verbindung zur Kamera über IP – wir können Webseiten von ihr aus aufrufen, sie anpingen usw.
Wir vermuten: der Server; er hat 2 Netzwerkports und aggregiert sie – er hat zwei MACs, aber eine IP-Adresse. Beim Wiresharking sehen wir, dass die Kamera an einen Port streamt (nennen wir ihn A), dann erhalten wir ein ARP vom anderen Port (nennen wir ihn B), unser Gerät hört auf, Pakete an MAC A zu senden, sendet ein Paket über das Kabel an MAC B und scheint dann stehen zu bleiben.
Weitere Informationen: Der Server scheint ARP-Pakete vom „falschen“ Port zu beschädigen, möglicherweise aufgrund einer Fehlkonfiguration oder etwas Ähnlichem, aber diese Pakete werden trotzdem von unserem Gerät gelesen und verarbeitet, möglicherweise aufgrund einer Fehlkonfiguration unseres Treibers oder Kernel-Netzwerks oder weil Prüfsummen übersprungen werden, um CPU-Zyklen zu sparen.
Diese chaotische Situation wirft einige Fragen auf:
- Wo im Kernel-Netzwerkcode sollte ich nachsehen, ob ich die Paketprüfsumme überprüfen oder die Überprüfung aktivieren kann? Unsere Hardware ist fest, da es sich um ein eingebettetes Gerät handelt. Daher ist eine Optimierung des Treibers keine schlechte Idee.
- Kann jemand den Fehlermechanismus erraten, der dazu führt, dass ein Prozess blockiert, wenn er ständig
send()Daten über einen Port sendet und sich die ARP-Tabellen darunter verschieben?
Bearbeitet, um hinzuzufügen: Wir vermuten nun, dass die ARPs nicht wirklich beschädigt sind, sondern dass Wireshark das Paket nur nicht richtig identifiziert (es denkt, das Paket sei lang genug, dass ein FSC-Wort vorhanden sein muss, aber wir glauben nun, dass es sich nur um Nullen-Padding handelt). Damit bleibt eigentlich nur noch Teil 2 dieser Frage: Was können wir tun, um zu verhindern, dass diese Änderung in der ARP-Tabelle einen Übertragungsprozess zum Absturz bringt?
Bearbeiten, um Folgendes hinzuzufügen:Ich möchte nicht, dass die Leute denken, ich würde Fragen zu Port- oder Prozesszuständen ignorieren. Das Problem tritt sehr selten auf (durchschnittlich vielleicht einmal pro 24 Stunden) und nur bei einer (Remote-)Installation, auf die wir nicht so leicht zugreifen können. Wir geben uns große Mühe, es im Labor zu reproduzieren, damit wir ausführlichere Diagnosen durchführen können. Der System-Watchdog wird jedoch innerhalb von ca. 3 Minuten nach Auftreten des Problems zurückgesetzt, sodass das System zum Zeitpunkt, an dem uns die Neuigkeit erreicht, bereits neugestartet ist und wieder ordnungsgemäß funktioniert.
Bearbeiten, um Wireshark-Informationen hinzuzufügen: Ich bin mir nicht sicher, wie ich Wireshark-Captures hier am besten zusammenfassen kann (es ist sehr schwierig, ca. 1 TB erfasster Pakete hochzuladen!), aber ich werde es versuchen. Cam:X& Cam:Ysind zwei RTSP-Videostreams, die von zwei identischen Instanzen von Live555 WIS Streamer von verschiedenen Ports aus gestreamt werden. Server „A“ und „B“ sind die MACs der beiden NICs auf dem Server.
Die Paketsequenz sieht folgendermaßen aus:
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
Zu diesem Zeitpunkt oder ungefähr zu diesem Zeitpunkt sind keine anderen Pakete im Stream. Die Intel ANS-Pakete stimmen nicht immer mit den ARPs der Netzwerkkarte überein, aber ich dachte, ich füge sie der Vollständigkeit halber hinzu.
Das Problem scheint SEHR zeitabhängig zu sein. Wir sehen diese „Team“-ARPs regelmäßig vom Server und nur alle Jubeljahre verursachen sie uns Probleme – als ob es einen bestimmten Punkt im Netzwerkstapelcode gäbe, der empfindlich auf Änderungen der ARP-Tabelle reagiert. Es ist nicht immer dieselbe Stream-Instanz, die ausfällt, und insbesondere die andere Instanz (sowie der gesamte andere Netzverkehr – HTTP usw.) funktioniert weiterhin einwandfrei.
Es hört sich so an, als ob Team-NICs während einer Sitzung kein derartiges ARP ausführen „sollten“, aber natürlich bemerken sie keine Sitzung, wenn der gesamte Datenverkehr über UDP erfolgt.
Antwort1
Nun, wenn auch nur, um einigeSchließungDer Kunde hat seine fehlerhafte Netzwerkkarte neu konfiguriert und alles hat funktioniert. Für die Neugierigen bedeutet das leider, dass niemand jemanden dafür bezahlen wird, sich genauer anzusehen, was hätte getan werden können, um diesen Fall zu beheben.