Re: [lwip-devel] TCP Client system fault

[Vinicius Bernardi]

Hi Simon,

[..]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.

I'm calling sigHUP from the same thread that manage all PPP stuff.

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..

I understand that, what I mean is that it's almost the same code from PPP thread already included in LWIP codes.

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?

TCP_SND_BUF ( 1500 bytes ) for example, the problem is when the buffer is bigger then this.

  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 whileconn->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!

Your suggestion here fix the bug, I can create my own thread to handle ppp, but PPP multithread should be equals 1 , that's the wrong configuration.

There is two parameters that should be config in opt.h ( or lwipopts.h ) ...

#define PPP_INPROC_OWNTHREAD     0

#define PPP_INPROC_MULTITHREADED 1

THANKS!

Now I don't know if the commented code it's necessary or not, but following the same way, there is no reason to depend's on that code, if the callback functions are optional. So I still think it's dangerous and not necessary. But it's just a guess, I don't understand the full library to have sure, that's why I'm here in the forum to find a deep understand about that.

Vinicius