The man page of "connect" states (snippet below):
".... datagram sockets may use connect() multiple times to change their association. Datagram sockets may dissolve the association by calling disconnectx(2), or by connecting to an invalid address, such as a null address ..."
Up until 12.3.1 (and even 12.4 Beta1), if a connect() call was used on a datagram socket to disconnect an IPv4-mapped IPv6 address, the call used to complete and return back "EADDRNOTAVAIL". Internally it would indeed dissolve the current association of the connected datagram socket (i.e. subsequent calls to "send" would return back a "EDESTADDRREQ" errno).
However, starting 12.4 Beta2, if a connect() call is made on such a datagram socket which is connected to a IPv4-mapped IPv6 address, the call now returns a "EINVAL" errno. Do note that this change in behaviour is happening in this Beta release only with IPv4-mapped IPv6 addresses. Other addresses like plain IPv6 address, continue to return "EADDRNOTAVAIL" on such connect() calls which are used to dissolve the current association.
We have been able to reproduce this issue with a trivial C program that is attached to this discussion. The attached program, creates a datagram socket which then connects to a IPv4-mapped IPv6 loopback address. This connect is expected to succeed and does succeed. Once the connect is done, a next connect() is issued on the connected datagram socket, this time passing it a null address (as noted in the man page) and this call is expected to dissolve the connection association. The program expects a EADDRNOTAVAIL to be returned by this call (since that's what was being returned in all MacOS releases so far) and if some other errno gets returned then the program fails.
When the attached reproducer is run against 12.3.1 (or other previous MacOS versions or even 12.4 Beta1), the program gets the expected EADDRNOTAVAIL and when it is run against 12.4 Beta2, it gets the unexpected EINVAL errno.
Here's a sample output from 12.3.1 (the "successful" one):
$> sw_vers
ProductName: macOS
ProductVersion: 12.3.1
BuildVersion: 21E258
$> clang main.c
$> ./a.out
created a socket, descriptor=3
trying to bind to addr ::ffff:127.0.0.1:0, addr family=30
Bound socket to ::ffff:127.0.0.1:46787, addr family=30
created another socket, descriptor=4
connecting to ::ffff:127.0.0.1:46787, addr family=30
successfully connected
Disconnecting using addr :::0, addr family=30
got errno 49, which is considered OK for a connect to null address (a.k.a disconnect)
Successfully disconnected
Output from 12.4 Beta2 (the case where the behaviour has changed):
$> sw_vers
ProductName: macOS
ProductVersion: 12.4
BuildVersion: 21F5058e
$> clang main.c
$> ./a.out
created a socket, descriptor=3
trying to bind to addr ::ffff:127.0.0.1:0, addr family=30
Bound socket to ::ffff:127.0.0.1:23015, addr family=30
created another socket, descriptor=4
connecting to ::ffff:127.0.0.1:23015, addr family=30
successfully connected
Disconnecting using addr :::0, addr family=30
Got unexpected errno 22
disconnect failed: Invalid argument
Notice how the call to connect() to dissolve the connected association now returns errno 22 == Invalid Argument.
We had a look at the release notes here https://developer.apple.com/documentation/macos-release-notes/macos-12_4-release-notes but they appear to be very high level release notes and we couldn't find anything relevant related to this change. So:
Is this an intentional change? Are applications expected to account for this errno to be returned when calling connect() to dissolve a connected association of a datagram socket? If this is intentional, is there a reason why this is specific only for IPv4-mapped IPv6 address?
The man connect page also talks about using disconnectx as an alternative way to dissolve the association. This appears to be specific to MacOS systems (couldn't find it in BSD man pages for example). Is disconnectx the recommended way to do the dissociation?
P.S: I created a issue for this through the bug/feedback reporting tool (issue id: FB9996296), but there hasn't been any response to it since almost a week. So creating this thread in the forums hoping to get some inputs.
main.c
