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
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
Add support for 4addr unicast packets
Add support for 4addr unicast packets packets that will be supported in
linux 3.5.
svn path=/trunk/; revision=41826
Read unchanged packets of v12 as v10 packets
Read unchanged packets of v13 as v11 packets
Use version in packet type definitions
svn path=/trunk/; revision=37142
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
"v10 of the packet format was added recently and could be added
to the wireshark dissector"
See: Bug #4833: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4833
From me:
- Fix a compile error: ...version=tvb_get_ntohs...
- Fix a missing = NULL.
svn path=/trunk/; revision=33066
The wireless meshing protocol B.A.T.M.A.N. Advanced changed their packet format
in such a way that now versions can be identified and so correct dissection of
the packets can be supported by wireshark.
Since it is a ever moving target it is very possible that the packet format is
changing slightly. The dissector was written in such a way that new version can
be supported relative easy.
I hope that it sufficient for the inclusion in wireshark.
I tried to fuzzing it some hours and no error was reported.
From me:
Initialize our dissector handles.
Merge packet-batadv.h into packet-batadv.c. It isn't included anywhere else.
Fuzz 500 passes using attached capture files.
svn path=/trunk/; revision=33052
Pascal Quantin