Release ASUS RT-AC68U Firmware version 3.0.0.4.386_51668 (2023/11/30 )

[Tech9]

I'm checking something on this firmware and found Firewall, Network Services doesn't save changes.

This was a bug in 388 firmware for NHD models for quite some time, but fixed now. This thing here:

No one noticed it's not working? The router is RT-AC1900P, runs the same firmware.

 

[wouterv]

I am not using that, but tried to add a table entry: can give input and use the + to bring my input one line down, after Apply and the few seconds action spinner, the table reverted as empty, system log reports the firewall is restarted.
is there a SSH command to see if there really is no firewall rule entry?

 

[dave14305]

is there a SSH command to see if there really is no firewall rule entry?

nvram get filter_lwlist

Many of the reported issues were with using a CIDR address, which wasn’t supported yet. What was your test?

 

[Tech9]

the table reverted as empty

Indeed and the changes are not applied. This bug was present on older versions 388 firmware. I was surprised this firmware still has it. A bit disappointing given the fact RT-AC68U is perhaps on one of the last firmware updates before landing on EoL list. I reported it to Asus in Feedback. Every time - something fixed and something else broken.

Many of the reported issues were with using a CIDR address

No, this exact issue:

Release - ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.23285 (15-05-2023)

AiMesh advertisements claim compatibility between anything AiMesh capable, but how well the mix is going to work is up to you to discover.

www.snbforums.com

 

[wouterv]

nvram get filter_lwlist

Many of the reported issues were with using a CIDR address, which wasn’t supported yet. What was your test?

I did enter a Source Port Range (1024), Destination IP (192.168.1.52), Destination Port Range (1024), Protocol default TCP.

 

[bennor]

This was a bug in 388 firmware for NHD models for quite some time, but fixed now. This thing here:

Not sure it was fixed in the Asus 388 firmware, but RMerlin did a temporary workaround in 3004.388.5 (2-Dec-2023). See 388 change log.

- FIXED: CIDR-formatted addresses were rejected on the Network
Filter page. Implemented temporary workaround.

It doesn't appear that this temporary workaround was applied (yet) to the 386 Merlin firmware per the 386 change log if the Asus 386 firmware is also now affected by the same or similar CIDR formatted address issue.

 

[Tech9]

Not sure it was fixed in the Asus 388 firmware

Fixed with the last firmware update, at least on RT-AX86U.

In the meantime I found more "classic" Asuswrt bugs in this 486_51668 firmware:
- Traditional QoS and Bandwidth Limiter are broken with IPv6 enabled, Native configuration.
- Asus DDNS service offers IPv6, but errors out if IPv6 is also enabled on the DDNS settings.

Current stock firmware situation with this router is:
- roll back firmware to get the above working - get DCD constantly crashing
- update firmware to fix DCD crashing - get old known firmware issues fixed for other models

If not fixed and the router is EoL'd in this state - still usable hardware killed by firmware.

 

[Tech9]

Guys, is this one creating some trouble?

I want to give this router to someone else, but I don't want to support it.

Feb 11 03:04:27 kernel: asd/179: potentially unexpected fatal signal 11.
Feb 11 03:04:27 kernel: Pid: 179, comm:                  asd
Feb 11 03:04:27 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Feb 11 03:04:27 kernel: PC is at 0x404ec7a8
Feb 11 03:04:27 kernel: LR is at 0x404e7050
Feb 11 03:04:27 kernel: pc : [<404ec7a8>]    lr : [<404e7050>]    psr: a0000010
Feb 11 03:04:27 kernel: sp : bec96990  ip : 4051bda0  fp : 00000000
Feb 11 03:04:27 kernel: r10: 0000001c  r9 : bec96b18  r8 : 00000020
Feb 11 03:04:27 kernel: r7 : 00000000  r6 : 00000163  r5 : 0000000b  r4 : bec96a10
Feb 11 03:04:27 kernel: r3 : 00000163  r2 : 00000000  r1 : ffffffff  r0 : 00000163
Feb 11 03:04:27 kernel: Flags: NzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Feb 11 03:04:27 kernel: Control: 10c53c7d  Table: 9efd004a  DAC: 00000015
Feb 11 03:04:33 rc_service: service 8703:notify_rc restart_firewall

Left the router running overnight, this error is present in logs few times already.

Thank you.

 

[RMerlin]

Guys, is this one creating some trouble?

Can't speak for stock firmware, but on my dev RT-AC66U_B1 running my firmware there was no asd crash in nearly three months:

admin@rtac66b1:/tmp/home/root# cat /tmp/syslog.log | grep asd
admin@rtac66b1:/tmp/home/root# uptime
 14:06:57 up 79 days, 16:47,  load average: 0.05, 0.13, 0.11

