Posted: Mon Apr 19, 2021 12:08 Post subject: New Build - 04/19/2021 - r46395
[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.
Upgraded WRT1200AC v1's from r46380 to r46395using 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.267 #2564 SMP Mon Apr 19 03:35:08 +07 2021 armv7l
Router/Version: WRT1900ACSv2 / r46395
File/Kernel: webflash via SSH curl / 4.9.267 #2564
Previous/Reset: r 46380 / No
Mode/Status: Gateway / Uptime 2:19 hours
Issues/Errors: No 5G broadcasts at all during above test period, but 2.4G and wired were working fine with PC, Androids, and an iPad for a bit. Combined log attached. I just rebooted and 5G came back! Seems quite good now, and definitely an improvement. I'll update if there's any change. Thank you! _________________ 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 do a reset or 'nvram erase'. No issues with the upgrade. Lots of clients connected right away to both radios - appeared to be working fine but I didn't get a chance to test it because it crashed within a minute.
Within 1-3 minutes, got the process crash dump in dmesg that many users have been seeing since 46069. Could be related to Apple clients. Browser becomes unresponsive, existing wifi clients remain connected and running fine, however no new wifi clients are able to connect.
dmesg:
[ 10.528777] br0: port 3(wlan0) entered blocking state
[ 10.533862] br0: port 3(wlan0) entered forwarding state
[ 10.992886] br0: port 4(wlan1) entered blocking state
[ 10.997972] br0: port 4(wlan1) entered disabled state
[ 11.003165] device wlan1 entered promiscuous mode
[ 11.198791] br0: port 4(wlan1) entered blocking state
[ 11.203879] br0: port 4(wlan1) entered forwarding state
[ 11.953529] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 12.099386] ieee80211 phy0: Mac80211 start BA f4:fe:fb:55:75:30
[ 35.842301] ieee80211 phy0: Mac80211 start BA f0:18:98:6a:3d:e1
[ 52.821527] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 52.829668] pgd = dc814000
[ 52.832405] [00000004] *pgd=1c8d7831, *pte=00000000, *ppte=00000000
[ 52.838770] Internal error: Oops: 17 [#1] SMP ARM
[ 52.843490] Modules linked in: ip6_tables btmrvl_sdio btmrvl bluetooth mwifiex_sdio mvsdio sdhci_pxav3 sdhci_pltfm sdhci mmc_block mmc_core mwifiex mwlwifi mac80211 compat mii tmp421 pwm_fan leds_pca963x leds_tlc591xx orion_wdt
[ 52.863963] CPU: 1 PID: 1172 Comm: hostapd Not tainted 4.9.267 #2564
[ 52.870341] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 52.876285] task: df4b1f80 task.stack: dd14e000
[ 52.880866] PC is at _1534+0x9d4/0x1304 [mac80211]
[ 52.885675] LR is at 0x0
[ 52.888216] pc : [<bf02cb70>] lr : [<00000000>] psr: 80000013
[ 52.894507] sp : dd14fba8 ip : de140c20 fp : dd3d84c0
[ 52.899752] r10: de546138 r9 : 00000000 r8 : 00000000
[ 52.904996] r7 : 00000000 r6 : dd258150 r5 : dd258000 r4 : dd14fc28
[ 52.911548] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 52.918101] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 52.925265] Control: 10c5387d Table: 1c81404a DAC: 00000055
[ 52.931033] Process hostapd (pid: 1172, stack limit = 0xdd14e210)
[ 52.937149] Stack: (0xdd14fba8 to 0xdd150000)
[ 52.941524] fba0: c0a25540 00000493 df4f89c0 de140c20 dd258150 ffff9f71
[ 52.949736] fbc0: 00000001 dd2586b8 dd258150 c051711c de3fb720 de141138 dd3d8000 de3f4720
[ 52.957947] fbe0: dd14fc28 dd3d8000 00000014 de546138 dcb3c800 bf048a1c dd14fd4c bf0489d8
[ 52.966158] fc00: de3f4720 de140000 dd3d8000 bf0b1d10 00000000 de140000 dd3d80c0 de3fb720
[ 52.974370] fc20: dd14fc28 00000000 1183bf82 00010581 00000013 00000028 ec0c8dac 00000007
[ 52.982581] fc40: 00054ab5 00000000 0008614d 00000000 00000000 00c9ce00 00000000 00000000
[ 52.990792] fc60: 00000000 00000000 00000000 00000000 00000506 00000403 00000000 00000000
****** Truncated stack trace ********
[ 53.196070] ff80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffc0
[ 53.204281] ffa0: 00000128 c010b9c0 00000000 00000000 00000006 becaaaa4 00000000 00000000
[ 53.212493] ffc0: 00000000 00000000 ffffffc0 00000128 becaab38 00000001 00000004 0012bff0
[ 53.220704] ffe0: becaaa30 becaaa1c b6f6a848 b6f69d10 60000010 00000006 00000000 00000000
[ 53.228964] [<bf02cb70>] (_1534 [mac80211]) from [<bf048a1c>] (_509+0x44/0x60 [mac80211])
[ 53.237219] [<bf048a1c>] (_509 [mac80211]) from [<bf0b1d10>] (_1347+0x58/0x108 [mac80211])
[ 53.245542] [<bf0b1d10>] (_1347 [mac80211]) from [<bf01bc68>] (_45+0x20/0x6c [compat])
[ 53.253497] [<bf01bc68>] (_45 [compat]) from [<c051a974>] (genl_rcv_msg+0x31c/0x3c8)
[ 53.261274] [<c051a974>] (genl_rcv_msg) from [<c0517368>] (netlink_rcv_skb+0x5c/0xc0)
[ 53.269136] [<c0517368>] (netlink_rcv_skb) from [<c05197b0>] (genl_rcv+0x24/0x34)
[ 53.276650] [<c05197b0>] (genl_rcv) from [<c0516e98>] (netlink_unicast+0x20c/0x4f0)
[ 53.284339] [<c0516e98>] (netlink_unicast) from [<c0517f1c>] (netlink_sendmsg+0x324/0x36c)
[ 53.292638] [<c0517f1c>] (netlink_sendmsg) from [<c049c4fc>] (___sys_sendmsg+0x238/0x290)
[ 53.300851] [<c049c4fc>] (___sys_sendmsg) from [<c049cdc4>] (SyS_sendmsg+0x68/0xa0)
[ 53.308542] [<c049cdc4>] (SyS_sendmsg) from [<c010b9c0>] (ret_fast_syscall+0x0/0x40)
[ 53.316319] Code: e7e31251 e203300f e0822101 e59228cc (e5922004)
[ 53.322474] ---[ end trace 055e991827ff9526 ]---
[ 54.143572] ieee80211 phy0: Mac80211 start BA 0e:02:25:5e:3f:62
[ 56.603699] ieee80211 phy0: Mac80211 start BA f0:18:98:6a:3d:e1
[ 56.960496] ieee80211 phy0: Mac80211 start BA 0e:02:25:5e:3f:62
[ 60.858648] ieee80211 phy1: Mac80211 start BA 8a:6e:e2:b1:1a:35
[ 67.692850] ieee80211 phy1: Mac80211 start BA 8a:6e:e2:b1:1a:35
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 mode, hardwired ethernet lan to a WRT3200ACM. WIFI: 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)..
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Tue Apr 20, 2021 2:28 Post subject:
If you're not going to post the entire trace in your post, then move the dmesg output to a text file and attach it. There might be certain information in the trace that you truncated that might be helpful. Thank you. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Upgraded from previous version 3200ACM no reset of settings.
On first boot and subsequent reboots, OpenVPN client was working, but not the previous configuration of DNSCRYPT. It got fixed by simply changing to another provider and then back to whichever.
Will update if there's any issues. _________________ Router: Linksys WRT3200ACM WLAN0 and 1 have same SSID
88W8964 802.11ac WLAN0 Mode AP VHT80 80MHz Mixed Mode Channel and Extension Channel Auto Extension LL-6
88W8964 802.11ac WLAN1 Mode AP 20 MHz Mixed Mode Channel Auto
SD8887 802.11ac disabled but visible on GUI and CLI
TX Power 18 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
Multi 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 256 (Default: 256 Clients)
Minimum Signal for authenticate -128
Minimum Signal for connection -128
Poll Time for signal lookup 10
Amount of allowed low signals 3
Wireless security is WPA2 Personal CCMP-128 only
QAM256 is on
Router Model Linksys WRT1900ACS
Firmware Version DD-WRT v3.0-r46395 std (04/19/21)
Kernel Version Linux 4.9.267 #2564 SMP Mon Apr 19 03:35:08 +07 2021 armv7l
I came from 46329
If anyone would like to volunteer their WiFi settings on thier router, my Windows Surface Pro 7 is dropping out and won't reconnect to either the 5 or 2.4.
Android (tablets etc) devices still connect and my hardwired Nvidia Shield Pro continues to work, just my W10Pro SP7
If anyone would like to volunteer their WiFi settings on thier router, my Windows Surface Pro 7 is dropping out and won't reconnect to either the 5 or 2.4.
Android (tablets etc) devices still connect and my hardwired Nvidia Shield Pro continues to work, just my W10Pro SP7
My Win10 PC (fully updated, FWIW) isn't having any connection issues at all. Wifi settings attached. _________________ 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 Apr 20, 2021 15:50; edited 7 times in total
Router/Version: WRT1900ACS v1 / r46395
File/Kernel: webflash via ssh curl / 4.9.267 #2564
Previous/Reset: r46069 / No
Mode/Status: Gateway, OpenVPN Client, FreeRADIUS Server / Uptime 22 min
Issues/Errors: After 12+ hours up on our ACSv2 test unit without any lasting issues, I felt confident enough to put this on our ACSv1 production unit. It's working great so far! No issues at all and both radios are working well from the get-go. Thank you!
EDIT: On the subject of Apple devices, I just read that all(?) Apple devices only respond to a DTIM interval of 3 or more to realize power savings as enforced by Apple code. So, if an AP radio has DTIM set to less than 3, apparently the Apple device only responds to the third beacon anyway (sometimes leading to loss of buffered data, possibly due to staleness rather than AP buffer capacity). The Apple devices might not care about the timing of the beacons themselves. I've had my beacon intervals at 300 ms for a while now, but DTIM of 2 or 1. Based on the news, I've just changed DTIM to 3, but left beacons at 300 for now. I guess if that introduces too much delay in response (e.g., 3 x 300 = 900 msec or 9/10th of a second) for incoming voip calls or the like, I'd probably now opt to reduce beacon (e.g., to 200 or potentially back to 100), but leave DTIM at 3 or more for better compatibility with Apple devices! A remaining issue is that we don't really know exactly how the Apple devices handle a DTIM that is not a multiple of 3, so I'm now using DTIM of exactly 3 to be safe. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Router/Version: WRT1900ACS v1 / r46395
File/Kernel: webflash via ssh curl / 4.9.267 #2564
Previous/Reset: r46069 / No
Mode/Status: Gateway, OpenVPN Client, FreeRADIUS Server / Uptime 22 min
Issues/Errors: After 12+ hours up on our ACSv2 test unit without any lasting issues, I felt confident enough to put this on our ACSv1 production unit. It's working great so far! No issues at all and both radios are working well from the get-go. Thank you!
EDIT: On the subject of Apple devices, I just read that all(?) Apple devices only respond to a DTIM interval of 3 or more to realize power savings as enforced by Apple code. So, if an AP radio has DTIM set to less than 3, apparently the Apple device only responds to the third beacon anyway (sometimes leading to loss of buffered data, possibly due to staleness rather than AP buffer capacity). The Apple devices might not care about the timing of the beacons themselves. I've had my beacon intervals at 300 ms for a while now, but DTIM of 2 or 1. Based on the news, I've just changed DTIM to 3, but left beacons at 300 for now. I guess if that introduces too much delay in response (e.g., 3 x 300 = 900 msec or 9/10th of a second) for incoming voip calls or the like, I'd probably now opt to reduce beacon (e.g., to 200 or potentially back to 100), but leave DTIM at 3 or more for better compatibility with Apple devices! A remaining issue is that we don't really know exactly how the Apple devices handle a DTIM that is not a multiple of 3, so I'm now using DTIM of exactly 3 to be safe.
If that was the issue then why would ditm=2 work perfectly on 44048 and why would this only effect new wrt’s?
If that was the issue then why would ditm=2 work perfectly on 44048 and why would this only effect new wrt’s?
I was just sharing a revelation. You've asked two questions. I don't have either answer, but if you want my best guesses:
1) "why would ditm=2 work perfectly on 44048"?
DTIM=2 probably worked on the old r44048 build because that build used the older Linksys/Marvel drivers. Frankly, DTIM= 1 and DTIM=2 worked well for me on r46069 as well, but my config and/or usage case was unfortunately the exception. I don't know why, but haven't ruled out that I'd happened to combine it with a beacon interval of 300.
2) "why would this only effect new wrt’s"?
I'm not sure what you mean, exactly, but my guess would be that it's probably related to the newer Linksys/Marvell drivers in the more recent builds and their varying unknown incompatibiliites with other components of the kernel (realistically unsolvable without source code, which Linksys/Marvell haven't provided).
P.S. - I didn't save or cite the article I first read, but a web search for the terms: apple dtim 3 yields some results. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
I was hopeful and tried BI=100 and DTIM=3 on this release, and it promptly issued the same process stack trace as I reported above. All my details are above. I went back to 46069, the last release that didn't have a process crash for me, and tried BI=100 and DTIM=3 - no luck, Apple devices started hanging, wife started bitching.... Back to 44048 with BI=100 and DTIM=2 for me. Wish I had better news.
I've got some bad news. I was on my PC and got disconnected from our ACSv2 (r46395) wifi. Couldn't reconnect, and couldn't reconnect to our ACSv1 (r46395) wifi either! In fact, all but one device got disconnected and none can reconnect wirelessly or wired to either router! SSH/telnet not working to either router either, even with manual IP config.
One device is still connected to the ACSv2 wifi 2.4G wpa2 vlan, but it's an old Android 7 device with low memory and no telnet client, so I'm still trying to figure out if I can use it to capture the log file. Webif requested password but never came up. Any suggestions?
In the meantime, I think I've got no choice but to reboot the ACSv1 and switch partitions on that one back to r46069. I'll leave the ACSv2 up and running r46395 until I've either captured a log or exhausted all practical possibilities.
EDIT: Attached is the log. _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Its beginning to become something of a fact for most, that if you have the WRT1900ACS V2, Apple devices in your infrastructure and flash anything later than build 46069, you will eventually run in to the kernel crashes.
I tested all builds after 46069 - but stopped before this build. It took time - and it seemed to me, I was just keeping sharing the logs of the same kinds of errors.
Is there any way of knowing - or at least get at hint, that it makes sense to start testing again.
I guess that means that developers have addressed this issue. I'm quite new as an active participant here - but should/could we add this as a bug. I see the "Apple loosing connection" epic is there, several times actually - but not these dramatic crashes. So how would we act to make that happen?
If you tell me "keep testing, it will be addressed" - then let me know, and I continue checking them out.
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Wed Apr 21, 2021 14:36 Post subject:
Someone needs to find a bona-fide working wi-fi settings configuration that works with Apple devices and is fully supported by the Marvell drivers and post a @#$%^&*! write-up. Because the settings everyone is using is obviously *not* working. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net