Hallo, ich hab eine TCP Client Applikation und ein Gerät mit TCP Server Applikation. Die beiden Geräte kommunizeren über die Schnittstelle, aber nach unspezifierter Zeit bricht die Verbindung im Dauerlauftest ab. Ich hab zu beiden Programmen (Client,Server) ein Zugriff auf die Programme mittels GDB und auch kein Source code. Ich hab bis jetzt in WireShark nur selbstdefinierte Protokolle geprüft wie z.B. den TCP Payload. Ich würde gerne wissen, welche Applikation schuld ist am Verbindungsabbruch. Kann man in Wireshark sehen, ob Client oder Server die Verbindung geschlossen hat?
Thorben schrieb: > Ich > hab zu beiden Programmen (Client,Server) ein Zugriff auf die Programme > mittels GDB und auch kein Source code. hast du Source, oder nicht? Thorben schrieb: > Kann man in Wireshark sehen, ob Client > oder Server die Verbindung geschlossen hat? ja - ist deutlich farblich markiert und anhand des Ports siehst du wer zu gemacht hat
Wenn eine ordentliche FIN gesendet wird schon. Wenn der Server aber die Verbindung wegen eines Timeout schließt sieht das so aus: https://osqa-ask.wireshark.org/questions/25727/how-to-apply-filter-to-view-tcp-connection-timeout/ Sg
Thorben schrieb: > aber > nach unspezifierter Zeit bricht die Verbindung im Dauerlauftest ab. Ich > hab zu beiden Programmen (Client,Server) ein Zugriff auf die Programme > mittels GDB und auch kein Source code. Da hat dein Dauertest doch schon das erste Finding gebracht. Sieh dir mal die Zeiten im Wireshark an, kann es sein das die Verbindung wegen Untätigkeit geschlossen wird? Abgesehen davon würde ich mit diesen Finding den Hersteller kontaktieren (du bist es offensichtlich nicht, wenn du den Quellcode nicht hast), eine Netzwerkverbindung kann immer mal unterbrochen werden, zum Beispiel weil sich Routen ändern oder der genervte Admin das falsche Kabel zieht. Eine solide Client/Server Architektur sollte damit klarkommen und einfach eine neue Socket Verbindung aufbauen, wenn der Partner wieder erreicht werden kann. Außerdem solltest du dir die Kommunikation der beiden Partner vielleicht auch mal mit strace ansehen, gerade die Socket Parameter könnten interessante Informationen bringen, wie die Verbindungen geöffnet werden. Aber insgesamt empfehle ich dir, das Problem in einem isolierten Netzwerk mit tcpdump oder wireshark aufzuzeichnen und beim Hersteller der Software ein Defekt zu melden, mit dem aufgezeichneten Netzwerkverkehr. Der hat den Quellcode! Denn egal zu welcher Erkenntnis du kommst, du kannst an den Programmen nichts ändern, wenn wir mal Dinge wie Hacking und Reverse Engineering ausschließen.
Thorben schrieb: > Ich hab bis jetzt in WireShark nur selbstdefinierte Protokolle geprüft > wie z.B. den TCP Payload. Ich würde gerne wissen, welche Applikation > schuld ist am Verbindungsabbruch. Kann man in Wireshark sehen, ob Client > oder Server die Verbindung geschlossen hat? Ja, lade mal das *.pcap mit voller snaplen hier hoch.
>hast du Source, oder nicht? Ok ich meinte kein GDB und kein Source Code, da ging das "k" zwischendurch verloren. >Ja, lade mal das *.pcap mit voller snaplen hier hoch. Kann ich teilen, wegen NDA, aber mit den Informationen von Clemens kann ich mich weiter auf die Suche machen. Danke!
Thorben schrieb: >>Ja, lade mal das *.pcap mit voller snaplen hier hoch. > > Kann ich teilen, wegen NDA, aber mit den Informationen von Clemens kann > ich mich weiter auf die Suche machen. Danke! Hoffentlich ist es so einfach.
imonbln schrieb: > Abgesehen davon würde ich mit diesen > Finding den Hersteller kontaktieren (du bist es offensichtlich nicht, > wenn du den Quellcode nicht hast), eine Netzwerkverbindung kann immer > mal unterbrochen werden, zum Beispiel weil sich Routen ändern oder der > genervte Admin das falsche Kabel zieht. Er hat zwei Geräte und weiß nicht, welches davon am Verbindungsabbruch schuld ist. Welchen Hersteller soll er also kontaktieren?
Rolf M. schrieb: >Er hat zwei Geräte und weiß nicht, welches davon am Verbindungsabbruch >schuld ist. Welchen Hersteller soll er also kontaktieren? Richtig das würde ich gerne herausfinden und aufzeigen, damit der Ball nicht dauerhaft hin und her geschossen wird.
Na, dann viel Vergnügen... "Bei uns funktioniert das problemlos" - garantiert. Bei beiden... Oliver
Oliver S. schrieb: > "Bei uns funktioniert das problemlos" - garantiert. Bei beiden... Das ist leider inzwischen so üblich. Hatte mal ein industrielles Schweißgerät. Ip eingestellt und funktioniert. Nach ca einem Tag holt sich das Ding aber über DHCP eine andere IP und war nicht mehr zu erreichen. Selbst mit WS log meinte der Hersteller dass sein Gerät perfekt funktioniert. Das Problem war ein Fehler in der SW die nach Ablauf der Default DHCP Gültigkeit immer eine neue Adresse geholt hat, egal ob fix oder nicht. Da mussten wir dann leider Geräte im Wert von 2Mio zurück schicken. Danach gingen die erst auf die Suche nach dem Fehler. Naja, man lernt nie aus. Sg
Clemens S. schrieb: > Oliver S. schrieb: >> "Bei uns funktioniert das problemlos" - garantiert. Bei beiden... > > Das ist leider inzwischen so üblich. Das wird allerdings tatsächlich so sein. Oliver
Oliver S. schrieb: > Na, dann viel Vergnügen... > > "Bei uns funktioniert das problemlos" - garantiert. Bei beiden... > > Oliver Es kann auch passieren wenn man konkretes Fehlverhalten anhand eines Netzwerktraces nachweist das trotzdem Fehler abgestritten werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.