Recently, someone came to me with the problem that some remote IOT-devices received a broken configuration where the first octet of their IP-address was changed to 0 (i.e. from to Because of the location of these devices it was very impractical to go and change the configuration on the device itself, so I was asked if I could figure out a way to fix the configuration by remote.

The devices have a configuration command to set the IP-address, so changing the address by remote was not the problem. However, how are we going to talk to these devices? I only had access to a Windows machine in the same subnet as the devices.

I set up a little test lab with a misconfigured device to see how I could tackle this. I sniffed the network communication with Wireshark to see if the devices were still communicating, and luckely, they were. So the TCP/IP-stack in the device adopted its 0.x.x.x address and was using it instead of stopping the network all together, this was good news.

Trying the Windows route

First attempt was to try and talk to the devices from Windows. A ping from outside the 0.x.x.x subnet was already giving discouraging results; Windows’s TCP/IP-stack would not accept the address:


Pinging with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Trying to configure an IP-address on the machine in the 0.x.x.x subnet confirmed that this was not going to work in Windows: 0 is not a valid entry.

Linux then?

Linux does allow me to configure an IP-address in the 0.x.x.x range, so that was encouraging at first:

~# ifconfig eth0 inet netmask
~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        ether 08:00:27:d4:35:1d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0x80400000-80420000

But again; no traffic possible to the network:

~# ping
connect: Invalid argument
~# telnet
telnet: Unable to connect to remote host: Invalid argument

FreeBSD to the rescue!

At this point I was considering hooking up a custom IOT-device to the network through tunneling in order to just send the correct configuration packets, but of course there are OSes other than Windows and Linux, so I gave FreeBSD a try. Surprisingly, FreeBSD allowed me to configure an IP-address in 0.x.x.x and also connect to the ‘lost’ device!

# ifconfig em0 inet netmask
# ifconfig em0
        inet netmask 0xff000000 broadcast
        ether 08:00:27:d4:35:1d
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
# ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=1.137 ms
64 bytes from icmp_seq=1 ttl=255 time=1.122 ms
--- ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.122/1.129/1.137/0.013 ms
# telnet
Connected to
Escape character is '^]'.

In the end, booting a FreeBSD Live CD on VirtualBox on the remote Windows system and netcatting a few configuration commands to the affected devices fixed the IP-configuration on the devices without a time consuming (and costly) trip to physically access the devices.

What’s so special about

RFC6890 designates the block as a reserved block with a description of ‘this host on this network’. It is only valid as a source address, not as a destination. Section of RFC1122 further specifies that this address must not be used to send from and that it is intended for use as a broadcast address.

It appears Linux and Windows are following these standards more strictly than FreeBSD does. I could not find any further info on the reason for this difference in networking stack implementation. In this case, I was happy I found this difference and was able to restore the lost devices to their correct IP-addresses.