Skip to content

fix: encode connection data port values in host byte order#599

Open
MrAlaskan wants to merge 1 commit into
EIPStackGroup:masterfrom
MrAlaskan:fix/cipconnectionmanager-correct-connection-data-port-endianness
Open

fix: encode connection data port values in host byte order#599
MrAlaskan wants to merge 1 commit into
EIPStackGroup:masterfrom
MrAlaskan:fix/cipconnectionmanager-correct-connection-data-port-endianness

Conversation

@MrAlaskan

Copy link
Copy Markdown

Summary

This PR fixes the port values returned by GetConnectionData and SearchConnectionData so that they are encoded with the correct byte order in Connection Manager responses.

Problem

AssembleConnectionDataResponseMessage() currently writes connection_object->originator_address.sin_port and connection_object->remote_address.sin_port directly into the CIP response with AddIntToMessage(). However, both fields come from sockaddr_in and are stored in network byte order.

AddIntToMessage() encodes the provided integer value as a CIP little-endian UINT. On little-endian hosts, directly passing a network-order port therefore causes the returned port number to be byte-swapped in the response payload.

This makes the Connection Manager diagnostic response inconsistent with the actual network connection state and can mislead clients or conformance tools that rely on the reported Originator and Target port values.

Changes

  • Convert originator_address.sin_port and remote_address.sin_port from network byte order to host byte order before encoding them into the response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant