Notes: 1. SFE accelerated NAT is in 33006+ builds but only in kernel 3.2 and newer 2. 'KRACK' vulnerability fixes were completed in r33678 for Broadcom, including k26 (33655) & k24 (33656); use 33772 or later.
3. Bridge modes on k4.4 devices may sometimes work in some configurations in certain builds but are not supported by the bcmdhd driver. Use client or repeater instead as WDS doesn't work with Broadcom ARM either (see Issues below).
4. PBR/UDP with SFE working again since r40513 (see 6729)
4. CAKE scheduler added since r40547 (see 5796)
Issues, observations, and/or workarounds reported: 1.Trendnet 81*DRU models are missing factory-to-flash 2.DNScrypt is mostly only using v2 protocols now, but requires Golang that DD can't use:6246 3.WDS does not work on Broadcom ARM devices (only MIPS<->MIPS) 4.K2.6 builds are broken since 38253(?) (GUI issues):6538 5.VAPs not working at boot; workaround startup command:
sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas
This appears fixed (only for unbridged VAPs?) with r40564:40566...
Important: if reporting any issues, provide applicable info (GUI syslog, `dmesg`, `cat /var/log/messages`, etc.)
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
Template to copy (after "Code:") for posting issues, be sure to include the mode in use (gateway, AP, CB, etc.):
WARNING:This thread is to report on flashing this experimental test build, providing important info for both developers and users. Always state your hardware model, version, mode (e.g. Repeater) and SPECIFIC build (e.g. 33555_NEWD-2_K3.x_mega-nv64k.bin). Please avoid discussions and create a new thread to discuss specific problems or questions, as this thread is for reporting, not support. Posts may be deleted or moved to keep this thread manageable and useful. If you don't understand the risks or what to flash and how, with a means of recovery if it bricks, do NOT flash this experimental test build.
I have an Asus AC-3100. I am currently on:
Firmware: DD-WRT v3.0-r40527 std (08/04/19)
I tried the "Experimental Driver" version a few months ago which bricked my router (was able to restore using ASUS firmware loader). I tend to update once a month (more if I experience issues with a particular build) but follow these threads closely. So my question is: "What is the experimental driver?" My follow-up question is "should I continue to periodically try it or should I stick with the standard firmware?"
So far, BTW, the r40527 has been working well for the past month including significant UDP forwarding with SFE turned on.
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Wed Sep 04, 2019 17:06 Post subject:
PeteSL wrote:
I have an Asus AC-3100. I am currently on:
Firmware: DD-WRT v3.0-r40527 std (08/04/19)
I tried the "Experimental Driver" version a few months ago which bricked my router (was able to restore using ASUS firmware loader). I tend to update once a month (more if I experience issues with a particular build) but follow these threads closely. So my question is: "What is the experimental driver?" My follow-up question is "should I continue to periodically try it or should I stick with the standard firmware?"
So far, BTW, the r40527 has been working well for the past month including significant UDP forwarding with SFE turned on.
How often does BS release a stable version? or will it always be in Beta? reason I'm asking is I see BS releases quite often on here and I don't want to brick my only AC router in the house. I've been running KONG builds pretty regularly. I'm currently on the latest stable build for my EA6350 V2.
DD-WRT v3.0-r39960M kongac (06/08/19 )
any recommendations as far as a stable build ? Or are the Beta's pretty safe to flash? _________________ WRT54GL v1.1 - Flashed
Linksys WRT54G2 v1 - Flashed
EA6350 v2 - Flashed
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Thu Sep 05, 2019 3:07 Post subject:
For all intents and purposes, everything since v.24-sp2 (2008?) is beta, no matter who compiles it. That's what I have always understood. That being said, yes, <Kong>s supported devices always seemed to have 'stable' builds along the way, but he only pushed out builds at specific times in the development cycle. Anyway, the thing I had to learn the hard way is, always have a way to recover from a brick if you're going to flash custom firmware or firmware in general.
EDIT: What flyzipper said, below this post.
Last edited by kernel-panic69 on Thu Sep 05, 2019 3:10; edited 1 time in total
How often does BS release a stable version? or will it always be in Beta?
"stable"... there's no such designation for BS builds.
Addressing your primary concern... to avoid bricking your router, just avoid the urge to be one of the first to flash a new build. Truly misbehaving builds are usually flagged as such after a few reports in the forum.
RE: "are the Beta's pretty safe to flash"
As someone who flashes every build, I'd say they're definitely "pretty safe". They become "safer" with each positive user report. They become "safer still" when you see a positive user report for your device. They become "safest" when you see a positive report, on your hardware, with the same features that you've enabled.
How often does BS release a stable version? or will it always be in Beta?
"stable"... there's no such designation for BS builds.
Addressing your primary concern... to avoid bricking your router, just avoid the urge to be one of the first to flash a new build. Truly misbehaving builds are usually flagged as such after a few reports in the forum.
RE: "are the Beta's pretty safe to flash"
As someone who flashes every build, I'd say they're definitely "pretty safe". They become "safer" with each positive user report. They become "safer still" when you see a positive user report for your device. They become "safest" when you see a positive report, on your hardware, with the same features that you've enabled.
nicely written.
i have the means to de-brick but i do not have the time mostly as most of the devices i upgrade are operational and not for testing. so what i usually do is to wait until someone reports a successful flash for the same device.
if i am the first to flash, then i get my self ready to de-brick, no surprises.
Router Model: Linksys EA6700
Firmware Version: DD-WRT v3.0-r40900 std (09/04/19)
Kernel Version: Linux 4.4.190 #1136 SMP Wed Sep 4 06:03:54 +04 2019 armv7l
Uptime: 17:59
Mode: 2 X Gateway, 1 X AP
Status: working
Reset: no
Issues/Errors: Working well so far.
Router/Version: Asus RT-N18U
Firmware: DD-WRT v3.0-r40900 std (09/04/19)
Kernel: Linux 4.4.190 #1140 Wed Sep 4 06:22:19 +04 2019 armv7l
Mode: Gateway
Previous: r40750
Reset: No
Status: all essentials look good so far - dhcp, unbound, wifi, static leases, samba etc.