SURICATA Ethertype unknown
-
After upgrade to 26.03 RC Suricata started to alert about these events on some interfaces both with and without VLANs:
1:2200121 SURICATA Ethertype unknownRun Wireshark on interface without VLANs and it seems Suricata can't handle Broadcom Ethernet switches management tag (0x8874) anymore.
-
Hmm, how were they shown previously? In 25.11.1?
-
In 25.11.1 with the same configuration of switches etc. Suricata did not show them at all.
-
@pfsjap said in SURICATA Ethertype unknown:
In 25.11.1 with the same configuration of switches etc. Suricata did not show them at all.
Are you by chance using PPPoE on the interface where Suricata is configured? And if "yes", are you also using the new kernel-based PPPoE driver introduced in pfSense Plus?
If so, this is likely being caused by a pfSense custom patch required for the new if_pppoe kernel module not being pulled into the package tree for the latest 26.03 pfSense Plus branch. With the introduction of the if_pppoe kernel driver in pfSense, the Suricata binary package requires a custom patch for its PPPoE capture device code. This custom code has NOT been pushed to FreeBSD Ports upstream, so anytime the pfSense Plus repo is "sync'd" with upstream the custom patch may need to be applied depending on how the upstream ports are pulled down into the Plus repo branch of FreeBSD-ports.
Here is the patch as it appears in the public repo for FreeBSD-ports associated with pfSense CE DEVEL: https://github.com/pfsense/FreeBSD-ports/commit/68a06b3a33c690042b61fb4ccfe96f3138e83b72. This same patch needs to be present in the 26.03 Plus repo if it is not already. There is no public access to that repo, so I am unable to verify if the patch is present there or not.
-
@bmeeks Nope, PPPoE is not used in any of the configured interfaces.
-
@pfsjap said in SURICATA Ethertype unknown:
@bmeeks Nope, PPPoE is not used in any of the configured interfaces.
Strange then. The error message posted is exactly what you would get with the PPPoE kernel driver patch missing.
So far as I know, nothing changed inside the upstream Suricata binary's code that should impact what you are seeing.
-
@bmeeks said in SURICATA Ethertype unknown:
There is no public access to that repo, so I am unable to verify if the patch is present there or not.
That is in Plus since 25.07.1.
-
I do see the definition for C_HDLC is no longer in that patch. Any change that's what it sees those frames as?
-
@stephenw10 said in SURICATA Ethertype unknown:
I do see the definition for C_HDLC is no longer in that patch. Any change that's what it sees those frames as?
It's possible. I see that Kristof Provost made a change to the patch in December of last year to rebase it for the Suricata 8.x binary I believe.
LATER EDIT: Further research shows this is likely the ETHERTYPE_BRCM_TYPE Ethernet Type. It is, as the OP stated, a Broadcom Switch management tag. However, I see no history of that EtherType ever being supported in the Suricata binary. I do see it defined and supported in the Wireshark code, though. Looking through the GitHub history of the related files in the upstream Suricata binary, I don't see that EtherType as ever having been defined. Strange ???
-
Hmm. So it should have always seem them as unknown. If they were actually being captured...
-
I agree that it should always have been reported as "unknown" in Suricata. As stated earlier, I see no history in the upstream source code of it being defined and thus supported previously. The source code contains a header file defining a number of various LINK and ETHERTYPE values followed by a long SWITCH/CASE logic block to test each of the supported values. If there is no match, you get the "unknown" warning in the log.
Those lines of code are here: https://github.com/OISF/suricata/blob/44e75573accbe0e529f3754f78d1579673c4e6de/src/decode.h#L1418 and here: https://github.com/OISF/suricata/blob/44e75573accbe0e529f3754f78d1579673c4e6de/src/decode.h#L1453. One additional source file for ETHERNET_TYPES is here: https://github.com/OISF/suricata/blob/main-8.0.x/src/decode-ethernet.h.
Perhaps something changed in FreeBSD or the associated Broadcom driver that triggered the new behavior ???
-
The choice of "known" EtherTypes in decode-ethernet.h above seems quite limited.
I had a look into alerts.log of the interface with VLANs. The log file has also raw packets which triggered the alerts. Besides the obvious VLAN packets, there were also packets with LLDP (0x88CC) and XNS IDP (0x0600) EtherTypes.
The XNS packets originated from iPhones and iPads. Seems like it was some sort of fallback because of the disruption of the TCP/IP traffic.
-
The general idea for that Ethernet Type test is to find the appropriate "decoder" algorithm so that the packet can be properly analyzed, since different types are likely to require different and unique "decoder" routines. This is especially true with tunneled protocols.
Adding additional valid ETHERNET_TYPE values to the header file would also require writing the appropriate decoder routines so that the packet is properly unpacked and placed into the correct structure variables for analysis by the Suricata engine.
You could report this upstream if desired. But if you do, I suggest not mentioning pfSense at all because that will immediately get the report either routed back here or else sort of ignored as upstream Suricata does not officially support pfSense nor OPNsense. If you can reproduce the issue on a plain-vanilla FreeBSD VM for example by installing the port from FreeBSD Ports and running it from the command line in the virtual machine, then open a Suricata Redmine issue here: https://redmine.openinfosecfoundation.org/projects/suricata.
Just FYI - the upstream Suricata team does limited testing on FreeBSD, but not the same type of exhaustive testing they do on Linux distros. Linux is where they concentrate the majority of their development and support efforts.
-
Hi,
just for the record: I can confirm that. In my Lab-Machine (a simple PCengines APU2 with Intel Ethernet Ports and pfsense+ 26.03) Suricata is throwing the same error!
BTW: @bmeeks Is there any information about who will maintain in the future the Snort & Suricata Package?
Regards,
fireodo -
Do you know what packets are triggering it there?
-
@stephenw10 said in SURICATA Ethertype unknown:
Do you know what packets are triggering it there?
No. I just upgraded pfsense+ (25.11 - 26.03) and then i saw those errors in suricata.
-
Hmm, well if you can grab any in a pcap that might be useful to work out what changed here.
-
Yeah, me too! Started since installing 26.03. Flooding on all interfaces.
04/06/2026-21:14:34.571935 [**] [1:2200121:1] SURICATA Ethertype unknown [**] [Classification: Generic Protocol Command Decode] [Priority: 3] [**] [Raw pkt: FF FF FF FF FF FF 28 34 A2 18 03 AC 88 99 23 C4 25 85 ED 9F 88 28 34 A2 18 03 AC 00 20 20 20 20 ]SYSTEM: PFsense XG7100U
PFSENSE: 26.03 -
@ASGR71 said in SURICATA Ethertype unknown:
That's a packet with EtherType 0x8899, which a quick DuckDuckGo suggests is a RealTek proprietary thing. Wikipedia claims it's to allow remote access to switch registers: https://en.wikipedia.org/wiki/Realtek_Remote_Control_Protocol
In which case ... that certainly sounds like a terrible idea, but it's not surprising that Suricata doesn't know about it, as it's not an official IANA assigned EtherType.
-
@kprovost said in SURICATA Ethertype unknown:
suggests is a RealTek proprietary thing
Euh ... @ASGR71 : you use realtek NICs ?
Does a XG7100U contains realtek hardware ?No "help me" PM's please. Use the forum, the community will thank you.
Privacy Policy · Cookie Policy