This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Filter for TCP source port in IPv6

0

Hello,

I'm trying to create a capture filter for my TCP packets. I want to filter for packets with a specific source port, lets say port 1.

My filter is "tcp src port 1", and I also tried "tcp and src port 1".

However, this works perfectly when I use IPv4. But when I use IPv6, it doesn't. I don't capture any packets, although the TCP header is exactly the same, I just exchanged the IP-layer. When I filter for "tcp port 1" or "tcp and port 1", I get all packets which have 1 as destination port, but none of the packets which have 1 as source port.

Could this be a bug in the pcap library? The fact that it fully works with IPv4, but only with the destination port in IPv6 and not with the source port makes me think that way....

Oh yeah, also, when I try to make a display filter, everything works if I set it for example to "tcp.srcport==1", in both IPv4 and IPv6.

I'm running libpcap0.8 version 1.4.0-1, my wireshark version is 1.8.7-1.

Thanks for your help!

Regards, Moe

asked 30 May '13, 05:57

moe's gravatar image

moe
16115
accept rate: 0%

Just changed the virtual network card, did not make a difference

(30 May '13, 07:05) moe

One Answer:

3

Works for me (libpcap version 1.3.0 on OSX):

$ tshark -i en1 "tcp src port 80"
Capturing on en1
  0.000000 2001:898:2000:1::244 -> 2001:980:5354:3:fa1e:dfff:fed8:8748 TCP 94 http > 53101 [SYN, ACK] Seq=0 Ack=1 Win=5712 Len=0 MSS=1440 SACK_PERM=1 TSval=1714395974 TSecr=394066808 WS=128
  0.027056 2001:898:2000:1::244 -> 2001:980:5354:3:fa1e:dfff:fed8:8748 TCP 86 http > 53101 [ACK] Seq=1 Ack=784 Win=7296 Len=0 TSval=1714396004 TSecr=394066809
  0.046179 2001:898:2000:1::244 -> 2001:980:5354:3:fa1e:dfff:fed8:8748 TCP 1410 [TCP segment of a reassembled PDU]
  0.051261 2001:898:2000:1::244 -> 2001:980:5354:3:fa1e:dfff:fed8:8748 HTTP 91 HTTP/1.1 200 OK  (text/html)

Could you show the output of "compile BPF filter" (or run 'tcpdump -d "<filter>"' on the CLI). It should show something like this:

(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 6
(002) ldb      [20]
(003) jeq      #0x6             jt 4    jf 15
(004) ldh      [54]
(005) jeq      #0x50            jt 14   jf 15
(006) jeq      #0x800           jt 7    jf 15
(007) ldb      [23]
(008) jeq      #0x6             jt 9    jf 15
(009) ldh      [20]
(010) jset     #0x1fff          jt 15   jf 11
(011) ldxb     4*([14]&0xf)
(012) ldh      [x + 14]
(013) jeq      #0x50            jt 14   jf 15
(014) ret      #65535
(015) ret      #0

Maybe there is a bug in your version of libpcap indeed. Also, are you sure your frames are not vlan tagged (or encapsulated in pppoe or something else)?

answered 30 May '13, 06:27

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thats my output from "compile BF filter":

(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 6
(002) ldb      [20]
(003) jeq      #0x6             jt 4    jf 15
(004) ldh      [54]
(005) jeq      #0x1             jt 14   jf 15
(006) jeq      #0x800           jt 7    jf 15
(007) ldb      [23]
(008) jeq      #0x6             jt 9    jf 15
(009) ldh      [20]
(010) jset     #0x1fff          jt 15   jf 11
(011) ldxb     4*([14]&0xf)
(012) ldh      [x + 14]
(013) jeq      #0x1             jt 14   jf 15
(014) ret      #65535
(015) ret      #0

Its the same output as you have, except that I specified port 1 in line 6.

The communication I'm capturing is between two Virtual machines on the same physical PC. Wireshark runs on one of the virtual machines. So, yes, I'm sure that there's no VLAN or other things.

Here is (part of) the output of tshark when I do not filter for ports:

$ sudo tshark -i eth0 "tcp"
Capturing on eth0
  0.000000          ::a -> ::c          TCP 54425 > tcpmux [SYN, ACK] Seq=500048637 Ack=3996483048 Win=1024 Len=0 MSS=1460
  0.000253          ::c -> ::a          TCP tcpmux > 54425 [RST] Seq=3996483048 Win=0 Len=0

Now with the filter applied:

$ sudo tshark -i eth0 "tcp port 1"
Capturing on eth0
  0.000000          ::a -> ::c          TCP 35982 > tcpmux [SYN, ACK] Seq=4190420215 Ack=4138811225 Win=1024 Len=0 MSS=1460

The RST packet does not appear.

Any clues how to debug this further? I will try to change the virtual network cards of the machines, maybe this helps... I also already tried a different libpcap version (1.3.0-1), but that also did not help.

(30 May '13, 06:50) moe

Are you able to share the capture files on www.cloudshark.org? One taken with just "tcp" as filter and the other one taken with "tcp port 1" as filter (preferably made at the same time)?

(30 May '13, 07:04) SYN-bit ♦♦

here you go! the first pcap with the filter "tcp": http://cloudshark.org/captures/7c257d3b1532

the second pcap with the filter "tcp port 1": http://cloudshark.org/captures/5c6adae06fa1

both taken at the same time

(30 May '13, 07:21) moe

The return traffic is having an IPv6 fragmentation header. This changes the offset of the TCP within the packet. Since there are no loops allowed in BPF filtering, it is not possible for BPF to dynamically hop over all the possible IPv6 headers to adjust the offset for the tcp header.

The strange part is that when using only "tcp" as filter, the fragmentation header is accounted for (see line 4 of the BPF code):

$ tcpdump -d "tcp"
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 7
(002) ldb      [20]
(003) jeq      #0x6             jt 10   jf 4
(004) jeq      #0x2c            jt 5    jf 11
(005) ldb      [54]
(006) jeq      #0x6             jt 10   jf 11
(007) jeq      #0x800           jt 8    jf 11
(008) ldb      [23]
(009) jeq      #0x6             jt 10   jf 11
(010) ret      #65535
(011) ret      #0
$

This might be considered a bug in libpcap or if looked at differently, it would be an enhancement request in libpcap :-)

(30 May '13, 07:41) SYN-bit ♦♦

As for now, you can manually do the skipping of the extra header as follows:

$ tcpdump -nnlr tcp.pcap "(ip6[6]=6 and ip6[40:2]=1) or (ip6[6]=44 and ip6[40]=6 and ip6[48:2]=1)"
reading from file tcp.pcap, link-type EN10MB (Ethernet)
16:14:23.515746 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63034: Flags [R], seq 1099986487, win 0, length 0
16:14:23.547560 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63035: Flags [R], seq 1099986487, win 0, length 0
16:14:23.579576 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63036: Flags [R], seq 1099986487, win 0, length 0
16:14:23.611582 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63037: Flags [R], seq 1099986487, win 0, length 0
16:14:23.644003 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63038: Flags [R], seq 1099986487, win 0, length 0
16:14:23.676372 IP6 ::0.0.0.12 > ::0.0.0.10: frag (0|20) 1 > 63039: Flags [R], seq 1099986487, win 0, length 0
$
(30 May '13, 07:50) SYN-bit ♦♦

You are the man! I would have never found that issue on my own!

I guess changing this in libpcap would be desirable, especially because there might be also extension headers before the fragmentation header.

Thanks! If I managed to get my code published in Nmap, I will give you the credits for this one :)

(30 May '13, 09:05) moe
showing 5 of 6 show 1 more comments