MacOS 12.4 Beta 2 - Change in behaviour of connect() system call for datagram sockets for IPv4-mapped IPv6 addresses

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.

Answered by DTS Engineer in 711945022

P.S: I created a issue for this through the bug/feedback reporting tool (issue id: FB9996296)

Thank you. That’s the best way to handle regressions like this.

but there hasn't been any response to it since almost a week.

I had a quick look at your bug and it’s definitely landed in the right place.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

P.S: I created a issue for this through the bug/feedback reporting tool (issue id: FB9996296)

Thank you. That’s the best way to handle regressions like this.

but there hasn't been any response to it since almost a week.

I had a quick look at your bug and it’s definitely landed in the right place.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you very much for replying.

I had a quick look at your bug and it’s definitely landed in the right place.

I will wait to hear back there, then.

One small related question - are changes like these (at this low level of the OS) documented some place in the releases? This is more for future reference so that we can take a look at them before filing any issues.

are changes like these (at this low level of the OS) documented some place in the releases?

No. Changes that have a wide-ranging impact are documented in the release notes (which you’ve already found) but a change like this would be unlikely to make that cut. And that’s assuming that this was a deliberate change, rather than fallout from some other change, and I suspect that the latter is more likely.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

macOS 12.4 GA has been released a few days back and even 12.5 Beta version. Both these versions continue to have this bug. On the official feedback issue that was submitted, I haven't received any response. It's a bit disappointing that the Beta OS was tested, an issue was identified and feedback was logged but yet the bug made it to the GA version without receiving any response on the feedback issue.

As far as I know, the feedback assistance tool is the official recommended tool for reporting these issues. Is there anything we could have done differently to try and get attention to this issue? Some other channel or issue tracker? The feedback issue has the necessary context and details of which project this affects and how widely that project gets used and the impact of this bug. So we were hoping we would get some attention on it. Furthermore, this isn't really an one off issue, there's at least one other issue which we have filed that hasn't received any response.

As far as I know, the feedback assistance tool is the official recommended tool for reporting these issues.

Correct. And, and as I mentioned above, this bug definitely made it to the right place. At that point it’s up to the relevant engineering team to investigate and fix, and they set their own priorities based on all the other demands on their time.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

MacOS 12.4 Beta 2 - Change in behaviour of connect() system call for datagram sockets for IPv4-mapped IPv6 addresses
 
 
Q