|
Hi I have earlier reported that some TCP
connections gets stucked in
the state CLOSING. According to the RFC793, the
CLOSING state is a state where both ends have sent a FIN, but the ACK on the FIN
has not yet been received. There is not timeout in the CLOSING state. I guess
that the CLOSING state isn’t used to often. I have now analyzed this somewhat
further. tcp_in.c : … case
FIN_WAIT_1: tcp_receive(pcb); if
(flags & TCP_FIN) { if (flags & TCP_ACK && ackno == pcb->snd_nxt) { …. } else
{
tcp_ack_now(pcb);
ß control
goes here every time in my test setup. pcb->state = CLOSING; } … In my test setup: Every time a FIN is received in FIN_WAIT_1 state, control
goes to the part where the state is set to CLOSING The received flags are TCP_FIN and TCP_ACK. ackno
is equal to pcb->snd_nxt+1
?? ackno
is equal to pcb->snd_nxt+1
-> Is this really correct ? Should
it be if (flags & TCP_ACK && ackno >= pcb->snd_nxt) ? Attached in an Ethereal example. I currently
recover by tcp_rst () if remaining in CLOSING state
for 10 secs. In packet #22, lwIP transmits FIN with seq. no 11525. In packet #26 my PC transmits FIN with ACK to 11526. It should really do? For info: I test my opening a web page with a refresh timer of 3
seconds. This produces HTTP traffic continuously. <meta http-equiv="refresh" content="3, URL="">> Jan Ulvesten SICOM |
lwip connection stuck in Closing state - filtered
Description: lwip connection stuck in Closing state - filtered
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
