Feedback for "Allow defining clients by their MAC address, host name and networking interface"

[DL6ER]

@drwatson

[2020-06-23 21:33:19.613 1260] Locking database

We're trying to obtain a lock although there is already one:

@drwatson

[2020-06-23 21:33:19.611 1260] Locking database
[2020-06-23 21:33:19.611 1260] Locking database: Success

which is what is causing the inter-lock state. I have pushed a possible fix for this. Please update your FTL and try again.

[drwatson]

I am now on:
vDev-b5cb27a

pihole restartdns seems to suceed (no timeout anymore)! The web GUI does not print Connection to API lost anymore and is actually usable again. But the DNS service is still down as indicated by the first status light in the GUI and by

~$ pihole status
  [✗] DNS service is NOT running

Here is the logfile pihole-FTL.txt (138.0 KB). I have unsuccessfully tried to prune it to fit in this response, therefore, I attach it.

[DL6ER]

@drwatson

But the DNS service is still down

Is this also your experience (does the Internet connection work using the Pi-hole)?

The test done by pihole status (the very same test is used by the web interface) is merely checking if there is something listening on 127.0.0.1 TCP port 53. You may have a firewall set up that blocks this, please check this. If you can do

dig discourse.pi-hole.net @127.0.0.1

on your Pi-hole and then again with

dig discourse.pi-hole.net @127.0.0.1 +tcp

Maybe also try again with the IP addresses of your "real" interface (ens3).

[DL6ER]

I pushed another small update that should improve performance slightly. It is unlikely that you'll really notice it, however, it's always a good idea if you test always on the most recent revision to check if I broke something meanwhile

[Coro]

Thank you. I think I already see an improvement. With one of the previous versions I had one core working 100% for some time when restarting the Pi-hole. This is now gone.

[yubiuser]

@yubiuser

Macvendor detection is still not working.

Issue persists.

Do others experience the same?

Coming from other branches, flushing network table and vendor is not written to database.
(macVendor empty in sqlite3 /etc/pihole/pihole-FTL.db -header -column "Select * from network;" )

[PromoFaux]

@drwatson

Updating the over the web GUI succeeds as well but also prints in the pop-up:
Updating DNS settings failed. Result: (exactly like this with empty space after 'Result:')
However when refreshing the page, the chosen servers (including the DNSv6 servers) and settings are selected.

Is this new behaviour (read: regression!) in the development branch? What happens when you do this on 5.0?

[Coro]

@yubiuser

Coming from other branches, flushing network table and vendor is not written to database.

Have you really checked the content of the database table? Before it looked like you commented based on a screenshot of the network table web page. It could also be an issue with the web interface where something changed such that the vendor isn't shown even when it is available.

[yubiuser]

Yes I did.

nanopi@nanopi:~$ sqlite3 /etc/pihole/pihole-FTL.db -header -column "Select * from network;"
id          hwaddr             interface   firstSeen   lastQuery   numQueries  macVendor 
----------  -----------------  ----------  ----------  ----------  ----------  ----------
1           f0:9f:c2:dc:2f:75  eth0        1592985420  1592913937  4                     
2           e0:63:da:2c:19:17  eth0        1592985420  1592993891  9                     
3           18:e8:29:e0:12:a3  eth0        1592985420  0           0                     
4           f0:9f:c2:1e:8f:e9  eth0        1592985420  1592996504  228                   
5           f0:9f:c2:ce:09:31  eth0        1592985420  0           0                     
6           ip-10.0.10.136     eth0        1592985420  1592996505  1622                  
7           ip-10.0.99.33      eth0        1592985420  1592996474  369                   
8           ip-10.0.99.192     eth0        1592985480  1592996494  394                   
9           ip-10.0.10.190     eth0        1592985480  1592996484  283                   
10          ip-127.0.0.1       lo          1592985480  1592996400  164                   
11          ip-10.0.10.84      N/A         1592985540  1592973712  4                     
12          ip-10.0.10.6       N/A         1592985540  1592982011  4                     
13          ip-10.0.10.182     eth0        1592985540  1592995340  102                   
14          ip-10.0.40.3       eth0        1592985540  1592994831  902                   
15          ip-10.0.10.64      eth0        1592985540  1592996326  161      

