On the fly IP Address change

This wiki page describes a function common to all Barix IP devices, and a potential issue with routers "breaking the rules":

A Barix IP device has a built-in way of reconfiguring the IP address temporarily. This functionality is documented well and very useful. Under normal circumstances, this is considered "safe" as, to use the function, it is necesssary to know the MAC address of the device AND to be on the local network.

The functionality is called the "ARP Trick", and it allows the setup of a Barix device which has an unknown, probably "wrong" configuration on the network. So, how does it work ?

To switch the IP address to a known one temporarily, two steps are required. First, on a local PC, you need to set up a static ARP entry (the ARP protocol is normally used to associate the IP Address of the device with the MAC address actually used to address the unit on the Ethernet). In setting up such a static ARP entry, you give the workstation/PC you use the information on how to send IP blocks to the device. In normal circumstances, that information is detected by the ARP protocol, but if a device has an unknown configuration/non-local IP address, it of course will not answer to the search request sent out by the ARP protocol handler - which is the normal case. Again, to generate such an ARP entry, you need to provide both the IP address you want to assign as well as the MAC address to the arp protocol handler of your PC/workstation. That is typically done with the command (example, of course, IP address and MAC must be replaced with your real values)

arp -s 192.168.1.12 00-08-E1-12-34-56

You can then verify that a static entry has been created in the ARP table with the "arp -s" command. On mac/linux systems, you need to use a colon ":" instead of the dash "-" in the MAC address.

Once this entry is established, the PC/workstation now knows how to send traffic to that IP address, and if you now ping the IP or use the browser, the IP frames will be sent to the MAC address given ... however, Barix devices will still ignore these blocks because they are NOT carrying the right IP address.

Now comes the trick: if you send a TCP connection establishment request to port 1, however, the device understands this as a very special command and "switches" the IP Address to the destination IP of the block, and resets the netmask to the default netmask for that IP address.

So, after you have done a TCP connect try using port number 1 (can be done with a browser by specifying port 1 as part of the URL, or by telnet, or any other application using TCP with a configurable port number), the device will be switched to that IP address and of course "lose" the old IP address, until it is rebooted.

The described method is considered "safe" for the following reasons:

a) it only works on a local network, and only if you know the MAC address of the device b) if you know an IP and MAC of a device and have access to the low level protocol functionality on a workstation, you can disturb communications for that device by many means - creating fake ARP entries is just one method. c) because the ARP layer on devices like routers and gateways is generally not available, there seems to be no way how to do this "remote"

... well, you think so.

It has been reported now in one case (Alan) that a router (exact make and version should be added here) behaves wrongly and causes problems. What happens ?

On the internet, there are many culprits running port scanner software to find PCs to infect. These port scanners typically "scan" all IP addresses by trying to establish a TCP connection to every possible port (of course, scanning 2^32 IP addresses with 64k ports each takes quite a while, but the tools are smart and only look in certain IP address ranges).

So, what happens if a port scanner hits port 1 ? And it is forwarded by the router (which should NOT be the case, you should generally filter all ports other than the ones needed !!)

If the port scanner hits the IP of the Barix device and the port 1 TCP connection request is forwarded, it will be refused, BUT the Barix device will reset its netmask. So far so good, that will not have a disturbing effect in most cases as traffic over the internet generally uses non-local addresses, so the gateway will still be used. HOWEVER: what seems to happen in the customer case is much worse. The port scanner increments IP addresses and also tries the "broadcast" address of the network. A TCP connection request to the broadcast address makes absolutely NO sense, and the router must NOT forward it. BUT .. apparently, it does so - even using the Ethernet broadcast address ! Clear violation of about any rule. Our devices receive the TCP connection request to port one because they are sent using the broadcast address .. and they assume that address temporarily. Now the device is not any more reachable on the configured address, but on another address. A magic "IP address change" happened.

How can this be prevented:

well, quite simple:

a) update the router with fixed firmware (if it exists) or use a router which does comply with the standards and does NOT forward/send out TCP requests to the broadcast address via broadcast on the network b) configure the router to block traffic at least to port 1, better to all ports and selectively only open the ports needed. c) you can also ask your ISP why they forward traffic to the local broadcast address from the Internet, that is questionable as well .. if they give you a subnet/IP address range, they should know what your local "network" and "broadcast" addresses are and not send traffic to them.

We at Barix will modify the functionality of our stack, trying to prevent such issues. First measure is to check for this specific case if the block is arriving by broadcast hardware address and ignoring it in that case. Second measure will be likely to time-limit the functionality to 60 seconds after reboot/restart - so it will be only possible to reset the IP address using the ARP trick within the first minute after erset/power up of the device. But we need to discuss this and all the implications first before we an go ahead and implement it.

20.12.09 JR

Back to Troubleshooting