Manually expand some of the macros in packet-llrp.c that were only being used
in one place. Makes for a more traditional set of hf_ registrations.
svn path=/trunk/; revision=44817
add -no-cpp-precomp; I think the way the compiler handled precompiled
headers changed at some point. Let's stop adding it; that would fix bug
5878.
svn path=/trunk/; revision=44816
registration tables, and use g_free as the value_destroy_func. This saves us
from manually freeing the value when we remove an item, and prevents us from
leaking memory when we accidentally overwrite an existing item.
svn path=/trunk/; revision=44814
We *do*, however, use CFPropertyListCreateWithStream(), so we need to
check for it, and, if we're able to use the OS X frameworks at all, use
CFPropertyListCreateFromStream() if we don't have
CFPropertyListCreateWithStream().
svn path=/trunk/; revision=44812
fail on Mountain Lion with the default -W flags, but no replacement API
was specified. Fall back on dredging information out of
/System/Library/CoreServices/SystemVersion.plist; this also lets us get
the OS build version.
(In theory, we could calculate the OS version from the Darwin version
for everything except 10.0:
12.x.x OS X 10.8.x Mountain Lion
11.x.x OS X 10.7.x Lion
10.x.x OS X 10.6.x Snow Leopard
9.x.x OS X 10.5.x Leopard
8.x.x OS X 10.4.x Tiger
7.x.x OS X 10.3.x Panther
6.x.x OS X 10.2.x Jaguar
5.x OS X 10.1.x Puma
and could get the build number as "kern.osversion" from sysctl.)
svn path=/trunk/; revision=44811
IANA assignments for 6LoWPAN-ND
draft-ietf-6lowpan-nd-21 has entered the RFC editor's queue, and has been
officially assigned values for the ICMPv6 message and option type codes ( as
seen at http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml
)
This patch replaces the old placeholder values for the 6LoWPAN-ND types with
the official IANA assignments.
svn path=/trunk/; revision=44808
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
Bill Meier