Sorry, I don't see what the solution is. The TCP dump stops just when it starts to get interesting.
Line 21 that you mention makes it look like several packets were lost and the sender kept sending "the next" packet hoping that the lost packets were just delayed and would eventually show up. After a while, the sender decides that it has been too long (more precisely, that the receiver's "window" for buffering out-of-order packets can't hold the next packet) and starts sending the lost packets. Right after sending the first lost packet and the reciever acknowledging it, the trace stops. But this is probably because you don't get any more packets for a while since this also looks like the place where the script hangs.
Other than the trace stopping, this is all stuff that I expect from TCP. I'm curious about the nature of the network connection between the two machines. If it is always stopping in the same place, then something is consistantly preventing those "lost" packets from getting through.
You may want to use TCP dump on both ends of the connection and see how they differ to narrow down where the packets are being lost. You'll probably find some packets that are not displayed in the trace above (and vice versa).
Also realize that TCP will usually wait 2 minutes for a lost packet so it can take 4 to 8 minutes before everything times out. You obviously haven't waited "forever" ;), but have you waited at least 8 minutes?
- tye (but my friends call me "Tye")In reply to (tye)Re: network debug
by tye
in thread network debug
by iic
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |