Ask Your Question

tshark strange behavior with capture filter

asked 2021-01-20 17:47:51 +0000

BMWE gravatar image

updated 2021-01-20 19:34:49 +0000


I have some strange behavior of tshark:

On my PC, I'm executing tshark -i 5 port 1900 and I see some data. On lab's PC, I'm executing tshark -i 5 port 1900 and I see some data. (interface #5 is internal network).

On lab's PC, I'm executing tshark -i 2and see all the stream including Executing tshark -i 2 -f "port 30000" I don't see any data (port 30000 is one of the ports which is going alongside with Same for tshark -i 2 port 1900 -f "host" and tshark -i 2 port 30000

What I'm doing wrong?

P.S I'm working with Win7

EDIT: when I'm using display filter, I can see the data, but I'd like to use the capture filter in order to reduce some traffic handling. When I'm using same capture filter in wireshark - I have same issue like above

edit retag flag offensive close merge delete

Comments would typically be a multi-cast address. What protocol are you looking for?

Chuckc gravatar imageChuckc ( 2021-01-20 18:24:45 +0000 )edit

UDP. On top of it I have my custom dissector

BMWE gravatar imageBMWE ( 2021-01-20 18:38:11 +0000 )edit

Any VLAN tags involved?

Jaap gravatar imageJaap ( 2021-01-20 20:27:32 +0000 )edit

@Jaap, nope

BMWE gravatar imageBMWE ( 2021-01-20 20:38:38 +0000 )edit

So if you capture without a filter, you see traffic to and from port 30000, but if you capture with "port 30000", you don't?

Guy Harris gravatar imageGuy Harris ( 2021-01-21 04:28:01 +0000 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2021-02-10 11:42:05 +0000

SYN-bit gravatar image

I've figured out what is the issue: The PC sees GRE / ERSPAN.

OK, that means the offsets of where to find the port numbers is different because of the encapsulation. As the capture filter language does not include code to parse gre/erspan natively, the only thing you can do is work with offsets manually.

So, depending on the version of ERSPAN (there are a couple of versions with different header lengths), you can create a filter. Assuming ERSPAN type II packets, there will be:

  • 14 bytes ethernet header
  • 20 bytes IP header
  • 8 bytes GRE header
  • 8 bytes ERSPAN type II header
  • 14 bytes ethernet header (of the packet of interest)
  • 20 bytes IP header (of the packet of interest)
  • 8 bytes UDP header (of the packet of interest)
  • x bytes of payload (of the packet of interest)

Filtering for destination port 30000 (udp only) would mean pick the two bytes at position 14+20+8+8+14+20 of the frame and compare the value to 30000. This will result in ether[84:2] = 30000. Or ip proto 47 and ip[70:2]=30000 when just filtering for the GRE encapsulated frames and then looking for the correct port number, based of the first IP header.

They result in the following BPF code:

$ tcpdump -i en0 -d ether[84:2] = 30000
(000) ldh      [84]
(001) jeq      #0x7530          jt 2    jf 3
(002) ret      #262144
(003) ret      #0
$ tcpdump -i en0 -d ip proto 47 and ip[70:2]=30000
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 7
(002) ldb      [23]
(003) jeq      #0x2f            jt 4    jf 7
(004) ldh      [84]
(005) jeq      #0x7530          jt 6    jf 7
(006) ret      #262144
(007) ret      #0
edit flag offensive delete link more


These 2 proposed solution may work in many cases, but they make a few assumptions, which may or may not be valid.

  • The latest ERSPAN draft specification does seem to indicate that the outer IPv4 header is a fixed-length of 20 bytes, but it might be better not to make the assumption about the outer IP header length and it's certainly not a good idea to assume the inner IP header is always going to be 20 bytes. A more robust capture filter should compute both the inner and outer IP header lengths, rather than assume they're both always going to be 20 bytes, or at the very least compute the inner IP header length.

    • The GRE header is indicated as being 8 bytes in the ERSPAN draft, but other GRE header options are possible so that's something to keep in mind and pay attention to when ...
cmaynard gravatar imagecmaynard ( 2021-02-10 19:53:45 +0000 )edit

@SYN-bit, @cmaynard, Thanks for the explanation.

I've though that even if GRE is used, tshark should be able to identify filters like "udp.port==30000" (like wireshark do).

Maybe its a good idea to add this support in future versions of tshark.

BMWE gravatar imageBMWE ( 2021-02-11 06:39:21 +0000 )edit

@cmaynard Thank you for expanding on this. You are absolutely right in having to take into account different versions and non-default IP header lengths. I did not want to make it too complex though. In practice, I have good results looking at the traffic, determining what to take into account in constructing the proper filter. Of course some environments are more dynamic and have a multitude of versions while another environment has just one type of traffic.

@BMWE Tshark does support the DISPLAY filter udp.port==30000 and it does indeed skip all kinds of tunneling if it was able to dissect the tunneling. However, CAPTURE filters use the BPF engine and the possibilities of the BPF engine are limited for speed and stability. If you have an axample where the display filter udp.port==30000 does not work correctly, please share the example so we can check it is ...(more)

SYN-bit gravatar imageSYN-bit ( 2021-02-11 09:18:59 +0000 )edit

answered 2021-02-09 07:38:36 +0000

Jaap gravatar image

If your traffic comes in over GRE prefix your capture filter expression with ip protochain GRE

edit flag offensive delete link more


i.e. the filter shall be ip protochain GRE and port 30000 ?

BMWE gravatar imageBMWE ( 2021-02-09 07:41:54 +0000 )edit

maybe use "47" instead of "GRE" if your libpcap doesn't support gre as a protocol name.

grahamb gravatar imagegrahamb ( 2021-02-10 12:30:18 +0000 )edit

answered 2021-01-20 18:41:58 +0000

Chuckc gravatar image

Probably best to combine into a single capture filter. (tshark man page)

~$ tshark -i 5 host and port 1900
Capturing on 'Ethernet'
    1   0.000000 SSDP 216 eth:ethertype:ip:udp:ssdp   M-SEARCH * HTTP/1.1
    2   1.000658 SSDP 216 eth:ethertype:ip:udp:ssdp   M-SEARCH * HTTP/1.1
2 packets captured
edit flag offensive delete link more


This is working for the SSDP. But not working for my data :(

BMWE gravatar imageBMWE ( 2021-01-20 18:48:23 +0000 )edit

Man page of PCAP-FILTER
"port 53' means(tcp or udp) port 53'."

Are you able to capture and examine packets for your data to verify that the UDP dissection is working?
Can you share a packet capture?
(Capture filtering is handled by libpcap, and its documentation is part of the libpcap distribution.)

Chuckc gravatar imageChuckc ( 2021-01-20 19:06:23 +0000 )edit

can't share the data. it is in internal network. I can see the data in wireshark

BMWE gravatar imageBMWE ( 2021-01-20 19:14:47 +0000 )edit

You might try opening a libpcap issue but it would help to have an example packet to discuss.

Chuckc gravatar imageChuckc ( 2021-01-20 19:48:29 +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: 2021-01-20 17:47:51 +0000

Seen: 793 times

Last updated: Feb 10 '21