Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have an embedded device running Linux (2.6.?) that can no longer be accessed over Ethernet. Someone in the field gave this device the following bad settings to its ethernet interface:

IP: 172.16.1.236 
Subnet mask: 255.5.0.0

(I don't know what the result of using these settings is, other than the device cannot be talked to. I'd think those settings would be rejected and some alternate private IP assigned to the interface.)

Our man in the field can no longer communicate with the device, so I'm looking for any way around this.

I believe the device also runs Zeroconf, but I have no experience with the protocol.

Edit: Eventually an ARP was sent from 172.16.1.236 on our test setup that mimicked the device in the field. The actual IP on the Ethernet interface was another private one, in the 169.x.x.x range. I don't understand how I was able to connect to the 172.x.x.x IP.

share|improve this question
add comment

2 Answers

up vote 13 down vote accepted

My usual solution for problems like that is to:

  1. Get a device onto the same subnet as the device
  2. Configure the device with compatible network settings
  3. Connect to the embedded device
  4. Change the bad network settings on the embedded device

Step 1 is usually the hard part. It can be a laptop that you just drag to the right location, or a device with two connected network ports; one for you to connect to, one for the bad network data.

If the device has an unknown networking config, it gets hairier and results aren't as good. However, I've done it. You need physical access to the device and its networking connections. What I've done:

  1. Connect your laptop and the device to a switch connected to nothing else.
  2. Configure your laptop with no IP address, just leave it with the raw Ethernet addresses.
  3. Start a promiscuous mode network trace from that laptop.
  4. Power-cycle the device.
  5. Watch packets.

If you're lucky, the device will squawk some packets. Probably ARPing for the gateway device's MAC addresses. This should reveal the IP it considers itself to have. If it is squawking for a gateway, that should provide some clues as to what it considers its netmask to be though not always. Once you have the IP, configure your laptop to be one-adjacent to it IP-wise and attempt to ping it. Keep the network trace running.

If the network trace shows that when your machine attempts to ARP the target's IP address and the device does not respond, you may need to set a static ARP-table entry for that IP. I have run into devices where this step was needed to kick the device into working. If pinging does not work even after setting the arp-entry, chances are very high that it's fundamentally unreachable from the network.

share|improve this answer
    
That subnet mask is not valid (non-contiguous), so networking is very likely to not be working at all on the device. –  Massimo Jul 18 '11 at 18:52
    
This is my main problem. I do not know what address and mask the embedded device's interface is actually using, if any. What steps can I take to diagnose this, and can I use Zeroconf to help? –  Cat Jul 18 '11 at 19:11
    
The interface could very well be down... it has invalid settings, after all. –  Massimo Jul 18 '11 at 19:14
    
If none of that works, the device itself may have a physical hard-reset button that can be pushed by someone in the field - probably best to find the manual for the device and have a good read of it. A reset will normally set IP/mask back to 192.168.0.1/255.255.255.0. It may be possible to recover from there if the current settings are borked. –  jozzas Jul 19 '11 at 2:21
    
We build these devices. :) –  Cat Jul 19 '11 at 17:44
show 1 more comment

If you configure a computer with the IP: 172.16.1.235/8 you'll have the best chance of making it work immediately. If both devices think they're on the same subnet they'll just communicate.

Does it support IPv6? Use IPv6 to connect to the device. You can probably find the MAC and work out the link-local address.

If neither works, likely the interface is down. sysadmin1138's advice is excellent, do exactly that.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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