From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 00:06:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 427731FD for ; Sun, 16 Feb 2014 00:06:40 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8D631683 for ; Sun, 16 Feb 2014 00:06:39 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.8/8.14.8) with ESMTP id s1G06RSX037030; Sat, 15 Feb 2014 16:06:27 -0800 (PST) (envelope-from dg@pki2.com) Subject: Re: Recommendations for packet capture From: Dennis Glatting To: George Neville-Neil In-Reply-To: <3D9E8EFA-1EB0-4CA6-B26E-CA87553150E3@neville-neil.com> References: <1392304466.63673.23.camel@btw.pki2.com> <3D9E8EFA-1EB0-4CA6-B26E-CA87553150E3@neville-neil.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 15 Feb 2014 16:06:27 -0800 Message-ID: <1392509187.35612.12.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1G06RSX037030 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: dg@pki2.com Cc: "C. L. Martinez" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 00:06:40 -0000 On Sat, 2014-02-15 at 18:44 -0500, George Neville-Neil wrote: > On Feb 14, 2014, at 2:21 , C. L. Martinez wrote: > > > On Thu, Feb 13, 2014 at 3:14 PM, Dennis Glatting wrote: > >> On Thu, 2014-02-13 at 09:14 +0000, C. L. Martinez wrote: > >>> Hi all, > >>> > >>> I need to setup some FreeBSD (or Linux, it depends) hosts to use as a > >>> packet capture sensors for our infrastrucutre. > >>> > >>> Searching about software that I could use under FreeBSD, I only find > >>> these ones: > >>> > >>> a) daemonlogger > >>> b) streamdb > >>> > >>> For Linux, it seems exits more alternatives. Any suggestions?? > >>> > >>> I need to monitor 1 GiB networks. > >>> > >> > >> I've not (yet) used these: > >> > >> /usr/ports/security/sguil-client > >> /usr/ports/security/sguil-sensor > >> /usr/ports/security/sguil-server > >> > >> > >>> Thanks. > > > > Thanks Dennis, but Sguil is not a packet capture componente. Sguil > > needs daemonlogger to show you captured data. > > I might be a bit confused. Can you just use tcpdump with the appropriate flags > to limit the size and number of files? > > What are you trying to achieve? > Well, I was trying to achive an evaluation of SGuil under FreeBSD but after a couple hours of trying to get the peices to play I surrendered to another day. I assumed the goal here was IPS. -- Dennis Glatting From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 02:32:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 992A6D14 for ; Sun, 16 Feb 2014 02:32:52 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 525DB101E for ; Sun, 16 Feb 2014 02:32:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WErXE-0002KR-Pi for freebsd-net@freebsd.org; Sun, 16 Feb 2014 03:32:48 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Feb 2014 03:32:48 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Feb 2014 03:32:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Kevin Bowling Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? Date: Sat, 15 Feb 2014 19:32:39 -0700 Lines: 28 Message-ID: References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 In-Reply-To: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 02:32:52 -0000 On 2/15/2014 4:43 PM, George Neville-Neil wrote: > > On Feb 15, 2014, at 15:14 , Kevin Bowling wrote: > >> Hi, >> >> I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each node has an Intel X520-DA2 dual port 10gig card. One of the ports on each go to a switch using direct attach coaxial cables. The other port is directly connected between the two nodes (think crossover in twisted pair terminology) again using direct attach coaxial cables. >> >> On both machines, and on both ports (including the "crossover"), the links flap several times per day. >> >> I've pasted the output of lspci -vv and dmesg here: >> https://gist.github.com/kev009/9024442 >> >> There's nothing outstanding about the setup otherwise. I suspected some interaction with the switch initially but the "crossover" has eliminated that suspicion. >> >> It seems the ix driver is not very reliable under common conditions, i.e. https://forums.freebsd.org/viewtopic.php?f=7&t=44570 and a search of this list. Any recommendations or tests? >> > > Can you post (to your gist link) the output of sysctl dev.ix ? Hi George, sysctl info added to gist link. ix0 has been up for around 27 days. ix1 for about 24hrs. Regards, Kevin Bowling From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 09:33:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92D8ED27 for ; Sun, 16 Feb 2014 09:33:37 +0000 (UTC) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 19CCE1D3F for ; Sun, 16 Feb 2014 09:33:37 +0000 (UTC) Received: from [10.66.254.3] (mgmt.nette.pl [193.138.118.12]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 3C605479633; Sun, 16 Feb 2014 10:33:31 +0100 (CET) Message-ID: <530085F3.9020205@frasunek.com> Date: Sun, 16 Feb 2014 10:33:39 +0100 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Eugene Grosbein , "Bjoern A. Zeeb" , freebsd-net@freebsd.org, Mike Tancsa Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> <50039923.2060802@rdtc.ru> In-Reply-To: <50039923.2060802@rdtc.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 09:33:37 -0000 I aplogise for reviving this old thread, but after upgrading from 8.3 to 9.2-RELEASE, I started getting the same panics as in 2011, before Glebius' patches related to Netgraph topology locks. I've seen that Mike reported similar issues in October (http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html). Did you managed to resolve it? This is backtrace from PPPoE AC running mpd5 on FreeBSD 9.2 with IPv6 enabled, with over 300 sessions active. On 8.3 with IPv6 disabled I was able to get uptimes over 1 year. (kgdb) bt #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff80593466 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff80593967 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff8082ba10 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff8082bd71 in trap_pfault (frame=0xffffff8098da9660, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff8082c324 in trap (frame=0xffffff8098da9660) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80815653 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0xffffffff80670f32 in ng_address_hook (here=0x0, item=0xfffffe0061ccac00, hook=0xfffffe002fd0cc00, retaddr=0) at /usr/src/sys/netgraph/ng_base.c:3583 #8 0xffffffff8067a2ea in ng_ppp_link_xmit (node=, item=0xfffffe0061ccac00, proto=49185, linkNum=, plen=0) at /usr/src/sys/netgraph/ng_ppp.c:1348 #9 0xffffffff80672498 in ng_apply_item (node=0xfffffe000c784700, item=0xfffffe0061ccac00, rw=0) at /usr/src/sys/netgraph/ng_base.c:2397 #10 0xffffffff806715f4 in ng_snd_item (item=, flags=2) at /usr/src/sys/netgraph/ng_base.c:2314 #11 0xffffffff8067f990 in ngd_send (so=, flags=, m=0xfffffe005cc4d500, addr=, control=, td=) at /usr/src/sys/netgraph/ng_socket.c:441 #12 0xffffffff80603ea6 in sosend_generic (so=0xfffffe0001d8a000, addr=0xfffffe0055266460, uio=0xffffff8098da9a00, top=0xfffffe005cc4d500, control=0x0, flags=, td=0xfffffe0001baa000) at /usr/src/sys/kern/uipc_socket.c:1367 #13 0xffffffff80607783 in kern_sendit (td=0xfffffe0001baa000, s=6, mp=0xffffff8098da9ad0, flags=0, control=0x0, segflg=) at /usr/src/sys/kern/uipc_syscalls.c:811 #14 0xffffffff80607a3c in sendit (td=0xfffffe0001baa000, s=6, mp=0xffffff8098da9ad0, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:739 #15 0xffffffff80607b2d in sys_sendto (td=, uap=) at /usr/src/sys/kern/uipc_syscalls.c:863 #16 0xffffffff8082b1ba in amd64_syscall (td=0xfffffe0001baa000, traced=0) at subr_syscall.c:135 #17 0xffffffff80815937 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x000000080225adcc in ?? () (kgdb) frame 7 #7 0xffffffff80670f32 in ng_address_hook (here=0x0, item=0xfffffe0061ccac00, hook=0xfffffe002fd0cc00, retaddr=0) at /usr/src/sys/netgraph/ng_base.c:3583 3583 if ((hook == NULL) || NG_HOOK_NOT_VALID(hook) || Current language: auto; currently c (kgdb) print *hook $1 = {hk_name = "\b\000\000\000 \000\000\000\004\000\000\000\001\000\000\000\237\a~\000\003�\0248cmd4\000\000\000", hk_private = 0x0, hk_flags = 0, hk_type = 0, hk_peer = 0x0, hk_node = 0x353e38bf000feeae, hk_hooks = { le_next = 0x74bb3a9000dc7f3, le_prev = 0x0}, hk_rcvmsg = 0, hk_rcvdata = 0, hk_refs = 0} (kgdb) print *hook->hk_hooks->le_next Cannot access memory at address 0x74bb3a9000dc7f3 From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 11:18:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CE2B7D for ; Sun, 16 Feb 2014 11:18:49 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B55C14D0 for ; Sun, 16 Feb 2014 11:18:48 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s1GB2xR9021226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Feb 2014 12:03:00 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mike@sentex.net Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s1GB2tTj016000; Sun, 16 Feb 2014 18:02:55 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <53009ADF.9090707@grosbein.net> Date: Sun, 16 Feb 2014 18:02:55 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Przemyslaw Frasunek Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> <50039923.2060802@rdtc.ru> <530085F3.9020205@frasunek.com> In-Reply-To: <530085F3.9020205@frasunek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 2.7 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: ** Cc: "Bjoern A. Zeeb" , Mike Tancsa , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 11:18:49 -0000 On 16.02.2014 16:33, Przemyslaw Frasunek wrote: > I aplogise for reviving this old thread, but after upgrading from 8.3 to > 9.2-RELEASE, I started getting the same panics as in 2011, before Glebius' > patches related to Netgraph topology locks. > > I've seen that Mike reported similar issues in October > (http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html). > Did you managed to resolve it? > > This is backtrace from PPPoE AC running mpd5 on FreeBSD 9.2 with IPv6 enabled, > with over 300 sessions active. On 8.3 with IPv6 disabled I was able to get > uptimes over 1 year. I decided to not upgrade my 8.4-STABLE mpd servers running rock stable, without IPv6 too. They continue to serve existing user base but for new users we offer IPoE (DHCP) only. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 11:18:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38DF3B7C for ; Sun, 16 Feb 2014 11:18:48 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92D4F14CF for ; Sun, 16 Feb 2014 11:18:47 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s1GB2rvh021222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Feb 2014 12:02:54 +0100 (CET) (envelope-from egrosbein@rdtc.ru) X-Envelope-From: egrosbein@rdtc.ru X-Envelope-To: mike@sentex.net Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s1GB2lQ1015993; Sun, 16 Feb 2014 18:02:47 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <53009AD7.3080401@rdtc.ru> Date: Sun, 16 Feb 2014 18:02:47 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Przemyslaw Frasunek Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> <50039923.2060802@rdtc.ru> <530085F3.9020205@frasunek.com> In-Reply-To: <530085F3.9020205@frasunek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-Report: * 2.7 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * 0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net Cc: "Bjoern A. Zeeb" , Mike Tancsa , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 11:18:48 -0000 On 16.02.2014 16:33, Przemyslaw Frasunek wrote: > I aplogise for reviving this old thread, but after upgrading from 8.3 to > 9.2-RELEASE, I started getting the same panics as in 2011, before Glebius' > patches related to Netgraph topology locks. > > I've seen that Mike reported similar issues in October > (http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html). > Did you managed to resolve it? > > This is backtrace from PPPoE AC running mpd5 on FreeBSD 9.2 with IPv6 enabled, > with over 300 sessions active. On 8.3 with IPv6 disabled I was able to get > uptimes over 1 year. I decided to not upgrade my 8.4-STABLE mpd servers running rock stable, without IPv6 too. They continue to serve existing user base but for new users we offer IPoE (DHCP) only. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 14:48:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84081FDE for ; Sun, 16 Feb 2014 14:48:04 +0000 (UTC) Received: from mail.schmidp.com (mail.schmidp.com [IPv6:2a01:4f8:120:4ffe::9]) by mx1.freebsd.org (Postfix) with ESMTP id 14CE1137F for ; Sun, 16 Feb 2014 14:48:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.schmidp.com (Postfix) with ESMTP id D3DA25801F4 for ; Sun, 16 Feb 2014 15:52:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.schmidp.com Received: from mail.schmidp.com ([127.0.0.1]) by localhost (dna.schmidp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caHIHZB3mnHR for ; Sun, 16 Feb 2014 15:52:16 +0100 (CET) Received: from charlie.lan (chello213047013064.west2.11.vie.surfer.at [213.47.13.64]) by mail.schmidp.com (Postfix) with ESMTPSA id C81795801C2 for ; Sun, 16 Feb 2014 15:52:15 +0100 (CET) From: Philipp Schmid Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: IPSEC transport mode and PF NAT to VIMAGE Jail Message-Id: <37EFF023-E94C-4B81-BE73-B1833EF14C7C@openresearch.com> Date: Sun, 16 Feb 2014 15:47:56 +0100 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 14:48:04 -0000 Hi, I=92m having trouble connecting to a NATted VNET jail from a client that = uses IPsec in transport mode between the client and the server where the = jail is hosted on. The basic setup looks like: Laptop (10.0.1.111) <=97=97=97 IPSec transport mode =97=97=97> = FreeBSD 10 Server (10.0.1.178) On the server I have a bridge called bridge0 that has the IP address = 192.168.1.1 A freebsd 10 jail is running on the server with the IP 192.168.1.2 The server at 10.0.1.178 has NAT configured for 192.168.1.0/24 and = redirects port 548 to 192.168.1.2. What I=92d like to achieve is that the laptop connects is able to = connect to port 548 on the server which is redirected to port 548 in the = jail: Laptop (10.0.1.111) =97=97> 10.0.1.178 port 548 =97=97> NAT =97=97= > 192.168.1.2 port 548 (doesn=92t work) (10.0.1.1.111)$ telnet 10.0.1.178 548 Trying 10.0.1.178... telnet: connect to address 10.0.1.178: Connection refused telnet: Unable to connect to remote host I have this working for clients which do not use IPsec, eg: Other Laptop (10.0.1.248) =97=97> 10.0.1.178 port 548 =97=97> = NAT =97=97> 192.168.1.2 port 548 (DOES work) (10.0.1.248)$ telnet 10.0.1.178 548 Trying 10.0.1.178=85 Connected to 10.0.1.178. Escape character is '^]'. The IPSec tunnel between 10.0.1.111 and 10.0.1.178 is also working = correctly and I can connect to any port on the 10.0.1.178 server from = the 10.0.1.111 client. This is the spd policy on the server: spdadd 10.0.1.178 10.0.1.111 any -P out ipsec = esp/transport//require ah/transport//require; spdadd 10.0.1.111 10.0.1.178 any -P in ipsec = esp/transport//require ah/transport//require;=20 And on the client: spdadd 10.0.1.111 10.0.1.178 any -P out ipsec = esp/transport//require ah/transport//require; spdadd 10.0.1.178 10.0.1.111 any -P in ipsec = esp/transport//require ah/transport//require; Any idea how to get that working? For me it looks like if the packets arriving via IPsec are somehow = passing the firewall and are not processed by pf. I can also connect to any port from the 10.0.1.111 client on 10.0.1.178, = not just the ones I allowed in /etc/pf.conf Thank you, Philipp ------------------------------------- My /etc/pf.conf on the server: # interfaces and ips ext_if=3D"bge0" ext_ip=3D"10.0.1.178" jail_if =3D "bridge0" jailnet =3D $jail_if:network jail_netatalk_ip =3D "192.168.1.2" icmp_types =3D "{ echorep, echoreq, timex, unreach }" # groups admins =3D "{ 10.0.1.111 }" friends =3D "{ 10.0.1.111, 10.0.1.176, 10.0.1.248 }" scrub in all # dont't filter on the loopback devices set skip on lo0 # nat jails set skip on $jail_if nat on $ext_if from $jail_netatalk_ip to !$jailnet -> $ext_ip rdr on $ext_if proto tcp from any to $ext_ip port afpovertcp -> = $jail_netatalk_ip port afpovertcp # base rules block in all pass out all keep state # icmp pass in on $ext_if inet proto icmp from any to $ext_if icmp-type = $icmp_types keep state # mdns multicast pass in on $ext_if proto udp from any to 224.0.0.251/32 port 5353 keep = state # rna pass in inet proto tcp from $admins to $ext_ip port ssh pass in inet proto tcp from $friends to $ext_ip port afpovertcp pass in inet proto udp from $friends to $ext_ip port mdns # netatalk jail pass in inet proto tcp from any to $jail_netatalk_ip port afpovertcp # IPSec pass in proto esp from any to any pass in proto ah from any to any pass in proto ipencap from any to any pass in proto udp from $admins port=3D500 to $ext_ip port=3D500 pass out proto esp from any to any pass out proto ah from any to any pass out proto ipencap from any to any pass out proto udp from $ext_ip port=3D500 to $admins port=3D500= From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 20:38:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E7C321A for ; Sun, 16 Feb 2014 20:38:12 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0A441C68 for ; Sun, 16 Feb 2014 20:38:11 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 71C2721347 for ; Sun, 16 Feb 2014 15:38:08 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Sun, 16 Feb 2014 15:38:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=hhaFupIaMefWgdRzX7t6cRpkU10=; b=AQT RnMGo92r1v1EhCRmgDvTq/y6YACm2tlzzi94oES8OOr0R+1896OPIVW5ePK7/zfZ vuD/KvumnFHHNkBbxJ7v3t9tI4LhtTUio1J9BK2Fk7ZvqBlZW0eZbhXb9Zg5/9Mb beJo5hidtuFCYSfU33zff89Q7+1pLFQZUT76CcCI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 87E221A0EFD; Sun, 16 Feb 2014 15:38:08 -0500 (EST) Message-Id: <1392583088.30857.84104745.7521C62A@webmail.messagingengine.com> X-Sasl-Enc: FIRtwHSESYxWIlkkoaq+RetAwqRW5LaPtKqZCqzZCGya 1392583088 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-e72899be In-Reply-To: References: Subject: Re: Recommendations for packet capture Date: Sun, 16 Feb 2014 14:38:08 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 20:38:12 -0000 Does security/bro or security/snort fit your requirements? From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 20:42:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 146374DF for ; Sun, 16 Feb 2014 20:42:12 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CD9191CEB for ; Sun, 16 Feb 2014 20:42:11 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c896:bb5c:9b2b:52b0]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 81F984AC1C for ; Mon, 17 Feb 2014 00:42:10 +0400 (MSK) Date: Mon, 17 Feb 2014 00:42:07 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1763806559.20140217004207@serebryakov.spb.ru> To: freebsd-net@freebsd.org Subject: Do anyone use amd(8) on -CURRENT or 10.0? Does it crash for you? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:42:12 -0000 Hello, Freebsd-net. I'm trying to use amd(8) with default configuration to have fast and easy access to my NFS server from laptop (in local home network), and it coredumps on 10.0-RELEASE and recent 11.0-CURRENT on amd64 machine. I didn't add any special to configs or maps, but "cd /net//usr/home" crashes it and I got "tiemout" from shell (?). Mounting these shares by hands (with "mount -t nfs")) to directories like "/mnt" works perfectly. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Feb 16 21:15:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C6EB0A; Sun, 16 Feb 2014 21:15:25 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4C771FF1; Sun, 16 Feb 2014 21:15:25 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so14481121pbc.2 for ; Sun, 16 Feb 2014 13:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZYsekKtNY39bNDMmgBTdvv1BLGTwY9Qng2r8V4bKkOc=; b=ZymueXhl6H7nZ9K/4kjuhP2Ha/l9PoBT0cinI+LAs/scX/wmqA0d7YuPv4A8IKwxpV qvn7/H0FMPRkLdAMn6KO6GSUC9fvcnqlqvFU+R5Qlf3hAxzmKmPGUm5IMTY3BEPE5nDM HmZL9H+2OS3yVFAI7FgfgBZYUQeoJ8DyNkpuj19BvoscWZKZehHyifb6bRGNJ0YBbTiY rRcPFygA6MXBV+AD5TouZX49zM936tO1m0C7lNFuWNRhzhctWwh3oUSeFv0aLWSFcZq8 AgsPmAHWmL82v1PmqAFJBYsK4ltrlXoC38R0W5Y0BbHJZly5CiVoH0Fksog7lWQQX6xb DtPw== MIME-Version: 1.0 X-Received: by 10.68.230.137 with SMTP id sy9mr22348429pbc.126.1392585325323; Sun, 16 Feb 2014 13:15:25 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Sun, 16 Feb 2014 13:15:25 -0800 (PST) In-Reply-To: <1392583088.30857.84104745.7521C62A@webmail.messagingengine.com> References: <1392583088.30857.84104745.7521C62A@webmail.messagingengine.com> Date: Sun, 16 Feb 2014 13:15:25 -0800 X-Google-Sender-Auth: IDarrkr3DihjC95zjJDYGfYWgfw Message-ID: Subject: Re: Recommendations for packet capture From: Kevin Oberman To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Feb 2014 21:15:26 -0000 On Sun, Feb 16, 2014 at 12:38 PM, Mark Felder wrote: > Does security/bro or security/snort fit your requirements? > security/bro is an extremely powerful IPS, but it is also fairly complex to configure for a given environment. It was developed under an NSF grant by the International Computer Science Institute at the University of California at Berkeley (http://www.icsi.berkeley.edu/). The BRO community support is at http://bro.org. We used BRO at the job from which I retired last year. It worked extremely well and commercial support from a company founded by some of the developers is now available from Broala (http://www.broala.com). Our experience with the support was very good, but I suspect it was not cheap. (I was not involved with the procurement.) -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 02:59:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C56FE7B4 for ; Mon, 17 Feb 2014 02:59:39 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84E4817F5 for ; Mon, 17 Feb 2014 02:59:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s1H2xZiW093198; Sun, 16 Feb 2014 21:59:36 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <53017B12.9050304@sentex.net> Date: Sun, 16 Feb 2014 21:59:30 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Przemyslaw Frasunek , Eugene Grosbein , "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> <4FFBCA96.3000605@freebsd.lublin.pl> <50032E10.3060607@sentex.net> <65702E3D-9373-4CC7-9CB4-81704EF44ED8@lists.zabbadoz.net> <50039923.2060802@rdtc.ru> <530085F3.9020205@frasunek.com> In-Reply-To: <530085F3.9020205@frasunek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 02:59:39 -0000 On 2/16/2014 4:33 AM, Przemyslaw Frasunek wrote: > I aplogise for reviving this old thread, but after upgrading from 8.3 to > 9.2-RELEASE, I started getting the same panics as in 2011, before Glebius' > patches related to Netgraph topology locks. > > I've seen that Mike reported similar issues in October > (http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html). > Did you managed to resolve it? Hi, I worked around the crash by removing ipv6 from the kernel. The box has been functioning without a crash since then. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 04:05:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F18458F for ; Mon, 17 Feb 2014 04:05:57 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF6610FD for ; Mon, 17 Feb 2014 04:05:57 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:54138 helo=new-host-2.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WFFRr-0007vF-Fi; Sun, 16 Feb 2014 23:04:51 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? From: George Neville-Neil In-Reply-To: Date: Sun, 16 Feb 2014 23:04:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> To: Kevin Bowling X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 04:05:57 -0000 On Feb 15, 2014, at 21:32 , Kevin Bowling = wrote: > On 2/15/2014 4:43 PM, George Neville-Neil wrote: >>=20 >> On Feb 15, 2014, at 15:14 , Kevin Bowling = wrote: >>=20 >>> Hi, >>>=20 >>> I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each = node has an Intel X520-DA2 dual port 10gig card. One of the ports on = each go to a switch using direct attach coaxial cables. The other port = is directly connected between the two nodes (think crossover in twisted = pair terminology) again using direct attach coaxial cables. >>>=20 >>> On both machines, and on both ports (including the "crossover"), the = links flap several times per day. >>>=20 >>> I've pasted the output of lspci -vv and dmesg here: >>> https://gist.github.com/kev009/9024442 >>>=20 >>> There's nothing outstanding about the setup otherwise. I suspected = some interaction with the switch initially but the "crossover" has = eliminated that suspicion. >>>=20 >>> It seems the ix driver is not very reliable under common conditions, = i.e. https://forums.freebsd.org/viewtopic.php?f=3D7&t=3D44570 and a = search of this list. Any recommendations or tests? >>>=20 >>=20 >> Can you post (to your gist link) the output of sysctl dev.ix ? >=20 > Hi George, >=20 > sysctl info added to gist link. ix0 has been up for around 27 days. = ix1 for about 24hrs. >=20 I think this has something to do with it. dev.ix.0.mac_stats.local_faults: 314 dev.ix.0.mac_stats.remote_faults: 41 The device is seeing errors at the MAC layer, which I don=92t think a = driver bug would cause, though there is always the possibility of a misconfiguration = causing flapping. Can you try different cables? When you hook it to the switch does the switch give better diagnostics? = Reading over the Intel 82599 chip manual is not, shall we say, illuminating,=20 "Number of faults in the local MAC. This register is valid only when the = link speed is 10 Gb/s.=94 Best, George From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 10:11:24 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29E94C84 for ; Mon, 17 Feb 2014 10:11:24 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91F0A1C30 for ; Mon, 17 Feb 2014 10:11:23 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so11209428lbv.10 for ; Mon, 17 Feb 2014 02:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=vaGNdY4DcBo9GV0uI1Itd+2h2yE94GfCeJXI3LxH3rU=; b=YJwjJw03eDwtz6kseJGWTCNC24ch6lub4chql7kOTgosjVLqJwBea5y6+8SSzcodLt WkyswFh+zBLm1WQc7yWWuNOREoZ6zeShF090V+hrwYAc+pmtidrDiSo3dAqalJodNCMk ocJLQCMD18pKFzJR/4/vno7HULSEjGpBFT21e3t5uzyphE+zAX5Yt197dPztS8V11Y9/ EtaEg2KAB1/V9iD/TT6dgJ+P8TKcA+U4bPMRB4Opn0M0L9RETU5f0Kkvob1D3qn16sR2 uJWe7/mCMCgt3FcBLEoScmMUBfZudxhl2On1GcXL8ZR0d4qhvFtVucXwolJBoq2LiXm2 RUiw== MIME-Version: 1.0 X-Received: by 10.152.170.135 with SMTP id am7mr16985175lac.23.1392631881554; Mon, 17 Feb 2014 02:11:21 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Mon, 17 Feb 2014 02:11:21 -0800 (PST) Date: Mon, 17 Feb 2014 02:11:21 -0800 X-Google-Sender-Auth: 4YD9EwF2vYXPNMwvp1zscufCU9k Message-ID: Subject: netmap, VALE and netmap pipes From: Luigi Rizzo To: netdev@vger.kernel.org, "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 10:11:24 -0000 Hi, we have recently made a few extensions to netmap/VALE and put various pieces of code on public repositories, so i thought i'd share the pointers. All the code below runs with equal features and performance on FreeBSD and Linux, and we are trying to upstream it in the relevant projects if possible (as an example, QEMU recently added a netmap backend), at which point some of these clone repositories will become unnecessary. See http://info.iet.unipi.it/~luigi/netmap for more details. https://code.google.com/p/netmap/ The latest netmap code for FreeBSD/Linux. It has native support for certain NICs; emulated netmap over unmodified drivers; enhanced parallelism in the VALE switch (20 Mpps/source, scaling up to ~50Mpps); and a new feature called "netmap pipe" that does zero-copy blocking I/O at over 100 Mpps. Other features are the ability to allocate tons of extra netmap buffers, and configurable sharing of memory among NICs, VALE ports and netmap pipes. This increases the opportunity for zero copy operation. The user API is also greatly simplified, with a naming scheme that permits easy access to all types of ports including individual NIC queues. https://code.google.com/p/netmap-libpcap a netmap-enabled version of libpcap. With this, basically any pcap client can read/write traffic at 10+ Mpps, with zerocopy reads and (soon) support for zerocopy writes. Whether applications can cope with these packet rates, of course, is another story. https://code.google.com/p/netmap-click a netmap-enabled version of the Click Modular Router. This code matches the current version of netmap, supporting all features (including netmap pipes). https://code.google.com/p/netmap-ipfw a netmap-enabled, userspace version of the ipfw firewall and dummynet network emulator. This version reaches 7-10 Mpps for filtering and over 2.5 Mpps for emulation. Hope you'll find it useful. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 10:33:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3DDD28A for ; Mon, 17 Feb 2014 10:33:54 +0000 (UTC) Received: from man.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3221DBA for ; Mon, 17 Feb 2014 10:33:54 +0000 (UTC) Received: from man.dat.pl (localhost [127.0.0.1]) by man.dat.pl (Postfix) with ESMTP id 6867ECF1DAA; Mon, 17 Feb 2014 11:27:57 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from man.dat.pl ([127.0.0.1]) by man.dat.pl (man.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pd6GsIQkZV6l; Mon, 17 Feb 2014 11:27:55 +0100 (CET) Received: from [10.0.6.81] (unknown [212.69.68.42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by man.dat.pl (Postfix) with ESMTPSA id AC6ECCEF68E; Mon, 17 Feb 2014 11:27:54 +0100 (CET) Message-ID: <5301E429.3080900@dat.pl> Date: Mon, 17 Feb 2014 11:27:53 +0100 From: Maciej Milewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Philipp Schmid , freebsd-net@freebsd.org Subject: Re: IPSEC transport mode and PF NAT to VIMAGE Jail References: <37EFF023-E94C-4B81-BE73-B1833EF14C7C@openresearch.com> In-Reply-To: <37EFF023-E94C-4B81-BE73-B1833EF14C7C@openresearch.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 10:33:54 -0000 On 16.02.2014 15:47, Philipp Schmid wrote: > Any idea how to get that working? > For me it looks like if the packets arriving via IPsec are somehow passing the firewall and are not processed by pf. > I can also connect to any port from the 10.0.1.111 client on 10.0.1.178, not just the ones I allowed in /etc/pf.conf > > > Thank you, Philipp set skip on /interface/ Skip /all/ PF processing on /interface/. This can be useful on loopback interfaces where filtering, normalization, queueing, etc, are not required. This option can be used multiple times. By default this option is not set. You have: set skip on bridge0 I think that you should fix this first. -- Pozdrawiam, Maciej Milewski From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 11:06:52 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35FBEDA7 for ; Mon, 17 Feb 2014 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20CB511C5 for ; Mon, 17 Feb 2014 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 s1HB6qjp033132 for ; Mon, 17 Feb 2014 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1HB6pkK033130 for freebsd-net@FreeBSD.org; Mon, 17 Feb 2014 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:51 GMT Message-Id: <201402171106.s1HB6pkK033130@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.17 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, 17 Feb 2014 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/185496 net [re] RTL8169 doesn't receive unicast ethernet packets o kern/185427 net [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with o kern/185023 net [tun] Closing tun interface deconfigures IP address o kern/185022 net [tun] ls /dev/tun creates tun interface o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host p kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge 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/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/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/177184 net [bge] [patch] enable wake on lan 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/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na 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/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 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 p 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/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from 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/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/166462 net [gre] gre(4) when using a tunnel source address from c 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 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/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/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/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 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/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/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/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 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/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/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 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/132354 net [nat] Getting some packages to ipnat(8) causes crash 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 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 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 kern/129036 net [ipfw] 'ipfw fwd' does not change outgoing interface n 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/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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: 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] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan 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/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/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 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/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/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/25986 net Socket would hang at LAST_ACK forever. 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 Feb 17 18:56:32 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6061DD4E for ; Mon, 17 Feb 2014 18:56:32 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2009014F2 for ; Mon, 17 Feb 2014 18:56:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 948467300A; Mon, 17 Feb 2014 19:58:32 +0100 (CET) Date: Mon, 17 Feb 2014 19:58:32 +0100 From: Luigi Rizzo To: wishmaster Subject: Re: netmap, VALE and netmap pipes Message-ID: <20140217185832.GB41267@onelab2.iet.unipi.it> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 18:56:32 -0000 On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: > > Thanks, prof. Luigi. > > As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. > > E.g. I have classic router with 2 interfaces igb replace the "vale" ports with "netmap:igb0" and "netmap"igb1" and off you go. make sure you have some way to access the router because at the moment igb0 and igb1 will be disconnected from the host stack (this can be changed but at the moment this is what it does). cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 19:06:33 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21152A9 for ; Mon, 17 Feb 2014 19:06:33 +0000 (UTC) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA9531604 for ; Mon, 17 Feb 2014 19:06:32 +0000 (UTC) Received: from [10.10.2.23] (helo=frv198.fwdcdn.com) by frv190.fwdcdn.com with esmtp ID 1WFT3B-000Fp7-QI for net@freebsd.org; Mon, 17 Feb 2014 20:36:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=AimR2nLEgV9ANzicpKHTSbGlyhi/aMhJg5nzI8sKHLQ=; b=tLYzALhEhJcO2AAOuETXDhW7kY0BeYKt7rqBNNAAjXc8Jlk0G6dPBEggptC0/6f1erd8EQyoE0+Jf8LOFiFg8j8LglO2+FYCXSBYRzN8nzJmY5ecDwrWIJA0Hc1KbiwaIuljgJwUxKDJQQU6SXJM1QCFIZHBJypqFr/2OKKlZJU=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1WFT30-000FjG-Uk for net@freebsd.org; Mon, 17 Feb 2014 20:36:06 +0200 Date: Mon, 17 Feb 2014 20:36:06 +0200 From: wishmaster Subject: Re: netmap, VALE and netmap pipes To: Luigi Rizzo X-Mailer: mail.ukr.net 5.0 Message-Id: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> In-Reply-To: References: MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Mon, 17 Feb 2014 20:36:06 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 19:06:33 -0000 Thanks, prof. Luigi. As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. E.g. I have classic router with 2 interfaces igb >From README-file s f f d [pkt-gen]-->--[valeA]-->--[kipfw]-->--[valeB]-->--[pkt-gen] The commands to run (in separate windows) are ### this is clear # preliminarly, load the netmap module sudo kldload netmap.ko ### what with vale? how i should connect real interfaces to vale switch? # connect the firewall to two vale switches ./kipfw valeA:f valeB:f & ### it's clear # configure ipfw/dummynet ipfw/ipfw show # or other ### with real packets flow i think this is no needed. My mistake? # start the sink pkt-gen -i valeB:d -f rx # start an infinite source pkt-gen -i valeA:s -f tx ### it's clear # plain again with the firewall and enjoy ipfw/ipfw show # or other I think one real small example will be useful for everybody. Thanks for this great tool. -- Cheers, w --- Original message --- From: "Luigi Rizzo" Date: 17 February 2014, 12:17:33 > Hi, > we have recently made a few extensions to netmap/VALE and put various > pieces of code on public repositories, so i thought i'd share the > pointers. All the code below runs with equal features and performance > on FreeBSD and Linux, and we are trying to upstream it in the relevant > projects if possible (as an example, QEMU recently added a netmap backend), > at which point some of these clone repositories will become unnecessary. > > See http://info.iet.unipi.it/~luigi/netmap for more details. > > https://code.google.com/p/netmap/ > The latest netmap code for FreeBSD/Linux. It has native support > for certain NICs; emulated netmap over unmodified drivers; > enhanced parallelism in the VALE switch (20 Mpps/source, scaling > up to ~50Mpps); and a new feature called "netmap pipe" that > does zero-copy blocking I/O at over 100 Mpps. > Other features are the ability to allocate tons of extra > netmap buffers, and configurable sharing of memory among NICs, > VALE ports and netmap pipes. This increases the opportunity for > zero copy operation. > The user API is also greatly simplified, with a naming > scheme that permits easy access to all types of ports including > individual NIC queues. > > https://code.google.com/p/netmap-libpcap > a netmap-enabled version of libpcap. With this, basically any > pcap client can read/write traffic at 10+ Mpps, with zerocopy > reads and (soon) support for zerocopy writes. Whether applications > can cope with these packet rates, of course, is another story. > > https://code.google.com/p/netmap-click > a netmap-enabled version of the Click Modular Router. This > code matches the current version of netmap, supporting all > features (including netmap pipes). > > https://code.google.com/p/netmap-ipfw > a netmap-enabled, userspace version of the ipfw firewall and > dummynet network emulator. This version reaches 7-10 Mpps for > filtering and over 2.5 Mpps for emulation. > > > Hope you'll find it useful. > > 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 Mon Feb 17 19:12:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66FD9292 for ; Mon, 17 Feb 2014 19:12:50 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21D7616D1 for ; Mon, 17 Feb 2014 19:12:49 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WFTcV-0007fQ-Vc for freebsd-net@freebsd.org; Mon, 17 Feb 2014 20:12:47 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Feb 2014 20:12:47 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Feb 2014 20:12:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Kevin Bowling Subject: Re: netmap, VALE and netmap pipes Date: Mon, 17 Feb 2014 12:12:36 -0700 Lines: 18 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 In-Reply-To: Cc: netdev@vger.kernel.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 19:12:50 -0000 On 2/17/2014 3:11 AM, Luigi Rizzo wrote: > Hi, > we have recently made a few extensions to netmap/VALE and put various > pieces of code on public repositories, so i thought i'd share the > pointers. All the code below runs with equal features and performance > on FreeBSD and Linux, and we are trying to upstream it in the relevant > projects if possible (as an example, QEMU recently added a netmap backend), > at which point some of these clone repositories will become unnecessary. Just a thought, maybe this is a good time for The FreeBSD Foundation to reach out to The Linux Foundation for lobbying netmap into their main line kernel. It would be nice if netmap becomes the de facto UNIX standard for this type of programming (it is vendor neutral and broadly applicable vs other solutions), and avoid not-invented-here APIs like non-blocking I/O went through with all the UNIX flavors. Regards, Kevin Bowling From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 20:14:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01A20520 for ; Mon, 17 Feb 2014 20:14:50 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BFFEC1BAC for ; Mon, 17 Feb 2014 20:14:49 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kx10so15689159pab.7 for ; Mon, 17 Feb 2014 12:14:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=5O1McTPKhCrBQrEqzqB1/Tg81zsZiT6EIuncDNuNJ2U=; b=CiJgUuYIw8G83MSPmuztAuN6GUNpAt2wdt308moJYAL9jZ0FtAvc4ewIyJv4MINaXJ 5X2n1L+Z2AA9V5RyOohTWeb8i+xMbE4hM5w9SnzwsURMfckskybpj63GvyG7xy4EkxL4 aTsqMT51Bqu08Vpib1cjlToqm0jNk629DJIWexvYM31dbceAaO0RJ/DLQBWUtA13E01W 5zutxUMLtYVg80m9cLMQ9XsWGz0euIqL2Pkl0nbcWBmmBzv/hh67kmMzFTQWTnyCZeE1 ZPGZpVrdJZVos+5Fb0OWE7TxHGe3M94oLTk2ufv/TV5dQYSBMiwI/+MlfoYW6WoJtF7D aC5A== X-Gm-Message-State: ALoCoQm15qg4PEz1Oa0xpx3SqObbbJBN5qNWzZplTwEyFGRmHyCJkhzOezw0QSx+N7QRUmzx19T3 X-Received: by 10.66.241.73 with SMTP id wg9mr28749206pac.69.1392668083435; Mon, 17 Feb 2014 12:14:43 -0800 (PST) Received: from nehalam.linuxnetplumber.net (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51]) by mx.google.com with ESMTPSA id mo2sm48583520pbc.6.2014.02.17.12.14.42 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 17 Feb 2014 12:14:43 -0800 (PST) Date: Mon, 17 Feb 2014 12:14:40 -0800 From: Stephen Hemminger To: Kevin Bowling Subject: Re: netmap, VALE and netmap pipes Message-ID: <20140217121440.21a96821@nehalam.linuxnetplumber.net> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 20:14:50 -0000 On Mon, 17 Feb 2014 12:12:36 -0700 Kevin Bowling wrote: > On 2/17/2014 3:11 AM, Luigi Rizzo wrote: > > Hi, > > we have recently made a few extensions to netmap/VALE and put various > > pieces of code on public repositories, so i thought i'd share the > > pointers. All the code below runs with equal features and performance > > on FreeBSD and Linux, and we are trying to upstream it in the relevant > > projects if possible (as an example, QEMU recently added a netmap backend), > > at which point some of these clone repositories will become unnecessary. > > Just a thought, maybe this is a good time for The FreeBSD Foundation to > reach out to The Linux Foundation for lobbying netmap into their main > line kernel. It would be nice if netmap becomes the de facto UNIX > standard for this type of programming (it is vendor neutral and broadly > applicable vs other solutions), and avoid not-invented-here APIs like > non-blocking I/O went through with all the UNIX flavors. > > Regards, > Kevin Bowling You do not understand the role of Linux Foundation. Lobbying would only serve to annoy the developers. Netmap was submitted and rejected for a number of issues. Read the netdev mailing list archives if you want to follow what is going on. From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 20:40:41 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 084679D4 for ; Mon, 17 Feb 2014 20:40:41 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3B321DC4 for ; Mon, 17 Feb 2014 20:40:40 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s1HKectC070416; Mon, 17 Feb 2014 15:40:39 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <530273BF.5020303@sentex.net> Date: Mon, 17 Feb 2014 15:40:31 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Luigi Rizzo , wishmaster Subject: Re: netmap, VALE and netmap pipes References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> In-Reply-To: <20140217185832.GB41267@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 20:40:41 -0000 On 2/17/2014 1:58 PM, Luigi Rizzo wrote: > On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: >> >> Thanks, prof. Luigi. >> >> As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. >> >> E.g. I have classic router with 2 interfaces igb > > replace the "vale" ports with "netmap:igb0" and "netmap"igb1" > and off you go. Apart from the man pages, is there a repository of documentation and examples somewhere ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 20:50:03 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEAEDD34 for ; Mon, 17 Feb 2014 20:50:03 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9E01F9E for ; Mon, 17 Feb 2014 20:50:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 561A57300A; Mon, 17 Feb 2014 21:52:13 +0100 (CET) Date: Mon, 17 Feb 2014 21:52:13 +0100 From: Luigi Rizzo To: Mike Tancsa Subject: Re: netmap, VALE and netmap pipes Message-ID: <20140217205213.GC42021@onelab2.iet.unipi.it> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530273BF.5020303@sentex.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , wishmaster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 20:50:03 -0000 On Mon, Feb 17, 2014 at 03:40:31PM -0500, Mike Tancsa wrote: > On 2/17/2014 1:58 PM, Luigi Rizzo wrote: > > On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: > >> > >> Thanks, prof. Luigi. > >> > >> As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. > >> > >> E.g. I have classic router with 2 interfaces igb > > > > replace the "vale" ports with "netmap:igb0" and "netmap"igb1" > > and off you go. > > Apart from the man pages, is there a repository of documentation and > examples somewhere ? not really. but apart from the plumbing into the interfaces, this is just the FreeBSD/head ipfw code with obvious features disabled (e.g. there is no access to local sockets or address lists or routing tables so things like 'me', 'uid xx', 'verrpath' do not work). And it could definitely be improved to work on more interfaces, become multithreaded etc, but this is an exercise that i hope someone else will take over. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 20:52:15 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F94ECC for ; Mon, 17 Feb 2014 20:52:15 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37BAD102F for ; Mon, 17 Feb 2014 20:52:15 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s1HKqFJx071226; Mon, 17 Feb 2014 15:52:15 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <53027678.2020202@sentex.net> Date: Mon, 17 Feb 2014 15:52:08 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: netmap, VALE and netmap pipes References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> In-Reply-To: <20140217205213.GC42021@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 20:52:15 -0000 On 2/17/2014 3:52 PM, Luigi Rizzo wrote: > On Mon, Feb 17, 2014 at 03:40:31PM -0500, Mike Tancsa wrote: >> On 2/17/2014 1:58 PM, Luigi Rizzo wrote: >>> On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: >>>> >>>> Thanks, prof. Luigi. >>>> >>>> As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. >>>> >>>> E.g. I have classic router with 2 interfaces igb >>> >>> replace the "vale" ports with "netmap:igb0" and "netmap"igb1" >>> and off you go. >> >> Apart from the man pages, is there a repository of documentation and >> examples somewhere ? > > not really. but apart from the plumbing into the interfaces, > this is just the FreeBSD/head ipfw code with obvious features Actually, I was thinking more in terms of netmap in general. eg. examples of how to use it as a high speed firewall or router, or packet generator etc. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 21:14:39 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF10B355 for ; Mon, 17 Feb 2014 21:14:39 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8C15211F8 for ; Mon, 17 Feb 2014 21:14:39 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C3DF47300A; Mon, 17 Feb 2014 22:16:49 +0100 (CET) Date: Mon, 17 Feb 2014 22:16:49 +0100 From: Luigi Rizzo To: Mike Tancsa Subject: Re: netmap, VALE and netmap pipes Message-ID: <20140217211649.GA42452@onelab2.iet.unipi.it> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> <53027678.2020202@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53027678.2020202@sentex.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 21:14:39 -0000 On Mon, Feb 17, 2014 at 03:52:08PM -0500, Mike Tancsa wrote: ... > > this is just the FreeBSD/head ipfw code with obvious features > > Actually, I was thinking more in terms of netmap in general. eg. > examples of how to use it as a high speed firewall or router, or packet > generator etc. i should really write a book on this stuff :) + for simple traffic sources/sinks, the pkt-gen program (FreeBSD: tools/tools/netmap, git repo: examples/ ) is the swiss-army-knife. In RX mode it can drain and count packets at very high rates. In TX mode it can create one or more udp streams with programmable addresses, packet sizes and rates up to the 100+Mpps i was mentioning in the posting. It could be trivially extended to create TCP flows + the 'bridge' program also in the same directories is an example of how to move traffic between (2) interfaces. Note that if you really want to go fast with multiple ports and concurrent threads you will need to reimplement the same batching tricks that we use in the in-kernel VALE switch. I am afraid i do not have a ready-to-use example to point you at. In general, if you have a tool (generator, software router, etc) that speaks libpcap it is a no-op to have it working on top of the netmap-enabled libpcap. Note though that the application itself might be too slow to exploit the speedup that netmap could give. I know that tcpreplay has recently added netmap support and needed some tweaks to work correctly at high rates. Similarly a student of mine is working on the 'ostinato' traffic generator to get some speedups. Keep in mind, the basic I/O costs 500..1000ns per packet with conventional methods, and 10..50ns with netmap. This means that the actual rate you will be able to achieve is dominated by the extra time your application consumes on each packet. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 21:41:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D076192F for ; Mon, 17 Feb 2014 21:41:39 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8CD1478 for ; Mon, 17 Feb 2014 21:41:39 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WFVwR-0005Ow-TL for freebsd-net@freebsd.org; Mon, 17 Feb 2014 22:41:31 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Feb 2014 22:41:31 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Feb 2014 22:41:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Kevin Bowling Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? Date: Mon, 17 Feb 2014 14:41:17 -0700 Lines: 87 Message-ID: References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 21:41:40 -0000 On 2/16/2014 9:04 PM, George Neville-Neil wrote: > > On Feb 15, 2014, at 21:32 , Kevin Bowling wrote: > >> On 2/15/2014 4:43 PM, George Neville-Neil wrote: >>> >>> On Feb 15, 2014, at 15:14 , Kevin Bowling wrote: >>> >>>> Hi, >>>> >>>> I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each node has an Intel X520-DA2 dual port 10gig card. One of the ports on each go to a switch using direct attach coaxial cables. The other port is directly connected between the two nodes (think crossover in twisted pair terminology) again using direct attach coaxial cables. >>>> >>>> On both machines, and on both ports (including the "crossover"), the links flap several times per day. >>>> >>>> I've pasted the output of lspci -vv and dmesg here: >>>> https://gist.github.com/kev009/9024442 >>>> >>>> There's nothing outstanding about the setup otherwise. I suspected some interaction with the switch initially but the "crossover" has eliminated that suspicion. >>>> >>>> It seems the ix driver is not very reliable under common conditions, i.e. https://forums.freebsd.org/viewtopic.php?f=7&t=44570 and a search of this list. Any recommendations or tests? >>>> >>> >>> Can you post (to your gist link) the output of sysctl dev.ix ? >> >> Hi George, >> >> sysctl info added to gist link. ix0 has been up for around 27 days. ix1 for about 24hrs. >> > > I think this has something to do with it. > > dev.ix.0.mac_stats.local_faults: 314 > dev.ix.0.mac_stats.remote_faults: 41 > > The device is seeing errors at the MAC layer, which I don’t think a driver bug would > cause, though there is always the possibility of a misconfiguration causing flapping. > Can you try different cables? > > When you hook it to the switch does the switch give better diagnostics? Reading > over the Intel 82599 chip manual is not, shall we say, illuminating, > "Number of faults in the local MAC. This register is valid only when the link speed is 10 Gb/s.” Appreciate your help, this led me to find some new info although it doesn't entirely answer what local_faluts are for me: http://grouper.ieee.org/groups/802/3/ae/public/nov00/taborek_2_1100.pdf I may have spoke too soon, the "crossover" ix1 seems to be holding steady, so the local and remote faults must have been during negotiation and me bringing up the interfaces. On the other system's ix0, the faults are almost all local and quite a bit more frequent: dev.ix.0.mac_stats.local_faults: 10752 dev.ix.0.mac_stats.remote_faults: 2 I then noticed the switch had mandatory flow control on both send and receive for 10gig, but the FreeBSD box was only negotiating receive flow control. I disabled both on the switch and rebooted but am still seeing some increments of local_faults. Could it be a switch STP problem? Switch is a Cisco 4948-10ge. Configs look like below, which is working well on some copper gigabit interfaces: spanning-tree mode pvst spanning-tree portfast default spanning-tree extend system-id ! interface TenGigabitEthernet1/49 switchport trunk encapsulation dot1q switchport mode trunk spanning-tree portfast trunk ! interface TenGigabitEthernet1/50 switchport trunk encapsulation dot1q switchport mode trunk flowcontrol receive desired flowcontrol send desired spanning-tree portfast trunk ! It will be hard for me to source SFPs and fiber, but I can try to see if it's a physical layer problem. In the mean time I might try imaging one of the systems with a different OS and seeing if the problem persists. Regards, Kevin Bowling From owner-freebsd-net@FreeBSD.ORG Mon Feb 17 22:10:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBE56FB2; Mon, 17 Feb 2014 22:10:30 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53F0516D7; Mon, 17 Feb 2014 22:10:30 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u57so11240983wes.27 for ; Mon, 17 Feb 2014 14:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=+EnKCcaprQTWwCJS0KnGsS1Tigyr0zzZaJd7WPy4vqo=; b=a/kmeua1hgCbuQDIkcCZ86c97yTzW7JoNgMiovd7cPYW88IuWOfCmTy6f845b8+Y59 6J/N13KxNXWycaGUtMSpxE/HcSVyFWmoMQAOQzcx0ce6C3tIEDaOwDjCK//VhqAC2ipp IUUGP4eIp1N2R/FsLFW+wcYp4BjT74/KX3+1fR2tCrIwZ4BOHI2Qb3hARavCdcgS9knV 6be2rPu7gVTMoM1jzuzfrUrRKKk7Ua+W0PifePEHM7qC7D4WstJ3dBBC/+CrJixhB5Ef pkPkUpCuT3KxXRB/yjyW5DGBR0ptXNPw7aOXST1gU5lVTaztLTrE+NVpR+HVX9sDwMsV Snuw== MIME-Version: 1.0 X-Received: by 10.180.97.37 with SMTP id dx5mr14950573wib.53.1392675028644; Mon, 17 Feb 2014 14:10:28 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.168.197 with HTTP; Mon, 17 Feb 2014 14:10:28 -0800 (PST) Date: Mon, 17 Feb 2014 15:10:28 -0700 X-Google-Sender-Auth: OnATy8Tj-dDU94Wm2tGHj6gy2ms Message-ID: Subject: kern/185812: send(2) on a UNIX domain SEQPACKET socket returns EMSGSIZE instead of EAGAIN From: Alan Somers To: FreeBSD Net , rwatson@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Feb 2014 22:10:31 -0000 SOCK_SEQPACKET Unix domain sockets don't work on FreeBSD. kern/185812 is one of the reasons. When send(2) ought to block on a seqpacket socket, it returns EMSGSIZE instead. If the socket is nonblocking, send(2) returns EMSGSIZE instead of EAGAIN. The problem can be demonstrated on FreeBSD 10 or head by the ATF testcase sys/kern/unix_seqpacket_test:eagain_8k_8k. The problem dates to an old hack. It's at least as old as 4.4BSD Lite. When you write to a unix domain socket, the data goes directly to the receiving socket's sockbuf, bypassing the sending socket's sockbuf.. However, sosend_generic doesn't know anything about Unix domain sockets, and it doesn't know anything about the receiving socket. Without some form of backpressure, sosend_generic would never block. So, uipc_send updates the _sending_ sockbuf's sb_hiwat to account for whatever it wrote to the _receiving_ sockbuf. (For those not in the know, sb_hiwat is the maximum allowed amount of data in the buffer.) The next time that sosend_generic gets called, it sees that the sending sockbuf is empty, but it has a lower maximum size than before. If the maximum size is 0, sosend_generic will block. This hack worked fine for SOCK_STREAM sockets, but it breaks SOCK_SEQPACKET sockets, since the latter consist of messages that must be sent atomically. When sb_hiwat is too low to fit an entire message, sosend_generic will return EMSGSIZE instead of blocking or returning EAGAIN. Fortunately, we have a template for how to fix this bug. DragonFlyBSD fixed it back in 2008. Instead of applying backpressure through sb_hiwat, it uses a new sockbuf flag called SSB_STOP. When the receiving sockbuf runs out of space, uipc_send sets SSB_STOP on the sending sockbuf. Then, sosend_generic will block (or return EAGAIN) on the next attempt to write. This solution is very clean and simple. It might also be slightly faster than the legacy method, because it eliminates the need to call chgsbsize() on every send() and recv(). I am aware of one drawback: since ssb_space() will only ever return 0 or ssb_hiwat, sosend_generic will allow the sockbuf to exceed its nominal maximum size by at most one packet of size less than ssb_hiwat. I don't think that's a serious problem. In fact, I'm not even positive that FreeBSD guarantees a socket will always stay within its nominal size limit. Does this solution sound acceptable in FreeBSD? Is there any reason that I shouldn't port it? Note that DragonFly long ago refactored struct sockbuf into two separate structures: struct sockbuf and struct signalsockbuf. I won't make that change as part of the port. In case you're wondering, NetBSD 6.0 suffers from the same bug, OpenBSD 5.4 doesn't appear to support SOCK_SEQPACKET unix domain sockets, and Linux 3.2.0 does not suffer. The relevant commit in DragonFlyBSD: https://github.com/DragonFlyBSD/DragonFlyBSD/commit/3a6117bbe0ed6a87605c1e43e12a1438d8844380 -Alan From owner-freebsd-net@FreeBSD.ORG Tue Feb 18 04:08:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7912D78B; Tue, 18 Feb 2014 04:08:51 +0000 (UTC) Received: from dub0-omc2-s2.dub0.hotmail.com (dub0-omc2-s2.dub0.hotmail.com [157.55.1.141]) by mx1.freebsd.org (Postfix) with ESMTP id 051B017CF; Tue, 18 Feb 2014 04:08:50 +0000 (UTC) Received: from DUB114-W89 ([157.55.1.138]) by dub0-omc2-s2.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Feb 2014 20:07:43 -0800 X-TMN: [tuW6caDOO7/UZqloSYCBcuISXTWajbCD] X-Originating-Email: [robert.sevat@live.nl] Message-ID: From: Robert Sevat To: "freebsd-net@freebsd.org" Subject: re driver crashing under load, can reproduce it. Date: Tue, 18 Feb 2014 05:07:43 +0100 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 18 Feb 2014 04:07:43.0624 (UTC) FILETIME=[F92FC880:01CF2C5E] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Feb 2014 04:08:51 -0000 Hey=2C I've got a small server on which the network driver crashes completely the = instant I put any network load on it. The only way to fix it is by rebootin= g the machine=2C it'll be completely unresponsive to ifconfig up or down. I've seen a bunch of errors already: re0: watchdog timeout re0: link state changed to DOWN re0: link state changed to UP It'll start with that before the driver completely crashes and locks up=2C = a few hunderd times the up/down changes. Feb 18 00:49:33 transmission-video transmission-daemon[1791]: UDP Failed to= set receive buffer: No buffer space available (tr-udp.c:59) Feb 18 00:49:33 transmission-video transmission-daemon[1791]: UDP Failed to= set receive buffer: requested 4194304=2C got 42080 (tr-udp.c:78) I've also had this=2C so I've set the buffer already to 4194304 with: sysct= l net.inet.udp.recvspace: 4194304. After I did this transmission stopped complaining for a bit. An hour later = the Re driver crashed again. This time after reboot the driver refused to w= ork at all. I had to remove that from sysctl.conf and set it back to 42080 = before the driver would work again. netstat -sl re0: http://pastebin.com/NmDWJJ6k This does show that a lot of udp packets are dropped due to full buffers: "4880 dropped due to no socket 2708 broadcast/multicast datagrams undelivered 139828 dropped due to full socket buffers" I have also gotten:=20 "Feb 15 02:39:00 incognitus kernel: sonewconn: pcb 0xfffff80028d28620: List= en queue overflow: 193 already in queue awaiting acceptance Feb 15 02:39:03 incognitus last message repeated 207 times" After googling a bit I have tried multiple things: Disable acpi in the bios=2C and enable ErP to ensure no weird things happen= with power states. I've also disabled powerd in rc.conf. Because I also got these messages in dmesg: "ip6addrctl: socket(UDP): No bu= ffer space available" I've disabled ipv6 on the machine. ip6addrctl_enable=3D"NO" ip6addrctl_policy=3D"ipv4_prefer" ipv6_network_interfaces=3D"none" ipv6_active_all_interfaces=3D"NO" I have also disabling msix and msi in /boot/loader.conf because this was su= ggested by others. hw.re.msi_disable=3D"1" hw.re.msix_disable=3D"1" I also have disabled hardware checksum offloading with ifconfig ifconfig re0 -txcsum ifconfig re0 -rxcsum I've tried forcing the nic to use Full duplex 1000BaseTX since some people = suggested it was due to auto negotiation failure. When I did this the entir= e driver locked up completely and refused to work until I rebooted it. ifconfig re0 media 1000BaseTX mediaopt full-duplex This is on a machine that runs:=20 root@incognitus:/ # uname -a FreeBSD incognitus.indylix.nl 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r261411:= Sun Feb 2 21:51:04 CET 2014 robert@Incognitus:/usr/obj/usr/src/sys/Pf= amd64 I've only added PF support to the kernel. It happens with PF enabled or dis= abled=2C makes no difference. I've ran Pfsense 2.1 on this machine for about 3-4 months without any of th= ese problems. This was also while putting significant load on it (120 mbit = internet). But now that it runs FreeBSD 10.0 it is highly unstable as soon = as I push any traffic. I can manually trigger the crash by starting an Rsyn= c upload to another server. This upload will do roughly 80 mbit of traffic = and crash it within a few Gigabytes of traffic. Or by adding a few torrents= to Transmission that push a fair bit of netwerk traffic. But it's only the= Re driver that crashes=2C the machine it self is up and responsive=2C only= the network stops working. Crashes can be triggered within 10 minutes. root@incognitus:/ # pciconf -lcv re0@pci0:1:0:0: class=3D0x020000 card=3D0xe0001458 chip=3D0x816810ec rev=3D= 0x06 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co.=2C Ltd.' device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class =3D network subclass =3D ethernet cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] =3D MSI supports 1 message=2C 64 bit cap 10[70] =3D PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x= 1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] =3D MSI-X supports 4 messages Table in map 0x20[0x0]=2C PBA in map 0x20[0x800] cap 03[d0] =3D VPD ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] =3D VC 1 max VC0 ecap 0003[160] =3D Serial 1 01000000684ce000 This is on a Gigabyte GA-C847N with the Realtek RTL8111F network card.=20 Any things that I could try? Commands to run? Or extra info you'd like to h= ave? Since I'm pretty much out of ideas.=20 (Except of course buying a different Intel nic=2C which I will resort to if= I can't get it resolved since it's unworkable now. I rather help debug a p= roblem in the driver.) Kind Regards=2C Robert Sevat = From owner-freebsd-net@FreeBSD.ORG Tue Feb 18 06:24:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 232276D for ; Tue, 18 Feb 2014 06:24:02 +0000 (UTC) Received: from dark.beer.net (dark.beer.net [204.145.225.20]) by mx1.freebsd.org (Postfix) with ESMTP id E4CCE11B0 for ; Tue, 18 Feb 2014 06:24:01 +0000 (UTC) Received: from dark.beer.net (glasgow@localhost [127.0.0.1]) by dark.beer.net (8.13.8/8.13.8) with ESMTP id s1I6Ddf0020354 for ; Tue, 18 Feb 2014 00:13:40 -0600 (CST) Received: (from glasgow@localhost) by dark.beer.net (8.13.8/8.13.8/Submit) id s1I6DdhS020353 for freebsd-net@freebsd.org; Tue, 18 Feb 2014 00:13:39 -0600 (CST) From: Michael Glasgow Message-Id: <201402180613.s1I6DdhS020353@dark.beer.net> Subject: ipsec foils traceroute on gre/gif To: freebsd-net@freebsd.org Date: Tue, 18 Feb 2014 00:13:39 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Feb 2014 06:24:02 -0000 I noticed traceroute misses a hop when crossing an encrypted gif or gre tunnel, e.g.: $ sudo traceroute -I 172.29.0.5 traceroute to 172.29.0.5 (172.29.0.5), 30 hops max, 60 byte packets 1 169.254.249.21 (169.254.249.21) 0.524 ms 0.728 ms 0.726 ms 2 169.254.249.25 (169.254.249.25) 1.143 ms 1.160 ms 1.156 ms 3 * * * 4 172.29.0.5 (172.29.0.5) 241.931 ms 247.545 ms 252.398 ms Firewalls are all completely disabled in the above example. It appears the TTL-exceeded ICMP isn't properly generated. Poking through the archives, I found this old thread with a lot of info: http://lists.freebsd.org/pipermail/freebsd-net/2008-November/019928.html But alas, the final word on whether the recommended fix had any untoward security ramifications was not forthcoming. Anyone have an interest in resurrecting this? -- Michael Glasgow From owner-freebsd-net@FreeBSD.ORG Tue Feb 18 09:25:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB05A590 for ; Tue, 18 Feb 2014 09:25:56 +0000 (UTC) Received: from frv191.fwdcdn.com (frv191.fwdcdn.com [212.42.77.191]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91A4E1E36 for ; Tue, 18 Feb 2014 09:25:56 +0000 (UTC) Received: from [10.10.1.23] (helo=frv199.fwdcdn.com) by frv191.fwdcdn.com with esmtp ID 1WFgbR-0003ap-9a for freebsd-net@freebsd.org; Tue, 18 Feb 2014 11:04:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=gMnn9xt+dn6RK0xKNuzSj0UOXr6sF46zbMRYev5SQaU=; b=d7Nf+adKraIlIL7f/EyB3AYPbpnmNG7CHLr/TS9FXWhBTXvDUfKsIY7eDOjdN/SklwahtWE/CZsQdm3VifA8a6wFeeATnjDFEVVq00QV9g2PFVU1bpqzbr5OfMq3cZTafxyPOZQCV37jG704e/cnN05FXJfvUL4jVCM3gDIqgIQ=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1WFgbG-0003Ci-6x for freebsd-net@freebsd.org; Tue, 18 Feb 2014 11:04:22 +0200 Date: Tue, 18 Feb 2014 11:04:21 +0200 From: wishmaster Subject: Re[2]: netmap, VALE and netmap pipes To: Luigi Rizzo X-Mailer: mail.ukr.net 5.0 Message-Id: <1392711455.632249224.68nv9a9s@frv34.fwdcdn.com> In-Reply-To: <20140217205213.GC42021@onelab2.iet.unipi.it> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.fwdcdn.com; Tue, 18 Feb 2014 11:04:21 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Feb 2014 09:25:56 -0000 --- Original message --- From: "Luigi Rizzo" Date: 17 February 2014, 22:50:02 > On Mon, Feb 17, 2014 at 03:40:31PM -0500, Mike Tancsa wrote: > > On 2/17/2014 1:58 PM, Luigi Rizzo wrote: > > > On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: > > >> > > >> Thanks, prof. Luigi. > > >> > > >> As for me, netmap-ipfw is especially interesting. Would you like add some examples for userspace bundle of ipfw and dummynet. Because not all clear in README-file. > > >> > > >> E.g. I have classic router with 2 interfaces igb > > > > > > replace the "vale" ports with "netmap:igb0" and "netmap"igb1" > > > and off you go. > > > > Apart from the man pages, is there a repository of documentation and > > examples somewhere ? > > not really. but apart from the plumbing into the interfaces, > this is just the FreeBSD/head ipfw code with obvious features > disabled (e.g. there is no access to local sockets or address > lists or routing tables so things like 'me', 'uid xx', 'verrpath' > do not work). Thus it is unable to use kipfw/dummynet in situation with multiple external interfaces due to no access to routing tables? From owner-freebsd-net@FreeBSD.ORG Tue Feb 18 14:16:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6955E96A for ; Tue, 18 Feb 2014 14:16:35 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37C111973 for ; Tue, 18 Feb 2014 14:16:34 +0000 (UTC) Received: from mobile-198-228-192-202.mycingular.net ([198.228.192.202]:32484 helo=[172.20.10.5]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WFlTN-0005IX-JP; Tue, 18 Feb 2014 09:16:33 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? From: George Neville-Neil In-Reply-To: Date: Tue, 18 Feb 2014 09:16:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <11F52C6F-1A9C-4D5B-8364-AFB62322CB91@neville-neil.com> References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> To: Kevin Bowling X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Feb 2014 14:16:35 -0000 On Feb 17, 2014, at 16:41 , Kevin Bowling = wrote: > On 2/16/2014 9:04 PM, George Neville-Neil wrote: >>=20 >> On Feb 15, 2014, at 21:32 , Kevin Bowling = wrote: >>=20 >>> On 2/15/2014 4:43 PM, George Neville-Neil wrote: >>>>=20 >>>> On Feb 15, 2014, at 15:14 , Kevin Bowling = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. = Each node has an Intel X520-DA2 dual port 10gig card. One of the ports = on each go to a switch using direct attach coaxial cables. The other = port is directly connected between the two nodes (think crossover in = twisted pair terminology) again using direct attach coaxial cables. >>>>>=20 >>>>> On both machines, and on both ports (including the "crossover"), = the links flap several times per day. >>>>>=20 >>>>> I've pasted the output of lspci -vv and dmesg here: >>>>> https://gist.github.com/kev009/9024442 >>>>>=20 >>>>> There's nothing outstanding about the setup otherwise. I = suspected some interaction with the switch initially but the "crossover" = has eliminated that suspicion. >>>>>=20 >>>>> It seems the ix driver is not very reliable under common = conditions, i.e. https://forums.freebsd.org/viewtopic.php?f=3D7&t=3D44570 = and a search of this list. Any recommendations or tests? >>>>>=20 >>>>=20 >>>> Can you post (to your gist link) the output of sysctl dev.ix ? >>>=20 >>> Hi George, >>>=20 >>> sysctl info added to gist link. ix0 has been up for around 27 days. = ix1 for about 24hrs. >>>=20 >>=20 >> I think this has something to do with it. >>=20 >> dev.ix.0.mac_stats.local_faults: 314 >> dev.ix.0.mac_stats.remote_faults: 41 >>=20 >> The device is seeing errors at the MAC layer, which I don=92t think = a driver bug would >> cause, though there is always the possibility of a misconfiguration = causing flapping. >> Can you try different cables? >>=20 >> When you hook it to the switch does the switch give better = diagnostics? Reading >> over the Intel 82599 chip manual is not, shall we say, illuminating, >> "Number of faults in the local MAC. This register is valid only when = the link speed is 10 Gb/s.=94 >=20 > Appreciate your help, this led me to find some new info although it = doesn't entirely answer what local_faluts are for me: = http://grouper.ieee.org/groups/802/3/ae/public/nov00/taborek_2_1100.pdf >=20 > I may have spoke too soon, the "crossover" ix1 seems to be holding = steady, so the local and remote faults must have been during negotiation = and me bringing up the interfaces. >=20 > On the other system's ix0, the faults are almost all local and quite a = bit more frequent: > dev.ix.0.mac_stats.local_faults: 10752 > dev.ix.0.mac_stats.remote_faults: 2 >=20 > I then noticed the switch had mandatory flow control on both send and = receive for 10gig, but the FreeBSD box was only negotiating receive flow = control. I disabled both on the switch and rebooted but am still seeing = some increments of local_faults. >=20 > Could it be a switch STP problem? Switch is a Cisco 4948-10ge. = Configs look like below, which is working well on some copper gigabit = interfaces: >=20 > spanning-tree mode pvst > spanning-tree portfast default > spanning-tree extend system-id > ! > interface TenGigabitEthernet1/49 > switchport trunk encapsulation dot1q > switchport mode trunk > spanning-tree portfast trunk > ! > interface TenGigabitEthernet1/50 > switchport trunk encapsulation dot1q > switchport mode trunk > flowcontrol receive desired > flowcontrol send desired > spanning-tree portfast trunk > ! >=20 > It will be hard for me to source SFPs and fiber, but I can try to see = if it's a physical layer problem. In the mean time I might try imaging = one of the systems with a different OS and seeing if the problem = persists. >=20 Another possibility is flow control. Can you try this setting? sysctl dev.ix.0.fc=3D0 Best, George From owner-freebsd-net@FreeBSD.ORG Tue Feb 18 18:53:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5B67DFC for ; Tue, 18 Feb 2014 18:53:52 +0000 (UTC) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5361714 for ; Tue, 18 Feb 2014 18:53:52 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 96CE41FF0054; Tue, 18 Feb 2014 13:25:26 -0500 (EST) Received: from IAD-WPRD-XCHB01.corp.verio.net ([198.87.7.137]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 13:26:35 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: RE: ipsec foils traceroute on gre/gif Date: Tue, 18 Feb 2014 13:26:34 -0500 Message-ID: In-Reply-To: <201402180613.s1I6DdhS020353@dark.beer.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipsec foils traceroute on gre/gif thread-index: Ac8scgnINip2gpa4Shex/qWtbwEPjAAZFDGg References: <201402180613.s1I6DdhS020353@dark.beer.net> From: "David DeSimone" To: "Michael Glasgow" X-OriginalArrivalTime: 18 Feb 2014 18:26:35.0215 (UTC) FILETIME=[F4688DF0:01CF2CD6] Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Feb 2014 18:53:52 -0000 My understanding of this issue is that replying with an ICMP message for = traceroute carries the risk of violating security policy. When an ICMP Unreachable packet is generated, the first 64 octets in the = packet are copied into the reply. If the packet was originally = encrypted with IPSEC, those octets were never seen unencrypted on the = wire. If the ICMP Unreachable were permitted to be generated and sent, = it could very well reveal the unencrypted IPSEC packet contents on the = wire, because the source/destination IP's of the ICMP message no longer = matches SPD's. Thus the conservative decision in the kernel is to drop the TTL-exceeded = packet coming from IPSEC, with no reply. In other words, "working as intended." -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Michael Glasgow Sent: Tuesday, February 18, 2014 12:14 AM To: freebsd-net@freebsd.org Subject: ipsec foils traceroute on gre/gif I noticed traceroute misses a hop when crossing an encrypted gif or gre tunnel, e.g.: $ sudo traceroute -I 172.29.0.5 traceroute to 172.29.0.5 (172.29.0.5), 30 hops max, 60 byte packets 1 169.254.249.21 (169.254.249.21) 0.524 ms 0.728 ms 0.726 ms 2 169.254.249.25 (169.254.249.25) 1.143 ms 1.160 ms 1.156 ms 3 * * * 4 172.29.0.5 (172.29.0.5) 241.931 ms 247.545 ms 252.398 ms Firewalls are all completely disabled in the above example. It appears the TTL-exceeded ICMP isn't properly generated. Poking through the archives, I found this old thread with a lot of info: http://lists.freebsd.org/pipermail/freebsd-net/2008-November/019928.html But alas, the final word on whether the recommended fix had any untoward security ramifications was not forthcoming. Anyone have an interest in resurrecting this? --=20 Michael Glasgow _______________________________________________ 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" This email message is intended for the use of the person to whom it has = been sent, and may contain information that is confidential or legally = protected. If you are not the intended recipient or have received this = message in error, you are not authorized to copy, distribute, or = otherwise use this message or its attachments. Please notify the sender = immediately by return e-mail and permanently delete this message and any = attachments. Verio Inc. makes no warranty that this email is error or = virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 04:57:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4511B10 for ; Wed, 19 Feb 2014 04:57:05 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5891017B3 for ; Wed, 19 Feb 2014 04:57:05 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id u14so13147837lbd.9 for ; Tue, 18 Feb 2014 20:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5NvOtwWCfl67bLoXoFk/Zhm79pc3pZalMFzHNH/cfBI=; b=CdTz2UP8RyrjG1XFv6mXA1EYUbqh4ASe3hWVKNN/3kd0jt1QiOuE5n9ZJXWZvjsXhX sFPjvREiQPRFNKEFT/yjVfJezxSaxLgfOpwwdU3QNTL2F0nZfcq8QrgfvpgkypHnz/oo hIQ9qBxEja0CSjVErvENzjC/vYz36Z5ygaoIJAp+WVQSxiJWHIvclOh04GJY+N7bmEiT DKNpd2frqIIIDuShKuZAk353hnQCm5LEZICM1m3BZBmDrlIKwsFnig1AUizbAnkaxQpd bzAWFj11cyidKSNY1ndwHTSGbkNlyDYWwakGC3HMRUwFvicm2KwA04eNzb5iYt9yQNMn rGDQ== MIME-Version: 1.0 X-Received: by 10.112.17.65 with SMTP id m1mr164439lbd.46.1392785822780; Tue, 18 Feb 2014 20:57:02 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Tue, 18 Feb 2014 20:57:02 -0800 (PST) In-Reply-To: <1392711455.632249224.68nv9a9s@frv34.fwdcdn.com> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> <1392711455.632249224.68nv9a9s@frv34.fwdcdn.com> Date: Tue, 18 Feb 2014 20:57:02 -0800 X-Google-Sender-Auth: ED8xrNX2TtZVchb_NwBgF9UcMKM Message-ID: Subject: Re: Re[2]: netmap, VALE and netmap pipes From: Luigi Rizzo To: wishmaster Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 04:57:06 -0000 On Tue, Feb 18, 2014 at 1:04 AM, wishmaster wrote: > > > > --- Original message --- > From: "Luigi Rizzo" > Date: 17 February 2014, 22:50:02 > > > > > On Mon, Feb 17, 2014 at 03:40:31PM -0500, Mike Tancsa wrote: > > > On 2/17/2014 1:58 PM, Luigi Rizzo wrote: > > > > On Mon, Feb 17, 2014 at 08:36:06PM +0200, wishmaster wrote: > > > >> > > > >> Thanks, prof. Luigi. > > > >> > > > >> As for me, netmap-ipfw is especially interesting. Would you like > add some examples for userspace bundle of ipfw and dummynet. Because not > all clear in README-file. > > > >> > > > >> E.g. I have classic router with 2 interfaces igb > > > > > > > > replace the "vale" ports with "netmap:igb0" and "netmap"igb1" > > > > and off you go. > > > > > > Apart from the man pages, is there a repository of documentation and > > > examples somewhere ? > > > > not really. but apart from the plumbing into the interfaces, > > this is just the FreeBSD/head ipfw code with obvious features > > disabled (e.g. there is no access to local sockets or address > > lists or routing tables so things like 'me', 'uid xx', 'verrpath' > > do not work). > > Thus it is unable to use kipfw/dummynet in situation with multiple > external interfaces due to > no access to routing tables? > actually the routing is done by a router, a firewall just filters. So you could use this kipfw in a transparent firewall bridge, or in front of the host stack on a machine you want to protect. And for the rest, my original email continued like this: --> And it could definitely be improved to work on more interfaces, --> become multithreaded etc, but this is an exercise that i hope --> someone else will take over. cheers luigi -- -----------------------------------------+------------------------------- 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 Wed Feb 19 06:43:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A453D8D for ; Wed, 19 Feb 2014 06:43:03 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E15E2108B for ; Wed, 19 Feb 2014 06:43:02 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x3so2112573qcv.30 for ; Tue, 18 Feb 2014 22:43:02 -0800 (PST) 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=EH6YUulhqbVnIcFLa+H91Ydo4w763w4RwJboU/hBH2M=; b=pDckGgRr1OrDKVlo3NxTu0R3bR8EFyHMB1LpVx+uKi7Ybg2SPQ/fH7saJPGWshVpkm 1bB2Ygd4SwJYNduah3YaGG87baygwBSckG0ylMOwrWWqkUH2Ln4na9UlqzueTtfqDn3e GfBtz/Yu3yNf9O6QZuwHUuZa4Z7xFeymxFQaBbE9M3BiElQHzmaSR8LJZC4Y0HYxgrKP 5OK55mZyZZ/dxPKpyc7NGJyTLBwtKgERNKoTQEtPA9GB1ZKd+HvY6Gi+ErWyzPOKztUu FLZmcfiCGw4m8AOv4/e2svVoROPbyQjxlxI/PT6f0sx2YsLHoGZeVA8ondgG/MNcs+9Q bbTA== MIME-Version: 1.0 X-Received: by 10.224.104.9 with SMTP id m9mr907145qao.18.1392792182072; Tue, 18 Feb 2014 22:43:02 -0800 (PST) Received: by 10.140.43.55 with HTTP; Tue, 18 Feb 2014 22:43:02 -0800 (PST) Date: Wed, 19 Feb 2014 10:43:02 +0400 Message-ID: Subject: how to delete second default route ipv6? From: venom To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 06:43:03 -0000 Hello, All. i have a problem with procedure of delete second ipv6 default route # netstat -f inet6 -nr | grep default default fe80::7afe:3dff:feef:66c1%lagg0 UG lagg0 => default fe80::210:dbff:feff:1002%lagg0 UG lagg0 # route delete -inet6 default route: writing to routing socket: No such process delete net default: not in table # uname -a FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 -- Vladimir Laskov samflanker@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 09:18:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DFD132D for ; Wed, 19 Feb 2014 09:18:14 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48E461D7C for ; Wed, 19 Feb 2014 09:18:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,504,1389772800"; d="asc'?scan'208";a="103183924" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 19 Feb 2014 01:18:12 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 01:18:13 -0800 From: "Eggert, Lars" To: "freebsd-net@freebsd.org" Subject: DCTCP for FreeBSD Thread-Topic: DCTCP for FreeBSD Thread-Index: AQHPLVOCepB89nhM3kSw+mvDiTdbnQ== Date: Wed, 19 Feb 2014 09:18:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/signed; boundary="Apple-Mail=_BAE04A14-8EAB-4CA7-89EF-860A13E6E143"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Midori Kato X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 09:18:14 -0000 --Apple-Mail=_BAE04A14-8EAB-4CA7-89EF-860A13E6E143 Content-Type: multipart/mixed; boundary="Apple-Mail=_5AB129EF-65C5-4C0E-ACC4-CE048EBD9985" --Apple-Mail=_5AB129EF-65C5-4C0E-ACC4-CE048EBD9985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Midori Kato has implemented Microsoft's/Stanford's Datacenter TCP = (DCTCP) for FreeBSD as part of her MS thesis with me. Find a patch = attached. Also note that we're documenting a specification for DCTCP in an IETF = draft: http://tools.ietf.org/html/draft-bensley-tcpm-dctcp Microsoft has made a licensing statement (RAND-Z) on the technology to = the IETF: https://datatracker.ietf.org/ipr/2319/ (I'm not sure what this = means for an eventual inclusion in FreeBSD.) Roughly, Midori's patch consists of an extension of the modular = congestion control framework to expose ECN information to the modules, a = module to implement DCTCP, and a few experimental variants. See Midori's = explanation: > [1] A change for the modular congestion control framework (See Section = 4.1 if needed) > DCTCP uses the difference ECN processing from RFC3168. We need to = prepare three functions to do the following ECN processing.=20 > a) The kernel decides whether an ECE flag should be set in the next = outgoing TCP segment by snooping reserved bits in IP and TCP headers. = (tcp_input.c) > b) The kernel controls a congestion if an ECE flag is set in an = arriving TCP segment. (tcp_input.c) > c) After the outgoing TCP segment is generated, the kernel decides = whether an ECT bit should be set in an ECN field of IP header in the = outgoing packet. (tcp_output.c) > The current framework has no housekeeping functions for (a) and (b). = Therefore, I add two functions into the moduler cc framework: = ecnpkt_handler() and ect_handler(). >=20 > - ecnpkt_handler() allows the kernel to do the additional ECN = processing by snooping ECN field in IP and TCP headers. As an option, = this function takes a flag, which tells whether this function is in the = delayed ACK. This function returns an integer value. When the return = value is set, the kernel force to disable delayed ACK. > - ect_handler() allows the kernel to use different rule from RFC3168 = in terms of an ECT marking in the outgoing segment. This function = returns an integer value. If the value is set, an ECT bit is set to the = outgoing segment. >=20 >=20 > [2] Five changes from the original DCTCP algorithm > In order to reflect the DCTCP motivation, I modified the following = processing. First four modifications are for senders and the last = modification is for receivers. >=20 > (1) no congestion recovery in the receipt of ECE flags (See section = 4.2.1 if needed) > FreeBSD handles ECN as a congestion event but it's not true for DCTCP = senders. A DCTCP sender uses ECN as a means to understand the extent of = congestions. Therefore, I remove congestion recovery mode in any = situation for DCTCP senders. >=20 > (2) selective initial alpha value (See section 4.2.2 if needed)=20 > DCTCP defines alpha as a parameter to see the depth of a congestion. = When the alpha value is large, it allows a saw-toothed CWND behavior to = a DCTCP sender. > A problem is that the alpha value is not reliable during a dozen of = RTTs because there is no way to identify the depth of a congestion over = a network from the beginning. When considering the alpha reliability, I = think the initial alpha should be selective for applications by users. = When a user chooses DCTCP for latency-sensitive applications, the = initial alpha is preferred. Otherwise, DCTCP senders had better to set = the initial alpha value to zero from my experimental result (See section = 7.2 of attaching file). > The default alpha value is set to zero in my implementation. >=20 > (3) alpha value initialization after an idle period (See section 4.2.3 = if needed) > How long an idle period is no longer predictable. Therefore, for a = DCTCP sender, using the out-dated alpha after an idle period is not good = idea. A DCTCP sender resets alpha to the initial value when an idle = period occurs. >=20 > The following changes is applied to eliminate a compatibility issue to = standard ECN defined in RFC3465. DCTCP and standard ECN servers have no = way to identify which mechanism is working on the peer. Thus, we need to = eliminate the worst situation in a network mixing DCTCP = senders/receivers and standard ECN senders/receivers. > (4) using CWR flag when the ECE flag is found for a RTT (See section = 5.1 if needed) > This change is applied for a situation when a sender uses DCTCP and a = reciever uses standard ECN.=20 > Under the situation, I find that a DCTCP sender minimizes CWND. The = detailed technical reason is described in section 4.2 of my attaching = file. Fortunately, the current tcp_input() function complement this = change, thus, there is no modification in my patch. >=20 > (5) enabling delayed ACK in the receipt of the CWR flag (See section = 5.2 if needed) > This change is applied for a situation when a sender uses standard ECN = and a reciever uses DCTCP. Under the situation, I find that a standard = ECN sender increases smaller CWND than expected without this change. The = detailed technical reason is described in section 5.2 of my attaching = file. The patch is attached and should apply to a recent -CURRENT. Midori's = thesis (which she refers to in the quoted text above) is at = https://eggert.org/students/kato-thesis.pdf Lars --Apple-Mail=_5AB129EF-65C5-4C0E-ACC4-CE048EBD9985 Content-Disposition: attachment; filename=dctcp.patch Content-Type: application/octet-stream; name="dctcp.patch" Content-Transfer-Encoding: 7bit diff --git a/sys/modules/cc/Makefile b/sys/modules/cc/Makefile index 7b851f5..7f4e94e 100644 --- a/sys/modules/cc/Makefile +++ b/sys/modules/cc/Makefile @@ -3,6 +3,7 @@ SUBDIR= cc_cdg \ cc_chd \ cc_cubic \ + cc_dctcp \ cc_hd \ cc_htcp \ cc_vegas diff --git a/sys/modules/cc/cc_dctcp/Makefile b/sys/modules/cc/cc_dctcp/Makefile new file mode 100644 index 0000000..32919cd --- /dev/null +++ b/sys/modules/cc/cc_dctcp/Makefile @@ -0,0 +1,9 @@ +# $FreeBSD$ + +.include + +.PATH: ${.CURDIR}/../../../netinet/cc +KMOD= cc_dctcp +SRCS= cc_dctcp.c + +.include diff --git a/sys/netinet/cc.h b/sys/netinet/cc.h index 14b4a9d..381f94e 100644 --- a/sys/netinet/cc.h +++ b/sys/netinet/cc.h @@ -143,6 +143,13 @@ struct cc_algo { /* Called when data transfer resumes after an idle period. */ void (*after_idle)(struct cc_var *ccv); + /* Called for an additional ECN processing apart from RFC3168. */ + int (*ecnpkt_handler)(struct cc_var *ccv, uint8_t iptos, int cwr, + int is_delayack); + + /* Called when the host marks ECN capable transmission (ECT). */ + int (*ect_handler)(struct cc_var *ccv); + STAILQ_ENTRY (cc_algo) entries; }; diff --git a/sys/netinet/cc/cc_dctcp.c b/sys/netinet/cc/cc_dctcp.c new file mode 100644 index 0000000..d8cd166 --- /dev/null +++ b/sys/netinet/cc/cc_dctcp.c @@ -0,0 +1,442 @@ +/*- + * Copyright (c) 2007-2008 + * Swinburne University of Technology, Melbourne, Australia + * Copyright (c) 2009-2010 Lawrence Stewart + * Copyright (c) 2014 Midori Kato + * Copyright (c) 2014 The FreeBSD Foundation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * An implementation of the DCTCP algorithm for FreeBSD, based on + * "Data Center TCP (DCTCP)" by M. Alizadeh, A. Greenberg, D. A. Maltz, + * J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Sridharan., + * in ACM Conference on SIGCOMM 2010, New York, USA, + * Originally released as the contribution of Microsoft Research project. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include + +#include + +#define CAST_PTR_INT(X) (*((int*)(X))) + +static VNET_DEFINE(uint32_t, dctcp_shift_g) = 4; +static VNET_DEFINE(uint32_t, dctcp_slowstart) = 0; +#define V_dctcp_shift_g VNET(dctcp_shift_g) +#define V_dctcp_slowstart VNET(dctcp_slowstart) + +struct dctcp { + /* # of marked bytes during a RTT */ + int bytes_ecn; + /* # of acked bytes during a RTT */ + int bytes_total; + /* the fraction of marked bytes */ + int alpha; + /* CE state of the last segment */ + int ce_prev; + /* end sequence number of the current window */ + int save_sndnxt; + /* ECE flag in this segment */ + int is_ece; + /* ECE flag in the last segment */ + int ece_prev; + /* # of congestion events */ + uint32_t num_cong_events; +}; + +static MALLOC_DEFINE(M_dctcp, "dctcp data", + "Per connection data required for the dctcp algorithm"); + +static void dctcp_ack_received(struct cc_var *ccv, uint16_t type); +static void dctcp_after_idle(struct cc_var *ccv); +static void dctcp_cb_destroy(struct cc_var *ccv); +static int dctcp_cb_init(struct cc_var *ccv); +static void dctcp_cong_signal(struct cc_var *ccv, uint32_t type); +static void dctcp_conn_init(struct cc_var *ccv); +static void dctcp_post_recovery(struct cc_var *ccv); +static int dctcp_ecnpkt_handler(struct cc_var *ccv, uint8_t iptos, int cwr, + int is_delayack); +static int dctcp_ecthandler(struct cc_var *ccv); +static void dctcp_update_alpha(struct cc_var *ccv); + +struct cc_algo dctcp_cc_algo = { + .name = "dctcp", + .ack_received = dctcp_ack_received, + .cb_destroy = dctcp_cb_destroy, + .cb_init = dctcp_cb_init, + .cong_signal = dctcp_cong_signal, + .conn_init = dctcp_conn_init, + .post_recovery = dctcp_post_recovery, + .ecnpkt_handler = dctcp_ecnpkt_handler, + .after_idle = dctcp_after_idle, + .ect_handler = dctcp_ecthandler, +}; + +static void +dctcp_ack_received(struct cc_var *ccv, uint16_t type) +{ + struct dctcp *dctcp_data; + int bytes_acked = 0; + + dctcp_data = ccv->cc_data; + + /* + * DCTCP doesn't regard with ECN as a congestion. + * Thus, DCTCP always executes the ACK processing out + * of congestion recovery. + */ + if (IN_CONGRECOVERY(CCV(ccv, t_flags))) { + EXIT_CONGRECOVERY(CCV(ccv, t_flags)); + newreno_cc_algo.ack_received(ccv, type); + ENTER_CONGRECOVERY(CCV(ccv, t_flags)); + } else + newreno_cc_algo.ack_received(ccv, type); + + /* Updates the fraction of marked bytes. */ + if (CCV(ccv, t_flags) & TF_ECN_PERMIT) { + + if (type == CC_DUPACK) + bytes_acked = CCV(ccv, t_maxseg); + + if (type == CC_ACK) + bytes_acked = ccv->bytes_this_ack; + + /* Update total bytes. */ + dctcp_data->bytes_total += bytes_acked; + + /* Update total marked bytes. */ + if (dctcp_data->is_ece) { + if (!dctcp_data->ece_prev + && bytes_acked > CCV(ccv, t_maxseg)) { + dctcp_data->bytes_ecn += + (bytes_acked - CCV(ccv, t_maxseg)); + } else + dctcp_data->bytes_ecn += bytes_acked; + dctcp_data->ece_prev = 1; + } else { + if (dctcp_data->ece_prev + && bytes_acked > CCV(ccv, t_maxseg)) + dctcp_data->bytes_ecn += CCV(ccv, t_maxseg); + dctcp_data->ece_prev = 0; + } + dctcp_data->is_ece = 0; + + /* + * Update the fraction of marked bytes at the end of + * current window size. + */ + if ((IN_FASTRECOVERY(CCV(ccv, t_flags)) && + SEQ_GEQ(ccv->curack, CCV(ccv, snd_recover))) || + (!IN_FASTRECOVERY(CCV(ccv, t_flags)) && + SEQ_GT(ccv->curack, dctcp_data->save_sndnxt))) + dctcp_update_alpha(ccv); + } +} + +static void +dctcp_after_idle(struct cc_var *ccv) +{ + struct dctcp *dctcp_data; + + dctcp_data = ccv->cc_data; + + /* Initialize internal parameters after idle time */ + dctcp_data->bytes_ecn = 0; + dctcp_data->bytes_total = 0; + dctcp_data->save_sndnxt = CCV(ccv, snd_nxt); + dctcp_data->alpha = 0; + dctcp_data->is_ece = 0; + dctcp_data->ece_prev = 0; + dctcp_data->num_cong_events = 0; + + dctcp_cc_algo.after_idle = newreno_cc_algo.after_idle; +} + +static void +dctcp_cb_destroy(struct cc_var *ccv) +{ + if (ccv->cc_data != NULL) + free(ccv->cc_data, M_dctcp); +} + +static int +dctcp_cb_init(struct cc_var *ccv) +{ + struct dctcp *dctcp_data; + + dctcp_data = malloc(sizeof(struct dctcp), M_dctcp, M_NOWAIT|M_ZERO); + + if (dctcp_data == NULL) + return (ENOMEM); + + /* Initialize some key variables with sensible defaults. */ + dctcp_data->bytes_ecn = 0; + dctcp_data->bytes_total = 0; + dctcp_data->alpha = 0; + dctcp_data->save_sndnxt = 0; + dctcp_data->ce_prev = 0; + dctcp_data->is_ece = 0; + dctcp_data->ece_prev = 0; + dctcp_data->num_cong_events = 0; + + ccv->cc_data = dctcp_data; + return (0); +} + +/* + * Perform any necessary tasks before we enter congestion recovery. + */ +static void +dctcp_cong_signal(struct cc_var *ccv, uint32_t type) +{ + struct dctcp *dctcp_data; + u_int win, mss; + + dctcp_data = ccv->cc_data; + win = CCV(ccv, snd_cwnd); + mss = CCV(ccv, t_maxseg); + + switch (type) { + case CC_NDUPACK: + if (!IN_FASTRECOVERY(CCV(ccv, t_flags))) { + if (!IN_CONGRECOVERY(CCV(ccv, t_flags))) { + CCV(ccv, snd_ssthresh) = mss * + max(win / 2 / mss, 2); + dctcp_data->num_cong_events++; + } else { + /* cwnd has already updated as congestion + * recovery. Reverse cwnd value using + * snd_cwnd_prev and recalculate snd_ssthresh + */ + win = CCV(ccv, snd_cwnd_prev); + CCV(ccv, snd_ssthresh) = + max(win / 2 / mss, 2) * mss; + } + ENTER_RECOVERY(CCV(ccv, t_flags)); + } + break; + case CC_ECN: + /* + * Save current snd_cwnd when the host encounters both + * congestion recovery and fast recovery. + */ + CCV(ccv, snd_cwnd_prev) = win; + if (!IN_CONGRECOVERY(CCV(ccv, t_flags))) { + if (V_dctcp_slowstart && + dctcp_data->num_cong_events++ == 0) { + CCV(ccv, snd_ssthresh) = + mss * max(win / 2 / mss, 2); + dctcp_data->alpha = 1024; + dctcp_data->bytes_ecn = 0; + dctcp_data->bytes_total = 0; + dctcp_data->save_sndnxt = CCV(ccv, snd_nxt); + } else + CCV(ccv, snd_ssthresh) = max((win - ((win * + dctcp_data->alpha) >> 11)) / mss, 2) * mss; + CCV(ccv, snd_cwnd) = CCV(ccv, snd_ssthresh); + ENTER_CONGRECOVERY(CCV(ccv, t_flags)); + } + dctcp_data->is_ece = 1; + break; + case CC_RTO: + if (CCV(ccv, t_flags) & TF_ECN_PERMIT) { + CCV(ccv, t_flags) |= TF_ECN_SND_CWR; + dctcp_update_alpha(ccv); + dctcp_data->save_sndnxt += CCV(ccv, t_maxseg); + dctcp_data->num_cong_events++; + } + break; + } +} + +static void +dctcp_conn_init(struct cc_var *ccv) +{ + struct dctcp *dctcp_data; + + dctcp_data = ccv->cc_data; + + if (CCV(ccv, t_flags) & TF_ECN_PERMIT) + dctcp_data->save_sndnxt = CCV(ccv, snd_nxt); +} + +/* + * Perform any necessary tasks before we exit congestion recovery. + */ +static void +dctcp_post_recovery(struct cc_var *ccv) +{ + dctcp_cc_algo.post_recovery = newreno_cc_algo.post_recovery; + + if (CCV(ccv, t_flags) & TF_ECN_PERMIT) + dctcp_update_alpha(ccv); +} + +static int +dctcp_ecnpkt_handler(struct cc_var *ccv, uint8_t iptos, int cwr, int is_delayack) +{ + struct dctcp *dctcp_data; + int ret = 0; + + dctcp_data = ccv->cc_data; + /* + * DCTCP responses an ACK immediately + * - when the CE state in between this segment + * and the last segment is not same + * - when this segment sets the CWR flag + */ + switch (iptos & IPTOS_ECN_MASK) { + case IPTOS_ECN_CE: + if (!dctcp_data->ce_prev && is_delayack) + ret = 1; + dctcp_data->ce_prev = 1; + CCV(ccv, t_flags) |= TF_ECN_SND_ECE; + break; + case IPTOS_ECN_ECT0: + if (dctcp_data->ce_prev && is_delayack) + ret = 1; + CCV(ccv, t_flags) &= ~TF_ECN_SND_ECE; + dctcp_data->ce_prev = 0; + break; + case IPTOS_ECN_ECT1: + if (dctcp_data->ce_prev && is_delayack) + ret = 1; + CCV(ccv, t_flags) &= ~TF_ECN_SND_ECE; + dctcp_data->ce_prev = 0; + break; + } + if (cwr && is_delayack) + ret = 0; + + return (ret); +} + +static int +dctcp_ecthandler(struct cc_var *ccv) +{ + /* DCTCP always marks ECT */ + return (1); +} + +/* + * Update the fraction of marked bytes named alpha. Then, initialize + * several internal parameters at the end of this function. + */ +static void +dctcp_update_alpha(struct cc_var *ccv) +{ + struct dctcp *dctcp_data; + int alpha_prev; + + dctcp_data = ccv->cc_data; + + alpha_prev = dctcp_data->alpha; + + dctcp_data->bytes_total = max(dctcp_data->bytes_total, 1); + + /* + * Update alpha: alpha = (1 - g) * alpha + g * F. + * Alpha must be round to 0 - 1024. + * XXXMIDORI Is more fine-grained alpha necessary? + */ + dctcp_data->alpha = min(alpha_prev - (alpha_prev >> V_dctcp_shift_g) + + (dctcp_data->bytes_ecn << (10 - V_dctcp_shift_g)) / + dctcp_data->bytes_total, 1024); + + /* Initialize internal parameters for next alpha calculation */ + dctcp_data->bytes_ecn = 0; + dctcp_data->bytes_total = 0; + dctcp_data->save_sndnxt = CCV(ccv, snd_nxt); +} + +static int +dctcp_shift_g_handler(SYSCTL_HANDLER_ARGS) +{ + int error; + uint32_t new; + + new = V_dctcp_shift_g ; + error = sysctl_handle_int(oidp, &new, 0, req); + if (error == 0 && req->newptr != NULL) { + if (CAST_PTR_INT(req->newptr) > 1) + error = EINVAL; + else + V_dctcp_shift_g = new; + } + + return (error); +} + +static int +dctcp_slowstart_handler(SYSCTL_HANDLER_ARGS) +{ + int error; + uint32_t new; + + new = V_dctcp_slowstart; + error = sysctl_handle_int(oidp, &new, 0, req); + if (error == 0 && req->newptr != NULL) { + if (CAST_PTR_INT(req->newptr) > 1) + error = EINVAL; + else + V_dctcp_slowstart = new; + } + + return (error); +} + +SYSCTL_DECL(_net_inet_tcp_cc_dctcp); +SYSCTL_NODE(_net_inet_tcp_cc, OID_AUTO, dctcp, CTLFLAG_RW, NULL, + "dctcp congestion control related settings"); + +SYSCTL_VNET_PROC(_net_inet_tcp_cc_dctcp, OID_AUTO, shift_g, + CTLTYPE_UINT|CTLFLAG_RW, &VNET_NAME(dctcp_shift_g), 4, + &dctcp_shift_g_handler, + "IU", "dctcp shift parameter"); + +SYSCTL_VNET_PROC(_net_inet_tcp_cc_dctcp, OID_AUTO, slowstart, + CTLTYPE_UINT|CTLFLAG_RW, &VNET_NAME(dctcp_slowstart), 0, + &dctcp_slowstart_handler, + "IU", "half CWND reduction after the first slow start"); + +DECLARE_CC_MODULE(dctcp, &dctcp_cc_algo); diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index 20c22ed..2822248 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -455,6 +455,32 @@ cc_post_recovery(struct tcpcb *tp, struct tcphdr *th) tp->t_bytes_acked = 0; } +/* + * Indicate whether this ack should be delayed. We can delay the ack if + * - there is no delayed ack timer in progress and + * - our last ack wasn't a 0-sized window. We never want to delay + * the ack that opens up a 0-sized window and + * - delayed acks are enabled or + * - this is a half-synchronized T/TCP connection. + */ +#define DELAY_ACK(tp) \ + ((!tcp_timer_active(tp, TT_DELACK) && \ + (tp->t_flags & TF_RXWIN0SENT) == 0) && \ + (V_tcp_delack_enabled || (tp->t_flags & TF_NEEDSYN))) + +static void inline +cc_ecnpkt_handler(struct tcpcb *tp, struct tcphdr *th, uint8_t iptos) +{ + INP_WLOCK_ASSERT(tp->t_inpcb); + + if (CC_ALGO(tp)->ecnpkt_handler != NULL) { + if (CC_ALGO(tp)->ecnpkt_handler(tp->ccv, iptos, + (th->th_flags & TH_CWR), DELAY_ACK(tp))) { + tcp_timer_activate(tp, TT_DELACK, tcp_delacktime); + } + } +} + static inline void tcp_fields_to_host(struct tcphdr *th) { @@ -502,19 +528,6 @@ do { \ #endif /* - * Indicate whether this ack should be delayed. We can delay the ack if - * - there is no delayed ack timer in progress and - * - our last ack wasn't a 0-sized window. We never want to delay - * the ack that opens up a 0-sized window and - * - delayed acks are enabled or - * - this is a half-synchronized T/TCP connection. - */ -#define DELAY_ACK(tp) \ - ((!tcp_timer_active(tp, TT_DELACK) && \ - (tp->t_flags & TF_RXWIN0SENT) == 0) && \ - (V_tcp_delack_enabled || (tp->t_flags & TF_NEEDSYN))) - -/* * TCP input handling is split into multiple parts: * tcp6_input is a thin wrapper around tcp_input for the extended * ip6_protox[] call format in ip6_input @@ -1539,6 +1552,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, struct socket *so, TCPSTAT_INC(tcps_ecn_ect1); break; } + + /* Process a packet differently from RFC3168. */ + cc_ecnpkt_handler(tp, th, iptos); + /* Congestion experienced. */ if (thflags & TH_ECE) { cc_cong_signal(tp, th, CC_ECN); diff --git a/sys/netinet/tcp_output.c b/sys/netinet/tcp_output.c index 00d5415..30e9b19 100644 --- a/sys/netinet/tcp_output.c +++ b/sys/netinet/tcp_output.c @@ -162,6 +162,18 @@ cc_after_idle(struct tcpcb *tp) CC_ALGO(tp)->after_idle(tp->ccv); } +static int inline +cc_ect_handler(struct tcpcb *tp) +{ + INP_WLOCK_ASSERT(tp->t_inpcb); + + if (CC_ALGO(tp)->ect_handler != NULL) { + if (CC_ALGO(tp)->ect_handler(tp->ccv)) + return (1); + } + return (0); +} + /* * Tcp output routine: figure out what should be sent and send it. */ @@ -966,9 +978,15 @@ send: * If the peer has ECN, mark data packets with * ECN capable transmission (ECT). * Ignore pure ack packets, retransmissions and window probes. + * Mark data packet with ECN capable transmission (ECT) + * when CC_ALGO meets specific condition. + * Or, if the peer has ECN, mark data packets with ECT + * (RFC 3168). Ignore pure ack packets, retransmissions + * and window probes. */ - if (len > 0 && SEQ_GEQ(tp->snd_nxt, tp->snd_max) && - !((tp->t_flags & TF_FORCEDATA) && len == 1)) { + int mark_ect = cc_ect_handler(tp); + if (mark_ect || (len > 0 && SEQ_GEQ(tp->snd_nxt, tp->snd_max) + && !((tp->t_flags & TF_FORCEDATA) && len == 1))) { #ifdef INET6 if (isipv6) ip6->ip6_flow |= htonl(IPTOS_ECN_ECT0 << 20); --Apple-Mail=_5AB129EF-65C5-4C0E-ACC4-CE048EBD9985 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_5AB129EF-65C5-4C0E-ACC4-CE048EBD9985-- --Apple-Mail=_BAE04A14-8EAB-4CA7-89EF-860A13E6E143 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwR20tZcnpRveo1xAQK0zAQAjxgL0C3ZwSCNS+EHWgu2ogmsXEod9ufc mrCznwe0FgPS79ztnZq6QTYaKvZbkeDyRMyfDvG14xxsPdKVlksVUBtUym+tRpDy n5CeQhXlUxbZVllrtF36/Dau2iTbyxAHVC/EIx3GvQVGtw39rataavu/h2+GjKox cFw4QbOlmJU= =7dfk -----END PGP SIGNATURE----- --Apple-Mail=_BAE04A14-8EAB-4CA7-89EF-860A13E6E143-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 09:33:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E333FB3A for ; Wed, 19 Feb 2014 09:33:14 +0000 (UTC) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A77AA2000 for ; Wed, 19 Feb 2014 09:33:14 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id v1so102829yhn.40 for ; Wed, 19 Feb 2014 01:33:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oTAOITM99R75ZY2TSGg7ByvfnRMZz9nFOfk8tbAEC8U=; b=SdL1swyLe21DhM1LgT/SQoHJphZF4PYdXqIrPN6BLg/XLr91ZbqzsiR3p0s/o2nIfa Z6yEzwImItzvPBMj9IlWXJN866Qc0bpzB2POR5BpopILBoYCuhGb4yapCjQapEBBZ7wH KNqeDRhdKWVI9EhhglrfcxJToN3xu2nhubfsNOAAqGrETeXn3MQ2dI3R/Dv37zx9DvQe BsaxWwQkBkrdaD8lsPp0a8soorritStmi+r+Zu5ZGMBTzl4uz6lzCe2AGBYeezUT5b8w PsRPLz1T54LQC5hQMZE9rMjV8gAsPcXNUuQvk4R7nlLjGatXCjBc+CXEf04hzzMimoAN ViZw== X-Gm-Message-State: ALoCoQlMoS3EoFM9KLUm3u6MHxzoz30Znwb0xT+4E2IHzPgRO9PWFKbWGmCPavs5jYPgdZcMlXO9 MIME-Version: 1.0 X-Received: by 10.236.220.195 with SMTP id o63mr3417646yhp.149.1392801053345; Wed, 19 Feb 2014 01:10:53 -0800 (PST) Received: by 10.170.160.214 with HTTP; Wed, 19 Feb 2014 01:10:53 -0800 (PST) Date: Wed, 19 Feb 2014 09:10:53 +0000 Message-ID: Subject: Where has my /dev/label gone? From: Lucian To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 09:33:15 -0000 Hi, I set up some labels (glabel label blah /dev/partition) and they show up fine in /dev/label, but once I reboot out of single user mode and into nornal mode /dev/label is gone. What am I missing? Regards, Lucian From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 09:57:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26BB0BF7 for ; Wed, 19 Feb 2014 09:57:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2B571224 for ; Wed, 19 Feb 2014 09:56:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=B1Yd7KpUuUSO3JR8b6q6XznvMrg1FOm2ib+cdllqKB0=; b=JfmbiCml1vBIBSAS0EsnwLsvbvB8/ih/G8mV5W37NWhDSZ88Q7K17jMpuYNzrFzFC50EKw+maX6rWMv5+d5N2TFI8JxEN4cvFC1RlSsGeTfKL6iqjO86gZXce715uQcC7OTp7ukJPX42AesKsw7XIzZjleAWUWiurlawj7k5Viw=; Received: from [39.212.216.37] (port=18276 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WG3th-002raO-My; Wed, 19 Feb 2014 02:56:58 -0700 Date: Wed, 19 Feb 2014 17:56:43 +0800 From: Erich Dollansky To: Lucian Subject: Re: Where has my /dev/label gone? Message-ID: <20140219175643.0e744028@X220.alogt.com> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 09:57:00 -0000 Hi, On Wed, 19 Feb 2014 09:10:53 +0000 Lucian wrote: > I set up some labels (glabel label blah /dev/partition) and they show > up fine in /dev/label, but once I reboot out of single user mode and > into nornal mode /dev/label is gone. > > What am I missing? Bermuda triangle? It sounds strange. Ok, you this in the single user mode. Why? What devices did you label? Hopefully not the devices in use. This does not work from my point of view. You would have to use another label type then. Erich From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 11:23:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21E45E3F for ; Wed, 19 Feb 2014 11:23:11 +0000 (UTC) Received: from smtp.novso.com (smtp1.novso.com [193.189.104.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDAC81A26 for ; Wed, 19 Feb 2014 11:23:10 +0000 (UTC) Message-ID: <1392808981.10645.15.camel@srv31.corp.novso.com> Subject: Re: ipsec foils traceroute on gre/gif From: Nicolas DEFFAYET To: David DeSimone Date: Wed, 19 Feb 2014 11:23:01 +0000 In-Reply-To: References: <201402180613.s1I6DdhS020353@dark.beer.net> Organization: DEFFAYET.COM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3.noclutter Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Michael Glasgow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 11:23:11 -0000 On Tue, 2014-02-18 at 13:26 -0500, David DeSimone wrote: > My understanding of this issue is that replying with an ICMP message for traceroute carries the risk of violating security policy. > > When an ICMP Unreachable packet is generated, the first 64 octets in the packet are copied into the reply. If the packet was originally encrypted with IPSEC, those octets were never seen unencrypted on the wire. If the ICMP Unreachable were permitted to be generated and sent, it could very well reveal the unencrypted IPSEC packet contents on the wire, because the source/destination IP's of the ICMP message no longer matches SPD's. > > Thus the conservative decision in the kernel is to drop the TTL-exceeded packet coming from IPSEC, with no reply. > > In other words, "working as intended." Is it possible to add a sysctl for turn on/off this per interface or it's too complex ? -- Nicolas DEFFAYET From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 12:03:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24DE33E2 for ; Wed, 19 Feb 2014 12:03:05 +0000 (UTC) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD3A41DC6 for ; Wed, 19 Feb 2014 12:03:04 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t61so245958wes.28 for ; Wed, 19 Feb 2014 04:02:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:message-id:from:to:cc:subject:date :mime-version:content-type:content-disposition :content-transfer-encoding; bh=APZppgJslSbzcU/A9hsOXqJ+5XyyQBMjIc1xwcGtRFA=; b=SWI27/V3WI9xDIiJczjLp3oFpFLMREFsub9uHCfPpA7ak5h1eBgv1H6VrTRAwEVqKp g+soJAwDem3lQwX+7s1ZKx8ZwG9Y5XWvgraD30BZue4hvmv+JWs2RybHmvbry9LBx/Dq R0Hltabby5O1OwMNlibTFnrKkA9w1O06OfLG8za+jNC/4T20qxWw0PRgD36pZGiuyckX AihPDnZaSvmgOnxtfuKzl+oPbXsA6QA0SkMdOlcCNuzNfa1q4Zswf9Et/+3ekQAEc3rU uSKIHT8OnG+6UzH27Bb+94MDczsUdyWmfWwTDr35Kw+VJ4ctVBjWsxB0g93p7kg7DG3B AZ8g== X-Gm-Message-State: ALoCoQkk9SzVgMQTN7d9wIEb6xO6Qb8ArdoSFQ+6puTdW8Mge8YZiy62p0dZdzy097Czss1SniFj X-Received: by 10.194.57.239 with SMTP id l15mr23652591wjq.40.1392810883971; Wed, 19 Feb 2014 03:54:43 -0800 (PST) Received: from workvmetc ([85.13.211.140]) by mx.google.com with ESMTPSA id j9sm53302572wjz.13.2014.02.19.03.54.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2014 03:54:43 -0800 (PST) References: <20140219175643.0e744028@X220.alogt.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: lucian@lastdot.org To: Erich Dollansky Subject: Re: Where has my /dev/label =?UTF-8?Q?gone=3F?= Date: Wed, 19 Feb 2014 11:54:40 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 12:03:05 -0000 Erich Dollansky writes: > Hi, > > On Wed, 19 Feb 2014 09:10:53 +0000 > Lucian wrote: > > > I set up some labels (glabel label blah /dev/partition) and they show > > up fine in /dev/label, but once I reboot out of single user mode and > > into nornal mode /dev/label is gone. > > > > What am I missing? > > Bermuda triangle? > > It sounds strange. Ok, you this in the single user mode. Why? What > devices did you label? > > Hopefully not the devices in use. This does not work from my point of > view. You would have to use another label type then. > > Erich I did this in single user because according to the docs you can't do it on a "live system". http://www.freebsd.org/doc/handbook/geom-glabel.html From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 12:09:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34A1F957 for ; Wed, 19 Feb 2014 12:09:37 +0000 (UTC) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE4671E5A for ; Wed, 19 Feb 2014 12:09:36 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id u56so256384wes.3 for ; Wed, 19 Feb 2014 04:09:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:message-id:from:to:cc:subject:date :mime-version:content-type:content-disposition :content-transfer-encoding; bh=WBpKcBgXafSdvfwIzy4W8f2b0OxZE4v/mquYmM/S8LU=; b=eOQqZmW6O15+iTAB02YDw6d8OkwQC8gmoXkyIeqPqMDa+2kwUDij9QaEg1G/XGzqOh tB+12BhVhuF9gljYrfC37E+rWii3qgHe7XFbD5jDuDZAdodjSXnyqxQO9lBU3Lo3rLk2 C7vjc2eUYd/Jvy0x6B2uxEP7YqVbSnAYnigO6qp0uTjZ+RjZuK6BU4RBUF4E9nkj58iW 1TnCf7x5vvFJJ1KqkoK4jEZGk/czt1Xi5786XpS4NBxzCur8ar4gBmqczxxTPsXS48w3 rV1MfT/UVeYlCwVJNUIkGJPQ/6euG1J3I5EDfiHQowMPKEr7Q0NdruVNMQqSnPS5GSny +xsg== X-Gm-Message-State: ALoCoQnbr/jsxvQdjilIl5v9LBal594dxi3rqdLKRQxuoBDOZe+FJhDkkf0ye6UZ7m8oz1qKCQwK X-Received: by 10.180.73.141 with SMTP id l13mr1077291wiv.60.1392811364875; Wed, 19 Feb 2014 04:02:44 -0800 (PST) Received: from workvmetc ([85.13.211.140]) by mx.google.com with ESMTPSA id br10sm53322847wjb.3.2014.02.19.04.02.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2014 04:02:44 -0800 (PST) References: <20140219175643.0e744028@X220.alogt.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: lucian@lastdot.org To: Erich Dollansky Subject: Re: Where has my /dev/label =?UTF-8?Q?gone=3F?= Date: Wed, 19 Feb 2014 12:02:42 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 12:09:37 -0000 Erich Dollansky writes: > Hi, > > On Wed, 19 Feb 2014 09:10:53 +0000 > Lucian wrote: > > > I set up some labels (glabel label blah /dev/partition) and they show > > up fine in /dev/label, but once I reboot out of single user mode and > > into nornal mode /dev/label is gone. > > > > What am I missing? > > Bermuda triangle? > > It sounds strange. Ok, you this in the single user mode. Why? What > devices did you label? > > Hopefully not the devices in use. This does not work from my point of > view. You would have to use another label type then. > > Erich BTW, if I go back in single user I can see /dev/label and the expected labels in it. This disappears once I go multiuser. From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 12:14:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F102BC4 for ; Wed, 19 Feb 2014 12:14:44 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 545161FFF for ; Wed, 19 Feb 2014 12:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=//GMLz+p9RySUQIwx/lqL43PLYNEgtL4fnyJrn+UYTA=; b=j5QB+I70bxb54eaJ+I6+B6AivVGKv04DXS7y3xBxQ7w+BWvsTkGluvdpAXR3nEU9vZ8u+oZ2YrUeii2JzYPg2Whak6WfvjITKSkrujYqjw+NiFqfgcyYMspQav4XYXysKZvhV0NpNpV9uNzudIzviBkKdYeoImRUCLFalXiAsNQ=; Received: from [39.212.216.37] (port=42185 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WG631-004GP0-0k; Wed, 19 Feb 2014 05:14:44 -0700 Date: Wed, 19 Feb 2014 20:14:20 +0800 From: Erich Dollansky To: lucian@lastdot.org Subject: Re: Where has my /dev/label gone? Message-ID: <20140219201420.7d2f7e1c@X220.alogt.com> In-Reply-To: References: <20140219175643.0e744028@X220.alogt.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 12:14:44 -0000 Hi, On Wed, 19 Feb 2014 11:54:40 +0000 lucian@lastdot.org wrote: > Erich Dollansky writes: > > > On Wed, 19 Feb 2014 09:10:53 +0000 > > Lucian wrote: > > > > > I set up some labels (glabel label blah /dev/partition) and they > > > show up fine in /dev/label, but once I reboot out of single user > > > mode and into nornal mode /dev/label is gone. > > > > > > What am I missing? > > > > Bermuda triangle? > > > > It sounds strange. Ok, you this in the single user mode. Why? What > > devices did you label? > > > > Hopefully not the devices in use. This does not work from my point > > of view. You would have to use another label type then. > > I did this in single user because according to the docs you can't do > it on a "live system". > http://www.freebsd.org/doc/handbook/geom-glabel.html do you have this in your kernel? options GEOM_LABEL You can also load the module at boot time with an entry in /boot/loader.conf. Erich From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 12:32:41 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D07931A7 for ; Wed, 19 Feb 2014 12:32:41 +0000 (UTC) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6580611BC for ; Wed, 19 Feb 2014 12:32:40 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so269363wgg.13 for ; Wed, 19 Feb 2014 04:32:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:message-id:from:to:cc:subject:date :mime-version:content-type:content-disposition :content-transfer-encoding; bh=SZzsZoS/RxZgqJPolgOggCBShWqRw7UHds5yVEfmySk=; b=F++/YVkQjmFJyYuGWGmyDjpT/YCJ2tQ9A0aDuCEYcyg6g/tXlJS+H/yycR0BKaYrEb x7jUy4qVDVpdq2XyORVdiBPgx08BoNT2IVCruqw74Tu5qR8zpD7C175Qp43UeXeenGIk IkwSWfCBMD1yNHZpZsatrzq+j2+L4IDjgLACyA47S0GvbNRLODuFlMt63Zm2UaV6HxDg jgC3+q9w5gC12yeesVNkDvpQWul3Zhc65cswAzQ4y8TgwKng137yGqc1F3a2kRcQc316 77qci3lOe6y+2TazyGAV9bsFrHrRaTiU8+dpxHfBy9PESpRbVYHK2gT2Ttm8ogpCW+52 3c1A== X-Gm-Message-State: ALoCoQkVEAmQ7LMK11HoLZ7QECVZnbZsxCsDEdcFrsDjenW6K9sUkVEqWNWOwYeckuU58NMHCjBF X-Received: by 10.194.118.228 with SMTP id kp4mr657070wjb.94.1392812670494; Wed, 19 Feb 2014 04:24:30 -0800 (PST) Received: from workvmetc ([85.13.211.140]) by mx.google.com with ESMTPSA id cm5sm1259777wid.5.2014.02.19.04.24.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2014 04:24:30 -0800 (PST) References: <20140219175643.0e744028@X220.alogt.com> <20140219201420.7d2f7e1c@X220.alogt.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: lucian@lastdot.org To: Erich Dollansky Subject: Re: Where has my /dev/label =?UTF-8?Q?gone=3F?= Date: Wed, 19 Feb 2014 12:24:28 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 12:32:41 -0000 Erich Dollansky writes: > Hi, > > On Wed, 19 Feb 2014 11:54:40 +0000 > lucian@lastdot.org wrote: > > > Erich Dollansky writes: > > > > > On Wed, 19 Feb 2014 09:10:53 +0000 > > > Lucian wrote: > > > > > > > I set up some labels (glabel label blah /dev/partition) and they > > > > show up fine in /dev/label, but once I reboot out of single user > > > > mode and into nornal mode /dev/label is gone. > > > > > > > > What am I missing? > > > > > > Bermuda triangle? > > > > > > It sounds strange. Ok, you this in the single user mode. Why? What > > > devices did you label? > > > > > > Hopefully not the devices in use. This does not work from my point > > > of view. You would have to use another label type then. > > > > I did this in single user because according to the docs you can't do > > it on a "live system". > > http://www.freebsd.org/doc/handbook/geom-glabel.html > > do you have this in your kernel? > > options GEOM_LABEL > > You can also load the module at boot time with an entry > in /boot/loader.conf. > > Erich I have GEOM_LABEL loaded, but I noticed something strange. If I boot in single user, I can create and see the labels under /dev/label, however if I remount the / filesystem RW then /dev/label disappears. BUT, if I just replace my / partition in fstab with the seemingly missing label (eg /dev/label/rootfs) then the system boots up fine and /dev/label is again available to `ls`. Strange stuff, it should be covered in the handbook... Problem solved, I guess. From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 12:38:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71C90307 for ; Wed, 19 Feb 2014 12:38:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4659B1211 for ; Wed, 19 Feb 2014 12:38:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=GNrRkRrqtRSNlDvXJRBG5H5lb8EW2OKdOAdR61G+1W4=; b=R+8eP76JZC8W1oL1ZBPzxCBhjOT7lbxHYtbk4AR8ni2Zm5wUgjNaqo4pCxmUjKSxRnsxIv0tDcvyjLEcB44MeyJVBU4QvlqeHwtY+J4S5oAuXHiM1pMCyTL8HbeL8QV2U1XjDrlfHWK9lxYfD6nDq5W/QyHm3qF4lpIroMP07aY=; Received: from [39.212.216.37] (port=33452 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WG6Q2-0007UC-6J; Wed, 19 Feb 2014 05:38:31 -0700 Date: Wed, 19 Feb 2014 20:38:25 +0800 From: Erich Dollansky To: lucian@lastdot.org Subject: Re: Where has my /dev/label gone? Message-ID: <20140219203825.399fa2f4@X220.alogt.com> In-Reply-To: References: <20140219175643.0e744028@X220.alogt.com> <20140219201420.7d2f7e1c@X220.alogt.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 12:38:32 -0000 Hi, On Wed, 19 Feb 2014 12:24:28 +0000 lucian@lastdot.org wrote: > Erich Dollansky writes: > > > I have GEOM_LABEL loaded, but I noticed something strange. > If I boot in single user, I can create and see the labels > under /dev/label, however if I remount the / filesystem RW > then /dev/label disappears. BUT, if I just replace my / partition in > fstab with the seemingly missing label (eg /dev/label/rootfs) then > the system boots up fine and /dev/label is again available to `ls`. > Strange stuff, it should be covered in the handbook... > Problem solved, I guess. this is what you need. After the partition is mounted, the label is not used anymore. Erich From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 14:26:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA1085ED for ; Wed, 19 Feb 2014 14:26:53 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 711621B81 for ; Wed, 19 Feb 2014 14:26:53 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so332413lbv.24 for ; Wed, 19 Feb 2014 06:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sm9DPHwRD91lW+F9hIuj0nLUYF84MlL0qQ8PgNXHq4g=; b=O3JXIenXfzulvjJtCM6kCfTVsgrG9PvMXsQwBD6pJ8E3Qg7QaeQgr2yTccqE8CPUnF lMZSvUrH65wrSnMcU+ogN6Re17mIEE/cpCb5CdAGoV6+i51kQrxKBe5rqzxUvZr1XptN nUThZbJjU0JXjKRmU+dUAFxPa3UXJqo4h1W2e1E9BspTXodPXboCDSrz4R1MSdiHcIdu I/1ivK7hwqDW4DfX8drWSCvL7GGxgUTymite10z98TQtQHOmUN4CB9Hls+X+Vjul4xjn oAmcSWTucXuD9tXnkyl8YbA6oQBYfQDZNvf2AOnW+1PcEKCbCmmxI68zUxEoGnXsKLH2 gt3w== MIME-Version: 1.0 X-Received: by 10.112.128.170 with SMTP id np10mr25173128lbb.22.1392820011394; Wed, 19 Feb 2014 06:26:51 -0800 (PST) Received: by 10.112.35.167 with HTTP; Wed, 19 Feb 2014 06:26:51 -0800 (PST) In-Reply-To: References: <20140219175643.0e744028@X220.alogt.com> <20140219201420.7d2f7e1c@X220.alogt.com> Date: Wed, 19 Feb 2014 14:26:51 +0000 Message-ID: Subject: Re: Where has my /dev/label gone? From: Tom Evans To: lucian@lastdot.org Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 14:26:54 -0000 On Wed, Feb 19, 2014 at 12:24 PM, wrote: > I have GEOM_LABEL loaded, but I noticed something strange. > If I boot in single user, I can create and see the labels under /dev/label, > however if I remount the / filesystem RW then /dev/label disappears. > BUT, if I just replace my / partition in fstab with the seemingly missing > label (eg /dev/label/rootfs) then the system boots up fine and /dev/label is > again available to `ls`. Strange stuff, it should be covered in the > handbook... > Problem solved, I guess. When you mount a geom, any other names that it has are removed. Thus, if you label "ada1p1" as "foo", but mount it as "ada1p1", then the label "foo" disappears. Logical once you think about it. Cheers Tom PS: Why is this -net? From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 15:53:10 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8A49184; Wed, 19 Feb 2014 15:53:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCB9E156B; Wed, 19 Feb 2014 15:53: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 s1JFr5iB088527; Wed, 19 Feb 2014 15:53:10 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JFr0B8088487; Wed, 19 Feb 2014 16:53:00 +0100 (CET) (envelope-from brueffer) Date: Wed, 19 Feb 2014 16:53:00 +0100 (CET) Message-Id: <201402191553.s1JFr0B8088487@freefall.freebsd.org> To: oberman@es.net, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: bin/98218: wpa_supplicant(8) blacklist not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 15:53:11 -0000 Synopsis: wpa_supplicant(8) blacklist not working State-Changed-From-To: open->feedback State-Changed-By: brueffer State-Changed-When: Wed Feb 19 16:52:12 CET 2014 State-Changed-Why: Hi Kevin, wpa_supplicant has been updated since this PR was filed. Do you still see this behaviour in newer FreeBSD releases? http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 16:34:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4787E651 for ; Wed, 19 Feb 2014 16:34:31 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1EBA198C for ; Wed, 19 Feb 2014 16:34:30 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1JGYQaL059801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Feb 2014 09:34:26 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1JGYOOB059798; Wed, 19 Feb 2014 09:34:26 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 19 Feb 2014 09:34:24 -0700 (MST) From: Warren Block To: lucian@lastdot.org Subject: Re: Where has my /dev/label gone? In-Reply-To: Message-ID: References: <20140219175643.0e744028@X220.alogt.com> <20140219201420.7d2f7e1c@X220.alogt.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 19 Feb 2014 09:34:26 -0700 (MST) Cc: freebsd-net@freebsd.org, Erich Dollansky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 16:34:31 -0000 On Wed, 19 Feb 2014, lucian@lastdot.org wrote: > I have GEOM_LABEL loaded, but I noticed something strange. > If I boot in single user, I can create and see the labels under /dev/label, > however if I remount the / filesystem RW then /dev/label disappears. > BUT, if I just replace my / partition in fstab with the seemingly missing > label (eg /dev/label/rootfs) then the system boots up fine and /dev/label is > again available to `ls`. Strange stuff, it should be covered in the > handbook... > Problem solved, I guess. GEOM hides devices that are mounted. Most of them, or some of the time, or maybe only certain types, the rules are not clear. From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 16:51:58 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D0A6D73; Wed, 19 Feb 2014 16:51:58 +0000 (UTC) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C12D1B52; Wed, 19 Feb 2014 16:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=YqSDBPut++8h5MEBt7drEwGhLqVLkYCwsoeEX2qUoaE=; b=G/enxwKOGJaslMNapHYIiGJKEuIA8vkTL/wtRuH7DwcE1PHeUQUeQsNBqNG5AlFkVi2r oXfu8eaCYEnRRfPNf7nKInpcEH8ElJsbNomq4TYZpsn3mqDLXMAsLDrWkb5VIkbAFvTi Ym5O4THngm4efogmGkHgKngtvo9PABD3bJw= Received: from rogue.local (pool-71-102-47-150.plspca.fios.verizon.net [71.102.47.150]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id s1JGptNn019890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Feb 2014 08:51:56 -0800 Message-ID: <5304E12B.9090003@es.net> Date: Wed, 19 Feb 2014 08:51:55 -0800 From: Kevin Oberman Organization: ESnet -- The Energy Sciences Network User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: brueffer@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: bin/98218: wpa_supplicant(8) blacklist not working References: <201402191553.s1JFr0B8088487@freefall.freebsd.org> In-Reply-To: <201402191553.s1JFr0B8088487@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-19_05:2014-02-18,2014-02-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305240000 definitions=main-1402190088 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 16:51:58 -0000 In the eight years since I reported this issue, I have retired and no longer have the means to test the issue. I guess you might as well close this one. On 02/19/2014 07:53, brueffer@FreeBSD.org wrote: > Synopsis: wpa_supplicant(8) blacklist not working > > State-Changed-From-To: open->feedback > State-Changed-By: brueffer > State-Changed-When: Wed Feb 19 16:52:12 CET 2014 > State-Changed-Why: > Hi Kevin, wpa_supplicant has been updated since this PR was filed. Do you > still see this behaviour in newer FreeBSD releases? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 -- R. Kevin Oberman, Network Engineer Emeritus Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 17:00:26 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3266289; Wed, 19 Feb 2014 17:00:26 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8DE31BE6; Wed, 19 Feb 2014 17:00:26 +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 s1JH0QBT020478; Wed, 19 Feb 2014 17:00:26 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JH0QVO020477; Wed, 19 Feb 2014 18:00:26 +0100 (CET) (envelope-from brueffer) Date: Wed, 19 Feb 2014 18:00:26 +0100 (CET) Message-Id: <201402191700.s1JH0QVO020477@freefall.freebsd.org> To: oberman@es.net, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: bin/98218: wpa_supplicant(8) blacklist not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 17:00:27 -0000 Synopsis: wpa_supplicant(8) blacklist not working State-Changed-From-To: feedback->closed State-Changed-By: brueffer State-Changed-When: Wed Feb 19 17:57:32 CET 2014 State-Changed-Why: Hi Kevin, thanks for the quick answer and sorry this PR sat around for so long. I close the PR with this, but in case you come into the situation where you can test this again, we'd be happy to hear your report. Happy retirement! http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 17:07:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 588238C0 for ; Wed, 19 Feb 2014 17:07:35 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE6C1CC9 for ; Wed, 19 Feb 2014 17:07:35 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WG6lO-000Pm0-AU; Wed, 19 Feb 2014 17:00:34 +0400 Message-ID: <5304E4BD.3050703@FreeBSD.org> Date: Wed, 19 Feb 2014 21:07:09 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: venom , freebsd-net@freebsd.org Subject: Re: how to delete second default route ipv6? References: In-Reply-To: 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.17 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, 19 Feb 2014 17:07:35 -0000 On 19.02.2014 10:43, venom wrote: > Hello, All. > > i have a problem with procedure of delete second ipv6 default route > > > # netstat -f inet6 -nr | grep default > default fe80::7afe:3dff:feef:66c1%lagg0 UG > lagg0 => > default fe80::210:dbff:feff:1002%lagg0 UG lagg0 > > # route delete -inet6 default > route: writing to routing socket: No such process > delete net default: not in table Can you try deleting route specifying gateway along with destination ? > > # uname -a > FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 > UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > > > > -- > Vladimir Laskov > samflanker@gmail.com > _______________________________________________ > 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 Wed Feb 19 17:11:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09933AFA; Wed, 19 Feb 2014 17:11:51 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4F0B1D78; Wed, 19 Feb 2014 17:11:50 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id x13so991937qcv.20 for ; Wed, 19 Feb 2014 09:11:49 -0800 (PST) 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=1OEdk3J4YbSsVZ2iQuDRX0F7SkjfgWMdImH7Q8Bv574=; b=LLlp8q11WzoOzkEOiYkaBeNr58OFWr88ICyKt5T5ZlZzV0lp9Micrje61dHDrUSRFt rgUoxPg9JSizKJUGoN8BiIfNsn0lfUj7ot760OSG55O2uZX1n1/nREI1sdu8I7EAoQUK NDTix6rLuBjzG5Vt/9IjnvpwUyzKo17wZsl849L+JruiRDjnWCKDuHoTg0mUVBrDgeQw KMRSU9G/hI080bmfvSwSgyoxfSKrrtYd7Egd9OnDBKIfZRzghqMOQwOtrqcI8eA4LGqh 0Xcgzl3HWGuzgg/UD4wTYQ5mMlOuy3MXuNTrAM56+MQpAOehL83cRQthScjrn14K6Hm6 nUTw== MIME-Version: 1.0 X-Received: by 10.224.162.200 with SMTP id w8mr51996137qax.1.1392829909881; Wed, 19 Feb 2014 09:11:49 -0800 (PST) Received: by 10.140.43.55 with HTTP; Wed, 19 Feb 2014 09:11:49 -0800 (PST) In-Reply-To: <5304E4BD.3050703@FreeBSD.org> References: <5304E4BD.3050703@FreeBSD.org> Date: Wed, 19 Feb 2014 21:11:49 +0400 Message-ID: Subject: Re: how to delete second default route ipv6? From: venom To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 17:11:51 -0000 yes, but do not help ( work `route flush -inet6` only -- Vladimir Laskov On Wed, Feb 19, 2014 at 9:07 PM, Alexander V. Chernikov wrote: > On 19.02.2014 10:43, venom wrote: >> >> Hello, All. >> >> i have a problem with procedure of delete second ipv6 default route >> >> >> # netstat -f inet6 -nr | grep default >> default fe80::7afe:3dff:feef:66c1%lagg0 UG >> lagg0 => >> default fe80::210:dbff:feff:1002%lagg0 UG >> lagg0 >> >> # route delete -inet6 default >> route: writing to routing socket: No such process >> delete net default: not in table > > Can you try deleting route specifying gateway along with destination ? >> >> >> # uname -a >> FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 >> UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> >> >> -- >> Vladimir Laskov >> samflanker@gmail.com >> _______________________________________________ >> 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 Wed Feb 19 17:38:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E1DB101 for ; Wed, 19 Feb 2014 17:38:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35F2D1075 for ; Wed, 19 Feb 2014 17:38:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1JHcOhs005618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 09:38:25 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1JHcOYc005617; Wed, 19 Feb 2014 09:38:24 -0800 (PST) (envelope-from jmg) Date: Wed, 19 Feb 2014 09:38:24 -0800 From: John-Mark Gurney To: lucian@lastdot.org Subject: Re: Where has my /dev/label gone? Message-ID: <20140219173824.GI34851@funkthat.com> Mail-Followup-To: lucian@lastdot.org, Erich Dollansky , freebsd-net@freebsd.org References: <20140219175643.0e744028@X220.alogt.com> <20140219201420.7d2f7e1c@X220.alogt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 19 Feb 2014 09:38:25 -0800 (PST) Cc: freebsd-net@freebsd.org, Erich Dollansky X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 17:38:28 -0000 lucian@lastdot.org wrote this message on Wed, Feb 19, 2014 at 12:24 +0000: > Erich Dollansky writes: > > >On Wed, 19 Feb 2014 11:54:40 +0000 > >lucian@lastdot.org wrote: > > > >> Erich Dollansky writes: > >> > >> > On Wed, 19 Feb 2014 09:10:53 +0000 > >> > Lucian wrote: > >> > > >> > > I set up some labels (glabel label blah /dev/partition) and they > >> > > show up fine in /dev/label, but once I reboot out of single user > >> > > mode and into nornal mode /dev/label is gone. > >> > > > >> > > What am I missing? > >> > > >> > Bermuda triangle? > >> > > >> > It sounds strange. Ok, you this in the single user mode. Why? What > >> > devices did you label? > >> > > >> > Hopefully not the devices in use. This does not work from my point > >> > of view. You would have to use another label type then. > >> > >> I did this in single user because according to the docs you can't do > >> it on a "live system". > >> http://www.freebsd.org/doc/handbook/geom-glabel.html > > > >do you have this in your kernel? > > > >options GEOM_LABEL > > > >You can also load the module at boot time with an entry > >in /boot/loader.conf. > > > >Erich > > I have GEOM_LABEL loaded, but I noticed something strange. > If I boot in single user, I can create and see the labels under /dev/label, > however if I remount the / filesystem RW then /dev/label disappears. > BUT, if I just replace my / partition in fstab with the seemingly missing > label (eg /dev/label/rootfs) then the system boots up fine and /dev/label > is again available to `ls`. Strange stuff, it should be covered in the > handbook... > Problem solved, I guess. This is correct, but it's not for the reason people are saying... The label is in the partition, say ada0s1a... When you mount ada0s1a for writing (which also sets exclusive access, not just reading), all children geoms will wither away because you won't be able to open the children for reading as the mounted partition has exclusive access.. If you later were to remount the partition read-only (I'm not sure if this drops exclusive/write access, but if it does), then the labels will show up again, assuming the file system didn't overwrite the label... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 18:29:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AD04EA2 for ; Wed, 19 Feb 2014 18:29:12 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31C4914C2 for ; Wed, 19 Feb 2014 18:29:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WGBtN-0000Bk-0x for freebsd-net@freebsd.org; Wed, 19 Feb 2014 19:29:09 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Feb 2014 19:29:09 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Feb 2014 19:29:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Kevin Bowling Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? Date: Wed, 19 Feb 2014 11:28:57 -0700 Lines: 88 Message-ID: References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> <11F52C6F-1A9C-4D5B-8364-AFB62322CB91@neville-neil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 In-Reply-To: <11F52C6F-1A9C-4D5B-8364-AFB62322CB91@neville-neil.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 18:29:12 -0000 On 2/18/2014 7:16 AM, George Neville-Neil wrote: > > On Feb 17, 2014, at 16:41 , Kevin Bowling wrote: > >> On 2/16/2014 9:04 PM, George Neville-Neil wrote: >>> >>> On Feb 15, 2014, at 21:32 , Kevin Bowling wrote: >>> >>>> On 2/15/2014 4:43 PM, George Neville-Neil wrote: >>>>> >>>>> On Feb 15, 2014, at 15:14 , Kevin Bowling wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each node has an Intel X520-DA2 dual port 10gig card. One of the ports on each go to a switch using direct attach coaxial cables. The other port is directly connected between the two nodes (think crossover in twisted pair terminology) again using direct attach coaxial cables. >>>>>> >>>>>> On both machines, and on both ports (including the "crossover"), the links flap several times per day. >>>>>> >>>>>> I've pasted the output of lspci -vv and dmesg here: >>>>>> https://gist.github.com/kev009/9024442 >>>>>> >>>>>> There's nothing outstanding about the setup otherwise. I suspected some interaction with the switch initially but the "crossover" has eliminated that suspicion. >>>>>> >>>>>> It seems the ix driver is not very reliable under common conditions, i.e. https://forums.freebsd.org/viewtopic.php?f=7&t=44570 and a search of this list. Any recommendations or tests? >>>>>> >>>>> >>>>> Can you post (to your gist link) the output of sysctl dev.ix ? >>>> >>>> Hi George, >>>> >>>> sysctl info added to gist link. ix0 has been up for around 27 days. ix1 for about 24hrs. >>>> >>> >>> I think this has something to do with it. >>> >>> dev.ix.0.mac_stats.local_faults: 314 >>> dev.ix.0.mac_stats.remote_faults: 41 >>> >>> The device is seeing errors at the MAC layer, which I don’t think a driver bug would >>> cause, though there is always the possibility of a misconfiguration causing flapping. >>> Can you try different cables? >>> >>> When you hook it to the switch does the switch give better diagnostics? Reading >>> over the Intel 82599 chip manual is not, shall we say, illuminating, >>> "Number of faults in the local MAC. This register is valid only when the link speed is 10 Gb/s.” >> >> Appreciate your help, this led me to find some new info although it doesn't entirely answer what local_faluts are for me: http://grouper.ieee.org/groups/802/3/ae/public/nov00/taborek_2_1100.pdf >> >> I may have spoke too soon, the "crossover" ix1 seems to be holding steady, so the local and remote faults must have been during negotiation and me bringing up the interfaces. >> >> On the other system's ix0, the faults are almost all local and quite a bit more frequent: >> dev.ix.0.mac_stats.local_faults: 10752 >> dev.ix.0.mac_stats.remote_faults: 2 >> >> I then noticed the switch had mandatory flow control on both send and receive for 10gig, but the FreeBSD box was only negotiating receive flow control. I disabled both on the switch and rebooted but am still seeing some increments of local_faults. >> >> Could it be a switch STP problem? Switch is a Cisco 4948-10ge. Configs look like below, which is working well on some copper gigabit interfaces: >> >> spanning-tree mode pvst >> spanning-tree portfast default >> spanning-tree extend system-id >> ! >> interface TenGigabitEthernet1/49 >> switchport trunk encapsulation dot1q >> switchport mode trunk >> spanning-tree portfast trunk >> ! >> interface TenGigabitEthernet1/50 >> switchport trunk encapsulation dot1q >> switchport mode trunk >> flowcontrol receive desired >> flowcontrol send desired >> spanning-tree portfast trunk >> ! >> >> It will be hard for me to source SFPs and fiber, but I can try to see if it's a physical layer problem. In the mean time I might try imaging one of the systems with a different OS and seeing if the problem persists. >> > > Another possibility is flow control. > > Can you try this setting? > > sysctl dev.ix.0.fc=0 No luck with flow control disabled on the switch and on the interface :(. I'll continue to look into problems on the switch side. From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 18:36:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17FFDAFF; Wed, 19 Feb 2014 18:36:14 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7A7B15C4; Wed, 19 Feb 2014 18:36:13 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so1136110qae.41 for ; Wed, 19 Feb 2014 10:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1jcuy/WbWGQpre+S3NyTUPxWQ2ozkHtUa3G3SEh4bRM=; b=cfpOhyyC6NdnHT4/Rd7RbCQ7M1p1A2TGd2T3fpQlV6Ur67V6mzDPdfaRhE3homzyTZ lPAPDlw3CdP/ZRnm7vWJv+sh4Ro9HIVj0UzE/WLy20PBBlRSDKbUCe2CSxfzWu6phcEI zNSam+EmItESnuPSErk9Z/QAnzLTy8jqE6Vt1Z13SqaxhS9xeO1LN4DrnMsMCVHElnJE zyJDu9W8ADNOsYUAHL+3zJeawXbO1XGjw/cwlBwXy85eYDyy/bzxGrr9bkuoD6I0iR4G 6YRx9NfNnblLE7sIbrSv1nycOW9EGdtx+pc8KAUgQMdPFIPl01qTBO7qFJbUv1KBtzsO bTIw== MIME-Version: 1.0 X-Received: by 10.229.66.202 with SMTP id o10mr2086367qci.7.1392834972992; Wed, 19 Feb 2014 10:36:12 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 10:36:12 -0800 (PST) In-Reply-To: <5304E12B.9090003@es.net> References: <201402191553.s1JFr0B8088487@freefall.freebsd.org> <5304E12B.9090003@es.net> Date: Wed, 19 Feb 2014 10:36:12 -0800 X-Google-Sender-Auth: SdqFMpjBj63yaGDnov9saxhnn5k Message-ID: Subject: Re: bin/98218: wpa_supplicant(8) blacklist not working From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , brueffer@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 18:36:14 -0000 I think this is still a problem; so leave it open and assign to -wireless. Thanks! -a On 19 February 2014 08:51, Kevin Oberman wrote: > In the eight years since I reported this issue, I have retired and no longer > have the means to test the issue. I guess you might as well close this one. > > > On 02/19/2014 07:53, brueffer@FreeBSD.org wrote: >> >> Synopsis: wpa_supplicant(8) blacklist not working >> >> State-Changed-From-To: open->feedback >> State-Changed-By: brueffer >> State-Changed-When: Wed Feb 19 16:52:12 CET 2014 >> State-Changed-Why: >> Hi Kevin, wpa_supplicant has been updated since this PR was filed. Do you >> still see this behaviour in newer FreeBSD releases? >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 > > > -- > R. Kevin Oberman, Network Engineer Emeritus > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net > > > _______________________________________________ > 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 Wed Feb 19 18:37:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 314DDCDB for ; Wed, 19 Feb 2014 18:37:37 +0000 (UTC) Received: from mail.monkeybrains.net (mail.monkeybrains.net [208.69.40.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1305615E3 for ; Wed, 19 Feb 2014 18:37:35 +0000 (UTC) Received: from [10.6.35.14] (192-195-81-185.PUBLIC.monkeybrains.net [192.195.81.185]) (authenticated bits=0) by mail.monkeybrains.net (8.14.7/8.14.7) with ESMTP id s1JIbZJE074243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 19 Feb 2014 10:37:35 -0800 (PST) (envelope-from crapsh@monkeybrains.net) X-Authentication-Warning: mail.monkeybrains.net: Host 192-195-81-185.PUBLIC.monkeybrains.net [192.195.81.185] claimed to be [10.6.35.14] Message-ID: <5304F9EF.4000009@monkeybrains.net> Date: Wed, 19 Feb 2014 10:37:35 -0800 From: Rudy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? References: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.1 at mail.monkeybrains.net X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 18:37:37 -0000 On 02/17/2014 01:41 PM, Kevin Bowling wrote: > It will be hard for me to source SFPs and fiber, but I can try to see if > it's a physical layer problem. In the mean time I might try imaging one > of the systems with a different OS and seeing if the problem persists. $95 for a 10Gbps single mode SFP. Makes it easier to source when they are cheap: http://www.fiberstore.com/10gbps-sfp+-1310nm-10km-single-mode-optical-transceiver-p-11591.html Rudy From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 19:28:45 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AFD41DE; Wed, 19 Feb 2014 19:28:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CAF11A2D; Wed, 19 Feb 2014 19:28:45 +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 s1JJSi0D072805; Wed, 19 Feb 2014 19:28:44 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JJSiOX072804; Wed, 19 Feb 2014 20:28:44 +0100 (CET) (envelope-from brueffer) Date: Wed, 19 Feb 2014 20:28:44 +0100 (CET) Message-Id: <201402191928.s1JJSiOX072804@freefall.freebsd.org> To: oberman@es.net, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: bin/98218: wpa_supplicant(8) blacklist not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 19:28:45 -0000 Synopsis: wpa_supplicant(8) blacklist not working State-Changed-From-To: closed->open State-Changed-By: brueffer State-Changed-When: Wed Feb 19 20:27:18 CET 2014 State-Changed-Why: Adrian says this is likely still an issue, open and assign to freebsd-wireless at his request. Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: brueffer Responsible-Changed-When: Wed Feb 19 20:27:18 CET 2014 Responsible-Changed-Why: Adrian says this is likely still an issue, open and assign to freebsd-wireless at his request. http://www.freebsd.org/cgi/query-pr.cgi?pr=98218 From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 19:30:36 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AA6172B; Wed, 19 Feb 2014 19:30:36 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D233D1AB0; Wed, 19 Feb 2014 19:30:35 +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 s1JJUZfC075482; Wed, 19 Feb 2014 19:30:35 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1JJUZ72075481; Wed, 19 Feb 2014 20:30:35 +0100 (CET) (envelope-from brueffer) Date: Wed, 19 Feb 2014 20:30:35 +0100 (CET) Message-Id: <201402191930.s1JJUZ72075481@freefall.freebsd.org> To: brueffer@FreeBSD.org, freebsd-net@FreeBSD.org, maxim@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: bin/121359: [patch] [security] ppp(8): fix local stack overflow in ppp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 19:30:36 -0000 Synopsis: [patch] [security] ppp(8): fix local stack overflow in ppp Responsible-Changed-From-To: freebsd-net->maxim Responsible-Changed-By: brueffer Responsible-Changed-When: Wed Feb 19 20:30:04 CET 2014 Responsible-Changed-Why: Maxim has a patch, so assign this to him. http://www.freebsd.org/cgi/query-pr.cgi?pr=121359 From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 21:14:40 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BD87906 for ; Wed, 19 Feb 2014 21:14:40 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B81281529 for ; Wed, 19 Feb 2014 21:14:39 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id lh14so1038666vcb.10 for ; Wed, 19 Feb 2014 13:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GbAiB4fpEOxKT1y9WfWcAPk5lQpTwBteX0OnPav/JWs=; b=o5f3tdNe1AEbDTPYXmgNJ23yhfJ/JU/WlaQfWHson2qA2COCakwYS5F88NP2zvkMi7 k/X9WwACbtP9IV3m3185/XQax+9AayVk2hQlRPtiX+h/vxGexQgeRTTLcyQQDaBdWkN8 PKgs7tdcV9Lvv4XZvz/6UWB6vFx2C+nkJB9Ri3H5G7BNZt7M2p1ZUh+GjnvU8Slk+Mil L39+4IM23Bb8xR3Wemq2qKNaJ8CmYlpnESfsmdWBmQ34JlNWWsHAJdqrbpV/Oqt8Cii6 6OhxNjdsIrzsdfOlsTYVmBd7/BCpFtuO6yRvkB0EMRp3E2wDXQdXTdgIlMMiBOsrSj5j 47Ow== X-Received: by 10.52.246.162 with SMTP id xx2mr1554196vdc.93.1392844478610; Wed, 19 Feb 2014 13:14:38 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.188.35 with HTTP; Wed, 19 Feb 2014 13:14:18 -0800 (PST) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 19 Feb 2014 22:14:18 +0100 X-Google-Sender-Auth: LDwTJ1EjT0gtNCU9af26q-1kkNk Message-ID: Subject: Re: netmap, VALE and netmap pipes To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 21:14:40 -0000 On Mon, Feb 17, 2014 at 11:11 AM, Luigi Rizzo wrote: > > > https://code.google.com/p/netmap-ipfw > a netmap-enabled, userspace version of the ipfw firewall and > dummynet network emulator. This version reaches 7-10 Mpps for > filtering and over 2.5 Mpps for emulation. > > > Hope you'll find it useful. > Hi, I didn't reach to compile netmap-ipfw under FreeBSD (10-stable r261209 and 11.0-CURRENT r262140): fetch http://netmap.googlecode.com/archive/7f66866e7b735497cc0f0b81cfca94e32e81a182.zip fetch http://netmap-ipfw.googlecode.com/archive/1430cbad0d128aebb80bbd54be970afb8fbe1c74.zip unzip 7f66866e7b735497cc0f0b81cfca94e32e81a182.zip unzip 1430cbad0d128aebb80bbd54be970afb8fbe1c74.zip cd netmap-ipfw-1430cbad0d12/ gmake NETMAP_INC=../netmap-7f66866e7b73/sys Building userspace ... gmake[1]: Entering directory `/root/netmap-ipfw-1430cbad0d12/ipfw' (cd ../objs; gmake -f ../Makefile.kipfw include_e) gmake[2]: Entering directory `/root/netmap-ipfw-1430cbad0d12/objs' Building /root/netmap-ipfw-1430cbad0d12/objs/../objs/include_e ... gmake[2]: Leaving directory `/root/netmap-ipfw-1430cbad0d12/objs' CC ipfw2.c CC dummynet.c CC main.c CC ipv6.c CC altq.c CC ../extra/glue.c ../extra/glue.c:181:36: error: comparison of unsigned expression < 0 is always false [-Werror,-Wtautological-compare] if((oldlenp != NULL) && (*oldlenp < 0)) ~~~~~~~~ ^ ~ 1 error generated. gmake[1]: *** [glue.o] Error 1 gmake[1]: Leaving directory `/root/netmap-ipfw-1430cbad0d12/ipfw' gmake: *** [ipfw] Error 2 From owner-freebsd-net@FreeBSD.ORG Wed Feb 19 22:48:50 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93D0889A for ; Wed, 19 Feb 2014 22:48:50 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 51A4D1C97 for ; Wed, 19 Feb 2014 22:48:50 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E888A7300B; Wed, 19 Feb 2014 23:50:56 +0100 (CET) Date: Wed, 19 Feb 2014 23:50:56 +0100 From: Luigi Rizzo To: Olivier Cochard-Labb? Subject: Re: netmap, VALE and netmap pipes Message-ID: <20140219225056.GC78996@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.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 19 Feb 2014 22:48:50 -0000 On Wed, Feb 19, 2014 at 10:14:18PM +0100, Olivier Cochard-Labb? wrote: > On Mon, Feb 17, 2014 at 11:11 AM, Luigi Rizzo wrote: > > > > > > > https://code.google.com/p/netmap-ipfw > > a netmap-enabled, userspace version of the ipfw firewall and > > dummynet network emulator. This version reaches 7-10 Mpps for > > filtering and over 2.5 Mpps for emulation. > > > > > > Hope you'll find it useful. > > > > Hi, > > I didn't reach to compile netmap-ipfw under FreeBSD (10-stable r261209 and > 11.0-CURRENT r262140): > > fetch > http://netmap.googlecode.com/archive/7f66866e7b735497cc0f0b81cfca94e32e81a182.zip > fetch > http://netmap-ipfw.googlecode.com/archive/1430cbad0d128aebb80bbd54be970afb8fbe1c74.zip > unzip 7f66866e7b735497cc0f0b81cfca94e32e81a182.zip > unzip 1430cbad0d128aebb80bbd54be970afb8fbe1c74.zip > cd netmap-ipfw-1430cbad0d12/ > gmake NETMAP_INC=../netmap-7f66866e7b73/sys > > Building userspace ... > gmake[1]: Entering directory `/root/netmap-ipfw-1430cbad0d12/ipfw' > (cd ../objs; gmake -f ../Makefile.kipfw include_e) > gmake[2]: Entering directory `/root/netmap-ipfw-1430cbad0d12/objs' > Building /root/netmap-ipfw-1430cbad0d12/objs/../objs/include_e ... > gmake[2]: Leaving directory `/root/netmap-ipfw-1430cbad0d12/objs' > CC ipfw2.c > CC dummynet.c > CC main.c > CC ipv6.c > CC altq.c > CC ../extra/glue.c > ../extra/glue.c:181:36: error: comparison of unsigned expression < 0 is > always false [-Werror,-Wtautological-compare] > if((oldlenp != NULL) && (*oldlenp < 0)) oh, clang... just remove the check for the time being, i will fix it upstream in the meantime thanks luigi From owner-freebsd-net@FreeBSD.ORG Thu Feb 20 07:34:26 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82C68182 for ; Thu, 20 Feb 2014 07:34:26 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [144.76.253.226]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35AB51CC8 for ; Thu, 20 Feb 2014 07:34:25 +0000 (UTC) Received: from [10.10.1.102] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 2DAD01925F6; Thu, 20 Feb 2014 07:34:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 2DAD01925F6 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1392881663; bh=6xJmqWgc7/2+e1vVsD+zs5zHFdrMAuujKXMlDC7vst8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=PXL80pyrtg7AoWkiNSrUtvWz+e5hHmyRP2Kca6Yq9CDvMWybNoFTh8PWhG/apDHML DXdSxHDg+JFj6WvMpVhH0LWiEpryZ5tQh+z40O9U8ld0gov006b2f9p6AKhBQUvJ6J WYG4uq3X+vUsnjWmPsRDuGsh2Hc3F9mvWLb/sbkEw2n0CI3mNgXpk47yWF8UfDF08K sg+i2N67y0JRJQpvlW60fXIZKMLEqlOeKtWS7zmBRTtGtkmXQcltEhgPw5VfaTJ+mU WsgA79xAuRF/9VXLExFmzR3bg2idWmEgQDYimHrXfs9xlZ5XEKIWTMZZt/hFok8ETx ZSu1UkKbpv36A== Message-ID: <5305AFFD.9080701@gibfest.dk> Date: Thu, 20 Feb 2014 08:34:21 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: netmap, VALE and netmap pipes References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> <53027678.2020202@sentex.net> <20140217211649.GA42452@onelab2.iet.unipi.it> In-Reply-To: <20140217211649.GA42452@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 20 Feb 2014 07:34:26 -0000 On 17-02-2014 22:16, Luigi Rizzo wrote: > On Mon, Feb 17, 2014 at 03:52:08PM -0500, Mike Tancsa wrote: > ... >>> this is just the FreeBSD/head ipfw code with obvious features >> Actually, I was thinking more in terms of netmap in general. eg. >> examples of how to use it as a high speed firewall or router, or packet >> generator etc. > i should really write a book on this stuff :) FWIW, I would buy the hell out of that book. :) /Thomas From owner-freebsd-net@FreeBSD.ORG Thu Feb 20 07:40:00 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 557583B8 for ; Thu, 20 Feb 2014 07:40:00 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A9431D13 for ; Thu, 20 Feb 2014 07:40:00 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1WGOEf-000Jsl-U5; Thu, 20 Feb 2014 11:39:57 +0400 Message-ID: <5305B143.5090600@smartspb.net> Date: Thu, 20 Feb 2014 11:39:47 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Thomas Steen Rasmussen , Luigi Rizzo Subject: Re: netmap, VALE and netmap pipes References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> <53027678.2020202@sentex.net> <20140217211649.GA42452@onelab2.iet.unipi.it> <5305AFFD.9080701@gibfest.dk> In-Reply-To: <5305AFFD.9080701@gibfest.dk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140219-0, 19.02.2014), Outbound message X-Antivirus-Status: Clean Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 20 Feb 2014 07:40:00 -0000 20.02.2014 11:34, Thomas Steen Rasmussen пишет: > i should really write a book on this stuff :) > > FWIW, I would buy the hell out of that book. :) So do I! :) -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Thu Feb 20 07:48:03 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8BFD5DC for ; Thu, 20 Feb 2014 07:48:03 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 293C31DC7 for ; Thu, 20 Feb 2014 07:48:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s1K7lrHA080067; Thu, 20 Feb 2014 18:47:53 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 20 Feb 2014 18:47:53 +1100 (EST) From: Ian Smith To: Thomas Steen Rasmussen Subject: Re: netmap, VALE and netmap pipes In-Reply-To: <5305AFFD.9080701@gibfest.dk> Message-ID: <20140220184428.A96409@sola.nimnet.asn.au> References: <1392661063.244494415.kh0fdlsv@frv34.fwdcdn.com> <20140217185832.GB41267@onelab2.iet.unipi.it> <530273BF.5020303@sentex.net> <20140217205213.GC42021@onelab2.iet.unipi.it> <53027678.2020202@sentex.net> <20140217211649.GA42452@onelab2.iet.unipi.it> <5305AFFD.9080701@gibfest.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 20 Feb 2014 07:48:03 -0000 On Thu, 20 Feb 2014 08:34:21 +0100, Thomas Steen Rasmussen wrote: > On 17-02-2014 22:16, Luigi Rizzo wrote: > > On Mon, Feb 17, 2014 at 03:52:08PM -0500, Mike Tancsa wrote: > > ... > > > > this is just the FreeBSD/head ipfw code with obvious features > > > Actually, I was thinking more in terms of netmap in general. eg. > > > examples of how to use it as a high speed firewall or router, or packet > > > generator etc. > > i should really write a book on this stuff :) > > FWIW, I would buy the hell out of that book. :) > > /Thomas +1, but I'd settle for a comprehensive Wiki page or Handbook entry .. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Feb 20 17:30:01 2014 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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65B3C624 for ; Thu, 20 Feb 2014 17:30:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF761996 for ; Thu, 20 Feb 2014 17:30: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 s1KHU10m018920 for ; Thu, 20 Feb 2014 17:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1KHU11L018919; Thu, 20 Feb 2014 17:30:01 GMT (envelope-from gnats) Date: Thu, 20 Feb 2014 17:30:01 GMT Message-Id: <201402201730.s1KHU11L018919@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Alan Somers Subject: Re: kern/181741: [kernel] [patch] Packet loss when ' control' messages are present with large data (sendmsg(2)) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Alan Somers List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:30:01 -0000 The following reply was made to PR kern/181741; it has been noted by GNATS. From: Alan Somers To: bug-followup@FreeBSD.org, yuri@rawbw.com Cc: Subject: Re: kern/181741: [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2)) Date: Thu, 20 Feb 2014 10:29:27 -0700 I've been working on kern/185813, which is closely related. My comments on your patch: 1) In uipc_socket.c, you twice do "if (clen > space) error = EMSGSIZE". Should the comparison be with sp->so_snd->sb_hiwat instead of space? Space shrinks when the sockbuf is partially full, but sb_hiwat is constant. (Actually, sb_hiwat also shrinks for Unix domain sockets, but I am going to fix that as part of kern/185812). 2) In uipc_finalizecontrol(), I think that you need to grab UNP_LINK_RLOCK to protect the linkage between unp and unp2. 3) It would be fantastic if you could convert the testcase to ATF format. ATF is the new format that all testcases should use going forward. It's easily automatable, unlike the stuff in tools/regression, and it's very flexible too. https://wiki.freebsd.org/TestingFreeBSD 4) I think there are some tab/space issues with the patch, but I'm not positive because I'm reading it in Firefox. -Alan From owner-freebsd-net@FreeBSD.ORG Thu Feb 20 18:27:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E3E87A for ; Thu, 20 Feb 2014 18:27:29 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35107100B for ; Thu, 20 Feb 2014 18:27:29 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi5so55wib.3 for ; Thu, 20 Feb 2014 10:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=NXylJLnHkVsW994gMqfXJF8eMy6uXJ48WhxIcnbkyio=; b=QZ7xKu867J9YiuBlbt6l86RHy2alt1qtlm6kPSzPFNoP898zmHZtH0iD+avvQGkC/T ZYm/K4SbKGjku1S3enyTmJL9EpCkcYD9marqU/2njWR37Loc4fZYCIqWfoq1tAJGJhzQ IY4YcX8J5DhN4360v6k4AH/qS9kldIJC6r0niSgIrp/UP4176uOvPQ9PYZ2RQpB7LR1E caIpewmbjQ1yV4krmeaACksx3rypibHRAlh5N9fmkBfXIVKcMZsBWctdgIO64w7Za7jp qOvPdZJLZC17rXFgJyLvldkvHI8bKnEtIWeEQNTNq6fafQWpvQPXEQMFeTtCAIM9yiSl batA== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mt4152355wjs.34.1392920846680; Thu, 20 Feb 2014 10:27:26 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.168.197 with HTTP; Thu, 20 Feb 2014 10:27:26 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 11:27:26 -0700 X-Google-Sender-Auth: rk_pNSUgco2_njXYDGEXZSEDygc Message-ID: Subject: Re: kern/185813: SOCK_SEQPACKET AF_UNIX sockets with asymmetrical buffers drop packets From: Alan Somers Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 20 Feb 2014 18:27:29 -0000 On Thu, Jan 23, 2014 at 5:31 PM, Alan Somers wrote: > On Thu, Jan 23, 2014 at 11:26 AM, Adrian Chadd wrote: >> Well, shouldn't we fix the API/code so it doesn't drop packets, >> regardless of the sensibility or non-sensibility of different >> transmit/receive buffer sizes? > > That would be nice, but it may be beyond my ability to do so. The > relevant code is very complicated, and most of it is in > domain-agnostic code where we can't introduce AF_UNIX specific special > cases. > > It may be possible to change the single-buffer optimization to use the > receiving sockbuf's size for space calculations in uipc_send() instead > of the transmitting sockbuf's size. I could try to do that, though it > may cause existing programs to fail if they're depending on > setsockopt(s, SOL_SOCKET, SO_SNDBUF, ...) to have an effect. > I decided that the space check within uipc_send() wasn't necessary. Here is a new patch. It simply eliminates the space check within uipc_send(), relying on the space check in sosend_generic to enforce the sockbuf limits. I audited all the callers of sbappendaddr() and sbappendaddr_locked() and decided that the space check is appropriate for all of them except uipc_send(). sys/sys/sockbuf.h sys/kern/uipc_sockbuf.c Add sbappendaddr_nospacecheck_locked(), which is just like sbappendaddr_locked but doesn't validate the receiving socket's space. Factor out common code into sbappendaddr_locked_internal(). We shouldn't simply make sbappendaddr_locked check the space and then call sbappendaddr_nospacecheck_locked, because that would cause the O(n) function m_length to be called twice. sys/kern/uipc_usrreq.c Use sbappendaddr_nospacecheck_locked for SOCK_SEQPACKET sockets, because the receiving sockbuf's size limit is irrelevant. -Alan Index: sys/kern/uipc_sockbuf.c =================================================================== --- sys/kern/uipc_sockbuf.c (revision 262245) +++ sys/kern/uipc_sockbuf.c (working copy) @@ -620,29 +620,12 @@ SOCKBUF_UNLOCK(sb); } -/* - * Append address and data, and optionally, control (ancillary) data to the - * receive queue of a socket. If present, m0 must include a packet header - * with total length. Returns 0 if no space in sockbuf or insufficient - * mbufs. - */ -int -sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, - struct mbuf *m0, struct mbuf *control) +/* Helper routine that appends data, control, and address to a sockbuf. */ +static int +sbappendaddr_locked_internal(struct sockbuf *sb, const struct sockaddr *asa, + struct mbuf *m0, struct mbuf *control, struct mbuf *ctrl_last) { struct mbuf *m, *n, *nlast; - int space = asa->sa_len; - - SOCKBUF_LOCK_ASSERT(sb); - - if (m0 && (m0->m_flags & M_PKTHDR) == 0) - panic("sbappendaddr_locked"); - if (m0) - space += m0->m_pkthdr.len; - space += m_length(control, &n); - - if (space > sbspace(sb)) - return (0); #if MSIZE <= 256 if (asa->sa_len > MLEN) return (0); @@ -652,8 +635,8 @@ return (0); m->m_len = asa->sa_len; bcopy(asa, mtod(m, caddr_t), asa->sa_len); - if (n) - n->m_next = m0; /* concatenate data to control */ + if (ctrl_last) + ctrl_last->m_next = m0; /* concatenate data to control */ else control = m0; m->m_next = control; @@ -677,6 +660,50 @@ * mbufs. */ int +sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, + struct mbuf *m0, struct mbuf *control) +{ + struct mbuf *ctrl_last; + int space = asa->sa_len; + + SOCKBUF_LOCK_ASSERT(sb); + + if (m0 && (m0->m_flags & M_PKTHDR) == 0) + panic("sbappendaddr_locked"); + if (m0) + space += m0->m_pkthdr.len; + space += m_length(control, &ctrl_last); + + if (space > sbspace(sb)) + return (0); + return (sbappendaddr_locked_internal(sb, asa, m0, control, ctrl_last)); +} + +/* + * Append address and data, and optionally, control (ancillary) data to the + * receive queue of a socket. If present, m0 must include a packet header + * with total length. Returns 0 if insufficient mbufs. Does not validate space + * on the receiving sockbuf. + */ +int +sbappendaddr_nospacecheck_locked(struct sockbuf *sb, const struct sockaddr *asa, + struct mbuf *m0, struct mbuf *control) +{ + struct mbuf *ctrl_last; + + SOCKBUF_LOCK_ASSERT(sb); + + ctrl_last = (control == NULL) ? NULL : m_last(control); + return (sbappendaddr_locked_internal(sb, asa, m0, control, ctrl_last)); +} + +/* + * Append address and data, and optionally, control (ancillary) data to the + * receive queue of a socket. If present, m0 must include a packet header + * with total length. Returns 0 if no space in sockbuf or insufficient + * mbufs. + */ +int sbappendaddr(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control) { Index: sys/kern/uipc_usrreq.c =================================================================== --- sys/kern/uipc_usrreq.c (revision 262245) +++ sys/kern/uipc_usrreq.c (working copy) @@ -892,7 +892,8 @@ from = &sun_noname; so2 = unp2->unp_socket; SOCKBUF_LOCK(&so2->so_rcv); - if (sbappendaddr_locked(&so2->so_rcv, from, m, control)) { + if (sbappendaddr_nospacecheck_locked(&so2->so_rcv, from, m, + control)) { sorwakeup_locked(so2); m = NULL; control = NULL; @@ -977,8 +978,14 @@ const struct sockaddr *from; from = &sun_noname; - if (sbappendaddr_locked(&so2->so_rcv, from, m, - control)) + /* + * Don't check for space available in so2->so_rcv. + * Unix domain sockets only check for space in the + * sending sockbuf, and that check is performed in + * sosend_generic. + */ + if (sbappendaddr_nospacecheck_locked(&so2->so_rcv, + from, m, control)) control = NULL; break; } Index: sys/sys/sockbuf.h =================================================================== --- sys/sys/sockbuf.h (revision 262245) +++ sys/sys/sockbuf.h (working copy) @@ -127,6 +127,8 @@ struct mbuf *m0, struct mbuf *control); int sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control); +int sbappendaddr_nospacecheck_locked(struct sockbuf *sb, + const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control); int sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control); int sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0, Index: tests/sys/kern/unix_seqpacket_test.c =================================================================== --- tests/sys/kern/unix_seqpacket_test.c (revision 262245) +++ tests/sys/kern/unix_seqpacket_test.c (working copy) @@ -951,7 +951,6 @@ ATF_TC_WITHOUT_HEAD(pipe_simulator_128k_8k); ATF_TC_BODY(pipe_simulator_128k_8k, tc) { - atf_tc_expect_fail("PR kern/185812 SOCK_SEQPACKET AF_UNIX sockets with asymmetrical buffers drop packets"); test_pipe_simulator(131072, 8192); } From owner-freebsd-net@FreeBSD.ORG Fri Feb 21 16:34:16 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7F25E4D for ; Fri, 21 Feb 2014 16:34:16 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CB20123C for ; Fri, 21 Feb 2014 16:34:16 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1LGYEGf001306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 21 Feb 2014 09:34:14 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1LGYEDj001303 for ; Fri, 21 Feb 2014 09:34:14 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 21 Feb 2014 09:34:14 -0700 (MST) From: Warren Block To: freebsd-net@FreeBSD.org Subject: LED support on em(4) Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 21 Feb 2014 09:34:14 -0700 (MST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 21 Feb 2014 16:34:16 -0000 On 10-stable, an EXPI9301CT Intel Pro/1000 CT PCIe card does not react when strings are written to /dev/led/em0. The card's BIOS menu does not show any options to change user control of the LED. Do some cards not respond to led(4), or is there some other configuration that needs to be done to allow it? From owner-freebsd-net@FreeBSD.ORG Fri Feb 21 17:05:41 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91882CA5; Fri, 21 Feb 2014 17:05:41 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6B8156D; Fri, 21 Feb 2014 17:05:38 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1LH5MB7069039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 12:05:22 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: network.subr _aliasN handling From: John Nielsen In-Reply-To: Date: Fri, 21 Feb 2014 10:05:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1827) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: "rc@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 21 Feb 2014 17:05:41 -0000 On Jan 4, 2014, at 4:25 AM, Teske, Devin = wrote: > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: >=20 >> I believe I know what you mean by that but in a way scares me when = you say sort as in mixing up the original order they appear in which I = would find to be really unattractive to most. >=20 > It's not as scary as it sounds. >=20 > The issue is that the variables are sorted alphabetically, instead > of numerically. >=20 > Let's take four words: foo1, foo2, foo10, and foo20. > If you sort them alphabetically, you get: >=20 > foo1 > foo10 > foo2 > foo20 >=20 > You'll notice this when doing a directory listing, as that too is = sorted > alphabetically. >=20 > This is why "alias14" is run before "alias8" and "alias9". Because = they > are processed in alphabetically sorted order. I didn't do anything to = sort > the values, they came pre-sorted in alphabetic order. >=20 > If I simply throw in a "| sort -n", then it will change it to = numerically sorted. > As you might expect, numerically sorting the above list would result = in: >=20 > foo1 > foo2 > foo10 > foo20 >=20 > Trivial really. I'll throw a patch at you when I get some cycles = (soon). Hi Devin, Jason- I've been behind on my mailing list e-mail for a while, but I really = like the idea and the patch proposed here. I don't see anything like it = in head yet, so ... Ping? :) JN >> On Jan 4, 2014, at 5:29, "Teske, Devin" = wrote: >>=20 >>>=20 >>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>>=20 >>>> Alright something is a little off about this from a running = standpoint it did what it is meant to do. >>>>=20 >>>> Bug1: it seems to have looped back over itself reissuing two = addresses from the top of the list. >>>>=20 >>>> Test case: >>>> I have aliases 0-14 used numbered as such. >>>> Aliases 0-7 are ipv6 >>>> Aliases 8-14 are ipv4 >>>>=20 >>>> I commented out alias 2 and 6 to break up consecutive order. >>>>=20 >>>> Alias 8 & 9 appeared to have been run after alias 14. >>>>=20 >>>>=20 >>>> Something is awry but I can't quite pick out what it is yet. >>>=20 >>>> On Dec 28, 2013, at 23:24, "Teske, Devin" = wrote: >>>>=20 >>>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>>=20 >>>>>> Curious what everyone's opinion would be on modifying the = handling of _aliasN functions or providing a wrapper around it to handle = non-sequential ordering. >>>>>>=20 >>>>>> My goal on this is simple and based around groupings similiar to = that of the way user id(1)'s in passwd and group are handled or denoted = for use on modern systems. >>>>>>=20 >>>>>> I.e.: I would like to achieve this... >>>>>>=20 >>>>>> *_alias[1-99] =3D System type addresses "Importand addresses or = internal" >>>>>> *_alias[100-199] =3D Aliases for interface 1 >>>>>> *_alias[200-299] =3D Aliases for interface 2 >>>>>> etc... >>>>>>=20 >>>>>> NOt looking to achieve some sort of prefered naming convention = for the interface aliases, but loosen them so they may be defined by the = user in whatever means neccesary to their benefit. >>>>>>=20 >>>>>> In a scheme similiar to above I attempted to set an address on = every other 4th alias leaving 3 space rule room for insertion of further = addresses but was surprised when the processing of the aliases ceased at = the first non-sequential space. >>>>>>=20 >>>>>> So why not just grab every _aliasN no matter of what it is for = the interface and shove them into an arrary to be processed by a "for" = statement ? the order would still be kept without having to inspect = every defintion of alias and incrementing prehistorically. >>>>>>=20 >>>>>> As well this could provide early loading of the addresses into = their respective arrays so they may be processed and provided to any = other functions that may need to access them earlier on in script = fallthrough. >>>>>>=20 >>>>>> Looking at _alias'N' sequentialy feels like a neucense. >>>>>=20 >>>>> You mean something like the attached? From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 01:08:16 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC7DB983 for ; Sat, 22 Feb 2014 01:08:16 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CE1011BD for ; Sat, 22 Feb 2014 01:08:16 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id y1so2938516lam.22 for ; Fri, 21 Feb 2014 17:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5C79vhZnfQ7YyDkuyTOjXw2Cr6CPOp/UlHRhb33CfOI=; b=jVsHw/WoTNL/mpVpe7USj+w+fGCF6F8L5bZg0HRKr3Kh394dxokg/XZ9a2oj9tQtLu QK7DaBD2HE8SZa4a2CkOyPsrQLWuigUTBPQPcN+bh8XqsihUolDGqJEQL5UYfsP1MWIn gq8VgHbt4QtKrsnC9QfkGz6+74Rr5E7z8kEm+w7H/gMEMm/xG/1qEL0KhVqZfhS8hIRa q08alFq52csmHgojBrEQeqy/aC7EJd9zVEfTvKPuPOQz+DmKMgbpp1zEX7V+8b6608vb +x/AI4CoHONU22d7WUqgnT6EmIVhzslLAO7Cn2EDlM8EDd9JKmHAMyklpHHOPAVkJhwF cYtg== MIME-Version: 1.0 X-Received: by 10.152.19.66 with SMTP id c2mr5854063lae.54.1393031294192; Fri, 21 Feb 2014 17:08:14 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Fri, 21 Feb 2014 17:08:14 -0800 (PST) In-Reply-To: <5307F755.4090303@huawei.com> References: <5307F755.4090303@huawei.com> Date: Fri, 21 Feb 2014 17:08:14 -0800 X-Google-Sender-Auth: GFnFeq0SWSJMEIP2owjgoLWKRNs Message-ID: Subject: Re: netmap, VALE and netmap pipes From: Luigi Rizzo To: jerry Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: netdev@vger.kernel.org, "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Feb 2014 01:08:16 -0000 On Fri, Feb 21, 2014 at 5:03 PM, jerry wrote: > Hi Luigi, > > How to use netmap pipe by pkt-gen commands? > I have tried the commands as follows: > ./pkt-gen -i netmap:pipename{1 -f tx > ./pkt-gen -i netmap:pipename}1 -f rx (in another terminal) > But it works failed. > Should the pipename be replaced with a invalid NIC name such as "eth3" in > netmap mode? > netmap: expects the name of an existing device. Arbitrary names should have the 'vale' prefix e.g. ./pkt-gen -i valexx:p{0 -f tx ./pkt-gen -i valexx:p}0 -f rx > > The netmap pipe works from software ring to software ring independently > with NICs, I understand. Is that right? > > correct, but the basename is used to group ports (NICs/VALE ports and netmap pipes) that use the same shared memory so that you can do zero copy among them. cheers luigi > B.R. > Jerry > > On 2014/2/17 18:11, Luigi Rizzo wrote: > > Hi, > > we have recently made a few extensions to netmap/VALE and put various > > pieces of code on public repositories, so i thought i'd share the > > pointers. All the code below runs with equal features and performance > > on FreeBSD and Linux, and we are trying to upstream it in the relevant > > projects if possible (as an example, QEMU recently added a netmap > backend), > > at which point some of these clone repositories will become unnecessary. > > > > See http://info.iet.unipi.it/~luigi/netmap for more details. > > > > https://code.google.com/p/netmap/ > > The latest netmap code for FreeBSD/Linux. It has native support > > for certain NICs; emulated netmap over unmodified drivers; > > enhanced parallelism in the VALE switch (20 Mpps/source, scaling > > up to ~50Mpps); and a new feature called "netmap pipe" that > > does zero-copy blocking I/O at over 100 Mpps. > > Other features are the ability to allocate tons of extra > > netmap buffers, and configurable sharing of memory among NICs, > > VALE ports and netmap pipes. This increases the opportunity for > > zero copy operation. > > > > > -- -----------------------------------------+------------------------------- 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 Sat Feb 22 01:10:03 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DF4CC2B for ; Sat, 22 Feb 2014 01:10:03 +0000 (UTC) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BAB2211D7 for ; Sat, 22 Feb 2014 01:10:02 +0000 (UTC) Received: from 172.24.2.119 (EHLO szxeml212-edg.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id AKY14311; Sat, 22 Feb 2014 09:03:25 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 09:03:21 +0800 Received: from [127.0.0.1] (10.177.19.236) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server id 14.3.158.1; Sat, 22 Feb 2014 09:03:18 +0800 Message-ID: <5307F755.4090303@huawei.com> Date: Sat, 22 Feb 2014 09:03:17 +0800 From: jerry User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Luigi Rizzo , , "freebsd-net@freebsd.org" Subject: Re: netmap, VALE and netmap pipes References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.19.236] X-CFilter-Loop: Reflected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Feb 2014 01:10:03 -0000 Hi Luigi, How to use netmap pipe by pkt-gen commands? I have tried the commands as follows: ./pkt-gen -i netmap:pipename{1 -f tx ./pkt-gen -i netmap:pipename}1 -f rx (in another terminal) But it works failed. Should the pipename be replaced with a invalid NIC name such as "eth3" in netmap mode? The netmap pipe works from software ring to software ring independently with NICs, I understand. Is that right? B.R. Jerry On 2014/2/17 18:11, Luigi Rizzo wrote: > Hi, > we have recently made a few extensions to netmap/VALE and put various > pieces of code on public repositories, so i thought i'd share the > pointers. All the code below runs with equal features and performance > on FreeBSD and Linux, and we are trying to upstream it in the relevant > projects if possible (as an example, QEMU recently added a netmap backend), > at which point some of these clone repositories will become unnecessary. > > See http://info.iet.unipi.it/~luigi/netmap for more details. > > https://code.google.com/p/netmap/ > The latest netmap code for FreeBSD/Linux. It has native support > for certain NICs; emulated netmap over unmodified drivers; > enhanced parallelism in the VALE switch (20 Mpps/source, scaling > up to ~50Mpps); and a new feature called "netmap pipe" that > does zero-copy blocking I/O at over 100 Mpps. > Other features are the ability to allocate tons of extra > netmap buffers, and configurable sharing of memory among NICs, > VALE ports and netmap pipes. This increases the opportunity for > zero copy operation. From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 02:42:47 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5843F19; Sat, 22 Feb 2014 02:42:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5AD51946; Sat, 22 Feb 2014 02:42:47 +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 s1M2gl3t094557; Sat, 22 Feb 2014 02:42:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1M2glmt094556; Sat, 22 Feb 2014 02:42:47 GMT (envelope-from linimon) Date: Sat, 22 Feb 2014 02:42:47 GMT Message-Id: <201402220242.s1M2glmt094556@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/186949: [re] re0 driver crashes under load every 10-20 minutes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Feb 2014 02:42:48 -0000 Synopsis: [re] re0 driver crashes under load every 10-20 minutes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 22 02:42:37 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=186949 From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 03:02:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FE86567 for ; Sat, 22 Feb 2014 03:02:26 +0000 (UTC) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAC441D29 for ; Sat, 22 Feb 2014 03:02:25 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id uz6so5242320obc.17 for ; Fri, 21 Feb 2014 19:02:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=kz2B87mMz/tVV4wqrpN/15XlVLx6eTquqVgu4jzcwzA=; b=ADi+seIOC+NTNGwZkb7WxNqh2Q23896zUdfzy2K0F3PjvKuIj8ArMFihn2/DnfnVEd I0i76hpK/It2XS4FzbfASpcqYqUDSIqcCrZkBaEr1EGyOMPgxJuVEd2gAfnDaz5e6HpA wzMc/qUjB8lF7yEriuLDU7qHqjoqeqTY6VzKODjvltfD+TxO2Sxs1RHrFWS1+mWzDYmj inksqtHpLiqOzFaOnnJ1klef6MRWGuhACS1MR8VMNGVJfNp9dg/zD4kKb2HRUe1pJZR7 WnqIZ2MnV66LVACtVqPLXyV0Xd2jHhkfxcvkGzcMn8s6L9WQL6WlT8W4J09pBCKndS32 gH/g== X-Gm-Message-State: ALoCoQm0XijhL/SAw1njalIYFdM0+AdqDpIN8hQ1ZWBJobYaK+d3o9PCH0HSVK9nlHp8LTigG722 X-Received: by 10.60.94.52 with SMTP id cz20mr12793454oeb.43.1393038138811; Fri, 21 Feb 2014 19:02:18 -0800 (PST) Received: from [10.0.0.20] (c-71-236-84-218.hsd1.pa.comcast.net. [71.236.84.218]) by mx.google.com with ESMTPSA id qh4sm15216876obc.4.2014.02.21.19.02.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 19:02:17 -0800 (PST) Message-ID: <5308133F.7050504@natserv.net> Date: Fri, 21 Feb 2014 22:02:23 -0500 From: Francisco Reyes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: FreeBSD behind a firewall 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.17 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, 22 Feb 2014 03:02:26 -0000 Setup Internet --> Vyatta firewall --> FreeBSD Trying to have the FreeBSD machine listen on http and https on local network and have the Vyatta firewall forward the traffic from the external connections. I have the Vyatta already configured to send to FreeBSD, but it seems the packets at the FreeBSD machine are not going back to the firewall.. The FreeBSD machine has 3 interfaces xn0 public - will have ssh open xn1 internal - visible in entire data center (Rackspace VM) xn2 internal - private net on 192.168.3.0 I have the Vyatta firewall sending traffic to xn2 and I am able to see it with TCPdump I tried setting a static route for all of 192.168.3.0 to go through the Vyatta firewall, but that did not seem to help. Output of netstat -r Internet: Destination Gateway Flags Refs Use Netif Expire default 162.209.99.1 UGS 0 3542 xn0 10.176.0.0/18 link#5 U 0 0 xn1 => 10.176.0.0/12 10.176.0.1 UGS 0 0 xn1 testvm link#5 UHS 0 0 lo0 localhost link#3 UH 0 0 lo0 162.209.99.0 link#4 U 0 0 xn0 testvm link#4 UHS 0 0 lo0 192.168.3.0 link#6 U 0 0 xn2 192.168.3.1 link#6 UHS 0 0 lo0 The FreeBSD machine is 192.168.3.1, the Vyatta firewall is 192.168.3.2 Relevant parts of /etc/rc.conf defaultrouter="162.209.99.1" static_routes="lan0 lan1 lan2" route_lan0="-net 10.176.0.0 -netmask 255.240.0.0 10.176.0.1" route_lan1="-net 10.208.0.0 -netmask 255.240.0.0 10.176.0.1" route_lan1="-net 192.168.3.0 -netmask 255.255.255.0 192.168.3.2" Any pointers on how I can get the traffic to go back to the Vyatta firewall? Does the firewall needs to be the gateway for the VM? The ideal would be to keep ssh outside as to not depend on the firewall and http and https to go throught he firewall. From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 17:10:01 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7B9F958 for ; Sat, 22 Feb 2014 17:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7790B18D2 for ; Sat, 22 Feb 2014 17:10: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 s1MHA1ej079943 for ; Sat, 22 Feb 2014 17:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1MHA1l2079942; Sat, 22 Feb 2014 17:10:01 GMT (envelope-from gnats) Date: Sat, 22 Feb 2014 17:10:01 GMT Message-Id: <201402221710.s1MHA1l2079942@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "J.R. Oldroyd" Subject: Re: conf/183407: [rc.d] [patch] Routing restart returns non-zero exitcode in case of no extra routing parameter or missing atm/ipx X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "J.R. Oldroyd" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 17:10:01 -0000 The following reply was made to PR conf/183407; it has been noted by GNATS. From: "J.R. Oldroyd" To: bug-followup@FreeBSD.org, abhikumar163@gmail.com Cc: Subject: Re: conf/183407: [rc.d] [patch] Routing restart returns non-zero exitcode in case of no extra routing parameter or missing atm/ipx Date: Sat, 22 Feb 2014 12:07:10 -0500 I've received bug reports for wifimgr(8) when it resets interfaces using "/etc/rc.d/netif restart ifname" which calls /etc/rc.d/routing which is returning an incorrect value of 1. The patch proposed here does indeed fix things. From owner-freebsd-net@FreeBSD.ORG Sat Feb 22 22:48:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C7B4186 for ; Sat, 22 Feb 2014 22:48:03 +0000 (UTC) Received: from smtp.novso.com (smtp1.novso.com [193.189.104.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4ED514F1 for ; Sat, 22 Feb 2014 22:48:02 +0000 (UTC) Message-ID: <1393109280.11968.3.camel@fr-wks3.corp.novso.com> Subject: Re: IPsec filtertunnel broken on FreeBSD 10 From: Nicolas DEFFAYET To: freebsd-net@freebsd.org Date: Sat, 22 Feb 2014 23:48:00 +0100 In-Reply-To: <5304DA80.6010403@yandex.ru> References: <1391725273.22934.16.camel@fr-wks3.corp.novso.com> <1392417340.10711.5.camel@fr-wks3.corp.novso.com> <52FEA4F5.5010702@yandex.ru> <52FEA5A2.3050106@yandex.ru> <1392641917.21759.1.camel@srv31.corp.novso.com> <53020F0F.9050809@yandex.ru> <1392648453.22762.2.camel@srv31.corp.novso.com> <5304DA80.6010403@yandex.ru> Organization: DEFFAYET.COM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Feb 2014 22:48:03 -0000 On Wed, 2014-02-19 at 20:23 +0400, Andrey V. Elsukov wrote: Hello, After very long testing, i have discovered the route cause. Testing is not easy as there is a dependency between kernel and userland, it's not like on a Linux where the kernel is not depend of userland. Broken userland can generate false-positive result. The revision 254519 break the firewall with IPsec. http://svnweb.freebsd.org/base?view=revision&revision=254519 "Move the global M_SKIP_FIREWALL mbuf flags to a protocol layer specific flag instead. The flag is only used within the IP and IPv6 layer 3 protocols. Because some firewall packages treat IPv4 and IPv6 packets the same the flag should have the same value for both." It seem that some code doesn't have been updated for allow firewall to work with IPsec. FreeBSD 10.0-CURRENT #0 r254518 (10-userland) ------------------------------- # ipfw -a list 00010 6 326 allow log logamount 10000 tcp from 192.168.0.1 to 192.168.0.2 dst-port 22 via re0 in 00020 0 0 allow log logamount 10000 tcp from 192.168.0.2 to 192.168.0.1 dst-port 22 via re0 out 65535 5149 411660 allow ip from any to any => ipfw counters are ok for inbound Feb 22 22:16:44 host2 kernel: ipfw: 10 Accept TCP 192.168.0.1:51691 192.168.0.2:22 in via re0 => ipfw see the connection 22:18:16.127112 IP 192.168.0.1 > 224.0.0.5: OSPFv2, Hello, length 44 22:18:21.042325 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15a), length 92 22:18:21.042548 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x6), length 92 22:18:21.042785 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15b), length 84 22:18:21.074818 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x7), length 116 22:18:21.174651 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc15c), length 84 => traffic is encrypted by IPsec FreeBSD 10.0-CURRENT #0 r254519 (10-userland) ------------------------------- # ipfw -a list 00010 0 0 allow log logamount 10000 tcp from 192.168.0.1 to 192.168.0.2 dst-port 22 via re0 in 00020 0 0 allow log logamount 10000 tcp from 192.168.0.2 to 192.168.0.1 dst-port 22 via re0 out 65535 3132 249778 allow ip from any to any => ipfw counters are not increased! nothing in log => ipfw DO NOT see the connection! 22:22:05.890386 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc165), length 92 22:22:05.890565 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x6), length 92 22:22:05.890793 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc166), length 84 22:22:05.922544 IP 192.168.0.2 > 192.168.0.1: ESP(spi=0x00003039,seq=0x7), length 116 22:22:06.022056 IP 192.168.0.1 > 192.168.0.2: ESP(spi=0x00003039,seq=0xc167), length 84 => traffic is encrypted by IPsec Many thanks -- Nicolas DEFFAYET