Release Asuswrt-Merlin 386.9 is now available for AC models

[kernol]

Wonderfully stable on RT-AC86U [many thanks @RMerlin ] ... just hoping to get as good on my RT-AX86U's sometime in the future with version 388.3

 

[Wrkdbf_Guy]

Dirty update from 386.7.2 to 386.9. My NVRAM size is still way up there but it actually went *down* 35 bytes.

 

[rotareneg]

The Adaptive QOS -> Internet Speed page has been a bit problematic on 386.9 on my RT-AC66U B1. Sometimes it'll seem to finish the upload and download tests but then just sit for a while saying "Testing" before popping up a error saying "NOTICE Failed to complete the Internet speed test. Please check your Internet status at Network Map for more information and try again later." The connection didn't drop during the test, and nothing is recorded in the log. Not sure if it's a remote issue with the Ookla servers or what, but I figured I'd mention it in case anyone has noticed it too.

 

[bennor]

Not sure if it's a remote issue with the Ookla servers or what, but I figured I'd mention it in case anyone has noticed it too.

The router GUI speed test, for me, has been wonky since the Alpha 386.9 firmware. Commented about it early on in the Alpha thread:
https://www.snbforums.com/threads/a...c2900-rt-ac68u-and-rt-ac86u.82209/post-808255
Currently, for me, it either fails outright or hangs with "testing" usually on the upload test on a RT-AC68U.

 

[banger]

Works for me on an RT-AC68U.

 

[Yota]

The "Enable WAN down browser redirect notice" option is broken in 386.9.

Reproduce:
In Administration -> System > turn off Enable WAN down browser redirect notice
In Parental Controls -> Time Scheduling -> Add a device
In System Log -> Port Forwarding you will see that the forwarding rules used for redirection still exist.

In previous versions, when redirection was turned off, any WAN outage would not be redirected to the router's warning page.

A change introduced in version 386.9 that I reported a few days ago could lead to denial of service attacks.

I added a large number of IoT and smart devices that I don't trust to the deny list.

Because of the redirection, when IoT devices try to access the external network, they will be redirected to the router web page to display a warning. When IoT devices keep trying to access, it causes a denial of service attack on the router.

I've observed this attack lead to CPU consumption by the router's httpd process, and difficulty accessing web pages.

I've noticed that each of my smart switches and smart bulbs are making 20 requests per minute that are being redirected.

A dozen of these IoT devices is enough to make the router admin pages difficult to access, I guess if someone had dozens then the router would crash.


The workaround is to respect the option to turn off redirection, and when redirection is turned off, outbound traffic from blocked IoT devices is simply dropped, not redirected to the router itself.

Can this be fixed in the Merlin firmware, or should I report it upstream? @RMerlin?


EDIT:
No, I can't report this upstream because I don't think upstream has an option to turn off redirects.

Forgot to mention, I didn't enable guest network for these smart devices, because I can control them locally via LAN and bluetooth, I don't need to use them from outside. that's why I need to have these IoT devices in my LAN, and that's one of the reasons why I block them from accessing the internet.

 

[RMerlin]

Can this be fixed in the Merlin firmware, or should I report it upstream? @RMerlin?

These two are completely unrelated. PCREDIRECT is created by the Parental Control code, not by the WAN down redirect setting.

The WAN down redirect setting only sets the nat_redirect_rule nvram, and does not make any change to the firewall. If the WAN connection goes down, then the wanduck process will call a function to reconfigure iptables. If that setting is enabled (which is the stock firmware behaviour), then rules are created in the PREROUTING table to redirect web traffic to port 18017. There is no reference at all to the PCREDIRECT table in that code. And if the redirection is disabled, then the PREROUTING rules will not be generated.

So what you are seeing is entirely related to the Parental Control code. Asus has made major changes to that code over the past year, so I am not familiar at all with the new implementation. Why the redirection exists at all time I don't know, could be tied to a different set of iptable rules that will only hit that chain for specific MAC addresses. I would have to read through their whole parental control code to figure out the new behaviour, which isn't something I have the time to do at the moment. Feel free to have a peek, the code is mostly within router/rc/pc_block.c.

 

[Yota]

These two are completely unrelated. PCREDIRECT is created by the Parental Control code, not by the WAN down redirect setting.

The WAN down redirect setting only sets the nat_redirect_rule nvram, and does not make any change to the firewall. If the WAN connection goes down, then the wanduck process will call a function to reconfigure iptables. If that setting is enabled (which is the stock firmware behaviour), then rules are created in the PREROUTING table to redirect web traffic to port 18017. There is no reference at all to the PCREDIRECT table in that code. And if the redirection is disabled, then the PREROUTING rules will not be generated.

Thanks for your reply, as you said, here is my iptabes output:

This is the output of iptables -v -L -n --line-numbers, which is consistent with the previous version:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        1198     71888 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX


