lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] [lwip] Close with 0.5.2


From: Kieran Mansley
Subject: [lwip-users] [lwip] Close with 0.5.2
Date: Thu, 09 Jan 2003 00:27:14 -0000

I'm seeing some unexpected behaviour with code based on the 0.5.2 release.
After close() is called (using the sockets interface), one side (the one
that called close) goes into state FIN_WAIT_1, the other into CLOSE_WAIT,
but neither progresses from there.  I've checked the code based on 0.5.1,
and that seems to work properly.  I notice that there have been some
changes in tcp_output.c to how the segment length is handled when dealing
with TCP_FIN.  However, the stack I'm running does have some modifications
to it, so if no one else is experiencing this problem it seems likely that
it's something I've done wrong.

An extract of the debug output (with TCP_DEBUG, TCP_OUTPUT_DEBUG and
TCP_INPUT_DEBUG all set) is as follows:

1) Side that calls close:
tcp_close: closing in state State: ESTABLISHED

tcp_enqueue: queueing 6610:6611 (0x1)
tcp_output
tcp_output_segment: 6610:6610
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags ACK -+-+-+-+-+-+-+-+-+-+-+-+-+-+
State: FIN_WAIT_1
tcp_receive: ACK for 6610, unacked->seqno 6510:6610
tcp_receive: removing 6510:6610 from pcb->unacked
tcp_output
tcp_output: nothing to send
State: FIN_WAIT_1
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags ACK -+-+-+-+-+-+-+-+-+-+-+-+-+-+
State: FIN_WAIT_1
tcp_output
tcp_output: nothing to send
State: FIN_WAIT_1

2) Side that doesn't call close:
State: ESTABLISHED
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags FIN ACK 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+
State: ESTABLISHED
tcp_output
tcp_output: sending ACK for 6610
tcp_output
tcp_output: nothing to send
State: CLOSE_WAIT
tcp_recved: recveived 100 bytes, wnd 8192 (0).
tcp_timer_fine: delayed ACK
tcp_output
tcp_output: sending ACK for 6610
tcp_output
tcp_output: nothing to send

So, if anyone else can let me know if they're seeing something similar
it'll help me track down if it's a bug in lwIP or a bug in my own code.

Thanks

Kieran


[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]