AC3100 gigabit speeds

[NyCShadow]

The only other thing I can suggest is try disabling anything and everything you don't need in the router for a internet connection. Also look at the logs. If that doesn't do anything that the next step is contacting Asus for a RMA.

Yeah I disabled everything I saw, I'm going to return it to best buy and swap it with another one, if that one does the same thing (I'm not going to mess with the firmware, I'm going to use the stock firmware it comes with) and not put any custom settings. If it still does it then I know its the router itself and will purchase a different brand/model

 

[Trikein]

I can't see it being a issue with the router. There isn't any kind of design flaw that would be causing that kind of problem. Either it's a bad unit, or not configured correctly.

 

[NyCShadow]

Ok so I finally was able to replicate what is causing it. Tests below

I restarted the modem without restarting the router and the speed tests were horrible. - BAD

I restarted the modem and then restarted the router and speeds were close to the gigabit speeds I am supposed to get. - GOOD

I restarted just the router and not the modem and speeds were close to the gigabit speeds I am supposed to get. - GOOD

I restarted the router and then waited for it to come back up then restarted the modem and speeds were back down to less than 200mb - BAD

So basically if I don't restart the router after the modem comes back online it's not going to hit the gigabit speeds. Any ideas as to why the router would have to be restarted if the modem rebooted or lost connection sometime throughout the night?

 

[Trikein]

I wonder if IPv6 is failing and that is causing some problem. Is IPv6 enabled on the Asus router? Also, have you tried disabling wireless and unplugging everything from the router except the ethernet going to the modem and the testing PC? I wonder if something on the network is using up bandwidth and rebooting the router is temporarily stopping that connection. Do you have a NAS or wireless camera system or backup device which might be kicking in?

In general, can you post the general logs and Netstat-NAT log from around the time of the testing above? Also a picture of the bandwidth monitor if you have that enabled.

 

[NyCShadow]

I wonder if IPv6 is failing and that is causing some problem. Is IPv6 enabled on the Asus router? Also, have you tried disabling wireless and unplugging everything from the router except the ethernet going to the modem and the testing PC? I wonder if something on the network is using up bandwidth and rebooting the router is temporarily stopping that connection. Do you have a NAS or wireless camera system or backup device which might be kicking in?

In general, can you post the general logs and Netstat-NAT log from around the time of the testing above? Also a picture of the bandwidth monitor if you have that enabled.

I tried with IPv6 off and on and this time just rebooting the modem and not the router resulted in good tests (kind of at a lost now lol). I do have a security camera system hooked up by wired ethernet cable hooked up to the ASUS router but I tested that with it not hooked up and with it hooked up just now and same results (good speed testes). I replaced the LAN IP with xx's for the Netstat-NET log.

 

[Trikein]

First thing I notice is your using a 10.x.x.x IP sceme. I wonder if that could be causing any conflict with Comcast internal IP sceme for their headend. IE the IP's you see when you do a tracert at hop 2 and 3. Second, it looks like you are using 75.75.75.75 for DNS. Is this static or set by DHCP? I think what might be happening is you're using static DNS (Comcast opt-out?) and your router is thinking your sending it to a 10.10.x.x IP on Comcast network and not the 10.10.x.x IP of your router gateway. Try changing to a normal 192.x.x.x range

Something else that might be happening has to do with the VLAN tag the modem uses to track which ethernet port on the SB8200 is active. First, I assume you only have 1 ethernet connected to the SB8200 and that goes to the Asus WAN port. Which port (1 or 2?) do you use on the back of the SB8200? See if using the other port makes any difference. In doing this, you will have to reboot the modem, wait for it to come online normally, and then reboot the router, for the DHCP lease to re-negotiate, but after that, see if it still fails like the other way. I know the Zoom/Motorola D3.1 had issues where it prefered ethernet port 2 under some conditions. Also, I assume you're not using port bonding with 2 ethernet.

Last, what do the logs in the SB8200 say? Can you post those? Make sure to delete/edit the HFC MAC address.

 

