Some hostnames do not resolve

@DL6ER I have a few devices that have N/A for hostname, This isn’t new from the updates I applied this morning but might be new since pihole 4. These few devices have the hostname populated in my router lease table (not static addresses)…and I’m sure I’ve seen them in pihole before. My desktop is populated but a work laptop is not. Lots of activity from both and have been on for weeks…though I flushed the network table about 5 days ago.

Never the problems with mock devices and no negative effects from fixes to such.

Also, can you tell me the location of the Custom DNS script so I can change the default lines from 10 to 100? As mentioned earlier I don’t see it in the folder where all the other pages are defined (that is, the contents that fill the drop-down with "10, 25, 50, 100…

Thanks…looking great.

EDIT: Clarification - The missing host names (N/A) are in the same subnet (my primary LAN) as the Rpi itself. I have N/A on my VLAN devices not included in the Custom DNS list, but that’s understandable.

Are you not seeing this pull-down for number of entries to display?

A post was merged into an existing topic: Request: Ability to add clients to known client list from Network page

@jfb I see the pull down on the page, BUT I can’t find the script file so I can adjust the contents of that pull down from 10, 25, etc to 100, 250, etc. as I prefer to see max when I visit a page. I created a script that updates all the other pages after each pihole program update but can’t even find where this script file is located for the custom dns page. Thanks!

There shouldn’t have been a change causing this. We did some modifications to the internal resolving mechanisms to improve the behavior on the Docker platform, this should not, however, have affected anything else. Who does know your host names? I assume the router (= DHCP server?). If so, the router has to be one of the upstream destinations or conditional forwarding has to be used.

That’s not necessarily the case. As long as you have an upstream server knowing the host names for such clients, these host names should also show up in the network table (maybe after some time, but eventually they will).

You can test whether your Pi-hole knows about them by asking FTL directly for their hostnames, e.g.

dig -x 192.168.0.10 @127.0.0.1

assuming you run this locally on your Pi-hole and want to query the host name for 192.168.0.10.

It isn’t defined here as it is on the other pages so the default kicks in. I want to overhaul the Custom DNS page at some point but no promises I will get to it soon enough…

@DL6ER OK, ran dig as described and the unresolved device doesn’t resolve using dig. So looks like it’s fine, definitely not a pi-hole issue. (see edit)

The Custom DNS page…yeah no problem at all…was more curious as to why I couldn’t find it. Thanks!

EDIT: When I point the dig command to my router (from the RPi and not localhost), it does resolve the host name…so not sure what’s going on here.

> pi@rpi-2:~ $ dig -x 192.168.1.3 @192.168.1.1
> 
> ; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 192.168.1.3 @192.168.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36429
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;3.1.168.192.in-addr.arpa.      IN      PTR
> 
> ;; ANSWER SECTION:
> 3.1.168.192.in-addr.arpa. 3600  IN      PTR     EAP-245-AP.home.
> 
> ;; Query time: 0 msec
> ;; SERVER: 192.168.1.1#53(192.168.1.1)
> ;; WHEN: Mon Mar 23 17:59:45 EDT 2020
> ;; MSG SIZE  rcvd: 82

In this example above, the hostname in pihole shows N/A and this is actually a static address which now I realize shouldn’t matter since the query returns it.

How did you tell your Pi-hole to ask your router for the host name?

edit I moved this into a new thread for the sake of cleanness.

@DL6ER If I understand your question, in settings on the DNS tab I simply checked use conditional forwarding and entered the ip address for the router and the domain name “home”. Most devices resolve, a few do not. I do not have any of the three check boxes selected under advanced dns settings.

Hmm, but they do resolve using dig -x sent to your router as you showed above?

@DL6ER Just applied commits again (updates from yesterday?) and the one device that had N/A (laptop) is now showing properly, but in the example above (one of my two access points) is still showing “N/A”. These devices (2 APs, one switch) are different in they don’t have any queries to pihole (Last Query = “NEVER”). Here’s the dig results for the network switch:

pi@rpi-2:~ $ dig -x 192.168.1.6 @192.168.1.1

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 192.168.1.6 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6902
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;6.1.168.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
6.1.168.192.in-addr.arpa. 3600  IN      PTR     T2600G-28TS.home.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Mar 24 10:00:30 EDT 2020
;; MSG SIZE  rcvd: 83

The hostname is “T2600G-28TS”, but shows “N/A” on the network page. Here’s a result for one of my file servers that resolves fine (maybe a clue):

pi@rpi-2:~ $ dig -x 192.168.1.200 @192.168.1.1

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 192.168.1.200 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 852
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;200.1.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
200.1.168.192.in-addr.arpa. 3600 IN     PTR     Daisy.home.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Mar 24 10:03:20 EDT 2020
;; MSG SIZE  rcvd: 79

If I can provide anything else let me know. Thx!

Ah, yes! FTL does not try to acquire hostnames for clients it doesn’t know about (if they are only added from ARP knowledge). I will see what we can do about them. We will probably have to import them as clients without queries into FTL’s memory in order to obtain host names for them.

@DL6ER Also, my VLAN clients are all showing properly too. Everything else appears correct and complete. :slight_smile: Nice work…and some good info on this page!

If you update once again, the missing host names should show up (hopefully, I cannot test this myself at the moment).

Yep that fixed it, they resolved as do the others. Looks good…thanks!

@DL6ER
Edit: Although I do see a duplicate for my iphone now. One has interface = N/A (no MAC address) and the other has Eth0 and normal looking. Both have some queries.

Just flushed tables again and now my ipad has the same situation as iphone (iphone entry is fine now). Maybe it’s a timing issue…the ipad in this case showed up before the actual valid entry did…then the valid entry showed up properly (and thus duplicated entries as described for iphone above).

Could you share a screenshot so I can see the Last Query fields, whether the IP fields are identical, etc.?

Sure thing:

It’s not entirely clear to me why this is happening. Can you flush your network table and check again if the duplicate appears?

Flush and enable a bit more debugging output using:

sudo service pihole-FTL stop
sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM network; DELETE FROM network_addresses;"
echo "DEBUG_ARP=true" | sudo tee /etc/pihole/pihole-FTL.conf
sudo service pihole-FTL start

@DL6ER The sql statement throws an error “Error: attempt to write a readonly database”.

Guessing here…it looks like a timing issue. What I mean is…when I flush the table (using the gui), returning to the network page, the first thing I see are no rows. Clicking repeatedly, they populate in groups and the first group contains the non-MAC ID record, then followed by the correctly resolved MAC ID record (duplicate). Not sure if that helps pin it down.

Testing again just now (using GUI), flush table, click and zero rows display. Then nine rows, six devices on my primary LAN (the iPad showing no MAC ID again but no duplicate record yet) and three rows of my VLAN devices. The table continues to fill in over time. The first rows fill in after just a couple clicks…so within 15 seconds of flushing. Could this be related to the mock issue from the other thread? This did not just show up from your last code change, I noticed it just before that as well (before I mentioned some devices were showing N/A).

Testing again, this time I get four devices that are now missing MAC IDs (and all become duplicate IP records). Sixteen devices populating the first group (while clicking Network repeatedly…obviously even though that’s what I’m seeing there could be multiple iterations of building this table occurring behind the scenes).

Edit: Also, one of my two network switches is missing, but on my other pihole (I run two in parallel independent) it does show. That pihole is running the standard pi-hole beta 5 branch, not this network branch. That’s strange in that it’s really no different from my other switch and resolves similarly.

dig -x 192.168.1.5 @192.168.1.1

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 192.168.1.5 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57274
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;5.1.168.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
5.1.168.192.in-addr.arpa. 3600  IN      PTR     TL-SG108E.home.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Mar 25 08:58:15 EDT 2020
;; MSG SIZE  rcvd: 81

Oh yeah, it should have been

sudo sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM network; DELETE FROM network_addresses;"

I wonder if flushing from the dashboard does more than just flushing the network table. It might also flushe the neigh cache itself. For now, please try with this sqlite3 command.

Okay, so this means the client is (initially) not in the ARP cache (assumed it was flushed, see above), FTL added it as it thought it was a client not directly connected, then it comes up in the ARP cache and FTL adds it as non-mock device.

This only seems resolvable with FTL checking if it already recently created a mock-device for a new ARP device it wants to add and converting this over. This will be … difficult … to add, at least.

If one thing should not happen, then you should not see less devices on this branch. Is there any difference in the output of ip neigh (may need sudo) between the two devices?

It does. (At least my observation)