Removed the line
tvb_ensure_bytes_exist(tvb, offset, 44);
from again.
This is not correct, because the frame might have been captured before the
os added the padding bytes. E.g. in Windows the frames are captured on the
protocol layer. When another protocol driver sends a frame this frame does
not include the padding bytes.
Also the dataLength variable in case of bMox==TRUE was not calculated
correctly.
svn path=/trunk/; revision=25738
and "hdlc" doesn't indicate that it's a protocol type), and, instead of
a "raw" option, have a "try to guess the traffic type" option - for now,
if the first byte is 0x0f or 0x8f, treat it as Cisco HDLC, otherwise
treat it as PPP.
svn path=/trunk/; revision=25737
"aal5_type" dissector, which offers only "guess the traffic type" and
"LLC multiplexed" as options, defaulting to "guess the type".
Add a separate preference to control whether to treat single ATM cells
as raw data or as the first cell of an AAL5 PDU (and dissecting them as
short AAL5 PDUs).
Don't reach inside the tvbuff to get the data and the length; use
tvb_length() and tvb_get_ptr().
Pass the data *after* the AAL5 header to the "guess the traffic type"
routine.
svn path=/trunk/; revision=25736
warnings (such as the warning you get when you say
"prefs_register_boolean_preference" rather than
"prefs_register_bool_preference") show up as errors.
svn path=/trunk/; revision=25735
ERF files can contain records of type TYPE_PAD. These records are not related
to captured packets, have a zero timestamp value and no associated packet data.
Normally TYPE_PAD records are stripped out during capture, but in rare cases
unstripped files may exist.
Previously wiretap/erf.c generated an 'unknown record encapsulation' error when
encountering TYPE_PAD records.
With this patch Wireshark skips over any TYPE_PAD records within ERF traces
files without reporting an error. TYPE_PAD records are not counted, displayed
or decoded.
svn path=/trunk/; revision=25733
it's not the "Bridge Control Protocol", and the packets aren't "BPDU"s
in the sense of Spanning Tree Protocol packets.
svn path=/trunk/; revision=25732
the payload we hand to the next dissector.
Check whether the length field in an 802.3 header doesn't go past the
(presumed) end of the payload.
svn path=/trunk/; revision=25731
Attached is a patch for:
- PW Associated Channel Header dissection as per RFC 4385
- PW MPLS Control Word dissection as per RFC 4385
- mpls subdissector table indexed by label value
- enhanced "what's past last mpls label?" heuristic
- Ethernet PW (w/o CW) support as per RFC 4448
svn path=/trunk/; revision=25730
to the "no FCS" dissector if the "FCS present" flag isn't set. Strip
off padding. Don't hand non-Ethernet packets to the Ethernet dissector.
Update the RFC number for the PPP Multilink protocol. Add a preference
for short sequence numbers. Check only the "first fragment" and "last
fragment" flags when constructing the summary description for the flags
field. Use the global "tfs_yes_no" true_false_string structure rather
than defining our own "Yes"/"No" true_false_string structure.
svn path=/trunk/; revision=25729
The attached patches bring the wireshark code up to date with the latest
NFSv4.1 protocol drafts (in ietf last call now, so hopefully not too much more
of this will be required).
They also cover more of the protocol, and do some minor cleanup (e.g. remove
some operations which were really only used by one prototype implementation,
and never part of the protocol.)
A few ops and attributes are still missing.
svn path=/trunk/; revision=25727
indicates; replace the "erf.eth" preference with an "erf.ethfcs"
preference, specifying whether the FCS is present in Ethernet frames,
and offer the options "present", "not present", and "maybe present" -
for "maybe present", call the regular Ethernet dissector, which tries to
figure out whether there's an FCS at the end of the packet or not.
svn path=/trunk/; revision=25719
The ULMAP decoder can get a wrong bit offset when decoding CQICH_Alloc_IE.
The finishing position shoud not pad to byte but pad to the length specified,
which can be nibble aligned.
svn path=/trunk/; revision=25703
Currently, sFlow dissector only recongnizes "Header" as the packet data type.
This patch enhances it to support "IPv4" and "IPv6" packet data type.
This patch seems to work well against sFlow packets exported from AlaxalA switch.
svn path=/trunk/; revision=25688
I'm pretty sure that it won't be used uninitialised, and that the code could be more clearly arranged to make this obvious to the compiler too.
svn path=/trunk/; revision=25685
Guy Harris