[lwip-users] Two Questions - general list question and loopif/transmit/receive bug

[Scott Taggart]

Hi,

First, a list administration question:  is sending email the only way to 
access the list?  Most forums allow you to browse the messages, click on 
and respond right in that message.  I know I can browse the messages but it 
seems like we are forced back into email to respond.  Very hard to follow 
the threads and respond in the correct place in the thread hierarchy.  Am I 
missing something?

--------

I have LWIP ported and running on a PC for test-tool purposes.  I have it 
running in multi-threaded mode.  I run using the loopback interface.  When 
I was first bringing the stack up, I just looped the output packets right 
back into the input side but I hit the dreaded bug #2595.  I see the code 
in loopif.c:

                /**
                 * workaround (patch #1779) to try to prevent bug #2595:
                 * When connecting to "localhost" with the loopif interface,
                 * tcp_output doesn't get the opportunity to finnish sending the
                 * segment before tcp_process gets it, resulting in tcp_process
                 * referencing pcb->unacked-> which still is NULL.
                 *
                 * TODO: Is there still a race condition here? Leon
                 */
                sys_timeout( 1, loopif_input, arg );

So, my questions are:
1) Has this been fixed?  If so, where is the fix posted.  If not, any ideas 
on what it will take to fix it (please point me at the suspected code).
2) I don't understand why the TCP stack expects a return from a transmit 
before a receive comes in.  This seems like a huge hole and it seems like 
it would be hit at other times too since receives can come in at any 
time.  Can someone elaborate on what this bug is and why it is occurring 
(by this, I mean why is it that the stack is sending before the send 
path/data structures are fully initialized)?

I would like to make it so that there are not timing delays between my 
transmits and receives.  As it is in the same code above, there is a 
guaranteed delay between the send and receive.

Thanks,

Scott