| commit | ffeae031458107caa65e8f7da053986effbe3749 | |
| author | rofl0r <retnyg@gmx.net> | |
| Thu, 15 Feb 2018 18:00:58 +0000 (15 18:00 +0000) | ||
| committer | rofl0r <retnyg@gmx.net> | |
| Thu, 15 Feb 2018 18:09:08 +0000 (15 18:09 +0000) | ||
| tree | 08ec82cd3b44ed30372bc0ccad0b6f3cc34ffcf2 | treesnapshot (tar.gz zip) |
| parent | 72f4eb2dcf4686ae909528eec1802df82c5506e0 | commitdiff |
handle frame checksum padded to end of packet
using a ATH9K_HTC device which added the FCS, the process_tags code
got confused since it interpreted the checksum following as additional
tag data. now if the driver signals that FCS is appended, we just shrink
the packet len so the checksum is ignored.
for optimal conditions, we should probably deal with the bad checksum
bit AND deal with the case that the checksum doesn't match the packet
contents (needs CRC32 comparison). the relevant code is in reaver's
check_fcs() in 80211.c.
using a ATH9K_HTC device which added the FCS, the process_tags code
got confused since it interpreted the checksum following as additional
tag data. now if the driver signals that FCS is appended, we just shrink
the packet len so the checksum is ignored.
for optimal conditions, we should probably deal with the bad checksum
bit AND deal with the case that the checksum doesn't match the packet
contents (needs CRC32 comparison). the relevant code is in reaver's
check_fcs() in 80211.c.
| macgeiger.c | diffblobblamehistory |