What's new

Beta Asuswrt-Merlin 388.1 Beta is available for select models

  • 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.
Last edited by a moderator:
Full Cone NAT is overhyped by gamers, quite honestly. Very few routers actually support it, it reduces your network's security, and when discussing it with an engineer, his question was: "Can you give me one precise scenario where it is necessary", which I couldn't answer (and apparently nobody can at a technical level, all you will find online are "My console complains about NAT mode").

Well, yes I understand what your saying.

There are many discussions about it but the only ones I have seen that I think actually have a problem are those that need to use two Xbox consoles (possibly other brands are problematic) at the same time and often both for the same game.
I have more than two Xbox consoles here at home but I rarely need both working at the same time but I'm pretty sure I would have a problem in that case especially if I wanted both using the same game.

I'm not going to try and explain it because I'm not sure my impression of the actual problem is in fact correct, it involves claiming that the Xbox upnp implementation is poor, and maybe even broken, and Microsoft just won't fix it.

Since so few routers support it, I refuse to believe that so many online games would be broken for such a large amount of people.
Probably only few people need to use two xbox consoles concurrently ... so likely not so many are actually affected.

Ian
 
I've reviewed two of them. One only works with UDP and does not support TCP. The other one requires completely replacing the kernel's masquerade implementation, which means it has a high chance of breaking a lot of other things - assuming that implementation is even compatible with 4.19's Netfilter.

I guess the question becomes is masquerade sufficient for the connection oriented TCP protocol.
To answer that you would need to define what a Full Cone NAT implementation is meant to do.
I think the answer is "it is sufficient" considering the restrictions an actual implementation must operate under.

Unfortunately these out of tree implementations do become abandoned from time to time but usually someone else takes up the challenge for things that there is demand for which looks to be the case for this.
Ideally someone would work on getting it merged into the Linus kernel tree ... maybe there are reasons the netfilter folk don't want this merged ... I wonder if I can find someone to ask ... mmm.
 
What is not right you did it after updating 386 -> 388. You had to do it before.
I do not understand. After the update it worked. After the update, I made a backup, reset and restored. Why is this incorrect? Maybe the recovery order is different? For example, first "Restore JFFS partition" then "Restore setting" instead of "Restore setting" and "Restore JFFS partition".
 
After the update, I made a backup, reset and restored. Why is this incorrect?

Because if during the update something got messed up - you made a backup of corrupted settings and then restored this backup after the reset. The backup had to be done on 386 so you have easier way back if something is not right with your 388 update. What you did doesn't make sense.
 
hink the answer is "it is sufficient" considering the restrictions an actual implementation must operate under.
A half-working implementation would lead to tons of support requests as it would sometime work, and sometime not. So implementing a half-working solution is out of the question.

Ideally someone would work on getting it merged into the Linus kernel tree
That is actually something I had been pondering: if Fullcone NAT is so great, why is it not part of the kernel tree yet?
 
A half-working implementation would lead to tons of support requests as it would sometime work, and sometime not. So implementing a half-working solution is out of the question.
I wasn't implying a half-working implementation I was implying there are cases that are "not possible" based on what I've seen as the definition of Full Cone NAT.
That is actually something I had been pondering: if Fullcone NAT is so great, why is it not part of the kernel tree yet?

Yes, indeed.

Ian
 
You know, another solution is to purchase an IP block from your ISP and dish out IPs accordingly. Yeah it brings its own set of issues, but it's an idea.

I would love to have my own IPv4 subnet, but you are not going to be able to purchase any meaningful IPv4 block in 2022 without paying tons of money. I have my own /30 block and even that is costing a lot of money in 2022. And it's not even provider-independent. I was working with a government entity that was going to get layer-2 redundancy for their Internet access across two different sets of ISPs so they had to get themselves a public /28 provider-independent IPv4 subnet. Oh man, that cost a lot of money. We are out of public IPv4 addresses, that's the whole reason why we have to deal with NAT in the first place. Even ISPs have to deploy CNAT/CGNAT within their own public IPv4 infrastructure as a result of the ISPs running out of IPv4 addresses themselves. Getting anything beyond a static /30 block of public IPv4 address space in 2022 is not going to happen unless you are rich and love to toss away money. IPv6 is obviously the answer to all of this. But the rollout is so awfully slow and unless additional entities start to enforce the use of IPv6 we won't be living in an IPv6 native world before I enter the grave.
 