I do use different asd signatures than stock firmware however.

 

[Tech9]

I need stock on this router. The person wants to watch YouTube, Instagram, etc. traffic to some kids devices. Your firmware switches the default tab for Traffic Analyzer and this router has Traffic Monitor bug. The one with spikes, I see them coming already. The reason I wanted to block QUIC so it shows YouTube in Traffic Analyzer and not QUIC.

Sorry, a bit off topic @RMerlin - is there a way to add firewall rules manually and make them survive a reboot? Need to block 80/UDP and 443/UDP on it.

The whole point here is to save the device and not throw it away. I'm getting 800Mbps wired and 400Mbps wireless with TM enabled. It's good for the purpose.

The Traffic Monitor bug:

YouTube with QUIC in Traffic Analyzer:

YouTube without QUIC in Traffic Analyzer:

 

[RMerlin]

Sorry, a bit off topic @RMerlin - is there a way to add firewall rules manually and make them survive a reboot? Need to block 80/UDP and 443/UDP on it.

Firewall -> Network Service Filter page.

 

[Tech9]

Firewall -> Network Service Filter page.

The GUI page has a problem in this firmware - not saving the data. Not only GUI bug, rules not working after Apply.

Trying to find a way to do it manually. Revert the firmware, save the rules, update the firmware is the plan for now.

/jffs/nvram/filter_lwlist is empty by default. With no reset the changes after firmware update must be still there, correct?

This firmware came after the bug was fixed in 388 branch. I wasn't expecting to see again in 386 branch.

 

[Tech9]

The manual solution from @dave14305 with the ports above as an example:

nvram set filter_lwlist="<>>>443>UDP<>>>80>UDP"
nvram commit
service restart_firewall

The result in GUI:

@dave14305

 

[RMerlin]

/jffs/nvram/filter_lwlist is empty by default. With no reset the changes after firmware update must be still there, correct?

Yes, unless it fails a validation step at load time, and the firmware then clears it.

I remember one of the issues was in the validation done when submitting to the web server, I don't remember if it was also validated at load time.

Reboot and make sure the iptables entries are there.

 

[Tech9]

Thank you, will do and post the result. Away from the router now, tomorrow.

 

[wouterv]

Guys, is this one creating some trouble?

I want to give this router to someone else, but I don't want to support it.

Feb 11 03:04:27 kernel: asd/179: potentially unexpected fatal signal 11.
Feb 11 03:04:27 kernel: Pid: 179, comm:                  asd
Feb 11 03:04:27 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Feb 11 03:04:27 kernel: PC is at 0x404ec7a8
Feb 11 03:04:27 kernel: LR is at 0x404e7050
Feb 11 03:04:27 kernel: pc : [<404ec7a8>]    lr : [<404e7050>]    psr: a0000010
Feb 11 03:04:27 kernel: sp : bec96990  ip : 4051bda0  fp : 00000000
Feb 11 03:04:27 kernel: r10: 0000001c  r9 : bec96b18  r8 : 00000020
Feb 11 03:04:27 kernel: r7 : 00000000  r6 : 00000163  r5 : 0000000b  r4 : bec96a10
Feb 11 03:04:27 kernel: r3 : 00000163  r2 : 00000000  r1 : ffffffff  r0 : 00000163
Feb 11 03:04:27 kernel: Flags: NzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Feb 11 03:04:27 kernel: Control: 10c53c7d  Table: 9efd004a  DAC: 00000015
Feb 11 03:04:33 rc_service: service 8703:notify_rc restart_firewall

Left the router running overnight, this error is present in logs few times already.

Thank you.

The asd fault disappeared completely with firmware 51668, my RT-AC68U showed the asd error a few times with firmware 51665 (see here).
With firmware 51665 and before the media bridge crashed a few times (say once a month).
My RT-AC68U router and RT-AC1900U media bridge do run 68 days now after the dirty upgrade from 51665 to 51668 without any errors or crashes (besides the firewall rule issue I tried).
For plain consumer router usage firmware 51668 seems very stable and trouble free to me.

 

[Tech9]

Reboot and make sure the iptables entries are there.

All good after reboot. Thank you!

very stable and trouble free to me

I know this router is more stable than some new ones. The reason I want to find a good use for it.

 

[VANT]

All good after reboot. Thank you!

and you want to say that you didn't do the basic thing, which is restarting the router?

 

[Tech9]

The router is not in my house. The GUI bug is still present and the SSH is a workaround.

This reboot test was to ensure manually applied rules in SSH persist and pass validation.

 

[wouterv]

No harm, only an observation:
RAM usage is still slowly increasing, see updated post #14.