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: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.
A change introduced in version 386.9 that I reported a few days ago could lead to denial of service attacks.The "Enable WAN down browser redirect notice" option is broken in 386.9.
Reproduce:
InAdministration
->System
> turn offEnable WAN down browser redirect notice
InParental Controls
->Time Scheduling
-> Add a device
InSystem 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.
These two are completely unrelated. PCREDIRECT is created by the Parental Control code, not by the WAN down redirect setting.Can this be fixed in the Merlin firmware, or should I report it upstream? @RMerlin?
Thanks for your reply, as you said, here is my iptabes output: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.
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
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
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.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.
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.which is the problem, an unexpected redirection:
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.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.
You should try few times.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
I tried a few more times without success, just gonna leave it and buy a new router at some pointYou should try few times.
For my case it works after 3 or 4 time
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.I tried a few more times without success, just gonna leave it and buy a new router at some point
dhcp_staticlist
, custom_clientlist
, and wans_routing_rulelist
). A few reboots during/after the processMay 5 02:05:12 dropbear[2196]: Failed loading /etc/dropbear/dropbear_dss_host_key
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
DSS is deprecated, and disabled by @RMerlin. But it seems like theAny idea about why it is missing?
DROPBEAR_DSS 0
isn’t working to suppress checking for the host key.Thank you very much @dave14305.DSS is deprecated, and disabled by @RMerlin. But it seems like theDROPBEAR_DSS 0
isn’t working to suppress checking for the host key.
(....)
Don’t worry about it, you don’t want it anyway.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!