I would appreciate some thoughts on this change from someone who knows
the reassembly machinery better than myself.
Evan
On Sat, Mar 2, 2013 at 11:39 AM, eapa...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=48011
User: eapache
Date: 2013/03/02 08:39
My instinct is to get rid of the 'read filter' concept entirely. I
find it's behaviour in wireshark very confusing, especially in the
reassembly cases we're considering. For example, take the capture from
bug #8223 and run
./wireshark -R ip.src == 10.90.130.69 ip.dst == 10.90.130.66
Yeah but getting rid of Wireshark's read filter is a much bigger change, if you
mean getting rid of it within Wireshark's GUI as well. On the other hand it
might be less confusing even within Wireshark to have fewer places/ways to
apply filters.
The *tshark* legacy '-R' by itself (without
BTW, some output from that bug's pcap with your filter:
./tshark -r testcapture.pcapng -R 'ip.src == 10.90.130.69 ip.dst ==
10.90.130.66 tcp.flags.push == 1'
5 0.001054000 0.5 10.90.130.69 - 10.90.130.66 HTTP/XML POST
/urreq/rrurreq.dll/?soaprequest HTTP/1.1
./tshark -r
Hi All,
I've released my dissector to the wild :
http://nikonhacker.com/viewtopic.php?f=2t=708
What is the next step to get it included into the next release of Wire
Shark?
Thanks,
-m
___
Sent via:Wireshark-dev
