Ah, yes, I am positively, absolutely, 100% sure, after running numerous trial versions preceding .24 and .26. It wasn't standard procedure to roll back to a previous version if a Factory Reset was run. If a roll-back to a previous version happens, its due to some technical reason specific to the version in question. If Dave decides to make that standard procedure, ok, it is what it is. Until the recent change, my standard procedure was to run a Factory reset after a trial version was loaded, coming out of the reset and reboot with the trial version intact on the modem, so, yes, I'm sure.
@RogersDave explained this when he came up with the workaround for IPv6 bugs in early CODA-4582 firmwares.
Old way: modems booted up with whatever firmware and connected to the network. A day or two later, a script ran that checked all modems' firmware, and updated modems to the newest release firmware unless the modem was on an exception list. If you join the trial program, Dave puts you on the exception list and manually updates your firmware. If you factory reset, you keep your trial firmware.
New way: modems boot up, and if they have any version other the right one, they get immediately updated to the 'right' one. To avoid this happening with trial participants, Dave sets a setting in the trial participants' modems so that they won't be downgraded back down. When you do a factory reset... whoooooooooops... that setting is removed along with the others, so the modem reboots and promptly updates ('downdates'?) itself to the version that the CMTS mandates.
This whole thing was done so they could reenable IPv6 on the 4582 without the IPv6 bugs affecting new 4582s for a day or two...
What is it that you were doing that needed a factory reset as opposed to just a reboot? I think this is there as an emergency bail-out situation. The last thing we want is to be on a beta firmware, find out that it's not so great, then have to suffer with it.
Keep in mind that you can backup your settings and restore them at any point, which may give you the same benefit that you find with a factory reset.
For this modem it is not an "emergency bail-out situation" -- it's a necessity, has always been, from the very beginning. Also I've been in the beta since CGN days (which is like almost 2.5 years by now) and at the beginning you were able to do a reset without reverting to a public release fw. Now it's just silly because the modem's performance degrades rapidly, and after 2 updates it lags so badly it's unusable.
@Vikentieff are you running a VPN for extended periods of time by any chance. Just trying to figure out why you would see a huge drop in performance. I don't reboot my modem unless its had a very recent update or unless I switch from Bridge to Gateway mode or vice versa for test purposes.
I haven't checked this with IPV6 but with IPV4 I'm seeing packet loss. I'm coming to the conclusion that there's something strange going on with .27 when it comes to pingplotter returns from the CMTS. I was playing with that just now in IPV4, pinging the CMTS and when the modem is in Gateway mode there is packet loss reported from the modem when the ping interval is less than 1 second. Its also possible to see the occasional packet loss report from the CMTS, but that isn't usual from what I can see. Remember this is only going as far as the CMTS. When you go beyond the CMTS, say for example google.ca, at 1 second ping interval I might see the odd packet loss report from the modem. If I reduce the ping interval below 1 second, something trips at some point and the packet loss becomes a regular occurance from both the modem and the CMTS, ending up around a continual 45% or so. So that is definitely odd. That didn't happen on previous modem firmware versions.
I don't have time at the moment to repeat this in Bridge mode thru the router, but, I played very briefly with that last night and ended up with packet loss indicated from the modem and CMTS with a ping time less than 1 second. I'd like to have a better look at that to confirm it, but, don't have time until later this evening.
So, from what I can see, running 1 second intervals should take care of this for now. The ultimate fix is to fix the modem.
If you ever doubt the pingplotter results, bring up a command prompt and ping the same address or any point along the way: ping xxx.xxx.xxx.xxx -t That will confirm or deny the pingplotter packet loss report.
Use Command C to bail out
@toolcubed what are you using for the IPV6 DNS address in your Asus router?
And, are you using the AI Protection by any chance. I think that uses site reputation and doesn't necessarily scan any or all IPV4 packets. From what I've seen using speed tests with all or some of the components of the AI Protection enabled, it looks as though IPV6 packets are scanned, which will drop the throughput rate considerably. Try running the speedtest at:
With IPV6 enabled that should show both IPV4 and IPV6 results separately. You have to run through one test before you can access the advance settings which is nothing more than site selection. You can then choose Detroit as the nearest server. Using that site, try different components of the AI Protection. That will give you a pretty good idea of how much of a drop the AI Protection imposes, if in fact you are using it.