Related to #881, which describes the same trigger on MT7981. The observable failure differs on this
platform, so I am filing it separately rather than commenting on a closed issue.
Summary
With dynamic_vlan=1 and per-PSK VLAN assignment through wpa_psk_file, a client that is placed into
an AP_VLAN associates and obtains a DHCP lease normally. The client then reports that it has no
internet connectivity, and roughly 10–20 seconds later the device locks up hard and is reset by the
watchdog.
The association itself is not the problem. Everything up to and including DHCP completes cleanly. What
fails is the data path afterwards — and it appears to fail before the lockup, not as a result of it.
Hardware / software
|
|
| Device |
D-Link DAP-X1860 A1 (dlink,dap-x1860-a1) |
| SoC |
MediaTek MT7621, target ramips/mt7621 |
| WiFi |
mt7915e, HW/SW Version 0x8a108a10, Build Time 20240429200716a |
| WM firmware |
____000000, Build Time 20240429200752 |
| WA firmware |
DEV_000000, Build Time 20240429200812 |
| OpenWrt |
25.12.5, r33051-f5dae5ece4 |
| Kernel |
6.12.94 |
Flow offloading is disabled (firewall.@defaults[0].flow_offloading='0').
Driver module parameters:
mt76/mt7915e: wed_enable = N
sr_scene_detect = Y
enable_6ghz = N
Configuration
One 5 GHz AP on radio1 with dynamic VLANs, four VLAN networks attached:
config wifi-iface 'If_Wifi_5'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'DD-Travel'
option encryption 'psk2+ccmp'
option dynamic_vlan '1'
config wifi-vlan
option iface 'If_Wifi_5'
option name 'vl3'
option network 'zuhause'
option vid '3'
# ... vl4/vid 4, vl5/vid 5, vl6/vid 6 accordingly
config wifi-station
option iface 'If_Wifi_5'
option vid '3'
option key '<per-VLAN passphrase>'
# ... one per VID
The VLAN networks are bridge VLANs on br-lan (br-lan.3 = 192.168.13.0/24, etc.), each with its own
DHCP server. hostapd is generated with dynamic_vlan=1, vlan_naming=1, vlan_no_bridge=1.
Resulting interfaces: phy1-ap0 (AP) plus phy1-ap0-vl3 … phy1-ap0-vl6 (AP/VLAN).
Reproduction
- Client connects to the single SSID using the passphrase mapped to VID 3.
- hostapd assigns it to the AP_VLAN, the four-way handshake completes, DHCP succeeds.
- The client has a valid address but reports "no internet connection" — its connectivity check does
not get through, so the data path over the AP_VLAN is already not working at this point.
- ~10–20 s later the device is gone. Watchdog reset, full reboot.
If the client has the network saved and reconnects automatically, this becomes a reboot loop:
boot → client reconnects → lockup → reset → repeat, roughly every 60–90 seconds. Disabling WiFi on
the client is required to break out of it.
Log evidence
Nothing survives on persistent storage, because nothing is written before the device dies. I captured
the following by streaming logread -f over the network to a second machine (client MAC redacted):
hostapd: phy1-ap0: STA <client> IEEE 802.11: authenticated
hostapd: phy1-ap0: STA <client> IEEE 802.11: associated (aid 2)
hostapd: Assigned VLAN ID 3 from wpa_psk_file to <client>
hostapd: phy1-ap0: AP-STA-CONNECTED <client> vlanid=3 auth_alg=open
hostapd: phy1-ap0: STA <client> WPA: pairwise key handshake completed (RSN)
hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED <client>
dnsmasq-dhcp[1]: DHCPREQUEST(br-lan.3) 192.168.13.100 <client>
dnsmasq-dhcp[1]: DHCPACK(br-lan.3) 192.168.13.100 <client> Redmi-Note-9S
[ ~15 seconds, no further output ]
[ stream torn down, device unreachable ]
During that final ~15 second window the client displayed "no internet connection" while holding a
valid lease. So DHCP still made it through the AP_VLAN, but the traffic that followed did not — and
the lockup came after that, not instead of it.
Difference from #881
On MT7981, #881 reports MCU timeouts (send message 000130ed timeout) followed by SER recovery with
status 0x00000004. On this MT7915/MT7621 device there is no such output at all — no MCU timeout,
no SER, no oops, no panic, no driver message of any kind. The last line in the log is unrelated routine
output from a userspace daemon, mid-cycle.
This is despite panic_on_oops=1 and panic=3, which would have produced a visible oops and a
deliberate reboot. So this is not a kernel oops but a hard lockup, with the watchdog doing the reset.
I mention this because it may mean the failure is reached before any error path can run, rather than
being a recoverable chip error as on MT7981.
Not reproducible with every client
A Linux laptop has been connected to the same AP for hours at a time without a single incident. The
Android phone above triggers the lockup repeatedly, but not instantly and not on every attempt: it was
observed sitting on the AP_VLAN without causing trouble while idle, and on the captured occasion the
device died roughly 15 seconds after DHCP completed. That points at a dependency on actual traffic
rather than on association, which is consistent with the small-unicast-TX trigger described in #881.
Workaround
Adding a second SSID bound directly to the VLAN network, as a regular AP with dynamic_vlan=0,
avoids the AP_VLAN path entirely and is stable:
config wifi-iface 'If_Wifi_Home'
option device 'radio1'
option mode 'ap'
option network 'zuhause'
option ssid 'DD-Home'
option encryption 'psk2+ccmp'
option key '<same passphrase as the VID 3 entry>'
The client lands on phy1-ap1, gets an address from the same DHCP server on br-lan.3, and the
existing policy routing continues to work unchanged because it matches on the source subnet rather
than on the interface. All AP_VLAN interfaces are then unused.
Worth noting for the diagnosis: with this SSID the same client on the same VLAN network with the
same address range now has full connectivity and has been passing traffic for a while without any
issue, and the device has been up and idle-stable since. The only thing that changed is that the
station sits on a normal AP interface instead of an AP_VLAN. That isolates the problem to the AP_VLAN
path rather than to the VLAN, the bridge, the DHCP server, or the client.
Related to #881, which describes the same trigger on MT7981. The observable failure differs on this
platform, so I am filing it separately rather than commenting on a closed issue.
Summary
With
dynamic_vlan=1and per-PSK VLAN assignment throughwpa_psk_file, a client that is placed intoan AP_VLAN associates and obtains a DHCP lease normally. The client then reports that it has no
internet connectivity, and roughly 10–20 seconds later the device locks up hard and is reset by the
watchdog.
The association itself is not the problem. Everything up to and including DHCP completes cleanly. What
fails is the data path afterwards — and it appears to fail before the lockup, not as a result of it.
Hardware / software
dlink,dap-x1860-a1)ramips/mt7621mt7915e, HW/SW Version0x8a108a10, Build Time20240429200716a____000000, Build Time20240429200752DEV_000000, Build Time20240429200812r33051-f5dae5ece4Flow offloading is disabled (
firewall.@defaults[0].flow_offloading='0').Driver module parameters:
Configuration
One 5 GHz AP on
radio1with dynamic VLANs, four VLAN networks attached:The VLAN networks are bridge VLANs on
br-lan(br-lan.3= 192.168.13.0/24, etc.), each with its ownDHCP server. hostapd is generated with
dynamic_vlan=1,vlan_naming=1,vlan_no_bridge=1.Resulting interfaces:
phy1-ap0(AP) plusphy1-ap0-vl3…phy1-ap0-vl6(AP/VLAN).Reproduction
not get through, so the data path over the AP_VLAN is already not working at this point.
If the client has the network saved and reconnects automatically, this becomes a reboot loop:
boot → client reconnects → lockup → reset → repeat, roughly every 60–90 seconds. Disabling WiFi on
the client is required to break out of it.
Log evidence
Nothing survives on persistent storage, because nothing is written before the device dies. I captured
the following by streaming
logread -fover the network to a second machine (client MAC redacted):During that final ~15 second window the client displayed "no internet connection" while holding a
valid lease. So DHCP still made it through the AP_VLAN, but the traffic that followed did not — and
the lockup came after that, not instead of it.
Difference from #881
On MT7981, #881 reports MCU timeouts (
send message 000130ed timeout) followed by SER recovery withstatus
0x00000004. On this MT7915/MT7621 device there is no such output at all — no MCU timeout,no SER, no oops, no panic, no driver message of any kind. The last line in the log is unrelated routine
output from a userspace daemon, mid-cycle.
This is despite
panic_on_oops=1andpanic=3, which would have produced a visible oops and adeliberate reboot. So this is not a kernel oops but a hard lockup, with the watchdog doing the reset.
I mention this because it may mean the failure is reached before any error path can run, rather than
being a recoverable chip error as on MT7981.
Not reproducible with every client
A Linux laptop has been connected to the same AP for hours at a time without a single incident. The
Android phone above triggers the lockup repeatedly, but not instantly and not on every attempt: it was
observed sitting on the AP_VLAN without causing trouble while idle, and on the captured occasion the
device died roughly 15 seconds after DHCP completed. That points at a dependency on actual traffic
rather than on association, which is consistent with the small-unicast-TX trigger described in #881.
Workaround
Adding a second SSID bound directly to the VLAN network, as a regular AP with
dynamic_vlan=0,avoids the AP_VLAN path entirely and is stable:
The client lands on
phy1-ap1, gets an address from the same DHCP server onbr-lan.3, and theexisting policy routing continues to work unchanged because it matches on the source subnet rather
than on the interface. All AP_VLAN interfaces are then unused.
Worth noting for the diagnosis: with this SSID the same client on the same VLAN network with the
same address range now has full connectivity and has been passing traffic for a while without any
issue, and the device has been up and idle-stable since. The only thing that changed is that the
station sits on a normal AP interface instead of an AP_VLAN. That isolates the problem to the AP_VLAN
path rather than to the VLAN, the bridge, the DHCP server, or the client.