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-requ...@wireshark.org?subject=unsubscribe
