RE: [lwip-users] Problem with long term running of lwIP.

[Taranowski, Thomas (SWCOE)]

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: address@hidden
> [mailto:address@hidden
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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users