Wireshark-bugs: [Wireshark-bugs] [Bug 9607] TFShark (Terminal FileShark)
Date: Tue, 31 Dec 2013 15:17:29 +0000

Comment # 7 on bug 9607 from
(In reply to comment #6)
> Trying to take the current patch farther, I tried to remove the dissector
> source from "libepan" and link it with fileshark, but I'm not having much
> luck (doing it quickly/easily).  Some of the issues have been outlined in
> http://www.wireshark.org/lists/wireshark-dev/201312/msg00288.html.  Taking a
> different approach of just trying to get the "minimum epan functionality" to
> link with fileshark, there are still "dissector dependencies" in epan_init
> (wslua needs register_frame_end_routine in packet-frame.c for starters)
> 
> Any suggestions on direction to take "libepan" to make this work?  Move
> wslua_init (or anything else with dissector dependencies) outside of
> epan_init (and probably epan_cleanup)?  Replace current calls to epan_init
> with dissector_epan_init that wraps "common" epan_init with dissector
> specific epan modules (for everything but fileshark)?

Thoughts on a couple of the linking problems:

- mtp3_pc_to_str_buf is not used outside of packet-mtp3.c that I can see. Just
make it static-local to that file or is it used in third-party plugins?

- frame end-routines are only called as the very last things in dissect_frame;
it is probably simplest to move that calling code into dissect_packet
(packet.c) instead, immediately after call_dissector(frame_handle, ...), since
file dissection code could theoretically want to register end-of-file
dissection routines as well

- any code that is really truly protocol-specific (eg gcp.c) should live with
that protocol proper

- the hf refs in print.c are tricky; PDML is a packet-specific markup language,
so I'm not sure it makes sense to even have that available for tfshark...


You are receiving this mail because:
  • You are watching all bug changes.