Netgear C7800 Firmware V3.01.36 and Pihole not working properly

charle1776 · February 20, 2020, 2:14pm

Expected Behaviour:

Use Pi DNS as only DNS in router, block all ads. OR Turn off DHCP in router, turn on DHCP in Pi to block adds for all devices connected to router.

Actual Behaviour:

DNS

When I make the Pi the only DNS on the router all internet stops working. I have come to the conclusion that this is some type of setting on the router causing this. The Netgear C7800 is a router/modem combo, which lacks settings and customization. I believe one suggestion to remedy this problem is to turn off DNS rebinding. There is no such option, and I have looked thoroughly. I will not be buying a combo again. I have given up on this option and moved on to DHCP only.

DHCP

What is working: All connected LAN devices. (Linux, Samsung TV, Windows)

What's not working: All devices connected via Wifi. (Macbook, Linux laptop, Android)

What I've tried: Resetting the router and changing the router IP (gateway) and disabling DHCP on the router before any devices were connected besides the RPi with a fresh install of Raspbian and Pihole.

Dilemma: All devices are getting DHCP leases from RPi, and DNS of those devices is showing as RPi, but the Wifi connected devices fail to block ads or show as connected to the RPi on the Network tab

Final Edit: No solution found, and I would not recommend this device to anyone who wants to use a Pihole with it. Maybe this will change in the future, but as it stands there is no known solution. Good luck.

Bucking_Horn · February 20, 2020, 2:57pm

Can you configure Pi-hole as your router's upstream DNS server (likely a WAN/Internet setting), local DNS server (likely a DHCP setting) or both?

Setting Pi-hole as local DNS server would be the preferred way.

Also, a quick search of these forums here revealed that some Netgear devices' firmware stubbornly refuses to work with custom DNS settings, though the UI clearly allows for it.

Some users got lucky reverting to some older firmware, e.g. Setup on Netgear X4S Router (R7800).

Those latter devices seem to bypass Pi-hole.
As they correctly register with Pi-hole's DHCP, they may be using IPv6 to employ a different DNS server altogether.
Note that DHCP is different from DHCPv6 - IPv6 clients cannot be forced to request DNS servers through Pi-hole's DHCP exclusively.
In fact, IPv6 clients may choose to integrate into your network by a method of their own preference (Stateful vs. Stateless DHCPv6 vs. SLAAC).

To confirm this, try disabling IPv6 on your router.

charle1776 · February 20, 2020, 3:18pm

You are correct the UI allows the user to change the DNS, but the router refuses to connect to the internet after doing so. Unfortunately, because the router is a modem combo the firmware is pushed out by the ISP. As far as I know, there is no way for me to alter the firmware. However, I could be wrong. Nothing I have done allows the Pi to be the DNS directly on the router.

IPv6 is disabled on my router, so I do not believe this to be the case.

EDIT:
After doubling checking IPv6, I am now unsure if it is disabled. The router setting is in a screenshot below. None of the buttons are clickable or options changeable.

This router is a joke. I will be sticking to routers with more accessible firmware in the future.

EDIT2: I went to Pihole DHCP settings and turned on IPv6. Still no luck.

Bucking_Horn · February 20, 2020, 11:32pm

I can only guess here, since I am not at all familiar with that router.
It doesn't seem like you have IPv6 support in your network - I'd assume that your ISP would assign a prefix for you to use, but the only entry hinting at this in your screenshot reads 'Not Available', and it may or may not relate to your ISP's assignment.

Would you be able to confirm through other sources that your ISP provides IPv6 connectivity at all?

Another way your clients could bypass Pi-hole would be if they had access to mobile network services. At least your Android smartphones could have access to that.
Verify that they have mobile data access switched off.

You also described that you have verified that your WiFi devices have been correctly assigned Pi-hole as DNS server.
Let's check whether your devices do honor this:
From your Linux laptop, what is the output of

nslookup flurry.com

charle1776 · February 21, 2020, 2:35am

Thanks for your respone.

When I checked on the Android I disabled data, and I was only connected to the wifi during the test.

I will call my ISP tomorrow to verify regarding the IPv6, but I believe the screenshot below might answer this quesiton.
Screenshot_20200220_193244

The results of nslookup are below:

