From owner-freebsd-current@freebsd.org Thu May 30 19:38:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C96F15A8F5F for ; Thu, 30 May 2019 19:38:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A363F6B12A; Thu, 30 May 2019 19:38:06 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id WQsDhAFxDGusjWQsEhMI33; Thu, 30 May 2019 13:38:04 -0600 X-Authority-Analysis: v=2.3 cv=fOdHIqSe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=E5NmQfObTbMA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=uAulVrp6mufAFwu96jAA:9 a=UJXRCHpk5MLBRmAW:21 a=_FIolvARWdt5fk_x:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id EF086E37; Thu, 30 May 2019 12:37:59 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x4UJbxfE065143; Thu, 30 May 2019 12:37:59 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x4UJbxtB065140; Thu, 30 May 2019 12:37:59 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201905301937.x4UJbxtB065140@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Johannes Lundberg cc: Greg Rivers , freebsd-current@freebsd.org Subject: Re: Inconsistent behavior with wpa / devd / network interfaces In-Reply-To: Message from Johannes Lundberg of "Thu, 30 May 2019 10:22:24 -0700." <85a5bf45-231e-1bb4-4c26-677e414af96f@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 May 2019 12:37:59 -0700 X-CMAE-Envelope: MS4wfCsc5MBqZkjiLYuSGfZfdFRjQ0duJ/ftxChomfa0oj6n9xBy6+nELVqd0A8EgLjs2SDFG6qVoKf7ufMANnEWAgHesksltPwIxDn+eSy13y3QF6Kn3Dmg J4e4qu7NG5UEUvqlyy/XfwqE7LDBNAEYNC+y9We2amwoArp8Ea+YiCt/3CB18ujvyL13eMLRT303Hr3kO90YncXIJDVl2pzOGQ/6lw6ZDGlVPif79ObofbuK hUuu8L1VidamBOViQRamzzAzTTJQJqcicjc6ejLmqs8= X-Rspamd-Queue-Id: A363F6B12A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd-current]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-2.38)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.26), asn: 6327(-2.52), country: CA(-0.09)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 19:38:08 -0000 In message <85a5bf45-231e-1bb4-4c26-677e414af96f@FreeBSD.org>, Johannes Lundber g writes: > > On 5/30/19 9:37 AM, Greg Rivers wrote: > > On Thursday, May 30, 2019 10:31:45 AM CDT Johannes Lundberg wrote: > >> Hi > >> > >> I have a bridge and an ethernet/wifi lagg failover like this: > >> > >> # First define all cloned interfaces > >> cloned_interfaces="bridge0 lagg0" > >> > >> # bhyve bridge > >> ifconfig_bridge0="inet 192.168.8.1/24 addm lagg0 up" > >> > >> # Ethernet/WiFi failvoer > >> ifconfig_em0="up" > >> wlans_iwm0="wlan0" > >> ifconfig_wlan0="WPA up" > >> create_args_wlan0="wlanaddr xx:xx:xx:xx:xx:xx" > >> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP up" > >> > >> When I move between home and work networks and plug in the network cable > >> it sometimes reconfigure and sometimes (mostly) not. Looking at devd > >> output from a failed occasion and I can see that it calls dhclient on > >> em0 and not lagg0. But it since it works sometimes I don't know if this > >> is correct or not (I would expect lagg0 and not em0 but manually running > >> this command with either em0 or lagg0 doesn't do anything)... > >> > >> devd log: Executing 'service dhclient quietstart $'em0'' > >> > >> In addition to this, I often have to run ifconfig wlan0 scan (or service > >> netif restart) or to have the it reconnect to a different wifi. It > >> doesn't seem to be doing any periodical scanning and reconnecting at all > >> (but maybe that's a different issue). > >> > >> For sometime now I usually have to run service netif restart to get > >> network working after switching location, followed by adding all my VM > >> tap interfaces to the bridge manually, and restarting bhyve guests > >> because they lose connectivity.. It's getting a bit tiring and I would > >> like to find a solution. > >> > >> Do I have something weird in my setup causing this? I don't recall ever > >> having this issue when not using failover lagg. Running recent 13-CURRENT. > >> > > I think there's a (unknown?) problem that makes lagg(4) incompatible with > > bridge(4). I've never been unable to make a lagg interface work as a member > of > > a bridge. Lacking the time to pursue it, I've resorted to NATing instead. > > > > Also, wlan interfaces tend to break if you change their MAC address. So in > a > > lagg consisting of a wlan interface and a ethernet interface (without a > > bridge), I always set the MAC of the ethernet to match the native MAC of th > e > > wlan, and not vice versa. > > > Hi > > Thanks for the reply! I could try to reverse the MAC address setting to > see if that helps. > > I'm also running NAT like this for bhyve guests > > % cat /etc/pf.conf > nat on lagg0 from {192.168.8.0/24} to any -> (lagg0) > > The "bhyve bridge" bridge0's members are lagg0 and the tapX interfaces. > This setup works great as long as external connection doesn't change. I > have full connectivity between host<->guests and guests can access > internet as well (with seamless switching between ethernet/wifi *). The > bhyve guests are configured with static IP addresses 192.168.8.X. > > * Sometimes seamless, sometimes not so much... I use a similar configuration except to use $cloned_interfaces. The caveat is, if on the same network switching from wired to wireless and back again is seamless. However if the wired and wireless networks are on different segments, because dhclient isn't recycled one needs to restart dhclient manually. The problem is that when switching from wired to wireless or back you are on another network, there is no way to know what network you're on until dhclient is killed and restarted. OK, so we automatically restart dhclient every time then: Problem: this is highly disruptive when you happen to be connected to the same network don't need dhclient restarted but is restarted anyway, e.g. the network address is the same. The trade-off is take a hit every time there is a reconnect and leave it to the user to do what is best. Example: I use one of my networks is no problem but use my wife's wireless network on a different segment there is a problem. A laptop doesn't know what network it's on merely by associating to a network. Sure, this can be scripted but that opens another can of worms, that being any solution would be site-specific to one degree or another. Regardless, changing the behaviour would be a POLA violation, unless the behaviour is a user selectable option. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.