Red Hat Bugzilla – Bug 165698
NM can not connect to wireless if the dhcp does not offer a default route
Last modified: 2007-11-30 17:11:11 EST
Description of problem:
NM seems to expect the dhcp server to deliver a default route when connecting to
a wireless access point. If no default route is offered, the following appears
in the syslog and connecting fails:
dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1
for sub-path eth1.dbus.get.routers
NetworkManager: <WARNING> (): get_ip4_uint32(): error calling 'routers', DHCP
daemon returned error 'org.freedesktop.DBus.Error.UnknownMethod', message
'Method "routers" with signature "" on interface "com.redhat.dhcp.dbus.get"
doesn't exist '.
The connection is then torn down.
The dhcp server offers an IP address, a netmask, a broadcast address and a DNS
server, which is enough for the case in question.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up dhcp server without "option routers"
2. try to connect with NM
*** Bug 165699 has been marked as a duplicate of this bug. ***
I think the way we handled this before switching to dhcdbd was to use the
address of the DHCP server as the default gateway... we should probably be
doing that here too.
First, sorry for the double entry, bugzilla threw some errors at me when
submitting it the first time.
What is wrong with having no default gateway if DHCP does not offer one? Some
things work just fine that way, so there may actually be a reason for the
behaviour. I do noth think that wildly guessing gateways gets us anywhere.
Most things require a gateway, and most people will be in a situation where a
gateway is required and given. I'm not sure it's worth special-casing the "no
gateway" instance here and changing a bunch of code. Having a gateway shouldn't
hurt you here and it allows us to localize the change down to a specific spot
with only a 4 line difference, instead of going through the code and making sure
all the spots that use IP4Config info are OK with not getting a gateway.
The problem should now be fixed in NM CVS the way I describe above.
Yes, there will be a default gateway in this scenario. It will just not be
supplied by the DHCP server, but by the VPN connection running over the link.
VPN just needs to reach the next hop, which is within the ethernet broadcast domain.
I'm not disagreeing from you on a technical standpoint, I just think that the
case can be fixed with a much smaller, more localized change to the code (which
isn't even a hack!) than going through and changing the default gateway
assumption in the rest of the code.
Is the change you made already in CVS? Which file should I look at?
src/dhcp-manager/nm-dhcp-manager.c, revision 1.9:
RCS file: /cvs/gnome/NetworkManager/src/dhcp-manager/nm-dhcp-manager.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- src/dhcp-manager/nm-dhcp-manager.c 13 Jul 2005 16:58:13 -0000 1.8
+++ src/dhcp-manager/nm-dhcp-manager.c 11 Aug 2005 13:31:50 -0000 1.9
@@ -479,7 +479,11 @@
if (!get_ip4_uint32s (manager, dev, "routers", &ip4_gateway, &count) || !count)
- goto out;
+ /* If DHCP doesn't have a 'routers', just use the DHCP server's address as
our gateway for now */
+ if (!get_ip4_uint32s (manager, dev, "dhcp_server_identifier", &ip4_gateway,
&count) || !count)
+ goto out;
if (!get_ip4_uint32s (manager, dev, "domain_name_servers", &ip4_nameservers,
&num_ip4_nameservers) || !num_ip4_nameservers)