From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 01:13: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED9ADA63 for ; Sun, 2 Nov 2014 01:13:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C1FEFECA for ; Sun, 2 Nov 2014 01:13:52 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA21DeCw016737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Nov 2014 18:13:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5455853E.2030700@freebsd.org> Date: Sun, 02 Nov 2014 09:13:34 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hooman Fazaeli , "freebsd-net@freebsd.org" Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> In-Reply-To: <54535B82.405@gmail.com> 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 01:13:53 -0000 On 10/31/14, 5:50 PM, Hooman Fazaeli wrote: > Hi, > > I my setup, I use a fwd rule to forward all udp traffic to my local > proxy: > > ipfw add 10 fwd localhost,7000 udp from any to any recv em1 just as a nit, I'd add "in" as well sometimes outgoing packets can have a receive interface if they were routed. > > The proxy needs to know the original destination address of > forwarded datagrams, but > there seems to be no way to obtain that address. hmm that used to work.. > > Using recvmsg with IP_RECVDSTADDR does not help because it returns > next-hop address > instead of original destination. This is because udp_input() > overwrites packet's destination > with next-hop address before doing ip_savecontrol. This behaviour may be new since IPFORWARD was added.. My memory is that you could do this. > > It seems easy to change udp_input to pass the original dest. address > to ip_savecontrol. > Another soultion would be to implement IP_RECVDSTSOCKADDR option, > which records the original > destination address:port as a 'struct sockaddr_in[6]' in packet's > control data. > > Comments/suggestions are welcome. > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 03:03:41 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F67F23E for ; Sun, 2 Nov 2014 03:03:41 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 654FEB68 for ; Sun, 2 Nov 2014 03:03:41 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id y20so3545893ier.20 for ; Sat, 01 Nov 2014 20:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AQ+EmcLhG2cBBSZpojizq72ZuOw3BTv/u1VKxm32myo=; b=dqSEO1azdZWs+Xm0NJS30cAGBO5XDhSlGafaFac5bY5MybadyXd2iYs55lGzWOfW07 S8p5uA3up3J8B8HQynfeLow4fqqjLNokIVvZLUQ/K/Pzv1lLj85/rWMi4ONtT6XR5PEA ByKqM18Q8WPAPmOXeyWisJnx98NT5lm2L8BZsIZG+Sf/LWHAHvID4dcN43V2x6elJlJ2 +y+NrqC7v054AcX9hpWvFVmbiMl/hKVT+zVC7usyn+uEcAIohDibvMxjcwQ+6vyTtEYw /Pcf4rXy6ipro3qLRzSsq0S7ofs9B38yYdq2MdYGcirnC4Rf9watPjrVD9r9+Zd44xXF JKqw== MIME-Version: 1.0 X-Received: by 10.42.11.69 with SMTP id t5mr56633ict.72.1414897420821; Sat, 01 Nov 2014 20:03:40 -0700 (PDT) Received: by 10.64.9.33 with HTTP; Sat, 1 Nov 2014 20:03:40 -0700 (PDT) In-Reply-To: <7BCDF08D-BAF5-4747-91FF-968E51B6AEED@bangj.com> References: <7BCDF08D-BAF5-4747-91FF-968E51B6AEED@bangj.com> Date: Sat, 1 Nov 2014 23:03:40 -0400 Message-ID: Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Chris Inacio To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 03:03:41 -0000 Thank you for all your help. You have indeed fixed my mistakes. I still have one more mistake, however, which is that my internal network interface isn't getting an IPv6 address, beyond link local. When I added "inet6 accept_rtadv" to the config of re1 in rc.conf, the static "192.168.1.1 netmask"... broke. If you have a quick fix I would be really appreciative, but I will say, at this point I'm being lazy a bit. I haven't really done the homework myself first. :) In either case, I really appreciate your help. thanks chris On Sat, Nov 1, 2014 at 1:09 AM, Tom Pusateri wrote: > > > On Oct 31, 2014, at 11:43 PM, Tom Pusateri wrote: > > > >> > >> On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote: > >> > >> My configs are really basic. dhcp6c.conf: > >> > >> interface re0 { > >> > >> send ia-pd 0; > >> > >> send ia-na 1; > >> > >> }; > >> > >> > >> id-assoc na 1 { > >> > >> }; > >> > >> > >> id-assoc pd { > >> > >> prefix ::/56 infinity; > >> > >> prefix-interface re0 { > >> > >> sla-len 4; > >> > >> sla-id 1; > >> > >> }; > >> > >> }; > > In addition to my earlier post, you are missing the ID for the ia-pd > association. > > replace: > > id-assoc pd { > > with: > > id-assoc pd 0 { > > and you are referencing your upstream interface instead of your downstream > interface in the delegated prefix-interface statement. > > replace: > > prefix-interface re0 { > > with > > prefix-interface re1 { > > > Thanks, > Tom > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 03: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D28B749C for ; Sun, 2 Nov 2014 03:10:31 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A563EBAA for ; Sun, 2 Nov 2014 03:10:31 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA23ARjW017061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Nov 2014 20:10:29 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5455A09C.6030808@freebsd.org> Date: Sun, 02 Nov 2014 11:10:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hooman Fazaeli , "freebsd-net@freebsd.org" Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <5455853E.2030700@freebsd.org> In-Reply-To: <5455853E.2030700@freebsd.org> 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 03:10:31 -0000 On 11/2/14, 9:13 AM, Julian Elischer wrote: > On 10/31/14, 5:50 PM, Hooman Fazaeli wrote: >> Hi, >> >> I my setup, I use a fwd rule to forward all udp traffic to my local >> proxy: >> >> ipfw add 10 fwd localhost,7000 udp from any to any recv em1 > just as a nit, I'd add "in" as well sometimes outgoing packets can > have a receive interface if they were routed. > >> >> The proxy needs to know the original destination address of >> forwarded datagrams, but >> there seems to be no way to obtain that address. > hmm that used to work.. >> >> Using recvmsg with IP_RECVDSTADDR does not help because it returns >> next-hop address >> instead of original destination. This is because udp_input() >> overwrites packet's destination >> with next-hop address before doing ip_savecontrol. > This behaviour may be new since IPFORWARD was added.. My memory is > that you could do this. >> >> It seems easy to change udp_input to pass the original dest. >> address to ip_savecontrol. >> Another soultion would be to implement IP_RECVDSTSOCKADDR option, >> which records the original >> destination address:port as a 'struct sockaddr_in[6]' in packet's >> control data. >> >> Comments/suggestions are welcome. apply the following patches to your kernel http://svnweb.freebsd.org/base/stable/9/sys/netinet/udp_usrreq.c?r1=225043&r2=225044& and http://svnweb.freebsd.org/base/stable/9/sys/netinet/udp_usrreq.c?r1=243585&r2=243586& >> >> > > _______________________________________________ > 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 Sun Nov 2 05:18:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CED1FE68 for ; Sun, 2 Nov 2014 05:18:21 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9CA7812 for ; Sun, 2 Nov 2014 05:18:21 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:400:640:21c:c0ff:fe7f:96ee]) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 82EF62D4F9B; Sat, 1 Nov 2014 22:18:20 -0700 (PDT) Received: from [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2580:674:baca:3aff:fe83:bd29]) by chombo.houseloki.net (Postfix) with ESMTPSA id 1919CA1C; Sat, 1 Nov 2014 22:18:18 -0700 (PDT) Message-ID: <5455BE9F.5020205@bluerosetech.com> Date: Sat, 01 Nov 2014 22:18:23 -0700 From: Darren Pilgrim Reply-To: freebsd-net@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Inacio , freebsd-net@freebsd.org Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq References: <7BCDF08D-BAF5-4747-91FF-968E51B6AEED@bangj.com> 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 05:18:21 -0000 On 11/1/2014 8:03 PM, Chris Inacio wrote: > Thank you for all your help. You have indeed fixed my mistakes. > > I still have one more mistake, however, which is that my internal network > interface isn't getting an IPv6 address, beyond link local. When I added > "inet6 accept_rtadv" to the config of re1 in rc.conf, the static > "192.168.1.1 netmask"... broke. Routers must not accept router advertisements from their downstream interfaces. Your /etc/rc.conf should look something like this: ipv6_cpe_wanif="re0" ifconfig_re0="DHCP" ifconfig_re0_ipv6="inet6 accept_rtadv -no_radr" ifconfig_re1="inet 192.168.1.1/24" ifconfig_re1_ipv6="inet6 -accept_rtadv" From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 15:40:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690F9FF5; Sun, 2 Nov 2014 15:40:29 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD6D4135; Sun, 2 Nov 2014 15:40:28 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so10941856wgh.10 for ; Sun, 02 Nov 2014 07:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8UhrR0R38QEt3vpUU+YpwyOEjrtLFA2yHTuMfvki+qI=; b=V180nPMV/82dGkUGJNi1ZlVutBJdjH9FK6NVQM6xc3OZBF/izGEzCO84DZuG3CkZDm x/DS4iYNrgUDU3kXSUnwfDYBgr/T/q1ZS+iVajhiLgj+7+r71+e1tAApDAGfWa+z7rrD k9IRmL6yk+srnOQnfiHq8RTq91dI0mSCIJ7McN4JKvnetN5AEGczKQV9yFR3A3MNUWa6 s4wicErtI+/UObLde+wC0T+5+CSNK5ItoemGHmJX0v7mFoarK1nY2R2aHu26iWGfru+J ElRxZHl0FmuB6vUIbzO/s9PDwWucCxwlSnOGHS1U01PD/4DOFDlmqo8Oj8wgQCEg3qVI OpIw== X-Received: by 10.180.211.2 with SMTP id my2mr10394024wic.13.1414942826180; Sun, 02 Nov 2014 07:40:26 -0800 (PST) Received: from [192.168.2.30] ([2.176.155.176]) by mx.google.com with ESMTPSA id pc8sm18986701wjb.36.2014.11.02.07.40.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 07:40:25 -0800 (PST) Message-ID: <5456506A.9060708@gmail.com> Date: Sun, 02 Nov 2014 19:10:26 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 15:40:29 -0000 On 10/31/2014 8:11 PM, Adrian Chadd wrote: > Hi, > > If it's missing in 10 or later then please file a bug and I'll see > what it'll take to add another socket option to return the original > destination address+port. > > Thanks, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194758 > > -adrian > > On 31 October 2014 08:00, Hooman Fazaeli wrote: >> On 10/31/2014 5:30 PM, Mark Felder wrote: >>> I'm not sure if this is what you're looking for, but perhaps the >>> solution is in net/samplicator ? >>> >>> From the project's website: >>> >>> This simple program listens for UDP datagrams on a network port, and >>> sends copies of these datagrams on to a set of destinations. Optionally, >>> it can perform sampling, i.e. rather than forwarding every packet, >>> forward only 1 in N. Another option is that it can "spoof" the IP source >>> address, so that the copies appear to come from the original source, >>> rather than the relay. Currently only supports IPv4. >>> _______________________________________________ >>> 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" >> >> Thanks. I do not thinks it provides what I am looking for. >> >> I am not looking for an application performing a specific task, but a >> mechanism >> to get the __original__ destination address and port of packets forwarded to >> a >> local UDP proxy by ipfw fwd rules. As I figured it out until now, The >> original destination >> address may be obtained by IP_RECVDSTADDR on 9.0+ (but not on 8.x and older >> versions) but >> there seems to be no mechanism get the _original_ destination _port_ (Apart >> from this >> missing mechanism, my proxy is functional and performs what it is intended >> to do). >> >> >> -- >> >> Best regards. >> Hooman Fazaeli >> >> _______________________________________________ >> 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" -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Sun Nov 2 19:42:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99CEA61F for ; Sun, 2 Nov 2014 19:42:24 +0000 (UTC) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 592E1B8D for ; Sun, 2 Nov 2014 19:42:23 +0000 (UTC) Received: from [192.168.0.151] (unknown [195.91.216.248]) by mail.otcnet.ru (Postfix) with ESMTPSA id 650333AE for ; Sun, 2 Nov 2014 22:36:10 +0300 (MSK) From: Victor Gamov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: freebsd as DMVPN spoke Message-Id: <6A8DE308-0DAE-4CF7-895D-8E46CE589DDA@euro-comm.net> Date: Sun, 2 Nov 2014 22:36:08 +0300 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 19:42:24 -0000 Hi All I have FreeBSD-based router with 3 uplinks. Everything works fine but = new tasks appears. Is it possible to use FreeBSD as spoke for Cisco-based DMVPN hub for = hub-and-spoke model? -- CU, Victor Gamov From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 01:26: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1623A0D for ; Mon, 3 Nov 2014 01:26:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88165EB0 for ; Mon, 3 Nov 2014 01:26:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA31Q5kj018983 for ; Mon, 3 Nov 2014 01:26:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191415] [carp] CARP password with "-" causes /etc/rc.d/netif to infinite loop Date: Mon, 03 Nov 2014 01:26:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hrs@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 01:26:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191415 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |hrs@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |hrs@FreeBSD.org --- Comment #2 from Hiroki Sato --- Take. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 04:07:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12D6130F for ; Mon, 3 Nov 2014 04:07:56 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AC5BFA0 for ; Mon, 3 Nov 2014 04:07:55 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id s18so3409905lam.41 for ; Sun, 02 Nov 2014 20:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=1/uoTUiwNlv9jB2RcMmF8zyVoV/hcrXsVAfmyi73+5Y=; b=G6C4oM0Qe6BP8O9u62k76gKDUCX76FHkT6PJA3vDR4NoP8Zddax6ZlKJ65sB5mVPSD 5g3iZH89G+mzu4yqI6MlUmI1N81f5guKx8APSamWknCWAzd/3UQ2WmGGqZWif0FxNcQk +4TyfVlcdoCMQ+ucEfCIzGnbpF/jSdmTDpI8DKj3epd5D6J07IopwbwA6ttmbQceA0Ct 5/u7HBSdNQoolXhxdF0I/wGSnKkOcaojGXDMGlEmWrkYxcFLIxnFDQ9vRkTL8Wxd/xGo o/eeb1YElSi0o/TYa1QtXWvCmXBePXK1YoqUzGDBhnfJFt1CP3vaHYuD4QVN654zWkmX l/2g== X-Received: by 10.112.144.228 with SMTP id sp4mr46813780lbb.58.1414987673152; Sun, 02 Nov 2014 20:07:53 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:2497:9687:421b:c20e]) by mx.google.com with ESMTPSA id x8sm3353343lae.24.2014.11.02.20.07.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Nov 2014 20:07:52 -0800 (PST) Message-ID: <5456ff98.c815980a.669e.ffffa80b@mx.google.com> X-Google-Original-Message-ID: <023901cff71b$bcc97250$365c56f0$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Marek Salwerowicz'" , References: <543D9C48.3010907@wp.pl> In-Reply-To: <543D9C48.3010907@wp.pl> Subject: RE: Multicast routing, IGMP, IPTV doubts.. Date: Mon, 3 Nov 2014 07:07:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/oAkFKn+sUj652TTW+80WkPv7HagPGQxAw Content-Language: ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 04:07:56 -0000 pass out quick inet proto udp to 224.0.0.0/4 no state allow-opts pass out quick inet proto igmp to 224.0.0.0/4 no state allow-opts pass out quick inet6 proto udp to ff00::/8 no state allow-opts # Allow send multicast pass out quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here pass in quick inet proto udp to 224.0.0.0/4 no state # Allow receive multicast pass in quick inet proto igmp to 224.0.0.0/4 no state allow-opts pass in quick inet6 proto udp to ff00::/8 no state # Allow receive multicast pass in quick inet6 proto icmp6 no state allow-opts # mld (igmp6) also here If not help you can use multicast bridge on netgraph: http://www.netlab.linkpc.net/forum/index.php?topic=796.0 http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030643.html > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Marek Salwerowicz > Sent: Wednesday, October 15, 2014 1:57 AM > To: freebsd-net@freebsd.org > Subject: Multicast routing, IGMP, IPTV doubts.. > > Hi all, > > My home router is small FreeBSD 10 box, with 3 ethernet ports, I use pf > as a firewall. > > My ISP provides FTTH, that ends at my home with a small box called CPE. > The CPE contains 4 ethernet ports. On one port I have Internet access, > on the other there is IPTV (that's based on udp/multicast) > > The IPTV works well - when I connect directly my PC to IPTV ethernet > socket - I can watch TV. > > But I would like to have both Internet and IPTV on my desktop at the > same time. > > I've downloaded the igmpproxy package, set up config: > > quickleave > # IPTV interface > phyint re2 upstream ratelimit 0 threshold 1 > altnet 10.0.0.0/8 > altnet 192.168.0.0/16 > > # LAN interface , bridge0 as it's re0+wlan0 phyint bridge0 downstream > ratelimit 0 threshold 1 > > # Internet access interface > phyint re1 disabled > > I've also loaded the ip_mroute module into kernel: > > 10 1 0xffffffff81aa7000 cd91 ip_mroute.ko > > And enabled UDP traffic in PF: > > IPTV="re2" > int_if="bridge0" > > # IPTV > pass in on $IPTV inet proto udp from any to any pass on {$int_if, > $IPTV} proto igmp allow-opts > > > > Unfortunately after starting igmpproxy: > > # igmpproxy -d -vv igmpproxy.conf > > the igmpproxy starts but can't build routing table: > Current routing table (Age active routes): > ----------------------------------------------------- > No routes in table... > ----------------------------------------------------- > received packet from 10.66.255.248 shorter (32 bytes) than hdr+data > length (24+32) received packet from 10.66.255.248 shorter (32 bytes) > than hdr+data length (24+32) received packet from 10.66.255.248 shorter > (32 bytes) than hdr+data length (24+32) > > > Do you have any idea how should I configure my box to be able to route > the IPTV traffic? > > Regards, > Marek > > -- > Marek Salwerowicz > _______________________________________________ > 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 Nov 3 10:04:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AAD0781 for ; Mon, 3 Nov 2014 10:04:43 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488F08A3 for ; Mon, 3 Nov 2014 10:04:43 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id gq1so3800222obb.20 for ; Mon, 03 Nov 2014 02:04:42 -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=ayXGD0I8hoseAdMrgp2q2/cfMxjhgIOwkgu+/OhbFx0=; b=xqVaAVxxtxEodSD6VJeNSdM4RxNyCI2+iVRV54nR9WblUoy9yAiFdzQc5fHfU/LR3l ZRz0TQNRfBlnFsTVRFMEdoUiSt4NGuLQ7iDqIxzbBDjvT7/hxc+lUc7c2JHAoIUu0jBm 5x6fq3jOsd06VPlIIR/GUEdb7QOJwoUs5EqKPuLWuxIFNkWA36pfRIM89Db/AZLQtZxo ODVuko2eIVyhGlmiBL/LMnTPNIqgHu+qQXXhBv0Br5GNu1Yo3ZRhq+0Gzd1jyKNIhSlJ o90OK/efdfXEfMvBIne56GgUunLyzlltJHpdC5czsuV8zlirBZ6X9sVq/X7UEGEyXqwQ X5NQ== MIME-Version: 1.0 X-Received: by 10.202.61.8 with SMTP id k8mr13789557oia.3.1415009082435; Mon, 03 Nov 2014 02:04:42 -0800 (PST) Received: by 10.76.167.202 with HTTP; Mon, 3 Nov 2014 02:04:42 -0800 (PST) Date: Mon, 3 Nov 2014 18:04:42 +0800 Message-ID: Subject: netmap: add extra interface on bridge From: upyzl To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 10:04:43 -0000 Hi there, I'm study on developing a simple openflow-based datapath module I know and tried successfully by "bridge -i em0 -i em1" Now I need bridge em0 em1 em2, but I find using vale-ctl is very difficult for me, as I need develop extract, match packets (packets from IN_PORT) and do actions from flow table (for simple, the flow table is static). I try like this, but only em0 & em1 are connect, without em2... --- "a/bridge.c" +++ "b/bridge.c" @@ -162,11 +162,11 @@ usage(void) int main(int argc, char **argv) { - struct pollfd pollfd[2]; + struct pollfd pollfd[3]; int i, ch; u_int burst = 1024, wait_link = 4; - struct my_ring me[2]; - char *ifa = NULL, *ifb = NULL; + struct my_ring me[3]; + char *ifa = NULL, *ifb = NULL, *ifc = NULL; fprintf(stderr, "%s %s built %s %s\n", argv[0], version, __DATE__, __TIME__); @@ -187,6 +187,8 @@ main(int argc, char **argv) ifa = optarg; else if (ifb == NULL) ifb = optarg; + else if (ifc == NULL) + ifc = optarg; else D("%s ignored, already have 2 interfaces", optarg); @@ -209,6 +211,8 @@ main(int argc, char **argv) if (argc > 2) ifb = argv[2]; if (argc > 3) + ifc = argv[3]; + if (argc > 4) burst = atoi(argv[3]); if (!ifb) ifb = ifa; @@ -227,6 +231,7 @@ main(int argc, char **argv) /* setup netmap interface #1. */ me[0].ifname = ifa; me[1].ifname = ifb; + me[2].ifname = ifc; if (!strcmp(ifa, ifb)) { D("same interface, endpoint 0 goes to host"); i = NETMAP_SW_RING; @@ -236,13 +241,15 @@ main(int argc, char **argv) } if (netmap_open(me, i, 1)) return (1); - me[1].mem = me[0].mem; /* copy the pointer, so only one mmap */ + me[2].mem = me[1].mem = me[0].mem; /* copy the pointer, so only one mmap */ if (netmap_open(me+1, 0, 1)) return (1); + if (netmap_open(me+2, 0, 1)) + return (1); /* setup poll(2) variables. */ memset(pollfd, 0, sizeof(pollfd)); - for (i = 0; i < 2; i++) { + for (i = 0; i < 3; i++) { pollfd[i].fd = me[i].fd; pollfd[i].events = (POLLIN); } @@ -256,20 +263,31 @@ main(int argc, char **argv) /* main loop */ signal(SIGINT, sigint_h); while (!do_abort) { - int n0, n1, ret; - pollfd[0].events = pollfd[1].events = 0; - pollfd[0].revents = pollfd[1].revents = 0; + int n0, n1, n2, ret; + pollfd[0].events = pollfd[1].events = pollfd[2].events = 0; + pollfd[0].revents = pollfd[1].revents = pollfd[2].revents = 0; n0 = pkt_queued(me, 0); n1 = pkt_queued(me + 1, 0); - if (n0) + n2 = pkt_queued(me + 2, 0); + if (n0) { pollfd[1].events |= POLLOUT; + pollfd[2].events |= POLLOUT; + } else pollfd[0].events |= POLLIN; - if (n1) + if (n1) { pollfd[0].events |= POLLOUT; + pollfd[2].events |= POLLOUT; + } else pollfd[1].events |= POLLIN; - ret = poll(pollfd, 2, 2500); + if (n2) { + pollfd[0].events |= POLLOUT; + pollfd[1].events |= POLLOUT; + } + else + pollfd[2].events |= POLLIN; + ret = poll(pollfd, 3, 2500); if (ret <= 0 || verbose) D("poll %s [0] ev %x %x rx %d@%d tx %d," " [1] ev %x %x rx %d@%d tx %d", @@ -297,16 +315,25 @@ main(int argc, char **argv) } if (pollfd[0].revents & POLLOUT) { move(me + 1, me, burst); + move(me + 2, me, burst); // XXX we don't need the ioctl */ // ioctl(me[0].fd, NIOCTXSYNC, NULL); } if (pollfd[1].revents & POLLOUT) { move(me, me + 1, burst); + move(me + 2, me + 1, burst); // XXX we don't need the ioctl */ // ioctl(me[1].fd, NIOCTXSYNC, NULL); } + if (pollfd[2].revents & POLLOUT) { + move(me, me + 2, burst); + move(me + 1, me + 2, burst); + // XXX we don't need the ioctl */ + // ioctl(me[2].fd, NIOCTXSYNC, NULL); + } } D("exiting"); + netmap_close(me + 2); netmap_close(me + 1); netmap_close(me + 0); for last, use ioctl instead of move is failed either... any advices or relative documents for devel are welcome :) Regards From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 13:36:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F782FFD for ; Mon, 3 Nov 2014 13:36:40 +0000 (UTC) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2C8FFD for ; Mon, 3 Nov 2014 13:36:39 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id u10so846451lbd.25 for ; Mon, 03 Nov 2014 05:36:36 -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 :cc:subject:references:in-reply-to:content-type; bh=RQYQWGbQRfW7x6ZCam51/ADKBv16ZlFXh6ADFWZXTgA=; b=iERZpIZQD2mMWLD5bnXxrtc/9gLrSBiYWUZv1/3QwplzO/uigegn6YHu5Rg9U20xM/ sb/aWq9rXc4+5T1grSj5uIRgjnIaBEIW6Ksh72bWxpa7PcL90oTWnYZyI83h3zc6eVYG sFxxzBpurJyDzbVhqJrlgLqyhAtzxgkiGbqd6CTnMpJDRevmpGUC0N8gObCGMATcH01M eJ5VAZnEpihDnWqvhFLezTZ+yrUHfvHNLFMqJYSFLt+4mi/MSPxt3bAJo0qc9/4D+4Pd UnBVVsO2fLh3tRUvZgwveil2cWpqhnAB9tEbmXFg1n3BEiH3d58Ar94q32xMjuAPmelP F6zg== X-Gm-Message-State: ALoCoQl2nib5w+pSpMJYQV/iWtXpUkCPmPKDtoErp/bOF4jInicpu/oo8u/ODDW3GPesclkrTVxe X-Received: by 10.112.239.12 with SMTP id vo12mr51324731lbc.81.1415021367271; Mon, 03 Nov 2014 05:29:27 -0800 (PST) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id ak7sm7948249lbc.12.2014.11.03.05.29.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 05:29:26 -0800 (PST) Message-ID: <5457832D.6070709@freebsd.org> Date: Mon, 03 Nov 2014 14:29:17 +0100 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <542EA1C9.6080907@freebsd.org> In-Reply-To: <542EA1C9.6080907@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VLXE2EJj2IFQl2Cv5JLw3s1W08jPW5rqc" Cc: "De La Gueronniere, Marc" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 13:36:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VLXE2EJj2IFQl2Cv5JLw3s1W08jPW5rqc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 03/10/14 15:16, Julien Charbon wrote: > On 23/05/14 14:06, Julien Charbon wrote: >> On 27/02/14 11:32, Julien Charbon wrote: >>> On 07/11/13 14:55, Julien Charbon wrote: >>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>>> wrote: >>>>> I have put technical and how-to-repeat details in below PR: >>>>> >>>>> kern/183659: TCP stack lock contention with short-lived connections= >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183659 >>>>> >>>>> We are currently working on this performance improvement effort; = it >>>>> will impact only the TCP locking strategy not the TCP stack logic >>>>> itself. We will share on freebsd-net the patches we made for >>>>> reviewing and improvement propositions; anyway this change might a= lso >>>>> require enough eyeballs to avoid tricky race conditions introductio= n >>>>> in TCP stack. As usual, a follow-up the TCP short-lived connections performance improvement progress: Thanks to jhb (mentor/reviewer) and adrian, rpaulo, rwatson (reviewers), two related commits have been added in HEAD: - First, just a fix for a wrong ECONNRESET error on close(): A connection in TIME_WAIT state before calling close() actually did not received any RST packet https://svnweb.freebsd.org/base?view=3Drevision&revision=3D273014 - Second, a race condition fix with a code clean-up: Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and tcp_tw_2msl_scan() https://svnweb.freebsd.org/base?view=3Drevision&revision=3D273850 It means that the whole set of tcp_tw_2msl_scan()-related changes could now be MFC-ed in 10-STABLE as the KBI stability can be kept now: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264321 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264342 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264351 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264356 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D273850 It also means that only one (big) related patch remains to be pushed: Introduce the INP_LIST global mutex for protecting pcbinfo global structures. Then use INP_INFO_RLOCK in critical paths to increase TCP processing scalability, and use INP_INFO_WLOCK in full INPs iteration loops. (See also joined patch). https://github.com/verisign/freebsd/commit/6e47f726f4d58f986e977fb0f816b8= a271804460 Nothing new here, just check previous emails in this thread to get all details. So far, we are adding comments and reviewing the change in more specific cases, then we plan to push this change in review around December 2014. My 2 cents. -- Julien --VLXE2EJj2IFQl2Cv5JLw3s1W08jPW5rqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUV4M0AAoJEKVlQ5Je6dhxG+IIAJ3sAh4KnAkAmySbRnPnFV7N WtnsOTxsJLZPqtDOQI1vaJZQrS7d8JS3WftDs29LuTc6Va8iCyiXt2xFZaPjXEPy Mm1eF7nuHRpW/u/tcSzGlm+rUrXYza92g685solZKkCyIYCyAS5r4UtmD2S2ReqV U5wFYGSud3fY3/H+3cJMb9aEU1kWmHxkzsVZxSBr9LUhK+Cd8Fwy+VqLo7r1PlUb dgjtCeaOFXzjXv88/BynfyIMHzH+n/XOfJ0FaRKPs/EWYS1YIKaMhaSthNcp9ECo oVGYfXOYE6cyYGka3g6tYHY1rW6FEtRM5vYNCsbBIwwIiLyK2t4U52TfO8tjU5Y= =6plW -----END PGP SIGNATURE----- --VLXE2EJj2IFQl2Cv5JLw3s1W08jPW5rqc-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 17:32:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE610EBA for ; Mon, 3 Nov 2014 17:32:01 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B96EF4F for ; Mon, 3 Nov 2014 17:32:01 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id r10so5085665igi.12 for ; Mon, 03 Nov 2014 09:32:01 -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=IiZnsjxdWY+HLTP3CsJhcmchNk8UnE4dzbLx3j8gllk=; b=yqDIgG7feBcexByyHrZiU3NnhBUfvUo1mtHQsp2OLlwtpAq4yV3QnNem7K2BhtLlCV 7iT4Coa4FG90OB/iv35YMwHDMMFXzO9hoE1JTPTLVh2xYaDf+9STdFzgGkYTt41Xzbwm 8IQfAzomw6XTC8UQmJpiixKXk0JBbuLQkQ8LNZpxj8t2Jrl3qLZ+8exu0q+8Ro26VUCS ceXnoauc4si25ooDa3EPFeJlDE+PvGU+xEfoKcYPUcbtYZYZpNuqg3LwZSjWW1tu85z5 JJLy9wwg7CrwyG/vz3fcrCaHMhLgesqb+jqh58JeRy9e3NVZtt9UDxlCS60PHOLoXQCy mS0w== MIME-Version: 1.0 X-Received: by 10.42.136.133 with SMTP id u5mr34244200ict.33.1415035920959; Mon, 03 Nov 2014 09:32:00 -0800 (PST) Received: by 10.107.8.194 with HTTP; Mon, 3 Nov 2014 09:32:00 -0800 (PST) Date: Mon, 3 Nov 2014 11:32:00 -0600 Message-ID: Subject: How do I poll() over just one ring on netmap? From: David To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:32:01 -0000 hi, I've been working with netmap with great results. My problem now is that I haven't figure out how to poll on just one TX ring to check for space available. I have several tx ring connected. I've been working with the pkt-gen example and I found a call to poll(), but when I step into the code that handles that I notice it is going over all the available rings, regardless I just want to send using one. How do I poll() over just one ring? Thanks --=20 David D=C3=ADaz Barquero Ingenier=C3=ADa en Computadores Tecnol=C3=B3gico de Costa Rica From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 19:34:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06B96931 for ; Mon, 3 Nov 2014 19:34:26 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85495EAA for ; Mon, 3 Nov 2014 19:34:25 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so7383885wiw.0 for ; Mon, 03 Nov 2014 11:34:23 -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=GPb6mHV8Eces5KmeAm8nkoKH8Xitv3msomb7IJdt9r0=; b=hX4KUMIVikuISL/zsvkFKpWJZnsKIGMAD+HcX5d9oSHuh2puUdDqADZuXYI82vgjJL iw4Y+TmHgN923H0S5vpp1FC99bUzClNa5UUwClDpIQhIA619B7Id5JBiS6Y6mcj/2H4Y GTE6Mu/Lq1oOqMsYiEuxTf+UlGl6JzOYwy9JCp7OEuqQyPxccjoqPSjPTbNHa8RFlGsj AgHRK3ennvcitsd+SvHAszRUUzO1I3cgW5HOHmeN0j0PLPI7kUi9sjb8v+MEbODzCJeu hGDX7TD8TSUS0JgpnH5hdPB9EzUcYrloRlBWVSDwYM+IIZsxrPGB2/q5wepwjCcPzdAL NAxw== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr5351738wjr.104.1415043263809; Mon, 03 Nov 2014 11:34:23 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Mon, 3 Nov 2014 11:34:23 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 11:34:23 -0800 X-Google-Sender-Auth: TQxnKIVW-116Lx8XCES_-yd_hJQ Message-ID: Subject: Re: netmap: add extra interface on bridge From: Luigi Rizzo To: upyzl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 19:34:26 -0000 On Monday, November 3, 2014, upyzl wrote: > Hi there, > > I'm study on developing a simple openflow-based datapath module > > I know and tried successfully by "bridge -i em0 -i em1" > > Now I need bridge em0 em1 em2, but I find using vale-ctl is very difficult > for me, as I need develop extract, match packets (packets from IN_PORT) and > do actions from flow table (for simple, the flow table is static). You are much batter off rewriting the whole thing yoirself. bridge.c is hardwired for transparent interconnection of two interfaces, so the patches you show below cannot possibly work. Here is a suggestion. Try to design (pen and paper) a simple handler that grabs packets from one interface, classifies them using your custom floe table and queues to the various output interfaces. Write a second handler that takes packets from an output queue and pushes them to a port. Ignore performance, for simplicity; thingd are already hard enough. Ignore the fact you are using netmap, that is just a detail, you can design your pseudo code as something that reads one packet at a time and writes one packet at a time. In the process, define what is your policy for dealing with a full output queue, also consider the broadcast case (you either drop, or block but with a timeout to avoid stalling the world because of a single port being down). Then you can write your event loop registering all input fds that are not blocked (see previous point), all output fds that have traffic queued, a timeout handler. This will be single threaded do you do not have to worry about locking. Once this works you can look at performance. For that, there is a ton of solutions (heavily commented) you can find in netmap_vale.c part of the netmap sources. Cheers Luigi > > I try like this, but only em0 & em1 are connect, without em2... > > --- "a/bridge.c" > +++ "b/bridge.c" > @@ -162,11 +162,11 @@ usage(void) > int > main(int argc, char **argv) > { > - struct pollfd pollfd[2]; > + struct pollfd pollfd[3]; > int i, ch; > u_int burst = 1024, wait_link = 4; > - struct my_ring me[2]; > - char *ifa = NULL, *ifb = NULL; > + struct my_ring me[3]; > + char *ifa = NULL, *ifb = NULL, *ifc = NULL; > > fprintf(stderr, "%s %s built %s %s\n", > argv[0], version, __DATE__, __TIME__); > @@ -187,6 +187,8 @@ main(int argc, char **argv) > ifa = optarg; > else if (ifb == NULL) > ifb = optarg; > + else if (ifc == NULL) > + ifc = optarg; > else > D("%s ignored, already have 2 interfaces", > optarg); > @@ -209,6 +211,8 @@ main(int argc, char **argv) > if (argc > 2) > ifb = argv[2]; > if (argc > 3) > + ifc = argv[3]; > + if (argc > 4) > burst = atoi(argv[3]); > if (!ifb) > ifb = ifa; > @@ -227,6 +231,7 @@ main(int argc, char **argv) > /* setup netmap interface #1. */ > me[0].ifname = ifa; > me[1].ifname = ifb; > + me[2].ifname = ifc; > if (!strcmp(ifa, ifb)) { > D("same interface, endpoint 0 goes to host"); > i = NETMAP_SW_RING; > @@ -236,13 +241,15 @@ main(int argc, char **argv) > } > if (netmap_open(me, i, 1)) > return (1); > - me[1].mem = me[0].mem; /* copy the pointer, so only one mmap */ > + me[2].mem = me[1].mem = me[0].mem; /* copy the pointer, so only one > mmap */ > if (netmap_open(me+1, 0, 1)) > return (1); > + if (netmap_open(me+2, 0, 1)) > + return (1); > > /* setup poll(2) variables. */ > memset(pollfd, 0, sizeof(pollfd)); > - for (i = 0; i < 2; i++) { > + for (i = 0; i < 3; i++) { > pollfd[i].fd = me[i].fd; > pollfd[i].events = (POLLIN); > } > @@ -256,20 +263,31 @@ main(int argc, char **argv) > /* main loop */ > signal(SIGINT, sigint_h); > while (!do_abort) { > - int n0, n1, ret; > - pollfd[0].events = pollfd[1].events = 0; > - pollfd[0].revents = pollfd[1].revents = 0; > + int n0, n1, n2, ret; > + pollfd[0].events = pollfd[1].events = pollfd[2].events = 0; > + pollfd[0].revents = pollfd[1].revents = pollfd[2].revents = 0; > n0 = pkt_queued(me, 0); > n1 = pkt_queued(me + 1, 0); > - if (n0) > + n2 = pkt_queued(me + 2, 0); > + if (n0) { > pollfd[1].events |= POLLOUT; > + pollfd[2].events |= POLLOUT; > + } > else > pollfd[0].events |= POLLIN; > - if (n1) > + if (n1) { > pollfd[0].events |= POLLOUT; > + pollfd[2].events |= POLLOUT; > + } > else > pollfd[1].events |= POLLIN; > - ret = poll(pollfd, 2, 2500); > + if (n2) { > + pollfd[0].events |= POLLOUT; > + pollfd[1].events |= POLLOUT; > + } > + else > + pollfd[2].events |= POLLIN; > + ret = poll(pollfd, 3, 2500); > if (ret <= 0 || verbose) > D("poll %s [0] ev %x %x rx %d@%d tx %d," > " [1] ev %x %x rx %d@%d tx %d", > @@ -297,16 +315,25 @@ main(int argc, char **argv) > } > if (pollfd[0].revents & POLLOUT) { > move(me + 1, me, burst); > + move(me + 2, me, burst); > // XXX we don't need the ioctl */ > // ioctl(me[0].fd, NIOCTXSYNC, NULL); > } > if (pollfd[1].revents & POLLOUT) { > move(me, me + 1, burst); > + move(me + 2, me + 1, burst); > // XXX we don't need the ioctl */ > // ioctl(me[1].fd, NIOCTXSYNC, NULL); > } > + if (pollfd[2].revents & POLLOUT) { > + move(me, me + 2, burst); > + move(me + 1, me + 2, burst); > + // XXX we don't need the ioctl */ > + // ioctl(me[2].fd, NIOCTXSYNC, NULL); > + } > } > D("exiting"); > + netmap_close(me + 2); > netmap_close(me + 1); > netmap_close(me + 0); > > > for last, use ioctl instead of move is failed either... > > any advices or relative documents for devel are welcome :) > > Regards > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 21:18:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE232E5 for ; Mon, 3 Nov 2014 21:18:20 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76B80BB2 for ; Mon, 3 Nov 2014 21:18:20 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id q5so7623606wiv.5 for ; Mon, 03 Nov 2014 13:18:17 -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=lqIgi7RBYwPXGp3o/1+0gLU0y3sJIKhHRNIWCOXSdhM=; b=J9L7DxWI2FCrq39q9zrLDY6rDanf6j+gQ9LxMPxcaOPTgQHMSRiwp6Cgr84C8iXUug 54TUuWkWMOVRgterTAUUAFiPsRVFEiPUhwJDmOyoVHa1/vnxfG1uQ017CYgRzO8CvTwt EqV6CHhxfPqSzL28W6l9pXiyT8Zy0pEoYLNfvkBkqV773M52F5uu6woUuUbE6oYDzafI TVjTcWObpsRsd/BG8g4qJibD/fCLxlP/N5Z6QFybZO+mwFz5k3IY+thf3OUhrXztonFU hurYQSREiPJbkud6LRZ3VeNJdXfq2qyhwrVrgqUx3/O7F4dDuRM5WUOocbi+VmdyxUsT VXSA== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr22776427wjb.78.1415049497817; Mon, 03 Nov 2014 13:18:17 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Mon, 3 Nov 2014 13:18:17 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Nov 2014 13:18:17 -0800 X-Google-Sender-Auth: CW69aifr9963d-yxJOuXkL6EANA Message-ID: Subject: Re: How do I poll() over just one ring on netmap? From: Luigi Rizzo To: David Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 21:18:21 -0000 On Monday, November 3, 2014, David wrote: > hi, > > I've been working with netmap with great results. My problem now is that = I > haven't figure out how to poll on just one TX ring to check for space > available. You have to specify a single ring index as the argument to the NIOCREGIF ioctl (or equivalent info as the name to nm_open(), e.g. netmap:ix0-2 to revrivr notifications from the third ring. Note that pkt-gen is not yet able to support one ring at a time (it will always use all rings, either with a single thread for all or with one thread per ring). Cheers Luigi > I have several tx ring connected. I've been working with the pkt-gen > example and I found a call to poll(), but when I step into the code that > handles that I notice it is going over all the available rings, regardles= s > I just want to send using one. > > How do I poll() over just one ring? > > Thanks > > -- > David D=C3=ADaz Barquero > > Ingenier=C3=ADa en Computadores > Tecnol=C3=B3gico de Costa Rica > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Nov 3 22:25:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C412B90B; Mon, 3 Nov 2014 22:25:34 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D53437A; Mon, 3 Nov 2014 22:25:34 +0000 (UTC) Received: from [192.168.192.254] (unknown [129.253.54.225]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 79623193964; Mon, 3 Nov 2014 22:25:33 +0000 (UTC) Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Sean Bruno Reply-To: sbruno@freebsd.org To: FreeBSD Net In-Reply-To: <1414873489.2069.1.camel@bruno> References: <1414525275.43009.3.camel@bruno> <20141030025241.GA73148@ns.kevlo.org> <1414692589.1773.11.camel@bruno> <1414696307.1773.12.camel@bruno> <1414873489.2069.1.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Nov 2014 14:25:32 -0800 Message-ID: <1415053532.1163.16.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Kevin Lo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 22:25:34 -0000 On Sat, 2014-11-01 at 13:24 -0700, Sean Bruno wrote: > ooo lovely. Able to get two different panics out of my laptop today. > Both in urtwn(4). > > Is this a USB problem and not a driver failure? > > https://people.freebsd.org/~sbruno/core.txt.1 > > https://people.freebsd.org/~sbruno/core.txt.0 > > sean > > _______________________________________________ > 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" So, this appears to be a symptom of an overheating and failing adapter. It suddenly died on me this weekend and changed usb devid and lost its MAC address. I bought 3 different units from Fry's this weekend and all three "just work". I appear to have 3 completely 100% working adapters. I have thrown the broke adapter away to never be seen again. sean From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 03:56:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8514743B for ; Tue, 4 Nov 2014 03:56:42 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5725D92D for ; Tue, 4 Nov 2014 03:56:42 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id r10so12817670pdi.17 for ; Mon, 03 Nov 2014 19:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uFCsMATL4ubvkIEw3sHp3H+FHNGI7O1n0J4JN5ZeqtE=; b=aYPOnsLQNZTM0n/76dpYYDICrgLtgPdHZisa8kVaSPbx01DHdfgflVujrd0yqdN0pw u8CTzEEnDLe2txwOm0W0SxlBB/62CTeipPt9SKeNR59Z4ZF5RI/PwNhYGFpwoIcZCn/R 4ROVpGBQkaUbUlcA40JD7cAMQJ6Fm5eIzMBixJx69W2qKOQakHbZseuHYkHOvVufbIyS steQ3cHtKHlJvpJ0W7CmL5pRmqQdX6lZ5H7eXrvPPWB+P05LGUw4Yzve72Ml9KIXrj8n TjtIu6UysO7T1AlIuNKvo4sGYRPZglkMIaTlMSK1S7BaQWXVDJQXVObKkfd0tQ5Br8/u CsIw== X-Received: by 10.68.65.68 with SMTP id v4mr42002380pbs.52.1415073383344; Mon, 03 Nov 2014 19:56:23 -0800 (PST) Received: from kmatoMacBook-Pro.local ([221.234.44.207]) by mx.google.com with ESMTPSA id hp4sm18419141pbb.95.2014.11.03.19.56.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 19:56:22 -0800 (PST) Message-ID: <54584E61.3020605@gmail.com> Date: Tue, 04 Nov 2014 11:56:17 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <542EA1C9.6080907@freebsd.org> <5457832D.6070709@freebsd.org> In-Reply-To: <5457832D.6070709@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 03:56:42 -0000 Great job. It would help me a lot. Simon 在 14/11/3 21:29, Julien Charbon 写é“: > > Hi, > > On 03/10/14 15:16, Julien Charbon wrote: >> On 23/05/14 14:06, Julien Charbon wrote: >>> On 27/02/14 11:32, Julien Charbon wrote: >>>> On 07/11/13 14:55, Julien Charbon wrote: >>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>>>> wrote: >>>>>> I have put technical and how-to-repeat details in below PR: >>>>>> >>>>>> kern/183659: TCP stack lock contention with short-lived connections >>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 >>>>>> >>>>>> We are currently working on this performance improvement effort; it >>>>>> will impact only the TCP locking strategy not the TCP stack logic >>>>>> itself. We will share on freebsd-net the patches we made for >>>>>> reviewing and improvement propositions; anyway this change might also >>>>>> require enough eyeballs to avoid tricky race conditions introduction >>>>>> in TCP stack. > > As usual, a follow-up the TCP short-lived connections performance > improvement progress: > > Thanks to jhb (mentor/reviewer) and adrian, rpaulo, rwatson > (reviewers), two related commits have been added in HEAD: > > - First, just a fix for a wrong ECONNRESET error on close(): > > A connection in TIME_WAIT state before calling close() actually did not > received any RST packet > https://svnweb.freebsd.org/base?view=revision&revision=273014 > > - Second, a race condition fix with a code clean-up: > > Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and > tcp_tw_2msl_scan() > https://svnweb.freebsd.org/base?view=revision&revision=273850 > > It means that the whole set of tcp_tw_2msl_scan()-related changes could > now be MFC-ed in 10-STABLE as the KBI stability can be kept now: > > https://svnweb.freebsd.org/base?view=revision&revision=264321 > https://svnweb.freebsd.org/base?view=revision&revision=264342 > https://svnweb.freebsd.org/base?view=revision&revision=264351 > https://svnweb.freebsd.org/base?view=revision&revision=264356 > https://svnweb.freebsd.org/base?view=revision&revision=273850 > > It also means that only one (big) related patch remains to be pushed: > > Introduce the INP_LIST global mutex for protecting pcbinfo > global structures. Then use INP_INFO_RLOCK in critical paths to > increase TCP processing scalability, and use INP_INFO_WLOCK in full INPs > iteration loops. (See also joined patch). > https://github.com/verisign/freebsd/commit/6e47f726f4d58f986e977fb0f816b8a271804460 > > Nothing new here, just check previous emails in this thread to get all > details. So far, we are adding comments and reviewing the change in > more specific cases, then we plan to push this change in review around > December 2014. > > My 2 cents. > > -- > Julien > From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 07:07: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FE62368 for ; Tue, 4 Nov 2014 07:07:00 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC16C01 for ; Tue, 4 Nov 2014 07:06:59 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id m8so9957116obr.22 for ; Mon, 03 Nov 2014 23:06:59 -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=2jzWrFYnU4AB2RROj4zrYH+i8SyorGijFISbXN7tQXg=; b=Ohuc7gF8aIdo76vGSXw/6wVzMvW/oBpXETTzpVm12bbpMxSGA+aUofctv+4JDcDk5L OsRFz0YxNMH8kjrd3W43pTV9xDhkDMGjTUM6n5/42D51Z1FsZ/d1B3dbQ5T1fYuepxFP qVwms1MWbteh6w2ehmpMW6KefifRu0I61gp8A/uX+hb3RUbhFJWUvoghWltYxk1CWRke 9ReDWUMEutKrA/+915pbTWiQ92DvIhW9UNHzObKmBfmRLuj5nLsKxjKK0UZYivI8a6KZ ZPaZ8t2Om31ok7o2LPwFVxjfyBRF9gZlTmycSxnQUWWJyN/iAXa4hDM50kB0BgubQEmA T9Zg== MIME-Version: 1.0 X-Received: by 10.182.92.234 with SMTP id cp10mr663921obb.53.1415084819044; Mon, 03 Nov 2014 23:06:59 -0800 (PST) Received: by 10.76.167.202 with HTTP; Mon, 3 Nov 2014 23:06:58 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 15:06:58 +0800 Message-ID: Subject: Re: netmap: add extra interface on bridge From: upyzl To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 07:07:00 -0000 Very useful! thx very much 2014-11-04 3:34 GMT+08:00 Luigi Rizzo : > > > On Monday, November 3, 2014, upyzl wrote: > >> Hi there, >> >> I'm study on developing a simple openflow-based datapath module >> >> I know and tried successfully by "bridge -i em0 -i em1" >> >> Now I need bridge em0 em1 em2, but I find using vale-ctl is very difficult >> for me, as I need develop extract, match packets (packets from IN_PORT) >> and >> do actions from flow table (for simple, the flow table is static). > > > You are much batter off rewriting the whole thing yoirself. bridge.c is > hardwired for transparent interconnection of two interfaces, so the > patches you show below cannot possibly work. > > Here is a suggestion. > > Try to design (pen and paper) a simple handler that grabs packets from one > interface, classifies them using your custom floe table and queues to the > various output interfaces. > > Write a second handler that takes packets from an output queue and pushes > them to a port. > > Ignore performance, for simplicity; thingd are already hard enough. > Ignore the fact you are using netmap, that is just a detail, you can design > your pseudo code as something that reads one packet at a time and writes > one packet at a time. > > In the process, define what is your policy for dealing with a full output > queue, also consider the broadcast case (you either drop, or block but with > a timeout to avoid stalling the world because of a single port being down). > > Then you can write your event loop registering all input fds that are not > blocked (see previous point), all output fds that have traffic queued, a > timeout handler. > > This will be single threaded do you do not have to worry about locking. > > Once this works you can look at performance. > For that, there is a ton of solutions (heavily commented) you can find in > netmap_vale.c part of the netmap sources. > > Cheers > Luigi > >> >> I try like this, but only em0 & em1 are connect, without em2... >> >> --- "a/bridge.c" >> +++ "b/bridge.c" >> @@ -162,11 +162,11 @@ usage(void) >> int >> main(int argc, char **argv) >> { >> - struct pollfd pollfd[2]; >> + struct pollfd pollfd[3]; >> int i, ch; >> u_int burst = 1024, wait_link = 4; >> - struct my_ring me[2]; >> - char *ifa = NULL, *ifb = NULL; >> + struct my_ring me[3]; >> + char *ifa = NULL, *ifb = NULL, *ifc = NULL; >> >> fprintf(stderr, "%s %s built %s %s\n", >> argv[0], version, __DATE__, __TIME__); >> @@ -187,6 +187,8 @@ main(int argc, char **argv) >> ifa = optarg; >> else if (ifb == NULL) >> ifb = optarg; >> + else if (ifc == NULL) >> + ifc = optarg; >> else >> D("%s ignored, already have 2 interfaces", >> optarg); >> @@ -209,6 +211,8 @@ main(int argc, char **argv) >> if (argc > 2) >> ifb = argv[2]; >> if (argc > 3) >> + ifc = argv[3]; >> + if (argc > 4) >> burst = atoi(argv[3]); >> if (!ifb) >> ifb = ifa; >> @@ -227,6 +231,7 @@ main(int argc, char **argv) >> /* setup netmap interface #1. */ >> me[0].ifname = ifa; >> me[1].ifname = ifb; >> + me[2].ifname = ifc; >> if (!strcmp(ifa, ifb)) { >> D("same interface, endpoint 0 goes to host"); >> i = NETMAP_SW_RING; >> @@ -236,13 +241,15 @@ main(int argc, char **argv) >> } >> if (netmap_open(me, i, 1)) >> return (1); >> - me[1].mem = me[0].mem; /* copy the pointer, so only one mmap */ >> + me[2].mem = me[1].mem = me[0].mem; /* copy the pointer, so only one >> mmap */ >> if (netmap_open(me+1, 0, 1)) >> return (1); >> + if (netmap_open(me+2, 0, 1)) >> + return (1); >> >> /* setup poll(2) variables. */ >> memset(pollfd, 0, sizeof(pollfd)); >> - for (i = 0; i < 2; i++) { >> + for (i = 0; i < 3; i++) { >> pollfd[i].fd = me[i].fd; >> pollfd[i].events = (POLLIN); >> } >> @@ -256,20 +263,31 @@ main(int argc, char **argv) >> /* main loop */ >> signal(SIGINT, sigint_h); >> while (!do_abort) { >> - int n0, n1, ret; >> - pollfd[0].events = pollfd[1].events = 0; >> - pollfd[0].revents = pollfd[1].revents = 0; >> + int n0, n1, n2, ret; >> + pollfd[0].events = pollfd[1].events = pollfd[2].events = 0; >> + pollfd[0].revents = pollfd[1].revents = pollfd[2].revents = 0; >> n0 = pkt_queued(me, 0); >> n1 = pkt_queued(me + 1, 0); >> - if (n0) >> + n2 = pkt_queued(me + 2, 0); >> + if (n0) { >> pollfd[1].events |= POLLOUT; >> + pollfd[2].events |= POLLOUT; >> + } >> else >> pollfd[0].events |= POLLIN; >> - if (n1) >> + if (n1) { >> pollfd[0].events |= POLLOUT; >> + pollfd[2].events |= POLLOUT; >> + } >> else >> pollfd[1].events |= POLLIN; >> - ret = poll(pollfd, 2, 2500); >> + if (n2) { >> + pollfd[0].events |= POLLOUT; >> + pollfd[1].events |= POLLOUT; >> + } >> + else >> + pollfd[2].events |= POLLIN; >> + ret = poll(pollfd, 3, 2500); >> if (ret <= 0 || verbose) >> D("poll %s [0] ev %x %x rx %d@%d tx %d," >> " [1] ev %x %x rx %d@%d tx %d", >> @@ -297,16 +315,25 @@ main(int argc, char **argv) >> } >> if (pollfd[0].revents & POLLOUT) { >> move(me + 1, me, burst); >> + move(me + 2, me, burst); >> // XXX we don't need the ioctl */ >> // ioctl(me[0].fd, NIOCTXSYNC, NULL); >> } >> if (pollfd[1].revents & POLLOUT) { >> move(me, me + 1, burst); >> + move(me + 2, me + 1, burst); >> // XXX we don't need the ioctl */ >> // ioctl(me[1].fd, NIOCTXSYNC, NULL); >> } >> + if (pollfd[2].revents & POLLOUT) { >> + move(me, me + 2, burst); >> + move(me + 1, me + 2, burst); >> + // XXX we don't need the ioctl */ >> + // ioctl(me[2].fd, NIOCTXSYNC, NULL); >> + } >> } >> D("exiting"); >> + netmap_close(me + 2); >> netmap_close(me + 1); >> netmap_close(me + 0); >> >> >> for last, use ioctl instead of move is failed either... >> >> any advices or relative documents for devel are welcome :) >> >> Regards >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 09:33:52 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA588D42 for ; Tue, 4 Nov 2014 09:33:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A10CCFCA for ; Tue, 4 Nov 2014 09:33:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA49Xq9g084860 for ; Tue, 4 Nov 2014 09:33:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 136911] [netgraph] [panic] system panic on kldload ng_bpf.ko then options NETGRAPH_BPF is built in Date: Tue, 04 Nov 2014 09:33:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 09:33:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136911 rozhuk.im@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 13:56: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F278B6F4 for ; Tue, 4 Nov 2014 13:56:32 +0000 (UTC) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F82D7ED for ; Tue, 4 Nov 2014 13:56:32 +0000 (UTC) Received: by mail-wi0-f194.google.com with SMTP id ex7so3341517wid.5 for ; Tue, 04 Nov 2014 05:56:30 -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=1LkoTBGw6FHj+mLmz6wcTr9PUUJEUPms5/jHWa9RQfs=; b=I2HScExl2vSek8ffENQbVP4I3ichs7RBYF/qvCwXk4uCZacc5xYK3XVrinbRn8TZci aBEtga7r6f91SCTo46xlX5ovwwg3jsxxlWLWUAnyqn0j1JSFBGj8vCBEEMz5BwWNDxse hXm8faycQ9zOqXsjTSunhwLJO3cLB+ncNW+vU/sbvxVgMW1e+T1R3gW6Ud5LtxOPQGwO P/VxHb1tizGnepYxr/mE2wvtPW10gTaMTHxAT9qp1yz5lQuyajVvf49LYnaSO/f/MUeY 2xqBK1F/caRYdS2ctv426MGTmvwMQhi5ukmp6ERu633W+zIbWsf68GYqhk0wBEZGF/qr BoGg== MIME-Version: 1.0 X-Received: by 10.180.101.102 with SMTP id ff6mr24459856wib.0.1415109390863; Tue, 04 Nov 2014 05:56:30 -0800 (PST) Received: by 10.217.92.7 with HTTP; Tue, 4 Nov 2014 05:56:30 -0800 (PST) Date: Tue, 4 Nov 2014 11:56:30 -0200 Message-ID: Subject: netmap-ipfw on em0 em1 From: Evandro Nunes To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:56:33 -0000 hello, I am trying to do some basic stateless filtering with netmap-ipfw. what i have running is: ./kipfw em1 em2 lo0 and when i do ipfw/ipfw show: ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 136 ptr 0x0 00100 0 0 allow ip from any to any via lo0 65535 0 0 allow ip from any to any it's not counting any packet, including loopback i have seem people using something similar but with ix(4) driver, what I am doing wrong? From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 14:11:20 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A4EBB4 for ; Tue, 4 Nov 2014 14:11:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BE019C5 for ; Tue, 4 Nov 2014 14:11:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA4EBK7c076309 for ; Tue, 4 Nov 2014 14:11:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 190102] [tcp] net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ [regression] Date: Tue, 04 Nov 2014 14:11:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: feld@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:11:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190102 Mark Felder changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |Works As Intended --- Comment #6 from Mark Felder --- Closing this. There was an off-list discussion where some sensitive information was exchanged to further evaluate this situation. After some testing mistakes on both ends were resolved we concluded that the behavior is correct and manual attempts to invoke this bug were unsuccessful. It seems the remote scanning service we were using was possibly triggering a bug of its own. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 14:37:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C190390 for ; Tue, 4 Nov 2014 14:37:50 +0000 (UTC) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA653C0F for ; Tue, 4 Nov 2014 14:37:49 +0000 (UTC) Received: by mail-wi0-f194.google.com with SMTP id ex7so3375815wid.9 for ; Tue, 04 Nov 2014 06:37:48 -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 :content-type; bh=gQbgQ0U9FhVBEL2Pn6dHvsPuLj7CU7uW3EmkQh5gcx0=; b=cWfyiUu35YGpHufLqbBD6d3z8o7LD9Au8EgUi3hfVTadS63lIHXQToXwCA7xd+LL3M DpTFGS/G6mU6WgMUrmD1WT4PmSF+l9YtYTkaEuwTFy62BxSytx1BVzvox6L2q80gL0CJ GWCkQcfaAs66SMSIVeYLpX+jwbdrFj36as4rUfReOxdWPem4jovde+31OqQmnNagdYmW jzYTNZbqmBRnd8lLTvOQrataeIdM7OB4M7KzGDPfzahGRJeSx2CAYg1f2vaVuvfkT+tW f7/hOWKiz2ScFyxTjlSQqltQ54y/MV8KZ7nj4dMR0kJ9YRCjoXAWRDAmXCzflovXh3TJ +Faw== MIME-Version: 1.0 X-Received: by 10.180.107.136 with SMTP id hc8mr24093662wib.78.1415111868139; Tue, 04 Nov 2014 06:37:48 -0800 (PST) Received: by 10.217.92.7 with HTTP; Tue, 4 Nov 2014 06:37:48 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 12:37:48 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:37:50 -0000 btw, I am generating traffic via pkt-gen which I can see os received on the other side: # /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1 -f tx -l 60 -d 172.16.250.10 643.417060 main [1649] interface is em1 643.417344 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 643.417386 extract_ip_range [287] range is 172.16.250.10:0 to 172.16.250.10:0 643.433773 main [1840] mapped 334980KB at 0x801800000 Sending on netmap:em1: 1 queues, 1 threads and 1 cpus. 10.0.0.1 -> 172.16.250.10 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) 643.433885 main [1924] Sending 512 packets every 0.000000000 s 643.433895 main [1926] Wait 2 secs for phy reset 645.434799 main [1928] Ready... 645.435012 nm_open [456] overriding ifname em1 ringid 0x0 flags 0x1 645.435315 sender_body [1014] start, fd 4 main_fd 3 646.100734 sender_body [1083] drop copy 646.436332 main_thread [1446] 149811 pps (149967 pkts in 1001041 usec) 647.437206 main_thread [1446] 148782 pps (148912 pkts in 1000875 usec) 648.438209 main_thread [1446] 148795 pps (148944 pkts in 1001002 usec) 649.439233 main_thread [1446] 50812 pps (50864 pkts in 1001024 usec) Sent 498687 packets, 60 bytes each, in 3.35 seconds. Speed: 148.81 Kpps Bandwidth: 71.43 Mbps (raw 100.00 Mbps) anyway ipfw does not seem to see this netmap-aware traffic: # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 112 ptr 0x0 00100 0 0 count ip from any to any 65535 0 0 allow ip from any to any while it's still running: # ps wauxw | grep ipfw root 40820 0.4 0.0 14648 1744 2 R 12:32PM 0:04.95 ./kipfw em1 em2 lo0 root 40886 0.0 0.0 14708 1552 2 DL+ 12:34PM 0:00.00 grep ipfw I am using latest netmap and netmap-ipfw source code, not the code from freebsd base system. everywhere I see examples, on readme files, luigi's papers and videos, it's related to vale interfaces, but what I want is to use it in phisical NIC not a vale NIC any further help is much appreciated thank you in advance On Tue, Nov 4, 2014 at 11:56 AM, Evandro Nunes wrote: > hello, > I am trying to do some basic stateless filtering with netmap-ipfw. > > what i have running is: > > ./kipfw em1 em2 lo0 > > and when i do ipfw/ipfw show: > > ipfw/ipfw show > connected to 127.0.0.1:5555 > nalloc 2248 nbytes 136 ptr 0x0 > 00100 0 0 allow ip from any to any via lo0 > 65535 0 0 allow ip from any to any > > it's not counting any packet, including loopback > > i have seem people using something similar but with ix(4) driver, what I > am doing wrong? > From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 19:02:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70F886E4 for ; Tue, 4 Nov 2014 19:02:52 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08C95DF2 for ; Tue, 4 Nov 2014 19:02:51 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id x13so14196675wgg.22 for ; Tue, 04 Nov 2014 11:02:50 -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=jSABSHMiMyAs377GhQ7m5341x7soSDLAMF/jUpbCRF8=; b=X9KSZnDqzNsXAaN+bix65LLse7M+heVGTmDkU+iuUo31jkoTUU5szBT6IrEiTteWSt 2iIz1Vq/QOZx1hLENY/BLEgvEyMnnMZkxjvAgIJCG+bGMQVoBVqxanKwgUrYthOEPsoy iVoh8yiqFnqUGjQiuGX7N0TxFVAmhpYlgzJH2EHsw33IKNAT+9a8vh5Ly38QiQMlIVer UA0gIg5klHdvOAYcPqbGsJJTNxcvvHS+tsV6FTHirq3ciKWP5wbiHlMxOyjjZ0ySmw36 N/aalQ4YmIXDgQCIRlChmqBRgg0gKrZgU1aiU1/4rGUADrd6Rgj1HyGptH+hAKHYs/oi iD5Q== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr30781431wjb.78.1415127770128; Tue, 04 Nov 2014 11:02:50 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Tue, 4 Nov 2014 11:02:50 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 11:02:50 -0800 X-Google-Sender-Auth: UoJtzdHvKOB-ss9CIaQ2aKswgzg Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:02:52 -0000 =E2=80=8Bthe user space netmap-ipfw only supports two interfaces, The hard problem in moving to 3+ interfaces is not much the code but deciding where to send a packet once it has passed the filter. Basically, passing things through the kernel stack is simple but performance is going to be no better than with the standard firewall (except for much better behaviour in blocking incoming attacks). cheers luigi On Tue, Nov 4, 2014 at 5:56 AM, Evandro Nunes wrote: > hello, > I am trying to do some basic stateless filtering with netmap-ipfw. > > what i have running is: > > ./kipfw em1 em2 lo0 > > and when i do ipfw/ipfw show: > > ipfw/ipfw show > connected to 127.0.0.1:5555 > nalloc 2248 nbytes 136 ptr 0x0 > 00100 0 0 allow ip from any to any via lo0 > 65535 0 0 allow ip from any to any > > it's not counting any packet, including loopback > > i have seem people using something similar but with ix(4) driver, what I = am > doing wrong? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 19:09:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 490978E1 for ; Tue, 4 Nov 2014 19:09:52 +0000 (UTC) Received: from mail-wg0-x241.google.com (mail-wg0-x241.google.com [IPv6:2a00:1450:400c:c00::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4BDCE5C for ; Tue, 4 Nov 2014 19:09:51 +0000 (UTC) Received: by mail-wg0-f65.google.com with SMTP id l18so2405438wgh.0 for ; Tue, 04 Nov 2014 11:09:50 -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=Cg3Zj38g8qTUDMgPB+v87TB9ehAOsBclG4X15x1MegQ=; b=t6POUHc3h7CO87wrmBsjPgj1F1uI+Y9JX/j4cNeaO8h51AzWuLDYoEo4TDvRIxu57M MGI6LgLHJrOUhgHg92W5mh+E2I0ZA9vUuwCDEZQbCpYqBjbZdH3JMKESMNfliQz9pqti mbz4vAgPsGxnazSjPDJvTQE9ekqn9jsn/ptoUDcAmpEXL0W40SZjwLkVl176A0LrhYdm laUypxiXQ5bzD/xted5hQghCFLh5TOUwZtf0Jg3d6thReqwkQTgF8apxpPGsTSAKKfq2 RrEgmWCiXdxqWl1TCIkh+ipkE+hd+xKJb3avwECpZ4SdYOb1k+WIXklCDQBFkEUmK7Ep yufg== MIME-Version: 1.0 X-Received: by 10.180.104.105 with SMTP id gd9mr26132490wib.65.1415128190125; Tue, 04 Nov 2014 11:09:50 -0800 (PST) Received: by 10.217.92.7 with HTTP; Tue, 4 Nov 2014 11:09:50 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 17:09:50 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:09:52 -0000 so, running em1 and em2 only should work? because I have the same behavior: # ps wauxw | grep kipfw root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95 ./kipfw em1 em2 root 61518 0.0 0.0 18804 1864 2 S+ 5:07PM 0:00.00 grep kipfw # /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1 -f tx -l 60 -d 172.16.250.10 112.372344 main [1649] interface is em1 112.372597 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 112.372622 extract_ip_range [287] range is 172.16.250.10:0 to 172.16.250.10:0 112.388845 main [1840] mapped 334980KB at 0x801800000 Sending on netmap:em1: 1 queues, 1 threads and 1 cpus. 10.0.0.1 -> 172.16.250.10 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) 112.388956 main [1924] Sending 512 packets every 0.000000000 s 112.388966 main [1926] Wait 2 secs for phy reset 114.389236 main [1928] Ready... 114.389473 nm_open [456] overriding ifname em1 ringid 0x0 flags 0x1 114.389765 sender_body [1014] start, fd 4 main_fd 3 115.055243 sender_body [1083] drop copy 115.390425 main_thread [1446] 149790 pps (149900 pkts in 1000735 usec) 116.391480 main_thread [1446] 148815 pps (148972 pkts in 1001056 usec) 117.392243 main_thread [1446] 148798 pps (148912 pkts in 1000763 usec) 118.393766 main_thread [1446] 148462 pps (148688 pkts in 1001523 usec) 119.394256 main_thread [1446] 8252 pps (8256 pkts in 1000491 usec) Sent 604728 packets, 60 bytes each, in 4.06 seconds. Speed: 148.80 Kpps Bandwidth: 71.42 Mbps (raw 99.99 Mbps) ^C # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 112 ptr 0x0 00100 0 0 count ip from any to any 65535 0 0 allow ip from any to any i gues I am missing a piece of the architecture... On Tue, Nov 4, 2014 at 5:02 PM, Luigi Rizzo wrote: > =E2=80=8Bthe user space netmap-ipfw only supports two interfaces, > > The hard problem in moving to 3+ interfaces is not much the code but > deciding where to send a packet once it has passed the filter. > > Basically, passing things through the kernel stack is simple > but performance is going to be no better than with the standard firewall > (except for much better behaviour in blocking incoming attacks). > > cheers > luigi > > > On Tue, Nov 4, 2014 at 5:56 AM, Evandro Nunes > wrote: > >> hello, >> I am trying to do some basic stateless filtering with netmap-ipfw. >> >> what i have running is: >> >> ./kipfw em1 em2 lo0 >> >> and when i do ipfw/ipfw show: >> >> ipfw/ipfw show >> connected to 127.0.0.1:5555 >> nalloc 2248 nbytes 136 ptr 0x0 >> 00100 0 0 allow ip from any to any via lo0 >> 65535 0 0 allow ip from any to any >> >> it's not counting any packet, including loopback >> >> i have seem people using something similar but with ix(4) driver, what I >> am >> doing wrong? >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 19:26:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01836D9D for ; Tue, 4 Nov 2014 19:26:42 +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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CBA7CA for ; Tue, 4 Nov 2014 19:26:42 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id h11so10399064wiw.9 for ; Tue, 04 Nov 2014 11:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kmDo3INQz5Dv4FOZyiH9X3g0vZ33nBjXcHFhS1tj0Pk=; b=cUbrsjFgExqvBxihDE5ICuSr0iVpIidcIb5ULvK/Qwdlh883+hfEznQEBqvw5jzK0w e7/q0+rH7/0rGMd7Kt+BsDfyY3cH/bmCaBbuM+RMLOhgMdQMD32CGpFWlFPuZ2n4+u/R QUZocfhjM+y5DWttIkOTJZ/5u6EY1DfLQwJkHgguTToo6cwKpe2TDde+6Ko2PK06Npdm q8lLE9L7toR8+iOea97jP3URYtxI4O0wxR1Yb8Z6cmPF8cxvivO7LnIRM3QYYoqhkU08 FOQd4V0QZwYxZwBKzp89p+mv+Sx39RDHF8tZX4RV7E8tQDj+4nqSOCdpaBxNOihip89m 4b/g== MIME-Version: 1.0 X-Received: by 10.194.103.230 with SMTP id fz6mr58096096wjb.53.1415129200662; Tue, 04 Nov 2014 11:26:40 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Tue, 4 Nov 2014 11:26:40 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 11:26:40 -0800 X-Google-Sender-Auth: HJH-3facAtnMscpy8BFyOer2AV0 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:26:43 -0000 On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes wrote: > so, running em1 and em2 only should work? > > because I have the same behavior: > > # ps wauxw | grep kipfw > root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95 > ./kipfw em1 em2 > root 61518 0.0 0.0 18804 1864 2 S+ 5:07PM 0:00.00 > grep kipfw > > > # /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1 > -f tx -l 60 -d 172.16.250.10 > 112.372344 main [1649] interface is em1 > 112.372597 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 > 112.372622 extract_ip_range [287] range is 172.16.250.10:0 to > 172.16.250.10:0 > 112.388845 main [1840] mapped 334980KB at 0x801800000 > Sending on netmap:em1: 1 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 172.16.250.10 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) > 112.388956 main [1924] Sending 512 packets every 0.000000000 s > 112.388966 main [1926] Wait 2 secs for phy reset > 114.389236 main [1928] Ready... > 114.389473 nm_open [456] overriding ifname em1 ringid 0x0 flags 0x1 > 114.389765 sender_body [1014] start, fd 4 main_fd 3 > 115.055243 sender_body [1083] drop copy > 115.390425 main_thread [1446] 149790 pps (149900 pkts in 1000735 usec) > 116.391480 main_thread [1446] 148815 pps (148972 pkts in 1001056 usec) > 117.392243 main_thread [1446] 148798 pps (148912 pkts in 1000763 usec) > 118.393766 main_thread [1446] 148462 pps (148688 pkts in 1001523 usec) > 119.394256 main_thread [1446] 8252 pps (8256 pkts in 1000491 usec) > Sent 604728 packets, 60 bytes each, in 4.06 seconds. > Speed: 148.80 Kpps Bandwidth: 71.42 Mbps (raw 99.99 Mbps) > > ^C > > # ipfw/ipfw show > connected to 127.0.0.1:5555 > nalloc 2248 nbytes 112 ptr 0x0 > 00100 0 0 count ip from any to any > 65535 0 0 allow ip from any to any > > i gues I am missing a piece of the architecture... > =E2=80=8Bprobably yes :) kipfw em1 em2 connects the two interfaces to each other, keeping the rest =E2=80=8B =E2=80=8Bof the host stack completely out of the game. =E2=80=8BI am not sure where you are running pkt-gen (is it on a separate machine ?) and what the 'em1' used in =E2=80=8B =E2=80=8B =E2=80=8Bpkt-gen is connected to. Also (not in the above case but in general) you might need to put the interfaces used in kipfw in promisc mode so you receive all traffic. cheers =E2=80=8Bluigi=E2=80=8B > > On Tue, Nov 4, 2014 at 5:02 PM, Luigi Rizzo wrote: > >> =E2=80=8Bthe user space netmap-ipfw only supports two interfaces, >> >> The hard problem in moving to 3+ interfaces is not much the code but >> deciding where to send a packet once it has passed the filter. >> >> Basically, passing things through the kernel stack is simple >> but performance is going to be no better than with the standard firewall >> (except for much better behaviour in blocking incoming attacks). >> >> cheers >> luigi >> >> >> On Tue, Nov 4, 2014 at 5:56 AM, Evandro Nunes >> wrote: >> >>> hello, >>> I am trying to do some basic stateless filtering with netmap-ipfw. >>> >>> what i have running is: >>> >>> ./kipfw em1 em2 lo0 >>> >>> and when i do ipfw/ipfw show: >>> >>> ipfw/ipfw show >>> connected to 127.0.0.1:5555 >>> nalloc 2248 nbytes 136 ptr 0x0 >>> 00100 0 0 allow ip from any to any via lo0 >>> 65535 0 0 allow ip from any to any >>> >>> it's not counting any packet, including loopback >>> >>> i have seem people using something similar but with ix(4) driver, what = I >>> am >>> doing wrong? >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >> >> -- >> -----------------------------------------+------------------------------= - >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------= - >> > > --=20 -----------------------------------------+------------------------------- 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 Tue Nov 4 19:44:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 230F2264 for ; Tue, 4 Nov 2014 19:44:46 +0000 (UTC) Received: from mail-wi0-x241.google.com (mail-wi0-x241.google.com [IPv6:2a00:1450:400c:c05::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E193341 for ; Tue, 4 Nov 2014 19:44:45 +0000 (UTC) Received: by mail-wi0-f193.google.com with SMTP id r20so22705wiv.0 for ; Tue, 04 Nov 2014 11:44:44 -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=Hu25JKX/ZPFMFzYTEt3tooK8B0p8fplMRH1zqFbJ4fs=; b=XhTbyeusLjv0m4JoTedSbbjQ5zWKJ96v6X2eKn5fnXLSSl+NzLKLtkhiMOygNAWW36 Wt08ff9Bw1tOMR4GnOWgSAjdo8FIAUfb+oEoX8VYj9eOtPkOfXINrgJ3dsg7Qe7rlmPU KCSIJszJPYaudXVRfibtyYVUj5V7VmqO+7dwvvSVrk85OEk26IUo0OVsaa5/Pz1DVYxE oqQrwVaEv6r+XzhJYxTmqJXrlnpvb+pG3T9macHCsYO0lcS9IHMkrLgM+QwEf5N29OCc 2aZi6slGFxot7SZ/JCMeuNfa1iXoDNStEGaA8bnDZPg5tGgw7KDcrb1VOoTdRlHchAVh 16dA== MIME-Version: 1.0 X-Received: by 10.194.248.162 with SMTP id yn2mr5546678wjc.16.1415130283953; Tue, 04 Nov 2014 11:44:43 -0800 (PST) Received: by 10.217.92.7 with HTTP; Tue, 4 Nov 2014 11:44:43 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 17:44:43 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:44:46 -0000 On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote: > > > On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes > wrote: > >> so, running em1 and em2 only should work? >> >> because I have the same behavior: >> >> # ps wauxw | grep kipfw >> root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.9= 5 >> ./kipfw em1 em2 >> root 61518 0.0 0.0 18804 1864 2 S+ 5:07PM 0:00.0= 0 >> grep kipfw >> >> >> # /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em= 1 >> -f tx -l 60 -d 172.16.250.10 >> 112.372344 main [1649] interface is em1 >> 112.372597 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 >> 112.372622 extract_ip_range [287] range is 172.16.250.10:0 to >> 172.16.250.10:0 >> 112.388845 main [1840] mapped 334980KB at 0x801800000 >> Sending on netmap:em1: 1 queues, 1 threads and 1 cpus. >> 10.0.0.1 -> 172.16.250.10 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) >> 112.388956 main [1924] Sending 512 packets every 0.000000000 s >> 112.388966 main [1926] Wait 2 secs for phy reset >> 114.389236 main [1928] Ready... >> 114.389473 nm_open [456] overriding ifname em1 ringid 0x0 flags 0x1 >> 114.389765 sender_body [1014] start, fd 4 main_fd 3 >> 115.055243 sender_body [1083] drop copy >> 115.390425 main_thread [1446] 149790 pps (149900 pkts in 1000735 usec) >> 116.391480 main_thread [1446] 148815 pps (148972 pkts in 1001056 usec) >> 117.392243 main_thread [1446] 148798 pps (148912 pkts in 1000763 usec) >> 118.393766 main_thread [1446] 148462 pps (148688 pkts in 1001523 usec) >> 119.394256 main_thread [1446] 8252 pps (8256 pkts in 1000491 usec) >> Sent 604728 packets, 60 bytes each, in 4.06 seconds. >> Speed: 148.80 Kpps Bandwidth: 71.42 Mbps (raw 99.99 Mbps) >> >> ^C >> >> # ipfw/ipfw show >> connected to 127.0.0.1:5555 >> nalloc 2248 nbytes 112 ptr 0x0 >> 00100 0 0 count ip from any to any >> 65535 0 0 allow ip from any to any >> >> i gues I am missing a piece of the architecture... >> > > =E2=80=8Bprobably yes :) > > kipfw em1 em2 connects the two interfaces to each other, keeping the > rest =E2=80=8B > > =E2=80=8Bof the host stack completely out of the game. > got it however it's still not counting any packets coming in or out of the interfaces > =E2=80=8BI am not sure where you are running pkt-gen (is it on a separate > machine ?) and what the 'em1' used in =E2=80=8B > =E2=80=8B > =E2=80=8Bpkt-gen is connected to. > I am running one pkt-gen in TX mode on the same machine, and another one in RX mode in a separate machine, but this is just for reference, to make sure packets are actually getting transmitted, and it is... > Also (not in the above case but in general) you might need to > put the interfaces used in kipfw in promisc mode so you receive > all traffic. > good to mention that I just did it, however, the scenario stills the same those are my steps: # ifconfig "em1" | grep flags em1: flags=3D28943 metric 0 mtu 1500 # ifconfig "em2" | grep flags em2: flags=3D28d02 metric 0 mtu 1500 Both are promisc # killall -9 kipfw [1] + Killed ./kipfw em1 em2 >& /tmp/kipfw.log # ./kipfw em1 em2 > & /tmp/kipfw.log & [1] 64218 kipfw running again # ipfw/ipfw add count all from any to any connected to 127.0.0.1:5555 00100 count ip from any to any we have a second rule now # /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1 -f tx -l 60 -d 172.16.250.10 977.772859 main [1649] interface is em1 977.773117 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 977.773141 extract_ip_range [287] range is 172.16.250.10:0 to 172.16.250.10:0 977.789890 main [1840] mapped 334980KB at 0x801800000 Sending on netmap:em1: 1 queues, 1 threads and 1 cpus. 10.0.0.1 -> 172.16.250.10 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) 977.790009 main [1924] Sending 512 packets every 0.000000000 s 977.790018 main [1926] Wait 2 secs for phy reset 979.790699 main [1928] Ready... 979.790932 nm_open [456] overriding ifname em1 ringid 0x0 flags 0x1 979.791216 sender_body [1014] start, fd 4 main_fd 3 980.456540 sender_body [1083] drop copy 980.791786 main_thread [1446] 149840 pps (149935 pkts in 1000634 usec) 981.793169 main_thread [1446] 148767 pps (148973 pkts in 1001383 usec) 982.793710 main_thread [1446] 148815 pps (148896 pkts in 1000541 usec) 983.794835 main_thread [1446] 148841 pps (149008 pkts in 1001125 usec) 984.796039 main_thread [1446] 148830 pps (149008 pkts in 1001194 usec) 985.796801 main_thread [1446] 148785 pps (148900 pkts in 1000772 usec) ^C986.798156 main_thread [1446] 134857 pps (135040 pkts in 1001355 usec) Sent 1029760 packets, 60 bytes each, in 6.92 seconds. Speed: 148.81 Kpps Bandwidth: 71.43 Mbps (raw 100.00 Mbps) Some packets transmitted to another machine o IP 172.16.250.10 # ping 172.16.250.10 PING 172.16.250.10 (172.16.250.10): 56 data bytes 64 bytes from 172.16.250.3: icmp_seq=3D0 ttl=3D64 time=3D0.296 ms 64 bytes from 172.16.250.3: icmp_seq=3D1 ttl=3D64 time=3D0.141 ms 64 bytes from 172.16.250.3: icmp_seq=3D2 ttl=3D64 time=3D0.144 ms 64 bytes from 172.16.250.3: icmp_seq=3D3 ttl=3D64 time=3D0.176 ms 64 bytes from 172.16.250.3: icmp_seq=3D4 ttl=3D64 time=3D0.109 ms ^C --- 172.16.250.10 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 0.109/0.173/0.296/0.065 ms Remote machine also available outside netmap # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 112 ptr 0x0 00100 0 0 count ip from any to any 65535 0 0 allow ip from any to any still, no packets counted... neither from host stack (ping) nor netmap (pkt-gen)... > > cheers > =E2=80=8Bluigi=E2=80=8B > > >> >> On Tue, Nov 4, 2014 at 5:02 PM, Luigi Rizzo wrote: >> >>> =E2=80=8Bthe user space netmap-ipfw only supports two interfaces, >>> >>> The hard problem in moving to 3+ interfaces is not much the code but >>> deciding where to send a packet once it has passed the filter. >>> >>> Basically, passing things through the kernel stack is simple >>> but performance is going to be no better than with the standard firewal= l >>> (except for much better behaviour in blocking incoming attacks). >>> >>> cheers >>> luigi >>> >>> >>> On Tue, Nov 4, 2014 at 5:56 AM, Evandro Nunes >>> wrote: >>> >>>> hello, >>>> I am trying to do some basic stateless filtering with netmap-ipfw. >>>> >>>> what i have running is: >>>> >>>> ./kipfw em1 em2 lo0 >>>> >>>> and when i do ipfw/ipfw show: >>>> >>>> ipfw/ipfw show >>>> connected to 127.0.0.1:5555 >>>> nalloc 2248 nbytes 136 ptr 0x0 >>>> 00100 0 0 allow ip from any to any via lo0 >>>> 65535 0 0 allow ip from any to any >>>> >>>> it's not counting any packet, including loopback >>>> >>>> i have seem people using something similar but with ix(4) driver, what >>>> I am >>>> doing wrong? >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> >>> >>> >>> -- >>> -----------------------------------------+-----------------------------= -- >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazion= e >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>> TEL +39-050-2211611 . via Diotisalvi 2 >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> -----------------------------------------+-----------------------------= -- >>> >> >> > > > -- > -----------------------------------------+------------------------------- > 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 Tue Nov 4 19:52:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03613702 for ; Tue, 4 Nov 2014 19:52:45 +0000 (UTC) Received: from smtp.sitkom.cz (smtp.sitkom.cz [IPv6:2a03:3a00:1:2::4:b]) by mx1.freebsd.org (Postfix) with ESMTP id B0CFD622 for ; Tue, 4 Nov 2014 19:52:44 +0000 (UTC) Received: from spamd.smtp.sitkom.cz (unknown [10.13.127.4]) by smtp.sitkom.cz (Postfix) with ESMTP id 06E8A2FB8 for ; Tue, 4 Nov 2014 20:52:41 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on smtp.sfn X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from avscan.smtp.sitkom.cz (unknown [10.13.127.4]) by spamd.smtp.sitkom.cz (Postfix) with ESMTP id D5BC52FB3 for ; Tue, 4 Nov 2014 20:52:40 +0100 (CET) Received: from [IPv6:2a03:3a00:2:a00:1a9:6f7:f0e7:dc2] (unknown [IPv6:2a03:3a00:2:a00:1a9:6f7:f0e7:dc2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.sitkom.cz (Postfix) with ESMTPSA id B4E4B2FB2 for ; Tue, 4 Nov 2014 20:52:40 +0100 (CET) Message-ID: <54592E86.2040703@borsice.net> Date: Tue, 04 Nov 2014 20:52:38 +0100 From: =?UTF-8?B?TWljaGFsIEJ1Y2h0w61r?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: netmap-ipfw on em0 em1 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on smtp.sitkom.cz X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:52:45 -0000 Dne 4.11.2014 20:44, Evandro Nunes napsal(a): > # ifconfig "em2" | grep flags > em2: flags=28d02 > metric 0 mtu 1500 Hi, interface is OACTIVE and down. Do you try "ifconfig em2 up" ? Michal From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 20:09:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D4EDD65 for ; Tue, 4 Nov 2014 20:09:46 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9785D7DC for ; Tue, 4 Nov 2014 20:09:45 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so13778227wgh.11 for ; Tue, 04 Nov 2014 12:09:43 -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=pG5LAuTiv0px0Dzw0GNSR5q7/KrfT2T/BzYjfkhRdrI=; b=N5IATj6VxU+wnjMxB5t9c14NLckcqMTWLgZWfMgmPuBaYiiY5Ds09Wx6oBr2juWTPd u1Lo5ptQ3F7l6Ma07BL/ySqqfgvQaheFbzTbT6vmStSqF9phC0vA+PZxXVsHIabQYf6A Z1/V5NJ33dTAIi/ps+Kg8ctKgJ1J6KJnKKgYXBbXd4EWTXhecSfrNOECVaBgitQQxrhG AdnL/tMiX9GsyRZP8GQDQh8IKEC1Uk0PRq1/lhaGwqCXl89sQOtCwRlloPCzRdmOZ7lu ty277XQDPwDR3RhKaLcN0Xeod95Wmv7ET2y+4/UpVbu2I3DeWOEaTjG1IFeODbsCew1o EICw== MIME-Version: 1.0 X-Received: by 10.180.86.38 with SMTP id m6mr128253wiz.65.1415131783842; Tue, 04 Nov 2014 12:09:43 -0800 (PST) Received: by 10.217.92.7 with HTTP; Tue, 4 Nov 2014 12:09:43 -0800 (PST) In-Reply-To: <54592E86.2040703@borsice.net> References: <54592E86.2040703@borsice.net> Date: Tue, 4 Nov 2014 18:09:43 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: =?UTF-8?Q?Michal_Bucht=C3=ADk?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 20:09:46 -0000 On Tue, Nov 4, 2014 at 5:52 PM, Michal Bucht=C3=ADk = wrote: > Dne 4.11.2014 20:44, Evandro Nunes napsal(a): > >> # ifconfig "em2" | grep flags >> em2: flags=3D28d02 >> metric 0 mtu 1500 >> > Hi, > interface is OACTIVE and down. > > Do you try "ifconfig em2 up" ? > hey Michal, strange, both NICs are addressed (active IP configured), no I didnt ifconfig up before you mention on none of both since usually the go up when IP is assigned, but anyway I just did it now, both are UP and PROMISC now: ifconfig em2 | grep flags em2: flags=3D28943 metric 0 mtu 1500 ifconfig em1 | grep flags em1: flags=3D28943 metric 0 mtu 1500 but still netmap-ipfw is not incrementing counters... > Michal > > _______________________________________________ > 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 Tue Nov 4 21:09:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14EA11A6 for ; Tue, 4 Nov 2014 21:09:47 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C17BCE37 for ; Tue, 4 Nov 2014 21:09:46 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XllMH-0002qg-Uv for freebsd-net@freebsd.org; Tue, 04 Nov 2014 22:09:45 +0100 Date: Tue, 4 Nov 2014 22:09:45 +0100 From: Kurt Jaeger To: freebsd-net@freebsd.org Subject: GPON SFP, any technical ideas ? Message-ID: <20141104210945.GQ66862@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:09:47 -0000 Hi! I got my hands on an GPON G.984.2 ClassB SFP and want to find a way to operate it using FreeBSD. What type of NIC with SFP slots can be recommended for this exotic use case ? It's data sheet: http://www.allnet.de/fileadmin/transfer/products/113608.pdf It's asymmetric with these specs: 1490nm continuos mode 2.5 Gbit/s DFB transmitter 1310nm burst mode 1.25 Gb/s APD receiver Any hints welcome! -- pi@opsec.eu +49 171 3101372 6 years to go ! From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 22:17:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43ACD58C for ; Tue, 4 Nov 2014 22:17:10 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 024F18A7 for ; Tue, 4 Nov 2014 22:17:09 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A0B917300A; Tue, 4 Nov 2014 23:12:16 +0100 (CET) Date: Tue, 4 Nov 2014 23:12:16 +0100 From: Luigi Rizzo To: Evandro Nunes Subject: Re: netmap-ipfw on em0 em1 Message-ID: <20141104221216.GA17502@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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 22:17:10 -0000 On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote: > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote: ... > >> i gues I am missing a piece of the architecture... > >> > > > > ???probably yes :) > > > > kipfw em1 em2 connects the two interfaces to each other, keeping the > > rest ??? > > > > ???of the host stack completely out of the game. > > > > got it uhmmm... probably not, see below: > however it's still not counting any packets coming in or out of the > interfaces > > > > ???I am not sure where you are running pkt-gen (is it on a separate > > machine ?) and what the 'em1' used in ??? > > ??? > > ???pkt-gen is connected to. > > > > > I am running one pkt-gen in TX mode on the same machine, and another one in > RX mode in a separate machine, but this is just for reference, to make sure > packets are actually getting transmitted, and it is... you cannot run two netmap clients on the same NIC at the same time (unless you know how to do that, and avoid they stomp on each other). In this particular case it means that you should test things as follows machine A: pkt-gen -i em1 -f tx ... machine B kipfw em1 em2 machine C pkt-gen -i em3 -f rx And the connection between the ports is the following [A em1] <--> [em1 B em2] <--> [em3 C] cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 10:43: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA949F7B for ; Wed, 5 Nov 2014 10:43:51 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1537388 for ; Wed, 5 Nov 2014 10:43:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA5AhpPk099459 for ; Wed, 5 Nov 2014 10:43:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 Date: Wed, 05 Nov 2014 10:43:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: praveenchoudary.gokina@emulex.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:43:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 --- Comment #2 from Praveen --- Thanks. Your suggestion has worked. In Linux, we don't need to configure route if we change mtu. Is it a bug in Freebsd ? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 10:45:12 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 248ECA6 for ; Wed, 5 Nov 2014 10:45:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C22E399 for ; Wed, 5 Nov 2014 10:45:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA5AjBwF000147 for ; Wed, 5 Nov 2014 10:45:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 Date: Wed, 05 Nov 2014 10:45:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 10:45:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 --- Comment #3 from Alexander V. Chernikov --- I'd rather say that it is a historical "feature". I'm going to change this behavior to be more user-friendly soon. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 14:28:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE89BD02; Wed, 5 Nov 2014 14:28:09 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B16BD192; Wed, 5 Nov 2014 14:28:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com A90747590E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415197687; bh=RzIFDK8SsGi9K3Kql9teE7ZNePrbrAznqHdDgii/3g8=; h=Date:From:To:Subject; b=ao/D/ci1OQLXr2KNusLWgARKauIR1aFw+OWpJWAUKN4rW25r2uV+BO1bHWIwS0unL Y71YAimOq3FKq+vHv7CWHK7x7ciKf8kcOfgRXbeLeHyhOMVUB74SF1IrsQyCa3cBfD sHfr2cLAM2rRVnBon0FCJjh3Py2illjdXoLvNrl4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Nov 2014 15:28:07 +0100 From: Ilya Bakulin To: freebsd-pf@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D?= =?UTF-8?Q?=5Foutput?= Organization: Deglitch Networks Message-ID: X-Sender: ilya@bakulin.de X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 14:28:10 -0000 Hi all, I have been hit by this 2-year-old bug with PF and 'scrub reassemble tcp' on IPv6 connections: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172648 I have been able to trace it down to the modifications of timestamp values by timestamp modulation code [1]. If I remove those two pf_change_a() calls in the output path (pd->dir == PF_OUT) then everything works as it should, except that the timestamps are not modulated which is kinda sucks. Of course it was interesting what does the upstream PF do (@ OpenBSD). Seems they have made the decision to leave the task of recalculating the checksums for outgoing packets to ip[6]_output, because currently the code there overwrites the checksum anyway. This seems a correct way to me. pf should not longer do any checksum updates in inbound and outbound path. For inbound path, it should however check the checksum correctness and set a flag in mbuf csum flags so the tcp[6]_input doesn't try to verify it. In this case even if we modify something while applying TS modulation or sequence number modulation or something else in PF the upper-layer won't bailout because it will see that the checksum was already verified and won't try to verify it once again. OpenBSD does it this way and they seem to be happy. For now, I decided to leave the inbound path as-is and instead wanted to fix the outbound path. The patch [2] solves the problem described in [2] in the following way: 1) Hijack the last argument of pf_change_a() so that it doesn't update the checksum of the packet; 2) When updating the timestamps in pf_normalize_tcp_stateful() call pf_change_a() in "no-update-checksum" mode; 3) In pf_check_out() remove the checks for CSUM_DELAY_DATA -- don't calculate the checksum in any case. Such fix should be done in pf_check6_out() as well, but in my test setup I haven't seen that flag anyway. In future we probably should implement pf_change_a changes the same or similar way OpenBSD does it. [1] https://github.com/freebsd/freebsd/blob/49c137f7be5791eee8102395257cdf48b40c81f7/sys/netpfil/pf/pf_norm.c#L1569 [2] http://dl.bakulin.de/freebsd/pf_fix_reass_tcp_ipv6.diff From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 15:39:09 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCBCDA8E for ; Wed, 5 Nov 2014 15:39:09 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 979A2C83 for ; Wed, 5 Nov 2014 15:39:08 +0000 (UTC) Received: from 50-206-19-250-static.hfc.comcastbusiness.net ([50.206.19.250]:55942 helo=[192.168.100.253]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Xm2fr-00014J-Ia for net@freebsd.org; Wed, 05 Nov 2014 10:39:07 -0500 From: "George Neville-Neil" To: net@freebsd.org Subject: netmap in GENERIC, by default, on HEAD Date: Wed, 05 Nov 2014 07:39:06 -0800 Message-ID: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4576) 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 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:39:09 -0000 Howdy, Last night (Pacific Time) I committed a change so that GENERIC, on HEAD has the netmap device enabled. This is to increase the breadth of our testing of that feature prior to the release of FreeBSD 11. In two weeks I will enable IPSec by default, again in preparation for 11. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 15:52:19 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6934CD68; Wed, 5 Nov 2014 15:52:19 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21A17E53; Wed, 5 Nov 2014 15:52:19 +0000 (UTC) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [77.88.61.132]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 4EBE7BC1260; Wed, 5 Nov 2014 18:52:16 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id C06CB6740158; Wed, 5 Nov 2014 18:52:15 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::1e7]) by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id qAVJk08r1g-qD24hm62; Wed, 5 Nov 2014 18:52:15 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 3247e923-0854-482b-8366-7bb58d04efcb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415202735; bh=ILiuQShVak/I8fHAFttliXResUFWNs4u+98she8ow34=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jfguAZseuQr5G7WNZOXbjo1KlXClU23sdV1qaeZIdV+qKyoXFRyAMVB1WO56mG5ad 4sxMpwGLSTjeRQNe+PCQrvoArcdbi3xyW8Rxl9+BF4FDjZ9zGfjAjjkI+4duPSLPZv qZRZM1BW48yWLFl3PNfuBO9DK914qZhxAn3hemdc= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <545A47A5.4010601@yandex.ru> Date: Wed, 05 Nov 2014 18:52:05 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: George Neville-Neil , net@freebsd.org Subject: Re: netmap in GENERIC, by default, on HEAD References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> In-Reply-To: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:52:19 -0000 On 05.11.2014 18:39, George Neville-Neil wrote: > Howdy, > > Last night (Pacific Time) I committed a change so that GENERIC, on HEAD > has the netmap > device enabled. This is to increase the breadth of our testing of that > feature prior > to the release of FreeBSD 11. > > In two weeks I will enable IPSec by default, again in preparation for 11. Hi, recently we did some IP forwarding tests and the GENERIC kernel is several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. I didn't do test on vanilla kernel, but our kernel is able forward IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPSEC can forward only 180 kpps. I think this problem should be solved before enabling it in GENERIC. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 16:06:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0EDDA6 for ; Wed, 5 Nov 2014 16:06:59 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6688FBF for ; Wed, 5 Nov 2014 16:06:59 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id ey11so1042317pad.21 for ; Wed, 05 Nov 2014 08:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6zyvrOaf+D/oYLOhhxoSQ/c+SdqNVPO/7gdU2TM8dXk=; b=m4F1s7en1ypMEoAbegL3ORpRE2TAMbPaGTbvTiWnHOfuS0qXBtEYkfUGjP5qQKJgnE ahgB/mGGAhskfBBszoGMjB3Fhv6og690AGXHsmWa33jmKdQNbSF3R+0aoCtAqG6AEATQ EN1GgE5g/5rKPSKQYZOCXxnXpZswgjdNmaCBjmswN5ntQd751iY6AQt6IOl9dDRRUsSO ToM/caxTnfgvQtiG9YVgwYzTzAlkhcm6qeVEa9saD05oZp0ctVZ4duGgQZpxxZqcvILn ktljkejOduLBQMW7sXlDmOTZisB6jp80zDwFugClvMADATFcw9zI9NQx999yvhtnQgPP bnuQ== X-Received: by 10.69.20.74 with SMTP id ha10mr18310203pbd.122.1415203619383; Wed, 05 Nov 2014 08:06:59 -0800 (PST) Received: from ketagalan.camachat.org ([2601:9:4700:360:a288:b4ff:fec2:e5d0]) by mx.google.com with ESMTPSA id ty8sm3607568pab.26.2014.11.05.08.06.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 08:06:59 -0800 (PST) Message-ID: <545A4B22.6080001@gmail.com> Date: Wed, 05 Nov 2014 08:06:58 -0800 From: "Eric L. Camachat" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: netmap in GENERIC, by default, on HEAD References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> In-Reply-To: <545A47A5.4010601@yandex.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:07:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/05/2014 07:52, Andrey V. Elsukov wrote: > On 05.11.2014 18:39, George Neville-Neil wrote: >> Howdy, >> >> Last night (Pacific Time) I committed a change so that GENERIC, on HEAD >> has the netmap >> device enabled. This is to increase the breadth of our testing of that >> feature prior >> to the release of FreeBSD 11. >> >> In two weeks I will enable IPSec by default, again in preparation for 11. > > Hi, > > recently we did some IP forwarding tests and the GENERIC kernel is > several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. > > I didn't do test on vanilla kernel, but our kernel is able forward > IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPSEC > can forward only 180 kpps. I think this problem should be solved before > enabling it in GENERIC. > I think this is why we need IPSEC in GENERIC to let more tests involved. Maybe it also helps in kernel SSL encryption (key per IP vs per TCP session). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlRaSyIACgkQSfBQu3oOwYwdfQEAvlvDjlH489YP7n7PYKkLbOfX 5Ew7+VdiJAC7BBkxnSwA/2y2V2sakpdPzlxEt5O4oQbKEmBUa40W7CU3gBzgJjTw =EHh4 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 16:14:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44D0E444 for ; Wed, 5 Nov 2014 16:14:22 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC9F4147 for ; Wed, 5 Nov 2014 16:14:21 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so1288179wgh.6 for ; Wed, 05 Nov 2014 08:14:20 -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=xkz3AA8+U4GsM3K4UqtBuOM4mQroKJXJeatVa6zLBRk=; b=ThCZ6yRZBggUXtaARekqHaJbyvcAwjkRCqGZgWBqQ9znDNGWMFBIthXo7gHKT14mtR Jntena8rBM4E8u7brl5rRUIZ7L6aeAA+p5i5MGUidT657NbVYQcA9dS3x2//h4sFbVSd j/Y5L8Yv05jPfk9dGpq2fABRPbGs+6lt3ttFNhpm4EiGoA18vQ9hN/StfhwB0k1RB2kE ts5smH3N/43Pk5ZKRXmC/C6PLesSpItcDN0VHGN6BliGlckOeFx6v5JR5HTPpkclThs9 SgJQojGiWPmoMZ/o6QDS5jNapY5koGGKnNdTlFeqNQogY7je5+B2645V5mweEIDKMA10 PmZA== MIME-Version: 1.0 X-Received: by 10.194.206.36 with SMTP id ll4mr66590122wjc.21.1415204060057; Wed, 05 Nov 2014 08:14:20 -0800 (PST) Received: by 10.217.92.7 with HTTP; Wed, 5 Nov 2014 08:14:19 -0800 (PST) In-Reply-To: <20141104221216.GA17502@onelab2.iet.unipi.it> References: <20141104221216.GA17502@onelab2.iet.unipi.it> Date: Wed, 5 Nov 2014 14:14:19 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:14:22 -0000 On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote: > On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote: > > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote: > ... > > >> i gues I am missing a piece of the architecture... > > >> > > > > > > ???probably yes :) > > > > > > kipfw em1 em2 connects the two interfaces to each other, keeping the > > > rest ??? > > > > > > ???of the host stack completely out of the game. > > > > > > > got it > > uhmmm... probably not, see below: > > > however it's still not counting any packets coming in or out of the > > interfaces > > > > > > > ???I am not sure where you are running pkt-gen (is it on a separate > > > machine ?) and what the 'em1' used in ??? > > > ??? > > > ???pkt-gen is connected to. > > > > > > > > > I am running one pkt-gen in TX mode on the same machine, and another one > in > > RX mode in a separate machine, but this is just for reference, to make > sure > > packets are actually getting transmitted, and it is... > > you cannot run two netmap clients on the same NIC at the same time > (unless you know how to do that, and avoid they stomp on each other). > > In this particular case it means that you should test things as follows > > machine A: pkt-gen -i em1 -f tx ... > > machine B kipfw em1 em2 > > machine C pkt-gen -i em3 -f rx > > And the connection between the ports is the following > > [A em1] <--> [em1 B em2] <--> [em3 C] > > cheers > luigi > ok this scenario will take a bit more time to create, Ill do it today so there is no way to filter a traffic generated by the same box, at least not right now, correct? one more thing, in this scenario you draw, should netmap-ipfw also filter host traffic? I mean, machine A pinging machine C instead of generating netmap-away traffic should be just like the same, right? thank you very much again From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 16:18:43 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5C85571; Wed, 5 Nov 2014 16:18:42 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B55718D; Wed, 5 Nov 2014 16:18:42 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bs8so521947wib.17 for ; Wed, 05 Nov 2014 08:18:40 -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=hl7IEeaYEO964evqEf5K/KePZ9zeoMfgmKx45Svz4cE=; b=WST033KuJ/fowlvxJhFxQ2b81ucayJkB1XEBx8PMk9lL436JTlK39YgRRgjPcF0ryU 7A1jMcrjHTG359AKn5w/z2/gX26ZFhu71rX4bw9nUfhHMiqXwLkiBN0QsmwQSrS2RUtx nvNf4Ytv5xVdwXGxyRSC4UvF2qt5RXNjDHQdFcgTFi0bxD/7fsZhz3OR4PoGjBChWIZK ETGe9mulc0iwEgTNwCEQQPWXLe4jFtRjqMTVmj3EV8yoQBg4Ga9pc2Gpzb2jgrkXJEtu Lauwb8MT0y3O1rwn28bDqLE3h39TtuVHjVggpCA2+2lvWTZrNwwaCq8Lb2DJta21k8BD rnLg== MIME-Version: 1.0 X-Received: by 10.180.14.231 with SMTP id s7mr33939185wic.0.1415204320562; Wed, 05 Nov 2014 08:18:40 -0800 (PST) Received: by 10.217.92.7 with HTTP; Wed, 5 Nov 2014 08:18:40 -0800 (PST) In-Reply-To: <545A47A5.4010601@yandex.ru> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> Date: Wed, 5 Nov 2014 14:18:40 -0200 Message-ID: Subject: Re: netmap in GENERIC, by default, on HEAD From: Evandro Nunes To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:18:43 -0000 On Wed, Nov 5, 2014 at 1:52 PM, Andrey V. Elsukov wrote: > On 05.11.2014 18:39, George Neville-Neil wrote: > > Howdy, > > > > Last night (Pacific Time) I committed a change so that GENERIC, on HEAD > > has the netmap > > device enabled. This is to increase the breadth of our testing of that > > feature prior > > to the release of FreeBSD 11. > > > > In two weeks I will enable IPSec by default, again in preparation for 11. > > Hi, > > recently we did some IP forwarding tests and the GENERIC kernel is > several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. > > I didn't do test on vanilla kernel, but our kernel is able forward > IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPSEC > can forward only 180 kpps. I think this problem should be solved before > enabling it in GENERIC. > this forward rate you mention is related to netmap? or usual forwarding/fastforwarding? this is a huge number, do you mind sharing your dmesg output and top -PSH output so I can check for interrupt CPU usage and other relevant stuff? thank you From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 16:19:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF51616 for ; Wed, 5 Nov 2014 16:19:35 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [84.201.143.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 902D619F for ; Wed, 5 Nov 2014 16:19:35 +0000 (UTC) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [77.88.61.132]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 995A314E17D2; Wed, 5 Nov 2014 19:19:25 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id 30E3F6740306; Wed, 5 Nov 2014 19:19:25 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::1e7]) by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RSXal0i6z8-JO2GPatu; Wed, 5 Nov 2014 19:19:24 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 28b3a187-a3df-4612-b247-8caedf046209 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415204364; bh=nLWYFnbaifC/+0xS0yfuld/fc2Y04xo5ZFihtLrnBc0=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=u+yLUZH9ZxdgmIwHK3RhoKbzrZn7n633JLJnSqWh/tc3iwdCAsRUn9NLwUg61Kwe0 Kv/5AWVuQzB3VAuWfTR72/efKkx4LQGg13m+zpMY1ZnUGExWDmuvafUVM8tL/zchgb O2yWgQbh48CAMocqZ8kLC2UpuAYIjeyLaq4QQFs4= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <545A4E01.6010404@yandex.ru> Date: Wed, 05 Nov 2014 19:19:13 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Eric L. Camachat" , freebsd-net@freebsd.org Subject: Re: netmap in GENERIC, by default, on HEAD References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> <545A4B22.6080001@gmail.com> In-Reply-To: <545A4B22.6080001@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="swOQumfd8nv04GXjc9Va1STEDB6HeShhK" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:19:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --swOQumfd8nv04GXjc9Va1STEDB6HeShhK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.11.2014 19:06, Eric L. Camachat wrote: >>> In two weeks I will enable IPSec by default, again in preparation for= 11. >=20 >> Hi, >=20 >> recently we did some IP forwarding tests and the GENERIC kernel is >> several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. >=20 >> I didn't do test on vanilla kernel, but our kernel is able forward >> IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPS= EC >> can forward only 180 kpps. I think this problem should be solved befor= e >> enabling it in GENERIC. >=20 > I think this is why we need IPSEC in GENERIC to let more tests involved= =2E > Maybe it also helps in kernel SSL encryption (key per IP vs per TCP > session). IPSEC had unresolved bugs for years, and now all will be magically fixed. I think we need some way to enable/disable it on the fly. This may be a compromise. --=20 WBR, Andrey V. Elsukov --swOQumfd8nv04GXjc9Va1STEDB6HeShhK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUWk4FAAoJEAHF6gQQyKF6mwUH/jgB+BZKnlA4RucJbYa4TD0+ YmUeLRr9Y6ZYsxuyrxCry1QJ6QZ2pFtQ9sgRryyLEGYTVhipMfHqwXI0Fu1AnIws 1nRNxH6tdianCxRjWGvR+uEEl9jn6sMO4+86KVDJ8HjAzJXs/U7l8VGbsaa5W7xH dgfZ9s6u3032DNG18+HrR20Kp6Ua9RvDeqKmmSAtzZoJ6N/4Aj+jO7jagRwpH/UZ BfPFIspWpfHIHkVvl+wS+5V04uzRGu5RwxGHSfvgqAHCFImX9fHZdYvqKAtXrAA/ tyadxTv5kUqJXb2zArNHUFrh1Wm21RYdtW/kL06fXkoMMhsrBPQXZlSw/OhYmSc= =n9sw -----END PGP SIGNATURE----- --swOQumfd8nv04GXjc9Va1STEDB6HeShhK-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 17:00: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73D1FBAB; Wed, 5 Nov 2014 17:00:41 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [IPv6:2a02:6b8:0:1819::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 212E399E; Wed, 5 Nov 2014 17:00:41 +0000 (UTC) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [77.88.61.132]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 2F0E21501645; Wed, 5 Nov 2014 20:00:38 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id A9F656740306; Wed, 5 Nov 2014 20:00:37 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::1e7]) by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id SQvRlQ1ZHO-0a20fHer; Wed, 5 Nov 2014 20:00:37 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 8b612584-8b76-4c57-9b87-04c130b37ce8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415206837; bh=eNsTn7X39voPdRPt8tIFB2rqi5zCC968XVk0/FwTSrE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=SCcP54Su5jjhoeTsMUHSlpWpK2B8+mid8bNdQlYtf1hTPXt5lWtulmlP3RRz/IENG S5cjT5IN03w2bwAlwK9+qRdfIBb19I/uctbiNZ8CKE9HCpE6aTzWvRrsghM26/8X5i TR9q9NgVBxCCcP2lsHBL6gG/T2Ff99eNVd40+hlU= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <545A57A8.2010904@yandex.ru> Date: Wed, 05 Nov 2014 20:00:24 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Evandro Nunes Subject: Re: netmap in GENERIC, by default, on HEAD References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w6HrlTCB1wwmluQU9FwTkbOBVFpAuU9P2" Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:00:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w6HrlTCB1wwmluQU9FwTkbOBVFpAuU9P2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.11.2014 19:18, Evandro Nunes wrote: > On Wed, Nov 5, 2014 at 1:52 PM, Andrey V. Elsukov w= rote: >=20 >> On 05.11.2014 18:39, George Neville-Neil wrote: >>> Howdy, >>> >>> Last night (Pacific Time) I committed a change so that GENERIC, on HE= AD >>> has the netmap >>> device enabled. This is to increase the breadth of our testing of th= at >>> feature prior >>> to the release of FreeBSD 11. >>> >>> In two weeks I will enable IPSec by default, again in preparation for= 11. >> >> Hi, >> >> recently we did some IP forwarding tests and the GENERIC kernel is >> several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. >> >> I didn't do test on vanilla kernel, but our kernel is able forward >> IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPS= EC >> can forward only 180 kpps. I think this problem should be solved befor= e >> enabling it in GENERIC. >> >=20 > this forward rate you mention is related to netmap? or usual > forwarding/fastforwarding? this is a huge number, do you mind sharing y= our > dmesg output and top -PSH output so I can check for interrupt CPU usage= and > other relevant stuff? This is patched kernel without netmap and fastforwarding. We removed all lock contention on the forwarding path to be sure that it doesn't affect IPSEC. Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (2200.05-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 SMT threads real memory =3D 68736253952 (65552 MB) avail memory =3D 66370662400 (63295 MB) ix0: port 0x7020-0x703f mem 0xde680000-0xde6fffff,0xde704000-0xde707fff irq 32 at device 0.0 on pci4 ix0: Using MSIX interrupts with 16 vectors ix0: Ethernet address: 90:e2:ba:0d:73:54 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 This is IPv6 forwarding test - 6 /64 prefixes each has 200 random addresses. They are routed between 6 vlans. # netstat -I ix0 -w 1 input (ix0) output packets errs idrops bytes packets errs bytes colls 8917043 0 0 571436864 8149880 0 522587200 0 8943391 0 0 571598336 8179318 0 525085504 0 8928155 0 0 571262144 8168254 0 522712192 0 8921342 0 937 571693504 8128132 0 521997184 0 8924322 0 0 571170048 8211500 0 520264320 0 8934564 0 0 571483584 8180040 0 524475264 0 8937039 0 0 571384640 8234779 0 525686080 0 8926528 0 0 571481728 8160380 0 524265920 0 8923160 0 0 571397248 8229839 0 522569408 0 8930070 0 1705 571594944 8216092 0 528481152 0 8916249 0 0 571294784 8184286 0 524399360 0 8937301 0 0 571391040 8221895 0 526383744 0 8927967 0 0 571613312 8164779 0 524997760 0 8936306 0 0 571251712 8167960 0 519575744 0 8922983 0 306 571430528 8216466 0 525893056 0 8916209 0 0 571434240 8202692 0 526046336 0 8945608 0 0 571426624 8265756 0 524815552 0 8925548 0 1045 571444480 8229681 0 530935232 0 8932145 0 0 571747200 8149710 0 523409536 0 8929339 0 0 571683200 8186790 0 520719040 0 8917697 0 0 571585152 8212635 0 525775680 0 # top -PSH last pid: 2788; load averages: 12.01, 4.76, 1.92 up 0+00:04:38 20:58:48 471 processes: 45 running, 344 sleeping, 82 waiting CPU 0: 0.0% user, 0.0% nice, 21.6% system, 68.2% interrupt, 10.2% idle= CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 2: 0.0% user, 0.0% nice, 2.7% system, 84.3% interrupt, 12.9% idle= CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 4: 0.0% user, 0.0% nice, 3.9% system, 86.7% interrupt, 9.4% idle= CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 6: 0.0% user, 0.0% nice, 5.5% system, 88.6% interrupt, 5.9% idle= CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 8: 0.0% user, 0.0% nice, 3.5% system, 90.2% interrupt, 6.3% idle= CPU 9: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 10: 0.0% user, 0.0% nice, 3.1% system, 87.1% interrupt, 9.8% idle= CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 12: 0.0% user, 0.0% nice, 27.5% system, 62.0% interrupt, 10.6% idle= CPU 13: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 14: 0.0% user, 0.0% nice, 6.3% system, 85.9% interrupt, 7.8% idle= CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 16: 0.0% user, 0.0% nice, 17.6% system, 79.6% interrupt, 2.7% idle= CPU 17: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 18: 0.0% user, 0.0% nice, 2.4% system, 92.2% interrupt, 5.5% idle= CPU 19: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 20: 0.0% user, 0.0% nice, 7.8% system, 86.7% interrupt, 5.5% idle= CPU 21: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 22: 0.0% user, 0.0% nice, 6.3% system, 87.5% interrupt, 6.3% idle= CPU 23: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 24: 0.0% user, 0.0% nice, 1.6% system, 89.4% interrupt, 9.0% idle= CPU 25: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 26: 0.0% user, 0.0% nice, 2.0% system, 91.8% interrupt, 6.3% idle= CPU 27: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 28: 0.0% user, 0.0% nice, 2.7% system, 87.8% interrupt, 9.4% idle= CPU 29: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 30: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle= CPU 31: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle= Mem: 17M Active, 13M Inact, 716M Wired, 61G Free ARC: 28M Total, 6102K MFU, 20M MRU, 16K Anon, 373K Header, 1492K Other Swap: 16G Total, 16G Free # top -HSIzts1 last pid: 2805; load averages: 13.88, 7.92, 3.56 up 0+00:06:40 21:00:50 469 processes: 45 running, 342 sleeping, 82 waiting CPU: 0.0% user, 0.0% nice, 3.5% system, 39.3% interrupt, 57.1% idle Mem: 17M Active, 13M Inact, 716M Wired, 61G Free ARC: 28M Total, 6105K MFU, 20M MRU, 16K Anon, 373K Header, 1494K Other Swap: 16G Total, 16G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -92 - 0K 1504K CPU22 22 3:38 87.35% intr{irq293: ix0:que } 12 root -92 - 0K 1504K WAIT 26 3:41 86.57% intr{irq295: ix0:que } 12 root -92 - 0K 1504K CPU18 18 3:41 86.47% intr{irq291: ix0:que } 12 root -92 - 0K 1504K CPU28 28 3:41 86.47% intr{irq296: ix0:que } 12 root -92 - 0K 1504K CPU24 24 3:39 86.18% intr{irq294: ix0:que } 12 root -92 - 0K 1504K WAIT 4 3:35 86.18% intr{irq284: ix0:que } 12 root -92 - 0K 1504K CPU8 8 3:35 86.18% intr{irq286: ix0:que } 12 root -92 - 0K 1504K CPU6 6 3:33 85.60% intr{irq285: ix0:que } 12 root -92 - 0K 1504K CPU20 20 3:32 85.50% intr{irq292: ix0:que } 12 root -92 - 0K 1504K CPU10 10 3:32 84.86% intr{irq287: ix0:que } 12 root -92 - 0K 1504K CPU2 2 3:32 84.67% intr{irq283: ix0:que } 12 root -92 - 0K 1504K WAIT 14 3:31 84.38% intr{irq289: ix0:que } 12 root -92 - 0K 1504K CPU16 16 3:11 77.59% intr{irq290: ix0:que } 12 root -92 - 0K 1504K CPU0 0 2:42 64.70% intr{irq282: ix0:que } 12 root -92 - 0K 1504K CPU12 12 2:44 63.67% intr{irq288: ix0:que } 0 root -92 0 0K 4672K - 12 1:01 26.66% kernel{ix0 que} 0 root -92 0 0K 4672K - 0 0:58 23.00% kernel{ix0 que} 0 root -92 0 0K 4672K - 16 0:48 18.16% kernel{ix0 que} 0 root -92 0 0K 4672K - 20 0:20 7.86% kernel{ix0 que} 0 root -92 0 0K 4672K - 14 0:15 5.57% kernel{ix0 que} 0 root -92 0 0K 4672K CPU6 6 0:14 5.57% kernel{ix0 que} 0 root -92 0 0K 4672K - 22 0:12 4.59% kernel{ix0 que} 0 root -92 0 0K 4672K - 18 0:06 4.59% kernel{ix0 que} 0 root -92 0 0K 4672K - 28 0:06 4.49% kernel{ix0 que} 0 root -92 0 0K 4672K - 26 0:06 4.39% kernel{ix0 que} 0 root -92 0 0K 4672K - 24 0:05 4.05% kernel{ix0 que} 0 root -92 0 0K 4672K - 8 0:09 3.47% kernel{ix0 que} 0 root -92 0 0K 4672K - 4 0:08 3.17% kernel{ix0 que} 0 root -92 0 0K 4672K - 10 0:07 2.98% kernel{ix0 que} 0 root -92 0 0K 4672K - 2 0:05 2.39% kernel{ix0 que} # pmcstat -TS llc-misses -w10 PMC: [llc-misses] Samples: 3949 (100.0%) , 0 unresolved %SAMP IMAGE FUNCTION CALLERS 28.6 kernel ixgbe_rxeof ixgbe_msix_que:25.9 ixgbe_handle_que:2.8 14.7 kernel bcmp netisr_dispatch_src:13.5 rtalloc_fib_nolock:1.0 5.9 kernel mb_ctor_mbuf uma_zalloc_arg 5.8 kernel ixgbe_mq_start vlan_transmit 4.6 kernel _mtx_trylock ixgbe_mq_start 3.8 kernel ether_nh_input netisr_dispatch_src 2.6 kernel ether_input ixgbe_msix_que 2.4 kernel m_tag_delete_chain m_tag_copy_chain:1.2 uma_zfree_arg:= 0.9 2.4 kernel netisr_dispatch_src ixgbe_rxeof:1.6 ixgbe_msix_que:0.6 2.2 kernel cpu_search_highest cpu_search_highest 2.2 kernel ixgbe_txeof ixgbe_msix_que 2.1 kernel uma_zfree_arg m_freem 2.0 kernel netisr_dispatch ixgbe_msix_que:1.1 ixgbe_rxeof:0.7 2.0 kernel critical_exit uma_zfree_arg 1.9 kernel _thread_lock_flags ithread_loop:1.2 intr_event_schedule_thread:0.6 1.9 kernel _bus_dmamap_sync ixgbe_rxeof 1.3 kernel ixgbe_xmit ixgbe_mq_start_locked 0.9 kernel ixgbe_msix_que intr_event_execute_handlers --=20 WBR, Andrey V. Elsukov --w6HrlTCB1wwmluQU9FwTkbOBVFpAuU9P2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUWlesAAoJEAHF6gQQyKF6aJsH/2bQCyYPCS6dllqsj/o81eMX 814K6t14Q85xvfDuTlfjxqjvTBjxPWrbZK2SBQ1qWB0WZvBQeOnFWn4Whf0QQ46f WRm2ft2YE7tTyBtdY5B9EltErH9MnbXqHGhGMQhrhTOlgmVo6dVVcGi2aXLmiUhm L62dKMpifedM9Ecfm9aZpXZhn0pdVyqriJ+QTND2xeynqC24Lu871CbiHr5UCE8j 8KpKCnS7c3uLcNH4j/pCvMmDcNc/igi9tyVC2wjx4rWm/sZlK+dG74p2UfjZGKow W+f8ITbpnE8OSIQ6OphlJFTdv4Hakc4AtCHrXLceqWixU4Q5i2+ntm/YhNjnJLs= =Xifd -----END PGP SIGNATURE----- --w6HrlTCB1wwmluQU9FwTkbOBVFpAuU9P2-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 17:22:36 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE3A9180; Wed, 5 Nov 2014 17:22:36 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A883C37; Wed, 5 Nov 2014 17:22:36 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xm0HP-000IRl-Vv; Wed, 05 Nov 2014 17:05:44 +0400 Message-ID: <545A5C4D.3050603@FreeBSD.org> Date: Wed, 05 Nov 2014 21:20:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: George Neville-Neil , net@freebsd.org Subject: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> In-Reply-To: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:22:37 -0000 On 05.11.2014 19:39, George Neville-Neil wrote: > Howdy, > > Last night (Pacific Time) I committed a change so that GENERIC, on > HEAD has the netmap > device enabled. This is to increase the breadth of our testing of > that feature prior > to the release of FreeBSD 11. > > In two weeks I will enable IPSec by default, again in preparation for 11. Please don't. While I love to be able to use IPSEC features on unmodified GENERIC kernel, simply enabling IPSEC is not the best thing to do in terms of performance. Current IPSEC locking model is pretty complicated and is not scalable enough. It looks like it requires quite a lot of man-hours/testing to be reworked to achieve good performance and I'm not sure if making it enabled by default will help that. Current IPv4/IPv6 stack code with some locking modifications is able to forward 8-10MPPS on something like 2xE2660. I'm in process of merging these modification in "proper" way to our HEAD, progress can be seen in projects/routing. While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of other) changes are not there yet, you can probably get x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. 2-3mpps depending on test conditions). In contrast, I haven't seen IPSEC being able to process more than 200kpps for any kind of workload. What we've discussed with glebius@ and jmg@ at EuroBSDCon was to modify PFIL to be able to monitor/enforce hooks ordering and make IPSEC code usual pfil consumer. In that case, running GENERIC with IPSEC but w/o any SA won't influence packet processing path. This also simplifies the process of making IPSEC loadable. > > Best, > George > _______________________________________________ > 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 Nov 5 17:47:29 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36B2C5F0; Wed, 5 Nov 2014 17:47:29 +0000 (UTC) Received: from forward1l.mail.yandex.net (forward1l.mail.yandex.net [IPv6:2a02:6b8:0:1819::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1369E57; Wed, 5 Nov 2014 17:47:28 +0000 (UTC) Received: from smtp1m.mail.yandex.net (smtp1m.mail.yandex.net [77.88.61.132]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 677DB152167D; Wed, 5 Nov 2014 20:47:16 +0300 (MSK) Received: from smtp1m.mail.yandex.net (localhost [127.0.0.1]) by smtp1m.mail.yandex.net (Yandex) with ESMTP id DF72C6740298; Wed, 5 Nov 2014 20:47:15 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::1e7]) by smtp1m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id rJUqf603rW-lF20wAcI; Wed, 5 Nov 2014 20:47:15 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 3247e923-0854-482b-8366-7bb58d04efcb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1415209635; bh=ZyIVWV2U7Jl1R+FFGj0BKimeTpW1t3exANLtz0r3gdo=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=o+Whm4Pd42OeBGhtOd2RYacrYzr56CyGdFxFYbPEfQwnD5dTzwOQ1L7JVAyCRLqrR d+lG+lFmAQjzghNmQb+fUHc6Ew0uBvRKbn/Yfn1TMPX+yJDI5MJl4JYosbAZ8M2WW+ 5KOJJ9jsP2zUVJQgr4+0jX0p4KhNLyR7eqHgXtz0= Authentication-Results: smtp1m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <545A6298.9070809@yandex.ru> Date: Wed, 05 Nov 2014 20:47:04 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: George Neville-Neil , net@freebsd.org Subject: Re: netmap in GENERIC, by default, on HEAD References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> In-Reply-To: <545A47A5.4010601@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KHtnrkujWAoPiEQvU1lc44fiktD46f5wU" Cc: "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:47:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KHtnrkujWAoPiEQvU1lc44fiktD46f5wU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.11.2014 18:52, Andrey V. Elsukov wrote: > recently we did some IP forwarding tests and the GENERIC kernel is > several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. >=20 > I didn't do test on vanilla kernel, but our kernel is able forward > IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPSE= C > can forward only 180 kpps.=20 Sorry, I showed wrong numbers here. IPSEC kernel in this test gives 2.4 Mpps, but with encryption only 180 kpps. --=20 WBR, Andrey V. Elsukov --KHtnrkujWAoPiEQvU1lc44fiktD46f5wU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUWmKcAAoJEAHF6gQQyKF6U+8IAJQZBnPAeA1oxWc1AWBGbiPX lxixHdwfk9OSzJCNUXGRegDElDEDqMhCEaIKK020CDUiz8OBspkCDTZ+A10Rjt9f NC6w11MLLSM6k1GM265WyaBlXdh9YKMqosRocL3+6fHfezrJGKMjDMQed++klWye QLp14ooj/mPmK5bA4SpRedvRGkVeuB6eKF4Ep+N0OJzEsrUiRlPOEvkEPo8aJhg8 lD4eIb54bazAg94vm7i+jCa3BovU4V8/jBxg4il7bVoodm/YoEUwgOjlqDTSv6u9 wHLegYXojdkx14aNuGbt1VC5rh1Ln6vm6WN94N8Z5Ri+NUeFEPIgBRoGrlloo7Q= =1LXs -----END PGP SIGNATURE----- --KHtnrkujWAoPiEQvU1lc44fiktD46f5wU-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 17:53:12 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2AAC86C for ; Wed, 5 Nov 2014 17:53:12 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A57A5F43 for ; Wed, 5 Nov 2014 17:53:12 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id g10so1171247pdj.38 for ; Wed, 05 Nov 2014 09:53:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=g+ayookuk/g67xXeyt68jNb8AWimR2nXhObJy1KyF3M=; b=LzPvTdI6VQK/Cubx1QZWZFkchRWbCSF9eOKvgTLARBTGWXyZC/9nxOQ05UfcQg27QI u/basZsdQYzVJsh0dNubdnw+qqH1IqOUwMAOCm9sxXtkQDcC+pDZ1EHwagYvCvh3G/+B wPOYimgqqW5jd/INrxH/1dNnGp3g0XIaTVJIhk8caq20syOOKsLpIRXpTp+d3DIwdeIW +h+7MVpWr3cUgGTB/QWvqDB1qUb6Zw6Cl6U57AagSMRfPfPedscetHD5LbXyTtrQ9sFd GpMIoFyihF0so42ZJwSSDmgvRWqEl2kJSsWT1T4zz03rAPAFX3PIDjBLnhnGBpD9tRM4 n+QA== X-Gm-Message-State: ALoCoQmWB0eZH29tt+hbb1cC7SS1AN5lWI6bT1BJVPtIGYQJP/rI9xygSg5293PEzub9XKtVnwPh X-Received: by 10.70.88.44 with SMTP id bd12mr6868974pdb.133.1415209986009; Wed, 05 Nov 2014 09:53:06 -0800 (PST) Received: from [29.220.175.147] ([66.87.119.147]) by mx.google.com with ESMTPSA id d9sm3814498pdm.5.2014.11.05.09.53.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 09:53:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: netmap in GENERIC, by default, on HEAD From: Jim Thompson X-Mailer: iPhone Mail (12B411) In-Reply-To: <545A6298.9070809@yandex.ru> Date: Wed, 5 Nov 2014 09:53:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> <545A6298.9070809@yandex.ru> To: "Andrey V. Elsukov" Cc: "Alexander V. Chernikov" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:53:12 -0000 > On Nov 5, 2014, at 9:47 AM, Andrey V. Elsukov wrote: >=20 > Sorry, I showed wrong numbers here. IPSEC kernel in this test gives 2.4 > Mpps, but with encryption only 180 kpps. This is more in-line with what I'd expect, assuming AES-CBC-HMAC.=20 Improving the situation wrt encryption overhead seems straight-forward or, a= t least, approachable.=20= From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 18:07: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4BA8B52 for ; Wed, 5 Nov 2014 18:07:52 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6771129 for ; Wed, 5 Nov 2014 18:07:52 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9A6C320921 for ; Wed, 5 Nov 2014 13:00:23 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Wed, 05 Nov 2014 13:00:23 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=ZCGe6dSa6KrVOoBvmkd693Ax otw=; b=isF+iNlpLfS3acRFMGOFEO3WnEBuimynPrwlaxlD1R+ilMv6E67yBgGW qhDqhUVWnmYi/kMycfT5YLFUAzh0dccBn53EZ7gpHaNBxlbHCt8xee2LC9fdbUVs 0xEZ9X25pE6SUQVll4BAEtE6cYQWcT7f+grvIIzCOiyxvL5myZ4= Received: by web3.nyi.internal (Postfix, from userid 99) id 77C7C1134A3; Wed, 5 Nov 2014 13:00:23 -0500 (EST) Message-Id: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> X-Sasl-Enc: +g+fVc20oQjz59QoEZ9pnSDk8fMfvtgZ7aaxMf5DP22C 1415210423 From: Mark Felder To: Ilya Bakulin , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c51dec4f In-Reply-To: References: Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output Date: Wed, 05 Nov 2014 12:00:23 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:07:52 -0000 On Wed, Nov 5, 2014, at 08:28, Ilya Bakulin wrote: > Hi all, > > I have been hit by this 2-year-old bug with PF and 'scrub reassemble > tcp' on IPv6 connections: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172648 > Wow, this is great. I've known about this problem since I discovered it upon updating to the 9.0-RELEASE and found my IPv6 connections were slow as molasses. Thank you for implementing a fix. I hope to be able to test it soon. Now if we could only stamp out the bug with ipv6 fragment and pf I'd be a happy, happy daemon. :-) From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 18:12:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4489AD36; Wed, 5 Nov 2014 18:12:04 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03E911F6; Wed, 5 Nov 2014 18:12:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 16F817590E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1415211115; bh=jiqV7nshTFIXF30xL6f5PmjUmzZN+LXf1Ry2BCijBP4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZYYBX1HDMmRovjnVtTVS9V9nscarWp/f/UltL4jBIIvvdDM6rArHKVm/NfR77fcEz vQbHXxzwC17pPREwj/281nOzIv4Q08BBhOqPXNK5+uc51JwYvFkC7IWmQmTyrBfBby oKbvJvfq/zhp+nE1C7fMHnWJwdqHVUO9M1yl1IjM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Nov 2014 19:11:55 +0100 From: Ilya Bakulin To: Mark Felder Subject: Re: Checksumming outgoing packets in PF vs in =?UTF-8?Q?ip=5B=36=5D=5Foutput?= Organization: Deglitch Networks In-Reply-To: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> Message-ID: <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> X-Sender: ilya@bakulin.de Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:12:04 -0000 On 2014-11-05 19:00, Mark Felder wrote: > On Wed, Nov 5, 2014, at 08:28, Ilya Bakulin wrote: >> Hi all, >> >> I have been hit by this 2-year-old bug with PF and 'scrub reassemble >> tcp' on IPv6 connections: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172648 >> > > Wow, this is great. I've known about this problem since I discovered it > upon updating to the 9.0-RELEASE and found my IPv6 connections were > slow > as molasses. Thank you for implementing a fix. I hope to be able to > test > it soon. I hope this helps! btw I've tested this on 11-CURRENT, but I think the code in 9 and 10 should not be different wrt checksum handling. > > Now if we could only stamp out the bug with ipv6 fragment and pf I'd be > a happy, happy daemon. :-) This is somewhat more complex problem, I'll take a look as the time allows. From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 19:06:55 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90BD1E85 for ; Wed, 5 Nov 2014 19:06:55 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 716FD9B8 for ; Wed, 5 Nov 2014 19:06:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA5J6tj0045688 for ; Wed, 5 Nov 2014 19:06:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194840] New: [carp] Incorrect work of CARP services, started at BACKUP IP Date: Wed, 05 Nov 2014 19:06:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RC1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: admin@support.od.ua X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:06:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194840 Bug ID: 194840 Summary: [carp] Incorrect work of CARP services, started at BACKUP IP Product: Base System Version: 10.1-RC1 Hardware: amd64 OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: admin@support.od.ua CC: freebsd-net@FreeBSD.org I have 2 almost identical BGP routers FreeBSD 10.1-PRERELEASE #0: Thu Oct 16 03:58:25 EEST 2014 Both servers are connected with the same switch and have 1 uplink, but default gateways are different. There is one gateway on the uplink side, IPs are different, but use VRRP. [20:19]router1:root->/root# ifconfig em1.201 em1.201: flags=8943 metric 0 mtu 1500 options=103 ether 00:25:90:34:cc:af inet XXX.XXX.157.1 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 13 inet XXX.XXX.157.2 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 11 inet XXX.XXX.157.5 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 12 inet XXX.XXX.157.129 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 14 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active vlan: 201 parent interface: em1 carp: MASTER vhid 13 advbase 1 advskew 50 carp: BACKUP vhid 11 advbase 1 advskew 150 carp: BACKUP vhid 12 advbase 1 advskew 100 carp: BACKUP vhid 14 advbase 1 advskew 100 [20:35]router1:root->/root# netstat -rn | egrep 'XXX.XXX.157.|Destination' Destination Gateway Flags Netif Expire XXX.XXX.157.0/24 link#8 U em1.201 XXX.XXX.157.1 link#8 UHS lo0 XXX.XXX.157.3 XXX.XXX.157.191 UGH1 em1.201 XXX.XXX.157.4 XXX.XXX.157.191 UGH1 em1.201 XXX.XXX.157.6 XXX.XXX.157.191 UGH1 em1.201 [20:36]router1:root->/root# arp -na ? (XXX.XXX.157.35) at (incomplete) on em1.201 expired [vlan] ? (XXX.XXX.157.131) at 00:25:90:18:3d:b8 on em1.201 expires in 1157 seconds [vlan] ? (XXX.XXX.157.195) at 62:b2:dc:c0:08:96 on em1.201 expires in 624 seconds [vlan] ? (XXX.XXX.157.2) at 00:00:5e:00:01:0b on em1.201 expires in 1194 seconds [vlan] ? (XXX.XXX.157.194) at (incomplete) on em1.201 expired [vlan] ... [20:18]router2:root->/root# ifconfig em1.201 em1.201: flags=8943 metric 0 mtu 1500 options=103 ether 00:25:90:00:58:fd inet XXX.XXX.157.1 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 13 inet XXX.XXX.157.2 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 11 inet XXX.XXX.157.5 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 12 inet XXX.XXX.157.129 netmask 0xffffff00 broadcast XXX.XXX.157.255 vhid 14 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active vlan: 201 parent interface: em1 carp: BACKUP vhid 13 advbase 1 advskew 100 carp: MASTER vhid 11 advbase 1 advskew 50 carp: MASTER vhid 12 advbase 1 advskew 50 carp: MASTER vhid 14 advbase 1 advskew 50 [20:34]router2:root->/root# arp -na ? (XXX.XXX.157.1) at 00:00:5e:00:01:0d on em1.201 expires in 1195 seconds [vlan] ? (XXX.XXX.157.196) at bc:5f:f4:1b:d8:91 on em1.201 expires in 1082 seconds [vlan] ? (XXX.XXX.157.191) at 00:25:90:18:3d:b8 on em1.201 expires in 549 seconds [vlan] ? (192.168.25.11) at 00:25:90:34:cc:af on em1.199 expires in 25 seconds [vlan] ? (192.168.25.12) at 00:25:90:00:58:fd on em1.199 permanent [vlan] ... After pinging from remote place XXX.XXX.157.2, I had answer, but, by tcpdump, answer is coming from em1.201 router1, but not router2! After pinging from router1 IP XXX.XXX.157.2, answer is coming from em1.201 router2 to em1.201 router1. ARP cache on server Backup inside the network: [20:30]backup:root->/root# traceroute -n XXX.XXX.157.2 traceroute to XXX.XXX.157.2 (XXX.XXX.157.2), 64 hops max, 52 byte packets 1 XXX.XXX.157.2 0.100 ms 0.131 ms 0.146 ms [20:30]backup:root->/root# arp -na ? (XXX.XXX.157.2) at 00:00:5e:00:01:0b on bge0 expires in 101 seconds [ethernet] ? (XXX.XXX.157.1) at 00:00:5e:00:01:0d on bge0 expires in 1199 seconds [ethernet] ? (XXX.XXX.157.196) at bc:5f:f4:1b:d8:91 on bge0 permanent [ethernet] ? (10.0.1.2) at 00:25:90:81:8b:8e on bge0 expires in 105 seconds [ethernet] ? (10.0.1.1) at 00:25:90:18:3d:b9 on bge0 expires in 866 seconds [ethernet] ? (10.0.1.5) at bc:5f:f4:1b:d8:91 on bge0 permanent [ethernet] ... -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 22:25: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 480641B3 for ; Wed, 5 Nov 2014 22:25:40 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4033CD for ; Wed, 5 Nov 2014 22:25:39 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id r20so1353765wiv.3 for ; Wed, 05 Nov 2014 14:25:37 -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=J511Kr3SPGS7FlDVj6quZLYcsi6b+dpYR+ezccj5fuM=; b=f9VzXYnZi6j2QFcNVFw0rFHvf/xD5yh60dprTLcNrdsTYgbS2Z8IcVbJfLMhk5hU3m +p1qbOI8LJDLSbV1YalGNokqgQkho/SqdFHAJHI8GwFPYJvjENopIVkOhsuf8OIPFrLe 7TJ+xo4ViwPw+3pdAGK/vz4bFzb6F2xOe9C5nmlYZchxOQQDylYKX3Y1Y9GGb79tPFmx PAVTHB66gZaUOhvAlt8hBUbyAue6+67HO0OrRqBw4AQSWgKz5+i3hgGHHX7gvufGyX5a c2P/knSgPvlhS++YPESqa2d8lM3/jRDhJxlTtlI4A3BDzw6vTU+xTum4sZAkRGDpGIHu IvpA== MIME-Version: 1.0 X-Received: by 10.180.107.136 with SMTP id hc8mr35253636wib.78.1415226337846; Wed, 05 Nov 2014 14:25:37 -0800 (PST) Received: by 10.217.92.7 with HTTP; Wed, 5 Nov 2014 14:25:37 -0800 (PST) In-Reply-To: <20141104221216.GA17502@onelab2.iet.unipi.it> References: <20141104221216.GA17502@onelab2.iet.unipi.it> Date: Wed, 5 Nov 2014 20:25:37 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 22:25:40 -0000 dear luigi sadly it still did not work, I have the scenario set, please see below: On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote: > On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote: > > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote: > ... > > >> i gues I am missing a piece of the architecture... > > >> > > > > > > ???probably yes :) > > > > > > kipfw em1 em2 connects the two interfaces to each other, keeping the > > > rest ??? > > > > > > ???of the host stack completely out of the game. > > > > > > > got it > > uhmmm... probably not, see below: > > > however it's still not counting any packets coming in or out of the > > interfaces > > > > > > > ???I am not sure where you are running pkt-gen (is it on a separate > > > machine ?) and what the 'em1' used in ??? > > > ??? > > > ???pkt-gen is connected to. > > > > > > > > > I am running one pkt-gen in TX mode on the same machine, and another one > in > > RX mode in a separate machine, but this is just for reference, to make > sure > > packets are actually getting transmitted, and it is... > > you cannot run two netmap clients on the same NIC at the same time > (unless you know how to do that, and avoid they stomp on each other). > > In this particular case it means that you should test things as follows > > machine A: pkt-gen -i em1 -f tx ... > > machine B kipfw em1 em2 > > machine C pkt-gen -i em3 -f rx > > And the connection between the ports is the following > > [A em1] <--> [em1 B em2] <--> [em3 C] > 1) added a couple count rules to ipfw (kernel): # ipfw add count all from any to any via em1 00100 count ip from any to any via em1 # ipfw add count all from any to any via em2 00200 count ip from any to any via em2 2) connected kipfw to the NICs # ./kipfw em1 em2 > & /tmp/kipfw.log & [1] 64845 3) added the same count rules to netmap-ipfw # ipfw/ipfw add count all from any to any via em1 connected to 127.0.0.1:5555 00100 count ip from any to any via em1 # ipfw/ipfw add count all from any to any via em2 connected to 127.0.0.1:5555 00200 count ip from any to any via em2 4) machine A started to ping machine C, both have machine B (netmap-ipfw host) as a gateway) 5) checked netmap-ipfw stats and nothing is counting: # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 216 ptr 0x0 00100 0 0 count ip from any to any via em1 00200 0 0 count ip from any to any via em2 65535 0 0 allow ip from any to any 6) checked kernel-stack ipfw and it does count: # ipfw show 00100 251 22168 count ip from any to any via em1 00200 143 13984 count ip from any to any via em2 65535 3272 365840 allow ip from any to any 7) started to generate high rate of pps via pkg-gen 8) ipfw kernel stack is counting: # ipfw show 00100 11976801 552000119 count ip from any to any via em1 00200 11975703 551008127 count ip from any to any via em2 65535 11989680 552505771 allow ip from any to any 9) while netmap-ipfw stills wont filter: # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 216 ptr 0x0 00100 0 0 count ip from any to any via em1 00200 0 0 count ip from any to any via em2 65535 0 0 allow ip from any to any 10) ./kipfw output reads: 642.000022] session.c:mainloop [624] callouts 3531236 skipped 16 [ 643.000214] session.c:mainloop [624] callouts 3535582 skipped 16 [ 644.000043] session.c:mainloop [624] callouts 3539934 skipped 16 [ 645.000203] session.c:mainloop [624] callouts 3544275 skipped 16 [ 646.000140] session.c:mainloop [624] callouts 3548639 skipped 16 [ 647.000155] session.c:mainloop [624] callouts 3552987 skipped 16 [ 648.000071] session.c:mainloop [624] callouts 3557311 skipped 16 [ 649.000112] session.c:mainloop [624] callouts 3561621 skipped 16 [ 650.000135] session.c:mainloop [624] callouts 3565505 skipped 16 [ 651.000110] session.c:mainloop [624] callouts 3569867 skipped 16 [ 652.000180] session.c:mainloop [624] callouts 3574215 skipped 16 [ 653.000156] session.c:mainloop [624] callouts 3578457 skipped 16 [ 654.000098] session.c:mainloop [624] callouts 3582747 skipped 16 [ 654.171717] missing.c:callout_run [378] running 0x61e9d0 due at 4289151 now 4289306 [ 654.277852] missing.c:callout_run [378] running 0x61e9d0 due at 4289652 now 4289836 [ 654.380216] missing.c:callout_run [378] running 0x61e9d0 due at 4290129 now 4290348 [ 654.419590] missing.c:callout_run [378] running 0x61e9d0 due at 4290430 now 4290545 [ 654.451089] missing.c:callout_run [378] running 0x61e9d0 due at 4290573 now 4290702 [ 654.482725] missing.c:callout_run [378] running 0x61e9d0 due at 4290751 now 4290861 [ 654.508343] missing.c:callout_run [378] running 0x61e9d0 due at 4290862 now 4290989 [ 655.000026] session.c:mainloop [624] callouts 3585292 skipped 16 [ 656.000042] session.c:mainloop [624] callouts 3589583 skipped 16 [ 657.000137] session.c:mainloop [624] callouts 3593939 skipped 16 [ 658.000011] session.c:mainloop [624] callouts 3598242 skipped 16 next, I have up on FreeBSD base's netmap and decided to try the latest code from: 11) stopped kipfw and unloaded netmap: # killall -9 kipfw [1] + Killed ./kipfw em1 em2 >& /tmp/kipfw.log # kldunload netmap 12) loaded the new just-built kernel module: # kldload ../netmap-7e9e5e7602f5/sys/modules/netmap/netmap.ko 13) started to generate traffic from machine A to machine C again and tried again to see some packets getting netmap filtered: # ./kipfw em1 em2 > & /tmp/kipfw.log & [1] 66583 # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 56 ptr 0x0 65535 0 0 allow ip from any to any # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 56 ptr 0x0 65535 0 0 allow ip from any to any # ipfw/ipfw add count all from any to any connected to 127.0.0.1:5555 00100 count ip from any to any # ipfw/ipfw add deny all from any to any connected to 127.0.0.1:5555 00200 deny ip from any to any # ipfw/ipfw show connected to 127.0.0.1:5555 nalloc 2248 nbytes 168 ptr 0x0 00100 0 0 count ip from any to any 00200 0 0 deny ip from any to any 65535 0 0 allow ip from any to any and still not counting (only the default rule this time) how can I debug from this point? NIC is em(4) controlled and has 82574L chipset... > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Wed Nov 5 22:44:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10069968 for ; Wed, 5 Nov 2014 22:44:06 +0000 (UTC) Received: from leviatan.freebsdbrasil.com.br (leviatan.freebsdbrasil.com.br [177.10.156.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56F132FC for ; Wed, 5 Nov 2014 22:44:04 +0000 (UTC) Received: (qmail 67663 invoked from network); 5 Nov 2014 22:44:00 -0000 Received: from darwin.bh.freebsdbrasil.com.br (eksffa@freebsdbrasil.com.br@[10.69.69.7]) (envelope-sender ) by capeta.freebsdbrasil.com.br (qmail-ldap-1.03) with SMTP for ; 5 Nov 2014 22:44:00 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: netmap-ipfw on em0 em1 From: Patrick Tracanelli In-Reply-To: Date: Wed, 5 Nov 2014 20:44:17 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> References: <20141104221216.GA17502@onelab2.iet.unipi.it> To: Evandro Nunes X-Mailer: Apple Mail (2.1990.1) Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 22:44:06 -0000 Hey, what you are doing wrong is much more simple than you expect. > # ./kipfw em1 em2 > & /tmp/kipfw.log & > [1] 66583 Just run ./kipfw netmap:em1 netmap:em2 and this will probably work. Please remember to redirect kipfw output to somewhere you are not = reading only *after* you are sure the output is showing errors. If you = could read the output you would probably get something like =E2=80=9Cerror= opening em0=E2=80=9D or something like that coming netmap. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 00:40:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71D062E0 for ; Thu, 6 Nov 2014 00:40:37 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F133812E for ; Thu, 6 Nov 2014 00:40:36 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so58187wiw.6 for ; Wed, 05 Nov 2014 16:40:33 -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=eMBQ8Fi6RQhE8s9p8EAFxyON0Gv1OIUfdZ9MYS1Npqg=; b=S/sam2bQP3YES4cDJyZRAt2ySL/hWvNWB3XddXbbuibh21HZgxDAaZZe0wmETuzXuW 92CZUq5VE1kQEQU5HiggZFx6h0rfr2eUgL3OoaiTeY8CBEyr+yitxPR5uNo5evfFZSlV jO6hjtCy2tQk0pwYRHCef0GdM8ymarMxbgXNOXdil002PljjLgEFutM5yGIYSNoq8NQY DzZvMYoyUYAFXuv6j96W3L6umji6nEK4QlYSITRuXvmoZAqJ5QuyawDq65KRP3iQKe5e /lILxulcft6/NF4rfOd2rHcIHdYXKFkTXCuXIlhaos0+VrSyL6xMfwzdbNeE/qlYFf6v tKvQ== MIME-Version: 1.0 X-Received: by 10.180.104.105 with SMTP id gd9mr36141171wib.65.1415234433500; Wed, 05 Nov 2014 16:40:33 -0800 (PST) Received: by 10.217.92.7 with HTTP; Wed, 5 Nov 2014 16:40:33 -0800 (PST) In-Reply-To: <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Wed, 5 Nov 2014 22:40:33 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Patrick Tracanelli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 00:40:37 -0000 On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli < eksffa@freebsdbrasil.com.br> wrote: > Hey, what you are doing wrong is much more simple than you expect. > > > # ./kipfw em1 em2 > & /tmp/kipfw.log & > > [1] 66583 > > Just run ./kipfw netmap:em1 netmap:em2 and this will probably work. > > Please remember to redirect kipfw output to somewhere you are not reading > only *after* you are sure the output is showing errors. If you could read > the output you would probably get something like =E2=80=9Cerror opening e= m0=E2=80=9D or > something like that coming netmap. > hello dear patrick thank you, yes it did work now at least it is counting packets but things are still weird, even though I have only count and allow rules, and yes they are counting packets, when I run kipfw, every packet on em1 and em2 gets dropped immediately. no matter they are allow rules counting packets, packets get dropped and machine-A gets completely isolated from machine-C any further help is appreciated From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 01:10:21 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46073B12; Thu, 6 Nov 2014 01:10:21 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BFAA5FF; Thu, 6 Nov 2014 01:10:20 +0000 (UTC) Received: from 50-206-19-250-static.hfc.comcastbusiness.net ([50.206.19.250]:57613 helo=[10.1.10.186]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XmBad-0008BB-HE; Wed, 05 Nov 2014 20:10:19 -0500 From: "George Neville-Neil" To: "Alexander V. Chernikov" Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] Date: Wed, 05 Nov 2014 17:10:18 -0800 Message-ID: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> In-Reply-To: <545A5C4D.3050603@FreeBSD.org> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4576) 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: "Andrey V. Elsukov" , John-Mark Gurney , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:10:21 -0000 On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote: > On 05.11.2014 19:39, George Neville-Neil wrote: >> Howdy, >> >> Last night (Pacific Time) I committed a change so that GENERIC, on >> HEAD has the netmap >> device enabled. This is to increase the breadth of our testing of >> that feature prior >> to the release of FreeBSD 11. >> >> In two weeks I will enable IPSec by default, again in preparation for >> 11. > Please don't. > > While I love to be able to use IPSEC features on unmodified GENERIC > kernel, simply enabling > IPSEC is not the best thing to do in terms of performance. > > Current IPSEC locking model is pretty complicated and is not scalable > enough. > It looks like it requires quite a lot of man-hours/testing to be > reworked to achieve good performance and I'm not sure > if making it enabled by default will help that. > > Current IPv4/IPv6 stack code with some locking modifications is able > to forward 8-10MPPS on something like 2xE2660. > I'm in process of merging these modification in "proper" way to our > HEAD, progress can be seen in projects/routing. > While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of other) > changes are not there yet, you can probably get > x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. > 2-3mpps depending on test conditions). > > In contrast, I haven't seen IPSEC being able to process more than > 200kpps for any kind of workload. > > What we've discussed with glebius@ and jmg@ at EuroBSDCon was to > modify PFIL to be able to monitor/enforce > hooks ordering and make IPSEC code usual pfil consumer. In that case, > running GENERIC with IPSEC but w/o any SA > won't influence packet processing path. This also simplifies the > process of making IPSEC loadable. > How soon do you think the pfil patch would be ready? That sounds like a good first step towards making all this enabled in HEAD so that we can make sure that IPSec gets the broad testing that it needs. Also, if folks who know about these problems can send workloads and test descriptions to the list that would be very helpful. Specific drivers and hardware types would be most helpful as this may be device related as well. I will turn this on on some machines in the network test lab to see what I can see. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 01:12:34 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D41F1C40; Thu, 6 Nov 2014 01:12:34 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A429C6DB; Thu, 6 Nov 2014 01:12:34 +0000 (UTC) Received: from 50-206-19-250-static.hfc.comcastbusiness.net ([50.206.19.250]:57632 helo=[10.1.10.186]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XmBcm-0008LG-27; Wed, 05 Nov 2014 20:12:33 -0500 From: "George Neville-Neil" To: "Andrey V. Elsukov" Subject: Re: netmap in GENERIC, by default, on HEAD Date: Wed, 05 Nov 2014 17:12:30 -0800 Message-ID: <7382F19D-A4E9-4831-8261-952629231B1A@neville-neil.com> In-Reply-To: <545A57A8.2010904@yandex.ru> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A47A5.4010601@yandex.ru> <545A57A8.2010904@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_270F14BB-B8AD-4903-9533-4BF594370719_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.8r4576) 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: Evandro Nunes , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:12:35 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_270F14BB-B8AD-4903-9533-4BF594370719_= Content-Type: text/plain On 5 Nov 2014, at 9:00, Andrey V. Elsukov wrote: > On 05.11.2014 19:18, Evandro Nunes wrote: >> On Wed, Nov 5, 2014 at 1:52 PM, Andrey V. Elsukov wrote: >> >>> On 05.11.2014 18:39, George Neville-Neil wrote: >>>> Howdy, >>>> >>>> Last night (Pacific Time) I committed a change so that GENERIC, on HEAD >>>> has the netmap >>>> device enabled. This is to increase the breadth of our testing of that >>>> feature prior >>>> to the release of FreeBSD 11. >>>> >>>> In two weeks I will enable IPSec by default, again in preparation for 11. >>> >>> Hi, >>> >>> recently we did some IP forwarding tests and the GENERIC kernel is >>> several times faster than GENERIC+IPSEC. Even when IPSEC has no SA. >>> >>> I didn't do test on vanilla kernel, but our kernel is able forward >>> IPv4/IPv6 on rate close to 8.6 Mpps. The same kernel compiled with IPSEC >>> can forward only 180 kpps. I think this problem should be solved before >>> enabling it in GENERIC. >>> >> >> this forward rate you mention is related to netmap? or usual >> forwarding/fastforwarding? this is a huge number, do you mind sharing your >> dmesg output and top -PSH output so I can check for interrupt CPU usage and >> other relevant stuff? > > This is patched kernel without netmap and fastforwarding. We removed all > lock contention on the forwarding path to be sure that it doesn't affect > IPSEC. > > Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (2200.05-MHz K8-class CPU) > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 SMT threads > real memory = 68736253952 (65552 MB) > avail memory = 66370662400 (63295 MB) > ix0: > port 0x7020-0x703f mem 0xde680000-0xde6fffff,0xde704000-0xde707fff irq > 32 at device 0.0 on pci4 > ix0: Using MSIX interrupts with 16 vectors > ix0: Ethernet address: 90:e2:ba:0d:73:54 > ix0: PCI Express Bus: Speed 5.0GT/s Width x8 > > This is IPv6 forwarding test - 6 /64 prefixes each has 200 random > addresses. They are routed between 6 vlans. > > # netstat -I ix0 -w 1 > input (ix0) output > packets errs idrops bytes packets errs bytes colls > 8917043 0 0 571436864 8149880 0 522587200 0 > 8943391 0 0 571598336 8179318 0 525085504 0 > 8928155 0 0 571262144 8168254 0 522712192 0 > 8921342 0 937 571693504 8128132 0 521997184 0 > 8924322 0 0 571170048 8211500 0 520264320 0 > 8934564 0 0 571483584 8180040 0 524475264 0 > 8937039 0 0 571384640 8234779 0 525686080 0 > 8926528 0 0 571481728 8160380 0 524265920 0 > 8923160 0 0 571397248 8229839 0 522569408 0 > 8930070 0 1705 571594944 8216092 0 528481152 0 > 8916249 0 0 571294784 8184286 0 524399360 0 > 8937301 0 0 571391040 8221895 0 526383744 0 > 8927967 0 0 571613312 8164779 0 524997760 0 > 8936306 0 0 571251712 8167960 0 519575744 0 > 8922983 0 306 571430528 8216466 0 525893056 0 > 8916209 0 0 571434240 8202692 0 526046336 0 > 8945608 0 0 571426624 8265756 0 524815552 0 > 8925548 0 1045 571444480 8229681 0 530935232 0 > 8932145 0 0 571747200 8149710 0 523409536 0 > 8929339 0 0 571683200 8186790 0 520719040 0 > 8917697 0 0 571585152 8212635 0 525775680 0 > > # top -PSH > last pid: 2788; load averages: 12.01, 4.76, 1.92 > > up 0+00:04:38 20:58:48 > 471 processes: 45 running, 344 sleeping, 82 waiting > CPU 0: 0.0% user, 0.0% nice, 21.6% system, 68.2% interrupt, 10.2% idle > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 2: 0.0% user, 0.0% nice, 2.7% system, 84.3% interrupt, 12.9% idle > CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 4: 0.0% user, 0.0% nice, 3.9% system, 86.7% interrupt, 9.4% idle > CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 6: 0.0% user, 0.0% nice, 5.5% system, 88.6% interrupt, 5.9% idle > CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 8: 0.0% user, 0.0% nice, 3.5% system, 90.2% interrupt, 6.3% idle > CPU 9: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 10: 0.0% user, 0.0% nice, 3.1% system, 87.1% interrupt, 9.8% idle > CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 12: 0.0% user, 0.0% nice, 27.5% system, 62.0% interrupt, 10.6% idle > CPU 13: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 14: 0.0% user, 0.0% nice, 6.3% system, 85.9% interrupt, 7.8% idle > CPU 15: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 16: 0.0% user, 0.0% nice, 17.6% system, 79.6% interrupt, 2.7% idle > CPU 17: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 18: 0.0% user, 0.0% nice, 2.4% system, 92.2% interrupt, 5.5% idle > CPU 19: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 20: 0.0% user, 0.0% nice, 7.8% system, 86.7% interrupt, 5.5% idle > CPU 21: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 22: 0.0% user, 0.0% nice, 6.3% system, 87.5% interrupt, 6.3% idle > CPU 23: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 24: 0.0% user, 0.0% nice, 1.6% system, 89.4% interrupt, 9.0% idle > CPU 25: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 26: 0.0% user, 0.0% nice, 2.0% system, 91.8% interrupt, 6.3% idle > CPU 27: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 28: 0.0% user, 0.0% nice, 2.7% system, 87.8% interrupt, 9.4% idle > CPU 29: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 30: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 31: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle > Mem: 17M Active, 13M Inact, 716M Wired, 61G Free > ARC: 28M Total, 6102K MFU, 20M MRU, 16K Anon, 373K Header, 1492K Other > Swap: 16G Total, 16G Free > > > # top -HSIzts1 > last pid: 2805; load averages: 13.88, 7.92, 3.56 > > up 0+00:06:40 21:00:50 > 469 processes: 45 running, 342 sleeping, 82 waiting > CPU: 0.0% user, 0.0% nice, 3.5% system, 39.3% interrupt, 57.1% idle > Mem: 17M Active, 13M Inact, 716M Wired, 61G Free > ARC: 28M Total, 6105K MFU, 20M MRU, 16K Anon, 373K Header, 1494K Other > Swap: 16G Total, 16G Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root -92 - 0K 1504K CPU22 22 3:38 87.35% > intr{irq293: ix0:que } > 12 root -92 - 0K 1504K WAIT 26 3:41 86.57% > intr{irq295: ix0:que } > 12 root -92 - 0K 1504K CPU18 18 3:41 86.47% > intr{irq291: ix0:que } > 12 root -92 - 0K 1504K CPU28 28 3:41 86.47% > intr{irq296: ix0:que } > 12 root -92 - 0K 1504K CPU24 24 3:39 86.18% > intr{irq294: ix0:que } > 12 root -92 - 0K 1504K WAIT 4 3:35 86.18% > intr{irq284: ix0:que } > 12 root -92 - 0K 1504K CPU8 8 3:35 86.18% > intr{irq286: ix0:que } > 12 root -92 - 0K 1504K CPU6 6 3:33 85.60% > intr{irq285: ix0:que } > 12 root -92 - 0K 1504K CPU20 20 3:32 85.50% > intr{irq292: ix0:que } > 12 root -92 - 0K 1504K CPU10 10 3:32 84.86% > intr{irq287: ix0:que } > 12 root -92 - 0K 1504K CPU2 2 3:32 84.67% > intr{irq283: ix0:que } > 12 root -92 - 0K 1504K WAIT 14 3:31 84.38% > intr{irq289: ix0:que } > 12 root -92 - 0K 1504K CPU16 16 3:11 77.59% > intr{irq290: ix0:que } > 12 root -92 - 0K 1504K CPU0 0 2:42 64.70% > intr{irq282: ix0:que } > 12 root -92 - 0K 1504K CPU12 12 2:44 63.67% > intr{irq288: ix0:que } > 0 root -92 0 0K 4672K - 12 1:01 26.66% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 0 0:58 23.00% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 16 0:48 18.16% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 20 0:20 7.86% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 14 0:15 5.57% > kernel{ix0 que} > 0 root -92 0 0K 4672K CPU6 6 0:14 5.57% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 22 0:12 4.59% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 18 0:06 4.59% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 28 0:06 4.49% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 26 0:06 4.39% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 24 0:05 4.05% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 8 0:09 3.47% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 4 0:08 3.17% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 10 0:07 2.98% > kernel{ix0 que} > 0 root -92 0 0K 4672K - 2 0:05 2.39% > kernel{ix0 que} > > # pmcstat -TS llc-misses -w10 > PMC: [llc-misses] Samples: 3949 (100.0%) , 0 unresolved > > %SAMP IMAGE FUNCTION CALLERS > 28.6 kernel ixgbe_rxeof ixgbe_msix_que:25.9 > ixgbe_handle_que:2.8 > 14.7 kernel bcmp netisr_dispatch_src:13.5 > rtalloc_fib_nolock:1.0 > 5.9 kernel mb_ctor_mbuf uma_zalloc_arg > 5.8 kernel ixgbe_mq_start vlan_transmit > 4.6 kernel _mtx_trylock ixgbe_mq_start > 3.8 kernel ether_nh_input netisr_dispatch_src > 2.6 kernel ether_input ixgbe_msix_que > 2.4 kernel m_tag_delete_chain m_tag_copy_chain:1.2 uma_zfree_arg:0.9 > 2.4 kernel netisr_dispatch_src ixgbe_rxeof:1.6 ixgbe_msix_que:0.6 > 2.2 kernel cpu_search_highest cpu_search_highest > 2.2 kernel ixgbe_txeof ixgbe_msix_que > 2.1 kernel uma_zfree_arg m_freem > 2.0 kernel netisr_dispatch ixgbe_msix_que:1.1 ixgbe_rxeof:0.7 > 2.0 kernel critical_exit uma_zfree_arg > 1.9 kernel _thread_lock_flags ithread_loop:1.2 > intr_event_schedule_thread:0.6 > 1.9 kernel _bus_dmamap_sync ixgbe_rxeof > 1.3 kernel ixgbe_xmit ixgbe_mq_start_locked > 0.9 kernel ixgbe_msix_que intr_event_execute_handlers > Thanks! This looks like it might be related to issues in the ixgbe driver specifically. I will test against this and other drivers in the lab. Also, did you cpuset your ixgbe interrupts to package 0? (cpu 0..7) and turn off SMT? Best, George --=_MailMate_270F14BB-B8AD-4903-9533-4BF594370719_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRayv4ACgkQYdh2wUQKM9IepQCdHcbJSzrSZn58IVXhIR+YmFZD 4V0AoOBuWbqXuwz6UDUjgnm47ZHiB6Wj =IxlB -----END PGP SIGNATURE----- --=_MailMate_270F14BB-B8AD-4903-9533-4BF594370719_=-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 01:37:58 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E045ED; Thu, 6 Nov 2014 01:37:58 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B904998; Thu, 6 Nov 2014 01:37:58 +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 sA61bppo024490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2014 17:37:51 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sA61bpNg024489; Wed, 5 Nov 2014 17:37:51 -0800 (PST) (envelope-from jmg) Date: Wed, 5 Nov 2014 17:37:51 -0800 From: John-Mark Gurney To: George Neville-Neil Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] Message-ID: <20141106013751.GJ8852@funkthat.com> Mail-Followup-To: George Neville-Neil , "Alexander V. Chernikov" , net@FreeBSD.org, Gleb Smirnoff , "Andrey V. Elsukov" References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 05 Nov 2014 17:37:51 -0800 (PST) Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:37:58 -0000 George Neville-Neil wrote this message on Wed, Nov 05, 2014 at 17:10 -0800: > On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote: > > >On 05.11.2014 19:39, George Neville-Neil wrote: > >>Howdy, > >> > >>Last night (Pacific Time) I committed a change so that GENERIC, on > >>HEAD has the netmap > >>device enabled. This is to increase the breadth of our testing of > >>that feature prior > >>to the release of FreeBSD 11. > >> > >>In two weeks I will enable IPSec by default, again in preparation for > >>11. > >Please don't. > > > >While I love to be able to use IPSEC features on unmodified GENERIC > >kernel, simply enabling > >IPSEC is not the best thing to do in terms of performance. > > > >Current IPSEC locking model is pretty complicated and is not scalable > >enough. > >It looks like it requires quite a lot of man-hours/testing to be > >reworked to achieve good performance and I'm not sure > >if making it enabled by default will help that. > > > >Current IPv4/IPv6 stack code with some locking modifications is able > >to forward 8-10MPPS on something like 2xE2660. > >I'm in process of merging these modification in "proper" way to our > >HEAD, progress can be seen in projects/routing. > >While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of other) > >changes are not there yet, you can probably get > >x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. > >2-3mpps depending on test conditions). > > > >In contrast, I haven't seen IPSEC being able to process more than > >200kpps for any kind of workload. In this workload, how many associtations are you testing? If you're testing more than a few, see the end of my email for more info.. > >What we've discussed with glebius@ and jmg@ at EuroBSDCon was to > >modify PFIL to be able to monitor/enforce > >hooks ordering and make IPSEC code usual pfil consumer. In that case, > >running GENERIC with IPSEC but w/o any SA > >won't influence packet processing path. This also simplifies the > >process of making IPSEC loadable. > > How soon do you think the pfil patch would be ready? That sounds like a > good first step > towards making all this enabled in HEAD so that we can make sure that > IPSec gets the broad > testing that it needs. > > Also, if folks who know about these problems can send workloads and test > descriptions to the > list that would be very helpful. Yes, also, a good description of how to manually set IPsec keys for testing would be good... I haven't had any luck in my testing... and I keep getting: ipsec4_common_input_cb: cannot handle inner ip proto 50 which doesn't make sense, as it should be able to handle ESP... > Specific drivers and hardware types would be most helpful as this may be > device related > as well. > > I will turn this on on some machines in the network test lab to see what > I can see. I have a patch that uses atomics instead of locks for some of the ref counting, but I belive it may suffer from the problem of not having a ref count held by the table, so I'm not sure it's ready for prime time, but it does significantly increase the PPS rate... If we are going to go high PPS and full SMP, it'll definately need a lot of work to segment lookups and the like... Also, sptree isn't a tree, it's a LIST.. The same goes for sahtree... So, if you have more than about 5 SP or SAH's, then obviously you'll have lots of fun... -- 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 Thu Nov 6 10:00:47 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A072A61; Thu, 6 Nov 2014 10:00:47 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EDD82DB; Thu, 6 Nov 2014 10:00:46 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bs8so923147wib.17 for ; Thu, 06 Nov 2014 02:00:45 -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=97c4BGBevQ6yh55mL7TNrz/cM7cmHdKT2++Y6eJ3T9Q=; b=FDa0egIqWwLFWPqKdaD6qRgwqUmv/Uau1AM04W5TwAUc7fLH+YCIik+6xQg8+iKTtV E1VmCOt2oA1kbAJRYL4k+TlGBIGFYYEP1wIZJm5h6irh8sI9kYOz2OF7sm8aFnT1wx9/ 8F3Se53ypqPpENZa9MIhnu0Z5Gruoh/vi7wW3DBTY8qi9EyQraWVN+GK2VE1ExWM02Fm ODfQNgqd2gjpXbFfjn4Zdtg72ByPFp9Nuv+ENogl43gZdqOqaZgwZfUGy5pMIpkqujQ4 MgvMopiVO68Je3qeUa0peH1HzUYkC0EjnP82wDzYS9RtwEJf7F6rwIVPUW2QEecaS1t0 GFOQ== X-Received: by 10.181.5.6 with SMTP id ci6mr13013943wid.35.1415268044890; Thu, 06 Nov 2014 02:00:44 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.164.73 with HTTP; Thu, 6 Nov 2014 02:00:24 -0800 (PST) In-Reply-To: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 6 Nov 2014 11:00:24 +0100 X-Google-Sender-Auth: gc2gT6JDrUAYmktWB7bVZ-3xLcE Message-ID: Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Andrey V. Elsukov" , John-Mark Gurney , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 10:00:47 -0000 How to correctly bench IPSec performance ? For benching forwarding performance I generate minimum-size packet (2000 flows: 100 different source IP * 20 different destination IP) like with this netmap's pkt-gen example: pkt-gen -i ix0 -f tx -n 1000000000 -l 60 -d 9.1.1.1:2000-9.1.1.100 -s 8.1.1.1:2000-8.1.1.20 => This permit me to obtain the maximum PPS forwarded by the server. But for benching IPSec: Is the PPS with minimum-size packet a useful value ? From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 11:46:25 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69EB4D46; Thu, 6 Nov 2014 11:46:25 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AEE6CE; Thu, 6 Nov 2014 11:46:24 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5534125D3A82; Thu, 6 Nov 2014 11:46:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 703B1C76FDE; Thu, 6 Nov 2014 11:46:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id qaRTM3d2O54a; Thu, 6 Nov 2014 11:46:10 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 13BCCC76FD9; Thu, 6 Nov 2014 11:46:08 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] From: "Bjoern A. Zeeb" In-Reply-To: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> Date: Thu, 6 Nov 2014 11:46:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <65C48D3B-0C08-4F8F-AF19-239238E49E62@FreeBSD.org> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> To: George Neville-Neil X-Mailer: Apple Mail (2.1878.6) Cc: "Alexander V. Chernikov" , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 11:46:25 -0000 On 06 Nov 2014, at 01:10 , George Neville-Neil = wrote: > On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote: >=20 >> On 05.11.2014 19:39, George Neville-Neil wrote: >>> Howdy, >>>=20 >>> Last night (Pacific Time) I committed a change so that GENERIC, on = HEAD has the netmap >>> device enabled. This is to increase the breadth of our testing of = that feature prior >>> to the release of FreeBSD 11. >>>=20 >>> In two weeks I will enable IPSec by default, again in preparation = for 11. >> Please don't. >>=20 >> While I love to be able to use IPSEC features on unmodified GENERIC = kernel, simply enabling >> IPSEC is not the best thing to do in terms of performance. >>=20 >> Current IPSEC locking model is pretty complicated and is not scalable = enough. >> It looks like it requires quite a lot of man-hours/testing to be = reworked to achieve good performance and I'm not sure >> if making it enabled by default will help that. >>=20 >> Current IPv4/IPv6 stack code with some locking modifications is able = to forward 8-10MPPS on something like 2xE2660. >> I'm in process of merging these modification in "proper" way to our = HEAD, progress can be seen in projects/routing. >> While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of = other) changes are not there yet, you can probably get >> x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. = 2-3mpps depending on test conditions). >>=20 >> In contrast, I haven't seen IPSEC being able to process more than = 200kpps for any kind of workload. >>=20 >> What we've discussed with glebius@ and jmg@ at EuroBSDCon was to = modify PFIL to be able to monitor/enforce >> hooks ordering and make IPSEC code usual pfil consumer. In that case, = running GENERIC with IPSEC but w/o any SA >> won't influence packet processing path. This also simplifies the = process of making IPSEC loadable. >>=20 >=20 > How soon do you think the pfil patch would be ready? That sounds like = a good first step > towards making all this enabled in HEAD so that we can make sure that = IPSec gets the broad > testing that it needs. I don=92t think making IPsec an pfil consumer is actually feasible but = that=92s a different story. > Also, if folks who know about these problems can send workloads and = test descriptions to the > list that would be very helpful. >=20 > Specific drivers and hardware types would be most helpful as this may = be device related > as well. >=20 > I will turn this on on some machines in the network test lab to see = what I can see. What you would want for the moment is a single read-mostly = (read-lockless, read-non-atomic) integer that tells you if you have any = policy in the system; that=92s for your branch statement. That=92s = probably the closest you can get to enabling it cheaply in GENERIC = without doing much. There=92s a tradeoff in that for a few packets the policy might not be = effective immediately but given the amount of time it takes to =93install=94= the policy thinking about any instant real-time guarantees here is not = feasible anyway. Just my 2cts. Bjoern From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 14:46:47 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4908B25; Thu, 6 Nov 2014 14:46:47 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E57B913; Thu, 6 Nov 2014 14:46:47 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so1718287wiw.6 for ; Thu, 06 Nov 2014 06:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BBwMQ0Q1ZpIcZMQMZp7lwpjK7Q+ICsnOGRC1sUB8550=; b=C6ynZA19ijAkKUelSik5Uu76SL0FnjqdS3pvH8uo6C9SBFPW3PHPULtKpvKuPQyYOQ y3Ezy83e1g0u/AePI+55p1ieA6gK0PNYbah1ubu8ymyOG9O2s3HEMxwiiphwQRY8ignL yGY+fLYuStHNNHEnvO6vSAI7Un3s50NNev1WjrDMjYLzuQJTrd6tOh70hnpwVqHXaNFx NICZRtBykpw4S5ChOyBoLsvtTJwGILOSYesprkujmmz4SYKcwtfs4dgm7NdJCbeFdhzW bgW3Xz8cXdyNHkS10kGJElnJ+cXY+zDCvtoiN69OUXLzrxrxHVmyebL6wu8tjD4/leFq XZMQ== X-Received: by 10.180.14.165 with SMTP id q5mr7326032wic.0.1415285204571; Thu, 06 Nov 2014 06:46:44 -0800 (PST) Received: from [192.168.2.30] ([2.176.144.74]) by mx.google.com with ESMTPSA id b6sm8540644wiy.22.2014.11.06.06.46.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 06:46:43 -0800 (PST) Message-ID: <545B89DC.2090305@gmail.com> Date: Thu, 06 Nov 2014 18:16:52 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , John-Mark Gurney , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 14:46:47 -0000 On 11/6/2014 1:30 PM, Olivier Cochard-Labbé wrote: > How to correctly bench IPSec performance ? > > For benching forwarding performance I generate minimum-size packet (2000 > flows: 100 different source IP * 20 different destination IP) like with > this netmap's pkt-gen example: > pkt-gen -i ix0 -f tx -n 1000000000 -l 60 -d 9.1.1.1:2000-9.1.1.100 > -s 8.1.1.1:2000-8.1.1.20 > > => This permit me to obtain the maximum PPS forwarded by the server. May be off-topic: How much PPS and on which hardware? > > But for benching IPSec: Is the PPS with minimum-size packet a useful value ? > _______________________________________________ > 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" -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 15:23:04 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB7C85A0; Thu, 6 Nov 2014 15:23:04 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 574A8D2B; Thu, 6 Nov 2014 15:23:04 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id r20so1762501wiv.5 for ; Thu, 06 Nov 2014 07:23: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:from:date:message-id :subject:to:cc:content-type; bh=e2x4DaxKpjw+8DS/X+T4ZpctDxaav11Z1lJ9hmDynj0=; b=hC8iJe2d2oYT+PG4yqd/5DOay5vV3gSQbnnCAUrt/TaCGaT+e1ooNULHY/exUXk5CM IWle7zTL7w6Eq5Od9KHdwbWhyF6EoWLcQGQNjWP5zgswKanDnbQ/HcFj1HP/d3JL0fCV 7vG1itFs34Ekdg7XFmnpudFUnPt/wllTy5kBscl+P50RLrIn2G4SlKOjFdt4VMd2S/0M grmh0bBKZ8sibYpj6VaxU47vRDBw6JBuHbTr+ImHshXe8chGRL/PfbTMN+tP0hfuovfw YiBnS6n21suNGSU+tli3i08LIB6eLftKugNrdAGgFVvGZ80Sme+chujzGb2IY5gURe4Q a+6w== X-Received: by 10.180.82.170 with SMTP id j10mr42463495wiy.35.1415287382733; Thu, 06 Nov 2014 07:23:02 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.164.73 with HTTP; Thu, 6 Nov 2014 07:22:42 -0800 (PST) In-Reply-To: <545B89DC.2090305@gmail.com> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> <545B89DC.2090305@gmail.com> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 6 Nov 2014 16:22:42 +0100 X-Google-Sender-Auth: BPE1rMol9D5NmjmSeQEW78vymBA Message-ID: Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Andrey V. Elsukov" , "Alexander V. Chernikov" , John-Mark Gurney , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 15:23:05 -0000 On Thu, Nov 6, 2014 at 3:46 PM, Hooman Fazaeli wrote: > > => This permit me to obtain the maximum PPS forwarded by the server. >> > May be off-topic: How much PPS and on which hardware? > It seems I'm not clear: My question is just "What is the correct methodology for benching IPSec performance ?" There is a RFC 2544 and RFC 3222 that explain methodologies for benching routers (packet forwarding) and RFC 3511 for benching firewall... but what about IPSec ? I didn't see any impact by enabling IPSec on the kernel (just enabling and not using it) on my benchs, but others people measured huge impact: Then my methodology is wrong. This is why I would to know if we could define a reproducible methodology for "benching IPSec" (packet size distribution, number of SA/SP, etc...). From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 17:38:17 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B082E159 for ; Thu, 6 Nov 2014 17:38:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97C76E96 for ; Thu, 6 Nov 2014 17:38:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA6HcHcu014327 for ; Thu, 6 Nov 2014 17:38:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 164475] [gre] gre misses RUNNING flag after a reboot Date: Thu, 06 Nov 2014 17:38:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 17:38:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=164475 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 21:22:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 037576B for ; Thu, 6 Nov 2014 21:22:19 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADA92BA3 for ; Thu, 6 Nov 2014 21:22:18 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id bm13so1439557qab.9 for ; Thu, 06 Nov 2014 13:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=rwDc2A+8pTZJCK6fRlx0uIoqkFImEvMXJh3ml3FQlDw=; b=gnJfPSSHH5U798447bS9sRhlAPhPQYXxISbFhAaTDo4YMfYy0n/yG14vtKrZNZitn8 6pMaih67vqxHSe3xczLISp76MjY/MwCipFF/VScPOx3QiQsyt9upifo/BuUddN8KpSA2 LFDYS8z7BCRcj/ppwjYKd7xKrhqTL6reUtTNSwOHpxfh0pIx0D4Z7hkU3CspdHWVCqgs 7xJb02VXJTQjHSPL6ctkkoNlOf+McwJLkFmE0GgnKojTjWMF6P/1LWrP3JpdfSfmJntO UI/R2Ab882/9QY+IBOn1tUGTBWBBLYsUtbwM6vEm2DZVAyMfXV652dycQWA0pGfjrUoO FMjQ== X-Received: by 10.229.236.197 with SMTP id kl5mr11088471qcb.31.1415308937913; Thu, 06 Nov 2014 13:22:17 -0800 (PST) Received: from dante.portari.intra ([201.91.194.178]) by mx.google.com with ESMTPSA id q8sm6843311qai.44.2014.11.06.13.22.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 13:22:17 -0800 (PST) Message-ID: <545BE687.3070506@gmail.com> Date: Thu, 06 Nov 2014 19:22:15 -0200 From: =?UTF-8?B?IkRhbnRlIEYuIEIuIENvbMOyIg==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Static routes issue Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:22:19 -0000 Hello everyone I'm trying to setup some static routes on a freebsd box for some public addresses , the machine has two ethernet cards *em0 *and *em1 ***, *em0* is attached to a Cisco internet router and *em1* is connected to a switch, both interfaces have public addresses of the same range , *em1 *appears has absolutely no communication , i took a look at the static routes and there is a route for the subnet that it goes to *em0* , i'm trying to add a static route for the ip address pointing to the***em1 *without pass gateway using *-iface* parameter but always returns "Network unreachble", someone can help me or give some tips to address this ? for many here this is probably a nooby question, we also have some firewall Linux boxes that i'm gonna migrate to freebsd (also trying on openbsd with the same problem) but first i have to solve this. Best Regards Dante F. B. Colò From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 21:26: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9687213 for ; Thu, 6 Nov 2014 21:26:52 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E0ABF2 for ; Thu, 6 Nov 2014 21:26:52 +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 sA6LQp2N039147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2014 13:26:51 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sA6LQpYT039146; Thu, 6 Nov 2014 13:26:51 -0800 (PST) (envelope-from jmg) Date: Thu, 6 Nov 2014 13:26:51 -0800 From: John-Mark Gurney To: Dante =?iso-8859-1?Q?F=2E_B=2E_Col=F2?= Subject: Re: Static routes issue Message-ID: <20141106212651.GK24601@funkthat.com> Mail-Followup-To: Dante =?iso-8859-1?Q?F=2E_B=2E_Col=F2?= , freebsd-net@freebsd.org References: <545BE687.3070506@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545BE687.3070506@gmail.com> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 06 Nov 2014 13:26:52 -0800 (PST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:26:52 -0000 "Dante F. B. Col" wrote this message on Thu, Nov 06, 2014 at 19:22 -0200: > I'm trying to setup some static routes on a freebsd box for some public > addresses , the machine has two ethernet cards *em0 *and *em1 ***, *em0* > is attached to a Cisco internet router and *em1* is connected to a > switch, both interfaces have public addresses of the same range , *em1 > *appears has absolutely no communication , i took a look at the static > routes and there is a route for the subnet that it goes to *em0* , i'm > trying to add a static route for the ip address pointing to the***em1 > *without pass gateway using *-iface* parameter but always returns > "Network unreachble", someone can help me or give some tips to address > this ? for many here this is probably a nooby question, we also have > some firewall Linux boxes that i'm gonna migrate to freebsd (also trying > on openbsd with the same problem) but first i have to solve this. Sounds like you're looking for multipath routing... This requires the kernel to be recompiled w/ the option RADIX_MPATH.. By default, FreeBSD does not support having the same route to two different interfaces.. Hope this helps... -- 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 Thu Nov 6 22:27:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54DAE43A for ; Thu, 6 Nov 2014 22:27:03 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1936402 for ; Thu, 6 Nov 2014 22:27:02 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so2920909wid.8 for ; Thu, 06 Nov 2014 14:27:01 -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=YU8GVhH7d68U22fkDJUx09yb/8hFbpAydMGNRWge0Vg=; b=nrqK/Np4UuGJ1MOf4Uz1FxM4BOwT5rXNUhIaSDswXv51NOJxozQl3okR84BDtADSKi fbdxkhszRFHRvYcEJeg31kHGQ2aS2YhKGWtlDhrsPqt4dBXSr10MPyao36k1of/BXMnZ okEwH6xEp7HxaSA9ExkQVQs83nNxSnWCG86deWKJzQzUMF0JBKjaTEsME4s78vgrQuGt br0TP0iddQnNikYcmJjyXk5IIw3MqJ9IVnfksSMOvTbQKjeTEZ0GiSns5IjbUfUE1UOL Sx6/ak7SzozQVoMK7pswJn5mimQ5srzbz68oRYo12SNyAUUYlXb/tsGYOoglTZ5Y8sFA t47g== MIME-Version: 1.0 X-Received: by 10.194.206.36 with SMTP id ll4mr10051042wjc.21.1415312821235; Thu, 06 Nov 2014 14:27:01 -0800 (PST) Received: by 10.217.92.7 with HTTP; Thu, 6 Nov 2014 14:27:01 -0800 (PST) In-Reply-To: References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Thu, 6 Nov 2014 20:27:01 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 22:27:03 -0000 On Wed, Nov 5, 2014 at 10:40 PM, Evandro Nunes wrote: > On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli < > eksffa@freebsdbrasil.com.br> wrote: > >> Hey, what you are doing wrong is much more simple than you expect. >> >> > # ./kipfw em1 em2 > & /tmp/kipfw.log & >> > [1] 66583 >> >> Just run ./kipfw netmap:em1 netmap:em2 and this will probably work. >> >> Please remember to redirect kipfw output to somewhere you are not readin= g >> only *after* you are sure the output is showing errors. If you could rea= d >> the output you would probably get something like =E2=80=9Cerror opening = em0=E2=80=9D or >> something like that coming netmap. >> > > hello dear patrick > thank you, yes it did work now > at least it is counting packets > > but things are still weird, even though I have only count and allow rules= , > and yes they are counting packets, when I run kipfw, every packet on em1 > and em2 gets dropped immediately. no matter they are allow rules counting > packets, packets get dropped and machine-A gets completely isolated from > machine-C > > any further help is appreciated > hello everybody, one clear and simple question: is anyone actually using netmap-ipfw on real NICs out there? or has anyone ever used? because every documentation I read, or video I watch, is based on vale NICs, not real ones; documentation is also not clear about or in fact existant regarding real NICs (this is not a complaint, I know netmap-ipfw is experimental and I dont expect it to be rich yet, but I am talking about any sort of doc, readme files, commit messages, mailing list excerpts...), not even the syntax netmap:NIC was clearly mentioned before I was told to do that I read the guy from BSDRP Project mentioning he got down on traffic after enabling netmap-ipfw, I have read the same thing from a guy mr Meyer, and from a couple others in different dates (but mostly in this list here) and everyone seem to gave given up. I started looking at the source code for extras/ and stuff but I am no hacker, and I could not figure out what I could be doing wrong. This is why I ask if anyone actually runs netmap-ipfw on real NICs. Im not asking for a recipe, Im just trying to figure out if I am focusing on testing something that will never work because it lacks a usable piece of code to make it run on real NICs (and I am not capable of coding it myself), or if I still doing something wrong... using netmap-ipfw with VALE ports is shows a very different behavior and works as expected and documented, not on real NICs has a complete different behavior, dropping everything even though it counts packets on an "allow" rule... From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 23:01:45 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 441ED287 for ; Thu, 6 Nov 2014 23:01:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A3F9AE8 for ; Thu, 6 Nov 2014 23:01:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA6N1jlu020120 for ; Thu, 6 Nov 2014 23:01:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194872] [netmap] documentation for bridge/pkt-gen doesn't mention the updated interface format (netmap:X, vale:X) nor how to configure a specific ring Date: Thu, 06 Nov 2014 23:01:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:01:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194872 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 23:24:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 449EFD92 for ; Thu, 6 Nov 2014 23:24:40 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF05CD89 for ; Thu, 6 Nov 2014 23:24:39 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bs8so3025404wib.11 for ; Thu, 06 Nov 2014 15:24: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:date:message-id:subject :from:to:cc:content-type; bh=PrSRhzHbpoYpoGZecpdbLHiZMBdx4ydI3+Lettq3TUc=; b=rRXwy6S4t+f/7gpec2xm1V5OG2KgweiBKn61unA9smJEWdB7Na4JKdH6I+BjXEb7WH oiS+1OZUaCx1WraZumzz/jEE67hPfdj8MaKHnK9w7hitQzy26u9U6Mgn98O61hHIAjK0 0y3zs8WmSIzPF9IRwGWLWnihibNtYyuFU5npQBSwv/J6Tc8qNSRmxzcpy2FA6Z0eEQIG 1b8SYdqPdGeEVOQ2d5zREeuNLa3SM1XkSWi11oQlJ7ELEslkPwREM2BEub4XHH46s9EI /cQmnhuZScAN64dDBFfXRAZNONZfYIU0/JmXA3BdlLOLJ7YK4vFiyGT80PJkznLYYXvb NWng== MIME-Version: 1.0 X-Received: by 10.194.103.230 with SMTP id fz6mr10306446wjb.53.1415316278178; Thu, 06 Nov 2014 15:24:38 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Thu, 6 Nov 2014 15:24:37 -0800 (PST) In-Reply-To: References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Thu, 6 Nov 2014 15:24:37 -0800 X-Google-Sender-Auth: 8qorATxWELKdV4UXQ5QwXgSs6rA Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:24:40 -0000 The code on code.google.com/p/netmap-ipfw/ works well for me on physical interfaces. For using the nics many of your examples show that you are not using the various programs correctly. There is clearly a mismatch between what this code does and your expectations, and there isn't much i can do to fix that. I acknowledge that the code might have rough edges and poor error reporting, but it is what it is. cheers luigi On Thu, Nov 6, 2014 at 2:27 PM, Evandro Nunes wrote: > On Wed, Nov 5, 2014 at 10:40 PM, Evandro Nunes > wrote: > >> On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli < >> eksffa@freebsdbrasil.com.br> wrote: >> >>> Hey, what you are doing wrong is much more simple than you expect. >>> >>> > # ./kipfw em1 em2 > & /tmp/kipfw.log & >>> > [1] 66583 >>> >>> Just run ./kipfw netmap:em1 netmap:em2 and this will probably work. >>> >>> Please remember to redirect kipfw output to somewhere you are not >>> reading only *after* you are sure the output is showing errors. If you >>> could read the output you would probably get something like =E2=80=9Cer= ror opening >>> em0=E2=80=9D or something like that coming netmap. >>> >> >> hello dear patrick >> thank you, yes it did work now >> at least it is counting packets >> >> but things are still weird, even though I have only count and allow >> rules, and yes they are counting packets, when I run kipfw, every packet= on >> em1 and em2 gets dropped immediately. no matter they are allow rules >> counting packets, packets get dropped and machine-A gets completely >> isolated from machine-C >> >> any further help is appreciated >> > > > hello everybody, > > one clear and simple question: is anyone actually using netmap-ipfw on > real NICs out there? or has anyone ever used? > > because every documentation I read, or video I watch, is based on vale > NICs, not real ones; documentation is also not clear about or in fact > existant regarding real NICs (this is not a complaint, I know netmap-ipfw > is experimental and I dont expect it to be rich yet, but I am talking abo= ut > any sort of doc, readme files, commit messages, mailing list excerpts...)= , > not even the syntax netmap:NIC was clearly mentioned before I was told to > do that > > I read the guy from BSDRP Project mentioning he got down on traffic after > enabling netmap-ipfw, I have read the same thing from a guy mr Meyer, and > from a couple others in different dates (but mostly in this list here) an= d > everyone seem to gave given up. > > I started looking at the source code for extras/ and stuff but I am no > hacker, and I could not figure out what I could be doing wrong. This is w= hy > I ask if anyone actually runs netmap-ipfw on real NICs. Im not asking for= a > recipe, Im just trying to figure out if I am focusing on testing somethin= g > that will never work because it lacks a usable piece of code to make it r= un > on real NICs (and I am not capable of coding it myself), or if I still > doing something wrong... > > using netmap-ipfw with VALE ports is shows a very different behavior and > works as expected and documented, not on real NICs has a complete differe= nt > behavior, dropping everything even though it counts packets on an "allow" > rule... > > > > > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 08:20:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04990A88 for ; Fri, 7 Nov 2014 08:20:19 +0000 (UTC) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B068CB05 for ; Fri, 7 Nov 2014 08:20:18 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id la4so1485256vcb.37 for ; Fri, 07 Nov 2014 00:20:17 -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=mRiyEnXoWexPNnZSBo8Ad1/oQlwYp5fAuNVNW+NKSog=; b=wT4A760SFIHrAMVNK86Ri78BIH2KzSuOWQ3IvGc5TgoAULS/9CnrgOeyoWWbyl4arg NtPan8/f/qz9ZYuodA57DkahDORKCu2Z1QzaMxgPrK6LzuXVdHANJM4k0vohgUTcdhoB BkA3q9Djcuf3hg1RSp0IDh7pgXoy61c7sB5ejujc+Wt2c9Jcyo2eqdNBqTsdVVQrwSq6 zE5roZbUubl1vRsngH+XapG+OOS3HslJ5hcBdhNIlXIcabpOT9ao+HyXl2Tz2j24gFEL LsLCDeG7m+OuiUf3ShaQuMUYeF9S1hO9clDOa9S4gFxnvxQ/rmzlzi5dmf7asvwuGIuV Cdgg== MIME-Version: 1.0 X-Received: by 10.220.128.71 with SMTP id j7mr6754716vcs.22.1415348417420; Fri, 07 Nov 2014 00:20:17 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 00:20:17 -0800 (PST) In-Reply-To: <20141106135228.GE3824@nymity.ch> References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 03:20:17 -0500 Message-ID: Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) From: grarpamp To: tor-relays@lists.torproject.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 08:20:19 -0000 On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: > On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: >> 173 FreeBSD > > FreeBSD still seems to use globally incrementing IP IDs by default. > That's an issue as it leaks fine-grained information about how many > packets a relay's networking stack processes. (However, nobody > investigated the exact impact on Tor relays so far, which makes this a > FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD > relays I tested (38%) use global IP IDs. > > There's a sysctl variable called "net.inet.ip.random_id" which makes a > FreeBSD's IP ID behaviour random. FreeBSD relay operators should set > this to "1". > > Note that this issue was already discussed earlier this year in a thread > called "Lots of tor relays send out sequential IP IDs; please fix > that!". It's been default off since before it was a sysctl over a decade ago. Anyone know what the deal is with that? Some objection, or forgotten flag day, or oversight that really should be set to 1? https://svnweb.freebsd.org/base?view=revision&revision=133720 From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 09:33:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4180CCE6; Fri, 7 Nov 2014 09:33:31 +0000 (UTC) Received: from gw.zefyris.com (sabik.zefyris.com [IPv6:2001:7a8:3c67:2::254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC59238D; Fri, 7 Nov 2014 09:33:30 +0000 (UTC) Received: from sekishi.zefyris.com (sekishi.zefyris.com [IPv6:2001:7a8:3c67:2::12]) by gw.zefyris.com (8.14.5/8.14.5) with ESMTP id sA793aC9258329; Fri, 7 Nov 2014 10:04:06 +0100 (CET) Date: Fri, 7 Nov 2014 10:03:36 +0100 From: Francois Tigeot To: "Alexander V. Chernikov" Subject: Re: faith(4) / faithd(8) removal Message-ID: <20141107090334.GA673044@sekishi.zefyris.com> References: <544E2FA4.8080003@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544E2FA4.8080003@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gw.zefyris.com [IPv6:2001:7a8:3c67:2::254]); Fri, 07 Nov 2014 10:04:06 +0100 (CET) Cc: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 09:33:31 -0000 Hi, On Mon, Oct 27, 2014 at 03:42:28PM +0400, Alexander V. Chernikov wrote: > > I'd like to remove faith (IPv6/v4 translator) from base. Another data point: http://www.litech.org/ptrtd/ This project was similar to faith; the last release was in 2002 and it has been officially declared dead in 2010. The authors themselves recommend to use NAT64 instead. I'm pretty sure you can safely remove faith from base. -- Francois Tigeot From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 12:33:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D2BBE3C for ; Fri, 7 Nov 2014 12:33:57 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1971C62 for ; Fri, 7 Nov 2014 12:33:56 +0000 (UTC) Received: from [89.204.138.158] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xmijc-0000WY-0D; Fri, 07 Nov 2014 13:33:48 +0100 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id sA7CXjVV008784; Fri, 7 Nov 2014 13:33:46 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id sA7CXhRL008780; Fri, 7 Nov 2014 13:33:43 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Fri, 7 Nov 2014 13:33:43 +0100 From: Matthias Apitz To: freebsd-net@freebsd.org Subject: IPv6 link-local addr && %interfacename Message-ID: <20141107123343.GA8713@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.138.158 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 12:33:57 -0000 Hi, I have a small question re/ the IPv6 link-local address; I configured IPv6 in my 11-CURRENT with: /etc/rc.conf: ifconfig_em0_ipv6="inet6 accept_rtadv" rtsold_enable="YES" The em0 interface now looks like this: # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:47:a3:8d inet6 fe80::20c:29ff:fe47:a38d%em0 prefixlen 64 scopeid 0x1 inet 192.168.56.131 netmask 0xffffff00 broadcast 192.168.56.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active I have a small C-written test client which connects to port 22 to the addr given in argv1, reads one line (in our case the GM message of the sshd) and prints it: $ ./ipv6-client ::1 host: ::1 read: SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 it does not work with the link-local addr: $ ./ipv6-client fe80::20c:29ff:fe47:a38d host: fe80::20c:29ff:fe47:a38d ssh: connect: Network is unreachable but with appending %em0 it does work: $ ./ipv6-client fe80::20c:29ff:fe47:a38d%em0 host: fe80::20c:29ff:fe47:a38d%em0 read: SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 My question is: What does the %em0 mean in the IPv6 addr and why it is not working without it? The failing sys call is the connect(2): ... socket(PF_INET6,SOCK_STREAM,6) = 3 (0x3) connect(3,{ AF_INET6 [fe80::20c:29ff:fe47:a38d]:22 },28) ERR#51 'Network is unreachable' I consulted the handbook and the RFC: https://www.freebsd.org/doc/handbook/network-ipv6.html http://www.ietf.org/rfc/rfc3513.txt Both do not give any explanation re/ the %interface value. Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 13:01: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF7A065F for ; Fri, 7 Nov 2014 13:01:04 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 07166F76 for ; Fri, 7 Nov 2014 13:01:03 +0000 (UTC) Received: (qmail 98465 invoked from network); 7 Nov 2014 12:54:19 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 7 Nov 2014 12:54:19 -0000 Date: Fri, 07 Nov 2014 13:54:19 +0100 (CET) Message-Id: <20141107.135419.41700845.sthaug@nethelp.no> To: guru@unixarea.de Subject: Re: IPv6 link-local addr && %interfacename From: sthaug@nethelp.no In-Reply-To: <20141107123343.GA8713@unixarea.DDR.dd> References: <20141107123343.GA8713@unixarea.DDR.dd> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:01:04 -0000 > it does not work with the link-local addr: > > $ ./ipv6-client fe80::20c:29ff:fe47:a38d > host: fe80::20c:29ff:fe47:a38d > ssh: connect: Network is unreachable This is expected. > but with appending %em0 it does work: > > $ ./ipv6-client fe80::20c:29ff:fe47:a38d%em0 > host: fe80::20c:29ff:fe47:a38d%em0 > read: SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 > > My question is: What does the %em0 mean in the IPv6 addr and why it is > not working without it? A link-local address is *link-local* and needs the interface specifier to be unique. The same address can be configured on several interfaces. In principle you could use fe80::1 as the link local address for *all* of your Ethernet interfaces... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 13:02: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28347714 for ; Fri, 7 Nov 2014 13:02:14 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DF6AF9E for ; Fri, 7 Nov 2014 13:02:13 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id z12so3606087wgg.9 for ; Fri, 07 Nov 2014 05:02:10 -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=wI0P48+4N9HvYnu6pTrAnI/jP4mIX7dtlXtqtaXO8+U=; b=VBaCsPrn+Dpd+catIbc0jcOJUbfmWuh8yv3RqvLpDqF045xEBJJ+UZarKsJf5BvD2r ZF+3FMSUo+VhZT+Rr2iD0Z54vxauyNx+HhIzEEZ7bHFU9ZOfV/IXx5exydjaoda2nMvl iO/KwpwsqFi4Fv4U6ItYy6PKheKZiQDfpaAIu6Bh8nzFInZGJgGcVmOV4k85i0QAWydw Do1UP+Jhvl5nt1MIV6yuZwvlDwIINc1y3tp4ELTsDZkqqK0cxpvVxfxnCpCGIKbWlq7v ntOKxwDExiYo3Wl8lVFZdNa8RJPNwiqdLZfG4t28NcMvceQXO4hpRBFZ9wkpN5/bBl6o WjFA== MIME-Version: 1.0 X-Received: by 10.181.8.72 with SMTP id di8mr14246637wid.1.1415365328798; Fri, 07 Nov 2014 05:02:08 -0800 (PST) Received: by 10.217.92.7 with HTTP; Fri, 7 Nov 2014 05:02:08 -0800 (PST) In-Reply-To: References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Fri, 7 Nov 2014 11:02:08 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:02:14 -0000 On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote: > The code on code.google.com/p/netmap-ipfw/ works well for me > on physical interfaces. > > For using the nics many of your examples show that you are not using the > various programs correctly. There is clearly a > mismatch between what this code does and your expectations, > and there isn't much i can do to fix that. > > I acknowledge that the code might have rough edges and poor error > reporting, but it is what it is. > > cheers > luigi > dear Luigi, do you run with em(4) driver? do you mind point out where I could read additional info on how to netmap-ipfw filter a traffic flow between 2 real boxes? I would love to read further details on netmap filtering on real NICs, because the default info is about vale: ports and not netmap: ports and yes, for vale ports it works very nice > > > On Thu, Nov 6, 2014 at 2:27 PM, Evandro Nunes > wrote: > >> On Wed, Nov 5, 2014 at 10:40 PM, Evandro Nunes >> wrote: >> >>> On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli < >>> eksffa@freebsdbrasil.com.br> wrote: >>> >>>> Hey, what you are doing wrong is much more simple than you expect. >>>> >>>> > # ./kipfw em1 em2 > & /tmp/kipfw.log & >>>> > [1] 66583 >>>> >>>> Just run ./kipfw netmap:em1 netmap:em2 and this will probably work. >>>> >>>> Please remember to redirect kipfw output to somewhere you are not >>>> reading only *after* you are sure the output is showing errors. If you >>>> could read the output you would probably get something like =E2=80=9Ce= rror opening >>>> em0=E2=80=9D or something like that coming netmap. >>>> >>> >>> hello dear patrick >>> thank you, yes it did work now >>> at least it is counting packets >>> >>> but things are still weird, even though I have only count and allow >>> rules, and yes they are counting packets, when I run kipfw, every packe= t on >>> em1 and em2 gets dropped immediately. no matter they are allow rules >>> counting packets, packets get dropped and machine-A gets completely >>> isolated from machine-C >>> >>> any further help is appreciated >>> >> >> >> hello everybody, >> >> one clear and simple question: is anyone actually using netmap-ipfw on >> real NICs out there? or has anyone ever used? >> >> because every documentation I read, or video I watch, is based on vale >> NICs, not real ones; documentation is also not clear about or in fact >> existant regarding real NICs (this is not a complaint, I know netmap-ipf= w >> is experimental and I dont expect it to be rich yet, but I am talking ab= out >> any sort of doc, readme files, commit messages, mailing list excerpts...= ), >> not even the syntax netmap:NIC was clearly mentioned before I was told t= o >> do that >> >> I read the guy from BSDRP Project mentioning he got down on traffic afte= r >> enabling netmap-ipfw, I have read the same thing from a guy mr Meyer, an= d >> from a couple others in different dates (but mostly in this list here) a= nd >> everyone seem to gave given up. >> >> I started looking at the source code for extras/ and stuff but I am no >> hacker, and I could not figure out what I could be doing wrong. This is = why >> I ask if anyone actually runs netmap-ipfw on real NICs. Im not asking fo= r a >> recipe, Im just trying to figure out if I am focusing on testing somethi= ng >> that will never work because it lacks a usable piece of code to make it = run >> on real NICs (and I am not capable of coding it myself), or if I still >> doing something wrong... >> >> using netmap-ipfw with VALE ports is shows a very different behavior and >> works as expected and documented, not on real NICs has a complete differ= ent >> behavior, dropping everything even though it counts packets on an "allow= " >> rule... >> >> >> >> >> > > > -- > -----------------------------------------+------------------------------- > 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 Fri Nov 7 13:31:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C55EEC2; Fri, 7 Nov 2014 13:31:06 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0FD237C; Fri, 7 Nov 2014 13:31:05 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id A2618E20C; Fri, 7 Nov 2014 14:31:01 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 9F75D2D1C; Fri, 7 Nov 2014 14:31:01 +0100 (CET) Date: Fri, 7 Nov 2014 14:31:01 +0100 From: Kristof Provost To: Ilya Bakulin Subject: Re: Checksumming outgoing packets in PF vs in ip[6]_output Message-ID: <20141107133101.GF2044@vega.codepro.be> References: <1415210423.3394438.187470637.21CD8D3D@webmail.messagingengine.com> <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9355b23f1a07008eca61f16ebd828d0b@mail.bakulin.de> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 13:31:06 -0000 On 2014-11-05 19:11:55 (+0100), Ilya Bakulin wrote: > On 2014-11-05 19:00, Mark Felder wrote: > > Now if we could only stamp out the bug with ipv6 fragment and pf I'd be > > a happy, happy daemon. :-) > > This is somewhat more complex problem, I'll take a look as the time > allows. > I've been playing with it too. I have a patch which seems to be working, but it currently drops the distinction between PFRULE_FRAGCROP and PFRULE_FRAGDROP. OpenBSD dropped that a while ago, but I figured FreeBSD wouldn't want user-visible changes. I've been meaning to look at that some more but ... ENOTIME. It's tentatively planned as a project for Chaos Congress (end of December), but no promises. If you like I can probably dig up the (non-clean) patches for you. Regards, Kristof From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 16:03:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DE791B5 for ; Fri, 7 Nov 2014 16:03:52 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A32ED9A4 for ; Fri, 7 Nov 2014 16:03:51 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so4094520wgg.32 for ; Fri, 07 Nov 2014 08:03:49 -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:content-type; bh=1bMSel8QX3Ihn7eNM0Qe41m/HZReCfXnxMwJQpj+iWk=; b=mk25QlNlgy6FH7lCCuyNyDDzPY6LjHSiVQ8U7L/VPu/rN4LPUt8DQxogvgApalvgfS wNHsnkOZMjEBGSpi5F81WpPUh+b7qRoqE4RVx/95pTLBtivXBLCyiwjfZaLWoGm50usr NUOft/ia5gIhCuSIc+jhGMpWv5Xb1Dr73fcJX5vn/g2qF9isCs4/CuP/zNFb0B4cKWhT SbljedcClQ8xA8lg77y2Q3wCwqMuLk36Y0lgwtGZMHoCKByBiN+lTr4/40eJNFgxrnd9 B3Z/fkhp1M+xMa9C35bu4NqUe9G426bVkrJDHj50jwZBLu3prreI15NGEeytWFePGWp+ H1Kw== MIME-Version: 1.0 X-Received: by 10.180.182.195 with SMTP id eg3mr6464987wic.31.1415376226929; Fri, 07 Nov 2014 08:03:46 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.194.19.136 with HTTP; Fri, 7 Nov 2014 08:03:46 -0800 (PST) In-Reply-To: <20141107123343.GA8713@unixarea.DDR.dd> References: <20141107123343.GA8713@unixarea.DDR.dd> Date: Fri, 7 Nov 2014 08:03:46 -0800 X-Google-Sender-Auth: eFOOsbIFbUDl3lY78ifm20o8nIg Message-ID: Subject: Re: IPv6 link-local addr && %interfacename From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Matthias Apitz , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:03:52 -0000 At Fri, 7 Nov 2014 13:33:43 +0100, Matthias Apitz wrote: > My question is: What does the %em0 mean in the IPv6 addr and why it is > not working without it? [...] > I consulted the handbook and the RFC: > > https://www.freebsd.org/doc/handbook/network-ipv6.html > http://www.ietf.org/rfc/rfc3513.txt > > Both do not give any explanation re/ the %interface value. See this: http://www.ietf.org/rfc/rfc4007.txt -- JINMEI, Tatuya From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 16:31:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33093B6D for ; Fri, 7 Nov 2014 16:31:49 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6A13CBA for ; Fri, 7 Nov 2014 16:31:48 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id r20so5093042wiv.16 for ; Fri, 07 Nov 2014 08:31:47 -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=PsUtAzTJkI/uV0jF6mYnMZMHQepbX1dTzOGDWp0jY/M=; b=Ep9jyP8KUFw7VdJmbGnghiwgByQUqZbc/Pjk9DLUvHf7VUJaviGYE0xPEVUV+qYiXF POAHivSZOsDGK81upB/g7YQP5rhedesOF0PkMjBdAMvDuXbVMV6ocDsywxFOuj8HtQKv J9SYJX0bdeh80q495YXenbB4naRqhGFUXRwqlQzOfJjFQ5nfgES92H+M6Voblywa9YRd nRBUbn0EZd077cpSBJbC9Dh1R4dSIu32Znh0t2G3i7zqHW9X8tnaWtrAfmyCmyE/lsec xyeCjCp7H4cc3H1+kPGgVfllh8/HTpdmjJZBmGM6rMrv3vW3j0WTaSmPpkQHdfFhaVlG BzKw== MIME-Version: 1.0 X-Received: by 10.180.83.98 with SMTP id p2mr6575204wiy.20.1415377907065; Fri, 07 Nov 2014 08:31:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 7 Nov 2014 08:31:47 -0800 (PST) In-Reply-To: References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 08:31:47 -0800 X-Google-Sender-Auth: YyuyCs00MdiBo0NLyAKJJae8xyM Message-ID: Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) From: Adrian Chadd To: grarpamp Content-Type: text/plain; charset=UTF-8 Cc: tor-relays@lists.torproject.org, FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 16:31:49 -0000 ... that's .. odd. Let's poke the freebsd crypto and network stack people and ask. I can't imagine why this is a problem anymore and we should default to it being on. The other thing you could do is have the tor port require it be turned on before tor runs. -adrian On 7 November 2014 00:20, grarpamp wrote: > On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: >> On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: >>> 173 FreeBSD >> >> FreeBSD still seems to use globally incrementing IP IDs by default. >> That's an issue as it leaks fine-grained information about how many >> packets a relay's networking stack processes. (However, nobody >> investigated the exact impact on Tor relays so far, which makes this a >> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >> relays I tested (38%) use global IP IDs. >> >> There's a sysctl variable called "net.inet.ip.random_id" which makes a >> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >> this to "1". >> >> Note that this issue was already discussed earlier this year in a thread >> called "Lots of tor relays send out sequential IP IDs; please fix >> that!". > > It's been default off since before it was a sysctl over a decade ago. > Anyone know what the deal is with that? Some objection, or > forgotten flag day, or oversight that really should be set to 1? > https://svnweb.freebsd.org/base?view=revision&revision=133720 > _______________________________________________ > 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 Fri Nov 7 18:08:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 172FB51A for ; Fri, 7 Nov 2014 18:08:15 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92710893 for ; Fri, 7 Nov 2014 18:08:14 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so5362053wib.13 for ; Fri, 07 Nov 2014 10:08:12 -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=R6vjCyQuQpnkc7Ty08W0tlYNIN+qL/ocHekrv+Znh5M=; b=BB0FoHQhENfYOO4di6IP+XNFlkSqPvJUkXQbb6s1vycDZTk40ab9J/dF1P5vN9LeJc FqRf1HMx3sdeanSG7TNq/G641+bh7PIuzFNXYOpYt/2wiPNk/lYLvihQTcb+VLDh22sO I0pttVJ9aOhsOZ2vrUZrIkvkiSIkpynTTm2OG6DZd6+jrgJy+6yTom/eqGqEYqFbTQ7C 8uI4PLa3hvyD9GgfZxGSI5exWUykgva1gxc1lhZt+zv8pN8k+v9y/cNbEybMdR2oM6pA TcAJEqhF6wA/vv2rVppOsVH/PGojpr22i9AzXPxPHIVz5Fjd8BvZoT12uQ1vbDpDKtTj vaAw== MIME-Version: 1.0 X-Received: by 10.180.10.231 with SMTP id l7mr7383600wib.1.1415383692090; Fri, 07 Nov 2014 10:08:12 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Fri, 7 Nov 2014 10:08:12 -0800 (PST) In-Reply-To: References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Fri, 7 Nov 2014 10:08:12 -0800 X-Google-Sender-Auth: Q-2upcAX5Wbtb1Pht_cbQrXef2w Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:08:15 -0000 On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes wrote: > On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote: > >> The code on code.google.com/p/netmap-ipfw/ works well for me >> on physical interfaces. >> >> For using the nics many of your examples show that you are not using the >> various programs correctly. There is clearly a >> mismatch between what this code does and your expectations, >> and there isn't much i can do to fix that. >> >> I acknowledge that the code might have rough edges and poor error >> reporting, but it is what it is. >> >> cheers >> luigi >> > > dear Luigi, > > do you run with em(4) driver? > i am using =E2=80=8B =E2=80=8Bit with ixgbe. do you mind point out where I could read additional info on how to > netmap-ipfw filter a traffic flow between 2 real boxes? > > =E2=80=8Bi am afraid i have no further docs to point you at. bye. luigi From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 21:06:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E24C87E; Fri, 7 Nov 2014 21:06:51 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 137A1C75; Fri, 7 Nov 2014 21:06:51 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id hy10so2241913vcb.39 for ; Fri, 07 Nov 2014 13:06:50 -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=Q8Bwf9rQwuFMx01aXD8aOzVraH2Q+lTxJLoP6htJ2dw=; b=m/Qoe9HIldtUqe1tl2UGTbANmZfpK9CC/Oa3Xz/9U9z78Y/oH/li1mrR/N7308HUlp Mj61xFBS6cpeQp2XxVg3Qo4bWok6upA93kzIPurOQ7A+xNQVhKR8XMwwoDds/nrw7TZ6 dcXL5B4qTV4z4mq7FeWYC8ZISwq3BQ8nPs+gFi7DK/2Ikgc7qD1aFKkAg9hcv0hZTgz6 r2dJr/TbPtocVfRKyUkYdS/2fv2BIOp1JFwlNgJhwjdYuCWvGtTW3SkYGM5u0VEEmqCp pTH6kuk4Z4oTwLIwh9nvUr8aR+q4J9tjWVqeFp97lAQUibpdQGQ6AOFarCc1/ucWG0Yw RQsg== MIME-Version: 1.0 X-Received: by 10.221.38.66 with SMTP id th2mr9320080vcb.21.1415394410134; Fri, 07 Nov 2014 13:06:50 -0800 (PST) Received: by 10.221.64.74 with HTTP; Fri, 7 Nov 2014 13:06:50 -0800 (PST) In-Reply-To: References: <20141106135228.GE3824@nymity.ch> Date: Fri, 7 Nov 2014 16:06:50 -0500 Message-ID: Subject: Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network) From: grarpamp To: tor-relays@lists.torproject.org Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:06:51 -0000 On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. > On 7 November 2014 00:20, grarpamp wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote: >>> >>> FreeBSD still seems to use globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 21:41:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0959B442; Fri, 7 Nov 2014 21:41:58 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DCB1169; Fri, 7 Nov 2014 21:41:57 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 963661A418; Fri, 7 Nov 2014 13:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1415396511; x=1415410911; bh=yPCw94Bbzu2Zrx7Mbr7gS9IOhJmfx02rf3OWSC7DJ7k=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=tnXKOvMfC7iG3JFFMfCZ5CdoDsQvD3kr3VUUqbJjGdLRSD9LyW6RRrXYumFSo8XBb 2q+q7cIN9KEzLv6mB60hLoej+QeVCk66CcjXjM8qGowshJH8RJ/yTtxwTL6iRd0Tx0 6y4ftyYhee5PrkTKJTQ9UU5WXj4ooa+EkZNbNA30= Message-ID: <545D3C9E.2000201@delphij.net> Date: Fri, 07 Nov 2014 13:41:50 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Adrian Chadd , grarpamp Subject: Re: [tor-relays] FreeBSD's global IP ID References: <20141106135228.GE3824@nymity.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: tor-relays@lists.torproject.org, FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:41:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/07/14 08:31, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default > to it being on. The other thing you could do is have the tor port > require it be turned on before tor runs. If I remember correctly, it wasn't about security but about performance, the idea was to make the option per-interface (so that e.g. for internal, fast connection, don't bother to do it), but that never happen. I personally enable it on all my systems to sink away more kernel arc4rand output (which is, unfortunately a side effect of wrong (IMO) behavior, because the current generation code is rather unoptimized and does arc4rand() for each IP ID generated). The NetBSD implementation is superior than ours in my opinion as it uses Fisher-Yates shuffle instead of doing arc4rand (modern version even uses a lighter weighted PRNG for those who do not need strong cryptographical strengths) every time then test for collision, and is therefore more scalable. See: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_id.c?only_with_tag=MAIN Cheers, > -adrian > > On 7 November 2014 00:20, grarpamp wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter >> wrote: >>> On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: >>>> 173 FreeBSD >>> >>> FreeBSD still seems to use globally incrementing IP IDs by >>> default. That's an issue as it leaks fine-grained information >>> about how many packets a relay's networking stack processes. >>> (However, nobody investigated the exact impact on Tor relays so >>> far, which makes this a FUD-heavy topic.) It looks like >>> approximately 50 out of the 131 FreeBSD relays I tested (38%) >>> use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which >>> makes a FreeBSD's IP ID behaviour random. FreeBSD relay >>> operators should set this to "1". >>> >>> Note that this issue was already discussed earlier this year in >>> a thread called "Lots of tor relays send out sequential IP IDs; >>> please fix that!". >> >> It's been default off since before it was a sysctl over a decade >> ago. Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUXTyeAAoJEJW2GBstM+nscFkP/3AZyfGcZ+guYAXKg2fXUeNL 2A6upXx5Vtb7xMyTeCSfccGMtvc/IsGjWNrN8m8gC1xo304RDE9ChxZKUwtbSjNz twSIACF26F1wUmyFXPAqyNu3m9Id1KET4ttW+XO8cCDZegoyzm4O+xnMQY6PkhtT czf9VfONFzMM/ZPwFEClWsVcxNnIL6rGgDRUF0TJOPijwRSdp14MUNPTfYJT8JZ0 xL/KSYwK228S0AtGJXEyh8JXn6ejNYZBC1A9bvZWzPeKFDbfS20hJfPbs7N2NBCf KqE4EEAVikJ0DRjB7qBhm09mAA0Igg2K5WROcuT5RoOgLL4vj/DPa6LGaBqxgCBT 9NiqTuefcoLjXKWcYNLuRxaBgPuERXm4J9CdIWIn1X9QXSx+En++JHMiuqUT+8fW qSmlXve0zOIpnLoIZ7mlpMDwpQe2YWWf3eNhDVtsZLr+ra3pd95gQaf3aOvAJpJQ 8syLAyso5GkR+uQK9/mT7L3IH8VuiGAGzVrmdXXd0GewQct7flBymWCnUb8yUF6F O8+MMJOF7WWbtRBW45boWhoHl7K9JFtznDiZxZ/ef0P2LP+C6tk2DtjNtXWKRw6M Fg8ZK2FsFj0QiYuN7rdHWASLUjQCM08VnGItPbaIK1mnEa5RR66jgbLckbsTzCpP u9TA361AfS2/MER6RNdF =zRJy -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Nov 7 22:32: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D475EEE; Fri, 7 Nov 2014 22:32:58 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B2A7B3; Fri, 7 Nov 2014 22:32:57 +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 sA7MWiWs056487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Nov 2014 14:32:44 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sA7MWgk3056486; Fri, 7 Nov 2014 14:32:42 -0800 (PST) (envelope-from jmg) Date: Fri, 7 Nov 2014 14:32:42 -0800 From: John-Mark Gurney To: d@delphij.net Subject: Re: [tor-relays] FreeBSD's global IP ID Message-ID: <20141107223242.GZ24601@funkthat.com> Mail-Followup-To: d@delphij.net, Adrian Chadd , grarpamp , tor-relays@lists.torproject.org, FreeBSD Net References: <20141106135228.GE3824@nymity.ch> <545D3C9E.2000201@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <545D3C9E.2000201@delphij.net> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 07 Nov 2014 14:32:44 -0800 (PST) Cc: tor-relays@lists.torproject.org, FreeBSD Net , Adrian Chadd , grarpamp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:32:58 -0000 Xin Li wrote this message on Fri, Nov 07, 2014 at 13:41 -0800: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/07/14 08:31, Adrian Chadd wrote: > > ... that's .. odd. > > > > Let's poke the freebsd crypto and network stack people and ask. I > > can't imagine why this is a problem anymore and we should default > > to it being on. The other thing you could do is have the tor port > > require it be turned on before tor runs. > > If I remember correctly, it wasn't about security but about > performance, the idea was to make the option per-interface (so that > e.g. for internal, fast connection, don't bother to do it), but that > never happen. > > I personally enable it on all my systems to sink away more kernel > arc4rand output (which is, unfortunately a side effect of wrong (IMO) > behavior, because the current generation code is rather unoptimized > and does arc4rand() for each IP ID generated). > > The NetBSD implementation is superior than ours in my opinion as it > uses Fisher-Yates shuffle instead of doing arc4rand (modern version > even uses a lighter weighted PRNG for those who do not need strong > cryptographical strengths) every time then test for collision, and is > therefore more scalable. See: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/ip_id.c?only_with_tag=MAIN Looks interesting, but please make sure to fix the for loop... and memory use is a bit high... 128KB for each of these? Though it looks like NetBSD only uses one... RFC6864 is an interesting read: https://tools.ietf.org/html/rfc6864 We should add a dtrace probe or acounter to see just how many non-atomic IP packets are sent... For most consumers, just a random ID is fine, but there are some workloads (heavy UDP) that will need more than just random ID's, but need additional state to prevent id reuse... > > On 7 November 2014 00:20, grarpamp wrote: > >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter > >> wrote: > >>> On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: > >>>> 173 FreeBSD > >>> > >>> FreeBSD still seems to use globally incrementing IP IDs by > >>> default. That's an issue as it leaks fine-grained information > >>> about how many packets a relay's networking stack processes. > >>> (However, nobody investigated the exact impact on Tor relays so > >>> far, which makes this a FUD-heavy topic.) It looks like > >>> approximately 50 out of the 131 FreeBSD relays I tested (38%) > >>> use global IP IDs. > >>> > >>> There's a sysctl variable called "net.inet.ip.random_id" which > >>> makes a FreeBSD's IP ID behaviour random. FreeBSD relay > >>> operators should set this to "1". > >>> > >>> Note that this issue was already discussed earlier this year in > >>> a thread called "Lots of tor relays send out sequential IP IDs; > >>> please fix that!". > >> > >> It's been default off since before it was a sysctl over a decade > >> ago. Anyone know what the deal is with that? Some objection, or > >> forgotten flag day, or oversight that really should be set to 1? > >> https://svnweb.freebsd.org/base?view=revision&revision=133720 > > > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0 > > iQIcBAEBCgAGBQJUXTyeAAoJEJW2GBstM+nscFkP/3AZyfGcZ+guYAXKg2fXUeNL > 2A6upXx5Vtb7xMyTeCSfccGMtvc/IsGjWNrN8m8gC1xo304RDE9ChxZKUwtbSjNz > twSIACF26F1wUmyFXPAqyNu3m9Id1KET4ttW+XO8cCDZegoyzm4O+xnMQY6PkhtT > czf9VfONFzMM/ZPwFEClWsVcxNnIL6rGgDRUF0TJOPijwRSdp14MUNPTfYJT8JZ0 > xL/KSYwK228S0AtGJXEyh8JXn6ejNYZBC1A9bvZWzPeKFDbfS20hJfPbs7N2NBCf > KqE4EEAVikJ0DRjB7qBhm09mAA0Igg2K5WROcuT5RoOgLL4vj/DPa6LGaBqxgCBT > 9NiqTuefcoLjXKWcYNLuRxaBgPuERXm4J9CdIWIn1X9QXSx+En++JHMiuqUT+8fW > qSmlXve0zOIpnLoIZ7mlpMDwpQe2YWWf3eNhDVtsZLr+ra3pd95gQaf3aOvAJpJQ > 8syLAyso5GkR+uQK9/mT7L3IH8VuiGAGzVrmdXXd0GewQct7flBymWCnUb8yUF6F > O8+MMJOF7WWbtRBW45boWhoHl7K9JFtznDiZxZ/ef0P2LP+C6tk2DtjNtXWKRw6M > Fg8ZK2FsFj0QiYuN7rdHWASLUjQCM08VnGItPbaIK1mnEa5RR66jgbLckbsTzCpP > u9TA361AfS2/MER6RNdF > =zRJy > -----END PGP SIGNATURE----- > _______________________________________________ > 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" -- 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 Fri Nov 7 22:42:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE812A4 for ; Fri, 7 Nov 2014 22:42:20 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54E3287D for ; Fri, 7 Nov 2014 22:42:20 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so4808047wgh.34 for ; Fri, 07 Nov 2014 14:42:18 -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=l1rVWcrqFUBh4n/UFJ+1wyD1tDKiSfgNEkaJBMcJrlE=; b=rqC2Ob1yI4W0gvPom9WUZBwQpcnNElUGB6PAQ6lgtiAY0P8F2fZdOrMl7aQnT/4VpM ISXuRYubj2L64dSGHT1WnOMI6+xwxCuMqH1wAV51j+kjdEaZy6x1UTseTlUve8wkAs3W 5r4KUDBxwmkgsT98ga1VTf0kdH5Ar0xIBlg0Gms5wNi4gBUIc2gMM66jm4ufJGyyiDqo +kZe1QZgG2LRSCI7axR6wX/tAeY1CnupH6QKG4X7dDiezxcEGS67v1japvmydRYDl64f VwWTPbpX7cLlweevh2S3IdjoGD3INsQQxnTb1mmgiv7HMc0sFMUiqHRissnUHd27+8xI EBEw== MIME-Version: 1.0 X-Received: by 10.194.248.162 with SMTP id yn2mr20699241wjc.16.1415400138579; Fri, 07 Nov 2014 14:42:18 -0800 (PST) Received: by 10.217.92.7 with HTTP; Fri, 7 Nov 2014 14:42:18 -0800 (PST) In-Reply-To: References: <20141104221216.GA17502@onelab2.iet.unipi.it> <9547E931-AF82-4F5C-AA22-865E93831A27@freebsdbrasil.com.br> Date: Fri, 7 Nov 2014 20:42:18 -0200 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Evandro Nunes To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:42:20 -0000 On Fri, Nov 7, 2014 at 4:08 PM, Luigi Rizzo wrote: > > > On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes > wrote: > >> On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote: >> >>> The code on code.google.com/p/netmap-ipfw/ works well for me >>> on physical interfaces. >>> >>> For using the nics many of your examples show that you are not using th= e >>> various programs correctly. There is clearly a >>> mismatch between what this code does and your expectations, >>> and there isn't much i can do to fix that. >>> >>> I acknowledge that the code might have rough edges and poor error >>> reporting, but it is what it is. >>> >>> cheers >>> luigi >>> >> >> dear Luigi, >> >> do you run with em(4) driver? >> > > i am using =E2=80=8B > > =E2=80=8Bit with ixgbe. > > do you mind point out where I could read additional info on how to >> netmap-ipfw filter a traffic flow between 2 real boxes? >> >> > =E2=80=8Bi am afraid i have no further docs to point you at. > > Is your scenario similtar to what you've draw previosly? Machines A<->B<->C with ixgbe receiveing packets from the wire? I wonder if the general topology differs. > bye. > luigi > From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 07:26:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEC01261 for ; Sat, 8 Nov 2014 07:26:28 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79E30C47 for ; Sat, 8 Nov 2014 07:26:28 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id n8so3372618qaq.12 for ; Fri, 07 Nov 2014 23:26:27 -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=8sW/an8lv60YWp5g8DmOqUiPUxONzNCD5kVb1rnuVrI=; b=wX/o5nniYZyxEzCRHYFqp8tapwxaBXxqBbWAK++lIPVPMMwJq8QSqvjK4u5xzrz15d dES6t7j3lfQ/9gQRM6EGFoEPSxIWjN+XaPRcOKeUCb+P3oYMAo0ZB5Cqf9S18EL3T5+R SZloCs6dsHrWeA5dJ0GZla2+lTS27+Fm25PncX7Bs0S7r+RDBFmCzfJUUhXNOgH33Cds isX53IfMzyr+g2nTgK/g2FkMCdJ2MT0qxNPK17QDakBWBaTmtUAnMsvUbz14BqbClf3I Voh0vnWIJs4RQ67rP29WHps7cX4/GTXscOwhS2HTNl3exKhobyC08diPvia9PmyrDa8p XLew== MIME-Version: 1.0 X-Received: by 10.140.94.85 with SMTP id f79mr23267894qge.50.1415431587699; Fri, 07 Nov 2014 23:26:27 -0800 (PST) Received: by 10.229.234.194 with HTTP; Fri, 7 Nov 2014 23:26:27 -0800 (PST) Date: Sat, 8 Nov 2014 10:56:27 +0330 Message-ID: Subject: Re: netmap-ipfw on em0 em1 From: Mahnaz Talebi To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 07:26:28 -0000 Hi Evandro. I've tested netmap-ipfw on real NICs. Use " ./kipfw -i netmap:em0 -i netmap:em1 " to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy incoming packets to em0 to em1 if they pass defined rules (and vice versa, from em1 to em0). If you still have problem with ipfw-netmap, please send your scenario for testing it.