lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matthias Dietrich
Subject: [lwip-devel] ACD for EtherNet/IP industrial protocol
Date: Sat, 9 Mar 2024 20:26:32 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]