Ask Your Question
0

Capture Filters - What am I doing wrong?

asked 2018-11-13 21:43:20 +0000

itangir gravatar image

updated 2018-11-14 03:11:05 +0000

Guys, I know I'm not the sharpest tool in the crayon box but capture filters are really hanging me up from some constructive monitoring. I have a port mirror setup on a Procurve uplink port going into yonder Windows 10 Wireshark computer. Things seem to work fine up until I try to use capture filters.

Here are a few examples:

Capture filter: vlan 70 or vlan 90
Expected behavior: Capture only frames with VLAN ID matching either 70 or 90
Actual behavior: Only VLAN 70 frames are captured
Sanity check: Captured without a filter and verified with a display filter that both can be captured, filtered

Capture filter: icmp
Expected behavior: Show pings, replies, and other ICMP traffic
Actual behavior: Ping requests are captured but replies are not
Sanity check: Capturing without a filter yields both requests and replies

Capture filter: not ip
Expected behavior: Capture only ARP, STP, and other L2 stuff
Actual behavior: TCP and UDP as far as the eye can see
Sanity check: Am insane

Hope someone can elucidate some of the troubles I'm having with getting some desired captures.

Edit1: Also, I have the latest Wireshark and winPcap versions.
Edit2: Replaced "show(n)" with "capture(d)" where appropriate to be less confusing
Edit3: All traffic I'm trying to monitor is IPv4 and VLANs.

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted
2

answered 2018-11-14 18:10:50 +0000

cmaynard gravatar image

updated 2018-11-14 18:44:42 +0000

For capturing multiple vlans, you can use a capture filter such as this:

ether proto 0x8100 and (((ether[14:2] & 0x0fff) = 70) or ((ether[14:2] & 0x0fff) = 90))

You can verify the resulting BPF code using dumpcap's -d option, for example:

dumpcap -i eth0 -d -f "ether proto 0x8100 and (((ether[14:2] & 0x0fff) = 70) or ((ether[14:2] & 0x0fff) = 90))"
Capturing on 'eth0'
(000) ldh      [12]
(001) jeq      #0x8100          jt 2    jf 7
(002) ldh      [14]
(003) and      #0xfff
(004) jeq      #0x46            jt 6    jf 5
(005) jeq      #0x5a            jt 6    jf 7
(006) ret      #262144
(007) ret      #0

If you want to capture all ICMP traffic, whether the ICMP traffic is VLAN-tagged or not, then you should be able to use a filter such as "icmp or (vlan and icmp)" Here's the sample BPF code:

dumpcap -i eth0 -d -f "icmp or (vlan and icmp)"
Capturing on 'eth0'
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 4
(002) ldb      [23]
(003) jeq      #0x1             jt 10   jf 11
(004) jeq      #0x8100          jt 6    jf 5
(005) jeq      #0x9100          jt 6    jf 11
(006) ldh      [16]
(007) jeq      #0x800           jt 8    jf 11
(008) ldb      [27]
(009) jeq      #0x1             jt 10   jf 11
(010) ret      #262144
(011) ret      #0

If you want to exclude IP traffic, whether the IP traffic is VLAN-tagged or not, then you should be able to use a filter such as "not (ip or (vlan and ip))". Again, here's the sample BPF code:

dumpcap -i eth0 -d -f "not (ip or (vlan and ip))"
Capturing on 'eth0'
(000) ldh      [12]
(001) jeq      #0x800           jt 6    jf 2
(002) jeq      #0x8100          jt 4    jf 3
(003) jeq      #0x9100          jt 4    jf 7
(004) ldh      [16]
(005) jeq      #0x800           jt 6    jf 7
(006) ret      #0
(007) ret      #262144

NOTE The -d output may vary a bit with respect to the VLAN TPIDs. Notice in the last 2 examples the additional check for 0x9100. On my Windows machine running dumpcap 2.6.2 with Winpcap 4.1.3, 0x9100 is not checked, but with dumpcap 1.12.13 and libpcap 1.4.0, it is checked. Modify your filter if needed or upgrade your version of dumpcap, libpcap, WinPcap or npcap as desired.

edit flag offensive delete link more

Comments

For reference, using Npcap 0.99-r7, I get the 0x9100 check and an additional check for 0x88a8:

