19:27:47.782291 98:9b:cb:: > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x88e1), length 60:
        0x0000:  0000 a000 b052 38e5 d57f 0000 0000 0000  .....R8.........
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
19:27:47.782293 98:9b:cb:: > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x8912), length 60:
        0x0000:  0170 a000 0000 1f84 e5a3 97a2 5553 bef1  .p..........US..
        0x0010:  fcf9 796b 5214 13e9 e200 0000 0000 0000  ..ykR...........
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

My router is sending this garbage into my network and I'd like to block it, as one cannot disable it. Doing so via iptables has proven to be more challenging than I thought it would be:

root@fw:~ # iptables -A INPUT -m mac --mac-source 98:9b:cb:: -p 0x88e1 -j DROP
iptables v1.8.2 (nf_tables): unknown protocol "0x88e1" specified
Try `iptables -h' or 'iptables --help' for more information.

Is there any way to block an invalid ether-type?

  • Those are broadcast frames, and a router should not forward broadcasts. That is probably coming from somewhere inside your network, or the router itself is creating them.
    – Ron Maupin
    Feb 1, 2021 at 0:18
  • @RonMaupin As I wrote, the router is sending/creating them Feb 5, 2021 at 5:14

3 Answers 3


It seems iptables cannot be used for our problem. We have to use its improved successor nftables. It has simply a meta expression available with expression type protocol = EtherType protocol value. Thanks to @Bernard who found the solution to his question Linux server dropping RX packets in __netif_receive_skb_core. He gives this example to drop the unknown EtherTypes, that must just appended to /etc/nftables.conf:

table netdev filter {
    chain ingress {
        type filter hook ingress device eno1 priority 0; policy accept;
        meta protocol {0x8912, 0x88e1} drop

On my Raspberry Pi with Raspberry Pi OS Buster I just do:

rpi ~$ sudo apt install nftables

/etc/nftables.conf is now available and I appended the rules with the correct interface name instead of eno1 from the example.

rpi ~$ sudo systemctl start nftables.service

and tcpdump show me, that there are no more that unknown EtherType packets.


Why do you want to drop these frames? What difference does it make? They are dropped anyway...

The reason why your iptables approach does not work is that you mix up protocol layers. Ethernet type (meaning: the higher level protocol) 0x0800 is IP (see /etc/ethertypes). In other words: This is not an IP packet. And as an immediate consequence Netfilter never sees it because it processes only IPv4 and IPv6 packets. For that reason there is no option for matching the ethertype in Netfilter.

Not even ebtables seems to help here as it does not have a test for ethertype.

Some hope: traffic shaping

Maybe there is a (difficult) "solution" (for this non-problem) in abusing traffric shaping (tc) and its Intermediate Functional Block (ifb) pseudo network interface. Usually traffic shaping is used for outgoing traffic only. With the ifb it can be enforced on incoming traffic (I have never done that). The reason why I think this may offer an approach is that tc offers filters beyond protocol logic. You can simply look at certain bytes in the packet. So maybe the ethertype field of incoming packets becomes accessible that way.

Next problem: Traffic shaping was not made for filtering packets but for reordering them. But maybe some of its features can be abused for dropping certain packets/frames.


I was trying the same thing and couldn't get it to work either, even though I though I think the -p option should to work (but perhaps I misread the manpage).

However, what did work for me was explicitly specifying allowed ethernet types and simply dropping everything else:

# ebtables -A INPUT -s XX:XX:XX:XX:XX:XX -p ip4 -j ACCEPT
# ebtables -A INPUT -s XX:XX:XX:XX:XX:XX -p ip6 -j ACCEPT
# ebtables -A INPUT -s XX:XX:XX:XX:XX:XX -p ARP -j ACCEPT
# ebtables -A INPUT -s XX:XX:XX:XX:XX:XX -j DROP

If you use other ethernet protocols you might need to add those too, e.g. perhaps 802_1Q for vlan tagged traffic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.