[En-Nut-Discussion] ARP optimization deadlock

[Dusan Ferbas]

Harald,

with taking your modification into account we monitored following scenario:

After power up there is no ethernet connection. E.g. sntp (-> dns, ARP for 
gw) is requested. ARP entry is created with no ATF_COM flag and after 3 
retries (ARP request attempts) error is returned. That's expected.

---
When ethernet is plugged, there are 2 things :
1) ARP entry exists so no ARP is sent from Nut/OS

I expected that after 10 minutes ARP entry will be dismissed and everything 
will continue normally.
2) but thread NutArpExpire() is not created because this can be done only 
from NutArpCacheUpdate() which itself is called from arpin.c:NutArpInput() 
when incoming ARP is detected
(this of course can happen after a long time)

Solution for latter:    move thread running check & creation into 
NutArpCacheNew()
Sideeffect:             this also saves some time (1 if :-) ) when incoming 
ARP is processed for existing entry in ARP cache

Solution for 1st case is not simple.
         - delete ARP entry when there is no response within 3 retries ?
         - what about if 2nd thread is also waiting for this entry 
completion at a same time
         - what about to mark ARP entry with a flag when it is created (a 
kind of thread ownership for just created entry)
                 if thread marked ARP entry then it will clear such a flag 
when returning from NutArpCacheQuery()
         - when 2nd thread is entering NutArpCacheQuery(), and finds 
existing entry and entry has this flag on it means do not send ARPs
                 if flag is cleared (incomplete entry only pending in ARP 
cache) -> send ARP

Maybe others will say do not bother with these things, but case 2) is 
important even if there is currently only 1 thread requesting ARP


Dusan