:strip_exif()/u/2087/osiris_ani.gif?f=community)
Casus: Brakke TCP-verbindingen
Het probleem
Ik heb al sinds een jaar of twee last van het probleem dat één van de twee 'halve verbindingen' van een TCP-verbinding 'stopt'. Dat uit zich bijvoorbeeld op IRC, maar ook steeds vaker op normale sites.Op IRC merk ik dat er al tijden geen "berichtjes" meer doorkomen en de lag-meter spiket tot z'n max.. Totdat IRC disconnected raakt. Berichtjes die ik zelf blaat komen echter nog wél bij de server en andere chatters aan! Bij sites laadt de site gewoon niet.
WireShark to the rescue: packet-dumps 
Naar wat packet-snif-werk ben ik er achter dat er iets mis gaat met de inhoud van de TCP-pakketjes van de inbound TCP-helft. Uitgaande zooi gaat tot nu toe altijd nog prima. Als het probleem zich voordoet, dan "zie" ik niets meer van het IRC-gechat doorkomen, maar zien anderen al mijn geblaat nog wél. In de packet-dump zie je dat ook duidelijk, mijn IRC-requests (geblaat van mijn kant dus 
) leveren zelfs nog prima een ACK op van de IRC-server, maar de inkomende helft stagneert vanwege het achterwege blijven van ACK's van mijn kant. Nogal logisch, waarom zou mijn TCP-stack ACK's gaan versturen voor brakke pakketjes met foutieve checksum (naar het blijkt is dat namelijk het probleem)? En zolang ik niet ACK, verstuurt de server geen nieuwe pakketjes meer, zodat de verbinding blijft 'hangen'. Het probleem doet zich echter ook voor bij normale sites, zo af en toe. (Sites zijn wat makkelijker te sniffen, want zelfs na F5/Ctrl-F5/whatever doet het probleem zich voor...)Nu dan toch echt de packet-dumps 
Anywayz, voorbeeldje van toen ik Weer.nl wilde bezoeken:
Analyse van de éérste rood/zwarte packet:
Transmission Control Protocol, Src Port: http (80), Dst Port: 1851 (1851), Seq: 1, Ack: 460, Len: 1354 Source port: http (80) Destination port: 1851 (1851) Sequence number: 1 (relative sequence number) Next sequence number: 1355 (relative sequence number) Acknowledgement number: 460 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) Window size: 6432 [b] Checksum: 0xfd15 [incorrect, should be 0x051e (maybe caused by checksum offloading?)][/] SEQ/ACK analysis This is an ACK to the segment in frame: 7 The RTT to ACK the segment was: 0.002548000 seconds TCP Analysis Flags This frame is a (suspected) out-of-order segment
Checksum incorrect? WTF? Eens kijken wat er in het pakketje staat dan...:
[me]Hele boel CSS-regels, ff weg voor duidelijkheid *[/] .linklist ul li ass="last"><div id="anchorIDf36dfe5298" suBnC2ArJq71lC2gDhkHFoCjN14zHmtBs3YDjg0DIRglbiOI c\303\004\215:,=(z\000\000\000\000\000\000\000 ^X<\227\000P\177\a:n\b\000E\000\000(\320\342
Die "\ddd" (waarbij "d" voor digit staat)-meuQ is, uiteraard, een non-ASCII character. Dit is overigens aan het einde van het pakketje, niet middenin ofzo.
Dát is géén CSS-code meer! Dat is dus random onzin-data wat in 't pakketje zit...
Als je eventjes weer teruggaat naar het pakketjes-overzicht, dan zie je ook een "Previous segment lost"-pakketje staan met de TCP-flags "FIN, ACK". Dat wil dus zeggen dat de server (server was de source van het pakketje) de TCP-verbinding wil beëindigen. Huh? Nu al? Het was immers pas pakketje 6, praktisch vlak na de HTTP GET?
Kijken we even naar de SYN/ACK-analyse:
Sequence number: 1355 (relative sequence number) Acknowledgement number: 460 (relative ack number)
Hey, 1355? Waar hadden we dat eerder gezien? Ohja, bij de "Next sequence number" van het kapotte pakketje! Het "data"-pakketje met m'n CSS-file die dus blijkbaar allang verstuurd had moeten zijn!
Klaarblijkelijk heeft de server het "data"-pakketje verstuurd en besloot het maar meteen de TCP-verbinding dicht te gooien (geen "keep-alive"), terwijl de CSS-data (hoewel foutief) pas 2,6 ms bij m'n systeem (Wireshark) aan kwam? Waar is het oorspronkelijke pakketje gebleven?
't Wekt bij mij eerlijk gezegd meer vragen op dan dat er beantwoord wordt
Verdere beknopte informatie
[list]• De "onzin-data" achteraan de pakketjes is random per herverstuurd pakketje, steeds anders dus;• Het is OS-onafhankelijk: Ik draai hier dualboot en zowel mijn Gentoo Linux als mijn Windows XP-installatie hebben last van het probleem;
• Het is "lokatie"-afhankelijk: Ik heb het alleen hier op mijn studentenkamer in Utrecht. Bij mijn ouders met een andere router/switch/bekabeling gaat het prima;
• Het is hoogstwaarschijnlijk systeem-afhankelijk: mijn server met 3Com-NIC en ook Gentoo Linux heeft naar mijn weten nergens last van, mijn laptop wel;
• Het is, denk ik, "packet"-afhankelijk: 100x op (Ctrl-)F5 rammen/Stop-Reload/Stop-handmatig weer op enter drukken in de adresbalk hadden allemaal geen nut. Mijn browser verstuurde immers identieke HTTP-requests gevolgd met een identieke HTTP-reply. Toen ik mijn weer.nl-cookie wegpleurde, werkte het opeens vlekkeloos! Dus ik dénk dat er een bepaalde "trigger" in het pakketje moet zitten ofzo?
De vraag: wat is de oorzaak?
What the #*()$ kan de oorzaak van zo'n vaag probleem zijn? Je zou immers denken: stuk = stuk, dus dan zou je d'r altijd last van moeten hebben? Nee, het doet zich alleen voor bij specifieke situaties.Ik denk zelf dat het mijn router (een Draytek Vigor 2600 WE) is. Wellicht een geheugen-probleem? Hij wordt niet te warm, hij hangt netjes in een soort post-verzamel-rekje onder onze telefoon etc, genoeg koeling dus.
Maar waarom dan alleen m'n laptop er last van heeft? Mijn server gaat namelijk via dezelfde switch... Ook kreeg ik er op ten duur ook last van via WiFi. Dit was eerder niet zo. Maar aangezien WiFi de switch omzijlt, lijkt 't me geen kabel/switch-probleem.
Is er wellicht iemand die al eens eerder van dit vage probleem heeft gehoord en zou iemand wellicht ook een oplossing weten?
Ik ben vooral benieuwd naar een beter diagnose-middel: hoe kan ik zeker weten dat het m'n router is, zonder dat ik teveel €€€'s uit moet geven?