[NyCShadow]

First thing I notice is your using a 10.x.x.x IP sceme. I wonder if that could be causing any conflict with Comcast internal IP sceme for their headend. IE the IP's you see when you do a tracert at hop 2 and 3. Second, it looks like you are using 75.75.75.75 for DNS. Is this static or set by DHCP? I think what might be happening is you're using static DNS (Comcast opt-out?) and your router is thinking your sending it to a 10.10.x.x IP on Comcast network and not the 10.10.x.x IP of your router gateway. Try changing to a normal 192.x.x.x range

Something else that might be happening has to do with the VLAN tag the modem uses to track which ethernet port on the SB8200 is active. First, I assume you only have 1 ethernet connected to the SB8200 and that goes to the Asus WAN port. Which port (1 or 2?) do you use on the back of the SB8200? See if using the other port makes any difference. In doing this, you will have to reboot the modem, wait for it to come online normally, and then reboot the router, for the DHCP lease to re-negotiate, but after that, see if it still fails like the other way. I know the Zoom/Motorola D3.1 had issues where it prefered ethernet port 2 under some conditions. Also, I assume you're not using port bonding with 2 ethernet.

Last, what do the logs in the SB8200 say? Can you post those? Make sure to delete/edit the HFC MAC address.

The DNS is set automatically. I only have 1 ethernet cable and that is on port 1 but I can try port 2 and test that out.

I don't understand the 1970 date stamp on the log below.

 

[Trikein]

Any different if you use a static DNS like google 8.8.8.8 and 8.8.4.4? Looks like 75.75.75.75 is the default Comcast DNS, I just wonder if a problem could be with the DNS relay.

As for the logs, I see a lot of T3 errors. I don't see how that would only be causing a problem through the router, but they are not optimal either way. Can you post the modem's signal levels for review? T3 errors usually suggest a problem with the Upstream(US/TX) signal to noise (SNR) clarity. Either the Upstream power level is too high or there is ingress (ie cellular interference) on the frequencies used for the upstream. It may be possible to use the modem's RF spectrum analyzer on port 8080 to get a general idea of noise on your line, but the only one who can get true readings of your US SNR is Comcast. Comcast SNMP tools for modems should show what the CMTS is reading for the modem's US channel. If you find your upstream is high, try to bypass any splitters between where the coaxial comes into the house and the outlet used for the modem. Also make sure you aren't using any kind of coaxial signal amps, especially ones with active returns.

Something else I see odd in the logs are a lot of

<10-28-2017, 3:22:44 Critical(3) "Resetting the cable modem due to docsDevResetNow">

Which is Comcast sending a signal to reset your modem. It looks like they did it several times today starting at 3:22AM and around 7am-10am. Were you talking to Comcast at those times? If not, something odd is going on.

 

[NyCShadow]

The reset from 7am-10am was me sending it from the phone app, the one at 3:22am I did not do so that is probably when it had restarted and then when I woke up I tested it the speeds were slow (cause I hadnt rebooted the router yet since I was not aware to do so yet)

 

[Trikein]

That 3:22AM one is weird. You wouldn't get that from power cycling the router, or even factory resetting from the UI. That means someone at Comcast sent that signal at 3:22AM. It's possible it was some transaction that was stuck in their broker from the day before and was sent during the nightly maitance period, but it's still weird.

Either way I think you have a signal problem going to the modem. Might not be causing your current problem, but it's not optimal nonetheless.

 

[NyCShadow]

Just got back on the computer and speeds again are at a crawl, I checked Eventlog on the SB8200 and this is the only newline I see, what does this mean? The modem didnt restart or anything nor did the router (til I just restarted it a min ago because of the slow speeds)

10-30-2017, 20:25:0 Critical(3) "Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=xxxxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.1;"

 

[Trikein]

Any change to the signal levels? Specifically the upstream power levels. Do live near a National Guard base by any chance? Any cellular microcell in your house or near by? Can you explain how the coaxial gets from outside at the pole/street to the modem?

 

