[Preview] RT-AX88U public test builds

[matthew johnson]

Yes.



Depends, can you be more specific?

Note that I don't use it as a router because I can't afford to take my whole network down every time I flash a new test build, so my first hand experience with it as a router is fairly limited.

Sorry what i meant was in terms of power and reliablity? Cause the gt-ac5300 had alot of bugs when first launched. And this has the same chipset i believe.

 

[RMerlin]

Sorry what i meant was in terms of power and reliablity? Cause the gt-ac5300 had alot of bugs when first launched. And this has the same chipset i believe.

It's a very similar platform indeed. The CPU power is the same, so expect similar VPN and USB performance. Can't comment on wifi performance or overall stability since I only used it for a day or two as a primary router. It sits within my LAN, and I only turn it on while doing development work on it.

Someone who has one and is actually using it as his main router would be able to provide more real life feedback.

 

[matthew johnson]

It's a very similar platform indeed. The CPU power is the same, so expect similar VPN and USB performance. Can't comment on wifi performance or overall stability since I only used it for a day or two as a primary router. It sits within my LAN, and I only turn it on while doing development work on it.

Someone who has one and is actually using it as his main router would be able to provide more real life feedback.

Thank you. I have the GT-AC5300 it runs pretty good. I just feel this would better suit what i need.

 

[RMerlin]

Third test build is now available. This build should finalize implementing support for the RT-AX88U.

Changes since last week's build:

6261ef60f (HEAD -> rtax88, origin/rtax88) Merge branch 'master' into rtax88
65be6df90 (origin/master, origin/HEAD, master) Bumped revision to alpha 3
2837c4e00 Updated documentation
8f4864302 webui: allow changing image for device vendors with a quote (like "Micro-star int'l co., ltd.")
aa7e1e002 webui: httpd: allow changing HTTP LAN port on webui; no longer check HTTP WAN port for conflicts since it's not used anymore
f98def201 net-snmp: remove model define from build since we don't use Asus MIBs - solves build time warnings
d840c97d3 net-snmp: move directory, and create symlink so we can reuse existing build recipes
cbda22265 net-snmp: update to 5.8
2e3e54f1e webui: re-sync WTFast page with upstream
717e1e104 wtfast: re-enable on RT-AC88U/3100/5300, now that the curl-related crash is fixed
5b2cf981b curl: disable threaded resolver, which crashes various applications like mastiff and wtfast
ed033afa5 rc: fix router mode test in watchdog for dnsmasq_check
f56c3a2a1 HND: merge prebuilt binaries from GPL 32799
4dd5a3ed0 httpd: fix filename generation in _get_vpn_crt_value(); code optimizations around that function
9cba12020 webui: move USB mode setting to the correct section
be5bb16df kernel41-ax: fix nested structure references in xt_set
73c640575 kernel41-ax: update ipset kernel compatibility header
ccd718ba2 kernel41-ax: update ipset kernel components to 6.32
2a7088935 kernel41-ax: Make xt_match_recent built-in instead of a module (to match with other platforms)
c6454ad25 Merge branch 'master' into rtax88
98cfc2545 rc: resolve compile warning for adjust_jffs_content()
58e383e9b build: fix ldcache (for HND AX)
da0303009 HNDAX: add Entware support
08cad4503 iptables: fix save formatting for ROUTE target
35564a40a iptables: fix match for ipt_account; add additional compile
1922904a0 iptables: fix save formatting for libipt_account
f0eacfc65 iptables: fix save formatting for libipt_webstr
8abce3643 rc: fix test in lan_up() to create default route in non-router modes
312e51024 rc: fix test to prevent starting dnsmasq in non-router modes

 

[Martin_D]

Third test build is now available. This build should finalize implementing support for the RT-AX88U.

Changes since last week's build:

6261ef60f (HEAD -> rtax88, origin/rtax88) Merge branch 'master' into rtax88
65be6df90 (origin/master, origin/HEAD, master) Bumped revision to alpha 3
2837c4e00 Updated documentation
8f4864302 webui: allow changing image for device vendors with a quote (like "Micro-star int'l co., ltd.")
aa7e1e002 webui: httpd: allow changing HTTP LAN port on webui; no longer check HTTP WAN port for conflicts since it's not used anymore
f98def201 net-snmp: remove model define from build since we don't use Asus MIBs - solves build time warnings
d840c97d3 net-snmp: move directory, and create symlink so we can reuse existing build recipes
cbda22265 net-snmp: update to 5.8
2e3e54f1e webui: re-sync WTFast page with upstream
717e1e104 wtfast: re-enable on RT-AC88U/3100/5300, now that the curl-related crash is fixed
5b2cf981b curl: disable threaded resolver, which crashes various applications like mastiff and wtfast
ed033afa5 rc: fix router mode test in watchdog for dnsmasq_check
f56c3a2a1 HND: merge prebuilt binaries from GPL 32799
4dd5a3ed0 httpd: fix filename generation in _get_vpn_crt_value(); code optimizations around that function
9cba12020 webui: move USB mode setting to the correct section
be5bb16df kernel41-ax: fix nested structure references in xt_set
73c640575 kernel41-ax: update ipset kernel compatibility header
ccd718ba2 kernel41-ax: update ipset kernel components to 6.32
2a7088935 kernel41-ax: Make xt_match_recent built-in instead of a module (to match with other platforms)
c6454ad25 Merge branch 'master' into rtax88
98cfc2545 rc: resolve compile warning for adjust_jffs_content()
58e383e9b build: fix ldcache (for HND AX)
da0303009 HNDAX: add Entware support
08cad4503 iptables: fix save formatting for ROUTE target
35564a40a iptables: fix match for ipt_account; add additional compile
1922904a0 iptables: fix save formatting for libipt_account
f0eacfc65 iptables: fix save formatting for libipt_webstr
8abce3643 rc: fix test in lan_up() to create default route in non-router modes
312e51024 rc: fix test to prevent starting dnsmasq in non-router modes

