4 ms·

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

151 points by vitalnodo 11mo ago

evilmonkey19 11mo ago
Perhaps a stupid question, but the last release and commit is from 2023. Did something happen to the project?
- Lammy 11mo ago
  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/page/series?id=68#xpl-accordion-1763252155159-2 https://ieeexplore.ieee.org/browse/standards/get-program/pag...
  - zamadatix 11mo ago
    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/ 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 https://github.com/libwifi/libwifi/issues/24.
  - karlgkk 11mo ago
    I would point to a few standards on there which have open bugs around following the standard. That would be a good start.
- m00x 11mo ago
  Likely complete to the point that the author needed it to be.
- taminka 11mo ago
  that's just called having a complete project in a stable language lol, not everything needs a change every week to function well...
  - tredre3 11mo ago
    The project isn't complete by their own admission: https://libwifi.so/features/ 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...
RossBencina 11mo ago
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.
deleted 11mo ago
[deleted]
deleted 11mo ago
[deleted]
throw1168b23 11mo ago
802.11 IPV4 libraries in glibc shows LC_TIME=C=UTF-8 in /etc/profile and locale.config
fooblaster 11mo ago
what's this for?
- beardyw 11mo ago
  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.
mdhb 11mo ago
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/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs... [2] https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/main/src/connectivity/network/netstack3 https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/mai...
deleted 11mo ago
[deleted]
nxobject 11mo ago
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!
ericpauley 11mo ago
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.

151 points by vitalnodo 11mo ago

evilmonkey19 11mo ago

Perhaps a stupid question, but the last release and commit is from 2023. Did something happen to the project?

Lammy 11mo ago
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/page/series?id=68#xpl-accordion-1763252155159-2 https://ieeexplore.ieee.org/browse/standards/get-program/pag...
- zamadatix 11mo ago
  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/ 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 https://github.com/libwifi/libwifi/issues/24.
- karlgkk 11mo ago
  I would point to a few standards on there which have open bugs around following the standard. That would be a good start.
m00x 11mo ago
Likely complete to the point that the author needed it to be.
taminka 11mo ago
that's just called having a complete project in a stable language lol, not everything needs a change every week to function well...
- tredre3 11mo ago
  The project isn't complete by their own admission: https://libwifi.so/features/ 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...

RossBencina 11mo ago

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.

deleted 11mo ago

[deleted]

deleted 11mo ago

[deleted]

throw1168b23 11mo ago

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

fooblaster 11mo ago

what's this for?

beardyw 11mo ago
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.

mdhb 11mo ago

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/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs... [2] https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/main/src/connectivity/network/netstack3 https://fuchsia.googlesource.com/fuchsia/+log/refs/heads/mai...

deleted 11mo ago

[deleted]

nxobject 11mo ago

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!

ericpauley 11mo ago

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.