Chain WGNPControls (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       all  --  br1    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX

This is the output of iptables -v -t nat -L -n --line-numbers, which is the problem, an unexpected redirection:

Chain PCREDIRECT (17 references)
num   pkts bytes target     prot opt in     out     source               destination
1        1147 68820 DNAT       tcp  --  br0    *       0.0.0.0/0           !192.168.50.0/24          tcp dpt:80 MAC XX:XX:XX:XX:XX:XX to:192.168.50.1:18099

So what you are seeing is entirely related to the Parental Control code. Asus has made major changes to that code over the past year, so I am not familiar at all with the new implementation. Why the redirection exists at all time I don't know, could be tied to a different set of iptable rules that will only hit that chain for specific MAC addresses. I would have to read through their whole parental control code to figure out the new behaviour, which isn't something I have the time to do at the moment. Feel free to have a peek, the code is mostly within router/rc/pc_block.c.

Thanks again for a possible solution, it's beyond me. but I understand that you don't need to waste time troubleshooting this particular use case, since doing so benefits hardly anyone.

I guess my case is special because almost no one tries to block that many IoT devices, I will use custom script and iptables rules to achieve the functionality in the previous version, or I just use a firewall script to remove those NAT rules, I think maybe this is simpler, thank you.

 

[RMerlin]

which is the problem, an unexpected redirection:

I suspect this is by design, Asus probably wants to display a block page indicating why Internet access is being blocked rather than just silently dropping traffic. Since the mechanism already exists for Parental Control, they are probably reusing it, just adding blocked clients.

 

[Yota]

I suspect this is by design, Asus probably wants to display a block page indicating why Internet access is being blocked rather than just silently dropping traffic. Since the mechanism already exists for Parental Control, they are probably reusing it, just adding blocked clients.

It looks like this, should I report this to Asus? Since the stock firmware is still stuck on the older and unaffected GPL version, I'm not sure I should report this, and most people don't get denial of service attacks from their own devices.

Or could you please forward this to Asus?

 

[Phantomski]

Dirty update from 386.7-2 to 386.9. Apart from this small issue, everything norminal. Thanks RMerlin for keeping the oldies alive, much appreciated.

 

[nakti]

Something happend to skynet after latest firmware update?
It doesn't show any blocks when trying to choose Debug Option and show log as they appear.

But like keepass.info is blocked but when I turn off skynet the site is working fine. Or is the issue Skynet, but it worked fine before updating to latest firmware..

 

[ryannathans]

updating from 386.7-2 to 386.9

tried flashing the new firmware twice but both times the router still shows the old firmware version post-update, not cache related because i have tried different web browsers and machines

 

[diabolyk]

updating from 386.7-2 to 386.9

tried flashing the new firmware twice but both times the router still shows the old firmware version post-update, not cache related because i have tried different web browsers and machines

You should try few times.
For my case it works after 3 or 4 time

 

[ryannathans]

You should try few times.
For my case it works after 3 or 4 time

I tried a few more times without success, just gonna leave it and buy a new router at some point

 

[bennor]

I tried a few more times without success, just gonna leave it and buy a new router at some point

If you haven't tried doing so already, try a hard factory reset. Do a hard factory reset, do a minimum configuration so you can get into the GUI to do a flash. Flash the 386.9 firmware and see if it sticks after the router reboots. Make sure to disconnect any attached USB hard drive/device from the router before doing a firmware update and not to reattach it until after the initial router configuration post update to 386.9.

 

[pat2]

386.9 on RT-AC86U
WAN- DDNS
tried to deregister an hostname on site www.asus.com
received a ko and a warning to upgrade release.
Probably the issue related to the fact I did many dirty upgrades.
Not a big issue, only to report in case it is a bug.

 

[FernandoF]

Context:

• RT-AC86U, very clean upgrade from 386.7_2 to 386.9
• Several “WPS” and “Restore+Intialize” hard resets, both before and after the firmware upload
• All settings entered manually (except dhcp_staticlist, custom_clientlist, and wans_routing_rulelist). A few reboots during/after the process
• Nothing fancy, except perhaps Dual WAN with manual Load Balance ip rules
• SSH enabled (LAN only, non-standard port), DoT enabled (Strict)

Everything seems to work fine, as always – thanks @RMerlin! This time, however, there’s a new, reboot-persistent entry in my syslog:

May  5 02:05:12 dropbear[2196]: Failed loading /etc/dropbear/dropbear_dss_host_key

I’ve searched a little and found out these dropbear host key files come in a set of 4. I suppose they are used for authentication purposes. I have 3 of them, but the DSS one is indeed missing:

admin@RT-AC86U-xxxx/tmp/etc/dropbear# ls -l
lrwxrwxrwx    1 admin    root            34 May  5  2018 dropbear_ecdsa_host_key -> /jffs/.ssh/dropbear_ecdsa_host_key
lrwxrwxrwx    1 admin    root            36 May  5  2018 dropbear_ed25519_host_key -> /jffs/.ssh/dropbear_ed25519_host_key
lrwxrwxrwx    1 admin    root            32 May  5  2018 dropbear_rsa_host_key -> /jffs/.ssh/dropbear_rsa_host_key

admin@RT-AC86U-xxxx:/jffs/.ssh# ls -l
-rw-------    1 admin    root           140 May  5  2018 dropbear_ecdsa_host_key
-rw-------    1 admin    root            83 May  5  2018 dropbear_ed25519_host_key
-rw-------    1 admin    root           805 May  5  2018 dropbear_rsa_host_key

Questions:

• Could that missing DSS file create problems I haven’t detected yet?
• Any idea about why it is missing?
• Should I try to create it, or even go through a full reset process one more time?

Thanks in advance for your expertise, and please let me know if further details are needed.

 

[dave14305]

Any idea about why it is missing?

DSS is deprecated, and disabled by @RMerlin. But it seems like the DROPBEAR_DSS 0 isn’t working to suppress checking for the host key.

dropbear: disable DSS key support · RMerl/asuswrt-merlin.ng@4b7a3d8

Deprecated. While still mentionned as required by the RFC, some validation programs like PCI will flag this as a security issue.

github.com

Don’t worry about it, you don’t want it anyway.

EDIT: dropbear bug explained in the comments.

Force DROPBEAR_DSS when fuzzing · mkj/dropbear@787391e

Dropbear SSH. Contribute to mkj/dropbear development by creating an account on GitHub.

github.com

 

[FernandoF]

DSS is deprecated, and disabled by @RMerlin. But it seems like the DROPBEAR_DSS 0 isn’t working to suppress checking for the host key.
(....)
Don’t worry about it, you don’t want it anyway.

Thank you very much @dave14305.