lagg0 and wlan0 - Link aggregation & network interface dependency issue

Hi

I'm experiencing a problem with link aggregation on my laptop. lagg0 aggregates my wired and wireless interfaces (em0 and wlan0 respectively) as described in the handbook. It works "manually", but when configured by rc.conf there appears to be a problem due to the wlan0 interface not being ready before the lagg0 is configured.

My rc.conf snippet:

Code:
ifconfig_em0="ether 00:24:d7:6a:7f:58 up"
ifconfig_iwn0="up"
wlans_iwn0="wlan0"
ifconfig_wlan0="country GB WPA up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP SYNCDHCP up"

Starting the interfaces via rc.d:

Code:
root@tma1> /etc/rc.d/netif start
ifconfig: create: [B]bad value[/B]
ifconfig: SIOCS80211: Device busy
Starting wpa_supplicant.
ifconfig: SIOCSLAGGPORT: Device busy
Starting dhclient.
lagg0: no link .............. giving up
/etc/rc.d/dhclient: WARNING: failed to start dhclient
Starting Network: lo0 em0 iwn0 lagg0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
        inet 127.0.0.1 netmask 0xff000000 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:24:d7:6a:7f:58
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
iwn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
        ether 00:24:d7:6a:7f:58
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
        status: associated
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether 00:24:d7:6a:7f:58
        inet6 fe80::224:d7ff:fe6a:7f58%lagg0 prefixlen 64 scopeid 0x6 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
        laggproto failover lagghash l2,l3,l4

[b]laggport: wlan0 flags=4<ACTIVE> [I]<--- this line is missing [/I][/b]

        laggport: em0 flags=1<MASTER>
root@tma1>

By elimination I'm pretty sure the "bad value" message comes from the "laggport wlan0" clause in the ifconfig_lagg0 rc.conf line.

If I then manually enter [cmd=]ifconfig lagg0 laggport wlan0[/cmd] then all is well, however that is no good during boot and as a result a load of my boot processes are failing due to no network.

I can't see any way to force lagg0 configuration to wait for its component interfaces to be configured (wlan0 instantiation apparently being non-instantaneous).

Can anyone suggest solutions/hacks/commiserations? :)

Much obliged,

sim
 
In case anyone is interested, I have found a possible workaround which, at least on first inspection, appears to work:

Add to devd.conf:
Code:
notify 0 {
match "system" "IFNET";
match "subsystem" "wlan0";
match "type" "LINK_UP";
media-type "802.11";
action "ifconfig lagg0 laggport wlan0";
};

I'll mark this as SOLVED (for now...).

sim
 
PS: and remove
Code:
laggport wlan0
from the ifconfig_lagg0 clause in rc.conf.

sim
 
I wrote too soon, this solution does not work. I'm not sure why I thought it did!

With the devd.conf hack in place, boot fails because of the following sequence:

1) lagg0 initially configured with em0 only (intentional)
2) SYNCDHCP clause on lagg0 causes lagg0 to try to get a DHCP configuration from the (not connected) cable LAN. This obviously fails.
3) wlan0 eventually shows up.
4) devd.conf rule is triggered to add wlan0 to lagg0, which it does successfully.
5) However lagg0 doesn't try to configure itself with DHCP again, even though it could now do so successfully.
6) A bunch of network dependent services fail (ntp, nfs*, mountd et al), (i.e those which "REQUIRES: NETWORKING"). They think NETWORKING is enabled (which it is) but don't realise it didn't get configured properly. In fact it's worse because each service blocks for 30-60 seconds before giving up. :(

For now I've removed the link aggregation stuff and have gone back to wlan only. :\

sim
 
Did you try exact config as described in Handbook as first?

In your case something like
Code:
ifconfig_bge0="up"
ifconfig_iwn0="ether 00:24:d7:6a:7f:58"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA" #country settings may wait to next iteration :)
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP"

From rc.conf()
Code:
[FILE]synchronous_dhclient[/FILE]
(bool) Set to ``YES'' to start dhclient(8) synchronously at startup.  This behavior can be overridden on
a per-interface basis by replacing the ``DHCP'' keyword in the ifconfig_<interface> variable with
``SYNCDHCP'' or ``NOSYNCDHCP''.
 
sim said:
4) devd.conf rule is triggered to add wlan0 to lagg0, which it does successfully.
5) However lagg0 doesn't try to configure itself with DHCP again, even though it could now do so successfully.

What about
Code:
action "ifconfig lagg0 laggport wlan0 && dhclient lagg0";
 
I follow the handbook to configure lagg0 in my notebook without any problem. I review your rc.conf, you does not exactly follow the handbook's template. May be this is the cause led to failure.

sim said:
My rc.conf snippet:

Code:
ifconfig_em0="ether 00:24:d7:6a:7f:58 up"
ifconfig_iwn0="up"
wlans_iwn0="wlan0"
ifconfig_wlan0="country GB WPA up"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP SYNCDHCP up"

However, the template in handbook does:
  1. to enable ethernet interface
  2. to write down the ethernet interface's MAC address in paper
  3. to enable wireless interface, at the same time, to rewrite the wireless interface's MAC address and sync it with ethernet interface's MAC address by "ifconfig ether" command
  4. create wlan0 interface
  5. configure wlan0 interface with WPA options
  6. clone lagg0 interface
  7. configure lagg0 to enable failover with em0{/FILE] and wlan0
    [*]dhclient lagg0 to catch ip address and dns servers.


In you rc.conf, the sqeunce of synchronize MAC addresses between em0 and iwn0 do not follow the template of Handbook.
 
Re: lagg0 and wlan0 - Link aggregation & network interface d

I also just tried the lagg0 setup for wireless fallback and wired internet, but it didn't work right and I just realized why: my wired connection needs to have a different ip than the wireless connection, since they don't go to the same router. Does anyone have any advice in this case?

I tried this, but it was unsuccessful:

Code:
ifconfig_em0="up DHCP"
ifconfig_iwn0="ether 3c:97:0e:77:80:b5"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0"

The following works until the active interface changes, since after that ip that had been given by dhclient is invalid:

Code:
ifconfig_em0="up"
ifconfig_iwn0="ether 3c:97:0e:77:80:b5"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"

Thanks.
 
The above did not work for me, but I found this: http://www.freebsdonline.com/content/view/718/524/
the link suggests applying the WIFI MAC to the Ethernet. maybe I found this worked when using wpa_supplicant for ssid management

sh:
# wired
ifconfig_em0="up"
ifconfig_em0_alias0="ether ${WIFIMAC}"

# wireless
wlans_iwm0="wlan0"
ifconfig_wlan0="WPA"
create_args_wlan0="country ${COUNTRY}"

# lagg
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"
ifconfig_lagg0_ipv6="inet6 accept_rtadv"
 
...my wired connection needs to have a different ip than the wireless connection, since they don't go to the same router. Does anyone have any advice in this case?
I'm fairly certain lagg will not do what you want. The lagg interface is for layer-2 failover, and masks any changes at that layer from higher layer protocols like DHCP.

I suspect you could get around this by configuring them as entirely separate interfaces, then select which interface is used via the default route in the routing table. I don't know off the top of my head any tools to make this easy or sane, but there are several other posts on this forum about this particular topic.
 
Back
Top