What the original poster describes is a 'clever' method used by Axis and other manufacturers of embedded IP products.
What you do is force the IP address of the device into the arp cache of another machine on the same network (using arp -s under Win32, arp pub under *nix). Then, you put the new embedded system on the network and ping it from the machine whose arp cache you stuffed. The embedded system, meanwhile, is listening for any Ethernet frames with its MAC. When it sees them, it peels them apart and looks for the destination IP. It assumes that the destination IP is its own, and configures itself appropriately.
The reasons for this approach are simplicity, hardware reduction, and code size:
1) The user of the device doesn't need a DHCP server, and doesn't need to flip any jumpers or anything.
2) The manufacturer doesn't have to write a DHCP client (which has a bunch of state code that is no fun to code in asm), and doesn't have to add extra hardware to the device just to support configuration (ie: switches, buttons, LCDs or LEDs or whatever).
However, I do not know of an implementation for this trick under Linux. It's within the realm of theoretical possibility, though I don't believe you'll find anyone in the "big" Linux world rushing to implement it when DHCP is fairly easy to do.
You might have some success in the ucLinux world, but it sounds like you want to use this to address workstations. What is your actual goal? What are your constraints, and why? Perhaps we could suggest an alternative if we had more background on the/actual/ problem, not the final technical issue.
Slashdot Mirror
What the original poster describes is a 'clever' method used by Axis and other manufacturers of embedded IP products.
/actual/ problem, not the final technical issue.
What you do is force the IP address of the device into the arp cache of another machine on the same network (using arp -s under Win32, arp pub under *nix). Then, you put the new embedded system on the network and ping it from the machine whose arp cache you stuffed. The embedded system, meanwhile, is listening for any Ethernet frames with its MAC. When it sees them, it peels them apart and looks for the destination IP. It assumes that the destination IP is its own, and configures itself appropriately.
The reasons for this approach are simplicity, hardware reduction, and code size:
1) The user of the device doesn't need a DHCP server, and doesn't need to flip any jumpers or anything.
2) The manufacturer doesn't have to write a DHCP client (which has a bunch of state code that is no fun to code in asm), and doesn't have to add extra hardware to the device just to support configuration (ie: switches, buttons, LCDs or LEDs or whatever).
However, I do not know of an implementation for this trick under Linux. It's within the realm of theoretical possibility, though I don't believe you'll find anyone in the "big" Linux world rushing to implement it when DHCP is fairly easy to do.
You might have some success in the ucLinux world, but it sounds like you want to use this to address workstations. What is your actual goal? What are your constraints, and why? Perhaps we could suggest an alternative if we had more background on the