On Jun 23, 2010, at 7:30 PM, Guy Harris wrote:
>
> On Jun 23, 2010, at 3:59 PM, David H. Lipman wrote:
>
>> "not udp port 137" and any other additions.
>> If there are many, command line options are untenable. Loading and parsing an ASCII file
>> would be the way to go.
>
> One limit on the number of command-line filtering when capturing is that there are limits on the power of the filter expressions. However, you might end up putting in a lot of filters to filter out particular hosts, for example.
>
> If the command line is *itself* read from an ASCII file, then, obviously, command-line options do involve loading an ASCII file. If somebody is typing that command at a command line, then:
>
> 1) at least on UN*X command lines, you can say
>
> tshark -f `cat {filter}`
>
> where {filter} is the name of a file containing the filter, although that is limited by the number of bytes of command-line argument that the UN*X in question supports;
>
> 2) if you use tcpdump or WinDump rather than TShark or dumpcap to capture the traffic, it has a -F flag that takes, as an argument, the name of a file containing the filter expression (tcpdump/WinDump, TShark, and dumpcap all use libpcap/WinPcap to do traffic capture, so they all have the same capture filter syntax).
> ___________________________________________________________________________
If you are eating up argument space, you might want to consider xargs. I awk a directory containing sysmon logs and at about 5000 files awk complained about having not enough argument space. I googled and find this kind of solution to it:
find /Volumes/Data/PROJECTS/Sysmon/sysmon_logs -type f | xargs /usr/bin/awk -f /Volumes/Data/PROJECTS/Sysmon/sysmon_prgs/workerprocess.awk > /Volumes/Data/PROJECTS/Sysmon/outs/workerprocess.out
You can taylor it to your tshark experiment.
János
