Re: Inconsistent behavior with wpa / devd / network interfaces

From: Cy Schubert <>
Date: Thu, 30 May 2019 12:37:59 -0700
In message <>, Johannes 
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 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 {} 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.

Cy Schubert <>
FreeBSD UNIX:  <>   Web:

	The need of the many outweighs the greed of the few.
Received on Thu May 30 2019 - 17:38:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC