Date: Wed, 20 Mar 2002 21:28:33 +1100 From: Gregory Bond <gnb@itga.com.au> To: Aaron Baugher <abaugher@esc.pike.il.us> Cc: freebsd-stable@FreeBSD.ORG, gnb@itga.com.au Subject: Re: Network stalls with 4.5 Message-ID: <200203201028.VAA28355@lightning.itga.com.au> In-Reply-To: Your message of 19 Mar 2002 12:19:44 -0600.
next in thread | raw e-mail | index | archive | help
At this point, your server has sent 33324 btyes. > 09:41:22.371874 55.66.77.88.22 > 11.22.33.44.4257: P 33324:33472(148) ack 161 > win 65535 [tos 0x10] > 09:41:23.371716 55.66.77.88.22 > 11.22.33.44.4257: P 33324:33472(148) ack 161 > win 65535 [tos 0x10] OK, the server tried to send another 148 bytes starting at byte #33324. After a second, it sent it again because your client didn't reply. > 09:41:24.381831 55.66.77.88.22 > 11.22.33.44.4257: P 33472:33628(156) ack 161 > win 65535 [tos 0x10] > 09:41:24.629822 11.22.33.44.4257 > 55.66.77.88.22: . ack 33324 win 51360 (DF) > [tos 0x10] A second later the server application sends another 156 bytes, and your client replies saying its received only the first 33324 bytes. > 09:41:25.371763 55.66.77.88.22 > 11.22.33.44.4257: P 33324:33628(304) ack 161 > win 65535 [tos 0x10] Now the server has 2 bunchs of data to send, and is trying to send them both at once. > Now here's the same number (33324) as the doubled packet above, but > with a different second number and size. (This is a misunderstanding - the <number>:<number> are sequence numbers of bytes being sent in this packet.) > 09:41:26.391896 55.66.77.88.22 > 11.22.33.44.4257: P 33628:33744(116) ack 161 > win 65535 [tos 0x10] Yet more data from the application. > 09:41:26.630980 11.22.33.44.4257 > 55.66.77.88.22: . ack 33324 win 51360 (DF) > [tos 0x10] Still your client is saying they haven't seen anything past byte 33324 [snip more of the same] > 09:41:35.147334 11.22.33.44.4257 > 55.66.77.88.22: . ack 34336 win 51360 (DF) > [tos 0x10] Finally! your application says, they recieved all the bytes up to 34336. AFAICT the problem is either in your client or the network between the two. The server seems to be doing everything right, but the client is either not getting the data packets or ignoring them for some reason. The net can't be totally down as we are seeing the occational ack packet back from the client. Someone with more experience on TCP internals might speculate on why the client was sending the acks at all, and what this tells us about the problem. (hmmm, I suppose it could be a CRC calculation error at the server that would cause it to send bogus checksums with some particular set of packet contents, but in that case I would expect the checksum to be OK and transfers to continue once the second load of data was added to the outgoing packets.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203201028.VAA28355>