There are no extension headers in these IPv6 packets. They are just plain
256-byte UDP IPv6 packets (not counting UDP and IPv6 overhead).
"tcpdump -d not port 6000" prints out the following:
(000) ldh [12]
(001) jeq #0x800 jt 2 jf 14
(002) ldb [23]
(003) jeq #0x84 jt 6 jf 4
(004) jeq #0x6 jt 6 jf 5
(005) jeq #0x11 jt 6 jf 14
(006) ldh [20]
(007) jset #0x1fff jt 14 jf 8
(008) ldxb 4*([14]&0xf)
(009) ldh [x + 14]
(010) jeq #0x1770 jt 13 jf 11
(011) ldh [x + 16]
(012) jeq #0x1770 jt 13 jf 14
(013) ret #0
(014) ret #96
I just noticed that "tcpdump -i eth1 -n not port 6000" also does not filter
out the traffic correctly (nor does "not dst port 6000"). Also, "tcpdump
-i eth1 -n port 6000" captures nothing, as if it's not recognizing the port
correctly. However, it prints out the port correctly with "not port 6000":
"fec0:108:0:59::7.33001 > fec0:1080:0:59::100.6000: udp 256".
After looking into it some more, I have discovered the following:
does not work:
tcpdump, version 3.7.1, libpcap version 0.7
Ethereal, version 0.10.0, libpcap version 0.7
does work:
Ethereal, version 0.9.1.3, libpcap version 0.6
So going off this, perhaps something is wrong with libpcap 0.7?
-Jeff
At Wednesday 1/21/2004 12:26 AM, Guy Harris wrote:
On Tue, Jan 20, 2004 at 02:47:00PM -0500, Jeff Weston wrote:
> While I was testing though, I did run across one problem: the capture
> filter "not port 6000" worked fine for IPv4 packets, but did not work for
> IPv6 packets (UDP, just general traffic created by a testing tool, not any
> specific protocol). Could be something you guys are currently working on,
If "you guys" refers to the Ethereal developers, no, it can't be
anything we're currently working on, as capture filtes are implemented
by libpcap, not Ethereal.
However, some of us also work on libpcap and tcpdump. What does the
command
tcpdump -d not port 6000
print? And are there any extension headers in your IPv6 packets?