Re: Using a tap to make a dissector work?

[Sake Blok <sake () euronet nl>]

On 8 mrt 2011, at 15:55, Jeff Morriss wrote:

> Sake Blok wrote:
> > Hi,
> > The buildbots are failing on the test.sh script because:
> > sake@macsake-wifi:~/Wireshark/trunk/test$ ../tshark -r dhcp.pcap -w - > tmp.cap
> > tshark: Taps aren't supported when saving to a pipe.
> > sake@macsake-wifi:~/Wireshark/trunk/test$
> > I tracked this down to http://anonsvn.wireshark.org/viewvc?view=revision&revision=35323 in which the tap 
> > functionality is used to track mappings that determine how packets should be dissected.
> > This basically makes writing to a pipe in tshark impossible unless the protocol would be dissabled. What would be 
> > the proper way to go?
> > 1) From a quick view of the code, the tap has been used as the conversation tracking wireshark provides does not 
> > provide the proper hooks for this kind of traffic. Should we change the conversation tracking to a more general 
> > framework? Or maybe map the indices that are available to the variables that are available (if this is at all 
> > possible). But then we need to make sure there will be no overlapping (which kinda calls for a general framework 
> > again).
> > 2) Allow taps to be used in dissectors and remove the check in tshark? Tshark does not know whether the tap is 
> > producing output or not, so maybe we need to have a flag with each tap to state whether it will produce output or 
> > not.
> > 3)  Just leave things as they are and disable this protocol by default (as has been done to PRP)?
> > Any ideas?
>
> Just for cross-referencing purposes:
>
> This issue is tracked in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5445 .  There, Guy suggested:
>
> > The trick might be to have multiple types of taps, such as ones that produce no
> > output, and are allowed to be unconditionally run, and ones that produce
> > output, which are not allowed to be unconditionally run.  Dissection will be
> > forced on in TShark if one of the latter type of taps is listening, but will
> > not be forced on if only the former type of taps is listening.
>
> That sounds similar to (2) above.

It does indeed. 

I checked the bug report. As long as it's kept open until there is a solution, we can skip the discussion here :-)

In the mean time, should we disable these protocols by default until it has been sorted out? It's a shame to have the 
buildbots unavailable because of this.

Cheers,


Sake

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe