dhcpcd-discuss

On 6/14/20 8:46 AM, Roy Marples wrote:
> On 14/06/2020 15:23, Bruce Ferrell wrote:
> > > You have set this config option?
> > > option classless-routes 32, 0,0,0,0, 192,0,2,135, 24, 192,168,22, 192,0,2,135;
> > >
> > > Try this instead
> > > option classless-routes 0, 192,0,2,135, 24, 192,168,22, 192,0,2,135;
> > >
> > > Roy
> >
> > It took me a bit to work that syntax out, but that's the configuration that worked for dhcpcd... And without a routers option (which, if set, breaks dhcpcd with no default route 
> > set), the windows and android devices failed with no default route. But it worked for dhcpcd.
>
> dhcpcd will work with that if a routers option is present as well.
> If not, then please tell me dhcpcd version.
>
> For reference, dhcpcd gained this option over 15 years ago and was the first open source client to support it.
>
> > I also tried:
> >
> >       option classless-routes 0, 0,0,0,0, 192,0,2,135, 24, 192,168,22, 192,0,2,135;
> >
> > Which conceptually "matches" route definitions syntactically, but is wrong, and gives a really weird routing table that doesn't work for anybody :-)
>
> No it does not match. Let me explain.
>
> The first byte is the CIDR. A default route has a CIDR of 0.
> The next CIDR bytes are the destination address. As the value is 0 for a default route it's length is 0 and thus doesn't exist in this option.
> The next 4 bytes are the gateway address.
>
> So effectively you have added this to the routing table
> 0.0.0.0      0.0.0.0        0.0.0.0 UG
>
> I would not expect that to work.

correct.  it took me a little bit to work that one out.  In "concept", I was declaring the mask and default route and gateway... That was wrong so it gave me what you illustrated.  
As you point out below, the correct syntax

> Let us look at your original route output:
> 0.0.0.0         192.0.2.135     255.255.255.255 UGH       0 0          0 eth0
>
> That matches your config option where you had a CIDR of 32, which I would not expect to work either.
>
> 0, 192,0,2,135,
> which will give this
> 0.0.0.0         192.0.2.135     0.0.0.0 UG       0 0          0 eth0
>
>
> Every DHCP client that supports this option WILL interpret 0, 192,0,2,135, correctly.
>
> > As I said, there are a LOT on non-rfc3442 compliant dhcp clients in the world and accommodating dhcpcd breaks them without doing fiddly things to assure compliant messages are 
> > ONLY sent to dhcpcd and any other rfc3442 conformant dhcp client (are there any?).
>
> And this is just bogus.
Declare it bogus if you like, but the evidence says otherwise... When I got the Raspberry PI to set proper routes, Windows and the Amazon devices all lost connection.  As I say, I 
didn't take time to check the OS X clients.  The PI version information is below. It's the 64 bit version. The regular 32 bit ones do this too.  I think we can agree the ISC dhcpd 
configuration WAS correct as the proper default route and static route was set on the PI.


#option routers 192.0.2.135;

option classless-routes 24, 192,168,22, 192,0,2,135, 0, 192,0,2,135;

With routers enabled, the PI fails to set the default route


The windows clients are on Windows 10 fully up to date (for what that's worth on windows)

sudo dhcpcd -T  eth0
dhcpcd-8.1.2 starting

more /etc/*rele*:
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1

As I said, I haven't gone back in time to actually test old distros yet, but I did find reference to this being a known (won't fix) thing on google.

The Android devices were a Samsung Note 8, a Kindle Fire 10 2019 release and several Amazon smart plugs (who knows what is in those things)


> I use a fairly complex CSR on my home network and I also send a default router option too. dhcpcd works just fine, along side dhclient on FreeBSD/OpenBSD, my kids android tablets 
> and the wifes iPhone as well as my Windows 10 gaming PC.
>
> And did you know that dhcpcd was used in android phones up to I think android-9?
> It's still used in ChromeOS last I checked.
>
> Roy 


Network and system support is what I do for a living (and have for nearly 40 years) and I think it fair to say I have a fairly complex network as well, with layer 3 switching and 
netbooting multiple system types.  Which is why I more or less ignored and manually worked around thins until I found it irritating enough to dig into and found I was NOT the only 
person to encounter the issue.