On Oct 2, 2011, at 11:09 PM, fab12@xxxxxxxxxxx wrote:
> I made a dissector that so far is used with capture file generated from
> traces by a protocol simulator.
> So it is not realtime ethernet sniffering.
> In the dissector I am gathering data from the read capture file to
> generate a new file
> with misc information.
> Now I need to name and save this file. So far I am using current date and
> hard coded default directory.
> It would be much more convenient to save it in the capture filename
> directory and name it after it.
>
> So my question is: is there a variable that contains the location and file
> name of the capture file?
In a dissector, there is no inherent guarantee that there *is* a capture file; in theory (and perhaps even in practice - I don't know whether any of the programs in the Wireshark suite run the dissector code in libwireshark with packets that don't come from a capture file, but, even if there aren't, there might be other programs out there using libwireshark in that fashion) a packet might just come from memory.
So, for a dissector, no, there is no variable that contains the location or file name of the capture file, because libwireshark has no notion of "the capture file". In fact, the data structure that contains that information is not defined in libwireshark, so there's no guarantee that if you tried to refer to it in a dissector, libwireshark would even build - it might work in a UN*X, but probably wouldn't work in Windows. The same applies to referring to it in a plugin dissector.
I would suggest that you add a tap interface to your dissector, and do the writing of the data to the file in a tap, instead. A plugin tap might not be able to refer to the data structure on Windows, but a built-in tap would. Note also that a dissector is, in Wireshark, not guaranteed to be called for all packets in the order in which they appear in the file; there is an initial pass in which all packets are read in and dissected, but it is possible for a dissector to be called again for a packet that has already been dissected, and it's possible for that to happen before all the packets have been read in. The "pinfo->fd->flags.visited" field could be used to know whether this is the first time a dissector was called, but that flag can be cleared if the capture file is redissected due to, for example, a preference being changed; a tap, however, can be set up so that it's called once per packet, in order, while the tap processing is being done.
*Currently*, in both Wireshark and TShark, there is a global variable named "cfile", which is a "capture_file" structure. The "capture_file" type is defined in the top-level header "cfile.h". The pathname of the capture file is the "filename" member of that structure. It is not guaranteed to be an absolute pathname, so it is not guaranteed to contain the pathname of the directory containing the capture file. We do not guarantee that the "cfile" data structure will continue to exist in future releases.
