[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[fastcx]

@RMerlin Thanks for your effort in continuing to improve on asus routers. I've loaded 382.3 alpha1 for AC68u, noticed these errors regarding applying QOS. Is it something related to my settings or it's something to be expected?

Spoiler: Error

Jan 14 03:46:36 rc_service: httpd 306:notify_rc restart_firewall
Jan 14 03:46:36 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)
Jan 14 03:46:46 rc_service: httpd 306:notify_rc restart_firewall
Jan 14 03:46:47 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)
Jan 14 03:47:18 rc_service: httpd 306:notify_rc restart_qos;restart_firewall
Jan 14 03:47:40 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 14 03:47:40 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 14 03:47:40 kernel: ioctl_iqos_op_config() fail!
Jan 14 03:47:40 kernel: ERR[qos_start:3344] QoS is already started!
Jan 14 03:47:40 kernel: ioctl_iqos_op_switch(1) fail!
Jan 14 03:47:44 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 14 03:47:44 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 14 03:47:44 kernel: ioctl_iqos_op_config() fail!
Jan 14 03:47:44 kernel: ERR[qos_start:3344] QoS is already started!
Jan 14 03:47:44 kernel: ioctl_iqos_op_switch(1) fail!
Jan 14 03:47:49 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)

AiProtection is on minus the DNSFilter.

 

[RMerlin]

@RMerlin Thanks for your effort in continuing to improve on asus routers. I've loaded 382.3 alpha1 for AC68u, noticed these errors regarding applying QOS. Is it something related to my settings or it's something to be expected?

Spoiler: Error

Jan 14 03:46:36 rc_service: httpd 306:notify_rc restart_firewall
Jan 14 03:46:36 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)
Jan 14 03:46:46 rc_service: httpd 306:notify_rc restart_firewall
Jan 14 03:46:47 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)
Jan 14 03:47:18 rc_service: httpd 306:notify_rc restart_qos;restart_firewall
Jan 14 03:47:40 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 14 03:47:40 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 14 03:47:40 kernel: ioctl_iqos_op_config() fail!
Jan 14 03:47:40 kernel: ERR[qos_start:3344] QoS is already started!
Jan 14 03:47:40 kernel: ioctl_iqos_op_switch(1) fail!
Jan 14 03:47:44 kernel: ERR[parse_qos_conf:932] Can't set new QoS conf while QoS is started!
Jan 14 03:47:44 kernel: ERR[ioctl_iqos_op_config:3592] parse qos_conf error!!
Jan 14 03:47:44 kernel: ioctl_iqos_op_config() fail!
Jan 14 03:47:44 kernel: ERR[qos_start:3344] QoS is already started!
Jan 14 03:47:44 kernel: ioctl_iqos_op_switch(1) fail!
Jan 14 03:47:49 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan500)

AiProtection is on minus the DNSFilter.

Same errors also appear in the stock firmware, and I have no idea what they mean.

 

[fastcx]

Same errors also appear in the stock firmware, and I have no idea what they mean.

Alright then Guess we'll have to wait for 384 source code...I didn't noticed these error in stock 384

 

[charlie2alpha]

