Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two *nix boxes that are connected via ethernet. However I only have physical access to one of them. In working on the "remote" computer I messed up the ifcfg-eth0 file and instead of typing IPADDR= I typed IPPADDR (note the extra P). So at this point I believe the network boot script is still correctly loading the device drivers but obviously it will fail trying to set the IP address of the device.

So, knowing only the MAC address of the "remote" computer and that the network cable goes directly from my computer to the "remote" computer, is there any way I can connect to this system and correct the ifcfg-eth0 file without gaining physical access?

share|improve this question
Even if a machine has no IPv4 address it may still have an IPv6 address. One can look if there is an IPv6 link-local address which is responding on the link: ping6 -nc2 ff02::1%eth0 – kasperd Jan 9 '15 at 0:49
up vote 4 down vote accepted

Not possible, sorry. Programs, particularly things like SSH, that work over TCP/IP can't be hacked to talk to a MAC address. This would have crazy security side affects if you could! By not having an IP, the interface won't accept traffic.

Your only hope would be that it did some default action on failing to parse the file like run dhcp and assign a default address. If your distro does that, you might be able to find this address by turning on tcpdump and watching the interface that connects you to the other box or even watchings logs for arp data. You could then add an IP to your other machine in the same subnet and talk. However if the machine really doesn't have an IP, you can't talk to it.

share|improve this answer
Yes, I know that TCP/IP based programs won't work otherwise I'd use telnet and not post questions. I was hoping for something that doesn't rely on the TCP/IP stack. – Corin Jun 16 '11 at 20:56
You would have to have something else installed ahead of time. This could be hacked (an arp trigger that reruns the dhcp daemon for example) but it require access to the other side to open up such a security hole ahead of time. There isn't any default way to get commands into a machine without using tcp-ip. Unless of course you have a serial console setup. But if you had that you wouldn't be asking here :) – Caleb Jun 16 '11 at 20:59
tcpdump was a useful suggestion. Confirmed that it definitely does not have an IP address. – Corin Jun 16 '11 at 22:14

Do you have iLO or any other out-of-band management tool setup? You may be able to get command line access. If your OODM tool doesn't support command line access you should be able to at least force a reboot on your remote machine, boot a suitable live cd image off of a network share via a PXE server, connect to your live cd via SSH, mount the local hard drive and then make the appropriate configuration changes.

Other than that, I can't think of a way to recover the machine without physical access.

share|improve this answer

It's possible to remotely login via a dial-up POTS modem (not through PPP or TCP/IP, the modem in this case becomes a big serial line) if you have everything configured correctly. No encryption is provided through this method so it should be used for absolute emergencies only. I realize it doesn't help you now but it is something to think about int the future.

share|improve this answer

You might get lucky if you have a serial connection on the back of the server. Connect a null modem cable to a laptop and console in with your favorite terminal emulator. Depends if you have ever set this up in the past or every had TTY devices connected.

Might work 50/50

share|improve this answer
Connecting a serial connection to the back of a server requires physical access. The point of this question is that the guy broke it without setting up some alternate access ahead of time. There are a million solutions could be implemented with physical access, but short of sending a robot to do the job, this doesn't really help the OP. – Caleb Jun 17 '11 at 17:00

do you have network manager on the "remote one?" It's may work if you lucky: install a dhcp server on the "local one" so maybe the "remote" will ask for ip... if you are lucky enough and the "remote one" runs dhcp client. :)

share|improve this answer
This is a good idea but was already suggested and the guy said it failed to turn up anything useful. For your future reference note that you can tell if there is a DHCP client active by watching a tcpdump or turning up log levels for arp traffic if you are on the other end of the wire. – Caleb Jun 17 '11 at 19:06

Your Answer


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.