dhcpcd-discuss

Hi Andrey

On 06/09/2018 21:28, Andrey Vakhitov wrote:
> I'm using dhcpcd 7.0.7 to delegate an IPv6 prefix for my local LAN.
>
> It's receiving the prefix from the upstream router, which in this case
>
> is an AVM FritzBox with IA_PD enabled.
>
> The IPv6 address and prefix are dynamic and changes at least once a day. 
> Dhcpcd gets RECONFIGURE6 message from the upstream router and starts 
> handling it due to “noauthrequired” option being set. Dhcpcd 
> successfully renews interface address but is unable to renew delegated 
> prefixes. It continuously sends RENEW6 but can’t process REPLY: “wan0: 
> DHCPv6 REPLY: iapd not found”. It tries to renew for ca. half hour, then 
> gives up and performs rebind. During this period my local network 
> doesn’t have correct IPv6 adresses. How can I fix it?
>
> Here is the log:
>
> ---------------------------
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: wan0: RECONFIGURE recv from 
> fe80::7eff:4dff:fe03:2c18, sending to all interfaces
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: wan0: unauthenticated RECONFIGURE6 
> from fe80::7eff:4dff:fe03:2c18
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: wan0: RECONFIGURE6 from 
> fe80::7eff:4dff:fe03:2c18
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: wan0: broadcasting RENEW6 (xid 
> 0xf49ac6), next in 9.8 seconds
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: lan0: DHCPv6 reply received but not 
> running: No such file or directory

I've pushed a change to not report strerror here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=f8f75e98201aab289f3a91ea75974b482ef9429f

And a change not to send to interfaces without a send state here:
https://roy.marples.name/git/dhcpcd.git/commit/?id=e496358e0c17ebebe7910c5a5927781fb0c24b94

> Sep 06 22:07:48 rtr dhcpcd[2438]: dmz0: DHCPv6 reply received but not 
> running: No such file or directory
>
> Sep 06 22:07:48 rtr dhcpcd[2438]: wan0: DHCPv6 REPLY: prefix mismatch

So we did attempt to renew the leased prefix, but the dhcp server claims 
there is a prefix mismatch.

> Sep 06 22:07:50 rtr dhcpcd[2438]: wan0: Router Advertisement DAD completed
>
> Sep 06 22:07:50 rtr dhcpcd[2438]: wan0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
>
> Sep 06 22:07:58 rtr dhcpcd[2438]: wan0: broadcasting RENEW6 (xid 
> 0xf49ac6), next in 20.2 seconds
>
> Sep 06 22:07:58 rtr dhcpcd[2438]: wan0: DHCPv6 REPLY: iapd not found

Now the iapd is lost, according to the dhcp server

> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: Router Advertisement from 
> fe80::7eff:4dff:fe03:2c18
>
> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: adding address 
> fd00::c2b0:ab08:4de0:dc18/64
>
> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: pltime 0 seconds, vltime 7200 
> seconds
>
> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: adding address 
> 2001:16b8:22a9:9400:c2b0:ab08:4de0:dc18/64
>
> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: pltime 3600 seconds, vltime 7200 
> seconds
>
> Sep 06 22:08:03 rtr dhcpcd[2438]: lo: deleting reject route to 
> 2001:16b8:22a8:fffc::/62

This looks like an error in dhcpcd to fix.

> Sep 06 22:08:03 rtr dhcpcd[2438]: wan0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
>
> Sep 06 22:08:18 rtr dhcpcd[2438]: wan0: broadcasting RENEW6 (xid 
> 0xf49ac6), next in 39.9 seconds
>
> Sep 06 22:08:18 rtr dhcpcd[2438]: wan0: DHCPv6 REPLY: iapd not found
>
> Sep 06 22:08:58 rtr dhcpcd[2438]: wan0: broadcasting RENEW6 (xid 
> 0xf49ac6), next in 79.6 seconds
>
> Sep 06 22:08:58 rtr dhcpcd[2438]: wan0: DHCPv6 REPLY: iapd not found

And we're now in a loop where the server can't find the binding.

dhcpcd *is* doing the right thing here.
See here:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg08453.html

If a server wants to renumber the delegated prefix, they can send the 
old prefix with a zero lifetime and the new prefix with a positive 
lifetime in the same iaid.

What they shouldn't do is lease a prefix for N seconds and then deny it 
sooner when renumbering - but this appears to be exactly what it's doing.

I've created the attached patch to enter discover if any reply is 
invalid, rather than if it's invalid and it's a rebind and it's 
delegated. I'm sure if this is the right thing to do just yet, but it 
should fix your immediate problem.

Please test it and let me know!

> ---------------------------
>
> According dump:
>
> ---------------------------

ewwww.
I prefer looking at logs I can parse in wireshark.
text dumps like that are often incomplete of critical data.

Roy

diff --git a/src/dhcp6.c b/src/dhcp6.c
index de51ee56..38de5b3e 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -3299,15 +3299,12 @@ dhcp6_recvif(struct interface *ifp, struct dhcp6_message *r, size_t len)
 			if (dhcp6_validatelease(ifp, r, len,
 			    ctx->sfrom, NULL) == -1)
 			{
-#ifndef SMALL
-				/* PD doesn't use CONFIRM, so REBIND could
-				 * throw up an invalid prefix if we
-				 * changed link */
-				if (state->state == DH6S_REBIND &&
-				    dhcp6_hasprefixdelegation(ifp))
+				/* If we can't use the lease, fallback to
+				 * DISCOVER and try and get a new one. */
+				if (state->state != DH6S_DISCOVER) {
 					dhcp6_startdiscover(ifp);
-#endif
-				return;
+					return;
+				}
 			}
 			if (state->state == DH6S_DISCOVER)
 				state->state = DH6S_REQUEST;