dhcpcd-discuss

Hi Roy,

On Thu, Apr 26, 2018 at 8:42 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:
> On 26/04/2018 09:39, Mattieu Baptiste wrote:
>>>
>>> The attached patch should work.
>>> I'm not in a position to test it yet, maybe you could?
>>
>>
>> I spent a lot of time since a few days trying to modify dhcpcd's
>> source code with these kind of changes:
>> - changing the values of different options to try to mimic the original
>> request,
>> - changing the order of the options.
>>
>> The only time I managed to get a reply from the server is when the
>> authentication option is somewhere before the first ~160 bytes ; ie
>> not the last option of the request.
>>
>> This is totally silly. Seems the server in question is this beast:
>>
>> https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0267-HTML/7X50_Advanced_Configuration_Guide/ESMv6_IPoE_dual_stack_hosts.html#
>
>
> Well, silly or not, dhcpcd should still strive to work.
> The only issue I have with re-arranging the options is if another server
> down the road wants options in a different order.
>
> Interesting note from RFC3315:
>    Any DHCP message MUST NOT include more than one Authentication
>    option
>
> So your dibbler hack isn't compliant :(
> So let's ignore it.
>
> If you make authentication the first option in the list, does it always
> work? How about after the client id being sent? Do you want me to make some
> patches to do this for you or are you ok working on this?
>
> Whilst looking over the authentication, I did find one area on in-compliance
> in dhcpcd where RDM and replay data were not set to zero which I've added
> here:
> https://roy.marples.name/git/dhcpcd.git/commit/?id=96ef771991dfd6887502ad9011562106fe245628
>
> Roy

So, with all the patches you committed recently to support the
mandatory options, I finally managed to get a reply from the server.
I use this minimal dhcpcd config:

ipv6only
duid
authprotocol token
authtoken 0 "" 0 fti/xxxxxxx
userclass FSVDSL_livebox.Internet.softathome.livebox3
vendclass 1038 sagem
persistent
noipv6rs
allowinterfaces vlan832
interface vlan832
        ia_pd 1

The point is I think my ISP is filtering on the DUID value. In order
to have a reply from the server, I MUST use the exact same DUID that
dibbler generates the first time I launched it some months ago.
If I change one bit in it (link type, time or macaddress), the server
doesn't reply anymore.

I tried to change it with clientid, but in my comprehension it seems
limited to DHCPv4: any value I set is ignored, and a DUID is
generated.
So, I edited /var/db/dhcpcd/duid to set the value that dibbler uses...
and the server replies.
Maybe it's a filtering policy to doesn't allow the client to use
something else than the official internet boxes...

So now that the server replies, dhcpcd complains about not beeing able
to authenticate the server:
# 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 0xbea62c), next in 0.4 seconds
vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 0.9 seconds
vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 1.9 seconds
vlan832: authentication failed from fe80::ba0:bab: Operation not permitted
vlan832: broadcasting SOLICIT6 (xid 0xbea62c), next in 3.9 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

I send:
Authentication
    Option: Authentication (11)
    Length: 22
    Value: 000000de8eac8dc8f3228f6674692fXXXXXXXXXXXXXX
    Protocol: 0
    Algorithm: 0
    RDM: 0
    Replay Detection: de8eac8dc8f3228f
    Authentication Information: 6674692fXXXXXXXXXXXXXX

The server replies with:
Authentication
    Option: Authentication (11)
    Length: 27
    Value: 0000000000000000000000646863706c697665626f786672...
    Protocol: 0
    Algorithm: 0
    RDM: 0
    Replay Detection: 0000000000000000
    Authentication Information: 646863706c697665626f786672323530
(The value is the string: dhcpliveboxfr)

Maybe the replay detection in the advertise isn't correct?
Or, shouldn't I set the server authentication parameters in dhcpcd's config?

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