[drwatson]

@DL6ER

If you can do

dig discourse.pi-hole.net @127.0.0.1

Yes, this works.

@DL6ER

and then again with

dig discourse.pi-hole.net @127.0.0.1 +tcp

This does not work:

~$ dig discourse.pi-hole.net @127.0.0.1 +tcp
;; Connection to 127.0.0.1#53(127.0.0.1) for discourse.pi-hole.net failed: connection refused.

There is no firewall in place on the system running PiHole, also iptables is not configured:

~$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

In fact, nothing is listening for IPv4-TCP connections on port 53 on that system (not even FTL):

~$ sudo netstat -tuplen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          15607      449/lighttpd        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          15267      414/sshd            
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      998        41362      7956/pihole-FTL     
tcp6       0      0 :::80                   :::*                    LISTEN      0          15608      449/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      998        41346      7956/pihole-FTL     
tcp6       0      0 :::22                   :::*                    LISTEN      0          15278      414/sshd            
tcp6       0      0 ::1:4711                :::*                    LISTEN      998        41364      7956/pihole-FTL     
udp        0      0 0.0.0.0:53              0.0.0.0:*                           998        41343      7956/pihole-FTL     
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          14977      516/dhcpcd          
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          13816      329/dhclient        
udp6       0      0 :::546                  :::*                                0          15503      516/dhcpcd          
udp6       0      0 :::53                   :::*                                998        41345      7956/pihole-FTL

I monitored the output of the above command when executing pihole restartdns. For a short moment the line

tcp  0  0 0.0.0.0:53   0.0.0.0:*   LISTEN  998  59917  10132/pihole-FTL

is added but immediately vanishes again.

[drwatson]

Here's what I tried:

1. Starting from a fresh PiHole v5 version (master).

• The version information from the web interface: Pi-hole Version v5.0, Web Interface Version v5.0, FTL Version v5.0
• Changing to DNSv6 servers works as expected. The GUI spawns the popup stating "The DNS settings have been updated (using 2 DNS servers)"

2. Applying the fix to this master branch version.

• pihole checkout core fix/ip_validation_setdns in the terminal
• Now the version information are: Pi-hole Version vDev (fix/ip_validation_setdns, v5.0-493-g3205606), Web Interface Version v5.0, FTL Version v5.0
• Works as well! The same popup message is displayed.

3. Starting again with a fresh version of PiHole v5 on master:

• Switching to the development branch: pihole checkout dev
• Immediately afterwards applying the fix: pihole checkout core fix/ip_validation_setdns
• Now the versions are: Pi-hole vDev (fix/ip_validation_setdns, v5.0-493-g3205606), Web Interface vDev (devel, v5.0-441-g59bd4de),FTL vDev (development, vDev-bd405e9)
• The popup message I referred to in my last post spawns: Updating DNS settings failed. Result:
• The chosen DNSv6 servers remain checked when re-visiting the DNS-settings page. This was not the case before (without the fix). It would fail (also announced ba a slightly different popup message) and when re-visiting the web page no DNSv6 server was checked anymore.

Maybe indeed a regression due to changes in the development branch

[DL6ER]

@yubiuser

@yubiuser

Macvendor detection is still not working.

Issue persists.

Ah, sorry, I missed that. It should be fixed now. It was caused by a log precedence issue (we stored NULL even if there was a valid record).

@drwatson

In fact, nothing is listening for IPv4-TCP connections on port 53 on that system (not even FTL)

This should not be happening.

@drwatson

I monitored the output of the above command when executing pihole restartdns . For a short moment the line

tcp  0  0 0.0.0.0:53   0.0.0.0:*   LISTEN  998  59917  10132/pihole-FTL

is added but immediately vanishes again.

Well, this is something new. Can you post the content of /etc/dnsmasq.d/01-pihole.conf ?
(and maybe from the other files in this directory in case there are some more)

[yubiuser]

@DL6ER

Ah, sorry, I missed that. It should be fixed now. It was caused by a log precedence issue (we stored NULL even if there was a valid record).

Confirm macVendor is fixed after flushing network table. DEBUG MAC Vendor works as well.

[drwatson]

