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

[Simon Goldschmidt]

Hi Mathias,

I'd very much like to upstream those changes! I'd welcome lwIP being
"Ethernet/IP-ready"!

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?

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

> It's also possible that I totally missed an obvious way to achieve the same 
> goal. Either way, I'd be happy to know what you think about it.

I'm not sure, but I can't think of something out of the box.

> 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 ;-)

Regards,
Simon