https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116

--- Comment #15 from Guy Harris <g...@alum.mit.edu> ---
(In reply to Chuck Craft from comment #9)
> Can you load the 1.9.0 package? Looks like a big improvement.
> 
> # tcpdump --version
> tcpdump version 4.9.2
> libpcap version 1.8.1
> OpenSSL 1.0.2s  28 May 2019
> # tcpdump -i lo -d "vlan 545"
> (000) ldb      [-4048]
> (001) jeq      #0x1             jt 2    jf 5
> (002) ldb      [-4052]
> (003) jeq      #0x221           jt 4    jf 5
> (004) ret      #262144
> (005) ret      #0

Works only if the packet's VLAN tag isn't present in the raw packet data.

> root@kali:~# tcpdump --version
> tcpdump version 4.9.3-PRE-GIT_2019_09_07
> libpcap version 1.9.0 (with TPACKET_V3)
> OpenSSL 1.1.1d  10 Sep 2019
> root@kali:~# tcpdump -i lo -d "vlan 545"
> (000) ldb      [-4048]
> (001) jeq      #0x1             jt 6    jf 2

OK, so for *this* version, if the packet doesn't have the VLAN tag stripped
out, the test doesn't fail - it tests whether the packet has a VLAN tag in the
normal location in the packet, which is what the ldh (loading a big-endian
16-bit quantity at an offset of 12 from the beginning of the packet, i.e. the
type/length field) and the three jeq's (testing that field value against three
types of tag) are doing.

> (002) ldh      [12]
> (003) jeq      #0x8100          jt 6    jf 4
> (004) jeq      #0x88a8          jt 6    jf 5
> (005) jeq      #0x9100          jt 6    jf 14

OK, now it's *again* testing the Special Magic Information.  I'm not sure why
the optimizer isn't cleaning this up, but....  (Perhaps it gets confused by
blocks that do tests for which the result doesn't have anything to do with
whether the packet matches or not, just how to do *subsequent* tests.  That's
not one of its strong points, probably because back when the BPF compiler was
originally written there weren't such tests generated.)

> (006) ldb      [-4048]
> (007) jeq      #0x1             jt 8    jf 10

OK, so if the VLAN tag was removed, it does this...

> (008) ldb      [-4052]
> (009) ja       11

...which loads the VLAN tag from the Special Magic Information and jumps to the
instruction at 14...

...and if the VLAN tag wasn't removed, it does this, which loads the first 16
bits of the VLAN tag...

> (010) ldh      [14]

...and now it's the common code, ANDing out the upper 4 bits of those 16 bits
and comparing them against 545.

> (011) and      #0xfff
> (012) jeq      #0x221           jt 13   jf 14
> (013) ret      #262144
> (014) ret      #0
> root@kali:~#

So maybe the packets in question didn't have the VLAN tag removed, and the
1.9.x code will handle them.

This short introduction to BPF and Linux peculiarities thereof is brought to
you by "PG&E might or might not shut off power to our area at midnight as a
safety precaution due to  high winds, so I want to get this out before we head
out to dinner, hoping the power outage doesn't mean the restaurant will close
early to shut things down".  If it's shut down, don't expect more from me on
this until they restore the power, which could take days.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to