*** 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*
@reefermajic69, the first thing to do is to force a restart on the modem. Pull the power from it, wait 30 seconds and plug it back in. After it boots up, log into it and kick it into Bridge mode. Leave the pc connected and reboot the pc as well. When the reboot into Bridge mode is complete, run a test at ipv6-test.com. That should show 4/20 as a final score as IPV6 is currently turned off on the modem. Then run a speedtest at www.speedtest.net Toronto Rogers or Beanfield or Montreal Rogers or Fibrenoire. Remember that the pc is relying on its own firewall for protection, so keep this time as short as possible. When that is done, take note of the speedtest results. I'll be interested in what you find.
Then run a Factory Reset on the router. That might hurt as you will have to reset the various parameters and pay very close attention to the LAN .... SWITCH CONTROL .... NAT Acceleration setting to ensure that it remains enabled. When the Factory Reset is complete, remove the power from it, connect it to the modem, and then power it back up. It should acquire an IP address from the modem and you should be able to connect to the router to set some minimal parameters for now. Disable items that you will not be using, but, at this point, don't enable anything perhaps beyond the AI Protection and the wifi. At this point you should run a speedtest to see what the results are. Depending on your CMTS and the loading on that CMTS, you may not see 900+ Mb/s at this time of the night. It wouldn't surprise me. You should however see the same data rate that you saw with a direct connection to the modem. Thats what you want to prove at this point. When you are done those tests, then I would go back into the modem and set the various parameters, once again, keeping an eye on the NAT Acceleration setting.
For the router, consider this. If you haven't really pushed the router with high data rates to this point, you may not have come across the same issues that others have. Lets see if you can get the router up to speed and go from there. I'm not keen on telling people to spend money, but, in the case of gigabit rates, end users are going to have to consider moving up from the usual consumer routers to something that can handle the higher data rates and provide the protection that they are looking for. That might mean moving to something like a Pfsense or Opensense router with an additional wifi only router such as the RT-87U as an access point. It depends on the stability of your 87U. Running gigabit rates is not going to be cheap. I have no hesitation in recommending other Asus routers, but my concern is whether or not they will actually handle the higher speeds. I don' t think there is a consumer router on the market these days that can adequately handle gigabit rates. There is a router that Asus is working on, the BRT-AC828. That is aimed at the business crowd apparently and hasen't been released yet from what I understand. In terms of it handling gigabit rates, I'll believe it when I see more reviews and test results. Thats going to be an expensive router. So, first things first, get the modem and router running at the data rates they should be at.
It should be on Auto and stay on Auto for the entire time that you are changing any other setting. Note that there was a new firmware version released in Dec so it would be worth running a check for that. On my RT-AC68U, with the new firmware, there is a note beside it that showed that both Cut Through Forwarding and Flow Acceleration were enabled initially after the firmware update. The Flow Acceleration portion of that note is new for the 68U. The fact that I run the AiProtection results in the Flow Acceleration being disabled. But, thats ok. I know that the 68U is underpowered for gigabit service although I can see speedtest results up to 950 Mb/s as everything else except for the wifi is disabled. So, that is something to keep in mind when you look at the NAT Acceleration.
Ok So I did all you ask and again same situation.
High with a direct connect but via the ASUS2400 it drops significantly 😞
One of the mods will have to approve the images so that they're publicly available, so, can't see them yet. The NAT Acceleration is still on Auto?
I'm guessing that the other images might contain your IP address, therefore the moderator didn't approve them. What are you seeing for speeds from the modem, and then thru the router? I'm assuming that they are run with ethernet connections in both cases.
I'm surprised that the speed thru the router is that low, especially given the download results out of the modem. The modem is running in Bridge mode correct. Stupid question, just want to be sure.
I'm going to have to think about that 87U and see what I can find. It should be able to keep up with the modem, but I'll have to do some searching.
As far as a router, that depends on what you are looking for, a stand alone firewall/router plus wifi access point, or a consumer class router similar in nature to the 87U. I would recommend anyone to think about a Pfsense router, but, not go low end. There is definitely a learning curve there. You can build our own pc and install Pfsense or even Opensense. For a consumer class router, restrict your search to Asus routers that have 1.7 Ghz processors, then consider routers with 1.4 Ghz processors. The AiProtection kills IPV6 datarates due to the packet scanning, so, processor speed is important. There are trade-offs in deciding which way to go. A Pfsense/Opensense firewall/router built on the right cpu will offer security and years of service. The consumer class adds wifi all in one box but, the CPU probably won't keep up to the data rates and offer the protection you might be looking for. So, there is some food for thought to consider. I haven't been router shopping recently so I'll have to see whats up in the Asus router line.
@Hybrid_Noodle wrote:@RogersDave There may be an issue with the Rogers Home Monitoring router (Netgear WNR2000v5) getting an IP address while the CODA is in bridge mode as after the .19 firmware push it appears as though the router has lost connectivity to the outside world.
@Hybrid_Noodle, Thanks I will have this tested.
@gp-se wrote:
In terms of the exchange program for users with the interference issue, how will those users know they are affected?
Is there a certain batch of serial numbers that are known to have the issue? I ask because I'm curious if my modem is affected and would need to be exchanged once the program launches.
@gp-se, I am not sure of what the communication channel will be all the way to the end-user but I will provide a list of affected modems to our product management team. They then could e-mail, call or send letters to affected users. The newer modems will have a distinctive mark on them as well so they will be easy to flag in store, at the warehouse and for end-users.
@Wizerobe wrote:I had the 250Mbps package hooked up yesterday (wednesday Jan 4th) and even up until this morning I had an average speedtest of 330Mbps, though as of tonight, I've been stuck at 5-10Mbps Down.
@Wizerobe, Can you send me a private message with you MAC address so I can have a look? Did you reboot your modem at least once after the upgrade to 2.0.10.19?
@14N wrote:
@RogersDave wrote:Issues getting an IP in bridge mode
Please check also TP-Link router, all users with TP-Link C2600 have this issue.
@14N, Noted.
@prateeck7 wrote:@RogersDaveI fail miserably at bufferbloat. I feel that is the reason I am doing bad at testmynet and speedof.me and when downloading files.
http://www.dslreports.com/speedtest/8450900
@prateeck7, I know this has been an issue for you for a while and I will be looking at your modem today. I needed additional tools which I was able to build only yesterday to investigate your case further.
Dave
-
494553 views
-
295 Likes
-
-
