From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 02:32:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E78F67FE for ; Sun, 9 Jun 2013 02:32:18 +0000 (UTC) (envelope-from kentas@hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by mx1.freebsd.org (Postfix) with ESMTP id D166C1791 for ; Sun, 9 Jun 2013 02:32:18 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 99E7E30F17 for ; Sun, 9 Jun 2013 02:32:12 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp1.hushmail.com (Postfix) with ESMTP; Sun, 9 Jun 2013 02:32:11 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D8E42200EA; Sun, 9 Jun 2013 02:32:11 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 08 Jun 2013 22:32:11 -0400 To: freebsd-jail@freebsd.org Subject: Per-IP Bandwidth Monitoring From: "Kenta Suzumoto" In-Reply-To: <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> References: <20130607174701.9DAA0400EA@smtp.hushmail.com> <51B2228F.1000008@llaisdy.com> <20130607184536.4A4D7400EA@smtp.hushmail.com> <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130609023211.D8E42200EA@smtp.hushmail.com> Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 02:32:19 -0000 Hello. I'm running a FreeBSD machine with 5 IP addresses, each of them attached to a specific jail. I'm wondering if there is an easy way to monitor the bandwidth usage of each of them individually. Upon googling, I ran into a lot of suggestions like bandwidthd. I gave it a try and it seemed very broken and basically didn't work at all. I'm basically looking for a "vnstat that works per IP instead of per interface" kind of thing. jnettop wasn't what I was looking for. It doesn't have to make pretty graphs(but that's nice too), just human-readable text is fine. Anyone have a recommendation? Some links I came across that were unhelpful: http://freebsd.1045724.n5.nabble.com/how-to-measure-bandwidth-per-jail-td5797422.html http://forum.pfsense.org/index.php?&topic=32256.0 http://www.daemonforums.org/showthread.php?t=1199 Thanks From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 03:24:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B7134D8; Sun, 9 Jun 2013 03:24:26 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 93D9E1B6A; Sun, 9 Jun 2013 03:24:25 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f11so1747268qae.3 for ; Sat, 08 Jun 2013 20:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1gmJNU02JMPse5uEd7m9BpZTBB8otKCck8h+btZqlhw=; b=u72FoX6sIj6F1FpHHIsFxfPzhm3qaeB7lrgOejJd1mg63sdTT41jvYpEpqZ9Kofh9F eCaLQ+3wl/kYW1lIxXt574vk4L//IZ+rR8R8478VLfQX5lOZJyo3M3RcPQRir6YK8ru0 41O+BRk6WDfhU7tm5zPa0wOHv79Ux1nWycplnxPE7AdHnq8xvXdXFjljKi/KMNKo/fox Onml0dZalGKeLibmpCcWBatwuAGersDIS5TqAgH5GF6n8DCHryF4gs2ZyCgBMXbz8PCZ AVDhkETwou+GEEFEn3MrVUIAA8MlTaTHFActTIZngsCFWu4uwb8AbW9ShLnaobYRcbXq JCmQ== MIME-Version: 1.0 X-Received: by 10.49.11.168 with SMTP id r8mr5160488qeb.34.1370748265089; Sat, 08 Jun 2013 20:24:25 -0700 (PDT) Received: by 10.49.42.73 with HTTP; Sat, 8 Jun 2013 20:24:25 -0700 (PDT) In-Reply-To: <20130609023211.D8E42200EA@smtp.hushmail.com> References: <20130607174701.9DAA0400EA@smtp.hushmail.com> <51B2228F.1000008@llaisdy.com> <20130607184536.4A4D7400EA@smtp.hushmail.com> <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> <20130609023211.D8E42200EA@smtp.hushmail.com> Date: Sat, 8 Jun 2013 20:24:25 -0700 Message-ID: Subject: Re: Per-IP Bandwidth Monitoring From: Xin LI To: Kenta Suzumoto Content-Type: text/plain; charset=UTF-8 Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-jail@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 03:24:26 -0000 Try this patch: https://cgit.delphij.net/freebsd/patch/?id=39c6ec81eb015ed6788c203a1aea6148f813d063 We haven't merged it to -HEAD only because it's not clear how much overhead this would incur. Cheers, From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 04:27:54 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B1AF7D; Sun, 9 Jun 2013 04:27:54 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 75E0D1EF8; Sun, 9 Jun 2013 04:27:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r594RsfE020688; Sun, 9 Jun 2013 04:27:54 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r594RrCG020687; Sun, 9 Jun 2013 04:27:53 GMT (envelope-from ae) Date: Sun, 9 Jun 2013 04:27:53 GMT Message-Id: <201306090427.r594RrCG020687@freefall.freebsd.org> To: lampa@fit.vutbr.cz, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/154169: [multicast] [ip6] Node Information Query multicast address wrong (FF02::2:x:y) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 04:27:54 -0000 Synopsis: [multicast] [ip6] Node Information Query multicast address wrong (FF02::2:x:y) State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Sun Jun 9 04:26:47 UTC 2013 State-Changed-Why: This was patched in r250251. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=154169 From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 04:34:10 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3015D24B; Sun, 9 Jun 2013 04:34:10 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 09B2B1F91; Sun, 9 Jun 2013 04:34:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r594Y91Q022421; Sun, 9 Jun 2013 04:34:09 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r594Y9Ks022420; Sun, 9 Jun 2013 04:34:09 GMT (envelope-from ae) Date: Sun, 9 Jun 2013 04:34:09 GMT Message-Id: <201306090434.r594Y9Ks022420@freefall.freebsd.org> To: tejblum@yandex-team.ru, ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/157209: [ip6] [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 04:34:10 -0000 Synopsis: [ip6] [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) State-Changed-From-To: open->closed State-Changed-By: ae State-Changed-When: Sun Jun 9 04:31:46 UTC 2013 State-Changed-Why: This was fixed in r248180 and merged to stable/9, stable/8. Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Sun Jun 9 04:31:46 UTC 2013 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=157209 From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 05:09:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 454BD9DC for ; Sun, 9 Jun 2013 05:09:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 110791218 for ; Sun, 9 Jun 2013 05:09:24 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so8670227iea.25 for ; Sat, 08 Jun 2013 22:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fa8ZsxRoPtP5wKgjYpnp+S/t58oUwjYlhOIlqVEUsAo=; b=GuP01KWWylB/jy2Nxs3YAIZ/8lNDC7UQR3L4TOXNf+XB0csOBrwLnVCfA6dHUPYVOl /UOVdbQloUamKbZuRw+dXl7GK1RzRFVlqzMr6cmA6OYHkGyPugsQh19CVc0yJtcm5NvV FrnQOek36OVQ/gkKzJLev6LeuAe3P5HdpqbrdTTYU4QA9a5jwAIVkenZabjWC7AZzRgE hEeQwhT4Ez9UPrB1H1lmy3Yqfvm+ezeKN92MbvaZnOlI4yg3hvrtwoJxajnp7VhJUql/ /sYLgGA53ufLcZnJhNQsDRN6/BYkl9hh/jAPaKB7DNp4gXr2IrL9KLmTPYTNLq8IFyF1 wzVg== X-Received: by 10.50.12.99 with SMTP id x3mr1818894igb.58.1370754563223; Sat, 08 Jun 2013 22:09:23 -0700 (PDT) Received: from raichu ([24.212.218.13]) by mx.google.com with ESMTPSA id wn10sm4238408igb.2.2013.06.08.22.09.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Jun 2013 22:09:22 -0700 (PDT) Sender: Mark Johnston Date: Sun, 9 Jun 2013 01:09:17 -0400 From: Mark Johnston To: Kenta Suzumoto Subject: Re: Per-IP Bandwidth Monitoring Message-ID: <20130609050917.GA31573@raichu> References: <20130607174701.9DAA0400EA@smtp.hushmail.com> <51B2228F.1000008@llaisdy.com> <20130607184536.4A4D7400EA@smtp.hushmail.com> <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> <20130609023211.D8E42200EA@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130609023211.D8E42200EA@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 05:09:24 -0000 On Sat, Jun 08, 2013 at 10:32:11PM -0400, Kenta Suzumoto wrote: > Hello. I'm running a FreeBSD machine with 5 IP addresses, each of them attached to a specific jail. I'm wondering if there is an easy way to monitor the bandwidth usage of each of them individually. Upon googling, I ran into a lot of suggestions like bandwidthd. I gave it a try and it seemed very broken and basically didn't work at all. I'm basically looking for a "vnstat that works per IP instead of per interface" kind of thing. jnettop wasn't what I was looking for. It doesn't have to make pretty graphs(but that's nice too), just human-readable text is fine. Anyone have a recommendation? I'm not clear on what exactly you're after, but it seems like you should be able to get the info you need using the DTrace ip provider. This provider isn't available in FreeBSD yet, but a patch for it is at [1]. To use it, you'll need to recompile the kernel with my changes and then install the ip.d file from the patch to /usr/lib/dtrace. Once that's done, you can try the example script at [2] on your jail host. It just tracks the number of sent and received bytes per local IP address, and prints the totals every second. That's just an example presentation though - the point is that collecting this kind of info is pretty trivial with DTrace. The downside is that such scripts may hurt your throughput since they cause the kernel to execute some extra code for every packet sent and received through the IP stack. The actual performance hit will depend on the script. -Mark [1] http://people.freebsd.org/~markj/patches/providers/ip-provider.diff [2] http://people.freebsd.org/~markj/monitor.d From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 08:28:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0E43121; Sun, 9 Jun 2013 08:28:44 +0000 (UTC) (envelope-from bah@bananmonarki.se) Received: from feeder.usenet4all.se (1-1-1-38a.far.sth.bostream.se [82.182.32.53]) by mx1.freebsd.org (Postfix) with ESMTP id 373EC1D1D; Sun, 9 Jun 2013 08:28:43 +0000 (UTC) Received: from kw.news4all.se (localhost [127.0.0.1]) by feeder.usenet4all.se (8.13.1/8.13.1) with ESMTP id r598SQ2k072688; Sun, 9 Jun 2013 10:28:30 +0200 (CEST) (envelope-from bah@bananmonarki.se) Message-ID: <51B43C9F.70802@bananmonarki.se> Date: Sun, 09 Jun 2013 10:28:15 +0200 From: Bernt Hansson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130419 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kenta Suzumoto Subject: Re: Per-IP Bandwidth Monitoring References: <20130607174701.9DAA0400EA@smtp.hushmail.com> <51B2228F.1000008@llaisdy.com> <20130607184536.4A4D7400EA@smtp.hushmail.com> <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> <20130609023211.D8E42200EA@smtp.hushmail.com> In-Reply-To: <20130609023211.D8E42200EA@smtp.hushmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-jail@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 08:28:44 -0000 On 2013-06-09 04:32, Kenta Suzumoto wrote: > Hello. I'm running a FreeBSD machine with 5 IP addresses, each of them attached to a specific jail. I'm wondering if there is an easy way to monitor the bandwidth usage of each of them individually. Upon googling, I ran into a lot of suggestions like bandwidthd. I gave it a try and it seemed very broken and basically didn't work at all. I'm basically looking for a "vnstat that works per IP instead of per interface" kind of thing. jnettop wasn't what I was looking for. It doesn't have to make pretty graphs(but that's nice too), just human-readable text is fine. Anyone have a recommendation? > > Some links I came across that were unhelpful: > http://freebsd.1045724.n5.nabble.com/how-to-measure-bandwidth-per-jail-td5797422.html > > http://forum.pfsense.org/index.php?&topic=32256.0 > > http://www.daemonforums.org/showthread.php?t=1199 > > Thanks IPFW with pipes. No graphs. man ipfw TRAFFIC SHAPER CONFIGURATION The ipfw pipe, queue and sched commands are used to configure the traffic shaper and packet scheduler. See the TRAFFIC SHAPER (DUMMYNET) CONFIGURATION Section below for details. If the world and the kernel get out of sync the ipfw ABI may break, pre- venting you from being able to add any rules. This can adversely effect the booting process. You can use ipfw disable firewall to temporarily disable the firewall to regain access to the network, allowing you to fix the problem. From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 12:37:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 904F25E1; Sun, 9 Jun 2013 12:37:10 +0000 (UTC) (envelope-from alexl@mellanox.com) Received: from eu1sys200aog120.obsmtp.com (eu1sys200aog120.obsmtp.com [207.126.144.149]) by mx1.freebsd.org (Postfix) with ESMTP id 18AD01703; Sun, 9 Jun 2013 12:37:08 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKUbR20hCLTG9M1dfNz2Vdk3nUEuY5eO+T@postini.com; Sun, 09 Jun 2013 12:37:09 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Sun, 9 Jun 2013 15:35:33 +0300 From: Alex Liptsin To: "freebsd-infiniband@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org" Subject: Mellanox NIC names changed, each kldunload/kldload mlx4ib module Thread-Topic: Mellanox NIC names changed, each kldunload/kldload mlx4ib module Thread-Index: Ac5lDdVKtrqzpa1jQyWp4SCSJfBUVA== Date: Sun, 9 Jun 2013 12:35:32 +0000 Message-ID: <64DAB3164E410447932305F50F896D8D6AF6D2E6@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Oded Shanoon , Regev Lev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 12:37:10 -0000 Hi. I work with FreeBSD9.1 and Mellanox devices. Every time I unload / load mlx4ib module, NIC names of mellanox devices (ib= X) are renamed. Can I prevent it? [root@h-qa-032 mlx4]# ifconfig ib8: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.28.0.48.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.31 nd6 options=3D29 ib9: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.28.0.49.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.32 nd6 options=3D29 [root@h-qa-032 mlx4]# kldunload mlx4ib [root@h-qa-032 mlx4]# kldload -v mlx4ib Loaded mlx4ib, id=3D9 [root@h-qa-032 mlx4]# ifconfig ib10: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.30.0.48.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.31 nd6 options=3D29 ib11: flags=3D8002 metric 0 mtu 65520 options=3D80018 lladdr 80.30.0.49.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.32 nd6 options=3D29 Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161 Email: alexl@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Isr= ael From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 12:55:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B1CE209; Sun, 9 Jun 2013 12:55:23 +0000 (UTC) (envelope-from pjlists@netzkommune.de) Received: from mx1.dui.nkhosting.net (mx1.dui.nkhosting.net [213.9.94.26]) by mx1.freebsd.org (Postfix) with ESMTP id F0EA5185E; Sun, 9 Jun 2013 12:55:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.dui.nkhosting.net (Postfix) with ESMTP id E87D3211C54AE; Sun, 9 Jun 2013 12:48:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx1.dui.nkhosting.net Received: from mx1.dui.nkhosting.net ([127.0.0.1]) by localhost (mx1.dui.nkhosting.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf3ojEhyin0E; Sun, 9 Jun 2013 12:48:02 +0200 (CEST) Received: from air13.home (AMontsouris-552-1-72-100.w92-140.abo.wanadoo.fr [92.140.39.100]) (Authenticated sender: pjlists@netzkommune.de) by mx1.dui.nkhosting.net (Postfix) with ESMTP id 598B4211C651D; Sun, 9 Jun 2013 12:48:02 +0200 (CEST) Subject: Re: Per-IP Bandwidth Monitoring Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Philip Jocks In-Reply-To: <20130609023211.D8E42200EA@smtp.hushmail.com> Date: Sun, 9 Jun 2013 12:47:59 +0200 Jabber-Id: pj@netzkommune.de Content-Transfer-Encoding: quoted-printable Message-Id: <89E98E53-6B11-468D-B160-2188FE189983@netzkommune.de> References: <20130607174701.9DAA0400EA@smtp.hushmail.com> <51B2228F.1000008@llaisdy.com> <20130607184536.4A4D7400EA@smtp.hushmail.com> <144D087B-9396-4FD5-90DD-2F7A29D9E55F@llaisdy.com> <20130609023211.D8E42200EA@smtp.hushmail.com> To: Kenta Suzumoto X-Mailer: Apple Mail (2.1503) Cc: freebsd-isp@freebsd.org, freebsd-net@freebsd.org, freebsd-jail@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 12:55:23 -0000 Am 09.06.2013 um 04:32 schrieb Kenta Suzumoto : > Hello. I'm running a FreeBSD machine with 5 IP addresses, each of them = attached to a specific jail. I'm wondering if there is an easy way to = monitor the bandwidth usage of each of them individually. Upon googling, = I ran into a lot of suggestions like bandwidthd. I gave it a try and it = seemed very broken and basically didn't work at all. I'm basically = looking for a "vnstat that works per IP instead of per interface" kind = of thing. jnettop wasn't what I was looking for. It doesn't have to make = pretty graphs(but that's nice too), just human-readable text is fine. = Anyone have a recommendation? >=20 > Some links I came across that were unhelpful:=20 > = http://freebsd.1045724.n5.nabble.com/how-to-measure-bandwidth-per-jail-td5= 797422.html >=20 > http://forum.pfsense.org/index.php?&topic=3D32256.0 >=20 > http://www.daemonforums.org/showthread.php?t=3D1199 I was using sysutils/ipa for this. It works with IPFW and also with PF, = I think, I have just used it with ipfw, worked pretty fine. It also = supports all sorts of reporting. Cheers, Philip From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 17:42:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5AFC637 for ; Sun, 9 Jun 2013 17:42:24 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 69F2E167E for ; Sun, 9 Jun 2013 17:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1370799745; x=1402335745; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=8Njj9xh1MWBj4i1gH/mtYUF/n0rHFEjw3FCagNrXoA4=; b=DzwjnPFi5IoLrknSUuwUqYorislSyD+K4DOP8Y/OJieUfkVTDCpiqS+p jc6e9QdmlY7GT/+NFvHE7y0FXNEBycE74DKRMXRY5Gxx6qllXkyT5kimV /+orTl4Zo/DZWMhQ291aIs8yXkllhit1662zKCW+8BAZog476sh6oBA/M U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEu9tFEKXgZY/2dsb2JhbABZDoJ7eb4+ehZ0giUFJ1ISAQUDIlYmAQQOBQiIBblsjwUCMYMGYQOIaKAagVh5PjyBaw X-IPAS-Result: AgEFAEu9tFEKXgZY/2dsb2JhbABZDoJ7eb4+ehZ0giUFJ1ISAQUDIlYmAQQOBQiIBblsjwUCMYMGYQOIaKAagVh5PjyBaw Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 09 Jun 2013 19:42:22 +0200 Received: from E14MDB-02.zdv.Uni-Mainz.DE ([fe80::1b:21ff:fe65:4560]) by E14HUB-02.zdv.Uni-Mainz.DE ([fe80::21d:d8ff:feb7:1c60%9]) with mapi id 14.03.0146.000; Sun, 9 Jun 2013 19:42:21 +0200 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: "'spawk@acm.poly.edu'" Subject: Re: Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection Thread-Topic: Re: Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection Thread-Index: Ac5lN+4bW+3d4vLLTfOXAST1yqeScg== Date: Sun, 9 Jun 2013 17:42:20 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-net@freebsd.org'" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 17:42:24 -0000 With the following patch the ixgbe (ix) driver accepts any SFP. --- ixgbe_phy.c.orig 2012-10-01 18:38:31.000000000 +0200 +++ ixgbe_phy.c 2012-11-13 16:23:18.650609931 +0100 @@ -1186,6 +1186,7 @@ } =20 ixgbe_get_device_caps(hw, &enforce_sfp); + enforce_sfp |=3D IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) && !((hw->phy.sfp_type =3D=3D ixgbe_sfp_type_1g_cu_core0) = || (hw->phy.sfp_type =3D=3D ixgbe_sfp_type_1g_cu_core1) = || Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 18:06:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD6BCF6 for ; Sun, 9 Jun 2013 18:06:47 +0000 (UTC) (envelope-from alexander.kapshuk@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 636DA1793 for ; Sun, 9 Jun 2013 18:06:47 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id jg1so2727001bkc.6 for ; Sun, 09 Jun 2013 11:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=UaldNffFSb2oX0R+JNanFRh+8bp35SMZH2zjVo7Hqu0=; b=BPhDimlAxxw4gdWHLntYbkm7Nhosadwpe8dvMbi3p0a5yRJxKgn4KuYuAcqAZA8U7s j3mKUlg3fFPvPQBPU5jMGSYXINupyXQA+s4D1TtKwIheq4B2GABmKuQJf4SO5jMW7Pla BxKNOlSxo3I/VP5NczvbWqIB4/epT54fW/QKEVpmtyDuAp/DhPGua3DR+9cbR0iwvjyq KuXf4Rs75lVcgOTUqzAWmLX/vh/tZnNi7f24WVq8pF6P71Qa8LiVo/ZBLQXH/s7W15Gm jyE//UdbTgjOp2i5kXLtukyb7QVXJKAzigxzlJUMOomoBQWMtY4S94/PnFnlmV8v0Pta ubqw== X-Received: by 10.205.1.198 with SMTP id nr6mr990478bkb.168.1370801206372; Sun, 09 Jun 2013 11:06:46 -0700 (PDT) Received: from [192.168.1.3] (78-25-13-129.static.vega-ua.net. [78.25.13.129]) by mx.google.com with ESMTPSA id i15sm2420607bkz.12.2013.06.09.11.06.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 11:06:45 -0700 (PDT) Message-ID: <51B4C433.9010702@gmail.com> Date: Sun, 09 Jun 2013 21:06:43 +0300 From: Alexander Kapshuk User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130609 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: re: kldstat doesn't show ath_hal [AR2425] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 18:06:48 -0000 I've got an Atheros card, AR2425, which is supposed to be supported by ath_hal(4), according to the man page. dmesg|grep -i Ath ath0: mem 0xd6000000-0xd600ffff irq 16 at device 0.0 on pci2 ath0: AR2425 mac 14.2 RF5424 phy 7.0 I can see that ath_hal is listed in the kernel config file: egrep 'ath_|wlan_' GENERIC device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device ath_pci # Atheros pci/cardbus glue device ath_hal # pci/cardbus chip support device ath_rate_sample # SampleRate tx rate control for ath kldstat doesn't show ath_hal as having been loaded. Is that normal? kldstat -v|egrep 'wlan|ath_' 98 pci/ath_pci 434 wlan 433 wlan_wep 432 wlan_tkip 431 wlan_ccmp 430 wlan_amrr 436 wlan_sta 435 wlan_ratectl_none Long story short, I can't seem to be able to configure my wireless, despite following the instructions given in the handbook. Here's my /etc/rc.conf: cat /etc/rc.conf hostname="box0" sshd_enable="YES" moused_enable="YES" ntpd_enable="YES" powerd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO" wlans_ath0="wlan0" ifconfig_wlan0="ssid plan9 WPA DHCP" hald_enable="YES" dbus_enable="YES" linux_enable="YES" ifconfig_re0="DHCP" And my /etc/wpa_supplicant.conf: cat /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant eapol_version=2 ap_scan=1 fast_reauth=1 network={ ssid="plan9" psk=wpa_passphrase-generated psk } ifconfig -a ath0: flags=8843 metric 0 mtu 2290 ether 00:24:2c:5e:06:f2 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:23:8b:b2:e5:1f inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb inet 127.0.0.1 netmask 0xff000000 nd6 options=21 wlan0: flags=8843 metric 0 mtu 1500 ether 00:24:2c:5e:06:f2 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid plan9 channel 1 (2412 MHz 11g) regdomain 103 indoor ecm authmode WPA1+WPA2/802.11i privacy OFF txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL 'ifconfig wlan0 list scan' returns nothing. uname -a FreeBSD box0 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 I've tried everything I could think of, still no luck. Any pointers would be appreciated. Alexander Kapshuk. From owner-freebsd-net@FreeBSD.ORG Sun Jun 9 18:46:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F98E64C; Sun, 9 Jun 2013 18:46:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD1F19BC; Sun, 9 Jun 2013 18:46:08 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id xa12so6502298pbc.11 for ; Sun, 09 Jun 2013 11:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nNjUAJmFn79l1m0FsW6u8rOTczMdqUPfMsNzPEsOZmE=; b=vhhia6nYBPKBUbnU1uZqfO04huYgVMAe/oCCtzU4TaU4qxf+d0ofsVmhcGI4Zq39C9 TyOyLFMk1QaYeeKZa8OBNWKaKKVwUgqBGhsBUK+EUpf7UbPpZKQMzvyohvdCev7o45xQ qdCX33x96OqMBjczSD5p94RsZh1hvjExvu95kIADMg2trD505e9cNKxi3xhkgFtob7A7 5EmRAun0eVO+m1cw0GtPfKnqZFnu3kTaJ4wPYCxU+2mz1WA7ZQp8NlpF3sb8bC3SYAq3 lXU8VmYDnC5YNdxIjTdErdzHtZTtBnLTWDlZsSB1nS4fKxf4oRyAqzYEYzs4/WpFqHbE g56A== X-Received: by 10.66.17.137 with SMTP id o9mr11129956pad.142.1370803568035; Sun, 09 Jun 2013 11:46:08 -0700 (PDT) Received: from [192.168.20.5] (c-98-203-241-95.hsd1.wa.comcast.net. [98.203.241.95]) by mx.google.com with ESMTPSA id p2sm12252558pag.22.2013.06.09.11.46.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Jun 2013 11:46:07 -0700 (PDT) Subject: Re: Mellanox NIC names changed, each kldunload/kldload mlx4ib module Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <64DAB3164E410447932305F50F896D8D6AF6D2E6@MTLDAG01.mtl.com> Date: Sun, 9 Jun 2013 11:46:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03D4440E-2D1D-497C-B084-CAB47DE5F880@gmail.com> References: <64DAB3164E410447932305F50F896D8D6AF6D2E6@MTLDAG01.mtl.com> To: Alex Liptsin X-Mailer: Apple Mail (2.1283) Cc: "freebsd-infiniband@freebsd.org" , Regev Lev , "freebsd-questions@freebsd.org" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 09 Jun 2013 18:46:08 -0000 On Jun 9, 2013, at 5:35 AM, Alex Liptsin wrote: > Hi. >=20 > I work with FreeBSD9.1 and Mellanox devices. > Every time I unload / load mlx4ib module, NIC names of mellanox = devices (ibX) are renamed. > Can I prevent it? >=20 > [root@h-qa-032 mlx4]# ifconfig > ib8: flags=3D8002 metric 0 mtu 65520 > options=3D80018 > lladdr 80.28.0.48.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.31 > nd6 options=3D29 > ib9: flags=3D8002 metric 0 mtu 65520 > options=3D80018 > lladdr 80.28.0.49.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.32 > nd6 options=3D29 >=20 > [root@h-qa-032 mlx4]# kldunload mlx4ib >=20 > [root@h-qa-032 mlx4]# kldload -v mlx4ib > Loaded mlx4ib, id=3D9 >=20 > [root@h-qa-032 mlx4]# ifconfig > ib10: flags=3D8002 metric 0 mtu 65520 > options=3D80018 > lladdr 80.30.0.48.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.31 > nd6 options=3D29 > ib11: flags=3D8002 metric 0 mtu 65520 > options=3D80018 > lladdr 80.30.0.49.fe.80.0.0.0.0.0.0.0.2.c9.3.0.2e.48.32 > nd6 options=3D29 You're probably running into a driver bug because OFED/ipoib was = never meant to be unloaded (assuming you're using my sources). Check the = detach/destroy routines to make sure that it's properly detaching = everything and updating indexes in the network stack before it unloads = the driver. Cheers, -Garrett From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 00:21:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA0A310C; Mon, 10 Jun 2013 00:21:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id 819EF10D2; Mon, 10 Jun 2013 00:21:47 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id l18so1993208qak.2 for ; Sun, 09 Jun 2013 17:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AWopmOixK22q9MMKzhBqo+X3BVP177yqKbnTFmKoDpo=; b=I3F5mxx7xdweua2cJLTECyEPf6ns740IkQ/CJEj3ttc3BsFZZZaTNeNgVKkuh0T4B+ g/tOV5LAnD2EbGPPk0Vz9l95tSDxxQLJ8t85BsxjekeFW88I+eAD7Ivubyod1yAdh8IB AlG0Xb2ea3FrMzBws0JCMSs77hTZU8ymNP+QgPVtNCzzrvhRsuRYaNC3+DsarKYU6xKb FDxlod1C9jz2GzUv9yz1fd9wyhLPjClS5wNavtNlcHjtXdcdJuy9xeQqW9PiabUf92yz iEOHNpuz/6zICKGjIhFZNMt5nCSXrgkwuSb4RHXETFm9xgoachs1AC69lv6PjKown10j giuA== MIME-Version: 1.0 X-Received: by 10.224.184.196 with SMTP id cl4mr11716630qab.65.1370823706866; Sun, 09 Jun 2013 17:21:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.5.65 with HTTP; Sun, 9 Jun 2013 17:21:46 -0700 (PDT) In-Reply-To: <51B4C433.9010702@gmail.com> References: <51B4C433.9010702@gmail.com> Date: Sun, 9 Jun 2013 17:21:46 -0700 X-Google-Sender-Auth: T1a9S4xdEVwYkKQiNImG_7qQzW0 Message-ID: Subject: Re: kldstat doesn't show ath_hal [AR2425] From: Adrian Chadd To: Alexander Kapshuk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 00:21:47 -0000 Hi, The ath driver right doesn't (currently!) build a separate HAL and ath driver module. It's something I plan on doing sometime soon as part of the embedded MIPS board support though. Anyway, it probed/attached. The AR2425 is just a different bus variant of the AR2424. So it's detected fine. Now, why it isn't working - I'm not sure. Compile it up with ATH_DEBUG, AH_DEBUG nad ATH_DIAGAPI in your kernel config file, then compile up tools/ath/ath/athstats/ and run it for me. Adrian On 9 June 2013 11:06, Alexander Kapshuk wrote: > I've got an Atheros card, AR2425, which is supposed to be supported by > ath_hal(4), according to the man page. > > dmesg|grep -i Ath > ath0: mem 0xd6000000-0xd600ffff irq 16 at device 0.0 on > pci2 > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > I can see that ath_hal is listed in the kernel config file: > > egrep 'ath_|wlan_' GENERIC > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device wlan_amrr # AMRR transmit rate control algorithm > device ath_pci # Atheros pci/cardbus glue > device ath_hal # pci/cardbus chip support > device ath_rate_sample # SampleRate tx rate control for ath > > kldstat doesn't show ath_hal as having been loaded. Is that normal? > > kldstat -v|egrep 'wlan|ath_' > 98 pci/ath_pci > 434 wlan > 433 wlan_wep > 432 wlan_tkip > 431 wlan_ccmp > 430 wlan_amrr > 436 wlan_sta 435 wlan_ratectl_none > > Long story short, I can't seem to be able to configure my wireless, despite > following the instructions given in the handbook. > > Here's my /etc/rc.conf: > cat /etc/rc.conf > hostname="box0" > sshd_enable="YES" > moused_enable="YES" > ntpd_enable="YES" > powerd_enable="YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev="AUTO" > wlans_ath0="wlan0" > ifconfig_wlan0="ssid plan9 WPA DHCP" > hald_enable="YES" > dbus_enable="YES" > linux_enable="YES" > ifconfig_re0="DHCP" > > And my /etc/wpa_supplicant.conf: > cat /etc/wpa_supplicant.conf > ctrl_interface=/var/run/wpa_supplicant > eapol_version=2 > ap_scan=1 > fast_reauth=1 > > network={ > ssid="plan9" > psk=wpa_passphrase-generated psk > } > ifconfig -a > ath0: flags=8843 metric 0 mtu 2290 > ether 00:24:2c:5e:06:f2 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > re0: flags=8843 metric 0 mtu 1500 > options=8209b > ether 00:23:8b:b2:e5:1f > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:24:2c:5e:06:f2 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid plan9 channel 1 (2412 MHz 11g) > regdomain 103 indoor ecm authmode WPA1+WPA2/802.11i privacy OFF > txpower 20 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle > 250 > roam:rssi 7 roam:rate 5 protmode CTS wme burst roaming MANUAL > > 'ifconfig wlan0 list scan' returns nothing. > uname -a > FreeBSD box0 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 > UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > i386 > > I've tried everything I could think of, still no luck. > > Any pointers would be appreciated. > > Alexander Kapshuk. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Jun 10 02:09:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C403B4EE for ; Mon, 10 Jun 2013 02:09:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 865F315D5 for ; Mon, 10 Jun 2013 02:09:09 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id q12so1008358vbe.13 for ; Sun, 09 Jun 2013 19:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AO723cTmuLy3BGsGd/kDwKIKvA71iDSmmnDgNKupUFE=; b=NdFiHOZIWM92dKahaTNuvd+wmYmpS6PZpdAk2lbCtUWza0Cwz2RAr1BH+AIES+7Kta k8d4n2KIGvhwHHBpsY9UCG+CY2qmkFV35PTwi3quSIr0tvQrnPzSixpemTbKc8wEU73x 1U8bcQrWekvnsA1vXSGnulZCjaoI0rCQI7SAyzJNBvyVKyIZVGfKRIlmwXoN7p8JPgB7 5JAIHp+lnspQde/Lun4clUfpFTbinRFlpeG4VvJ6thlR0a0WX8UjJprGrRXnzebPoso1 XHO/+6smIwzfK32QZ2/9ee6/vnf/aQd0rBkmzwqtv2WLI3LUfM2dHRYM45CXBoD/kz7W E99g== MIME-Version: 1.0 X-Received: by 10.220.45.132 with SMTP id e4mr4498737vcf.13.1370830149015; Sun, 09 Jun 2013 19:09:09 -0700 (PDT) Received: by 10.220.15.194 with HTTP; Sun, 9 Jun 2013 19:09:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Jun 2013 19:09:08 -0700 Message-ID: Subject: Re: Unsupported AFBR-700SDZ SFP+ module with 82598EB 10-Gigabit AF Dual Port Network Connection From: Jack Vogel To: =?ISO-8859-1?B?V2Vp3ywgSvxyZ2Vu?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "spawk@acm.poly.edu" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 02:09:09 -0000 There will be a driver update soon with the way it should be done, it will be in the core driver code and not as here in the shared code. Regards, Jack PS Oh, and the email address should be 'freebsd@intel.com' now rather than freebsdnic, it still ultimately just gets to me however. On Sun, Jun 9, 2013 at 10:42 AM, Wei=DF, J=FCrgen wrot= e: > With the following patch the ixgbe (ix) driver > accepts any SFP. > > > --- ixgbe_phy.c.orig 2012-10-01 18:38:31.000000000 +0200 > +++ ixgbe_phy.c 2012-11-13 16:23:18.650609931 +0100 > @@ -1186,6 +1186,7 @@ > } > > ixgbe_get_device_caps(hw, &enforce_sfp); > + enforce_sfp |=3D IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; > if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) && > !((hw->phy.sfp_type =3D=3D ixgbe_sfp_type_1g_cu_core0= ) || > (hw->phy.sfp_type =3D=3D ixgbe_sfp_type_1g_cu_core1= ) || > > > Regards > > Juergen > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: > +49(6131)39-26407 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Jun 10 02:54:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2D2192B for ; Mon, 10 Jun 2013 02:54:50 +0000 (UTC) (envelope-from cameron@cskk.homeip.net) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id D646E16C9 for ; Mon, 10 Jun 2013 02:54:49 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r5A2slMF001003 for ; Mon, 10 Jun 2013 12:54:47 +1000 Received: from fleet.local (c58-111-137-54.artrmn3.nsw.optusnet.com.au [58.111.137.54]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r5A2sUkW007984; Mon, 10 Jun 2013 12:54:34 +1000 Received: by fleet.local (Postfix, from userid 501) id 5FBEE17EE8FB; Mon, 10 Jun 2013 12:54:30 +1000 (EST) Date: Mon, 10 Jun 2013 12:54:30 +1000 From: Cameron Simpson To: "Eugene M. Zheganin" Subject: Re: carp regression in 9.1 ? Message-ID: <20130610025430.GA96587@cskk.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5146F61E.3040601@norma.perm.ru> User-Agent: Mutt/1.5.21 (2010-09-15) References: <5146F61E.3040601@norma.perm.ru> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=wom5GMh1gUkA:10 a=YHY2GCjW0LAA:10 a=kj9zAlcOel0A:10 a=vrnE16BAAAAA:8 a=ZtCCktOnAAAA:8 a=p0Ne3OfIa3EA:10 a=xpbdh_wkAAAA:8 a=JvhO6gbiIPBkvyUUYV8A:9 a=CjuIK1q_8ugA:10 a=AFDxSQY23i2t3Ran:21 a=RM3kU3RuB6Q1OyE3:21 a=ChdAjXE5lkUvdteQbhpnkQ==:117 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 02:54:50 -0000 On 18Mar2013 17:10, Eugene M. Zheganin wrote: | This is of course up to you to decide, but I feel like I should | encourage you - 10.x isn't that scarry as it seems to be. I also run | it on a production (though my production may be not as harsh as | yours) [...] | At least, after upgrade from 9.1-STABLE to a random -CURRENT I | didn't notice any degradation, only improvements. I had all of your | fears right before the upgrade, none of it became real. I'm looking at putting in a 9.1 FreeBSD as a new firewall soon and have only just discovered this possible CARP regression. Can someone inform me on the following questions: - does simple CARP (one address) work? - if I do not destroy and recreate CARP interfaces, does it work? - if I want to try 10.x, is it enough to build a 10.x kernel and boot that without making changes to userland? The partner firewall is running FreeBSD 8.1 and will be staying that way for a while. Finally, out of interest, does 10.x address a bug I found (but have not yet written up and reported, alas) to do with how CARP chooses the physical interface for its packets? We did some debugging on a longstanding problem we had in January, and it appears that CARP is choosing the physical interface naively: just checking if the CARP address is in the network and not consulting the netmask. It should be doing as the IP routing code does, but it does not. We have a /25 with a smaller subnet of it on our exterior link and another subnet on an internal DMZ; the main LAN runs the wider /25. All perfectly sane, but CARP's choice of interface for a given address is subject to hardware order; leaving aside CARP choosing the wrong iterface outright, the machines are not physically identical and therefore CARP can pick different physical networks on each machine, causing neither side to see the peer and both sides to go MASTER. A cursor read of the carp code later seemed to support what out testing with tcpdump showed. Cheers, -- Cameron Simpson From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 11:06:52 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0563FFE for ; Mon, 10 Jun 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A1EBE1C8F for ; Mon, 10 Jun 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5AB6qgC097039 for ; Mon, 10 Jun 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5AB6qhd097037 for freebsd-net@FreeBSD.org; Mon, 10 Jun 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jun 2013 11:06:52 GMT Message-Id: <201306101106.r5AB6qhd097037@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178116 net [ipfilter] [panic] Kernel panic: general protection fa o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] [ipfilter] drops UDP packets with zero checksu o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipfilter] ipfilter/nat NULL pointer deference p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipfilter] There is no ippool start script/ipfilter ma o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [ipfilter] [rc.d] [patch] No good way to set ipfilter o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipfilter] [patch] ipfilter drops OOW packets under 6. o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipfilter] [patch] wrong behaviour with skip rule insi o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipfilter] [panic] using ipfilter "auth" keyword leads o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipfilter] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipfilter] ipfilter ipnat problem with h323 proxy supp o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipfilter] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipfilter] [ppp] Interactive use of user PPP and ipfil f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 465 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 11:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6940A607 for ; Mon, 10 Jun 2013 11:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5B499108A for ; Mon, 10 Jun 2013 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5ABe0NT006352 for ; Mon, 10 Jun 2013 11:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5ABe03N006351; Mon, 10 Jun 2013 11:40:00 GMT (envelope-from gnats) Date: Mon, 10 Jun 2013 11:40:00 GMT Message-Id: <201306101140.r5ABe03N006351@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Maxim Bourmistrov Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Maxim Bourmistrov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:40:01 -0000 The following reply was made to PR kern/179299; it has been noted by GNATS. From: Maxim Bourmistrov To: bug-followup@FreeBSD.org, sysop@prisjakt.nu Cc: Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver Date: Mon, 10 Jun 2013 13:32:32 +0200 I was able to reproduce this issue on one of two identical machines, but = this is not 100% possible. However I was able to crash this machine, while trying to reproduce, = with the following stack trace. Thus no longer sure if my original problem IS cksum6/tso6 related. Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff805a220c stack pointer =3D 0x28:0xffffff917c839910 frame pointer =3D 0x28:0xffffff917c8399d0 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 (irq283: ix0:que 0) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff80955276 at kdb_backtrace+0x66 #1 0xffffffff8091c5ee at panic+0x1ce #2 0xffffffff80cab720 at trap_fatal+0x290 #3 0xffffffff80caba81 at trap_pfault+0x211 #4 0xffffffff80cac034 at trap+0x344 #5 0xffffffff80c953c3 at calltrap+0x8 #6 0xffffffff805a28e6 at ixgbe_msix_que+0x86 #7 0xffffffff808ed80d at intr_event_execute_handlers+0xfd #8 0xffffffff808eeffe at ithread_loop+0x9e #9 0xffffffff808ea49f at fork_exit+0x11f #10 0xffffffff80c958ee at fork_trampoline+0xe Uptime: 13m13s //maxim= From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 13:31:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D16CDD17; Mon, 10 Jun 2013 13:31:05 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7309B183A; Mon, 10 Jun 2013 13:31:05 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so4013271qej.37 for ; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/oJm3gqQ/csgqtJU5eaTMX0digT6R92GAdV1pWDVQLA=; b=xX/9KLP4LFmCdTMoJZbxpgrzXSQmpRC4ZsEnMfGsAR6r669TSczBOKbZ4Ay78zE1fi UzEonVP3UPhOgY94RjET45NYxE5vQgtRaSnbN9zlKKi0L6E0oMlsbnyVi7gUJFfiaKs7 8A32Vk9DA5Hamqok9eFJjRVJ0pQCD19M9q/HkbTzY8rNXpoQS/zsvxoU8NuBe+K83uEA oRKd/UtK9gAaJHK7zfg+tZ+AMiGXF3iyAn4OZ33FrVEK2N2aIxgLu5UxV9VlfExk0pvu FNkUgdgrXR9r+6r9re2SeKIMSLt3atIGBrMfQXjwh3dU6C+EI62t5qWG+6qB2WQeG93J OClw== MIME-Version: 1.0 X-Received: by 10.229.234.136 with SMTP id kc8mr4011063qcb.44.1370871059276; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 06:30:59 -0700 (PDT) In-Reply-To: <4F344CE4.301@freebsd.org> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 15:30:59 +0200 X-Google-Sender-Auth: 9291DsBy8Kt-LWuiE0SBVyN47Pg Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 13:31:06 -0000 Hello, reviving this old thread since i had time to bring the patch to FreeBSD 10 and unified the whole controlling under ipfw(8) binary. For reminder, the patch located at [1] provides multiple instances for ipfw(4). Basically you can control which interfaces belong to which context/ruleset to make maintaining easier. Also it gives more flexibility in general to ipfw(4) for various scenarios. It works by initializing a context of ipfw(4) and assigning specific interfaces explicitly by administrator to each instance. The context is not lost even on interface destruction and recreation, based on interface name match. Upon entering ipfw(4) processing the configured context/instance for that interface is selected if none no filtering is done. Most of the patch is rather straight forward and only some intrusive changes to ipfw NAT KPI, in kernel implementation is done to remove a global variable referring to the active instance and passing it explicitly. You can create a instance of ipfw by running: ipfw zone 1 create Add a member with ipfw zone 1 madd em0 ipfw zone 1 madd vlan0 Remove members with ipfw zone 1 mdel em0 Also destroy an instance by: ipfw zone 1 destroy All the other operations on ipfw(4) will be the same as before just require the -x $context argument added for each of them. The patch uses all the IP_FW3 option commands to avoid changes in other areas apart ipfw(4) related sources. Any objections on pushing this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 13:36:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1ACB241 for ; Mon, 10 Jun 2013 13:36:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 6A58F1894 for ; Mon, 10 Jun 2013 13:36:37 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id a1so1614640qcx.39 for ; Mon, 10 Jun 2013 06:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=5oyVe/boUocJlDAMrIbDl5WozO7Qsev19x7lskFlRl0=; b=t8KvPPxJSUX1wDY70LuXxCQqfS6NHeQkddcIOi7HIS0MXO5Ln9jQCV6hJzQgn7K0JO W2alzsaujly5B0JsvT738gHbVUioaEL+zv02RgM3mtIZQ2MfBwxaNjDxkDrbhJIwJ0EK Xr9Ax6HgfIsmR5R8acylJ7LiSulFnojMrBj9n34kB5LEgakiXib+ppJPcZW0TWNOzzxe 08DEKcKK5dthDiLLoumSx9UqL/1on50ugLi0eC5YTNCXLdrjBTXPESqZWM2Ih6oxYgpH 9jwxKqox3lwtneh0h5FUb9+IOAFHu0DNR7y4veW3zXzVw/gQP+ixzztroi5m+rjwhNLT 48vQ== MIME-Version: 1.0 X-Received: by 10.229.170.199 with SMTP id e7mr4001938qcz.29.1370871396930; Mon, 10 Jun 2013 06:36:36 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 06:36:36 -0700 (PDT) Date: Mon, 10 Jun 2013 15:36:36 +0200 X-Google-Sender-Auth: n0_IxB0XbzOtQU6VLz2nbDdZPhI Message-ID: Subject: [PATCH] CARP using rw locks and unified timer From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 13:36:37 -0000 Hello, at the location [1] is a patch for making carp(4): - use rw locks - unify the timers in carp to a single one for accuracy and predictability This patch has been tested in pfSense for a long time and recently it has been moved to FreeBSD 10. It also fixed some races and LORs present in the whole stack especially with bridge interfaces. Any objections to merging this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/carp_livelock_fixes.diff -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 13:43:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F21626D2 for ; Mon, 10 Jun 2013 13:43:19 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by mx1.freebsd.org (Postfix) with ESMTP id B90BD18FF for ; Mon, 10 Jun 2013 13:43:19 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id cz11so3965784qeb.8 for ; Mon, 10 Jun 2013 06:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ZF6kmWJVc/FySkeEa13vVOUtJb8J9Vt+1oagKF7fPy8=; b=AQDvxUb+94r8SMDJh6N5SShXwN98e3XbeF8iSLeqGVqSr0OrAeIrzDhaefyFQMirf6 1iD5TFZS9NNSzq9b1SHH2vE49IA+w1SEIOoSIyPNsCK8oO/ea++8tZUw3A2322sdCtgm 383yPbJar2E9GWKXRJSzI3dHZoKJNs5AHEG17rLvJJGfkevhIndp4DxyrvCp1LOADbeS 8KzRzD0gGjkfdK1zX577DvQKRH4ymku3xPTwZKxX3J+ORjseo2bID+sLITOPPNh9fnvT 5LKcBOIG/WPeTdp0pjY0YD2MCyeYMYqxKyahBB1MZmt4XMK6KgvQLt43dK4d/4L71ozW QLrA== MIME-Version: 1.0 X-Received: by 10.224.16.5 with SMTP id m5mr13798293qaa.90.1370871792802; Mon, 10 Jun 2013 06:43:12 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 06:43:12 -0700 (PDT) Date: Mon, 10 Jun 2013 15:43:12 +0200 X-Google-Sender-Auth: M0OOxq-kH4IcYK5hfe1nfyPPpIU Message-ID: Subject: [PATH] ALTQ(9) codel algorithm implementation From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 13:43:20 -0000 Hello, at location [1] can be found a patch for Codel[3] algorithm implementation. Triggered by a mail to the mailing lists[2] of OpenBSD i completed the implementation for FreeBSD. It allows to use codel as the single configured discipline on an interface. Also it can be used as a sub discipline of existing queueing disciplines already present. The work has been tested and confirmed working without issues in pfSense. Any objections on pushing this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/altq_codel.diff [2] http://permalink.gmane.org/gmane.os.openbsd.tech/29745 [3] http://www.bufferbloat.net/projects/codel/wiki -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 13:45:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4D04A61; Mon, 10 Jun 2013 13:45:07 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5B96A192C; Mon, 10 Jun 2013 13:45:07 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id 2so3971540qea.7 for ; Mon, 10 Jun 2013 06:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=yH5TjYWnRpohRBaxsxHWsQDPtZVg717Q6dr45wuzkVM=; b=fbwKbDYq86V3tgOnrkuMAuTFhPYeAHoStRN3qCWNfC2ucik8jAXSs1ZiJ/d4dNCa0i dzXn4Nh5DToISxIOtP57uJ9M3cs+TbwfnO6lXzuFVdtQZE5+feUETQYPsRlRJsvvdwHn 8JgXfggl/LFOtGkPH7fmjyr8DTFHlDIC9PUxxzaLM+SlGIhMb39VjB1TDnF3GDx01UJP XwfPdxX+S0/CCCVkhm4xWkHIbvnBgXuPccs+IuIMF7OmSRjGU+J6Ce2vGg28vFgCns25 NQdKRJtC9KXFOuS63dyP0X5M8+/R4u8rq/NAg6ph6u375YM1M0futVWSMT4WLGnXUXyD IR5A== MIME-Version: 1.0 X-Received: by 10.49.132.69 with SMTP id os5mr10669760qeb.48.1370871901704; Mon, 10 Jun 2013 06:45:01 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 06:45:01 -0700 (PDT) Date: Mon, 10 Jun 2013 15:45:01 +0200 X-Google-Sender-Auth: 2UfEIZXahz9JuLRxz24ESJm1igg Message-ID: Subject: [PATCH] dummynet(4) patch for pf(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net , "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 13:45:07 -0000 Hello, the patch at location [1] implements support for dummynet into pf(4). The patch has been tested and confirmed working without issues into pfSense. Any objections to integrating this into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/dummynet.RELENG_10.diff -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 13:58:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12DC9F83; Mon, 10 Jun 2013 13:58:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id CC5C219CC; Mon, 10 Jun 2013 13:58:20 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 71A8C7300A; Mon, 10 Jun 2013 16:01:17 +0200 (CEST) Date: Mon, 10 Jun 2013 16:01:17 +0200 From: Luigi Rizzo To: Ermal Lu?i Subject: Re: [PATCH] dummynet(4) patch for pf(4) Message-ID: <20130610140117.GA98967@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 13:58:21 -0000 On Mon, Jun 10, 2013 at 03:45:01PM +0200, Ermal Lu?i wrote: > Hello, > > the patch at location [1] implements support for dummynet into pf(4). > > The patch has been tested and confirmed working without issues into pfSense. > > Any objections to integrating this into FreeBSD? for the dummynet/ipfw part i have no objection -- this is only a one-line change to sys/netpfil/ipfw/ip_dn_io.c For the pf part sys/netpfil/pf/pf.c, there are two huge macros PACKET_UNDO_NAT() and PACKET_REDO_NAT() which really look ugly. It would really make sense to change them into functions (they already do some substantial work so the saving of one function call is negligible). There is also some questionable indentation see the calls to m_copyback() in PACKET_REDO_NAT() Some extra braces around if/else blocks would help immensely. cheers luigi > [1] > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/dummynet.RELENG_10.diff > > -- > Ermal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://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 Jun 10 15:01:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E105CEA9; Mon, 10 Jun 2013 15:01:36 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by mx1.freebsd.org (Postfix) with ESMTP id CDC671D57; Mon, 10 Jun 2013 15:01:35 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id 13so3175036lba.16 for ; Mon, 10 Jun 2013 08:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TkAzaGnQ6XPK2bhrnUGfI2WXJV2/Uyin4bnJH/ffcH4=; b=0mJu5c0VnApIAPm3CE10laTnHQ4dgW7HTaU+bcWKTT4gatKYYezR7W2bQIpFi97T90 uZJZuGm+Ar0Wo3UzJcfs46YenWD3DzEYqONLnCJKEItHc8YRrovJg+YrXPTxBbZ1ced+ fZ84Gm1lnh6pbgSjgaAnN129fNBwkUHpsOFB4H9TdQsqbVLAL/3Q8qhc1bjkkhE347f4 HsJqs7mNSvpj8mIweIPP8w3mP2UdNsPLLV49zVNLwvFwRB6gOby7HizlHCmyWqpu1U3y WqTTu73gpal5T+Pisz/+frrwO2QzHtamA1mNfmTli/FF2vdrU/9cEnX7YvDBgubEVLiq Y0Gw== MIME-Version: 1.0 X-Received: by 10.152.4.101 with SMTP id j5mr5177446laj.67.1370876488944; Mon, 10 Jun 2013 08:01:28 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.174.227 with HTTP; Mon, 10 Jun 2013 08:01:28 -0700 (PDT) In-Reply-To: References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 17:01:28 +0200 X-Google-Sender-Auth: UynPmGxCz0DkLZtzZyOr0Rx40Po Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: Luigi Rizzo To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 15:01:37 -0000 On Mon, Jun 10, 2013 at 3:30 PM, Ermal Lu=E7i wrote: > Hello, > > reviving this old thread since i had time to bring the patch to FreeBSD 1= 0 > and unified the whole controlling under ipfw(8) binary. > > For reminder, the patch located at [1] provides multiple instances for > ipfw(4). > Basically you can control which interfaces belong to which context/rulese= t > to make maintaining easier. > > ... > Any objections on pushing this into FreeBSD? > > > [1] > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/= CP_multi_instance_ipfw.diff > > > if i understand well, this has no runtime overhead as the ifp has the index of the context it refers to ? Or you need an additional IPFW_CTX_RLOCK() ? Comments on the control/config path: - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might overflow the temporary buffer when building the list. You compute the length under rlock, release the lock, malloc(), then fill the list without checking if the total size is still correct. This kind of code is terribly boring to write, but essentially you need a bound check in the second loop and possibly retry if you notice that you need more memory. "ipfw show" addresses the problem by failing and requesting the user application to pass a larger buffer. - similarly, how do you guarantee that deleting a context while a packet is under processing does not cause dereferencing a NULL pointer ? cheers luigi while=20 > -- > Ermal > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 15:29:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B4978E3 for ; Mon, 10 Jun 2013 15:29:16 +0000 (UTC) (envelope-from gd@bluecubesystems.com) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8831EBC for ; Mon, 10 Jun 2013 15:29:15 +0000 (UTC) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 8E91C2FDBDE for ; Mon, 10 Jun 2013 11:22:19 -0400 (EDT) Received: from serrano (unknown [196.213.208.10]) by smtp.mxes.net (Postfix) with ESMTPA id 358C722E256 for ; Mon, 10 Jun 2013 11:22:07 -0400 (EDT) X-Recieved: Authenticated email user (SMTP-AUTH) Message-ID: <51B5EF1D.1080204@bluecubesystems.com> Date: Mon, 10 Jun 2013 17:22:05 +0200 From: Gregor Dreijer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Gratuitous ARP increasing mbufs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 15:29:16 -0000 Hi, I am running a system on FreeBSD 9.1-RELEASE. I have a device on the network which is sending gratuitous ARP messages (used by a wireless mesh network for a "bridge-loop avoidance" protocol) every 10 seconds. This causes the mbuf clusters to slowly increase on FreeBSD, until the maximum is reached, which disables the networking. I am running netstat -m to keep track of the mbuf run away / leak. My understanding is that mbufs are allocated to hold these messages, but since they are "replys" they are never used. I am now using ipfw, to drop all ARP messages with the following rule: ipfw add 999 deny layer2 mac-type arp MAC ff:ff:ff:ff:ff:ff ac:86:74:02:8a:ff via vte0 It solves the problem. Luckily there are only offending gratuitous ARP messages from this MAC address, so I don't loose any ARP messages that I would need. I believe this might be a bug in FreeBSD. Shouldn't these gratuitous ARP packets be handled in a more elegant way? The increasing mbufs doesn't seem right. A timeout on these mbufs or a maximum number of mbufs that can be allocated for this type of packet might solve this problem. I just wanted to bring this to the developers attention. Thanks very much, Greg The details of the ARP message are as follows (from Wireshark): No. Time Source Destination Protocol Length Info 2450 4642.007546000 OpenMesh_02:8a:ff Broadcast ARP 60 Gratuitous ARP for 0.0.0.0 (Reply) Frame 2450: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 Ethernet II, Src: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) Address: OpenMesh_02:8a:ff (ac:86:74:02:8a:ff) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (reply/gratuitous ARP) Hardware type: Ethernet (1) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (2) [Is gratuitous: True] Sender MAC address: 43:05:43:05:00:00 (43:05:43:05:00:00) Sender IP address: 0.0.0.0 (0.0.0.0) Target MAC address: ff:43:05:02:a2:0c (ff:43:05:02:a2:0c) Target IP address: 0.0.0.0 (0.0.0.0) From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 16:52:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21FEB632; Mon, 10 Jun 2013 16:52:03 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by mx1.freebsd.org (Postfix) with ESMTP id B35071368; Mon, 10 Jun 2013 16:52:02 +0000 (UTC) Received: by mail-qe0-f48.google.com with SMTP id 2so4185020qea.35 for ; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=26YHp/W4zVGAu7j5J7AtFMQcl2Lzstj0rFpC2qovtjI=; b=Kg29vaHviMWw3DncQHdTHjO4QVCg1Z0LOIYLc9bvsxp95464cSVkHCy7o49KioYmR7 qrPigr5iqAx8+5kd/KS7h8HSibUfGzdl4i46g4aev16zZt4Tm6YYc+1nv/YpkCe+scNh eZs42IhXWi0PTUf+Z4Q7XU6rjUXAUCa45gAj/eQFr9NqwV3FYk35cA5cmkjJAooJ4nFM lR3tl53TfEUMssY23+PCQts53ge8oEYSutRU5u2ajUb69FPB1zM12UMAu5ZvWDwEOy1I x0HdvSHYrOpMaug/JAtv34ZmxKGxwpj/+/yLmFgC9a+vo41YzAPXM92tBISKKuZMZNS1 RZ3Q== MIME-Version: 1.0 X-Received: by 10.229.144.14 with SMTP id x14mr4085767qcu.36.1370883121423; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Mon, 10 Jun 2013 09:52:01 -0700 (PDT) In-Reply-To: References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> Date: Mon, 10 Jun 2013 18:52:01 +0200 X-Google-Sender-Auth: J4_vl2pAQ2S3gdwxfsAffdz3t-c Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 16:52:03 -0000 On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > > > > On Mon, Jun 10, 2013 at 3:30 PM, Ermal Lu=E7i wrote: > >> Hello, >> >> reviving this old thread since i had time to bring the patch to FreeBSD = 10 >> and unified the whole controlling under ipfw(8) binary. >> >> For reminder, the patch located at [1] provides multiple instances for >> ipfw(4). >> Basically you can control which interfaces belong to which context/rules= et >> to make maintaining easier. >> >> > ... > > > >> Any objections on pushing this into FreeBSD? >> >> >> [1] >> >> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0= /CP_multi_instance_ipfw.diff >> >> >> > > if i understand well, this has no runtime overhead as the ifp has > the index of the context it refers to ? > Or you need an additional IPFW_CTX_RLOCK() ? > Theoretically you would need for correctness the read lock. It has never been hit in pfSense hence no further investigation on it has been done. It can be made even a read mostly lock or to prevent the race the write lock of the pfil hooks so no packets are passed through?! > > Comments on the control/config path: > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > overflow the temporary buffer when building the list. You compute > the length under rlock, release the lock, malloc(), then fill the > list without checking if the total size is still correct. > This kind of code is terribly boring to write, but essentially > you need a bound check in the second loop and possibly > retry if you notice that you need more memory. > "ipfw show" addresses the problem by failing and requesting the > user application to pass a larger buffer. > Yeah that probably can be fixed. During implementation it was considered enough rare operation to not justify further thought. > > - similarly, how do you guarantee that deleting a context while > a packet is under processing does not cause dereferencing a > NULL pointer ? > Presently, none, but as i said during instance/context operation a write lock on the pfil hook can be taken? That should prevent the issue altogether and remove the requirement of having to read lock the fast path. If you agree with the above i can redo the patch again with the above changes for review? > cheers > luigi > > while >> -- >> Ermal >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 17:27:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 984419FC; Mon, 10 Jun 2013 17:27:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 555E9173F; Mon, 10 Jun 2013 17:27:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B21167300B; Mon, 10 Jun 2013 19:30:36 +0200 (CEST) Date: Mon, 10 Jun 2013 19:30:36 +0200 From: Luigi Rizzo To: Ermal Lu?i Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <20130610173036.GA916@onelab2.iet.unipi.it> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 17:27:34 -0000 On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: ... > > if i understand well, this has no runtime overhead as the ifp has > > the index of the context it refers to ? > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > Theoretically you would need for correctness the read lock. > It has never been hit in pfSense hence no further investigation on it has > been done. > It can be made even a read mostly lock or to prevent the race the write > lock > of the pfil hooks so no packets are passed through?! adding another lock (even just a read lock) around invocations is undesirable in my opinion. I'd rather check if there is already some other lock which is already held so we can use it to protect the list of contexts. > > Comments on the control/config path: > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > overflow the temporary buffer when building the list. You compute > > the length under rlock, release the lock, malloc(), then fill the > > list without checking if the total size is still correct. > > This kind of code is terribly boring to write, but essentially > > you need a bound check in the second loop and possibly > > retry if you notice that you need more memory. > > "ipfw show" addresses the problem by failing and requesting the > > user application to pass a larger buffer. > > > > Yeah that probably can be fixed. > During implementation it was considered enough rare operation to not > justify further thought. well, unlike the previous problem (locking), this has a very simple fix and no performance implications so there are really no excuses... > If you agree with the above i can redo the patch again with the above > changes for review? i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing comment in the place where the context is being accessed. Or if you can find another lock to recycle, fine. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Jun 10 19:13:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8CC5A4BB; Mon, 10 Jun 2013 19:13:20 +0000 (UTC) (envelope-from clif@eugeneweb.com) Received: from eugeneweb.com (eugeneweb.com [149.20.56.103]) by mx1.freebsd.org (Postfix) with ESMTP id 763431BD2; Mon, 10 Jun 2013 19:13:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeneweb.com (Postfix) with ESMTP id 554E624C042; Mon, 10 Jun 2013 12:13:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at eugeneweb.com Received: from eugeneweb.com ([127.0.0.1]) by localhost (eugeneweb.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y2ppjHOKcGB6; Mon, 10 Jun 2013 12:13:13 -0700 (PDT) Received: from [192.168.0.1] (unknown [71.193.185.189]) by eugeneweb.com (Postfix) with ESMTP id DEDCD31A488; Mon, 10 Jun 2013 12:13:12 -0700 (PDT) Message-ID: <51B62547.5000207@eugeneweb.com> Date: Mon, 10 Jun 2013 12:13:11 -0700 From: "Mr. Clif" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130119 Firefox/10.0.11esrpre Iceape/2.7.12 MIME-Version: 1.0 To: John Baldwin Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <51A6CE52.20501@eugeneweb.com> <20130530051214.GA1530@michelle.cdnetworks.com> <201305300929.31872.jhb@freebsd.org> In-Reply-To: <201305300929.31872.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jun 2013 19:13:20 -0000 Hi John and Pyun, Ok got the new kernel installed and tested. Yes it works! :-) Maybe that will also fix a simular problem with the sun cards (cas[03]), except I don't see a define like that in if_cas.c. Suggestions? Thanks, Clif John Baldwin wrote: > On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote: >> On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote: >>> Sorry for the confusion Pyun, >>> >>> I started looking at it in the context of pfsense, but they rejected my >>> bug report which was understandable because it's an upstream issue. They >>> suggested I resubmit it to you guys if I could reproduce it. So I booted >>> FreeBSD and lo and behold the same two ports failed in exactly the same >> Ok, I'd like to fix that. > Hmmm, the dc(4) driver is using the I/O port BARs rather than the > memory BARs for its registers and this bug seems to be that the dc(4) > device can't properly access its registers on dc0 and dc1 on the > Atom box. The one thing I see is that the BIOS on the Atom box assigns > addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses > conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS > is more careful to avoid these ranges. > > I think the fix is that I need to fix the PCI-PCI bridge to reject these > resource ranges if the ISA enable bit is set in the bridge's control > register. However, for the time being you can change dc(4) to use the > memory BAR instead of the I/O port BAR as a workaround: > > Index: if_dc.c > =================================================================== > --- if_dc.c (revision 251132) > +++ if_dc.c (working copy) > @@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > > -#define DC_USEIOSPACE > +//#define DC_USEIOSPACE > > #include > > > If this fixes it then I can take this PR as a test case for handling the ISA > enable bit in the PCI-PCI bridge code. > From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 00:28:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D0B8215; Tue, 11 Jun 2013 00:28:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id E0AAD1C7E; Tue, 11 Jun 2013 00:28:55 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id ld11so2049858pab.8 for ; Mon, 10 Jun 2013 17:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Lticocb2qNSMIBGi8giouOd8XwHaBcM4oXJKsyCQWGo=; b=HNv5vymutrnJfz9rq9L2VQxItbfMZx8q7j0c8c6OmmDHbWH93vIxmFEP5jRqQ/1cW+ RZeBGi1D42k39MVVkVFjCvK8fbt0+c59cT5nmSp6BlCfbTG4TJ26te/mDewsImeMC1Xh oDKnidiYelAbS2JGdE+dk23AAWE2I9dsmkEeX3htQeEHDXn9bqOXzNh06DTiDOZ6sELd lvVhIu0eg+jY7rhIDrfcdcMnphEt0So/lxKWF/5QnXZo163Wt9U3ufeGjSWGfNYOSnKO Mg4qTQGr903BzyQ0VNJHhI6ylmhjmuH6rZWLjc1zU150Tyinzlfks6KlQ+wkiil6X9Ea awzw== X-Received: by 10.66.169.42 with SMTP id ab10mr11586612pac.14.1370910535697; Mon, 10 Jun 2013 17:28:55 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id z19sm3122243paf.12.2013.06.10.17.28.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 17:28:54 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jun 2013 09:28:48 +0900 From: YongHyeon PYUN Date: Tue, 11 Jun 2013 09:28:48 +0900 To: "Mr. Clif" Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Message-ID: <20130611002848.GA1519@michelle.cdnetworks.com> References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <51A6CE52.20501@eugeneweb.com> <20130530051214.GA1530@michelle.cdnetworks.com> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B62547.5000207@eugeneweb.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:28:56 -0000 On Mon, Jun 10, 2013 at 12:13:11PM -0700, Mr. Clif wrote: > Hi John and Pyun, > > Ok got the new kernel installed and tested. Yes it works! :-) Maybe that Thanks, probably John can fix PCI-PCI bridge code. > will also fix a simular problem with the sun cards (cas[03]), except I > don't see a define like that in if_cas.c. Suggestions? Cassini does not support I/O port BARs so I guess you're seeing different issue. Would you start a new thread that explains cas(4) issues you're suffering from? > > Thanks, > Clif > > > John Baldwin wrote: > >On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote: > >>On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote: > >>>Sorry for the confusion Pyun, > >>> > >>>I started looking at it in the context of pfsense, but they rejected my > >>>bug report which was understandable because it's an upstream issue. They > >>>suggested I resubmit it to you guys if I could reproduce it. So I booted > >>>FreeBSD and lo and behold the same two ports failed in exactly the same > >>Ok, I'd like to fix that. > >Hmmm, the dc(4) driver is using the I/O port BARs rather than the > >memory BARs for its registers and this bug seems to be that the dc(4) > >device can't properly access its registers on dc0 and dc1 on the > >Atom box. The one thing I see is that the BIOS on the Atom box assigns > >addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses > >conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS > >is more careful to avoid these ranges. > > > >I think the fix is that I need to fix the PCI-PCI bridge to reject these > >resource ranges if the ISA enable bit is set in the bridge's control > >register. However, for the time being you can change dc(4) to use the > >memory BAR instead of the I/O port BAR as a workaround: > > > >Index: if_dc.c > >=================================================================== > >--- if_dc.c (revision 251132) > >+++ if_dc.c (working copy) > >@@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$"); > > #include > > #include > > > >-#define DC_USEIOSPACE > >+//#define DC_USEIOSPACE > > > > #include > > > > > >If this fixes it then I can take this PR as a test case for handling the > >ISA > >enable bit in the PCI-PCI bridge code. > > > From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 01:26:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36912531; Tue, 11 Jun 2013 01:26:38 +0000 (UTC) (envelope-from clif@eugeneweb.com) Received: from eugeneweb.com (eugeneweb.com [149.20.56.103]) by mx1.freebsd.org (Postfix) with ESMTP id 16A891EF6; Tue, 11 Jun 2013 01:26:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by eugeneweb.com (Postfix) with ESMTP id 4B69124C101; Mon, 10 Jun 2013 18:26:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at eugeneweb.com Received: from eugeneweb.com ([127.0.0.1]) by localhost (eugeneweb.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eskFwlP49WGe; Mon, 10 Jun 2013 18:26:36 -0700 (PDT) Received: from [192.168.0.1] (unknown [71.193.185.189]) by eugeneweb.com (Postfix) with ESMTP id AEE3A24C0FF; Mon, 10 Jun 2013 18:26:35 -0700 (PDT) Message-ID: <51B67CCA.2010507@eugeneweb.com> Date: Mon, 10 Jun 2013 18:26:34 -0700 From: "Mr. Clif" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130119 Firefox/10.0.11esrpre Iceape/2.7.12 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <51A6CE52.20501@eugeneweb.com> <20130530051214.GA1530@michelle.cdnetworks.com> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> <20130611002848.GA1519@michelle.cdnetworks.com> In-Reply-To: <20130611002848.GA1519@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 01:26:38 -0000 Is there any down side to using that dc fix in pfsense for now? Yes, I would like to have time to submit the cas bug as well. Maybe in the next week but probably by august I hope. ;-) Thanks for your help, Clif YongHyeon PYUN wrote: > On Mon, Jun 10, 2013 at 12:13:11PM -0700, Mr. Clif wrote: >> Hi John and Pyun, >> >> Ok got the new kernel installed and tested. Yes it works! :-) Maybe that > Thanks, probably John can fix PCI-PCI bridge code. > >> will also fix a simular problem with the sun cards (cas[03]), except I >> don't see a define like that in if_cas.c. Suggestions? > Cassini does not support I/O port BARs so I guess you're seeing > different issue. Would you start a new thread that explains cas(4) > issues you're suffering from? > >> Thanks, >> Clif >> >> >> John Baldwin wrote: >>> On Thursday, May 30, 2013 1:12:14 am YongHyeon PYUN wrote: >>>> On Wed, May 29, 2013 at 08:58:10PM -0700, Mr. Clif wrote: >>>>> Sorry for the confusion Pyun, >>>>> >>>>> I started looking at it in the context of pfsense, but they rejected my >>>>> bug report which was understandable because it's an upstream issue. They >>>>> suggested I resubmit it to you guys if I could reproduce it. So I booted >>>>> FreeBSD and lo and behold the same two ports failed in exactly the same >>>> Ok, I'd like to fix that. >>> Hmmm, the dc(4) driver is using the I/O port BARs rather than the >>> memory BARs for its registers and this bug seems to be that the dc(4) >>> device can't properly access its registers on dc0 and dc1 on the >>> Atom box. The one thing I see is that the BIOS on the Atom box assigns >>> addresses in the 0x1100-0x11ff range for dc0 and dc1. Those addresses >>> conflict with ISA I/O aliases for the 0x100-0x1ff range. The Dell BIOS >>> is more careful to avoid these ranges. >>> >>> I think the fix is that I need to fix the PCI-PCI bridge to reject these >>> resource ranges if the ISA enable bit is set in the bridge's control >>> register. However, for the time being you can change dc(4) to use the >>> memory BAR instead of the I/O port BAR as a workaround: >>> >>> Index: if_dc.c >>> =================================================================== >>> --- if_dc.c (revision 251132) >>> +++ if_dc.c (working copy) >>> @@ -128,7 +128,7 @@ __FBSDID("$FreeBSD$"); >>> #include >>> #include >>> >>> -#define DC_USEIOSPACE >>> +//#define DC_USEIOSPACE >>> >>> #include >>> >>> >>> If this fixes it then I can take this PR as a test case for handling the >>> ISA >>> enable bit in the PCI-PCI bridge code. >>> From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 02:27:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4432674B; Tue, 11 Jun 2013 02:27:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 138E41459; Tue, 11 Jun 2013 02:27:42 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id bi5so4997414pad.18 for ; Mon, 10 Jun 2013 19:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YzWsOcwQyVgR4UCLPnhWmNsc07ApTehMnBRLjwgvgpQ=; b=xGkewv/11Go2Bq5r8nhuwJwrgGcTi9sHGOI9vYmtQHUQqZrPSZir8iB/wHzSreKavn U77EALld14/Ew7zKvAg5PTR8wnTEZO1gBl2gEc/zrgG5eORYTjzDmyLwGehhjgY7hDGw zCynOivJ+k60YEqyYkQn9WlPMoUbYw/fowgoWCXIn1lKoLdjMMV5vutccvS5oBhSNxnw BpwQ9BDXwTqwi8RGKEIleSSUgQr15/px5HPoVy/92m3jkOqD++TGJQrlOSluD94yqGXs f0KrHFskRaJmVISTOoxEmjBh5LzhKTPyevbOs7CjLBPur0BxhWwsNhujp6n9bzEPsApI TbHg== X-Received: by 10.66.145.2 with SMTP id sq2mr16344004pab.2.1370917661909; Mon, 10 Jun 2013 19:27:41 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id l4sm12504290pbo.6.2013.06.10.19.27.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Jun 2013 19:27:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jun 2013 11:27:34 +0900 From: YongHyeon PYUN Date: Tue, 11 Jun 2013 11:27:34 +0900 To: "Mr. Clif" Subject: Re: misc/179033: [dc] dc ethernet driver seems to have issues with some multiport card and mother board combinations Message-ID: <20130611022734.GB1519@michelle.cdnetworks.com> References: <201305300113.r4U1DRGp089692@freefall.freebsd.org> <51A6CE52.20501@eugeneweb.com> <20130530051214.GA1530@michelle.cdnetworks.com> <201305300929.31872.jhb@freebsd.org> <51B62547.5000207@eugeneweb.com> <20130611002848.GA1519@michelle.cdnetworks.com> <51B67CCA.2010507@eugeneweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B67CCA.2010507@eugeneweb.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:27:42 -0000 On Mon, Jun 10, 2013 at 06:26:34PM -0700, Mr. Clif wrote: > Is there any down side to using that dc fix in pfsense for now? If dc(4) works as expected there is no reason not to use memory BARs. Generally using memory BARs is more efficient. Many old PCI controllers used to have bugs with memory BARs so driver used safer I/O port BARs. > > Yes, I would like to have time to submit the cas bug as well. Maybe in > the next week but probably by august I hope. ;-) > Ok. > Thanks for your help, > Clif From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 07:05:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80B14736; Tue, 11 Jun 2013 07:05:23 +0000 (UTC) (envelope-from alexl@mellanox.com) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) by mx1.freebsd.org (Postfix) with ESMTP id 3B50B1F71; Tue, 11 Jun 2013 07:05:21 +0000 (UTC) Received: from MTLCAS02.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKUbbMKrrMAf1CZCUEgY8J+pXsyxkqIF38@postini.com; Tue, 11 Jun 2013 07:05:22 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS02.mtl.com ([10.0.8.72]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 10:05:13 +0300 From: Alex Liptsin To: John Baldwin , "freebsd-net@freebsd.org" Subject: RE: How to switch Datgram/Connected mtu modes? Thread-Topic: How to switch Datgram/Connected mtu modes? Thread-Index: Ac5aBjoH5e0b3u1XTvyAlDGQDXzaKQCc1AwAAn3391A= Date: Tue, 11 Jun 2013 07:05:12 +0000 Message-ID: <64DAB3164E410447932305F50F896D8D6AF6DBCA@MTLDAG01.mtl.com> References: <64DAB3164E410447932305F50F896D8D6AF651AD@MTLDAG01.mtl.com> <201305291333.52607.jhb@freebsd.org> In-Reply-To: <201305291333.52607.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oded Shanoon , "freebsd-questions@freebsd.org" , Regev Lev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 07:05:23 -0000 Hi. Yes. There is no such entry. The only way I found is to compile inside the kernel " options IPOIB_CM ". Can I do it manually without compiling the kernel each time I want to switc= h between the modes? Maybe add it somehow to sysctl or loader.conf? =20 Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161=20 Email: alexl@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Isr= ael -----Original Message----- From: John Baldwin [mailto:jhb@freebsd.org]=20 Sent: Wednesday, May 29, 2013 9:17 PM To: freebsd-net@freebsd.org Cc: Alex Liptsin; freebsd-questions@freebsd.org Subject: Re: How to switch Datgram/Connected mtu modes? On Sunday, May 26, 2013 7:43:29 am Alex Liptsin wrote: > Hello. >=20 > I work with FreeBSD 9.1 and Mellanox devices. >=20 > How can I configure MTU in connected mode on FreeBSD 9.1? > In Linux to enable connected mode for interface ib0, I enter: >=20 > echo connected > /sys/class/net/ib0/mode >=20 >=20 >=20 > Switching between CM and UD mode can be done in run time: >=20 > echo datagram > /sys/class/net/ib0/mode sets the mode of ib0 to UD >=20 > echo connected > /sys/class/net/ib0/mode sets the mode ib0 to CM >=20 > There is no such directories at FreeBSD. Wat shall I do? Have you tried looking for dev.ib.0 sysctls? It looks like the OFED bits i= n FreeBSD map Linux sysfs entries to sysctl nodes, but I don't have a box w= ith IB handy to see what it looks like at runtime. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 08:40:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61A98D1D for ; Tue, 11 Jun 2013 08:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 39B0D148F for ; Tue, 11 Jun 2013 08:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5B8e1Nl063193 for ; Tue, 11 Jun 2013 08:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5B8e1YQ063192; Tue, 11 Jun 2013 08:40:01 GMT (envelope-from gnats) Date: Tue, 11 Jun 2013 08:40:01 GMT Message-Id: <201306110840.r5B8e1YQ063192@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Maxim Bourmistrov Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Maxim Bourmistrov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 08:40:02 -0000 The following reply was made to PR kern/179299; it has been noted by GNATS. From: Maxim Bourmistrov To: bug-followup@FreeBSD.org, sysop@prisjakt.nu Cc: Subject: Re: kern/179299: [igb] Intel X540-T2 - unstable driver Date: Tue, 11 Jun 2013 10:36:56 +0200 The card was new, but hardware was broken. Returned. From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 11:57:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FADFC38; Tue, 11 Jun 2013 11:57:35 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id 2DBD51E6A; Tue, 11 Jun 2013 11:57:35 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id l18so2912082qak.9 for ; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kyAft7s/XLwkghxceoOMrG/LivZ91Ijy0yTzIz2gevE=; b=n2/I4dU2N5EHC892PqN3pS90otNwWcem7BeZc8lxjajgiEEvk1ZyRXZsAnR/scPqLw 3Mxl8qCXjWsb+qKbMSB6+lWou8ccWZjBaJ1VgDDkAh9WXw782Z64aAPAWqb0WaKxiUdW lW/6t31LaBUMqmR9MVbjzDfj7MC5WuJzfl57AKipTzjcqYMAE1arg1eix2mAQn7IknyU MsXgv8RVZbfGe7FnxRe5S4hoR4vnrb+Vp/dNo7iFljoS/P1S0pkRxoryU3JRntrqcJ44 /dMEma++XlwKtp/RBBlct6Br6nIEpVZuz/zPAybPbv/2xLSWeotZ49MNiSIud2OvkyW8 DB8g== MIME-Version: 1.0 X-Received: by 10.229.152.4 with SMTP id e4mr5571136qcw.109.1370951854249; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Tue, 11 Jun 2013 04:57:34 -0700 (PDT) In-Reply-To: <20130610173036.GA916@onelab2.iet.unipi.it> References: <20120131110204.GA95472@onelab2.iet.unipi.it> <20120208133559.GK13554@FreeBSD.org> <20120208140921.GM13554@glebius.int.ru> <4F344CE4.301@freebsd.org> <20130610173036.GA916@onelab2.iet.unipi.it> Date: Tue, 11 Jun 2013 13:57:34 +0200 X-Google-Sender-Auth: ZASgw6JHD5aEzelV4cNDSXhKTVI Message-ID: Subject: Re: [PATCH] multiple instances of ipfw(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 11:57:35 -0000 Hello Luigi, On Mon, Jun 10, 2013 at 7:30 PM, Luigi Rizzo wrote: > On Mon, Jun 10, 2013 at 06:52:01PM +0200, Ermal Lu?i wrote: > > On Mon, Jun 10, 2013 at 5:01 PM, Luigi Rizzo wrote: > ... > > > if i understand well, this has no runtime overhead as the ifp has > > > the index of the context it refers to ? > > > Or you need an additional IPFW_CTX_RLOCK() ? > > > > > > > Theoretically you would need for correctness the read lock. > > It has never been hit in pfSense hence no further investigation on it has > > been done. > > It can be made even a read mostly lock or to prevent the race the write > > lock > > of the pfil hooks so no packets are passed through?! > > adding another lock (even just a read lock) around invocations is > undesirable in my opinion. I'd rather check if there is already > some other lock which is already held so we can use it to protect > the list of contexts. > > > > Comments on the control/config path: > > > - in ipfw_ctl(), handling IP_FW_CTX_GET i am worried that you might > > > overflow the temporary buffer when building the list. You compute > > > the length under rlock, release the lock, malloc(), then fill the > > > list without checking if the total size is still correct. > > > This kind of code is terribly boring to write, but essentially > > > you need a bound check in the second loop and possibly > > > retry if you notice that you need more memory. > > > "ipfw show" addresses the problem by failing and requesting the > > > user application to pass a larger buffer. > > > > > > > Yeah that probably can be fixed. > > During implementation it was considered enough rare operation to not > > justify further thought. > > well, unlike the previous problem (locking), this has a very simple fix > and no performance implications so there are really no excuses... > > > If you agree with the above i can redo the patch again with the above > > changes for review? > > i would just be happy with the fix to IP_FW_CTX_GET and a big red flashing > comment in the place where the context is being accessed. > Or if you can find another lock to recycle, fine. > > cheers > luigi > regenerated patch at the same location https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/CP_multi_instance_ipfw.diff I actually changed some more things to provide a more correct implementation. The only thing about this is that manual page and rc scripts need to be changed for this as well. How you propose to handle this? -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 12:50:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4ECA6D5D; Tue, 11 Jun 2013 12:50:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by mx1.freebsd.org (Postfix) with ESMTP id 02D9F1125; Tue, 11 Jun 2013 12:50:36 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id 1so4794932qee.12 for ; Tue, 11 Jun 2013 05:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7iP8K+LxC/tZDkrNaIw8LVNdw1zJ/jDuZRPx28Y4Y1U=; b=gGa3nP9o8QLPTRoBFM5Brp9NQbKH0TCOybdJCG3aUHN0TLCOxJrkwWAyULORgsFcrL nnHC8po7nqRKHeZ6pE2VK1E6DQyoY3A65EHDpPBdqMb/onheXbjlOWMR7vsMbxOHAU7A TjPH4wdTWeeY/3YdBwI2V+w9MOfmxXyMBS0YHjrVu4sls/w2j68v40RqFb+2gOTfH2+4 4CDxBG40j9YHtXEkUlRPHucqEum19RqwgduA9BcM7VCj2u0BasCLy/hDyvFf2fFnJm4r 8TMDaahlTxnCVRJZZJ7mf6YPj1g4y2Mr8JMM2zJNZPUmntdhqXdXnpofBVfPRsg+Yupf S63Q== MIME-Version: 1.0 X-Received: by 10.224.87.130 with SMTP id w2mr464275qal.53.1370955036034; Tue, 11 Jun 2013 05:50:36 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Tue, 11 Jun 2013 05:50:35 -0700 (PDT) In-Reply-To: <20130610140117.GA98967@onelab2.iet.unipi.it> References: <20130610140117.GA98967@onelab2.iet.unipi.it> Date: Tue, 11 Jun 2013 14:50:35 +0200 X-Google-Sender-Auth: MNUVteXUczx9xeo_cW4JWgnF_0w Message-ID: Subject: Re: [PATCH] dummynet(4) patch for pf(4) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:50:37 -0000 Hello, i made the corrections to the patch to make it more readble. Can some other eyes give a look and say if that have anything against it. Patch is at same location. On Mon, Jun 10, 2013 at 4:01 PM, Luigi Rizzo wrote: > On Mon, Jun 10, 2013 at 03:45:01PM +0200, Ermal Lu?i wrote: > > Hello, > > > > the patch at location [1] implements support for dummynet into pf(4). > > > > The patch has been tested and confirmed working without issues into > pfSense. > > > > Any objections to integrating this into FreeBSD? > > for the dummynet/ipfw part i have no objection -- this is only > a one-line change to sys/netpfil/ipfw/ip_dn_io.c > > For the pf part sys/netpfil/pf/pf.c, there are two huge macros > PACKET_UNDO_NAT() and PACKET_REDO_NAT() which really look ugly. > It would really make sense to change them into functions > (they already do some substantial work so the saving of one > function call is negligible). > > There is also some questionable indentation see the calls to > m_copyback() in PACKET_REDO_NAT() > Some extra braces around if/else blocks would help immensely. > > cheers > luigi > > > [1] > > > https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/dummynet.RELENG_10.diff > > > > -- > > Ermal > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 14:32:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FD3464B for ; Tue, 11 Jun 2013 14:32:40 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 284BD17AA for ; Tue, 11 Jun 2013 14:32:40 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id hu16so3015326qab.1 for ; Tue, 11 Jun 2013 07:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=HAJMTte7ug4PVtn90SteVVSHC6UN7URMOn0XkgpVdm4=; b=Vt5s3dJ/luix3Y2SuCTDiUTpyS/sobNOHM7V1JFzfQsVUT+jDfevO9/3JRYKkVyBlX SQdzY9+viF3NhfFEX4ci7hmpMzxED1PkIS6SO74bZ3h2EqK1p/cRQciwLiAqoUY43sFq zyqsET/x9NRx35KeNKgnB3BdksX8KC8ZHqaHududkLyAVBbpGPOvXodHfwfWDkK+7axK CzO4g5/Z4z2a4cziweDHfUrhHzKhCsKz4FgYISS8drjMsnsUGKlNt4LI6B/Wd2LE1SoD 5kQf9mHpLommF2zK1gBJNWVHhJkntBMocRCb8jJVqvuG/5OWiA26Yla9jjjIlCnKUZXa JyEg== MIME-Version: 1.0 X-Received: by 10.49.27.135 with SMTP id t7mr9409543qeg.22.1370961159633; Tue, 11 Jun 2013 07:32:39 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Tue, 11 Jun 2013 07:32:39 -0700 (PDT) Date: Tue, 11 Jun 2013 16:32:39 +0200 X-Google-Sender-Auth: djGyryJgjlEO1-SRLmNTOA8HvWA Message-ID: Subject: [PATCH] stf(4) 6rd implementation From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 14:32:40 -0000 Hello, at location [1] can be found a patch for making stf(4) understand 6rd. It supports variable masks for the ipv4 network as well. The patch has been tested on pfSense. It adds to new option to ifconfig for defining the 6rd border router at ISP. ifconfig $stf stfv4net $ipv4network/$mask ifconfig $stf stfv4br $6rdv4gwip Any reasons for not pushing this change into FreeBSD? [1] https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/stf_6rd.diff -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jun 11 23:13:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 25C2F679 for ; Tue, 11 Jun 2013 23:13:14 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id F395C1331 for ; Tue, 11 Jun 2013 23:13:13 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so7738535ied.14 for ; Tue, 11 Jun 2013 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YS/04UMIN7XimSbloEYlDSaZ/2y0PotEgB5sb4KMdtE=; b=Hpclpse83xGXAMdziu3YRHu/QlUVNKaZzl/NJUzQkWrYCpzqLW2ZtRM2S8H8KdFjWq ArKnm0S5AclbcIX7g7Y88jjc2riX5cI24XYbG61IgL1xetlxQiMxCp/m8MEE9wpwrXq+ sFP3JanlIdi3j+O2RtZhpDriKBXskzx+zCb4AO71rd7fL+LUvxrG6gWJIn3T9x4NLcpG OsfQIqMgcekmTUCg9rT1aS5hyyXCIAXORk0rq3uIo9NJWCqZV15ftgC9zgRLXz9uJeI9 x6v6lBw+DGAeOA9WUG/TD7HBlVb3gvi1pklhq+QuNfgaDoqqKzqHRF2Zu4NK1Afo7GfF c2Rw== MIME-Version: 1.0 X-Received: by 10.50.23.8 with SMTP id i8mr2039516igf.42.1370992393593; Tue, 11 Jun 2013 16:13:13 -0700 (PDT) Received: by 10.50.57.35 with HTTP; Tue, 11 Jun 2013 16:13:13 -0700 (PDT) Date: Tue, 11 Jun 2013 20:13:13 -0300 Message-ID: Subject: Netmap on em(4) newcomer (first steps) From: Eduardo Meyer To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:13:14 -0000 Hello, I would like tro try netmap on em(4) device. Other than comping my kernel with netmap what else I need to setup a "production-like" environment to test it? The scenario is a simple BGP router w/ FreeBSD forwarding packets from em0 to em1 with no NAT, etc. I read something about using a special virtual switch (VALE), is it needed? Or is it for testing scenarios only? I want to try it on 9-STABLE. Thanks! -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Wed Jun 12 07:06:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFDE46B6; Wed, 12 Jun 2013 07:06:56 +0000 (UTC) (envelope-from alexl@mellanox.com) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by mx1.freebsd.org (Postfix) with ESMTP id 448D6147F; Wed, 12 Jun 2013 07:06:54 +0000 (UTC) Received: from MTLCAS02.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKUbgd9Hy0VzjaM3Vz/+xju2KgOwOWJ2ql@postini.com; Wed, 12 Jun 2013 07:06:55 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS02.mtl.com ([10.0.8.72]) with mapi id 14.03.0123.003; Wed, 12 Jun 2013 10:06:26 +0300 From: Alex Liptsin To: "freebsd-infiniband@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-questions@freebsd.org" Subject: Failed to allocate receive buffer problem Thread-Topic: Failed to allocate receive buffer problem Thread-Index: Ac5nO1pW2LKE00ohRUCwnHjcKFM9Mw== Date: Wed, 12 Jun 2013 07:06:26 +0000 Message-ID: <64DAB3164E410447932305F50F896D8D6AF6E2C3@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Oded Shanoon , Regev Lev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jun 2013 07:06:57 -0000 Hi. I have a problem that when running a ping (or any other traffic) over IPoIB= port, Traffic fails after some time. At destination server DMESG I see that errors: Jun 11 14:42:11 h-qa-033 kernel: ib1: failed to allocate receive buffer 253 Jun 11 14:42:12 h-qa-033 kernel: ib1: failed to allocate receive buffer 254 Jun 11 14:42:13 h-qa-033 kernel: ib1: failed to allocate receive buffer 255 Jun 11 14:42:14 h-qa-033 kernel: ib1: failed to allocate receive buffer 0 Jun 11 14:42:15 h-qa-033 kernel: ib1: failed to allocate receive buffer 1 Jun 11 14:42:16 h-qa-033 kernel: ib1: failed to allocate receive buffer 2 Jun 11 14:42:17 h-qa-033 kernel: ib1: failed to allocate receive buffer 3 Jun 11 14:42:18 h-qa-033 kernel: ib1: failed to allocate receive buffer 4 Jun 11 14:42:19 h-qa-033 kernel: ib1: failed to allocate receive buffer 5 Jun 11 14:42:20 h-qa-033 kernel: ib1: failed to allocate receive buffer 6 Jun 11 14:42:21 h-qa-033 kernel: ib1: failed to allocate receive buffer 7 I work with FreeBSD 9.1. Is it a bug or some configuration issues? Thanks. Regards, Alex Liptsin Software Quality Assurance Engineer | Mellanox Technologies Ltd. Office: +972 (74) 7236141 Mobile: +972(54) 7833986 Fax: +972(74) 7236161 Email: alexl@mellanox.com Mellanox, Tel-Hai Industrial Park. Building 7, M.P. Upper Galilee 12100 Isr= ael From owner-freebsd-net@FreeBSD.ORG Wed Jun 12 08:04:02 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C31DD75D; Wed, 12 Jun 2013 08:04:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 460931869; Wed, 12 Jun 2013 08:04:02 +0000 (UTC) Received: from alph.d.allbsd.org (p3086-ipbf906funabasi.chiba.ocn.ne.jp [122.26.46.86]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r5C83h7a065788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 17:03:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r5C83fOc011193; Wed, 12 Jun 2013 17:03:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 12 Jun 2013 17:02:32 +0900 (JST) Message-Id: <20130612.170232.1609178509417950961.hrs@allbsd.org> To: eri@FreeBSD.org Subject: Re: [PATCH] stf(4) 6rd implementation From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jun_12_17_02_32_2013_963)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 12 Jun 2013 17:03:53 +0900 (JST) X-Spam-Status: No, score=-87.9 required=13.0 tests=CONTENT_TYPE_PRESENT, DIRECTOCNDYN,DYN_PBL,MIMEQENC,ONLY1HOPDIRECT,QENCPTR2,RCVD_IN_PBL, RCVD_IN_RP_RNBL,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jun 2013 08:04:02 -0000 ----Security_Multipart(Wed_Jun_12_17_02_32_2013_963)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ermal Lu=E7i wrote in : er> Hello, er> = er> at location [1] can be found a patch for making stf(4) understand 6= rd. er> It supports variable masks for the ipv4 network as well. er> = er> The patch has been tested on pfSense. er> It adds to new option to ifconfig for defining the 6rd border route= r at ISP. er> = er> ifconfig $stf stfv4net $ipv4network/$mask er> ifconfig $stf stfv4br $6rdv4gwip er> = er> = er> Any reasons for not pushing this change into FreeBSD? I am feeling guilty about not committing the original patch and RFC 5969 part for a long time. I still have uncommitted code for them (similar but some reported security and performance issues and corner cases addressed), I hope if you do not mind my working on it. I will finish it this month. -- Hiroki ----Security_Multipart(Wed_Jun_12_17_02_32_2013_963)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlG4KxgACgkQTyzT2CeTzy0MiACdHI6/YtIn5ab7S6XtbpNnxHvn bc0An3wZoH6tGrNEcWrtvtgJFLwcRG/8 =/4no -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jun_12_17_02_32_2013_963)---- From owner-freebsd-net@FreeBSD.ORG Wed Jun 12 17:27:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B3CB454; Wed, 12 Jun 2013 17:27:59 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE8E1209; Wed, 12 Jun 2013 17:27:59 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e10so2892086qcy.41 for ; Wed, 12 Jun 2013 10:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=srSW89Y53okCE+LT4cYFtTCmX1E6cx40u/2C9JrDayA=; b=cY+6uKX49DHcUvPr6d7tBfHgFSdOrsor4ZhgnBDKipefoEV5r97frxQnDQeDwSobBR UUUgNlAdoaVXkKfN7ZmswBh845maqdwLC+ry++2K8Ind1bDE4z1mVs3SyPMwxfWM2emH JEH7ro1ynwDC9wVGzI7wtVpjnA+85A4yukHAdvWHPzZAsum0+9RsM+OnOwhEQiKZwlZg TKGwT17iqNncdLbUJ+bDdwXvsVc4ODJPNzs6+UlZMV+vIaj0CunZewSabJqv9TM1ENkh JbhrtOYui/FFKZwxTGcZpwkgit0ldkvNE5ZtduuQazK1lHmANmbiWexSgEKqUKmbJGDY LQoQ== MIME-Version: 1.0 X-Received: by 10.224.42.195 with SMTP id t3mr24834092qae.44.1371058078562; Wed, 12 Jun 2013 10:27:58 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.51.8 with HTTP; Wed, 12 Jun 2013 10:27:58 -0700 (PDT) In-Reply-To: <20130612.170232.1609178509417950961.hrs@allbsd.org> References: <20130612.170232.1609178509417950961.hrs@allbsd.org> Date: Wed, 12 Jun 2013 19:27:58 +0200 X-Google-Sender-Auth: oO03THuuEaWI22B70_ufihYflTg Message-ID: Subject: Re: [PATCH] stf(4) 6rd implementation From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jun 2013 17:27:59 -0000 On Wed, Jun 12, 2013 at 10:02 AM, Hiroki Sato wrote: > Ermal Lu=E7i wrote > in = : > > er> Hello, > er> > er> at location [1] can be found a patch for making stf(4) understand 6rd= . > er> It supports variable masks for the ipv4 network as well. > er> > er> The patch has been tested on pfSense. > er> It adds to new option to ifconfig for defining the 6rd border router > at ISP. > er> > er> ifconfig $stf stfv4net $ipv4network/$mask > er> ifconfig $stf stfv4br $6rdv4gwip > er> > er> > er> Any reasons for not pushing this change into FreeBSD? > > I am feeling guilty about not committing the original patch and RFC > 5969 part for a long time. I still have uncommitted code for them > (similar but some reported security and performance issues and corner > cases addressed), I hope if you do not mind my working on it. I will > finish it this month. > > -- Hiroki > Your original patch had issues with looping of traffic and this patch also has still some other issues imported from your original implementation. If i would write it from scratch it would been more similar to gif/gre rather than this one. The target was to have it operational. If you feel that you will finish rather soon your implementation than ok for postponing. If you think its better to put this in and than you can push yours even better. Whichever is faster/better. --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Wed Jun 12 19:36:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7E0E6A9 for ; Wed, 12 Jun 2013 19:36:09 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id AF3831D2E for ; Wed, 12 Jun 2013 19:36:09 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so10782550ied.28 for ; Wed, 12 Jun 2013 12:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rQHSp40GibTTZAlUaZgpjxNIqUSoDXzoGtYoJFaEbhM=; b=mREXVA3fUbwOkBtl2TWPpTU09vUFZsAP/YD1njsHwCnDzPDv5YIlaOdrzMEljJHNf3 ecKYQH6aNiCKLeelTQvVk2zfkbJMbJAlmykYG7xSCu7kOpTqlV7FtjJ8efzq7m+jjVtN sqXjfGKqobAb5oMN6PTw8VLKbKOZF5QILx8gW9uIhm+wM/ro2FQZbD7uK0PlFxYl+hXB rMppzhl7yyAVUvZUtxfcMaxr8BxnREKbxv9lv4U06VJIL/zqqHcAp+wjHzOOSecaAtiP 4Zco3h1ySsp0C1jQOw1fm3LhXNrKjWl3f5+co9sygCzAjblm2pm/YDI9e0dvId5XP/kN QluA== MIME-Version: 1.0 X-Received: by 10.50.124.73 with SMTP id mg9mr4076628igb.63.1371065769414; Wed, 12 Jun 2013 12:36:09 -0700 (PDT) Received: by 10.50.57.35 with HTTP; Wed, 12 Jun 2013 12:36:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Jun 2013 16:36:09 -0300 Message-ID: Subject: Re: Netmap on em(4) newcomer (first steps) From: Eduardo Meyer To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Jun 2013 19:36:10 -0000 On Tue, Jun 11, 2013 at 8:13 PM, Eduardo Meyer wrote: > Hello, > > I would like tro try netmap on em(4) device. Other than comping my kernel > with netmap what else I need to setup a "production-like" environment to > test it? > > The scenario is a simple BGP router w/ FreeBSD forwarding packets from em0 > to em1 with no NAT, etc. > > I read something about using a special virtual switch (VALE), is it > needed? Or is it for testing scenarios only? > > I want to try it on 9-STABLE. > OK I have compiled -STABLE with device netmap statically and rebuilt everyting. I have set: dev.netmap.fwd: 1 dev.netmap.verbose: 1 Test topology is simple: HOST1 ---------- GATEWAY --------- HOST2 HOST1 192.168.250.2 HOST2 192.168.251.2 GATEWAY being 192.168.250.1 (em1) and 192.168.251.1 (em2) Tested with iperf and got the sabe rate of bps (800M) and pps (151k) with or without netmap. How should I use pkt-gen in this scenario? HOST1 nor HOST2 are netmap-aware, only the GATEWAY since I want better forwarding performance on the GW itself. CPU usage is quite the same with and without netmap. What am I doing wrong in this scenario? Thanks again. -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Thu Jun 13 12:56:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EE706E5 for ; Thu, 13 Jun 2013 12:56:31 +0000 (UTC) (envelope-from dudu.meyer@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D7FEF1B7B for ; Thu, 13 Jun 2013 12:56:30 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so21009866iea.39 for ; Thu, 13 Jun 2013 05:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tvV0niFm2dATRUSg2WRjqlGVmSMv+T0FTqomgEbJzac=; b=d7hvuYnUf5YJm3LjxMS/BR41pBvap4k3kQtnufUKH1KIqwEAZxlwCMi8XoGAjdiO/I mY/DIGJUXeK6I1Cg11j7Na7fWCYONoh5nw57SNiKMHlaRcTq78n0h83cfqCTaBxEcFQu wDojwNZ17GMA88ixAU7m5NwuK+IzrwL7Ytm6+iFKBHZNLMZyQ5JjChc1Q9kPLP192VT2 6Imq28rhNwQRLyTz9Yzf6Rh/b50aKidmZ4hiCJJBYG1to0hUnmFUgVE2s47wFHTw8J0f kSwR99xLlHhMpp4P1dB22DoOE/oYUqd9mwk7Z6QpTmNy6wHaVd9U7sLT3QAce4z3+KWp pdsQ== MIME-Version: 1.0 X-Received: by 10.50.97.74 with SMTP id dy10mr5447460igb.3.1371128190590; Thu, 13 Jun 2013 05:56:30 -0700 (PDT) Received: by 10.50.57.35 with HTTP; Thu, 13 Jun 2013 05:56:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Jun 2013 09:56:30 -0300 Message-ID: Subject: Re: Netmap on em(4) newcomer (first steps) From: Eduardo Meyer To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jun 2013 12:56:31 -0000 On Wednesday, June 12, 2013, Eduardo Meyer wrote: > > > > On Tue, Jun 11, 2013 at 8:13 PM, Eduardo Meyer > > wrote: > >> Hello, >> >> I would like tro try netmap on em(4) device. Other than comping my kernel >> with netmap what else I need to setup a "production-like" environment to >> test it? >> >> The scenario is a simple BGP router w/ FreeBSD forwarding packets from >> em0 to em1 with no NAT, etc. >> >> I read something about using a special virtual switch (VALE), is it >> needed? Or is it for testing scenarios only? >> >> I want to try it on 9-STABLE. >> > > OK I have compiled -STABLE with device netmap statically and rebuilt > everyting. I have set: > > dev.netmap.fwd: 1 > dev.netmap.verbose: 1 > > Test topology is simple: > > HOST1 ---------- GATEWAY --------- HOST2 > > HOST1 192.168.250.2 > HOST2 192.168.251.2 > > GATEWAY being 192.168.250.1 (em1) and 192.168.251.1 (em2) > > Tested with iperf and got the sabe rate of bps (800M) and pps (151k) with > or without netmap. > > How should I use pkt-gen in this scenario? > > HOST1 nor HOST2 are netmap-aware, only the GATEWAY since I want better > forwarding performance on the GW itself. CPU usage is quite the same with > and without netmap. > > What am I doing wrong in this scenario? > > Thanks again. > Ive read Olivier's (BSDRP) benchs sent to current@ and there seem no particular configuration for packet forwarding. So o dunno what I may be lacking. What and where output netmap verbose is supposed to generate? > > -- =========== Eduardo Meyer pessoal: dudu.meyer@gmail.com profissional: ddm.farmaciap@saude.gov.br From owner-freebsd-net@FreeBSD.ORG Thu Jun 13 14:48:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 085EEF41 for ; Thu, 13 Jun 2013 14:48:54 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id C069910A0 for ; Thu, 13 Jun 2013 14:48:53 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x17so7147350vbf.10 for ; Thu, 13 Jun 2013 07:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=zBfcgtoCf81/5ekQ8e2aZPiNzrgS+5UboAlTAAHrxTM=; b=ynLoTucXVk7M/2RqYFxdF07kswBg3JJkcAY37/5jj40Nzva7bGbUmvlx48lipnpt4H 4bHjTWvGh2t5YWBy3lb2GHOS7gt3FyH/AZIx57cIU0KW7BLaeJ0Eb1Li9sywxW244dcK pKLVkIh7IGymJLB/AqCY3JpDuhgo9mER9lLZRsa4zPxrReamOEEk8he4MpSw7vW+AJn9 YoSvfNTvO5BLaq6xd9aMJC+y8NS/hM1GN/YVgF/YiWHg/vvw6PdG3IqZKLKpQCtE7E51 ucrhKOx76tzCJ/BAojZHVREEXvGVDqcwDSeKKxBhgbCASUhGcCez546yJeXYbncdyRQT 8vDQ== X-Received: by 10.52.249.41 with SMTP id yr9mr429837vdc.17.1371134933275; Thu, 13 Jun 2013 07:48:53 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.204.232 with HTTP; Thu, 13 Jun 2013 07:48:33 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 13 Jun 2013 16:48:33 +0200 X-Google-Sender-Auth: h0V7arQWeE5ot6F4oeuj7E9BR2k Message-ID: Subject: Re: Netmap on em(4) newcomer (first steps) To: Eduardo Meyer Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Jun 2013 14:48:54 -0000 On Thu, Jun 13, 2013 at 2:56 PM, Eduardo Meyer wrote: > Ive read Olivier's (BSDRP) benchs sent to current@ and there seem no > particular configuration for packet forwarding. So o dunno what I may be > lacking. > > What and where output netmap verbose is supposed to generate? > Hi Eduardo, my benchs used netmap as a high-rate packet generator/receiver only: it was not used for forwarding. I've tried to used ipfw-netmap for measuring firewalling (not only forwarding) but didn't reach to used it (all traffic are blocked once I start it). Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 07:40:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C9A943A; Fri, 14 Jun 2013 07:40:31 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 538A91928; Fri, 14 Jun 2013 07:40:31 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id tj12so392507pac.40 for ; Fri, 14 Jun 2013 00:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8S2D9R5aidfMwe7Mxtbdm9pv5Ox9883Q+FNSjaWtYPQ=; b=HKKP3upjdqr0OfrrYC0fDHhcgfsWRPBRYdpHXdFhei+CT5lqJD53DIv+YxlG3b4W/0 s5Hra27opm5/pZqsopOEo2H0jFnm6fZqEbVND7oXHDgbgQIordvrm7Ep5agF9BnZkJSS 3eHPMIFfATzN83uv0+BfNMQkV4OGMrmOonkLggsaOuoGRB6/9ZCl5ekl/5QoLDRe/gnP iy9wt18fcpa6kkN75eh8WkrihvOu9+tuV3rbj640h6Y2y/fpj5n+/kfZxYXtGXPLmBJR 6FVh/qbUHAKtR72+uE43SfT5bRepW85cGzdmKxAoZzHW5FZ5O95ofkwm78f2YA3veR3d rA0A== MIME-Version: 1.0 X-Received: by 10.66.4.10 with SMTP id g10mr1310545pag.217.1371195631053; Fri, 14 Jun 2013 00:40:31 -0700 (PDT) Received: by 10.70.100.231 with HTTP; Fri, 14 Jun 2013 00:40:30 -0700 (PDT) Received: by 10.70.100.231 with HTTP; Fri, 14 Jun 2013 00:40:30 -0700 (PDT) In-Reply-To: References: <5146121B.5080608@FreeBSD.org> Date: Fri, 14 Jun 2013 10:40:30 +0300 Message-ID: Subject: Re: MPLS From: Sami Halabi To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 07:40:31 -0000 Hi Alex, Got any progress? I'm excited to test mpls in fbsd :) Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 15 =D7=91=D7=9E=D7=90=D7=99 2013 17:43= , =D7=9E=D7=90=D7=AA "Sami Halabi" : > Hi Alex, > Any progress on mpls fbsd? > > Thanks in advance, > Sami > On Mar 17, 2013 8:57 PM, "Alexander V. Chernikov" > wrote: > >> On 17.03.2013 13:20, Sami Halabi wrote: >> >>> any one? :) >>> >>> >>> On Fri, Mar 15, 2013 at 6:28 PM, Sami Halabi wrote= : >>> >>> Hi, >>>> Are there ongoing job of mpls in freebsd? >>>> I saw thd site http://freebsd.mpls.in for aboug a year now and I don't >>>> see much progress. >>>> >>> Yep. It was frozen for a while. >> Currently I'm working on it again. >> >> control plane code was heavily redesigned, see >> http://bird.mpls.in/projects/**mpls-bird/repository/show?rev=3D**bird_mp= ls >> >> I have some working MPLS code on 8-S and I hope to create freebsd svn >> branch with base MPLS support in 2-3 weeks. >> >> ITOH OpenBSD has a complete implementation of MPLS out of the box, mayb= e >>>> >>> Their control plane code is mostly useless due to design approach >> (routing daemons talk via kernel). >> Their data plane code, well.. Yes, we can use some defines from their >> headers, but that's all :) >> >>> porting it would be short and more straight forward than porting linux >>>> LDP >>>> implementation of BIRD. >>>> >>> It is not 'linux' implementation. LDP itself is cross-platform. >> The most tricky place here is control plane. >> However, making _fast_ MPLS switching is tricky too, since it requires >> chages in our netisr/ethernet handling code. >> >>> >>>> Thanks in advance, >>>> Sami >>>> >>>> >>> >>> >>> >> From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 09:20:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 08BC268E; Fri, 14 Jun 2013 09:20:11 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 88DD41078; Fri, 14 Jun 2013 09:20:09 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5E9Jrvp028069; Fri, 14 Jun 2013 13:19:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5E9JriJ028068; Fri, 14 Jun 2013 13:19:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Jun 2013 13:19:53 +0400 From: Gleb Smirnoff To: Ermal Lu?i Subject: Re: [PATCH] CARP using rw locks and unified timer Message-ID: <20130614091953.GP12443@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 09:20:11 -0000 Ermal, On Mon, Jun 10, 2013 at 03:36:36PM +0200, Ermal Lu?i wrote: E> at the location [1] is a patch for making carp(4): E> - use rw locks E> - unify the timers in carp to a single one for accuracy and predictability Actually patch does a lot more than these two points. E> This patch has been tested in pfSense for a long time and recently it has E> been moved to FreeBSD 10. E> It also fixed some races and LORs present in the whole stack especially E> with bridge interfaces. Can you please explain the races the patch is fixing? Can you please explain LORs, since I don't know any. Also, can you please explain reason for multiple (sc->sc_carpdev != NULL) checks added? At which circumstances this could happen? The reason for rwlock convertion should also be explained. Have you measured any contention on carp mutexes? P.S. The move of carp_version check to the top of carp_input_c() is a good idea and should be committed as a separate change. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 09:51:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F16CF186; Fri, 14 Jun 2013 09:51:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 657DF12BE; Fri, 14 Jun 2013 09:51:26 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5E9pPXE028187; Fri, 14 Jun 2013 13:51:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5E9pPCm028186; Fri, 14 Jun 2013 13:51:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Jun 2013 13:51:25 +0400 From: Gleb Smirnoff To: Ermal Lu?i Subject: Re: [PATH] ALTQ(9) codel algorithm implementation Message-ID: <20130614095125.GQ12443@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 09:51:27 -0000 Ermal, On Mon, Jun 10, 2013 at 03:43:12PM +0200, Ermal Lu?i wrote: E> at location [1] can be found a patch for Codel[3] algorithm implementation. E> E> Triggered by a mail to the mailing lists[2] of OpenBSD i completed the E> implementation for FreeBSD. E> E> It allows to use codel as the single configured discipline on an interface. E> Also it can be used as a sub discipline of existing queueing disciplines E> already present. E> E> The work has been tested and confirmed working without issues in pfSense. E> E> Any objections on pushing this into FreeBSD? E> E> [1] E> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/altq_codel.diff E> [2] http://permalink.gmane.org/gmane.os.openbsd.tech/29745 E> [3] http://www.bufferbloat.net/projects/codel/wiki I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy the ALTQ codel algo, which would definitely have a limited usage among FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into mbuf packet header. Smaller problems noticed: - codel_alloc() doesn't check return from malloc(). And fairq_class_create(), priq_class_create(), rmc_newclass() and hfsc_class_create() don't check return from codel_alloc(). - Need newline before function name in codel_Newton_step(). - Spaces instead of tab in declaration of struct codel_ifstats and struct codel_opts. - Diff chunk to fairq_add_altq() is okay, but is entirely unrelated to overall patch. Should be committed separately and old MALLOC() macro should be removed. Assuming all above is taken into account, IMHO, the patch is okay to be included into FreeBSD. Thanks! Some grumbling: the altq_codel.c is polluted with spl(9) and has a lot of ifdef __NetBSD__, uses legacy u_intXX_t types instead of C99, uses strange macro m_pktlen() and so on. Same thing as the rest of ALTQ code. If someone can mechanically polish altq, that would be nice. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 10:05:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF321B4F; Fri, 14 Jun 2013 10:05:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A5EE813CA; Fri, 14 Jun 2013 10:05:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CF89F7300B; Fri, 14 Jun 2013 12:08:28 +0200 (CEST) Date: Fri, 14 Jun 2013 12:08:28 +0200 From: Luigi Rizzo To: Gleb Smirnoff Subject: Re: [PATH] ALTQ(9) codel algorithm implementation Message-ID: <20130614100828.GA48119@onelab2.iet.unipi.it> References: <20130614095125.GQ12443@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614095125.GQ12443@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ermal Lu?i , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 10:05:26 -0000 On Fri, Jun 14, 2013 at 01:51:25PM +0400, Gleb Smirnoff wrote: > Ermal, ... > I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy > the ALTQ codel algo, which would definitely have a limited usage among > FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into > mbuf packet header. not to take positions one way or the other, but getting and releasing a tag on every packet is going to kill performance. If i remember well, 2-3 years ago at bsdcan there was discussion (and mention of some pending work, jeffr maybe ?) on providing some leading space in the mbuf so one could put there tags (e.g. ipfw and dummynet ones) without having to allocate them. Not sure where is this. The other thing with codel is that it needs a fairly coarse timer resolution (100us..1ms) to work so one might be happy with shorter timestamps (e.g. 4 bytes) if space allows them. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 10:07:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1665DC12; Fri, 14 Jun 2013 10:07:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 979C91471; Fri, 14 Jun 2013 10:07:45 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5EA7iUR028352; Fri, 14 Jun 2013 14:07:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5EA7ir1028351; Fri, 14 Jun 2013 14:07:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Jun 2013 14:07:44 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: [PATH] ALTQ(9) codel algorithm implementation Message-ID: <20130614100744.GS12443@glebius.int.ru> References: <20130614095125.GQ12443@FreeBSD.org> <20130614100828.GA48119@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130614100828.GA48119@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ermal Lu?i , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 10:07:46 -0000 Luigi, On Fri, Jun 14, 2013 at 12:08:28PM +0200, Luigi Rizzo wrote: L> > I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy L> > the ALTQ codel algo, which would definitely have a limited usage among L> > FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into L> > mbuf packet header. L> L> not to take positions one way or the other, but getting and releasing L> a tag on every packet is going to kill performance. Does ALTQ care about performance? L> If i remember well, 2-3 years ago at bsdcan there was discussion L> (and mention of some pending work, jeffr maybe ?) L> on providing some leading space in the mbuf so one could put there L> tags (e.g. ipfw and dummynet ones) without having to allocate them. L> Not sure where is this. I even tried to prototype that. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 11:01:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A27E8981 for ; Fri, 14 Jun 2013 11:01:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0A510ED for ; Fri, 14 Jun 2013 11:01:28 +0000 (UTC) Received: (qmail 8038 invoked from network); 14 Jun 2013 11:30:11 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jun 2013 11:30:11 -0000 Message-ID: <51BAF1BA.8000603@freebsd.org> Date: Fri, 14 Jun 2013 12:34:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: [PATH] ALTQ(9) codel algorithm implementation References: <20130614095125.GQ12443@FreeBSD.org> In-Reply-To: <20130614095125.GQ12443@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ermal Lu?i , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 11:01:29 -0000 On 14.06.2013 11:51, Gleb Smirnoff wrote: > Ermal, > > On Mon, Jun 10, 2013 at 03:43:12PM +0200, Ermal Lu?i wrote: > E> at location [1] can be found a patch for Codel[3] algorithm implementation. > E> > E> Triggered by a mail to the mailing lists[2] of OpenBSD i completed the > E> implementation for FreeBSD. > E> > E> It allows to use codel as the single configured discipline on an interface. > E> Also it can be used as a sub discipline of existing queueing disciplines > E> already present. > E> > E> The work has been tested and confirmed working without issues in pfSense. > E> > E> Any objections on pushing this into FreeBSD? > E> > E> [1] > E> https://github.com/pfsense/pfsense-tools/blob/master/patches/RELENG_10_0/altq_codel.diff > E> [2] http://permalink.gmane.org/gmane.os.openbsd.tech/29745 > E> [3] http://www.bufferbloat.net/projects/codel/wiki > > I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy > the ALTQ codel algo, which would definitely have a limited usage among > FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into > mbuf packet header. Agreed. We don't have space for that in the mbuf header. There's some other fields that may be repurposed though, the header pointer for example which is almost entirely unused. With some updates to the TSO and Checksum offload mechanism I have in the pipeline the "header" field can be easily repurposed. Though I'm against an "obscure" ALTQ mechanism having its own mbuf header field as such. It must be a generic field that can be used by others as well. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 11:04:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65DBFC53; Fri, 14 Jun 2013 11:04:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id CFACC117C; Fri, 14 Jun 2013 11:04:45 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5EAVTXP028490; Fri, 14 Jun 2013 14:31:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5EAVTuN028489; Fri, 14 Jun 2013 14:31:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Jun 2013 14:31:29 +0400 From: Gleb Smirnoff To: Ermal Lu?i Subject: Re: [PATH] ALTQ(9) codel algorithm implementation Message-ID: <20130614103129.GU12443@FreeBSD.org> References: <20130614095125.GQ12443@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130614095125.GQ12443@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 11:04:46 -0000 On Fri, Jun 14, 2013 at 01:51:25PM +0400, Gleb Smirnoff wrote: T> Assuming all above is taken into account, IMHO, the patch is okay to be included T> into FreeBSD. Thanks! P.S. Patch also lacks update to manual pages altq.9 and pf.conf.5. These should be written and committed in one commit with the new functionality. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 11:10:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 501112F6 for ; Fri, 14 Jun 2013 11:10:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 14612129A for ; Fri, 14 Jun 2013 11:10:55 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UnRMd-000ALv-5o for freebsd-net@freebsd.org; Fri, 14 Jun 2013 14:36:15 +0400 Date: Fri, 14 Jun 2013 14:36:15 +0400 From: Slawa Olhovchenkov To: freebsd-net@freebsd.org Subject: IPSec improvement Message-ID: <20130614103615.GQ34554@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 11:10:55 -0000 I am plan to do some improve in IPSec stack: - AES-GCM support (from OpenBSD) - GOST 28147-89 and 34.10-2001 support (by modules) - support for IPSec acceleration in network cards This is somebody interested? From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 13:05:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A82084C; Fri, 14 Jun 2013 13:05:17 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id E00801DFC; Fri, 14 Jun 2013 13:05:16 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id 10so558248pdc.19 for ; Fri, 14 Jun 2013 06:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=meiL3CTzzk1hBDCJdvDeDCUHLru2VN0z7qIZjCWEczo=; b=iRvztNSiG4QJyEdq3o1Sbk+lqbeBTH2Yv9mX+40DdJGuuQ7+sIvMP/OuI2HBtLecKn nwbetsmgHYl3NM70PcpQo1DvHBdVVW790RvlLlIsbnTPY3B3q2dd0hgmVO9td374MVY+ 8m18ksRZTtd/rmQevmRaGuOg1dhiHBEwuh9JopHEnV3oWgMGRHmaVNuhCfZ6axPEItLc fKs30pihqRUqopQ5gjd/EgDPwa4KgEQz6IZnSV8aXQOD1liunu0D9ivBNHiN0YMzhXbP KiQeuIm4hoBW1A6nYk+K9pY7fCHQPM3NMcqHJAcPp+dObZ3sCFrZPRnHjjb30JMI36wV bW7A== MIME-Version: 1.0 X-Received: by 10.68.164.196 with SMTP id ys4mr2466262pbb.170.1371215116405; Fri, 14 Jun 2013 06:05:16 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.56.37 with HTTP; Fri, 14 Jun 2013 06:05:16 -0700 (PDT) In-Reply-To: <51BAF1BA.8000603@freebsd.org> References: <20130614095125.GQ12443@FreeBSD.org> <51BAF1BA.8000603@freebsd.org> Date: Fri, 14 Jun 2013 15:05:16 +0200 X-Google-Sender-Auth: sls5nn1gGVmTtQD89kG9efSiN7w Message-ID: Subject: Re: [PATH] ALTQ(9) codel algorithm implementation From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 13:05:17 -0000 On Fri, Jun 14, 2013 at 12:34 PM, Andre Oppermann wrote: > On 14.06.2013 11:51, Gleb Smirnoff wrote: > >> Ermal, >> >> On Mon, Jun 10, 2013 at 03:43:12PM +0200, Ermal Lu?i wrote: >> E> at location [1] can be found a patch for Codel[3] algorithm >> implementation. >> E> >> E> Triggered by a mail to the mailing lists[2] of OpenBSD i completed the >> E> implementation for FreeBSD. >> E> >> E> It allows to use codel as the single configured discipline on an >> interface. >> E> Also it can be used as a sub discipline of existing queueing >> disciplines >> E> already present. >> E> >> E> The work has been tested and confirmed working without issues in >> pfSense. >> E> >> E> Any objections on pushing this into FreeBSD? >> E> >> E> [1] >> E> https://github.com/pfsense/**pfsense-tools/blob/master/** >> patches/RELENG_10_0/altq_**codel.diff >> E> [2] http://permalink.gmane.org/**gmane.os.openbsd.tech/29745 >> E> [3] http://www.bufferbloat.net/**projects/codel/wiki >> >> I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy >> the ALTQ codel algo, which would definitely have a limited usage among >> FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into >> mbuf packet header. >> > > Agreed. We don't have space for that in the mbuf header. There's some > other > fields that may be repurposed though, the header pointer for example which > is > almost entirely unused. With some updates to the TSO and Checksum offload > mechanism I have in the pipeline the "header" field can be easily > repurposed. > > Though I'm against an "obscure" ALTQ mechanism having its own mbuf header > field > as such. It must be a generic field that can be used by others as well. > > -- > Andre > > Yeah i forgot to clarify that. The initial implementation had the added field in tag of pf but for some reason i did not investigate, and this can be a more deep problem the tag not always made it up to ALTQ. Hence it was put in the mbuf header. I did not find a direct way on why the mbuf tag was lost. Also with codel this does give lots of dropped packet hence i choose this way. I do not like to grow the mbuf tag as well but that was the only consistent way to get this to work reliably. -- Ermal From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 13:14:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33EC7D6D for ; Fri, 14 Jun 2013 13:14:16 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id BB52B1E8A for ; Fri, 14 Jun 2013 13:14:15 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id 0A59227988B; Fri, 14 Jun 2013 15:06:15 +0200 (CEST) Received: by nono (Postfix, from userid 1000) id F30DE20C05; Fri, 14 Jun 2013 15:14:00 +0200 (CEST) Date: Fri, 14 Jun 2013 15:14:00 +0200 From: VANHULLEBUS Yvan To: Slawa Olhovchenkov Subject: Re: IPSec improvement Message-ID: <20130614131400.GA23375@zeninc.net> References: <20130614103615.GQ34554@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614103615.GQ34554@zxy.spb.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 13:14:16 -0000 Hi. On Fri, Jun 14, 2013 at 02:36:15PM +0400, Slawa Olhovchenkov wrote: > I am plan to do some improve in IPSec stack: > > - AES-GCM support (from OpenBSD) Dylan Castine already started to work on that last year (see ML's archives), and we took some time to work together on that. Unfortunately, patch hasn't been commited since, as Dylan needed some more time to do some important cleanups on the code. I'll try to recontact Dylan to see if he could take time to finish that. > - GOST 28147-89 and 34.10-2001 support (by modules) > - support for IPSec acceleration in network cards What kind of acceleration, in which kind of network card ? Are you talking about encryption/authentication done in the network card (or CPUs, or .....), or do you want to use advanced IPsec offloading provided by some chipsets ? Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 13:23:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1DA83E2; Fri, 14 Jun 2013 13:23:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id A447D1F1A; Fri, 14 Jun 2013 13:23:31 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UnTzS-000BxR-9H; Fri, 14 Jun 2013 17:24:30 +0400 Date: Fri, 14 Jun 2013 17:24:30 +0400 From: Slawa Olhovchenkov To: VANHULLEBUS Yvan Subject: Re: IPSec improvement Message-ID: <20130614132430.GS34554@zxy.spb.ru> References: <20130614103615.GQ34554@zxy.spb.ru> <20130614131400.GA23375@zeninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614131400.GA23375@zeninc.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 13:23:32 -0000 On Fri, Jun 14, 2013 at 03:14:00PM +0200, VANHULLEBUS Yvan wrote: > On Fri, Jun 14, 2013 at 02:36:15PM +0400, Slawa Olhovchenkov wrote: > > I am plan to do some improve in IPSec stack: > > > > - AES-GCM support (from OpenBSD) > > Dylan Castine already started to work on that last year (see ML's > archives), and we took some time to work together on that. > > Unfortunately, patch hasn't been commited since, as Dylan needed some > more time to do some important cleanups on the code. > > I'll try to recontact Dylan to see if he could take time to finish > that. OK, you inform about progress in this list? > > - GOST 28147-89 and 34.10-2001 support (by modules) > > - support for IPSec acceleration in network cards > > What kind of acceleration, in which kind of network card ? > > Are you talking about encryption/authentication done in the network > card (or CPUs, or .....), or do you want to use advanced IPsec > offloading provided by some chipsets ? IPSec offloadin (ex. Intel 82599). From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 13:51:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BD4EF26 for ; Fri, 14 Jun 2013 13:51:37 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id EE6891074 for ; Fri, 14 Jun 2013 13:51:36 +0000 (UTC) Received: from nono (nono.zen.inc [192.168.1.95]) by smtp.zeninc.net (smtpd) with ESMTP id CFA2F27988B; Fri, 14 Jun 2013 15:51:35 +0200 (CEST) Received: by nono (Postfix, from userid 1000) id 3185F20BA6; Fri, 14 Jun 2013 15:59:22 +0200 (CEST) Date: Fri, 14 Jun 2013 15:59:22 +0200 From: VANHULLEBUS Yvan To: Slawa Olhovchenkov Subject: Re: IPSec improvement Message-ID: <20130614135921.GB23484@zeninc.net> References: <20130614103615.GQ34554@zxy.spb.ru> <20130614131400.GA23375@zeninc.net> <20130614132430.GS34554@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614132430.GS34554@zxy.spb.ru> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 13:51:37 -0000 On Fri, Jun 14, 2013 at 05:24:30PM +0400, Slawa Olhovchenkov wrote: > On Fri, Jun 14, 2013 at 03:14:00PM +0200, VANHULLEBUS Yvan wrote: > > > On Fri, Jun 14, 2013 at 02:36:15PM +0400, Slawa Olhovchenkov wrote: > > > I am plan to do some improve in IPSec stack: > > > > > > - AES-GCM support (from OpenBSD) > > > > Dylan Castine already started to work on that last year (see ML's > > archives), and we took some time to work together on that. > > > > Unfortunately, patch hasn't been commited since, as Dylan needed some > > more time to do some important cleanups on the code. > > > > I'll try to recontact Dylan to see if he could take time to finish > > that. > > OK, you inform about progress in this list? Yep. Just for information, Dylan also talked about such code last year, but the patch I got were from Riaan Kruger. I just sent him a mail on that subject. The patchset Riaan provided me was working on basic tests. On the benchmark we did, software AES-GCM was faster than software AES-CBC+SHA1, but slower than hardware accelerated AES-CBC+SHA1 (tried with both VIA's Padlock and Intel's AESNI). As AES-CBC / SHA1 acceleration is quite common today, but AES-GCM hardware acceleration is still not so common, AES-GCM may be really interesting only on hardware which provide such acceleration (or in older hardware which provide none of them). We also started to have a look at AES-CTR acceleration (more common than AES-GCM acceleration) to provide a partial hardware work for AES-GCM, and it looks like at least OpenSSL's guys coud implement that, with interesting benchmarks. > > > - GOST 28147-89 and 34.10-2001 support (by modules) > > > - support for IPSec acceleration in network cards > > > > What kind of acceleration, in which kind of network card ? > > > > Are you talking about encryption/authentication done in the network > > card (or CPUs, or .....), or do you want to use advanced IPsec > > offloading provided by some chipsets ? > > IPSec offloadin (ex. Intel 82599). Interesting. Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 14:11:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1288F901; Fri, 14 Jun 2013 14:11:44 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id C83531185; Fri, 14 Jun 2013 14:11:43 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UnUk4-000CY7-Fc; Fri, 14 Jun 2013 18:12:40 +0400 Date: Fri, 14 Jun 2013 18:12:40 +0400 From: Slawa Olhovchenkov To: VANHULLEBUS Yvan Subject: Re: IPSec improvement Message-ID: <20130614141240.GU34554@zxy.spb.ru> References: <20130614103615.GQ34554@zxy.spb.ru> <20130614131400.GA23375@zeninc.net> <20130614132430.GS34554@zxy.spb.ru> <20130614135921.GB23484@zeninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614135921.GB23484@zeninc.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 14:11:44 -0000 On Fri, Jun 14, 2013 at 03:59:22PM +0200, VANHULLEBUS Yvan wrote: > On Fri, Jun 14, 2013 at 05:24:30PM +0400, Slawa Olhovchenkov wrote: > > On Fri, Jun 14, 2013 at 03:14:00PM +0200, VANHULLEBUS Yvan wrote: > > > > > On Fri, Jun 14, 2013 at 02:36:15PM +0400, Slawa Olhovchenkov wrote: > > > > I am plan to do some improve in IPSec stack: > > > > > > > > - AES-GCM support (from OpenBSD) > > > > > > Dylan Castine already started to work on that last year (see ML's > > > archives), and we took some time to work together on that. > > > > > > Unfortunately, patch hasn't been commited since, as Dylan needed some > > > more time to do some important cleanups on the code. > > > > > > I'll try to recontact Dylan to see if he could take time to finish > > > that. > > > > OK, you inform about progress in this list? > > Yep. > > Just for information, Dylan also talked about such code last year, but > the patch I got were from Riaan Kruger. > I just sent him a mail on that subject. > > The patchset Riaan provided me was working on basic tests. > On the benchmark we did, software AES-GCM was faster than software > AES-CBC+SHA1, but slower than hardware accelerated AES-CBC+SHA1 (tried > with both VIA's Padlock and Intel's AESNI). > > As AES-CBC / SHA1 acceleration is quite common today, but AES-GCM > hardware acceleration is still not so common, AES-GCM may be really > interesting only on hardware which provide such acceleration (or in > older hardware which provide none of them). > > We also started to have a look at AES-CTR acceleration (more common > than AES-GCM acceleration) to provide a partial hardware work for > AES-GCM, and it looks like at least OpenSSL's guys coud implement > that, with interesting benchmarks. As I know, AESNI support accelerating AES-GCM https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf > > > > - GOST 28147-89 and 34.10-2001 support (by modules) > > > > - support for IPSec acceleration in network cards > > > > > > What kind of acceleration, in which kind of network card ? > > > > > > Are you talking about encryption/authentication done in the network > > > card (or CPUs, or .....), or do you want to use advanced IPsec > > > offloading provided by some chipsets ? > > > > IPSec offloadin (ex. Intel 82599). > > Interesting. > > > Yvan. From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 15:40:42 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AB68119; Fri, 14 Jun 2013 15:40:42 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 64509171E; Fri, 14 Jun 2013 15:40:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5EFegGt016689; Fri, 14 Jun 2013 15:40:42 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5EFegnV016688; Fri, 14 Jun 2013 15:40:42 GMT (envelope-from ae) Date: Fri, 14 Jun 2013 15:40:42 GMT Message-Id: <201306141540.r5EFegnV016688@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/176596: [firewire] [ip6] Crash with IPv6 and Firewire X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 15:40:42 -0000 Synopsis: [firewire] [ip6] Crash with IPv6 and Firewire Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Fri Jun 14 15:40:18 UTC 2013 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=176596 From owner-freebsd-net@FreeBSD.ORG Fri Jun 14 19:34:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 63A5B6B1; Fri, 14 Jun 2013 19:34:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 253191462; Fri, 14 Jun 2013 19:34:50 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UnZml-000FjL-Oj; Fri, 14 Jun 2013 23:35:47 +0400 Date: Fri, 14 Jun 2013 23:35:47 +0400 From: Slawa Olhovchenkov To: VANHULLEBUS Yvan Subject: Re: IPSec improvement Message-ID: <20130614193547.GA58171@zxy.spb.ru> References: <20130614103615.GQ34554@zxy.spb.ru> <20130614131400.GA23375@zeninc.net> <20130614132430.GS34554@zxy.spb.ru> <20130614135921.GB23484@zeninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614135921.GB23484@zeninc.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Jun 2013 19:34:51 -0000 On Fri, Jun 14, 2013 at 03:59:22PM +0200, VANHULLEBUS Yvan wrote: > > > On Fri, Jun 14, 2013 at 02:36:15PM +0400, Slawa Olhovchenkov wrote: > > > > I am plan to do some improve in IPSec stack: > > > > > > > > - AES-GCM support (from OpenBSD) > > > > > > Dylan Castine already started to work on that last year (see ML's > > > archives), and we took some time to work together on that. > > > > > > Unfortunately, patch hasn't been commited since, as Dylan needed some > > > more time to do some important cleanups on the code. > > > > > > I'll try to recontact Dylan to see if he could take time to finish > > > that. > > > > OK, you inform about progress in this list? > > Yep. > > Just for information, Dylan also talked about such code last year, but > the patch I got were from Riaan Kruger. > I just sent him a mail on that subject. > > The patchset Riaan provided me was working on basic tests. > On the benchmark we did, software AES-GCM was faster than software > AES-CBC+SHA1, but slower than hardware accelerated AES-CBC+SHA1 (tried > with both VIA's Padlock and Intel's AESNI). Can I see this patches? This patches must implement infrastructure for combined algoritms, GOST/GOST R also is combined algoritm. From owner-freebsd-net@FreeBSD.ORG Sat Jun 15 03:05:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 91ABB518; Sat, 15 Jun 2013 03:05:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 66B2315D5; Sat, 15 Jun 2013 03:05:29 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r5F35MA0098643 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 20:05:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51BBD9EC.3090904@freebsd.org> Date: Sat, 15 Jun 2013 11:05:16 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [PATH] ALTQ(9) codel algorithm implementation References: <20130614095125.GQ12443@FreeBSD.org> <20130614100828.GA48119@onelab2.iet.unipi.it> In-Reply-To: <20130614100828.GA48119@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ermal Lu?i , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jun 2013 03:05:30 -0000 On 6/14/13 6:08 PM, Luigi Rizzo wrote: > On Fri, Jun 14, 2013 at 01:51:25PM +0400, Gleb Smirnoff wrote: >> Ermal, > ... >> I'm afraid we can't grow mbuf packet header with 8 bytes just to satisfy >> the ALTQ codel algo, which would definitely have a limited usage among >> FreeBSD users. Thus, "enqueue_time" should go into mbuf_tags(9) not into >> mbuf packet header. in -current there are currently 2 pad bytes as I just grew it by 16 bits and wanted to get it 32 bit aligned. is there something you can do with 2 bytes to make the overhead less than a tag? tags are not as expensive as they seem however (last I checked). > not to take positions one way or the other, but getting and releasing > a tag on every packet is going to kill performance. > > If i remember well, 2-3 years ago at bsdcan there was discussion > (and mention of some pending work, jeffr maybe ?) > on providing some leading space in the mbuf so one could put there > tags (e.g. ipfw and dummynet ones) without having to allocate them. > Not sure where is this. yes we discussed this and nothing came of it but it's still a valid point of discussion. > > The other thing with codel is that it needs a fairly coarse > timer resolution (100us..1ms) to work so one might be happy > with shorter timestamps (e.g. 4 bytes) if space allows them. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sat Jun 15 23:28:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B0F2FAB for ; Sat, 15 Jun 2013 23:28:33 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by mx1.freebsd.org (Postfix) with ESMTP id 160261D95 for ; Sat, 15 Jun 2013 23:28:32 +0000 (UTC) Received: from [186.134.15.116] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UnztU-0004pv-Qi; Sun, 16 Jun 2013 01:28:29 +0200 Message-ID: <51BCF068.9000207@gont.com.ar> Date: Sun, 16 Jun 2013 00:53:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Net Subject: Show multicast groups joined? X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jun 2013 23:28:33 -0000 Folks, What would be the appropriate command to show the IPv6 multicast groups joined by all/each interface? Thanks in advance! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sat Jun 15 23:51:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13B895F6 for ; Sat, 15 Jun 2013 23:51:59 +0000 (UTC) (envelope-from bmah@kitchenlab.org) Received: from ohta.kitchenlab.org (ohta.kitchenlab.org [IPv6:2001:470:1f05:55c::1]) by mx1.freebsd.org (Postfix) with ESMTP id DAF1D1E55 for ; Sat, 15 Jun 2013 23:51:58 +0000 (UTC) Received: from hattori.local (c-98-242-55-150.hsd1.ca.comcast.net [98.242.55.150]) (authenticated bits=0) by ohta.kitchenlab.org (8.14.7/8.14.6) with ESMTP id r5FNpvkg087226 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 15 Jun 2013 16:51:58 -0700 (PDT) (envelope-from bmah@kitchenlab.org) Message-ID: <51BCFE13.7010703@kitchenlab.org> Date: Sat, 15 Jun 2013 16:51:47 -0700 From: "Bruce A. Mah" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Show multicast groups joined? References: <51BCF068.9000207@gont.com.ar> In-Reply-To: <51BCF068.9000207@gont.com.ar> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2HVTAQUAIFQNOROSSBXAI" Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Jun 2013 23:51:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HVTAQUAIFQNOROSSBXAI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Fernando Gont wrote: > What would be the appropriate command to show the IPv6 multicast groups= > joined by all/each interface? Try ifmcstat(8). Bruce. ------enig2HVTAQUAIFQNOROSSBXAI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG8/hMACgkQ2MoxcVugUsOp8gCfUZ80DACWun4Z+yOGOEaUhabz Qq0AoIT6+JnPVdRMrgAhZKHmN2OzV03m =WWCV -----END PGP SIGNATURE----- ------enig2HVTAQUAIFQNOROSSBXAI--