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 <[EMAIL PROTECTED]>: > > 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
