Keine Portaushandlung mehr
geschrieben am 27.05.2009 um 17:15 von Doninho
Hi Folks
Wir haben hier bei uns ein Problem, dass wir mittlerweile- so scheint es uns jedenfalls- auf die Portaushandlung zurückführen konnten.
Erst einmal etwas zur Umgebung. Wir haben ca. 40 WXP Clients welche auf einen W3k Std. Server Verbindung aufbauen. Auf dem W3k Server läuft eine Software welche die unassigned Ports 13000-13049 öffnet.
Das Programm setzt sich aus der Server-Software auf dem W3k Server, sowie einer Client-Software auf den XP-Clients zusammen. Beim Kommunikationsaufbau geht die Client-Software zum Server und spricht ihn auf dem Port 13000 an. Der Server gibt ihm dann den nächsten freien Port (13001-13049) als neuen Kommunikations-Port zurück, damit der Port 13000 für den Verbindungsaufbau frei bleibt.
Seit Wochen stellt sich nun ein Problem dar, dessen Ursache wir nun beinahe gefunden haben. Mit Wireshark sehe ich, dass ein entsprechender Client (ist jeweils immer ein anderer) zum Server hingeht, die Verbindung aufbaut und vom Server nicht den neuen Port zugewiesen bekommt, sondern einfach ein ACK zurückbekommt und dann auf dem Port 13000 weiter mit dem Server kommuniziert. Wenn wir den Client neu starten, wird der Port wieder freigegeben und einige Clients können wieder verbinden. Allerdings schon nach kurzer Zeit tritt das Problem mit einem anderen Client auf.
Für mich ist nun die Frage, warum der Server nicht den korrekten Vorgang durchläuft und einen freien Port zwischen 13001-13049 zurückgibt, sondern mit dem Client weiter auf Port 13000 kommuniziert. Und wie ich das Problem allenfalls noch tiefer analysieren kann?
geschrieben am 27.05.2009 um 19:17 von Mirko
Ich würde hier eher ein Problem in der Anwendung vermuten. Ist das eine Eigenentwicklung?
Mirko
geschrieben am 27.05.2009 um 19:23 von Doninho
Hi Mirko
Ja das ist so. Die Anwendung wurde Inhouse entwickelt.
Kannst du mehr dazu sagen, wo du das Problem vermuten würdest?
geschrieben am 27.05.2009 um 19:46 von Mirko
Gibt es denn einen Unterschied im Trace zwischen einem erfolgreichen Versuch (Client wechelt den Port) und einem fehlerhaften Versuch (Client bleicht auf 13000)?
Mit dem Trace aus Wireshark sollte der Entwickler doch das Problem eingrenzen können.
Mirko
geschrieben am 28.05.2009 um 09:39 von Otaku19
Hi Mirko
Ja das ist so. Die Anwendung wurde Inhouse entwickelt.
Kannst du mehr dazu sagen, wo du das Problem vermuten würdest?
dazu müsste er dei Anwendung kennen ;) Das sind so Probleme denen man als Netzwerker immer sehr gelassen entgegensieht :D
geschrieben am 29.05.2009 um 13:45 von Doninho
Hallo Leute
sorry für die späte Antwort!
@Otaku19; ja das kannst du machen, wenn am Ende des Tages der Task nicht sowieso an deiner Backe hängen bleibt.
@Mirko; ja den Unterschied gibt es.
Erfolgreicher Aufbau:
Client:___________________ Server:
dyn. Port ---------SYN-----------> 13000
dyn. Port <----SYN/ACK---------- 13000
dyn. Port ---------ACK-----------> 13000
dyn. Port <----PSH/ACK---------- 13000 (und hier gibt der Server den näcshten freien 130xxer Port, also Beispielsweise 13001)
die weitere Kommunikation läuft dann über den 13001er
Beim fehlerhaften Verbindungsaufbau fehlt das letzte PSH/ACK-Packet, danach kommunizieren Server und Client auf dem 13000er Port weiter.
geschrieben am 30.05.2009 um 14:26 von Mirko
Die ersten drei Frames sind der Aufbau der TCP-Session. Danach beginnt die eigentliche Datenübertragung. Diese wird komplett von der Anwendung gesteuert. Das Problem liegt hier mit Sicherheit in der Applikation.
Wenn es keine Monsterapplikation ist, sollte sich die betreffende Stelle im Quellcode schnell finden und debuggen lassen. Was sagt der Entwickler zu dem Trace?
Mirko
geschrieben am 02.06.2009 um 10:57 von Doninho
Tja leider stützt sich der Entwickler auf die Aussage, die Applikation würde seit Jahren stabil laufen und auch bei anderen Firmen sauber laufen.
Bis jetzt hat er sich halt auf den Standpunkt gesetzt, dass aufgrund dessen das Programm schon seit Jahren - mehr oder weniger - stabil läuft, irgendetwas anderes geändert wurde. Daraufhin haben wir deshalb Networkmonitoring, etc. eingerichtet.
Scheinbar wird es damit leider erst mal eine politische Sache.
geschrieben am 03.06.2009 um 08:33 von Otaku19
da hilft nur eines, client direkt an den Server anschließen und demonstrieren das es da auch nicht geht. Somit ist das Netzwerk aus dem Schneider und der Entwickler am Zug.
geschrieben am 05.06.2009 um 08:41 von Doninho
Mittlerweilen ist er sowieso am Zug. Die entsprechenden Leute haben endlich ein Machtwort gesprochen ;)
Trotzdem war es ein spannendes Problem, danke für eure Unterstützung :)
PS: In der Zwischenzeit hatten wir auf den Clients eine Konfiguration umgeschaltet, so dass die Portaushandlung weg fällt. Damit hat es dann funktioniert. Das war für die betreffenden Leute Hinweis genug.
geschrieben am 05.06.2009 um 08:58 von Otaku19
das ist nun mal leider das Los der Netzwerker/Securityleute. Da unsere Devices immer zwischen allen anderen stehen ist jedes Problem ein Netzwerkproblem -.-
Die "Probleme" die ich wirklich fixen muss kann ich pro woche an einer Hand abzählen, der Rest sind Fehler die woanders liegen oder bei Firewallsachen unzureichende Infos was ich denn jetzt freischalten soll.
geschrieben am 05.06.2009 um 10:10 von Doninho
Das wirklich Coole daran war meiner Meinung nach, dass ich praktisch auf Netzwerkebene den Fehler mehr oder weniger schon eingrenzen konnte.
[ Dieses Thema im Live-Forum aufrufen ]
|