Posted: Fri May 11, 2018 21:05 Post subject: Netgear R7000 + R8000
Router: Netgear R7000 + R8000
Firmware: DD-WRT v3.0-r35900M kongac (05/10/18 )
Kernel: Linux 4.4.131 #553 SMP Thu May 10 09:47:47 CEST 2018 armv7l
Status: WPA2 authentication instable after 2 days, moving back to 35550M
Upgraded: From 35550M via web i/f
Reset: No
Errors: Ipad client WPA2 authentication not working after 2 days runtime
R7000 config:
no DHCP
wl0 NG-Mixed WEP2/AES with fixed channels + one virtual i/f
wl1 AC/N-mixed WEP2/AES with auto channel + one virtual i/f
VLAN for guest WLAN separation
R8000:
same as R7000, plus
DHCP
QoS
Kong: Thanks for all your good work!
fahrstufensensor _________________ 2x Netgear R7000 - Kong 35550M
1x Netgear R8000 - Kong 35550M
Last edited by Fahrstufensensor on Sun May 13, 2018 23:17; edited 1 time in total
Updated yesterday my r7000 without erasing nvram and runs fine so far with a lot of features enabled and custom stuff. Nice to see that ipsec server now pushes dns correctly and works fine for wan however it uses google dns and not the internal dnsmasq on the router itself breaking internal name resolution and auto dnscrypt but at least now ipsec vpn works fine when accessing wan. Now I have to test crond that was also broken in previous builds resulting in not executing jobs or executing them only few times. If and when crond will be fixed ddwrt will be perfect for my usage. Keep up the good work @Kong and @BrainSlayer. Thanks to all those who maintain this fantastic firmware!
errors: HTTPS interface is *really* slow to connect. It's consistently stuck at the "establishing secure connecton" message in chromium for a solid 45 seconds. Subsequent page browsing takes equally as long. If I ssh into the router and watch `top` as I try to browse, the CPU usage is >50% for `httpd -S` while pages try to load. Others?
jasonring wrote:
I clear my browser cache and webui is still very slow. Took at least 10 seconds to login and 5 seconds to response to any click.
OK. Glad to hear that I'm not the only one experiencing it. I can confirm this on two different R7000s of my own and now at least 1 other (jasonring) is experiencing it too.
What can be done to further troubleshoot?
Last edited by thunderhead on Sun May 13, 2018 13:38; edited 2 times in total
Posted: Sat May 12, 2018 17:54 Post subject: RT-AC3200 asus
Router: Asus RT-AC3200
Firmware: DD-WRT v3.0-r35900M kongac (05/10/1
Kernel: Linux 4.4.131 #553 SMP Thu May 10 09:47:47 CEST 2018 armv7l
Status: stable for few hours
Reset: No
Errors: a few in radio wl2
I noticied that the range o AC radio is no longer as the previus version March 23 _________________ RT-AC68U
RT-AC3200
TL-MR3020
TL-WDR3600 v1
Firmware: v3.0-r35900M kongac (05/10/18 )
Kernel: Linux 4.4.131 #553 SMP Thu May 10 09:47:47 CEST 2018 armv7l
Previous: v3.0-r35530M kongac (03/25/18 )
Mode/Status: Up and running for about 2 days
Reset: Soft boot before and after ddup
Issues/Errors: Occasional WAN disconnections?
Upgraded via "ddup --flash-remote desipro.de/ddwrt/K3-AC-Arm/TEST/dd-wrt.v24-K3_AC_ARM_STD.bin", no 'erase nvram' this time.
Lost connection 2 or 3 times with this build, but for now I'll blame my ISP. I have a WDS/Connection Watchdog set to test 8.8.8.8 every 1000 seconds. The logs show several messages like the following after a restart, until finally successfully connecting to the NTP server after about 15 minutes of trying:
Dec 31 19:11:25 R7000 daemon.err process_monitor[1098]: cyclic NTP Update failed (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
Dec 31 19:12:00 R7000 daemon.err ntpclient[1467]: Failed resolving address to hostname 2.pool.ntp.org: Try again
Dec 31 19:12:00 R7000 daemon.err ntpclient[1467]: Failed resolving server 2.pool.ntp.org: Network is down
Dec 31 19:12:00 R7000 daemon.notice ntpclient[1467]: Network up, resolved address to hostname 212.18.3.19
Dec 31 19:12:00 R7000 daemon.debug ntpclient[1467]: Connecting to 212.18.3.19 [212.18.3.19] ...
Dec 31 19:12:03 R7000 daemon.debug ntpclient[1467]: Timed out waiting for 212.18.3.19 [212.18.3.19].
Dec 31 19:12:03 R7000 daemon.debug ntpclient[1467]: Connecting to 88.99.174.22 [88.99.174.22] ...
Dec 31 19:12:06 R7000 daemon.debug ntpclient[1467]: Timed out waiting for 88.99.174.22 [88.99.174.22].
Dec 31 19:12:06 R7000 daemon.err process_monitor[1098]: cyclic NTP Update failed (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
I did not see these messages with the previous build, the time set usually succeeded early in the startup process.
The temperatures are good: CPU 56.9 °C / WL0 45.1 °C / WL1 48.0 °C (The R7000 is wall-mounted.)
Current basic R7000 setup (subject to change of course):
- SFE - Off
- Static WAN IP
- LAN DHCP Enabled
- IPv4 only
- 1 wireless VLAN on wl0
- Encrypt DNS disabled
- Wireless: Regulatory Domain = UNITED_STATES, wl0 Mixed (ch. 1), wl1 NA-Mixed (ch. 161 + 159), AES
- SNMP enabled, SSH enabled, Telnet disabled
- Firewall enabled, Log Level high
- Syslog: remote to Logentries. klogd: disabled.
- USB support - Off
- NO: ttraf, VNC, Zabbix, VPN, Radius, OpenVPN
- NO: UPnP, DMZ, QoS
- NO: Samba, CIFS, JFFS2, miniDLNA, Entware, Optware _________________ Netgear R7000: v3.0-r54248 std (11/29/23)
EdgeRouter-X: EdgeOS v2.0.9-hotfix 7
I downgraded back to 35550M which completely reverses the slugish WebGUI bug I am experiencing. There is something is clearly wrong in 35900M related to the WebGUI :/
Joined: 23 Jan 2008 Posts: 50 Location: Ulm, Germany
Posted: Sun May 13, 2018 22:53 Post subject: Re: New Kong's build released: DD-WRT v3.0-r35900M, 05/10/18
Router: Netgear Nighthawk R7000P
Firmware: DD-WRT v3.0-r35900M kongac, Release: 05/10/18
Kernel: Linux wl-ap-eg 4.4.131 #553 SMP Thu May 1009:47:47 CEST 2018 armv7l DD-WRT
Status: Came up successfully, runs stable. 5 GHz WLAN starts to ignore broadcasts after about 2 hours of operation.
Reset: Tried NVRAM reset via Web GUI, didn't solve the problem.
Errors: 5 GHz WLAN ignores broadcasts after about 2 hours of operation
Details:
I have set up the R7000P in client bridge mode using its 5 GHz WLAN module. The access point the R7000P connects to is a Netgear R7000 which is also running DD-WRT and serving other clients (e.g. Linksys WRT600N). In this scenario, the R7000P (and only the R7000P, the other clients are not affected) seems to start ignoring incoming packets to the broadcast address FF:FF:FF:FF:FF:FF on the 5 GHz device after about two errors of operation. This can be clearly observerd by using "tcpdump -i any".
This problem breaks ARP and DHCP. A DHCP client, which connects to the 2.4 GHz device of the R7000P, or a DHCP client, which connects via wire to the R7000P, doesn't get an IP address.
I suppose that the driver for "eth2" (wl0: May 1 2017 12:43:53 version 10.10.122.301 (r658909) FWID 01-1ebebd8a) is the cause of the problem. I tried earilier versions of KONG and BS builds (which come with the same driver) and discovered the same problem. There are no eth2-related messages in the dmesg log. Especially, there is no log when the problem starts to occur. :-(
Resetting the R7000P to factory defaults didn't help.
It is definitely not a "packet loss" problem caused by bad radio channel conditions. Unicasts come through perfectly. The problem is independent from the channel number.
After reconnecting the 5 GHz link, the problem is gone for another 2 hours
Web GUI is fine, no lag. Everything is running ok, except ...
Connect a laptop via 'wireless display' to Roku 3 box. Video and sound transfer over to the roku + TV. For a minute or two, then it crashes. The laptop is on VPN, the roku is not, using policy based routing. After the crash, I see the VPN loses or already has lost connection and automatically reconnects. So OpenVPN client is crashing when using a wireless display.
Update: the VPN lost connection again this morning, nothing was streaming at the time. It did reconnect automatically. The log transmitted to papertrail shows nothing. I also see a huge number of dnsmasq-dhcp entries for my daughters iPhone e.g.
Code:
May 16 03:30:46 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:30:46 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:30:48 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:30:48 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:35:46 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:35:46 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:37:05 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:37:05 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:39:37 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:39:37 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:54:09 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:54:09 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:57:54 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:57:54 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:58:35 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:58:35 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:58:46 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:58:46 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 03:58:54 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 03:58:54 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 04:09:02 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 04:09:02 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 04:10:56 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 04:10:56 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 04:11:57 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 04:11:57 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
May 16 04:14:25 Netgear_R7000 dnsmasq-dhcp: DHCPREQUEST(br0) 192.168.0.191 60:xx:xx:xx:xx:xx
May 16 04:14:25 Netgear_R7000 dnsmasq-dhcp: DHCPACK(br0) 192.168.0.191 60:xx:xx:xx:xx:xx Rachels-iPhone
Update: laptop lost connection on 2.4G WiFi. Rebooted laptop and router several times, the laptop would either not see the 2.4G or did see it but could not connect. Reverted back to R35030M. Everything working well again.
Last edited by kallsop on Thu May 17, 2018 11:24; edited 2 times in total
I've to correct myself. It seems to be working until an "EAPoL key" frame is received from the AP by the R7000P. After then, the R7000P starts to ignore frames to FF:FF:FF:FF:FF:FF.
Edit: I did further tests: The problem I observe is definitely caused by session key renewal (in WPA2 PSK mode) on 5 GHz.
As soon as the R7000 AP sends the EAPoL message, my R7000P client bridge stops answering incoming broadcast messages (they don't appear in tcpdump log anymore). This breaks, for example, DHCP clients, which connect to the 2.4 GHz device of the R7000P, or wired clients, which are connected to the LAN ports of the R7000P.