Unknown Ethertype Error

[f1yankees]

Hello, I am trying to troubleshoot some packet loss warnings I keep getting. Running tcpdump gives me the error below - I am just not sure what it is trying to tell me. Any help here would be appreciated.

21:54:22.045516 08:36:c9:f3:77:f5 (oui Unknown) > 01:80:c2:00:00:13 (oui Unknown), ethertype IEEE1905.1 (0x893a), length 65: 
	0x0000:  0000 0000 be85 0080 0100 0608 36c9 f377  ............6..w
	0x0010:  f50b 0008 0003 7f03 0000 0002 0b00 0800  ................
	0x0020:  037f 0200 0000 0302 0006 0a36 c9f3 77f7  ...........6..w.
	0x0030:  0000 00                                  ...
21:54:22.143691 LLDP, length 46
21:54:23.586726 LLDP, length 208: jetback
21:54:32.939805 IP _gateway > pi.hole: ICMP _gateway udp port 7952 unreachable, length 121

Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye
Linux 5.10.0-19-amd64 x86_64
tcpdump version 4.99.0
libpcap version 1.10.0 (with TPACKET_V3)
OpenSSL 1.1.1n  15 Mar 2022

[guyharris]

I am just not sure what it is trying to tell me

Assuming that the packet passed, unmolested by the Linux networking stack, from the Ethernet device to libpcap, It's trying to tell you that a host with the MAC address 08:36:c9:f3:77:f5 sent a packet to the MAC address 01:80:c2:00:00:13, and the link-layer type of that packet is 0x893a.

I don't see the word "Unknown Ethertype" anywhere in the tcpdump output. Tcpdump doesn't know how to dissect packets of that type, but it at least knows that the Ethertype value 0x893a corresponds to IEEE Standard 1905.1.

The first 3 octets of a host MAC address, such as the sending MAC address 08:36:c9:f3:77:f5, are the Organizationally Unique Identifier if the MAC address is part of an MA-L assignment. Tcpdump currently only looks in a small internal table to identify OUI values; Wireshark has a large file ("manuf"), generated from various public databases and an exception file, that it uses to identify OUIs. The Wireshark Web site has an OUI identification tool that uses that file; it identifies 08:36:c9 as belonging to Netgear, so a Netgear device presumably sent that packet.

The destination MAC address is a multicast address. According to the IEEE Standards Association tutorial guide to standard group MAC addresses, it's an address assigned for standard protocols. According to the IEEE Standards Association listing of standardized gorup MAC addresses, it's for "Transmission of IEEE 1905.1 control packets".

Tcpdump doesn't currently have code to decode those packets, so it just shows what the Ethertype means and dumps the raw hex contents of the packet.

[guyharris]

The only error tcpdump is showing you is

21:54:32.939805 IP _gateway > pi.hole: ICMP _gateway udp port 7952 unreachable, length 121

which says that some machine - presumably a gateway machine, given its name is "_gateway" - is telling a machine named "pi.hole" that an attempt to send a UDP packet to _gateway, UDP port 7952, failed because _gateway isn't listening to that UDP port. There is no indication of why pi.hole attempted to send a packet to that port.

[f1yankees]

Thank you very much, this is very helpful. The only Netgear device I have is my router (Netgear Orbi) which is connected by ethernet to this machine. Any idea why it is not recognizing the traffic?

As for pihole, I almost snipped that out but glad I was doing this late at night. I don't know why pihole is not using port 53 but I'll look into it.

[guyharris]

The only Netgear device I have is my router (Netgear Orbi) which is connected by ethernet to this machine. Any idea why it is not recognizing the traffic?

What is "it", what is "recognizing", and what is "the traffic"?

The Orbi is sending the 1905.1 control messages, rather than receiving them, so that's not traffic that it's not recognizing.

tcpdump recognizes that they're 1905.1 (control) messages, but nobody's written and contributed code to further dissect that protocol, so it doesn't indicate the details of those packets, it just dumps the raw payload in hex. The fact that tcpdump doesn't provide the details of those packets does not indicate a network issue of any sort on your network, so it says nothing about any packet loss on your network.

[infrastation]

@f1yankees, without your feedback this request will be closed in 10 days.

[infrastation]

It is time.