Peer addresses from accept() and getpeername() are different.

[metamon123]

Hi. In my environment (Apple M1 + KENS version), struct sockaddr addr passed to accept() and getpeername() are filled with different peer address.

I expected both client_addr are same because of the following reasons.

• From accept(2)

  • The argument addr is a pointer to a sockaddr structure. This structure is filled in with the address of the peer socket, as known to the communications layer.

• Some stackoverflow Q&As saying that peer addresses gotten from accept() and getpeername() are same.
  • https://stackoverflow.com/questions/22904179/difference-in-address-returned-by-getpeername-and-accept-c-socket
  • https://stackoverflow.com/questions/2104495/extract-ip-from-connection-that-listen-and-accept-in-socket-programming-in-linux

However when I ran SingleEcho test, the addresses were different, as follows;

• accept(server_fd, &client_addr, ...); -> client_addr.sin_addr : 10.0.0.1
• getpeername(client_fd, &client_addr, ...); -> client_addr.sin_addr : 10.0.0.2

Is it normal that these addresses are different? If not, does accept() somehow behave in different way under KENS system?

Thanks.

[Pusnow]

It seems a KENS's bug. Thank you for reporting this. We'll fix in the next release.

Until then, use getpeername.

[metamon123]

Thanks for your reply! I'll just simply ignore the addr filled by accept().

By the way, after it's analyzed and fixed, it would be grateful if you share the fix commit/release to me or on this thread. I'm just curious of why the bug happened. (In case if you remember this thread after the fix 😅 )

[Pusnow]

This is fixed in the latest release (3.3.2). It was due to wrong implementation in the solution binary.