[NyCShadow]

Any change to the signal levels? Specifically the upstream power levels. Do live near a National Guard base by any chance? Any cellular microcell in your house or near by? Can you explain how the coaxial gets from outside at the pole/street to the modem?

Signal levels were the same, dont live near national guard, I live in HOUSTON, TX. The coaxial cable goes to the tap in my neighbors backyard which when the tech came out few weeks ago said needed to be serviced cause there was noise on the tap.

 

[Almighty1]

I have the Blast Pro 200/10 since March 14, 2017 and now Blast Pro 250/10 profile from XFinity/Comcast since January 2, 2017 when they provided the upgrades. I originally had Blast 150/10 when service was initially installed on March 15, 2016 and basically I also am using a Arris SurfBoard SB8200 DOCSIS 3.1 modem and using a NETGEAR R7000 router running XWRT v380.69_0 which is ASUS RMerlin ported. I am running on 31 Docsis 3.0 + 1 Docsis 3.1 downstream channels and 4 upstream channels. As there is a known firmware issue with the Arris E6000 CMTS, the 20% overprovisioning is ignored on DOCSIS 3.1 modems so I was getting only 200/12 instead of 240/12.

On December 20, 2017 - Comcast performed maintenance and moved me to a different CMTS which was having node/plant issues as my upstream signal levels on all 4 channels went from the 35-37dB to 28dB for the first week which was making my upload test speeds and file uploading go from 12Mbps to 200Kbps. After the first week, all 4 of the upstream channels went from the 28dB back to 35-38dB and the upload speeds were once again at 12Mbps while the downloads vary from 50Mbps-199Mbps. On January 2, 2017 when the Blast Pro upgrade went in, the downloads were 244Mbps while the upload remained at 12Mbps which was fine until Comcast sent out the e-mail on January 5, 2017 that mentioned the free Blast Pro upgrade to 250/10 and basically at that point, I was seeing anywhere from 50Mbps-140Mbps down and 13-14Mbps up using speedtest.xfinity.com in the browser and the Windows 10 speedtest.net app to the XFinity server on the Windows 10 PC while also the speedtest app on both the Samsung Note 8 mobile phone and the Apple iPhone 6S Plus unlocked sim free mobile phone. I was told by netcool, a reputable and awesome Comcast Engineer on DSLReports that the Arris E6000 CMTS I was on is running newer code for the firmware so I should be seeing the 20% overprovisioning with the DOCSIS 3.1 modem so the speeds should be closer to 300Mbps down/12Mbps up like other people with DOCSIS 3.0 modems were posting on DSLReports. It appears if I connect with CAT7 using Gigabit Ethernet to either the modem directly or to the NETGEAR R7000 router, I would get 295Mbps/12Mbps. However, the WiFi would be 50Mbps-140Mbps down and 13-14Mbps up with both the notebook PC using the Intel 7260AC Mini-PCIe WiFi card and the Samsung Note 8 mobile phone and also the Apple iPhone 6S Plus unlocked sim free mobile phone which would rule out it being a problem with the WiFi card on the computer. netcool wanted to see if the stock NETGEAR R7000 firmware would make a difference but it seemed easier if I just picked up a NETGEAR X6 R8000 router to test which is what I did since I have 3 months to return the R8000 for a full refund even though I will probably only use it for a few weeks at the most as I already have both a ASUS RT-AC68R and ASUS RT-AC5300 new in the box shrinkwrapped that I had bought but didn't have the time to setup. I also ran iperf/iperf3 between the notebook PC and the mobile devices to test for WiFi speeds on the WLAN and the speeds are the same as what I would get with speedtests on the internet except in this case, it was 50Mbps so something else was wrong obviously. I did a factory reset on the NETGEAR R7000 and while still using XWRT ASUS RMerlin software, it was doing 295Mbps down/12Mbps up on wired and 296Mbps down/14Mbps up on wireless and then after a few reboots, it would do 50Mbps/14Mbps up. The only thing was I did not know when the 296bps down/12Mbps up was done, if it was just with CTF only enabled which was the default or was it after I made it both CTF + FA enabled.

