send DHCPv6 lease events over U-Bus#369
Conversation
odhcpd currently only sends DHCPv4 lease events over U-Bus. For DHCPv6 the only option was to use a trigger hook script and then parse a lease file and diff it against previous version. This made it very inconvenient to use in cases like adding DHCP hosts to DNS server and the behavior is also inconsistent with DHCPv4 counterpart. Format of the U-Bus message is based on reply of `ipv6leases` U-Bus method. This patch is largely based on mikma@b796d61 Signed-off-by: Erin Kalousková <erin.kalouskova@nic.cz>
|
@erin-desu there are conflicts with current master, so this branch has to be rebased. |
| if (!(c->flags & OAF_DHCPV6_NA) || c->assigned_host_id > a->assigned_host_id ) { | ||
| list_add_tail(&a->head, &c->head); | ||
| if (a->flags &OAF_BOUND) | ||
| apply_lease(a, true); |
There was a problem hiding this comment.
apply_lease() is currently used for installing routes to prefixes delegated to DHCPv6-PD clients. (Ab)using it for sending ubus notifications for address leases not only hurts readability, but it is also a very slippery slope - and it already shows.
For lease renewals, this PR causes an erroneous dhcpv6.release notification to be emitted just before a dhcpv6.ack one for the same lease. Why? assign_na() is called from dhcpv6_ia_handle_IAs(), shortly after apply_lease(a, false); is called on line 1522. Note that no release actually happens from lease management perspective; this behavior is just an artifact of emitting notifications from __apply_lease().
Please see #393 for what I hope is a more maintainable counterproposal.
4 participants
odhcpd currently only sends DHCPv4 lease events over U-Bus. For DHCPv6 the only option was to use a trigger hook script and then parse a lease file and diff it against previous version.
This made it very inconvenient to use in cases like adding DHCP hosts to DNS server and the behavior is also inconsistent with DHCPv4 counterpart. Format of the U-Bus message is based on reply of
ipv6leasesU-Bus method.This patch is largely based on mikma@b796d61