Subnet masking issues

Bernd_Wechner · October 2, 2017, 8:53pm

I’m trying to understand subnet masking but have atwo conflicting pieces of evidence to grapple with. Here’s what I am experimenting with:

My LAN runs on the 192.168.0 subnet with a subnet mask of 255.255.255.0, as follows in /etc/config/network::

config interface 'lan'
	option ifname 'eth0 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ip6assign '60'
	option ipaddr '192.168.0.1'
	option netmask '255.255.255.0'
	option gateway '192.168.0.1'
	option broadcast '192.168.0.255'

All is good. And I am happy. Loads of devices with IPs reserved on my LAN, printers, scanners, servers, other things … all no dramas and great little home LAN and has been for years …

Every now and then I get a peripheral (typically a wifi camera but it matters not) that comes factory set with an IP on the 192.168.1 subnet.

Historically the only way I have of integrating that is to get a laptop, connect it directly to the peripheral with a CAT cable and set the IP of th laptop to 192.168.1.1 and then I can connect to the peripherals web interface and configure it to use DHCP and from there plug it into my LAN.

That works fine,m but is a hassle. And so I wanted to learn a bit more about how I might do it all on my LAN directly.

So I read a little about subnets and turns out I can basically relax the netmask as follows:

config interface 'lan'
	option ifname 'eth0 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ip6assign '60'
	option ipaddr '192.168.0.1'
	option netmask '255.255.0.0'
	option gateway '192.168.0.1'
	option broadcast '192.168.1.255'

And suddenly I can plug the peripheral into my LAN and see it on my LAN. Awesome. Essentially I’ve moved from a type C to type B subnetwork I guess with a much larger range of IP’s available on the subnet.

Now the simplest test I have for visibility is just the arp command. I type arp, and if I see the peripheral (the specific one I have is factory set to 192.168.1.88) and with a mask of 255.255.255.0 in /etc/config/network as above I cannot see the peripheral, but with 255.255.0.0 I can!

Between tests I reboot the router so that it rebuilds the arp table and also propagates the netmask to my desktop (and other devices I guess) properly. That’s a mild time consuming hassle between tests, which relevant for the next step.

Essentially, I am keen to learn, more that I am keen to solve this problem. I want to understand how this works. So, thinking I have understood it, I used a subnet calculator:

http://www.subnet-calculator.com/subnet.php

to explore my options. Essentially, can I set it up so my subnet supports not:

192.168.0.0 to 192.168.0.255
192.168.0.0 to 192.168.255.255

(being the type C and type B configs and netmasks as above of 255.255.255.0 and 255.255.0.0 respectively)

But instead supports:

192.168.0.0 to 192.168.1.255

(i.e. just the 0 and 1 subnets).

The mask to do this, is no surprise, rather than zeroing the 8 least significant bits in the mask, zero 9 and the subnet calculator confims that a mask of 255.255.254.0 supports a range of:

192.168.0.0 to 192.168.1.255

(well actually to 192.168.1.255 as the last one is always reserved fro broadcast).

So I configure the Omnia with:

config interface 'lan'
	option ifname 'eth0 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ip6assign '60'
	option ipaddr '192.168.0.1'
	option netmask '255.255.254.0'
	option gateway '192.168.0.1'
	option broadcast '192.168.1.255'

and reboot … and check with arp and BZZZZZT, fail. I cannot see the peripheral.

Why not?

My problem is cognitive dissonance, namely two pieces of conflicting evidence:

a reading of the theory and use of a subnet calculator to confirm understanding (see: http://i772.photobucket.com/albums/yy2/Bernd_Wechner/Subnet%20Mask_zpsiou3zyhk.jpg)
empirical observation of what the Omnia does.

They conflict. So I presume the weakness is in 1), but what am I missing? Is there some nuance to subnet masking that I am overlooking here?

Just a reminder, I’m not looking for novel solutions to seeing this and other 192.169.1 peripherals as I have working solutions. I am interested in understanding what is happening with my subnet masking efforts, i.e in learning.

jklaas · October 3, 2017, 4:08pm

You need to either delete the “option broadcast” and let the network scripts set your broadcast address automatically or set it correctly.

Broadcast is always the last IP in the subnet.

For this subnet:
option ipaddr '192.168.0.1’
option netmask ‘255.255.0.0’

