I've been using the tcpip_input mechanism, which I think Frederic introduced awhile back, which looks to be a precursor to the 1.3 mechanism, as the ARP handling is done within the context of tcpip(core) thread.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Goldschmidt Simon > Sent: Friday, February 29, 2008 3:35 AM > To: Mailing list for lwIP users > Subject: RE: [lwip-users] Problem with long term running of lwIP. > > > Another possible cause (I have seen this) is that after the ARP entry > expired, > > and the client sends the pbuf chained, got queued in ARP layer, an ARP > request > > is sent. As soon the polling thread gets the ARP REPLY, it then > updates the > > table and try to send the queued data (in the thread itself). > > The problem was, my low_level_output was not protected, hence the > chances are > > there that both tcpip thread (sending a TCP packet)and the polling > thread access > > low_level_output simulataneously and corrupted the index of my > Ethernet buffer > > descriptor. The TCP was retransmitted as it should, but the UDP data > was lost, hence the echo stopped. > > I guess this is fixed with lwIP 1.3.0 (if you adopt your drivers): > The ARP layer is now called from within the tcpip_thread by setting > netif->input > to ethernet_input() instead of ip_input(). Resultingly, your driver > should not > call the ARP functions directly in your ethernetif_input function. > > This was a design error in lwIP multithreading. > > Simon. > > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/lwip-users
