libwifi - An 802.11 (WiFi) Frame Generation and Parsing Library in C

	Commit message (Collapse)	Author	Age	Files	Lines
*	core/gen: Fix warnings flagged by new compiler options	Marc	2023-01-15	2	-1/+5
\|
*	Merge branch 'main' into 6ghz	Marc	2022-10-16	1	-0/+5
\|\
\| *	gen: Fix boundary alignment in Radiotap header	Jeff	2022-10-02	1	-0/+5
\| \|
* \|	parse: Add clarifying comment for Beacon frame length check	Marc	2022-09-10	1	-0/+1
\| \|
* \|	core/parse: Add skeleton for element extension parsing	Marc	2022-09-10	2	-0/+18
\| \|
* \|	core/parse: Better handling of Radiotap information	Marc	2022-09-10	4	-3/+36
\|/ \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Radiotap information is now stored in the `libwifi_frame` struct, and will be kept automatically in `libwifi_frame.radiotap_info` for the lifecycle of said frame, if it is present. A new flag has been added for the frame for use with `libwifi_frame.flags` to detect if the radiotap info is present: `LIBWIFI_FLAGS_RADIOTAP_PRESENT`. The frame parser will now automatically calculate the band and center channel from radiotap data, and will store them in `libwifi_radiotap_info.channel.center` and `libwifi_radiotap_info.channel.band`. Four new flags have been added for use with the new radiotap band field: - `LIBWIFI_RADIOTAP_BAND_2GHZ` - `LIBWIFI_RADIOTAP_BAND_5GHZ` - `LIBWIFI_RADIOTAP_BAND_6GHZ` - `LIBWIFI_RADIOTAP_BAND_900MHZ` These can be used with a binary AND: `if (rtap.channel.band & LIBWIFI_RADIOTAP_BAND_6GHZ) { }`
*	Add macOS support (#8)	Marc	2022-08-20	3	-4/+39
\| \| \|	Add macOS build support
*	parse: Update references to libwifi_cipher_suite struct	Marc	2022-08-10	1	-6/+6
\|
*	parse: Check for WEP presence before removing it from bitfield	Marc	2022-08-10	1	-2/+6
\|
*	parse: Remove useless reassignment of suite_type	Marc	2022-08-10	1	-4/+0
\|
*	core: Avoid double frame copy in radiotap handling	Marc	2022-03-07	1	-18/+7
\| \| \| \|	Thanks @dragorn !
*	core: Ensure radiotap parser errors are handled	Marc	2022-03-07	1	-1/+4
\|
*	core: Return error if invalid length is supplied to tag_iterator_init()	Marc	2022-03-04	1	-1/+4
\|
*	gen: Style fixups for #5	Marc	2022-01-29	2	-5/+6
\|
*	core: Use version set in CMakeLists, inside code. Bump version to 0.0.3	Marc	2022-01-28	1	-1/+3
\|
*	gen: Improve header comments, add ability to set Address 3 field for all ↵	Marc	2022-01-28	26	-181/+388
\| \| \| \|	management frames
*	gen: Add ability to set different BSSID than Transmitter for Beacons	Marc	2022-01-15	2	-4/+14
\|
*	core: Fix `libwifi_frame_verify()` and clarify usage.	Marc	2022-01-13	2	-3/+12
\|
*	parse: Check frame minimum length when parsing Radiotap header	Marc	2022-01-12	3	-4/+14
\|
*	core: Add LIBWIFI_FLAGS_IS_ORDERED flag to frame	Marc	2022-01-11	2	-0/+2
\|
*	core: Add Element Extension tag recognition	Marc	2022-01-09	2	-1/+4
\|
*	core: Add a function to get the tag name via tag number.	Marc	2022-01-09	2	-0/+351
\| \| \| \| \|	Not very pretty, but it's also not so bad. Alternative is a huge array or a super ugly macro hack.
*	gen/parse: Remove stdio.h includes	Marc	2022-01-09	6	-6/+0
\|
*	core: Add a function to check if a tag is present by tag number	Marc	2022-01-09	2	-0/+25
\|
*	core: Fix tag_iterator failure on empty tags.	Marc	2022-01-09	1	-4/+0
\| \| \| \| \| \| \| \| \| \| \|	This code used to be `< 0`, but was changed to `<= 0` in commit d40ddfe. Thinking more about this, it's a bad idea to abort on 0 length tags, since it's completely valid for some tags (such as SSID) to be empty. It doesn't make sense to check if `tag_len` is below 0, because it's unsigned. So, remove the check completely.
*	test: Add ctests for generation functions.	Marc	2021-12-17	18	-56/+138
\| \| \| \| \|	This commit also enforces error code checking on functions inside of the generation functions, such as for `libwifi_quick_add_tag`.
*	build: Unset hard dependency on clang in CMake	Marc	2021-12-07	1	-2/+2
\| \| \| \|	This commit also corrects a small warning for gcc.
*	Initial Commit	Marc	2021-12-01	101	-0/+8734
	Signed-off-by: Marc <foxtrot@malloc.me>