Slower download speed in bridge mode

Need Help?

That's what we're here for! The goal of the Rogers Community is to help you find answers on everything Rogers. Can't find what you're looking for? Just ask!
cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
Resident Expert
Resident Expert
Posts: 6,986

Re: Slower download speed in bridge mode

Ok, if it worked previously and only failed recently, I'd suspect a port controller failure, which would be a chip issue.  I was thinking that maybe, there's a disconnect between the WAN port and the motherboard, but, from what you're indicating, that's probably not the issue. 

 

I wasn't aware that the AX86U was available.  Yup, if it dropped down to $250 on sale, that would definitely be worth considering.  That has a 1.8 Ghz quad core processor, probably one of the few all in one routers that have a quad core processor



Highlighted
Resident Expert
Resident Expert
Posts: 6,986

Re: Slower download speed in bridge mode

@forcefed here's more food for thought for your 86U which is to use on of the LAN ports as a WAN port, which the firmware should allow.  Its allowed in Merlin and I believe that its in the original Asus firmware.

 

In the 86U, reenable the firewall and DHCP server.

 

Under WAN .... Dual WAN:  Enable Dual WAN

 

Set the Primary WAN as an Ethernet LAN .... LAN Port 1


Set the Secondary WAN as the WAN port

 

Set the Dual WAN Mode to Fail Over

 

With the modem in Bridge mode, connect the modem's LAN port to the the 86U's LAN port 1. Leave the WAN port empty. That way, with Fail Over set as the Dual WAN mode, the 86U will never flip over to using the WAN port.  Hopefully, with nothing connected to the WAN port, the firmware won't complain about that fact.  Only one way to find out.

 

Give that a go and see what happens. I think it should work unless the WAN port problem prevents you from using Dual WAN mode properly. This should leave the other three LAN ports for local use.

 

 



Highlighted
I Plan to Stick Around
Posts: 34

Re: Slower download speed in bridge mode

Did i already mention that you're a genius? 😀

That's even better than the previous solution, dual wan works perfectly, always wondered if i'll ever use it https://i.imgur.com/qbYEwEM.jpg https://i.imgur.com/gLwvkg5.jpg

Now i can get updates to the ac86u, the ac56u i set as an ap since i needed 4 lan ports, all good now 👍

Highlighted
Resident Expert
Resident Expert
Posts: 6,986

Re: Slower download speed in bridge mode

lol, I'm not sure that I can list "occasional" genius on the resume.  Nice to see that its working so far.  One check that I would do is to go to grc.com specifically Services .... Shields UP to run the port check on "All Service Ports".  The result should show all ports stealthed, but, I'm wondering if running LAN port 1 as the WAN port would make any difference. It shouldn't, but, as they say, assume nothing .... look for proof.



I Plan to Stick Around
Posts: 34

Re: Slower download speed in bridge mode

How'd i do? 

 

 

Results from scan of ports: 0-1055

    2 Ports Open
 1052 Ports Closed
    2 Ports Stealth
---------------------
 1056 Ports Tested

Ports found to be OPEN were: 85, 554

Ports found to be STEALTH were: 135, 445

Other than what is listed above, all ports are CLOSED.

TruStealth: FAILED - NOT all tested ports were STEALTH,
                   - NO unsolicited packets were received,
                   - A PING REPLY (ICMP Echo) WAS RECEIVED.

 

 

Btw one thing i noticed with the ac86u is once i enable ai protection/qos/apps analysis/web history and traffic statistics my wired speedtest drops to around 400mbps, with everything disabled it peaks at 730mbps. However wireless speeds are fine at 6-700mbps  🤷‍♂️

Highlighted
Resident Expert
Resident Expert
Posts: 6,986

Re: Slower download speed in bridge mode

@forcefed all of those ports should be stealthed, as in no response to any external probes.  To a degree, that might depend on what you are running, but, I'd still be looking for no responses from those ports.  

 

If you have the time, patience, and opportunity to experiment, try the following:

 

1.  Rerun the grc.com .... Services .... Shields UP! test a couple of times to ensure that you see consistent results.

 

2.  In the router settings:  WAN .... Internet Connections ..... Enable UPNP:  ensure this is set to No unless you happen to be a gamer and rely on this instead of setting port forwarding manually.  I've never allowed UPNP to run or used port forwarding, and haven't seen any complaints from the family gamer. UPNP will set ports as requested by applications without your knowledge, which I won't allow.

 

3.  In the router settings:  WAN .... Virtual Server / Port Forwarding:  If there are existing port forwarding rules, and .... you didn't set them, or don't need them, delete any existing port forwarding rules.  Then set the Basic Config .... Enable Port Forwarding to OFF

 

4.  In the router settings:  Firewall .... General set the following:

            Enable Firewall:                                 Yes
            Enable DoS protection:                   Yes
            Logged packets type:                      Dropped
            Respond ICMP Echo (ping) Request from WAN:      No


  5.   Go through all of the settings under the General section on the left hand side and through all of their sub-pages.  Disable anything and everything that you know you're not using or never intend to use.  

 

