01-05-2017 11:03 AM - edited 05-02-2017 07:09 AM
*** This post was last edited May 2, 2017 ***
Good morning Community,
As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.
However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.
In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂
UDP Packet Loss
The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.
Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).
Bufferbloat
When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.
Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.
The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.
Update April 22: This problem seems resolved in firmware 2.0.10.27
5 GHz WiFi Low range for channels 36 to 48
Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.
Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.
Workaround: manually select higher channels (149-153-157-161)
Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27
Loss of OFDM Channel Lock
Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.
Update April 12: This problem is resolved in 2.0.10.26T2
List of connected device does not get fully populated
This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.
The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.
NAT Loopback not working for wired clients
When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.
Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)
LAN Counters not working
Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.
This problem has been reported to Hitron for investigation.
Unexpected modem reboot
Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.
Update April 12: This problem is resolved in 2.0.10.26T2
Missing SC-QAM Channels
After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.
Investigation continues with Hitron.
WiFi Survey
The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.
Guest Network
When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless". This has been reported in firmware 2.0.10.26T2.
Update April 22: This issue has been resolved in firmware 2.0.10.27
Update May 2: It seems this issue is not fully resolved and still experienced by some users
Future Planned Improvements
The following are items that we are working on in parallel of the above.
Dave
*Edited Labels*
02-21-2017 09:29 AM
.24
003 days 13h:55m:14s Uptime now
http://www.speedtest.net/my-result/6071096318
Ping 19ms
Dwl 319 mbs
Uplod 19,60 mbs
Even after 3 days of uptime speeds not going down, .24 definetely more solid.
02-21-2017 11:21 AM
@Alex4161 wrote:
One issue I have been seeing for some time is that if you dont use any of your wired or wireless devices for several hours you lose network connectivity. I turned my laptop on this morning connected to a cat 6 cable and did not get any internet access. I then tried to access the web on my google pixel and as soon as I did that the cat6 network connectivity was restored on my laptop.
Has anyone else had this issue?
thanks
I have experienced that too, but in my case even after login in to modem webpage, the wireless and wired connections had no internet access. Had to reboot. This as now happened twice, and like you its always been first thing morning, no or litte activity during night.
02-21-2017 12:53 PM
@JohnBeaudin The speed issues have been effecting Gigabit customers, people on lower speeds always will be the one to say things look great but us Gigabit users have speed issues on every firmware. Its the GTA users with Gigabit for the most part working good.
02-21-2017 12:59 PM
Yes the issues will be more frequent on the GIGABIT because the gigabit is pushing to the extreme the rogers infrastructure.
Even thought I am on 250, I still had problems on previous firmwares versions that are now solved on .24 so it's still progress.
The reason I am not on GIGABIT yet is because there is still too many issues, but once everything is settled I plan to move on GIGABIT but that probably won't be until a few months for sure.
02-21-2017 01:02 PM
@AccordXTC wrote:@JohnBeaudin The speed issues have been effecting Gigabit customers, people on lower speeds always will be the one to say things look great but us Gigabit users have speed issues on every firmware. Its the GTA users with Gigabit for the most part working good.
Not entirly true, I don't have gigabit and had severe issues with speed degridation and latency over time. .24 fixed these issues. The gigabit customers have a seperate issue of the network just not being able to provide the advertised speed in certain areas.
The issue that .24 was supposed to fix, it fixed and it is working as intended. It was meanto t resolve speed degridation over time, not resolve missing speed all togeather.
02-21-2017 01:16 PM
@AccordXTC wrote:@JohnBeaudin The speed issues have been effecting Gigabit customers, people on lower speeds always will be the one to say things look great but us Gigabit users have speed issues on every firmware. Its the GTA users with Gigabit for the most part working good.
I am in GTA (Scarborough East) and NOT getting Gig speeds....Still waiting for a FIX on the Node to the CMTS server (where ever that is). Best speed achieved once was 532/32-8 to closest Rogers' Server ....but after that downhill again. Some folks in GTA are getting close to Gig speeds...but not in my area. It's plain and simple Rogers Infrastructure....Docsis 3.0 is capable to handle up to 1Gbps ....and some folks on non Coda 4582 are able to get these speeds. Docsis 3.1 is able to handle up to 10Gbps.....and once Rogers gets the infrastructure and their equipment at the headend upgraded....we can get near Bell Fibe speeds as well (hopefully this year?)
02-21-2017 01:19 PM
Pretty sure it's their intention to match bell Fibe speed, since it's their competitors, they also need to match the latency or at least make it better.
But heard it's all in the works.
02-21-2017 01:33 PM
02-21-2017 01:43 PM
@MarkR1989 wrote:
Have there been an updates regarding the AC2600 router compatibility in bridge mode? Still not establishing an IP address. Last update on the first post said it was most likely going to be addressed on .21 in January. I'm still on .19, but seem to see lots of people on .24. Would really like to get my setup working again. I have been waiting for a few weeks for this to be addressed
Look at page 1 for updated fixes. Here's the one of interest to you.
Issues getting an IP in bridge mode
We have been able to reproduce this on D-Link routers. It is an bug in the D-Link firmware (DD-WRT doesn’t have the bug) but we are looking at ways to mitigate it from the modem side.
If this issue occurs routers other than D-Link, let me know as I’ll need to investigate further.
Also reported but not tested on: TPLink C2600 and Netgear WNR2000v5
Update Jan 10: A problem was identified in the way D-Link routers are executing a DHCP request and a workaround is being put in place. The fix will likely address the TP-Link case as well. This fix will be included in firmware 2.0.10.21.
02-21-2017 01:45 PM - edited 02-21-2017 01:48 PM
@JohnBeaudin wrote:Pretty sure it's their intention to match bell Fibe speed, since it's their competitors, they also need to match the latency or at least make it better.
But heard it's all in the works.
On the speed, yes, they have to compete, but don't forget that Bell's reach for gigabit is tiny in comparison to Rogers' cable network reach.
On the latency, I'd wager than 99% of Rogers' customers don't care if latency is 25ms or 5ms. They won't notice a difference. 90% of users probably wouldn't even notice 75ms vs 25ms latency. Now gigabit users are a different breed, so I'm not entirely sure what the priorities will be here.
02-21-2017 01:52 PM
I can see on this forum many people complaints about latency, and with the new generation there will be more gamers and even more people that will care about latency, better fix it now and stay competitive.
02-21-2017 01:53 PM
Quick question - I am on .24 now and this is by far one of the most stable connections I have had with this modem. Previously I had been unable to use my DLink router in bridge mode. If I try to do this now and it doesnt work for any reason, will a factory reset set me back to .13 or .24? Thank you.
02-21-2017 02:45 PM
@JohnBeaudin wrote:I can see on this forum many people complaints about latency, and with the new generation there will be more gamers and even more people that will care about latency, better fix it now and stay competitive.
Except, relative to the total number of subscribers, the couple dozen people here are completely negligable.
Rogers' network reaches 4 million homes. They have about 2 million TV subscribers, and I'd estimate about 1.6 million cable internet subscribers based on what I can find.
Keep in mind that the current latency is already acceptable in most cases, for the vast majority of players. Could it be better? Yes. But there's still a fraction of a percent that this would affect. Cost/benefit may not dictate that it's worth doing anything about.
02-21-2017 02:49 PM - last edited on 02-21-2017 03:06 PM by RogersPrasana
We're already working on improving the routing so we get a much better latency on us servers, and also fix for udp to come in next firmware versions that will help in there as well.
02-21-2017 03:25 PM
@rk72 a factory reset will reload the default settings and reboot back into Gateway mode with .24 running. To move to any other version, either up or down, takes another firmware load from the CMTS. You would know if that happened. If you want to switch the modem from Bridge mode to Gateway mode, you can log into the modem in Bridge mode using 192.168.100.1 Then navigate to the BASIC .... RESIDENTIAL GATEWAY page and enable the Residential Gateway Function. The modem will reboot back into Gateway mode with its previous settings intact so you don't have to reset everything just because you switched back to Gateway mode.
If you had .24 loaded onto your modem today, run a modem restart at the very least, that is, pull the power, wait for 30 seconds and plug the modem back in again to force a restart. If you have any issues, you can always run a factory reset, which should ensure that the modem operates as it is intended with the current firmware load.
02-21-2017 04:09 PM
I can confirm that the .24 firmware does indeed work in bridge mode with my Dlink 868L router. Hopefully it will work with yours as well. I hope that is helpful. A factory reset will not revert you to a previous firmware revision.
02-21-2017 04:12 PM
I will say that the .24 firmware is definitely excellent and a big step in the right direction, however, I am still having *massive* congestion issues during peak hours. Last night in the evening I wasn't even able to get 100mbps download speed on *any* of the Speedtest servers. Just brutal. Hopefully Rogers can figure this out. I wasn't having this issue on DOCSIS 3.0, only on DOCSIS 3.1 with the new Coda modem.
02-21-2017 04:15 PM
02-21-2017 05:13 PM - edited 02-21-2017 05:21 PM
I'm going to be the odd one out and say .24 is a nightmare for me. Nothing but latency / packet loss issues...
.19 was much more stable for me. Pinging 8.8.8.8 starts off nicely under 100 ms (30-60ms usually), then goes to a few hundred ms ping, then into the thousands and times out half the time. Rebooting the modem only fixes it for a few minutes then it re-occurs.
I'm going to go swap the modem at the store to roll back as the tech support agents could not push me back to production .19 firmware.
I did try to factory reset it after the .24 got pushed but this didn't seem to do anything. I also tried various ports for the bridge mode and tried it in residential gateway mode, but no dice. I even moved my AP away from the modem into another room and while this seemed to help somewhat it is still problematic.
Here is my CODA signal info on .24:
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 591000000 | 256QAM | -4.600 | 31 | 38.605 |
2 | 363000000 | 256QAM | -5.800 | 10 | 37.356 |
3 | 369000000 | 256QAM | -5.600 | 11 | 37.356 |
4 | 375000000 | 256QAM | -5.900 | 12 | 37.636 |
5 | 381000000 | 256QAM | -6.100 | 13 | 37.636 |
6 | 387000000 | 256QAM | -5.900 | 14 | 37.356 |
7 | 393000000 | 256QAM | -5.900 | 15 | 37.636 |
8 | 399000000 | 256QAM | -5.600 | 16 | 37.636 |
9 | 405000000 | 256QAM | -5.400 | 17 | 37.356 |
10 | 411000000 | 256QAM | -6.100 | 18 | 37.636 |
11 | 417000000 | 256QAM | -5.400 | 19 | 37.636 |
12 | 423000000 | 256QAM | -5.400 | 20 | 38.605 |
13 | 429000000 | 256QAM | -5.300 | 21 | 38.605 |
14 | 435000000 | 256QAM | -5.200 | 22 | 38.605 |
15 | 441000000 | 256QAM | -5.200 | 23 | 38.605 |
16 | 447000000 | 256QAM | -4.800 | 24 | 38.983 |
20 | 573000000 | 256QAM | -5.200 | 28 | 38.605 |
21 | 579000000 | 256QAM | -4.800 | 29 | 38.605 |
23 | 357000000 | 256QAM | -5.900 | 9 | 37.636 |
24 | 597000000 | 256QAM | -5.100 | 32 | 38.605 |
25 | 603000000 | 256QAM | -4.500 | 33 | 38.605 |
26 | 609000000 | 256QAM | -5.100 | 34 | 38.983 |
27 | 615000000 | 256QAM | -4.600 | 35 | 38.605 |
28 | 621000000 | 256QAM | -4.100 | 36 | 38.983 |
29 | 633000000 | 256QAM | -3.800 | 37 | 38.983 |
30 | 639000000 | 256QAM | -3.600 | 38 | 38.983 |
31 | 645000000 | 256QAM | -3.600 | 39 | 38.605 |
32 | 651000000 | 256QAM | -3.800 | 40 | 38.605 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | NA | NA | NO | NO | NO | NA |
1 | NA | NA | NO | NO | NO | NA |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 23700000 | ATDMA - 64QAM | 41.500 | 2 | 6400000 |
2 | 38595727 | ATDMA - 64QAM | 46.750 | 3 | 3200000 |
3 | 30596000 | ATDMA - 64QAM | 42.750 | 1 | 6400000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
1 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
I was told DOCSIS 3.1 is available in my area, but my modem lights have only ever been blue, never purple (I believe I saw in this thread somewhere that download should be purple if on 3.1, and blue if on 3.0). I also don't see anything for OFDM on the stats above to confirm DOCSIS 3.1.
Does anyone have any suggestions for me? I'm going to swap the modem now to get back to .13, then ask for an upgrade to .19 or wait for overnight upgrade.
Cheers
Edit: some PingPlotter info to show you how bad it really is for me....
Target Name: google-public-dns-b.google.com
IP: 8.8.4.4
Date/Time: 2017-02-21 5:07:35 PM - 2017-02-21 5:17:35 PM
Hop Sent PL% Min Max Avg Host Name / [IP]
5 230 0 15.07 2317.57 363.22 pos-0-0.gw01.pr.phub.net.cable.rogers.com [66.185.81.174]
6 230 0 12.08 2283.64 361.23 209.148.230.2 [209.148.230.2]
7 230 0 11.90 2248.83 358.99 72.14.222.87 [72.14.222.87]
8 230 0 9.73 2218.87 356.97 209.85.255.197 [209.85.255.197]
9 230 0 11.20 2182.42 362.07 108.170.234.17 [108.170.234.17]
10 230 0 26.35 2488.39 379.88 google-public-dns-b.google.com [8.8.4.4]
Target Name: www.google.com
IP: 172.217.1.36
Date/Time: 2017-02-21 5:07:26 PM - 2017-02-21 5:17:26 PM
Hop Sent PL% Min Max Avg Host Name / [IP]
5 230 0 9.05 1665.92 355.44 66.185.81.174 [66.185.81.174]
6 230 0 10.77 1633.80 353.44 209.148.230.2 [209.148.230.2]
7 230 100 0 0 0 3021-dgw01.mtnk.rmgt.net.rogers.com [209.148.232.50]
8 230 0 12.37 1669.18 357.42 209.85.242.13 [209.85.242.13]
9 109 1 25.16 1611.25 376.53 216.239.46.162 [216.239.46.162]
10 88 0 24.02 1603.41 374.11 216.239.50.235 [216.239.50.235]
11 183 0 22.62 1487.40 367.06 108.170.243.225 [108.170.243.225]
12 177 0 23.71 1571.08 365.88 216.239.41.163 [216.239.41.163]
13 230 0 22.88 1557.43 360.76 www.google.com [172.217.1.36]
Look at this one, 100% Packet Loss....
7 230 100 0 0 0 3021-dgw01.mtnk.rmgt.net.rogers.com [209.148.232.50]
02-21-2017 05:30 PM - edited 02-21-2017 05:31 PM
@notregistering wrote:I'm going to be the odd one out and say .24 is a nightmare for me. Nothing but latency / packet loss issues...
Do you have a black-dot modem? How long ago did you get it?
I see missing channels in your listing, might be a problem as well.
Pinging www.google.com should be in the low double digits, at least it is for me. I have a constant ping running to google 24/7:
Ping statistics for 172.217.1.100:
Packets: Sent = 20440, Received = 20440, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 182ms, Average = 10ms
Pinging 8.8.8.8 comes in the mid 20's for me.
02-21-2017 05:35 PM - edited 02-21-2017 05:37 PM
@notregistering I would need to see the whole trace to see the top numbers. You can delete the 2nd IP if you prefer, or just delete the last figure(s). That's the CMTS. The first hop is the modem or router, which is an internal address only, so, there's no problem posting that as its only IPV4. I'd like to know if the problem starts at the CMTS and I can't see that without the top data. You can always send that to me in a private message. Click on my name to get to my public page. On the right is a link to "Send this user a private message" Follow that link to the message composition page, which will already be addressed. Add a title and details and hit send. Watch for a number overlaid on your avatar at the upper right when you're logged into the forum. Follow that link to the next menus and drill down to the inbox for the response.
If your modem does not have a black dot near the power cord, swap it at the nearest Rogers store and then ask for .24 That should make a considerable difference in the performance.