Updated all my machines to r354217 this week and began running into an issue where once rebooted OpenVPN stopped working. Turns out that all the tap0 interfaces on the machines when they came back up had the MAC 58:9c:fc:10:ff:c4, which prevents prevents ARP from working. To reproduce this... ifconfig tap create ifconfig tap0 ifconfig tap0 destroy ifconfig tap create ifconfig tap0 ifconfig tap0 destroy ifconfig tap create ifconfig tap0 ifconfig tap0 destroy And each time on each machine it will be created with the same MAC. The work around for this is to add a manually set random MAC in via 'ether random' for the line for it in rc.conf.
Thank you for the report Zane Could you please provide additional information including: - Exact uname -a output - /etc/rc.conf output, (as an attachment), sanitized where necessary - /var/run/dmesg.boot output (as an attachment - openvpn configuration (as an attachment) sanitized for any key/password material and hostnames/ips) - The version of FreeBSD you were on prior to the update to stable/12 @ r354217
Created attachment 208846 [details] relevant client rc.conf bits
Created attachment 208847 [details] relevant server rc.conf bits
Created attachment 208848 [details] client openvpn config
Created attachment 208849 [details] server openvpn config
Created attachment 208850 [details] client boot dmesg
Created attachment 208851 [details] server boot dmesg
Created attachment 208852 [details] kernel config... includes ALTQ bits and GENERIC
FreeBSD vixen42.vulpes.vvelox.net 12.1-STABLE FreeBSD 12.1-STABLE r354217 vixen42 amd64 Forget what the earlier version was. Was like a 12-STABLE from a few months back. Likely r346624 or around there. Tested on r346624 and it does not exhibit that behavior at all. Nothing though that should be causing this in the config. Was Same config prior to reboot. The openvpn stuff is irrelevant as well. For example openvpn will never have touched tap6 in the config and if I do ifconfig tap6 create it will end up with the MAC 58:9c:fc:10:ff:86.
The driver tap(4) was recently rewritten and merged with tun(4) driver to single if_tuntap(4) driver. This may be reason behaviour change. The code now tries to create unique but stable (non-random) MAC adress based on interface name and contents of sysctl kern.hostuuid of the host or jail owning the interface. Please verify if all your systems have different kern.hostuuid or not and report back.
It is the same on every machine. That said I compile the world and kernel on one build system and use that for every where.
(In reply to Zane C. Bowers-Hadley from comment #11) Interesting! That's not supposed to happen. =( Some follow-up questions: 1. You don't inadvertently copy a /etc/hostid from one machine to many others, correct? 2. Is smbios data sane/populated on these systems? In particular, kenv smbios.system.uuid Thanks, and sorry for the breakage. =(
Hmm... Strange. Yeah, that file is the same on affected machines. I don't recall copying it though. smbios.system.uuid is not populated... actually it does not even exist, even after loading smbios(not tried it post rebooting).
(In reply to Zane C. Bowers-Hadley from comment #13) The file is generated at boot time if it does not exists. Your hardware seems to have identical/incorrect SMBIOS data, so host id/uuid generated does not differ. Maybe you should perform one-time manual randomization for /etc/hostid because you could get into other problems due to non-unique host identifiers that are supposed to be unique.
(In reply to Eugene Grosbein from comment #14) Just checked and removing it does result in it being regenerated with a new and different ID. Looks like I did at some time accidentally copy it between all of them. And it does come up with a different MAC as well, so all good. :)