MAC address lengths reported by nftables in logs doesn't always consist of 12 hexadecimal digits

While monitoring firewall logs I noticed MAC addresses reported in nftables logs which don't match standard length. It is my understanding that MAC address is 48 bits which should be represented as 12 hexadecimal digits because each hexadecimal digit requires 4 bits therefore 48 / 4 = 12 hexadecimal digits (grouped into 6 groups of 2 digits each). The above is in line to what wikipedia states: > As typically represented, MAC addresses are recognizable as **six groups of two hexadecimal digits**, separated by hyphens, colons, or without a separator. According to wikipedia an example of such address is 01:23:45:67:89:AB, this means there are 12 hexadecimal digits (6 groups x 2 per group = 12) and that's how I recognize devices on my LAN too and how I do traffic filtering on LAN. Such 6 group hexadecimal digits are also seen in firewall logs (e.g ARP entry), since that's clear I'm not going to post an example of it.. However there are also logs such as this one:

2024-09-29T14:44:21.000498+02:00 debian kernel: [ 2520.417160] DROP default new_in_4: IN=wlan0 OUT= MAC=00:c0:ca:52:bf:8e:10:a3:b8:f5:f7:28:08:00 SRC=157.48.189.170 DST=192.168.1.34 LEN=132 TOS=0x08 PREC=0x20 TTL=43 ID=0 PROTO=UDP SPT=35165 DPT=3451 LEN=112

This one lists 14 groups of hexadecimal digits MAC address or 28 hex digits in total.\ All such addresses are begin with 00: and end with :00 as first and last group of digits. Therefore this MAC address that can be seen in nftables log is more than double size than what it should be (counting prefix group and suffix group of 00). Question 1 is, what is this 14 group 28 digit MAC address and what does it mean in nftables logs? And question 2, probably even more interesting is, how is it possible to get MAC address for a peer somewhere on the internet? I assume this MAC address comes from beyond NAT firewall because i don't recognize it. How do I filter these odd MAC addresses and should I? This sample log entry is dropped inbound UDP traffic generated by bittorrent peer because I've closed the client. **edit:**

ip link show wlan0

3: wlan0  mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000
    link/ether 00:c0:ca:52:bf:8e brd ff:ff:ff:ff:ff:ff