Old ARP entries can't be deleted

Installing and Using OpenWrt Network and Wireless Configuration
1

My OpenWRT-powered control board (with dnsmasq) doesn't give the nodes in my cluster any fresh IP addresses. While trying to hunt down the cause, I stumbled upon some age-old (and incorrect) ARP entries:

mixtile@ClusterBox:~$ arp
IP address       HW type     Flags       HW address            Mask     Device
10.20.0.11       0x1         0x0         00:00:00:00:00:00     *        pci0
10.20.0.14       0x1         0x0         00:00:00:00:00:00     *        pci0
10.20.0.13       0x1         0x0         00:00:00:00:00:00     *        pci0
10.20.0.12       0x1         0x0         00:00:00:00:00:00     *        pci0
192.168.178.43   0x1         0x2         b4:2e:99:c6:e9:9f     *        eth0.2
192.168.178.1    0x1         0x2         34:81:c4:dd:78:f2     *        eth0.2

The only problem is: I can't delete them! When using ip neigh flush, as suggested by Google's AI, I only get a Nothing to flush message:

mixtile@ClusterBox:~$ sudo ip neigh flush dev pci0
Nothing to flush

So: What can I d to get rid of these wrong ARP entries?

2

Old / stale entries got cleanedup automatically.

Is there any issue?
And for showing entries I recommend using ip neigh show and not arp.

3

What version of OpenWrt are you running?

4

Made me also curious what's happening here...

5

But it doesn't help me very much either:

mixtile@ClusterBox:~$ ip neigh show
10.20.0.11 dev pci0  used 0/0/0 probes 6 FAILED
192.168.178.1 dev eth0.2 lladdr 34:81:c4:dd:78:f2 ref 1 used 0/0/0 probes 1 REACHABLE
10.20.0.12 dev pci0  used 0/0/0 probes 6 FAILED
192.168.178.43 dev eth0.2 lladdr b4:2e:99:c6:e9:9f ref 1 used 0/0/0 probes 1 DELAY
fe80::d0:62ff:fe73:d062 dev eth0.2 lladdr 02:d0:62:73:d0:62 used 0/0/0 probes 0 STALE
fe80::ca8e:d1ff:fe90:94ee dev eth0.2 lladdr c8:8e:d1:90:94:ee used 0/0/0 probes 0 STALE

An adapted edition of 23.05. Comes from the manufacturer of the cluster, who won't switch to a newer version.

6

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

7

The answer you received every time you asked about this hw.

8

That's exactly the problem: The manufacturer won't disclose the amendments he has made to theis particular version, so I don't even know what's wrong here.

9

They're legally obligated to publish the code.

Welcome to the club.

10

I did not said either that it will solve your issue but it's only to get more accurate debug info.
Arp and friends is legacy since 2012!

As frolic said. If you use a vendor firmware then please deal with the vendor.