Bug #8142
openUnknown ethertype event logs outer header ethertype instead of unrecognized ethertype in inner header
Description
Hi,
I was looking into the logging by this rule because of its huge volume:
alert pkthdr any any -> any any (msg:"SURICATA Ethertype unknown"; decode-event:ethernet.unknown_ethertype; classtype:protocol-command-decode; sid:2200121; rev:1;)
(I removed the default treshold settings in my test setup)
Surprisingly ethertype 0x8100 was mentioned a lot which is weird because that is plain 802.1q VLAN tagging.
Turns out that if, for instance, a RARP packet is received on a certain VLAN, that RARP packet (ethertype 0x8035) is marked as unknown in the debug output but the outer ethertype (0x8100) is logged as being unknown in the generated event.
When run with debug enabled, you'll see somthing like this:
Debug: decode-vlan: p 0x7f89b428c140 pkt 0x7f89b428c31a VLAN protocol 8035 VLAN PRI 0 VLAN CFI 0 VLAN ID 2015 Len: 50 [DecodeVLAN:decode-vlan.c:84] Debug: decode-vlan: unknown ether type: 8035 [DecodeNetworkLayer:decode.h:1509] Debug: decode-vlan: p 0x7f89b428c140 event 62 [DecodeNetworkLayer:decode.h:1511] Debug: decode-vlan: p 0x7f89b428c140 event 88 [DecodeVLAN:decode-vlan.c:91]
In the eve.json, this alert show up:
{
"timestamp": "2025-11-26T10:27:54.334585+0100",
"pcap_cnt": 1,
"event_type": "alert",
"vlan": [
2015
],
"pkt_src": "wire/pcap",
"ether": {
"ether_type": 33024,
"src_mac": "00:50:56:83:74:6d",
"dest_mac": "ff:ff:ff:ff:ff:ff"
},
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 2200121,
"rev": 1,
"signature": "SURICATA Ethertype unknown",
"category": "Generic Protocol Command Decode",
"severity": 3
}
}
Ether-type 33024 == 0x8100
The above is true for all unknown ether types in the inner header; I found several of them like 0x8922 and 0x8902 within a VLAN tagged packet.
Unknown ether types in the first/outer header, like LACP (0x8809) are reported correctly.
A small pcap with 3 RARP packets within a 802.1q VLAN, is attached.
Maybe it is also a good idea to log the ethertype as hex-number in the event as almost all documentation you'll find on the internet, mentions the hex value and not the decimal value.
Thanks, John
Files
Updated by Jason Ish 1 day ago
Interesting observation. I think by design, the ether object is only supposed to describe the outer ethernet packet. Its more about knowing where it came from, and where its going directly on the lan that captured it, not really for tunneled ethernet. As such, its not really considered related to the alert object. Given that, yes, this alert type does lack context about the ethertype it is alerting on.
We have a related, perhaps duplicate issue here: #7849.
In summary, I think the ether object is logging what it should, but we lack the context as to what ethertype is unknown causing the alert.
Updated by Jason Ish 1 day ago
- Related to Optimization #7849: rule 2200121 : SURICATA Ethertype unknown added