From owner-freebsd-net@freebsd.org Sun May 21 04:38:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E499DD77050; Sun, 21 May 2017 04:38:53 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A781635C; Sun, 21 May 2017 04:38:53 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:56955] helo=localhost) by dnvrco-omsmta02 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id 1C/E7-29375-6D911295; Sun, 21 May 2017 04:38:46 +0000 Date: Sun, 21 May 2017 04:38:46 +0000 Message-ID: <1C.E7.29375.6D911295@dnvrco-omsmta02> From: "Thomas Mueller" To: freebsd-current@freebsd.org CC: freebsd-net@freebsd.org, kevlo@freebsd.org Subject: Maintainershjip status regarding re(4) Ethernet driver? X-RR-Connecting-IP: 107.14.64.7:25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 04:38:54 -0000 Who is the maintainer, if any, for re(4) Ethernet driver that is again giving me trouble on Intel Ivy Bridge computer with MSI Z77 MPOWER motherboard? I remember Kevin Lo, but have checked the web archives for freebsd-current and freebsd-net, and find Kevin Lo's last posts were during October 2016. Is Kevin Lo still with FreeBSD? I just opened a bugzilla account with this Ethernet re(4) connectivity problem on my mind. I posted the details on this list five days ago but haven't had any response. Tom From owner-freebsd-net@freebsd.org Sun May 21 06:25:32 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78714D7773C; Sun, 21 May 2017 06:25:32 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCF67F37; Sun, 21 May 2017 06:25:31 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id v4L6NWGv061255 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 May 2017 14:23:34 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id v4L6NVwv061254; Sun, 21 May 2017 14:23:31 +0800 (CST) (envelope-from kevlo) Date: Sun, 21 May 2017 14:23:31 +0800 From: Kevin Lo To: Thomas Mueller Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Maintainershjip status regarding re(4) Ethernet driver? Message-ID: <20170521062331.GA61218@ns.kevlo.org> References: <1C.E7.29375.6D911295@dnvrco-omsmta02> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C.E7.29375.6D911295@dnvrco-omsmta02> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 06:25:32 -0000 On Sun, May 21, 2017 at 04:38:46AM +0000, Thomas Mueller wrote: > > Who is the maintainer, if any, for re(4) Ethernet driver that is again giving me trouble on Intel Ivy Bridge computer with MSI Z77 MPOWER motherboard? > > I remember Kevin Lo, but have checked the web archives for freebsd-current and freebsd-net, and find Kevin Lo's last posts were during October 2016. > > Is Kevin Lo still with FreeBSD? > > I just opened a bugzilla account with this Ethernet re(4) connectivity problem on my mind. > > I posted the details on this list five days ago but haven't had any response. I have no idea why you cc'd me. I'm not the maintainer of re(4). > Tom Kevin From owner-freebsd-net@freebsd.org Sun May 21 20:55:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 723BDD77C28 for ; Sun, 21 May 2017 20:55:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61D8C1E1D for ; Sun, 21 May 2017 20:55:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4LKth6h008422 for ; Sun, 21 May 2017 20:55:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213237] [ndis][patch] ndis wireless ieee80211 communication failure Date: Sun, 21 May 2017 20:55:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 20:55:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213237 Marius Strobl changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |glebius@FreeBSD.org CC| |marius@FreeBSD.org --- Comment #8 from Marius Strobl --- Assign to glebius@, who committed r286410. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun May 21 21:01:02 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66BD2D770D6 for ; Sun, 21 May 2017 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 350E4878 for ; Sun, 21 May 2017 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4LL01ZW015108 for ; Sun, 21 May 2017 21:01:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201705212101.v4LL01ZW015108@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 21 May 2017 21:01:02 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 21:01:02 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe New | 215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt New | 217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to Open | 173444 | socket: IPV6_USE_MIN_MTU and TCP is broken Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 218653 | Intel e1000 network link drops under high network 19 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun May 21 23:05:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEF99D77E9F for ; Sun, 21 May 2017 23:05:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id AE2E01CCD for ; Sun, 21 May 2017 23:05:35 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:7557:48c9:3a95:5037]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 87DDB46 for ; Mon, 22 May 2017 02:05:27 +0300 (MSK) Date: Mon, 22 May 2017 02:05:24 +0300 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <13310414754.20170522020524@serebryakov.spb.ru> To: freebsd-net@freebsd.org Subject: How to bring up interface without address? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 23:05:36 -0000 Hello Freebsd-net, I have "em1" interface which is container for several vlans, but it doesn't need any special configuration and it doesn't need IPv4 or IPv6 address. If I write this in /etc/rc.conf: ifconifg_em1="" vlans_em1="isp1 isp2" create_args_isp1="vlan 10" create_args_isp2="vlan 20" ifconfig_isp1="DHCP" ifconfig_isp2="DHCP" Startup script will not bring em1 UP automatically. So, I need some no-op option for ifconifg_em1 variable. What should I use? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-net@freebsd.org Sun May 21 23:15:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F31DD780EE for ; Sun, 21 May 2017 23:15:00 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B2F110CB for ; Sun, 21 May 2017 23:15:00 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id k91so71865588ioi.1 for ; Sun, 21 May 2017 16:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=f6FlXlO6O0So08PWjD8j8CqYc9DvglEgXjBl7BOEO4w=; b=H7fzUqrhgbSJoBjeHdyfEx9F/pVXrpPBHJ7IclqPeK+OFyU4OkkWgHEpK4OtFuCFSV AQZLP6LVe7Z1nqjqeRvphzDWpi8b4m3rrLCzCWNgW4q5a0pWjEQu23KEoMkVLYdkEQ26 6MT2tUm0I980xce74ZQPv/BRSMtbegvnEGZWw1JE8VFlI5UkXohBDZ7TAZ3w3iBI18Qg FTKBRnOdxdJHeEvdTVE2cU2gDr07Luju6mZ1KrCtaSdk6m/P0Lsv8WM3SUCW9rKKW8IA HCqhVn3b/RnAL0hwuUqdzEvAhFMWn/JasQUWTkszjih+a1cYbwX8/ee0yrTCIBSmZxU6 +Lpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=f6FlXlO6O0So08PWjD8j8CqYc9DvglEgXjBl7BOEO4w=; b=NVDLDDiukXJVmhHcTI6yrKyfumqK42B8jPh/luMO66x6c1b30EW+AqnNBEUZ0CFFLX cCW4+nlxhWz5kxRff3sFyx7zZfwzAMfj/LAEswNfzA6AJX+vL3S1q2osMynLo7kTVDTm +x5SNl+hy4DQTcafTYU2fdGVK39H54DDvPV8lAF/M3AK7Igh+6K/YJxM94TJ+59T1kDh 489VD57PN5mUBClBTqvlov5LRVQLVFShb2GC+VF0ikwVjAY2WkP6kkislzYu+oZ5MvtF e/WAnkl81ABronPmWIjww0Ed9e8/QnOTDI8sYmTtO+6KV5M8KmYlc0dvLJNvxk/LBnBJ cEkA== X-Gm-Message-State: AODbwcDZzuKn8NEYW4A6RO+98YQ517dFxxN86IIZRD/RaJvmjr6d5+Fe DBjArAZqg2+zaQCeLH1N0vYSnYcErw== X-Received: by 10.107.134.198 with SMTP id q67mr18243480ioi.28.1495408499348; Sun, 21 May 2017 16:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.69.194 with HTTP; Sun, 21 May 2017 16:14:58 -0700 (PDT) In-Reply-To: <13310414754.20170522020524@serebryakov.spb.ru> References: <13310414754.20170522020524@serebryakov.spb.ru> From: Kurt Buff Date: Sun, 21 May 2017 16:14:58 -0700 Message-ID: Subject: Re: How to bring up interface without address? To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 23:15:00 -0000 Your first line has a typo - it should be: ifconfig_em1="" but I've used this in /etc/rc.conf ifconfig_em1="up" to ensure that it's available. Kurt On Sun, May 21, 2017 at 4:05 PM, Lev Serebryakov wrote: > Hello Freebsd-net, > > I have "em1" interface which is container for several vlans, but it doesn't > need any special configuration and it doesn't need IPv4 or IPv6 address. > > If I write this in /etc/rc.conf: > > ifconifg_em1="" > vlans_em1="isp1 isp2" > create_args_isp1="vlan 10" > create_args_isp2="vlan 20" > > ifconfig_isp1="DHCP" > ifconfig_isp2="DHCP" > > > Startup script will not bring em1 UP automatically. So, I need some no-op > option for ifconifg_em1 variable. What should I use? > > -- > Best regards, > Lev mailto:lev@FreeBSD.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Mon May 22 06:33:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727AAD788B4 for ; Mon, 22 May 2017 06:33:27 +0000 (UTC) (envelope-from bounce-freebsd-net+freebsd.org@streturns.eu) Received: from mx-out-gi2.emailamp.com (mx-out-gi2.emailamp.com [89.238.184.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35A401A30 for ; Mon, 22 May 2017 06:33:07 +0000 (UTC) (envelope-from bounce-freebsd-net+freebsd.org@streturns.eu) DKIM-Signature: v=1; a=rsa-sha256; c=simple; s=email; d=emailamp.com; h=Reply-To:Content-Type:MIME-Version:Subject:List-Unsubscribe:From:To:Date: Message-ID:From:To:Subject; t=1495434795; x=1495456395; bh=qWDb7/+aXJD6lTcMvyE6VXWgBaftPaaEjnLuYg4qSjQ=; b=mI1xz0Q2ATFSJ3S2YwOSUZ0x26gyG8HiiBxKPM5Bc3OKcvkZwyyLp/hemvK1QD2TDR06ky2mEpkW 1juYxONOm2/ZWREt6raIQtL4wkfvRibmY1as8TbJ3GIP2sC0oVGM2yKqb7yUBLLA6SEKRLDtaGS5 Y4IHlkz8cYdThhHvicmKfa6a0F2IsalOkoRUblEP0seXLdljo5BVUdVgSnFXYcHqVHutBlgHvJjI BSqIMVpqs/wRDcVwaVuvmv9jS3NmKu9x5UlEAztEkPdL081D6iwrHMb1m22e+QEoZWzEQW5Koftr 9jnrMMIt9Z8jbHWvN4s5JWq13xVcPzijTbt1xw== Received: by mx-out-gi1.emailamp.com id h4a32m2akmce for ; Mon, 22 May 2017 09:18:23 +0300 (envelope-from ) Reply-To: MIME-Version: 1.0 Subject: Invitatie la dezvoltare - programele de training din perioada urmatoare From: Dynamic Training Solutions To: freebsd-net@freebsd.org Date: Mon, 22 May 2017 06:17:41 -0000 Message-ID: <592278d335692d2321dae839@training-info.ro> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 May 2017 06:33:27 -0000 | ![](http://nl.training-info.ro/V-YNXEOtk9LycdVdmfLC4ZFA1wIwRZOizaTyTPv_eU= aMaKZPX30eQZS8Pidv6jVwqGzaVD9LXlREukK3ygcbiWPCkXeaVGQw9ZciTzbc34v-M_h-AJAnX= aBjN-TTcMaq871j7l2IxY0uBnn78bV55kRs52w4dgGazAXWL4ZM8lSmGQaiEMdKVLKRdz5YLbSr= eW5-ihHbJpfCdgcPCUiclrf_10eDONUDN0_FlshthuKsU19EdlDiFnOkhILITm5IO7XKLFKSn35= fpT4cZB5n75WZbATfzm8M-mLtit9jtiQ0MSjvNxvTEhz5c0mUROrEh9XrM8R94IgyHP4_zoCzIh= ggvP2TkFC2dCWtIgVs90f_PstrXVKE9uozS8axK9VPlBP2Dz_Ud8WAE4TjgW-kQBOjMX3a7mHXb= dmiLnmRRb-ONZWjUcvb9UwWiwnTyHGLn8qOWUsf8m-xaPVHdPxSiEvBFYVXWqHY8MRexnvlWLSq= 9t2r3adHZtd4sD9IrqyCCZpOW7XUZB6vkXqNgQ) =20 --- =20 =20 **VREI S=C4=82 FII MAI BUN?** **VREI S=C4=82 =C3=8ENVE=C8=9AI MAI MULT =C3=8ENTR-UN TIMP MAI SCURT?** **Atunci, te invit=C4=83m la cursurile Dynamic Training Solutions!** =20 =20 | **Bine te-am gasit!** Pentru perioada **26 mai - 30 iunie** ti-am pregatit pentru dezvoltarea ta = sau a colegilor tai un numar de **33 programe de training**. Acestea se vor= desfasura in zone si locatii diferite, incepand cu Bucuresti, apoi continu= and cu mare (Mamaia si Balcic) si binenteles ajungand si la munte (Bran si = Poiana Brasov). Lista acestora o vei gasi ceva mai jos. Pentru a nu mai pierde timpul, te invit sa vizualizezi cateva informatii pr= ivind primul curs - **Negocierea pentru achizitori, buyeri si cei din comer= cial **ce se va derula in 26/27 mai in Bucuresti. Pentru acesta sau pentru = oricare din celelate traininguri te asteptam pe site-ul nostru pentru mai m= ulte informatii - [http://nl.training-info.ro/NKdoHZQNHUYBGQW31JbYQ2Fqt_YkW= pRfE3MYGzMB815KgxVShFJRMCl_Mb7bcptY7Wn75tMLIe3fo5kXyW8jXpK_A92Y4-SLX5WX-3Rl= fdACjVntkLfwj1uu7vglEhwT1iln2wHiClsPfEY5TRObap0V1EEahVHwS8v4UFv594liKiG49g0= bZ8VWuWd9k6s_sN6BAaHB_xftc7pMcdUS_WmqM5nKoecLnyQSYgL3Tc9iOT4smaZO07R1Bilclr= 2lLNPu4lgWJCxkJEPxBeXXFwJCZ2d0rSNHMAjzduD2Ts_IFhHUSYfiTOCIzp5UTXrni7uHTr5K8= y6K74XhbNP2hSpCkndyirXhAX0cGwGvvDaJUjOqHlty-u034ShCGV9H0O01DI4aFQ3yGPKgYqky= zgDmX0u9PEsFDS5IhaRv1uhWZqv9ig]() Iar daca nu te-am convins pana acum la actiune, te rog sa primesti si: **7 Motive pentru care s=C4=83 te =C3=AEnscrii la cursuri** **Ce o s=C4=83 =C3=AEnve=C8=9Bi:** 1. Cum s=C4=83 treci peste orice obstacol =C8=99i s=C4=83 legi parteneria= te de succes. 2. Cum s=C4=83 =C3=AE=C8=9Bi dezvol=C8=9Bi abilit=C4=83=C8=9Bile =C8=99i = s=C4=83 comunici eficient, =C3=AEntr-un mod profesionist. 3. Vei =C8=99ti ce strategii s=C4=83 aplici pentru a fi un om valoros, at= =C3=A2t ca =C8=99i angajat, c=C3=A2t =C8=99i antreprenor. 4. Vei =C8=99ti ce s=C4=83 faci ca s=C4=83 =C3=AEi cucere=C8=99ti pe cei = din jur =C8=99i s=C4=83 prime=C8=99ti un feedback pozitiv. 5. Vei descoperi cum s=C4=83 =C3=AE=C8=9Bi satisfaci nevoile =C8=99i care= sunt necunoscutele la care nu aveai r=C4=83spuns. 6. ****Vei avea oportunit=C4=83=C8=9Bi extraordinare datorit=C4=83 resurs= elor acumulate =C3=AEn urma cursurilor. 7. ******Vei investi =C3=AEn tine 100%. Vei livra valoare!** **MAI BINE PREG=C4=82TIT. ACCES SPRE SUCCES!** =20 =20 --- =20 =20 ****. **** **![](http://nl.training-info.ro/IGRQVoA8IOYhwfUjtGM16JV4tJN7PWCEez5ii4z83D= AJRxRTciB4pUyXmve9-T6AWBxwao_oeijxNGKqO3K3WiZgTpvf0WlJZlrFSe5B9d-eh0emjrEIG= TKcEasUGnKJ8pKfM1m_ufuj1Ms2jQ7XfrPZ89WpCYtUMK5JNy1D0OPVlffPVqsn2Lsc647eHVqW= RRL93pkQEgTLklnMJeYmOLYvius2by2neR7kWKdMD40KgbnpSZLch2lSgbBnXUkwk9T6DSM2S8h= -KqIrSRDCKCupT3_k3jUxMDok5bNr-WHnk-N-rDQJn7Is_peQdowASkhYMIX3fdBrBUf_XENlZV= wYoO0Jxs0AD2YIVZ3Z5NccjcmYmo1HxnSrY8vOeHW0_REC9WczKqadtcKjjoBi-My4gPL0NwvbF= QHvWPGirhCwKdsiMGodSzbpHnil59vvGJNiVel4Cg58geilHVLu3jCW7If68GIIQgiByCDp0qBD= f7j6i_H28fu9mDXMy_2WDCfKL-iU8vTnKMlA4w)** **Negocierea pentru achizitori, buyeri ** **s****au pentru cei din comercial =E2=80=93 26/27 mai** ** ** ** **Negocierea pentru achizitori, buyeri sau cei ce lucreaza in comercial = este unul dintre **cursurile foarte utile de recomandate pentru acesti spec= ialisti**. Parcurgand acest curs, achizitorii, achizitorii, buyerii vor put= ea: * sa inteleaga conceptele de baza care se aplica in negocierea in achizit= ii * sa afle cat de utile sunt unele tehnici existente pentru a putea fi apl= icate cu succes in companii * sa identifice posibilitati de eficientizare a metodelor de negociere. Achizitorii eficienti trebuie sa aiba capacitatea de a obtine acorduri du= rabile in relatiile companiei cu factori majori ai mediului economic, si sa= aiba sprijin deplin de la cei fata de care depind in ceea ce priveste resu= rsele, autoritatea si producerea efectiva de rezultate. **Cursul isi propune sa ofere buyerilor instrumente practice** care au rolu= l de a clarifica nuantele sensibile in obtinerea de rezultate in procesul d= e negociere. Cursul este unul interactiv astfel se creeaza cadrul analitic = cat si abilitatile si cunostintele necesare imbuntatirii performantei de lu= cru. In cadrul cursului vor exista exercitii si discutii de grup cu rolul de a e= videntia si de a ajuta participantii sa isi consolideze cadrul teoretic rel= evant pentru mediul lor de lucru. ** Obiectivele cursului:** * Prezentarea celor mai moderne metode si experiente legate de metode sof= isticate de obtinere a unor acorduri profitabile si solide; * Dezvoltarea capacitatilor de elaborare a strategiilor de negociere in a= chizitii si de implementare creative a acestora. ** ** ### Ce veti invata in cadrul cursului: * Tipuri de comunicare =E2=80=93 elemente de comportament si utilizarea l= or eficienta; * Asertivitatea =E2=80=93 metoda optima de colaborare si eficienta; * Dilema esentiala a negociatorului: stabilirea scopului; * Alternativele intr-un accord. Limitele negocierii; * Definirea intereselor ca masura a negocierii; * Crearea valorilor: cum se obtin cu adevarat valori comune; * Punerea in practica a principiilor negocierii in achizitii; * Negocierea in evolutie =E2=80=93 etape si metodologii; * Puterea de influenta in negociere si aplicarea ei in achizitii; * Negocierea pentru atingerea unui scop, autoritati sau resurse =E2=80=93= nevoia de mandate; * Ratificarea, evaluarea post-negociere, evolutie; * ****Exercitii practice, simulare, teste. **Mai multe informatii si intreaga prezentare a cursului la** \- ** ** **NU TE OPRI NICIODAT=C4=82 DIN =C3=8ENV=C4=82=C8=9AAT!** ** ****Accept=C4=83 acum provocarea.** **Noi experien=C8=9Be pentru ca tu s= =C4=83 c=C3=A2=C8=99tigi!** **** ****. **** | | **Calendar cursuri open 26 mai - 30 iunie 2017** =20 ---|--- =20 26-27 | Bucuresti | Tehnici de Negociere pentru achizitori si buyeri =20 29-30 | Bucuresti | Managementul Stocurilor si Depozitelor - simulare =20 29-30 | Bucuresti | Customer Care =20 | | =20 01-02 | Bucuresti | Finante pentru Non Finantisti =20 01-04 | Mamaia | Leadership for HighPerformance =20 | | =20 07-08 | Bucuresti | Managementul Stocurilor si Depozitelor - simulare =20 09-10 | Bucuresti | Tehnici de Influenta si Persuasiune cu integritate =20 09-10 | Bucuresti | Vanzarea Consultativa =20 09-11 | Bran | Marketing Strategic =20 09-11 | Bran | Time Management - Managementul Timpului si Stabilirea Priori= tatilor =20 | | =20 15-18 | Balcic (Bg) | Management Operational =20 16-17 | Bucuresti | KAM - Key Account Management =20 16-17 | Bucuresti | Supply Chain Management- Managementul Lantului de Aprov= izionare-Distributie =20 16-17 | Bucuresti | Tehnici in convingerea clientilor =20 16-18 | Mamaia | Comunicare asertiva =20 | | =20 21-22 | Bucuresti | Tehnici SPIN pentru finalizarea cu succes a vanzarilor =20 21-22 | Bucuresti | Tehici de luare a deciziilor si rezolvare a problemelor= . Creativitate si inovare in luarea deciziilor. =20 23-24 | Bucuresti | Cum sa descoperi diamante. Curs avansat de recrutare =20 23-24 | Bucuresti | Logistica - Managementul Logisticii =20 23-24 | Bucuresti | Management Strategic. Strategie si Planificare Manageri= ala =20 23-24 | Bucuresti | NLP si Instrumente de calibrare si influentare in comun= icarea cu clientii =20 23-25 | Mamaia | Abilitati de coaching pt manageri, sefi de compartimente i= n dezvoltarea angajatilor =20 23-25 | Poiana Bv | Roluri si abilitati manageriale - Dezvoltarea abilitat= ilor Manageriale - Eu ca Manager =20 | | =20 28-29 | Bucuresti | Abordarea telefonica a clientilor =20 28-29 | Bucuresti | Lean Management. Sisteme eficiente de decizie manageria= la =20 28-29 | Bucuresti | Managementul Motivatiei =20 28-29 | Bucuresti | Microsoft Excel - nivel Basic si Intermediar =20 28-29 | Bucuresti | Social media - "Cand imaginea conteaza" - curs aplicat = de folosire eficienta a instrumentelor online =20 30-01 | Bucuresti | Folosirea eficienta a Fiselor de Post - Implicarea prac= tica in strategia de Resurse Umane =20 30-01 | Bucuresti | Managementul securit=C4=83=C5=A3ii informa=C5=A3iilor c= lasificate =C5=9Fi neclasificate =20 30-01 | Bucuresti | NLP (Programare Neuro Lingvistica) in dezvoltarea manag= eriala =20 30-02 | Bran | Managementul Conflictului =20 30-02 | Bran | Management de Proiect . Managementul proiectelor =20 =20 =20 Click AICI ** **=C8=99i cite=C8=99te mai= mult. **Te va ajuta! ** **** =20 =20 =20 --- =20 =20 [![](http://nl.training-info.ro/uk1ay81Cum9BU4v_wQ8KJGhXYhxLU9-_rq1rPYmM7_D= IaTlZt8dZ0lHcoPD0Asz_XRSWx3VyWWkJ3UO6jpHX-eA5k2GDHt8-sbIWla1B_eXsdDkMdyHEvu= SN8BJxX2e0WCN5Fl9qUxYb8XnuI456PapI_vKMhx5jkaleRdQNpV5hD9AwJkLhlwu1oIhqp8afv= sa3XnXUdbS8Hkj23iwUG01C380D64ZzuqcoHZyNOfwOyAcR_5YvVd87oKk8iqRYiwPdGDo4xoyR= 8BoPG4Q3LlI6FldpBFexSHdJ9NU45w6Rb5DZeuaK_4fQcnueJQLqnlJAUgbgxoPMhdKxveMbuVs= lfbX536D2dMqQ-4PA0su5Ir16RCpgK-JJbMkLWSY3sQyXNDwLEpltppd3FHKgfNV1ZwOlVU0o9N= lwVNvMLk-Xrao1hhrPcxZTSpqGlWPURoV8nQ)]() [![]= (http://nl.training-info.ro/kj6co5LD3jma2rc-PEN1o_MNlII5_v--I3ga29_vlRHLEs9= MRKhF0gdHXsgfTgbUCpz62G6rn69jAXOWFh3J7LJk4FFyQWCfaIdEdnRc17p_0iJQJKoEM6k5jo= _SBQh5ukqQcf9D6qFu8csDSAObTJFn64z4HZP9b5RhHDnxDR2K4wvydv2SKsDF_UM2P-YYR8Quz= 1e68HMmzs0FRYDw5_MdqAmurRlDDLO_kJfDCsSD9qa0hBwKA_xaUQe9kkJ3tBdqqQNuGbgFGzQN= OSTMrHLQOiupDd8tjiaCOhahkG4dk-f_EM__y8iTSpdce6dIoD3Vaxcdfw0m74rJFdNjnjAdaZd= vg4lKBcgniS6qC2pChIMPwsXeZZTL5Eit1ie4JSkksN0ulhfkWXgklHnu89QWi0abbmCT7CCkVG= vxaSBD5WH5QDxO1sugkXVTKiVvw69TIg)]() ![](http://nl.training-info.ro/7= njvFQWfRfQ5EZ-0Qa1roleBMGkDOV82XY3Jp4GYdc4_kyhVLAj6iiVgxR2VC0bLJJH18aj5kuWZ= UbGw3gGrcl02lPKPqYpTXCQqGfZZ_aqs7f_egR6s69WtRUzZP1WbykMIpVHS-t_m-UZ4c8wSKgv= EY15qLE4--I0tuL8IWjR7CWPoa_3REmMwmzbqjukC1aqJG94nEgkwSY1UmjZK-O0c5ltRRWURgr= 6HjI25S9GYoKSEyqy5kxJCg-jCzKV0ay0XoESV7CZd2VRP_B542KS6FT90XQbo0PkmAKnV19Ats= kPIwiQBgRWiIs_7q-toh3C6O0VNTLnpi7tXg7qoo2XI5hvdQq1vZ6kPyHgI99WLsoqFH7RwgoUL= VbSpne3KMANgespxLnDV_PqEjJw8xYomViHllI2rMUAfYRWe8qZk3IHD3XF3FFCz-dW1qH3udH2= nCZc5) =20 =20 ******Programele de mai sus, pot fi accesate si prin Unitatea Protejata ce = suntem autorizati din 2007** * * * =20 =20 **"Educatia este cea mai puternica arma pe care voi o puteti folosi pentru = a schimba lumea." - Nelson Mandela** =20 | ![](http://nl.training-info.ro/72QIJaeho1A0VvSxeTvTi0SP6D42L01RH_MkA5olb= X9irK3l5xJgpdhBVRoYDK0fnVqOJkJrPWH85HGSc8azx4AFMNvwxDQvNiFv_MuxZgACrAw55oWP= _aj-5hKB49VTLbByyWfu78w5cNVuNpnM2zXWTxHM8ve8otZZdYaIU6ZSr0vqd2HwrrmLLKEhIRt= i0L5404FlKfIVH0c0G8WK7GeEGL2jHy2LyAF_-T6R7kBmlDnpf9oF71t7tRJXqumTT3i8ZBNR41= ydtKrknygP0EJyPXBDgXmhYS2ubqirRd1-39-HUvAkSg9L160fStHVgu0QEgBZxk2_wqcT1Rj2t= V7SzVIswycF9pI7lm_KIDCkEQpueTGirBPxthjChV1e7ZjowQdkf3gWzQiSemn0jnl2KdofZw43= pGCDZOJUNhwhjHD3xkYGEnChrP0qpilHIiJhKbcUcdjO1Xv8OEU3L5jAVd8Q3C9zQeZjje2AIpj= Uqmp6Yz99YSO_3G89GCZfWSaiiclEdWvwQO4y) | office @ http://nl.training-info.r= o/cZZVuT8gvWLB739mC5ZU2XmdMKNi1GCzs8uOLNRzYJXnAxSW9ZeCbIjwhZHXI2_wMTGiuiBuu= vXuGpD9DiAD4fAes-5g6gszswPgPJtT35crYefOuAvUgV8UeViSyPfmRk_fAomuJT8-tJwUEmqk= K7KzkW6HMQox1SoDZoD9k1ROJlkrH84ZEL3EtNKPYTdwHxF0L5bdrN3OcZ-ZUW8esvtfcc2uh9E= WiAaRG4KG_xPq0PLuT67x9mtj3JCA2tVbJZ9S91JgzXWBNqGxYH27kPuSFatTuE12LIf7bkpL5g= Wq8N3YEjIDRxiUSBWzOuX2j1k1rabzFWMqheihIF5eKXcg4ftWl5HUK5DkS3zBsS20mkfkkuIlE= 5U15_Lst52azqm40pZ9ooj2_mRGq9Z6-IREe8UbUWuNrupzMMTh-0R- =20 fax +40368 81 33 15 =20 Mobil +40 734 909 230 =20 ---|--- From owner-freebsd-net@freebsd.org Mon May 22 08:02:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34991D7821F for ; Mon, 22 May 2017 08:02:45 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (x0r.aitnet.org [IPv6:2a00:1728:9:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id F0B0F1119 for ; Mon, 22 May 2017 08:02:44 +0000 (UTC) (envelope-from misho@elwix.org) Received: from terran.aitnet.org (unknown [95.87.199.119]) by x0r.aitnet.org (Postfix) with ESMTPSA id 49CF43F75C for ; Mon, 22 May 2017 11:02:43 +0300 (EEST) Date: Mon, 22 May 2017 11:02:42 +0300 From: Michael Pounov To: freebsd-net@freebsd.org Subject: Re: How to bring up interface without address? Message-Id: <20170522110242.094706555a77a39e3835a530@elwix.org> In-Reply-To: <13310414754.20170522020524@serebryakov.spb.ru> References: <13310414754.20170522020524@serebryakov.spb.ru> Organization: ELWIX X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 May 2017 08:02:45 -0000 Hi Lev Try to put this into your rc.conf ifconfig_em1="up" On Mon, 22 May 2017 02:05:24 +0300 Lev Serebryakov wrote: > Hello Freebsd-net, > > I have "em1" interface which is container for several vlans, but it doesn't > need any special configuration and it doesn't need IPv4 or IPv6 address. > > If I write this in /etc/rc.conf: > > ifconifg_em1="" > vlans_em1="isp1 isp2" > create_args_isp1="vlan 10" > create_args_isp2="vlan 20" > > ifconfig_isp1="DHCP" > ifconfig_isp2="DHCP" > > > Startup script will not bring em1 UP automatically. So, I need some no-op > option for ifconifg_em1 variable. What should I use? > > -- > Best regards, > Lev mailto:lev@FreeBSD.org > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Michael Pounov From owner-freebsd-net@freebsd.org Mon May 22 12:04:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22135D775DA for ; Mon, 22 May 2017 12:04:00 +0000 (UTC) (envelope-from william@gathoye.be) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9FB012B8 for ; Mon, 22 May 2017 12:03:58 +0000 (UTC) (envelope-from william@gathoye.be) Received: by mail-wm0-x243.google.com with SMTP id k15so31588951wmh.3 for ; Mon, 22 May 2017 05:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gathoye-be.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:disposition-notification-to :date:user-agent:mime-version:in-reply-to; bh=+YK1uRnHhTXYfeisYL5xvmmPp1K2ZZzXUA4i3m13X2c=; b=YtDNfQYbZjJKe+c5R9EC6gJSc9HRf6Dey3DNOJdkW8UnZRt3K1C95fvY0GRWogi3uk Ydfvn0E2wTGqACpM76/VzLVcJTbJAUqJv77K5QMcspEO0wYqEwtyYxkH4erEqMmEgBHA PPeNtUJGAgVyYDT5Xom10FFuMFNoiGaTOGf24hWyrpjOIEeE/lRJeDo0r/7tuj6/fUc5 wB6aesTFevrGK8/04R7myJcE4kuzCR8KC6MeteFuXunm1RT6bUsIM7au9ZiE0bgJxpnU CmwGUw59lTskIMZuDBLDlkOIDeWrJLp5AJDuAiVhtDUsZcXCpqbd11+OwmK/HPRmIvP2 gSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to; bh=+YK1uRnHhTXYfeisYL5xvmmPp1K2ZZzXUA4i3m13X2c=; b=fnfOHfWEZy3K9tGtbe5YXhqxJcXg8xS5hNR5CuHa3iPlA6imKj4Af02/ur4EsupGlU wTU0p4Rm1GdBoY3AEx63MSXB8XmUgLYYrZyTdgnB84igDfJqyGamVxtmqfa8ILRrI2Q7 o3+eOcpMK571cNhywAUV3TeU5kQJxiZNfcdfQ5rd1twj9G3s/ZycgwcXPvMeiGFQNzDY teF5K5J2e1p9ekDn4mjI+eFnu//7assccR+3VZ9gpecT6X/1OvIyKCfDRkXXW2eXM1op wIjkk/94ldOiggq5w26dHMozvxsX5jdDfOIl0C4xpjE6BSM0n+58Qc3j3JpK1RSoXkCj V3RA== X-Gm-Message-State: AODbwcB6ahcmjwdTkmiGQDO2x1H5vxeiQEYyIGw2mzhRFmJiCao9QUrz i33syHpLr58yRz6PkTwc/A== X-Received: by 10.80.194.25 with SMTP id n25mr17074508edf.153.1495454636889; Mon, 22 May 2017 05:03:56 -0700 (PDT) Received: from ?IPv6:2a02:2788:134:20ee:d1be:7ddc:738f:4830? ([2a02:2788:134:20ee:d1be:7ddc:738f:4830]) by smtp.gmail.com with ESMTPSA id e11sm6859990edd.68.2017.05.22.05.03.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 05:03:55 -0700 (PDT) From: William Gathoye Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" To: "Andrey V. Elsukov" , alarig@swordarmor.fr, freebsd-net@freebsd.org References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> Message-ID: Date: Mon, 22 May 2017 14:03:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aNeSV6RoDbCJSO8k62lMeHSswDQ68FhI4" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 May 2017 12:04:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aNeSV6RoDbCJSO8k62lMeHSswDQ68FhI4 Content-Type: multipart/mixed; boundary="1WBkh4ai208Pd4ew5clI3w84R6eCTEusC"; protected-headers="v1" From: William Gathoye To: "Andrey V. Elsukov" , alarig@swordarmor.fr, freebsd-net@freebsd.org Message-ID: Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> In-Reply-To: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> --1WBkh4ai208Pd4ew5clI3w84R6eCTEusC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks all for your answers. Since I'm not subscribed to this list, please make sure I'm in your `To` field when replying. On 05/17/2017 09:45 AM, Andrey V. Elsukov wrote: >> Please note all my GWs are outside of my IP subnets. >=20 > FreeBSD's IPv6 NDP implementation can not find GWs layer 2 address, > since its IPv6 address is not considered as neighbor. You need to > configure IPv6 address on the vtnet0 interface from the same prefix as > GWs address. Or use link-local addresses. On 05/16/2017 21:36:54, Alarig Le Lay wrote: > Did you tried to use the fe80 of your router as gateway? After some discussion with guys from the company behind OPNsense, I have been able to solve my issue. My far gateway was in /56. Even if my IPv6 is not a /56, setting my IPv6 with a /56 prefix instead of the /64 fixed my issue. Thanks for the explanation with NDP, Andrey, this is what made us on the track. :) Btw, if I wanted to use link local addresses to communicate with the provider next hop gateway, how can I know the local link fe80 IPv6 address of that gateway since my provider (OVH) doesn't disclose it? Regards, And thanks again for your help. :) -- William Gathoye --1WBkh4ai208Pd4ew5clI3w84R6eCTEusC-- --aNeSV6RoDbCJSO8k62lMeHSswDQ68FhI4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE8ucX65+2FhkmJe7RDn3lLATXFoMFAlki06oACgkQDn3lLATX FoNVKQ/8Ck8NXvM6Bh570wxN+uxyP5WbJMTgFeKifIIHuZUIU5WkQvAxRpJ7x5wV yqBbnlwczFPx5sdnrcYjlgfjDl20cwPLHdHE4H9YBiLQvyodAoAFR0iFevT1hscJ ObRaZCZBduvm1I1LYbgmDMsmhjkK+KUi4ZHxGXzebNx7XrX0y/4jClWaWJzHIb/Z aI8ba5vXt0gHguJqiUQO/4VyihNEYueuxJhv55mml3Z7VrRYg/W8Cio4peMf4mqt rdVPsMQfp3c1m4M3TcyzBOiWwawNFESvHy36/hrnLxIsQkwOAaWRgkFsB1lWEDbB QChLFvLgtmWHvNLpe6Wzukl7PwKmSFmHP4DJB7iXsfTI5DyNaLOThq0PaqbqmVRp bDElfyQkPUKX9ZmZE0T01B4LBg026goQXqlZryXGUPCIk4vZmQ0jy+7ee0DsS/tM DtpupXNZK32LlDLzJrTCm601H9w+xuqyBJujGULqyRjJPkBiWcRIFDpXBmN/qBWE BUyBEIlG+sjeF66/JnXaioPNA0eu2QtbsZua5WoV2UmMbTARkwSpjHvN+MJxar1l 4TORkXrCISkJv5SHv2S6Rog9Lbs5F3Z8w6dTsBoAA7JnLEJUgcsLuGm7ntun0J8Z akSsT/GEGWVsnIFzj+mFeEHGI3Eux1JfGNuhUQEbB4bNfYEKpF4= =GLp5 -----END PGP SIGNATURE----- --aNeSV6RoDbCJSO8k62lMeHSswDQ68FhI4-- From owner-freebsd-net@freebsd.org Mon May 22 12:13:23 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7F09D77D96 for ; Mon, 22 May 2017 12:13:23 +0000 (UTC) (envelope-from alarig@swordarmor.fr) Received: from togepi.gozmail.bzh (togepi.gozmail.bzh [IPv6:2a00:5884:124::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C2051BD4 for ; Mon, 22 May 2017 12:13:23 +0000 (UTC) (envelope-from alarig@swordarmor.fr) Received: from mew.swordarmor.fr (mew.swordarmor.fr [IPv6:2a00:5884:102:1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alarig@swordarmor.fr) by togepi.gozmail.bzh (Postfix) with ESMTPSA id 7D4FE1A0083; Mon, 22 May 2017 14:13:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swordarmor.fr; s=default; t=1495455199; bh=d2FJ+Ut/DUulshDTWy5iVZ8nChZn7OLj7qiV4v/KQWI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PVtorA6Z8bzYP26O04XCmJFmn0wXZNxJeBgNZE23w5Urs9TiIzswiEvR8xWpt21Tr 7+9xXt/rjfribEYfaamizN4KicXp6jxGhpIG4gAUIK1qKcDgUM48Pw+XVBDEK2SVCA K/Kj3Cf80imVMJLbCLMaXZkEK9qnbCLrwq+pmL7Q= Date: Mon, 22 May 2017 14:13:18 +0200 From: Alarig Le Lay To: William Gathoye Cc: "Andrey V. Elsukov" , freebsd-net@freebsd.org Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" Message-ID: <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wystypbis4c62uhx" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170128 (1.7.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 22 May 2017 12:13:23 -0000 --wystypbis4c62uhx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On lun. 22 mai 14:03:54 2017, William Gathoye wrote: > Btw, if I wanted to use link local addresses to communicate with the > provider next hop gateway, how can I know the local link fe80 IPv6 > address of that gateway since my provider (OVH) doesn't disclose it? You can try to ping6 the IPv6 multicast address for all the routers on the link: 14:07 alarig@mew ~ % ping6 -c1 ff02::2%vtnet0 PING6(56=3D40+8+8 bytes) fe80::a800:ff:fe93:83a3%vtnet0 --> ff02::2%vtnet0 16 bytes from fe80::209%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D0.237 ms --- ff02::2%vtnet0 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 0.237/0.237/0.237/0.000 ms But, it=E2=80=99s possible that you don=E2=80=99t get any reply if they do = some nasty things on their network (as Hetzner does). In that case, you=E2=80=99re stu= ck on the /56 setup. --=20 alarig --wystypbis4c62uhx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+2yGwT0H0n57WkRbrzhKwWsgK4gFAlki1dsACgkQrzhKwWsg K4j5fwgAgMXzefkvOwdPJYejyjET3bR/VLEa2iX0PCn8f5iSAPr0xCoIwJNWlcXv fLKny43qsf42lVFu5H4FkSOYIWB5/03mu4xjmk6xDdpy+TLB2Q4Iae0ySt0ZlNmG COzh5o2RxuHf+QvAFHeCYWP4Ve1m/k35wzUuPbmzW3xktf13/py7/S1/x3wdT7Zq MekdkamHSoSk5QKtZGEBlh5bmA/ikhey8LkaPKjGv0IVyQH0obn8TGCLQCpt8HJE 1M6P+PasvBRndZXVJh/5Gb/6BQedtzItzLGThvkDtKQA55jdWLnJdJRLsFjzPHju 7kEmWEVYn0M/GGJYCksMqZgf5aXwGQ== =1hsK -----END PGP SIGNATURE----- --wystypbis4c62uhx-- From owner-freebsd-net@freebsd.org Mon May 22 12:41:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57146D787EF for ; Mon, 22 May 2017 12:41:33 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 345AC1E46 for ; Mon, 22 May 2017 12:41:33 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id A5F0B485D1; Mon, 22 May 2017 12:41:32 +0000 (UTC) Date: Mon, 22 May 2017 12:41:32 +0000 To: freebsd-net@freebsd.org From: "kczekirda (Kamil Czekirda)" Reply-to: D10603+325+510ac35a6a4d5b5d@reviews.freebsd.org Subject: [Differential] D10603: distinguish NFS versus TFTP boot by rootpath Message-ID: <72aafd2e95db60671a102a33d2cf3885@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D10603: distinguish NFS versus TFTP boot by rootpath X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NzNhM2RlMTc4NjEyZjQwMDg1YjdlMzhhODMyIFki3Hw= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:41:33 -0000 a2N6ZWtpcmRhIGFkZGVkIGEgY29tbWVudC4KCgogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y Zy9EMTA4NTQKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9E MTA2MDMKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL3Nl dHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzoga2N6ZWtpcmRhLCBvc2hvZ2JvLCB0 c29vbWUsIGJhcHQsIHNicnVubywgZnJlZWJzZC1uZXQtbGlzdCwgI25ldHdvcmsKQ2M6IGF2Zywg cmdyaW1lcwo= From owner-freebsd-net@freebsd.org Wed May 24 08:21:43 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB9C4D7B44E for ; Wed, 24 May 2017 08:21:43 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A6B91756 for ; Wed, 24 May 2017 08:21:43 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dDRXy-0003Gw-Sl for freebsd-net@freebsd.org; Wed, 24 May 2017 10:21:34 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dDRXx-0006D9-8o for freebsd-net@freebsd.org; Wed, 24 May 2017 10:21:33 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 7243B2A0929 for ; Wed, 24 May 2017 10:22:15 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0AdFRz44wEHZ for ; Wed, 24 May 2017 10:22:13 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ECF712A092A for ; Wed, 24 May 2017 10:22:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JQcm6U4WzUjK for ; Wed, 24 May 2017 10:22:12 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id CCB102A0929 for ; Wed, 24 May 2017 10:22:12 +0200 (CEST) To: freebsd-net@freebsd.org From: Sebastian Huber Subject: Basic support for IEEE 802.3ae clause 45 phys? Message-ID: <1b17f1a4-54ad-0d1d-32fc-09f781358a27@embedded-brains.de> Date: Wed, 24 May 2017 10:21:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23412/Wed May 24 02:55:55 2017) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 08:21:43 -0000 Hello, is there some basic support for IEEE 802.3ae clause 45 phys planned in=20 FreeBSD? It seems that every >1GBit network interface driver currently=20 deals with this individually. Linux has at least some infrastructure to=20 get the device identifiers: http://elixir.free-electrons.com/linux/latest/ident/get_phy_c45_ids --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-net@freebsd.org Wed May 24 10:09:25 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16214D7AE10 for ; Wed, 24 May 2017 10:09:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 063961486 for ; Wed, 24 May 2017 10:09:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4OA9N04049090 for ; Wed, 24 May 2017 10:09:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219472] Out of bounds access in vlan Date: Wed, 24 May 2017 10:09:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 10:09:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219472 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed May 24 10:18:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39AF0D7B347 for ; Wed, 24 May 2017 10:18:01 +0000 (UTC) (envelope-from william@gathoye.be) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFCEB1D07 for ; Wed, 24 May 2017 10:17:59 +0000 (UTC) (envelope-from william@gathoye.be) Received: by mail-wm0-x242.google.com with SMTP id b84so30346172wmh.0 for ; Wed, 24 May 2017 03:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gathoye-be.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to; bh=H0PpflmJAvL1J7xN0KN1SL01lAS9oTKcFJbYss8hxfk=; b=zZqQOIx1d4MIlzoY/sBs9xuVH+yo2PjmfSbvkBwvRjZdFvidDL1UxJiqWhg8GBQeAb CkspJUDB0ZDQI2Jd4rHfzQSegdSEJkK6kg0uEOjbo6JGbBocnq9xTYtlt6SC9pp+Q4fF aotDQ5g0wEc5mlPTCJBG6MWBsP1wopY95zM29cRSR/kA0NYuTn4Mo4cmxkjxIlDUQiUF mSExlF59rz5bIO7cSLjdbBZ1bBrGJFnPoWLU85cxf3+p3bBvgcV89FAbfAV6PuDUO2Iw aPDrAHduTr5wsHaWYRSxG5GFCFa+gjmJlwnOn38qf7cRgSCsW6qovxCB2e7t/mgiA3pg gXAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to; bh=H0PpflmJAvL1J7xN0KN1SL01lAS9oTKcFJbYss8hxfk=; b=MpsuGgQR/b/EPmNvn91ohVeRnqW9VbjMWjQTVSVUpbwUYeo1DExai8/en5+yWIsWvW D+I40LNZNQQJpciZHsTbvCMG68BjEvhjTJu9zVnxOy3d12F96f+io7IZrU/Z9eepZr4W JBsPy3gdlGIHuaWGkxnDgANVTOF4KDicp1aQK6Dj/iPyHfeisEb9a2Jw1SJyZV8+E76C xNNR2YPQWlNuZIsLVnSQmTz275twsRME5pZez2zvAxseIJ8x7UZkJSntJeeuKTRjpTko B3FU0ND3m7UOlRVJnMWMrxS1nmYFvb/IHUAsIVRtRy0h0QzL+BDTNB/WEotzXlcp7ckm 8sNA== X-Gm-Message-State: AODbwcDE5PGMT/sc3j4KO3k+GpT79upv7E+Qso0zBcyTmB4e+SXI7aGE V3a5wMQF6bIGdL5f X-Received: by 10.80.152.9 with SMTP id g9mr24671096edb.10.1495621077075; Wed, 24 May 2017 03:17:57 -0700 (PDT) Received: from [10.0.0.3] ([82.212.185.202]) by smtp.gmail.com with ESMTPSA id i42sm898538ede.5.2017.05.24.03.17.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 03:17:56 -0700 (PDT) Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" To: Alarig Le Lay Cc: "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> From: William Gathoye Message-ID: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> Date: Wed, 24 May 2017 12:17:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LVMlh6f1cfhtNVckMQwvbcVI98JRElvSF" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 10:18:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LVMlh6f1cfhtNVckMQwvbcVI98JRElvSF Content-Type: multipart/mixed; boundary="h5vTiTHo81SiUTNfuupwOJvv374IMVGEJ"; protected-headers="v1" From: William Gathoye To: Alarig Le Lay Cc: "Andrey V. Elsukov" , freebsd-net@freebsd.org Message-ID: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> In-Reply-To: <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> --h5vTiTHo81SiUTNfuupwOJvv374IMVGEJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/22/2017 02:13 PM, Alarig Le Lay wrote: > You can try to ping6 the IPv6 multicast address for all the routers on > the link: >=20 > 14:07 alarig@mew ~ % ping6 -c1 ff02::2%vtnet0 > PING6(56=3D40+8+8 bytes) fe80::a800:ff:fe93:83a3%vtnet0 --> ff02::2%vtn= et0 > 16 bytes from fe80::209%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D0.237 ms >=20 > --- ff02::2%vtnet0 ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev =3D 0.237/0.237/0.237/0.000 ms In this use case, you make the assumption that my gateway is actually the first one to respond, this is why you select only the first answer using -c1. But as you can see below, if I remove that argument, several routers are answering to me (seems sensible to me), how can I be sure my gateway is actually the first device that answers? PING6(56=3D40+8+8 bytes) fe80::ff:fec2:e61d%vtnet0 --> ff02::2%vtnet0 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D0.292 ms 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D0.355 ms(DUP!) 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D2.970 ms(DUP!) 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=3D0 hlim=3D64 time=3D5.964 ms(DUP!) 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=3D1 hlim=3D64 time=3D0.314 ms 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=3D1 hlim=3D64 time=3D0.389 ms(DUP!) 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=3D1 hlim=3D64 time=3D3.222 ms(DUP!) 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=3D1 hlim=3D64 time=3D6.382 ms(DUP!) How can I understand the "DUP!" statement here? I assume these are due because we are using multicast here end the ICMP reply are echoes to each others? Right? >=20 > But, it=E2=80=99s possible that you don=E2=80=99t get any reply if they= do some nasty > things on their network (as Hetzner does). In that case, you=E2=80=99re= stuck on > the /56 setup. >=20 As you can see, it seems there is no restriction / too nasty things at OVH, as I have got replies, at least :) Regards, -- William Gathoye --h5vTiTHo81SiUTNfuupwOJvv374IMVGEJ-- --LVMlh6f1cfhtNVckMQwvbcVI98JRElvSF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE8ucX65+2FhkmJe7RDn3lLATXFoMFAlklXc4ACgkQDn3lLATX FoMUqxAAl9zZM9ErmW2GICvgtJIQrUXTHTuD5LT9fl2Xbw6/Dp0URIYA5w6XBImk LB55e2s5xyTog4qglSq8NYcbx9iQQrNGwWT5qLbBCeZFdhC9vy5gAD6GKrh3kW8U e9qk4xwGBk8bWexTjvUvyfH58/MJrPWQfMUeyw9HBcCdRAh8ItQ3DTKL68tqAhU1 hUm4DHeBNqHDXmUI1+UpIviaKZ1h5ExfliT4GquQhJ0qmZ+FgHw4aZ/qOzbMkt1i GA/UqA01vW3nEXx4vGx5m7Ti7MHU54m9qjTZSV/Tly95ZrgT/sz9JwdjFfO62IOl 7PFFsKjRV0+h4+3BAcJQshAsAsW3oSueqBjgw7Gso5AYyOL+5DvmcHtiDSsZ8Hg6 Xs6nWNXL6pm790aMoKKXW3Ogkbg+SCA2WYZMgsit7gLvChLLDk+GvoJI8ttYmXrb ljNRrM0gNyn0rOfSOJV+0I0zXNRYdoUMg9dpny2jmD9NLaDUN16YaFwPY0Uqo32V Ybq1j+1a5/bRxcFe/Dz3xNxMBwqCOzvKBauQhKivP+8c+7QJ5u4g/C9g6CiUdmmE uZoqeRJKboFkk7x5TkHAO4EcM2p2aCAHr5xa5tspnms+7FeooPPE1EeZCELGQz3d z60eRGyEx0RtyYcQVUhN3LbTXjIOUSzsjdpa3WX1b/lN7Q/qojI= =H5ze -----END PGP SIGNATURE----- --LVMlh6f1cfhtNVckMQwvbcVI98JRElvSF-- From owner-freebsd-net@freebsd.org Wed May 24 10:30:22 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B0ADD7B9B6 for ; Wed, 24 May 2017 10:30:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AE5613C6 for ; Wed, 24 May 2017 10:30:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F35EB25D3892; Wed, 24 May 2017 10:30:12 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2087DD1F7EE; Wed, 24 May 2017 10:30:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dGaZHven2vmI; Wed, 24 May 2017 10:30:10 +0000 (UTC) Received: from [10.249.122.211] (unknown [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 615B9D1F7EA; Wed, 24 May 2017 10:30:10 +0000 (UTC) From: "Bjoern A. Zeeb" To: "William Gathoye" Cc: freebsd-net@freebsd.org Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" Date: Wed, 24 May 2017 10:30:07 +0000 Message-ID: In-Reply-To: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 10:30:22 -0000 On 24 May 2017, at 10:17, William Gathoye wrote: > In this use case, you make the assumption that my gateway is actually > the first one to respond, this is why you select only the first answer > using -c1. But as you can see below, if I remove that argument, > several > routers are answering to me (seems sensible to me), how can I be sure > my > gateway is actually the first device that answers? You cannot. It’s all about latency and where your time goes. Switch buffers, distance, NICs, input paths, CPU loads, .. lots of things can change the timing of a packet. > PING6(56=40+8+8 bytes) fe80::ff:fec2:e61d%vtnet0 --> ff02::2%vtnet0 > 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=0 hlim=64 > time=0.292 ms > 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=0 hlim=64 > time=0.355 ms(DUP!) > 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=0 hlim=64 > time=2.970 ms(DUP!) > 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=0 hlim=64 > time=5.964 ms(DUP!) > 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=1 hlim=64 > time=0.314 ms > 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=1 hlim=64 > time=0.389 ms(DUP!) > 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=1 hlim=64 > time=3.222 ms(DUP!) > 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=1 hlim=64 > time=6.382 ms(DUP!) > > How can I understand the "DUP!" statement here? I assume these are due > because we are using multicast here end the ICMP reply are echoes to > each others? Right? The DUP! here in case is indeed as you get 4 replies for each request you are sending out. It’s not “each other”, it’s one request to the multicast address, 4 unicast replies to you. /bz From owner-freebsd-net@freebsd.org Thu May 25 00:41:26 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A1DCD805A8 for ; Thu, 25 May 2017 00:41:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDDE11014 for ; Thu, 25 May 2017 00:41:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4P0fP5v050639 for ; Thu, 25 May 2017 00:41:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219428] em network driver broken in current Date: Thu, 25 May 2017 00:41:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 00:41:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219428 Kevin Bowling changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kbowling@freebsd.org --- Comment #1 from Kevin Bowling --- This report should be self contained, it is difficult to attempt to try and= dig up and align ML threads --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu May 25 02:54:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FA81D80DE8; Thu, 25 May 2017 02:54:00 +0000 (UTC) (envelope-from avv314@gmail.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E272D1840; Thu, 25 May 2017 02:53:59 +0000 (UTC) (envelope-from avv314@gmail.com) Received: by mail-yw0-x232.google.com with SMTP id b68so97884730ywe.3; Wed, 24 May 2017 19:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tMN81fIqPiwJjG3+/nnaJkb7qc/rOA6UoNkXKFArERs=; b=psw06tD0CJUXXVSpAWv6vn9x24nTnjnLLnO+/N9OAT5orC1UHrQOKxQvgCLdDqZE5v axEOGw/vOQaiouzjLLVsgNT7tIEfcKDsKvYrRGCK+xi5yJAS6af0TLhs4qUzhvFwXCWq CjECsCD83WfoLIXCW34YSlNZvjvDCFrJW1arqNH5JO6L2l/AtjC7Nw8MLrOQtUtn6Ws+ EVAr37/6/66+tMPfWMEWMHHWJEpry6mym4eFU1KECBoo90vXogIusEOWzp6lm3FTYcDB k46Eq37cqQvMXwCDFYgescnqgrYlALKnvrJwMtuyrzhdXG8uReQVwxs8x0yXil5sLtwg bb/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tMN81fIqPiwJjG3+/nnaJkb7qc/rOA6UoNkXKFArERs=; b=CzRnvJjlQQdQ/aWIQJOzvi4IdDRc49pN7rpQbsuUJXaIIegLbvuaxyL4iiDgfsoX3w BLzMggPSCS0mZi4f3wixZtfuKetXd/8lI4nCvOKhSjgM8ojA1Br6HUZwk/Tczg4w5fFB WU6b7Pab54FtF6kReemyhP6EONnctQGzkyHNjSpDao9lMOaJgoRyJQ6ojVG6DP98D0ry wPkasmfwtbswY8w7NWS8TGxwVXc7OKM70DtYSDDG4f7IFxLj9LkZu1jBaj1PH1bRbUWM 8L3I8t7yv2X3GxnY7l+/8r6v+b8xUOm8wsOti21iP/0grcN7Oj6/MjOUCDsH7qEvn7SZ ApYA== X-Gm-Message-State: AODbwcAw/mpSSL5iYmz0zLY/MCwTtz4ajuIE3dFRYKgG2ASGCZtbsZ0W Qe2kmoYv2KMx7hEdKRwmZ67hYmQQ/Q== X-Received: by 10.129.74.195 with SMTP id x186mr9034584ywa.88.1495680838754; Wed, 24 May 2017 19:53:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.133 with HTTP; Wed, 24 May 2017 19:53:58 -0700 (PDT) In-Reply-To: <201705180938.v4I9ckIb065376@pdx.rh.CN85.dnsmgr.net> References: <201705180938.v4I9ckIb065376@pdx.rh.CN85.dnsmgr.net> From: Andrew Vylegzhanin Date: Thu, 25 May 2017 05:53:58 +0300 Message-ID: Subject: Re: vmx bug? To: "Rodney W. Grimes" Cc: Ryan Stone , freebsd-net , freebsd-virtualization@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 02:54:00 -0000 2017-05-18 12:38 GMT+03:00 Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net>: > > This is a long standing issue with VMware ESXi, it effects > Linux as well as FreeBSD and Windows. A couple of googles > for things like > https://www.google.com/search?q=esxi+guest+ethernet++order&ie=utf-8&oe=utf-8 > > Well lead you to several articles talking about this issue. > I did not find any solutions however. > Did you try edit vmx hardware config? I googled solution for RHEL6: # cat /etc/udev/rules.d/69-vmxnet3-net.rules SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:0b:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:13:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", KERNELS=="0000:1b:00.0" DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" .... Do we have similar technique for mapping pci id to driver/name? -- Andrew > > -- > Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Thu May 25 14:47:55 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68C33D8166C for ; Thu, 25 May 2017 14:47:55 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 076251686 for ; Thu, 25 May 2017 14:47:54 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PElp7C051668; Thu, 25 May 2017 16:47:51 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 5D30C11E; Thu, 25 May 2017 16:47:51 +0200 (CEST) Message-ID: <5926EE96.1010000@omnilan.de> Date: Thu, 25 May 2017 16:47:50 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 16:47:51 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 14:47:55 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 15:01 (localtime): > 2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer : > >> Bezüglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 (localtime): … >> I'll try to provide more info about the panic this week. Like discussed >> offlist, the panic happend on a machine with the mentioned fix (latest >> stable). >> Perhaps this panic can be fixed, especialy for the vlan children. >> > > Ok, so if you create a vlan on an interface, and use netmap over the vlan, > you get a deterministic crash? Does the crash happen when you start > transmitting, receiving or both? > Sorry for the long delay. I now have a crash dump and could provide more info if someone can afford having a look at the lagg panic. The panic with em0.vlan vanisehd with latest -stable (11.1-prerelease), but using lagg reproducably panics. Unread portion of the kernel message buffer: 066.051358 [ 254] generic_find_num_desc called, in tx 1024 rx 1024 066.058166 [ 262] generic_find_num_queues called, in txq 0 rxq 0 066.064756 [1673] netmap_interp_ringid deprecated API, old ringid 0x0 -> ringid 0 reg 1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80426894 stack pointer = 0x28:0xfffffe03afccb750 frame pointer = 0x28:0xfffffe03afccb770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq269: igb0:que 1) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: #0 0xffffffff805d8277 at kdb_backtrace+0x67 #1 0xffffffff80596d06 at vpanic+0x186 #2 0xffffffff80596b73 at panic+0x43 #3 0xffffffff80898472 at trap_fatal+0x322 #4 0xffffffff808984c9 at trap_pfault+0x49 #5 0xffffffff80897d06 at trap+0x286 #6 0xffffffff8087dfa1 at calltrap+0x8 #7 0xffffffff8069dc50 at vlan_input+0x1f0 #8 0xffffffff8068eb08 at ether_demux+0x128 #9 0xffffffff8068f7ab at ether_nh_input+0x31b #10 0xffffffff806ab3f0 at netisr_dispatch_src+0xa0 #11 0xffffffff8068edb6 at ether_input+0x26 #12 0xffffffff8039f808 at igb_rxeof+0x738 #13 0xffffffff8039ebcf at igb_msix_que+0x10f #14 0xffffffff8055e66c at intr_event_execute_handlers+0xec #15 0xffffffff8055e956 at ithread_loop+0xd6 #16 0xffffffff8055bcc5 at fork_exit+0x85 #17 0xffffffff8087e4de at fork_trampoline+0xe Uptime: 1m37s Dumping 1535 out of 15529 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91% … Reading symbols from /usr/lib/debug/boot/kernel/uhid.ko.debug...done. Loaded symbols for /usr/lib/debug/boot/kernel/uhid.ko.debug #0 doadump (textdump=) at pcpu.h:222 222 pcpu.h: No such file or directory. in pcpu.h (kgdb) list *0xffffffff80426894 0xffffffff80426894 is in generic_rx_handler (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628). 623 struct netmap_adapter *na = NA(ifp); 624 struct netmap_generic_adapter *gna = (struct netmap_generic_adapter *)na; 625 u_int work_done; 626 u_int rr = MBUF_RXQ(m); // receive ring number 627 628 if (rr >= na->num_rx_rings) { 629 rr = rr % na->num_rx_rings; // XXX expensive... 630 } 631 632 /* limit the size of the queue */ Thanks, -harry From owner-freebsd-net@freebsd.org Thu May 25 15:25:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82707D8261B for ; Thu, 25 May 2017 15:25:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C6B61D2F for ; Thu, 25 May 2017 15:25:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PFOxvp051999; Thu, 25 May 2017 17:24:59 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id D2F1D12C; Thu, 25 May 2017 17:24:58 +0200 (CEST) Message-ID: <5926F74A.1000101@omnilan.de> Date: Thu, 25 May 2017 17:24:58 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: "freebsd-net@freebsd.org" Subject: vale uplink via vlan-if [Was: Re: Are ./valte-ctl and ./bridge friends or competitors?] References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <58CC26CF.5050708@omnilan.de> <58CFA606.7090306@omnilan.de> <58D02259.9010101@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 25 May 2017 17:24:59 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 15:25:01 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 21.03.2017 19:05 (localtime): > 2017-03-20 19:41 GMT+01:00 Harry Schmalzbauer : > >> Bezüglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50 (localtime): >> … >>>> So to summarize for newbies exploring netmap(4) world in combination >>>> with physical uplinks and virtual interfaces, it's important to do the >>>> following uplink NIC configuration (ifconfig(8)): >>>> -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc >>>> >>> >>> Exactly. This is mentioned at the very end of netmap(4): >>> >>> "netmap does not use features such as checksum offloading, TCP >> segmentation >>> offloading, encryption, VLAN encapsulation/decapsulation, etc. When >> using >>> netmap to exchange packets with the host stack, make sure to disable >> these >>> features." >>> >>> But it is probably a good idea to add these example ifconfig instructions >>> somewhere (man page or at least the README in the netmap repo). >>> >>> >>>> >>>> I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do they? >>>> >>> >>> Well, I think they interfere: if you receive a tagged packet and the NIC >>> strips the tag and puts it in the packet descriptor, then with netmap you >>> will see the untagged packet, and you wouldn't have a way to see the tag. Sorry picking this up again, but I'm stuck getting vale(4) productive :-( I took lagg(4) out of the game and configured my desired setup using if_bridge(4) at first. The physical uplink NIC is em0. The bridge/vale uplink is em0.232. hostB --switch-- em0-hostA | '- em0.232 | bridge5-vmnet0 | vtnet0-GUESTa <-tcpdump: 17:07:28.423768 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1, length 28 17:07:28.424208 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 46 The same is visable on vmnet0 nad em0 of course. Now if I replace bridge5 by vale, leaving everything else unchanged besides using netmap-vtnet with bhyve, I don't get ARP is-at answer. I can see the who-has on all interfaces involved, and also the is-at answer up to em0.232, but not at vtnet0 (the guest, connected via vale). To draw the same picture like with bridge: hostB --switch-- em0-hostA | '- em0.232 | vale232:em0.232-' vale232:GUESTa--vtnet0-GUESTa <-tcpdump: 17:16:00.111868 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1, length 28 ... no reply While tcpdump of em0.232 shows: 17:16:01.119537 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.21.34.10 tell 172.21.35.1, length 46 17:16:01.119849 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 46 The reply made it up to vale's uplink, but not through vale. Am I missing something? Tagging, checksum-disabling etc. seems to be right, since utilizing if_bridge(4) gives the expected result, but I have no idea why I can't get packets via vale(4). Important note: Using em0.232 parent (vlandev em0) for vale uplink does work! So I guess if_em(4)'s native netmap support interferes with the vlan clone. I'm out at this point, far too less knwoledge about the code paths... Can anybody else help here? Thanks, -harry From owner-freebsd-net@freebsd.org Thu May 25 15:32:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EC63D826FE for ; Thu, 25 May 2017 15:32:00 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 116681116 for ; Thu, 25 May 2017 15:32:00 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id h4so284243736oib.3 for ; Thu, 25 May 2017 08:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8PhoyeVFTrJfLisDmZnWpuYHiyLx0Yn0cbg0sti+5kY=; b=h+JzmRqpF3DXNRw75WeFXVFzx4HyKtCwZ1F3uduVTlsetw1qn74YC31LBsP61ofQiE vnbtToRTWziyVgolcXz3w+OWdHISAWf2tS68iFyXRLxXVJUGHZ2Y0aNTq3xuoA0uUoot e6OnfR7LmINRQmCWoI89uxm5r7B0hGl8Bbv3oCmPeWJ3zNmv5U1wC5xpNZw6h1voEK7q bpUxWXhTSSyQzQGAO8ss02qAEyd1UfxRw/n+WCHGyLMf0UsTYD25f3SVpjK7Wbntek8E wlgnYBHWsE3UyqxHFnz5e3ZJJbmOgHiRCjQmpY/Y75wwog6YoljpUl0nKzTEhPZht/rR CASA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8PhoyeVFTrJfLisDmZnWpuYHiyLx0Yn0cbg0sti+5kY=; b=VL9AHCaIRKHrlEtpfwUh1VuRAlSILiRZ6JFhnO/Owxxxe4rQ6W6D0UjPP5FeKVh7E4 8I17DEGBXSD0oaiiuyYYbufixdEG6OBBEUNpd8X5MXxvDrPyo+DBRsNug/6tjeXAh4om dLAZGv1TTbmXlJYCFo2znpEYScaMijzdrinD7kkhbg16tkdumHptqVjd2XX08ZMCKYbT MRsMXBSVgkUXnbhtZOzhQKChXQpUBP827DQar8JkBg/PygLRjs5KIDQDk2UsCBo9OhVq 9Q+sKgSoqOn8josHTuINM6alTc5RthwtrkC5Wt/1/gHBlVbzawbl8+TCIRDLxjvr1INj HymA== X-Gm-Message-State: AODbwcAiQGPwVG4a0VdTinYLItIEmWeUkjLi3Px+p4bTpcBfh3TpTwtL oEG6SGHMyJhq76kwVAsUG6IklF9gyKzh X-Received: by 10.202.108.132 with SMTP id h126mr19439113oic.181.1495726319247; Thu, 25 May 2017 08:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Thu, 25 May 2017 08:31:58 -0700 (PDT) In-Reply-To: <5926EE96.1010000@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> From: Vincenzo Maffione Date: Thu, 25 May 2017 17:31:58 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 15:32:00 -0000 Hi, This is a (silly) bug that is not present anymore in the upstream code https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_free= bsd.c#L410-L417 that is txq and rxq for generic adapter cannot be 0. So I would say the problem is outdated code in the FreeBSD version you are using. Which version you are using exactly? Maybe we can try to push a fix. Cheers, Vincenzo 2017-05-25 16:47 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 20.03.2017 15:01 (localt= ime): > > 2017-03-20 10:40 GMT+01:00 Harry Schmalzbauer : > > > >> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 17.03.2017 22:28 > (localtime): > > =E2=80=A6 > >> I'll try to provide more info about the panic this week. Like discuss= ed > >> offlist, the panic happend on a machine with the mentioned fix (latest > >> stable). > >> Perhaps this panic can be fixed, especialy for the vlan children. > >> > > > > Ok, so if you create a vlan on an interface, and use netmap over the > vlan, > > you get a deterministic crash? Does the crash happen when you start > > transmitting, receiving or both? > > > > Sorry for the long delay. > > I now have a crash dump and could provide more info if someone can > afford having a look at the lagg panic. > The panic with em0.vlan vanisehd with latest -stable (11.1-prerelease), > but using lagg reproducably panics. > > Unread portion of the kernel message buffer: > 066.051358 [ 254] generic_find_num_desc called, in tx 1024 rx 1024 > 066.058166 [ 262] generic_find_num_queues called, in txq 0 rxq 0 > 066.064756 [1673] netmap_interp_ringid deprecated API, old ringid > 0x0 -> ringid 0 reg 1 > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address =3D 0xc > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80426894 > stack pointer =3D 0x28:0xfffffe03afccb750 > frame pointer =3D 0x28:0xfffffe03afccb770 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12 (irq269: igb0:que 1) > trap number =3D 12 > panic: page fault > cpuid =3D 1 > KDB: stack backtrace: > #0 0xffffffff805d8277 at kdb_backtrace+0x67 > #1 0xffffffff80596d06 at vpanic+0x186 > #2 0xffffffff80596b73 at panic+0x43 > #3 0xffffffff80898472 at trap_fatal+0x322 > #4 0xffffffff808984c9 at trap_pfault+0x49 > #5 0xffffffff80897d06 at trap+0x286 > #6 0xffffffff8087dfa1 at calltrap+0x8 > #7 0xffffffff8069dc50 at vlan_input+0x1f0 > #8 0xffffffff8068eb08 at ether_demux+0x128 > #9 0xffffffff8068f7ab at ether_nh_input+0x31b > #10 0xffffffff806ab3f0 at netisr_dispatch_src+0xa0 > #11 0xffffffff8068edb6 at ether_input+0x26 > #12 0xffffffff8039f808 at igb_rxeof+0x738 > #13 0xffffffff8039ebcf at igb_msix_que+0x10f > #14 0xffffffff8055e66c at intr_event_execute_handlers+0xec > #15 0xffffffff8055e956 at ithread_loop+0xd6 > #16 0xffffffff8055bcc5 at fork_exit+0x85 > #17 0xffffffff8087e4de at fork_trampoline+0xe > Uptime: 1m37s > Dumping 1535 out of 15529 > MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91% > =E2=80=A6 > Reading symbols from /usr/lib/debug/boot/kernel/uhid.ko.debug...done. > Loaded symbols for /usr/lib/debug/boot/kernel/uhid.ko.debug > #0 doadump (textdump=3D) at pcpu.h:222 > 222 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) list *0xffffffff80426894 > 0xffffffff80426894 is in generic_rx_handler > (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/ > netmap/netmap_generic.c:628). > 623 struct netmap_adapter *na =3D NA(ifp); > 624 struct netmap_generic_adapter *gna =3D (struct > netmap_generic_adapter *)na; > 625 u_int work_done; > 626 u_int rr =3D MBUF_RXQ(m); // receive ring number > 627 > 628 if (rr >=3D na->num_rx_rings) { > 629 rr =3D rr % na->num_rx_rings; // XXX expensive... > 630 } > 631 > 632 /* limit the size of the queue */ > > Thanks, > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Thu May 25 15:36:28 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72F6ED828C4 for ; Thu, 25 May 2017 15:36:28 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 129301356 for ; Thu, 25 May 2017 15:36:27 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PFaQjW052094; Thu, 25 May 2017 17:36:26 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 104A0134; Thu, 25 May 2017 17:36:25 +0200 (CEST) Message-ID: <5926F9F9.4040706@omnilan.de> Date: Thu, 25 May 2017 17:36:25 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 17:36:26 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 15:36:28 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:31 (localtime): > Hi, > This is a (silly) bug that is not present anymore in the upstream code > https://github.com/luigirizzo/netmap/blob/master/sys/dev/netmap/netmap_freebsd.c#L410-L417 > that is txq and rxq for generic adapter cannot be 0. > > So I would say the problem is outdated code in the FreeBSD version you are > using. Which version you are using exactly? Maybe we can try to push a fix. Thanks for the quick reply! This panic was with r318629 (stable/11 = FreeBSD 11.1-PRERELEASE) You mentioned "generic adapter": Does this mean native-netmap support get's lost when if_lagg(4) is in game after if_igb(4)? Thanks, -harry From owner-freebsd-net@freebsd.org Thu May 25 15:56:09 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69B2CD82E61 for ; Thu, 25 May 2017 15:56:09 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 288881F80 for ; Thu, 25 May 2017 15:56:09 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id l18so285170232oig.2 for ; Thu, 25 May 2017 08:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7WFNBRDwnKDt+gUoSScvWe6DkINoUMbSo54dfok2Q50=; b=kHz4BBWQ/hZ1d/mAYbmmVqlx7r/PBVHTY0ZL07MnosvUuebPSD7lRQr/P655OFwgrj LlJdmP9/3mMWET8bhurGarBJY5hjdiO8DMQ4Bj1mkZI6C9iGQmYaGS3+HhB5WmLEyAe3 frLN6vVCLZmYTUVSwhT4W3/0xQiE/GN1PJ+MrUE0Hj9lrepOKMze1M/bEF7jRhJqkRXu FaBk+/qcPtm+/2athMuGdYmMOJnO+flM5w9hb0oO4Te+2z9IAJgQztmkVvrRlTWx6M5T tx3ftM5rsWvUEIYcmgEgrNEXE7L3fnQeJGmwRfKVA9ygByChjdVXYDeICJTpys0lZSCu gQ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7WFNBRDwnKDt+gUoSScvWe6DkINoUMbSo54dfok2Q50=; b=SLKcDpQqso0wtL44M0a23t88CbzqyCgvbFHkM0fLcRGV2YfSsOpuoH/gnhBfmZ0BIr BqXKd+hildEboURdWorNOQy5QtZyVxM1EmKvBKr2osXe+ysUW5NQGr+JV+aRAKTtmgow NuNYXUqe5AWEPYrRIMA5LQfKwdXK5Q2MxelknJOA+uBZJXDUHambKyN4L+yrXQQK/pN8 S2trasFubSFdRaSflA7+GIlOUMbpTf1hU1ay1sGqqR9qlDmNaUzfRQrECvw9rxmYeGm6 CbnfeFO3H/iRCnAHtqLQ1zABqjxdrn7cg6svr8ZHBBtFyp2iS4ag570Vrc+QamWdIw5T vr1g== X-Gm-Message-State: AODbwcCjMKSL0yuIG0tfLMZ3wj7aV7AKaIQyMLh/kaVTmPX0E1fW8T2Z vSUhm7/2cLqt+DVoU7Fy8GhwpjbEaQ== X-Received: by 10.202.205.196 with SMTP id d187mr20537280oig.6.1495727768324; Thu, 25 May 2017 08:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Thu, 25 May 2017 08:56:07 -0700 (PDT) In-Reply-To: <5926F9F9.4040706@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> From: Vincenzo Maffione Date: Thu, 25 May 2017 17:56:07 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: freebsd-net Content-Type: multipart/mixed; boundary="001a1134f8464ff56705505b427e" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 15:56:09 -0000 --001a1134f8464ff56705505b427e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see the bug is in FreeBSD 11. I attached the simple patch to fix it. Can someone commit the patch to 11/stable? Harry: You should be able to workaround the bug by setting # sysctl dev.netmap.generic_rings=3D1 And yes, if_lagg(4) doesn't have native netmap support, like all the meta-drivers (e.g. vlan, tunnels, etc.). Point is that you should implement link aggregation in your application (in user-space). Cheers, Vincenzo 2017-05-25 17:36 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:31 (localt= ime): > > Hi, > > This is a (silly) bug that is not present anymore in the upstream cod= e > > https://github.com/luigirizzo/netmap/blob/master/sys/dev/ > netmap/netmap_freebsd.c#L410-L417 > > that is txq and rxq for generic adapter cannot be 0. > > > > So I would say the problem is outdated code in the FreeBSD version you > are > > using. Which version you are using exactly? Maybe we can try to push a > fix. > > Thanks for the quick reply! > This panic was with r318629 (stable/11 =3D FreeBSD 11.1-PRERELEASE) > > You mentioned "generic adapter": Does this mean native-netmap support > get's lost when if_lagg(4) is in game after if_igb(4)? > > Thanks, > > -harry > > > --=20 Vincenzo Maffione --001a1134f8464ff56705505b427e Content-Type: text/x-patch; charset="US-ASCII"; name="11-stable-fix-netmap-generic-bug.patch" Content-Disposition: attachment; filename="11-stable-fix-netmap-generic-bug.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j34ligm90 LS0tIGYxLmMJMjAxNy0wNS0yNSAxNzo0NjozNi45NDg4NzEzMDUgKzAyMDAKKysrIGYuYwkyMDE3 LTA1LTI1IDE3OjQ2OjAxLjU0MjIwMzA1NCArMDIwMApAQCAtMjczLDkgKzI3MywxMCBAQCBnZW5l cmljX2ZpbmRfbnVtX2Rlc2Moc3RydWN0IGlmbmV0ICppZnAsCiB2b2lkCiBnZW5lcmljX2ZpbmRf bnVtX3F1ZXVlcyhzdHJ1Y3QgaWZuZXQgKmlmcCwgdV9pbnQgKnR4cSwgdV9pbnQgKnJ4cSkKIHsK LQlEKCJjYWxsZWQsIGluIHR4cSAlZCByeHEgJWQiLCAqdHhxLCAqcnhxKTsKLQkqdHhxID0gbmV0 bWFwX2dlbmVyaWNfcmluZ3M7Ci0JKnJ4cSA9IG5ldG1hcF9nZW5lcmljX3JpbmdzOworCXVfaW50 IG51bV9yaW5ncyA9IG5ldG1hcF9nZW5lcmljX3JpbmdzID8gbmV0bWFwX2dlbmVyaWNfcmluZ3Mg OiAxOworCisJKnR4cSA9IG51bV9yaW5nczsKKwkqcnhxID0gbnVtX3JpbmdzOwogfQogCiAK --001a1134f8464ff56705505b427e-- From owner-freebsd-net@freebsd.org Thu May 25 16:01:34 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70EB4D81148 for ; Thu, 25 May 2017 16:01:34 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16B4B15A0 for ; Thu, 25 May 2017 16:01:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PG1WWM052377; Thu, 25 May 2017 18:01:32 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 192D416B; Thu, 25 May 2017 18:01:32 +0200 (CEST) Message-ID: <5926FFDB.7040900@omnilan.de> Date: Thu, 25 May 2017 18:01:31 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-net CC: gaetano.catalli@gmail.com Subject: ovs-netmap forgotten? Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 18:01:32 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:01:34 -0000 Hello, I found lots of interesting papers about research and improvements regarding Open vSwitch and netmap (on FreeBSD, e.g. http://changeofelia.info.ucl.ac.be/pmwiki/uploads/SummerSchool/Program/poster_001.pdf) Again, University of Pisa with a famous team arround Luigi Rizzo did some highly appreciated coding and presentation, the paper in the link is from Gaetano Catalli (cc'd). But it seems that this work got lost in space... openvswitch in ports is quiet old codebase without any netmap-integration and a provided patch isn't in our netmap tree: https://github.com/cnplab/ovs-netmap/blob/master/0001-datapath-Add-support-for-netmap-VALE.patch So I guess nobody uses ports/net/openvswitch these days anymore. I also found a FreeBSD kernel module was written back in 2014. But that seems also got lost, which most likely was due to ovs-netmap replacement? Thanks for any hints, -harry From owner-freebsd-net@freebsd.org Thu May 25 16:10:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 401B7D81589 for ; Thu, 25 May 2017 16:10:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7C251DAF for ; Thu, 25 May 2017 16:10:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PG9wtw052414; Thu, 25 May 2017 18:09:58 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id AC6B516E; Thu, 25 May 2017 18:09:58 +0200 (CEST) Message-ID: <592701D6.7030301@omnilan.de> Date: Thu, 25 May 2017 18:09:58 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 18:09:59 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:10:01 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): > I see the bug is in FreeBSD 11. I attached the simple patch to fix it. > Can someone commit the patch to 11/stable? > > Harry: You should be able to workaround the bug by setting > > # sysctl dev.netmap.generic_rings=1 I'll recompile with your patch, thanks a lot! > And yes, if_lagg(4) doesn't have native netmap support, like all the > meta-drivers (e.g. vlan, tunnels, etc.). > Point is that you should implement link aggregation in your application (in > user-space). Thanks for confirmation. My problem is that I can't pass frames to guests without vlan filtering first :-( Focus is not on inter-VM-connection, but most efficient port usage _and_ vm-interconnection. The more I learn the less I know what to do ;-) If I only had VF-capable hardware (actually VF-"supported" hardware, 82576 was SR-IOV enabled, but at the advent of 10GbE, SR-IOV support for older chips was removed - where initially implemented - and of course not implemented anywhere else). -harry From owner-freebsd-net@freebsd.org Thu May 25 16:21:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AD6FD81AD9 for ; Thu, 25 May 2017 16:21:16 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D028E15C7 for ; Thu, 25 May 2017 16:21:15 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id h4so286093086oib.3 for ; Thu, 25 May 2017 09:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MCz24ddvCTw/nUwPaLV9gCtKbHKOQ768xs6yd/2CNqI=; b=EcjENoDEKBwtVEoEFHk3dkq7Ut34r1jrcygaxcUBNUODuj1pN6F+b0YuznPm83c5qX nee/Dzl0aeapY1d78aHqXp/9KUgbPU/Ix6ivjlqvWvmy5WKoGzIN772y7Z3ZjKLbISv4 k2GCuKDSZ+LUnT9j9wh3teNMIUG4jATtUH1zNNqdjpVGaY5+6aixi8YXK43HJjduWgr+ 9I1iIs08GEAgPFW+59lw28MMJqIY2xU682FbogqT2lT76ejGgqs23OeKnwobtPv+NBRW PY8IUw32YblhT13x4HGzXkdSA/G+2Uu4YiDOYAcqwgqgzKUUyH9QKfMtV/DlJyY72Buw 8W0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MCz24ddvCTw/nUwPaLV9gCtKbHKOQ768xs6yd/2CNqI=; b=kvLCnB7ldTcLZWQVyZz/TURM/HdBGO+02AhBEC4VD7t3yOxc532lNileyTg5wkE5wU s9TmXaIpTbM/+bBYKijaum5EU1LcgqMeGSWsIDhK9C5//YV6m/JHLYWCldfTleBGBMBW GQdbdBqY6ngHVjuYUMVVisKKp+EfUdiUdeVkUAfq+KTDwB65gg4oLdPyT+53rntfyS36 FNlUmxn1LvHDqmO3IpHCX041R8lyXj2quLHLeYNVDSRHfvAeJZbfqCFFC+FFabdtPhxA 2WbcV8nkdWb3Tyq9itlMfLCnRTqLIfVs0KJoIx83S+LMmJtM+xXWmgSLyBd4bnUKK8SU xWrA== X-Gm-Message-State: AODbwcCX6ZBCrWz6Nmh15rVaLKV7mxAD+PP6+2YiaL3XIBCqJcmEg/Ei urr/T7WMcI8li2W1ua9YVhm2+eeB8QTg X-Received: by 10.157.56.88 with SMTP id r24mr8334710otd.57.1495729274928; Thu, 25 May 2017 09:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Thu, 25 May 2017 09:21:14 -0700 (PDT) In-Reply-To: <592701D6.7030301@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> From: Vincenzo Maffione Date: Thu, 25 May 2017 18:21:14 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:21:16 -0000 2017-05-25 18:09 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localt= ime): > > I see the bug is in FreeBSD 11. I attached the simple patch to fix it. > > Can someone commit the patch to 11/stable? > > > > Harry: You should be able to workaround the bug by setting > > > > # sysctl dev.netmap.generic_rings=3D1 > > I'll recompile with your patch, thanks a lot! > > > And yes, if_lagg(4) doesn't have native netmap support, like all the > > meta-drivers (e.g. vlan, tunnels, etc.). > > Point is that you should implement link aggregation in your application > (in > > user-space). > > Thanks for confirmation. > My problem is that I can't pass frames to guests without vlan filtering > first :-( > Then you need an ad-hoc userspace netmap application that does this job, reading the tagged frames from the NIC, strip the tag and dispatch to the proper VM. > > Focus is not on inter-VM-connection, but most efficient port usage _and_ > vm-interconnection. The more I learn the less I know what to do ;-) > If I only had VF-capable hardware (actually VF-"supported" hardware, > 82576 was SR-IOV enabled, but at the advent of 10GbE, SR-IOV support for > older chips was removed - where initially implemented - and of course > not implemented anywhere else). > > -harry > > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Thu May 25 17:10:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 814E7D82C29 for ; Thu, 25 May 2017 17:10:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5C15C1B71 for ; Thu, 25 May 2017 17:10:12 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v4PHA4eU017413 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 25 May 2017 10:10:05 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me To: "freebsd-net@freebsd.org" From: Yuri Subject: dhclient vs. dhcpcd Message-ID: <97050ce3-ad75-c3dc-c106-3bd608e7aa8e@rawbw.com> Date: Thu, 25 May 2017 10:10:03 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:10:12 -0000 I came across the WiFi router through which dhclient fails to obtain the IP address. It sets 0.0.0.0 and it stays this way, On the other hand, dhcpcd obtains the IP address almost instantly. Other routers mostly don't have such problem. Is dhclient not as robust, or outdated as compared to dhcpcd? Yuri From owner-freebsd-net@freebsd.org Thu May 25 17:58:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02B9AD820D9 for ; Thu, 25 May 2017 17:58:56 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97A231FEB for ; Thu, 25 May 2017 17:58:55 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PHwrOa053463; Thu, 25 May 2017 19:58:53 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 664FA1AE; Thu, 25 May 2017 19:58:53 +0200 (CEST) Message-ID: <59271B5C.7020306@omnilan.de> Date: Thu, 25 May 2017 19:58:52 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Andrey V. Elsukov" CC: "freebsd-net@freebsd.org" Subject: Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6 References: <58CAD8CB.3060101@omnilan.de> <283742a4-5314-eef3-ed53-958a1f6e7492@yandex.ru> <58E641B8.5050108@omnilan.de> In-Reply-To: <58E641B8.5050108@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 25 May 2017 19:58:53 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:58:56 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 06.04.2017 15:25 (localtime): > Bezüglich Andrey V. Elsukov's Nachricht vom 06.04.2017 14:56 (localtime): >> On 16.03.2017 21:26, Harry Schmalzbauer wrote: >>> Hello, >>> >>> I'm wondering if I really loose [RT]XCSUM_IPV6 on if_igb(4) vlan(4) >>> children. >>> My igb0 (Kawela, aka 82576) options end with >>> "TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6" >>> >>> The vlan(4) filtered interfaces show these: >>> options=303 >>> >>> So TSO6 is inherited, but RC/TXCSUM_IPV6 dropped? >> Can you test the attached patch? > Great, thanks for your explanation and the patch. Unfortunately I won't > be able to test before weekend. Will report asap. Hello, thank you for your fix, which made it into stable/11 in the meantime, where I can confirm it does work. But I noticed a possibly related oddity: Setting "-vlanhwcsum" seems to have no effect, at least ifconfig(8) reports always 'VLAN_HWCSUM'. Haven't done any further tests, maybe your eye-brain-connection find the answer quicker than any test I can do. thanks, -harry From owner-freebsd-net@freebsd.org Thu May 25 18:09:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22812D82333 for ; Thu, 25 May 2017 18:09:01 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E36A1503 for ; Thu, 25 May 2017 18:09:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PI8wJH053553; Thu, 25 May 2017 20:08:58 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 9A31F1B2; Thu, 25 May 2017 20:08:58 +0200 (CEST) Message-ID: <59271DBA.30907@omnilan.de> Date: Thu, 25 May 2017 20:08:58 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Andrey V. Elsukov" CC: "freebsd-net@freebsd.org" Subject: Re: Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6 References: <58CAD8CB.3060101@omnilan.de> <283742a4-5314-eef3-ed53-958a1f6e7492@yandex.ru> <58E641B8.5050108@omnilan.de> <59271B5C.7020306@omnilan.de> In-Reply-To: <59271B5C.7020306@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 20:08:58 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:09:01 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 19:58 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 06.04.2017 15:25 (localtime): >> Bezüglich Andrey V. Elsukov's Nachricht vom 06.04.2017 14:56 (localtime): >>> On 16.03.2017 21:26, Harry Schmalzbauer wrote: >>>> Hello, >>>> >>>> I'm wondering if I really loose [RT]XCSUM_IPV6 on if_igb(4) vlan(4) >>>> children. >>>> My igb0 (Kawela, aka 82576) options end with >>>> "TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6" >>>> >>>> The vlan(4) filtered interfaces show these: >>>> options=303 >>>> >>>> So TSO6 is inherited, but RC/TXCSUM_IPV6 dropped? >>> Can you test the attached patch? >> Great, thanks for your explanation and the patch. Unfortunately I won't >> be able to test before weekend. Will report asap. > Hello, > > thank you for your fix, which made it into stable/11 in the meantime, > where I can confirm it does work. > > But I noticed a possibly related oddity: > Setting "-vlanhwcsum" seems to have no effect, at least ifconfig(8) > reports always 'VLAN_HWCSUM'. And to complete today's discoverings of personal knwoledge deficiencies: ifconfig(8) reports "PPROMISC" doubled. Don't know if that's a special meaning or a cosmetic bug. Thanks, -harry From owner-freebsd-net@freebsd.org Thu May 25 19:15:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19844D82DC5 for ; Thu, 25 May 2017 19:15:14 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from mail.netcult.ch (mail.netcult.ch [46.140.84.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9E4716FA for ; Thu, 25 May 2017 19:15:12 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from thunb001 ([192.168.1.200]) (authenticated bits=0) by mail.netcult.ch (8.14.7/8.14.7) with ESMTP id v4PIbLDb027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 May 2017 20:37:22 +0200 From: "Tom Huerlimann" To: References: In-Reply-To: Subject: AW: axge0 and AX88179 Date: Thu, 25 May 2017 20:37:20 +0200 Message-ID: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> X-Mailer: Microsoft Outlook 15.0 MIME-Version: 1.0 Thread-Index: AQNcD8HU/AXwcV/27iM266D9N4ZFdJ7y5lOg Content-Language: de-ch Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0082_01D2D596.B4B61C10" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:15:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01D2D596.B4B61C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I have the problem, that I cannot reach more than 20-40Mbit/s when using the AX88179 chip (1Gbit/s NIC) on a USB 3.0 SuperSpeed Port (same on a 480Mbps High Speed USB v2.0-Port). # usbconfig dump_device_desc (...) ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x00ff bDeviceSubClass = 0x00ff bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x0b95 idProduct = 0x1790 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <00000000000001> bNumConfigurations = 0x0001 plugged into this USB controller: # dmesg | grep -i usb xhci0: mem 0xd0800000-0xd080ffff irq 20 at device 20.0 on pci0 usbus0 on xhci0 ehci0: mem 0xd0815000-0xd08153ff irq 23 at device 29.0 on pci0 usbus1: waiting for BIOS to give up control usbus1: timed out waiting for BIOS usbus1: EHCI version 1.0 usbus1 on ehci0 usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: <0x8086> at usbus0 uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen0.2: at usbus0 umass0: on usbus0 ugen0.3: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 ugen0.4: at usbus0 ukbd0: on usbus0 uhid0: on usbus0 ugen0.5: at usbus0 uhub4: on usbus0 ugen0.6: at usbus0 ukbd1: on usbus0 uhid1: on usbus0 ugen0.7: at usbus0 axge0: on usbus0 ue0: on axge0 # dmesg | grep -i axge axge0: on usbus0 miibus2: on axge0 ue0: on axge0 axge0: at uhub1, port 7, addr 6 (disconnected) axge0: on usbus0 miibus2: on axge0 ue0: on axge0 axge0: on usbus0 miibus2: on axge0 ue0: on axge0 I'm using FreeBSD 10.3-RELEASE-p19. Did someone of you ever managed to reach a higher bandwidth with axge driver and AX88179 chipset? Best regards -Tom ------=_NextPart_000_0082_01D2D596.B4B61C10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUizCCBeIw ggPKoAMCAQICEDZ5UlTLE1WeMCbSKy5LEOswDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAzIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANYjcOFzVjMVemifqK8VYRDvjxUxEc5soFBfad3Y1e7bZufzKb1/yTalMXW6iepa hiRBta9+i9nf09Rt0CEjNRlkUVTVjdQxUjNWGcvA/7bGqLFOB5Dtc6c66odhMfifEvrFRc6oXDE6 8Civo19smaFJoe7Pzk0DXy5l+f8+8LeSkK2sCeYTSKUecM1kt6v955hgWQWKehqW4XSs5iOJOqWz prW4TxnQLQTemoQEUMaIO2UBfoeXTCeclC9DgDvSl6TA0DqJiLBWA6BFBM4KCmlOOs1Wf3T3Qy3S 3tAuw2glk0VxDqbKC/3ZPMTrU9msz4Uhutgn1HNaOGPcD93A+K8CAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU NFpzxB+rcWNns0/Amy0gp53myR8wHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAtGvTe3y0uo6+hngSROfH4CzL3GmXfQDtt1evpt/fs7Fs VgCT1hOzuNWBQn9KXCQlzfkxm5MBCqGUWz33c+jdiTinIzn4BwyaEds/bGWABSCg3au7Qr5NAG6l 65RD+xRa+JyrCScvt1lCIlAmD0oI5CVCe0Yk0teWa2ZSRZGf+1S2eymzGKh6TaU0q2oYFPjwf7TZ sDcD0Rzklrd3HsjGZy1WUB3zw5eTg5HnNBQ107I7e98xnjhszIUp4ymYRoCr48SnqOibCbUpaVdt TlPs8txgpRD4iD37DAyOslb7TFcF+etOMPtD6Ym+3iifUpH8Am85SuUsU212B0t10vsGT7ZTD2zW dppbOkF7ncOUQYpQCsXCNO40U25UlbVPoWb0rB/cqfLTtsT3b2mCDt9PSjfjS5AgZRumaWrJPypm h1VTImuiVHFA7M/++VXnxP0YD+0YOzkD8v1PvRR9vc7D+F5EE8gtVyMO4NJgZitVOdYNSrFUYqrp /dFaRWuDvdh5FblJC6gkxeo4ultgujug+qr/Rgt7FNUahvNAXD8snMpIf5c+vSIAU2Xbq7OERtnJ eaV72T1s09LgPZPxKibtXoDOfCAh4r4tT/ZrW7Lexpt4lgF54PY71djGEqTPtcNjgIC/NIjqIAEE eT611lIB8PFT3q39ujp1YuSASRQErGEwggbUMIIFvKADAgECAhBg8QQfKFVWRpx/vUvT+s8qMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMyBDbGllbnQgQ0EwHhcNMTYwNzI5MTIwNjUwWhcNMTkwNzI5MTIwNjUwWjCBkjELMAkG A1UEBhMCQ0gxDzANBgNVBAgMBlp1cmljaDEQMA4GA1UEBwwHQsO8bGFjaDEbMBkGA1UECgwSdGh1 aW5mb3JtYXRpayBHbWJIMRswGQYDVQQDDBJ0aHVpbmZvcm1hdGlrIEdtYkgxJjAkBgkqhkiG9w0B CQEWF3Rob21hc0B0aHVpbmZvcm1hdGlrLmNoMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAt4gSFkzR0O+waPNy4YxbAyLCFmeINKBqMD7cfWegh9JN+W891DReNHC/t8Yhl3Auwhcnj0j6 m1UUEV40/ztEqp2P9+5V5JIMIjFOPO/JxHSwS43nPKmVdJ9TPwnTaEJuPQKNv27ID+cdkvEiWajj wo27BalC5589xpUgkoSQI/TMseEzf+KyzWedImItCZ+KOVYz2F9sQxW/0TRTt360fGe7u5p6n1RS 9+qi/2O4qdnJ6dJG35LqJW7YTEVeJRlqjEbazbghcYFJMdN0NUpGdsTYrMS0w99QTRL5XbajnNh4 /Hd3cdAnvkFRvqY57Htwh6tFLNvy14R4Wu3SDj/LMeJ75FbxsDbicNC/e0H5JJKMinR8Md7iuDNc ts9WATZ59vjolkW/xdKakrozW9d9uZfDrfA3ss6FRpYRdyVR3QnJoJZvdTJe0uGucDEgZBpSdyoO Zp6jR0GOdbahlEt4RxF22ROSM3A4fiHFC5Tws8Ka+9LZD+AajT7+DgQrsog5CpK766qd7G/94kNs eh/iIjp3jb5WpVhfna7zi24Oqs0IIw0Rbp7mFoV0vwdgY8vn6NR4jV8O4xJjnYP0VxT81h/ld3Wo RZPWeWBbmTPhYd9hnA94INmjIDJFwiDR6xinPkM/PgFfEb8HkLXXiCwra0MpiGTSI2pyYQDUdG/R NXkCAwEAAaOCAkAwggI8MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwCQYDVR0TBAIwADAdBgNVHQ4EFgQUFU37q+RDUVI+CeKvkUXOCavMRzMwHwYDVR0jBBgw FoAUNFpzxB+rcWNns0/Amy0gp53myR8wbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5zdGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3NjYS5jbGllbnQzLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9zY2EtY2xpZW50My5jcmwwgZgGA1UdEQSBkDCBjYEXdGhvbWFzQHRodWluZm9ybWF0 aWsuY2iBF29mZmljZUB0aHVpbmZvcm1hdGlrLmNogRtwb3N0bWFzdGVyQHRodWluZm9ybWF0aWsu Y2iBEnN1cHBvcnRAbmV0Y3VsdC5jaIERdGhvbWFzQG5ldGN1bHQuY2iBFXBvc3RtYXN0ZXJAbmV0 Y3VsdC5jaDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wVQYDVR0gBE4wTDAM BgorBgEEAYG1NwYBMDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBABxq8f6Lce/UBYTBVcuxQRfCF6p3 8Jp0EEQLQwIQ9Iw07VTynViuo4PTkmgyT0PhwfAbndhk6ecUz8+BC6Lr6iUiWkqCTVISNhHMk/Mf 9PzlLG1uxMKPBEYAh9qjT0GmoY6mNqji5SaJwb8SInC2JSfdLR/P4euXrKFQMWVRJ4e6NbyglBZJ WQNeDPdlxVAG6FwCWCiPdtm5gP8FaXsmcFBW/AT4j/RISvez+QDJPsLSQrqaQ1KNraFZyfVRPnod nih7xLC2ROQxeAF9/Xh1sqPitENtTmyZ348tDXvSIjfXwETOd4KbXUmhGGelHc4p9GudoIi8472H zkiPWLvIabswggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w NjA5MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSkzI42+Djm I/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk0oWF0sNx 83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2dlwB23QU Jf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrMtWamwmt0 B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvfp1hQ2Th1 qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvhDXD7Y6qo bBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfB CpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQ qNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy 9uMzjF0JSxPfu4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAd BgNVHQ4EFgQUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAv BggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUH AgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcC AjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBM aWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJYIZIAYb4 QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0GCSqGSIb3 DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYopy2YCt7Ga 9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaaRRYWOApe V/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux8y5cZG5z MToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYS r/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7 YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7ed kPQiO674/CrK+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7 c0mjaleHlOXWeMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA5 2NAr9b/sdb+XAsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0 iByADfxyiuiDXjGCBOQwggTgAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMyBDbGllbnQgQ0ECEGDxBB8oVVZGnH+9S9P6zyowCQYFKw4DAhoF AKCCAi8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTI1MTgz NzIwWjAjBgkqhkiG9w0BCQQxFgQUgQuikt/xACNnk6EEnbTqpN6tZeIwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/ vUvT+s8qMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAh BgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/vUvT+s8qMA0GCSqG SIb3DQEBAQUABIICAEoPWSqo9GWkqB3M7w20kx6LR8VUTWfXIypFUSPSu7eAfiho90tIPBU3tWqc Excit45qc8AaTQVT7ycie7GLap65VqxSxBNlMh8qQdVkuK1UjLV/58pQiDbuLtlqCrKlroHitk+Z 7Ro9lU/NKZtDSrLjNTZ2GYlCk31J9w+L1Xtpc0vIpXQ7Aupp3b/4xVb9Fa/raO8JMI83pPoaCAZJ xu/hR9/lSnnhC4cGnTCl6CzUYIg9mo7vKxHrrOFs/v2LqoxNTQbT3DRZbu0RAiCK8gcVAzasiPYM Fq4WXO2MoZrHah0dRW9Wz4uQGY+nxszKdq8qIecj6lfVyrXQHq2lG43i1SJCOjTYtqO0tsstW6kh N4Y7aaUZQl/nNYWuAjVIBf6+l6A5tOJF8kSVjNAw3eyCRXF2Jt0OkEcEvQJLZqnblLjjgb2FNluY fNNfze1BY4MwAWphZNSBfHkKf3L9FCYwTQSWp2DVnbXRDXxKXQ6CaLzDEB4IiOdjc16BUnVR1X1p MLHBgK9uaiBjD0cxzHNexYs8R1vwntw18G7SL36DJcnmJ92N2aHZyH0VxINOhfOi3qMqq39T+ps7 MNXV+H7RhMpCk0QOX9/J2rpIngxY2b8L8ab7vkDwqb89NhYuZe5a07nTFwR1D74Bg2HWawyPRhjm KG5nrj4FwWhbALhdAAAAAAAA ------=_NextPart_000_0082_01D2D596.B4B61C10-- From owner-freebsd-net@freebsd.org Thu May 25 19:37:25 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB10BD82425 for ; Thu, 25 May 2017 19:37:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D56A12AC for ; Thu, 25 May 2017 19:37:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4CF4326011D; Thu, 25 May 2017 21:37:23 +0200 (CEST) Subject: Re: AW: axge0 and AX88179 To: Tom Huerlimann , freebsd-net@freebsd.org References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> From: Hans Petter Selasky Message-ID: <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> Date: Thu, 25 May 2017 21:35:23 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:37:25 -0000 On 05/25/17 20:37, Tom Huerlimann wrote: > Hi all, > > I have the problem, that I cannot reach more than 20-40Mbit/s when using the > AX88179 chip (1Gbit/s NIC) on a USB 3.0 SuperSpeed Port (same on a 480Mbps > High Speed USB v2.0-Port). > > # usbconfig dump_device_desc > (...) > ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER > (5.0Gbps) pwr=ON (124mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0300 > bDeviceClass = 0x00ff > bDeviceSubClass = 0x00ff > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0009 > idVendor = 0x0b95 > idProduct = 0x1790 > bcdDevice = 0x0100 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 <00000000000001> > bNumConfigurations = 0x0001 > > plugged into this USB controller: > > # dmesg | grep -i usb > xhci0: mem 0xd0800000-0xd080ffff irq 20 > at device 20.0 on pci0 usbus0 on xhci0 > ehci0: mem 0xd0815000-0xd08153ff irq 23 > at device 29.0 on pci0 > usbus1: waiting for BIOS to give up control > usbus1: timed out waiting for BIOS > usbus1: EHCI version 1.0 > usbus1 on ehci0 > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > uhub0: on usbus1 > ugen0.1: <0x8086> at usbus0 > uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ugen0.2: at usbus0 > umass0: on usbus0 > ugen0.3: at usbus0 > uhub2: on > usbus0 > ugen1.2: at usbus1 > uhub3: on > usbus1 > ugen0.4: at usbus0 > ukbd0: on usbus0 > uhid0: on usbus0 > ugen0.5: at usbus0 > uhub4: on > usbus0 > ugen0.6: at usbus0 > ukbd1: > on usbus0 > uhid1: > on usbus0 > ugen0.7: at usbus0 > axge0: on usbus0 > ue0: on axge0 > > # dmesg | grep -i axge > axge0: on usbus0 > miibus2: on axge0 > ue0: on axge0 > axge0: at uhub1, port 7, addr 6 (disconnected) > axge0: on usbus0 > miibus2: on axge0 > ue0: on axge0 > axge0: on usbus0 > miibus2: on axge0 > ue0: on axge0 > > I'm using FreeBSD 10.3-RELEASE-p19. > > Did someone of you ever managed to reach a higher bandwidth with axge driver > and AX88179 chipset? Yes, you can reach more than 100Mbit/s with USB 3.0. What does ifconfig say about this device? --HPS From owner-freebsd-net@freebsd.org Thu May 25 20:14:07 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC28DD822F1 for ; Thu, 25 May 2017 20:14:07 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from mail.netcult.ch (mail.netcult.ch [46.140.84.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C19E1E1E for ; Thu, 25 May 2017 20:14:06 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from thunb001 ([192.168.1.200]) (authenticated bits=0) by mail.netcult.ch (8.14.7/8.14.7) with ESMTP id v4PKE1jR031278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 May 2017 22:14:03 +0200 From: "Tom Huerlimann" To: "'Hans Petter Selasky'" , References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> In-Reply-To: <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> Subject: AW: AW: axge0 and AX88179 Date: Thu, 25 May 2017 22:13:59 +0200 Message-ID: <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> X-Mailer: Microsoft Outlook 15.0 MIME-Version: 1.0 Thread-Index: AQJdH3nE5dyHkJndVbel4ZEpsnb59wITsuhloOBDMbA= Content-Language: de-ch Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00ED_01D2D5A4.35515080" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:14:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00ED_01D2D5A4.35515080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Hans Petter Selasky [mailto:hps@selasky.org] On 05/25/17 20:37, Tom Huerlimann wrote: >> Hi all, >> >> I have the problem, that I cannot reach more than 20-40Mbit/s when >> using the >> AX88179 chip (1Gbit/s NIC) on a USB 3.0 SuperSpeed Port (same on a >> 480Mbps High Speed USB v2.0-Port). >> >> # usbconfig dump_device_desc >> (...) >> ugen0.7: > at usbus0, cfg=0 md=HOST spd=SUPER >> (5.0Gbps) pwr=ON (124mA) >> >> bLength = 0x0012 >> bDescriptorType = 0x0001 >> bcdUSB = 0x0300 >> bDeviceClass = 0x00ff > >> bDeviceSubClass = 0x00ff >> bDeviceProtocol = 0x0000 >> bMaxPacketSize0 = 0x0009 >> idVendor = 0x0b95 >> idProduct = 0x1790 >> bcdDevice = 0x0100 >> iManufacturer = 0x0001 > >> iProduct = 0x0002 > >> iSerialNumber = 0x0003 <00000000000001>> >> bNumConfigurations = 0x0001 >> >> plugged into this USB controller: >> >> # dmesg | grep -i usb >> xhci0: > mem 0xd0800000-0xd080ffff >> irq 20 at device 20.0 on pci0 usbus0 on xhci0 >> ehci0: > mem 0xd0815000-0xd08153ff >> irq 23 at device 29.0 on pci0 >> usbus1: waiting for BIOS to give up control >> usbus1: timed out waiting for BIOS >> usbus1: EHCI version 1.0 >> usbus1 on ehci0 >> usbus0: 5.0Gbps Super Speed USB v3.0 >> usbus1: 480Mbps High Speed USB v2.0 >> ugen1.1: > at usbus1 >> uhub0: > on >> usbus1 >> ugen0.1: <0x8086>> at usbus0 >> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1>> on >> usbus0 >> ugen0.2: > at usbus0 >> umass0: > on >> usbus0 >> ugen0.3: > at usbus0 >> uhub2: > >> on >> usbus0 >> ugen1.2: > at usbus1 >> uhub3: > 2>> on >> usbus1 >> ugen0.4: > at usbus0 >> ukbd0: > on usbus0 >> uhid0: > on usbus0 >> ugen0.5: > at usbus0 >> uhub4: > >> on >> usbus0 >> ugen0.6: > at usbus0 >> ukbd1: > addr 5>> on usbus0 >> uhid1: > addr 5>> on usbus0 >> ugen0.7: > at usbus0 >> axge0: > on usbus0 >> ue0: > on axge0 >> >> # dmesg | grep -i axge >> axge0: > on usbus0 >> miibus2: > on axge0 >> ue0: > on axge0 >> axge0: at uhub1, port 7, addr 6 (disconnected) >> axge0: > on usbus0 >> miibus2: > on axge0 >> ue0: > on axge0 >> axge0: > on usbus0 >> miibus2: > on axge0 >> ue0: > on axge0 >> >> I'm using FreeBSD 10.3-RELEASE-p19. >> >> Did someone of you ever managed to reach a higher bandwidth with axge >> driver and AX88179 chipset? >Yes, you can reach more than 100Mbit/s with USB 3.0. >What does ifconfig say about this device? # ifconfig (...) ue0: flags=8843 metric 0 mtu 1500 options=8000b ether a4:f7:d0:00:19:a0 inet6 fe80::a6f7:d0ff:fe00:19a0%ue0 prefixlen 64 scopeid 0x7 inet 1.2.3.4 netmask 0xfffffff8 broadcast 1.2.3.9 inet 1.2.3.5 netmask 0xfffffff8 broadcast 1.2.3.9 inet 1.2.3.6 netmask 0xfffffff8 broadcast 1.2.3.9 inet 1.2.3.7 netmask 0xfffffff8 broadcast 1.2.3.9 inet 1.2.3.8 netmask 0xfffffff8 broadcast 1.2.3.9 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active The host uses the device to be able to act as www-gateway. As soon the WAN link is connected to this AX88179 device the speed drops to 20-40Mbit/s. If WAN link is connected to internal then the host/device is reaching the speed limit of 400Mbit/s. The device uses a direct connection to the WAL link, RJ-45 Kat6 cable. I observe the same behaviour on FreeBSD 10.1-RELEASE-p25. The only thing I can find on the web is https://forum.pfsense.org/index.php?topic=72019.0 I don't have the problem described in the headline: "randomly loses connection, and reboot is only solution." My experience is: (Somethimes!) If link is lost, then a reboot of the OS is required to bring back the functionality of the NIC. Editing /boot/loader.conf.local and changeing kern.ipc.nmbclusters="0" to kern.ipc.nmbclusters="32768" does not solve the performance issue. Does someone have an idea what I did forget to check/verify? -Tom ------=_NextPart_000_00ED_01D2D5A4.35515080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUizCCBeIw ggPKoAMCAQICEDZ5UlTLE1WeMCbSKy5LEOswDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAzIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANYjcOFzVjMVemifqK8VYRDvjxUxEc5soFBfad3Y1e7bZufzKb1/yTalMXW6iepa hiRBta9+i9nf09Rt0CEjNRlkUVTVjdQxUjNWGcvA/7bGqLFOB5Dtc6c66odhMfifEvrFRc6oXDE6 8Civo19smaFJoe7Pzk0DXy5l+f8+8LeSkK2sCeYTSKUecM1kt6v955hgWQWKehqW4XSs5iOJOqWz prW4TxnQLQTemoQEUMaIO2UBfoeXTCeclC9DgDvSl6TA0DqJiLBWA6BFBM4KCmlOOs1Wf3T3Qy3S 3tAuw2glk0VxDqbKC/3ZPMTrU9msz4Uhutgn1HNaOGPcD93A+K8CAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU NFpzxB+rcWNns0/Amy0gp53myR8wHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAtGvTe3y0uo6+hngSROfH4CzL3GmXfQDtt1evpt/fs7Fs VgCT1hOzuNWBQn9KXCQlzfkxm5MBCqGUWz33c+jdiTinIzn4BwyaEds/bGWABSCg3au7Qr5NAG6l 65RD+xRa+JyrCScvt1lCIlAmD0oI5CVCe0Yk0teWa2ZSRZGf+1S2eymzGKh6TaU0q2oYFPjwf7TZ sDcD0Rzklrd3HsjGZy1WUB3zw5eTg5HnNBQ107I7e98xnjhszIUp4ymYRoCr48SnqOibCbUpaVdt TlPs8txgpRD4iD37DAyOslb7TFcF+etOMPtD6Ym+3iifUpH8Am85SuUsU212B0t10vsGT7ZTD2zW dppbOkF7ncOUQYpQCsXCNO40U25UlbVPoWb0rB/cqfLTtsT3b2mCDt9PSjfjS5AgZRumaWrJPypm h1VTImuiVHFA7M/++VXnxP0YD+0YOzkD8v1PvRR9vc7D+F5EE8gtVyMO4NJgZitVOdYNSrFUYqrp /dFaRWuDvdh5FblJC6gkxeo4ultgujug+qr/Rgt7FNUahvNAXD8snMpIf5c+vSIAU2Xbq7OERtnJ eaV72T1s09LgPZPxKibtXoDOfCAh4r4tT/ZrW7Lexpt4lgF54PY71djGEqTPtcNjgIC/NIjqIAEE eT611lIB8PFT3q39ujp1YuSASRQErGEwggbUMIIFvKADAgECAhBg8QQfKFVWRpx/vUvT+s8qMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMyBDbGllbnQgQ0EwHhcNMTYwNzI5MTIwNjUwWhcNMTkwNzI5MTIwNjUwWjCBkjELMAkG A1UEBhMCQ0gxDzANBgNVBAgMBlp1cmljaDEQMA4GA1UEBwwHQsO8bGFjaDEbMBkGA1UECgwSdGh1 aW5mb3JtYXRpayBHbWJIMRswGQYDVQQDDBJ0aHVpbmZvcm1hdGlrIEdtYkgxJjAkBgkqhkiG9w0B CQEWF3Rob21hc0B0aHVpbmZvcm1hdGlrLmNoMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAt4gSFkzR0O+waPNy4YxbAyLCFmeINKBqMD7cfWegh9JN+W891DReNHC/t8Yhl3Auwhcnj0j6 m1UUEV40/ztEqp2P9+5V5JIMIjFOPO/JxHSwS43nPKmVdJ9TPwnTaEJuPQKNv27ID+cdkvEiWajj wo27BalC5589xpUgkoSQI/TMseEzf+KyzWedImItCZ+KOVYz2F9sQxW/0TRTt360fGe7u5p6n1RS 9+qi/2O4qdnJ6dJG35LqJW7YTEVeJRlqjEbazbghcYFJMdN0NUpGdsTYrMS0w99QTRL5XbajnNh4 /Hd3cdAnvkFRvqY57Htwh6tFLNvy14R4Wu3SDj/LMeJ75FbxsDbicNC/e0H5JJKMinR8Md7iuDNc ts9WATZ59vjolkW/xdKakrozW9d9uZfDrfA3ss6FRpYRdyVR3QnJoJZvdTJe0uGucDEgZBpSdyoO Zp6jR0GOdbahlEt4RxF22ROSM3A4fiHFC5Tws8Ka+9LZD+AajT7+DgQrsog5CpK766qd7G/94kNs eh/iIjp3jb5WpVhfna7zi24Oqs0IIw0Rbp7mFoV0vwdgY8vn6NR4jV8O4xJjnYP0VxT81h/ld3Wo RZPWeWBbmTPhYd9hnA94INmjIDJFwiDR6xinPkM/PgFfEb8HkLXXiCwra0MpiGTSI2pyYQDUdG/R NXkCAwEAAaOCAkAwggI8MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwCQYDVR0TBAIwADAdBgNVHQ4EFgQUFU37q+RDUVI+CeKvkUXOCavMRzMwHwYDVR0jBBgw FoAUNFpzxB+rcWNns0/Amy0gp53myR8wbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5zdGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3NjYS5jbGllbnQzLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9zY2EtY2xpZW50My5jcmwwgZgGA1UdEQSBkDCBjYEXdGhvbWFzQHRodWluZm9ybWF0 aWsuY2iBF29mZmljZUB0aHVpbmZvcm1hdGlrLmNogRtwb3N0bWFzdGVyQHRodWluZm9ybWF0aWsu Y2iBEnN1cHBvcnRAbmV0Y3VsdC5jaIERdGhvbWFzQG5ldGN1bHQuY2iBFXBvc3RtYXN0ZXJAbmV0 Y3VsdC5jaDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wVQYDVR0gBE4wTDAM BgorBgEEAYG1NwYBMDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBABxq8f6Lce/UBYTBVcuxQRfCF6p3 8Jp0EEQLQwIQ9Iw07VTynViuo4PTkmgyT0PhwfAbndhk6ecUz8+BC6Lr6iUiWkqCTVISNhHMk/Mf 9PzlLG1uxMKPBEYAh9qjT0GmoY6mNqji5SaJwb8SInC2JSfdLR/P4euXrKFQMWVRJ4e6NbyglBZJ WQNeDPdlxVAG6FwCWCiPdtm5gP8FaXsmcFBW/AT4j/RISvez+QDJPsLSQrqaQ1KNraFZyfVRPnod nih7xLC2ROQxeAF9/Xh1sqPitENtTmyZ348tDXvSIjfXwETOd4KbXUmhGGelHc4p9GudoIi8472H zkiPWLvIabswggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w NjA5MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSkzI42+Djm I/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk0oWF0sNx 83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2dlwB23QU Jf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrMtWamwmt0 B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvfp1hQ2Th1 qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvhDXD7Y6qo bBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfB CpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQ qNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy 9uMzjF0JSxPfu4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAd BgNVHQ4EFgQUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAv BggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUH AgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcC AjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBM aWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJYIZIAYb4 QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0GCSqGSIb3 DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYopy2YCt7Ga 9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaaRRYWOApe V/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux8y5cZG5z MToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYS r/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7 YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7ed kPQiO674/CrK+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7 c0mjaleHlOXWeMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA5 2NAr9b/sdb+XAsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0 iByADfxyiuiDXjGCBOQwggTgAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMyBDbGllbnQgQ0ECEGDxBB8oVVZGnH+9S9P6zyowCQYFKw4DAhoF AKCCAi8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTI1MjAx MzU5WjAjBgkqhkiG9w0BCQQxFgQUdoalmMKHFDLIOjylAG/LNXKukQwwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/ vUvT+s8qMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAh BgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/vUvT+s8qMA0GCSqG SIb3DQEBAQUABIICAGVqHv4QXvRE4Ta0xX6Fp+SE/kLXuRL+rxTopgZW8pUsC0HuWjnTTD4ySELf SNC9NW19FD0LCx/WPPH4alGt/VQJqMfGDaSYhDW+qlAJgbVgVWYWayx1mlsg/Rzpk40lN2sLFRl5 l3TGfeGYSuhaJUqLRw24/AuWQyR+Y5hYHp9pWwjS9vFCnApMZbPVuc+9g+b7cr5GX8QBu7Xp+41s gFkT7LzHRfzar1NrMQ4unv2CH/EtDGeR1XSGH8kckky8q93zsXTBHdkjixLIlmbPeV1GyQkSzqwO yPcSQg/TNOncUzqOoO9PHDpObq/VipdQwxWBJI/frTiPCHVBl0Er49O2MMfCAR0xNfTFLa7k4v2Q HwJmenmHvZ6zDLq8kpXf8w+CS2Z9LSthKhfYwq5MB33Ypji6fLvUyXGM5zHcK/YsQdfd5sE9FuV9 arCaVc+ujeZjnnV2oDjDE6/Z51lVZln6KPd/kvv5KXoNWgvf5GCtYDgXPta3HGITDQuQqTq8MJK+ fPEIFkSjEa57+FfmpcGDBgqD998WAg3LQMUwiKW2UXmfmdMo3r5Pt5M+7wUudgMkkj15/9wHbE9t Vuoj0zEDuJXDx9OIvhioU5Qy0fWiHaXOvtNBoa9+OWDa5dH4kQ8yVEevsese/9IrSaqG9KVs+/ik gXBKvKIdABmgIYqQAAAAAAAA ------=_NextPart_000_00ED_01D2D5A4.35515080-- From owner-freebsd-net@freebsd.org Thu May 25 20:46:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 482DCD82E03 for ; Thu, 25 May 2017 20:46:36 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCF7A1262 for ; Thu, 25 May 2017 20:46:35 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PKkXeW055335; Thu, 25 May 2017 22:46:33 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 83DBC1ED; Thu, 25 May 2017 22:46:33 +0200 (CEST) Message-ID: <592742A8.4010207@omnilan.de> Date: Thu, 25 May 2017 22:46:32 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> In-Reply-To: <592701D6.7030301@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 22:46:33 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:46:36 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:09 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): >> I see the bug is in FreeBSD 11. I attached the simple patch to fix it. >> Can someone commit the patch to 11/stable? >> >> Harry: You should be able to workaround the bug by setting >> >> # sysctl dev.netmap.generic_rings=1 > I'll recompile with your patch, thanks a lot! Hi, unfortunately I can't confirm it to be fixed. The kgdb output is exactly the same: (kgdb) list *0xffffffff80426714 0xffffffff80426714 is in generic_rx_handler (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628). 623 struct netmap_adapter *na = NA(ifp); 624 struct netmap_generic_adapter *gna = (struct netmap_generic_adapter *)na; 625 u_int work_done; 626 u_int rr = MBUF_RXQ(m); // receive ring number 627 628 if (rr >= na->num_rx_rings) { 629 rr = rr % na->num_rx_rings; // XXX expensive... 630 } 631 632 /* limit the size of the queue */ Current language: auto; currently minimal Will double-check tomorrow that the binary really includes your patch. Ofcourse I checked briefly and revision and buildtime check affirms it. best, -harry From owner-freebsd-net@freebsd.org Thu May 25 20:49:49 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35030D82F3F for ; Thu, 25 May 2017 20:49:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F38EC13BA for ; Thu, 25 May 2017 20:49:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 650C826011D; Thu, 25 May 2017 22:49:45 +0200 (CEST) Subject: Re: AW: AW: axge0 and AX88179 To: Tom Huerlimann , freebsd-net@freebsd.org References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> From: Hans Petter Selasky Message-ID: <0b953cc0-f361-84fa-fc94-249a3029f51f@selasky.org> Date: Thu, 25 May 2017 22:47:45 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:49:49 -0000 Hi, > > Does someone have an idea what I did forget to check/verify? > You can try to enable debugging: sysctl hw.usb.axge.debug=255 Or: Try to log the USB traffic using "usbdump" usbdump -i usbusX -f y -s 65536 And look for errors like "ERR". Did you verify two such adapters back2back with iperf, for packetloss and other issues? --HPS From owner-freebsd-net@freebsd.org Thu May 25 20:53:23 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AD0ED822FF for ; Thu, 25 May 2017 20:53:23 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8BC1AF0 for ; Thu, 25 May 2017 20:53:22 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4PKrK7O055387; Thu, 25 May 2017 22:53:20 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id DC6FB1F2; Thu, 25 May 2017 22:53:19 +0200 (CEST) Message-ID: <5927443F.8080502@omnilan.de> Date: Thu, 25 May 2017 22:53:19 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> In-Reply-To: <592742A8.4010207@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 May 2017 22:53:20 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:53:23 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 22:46 (localtime): > Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:09 (localtime): >> Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localtime): >>> I see the bug is in FreeBSD 11. I attached the simple patch to fix it. >>> Can someone commit the patch to 11/stable? >>> >>> Harry: You should be able to workaround the bug by setting >>> >>> # sysctl dev.netmap.generic_rings=1 >> I'll recompile with your patch, thanks a lot! > Hi, unfortunately I can't confirm it to be fixed. > > The kgdb output is exactly the same: > > (kgdb) list *0xffffffff80426714 > 0xffffffff80426714 is in generic_rx_handler > (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628). > 623 struct netmap_adapter *na = NA(ifp); > 624 struct netmap_generic_adapter *gna = (struct > netmap_generic_adapter *)na; > 625 u_int work_done; > 626 u_int rr = MBUF_RXQ(m); // receive ring number > 627 > 628 if (rr >= na->num_rx_rings) { > 629 rr = rr % na->num_rx_rings; // XXX expensive... > 630 } > 631 > 632 /* limit the size of the queue */ > Current language: auto; currently minimal > > Will double-check tomorrow that the binary really includes your patch. > Ofcourse I checked briefly and revision and buildtime check affirms it. Last note for today; late here: The patch is against sys/dev/netmap/netmap_freebsd.c (at least my interpretation of it, since f1.c wasN#t applicable), and the debugger claims sys/dev/netmap/netmap_generic.c! thnaks, -harry From owner-freebsd-net@freebsd.org Thu May 25 20:57:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C6A2D824D7 for ; Thu, 25 May 2017 20:57:12 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BD0F1CC1 for ; Thu, 25 May 2017 20:57:12 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id b204so295406336oii.1 for ; Thu, 25 May 2017 13:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y/6MH5ggdekZ+um/3vA9KQAoAAYrDk+U+Y3saV85EjM=; b=MX2HMKlWX2VKiYGSO1W7d9jcwwpFxHaouSU3e9c5ACxS45Gh1Hrfm0pjWVoD1LWwCu sUaGLmoDr0ycwpDbcIk9fpevLCmdmAWTbjv+OBlrI3Vaok+u0Er7FDTmvir+IBO1XAko zm8sZWL9MlddcAbqQ/JVy2y4SP5MZ+hctwpdAieR9wT9wIQcrDXfjAceaFjg/xj8Px3o zU7J4d9FvQzC00/tYPD/WWK6AlCTTrVMhZ8/eG0I7ISmYFHMXuuxlaaeUba5YleVsgYg 1bHp6lOAmdzirCTbRvmfl3I0Z5pAsbsIv4yhr919a3Wndu7mj0c/Cv7raLmDG3BJgcnf RaXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y/6MH5ggdekZ+um/3vA9KQAoAAYrDk+U+Y3saV85EjM=; b=SBHAvPDE709vGsRoVwviqs3Eq3z2Rc3WxW31t5AzqGTudTshwxCFbHbxkE1+IDoEeA SbWtYDz0R8HRKfZqAEAiqOBZWacuKzFw4qQwNbL0bDN2SUo37Q2jDGzUGMQnwHooyuzO 8GBKwFlrqgaCNTwxnAdKIlJXglnsPwhngqIj5XZOqnbr95Q0kbiMEdkb/bocXbiJ2STP lPefB63x/SrAPA/5j/1FY58TFo5eQIUL9pitq9z1qvkLsme0uE2ISD4DvgKlgHKi4d7R VAOoVV8keXcQXCCQlD1CWRQe7xQwrXBvsHa40lW3g5cf97QiBZtwDSQaxAD46vRWZN5G i9jg== X-Gm-Message-State: AODbwcC8YEkepJJwY0RkarMsu0IPfLXnYDP/Eeflql79scxxyJ5lQQHx 9fJXIgxTLyLdt9QVkteobor5lGmSdA== X-Received: by 10.157.23.133 with SMTP id j5mr7644846otj.37.1495745831524; Thu, 25 May 2017 13:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Thu, 25 May 2017 13:57:10 -0700 (PDT) Received: by 10.157.17.59 with HTTP; Thu, 25 May 2017 13:57:10 -0700 (PDT) In-Reply-To: <592742A8.4010207@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> From: Vincenzo Maffione Date: Thu, 25 May 2017 22:57:10 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:57:12 -0000 No, the thing is that I misinterpreted your stack trace. The patch is ok for a different bug. It seems that the problem are vlans more than lagg. Which interface did you put in netmap mode, em or em.345? Il 25 mag 2017 10:46 PM, "Harry Schmalzbauer" ha scritto: Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:09 (localt= ime): > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 25.05.2017 17:56 (localt= ime): >> I see the bug is in FreeBSD 11. I attached the simple patch to fix it. >> Can someone commit the patch to 11/stable? >> >> Harry: You should be able to workaround the bug by setting >> >> # sysctl dev.netmap.generic_rings=3D1 > I'll recompile with your patch, thanks a lot! Hi, unfortunately I can't confirm it to be fixed. The kgdb output is exactly the same: (kgdb) list *0xffffffff80426714 0xffffffff80426714 is in generic_rx_handler (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ netmap_generic.c:628). 623 struct netmap_adapter *na =3D NA(ifp); 624 struct netmap_generic_adapter *gna =3D (struct netmap_generic_adapter *)na; 625 u_int work_done; 626 u_int rr =3D MBUF_RXQ(m); // receive ring number 627 628 if (rr >=3D na->num_rx_rings) { 629 rr =3D rr % na->num_rx_rings; // XXX expensive... 630 } 631 632 /* limit the size of the queue */ Current language: auto; currently minimal Will double-check tomorrow that the binary really includes your patch. Ofcourse I checked briefly and revision and buildtime check affirms it. best, -harry From owner-freebsd-net@freebsd.org Thu May 25 21:51:47 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51044D8293A for ; Thu, 25 May 2017 21:51:47 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 135731166 for ; Thu, 25 May 2017 21:51:47 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: by mail-io0-x232.google.com with SMTP id f102so144207247ioi.2 for ; Thu, 25 May 2017 14:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c5v3ssy6uN6QkTQ6TtfuJSWKQswekY2HqVUom/quIFo=; b=BtdzS2LiXQ1ulyaOoHOcppXw10H+Eko+W7SQsE7ckTsZOqu9OsCZBRtHOXS9kWW0sN DG3PzDFOmG+2MTALJYz3GZgyavO384gwUlAYHBtRmQaGLpMNv8aGpIv7RAw8NTHaz6uA Qiqfw2NPftoztoFH40DkbfacL+Xvm2m9R5CXO9+oq85hrzEqbcfMMavPf3gle2uTv2GY 4jk0Qpxes3PGrKl1KxzLmr+yoeh9UDu6y2gooqvjZorvt5jfUZNzMAUhbRmj18yW/aBJ V/LEo/T2VBlJT+slx1Ur1Nj4WZtg5reYvvC9/v/6zYjv6J+tSD93xnl6XcjEflCex7rb 0fNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=c5v3ssy6uN6QkTQ6TtfuJSWKQswekY2HqVUom/quIFo=; b=cDWV4W3rCZeo+R7wpiaVvxZCY0VI7+qwTuG+DcR0TxxRv26Iy5jQYAgJK/pXxYxgfx oDpjVSt326u7DcqHNkYnAWGfl7NPnbXt4W5jDk7u6usGf4mY6gzlW9exvkzfObMbb53y wc7oNriG3B8GfHygZQSf4Bq2ZGBGJ9c4cJjS9rHYCSlAMpOwHKtXCP6zvQPQBE5EC4cm sPIVpEmH0Gx5Rr8QqKCbeFWgbADexpurH5bK/pwwcbAWqrA1FRZF96nT5r59SDJio/2o mef9e9fPMp4+PHqWgluKSqAco72Hs4nJCSq+6y6ecdALXqUWqyBxIR4Omo5y+GthNowN 3WfQ== X-Gm-Message-State: AODbwcC+rJUjZRrHTdqbvSpFwPalW/BXKlzhZ1gBEl3t5K+M7aaFR/Ba urmUTxJwb8rWeSMTTVOjcryNpaUL+Q== X-Received: by 10.107.134.72 with SMTP id i69mr4539256iod.118.1495749106261; Thu, 25 May 2017 14:51:46 -0700 (PDT) MIME-Version: 1.0 Reply-To: syrinx@freebsd.org Sender: shteryana@gmail.com Received: by 10.107.132.99 with HTTP; Thu, 25 May 2017 14:51:45 -0700 (PDT) In-Reply-To: <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> From: Shteryana Shopova Date: Fri, 26 May 2017 00:51:45 +0300 X-Google-Sender-Auth: aA4KNNltgOQIAXm-uCGRVrJ2guE Message-ID: Subject: Re: AW: axge0 and AX88179 To: Tom Huerlimann Cc: Hans Petter Selasky , "freebsd-net@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 21:51:47 -0000 Hi all, I've experienced a similar problem but didn't get to analyzing it deeper (or reporting) unfortunately ; the device is ugen0.8: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x00ff bDeviceSubClass = 0x00ff bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x0b95 idProduct = 0x1790 bcdDevice = 0x0100 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 <000000000000C> bNumConfigurations = 0x0001 what I've noticed so far - dhclient complains about wrong ip length - % sudo dhclient ue1 DHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 7 ifconDHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 15 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPOFFER from 192.168.10.1 DHCPREQUEST on ue1 to 255.255.255.255 port 67 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPACK from 192.168.10.1 bound to 192.168.10.7 -- renewal in 3600 seconds. Running iperf3 & watching netstat -i at the same time on the interface in question shows increasing InErrors on the interface - Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll ... ue1 1500 00:0e:c6:c6:db:ea 66333 354 0 35939 0 0 ue1 - 192.168.10.0/24 192.168.10.7 66323 - - 35927 - - Iperf reports ~37.1 Mbits/sec on the interface. If I attach the device on a USB2 port (or force USB2 speed on the port) I was able to get ~ 150-200Mbits on the same system with the same device. This particular system has an Intel Lynx Point USB 3.0 controller pciconf -lv | grep -A 4 xhci xhci0@pci0:0:20:0: class=0x0c0330 card=0x8179103c chip=0x8c318086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family USB xHCI' class = serial bus subclass = USB ,is running FreeBSD 12.0-CURRENT #19 r315483M (M stands for a patch similar to https://people.freebsd.org/~syrinx/freebsd_xhci-20170318-01.diff needed to trick the controller on that particular system to actually use USB3.0 speeds). The same ASIX AX88179 device worked just fine reaching over 500 Mbits/sec on another system running 11.0-RELEASE-p7 with a different USB 3 controller (will double check and report back at first opportunity). Hope this helps. cheers, Shteryana On Thu, May 25, 2017 at 11:13 PM, Tom Huerlimann wrote: > From: Hans Petter Selasky [mailto:hps@selasky.org] > On 05/25/17 20:37, Tom Huerlimann wrote: >>> Hi all, >>> >>> I have the problem, that I cannot reach more than 20-40Mbit/s when >>> using the >>> AX88179 chip (1Gbit/s NIC) on a USB 3.0 SuperSpeed Port (same on a >>> 480Mbps High Speed USB v2.0-Port). >>> >>> # usbconfig dump_device_desc >>> (...) >>> ugen0.7: > at usbus0, cfg=0 md=HOST spd=SUPER >>> (5.0Gbps) pwr=ON (124mA) >>> >>> bLength = 0x0012 >>> bDescriptorType = 0x0001 >>> bcdUSB = 0x0300 >>> bDeviceClass = 0x00ff > >>> bDeviceSubClass = 0x00ff >>> bDeviceProtocol = 0x0000 >>> bMaxPacketSize0 = 0x0009 >>> idVendor = 0x0b95 >>> idProduct = 0x1790 >>> bcdDevice = 0x0100 >>> iManufacturer = 0x0001 > >>> iProduct = 0x0002 > >>> iSerialNumber = 0x0003 <00000000000001>> >>> bNumConfigurations = 0x0001 >>> >>> plugged into this USB controller: >>> >>> # dmesg | grep -i usb >>> xhci0: > mem 0xd0800000-0xd080ffff >>> irq 20 at device 20.0 on pci0 usbus0 on xhci0 >>> ehci0: > mem 0xd0815000-0xd08153ff >>> irq 23 at device 29.0 on pci0 >>> usbus1: waiting for BIOS to give up control >>> usbus1: timed out waiting for BIOS >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci0 >>> usbus0: 5.0Gbps Super Speed USB v3.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> ugen1.1: > at usbus1 >>> uhub0: > on >>> usbus1 >>> ugen0.1: <0x8086>> at usbus0 >>> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1>> on >>> usbus0 >>> ugen0.2: > at usbus0 >>> umass0: > on >>> usbus0 >>> ugen0.3: > at usbus0 >>> uhub2: > >>> on >>> usbus0 >>> ugen1.2: > at usbus1 >>> uhub3: >> 2>> on >>> usbus1 >>> ugen0.4: > at usbus0 >>> ukbd0: > on usbus0 >>> uhid0: > on usbus0 >>> ugen0.5: > at usbus0 >>> uhub4: > >>> on >>> usbus0 >>> ugen0.6: > at usbus0 >>> ukbd1: >> addr 5>> on usbus0 >>> uhid1: >> addr 5>> on usbus0 >>> ugen0.7: > at usbus0 >>> axge0: > on usbus0 >>> ue0: > on axge0 >>> >>> # dmesg | grep -i axge >>> axge0: > on usbus0 >>> miibus2: > on axge0 >>> ue0: > on axge0 >>> axge0: at uhub1, port 7, addr 6 (disconnected) >>> axge0: > on usbus0 >>> miibus2: > on axge0 >>> ue0: > on axge0 >>> axge0: > on usbus0 >>> miibus2: > on axge0 >>> ue0: > on axge0 >>> >>> I'm using FreeBSD 10.3-RELEASE-p19. >>> >>> Did someone of you ever managed to reach a higher bandwidth with axge >>> driver and AX88179 chipset? > >>Yes, you can reach more than 100Mbit/s with USB 3.0. > >>What does ifconfig say about this device? > > # ifconfig > (...) > ue0: flags=8843 metric 0 mtu 1500 > options=8000b > ether a4:f7:d0:00:19:a0 > inet6 fe80::a6f7:d0ff:fe00:19a0%ue0 prefixlen 64 scopeid 0x7 > inet 1.2.3.4 netmask 0xfffffff8 broadcast 1.2.3.9 > inet 1.2.3.5 netmask 0xfffffff8 broadcast 1.2.3.9 > inet 1.2.3.6 netmask 0xfffffff8 broadcast 1.2.3.9 > inet 1.2.3.7 netmask 0xfffffff8 broadcast 1.2.3.9 > inet 1.2.3.8 netmask 0xfffffff8 broadcast 1.2.3.9 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > The host uses the device to be able to act as www-gateway. As soon the WAN > link > is connected to this AX88179 device the speed drops to 20-40Mbit/s. > If WAN link is connected to internal PCIe Gigabit Ethernet> > then the host/device is reaching the speed limit of 400Mbit/s. > The device uses a direct connection to the WAL link, RJ-45 Kat6 cable. > I observe the same behaviour on FreeBSD 10.1-RELEASE-p25. > > The only thing I can find on the web is > https://forum.pfsense.org/index.php?topic=72019.0 > I don't have the problem described in the headline: "randomly loses > connection, and reboot is only solution." > My experience is: (Somethimes!) If link is lost, then a reboot of the OS is > required to bring back the functionality of the NIC. > > Editing /boot/loader.conf.local and changeing kern.ipc.nmbclusters="0" to > kern.ipc.nmbclusters="32768" does not solve the performance issue. > > Does someone have an idea what I did forget to check/verify? > > -Tom From owner-freebsd-net@freebsd.org Thu May 25 22:28:09 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C83FD80461 for ; Thu, 25 May 2017 22:28:09 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from mail.netcult.ch (mail.netcult.ch [46.140.84.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE6814C8 for ; Thu, 25 May 2017 22:28:07 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from thunb001 ([192.168.1.200]) (authenticated bits=0) by mail.netcult.ch (8.14.7/8.14.7) with ESMTP id v4PMS3gw003953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 May 2017 00:28:04 +0200 From: "Tom Huerlimann" To: "'Hans Petter Selasky'" , References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> <0b953cc0-f361-84fa-fc94-249a3029f51f@selasky.org> In-Reply-To: <0b953cc0-f361-84fa-fc94-249a3029f51f@selasky.org> Subject: AW: AW: AW: axge0 and AX88179 Date: Fri, 26 May 2017 00:28:02 +0200 Message-ID: <013c01d2d5a6$2c022070$84066150$@thuinformatik.ch> X-Mailer: Microsoft Outlook 15.0 MIME-Version: 1.0 Thread-Index: AQJdH3nE5dyHkJndVbel4ZEpsnb59wITsuhlAoViI88CPZzVcqC6S8Mw Content-Language: de-ch Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0136_01D2D5B6.EF17BC40" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 22:28:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0136_01D2D5B6.EF17BC40 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0137_01D2D5B6.EF17BC40" ------=_NextPart_001_0137_01D2D5B6.EF17BC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Hans Petter Selasky [mailto:hps@selasky.org] Hello HPS > You can try to enable debugging: > sysctl hw.usb.axge.debug=255 # sysctl hw.usb.axge.debug=255 sysctl: unknown oid 'hw.usb.axge.debug': No such file or directory # sysctl hw.usb hw.usb.ucom.cons_baud: 9600 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_unit: -1 hw.usb.ucom.pps_mode: 0 hw.usb.uftdi.skip_jtag_interfaces: 1 hw.usb.urtw.preamble_mode: 2 hw.usb.uath.regdomain: 0 hw.usb.uath.countrycode: 0 hw.usb.full_ddesc: 0 hw.usb.no_cs_fail: 0 hw.usb.disable_port_power: 0 hw.usb.disable_enumeration: 0 hw.usb.power_timeout: 30 hw.usb.usb_lang_mask: 255 hw.usb.usb_lang_id: 9 hw.usb.template: 0 hw.usb.debug: 0 hw.usb.no_shutdown_wait: 0 hw.usb.no_suspend_wait: 0 hw.usb.no_boot_wait: 0 hw.usb.xhci.streams: 0 # sysctl hw.usb.debug=255 hw.usb.debug: 0 -> 255 # sysctl hw.usb.debug hw.usb.debug: 255 There is nothing printed to the console and I searched for the DEBUG logs in /var/logs/system.log. I also tried with value '1' because I found a website saying value 1 is to enable debug mode - just to exclude that. # sysctl hw.usb.debug=1 hw.usb.debug: 255 -> 1 # sysctl hw.usb.debug hw.usb.debug: 1 Same: Noting on console nor system.log. There is nothing logged or I don't know where to find the logs. Do you know where the logs are? > Or: > Try to log the USB traffic using "usbdump" > usbdump -i usbusX -f y -s 65536 > And look for errors like "ERR". # usbdump -i usbus0 -f 7 -s 65535 | grep -i ERR (...) 23:44:41.604114 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.604367 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.605907 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.606159 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.606651 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.606905 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.608688 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.608944 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=6104,IVAL=0,ERR=0 23:44:41.609196 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=4576,IVAL=0,ERR=0 23:44:41.609448 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.609701 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.609958 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=2,SLEN=0,IVAL=0,ERR=0 # usbdump -i usbus0 -f 7 -s 65535 | grep -v ERR=0 (...) 23:48:07.877798 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882190 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882438 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882447 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882696 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882708 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882952 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882964 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 Result: ERR is always = 0 or ERR=0 is not present in the output. > Did you verify two such adapters back2back with iperf, for packetloss and other issues? On FreeBSD 10.3-RELEASE-p19 is one adapter and on my other box containing FreeBSD 10.1-RELEASE-p25 is another adapter. After I did some bandwith test with slow performance, I have those statistics (full output off netstat -s attached): # netstat -s | egrep -i 'loss|retran' 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 retransmit timeouts 0 retransmitted 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 TSN's marked for Fast Retran Is that the information you are asking for? Thank you for your time, I'm very interested in finding the root cause for this one. Have a good day Tom ------=_NextPart_001_0137_01D2D5B6.EF17BC40 Content-Type: text/plain; name="netstat-s.log.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netstat-s.log.txt" # netstat -s tcp: 368 packets sent 251 data packets (62352 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 114 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 3 control packets 279 packets received 177 acks (for 58426 bytes) 5 duplicate acks 0 acks for unsent data 107 packets (9305 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 7 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 7 connections established (including accepts) 16 connections closed (including 3 drops) 2 connections updated cached RTT on close 2 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 164 segments updated rtt (of 151 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 56 correct ACK header predictions 87 correct data packet header predictions 7 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 7 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 7 cookies sent 0 cookies received 1 hostcache entry added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window 0 packets with valid tcp-md5 signature received 0 packets with invalid tcp-md5 signature received 0 packets with tcp-md5 signature mismatch 0 packets with unexpected tcp-md5 signature received 0 packets without expected tcp-md5 signature received udp: 558 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 127 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 431 delivered 2729 datagrams output 0 times multicast source filter matched sctp: 0 input packets 0 datagrams 0 packets that had data 0 input SACK chunks 0 input DATA chunks 0 duplicate DATA chunks 0 input HB chunks 0 HB-ACK chunks 0 input ECNE chunks 0 input AUTH chunks 0 chunks missing AUTH 0 invalid HMAC ids received 0 invalid secret ids received 0 auth failed 0 fast path receives all one chunk 0 fast path multi-part data 0 output packets 0 output SACKs 0 output DATA chunks 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 FR's that happened more than once to same chunk 0 output HB chunks 0 output ECNE chunks 0 output AUTH chunks 0 ip_output error counter Packet drop statistics: 0 from middle box 0 from end host 0 with data 0 non-data, non-endhost 0 non-endhost, bandwidth rep only 0 not enough for chunk header 0 not enough data to confirm 0 where process_chunk_drop said break 0 failed to find TSN 0 attempt reverse TSN lookup 0 e-host confirms zero-rwnd 0 midbox confirms no space 0 data did not match TSN 0 TSN's marked for Fast Retran Timeouts: 0 iterator timers fired 0 T3 data time outs 0 window probe (T3) timers fired 0 INIT timers fired 0 sack timers fired 0 shutdown timers fired 0 heartbeat timers fired 0 a cookie timeout fired 0 an endpoint changed its cookiesecret 0 PMTU timers fired 0 shutdown ack timers fired 0 shutdown guard timers fired 0 stream reset timers fired 0 early FR timers fired 0 an asconf timer fired 0 auto close timer fired 0 asoc free timers expired 0 inp free timers expired 0 packet shorter than header 0 checksum error 0 no endpoint for port 0 bad v-tag 0 bad SID 0 no memory 0 number of multiple FR in a RTT window 0 RFC813 allowed sending 0 RFC813 does not allow sending 0 times max burst prohibited sending 0 look ahead tells us no memory in interface 0 numbers of window probes sent 0 times an output error to clamp down on next user send 0 times sctp_senderrors were caused from a user 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 times a ECN reduced the cwnd 0 used express lookup via vtag 0 collision in express lookup 0 times the sender ran dry of user data on primary 0 same for above 0 sacks the slow way 0 window update only sacks sent 0 sends with sinfo_flags !=0 0 unordered sends 0 sends with EOF flag set 0 sends with ABORT flag set 0 times protocol drain called 0 times we did a protocol drain 0 times recv was called with peek 0 cached chunks used 0 cached stream oq's used 0 unread messages abandonded by close 0 send burst avoidance, already max burst inflight to net 0 send cwnd full avoidance, already max burst inflight to net 0 number of map array over-runs via fwd-tsn's ip: 146618 total packets received 0 bad header checksums 0 with size smaller than minimum 80 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 11333 packets for this host 0 packets for unknown/unsupported protocol 132300 packets forwarded (0 packets fast forwarded) 1914 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 5380 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 72 output packets discarded due to no route 25 output datagrams fragmented 50 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 1877 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: echo reply: 87 destination unreachable: 1774 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 412 destination unreachable: 1875 echo: 87 87 message responses generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent ipsec: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 8 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 3207 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures AH output histogram: hmac-sha2-256: 622 hmac-sha2-512: 6709 esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 58 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 4090 packets in 3299 packets out 0 packets dropped; invalid TDB 1862432 bytes in 477901 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ESP output histogram: rijndael-cbc: 7331 ipcomp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 packets sent uncompressed; size < compr. algo. threshold 0 packets sent uncompressed; compression was useless pim: 0 messages received 0 bytes received 0 messages received with too few bytes 0 messages received with bad checksum 0 messages received with bad version 0 data register messages received 0 data register bytes received 0 data register messages received on wrong iif 0 bad registers received 0 data register messages sent 0 data register bytes sent carp: 0 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error pfsync: 0 packets received (IPv4) 0 packets received (IPv6) 0 clear all requests received 0 state inserts received 0 state inserted acks received 0 state updates received 0 compressed state updates received 0 uncompressed state requests received 0 state deletes received 0 compressed state deletes received 0 fragment inserts received 0 fragment deletes received 0 bulk update marks received 0 TDB replay counter updates received 0 end of frame marks received 0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 0 stale states 0 failed state lookup/inserts 0 packets sent (IPv4) 0 packets sent (IPv6) 0 clear all requests sent 0 state inserts sent 0 state inserted acks sent 0 state updates sent 0 compressed state updates sent 0 uncompressed state requests sent 0 state deletes sent 0 compressed state deletes sent 0 fragment inserts sent 0 fragment deletes sent 0 bulk update marks sent 0 TDB replay counter updates sent 0 end of frame marks sent 0 failures due to mbuf memory error 0 send errors arp: 165 ARP requests sent 68 ARP replies sent 199 ARP requests received 47 ARP replies received 246 ARP packets received 3013 total packets dropped due to no ARP entry 14 ARP entrys timed out 34 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 12 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 198 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 1 failure of source address selection source addresses on a non-outgoing I/F 1 addresses scope=f Source addresses selection rule applied: 1 same address icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 3 MLDv2 listener report: 3 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes ipsec6: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 0 mbufs inserted during makespace rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output pfkey: 535 requests sent from userland 49696 bytes sent from userland histogram by message type: getspi: 8 add: 16 delete: 12 get: 20 register: 2 x_spdupdate: 30 x_spdadd: 28 x_spdget: 419 0 messages with invalid length field 0 messages with invalid version field 0 messages with invalid message type field 0 messages too short 0 messages with memory allocation failure 0 messages with duplicate extension 0 messages with invalid extension type 0 messages with invalid sa type 0 messages with invalid address extension 540 requests sent to userland 98992 bytes sent to userland histogram by message type: getspi: 8 add: 16 delete: 13 get: 20 acquire: 4 register: 2 x_spdupdate: 30 x_spdadd: 28 x_spdget: 419 448 messages toward single socket 85 messages toward all sockets 12 messages toward registered sockets 0 messages with memory allocation failure ------=_NextPart_001_0137_01D2D5B6.EF17BC40-- ------=_NextPart_000_0136_01D2D5B6.EF17BC40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUizCCBeIw ggPKoAMCAQICEDZ5UlTLE1WeMCbSKy5LEOswDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAzIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANYjcOFzVjMVemifqK8VYRDvjxUxEc5soFBfad3Y1e7bZufzKb1/yTalMXW6iepa hiRBta9+i9nf09Rt0CEjNRlkUVTVjdQxUjNWGcvA/7bGqLFOB5Dtc6c66odhMfifEvrFRc6oXDE6 8Civo19smaFJoe7Pzk0DXy5l+f8+8LeSkK2sCeYTSKUecM1kt6v955hgWQWKehqW4XSs5iOJOqWz prW4TxnQLQTemoQEUMaIO2UBfoeXTCeclC9DgDvSl6TA0DqJiLBWA6BFBM4KCmlOOs1Wf3T3Qy3S 3tAuw2glk0VxDqbKC/3ZPMTrU9msz4Uhutgn1HNaOGPcD93A+K8CAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU NFpzxB+rcWNns0/Amy0gp53myR8wHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAtGvTe3y0uo6+hngSROfH4CzL3GmXfQDtt1evpt/fs7Fs VgCT1hOzuNWBQn9KXCQlzfkxm5MBCqGUWz33c+jdiTinIzn4BwyaEds/bGWABSCg3au7Qr5NAG6l 65RD+xRa+JyrCScvt1lCIlAmD0oI5CVCe0Yk0teWa2ZSRZGf+1S2eymzGKh6TaU0q2oYFPjwf7TZ sDcD0Rzklrd3HsjGZy1WUB3zw5eTg5HnNBQ107I7e98xnjhszIUp4ymYRoCr48SnqOibCbUpaVdt TlPs8txgpRD4iD37DAyOslb7TFcF+etOMPtD6Ym+3iifUpH8Am85SuUsU212B0t10vsGT7ZTD2zW dppbOkF7ncOUQYpQCsXCNO40U25UlbVPoWb0rB/cqfLTtsT3b2mCDt9PSjfjS5AgZRumaWrJPypm h1VTImuiVHFA7M/++VXnxP0YD+0YOzkD8v1PvRR9vc7D+F5EE8gtVyMO4NJgZitVOdYNSrFUYqrp /dFaRWuDvdh5FblJC6gkxeo4ultgujug+qr/Rgt7FNUahvNAXD8snMpIf5c+vSIAU2Xbq7OERtnJ eaV72T1s09LgPZPxKibtXoDOfCAh4r4tT/ZrW7Lexpt4lgF54PY71djGEqTPtcNjgIC/NIjqIAEE eT611lIB8PFT3q39ujp1YuSASRQErGEwggbUMIIFvKADAgECAhBg8QQfKFVWRpx/vUvT+s8qMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMyBDbGllbnQgQ0EwHhcNMTYwNzI5MTIwNjUwWhcNMTkwNzI5MTIwNjUwWjCBkjELMAkG A1UEBhMCQ0gxDzANBgNVBAgMBlp1cmljaDEQMA4GA1UEBwwHQsO8bGFjaDEbMBkGA1UECgwSdGh1 aW5mb3JtYXRpayBHbWJIMRswGQYDVQQDDBJ0aHVpbmZvcm1hdGlrIEdtYkgxJjAkBgkqhkiG9w0B CQEWF3Rob21hc0B0aHVpbmZvcm1hdGlrLmNoMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAt4gSFkzR0O+waPNy4YxbAyLCFmeINKBqMD7cfWegh9JN+W891DReNHC/t8Yhl3Auwhcnj0j6 m1UUEV40/ztEqp2P9+5V5JIMIjFOPO/JxHSwS43nPKmVdJ9TPwnTaEJuPQKNv27ID+cdkvEiWajj wo27BalC5589xpUgkoSQI/TMseEzf+KyzWedImItCZ+KOVYz2F9sQxW/0TRTt360fGe7u5p6n1RS 9+qi/2O4qdnJ6dJG35LqJW7YTEVeJRlqjEbazbghcYFJMdN0NUpGdsTYrMS0w99QTRL5XbajnNh4 /Hd3cdAnvkFRvqY57Htwh6tFLNvy14R4Wu3SDj/LMeJ75FbxsDbicNC/e0H5JJKMinR8Md7iuDNc ts9WATZ59vjolkW/xdKakrozW9d9uZfDrfA3ss6FRpYRdyVR3QnJoJZvdTJe0uGucDEgZBpSdyoO Zp6jR0GOdbahlEt4RxF22ROSM3A4fiHFC5Tws8Ka+9LZD+AajT7+DgQrsog5CpK766qd7G/94kNs eh/iIjp3jb5WpVhfna7zi24Oqs0IIw0Rbp7mFoV0vwdgY8vn6NR4jV8O4xJjnYP0VxT81h/ld3Wo RZPWeWBbmTPhYd9hnA94INmjIDJFwiDR6xinPkM/PgFfEb8HkLXXiCwra0MpiGTSI2pyYQDUdG/R NXkCAwEAAaOCAkAwggI8MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwCQYDVR0TBAIwADAdBgNVHQ4EFgQUFU37q+RDUVI+CeKvkUXOCavMRzMwHwYDVR0jBBgw FoAUNFpzxB+rcWNns0/Amy0gp53myR8wbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5zdGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3NjYS5jbGllbnQzLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9zY2EtY2xpZW50My5jcmwwgZgGA1UdEQSBkDCBjYEXdGhvbWFzQHRodWluZm9ybWF0 aWsuY2iBF29mZmljZUB0aHVpbmZvcm1hdGlrLmNogRtwb3N0bWFzdGVyQHRodWluZm9ybWF0aWsu Y2iBEnN1cHBvcnRAbmV0Y3VsdC5jaIERdGhvbWFzQG5ldGN1bHQuY2iBFXBvc3RtYXN0ZXJAbmV0 Y3VsdC5jaDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wVQYDVR0gBE4wTDAM BgorBgEEAYG1NwYBMDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBABxq8f6Lce/UBYTBVcuxQRfCF6p3 8Jp0EEQLQwIQ9Iw07VTynViuo4PTkmgyT0PhwfAbndhk6ecUz8+BC6Lr6iUiWkqCTVISNhHMk/Mf 9PzlLG1uxMKPBEYAh9qjT0GmoY6mNqji5SaJwb8SInC2JSfdLR/P4euXrKFQMWVRJ4e6NbyglBZJ WQNeDPdlxVAG6FwCWCiPdtm5gP8FaXsmcFBW/AT4j/RISvez+QDJPsLSQrqaQ1KNraFZyfVRPnod nih7xLC2ROQxeAF9/Xh1sqPitENtTmyZ348tDXvSIjfXwETOd4KbXUmhGGelHc4p9GudoIi8472H zkiPWLvIabswggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w NjA5MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSkzI42+Djm I/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk0oWF0sNx 83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2dlwB23QU Jf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrMtWamwmt0 B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvfp1hQ2Th1 qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvhDXD7Y6qo bBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfB CpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQ qNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy 9uMzjF0JSxPfu4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAd BgNVHQ4EFgQUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAv BggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUH AgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcC AjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBM aWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJYIZIAYb4 QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0GCSqGSIb3 DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYopy2YCt7Ga 9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaaRRYWOApe V/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux8y5cZG5z MToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYS r/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7 YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7ed kPQiO674/CrK+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7 c0mjaleHlOXWeMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA5 2NAr9b/sdb+XAsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0 iByADfxyiuiDXjGCBOQwggTgAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMyBDbGllbnQgQ0ECEGDxBB8oVVZGnH+9S9P6zyowCQYFKw4DAhoF AKCCAi8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTI1MjIy ODAxWjAjBgkqhkiG9w0BCQQxFgQUEHyVGxeqL7r9ywmJm4QzXIA8PbYwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/ vUvT+s8qMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAh BgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/vUvT+s8qMA0GCSqG SIb3DQEBAQUABIICAB+uKHEzXL18/2ZMjlhO9nokiZf07NSoKL4bAlUERnCri+xjZY+qBzx/HiT1 Q4/1XiVDU09fLQ5OaWUXU6zYZJu16iTe7WyrlvFtzGUsWABfC2MjBe688HzXLePaKdpvQVLOwiFl NV7AM0aa2GuIVqWtOKyCyHVIs7h6j7/zVpzDP/lSnxceCWKjPYyURywktfzX43jxPl137rfhNc6p KaU4VF1iBw4bbXdzSVQ8i6+9T42Ewcy7+GlHtYqr2QdJAJpiJ8aO/1kQhbaepEK/lx9LLSzCHq4+ ccFmn+0A5yHjQYiRaUW/UL7uJvUdF34zAIHB0BtkXv/LaOivKYRjJHxb17AMojjoobDvoO1nRkK2 4f3ix/xMPfHeNoY7zLiXtzP99LRw3d2WePFvmFbCJcFu8jUYCgyIhD2uKXCB353AGByE90a8SRcC r5q5CStq6VsD52Gl+AjWoFDw0MKlXAXlC6GWgSMOmiD4vfRw0+bNU4L0AXt0tJFpqQAKKAakY3j+ 7Ks2UEv4Z4uIrtcaw8+BZ/e9AJKnglN8b/ACDzsw20Lu2KUf/JIsUGyK9u7edVDsDD25sy8oFNKf I/3zEWuwrIFAymDQVOSwp2B0Y0mYRZF94zhAhXgURD3f52e6apsAQUUApf6hMfun2YCn3qmchna5 WpCUZkZ50VLDjzUjAAAAAAAA ------=_NextPart_000_0136_01D2D5B6.EF17BC40-- From owner-freebsd-net@freebsd.org Thu May 25 23:46:53 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4AA4D81AFB for ; Thu, 25 May 2017 23:46:53 +0000 (UTC) (envelope-from alarig@swordarmor.fr) Received: from togepi.gozmail.bzh (togepi.gozmail.bzh [IPv6:2a00:5884:124::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E09C18D6 for ; Thu, 25 May 2017 23:46:53 +0000 (UTC) (envelope-from alarig@swordarmor.fr) Received: from mew.swordarmor.fr (mew.swordarmor.fr [IPv6:2a00:5884:102:1::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alarig@swordarmor.fr) by togepi.gozmail.bzh (Postfix) with ESMTPSA id CB4721A0075 for ; Fri, 26 May 2017 01:46:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swordarmor.fr; s=default; t=1495756008; bh=8RYgycEtgQ2fskTNykaEuR+Zqsf6BZoT7VnxY+xXDr8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RgOKNbeaVUmxkVyyz1RaCJSlPu2PAWTHB8OL02gAQznUDWebAkOzMWBm+lo3XH/QJ eaEjfF1P5sIPSyo8j8pGdkPpA4rqEXWd+m/HT3CfxiKZ9EyzwSR4LmgQxXJWqLGgzg bW6AoPp89tpBjIbG4vJRxaMcl8Ry8wzLEATiO17k= Date: Fri, 26 May 2017 01:46:38 +0200 From: Alarig Le Lay To: freebsd-net@freebsd.org Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" Message-ID: <20170525234638.ugtx7jw5ttm44tpm@mew.swordarmor.fr> References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ox3hjhje7gyx6mck" Content-Disposition: inline In-Reply-To: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 23:46:54 -0000 --ox3hjhje7gyx6mck Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On mer. 24 mai 12:17:50 2017, William Gathoye wrote: > In this use case, you make the assumption that my gateway is actually > the first one to respond, this is why you select only the first answer > using -c1. But as you can see below, if I remove that argument, several > routers are answering to me (seems sensible to me), how can I be sure my > gateway is actually the first device that answers? You can check the MAC address of the gateway of OVH and compare it with each fe80 address. --=20 alarig --ox3hjhje7gyx6mck Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+2yGwT0H0n57WkRbrzhKwWsgK4gFAlknbNcACgkQrzhKwWsg K4jmoQf8DJF0ykkMeKf1WNRpqBN1oVVmlkGNwbYgL3od7ywAxcly3mf8WP8KeXlX Yqxd8f3fcBuaiO6p8QLdJPvB118/F9ODQGD7k05AtiX2I8sjVnwqO/D8KgIT29gL yaEhl2qr2g+kPVO0NwyNovRW6FS3PVKu4WGFS9/te5yuXfhWwkSbQFchEq3RTPXJ lbEtDDAx98j+HjhFCFkzPnP7jyUQQiHw6wcqR3609Qf/GZMsyw57tNidRhKYRXqI qf6K/CSEIsUENPNBB6M/1ZZO8SzvXWyMU4gO8jrS5VuYmSYy7Zkr+0x2g58YA8cg pQ9I0ZOOC7ksVTYDoDd+vq7dNLEO/Q== =Z0TW -----END PGP SIGNATURE----- --ox3hjhje7gyx6mck-- From owner-freebsd-net@freebsd.org Fri May 26 05:23:10 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41584D7BBDA for ; Fri, 26 May 2017 05:23:10 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from mail.netcult.ch (mail.netcult.ch [46.140.84.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D39F713C2 for ; Fri, 26 May 2017 05:23:09 +0000 (UTC) (envelope-from office@thuinformatik.ch) Received: from thunb001 ([192.168.1.105]) (authenticated bits=0) by mail.netcult.ch (8.14.7/8.14.7) with ESMTP id v4Q5N4O1017996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 May 2017 07:23:05 +0200 From: "Tom Huerlimann" To: "'Hans Petter Selasky'" , References: <008701d2d585$f1977f90$d4c67eb0$@thuinformatik.ch> <2248eb55-c402-cdb9-2648-986a0ed9663a@selasky.org> <00f201d2d593$734c6160$59e52420$@thuinformatik.ch> <0b953cc0-f361-84fa-fc94-249a3029f51f@selasky.org> In-Reply-To: Subject: AW: AW: AW: axge0 and AX88179 Date: Fri, 26 May 2017 07:23:02 +0200 Message-ID: <01b101d2d5e0$25beaf50$713c0df0$@thuinformatik.ch> X-Mailer: Microsoft Outlook 15.0 MIME-Version: 1.0 Thread-Index: AQJdH3nE5dyHkJndVbel4ZEpsnb59wITsuhlAoViI88CPZzVcgFh8Vr3oK+738A= Content-Language: de-ch Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01AB_01D2D5F0.E883BA20" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 05:23:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AB_01D2D5F0.E883BA20 Content-Type: multipart/mixed; boundary="----=_NextPart_001_01AC_01D2D5F0.E883BA20" ------=_NextPart_001_01AC_01D2D5F0.E883BA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached netstat-s.log2.txt after the box was up during the night. From: Hans Petter Selasky [mailto:hps@selasky.org] Hello HPS > You can try to enable debugging: > sysctl hw.usb.axge.debug=255 # sysctl hw.usb.axge.debug=255 sysctl: unknown oid 'hw.usb.axge.debug': No such file or directory # sysctl hw.usb hw.usb.ucom.cons_baud: 9600 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_unit: -1 hw.usb.ucom.pps_mode: 0 hw.usb.uftdi.skip_jtag_interfaces: 1 hw.usb.urtw.preamble_mode: 2 hw.usb.uath.regdomain: 0 hw.usb.uath.countrycode: 0 hw.usb.full_ddesc: 0 hw.usb.no_cs_fail: 0 hw.usb.disable_port_power: 0 hw.usb.disable_enumeration: 0 hw.usb.power_timeout: 30 hw.usb.usb_lang_mask: 255 hw.usb.usb_lang_id: 9 hw.usb.template: 0 hw.usb.debug: 0 hw.usb.no_shutdown_wait: 0 hw.usb.no_suspend_wait: 0 hw.usb.no_boot_wait: 0 hw.usb.xhci.streams: 0 # sysctl hw.usb.debug=255 hw.usb.debug: 0 -> 255 # sysctl hw.usb.debug hw.usb.debug: 255 There is nothing printed to the console and I searched for the DEBUG logs in /var/logs/system.log. I also tried with value '1' because I found a website saying value 1 is to enable debug mode - just to exclude that. # sysctl hw.usb.debug=1 hw.usb.debug: 255 -> 1 # sysctl hw.usb.debug hw.usb.debug: 1 Same: Noting on console nor system.log. There is nothing logged or I don't know where to find the logs. Do you know where the logs are? > Or: > Try to log the USB traffic using "usbdump" > usbdump -i usbusX -f y -s 65536 > And look for errors like "ERR". # usbdump -i usbus0 -f 7 -s 65535 | grep -i ERR (...) 23:44:41.604114 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.604367 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.605907 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.606159 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.606651 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.606905 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.608688 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=1528,IVAL=0,ERR=0 23:44:41.608944 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=6104,IVAL=0,ERR=0 23:44:41.609196 usbus0.7 DONE-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=4576,IVAL=0,ERR=0 23:44:41.609448 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.609701 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=0,IVAL=0,ERR=0 23:44:41.609958 usbus0.7 DONE-BULK-EP=00000003,SPD=SUPER,NFR=2,SLEN=0,IVAL=0,ERR=0 # usbdump -i usbus0 -f 7 -s 65535 | grep -v ERR=0 (...) 23:48:07.877798 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882190 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882438 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882447 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882696 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882708 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 23:48:07.882952 usbus0.7 SUBM-BULK-EP=00000003,SPD=SUPER,NFR=1,SLEN=64,IVAL=0 23:48:07.882964 usbus0.7 SUBM-BULK-EP=00000082,SPD=SUPER,NFR=1,SLEN=0,IVAL=0 Result: ERR is always = 0 or ERR=0 is not present in the output. > Did you verify two such adapters back2back with iperf, for packetloss and other issues? On FreeBSD 10.3-RELEASE-p19 is one adapter and on my other box containing FreeBSD 10.1-RELEASE-p25 is another adapter. After I did some bandwith test with slow performance, I have those statistics (full output off netstat -s attached): # netstat -s | egrep -i 'loss|retran' 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 retransmit timeouts 0 retransmitted 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 TSN's marked for Fast Retran Is that the information you are asking for? Thank you for your time, I'm very interested in finding the root cause for this one. Have a good day Tom ------=_NextPart_001_01AC_01D2D5F0.E883BA20 Content-Type: text/plain; name="netstat-s.log2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netstat-s.log2.txt" # netstat -s tcp: 16091 packets sent 12835 data packets (9319487 bytes) 24 data packets (2560 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 2973 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 259 control packets 9994 packets received 7648 acks (for 9100000 bytes) 339 duplicate acks 0 acks for unsent data 2540 packets (205135 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 428 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 428 connections established (including accepts) 603 connections closed (including 171 drops) 167 connections updated cached RTT on close 169 connections updated cached RTT variance on close 2 connections updated cached ssthresh on close 0 embryonic connections dropped 5429 segments updated rtt (of 4153 attempts) 24 retransmit timeouts 2 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 1595 correct ACK header predictions 1399 correct data packet header predictions 434 syncache entries added 9 retransmitted 0 dupsyn 0 dropped 428 completed 0 bucket overflow 0 cache overflow 3 reset 3 stale 0 aborted 0 badack 0 unreach 0 zone failures 434 cookies sent 0 cookies received 3 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window 0 packets with valid tcp-md5 signature received 0 packets with invalid tcp-md5 signature received 0 packets with tcp-md5 signature mismatch 0 packets with unexpected tcp-md5 signature received 0 packets without expected tcp-md5 signature received udp: 25799 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 1 dropped due to no socket 8652 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 17146 delivered 92514 datagrams output 0 times multicast source filter matched sctp: 0 input packets 0 datagrams 0 packets that had data 0 input SACK chunks 0 input DATA chunks 0 duplicate DATA chunks 0 input HB chunks 0 HB-ACK chunks 0 input ECNE chunks 0 input AUTH chunks 0 chunks missing AUTH 0 invalid HMAC ids received 0 invalid secret ids received 0 auth failed 0 fast path receives all one chunk 0 fast path multi-part data 0 output packets 0 output SACKs 0 output DATA chunks 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 FR's that happened more than once to same chunk 0 output HB chunks 0 output ECNE chunks 0 output AUTH chunks 0 ip_output error counter Packet drop statistics: 0 from middle box 0 from end host 0 with data 0 non-data, non-endhost 0 non-endhost, bandwidth rep only 0 not enough for chunk header 0 not enough data to confirm 0 where process_chunk_drop said break 0 failed to find TSN 0 attempt reverse TSN lookup 0 e-host confirms zero-rwnd 0 midbox confirms no space 0 data did not match TSN 0 TSN's marked for Fast Retran Timeouts: 0 iterator timers fired 0 T3 data time outs 0 window probe (T3) timers fired 0 INIT timers fired 0 sack timers fired 0 shutdown timers fired 0 heartbeat timers fired 0 a cookie timeout fired 0 an endpoint changed its cookiesecret 0 PMTU timers fired 0 shutdown ack timers fired 0 shutdown guard timers fired 0 stream reset timers fired 0 early FR timers fired 0 an asconf timer fired 0 auto close timer fired 0 asoc free timers expired 0 inp free timers expired 0 packet shorter than header 0 checksum error 0 no endpoint for port 0 bad v-tag 0 bad SID 0 no memory 0 number of multiple FR in a RTT window 0 RFC813 allowed sending 0 RFC813 does not allow sending 0 times max burst prohibited sending 0 look ahead tells us no memory in interface 0 numbers of window probes sent 0 times an output error to clamp down on next user send 0 times sctp_senderrors were caused from a user 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 times a ECN reduced the cwnd 0 used express lookup via vtag 0 collision in express lookup 0 times the sender ran dry of user data on primary 0 same for above 0 sacks the slow way 0 window update only sacks sent 0 sends with sinfo_flags !=0 0 unordered sends 0 sends with EOF flag set 0 sends with ABORT flag set 0 times protocol drain called 0 times we did a protocol drain 0 times recv was called with peek 0 cached chunks used 0 cached stream oq's used 0 unread messages abandonded by close 0 send burst avoidance, already max burst inflight to net 0 send cwnd full avoidance, already max burst inflight to net 0 number of map array over-runs via fwd-tsn's ip: 3197651 total packets received 0 bad header checksums 0 with size smaller than minimum 348 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 1330585 packets for this host 0 packets for unknown/unsupported protocol 1547923 packets forwarded (0 packets fast forwarded) 1879 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 141674 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 64 output packets discarded due to no route 37992 output datagrams fragmented 75984 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 1870 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: echo reply: 5290 destination unreachable: 152 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 27603 destination unreachable: 74559 echo: 5290 5290 message responses generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent ipsec: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 8 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 487743 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures AH output histogram: hmac-sha2-256: 33977 hmac-sha2-512: 1053591 esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 250 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 593795 packets in 494023 packets out 0 packets dropped; invalid TDB 536789216 bytes in 137433389 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ESP output histogram: rijndael-cbc: 1087568 ipcomp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 packets sent uncompressed; size < compr. algo. threshold 0 packets sent uncompressed; compression was useless pim: 0 messages received 0 bytes received 0 messages received with too few bytes 0 messages received with bad checksum 0 messages received with bad version 0 data register messages received 0 data register bytes received 0 data register messages received on wrong iif 0 bad registers received 0 data register messages sent 0 data register bytes sent carp: 0 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error pfsync: 0 packets received (IPv4) 0 packets received (IPv6) 0 clear all requests received 0 state inserts received 0 state inserted acks received 0 state updates received 0 compressed state updates received 0 uncompressed state requests received 0 state deletes received 0 compressed state deletes received 0 fragment inserts received 0 fragment deletes received 0 bulk update marks received 0 TDB replay counter updates received 0 end of frame marks received 0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 0 stale states 0 failed state lookup/inserts 0 packets sent (IPv4) 0 packets sent (IPv6) 0 clear all requests sent 0 state inserts sent 0 state inserted acks sent 0 state updates sent 0 compressed state updates sent 0 uncompressed state requests sent 0 state deletes sent 0 compressed state deletes sent 0 fragment inserts sent 0 fragment deletes sent 0 bulk update marks sent 0 TDB replay counter updates sent 0 end of frame marks sent 0 failures due to mbuf memory error 0 send errors arp: 4642 ARP requests sent 4307 ARP replies sent 13643 ARP requests received 110 ARP replies received 13753 ARP packets received 5555 total packets dropped due to no ARP entry 823 ARP entrys timed out 0 Duplicate IPs seen ip6: 1 total packet received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 9 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 391 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: ICMP6: 1 Mbuf statistics: 0 one mbuf 1 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 1 failure of source address selection source addresses on a non-outgoing I/F 1 addresses scope=f Source addresses selection rule applied: 1 same address icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 3 MLDv2 listener report: 3 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes ipsec6: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 0 mbufs inserted during makespace rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output pfkey: 24264 requests sent from userland 1987040 bytes sent from userland histogram by message type: getspi: 73 add: 146 delete: 203 get: 402 register: 2 x_spdupdate: 272 x_spdadd: 28 x_spdget: 23138 0 messages with invalid length field 0 messages with invalid version field 0 messages with invalid message type field 0 messages too short 0 messages with memory allocation failure 0 messages with duplicate extension 0 messages with invalid extension type 0 messages with invalid sa type 0 messages with invalid address extension 24341 requests sent to userland 4470960 bytes sent to userland histogram by message type: getspi: 73 add: 146 delete: 239 get: 402 acquire: 5 register: 2 expire: 36 x_spdupdate: 272 x_spdadd: 28 x_spdget: 23138 23647 messages toward single socket 615 messages toward all sockets 156 messages toward registered sockets 0 messages with memory allocation failure ------=_NextPart_001_01AC_01D2D5F0.E883BA20-- ------=_NextPart_000_01AB_01D2D5F0.E883BA20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUizCCBeIw ggPKoAMCAQICEDZ5UlTLE1WeMCbSKy5LEOswDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAzIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANYjcOFzVjMVemifqK8VYRDvjxUxEc5soFBfad3Y1e7bZufzKb1/yTalMXW6iepa hiRBta9+i9nf09Rt0CEjNRlkUVTVjdQxUjNWGcvA/7bGqLFOB5Dtc6c66odhMfifEvrFRc6oXDE6 8Civo19smaFJoe7Pzk0DXy5l+f8+8LeSkK2sCeYTSKUecM1kt6v955hgWQWKehqW4XSs5iOJOqWz prW4TxnQLQTemoQEUMaIO2UBfoeXTCeclC9DgDvSl6TA0DqJiLBWA6BFBM4KCmlOOs1Wf3T3Qy3S 3tAuw2glk0VxDqbKC/3ZPMTrU9msz4Uhutgn1HNaOGPcD93A+K8CAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU NFpzxB+rcWNns0/Amy0gp53myR8wHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAtGvTe3y0uo6+hngSROfH4CzL3GmXfQDtt1evpt/fs7Fs VgCT1hOzuNWBQn9KXCQlzfkxm5MBCqGUWz33c+jdiTinIzn4BwyaEds/bGWABSCg3au7Qr5NAG6l 65RD+xRa+JyrCScvt1lCIlAmD0oI5CVCe0Yk0teWa2ZSRZGf+1S2eymzGKh6TaU0q2oYFPjwf7TZ sDcD0Rzklrd3HsjGZy1WUB3zw5eTg5HnNBQ107I7e98xnjhszIUp4ymYRoCr48SnqOibCbUpaVdt TlPs8txgpRD4iD37DAyOslb7TFcF+etOMPtD6Ym+3iifUpH8Am85SuUsU212B0t10vsGT7ZTD2zW dppbOkF7ncOUQYpQCsXCNO40U25UlbVPoWb0rB/cqfLTtsT3b2mCDt9PSjfjS5AgZRumaWrJPypm h1VTImuiVHFA7M/++VXnxP0YD+0YOzkD8v1PvRR9vc7D+F5EE8gtVyMO4NJgZitVOdYNSrFUYqrp /dFaRWuDvdh5FblJC6gkxeo4ultgujug+qr/Rgt7FNUahvNAXD8snMpIf5c+vSIAU2Xbq7OERtnJ eaV72T1s09LgPZPxKibtXoDOfCAh4r4tT/ZrW7Lexpt4lgF54PY71djGEqTPtcNjgIC/NIjqIAEE eT611lIB8PFT3q39ujp1YuSASRQErGEwggbUMIIFvKADAgECAhBg8QQfKFVWRpx/vUvT+s8qMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMyBDbGllbnQgQ0EwHhcNMTYwNzI5MTIwNjUwWhcNMTkwNzI5MTIwNjUwWjCBkjELMAkG A1UEBhMCQ0gxDzANBgNVBAgMBlp1cmljaDEQMA4GA1UEBwwHQsO8bGFjaDEbMBkGA1UECgwSdGh1 aW5mb3JtYXRpayBHbWJIMRswGQYDVQQDDBJ0aHVpbmZvcm1hdGlrIEdtYkgxJjAkBgkqhkiG9w0B CQEWF3Rob21hc0B0aHVpbmZvcm1hdGlrLmNoMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAt4gSFkzR0O+waPNy4YxbAyLCFmeINKBqMD7cfWegh9JN+W891DReNHC/t8Yhl3Auwhcnj0j6 m1UUEV40/ztEqp2P9+5V5JIMIjFOPO/JxHSwS43nPKmVdJ9TPwnTaEJuPQKNv27ID+cdkvEiWajj wo27BalC5589xpUgkoSQI/TMseEzf+KyzWedImItCZ+KOVYz2F9sQxW/0TRTt360fGe7u5p6n1RS 9+qi/2O4qdnJ6dJG35LqJW7YTEVeJRlqjEbazbghcYFJMdN0NUpGdsTYrMS0w99QTRL5XbajnNh4 /Hd3cdAnvkFRvqY57Htwh6tFLNvy14R4Wu3SDj/LMeJ75FbxsDbicNC/e0H5JJKMinR8Md7iuDNc ts9WATZ59vjolkW/xdKakrozW9d9uZfDrfA3ss6FRpYRdyVR3QnJoJZvdTJe0uGucDEgZBpSdyoO Zp6jR0GOdbahlEt4RxF22ROSM3A4fiHFC5Tws8Ka+9LZD+AajT7+DgQrsog5CpK766qd7G/94kNs eh/iIjp3jb5WpVhfna7zi24Oqs0IIw0Rbp7mFoV0vwdgY8vn6NR4jV8O4xJjnYP0VxT81h/ld3Wo RZPWeWBbmTPhYd9hnA94INmjIDJFwiDR6xinPkM/PgFfEb8HkLXXiCwra0MpiGTSI2pyYQDUdG/R NXkCAwEAAaOCAkAwggI8MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwCQYDVR0TBAIwADAdBgNVHQ4EFgQUFU37q+RDUVI+CeKvkUXOCavMRzMwHwYDVR0jBBgw FoAUNFpzxB+rcWNns0/Amy0gp53myR8wbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5zdGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3NjYS5jbGllbnQzLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9zY2EtY2xpZW50My5jcmwwgZgGA1UdEQSBkDCBjYEXdGhvbWFzQHRodWluZm9ybWF0 aWsuY2iBF29mZmljZUB0aHVpbmZvcm1hdGlrLmNogRtwb3N0bWFzdGVyQHRodWluZm9ybWF0aWsu Y2iBEnN1cHBvcnRAbmV0Y3VsdC5jaIERdGhvbWFzQG5ldGN1bHQuY2iBFXBvc3RtYXN0ZXJAbmV0 Y3VsdC5jaDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wVQYDVR0gBE4wTDAM BgorBgEEAYG1NwYBMDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBABxq8f6Lce/UBYTBVcuxQRfCF6p3 8Jp0EEQLQwIQ9Iw07VTynViuo4PTkmgyT0PhwfAbndhk6ecUz8+BC6Lr6iUiWkqCTVISNhHMk/Mf 9PzlLG1uxMKPBEYAh9qjT0GmoY6mNqji5SaJwb8SInC2JSfdLR/P4euXrKFQMWVRJ4e6NbyglBZJ WQNeDPdlxVAG6FwCWCiPdtm5gP8FaXsmcFBW/AT4j/RISvez+QDJPsLSQrqaQ1KNraFZyfVRPnod nih7xLC2ROQxeAF9/Xh1sqPitENtTmyZ348tDXvSIjfXwETOd4KbXUmhGGelHc4p9GudoIi8472H zkiPWLvIabswggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w NjA5MTcxOTQ2MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSkzI42+Djm I/BubbE83XKjhRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk0oWF0sNx 83ViNLosin8ej+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2dlwB23QU Jf7ttaCID914yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrMtWamwmt0 B+Qr4XY+tG3Y9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvfp1hQ2Th1 qVvqQwwC/5nr6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvhDXD7Y6qo bBpUtFwlesmiyYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfB CpDW+nkiSL+6e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQ qNn7GMa2tVxSPIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy 9uMzjF0JSxPfu4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAd BgNVHQ4EFgQUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20u b3JnL3Nmc2NhLWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAv BggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUH AgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcC AjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBM aWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJYIZIAYb4 QgENBCsWKVN0YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0GCSqGSIb3 DQEBBQUAA4ICAQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYopy2YCt7Ga 9yWYCTyOG+HdNocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaaRRYWOApe V/Zix3oCBea8HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux8y5cZG5z MToSuLyzEeR9j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYS r/clHjiJkHd+w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7 YS6+hKg4wJkShqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7ed kPQiO674/CrK+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7 c0mjaleHlOXWeMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA5 2NAr9b/sdb+XAsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0 iByADfxyiuiDXjGCBOQwggTgAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMyBDbGllbnQgQ0ECEGDxBB8oVVZGnH+9S9P6zyowCQYFKw4DAhoF AKCCAi8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTI2MDUy MzAxWjAjBgkqhkiG9w0BCQQxFgQUn5gsqm3pOIKZCq7r68ibL5FQeLcwgZMGCSqGSIb3DQEJDzGB hTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCG SAFlAwQCAjALBglghkgBZQMEAgEwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/ vUvT+s8qMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAh BgNVBAMTGlN0YXJ0Q29tIENsYXNzIDMgQ2xpZW50IENBAhBg8QQfKFVWRpx/vUvT+s8qMA0GCSqG SIb3DQEBAQUABIICAD3vk1SrJNZHjaUbj967fymxBnf9kx/KnYFlzHqS4EzKBZPDNJf5WKAZjpoZ HWqunxo2JVmjZLOpwNCZKwc14gLp1MBDY53iPimRgr+jLNLp24Tew7Djdpia4jZvzNi0iG1UQBJU d0TNgkuieCtpX26OYj5Tiw5SF2UZWMs2ShlcHsCxBbJQNMdH3pHrD1zxJyHyP2ZP+/qd6G0pHNub MbDeJJD74EnXV1GHgw71+4WA5m/8H+RQIjbNid98w7vbAqHbg4BZIjHOoxSPjmP6s6Xh1fu5o4MX fMLUNVCDMspckAFUsT2T4mIlHPWoakpUcq2XpO0yI0xJ6GZtZm0DprhXP4VcQcEIj/sr9xUHTdJ0 9sBu1uVb8MhGAFjqlCgTSSr4RUMLMTqbkLskN0F5J+Dnww8yNjEss/Km8TwzWa7Z1w4G+k8X5RHv 6UpwECbfs+/LgGNZJu+oN1b2zW0xsDbG0nqoojlfxQsxRWZN0XVfVXfPy1z6rBayCybBvC0eiJZg Y2zNklae+6wRJNRhebQSF6acVQVETpeHj5TwDSkZXoarXIkXMfqY7+DNuoibksfxV+ykveeoHR1h lS4C3PMDALe377A6lzRCamgdABk5L9414XPS7q/bVYELeA+e7xZ1UVQ2Ph8aL0e/GE2VT05hf1f5 4VNLmL+obfCg8PrOAAAAAAAA ------=_NextPart_000_01AB_01D2D5F0.E883BA20-- From owner-freebsd-net@freebsd.org Fri May 26 07:12:37 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91642D8269E for ; Fri, 26 May 2017 07:12:37 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C309170A for ; Fri, 26 May 2017 07:12:36 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4Q7CX36063330; Fri, 26 May 2017 09:12:33 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2DFFC2AA; Fri, 26 May 2017 09:12:33 +0200 (CEST) Message-ID: <5927D560.10003@omnilan.de> Date: Fri, 26 May 2017 09:12:32 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 26 May 2017 09:12:33 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:12:37 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 22:57 (localtime): > No, the thing is that I misinterpreted your stack trace. The patch is ok > for a different bug. It seems that the problem are vlans more than lagg. > Which interface did you put in netmap mode, em or em.345? Good morning, it was if_lagg itself, no vlan clone. The latter is a completely different problem, and contrary to the initial panic report, vlan clones don't lead to panics anymore. -harry From owner-freebsd-net@freebsd.org Fri May 26 07:14:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9227D8273C for ; Fri, 26 May 2017 07:14:38 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79A9017EA for ; Fri, 26 May 2017 07:14:38 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id h4so2998255oib.3 for ; Fri, 26 May 2017 00:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K8onUhLDHS+RGgUsOVaaVKhq9Z7u8SxjWiADG01d6vo=; b=uUuAt5Yaz+ocX6QS1xtCk0kdtc21YyaO6ee6+S6SUGMqfRa5SUujX9RYGcjdoODMAS Z3g1JOdbtP+kGi9fdWTuIWC/bbU7kHGU+REUOFpL+/FBgChXx2W7X7pg6NCxWl/wCNxY Qm9u8U2bIDdQFLnsaAAIUmpj16P6jYZqKBchbGXej/rXqe4qhnX4xQXf9l3bT2zNzV7l ixbFKUarkD8uG8Vc72RbngXJXVf5StRxFe86QJJBd9k/Quvcj9CnX9TbE6rjoiii7RJ9 YOKVSOKC6Aw2p7VPdRREpoN9UYqFpHIIDjqkMw0Q22ww3OWwptSl8IP7X6oFlGwbf1qm AQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K8onUhLDHS+RGgUsOVaaVKhq9Z7u8SxjWiADG01d6vo=; b=uHAwtgAx1h9WLLnB7/yhPoZ2pNRMvimNl7C5HrR4zfyCy8evB7k539USeLqXM/mYIl BXukuxlxwjzfcTooB9Bm1KwQDgIyf5nyMHoVBYTk11VAyU170ARQwmPnX9f6EmQ7ljIy QAo3LGC4WU6vjzusXKehChqB9oOMNXmkA8Zdk2u2Y+ayFpzbEBB6iGNH+iuhq88SSest E9dJcCQwVBpHfI/BhkTsXrVuC7U7ig7yG83fWaF3sF6N2fM6zvnj/EcRfg5As9EDz2Fb fk54oyHncjmv3EAHWKzI1yjFpOr5OqBGDn80i/SeOouTmdS9GjTIFXGbfSLPrK3YUuJu eE7w== X-Gm-Message-State: AODbwcCDROhbK2uEDapYYuWyU+Y03xPQgdjAXIPJpf1eibNpAsn0AftK KshNxE31VnTYLdMfdF4KgU4yMJzUHtst X-Received: by 10.202.236.67 with SMTP id k64mr236200oih.192.1495782877735; Fri, 26 May 2017 00:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Fri, 26 May 2017 00:14:37 -0700 (PDT) In-Reply-To: <5927D560.10003@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> From: Vincenzo Maffione Date: Fri, 26 May 2017 09:14:37 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:14:38 -0000 Hi, Your stack trace report this: #7 0xffffffff8069dc50 at vlan_input+0x1f0 which means VLANs are involved, in some way. Is that the correct trace? Cheers, VIncenzo 2017-05-26 9:12 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 25.05.2017 22:57 (localt= ime): > > No, the thing is that I misinterpreted your stack trace. The patch is o= k > > for a different bug. It seems that the problem are vlans more than lagg= . > > Which interface did you put in netmap mode, em or em.345? > > Good morning, > > it was if_lagg itself, no vlan clone. > The latter is a completely different problem, and contrary to the > initial panic report, vlan clones don't lead to panics anymore. > > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri May 26 07:21:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A15C8D82935 for ; Fri, 26 May 2017 07:21:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 345471ADA for ; Fri, 26 May 2017 07:21:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4Q7LVfU063401; Fri, 26 May 2017 09:21:31 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2A67E2B0; Fri, 26 May 2017 09:21:31 +0200 (CEST) Message-ID: <5927D77A.60502@omnilan.de> Date: Fri, 26 May 2017 09:21:30 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 26 May 2017 09:21:31 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:21:33 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:14 (localtime): > Hi, > Your stack trace report this: > > #7 0xffffffff8069dc50 at vlan_input+0x1f0 > > which means VLANs are involved, in some way. Is that the correct trace? The trace is from the pnaic after doing 'vale-ctl -a vale0:lagg0' (while lagg0 can have various names, but I'm not using a vlan clone). Might be that existing, but to my understanding uninvolved vlan clones interfere here... The lagg0 does have vlan clones (lots of) defined. Unfortunately I can't take them out of the game for testing... Does that picture match the trace? thanks, -harry From owner-freebsd-net@freebsd.org Fri May 26 07:31:21 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1DD6D82AA6 for ; Fri, 26 May 2017 07:31:21 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 905FB1E89 for ; Fri, 26 May 2017 07:31:21 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x243.google.com with SMTP id h4so524123oib.0 for ; Fri, 26 May 2017 00:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V+oubFIeTC6aJbDVif11oOvIramYWCZdUfOhhCAdpHQ=; b=IekkORuQyB6dls+ia2fWm5iz8qgGNJX0xSli4xj2f2NnUruQGcYINU4RZLolr/2sPi LdlsiVraglotBcXblTrhNTESq48Mc95e3M8ZrC6jAI4VKSIdlPwGtmKLRAy33XkQ35gJ JvAROV2WhuOwg/ece2He1Qyr74xa3c3a5z31eZWLN7T0a7V0O+IVVvUB/Cm7HxjELYWa nqXQFv3mARlug/QXJNET3vSDVJlM0AS2vYZvWVrUVajYH0yyiUWkVzrremgMXEclY0W2 crugsNdbzs9qsLX8Qn7z6KEAj0ENtSGXHMBAcRBDWnAx7J/tI2MQDXmKr0W0NvVjpFJx Ftng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V+oubFIeTC6aJbDVif11oOvIramYWCZdUfOhhCAdpHQ=; b=BDaIX68JMnblZt6j+vTYYNtKX9UeINAXTIUwG08fhHVN9edWwvdEz+enp1aJB49Y9B pCKMJETRhTpHJY8GMeGnGs4qE7IilyR+xLf3Y2CL5VswwI8HDdDzPRqZ1mdE9d7DjYyV VgTqBcC95pClivwLvt6ZorPdMI4aLwygNiHvE6YsTzOEgBd+/NGXGarPLGeFVqTxts90 zLIGoCwF0x9lu46MAqoWGm4LT0fJwo0aKgUax/KFUc3kOE/GelxI2rB93hzgymVBhXqL JzBj1Q2Nz4A5NevP9d6KOX7olIexZVhV234BH7fmpvQjBLs/usysac43sMZymgpBDqCZ Hziw== X-Gm-Message-State: AODbwcDSIW4DFH9qTserm5CIO/dnwRL7jSDrv57/aksFFb3HeCe08J/O Rf+f4vr4uLfFUDagTAGvSG5Qj3OYCg== X-Received: by 10.157.23.133 with SMTP id j5mr241776otj.37.1495783880889; Fri, 26 May 2017 00:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Fri, 26 May 2017 00:31:20 -0700 (PDT) In-Reply-To: <5927D77A.60502@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> From: Vincenzo Maffione Date: Fri, 26 May 2017 09:31:20 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:31:21 -0000 Is lagg0 the only interface attached to vale0? Is lagg0 aggregating a VLAN interface? You can try this trivial patch diff --git a/sys/dev/netmap/netmap_generic.c b/sys/dev/netmap/netmap_generic.c index f148b228..46a3c2c6 100644 --- a/sys/dev/netmap/netmap_generic.c +++ b/sys/dev/netmap/netmap_generic.c @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m) u_int work_done; u_int r =3D MBUF_RXQ(m); /* receive ring number */ + if (!NM_NA_VALID(ifp)) { + return 0; + } + if (r >=3D na->num_rx_rings) { r =3D r % na->num_rx_rings; } 2017-05-26 9:21 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:14 (localt= ime): > > Hi, > > Your stack trace report this: > > > > #7 0xffffffff8069dc50 at vlan_input+0x1f0 > > > > which means VLANs are involved, in some way. Is that the correct trace? > > The trace is from the pnaic after doing 'vale-ctl -a vale0:lagg0' (while > lagg0 can have various names, but I'm not using a vlan clone). > > Might be that existing, but to my understanding uninvolved vlan clones > interfere here... > The lagg0 does have vlan clones (lots of) defined. > Unfortunately I can't take them out of the game for testing... > > Does that picture match the trace? > > thanks, > > -harry > > > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri May 26 07:37:04 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97181D82D34 for ; Fri, 26 May 2017 07:37:04 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14B0D1214 for ; Fri, 26 May 2017 07:37:03 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4Q7b2GD063604; Fri, 26 May 2017 09:37:02 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id C9A9F2BC; Fri, 26 May 2017 09:37:01 +0200 (CEST) Message-ID: <5927DB1D.3020303@omnilan.de> Date: Fri, 26 May 2017 09:37:01 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 26 May 2017 09:37:02 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:37:04 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime): > Is lagg0 the only interface attached to vale0? Yes. > Is lagg0 aggregating a VLAN interface? No. > You can try this trivial patch > > diff --git a/sys/dev/netmap/netmap_generic.c > b/sys/dev/netmap/netmap_generic.c > index f148b228..46a3c2c6 100644 > --- a/sys/dev/netmap/netmap_generic.c > +++ b/sys/dev/netmap/netmap_generic.c > @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m) > u_int work_done; > u_int r = MBUF_RXQ(m); /* receive ring number */ > > + if (!NM_NA_VALID(ifp)) { > + return 0; > + } > + > if (r >= na->num_rx_rings) { > r = r % na->num_rx_rings; > } Thank you very much, I'll compile. I'd like to point to my other, directly if_vlan(4) related problem: https://lists.freebsd.org/pipermail/freebsd-net/2017-May/048000.html Having this explained/solved would split a big part of my too-much-variables-equation :-) Thanks, -harry From owner-freebsd-net@freebsd.org Fri May 26 08:38:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A153D82E2A for ; Fri, 26 May 2017 08:38:16 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A5E51EBD for ; Fri, 26 May 2017 08:38:15 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4Q8cDTp064354; Fri, 26 May 2017 10:38:13 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id F3D272CF; Fri, 26 May 2017 10:38:12 +0200 (CEST) Message-ID: <5927E974.6060706@omnilan.de> Date: Fri, 26 May 2017 10:38:12 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 26 May 2017 10:38:13 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 08:38:16 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime): > Is lagg0 the only interface attached to vale0? > Is lagg0 aggregating a VLAN interface? > > You can try this trivial patch > > diff --git a/sys/dev/netmap/netmap_generic.c > b/sys/dev/netmap/netmap_generic.c > index f148b228..46a3c2c6 100644 > --- a/sys/dev/netmap/netmap_generic.c > +++ b/sys/dev/netmap/netmap_generic.c > @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf *m) > u_int work_done; > u_int r = MBUF_RXQ(m); /* receive ring number */ > > + if (!NM_NA_VALID(ifp)) { > + return 0; > + } > + > if (r >= na->num_rx_rings) { > r = r % na->num_rx_rings; > } Unfortunately code base is too differing for me, since I absolutely don't know what I'm doing here. My resulting patch follows (combining this patch with the previous you provided and adding NM_NA_VALID()), but there are unmatching macros involved, which I have no idea about, so I'm not able to test this patch: --- src/sys/dev/netmap/netmap_freebsd.c.orig 2017-05-25 20:36:29.744382000 +0200 +++ src/sys/dev/netmap/netmap_freebsd.c 2017-05-25 20:35:53.858843000 +0200 @@ -259,9 +259,10 @@ void generic_find_num_queues(struct ifnet *ifp, u_int *txq, u_int *rxq) { - D("called, in txq %d rxq %d", *txq, *rxq); - *txq = netmap_generic_rings; - *rxq = netmap_generic_rings; + u_int num_rings = netmap_generic_rings ? netmap_generic_rings : 1; + + *txq = num_rings; + *rxq = num_rings; } --- src/sys/dev/netmap/netmap_kern.h.orig 2017-01-31 19:42:41.453502000 +0100 +++ src/sys/dev/netmap/netmap_kern.h 2017-05-26 10:08:17.128420000 +0200 @@ -1284,6 +1284,12 @@ #endif /* linux */ +#define NM_NA_VALID(ifp) (NA(ifp) && \ + ((uint32_t)(uintptr_t)NA(ifp) ^ NA(ifp)->magic) == NETMAP_MAGIC ) + + ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ + } while(0) + #ifdef __FreeBSD__ /* Assigns the device IOMMU domain to an allocator. --- src/sys/dev/netmap/netmap_generic.c.orig 2017-01-31 19:42:41.452980000 +0100 +++ src/sys/dev/netmap/netmap_generic.c 2017-05-26 09:55:21.265066000 +0200 @@ -625,6 +625,10 @@ u_int work_done; u_int rr = MBUF_RXQ(m); // receive ring number + if (!NM_NA_VALID(ifp)) { + return; + } + if (rr >= na->num_rx_rings) { rr = rr % na->num_rx_rings; // XXX expensive... } In file included from /usr/local/share/deploy-tools/RELENG_11/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_netmap.c:52: /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:20: note: expanded from macro 'NA' #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:27: error: a parameter list without types is only allowed in a function definition ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24: error: function cannot return function type 'int ()' ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:19: note: expanded from macro 'NA' #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24: error: expected ')' /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:44: note: expanded from macro 'NA' #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:90:25: note: expanded from macro 'WNA' #define WNA(_ifp) (_ifp)->if_netmap ^ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1290:24: note: to match this '(' /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_kern.h:1254:18: note: expanded from macro 'NA' #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) thanks, -harry From owner-freebsd-net@freebsd.org Fri May 26 08:42:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECD26D82F4E for ; Fri, 26 May 2017 08:42:00 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA8511370 for ; Fri, 26 May 2017 08:42:00 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id l18so5037046oig.2 for ; Fri, 26 May 2017 01:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tootsQg9r8pPVgySuj5J3RM9ZmllGAoEBa2M/jPybL8=; b=ZQ8l/6c0douPA7QpA88a9UDder21vfOU4nzYi+BdmsiKtvx/SuJHTlYFP0dpAxe0I7 +VoA/PJ29WO3J5o+YDmPnlq4MPY7LBFhWaMV7aKwsrkAOrfHZung5l2Ja6WRmK42Bhmm Urt4p7a7xDW+Epex+T+I9f+CCSrkQFkQesRUjsNOIS4oDstG1NNQTWBvaJZU/OE0Itod fMKHsZIuBuFe8UOYPzULeQm9lJEZ7pc7RqwIq1+1mmEbItzIPwjp1SiBROsJIqdG486x YqOy073l52dK4d+BSV/IOiEl6ATSibciH8M60uIGYk7zdtwF3oZNxSTwQX5FYmG3ko2f IiPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tootsQg9r8pPVgySuj5J3RM9ZmllGAoEBa2M/jPybL8=; b=STkYVTeVO41gGctqElkNPb683a7txgqR2i/Od9OabSOAJ82WexhFyiDP/M7lqx9/oB xcyVu7QgEidssGuQpC/PFTVrpM97QY1V+U9gNDl4byXJDCfbTkYsItjwayxR6lfz0G3U lXG1b986IpPvSUy/P4SP6KUYoNlMhfxBHO6mjHOHcS/1JnYmDzLWIjTWStg5Y3LZ46gA mY5mN4og2DOTiIJzmOl2pvEs9ZwBNst/pAowKt+NVF4CJkjUNN6sfvf5HViJbvzERKRz 2toZLJDm7dluMvAxJ7oy5aDDCon1GL2b9oHJ8sYNMzVG5jBsnOyLORsM+uSidjfp+EWi uYGA== X-Gm-Message-State: AODbwcDGrpAP+cAJRmXPYNNdn7xsMdzojFJaqTI0YM+Lua8Ik4pw/lfR pmAcdfIw7izOu66Q8OAHwa17BOAXBA== X-Received: by 10.202.236.67 with SMTP id k64mr371654oih.192.1495788119995; Fri, 26 May 2017 01:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Fri, 26 May 2017 01:41:59 -0700 (PDT) In-Reply-To: <5927E974.6060706@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> <5927E974.6060706@omnilan.de> From: Vincenzo Maffione Date: Fri, 26 May 2017 10:41:59 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 08:42:01 -0000 Ok, so you should try to completely replace the code in your /usr/src/sys with the code in the upstream netmap repository https://github.com/luigirizzo/netmap (sys directory). 2017-05-26 10:38 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localt= ime): > > Is lagg0 the only interface attached to vale0? > > Is lagg0 aggregating a VLAN interface? > > > > You can try this trivial patch > > > > diff --git a/sys/dev/netmap/netmap_generic.c > > b/sys/dev/netmap/netmap_generic.c > > index f148b228..46a3c2c6 100644 > > --- a/sys/dev/netmap/netmap_generic.c > > +++ b/sys/dev/netmap/netmap_generic.c > > @@ -950,6 +950,10 @@ generic_rx_handler(struct ifnet *ifp, struct mbuf > *m) > > u_int work_done; > > u_int r =3D MBUF_RXQ(m); /* receive ring number */ > > > > + if (!NM_NA_VALID(ifp)) { > > + return 0; > > + } > > + > > if (r >=3D na->num_rx_rings) { > > r =3D r % na->num_rx_rings; > > } > > Unfortunately code base is too differing for me, since I absolutely > don't know what I'm doing here. > My resulting patch follows (combining this patch with the previous you > provided and adding NM_NA_VALID()), but there are unmatching macros > involved, which I have no idea about, so I'm not able to test this patch: > --- src/sys/dev/netmap/netmap_freebsd.c.orig 2017-05-25 > 20:36:29.744382000 +0200 > +++ src/sys/dev/netmap/netmap_freebsd.c 2017-05-25 20:35:53.858843000 > +0200 > @@ -259,9 +259,10 @@ > void > generic_find_num_queues(struct ifnet *ifp, u_int *txq, u_int *rxq) > { > - D("called, in txq %d rxq %d", *txq, *rxq); > - *txq =3D netmap_generic_rings; > - *rxq =3D netmap_generic_rings; > + u_int num_rings =3D netmap_generic_rings ? netmap_generic_rings := 1; > + > + *txq =3D num_rings; > + *rxq =3D num_rings; > } > > > --- src/sys/dev/netmap/netmap_kern.h.orig 2017-01-31 > 19:42:41.453502000 +0100 > +++ src/sys/dev/netmap/netmap_kern.h 2017-05-26 10:08:17.128420000 > +0200 > @@ -1284,6 +1284,12 @@ > > #endif /* linux */ > > +#define NM_NA_VALID(ifp) (NA(ifp) && \ > + ((uint32_t)(uintptr_t)NA(ifp) ^ NA(ifp)->magic) =3D=3D NETMAP_MAG= IC ) > + > + ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ > + } while(0) > + > #ifdef __FreeBSD__ > > /* Assigns the device IOMMU domain to an allocator. > --- src/sys/dev/netmap/netmap_generic.c.orig 2017-01-31 > 19:42:41.452980000 +0100 > +++ src/sys/dev/netmap/netmap_generic.c 2017-05-26 09:55:21.265066000 > +0200 > @@ -625,6 +625,10 @@ > u_int work_done; > u_int rr =3D MBUF_RXQ(m); // receive ring number > > + if (!NM_NA_VALID(ifp)) { > + return; > + } > + > if (rr >=3D na->num_rx_rings) { > rr =3D rr % na->num_rx_rings; // XXX expensive... > } > > In file included from > /usr/local/share/deploy-tools/RELENG_11/src/sys/modules/ > cxgbe/if_cxgbe/../../../dev/cxgbe/t4_netmap.c:52: > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1290:24: > error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] > ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1254:20: > note: expanded from macro 'NA' > #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1290:27: > error: a parameter list without types is only allowed in a function > definition > ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1290:24: > error: function cannot return function type 'int ()' > ((uint32_t)(uintptr_t)NA(ifp)) ^ NETMAP_MAGIC; \ > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1254:19: > note: expanded from macro 'NA' > #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1290:24: > error: expected ')' > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1254:44: > note: expanded from macro 'NA' > #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:90:25: > note: expanded from macro 'WNA' > #define WNA(_ifp) (_ifp)->if_netmap > ^ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1290:24: > note: to match this '(' > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_kern.h:1254:18: > note: expanded from macro 'NA' > #define NA(_ifp) ((struct netmap_adapter *)WNA(_ifp)) > > thanks, > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri May 26 09:02:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D52DD82AB1 for ; Fri, 26 May 2017 09:02:00 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B18210DA for ; Fri, 26 May 2017 09:01:59 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4Q91wCh064723; Fri, 26 May 2017 11:01:58 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 0B4D42DD; Fri, 26 May 2017 11:01:57 +0200 (CEST) Message-ID: <5927EF05.9040208@omnilan.de> Date: Fri, 26 May 2017 11:01:57 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> <5927E974.6060706@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 26 May 2017 11:01:58 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:02:00 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 10:41 (localtime): > Ok, so you should try to completely replace the code in your > /usr/src/sys with the code in the upstream netmap > repository https://github.com/luigirizzo/netmap (sys directory). Sorry beeing so complicated; But is there a real chance this integrates and compiles well out of the box? My build machine (which is not the test machine) doesn't have internet access and additionally I'm not faimilar with git, so I'd have to find a solution getting the source first. And if I need to adapt/port anything to match stable/11, I won't be abel to do so (much too less knwoledge about all that code). I guess HEAD has already updated codebase. Maybe it's better to start with HEAD? But on the other hand, my test equipment is semi-productive with a quiet special setup (memory-rootfs with additional ZFS boot and sys-pool)... Very complicated I am... worth the stable/11 attempt? thanks, -harry From owner-freebsd-net@freebsd.org Fri May 26 09:06:10 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D98C6D82C7F for ; Fri, 26 May 2017 09:06:10 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 970C814A2 for ; Fri, 26 May 2017 09:06:10 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id l18so5614470oig.2 for ; Fri, 26 May 2017 02:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eCK2UgVlXDKtc1LLPWdVlCbKEgIoG4dh/uGMh9b+q5s=; b=g5s2Jd6c3lb8brE3kCM5B5bImYiAAe5a+Fr/SP6eD3yxE69CRNmwb62kfPUDieOTTt wWOxDQw28vDvpC8b6E6l2QIlUcWtQ3mY4etl0GQliBmdLOuFx/IKF9vl3YAPJZd8FZVV SniCRh9BePFatZudeoG+L9ctTyiuir85kX547m72A7LuEOv8gpYA7fN/TjZ98EK5BPbE K/tkWqlTVNkF3wP10TfUULJjefXc3EHYLM66W46d8Hf/zur2gcDxgidPidF31mdKntgx FURBHssFjmsQn32vgNAGvWdTGD2uIkNKez7UPA8fx4m22qEGi/3gAFjwI7ZKQSkt0xYS wzug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eCK2UgVlXDKtc1LLPWdVlCbKEgIoG4dh/uGMh9b+q5s=; b=Dn2sP1iLlYegy1aJ8krUiYncr2wdL1AfpgkkeGNbEeqOL0WSSkHEjNJ9/wxQq+0m+k 7GHWieJizFv5t+7fg2CrSOvED18TKpAwNh8JraUckDsVBIytUSZZlU2sPntInB7D8VBE 5tsIBg5IdU4MNuKoqG6yi0ADDeO069ewHbwUmkE32bmFhWqGLGfT2R6ldWSwIFh4F0VU H4LkrMLdTNzSEzpc9Qz63IqvLZz+jHAbcZh0IIvrbno/MnZTJR08Fl9A/QGGWlczNPZn KP6aSoK12f4R07D1yOj2ar1o5+OjbPOTY4CXTla9TrwVUPqq+szCQ+S33S44jcJ/3y1g 9neQ== X-Gm-Message-State: AODbwcCBeaBYvmvXQlX+4Gf0dcqfehEe+K+abtPr054fSVYjcVaC70wM XNP+n7DzP4xuGO8nQnbMA9h47nBUXw== X-Received: by 10.202.205.196 with SMTP id d187mr422723oig.6.1495789570012; Fri, 26 May 2017 02:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.59 with HTTP; Fri, 26 May 2017 02:06:09 -0700 (PDT) In-Reply-To: <5927EF05.9040208@omnilan.de> References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> <5927E974.6060706@omnilan.de> <5927EF05.9040208@omnilan.de> From: Vincenzo Maffione Date: Fri, 26 May 2017 11:06:09 +0200 Message-ID: Subject: Re: [panic] netmap(4) and if_lagg(4) To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:06:10 -0000 Yes, it should integrate and compile out of the box, I've done that several times with FreeBSD-11.0 and 10.3. And yes, HEAD contains recent code, you can also use that. Cheers, Vincenzo 2017-05-26 11:01 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 26.05.2017 10:41 (localt= ime): > > Ok, so you should try to completely replace the code in your > > /usr/src/sys with the code in the upstream netmap > > repository https://github.com/luigirizzo/netmap (sys directory). > > Sorry beeing so complicated; But is there a real chance this integrates > and compiles well out of the box? > My build machine (which is not the test machine) doesn't have internet > access and additionally I'm not faimilar with git, so I'd have to find a > solution getting the source first. And if I need to adapt/port anything > to match stable/11, I won't be abel to do so (much too less knwoledge > about all that code). > > I guess HEAD has already updated codebase. > Maybe it's better to start with HEAD? > But on the other hand, my test equipment is semi-productive with a quiet > special setup (memory-rootfs with additional ZFS boot and sys-pool)... > Very complicated I am... > > worth the stable/11 attempt? > > thanks, > > -harry > > > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Fri May 26 09:10:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43766D82E02 for ; Fri, 26 May 2017 09:10:59 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward2m.cmail.yandex.net (forward2m.cmail.yandex.net [IPv6:2a02:6b8:b030::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C154C167E for ; Fri, 26 May 2017 09:10:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [IPv6:2a02:6b8:0:2519::125]) by forward2m.cmail.yandex.net (Yandex) with ESMTP id 4EFA5216B3; Fri, 26 May 2017 12:10:47 +0300 (MSK) Received: from smtp3m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id AF3462840BDB; Fri, 26 May 2017 12:10:46 +0300 (MSK) Received: by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6ku0RBSXFF-AjPOlWWI; Fri, 26 May 2017 12:10:45 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1495789845; bh=f3kWwqBK9t7Ww1NsWtht4tl51Wd9w0vPJ9L3Zt9IXKY=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=jFynhFcCBZSstdWyyozTq4S2pWj7phPDwtqU4wf0OE1LQHBxF4at+eMGLhL1mNIsN yfNjnzlKCYaJ+TKTfQY0QTfWNgvffxABlj3rXir/NU+0O8jo3SobzkNPlgYb/WMCqp nMKjgt0hZi2bByBObx9vFWYZFiSZnrqWEjrqni9A= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6 To: Harry Schmalzbauer Cc: "freebsd-net@freebsd.org" References: <58CAD8CB.3060101@omnilan.de> <283742a4-5314-eef3-ed53-958a1f6e7492@yandex.ru> <58E641B8.5050108@omnilan.de> <59271B5C.7020306@omnilan.de> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <2e80ee51-8311-8d64-d290-0cdbe26dcd58@yandex.ru> Date: Fri, 26 May 2017 12:09:10 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <59271B5C.7020306@omnilan.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S2X06TciDo1Px14vCMbdbfi1SJtJgCHoj" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:10:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S2X06TciDo1Px14vCMbdbfi1SJtJgCHoj Content-Type: multipart/mixed; boundary="HmDQ92xp1uwraEQIIEoeEaUml2nnBen4T"; protected-headers="v1" From: "Andrey V. Elsukov" To: Harry Schmalzbauer Cc: "freebsd-net@freebsd.org" Message-ID: <2e80ee51-8311-8d64-d290-0cdbe26dcd58@yandex.ru> Subject: Re: Is "-vlanhwcsum" without effect? [Was: Re: if_igb(4) VLAN(4) and [RT]XCSUM_IPV6, TSO6 References: <58CAD8CB.3060101@omnilan.de> <283742a4-5314-eef3-ed53-958a1f6e7492@yandex.ru> <58E641B8.5050108@omnilan.de> <59271B5C.7020306@omnilan.de> In-Reply-To: <59271B5C.7020306@omnilan.de> --HmDQ92xp1uwraEQIIEoeEaUml2nnBen4T Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 25.05.2017 20:58, Harry Schmalzbauer wrote: > thank you for your fix, which made it into stable/11 in the meantime, > where I can confirm it does work. >=20 > But I noticed a possibly related oddity: > Setting "-vlanhwcsum" seems to have no effect, at least ifconfig(8) > reports always 'VLAN_HWCSUM'. > Haven't done any further tests, maybe your eye-brain-connection find th= e > answer quicker than any test I can do. I think it is driver specific bug. I tested with cxgbe(4), mlx5en(4), ixgbe(4), igb(4) and em(4) drivers, only cxgbe(4) sets/clears this flag correctly. --=20 WBR, Andrey V. Elsukov --HmDQ92xp1uwraEQIIEoeEaUml2nnBen4T-- --S2X06TciDo1Px14vCMbdbfi1SJtJgCHoj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlkn8LYACgkQAcXqBBDI oXqpgAf/f9HfZ3+CboK7N+KZA46jMsq9N+WPsF3cBFtE0gDoVZ5KdUKJGKheifcQ Hu7sTLRzInLqZN3XuByWrtlhmZAVzJcWbS8ufE2QYprWki3iwGslVeBvbSDnetBH zXgOhw/lvsUcBvPJEjnsvR3CqS0ReoHusUgBUKJkapx8DfpmNkoEGkvdwe8gM3Gz yC8m5e+QISzgQqeqiE+ZYHxt0qD1mykN836wfHD4HQOTI7ap978R0L50wEE/fM7Q nC+7H/1I1yfO4YCOQNmLEYxDQqsh7aWbk+pjRy+7npkRoYqWE4WBY9rmd4L1qim7 tCrmU3tUlW90/nKLrNDd7jd+GyDyqg== =XNyf -----END PGP SIGNATURE----- --S2X06TciDo1Px14vCMbdbfi1SJtJgCHoj-- From owner-freebsd-net@freebsd.org Fri May 26 09:29:15 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAD9AD7B49A for ; Fri, 26 May 2017 09:29:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CA02102E; Fri, 26 May 2017 09:29:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA06268; Fri, 26 May 2017 12:29:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1dEBYQ-000IAN-Fz; Fri, 26 May 2017 12:29:06 +0300 From: Andriy Gapon Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 To: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Baptiste Daroussin , Toomas Soome References: <201703090601.v2961OJx077853@repo.freebsd.org> Cc: freebsd-net@FreeBSD.org Message-ID: Date: Fri, 26 May 2017 12:27:45 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <201703090601.v2961OJx077853@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 09:29:16 -0000 On 09/03/2017 08:01, Mariusz Zaborski wrote: > Author: oshogbo > Date: Thu Mar 9 06:01:24 2017 > New Revision: 314948 > URL: https://svnweb.freebsd.org/changeset/base/314948 > > Log: > Try to extract the RFC1048 data from PXE. If we get enough info we can skip > the bootp(). It removes unnecessary DHCP request from pxeloader. > > Submitted by: kczekirda > Sponsored by: Oktawave > Initiated by: Matthew Dillon > Reviewed by: smh, gnn, bapt, oshogbo > MFC after: 3 weeks > Differential Revision: https://reviews.freebsd.org/D9847 Sorry for being late to the party, but this being head hopefully not too late. I am not sure that I agree with the spirit of this change. There are network boot setups that do depend on the "unnecessary" DHCP request from pxeboot. For example, a DHCP server could be configured to return a different set of parameters depending on a particular PXE client. I personally use a configuration where the DCHP server sends a boot menu[*] to a PXE client that's built into network cards. If a FreeBSD boot is selected and pxeboot is started, then the server sends parameters required for the FreeBSD boot (root-path, etc) in response to the request from pxeboot. I don't see how I can keep that working after this change. Additionally, as far as I can tell, we only get cached PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments where a separate PXE server (Proxy DHCP) is used. In that case the reply might not have the network configuration information which would actually be in PXENV_PACKET_TYPE_DHCP_ACK. An example of such a setup is described here: https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mode/ Using a separate PXE server is not uncommon in corporate environments too. In general, I think that the change was not thought through to cover scenarios beyond the basic unattended, FreeBSD-only, single DHCP server network boots. That scenario is, of course, very common, but it is not the only one. At minimum, I would like to have a compile time option to control whether pxeboot should send a DHCP request of its own or rely entirely on the cached information. Or maybe pxeboot could be smart enough to do the former if the cached reply is missing some required information like the root-path. Right now, there is no bootp(BOOTP_PXE) under any conditions. And my apologies again for missing the original discussion. My focus was somewhere else at the time. [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. References: http://www.pix.net/software/pxeboot/archive/pxespec.pdf -- Andriy Gapon From owner-freebsd-net@freebsd.org Fri May 26 12:22:20 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C924D7B497 for ; Fri, 26 May 2017 12:22:20 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F34A61118 for ; Fri, 26 May 2017 12:22:19 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4QCMHmO067031; Fri, 26 May 2017 14:22:17 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id EC3C4340; Fri, 26 May 2017 14:22:16 +0200 (CEST) Message-ID: <59281DF8.20402@omnilan.de> Date: Fri, 26 May 2017 14:22:16 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> <5927E974.6060706@omnilan.de> <5927EF05.9040208@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 26 May 2017 14:22:17 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 12:22:20 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 11:06 (localtime): > Yes, it should integrate and compile out of the box, I've done that > several times with FreeBSD-11.0 and 10.3. Impressive, it needed just a small addition to sys/conf/files to make the linker happy :-) I also recomplied vale-ctl, but I get the following error when trying to add em0 (lagg-unrelated): 389.083433 [ 835] netmap_obj_malloc netmap_ring request size 65792 too large 389.091593 [1693] netmap_mem2_rings_create Cannot allocate RX_ring Adding lagg still results in a panci, but with your latest "return()"-patch, it's different: 0xffffffff8042aefb is in freebsd_generic_rx_handler (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:276). 271 struct netmap_generic_adapter *gna = 272 (struct netmap_generic_adapter *)NA(ifp); 273 int stolen = generic_rx_handler(ifp, m); 274 275 if (!stolen) { 276 gna->save_if_input(ifp, m); 277 } 278 } 279 280 /* KDB: stack backtrace: #0 0xffffffff805e4a17 at kdb_backtrace+0x67 #1 0xffffffff805a34b6 at vpanic+0x186 #2 0xffffffff805a3323 at panic+0x43 #3 0xffffffff808a49b2 at trap_fatal+0x322 #4 0xffffffff808a4a09 at trap_pfault+0x49 #5 0xffffffff808a4246 at trap+0x286 #6 0xffffffff8088a521 at calltrap+0x8 #7 0xffffffff806aa3e0 at vlan_input+0x1f0 #8 0xffffffff8069b298 at ether_demux+0x128 #9 0xffffffff8069bf3b at ether_nh_input+0x31b #10 0xffffffff806b7c00 at netisr_dispatch_src+0xa0 #11 0xffffffff8069b546 at ether_input+0x26 #12 0xffffffff803a0278 at igb_rxeof+0x738 #13 0xffffffff8039f63f at igb_msix_que+0x10f #14 0xffffffff8056ae1c at intr_event_execute_handlers+0xec #15 0xffffffff8056b106 at ithread_loop+0xd6 #16 0xffffffff80568475 at fork_exit+0x85 #17 0xffffffff8088aa5e at fork_trampoline+0xe Any hints how I can get adding em0 (lagg and vlan-less) via vale-ctl again? (netmap_obj_malloc netmap_ring request size 65792 too large) Thanks, -harry From owner-freebsd-net@freebsd.org Fri May 26 18:26:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 405C1D83246 for ; Fri, 26 May 2017 18:26:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 168A31D20; Fri, 26 May 2017 18:26:59 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQK00300LLJI700@st13p35im-asmtp002.me.com>; Fri, 26 May 2017 17:26:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1495819609; bh=Uo8VYNpPnGzO7Lu2HttvBGMkOQSUaXrhMYXFTYZO0Vc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=bYUs4LgOXARHRBN8vkhJmZsiOd4vcC2mpyWIWgM9QnbDdOIgLQjw8D2CwPL7EvD5p XJ6Kap+u7fyl/mwJQQYNmaGPb2b50rpxZ6QlVDhf9Hun6qLgc8c6MfV35L34L07cEw oVVfyCLqz4/ZhdQHv0SaLeIRupDYyhKyT/4ESf9h/UKKgWPUg5idn47LFBYRU4BzSy /hoiyn+lsL3TXQ6FzV4XJVNZawf6XimGLN9GabFIWn9nWu/XWH0nE8E2UP8M35Ziu7 5p+O+b5/4giSQO6Dsw7iQxgh6bfFv9GL7T+Q25sUY1KK5v7cHvn/8uxEdTeZl+7weO NoH1zYFj4GS+Q== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQK00C6LLSLP610@st13p35im-asmtp002.me.com>; Fri, 26 May 2017 17:26:49 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-26_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705260310 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 From: Toomas Soome In-reply-to: Date: Fri, 26 May 2017 20:26:45 +0300 Cc: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Baptiste Daroussin , Toomas Soome , freebsd-net@FreeBSD.org Content-transfer-encoding: quoted-printable Message-id: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> References: <201703090601.v2961OJx077853@repo.freebsd.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 18:26:59 -0000 > On 26. mai 2017, at 12:27, Andriy Gapon wrote: >=20 > On 09/03/2017 08:01, Mariusz Zaborski wrote: >> Author: oshogbo >> Date: Thu Mar 9 06:01:24 2017 >> New Revision: 314948 >> URL: https://svnweb.freebsd.org/changeset/base/314948 >>=20 >> Log: >> Try to extract the RFC1048 data from PXE. If we get enough info we = can skip >> the bootp(). It removes unnecessary DHCP request from pxeloader. >>=20 >> Submitted by: kczekirda >> Sponsored by: Oktawave >> Initiated by: Matthew Dillon >> Reviewed by: smh, gnn, bapt, oshogbo >> MFC after: 3 weeks >> Differential Revision: https://reviews.freebsd.org/D9847 >=20 > Sorry for being late to the party, but this being head hopefully not = too late. >=20 > I am not sure that I agree with the spirit of this change. >=20 > There are network boot setups that do depend on the "unnecessary" DHCP = request > from pxeboot. For example, a DHCP server could be configured to = return a > different set of parameters depending on a particular PXE client. I = personally > use a configuration where the DCHP server sends a boot menu[*] to a = PXE client > that's built into network cards. If a FreeBSD boot is selected and = pxeboot is > started, then the server sends parameters required for the FreeBSD = boot > (root-path, etc) in response to the request from pxeboot. > I don't see how I can keep that working after this change. >=20 > Additionally, as far as I can tell, we only get cached > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in = environments where > a separate PXE server (Proxy DHCP) is used. In that case the reply = might not > have the network configuration information which would actually be in > PXENV_PACKET_TYPE_DHCP_ACK. > An example of such a setup is described here: > = https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mod= e/ > Using a separate PXE server is not uncommon in corporate environments = too. >=20 > In general, I think that the change was not thought through to cover = scenarios > beyond the basic unattended, FreeBSD-only, single DHCP server network = boots. > That scenario is, of course, very common, but it is not the only one. >=20 > At minimum, I would like to have a compile time option to control = whether > pxeboot should send a DHCP request of its own or rely entirely on the = cached > information. Or maybe pxeboot could be smart enough to do the former = if the > cached reply is missing some required information like the root-path. > Right now, there is no bootp(BOOTP_PXE) under any conditions. >=20 > And my apologies again for missing the original discussion. > My focus was somewhere else at the time. >=20 > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. >=20 > References: > http://www.pix.net/software/pxeboot/archive/pxespec.pdf > --=20 > Andriy Gapon Yep, there was some discussion added after the commit, and IMO the only = real conclusion was that this whole topic needs some more thinking. Also = I do not think the holy grail should be reusing the initial ACK - it may = be providing enough information for simple setups, but is most certainly = not enough for more complex ones as you just did describe. Also, it did = became quite clear that there are some different views on the issue, so = IMO we need to take some time to collect the ideas and then figure what = is the best way there. rgds, toomas From owner-freebsd-net@freebsd.org Fri May 26 21:09:10 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D53DD8302A for ; Fri, 26 May 2017 21:09:10 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A9021697; Fri, 26 May 2017 21:09:10 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 54D19218C; Fri, 26 May 2017 21:09:09 +0000 (UTC) Date: Fri, 26 May 2017 23:09:09 +0200 From: Baptiste Daroussin To: Andriy Gapon Cc: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Toomas Soome , freebsd-net@FreeBSD.org, kczekirda@FreeBSD.org Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170526210908.ykqalqbetxp4f27p@ivaldir.net> References: <201703090601.v2961OJx077853@repo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mb35fwzxs6poyq4t" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 21:09:10 -0000 --mb35fwzxs6poyq4t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 12:27:45PM +0300, Andriy Gapon wrote: > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > Author: oshogbo > > Date: Thu Mar 9 06:01:24 2017 > > New Revision: 314948 > > URL: https://svnweb.freebsd.org/changeset/base/314948 > >=20 > > Log: > > Try to extract the RFC1048 data from PXE. If we get enough info we ca= n skip > > the bootp(). It removes unnecessary DHCP request from pxeloader. > > =20 > > Submitted by: kczekirda > > Sponsored by: Oktawave > > Initiated by: Matthew Dillon > > Reviewed by: smh, gnn, bapt, oshogbo > > MFC after: 3 weeks > > Differential Revision: https://reviews.freebsd.org/D9847 >=20 > Sorry for being late to the party, but this being head hopefully not too = late. >=20 > I am not sure that I agree with the spirit of this change. I just figured out it also breaks chainloading with ipxe (like qemu does) a= nd it does not request the rootpath if not passed to the ipxe first. I'm now really thinking the our loader deserves its own DHCP value. We should also give it some tags so people can provide it the information t= hey want depending on the tags (like hey this is the fbsd loader give it that rootpath). >=20 > There are network boot setups that do depend on the "unnecessary" DHCP re= quest > from pxeboot. For example, a DHCP server could be configured to return a > different set of parameters depending on a particular PXE client. I pers= onally > use a configuration where the DCHP server sends a boot menu[*] to a PXE c= lient > that's built into network cards. If a FreeBSD boot is selected and pxebo= ot is > started, then the server sends parameters required for the FreeBSD boot > (root-path, etc) in response to the request from pxeboot. > I don't see how I can keep that working after this change. >=20 > Additionally, as far as I can tell, we only get cached > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments= where > a separate PXE server (Proxy DHCP) is used. In that case the reply might= not > have the network configuration information which would actually be in > PXENV_PACKET_TYPE_DHCP_ACK. > An example of such a setup is described here: > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mo= de/ > Using a separate PXE server is not uncommon in corporate environments too. >=20 > In general, I think that the change was not thought through to cover scen= arios > beyond the basic unattended, FreeBSD-only, single DHCP server network boo= ts. > That scenario is, of course, very common, but it is not the only one. >=20 > At minimum, I would like to have a compile time option to control whether > pxeboot should send a DHCP request of its own or rely entirely on the cac= hed > information. Or maybe pxeboot could be smart enough to do the former if = the > cached reply is missing some required information like the root-path. > Right now, there is no bootp(BOOTP_PXE) under any conditions. >=20 > And my apologies again for missing the original discussion. > My focus was somewhere else at the time. >=20 > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. >=20 --mb35fwzxs6poyq4t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkomWcACgkQY4mL3PG3 Plp1URAAjTMDuyo/Hiy5a/+bMMw808gM3RFVskFM6C4e+5f9Aji+2dUSHVLtIBSL SXeUN95FuQOMk920h9wzPOJg7sLM4fuoT2L2F8rwjeopd04y/S6FkZCE0ohjFBSP +ZwcCI3vaq+Ue40BbdVfZCr/+Ygs+7Kj9YLu2CAOlH2LvBchYeXxqzmxCcrNudE0 vJr5Gcp6wo2lN85SxkwV//bkGkiUAAnUO6hHpRX35yWxMgWuyBaiVSlP7BzfGMkr QtEl7j2coIgwwAW5dOTG0FQG+TDnyB3CFC/47NTPg0zRk+xp+Pj2xXP3H9RA+Lyp PeMGizc/vJ5gaPw/NsOKj0za91JXDS6Ki5QNiaIFciUj1IlGn2PlhjgXtgD2mYTV bw2UdFF0NWPWLT9ku66XfT6xQdWMF4GXsoeut+6WyjzebB0DJwRNujL5u6Ngs6uj itMMfatCqudZQHrLZMpZzpjq+/8o6QOafF64gWhB7VCXTLYIq2YgaGW2vX2R2zWW d4wKyx4YaaESjF4zriFhQ1QnZyZYj11EoDNyNRqQwqudoTd9Tv2EUpOdvlb/yljD XH5sERr6KwG83KIuQNqMAEj5z9Q+VxyfWEy1wKoAEVw4wJ/I5rM6jbNvYD9h08uI A5So7Mwcs9aVRvnDJWtDSRh1DBP36H5tRweuyAp5cDHMhFlZIEw= =VvHH -----END PGP SIGNATURE----- --mb35fwzxs6poyq4t-- From owner-freebsd-net@freebsd.org Sat May 27 01:15:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0A93D8359F for ; Sat, 27 May 2017 01:15:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0B371E51 for ; Sat, 27 May 2017 01:15:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4R1FjjK064368 for ; Sat, 27 May 2017 01:15:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219428] em network driver broken in current Date: Sat, 27 May 2017 01:15:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: andy@neu.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 01:15:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219428 --- Comment #2 from andy@neu.net --- No need to look thru ML threads, I just mentioned that so there was more reports than just mine. Not much to report, install CURRENT on a physical machine with an Intel gigabit nic. DHCP and static address assignment both fail to configure the interface and successfully ping another machine. Not sure what I can add. Did you try to install on a physical machine? I have= no way else to tell you how to reproduce the problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat May 27 03:29:37 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 797CCD8417D for ; Sat, 27 May 2017 03:29:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CDAE1E7C; Sat, 27 May 2017 03:29:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v4R3TWYj011341; Fri, 26 May 2017 20:29:32 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v4R3TUP1011340; Fri, 26 May 2017 20:29:30 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 In-Reply-To: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> To: Toomas Soome Date: Fri, 26 May 2017 20:29:30 -0700 (PDT) CC: Andriy Gapon , Baptiste Daroussin , Mariusz Zaborski , freebsd-net@freebsd.org, "George V. Neville-Neil" , Toomas Soome , Steven Hartland X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 03:29:37 -0000 > > On 26. mai 2017, at 12:27, Andriy Gapon wrote: > > > > On 09/03/2017 08:01, Mariusz Zaborski wrote: > >> Author: oshogbo > >> Date: Thu Mar 9 06:01:24 2017 > >> New Revision: 314948 > >> URL: https://svnweb.freebsd.org/changeset/base/314948 > >> > >> Log: > >> Try to extract the RFC1048 data from PXE. If we get enough info we can skip > >> the bootp(). It removes unnecessary DHCP request from pxeloader. > >> > >> Submitted by: kczekirda > >> Sponsored by: Oktawave > >> Initiated by: Matthew Dillon > >> Reviewed by: smh, gnn, bapt, oshogbo > >> MFC after: 3 weeks > >> Differential Revision: https://reviews.freebsd.org/D9847 > > > > Sorry for being late to the party, but this being head hopefully not too late. > > > > I am not sure that I agree with the spirit of this change. > > > > There are network boot setups that do depend on the "unnecessary" DHCP request > > from pxeboot. For example, a DHCP server could be configured to return a > > different set of parameters depending on a particular PXE client. I personally > > use a configuration where the DCHP server sends a boot menu[*] to a PXE client > > that's built into network cards. If a FreeBSD boot is selected and pxeboot is > > started, then the server sends parameters required for the FreeBSD boot > > (root-path, etc) in response to the request from pxeboot. > > I don't see how I can keep that working after this change. > > > > Additionally, as far as I can tell, we only get cached > > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments where > > a separate PXE server (Proxy DHCP) is used. In that case the reply might not > > have the network configuration information which would actually be in > > PXENV_PACKET_TYPE_DHCP_ACK. > > An example of such a setup is described here: > > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mode/ > > Using a separate PXE server is not uncommon in corporate environments too. > > > > In general, I think that the change was not thought through to cover scenarios > > beyond the basic unattended, FreeBSD-only, single DHCP server network boots. > > That scenario is, of course, very common, but it is not the only one. > > > > At minimum, I would like to have a compile time option to control whether > > pxeboot should send a DHCP request of its own or rely entirely on the cached > > information. Or maybe pxeboot could be smart enough to do the former if the > > cached reply is missing some required information like the root-path. > > Right now, there is no bootp(BOOTP_PXE) under any conditions. > > > > And my apologies again for missing the original discussion. > > My focus was somewhere else at the time. > > > > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. > > > > References: > > http://www.pix.net/software/pxeboot/archive/pxespec.pdf > > -- > > Andriy Gapon > > > Yep, there was some discussion added after the commit, and IMO the only real conclusion was that this whole topic needs some more thinking. Also I do not think the holy grail should be reusing the initial ACK - it may be providing enough information for simple setups, but is most certainly not enough for more complex ones as you just did describe. Also, it did became quite clear that there are some different views on the issue, so IMO we need to take some time to collect the ideas and then figure what is the best way there. > It is starting to become very clear that we do infact need to do a full on DHCP request, hopefully with a unique client string to indicate to the dhcp server that this is the freebsd loader making the request. This would lead to a great deal of flexiability for those of use using complicated PXE boot menus and infustructure supporting much more than just FreeBSD as a client. The fact that FreeBSD does not do this has made it more difficult to deal with than it should be when adding it to a network boot infustructure. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Sat May 27 07:27:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 081B2D84C90 for ; Sat, 27 May 2017 07:27:14 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dnvrco-oedge-vip.email.rr.com", Issuer "dnvrco-oedge-vip.email.rr.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCEEB1AD0 for ; Sat, 27 May 2017 07:27:13 +0000 (UTC) (envelope-from mueller6722@twc.com) Received: from [74.134.208.22] ([74.134.208.22:28587] helo=localhost) by dnvrco-omsmta03 (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id B8/24-01815-94A29295; Sat, 27 May 2017 07:27:06 +0000 Date: Sat, 27 May 2017 07:26:57 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-net@freebsd.org CC: Yuri Subject: Re: Bug in make setting wrong MAKESYSPATH References: <97050ce3-ad75-c3dc-c106-3bd608e7aa8e@rawbw.com> X-RR-Connecting-IP: 107.14.64.88:25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 07:27:14 -0000 > I came across the WiFi router through which dhclient fails to obtain the IP > address. It sets 0.0.0.0 and it stays this way, > On the other hand, dhcpcd obtains the IP address almost instantly. > Other routers mostly don't have such problem. > Is dhclient not as robust, or outdated as compared to dhcpcd? > Yuri NetBSD has both dhclient and dhcpcd. NetBSD developers say they intend to remove dhclient in the future. On NetBSD, sometimes dhclient works where dhcpcd doesn't, or vice versa. In FreeBSD, I see dhclient, but not dhcpcd, is in the base system, while there is a net/dhcpcd port. NetBSD-current is on dhcpcd 7.0, ahead of FreeBSD ports version. Comparison of file sizes from NetBSD 7.99.71 (current) i386: -r-xr-xr-x 1 root wheel 5343688 May 16 14:42 /media/zip0/sbin/dhclient -r-xr-xr-x 1 root wheel 6221 May 16 14:42 /media/zip0/sbin/dhclient-script -r-xr-xr-x 1 root wheel 299176 May 16 14:41 /media/zip0/sbin/dhcpcd Now I have an incentive to try for myself on other computer (MSI Z77 MPOWER motherboard with re (Realtek 8111E/8168 Ethernet chip)). "dhclient re0" fails to connect, though I can connect by Hiro H50191 USB wireless adapter using rsu driver. I won't be able to try immediately, because I believe I need to rebuild the system (11.0-STABLE amd64) first, then HEAD on another partition. Tom From owner-freebsd-net@freebsd.org Sat May 27 07:34:25 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF6FDD84EED for ; Sat, 27 May 2017 07:34:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEF2E1EDA for ; Sat, 27 May 2017 07:34:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v4R7YPMh061948 for ; Sat, 27 May 2017 07:34:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219428] em network driver broken in current Date: Sat, 27 May 2017 07:34:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohartmann@walstatt.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 07:34:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219428 O. Hartmann changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ohartmann@walstatt.org --- Comment #3 from O. Hartmann --- This is what I've send to the mailing list recently and I simply copy-and-paste'd it here for convenience to document the problem, which is still present and serious. The problem has gone worse and reliefed since the introduction of IFLIB, to say: recent CURRENT recovers itself now after bei= ng "dead" for more than a minute (but loosing then connections due to timeouts, i.e. ssh) and in now more frequently occuring cases getting worse in terms = of loosing the device: there was no known to me method to revive the NIC but rebooting - which is desastrous in some situations. [...] Since the introduction of IFLIB, I have big trouble with especially a certa= in type of NIC, namely formerly known igb and em. The worst device is an Intel NIC known as i217-LM em0@pci0:0:25:0: class=3D0x020000 card=3D0x11ed1734 chip=3D0x153a808= 6 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ethernet Connection I217-LM' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xfb300000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0xfb339000, size 4096, enabl= ed bar [18] =3D type I/O Port, range 32, base 0xf020, size 32, enabled This NIC is widely used by Fujitsu's workstations CELSIUS M740 and the fate would have it, that I have to use one of these. When syncing data over the network from the workstation to an older C2D/bce based server via NFSv4, since introduction of IFLIB the connection to the N= FS get stuck and I receive on the console messages like em0: TX(0) desc avail =3D 1024, pidx =3D 0 em0: TX(0) desc avail =3D 42, pidx =3D 985 Hitting "Ctrl-T" on the terminal doing the sync via "rsync", I see then this message: load: 0.01 cmd: rsync 68868 [nfsaio] 395.68r 4.68u 4.64s 0% 3288k (just for the record) Server and client(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285:= Mon May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (j= ust for the record if that matters). In the past, I was able to revive the connection by simply putting the NIC = down and then up again and while I had running a ping as a trace indication of t= he state of the NIC, I got very often ping: sendto: No buffer space available Well, today I checked via dmesg the output to gather again those messages a= nd realised that the dmesg is garbled: [...] nfs nfs servnnfs servefs r server19 2.19162n.fs snerver fs1 s9nfs s2er.nfs server er192.168.0.31:/pool/packages: not responding v er 192.168.0.31ver :/po1ol/packages9: 2.168.0.31:/pool/packagesn: noot responding t <6>n fs serverespondinngf s server 192.168.1rn nfs server 192.168.0.31:/pool/packages: not1 responding 9 2.168.1f7s 0.31:/pool/packagenfs sesrver 19serv2er .168.0.31:/poo: not respolnding / packages: not responding nfs server 19192.168.0.31:/pool/pa2c.k168.0.31:a/gpserver ne1s92.168.0.31:/pool/pac: knot respaof1s68 gs.e17rve8r.2 3192.168.0.31:/pool/packa1:/pool/packages: not responding o goes: nl/packag= es: not responding o t responding nfs server 192.168.0.31:/poes: ol/packages: nfns server 192.168.0.31:/pool/paot responding c kages: not respondinnfs server n192.1f68.0.31:/pool/packagess: ndi server 192.168.0.31:/pool/packages: not responding [...] Earlier this year after introduction of IFLIB, I checked out servers equipt= ed with Intels very popular i350T2v2 NIC and I had similar problems when dd'ing large files over NFSv4 (ZFS backed) from a client (em0, a client/consumer g= rade older NIC from 2010, forgot its ID, towards server with i350, but the server side got stuck with the messages seen similar to those reported with the i217-LM). Since my department uses lots of those server grade NICs, I will = swap the i217 with a i350T2 and check again. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat May 27 07:54:02 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A9ABD84810 for ; Sat, 27 May 2017 07:54:02 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 783121CAE; Sat, 27 May 2017 07:54:02 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id A27BCCE3; Sat, 27 May 2017 07:54:01 +0000 (UTC) Date: Sat, 27 May 2017 09:54:01 +0200 From: Baptiste Daroussin To: "Rodney W. Grimes" Cc: Toomas Soome , Andriy Gapon , Mariusz Zaborski , freebsd-net@freebsd.org, "George V. Neville-Neil" , Toomas Soome , Steven Hartland Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170527075401.xlpzc5odaxpupnsh@ivaldir.net> References: <9E2DD485-BC28-4DF0-B6EA-22FF63E33D4F@me.com> <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sspro6sax76c56wp" Content-Disposition: inline In-Reply-To: <201705270329.v4R3TUP1011340@pdx.rh.CN85.dnsmgr.net> User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 07:54:02 -0000 --sspro6sax76c56wp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 08:29:30PM -0700, Rodney W. Grimes wrote: > > > On 26. mai 2017, at 12:27, Andriy Gapon wrote: > > >=20 > > > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > >> Author: oshogbo > > >> Date: Thu Mar 9 06:01:24 2017 > > >> New Revision: 314948 > > >> URL: https://svnweb.freebsd.org/changeset/base/314948 > > >>=20 > > >> Log: > > >> Try to extract the RFC1048 data from PXE. If we get enough info we = can skip > > >> the bootp(). It removes unnecessary DHCP request from pxeloader. > > >>=20 > > >> Submitted by: kczekirda > > >> Sponsored by: Oktawave > > >> Initiated by: Matthew Dillon > > >> Reviewed by: smh, gnn, bapt, oshogbo > > >> MFC after: 3 weeks > > >> Differential Revision: https://reviews.freebsd.org/D9847 > > >=20 > > > Sorry for being late to the party, but this being head hopefully not = too late. > > >=20 > > > I am not sure that I agree with the spirit of this change. > > >=20 > > > There are network boot setups that do depend on the "unnecessary" DHC= P request > > > from pxeboot. For example, a DHCP server could be configured to retu= rn a > > > different set of parameters depending on a particular PXE client. I = personally > > > use a configuration where the DCHP server sends a boot menu[*] to a P= XE client > > > that's built into network cards. If a FreeBSD boot is selected and p= xeboot is > > > started, then the server sends parameters required for the FreeBSD bo= ot > > > (root-path, etc) in response to the request from pxeboot. > > > I don't see how I can keep that working after this change. > > >=20 > > > Additionally, as far as I can tell, we only get cached > > > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environm= ents where > > > a separate PXE server (Proxy DHCP) is used. In that case the reply m= ight not > > > have the network configuration information which would actually be in > > > PXENV_PACKET_TYPE_DHCP_ACK. > > > An example of such a setup is described here: > > > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-prox= y-mode/ > > > Using a separate PXE server is not uncommon in corporate environments= too. > > >=20 > > > In general, I think that the change was not thought through to cover = scenarios > > > beyond the basic unattended, FreeBSD-only, single DHCP server network= boots. > > > That scenario is, of course, very common, but it is not the only one. > > >=20 > > > At minimum, I would like to have a compile time option to control whe= ther > > > pxeboot should send a DHCP request of its own or rely entirely on the= cached > > > information. Or maybe pxeboot could be smart enough to do the former= if the > > > cached reply is missing some required information like the root-path. > > > Right now, there is no bootp(BOOTP_PXE) under any conditions. > > >=20 > > > And my apologies again for missing the original discussion. > > > My focus was somewhere else at the time. > > >=20 > > > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. > > >=20 > > > References: > > > http://www.pix.net/software/pxeboot/archive/pxespec.pdf > > > --=20 > > > Andriy Gapon > >=20 > >=20 > > Yep, there was some discussion added after the commit, and IMO the only= real conclusion was that this whole topic needs some more thinking. Also I= do not think the holy grail should be reusing the initial ACK - it may be = providing enough information for simple setups, but is most certainly not e= nough for more complex ones as you just did describe. Also, it did became q= uite clear that there are some different views on the issue, so IMO we need= to take some time to collect the ideas and then figure what is the best wa= y there. > >=20 >=20 > It is starting to become very clear that we do infact need to > do a full on DHCP request, hopefully with a unique client > string to indicate to the dhcp server that this is the freebsd > loader making the request. This would lead to a great deal > of flexiability for those of use using complicated PXE boot > menus and infustructure supporting much more than just FreeBSD > as a client. >=20 > The fact that FreeBSD does not do this has made it more > difficult to deal with than it should be when adding it > to a network boot infustructure. >=20 This addresses it: https://reviews.freebsd.org/D10951 defining a FREEBSD user class on dhcp request. I plan to remove the BOOTP_PXE option afterward to always boot with a full = dhcp request no need to differentiate BOOTP_PXE and others. Best regards, Bapt --sspro6sax76c56wp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkpMJUACgkQY4mL3PG3 PloAChAAlitSCfghc2Z/3DUFotuFKWVYSAA47l+78swhI0ZBwPrxn+yos75xXL22 PrjTdAbTkSYM6TwqIS+YBb5p5ZElBPMkU+WqPyE3kZtqnZYnMkWgO4Beov0FMCt3 7wnVB+MKyw+MTkhwpqoMSAfxx4aKKk81AZLiOCJnZwmRuGzkZwsQK+z6wnduwbiF kC9HN5sb+S6pWTsGRTLIeplmIT2SUuAe594fAN95uvG4zEMa2us/x5XHZPuSqquR PizkJa507BDVRTusSsFxApagNzIxE9yBweqoxAWKxCYDBNWWYHTrdZl+IKOw7lKy SBtGijU1CWE7Gla3ulDiS5zcodlO61C7v6RTQDkUBPUMagIwApbtVuTzTljvYjtX 7lwrIDTgLogvrjW2LjDQXAh4i35Fsnm0E8QD48HY697OGQaZ6Sx+2mi71Qeu/jvc h7YayvXIeKg1xQ9GbG+9m/EHwbEmS1fm2Ihj6KjxaPlEVL0VLB1opRlPLcCJd2zS 63EdsJzc/xx2dBMA+HEdqBQA6kb2NijOhYJ96DQMjT6FKGz4Z84BmxpQ9i44GxmP jWChsdeetZMe48WO7iG366sqNVoR/1nZriJ1pfl3gmfLtlcuvPBhB4l2ezWG4qXi 2YT8H+sTzEX/GmwLupsbVCDmw9D5UDqJ4S9NJD6P1JTb7BSj/sg= =dXwx -----END PGP SIGNATURE----- --sspro6sax76c56wp-- From owner-freebsd-net@freebsd.org Sat May 27 12:56:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5967DD85A7A for ; Sat, 27 May 2017 12:56:18 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4C11202; Sat, 27 May 2017 12:56:18 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id 4382D4399; Sat, 27 May 2017 12:56:17 +0000 (UTC) Date: Sat, 27 May 2017 14:56:16 +0200 From: Baptiste Daroussin To: Andriy Gapon Cc: Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Toomas Soome , freebsd-net@FreeBSD.org Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170527125616.3c5h4iag3egvq32s@ivaldir.net> References: <201703090601.v2961OJx077853@repo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lowxsrzm27t7fc6z" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 12:56:18 -0000 --lowxsrzm27t7fc6z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 12:27:45PM +0300, Andriy Gapon wrote: > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > Author: oshogbo > > Date: Thu Mar 9 06:01:24 2017 > > New Revision: 314948 > > URL: https://svnweb.freebsd.org/changeset/base/314948 > >=20 > > Log: > > Try to extract the RFC1048 data from PXE. If we get enough info we ca= n skip > > the bootp(). It removes unnecessary DHCP request from pxeloader. > > =20 > > Submitted by: kczekirda > > Sponsored by: Oktawave > > Initiated by: Matthew Dillon > > Reviewed by: smh, gnn, bapt, oshogbo > > MFC after: 3 weeks > > Differential Revision: https://reviews.freebsd.org/D9847 >=20 > Sorry for being late to the party, but this being head hopefully not too = late. >=20 > I am not sure that I agree with the spirit of this change. >=20 > There are network boot setups that do depend on the "unnecessary" DHCP re= quest > from pxeboot. For example, a DHCP server could be configured to return a > different set of parameters depending on a particular PXE client. I pers= onally > use a configuration where the DCHP server sends a boot menu[*] to a PXE c= lient > that's built into network cards. If a FreeBSD boot is selected and pxebo= ot is > started, then the server sends parameters required for the FreeBSD boot > (root-path, etc) in response to the request from pxeboot. > I don't see how I can keep that working after this change. >=20 > Additionally, as far as I can tell, we only get cached > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments= where > a separate PXE server (Proxy DHCP) is used. In that case the reply might= not > have the network configuration information which would actually be in > PXENV_PACKET_TYPE_DHCP_ACK. > An example of such a setup is described here: > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mo= de/ > Using a separate PXE server is not uncommon in corporate environments too. >=20 > In general, I think that the change was not thought through to cover scen= arios > beyond the basic unattended, FreeBSD-only, single DHCP server network boo= ts. > That scenario is, of course, very common, but it is not the only one. >=20 > At minimum, I would like to have a compile time option to control whether > pxeboot should send a DHCP request of its own or rely entirely on the cac= hed > information. Or maybe pxeboot could be smart enough to do the former if = the > cached reply is missing some required information like the root-path. > Right now, there is no bootp(BOOTP_PXE) under any conditions. >=20 > And my apologies again for missing the original discussion. > My focus was somewhere else at the time. >=20 > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. >=20 > References: > http://www.pix.net/software/pxeboot/archive/pxespec.pdf I should have been all fixed in head (including some sugar added) Can you confirm? Best regards, Bapt --lowxsrzm27t7fc6z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkpd18ACgkQY4mL3PG3 PlrooA//QM99YZ3ZzTiRwy8wNkp0sdAVGq/53s+Pj/STIh51kxQjtTWndTRR9UYJ 5V8cGc4GCUnhsgB671qvI8sQfPI5D2aL6G8jXSTukxPvVak4vJeB5a5m17ObrDyO HrZSJc6Ebgkr+7JVkL2U9mdjWb0xoMn0OXBStM+49igSBWW1hcvbC8Vtzs7Jflsm TMEpKLutmRylZzQOSW3khAgYtt3gByfNJbwUifzwwPw9b9ATscxju3zqv0hPf7tC R3gv7ifaK3vDLvlOeGJDUGC9DxosVIzTt1XmQcII+X5deZ9+/hdPQNufG7FR6rhH AQ1OtV8Aqr1thlQeS6mgf5FOuxWNlC4ry9vGte3mk/oW0Tl0Aildnbm006k38UEB AnnSWEYOU7YX5dw+rOODJ/tkfkjIqQVAL1Mn8McSgnlM5MFTFlHubDvvolirmIFI +A7kOD5zAHUOFzLn+n/La87ixW18LCkEQTaXCEO/ZgfNYrxgtDNY+gBbfnnm9Fgi UfdfKLpGQDVK9LCuLLzDolWGgSMCePfL+YZmO7mEraMmaDWrJn+04QJqEyIPfQs0 24Vng0DJi8UVlWCA4VZONeHTX8WenqG2hP7ANJrLoPyvHkr0SqdQSi748m0xPIlJ qVeAu8GmGIzm2AmKOdaSOoUJaSWN3fl5du7kXiRfbyDZK3NcOnY= =al8r -----END PGP SIGNATURE----- --lowxsrzm27t7fc6z-- From owner-freebsd-net@freebsd.org Sat May 27 18:58:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA1BED85D77 for ; Sat, 27 May 2017 18:58:52 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64F551D8F for ; Sat, 27 May 2017 18:58:51 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v4RIwmEc085067; Sat, 27 May 2017 20:58:48 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 1D261561; Sat, 27 May 2017 20:58:48 +0200 (CEST) Message-ID: <5929CC67.4020508@omnilan.de> Date: Sat, 27 May 2017 20:58:47 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: FreeBSD Net Subject: Re: [panic] netmap(4) and if_lagg(4) References: <58CBCD7A.8060301@omnilan.de> <58CC23F5.7060507@omnilan.de> <58CFA394.8070901@omnilan.de> <5926EE96.1010000@omnilan.de> <5926F9F9.4040706@omnilan.de> <592701D6.7030301@omnilan.de> <592742A8.4010207@omnilan.de> <5927D560.10003@omnilan.de> <5927D77A.60502@omnilan.de> <5927E974.6060706@omnilan.de> <5927EF05.9040208@omnilan.de> <59281DF8.20402@omnilan.de> In-Reply-To: <59281DF8.20402@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 27 May 2017 20:58:48 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 18:58:53 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 26.05.2017 14:22 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 11:06 (localtime): >> Yes, it should integrate and compile out of the box, I've done that >> several times with FreeBSD-11.0 and 10.3. > Impressive, it needed just a small addition to sys/conf/files to make > the linker happy :-) I perpared a diff to merge HEAD's netmap code to 11.1-prerelease for further tests (preferred over replacing stable/11 code with upstream clone, since there were some post-sync (r307394, 2016 Oct.) fixes, which I haven't check if they are FreeBSD specific or also included upstream). This hasn't changed anything regarding my problems (vale-ctl -a vale0:em0 not usable anymore: netmap_ring request size 65792 too large, panic when adding trying to add vale0:lagg0), but hopefully make things easier to narrow down the problems. If anybody else is interested in closer upstream netmap code on stable/11, here's the diff of the inofficial MFC: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/MFC-netmap-to-11.1-prerelease.diff I hope I found all related commits, but I've done by hand; no idea if there's a way to let svn do the same job... List of repspected revisions: r306772, r307394-r307396, r307569, r307572, r307574, r307703, r307706, r307728, r308000, r308038, r309306, r310822, r311045, r311986, r313747, r314915. No guarantee that I missed something! No tests regarding pt_netmap done yet, I just wanted to provide a better testing platfrom! -harry From owner-freebsd-net@freebsd.org Sat May 27 22:09:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4325D85F18 for ; Sat, 27 May 2017 22:09:41 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 518FA1959; Sat, 27 May 2017 22:09:41 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: by mail-qk0-x229.google.com with SMTP id u75so28128506qka.3; Sat, 27 May 2017 15:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YVG2/YcJwUJF2u6E+r4Mq5VOw9XiIn53uibfCj7u/rY=; b=SFXoyDauYusoT/eJ0FL9KhYD8F/tCJ5X7iaSHZTYurfPTo8pJwDdQrrEIYwLIx/f3L RzFIhx9c4NNWIbKvJJoGBMu6Q112oAOaU6BI59Jb7qlhm8SEXDPsaCOtYcBjsS8iuFvp j0890FkxxtOc7EP0+x6DJsLMh7zove+sf9jFUP8LubMFB2dmOx9ljCVJLdoll8w1Az+S 8DKXK7cAiFI0pXiuSWePLHvsgs0CyLZ88C57ZiOlz0Ijym1cgo16NBm8og964/rF00ib 8wrUymHDaDyfhQPeWOyGN9HjB6wkpnM51xI2OnzjJYfyv808Ccqq0k1Z1bWWURdpvtBB Q0Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YVG2/YcJwUJF2u6E+r4Mq5VOw9XiIn53uibfCj7u/rY=; b=NW2zJoWPv3mP2R5Z4wSOEgLGbG+H1LWiA9cHi/FAqysSc2esIMj8Rz1iyDtoLxargx gGsZoGIjCiQ6UHs4nFjSzeqF/ACp1ppWet4Lkii9Y6MbD6a3QBzOEMehNGqxtxdSZFHE vNM9PjU7ixXs0Y0+tXzmpEQwLeod7WNuimpDY+j204OI3PXqZ49k/dwxAbG2MCuEYYF/ uS4YldxNPMdcN2MmQ5qKcJwwt7/VChHBEnGJsftxUwACSXqN/Rf1Xbwi8KNMWHnh7nU8 unVNCgmTNc0TH1sPyeHa0JzHsnfpM5oLu2lwPKwFSXSxJDx0D4qU8cyHpMeilRpMGcSI WRbg== X-Gm-Message-State: AODbwcBae4fOh+pUf6d8DxYkbiClT6jiWLOw4IzB9fKb1HG7JMkS/PVm ySo8JKD/NLkcMeBcTzroF6w665QBty7aIaA= X-Received: by 10.233.239.65 with SMTP id d62mr8952232qkg.119.1495922980237; Sat, 27 May 2017 15:09:40 -0700 (PDT) MIME-Version: 1.0 Sender: kczekirda@gmail.com Received: by 10.200.44.139 with HTTP; Sat, 27 May 2017 15:09:09 -0700 (PDT) In-Reply-To: <20170526210908.ykqalqbetxp4f27p@ivaldir.net> References: <201703090601.v2961OJx077853@repo.freebsd.org> <20170526210908.ykqalqbetxp4f27p@ivaldir.net> From: Kamil Czekirda Date: Sun, 28 May 2017 00:09:09 +0200 X-Google-Sender-Auth: --X8tVQ0iJdDeTESL8iNo6s5DYE Message-ID: Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 To: Baptiste Daroussin Cc: Andriy Gapon , Mariusz Zaborski , Steven Hartland , "George V. Neville-Neil" , Toomas Soome , freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 22:09:41 -0000 2017-05-26 23:09 GMT+02:00 Baptiste Daroussin : > On Fri, May 26, 2017 at 12:27:45PM +0300, Andriy Gapon wrote: > > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > > Author: oshogbo > > > Date: Thu Mar 9 06:01:24 2017 > > > New Revision: 314948 > > > URL: https://svnweb.freebsd.org/changeset/base/314948 > > > > > > Log: > > > Try to extract the RFC1048 data from PXE. If we get enough info we > can skip > > > the bootp(). It removes unnecessary DHCP request from pxeloader. > > > > > > Submitted by: kczekirda > > > Sponsored by: Oktawave > > > Initiated by: Matthew Dillon > > > Reviewed by: smh, gnn, bapt, oshogbo > > > MFC after: 3 weeks > > > Differential Revision: https://reviews.freebsd.org/D9847 > > > > Sorry for being late to the party, but this being head hopefully not too > late. > > > > I am not sure that I agree with the spirit of this change. > > I just figured out it also breaks chainloading with ipxe (like qemu does) > and it > does not request the rootpath if not passed to the ipxe first. > > I'm now really thinking the our loader deserves its own DHCP value. > > We should also give it some tags so people can provide it the information > they > want depending on the tags (like hey this is the fbsd loader give it that > rootpath). > > > > > There are network boot setups that do depend on the "unnecessary" DHCP > request > > from pxeboot. For example, a DHCP server could be configured to return a > > different set of parameters depending on a particular PXE client. I > personally > > use a configuration where the DCHP server sends a boot menu[*] to a PXE > client > > that's built into network cards. If a FreeBSD boot is selected and > pxeboot is > > started, then the server sends parameters required for the FreeBSD boot > > (root-path, etc) in response to the request from pxeboot. > > I don't see how I can keep that working after this change. > > > > Additionally, as far as I can tell, we only get cached > > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in > environments where > > a separate PXE server (Proxy DHCP) is used. In that case the reply > might not > > have the network configuration information which would actually be in > > PXENV_PACKET_TYPE_DHCP_ACK. > > An example of such a setup is described here: > > https://n0dy.com/blog/2014/09/14/network-booting-with- > dnsmasq-in-proxy-mode/ > > Using a separate PXE server is not uncommon in corporate environments > too. > > > > In general, I think that the change was not thought through to cover > scenarios > > beyond the basic unattended, FreeBSD-only, single DHCP server network > boots. > > That scenario is, of course, very common, but it is not the only one. > > > > At minimum, I would like to have a compile time option to control whether > > pxeboot should send a DHCP request of its own or rely entirely on the > cached > > information. Or maybe pxeboot could be smart enough to do the former if > the > > cached reply is missing some required information like the root-path. > > Right now, there is no bootp(BOOTP_PXE) under any conditions. > > > In initial revision I noticed, that I'm not sure it should be default behavior. In a lot of installations pxeloader can base on the cache and doesn't require second, full request with the same answer. In that situation we can switch off bootp() and I think it would be nice to have this switch and give them to users. Flag during compilation is sensible. In very simple and popular case we have chain with four requests for the same information (!): PXE (NIC) -> iPXE -> pxeloader -> dhclient and it's possible to switch off request from iPXE and pxeloader without breaking boot process. Kamil > > And my apologies again for missing the original discussion. > > My focus was somewhere else at the time. > > > > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. > > > From owner-freebsd-net@freebsd.org Sat May 27 22:14:10 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D862FD850C6 for ; Sat, 27 May 2017 22:14:10 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id BEDF31CEE for ; Sat, 27 May 2017 22:14:10 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v4RME3KQ097038 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 27 May 2017 15:14:03 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me Subject: Re: Bug in make setting wrong MAKESYSPATH To: Thomas Mueller , freebsd-net@freebsd.org References: <97050ce3-ad75-c3dc-c106-3bd608e7aa8e@rawbw.com> From: Yuri Message-ID: <0758ef3c-c581-12ff-9310-81af40188236@rawbw.com> Date: Sat, 27 May 2017 15:14:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 22:14:10 -0000 On 05/27/2017 00:26, Thomas Mueller wrote: > NetBSD developers say they intend to remove dhclient in the future. > > On NetBSD, sometimes dhclient works where dhcpcd doesn't, or vice versa. This is disconcerting. There should be at least one DHCP client that always works well. > NetBSD-current is on dhcpcd 7.0, ahead of FreeBSD ports version. 7.0.0 isn't released yet, it is in rc1: https://roy.marples.name/projects/dhcpcd FreeBSD is at the latest released version. Yuri