20

I have an piece of industrial equipment that runs on a pretty basic OS called VxWorks. I usually communicate with the system for troubleshooting purposes by setting my IPv4 IP to the same range as the local IP and then running diagnostic software.

A few weeks ago I found that for some odd reason the local IP addreess of the system set itself to 0.0.0.0. Now I want to get into diagnostics to change it but my PC will not permit setting an IP beginning in 0.

Is there any other way to communicate with a device that has a local IP of 0.0.0.0 using a windows PC.

There is no way to reset the device to factory default settings without shipping it back to the manufacturer.

8
  • 14
    As others state 0.0.0.0 is not a routable address. Many pieces of software bind to 0.0.0.0 to allow that software to bind to whatever IP address is assigned to the network interface. This makes it easier—for example—to place the device on an DHCP setting and you just connect by getting the devices IP address and that’s that. My big question to you is why you are setting your machine’s IPv4 IP to the same range as the local IP to then running diagnostic software? Makes no sense. You should just get the device’s IP address and connect to that. That said, I have an idea. Posting an answer. – Giacomo1968 Oct 22 '18 at 14:43
  • VX Works might not run DHCP and might therefore need a static IP address, something you would have to do internally on VX Works. In addition to that, any software or interfaces on your PC that talk to that VX Works machine would have to know that IP address. You would have to verify that all machines that need to talk to your VX Works machine know its IP address. It might auto-fill, or you might have to enter it manually. The all-0s address works as a default gateway, however, if your VX Works machine and your host it wants to talk to both have that gateway in common. – Shankensteinium Oct 22 '18 at 14:48
  • 7
    How were you able to determine that the device is using an IP address of 0.0.0.0? Did you use a piece of software that was able to communicate with the device over the network, or is there a basic Human-Machine Interface (HMI) on the device to show you the IP address? Also, to get the obvious question out of the way, have you tried turning it off and then on again to see if it picks up a sane address? – Sam Skuce Oct 22 '18 at 16:32
  • 5
    Literally assigning itself address 0.0.0.0 is not possible if it has a standards compliant IP stack. This leaves a couple of options: 1. It shows 0.0.0.0 as a way to signal that it failed to assign an IP address. 2. It has a broken IP stack which somehow managed to assign itself 0.0.0.0. I don't know enough about VxWorks to say which of the two is most likely. If it really has assigned address 0.0.0.0 you'd need a hacked up IP stack to communicate with it. But that will not do much good if it hasn't assigned an address at all. – kasperd Oct 22 '18 at 17:34
  • 4
    How did you determine it has a 0.0.0.0 IP address? If you're at a terminal, you can use that to set the IP. – CramerTV Oct 22 '18 at 18:31
23

0.0.0.0 is not a valid IP address. RFC1700 (a) states that 0.0.0.0/8 (0.anything.anything.anything) is reserved as a source address only.

Normally you'll see systems and applications bind ports to 0.0.0.0 which means the port is accessible from any interface.

I'm not familiar with VxWrks but I would assume that there is a way to specify a local IP for interfacing with other computer devices.

WindRiver has a variety of manuals on how to configure the IP setup.

3
  • If 0.0.0.0 is only valid as a source, then how are ports bound to 0.0.0.0 accessible at all? I'm sure I'm missing a detail but this sounds like a contradiction. – Captain Man Oct 22 '18 at 17:33
  • 20
    @CaptainMan: You're confusing an aspect of the sockets API with an aspect of the IP protocol. Binding 0.0.0.0 is an API-level thing to accept packets/connections addressed to any locally configured address. It does not involve packets addressed to 0.0.0.0 travelling anywhere at the protocol level. – R.. GitHub STOP HELPING ICE Oct 22 '18 at 17:43
  • 1
    @CaptainMan: 0.0.0.0 is treated as an empty string. If you set up your server to accept connections from 0.0.0.0 then it will accept connections from any IP address - that's what 0.0.0.0 means. If you don't bind to 0.0.0.0 then your server will ONLY accept connections from a single IP address and will refuse connections from any other machines on the network. Think of non-0.0.0.0 binding as a sort of built-in firewall – slebetman Oct 24 '18 at 2:02
13

You can trick your PC into thinking that device has a real IP address. But you need the physical address (also known as the MAC address), the thingy with 6 two-hexa-digits fields. You do that by adding it to your arp resolution table. In Windows, open a cmd terminal and use arp.

