Re: Nighthawk D7000 2.4Ghz WiFi issues

Kiwito · ‎2018-01-13

Hi there,
Finally I went to the shop and I returned the router/mother. It wasn't under warranty 1 month expired, but the seller was aware of the issue and allow me to return the D7000. Good luck and if you have the chance, return it!

IT9MBZ · ‎2018-01-13

@Case850 wrote:
@IT9MBZ
Can you post a log of what you have since the crash?

Just another 5GHz crash!
To recovery, I clicked on "Apply" tab in the WiFI configuration web page of the modem, without any modify.

@Case850

I filtered the log unchecking all the tabs, leaving flagged the "Wireless acces" tab only. No items showed.

Lot of items are concerning "Port Forwarding / Port Triggering" filter, that showing many external connections to LAN devices such as NAS and IPCam where are enabled P2P services, DDNS and other.

Which part of log are you interessed?

IT9MBZ · ‎2018-01-13

Less than one hour ago, about an half hour after the 5GHz crash, the 2.4GHz dropped out all the devices connected.

I'm really bored about this continuous resetting the modem.

I'm going to remove the D7000 from my network, and sobstitute it with a Mikrotik hAP Lite. More cheaper, more reliable, more flexible and more.

I will keep in touch with this discussion, waiting for the real solution at this issue.

IT9MBZ · ‎2018-01-13

@Case850 wrote:
@IT9MBZ
Not a good idea to filter the log file. All devices need to be accountable. You could have a virus or malware on your NAS that is sending out unnecessary packets.

@Case850

I don't think so. My NAS have the antivirus service (it' a QNap).
And more, the items of log report tell the che connection trying come from remote.

Anyway, here is the log after restart.

[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:32
[UPnP set event:AddPortMapping] from source 192.168.0.221 Saturday, January 13,2018 14:27:32
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:56071 Saturday, January 13,2018 14:27:13
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:09
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:08
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:07
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:05
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:04
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:02
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 74.207.241.132:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 176.58.96.231:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:55

192.168.0.121 and 192.168.0.124 are IPCams

192.168.0.30 is NAS

richardw001 · ‎2018-01-13

@IT9MBZ wrote:
@Case850 wrote:
@IT9MBZ
Not a good idea to filter the log file. All devices need to be accountable. You could have a virus or malware on your NAS that is sending out unnecessary packets.
@Case850

I don't think so. My NAS have the antivirus service (it' a QNap).
And more, the items of log report tell the che connection trying come from remote.

Anyway, here is the log after restart.
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:32
[UPnP set event:AddPortMapping] from source 192.168.0.221 Saturday, January 13,2018 14:27:32
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:56071 Saturday, January 13,2018 14:27:13
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:09
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:08
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:07
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:05
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:04
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:02
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 74.207.241.132:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 176.58.96.231:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:55

192.168.0.121 and 192.168.0.124 are IPCams
192.168.0.30 is NAS

Is this on 1.58 ? - I've created a new discussion thread -for 1.58 - as between people that are newly landing here because of problems with the current official firmware an people trialing the new firmware its hard to see (at least for me 🙂 )

So if 1.58 could we post there instead (see below)

https://community.netgear.com/t5/DSL-Modems-Routers/D7000-1-58-Beta-Firmware/m-p/1485324#M21732

IT9MBZ · ‎2018-01-13

@richardw001 wrote:
@IT9MBZ wrote:
@Case850 wrote:
@IT9MBZ
Not a good idea to filter the log file. All devices need to be accountable. You could have a virus or malware on your NAS that is sending out unnecessary packets.
@Case850

I don't think so. My NAS have the antivirus service (it' a QNap).
And more, the items of log report tell the che connection trying come from remote.

Anyway, here is the log after restart.
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:36
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:34
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:32
[UPnP set event:AddPortMapping] from source 192.168.0.221 Saturday, January 13,2018 14:27:32
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:30
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:30
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:29
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:28
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 212.227.88.30:32099 to 192.168.0.124:3356 Saturday, January 13,2018 14:27:26
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:56071 Saturday, January 13,2018 14:27:13
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:09
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:08
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:07
[LAN access from remote] from 54.214.22.83:32099 to 192.168.0.124:3355 Saturday, January 13,2018 14:27:05
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:04
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:02
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 74.207.241.132:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[LAN access from remote] from 176.58.96.231:31431 to 192.168.0.30:54527 Saturday, January 13,2018 14:27:01
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:59
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:AddPortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:57
[UPnP set event:DeletePortMapping] from source 192.168.0.121 Saturday, January 13,2018 14:26:55

192.168.0.121 and 192.168.0.124 are IPCams
192.168.0.30 is NAS

Is this on 1.58 ? - I've created a new discussion thread -for 1.58 - as between people that are newly landing here because of problems with the current official firmware an people trialing the new firmware its hard to see (at least for me 🙂 )

So if 1.58 could we post there instead (see below)

https://community.netgear.com/t5/DSL-Modems-Routers/D7000-1-58-Beta-Firmware/m-p/1485324#M21732

