Bug 165698
| Summary: | NM can not connect to wireless if the dhcp does not offer a default route | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ralf Ertzinger <redhat-bugzilla> |
| Component: | NetworkManager | Assignee: | Christopher Aillon <caillon> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-07 22:02:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ralf Ertzinger
2005-08-11 12:55:59 UTC
*** 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;
|