tcpdump capture filter for vlans incorrect

[Olli Salonen]

The BPF code output by tcpdump -d looks suspicious:

root@nucserver:/root# tcpdump -i eno1 vlan 114 -d
(000) ldb [-4048]
(001) jeq #0x1 jt 2 jf 5
(002) ldb [-4052]
(003) jeq #0x72 jt 4 jf 5
(004) ret #262144
(005) ret #0

There are negative offsets for the ldb commands. It seems to work though:

root@nucserver:/root# tcpdump -e -i eno1 vlan 114
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:15:18.545460 00:00:00:01:05:19 (oui Ethernet) > 01:00:5e:00:00:05 (oui Unknown), ethertype 802.1Q (0x8100), length 110: vlan 114, p 0, ethertype IPv4, 10.85.7.230 > ospf-all.mcast.net: OSPFv2, Hello, length 72
17:15:18.727565 00:30:88:17:62:67 (oui Unknown) > 00:00:00:01:05:28 (oui Ethernet), ethertype 802.1Q (0x8100), length 174: vlan 114, p 0, ethertype IPv4, 10.85.7.6.34530 > 10.85.0.144.6653: Flags [P.], seq 157278598:157278702, ack 282166902, win 1444, options [nop,nop,TS val 817752435 ecr 108670837], length 104: OpenFlow

Generating the BPF for matching VLAN tagged packets manually looks fine:

root@nucserver:/root# tcpdump -e -i eno1 "ether[12:2]==0x8100" -d
(000) ldh [12]
(001) jeq #0x8100 jt 2 jf 3
(002) ret #262144
(003) ret #0

But it does not match (even if there's heavy VLAN tagged traffic):

root@nucserver:/root# tcpdump -e -i eno1 "ether[12:2]==0x8100"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

On an Ubuntu 14.04 system it works as expected:

eollsal@cpoc:~$ uname -a
Linux cpoc.foobar.com 3.19.0-74-generic #82~14.04.1-Ubuntu SMP Fri Oct 21 15:43:47 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
eollsal@cpoc:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
eollsal@cpoc:~$ tcpdump -i eth2 vlan 114 -d
(000) ldh [12]
(001) jeq #0x8100 jt 3 jf 2
(002) jeq #0x9100 jt 3 jf 7
(003) ldh [14]
(004) and #0xfff
(005) jeq #0x72 jt 6 jf 7
(006) ret #65535
(007) ret #0
eollsal@cpoc:~$ tcpdump -h
tcpdump version 4.5.1
libpcap version 1.5.3

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: tcpdump 4.7.4-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Sun Nov 13 18:10:56 2016
InstallationDate: Installed on 2016-11-12 (0 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: tcpdump
UpgradeStatus: No upgrade log present (probably fresh install)

[Gianfranco Costamagna (costamagnagianfranco)]

Can you please try again with the new tcpdump in -security and zesty pockets?

[Olli Salonen (olli-salonen)]

The offsets are still negative:

root@tools:~# dpkg -l | grep tcpdump
ii tcpdump 4.9.0-2ubuntu2 amd64 command-line network traffic analyzer

root@tools:~# tcpdump --version
tcpdump version 4.9.0
libpcap version 1.7.4
OpenSSL 1.0.2g 1 Mar 2016

root@tools:~# tcpdump -i eno1 vlan 114 -d
(000) ldb [-4048]
(001) jeq #0x1 jt 2 jf 5
(002) ldb [-4052]
(003) jeq #0x72 jt 4 jf 5
(004) ret #262144
(005) ret #0

[Gianfranco Costamagna (costamagnagianfranco)]

Can you pleae report it to tcpdump development team?

[Lukas Tribus (luky-37)]

The kernel now longer passes vlan tag information as-is to libpcap, instead BPF needs to access ancillary data.

That is the reason "vlan 114" works (because it does the right thing), and a manual filter doesn't, because libpcap never actually sees this.

Offsets are negative because this is the way to access this ancillary data (like vlan tags) in the Linux kernel:
https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/uapi/linux/filter.h#L60