I've set it up and it's great on the laptop but the android devices either don't load, partial load or don't have any connection.
Switch back to open dns and everything is fine again.
Anyone got any pointers?
I've set it up and it's great on the laptop but the android devices either don't load, partial load or don't have any connection.
Switch back to open dns and everything is fine again.
Anyone got any pointers?
I see this issue as well. No response in three months? Did you find any solution, Mat?
We must have lost this one somehow... Did you set Pi-hole through the router or manually on your clients? Run pihole -d
for a debug token.
It was through the router on ddwrt.
I gave up to be honest. Nice idea just didn't help
Looks like it's imported from the old forums, which we weren't able to be on top of as much!
I too run android and am not seeing any slowdown issues, curious to find out what the root of your issues were @Mat_Johnson!
I wired my Pi to the router and set the router's DNS to the Pi-hole's IP. I also set the clients' DNS manually, for good measure (perhaps this interferes, though). Google searches and info (e.g. from Maps) seem to be working fine now. I have noticed that a forums app seems to be having difficulty loading imgur links; maybe that should be a new thread, though.
I'm new to pi-hole (installed this week on my synology) and I was experiencing the same issue as the original poster. Browsing on my pc's in my network were lightning fast responses where the DNS requests were handled by pi-hole, but on android devices it would take a very long time for a page to start loading. I suspected a time-out but couldn't find anything when I ran pihole -d except that the log starts with:
::: IP Address Information
::: IPv6 addresses located
::: Pinging default IPv6 gateway: ping: unknown iface
Gateway Responded.
::: Pinging Internet via IPv6: ping: unknown iface
Gateway Responded.
I'm not sure if this is intended behaviour, but I wasn't able to fix this.
Back to the matter at hand, the android devices. I noticed they used IPv6 for queries when being served by pi-hole. So I looked into my fritz.box network settings for IPv6. I had added the IPv6 DNS address for the pi-hole there and checked the checkbox "Also announce DNSv6 server via router advertisement (RFC 5006)" checked.
Unchecking that box solved the issues on my android devices for me.
At first I was worried this meant the android devices wouldn't use pi-hole for DNS requests anymore, but the tail tool for the pihole.log showed me it did.
Happily enjoying fast ad-free browsing on all my devices in network now.
I know it's pretty specific solution for fritz.box devices, but maybe it helps others.
We are investigation. Have you uploaded a debug log?
Could post the output of
ip r
ip -6 r
grep 'IPV4\|IPV6\|INTERFACE' /etc/pihole/setupVars.conf
I have not uploaded my debug log as I was not sure if the output I listed was intentional behavior or not.
However, this is output of the requested commands:
root@Storage:/# ip r
default via 192.168.192.1 dev eth0 src 192.168.192.2
192.168.192.0/24 dev eth0 proto kernel scope link src 192.168.192.2
root@Storage:/# ip -6 r
2001:984:3af3:1::/64 dev eth0 proto kernel metric 256 expires 6630sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::3631:c4ff:fe80:b625 dev eth0 metric 1024
root@Storage:/# grep 'IPV4|IPV6|INTERFACE' /etc/pihole/setupVars.conf
PIHOLE_INTERFACE=eth0
IPV4_ADDRESS=192.168.192.2
IPV6_ADDRESS=2001:984:3af3:1:211:32ff:fe22:d24f
I have my fritz.box as DHCP router with my Synology (storage) as DNS server (ipv4 192.168.192.2 and ipv6 2001:984:3af3:1:211:32ff:fe22:d24f).The synology has 2 network ports, but I have 1 connected (eth0)
Let me know if you need my debug log as well.
FYI, the "Pinging default IPv6 gateway: ping: unknown iface" etc is not in the debug.log but shows as output of pihole -d when running it in a terminal.
I see your default IPv6 route is a link-local address, can you ping IPv6 addresses from your Pi-hole?
ping6 -c 3 2001:4860:4860::8888
Yes, I can.
root@Storage:/# ping6 -c 3 www.google.com
PING www.google.com(ams16s29-in-x04.1e100.net) 56 data bytes
64 bytes from ams16s29-in-x04.1e100.net: icmp_seq=1 ttl=56 time=3.19 ms
64 bytes from ams16s29-in-x04.1e100.net: icmp_seq=2 ttl=56 time=2.20 ms
64 bytes from ams16s29-in-x04.1e100.net: icmp_seq=3 ttl=56 time=2.46 ms
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2048ms
rtt min/avg/max/mdev = 2.203/2.619/3.194/0.423 ms
root@Storage:/# ping6 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=56 time=6.24 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=56 time=5.53 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=56 time=5.66 ms
--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 5.536/5.815/6.242/0.306 ms
Thank you so much for figuring this out.
I can confirm that disabling RFC 5006 fixes the performance flaws of Android devices in the network.
You're welcome! Glad it helped someone else beyond me!
Would be interesting to know what the RA packages look like that are sent by the fritz box. If anyone would like to try that out, I'd appreciate that. If you use e.g. wireshark
you can use the following filter to see only ICMPv6 RA packets:
icmpv6.type==134
By the way, I did not solve this issue. Benjiir did
Yep, that's better.
I'm not familiar with Wireshark or networking, but I ran it for you.
Got 5 packets from the filter from turning RFC 5006 on and back off again. What I see is that the RFC 5006 packets have a length of 166 and without 144.
Hope this output helps. Lemme know if you need anything else or how I should export the data.
41716 191.729741 fe80::3631:c4ff:fe80:b625 ff02::1 ICMPv6 142 Router Advertisement from 34:31:c4:80:b6:25
41895 192.560649 fe80::3631:c4ff:fe80:b625 ff02::1 ICMPv6 166 Router Advertisement from 34:31:c4:80:b6:25
46759 214.714213 fe80::3631:c4ff:fe80:b625 ff02::1 ICMPv6 166 Router Advertisement from 34:31:c4:80:b6:25
134796 626.204757 fe80::3631:c4ff:fe80:b625 ff02::1 ICMPv6 166 Router Advertisement from 34:31:c4:80:b6:25
134977 627.030458 fe80::3631:c4ff:fe80:b625 ff02::1 ICMPv6 142 Router Advertisement from 34:31:c4:80:b6:25
41716:
0000 33 33 00 00 00 01 34 31 c4 80 b6 25 86 dd 60 00 33....41...%..`.
0010 00 00 00 58 3a ff fe 80 00 00 00 00 00 00 36 31 ...X:.........61
0020 c4 ff fe 80 b6 25 ff 02 00 00 00 00 00 00 00 00 .....%..........
0030 00 00 00 00 00 01 86 00 66 20 ff 40 07 08 00 00 ........f .@....
0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 20 00 00 ........@.... ..
0050 0e 10 00 00 00 00 20 01 09 84 3a f3 00 01 00 00 ...... ...:.....
0060 00 00 00 00 00 00 05 01 00 00 00 00 05 d4 18 01 ................
0070 00 00 00 00 07 08 18 02 30 00 00 00 07 08 20 01 ........0..... .
0080 09 84 3a f3 00 00 01 01 34 31 c4 80 b6 25 ..:.....41...%
41895:
0000 33 33 00 00 00 01 34 31 c4 80 b6 25 86 dd 60 00 33....41...%..`.
0010 00 00 00 70 3a ff fe 80 00 00 00 00 00 00 36 31 ...p:.........61
0020 c4 ff fe 80 b6 25 ff 02 00 00 00 00 00 00 00 00 .....%..........
0030 00 00 00 00 00 01 86 00 9d 99 ff 40 07 08 00 00 ...........@....
0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 1f 00 00 ........@.......
0050 0e 10 00 00 00 00 20 01 09 84 3a f3 00 01 00 00 ...... ...:.....
0060 00 00 00 00 00 00 19 03 40 c0 00 00 04 b0 20 01 ........@..... .
0070 09 84 3a f3 00 01 02 11 32 ff fe 22 d2 4f 05 01 ..:.....2..".O..
0080 00 00 00 00 05 d4 18 01 00 00 00 00 07 08 18 02 ................
0090 30 00 00 00 07 08 20 01 09 84 3a f3 00 00 01 01 0..... ...:.....
00a0 34 31 c4 80 b6 25 41...%
46759:
0000 33 33 00 00 00 01 34 31 c4 80 b6 25 86 dd 60 00 33....41...%..`.
0010 00 00 00 70 3a ff fe 80 00 00 00 00 00 00 36 31 ...p:.........61
0020 c4 ff fe 80 b6 25 ff 02 00 00 00 00 00 00 00 00 .....%..........
0030 00 00 00 00 00 01 86 00 9d af ff 40 07 08 00 00 ...........@....
0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 09 00 00 ........@.......
0050 0e 10 00 00 00 00 20 01 09 84 3a f3 00 01 00 00 ...... ...:.....
0060 00 00 00 00 00 00 19 03 40 c0 00 00 04 b0 20 01 ........@..... .
0070 09 84 3a f3 00 01 02 11 32 ff fe 22 d2 4f 05 01 ..:.....2..".O..
0080 00 00 00 00 05 d4 18 01 00 00 00 00 07 08 18 02 ................
0090 30 00 00 00 07 08 20 01 09 84 3a f3 00 00 01 01 0..... ...:.....
00a0 34 31 c4 80 b6 25 41...%
134796:
0000 33 33 00 00 00 01 34 31 c4 80 b6 25 86 dd 60 00 33....41...%..`.
0010 00 00 00 70 3a ff fe 80 00 00 00 00 00 00 36 31 ...p:.........61
0020 c4 ff fe 80 b6 25 ff 02 00 00 00 00 00 00 00 00 .....%..........
0030 00 00 00 00 00 01 86 00 9d 98 ff 40 07 08 00 00 ...........@....
0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 20 00 00 ........@.... ..
0050 0e 10 00 00 00 00 20 01 09 84 3a f3 00 01 00 00 ...... ...:.....
0060 00 00 00 00 00 00 19 03 40 c0 00 00 04 b0 20 01 ........@..... .
0070 09 84 3a f3 00 01 02 11 32 ff fe 22 d2 4f 05 01 ..:.....2..".O..
0080 00 00 00 00 05 d4 18 01 00 00 00 00 07 08 18 02 ................
0090 30 00 00 00 07 08 20 01 09 84 3a f3 00 00 01 01 0..... ...:.....
00a0 34 31 c4 80 b6 25 41...%
134977:
0000 33 33 00 00 00 01 34 31 c4 80 b6 25 86 dd 60 00 33....41...%..`.
0010 00 00 00 58 3a ff fe 80 00 00 00 00 00 00 36 31 ...X:.........61
0020 c4 ff fe 80 b6 25 ff 02 00 00 00 00 00 00 00 00 .....%..........
0030 00 00 00 00 00 01 86 00 66 21 ff 40 07 08 00 00 ........f!.@....
0040 00 00 00 00 00 00 03 04 40 c0 00 00 1c 1f 00 00 ........@.......
0050 0e 10 00 00 00 00 20 01 09 84 3a f3 00 01 00 00 ...... ...:.....
0060 00 00 00 00 00 00 05 01 00 00 00 00 05 d4 18 01 ................
0070 00 00 00 00 07 08 18 02 30 00 00 00 07 08 20 01 ........0..... .
0080 09 84 3a f3 00 00 01 01 34 31 c4 80 b6 25 ..:.....41...%
Thanks. That worked well, it seems, but those outputs are rather hard to parse for a human Could you make some screenshots showing the interpreted content?
Like this one (captured on my network):
The highlighted line is the one which tells my devices the address of my Pi-hole (but I'm also using the Pi-hole DHCP server). What you can already see (in the very first line), my packets are 144 bytes long as yours with disabled option.
Hope this parses better:
144 bytes:
166 bytes (RFC 5006):
Yes, Thank you. However, that is quite strange, since for you the version that does not contain the Recursive DNS Server
info works better
In contrast, I have found that for me only the version with this makes the DNS server also work with IPv6.
Your configuration simply lets the IPv6 server unspecified and the Android devices will only use the IPv4 address of your Pi-hole to get both, IPv4 and IPv6 query answers - which is perfectly fine by the way!
Maybe it's related to the android version (5.0.2) which is a bit older and uses a different IPV6 to IPV4 implementation from what I'm reading than 5.1+ versions. And maybe it's something in the FritzBox.
Either way, disabling RFC 5006 makes pi-hole run perfectly on my network, so I'm happy.