On Oct 2, 2011, at 11:09 PM, fa...@freesurf.fr 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to