[jaunty] option rfc3442-classless-static-routes causes missing routes

[Bogdan Butnaru]

EDIT: The original description seems wrong. You should probably read my first comment below for an updated diagnosis. I let the original description stand in case it's relevant.

******
Hello! I've just updated to Jaunty and I encountered this bug. I'm not sure it's a nm-applet bug or not, I'm attaching it here in hope someone can track down the source.

A bit of history: when I updated to Intrepid, there was an "Auto eth0" wired network in its settings that didn't work well and that I couldn't edit. I posted a bug somewhere (sorry, can't seem to find it now) and somebody said it was because of an entry /etc/network/interfaces. I assumed it was caused by my tinkering and just commented out that line. Things worked correctly then.

Now I updated to Jaunty, and the first thing I noticed is that I had no Internet access, although I was connected to my LAN. What I noticed:

1) There was again an "Auto eth0" entry in Network Manager's list. It was editable (I could change its name, at least), unlike in Intrepid.
2) The LAN card received an address, so something was working, but there was no route set for the wider Internet.
3) Sure enough, there was an "auto eth0" entry in /etc/network/interfaces. No idea how it got there. There was also a commented-out line "#iface eth0 inet dhcp", which I think is the line I had commented out in Intrepid.
4) With this setup, I could tell Network Manager to turn off and on the network, and it got an IP each time but no default route. There was only a route for 192.168.1.0/24 and one for 169.254.0.0/16.
5) If I ran "sudo dhclient eth0" by hand, it got me a correct default route, but no 169.254.0.0/16 route or IP.
5) I commented out the eth0 line in /etc/network/interfaces, added a new wired connection in nm-applet (everything default except the name), and now nm-applet does everything correctly. I get a correct route each for 192.168.1.0/24, 169.254.0.0/16 and 0.0.0.0/32 (via my router).

All this shouldn't happen. It was actually very hard to figure out in Intrepid, and if I hadn't remembered to look in /etc/network/interfaces it would have taken me a lot of time to figure it out now, too.

Here's a log of everything if it helps:

# This is the state I got after my first boot with Jaunty:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:22:15:95:14:b8
          inet addr:192.168.1.66 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::222:15ff:fe95:14b8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:564 errors:0 dropped:0 overruns:0 frame:0
          TX packets:155 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:35890 (35.8 KB) TX bytes:31225 (31.2 KB)
          Interrupt:252

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:250 errors:0 dropped:0 overruns:0 frame:0
          TX packets:250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16088 (16.0 KB) TX bytes:16088 (16.0 KB)

$ sudo dhclient eth0
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:22:15:95:14:b8
Sending on LPF/eth0/00:22:15:95:14:b8
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 192.168.1.66 from 192.168.1.254
DHCPREQUEST of 192.168.1.66 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.66 from 192.168.1.254
bound to 192.168.1.66 -- renewal in 34799 seconds.

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

# Here I clicked on the "Auto eth0" connection in nm-applet to tell it to reconnect. Then:
bogdanb@mabelode:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp

$ sudo vim /etc/network/interfaces

# edited out the "auto eth0" route
# deleted the "Auto (eth0)" connection in nm-applet
# added a new wired connection with default settings
# connected to it, and:

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

[Bogdan Butnaru (bogdanb)]

Hello again. I had a different issue with dhclient that I meant to report separately, but it seems the problem above was related to it. There seems to be something wrong with the option rfc3442-classless-static-routes in dhclient.conf. Check this out:

$ sudo killall -9 dhclient
# now nm-applet tells me the network is disconnected, which is true:

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface

# I removed the leases file:
$ sudo rm /var/lib/dhcp3/dhclient.leases

# Checked that in dhclient.conf the rfc3442 option is enabled
$ grep rfc3442 /etc/dhcp3/dhclient.conf
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
 rfc3442-classless-static-routes;

# And now run dhclient:
$ sudo dhclient eth0
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:22:15:95:14:b8
Sending on LPF/eth0/00:22:15:95:14:b8
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 192.168.1.66 from 192.168.1.254
DHCPREQUEST of 192.168.1.66 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.66 from 192.168.1.254
bound to 192.168.1.66 -- renewal in 39964 seconds.

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

# Everything seems OK. Now I run again dhclient, with the same configuration:
$ sudo dhclient eth0
There is already a pid file /var/run/dhclient.pid with pid 16328
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

parse_option_param: Bad format a
Listening on LPF/eth0/00:22:15:95:14:b8
Sending on LPF/eth0/00:22:15:95:14:b8
Sending on Socket/fallback
DHCPREQUEST of 192.168.1.66 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.66 from 192.168.1.254
bound to 192.168.1.66 -- renewal in 33985 seconds.

# Note above the 'parse_option_param: Bad format a' error. The gateway route is not added anymore:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

# Now I commented-out the rfc3442 option in dhclient.conf
$ grep rfc3442 /etc/dhcp3/dhclient.conf
#option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
# rfc3442-classless-static-routes;

# And I run again dhclient:
$ sudo dhclient eth0
There is already a pid file /var/run/dhclient.pid with pid 16394
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