So anyways, I went to get the NETGEAR X6 R8000 last week and the first thing I did was update the stock firmware to the latest version being v1.0.4.4_1.1.42 in this case and basically configured the R8000 except I left ipv6 disabled as I did not know what Internet Connection Type should be set to since there is no IPv6 Prefix Delegation which is what Comcast uses. It appears that the R8000 has problems with the DHCP with Comcast as it seems to require rebooting in a certain order in order for the modem to obtain a IP since basically it appears that if the router cannot get the WAN connection up via DHCP, I will need to reboot the modem first and if it still cannot see it, I will need to reboot the router which was the same issue I saw with the NETGEAR R7000 as well ever since December 20, 2017 but did not have such issues prior to December 20, 2017 on the previous Arris E6000 CMTS. Anyways, wired tests were doing 296/12 while wireless it was doing 50-140Mbps/14Mbps. Others told me to use "Auto Detect" for the ipv6 connection type which is what I did except "Auto Detect" after it is applied ends up randomly choosing "DHCP ipv6" as the connection type or it would choose "6to4 tunnel" connection type. DHCP ipv6 is not the same as DHCP ipv6-pd (Prefix Delegation) that Comcast uses. NETGEAR's firmware can do DHCP ipv6-pd on the WAN side but not on the LAN side. Anyways, as soon as the ipv6 was working, the connection speeds went to 295Mbps/12Mbps which did not last long as after some hours of uptime, the speeds went to 199Mbps down/200Kbps up and it appears that the ipv6 is like playing random selection as picking "Auto Detect" and applying does not always get IPv6 working since the IPv6 addresses for the LAN and WAN is blank. I was testing under the stock SSID's so that only my notebook is connected and the Obi202 VoIP adapter via CAT7 cable.

So in a effort to test this further, I put in koolshare v380.68_4-X7.720180116 which is ASUS RMerlin ported except as one can see, XWRT for the NETGEAR R7000 is a more recent ASUS RMerlin version. So basically I tested every single setting on the router and took screenshots of the defaults settings before configuring and tested after each reboot to make sure the wireless speedtest was still 295Mbps/12Mbps even though I was using the stock SSID's so only my laptop would be connected other than the Obi202 VoIP adapter which is connected by CAT7 cable. After all the settings are correct and it was doing 295bps/12Mbps still in speedtests, I changed the SSID's to what I was using on the NETGEAR R7000 and basically got the 50Mbps down/14Mbps up. While doing all this testing, I was doing a search to see how to disable FA while keeping CTF Enabled as on the R8000 firmware unlike the R7000, next to LAN - Switch Control and NAT Acceleration, it seems like it only lists CTF (Cut Through Forwarding) is enabled but does not mention FA at all. The reason is probably the R7000 has the CTF and FA as part of software which is why DD-WRT does not support hardware acceleration on the R7000 but hardware acceleration is already enabled on the R8000 and R8500 in DD-WRT as it is part of hardware.

This explains better what CTF and FA actually is:
https://routerguide.net/nat-acceleration-on-or-off/

The https://www.snbforums.com/threads/turn-off-fa-and-not-ctf.36890/ thread was the first one I saw which seems to have some of the posts missing as post #2 is quoting someone except that post being quoted does not exist just like post #3 says Thanks but whatever post(s) there were between posts #2 and #3 no longer exist. So I was searching for "ctf_fa_cap" on google and came across this thread as I was trying to figure out how to turn the FA back on since it appears that 0 is to turn FA off and in that thread, it appears that one can put 0, 1 or 2 which probably just a guess means:
0 = CTF Enabled, FA disabled
1 = CTF Enabled, FA Capable since I noticed that Capable is a option on the menus in the web interface for different things
2 = CTF Enabled, FA Enabled

It appears that post #4 also talked about looking up the command as there are probably missing posts before post #4 as well since I am still trying to find out where information was found about the command.

