Re: [lwip-users] tcp_enqueue problem, using socket:

[Piero 74]

Jifl,

I found the problem.

First, just for understanding, my lwip application, receives packets FROM serial port, and forward to a socket using send function.

Yes, the problem is in my driver... 
I have completely rewritten driver, starting from an old driver, and adding some features. I didn' t change a low-level function, which makes a copy between two buffers USING WORD COPY. 
This means that only even number of bytes could be copied, for odd number, a zero byte is added.
When i send small packets, and nagle is on, lwip build a big packet, but can happen, that this packet would stored in two pbus (now i'm seeing this situation in my debugger) chained, where the first has a payload with odd size. When my driver copy pbfus payload, with two different calls, insert a zero byte between them.

So... no bug in LWIP :O) ....now i'm changing this fucking function! :O!

Anyway, just a comment about lwip: 
in my situation i had a client which doesn't send an ack, because packet is corrupted, and lwip was looped tryng to resend a packet, and send function NEVER return. 
We will have similar situation if lwip try to send a packet and for a strange reason client in the other side crashes BEFORE send an ack. LWIP will block forever again.
As you said, this is the correct behaviour for socket, but, if the developer want avoid this situation, needs NON BLOCKING OPERATION FOR SEND function too (in recv operation is possible to use non blocking operation)

I think it is VERY IMPORTANT that lwip has this feauture implemented, in 1.3.0 version.

In these months i understood a lot of thing about lwip code and configuration, and ho to debug its code.... but i'm not able to do a changes like this.
Do you think someone can add non blocking flag for send??

Bye and thanks,
Piero

2008/3/20, Jonathan Larmour <address@hidden>:

Piero 74 wrote:
>
> Jifl... i use send function (socket).... i cannot change packet  in low
> level protocols


You mean you're just sending packet data from serial? I thought maybe you
were maybe redirecting entire packets including headers from serial. IF
that's not happening, that's okay.


> I'm thinking.... it could be possible a problem in my emac driver? but i
> don't know how i can debug this problem, if there is....
> can you help me?


It probably is a problem in your driver in that case.

To debug it, first start comparing what you think you're sending in the
emac driver with what wireshark reports actually got sent to find the
difference.

You can look through your driver for places where some buffer data could be
reused before it was really finished with. That sort of thing might be a cause.


Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
  **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users