[lwip-users] arp question

[Jim Gibbons]

I have caught yet another problem in my code related to ARP.  It has made me wonder if perhaps it might be wise to make some modest changes in etharp.c to protect the likes of me.

The issue is the integrity of the ARP table in a multi-tasking environment.  Three major entry points to etharp are involved.  These are etharp_timer, etharp_input and etharp_output.  All must be called by the user by some means, and all result in ARP table accesses and modifications.  If all are called from the same task, then everything will be all right, but if they are called from different tasks, problems may ensue.

Typically, etharp_output is called from the context of the TCP/IP task, in the netif upper level output function.  etharp_timer is usually called via a sys_timeout function.  It is possible to put these calls into the context of the TCP/IP task by calling the sys_timeout for the first time from the tcpip_init_done function.  But it is pretty difficult to get the etharp_input call into the context of the TCP/IP task.  (If I'm mistaken about this, please correct me.)

If calling all three of these functions from the context of the TCP/IP task isn't going to work, then another option would be to call them all from the context of some user task.  This is pretty straightforward for etharp_timer and etharp_input.  In order to get the etharp_output calls out of the TCP/IP task context, though, the outbound pbuf will have to be passed to the user task in some kind of OS message (from within netif's upper level output function).  This isn't too satisfying, either.

It seems like the best approach would be to simply protect the ARP table with a mutex (sys_sem?).  This could be done within the ARP code without too much difficulty.

Does this sound reasonable?

--

Jim Gibbons	address@hidden
Gibbons and Associates, Inc.	TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA	FAX: (408) 247-6395