What's new

[Release 384/NG] Asuswrt-Merlin 384.4 is now available

  • 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.
So as it turns out, just having a nat-start script is whats breaking it. I entered in the following commands in order to test the script.

Code:
iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE

iptables -I FORWARD -i tun11 -p udp -d 192.168.x.x --dport 61xxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.x.x --dport 61xxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 61xxx -j DNAT --to-destination 192.168.x.x
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 61xxx -j DNAT --to-destination 192.168.x.x

After doing so, the port successfully tested open. THis told me the script was fine. So I used the same commands and created the nat-start script. Upon reboot, it broke the router. I verified the commands were in there by SSHing into the router and listing all of the iptable rules. The ones from the script were there.

Any thoughts guys?
After editing the nat-start script run "dos2unix /jffs/scripts/nat-start" without the quotes and test again.
 
Try disabling NAT acceleration, i had mine set to auto and was experiencing all sorts of problems, I then set to disabled and it has been working fine since. I have ac68u.
Thank you for your feedback :)

Please correct me if I'm wrong but since I'm on 1Gb ISP, disabling NAT acceleration can cause more issues? From my understanding if you are on fast ISP +200mb service you need to have NAT accelartion enabled. Like I said before, I've never had this issue when I was on 380.69, so there must be an issue with Parental Controls - Time Scheduling (AiProtection).

Did you have this problem with 384.4_0? Maybe it is worth trying to downgrade?
 
All wireless interfaces were down. Started them up via the gui (professional) and all was working again. Downgraded to 384.4.

Errors (there was another error regarding a write error, though i didnt manage to capture it at the time):

kernel: ERROR fwder_init: fwd_cpumap nvram not present, using default
kernel: *** ERROR: [tdts_shell_ioctl_sig_op_load:95] tdts_core_rule_parsing_trf_load() fail!


The only other module i installed on the ac5300 was dnscrypt: https://github.com/thuantran/dnscrypt-asuswrt-installer

1 last thing to note here is that i have set the wireless settings as per this great new guide and i have already noticed a performance increase (less lag). It might be that we were putting the device under to much load last time and disabling unneeded features etc will cause less possibility of wireless crashing again:
https://www.snbforums.com/threads/rt-ac5300-performance-security-guide.45710/
 
Thank you for your feedback :)

Please correct me if I'm wrong but since I'm on 1Gb ISP, disabling NAT acceleration can cause more issues? From my understanding if you are on fast ISP +200mb service you need to have NAT accelartion enabled. Like I said before, I've never had this issue when I was on 380.69, so there must be an issue with Parental Controls - Time Scheduling (AiProtection).

Did you have this problem with 384.4_0? Maybe it is worth trying to downgrade?

My connection speed is 80mbps so I’m unsure how disabling NAT acceleration will affect a faster connection speed but I had read up that parental controls/time scheduling needs to have NAT acceleration disabled for it to work properly.
I didn’t have any problems before upgrading the firmware to 384.4_2 but I have seen other posts where they have had issues after upgrading to 384.4
The only concern I have is that when I disabled NAT acceleration when I first upgraded to 384.4 I found core 2 processor was maxing out at 100% and I could only stop it by unplugging the router.
So far with 384.4_2 I have not had that problem.
If I have any issues I will post them here.
Hope It helps with your issues.
 
Can post here aswell.

Was able to downgrade my AC3200 to 380.69_2 (Yes its possible), and my low Netflix bitrate on my LG TV is back to normal!. So happy to be off this buggy 382/384 FW!!
 
Can post here aswell.

Was able to downgrade my AC3200 to 380.69_2 (Yes its possible), and my low Netflix bitrate on my LG TV is back to normal!. So happy to be off this buggy 382/384 FW!!
Thought this was impossible? Glad you’re all good now, Simkin.
 
Thought this was impossible? Glad you’re all good now, Simkin.

Apparently it is possible, Thanks to GameDr04!

