dhcpcd-discuss

On 6/14/20 3:37 AM, Roy Marples wrote:
> 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

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.


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 :-)


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?).


rfc3442 seems to introduce a conundrum into the concept of "it just works" for universal address and route distribution.