On Jan 16, 2012, at 12:13 PM, Manolis Katsidoniotis wrote:
> Question 1
> In order to reduce captured traffic we also use capture filters.
> However the "highest" layer I can see is TCP/UDP (using ports).
Yes. The capture filter mechanism, as described in
http://www.tcpdump.org/papers/bpf-usenix93.pdf
involves a fairly simple pseudo-machine language, with an interpreter in the kernel, so the pseudo-machine language doesn't, for example, support loops, to prevent infinite loops from being run in the kernel. Its filtering capabilities are somewhat limited, and the compiler that translates filtes into pseudo-machine code is also somewhat limited.
> I’m not familiar with higher layer examples like the smtp below
If "the smtp below" refers to the screenshot of the list of capture filters, those aren't really higher-layer examples. "Non-HTTP and non-SMTP to/from www.wireshark.org" isn't a filter, it's just a name given to the filter in the filter list; the actual filter is just "not port 80 and not port 25 and host www.wireshark.org", i.e. it's just testing the TCP port number for "non-HTTP" and "non-SMTP".
> but especially for SIP
> or even capture filter examples of the type field[4:18]>200
> in which case I could filter out half the clause during capture and the other half during viewing
At best, you could do something along the lines of what's done here:
http://seclists.org/tcpdump/2004/q4/95
That filter is comparing the first 4 bytes of the TCP payload with 0x47455420 (big-endian), i.e. with "GET ".
> Question 2
>
> The filter I used as example is not actually used in wireshark.
> It is provided as input in tshark which reads files and produces some statistics for view (like below – it actually runs through a simple script and reads each file separately).
>
> Is this the same case (I mean when I use tshark)
Yes.
