Ask Your Question
0

reference outer most eth.type

asked 2020-06-22 16:34:15 +0000

aaronf gravatar image

updated 2020-06-22 17:02:03 +0000

Is there any way to reference the outer most eth.type value in a display filter?

e.g. we are filtering on eth.type == 0x0800 (ipv4) packets. Because some packets are encapsulated with another ethernet header the display filter is matching on both outer and inner ethernet frames. Our specific goal is to filter on the outer most ethernet frame.

heres the display filter

eth.type == 0x0800 and ip.proto == 6 and tcp.option_kind==5

Example packet in question

Frame 332259: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Ethernet II, Src: JuniperN_bd:97:d9 (7c:e2:ca:bd:97:d9), Dst: Optium_80:00:16 (00:0e:52:80:00:16)
    Destination: Optium_80:00:16 (00:0e:52:80:00:16)
    Source: JuniperN_bd:97:d9 (7c:e2:ca:bd:97:d9)
    Type: IPv4 (0x0800)
    Frame check sequence: 0xd06b73f1 [unverified]
    [FCS Status: Unverified]
Internet Protocol Version 4, Src: 61.197.167.247, Dst: 130.128.255.152
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 112
    Identification: 0xc804 (51204)
    Flags: 0x0000
    Fragment offset: 0
    Time to live: 57
    Protocol: UDP (17)
    Header checksum: 0x51a3 [validation disabled]
    [Header checksum status: Unverified]
    Source: 61.197.167.247
    Destination: 130.128.255.152
User Datagram Protocol, Src Port: 1701, Dst Port: 9348
Layer 2 Tunneling Protocol
Point-to-Point Protocol
PPP Bridging Control Protocol Bridged PDU
Ethernet II, Src: AlliedTe_92:65:06 (00:1a:eb:92:65:06), Dst: Toshiba_3b:0b:88 (b8:6b:23:3b:0b:88)
    Destination: Toshiba_3b:0b:88 (b8:6b:23:3b:0b:88)
    Source: AlliedTe_92:65:06 (00:1a:eb:92:65:06)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 230
Internet Protocol Version 4, Src: 172.217.25.232, Dst: 192.168.230.72
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 52
    Identification: 0x408b (16523)
    Flags: 0x0000
    Fragment offset: 0
    Time to live: 56
    Protocol: TCP (6)
    Header checksum: 0xd486 [validation disabled]
    [Header checksum status: Unverified]
    Source: 172.217.25.232
    Destination: 192.168.230.72
Transmission Control Protocol, Src Port: 443, Dst Port: 50112, Seq: 1, Ack: 2, Len: 0
    Source Port: 443
    Destination Port: 50112
    [Stream index: 18591]
    [TCP Segment Len: 0]
    Sequence number: 1    (relative sequence number)
    Sequence number (raw): 450123849
    [Next sequence number: 1    (relative sequence number)]
    Acknowledgment number: 2    (relative ack number)
    Acknowledgment number (raw): 1913214286
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
    Window size value: 369
    [Calculated window size: 369]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x7bfa [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), SACK
        TCP Option - No-Operation (NOP)
        TCP Option - No-Operation (NOP)
        TCP Option - SACK 1-2
            Kind: SACK (5)
            Length: 10
            left edge = 1 (relative)
            right edge = 2 (relative)
            [TCP SACK Count: 1]
    [SEQ/ACK analysis]
    [Timestamps]

Edit 1:

Looking at this some more, the display filter is working ... (more)

edit retag flag offensive close merge delete

Comments

Related to your original question - request to handle display filter occurence

Chuckc gravatar imageChuckc ( 2020-06-22 18:33:40 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-06-23 06:21:14 +0000

Jaap gravatar image

Wireshark has no concept of 'inner' and 'outer' in display filters. It regards the whole packet as a set of fields with values when processed through the display filter system.

edit flag offensive delete link more

Comments

Thanks, sounds need a different approach

aaronf gravatar imageaaronf ( 2020-06-23 12:57:02 +0000 )edit

And the bug 3791 proposal, adding ordinal numbers to fields, may not be enough to do the trick; see my latest comment on the bug.

Guy Harris gravatar imageGuy Harris ( 2020-06-24 04:39:55 +0000 )edit

looks like we can do it this way

frame.protocols == eth:ethertype:ip:tcp

aaronf gravatar imageaaronf ( 2020-06-24 08:10:56 +0000 )edit

a better way is partial string

frame.protocols ~ eth:ethertype:ip:tcp

otherwise it only counts tcp packets it cant decode.

aaronf gravatar imageaaronf ( 2020-06-24 09:20:06 +0000 )edit

perhaps if you can do some minior regex like searching, you could do some pretty interesting filtering

e.g

frame.protocols.== *.ip:tcp:*

or 

frame.protocols == eth:ethertype:ip:*:tcp:*

might be an interesting way to deal with encapsulation?

aaronf gravatar imageaaronf ( 2020-06-24 09:29:44 +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

Stats

Asked: 2020-06-22 16:34:15 +0000

Seen: 865 times

Last updated: Jun 23 '20