Ofcourse, before I did the:
nvram set ctf_fa_cap=0
nvram commit
reboot

I was curious what the default was:
admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_cap
admin@R8000-CC16898:/tmp/home/root#

This means that there is no setting for this variable.

So I did:
nvram set ctf_fa_cap=0
nvram commit
reboot

and the setting is saved after rebooting, since:
admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_cap
0
admin@R8000-CC16898:/tmp/home/root#

I am getting 298Mbps down/14Mbps up.

To test out what setting 1 and 2 did, the following was done:
nvram set ctf_fa_cap=1
nvram commit
reboot

and the setting is saved after rebooting, since:
admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_cap
1
admin@R8000-CC16898:/tmp/home/root#

I am getting 298Mbps down/14Mbps up.

Then:
nvram set ctf_fa_cap=2
nvram commit
reboot
and the setting is saved after rebooting, since:
admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_cap
2
admin@R8000-CC16898:/tmp/home/root#

I am getting 298Mbps down/14Mbps up.

Continued in next message as post is limited to 10,000 characters.

 

[Almighty1]

The correct way to reverse what was done is not to set it to anything since as you can see, the original variable was not set to anything so the correct way to do it is:
nvram unset ctf_fa_cap
nvram commit
reboot

admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_cap
admin@R8000-CC16898:/tmp/home/root#

I am getting 298Mbps down/14Mbps up.

In any case, what I set sticks as nvram commit means to write to nvram and if it doesn't, then something else is wrong with your router.


I have not gotten the chance to test the above with the NETGEAR R7000 running XWRT yet but will edit this post or add a reply once I get it done.

I would like to mention that it seems that on the XWRT thread in post #3161,
http://www.linksysinfo.org/index.php?threads/asuswrt-merlin-on-netgear-r7000.71108/page-32

someone used the ctf_fa_cap=0 setting and also used ctf_fa_mode=1 in addtion, would be great to know what each of the two does as that one also does not have a default setting:

admin@R8000-CC16898:/tmp/home/root# nvram get ctf_fa_mode
admin@R8000-CC16898:/tmp/home/root#

 

[Almighty1]

Had a chance to test out both my original R7000-NAS (Made in Vietnam) and also a new R7000-NAS (Made in Vietnam) purchased yesterday.

And here are my results with the new R7000-NAS put in test today which is similar to the original one. This one seems to reboot faster than my original one but kept turning off my WiFi card whenever Advanced Tomato did not fully boot since the WiFi lights were solid and didn't blink at all and the WiFi turning off happens either during the WiFi
connection stage when it tries to get the settings and when Advanced Tomato reboots. I couldn't get the wired LAN working in Advanced Tomato on this
one because it woudn't release and renew the IP and manual configuration to 192.168.1.2 didn't work either as ipconfig will still show it on Auto config with
the 169.x.x.x address so only hibernating the notebook and resuming out of it will turn the WiFi back on.

NETGEAR Stock Firmware v1.0.9.20_1.2.28
without ipv6 176.24Mbps/10.91Mbps
with ipv6 168.78Mbps/12.07Mbps

Advanced Tomato v3.5-140 AIO
CTF off 115.58Mbps/13.58Mbps
CTF on 118.63Mbps/8.98Mbps

DD-WRT 34015
SFE (Shortcut Forwarding Engine - not compatible with ipv6) off 190.36Mbps/9.07Mbps
SFE (Shortcut Forwarding Engine - not compatible with ipv6) on 160.08Mbps/11.43Mbps

XWRT 380.69_0
IPv6 off - 173.04Mbps/10.07Mbps
IPv6 on - 178.44Mbps/9.18Mbps

Switched Power Supplies to the new one and it enabled FA:
States CTF (Cut Through Forwarding) and FA (Flow Acceleration) accelerator are enabled under LAN - Switch Control on the right of NAT Acceleration

admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
ctf_fa_mode=2
ctf_disable=0
size: 52370 bytes (13166 left)
ctf_disable_force=0
ctf_fa_cap=1
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
nvram set ctf_fa_cap=0
nvram commit
reboot
Still States CTF (Cut Through Forwarding) and FA (Flow Acceleration) accelerator are enabled under LAN - Switch Control on the right of NAT Acceleration
Speedtest 163.67Mbps/11.49Mbps

admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
ctf_disable=0
size: 52298 bytes (13238 left)
ctf_disable_force=0
ctf_fa_cap=0
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
nvram set ctf_fa_mode=0
nvram commit
reboot
Shows CTF (Cut Through Forwarding) is enabled under LAN - Switch Control on the right of NAT Acceleration
Speedtest 161.47Mbps/10.82Mbps

admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
ctf_disable=0
size: 52365 bytes (13171 left)
ctf_disable_force=0
ctf_fa_cap=0
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
nvram set ctf_fa_mode=1
nvram commit
reboot

Shows CTF (Cut Through Forwarding) is enabled under LAN - Switch Control on the right of NAT Acceleration
Speedtest 260.48Mbps/8.44Mbps

admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
ctf_disable=0
size: 52365 bytes (13171 left)
ctf_disable_force=0
ctf_fa_cap=0
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
nvram set ctf_fa_mode=2
nvram commit
reboot

admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
size: 52365 bytes (13171 left)
ctf_disable=0
ctf_disable_force=0
ctf_fa_cap=0
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
nvram set ctf_fa_cap=1
nvram commit
reboot
Shows CTF (Cut Through Forwarding) and FA (Flow Acceleration) accelerator are enabled under LAN - Switch Control on the right of NAT Acceleration as this time, I basically
set it back to the original ctf_mode and original ctf_cap setting.
Speedtest 261.25Mbps/9.93Mbps

This is using 80Mhz bandwidth even though on the R8000, 20/40/80Mhz has the same results. And the channels used are 149 for Primary and auto for secondary which is the same for the R8000. Channels 36, 44, 48 are all used by others.

 

[Almighty1]

Today, I decided to do a speedtest since the new R7000 may require breaking in for maximum performance:
With CTF and FA on:
289.85Mbps down/10.72Mbps up
The ctf_fa_cap was set to 1 but no matter what I did, I cannot set the ctf_fa_mode as it will show up as ctf_fa_mode=2
when I did:
nvram set ctf_fa_mode=0
nvram commit
reboot
which left CTF + FA on

and

nvram set ctf_fa_mode=1
nvram commit
reboot
which left CTF + FA on

What was interesting is all I had to do was:
nvram set ctf_fa_cap=1
nvram commit
reboot
which left CTF on and the FA is now off.
But what is interesing is:
admin@NETGEAR-R7000:/tmp/home/root# nvram show | grep ctf
ctf_disable=0
size: 52989 bytes (12547 left)
ctf_disable_force=0
ctf_fa_cap=0
ctf_pt_udp=0
admin@NETGEAR-R7000:/tmp/home/root#
Just like posted previously, the ctf_fa_mode variable completely disappeared on it's own when nvram set ctf_fa_cap=0 and is issued but the interesting part is this time it did actually turned off FA without me having to do the nvram set ctf_fa_mode=1

Anyways, with FA turned off - the speed is now:
296.25Mbps down/11.43Mbps up

Enabled Jumbo frames and the results are:
CTF + FA: 238.96Mbps down/10.20Mbps up
CTF only with FA off: 283.37Mbps down/11.60Mbps up

 

[JohnHB]

Signal levels were the same, dont live near national guard, I live in HOUSTON, TX. The coaxial cable goes to the tap in my neighbors backyard which when the tech came out few weeks ago said needed to be serviced cause there was noise on the tap.

Hi I have the exact same modem router setup as you and I'm having the same issue? Direct from the modem I get almost the full 1GB but from the router I lose speed and it shows less then 200mb most of the time. Were you ever able to figure this out? What firmware version did you find the best results with?