arp -s <IP address> <physical address>

Of course, you need an IP address unique and in your network. Otherwise, the stack is going to reroute somewhere else. If you get to this point, you should be able to access the device. The network infrastructure will route according to the physical address.

In Linux is pretty much the same. Open a terminal, use arp.

It may not work!! Some devices answer only to their own IP. But I'm guessing it's not your case.

6
  • 1
    I am interested to know if this works. Definitely a cool trick. – trognanders Oct 23 '18 at 2:27
  • @BaileyS oh it works all right in normal circumstances. You just insert a manual override for address resolution into an automatic table. Whether it will help op is a different question – Gnudiff Oct 23 '18 at 5:35
  • 2
    If you can now SEND stuff to this address, that doesn't always mean you can correctly handle the RESPONSE if there is one... – rackandboneman Oct 23 '18 at 12:58
  • 1
    Most of iptables is above the lowest-level routing machinery, so might have limited access to that kind of works... – rackandboneman Oct 24 '18 at 0:50
  • 1
    @BaileyS It does and it doesn't. A device with a normal IP stack shouldn't. The route table is going to ignore packets addresses to IP numbers other than their own or that it doesn't know how to route. In this case, the OP is asking about a small industrial device. Most likely, it doesn't have an IP stack implemented. It just answer any packet that reaches it. I know it because I've seen and used many like that. To save costs, they don't have a panel or interface for configuration. Sending them a packet with a "suggested" IP matching the MAC address is enough. – Gabe Mizuka Oct 24 '18 at 22:18
12

The 0.0.0.0 IP address is fine but I would guess that something else has changed on the network that device is on to block zero-configuration networking traffic from allowing your diagnostic software to easily connect to that device.

As others, state in their answer 0.0.0.0 is a non-routable IP address that is often used by software to bind on any IP address on all networking interfaces on a device. This basically means:

“Hey I am a piece of software and will accept any connection made to any assigned IP address on the machine I am running on.”

So if the device uses DHCP—to get its own IP address for its connected interfaces—and gets an assigned address of 1.2.3.4 then you can connect to that device at 1.2.3.4. And if that address changes to 5.6.7.8 the device will happily allow you to connect to it via 5.6.7.8.

The 0.0.0.0 seems to be something you discovered but is not the cause of the problem. Rather, I’m my opinion, the issue you have is revealed when you state:

“I usually communicate with the system for troubleshooting purposes by setting my IPv4 IP to the same range as the local IP and then running diagnostic software.”

First, that seems odd. Why would you need to change your machine’s local IP address to connect to the VxWorks device? Shouldn’t you just connect directly to the IP address of the device?

Well, when you state this all I can think of is that the device—and the diagnostic software—might operate using some sort of zero-configuration networking setup. Meaning, the device broadcasts on the network, and the diagnostic software is designed to seek out these device broadcasts to help it connect to device without knowing the exact IP address.

This kind of “self-configuring” zero-configuration networking stuff is a convenience until it becomes a headache.

My first guess is that you can connect to the device directly if you can determine what IP address it has assigned to it. And thinking even more, I bet that the reason you could connect to it in the past—but not now—might have to do with some networking change that has blocked the ports that device’s zero-configuration networking setup is broadcasting on. What port that may be? Unsure. But if zero-configuration traffic is not being routed through the network, then that is why you can’t connect to the device and the 0.0.0.0 IP address has nothing to do with it.

0
6

0.0.0.0 is an unroutable address. There is no way you can route to it because "it doesn't really exist", or actually, "can exist in too many places".

It can have slightly different meanings depending if it's a host or a route.

As a route, which is not applicable in this case, it means "default route" which with no further instruction means either the default gateway, or "any of my routes", or similar to 127.0.0.1

As a host, then most notably in your case, it is either; as explained on Wikipedia:

The address a host claims as its own when it has not yet been assigned an address. Such as when sending the initial DHCPDISCOVER packet when using DHCP.

The address a host assigns to itself when address request via DHCP has failed, provided the host's IP stack supports this.

Assuming it usually uses DHCP, a couple of things to try, rather than a full reset - 'switch it off & on again' or just unplug the network, wait a minute, plug it back in. It might just ask for a new DHCP address.

Also, of course, make sure it can actually see its DHCP server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.