since 10.1.0, cannot assign the same IPv4 to 2 interfaces anymore

[perkelix]

As per log below:

Oct 24 20:33:16 u1400 dhcpcd[676]: dhcpcd-10.1.0 starting
Oct 24 20:33:16 u1400 dhcpcd[679]: DUID 00:01:00:01:2c:91:da:a1:00:1c:23:28:c9:4f
Oct 24 20:33:17 u1400 dhcpcd[679]: wlp12s0: waiting for carrier
Oct 24 20:33:17 u1400 dhcpcd[654]: enp9s0: waiting for carrier
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: carrier acquired
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: connected to Access Point: 715517
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: IAID e0:36:99:1b
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: adding address fe80::9f61:80bd:9b17:ccf0
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: soliciting a DHCP lease
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: offered 172.16.1.14 from 172.16.1.1
Oct 24 20:33:19 u1400 dhcpcd[679]: wlp12s0: probing address 172.16.1.14/16
Oct 24 20:33:20 u1400 dhcpcd[654]: enp9s0: carrier acquired
Oct 24 20:33:20 u1400 dhcpcd[654]: enp9s0: IAID 23:28:c9:4f
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: soliciting a DHCP lease
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: offered 172.16.1.14 from 172.16.1.1
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: probing address 172.16.1.14/16
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: 00:1c:23:28:c9:4f(00:1c:23:28:c9:4f) claims 172.16.1.14
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: DAD detected 172.16.1.14
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: soliciting an IPv6 router
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: soliciting an IPv6 router
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: Router Advertisement from fe80::5022:e24d:b9fa:2d57
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: Router Advertisement from fe80::5022:e24d:b9fa:2d57
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: adding address 2001:14ba:a00e:1905:b8c3:d439:7b3b:26f1/64
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: adding route to 2001:14ba:a00e:1905::/64
Oct 24 20:33:21 u1400 dhcpcd[679]: wlp12s0: adding default route via fe80::5022:e24d:b9fa:2d57
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: adding address 2001:14ba:a00e:1905:6883:ff76:955e:d5c9/64
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: adding route to 2001:14ba:a00e:1905::/64
Oct 24 20:33:21 u1400 dhcpcd[654]: enp9s0: adding default route via fe80::5022:e24d:b9fa:2d57
Oct 24 20:33:22 u1400 dhcpcd[679]: wlp12s0: soliciting a DHCP lease
Oct 24 20:33:26 u1400 dhcpcd[654]: enp9s0: leased 172.16.1.14 for infinity
Oct 24 20:33:26 u1400 dhcpcd[654]: enp9s0: adding route to 172.16.0.0/16
Oct 24 20:33:26 u1400 dhcpcd[654]: enp9s0: adding default route via 172.16.1.1

Basically, DAD mistakenly prevents 2 interfaces on the same host from using the same address. This wasn't the case before.

[rsmarples]

This feature has been removed. Maybe what you need is interface bonding (Linux) or link aggregation (BSD)? This gives a more sane picture to the OS of what you really want rather than playing tricks at the L3 level.

Also, only one DHCP server (ISC DHCPd) actually allows this and all others I've used (kea, which supersedes ISC DHCPd), dnsmasq and whatever ships with my Ubiquiti router actively deny this ability.

[perkelix]

What was the point of removing this feature? It provides a seamless failsafe against one of the interfaces dropping. Now, with the feature gone, the other interface wrongfully gets an LL4 address, which means that the failsafe no longer works.

Btw, dnsmasq DOES allow multiple MACs to receive the same IPv4 as long as they appear on the same line for a given host. For compatibility reasons, this cannot go to /etc/ethers, but rather to an optional file defined via dhcp-hostsfile=/etc/dhcp-hostsfile whose format is: MAC[,MAC2][,MAC3],hostname,IPv4 and it's precisely how I have it configured on my LAN.

[rsmarples]

Oh, I didn't know that about dnsmasq.

The point of removing the feature was that kernel level ARP replies (which I can't control) sometimes send out the MAC of the non preferred interface giving a poor experience. With bonding you can say which is the master interface so the kernel always sends out for the correct ARP reply.

[perkelix]

I would really ask you to reinstate the feature. Having to configure bondage just to have a host switch interface on the fly is really not desirable.

[rsmarples]

I'll consider it.

But think about this - you have to configure something somewhere. It's generally better to configure the client than the server.

[perkelix]

Thanks.

The server already is configured to provide the same IPv4 address to any MAC address matching that hostname. This setup has worked fine as-is for many years.

The only thing that is no longer working is at dhcpcd's end.

[perkelix]

I would kindly urge you to revert this ASAP. Losing that feature has seriously disrupted operation on my dual-interface hosts.

[rsmarples]

I need to make some changes in NetBSD to try to accommodate your need for this.

[perkelix]

Noted. Looking forward to it.

[perkelix]

Have we made any progress on this?

A related issue is that once the "unlucky" interface has reverted to the IPv4LL fallback, it seemingly won't try DHCPv4 ever again, even if the "lucky" interface that succesfully acquired an IPv4 gets switched off.

[perkelix]

Could we have this done fof the next release?