dhcpcd-discuss

On Sun, Apr 29, 2018 at 1:46 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:
> On 29/04/2018 11:00, Mattieu Baptiste wrote:
>>
>> Alas with the patch, I have the same "authentication failed" behavior:
>> # dhcpcd -Bd
>> dhcpcd-7.0.3 starting
>> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' PREINIT
>> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' CARRIER
>> DUID 00:01:00:06:20:f6:4d:7a:00:0d:b9:33:8e:8c
>> vlan832: IAID ff:00:03:40
>> vlan832: IAID 00:00:00:01
>> vlan832: reading lease `/var/db/dhcpcd/vlan832.lease6'
>> vlan832: soliciting a DHCPv6 lease
>> vlan832: delaying SOLICIT6 (xid 0x2bfb39), next in 0.0 seconds
>> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 1.0 seconds
>> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
>> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 1.9 seconds
>> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
>> vlan832: broadcasting SOLICIT6 (xid 0x2bfb39), next in 3.6 seconds
>> vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
>> ^Creceived SIGINT, stopping
>> vlan832: removing interface
>> vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' STOPPED
>> dhcpcd exited
>>
>> Here is the full dhcpv6 advert the server send me:
>> DHCPv6
>>      Message type: Advertise (2)
>>      Transaction ID: 0x191db8
>>      Identity Association for Prefix Delegation
>>          Option: Identity Association for Prefix Delegation (25)
>>          Length: 41
>>          Value: 000000010000b98400032a00001a00190003f4800003f480...
>>          IAID: 00000001
>>          T1: 47492
>>          T2: 207360
>>          IA Prefix
>>              Option: IA Prefix (26)
>>              Length: 25
>>              Value: 0003f4800003f480382a01cb0007c87f0000000000000000...
>>              Preferred lifetime: 259200
>>              Valid lifetime: 259200
>>              Prefix length: 56
>>              Prefix address: 2a01:cb00:7c8:7f00::
>>      Server Identifier
>>          Option: Server Identifier (2)
>>          Length: 20
>>          Value: 0002000005584445534841594553535544524f54
>>          DUID: 0002000005584445534841594553535544524f54
>>          DUID Type: assigned by vendor based on Enterprise number (2)
>>          Enterprise ID: Orange (formerly 'France Telecom') (1368)
>>          Identifier: 4445534841594553535544524f54
>>      Client Identifier
>>          Option: Client Identifier (1)
>>          Length: 14
>>          Value: 0001000620f64d7a000db9338e8c
>>          DUID: 0001000620f64d7a000db9338e8c
>>          DUID Type: link-layer address plus time (1)
>>          Hardware type: IEEE 802 (6)
>>          DUID Time: Jul 10, 2017 16:36:42.000000000 CEST
>>          Link-layer address: 00:0d:b9:33:8e:8c
>>      Authentication
>>          Option: Authentication (11)
>>          Length: 27
>>          Value: 0000000000000000000000646863706c697665626f786672...
>>          Protocol: 0
>>          Algorithm: 0
>>          RDM: 0
>>          Replay Detection: 0000000000000000
>>          Authentication Information: 646863706c697665626f786672323530
>>      Preference
>>          Option: Preference (7)
>>          Length: 1
>>          Value: ff
>>          Pref-value: 255
>
>
> WOW!
> You're using token authentication, but the token you're sending does not
> match the token being sent back. This is not what I expected.

Yes, that was my first thought.

> Can I see your working dibbler configuration please?
> Looking at the dibbler documentation (I can't read the source, it hurts my
> eyes and I don't understand c++ too well) they don't even have an option for
> sending token based authentication which is what it's actually sending ....

They don't support the required options directly, but you can set the
options manually. Here is the configuration:
script "/etc/dibbler/radvd.sh"
downlink-prefix-ifaces "none"
iface "vlan832" {
  pd
  option 16 hex 00:00:04:0e:00:05:73:61:67:65:6d
  option 15 hex
00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33
  option 11 hex
00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:XX:XX:XX:XX:XX:XX:XX
  option 11 hex
00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:XX:XX:XX:XX:XX:XX:XX
}

Don't pay attention to the dublicate "option 11". In fact it's due to
a dibbler bug that don't set the auth option anymore in the "DHCPv6
request" if we don't set the option twice (it only sets it in the
DHCPv6 solicit).

> But it might we we need two tokens, 1 the server expects and 2 the client
> expects. I've always taken the assumption that both are the same.

Exactly, the server sends the different auth token "dhcpliveboxfr".
I think dibbler doesn't care about the authentication server response.

> Test this new patch for auth.c
> It disables the returned token check. If this works then I guess we need an
> option to specify the receive token as well as the send token.

Yeah, seems to work fine!
# dhcpcd -Bd
dhcpcd-7.0.3 starting
vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' PREINIT
vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' CARRIER
DUID 00:01:00:06:20:f6:4d:7a:00:0d:b9:33:8e:8c
vlan832: IAID ff:00:03:40
vlan832: IAID 00:00:00:01
vlan832: reading lease `/var/db/dhcpcd/vlan832.lease6'
vlan832: soliciting a DHCPv6 lease
vlan832: delaying SOLICIT6 (xid 0x861cf0), next in 0.8 seconds
vlan832: broadcasting SOLICIT6 (xid 0x861cf0), next in 1.1 seconds
vlan832: validated using 0x00000000
vlan832: ADV 2a01:cb00:7c8:7f00::/56 from fe80::ba0:bab
vlan832: broadcasting REQUEST6 (xid 0xb0e0e3), next in 1.0 seconds
vlan832: validated using 0x00000000
vlan832: REPLY6 received from fe80::ba0:bab
vlan832: renew in 49290, rebind in 207360, expire in 259200 seconds
lo0: adding reject route to 2a01:cb00:7c8:7f00::/56 via ::1
vlan832: writing lease `/var/db/dhcpcd/vlan832.lease6'
vlan832: delegated prefix 2a01:cb00:7c8:7f00::/56
vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' BOUND6
^Creceived SIGINT, stopping
vlan832: removing interface
vlan832: executing `/usr/local/libexec/dhcpcd-run-hooks' STOPPED
dhcpcd exited

-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."