Thank you.

 

[Topazali]

I'm still having a problem with OpenVPN client settings on alpha 3. When I upload an ovpn file the settings are not saving. Stock firmware seems fine.

 

[RamGuy]

Seems to be working solid so far. Any plans on adding the Full-Cone-NAT feature to the WebUI?

 

[RMerlin]

Seems to be working solid so far. Any plans on adding the Full-Cone-NAT feature to the WebUI?

The webui check was specifically looking for the RT-AC86U. I just made it appear for all HND models, just need to test to confirm that it still works with the RT-AX88U kernel.

 

[RMerlin]

I'm still having a problem with OpenVPN client settings on alpha 3. When I upload an ovpn file the settings are not saving. Stock firmware seems fine.

Works for me.

 

[Empassant18]

Adding more than 64 DHCP addresses does not work. Seems like it's stuck on the stock default of 64. Great build! Thanks so much.

 

[JDB]

The webui check was specifically looking for the RT-AC86U. I just made it appear for all HND models, just need to test to confirm that it still works with the RT-AX88U kernel.

On that subject, how can you programmatically determine if you are on a HND model or not?
Need to know for the NTP project as it needs different RRD file formats.


Sent from my iPhone using Tapatalk

 

[Jack Yaz]

On that subject, how can you programmatically determine if you are on a HND model or not?
Need to know for the NTP project as it needs different RRD file formats.


Sent from my iPhone using Tapatalk

uname -m returns aarch64 for AC86U, and possibly AX88U as well

 

[Topazali]

Works for me.

Thanks. I formatted JFFS and rebooted and now all is working.

 

[Gitsum]

Thank you. I have the GT-AC5300 it runs pretty good. I just feel this would better suit what i need.

Same here. Wish Merlin supported the GT-AC5300. May get AX88 just because of Merlin support.

 

[ColinTaylor]

The webui check was specifically looking for the RT-AC86U. I just made it appear for all HND models, just need to test to confirm that it still works with the RT-AX88U kernel.

@RMerlin Could you clear up a source of confusion about the "Full Cone NAT" option present on the RT-AC86U (which I don't have so I can't check myself). Am I correct in thinking that this option only applies to the router's normal NAT operation and is not related to UPnP in any way? This was my understanding from a comment you made in another thread about a year ago.

Side Note: AFAIK the port forwarding rules created by miniupnpd have no source restrictions and would therefore be classified as "full cone NAT".

 

[Vexira]

@RMerlin Could you clear up a source of confusion about the "Full Cone NAT" option present on the RT-AC86U (which I don't have so I can't check myself). Am I correct in thinking that this option only applies to the router's normal NAT operation and is not related to UPnP in any way? This was my understanding from a comment you made in another thread about a year ago.

Side Note: AFAIK the port forwarding rules created by miniupnpd have no source restrictions and would therefore be classified as "full cone NAT".

I'm pretty sure if I remember correctly it also affects upnp, i remember reading about port and address restricted Nat affecting what ports can be forwarded while still being a cone nat, granted I could be wrong and have miss read it.
My AC 88U has symetic Nat and the kernel is too old to support full cone, because Asus and , didn't pull a netgear and put in some black box solutions to getting things like full cone nat and fq_codel supported.

 

[ColinTaylor]

I'm pretty sure if I remember correctly it also affects upnp, i remember reading about port and address restricted Nat affecting what ports can be forwarded while still being a cone nat, granted I could be wrong and have miss read it.
My AC 88U has symetic Nat and the kernel is too old to support full cone, because Asus and , didn't pull a netgear and put in some black box solutions to getting things like full cone nat and fq_codel supported.

It's precisely this kind of uncertainty I'm trying to get clarification of, straight from the horse's mouth as it were.

 

[RMerlin]

It affects UPnP, however the implementation lies right at the kernel level, inside the MASQUERADE module.

 

[ColinTaylor]

It affects UPnP, however the implementation lies right at the kernel level, inside the MASQUERADE module.

Thank you for your reply. However, I've been thinking about this all day and pouring over the previous discussions about this and I still can't get my head around it. I think there are two things that I don't understand;

1. (Sorry to labour this point) Does this apply only to UPnP created connections? If it's a change to the MASQUERADE module then presumably it's effecting all the router's NATing and is not specific to anything UPnP is doing?

2. The port forwarding (DNAT) rules that UPnP normally creates don't have any restrictions on the incoming source and can already be called "Full-cone". What does this new router option add to this that it wasn't already doing?

The only hypothesis that I've been able to come up with is that this new option changes the kernel's NAT/MASQUERADE behaviour from what it usually is, a Port/address-restricted cone NAT, to a Full-cone NAT. That to me would make sense.

 

[john9527]

2. The port forwarding (DNAT) rules that UPnP normally creates don't have any restrictions on the incoming source and can already be called "Full-cone". What does this new router option add to this that it wasn't already doing?

The only hypothesis that I've been able to come up with is that this new option changes the kernel's NAT/MASQUERADE behaviour from what it usually is, a Port/address-restricted cone NAT, to a Full-cone NAT. That to me would make sense.

/speculation-on
I like your term port/address restricted.....since the random assigned upper host port is unique for each server there is in essence a host restricted relationship. I suppose if someone wanted to scan all the upper ports for a connection they could try, but then they also wouldn't know what app would be at the other end.

The new behavior I'm guessing establishes a one-to-one source port to client port relationship.
/speculation-off