This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hello,

I have the two TCP packets in my stream with the following payload:

00 00 00 0b 06 ff 82 00 00 00 01 00 00 00 00

00 00 00 0b 07 ff 82 00 00 00 01 78 bf 88 b0

I want to capture both of them with the following capture filter: tcp port 4500 and tcp[26:1]==0x82 and (tcp[24:1]==06 or tcp[24:1]==07)

The problem is, the first packet with 06 is captured, the second is not.

If I capture everything and apply the following display filter it works: tcp.port==4500 && tcp[26:1]==0x82 && (tcp[24]==06 || tcp[24]==07)

I don't understand it. In my opinion the capture filter is correct. I'm running the current version of wireshark and winpcap

asked 05 Nov '15, 21:57

Sputnik24's gravatar image

Sputnik24
6112
accept rate: 0%

edited 10 Nov '15, 05:40

grahamb's gravatar image

grahamb ♦
19.8k330206

They look oke, but are there (varying) TCP options involved? The index into TCP doesn't necessarily land you on your payload bytes then.

(06 Nov '15, 00:43) Jaap ♦

Length is always the same. Here are the full packets:

0010020e001fc22697fdbd8008004500003765c040008006f1cea9fe500aa9feff2ac0791194cfc8cac3ea530c4850183ff3df5700000000000b06ff820000000100000000

c22697fdbd800010020e001f080045000037d9ef40004006bd9fa9feff2aa9fe500a1194c079ea530c48cfc8cad250180b58a2e200000000000b07ff820000000178bf88b0

(06 Nov '15, 00:47) Sputnik24

Nope, no IP or TCP options.

If the capture filter in Wireshark has a "Compile selected BPFs" or "Compile BPFs" button next to it, if you click on that button when your capture filter is typed in, it should pop up a window with some cryptic text in it (well, cryptic unless you're a BPF geek). Please copy the text from that window and paste it in a comment. (Please don't post a screenshot, just copy and paste the text - that's all we want.)

(06 Nov '15, 14:36) Guy Harris ♦♦

I've already looked at the compiled BPF code (assuming ethernet), and if you read assembly language it's not that hard to follow ;)

(000) ldh      [12]
(001) jeq      #0x86dd          jt 18   jf 2
(002) jeq      #0x800           jt 3    jf 18
(003) ldb      [23]
(004) jeq      #0x6             jt 5    jf 18
(005) ldh      [20]
(006) jset     #0x1fff          jt 18   jf 7
(007) ldxb     4*([14]&0xf)
(008) ldh      [x + 14]
(009) jeq      #0x1194          jt 12   jf 10
(010) ldh      [x + 16]
(011) jeq      #0x1194          jt 12   jf 18
(012) ldb      [x + 40]
(013) jeq      #0x82            jt 14   jf 18
(014) ldb      [x + 38]
(015) jeq      #0x6             jt 17   jf 16
(016) jeq      #0x7             jt 17   jf 18
(017) ret      #262144
(018) ret      #0

It looks for IPv4, looks for TCP, gets the IPv4 header length, looks for source or destination port 4500, then looks for the respective databytes. Couldn't see a flaw in that, other than TCP options taking space.

Hope he can paste his.

(07 Nov '15, 14:41) Jaap ♦

That's what libpcap generated on your machine; perhaps there's a code generator bug in the libpcap/WInPcap on the original poster's machine. (And, yes, both packets have what appear to be Ethernet headers.)

(07 Nov '15, 17:35) Guy Harris ♦♦

Indeed, so OP please post your compiled BPF.

(08 Nov '15, 01:21) Jaap ♦

Hi,

thanks a lot and sorry for the late response. Before I post the BPF code here some new infos:

We have a XenServer hosting 4 VMs with Windows 7. They are using virtual NICs linked to real NICs of the Server. The described error exists there. We have additionally single PCs running Windows 7 and a similiar hardware environment. Here, the capture filter works.

Filter: tcp port 4500 and tcp[20:4]==0x0000000B and (tcp[24:1]==06 or tcp[24:1]==07) and tcp[26:1]==0x82

BPF code, looks the same at VM and PC:

(000) ldh      [12]
(001) jeq      #0x86dd          jt 20   jf 2
(002) jeq      #0x800           jt 3    jf 20
(003) ldb      [23]
(004) jeq      #0x6             jt 5    jf 20
(005) ldh      [20]
(006) jset     #0x1fff          jt 20   jf 7
(007) ldxb     4*([14]&0xf)
(008) ldh      [x + 14]
(009) jeq      #0x1194          jt 12   jf 10
(010) ldh      [x + 16]
(011) jeq      #0x1194          jt 12   jf 20
(012) ld       [x + 34]
(013) jeq      #0xb             jt 14   jf 20
(014) ldb      [x + 38]
(015) jeq      #0x6             jt 17   jf 16
(016) jeq      #0x7             jt 17   jf 20
(017) ldb      [x + 40]
(018) jeq      #0x82            jt 19   jf 20
(019) ret      #65535
(020) ret      #0

It looks like a problem of VM, but without filter I can see the frame. Why doesn't Wireshark capture it at the VM? Weird.

(09 Nov '15, 23:27) Sputnik24

You're not very specific on where you capture the network traffic: In the Win7 guest, in the Xen host on the VIF, on the PIF, or on a bridge maybe?

(10 Nov '15, 03:51) Jaap ♦
showing 5 of 8 show 3 more comments
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×184
×165

question asked: 05 Nov '15, 21:57

question was seen: 1,105 times

last updated: 10 Nov '15, 05:40

p​o​w​e​r​e​d by O​S​Q​A