Bugzilla – Bug 142955
NetworkManager sets a default gateway although the dhcp server does not supply one.
Last modified: 2008-06-25 09:53:15 UTC
I have a very small network here with one machine "server", running dnsmasq as a dhcp- and dns server. I connected with NM via an unencrypted WLAN and got the following: seife@strolchi:~> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 * 255.255.255.0 U 0 0 0 air loopback * 255.0.0.0 U 0 0 0 lo default gost.nbg.s3e.de 0.0.0.0 UG 0 0 0 air But the server does not provide a default gateway (gost.nbg.s3e.de is the server, 192.168.100.1) this is the dnsmasq config (pretty basic, the dns information comes from /etc/hosts): gost:~ # cat /etc/dnsmasq.conf domain=nbg.s3e.de dhcp-range=192.168.100.50,192.168.100.150,12h dhcp-host=00:12:79:59:37:34,192.168.100.2 dhcp-host=00:0E:35:B0:C9:9E,192.168.100.3 # Set the "all subnets are local" flag dhcp-option=3, there are two MACs configured, one for LAN and one for WLAN. I'll attach the log snippet from NetworkManager when connecting.
Created attachment 63190 [details] /var/log/messages snippet with NM messages i tried this multiple times, just to make sure that i did not make a mistake.
sorry, i forgot to set the assignee.
This is on purpose (so not a bug). If a DHCP server does not send a "routers" field, NM will set the gateway to the DHCP server as a "last resort". Is that actually a problem for you?
Hm, i actually deliberately set no gateway (because there is none :-), i believe it was to avoid long timeout. OTOH, gost.nbg.s3e.de should just return an "icmp destination unreachable" if it is "abused" as a router. Don't know ;-) I will just have an eye on "unwanted side effects" and holler if i find one. OTOH at home my dhcp server deliberately gives no gateway to prevent my kids machines to access the internet when booted into windows, (the linux setup has a static ip); so this might be a "lockdown setting" administrators might be interested in. So this might be an enhancement, don't know.
The other side is that this is a deliberate feature: Some crappy home routers have a bug where they do not set the "routers" field in the DHCP address (or they set some other non-standard field, forget). So this is a cheap bit of logic that makes everything work for them. I don't really see the downside. If the machine is not a DHCP server, you aren't any worse off than not having a router. A non-router should just reset the connection, so there is no timeout concern. And it is only affecting non-local packets, anyhow. I am inclined to not fix and close.
Marking WONTFIX.
i found a "use case". Dial in via Modem. Default route points to the providers gateway. Now i associate with my isolated WLAN. Default route points to my dhcp server / access point. Boom, internet is dead. I admit this is a somewhat obscure usecase, but it happened to me some minutes ago when i changed from wired to wireles LAN in the local network :-)
I guess one would ask, why are you doing that? ;-) So I have another question: Would you suggest "fixing" this, alleviating your problem, but at the expense of the broken routers and other beneficiaries of the "fallback" default gateway?
(In reply to comment #8) > I guess one would ask, why are you doing that? ;-) Well, i am often already dialed in and the VPN is set up when i come home. This is what mobile connectivity is good for ;-) > So I have another question: Would you suggest "fixing" this, alleviating your > problem, but at the expense of the broken routers and other beneficiaries of > the "fallback" default gateway? I'd appreciate a config option. But i'll accept this as LATER since there is more important stuff to fix right now. Timo suggested an "intelligent" setting of the default route: if there is already a default route and DHCP does not provide one, then do not set it. This will get easier as soon as NM really starts managing dialup, then we can build a really intelligent solution.
Alright. Let's revisit later.
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(