On Thu, 24 Nov 2016 at 23:46 ED Fochler <[email protected]> wrote:
> On 2016, Nov 24, at 5:38 PM, Kenneth Westerback <[email protected]> wrote: > > As is shown by the -L file, your DHCP server is configured incorrectly (a.k.a. in violation of the DHCP RFC's). In particular it is specifically FORBIDDEN to pay any attention to the static route option in the presence of a classless-static-routes option. So configuring the server to NOT have a default route in the classless-static-routes option is an error that must be fixed at the server. > > As RFC 3442 says > > "If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option." > > We abide by the RFC. Unfortunately some other OS's do not. > > .... Ken > Thank you for your feedback, Ken. You were right that my DHCP server was not redundantly specifying the default route in the classless-static-routes option. I am now a better man with a better DHCP server. There is still a resolv.conf bug, and some questionable behavior. OpenBSD is implementing routes according to RFC. However, dhclient placed both router and classless-static-routes in the Effective section of the lease, implying that dhclient took the default route from the DHCP option “router” like everyone else. If router is not effective, the lease should probably say so. dhclient showed no errors of any sort when run in debug mode for this. Shouldn’t this information be the point of showing the effective section of the lease? Excellent point! I've just committed a fix that removes both DHO_ROUTES and DHO_STATIC_ROUTES from the effective lease DHO_CLASSLESS options are present. RFC 3442 says both MUST be ignored. dhclient still fails to write resolv.conf when no default route is specified in classless-static-routes. An obscure bug to be sure, but still a bug. Even without a default route, there is no excuse for dhclient not updating /etc/resolv.conf with the DNS server specified by DHCP. This is a more complex case. Historically OpenBSD only allowed a single default route and in order to make sure the correct interface was writing out the resolv.conf file the interface providing the default route got priority. But this was implemented in a way that meant no default route == no resolv.conf being written. The historical constraint of a single default route is now history. And the case of no default route being present should not prevent the creation of a resolv.conf. ALthough whether dhclient should ensure the DNS servers are reachable is ... interesting. I will investigate this more. I'm not sure if there will be quick fix. :-( Speaking with you has made me smarter. I hope my contribution has value. ED. Shameless flattery is always welcome. :-) .... Ken
