Clarification on MM8108 monitor mode, frame visibility, and MAC control capabilities

Software Linux
1

Hi,

We are currently setting up the MM8108 platform (EKH01) to form a network and would like to better understand the capabilities and limitations of monitor mode and MAC behaviour, for Linux-based deployments.

We would appreciate clarification on the following areas:

  1. RX path / visibility
  • In monitor mode (e.g., via morse0), are frames delivered:
    a) before or after MAC processing within the firmware?
    b) including control frames such as ACK / RTS / CTS, and frames with failed FCS?
  • Is radiotap-style metadata available (e.g., RSSI, rate, timestamps)?
  • Is there any API or mode that exposes lower-level receive timing information for data frames (beyond beacon-related timing)?
  1. TX path / frame handling
  • Is raw 802.11 frame injection supported from Linux (e.g., sending custom 802.11 headers or management frames)?
  • Is there any mechanism to control transmission timing beyond “send when ready” (e.g., relative timing control, scheduling hints, or alignment to internal clocks)?
  • Are there supported methods to influence or tune MAC behaviour, such as:
    • adjusting contention behaviour
    • modifying backoff characteristics
    • relaxing carrier-sense constraints
  1. MAC control / tuning
  • Which MAC parameters are publicly supported for tuning (e.g., AIFS, CWmin/CWmax, TXOP, CCA threshold)?
  • Are there any recommended configurations for applications that require tighter control over transmission behaviour?
  • Are there debug or engineering builds that expose:
    • more detailed RX metadata
    • additional timing information
    • extended MAC control interfaces
  1. Mesh / 802.11s
  • Is 802.11s mesh mode supported only via Linux (mac80211 / wpa_supplicant)?
  • Is there any support or roadmap for mesh-related functionality in MCU / standalone mode?

Our goal is to understand the extent of visibility and control available at the MAC/PHY boundary for the Linux based development, particularly for applications that are sensitive to timing and transmission behaviour.

Any guidance on supported capabilities, limitations, and recommended approaches would be greatly appreciated.

Thank you.

2

Hi @user44

  • 1:
  • a. Frames are delivered after MAC processing
    b. Yes
  • Radiotap metadata information is passed to Linux and comes over the netlink interface
  • No
  • 2:
  • We do not officially support 802.11frame injection
  • There is no mechanism to control transmission timing
  • The medium access parameters (AIFS, CWmin/CWmax, TXOP Limit) can be set on the AP for the AP and the STAs
  • 3:
  • IAIFS, CWmin/CWmax and TXOP are supported, CCA threshold is not
  • EDCAF is implemented in firmware and can’t be bypassed
  • There are no builds that expose any more control interfaces, metadata or timing information
  • 4:
  • Initial support for S1G relay in MCU mode is coming shortly.
  • There are no roadmap plans for 802.11s mesh support on MCU.
3

Hi @cmistry

Thanks for the earlier clarification on MAC capabilities.

We are currently running UDP traffic over 802.11s mesh (wlan0) on EKH01-MM8108. As we increase the traffic rate, we observe increasing packet loss and TX backpressure, suggesting the bottleneck may be at MAC/firmware medium access.

Could you help clarify the following:

  1. EDCA configuration in mesh mode
    Where should AIFS, CWmin/CWmax, and TXOP be configured when using mesh point mode (not AP/STA)?
    (e.g., UCI config, iw/nl80211, morse_cli, driver parameters, etc.)

  2. Access category mapping
    How are Linux packets mapped to EDCA access categories?
    Does SO_PRIORITY or IP_TOS influence the AC selection, and can we separate different traffic types into different ACs?

  3. Recommended settings
    Do you have recommended EDCA parameter settings for low-latency UDP traffic (small packets)?
    Also, does TXOP provide any benefit in this scenario?

  4. Broadcast vs unicast behavior
    Would switching from broadcast to unicast improve reliability due to MAC ACK/retry?

  5. Verification and application
    How can we verify the active EDCA parameters, and do changes require interface restart or can they be applied at runtime?

Thanks in advance for your guidance.