[blkt]

[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 specific device recovery 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.

Downloads: (DD-WRT website) HTTPS & FTP (try another if a link doesn't work)

CLI Flash: 'cd /tmp' then 'wget {file URL}' (or 'curl -k {file URL} -o {file}') with http (not https) or ftp. Then 'write {file} linux'.

Repository: Trac SVN changelog since last build r44700 (GitHub mirror)

Notes:
• CVE-2019-14899 VPN fix (applicability depends on VPN setup) and GUI toggle. 6920, 6928, 6931, 6932 (WIP 7040)
• In-kernel Samba has been implemented this year and default min/max versions have changed 6954, 6957, with WSD support.
• VAP issue is fixed! For any Wireless Mode, create a VAP and both ath0/ath1 should now function properly.
• Local DNS option removed from Services->DNSMasq in changesets 43080 and 43081; ref: #7092
• DHCP and DNS help (English) updated in 43083; ref: #7091
• WireGuard 1.0.20200908 & Tools: PBR, Kill Switch, Inbound Firewall, Naming of Peers, Status, Key, Guides. Thanks BS & egc!
• OpenVPN Version 2.5.0

Issues:
• There may be remaining issues for Samba (for example NTFS), with frequent updates.

Important:
• If reporting issues provide applicable info: 'dmesg', 'cat /tmp/var/log/messages', syslog, serial output, strace, tcpdump etc.
• For firewall NAT or WAN issues provide 'iptables -vnL', 'iptables -t nat -vnL', 'iptables -t mangle -vnL' and the /tmp/.ipt file.
• Search existing SVN tickets before opening a new one. Before reporting, reset and manually setup (no nvram backup).
• Be sure to include operating and wireless modes (Gateway, AP, CB, etc.) along with relevant configuration information.

Example Template:

[Monza]

Upgraded WRT1200AC v1's from r44700 to r44715 using Brave Version 1.10.97 (64-bit) running on Linux Mint 20 OS.

Successful update and reboot. No reset, nothing disabled prior to update, uptime aproximatly 15 hrs, wired/wireless connected, vpn up immediately (Expressvpn). I do not use NAS. SFE is always disabled. OpenVPN client/DNSMasq, QoS with PIE always enabled.

Kernel Version Linux 4.9.241 #2174 SMP Tue Nov 3 02:44:43 +03 2020 armv7l

No issues. I do not have any Apple devices.

[Argenis]

WRT3200ACM upgraded while wiping via GUI.

So far so good, all three wireless interfaces are available, temperatures and CPU usage is great.

Will update if there's any issues.

[PIZZEDMEOFF]

been running great on my setup, it is pretty basic though

[oliver44]

Router Model Linksys WRT1900ACS v2
Connection Type PPP0E-OK +ipv6 DHCP with Prefix Delegation-ok
Port Range Forwarding-ok
Dnsmasq,DNSCrypt-ok

The web interface is stable and ipv6 is no longer lost:!:
The only problem remains the wifi part which is unstable in the speedtest, during the speed test I left a ping on the router and it is clear that the response time increases

in the link below you have all the information with the tests, to view an image in the original format y click on the image, click right on the image and choose the image viewing option!

http://s.go.ro/lgpaxi7b

[pbphoto]

Oliver44 - do you have QOS enabled? If not, try enabling QOS on the WAN port (HTB, Cake) with your upload and download speeds set to ~90% of your ISP's throughput. Don't set priorities on anything else - leave the rest of the page alone. I found that just having basic QOS enabled like this helps stabilize ping times when running multiple simultaneous speedtests.

[ho1Aetoo]

the ping test is between the PC and the router and QoS on the WAN will not help

atheros (ath10k) routers have fq_codel and AQL (Airtime Queue Limits) in the WLAN drivers

this works quite well
but it is also a bit dependent on the client and its driver

ping -i 0,2 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) Bytes Daten.
64 Bytes von 192.168.1.1: icmp_seq=1 ttl=64 Zeit=1.34 ms
64 Bytes von 192.168.1.1: icmp_seq=2 ttl=64 Zeit=1.53 ms
64 Bytes von 192.168.1.1: icmp_seq=3 ttl=64 Zeit=2.48 ms
64 Bytes von 192.168.1.1: icmp_seq=4 ttl=64 Zeit=1.15 ms
64 Bytes von 192.168.1.1: icmp_seq=5 ttl=64 Zeit=1.87 ms
64 Bytes von 192.168.1.1: icmp_seq=6 ttl=64 Zeit=7.65 ms
64 Bytes von 192.168.1.1: icmp_seq=7 ttl=64 Zeit=3.55 ms
64 Bytes von 192.168.1.1: icmp_seq=8 ttl=64 Zeit=2.00 ms
64 Bytes von 192.168.1.1: icmp_seq=9 ttl=64 Zeit=2.42 ms
64 Bytes von 192.168.1.1: icmp_seq=10 ttl=64 Zeit=3.08 ms
64 Bytes von 192.168.1.1: icmp_seq=11 ttl=64 Zeit=0.790 ms
64 Bytes von 192.168.1.1: icmp_seq=12 ttl=64 Zeit=0.951 ms
64 Bytes von 192.168.1.1: icmp_seq=13 ttl=64 Zeit=1.31 ms
64 Bytes von 192.168.1.1: icmp_seq=14 ttl=64 Zeit=1.87 ms
64 Bytes von 192.168.1.1: icmp_seq=15 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=16 ttl=64 Zeit=3.57 ms
64 Bytes von 192.168.1.1: icmp_seq=17 ttl=64 Zeit=4.38 ms
64 Bytes von 192.168.1.1: icmp_seq=18 ttl=64 Zeit=3.23 ms
64 Bytes von 192.168.1.1: icmp_seq=19 ttl=64 Zeit=2.18 ms
64 Bytes von 192.168.1.1: icmp_seq=20 ttl=64 Zeit=3.68 ms
64 Bytes von 192.168.1.1: icmp_seq=21 ttl=64 Zeit=2.17 ms
64 Bytes von 192.168.1.1: icmp_seq=22 ttl=64 Zeit=1.88 ms
64 Bytes von 192.168.1.1: icmp_seq=23 ttl=64 Zeit=1.45 ms
64 Bytes von 192.168.1.1: icmp_seq=24 ttl=64 Zeit=1.33 ms
64 Bytes von 192.168.1.1: icmp_seq=25 ttl=64 Zeit=2.00 ms
64 Bytes von 192.168.1.1: icmp_seq=26 ttl=64 Zeit=4.12 ms
64 Bytes von 192.168.1.1: icmp_seq=27 ttl=64 Zeit=3.94 ms
64 Bytes von 192.168.1.1: icmp_seq=28 ttl=64 Zeit=1.02 ms
64 Bytes von 192.168.1.1: icmp_seq=29 ttl=64 Zeit=2.78 ms
64 Bytes von 192.168.1.1: icmp_seq=30 ttl=64 Zeit=5.82 ms
64 Bytes von 192.168.1.1: icmp_seq=31 ttl=64 Zeit=4.75 ms
64 Bytes von 192.168.1.1: icmp_seq=32 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=33 ttl=64 Zeit=3.56 ms
64 Bytes von 192.168.1.1: icmp_seq=34 ttl=64 Zeit=6.10 ms
64 Bytes von 192.168.1.1: icmp_seq=35 ttl=64 Zeit=5.19 ms
64 Bytes von 192.168.1.1: icmp_seq=36 ttl=64 Zeit=4.81 ms
64 Bytes von 192.168.1.1: icmp_seq=37 ttl=64 Zeit=3.72 ms
64 Bytes von 192.168.1.1: icmp_seq=38 ttl=64 Zeit=2.63 ms
64 Bytes von 192.168.1.1: icmp_seq=39 ttl=64 Zeit=4.50 ms
64 Bytes von 192.168.1.1: icmp_seq=40 ttl=64 Zeit=4.56 ms
64 Bytes von 192.168.1.1: icmp_seq=41 ttl=64 Zeit=4.29 ms
64 Bytes von 192.168.1.1: icmp_seq=42 ttl=64 Zeit=3.56 ms
64 Bytes von 192.168.1.1: icmp_seq=43 ttl=64 Zeit=5.34 ms
64 Bytes von 192.168.1.1: icmp_seq=44 ttl=64 Zeit=5.33 ms
64 Bytes von 192.168.1.1: icmp_seq=45 ttl=64 Zeit=5.26 ms
64 Bytes von 192.168.1.1: icmp_seq=46 ttl=64 Zeit=3.53 ms
64 Bytes von 192.168.1.1: icmp_seq=47 ttl=64 Zeit=5.70 ms
64 Bytes von 192.168.1.1: icmp_seq=48 ttl=64 Zeit=11.2 ms
64 Bytes von 192.168.1.1: icmp_seq=49 ttl=64 Zeit=28.3 ms
64 Bytes von 192.168.1.1: icmp_seq=50 ttl=64 Zeit=3.25 ms
64 Bytes von 192.168.1.1: icmp_seq=51 ttl=64 Zeit=5.28 ms
64 Bytes von 192.168.1.1: icmp_seq=52 ttl=64 Zeit=4.57 ms
64 Bytes von 192.168.1.1: icmp_seq=53 ttl=64 Zeit=6.66 ms
64 Bytes von 192.168.1.1: icmp_seq=54 ttl=64 Zeit=5.03 ms
64 Bytes von 192.168.1.1: icmp_seq=55 ttl=64 Zeit=2.57 ms
64 Bytes von 192.168.1.1: icmp_seq=56 ttl=64 Zeit=3.47 ms
64 Bytes von 192.168.1.1: icmp_seq=57 ttl=64 Zeit=3.49 ms
64 Bytes von 192.168.1.1: icmp_seq=58 ttl=64 Zeit=4.98 ms
64 Bytes von 192.168.1.1: icmp_seq=59 ttl=64 Zeit=3.70 ms
64 Bytes von 192.168.1.1: icmp_seq=60 ttl=64 Zeit=5.91 ms
64 Bytes von 192.168.1.1: icmp_seq=61 ttl=64 Zeit=3.85 ms
64 Bytes von 192.168.1.1: icmp_seq=62 ttl=64 Zeit=4.36 ms
64 Bytes von 192.168.1.1: icmp_seq=63 ttl=64 Zeit=4.37 ms
64 Bytes von 192.168.1.1: icmp_seq=64 ttl=64 Zeit=6.61 ms
........
--- 192.168.1.1 ping statistics ---
143 Pakete übertragen, 143 empfangen, 0% Paketverlust, Zeit 28515ms
rtt min/avg/max/mdev = 0.790/4.479/28.313/3.007 ms

[SUM] 0.00-30.83 sec 2.71 GBytes 754 Mbits/sec receiver

for testing is recommended as in the example "ping -i 0,2"

2-3 seconds like in oliver44's test are very bad

[oliver44]

That ping becomes unstable only during the speedtest on the wifi side!
On the wire it behaves normally, i do not have active QOS!

@ho1Aetoo you should know that I found older versions with ddwrt where the ping during the speed test behaves normally on the wifi side....

[RCShadows]

Seems to be working well for my WRT3200ACM. I appreciate your effort as this router has been a PIA. As you can see I have been using DD-WRT for some time now with my membership length on the board.

Thank you again.

RCShadows

[PavelVD]

Router: Linksys WRT1900ACSv2
Firmware DD-WRT v3.0-r44715 std (11/03/20)
Kernel Linux 4.9.241 #2174 SMP Tue Nov 3 02:44:43 +03 2020 armv7l
Reset: No.
Mode:
QoS Enable: HTB, CAKE
Dnsmasq + SmartDNS
5 GHz: AP AC/N-Mixed, Wide NT40, Channel 149+Upper, Allow Channel Overlapping, Short Preamble, Short GI, Single User Beamforming.
2.4 GHz: AP NG-Mixed, Channel 5, Full 20 MHz, TurboQAM (QAM256) support, Short Preamble, Short GI.
Security: WPA2 Personal CCMP-128 (AES)
The "ap_max_inactivity 600" option improves the situation a little bit for iOS customers, but in general it's still bad. The customer falls off and can't connect for a long time.
NAS via USB:
/dev/sda - Block device, size 931.5GiB, Partition: 1-Ext4, 2-Ext4 , 3-swap.
ProFTPD Enable, But the fact is not used.
NFS Server: Shared the same partitions as in Samba.
Samba: Protocol Version SMB 2.10\SMB 3.11
It's possible that the problem with windows 10 customers' failure to connect to SMB resources is that Windows doesn't tolerate anonymous guest connections while the server does. In the event of a failure (or incorrect) authentication, the SMB server provides anonymous access without hesitation, and Windows "loses its head." It did not agree with that state of affairs and repeated the requests. The server has already "decided" - it's a guest - and gives an answer that does not suit Windows. Clinch is allowed by a reboot of samba.
Unfortunately I wasn't able to get the samba logs to see it. However, the situation seems more stable if the smb.conf make changes:

[PavelVD]

I'd like to show the developers my swollen log file in three days. Maybe when they see this, the gentlemen will feel the feeling and look: What can be done about it?
I want to note that during this period, Windows SMB customers have never lost their connection. I think it was affected by the disconnection of the guest access. (Previous post.)
Thank you for your attention!