dhcpcd-discuss

Re: sending custom option

Roy Marples

Fri Nov 18 15:43:17 2016

On 18/11/2016 11:34, Kirth Gersen wrote:
> our ISP here (Orange) is using custom auth for DHCPv4 & DHCPv6.
> 
> The packet to send must be exactly like this (as captured by wireshark:)
> 
> Option: (90) Authentication
>     Length: 22
>     Protocol: configuration token (0)
>     Algorithm: 0
>     Replay Detection Method: Monotonically-increasing counter (0)
>     RDM Replay Detection Value: 0x0000000000000000
>     Authentication Information: fti/xxxxxx
> 
> I've tried to do this using the autoprotocol and authtoken options
> but It doesn't work. Algo can't be 0 and RDM value neither.

OK, so there is a bug in dhcpcd.
When using a token, the algorithm field should be set to 0 (currently
it's 1).
Fixed here:
http://roy.marples.name/projects/dhcpcd/info/607ce2e466a2aaf0

This allows this config to work:
authprotocol token
authtoken 0 "" 0 fti/xxxxxx

However, then I spotted another bug (which may affect you also) where
the RDM value was double host to network translated.
Fixed here:
http://roy.marples.name/projects/dhcpcd/info/d598393ba5fa83e6

Now, you wanted an RDM value of zero, but the RFC disagrees because it
says this:
   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  Using a
   counter value such as the current time of day (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

Hopefully the above fixes will allow you to use dhcpcd authentication.
Let me know how it works out for you!

Roy

Follow-Ups:
Re: sending custom optionKirth Gersen
References:
sending custom optionKirth Gersen
Re: sending custom optionRoy Marples
Re: sending custom optionKirth Gersen
Archive administrator: postmaster@marples.name