First of all, this library is designed to be easily extendable.
There's an architectural/contribution guide in docs/Frame.md
and pull requests are highly welcome.
Covering the whole spectrum of possible 802.11 frames or all different implementations of wifi tools out there is an impossible task for a single person, let's try to tackle this together!
Large parts of this library have been upstreamed from @Ragnt's AngryOxide.
The goal of libwifi
is to provide a convenient way of parsing raw IEEE 802.11 frames!
The emphasis is on convenient, since the focus is to providing an easy-to-use API, instead of squeezing the last bit of performance out of it.
This includes consistent and intuitive structs that represent the structure of a given frame.
However, this library is still very fast.
The project is still under heavy development, and a quite a few features are missing, but it should be a good foundation for a proper IEE 802.11 library :).
I'm no longer actively using this library myself, so it relies on external contributions.
Writing documentation and tests are a huge way to start contributing to it and are very appreciated!
Parsing a frame is fairly straight forward:
use libwifi::parse_frame;
// A simple RTS frame
let bytes = [
180, 0, // FrameControl
158, 0, // Duration
116, 66, 127, 77, 29, 45, // First Address
20, 125, 218, 170, 84, 81, // Second Address
];
match libwifi::parse_frame(&bytes) {
Ok(frame) => {
println!("Got frame: {frame:?}");
}
Err(err) => {
println!("Error during parsing :\n{err:?}");
}
};
A full example on how to capture, process and parse wifi traffic can be found in the examples
directory.
There are a few benchmarks in the benches
folder, which can be run by calling cargo bench
.
Right now, parsing a Beacon
frame, which is one of the more complex frames, takes ~300ns
on a AMD Ryzen 7 7840HS
.
Parsing a Data
frame takes ~28 ns
.
If we take this as a rough guideline, you can roughly expect 3-35 million frames per second per core on that CPU, depending on frame type.
- Implement basic parsers for all frame subtypes.
- Add specialized parsers for fields that are currently generically handled by the
StationInfo
struct. - Handle all edge-cases (there are a lot and I'll need help!)
I would love to add proper interface handling to the library. This includes features to:
- Switch modes
- Switch channels
- Discover available channels
- Management Frames
- AssociationRequest,
- AssociationResponse,
- ReassociationRequest,
- ReassociationResponse,
- Deauthentication,
- ProbeRequest,
- ProbeResponse,
- TimingAdvertisement,
- Beacon,
- Atim,
- Disassociation,
- Authentication,
- Action,
- ActionNoAck,
- Control Frames
- Trigger,
- Tack,
- BeamformingReportPoll,
- NdpAnnouncement,
- ControlFrameExtension,
- ControlWrapper,
- BlockAckRequest,
- BlockAck,
- PsPoll,
- Rts,
- Cts,
- Ack,
- CfEnd,
- CfEndCfAck,
- Data Frames
- Data,
- DataCfAck,
- DataCfPoll,
- DataCfAckCfPoll,
- NullData,
- CfAck,
- CfPoll,
- CfAckCfPoll,
- QosData,
- QosDataCfAck,
- QosDataCfPoll,
- QosDataCfAckCfPoll,
- QosNull,
- QosCfPoll,
- QosCfAckCfPoll,
- Frame Components
- Frame Control
- Sequence Control
- Management Header
- Dynamic Management Header fields
- SSID
- Supported rates
- Generic extraction of remaining fields
- Data Header
- QoS Data Header
There's a lot more to the IEE 802.11 spec and a lot of stuff needs to be done.
If you find that something you need is missing, consider creating a ticket and contributing :).