This is wrong it breaks all sort of things. The "Volume label field"
is a special case, which can be fixed by using nopad=TRUE.
Change-Id: I3cd3f30ff0076d5e31a735391b175fd68e5fa142
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-on: https://code.wireshark.org/review/26
Reviewed-by: Evan Huus <eapache@gmail.com>
Tested-by: Evan Huus <eapache@gmail.com>
Also added some minor text to README.wslua for developers.
Change-Id: I50b36f06710da6920ad98be6dde27d6091d91d54
Reviewed-on: https://code.wireshark.org/review/50
Reviewed-by: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Stig Bjørlykke <stig@bjorlykke.org>
* Update to the last IANA icmpv6-parameters (2014-01-30)
* Update to final draft (for RFC 6743 and RFC 6775)
* Add RFC 7112 (Implications of Oversized IPv6 Header Chains) support (Add new Parameter Problem code)
* Fix a encoding arg
Change-Id: I90f65dfc54e5c0aff21a0e7ec2c937304aced02d
Reviewed-on: https://code.wireshark.org/review/62
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
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
Stefan Metzmacher