For simplicity 160Mhz and 80+80Mhz were grouped together when
parsing the VHT capabilities, but the 80+80 bits were left in
vht_widht_map. This could cause an overflow when getting the
width map.
This adds support for parsing the VHT IE, which allows a BSS supporting
VHT (80211ac) to be ranked higher than a BSS supporting only HT/basic
rates. Now, with basic/HT/VHT parsing we can calculate the theoretical
maximum data rate for all three and rank the BSS based on that.
This adds HT IE parsing and data rate calculation for HT (80211n)
rates. Now, a BSS supporting HT rates will be ranked higher than
a basic rate BSS, assuming the RSSI is at an acceptable level.
The spec dictates RSSI thresholds for different modulation schemes, which
correlate to different data rates. Until now were were ranking a BSS with
only looking at its advertised data rate, which may not even be possible
if the RSSI does not meet the threshold.
Now, RSSI is taken into consideration and the data rate returned from
parsing (Ext) Supported Rates IE(s) will reflect that.
According to the specification, Supported rates IE is supposed
to have a maximum length of eight rate bytes. In the wild an
Access Point is found to add 12 bytes of data instead of placing
excess rate bytes in an Extended Rates IE.
BSS: len 480
BSSID 44:39:C4:XX:XX:XX
Probe Response: true
TSF: 0 (0x0000000000000000)
IEs: len 188
...
Supported rates:
1.0(B) 2.0(B) 5.5(B) 6.0(B) 9.0 11.0(B) 12.0(B) 18.0 Mbit/s
24.0(B) 36.0 48.0 54.0 Mbit/s
82 84 8b 8c 12 96 98 24 b0 48 60 6c .......$.H`l
DSSS parameter set: channel 3
03
...
Any following IEs decode nicely, thus it seems that we can relax
Supported Rates IE length handling to support this thermostat.
Since we use the special 0xffff value in the builder code, check that
the tag is not 0xffff in ie_tlv_builder_finalize before writing the
header. This is for consistency, not for a specific use case.
Make parsing TLVs using Extended Element IDs easier by returning the
extended tag value as listed in enum ie_type instead of just the 255
value, and not returning the pointer to the extended tag as the IE data
and instead the pointer to the next byte after the extended ID.
Parse the contents of the GTK and IGTK subelements in an FT IE instead
of working with buffers containing the whole subelement. Some more
validation of the subelement contents. Drop support for GTK / IGTK when
building the FTE (unused).
When parsing the EAPoL-Key key data field we don't strip the 0xdd /
0x00 padding from the decrypted data so there may be trailing padding
after the IE sequence and valgrind will report an invalid read of the
length byte. Same thing may happen if we're sent garbage.
Currently it supports Microsoft vendor specific information element
with version and type value 1 only. Typically it contains WPA security
related information.
==20758== Invalid read of size 1
==20758== at 0x401254: ie_tlv_iter_next (ie.c:55)
==20758== by 0x40104B: ie_test (test-ie.c:57)
==20758== by 0x4021C0: l_test_run (test.c:83)
==20758== by 0x4011B7: main (test-ie.c:123)
==20758== Address 0x51e10f3 is 0 bytes after a block of size 19 alloc'd
==20758== at 0x4C2C874: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20758== by 0x4010CF: append_data (test-ie.c:101)
==20758== by 0x40118F: main (test-ie.c:119)
==20758==
==20758== Invalid read of size 1
==20758== at 0x401266: ie_tlv_iter_next (ie.c:56)
==20758== by 0x40104B: ie_test (test-ie.c:57)
==20758== by 0x4021C0: l_test_run (test.c:83)
==20758== by 0x4011B7: main (test-ie.c:123)
==20758== Address 0x51e10f4 is 1 bytes after a block of size 19 alloc'd
==20758== at 0x4C2C874: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20758== by 0x4010CF: append_data (test-ie.c:101)
==20758== by 0x40118F: main (test-ie.c:119)
