Timeout in response on status page

I’m regularly getting a red-text banner indicating that there is a timeout in response o the status page. The router has a two clients, an iPhone and iWatch, and is effectively idle. It is hard wired to the network from which it is being observed.

OpenWrt 21.02-SNAPSHOT r15812+870-46b6ee7ffc
Gaps also occur with 4.1.3 snapshot build Date Compiled: 2023-01-06 13:40:40 (UTC-08:00)

What is this model? AXT1800?

Are you using wifi connection and observe that wifi is disconnected?

GL-MT3000, hardwired to the computer running the browser.

The discussion of the GL-AXT1800 is to try to provide an AX client. My Comfast dongles are coming whenever Cainiao “express” gets them here from China, which is probably several weeks.

My two "GL-MT300N-V2 Mango have the same problem". (But not my GL-MT3000 Beryl AX.)
Ongoing time outs!

Firmware 4.3.7, 4.3.10, 4.3.11 and 4.3.17 (beta)

Workaround:

While using in the console: ping 192.168.8.1

Can you explain? MT300N-V2 is not strong. Should not keep the Admin panel active all the time.

It's not about being open all the time.
It is hardly possible to configure the Mango via the GUI. - Via Wifi!
(Easily via LAN.)

Caused:
Wifi driver (Mango) loses connection to clients whose Wifi is doing power management. What has been implemented for many years.

Workaround 1: Permanently ping the clients so that the client does not activate Powersafe in the WiFi. The ping can also be done to a non-existent IP. - It still stops the client from going into Powersafe and no longer times out.

Workaround 2 (PC): Deactivate WiFi power management on the clients.

These are not real solutions!

Is this a common problem?

I checked my wifi card has power management as well. Power management should not causing not be able to configure the router at all.

I have a few routers and many clients here:

For example:

  • 2x GL-MT3000
  • 1x TP-Link Archer C5V1 (with actual OpenWRT)
  • Speedport Smart 4 Typ B
  • D-Link DI 524 ( completely outdated - to test)
    ...
  • 2x GL-MT300N-V2

Only the two routers (Mango) currently generate time outs with client-side power management.

A small selection of clients:

  • PC and Laptop (Linux Debian stable, Windows 11)
  • Mobile Phones and Tablets, E-book reader (Android 9 - 13)
    ...

The last time I had this was a few years ago with a WLAN USB stick with incomplete Linux support.

Here too, deactivating the power management on the client side or keeping the connection open via ping helped.

I've read a few posts here about "timeout problems" that are probably due to power management incompatibility.

Not only is the configuration more difficult, websites also load more slowly, streams stop, and WiFi telephony drops out.

Then ping and the first results are over 200ms. If ping remains activated, the values ​​return to normal and the connection remains stable.

With client-side WiFi power management deactivated or prevented, the Mango performs surprisingly well. - Within the scope of his possibilities. :grin:

Can you let me know what is your wifi card and driver?

As long as we can replicate the problem locally it will be easier to solve.

Laptop (Debian stable):
Intel Corporation Wi-Fi 6 AX201

USB: TP-Link RTL8812AU Archer T4U 802.11ac (Driver: GitHub - morrownr/8812au-20210820: Linux Driver for USB WiFi Adapters that are based on the RTL8812AU Chipset - v5.13.6-23)

Short test with TP-Link RTL8812AU Archer T4U:

/etc/modprobe.d/8812au.conf

options 8812au rtw_switch_usb_mode=0 rtw_led_ctrl=1 rtw_power_mgnt=1 rtw_country_code=DE

