On 18/01/2012 6:29 PM, Simon Goldschmidt wrote:
Ian Wilson<i.wil...@considered.com.au> wrote:
This all works for the first connection. The problem is that incoming
packets are not "detected" by lwip_select for subsequent connections to
the listener (after closing the first connection of course).
[..]
Is this something obvious? If not I will provide some code and wireshark
and lwip debug logs.
Any suggestions on the best lwip debug settings that would help detect
where the problem is?
No obvious errors come to mind and I don't have any obvious debug settings for
you, either. If it helps, select relies on two things: a counter to know when
to wake threads (increased on rx packets, decreased when reading I think) and a
linked list of semaphores to wake the threads (there's only one thread in the
list for you). If there's something wrong in that code, select doesn't work
although you could actually read data.
It would highly help to know if just reading data works, i.e. if select isn't
working or if there's no data coming in. For that, you could set a receive
timeout and just call recv every time select times out.
Simon
Simon, thanks.
I have solved the (embarrassing) problem.
While implementing some hacks to test your idea of whether the data was
present and it was just select that was failing I came to the
realisation that I had the first parameter of lwip_select wrong - I had
read the docs (quickly) as it being the count+1 of the number of fd
rather than "one more than the maximum fd value". On the first
connection, lwip gave the accepted socket an fd==1 so it worked. On the
second fd==2 etc - so the lwip_select was not inspecting the full range
of fd present.
Sorted now. Silly me. Thanks,
Ian
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
