Your reports for Broadcom units are greatly appreciated !
Router: Netgear R7000
Firmware: Upgraded from r33435M to r33575M
Status: The upgrade itself worked well, but severe problems occurred regarding Wi-Fi connectivity. The router is in AP mode. While the wired connections work flawlessly, the 2.4 GHz and 5.8 GHz Wi-Fi link to all clients (three Linksys WRT600N (in Client AP mode), two Linksys WRT54G (in Client AP mode), one Linksys WAP54G (in Client AP mode) and two Samsung Galaxy S5) became very unstable after this upgrade or don't work at all. The devices "see" each other, but there is no stable data transmission.
Reset: Tried, didn't help.
Errors: No error messages are shown. WLAN just got unstable - in an unusable manner. No problems with r33435M.
Last edited by Steffen M. on Tue Oct 24, 2017 8:18; edited 1 time in total
I forget what build I came from, I *THINK* it was 33010 on an R7000. It was an August kong build, and I see 33010 was the only August build. I had to regenerate certificates for Wifi, but that's fine, as there was a radius or openssl update. However, some of my 2.4ghz devices either can't connect, or they are unstable. And one of these is my Wifi thermostat. I see others are having 2.4g wifi issues too. Hopefully the issue can be figured out. The devices that have the issues can SEE the network, but just don't connect to it and the only change was the router firmware upgraded. I guess something happened with the wifi hacking bug fixes or something, perhaps?
Posted: Tue Oct 24, 2017 0:11 Post subject: Re: New Kong test build: DD-WRT 33575M - 2017/10/22
Appreciate the work on DD-WRT and quick turnaround on the fix. Some feedback from testing:
CloneVince wrote:
Router: R7000
Firmware: Flashed : dd-wrt.v24-K3_AC_ARM_R7000P.bin, upgrading from generic build 32170M
Kernel: Reported as Linux 4.4.94 #456 SMP Sun Oct 22 22:42:48 CEST 2017 armv7l
Status: Partially working, stable for ~70% of my client devices. Configured as simple WAP, no extra services.
Reset: No.
Errors: Majority of wireless clients OK: Android devices from Samsung, Sony, Asus. However can see devices repeatedly connecting and dropping on 2.4G from Nvidia and LIFX.
Router: Netgear R6400
Firmware: Flashed dd-wrt.K3_R6400.chk from ftp -> v3.0-r33575M kongac (10/22/17)
Kernel: Linux 4.4.94 #456 SMP Sun Oct 22 22:42:48 CEST 2017 armv7l
Status: Runs fine - basic router AP with some additional hardwired AP's
Reset: No (but rebooted)
Errors: Android devices (Sony and Motorola) on 2.4Ghz network are repeatedly dropping and reconnecting. Same problem on release 33525. Other devices are probably doing the same, but I don't notice them because I have notifications setup on the android's for this.
I was hoping we have an option for "Disable EAPOL Key Retries" here but it doesn't seem to apply to this yet (Broadcom maybe).
Last edited by eddwrt on Tue Oct 24, 2017 19:44; edited 1 time in total
Posted: Tue Oct 24, 2017 10:31 Post subject: Can't see USB attached as SAMBA, OpenVPN Client config, DNS
CloneVince wrote:
Kong, I have a problem with this build :
I can't access to my network computers, for example my windows server, my AppleTV and my network printer.
May be related, but I updated from the prior version via ddup --flash-latest, and can no longer access USB storage mounted to the DD-WRT via SAMBA. I was attempting to add write access to a exFAT mount using Slim Samba 2 before upgrading, now my NVIDIA Shield TV doesn't see the SAMBA share at all.
Also, in order to connect to my VPN, I had to add tls-cipher "DEFAULT:@SECLEVEL=0" to the OpenVPN Client Configuration
No problems with SAMBA or miniDLNA (netgear R6400)
this problem with many DNS's is a bit funky....
what ive noticed so far is... among all the selected DNS router is using the fastest to replay/respond but not in selected order (unless you tick use DNS in strict order) but even thou the fastest DNS might respond fast to pings but might not be able to resolve or fail to resolve data that fast, and in this case you got no or bad DNS probe, but the router doesn't switch to the next one, so there must be another criteria to switch to the next chosen DNS apart from pinging time ... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Router: Netgear R7000
Firmware: v3.0-r33575M kongac (10/22/17)
Kernel: Linux 4.4.94 #456 SMP Sun Oct 22 22:42:48 CEST 2017 armv7l
Status: Up and running for just under 48 hours
Reset: Soft boot before and after ddup
Errors: None
Upgraded via 'ddup --flash-latest' from r33525M. No 'erase nvram' this time.
The temperatures are good: CPU 60.2 °C / WL0 48.3 °C / WL1 49.3 °C (The R7000 is wall-mounted.)
I see that some other users of this version are encountering connectivity issuers with wireless clients. My tablets and phone all seem to work without issues, but I have an older Linksys camera, the WVC54GCA (G-only), that has cut-out twice since installing 33575. Each time I've had to preform a power-off reset of the camera to re-establish connectivity. At this point I am not ready to blame 33575, as the camera is old and probably on its last legs, but I want to note the issue. At about the time of the connectivity failure the logs show:
24 Oct 2017 15:28:01.008<14>Oct 24 15:28:00 : nas : NAS daemon successfully stopped
24 Oct 2017 15:28:03.260<14>Oct 24 15:28:03 : nas : NAS daemon successfully stopped
24 Oct 2017 15:28:03.372<14>Oct 24 15:28:03 : NAS : NAS lan (wl0 interface) successfully started
24 Oct 2017 15:28:03.377<14>Oct 24 15:28:03 : NAS : NAS lan (wl1 interface) successfully started
...followed by several dnsmasq-dhcp calls.
Current basic R7000 setup (subject to change of course):
- SFE - On
- Static WAN IP
- LAN DHCP Enabled
- IPv4 only
- No additional VLANS
- Encrypt DNS enabled / Cisco OpenDNS
- Wireless: Regulatory Domain = UNITED_STATES, wl0 NG-Mixed (ch. 7 + 5), 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 Flashdrive mounted as JFFS, adblocking via pixelserv
- NO: ttraf, VNC, Zabbix, VPN, Radius, OpenVPN
- NO: Port forwarding, 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
My tablets and phone all seem to work without issues, but I have an older Linksys camera, the WVC54GCA (G-only), that has cut-out twice since installing 33575. Each time I've had to preform a power-off reset of the camera to re-establish connectivity. At this point I am not ready to blame 33575, as the camera is old and probably on its last legs, but I want to note the issue. At about the time of the connectivity failure the logs show:
It's worth noting that I only noticed the disconnects because I have a custom notification (via tasker) on my Android devices which let's me know when a wifi connection is lost. The device would subsequently reconnect almost immediately to the same AP.
For most devices I would imagine most users wouldn't notice this. For devices like IP cameras tho, where the stream is constant, such hiccups would be much more noticeable. I wouldn't count your old camera out completely yet
I've dropped my R6400 back down to 33435 again and the disconnects appear to have resolved with some limited testing - although I'm not willing to blame 33575 completely yet. Good idea to check the log, I should have looked at it more carefully.
Interestingly enough, my 5Ghz client remains solidly connected throughout the entire ordeal.
Posted: Wed Oct 25, 2017 13:58 Post subject: Re: New Kong test build: DD-WRT 33575M - 2017/10/22
Steffen M. wrote:
Router: Netgear R7000
Firmware: Upgraded from r33435M to r33575M
Status: The upgrade itself worked well, but severe problems occurred regarding Wi-Fi connectivity. The router is in AP mode. While the wired connections work flawlessly, the 2.4 GHz and 5.8 GHz Wi-Fi link to all clients (three Linksys WRT600N (in Client AP mode), two Linksys WRT54G (in Client AP mode), one Linksys WAP54G (in Client AP mode) and two Samsung Galaxy S5) became very unstable after this upgrade or don't work at all. The devices "see" each other, but there is no stable data transmission.
Reset: Tried, didn't help.
Errors: No error messages are shown. WLAN just got unstable - in an unusable manner. No problems with r33435M.
Yeah, something is not quite right with wireless connectivity here. My old WVC54GCA camera works fine with a wired connection, but wireless-G is very flaky. Even though the camera shows in the wireless clients list in the System Info page with a fairly solid 76% Signal Quality, the ability to stream, or even connect dies after a time. I also noticed issues with my Roku Streaming Stick (5GHz) when viewing YouTube, usually that "Loading..." message when viewing a video. _________________ Netgear R7000: v3.0-r54248 std (11/29/23)
EdgeRouter-X: EdgeOS v2.0.9-hotfix 7
I was having a similar problem with reconnects on my e4200v1 on a "stable" build (30880). Since I knew it's an older broadcom unit and hasn't been reset in a while I did a 30/30/30 on it. So far it seems better now - will keep monitoring.
I wonder if my R6400 needs this as well. I'm a bit heasitant to do it because of the amount of config i've got in there (i suppose it's time to back it up..)
That said - I am back to 33435 and I am not experiencing those problems.
Posted: Wed Oct 25, 2017 23:12 Post subject: R8000
Came back to it re-flashed and everything was showing a issue with wireless. Did a hard reset by pushing the reset button and everything is working correctly. CPU usage was high at first but I think that it is calming down. Hopefully wireless is stable.
Posted: Thu Oct 26, 2017 1:20 Post subject: Re: R8000
james1795 wrote:
Came back to it re-flashed and everything was showing a issue with wireless. Did a hard reset by pushing the reset button and everything is working correctly. CPU usage was high at first but I think that it is calming down. Hopefully wireless is stable.
I did believe you (for several minutes). Speaking of Broadcom routers, positing the need for a factory reset is a red flag. _________________ 2 times APU2 Opnsense 21.1 with Sensei
2 times RT-AC56U running DD-WRT 45493 (one as Gateway, the other as AP, both bridged with LAN cable)
3 times Asus RT-N16 shelved
E4200 V1 running freshtomato 2020.8 (bridged with LAN cable)
3 times Linksys WRT610N V2 converted to E3000 and 1 original E3000 running freshtomato 2020.8 (bridged with LAN cable)
Thanks for all the hard work Kong.