Server is the Pi

Bucking_Horn · February 21, 2020, 8:22am

It just means that clients are sending IPv6 queries to your Pi-hole, not that you have upstream IPv6 connectivity (which would be necessary for a device to bypass Pi-hole by using a public DNS server via IPv6). In fact, my graph looks quite similar, though I can confirm IPv6 as unavailable.

But meanwhile, the results of your nslookup should have been 0.0.0.0 - blocked by Pi-hole. This provides us with a different possible cause.

As your Pi-hole machine is living at 192.168.1.251, your client is using the right machine, but the DNS requests are not being filtered.

On your RPi running Pi-hole, let's have a look at your configured nameservers:

cat /etc/resolv.conf

P.S.: (click for more)

Please consider posting the textual output of commands.
It might be necessary to reenact or reuse some of it, and that is easier to do for both me and other potential readers with living text instead of a "dead" screenshot.

You can paste your output here and format it, either by prefixing it with a > or, even better, by selecting a text passage and applying the </> option from the menu

charle1776 · February 22, 2020, 12:49am

Bucking_Horn:

But meanwhile, the results of your nslookup should have been 0.0.0.0 - blocked by Pi-hole. This provides us with a different possible cause.

As your Pi-hole machine is living at 192.168.1.251, your client is using the right machine, but the DNS requests are not being filtered.

On your RPi running Pi-hole, let's have a look at your configured nameservers:
cat /etc/resolv.conf
P.S.: (click for more)

Please consider posting the textual output of commands.
It might be necessary to reenact or reuse some of it, and that is easier to do for both me and other potential readers with living text instead of a "dead" screenshot.

You can paste your output here and format it, either by prefixing it with a > or, even better, by selecting a text passage and applying the </> option from the menu

I'll edit the pic when I have time show as text. The results of cat /etc/resolv.conf are below:

pi@raspberrypi:~ $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

I have tried editing the resolv.conf with sudo nano /etc/resolv.conf in the past, but my changes never seem to be saved.

Bucking_Horn · February 22, 2020, 4:28pm

That is the correct entry, as Pi-hole is running as DNS server on that machine (i.e. localhost).
If we'd seen an additional nameserver in there, it could have been used instead of Pi-hole. We do not, so everything OK in /etc/resolv.conf.

Let's run the following command on your Pi-hole machine to check some of Pi-hole's stats:

echo ">stats" | nc localhost 4711 -w 1

and also to check clients:

echo ">top-clients" | nc localhost 4711 -w 1

P.S.: (click for more)

No need to revise your screenshots, just consider it for future posts, like you already did - thank you

(It's also a bit easier to redact sensitive info from texts by altering or deleting corresponding parts.)

charle1776 · February 24, 2020, 2:24am

Results are below:

echo ">stats" | nc localhost 4711 -w 1
domains_being_blocked 1029922
dns_queries_today 600
ads_blocked_today 139
ads_percentage_today 23.166666
unique_domains 1700
queries_forwarded 317
queries_cached 144
clients_ever_seen 4
unique_clients 3
dns_queries_all_types 600
reply_NODATA 31
reply_NXDOMAIN 40
reply_CNAME 179
reply_IP 266
privacy_level 0
status enabled
---EOM---

echo ">top-clients" | nc localhost 4711 -w 1
0 253 192.168.1.235 
1 203 127.0.0.1 localhost
2 150 192.168.1.233 
---EOM---

Tripp_cmd · February 24, 2020, 5:06am

I have this exact c7800 with CoX and having a lot of trouble. I know 1% of what you know about these things but my friend who does this stuff for a living abroad tried helping me and said he had never seen a router so hard to deal with and set pi hole up with. What i ended up doing today was de activating DHCP in the c7800 and activating it in the Pi-hole console and then making the range of IP's meet the devices i have. And manually setting each device DNS with the Pi IP.

What did work from doing that is i was actually finally able to see all 9 devices in the network section of the pi-hole console (pc, laptop, 2 mobiles, pi, google home and mini's). What hasn't worked yet is adds being removed from things like browser and some games i have on my phone.

To bet honest i never know what to think. Watch a video like Linus tech tips and he gets adds taken off youtube videos and every device in his life with in 10 minutes and i spend 2 days still looking at ads here and there lol. I will watch your post because like i said i couldn't find any posts about how to get this thing to work with that garbage c7800. I have a feeling I am not setup nearly to what i need to be.

Bucking_Horn · February 24, 2020, 10:53am

This shows that Pi-hole is working alright, but currently only 2 clients (plus Pi-hole itself) are using your Pi-hole for DNS. (I am a bit surprised that top clients (apart from Pi-hole, shown as localhost) are only listed by IP address, but that does not provide cause for trouble in itself re your current issue.)

I assume that .235 and .233 are your LAN-connected Linux and Windows machine, while your TV was switched off. So it would seem none of your WiFi clients ever registered with a DNS query on your Pi-hole (just as you described).
Which makes me scratching my head, as we did verify that your WiFi Linux laptop is using your Pi-hole's IP .251 for DNS. We also verified that your Pi-hole machine uses itself as DNS by checking /etc/resolv.conf, ensuring that Pi-hole isn't by-passed locally.

Let's see how a LAN client compares directly to a WiFi client when using the exact same set of two nslookups as follows:
a) for using the default DNS (i.e. Pi-hole at 192.168.1.251)

nslookup flurry.com

b) for forcing lookup through a specific public DNS (80.241.218.68)

