[lwip-users] possible find_arp_entry() issue?

[Ed Sutter]

Hello,
I've been tracking down a performance issue in my system and
I think I stumbled onto something...

I have my target on a network with several machines (a lot
of traffic), and I also have ETHARP_ALWAYS_INSERT set to 1.
That being said, here's what I found...

If all entries in the arp_table[] array are stamped AND the
find_arp_entry() function is called within the same
ARP_TMR_INTERVAL window, the value of global ctime and
all of the arp_table[].ctime entries will be the same.

In that case, the function find_arp_entry() will return
ARP_TABLE_SIZE, erroneously indicating that there are
no arp_table[] slots available.  This will occur because
in every case 'ctime - arp_table[i].ctime' will be zero;
hence, j will remain set to ARP_TABLE_SIZE.

If someone else can take a look at this and it is agreed
that this is a bug, I have a fix for it, so please let
me know.

Also, a minor note...
Under some extreme cases it is valid for find_arp_entry()
to return ARP_TABLE_SIZE, and in that case, the DEBUGF()
statement at the bottom of the function will attempt to
dump the content of arp_table[ARP_TABLE_SIZE].state, which
is outside the boundary of the table.  This should be
qualified with a test for the value of 'i'.

Ed Sutter

els.vcf
Description: Card for Ed Sutter