[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
- [lwip-devel] ACD for EtherNet/IP industrial protocol,
Matthias Dietrich <=