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
|
* It appears, in one 802.11 capture, that
|
||||||
* we have 4 bytes of junk at the ends of
|
* we have 4 bytes of junk at the ends of
|
||||||
* frames in which hdr->hdr_2_x.xxx[2] and
|
* frames in which hdr->hdr_2_x.xxx[2] and
|
||||||
* hdr->hdr_2_x.xxx[3] are 0xff; we assume
|
* hdr->hdr_2_x.xxx[3] are 0xff; I haven't
|
||||||
* for now that it works like Ethernet.
|
* 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 &&
|
if (hdr->hdr_2_x.xxx[2] == 0xff &&
|
||||||
hdr->hdr_2_x.xxx[3] == 0xff) {
|
hdr->hdr_2_x.xxx[3] == 0xff) {
|
||||||
|
|
Loading…
Reference in New Issue