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*
03-11-2017 04:16 PM
Has anyone tried testing IPv6 in bridged mode using ....testmyipv6.com without a tunnel broker? My router and OS's are all IPv6 enabled but keep getting a message saying that the IPv6 server is only connected using IPv4.
This seems to be confirmed when using IPv6-test.com which scores a 17/20 and indicates IPv4 tunneling to reach the IPv6 site.
I thought the CODA is native IPv6 enabled.......but also thought that in Passthru or Bridged mode it should not matter .... maybe I am wrong? @RogersDave, @Datalink Perhaps the Coda is not fully IPv6 enabled yet and using IPv4 tunnel to connect to IPv6.
Also like to know if there are difference in the 4 ports....is there port priority or are they equally distributed. Previous modems only had port 1 active, when using Bridged mode.
03-11-2017 04:33 PM
@rjmaxim wrote:Has anyone tried testing IPv6 in bridged mode using ....testmyipv6.com without a tunnel broker? My router and OS's are all IPv6 enabled but keep getting a message saying that the IPv6 server is only connected using IPv4.
This seems to be confirmed when using IPv6-test.com which scores a 17/20 and indicates IPv4 tunneling to reach the IPv6 site.
I thought the CODA is native IPv6 enabled.......but also thought that in Passthru or Bridged mode it should not matter .... maybe I am wrong? @RogersDave, @Datalink Perhaps the Coda is not fully IPv6 enabled yet and using IPv4 tunnel to connect to IPv6.
Also like to know if there are difference in the 4 ports....is there port priority or are they equally distributed. Previous modems only had port 1 active, when using Bridged mode.
There appears to be many different test sites....this one now gives me a different result (http://test-ipv6.com)
Your IPv4 address on the public Internet appears to be XXX.XXX.XXX.XXX | ||
Your IPv6 address on the public Internet appears to be 2607:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx | ||
Your Internet Service Provider (ISP) appears to be ROGERS-CABLE - Rogers Cable Communications Inc., CA | |
Since you have IPv6, we are including a tab that shows how well you can reach other IPv6 sites. [more info] |
Good news! Your current configuration will continue to work as web sites enable IPv6. |
Your DNS server (possibly run by your ISP) appears to have IPv6 Internet access. |
Your readiness score | |
10/10 | for your IPv6 stability and readiness, when publishers are forced to go IPv6 only |
03-11-2017 04:53 PM - edited 03-11-2017 04:57 PM
If you only see a score of 17/20 on the ipv6-test.com site, you need to add an IPV6 rule to your Windows firewall rules.
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/create-an-inbound-icmp-rule
Add the IPV6 rule only. Then reboot the pc and rerun the ipv6-test.com test. If that still doesn't give you 19/20, add an outbound rule as well.
You should be able to use any port on the modem, whether its in Gateway or Bridge mode.
The IPV6 type set in the router should be Native IPV6.
Here is a link to Dave's IPV6 settings post:
03-11-2017 06:47 PM
@Triple_Helix wrote:
@RogersDave wrote:
@Triple_Helix wrote:Only 2 issues I continue to see.
1. Mobile devices keep dropping the 5G Wi-Fi signal
2. Upload speed is not consistent
@Triple_Helix, can you clarify what devices do you have that are impacted on 5 GHz?
I just made a small change to your modem for that. Let me know if it helps.
Dave
Yes it's my new Moto Z phone and I see that you set the 5G to Auto (Channel) so I will keep an eye for disconnects.
Thanks,
Daniel
Actually the change I made is not customer visible (actually it can only be done in the modem configuration file). I change the IPv6 RA interval to allign with RFC7772.
On the Pixel phone, this greatly improved stability.
Dave
03-12-2017 12:41 AM
@RogersDave ohh so thats why my pixel has been having so many issues with wifi, I thought I was going crazy.
03-12-2017 09:10 AM
@Breadwinka wrote:@RogersDave ohh so thats why my pixel has been having so many issues with wifi, I thought I was going crazy.
I reconfigured your modem with the new settings. Let me know if it works better.
Dave
03-12-2017 10:16 AM
03-12-2017 11:40 AM
@RogersDave wrote:
@Triple_Helix wrote:
@RogersDave wrote:
@Triple_Helix wrote:Only 2 issues I continue to see.
1. Mobile devices keep dropping the 5G Wi-Fi signal
2. Upload speed is not consistent
@Triple_Helix, can you clarify what devices do you have that are impacted on 5 GHz?
I just made a small change to your modem for that. Let me know if it helps.
Dave
Yes it's my new Moto Z phone and I see that you set the 5G to Auto (Channel) so I will keep an eye for disconnects.
Thanks,
Daniel
Actually the change I made is not customer visible (actually it can only be done in the modem configuration file). I change the IPv6 RA interval to allign with RFC7772.
On the Pixel phone, this greatly improved stability.
Dave
Would a Factory Reset affect the changes in the settings you did? I had to a couple of times to get all of my download channels back and now the problem has reoccurred and keeps dropping the 5G Wi-Fi for my Moto Z phone so I went to the 2.4G band and that works fine.
03-12-2017 12:26 PM
@Datalink wrote:If you only see a score of 17/20 on the ipv6-test.com site, you need to add an IPV6 rule to your Windows firewall rules.
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/create-an-inbound-icmp-rule
Add the IPV6 rule only. Then reboot the pc and rerun the ipv6-test.com test. If that still doesn't give you 19/20, add an outbound rule as well.
You should be able to use any port on the modem, whether its in Gateway or Bridge mode.
The IPV6 type set in the router should be Native IPV6.
Here is a link to Dave's IPV6 settings post:
Thanks for the info @Datalink....much appreciated!
My Router settings are correct. Not sure who owns/operates the "ipv6-test.com" site versus the open source "test-ipv6.com"...only difference appears to be the ICMP error message checking, which most OS's require a rule to be added as per your suggestion. For most of us, it's a bit tricky to play with firewall settings, particularly if you also have AV software involved. It's easy to mess up and potentially leave your system vulnerable. But you are right....to get a 19/20 score (although I don't know why it would not be 20/20)....you need to add an exception rule. Somehow, the Open source site is a bit clearer....explaing how they score a 10/10:
03-12-2017 12:43 PM - edited 03-12-2017 12:44 PM
@rjmaxim did you add the rule to the inbound rules only? Just curious.
You wil not see a score of 20/20 as Rogers does not supply an IPV6 host name. Its possible to see 20/20 if you connect to directly to the modem when its running in Bridge mode. However, as Rogers doesn't supply that IPV6 host name, what is observed as an IPV6 host name is false, incorrect, not true, or any other term one would prefer to use.
03-12-2017 01:16 PM
WoW I got over 40Mbps on the Upload side and I wish it was consistent.
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 591000000 | 256QAM | 3.600 | 7 | 37.636 |
2 | 567000000 | 256QAM | 3.900 | 3 | 38.605 |
3 | 573000000 | 256QAM | 3.000 | 4 | 37.356 |
4 | 579000000 | 256QAM | 3.700 | 5 | 38.605 |
5 | 585000000 | 256QAM | 3.100 | 6 | 38.605 |
6 | 561000000 | 256QAM | 3.500 | 2 | 38.605 |
7 | 597000000 | 256QAM | 3.600 | 8 | 37.636 |
8 | 603000000 | 256QAM | 4.100 | 9 | 37.636 |
9 | 609000000 | 256QAM | 4.900 | 10 | 38.605 |
10 | 615000000 | 256QAM | 5.000 | 11 | 38.605 |
11 | 621000000 | 256QAM | 4.500 | 12 | 37.636 |
12 | 633000000 | 256QAM | 3.700 | 13 | 37.356 |
13 | 639000000 | 256QAM | 3.600 | 14 | 37.636 |
14 | 645000000 | 256QAM | 3.100 | 15 | 37.636 |
15 | 651000000 | 256QAM | 3.200 | 16 | 37.356 |
16 | 657000000 | 256QAM | 3.100 | 17 | 36.610 |
17 | 663000000 | 256QAM | 4.500 | 18 | 37.356 |
18 | 669000000 | 256QAM | 5.000 | 19 | 37.356 |
19 | 675000000 | 256QAM | 4.900 | 20 | 37.356 |
20 | 681000000 | 256QAM | 6.000 | 21 | 37.636 |
21 | 687000000 | 256QAM | 4.900 | 22 | 37.356 |
22 | 693000000 | 256QAM | 5.400 | 23 | 37.356 |
23 | 699000000 | 256QAM | 5.200 | 24 | 37.356 |
24 | 705000000 | 256QAM | 5.300 | 25 | 37.636 |
25 | 711000000 | 256QAM | 5.200 | 26 | 37.356 |
26 | 717000000 | 256QAM | 5.400 | 27 | 37.636 |
27 | 723000000 | 256QAM | 5.900 | 28 | 37.356 |
28 | 825000000 | 256QAM | 5.800 | 29 | 36.610 |
29 | 831000000 | 256QAM | 5.800 | 30 | 36.610 |
30 | 837000000 | 256QAM | 6.000 | 31 | 36.387 |
31 | 843000000 | 256QAM | 4.600 | 32 | 36.387 |
32 | 555000000 | 256QAM | 3.200 | 1 | 38.605 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | 4K | 275600000 | YES | YES | YES | 0.500000 |
1 | NA | NA | NO | NO | NO | NA |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 23700000 | ATDMA - 64QAM | 42.750 | 2 | 6400000 |
2 | 38596000 | ATDMA - 64QAM | 45.750 | 3 | 3200000 |
3 | 30596000 | ATDMA - 64QAM | 44.250 | 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 |
© 2017 Hitron Technologies Inc.. All rights reserved.
03-12-2017 01:20 PM
@Datalink wrote:@rjmaxim did you add the rule to the inbound rules only? Just curious.
You wil not see a score of 20/20 as Rogers does not supply an IPV6 host name. Its possible to see 20/20 if you connect to directly to the modem when its running in Bridge mode. However, as Rogers doesn't supply that IPV6 host name, what is observed as an IPV6 host name is false, incorrect, not true, or any other term one would prefer to use.
Yes, I tried it on my test Win 10 machine. Followed the MS instructions and Created the rule....rebooted but did not work . It's tricky and Microsoft does not make it easy. I definetly won't do it on my main system.
03-12-2017 01:24 PM - edited 03-12-2017 01:30 PM
@RogersDave Do you have an idea when DOCSIS 3.1 upstream will be enabled? How's the progress wtih casa systems on this?
03-12-2017 01:27 PM
If I remember, I think almost all Rogers footprint will be on D3.1 within the end of March.
03-12-2017 01:31 PM
Oops, forgot the mention the word upstream. I know it's under some work but how's the progress?
03-12-2017 01:33 PM
Upstream, not until Summer, but no specific date yet.
03-12-2017 07:37 PM
This packet loss stuff going on really getting under my skin now. Kids tried to play game and was complete waste of time, they gave up and went out to Esports bar so they could play, pretty sad paying for internet and not be able to use it. Had to go exchange yet another pvr and asked the guy at the store if he has heard about problems with white modem, he started laughing and pointed to a bin full them, all returns. Looks like Rogers been pushing for these modems and people are bringing them all back.
@RogersDave, is rogers going to at least attempt and fix the packet loss issue? I'm at the point of calling and getting rogers to pick all this stuff up and jump ship. Calls to tech support uselless and nothing but waste of time.
03-12-2017 09:27 PM
These speed issue and bufferbloat is insant cant even watch youtube and browse the net or play games without lagging.
03-12-2017 09:57 PM
03-12-2017 10:00 PM - edited 03-12-2017 10:01 PM
I had to switch down to the CGNM-3552 b/c the UDP packet loss was pretty bad. I'm HOPING we tunnel vision into this issue this week so we can get significant progress on it, it really needs to get fixed quick. @RogersDave says might related to UDP fragmentation but we need to to be sure of it.
We need this issue fixed quickly.
03-12-2017 10:05 PM