I've been investigating an issue with the SO_OOBINLINE socket option. When that option is disabled, the expectation is that out-of-band data that is sent on the socket will not be available through the use of read() or recv() calls on that socket.
What we have been noticing is that when the socket is bound to a non-loopback address (and the communication is happening over that non-loopback address), then even when SO_OOBINLINE is disabled for the socket, the read()/recv() calls both return the out-of-band data. The issue however isn't reproducible with loopback address, and read()/recv() both correctly exclude the out-of-band data.
This issue is only noticed on macos. I have been able to reproduce on macos M1, following version, but the original report which prompted me to look into this was reported on macos x64. My M1 OS version is:
sw_vers
ProductName: macOS
ProductVersion: 14.3.1
BuildVersion: 23D60
Attached is a reproducer (main.c.txt - rename it to main.c after downloading) that I have been able to develop which reproduces this issue on macos. When you compile and run that:
./a.out
it binds to a non-loopback address by default and you should see the failure log, resembling:
...
ERROR: expected: 1234512345 but received: 12345U12345
To run the same reproducer against loopback address, run it as:
./a.out loopback
and that should succeed (i.e. no out-of-band data) with logs resembling:
...
SUCCESS: completed successfully, expected: 1234512345, received: 1234512345
Is this a bug in the OS? I would have reported this directly through feedback assistant, but my past few open issues (since more than a year) have not even seen an acknowledgement or a reply, so I decided to check here first.