> With an 802.11 device, does turning DLPI_NATIVE on put the device into
> monitor mode, or does it just cause it to supply 802.11 headers?
It just causes it to supply 802.11 headers. We may later add support to
monitor.
> Is there a way to query whether a device supports DLPI_NATIVE
> ("supports" in the sense that it gives different link-layer headers
> depending on whether it's set or not)?
The ioctl libdlpi uses (see below) will fail if native mode is not
supported on that link. But in general, we expect monitoring apps will
just always request native mode and will want to continue on if the
underlying driver doesn't support it.
> Is there a raw DLPI (without libdlpi) equivalent to DLPI_NATIVE in pre-
> Solaris 11 releases?
Support for native only exists in Solaris 11, but there is a DLPI
equivalent, covered in dlpi(7P):
Native Mode
Some DLPI providers may be able to represent their link
layer using more than one link-layer format. In this
case, the default link-layer format may minimize impact
to applications, but may not allow truly "native" link-
layer headers to be sent or received. DLPI consumers who
wish to use the native link-layer format can use DLIOC-
NATIVE to transition the stream. DLIOCNATIVE takes no
arguments and returns the DLPI mac type associated with
the new link-layer format upon success. Once
enabled, the stream remains in this mode until closed.
Note that DLIOCNATIVE does not enable transition
between dissimilar DLPI mac types and (aside from the
link-layer format), the new DLPI mac type is
guaranteed to be semantically identical. In particular,
the SAP space and addressing format are not affected and
the effect of DLIOCNATIVE is only visible when in raw
mode, though any subsequent DL_INFO_REQ requests gen-
erate responses with dl_mac_type set to the native DLPI
type.
> And, speaking of monitor mode, is there a way to put an 802.11 adapter
> into monitor mode, and is there a way to set the channel it uses?
AFAIK, there's no way to do that at this time -- most of the control
messages never make it beyond the net80211 kernel module. It's
probably worth verifying my understanding via the laptop-discuss
alias though, as that is monitored by the WiFi team.
--
meem
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
