dhcpcd-discuss

Thanks for the reply Roy (been waiting on it :))
My code is based on 7.2.3 so it will be difficult for me to test it for
dhcpcd-8* versions. I understand and appreciate your support for this.
If you send patches, I can test it and get back to you.

Thanks,
Shweta

On Thu, Dec 12, 2019 at 6:12 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi
>
> Firstly, sorry about the delay - I've been knee deep in working on
> dhcpcd-9. It's now in a state I can look into addressing a few other
> things.
>
> On 05/12/2019 12:27, Shweta Kalyani wrote:
> > Hi Roy,
> >
> > We are using DHCPCD version 7.2.3.
>
> For reference, I've tested dhcpcd-7.2.3, dhcpcd-8.1.2 and the latest
> dhcpcd-9 code against wide dhcp6s.
>
> > The CDRouter reported a PD renumbering test case failure for IA_PD.
> > Below is a description of the same:
> >
> >      step 1. Change the client's DHCPv6 binding to use the new IPv6
> >              prefix specified by the testvar "dhcpv6WanAssignNextPrefix"
> >      step 2. Verify DHCPv6 client sends DHCPv6 Renew or Request
> >      step 3. Verify Renew or Request contains IA_PD option (26) for
> >              same prefix
> >      step 4. Send valid DHCPv6 Reply with new prefix
> >      step 5. Verify client updates router advertisements on LAN with new
> >              prefix information
> >      step 6. Send pings from LAN client to an IPv6 remote host on the
> >              WAN to verify connectivity with new prefix
> >      step 7. Restore client's original prefix by repeating Steps 1
> >              through 5 using original IPv6 prefix
> >      step 8. Send pings from LAN client to an IPv6 remote host on the
> >              WAN to verify connectivity with original prefix
> >
> >      Reference: IETF RFC 3633 Section 12.1 "Requesting router behavior"
> >
> >      Upon the receipt of a valid Reply message, for each IA_PD the
> >      requesting router assigns a subnet from each of the delegated
> >      prefixes to each of the links to which the associated interfaces are
> >      attached, with the following exception: the requesting router MUST
> >      NOT assign any delegated prefixes or subnets from the delegated
> >      prefix(es) to the link through which it received the DHCP message
> >      from the delegating router.
> >
> > The issue lies at step 5. The dhcpcd client fires a DELEGATED6 event but
> > the $new_delegated_dhcp6_prefix is missing due to which the DUT is
> > unable to update RA on LAN with new prefix.
> > Please find attached dhcpcd-hook.log (has dhcpcd environment variable
> > info), dhcpcd.log and wan captures.
> >
> > Would really appreciate your help on this.
>
> I cannot replicate your issue at all - in all cases renumbering the
> prefix delegation still has the address in both the DELEGATED6
> environment and added the downstream interface.
> I can also see that when it fails
>
> The big difference though is that your reply has two prefix delegations
> whereas wide dhcp6s can only send the one. The first (old) delegation
> has zero lifetime and this also could be something too look at.
>
> I am currently unable to test using ISC dhcpd because it segfaults on my
> router (also unsure how to set it up for prefix delegation). I'll try
> and resolve this first - might take a while as compiling on an ERLITE is
> dog slow and I don't want to update the NetBSD on it right now for other
> reasons.
>
> If I sent patches, can you test them against dhcpcd-8.1.2 or are you
> dead set on using dhcpcd-7.2.3? I ask because I don't actively support
> dhcpcd-7 aside from security issues ...... but this is a very
> interesting issue to solve regardless.
>
> Roy
>