lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] restarting a connection with the raw api


From: Richie Bonventre
Subject: Re: [lwip-users] restarting a connection with the raw api
Date: Thu, 22 Sep 2011 17:57:50 -0400

Ok, thanks for the clarifications!
In case you guys are interested, the project that I am working on is part of the readout electronics for the SNO+ experiment (http://snoplus.phy.queensu.ca/), an underground neutrino detector. We are using LwIP to replace piles and piles of slow, noisy ribbon cables and increase the experiment's readout speed. LwIP has been a super helpful tool for us so thanks for all the hard work!
Richie

On Wed, Sep 21, 2011 at 12:02 PM, address@hidden <address@hidden> wrote:
Richie Bonventre wrote:

[..] In addition, the state the struct returns to is identical to the state of a brand new tcp_pcb, "CLOSED". This caused me to believe that I could tcp_connect() again on the same tcp_pcb. As you've said, this is not actually ok. After tcp_close returns, lwip no longer knows about your tcp_pcb struct, and although the memory isn't cleared, lwip has designated that memory space as free so the next time you create a connection with tcp_new() it may place it there and overwrite your old tcp_pcb.
Clearing the memory would not help: it might already be re-allocated and thus have a valid state. Plus "CLOSED" is 0, I think...

Anyway, it is documented that a pcb may not be referenced after tcp_close() returned ERR_OK (even if the pcb might not be deallocated at that point, it will eventually be).


So my four situations:
1) I ctrl-C the listener on the other machine.
This will send some sort of packet to your lwip machine telling you the connection is closing. Lwip will move tcp_pcb into the CLOSE_WAIT state, and will call the recv_callback with a NULL argument. In the recv_callback you should then check that this packet is coming from your currently opened connection. If it isn't, it must be from an old connection that you already attempted to close, so you can ignore it.

If you do get a NULL-recv-callback for an older connection, it means you haven't closed it correctly (remember to set the recv callback to NULL before calling tcp_close - that way you won't get informed when the remote FIN arrives, if you don't need that). However, it doesn't hurt to always call tcp_close() when you get a NULL-recv-callback.


If it is, then you must call tcp_close() yourself. This then completes some more acking with the other machine and eventually places the tcp_pcb into the CLOSED state, and then calls the err_callback with ERR_ABRT.
No, this is wrong: the err-callback is only called in an error condition (e.g. a timeout, RST received or something like that). It is *not* called in a normal graceful-close-scenario.

At this point, the tcp_pcb is "freed" and should not be touched again.
Again, do *not* reference the pcb after tcp_close() has returned ERR_OK, please read the documentation (doc/rawapi.txt)!

A new tcp_pcb should be tcp_new()'d and then you can tcp_connect() again.

2) I try to connect from lwip but no cable is plugged in.
Lwip will try and send a SYN packet and wait for an ack. Until it gets the ack, a counter is being incremented until it times out. When it times out, it calls the err_callback with ERR_ABRT. It is not clear to me if the tcp_pcb is CLOSED at this point, but it looks like the memory is freed anyway.
From an application point of view, a pcb is always freed *before* the err-callback is called.

Should I have to call tcp_close() here? Once the memory is freed in lwip you can again tcp_new() and tcp_connect().

3) I try to connect from lwip and the cable is plugged in, but nothing is listening.
The other machine should immediately send Lwip back a rst packet. Lwip will then call the err_callback with ERR_RST. I noted though that at this point when the error callback is called, the old tcp_pcb is not yet closed nor freed.
How did you notice that? The pcb is freed after the err-callback is called. There's no need to set the state to CLOSED before freeing the memory. Please don't try to assume anything from reading the pcb contents here.

Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

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