Force update of IP / hostname / clientname relationship

Help Community Help
8

DNS resolution is unavailable for more than 15 seconds, which is a pain in the *** for other users / devices

As stated before (using hostdir= and reload-lists), nslookup and dig immediately show the correct result on any workstation, I wonder why pihole (or at least some portions of the web interface) don't pick up the changes immediately.

When a new IPv6 address becomes active, and the user has a blocking problem, I force run the script, this to update the hosts file and the client entries immediately. It than takes minutes (more than 5, sometimes up to 20) for the query log and the dashboard to pick up the changes. This is especially annoying when having to solve a blocking problem for a new client (changed IPv6 temporary address). If multiple devices have recently started up, the query log shows a lot of IPv6 entries, this makes it more difficult to identify the user / device that has a problem.

Not a problem in my environment, I've tested my solution / script with several devices, for which I have entered a static configuration file (MAC / hostname), works perfectly, only the delay in the web interface remains a problem.

I wonder if the web interface pages handle the (address to hostname) resolution differently...

9

Have you had a look in the log which step takes so long? Maybe there is room for improvement?

10

I cannot recreate your observations:
DNS resolution does not stop for me, and dashboard refreshes with the correct information within a few seconds.
Differences in my setup: I do IP addresss updates manually (of course), I do not use IPv6, and I use addn-hosts and restartdns reload to include definitions.

EDIT: For comparison: I ran my tests on the latest vanilla Pi-hole (no custom checkouts), with half a dozen clients on my network.

11

I generated a debug log (not send to pihole), there are no errors in the log.
I checked pihole.log, no obvious errors
@DL6ER: I checked the pihole-FTL.log (using ftl new/tre-regex), this log has entries I don't like:

[2020-08-03 10:17:46.708 27839M] SQLite3 message: bind on a busy prepared statement: [SELECT * FROM queries WHERE timestamp >= 1596356266] (21)
[2020-08-03 10:17:46.708 27839M] SQLite3 message: misuse at line 83855 of [3bfa9cc97d] (21)
[2020-08-03 10:17:46.713 27839M] Resizing "/FTL-strings" from 8192 to 12288
[2020-08-03 10:17:46.718 27839M] Resizing "/FTL-queries" from 229376 to 458752
[2020-08-03 10:17:46.742 27839M] SQLite3 message: bind on a busy prepared statement: [SELECT * FROM queries WHERE timestamp >= 1596356266] (21)
[2020-08-03 10:17:46.743 27839M] SQLite3 message: misuse at line 83855 of [3bfa9cc97d] (21)

A lot more log entries like this, the list goes on...

I checked all my scripts (filesearch) for the string SELECT * FROM queries WHERE timestamp >=, nothing found, so it doesn't appear to be something I'm initiating, I also ran the majority of my scripts that execute sqlite3 statements, this to verify if it may be some thing I'm causing, no new entries in the pihole-FTL log...

if your not using IPv6, with the windows 10 privacy extensions, you will never have this problem. adding an IPv4 hostname (to custom.list or any other hosts file) and or a client to the database is a one time operation.

The reason(s) for using IPv6, and adding the temporary addresses to hosts and database:

  • IPv6 is here to stay, you better get onboard...
  • More recent programs, I'm using, appear to prefer IPv6 over IPv4, when available.
  • DL6ER once said: If you're not using IPv6, you're missing out on a big part of the internet...
  • I want all pihole clients listed by name, this to ensure no external devices are using my network (when an IP address without a client name is listed in the client list ( telnet 127.0.0.1 4711 - >top-clients withzero (256)), it immediately triggers my attention -> mail)
12

I am not debating your use of IPv6.
I just don't have it enabled myself, so I add and delete lines for existing IPv4s to mimic what your script does.
I don't think it matters for the refresh issue, but thought I'd mention it nonetheless.

(edited for clarity)

13

I wasn't thinking about error but lags in the startup of FTL, especially while counting/compiling regex entries after a reload.

I'm not sure if you are aware of this topic: DNS resolution unexpectedly stops after upgrade to 5.0 - #38 by yubiuser

If you don' have any debug flag enabled, you would see a delay between those two lines

[2020-07-02 11:41:59.853 1202] Reloading DNS cache

[2020-07-02 11:43:26.199 1202] Compiled 0 whitelist and 0 blacklist regex filters in 5.9 msec

With advanced debug flags it appears that pihole hangs at counting domains in vw_gravity
Querying count of distinct domains in gravity database table vw_gravity

And using the special debug branch it turned out to be here

