Ask Your Question

Outgoing TCP Traffic not captured

asked 2019-04-05 10:24:03 +0000

Levi gravatar image

Hello everybody,

I have a weird problem. I capture TCP traffic without filters. Here, I see the outgoing and incoming messages. If I start capturing with a capture filter (tcp[offset] == value), only the incoming messages will be recorded. On the client side I do not see any data, on the server side I see that the transport has worked.

Does somebody has any idea? I think it's very strange.

thank you in advance

Wireshark version 3.0.0 Npcap 0.99 r-9

edit retag flag offensive close merge delete


The obvious conclusion is that your capture filter is excluding the outgoing traffic. Without a pcap (unfiltered) to examine we can't offer much help.

grahamb gravatar imagegrahamb ( 2019-04-05 10:27:14 +0000 )edit

Thank you for your quick reply. I have recorded a file, but unfortunately I can not attach it. My filter looks like this: tcp [0x2d: 2] == 0x032f and tcp [0x25: 1] == 0x05 as I said, on the server side, I see the traffic

Levi gravatar imageLevi ( 2019-04-05 10:50:18 +0000 )edit

You can save the capture file on a public share, e.g. Google Drive, DropBox etc., and then add a comment here with a link to the file.

grahamb gravatar imagegrahamb ( 2019-04-05 11:00:32 +0000 )edit

thanks for the tip, file is here ready

Levi gravatar imageLevi ( 2019-04-05 11:11:30 +0000 )edit

2 Answers

Sort by » oldest newest most voted

answered 2019-04-07 22:26:50 +0000

SYN-bit gravatar image

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?


edit flag offensive delete link more


I think there is a general problem reading the values ​​here. I can not read the first byte if I leave TCP, so I'm in the TPKT area. On the server side it can be read. With the right offset.

here is the file

Levi gravatar imageLevi ( 2019-04-08 07:06:26 +0000 )edit

I'm not sure I understand what you mean by "I can not read the first byte if I leave TCP, so I'm in the TPKT area.". The link you sent is the same as before and from the server side. If you'd like I can have a look at the traffic on the client side to see whether I can figure out a way to filter out what you need... If so, please supply the trace from the client side too.

SYN-bit gravatar imageSYN-bit ( 2019-04-10 22:00:08 +0000 )edit

answered 2019-04-05 11:54:18 +0000

grahamb gravatar image

The capture filter seems to be equivalent to the Wireshark display filter s7comm.param.item.db == 815 and s7comm.param.func == 0x05, which can't be used for capture filters as BPF syntax doesn't know about S7 over COTP over TPKT over TCP.

As you're using offsets from the start of TCP the accuracy of the filters depends on the consistency of the size of the TCP headers and the other layers, i.e. TPKT and COTP, I suspect there's something slightly different in the headers on the outgoing traffic that messes up the offsets.

By examination of the outgoing packets from an unfiltered capture you might be able to determine the different offsets required.

edit flag offensive delete link more


in an unfiltered capture I see the offset in the right place. Therefore, I suspect that he has another problem with it. Thank you for the quick answer, I'll test it piece by piece. If I find the solution, I will post it here

Levi gravatar imageLevi ( 2019-04-05 12:05:41 +0000 )edit

Was that capture filtered?

if I have converted the offsets to the correct protocol fields, there is only 1 packet in the capture that matches. I get an identical result if I use my equivalent display filter. I have no idea if there should be more.

The response to the request doesn't match the filter as it doesn't include the same fields as the request, in particular the s7comm.param.item.db field.

grahamb gravatar imagegrahamb ( 2019-04-05 12:24:55 +0000 )edit

That capture was unfiltered. 1 package would be correct in this case.

If I search the offset of the filter in the result, I'm still on the value I'm looking for. or am I wrong?

Levi gravatar imageLevi ( 2019-04-05 12:39:06 +0000 )edit

@Levi, sorry I don't understand your last question, can you put it another way?

grahamb gravatar imagegrahamb ( 2019-04-05 12:55:40 +0000 )edit

sure :)

in the capture without filter, I have 1 result. If I take a closer look at the result, then I see the offset in the right place. In the meantime I have tested the protocols. I think that the offset changes during the capturing. when changing from tcp to tpkt I lose the offset, i get no result

Levi gravatar imageLevi ( 2019-04-05 13:07:20 +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


Asked: 2019-04-05 10:24:03 +0000

Seen: 1,020 times

Last updated: Apr 07 '19