nslookup flurry.com 80.241.218.68

Could you please execute both nslookup commands on
I. a LAN-connected machine
II. your WiFi-connected Linux laptop
III. (optional) on your Linux laptop, after disabling WiFi and connecting your Linux latop by LAN cable
and post the results?

charle1776 · February 24, 2020, 9:08pm

Linux Desktop LAN:

$ nslookup flurry.com
Server:         192.168.1.251
Address:        192.168.1.251#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::

$ nslookup flurry.com 80.241.218.68
Server:         80.241.218.68
Address:        80.241.218.68#53

Non-authoritative answer:
Name:   flurry.com
Address: 74.6.136.153
Name:   flurry.com
Address: 212.82.100.153
Name:   flurry.com
Address: 98.136.103.26

Linux Laptop Wifi

$ nslookup flurry.com
Server:         192.168.1.251
Address:        192.168.1.251#53

Non-authoritative answer:
Name:   flurry.com
Address: 212.82.100.153
Name:   flurry.com
Address: 74.6.136.153
Name:   flurry.com
Address: 98.136.103.26

$ nslookup flurry.com 80.241.218.68
Server:         80.241.218.68
Address:        80.241.218.68#53

Non-authoritative answer:
Name:   flurry.com
Address: 98.136.103.26
Name:   flurry.com
Address: 74.6.136.153
Name:   flurry.com
Address: 212.82.100.153

Linux Laptop LAN (Wifi disabled):

$ nslookup flurry.com
Server:         192.168.1.251
Address:        192.168.1.251#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::

$ nslookup flurry.com 80.241.218.68
Server:         80.241.218.68
Address:        80.241.218.68#53

Non-authoritative answer:
Name:   flurry.com
Address: 98.136.103.26
Name:   flurry.com
Address: 212.82.100.153
Name:   flurry.com
Address: 74.6.136.153

Interesting results as I see the laptop went through the pihole when connected via ethernet. I don't know enough about this to determine what the cause of the problem is.

Bucking_Horn · February 25, 2020, 8:54am

I can, and I fear you are not going to like this.

The expected outcome for this would have been a consistent `0.0.0.0` (click for my details)

through local DNS, i.e. Pi-hole

~ $ nslookup flurry.com 
Server:         192.168.0.254
Address:        192.168.0.254#53

Name:   flurry.com
Address: 0.0.0.0

through public filtering DNS

~ $ nslookup flurry.com 80.241.218.68
Server:         80.241.218.68
Address:        80.241.218.68#53

Name:   flurry.com
Address: 0.0.0.0

through public DNS

~ $ nslookup flurry.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   flurry.com
Address: 98.136.103.26
Name:   flurry.com
Address: 74.6.136.153
Name:   flurry.com
Address: 212.82.100.153

tl;dr: Your router is redirecting all public facing DNS traffic to a DNS server of its choice, and it is also wrongly redirecting local DNS traffic for WiFi connections. (click for long version)

