ASUS RT-AC68U Pause frame control

[BosseSwede]

I have a newly installed fiber connection at my summer cottage.
I subscribe to a 250/250 Mbps service.
I have installed my old home router (RT-AC68U) there when I visited the site after fiber was activated.
The site is 100 km away so not easily accessed.

The router is configured with OpenVPN connection to my home LAN and routing is set up to allow bi-directional access between the two networks.
This works fine functionally, but I have discovered a speed problem...

The measured down/up speed to the Internet does not comply to the 250/250 Mbps I have subscribed to.
Download is always at 250 but upload varies wildly over the day to sometimes ridiculously low values in single digit Mbps levels.
See attached graph below.

I have complained to my ISP and they have forwarded the complaint to the fiber network provider, which required me to make some specific tests only possible on location:
- Attach a computer directly to the fiber interface
- Disconnect anything else connected there (the router)
- Make speed tests against several test providers
- Report results

Again I saw these problems using my Windows laptop as test device and reported.

Then I reconnected the router and also connected a RaspberryPi4 directly to the fiber interface where I had the laptop during testing.
This RPi4 is configured to run Ookla Speedtest CLI from cron at 30 min interval and log the result to a logfile.
It also reports the log to me so I can follow the progress.

The fiber network provider has replied to my ISP and said (translated by me):

We see that there are a number of "pause frames" coming from a device on the LAN1 connection.
Ask the customer to test with a single device connected at a time to exclude the possibility of a local problem source.
Return if the problem appears on devices connected alone to the CPE.

The other "device" I have now re-attached on LAN1 is the Asus router and behind that are another HP Linux computer and a slave Access Point (another Asus router).

Due to the distance to the cottage it is not a simple task to rearrange the physical connections...

QUESTIONS:
1) Is it possible to configure the Asus RT-AC68U router to NOT generate (or transfer) the pause frames they complain about?
2) Is it really possible that the "pause frames" they complain about can cause such problems on a different LAN connection on the fiber interface (it has 4 Ethernet connectors)?

The current log graph covering a month of measurements looks like this:

 

[ColinTaylor]

2) Is it really possible that the "pause frames" they complain about can cause such problems on a different LAN connection on the fiber interface (it has 4 Ethernet connectors)?

It's possible (but unlikely) that two devices connected to the same switch might cause issues. However, you've proved that's not the problem when you connected a single different device (the laptop) to the ISP's equipment and experienced the same problem. I'm assuming that while the laptop was connected you had physically unplugged any other devices from the ISP's equipment.

 

[BosseSwede]

It's possible (but unlikely) that two devices connected to the same switch might cause issues. However, you've proved that's not the problem when you connected a single different device (the laptop) to the ISP's equipment and experienced the same problem. I'm assuming that while the laptop was connected you had physically unplugged any other devices from the ISP's equipment.

Yes, that was the whole reason I had to travel to the location to do the tests.
I disconnected the router cable at the fiber box and connected the laptop instead. Then made several different tests using OOkla and and a couple of other services my ISP had specified.
After that was done and documented I reconnected the router and replaced the laptop with a Raspberry Pi4B I had brought with me (after DHCP release on the laptop). It is used to log speed on the outside of the router going forward. It runs a server type Linux (PiOS, which is Debian bullseye based).
It uses the Ookla CLI speedtest as a cron job every 30 minutes to log the speed to a logfile and send the result back home to me. That is how I have created the graph shown above.
What I have run up against is that the fiber provider sees these packets and requires me to repeat the original test...

By what I read there should be no such pause frames and this must mean that reconnecting the router made them re-appear.
So this is why I ask if there is a way to block them on the router. Or if the router firmware could be updated to solve it. Currently it runs: Firmware Version: 3.0.0.4.384_32799
I have downloaded an update file to version: 3.0.0.4.386.46065, but I have not dared to update the f/w remotely in case it would hang and require a physical power cycle to restart...
But I guess that if it would solve the problem I need to do it anyway; I access the router config page via VPN.

I have googled the problem and found a related issue here: OpenWrt flooding the network with pause frames
But that seems to be related to some unmanaged network switches...

 

[ColinTaylor]

I find it unlikely that the router is sending pause frames but I suppose anything is possible. Also, it makes no sense (even if it does support it) as the only reason the router would do that is if it wanted the ISP device to slow the downloads. You don't have a problem with downloads, you have a problem with uploads. So therefore, if anything, if would be the ISP device that is sending pause frames to the router. But again, none of this affected the laptop test.

EDIT: Does the ISP fibre box officially support multiple host devices being connected to it? If so that would imply that it's also a router as well as an ONT.

I don't know whether the RT-AC68U supports pause frames. The only way to know for sure would be to install ethtool on the router via Entware. Then you could query it. For example on my RT-AX86U:

# ethtool --show-pause eth0
Pause parameters for eth0:
Autonegotiate:  on
RX:             off
TX:             off
RX negotiated:  off
TX negotiated:  off

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 12
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Link detected: yes

 

[itpp20]

A morality tale: The Importance of flow control

So a thread either on here or over on Anandtech got me thinking about flow control a bit. I've never bothered playing with it on a network. Just leaving the defaults, and oh hey, things seem to work okay. Well in testing my network config, I delved in to testing flow control too and I am glad...

www.snbforums.com

Sounds like a flow control issue, this may be a vpn setting (if not used outside a vpn).

 

[ColinTaylor]

A morality tale: The Importance of flow control

