-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DHCPv6 Server multicast handling improvements #316
Conversation
Joining a multicast group with an address that can't be received on a socket is ineffective, at least on linux. This updates the logic of NewServer in a mostly backwards-compatible way, to enable listening on arbitrary multicast addresses: * Unicast addresses see no user-visible change, but don't join a multicast group for which they don't receive traffic anyway * Multicast addresses start actually receiving traffic for the group they represent, and don't join the default group. **this is a behaviour change**: previously they would receive traffic for the default group if it was on the same port and **not** for the group they represent. I consider that previous behaviour a bug * Wildcard addresses, if on the proper port, will join both AllDHCPRelayAgentsAndServers and AllDHCPServers **this is a behaviour change**: previously only AllDHCPRelayAgentsAndServers was joined * Wildcard addresses on another port: no visible change, same as unicast case Signed-off-by: Anatole Denis <[email protected]>
This moves the implementations of the BindToInterface to the interfaces/ package, since they aren't ipv4-specific. The BindToInterface function remains in dhcpv4 (simply wraps the one in interfaces) to keep backwards-compatibility Additionally, fold bindtodevice_darwin into bindtodevice_bsd: darwin is mostly a BSD, and happens to support IP_RECVIF, so use that instead of IP_BOUND_IF, which only affects sends, not receives according to the code comments in bsd/netinet/ip_output.c as well as being v4-only Signed-off-by: Anatole Denis <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #316 +/- ##
==========================================
- Coverage 73.2% 72.78% -0.43%
==========================================
Files 76 78 +2
Lines 3728 3762 +34
==========================================
+ Hits 2729 2738 +9
- Misses 860 880 +20
- Partials 139 144 +5
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
OK, I won't worry too much about darwin then. |
Similar to server4 where the UDP connection is manually created using the socket interfaces, this creates a connection with adequate options: * SO_BINDTODEVICE or equivalent if an interface is requested * V6ONLY when supported by the operating system * Allows binding to a multicast address specifically instead of falling back to wildcard Signed-off-by: Anatole Denis <[email protected]>
c906f64
to
a8311df
Compare
v2 changed the last commit, correcting the documentation and handling the case |
Are you still testing it? |
I'm pretty sure it's still broken for darwin, but no worse than it was before, so I think it's good to go in the current state |
Summary
From the code comments in bsd/netinet/ip_output.c#L2715
IP_BOUND_IF
for darwin doesn't do anything on the receive path, only send.IP_RECVIF
however is also supported on darwin (I assume inherited from freebsd) and should do the same thingNote: I do not have access to either darwin or *bsd machines to test this change, but at least it does build. Any help / pointers for testing on those (esp. darwin, which I can't easily start in a cloud somewhere) would be appreciated
Testing
Since we can't really use default ports or require privileges in unittests, I tested the additions manually for the handling of bindtodevice.
This is a build of coredhcp with these patches, listening on wildcard addresses:
An strace log shows it joined both multicast groups (and I verified a relayed packet to
ff05::1:3
was handled):Similarly, I verified that asking explicitly to bind on
ff05::1:3
, interface srv_u, results in a socket listening on[ff05::1:3]%srv_u:547
, and the mcast group is joined (but not the other one):