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): NetworkManager-0.4-34.cvs20050729 How reproducible: Always Steps to Reproduce: 1. Set up dhcp server without "option routers" 2. try to connect with NM 3. Actual results: Connect fails Expected results: connect succeeds Additional info:
*** 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: Index: src/dhcp-manager/nm-dhcp-manager.c =================================================================== 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 @@ goto out; 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) goto out;