The most likely reason why Full-Cone NAT is not implemented into the Linux kernel, or more in-demand in general is most likely because this is basically nitpicking at this point. Most people have no clue if they are using Full-Cone NAT, Port-Restricted Cone NAT or Symmetrical NAT. And most people wouldn't, and shouldn't care. For a normal user, there would be next to no real need for Full-Cone NAT. And for a home network without any meaningful or proper firewall in place, one could argue that NAT is the primary means of protection for inbound Internet traffic making Full-Cone NAT the least secure option for most home networks. Even though NAT really has nothing to do with security. And this is something that becomes less and less relevant by the minute. More and more services are avoiding the topic of NAT by making services entirely cloud-hosted. Removing the need for P2P or any connections to be going inbound into home networks in general. And obviously, the move to IPv6 regardless of how slow it's going will remove the need for NAT entirely.

I will fully admit I'm a huge nerd and edge-case here I sit advocating and wanting Full-Cone NAT to make my life easier and my home network better for my use case.
 
I will simply bypass this issue by keeping my RT-AX88U instead of the GT-AX6000 and get myself another 10Gbps/2.5Gbps switch. I already have a 10Gbps backbone between all my switches, but I have a lot of devices connected directly to my RT-AX88U, so instead of having the GT-AX6000 with a 2.5Gbps link to my nearest switch, I'll just get myself a more expensive switch and not have anything connected directly to the RT-AX88U and thus the downgrade to a 1Gbps connecting will only be happening for Internet traffic and thus far I only have a 1Gbps internet connection so unless my ISP suddenly starts offering beyond 1Gbps Internet speeds that won't be any issue for the foreseeable future.
 
PCREDIRECT = Parental Control Redirection.
Thank you, because of you I learned somehow the system allowed some device blockage- which I did not do.
Thats bizzare...
Once I disabled it, of course the port redirect is off.
Thanks
 
Updated Xt12's from Last Merlin 386 firmware to 388.1 B3 no issues but had to change DDNS lets encrypt IPv6 Update to no as it was flagging up an error. Barr this all goooood...Thx @RMerlin
 
Reflashed my AX86u node back to stock 388.20566 and link is green, then back to 388.1 b2 and link shows broken again, but the mesh is working fine and all devices on the node are connecting to Internet. Annoying but seems to be moslty a cosmetic problem.
Just noticed a new ASUS drop 21709 for the AX86u that contains this update:

5. Fixed VPN fusion, AiMesh, and Network map GUI bugs.
 
Does RT-AX58U Beta 3 support GS-AX3000-supposedly the same hardware? I have a friend who is trying to capture a deal today.
I've searched with no definitive result...

NEVER MIND...ANSWER FOUND:
No, that uses its own model-specific firmware.
 
Last edited:
Just noticed a new ASUS drop 21709 for the AX86u that contains this update:

5. Fixed VPN fusion, AiMesh, and Network map GUI bugs.
Contains the following as well (including other models like GT-AX6000) which is interesting.


9. Improved connection speed with Verizon FIOS.
 
Hi,

Web History is stil broken. Last logs are more then 10days ago on Beta 2. But there it was already unstable. Now there are no logs at all.
 
Hi,

Web History is stil broken. Last logs are more then 10days ago on Beta 2. But there it was already unstable. Now there are no logs at all.
Yeah, sorry this is out of Merlin's control. You could ask Asus support about it.
 
Web History is stil broken.

Common issue with many stock Asuswrt versions on different routers. It just stops working at some point.

 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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