Re: [tcpdump-workers] odd issue with Linux VLAN interface
Denis Ovsienko de...@ovsienko.info wrote: Thus the behaviour is the same as it used to be for years, both on tcpdump side and on Linux side. It must be the odd timing that kept me thinking the BPF filter had somewhere flipped to do the opposite from its normal job, I had checked several times before posting. Perhaps this should be turned into a FAQ. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
Denis Ovsienko de...@ovsienko.info wrote: I have to correct myself: tcpdump -pni eth0 not tcp actually yields both TCP and everything else (ARP and UDP). It turns out that during all previous runs that everything else just didn't make it to the screen because of timing. Now it does, please see: please add -e. My bet is that there are vlan tags. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Wed, 28 Jan 2015 01:20:26 + Michael Richardson wrote Denis Ovsienko de...@ovsienko.info wrote: The host has an Ethernet interface with only an IPv6 link-local address (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference is, when tcpdump runs with -i eth0.75, it works as expected and displays ARP and, for instance, UDP from/to the network 10.0.75.0/24. When run with -i eth0, it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways as the tagged packets should not appear on the bearing interface in the first place and even if they appear there the filter should exclude them, but instead of this it excludes all the other packets. Tagged packets do appear, and if you add -e, you'll see the entire tag there too. At this point, it's hard to get the behaviour I think you want from the pcap compiler, which is to filter the traffic within the VLAN from the bearer. (I think that showing the tcp packets might be a fluke) You are right: root@homepc:~# tcpdump -pni eth0 -e not tcp 08:09:56.529239 00:0f:ea:18:f6:23 d4:ca:6d:72:b1:da, ethertype 802.1Q (0x8100), length 58: vlan 75, p 0, ethertype IPv4, 109.74.202.168.6633 10.0.75.2.55847: Flags [R.], seq 0, ack 1992001615, win 0, length 0 Of course, not ethertype ip and ip proto tcp does not match and the right way to do this filtering on this interface is to filter by vlan and not tcp (just checked, works). Thus the behaviour is the same as it used to be for years, both on tcpdump side and on Linux side. It must be the odd timing that kept me thinking the BPF filter had somewhere flipped to do the opposite from its normal job, I had checked several times before posting. Thank you for help, Guy and Michael. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
I.e., tcpdump -i eth0 not tcp prints *only* TCP packets? Yes, exactly. Just checked once again. Just out of curiosity, what does tcpdump -i eth0 -d not tcp print? root@homepc:~# tcpdump -pni eth0 -d not tcp (000) ldh [12] (001) jeq #0x86dd jt 2jf 7 (002) ldb [20] (003) jeq #0x6 jt 10 jf 4 (004) jeq #0x2cjt 5jf 11 (005) ldb [54] (006) jeq #0x6 jt 10 jf 11 (007) jeq #0x800 jt 8jf 11 (008) ldb [23] (009) jeq #0x6 jt 10 jf 11 (010) ret #0 (011) ret #262144 -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
[...] If IPv4 Protocol is TCP, go to 10, else go to 11 (010) ret #0 Reject packet (011) ret #262144 Accept packet So that *looks* OK. Thank you for the analysis! Could you run tcpdump -i eth0 -xx not tcp and see what the contents of the TCP packets being accepted are? I have to correct myself: tcpdump -pni eth0 not tcp actually yields both TCP and everything else (ARP and UDP). It turns out that during all previous runs that everything else just didn't make it to the screen because of timing. Now it does, please see: root@homepc:~# tcpdump -pni eth0 -xx not tcp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:56:19.466860 IP 109.74.202.168.6633 10.0.75.2.56538: Flags [.], ack 2668283334, win 235, options [nop,nop,TS val 521910355 ecr 1688339], length 0 0x: d4ca 6d72 b1da 000f ea18 f623 8100 004b 0x0010: 0800 4500 0034 dd1d 4000 3406 dcb1 6d4a 0x0020: caa8 0a00 4b02 19e9 dcda 6f36 d02b 9f0a 0x0030: c5c6 8010 00eb b34a 0101 080a 1f1b 0x0040: b853 0019 c313 00:56:20.332325 ARP, Request who-has 10.0.75.3 tell 10.0.75.254, length 28 0x: d4ca 6d66 cf65 000f ea18 f623 8100 004b 0x0010: 0806 0001 0800 0604 0001 000f ea18 f623 0x0020: 0a00 4bfe 0a00 4b03 It looks like the filter just has no effect at all, as tcpdump -pni eth0 not arp also delivers a similar mix of packets including ARP. And what does tcpdump -v print? Was it built with the latest libpcap? This might be an issue with the kernel and libpcap not properly working together to deal with VLAN tags - this commit: commit 04660eb1e56102e2369473cae2538e4d3d263607 Author: Michal Sekletar msekl...@redhat.com Date: Fri Oct 31 15:19:54 2014 +0100 Use BPF extensions in compiled filters libpcap will generate BPF filter code which uses BPF extensions if target platform supports them. Currently supported BPF extensions are vlan_tci and vlan_pr. Also to properly handle such filters when filtering in userspace libpcap now employs bpf_filter1. fixed some issues there. It is today's master branch build of both: root@homepc:~# tcpdump --version tcpdump version 4.7.0-PRE-GIT_2015_01_28 libpcap version 1.7.0-PRE-GIT_2015_01_28 OpenSSL 1.0.1f 6 Jan 2014 This Ubuntu host has no BPF extensions: denis@homepc:~/libpcap$ fgrep -r SO_BPF_EXT /usr/include/ denis@homepc:~/libpcap$ If this is a new bug, I can file it if it helps. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Jan 27, 2015, at 4:28 PM, Denis Ovsienko de...@ovsienko.info wrote: I.e., tcpdump -i eth0 not tcp prints *only* TCP packets? Yes, exactly. Just checked once again. Just out of curiosity, what does tcpdump -i eth0 -d not tcp print? root@homepc:~# tcpdump -pni eth0 -d not tcp (000) ldh [12] (001) jeq #0x86dd jt 2 jf 7 If ethertype == IPv6, go to 2, else go to 7 (002) ldb [20] (003) jeq #0x6 jt 10 jf 4 If IPv6 Next Header is TCP, go to 10, else go to 4 (004) jeq #0x2cjt 5 jf 11 If IPv6 Next Header is Fragment Header, go to 5, else go to 11 (005) ldb [54] (006) jeq #0x6 jt 10 jf 11 If header after that is TCP, go to 10, else go to 11 (007) jeq #0x800 jt 8 jf 11 If ethertype == IPv4, go to 8, else go to 11 (008) ldb [23] (009) jeq #0x6 jt 10 jf 11 If IPv4 Protocol is TCP, go to 10, else go to 11 (010) ret #0 Reject packet (011) ret #262144 Accept packet So that *looks* OK. Could you run tcpdump -i eth0 -xx not tcp and see what the contents of the TCP packets being accepted are? And what does tcpdump -v print? Was it built with the latest libpcap? This might be an issue with the kernel and libpcap not properly working together to deal with VLAN tags - this commit: commit 04660eb1e56102e2369473cae2538e4d3d263607 Author: Michal Sekletar msekl...@redhat.com Date: Fri Oct 31 15:19:54 2014 +0100 Use BPF extensions in compiled filters libpcap will generate BPF filter code which uses BPF extensions if target platform supports them. Currently supported BPF extensions are vlan_tci and vlan_pr. Also to properly handle such filters when filtering in userspace libpcap now employs bpf_filter1. fixed some issues there. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Jan 27, 2015, at 4:09 PM, Denis Ovsienko de...@ovsienko.info wrote: some time ago I did troubleshooting on a Linux PC and that involved running tcpdump with the not tcp filter on a few network interfaces to put a number of background TCP connections out of scope (I was interested how other protocols' packets were making from one interface to the other). At some point I had realized that tcpdump was printing TCP packets _only_ and no other protocols (again, the filter was not tcp). Later I figured it out how to reproduce the problem but not the cause of it. The host has an Ethernet interface with only an IPv6 link-local address (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference is, when tcpdump runs with -i eth0.75, it works as expected and displays ARP and, for instance, UDP from/to the network 10.0.75.0/24. When run with -i eth0, it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways as the tagged packets should not appear on the bearing interface in the first place and even if they appear there the filter should exclude them, but instead of this it excludes all the other packets. I.e., tcpdump -i eth0 not tcp prints *only* TCP packets? Just out of curiosity, what does tcpdump -i eth0 -d not tcp print? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] odd issue with Linux VLAN interface
List, some time ago I did troubleshooting on a Linux PC and that involved running tcpdump with the not tcp filter on a few network interfaces to put a number of background TCP connections out of scope (I was interested how other protocols' packets were making from one interface to the other). At some point I had realized that tcpdump was printing TCP packets _only_ and no other protocols (again, the filter was not tcp). Later I figured it out how to reproduce the problem but not the cause of it. The host has an Ethernet interface with only an IPv6 link-local address (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference is, when tcpdump runs with -i eth0.75, it works as expected and displays ARP and, for instance, UDP from/to the network 10.0.75.0/24. When run with -i eth0, it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways as the tagged packets should not appear on the bearing interface in the first place and even if they appear there the filter should exclude them, but instead of this it excludes all the other packets. This is the latest build of tcpdump on kernel 3.13.0-44-generic #73-Ubuntu SMP. Not sure if I will get to find the reason myself, but if anybody sees this as a duplicate of or an additional input for one of the known bugs, please let me know. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
