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...
Before listing a bunch of specifics about newer changes I'm guessing you don't actually care about, some of the basic things at https://libwifi.so/features/ would be good to complete first before the newer stuff since the last update was 2023, not the last completed feature level (Wi-Fi is enormous).
Google’s Rule of Two [1] jumped out to me the moment I saw this combined with what seems to be a group of semi-anonymous authors on GitHub and this project while cool and a huge amount of work is also a bit of a yikes I think.
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.
> 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.
File extension reference notwithstanding, what an awful choice of vanity domain name. Depending on where you look .so isn’t even allowed to be used by non-Somali affiliates, and there are horror stories online of arbitrary non-renewals.
If you need to process individual WiFi frames, of which there are many formats, each one structured with a lot of ifs and buts to only send what is necessary.
Perhaps a stupid question, but the last release and commit is from 2023. Did something happen to the project?
Likely complete to the point that the author needed it to be.
that's just called having a complete project in a stable language lol, not everything needs a change every week to function well...
The project isn't complete by their own admission: https://libwifi.so/features/
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...
Please point to which 802.11 standard has changed since 2023 that you would like to see supported: https://ieeexplore.ieee.org/browse/standards/get-program/pag...
Before listing a bunch of specifics about newer changes I'm guessing you don't actually care about, some of the basic things at https://libwifi.so/features/ would be good to complete first before the newer stuff since the last update was 2023, not the last completed feature level (Wi-Fi is enormous).
There also seem to be some open bug reports despite the low level of usage e.g. https://github.com/libwifi/libwifi/issues/24.
I would point to a few standards on there which have open bugs around following the standard.
That would be a good start.
I see “parsing” and I think: I’ve always wanted to try out SOTA fuzzers - I guess I have a project with what’s left of the weekend!
Google’s Rule of Two [1] jumped out to me the moment I saw this combined with what seems to be a group of semi-anonymous authors on GitHub and this project while cool and a huge amount of work is also a bit of a yikes I think.
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...
Nice.
> 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.
File extension reference notwithstanding, what an awful choice of vanity domain name. Depending on where you look .so isn’t even allowed to be used by non-Somali affiliates, and there are horror stories online of arbitrary non-renewals.
what's this for?
If you need to process individual WiFi frames, of which there are many formats, each one structured with a lot of ifs and buts to only send what is necessary.
802.11 IPV4 libraries in glibc shows LC_TIME=C=UTF-8 in /etc/profile and locale.config