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
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
- Fix various bugs.
- Add some optional debug.
- Enable checking of the Calling address.
- Check that the Called/Calling address has at least a minimum number of
octets.
- Handle XUDTS.
- Reject messages whose mandatory variable pointers are 0 (meaning not
present).
- Reject Class-2 messages whose Class-spare bits are non-zero.
- For (Class-2) messages that have no variable parameters but an optional
pointer, only accept messages whose optional pointer is 0 (no optional
parameters) or 1 (optional parameter immediately follows the pointer).
- (For some of those Class-2 messages) if there are no optional parameters,
reject messages if we didn't reach the end of the message.
svn path=/trunk/; revision=40819
they're signed, but that's only to handle "offset from the end" - we
should probably get rid of that and make them unsigned.)
svn path=/trunk/; revision=40785
- Handle ERR and IT messages.
- When checking variable parameter lengths, check that we have enough data
remaining (by adding the current offset to the retrieved length).
- Check the lengths of several more messages.
- When checking the length, add up the values of the parameter length macros
to make it obvious how we came to use that value.
svn path=/trunk/; revision=40784
- Reject all Class-3 messages (it's never used)
- Group Class-2 and Class-1 messages closer together
- Some code cleanup (use macros where we have them)
svn path=/trunk/; revision=40780
Part of "display filters with redundancies of PROTABBREV in them."
The ones left outs should be fixed differently I think.
Rename som ndps hf variables while at it.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2794
svn path=/trunk/; revision=37406
- routing on SSN but the SSN is not present or is unspecified (zero)
- message handling has an unexpected value
- message class is incorrect for the message type
Also clean up some indentation and other white space.
svn path=/trunk/; revision=37400
if the preference is set.
Add %d to the "not found" string in val_to_str() calls.
Upgrade the "ITU address format seen in ANSI" expert info from NOTE to WARN.
svn path=/trunk/; revision=37218
digits.
Since we now have a subtree from which to hang things, make the generic (called
or calling) digits fields visible under this new subtree (one less hidden item).
Don't use add_string_format() to add the GT digits, let epan format it for us.
Use more descriptive field descriptions for these entries.
svn path=/trunk/; revision=37214
and without causing us to potentially run into bug 3834.
Add a couple hf entries for things that had been added with add_text().
svn path=/trunk/; revision=36946
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
The information which is used to determine which sub-dissector to use for the
various Data messages within an SCCP connection is only present within the
initial Connection Request, so even with connection tracking on, unless the
trace contains the Connection Request no sub-dissector is called. It is common
for traces to only contain a single carried protocol anyway - e.g. RANAP.
The supplied patch adds a user preference for a "default payload"
sub-dissector, which is called in preference to the Data dissector if nothing
else has claimed the packet first.
svn path=/trunk/; revision=35098
The packet-sccp.c has a bug in the declared valid ranges of the SSN and DPC
values in the user table used to match to a subdissector. The SSN range is 16
bits rather than 8 (not really an issue) but the DPC range is 16 bits rather
than 24 - so many traces cannot be matched by this table.
svn path=/trunk/; revision=35097
called GTs (if RI=GT) put in the (pinfo) source and destination (and thus into
the source and destination columns).
This may help (if the PCs change but the GT does not) or hurt (if the GT or RI
change but the PCs do not) TCAP's ability to identify which messages belong to
which TCAP "session."
svn path=/trunk/; revision=33097
Jeff Morriss