Yesterday evening I updated the FTL-branch to the most recent version, and... it worked again! FTL now listens on for IPv4 TCP DNS requests. I did not work after the last update (the fix to the locking-problem), or after repeated new setups from the scratch. I am bit puzzled.

For the sake of completeness this is (and was before performing the latest update) the content of /etc/dnsmasq.d/01-pihole.conf:

addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list


localise-queries


no-resolv



cache-size=10000

log-queries
log-facility=/var/log/pihole.log

local-ttl=2

log-async




server=8.8.8.8
server=8.8.4.4
interface=ens3
server=/use-application-dns.net/

No other files are in this directory.

It worked quite well until just now, when FTL crashed:

[2020-06-25 13:00:01.340 4838] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-06-25 13:00:01.340 4838] ---------------------------->  FTL crashed!  <----------------------------
[2020-06-25 13:00:01.340 4838] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-06-25 13:00:01.340 4838] Please report a bug at https://github.com/pi-hole/FTL/issues
[2020-06-25 13:00:01.340 4838] and include in your report already the following details:
[2020-06-25 13:00:01.340 4838] FTL has been running for 46876 seconds
[2020-06-25 13:00:01.340 4838] FTL branch: new/mac_clients
[2020-06-25 13:00:01.340 4838] FTL version: vDev-73473ac
[2020-06-25 13:00:01.340 4838] FTL commit: 73473ac
[2020-06-25 13:00:01.340 4838] FTL date: 2020-06-24 20:44:04 +0200
[2020-06-25 13:00:01.340 4838] FTL user: started as pihole, ended as pihole
[2020-06-25 13:00:01.340 4838] Compiled for x86_64 (compiled on CI) using gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
[2020-06-25 13:00:01.340 4838] Received signal: Segmentation fault
[2020-06-25 13:00:01.340 4838]      at address: 0x18
[2020-06-25 13:00:01.340 4838]      with code: SEGV_MAPERR (Address not mapped to object)
[2020-06-25 13:00:01.341 4838] Obtained lock for _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.341 4838] **** new UDP query[AAAA] "jenson.api.swiftkey.com" from ens3:fd00::c1a6:8f8e:24f:ff4 (ID 16366, FTL 22494, /root/project/src/dnsmasq/forward.c:1556)
[2020-06-25 13:00:01.341 4838] getOverTimeID(1593083100): 138
[2020-06-25 13:00:01.341 4838] Adding "jenson.api.swiftkey.com" (len 24) to buffer. next_str_pos is 56439
[2020-06-25 13:00:01.341 4838] jenson.api.swiftkey.com is not known
[2020-06-25 13:00:01.341 4838] Getting sqlite3_stmt** 0x558a8c3f6de0[15] --> 0x558a8c3fdf18
[2020-06-25 13:00:01.342 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c3fdf18, whitelist): 0
[2020-06-25 13:00:01.342 4838] Getting sqlite3_stmt** 0x558a8c3f6e10[15] --> 0x558a8c3feb18
[2020-06-25 13:00:01.342 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c3feb18, blacklist): 0
[2020-06-25 13:00:01.342 4838] Getting sqlite3_stmt** 0x558a8c401480[15] --> 0x558a8c3fe688
[2020-06-25 13:00:01.361 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c3fe688, gravity): 0
[2020-06-25 13:00:01.362 4838] Removed lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:622)
[2020-06-25 13:00:01.362 4838] Waiting for lock in _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:709)
[2020-06-25 13:00:01.362 4838] Obtained lock for _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:709)
[2020-06-25 13:00:01.362 4838] **** forwarded jenson.api.swiftkey.com to 9.9.9.9 (ID 16366, /root/project/src/dnsmasq/forward.c:549)
[2020-06-25 13:00:01.362 4838] Removed lock in _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:815)
[2020-06-25 13:00:01.372 4838] Backtrace:
[2020-06-25 13:00:01.373 4838] B[0000]: 0x558a8bcdf2c9, /usr/bin/pihole-FTL(+0x342c9) [0x558a8bcdf2c9]
[2020-06-25 13:00:01.389 4838] B[0001]: 0x7febddfe3730, /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7febddfe3730]
[2020-06-25 13:00:01.389 4838] B[0002]: 0x558a8bd64151, /usr/bin/pihole-FTL(+0xb9151) [0x558a8bd64151]
[2020-06-25 13:00:01.392 4838] B[0003]: 0x558a8bde7f7c, /usr/bin/pihole-FTL(+0x13cf7c) [0x558a8bde7f7c]
[2020-06-25 13:00:01.396 4838] B[0004]: 0x558a8bde8f39, /usr/bin/pihole-FTL(+0x13df39) [0x558a8bde8f39]
[2020-06-25 13:00:01.399 4838] B[0005]: 0x558a8bd4e0e7, /usr/bin/pihole-FTL(+0xa30e7) [0x558a8bd4e0e7]
[2020-06-25 13:00:01.403 4838] B[0006]: 0x558a8bd4eaeb, /usr/bin/pihole-FTL(+0xa3aeb) [0x558a8bd4eaeb]
[2020-06-25 13:00:01.406 4838] B[0007]: 0x558a8bdb9b9b, /usr/bin/pihole-FTL(+0x10eb9b) [0x558a8bdb9b9b]
[2020-06-25 13:00:01.416 4838] B[0008]: 0x558a8bdcf5bf, /usr/bin/pihole-FTL(+0x1245bf) [0x558a8bdcf5bf]
[2020-06-25 13:00:01.419 4838] B[0009]: 0x558a8bdd417f, /usr/bin/pihole-FTL(+0x12917f) [0x558a8bdd417f]
[2020-06-25 13:00:01.423 4838] Waiting for lock in _FTL_dnssec() (/root/project/src/dnsmasq_interface.c:1364)
[2020-06-25 13:00:01.423 4838] Obtained lock for _FTL_dnssec() (/root/project/src/dnsmasq_interface.c:1364)
[2020-06-25 13:00:01.423 4838] **** got DNSSEC details for jenson.api.swiftkey.com: 2 (ID 16366, /root/project/src/dnsmasq/forward.c:1237)
[2020-06-25 13:00:01.423 4838] Removed lock in _FTL_dnssec() (/root/project/src/dnsmasq_interface.c:1404)
[2020-06-25 13:00:01.423 4838] Waiting for lock in _FTL_reply() (/root/project/src/dnsmasq_interface.c:869)
[2020-06-25 13:00:01.423 4838] Obtained lock for _FTL_reply() (/root/project/src/dnsmasq_interface.c:869)
[2020-06-25 13:00:01.423 4838] **** got reply jenson.api.swiftkey.com is (NODATA) (ID 16366, /root/project/src/dnsmasq/cache.c:480)
[2020-06-25 13:00:01.423 4838]      Flags: F_FORWARD F_NEG F_IPV6 
[2020-06-25 13:00:01.423 4838] Removed lock in _FTL_reply() (/root/project/src/dnsmasq_interface.c:1019)
[2020-06-25 13:00:01.425 4838] B[0010]: 0x558a8bdd46d5, /usr/bin/pihole-FTL(+0x1296d5) [0x558a8bdd46d5]
[2020-06-25 13:00:01.428 4838] Waiting for lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.429 4838] Obtained lock for _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.429 4838] **** new UDP query[AAAA] "jenson.api.swiftkey.com" from ens3:192.168.2.105 (ID 16367, FTL 22495, /root/project/src/dnsmasq/forward.c:1549)
[2020-06-25 13:00:01.429 4838] getOverTimeID(1593083100): 138
[2020-06-25 13:00:01.429 4838] jenson.api.swiftkey.com is not known
[2020-06-25 13:00:01.429 4838] Getting sqlite3_stmt** 0x558a8c3f6de0[4] --> 0x558a8c3e5258
[2020-06-25 13:00:01.429 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c3e5258, whitelist): 0
[2020-06-25 13:00:01.429 4838] Getting sqlite3_stmt** 0x558a8c3f6e10[4] --> 0x558a8c3e5068
[2020-06-25 13:00:01.429 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c3e5068, blacklist): 0
[2020-06-25 13:00:01.429 4838] Getting sqlite3_stmt** 0x558a8c401480[4] --> 0x558a8c512688
[2020-06-25 13:00:01.429 4838] domain_in_list("jenson.api.swiftkey.com", 0x558a8c512688, gravity): 0
[2020-06-25 13:00:01.429 4838] Removed lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:622)
[2020-06-25 13:00:01.431 4838] **** got cache answer for jenson.api.swiftkey.com /  / <unknown> (ID 16367, /root/project/src/dnsmasq/rfc1035.c:1797)
[2020-06-25 13:00:01.431 4838]      Flags: F_FORWARD F_NEG F_IPV6 
[2020-06-25 13:00:01.431 4838] Waiting for lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.431 4838] Obtained lock for _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.431 4838] Removed lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1314)
[2020-06-25 13:00:01.433 4838] B[0011]: 0x558a8bdd481a, /usr/bin/pihole-FTL(sqlite3_prepare_v2+0x1a) [0x558a8bdd481a]
[2020-06-25 13:00:01.434 4838] Waiting for lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.434 4838] Obtained lock for _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.434 4838] **** new UDP query[AAAA] "jenson.api.swiftkey.com" from ens3:fd00::c1a6:8f8e:24f:ff4 (ID 16368, FTL 22496, /root/project/src/dnsmasq/forward.c:1556)
[2020-06-25 13:00:01.434 4838] getOverTimeID(1593083100): 138
[2020-06-25 13:00:01.434 4838] jenson.api.swiftkey.com is known as not to be blocked
[2020-06-25 13:00:01.434 4838] Removed lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:622)
[2020-06-25 13:00:01.435 4838] **** got cache answer for jenson.api.swiftkey.com /  / <unknown> (ID 16368, /root/project/src/dnsmasq/rfc1035.c:1797)
[2020-06-25 13:00:01.435 4838]      Flags: F_FORWARD F_NEG F_IPV6 
[2020-06-25 13:00:01.435 4838] Waiting for lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.435 4838] Obtained lock for _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.435 4838] Removed lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1314)
[2020-06-25 13:00:01.437 4838] Waiting for lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.437 4838] Obtained lock for _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.437 4838] **** new UDP query[AAAA] "jenson.api.swiftkey.com" from ens3:192.168.2.105 (ID 16369, FTL 22497, /root/project/src/dnsmasq/forward.c:1549)
[2020-06-25 13:00:01.437 4838] getOverTimeID(1593083100): 138
[2020-06-25 13:00:01.437 4838] jenson.api.swiftkey.com is known as not to be blocked
[2020-06-25 13:00:01.438 4838] Removed lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:622)
[2020-06-25 13:00:01.439 4838] **** got cache answer for jenson.api.swiftkey.com /  / <unknown> (ID 16369, /root/project/src/dnsmasq/rfc1035.c:1797)
[2020-06-25 13:00:01.439 4838]      Flags: F_FORWARD F_NEG F_IPV6 
[2020-06-25 13:00:01.439 4838] Waiting for lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.439 4838] Obtained lock for _FTL_cache() (/root/project/src/dnsmasq_interface.c:1221)
[2020-06-25 13:00:01.439 4838] Removed lock in _FTL_cache() (/root/project/src/dnsmasq_interface.c:1314)
[2020-06-25 13:00:01.440 4838] B[0012]: 0x558a8bcecf0f, /usr/bin/pihole-FTL(getDatabaseHostname+0x19f) [0x558a8bcecf0f]
[2020-06-25 13:00:01.442 4838] Waiting for lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.442 4838] Obtained lock for _FTL_new_query() (/root/project/src/dnsmasq_interface.c:480)
[2020-06-25 13:00:01.442 4838] **** new UDP query[A] "jenson.api.swiftkey.com" from ens3:fd00::c1a6:8f8e:24f:ff4 (ID 16370, FTL 22498, /root/project/src/dnsmasq/forward.c:1556)
[2020-06-25 13:00:01.442 4838] getOverTimeID(1593083100): 138
[2020-06-25 13:00:01.443 4838] jenson.api.swiftkey.com is known as not to be blocked
[2020-06-25 13:00:01.443 4838] Removed lock in _FTL_new_query() (/root/project/src/dnsmasq_interface.c:622)
[2020-06-25 13:00:01.443 4838] Waiting for lock in _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:709)
[2020-06-25 13:00:01.443 4838] Obtained lock for _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:709)
[2020-06-25 13:00:01.443 4838] **** forwarded jenson.api.swiftkey.com to 9.9.9.9 (ID 16370, /root/project/src/dnsmasq/forward.c:549)
[2020-06-25 13:00:01.443 4838] Removed lock in _FTL_forwarded() (/root/project/src/dnsmasq_interface.c:815)
[2020-06-25 13:00:01.448 4838] B[0013]: 0x558a8bcdc37b, /usr/bin/pihole-FTL(+0x3137b) [0x558a8bcdc37b]
[2020-06-25 13:00:01.451 4838] B[0014]: 0x558a8bcdc55d, /usr/bin/pihole-FTL(resolveClients+0x12d) [0x558a8bcdc55d]
[2020-06-25 13:00:01.455 4838] B[0015]: 0x558a8bcdc88d, /usr/bin/pihole-FTL(DNSclient_thread+0xdd) [0x558a8bcdc88d]
[2020-06-25 13:00:01.460 4838] B[0016]: 0x7febddfd8fa3, /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7febddfd8fa3]
[2020-06-25 13:00:01.460 4838] B[0017]: 0x7febddf094cf, /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7febddf094cf]
[2020-06-25 13:00:01.460 4838] ------ Listing content of directory /dev/shm ------
[2020-06-25 13:00:01.460 4838] File Mode User:Group  Filesize Filename
[2020-06-25 13:00:01.461 4838] rwxrwxrwx root:root 260 .
[2020-06-25 13:00:01.461 4838] rwxr-xr-x root:root 3K ..
[2020-06-25 13:00:01.461 4838] rw------- pihole:pihole 4K FTL-per-client-regex
[2020-06-25 13:00:01.461 4838] rw------- pihole:pihole 33K FTL-dns-cache
[2020-06-25 13:00:01.461 4838] rw------- pihole:pihole 12K FTL-overTime
[2020-06-25 13:00:01.461 4838] rw------- pihole:pihole 2M FTL-queries
[2020-06-25 13:00:01.461 4838] rw------- pihole:pihole 4K FTL-upstreams
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 340K FTL-clients
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 98K FTL-domains
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 57K FTL-strings
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 12 FTL-settings
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 124 FTL-counters
[2020-06-25 13:00:01.462 4838] rw------- pihole:pihole 48 FTL-lock
[2020-06-25 13:00:01.462 4838] ---------------------------------------------------
[2020-06-25 13:00:01.462 4838] Thank you for helping us to improve our FTL engine!
[2020-06-25 13:00:01.462 4838] FTL terminated!

