I have done what I think of I could do and I have read older topics about similar or near similar issue.
What I have done:
Deleted the entry from the Network Overview table using the trashcan.
Done Flush Network Table under the System tab.
Done pihole arpflush
Done sudo arp -d 192.168.2.2 which is answered with No ARP entry for 192.168.2.2.
Before I did the above command I did ip neigh which did not show the ghost entry, and I also tried sudo ip neigh flush nud stale and sudo ip -s -s neigh flush all just to be sure.
I also did the pihole -r just to see...
So it looks like Pi-hole don't get the ghost entry from arp / neigh tables, I presume there could be a DB where the entry could be stored / come from, but I am not sure where to look.
Pi-hole is used as DNS and DHCP server, where I have a list of static entries, 192.168.2.2 was used a while back (it is a unify AP), which I started to use yesterday. However with a different static IP address (192.168.2.5). In the table Currently active DHCP leases the entry is not showing.
I am running a fix version of FTL but think this is not related.
Core vDev (development-v6, dd2c1c69)
FTL vDev (fix/dhcp_names, 61b44031)
Web interface vDev (development-v6, 2d45f6d3)
Not sure if of any help, however here the debug log https://tricorder.pi-hole.net/aVu6kP2z/.
Please try stopping the pihole-FTL process before flushing the network table and restart it afterwards. FTL may be caching old ARP entries itself. If you can confirm this is the case and stopping FTL temporarily does fix the issue, we can work on a fix for this in a second step.
Hi @DL6ER
Step 1:
On Network Overview Table I deleted the 192.168.2.2 entry.
Step 2:
Issued the command sudo systemctl stop pihole-FTL
Step 3:
Issued pihole arpflush
Step 4:
Issued sudo systemctl start pihole-FTL
Same as before the above the IP Adr still stick.
I also had logged in to the AP before stopping pihole-FTL where I did sudo ip -s -s neigh flush all after I had done ip neigh. To be sure I did same on the other AP.
Did again ip neigh on the raspberry Pi where Pi-hole runs, there is no entry for 192.168.2.2.
Update: The ghost IP eventually disappeared, however I then got a second device having same behaviour. I have tried all the above 4 times now and the "new" ghost IP is still appearing. I have removed that device from the network, but still the IP stays.
I have also tried with these comamnds sudo service pihole-FTL stop & sudo service pihole-FTL start to see if any difference.
Each time I clear the ARP the ghost IP appears with either a 1 or 2 in the Number of Queries column.
The issue happens when a "new" device is connected to the network and is handed out a dynamic address which is then changed to a static address.
e.g. in this last example the device was first given the dynamic IP address 192.168.2.246 then a new static address was configured as 192.168.2.22, where initial they both appears together in the Network Overview Table, then after deleting they appear as two entries where the initial dynamic address don't go away.
Sorry, replying to this has taken way too long. Everything you do needs to be done while FTL is stopped as FTL does a final database backup of its current knowledge on shutdown so it can reload this on (re)start.
You see me actually scratching my head right now if this is wrong behavior to even begin with. The reason is that this device switched address too quickly, and somehow FTL wasn't even able to get the MAC address. Note that we only query the ARP cache once per minute so it is very likely that - in the case you described - exactly this happened. As FTL was not able to get the MAC address, it also cannot know if 192.168.2.22 is the same device.
You can see this when looking at the mocked-up MAC address: ip-192.168.2.246 - any real device where FTL had a chance to get the MAC address, gets this updated.
This client may also simply be re-imported from the Query Log which is restored from disk after (re)starting of pihole-FTL. Can you confirm such devices always feature a ip-... MAC address as well? If so, we can probably resolve this by adding some extra flag to clients re-imported from the database to definitely skip such clients in ARP processing unless they have made at least one new query after the restart.
Final words:
You may gain additional insight when setting debug.arp = true in /etc/pihole/pihole.toml.
