Re: [lwip-users] strange TCP behavior, connection stalls

[Sergio R. Caprile]

> * known-to-work application:
> esp-open-rtos comes with some examples, including a simple 'http_get'
[...]
> and now it exhibits the same behavior as my own application:

That's why I recommended using apps in the contrib tree, those are the 
only "known to work" apps for many lwIP users. Vendor provided apps 
sometimes are just demos, sometimes not.

> * API:
> My actual application uses the same functions from lwip as the simple 
> http_get example: socket(), connect(), lwip_read(), lwip_write() etc

OK, socket API, I can't help with that. You can wait to see if someone 
drops in or open a new thread with "socket" in the subject.
Anyway, that is vendor example, not lwIP example, you should check 
thoroughly, sometimes vendor code is a demo, or a hack, or a great piece 
of code.

> I forgot to mention that esp-open-rtos is a port of FreeRTOS, so yes,
> indeed, an RTOS. No other tasks (threads) are created in the user
> application, but the SDK itself is creating one or more threads in
> the background for wifi, lwip, etc

The socket API allows some use of multithreading, but you can't call 
some lwIP functions from "main context" and also from interrupt context, 
those are not reentrant functions.
Can you guarantee that on your port ?


> You are suspecting a bad port or network driver. If that's the case,
> I should probably report a bug against esp-open-rtos. Is there a way
> I can test whether this is the case?

I always suspect that, because I did write a port and a driver and I 
know lwIP works ;^), all problems I've had were, well, my own. Most 
problems reported are either a bad driver, [vendor code] polling the 
controller and not extracting all frames, [vendor code] getting frames 
on interrupts and running lwIP on main context, and the like.
Running an app from the contrib tree can tell you if port+driver run OK. 
If it works, there's a problem in your app. If it doesn't, then there's 
a problem in lwIP or port+driver; given that others have run lwIP OK in 
that scenario, it is quite likely the problem is not in lwIP. There can 
be mistakes, but I haven't seen something as flagrant as you mention.