Re: [lwip-devel] ARP code question

[address@hidden]

Am 10.09.2021 um 14:49 schrieb Bill Auerbach:
> Hello,
>
>  
>
> I’m trying to figure out how to get lwIP to not do ARP requests to the
> PC on an open connection where there are packets constantly being sent
> to and from lwIP and the PC.
>
>  
>
> The protocol for this product is every 5mS a packet is sent to the PC -
> to do real-time control.  I warned the PC code developers (3^rd party)
> that you can’t rely on this with TCP/IP.  It turns out that it actually
> works very well.  There is much less bobble than I expected.  Good
> enough for their application.
>
>  
>
> But while they are running, after about 25 hours, there is an ARP “who
> is” request from lwIP to the PC. This affects the timing, which you
> might expect, but it also leads to a 200-300mS stall in wire shark for
> this stream of data.  They can handle some bobble but they do throw an
> error and shutdown with the 200mS error.  This may relate to the stalls
> I was seeing some months ago which I never definitely got to the bottom of.
>
>  
>
> It feels like a timer wrap problem.  I’ve been studying the code and I
> am trying to figure when or how it goes to the
> ETHARP_STATE_STABLE_REREQUESTING_1 or ETHARP_STATE_STABLE_REREQUESTING_2
> state which I believe it what starts off the ARP request.

Re-requesting ARP is expected, but should not stall the connection: the
re-request phase is done before the ARP entry times out. Plus it is done
as unicast (in contrast to the broadcast which is done when the address
is not known). You should see such re-requests every couple of minutes,
as the default ARP timeouts is 5 minutes if I remember correctly.

>
> I was going to submit this as a bug, because I think an open connection
> constantly sending and receiving should not need ARP at all.  I don’t
> see in the RFC whether this behavior is allowed or not allowed.  There
> is a hint about ARP not using a lot of bandwidth.  And I see
> “gratuitous” ARPs mentioned as well. It seems that the spirit of the
> protocol is that it is used to resolve the physical address.  With an
> opening connection the physical address is known and cannot change.

I can't cite an RFC, but the point here is that the ARP cache should not
trust incoming IP packets but refresh itself only using ARP packets.
That's a security mechanism and it should *not* interfere with what
you're doing.

In the past, we had ETHARP_TRUST_IP_MAC to update the ARP cache from
incoming IP packets, but that's both insecure and slow (ARP cache lookup
for every received IP packet!), so we removed it ~5 years ago.

If you do see this problem every ~25 hours, there should be a bug
somewhere and I guess you'll need to dig into it :-(

Regards,
Simon