In case you're considering doing the same thing, here's my success story (I'm sure know you SNB folks already know all this but the random Googler who's stuck may not):
• give your adapter a manual IP of 192.168.1.9
• power off the router
• power on while holding WDS button to clear NVRAM (hold onto that sucker for a good 30 seconds)
• let go of WDS and wait until you get the initial setup screen at 192.168.1.1 (could take up to 5 minutes)
• power off the router
• hold down reset button and power on router while continuing to hold reset button for about 30 seconds - this gives you the ASUSTEK CFE miniWeb interface ("rescue mode"?)
• flash the downgraded firmware
• don't restore settings; that's never a good idea anyway
• pray

Here's the thing: Merlin said that ASUS said downgrading from 382/384 to 380 on AC3200 is not supported due to bootloader size mismatch. So do this at your own risk.


My device did not boot up properly after clear nvram, i tried several times, so i went directly to holding down reset button and after that i was able to go into the Asus log in, (i did not get the ASUSTEK CFE miniWEB) and flashed the 380 FW.

Device got into a bootloop, reset again and now its fine!
 
From my understanding if you are on fast ISP +200mb service you need to have NAT accelartion enabled. Like I said before, I've never had this issue when I was on 380.69, so there must be an issue with Parental Controls - Time Scheduling (AiProtection).

Personally I consider the info/hints in the GUI ambiguous? o_O

upload_2018-3-30_16-23-47.png


So I suspect that the Parental Controls Time Schedules do work with 'NAT Acceleration=Auto' but may not always be checked/applied in a timely manner?

However, if you check the GUI hint for the 'NAT Acceleration' state, it seems to imply that the firmware will alter this as required? - although not sure I've ever seen this...

upload_2018-3-30_16-25-35.png


So whilst performing diagnostics, then @D_Day's advice is advised Disable NAT Acceleration

You should then dump the Parental Control rules in detail for the MAC address that is being incorrectly blocked
e.g.
Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX

