GL-MT300N-V2: client stays associated with a valid IP but all traffic dies periodically — only a client Wi-Fi toggle fixes it

Router
1

Environment

  • Device: GL-MT300N-V2 (Mango)
  • Firmware: 4.3.25
  • Wi-Fi: 2.4 GHz, AP mode, WPA2-PSK (AES), proprietary mt7628 driver
  • Affected client: iPhone (iOS) using a fixed/static private Wi-Fi MAC address

Symptom
Several times a day, at random intervals, the iPhone loses all connectivity through the router. While it is happening:

  • The client stays associated to the AP and keeps its valid DHCP lease / IP (e.g. 192.168.8.246).
  • No traffic passes in either direction — no internet, and the router's own admin/LuCI page at 192.168.8.1 is unreachable as well.
  • The only thing that restores it is toggling Wi-Fi off/on on the client (forcing a re-association). A router reboot is not required.
  • It always recurs later; it is not a one-off event.

Already ruled out

  • DHCP: the lease is valid during the outage
  • Client MAC: the private MAC is static (identical across the whole day), so this is not a rotating-MAC issue.
  • Config drift: the problem persists after a full factory reset AND after a complete reinstall via U-Boot.

I can provide the full logread output on request.

Has anyone had a similar experience or found a solution to this problem? Many thanks in advance.
Benni

2

Hi

Yes, if possible, please send us the device logs via private message after the issue occurs so that we can analyze them. It would also be helpful if you could include the iPhone's MAC address to assist with troubleshooting.

In addition, could you please clarify the following?

  1. Does this issue occur only on iOS devices, or do other devices experience it as well?
  2. When the issue occurs, is it only the iOS device that is affected, while other devices can still access the Internet normally through the MT300N's SSID?
  3. When the issue occurs, can other devices successfully ping the iPhone?
  4. Please SSH into the MT300N and run the following commands to check whether the iPhone's ARP entry appears normal at that time:
    ip neighbor
cat /proc/oui-tertf/term
How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image632×233 19.1 KB

4

I have the same, with Android phone.

Did you find a solution?

5

Hi @Janekpol, @will.qiu from GLiNet is currently investigating in this topic. But currently no more information on that.

6

Hi

Are you experiencing exactly the same symptoms as the op?

If so, could you please provide the phone model and Android version of the affected device? We'd like to see if we can reproduce the issue in our local test environment.

We are still waiting for the testing team's verification. Once we are able to reproduce the issue, our development team will begin working on a fix.

7

Hi,

We've observed similar behavior during our internal testing. It appears to be related to Apple devices entering sleep mode. However, once the device wakes up and you browse a few web pages, the connection usually recovers automatically without needing to toggle Wi-Fi off and back on.

Could you help us reproduce the issue again and capture some packet traces via SSH so we can confirm whether you're seeing the same behavior? Please follow the steps below:

  1. SSH into the router and open two terminal windows so you can run the following commands simultaneously:

    tcpdump -i br-lan -s 0 -w /tmp/iphone-lan.pcap "host $IPHONE_IP or ether host $IPHONE_MAC or arp or icmp"
tcpdump -i "$WAN_IF" -s 0 -w /tmp/iphone-wan.pcap "icmp or tcp or udp"

    Please replace $IPHONE_IP and $IPHONE_MAC with the actual IP and MAC address of your iPhone. You can determine $WAN_IF by running ip -br a and identifying the interface that has the WAN IP address.

  2. Let the packet capture run for about 5 minutes to collect enough data.

  3. Then toggle the Wi-Fi on your Apple device off and back on so that network connectivity is restored.

  4. Continue capturing traffic for another 5 minutes. After that, press Ctrl + C to stop the captures, then use SCP to copy the .pcap files and send them to us via private message for analysis.

8

Hi,

Thank you for providing the packet capture files.

After reviewing them, our R&D team confirmed that the behavior appears to be consistent with the issue we observed internally, where the client device enters sleep mode.

We'll look into improving the behavior in this scenario in a future firmware release.

Thank you for your cooperation and patience.