I'm experiencing a bug where snd_wnd collapses. I see snd_wnd approach zero even though data is sent/received and ack'ed successfully.
After taking a close look at tcp_input, I think I see a senario where this could happen. Say header prediction handles ~2 GB of data without problems, then a retransmission happens. snd_wnd starts collapsing as it should. The header prediction code is correctly skipped as the snd_wnd no long matches the advertised window. We recover from the retransmission, *BUT* the code that reopens window is skipped because of rolled over sequence numbers. In the ack processing code (step 6), the variable snd_wl1 tracks the newest sequence number that we've seen. It helps prevent snd_wnd from being reopened on re-transmitted data. If snd_wl1 is greater than received sequence #, we skip it. This is fine unless we're 2^31 bytes ahead and SEQ_LT says we're behind. Since snd_wl1 is only updated if the condition is true -- we're stuck. snd_wl1 is only updated with in SYN/FIN processing code and in step 6. So if we process 2GB in the header prediction code -- where the step 6 never executes, and then somehow reach step 6. snd_wnd collapses and tcp_output stops sending. I have a trace mechanism that dumps various tcp_input variables that corroborates this theory. I have lined this up with tcpdump. The trace shows snd_wnd collapsing and snd_wl1 > th_seq even as healthy traffic is transmitted and received. The outcome is a halted transmitter. Possible remedy: update snd_wl1 in the header prediction code. What do you all think? Is this real? Or am I missing something? Regards, Bill Baumann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
