Re: [lwip-devel] ACD for EtherNet/IP industrial protocol

[Matthias Dietrich]

Hi all,

Here is a short update on my progress.

I've renamed the ACD timing constants and made them configurable.
However they're still defined in prot/acd.h. Should these be better
defined in opt.h with appropriate documentation? The timings are now
expressed in milliseconds.

Since there were no unit tests for ACD, I've added some tests to verify
that everything behaves as expected.

As already mentioned in the bug report #58139, I also noticed through
the unit tests that the current implementation does not follow the RFC
(the IP address is only considered valid *after* the last announce
frame, although the RFC states that it should be considered valid after
the *first* announce). I've reverted to the RFC behavior, but added
another compile-time configuration to use the "valid after last
announce" behavior if that's still required by someone.

Then I noticed another feature missing for EtherNet/IP: the RFC states
that there shall be no further probing after the IP address is
considered valid. However EtherNet/IP expects to continue probing in the
"ongoing phase". So I added another compile-time configuration to enable
that behavior, but it's disabled per default.

Finally I had missed yet another requirement for EtherNet/IP: we need to
be able to enable/disable ACD at runtime. Currently, that could be done
"manually" for static IP addressing, but not when using DHCP, since the
DHCP+ACD handling is completely done in dhcp.c with no external access.

So we'd need something to mark whether ACD is enabled/disabled, ideally
at the netif level. I thought about using a netif flag for that, but I
noticed there's just one bit free in the 8-bit netif flags, and I guess
you'd rather keep it for future use and not for one optional feature
that's only going to interest a couple people ;-) So I'll probably try
to add another optional variable in the netif structure, which will only
be active if the "runtime ACD selection" is selected at compile-time.

> > > The second issue arises in case of an address conflict. EtherNet/IP
> > > also requires that a device shall save the ARP packet that triggered
> > > the conflict. The current ACD callback propagates only the netif and
> > > the ACD state, but we have no reference to the specific ARP packet
> > > that triggered the conflict. My first  idea was to modify the ACD
> > > callback's prototype to also include a pointer to the pbuf or to the
> > > etharp_hdr containing the ARP packet. I haven't tried that yet, but
> > > this change would kind of break backward compatibility since
> > > existing applications would require to modify their callback.
> > > Another option I considered was to extend the netif's extended
> > > status callback with a new event, reporting IPv4 address conflicts.
> > > We could then extend the union carrying the extended status callback
> > > arguments and provide a pointer to the ARP packet. In that case, the
> > > ACD callback would not be changed and there would be no backward
> > > compatibility issue, just an additional extended status event.
> >
> > Hm, would it work to provide a callback "current ARP apcket" analogue to
> > the "current IP header" macros?
> Thanks for the hint. I'll look into that. I haven't seen anything
> similar in ARP yet, but that could be a less intrusive option.
Concerning my callback issues, I found out that modifying the ACD
callback's prototype would not help at all. DHCP has its own ACD
callback which is not modifiable by users (like AutoIP). So if a
conflict arises when using DHCP, there's no way to notify the
application from the ACD callback.

I ended up using the extended status callback with a new event. This one
now gets called whenever a conflict is reported, whether from DHCP,
AutoIP or static addressing.

To access the "current ARP packet", I added something similar to the
"current IP header" macros. This is passed in the extended status
callback argument structure.

I have only tested this with unit tests and on Linux for the moment.
I'll try to run it through the EtherNet/IP certification tests next.

I can start publishing some patches for review if you want, or I can
wait until it's completely tested.

Regards,

Matthias