If the scope has changed they should remove the planned features. But until then, it's perfectly logical to assume that something happened and the project is incomplete...
There also seem to be some open bug reports despite the low level of usage e.g. https://github.com/libwifi/libwifi/issues/24.
That would be a good start.
I know the common thinking is that “Fuchsia is dead” (it’s not check the repo it’s under heavy daily development) but it’s developing a new Rust based networking stack that’s really worth digging into [2] if that’s your idea of fun.
[1] https://chromium.googlesource.com/chromium/src/+/master/docs...
[2] https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/mai...
> int ret = libwifi_get_wifi_frame(&frame, data, data_len, got_radiotap);
> ...
> int ret = libwifi_parse_beacon(&bss, &frame);
I haven't looked into the implementation, but if I understand correctly, the above code (extracted from the example on the home page) implies that the unparsed segment of `data` is either (1) copied into `frame` or (2) a pointer-span in `frame` references the unparsed segment of `data`. I wonder why either of these approaches have been taken. I imagine that the pointer-span could be computed (possibly even statically) inside `libwifi_parse_beacon` and `data` could also be passed:
> libwifi_parse_beacon(&bss, &frame, data);
This would shrink the size of `frame` and achieve zero-copy. Or perhaps I'm missing something.