Chain PControls (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
2        0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0          
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Now for the debugging example above with three ALLOW periods, (if you have enabled NSFW rules, then this will complicate matters :-( ) you could try adding a logging rule to try and confirm precisely when the MAC is incorrectly blocked during the ALLOW period(s):
e.g. insert a debugging rule before the DROP rule (position 4 in the example above) for the MAC to be debugged
Code:
iptables -I FORWARD 4 -i br0 -m mac --mac-source XX:XX:XX:XX:XX:XX -j LOG --log-prefix "PControls BLOCK "
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX LOG flags 0 level 4 prefix "PControls BLOCK "
5        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX
NOTE: You could use a cron script to regularly dump the Parental Controls Schedule rules to ensure that they are not getting corrupted.
 
In access point mode at guest network there is no intranet option to restrict guest clients accessing intranet. Then why exist guest network in ap mode?
Can I solve this problem somehow, to have real guest wifi on ap (disable intranet)? (the main router is an ac87u, the ap is an ac56u (both with 384.4_2 merlin fw)

(I know asuswrt doesn't know vlan, except brt-ac828)
Anybody?
 
Last edited:
Personally I consider the info/hints in the GUI ambiguous? o_O

View attachment 12537

So I suspect that the Parental Controls Time Schedules do work with 'NAT Acceleration=Auto' but may not always be checked/applied in a timely manner?

However, if you check the GUI hint for the 'NAT Acceleration' state, it seems to imply that the firmware will alter this as required? - although not sure I've ever seen this...

View attachment 12538

So whilst performing diagnostics, then @D_Day's advice is advised Disable NAT Acceleration

You should then dump the Parental Control rules in detail for the MAC address that is being incorrectly blocked
e.g.
Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX

Chain PControls (2 references)
num   pkts bytes target     prot opt in     out     source               destination       
1        0     0 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
2        0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0         
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Now for the debugging example above with three ALLOW periods, (if you have enabled NSFW rules, then this will complicate matters :-( ) you could try adding a logging rule to try and confirm precisely when the MAC is incorrectly blocked during the ALLOW period(s):
e.g. insert a debugging rule before the DROP rule (position 4 in the example above) for the MAC to be debugged
Code:
iptables -I FORWARD 4 -i br0 -m mac --mac-source XX:XX:XX:XX:XX:XX -j LOG --log-prefix "PControls BLOCK "
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX LOG flags 0 level 4 prefix "PControls BLOCK "
5        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX
NOTE: You could use a cron script to regularly dump the Parental Controls Schedule rules to ensure that they are not getting corrupted.

This is where I read that parental controls/time scheduling is incompatible with NAT acceleration and CTF cut through.
https://routerguide.net/nat-acceleration-on-or-off/
It looks like there is a trade off though, it just depends what is more important to the individual.
 
After editing the nat-start script run "dos2unix /jffs/scripts/nat-start" without the quotes and test again.

Thanks for the suggestion, unfortunately, I have the same result. I even went in and deleted the script and recreated from the cmd.
 
Thank you very much for your detailed feedback. I tried to disabled NAT acceleration, and my up/down speeds were decreased to 315/30 from 910/40.
I understand all this, but I don't remember I've experienced this sort of problem with AiProtection/schedule prior to this firmware release.
Perhaps I was just lucky or I haven't noticed.

Personally I consider the info/hints in the GUI ambiguous? o_O

View attachment 12537

So I suspect that the Parental Controls Time Schedules do work with 'NAT Acceleration=Auto' but may not always be checked/applied in a timely manner?

However, if you check the GUI hint for the 'NAT Acceleration' state, it seems to imply that the firmware will alter this as required? - although not sure I've ever seen this...

View attachment 12538

So whilst performing diagnostics, then @D_Day's advice is advised Disable NAT Acceleration

You should then dump the Parental Control rules in detail for the MAC address that is being incorrectly blocked
e.g.
Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX

Chain PControls (2 references)
num   pkts bytes target     prot opt in     out     source               destination       
1        0     0 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
2        0     0 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0         
3        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
Now for the debugging example above with three ALLOW periods, (if you have enabled NSFW rules, then this will complicate matters :-( ) you could try adding a logging rule to try and confirm precisely when the MAC is incorrectly blocked during the ALLOW period(s):
e.g. insert a debugging rule before the DROP rule (position 4 in the example above) for the MAC to be debugged
Code:
iptables -I FORWARD 4 -i br0 -m mac --mac-source XX:XX:XX:XX:XX:XX -j LOG --log-prefix "PControls BLOCK "
Chain FORWARD (policy DROP 0 packets, 0 bytes)
1        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 07:00:00 to 10:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
2        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 14:00:00 to 17:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
3        0     0 PControls  all  --  br0    *       0.0.0.0/0            0.0.0.0/0            TIME from 20:00:00 to 21:00:00 on Fri MAC XX:XX:XX:XX:XX:XX
4        0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX LOG flags 0 level 4 prefix "PControls BLOCK "
5        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC XX:XX:XX:XX:XX:XX
NOTE: You could use a cron script to regularly dump the Parental Controls Schedule rules to ensure that they are not getting corrupted.
 
One question I have, is now my login will not time out. I did a default and setup as new on 4_2 This is something new. I have tried changing the timeout to something other than default and it has no effect. Same Computer, no updates, etc since running 384.4 where I recall it working as desired.

I'm curious if anyone else has experienced this behavior?

* So far all my other GUI and VPN issue have been resolved by simply disabling IPSec, I’ll give it a another go next build.

Edit: NVM, dumb user error. :mad:
 
Last edited:
I should have taken a screenshot......
I went to log into the admin page today & everything is suddenly in Chinese, including the login page. Now I did not make any changes. Currently have FW: 380.69. I will be updating this soon but wondering if I should be concerned & how would I check the integrity of the router?
 
Last edited by a moderator:
Running 384.4_2 on RT-AC86U, everything is fine. Thank you Eric!
 
Upgraded to 384.4_2 from 384.4 on RT-AC88U, everything fine.
 
Thanks @kvic your script to generate webui cert works real nice. I bookmarked the site.:p
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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