item to look more-or-less like a PPP packet, just dissect it in place
and hand off to the appropriate subdissector using the PPP dissector's
handoff table (which we export, along with its value_string table for
protocol IDs, which we use to report the protocol ID symbolically).
This means there's no point in having a configurable option to control
whether to do that tweaking; make it an obsolete option.
Bring "col_get_writable()" back from the dead, and have the GTP
dissector save the current "writable" flag for columns, mark the columns
non-writable before calling the subdissector for the PPP configuration
protocol, and restore the state of the writable flag, rather than
putting the columns back after the PPP configuration protocol's
dissector is done.
Fix some more typos in comments.
Don't register the IP dissector in the "ppp.protocol" table in the GTP
dissector's handoff registration routine - it's already being done in
the IP dissector's handoff routine.
Fix the name for CHAP to match what RFC 1994 calls it (if the name
changed, it should be changed in all places, but, at least according to
this message, a while ago, from Bob Sutterfield, "since the RFC defines
the protocol, the RFC defines the name":
http://mail-index.netbsd.org/netbsd-help/1996/05/16/0011.html
and the RFC defines the name as "PPP Challenge Handshake Authentication
Protocol (CHAP)").
svn path=/trunk/; revision=6617
structure to the "packet_info" structure; only stuff that's permanently
stored with each frame should be in the "frame_data" structure, and the
"column_info" structure is not guaranteed to hold the column values for
that frame at all times - it was only in the "frame_data" structure so
that it could be passed to dissectors, and, as all dissectors are now
passed a pointer to a "packet_info" structure, it could just as well be
put in the "packet_info" structure.
That saves memory, by shrinking the "frame_data" structure (there's one
of those per frame), and also lets us clean up the code a bit.
svn path=/trunk/; revision=4370
access their own "pinfo". A packet_info is stored in epan_dissect_t,
which is created for the dissection of a single packet.
GUI functions which need to access the packet_info of the currently
selected packet used to use "pi"; now they use cfile.edt->pi. cfile's
"edt" member is the epan_dissect_t of the currently-selected packet.
The functionality of blank_packetinfo() was moved into
dissect_packet(), as that's the only place that called blank_packetinfo(),
after a spurious call to blank_packetinfo() was removed from
packet_list_select_cb().
svn path=/trunk/; revision=4246
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114