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

[Matthias Dietrich]

Hi Simon,

Thanks for the feedback.

Le 12/03/2024 à 19:29, Simon Goldschmidt a écrit :
> Hi Mathias,
>
> I'd very much like to upstream those changes! I'd welcome lwIP being
> "Ethernet/IP-ready"!
That's good news! I suggest then to to this in 2 steps, first making the
timings configurable and then tackling the callback issue.

I'll need some time to prepare and test this.

> On 09.03.2024 20:26, Matthias Dietrich via lwip-devel wrote:
> > Hi all,
> >
> > I am looking into using lwIP for a device communicating with the
> > EtherNet/IP industrial protocol. I might be mistaken, but it seems
> > that lwIP currently does not meet all the requirements set by the
> > EtherNet/IP specifications.
> >
> > The first issue I identified concerns the timings, but that would
> > probably be the easiest to solve. EtherNet/IP does not use the
> > standard timings defined in RFC 5227. The ACD timings are currently
> > defined in prot/acd.h. They are expressed in seconds and are not
> > modifiable by users. I am looking into expressing the timings in
> > milliseconds and wrapping the default timing definitions with #ifndef
> > so that we could override them in lwipopts.h if needed (like for most
> > lwIP settings). Would you consider such a change acceptable? I would
> > be willing to contribute a patch if you're OK with it.
>
> This is a good idea. Maybe we can also document somewhere which timings
> would be required for Ethernet/IP?
Yes, sure. In another reply Teddy suggested defining a "profile" for
EtherNet/IP. If this is a viable option, we could then have a define in
lwipopts.h to automatically use the EtherNet/IP timings. If not, setting
these manually would be totally acceptable for me.

By the way, I would then suggest prefixing the timings with "ACD_".
Otherwise, something like RATE_LIMIT_INTERVAL or PROBE_WAIT might be a
bit too unspecific and prone to future name collisions once they appear
among all other defines in lwipopts.h. But that's a detail.


> > 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.

> > Although I know that some of you on this mailing list are familiar
> > with EtherNet/IP, I have to admit that my second issue with the
> > callbacks might be very specific and I would understand if such
> > changes were considered too specific to be ever included in a general
> > purpose stack like lwIP.
>
> Looking forward to seeing your devices with lwIP ;-)
I'll let you know when these are ready ;-)


Regards,

Matthias