From: On Behalf Of Guy Harris > On Jan 25, 2007, at 8:23 PM, Stuart MacDonald wrote: > > I've read the man pages on the tools that come with Wireshark. I was > > hoping to find a tool that opens a capture, applies a filter and > > outputs matching packets to a new file. Here's a sample run of the > > hypothetical filtercap tool: > > # filtercap -r very-large.eth -w only-infrequent.eth -f > > "tcp.port==50000" > > tcpdump -r very-large.eth -w only-infrequent.eth tcp port 50000
tcpdump isn't part of wireshark. Thanks though, I think I still have the original capture on the original machine, and this would be faster than the shell script solution elsethread. > That can't do arbitrary display filtering, but truly *arbitrary* > display filtering has problems with reassembly (i.e., a filter that > matches something in the reassembled portion of the packet > can't match > anything but the last packet). It also can't handle non-libpcap Fair enough. What exactly constitutes the reassembled portion? I'm thinking it's things like the TCP analysis; "Zero Window" status etc. <mulls> I guess it's anything that can't be expressed as a capture filter. Interesting. I've lcoated http://wiki.wireshark.org/TCP_Reassembly and those options are off (by default) for my Wireshark. Are they not also off (by default) for tshark? > > tshark is almost the right thing, except that tshark also tries to > > read in the whole capture first instead of processing it > like editcap. > > No, actually, it *does* process it like editcap; neither it nor > Wireshark read the entire capture file into memory. They *do* keep > reassembled data in memory, but that's another matter. Let me reprhase that then. tshark also bails with the out of memory crash, just like Wireshark. editcap does not. I assumed that was due to the method of processing the file, but I see now that it's due to reassembly, and this is perhaps why editcap doesn't filter on anything but frame numbers and time; it avoids reassembly by doing so. Hm, the research on TCP Reassembly from above makes me think the crashes are not due to reassembly after all. Is that a new bug in Wireshark/tshark then? Ah yes. tshark refuses to apply a capture filter when reading from a file, thereby enforcing a display filter and the subsequent crash. I suppose that it can't apply a capture filter because it's not using libpcap to get the packets in the first place? Perhaps libpcap needs to be taught how to use a file instead of an interface. Is there a way to turn off reassembly so that tshark would work the same as tcpdump in the above example? Although now it looks like it should be off (by default). ..Stu _______________________________________________ Wireshark-users mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-users
