Ask Your Question
0

How to Determine Low Level Filter

asked 2020-07-24 19:44:21 +0000

zchbrsn gravatar image

updated 2020-07-24 22:13:54 +0000

Hello,

I'm trying to get an understanding of what is actually being applied to the filter when using quick terms such as tcp.

E.g. if I filter "tcp", is it actually filtering ip.proto==0x06?

I am getting different packet counts for each of these filters and I would like to know if there is a document that contains this type of information for these quick reference type of filters.

Thank you for your help.

Edit: Another example is something like ipv6 vs ip.version==6

Edit 2: I wanted to mention that I am looking for a resource or tool that would help me dissect a display filter. I've used dumpcap -d -f <display filter>, but not exactly what I'm looking for.

edit retag flag offensive close merge delete

Comments

I think you are at the mercy of the logic in the code. Maybe one of the developers will weigh in on this.

Until then, try some experiments:
- add ip.proto as a column and compare that to the Protocol column

- to see the difference in TCP packets try filter tcp && !ip.proto==0x06. The test capture I'm looking at has lots of IPv6 which doesn't have an ip.proto field but yet does have TCP packets.

- I didn't get any hits on ipv6 && !ip.version==0x06 so would be curious what packets in your capture meet that criteria.

Chuckc gravatar imageChuckc ( 2020-07-24 21:20:17 +0000 )edit

Thanks for the advice.

I actually tested what you were suggesting and found that ip.proto == 0x06 is strictly looking for IPv4 TCP traffic. I believe this filter is actually more similar to ip[9] == 0x06 or ipv6[6] == 0x06, or simply looking for both IPv4 and IPv6 like you stated.

I was hoping to get the information on a broader spectrum though. I thought there might be a reference that we could input a display filter such as port 53 and it produces something like tcp.port == 53 || udp.port == 53

zchbrsn gravatar imagezchbrsn ( 2020-07-24 22:10:04 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2020-07-24 22:07:59 +0000

Guy Harris gravatar image

E.g. if I filter "tcp", is it actually filtering ip.proto==0x06?

No.

When dissecting packets, if it's doing so in order to display the packet details, or to test a packet-matching expression (called a "display filter", but it's used for purposes other than filtering the display, such as coloring packets), Wireshark builds a "protocol tree" with items for every field in the packet - and for items that include multiple fields.

Most of those fields have names, which means they can be tested in a packet-matching expression. If they have a value, the value can be tested, for example, ip.proto==0x06 tests whether there is an instance of the field named ip.proto that has the value 0x6.

(Note that there could be more than one instance of a field; if there's some protocol running over IPv4 that provides a "pseudo-wire" that transports Ethernet packets, and the Ethernet packet is an IPv4 packet, there will be two IPv4 headers in the packet, and thus two instances of ip.proto; if one of them is 0x06, that expression will match, even though the other one might not be 0x06.)

Even if the field doesn't have a name, a packet-matching expression can test whether it's present in a protocols. A filter ip,proto by itself will test whether the packet has that field.

Protocols also have "fields" associated with them; the field named ip refers to the IPv4 protocol, the field named ipv6 refers to the IPv6 protocol, and the field named tcp refers to the TCP protocol, for example.

So, for a TCP packet, the protocol tree might look like:

Frame 16: Bytes bytes on wire (Bytes*8 bits), Bytes bytes captured (Bytes*8 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Month Day, Year HH:MM:SS.FFFFFFFF TZ
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 917071640.531000000 seconds
    [Time delta from previous captured frame: 0.329000000 seconds]
    [Time delta from previous displayed frame: 0.329000000 seconds]
    [Time since reference or first frame: 2.661000000 seconds]
    Frame Number: 16
    Frame Length: Bytes bytes (Bytes*8 bits)
    Capture Length: Bytes bytes (Bytes*8 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    File Offset: Offset-in-decimal (Offset-in-hex)
    [Protocols in frame: eth:ethertype:ip:tcp:{more protocols}]
Ethernet II, Src: XX:XX:XX:XX:XX:XX, Dst: YY:YY:YY:YY:YY:YY
    Destination: YY:YY:YY:YY:YY:YY
        Address: YY:YY:YY:YY:YY:YY
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: XX:XX:XX:XX:XX:XX
        Address: XX:XX:XX:XX:XX:XX
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: XXX.XXX.XXX.XXX, Dst: YYY.YYY.YYY.YYY
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x64 (DSCP: Unknown, ECN: Not-ECT)
        0110 01.. = Differentiated Services Codepoint: Unknown (25)
        .... ..00 = Explicit Congestion Notification ...
(more)
edit flag offensive delete link more

Comments

Thank you for the write-up, this explains quite a bit.

I know it's been a pain for me trying to find packets and having to explicitly filter out ICMP.

Also, good to know that something like tcp.flags.syn matches on all packets that have that flag (essentially TCP packets), whereas tcp.flags.syn == 1 matches on packets that have the SYN flag turned on.

Appreciate it!

zchbrsn gravatar imagezchbrsn ( 2020-07-24 22:17:42 +0000 )edit
0

answered 2020-07-24 21:36:38 +0000

Jaap gravatar image

These filter, e.g., tcp, is filtering for the protocol being included in the packet details. So whenever the IPv4 dissector has a complete packet it hands that off to the TCP dissector, which passes the filter to be shown. This gets complicated when there are fragmented TCP packets. Then you'll have more packets with ip.proto==0x06 then there are TCP packets coming through the filter.

edit flag offensive delete link more

Your Answer

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

Add Answer

Question Tools

Stats

Asked: 2020-07-24 19:44:21 +0000

Seen: 822 times

Last updated: Jul 24 '20