Love BRIDGE Mode -- very stable with .33
@Triple_Helix wrote:@I have to disagree as the default Firmware doesn't make the modem reboot like .33 and .33T2 so hopefully @RogersDave and Hitron can find the issue and correct it.
I'm just saying on the last few pages were seldom reports about actual FW issues, but what was perceived as "modem reboot", whether it was in fact reboot or not, and regardless what was causing the issue observed (or not observed, but seen in the log). For example, many reported
"90000000 warning MIMO Event MIMO: Stored MIMO=1 post cfg file MIMO=-1;CM-MAC=xx;CMTS-MAC=xx;CM-QOS=1.1;CM-VER=3.1"
event, but this event is in fact Modem Reset upon receiving a new config file from CMTS. Would you classify it as FW bug? 
It usually happens on manual reboot by pressing Reset button, or CMTS periodically pushing a default config for the member sub, while modem is running the trial FW config, so there is a mismatch causing modem reset upon config update.
Not every perceived issue a subscriber might face or doesn't observe but presume happening is "modem reboot" or related to trial FW. What I suggest is to post detail logs, so we all can observe and learn whether there was a problem, and what if anything caused it. Also, pls explain, what log events do you classify as "modem reboot" and link to defective trial FW? 
@RyzenFX wrote:
Dave and Hitron are already aware that there is a reboot issue with firmware .33 and .33T2. The MIMO event in the DOCSIS logs is there to indicate that yes, the modem did infact reboot, but NOT because it received a new config file from the CMTS. There is an underlying issue causing the modem in .33 and .33T2 to reboot for some reason.
With that being said, my 6 day uptime streak has ended as the modem ended up rebooting. My new LAN uptime is:
LAN Up Time 000 days 12h:58m:57s
Right!
LAN Up Time 000 days 04h:16m:41s
@RyzenFX wrote:Dave and Hitron are already aware that there is a reboot issue with firmware .33 and .33T2.
The guy above your post said he manually reboot the modem. Yet you ignored his report and the linked SpeedGuide info, instead saying the MIMO event namely identifies "modem reboot" of unknown cause. Even that's fine with me, except one thing: are there any other issues with CODA FW apart from "modem reboot"? Suppose "Dave and Hitron" found and fixed the bug(s) causing periodic reboots - will that be the end of FW development, or it has some other problems you observe? If "yes", how they correlate with your internet use pattern?
@arnym21 wrote:In fact, RogersDave never replied to my very specific direct question, whether they in fact now able to dynamically look at specific modem usage, i.e. getting exact copy of trial participants traffic. Interesting ignorance in such critical issue from privacy & security standpoint.
I'm sorry @arnym21, this question was missed. The answer is simple however, trial firmwares are no different than production firmware in the availability of monitoring tools or logs. For any modem on the network, I have the ability to pull logs and performance metrics (signal level, uptime, configuration) but not actual traffic.
@mozerd wrote:In Gateway mode Rogers can dynamically look at every aspect of your gateway activities ... in Bridge mode Rogers do not have access to your private gateway and the only way to achieve that level of security and privacy is through your own router.
@mozerd, It is true that in gateway mode, we have the ability to see more information but the difference is essentially what can be seen in the GUI (connected devices, DHCP reservation, signal levels on WiFi, radio channels and port forwarding).
@arnym21 wrote:In any mode Rogers can record at the hub the entire traffic passing through the modem, and does record or proxy it under certain circumstances. That's what I was asking RogersDave about - whether they in fact use it for modem failure root cause analysis. In Gateway mode a Rogers tech can also look or scan your LAN layout and have more convenient access to login to connected devices if they wish to, including probably setting a WAN traffic proxy.
Yes traffic can be recorded in the core network but this is not an easy operation (we don't have equipment deployed permanently for this), requires a lot of planning and resources. Therefore, it is only performed in extreme circumstances and frankly I never had to do this for modem failure analysis.
With regards to scanning the LAN layout or access to connected devices, the access is the same as what is visible in the modem GUI. Techs can see the list of connected devices and through the diagnostic page, ping and/or traceroute to the IP addresses of the devices in the LAN. They can't "connect" to these devices.
WAN proxy is also not a supported on these modems.
--Dave
As some of you noticed, I just pushed firmware 2.0.10.33T3 to some modems. Hitron originally found a memory issue with the new code and fixed it in 2.0.10.32T2 which helped some of you. Given that reboots were still an issue, the R&D team kept looking and found a 2nd cause for the reboots which was addressed in 2.0.10.33T3.
With this version, I will update the modems for people who reported the issue in this thread and then for new participants pending access to the firmware trial. If everything goes well, I will update all the 2.0.10.33 to 2.0.10.33T3.
--Dave
@lethalsniper wrote:
@RogersDave off topic but i see some work going on just in front of my building just wondering if Telecom , confra are contracted by rogers ? Hopefully it's the end of my speed degration!
I can't confirm with certainty (I don't have access to the project details) but it does make sense yes.
Thanks Dave! That sounds re-assuring. Hope, we'll move on now from "modem reboot" to other bugs and missing features. Unless of course the reports will go on like this: "3 days, no reboots..." 
-
940031 views
-
669 Likes
-
-
