In D29190#653711, @kp wrote:

In D29190#653630, @melifaro wrote:

Can counter ptr really be NULL is these cases? If yes, I'd rather retain the existing checks as they indicate that this a valid possibility.

It can happen, but really only if we fail to allocate memory (see line 520-521).

Also, counter(9) man page says nothing about the free(NULL) use case.

Until D29189 it couldn't handle that. This commit builds on top of that.

Yep :-) What I'm saying is that the man page should also be updated to reflect the code changes.

Can counter ptr really be NULL is these cases? If yes, I'd rather retain the existing checks as they indicate that this a valid possibility.

Implement a cleaner fix.

+1 for removing and not MFCin.

In D28812#645023, @kp wrote:

We could potentially use pft_ping.py to actually verify that the stack sets the correct MAC address on packets (and thus also check that the insertion really succeeded), but this'll catch a number of potential issues already.

IMHO there are multiple things worth testing:
(1) rtsock API - that's what we have in tests/sys/net/routing/test_rtsock_lladdr
(2) that actual arp ndp binaries work (as they have logic other than just sending a proper message - that's what these tests are targeting
(3) datapath actually uses these entries - partially covered in IPv4/IPv6 multipath tests, but we certainly need an explicit tests for these as well

In D28804#644956, @donner wrote:

Is this a problem of the kernel or the laziness of the arp code?

I'd say it's the problem of both due to the undefined contract.

Fix compilation.

Address comments.

Address comments.

Reflect comments.