@richardw001

I didn't know. I will reply in the other thread.

Brum80 · ‎2018-01-13

Can I ask why your creating another thread?? I think it's better to keep everything on this page, quite a few people are running.58 firmware here and I think it's best we see the results here rather than on a new thread.

richardw001 · ‎2018-01-13

@Brum80 wrote:
Can I ask why your creating another thread?? I think it's better to keep everything on this page, quite a few people are running.58 firmware here and I think it's best we see the results here rather than on a new thread.

The reasoning is that from what I have seen on this thread we have people that are at different stages - and it is unclear at the moment (at least to me) when they post whether people are seeing problems with the D7000s running the beta firmware or with the currently officially released one.

I would have expected the netgear admins here to do it tbh - at least if they are interested in our feedback on the beta firmware they only have to look in one place.

Graphicomp · ‎2018-01-13

Installed V58 yesterday evening CET.

First dropout after 13 hrs, only 2.4g fails.

Reboot. After 1 hr both WIFI fails...

Reboot. After 3 hrs only 5g fails...

During the tests, I noticed a system instability, GUI slower than ever and a high delay connecting to internet.

I had to resume my old DGND4000. I cannot remain with no connectivity during the night...

nscolli · ‎2018-01-13

There seems to be some differences of opinion on whether V58 posts should be here or in the new V58 discusson thread: https://community.netgear.com/t5/DSL-Modems-Routers/D7000-1-58-Beta-Firmware/m-p/1485324#M21732

So I thought I'd re-post my V58 post here:

"A very brief summary of my V58 experience for this new discussion thread.

08 Jan 2018

21:15 downloaded and installed FW V58.

11 Jan 2018

07:08 still all good. Reached 57+ hours.

09:00 All devices shown as connected to 5G cannot access the internet!

Various 2.4G and 5G ups and downs during 11/12 Jan fixed by either WiFi switch off/on or D7000 reboot or remote turn on by Netgear engineers.

Finally on 12 Jan 14:15 reset again with WiFi switch.

14 Jan 2018

06:49 Still all good at around 40 hours uptime.

The Netgear engineers have TeamViewed in to PC 6 times since 3 Jan and the last two times were in V58.

During the V58 time I had trouble with a Netgear WN300RP WiFi extender which was overcome by one of the reboots, so this might be "user error"! The other problem was the installation during V58 test of a Google Home Mini. Netgear intent to add one of these to their test lab environment to see if it is an issue. The Google Home Mini has been removed from my D7000 environment for the remainder of the V58 testing.

A side issue emerged during this and that is that the D7000 GUI Genie did not show the IP addresses of all connected devices. The windows program Genie also did not display all connected devices in the Network Map . The driver/system engineers are to refer this to the genie engineer team on Monday."

Graphicomp · ‎2018-01-13

...surfing the internet, I've found a forum of a community that claims for exaclty the same problem we are experiencing, with a TP-LINK VR2800 that has got exaclty the same Broadcom chipset as D7000.

Just a coincidence?

nscolli · ‎2018-01-13

Further to my D7000 V58 summary earlier (in AEDT)

14 Jan 2018

06:49 All good for around 40 hours up time

09:27 All dead:

PC on Ethernet connection displays “No Internet access” and cannot access D7000 (192.168.0.1).

5G iPad shows connected to 5G SSID but cannot connect to internet.

Laptop can see 2.4G SSID but displays “Can’t connect to this network”.

Huawei 2.4G showed SSID as disabled although WiFi turned on, clicked on SSID and display changes to “Saved”.

Cannot save log as D7000 not accessible from Ethernet, 2.4G and 5G.

D7000 Internet and DSL LEDs both white.

09:40 Rebooted D7000 and all Ethernet, 2.4G and 5G reconnected automatically.

Al94 · ‎2018-01-14

Can they explain how this only affects Netgear products? I'm now a 9 days up and running on a TP Link Archer VR900 with not one single issue and numerous devices connected.

johnmcl7 · ‎2018-01-14

@Al94 wrote:
Can they explain how this only affects Netgear products? I'm now a 9 days up and running on a TP Link Archer VR900 with not one single issue and numerous devices connected.

It looks like this can affect certain Netgear, Linksys and TP-link devices - there's a forum topic on it here:

https://productforums.google.com/forum/#!msg/googlehome/lssgm7TjgGs/wpMjS5xDAQAJ

I'm wondering if it's just Chromecast/Google Home devices or if it's Android devices as well as there's a few people here who said they either switched off their Chromecast devices or didn't have any.

Brum80 · ‎2018-01-14

I'm running beta firmware 58. I have a chromecast using 5ghz but this is powered by my TV so isn't on 24/7. I also have a few android devices. So far, I've not seen any issues with this firmware, no drops or disconnections.

Graphicomp · ‎2018-01-14

@Al94 wrote:
Can they explain how this only affects Netgear products? I'm now a 9 days up and running on a TP Link Archer VR900 with not one single issue and numerous devices connected.

