Interface based on header type rather than MCS.
passes in the header type for EGPRS packets.
This makes sense because in a real protocol stack, the header type is encoded
in the burst stealing bits, allowing the header can be decoded, giving the CPS
IE, which then allows the data blocks to be decoded, so wireshark now follows
the same practice.
I found that there was a (previously overlooked) alignment error in decoding
the last octet of some headers due to the last "octet" having less than 8 bits,
and both the protocol stacks I have here assume that the left-hand bits are
missing (as per the figures in 44.060). I corrected this by making a small
extension to the NULL encoding in packet-csn.[ch] to allow a NULL field to
consume more than 0 bits.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7615
svn path=/trunk/; revision=44805
The reassembled fragments tree in the Packet Details view is awesome, but it
lacks one thing: a field that exposes the reassembled data.
tcp.data already exists for exposing a single TCP segment's payload as a byte
array. It would be handy to have something similar for a single application
layer PDU when TCP segment reassembly is involved. I propose
tcp.reassembled.data, named and placed after the already existing field
tcp.reassembled.length.
My primary use case for this feature is outputting tcp.reassembled.data with
tshark for further processing with a script.
The attached patch implements this very feature. Because the reassembled
fragment tree code is general purpose, i.e. not specific to just TCP, any
dissector that relies upon it can add a similar field very cheaply. In that
vein I've also implemented ip.reassembled.data and ipv6.reassembled.data, which
expose reassembled fragment data as a single byte stream for IPv4 and IPv6,
respectively. All other protocols that use the reassembly code have been left
alone, other than inserting NULL into their initializer lists for the newly
introduced struct field reassemble.h:fragment_items.hf_reassembled_data.
svn path=/trunk/; revision=44802
Fix CID 703472 and (external) fuzz failure 7567:
The dissect_subtlv_interface_parameters is missing the handling of BFD 2..4.
For the crash patch, we decided to add the bfd2..4 in dissect_tlc function(in
the diff). We plan to open a separate bug to fix
dissect_subtlv_interface_parameters to make it handle BFD2..4. (Thanks to Arun
Arunachalam for this analysis)
From me: fix up some indentation and replace tabs with spaces (for consistency).
svn path=/trunk/; revision=44801
TKIP dissection : wrong IS_TKIP macro
In [1] "11.4.2.2 TKIP MPDU formats", we could see below sentence.
"WEPSeed[1] is not used to construct the TSC, but is set to (TSC1 | 0x20) &
0x7f."
But the IS_TKIP macro only checks (WEPSeed[1] & 0x20).
So sometimes IS_TKIP macro mis-dissects a CCMP frame as a TKIP frame.
This patch changes IS_TKIP macro to do more better check.
[1] IEEE Std 802.11.-2012
#BACKPORT(1.8, 1.6)
svn path=/trunk/; revision=44790
control field. This means processing the AX.25 header data in one pass.
The field after the control field is the "protocol identifier" field,
not the "packet identifier" field.
svn path=/trunk/; revision=44772
Change one tvb_get_bits8 to tvb_get_bits16 since the queried length is
9 bits long (should this be added to checkAPI somehow?)
svn path=/trunk/; revision=44742
length check "heuristics" for FF dissector (UDP + TCP)
"Fix" WTP+WSP packets incorrectly dissected as Foundation FieldBus packets https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4822
As it fails with
cc1: warnings being treated as errors
packet-ff.c: In function 'dissect_ff_tcp':
packet-ff.c:13061: warning: passing argument 7 of 'tcp_dissect_pdus' from incompatible pointer type
svn path=/trunk/; revision=44724
Anders Broman