tshark strange behavior with capture filter

tshark

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

BMWE

1 ●10 ●18 ●21

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

Hi,

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 224.1.1.1. 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 224.1.1.1). Same for tshark -i 2 port 1900 -f "host 224.1.1.1" 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

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

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

UDP. On top of it I have my custom dissector

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

Any VLAN tags involved?

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

@Jaap, nope

BMWE ( 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 ( 2021-01-21 04:28:01 +0000 )edit

see more comments

3 Answers

Sort by » oldest newest most voted

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

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

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

Comments

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 ...

(more)

cmaynard ( 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 ( 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 ( 2021-02-11 09:18:59 +0000 )edit

add a comment

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

Jaap

13742 ●711 ●115

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

edit flag offensive delete link

Comments

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

BMWE ( 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 ( 2021-02-10 12:30:18 +0000 )edit

add a comment

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

Chuckc
3023 ●6 ●608 ●20

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

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

edit flag offensive delete link

Comments

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

BMWE ( 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 ( 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 ( 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 ( 2021-01-20 19:48:29 +0000 )edit

add a comment

Your Answer

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

Add Answer

tshark strange behavior with capture filter

Comments

3 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

tshark strange behavior with capture filter edit

Comments

3 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

tshark strange behavior with capture filter