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)
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 theProtocol
column- to see the difference in
TCP
packets try filtertcp && !ip.proto==0x06
. The test capture I'm looking at has lots ofIPv6
which doesn't have anip.proto
field but yet does haveTCP
packets.- I didn't get any hits on
ipv6 && !ip.version==0x06
so would be curious what packets in your capture meet that criteria.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 toip[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 liketcp.port == 53 || udp.port == 53