[ 3004.388.5 alpha Build(s) ] Testing available build(s)

[bluepoint]

Something new or I just notice it now?

Nov  5 01:00:00 watchdog: restart_firewall due DST time changed(1->0)
Nov  5 01:00:00 rc_service: watchdog 2877:notify_rc restart_firewall
Nov  5 01:00:00 rc_service: watchdog 2877:notify_rc restart_wan
Nov  5 01:00:00 rc_service: waitting "restart_firewall" via watchdog ...
Nov  5 01:00:00 custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Nov  5 01:00:01 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Nov  5 01:00:01 Diversion: added type 65 blocking rules in iptables and ip6tables
Nov  5 01:00:01 custom_script: Running /jffs/scripts/service-event (args: restart wan)
Nov  5 01:00:01 miniupnpd[4848]: shutting down MiniUPnPd
Nov  5 01:00:01 lldpd[2981]: removal request for address of 2600:4040:yyyy:xxxx::1%27, but no knowledge of it
Nov  5 01:00:01 ddns: eth0 has not yet obtained an WAN IPv6 address.(10)

This morning's DST time change restarted services through the watchdog and custom scripts.
Is my understanding correct that some services like firewall, WAN were restarted twice one by the watchdog and secondly by custom scripts?
Or maybe the custom scripts execution were results of the watchdog?

GT-AX6000
3004.388.5 A1

 

[kuki68ster]

Installed and it is working fine, only issue I am noticing is some stutter when navigating between the settings options…

 

[emwgee]

DST setting - isn't it supposed to be "11" for Nov instead of "10" ?

I am in the PST time zone. If I changed it to "11", the system clock would be one hour ahead

 

[aex.perez]

DST setting - isn't it supposed to be "11" for Nov instead of "10" ?

I am in the PST time zone. If I changed it to "11", the system clock would be one hour ahead
View attachment 53963

DST Ends on the 11th month and 1st Sun, I'm on EST and had to change back when I noticed the system time was off

 

[RMerlin]

ANY CIDR notation causes the reboot of death. ie, 192.168.50.224/32 or 192.168.50.224/28 or 192.168.50.192/27. ANY CIDR notation locks up the router.

Probably two separate issues, because the validation issue that was addressed in this test build only gets applied when saving settings, Works fine for me with two entries set to 10.9.0.0/16, but a crash when using 192.168.50.224/32.

I am now wondering if ASUS intentionally blocked CIDR notation on the filter because it breaks some coding.

They didn't. They are rejecting CIDR addresses because they aren't supported by their webui, and they reject any address that contains an illegal character (i.e. anything beside numbers and dots). They will be adding an exception rule to their validation code in a future GPL release.

 

[RMerlin]

Probably two separate issues

The new firewall code uses buffers that are too small to contain a full CIDR (which is what was causing the crashes on firewall rule application - my tests used an address that was small enough to fit in), and that new code also needs to be updated to handle CIDR formatted strings. This is in addition to the validation issue that was previously resolved.

 

[Dedel66]

Everything is working fine. System log is still without an entry (log level @ warning - warning)!

 

[L&LD]

4 days, and 10 minutes, no issues. RT-AX86U (main), GT-AX6000 (AiMesh node, wired 2.5GbE backhaul).

BTW, fastest WiFi (highest throughput and lowest latency) I've yet seen on my network. Very noticeable with any client device I care to use on it.

 

[RMerlin]

BTW, fastest WiFi (highest throughput and lowest latency) I've yet seen on my network. Very noticeable with any client device I care to use on it.

Placebo. Zero SDK change in this build.

 

[L&LD]

Not placebo. I know how my network performs.

Today (and for the last 4 days, after rebooting it twice in ~1hr after first installing this firmware), it is noticeably faster and smoother.

 

[RMerlin]

Not placebo. I know how my network performs.

Today (and for the last 4 days, after rebooting it twice in ~1hr after first installing this firmware), it is noticeably faster and smoother.

And I'm positive it's impossible to be related to the new firmware.

