*** 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 126.96.36.199 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).
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 188.8.131.52 but more likely in 184.108.40.206 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 220.127.116.11
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 18.104.22.168
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 22.214.171.124T2
List of connected device does not get fully populated
This is a known issue that has been tracked since firmware 126.96.36.199. 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 188.8.131.52T2 (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 184.108.40.206T2
Missing SC-QAM Channels
After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 220.127.116.11T2 to address this behavior but it has not corrected all scenarios.
Investigation continues with Hitron.
The WiFi Survey functionality in firmware 18.104.22.168T2 (and possibly before) reports incorrect SSID names.
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 22.214.171.124T2.
Update April 22: This issue has been resolved in firmware 126.96.36.199
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.
I have no idea what the Roku does while supposedly idle. I unplug it while at work and this week everything seemed settled as regards to lag spikes.
I am beginning to suspect that the lag issues I am having is related to the wireless on the coda in general. I am very tempted to by my own wireless router and test this theory. Any suggestion as to one to buy that won't break the bank?
So, I've got an interesting issue I'm not sure how to resolve.
It seems that often HTTPS negotiations are stalling for me, on multiple devices. When I refresh a page, they tend to load fine (sometimes two refreshes are required).
CODA-4582, Gigabit. Device is in bridge mode, connected to an Apple 802.11ac time capsule.
Now, here's the wrinkle - I just moved homes. The new home I'm in is a FTTP home - that is, there's a fiber terminator in my basement connected to a media converter, then a short run of coax in my home that leads to the CODA. That all but eliminates signal issues as the cause, AFAIK.
Data rates and latency are fine - I ran mtr for hours against google.ca and had less than 1% packetloss over the wifi connection and expected latency. That doesn't seem to be the problem.
as you'll see in this verbose curl connection however, when I try to make HTTPS requests, the connections almost always time out the first time or two at the HTTPS handshake. This happens on my imac, my appleTV, my phones, my ipad - doesn't matter which device - the first request almost always hangs:
$ fcurl https://google.ca * Rebuilt URL to: https://google.ca/ * Trying 188.8.131.52... * TCP_NODELAY set * Connected to google.ca (184.108.40.206) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /usr/local/etc/openssl/cert.pem CApath: /usr/local/etc/openssl/certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): } [5 bytes data] * TLSv1.2 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.ca:443 * stopped the pause stream! * Closing connection 0
this doesn't seem to affect unencrypted streams, and certainly wasn't happening prior to my move. I brought my CODA-4582 with me, and I'm genuinely at a loss to determine what the source of the problem could be here.
Hardware Version 1A Software Version 220.127.116.11T3 Downstream Overview Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB) 1 597000000 256QAM -2.400 8 37.636 2 849000000 256QAM -3.100 2 37.636 3 855000000 256QAM -3.400 3 37.636 4 861000000 256QAM -3.800 4 37.636 5 579000000 256QAM -2.600 5 37.356 6 585000000 256QAM -2.500 6 37.356 7 591000000 256QAM -2.400 7 37.636 8 303000000 256QAM -2.200 1 37.356 9 603000000 256QAM -2.200 9 37.356 10 609000000 256QAM -2.400 10 37.356 11 615000000 256QAM -2.300 11 37.356 12 621000000 256QAM -2.100 12 37.636 13 633000000 256QAM -1.800 13 37.636 14 639000000 256QAM -2.000 14 37.636 15 645000000 256QAM -2.100 15 37.636 16 651000000 256QAM -1.900 16 37.636 17 657000000 256QAM -2.200 17 37.636 18 663000000 256QAM -2.200 18 37.356 19 669000000 256QAM -2.300 19 37.636 20 675000000 256QAM -2.500 20 37.636 21 681000000 256QAM -2.700 21 37.356 22 687000000 256QAM -2.700 22 37.636 23 693000000 256QAM -2.600 23 37.636 24 699000000 256QAM -2.600 24 37.636 25 705000000 256QAM -2.900 25 37.356 26 711000000 256QAM -3.000 26 37.636 27 717000000 256QAM -3.000 27 37.356 28 723000000 256QAM -3.700 28 37.356 29 825000000 256QAM -3.100 29 37.636 30 831000000 256QAM -3.200 30 37.636 31 837000000 256QAM -3.200 31 37.636 32 843000000 256QAM -3.200 32 37.636 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 -2.000000 Upstream Overview Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Bandwidth 1 13696000 ATDMA - 64QAM 30.500 1 6400000 2 30596000 ATDMA - 64QAM 32.250 3 6400000 3 23700000 ATDMA - 64QAM 32.500 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
Any thoughts? It's driving us nuts!!
@Mythen, it depends on your plan data rate, ie; whether you are running gigabit service or plan to go there, and whether or not you’re looking for an all in one router or possibly splitting the duties into a wired router with wifi access points. My primary recommendation if you are running gigabit service or plan to go there is to buy the fastest processor within your budget. There are all in one routers out now that have either a 1.4 or 1.8 Ghz processor, which will run gig rates with features enabled on the router. I’ll pick on Asus routers as I’m most familiar with them.
The RT-AC1900P has a 1.4 Ghz processor. The new RT-AC86U has a 1.8 Ghz processor. I have the older RT-AC86U which only runs an 800 Mhz processor and now run the AC86U. With nothing enabled but the router’s AI Protection and wifi, the 68U, running IPV4 will top out at about 900 to 910 Mb/s. The 86U will easily top out at 950 to 960 Mb/s running IPV4. Both will reach 57/58 Mb/s upstream, probably much higher if the upload rates were higher on the gig plan. At Best buy, the RT-AC1900P is $199.99, the RT-AC86U is $269.99. If you keep your eyes open for sales, the RT-AC86U will drop down to about $229.00. If you plan to keep the router for a while the extra $30 is worth it, partly for the processor horsepower and the ability to run MU-MIMO on newer devices. My personal opinion is that MU-MIMO is not important at the moment to the vast majority of wifi users, but, over the next few years, MU-MIMO devices will (maybe), become common as users replace their devices. Assuming that my crystal ball gazing is correct, the router will be ready to go when MU-MIMO shows up on your doorstep.
So, whatever you look at for an all in one router, keep the processor rate in mind. To run gig rates with various functions enabled on the router takes horsepower, which doesn’t come cheap. If you look at some of the monster routers on the market, they will range in the $400 to $500 range. They split the 5 Ghz band into two bands, 5Ghz low and 5 Ghz high, with their own antenna. Depending on the number of wifi devices you have and whether or not you have MU-MIMO devices on hand, that might be worth considering. I couldn’t justify that cost given our low wifi device count so, the 86U is more than sufficient for now. I’m more interested in security functions that a PfSense type of router can provide.
If your on a lower data rate plan, you could consider something like the mini-PfSense router, which is fairly new.
The SG-1000 is $149.00 US and apparently can handle data rates up to 300 Mb/s. To get to gig rates you would have to step up to the SG-4860, which is $750.00 US without extras. So, once again, gig rates with router functions = expensive. The alternative to this is to turn an older pc into a router by installing the router operating system and a gig NIC card for a second port, or more. If you’re considering replacing a pc, this might make some sense. There is a learning curve to PfSense, OpenSense, Sophos UTM, but, if you’re technically adept and interested in going this route, then it might be worth considering as it provides much better control over just about everything, compared to an all in one router.
On top of that, you would need a wifi access point, which could be a cheaper router, given that the wired router is doing the majority of the work, or you could look at something like a Ubiquiti wifi access point. I’m not the person to ask about these, but, from what I’ve read, Ubiquiti users are usually pretty happy with the access point performance:
Additional food for thought: Asus is releasing new firmware versions for its more recent routers. This might be part of the fallout from a US FTC court case against Asus where Asus ended up with independent audits for the next 20 years. I think all companies in this space are guilty to some degree of poor security and customer support, looks like Asus might have become the example of what not to do if a company wants to remain clear of similar complaints and resulting actions.
So, at the present time, there are minor development bugs that are coming up with new version, but, it shouldn’t be too long before these are put to bed once and for all. Just a matter of the users complaining loudly enough. The alternative to the Asuswrt firmware is Asuswrt-Merlin which is widely regarded with its additional features above the original Asuswrt. So, this gives the users an alternate firmware source. I’ll probably load Merlin’s Asuswrt after the next two or three versions are shaken out. I think there will be some give from Asus in terms of the restrictions that Merlin is running into as he converts the previous firmware additions to this recent firmware version. As a note, OpenVPN users with the RT-AC86U are pretty pleased with their VPN data rates due to the AES-related acceleration at the CPU level.
Netgear Routers: If you’re looking at Netgear routers, have a look at the current state of affairs with filtering of IPV6 ICMP on their routers. IPV6 ICMP is required to run IPV6. This has been brought up in their forums in the past, without success, but, I haven’t been keeping track of this, so, I’m not sure if this is the case. There is also an alternative firmware version such as Asuswrt-Merlin (or XWRT or Cross-WRT) firmware for the Netgear R7000. This is very similar to the Asuswrt-Merlin but doesn’t have the Trendnet AI Protection included, most likely due to licensing costs and issues. I don’t know if XWRT is available for other Netgear routers. There is also DD-WRT which can be loaded on a good number of routers, including Netgear routers. Just a matter of determining what available before deciding to buy a Netgear router.
Ok, so, there is some food for thought. As I indicated above, processor horsepower is pretty important if you’re running gig rates and want to run some type of router function or multiple functions. I think that’s probably the most important item to consider, next to the router cost and the budget.
Hope this helps.
@ksnider this is most likely a case for @RogersDave to have a look at as he has the background as a Network Architect to understand this, or, to point the problem to the appropriate staff member. He'll see the link to your question, but, it won't be anytime soon. Not trying to pass the buck, but, looking at the info, it seems that you need an answer from someone within Rogers Network Staff. I'm also wondering if you haven't found some strange bug within the modem, although as you indicated, you didn't see this prior to the move. Do you have IPV6 up and running in the modem, or are you running IPV4 only? I'm wondering why the addresses are IPV4 only.
So, that's actually what I was tinkering with tonight - I had set ipv6 to link-local,. and I'm wondering if what the issue I've been seeing was somehow related to not being provisioned an ipv6 address at my old physical address, but I am now, and having the Airport Extreme configured to link-local might have been breaking things.
I just successfully configured ipv6, and now have a new and more interesting datapoint: The problem doesn't exist for ipv6 addresses! It's happening only with ipv4 connections.
For example, using curl with the -4 flag to https://google.ca will hang, while with the -6 flag, it will succeed every time.
It's a very, very strange problem, but it is happening so consistently, and seemingly only at connection startup, that I have to believe this is a specific bug I've managed to trigger somehow.
I'd love to have @RogersDave or anyone else have a look, and happy to provide details at whatever level needed - I can even do a packet capture if that helps. You can imagine how annoying it is when 75%+ of your https connections have to be retried - loading webpages, reloading netflix on the appletv, app updates time out the first run, etc.!
Its interesting that you're seeing that as a similar occurrence is underway in the US, as reported in the DSLReports forum. In this case its with a Broadcom modem and different CMTS. The Hitron 4582 is an Intel Puma 7 modem.
Ok, one thing you could do is call tech support and ask for a Level II tech. The Level I tech might give you some static, but, he or she won't be able to help you. I'd ping this off of the Level II tech and see what he or she can do. If nothing else, perhaps the tech can pass this on to the Network Engineering staff and get the ball rolling. My guess is a possible CMTS configuration error of some type. The modem connects to the Cable Modem Termination System (CMTS) enroute to anywhere and everywhere, so, maybe the issue is with the CMTS??
I think that if you had the wrong MAC address on the account, as indicated in the US case, that your modem wouldn't work, but, one can't assume. You could always confirm the modem's MAC address against the account data with the Level I tech.
Let me know how this turns out if you decide to chat with the Level II tech. You can send @RogersDave a private message with the details, but, don't expect an answer anytime soon. Follow that link to navigate to his pubic page. On the right hand side is a link to "send this user a private message". Follow that link to navigate to the message composition page. It will already be addressed. Fill in the title and text details and hit send. For a response, you will see a number overlaying your avatar at the upper right hand corner of the page when you're logged into the forum. Follow the avatar, which is a link, down to your profile and message inbox.
Using that same method, you can send anyone a message just by following the link for their name.
I am currently subscribed to the 500/20 plan. My current plan expires in March. so depending on price I might try to get to the gig plan.
Also $350 bucks for a top of the line wireless router. idk. Our gaming pc's are both directly connected and not wireless. We have two cell phones two tablets, a Roku, and a chrome cast. So not a dire need for extreme WiFi but don't want it slow either
@Mythen, if your looking at going to gigabit service, and running VPNs, especially OpenVPN, I'd definitely suggest the RT-AC86U. If your not in a hurry, keep your eyes open for a sale to come up. If you run a different VPN, I'd suggest posting a question in the SNB forum regarding the performance you might see with that VPN and the RT-AC86U. See what Merlin might have to say:
Hitron CGN3 Modem intemitten low download speed issue
I have got the Hitron CGN3 modem with the 500MB download package. I was able to get close to 400MB down stream at the beginning. However after a day use, the download speed will be below 1MB. While the upstream stays at 15 to 20 MB all the time. It remains until I reboot the modem. The download speed will recover to over 300MB immediately.
Then I disabled the gateway function and used it as a cable modem passthrough. The problem still happens. Of course the reboot of the modem will recover the download speed. I did further test and found that I can just unplug the cable of the input to the modem and plug it in again, the download speed will recover too without the need to reboot the modem. It normally happens after a night or a quiet day when there is no one in the house using the internet.
Any suggestion what I should do next? Since I have reset the modem into the passthrough mode, I was not able to log into the modem any more to check the cable side stats.
Thanks in advance for help and advises!
@unidisk, this sounds like a cable issue. I'm assuming here that you're running an ethernet connection to the modem. If this is via wifi, then it could be a combination of cable and wifi issues. A modem reboot will temporarily resolve the the problem, but, it doesn't solve the underlying cable issue. When your ethernet connected data rates are down to a minimum, call tech support and ask the CSR to run a signal check on your modem. My guess is that the signal check won't pass and you should see a tech at your home fairly soon.
You could also log into your modem, navigate to the DOCSIS WAN tab, copy the Downstream and Upstream table (top to bottom) and paste that data directly into a post. Do that when your ethernet rates are at a minimum. The copy and paste process will paste in the text contents of the table and it should look like the table itself when it's pasted in. Ignore the data that resides above the Downstream table as it's modem specific. After I see that I might just indicate to you to call tech support anyways, but, at that point I'll have an idea of what your signal levels are like and whether or not they might be the cause of your data rate issues.
Can you confirm for me if those rates are seen via ethernet, wifi, or both?
Just to note, there are two operating modes with the Rogers Hitron modems, Gateway mode, where the modem acts as modem and wifi router, and Bridge mode, where the modem acts as a modem only. You can log into the modem in Gateway mode using 192.168.0.1 For Gateway mode (secondary address) or Bridge mode, you can use 192.168.100.1 to log into the modem. With the modem in Bridge mode, you can log into it using 192.168.100.1, navigate to the BASIC .... GATEWAY FUNCTION tab and enable the Residential Gateway Function. Save the change and the modem will reboot back into Gateway mode with its previous settings intact.
There is no passthrough mode as is seen in the Shaw Hitron CGNM-2250 modem.
The test was done via wired connection. No wifi connection involved.
The modem (CODA-4582U) is set with Gateway mode disabled . it is used as cable modem only and an external router is used.
The reboot of external modem or disconnecting the Ethernet connection does not solve the problem.
The only way to solve the problem is to disconnect the coax cable from the cable modem and reconnect again. It seems to force the cable side to resync. Of course the rebooting the modem alone will also solve the problem.
I just logged into the modem (in bridge mode) and here is the current downstream stats. The wired speed test result is about 600MB down/20 MB up. I will do another capture when the problem happens next time.
Version:1.0 StartHTML:000000194 EndHTML:000010383 StartFragment:000002679 EndFragment:000010327 StartSelection:000002799 EndSelection:000010289 SourceURL:http://192.168.100.1/index.htmlCODA-4582U Router - Hitron Technologies
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
|Receiver||FFT type||Subcarr 0 Frequency(MHz)||PLC locked||NCP locked||MDC1 locked||PLC power(dBmv)|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Bandwidth|
|1||30596000||ATDMA - 64QAM||33.000||1||6400000|
|2||38595766||ATDMA - 64QAM||36.000||3||3200000|
|3||23700000||ATDMA - 64QAM||32.500||2||6400000|
|Channel Index||State||lin Digital Att||Digital Att||BW (sc's*fft)||Report Power||Report Power1_6||FFT Size|
Here is the log and there are critical warnings. Do not know if it matters. However the connection is OK for the day since I toggle the coax cable in the morning. Strange enough there is no log about the cable reconnecting.
Log table removed for privacy reasons. Please edit out modem MAC (CM-MAC) address and post again. - RogersMoin
Thanks @RogersMoin. I would have requested the same 🙂
@unidisk, ok, so, very interesting. What model of router do you have? Depending on the router model in question one question is whether or not it can handle max data rates of 950 Mb/s down. Depending on when you signed up for gig service, you will see either 30 Mb/s up, or 50 Mb/s up. Rogers has recently reduced the upload rates for new customers. If you are a new customer and you haven't done this already, I would advise you to run a factory reset on the router and then set the various parameters from scratch. Don’t use a backup settings file for reload purposes. We often see customers arrive from other ISPs who experience issues with their router not delivering the expected data rates. Usually a factory reset for the router solves the issue as it clears out any data that was specific to the previous modem. In this case, it might only be part of the problem.
Most of the DOCSIS 3.0 signal levels are high, except for a couple of them and some of the signal to noise ratios are slightly low. The Signal to Noise ratio isn’t exactly a signal to noise ratio in the conventional sense. It’s actually an error measurement of where the receive signal is, in terms of time and signal level, versus where it should theoretically be. So, for some reason, the received signal timing isn’t what it should be.
The modem isn’t using DOCSIS 3.1, although it should be. That is seen in the OFDM (DOCSIS 3.1) section. By now DOCSIS 3.1 should be turned on for all Rogers CMTS equipment. The fact that your modem isn’t running DOCSIS 3.1 could point to a noise issue with the OFDM channel that DOCSIS 3.1 should be using on your Cable Modem Termination System (CMTS). All Rogers modems and cable boxes in your immediate neighborhood use one CMTS, so, there is either a problem with your CMTS, or, there is a noise issue on the go. That will take a call to tech support to report and enquire about.
The Upstream signal levels aren’t too bad. Typically with this modem we’re seeing somewhere around 30 to 32 dBmV, so, your signal levels are a little higher. That might be another indication of noise in the cable system, where the modem output has to be slightly higher in order for the CMTS to receive and decode the incoming data.
Ok, so, call tech support. Advise the CSR that your DOCSIS 3.0 downstream signal levels are high, for the most part but still in spec, and that a good number of the DOCSIS 3.0 signal levels are below 36 dBmV. Since the modem is using DOCSIS 3.0 at this time, those numbers are important when you’re talking about the modem performance. Also let the CSR know that the modem isn’t using DOCSIS 3.1. Ask if that is an issue with the CMTS, as in, is DOCSIS 3.1 not enabled on your CMTS, or, if its possibly due to a noise issue with your cabling. Ask the CSR to run a signal check on the modem and to check the noise levels on your modem and that of your immediate neighbors. The question is, is this an issue with just your modem, or is it a problem for your immediate neighbors as well, as you will all be connected to a local tap. That local tap, depending on whether you have overhead or underground cabling will be located on a nearby utility pole, or in a ground level green pedestal, located close to your home. It will provide service to 4 to 6 customers (your immediate neighbors) I believe.
That should give you enough info to have an informed conversation with tech support. That conversation will hopefully start the ball rolling enroute to better modem performance. You should see ~950 Mb/s max down, ~33 or 58 Mb/s up, depending on when you signed up for gig service.
Hope this helps.
Edit: in the OFDM section of the data, you should see one channel up and running. Running DOCSIS 3.1, the modem can provide the max 950/960 Mb/s on a speedtest. The www.speedtest.net Toronto Rogers or Montreal Rogers servers should be used for speedtests for this modem. The Toronto Beanfield and Montreal Fibrenoire servers are good seconday choices for speedtests.
@DatalinkThanks a lot for the detail explanation.
The test was done by connecting a laptop to the port 2 of the cable modem. The router is connected to the port 1. It appears that both router and the laptop get separate IP address (99.228.x.x). This is a bit surprise to me.
I signed up for 500MB down/20MB up. So getting 600MB down is over the higher end. The rate control may not be strictly enforced on Rogers end. Behind the router I can get the similar result. I am using MikroTik 750G router. The APs are 4x4 11ac from our own company. Thus pretty I can get close to over 400MB download over with a 2x2 11ac laptop. Check all the details with the AP and the router and I do not see any issue related to Wifi, L2 or L3 IP layers. However I always do the final test using a laptop with the wired connection.
I probably will wait until the problem happens again. At the time the down stream is below 1MB while the upstream can stay around 15-20MB. Then I will do another capture of the signal stats. Then I will call the CSR and ask them to run the test. Definitively I will ask them about DOCSIS 3.1 not being enabled.
@unidisk the modems will support two devices when the modem is running in Bridge mode, as in it will supply independent IPV4 and IPV6 addresses to two separate devices. The modems are actually supposed to supply an unlimited number of IPV6 addresses, but, I've never gone beyond two devices to see if this will work as expected. Each device will end up with its share of the plan internet data rate. Ie: the internet plan data rate is spit between all of the devices plugged into the modem, either in Gateway or Bridge mode. One point to keep in mind, which I remind customers about, connecting directly to the modem when the modem is in Bridge mode exposes the connected device directly to the internet and all of the scanners looking for open ports and access points. So, the device has to be able to protect itself from that. I only advise that configuration for very brief periods of time for test purposes, after which its time to retreat behind a firewall. No doubt there are individuals who run that configuration full time, but, for the average every day user, I don't recommend it, simply due to potential security issues.
When you run into a slow data rate period of time, if you have the time, log into the modem and see if one of the OFDM channels has gone active. If there are noise issues going on its possible that the modem is trying to run DOCSIS 3.1 and failing rather badly. Also check to see if the upper DOCSIS 3.0 signal levels or signal to noise ratios have taken a dramatic drop. At the same time look for a dramatic increase in the upstream signal levels and the possibility that your modem has dropped down to one upstream channel in an attempt to maintain comms with the CMTS. All of that points to a cable problem or some type of severe cable noise issue. If this is an intermittent noise issue it will be a major pain to track down the noise source and isolate it from the cable network.
When the internet service is at its worst, that's the best time to call tech support so that the CSR can start to track this down. Don't reset the modem. Leave it as is so that the CSR can see where the signal levels and signal to noise ratios are at.
I called tech support and requested to speak with a level 2 technician but the person said there isn't really a tech 2 technician anymore. She just told told me to exchange the modem again so I did and I'm still experiencing packet loss and unstable pings. Im getting 30-40% PL to my CMTS, it's pretty bad.
I messaged @RogersDave 3 weeks ago but he hasn't gotten back to me yet.
Apologies for jumping in on this conversation but I have encountered an issue that I hope you are aware of and have a solution for.
I have a CODA-4582U modem / router. I have setup a VPN server on my laptop (with all traffic from the client going through the VPN) so that I can access files, etc. from my home.
When connecting to the VPN server the throughput is so slow from my iPhone / remote computer that I cannot even load CNN.COM which essentially makes the VPN connection useless. And yes, I do have the VPN Passthrough enabled and I do have the port-forwarding properly configured (i.e. the connection gets established but the throughput is non-existent).
Worth also noting is that I know the problem is VPN related because all other connections (i.e TeamViewer, ScreenSharing / VNC) work consistently and quickly. The other point is that this problem started when I moved from Bell to Rogers.
Would greatly appreciate a solution / workaround as this performance issue is exceptionally disappointing!