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.@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.
my reply to your incorrect post stands...My math was wrong ... USD43 equiv per month
It doesn’t crash really, in the sense that the pid is constant between occurrences, unless I restart it manually.
@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/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).
ethtool -K br0 tx off sg off tso off gso off
ethtool -k br0 | grep checksum
).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 ;-)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.
My primary ISP does not support IPv6 in my service area.IPv4, IPv6 'hate'? I find that depends on the ISP. IPv6 works great when the ISP properly implements it.
AiMesh is a proprietary blackbox. I have no control over it, and no info as to how it works internally.@RMerlin Is their any way we can get better AIMesh reconnectivity.
IPv6 is still an overengineered solution to a problem that also tries to address 10 other problems that sometimes weren't even problems.IPv4, IPv6 'hate'? I find that depends on the ISP. IPv6 works great when the ISP properly implements it.
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.@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.
P.S. I don't think this will make a difference but it's worth a shot.Code:ethtool -K br0 tx off sg off tso off gso off
P.P.S. I'm assuming rx-checksumming is already off (ethtool -k br0 | grep checksum
).
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.@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.
See https://en.wikipedia.org/wiki/Rube_Goldberg_machine as to why that is not necessarily true.Overbuilt and overengineered are things that last to me. Everything else is by default, inferior.
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 ran the test because I know the RT-AC5300 uses a different GPL versus the others.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!