6.  When that is all complete, reboot the router and pc and rerun the grc.com port scan two or three times looking for consistent results.  

 

7.  At this point I would expect to see that all ports are closed and that you shouldn't see any response from an external ping.  You might still see ports 135 and 445 are not stealthed (no response).  Consider shutting down your wifi for test purposes and disconnect everything except the pc that you're using to run the test.  Reboot the router and rerun the test again.  

 

8.  At this point, I'd expect to see all ports stealthed.  If you do see some strange results, consider disabling Dual Wan so that the WAN Port is once again the primary WAN port.  Reboot the router and rerun the grc.com test, just to see if there are any differences in the results from the two ports.  I think in theory the results should be the same, but, I've never used Dual Wan and haven't had the chance to check for any differences in port test results.  I'll have to try this with my 68U just to satisfy my curiosity.  When you're done testing, reenable Dual Wan and set Port 1 as the primary port.  Reboot the router. 

 

Fwiw, I know that AiProtection will affect IPV6 test speeds.  I suspect that AiProtect runs packet scans on the incoming traffic, and as a result, routing traffic thru the CPU for packet scan purposes results in lower throughout data rates.  AiProtect shouldn't slow the IPV4 tests.  I suspect that AiProtect uses site reputation to clear traffic from IPV4 sites.  Are you using IPV6 by any chance?

 

There is also the general issue of the Asus use of Hardware Acceleration to bypass the CPU wherever and whenever possible, resulting in higher throughput data rates.  The only problem with this is that various functions, like AiProtect(?), parental control, filtering, etc, can disable one or both parts of the Hardware Acceleration.  The components that comprise Hardware Acceleration are titled Runner and Flow Cache.  I think in the stock Asus Firmware that these are shown in the LAN .... Switch Control, but don't quote me on that one.  It been a while since I've used the stock firmware.  With any of the mentioned functions, I believe that Flow Cache will be disabled.  If you can have a look around the settings, you should come across this.  You can't set these.  They are set when the router boots up and their state will depend on what functions are active, or later on, when you enable a function that isn't compatible with Runner or Flow Cache, they will be disabled without warning the user (not good !!).  You will notice that Runner of Flow Cache is disabled when you run a speed test.  So, the starting point is to disable just about everything except the Firewall and DOS protection and run a speed test to see what results you end up with.  When you enable a function that you want to use, enable it, and then run a speed test to see what effect it has on the throughput.  You can also check on the Runner And Flow Cache status to see if there is a change in their status.  If you disable a router function that you know causes Runner and/or Flow Cache to be disabled, reboot the router.  The final status of those two after the reboot will depend on the number and type of router functions that are still enabled.   

 

Fwiw, with only IPV4 running, and no AiProtect, I'll see 940+ Mb/s down 32.8 Mb/s up.  That's using the www.speedtest.net Ottawa or Montreal Rogers servers.  I'll see pretty well the sane results using the Toronto Rogers server, but with higher latency due to the distance.  I'll located in Ottawa, hence the use of the Ottawa and Montreal Roger servers.  I don't use Aiprotect, instead, I use Merlin's firmware with two add-ons running, Skynet and Diversion.  Skynet is used to disallow access to malware sites and to block entire countries known for malware and hacking, and Diversion is used to block Adds.  There is an additional add-on available which is Suricata, but its not a full up version.  That is used for PfSense, OpnSense, type of routers as well which run the full Suricata version.  I'm thinking about it, but, the real answer is to run a router using PfSense, OpnSense or others.  That's the next leap .....

 

Ok, that should do it for now.  

 

Edit:  The gears are still churning.  There was or still is an issue with the Asus App.  I'm not sure of the current status, so, you might have to do some digging.  It seems that when you load and set the app, there was a setting to enable a remote connection.  Even with this setting disabled by user choice, the Router's WAN interface was still available which is a security risk, which might explain some of the open ports that you're seeing.  Here's a reference point to start from:

 

https://www.snbforums.com/threads/asus-router-app-and-unintentional-activation-of-remote-access-to-r...

 

This appears to be dated from Nov 2019:

 

https://thenextweb.com/security/2019/11/05/asus-alexa-data-leak-network-wi-fi/

 

There's more to this but I don't have time at the moment to look around to see what the specifics are and where this issue sits today. 



Highlighted
I Plan to Stick Around
Posts: 34

Re: Slower download speed in bridge mode

Figured out what was opening those ports, to view my security cameras i need to enable dmz to my dvr, otherwise i can't view them outside of the house. With dmz disabled it passed.

 

Results from scan of ports: 0-1055

    0 Ports Open
    0 Ports Closed
 1056 Ports Stealth
---------------------
 1056 Ports Tested

ALL PORTS tested were found to be: STEALTH.

TruStealth: PASSED - ALL tested ports were STEALTH,
                   - NO unsolicited packets were received,
                   - NO Ping reply (ICMP Echo) was received.

 

Still stuck on ipv4, with aiprotect off it goes up to 500 and disabling qos it goes up to 700, i'll disable qos for now but need aiprotect.