[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #26 from Christopher Maynard --- (In reply to Guy Harris from comment #25) > Not just VLAN names, but, yes, it should show the negative offsets > symbolically. File an issue at > https://github.com/the-tcpdump-group/libpcap/issues (or a pull request at > https://github.com/the-tcpdump-group/libpcap/pulls). Libpcap issue #861 has been filed: https://github.com/the-tcpdump-group/libpcap/issues/861 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #25 from Guy Harris --- (In reply to Christopher Maynard from comment #24) > Thanks for this information (and what followed, omitted for brevity). This > has been an education for me, Being a libpcap core developer has been a bit of an education for me, especially about the innards of 1) Linux sockets and 2) Linux PF_PACKET sockets. :-) > It would seem that the defined > offsets are not correlated to their offset position within the sk_buff > struct. They're not, they're just magic numbers used in a switch statement. > Also, since most of us probably won't memorize which negative offset > corresponds to which field, in order to help make the BPF code more readable > and understandable, would it help if libpcap, instead of displaying BPF code > using negative offsets would take a page out of bpfc > (http://man7.org/linux/man-pages/man8/bpfc.8.html) and display them using > vlan names instead? Not just VLAN names, but, yes, it should show the negative offsets symbolically. File an issue at https://github.com/the-tcpdump-group/libpcap/issues (or a pull request at https://github.com/the-tcpdump-group/libpcap/pulls). -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
--- Comment #24 from Christopher Maynard ---
(In reply to Guy Harris from comment #13)
> (In reply to michal.pecuch from comment #3)
> > dumpcap -f "vlan 545" -d
> > Capturing on 'enp0s31f6'
> > (000) ldb [-4048]
> > (001) jeq #0x1 jt 2jf 5
>
> In the Magical World of Linux Networking, the outermost VLAN tags are either
> not put into the raw packet data in the "skbuff" (kernel data structure for
> packet data on a socket) or are removed from it, with the information in the
> absent VLAN tag being stored in fields in the skbuff.
>
> This means that a BPF filter for a live capture can't test fields in the
> VLAN tag by looking at packet data; instead, it needs to use Special Magical
> Negative Packet Offsets to request that the kernel's BPF interpreter/JIT
> compiler fetch data from the skbuff fields.
>
> -4048 is -4096 + 48, or SKF_AD_OFF + SKF_AD_VLAN_TAG_PRESENT, meaning "fetch
> the Special Magical Field containing an indication of whether this packet
> *has* a VLAN tag or not - it's 0 if it doesn't and 1 if it does.
Thanks for this information (and what followed, omitted for brevity). This has
been an education for me, as it wasn't at all obvious what these negative
offsets meant.
I'm curious about the values of the offsets though. I see them defined in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/filter.h?h=v5.3.5#n60,
but the offsets don't seem to match the sk_buff fields as defined in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/bpf.h?h=v5.3.5#n2931.
For example, __sk_buff begins as follows:
struct __sk_buff {
__u32 len;
__u32 pkt_type;
__u32 mark;
__u32 queue_mapping;
__u32 protocol;
__u32 vlan_present;
...
... so I'd expect the vlan_present offset to be at offset 20 and yet we have:
#define SKF_AD_VLAN_TAG_PRESENT 48
Obviously, I'm missing something here. It would seem that the defined offsets
are not correlated to their offset position within the sk_buff struct.
Also, since most of us probably won't memorize which negative offset
corresponds to which field, in order to help make the BPF code more readable
and understandable, would it help if libpcap, instead of displaying BPF code
using negative offsets would take a page out of bpfc
(http://man7.org/linux/man-pages/man8/bpfc.8.html) and display them using vlan
names instead?
For example, instead of displaying:
(000) ldb [-4048]
.. it instead displays one of these (assuming my use of these are correct):
(000) ldb [vlanp]
(000) ldb #vlanp
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list
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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #23 from michal.pec...@telekom.sk --- Tahnks for help. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #22 from Guy Harris --- (In reply to Guy Harris from comment #21) > At least as I read the BPF interpreter and other parts of the networking > stack in the 3.10.71 kernel, the load of the 16-bit value at an "offset" of > -4052 will fetch a value with the PCP and VID fields, so the masking has to > be done. I'll fix the libpcap code to do so, even though the optimizer > accidentally makes the code OK. That's already fixed, and the fix is in 1.9.1. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #21 from Guy Harris --- (In reply to Guy Harris from comment #15) > So maybe the packets in question didn't have the VLAN tag removed, and the > 1.9.x code will handle them. Or maybe, as a side effect of the code path for handling non-tag-removed packets being added, the generated code now masks the PCP field out when comparing with the specified VLAN tag value, so even if the PCP field is non-zero, the match will be done correctly. At least as I read the BPF interpreter and other parts of the networking stack in the 3.10.71 kernel, the load of the 16-bit value at an "offset" of -4052 will fetch a value with the PCP and VID fields, so the masking has to be done. I'll fix the libpcap code to do so, even though the optimizer accidentally makes the code OK. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 Guy Harris changed: What|Removed |Added Hardware|x86-64 |All OS|Ubuntu |Linux -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #20 from Guy Harris --- (In reply to Guy Harris from comment #13) > In the Magical World of Linux Networking, the outermost VLAN tags are either > not put into the raw packet data in the "skbuff" (kernel data structure for > packet data on a socket) or are removed from it, with the information in the > absent VLAN tag being stored in fields in the skbuff. > > This means that a BPF filter for a live capture can't test fields in the > VLAN tag by looking at packet data; instead, it needs to use Special Magical > Negative Packet Offsets to request that the kernel's BPF interpreter/JIT > compiler fetch data from the skbuff fields. It also means that, in order for the code using libpcap to see the packet as it was on the wire (other than perhaps being truncated by a snapshot length having been specified at capture time), libpcap has to move the link-layer header to make room for the outermost VLAN tag and insert that tag into the raw packet data. libpcap does that, so capturing shouldn't show packets with a tag removed if, in fact, it was removed *and* the capture mechanism indicates that. (On some platforms, it might get removed with no indication to libpcap that this happened.) -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #19 from Guy Harris --- (In reply to michal.pecuch from comment #16) > I did instal that 1.9.1 > ./configure > make > sudo make install > > Is there a nice way how to link this new version to be used by tcpdump and > wireshark? Or check firstly the /usr/locla/lib folder for it.. ls -l /usr/local/lib/libpcap* Also do ls -l /usr/lib/libpcap* to find out the pathname for which programs linked with libpcap will probably be looking. > For wireshark install I use apt-get and I didn't find a way how to link it > during install. That's because a dpkg contains an *already-linked* executable, so there's nothing *to* link. It is, however, probably an executable that's dynamically linked with libpcap, so only half of the linking process has already been done; the remainder of the linking process is done by the run-time linker (ld.so) at startup time, and it *might* be possible to get that to load the new version of libpcap. Note that you'll probably have to run "sudo ldconfig" to tell the run-time linker about the newly-installed libpcap. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
--- Comment #18 from Guy Harris ---
(In reply to michal.pecuch from comment #17)
> I have manage to install new version of tcpdump which seems to work beter
> now but the dumpcap seams unaffected.
Unless
ldd {path-to-dumpcap}
reports the pathname of the newly-installed libpcap, dumpcap is still picking
up the system libpcap and thus will not change its behavior.
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list
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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #17 from michal.pec...@telekom.sk --- (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 2jf 5 > (002) ldb [-4052] > (003) jeq #0x221 jt 4jf 5 > (004) ret #262144 > (005) ret #0 > # > > 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 6jf 2 > (002) ldh [12] > (003) jeq #0x8100 jt 6jf 4 > (004) jeq #0x88a8 jt 6jf 5 > (005) jeq #0x9100 jt 6jf 14 > (006) ldb [-4048] > (007) jeq #0x1 jt 8jf 10 > (008) ldb [-4052] > (009) ja 11 > (010) ldh [14] > (011) and #0xfff > (012) jeq #0x221 jt 13 jf 14 > (013) ret #262144 > (014) ret #0 > root@kali:~# I have manage to install new version of tcpdump which seems to work beter now but the dumpcap seams unaffected. user@tacmerak:~$ dumpcap -f "vlan 200" -d Capturing on 'enp0s31f6' (000) ldb [-4048] (001) jeq #0x1 jt 2jf 5 (002) ldb [-4052] (003) jeq #0xc8jt 4jf 5 (004) ret #262144 (005) ret #0 user@tacmerak:~$ tcpdump --version tcpdump version 4.9.3 libpcap version 1.9.1 (with TPACKET_V3) user@tacmerak:~$ sudo tcpdump -d "vlan 545" (000) ldb [-4048] (001) jeq #0x1 jt 6jf 2 (002) ldh [12] (003) jeq #0x8100 jt 6jf 4 (004) jeq #0x88a8 jt 6jf 5 (005) jeq #0x9100 jt 6jf 14 (006) ldb [-4048] (007) jeq #0x1 jt 8jf 10 (008) ldb [-4052] (009) ja 11 (010) ldh [14] (011) and #0xfff (012) jeq #0x221 jt 13 jf 14 (013) ret #262144 (014) ret #0 user@tacmerak:~$ -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #16 from michal.pec...@telekom.sk --- (In reply to Guy Harris from comment #11) > (In reply to michal.pecuch from comment #5) > > It is the same on all interfaces. > > > > For some reason I am unable to compile libpcap 1.9.1. No errors but still > > only 1.8.1 available. > > What do you mean by "unable ... No errors"? > > Do you mean you download the 1.9.1 source tarball, unpack it, run > ./configure, and run "make", and you get no errors? > > And what do you mean by "only 1.8.1 available"? Compiling 1.9.1 won't > automatically make Wireshark use it; you would have to, at minimum, do "make > install", *and* the dynamically-linked Wireshark would have to be looking > for it in /usr/local/lib before /usr/lib, with the name under which it's > installed in /usr/local/lib, to find 1.9.1 rather than the 1.8.1 that you > presumably have installed as the system libpcap. I did instal that 1.9.1 ./configure make sudo make install Is there a nice way how to link this new version to be used by tcpdump and wireshark? Or check firstly the /usr/locla/lib folder for it.. For wireshark install I use apt-get and I didn't find a way how to link it during install. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #15 from Guy Harris --- (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 2jf 5 > (002) ldb [-4052] > (003) jeq #0x221 jt 4jf 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 6jf 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 6jf 4 > (004) jeq #0x88a8 jt 6jf 5 > (005) jeq #0x9100 jt 6jf 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 8jf 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 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 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #14 from Guy Harris --- (In reply to Guy Harris from comment #13) > I.e., that's testing whether the packet has a VLAN tag. Or, rather, it's testing whether the packet has a VLAN tag *that's not present, at that point, in the packet data, because it wasn't inserted or it was removed*". If the packet hasn't had the VLAN tag removed by the adapter or by the networking stack, that test *won't* match. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #13 from Guy Harris --- (In reply to michal.pecuch from comment #3) > dumpcap -f "vlan 545" -d > Capturing on 'enp0s31f6' > (000) ldb [-4048] > (001) jeq #0x1 jt 2 jf 5 In the Magical World of Linux Networking, the outermost VLAN tags are either not put into the raw packet data in the "skbuff" (kernel data structure for packet data on a socket) or are removed from it, with the information in the absent VLAN tag being stored in fields in the skbuff. This means that a BPF filter for a live capture can't test fields in the VLAN tag by looking at packet data; instead, it needs to use Special Magical Negative Packet Offsets to request that the kernel's BPF interpreter/JIT compiler fetch data from the skbuff fields. -4048 is -4096 + 48, or SKF_AD_OFF + SKF_AD_VLAN_TAG_PRESENT, meaning "fetch the Special Magical Field containing an indication of whether this packet *has* a VLAN tag or not - it's 0 if it doesn't and 1 if it does. I.e., that's testing whether the packet has a VLAN tag. If it does, the program jumps to the instruction at 2, otherwise it jumps to the instruction at 5. > (002) ldb [-4052] > (003) jeq #0x221 jt 4 jf 5 -4052 is -4096 + 44, or SKF_AD_OFF + SKF_AD_VLAN_TAG, meaning "fetch the Special Magical Field containing the VLAN tag". So that's comparing the VLAN tag against 0x221, or 545, jumping to the instruction at 4 if the VLAN tag is 545 and to the instruction at 5 if it isn't. > (004) ret #262144 Because the program is returning a non-zero value, that says "this packet matches, so return 262144 bytes of the packet (which is the way we say "all the data in the packet"). > (005) ret #0 Because the program is returning a zero value, that says "this packet *doesn't* match". So if the packet has a VLAN tag and it's 545, the packet matches, otherwise it doesn't. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 Guy Harris changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG --- Comment #12 from Guy Harris --- (In reply to Chuck Craft from comment #9) > Can you load the 1.9.0 package? Looks like a big improvement. If by "the 1.9.0 package" you mean the source package from tcpdump.org, the current source package is 1.9.1, which also includes a fix for this issue: https://github.com/the-tcpdump-group/libpcap/issues/461 which reports the problem as VLAN filtering does only work if the priority field in the dot1p header is cleared. If the field is non-null, vlan filtering doesn't work (read: doesn't match). In any case, if the wrong BPF code is being generated, that's a libpcap bug, not a Wireshark bug. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #11 from Guy Harris --- (In reply to michal.pecuch from comment #5) > It is the same on all interfaces. > > For some reason I am unable to compile libpcap 1.9.1. No errors but still > only 1.8.1 available. What do you mean by "unable ... No errors"? Do you mean you download the 1.9.1 source tarball, unpack it, run ./configure, and run "make", and you get no errors? And what do you mean by "only 1.8.1 available"? Compiling 1.9.1 won't automatically make Wireshark use it; you would have to, at minimum, do "make install", *and* the dynamically-linked Wireshark would have to be looking for it in /usr/local/lib before /usr/lib, with the name under which it's installed in /usr/local/lib, to find 1.9.1 rather than the 1.8.1 that you presumably have installed as the system libpcap. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #10 from Chuck Craft --- On my debian system, the man page for "pcap-filter" discusses byte offsets. Look in section on expressions: expr relop expr "To access data inside the packet, use the following syntax: proto [ expr : size ]" -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 Chuck Craft changed: What|Removed |Added CC||bubbas...@gmail.com --- Comment #9 from Chuck Craft --- 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 2jf 5 (002) ldb [-4052] (003) jeq #0x221 jt 4jf 5 (004) ret #262144 (005) ret #0 # 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 6jf 2 (002) ldh [12] (003) jeq #0x8100 jt 6jf 4 (004) jeq #0x88a8 jt 6jf 5 (005) jeq #0x9100 jt 6jf 14 (006) ldb [-4048] (007) jeq #0x1 jt 8jf 10 (008) ldb [-4052] (009) ja 11 (010) ldh [14] (011) and #0xfff (012) jeq #0x221 jt 13 jf 14 (013) ret #262144 (014) ret #0 root@kali:~# -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #8 from michal.pec...@telekom.sk --- It is some onboard ethernet port on Dell Precision 7520 it should be Intel I219-LM network controller. That documentation is not with the ether expresions but rather some abbreviations and aliases rather then exact terms. I would like more info about this "(ether[12:2]=0x8100) and (ether[14:2]&0xfff=545)" rather then this "vlan 545" if it exists. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 Jaap Keuter changed: What|Removed |Added CC||g...@alum.mit.edu --- Comment #7 from Jaap Keuter --- (In reply to michal.pecuch from comment #3) > dumpcap -f "vlan 545" -d > Capturing on 'enp0s31f6' Could you elaborate on the type of interface enp0s31f6 is? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #6 from Christopher Maynard --- (In reply to michal.pecuch from comment #5) > Is there some good documentation for the filters in this format? I would say the authoritative source for capture filter syntax would be at: https://www.tcpdump.org/manpages/pcap-filter.7.html > Thank you. You're welcome. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #5 from michal.pec...@telekom.sk --- It is the same on all interfaces. For some reason I am unable to compile libpcap 1.9.1. No errors but still only 1.8.1 available. That workaround seems better. I get the same BPF code as you. I will try it on some lines to see if it works for me. Is there some good documentation for the filters in this format? Thank you. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #4 from Christopher Maynard --- (In reply to michal.pecuch from comment #3) > dumpcap -f "vlan 545" -d > Capturing on 'enp0s31f6' Do you get the same BPF for all interfaces? > This seems off as the first ethertype should be #0x8100. Or am I missing > something? Definitely looks wrong to me. As a work-around, you could try 'dumpcap -f "(ether[12:2]=0x8100) and (ether[14:2]&0xfff=545)" -d' instead, which produces the exact same BPF code on my system as it did with the previous "vlan 545" capture filter. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #3 from michal.pec...@telekom.sk --- dumpcap -f "vlan 545" -d Capturing on 'enp0s31f6' (000) ldb [-4048] (001) jeq #0x1 jt 2jf 5 (002) ldb [-4052] (003) jeq #0x221 jt 4jf 5 (004) ret #262144 (005) ret #0 This seems off as the first ethertype should be #0x8100. Or am I missing something? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 Christopher Maynard changed: What|Removed |Added Component|GTK+ UI |Dumpcap Severity|Major |Normal -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #2 from Christopher Maynard --- (In reply to michal.pecuch from comment #0) > LC_IDENTIFICATION=sk_SK.UTF-8, with libpcap version 1.8.1 It's possible this is a libpcap bug. You could try upgrading to the latest version, currently 1.9.1, to see if this problem has been fixed? Download from: https://www.tcpdump.org/. There are a couple of VLAN-related issues mentioned in the changelog; it's possible that one of those fixed this issue. See: https://www.tcpdump.org/libpcap-changes.txt > On Ubuntu 19.04 on two similar computers. > When capturing live data using capturing filter to filter specific vlan > (vlan 545) for some reason only ethernet frames with CoS 0 are captured. > Frames with the same vlan tag and CoS 4 are not captured by this filter. > Without capturing vlan filter all frames are captured. Have you looked at the resulting BPF code for the "vlan 545" capture filter to see if it's sane? Running 'dumpcap -f "vlan 545" -d' on my system yields the following, which looks correct to me: Capturing on 'foo' (000) ldh [12] (001) jeq #0x8100 jt 2jf 6 (002) ldh [14] (003) and #0xfff (004) jeq #0x221 jt 5jf 6 (005) ret #65535 (006) ret #0 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 michal.pec...@telekom.sk changed: What|Removed |Added Hardware|x86 |x86-64 OS|Windows 10 |Ubuntu -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
[Wireshark-bugs] [Bug 16116] when using vlan capturing filter priority frames dropped
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116 --- Comment #1 from michal.pec...@telekom.sk --- Created attachment 17395 --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17395=edit frames captured without capturing vlan filter -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list 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
