Fix IPv6 setup under MacOS when binding to "" #392
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Setting IP_MULTICAST_TTL and IP_MULTICAST_LOOP does not work under MacOS when the bind address is ""
Codecov Report
@@ Coverage Diff @@
## master #392 +/- ##
==========================================
- Coverage 92.21% 92.19% -0.03%
==========================================
Files 4 4
Lines 2941 2945 +4
Branches 375 376 +1
==========================================
+ Hits 2712 2715 +3
- Misses 154 156 +2
+ Partials 75 74 -1
Continue to review full report at Codecov.
|
Member
Author
|
Next PR will enable IPv6 in the CI |
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared lister/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 10, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 14, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4 dual-stack configurations. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Since we allow shared listener/responder sockets, with IPv4 only sockets now, the macOS error address in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 14, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. Removing the InterfaceChoice.Default config when IPv6 is enabled would be a major breaking change. Instead, inform the user with an error log message and a DeprecationWarning that this is not a working configuration. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Also don't use a shared listener/responder sockets for dual-stack mode. Using a shared socket for IPv4 and IPv6 is especially problematic on macOS, where the kernel does not support this and even rejects socket options for IPv4 multicast in this case. With a separate IPv4 socket, this actually fixes the IPv4 multicast query sending when using the default interface. The sending will only fail on the IPv6 socket, so IPv4 requests will make it through. With that, the macOS error addressed in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 14, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. Removing the InterfaceChoice.Default config when IPv6 is enabled would be a major breaking change. Instead, inform the user with an error log message and a DeprecationWarning that this is not a working configuration. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Also don't use a shared listener/responder sockets for dual-stack mode. Using a shared socket for IPv4 and IPv6 is especially problematic on macOS, where the kernel does not support this and even rejects socket options for IPv4 multicast in this case. With a separate IPv4 socket, this actually fixes the IPv4 multicast query sending when using the default interface. The sending will only fail on the IPv6 socket, so IPv4 requests will make it through. With that, the macOS error addressed in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 14, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. Removing the InterfaceChoice.Default config when IPv6 is enabled would be a major breaking change. Instead, inform the user with an error log message and a DeprecationWarning that this is not a working configuration. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Also don't use a shared listener/responder sockets for dual-stack mode. Using a shared socket for IPv4 and IPv6 is especially problematic on macOS, where the kernel does not support this and even rejects socket options for IPv4 multicast in this case. With a separate IPv4 socket, this actually fixes the IPv4 multicast query sending when using the default interface. The sending will only fail on the IPv6 socket, so IPv4 requests will make it through. With that, the macOS error addressed in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
agners
added a commit
that referenced
this pull request
Apr 14, 2025
For IPv6, a shared listener/responder socket is not really possible when sending to link-local IPv6 multicast addresses (ff02::/16): The kernel needs to know which interface to use for routing. On IPv4, this is historically a bit different, the kernel just uses what it deems the primary/best route interface based on the routing table. But for IPv6, a message is rejected by Linux with OSError no 99 "Cannot assign requested address" and OSError no 65 "No route to host" on macOS. Removing the InterfaceChoice.Default config when IPv6 is enabled would be a major breaking change. Instead, inform the user with an error log message and a DeprecationWarning that this is not a working configuration. As a further cleanup, move the socket options for sending multicast packets out of the common socket creation code. For listen only sockets those settings are not needed. Also don't use a shared listener/responder sockets for dual-stack mode. Using a shared socket for IPv4 and IPv6 is especially problematic on macOS, where the kernel does not support this and even rejects socket options for IPv4 multicast in this case. With a separate IPv4 socket, this actually fixes the IPv4 multicast query sending when using the default interface. The sending will only fail on the IPv6 socket, so IPv4 requests will make it through. With that, the macOS error addressed in #392 is not a problem anymore. Actually, we would like to get an exception in case we get into this combination, so remove the explicit exception handling.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MacOS when the bind address is ""