Problem when Filtering Vlan Id #1169
Comments
|
This might be a duplicate of an earlier bug specific to Linux VLAN handling. Does the problem reproduce when you filter packet from a file rather than from a live capture? Does it reproduce using libpcap 1.10.3? |
|
I ran the tests here, updated it, luckily I had the latest versions in the backports repository, but unfortunately it didn't have a positive effect. However, the file test gave a positive result, I first generated a file like this:
and then I used the following filtering:
the result was this: Current versions are: |
|
Any progress on this issue? |
|
At the time there are some other problems requiring attention, so this may take time to resolve. Please have patience. Meanwhile you are welcome to provide exact steps to reproduce the problem (Linux distribution and version, network interface configuration, whether it reproduces using the current libpcap master branch). |
|
I left the procedure I did very detailed in the history of the problem report, anyone can reproduce it. Anyway, we wait and thank you for your attention. |
|
During a live capture, the Linux kernel stores the VLAN tag information somewhere else, not in the packet data. libpcap does know about this quirk and builds the filter appropriately if you use the All of your observations (e.g., when using position 12...he is apparently "looking" at position 16) are consistent with this Linux kernel behavior. One idea - that may not be helpful - is that you could request that tcpdump add an option to not load the filter into the kernel, and only do userland filtering. That way, the filter could skip the kernel quirks altogether (and also of course lose the speed advantage of running in the kernel). |
|
Hi, @fenner I even looked for a way to make tcpdump not load this filter, without success so far. |
It turns out to be more complex than I remembered: you need to introduce a mechanism in libpcap to skip trying to install the filter in the kernel (in |
I just came across the following situation: if I try to filter a certain vlan using this type of filter, it doesn't work:
tcpdump -i ens160 'ether[14:2] & 0x0fff == 1000'My goal is to filter vlan id 1000 (and a few more), but for now, getting 1000 would help me a lot.
The hex content of the packet is:
In my tests, using the command "tcpdump -XX -c 1 -i ens160 'ether[11] == 0x89'" I noticed that up to position 11 it manages to apply the filter perfectly, as can be seen below:
However, when advancing to position 12 ("tcpdump -XX -c 1 -i ens160 'ether[12] == 0x81'"), it does not work:
What I noticed is as if he "ignored" the information between position 12 and 15, and, in fact, when using position 12 ("tcpdump -XX -i ens160 -c 1 'ether[12:2] == 0x0800'"), he is apparently "looking" at position 16:
I'm using Debian 11, and the application versions are: tcpdump, 4.99.0 and libpcap, 1.10.0 (with TPACKET_V3).
The text was updated successfully, but these errors were encountered: