tap(4): half-duplex and zero-speed ?

[Ben Woods]

On Thu, 23 Feb 2017 at 8:43 pm, Alexandre Snarskii <snar at snar.spb.ru> wrote:

>
> Hi!
>
> Long story short: if you try to aggregate tap(4) devices into lacp-based
> lagg(4), aggregate will fail to negotiate lacp with remote end and will not
> be able to pass traffic.
>
> Root cause: lacp code requires underlying interface to be full-duplex
> (else it will not participate in lacp negotiation at all[1]) and have
> non-zero speed (else it can not be selected as active aggregator[2],
> and so if tap is the only lagg member - aggregate will not become active).
>
> Patch can be as trivial as:
>
> --- sys/net/if_tap.c.orig       2017-02-21 21:02:04.460053000 +0300
> +++ sys/net/if_tap.c    2017-02-21 21:02:12.580696000 +0300
> @@ -617,7 +617,7 @@
>                         dummy = ifmr->ifm_count;
>                         ifmr->ifm_count = 1;
>                         ifmr->ifm_status = IFM_AVALID;
> -                       ifmr->ifm_active = IFM_ETHER;
> +                       ifmr->ifm_active = IFM_ETHER | IFM_1000_T |
> IFM_FDX;
>                         if (tp->tap_flags & TAP_OPEN)
>                                 ifmr->ifm_status |= IFM_ACTIVE;
>                         ifmr->ifm_current = ifmr->ifm_active;
>
>
> [1]:
> https://svnweb.freebsd.org/base/head/sys/net/ieee8023ad_lacp.c?revision=312678&view=markup#l483
> [2]:
> https://svnweb.freebsd.org/base/head/sys/net/ieee8023ad_lacp.c?revision=312678&view=markup#l983



Hi Alexandre,

Thanks for taking the time to look into the cause of this and for your
clear explanation of the problem.

Would you mind please submitting a bug report so this doesn't get forgotten?
https://bugs.freebsd.org/

Regards,
Ben
-- 

--
From: Benjamin Woods
woodsb02 at gmail.com