Could just be the known Adaptive QoS issue that Asus only fixed later on. Try restarting QoS, and give it a good two minutes (it's much slower than with 380.xx at parsing the rules), then check again.

Tried restarting QoS, still no rules appear in the tc filters. Tried turning off AI Protection in case it was interfering, still nothing. What's interesting is that I saw on the logs when the router booted an entry going like "QoS: applying codel patch". So some part of your custom code was still triggered but no rules were created. It's possible invalid rules are created, is there a way I can use the debug switch you have in your tc script?

EDIT: Never mind, found how to use it, I get this:

ori: qdisc del dev ppp0 root
new: qdisc del dev ppp0 root

ori: qdisc del dev vlan1 eth1 eth2 root
new: qdisc del dev vlan1 eth1 eth2 root

ori: qdisc del dev ppp0 root
new: qdisc del dev ppp0 root

ori: qdisc del dev vlan1 eth1 eth2 root
new: qdisc del dev vlan1 eth1 eth2 root

ori: qdisc add dev vlan835 root pfifo
new: qdisc add dev vlan835 root pfifo

And nothing else after that.
The vlan835 interface is required for my connection to work (VDSL2). I configured it in the LAN -> IPTV page, not done via scripts or otherwise an it works fine in the 382.2 beta.

 

[bradbort]

I've been using trying out the new asus 384 build. It seems to fix several issues. The map now shows the correct clients. The GUI is quick. No stability issues in the cuople of days I've been trying it. The 5G signal is showing stronger at distance. I have no need of mesh for my house, so have not tried that. All on a 88U router.

If the 382.3 Frankenbuild works well, then it means I will be able to completely scrap the 382.2 release, issue a 382.3 release for the RT-AC56U,RT-AC68U and RT-AC3200, then move on to work on 384.4 for everything (but the AC56U and AC3200). That will be one less branch for me to worry about.

 

[Deleted member 22229]

The 5G signal is showing stronger at distance.

Good to see someone else noticed this as well. There is no doubt they pumped up the 5 Ghz signal output in the latest 384 build. I noticed it right away when my roku box in the far bedroom went from fair to excellent signal.

 

[hotsauce2007]

Any chance of use Authy to enter in the router using a 2factor authentication?

 

[DaveMishSr]

Well today is the last day of that "couple of days" so we might hope for a weekend release

He meant a couple a days before he could even look at the gpl. You either did not read his post in its entirety, or did not comprehend it if you did. It will be two months before the next official release. If it happens to be sooner it will be a pleasant surprise.

 

[WET]

RT-AC68U running 382.3 alpha1 up for 3 days all is well. One observation is I cannot get to GUI of AP (RT-N66U) or network Printer (HP 8600) from Client Status list under Network Map. Usually the IP address is underscored (hyperlink), it is not on this firmware version.

 

[DonnyJohnny]

RT-AC68U running 382.3 alpha1 up for 3 days all is well. One observation is I cannot get to GUI of AP (RT-N66U) or network Printer (HP 8600) from Client Status list under Network Map. Usually the IP address is underscored (hyperlink), it is not on this firmware version.

See if this helps,
https://www.snbforums.com/threads/382-2-beta1-cant-load-wireless-page-properly-solved.43051/

 

[Sanna1967]

One observation is I cannot get to GUI of AP (RT-N66U) or network Printer (HP 8600) from Client Status list under Network Map. Usually the IP address is underscored (hyperlink), it is not on this firmware version.

Same for my rt-n66 ( bridge mode ).The link was present on all the firmwares before this one.

 

[WET]

See if this helps,
https://www.snbforums.com/threads/382-2-beta1-cant-load-wireless-page-properly-solved.43051/

My wireless passwords are strictly alphanumeric.

 

[Sanna1967]

There is only one language that has a bug to load the "VPN Status" page correctly,probably because there is one more line "IPSec Server". French
IE,FFox, not tested with Chrome.

 

[brummygit]

My RT-AC68U up for 3 days on 382.3 Alpha 1 just suffered the same traffic slowdown reported for 382.2. A reboot has fixed it as normal.

I’m not using WI-FI on the router but am a QoS and AI-Protect user.

I know there is a theory that this is down to a Trend Micro closed source bug, but wanted to report that it continues on 382.3. For now I’ll schedule a daily reboot and wait to see what the future brings.


Sent from my iPhone using Tapatalk

 

[JGrana]

And AiMesh doing a lot of settings handling within closed source code, there's a high chance that it might not be fully compatible with all the changes I've done to settings. First thing that I can spot at a first glance at the code is the list of DHCP static leases. I store them in a different format to store hostnames - Asus doesn't. This can possibly break AiMesh support.

Indeed! I should have mentioned this.

I knew that I shouldn't attempt to migrate Johns9527's nvram restore to the router. I have a fairly long static DHCP list so I used the small "sort dhcp" utility to just save my static addresses.
When I first installed the stock firmware, I did the factory reset. After going through the initial setup on the AC88U it saw the AC68U node and even connected.
I then enabled SSH and restored just my dhcp_staticlist.
After a reboot the AC88U would never see the AC68U again. Suspecting the restore of the static leases, I did a factory reset on both and again AiMesh worked. About 6 of my clients migrated to the AC68U node. Nice.

For about 6 hours - then went blind again...clients dropped, it was ugly... So, back to this fine firmware!

Motto/lessons learned - if you want to go to stock ASUS firmware, don't even think about touching the nvram using scripts.
Be prepared to setup everything manually...

 

[hifiwifi]

Possible minor bug. 382.3_Alpha1 running on ASUS RT-AC1900P. When logged in, it won't log you out per the timer setting. It's happened twice now across different devices. I have it set to 20 minutes. Still logged in hours later. FYI.

 

[king006]

Since the 382.3 alpha 1 for RT-AC68U, http://rtr.ca/merlin/enable_dhcp_for_guests.sh no longer works?

The system.log says:

Jan 14 14:29:58 kernel: DROP IN=wl1.1 OUT=eth0 SRC=172.16.11.135 DST=195.121.1.34 LEN=62 TOS=0x00 PREC=0x00 TTL=63 ID=4887 DF PROTO=UDP SPT=41497 DPT=53 LEN=42 MARK=0x1f

He lost the connection to the DNS server. But why? I also no longer receive an IP address from the guest DHCP.

 

[Gregory Phillips]

I was having some weird issues with a single client on my network so I installed the 382.2_beta2 to see if it makes a difference.

 

[fastcx]

I noticed when AiProtection logged a lot of traffic in 2way IPS, it takes up around 200mb of memory, once u cleared the log in there memory usage is back to normal. Perhaps those that have AiProtection on and encountered slowdown, check that area and memory usage?

 

[king006]

Since the 382.3 alpha 1 for RT-AC68U, http://rtr.ca/merlin/enable_dhcp_for_guests.sh no longer works?

The system.log says:

Jan 14 14:29:58 kernel: DROP IN=wl1.1 OUT=eth0 SRC=172.16.11.135 DST=195.121.1.34 LEN=62 TOS=0x00 PREC=0x00 TTL=63 ID=4887 DF PROTO=UDP SPT=41497 DPT=53 LEN=42 MARK=0x1f

He lost the connection to the DNS server. But why? I also no longer receive an IP address from the guest DHCP.

@RMerlin,

This problem has been resolved with a downgrade to 382.2 beta 2. So the problem is in the new alpha 382.3! Do you want to find out and solve this problem? Thank you!