Re: [lwip-users] ARP interfering with TCP server??

[Christiaan Simons]

address@hidden wrote on 24-10-2005
18:05:39:

> I've got a bug in my embedded product that is using lwip and maybe some
out
> there can help me find out if the bug is located in my code or in lwip.

Can you be more precise, can it also be in your contrib/port?

Some of them were created against an ancient lwip, without properly
releasing them for a specific version.

> My application is a TCP server that I've based on the 'raw api' httpd
example.
>
http://savannah.nongnu.org/cgi-bin/viewcvs/lwip/contrib/ports/msvc6/httpd.c

> (my application is not a web server but basically it does the same
> 'command/answer')
> The difference is that the webserver example closes the connection
> after each request which my server doesn't.

Beware that you are eating resources when more connections are made.

> 4) Another Command/Answer
>    I can see that an ARP request/reply is executed successfully.
>    Everything stops....
>
> The problem is related to the ARP becuase if I add a static entry in
> the ARP table it never fails.

ARP code in lwip works fine as far as I know. You say
everything stops? Can you use a debugger to see where it halts?
E.g. are your tcp timers still running? Are there more incoming packets?

Maybe it has something todo with lwip memory management. Reading
your remarks below it smels like a memory or pbuf chain issue.

Pbufs that carry the datagrams or segments are ususally about 128 bytes for
most example code. Multiple chained pbufs are required to receive or send
more than 128 bytes.
When these chains aren't handled (freed) properly, you get into all sorts
of problems.

> Also it never fails for 'Commands' smaller that 129 bytes. This made
> me think that
> it had something to do with signed/unsigned chars but I've compiled
> my code with both types.

Please let your compiler use both types (chars = signed),
lwip uses more explicit typedefs.

> If I enable debug I can see that
>  "pbuf_free: 0x2000276c has ref 1, ending here."

That only tells some pbuf memory was freed.
The "ending here" can be a bit misleading, the code will continue,
only the pbuf_free() will end at some point in the pbuf chain.

> So has anyone out there experinced this or maybe has possibilty to
> test this with
> your implementation of lwip.

I cannot verify this port since I don't run the MS compiler (or OS).

> Regards
> /Per/

Bye,
Christiaan.



This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.