aboutsummaryrefslogtreecommitdiffstats
path: root/wiretap
diff options
context:
space:
mode:
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>2002-04-08 02:11:24 +0000
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>2002-04-08 02:11:24 +0000
commitf1cf1d4350b862f83da363355c7de3b93ceb31a7 (patch)
treec1e66a48744a87690b4e5aedc3ee9bbb12eabf8a /wiretap
parent9fbbf9561b129201e4963018554e3ce0d6a86029 (diff)
Yes, that stuff really *does* appear to be just padding. Go figure.
git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@5119 f5534014-38df-0310-8fa8-9805f1628bb7
Diffstat (limited to 'wiretap')
-rw-r--r--wiretap/netxray.c23
1 files changed, 6 insertions, 17 deletions
diff --git a/wiretap/netxray.c b/wiretap/netxray.c
index 1e3f047279..ea7894dca5 100644
--- a/wiretap/netxray.c
+++ b/wiretap/netxray.c
@@ -1,6 +1,6 @@
/* netxray.c
*
- * $Id: netxray.c,v 1.50 2002/04/07 21:44:55 guy Exp $
+ * $Id: netxray.c,v 1.51 2002/04/08 02:11:24 guy Exp $
*
* Wiretap Library
* Copyright (c) 1998 by Gilbert Ramirez <gram@alumni.rice.edu>
@@ -219,13 +219,12 @@ int netxray_open(wtap *wth, int *err)
/*
* End-of-packet padding. 802.11 captures appear to have four
- * bytes of it; is this the FCS, rather than padding? I think
- * we've seen padding at the end of some Ethernet captures; is
- * that an FCS as well?
+ * bytes of it.
*
- * Gerald indicates that the padding has values that don't look
- * as if they're FCS values, so perhaps it's just padding
- * junk.
+ * We've seen what appears to be an FCS at the end of some frames
+ * in some Ethernet captures, but this stuff appears to be just
+ * padding - Sniffers don't show it, and it doesn't have values
+ * that look like FCS values.
*/
wth->capture.netxray->padding = 0;
if (netxray_encap[hdr.network] == WTAP_ENCAP_IEEE_802_11) {
@@ -335,16 +334,6 @@ reread:
/*
* We subtract the padding from the packet size, so our caller
* doesn't see it.
- *
- * However, if it turns out the padding is really the FCS, we'd
- * probably want to supply it, along with an indication of whether
- * the frame has an FCS or not, so that Ethereal and Tethereal
- * could display it.
- *
- * That may also mean that if incl_len is shorter than orig_len
- * by less than 4 bytes, we shouldn't just subtract the length
- * of the padding from it, as the snapshot length would have
- * cut it off.
*/
wth->phdr.caplen = packet_size - wth->capture.netxray->padding;
wth->phdr.len = pletohs(&hdr.hdr_1_x.orig_len) - wth->capture.netxray->padding;