I deliberately chose a public filtering DNS server (fdns1.dismail.de / 80.241.218.68) I know to block flurry.com, as it applies the same matching blocklist as Pi-hole (i.e. http://sysctl.org/cameleon/hosts).

So when an nslookup flurry.com 80.241.218.68 provides an actual IP for flurry.com, it indeed has not gone through 80.241.218.68.
(Theoretically, fdns1.dismail.de could provide region-specific blocking based on the requesters IP's geo-location, but I am not aware it does so, and this finding is in line with all of your observations.)

What we are seeing is the result of something (supposedly, your router) redirecting DNS traffic (port 53) to some public DNS server.

This indiscriminately applies to all DNS traffic destined for a public IP (as all lookups through 80.241.218.68 failed consistently), so your router is definitely redirecting your public facing DNS.

However, while local DNS traffic seems to be correctly exempted for LAN, we just confirmed that WiFi-connected local DNS traffic is redirected also (as proven by your laptop's lookup through Pi-hole).

If you are not running a separate WiFi device (e.g. an access point) that may come with its own, misconfigured DNS settings, then again your router is the cause.

I am afraid that if your router does not expose any configuration option to change this, your WiFi devices will always be forced to use the DNS server your router is using, at least with its current firmware.

EDIT: You may want to reverify if you can revert your router to another firmware, as linked above (click on up arrow 'go to the quoted post' below):

EDIT-2: For the sake of other users with similar experiences, I think it would be beneficial if you'd be able to provide your router's exact current firmware version, either in your initial description or in your topic's title. Thank you for considering

Tripp_cmd · February 25, 2020, 4:25pm

I have the same Netgear C7800 router and my firmware version is 3.01.38 so i guess a little newer than his .36 version. And i have the same issues. I read that post you linked about older version. But how do you even change the firmware? I don't see anything related to it in settings for even updates. Doing a duck search says the ISP updates the firmware. So how would i know which to revert to and if i found one how would i do it if CoX is the one that controls it?

I wish there was a list of routers that work great with Pi from different IP's. On the CoX website for gigabit internet they have a list of compatible router/modem combos and there are maybe 10 on the list. I chose this one. But Is there something specific we should look at when buying one to use with a Pi that will be less hassle. A specific spec or available option the router provides that we need? None of the developers got a chance to look at my token i posted yesterday but after doing all my research it seems this c7800 is just not compatible with Pi.

charle1776 · February 26, 2020, 7:07pm

Title updated. Thank you very much for your assistance throughout this. I will call my ISP when I have the chance and see if there is any way to downgrade the firmware and attempt again. If not, I will be leaving this thread as is.

While not the best news, 90 percent of my traffic is done through LAN, so I will accept the result as somewhat of a success. However, for others with the same router/modem I imagine this will be tragic news.

I have also read that the firmware is pushed out by the ISP for the combo. I am going to call my ISP to see if there is any way to upgrade/downgrade.

Personally, I will not be buying a combo in the future. I liked the idea, but I will be purchasing a modem on its own that is good for high speeds, and a separate router that works with high speeds and allows more customization on the firmware. To expand, there are open source firmwares like DD-WRT that work with specific routers. I will likely be looking at their list of compatible routers and choose one from there as I am a fan of FOSS.

RamSet · February 26, 2020, 7:20pm

I have 2 Netgear devices. An R8000 and an R9000.

BOTH, are working properly when setting up the DNS under the WAN port to my Pi-hole IPs.

Here is a screenshot:

You need to set Pi-hole to listen to all, permit all origins under the settings.

You should disable IPV6 as that might override your IPV4 DNS settings.

If that does not work, there is a different approach we can look into but it's a little bit more complex and ... weird

Your ISP will not provide you any previous firmware and even if you find it online, flashing that, might not be the best approach

DanSchaper · February 26, 2020, 7:36pm

charle1776 · February 26, 2020, 7:38pm

I do not see the same options as RamSet.

RamSet · February 26, 2020, 7:43pm

DNS1,2 and 3 ... you are in the right place

Just make sure it's Use these DNS servers.

And point them to the IP of Pi-hole.

charle1776 · February 26, 2020, 7:46pm

Pardon my initial confusion. I described in my first post that when I do this all devices lose internet connection which is why I opted for the DHCP route to bypass this issue.