What's new

Release Asuswrt-Merlin 386.7 is now available for all 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.
Wow, 21 pages already :)

I don't have the time to read through all of them, but is it finally 100% safe to install on AX86U?
 
@RMerlin Is their any way we can get better AIMesh reconnectivity. I’m running this firmware on both a gt-ax11000 (main router) and a rt-ax58u (node), however on reboot of the main router should it need to be done I find the node will disappear from the list and not connect. It does show its connected under the wireless log but aimesh doesn’t detect it and it usually requires a manual reset of the node which is a pain in the butt when it’s only working off a wireless only backbone meaning I need to bring the router downstairs to setback up. I have the feeling that the node reverts to the 192.168.50.1 (default ip when first reset) where I’ve set the private ip on the main to 192.168.1.1 instead.

I can’t use a cable. I’ve tried powerlines before but they sucked and it still has the chance of just not connecting correctly.
AIMesh, as well as all the wireless control stuff is all closed source code. Merlin has no control over it. I can't count the number of times he has had to say that.

From my own perspective, this release has gone pretty much like any other. For what ever reason, a few users have issues while others don't. It is weird. From my experience, when I have run into weirdness after a release upgrade, a full wipe and reset is required as something changed in the release at the nvram level that requires new defaults to be applied.

I don't use AIMesh. I have found it unreliable compared to good old APs. Same with a lot of the wireless special features. I find a lot of devices have issues with fancy features as they were never designed for it.

I have not upgraded to this release yet out of lack of time (I want a good two to three hour block just in case I need to do a full wipe and rebuild), but my thanks to @RMerlin for all effort you have put into this project over the years. You have inspired me to get back into Unix/linux after a 25 year absence.

Cheers.
 
Would just like to add I also fully reset both devices when updating to this firmware.

Unfortunately I’m well aware he doesn’t have access to modify close source code however as Tech9 said it could be something in Merlin’s builds that breaks discovery, but at the very least if this is a issue that enough of his users have if he reports it to ASUS it will carry weight in getting fixed on their end if it’s not something caused on his end.
 
It doesn’t crash really, in the sense that the pid is constant between occurrences, unless I restart it manually.
It's not a crash, it's a kernel error that an invalid checksum was detected, and it then dumps the stack as well as the name of the process that generated the packet. These checksum errors can occur for a number of reason, one of them being hardware offloading done by the switch (like GSO/GRO).
@dave14305 I wonder whether this is similar to the issue I described in this thread: https://www.snbforums.com/threads/t...sb-drive-to-client-intermittently-fail.77879/

You seem to be able to recreate the problem on demand so it would be interesting to see if the following command "fixes" it.
Code:
ethtool -K br0 tx off sg off tso off gso off
P.S. I don't think this will make a difference but it's worth a shot.

P.P.S. I'm assuming rx-checksumming is already off (ethtool -k br0 | grep checksum).
 
Last edited:
So here's what I've gathered.

It's not a crash, it's a kernel error that an invalid checksum was detected, and it then dumps the stack as well as the name of the process that generated the packet. These checksum errors can occur for a number of reason, one of them being hardware offloading done by the switch (like GSO/GRO).

I already eliminated the possibility of it being caused by flow cache or archer/runner.

I've tried redirecting to the link-local address, as well as to the local loopback (which didn't work), without any success.

I've also gone back through around 4 years of commits to the kernel udp.c driver as well as Netfilter's NAT driver. I tested two potential candidate, without any success.

So at this stage, there's a chance it may be an issue related to the Broadcom network driver (the kernel had a few drivers that needed fixing in the past over this issue).

It could also be an issue tied to packet fragmentation occurring with large UDP packets (that might explain why it does not happen with every IPv6 queries).

I think this is unlikely to be fixable without a low level debugging of the generated traffic, something beyond my current knowledge of networking (and not something I'm willing to devote hours into figuring out). So most likely fix at this time will be to remove IPv6 support from DNSFilter mode "Router".

I haven't yet tested it on a newer HND 5.04 device, tho even if it worked that wouldn't tell us much, as it has both a newer kernel and Broadcom SDK.

I've said it before, and I'll say it again: I hate IPv6.
OMG we cannot say thank you "ENOUGH" for all your efforts + I also HATE IPv6, myself (but as I said earlier... I don't think it's going away). Good Luck & hopefully there is some additional help to resolve these IPv6 issues ;-)
 
IPv4, IPv6 'hate'? I find that depends on the ISP. IPv6 works great when the ISP properly implements it.
 
IPv4, IPv6 'hate'? I find that depends on the ISP. IPv6 works great when the ISP properly implements it.
My primary ISP does not support IPv6 in my service area.

My secondary ISP supports IPv6 but I have had DNS issues in the past when attempting to use it.

For now, I have disabled all support for IPv6 on my network.
 
@RMerlin Is their any way we can get better AIMesh reconnectivity.
AiMesh is a proprietary blackbox. I have no control over it, and no info as to how it works internally.
 
