Follow-ups left open by the station identity seam (#460)

[josephnef]

Follow-ups left open by #460 (IRadio::SetStationIdentity, the MT7612U station arm, merged as 77b907a). None blocks the seam; each is a measurement or a port that the PR named and did not do.

Library

• The Realtek station arm. SetStationIdentity returns the not-ported false on Jaguar1/2/3, Kestrel and the RTL8733B. On Realtek the MACID / BSSID registers and the ACK responder relate differently from the MT7612U's port identity, so the seam needs its own measured arm per family, with the same two halves of the bar (station_mode_ok): unicast addressed to the station received and acknowledged, and the station's own unicast acknowledged.
• A role-selected managed receive filter on the MT7612U. Mt7612uRadio::StartRxLoop installs the monitor filter unconditionally, so a station driven through IRadio runs promiscuous and never runs the managed filter 0x00015f97 the cells measured. "Moving the port identity makes a station deaf" is a managed-filter property; under the monitor filter it keeps receiving and stops acknowledging.
• The src/sta caller. Nothing in-tree calls SetStationIdentity yet. The station harness that associates through IRadio over the src/sta core (frames, supplicant, CCMP, DupDetector) is what exercises the arm-then-measure path the cells did not run, and is where the tx.retry_limit == 0 warning gets bench-checked.

Measurements

• The BSSID receive table on a second rig. The second unit (CF-922AC, 40:a5:ef:5f:65:51) reproduced staid, autoack, uplink and staack arm C, but the sta table stalled twice on an rtw88 AP (RTL8812BU on a SuperSpeed root port, failed to get tx report from firmware; injector at 100/s and 8/s of 300). The harness refused both, correctly. A non-rtw88 AP (vendor rtl88x2bu built for the rig kernel, or a non-Realtek AP) is needed to reproduce the table off the author's rig.
• The 6 fps txs gate loses one status entry per arm on the second unit. Every ~6 fps arm reads 199/200 (or 59/60) while the high-fps arms settle 200/200; the author's unit settles all of them. tests/mt7612u_sta_uplink.sh refuses any deficit on a claiming arm, so on that unit the uplink half of station_mode_ok's bar is INCONCLUSIVE 3 runs out of 4 with arm A at 199/200 acknowledged, 0.0 mean retries, against 0/158 at 16.0. Either find the lost entry in the status-FIFO drain (gate_txs, from radiotap: stream frames can request an ACK, and an MT7612U retry-limit knob #452) or give the claiming arm a bounded tolerance.
• Uplink mean retries differ between units: 0.0 on the author's, 1.9 on the second (cc48be4 run, 60/60). Stated in the doc, unexplained.
• The unexplained first-arm excess. Arm A of the BSSID table sits 4–7% above B–F in every run; with one run per arm it cannot be separated from drift, and a real few-percent BSSID-register effect would hide inside it.
• Unassociated cells only. Power save, TIM parsing, cross-BSS duplicate detection and hardware key lookup are untested on the MT7612U.

Harness

• tests/mt7612u_sta_identity.sh's rig requirement ("both adapters at high speed, no full-speed hub") is necessary, not sufficient: the rtw88 stall also happened on a SuperSpeed root port.

[snokvist]

A data point for the txs item: on the author's unit the uplink harness now loses more than one status entry per arm, and it does so on master.

tests/mt7612u_sta_uplink.sh at the defaults (FRAMES=60, ch6). DUT MT7612U at 1-1, peer RTL8812CU (0bda:c812), near field.

tree	arm A (peer answers)	arm B (control)	verdict
master dea68d4	UNSETTLED, entries 57/60, success 57, retries 0.0	acked 0/49, retries 16.0	INCONCLUSIVE
master + a local follow-up branch	UNSETTLED, entries 48/53, success 48, retries 0.0	acked 0/49, retries 16.0	INCONCLUSIVE

One run each. Every entry that arrived in arm A reads acknowledged at 0 retries, and arm B is cleanly 0%. So the uplink half looks intact, and what fails is only the entry count, by 3 and 5 here against the 1 recorded above for the second unit.

That changes how the item reads:

• The loss is not specific to the second unit.
• It is not a single off-by-one. A local change that claims an arm's first entry back from a stale EXT read lets the dedicated txs gate settle 16/16 arms at retry limits 5 and 0 on this unit. It does not close the uplink harness's gap, which is several entries per arm.
• The bounded tolerance on the claiming arm (entries >= sent - 1) would not be enough on this unit at these numbers.

The cause is not established. The local follow-up branch (the stale-EXT claim among a few small harness fixes) will come as a PR once #464 is in; this comment is so the multi-entry loss is on record either way.