DUP ACK probleem bij opzetten van een verbinding

[Alain]

Ik heb het probleem tussen twee apparaten van verschillende leveranciers, waarbij beide leveranciers zeggen dat ze niets fout doen. Het probleem is als volgt:

code:

C --> S [SYN] Seq=0
C <-- S {SYN,ACK] Seq=0 Ack=1
C --> S [PSH,ACK] Seq=1 Ack=1
C --> S [DATA] Seq=1 Ack=1
C <-- S [ACK] Seq=1 Ack=1 (Hier begint het probleem, dit is een DUP ACK)
C <-- S [ACK] Seq=1 Ack=13
C --> S [RST] Seq=1 (En de client reset de verbinding vanwege een DUP ACK)
C <-- S [DATA] Seq=1 ACK=13
etc ...

Ik heb de RFC erop nageslagen, maar ik ben niet echt bedreven in het lezen en interpreteren van dit soort documenten. Wat ik eruit begrijp is dat het pakket van regel 5 niet verzonden hoort te worden (dit gebeurd bewezen alleen bij third-party clients) en dat de client de verbinding niet hoeft te resetten bij dit bericht.

De leverancier van de client zegt dat zij de verbinding verbreken vanwege de niet verwachte ACK. De leverancier van de server zegt dat de client de verbinding niet zou moeten resetten bij dit bericht, maar kan niet aangeven waarom dit bericht verstuurd wordt.

Kan iemand mij vertellen wat volgens de RFC correct is?

Op verzoek de volledige trace

10.11.22.2 is de client
10.11.22.10 is de server

[ Voor 6% gewijzigd door Alain op 23-12-2011 15:46 ]

[TrailBlazer]

kan je ergens een wireshark capture van dit probleem laten zien. Dat leest wat beter.

[Alain]

Ik heb de volledige trace toegevoegd aan de TS.

[Alain]

* bump *

[Anoniem: 273065]

Heb even tcp stream 1 er uit genomen. Wat ik raar vind is dat de client in packet 7 uit de capture (tijdens de handshake) de PUSH flag set. Er zit ook geen data in dit segment dus imo is het niet nodig de push flag hier te setten. (len=0)
Imo is dat niet de bedoeling, al kan ik hier zo niet onmiddellijk iets van terugvinden in de RFC's.

Nu als je kijkt naar de DUP ACK zie je dat het ACK nummer terug verwijst naar het initiele sequence nummer (SYN van client) + 1. Dwz dat de server packet 7 van de client (met de PSH ACK fields) negeerd en dus opnieuw vraagt aan de client om dat pakket te zenden. Echter voor de client was de 3 way handshake complete, en reset hij dus de connectie (Kijk ook hier naar het SEQ nummer, is hier dus het initiële SYN SEQ nummer + 1).

Ondertussen heeft de client dus ook het segment met de data verzonden (pakket . In dit pakket ACK'ed de client de SYN ACK van de server (paket 6). Ook hier is de PUSH flag geset, maar omdat hier wel een payload aanwezig is, lijkt me dat perfect correct. Vandaar ook dat de server dit segment ACK'ed (pakket 10).

Het probleem is dus pakket 7: PUSH flag tijdens handshake, waar geen payload/data aanwezig is (len=0) . Dus ik denk dat je het op de client moet gaan zoeken.

[ Voor 32% gewijzigd door Anoniem: 273065 op 28-12-2011 19:35 . Reden: enkele toevoegingen ]

[Alain]

Anoniem: 273065 schreef op woensdag 28 december 2011 @ 19:03:
Nu als je kijkt naar de DUP ACK zie je dat het ACK nummer terug verwijst naar het initiele sequence nummer (SYN van client) + 1. Dwz dat de server packet 7 van de client (met de PSH ACK fields) negeerd en dus opnieuw vraagt aan de client om dat pakket te zenden.

Je verhaal klinkt aannemelijk (bedankt daarvoor ), maar ook als de PSH niet wordt verstuurd, wordt de DUP ACK verstuurd. Ook de volgende java code resulteert in een DUP ACK (maar niet in een RST):

Java:

Socket clientSocket = new Socket("10.11.22.10", 502);
clientSocket.close();

De DUP ACK wordt alleen verstuurd als de client niet van hetzelfde merk is als de server.

Ik vraag me serieus af of pakket 9 uit de trace (regel 5 in mijn uitleg) wel verstuurd mag worden (mits er geen andere netwerkproblemen zijn).

[Anoniem: 273065]

Ik zie geen reden waarom de DUP ACK er zou mogen zijn.
Nog even verder na gedacht over de PSH ACK tijdens de handshake, als de PSH flag daar niet mag geset zijn, zou de server daar de tcp connectie al moeten verbreken met een TCP RESET.

Sniff je dit op de client of de server? Wat voor apparaten zijn dit? Wat voor OS draait er op?

Draai je dat java programma op dezelfde client?
In je trace zie is er een connectie te zien, die wel volledig lukt (tcp stream . Is dat dan ook weer een andere client?

[Alain]

Anoniem: 273065 schreef op donderdag 29 december 2011 @ 11:33:
Sniff je dit op de client of de server? Wat voor apparaten zijn dit? Wat voor OS draait er op?

Het is een PLC (client) die babbelt met een Modbus gateway (RTU-->TCP) (server). Ik heb de poort waar de PLC op aangesloten zit gemirrort naar de poort waar mijn laptop op aangesloten zit en daarmee de trace opgevangen.

Draai je dat java programma op dezelfde client?

De java applicatie draai ik vanaf mijn latop. Hiervan heb ik geen trace opgeslagen.

In je trace zie is er een connectie te zien, die wel volledig lukt (tcp stream . Is dat dan ook weer een andere client?

Nee, dat is gewoon dezelfde client. De verbinding komt (meestal na zo'n 5 minuten) ineens spontaan op gang. Wanneer je dan ook maar op wat voor manier de verbinding verbreekt, dan duurt het weer zo'n 5 minuten totdat het weer op gang komt. Dat lijkt me meer geluk dan wijsheid eigenlijk.

[Anoniem: 273065]

Kan je dit eens sniffen langs beide uiteinden (dus server en client)?

Duplicate ACK mag enkel onststaan omdat een bepaald segment out of order aankomt (door congestion of loss). Loss lijkt me niet het geval te zijn, want vlak na de DUP ACK akced de server de query van je client. Dus in het slechtse geval komt het out of order aan...
Als je het op de server sniffed, kunnen we zien of het segment al dan niet out of order is aangekomen.

[Alain]

Anoniem: 273065 schreef op donderdag 29 december 2011 @ 14:31:
Kan je dit eens sniffen langs beide uiteinden (dus server en client)?

Ik zal dat volgende week eens proberen. Alvast bedankt voor het meedenken.

[Alain]

Ik ben hier eindelijk wat verder mee.

De leverancier van de client heeft aangegeven dat ze een zeer agressieve manier van foutafhandeling toepassen bij het initialiseren van de verbinding. De reden hiervoor is dat het resetten van de verbinding sneller is dan wachten en ze met beperkte resources wel de polltijden moeten halen. Zij gaan hier niks aan veranderen.

De leverancier van de server heeft aangegeven dat de DUP ACK inderdaad ongeldig is. Ondanks dat dit normaliter geen problemen oplevert gaan ze wel de firmware aanpassen zodat dit niet meer voor komt.

Eind goed, al goed.