[2020-07-17 17:23:44.892 28893M] Reading regex from database...
[...]
[2020-07-17 17:24:37.655 28893M] Querying count of distinct domains in gravity database table vw_regex_blacklist: SELECT COUNT(DISTINCT domain) FROM vw_regex_blacklist

It seems to be a tough bug, so far only one person encountered it on master but on new/regex I could reproduce it.

14

pihole restartdns reload:

[2020-08-03 11:12:22.614 27841M] Reloading DNS cache

[2020-08-03 11:12:22.692 27841M] Compiled 2 whitelist and 35 blacklist regex filters for 15 clients in 31.6 msec
15

Ok. Then

must hang somewhere else.

Just curious: does pihole restartdns (without any suffix) fixes the problem with dashboard hostname resolution?

16

tried this 2 times (dashboard and stopwatch on a different computer. Restarted the windows computer (ipv6 with privacy extensions) and forced the script to run. result with restartdns (no options):

  • 20 seconds
  • 34 seconds

why does restartdns (no options) pick up the changes almost immediately , while restartdns (reload-list) takes forever?

edit
@DL6ER the sqlite3 errors in the log, mentioned earlier, appear after pihole restartdns but NOT after pihole restartdns reload-lists (currently using MAXDBDAYS=8 and DBINTERVAL=2 in /etc/pihole/pihole-FTL.conf)
/edit

18

I don't like them either. They are created only in a very specific case on a full restart (never on a reload). But you have already seen this. I agree this should be fixed. There is a small bug where we do not check properly for the busy state of the database during initial database importing but only if there are records with the regex ID of a non-CNAME caused block was read from the database.

Fixed now in

pihole checkout ftl fix/read_should_not_bind

@jpgpi250 Please check if this resolves the issue for you. This branch is based on the latest release/v5.2 branch.

19

thanks again for looking into this, much appreciated.

does fix/read_should_not_bind also contain the code from new/tre-regex or do I have to remove the regex (.*;querytype=!A) before switching?

any idea why query log and dashboard have a very long update time (switch from displaying IP to hostname) when using restartdns reload-lists as opposed to restartdns (long-term data / query log doesn't have the problem)?

20

Just leave it, it will be ignored. I also switched from new/tre-regex to an other branch without disabling or removing it.

21

@jpgpi250 @yubiuser is right, just leave it and ignore the regex warning about invalid syntax (if any).

No, this seems separate, the corresponding debug mode (I think it is DEBUG_RESOLVER=true) should show when FTL tries to resolve IP addresses and what the outcome is.

22
  • fairly easy to get the error when running new/tre-regex, a few restarts and bingo
  • impossible to get the error when running fix/read_should_not_bind, force rotated the log and ran (still running):
while : ;do
	sleep 60
	grep "SQLite3 message" /var/log/pihole/pihole-FTL.log
	pihole restartdns
done

must of restarted over 30 times by now, no errors in the log (yes, my log isn't in the default location), so the fix works. thank you!!!

23

Thank your for testing it so quickly. It is scheduled to still make it into v5.2

24

Appreciate your work, but again, just like the new/mac-clients, the new/super-clients branch doesn't solve my, and I assume other users, problem.

You're always assuming that arp -a and / or ip neigh (the equivalent code in pihole-FTL) is able to figure out the MAC address of the clients. My pi is isolated on a separated physical network, and doesn't see anything but the router/firewall (4 port) interface.

I assume neither branches will solve this problem, unless you claim this to be otherwise.

One of the reasons my dashboard, query log and long term data views are a total mess is, as explained earlier here (but that topic unfortunately turned into a FTL problem and fix) is, again I assume, the missing data in the pihole-FTL database

FTL sees, and ads the clients to the network table, but fails to update the name field, example screenshot below

image
image1712×1654 415 KB

FTL sometimes inserts the hostname into the database, but often fails to enter this info, even if the data is available (separate configuration file, added to dnsmasq). If that field contains a value, the dashboard and the query log display the correct info (hostname) after a while, if the field is (remains) blank, the query log displays the ipv6 address, all different because of the windows 10 privacy extensions ( all the IPs in the screenshot are from a single client, db up and running (new v5.1.2) for almost 2 days)

currently, I'm investigating a safe way to inject the names my self, that is one of the reasons I asked for a version indication in pihole-FTL.db,

25

Maybe because it wasn't designed to?

26

Have you confirmed (using dig -x) that the information is really available? Maybe there is some other problem.

Looking at your description and your screenshot, I don't think this affects a lot of users. They typically don't separate (V)LANs at home. This is not to say this is not an important thing, it is just maybe less common than you'd expect.

I think this is a good assumption. How should it work differently? As long as Pi-hole does not know the foreign MAC address, it cannot know which devices belong together.

Yes, I guess that's the issue. If Pi-hole has thousands of users, maybe tens of thousands (we don't know because of the anonymity of the downloads from Github and no Pi-hole telemetry), a lot of unusual network configurations will show up. If the information is not available, how should Pi-hole (automatically) detect which address belong to which device.

As always, just oppnons: I disagree with pseudoclients. It somehow seems to suggest they are not really there. While one might argue that this is the case, they actually physically exist as devices and are no pseudo. In my understanding the term pseudo would cause more confusion. super may not be optimal, either, but right now at least it seems more descriptive for the "it is more than one ordinary client".

Otherwise this is really a cool thing. I just tried it in my network and it seems to work just as expected. I even configured all my devices now and have not seen anything odd.

27

the database table, current content

image
image1361×1248 180 KB

the hosts file

2a02:1810:4d02:6903:49b3:cc94:cd8:dd0e y50ipv6 y50ipv6.localdomain # Mon 10 Aug 08:00:01 CEST 2020
2a02:1810:4d02:6903:d849:7563:3852:ae93 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 11:40:02 CEST 2020
2a02:1810:4d02:6903:280c:5ca8:438:f73 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 14:40:01 CEST 2020
2a02:1810:4d02:6903:a8ed:9058:a230:39fe y50ipv6 y50ipv6.localdomain # Mon 10 Aug 15:30:01 CEST 2020
2a02:1810:4d02:6903:40e9:69:98c0:b990 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 16:21:02 CEST 2020
2a02:1810:4d02:6903:194e:5c8d:14d7:1cc9 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 17:40:02 CEST 2020
2a02:1810:4d02:6903:1d92:155:e2e2:94b2 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 21:50:02 CEST 2020
2a02:1810:4d02:6903:b4ac:bb3f:83d6:6894 y50ipv6 y50ipv6.localdomain # Mon 10 Aug 22:40:01 CEST 2020
2a02:1810:4d02:6903:49b8:e421:9a56:b2c8 y50ipv6 y50ipv6.localdomain # Tue 11 Aug 08:00:01 CEST 2020
2a02:1810:4d02:6903:9910:ed01:952c:e35c y50ipv6 y50ipv6.localdomain # Tue 11 Aug 14:40:01 CEST 2020
2a02:1810:4d02:6903:18f7:fd2f:c2cc:454c y50ipv6 y50ipv6.localdomain # Tue 11 Aug 22:12:01 CEST 2020
2a02:1810:4d02:6903:506c:1507:19d1:a873 y50ipv6 y50ipv6.localdomain # Wed 12 Aug 08:00:01 CEST 2020
2a02:1810:4d02:6903:d9e3:deb:2516:3f09 y50ipv6 y50ipv6.localdomain # Wed 12 Aug 10:20:01 CEST 2020

the dig -x result (last IPv6 entry, = current windows 10 temporary address)

dig -x 2a02:1810:4d02:6903:d9e3:deb:2516:3f09

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> -x 2a02:1810:4d02:6903:d9e3:deb:2516:3f09
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38820
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;9.0.f.3.6.1.5.2.b.e.d.0.3.e.9.d.3.0.9.6.2.0.d.4.0.1.8.1.2.0.a.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
9.0.f.3.6.1.5.2.b.e.d.0.3.e.9.d.3.0.9.6.2.0.d.4.0.1.8.1.2.0.a.2.ip6.arpa. 2 IN PTR y50ipv6.localdomain.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 12 10:34:29 CEST 2020
;; MSG SIZE  rcvd: 134

yes I'm sure, pihole-FTL doesn't always pickup the name of the host.
My original question, in the topic that drifted off topic (FTL error message) was: How do I force FTL to update the IP / hostname relationship.

28

There should be no need to, it automatically does once an hour. You can see PTR requests coming in ont he Query Log. Maybe try DEBUG_RESOLVER=true in pihole-FTL.conf + pihole restartdns ?

Extensive information about hostname resolution like which DNS servers are used in the first and second hostname resolving tries (only affecting internally generated PTR queries).

Configuration - Pi-hole documentation

Then watch pihole-FTL.log for the messages related to trying to resolve these IP addresses you added to the HOSTS file.

edit

One other thing that came to my mind: Have you reloaded FTL after adding these lines to your HOSTS file? Not sure if this is needed. They seem to have been added only over two days.