So a thread either on here or over on Anandtech got me thinking about flow control a bit. I've never bothered playing with it on a network. Just leaving the defaults, and oh hey, things seem to work okay. Well in testing my network config, I delved in to testing flow control too and I am glad...

www.snbforums.com

Sounds like a flow control issue, this may be a vpn setting (if not used outside a vpn).

Flow control and pause frames are the same thing. It doesn't apply to VPN's as it operates on the Ethernet datalink layer.

 

[itpp20]

It does if the option is there on the vpn interface which can be effective outside the real interface (which may or may not use flow control).

I don't agree FC is the same as Pause frames,

Understanding CoS Flow Control (Ethernet PAUSE and PFC) | Junos OS | Juniper Networks

www.juniper.net

Albeit this ain't a one on one explanation, it describes the implementation differences.

 

[BosseSwede]

Do you think I could dare update the f/w of the RT-AC68U via VPN access to its GUI?
If it fails then I cannot power cycle it from here..

 

[ColinTaylor]

It does if the option is there on the vpn interface which can be effective outside the real interface (which may or may not use flow control).

I don't agree FC is the same as Pause frames,

Understanding CoS Flow Control (Ethernet PAUSE and PFC) | Junos OS | Juniper Networks

www.juniper.net

Albeit this ain't a one on one explanation, it describes the implementation differences.

Sorry, I think we're talking about different things here. I was talking specifically about the pause frames the OP was asking about, i.e. 802.3x. You seem to be talking about something else.

I still don't understand the VPN reference as the speed tests aren't going over a VPN.

Either way this is a red herring from the ISP as the problem was still there when only the laptop was connected.

 

[ColinTaylor]

Do you think I could dare update the f/w of the RT-AC68U via VPN access to its GUI?
If it fails then I cannot power cycle it from here..

You could try. But I wouldn't be surprised if you had problems, either with the reboot or just with the VPN starting up.

If it were a normal incremental update I'd be more confident but you're going from a 384.x release to a 386.x release. Also, your current firmware is 3 1/2 years and 22 releases behind the current version.

 

[itpp20]

I still don't understand the VPN reference as the speed tests aren't going over a VPN.

Wasn't that the initial finding where a problem was seen?

"The router is configured with OpenVPN connection to my home LAN and routing is set up to allow bi-directional access between the two networks.
This works fine functionally, but I have discovered a speed problem..."

Or did I miss something?

 

[itpp20]

Do you think I could dare update the f/w of the RT-AC68U via VPN access to its GUI?
If it fails then I cannot power cycle it from here..

I went from 384.17_0 to 386.5_2 without too much issues but I'm not using vpn, ymmv.

 

[ColinTaylor]

Wasn't that the initial finding where a problem was seen?

"The router is configured with OpenVPN connection to my home LAN and routing is set up to allow bi-directional access between the two networks.
This works fine functionally, but I have discovered a speed problem..."

Or did I miss something?

Maybe @BosseSwede can clarify this. My understanding was that the VPN was for LAN to LAN only and the internet traffic wasn't going via the VPN.

EDIT: That (direct internet) would have to be the case as he completely removed the router running the VPN when he was on-site and tested the connection from a locally attached laptop. The Pi is also directly connected to the ISP device and doesn't go via the router's VPN.

 

[L&LD]

With such old hardware and firmware, you're in a bad position to quickly determine if one or both are at fault here. I would not be as confident in upgrading Asus stock firmware (without issues afterward) vs. RMerlin firmware to RMerlin firmware (even from 384.xx to 386.xx versions).

With the distance to the cottage and the high ISP speeds involved, a new router seems warranted here. An RT-AX68U seems like an ideal candidate. If you want to do this in a single trip.

Not only has the hardware, SDKs, and security concerns changed, but the age of the router/power supply may be an issue too. Does your cottage network run on a UPS?

Even if the upgrade to 386.xx was performed successfully, you couldn't test it properly without fully resetting the router (at least, not to my satisfaction/experience), if the issues continued afterward. Note that reports (and my own experience) have shown that toggling settings and features on/off isn't the same as not touching them at all and will affect the router/network in unexpected ways. A few posts recently even indicate that simply navigating to a tab in the GUI has the same effect (with no need to toggle anything to observe issues).

While I regularly travel similar distances to my more remote customers a few times a month, I also bring a fully setup router too. (You don't need to connect the WAN port when setting up a new router until it is (as much as possible), otherwise fully configured).

Your issues might be solved with a simple/full reset on the current firmware. Or, using current firmware (and a full reset afterward). Or, the hardware needs replacing, soon.

Either way, the time and distance involved to do the above points to a new router being the most cost-effective choice, for me. One that has been fully set up as much as possible before you drive out to install it.

I'll be curious to see what the solution will be here. And of course, I hope that other members here will be able to solve this for you faster and easier with the skills they have too.

My work lately has been concentrated on replacing AC class routers for most of the reasons above. The RT-AC68U (particularly the original 800MHz version) seems to have almost reached the end of the road of its usefulness around here. Particularly with symmetrical ISP connections.

Current Order of Recommended Routers Late 2021

[Wireless] ASUS router Hard Factory Reset | Official Support | ASUS Global

Fully Reset / Best Practice Setup / More

 

[BosseSwede]

With the distance to the cottage and the high ISP speeds involved, a new router seems warranted here. An RT-AX68U seems like an ideal candidate. If you want to do this in a single trip.

I have already purchased an RT-AC86U router and configured it for use at the cottage when I get there later in spring.
The f/w update question was really about doing it remotely....
Seems like that is a bad idea, so I will wait until I get there with the new router.
I already have the same 86 router model on my home LAN.