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:
Guy Harris 2005-01-14 09:47:22 +00:00
parent a649b53ed3
commit c3240e1ccb
1 changed files with 10 additions and 2 deletions

View File

@ -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) {