I know they share the same main Broadcom chipset, the BCM61318 if I'm not wrong... + other secondary chip. This can explain the reason why not only our devices are affected. The fact that the Chomecast could cause a overload can be true... I started having problem after I have bought a new smart TV Sony... and after having set the mobile. Unfortunately I don't know how to disable Chromecast on both my mobile and Smart TV... to test again the FW V58...

Graphicomp · ‎2018-01-14

I'm sorry, I was incaccurate on my answer. I know TP-LINK modem-routers have problem on VR2800 model that share the same chipset of the D7000.

OriginalJB · ‎2018-01-14

I use my D7000 as a router to supplement my internet providers supplied modem. It's as a Technicolor modem. I noticed my Android phone would not connect on 2.4GHz. I have uninstalled the Google Home app from my phone (I used it for my Chromecast) and restarted the phone. The Chromecast is connected to the 5Ghz network. I was able to reconnect to the 2,4 network on my Technicolor modem, but when the TV fitted with the Chromecast was turned on, I lost the connection. I removed the Chromecast from theTV and the phone self-connected to the 2.4 connection.

I'm thinking it's a Chromecast/Google Home problem.

The link to a discussion on the Technicolor modem is HERE.

DKenward · ‎2018-01-15

While support are coninuing the firmware fix I came accross this which if true implies an impact accross many vendors.

https://www.theregister.co.uk/2018/01/15/router_vendors_update_firmware_to_protect_against_google_ch...

Maybe to speed a resolve vendors all need to speak with each other and work together?

michaelkenward · ‎2018-01-15

This is an amusing turn of events after all the complaints and insults thrown at Netgear's support people.

Have all the victims of this bug tried disabling anything Chromecast on their networks?

That would be an interesting experiment. It is surprising that it has taken so long for the Chromecast issue to surface. But one or two people here have dropped their Chromecast experience into the mix.

loftyendgame · ‎2018-01-15

i do not have a chromecast. i don't know what the google home app is.

i do have problems with the router!

(fwiw, we do have roku 3. i cast something to it from an android phone about 10 months ago, but not since. the roku is normally powered down until the evening)

OriginalJB · ‎2018-01-15

@loftyendgame wrote:
i do not have a chromecast. i don't know what the google home app is.

i do have problems with the router!

(fwiw, we do have roku 3. i cast something to it from an android phone about 10 months ago, but not since. the roku is normally powered down until the evening)

I have no clues.......

nscolli · ‎2018-01-15

@michaelkenward wrote:
This is an amusing turn of events after all the complaints and insults thrown at Netgear's support people.

Have all the victims of this bug tried disabling anything Chromecast on their networks?

That would be an interesting experiment. It is surprising that it has taken so long for the Chromecast issue to surface. But one or two people here have dropped their Chromecast experience into the mix.

I had a V58 D7000 crash (no 2.4, 5 or Ethernet!) 09:27 (AEDT) 14 Jan.

I suspect that it might have been caused by a Chromecast (this view reinforced by all the vaious forums and their chatter on Chromecast killing WiFi networks). The TV had been on a long time and thus the Chromecast in long sleep. I changed TV input to Chromecast, cast from an iPad and watched a show. I did not keep a log of the time this happened and the relationship to when the D7000 went down.

I resolved not to use the Chromecast since a D7000 reboot 09:40 14 Jan.

The D7000 appears to have worked as it should since then. It is now 23:00 (AEDT) so that's about 35 hours uptime with no Chromecast activity.

I suspect a Google Home Mini was, likewise, the cause of an earlier D7000 demise. It is now banned from my network by me and the netgear engineering team until V58 testing is over and solved.

michaelkenward · ‎2018-01-15

@nscolli wrote:

I suspect that it might have been caused by a Chromecast (this view reinforced by all the vaious forums and their chatter on Chromecast killing WiFi networks). The TV had been on a long time and thus the Chromecast in long sleep. I changed TV input to Chromecast, cast from an iPad and watched a show. I did not keep a log of the time this happened and the relationship to when the D7000 went down.

Uh oh. If this is a common experience it looks like the victims, and Netgear, have spent the past six weeks on a wild goose chase.

i-s · ‎2018-01-15

No, not necessarily.

We suffered the problem (and I've not checked whether it's still happening because I swapped over to our ISP-provided Fritzbox 3490 which turns out to be largely superior to the D7000) and yet we have no google home nor Chromecast.

What we DO have is an Android TV which is hooked up through Ethernet, and this offers cast functionality. Disconnecting this from the network is NOT optional - we use it every day to stream content from Amazon, youtube etc (directly from TV, not cast).

Are the chromecast or google home devices doing something that is outside of network specification, or are they doing something that although not necessary or correct still doesn't contravene any networking standard and consequently something that the D7000 should be able to cope with?

And if it's really down to a casting then why does the Fritz (and various other routers that people have tried) not suffer the same issue and why did it suddenly start happening in december having not been a problem before that?