Unable to edit Firewall - Network Services Filter Table on RT-AX88U Pro (fw. 388.3)

[L&LD]

Still not clear.

Correct order:

• Flash the firmware you want to test/use.
• Perform a full reset (ideally, with more than one method, after flashing the firmware first).
• Minimal and Manual configuration to secure the router and connect to your ISP.
• Test.
• Repeat from top when you want to test the next firmware.

 

[RandomUser777]

Still not clear.

Correct order:

• Flash the firmware you want to test/use.
• Perform a full reset (ideally, with more than one method, after flashing the firmware first).
• Minimal and Manual configuration to secure the router and connect to your ISP.
• Test.
• Repeat from top when you want to test the next firmware.

Correct. That was my method for each discrete test on each of the two firmware versions on two routers. For a total of 4 tests.

Then I fully set up my 86UPro using 388.4. CIDR didn't work. Then I dirty downgraded to 388.2 and CIDR works.

 

[Tech9]

Report your findings to the corresponding release thread:

Release - Asuswrt-Merlin 3004.388.4 is now available

Asuswrt-Merlin 388.4 is now available for Wifi 6 models. 3004.388.4 (21-Aug-2023) - NOTE: In preparation for the new 3.0.0.6 codebase, the version string will now start with 3004 or 3006 to match with upstream. - NOTE: The RT-AX56U is no longer supported, as Asus has...

www.snbforums.com

 

[RMerlin]

I was able to test on an RT-AX88U_Pro.

On a completely reset RT-AX88U_Pro:
Merlin 388.2_2 accepts CIDR notation no problem.
Merlin 3004.388.4 does not accept CIDR notation (same issues as on the AX-86U_Pro)

I downgraded my production AX-86U_Pro to 388.2_2, and CIDR notation works fine. 3004.388.4 breaks CIDR.

So it looks like there is a bug somewhere after 388.2_2

Asus added some extra variable validation in the httpd daemon, probably to protect against certain types of attacks. That validation now rejects filter rules that use the CIDR format.

I'll probably have to skip that validation if we want to regain CIDR support, hopefully there aren't further validations later on that would also fail. I'm also hoping there aren't other variables that may also be affected by these new security checks.

 

[RandomUser777]

Asus added some extra variable validation in the httpd daemon, probably to protect against certain types of attacks. That validation now rejects filter rules that use the CIDR format.

I'll probably have to skip that validation if we want to regain CIDR support, hopefully there aren't further validations later on that would also fail. I'm also hoping there aren't other variables that may also be affected by these new security checks.

Hi Merlin. Thanks for checking into this.

I did a couple more tests. CIDR still works withinin the traditional QoS webgui.

On 388.2_2, I tried manually editing values in /jffs/nvram/filter_lwlist. All changes were reflected on the Network Services Filter gui page.

So, I tried 388.4. Flashed fine, and the CIDR entries persisted. Editing values in /jffs/nvram/filter_lwlist also worked. ****HOWEVER***, if I pressed "apply" on the GUI with a CIDR value in the table, the router would get caught in a rebooting loop of some sort. I could not access it again until a factory reset.

 

[RandomUser777]

@RMerlin do you have any estimate when this can be patched?

 

[RMerlin]

@RMerlin do you have any estimate when this can be patched?

I implemented a workaround for now since a full patch won't be available until a new GPL is merged in. That workaround will be present in 3004.388.5.

 

[Routerguyuk]

I implemented a workaround for now since a full patch won't be available until a new GPL is merged in. That workaround will be present in 3004.388.5.

Note this is also happening with RT-AC88U. v386.12_4 (latest 2023-11-22)

Pages
Firewall - Network Services Filter (Advanced_Firewall_Content.asp) - this page will no longer save any edits or new entries.
Firewall - URL Filter (Advanced_URLFilter_Content.asp)- this page will no longer save any edits or new entries.

 

[L&LD]

Have you tested with different browsers? In 'incognito mode'? With extensions disabled?

 

[Routerguyuk]

Have you tested with different browsers? In 'incognito mode'? With extensions disabled?

Good question. Apologies I should have noted I have checked with 3 browsers. Firefox v121 (all add-ons disabled & incognito). Chrome latest private browsing mode, and Edge browser browsing mode, Version 120.0.2210.91 (Official build) (64-bit).
All 3 will allow the entry of a value, but the issue is on submission of the form. Having clicked the apply button, the spinner will remain indefinitely. Refreshing the page will result in having been logged out and the need to sign in again. The changes were not applied / saved.

 

[ColinTaylor]

All 3 will allow the entry of a value, but the issue is on submission of the form. Having clicked the apply button, the spinner will remain indefinitely. Refreshing the page will result in having been logged out and the need to sign in again. The changes were not applied / saved.

Your problem is not the same as the one discussed in this thread. The problem you describe is the same as reported here and is present only in the 386 branch of the firmware.