dhcpcd-discuss

On 14/06/2020 06:26, Bruce Ferrell wrote:
> On 6/13/20 6:45 PM, Roy Marples wrote:
> > On 14/06/2020 01:30, Bruce Ferrell wrote:
> > > Standards are a wonderful thing... Until people don't follow them and things 
> > > that don't work.
> >
> > Agreed. If there were no standards there would just be chaos, so follow the 
> > standard :)
> >
> > > So, completely following this particular RFC, results in a LARGE number of 
> > > android based devices (phones, tablets, IoT devices etc) that don't work 
> > > correctly... Unless someone is willing to do a LOT of very "fiddly" 
> > > configuration to accommodate this.
> > There is nothing fiddly about setting up the routes correctly in any DHCP 
> > server really.
> >
> > Why don't you tell me how you want the routes to look and I'll tell you how to 
> > setup your DHCP?
> >
> > Roy
> Roy,
>
> I got the delivered routes to work for dhcpcd with the dhcpd.conf entries I 
> detailed earlier... And that broke the android and windows dhcp clients.  I 
> didn't check the OS X clients. I just reverted until I can make suitable 
> adjustments.  I suspect OS X broke as well, just because they worked before.
>
> The "fiddly" part isn't setting the routes, but in knowing what clients are 
> likely to be rfc3442 compliant by their MAC address. What it appears is needed 
> is MAC prefix match lists to deliver the non-rfc3442 compliant configuration to 
> those client types (selected on the assumption that those MAC prefixes will use 
> a non-rfc3442-compliant dhcp client) and deliver the rfc3442 configuration to 
> dhcpcd and the like.
>
> The problem here, I believe, that in the past rfc3442 has largely been ignored 
> in things like android, IoT devices and, in general, dhcp clients (the vast 
> majority of client implementations).
>
> I haven't done very deep testing yet (older distros etc), but the evidence of 
> making dhcpd configuration work correctly for dhcpcd and finding that 
> configuration broke everything else in my network, certainly suggests that as a 
> possibility.  Googling the question and finding a significant number of similar 
> queries over time with the same issue and no real resolution would seem to 
> strengthen that possibility.
>
> Obviously, the implementation of rfc4332 in dhcpcd seems to be correct per the 
> document, but it would seem the majority of dhcp server and client 
> implementations are only built to the earlier 1997 standards set out in rfc2131/32.
>
> Even if the server side can be made to be rfc3442 compliant (obviously, it can) 
> this still leave a world full of non-compliant and incompatible client 
> implementations to be considered and accommodated.

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