Posted: Mon May 17, 2021 7:26 Post subject: New Build - 05/17/2021 - r46690
[WARNING]: This thread is only for feedback on this beta release for developers and the community's benefit.
DO NOT flash this beta release unless you understand the risks involved and device specificrecovery methods.
Avoid discussions! Create threads for questions, general problems or use search; this thread is not for support.
Please list router model & revision, operating & wireless mode(s) and exact filename/firmware image flashed.
Issues:
• Show us your findings with steps to reproduce, configuration, output, logs and important information below!
Important:
• For issues provide applicable info: 'dmesg', 'cat /tmp/var/log/messages', syslog, klog, serial, strace, tcpdump, wireshark etc.
• Any firewall NAT or WAN issues, show output: 'iptables -vnL', 'iptables -t nat -vnL', 'iptables -t mangle -vnL' and /tmp/.ipt file.
• Search SVN tickets & discuss in forum before opening. Before reporting: reset & manually set up, not restore from a backup.
• Please include operating & wireless modes (e.g. Gateway, Router, AP, CB, WDS, Mesh) & relevant configuration information.
Flashed my 1900ACSv1 via CLI from 44048. I did not reset to factory this time. No issues with the upgrade.
Test #1: I set the wifi settings to match Argenis' settings as close as possible.
WLAN0 Mode AP VHT80 80MHz Mixed Mode Channel and Extension Channel Auto Extension LL-6
WLAN1 Mode AP 20 MHz Mixed Mode Channel Auto
TX Power 19 dBm
Antenna Gain 0 dBi
U-APSD (Automatic Power Save)Enabled
Protection Mode None
RTS Threshold Disabled
Short Preamble Disabled
Short GI Enabled
Single User Beamforming Enabled
AP Isolation Disabled
Beacon Interval 100
DTIM Interval 2
WMM Support Enabled
Radar Detection Disabled
ScanList default
Sensitivity Range (ACK Timing) 500 (Default: 500 meters)
Max Associated Clients 16
Minimum Signal for authenticate -96
Minimum Signal for connection -96
Poll Time for signal lookup 10
Amount of allowed low signals 3
Wireless security is WPA2 Personal CCMP-128 only
QAM256 is off
Test #2: Same as above but with a 20mhz channel width on wlan0.
Test clients:
Macbook PRO 2018 running 11.3.1
iPhone SE 2020 running 14.5.1
Results: Neither test worked. Hostapd takes a dump shortly after either of these two apple clients connects to wlan0. The one time the iphone was connected and hostapd hadn't dumped yet, it's wifi got hung up - stopping/starting wifi on the iphone restored it but then hostapd dumped. No progress here - back to 44048. Environment details, dmesg and logs attached.
Went back to 44048 which is the last good release if you have Apple devices in your environment. Something broke starting with 44085.
Linksys WRT1900ACSv1: router operating mode, hardwired ethernet lan to a WRT3200ACM. Normal WIFI settings when I'm not testing: 2.4ghz: NG-mixed, 20mhz channel width, channel 11, WPA2-CCMP-128. 5ghz: AC/N mixed, 80mhz channel width, channel 36+upper, WPA2-CCMP-128.
Clients: Apple MACOS x 4, IOS x 4, Apple TV, Chromecast Audio x 2, Eufy doorbells, Lutron Caseta, Axis Camera, Samsung TV, Nest thermostat, EtekCity outlets (Espressif)..
Upgraded WRT1200AC v1's from r46681 to r46690 using Brave 1.10.97 (64-bit) running on Linux Mint 20.1 OS hardwired via Cat6.
Successful update and reboot. No reset, nothing disabled prior to update, uptime approx 2 hrs, wired/wireless connected, vpn up immediately (Expressvpn). I do not use NAS. SFE, QoS and IPv6 are always disabled. OpenVPN client/DNSMasq and radios always enabled. I do not have any Apple devices.
Kernel Version Linux 4.9.268 #2606 SMP Mon May 17 04:09:39 +07 2021 armv7l
Skipped a couple of builds - and tried this one. Same crashing as before - and similar as reported by pbphoto..
Flashed from 46069. No reset.
Uptime 1:32. Load average: 8.64, 5.71, 2.68
Apple devices (and others) connected and worked during the uptime. WEB Gui not accessible at 1:30. Crashed with message "hostapd Not tainted 4.9.268 #2606".
Router is still alive, and can be accessed via Wifi and wire on terminal.
Speedtest on Apple Ipad conducted after GUI crash. Connected to Wifi 5GHZ radio. Fast.com reports 360Mbit DL. Before crash, same test gave 500Mbit DL (Full speed - Line saturation).
I'd expect the Wifi to become unaccessible. Will test some more before cold-booting. Dmesg log enclosed.
Update: Did a cold boot. The kernel crash did return - starting with wifi clients staying connected - but no lease on reconnect. After a while wifi and wired connections to internet stops. Wired connection to terminal still possible. Same behaviour as all builds > 46069.
Router/Version: WRT1900ACSv1 / r46690
File/Kernel: webflash / Linux 4.9.268 #2606 SMP Mon May 17 04:09:39 +07 2021 armv7l
Previous/Reset: r46640 (missed r46681) / No
Mode/Status: Gateway, OpenVPN Client, FreeRadius Server / Up
Issues/Errors: None!
Comments: Updated via Putty SSH from r46640 in linux partition #1 to r46690 in linux partition #2 and rebooted. Everything's working well, even after connecting an iOS 14.5.1 client with Private Address (per-network MAC randomization) enabled.
EDIT: Still running smoothly after connecting/disconeecting/reconnecting a Windows 10 PC with MAC Randomization ("Use private hardware address") enabled! _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Last edited by o2bad455 on Tue May 18, 2021 17:59; edited 1 time in total
Skipped a couple of builds - and tried this one. Same crashing as before - and similar as reported by pbphoto..
Flashed from 46069. No reset.
...
Update: Did a cold boot. The kernel crash did return - starting with wifi clients staying connected - but no lease on reconnect. After a while wifi and wired connections to internet stops. Wired connection to terminal still possible. Same behaviour as all builds > 46069.
That's the same as what I experienced my first try with r46640 when an Apple iPad Air 2 iOS 14.4 client connected. But as soon as I updated that client to iOS 14.5.1, all was stable for days! Although too soon to say for this build as I've had it up less than an hour, I might suggest ensuring all Apple devices are updated to no less than iOS 14.5.1 (no idea about MacOS since we don't have any). _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Skipped a couple of builds - and tried this one. Same crashing as before - and similar as reported by pbphoto..
Flashed from 46069. No reset.
...
Update: Did a cold boot. The kernel crash did return - starting with wifi clients staying connected - but no lease on reconnect. After a while wifi and wired connections to internet stops. Wired connection to terminal still possible. Same behaviour as all builds > 46069.
That's the same as what I experienced my first try with r46640 when an Apple iPad Air 2 iOS 14.4 client connected. But as soon as I updated that client to iOS 14.5.1, all was stable for days! Although too soon to say for this build as I've had it up less than an hour, I might suggest ensuring all Apple devices are updated to no less than iOS 14.5.1 (no idea about MacOS since we don't have any).
After the cold boot, the router stayed stable for ca 10 hours. And then crashed. Needless to say, during that time, the Apple devices worked just fine.
Your assumption that the Apple Devices bring down the router is one I'm not convinced about. I have similar connection problems with my Samsung Galaxy S9+. Why wouldn't that bring down the router?
It just doesn't make sense that 46069 is stable while later builds crash, and the dev's claim they haven't changed anything related to the Marvel implementation.
Something must have changed in DD-WRT between those builds. The Apple devices are not nice behaving wifi-citizens on 46069 and aggressive wifi predators on later builds. They are the same. So we have a simple case of occam's razor here.... the more assumptions you have to make, the more unlikely is the explanation. Or to put it bluntly - DD-WRT has a bug introduced >46069 on these routers, that hasn't been addressed/found yet.
Anyway, will check/try the update on the Apples and report back.
Update: That was quick. All Apple devices updated to IOS 14.5.1. Literally within minutes another well-known crash. Same story. Wasting time here....
Thinking back to the troubles between r44048 and r46069, I recall that those were mostly related to the Apple devices themselves having trouble while non-Apples were generally fine.
Then between r46069 and r46640, I had the recurring router crashes and/or inability to reconnect anything (unresponsive) issues, generally within the first hour or so.
Now, including and since r46640 but after updating the Apple test client to iOS 14.5.1, zero issues so far (knock on wood) with two routers tested on r46640 and now one testing on r46690.
I suppose best scientific method would be for me to go back to other builds that had crash/unresponsive issues to see if the later iOS really cures it, but until I find the time to try that it sure looks like iOS versions of 14.4.x (or before 14.5.1) remain suspicious.
That said, I agree that in an ideal world a client OS issue should not bring down a router nor make it unresponsive. It's really too bad that we can't get ALL of the router's driver source code to sort this out properly, but that's our lot with this wifi hardware. In all honesty, I'm amazed that it works at all. Thank you BS!
I appreciate Ockham's razor (or as a favorite teacher used to say, Keep It Simple Stupid - K.I.S.S.). Just to summarize: On r46640 with an iOS 14.4 client, everything went bad within an hour. But after updating that client to iOS 14.5.1 (literally the only change), the router was stable for days. No assumptions. That's exactly how it played out.
I just enabled MAC-randomization on a Windows 10 client with a compatible wifi adapter (some are, some aren't). So the current test mix has 7 clients (1 wired printer/scanner, 6 wireless) including three PCs (one with MAC-randomization), two Androids, and one Apple with MAC-randomization (iPad Air 2 running iOS 14.5.1).
If the current r46690 build handles this for the week, I'll be jumping for joy (and begin the diplomatic task of enticing the other Apple users back into the fold). If not, I'll consider r46640 rather than r46069 to be the most recent stable build for my configurations (having missed testing r46681 so far). _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Flashed my 1900ACSv1 via CLI from 44048. I did not reset to factory this time. No issues with the upgrade.
Test #1: I set the wifi settings to match Argenis' settings as close as possible.
Just to be clear, did you neither reset nor restore? My understanding is that there are so many differences between r44xxx and r46xxx builds that we basically have to do a reset. Particularly there, where even the wifi wlan's changed from athx to wlanx, etc.
My work-around when swapping between distant builds is to reconfig just once from scratch to a recent build, save a backup, and then use that as an intermediate stepping stone the next time around.
I really don't think there's any better way (unless scrubbing nvram of incompatible variables would be enough - anyone know?). Upgrading from such distant builds without reset is otherwise quite likely to be a major contributor to any issues, IMHO. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
...
Update: That was quick. All Apple devices updated to IOS 14.5.1. Literally within minutes another well-known crash. Same story. Wasting time here....
Oh well. Thanks for trying. I really don't know then why mine are working again. I haven't made any config changes for many builds (I'd considered SurprisedItWorks MTU suggestion but r46640 had already started working so I didn't change anything).
EDIT 1: Oh, just one more thought... Any Apple iWatches in the mix? We have one that we went out of our way to update. It uses some sort of a Bluetooth bridge to a paired iPhone, but could be messing things up since it occasionally tries to get its own lease via the paired device despite lack of its own wifi (and apparently rarely succeeds when everything's running smoothly).
EDIT 2: Apparently the Apple Watch does have it's own wifi (at least that's what the owner just told me). Hmmm...
EDIT 3: It's an Apple Watch Series 5 running watchOS 7.3.3 (the latest is 7.5.RC). It looks like it "learns" wifi connection parameters from its bluetooth paired iPhone, but can then connect directly by wifi if the iPhone is off or out of range. Interestingly, it appears that it can only connect to PSK learned through the paired iPhone, but not EAP! But when the piared iPhone is connected ny EAP, the watch can piggyback on that.
EDIT 4: So, I suppose one difference between my DD-WRT config and most others is that this Watch probably can't connect directly to my EAP wlans without the updted iPhone in play, whereas it could (and has) connected directly to PSK wlans without the iPhone present.
EDIT 5: Here's Apple's support link on the subject:
https://support.apple.com/en-us/HT209071 _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Last edited by o2bad455 on Tue May 18, 2021 22:24; edited 8 times in total
Now, including and since r46640 but after updating the Apple test client to iOS 14.5.1, zero issues so far (knock on wood) with two routers tested on r46640 and now one testing on r46690.
...well, in this thread we have two occurrences of the same crashes we had before, with updated IOS, me - and pbphoto. So if you had them, but don't have them anymore - I'd be really interested in any other hypothesis than the IOS update being the reason. And if that's the only difference between the builds.... then we are in goblin territory here:
- We all came from 46069 being stable
- We all had crashes up until now/recently > 46069
- Both pbphoto and me, have updated IOS-Clients (Assumed salvation), and we both experience the same crashes as before.
It tells me its something else, than the IOS-update - and if that's the only change you made - then either we have to wait until it eventually crashes for you as well - or just accept that this problem seems to be completely individual and random, and for some very peculiar reason is not happening to any of us on 46069.
UPDATE: OK - no goblins after all. Saw the update of o2bad455 in the 46640-thread. It crashed after all. So lets get back to assuming the obvious - a bug has been introduced in later builds - and hasn't been fixed yet.
Last edited by Fonzi on Wed May 19, 2021 15:57; edited 1 time in total
Yeah... I feel like we must be close to figuring it out, but never quite do. The stark contrast between my back-to-back tests of iOS versions in r46640 really seemed key, but perhaps only in combination with other esoteric settings. Let's wait and see if either or both of my ACSv1 on r46640 or ACSv2 on r46690 last the week. If so, I'll plan to post up detailed configs again (or maybe share an nvram backup of a trimmed down config if anyone's game to test).
EDIT: After putting r46640 on our production/daily-use router (ACSv1), I wasn't able to prevent non-updated Apple clients (e.g., an iOS 14.4.2 iPhone) from connecting and experienced a wifi issue as posted in that build's thread. Realizing that I can't prevent non-updated Apple devices from being used on that router, it's switched back to the r46069 partition. I'll continue testing the latest build on our test router (ACSv2), which is still running well with an iOS 14.5.1 client and various non-Apples after over 1 day up and counting. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Last edited by o2bad455 on Wed May 19, 2021 17:28; edited 1 time in total
Posted: Tue May 18, 2021 21:29 Post subject: slow WLan connection to clients
I am just install the new update "2021/05-17-2021-r46690" on my new "linksys-wrt3200acm". The WLan range is very bad!
Before I had the "Buffalo WZR-HP-AG300H", this router had reach all my clients without problems.
I must use the 2.4Ghz Wlan.
What goes wrong? Why the Range is sooo bad? I can not understand why this model of Router is not better than the buffalo!?!?
Clients:
- 2 x Samsung Android Phones
- 3x Webcam
- PC
- Android Tablet
- 2x Maxcio Wlan Switch Mini
- 8x TECKIN Smart Wlan Steckdose 16A SP21
- Internet Radio
- and some other stuff
best regards _________________ Buffalo WZR-HP-AG300H
Posted: Tue May 18, 2021 21:56 Post subject: Re: slow WLan connection to clients
Fritzbuf wrote:
I am just install the new update "2021/05-17-2021-r46690" on my new "linksys-wrt3200acm". The WLan range is very bad!
Before I had the "Buffalo WZR-HP-AG300H", this router had reach all my clients without problems.
I must use the 2.4Ghz Wlan.
What goes wrong? Why the Range is sooo bad? I can not understand why this model of Router is not better than the buffalo!?!?
...
best regards
One possibility is the relatively short omni-directional antennas that these ship with. Although relatively high quality as consumer router antennas go, they're relatively low gain. Linksys does sell taller (generally higher gain) antennas that are better for same-floor level but worse for upstairs/downstairs (when pointed straight up, that is). I've actually had a pair of taller more directional borrowed Netgear antennas mounted in place of 2 of the 4 Linksys antennas when I wanted a better connection in an outdoor garage without boosting router output power (since client output power couldn't match that anyway). Worked quite well as long as longer antennas tilted perpendicular (NOT parallel) to desired direction. Antenna orientation less critical with shorter (generally lower gain) antennas, but can still help. Contrary to common sense, pointing these antennas in the parallel rather than perpendicular direction generally makes the signal strength worse. Another alternative is a Yagi antenna, although I'm not sure how it would work due to the multi-antenna diversity on these. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Posted: Wed May 19, 2021 13:10 Post subject: Re: slow WLan connection to clients
o2bad455 wrote:
Fritzbuf wrote:
I am just install the new update "2021/05-17-2021-r46690" on my new "linksys-wrt3200acm". The WLan range is very bad!
Before I had the "Buffalo WZR-HP-AG300H", this router had reach all my clients without problems.
I must use the 2.4Ghz Wlan.
What goes wrong? Why the Range is sooo bad? I can not understand why this model of Router is not better than the buffalo!?!?
...
best regards
One possibility is the relatively short omni-directional antennas that these ship with. Although relatively high quality as consumer router antennas go, they're relatively low gain. Linksys does sell taller (generally higher gain) antennas that are better for same-floor level but worse for upstairs/downstairs (when pointed straight up, that is). I've actually had a pair of taller more directional borrowed Netgear antennas mounted in place of 2 of the 4 Linksys antennas when I wanted a better connection in an outdoor garage without boosting router output power (since client output power couldn't match that anyway). Worked quite well as long as longer antennas tilted perpendicular (NOT parallel) to desired direction. Antenna orientation less critical with shorter (generally lower gain) antennas, but can still help. Contrary to common sense, pointing these antennas in the parallel rather than perpendicular direction generally makes the signal strength worse. Another alternative is a Yagi antenna, although I'm not sure how it would work due to the multi-antenna diversity on these.
Now the Range is a little bit better, but not so good as my old Buffalo
I install a repeater at groundfloor and all my clients are now connected.
