Date: Thu, 3 Aug 2000 19:35:19 -0400 (EDT) From: "Vladimir N. Silyaev" <vsilyaev@mindspring.com> To: rwatson@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vmware changes result in nasty bridging mess Message-ID: <200008032335.TAA01440@jupiter.delta.ny.us> In-Reply-To: <Pine.NEB.3.96L.1000802193745.97709C-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000802193745.97709C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In muc.lists.freebsd.hackers, you wrote: > >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >bridge_in-- reading table >... > >The vmware2 port now seems to enable bridging by default, and generate a >kernel message for every ethernet packet sent. FreeBSD bridge code doesn't have any vmware related modifications. Only one modification what was impelmented, it's a special sysctl net.link.ether.bridge_refresh, which provied support for loadable ethernets drivers. The rest of bridging code didn't touched at all. >Bridging on by default may >have nasty side effects for multi-interface machines (especially security >side effects). It's several ways to work around about that: - compile kernel without bridging support. - remove bridge starting code vmware.sh file in rc.d directory. - create special bridge cluster with one real interface and with one emulated >I haven't read the code (I admit) but I finding the >current behavior both (a) irritating (messages) and (b) worrying >(unpredicted bridging with potential side effects). I don't know I never seen such effect. Could you to do more testing about that. -- Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008032335.TAA01440>