IPv4, IPv6 'hate'? I find that depends on the ISP. IPv6 works great when the ISP properly implements it.
IPv6 is still an overengineered solution to a problem that also tries to address 10 other problems that sometimes weren't even problems.

But then, this is a recurring issue with other Internet novelties as well. The Internet was initially designed to be simple yet very robust in its design. Most protocols were even text-based, making it easy to debug and troubleshoot. What has been done to simple protocols such as HTTP, SMTP or DNS these past 5 years has been mind boggling. Developing any application that can handle sending email notifications has become quite complicated now that providers like Google expect you to use OAUTH2 for authentication. DNS has forked into four or five different protocols over the past three years.

Sometimes it does improve things or address a specific problem. But they also go out of their way to find other problems to solve at the same time. This added complexity only makes things harder to debug, and less robust and reliable.
 
Last edited:
@dave14305 I wonder whether this is similar to the issue I described in this thread: https://www.snbforums.com/threads/t...sb-drive-to-client-intermittently-fail.77879/

You seem to be able to recreate the problem on demand so it would be interesting to see if the following command "fixes" it.
Code:
ethtool -K br0 tx off sg off tso off gso off
P.S. I don't think this will make a difference but it's worth a shot.

P.P.S. I'm assuming rx-checksumming is already off (ethtool -k br0 | grep checksum).
It didn’t help, unfortunately. There’s so little written about issues DNATting IPv6 UDP packets, that I’m starting to believe it’s another Broadcom “gift”. Disabling DNS Filter will avoid it.
 
@RMerlin, and how does that make it bad?

I'd rather have a V6/V8 in my only SUV to go grocery shopping with which I may also use on the highway, than an inline 4 and be worried about passing, mountains, and other safety and reliability issues with my primary/main mode of transportation.

Overbuilt and overengineered are things that last to me. Everything else is by default, inferior.
 
@RMerlin, and how does that make it bad?

I'd rather have a V6/V8 in my only SUV to go grocery shopping with which I may also use on the highway, than an inline 4 and be worried about passing, mountains, and other safety and reliability issues with my primary/main mode of transportation.

Overbuilt and overengineered are things that last to me. Everything else is by default, inferior.
Sorry L&LD but I have to side with RMerlin on this topic... & here is why. Under the pretense of security time & time again... more & more encryption adds several layers of "non-human readable" content. So... something as simple as a (Link or URL) which previously could be verified "by a competent user" is no-longer caught or recognized by the human eye. Essentially we need more & more layers of software to somehow tell us the content is "safe" but we as humans really have almost no clue. + the more complicated something is... the less likely "we" will ever be able to understand it.

EDIT: sorry for going off-topic but it's a real sore-spot with me.
 
Last edited:
Updated RT-AC5300 from 386.5 to 386.7 and it has been running for over four days without issue. Thank you RMerlin!

ProtonVPN takes IPV6 down, so I turned off VPN, enabled IPV6, checked IPV6 was working properly, and ran the DNS check as noted in post 344 and saw no issues noted in the log as shown in post 361. I use QUAD9, have the LAN -> DNS Filter set to ON -> Router, and have the IPV4 addresses listed in WAN -> Internet Connection -> DNS Server and the IPV6 addresses in IPV6 - DNS Server (do both to protect against single-path failures). The DNS fields are left blank under LAN -> DHCP Server -> DNS and WIN Server Settings, LAN -> DNS Filter, and LAN -> DHCP Server -> IPV6 DNS Server

The QUAD9 addresses I use are 9.9.9.11, 149.112.112.11, 2620:fe::11 and 2620:fe::fe:11 (Secured w/ECS: Malware blocking, DNSSEC Validation, ECS enabled and the IPV4 default listed in the drop down menu).

I ran the test because I know the RT-AC5300 uses a different GPL versus the others.
 
I ran the test because I know the RT-AC5300 uses a different GPL versus the others.
IPv6 DNAT is not available on the RT-AC5300, it requires a model with a newer Linux kernel. So in your case, DNSFilter behaviour remains the same as before.
 
I can understand and agree with the arguments against IPv6, but with the need for IPv6 growing each day, they are all moot points in the long run.

It is needed. It will be the standard. IPv4 is (for many places in the world) obsolete. Even if we can still connect to most websites with IPv4, today.

Nothing I have bought 'overbuilt' has gone to waste. Anything I bought 'good enough' was almost immediately regretted.

My point is that my experience with IPv6 is that when the ISP has implemented it properly, it works seamlessly, just like IPv4 does for so many others. And it is faster (less latency) too.
 
IPv4 exhaustion is really coming in quick and fast in Australia.
There is few standard residential internet plans not using cgnat already.
I imagine another 12 months you will not find a residential plan without cgnat.
Most turn to 4g/5g as their failover internet but there is almost no options regardless of money to not be connected via cgnat.

IPv6 needs to be everywhere yesterday or we can forget about vpn to devices like an Asus router.
 
RT-AX86U hardware reset and install and config yesterday, no issues to report, today upgraded to Gig1 VM, smooth sailing.

Off topic, what IPv6 should I use for VM 6to4, native etc ?
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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