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://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
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
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:
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
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
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
Guy Harris changed:
What|Removed |Added
Hardware|x86-64 |All
OS|Ubuntu
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
>
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
>
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}
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
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.
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
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
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
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
Guy Harris changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
Chuck Craft changed:
What|Removed |Added
CC||bubbas...@gmail.com
--- Comment #9
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
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
Jaap Keuter changed:
What|Removed |Added
CC||g...@alum.mit.edu
--- Comment #7
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://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
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
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
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
Christopher Maynard changed:
What|Removed |Added
Component|GTK+ UI |Dumpcap
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,
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16116
michal.pec...@telekom.sk changed:
What|Removed |Added
Hardware|x86 |x86-64
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
29 matches
Mail list logo
