Comment # 5
on bug 1814
from Tore Anderson
(In reply to comment #2)
> ...and if we're not going to use the filter, we shouldn't let the user
> specify it, as having a capture filter box fools the user into thinking it
> makes a difference.
>
> As such, doing bpf_filter() on the packets when reading from a pipe is
> probably the right idea, if doable. *HOWEVER*, doing the filtering in the
> program writing to the pipe (or, if that program is getting its input from
> another program, e.g. a tcpdump/WinDump run over ssh, doing it in *that*
> program - i.e., doing itas early as possible in the pipeline) is *STILL* a
> good idea, as per my previous comment.
The reason I came across this issue was that I needed to dump packets on my
home gateway, an embedded device with a stripped down Linux operating system on
it. It has tcpdump installed, but it is compiled without IPv6 decoding support
(it can only match the IPv6 ethertype, nothing else). I need to save only
DHCPv6 IPv6 traffic, dumping all of it would fill my disks quite rapidly.
So I wanted to do was on the home gateway something like:
$ tcpdump -i wan0 -U -w - ip6 | nc my-workstation 12345
And on the workstation do something like:
$ nc -l 12345 | tshark -i - -f "udp and (port dhcpv6-client or port
dhcpv6-server)" -w dhcpv6.pcap
In other words, thark is the earliest place in the pipeline I could apply the
capture filter. But, because it ignores the capture filter, the dhcpv6.pcap
quickly became much too large, since it contained all IPv6 traffic, not only
DHCPv6.
I managed to find a workaround, though, by giving the filter "ip6 and ip6[6] ==
17 and (ip6[40:2] == 546 or ip6[42:2] == 546 or ip6[40:2] == 547 or ip6[42:2]
== 547)" to the tcpdump on the home gateway. But it would have been much easier
if tshark could do it instead.
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.