Posted: Tue Apr 13, 2021 9:11 Post subject: New Build - 04/13/2021 - r46329
[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.
Some days ago I rolled back to r44048 because each subsequent release has problem with wifi and some Apple devices (as you can read in many posts in this forum) for my WRT1900ACSv2.
But anyway I'd like to try new releases to find out if such bugs will be resolved, but upgragading to this new one from r44048 I get router reset to defaults, despite I opt for don't reset
As reconfiguring from scratch requires me hours, I think I will stalk every new build post to ask if Apple/wifi issues are still a matter
Router setup:
WRT1900ACS V2
Config retained from previous build
Configuration
Build 46329
OpenVPN - tap mode bridged
Wireguard - 11 clients
Wifi 5GHZ AC-Only WHT80
Wifi 2.4GHZ - Auto Channel NG-Mixed
Security WP2+AES on both radios
Port forwarding utilized for SMTP, IMAP, HTTP and HTTPS (IMAP on non-standard port)
Error Descriptions:
Httpd keeps crashing also on this build, shortly after boot (17 min uptime this time). Flashed and accessed only with Palemoon Portable. Same or similar kernel error as previous builds. Don't see any point in keep checking. Will try next on another kernel version bump. Last stable build for me is 46069 with kernel 4.9.261. That build runs stable without any issues.
Upgraded 3200ACM no reset from build 04-09-2021-r46316 and no issues, OpenVPN client and DNSCrypt is working.
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
Upgraded WRT1200AC v1's from r46316 to r46329 using Brave 1.10.91 (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.265 #2546 SMP Tue Apr 13 01:51:18 +07 2021 armv7l
No issues with a routine update session. Load times seem a little faster on this version.
Joined: 12 Dec 2007 Posts: 764 Location: Pittsburgh, PA USA
Posted: Tue Apr 13, 2021 13:03 Post subject:
Router/Version: WRT1900AC v1
File/Kernel: r46329 STD
Previous/Reset: No reset. Upgrade from 46316.
Mode/Status: Router, AP, OpenVPN and WireGuard server, DOT using Entware/Stubby on USB.
Issues/Errors: No issues. From 45592 through 46301, I had to do a full reset including a full reformat of the USB drive in order to upgrade or DNSMASQ would continously fail and restart. I've been able to upgrade to 46316 and 46329 without a reset. Not sure what changed, but it certainly makes life easier.
I have not seen any of the issues with Apple devices reported by other Marvell users, but we only have an iPhone XS. There's also an iPhone 7 that visits frequently and hasn't had an issue either. _________________ __________________________
Netgear R7800
DD-WRT v3.0 STD
Linksys WRT1900AC
DD-WRT v3.0 STD
Some days ago I rolled back to r44048 because each subsequent release has problem with wifi and some Apple devices (as you can read in many posts in this forum) for my WRT1900ACSv2.
But anyway I'd like to try new releases to find out if such bugs will be resolved, but upgragading to this new one from r44048 I get router reset to defaults, despite I opt for don't reset
As reconfiguring from scratch requires me hours, I think I will stalk every new build post to ask if Apple/wifi issues are still a matter
Yes, r44048 definitely can't use the same nvram variables or backup file because the radio designations (among others) were changed (e.g., from "ath" to "wlan") in an intervening build.
Fortunately, these have two flash partitions (although it's not really necesssary for this procedure, but does save the step of otherwise having to reflash r44048 every time)! Let's call the first flash area PRODUCTION (e.g., r44048) and the second flash area SANDBOX (e.g., r46316).
This procedure requires an nvram backup file of a reasonably recent build, but only for restoring to that very same build. What you have to do before flashing the latest beta release (e.g., 46329), is to:
first backup your r44048 nvram,
then erase nvram,
then switch to the SANDBOX partition (e.g., 46316),
then restore ITS corresponding same-build backup,
disconnect from Internet, etc.,
switch back to the PRODUCTION partition (not to run it just now but only to preserve r44048 so it doesn't have to be reflashed every time, since it always flashes over the partition that's NOT active),
and then flash r46329 or whatever into the SANDBOX partition WITHOUT RESET (ideally from telnet rather than webif, but webif does seem to work most of the time).
If the release still has Apple issues:
DO AN NVRAM BACKUP ANYWAY for the build since you might need it to perform the same procedure for the next release candidate,
optionally erase nvram,
then switch back to the PRODUCTION partition,
and finally restore a proper r44048 nvram backup file.
I've got a feeling I might get some pushback on the above, so let's just be clear that the only potentially kludgy part of this is switching back to the PRODUCTION (r44048) partition after restoring nvram while in the SANDBOX (e.g., r46316) partition. AFAIK, this step can only be avoided by treating the device as if it only had one partition and doing twice as much flashing, but I understand the concern. If anyone knows a way to do it from telnet without actually switching (that is, so r44048 never boots after restoring r46316's nvram backup), that'd be amazing!
EDIT: OH!!! I just read the Cliff Notes at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=311117 and found that it should be possible to flash the currently active partition from telnet after all, therefore avoiding the potentially kludgy part mentioned above:
Quote:
1. Use the ubootenv get boot_part command to learn the current Partition in use.
2. Use the ubootenv set boot_part (1 or 2 – the opposite number returned in Step 1) command.
3. DO NOT REBOOT
4. In DD-WRT GUI – Administration Tab – Firmware Upgrade Sub Tab: Upload the new ’dd-wrt webflash.bin’ file for your Router & Hardware Version. MAKE SURE THAT NO RESET IS SELECTED.
5. After Firmware Upgrade is finished the Router will automatically reboot.
(attributed to unknown author, so thank you!)
EDIT 2: That didn't quite solve it, but here's what did to avoid the kludge by using telnet/ssh (actually easier then webif, IMHO):
1) Assuming currently on r44048 in first linux partition, with r46316 in second linux2 partition, and want to test r46329 instead in that second linux2 partition:
Code:
cd /tmp
nvram backup nvram-backup-ACSv2-r44048.bin (and can copy it out using WinSCP, if needed)
ubootenv get boot_part
ubootenv set boot_part 2
nvram erase && reboot
nvram restore nvram-backup-ACSv2-r46316.bin (after copying it in with WinSCP, if needed)
nvram backup nvram-backup-ACSv2-r46329.bin (and copy out using WinSCP, if needed)
------------------------------
2. To go back to r44048 in first linux partition:
Code:
cd /tmp
nvram backup nvram-backup-ACSv2-r46329.bin (and copy out using WinSCP, if needed)
ubootenv set boot_part 1
nvram erase && reboot
nvram restore nvram-backup-ACSv2-r44048.bin (after copying it in with WinSCP, if needed)
reboot
EDIT: Changed "nvram erase" just before each instance of restore to "nvram erase && reboot" per blkt's suggestion. Thank you! _________________ 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 Fri Apr 16, 2021 17:36; edited 7 times in total
Use nvram erase && rebootafter switch boot into a build then manually configure, save and clean backup.
Agreed that that's preferred, but geps already said manual configuration was taking too much time for them to test each build. So I was trying to outline a faster solution...
Router/Version: WRT1900ACSv2 / DD-WRT v3.0-r46329 std (04/13/21)
File/Kernel: webflash / Linux 4.9.265 #2546 SMP Tue Apr 13 01:51:18 +07 2021 armv7l
Previous/Reset: r46316 / No
Mode/Status: Gateway, FreeRadius Server, OpenVPN client, separate WPA3-EAP and WPA2-EAP vlans. / Uptime 12:05
Issues/Errors: Working well except for Apple devices, thanks! After no issues for hours without any Apple devices, we connected an iPhone X, which promptly disconnected the first time but then reconnected and crashed the webif. I SSH'd in and captured the attached logs before rebooting (and relegating all Apple devices back to the r44048 router). _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros
Use nvram erase && rebootafter switch boot into a build then manually configure, save and clean backup.
o2bad455 wrote:
Agreed that that's preferred, but geps already said manual configuration was taking too much time for them to test each build. So I was trying to outline a faster solution...
Certainly not faster, needlessly complicated and wrong, nvram erase is pointless until after running a new build.
Reboot issues nvram commit. There is no avoiding manual configuration first time boot into a new environment.
With clean backup you can restore same build, and some cases need an nvram erase && reboot before restore.
You can reboot into recent build, restore, use quoted method overwriting same partition and boot into new build.
Last edited by blkt on Wed Apr 14, 2021 13:20; edited 2 times in total
Issues/Errors: Working well except for Apple devices, thanks! After no issues for hours without any Apple devices, we connected an iPhone X, which promptly disconnected the first time but then reconnected and crashed the webif. I SSH'd in and captured the attached logs before rebooting (and relegating all Apple devices back to the r44048 router).
The DMESG errors you are experiencing are very similar to mine - and for most the same. My theory so far is that it is kernel related. 4.9.265/264 crashes consistently on my router. I haven't thought of IOS-devices actually causing the crash, so I will at some time do one more attempt, shutting all those down, and see if newer versions stay stable then. Anyway - for me this does not happen on builds with kernel 4.9.261. You might want to try 46069. That is the last build with the 4.9.261 kernel, that is stable on my setup, regardless of wifi clients. Thought this might be helpful.
Certainly not faster, needlessly complicated and wrong, nvram erase is pointless until after running a new build.
Reboot issues nvram commit. There is no avoiding manual configuration first time boot into a new environment.
With clean backup you can restore same build, and some cases need an nvram erase && reboot before restore.
You can reboot into recent build, restore, use quoted method overwriting same partition and boot into new build.
Well, I beg to differ on it not being faster as I can get through it in 5-10 minutes, versus the hours for geps complex manual config, but all other points taken, thanks!
Zyxx wrote:
@o2bad455:
I have also one question:
According to your DMESG you are using VAP or some virtual WLAN?
WLAN 0.1 and 1.1 on br1 are the ones your devices connect to?
It's currently 3 VAPs with wlan0 on a first SSID, wlan1 on a second SSID, and both wlan0.1 and wlan1.1 on a third SSID. WPA3 devices connect to wlan0 or wlan1 on br0 with eth1, while WPA2 devices connect to wlan0.1 or wlan1.1 on br1 which is segregated from eth1. It's mainly intended for security (assuning WPA3-EAP is harder to crack than WPA2-EAP), but also helps me with diagnostics. I've tested Apple devices on all wlan's and the results are basically the same. In last night's test under r46329 that resulted in the posted logs, I believe my test PC (MAC ending 94) was on wlan0 and the Apple iPhone (MAC ending e7 for 2.4G or c9 for 5G) also attempted to connect on wlan0, both using WPA3-EAP. A nearly identical test scenario under r44048 resulted in no such errors, but I think I missed Apple testing on r46301 mentioned by pbphoto, and I've yet to try it on r46069 per Fonzi's suggestion - hopefully today.
EDIT: There's also an Apple iWatch in the local mix that may be complicating matters. It looks like it may form its own connection to an intermediary iPhone or iPad via Bluetooth, but then gets it's own IP at some point. I don't think it has any wifi of its own on board, but could be mistaken. The iWatch has a MAC ending 42, but rarely appears in router status and I've yet to notice it in any captured logs.
EDIT #2: Coincidentally, the Apple iPhone has last 3 bytes of 5G MAC identical to a PC of same user (i.e., a 1 in 4096 chance), and user reports more intermittent trouble with connections from that PC than any other. Is it possible that some buried code incorrectly assumes last 3 of MAC unique to every client connected to that router? Oh, and I just remembered that the user complained 5G was less stable than 2.4G, but this when in the same room within about two meters of router (i.e., close-range just the opposite of long-range scenario where that might be expected). _________________ My DD-WRT Routers:
Linksys WRT3200ACM - Marvell
Linksys WRT1900ACS - Marvell
Netgear R9000 - Atheros
Netgear R7000 - Broadcom
PC x86-64 VM - Atheros