the correct broadcast is 192.168.255.255.

The second example look correct, but I recommend letting the network scripts figure out the broadcast for you. I also allow it to assume the gateway for me as well, which is normally the first IP in the subnet.

If you’re statically setting the laptop, you need to make sure that the subnet settings are also the same. If the network is set to a 23-bit subnet (netmask 255.255.254.0), then that must be set by hand on the laptop for static addresses. Most set ups assume a 24-bit subnet for static entries.

If the setup in the config files on the router are correct, the dnsmasq dhcp server will send the correct data to dhcp clients.

kixorz · October 3, 2017, 8:28pm

I’d remove the broadcast address and use:

option ipaddr '192.168.0.1' option netmask '255.255.254.0'

This gives you a network of 512 - 2 = 510 IP addresses. See ip calculator.

Bernd_Wechner · October 4, 2017, 5:29am

Thanks guys. Appreciate the ideas. Alas have tried it as suggested, only adding explicit Gateway and Broadcasts in experiments to try and mane 255.255.254.0 work.

255.255.0.0 of course works regardless. It’s the fact that netmask of 255.255.254.0 does not see my 192.168.1.88 device on the arp table of the router whereas a netmask of 255.255.0.0 does.

As noted minor time consuming hassle to do tests as with each new setting I unplug the device (192.168.1.88), reboot the router, then restart networking on my desktop PC to be doubly sure. I then check on the desktop PC with ifconfig that the netmask is reflected as I configured it on the Omnia (which it is - conclusion I draw is that when the DHCP server issues an IP address it also issues a netmask), then I plug the device back in again, and finally I check the arp table on the Desktop PC and on the Omnia to see if 192.168.1.88 is listed.

Observations are that with netmask of 255.255.0.0 it is listed and with netmask of 255.255.254.0 it is not.

But that said, because of all that fiddling, I will try it again, cleanly, keeping good notes, and with minimal specs as suggested (already did it before posting but because of all that fiddly power cycling to ensure arp tables reconstructed nd IPs reissued etc) there is scope for human error in the test cycles and a repeat with good notes is worth my while I guess. Because netmask of 255.255.245.0 should work dangit!

Bernd_Wechner · October 5, 2017, 7:04am

Egads. I could kick myself. Solved.

I have a managed switch between the camera and the router that is DHCP managed. As noted in previous post so many fiddly steps easy to inject human error. And that’s what I did. A simple reset of that switch so it reinitiates the DHCP request and gets the netmask and now 255.255.254.0 works! As documented, and as expected. So I have a nice subnet now that includes network prefixes 192.168.0 and 192.168.1.

That simple. Turns out it still had 255.255.255.0 set which will relate to the order in which I did tests and the point at which I forgot to do a switch reset! Piffle.

My bad but hey, now documented well in the forums should anyone else ever want to do something like this and find a struggle.

The key thing to observe is that the DHCP requests deliver an IP address and netmask as configured on the DHCP server (Omnia) and that the netmask defines a network prefix (by its leftmost 1s, and often in CIDR format described by a bitcount so I have a 192.168.0.0/23 subnet now). These two are used as routing deciders by every device on the LAN basically, each device checks for any packet it wants to send whether the destination IP has the LAN’s network prefix and if so transmits it on the LAN - ethernet- based on its current ARP knowledge, probably defaulting to the gateway.

Not entirely clear to me why a switch configured with /24 (as I had) doesn’t:

a) Get or issue an ARP request at some point (either issuing it itself when it detects the camera connected, or receiving it from my desktop when I try to ping it) and hence associate the camera’s MAC with a given port.

b) Then receive requests for 192.168.1.88 and notice it is NOT on the /24 subnet it is on which is 192.168.0 and hence route it to the gateway (192.168.0.1) which it has a MAC address for already.

c) The gateway (Omnia) then receives the request, but thinks it is on the LAN (as it matches its /23 network prefix) can’t find it in the ARP table so issues an ARP request.

d) Switch gets the ARP request, and knows know the MAC address of the camera and the port its on so can either forward the request to the camera or just answer on its behalf.

I suspect step d) breaks down, and perhaps the switch is a bit daft or by design, chooses to ignore the ARP request from the router, or just bounce it straight back as the default route (to the gateway).

A fair bit of guesswork involved with networking I guess ;-).