The OP asked 9169 to be reopened because the capture was spewing ~40GB of output
when dissected with tshark. Investigation showed this was because the HTTP
dissector was requesting ONE_MORE_PACKET reassembly a lot, and TCP was adding
each step as a data-source which was being printed by tshark's hex dump. This
was leading to O(n^2) of output.
To fix, introduce function remove_last_data_source which removes the most recent
data source from the list. If the subdissector in TCP reassembly asks for
ONE_MORE_PACKET, assume it hasn't added any tree items (since it shouldn't have)
and remove the data source since it is unnecessary.
This may break dissectors which add tree items and *then* return
ONE_MORE_PACKET, since they will have their data source removed out from under
them. I believe those cases should be fixed to not add tree items until they're
sure they have enough data.
Change-Id: Iff07f959b8b8bd1acda9bff03f7c8684901ba8aa
Reviewed-on: https://code.wireshark.org/review/38
Reviewed-by: Evan Huus <eapache@gmail.com>
Tested-by: Evan Huus <eapache@gmail.com>
- SNMT messages where presented in a way, where the value of the
field was not pointing to the correct bytes where it came from
- Sender / Receiver where renamed to be better understandable
- SN send to (Receiver) now comes first as it does in the byte
stream
Change-Id: I364cb248bed9489c0cf9c7bf9fbd37b0225dbd78
Load system init.lua from build-directory/epan/wslua
Set Lua datafile_path to source-directory/epan/wslua
Made dofile() search in source-directory/epan/wslua
Change-Id: I009234eb8193c1ed3260455b245c256c9747930f
Changeset 1d8a895fa4 introduced the use of UTF-8 righ arrow to indicate the direction in TCP dissector.
While it displays nicely in Wireshark GUI or in a text export of packets, an export to CSV results in an escaped string.
This patch is a naive attempt to display the right arrow in a more friendly way when exporting to CSV.
Any smarter fix is welcome.
Change-Id: Ife787268696fa69dafc24a5cf9706af4c4832831
This function can be used to check for files before calling dofile(),
which will fail for non-existing files.
Change-Id: Iae7b7ef6d8eb6e0e18f98fee7c740d2a5705eef3
(Found by checkhf).
Note: There's quite a large amount of hf[] entries which are
commented out. I wonder if there are "top-level" entries
missing from the "parse-tree" arrays ?
svn path=/trunk/; revision=54990
to add missing BASE_RANGE_STRING and to use RVALS instead of VALS.
Fixes crashes in 'tshark -G values' and presumably also fixes
crashes when used in a dissection.
Introduced in SVN #54449.
(I suspect that ' convert_proto_tree_add_text.pl' may need some work
to handle range_strings).
svn path=/trunk/; revision=54984
an hf[] entry but defined as a 'value_string' intead of
as a 'val64_string'.
Caused 'tshark -G values' to crash
(and presumably would also cause a crash when the value-string
is referenced in a dissection):
Introduced in svn #54728
(Note: There's still another 'tshark -G values' crash to to found & fixed)
svn path=/trunk/; revision=54983
restore usage in cms and pkcs12. They never got a valid value in
actx->external.direct_reference because they use another actx in this case.
This will add back the global variable in x509af, but this is needed
until we manage to pass the value in another way.
See comments in bug 9573.
svn path=/trunk/; revision=54975
Alexis La Goutte