On Sat, Jun 15, 2002 at 01:59:06PM -0700, Guy Harris wrote:
> If you create a new data source, it will show up in Ethereal as a
> notebook page in the hex dump pane, and will show up in "tethereal -x"
> output and in the output of "print to file" if "Print hex data" is
> selected.
The updated patch I posted on Friday does it this way. (I wasn't aware
of that mechanism originally..)
> Neither do FDDI nor Token Ring nor Ethernet II; nevertheless, libpcap
> *does* supply both a packet length and a captured length....
Okay, I see where you're coming from here; more on this later.
> Whether the underlying capture mechanism supplies the FCS to libpcap, or
> whether the non-native capture file we're reading (e.g., an AiroPeek or
> Wireless Sniffer capture file, in the case of 802.11) includes the FCS
> as part of the packet data, is another matter.
And generally speaking, it won't.
> 1) the 802.11 dissector common code ("dissect_ieee80211_common()")
> needs to have an argument telling it whether the frame has an
> FCS or not and, if that argument says it doesn't, not treat
> the stuff at the end of the frame as an FCS
Right now, that argument comes in the form of a preference. Either the
FCS is present, or it is not present. It won't vary on a per-packet basis
in the middle of a capture. Assuming that we have a sane snarflen, that
is.. but if not, the packet data will be truncated anyway, rendering the
FCS argument a little moot in the grander scheme of htings.
> 2) "dissect_ieee80211_radio()" should, for now, pass to
> "dissect_ieee80211_common()" a value of "does not contain
> FCS", although that may change in the future - if so, we'll
> need some mechanism by which the Wiretap code can pass an
> indication of whether there's an FCS or not to
> Ethereal/Tethereal.
The more I think about this, the more I like it. The existing "radio"
header was arbitrarily defined for the original monitor code on the prism
driver, and the wlan-ng stuff will be changing this format drastically in
the future (with new encapsulations and whatnot, don't worry). And the
FCS will _always_ be present in those cases.
> Those two lengths in the libpcap header come from the lengths that
> libpcap supplies, which come from the underlying packet capture
> mechanism, as stated above.
I was assuming the opposite; tvb_length() would always be equal to or
greater than reported_length(). Because in the dissectors, I was always
seeing the reported length being shortened as a way of informing
sub-dissectors of the data they should care about.
I was ignoring the case of us deliberately truncating the packets via the
snarflen.
Okay, this is what I plan to do in the short run:
* Leave the "Assume FCS is present" toggle in the 802.11 dissector, but
have it default to off.
* Mangle the dissect_ieee80211_common() and friends to have the FCS
toggle as an argument, like you proposed.
* Assume FCS is missing if the captured length is too short. Ditto for
the WEP ICV.
* Alter the wlan-ng driver to make the FCS optional, defaulting to off.
(while the prism chipsets do not pass this down, I know for a fact that
future chipsets will, and in fact, may actually need to...)
Longer run:
* Create another encapsulation, DLT_IEEE80211_FCS and quite possibly
DLT_IEEE80211_NEWRADIO (or something like that..)
The DLT_IEEE80211 encapsulation should not include the FCS, as that's the
established "standard" now. Generally speaking, the FCS is useless to
userspace code anyway, as most chipsets don't even pass packets down if
the FCS is invalid, and those that can are usually told not to.
I'll have the third revision of the patch sometime later today.
- Pizza
--
Solomon Peachy solomon@xxxxxxxxxxxxxx
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
Attachment:
pgp937DT_gpav.pgp
Description: PGP signature
