[fab12@xxxxxxxxxxx]

Thanks for the detailed answer :-)

FYI this is a plugin dissector. I have handled the fact that packets are
dissected
out of order and multiple times.
It seems to work fine though I'm aware that what I do  does not really
respect wireshark dev. spirit partly because this is ad hoc proprietary
protocol and also because I am not wireshark development expert.

Actually I am generating a capture file derived from the initial capture
file.
The only flaw so far is the name of the file (PDU03Oct2011_11h13mn50s.pcap
for instance), the location (hardcoded C:\Temp\Wireshark) and the fact
that I don't have an external trigger (like a wireshark GUI menu) to
generate the file. So I generate it for each opened capture file .

Now that I understand better wireshark architecture I'm pretty sure it is
not possible but I still ask: Is there any way to access the current
filter applied from the plugin?
If yes I could use it to pass the location + filename and also as a
trigger...

Best regards
Fabien

>
> 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.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>