From Hauke Mehrtens
1. dtls: set ssl_set_server() in DTLS dissector so wireshark knows if this is client or server
2. SSL: add decrypt support for CCM and CCM_8 Ciphers per rfc 6655
3. dtls: add psk decrypt support
svn path=/trunk/; revision=53836
Break out Signature Hash Algorithm into hash and signature values
From me:
Cleanup all "saved" trees throughout the dissector as well as removing a few unnecessary NULL tree checks.
Removed most of the tvb_ensure_bytes_exist checks because the line that follows will through an exception anyway if there isn't enough bytes in the tvb.
svn path=/trunk/; revision=51574
DTLS 1.2 adds a supported_signature_algorithms attribute to the CertificateRequest which was not parsed in DTLS.
This code was copied from the ssl code.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8781
svn path=/trunk/; revision=49878
[PATCH 1/8]
Add a subtree for the random DTLS elements. This is what TLS already does, and
it makes more sense than prefixing their display names.
[PATCH 2/8]
Show the actual hex content of the cookie by just using proto_tree_add_item.
The cookie length has its own field, so there's no need to display it twice.
[From me]
Fix an @ in the AUTHORS file
svn path=/trunk/; revision=49172
trying to handle reassembly of packets with *differing* handshake length
values a bit better.
Make coding style a little more consistent.
svn path=/trunk/; revision=48916
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
fields that were captured show up even if the packet was cut short by a
snapshot length. Advance the offset variable as we do so.
Be a little clearer in some comments.
svn path=/trunk/; revision=48537
be done on flows from one address to another; reassembly for protocols
running atop TCP should be done on flows from one TCP endpoint to
another.
We do this by:
adding "reassembly table" as a data structure;
associating hash tables for both in-progress reassemblies and
completed reassemblies with that data structure (currently, not
all reassemblies use the latter; they might keep completed
reassemblies in the first table);
having functions to create and destroy keys in that table;
offering standard routines for doing address-based and
address-and-port-based flow processing, so that dissectors not
needing their own specialized flow processing can just use them.
This fixes some mis-reassemblies of NIS YPSERV YPALL responses (where
the second YPALL response is processed as if it were a continuation of
a previous response between different endpoints, even though said
response is already reassembled), and also allows the DCE RPC-specific
stuff to be moved out of epan/reassembly.c into the DCE RPC dissector.
svn path=/trunk/; revision=48491
call fragment_add() before fragment_set_tot_len()
(the latter has no effect if no fragments are present, so we don't set
the total length correctly when it's in the first fragment)
svn path=/trunk/; revision=47000
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
Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
implicitly by the #define name and string they were defined to; not all
UATs neatly fit into any of the categories, so some of them were put
into categories that weren't obviously correct for them, and one - the
display filter macro UAT - wasn't put into any category at all (which
caused crashes when editing them, as the GUI code that handled UAT
changes from a dialog assumed the category field was non-null).
The category was, in practice, used only to decide, in the
aforementioned GUI code, whether the packet summary pane needed to be
updated or not. It also offered no option of "don't update the packet
summary pane *and* don't redissect anything", which is what would be
appropriate for the display filter macro UAT.
Replace the category with a set of fields indicating what the UAT
affects; we currently offer "dissection", which applies to most UATs
(any UAT in libwireshark presumably affects dissection at a minimum) and
"the set of named fields that exist". Changing any UAT that affects
dissection requires a redissection; changing any UAT that affects the
set of named fields that exist requires a redissection *and* rebuilding
the packet summary pane.
Perhaps we also need "filtering", so that if you change a display filter
macro, we re-filter, in case the display is currently filtered with a
display filter that uses a macro that changed.
svn path=/trunk/; revision=43603
File name preferences are basically just string preferences except that the
GUI will present a "Browse" button that allows the user to go and find the
file s/he wants (rather than having to blindly type in the full path).
svn path=/trunk/; revision=43228
