dhcpcd-discuss

On 2017-10-25, Roy Marples wrote:

> Hi Jakub
>
> On 24/10/2017 23:15, Jakub Jankowski wrote:
> > I am trying to debug an issue I have with DHCPv6 IA_PD on my ISP's network. 
> > I'm using dhcpcd-7.0.0-rc3 with the following configuration:
[...]
> > So far so good. After 20 minutes (as per T1) my dhcpcd sends Renew packets, 
> > which don't get any reply from my ISP side.
> > And that's what makes me wonder - source address in those Renews is my 
> > link-local address:
> >
> > initial Reply:
> >   12 20:48:17.353653 fe80::224:14ff:feef:72ff -> fe80::baae:edff:fe76:98d6 
> > DHCPv6 346 Reply XID: 0xfedcba IAA: 2a02:168:<redacted1> CID: 012345...
> >
> > subsequent Renews:
> >   13 21:08:17.360399 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> > DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
> >   14 21:08:26.492686 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> > DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
> >   15 21:08:43.910163 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> > DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
> >   16 21:09:18.636170 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> > DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
> >   17 21:10:26.345222 fe80::baae:edff:fe76:98d6 -> 2001:1620:<redacted3> 
> > DHCPv6 288 Renew XID: 0xabcdef CID: 012345... IAA: 2a02:168:<redacted1>
> >
> > All those Renews are for both IA_NA and IA_PD (with T1=T2=0).
> >
> > I'm quite surprised to see a link-local used as source here, when there is 
> > a global-scope unicast address assigned to that interface already. But I 
> > might be misinterpreting RFC3315 section 16:
> >
> >     When a client sends a DHCP message directly to a server using unicast
> >     (after receiving the Server Unicast option from that server), the
> >     source address in the header of the IP datagram MUST be an address
> >     assigned to the interface for which the client is interested in
> >     obtaining configuration and which is suitable for use by the server
> >     in responding to the client.
> >
> > And although RFC3633 section 8 says
> >
> >     Delegated prefixes are not associated with a particular interface in
> >     the same way as addresses are for address assignment, and the rules
> >     described in section 16, "Client Source Address and Interface
> >     Selection" of RFC 3315 do not apply.
> >
> > it also says
> >
> >     When a requesting router sends a DHCP message directly to a
> >     delegating router using unicast (after receiving the Server Unicast
> >     option from that delegating router), the source address SHOULD be an
> >     address from the upstream interface and which is suitable for use by
> >     the delegating router in responding to the requesting router.
>
> I'll guess that you started dhcpcd on a specific interface as it's bound to 
> lladdr.
> You can either start dhcpcd in master mode (ie don't specify an interface on 
> the command line or pass it the -M flag or add master to dhcpcd.conf) or try 
> the latest git head where I think I've fixed this here:
> https://roy.marples.name/git/dhcpcd.git/commit/?id=ef53a17e01fc25aea22717373afcfcd9e35c85b5
>
> That should always let the kernel decide what address to send from, as long 
> as it's on the interface.
>
> Let me know if that fixes it for you!

Thanks! I've build dhcpcd from HEAD and indeed the subsequent Renew 
packets now originate from my IA_NA address.
I'm still puzzled by the fact I'm not getting any responses from my ISP's 
DHCP server, but I think my side is now doing everything as expected.
I'm having a case opened with my ISP, let's see if they can figure it out.


Cheers,
 Jakub.

--
Jakub Jankowski|shasta@xxxxxxxxxxx|http://toxcorp.com/
GPG: FCBF F03D 9ADB B768 8B92 BB52 0341 9037 A875 942D