Sake Blok wrote:
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 :-)
Well, except that no progress has been made--discussion out here might
change that. :-)
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.
Except that having the buildbots red might eventually annoy someone
enough to fix the underlying problem ;-). (More seriously: I think
test.sh is the last step so they're only missing the other tests in the
test suites. Or is something else being missed/lost?)
___________________________________________________________________________
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