A pihole restardns made everything functional again.

[PromoFaux]

@drwatson

Updating DNS settings failed. Result:

Yep, I think I found where the issue was, and have prepared a fix for this here:

https://github.com/pi-hole/AdminLTE/pull/1472

[DL6ER]

Is it still running? We're currently haunting another issue with incorrect database pointers when a massive number of TCP clients is spawned. The new/mac_client branch may not be fully up-to-date with respect to development so this may have already been fixed.

[drwatson]

Yes, still running since 2 days now. Maybe it was an unrelated glitch. It seems my issues are resolved for now. I will continue using new/mac_client and report new issues.

For now, thank you for your help and excellent work!

[ampfinger]

Hi,
As version 5.1.1 is out and there are some bugs already fixed in development branch, i wanted to ask you to update the branch with latest commits?
Especially updating of DNS settings and conditional forwarding is broken at the moment within this branch.

Thanks for your hard work! I like this project very much and as dual-stack user this branch is very useful (happy wife, happy life )

[Coro]

@ampfinger

happy wife, happy life

@ampfinger

update the branch with latest commits

I second this request.

[DL6ER]

See

RegEx engine improvements

This summarizes everything. FTL v5.1.1 will come sooner than later (maybe even today, maybe Monday, who knows) and once it is out, I will merge everything into the various feature branches floating around. And, finally, they will be marked as ready for merging into development a few days later. Even if they contain some subtle bugs we haven't seen so far, it is more easy to have everything in one place and fix it there. We need to test their (possible) interaction anyway at some point.