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, [email protected] <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
