Hi guys,

 

Using Debian Jessie/armbian 4.5 here. Was today using tcpdump, tested out also tshark, and aparently the BPF rules are not working... (?)

 

Is it just me, some kernel compiling, a bug, or am I missing something? I know for sure that in a very similar setup I have at work in Intel, I do not have this problem.

 

This issue is present both with libpcap 1.7.4-1 and 1.6.2-2

 

As an example:

 

rui@ruir:/etc$ sudo tcpdump -n not port 22 | egrep "22[ :]"

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

14:50:34.559080 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 4022649725:4022649913, ack 2953755432, win 335, options [nop,nop,TS val 6371162 ecr 1180556165], length 188

14:50:40.527727 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 188:408, ack 1, win 335, options [nop,nop,TS val 6371759 ecr 1180557444], length 220

14:50:41.526983 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 408:604, ack 1, win 335, options [nop,nop,TS val 6371859 ecr 1180563404], length 196

14:50:47.527292 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 604:880, ack 1, win 335, options [nop,nop,TS val 6372459 ecr 1180564390], length 276

14:50:50.527237 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 880:1076, ack 1, win 335, options [nop,nop,TS val 6372759 ecr 1180570384], length 196

14:50:53.527155 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 1076:1280, ack 1, win 335, options [nop,nop,TS val 6373059 ecr 1180573371], length 204

14:50:54.527222 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 1280:1484, ack 1, win 335, options [nop,nop,TS val 6373159 ecr 1180576370], length 204

14:50:55.527043 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 1484:1688, ack 1, win 335, options [nop,nop,TS val 6373259 ecr 1180577369], length 204

14:50:57.527493 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 1688:1892, ack 1, win 335, options [nop,nop,TS val 6373459 ecr 1180578362], length 204

14:50:58.527957 IP xx.xxx.254.104.22 > xxx.xxx.xxx.2.57030: Flags [P.], seq 1892:2096, ack 1, win 335, options [nop,nop,TS val 6373559 ecr 1180580358], length 204

I solved this myself. I suspected it was due to problems of using a toolchain in a foreign architecture, and compiled/made a deb with the debian libpcap sources myself in ARM. It is working now.

 

The steps to fix it are:

 

$apt-get source libpcap

$cd libpcap-1.6.2/

$apt-get install debhelper dh-autoreconf flex bison

$fakeroot dpkg-buildpackage -b -uc

$cd ..

$sudo dpkg -i libpcap0.8_1.6.2-2_armhf.deb

$sudo echo "libpcap0.8:armhf hold" | dpkg --set-selections

I am wrong apparently. It is still is faulty, it must be something else. No idea if it is related to bugs handling 802.1Q

unsure what you are looking for...

 

if using vlan with lamobo, you need a trick to make vlan appear as tcpdump is not "meant for" vlan

 

sudo tcpdump -i eth0 -Uw - | tcpdump -v -en -r - vlan

 

sudo tcpdump -i eth0 -Uw - | tcpdump -v -en -r - vlan 102

 

 

ref.

http://virtualtechnotes.com/linux-administration/linux-networking/tcpdump-filter-802-1q-tagged-traffic

http://serverfault.com/questions/544651/vlan-tags-not-shown-in-packet-capture-linux-via-tcpdump

(same issue on linux amd64 or arm)

Edited October 31, 201510 yr by wildcat_paris

Interesting...the syntax seems a bit off (not working here) I will investigate it. I was already suspecting it had something to do with the VLANs/802.1Q headers. Thanks for pointing me in the right direction. 

Already tested it out, if I put there the vlan it works. Thanks.

 tcpdump -n vlan 102 and not port 8200

Better yet, I found out that if I add  bridge_stp off to the interfaces, I do not need to deal with VLANs in tcpdump.