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
- Use/create extended value strings as appropriate;
- Reformat hf[] entries;
- Do whitespace, & etc changes to use a consistent formatting style;
- Reformat some long lines;
- Localize some variables; remove some unneeded initializers;
- expert...() shouldnt be called under 'if (tree)' (packet-wimaxasncp);
- Move proto_register...() & etc to the end of the file (packet-ieee80211);
- Misc.
svn path=/trunk/; revision=46489
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
- Update eap header file to include MS-CHAP v2 definitions.
- Convert EAP-MS-CHAP-V2 to use proto_tree_add_item() and make a few, hopefully final, changes.
Fixed a couple of typos etc.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7020
svn path=/trunk/; revision=41955
packet-eap.c: At top level:
packet-eap.c:150: error: static declaration of ‘eap_sim_subtype_vals’ follows non-static declaration
../../epan/eap.h:62: note: previous declaration of ‘eap_sim_subtype_vals’ was here
packet-eap.c:159: error: static declaration of ‘eap_aka_subtype_vals’ follows non-static declaration
../../epan/eap.h:72: note: previous declaration of ‘eap_aka_subtype_vals’ was here
packet-eap.c: In function ‘dissect_eap’:
packet-eap.c:668: warning: request for implicit conversion from ‘void *’ to ‘struct conv_state_t *’ not permitted in C++
packet-eap.c:673: warning: request for implicit conversion from ‘void *’ to ‘struct conv_state_t *’ not permitted in C++
packet-eap.c:866: warning: request for implicit conversion from ‘void *’ to ‘struct frame_state_t *’ not permitted in C++
packet-eap.c:927: warning: request for implicit conversion from ‘void *’ to ‘struct frame_state_t *’ not permitted in C++
packet-eap.c:1048: warning: request for implicit conversion from ‘void *’ to ‘struct frame_state_t *’ not permitted in C++
packet-eap.c:1067: warning: request for implicit conversion from ‘void *’ to ‘struct frame_state_t *’ not permitted in C++
svn path=/trunk/; revision=41924
Convert EAP-IDENTITY, EAP-NOTIFY and EAP-MD5 to use proto_tree_add_item().
From me consistently use "proto abbr"_"name".
svn path=/trunk/; revision=41918
First patch to start the conversion of the EAP dissector from its use of
proto_tree_add_text() to proto_tree_add_item().
svn path=/trunk/; revision=41913
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
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
directory to the epan directory. Some of them should perhaps ultimately
be moved to epan/dissectors, if they pertain only to stuff exported by a
particular dissector.
Fix Gerald's e-mail address in files we're moving.
svn path=/trunk/; revision=15844
Call "dissect_attribute_value_pairs()" regardless of whether we're
building a protocol tree, so the EAP subdissector is always called.
"dissect_attribute_value_pairs()" is only called when the length of AVPs
in the packet is non-zero; don't bother checking for a zero length.
Don't put two items in for each AVP - one is sufficient.
Add some more length checks when processing AVPs. Don't require AVPs to
be at least 3 bytes long - they might have just a type and length; let
an exception be thrown if that's a problem.
Don't require that the entire AVP be available in the tvbuff before
processing it; let an exception be thrown as we're processing the AVP if
we don't have all the data, so the stuff before the end is processed.
Give the tvbuff for the AVP data a length that reflects the length of
data left in the tvbuff, so that the appropriate exception is thrown if
the packet was cut short by a snapshot length.
Don't have a fixed-length buffer for reassembled EAP messages; grow it
as necessary.
Don't special-case the initial part of the processing of EAP messages;
put in the standard length item, as well as, for fragments, an item for
the fragment data.
Check for non-consecutive EAP-Message attributes.
Set the columns non-writable while dissecting the EAP message, so
Protocol and Info reflect the RADIUS packet.
Doing the reassembly by gluing together all the consecutive EAP-Message
attributes means we don't need help from the EAP dissector, returning
the total length of the EAP message. Get rid of the no-longer-needed
eap_fragment dissector; just call the regular EAP dissector.
svn path=/trunk/; revision=15046
