Do not default to a /24 when DHCP doesn't specify netmask

[Robert Collins]

 affects ubuntu/network-manager

Just had a bizarre network at heathrow:
Retrieved the following IP4 configuration from the DHCP daemon:
address 10.231.33.227
netmask 255.255.255.0
broadcast 10.231.33.255
gateway 10.231.32.1
nameserver 192.168.22.22
nameserver 192.168.22.23
domain name 'hatbl.btopenzone.com'

Now, I'm not exactly sure what windows does, but it clearly works.

In this case, the 'ip route add default via 10.231.32.1 dev wlan0'
command fails (no such process) because there is no route to
10.231.32/24

Adding a manual route thusly:
ip route add 10.231.32.1 dev wlan0
allows the default route to be added (and the network then works fine -
see for instance me filing this bug report).

I suggest a) checking for insane DHCP parameters, and b) issuing a
direct route as above when discovered - it's almost certain to work.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Chris Crisafulli (itnet7)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Anand Kumria (wildfire)]

The inability to support insane network configurations is definately a problem with the current development release.

However it is not clear that this kind of intelligence should be automated.

Whilst the solution that Robert suggests obviously worked, how does one detect a that the network is really a /23 rather than the advertised /24?

I do not think there is any sensible automatic method by which this can be achieved.

Personally I would recommend 'wontfix'ing this bug -- because there has been no confirmation that this is incorrect network configuration is still live at Heathrow (there is a reason for you to get to London now, Robert).

Also -- has there been any confirmation from anyone that Windows actually produces anything sensible with this set of DHCP options?

I suspect that the default router is set that way deliberately, and that the nameserver returns something on-link for every DNS query. Once you have given you credentials(^Wcredit card) it probably kicks the DHCP server to give you better ones.

Cheers,
Anand

[Robert Collins (lifeless)]

If I get the chance to test that specific network again, I'd be happy to get hold of a windows environment and observe. However, I didn't see any indications that there were more clever things happening - I really do think its a case of muppet-config that just-works in windows, because windows is trusting that the gateway is on the LAN, whereas linux isn't.

So I don't think you *need* to tell that its really a /23: there are only two cases I can think of when adding the default route fails with no such process:
 - the dhcp config is more deeply broken than it looks, in which case a an explicit route to the gateway on the device will not make it worse :P (can't get more broken than broken)
 - the dhcp config is broken only to the point that the default gateway isn't in the subnet, in which case trusting the dhcp config to be accurate - that is that that ip is the right gateway and thus must be on the device's broadcast domain - will work.

Testing a windows setup is probably very sensible, I'm entirely confident it will work though, based on when I did windows sysadminning :P

[Mathieu Trudel-Lapierre (cyphermox)]

Looking at this quickly, it seems as though NM currently assumes that the netmask is 255.255.255.0 if it doesn't receive something saying otherwise from DHCP's 'option subnet-mask'. I'm trying to write a quick patch that I should be able to test locally from here (given that I have access to different network environment, with very different IP addressing schemes).

[Alexander Sack (asac)]

the bug title is a mess ... can we get something more concrete here ;)

[Mathieu Trudel-Lapierre (cyphermox)]

Set the title according to my initial investigation... It is possible that I'm wrong in my belief that DHCP doesn't give out option subnet-mask, then we should change the title back to something else.

I'm still working on trying to establish that it is the case for sure, setting up a "badly configured" DNS server.

[Bryan Quigley (bryanquigley)]

This bug was fixed upstream and likely fixed in current Ubuntu releases.