[En-Nut-Discussion] Re: En-Nut-Discussion] Duplicate ARPs (was: Time needed to get packet from RTL on ATmega128)

[Dusan Ferbas]

Hi Harald,

>From: Harald Kipp <harald.kipp at egnite.de>
>...
> >I did that but I am still getting 2 ARPs for 1st UDP output packet.
>
>What is the time difference between both sends?

I am getting 2 ARPs even if 2 UDPs are sent from within a thread.

     snmp_cold_start();
     link_up();

...
u_rslt SnmpTrapSend(char *packet, int length)
{
    //  Usually failure occures e.g. if ARP was unable to resolve MAC address.
     return (NutUdpSendTo(trap_sock, *pSNMPConfig->TrapAddressp, 
*pSNMPConfig->TrapPortNump
             , packet, length) < 0)
         ? FAIL : OK;
}

AFAIK NutUdpSendTo waits in NutArpCacheQuery.


>  Note the 500 ms timeout
>at
>
>    while (retries--) {
>      ...
>      NutEventWait(&((ARPENTRY *) entry)->ae_tq, 500);
>    }
>
>which is a very simple (IMHO too simple) implementation.
>
>But that's not all. If two threads enter NutArpCacheQuery(), we still
>have a problem. Both threads do not know about each other, but only one
>should send out requests. If one gives up, there is actually no reason
>for the other one to continue.

1st thread inserts entry in arp cache. It has MAC 0 and no flag set. Second 
thread can check that requested IP is already in arp cache
but has no ATF_COM set (in that case fl_send is set to send ARP request).

>My idea is to pass the query task to THREAD(NutArpExpire, arg).
>The problem would be to avoid polling the ARP table.
>What do you think?

I am fine with fl_send but there should be something else that is causing 
duplication ?


Dusan