From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 19:33:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DED63C3 for ; Mon, 15 Dec 2014 19:33:42 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EFD6CCF for ; Mon, 15 Dec 2014 19:33:41 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id x12so15439741wgg.25 for ; Mon, 15 Dec 2014 11:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=N7NcDxAVEHuKbHza0xpftwwQwUhlGC+AK0ShwtKjedc=; b=JNoJc3pJffEca+XUbKR2J68Q9HdP6fu/DgFMTyUuYT/u67/6UuhNplAaTEVCqjEtmu KDiqSHtwf5JqCkr8rXdtE8h5V+etfyBgUCFFjBEDmU1Lsz5zov+8/etNIblErv05R310 qk5TdKtLeiLkAusuu5Z78AbR8jVw7HsYvKzK/iit8Ob2msKJz18fxKeVeCxQdps9xjU4 2XggYnWCqTSHFCaHpQimVkrUM/fmEdl1Os1yWeyK6jRonLaezzml6XtWN1rq4mXrLrw5 0ledlzetowks1iRXe+LL/JwmrNFeLm5LAlpZ9ACWIOCTpoqpf9+qa8ydXd4hEfz9vL9O AxOg== MIME-Version: 1.0 X-Received: by 10.180.84.134 with SMTP id z6mr12922865wiy.50.1418672020128; Mon, 15 Dec 2014 11:33:40 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Mon, 15 Dec 2014 11:33:40 -0800 (PST) In-Reply-To: <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> <34276C9E-CAEF-4E3F-AA2A-568F2D3099EC@dpdtech.com> Date: Mon, 15 Dec 2014 12:33:40 -0700 X-Google-Sender-Auth: 0Fvv5Hrt8qGawzr9cGKw8nxNcwQ Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Alan Somers To: "David P. Discher" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 19:33:42 -0000 On Sun, Dec 14, 2014 at 6:23 PM, David P. Discher wrote: > > So, I think I=E2=80=99ve identified the issue. In sys/net/ieee8023ad_lac= p.c, lacp_pdu_input() has a sanity check : > > if (m->m_pkthdr.len !=3D sizeof(*du)) { > goto bad; > } > > I added some debugging information in if_lagg, and ran with it. The lacp= du packet that being sent by the TP-Link switch is 4 bytes longer than the = FreeBSD "struct lacpdu du=E2=80=9D. > > em1: lacp_pdu_input-sizeof(du) bad m_pkthdr.len=3D128 sizeof(du)= =3D124 > > My packet captures shows the packet size differing as well. > > I=E2=80=99m still poking around. I=E2=80=99ve been trying to look for the= official LACPDU binary/wire format =E2=80=A6 if someone can point me to th= e reference for that, that would be helpful (at least my own understanding)= . Try here: http://standards.ieee.org/findstds/standard/802.1AX-2008.html > > Not exactly sure what these extra 4 bytes are at the end of the packet. = Still trying to figure that out. > > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz > > > > On Dec 4, 2014, at 8:41 PM, David P. Discher wrote: > >> Thanks Adam - >> >> On Dec 4, 2014, at 1:58 PM, Adam McDougall wrote: >> >>> >>> Is the switch side set to "active" for the lacp mode (instead of >>> passive)? Also, try: >>> sysctl net.link.lagg.0.lacp.lacp_strict_mode=3D0 >>> >>> If either of those work, I'll explain more, don't have time to dig for >>> old email right this minute. >> >> Yes, the switch was in active mode. Turn strict mode off (which I thoug= ht I did before, but of course this sysctl clears when destroying the inter= face). So, the LACP did finally negotiated, at least in ifconfig : >