MT7915 (MT7621): hard lockup when a station assigned to an AP_VLAN via wpa_psk_file starts passing traffic

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

1. Client connects to the single SSID using the passphrase mapped to VID 3.
2. hostapd assigns it to the AP_VLAN, the four-way handshake completes, DHCP succeeds.
3. 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.
4. ~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.

Start by reproducing the failure with mt7915e on the documented MT7621 setup, comparing traffic through the AP_VLAN path with the stable normal AP path. Trace the driver and AP_VLAN data path using the captured logs and configuration; done means traffic works without a hard lockup or watchdog reset, with a regression test or reproduction evidence if the project supports it.