Raising the count doesn't seem to make a difference. It looks
like by default the pfring version of tcpdump compiled against
the static '.a' libraries. However, an LD_PRELOAD against the
system tcpdump shows the same behavior for BPF:
% LD_PRELOAD=/opt/pf/lib/libpcap.so /usr/sbin/tcpdump -i enp4s0 -nn -c 100
'port 22'
[...]
12:49:52.968109 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.59732: Flags [.], ack 341,
win 40137, length 0
12:49:52.968111 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
12:49:52.968114 IP XX.XX.XX.XX.16402 > XX.XX.XX.XX.16402: UDP, length 1199
12:49:52.968116 IP XX.XX.XX.XX.16402 > XX.XX.XX.XX.16402: UDP, length 1214
12:49:52.968119 IP XX.XX.XX.XX.16402 > XX.XX.XX.XX.16402: UDP, length 1214
12:49:52.968121 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
12:49:52.968125 IP XX.XX.XX.XX.57910 > XX.XX.XX.XX.80: Flags [.], ack 14601,
win 64240, length 0
12:49:52.968126 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
12:49:52.968129 IP XX.XX.XX.XX.80 > XX.XX.XX.XX.60891: Flags [.], ack
1874981220, win 36500, length 0
12:49:52.968136 IP XX.XX.XX.XX.80 > XX.XX.XX.XX.60891: Flags [.], ack 1461,
win 39420, length 0
12:49:52.968138 IP XX.XX.XX.XX.80 > XX.XX.XX.XX.60891: Flags [.], ack 2921,
win 42340, length 0
12:49:52.968140 IP XX.XX.XX.XX.56143 > XX.XX.XX.XX.80: Flags [.], ack
4294809464, win 7059, options [nop,nop,TS val 3769675 ecr 1069192846], length 0
12:49:52.968142 IP XX.XX.XX.XX.57403 > XX.XX.XX.XX.443: Flags [.], ack
2314912516, win 4086, options [nop,nop,TS val 948999881 ecr 2452962927], length 0
12:49:52.968144 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
12:49:52.968146 IP XX.XX.XX.XX.80 > XX.XX.XX.XX.60891: Flags [.], ack 4381,
win 45260, length 0
12:49:52.968148 IP XX.XX.XX.XX.80 > XX.XX.XX.XX.60891: Flags [.], ack 4771,
win 48180, length 0
12:49:52.968150 IP XX.XX.XX.XX.57910 > XX.XX.XX.XX.80: Flags [.], ack 16061,
win 64240, length 0
12:49:52.968151 IP XX.XX.XX.XX.57403 > XX.XX.XX.XX.443: Flags [.], ack 2797,
win 3998, options [nop,nop,TS val 948999882 ecr 2452962930], length 0
12:49:52.968153 IP XX.XX.XX.XX.57403 > XX.XX.XX.XX.443: Flags [.], ack 5593,
win 3911, options [nop,nop,TS val 948999882 ecr 2452962930], length 0
12:49:52.968155 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
12:49:52.968157 IP XX.XX.XX.XX.57403 > XX.XX.XX.XX.443: Flags [.], ack 8097,
win 3833, options [nop,nop,TS val 948999883 ecr 2452962930], length 0
12:49:52.968159 IP XX.XX.XX.XX.443 > XX.XX.XX.XX.61003: UDP, length 1453
100 packets captured
100 packets received by filter
% ldd /usr/sbin/tcpdump
linux-vdso.so.1 => (0x00007fffcc56f000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fe53c391000)
libpcap.so.1 => /lib64/libpcap.so.1 (0x00007fe53c150000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe53bd8e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe53bb8a000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe53b974000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe53c786000)
% ldd /opt/pf/sbin/tcpdump
linux-vdso.so.1 => (0x00007fff95ba7000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fee6ab40000)
librt.so.1 => /lib64/librt.so.1 (0x00007fee6a937000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fee6a71b000)
libm.so.6 => /lib64/libm.so.6 (0x00007fee6a419000)
libc.so.6 => /lib64/libc.so.6 (0x00007fee6a057000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fee69e53000)
libz.so.1 => /lib64/libz.so.1 (0x00007fee69c3d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fee6af35000)
% strings /usr/sbin/tcpdump | grep PF_R
% strings /opt/pf/sbin/tcpdump | grep PF_R
PF_RING
PF_RING H
PCAP_NO_PF_RING
PCAP_PF_RING_ACTIVE_POLL
PCAP_PF_RING_DNA_RSS
PCAP_PF_RING_ZC_RSS
PCAP_PF_RING_STRIP_HW_TIMESTAMP
PCAP_PF_RING_RECV_ONLY
Jim
On 05/30/2016 11:23 PM, Joseph Gresham wrote:
> I see similiar behavior on debian linux, except after some time the bpf
> starts to work. Curious Jim if you expand the count to say -c 25 do is
> it then seem to work? Im on version 6.1.1 kernel 3.16 libpcap 1.6.2
>
> ldd `which tcpdump`
> linux-vdso.so.1 (0x00007fff925d3000)
> libpcap.so.0.8 => /usr/lib/libpcap.so.0.8 (0x00007f71cd33c000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f71ccf93000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f71ccd76000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f71ccb6e000)
> libnl-genl-3.so.200 => /lib/x86_64-linux-gnu/libnl-genl-3.so.200
> (0x00007f71cc968000)
> libnl-3.so.200 => /lib/x86_64-linux-gnu/libnl-3.so.200
> (0x00007f71cc74b000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f71cd5d2000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f71cc44a000)
>
> ls -al /usr/lib/libpcap.so.0.8
> lrwxrwxrwx 1 root root 31 Nov 14 2015 /usr/lib/libpcap.so.0.8 ->
> /usr/local/lib/libpcap.so.1.6.2
>
>
> strings /usr/local/lib/libpcap.so.1.6.2 | grep PF_R
>
> strings /usr/local/lib/libpcap.so.1.6.2 | grep PF_R
> PF_RING
> PF_RING
> PCAP_PF_RING_STRIP_HW_TIMESTAMP
> PCAP_PF_RING_USE_CLUSTER_PER_FLOW
> PCAP_PF_RING_USE_CLUSTER_PER_FLOW_2_TUPLE
> PCAP_PF_RING_USE_CLUSTER_PER_FLOW_4_TUPLE
> PCAP_PF_RING_USE_CLUSTER_PER_FLOW_TCP_5_TUPLE
> PCAP_PF_RING_USE_CLUSTER_PER_FLOW_5_TUPLE
> PCAP_NO_PF_RING
> PCAP_PF_RING_ACTIVE_POLL
> PCAP_PF_RING_DNA_RSS
> PCAP_PF_RING_RECV_ONLY
> PCAP_PF_RING_CLUSTER_ID
> PCAP_PF_RING_APPNAME
> PCAP_PF_RING_RSS_REHASH
> [PF_RING] Warning: unable to unmap ring buffer memory [address=%p][size=%u]
> [PF_RING] mmap() failed: try with a smaller snaplen
> [PF_RING] Wrong RING version: kernel is %i, libpfring was compiled with %i
> [PF_RING] ring failure (pfring_get_slot_header_len)
> [PF_RING] failure enabling rx packet bounce support
> [PF_RING] mmap() failed
> # ERROR: You do not seem to have a valid PF_RING ZC license %s for %s [%s]
>
>
> strings /lib/modules/3.16.0-4-amd64/updates/dkms/pf_ring.ko | grep
> 'verm\|^[0-9]\.[0-9]'
> 6.1.1
> vermagic=3.16.0-4-amd64 SMP mod_unload modversions
> __UNIQUE_ID_vermagic0
>
>
> tcpdump version 4.5.0-PRE-GIT_2013_07_20
> libpcap version 1.6.2
>
> tcpdump -i eth2 -n tcp port 443 -vv -c 25
>
> tcpdump: WARNING: eth2: no IPv4 address assigned
> tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size
> 65535 bytes
>
> 22:12:46.066884 IP (tos 0x0, ttl 128, id 13098, offset 0, flags [DF],
> proto TCP (6), length 124)
> 10.108.112.10.135 > 10.101.253.24.52406: Flags [P.], cksum 0x3146
> (correct), seq 3167632000:3167632084, ack 533236072, win 261, length 84
>
> 22:12:46.066909 IP (tos 0x0, ttl 64, id 56989, offset 0, flags [DF],
> proto TCP (6), length 140)
> 10.101.118.228.22 > 10.10.207.54.52653: Flags [P.], cksum 0x963b
> (correct), seq 619225200:619225288, ack 2621028941, win 358, options
> [nop,nop,TS val 4206738090 ecr 918632462], length 88
>
> 22:12:46.069984 IP (tos 0x0, ttl 124, id 27449, offset 0, flags [DF],
> proto TCP (6), length 99)
> 10.101.244.1.443 > 10.101.116.177.56877: Flags [P.], cksum 0x129b
> (correct), seq 922098006:922098065, ack 1189466598, win 256, length 59
>
> 22:12:46.073738 IP (tos 0x0, ttl 124, id 27450, offset 0, flags [DF],
> proto TCP (6), length 573)
> 10.101.244.1.443 > 10.101.112.251.49619: Flags [P.], cksum 0x6cff
> (correct), seq 3211492618:3211493151, ack 3059021072, win 256, length 533
>
> 22:12:46.073931 IP (tos 0x0, ttl 124, id 27451, offset 0, flags [DF],
> proto TCP (6), length 1500)
> 10.101.244.1.443 > 10.101.112.251.49619: Flags [.], cksum 0xd577
> (correct), seq 533:1993, ack 1, win 256, length 1460
>
> 22:12:46.073951 IP (tos 0x0, ttl 124, id 27452, offset 0, flags [DF],
> proto TCP (6), length 1500)
> 10.101.244.1.443 > 10.101.112.251.49619: Flags [.], cksum 0x8533
> (correct), seq 1993:3453, ack 1, win 256, length 1460
>
> 22:12:46.073960 IP (tos 0x0, ttl 124, id 27453, offset 0, flags [DF],
> proto TCP (6), length 1500)
> 10.101.244.1.443 > 10.101.112.251.49619: Flags [.], cksum 0x9ce0
> (correct), seq 3453:4913, ack 1, win 256, length 1460
>
> 22:12:46.073968 IP (tos 0x0, ttl 124, id 27454, offset 0, flags [DF],
> proto TCP (6), length 929)
> 10.101.244.1.443 > 10.101.112.251.49619: Flags [P.], cksum 0x1110
> (correct), seq 4913:5802, ack 1, win 256, length 889
>
>
> On 05/09/2016 12:15 PM, Jim Hranicky wrote:
>> Created. > > Jim > > On 05/09/2016 12:07 PM, Alfredo Cardigliano wrote: >> Hi
> Jim >> it seems to be working in our lab on the same OS: > > [...] > > >
>> _______________________________________________ > Ntop-misc mailing
> list > [email protected] >
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> --
> --
> =======================
> Joseph Gresham Jr.
> [email protected]
> Network Security Engineer
> Onshore Networks
> 312-850-5200 x.116 Desk
> 312-208-1887 Cell
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
