libwifi: an 802.11 frame parsing and generation library written in C

evilmonkey19 7 hours ago | parent | next [-]

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...

	▲	zamadatix 6 hours ago \| parent \| next [-]
		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.
	▲	karlgkk 2 hours ago \| parent \| prev [-]
		I would point to a few standards on there which have open bugs around following the standard. That would be a good start.

▲

RossBencina 7 hours ago | parent | prev | next [-]

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.

▲

throw1168b23 4 hours ago | parent | prev [-]

802.11 IPV4 libraries in glibc shows LC_TIME=C=UTF-8 in /etc/profile and locale.config