CPU in the single digits except for peaks on occassion, but here are the averages
Another factor to consider is , does the speedtest always use the same server? Does that server ever have issues? There are alot of factors to consider, and the only way for you to find resolution on this matter is to process eliminate. Other factors to consider, are there any other scripts performing cpu intensive task during the times these drops occur? You can determine this sometimes by indications made in the syslog that a certain script may be active or there may be indication that a script is performing some sort of maintenance task.
FWIW I have Dual Stack IPv4 / IPv6 from my ISP and to date, I've had no problems with either protocol, but, by choice / default, I don't enable the 'Enable DoS Protection' option on my router. As per this other thread that you've already posted, enabling / disabling this option, does indeed, change this specific response:
504 RETURN icmpv6 * * ::/0 ::/0 ipv6-icmptype 128 limit: avg 1/sec burst 5112 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 128
Works for me. Try disabling your browser addon, also make sure you don`t have any funky character in a device description.
Source?
Bug introduced in Asus's 22525 code, I just fixed it.
Works for me. How many entries do you have? Can you reproduce the issue if you only add one client?
Should be fine in theory, VPN settings are the most problematic when migrating from stock to AMNG.
Been around here long enough to factor all that in. Random or the same Speedtest server the variation is minimal. Right after the router, I run from the PC I get my full speed, from the AT&T modem, full rated speed. CPU is running in the single digits on the router right when the sample is taken. I take 20-25 runs just to get to an average and weed out and high and low to minimize the variables. The log is clean, really noting running of significance. At this point it's process of elimination. Taking out Skynet got me closer to my normal, but can't fathom why as CPU has never been an issue and in the 386 family with the same scripts, never had a drop like this.
OK, power of/on, modem off/on, getting rid of the MAC Clone and redoing the passthrough, even built-in vs external libraries, in all cases no change. I'd say carrier but the their speedtest at the modem(resedential gateway) is fine;
I upgraded my AX client to 388.2b1 and unfortunately TAP VPN between my server and client is still broken. The same client works fine (as always) with my TAP VPN server running on my AC router, just not my AX, unfortunately.I just tried upgrading my GT-AX11000 to 388.2b1. Unfortunately, my TAP based VPN server crash issue still remains
(dirty update this time)
I find it strange that I see the same crash/reboot (~20-30 seconds after a successful tunnel is established) with all three of the most recent firmware versions, specifically 386_7_2, 388.1, and 388.2.
My AC5300 is still working just fine (same configuration, acting as the VPN server) and is now upgraded to 386.10 (was also working fine on 386_7_2 and 396.9). The client is running on an AX68U on 388.1
I do have two different .opvn files client configs to match each server, which I switch between on the client when experimenting with each server router, but the only differences is the order of the ciphers. I wouldn't have thought this mattered, but maybe it does?
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC vs ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
That all said, I'm starting to believe the issue is hardware / driver related (because the AC works and the AX doesn't when on the lowest common firmware, i.e. 386_7_2)
The one thing I haven't tried yet is upgrading my client router (AX68U) to 388.2 from 388.1. I may do that soon, but it's risky for me as it's at my remote location that's not so easy to physically manage.
System log doesn't show anything interesting that I can see.
Any ideas?
For more details, if anyone cares, this is the original post:
Internet access inconsistency and a repeatable crash with GT-AX6000 and GT-AX11000 vs my RT-AC class routers
I recently decided to upgrade my primary home router (AC5300) to an AX class router to match my remote location, which is already running an AX68U and is connected to my home via a site-to-site TAP based Open VPN connection. Since the firmware versioning between AC and AX seems to be diverging...www.snbforums.com
On newer HND models, custom nvram variables are limited to 255 chars values, so for these the rulelist is split between 6 separate variables (dnsfilter_rulelist, and dnsfilter_rulelist1 through dnsfilter_rulelist5). That`s why I was asking about the number of entries, to see if the issue might occur when you end up filling one variable and having it split between two.
I noticed this too and assuming the fix will come in the final release.
The Wireless settings issue was fixed last night and also sent upstream. However I am unable to reproduce the dnsfilter issue so far.
No. What I mean is there are 6 separate variables:
nvram unset dnsfilter_rulelist
nvram unset dnsfilter_rulelist1
nvram unset dnsfilter_rulelist2
nvram unset dnsfilter_rulelist3
nvram unset dnsfilter_rulelist4
nvram unset dnsfilter_rulelist5
nvram commitIf
dnsfilter_rulelist is one of the variables that's been moved to /jffs/nvram then what you're seeing is normal (you're using nvram show aren't you). The first blank entry is the stub that's left in nvram and can be ignored.
Right, I believe Asus uses dnsfilter_rulelist for their mobile app features, in which case they probably defined it as a "large_nvram" within wlcsm, and stored it to JFFS. Which leads to another possibility: is the JFFS partition full?
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!