Hi,

I am creating a embedded linux device. I want to build in a sort of reset to factory default feature but the box lacks any physical buttons on it and there wont be a keyboard or anything plugged into it.

The user can change the IP address of the box so therefore I need a reset function in case they lock themselves out. I was thinking about just creating a script on start up that checks to see if there is a cable plugged straight in between the LAN1 and WAN1, if there is, reset the box.

So I started experimenting, I basically plan to do it like this,

0. (All interfaces are down)
1. Bring up eth0 on 123.123.123.1/24
2. Send out one ping to 123.123.123.123 on eth0
3. If no reply, bring up eth1 on 123.123.123.123/24
4. Send out one ping to 123.123.123.123 on eth0 again
5. If reply, reset box

The reason for the two pings is first to make sure there is no other device already using the dummy address of 123.123.123.1, then a second ping, if there is a reply, then there is a cable plugged straight in between the interfaces, therefore we should reset the box.

I am using the following command to send the ping

ping -c 1 -r -I eth0 -t 1 -q 123.123.123.123

I use -c as I only want to send 1 ping.
I use -I to send it out on eth0
I use -t to only use 1 hop
I use -q to just minimize the output
I use -r (if I understand the manpage correctly) to ignore the routing table and just send it out to a local host on that interface.

However, I only get a "Destination Host Unreachable" reply on my pings. I still get this even if I only use "ping -I eth0 123.123.123.123". Obviously removing -I will make the replies come back, but then they just go to eth1 straight away.

I have flushed iptables before so there is no firewall rules.




Why can I not ping myself from one interface into another?


Thanks!

Regardless of how you send the ICMP packets out, the replies should come over the loopback adapter since both addresses are local. I suspect what is happening is that the ICMP echo request goes out over eth0, comes in on eth1, and the response goes back over lo. The kernel is expecting a response from eth1, not lo, so the reply gets ignored.

By the way, your test shouldn't be using real, routeable IP addresses. You should use a private range, such as 169.254.0.0/16.

If the user can change the IP, why not have one IP be "magic" and if they set the device to that IP, it resets itself? If it's possible for the user to lock themselves out where they cannot change the IP, how will you know if the device is plugged into itself? There are valid cases for the device becoming unplugged on losing link, so you definitely don't want to switch to your magic IP just because it loses link, and being able to ping a device on the same subnet is normal expected behavior, so you can't just set the second interface to something on the same subnet as the first and ping it.

It sounds to me like you need to find a different approach.

I was planning to use a private range, but just used the 123.123.123.123 for testing as it was easier to remember and type :P


Sorry, the reset function will only be used in one of two scenarios,

1. The user changes the devices IP address and forgets it
2. There is a bug in order software which allows the user to set the device to a invalid IP address (like a broadcast address or a incorrect netmask) so that it can not longer be accessed.


Sorry, I think I might have been unclear to what I am trying to do. The reason for having this reset feature is if a user can not connect to the devices for what ever reason. There is no physical button on the unit that I can use to call a reset script with.

I was therefore planning to reset the box if the user connects a cross over cable between LAN1 and WAN1 during boot with no other cables attached. There is no reason why the user would have these ports connected straight to each other in a normal setup.

This script would therefore run at boot, send one ping out first on one interface to make sure nothing else is already using that IP address. If the ping does not respond, then bring up the second interface and send the same ping again. If we now get a reply, then we know it is our other interface responding, therefore the ports are plugged straight into each other. Therefore we should reset the IP address.


Is there a way I can get around this so that it responds back via the interface it came in through?


I would welcome any other suggestions as I agree this is not a ideal solution. The limitations are that there is no physical button on the box and it wont have any inputs connected (keyboard, mice etc).

What about this:
1. Bring up both interfaces during boot
2. Confirm each interface has an active link (check the status of the device, this can be done with ethtool)
3. Deliberately disable eth0
4. Check to see if eth1 has now lost it's link
5. Enable eth0
6. Check to see that eth1 has regained link (this could take a few seconds)

This should work in theory, but I haven't confirmed that doing an ifconfig eth0 down will actually make eth1 lose link (assuming they're plugged into each other). I don't have any physical machines with Linux installed that I can use to confirm.

I think you're much better off using linkstate to confirm, since overriding the loopback routing would probably require kernel changes.

Tried this but unfortunatly bringing down the interface does not loose the link (I assume you mean use mii-tool here?).

Could I do it using arp in some realiable way? Or have you got any other suggestions?

Thanks!

I bet it would lose link if you forced one end to 10baseT/half-duplex and the other to 100baseTX/full-duplex. More complex than simply ifconfig down, but that should actually work.

It does loose link, is this a good way to do it though? What if the customer is using a 10mbit connection which doesnt support 100mbit? Then it will loose link as well and get a false positive on boot when checking for the loop back cable?

Ok I think I got a good solution.

I ended up modifying /etc/acpi/powerbtn.sh which is the shell script called when the power button is pressed in debian. I then modified it to add a 5 sec sleep at the top. It also increments a number saved in /tmp/reset. Then if /tmp/reset == 5 I call my reset to factory default.

So now if the user presses the Power button 5 times within a 5 second period the device will reset itself.


Thanks for your help chort!