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 |
One Answer:
Works for me (libpcap version 1.3.0 on OSX): Could you show the output of "compile BPF filter" (or run 'tcpdump -d "<filter>"' on the CLI). It should show something like this: 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 ♦♦ Thats my output from "compile BF filter": 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: Now with the filter applied: 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): 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: (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 |
Just changed the virtual network card, did not make a difference