Re: [lwip-devel] TCP Client system fault

[address@hidden]

Vinicius Bernardi wrote:
> [..]1 - tcpip_thread ( internal thread for LWIP )
> 2 - PPP + GSM AT commands, my own thread to coordinate PPP and AT commands to 
> get connected ( this thread it's my own code, but it's also based on PPP thread 
> from LWIP, I use SIGHUP, and other ways to coordinate and keep PPP activated.

There's potential for threadin issues here: you must watch out to no 
directly call into PPP code - e.g. just calling sigHup from here is not 
allowed since it directly calls into the PPP parts that are not locked 
for multithreading - this way, you get a race condition.

> 3 - TCP connection, here I have just 1 netconn connection open, if I loose 
> connection or my data application detects some failure, I reestablish the 
> connection, sometimes even the GPRS connection.
> So based on your questions, I'm not using threads for connection.

You do (your PPP thread), but that might be OK or not..

> And in my tests netconn_write does not block up to end of transmission, it's 
> true only in cases that the buffer it's smaller then NET_SND_BUF size,

What's that NET_SND_BUF? Do you mean TCP_SND_BUF?

>   if it's bigger, the remaing data it's queued but the semaphore at netconn_write it's 
> realeased, and when this situation occur with the case that I had described ( the ACK 
> came from network in a specific situation, the code that generate the EVENT to let 
> application known about the transmission success, then I have the fail situation about 
> semaphore and data corruption ) as the event it's optional to be "installed or 
> not" the callback function, I can't see why there is a reson to call do_writemore 
> inside that code, as it's not called for all situations of config.

I still don't see how this can happen unless your threading setup is 
broken: the lwIP core is only allowed to be used from one thread at a 
time. Being like that, there cannot be an ACK coming in while 
conn->state == NETCONN_WRITE, simply because incoming packets are not 
processed while netconn_write is underway.

The only situation this can happen is when input packets are processed 
from a different thread than tcpip_thread. In your case, this might mean 
that input packets are passed into lwIP from your PPP thread, which 
would be wrong. You should use tcpip_input() instead to get the packets 
into tcpip_thread before passing them up the stack.

In any case, applications will stop working correctly if your remove the 
code from sent_tcp() like you suggested!

Simon