RE: RE : RE : [lwip-devel] [bug #19206] the ARP layerisnotprotectedagainstconcurrent access

[Goldschmidt Simon]

Hi,


> Patch with last fix. Always a solution to find for :
> 
> etharp_arp_input(netif, (struct eth_addr*)(netif->hwaddr), 
> p); //FB Not really nice, but internal driver state in 
> "unknown" in tcpip.c 

Nice patch. Although I had two input functions in my patch (one for IP,
one for ARP), to keep tcpip_thread from finding out what kind of frame
this is, I think this solution is also good.
Using netif->hwaddr is better than the other solution, anyway. The
ethernetif.c example has redundant storage for the MAC address, which
(as I think) is not necessary.

I would take the comment "Not really necessary, but..." out, though. It
IS necessary to protect the user from having a memory leak if sending
all incoming frames to the tcpip_thread.
Also, I'm not sure if we need the define ETHARP_TCPIP_ETHINPUT. Maybe to
reduce code size for PPP, but all other configurations should use this,
so...

Oh, and for some (old?) compilers, you have to put pre-processor
statements at the beginning of the line, or they will go unnoticed.
Last but no least, I'm not sure if the ARP timer should be an option
(again, I don't know if PPP needs that one, I think not).

OK, one more: while you're at it, can you modify one of the ports (e.g.
unixsim) to use the new functionality? I'll do the same for the windows
port (I'm currently modifying it, anyway).

Other than that, I think the patch solves our problem. So please, go
ahead and check it in (as long as the other developers agree :)

Simon