https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5952
--- Comment #6 from Colin O'Flynn <coflynn@xxxxxxxxx> 2011-05-25 12:48:03 PDT ---
>"Perhaps there should be a
>filter expression that, for a given protocol layer in a packet, gives the
>length of the data initially handed to that protocol layer."
I agree, in general this would be useful. Unfortunately I don't know how to do
this generically/automatically, without requiring adding code such as I did to
each dissector.
To have this special filter field report a length modified based on the
presence/absence of an FCS, I think would require the addition of specialized
code to each dissector anyway. Otherwise it would be difficult to generically
deal with knowing about the FCS length and if it is present or not.
I think it is more useful to always include the FCS in the length calculation
(i.e. inflating the length by 2 if the FCS is absent). Most PDU definitions
seem to include the FCS. For example an 802.15.4 MAC-PDU includes the FCS.
If I modified the code to always report the same length with/without FCS, would
that be acceptable? What would you suggest as a generic name for this field?
What about .cap_len, as this already exists as frame.cap_len ? If this is
confusing (since it isn't exactly the capture length) what about .pdu_len ?
Note, some additional background about where I am coming from:
For 802.15.4 specifically I think it is a bigger problem than other MACs,
because there are many ways the data gets to the 802.15.4 layer in Wireshark.
The problem came about when I was using tshark to dump a bunch of fields, and
do some more advanced IO graphing. In my case I could use the zep.length field,
but this isn't a good 'generic' solution. If someone runs the same script and
they used another method to capture the 802.15.4 data, it won't work.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
