Provide a way for Lua-based dissectors to invoke tcp_dissect_pdus()
to make TCP-based dissection easier.
Bug: 9851
Change-Id: I91630ebf1f1fc1964118b6750cc34238e18a8ad3
Reviewed-on: https://code.wireshark.org/review/6778
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Hadriel Kaplan <hadrielk@yahoo.com>
Specifically:
- Set packet.h to be the first wireshark #include after
config.h and "system" #includes.
packet.h added as an #include in some cases when missing.
- Remove some #includes included (directly/indirectly) in
packet.h. E.g., glib.h.
(Done only for those files including packet.h).
- As needed, move "system" #includes to be after config.h and
before wireshark #includes.
- Rework various #include file specifications for consistency.
- Misc.
Change-Id: Ifaa1a14b50b69fbad38ea4838a49dfe595c54c95
Reviewed-on: https://code.wireshark.org/review/5923
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Bill Meier <wmeier@newsguy.com>
(for some dissectors which fetch all other integral fields using
ENC_BIG_ENDIAN).
Change-Id: Ic18e3172aad76af12b12d6732c88497be22aed56
Reviewed-on: https://code.wireshark.org/review/5748
Reviewed-by: Bill Meier <wmeier@newsguy.com>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
The LLRP Standard 1.0.1 defines the ProtocolID Parameter as 8 bit value (see
LLRP Standard 1.0.1 document, page 138, AccessSpecParameter) but Wireshark
treats it as 16 bit value and therefore doesn't recognize the
EPCGlobalClass1Gen2 protocol type and marks the whole packet afterwards as
invalid.
svn path=/trunk/; revision=49991
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
Manually expand some of the macros in packet-llrp.c that were only being used
in one place. Makes for a more traditional set of hf_ registrations.
svn path=/trunk/; revision=44817
function in the switch statement. This keeps us from calling through an
uninitialized pointer for custome parameter numbers other than
LLRP_VENDOR_IMPINJ (as warned of by at least some compilers).
svn path=/trunk/; revision=44624
Given the problems with the original attempt, and the fact that there's a new
version of the protocol spec out (v1.1), I took a crack at writing a new
dissector from scratch. It doesn't decode the fields within the message
parameters (there are far too many to bother with for an initial draft), but it
decodes everything else.
Even though it's not complete, I feel it's worth checking in as an intermediate
step (assuming it passes review), since it's still far better than nothing, and
adding full parameter-field decoding is going to take a lot of time simply for
transcribing all the different fields.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1957
svn path=/trunk/; revision=42383
Hadriel Kaplan