forked from osmocom/wireshark
Note that the low-order bit of hdr->hdr_2_x.xxx[8] appears to be a "bad
FCS" bit for 802.11, just as it appears to be for Ethernet, and give more details on the 4 bytes of junk at the end of the packet (i.e., that we haven't yet seen an 802.11 capture where it's an FCS rather than just junk). svn path=/trunk/; revision=13028
This commit is contained in:
parent
a649b53ed3
commit
c3240e1ccb
|
@ -865,8 +865,16 @@ netxray_set_pseudo_header(wtap *wth, const guint8 *pd, int len,
|
|||
* It appears, in one 802.11 capture, that
|
||||
* we have 4 bytes of junk at the ends of
|
||||
* frames in which hdr->hdr_2_x.xxx[2] and
|
||||
* hdr->hdr_2_x.xxx[3] are 0xff; we assume
|
||||
* for now that it works like Ethernet.
|
||||
* hdr->hdr_2_x.xxx[3] are 0xff; I haven't
|
||||
* seen any frames where it's an FCS, but,
|
||||
* for now, we still check the fcs_valid
|
||||
* flag - I also haven't seen any capture
|
||||
* where we'd set it based on the realtick
|
||||
* value.
|
||||
*
|
||||
* It also appears that if the low-order bit of
|
||||
* hdr->hdr_2_x.xxx[8] is set, the packet has a
|
||||
* bad FCS.
|
||||
*/
|
||||
if (hdr->hdr_2_x.xxx[2] == 0xff &&
|
||||
hdr->hdr_2_x.xxx[3] == 0xff) {
|
||||
|
|
Loading…
Reference in New Issue