Well, done... @gpb Please check whether your mock-devices magically become real devices once the kernel gathered the necessary details. Note that I do all this in an offline environment where I'm directly interacting with my kernel trying to make is behave similarly strange than your network equipment does. While I'm fairly certain this is equivalent, a final testing in the real affected system would be great.
@DL6ER Ran the command to stop, delete, enable debug and restart. Clicking Network, again, no rows...repeated clicking, populates, this time with zero host names populated (all N/A). Then, all host names appear except one, on the primarly LAN with no mac ID (duplicate scenario again).
IP Neigh does show differences. On the non-network branch Rpi, there are three additional IP records including the missing switch. Pinging the missing switch adds it to the IP Neigh list...so that should self-resolve now. For me, missing devices that never use pi-hole is not an issue for me...I only mentioned it as it was something I noticed. Thx.
So you flushed the network table, updated FTL (and restarted it) and it still does not convert the recently added mock device into a real one?
@DL6ER I replied before seeing your last post. So now have updated (about 10 mins ago), flushed and noted all devices show initially as mock, then after a bit of time, start to be replaced with legit records with mac address and hostname.
All devices populated as above except two which seem "stuck". Those two in particular are not active devices (no recent DNS queries...like in the past 10 minutes), I assume once they hit pi-hole with a request they too will fill in. They resolve fine using dig though. I'm also missing host names again on VLAN devices, half are there and half are missing. I think those too are low activity devices with regard to DNS queries. However, I am not seeing any duplicates! 
EDIT: In fact most of the devices have resolved now on the VLAN, the two others have not yet but that looks to be the pattern. Once they query a DNS record, they get resolved.
EDIT 2: The missing host names show up once the device performs a DNS query...but those same devices (most) are also in the Custom DNS table...just an observation if that matters.
EDIT 3: Just for clarification, the reason one RPi has a different ip neigh result is, the one with more entries displayed also runs Nagios...and it pings devices all day keeping that data current.
1 Like
@DL6ER Another scenario I noticed this morning (new for me). We have an apple watch which rarely uses the network directly (mostly connects via an iphone). There was a mock record added yesterday with 2 queries. The record in Network sat there for 10+ hours (no mac id), this morning I noticed it at some point did connect to the network and now there are two Network records (mock and ARP). This might be as designed since the time gap between the two was so long. Just mentioning as now I have dup's and not sure if the mock will be removed at some point. I think this ties in with comments by @yubiuser on the other thread. These are not show-stoppers in my opinion and I get it's impossible to tell if these might have been two distinct devices. Just an FYI...thx.
Which branch are you using at the moment?
all_clients_network_table or all_clients_network_table_no-auto?
If it is the former I think this duplicates might be expected because the 'transformation' rule kind of overrides the 'do not add incomplete ARP entry devices' rule. For devices with incomplete ARP entries for more >1h those rules conflict - we have to decide what we want or how we get the best out of those two approaches.
I used "pihole checkout web new/all_clients_network_table" several days ago when it was made available and haven't changed since. Is there a command I can issue to check what my current branch is? OK...so I'm confused...lol. Which should I be on for it to work as we were discussing?
Pi-hole version is v4.3.5-450-g1b35eeb (Latest: v4.4)
AdminLTE version is v4.3.2-437-gbc9c656e (Latest: v4.3.3)
FTL version is vDev-7759a76 (Latest: v4.3.1)
You can check your current branch in the footer of the WEB GUI or on github by looking for the commit ('7759a76'). But I know 7759a76 is pihole checkout web new/all_clients_network_table
If it's working for you it is fine and you don't have to do anything. But if you want to help further debugging you could do the steps I have mentioned here.
Thanks...switched to "no_auto".
Just for the future: pihole-FTL branch
Yes. I thought for a second about an option where users can say: Yes, my DHCP server ensures that the same devices always get the same IP addresses, but, hey, most users wouldn't know probably and we should not go this far. We are already much farther than I planed to go, initially.
The important question at this point seems to be: Why are you seeing incomplete devices at all. I did never see such, however, I, apparently, also do not own fancy enough devices to trigger this. Normal computers and laptops behave ... well .. normally. A once-and-for-all solution seems to be to switch to Pi-hole's DHCP server because the ARP table should then be guaranteed to have the maximum available wisdom in your network. Just saying.
No, they don't conflict. The transformation rule can always only come on top of an already added mock-device. And this would not have been added if there would have been an incomplete record. So there has had to be no entry for this device at all in the ARP table, at least once when we checked.
The rules are already quite complex now and I wouldn't want to push their complexity further, I'm going to document them now in the source code to ensure we all understand them at some distant point in the future where we look at this again.
@DL6ER I don't mind the duplicates, I understand the issue. I think it's excellent as is and appreciate the effort and glad I was able to help with feedback. I prefer to have the DHCP servers on the router (OPNsense) since it controls VLANs and for a while a second physical LAN. And I have other reporting utilities running on the router box that also grab dhcp data and prefer not to introduce additional complexity on that device. Thx!
Thanks 
Thanks for the explanation. I think I got confused by your suggestion.
Yeah, not done, indeed just a suggestion. There is no harm in keeping both, just somewhat higher added complexity of the code.
1 Like
For me, none of my local hostnames get resolved in the "Top Clients (total)" table of the Dashboard.
Pihole is not my DHCP. I can resolve the IPs to hostnames on the pihole using dig and pointing it to my router/DHCP server. I have "Conditional Forwarding" enabled and added the IP of my router and the local domain name (local.mydomain.de). Example given below:
19:10:52 [~]
root@pihole $ dig -x 10.0.1.89 @10.0.0.254
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 10.0.1.89 @10.0.0.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21542
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;89.1.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
89.1.0.10.in-addr.arpa. 0 IN PTR x1.local.mydomain.de.
;; Query time: 1 msec
;; SERVER: 10.0.0.254#53(10.0.0.254)
;; WHEN: Tue Apr 07 19:12:30 CEST 2020
;; MSG SIZE rcvd: 85
19:12:30 [~]
root@pihole $ dig -x 10.0.1.89 @localhost
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 10.0.1.89 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54050
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;89.1.0.10.in-addr.arpa. IN PTR
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Apr 07 19:12:35 CEST 2020
;; MSG SIZE rcvd: 51
Any ideas where to start looking for the problem?
Cheers,
Bjoern
Did you flush your network table from the settings screen?
Hej,
yes, multiple times, restarted, etc... nothing helped 
Cheers,
Bjoern
Conditional Forwarding is something that has been there since the very early days of Pi-hole. Unfortunately, it isn't the most reliable thing you can imagine.
Try disabling it and adding instead
rev-server=10.0.0.0/8,10.0.0.254
to a new file
/etc/dnsmasq.d/05-rev-server.conf
and run
pihole restartdns
This will make sure to send all PTRs for 10.*.*.* names to your router's IP address.
Fingers crossed that the hostnames will show up a few minutes later.
Hej, thanks for helping!
Disabling "conditional forwarding" and adding your suggestion at least fixed "dig" instantly after restarting DNS:
root@pihole $ dig -x 10.0.1.89 @10.0.0.254
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 10.0.1.89 @10.0.0.254
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5657
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;89.1.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
89.1.0.10.in-addr.arpa. 0 IN PTR x1.local.mydomain.de.
;; Query time: 1 msec
;; SERVER: 10.0.0.254#53(10.0.0.254)
;; WHEN: Wed Apr 08 11:18:24 CEST 2020
;; MSG SIZE rcvd: 85
root@pihole $ dig -x 10.0.1.89 @localhost
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 10.0.1.89 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59417
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;89.1.0.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
89.1.0.10.in-addr.arpa. 0 IN PTR x1.local.mydomain.de.
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Apr 08 11:18:30 CEST 2020
;; MSG SIZE rcvd: 85
But even after flushing logs, and the network table followed by a reboot, the hostnames do not show up on the dashboard:
Even after waiting for 41 min (292 requests later for 10.0.1.89), no hostnames show up on the dashboard.
Cheers,
Bjoern
Verify that Never forward reverse lookups for private IP ranges is unchecked on Pi-hole’s Settings | DNS panel.
(Edit: It wouldn't normally interfere with Conditional Forwarding, so just a guess. But needs to be unchecked if you want local hostname resolution when using your router as Pi-hole's sole upstream without CF enabled.)