PING 192.168.118.1 (192.168.118.1) 56(84) bytes of data.
64 bytes from 192.168.118.1: icmp_seq=1 ttl=64 time=56.4 ms
64 bytes from 192.168.118.1: icmp_seq=2 ttl=64 time=2.57 ms
64 bytes from 192.168.118.1: icmp_seq=3 ttl=64 time=2.57 ms
64 bytes from 192.168.118.1: icmp_seq=4 ttl=64 time=2.48 ms
64 bytes from 192.168.118.1: icmp_seq=5 ttl=64 time=5.26 ms
64 bytes from 192.168.118.1: icmp_seq=6 ttl=64 time=2.24 ms
64 bytes from 192.168.118.1: icmp_seq=7 ttl=64 time=4.81 ms
64 bytes from 192.168.118.1: icmp_seq=8 ttl=64 time=2.57 ms
64 bytes from 192.168.118.1: icmp_seq=9 ttl=64 time=410 ms
64 bytes from 192.168.118.1: icmp_seq=10 ttl=64 time=5.49 ms
64 bytes from 192.168.118.1: icmp_seq=11 ttl=64 time=5.10 ms
64 bytes from 192.168.118.1: icmp_seq=12 ttl=64 time=2.63 ms
64 bytes from 192.168.118.1: icmp_seq=13 ttl=64 time=5.65 ms
64 bytes from 192.168.118.1: icmp_seq=14 ttl=64 time=2.57 ms
64 bytes from 192.168.118.1: icmp_seq=15 ttl=64 time=4.63 ms
64 bytes from 192.168.118.1: icmp_seq=16 ttl=64 time=2.24 ms
64 bytes from 192.168.118.1: icmp_seq=17 ttl=64 time=5.62 ms
64 bytes from 192.168.118.1: icmp_seq=18 ttl=64 time=2.60 ms
64 bytes from 192.168.118.1: icmp_seq=19 ttl=64 time=2.88 ms
64 bytes from 192.168.118.1: icmp_seq=20 ttl=64 time=2.43 ms
64 bytes from 192.168.118.1: icmp_seq=21 ttl=64 time=4.71 ms
64 bytes from 192.168.118.1: icmp_seq=22 ttl=64 time=3.38 ms

/etc/modprobe.d/8812au.conf

options 8812au rtw_switch_usb_mode=0 rtw_led_ctrl=1 rtw_power_mgnt=0 rtw_country_code=DE

PING 192.168.118.1 (192.168.118.1) 56(84) bytes of data.
64 bytes from 192.168.118.1: icmp_seq=1 ttl=64 time=3.79 ms
64 bytes from 192.168.118.1: icmp_seq=2 ttl=64 time=4.16 ms
64 bytes from 192.168.118.1: icmp_seq=3 ttl=64 time=2.18 ms
64 bytes from 192.168.118.1: icmp_seq=4 ttl=64 time=2.45 ms
64 bytes from 192.168.118.1: icmp_seq=5 ttl=64 time=2.74 ms
64 bytes from 192.168.118.1: icmp_seq=6 ttl=64 time=9.82 ms
64 bytes from 192.168.118.1: icmp_seq=7 ttl=64 time=2.58 ms
64 bytes from 192.168.118.1: icmp_seq=8 ttl=64 time=2.13 ms
64 bytes from 192.168.118.1: icmp_seq=9 ttl=64 time=2.23 ms
64 bytes from 192.168.118.1: icmp_seq=10 ttl=64 time=2.12 ms
64 bytes from 192.168.118.1: icmp_seq=11 ttl=64 time=2.34 ms
64 bytes from 192.168.118.1: icmp_seq=12 ttl=64 time=2.61 ms
64 bytes from 192.168.118.1: icmp_seq=13 ttl=64 time=2.21 ms
64 bytes from 192.168.118.1: icmp_seq=14 ttl=64 time=2.58 ms
64 bytes from 192.168.118.1: icmp_seq=15 ttl=64 time=2.58 ms
64 bytes from 192.168.118.1: icmp_seq=16 ttl=64 time=2.33 ms
64 bytes from 192.168.118.1: icmp_seq=17 ttl=64 time=2.57 ms
64 bytes from 192.168.118.1: icmp_seq=18 ttl=64 time=2.60 ms
64 bytes from 192.168.118.1: icmp_seq=19 ttl=64 time=2.24 ms
64 bytes from 192.168.118.1: icmp_seq=20 ttl=64 time=2.55 ms
64 bytes from 192.168.118.1: icmp_seq=21 ttl=64 time=1.64 ms
64 bytes from 192.168.118.1: icmp_seq=22 ttl=64 time=2.18 ms
64 bytes from 192.168.118.1: icmp_seq=23 ttl=64 time=2.20 ms

Ping values ​​are similar on Android (mobile phone, tablet) and other PCs.

No problems with power management with other routers (e.g. GL-MT3000)

Addendum:
(Power management active on clients.)

Dirty trick on GL MT300N V2 (Mango):

Edit: /etc/wireless/mt7628.dat

from: BeaconPeriod=100
to: BeaconPeriod=50

See also:

The connection is smoother on all clients.
Dashboard reports little or no timeouts.

I will continue to monitor this.