D7000 Recent dnrd issues : workaround found

[Geords71]

Hi,

I 've got a first gen d7000 router and recently it's been hanging quite regularly at least once a day.

After some googling I noticed that you can get a rescue version of the firmware with telnet access.

After installing that and telnetting in, it was easy to get the router going again by restarting dnrd e.g.

/usr/sbin/rc dnrd restart

But that didn't explain why dnrd was hanging

An lsof showed a *ton* of CLOSE_WAIT connections against that process but only from a couple of windows laptops. I suspect these were stacking up to the dnrd limit - and at that point dnrd was becoming unresponsive.

Using this powershell  snippet on the laptops themselves, I traced the close_wait to chrome in both cases (where XXX is the port number listed after the ip address in the *router's* lsof output):

Get-Process -Id (Get-NetTCPConnection -LocalPort XXXX).OwningProcess

It was chrome in both instances. I made the following change only to chrome's security settings and the hanging close_waits have all disappeared:

Three Dots -> Settings -> Privacy and Security -> Security  -> Use Secure DNS -> With Google (Public DNS)

So perhaps the D700 is struggling with those secure dns lookup requests? In any case this workaround has resolved my dnrd issue, so I'm sharing it in case others have also started experiencing this recently and - like me - don't want to have to set up their devices to use public dns servers at the connection level. 

[michaelkenward]

---

@Geords71 wrote:

Hi,

I 've got a first gen d7000 router and recently it's been hanging quite regularly at least once a day.

The D7000 is a DSL modem/router combination. Is that how you are using it, or just as a router?

What happens when it hangs? What do the LEDs on the front look like? Does the DSL signal die?

Is it wfi that hangs or Ethernet connections?

---

After some googling I noticed that you can get a rescue version of the firmware with telnet access.

I don't know what you read, or what you mean by "a rescue version of the firmware", but the usual way to recover a dying device is with TFTP. Then you can take your pick from the Netgear library of firmware for your device

But that is only really needed when you have broken firmware. That is evident when the power LED misbehaves. (Hence the previous question about your LEDs.) If the firmware is not bust then the usual, and safer, way to write firmware is with a manual upload.

If you are talking about third party firmware, then this isn't the place to find experts.That's best done over where they support that stuff.

Rather than diving into exotic command-line gymnastics, have you been through the usual troubleshooting process?

[Geords71]

When router hangs, the issue is that the router can no longer serve up dns requests. No other aspect of the router's functionality is affected.

I used the ancistrus version of the firmware to diagnose the issue . i.e. purely just so I could gain telnet access. Under both this and the stock firmware, the symptoms are the same:

https://negan07.github.io/ancistrus/tools/ancistrus-arm-D7000/D7000-V1.0.1.84_1.0.1_rescue.zip

The process on the router which handles dns requests is called dnrd. Restarting this dnrd process fixes the issue. No other action is required - and the router then operates as normal once this has been done.

As to why the dnrd process is hanging - running the lsof command in a telnet session showed a whole slew of hanging connections from two laptops on my network. By default, I think dnrd may only serve 200 concurrent requests?

https://dnrd.sourceforge.net/docs.php

An  'lsof' command on the router (via telnet) lists the open port on the laptop that made the hanging connection to dnrd. So you can back-trace the application that was making the stalled dns lookup by running a powershell command on the laptops directly (looking for the process that has this port open). Curiously this was chrome in both instances - so something about how chrome was making it's dns requests to the router was causing issues. The laptops were windows 10 and windows 11 and running with standard dhcp windows wireless connections.

So, as far as I can tell, the router's dnrd process is coping badly with certain dns lookups made from Chrome on windows. Changing the secure dns lookup setting in chrome on these two laptops has solved the issue for me. I will re-install stock firmware to confirm that it also works around the issue with this.