*** 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.
- Improvement in WiFi speeds
- Improvement in latency / bufferbloat
Dave
*Edited Labels*
I just received some information regarding the upcoming software versions for the CODA-4582.
I will add more details in the release notes in the next couple of days but I'm trying to be as transparent as possible in the meantime.
Version 2.0.10.28T2
This version of firmware is identical in functionality to 2.0.10.27. The only difference is that it contains some changes to branding and images.
This version will go live in production at some point in June and won't be tested on this forum.
Version 2.0.10.29
I have received this version and should be able to start deploying it to a few modems tomorrow and gradually for the rest of the week. I will accept volunteers for the first batch via PM.
The most important changes are:
- IPv6 DNS settings
- IPv6 Firewall
- Wireless encryption GUI fixes
- Guest SSID
- WiFi special characters
Version 2.0.10.30
I should receive this version mid next-week. This version will include the same fixes as 2.0.10.29 +
- WiFi performance improvement (increased speed)
- MoCA (not confirmed)
These release notes are a subset of everything. I'm trying my best to extract what is relevant while keeping it clear.
Dave
@RogersDave can you elaborate on the 4582 MoCA implementation? Is this intended for use with the Hitron MoCA extender only, with Rogers Cable modems only, or with other MoCA adapters such as the Actiontec adapters? Or is the implentation wide open for use with any other MoCA device? The 4582 datasheet indicates " MoCA 2.0 bonding provides a near Gigabit wired backbone in the customer’s home for Wi-Fi extension. " and shows a Hitron wifi extender connected via MoCA, so, its not clear if the 4582 MoCA implementation is intended for use solely with the Hitron MoCA extender.
http://www.hitron-americas.com/product_category/ethernet-wifi-extender/
@Datalink wrote:@RogersDave can you elaborate on the 4582 MoCA implementation?
The intent is to support MoCA extenders in the future but we are trying to provide enough flexibility so that a customer can use his own extender if he wishes to do so.
That being said, there are a few things missing in the current build (privacy settings) but we are working towards that.
Dave
@traghipp in theory you should be able to remove the MoCA adapter that is connected to the modem. However, if you are using the privacy settings on the MoCA adapter, you would have to keep using the adapters as the Modem MoCA privacy settings are not included in this trial build. All MoCA adapters either have to be using the privacy settings, or running in the clear. Personally speaking, even though encryption does cost, in terms of throughput, I'd rather run encrypted than unencrypted. You should also have a MoCA filter attached to the end of the cable as it comes in from the street, or utility pole. That prevents your MoCA data from exiting the home, encrypted or not, and would prevent the MoCA data from any of your neighbors from entering your home cable network.
- last edited on by
RogersTony
CODA-4582 refuses to give out IP addresses
We recently started using the new CODA-4582 router and it worked great for a while, but recently it's been giving us a bit of trouble. For some reason, after being on for a few hours, it stops giving out valid IP addresses; instead, it gives our devices bogus addresses like the one below:
(sorry about the French; it's "IPv4 Address", "Subnet Mask", and "Router IP", in order)
However, everything works if we give the device a static IP (but I'd rather not have to do that for every single device we own, and it wouldn't work for our guests). We got our router replaced by the local Rogers store but the issue is still present. We tried factory resetting the router a few times to no avail. It started happening about a month ago on/off, but it's been getting worse lately. Is there any way to solve this problem?
Just to confirm, are you using the modem in Gateway mode as modem and router, or in Bridge mode, with a stand alone router after it? It doesn't make sense that you would have the same issue with two modem, and thats just a comment in general for any modem. In cases like this I would suspect a device has a LAN IP address set as a hard address that isn't agreeing with the modem. Perhaps the IP address is outside of the address range of the modem and the modem isn't happy with it ??
Edit: ok, that looks like a default device IP address when the modem or router DHCP fails to provide an address, or can't in the case where a pc, laptop or other device boots up without a connection to a DHCP server. If I had that issue, I would enable or connect one network at a time, such as ethernet, then 2.4 Ghz wifi, then 5 Ghz wifi, looking for the point where the modem fails to give out a LAN IP address. I'm going on the assumption here that there is a problem with a specific device that is causing the DHCP server on the modem to fail. A step by step approach should allow you to determine if that is the case.
You might be able to do this fairly fast by doing it in groups.
Pick a group, say ethernet devices first, turn off the 2.4 and 5 Ghz wifi and reboot the modem. See what happens when the ethernet devices receive their LAN IP address after the reboot, all as a group instead of one by one. Look for the existing problem.
Then if you don't see anything untoward happen, turn on the 2.4 Ghz wifi. Look for the issue to come up.
Lastly, turn on the 5 Ghz wifi and watch for the issue to come up.
You could always disconnect the ethernet devices except perhaps one pc or lapotp. Turn on one of the wifi networks and reboot the modem. While the modem is rebooting, disconnect the last ethernet device so that the only network running after the reboot is the wifi network. Then do the same with the other network. Enable the 5 Ghz network, turn off the 2.4 Ghz network and reboot the modem. In each case, what you would do is assign the IP addresses in batches, ethernet, then 2.4 Ghz network, then 5 Ghz network.
Hopefully, by doing this network by network, that will help to determine which network is at fault. Then you can drill down into the network device by device to find the culprit.
@joedrew, this isn't a typical or known issue at this point with this modem. Can you log into the modem and check the Software (firmware) Version on the STATUS tab and let me know what that is. If it is V2.0.10.27, please have a look at the DOCSIS EVENT log, also in the STATUS section and look for:
SW Download INIT - Via NMS
SW download Successful - Via NMS
I'm wondering at this point about the firmware version and whether or not that was updated to that version in the last two to three days.
If you have .27 loaded, have you already restarted the modem, as in pull the power from the modem and reapply power? In the post just above yours is a procedure that I posted to locate any devices connected to the modem that might be causing a problem. Can you read thru that and consider running that procedure? When the DHCP fails, is it an immediate failure, as in you restart the modem and the problem comes up immediately, or does it take minutes/hours to occur?
So if we have .29 firmware is it the same as before if we do a Factory Reset it will go back to the older Firmware?
Downstream Overview
| Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
| 1 | 639000000 | 256QAM | 0.500 | 14 | 38.605 |
| 2 | 849000000 | 256QAM | -2.200 | 2 | 36.610 |
| 3 | 855000000 | 256QAM | -2.200 | 3 | 36.387 |
| 4 | 861000000 | 256QAM | -2.400 | 4 | 36.387 |
| 5 | 579000000 | 256QAM | 1.200 | 5 | 38.983 |
| 6 | 585000000 | 256QAM | 0.700 | 6 | 38.605 |
| 7 | 591000000 | 256QAM | 1.100 | 7 | 38.983 |
| 8 | 597000000 | 256QAM | 1.400 | 8 | 38.983 |
| 9 | 603000000 | 256QAM | 1.500 | 9 | 38.983 |
| 10 | 609000000 | 256QAM | 2.000 | 10 | 38.605 |
| 11 | 615000000 | 256QAM | 2.600 | 11 | 38.983 |
| 12 | 621000000 | 256QAM | 2.600 | 12 | 38.605 |
| 13 | 633000000 | 256QAM | 0.800 | 13 | 38.605 |
| 14 | 303000000 | 256QAM | -3.100 | 1 | 37.636 |
| 15 | 645000000 | 256QAM | 1.200 | 15 | 38.983 |
| 16 | 651000000 | 256QAM | 2.000 | 16 | 38.605 |
| 17 | 657000000 | 256QAM | 2.100 | 17 | 38.605 |
| 18 | 663000000 | 256QAM | 2.800 | 18 | 37.636 |
| 19 | 669000000 | 256QAM | 3.400 | 19 | 37.636 |
| 20 | 675000000 | 256QAM | 2.700 | 20 | 37.636 |
| 21 | 681000000 | 256QAM | 3.400 | 21 | 38.605 |
| 22 | 687000000 | 256QAM | 2.900 | 22 | 37.356 |
| 23 | 693000000 | 256QAM | 2.900 | 23 | 37.636 |
| 24 | 699000000 | 256QAM | 3.700 | 24 | 37.636 |
| 25 | 705000000 | 256QAM | 3.300 | 25 | 37.636 |
| 26 | 711000000 | 256QAM | 3.800 | 26 | 38.983 |
| 27 | 717000000 | 256QAM | 2.900 | 27 | 37.636 |
| 28 | 723000000 | 256QAM | 3.200 | 28 | 37.356 |
| 29 | 825000000 | 256QAM | 1.300 | 29 | 37.356 |
| 30 | 831000000 | 256QAM | 0.500 | 30 | 37.636 |
| 31 | 837000000 | 256QAM | -0.300 | 31 | 37.356 |
| 32 | 843000000 | 256QAM | -1.100 | 32 | 36.387 |
OFDM Downstream Overview
| Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
| 0 | NA | NA | NO | NO | NO | NA |
| 1 | 4K | 275600000 | YES | YES | YES | -1.700001 |
Upstream Overview
| Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
| 1 | 30596000 | ATDMA - 64QAM | 45.500 | 1 | 6400000 |
| 2 | 38595727 | ATDMA - 64QAM | 47.500 | 3 | 3200000 |
| 3 | 23700000 | ATDMA - 64QAM | 44.000 | 2 | 6400000 |
OFDM/OFDMA Overview
| 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 |
@Triple_Helix, yes, its the same situation. If you run a Factory reset with .29 loaded, your modem will revert back to .27 during the reset. A modem restart or reboot retains .29 on the modem.
Hello @Menkhor, welcome to the forum.
The simple short answer is: no
The long answer:
In terms of loading any additional firmware on an ISP or customer owned modem, that won't be allowed, not only by Rogers, but by any other ISP around the world. That is due to security and network operational concerns.
In terms of QOS, that is a much larger discussion. With the 4582, you probably won't need to run QOS for any service plan, unless you happen to have a bandwidth hog on your network that you are looking to throttle. Intel has done a lot of work for V2.0.10.27, which is the current network firmware version for the 4582. That effort has been on packet scheduling with the aim of reducing latency thru the modem. Here's a link to a post by @RogersDave with his FLENT test for version .26 and .27. This is a simultaneous input/output ping test, essentially a test under load:
If you look at that test, you can see that there is a significant reduction in the ping time thru the modem under load. Gamers in the crowd who are using the 4582 with V2.0.10.27 have reported better gaming latency results with that combination. The modem itself, with any internet plan should be able to provide the necessary response under load.
Now, having said that, if your intention is to throttle a bandwidth hog that is taking up too much bandwidth at any given time, that's a different matter altogether. To do that you would need a router and no matter which router you might buy, running QOS comes with a throughput penalty as the router processor has to look at each packet, inbound and outbound to determine where it fits in with the priority scheme. So, instead of the router running flat out in terms of throughput, you will see a reduced throughput.
A good many routers use Broadcom chipsets which have Cut Through Forwarding (CTF) and Flow Acceleration (FA) proprietary modules built into the firmware. This is proprietary technology, designed by Broadcom. Doing some quick reading, it looks like Tomato supports CTF, don't know about FA, but, as with other routers with stock firmware, functions such as QOS, Traffic Management or monitoring, Parental controls and a few others will disable CTF automatically. Without the CTF enabled, a gigabit router will probably drop to 200 to 300 Mb/s in terms of throughput. Add the processing required for QOS and you might be down well below 200 Mb/s. That will depend partly on the router processor speed itself.
Running QOS successfully will depend on your internet plan service rate and the horsepower of the router itself. Its possible that if you bought a typical consumer router with a fast processor, by that I mean 1.4 or 1.8, preferably a 1.8 Ghz processor, you might be able to run QOS on a 100 or 250 mb/s downstream plan without seeing any large performance penalty. If you wanted to do that with a 1 Gb/s downstream plan, you would need a much faster processor which leads you into a PfSense, OpenSense, Sophos UTM type of router, and that is a step above a consumer router and then some. At that level, although its possible to buy something like a PfSense router, a good majority of people build theirs, which is essentially building a computer and loading it with the router operating system instead of Windows or linux.
Fwiw, here's a link to the procedure on setting up QOS on a PfSense router:
https://turbofuture.com/computers/How-to-Configure-Deep-Packet-Inspection-Using-pfSense
So, hopefully that gives you enough information to consider and to decide what the next step is.
-
480683 views
-
295 Likes
-
-
