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.

This is a follow-up to Embedded device configured with bad IP address, can I still connect?

We make embedded devices that run Linux. Users can change the networking configuration of the device (static IP, DHCP client and server). Zeroconf was supposed to be the fallback when a user forgets static IP was assigned, but Zeroconf seems spotty in implementation. Connecting a Windows client frequently results in the client getting a link-local address that cannot communicate with the device.

There is no hardware reset button, sadly. I know what MAC address each device has, but I don't know how to use that information because the device's networking stack rejects data unless I know its IP address.

Would it be bad to statically assign a secondary IP address in the link-local range (169.254.0.0/16) to eth0:0? That way I can write a restore utility that will work when the device is directly connected to a client. (No routers involved, but possibly a switch)

What happens if two of our devices are on the same network with the same link-local IP address? They will have different primary IP addresses.

Some similar products hard code a private IP (i.e. 192.168.1.2) for this particular situation.

share|improve this question
add comment

1 Answer

Hard coding IP addresses (that aren't user modifiable) is generally not a good idea, unless your audience is primarily home users. Using the 169.254./16 (RFC 3927) range is better than a RFC1918, but the typical implementation of RFC3927 is for the device to issue an ARP Probe prior to binding to an IP address. Though statically assigning an address from 169.254/16 is less risky and intrusive than an RFC1918 (APIPA, as MS calls it) address, there's a slight chance that some users leverage that network for workgroup connectivity (esp with MS shops).

If two devices come on the network segment (broadcast domain) with the same link-local address, it causes a collision. Traffic to/from those devices either slows down or breaks completely. The effect such an event has if the devices are connected on separate collision domains may differ. Since connectivity relies on mapping MAC address to IP address, you could run into a situation where traffic destined to the same address ends up at a different node than intended. Alternatively, devices that use static ARP might run into different problems. Again, such problems may be minimal (or nonexistent) if the scope of RFC3927 is small or nonexistent.

share|improve this answer
    
A collision only happens if communication is attempted with the duplicate address, right? Nothing will attempt to use this address except for the ARP queries from link-local address negotiation, which is meant to happen. What's the practical effect of this collision? –  Cat May 23 '12 at 16:33
    
Yep - any communication to/from devices could generate a collision. The effect is broken comm until the conflict is resolved. With that said, following the RFC is a good practice IMHO. –  bangdang May 23 '12 at 20:14
    
Okay, my new approach is to, on boot, obtain an link-local address one time using the implementation at zeroconf.org/AVH-IPv4LL.c. I then do an ifconfig add eth0:0 user_configurable_ip_address to add an alias. This is not so robust if I move my device to another network while powered, but it's powered by its Ethernet cable, so it should almost always follow the link-local address acquisition rules. (reboots upon disconnect) –  Cat May 24 '12 at 21:56
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.