PS> & 'C:\Program Files\Wireshark\dumpcap.exe' -i 8 -d -f "not (ip or(vlan and ip))"
Capturing on 'Ethernet'
(000) ldh      [12]
(001) jeq      #0x800           jt 7    jf 2
(002) jeq      #0x8100          jt 5    jf 3
(003) jeq      #0x88a8          jt 5    jf 4
(004) jeq      #0x9100          jt 5    jf 8
(005) ldh      [16]
(006) jeq      #0x800           jt 7    jf 8
(007) ret      #0
(008) ret      #262144
grahamb gravatar imagegrahamb ( 2018-11-14 18:38:24 +0000 )edit

0x88a8 ? Cool, finally proper support for provider bridging.

Jaap gravatar imageJaap ( 2018-11-15 07:41:56 +0000 )edit

PS: You can also do this from the capture options dialog in Wireshark. Select the interface, enter the filter and click 'Compile BPFs'.

Jaap gravatar imageJaap ( 2018-11-15 07:45:32 +0000 )edit
0

answered 2018-11-14 00:00:58 +0000

Guy Harris gravatar image

What am I doing wrong?

Trying to filter traffic on a network with VLANs.

vlan 70 or vlan 90

Unfortunately, "vlan" is handled in a fashion that causes all filters after a "vlan N" filter to assume the packet is already in a VLAN, so the checks affect the header inside the VLAN header.

I.e., it means that the "vlan 90" test doesn't test the outer VLAN header, it tests a VLAN header inside the "vlan 70" header.

Yes, this is a libpcap/WinPcap/Npcap bug.

Unfortunately, there's no easy workaround.

icmp

Are the replies going over a VLAN and the requests not going over a VLAN? If so, you need to do icmp or (vlan and icmp). More of the pain from the way "vlan" is handled.

not ip

Is the IP traffic you're seeing either 1) IPv6 traffic or 2) VLAN traffic?

If it's IPv6 traffic, you need not ip and not ip6.

If it's VLAN traffic, I'm not sure there's a workaround.

edit flag offensive delete link more

Comments

Addendum: All of this traffic is basically VLAN (except where untagged, etc.) and IPv4.

Are you saying Wireshark is ill-suited for capturing on enterprise traffic (re: vlans)? Or just filtering it at capture? Is there some other software that I should be looking into for tasks such as these?

Hmm, the ping request is tagged on VLAN 90 but the reply does not have VLAN information on it. I guess that makes sense since the monitored port is untagged for that VLAN.

I was momentarily stymied once again when icmp or (icmp and vlan) did not show the replies. I re-examined your example and tried it as you actually stated icmp and (vlan and icmp) and that did work.

So that's pretty confusing... I'd definitely like to understand that better to not continue to be boggled by this behavior but don't necessarily want to burden you with ...(more)

itangir gravatar imageitangir ( 2018-11-14 03:04:40 +0000 )edit

I'm sure you meant, icmp or (vlan and icmp) and not icmp and (vlan and icmp), since the latter is an invalid capture filter and will be rejected:

dumpcap -i eth0 -d -f "icmp and (vlan and icmp)"
Capturing on 'eth0'
dumpcap: Invalid capture filter "icmp and (vlan and icmp)" for interface 'eth0'!

That string isn't a valid capture filter ().
See the User's Guide for a description of the capture filter syntax.

… or a more useful error message from tcpdump:

tcpdump -i eth0 -d "icmp and (vlan and icmp)"
tcpdump: expression rejects all packets
cmaynard gravatar imagecmaynard ( 2018-11-14 18:23:43 +0000 )edit

Yeah, meant to be "or" there. I guess I just have to be extra careful when filtering with the "vlan" primitive.

itangir gravatar imageitangir ( 2018-11-14 20:57:22 +0000 )edit

Caution should be exercised with not only the vlan primitive, but the mpls, pppoes and geneve primitives as well, since they all change the decoding offset, although the pcap-filter man page currently omits the amount of change for the latter 2 primitives.

cmaynard gravatar imagecmaynard ( 2018-11-14 21:15:56 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-11-13 21:43:20 +0000

Seen: 207 times

Last updated: Nov 14