merlin@ubuntu-dev:~/amng$ git log --oneline 3004.388.4..HEAD
b8fd700163 (HEAD -> master, origin/master) rc: add support for CIDR formatted addresses in iprange_ex_conv()
ca44a0390d httpd: webui: allow resolving IPv6 addresses on Classification page
0f86e99a69 Updated documentation
8fae54ac60 httpd: skip extra validation when setting filter_lwlist nvram
7afddbce78 webui: display conntrack/app type even if aQoS isn't enabled
91cf874619 webui: allow entering an IPv6 on Networking Tools page
363db10b84 curl: update to 8.4.0.
0a15aa6a12 webui: properly show USB3 support on networkmap page for GT-AX11000_PRO
7f513adff2 openssl: updated to 1.1.1w
597e72beab openvpn: updated to 2.6.6
9b70fc45cc libovpn: enable fast-io for OpenVPN UDP servers
09041e181a Bumped revision to 3004.388.5 alpha 1
312ed2c0d8 rc: trigger a DDNS retry attempt if WAN IP was not set yet following a down/up event
66e04a0fa5 Updated documentation

 

[L&LD]

I'm not doubting that the firmware may not be the only contributing factor.

Many things have changed in the last 4 or more days.

Including reboots (of router and all client devices), and Windows updates. Even a few drivers and one BIOS update for my computers.

The cumulative effect is very noticeable from when running 388.4_0 final.

 

[RandomUser777]

The new firewall code uses buffers that are too small to contain a full CIDR (which is what was causing the crashes on firewall rule application - my tests used an address that was small enough to fit in), and that new code also needs to be updated to handle CIDR formatted strings. This is in addition to the validation issue that was previously resolved.

@RMerlin thank you so much for researching this. Do you expect a fix for both from Asus soon, or are you able to patch it for your next release?

 

[MDM]

@RMerlin thank you so much for researching this. Do you expect a fix for both from Asus soon, or are you able to patch it for your next release?

He already answered it in the post above the one you quoted (and in that one as continuation).
Did you miss it?

 

[RandomUser777]

He already answered it in the post above the one you quoted (and in that one as continuation).
Did you miss it?

I'm sorry, but the answer is not clear to me:

They didn't. They are rejecting CIDR addresses because they aren't supported by their webui, and they reject any address that contains an illegal character (i.e. anything beside numbers and dots). They will be adding an exception rule to their validation code in a future GPL release.

The new firewall code uses buffers that are too small to contain a full CIDR (which is what was causing the crashes on firewall rule application - my tests used an address that was small enough to fit in), and that new code also needs to be updated to handle CIDR formatted strings. This is in addition to the validation issue that was previously resolved.

Neither of those responses explicitly states whether Asus will be fixing this soon, or whether RMerlin himself will be able to provide a patch for both, since he was able to patch the CIDR issue himself, but the firewall buffer issue still exists in his alpha.

 

[RMerlin]

Neither of those responses explicitly states whether Asus will be fixing this soon,

Technically Asus does not have anything in need of fixing, as the stock firmware does not support CIDR, therefore nothing is broken on their end.

The first issue that affects us is the variable content validation when you apply your settings. That`s closed source and it rejects IP addresses that contains a slash in them. That`s what prevented saving a CIDR value. I implemented a workaround that skips that validation for this particular variable. A future GPL release will implement a bypass within that code for when it`s running on Asuswrt-Merlin, at which point the workaround will no longer be required. https://github.com/RMerl/asuswrt-merlin.ng/commit/8fae54ac608b28a4f6e57931f8fce60a6bf8bdab

The second issue is that changes to the firewall code were no longer supporting CIDR (too small buffer was causing your boot loops, and the code itself ignored the subnet portion of the CIDR). That part is for me to implement, since Asus does not support CIDR. https://github.com/RMerl/asuswrt-merlin.ng/commit/b8fd70016349433096c5d8be0fd9f07d40e11376

 

[privacyguy123]

Is it safe to assume the test builds for AX58U firmware works with AX3000 as they do for regular Merlin builds?

 

[visortgw]

Is it safe to assume the test builds for AX58U firmware works with AX3000 as they do for regular Merlin builds?

Absolutely.

 

[kernol]

Is it safe to assume the test builds for AX58U firmware works with AX3000 as they do for regular Merlin builds?

Only one cautionary - Merlinware works with AX58U Ver1 and not Ver2 - so the same will apply to the AX3000 [the alternate marketing name for the AX58U]. See here.

 

[kernol]

@RMerlin - Now that Asus stock firmware version 3.0.0.4.388_24198 is being rolled out for several AX models - will that likely find its way into your 3.0.0.4.388-5 final release? Just curious as several closed source areas of the Asus code are claimed to be patched/fixed/improved?

https://www.snbforums.com/threads/a...ware-version-3-0-0-4-388_24198-08nov23.87548/