@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.
@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.
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.
@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.
@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:
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.
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).
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.
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?
Nice work...and some good info on this page!