Ok, well, that doesn't leave much left then. Only suggestions are to nuke both modem and router to see what happens. If that doesn't work, then I'd swap modems. So, I would do this:
1. Run a factory reset on the modem. After the reset, disable ports 1 and 2 and then kick the modem into Bridge mode. Check the connected port LED to see if its flashing amber. Check the LED in both Gateway mode and Bridge mode. If that doesn't work:
2. Run a factory reset on the 86U. Before that I would:
a. select "Format JFFS partition at next boot" which is located in the Admin ..... System page. Reboot the
86U and set the modem up just enough to navigate to the Admin ..... Restore/Save/Upload Setting tab.
b. On that tab, Select "Initialize all the settings, and clear ......" then select "Restore" to run to return the 86U
to Factory Default settings.
3. After the Factory reset on the 86U check the modem's connected port LED to see if its connecting at 1 Gb/s.
4. If that doesn't work, swap the modem at the nearest Rogers store. You may have to call tech support to arrange for a work order to do that. Seems that some stores need the work order and some don't. Call the store first to see if they have any 4582's in stock and ask if they need a work order to do the swap. If not, yay. If yes, ok, call tech support to generate the paperwork.
It makes no sense that two 86Us end up with the same problem. You should be buying lottery tickets .....
I'm hoping that a factory reset on the modem first, then the 86U will solve the problem. Maybe the firmware update to version 7.x was a enough of a change that the 86U isn't satisfied when connecting to the modem. Version 7.x is a new kernel, so, possibly some changes occurred with the port controller firmware, don't know, just speculating.
Edit; One last thought, before swapping modems is to load Merlin's latest firmware version and run a factory reset after the firmware load to see if that changes anything. Version 384.19 can be downloaded from site on the following page:
https://www.asuswrt-merlin.net/download
Direct download page is:
https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC86U/
Don't quote me on that one, but I would think that Merlin's version does. Any questions about Merlin's version can be posted in the Merlin forum within the SmallNetBuilders site:
https://www.snbforums.com/forums/asuswrt-merlin.42/
My thinking about the modem and router factory resets is that possibly there's some value sitting in NVRAM in either the modem or router that is causing the current problem. Hopefully, the factory reset will completely clear any offending NRVAM value after which the two devices will operate as expected. There's no reason that I can think of that is causing the current problem.
Food for thought, before running a factory reset for the 86U, consider cloning the MAC address of some device on your network. That is located in WAN ..... Internet Connection.
Fwiw, the values of interest for my 86U within that section are:
WAN MTU: 1500
MAC Address: set to a MAC Address that works
DHCP query frequency: Aggressive Mode
If you clone an address from your network, reboot the router after its set. Check the network map after the reboot to ensure that the router has been assigned a WAN IP address.
This has to be absolutely frustrating. Beyond a modem swap, I'm stumped. The fact that the modem connects to a LAN port at 1 Gb/s indicates that the modem will connect properly, so the question is, which of the two devices has some value set that is preventing the router, with its specific MAC address, from connecting properly.
If you connect the 86U WAN port to one of the AX58U LAN ports, and then check the 86Us port speeds as you posted above, what do you get for the WAN port connect rate, still 100 Mb/s instead of 1000 Mb/s? If its still showing 100 Mb/s port speed rate, are you beyond the time to return the 86U to the store or to get Asus to RMA the 86U?
You can use the 86U as an Access Point by disabling the firewall and DHCP server and connecting a LAN port from the AX58U to any one of the 86U's LAN ports. That's how to manually configure a router as an access point if it doesn't have an Access Point mode. Although the 86U has an Access Point mode, that would require you to use the slow WAN port, so, keeping the 86U in router mode and using a LAN port to connect with, would allow you to run the 86U as an Access Point, running at a 1 Gb/s connect rate.
The only problem with the ac56u is that the last Merlin update for that router RT-AC56U_384.6_0.zip dated 2018-07-25. That's over two years old.
https://sourceforge.net/projects/asuswrt-merlin/files/RT-AC56U/
Asus's last update was Version 3.0.0.4.382.51641 dated 2019/11/05:
https://www.asus.com/us/Networking/RTAC56U/HelpDesk_Download/
Although the 86U can be used as an access point, you need an up to date router at the front end. At the very least, I'd update to the last Asus version, but, that's still 10 months old. Asus is working on Version 386.x but the 56U isn't on the support list, at least not to date. Its possible that Asus has put the 56U out to pasture:
https://www.snbforums.com/threads/asuswrt-386-rc2-public-beta-with-full-functions-aimesh-2-0.65235/
Hate to say it, and I'm loath to recommend spending money, to anyone, but I suspect that you're going to have to keep the AX58U, or if you return it, consider buying another router. Ten months and counting for a firmware update is a long time, in terms of the security updates that keep rolling out.
Its possible that we'll see the AX86U one of these days. Its out, but I don't believe that its been released in Canada yet.
I'm wondering if there's an issue with the WAN port to motherboard connection? If you're adventurous, maybe its worth taking the back off of the 86U to see if there's any apparent problem between the WAN connector port and the motherboard.
Did the 86U WAN port ever work properly?
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
@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.
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.
@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:
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.
-
55446 views
-
12 Likes
-
-
