Thanks for your report.
On 07/04/20(Tue) 16:04, Laurent Salle wrote:
> On 06/04/2020 14.36, Laurent Salle wrote:
> > If you wish, I may do some more test the next time the problem occurs.
>
> I've done more tests.
>
> This time, I've noticed the following message on the console "arpresolve:
> unresolved and rt_expire == 0"
It's the same bug as reported by sthen@. Two interfaces in the same subnet
have two identical cloning routes:
> 192.168.1/24 192.168.1.4 UCn 1 887 - 4 em0
> 192.168.1/24 192.168.1.18 UCn 1 47 - 8 iwm0
ARP entries are "cloned" from one of these two. It should be only one
at a time, obviously the one with higher priority.
Then I believe dhclient(8) inserts default routes for both interfaces:
> default 192.168.1.254 UGS 5 26091 - 8 em0
> default 192.168.1.254 UGS 0 1671 - 12 iwm0
One of these routes, the one with higher priority, is picked when
sending packets to "8.8.8.8", now the kernel needs to find the ARP entry
corresponding to "192.168.1.254":
> 192.168.1.254 f4:ca:e5:55:0d:2d UHLc 0 1108 - 3 em0
> 192.168.1.254 link#1 UHLch 1 1468 - 7 iwm0
First question is why an entry is cached ('h') when the other isn't? Both
should be.
Second question is why the entry on iwm0 is returned when the query is
done on em0.
Answering those questions should be enough to fix the bug :o)
