Date: Thu, 1 Nov 2018 19:24:54 +0100 From: Andrea Venturoli <ml@netfence.it> To: freebsd-virtualization@freebsd.org Subject: Re: Network identification problem with Windows 10 on bhyve Message-ID: <15402830-012b-d482-4da4-b28e2871420c@netfence.it> In-Reply-To: <76ae92a5-4ade-8798-d584-eba2ccf35709@netfence.it> References: <0de2dbf1-bb31-e10b-777b-b93d6ca92683@netfence.it> <8cad7f22-946c-915d-c6e4-a55d682e9f29@omnilan.de> <76ae92a5-4ade-8798-d584-eba2ccf35709@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/26/18 12:05 PM, Andrea Venturoli wrote: > I'm trying sysctl net.link.bridge.inherit_mac=1, to see if it makes any > difference. It looks like this does the trick, although I'm not sure yet; however, it breaks other things. In fact, in order to get a more deterministic behaviour with ipfw, I have: net.link.bridge.pfil_bridge=0 net.link.bridge.pfil_local_phys=1 Having the same MAC address on the bridge and the physical interfaces doesn't allow incoming packet to be assigned to the correct one. > I'll also check and see if the tap adapter MAC address changes over > reboots. In fact tap0's MAC changes after every reboot. As soon as I have the chance, I'll try and see if I can fix this. bye av.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15402830-012b-d482-4da4-b28e2871420c>