@archp wrote: This is what the netgear engineer said:
We have identified that the traffic meter will cause problem while auto daylight saving time enabled. Since you turn off auto daylight saving time, the issue should be go away. Turn off traffic meter would also avoid the issue. We are working on a trial fix firmware. Will provide to you once it’s ready. Thanks.
@archp wrote: Maybe he meant a beta firmware to test before they release an official one? That's literally all that was said.
Thanks
That's what appears to be happening when they decide to put the newest and greatest firmware update on the server for all to use. Then here comes the 'I gotta it have bunch', who in turn become our beta testers.
A long-term fix for devices that absolutely need access is to explicitly set them to use DNS other than through the router-as-relay. I.e., set the DNS on your laptop, phone, whatever to something other than 192.1.6.1.1 (as provided by the DHCP of the RBR50 router).
It is possible to set the RBR50 DHCP to provide that information, but not to ensure the configuration is persistent across reboots (it would be nice if that were a configuration option, though!)
A long-term fix for devices that absolutely need access is to explicitly set them to use DNS other than through the router-as-relay. I.e., set the DNS on your laptop, phone, whatever to something other than 192.1.6.1.1 (as provided by the DHCP of the RBR50 router).
It is possible to set the RBR50 DHCP to provide that information, but not to ensure the configuration is persistent across reboots (it would be nice if that were a configuration option, though!)
Same issues as I see many others have in the community. The Orbi network seems to be working and I have internet connectivity on some devices and not on others. For instance, my computer and Rokus work but cell phones say there is no connection to the internet. Sometimes just the Rokus will work and the computers will have the same no internet message as the cell phones. This makes no sense to me. I have rebooted the main and satellites several times.
IPv6 DNS entries appear to be not working correctly.
If I leave the configuration to "get automatically from ISP", then there is no entry in /tmp/resolv.conf (i.e., no override).
If I put in a DNS entry "use these DNS servers", then the entry in /tmp/resolv.conf is NOT what I entered - it is the value the router gets from my ISP.
I don't know if this is related to the overall DNS problems we've all been seeing.
PS - ROKUs may work (some apps at least) because they have hard-wired IP addresses for DNS servers in the public Internet (e.g., Google 8.8.8.8).
Laptops, phones, and pads typically take the DNS info from their DHCP response and use that; the Orbi always tells them to use the Orbi as the DNS server (192.168.1.1). That works fine until dnsmasq crashes and fails to restart, at which point the Orbi no longer does DNS caching relay or DHCP.
You CAN login and restart dnsmasq. You can setup a cron job to do that automatically, at least until the system reboots (it loses that state). You can also reboot, which will start dnsmasq again.
I also wanted to say that while the advice Furry38 gave on doing a factory reset is a semi-valid solution, it is not a practial one in this case. That would be like saying if my car had a flat tire, I should trade it in and buy a new one. People come to this board looking for real help and viable solutions. And as it turns out, those who did a factory reset would still face this issue if they did a config backup/restore. And as we all see now, a simple workaround is to disable Traffic Metering which is what we all came here for.
FYI - the only reason a "factory reset" works is because most users did that reset and DID NOT turn logging back on. That's why it sometimes works and sometimes doesn't.
I'll summarize as follows: do any of the following:
disable traffic logging
disable automatic DST for NTP (typically by setting your time zone one zone east, i.e., setting the clock for US mountain standard time if you live in US pacific daylight time
Netgear is aware of this issue. You CAN also edit the DHCP configuration file, but its contents in /tmp are rewritten each reboot. You have to edit the print statements in /etc/init.d/net-lan instead. Set the "option dns" to use whatever IP address you want instead of using the router's LAN address (I might end up doing this anyway - it gets around the fact that Netgear's API doesn't allow users to configure this directly).
FYI, the logging has been showing zeroes; if you use the second trick, apparently all the past logs are recovered and show up too. The downside of the second trick is that you have to change it when the time changes again, but that won't be for 8 months...
On mine I have DST enabled and TM disabled as I don't use TM ever. So may have been one reason why I didn't see any issues on my RBK50 using v104. However I did see 3 DNS errors on my Orbi AX system, DST was disabled and TM not used. After enabling DST on the Orbi AX system, which I though I had alredy enabled, I have not see any DNS errors since. I presume there is some forum of mishandling of Traffic Meter/DST/NTP/DNS when the time change starts happening at these two times here in the US region. Something I hope NG will finally get fixed.
The downgrading of FW may have fixed it for some however I presume since the time changed even had already taken place, that if they were on the downgraded version of FM using DST/TM or not, would have probably seen this problem anyways. I presume that the use of DST and or TM now, since the time change even has past, there should be any more problems seen on any version of FW. Until next time change comes later this year.
The downgrading of FW may have fixed it for some however I presume since the time changed even had already taken place, that if they were on the downgraded version of FM using DST/TM or not, would have probably seen this problem anyways. I presume that the use of DST and or TM now, since the time change even has past, there should be any more problems seen on any version of FW. Until next time change comes later this year.
FYI - dnsmasq in V2.7.2.104 is 2.80; the updates to other firmware that mentions dnsmasq are over 2 yrs old (Jan 2019) and mention dnsmask 2.78.
It's interesting that the issue appears to kill the dnsmasq process but happens only when TM logging is active. The former suggests a bug in dnsmasq, the latter with TM - in either case, triggered by some date format error.
I agree, something between the DNS and TM is causing problems. However I didn't have TM enabled on my RBR50, only DST was enabled. Have not seen any issues with that configuration. Ya, it's something NG seems aware about and hopefully will fix.
FYI - dnsmasq in V2.7.2.104 is 2.80; the updates to other firmware that mentions dnsmasq are over 2 yrs old (Jan 2019) and mention dnsmask 2.78.
Per the reports cited (dated Jan 2021):
The flaws are patched in dnsmasq version 2.83, which will be released Tuesday, January 19, and will be available in the repositories of most Linux distributions.
Vulnerable versions, devices, and mitigation advice
The researchers confirmed that Dnsmasq versions 2.78 to 2.82 are all affected by the vulnerabilities. Whether a device/system is affected or not (or just partially) also depends on how it uses Dnsmasq.
They found that some Cisco VPN routers are affected by the DNS cache poisoning vulnerabilities, and so is the OpenWRT firmware available for hundreds of devices and models.
Devices that do not use Dnsmasq’s caching feature will be much less affected (but not completely immune) to cache poisoning attacks, Oberman told Help Net Security. Devices that don’t use the DNSSEC feature will be immune to the buffer overflow attacks
“DNSSEC is a security feature meant to prevent cache poisoning attacks and so we would not recommend turning it off, but rather updating to the newest version of Dnsmasq (v2.83),” he added.
That report is yet another security vulnerability patch. Nearly every version of dnsmasq has a similar patch note.
However, nothing in that note correlates with the interactions we see with NTP+DST and TM. If the vulnerabilities alone were the issue, disabling one of DST or TM would not provide relief - yet it does.
At this point, it's not clear that merely updating to dnsmasq 2.83 would help. AFAICT we're still waiting to hear what the root cause might be.
If you look at my past post, I never represented that it was THE issue - just a POTENTIAL issue, since the EXACT issue is really not known. Additionally, not all individuals experiencing the issue has the specific combination of settings being attributed to problem.
