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

[Muhamad Ikhwan Ismail]

I know. But since for now we are using 1.2.0 I just locked the function to the task running it for now to prevent
preemption. But later when we integrate 1.3.0 this problem should be gone. However this does not solve original
problem raised by Thomas.

---

> Subject: RE: [lwip-users] Problem with long term running of lwIP.
> Date: Fri, 29 Feb 2008 12:34:40 +0100
> From: address@hidden
> To: address@hidden
>
> > 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

---

Climb to the top of the charts! Play the word scramble challenge with star power. Play now!