ruvnet/RuView · warning

ENOTSUP

ENOTSUP

Error message

veil: [blob-blocked] MU-MIMO group shuffle needs a vendor subcmd / firmware patch (TODO(hw))

What it means

Byte-identical vendored copy of the MU-MIMO stub. On every NEW_STATION/DEL_STATION nl80211 event the daemon calls `veil_shuffle_mumimo_groups`, which is an explicit no-op: on mt76/ath the MU groups and steering matrices live inside WiFi MCU firmware with no upstream vendor subcmd to reach them. It logs `[blob-blocked] ... TODO(hw)` on stderr and returns `-ENOTSUP` rather than pretending success.

Source

Thrown at wifi-veil/firmware/openwrt/veil_shieldd.c:171

    fprintf(stderr, "veil: [feasible/indirect] next sounding jitter = %u ms "
                    "(TODO(hw): apply via hostapd ctrl_iface)\n", ms);
    return 0;
}

/* ---------------------------------------------------------------------- */
/* CONTROL 3 (MOSTLY BLOB-BLOCKED): MU-MIMO group shuffling.               */
/* The MU group definition + steering matrices are computed and applied in */
/* the WiFi MCU firmware on mt76 (mt7915) and all ath1x parts. There is no */
/* generic nl80211 command to reshuffle MU groups. Only a vendor subcmd    */
/* (NL80211_CMD_VENDOR) on a driver that chose to expose one could do it.  */
/* ---------------------------------------------------------------------- */
static int veil_shuffle_mumimo_groups(struct veil_ctx *c) {
    (void)c;
    /* TODO(hw): requires NL80211_CMD_VENDOR + a driver-specific
     * NL80211_ATTR_VENDOR_ID / _SUBCMD / _DATA that does not exist upstream
     * for mt76/ath. Without a driver+firmware patch this is unreachable.
     * See INTEGRATION.md §3. Left as an explicit no-op, not a fake success. */
    fprintf(stderr, "veil: [blob-blocked] MU-MIMO group shuffle needs a "
                    "vendor subcmd / firmware patch (TODO(hw))\n");
    return -ENOTSUP;
}

/* ---------------------------------------------------------------------- */
/* CONTROL 4 (BLOB-BLOCKED on commodity AP silicon): the keyed rotation.   */
/* This is the actual VEIL transform — a keyed Givens rotation on the fine */
/* subspace of the compressed beamforming feedback (the phi/psi angles),   */
/* or equivalently a unitary Q on the LTF spatial mapping. On mt76/ath the */
/* feedback report is generated and the precoder applied inside firmware,  */
/* so userspace cannot edit it. This function shows WHERE the core plugs   */
/* in for the platforms that CAN reach the buffer (openwifi FPGA datapath, */
/* Nexmon Broadcom patch) — it operates on a caller-supplied fine block.   */
/* ---------------------------------------------------------------------- */
static int veil_apply_keyed_rotation(struct veil_ctx *c,
                                     float *fine, size_t n) {
    if (!fine || n < 2) return -EINVAL;
    /* Pure, orthogonal, energy-preserving (the "not jamming" invariant). */

View on GitHub (pinned to 4685618388)

Solutions

  1. Accept it as an informational limitation; the daemon continues and the return value is ignored by design.
  2. Exclude `blob-blocked` lines from alerting/log collection.
  3. If the capability is required, plan the vendor-subcmd/firmware work described in INTEGRATION.md §3 — no userspace workaround exists.

Example fix

# before: alert on any veil: line
logread -f | grep 'veil:'
# after: ignore the documented stub notice
logread -f | grep 'veil:' | grep -v 'blob-blocked'
Defensive patterns

Strategy: fallback

Try / catch

int rc = veil_shuffle_mumimo_groups(c);
if (rc == -ENOTSUP) {
    /* expected: firmware-blocked on mt76/ath; skip silently or rate-limit logging */
}

Prevention

When it happens

Trigger: Any station join/leave on the monitored AP while the daemon is running — expected during normal operation; the message recurs per event.

Common situations: Log triage mistaking the recurring notice for an error; alert rules matching `veil:` prefix paging on it.

Related errors


AI-assisted analysis of ruvnet/RuView@4685618388 (2026-08-16). Data as JSON: /api/errors/c5554428feb5d2eb. Report an issue: GitHub.