1

I have a device that I'm trying to connect to. It seems to have Auto IP working, so that when I plug my machine into it I get assigned the address 169.254.163.41. I need to know the IP address of the device so that I can send config files to it.

Is there any way to find it? Or is there a way to deduce it? So far I've checked the output of arp -a and there is nothing in there other than the broadcast address 169.254.255.255.

I've also tried to ping each address in the range 169.254.163.0-255, but I keep getting destination unreachable errors.

Edit:

Thanks for the help guys. It looks like the power supply on the device has failed. It's a prototype setup so there is no manual as such.

The power issue makes sense now as it seems my IP knowledge was flawed and the 169.254.* address was assigned by the PC itself because it received no DHCP offers.

0

6 Answers 6

4

You're going on the wrong assumption.
Your Windows computer will give ITSELF an auto-IP address if it can't get an IP address from an DHCP server.
This says NOTHING about the other device to which you want to connect.
You must first figure out that other devices behaviour if it can't get an DHCP address.
Some devices will also dynamically generate a 169.254.. address. In that case doing a ping 169.254.255.255 from the PC and then inspect the arp-table with arp -a should give you the ip-address the other device is using.

If the other device defaults to a static ip-address you will have to consult it's manual to figure out how to determine that ip-address.

In some case a device doesn't have any ip-address at all, but you can assign one with a special tool from the manufacturer or through other means (usually a static arp entry). Again: Consult the manual.

2

First, note that Auto IP is configured independently by each device. Just because your computer auto-configures a link-local address for itself, does not mean the other device does. You would see identical behavior if the other device was using DHCP, or if it had a static address configured.

You should use Wireshark/tcpdump to see what the other device actually sends – look for DHCP requests, ARP probes, anything that isn't sent from your own computer.

Also note that Auto IP is always 169.254.0.0/16 (minus some reservations), not a /24, so the range would be from 169.254.1.0 to 169.254.254.255, not just the one you tried.

(The entire range is actually 169.254.0.1 to 169.254.255.254 – but as specified, "The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism." They can still be configured manually though.)


As for address assignment: It depends on the device, but officially, IPv4 link-local (aka APIPA) addresses are chosen pseudo-randomly, although potentially seeded with the MAC addresses (so the address stays the same every time).

Some devices (e.g. Ubiquiti) first start with directly using the last two bytes of their MAC address, e.g. …:ab:cd169.254.171.205, but that's rare and nonstandard.

As Frank mentioned, some devices respond to broadcast pings to 169.254.255.255 and/or 169.254.0.0. This is also not very common.

Generally, link-local address assignment always involves probing the network for any other hosts with the same address – you can see the ARP requests using Wireshark or tcpdump.

0
1
  • Power off the device.
  • Connect your PC directly. The network interface should be up, but the ip, etc. doesn't matter.
  • Turn off anything generating network noise.
  • Run tcpdump or something else that dumps all traffic.
  • When you're set up and ready to go, power on the device. If it does anything via IP on startup or otherwise, you should see it. Tcpdump is raw, so you see things that aren't on your network subnet. Probably ignore things that come from your own IP (noise you failed to stop).

If that fails, check the manual and probably factory reset it.

0

Do you have DHCP server in your network? 169.254.x.x address implies that that the device is configured to use DHCP but has not received address from server.

If you have DHCP server make sure it is configured to give IP address to your device. (For example DHCP server might only give IPs to known macaddresses.) Then the device should get real IP address that can be used for connecting.

0

You can check this program out, it's a little software that discover your devices in your network.

by the way if you want the hostname of a device in your network you can ping it with the -a parameter:

ping -a x.x.x.x

Hope it helps you :)

-1

Default ip of 169.254.. is something your OS assigns your nic, some nonsense MS made up. You find its ip in the arp table if the device has shown any sign of life in the IP layer. You can also provoke such by ping ip ..255 from a static ip and full blown netmask if the device is broadcast aware. You can also bring your nic in promiscuous mode and looking for arp packets. Last resort will be to reset to factory settings.

3
  • 2
    "some nonsense MS made up" is complete crap. It is a link-local address defined by RFC 3927, only used to assign IP addresses to network interfaces when no external, stateful mechanism of address configuration exists, such as the Dynamic Host Configuration Protocol (DHCP), or when another primary configuration method has failed. Please don't spread incorrect information in your answers.
    – DavidPostill
    May 23, 2016 at 12:52
  • Well, to be fair, RFC 3927 was co-authored by Microsoft (along with Apple and Sun). May 23, 2016 at 13:18
  • @DavidPostill According to Wikipedia: Microsoft created an implementation called Automatic Private IP Addressing (APIPA), which was deployed on millions of machines and became a de facto standard. Many years later, in May 2005, the IETF defined a formal standard in RFC 3927, entitled Dynamic Configuration of IPv4 Link-Local Addresses. Please don't spread incorrect information in your comments.
    – Gogeta70
    Dec 4, 2019 at 22:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .