Permanently assigning IP address for an embedded device

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.

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.