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
Correct a logic error which filtered out the Python-related library symbols
when Python is enabled.
Actually expose some Python-related symbols (which get filtered out if it's
not enabled).
svn path=/trunk/; revision=44803
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
Since we have to 'downconvert' the ERF time stamps to Wireshark's internal
representation anyway, we may as well report the resolution which we convert
to, rather than the original native resolution.
svn path=/trunk/; revision=44800
The GTK+ and native Win32 versions are slightly different. The GTK+
version lets you select an output file type and the Win32 version uses
the existing capture filetype. We do the latter for now.
Start documenting significant UI changes in README.qt. This might be
better handled on the wiki.
svn path=/trunk/; revision=44797
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
