 | 1 | initial version |
If the packets on the client side contain a vlan tag, all offsets will be off by 4. You can compensate with adding "vlan and ..." in front of your filter (resulting in: vlan and tcp [0x2d: 2] == 0x032f and tcp [0x25: 1] == 0x05).
Please note that using a direct offset from the start of the TCP header will only work if all the frames have no (or the same length) of TCP options. It is better to read the TCP data offset and use that in your filter. The TCP data offset can be calculated with tcp[12]&0xf0)>>2, so your filter will become tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05.
So to make the BPF filter both vlan and TCP option length agnostic, you can use:
( tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05 ) or (vlan and ( tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05 ))
If that does not work for you, could you provide a capture file of the client side so I can check what makes the offsets different there?
`
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.