Bug 241704 - if_tap: Not using random MAC upon creation
Summary: if_tap: Not using random MAC upon creation
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net mailing list
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2019-11-04 10:44 UTC by Zane C. Bowers-Hadley
Modified: 2019-11-05 08:46 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback? (kevans)


Attachments
relevant client rc.conf bits (365 bytes, audio/x-mod)
2019-11-04 11:59 UTC, Zane C. Bowers-Hadley
no flags Details
relevant server rc.conf bits (523 bytes, audio/x-mod)
2019-11-04 11:59 UTC, Zane C. Bowers-Hadley
no flags Details
client openvpn config (223 bytes, text/plain)
2019-11-04 12:01 UTC, Zane C. Bowers-Hadley
no flags Details
server openvpn config (631 bytes, text/plain)
2019-11-04 12:01 UTC, Zane C. Bowers-Hadley
no flags Details
client boot dmesg (16.89 KB, text/plain)
2019-11-04 12:02 UTC, Zane C. Bowers-Hadley
no flags Details
server boot dmesg (13.00 KB, text/plain)
2019-11-04 12:03 UTC, Zane C. Bowers-Hadley
no flags Details
kernel config... includes ALTQ bits and GENERIC (392 bytes, text/plain)
2019-11-04 12:06 UTC, Zane C. Bowers-Hadley
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zane C. Bowers-Hadley 2019-11-04 10:44:25 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-04 10:50:46 UTC
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
Comment 2 Zane C. Bowers-Hadley 2019-11-04 11:59:17 UTC
Created attachment 208846 [details]
relevant client rc.conf bits
Comment 3 Zane C. Bowers-Hadley 2019-11-04 11:59:48 UTC
Created attachment 208847 [details]
relevant server rc.conf bits
Comment 4 Zane C. Bowers-Hadley 2019-11-04 12:01:34 UTC
Created attachment 208848 [details]
client openvpn config
Comment 5 Zane C. Bowers-Hadley 2019-11-04 12:01:53 UTC
Created attachment 208849 [details]
server openvpn config
Comment 6 Zane C. Bowers-Hadley 2019-11-04 12:02:31 UTC
Created attachment 208850 [details]
client boot dmesg
Comment 7 Zane C. Bowers-Hadley 2019-11-04 12:03:15 UTC
Created attachment 208851 [details]
server boot dmesg
Comment 8 Zane C. Bowers-Hadley 2019-11-04 12:06:54 UTC
Created attachment 208852 [details]
kernel config... includes ALTQ bits and GENERIC
Comment 9 Zane C. Bowers-Hadley 2019-11-04 12:15:34 UTC
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.
Comment 10 Eugene Grosbein freebsd_committer 2019-11-05 04:31:46 UTC
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.
Comment 11 Zane C. Bowers-Hadley 2019-11-05 04:42:07 UTC
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.
Comment 12 Kyle Evans freebsd_committer 2019-11-05 04:52:30 UTC
(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. =(
Comment 13 Zane C. Bowers-Hadley 2019-11-05 05:06:26 UTC
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).
Comment 14 Eugene Grosbein freebsd_committer 2019-11-05 05:15:54 UTC
(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.
Comment 15 Zane C. Bowers-Hadley 2019-11-05 08:46:06 UTC
(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. :)