I wrote some C code having a rudimentary software licensing function within, where the executable will only run if the MAC address of the system I whitelisted in my C code. I only want this to work in linux. I was accessing /sys/class/net/eth0/address which contains something like a0:b1:c2:d3:e4:f5 all in lower case on one line, making it very easy to get the MAC address. This works only if you have eth0 because I hard coded fopen( "/sys/class/net/eth0/address", "r" ); The problem I am realizing is the **eth0** part. With BiosDevName and/or Predictable Network Interface Naming being the default now [in RHEL/CentOS 7] I am seeing something like eno1 rather than eth0 as the first network device having a MAC address. And this can vary greatly from system to system. So I am dealing with /sys/class/net//address. What is the most portable and reliable, and not to hard, of a way to get the MAC address(es) of a linux system? Oftentimes the servers I deal with have quad port Intel NIC's, but I really only need the first one. And my code doesn't care what the network interface names are, I just need to know one or more MAC addresses that are present.

Looking at syslog files on Debian 10 form a previous session I have noticed a MAC Address change and I do not know why it is happening. Any ideas on how to stop this? Jun 8 15:43:46 NetworkManager: [1591623826.4785] manager: NetworkManager state is now CONNECTED_LOCAL Jun 8 15:43:46 NetworkManager: [1591623826.4790] device (wlp8s0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Jun 8 15:43:46 dbus-daemon: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=729 comm="/usr/sbin/NetworkManager --no-daemon ") Jun 8 15:43:46 NetworkManager: [1591623826.4793] device (wlp8s0): set-hw-addr: **reset MAC address to 68:5D:43:61:77:45** (unmanage) Jun 8 15:43:46 NetworkManager: [1591623826.4799] device (enp7s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Jun 8 15:43:46 kernel: [15194.894941] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready Jun 8 15:43:46 kernel: [15194.895237] RTL8211E Gigabit Ethernet r8169-700:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-700:00, irq=IGNORE) Jun 8 15:43:46 systemd: Starting Network Manager Script Dispatcher Service... Jun 8 15:43:46 dbus-daemon: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 8 15:43:46 systemd: Started Network Manager Script Dispatcher Service. Jun 8 15:43:46 nm-dispatcher: req:1 'down' [enp7s0]: new request (1 scripts) Jun 8 15:43:46 nm-dispatcher: req:1 'down' [enp7s0]: start running ordered scripts... Jun 8 15:43:46 nm-dispatcher: req:2 'connectivity-change': new request (1 scripts) Jun 8 15:43:46 NetworkManager: [1591623826.6955] device (wlp8s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Jun 8 15:43:46 kernel: [15195.108815] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready Jun 8 15:43:46 kernel: [15195.110559] IPv6: ADDRCONF(NETDEV_UP): wlp8s0: link is not ready Jun 8 15:43:46 NetworkManager: [1591623826.6963] device (wlp8s0): set-hw-addr: set MAC address to **DE:5B:91:11:04:52** (scanning) Jun 8 15:43:46 nm-dispatcher: req:2 'connectivity-change': start running ordered scripts...

I wanted to know if there is a way to differentiate physical and virtual network devices. ip a doesn't have an option. So I am trying /sys/class/net/. There are 2 attributes addr_assign_type and type, but type only tells Ethernet or loopback there is not way to tell if its virtual. I wanted to know does addr_assign_type tell us the different? As per my observation /sys/class/net//{eth|loopback} gives 0 and /sys/class/net//{virtualdevice} gives 1 or 3. Is there something I can infer from this?

On my Linux Ubuntu I've a Linux bridge vnet0_6. You can check the mac address of each of the two interfaces attached to bridge's ports. root@eve-ng62:~# brctl show vnet0_6 bridge name bridge id STP enabled interfaces vnet0_6 8000.7afc42bc8d20 no vunl0_4_4 vunl0_6_5 root@eve-ng62:~# root@eve-ng62:~# brctl showmacs vnet0_6 port no mac addr is local? ageing timer 2 ba:41:1d:fc:61:3a yes 0.00 2 ba:41:1d:fc:61:3a yes 0.00 1 ce:8f:3f:0e:a7:cb yes 0.00 1 ce:8f:3f:0e:a7:cb yes 0.00 root@eve-ng62:~# My question is: do bridge's ports have their *own* mac addresses ? I'm not sure whether the concept of mac address actually applies to bridge's ports themselves or only to interfaces (even virtual ones) attached to them.

I need to write a bash script wherein I have to create a file which holds the details of IP Addresses of the hosts and their mapping with corresponding MAC Addresses. Is there any possible way with which I can find out the MAC address of any (remote) host when IP address of the host is available?

I only have the BSSID of the specific target device I want to connect to. How can I determine the actual Wi-Fi network name that the device is connected to? I'm using kali linux, and I used crunch 8 14 | aircrack-ng -a2 -b [target device BSSID] -w [file saved using airodump-ng].

I am in the process of writing software to test Linux based embedded devices after manufacturing. Each of the devices has multiple physical network interfaces, all internally bridged to a Linux bridge br0. **Problem**: - I need to find out if all of the NICs of the DUT are working properly (i.e. nothing went wrong during manufacturing). **The test setup is as follows**: - All Ethernet NICs of the DUT (MAC addresses are known, STP deactivated, IPv4/IPv6 activated) are physically connected to separate ports (let's say 1-3) of a managed switch - The system running the test software (also Linux) is physically connected to the same switch (let's say on port 4). **What I did so far**: - I made sure exactly one of the switch ports (1-3) was enabled (ifAdminStatus=up) via SNMP and then send simply pinged the DUT to see if the connected NIC is working and repeated the process for all switch ports/NICs. This, however, is somewhat slow as the switch needs ~3.5 seconds to (de-)activate a switch port and introduces additional delay until a ping is then successful. This adds up to ~15 seconds which I consider way to long. Ideally, I'd like to activate all switch ports 1-3 simultaneously and do the test in parallel on layer 2 or 3. **Question**: What would be we the best way to design a simple and fast (!) test to find out if all NICs are working and simultanously avoiding all of the inherent problems (broadcast storms due to switching loops, ...)?

I am trying out [Tails](https://tails.net/index.de.html) and disabled the [MAC address randomization](https://tails.net/doc/first_steps/welcome_screen/mac_spoofing/index.en.html#index5h1) feature during boot, but when doing ip addr in the terminal, the MAC address of wlan0 (WiFi adapter) keeps changing regardless. This is extremely annoying and means e.g. that I cannot access WiFi hotspots employing a MAC filter. Is there any way to disable this feature e.g. from a root terminal and force Tails to use a static MAC address?

I've been trying for days to connect a live [Tails](https://tails.net/) system to a mobile WiFi hotspot on an Android 9.0 device without success. What I have done so far: 1. Set up a mobile WiFi hotspot in Android protected by a WPA2 password and MAC filtering 2. Boot Tails with the MAC address anonymization feature disabled 3. Read out the hostname and static MAC address of the Tails system by doing cat /etc/hostname and ip link, respectively 4. Using the hostname and MAC address, add the Tails system to the hotspot's white list of allowed devices 5. Try to connect to the hotspot using its SSID and WPA2 password Step 5 keeps failing with the error message > Connection failed > > Activation of network connection failed I quadruple-checked every single setting, checked and changed the WPA2 password, tried disabling MAC filtering, switched between 2.4 GHz and 5.0 GHz, switched between visible and hidden SSIDs etc., all without success. There are zero issues connecting other Linux systems to the exact same hotspot using exactly the same procedure, and I also have been connected to other public WiFi networks using this exact Tails system before. FWIW, the network controller according to lspci -v | grep "Network controller" is Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34) What am I missing here? Is there a way to get some real-time, verbose terminal output with detailed error messages etc. from the WiFi adapter while it is trying to connect?

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

Say I create a bridge interface on linux (br0) and add to it some interfaces (eth0, tap0, etc.). My understanding is that this interface act like a virtual switch with all its interfaces/ports that I add to it. What is the meaning of assigning a MAC and an IP address to that interface? Does the interface act as an additional port on the switch/bridge which allows other ports to access the host machine? I have seen some pages talk about assigning an IP address to a bridge. Is the MAC assignation implied (or automatic)?

I upgraded to Fedora 40 and was introduced to its new feature of MAC address randomization (for Wi-Fi interfaces at least). How do I disable it? Links I found didn't work for me: https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/5 https://fedoraproject.org/wiki/Changes/StableSSIDMACAddress I tried to follow the advice from link 2 and create 2 files in /etc/NetworkManager/conf.d/: 22-wifi-mac-addr.conf: [connection.22-wifi-mac-addr] match-device=type:wifi wifi.cloned-mac-address=stable-ssid [.config] enable=nm-version-min:1.45 and 90-wifi-mac-addr.conf: [connection-90-wifi-mac-addr-conf] wifi.cloned-mac-address=permanent I followed instructions literally: e.g. the 22* file has section named [connection.22-wifi-mac-addr] while the 90* file has one named [connection-90-wifi-mac-addr-conf] (i.e. the dot and minus after the word 'connection', present and absent '-conf' suffix etc.). Also I tried to make it uniform, sort of to fix all of the typos. Nothing, after I restarted the NetworkManager.service: # systemctl restart NetworkManager.service the MAC address keeped to change on every enable/disable Wifi toggle. Could someone help me please?

I have various small NUCs with attached on each one some of this USB3 LAN adapters (because the NUCs have only one Ethernet, so I added extra ones with USB3 adapters). You can see an image of the product . All of a sudden, probably due to an unattended automatic upgrade, these devices started getting random MAC addresses. Before: Each USB3 attached device had an address in the form: 00:0E:C6:XX:XX:XX Each one was distinct and always the same (stable), surviving reboots. Now they have address like: eth1 - be:7d:ee:6a:26:ab eth2 - be:7d:ee:6a:26:ab eth3 - be:7d:ee:6a:26:ab eth4 - be:7d:ee:6a:26:ab eth5 - be:7d:ee:6a:26:ab all sharing the same randomly picked address. In short, troubles: - **Each time the machine reboots, this random MAC address changes.** - **They all share the same random MAC address.  Previously each one had a different and clearly distinct one.** The devices are identified in lsusb as:    **ASIX Electronics Corp. AX88179 Gigabit Ethernet** I have no idea what happened since latest automatic update, it's matter of the latest 2 days, 1h ago everything was working OK, after all these devices started to have this weird behaviour. Could it be a problematic update?  Could it be a new driver been released that randomizes the MAC address each time?  Could it be a feature from the Linux kernel or the distro or GRUB setting where USB LAN devices now get random MAC address each time?  But in this case, why all of them share the same?  They should be totally random.... I am seeking help and willing to do tests... Regarding the OS: Debian Version: **12.5** Linux 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux --- Workarounds suggested so far, including the final one always working thanks to @A.B: - https://unix.stackexchange.com/questions/774706 - https://unix.stackexchange.com/questions/774748 - https://unix.stackexchange.com/questions/774865

I'm starting three Qemu VMs, each with several network interfaces. The network interface config looks like this:

-nic user,hostfwd=tcp::"${ssh_ports[$machine]}"-:22,model=virtio-net-pci \
-nic bridge,br="${bridge1}",model=virtio-net-pci
...

In all machines, I find that the first network device's MAC address is 52:54:00:12:34:56, the second ...:57, the third ...:58 and so on. This leads to a conflict of MAC addresses between my VMs. How can I let Qemu randomly assign the MAC addresses? PS: * Not sure if this is relevant: I have two bridge interfaces, and each VM has one network interface in the first bridge, and one network interface in the second bridge. * I could of course use bash to generate some random number and then explicitly set it as a parameter. I would find it nicer if Qemu would just do that itself though. * A quick search revealed questions from people that wanted to reach the opposite: have Qemu assign some predetermined MAC. Those questions sounded like random assignment of MAC addresses is actually the default.

I am trying to implement packet forwarding using a BPF-program. The idea is to forward a suitable packet from veth1 (ingress) directly to veth2 (egress). The problem I am facing is that the redirected packets seem to be dropped by the bridge v-net-1. I have been analyzing the traffic with Wireshark and the packets leave from veth2 and enter at veth2-br just as intended but never reach veth3-br. Now there are a few things where I do not really understand why they are happening. The first would be that when I turn off my BPF-program and let the user-space-program build the packet the destination IP address of the packet is the one of the bridge (192.168.11.10), however the way I understood IP addresses was that they are end-to-end i.e. there should be the IP address of the client in the packet (192.168.11.1) and only the MAC addresses would change while routing the packet. The second one would be that a packet created by my BPF-program, which has the exact same MAC and IP entries, is not sent to veth3-br, while one created by the user-space-program is sent there. The UDP-port is the only thing that differed between my tries but as far as I understand it that cannot be the reason for a drop since the bridge is not considering l4 protocols. The setup looks like this:

_______________________________________              ______________________
  |            Relay namespace            |            |   Client namespace   |
  |    ______________   ______________    |            |     ____________     |
  |   | 192.168.10.2 | | 192.168.11.2 |   |            |    |192.168.11.1|    |
  |___|____veth1_____|_|____veth2_____|___|            |____|____veth3___|____|
 	                          \                                   /
				               \                                 /
				                \                               /
				         	     \                             /
				        	    __\ _________________________ /
				          	   /veth2-br|            |veth3-br\
					           |                              |
				        	   \__________v-net-1_____________/
				        	                 /
				        	       ip: 192.168.11.10
					               net: 192.168.11.0/24

the link info of the relay namespace is:

9: veth1@if8:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a2:85:a2:09:2a:77 brd ff:ff:ff:ff:ff:ff link-netnsid 0
14: veth2@if13:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ce:b8:3f:d5:f3:17 brd ff:ff:ff:ff:ff:ff link-netnsid 0

the link info of the global namespace is:

10: v-net-1:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d6:06:cb:05:65:62 brd ff:ff:ff:ff:ff:ff
11: veth3-br@if12:  mtu 1500 qdisc noqueue master v-net-1 state UP mode DEFAULT group default qlen 1000
    link/ether a6:bc:ae:a2:75:8f brd ff:ff:ff:ff:ff:ff link-netns client_ns
13: veth2-br@if14:  mtu 1500 qdisc noqueue master v-net-1 state UP mode DEFAULT group default qlen 1000
    link/ether 0a:85:99:6c:80:1f brd ff:ff:ff:ff:ff:ff link-netns relay_ns

the link info of the client namespace is:

12: veth3@if11:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether f2:51:1c:4c:2b:0b brd ff:ff:ff:ff:ff:ff link-netnsid 0

and the bridge forwarding database looks like that:

33:33:00:00:00:01 self permanent
01:00:5e:00:00:6a self permanent
33:33:00:00:00:6a self permanent
01:00:5e:00:00:01 self permanent
33:33:ff:05:65:62 self permanent
01:00:5e:00:00:fb self permanent
33:33:00:00:00:fb self permanent
d6:06:cb:05:65:62 vlan 1 master v-net-1 permanent
d6:06:cb:05:65:62 master v-net-1 permanent

Running Ubuntu 22.04.3 LTS on top of WSL2 Output of ifconfig: eth0: flags=4163 mtu 1492 inet 172.28.193.11 netmask 255.255.240.0 broadcast 172.28.207.255 inet6 fe80::215:5dff:fe3e:7ffa prefixlen 64 scopeid 0x20 ether 00:15:5d:3e:7f:fa txqueuelen 1000 (Ethernet) RX packets 1402 bytes 590609 (590.6 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 163 bytes 52446 (52.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Output of ipconfig /all from PowerShell (pardon my machine's French): Configuration IP de Windows Nom de l’hôte . . . . . . . . . . : Zenbook-OZ Suffixe DNS principal . . . . . . : Type de noeud. . . . . . . . . . : Hybride Routage IP activé . . . . . . . . : Non Proxy WINS activé . . . . . . . . : Non Liste de recherche du suffixe DNS.: Speedport_W_724V_01011603_07_008 Carte réseau sans fil Connexion au réseau local* 1 : Statut du média. . . . . . . . . . . . : Média déconnecté Suffixe DNS propre à la connexion. . . : Description. . . . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter Adresse physique . . . . . . . . . . . : 3E-55-76-BE-66-95 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Carte réseau sans fil Connexion au réseau local* 2 : Statut du média. . . . . . . . . . . . : Média déconnecté Suffixe DNS propre à la connexion. . . : Description. . . . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2 Adresse physique . . . . . . . . . . . : 3E-55-76-BE-76-85 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Carte réseau sans fil Wi-Fi : Suffixe DNS propre à la connexion. . . : Speedport_W_724V_01011603_07_008 Description. . . . . . . . . . . . . . : MediaTek Wi-Fi 6E MT7922 (RZ616) 160MHz Wireless LAN Card Adresse physique . . . . . . . . . . . : 3C-55-76-BE-46-B5 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Adresse IPv6. . . . . . . . . . . . . .: 2003:c5:c715:bad9:aa0e:5e09:f399:6903(préféré) Adresse IPv6 temporaire . . . . . . . .: 2003:c5:c715:bad9:fc98:b63c:31e6:1374(préféré) Adresse IPv6. . . . . . . . . . . . . .: 2003:c5:c715:badb:904b:d90b:7543:f858(déprécié) Adresse IPv6 de liaison locale. . . . .: fe80::f215:b016:e094:6711%13(préféré) Adresse IPv4. . . . . . . . . . . . . .: 192.168.2.106(préféré) Masque de sous-réseau. . . . . . . . . : 255.255.255.0 Bail obtenu. . . . . . . . . . . . . . : mercredi 13 mars 2024 01:52:12 Bail expirant. . . . . . . . . . . . . : jeudi 4 avril 2024 00:38:51 Passerelle par défaut. . . . . . . . . : fe80::1%13 192.168.2.1 Serveur DHCP . . . . . . . . . . . . . : 192.168.2.1 IAID DHCPv6 . . . . . . . . . . . : 121394550 DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2C-2A-D6-E9-00-4C-E0-86-43-54 Serveurs DNS. . . . . . . . . . . . . : fe80::1%13 192.168.2.1 NetBIOS sur Tcpip. . . . . . . . . . . : Activé Carte Ethernet Connexion réseau Bluetooth : Statut du média. . . . . . . . . . . . : Média déconnecté Suffixe DNS propre à la connexion. . . : Description. . . . . . . . . . . . . . : Bluetooth Device (Personal Area Network) Adresse physique . . . . . . . . . . . : 3C-55-76-BE-46-B6 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Carte Ethernet vEthernet (WSL (Hyper-V firewall)) : Suffixe DNS propre à la connexion. . . : Description. . . . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter Adresse physique . . . . . . . . . . . : 00-15-5D-AE-85-70 DHCP activé. . . . . . . . . . . . . . : Non Configuration automatique activée. . . : Oui Adresse IPv6 de liaison locale. . . . .: fe80::5516:60d0:65b2:eb67%35(préféré) Adresse IPv4. . . . . . . . . . . . . .: 172.28.192.1(préféré) Masque de sous-réseau. . . . . . . . . : 255.255.240.0 Passerelle par défaut. . . . . . . . . : IAID DHCPv6 . . . . . . . . . . . : 587208029 DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2C-2A-D6-E9-00-4C-E0-86-43-54 NetBIOS sur Tcpip. . . . . . . . . . . : Activé **My question:** I don't understand where the IP address 172.28.193.11 (assigned to eth0 in the output ifconfig) comes from. The MAC address 00:15:5d:3e:7f:fa associated to eth0 in ifconfig does not appear anywhere in the output of ipconfig /all on PowerShell. To what network interface does the MAC address 00:15:5d:3e:7f:fa correspond?

In Red Hat Enterprise Linux (RHEL) 8, if someone does ifconfig eth0 hw ether abcd12341234, *all I know is ifconfig and ip -a*, so then is there a way to reliably get the real MAC address of that eth0 interface and if so how? ... other than for example rebooting to a Linux live CD coming from a reliable source to be sure the MAC address of the interface hasn't been changed.

I'm a networking senior guy steadily diving more into Linux internals over last 5 years, grasping networking caps a lot, however just arriving at Netfilter domain and learning of nftables last 3-4 days to achieve what I need in my lab. I made an honest search for "MAC address translation/NAT" in this and ServerFault portals to land here. I need to workaround some ESXI vSwitch lame VLAN mgmt capabilities when doing VM Linux bridging and **want to translate both ARP-hw_addr and real packets' MAC addresses to match MAC@ of VNIC assigned to Linux VM port**, as subject. Full story shared on https://docs.google.com/document/d/1TBFYlO-n8G-inYO6cdnMnSEeYUP2Ch9vWNO_TwIxK9M/edit?usp=sharing By reference, what **I can do is to statically translate** single host's MAC-related properties on opposite VM port/VLAN-dev (per my ref) by matching e.g. Y-side host IP@ and translating its MAC@ in both ARP and real Eth header to that of MAC A (on X-side) and vice versa in opposite direction: table netdev mpls { chain input { type filter hook ingress device "mpls" priority filter; policy accept; arp daddr ip 172.16.100.189 arp daddr ether set 00:50:56:01:00:61 counter ether daddr 00:50:56:01:02:03 ether daddr set 00:50:56:01:00:61 counter accept } chain output { type filter hook egress device "mpls" priority filter; policy accept; arp saddr ip 172.16.100.189 arp saddr ether set 00:50:56:01:02:03 counter ether saddr 00:50:56:01:00:61 ether saddr set 00:50:56:01:02:03 counter accept } } **But I need to do this dynamically in scale**, to match on selected IP addresses and let NF do 2-way job on the fly. I hope other networking/virtualization fellows may find this useful to workaround some vSwitch insufficiences (subjective perspective). **Question:** How to do this dynamically using ton of Netfilter caps working after netdev domain? If can't, only nf-queue call in bridge family with custom app could do this? BR Peter

#!/usr/bin/bash
echo "Give me your private IP and its mask";read given
if [[ "$given" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}/{0,1}[0-9]{1,3} ]]; then
    echo "version 4"
    doas nmap -sn "$given"
    arp
else
    echo "version 6"
    prefix=${given::6}
    mask=$(echo "$given"|sed -E 's|.*(/[0-9]{1,3})|\1|')
    echo "$mask"
    echo "$prefix"
    doas nmap -6 -sn "$given" #halts, I have to press Ctrl-C
    doas nmap -6 --script=neighbors "$given" #does not work
    doas nmap -6 --script=neighbors "$prefix$mask" #does not work
    doas ip -6 neighbour #empty line, no results
fi

Give me your private IP and its mask
fe80::xxxx:xxxx:xxxx:xxxx/64
version 6
/64
fe80::
doas (j@j-AERO-17-KC) password: 
Starting Nmap 7.80 ( https://nmap.org  ) at 2023-11-26 12:55 CET
Interrupt
doas (j@j-AERO-17-KC) password: 
Starting Nmap 7.80 ( https://nmap.org  ) at 2023-11-26 12:59 CET
NSE: failed to initialize the script engine:
/usr/bin/../share/nmap/nse_main.lua:818: 'neighbors' did not match a category, filename, or directory
stack traceback:

	/usr/bin/../share/nmap/nse_main.lua:818: in local 'get_chosen_scripts'
	/usr/bin/../share/nmap/nse_main.lua:1310: in main chunk


QUITTING!
doas (j@j-AERO-17-KC) password: 
Starting Nmap 7.80 ( https://nmap.org  ) at 2023-11-26 12:59 CET
NSE: failed to initialize the script engine:
/usr/bin/../share/nmap/nse_main.lua:818: 'neighbors' did not match a category, filename, or directory
stack traceback:

	/usr/bin/../share/nmap/nse_main.lua:818: in local 'get_chosen_scripts'
	/usr/bin/../share/nmap/nse_main.lua:1310: in main chunk


QUITTING!

I replaced with x some of the digits of my address - for the sake of preserving my privacy. **1.** Why does my script halt on doas nmap -6 -sn "$given" when an IPv6 address is given **2.** doas nmap -6 --script=neighbors "$prefix$mask" was suggested by ChatGPT to me - why doesn't it work? **3.** Why doesn't doas ip -6 neighbour work?

I've got an ubuntu linux PC on a private 192.168.x.y LAN. It's got an IP on the 0 subnet (192.168.0.y) and is able to ping other PC's on the 0 subnet. It looked like the _gateway MAC address had been hardcoded, so I was unable to reach any other subnet until I read this article . It had me run sudo ip nei flush all so that my ARP table would be cleared. This worked initially but a little bit later I was unable to ping the PC again; the ARP table reverted to the old hardcoded MAC address for the _gateway entry in the ARP table. Where in linux would someone set up a periodic change of the MAC address for the _gateway entry in the ARP table?