Assumes that AF_INET is defined as 2

[arbrauns]

The ENIP spec (The CIP Networks Library Volume 2 (Edition 1.33), Table 2-4.4 CIP Identity Item) requires that:

sin_family: Shall be AF_INET = 2. This field shall be sent in big endian order.

The mention of AF_INET here is a red herring; since this is a network protocol, the name of the C library constant is irrelevant, it's the value 2 that counts. Still OpENer simply fills the protocol field with the value of the C standard library AF_INET constant, whose value is implementation-defined (that's why there's a constant definition for it) - for example, zephyr defines it as 1. This obviously breaks recipients who actually check the value of sin_family, which includes but is probably not limited to Allen-Bradley ControlLogix PLCs.

As a quick fix for this I modified

OpENer/source/src/enet_encap/endianconv.c

Line 205 in db1d6bf

AddIntToMessage(htons(AF_INET), outgoing_message);

and

OpENer/source/src/enet_encap/endianconv.c

Line 212 in db1d6bf

AddIntToMessage(htons(AF_INET), outgoing_message);

to instead use a constant that is always defined as 2. A proper solution would be:

1. auditing the entire stack for uses of implementation-defined constants in protocol fields
2. fixing the stack to actually use the value of SocketAddressInfoItem.sin_family as set e.g. here:

   OpENer/source/src/cip/cipioconnection.c

   Line 600 in db1d6bf

   common_packet_format_data->address_info_item[j].sin_family = htons(AF_INET);

   
   I spent a while scratching my head as to why my changes to those values weren't changing what I'm seeing on the network; they're never actually read as far as I can tell.

[MartinMelikMerkumians]

Thanks for the input, I will check and change accordingly