Started by grepping call_dissector_with_data, call_dissector_only and call_dissector and traced the handles passed into them to a find_dissector within the dissector. Then replaced find_dissector with find_dissector_add_dependency and added the protocol id from the dissector.
"data" dissector was not considered to be a dependency.
Change-Id: I15d0d77301306587ef8e7af5876e74231816890d
Reviewed-on: https://code.wireshark.org/review/14509
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
That removes most of the uses of the frame number field in the
frame_data structure.
Change-Id: Ie22e4533e87f8360d7c0a61ca6ffb796cc233f22
Reviewed-on: https://code.wireshark.org/review/13509
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add fields for the absolute time stamp (and another field for a presence
flag for the absolute time stamp) and the packet encapsulation for the
packet.
This lets us remove the field for the packet encapsulation in the
frame_data structure; do so.
Change-Id: Ifb910a9a192414e2a53086f3f7b97f39ed36aa39
Reviewed-on: https://code.wireshark.org/review/13499
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(If the magic number isn't something we recognize, we don't treat the
file as a pcap file, so it can never be "unknown".)
Change-Id: I7e8bac1ebd2cbfd6d603035428274a1098ff7544
Reviewed-on: https://code.wireshark.org/review/13491
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Just treat it as an array of bytes. When checking for whether it's a
pcap file, also determine whether it's big-endian or little-endian.
Note that reading it in *host* byte order will tell you whether it's in
your byte order or byte-swapped; you have to know your byte order to
know whether that means little-endian or big-endian.
Have a #define for the magic number size, as all magic number values
must be that size, and use that as the size of the magic-number arrays.
Handle nanosecond timestamp resolution while we're at it.
Change-Id: I4d83579d919ae9f15888afca14317631d413ca51
Reviewed-on: https://code.wireshark.org/review/13490
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: Ie39ef054a4a942687bd079f3a4d8c2cc55d5f22c
Reviewed-on: https://code.wireshark.org/review/12485
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Put that dissector into its own file, and get handles for it from the
pcap and pcapng file dissectors. Put the value_string of pcap/pcapng
LINKTYPE_ values there, and have the pcap and pcapng file dissectors
import it.
Expand that table to include all LINKTYPE_ values in the current
libpcap.
Change-Id: I9397035efa5711e8a18a26e056d3b54494fd3148
Reviewed-on: https://code.wireshark.org/review/12000
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Assign numbers for LinkTypes on webpage
http://www.tcpdump.org/linktypes.html were changed, so update
it for file dissector for PCAP/PCAPNG.
Change-Id: Icb52c2a8f19bd056723de155700b83497d5fded4
Reviewed-on: https://code.wireshark.org/review/11983
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Otherwise dissection will fail when analyzing a capture with a snap length set
Change-Id: I764f48c624d0cc411b04ee62f8ecccaf6abb6f0c
Reviewed-on: https://code.wireshark.org/review/10134
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Found compiling with gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04).
Change-Id: I21bd3a5ab3365f0065c919aba7d6bd00b878d041
Reviewed-on: https://code.wireshark.org/review/10105
Petri-Dish: Hadriel Kaplan <hadrielk@yahoo.com>
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
They have educational values and can be used to debugging some issues.
Now Wireshark can open three files (BTSNOOP, PCAP, PCAPNG)
in two modes: Capture (Traditional) and File-Format.
Change-Id: I833b2464d11864f170923dc989a1925d3d217943
Reviewed-on: https://code.wireshark.org/review/10089
Reviewed-by: Anders Broman <a.broman58@gmail.com>
