class WireSyncClientImpl

Gets general information about the device and its supported features.

This method is safe to call even when the SoftMAC has not yet started.

Note: The implementation of this method must not depend on a response

from an ethernet driver, otherwise there is a risk of deadlock.

The wlansoftmac driver calls this method synchronously while

serving the fuchsia.hardware.ethernet/EthernetImpl.Query method.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Gets information about the station discovery (e.g., scanning and

probing) features supported by the device. This method is safe to call

even when the SoftMAC has not yet started.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Gets information about the MAC features supported by the device. This

method is safe to call even when the SoftMAC has not yet started.

Note: The implementation of this method must not depend on a response

from an ethernet driver, otherwise there is a risk of deadlock.

The wlansoftmac driver calls this method synchronously while

serving the fuchsia.hardware.ethernet/EthernetImpl.Query method.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Gets information about the security features supported by the device.

This method is safe to call even when the SoftMAC has not yet started.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Gets information about the spectrum usage (e.g., DFS) features supported

by the device. This method is safe to call even when the SoftMAC has not

yet started.

Allocates 16 bytes of request buffer on the stack. Response is heap-allocated.

Set the primary radio channel, e.g. in response to a channel switch event.

If successful, this will trigger the channel switch immediately. This may

impact the transmission of any frames that are in-flight, and might also

interfere with an ongoing scan request.

Common errors include:

\

/// ZX_ERR_NOT_SUPPORTED: The device cannot switch to the requested channel.

Allocates 88 bytes of message buffer on the stack. No heap allocation necessary.

Join a specific BSS in which we will participate.

This applies regardless of if we are hosting the BSS or joining it

(indicated by the `remote` flag in `JoinBssRequest`).

If successful, the device will switch to the correct channel and perform

any internal filtering/timing operations required to join the BSS.

For client STAs, this is the first step before authenticating.

Common errors include:

\

/// ZX_ERR_NOT_SUPPORTED: The device does not support the given bss config.

Allocates 104 bytes of message buffer on the stack. No heap allocation necessary.

Enables hardware Beaconing.

This method cannot be called while beaconing is enabled and so

`DisableBeaconing` must be called prior to this method if beaconing is

enabled.

All request fields are required.

Common errors include:

- `ZX_ERR_NOT_SUPPORTED`: The device does not support hardware beacons.

- `ZX_ERR_INVALID_ARGS`: The device cannot transmit the requested

beacon.

- `ZX_ERR_BAD_STATE`: The device is already beaconing.

Allocates 32 bytes of response buffer on the stack. Request is heap-allocated.

Disables hardware beaconing.

Allocates 48 bytes of message buffer on the stack. No heap allocation necessary.

Install a key for encryption when transmitting or receiving protected

frames.

Common errors include:

ZX_ERR_INVALID_ARGS: The given config does not specify a valid key.

ZX_ERR_NOT_SUPPORTED: The device does not support the given cipher.

Allocates 192 bytes of message buffer on the stack. No heap allocation necessary.

Notifies the device of a successful association and configures

additional parameters necessary to participate in that association.

# Errors

Common errors include:

- `ZX_ERR_BAD_STATE`: The device was not previously informed of this BSS

via `WlanSoftmac.JoinBss`.

Allocates 32 bytes of response buffer on the stack. Request is heap-allocated.

Notifies MAC and PHY that the peer has been de-associated.

Allocates 80 bytes of message buffer on the stack. No heap allocation necessary.

Starts a passive scan. The server will deliver scan results

as Beacon frames using WlanSoftmacIfc.Recv(). When complete,

the server will call WlanSoftmacIfc.ScanComplete() with the

same `scan_id` returned by StartPassiveScan().

The server indicates support for `StartPassiveScan()` using

`fuchsia.wlan.common/ScanOffloadExtension.supported`.

Common errors include:

ZX_ERR_INVALID_ARGS: The device is not capable of performing the

requested scan, e.g. because an incompatible channel was requested.

ZX_ERR_UNAVAILABLE: The device cannot currently perform scans.

ZX_ERR_SHOULD_WAIT: Another scan is already in-progress.

Allocates 360 bytes of request buffer on the stack. Response is heap-allocated.

Starts an active scan. The server will deliver scan results

as Beacon or Probe Response frames using WlanSoftmacIfc.Recv().

When complete, the server will call WlanSoftmacIfc.ScanComplete()

with the same `scan_id` returned by StartActiveScan().

