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

[Teddy Zhai]

Hi,

In general, I think you should have keep these 2 changes locally. 

For the timing question, I have the same scenario where autoIP runs with different parameters, different timing parameters and number of probes. For such simple change, there should be no need to upstream.

The same applies to the 2nd question, where special treatment needs to be applied to conflicting MAC (I believe this is the only thing that worths caching).

Or, If you want to upstream, I would suggest to make a EtherNet/IP "profile" that contains all EtherNet/IP related  network stack changes and can be turned on/off in lwipopt.h.

Met vriendelijke groet / Best regards.
Teddy

On Sat, Mar 9, 2024 at 11:28 AM Matthias Dietrich via lwip-devel <lwip-devel@nongnu.org> 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.

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.

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.

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.

Regards,
Matthias

_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel