TCP-stack: probleem met close_wait

[rookie]

Ben voor mijn werk verwikkeld in een discussie met een Core IE Support engineer van Micorsoft vanwege een probleem wat we hebben met Internet Explorer. IE loopt namelijk af-en-toe vast op een tweetal specifieke intranet-pagina's.

Omdat IE soms de TCP-connectie niet sluit blijven er twee poorten in CLOSE_WAIT status en hangt het iexplore-proces volledig.

De wireshark pcap-traces op het werkstation tonen inderdaad aan dat IE geen [FIN,ACK] bericht terugstuurt als het probleem optreedt.

Nu zegt de MS-engineer dat het komt omdat het TCP pakket met de HTTP 200 OK van de webserver een [FIN,PSH,ACK] bevat en dat dit niet normaal is. Volgens hem moet de server aansluitend een [PSH,ACK] en een [FIN,ACK] sturen.

Nou ben ik geen hardcore netwerkspecialist, dus vandaar mijn vraag. Heeft hij gelijk??

Overigens stuurt IE in de meeste gevallen wel gewoon een [FIN,ACK] als antwoord op de [FIN,PSH,ACK], dus er zit weldegelijk een bug in IE (IE6 en IE7 in dit geval)..

[Guru Evi]

[b][message=34205227,noline]
Nu zegt de MS-engineer dat het komt omdat het TCP pakket met de HTTP 200 OK van de webserver een [FIN,PSH,ACK] bevat en dat dit niet normaal is. Volgens hem moet de server aansluitend een [PSH,ACK] en een [FIN,ACK] sturen.

Nou ben ik geen hardcore netwerkspecialist, dus vandaar mijn vraag. Heeft hij gelijk??

Nee, de TCP/IP stack van je OS moet dit goed kunnen afwerken. IE zou daar in principe niets mee te maken hebben (of ze hebben een bagger slecht design waar TCP/IP wordt afgeladen op IE - zie ook OSI model).

Daarnaast zou een client niet mogen beïnvloed worden door een 'slechte' server en vice versa. Ik denk dat je hier eerder een bug ontdekt hebt, vastlopen/hangen betekent veelal dat er ook een lek is die misschien misbruikt kan worden. Microsoft kennende gaan ze dit probleem niet oplossen tot er een virus is die het uitbuit.

ACK, PSH, FIN is een correcte TCP response en wil gewoon zeggen dat de server de verbinding sluit met instructies naar de client: gelieve dit pakket niet te bufferen, zo snel mogelijk naar de applicatie brengen.

Een manier om dit misschien uit te buiten is na een datastream een TCP pakket met ACK, FIN, PSH bits te zenden en daarna een 'rogue' datastream te sturen van een ander systeem met fake TCP headers en dit dan wel afwerken zoals IE het verwacht (met ACK, FIN) en dan kijken wat je kunt veroorzaken. Probeer gewoon een 'andere' webpagina door te sturen of een virus of gewoon iets in het geheugen zetten.

[ Voor 16% gewijzigd door Guru Evi op 18-06-2010 17:10 ]

[rookie]

Dank voor het supersnelle antwoord!

Ik heb zojuist mijn case bij MS ge-update, maar ik verwacht inderdaad niet dat dit snel ge-hotfixed o.i.d gaat worden. Zal wel weer een leuke escalatie worden, want men schijnt hier toch wel een redelijk duur betaald contract met MS te hebben, en dit is een blocking issue voor de projectuitrol...