Revision history [back]

Hi,

Wireshark 3.6.2 (Ubuntu 22.04.1 LTS) is not able to capture packets with the below filter -

(ether[len - 4:4] == 0x1d10c0da) and not (icmp or (vlan and icmp))

The packets are UDP with VLAN and have the pattern 0x1d10c0da at the end which should match the above capture filter, but they don't.

To investigate, I used dumpcap -d with the above filter

$ dumpcap -c 5 -i enp0s9 -f "(ether[len - 4:4] == 0x1d10c0da) and not (icmp or (vlan and icmp))" -d
Capturing on 'enp0s9'
(000) ld       #0x0
(001) st       M[4]
(002) ld       #pktlen
(003) sub      #4
(004) tax
(005) ld       [x + 0]
(006) st       M[2]
(007) ld       #0x1d10c0da
(008) st       M[3]
(009) ld       M[2]
(010) jeq      #0x1d10c0da      jt 11   jf 32
(011) ldh      [12]
(012) jeq      #0x800           jt 13   jf 15
(013) ldb      [23]
(014) jeq      #0x1             jt 32   jf 15
(015) ldb      [vlanp]
(016) jeq      #0x1             jt 25   jf 17
(017) ld       #0x1d10c0de
(018) st       M[3]
(019) ld       #0x4
(020) st       M[4]
(021) ldh      [12]
(022) jeq      #0x8100          jt 25   jf 23
(023) jeq      #0x88a8          jt 25   jf 24
(024) jeq      #0x9100          jt 25   jf 31
(025) ldx      M[4]
(026) ldh      [x + 12]
(027) jeq      #0x800           jt 28   jf 31
(028) ldx      M[3]
(029) ldb      [x + 23]
(030) jeq      #0x1             jt 32   jf 31
(031) ret      #262144
(032) ret      #0

All seems ok till we come post the vlanp (vlan present) check.

If I'm reading the instructions correctly, I think the problem is (017), (018) which stores 0x1d10c0de intoM[3] which is accessed by (028), (029).

Instruction (028) seems incorrect to me as (029) expects x to be 4 similar to (026).

tcpdump -d also generates the same bpf instructions. Trying --no-optimize with tcpdump has a similar error in the unoptimized code.

However, the Wireshark Capture Options | Compile BPFs seems to generate the correct BPF instructions -

(000) ld       #pktlen
(001) sub      #4
(002) tax      
(003) ld       [x + 0]
(004) jeq      #0x1d10c0da      jt 5    jf 17
(005) ldh      [12]
(006) jeq      #0x800           jt 7    jf 9
(007) ldb      [23]
(008) jeq      #0x1             jt 17   jf 16
(009) jeq      #0x8100          jt 12   jf 10
(010) jeq      #0x88a8          jt 12   jf 11
(011) jeq      #0x9100          jt 12   jf 16
(012) ldh      [16]
(013) jeq      #0x800           jt 14   jf 16
(014) ldb      [27]
(015) jeq      #0x1             jt 17   jf 16
(016) ret      #262144
(017) ret      #0

Does Wireshark Compile BPFs use a different BPF compiler than dumpcap? Since the instructions generated by dumpcap is same as tcpdump, I assume both of them use the libpcap pcap_compile()?

Is this a bug in the libpcap BPF compiler or am I reading the instructions incorrectly?

Thanks in advance, Srivats

Hi,

Wireshark 3.6.2 (Ubuntu 22.04.1 LTS) is not able to capture packets with the below filter -

(ether[len - 4:4] == 0x1d10c0da) and not (icmp or (vlan and icmp))

The packets are UDP with VLAN and have the pattern 0x1d10c0da at the end which should match the above capture filter, but they don't.

To investigate, I used dumpcap -d with the above filter

$ dumpcap -c 5 -i enp0s9 -f "(ether[len - 4:4] == 0x1d10c0da) and not (icmp or (vlan and icmp))" -d
Capturing on 'enp0s9'
(000) ld       #0x0
(001) st       M[4]
(002) ld       #pktlen
(003) sub      #4
(004) tax
(005) ld       [x + 0]
(006) st       M[2]
(007) ld       #0x1d10c0da
(008) st       M[3]
(009) ld       M[2]
(010) jeq      #0x1d10c0da      jt 11   jf 32
(011) ldh      [12]
(012) jeq      #0x800           jt 13   jf 15
(013) ldb      [23]
(014) jeq      #0x1             jt 32   jf 15
(015) ldb      [vlanp]
(016) jeq      #0x1             jt 25   jf 17
(017) ld       #0x1d10c0de
(018) st       M[3]
(019) ld       #0x4
(020) st       M[4]
(021) ldh      [12]
(022) jeq      #0x8100          jt 25   jf 23
(023) jeq      #0x88a8          jt 25   jf 24
(024) jeq      #0x9100          jt 25   jf 31
(025) ldx      M[4]
(026) ldh      [x + 12]
(027) jeq      #0x800           jt 28   jf 31
(028) ldx      M[3]
(029) ldb      [x + 23]
(030) jeq      #0x1             jt 32   jf 31
(031) ret      #262144
(032) ret      #0

All seems ok till we come post the vlanp (vlan present) check.

If I'm reading the instructions correctly, I think the problem is (017), (018) which stores 0x1d10c0de intoM[3] which is accessed by (028), (029).

Instruction (028) seems incorrect to me as (029) expects x to be 4 similar to (026).

tcpdump -d also generates the same bpf instructions. Trying --no-optimize with tcpdump has a similar error in the unoptimized code.

However, the Wireshark Capture Options | Compile BPFs seems to generate the correct BPF instructions -

(000) ld       #pktlen
(001) sub      #4
(002) tax      
(003) ld       [x + 0]
(004) jeq      #0x1d10c0da      jt 5    jf 17
(005) ldh      [12]
(006) jeq      #0x800           jt 7    jf 9
(007) ldb      [23]
(008) jeq      #0x1             jt 17   jf 16
(009) jeq      #0x8100          jt 12   jf 10
(010) jeq      #0x88a8          jt 12   jf 11
(011) jeq      #0x9100          jt 12   jf 16
(012) ldh      [16]
(013) jeq      #0x800           jt 14   jf 16
(014) ldb      [27]
(015) jeq      #0x1             jt 17   jf 16
(016) ret      #262144
(017) ret      #0

Does Wireshark Compile BPFs use a different BPF compiler than dumpcap? Since the instructions generated by dumpcap is same as tcpdump, I assume both of them use the libpcap pcap_compile()?

dumpcap version

$ dumpcap --version
Dumpcap (Wireshark) 3.6.2 (Git v3.6.2 packaged as 3.6.2-2)

Copyright 1998-2022 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) using GCC 11.2.0, with GLib 2.71.2, with zlib 1.2.11, with
libpcap, with POSIX capabilities (Linux), with libnl 3.

Running on Linux 5.15.0-60-generic, with Intel(R) Core(TM) i5-8350U CPU @
1.70GHz (with SSE4.2), with 3923 MB of physical memory, with GLib 2.72.1, with
zlib 1.2.11, with libpcap 1.10.1 (with TPACKET_V3), with LC_TYPE=C, binary
plugins supported (0 loaded).

tcpdump version

$ tcpdump --version
tcpdump version 4.99.1
libpcap version 1.10.1 (with TPACKET_V3)
OpenSSL 3.0.2 15 Mar 2022

Is this a bug in the libpcap BPF compiler or am I reading the instructions incorrectly?

Thanks in advance, Srivats