What's new

[alpha] Early preview builds for Asuswrt-Merlin 380.66

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Been using 380.66_alpha2 since 8th March on my AC3200. The performance is good, in fact I'd rate it as slightly better than 380.65. The router continued running for nearly 10 days without a restart at which point the Wi-Fi started acting a bit flaky with random signal drops. A reboot brought things back to normal.
 
Last edited:
Still haven't heard back about this one. This has been a problem since 380.65. Doesn't show traffic reception at all under Traffic Analyzer.

Not sure what I did to get this to happen, but reset to factory and reflashing/setup from scratch does not help.
notraffic1.jpg
notraffic2.jpg
 
Is anyone seeing any evidence of IP confusion with this build or the underlying ASUS firmware. The working hypothesis I'm having with Sonos about my roost problem (love those names), is that there is occasional IP confusion when the roost comes on line to send and alert, and it thinks its sending to an iphone, but it really ends up going to the sonos, or both (dup IPs). Its the closest to a theory we have, however implausable....
 
Is anyone seeing any evidence of IP confusion with this build or the underlying ASUS firmware. The working hypothesis I'm having with Sonos about my roost problem (love those names), is that there is occasional IP confusion when the roost comes on line to send and alert, and it thinks its sending to an iphone, but it really ends up going to the sonos, or both (dup IPs). Its the closest to a theory we have, however implausable....
Have you tried using a fix IP for the roost (i.e., outside of the DHCP range)?
 
Have you tried using a fix IP for the roost (i.e., outside of the DHCP range)?
Not yet, but It's not the roost's IP that would be the problem. It would have to be confusion between the iphone and the sonos, with the roost ending up sending communications to both....

Before going down the rout though, I'm just trying to see if anyone has seen any evidence of IP confustion on thsi build of firmware. Frankly, its a very issolated case. The universe of users who have both this router, use this alpha build of firmware, and have a roost may be limited to ...me and maybe a few others? Or maybe just me....For now, I've changed the alert parameters so i don't get woken up at 1am again...I hope....
 
After an initial false start this build now seems to be running fine on my RT-AC3200 after entering the following as recommended in the 360.65 thread;

nvram set stop_gmac3=1
nvram commit

Reboot
 
After an initial false start this build now seems to be running fine on my RT-AC3200 after entering the following as recommended in the 360.65 thread;

nvram set stop_gmac3=1
nvram commit

Reboot
Thanks for validating it also works on .66
 
Anyone with an N66 using DLNA successfully with this build ? On .65, a few people with N66 and possibly AC66 routers (with MIPS or non-MIPS CPUs ??) had issues.
 
I just bought RT-AC68U. In this thread, i read that there are problems with ip bandwidth limiter and qos are broken. Is there any plan to make it work? If there will be any changes made to the ip limiter it would be nice to have an option to assign ip limiter to unlisted MAC / IP's (all ip's that would connect to router and are not assigned in limiter would share defined bandwidth).
 
I just bought RT-AC68U. In this thread, i read that there are problems with ip bandwidth limiter and qos are broken. Is there any plan to make it work? If there will be any changes made to the ip limiter it would be nice to have an option to assign ip limiter to unlisted MAC / IP's (all ip's that would connect to router and are not assigned in limiter would share defined bandwidth).

Only Traditional QoS is broken. Adaptive QoS works just fine. So, if you need QoS use that, and you will be fine.
 
Only Traditional QoS is broken. Adaptive QoS works just fine. So, if you need QoS use that, and you will be fine.
Thanks much for the reminder. Went into my AC68u and set Adaptive QOS to optimize Web Browsing, with manual speed limits set to match the physical limits of my cable internet provider.

Now DSL Reports http://www.dslreports.com/speedtest gives me an "A" rating on all three measures of internet connection quality. In other words, "bufferbloat" completely gone (my old bufferbloat rating without QOS was "F" with frequent pauses during tests of half a second or more).
 
With this alpha my IPv6 block from my ISP is not stable anymore. With 380.65.2 everything is working fine, but with the alpha the connection is dropped after some time.
 
After an initial false start this build now seems to be running fine on my RT-AC3200 after entering the following as recommended in the 360.65 thread;

nvram set stop_gmac3=1
nvram commit

Reboot

Would you mind explaining what these do? Link to the discussion would be helpful. TiA
 
My ipv6 to clients from RT-AC87U on 380.66 was unstable. I was using .66 alpha for three weeks and decided to go back to 65_2 for ipv6 stability. Is anybody still experiencing routed ipv6 to clients issues?
 
AC66U B1 with AC68U 380.66 alpha2 firmware. Script to start swap would not run. I could start the swap on drive in USB 3 front port from a terminal but it would not start on a reboot. Also had USB 3 problems with the latest Asus firmware.
 
AC88U new, out of the box flashed with .66 alpha.
After flash cleared NVRAM by factory restore and then setup from scratch.
OpenVPN server and client, QOS, port fw ... no scripts or advanced stuff.
noticed until now:
1. web UI afer some time gets sluggish in Chrome, especially index.asp (switched to Mozilla - no problem)
2. some weird behaviour with Adaptive QoS set to manual:
a) if bandwidth is set right (as it supposed to be), I get max DL speed without VPN client ON, with VPN ON speed is capped as UL bandwidth limit
b) if switched UL & DL bandwidth numbers then VPN speed is OK but without VPN speed is capped to UL bandwidth limit
 
Not sure if this isn't browser related, but when clicking on the \WebUI\USB Application\Media Server\Network Place (Samba) Share / Cloud Disk link, the browser (Firefox 52.0) keeps opening browser tabs for the same link unless the browser is shutdown.

Browser.png
 
Refreshed builds are available.

Code:
c52b2b2 openvpn: only mark traffic if CTF is enabled
b870074 rc: re-enable code that causes some router models to reboot if one of the radios is disabled at boot time, and set limit it to 1 reboot instead of 3 like it originally did (compromise for issue #1284)
4cd4e93 openvpn: made log verbosity configuration specific to each server/client instances (to be in line with GPL 382)
3ffe814 openvpn: upgrade bundled LZ4 library to 1.7.5
a018d83 openvpn: Upgrade to 2.4.1
0b95bda openvpn: replace deprecated ns-cert-type with remote-cert-tls
712bd9d Updated documentation
662c845 shared: explicitely check for gmac3 being enabled when retrieving wan/lan MAC, rather than checking if it's not force-stopped.
87dc136 rc: initialize gmac3 nvram as disabled on SDK 7.x, else code portions specific to SDK 7.x might break - for instance, it broke various things with the RT-AC3200.
74cc0ea Merge pull request #1273 from blackfuel/torfirewall
24f455b openvpn: Initial support for instance-specific log verbosity; don't enable multihome support as OpenVPN cannot support dual-stack (IPv4/IPv6) environments with older kernels when this option is enabled.  (Backports from 382_9736)
5e8cb44 Disable airtime fairness by default - too many compatibility issues at this time
ad30067 Updated documentation
1eb4eef Merge pull request #1279 from umerov1999/patch-2
0e01ecd Update configure.ac
8e1f754 Updated documentation
4f4fcc5 httpd: temporary patch to protect against CVE-2017-6549 (while we wait for a proper fix from Asus)
ae4382b webui: fix array index used to fill up the port forward table
b616bc5 Tor firewall: inserting NAT rules at bottom is safer
 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top