/var/lib/dhcp3/dhclient.leases line 22: no option named rfc3442-classless-static-r...

[Bogdan Butnaru (bogdanb)]

Moving this to dhcp-client, as that seems to be the package with the bug.

[Martijn vdS (martijn)]

I also see this problem, it's also fixed when disabling all references to rfc3442 in dhclient.conf

[Alexia Death (alexiade)]

Also seeing it on a network that uses 192.168.1.254 as default route, not on several others. Took me a while to figure out why this one connection was giving me trouble. The issue annoing, because this is default configuration of the speedTouch home routers that are very common around my area. About one in three AP-s is a speedtouch, because thats what the leading ISP sets up with its home solution connections.

[Alexia Death (alexiade)]

Adding that for me the issue also seems to have been cured by removing references to rfc3442 from dhclient conf.

[marmuta (marmuta)]

This came up on the forums too recently.
http://ubuntuforums.org/showthread.php?t=1044323

Could you please run a full packet dump with the following (replace eth0 with your network interface).
 sudo tcpdump -i eth0 -s 1500 -w tcpdump.dat

Try to reproduce the missing route issue in another terminal with
 sudo dhclient eth0 -r; sudo dhclient eth0

Then please stop tcpdump (Ctrl+c) and post the resulting tcpdump.dat.

[_tom_ (tom-gufler)]

I'm using a wireless connection, networkmanager, but there is no default route to gateway after the connection to the router is established. I can connect to the router (10.0.0.138), but I have to create after every reboot a new default route (sudo route add default gw 10.0.0.138).

Problem only exists in jaunty, no problems in intrepid.

Hope the attached tcpdump helps.

[marmuta (marmuta)]

Thank you _tom_, the dump looks good. I can try to reproduce this now.

[Åskar (olskar)]

Here is another dump running tcpdump and doing this:

1. Connect to the wireless network

(Internet does not work)

2. Running sudo dhclient eth0 -r; sudo dhclient eth0

(Internet does work)

[_tom_ (tom-gufler)]

Same here:
Either I run

sudo route add default gw 10.0.0.138

or

sudo dhclient eth0 -r; sudo dhclient eth0

to get a working internet connection

[marmuta (marmuta)]

Does it still work when you run 'sudo dhclient eth0' twice? This is what failed for the bug submitter.

Thanks for the second dump, it's interesting to see that both show pretty much identical dhcp responses.

[marmuta (marmuta)]

Ok, I can reproduce it reliably now. Above is the configuration for dhcp3-server to get the same dhcp responses as in the dumps.
I can see what the bug submitter described with:

sudo dhclient eth0 -r
--> ok, no routes
sudo dhclient eth0
--> ok, all routes there
sudo dhclient eth0
--> default gateway missing from the routes

[marmuta (marmuta)]

Here is a small patch for dhcp3-client 3.1.1-5ubuntu2 that fixes this in my test setup.
The documentation states that REBOOT can be processed as BOUND, so this is what I changed there. Before the routes were added only in the initial BOUND case, whereas now subsequent REBOOT cases are covered as well.

[Åskar (olskar)]

Do you have a PPA I can test this with marmuta?

[Åskar (olskar)]

This is no longer a problem for me, anyone else can confirm as fixed?

[Dutch Gecko (dutch-gecko)]

I upgraded to Jaunty last Friday (after release) and seem to be having this problem. I'll see if the workarounds posted here fix it to confirm.

[Dutch Gecko (dutch-gecko)]

Yep, exact same problem for me. I've also attached a dump, showing

dhclient -r eth0 ; dhclient eth0; dhclient eth0

Commenting out lines relating to rfc3442 in dhclient.conf fixed the issue as well.

[marmuta (marmuta)]

Apparently this was fixed in Karmic starting with dhcp3 3.1.2-1.

Quote from the changelog:
 * debian/rfc3442-classless-routes: also run for REBOOT reason (closes:
    #515756)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515756

[Roy Sindre Norangshol (norangshol)]

I'm not sure if this is related, but I've also have had some issues with dhclient not fetching the default route from my speedtouch home router. I went digging a bit and noticed my speedtouch handing out some kind of Microsoft proprietary classless static routing 249 instead of the default classless static route 121 from the official RFC. Removing the rfc3442-classless-static-routes makes the router issue a normal default route (dhcp option 3). I've made a blog post on it here: http://www.roysindre.no/a/2009/11/05/dhclient-classless-static-route-bug/

[oliver (oliver-schinagl)]

I just like to note, that this still happens today.

I just installed 10.04 and updated it right away on my gf's Dell Vostro 1700 using an intel a/b/g wireless. It used to be pre-installed with win vista, she downgraded a year ago to XP; and now she dualboots and initially had no gateway (and no internet basically).

The workaround of adding the default gw worked of course, and commenting the rfc3442-classless-routes in the config made it all work again. The router/modem in question is a Thomson SpeedTouch.

Digging through the dhcp replies with wireshark made me find Roy's post #21 actually.

[Jamie Strandboge (jdstrand)]

Marking fixed as per comment #20.

Roy and oliver, if you are still having your issues, please file a new bug.