A device driver indicates support for `StartActiveScan()` using

`fuchsia.wlan.common/ProbeRequestOffloadExtension.supported`.

Common errors include:

ZX_ERR_INVALID_ARGS: The device is not capable of performing the

requested scan, e.g. because an incompatible channel was requested.

ZX_ERR_UNAVAILABLE: The device cannot currently perform scans.

ZX_ERR_SHOULD_WAIT: Another scan is already in-progress.

Request is heap-allocated. Response is heap-allocated.

Cancels the ongoing scan corresponding to `scan_id`,

where `scan_id` is an identifier returned by

`StartPassiveScan()` or `StartActiveScan()`. If cancellation succeeds,

the server will soon call WlanSoftmacIfc.ScanComplete() with the same

`scan_id`.

A device driver indicates support for `CancelScan()` using

`fuchsia.wlan.common/ScanOffloadExtension.scan_cancel_supported`.

Common errors include:

- `ZX_ERR_NOT_FOUND`: `scan_id` does not match an ongoing scan.

- `ZX_ERR_NOT_SUPPORTED`: Server does not support scan cancellation.

Allocates 80 bytes of message buffer on the stack. No heap allocation necessary.

Indicate the device of modified WiFi Multimedia (WMM) parameters for a

particular access category (AC).

Allocates 120 bytes of message buffer on the stack. No heap allocation necessary.

Signal to the server that the MLME for the iface is ready to send and receive

frames.

The client provides the following arguments:

- `ifc_bridge`: The client end of a `WlanSoftmacIfcBridge` server which the

`wlansoftmac` driver will use to forward `WlanSoftmacIfc` events to

the bridged driver.

- `ethernet_tx`: A `ethernet_tx_t*` casted to a `uint64`. The

`ethernet_tx_t` is defined in

`//src/connectivity/wlan/drivers/wlansoftmac/rust_driver/c-binding/bindings.h`.

- `wlan_rx`: A `wlan_rx_t*` casted to a `uint64`. The

`wlan_rx_t` is defined in

`//src/connectivity/wlan/drivers/wlansoftmac/rust_driver/c-binding/bindings.h`.

The server must copy the contents of `ethernet_tx_t` and `wlan_rx_t` before

returning from this method. The lifetimes of `ethernet_tx_t*` and `wlan_rx_t*` are only as

long as this method call, but the contents of `ethernet_tx_t` and `wlan_rx_t` will

live until the server stops the MLME.

The server returns a server end of a `fuchsia.wlan.mlme/MLME` protocol. The SME

for the iface owns the client end. Thus, this channel is used for SME

<

-> MLME

communication.

The `WlanSoftmacBridge.Start` method is different from `WlanSoftmac.Start`

for two reasons. First, Rust bindings do not exist for Driver transported

protocols, so `WlanSoftmacIfcBridge` protocol must be Zircon transported to be

usable by the bridged driver. Second, the Zircon transport adds

significant latency compared to the Driver transport. As a result, the

`ethernet_tx` and `wlan_rx` arguments provide an FFI for the wlansoftmac driver

to send Ethernet and receive WLAN packets to the bridged driver with

latency comparable or better than a Driver transported protocol.

Except where noted, `WlanSoftmacBridge` methods must only be called after

a successful call to `WlanSoftmacBridge.Start`.

Common errors include:

- `ZX_ERR_ALREADY_BOUND`: `Start` was already called on this softmac.

Allocates 72 bytes of message buffer on the stack. No heap allocation necessary.

Forwards a status containing `ETHERNET_STATUS_*` flags to the

`fuchsia.hardware.ethernet/EthernetImplIfc` proxy owned by

the C++ portion of wlansoftmac.

As documented, the value of `status` is set by bits defined in

`ETHERNET_STATUS_*` flags. However, there is only one flag named

`ETHERNET_STATUS_ONLINE` and no specification of for the meaning

of specifying no flags. In practice, `0x1` means the status is up,

and `0x0` means the status is down.

While this method should belong in something like an

"`EthernetImplIfcBridge` protocol", it's included in the

`WlanSoftmacBridge` protocol as a convenience. The wlansoftmac driver

will eventually cease using a `fuchsia.hardware.ethernet/EthernetImplIfc`

proxy and use a `fuchsia.hardware.network.driver/NetworkDeviceIfc`

proxy instead. At that time, an equivalent of this method should be

refactored into a separate bridge.

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.