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).
> 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.
Perhaps a stupid question, but the last release and commit is from 2023. Did something happen to the project?
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.
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.
802.11 IPV4 libraries in glibc shows LC_TIME=C=UTF-8 in /etc/profile and locale.config