Created attachment 356761 [details] rfc3442-classless-routes Description of problem: It would be useful in some cases if Fedora would support classless static route option in dhcp client Version-Release number of selected component (if applicable): Any How reproducible: Always Steps to Reproduce: 1. Set the dhcp server to distribute static routes via option 121. Using dnsmasq I set "--dhcp-option=121,172.22.0.0/16,172.22.1.2" parameter. 2. Run dhclient on fedora. 3. See "ip route" command for route information. Actual results: Static route is not set. Expected results: Static route is set and visible in ip route Additional info: http://www.faqs.org/rfcs/rfc3442.html This functionality is already in Ubuntu and Debian. They solved is by exit hook called from exit_with_hooks() function in the script: exit_with_hooks() { exit_status=$1 # Source the documented exit-hook script, if it exists if ! run_hook /etc/dhcp3/dhclient-exit-hooks "$@"; then exit_status=$? fi # Now run scripts in the Debian-specific directory. if ! run_hookdir /etc/dhcp3/dhclient-exit-hooks.d "$@"; then exit_status=$? fi exit $exit_status } In etc/dhcp3/dhclient-exit-hooks.d directory there is a file named rfc3442-classless-routes (attached). Also there is a file /etc/dhclient.conf with following lines: option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; send host-name "<hostname>"; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers;
I would much prefer ISC to add this support to dhcp rather than bolt it on with this method. In fact, I already asked about this a while ago: https://lists.isc.org/pipermail/dhcp-users/2008-December/007628.html The method that Debian is using seems to be a common suggested method to implement RFC 3442 at your site, but is still just a suggestion. What makes me nervous about this sort of thing is if we include this in Fedora, we'll have to accommodate this method even if something more official from ISC comes later on down the road. So, I haven't included anything in the Fedora package preferring instead to wait for ISC to add support. Also, what Debian is including is only a method for the client. There's no equivalent example provided for the server side. They've only added support for the client to request an option with code number 121 and consisting of an array of unsigned 8-bit integers. So this only works if you happen to be on a network that has a server set up to kick out option 121 data this way. This is the first request I've received for RFC 3442 support in the dhcp package and I'm willing to add it if there is something more solid than "this is what Debian does". I'm going to consider this closed upstream and continue to wait for ISC to add support, unless there is a demonstrable need for it in Fedora. In the end, there's nothing stopping users from adding this on their own. That's really what the hooks are for in dhclient-script.
I'm using dnsmasq as dhcp-server and I specify the option manually there. I think I saw a similar way for ISC dhcp server. Anyway I think that client support is not dependent on this. The thing is that Fedora is the only one which doesn't work fine (unlike other major linux distros, not to mention Win) in networks where classless static routing is used...
Right, there are definitely ways to implement RFC 3442 in the client and server, but no official method yet. I would prefer to wait for ISC to implement it in their code base before shipping something official. If you want to put together a README and contrib script, I am not opposed to shipping that in the /usr/share/doc/dhcp-* and /usr/share/doc/dhclient-* directories.
I need RFC 3442 support too, so chiming in with a "me too" here.
Here it is guys. Just commited into git, builds will follow. http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=commitdiff;h=fe8e8224b5cbd10550a02c6427f388cc34b4274e Would be great if you could help me with testing. What/how to test ? 1) Check documentation in dhcp-options(5) 2) server - Try to define the classless-static-routes option in dhcpd.conf in different ways. The server should refuse to start if there's something wrong with the definition. e.g. (these are wrong) option classless-static-routes "something" 192.168.1.1; option classless-static-routes 33.192.168.1.1 192.168.1.1; option classless-static-routes 30.192.168.1 192.168.1.1; option classless-static-routes 24.192.268.1 192.168.1.1; option classless-static-routes 12.192.168.1 192.168.1.1; option classless-static-routes 12.192.168 192.168.1.1 192.168.1.2; But the server should take correct definitions, e.g. (it's all on one line) option classless-static-routes 25.129.210.177.132 192.168.0.113, 7.2 dhcp-24-240.brq.redhat.com, 0 192.168.0.113; 3) client - Check ('ip route show') that client installs the routes specified in the option. - Check (use wireshark) that client requests both classless static route option and the Router option in the DHCP Parameter Request List. The Classless Static Routes option code MUST appear in the parameter request list prior to the Router option code. - If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option. - After deriving a subnet number and subnet mask from each destination descriptor, the DHCP client MUST zero any bits in the subnet number where the corresponding bit in the mask is zero. In other words, the subnet number installed in the routing table is the logical AND of the subnet number and subnet mask given in the Classless Static Routes option. For example, if the server sends a route with a destination of 129.210.177.132 (hexadecimal 81D4B184) and a subnet mask of 255.255.255.128 (hexadecimal FFFFFF80), the client will install a route with a destination of 129.210.177.128 (hexadecimal 81D4B180). - Check that the client understands classless static route option sent from other dhcp server implementation (e.g. dnsmasq). Put e.g. interface=eth1 dhcp-range=192.168.56.50,192.168.56.150,255.255.255.0,12h dhcp-option=121,192.168.66.0/24,196.168.56.1,10.0.0.0/7,5.6.7.8 into /etc/dnsmasq.conf and run 'dnsmasq -d' on server machine
dhcp-4.2.0-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/dhcp-4.2.0-4.fc14
dhcp-4.2.0-5.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dhcp-4.2.0-5.fc14
dhcp-4.2.0-6.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dhcp-4.2.0-6.fc14
dhcp-4.2.0-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.