This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 639935 - RFC3442 (The Classless Static Route Option) support in dhclient
RFC3442 (The Classless Static Route Option) support in dhclient
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 641598 642596 (view as bug list)
Depends On: 516325
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-04 07:05 EDT by Jiri Popelka
Modified: 2011-04-12 17:27 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-0.8.3.996-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-01 20:50:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch (1.90 KB, patch)
2010-10-04 07:05 EDT, Jiri Popelka
no flags Details | Diff
simpler patch (1.64 KB, patch)
2010-10-15 09:04 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
Description Jiri Popelka 2010-10-04 07:05:17 EDT
Created attachment 451377 [details]
patch

Hello,

dhcpd/dhclient in Fedora-14 have had support for RFC 3442 implemented since version 4.2.0-4.fc14. See bug #516325.
It's my unofficial implementation but I hope upstream will ever implement it in a similar way.

I was looking into NM to see how much work it would take to add a support for RFC 3442 to NM
and discovered that it's actually already there but for arbitrary format:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
see https://lists.isc.org/pipermail/dhcp-users/2008-December/007629.html

My format looks like:
option classless-static-routes = array of (destination-descriptor ip-address);

I'm adding a tiny patch, that adds a support for my format of classless-static-route option,
which I hope is same/similar as the official one will be once the upstream implement the RFC 3442.

I have been testing it and it works great.

thanks,
Jiri
Comment 1 Jiri Popelka 2010-10-15 09:04:14 EDT
Created attachment 453725 [details]
simpler patch

Actually the

 	if (tmp > 0)
-		addr_len = ((tmp - 1) / 8) + 1;
+		addr_len = (tmp + 7) / 8;

change is not needed because of the 'if (tmp > 0)' condition.
Comment 2 Dan Williams 2010-10-20 19:10:27 EDT
Given the example from the code:

0 192.168.0.113 25.129.210.177.132 192.168.0.113 7.2 10.34.255.6

what route should that actually be?  Can you break this down for me a bit more?  I can't quite seem to match up the above bits with the examples I have already when I'm writing the testcases.  Thanks!
Comment 3 Jiri Popelka 2010-10-21 06:46:06 EDT
Oh yeah, this example is 'just an example'.
I should have put there something making more sense.
Anyway this string
"0 192.168.0.113 25.129.210.177.132 192.168.0.113 7.2 10.34.255.6"
is array of 3 routes (destination-descriptor router's-ip-address)

dest.descriptor    |  router
-------------------+----------------
0                  |  192.168.0.113
25.129.210.177.132 |  192.168.0.113
7.2                |  10.34.255.6

- the first line means that the default (destination 0.0.0.0/0) router is 192.168.0.113
- the second line means that there's a route with destination 129.210.177.128/25 and router address 192.168.0.113.
This one is example taken from RFC3442:
'For example, if the server sends a route with a destination
of 129.210.177.132 and a subnet mask of 255.255.255.128,
the client will install a route with a destination of 129.210.177.128.'
- the third line means that there's a route with destination 2.0.0.0/7 and router address 10.34.255.6

So after the binding the 'ip route show' on client's machine shows:
129.210.177.128/25 via 192.168.0.113 dev eth0 proto static
2.0.0.0/7 via 10.34.255.6 dev eth0 proto static
default via 192.168.0.113 dev eth0 proto static

Did I answer your question ?
Comment 4 Dan Williams 2010-10-21 14:35:24 EDT
Yeah, you did, thanks.  Reworked and pushed to git.  I had to rewrite a bunch of the code to be able to do more complete unit testing of the DHCP RFC3442 route parsing.

8b006f331dc28f61cf063b2e8415305041e0ca7c (master)
59b65bb1240b0b15c423fe8926bb34876bdd6847 (0.8.x)

thanks!
Comment 5 Fedora Update System 2011-02-24 01:05:58 EST
NetworkManager-0.8.3.995-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc14
Comment 6 Fedora Update System 2011-02-24 01:09:28 EST
NetworkManager-0.8.3.995-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc13
Comment 7 Fedora Update System 2011-02-24 15:57:10 EST
NetworkManager-0.8.3.995-1.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 NetworkManager'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc14
Comment 8 Dan Williams 2011-02-25 02:03:47 EST
*** Bug 642596 has been marked as a duplicate of this bug. ***
Comment 9 Dan Williams 2011-02-25 02:04:10 EST
*** Bug 641598 has been marked as a duplicate of this bug. ***
Comment 10 Fedora Update System 2011-02-25 18:42:48 EST
Package NetworkManager-0.8.3.996-1.fc14:
* should fix your issue,
* was pushed to the Fedora 14 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.996-1.fc14'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.996-1.fc14
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2011-02-25 18:45:48 EST
Package NetworkManager-0.8.3.996-1.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.996-1.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.996-1.fc13
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2011-03-01 20:49:08 EST
NetworkManager-0.8.3.996-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2011-03-03 04:47:13 EST
Package NetworkManager-0.8.3.997-1.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.997-1.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.997-1.fc13
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2011-03-24 23:30:09 EDT
NetworkManager-0.8.3.998-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.998-2.fc13
Comment 15 Fedora Update System 2011-04-12 17:27:59 EDT
NetworkManager-0.8.3.998-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.