From owner-freebsd-net@FreeBSD.ORG Sun Feb 9 18:38:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 133A1305 for ; Sun, 9 Feb 2014 18:38:43 +0000 (UTC) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADA821B0C for ; Sun, 9 Feb 2014 18:38:42 +0000 (UTC) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 1F0C4198D27 for ; Sun, 9 Feb 2014 19:03:22 +0100 (CET) Received: from mail-in-15.arcor-online.net (mail-in-15.arcor-online.net [151.189.21.55]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id D768C116007 for ; Sun, 9 Feb 2014 19:03:22 +0100 (CET) X-Greylist: Passed host: 88.67.113.179 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-15.arcor-online.net C014C1AB52F Received: from lorvorc.mips.inka.de (dslb-088-067-113-179.pools.arcor-ip.net [88.67.113.179]) by mail-in-15.arcor-online.net (Postfix) with ESMTPS id C014C1AB52F for ; Sun, 9 Feb 2014 19:03:22 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id s19I3Mk6071693 for ; Sun, 9 Feb 2014 19:03:22 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id s19I3M4L071692 for freebsd-net@freebsd.org; Sun, 9 Feb 2014 19:03:22 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Terrible NFS performance under 9.2-RELEASE? Date: Sun, 9 Feb 2014 18:03:21 +0000 (UTC) Message-ID: References: <52DC1241.7010004@egr.msu.edu> <1629593139.16590858.1390789014324.JavaMail.root@uoguelph.ca> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 18:38:43 -0000 Rick Macklem wrote: > I have a "hunch" that might explain why 64K NFS reads/writes perform > poorly for some network environments. > A 64K NFS read reply/write request consists of a list of 34 mbufs when > passed to TCP via sosend() and a total data length of around 65680bytes. > Looking at a couple of drivers (virtio and ixgbe), they seem to expect > no more than 32-33 mbufs in a list for a 65535 byte TSO xmit. I think > (I don't have anything that does TSO to confirm this) that NFS will pass > a list that is longer (34 plus a TCP/IP header). This may or may not be the same problem: When I switched my desktop box from FreeBSD 7 to 9, NFS read performance from my media server (running OpenBSD) became extremely poor. I couldn't even stream a movie any longer. Disabling TSO on the nfe(4) interface had no effect. My workaround was to switch from a TCP mount to a UDP one. The problem has persisted to FreeBSD 10. I can now report that switching to [rw]size=32768 with a TCP mount also works fine. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Sun Feb 9 18:54:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75C2562D for ; Sun, 9 Feb 2014 18:54:16 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 339901C63 for ; Sun, 9 Feb 2014 18:54:16 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id i57so4348638yha.32 for ; Sun, 09 Feb 2014 10:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iNP4n5nZ9bWVXJSsTDTjPaWNHXg/oQVkD3JI8qQCC2U=; b=mESRvLZ8KxLXNDSV3wLhWnBqJP5iK9l+J5XdScRiI0ZUZpYTnCalu6lQuAk6s9QnK0 yC+naz43un6JMuhkcoNFtCh07Jt4GBuSZIrBQQ8S7FJPy5wh3ELipuMRv/oDlkayTSaa hckRF/uJuRft41MpaFtJS+i7LJ8BF9eYT9IKooFvVADs3GQQxgLGGe4OcQKWibAdQVBa 0wPb6WoFCQW01+0WN/vJJgTRT/oN0MyWaGf1rDgYIW9am2Aef3xZSuuCyAoniJC2RMIy yYx6cntnRtGbYsKYWHxMm0bGwsmTKJmim/cuOEZ6oFS2yl1THM5po0shBi6cKe34HxM2 QZqg== X-Received: by 10.236.51.71 with SMTP id a47mr23324582yhc.22.1391972055536; Sun, 09 Feb 2014 10:54:15 -0800 (PST) Received: from [192.168.1.76] (75-63-29-182.lightspeed.irvnca.sbcglobal.net. [75.63.29.182]) by mx.google.com with ESMTPSA id e50sm36790750yhd.26.2014.02.09.10.54.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Feb 2014 10:54:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Terrible NFS performance under 9.2-RELEASE? From: aurfalien In-Reply-To: Date: Sun, 9 Feb 2014 10:54:10 -0800 Content-Transfer-Encoding: 7bit Message-Id: <49357095-33DB-4881-8AC2-847C86E63350@gmail.com> References: <52DC1241.7010004@egr.msu.edu> <1629593139.16590858.1390789014324.JavaMail.root@uoguelph.ca> To: Christian Weisgerber X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 18:54:16 -0000 On Feb 9, 2014, at 10:03 AM, Christian Weisgerber wrote: > Rick Macklem wrote: > >> I have a "hunch" that might explain why 64K NFS reads/writes perform >> poorly for some network environments. >> A 64K NFS read reply/write request consists of a list of 34 mbufs when >> passed to TCP via sosend() and a total data length of around 65680bytes. >> Looking at a couple of drivers (virtio and ixgbe), they seem to expect >> no more than 32-33 mbufs in a list for a 65535 byte TSO xmit. I think >> (I don't have anything that does TSO to confirm this) that NFS will pass >> a list that is longer (34 plus a TCP/IP header). > > This may or may not be the same problem: > > When I switched my desktop box from FreeBSD 7 to 9, NFS read > performance from my media server (running OpenBSD) became extremely > poor. I couldn't even stream a movie any longer. Disabling TSO > on the nfe(4) interface had no effect. My workaround was to switch > from a TCP mount to a UDP one. The problem has persisted to FreeBSD 10. > > I can now report that switching to [rw]size=32768 with a TCP mount So either UDP or TCP w/rw sizes of 32K work the same? - aurf From owner-freebsd-net@FreeBSD.ORG Sun Feb 9 20:11:08 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F310A47 for ; Sun, 9 Feb 2014 20:11:08 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C974E1297 for ; Sun, 9 Feb 2014 20:11:07 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s19KB55o001554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 9 Feb 2014 13:11:06 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s19KB5he001551 for ; Sun, 9 Feb 2014 13:11:05 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 9 Feb 2014 13:11:05 -0700 (MST) From: Warren Block To: freebsd-net@FreeBSD.org Subject: re(4) startup and 10-stable Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 09 Feb 2014 13:11:06 -0700 (MST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 20:11:08 -0000 Last night, I upgraded a small firewall from 9-stable to 10-stable. Now pf can't load the ruleset on startup, reporting: Enabling pfNo ALTQ support in kernel ALTQ related functions disabled no IP address found for re0 /etc/pf.rules:76: could not parse host specification pfctl: Syntax error in config file: pf rules not loaded The rules can be loaded after it starts, and everything works fine. pciconf -lv re0@pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet netwait is used in rc.conf, but of course it happens long after pf is started. I was aware there had been some up/down bouncing problems on startup with later revisions of this interface, but hadn't had any problems with this older version. Is there a workaround? From owner-freebsd-net@FreeBSD.ORG Sun Feb 9 21:50: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA5C894F for ; Sun, 9 Feb 2014 21:50:55 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72CBC1AB5 for ; Sun, 9 Feb 2014 21:50:55 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so6436589obc.11 for ; Sun, 09 Feb 2014 13:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UrjiwI2jPIRfVPa/LgtUavEQP4lkOyLHnR0sYLv0fN0=; b=OXCw/Ca+FwmwnCmiF0W64aMGtFpn8h7DY85bRBN/AjVJjV1gJJcJzlDwDdPghGHiWR NNZpw0gvE4lseRBIp2iWUSSE/kMVfloCP+YXC8rzfL6JkeGYALVweXQIu9LS6rw/+fUj frLOvwVA4bCxOgY00pAuwgfAVQGsvtZFmSzBD2i0yjtmXM05p/fdkqAm0v1U+x6VwMT5 S3ETlpiedOXqSHzVaA9aeVqCAkqzJ+shuE+yN0vlStXHC7F0xeoKlh/uvZJapw6OCHiX LJyZJuRSeFlYxMUmc7j6H/d11K5dMJJkp9s9FVFAgyIxnWefu4QK98PXA5BOwgmtsoIR +0HA== X-Received: by 10.60.142.10 with SMTP id rs10mr23938600oeb.8.1391982654550; Sun, 09 Feb 2014 13:50:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.61.7 with HTTP; Sun, 9 Feb 2014 13:50:34 -0800 (PST) From: Raimundo Santos Date: Sun, 9 Feb 2014 19:50:34 -0200 Message-ID: Subject: userspace ipfw and FreeBSD 10 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 21:50:55 -0000 Hello list! There is a way to compile and use the userspace, netmap based, ipfw on top of FreeBSD 10? I mean, to compile it without great dependencies (gmake is one, may be GCC another). Here is the output of a tentative, with netmap and VIMAGE inkernel: root@fbsdserver:~/ipfw-user # gmake Building userspace ... gmake[1]: Entering directory `/root/ipfw-user/ipfw' (cd ../objs; gmake -f ../Makefile.kipfw include_e) gmake[2]: Entering directory `/root/ipfw-user/objs' Building /root/ipfw-user/objs/../objs/include_e ... gmake[2]: Leaving directory `/root/ipfw-user/objs' CC ipfw2.c CC dummynet.c CC main.c CC ipv6.c CC altq.c CC ../extra/glue.c ../extra/glue.c:181:36: error: comparison of unsigned expression < 0 is always false [-Werror,-Wtautological-compare] if((oldlenp != NULL) && (*oldlenp < 0)) ~~~~~~~~ ^ ~ 1 error generated. gmake[1]: *** [glue.o] Error 1 gmake[1]: Leaving directory `/root/ipfw-user/ipfw' gmake: *** [ipfw] Error 2 Thank you all, Raimundo From owner-freebsd-net@FreeBSD.ORG Sun Feb 9 22:20:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C85058BF for ; Sun, 9 Feb 2014 22:20:13 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D18A1CE1 for ; Sun, 9 Feb 2014 22:20:13 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id w7so4149120lbi.7 for ; Sun, 09 Feb 2014 14:20:10 -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=IkCOgaWJOFBp1vQLnwAG8scWmR7dUC2liiLbB8CwktI=; b=wkE1vI43CMDpgjF3ZO2VDN7AMfzpypp78C7JOt7Q05PfxjWahCRIpTUvSmXUAOS6SB hlK7/x7WGUP5PPB0gwQRa5yOqn5qj8o8bTh1zQ9PeKOHGgNnHyt5jRJ5S/PoDjUTu2Ko mctqpmor6SK5doVNXtTRAl5PPL52/okDWGhuYJepmIoXkdLR1XvEvJBc3J563U3bXwzX zjJ2olzEBaTbxgaSypypmQa2DSLMIfPC0Bm2nGlNvJzLlNxR5UqbwEYTeCZYYtgK2dQH HqV0ojlJw5lCdCM1SzBMJHbN4fddX72tIOJ3l8cDUXhspe1vENZNB4XeCYJdD+p/ZyVc Wwqg== MIME-Version: 1.0 X-Received: by 10.112.125.225 with SMTP id mt1mr3093248lbb.35.1391984410628; Sun, 09 Feb 2014 14:20:10 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Sun, 9 Feb 2014 14:20:10 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Feb 2014 14:20:10 -0800 X-Google-Sender-Auth: m0k8K6BxGaxg_bDQkeI1G4lxpiw Message-ID: Subject: Re: userspace ipfw and FreeBSD 10 From: Luigi Rizzo To: Raimundo Santos Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:20:13 -0000 just be patient for a few days, we are about to release a newer version of netmap and matching userspace ipfw code that can use the new features such as zerocopy and 'transparent' mode (all this is meant to work on HEAD, 10 and 9) cheers luigi On Sun, Feb 9, 2014 at 1:50 PM, Raimundo Santos wrote: > Hello list! > > There is a way to compile and use the userspace, netmap based, ipfw on top > of FreeBSD 10? I mean, to compile it without great dependencies (gmake is > one, may be GCC another). > > Here is the output of a tentative, with netmap and VIMAGE inkernel: > > root@fbsdserver:~/ipfw-user # gmake > Building userspace ... > gmake[1]: Entering directory `/root/ipfw-user/ipfw' > (cd ../objs; gmake -f ../Makefile.kipfw include_e) > gmake[2]: Entering directory `/root/ipfw-user/objs' > Building /root/ipfw-user/objs/../objs/include_e ... > gmake[2]: Leaving directory `/root/ipfw-user/objs' > CC ipfw2.c > CC dummynet.c > CC main.c > CC ipv6.c > CC altq.c > CC ../extra/glue.c > > ../extra/glue.c:181:36: error: comparison of unsigned expression < 0 is > always false [-Werror,-Wtautological-compare] > if((oldlenp != NULL) && (*oldlenp < 0)) > ~~~~~~~~ ^ ~ > 1 error generated. > gmake[1]: *** [glue.o] Error 1 > gmake[1]: Leaving directory `/root/ipfw-user/ipfw' > gmake: *** [ipfw] Error 2 > > Thank you all, > Raimundo > _______________________________________________ > 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 Sun Feb 9 23:47:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B55AD733 for ; Sun, 9 Feb 2014 23:47:32 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 778A414A1 for ; Sun, 9 Feb 2014 23:47:32 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so6507094obc.11 for ; Sun, 09 Feb 2014 15:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XKjppIBd73hZrKwNE6cIDxsbfnRJNSjNSeILeDlR+gk=; b=k3r9hBWxeiDPmC6LoE/79gJaaxhVELm4NPlDkBK9BvWw0rhhxxbeQ7un9xYmWNSGTG 7XDxZNMTskZ9TBd5TynO/KCFEDOC3ir6ax5y9jq3mrjSFOKghqY17Jb8TClYVt0F7Qij +iDgkp4AjywhCoxsbDW34B0FAXtTsLJcmDVBzGnJbdxM3EysIVFQDrOorkSTP57aw2P1 woezwPvZZaXYvciIRYdxXcE9ZwvyP2iqDBJkZj1U1u4hTvtaSiOxSlXLpCAWh5DGbmuI OLdE+10GrMKdxJZopiYOgJnDp5nT8DZmq+zHe+SY1XI9OJfeG1bmY5diNnk3rG6QpnVG i9Lw== X-Received: by 10.182.81.197 with SMTP id c5mr3952510oby.40.1391989651822; Sun, 09 Feb 2014 15:47:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.61.7 with HTTP; Sun, 9 Feb 2014 15:47:11 -0800 (PST) In-Reply-To: References: From: Raimundo Santos Date: Sun, 9 Feb 2014 21:47:11 -0200 Message-ID: Subject: Re: userspace ipfw and FreeBSD 10 To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 23:47:32 -0000 Hi Luigi! Thank you for the quick reply. I will be patiently waiting. cheers, Raimundo On 9 February 2014 20:20, Luigi Rizzo wrote: > just be patient for a few days, we are about to release a newer version > of netmap and matching userspace ipfw code that can use the new > features such as zerocopy and 'transparent' mode > (all this is meant to work on HEAD, 10 and 9) > > cheers > luigi > > > > On Sun, Feb 9, 2014 at 1:50 PM, Raimundo Santos wrote: > >> Hello list! >> >> There is a way to compile and use the userspace, netmap based, ipfw on top >> of FreeBSD 10? I mean, to compile it without great dependencies (gmake is >> one, may be GCC another). >> >> Here is the output of a tentative, with netmap and VIMAGE inkernel: >> >> root@fbsdserver:~/ipfw-user # gmake >> Building userspace ... >> gmake[1]: Entering directory `/root/ipfw-user/ipfw' >> (cd ../objs; gmake -f ../Makefile.kipfw include_e) >> gmake[2]: Entering directory `/root/ipfw-user/objs' >> Building /root/ipfw-user/objs/../objs/include_e ... >> gmake[2]: Leaving directory `/root/ipfw-user/objs' >> CC ipfw2.c >> CC dummynet.c >> CC main.c >> CC ipv6.c >> CC altq.c >> CC ../extra/glue.c >> >> ../extra/glue.c:181:36: error: comparison of unsigned expression < 0 is >> always false [-Werror,-Wtautological-compare] >> if((oldlenp != NULL) && (*oldlenp < 0)) >> ~~~~~~~~ ^ ~ >> 1 error generated. >> gmake[1]: *** [glue.o] Error 1 >> gmake[1]: Leaving directory `/root/ipfw-user/ipfw' >> gmake: *** [ipfw] Error 2 >> >> Thank you all, >> Raimundo >> _______________________________________________ >> 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 Feb 10 00:21: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D749F2A for ; Mon, 10 Feb 2014 00:21:26 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC20D171B for ; Mon, 10 Feb 2014 00:21:25 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i7so6790995oag.1 for ; Sun, 09 Feb 2014 16:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YaIm0UIT5y/dDQuuLVXQMoQVuyzoJ3Ux7CQbSQpT8ek=; b=W5bpbdif+LaPf95Eqk7OtJXjy11rJijRuGamCUC44BWkthwSxKYyjreLRUIG2enMEX Mrnf85hIY5/1cvfhIyzhPXE3BB7UAqqoJKAVugZ6ioOBRWNJtnK2Na2DBT5FHb59jnyD ocGCGMhmqP6ON35imcI03WrfaNMWTdVp9LANxoAstw0Cc75LuJQCM0fljCkJGYNpxmr2 gCp7gKsybet0PRQ/on5UhtBhGlWbWcvIE3uNSv+aDsDNcN8IIvUdua9MWV+ESJqyGFST T40Vrz/ijKDRuuOK0PXUegxy9MN4ZGh8hiVHQeQRagH81Jp+nBN4aKZGTyk6/YBmipOh XOkw== X-Received: by 10.182.233.201 with SMTP id ty9mr10209834obc.29.1391991685217; Sun, 09 Feb 2014 16:21:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.61.7 with HTTP; Sun, 9 Feb 2014 16:21:05 -0800 (PST) From: Raimundo Santos Date: Sun, 9 Feb 2014 22:21:05 -0200 Message-ID: Subject: vnet + netmap: how is it possible? To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 00:21:26 -0000 Hello list! I am willing to test an idea: modularize network functions using vnet jails. One vnet jail do the NAT, other do balancing, another one the traffic shapping, and so on. And I wonder if netmap could help to interconnect these vnets, because I can not see a way to do this. May be using netgraph or epair? But any of these options are not netmap aware, are they? Well, the question is in the air! Thank you all, Raimundo From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 00:50: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8024B605 for ; Mon, 10 Feb 2014 00:50:42 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4185B190C for ; Mon, 10 Feb 2014 00:50:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,814,1384318800"; d="scan'208";a="95135465" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 09 Feb 2014 19:49:32 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EF21FB404B; Sun, 9 Feb 2014 19:49:32 -0500 (EST) Date: Sun, 9 Feb 2014 19:49:32 -0500 (EST) From: Rick Macklem To: aurfalien Message-ID: <1278699658.3088617.1391993372969.JavaMail.root@uoguelph.ca> In-Reply-To: <49357095-33DB-4881-8AC2-847C86E63350@gmail.com> Subject: Re: Terrible NFS performance under 9.2-RELEASE? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-net@freebsd.org, Christian Weisgerber X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 00:50:42 -0000 aurfalien wrote: > On Feb 9, 2014, at 10:03 AM, Christian Weisgerber > wrote: > > > Rick Macklem wrote: > > > >> I have a "hunch" that might explain why 64K NFS reads/writes > >> perform > >> poorly for some network environments. > >> A 64K NFS read reply/write request consists of a list of 34 mbufs > >> when > >> passed to TCP via sosend() and a total data length of around > >> 65680bytes. > >> Looking at a couple of drivers (virtio and ixgbe), they seem to > >> expect > >> no more than 32-33 mbufs in a list for a 65535 byte TSO xmit. I > >> think > >> (I don't have anything that does TSO to confirm this) that NFS > >> will pass > >> a list that is longer (34 plus a TCP/IP header). > > > > This may or may not be the same problem: > > > > When I switched my desktop box from FreeBSD 7 to 9, NFS read > > performance from my media server (running OpenBSD) became extremely > > poor. I couldn't even stream a movie any longer. Disabling TSO > > on the nfe(4) interface had no effect. My workaround was to switch > > from a TCP mount to a UDP one. The problem has persisted to > > FreeBSD 10. > > > > I can now report that switching to [rw]size=32768 with a TCP mount > > So either UDP or TCP w/rw sizes of 32K work the same? > Nope. The client limits UDP rsize/wsize to 16K, so you were actually using rsize=16384,wsize=16384 when using UDP. You can "nfsstat -m" on the client to see what the actual "negotiated" mount options are. rick > - aurf > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 00:54:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40FAD862 for ; Mon, 10 Feb 2014 00:54:23 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id F0F3E1935 for ; Mon, 10 Feb 2014 00:54:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAD8i+FKDaFve/2dsb2JhbABZg0RXgwG7ek+BHXSCJQEBAQQBAQEgBCcgCxsOChEZAgQlAQkmBggHBAEcBIdkDadMoDMXjiwBARsZGweCb4FJBIlJhnaEAQeBEIQGkG+DSx4xgQQ5 X-IronPort-AV: E=Sophos;i="4.95,814,1384318800"; d="scan'208";a="94571820" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 09 Feb 2014 19:54:15 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 807BEB3F49; Sun, 9 Feb 2014 19:54:15 -0500 (EST) Date: Sun, 9 Feb 2014 19:54:15 -0500 (EST) From: Rick Macklem To: Christian Weisgerber Message-ID: <2059385169.3089582.1391993655512.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Terrible NFS performance under 9.2-RELEASE? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3089580_2077641633.1391993655510" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 00:54:23 -0000 ------=_Part_3089580_2077641633.1391993655510 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Christian Weisgerber wrote: > Rick Macklem wrote: > > > I have a "hunch" that might explain why 64K NFS reads/writes > > perform > > poorly for some network environments. > > A 64K NFS read reply/write request consists of a list of 34 mbufs > > when > > passed to TCP via sosend() and a total data length of around > > 65680bytes. > > Looking at a couple of drivers (virtio and ixgbe), they seem to > > expect > > no more than 32-33 mbufs in a list for a 65535 byte TSO xmit. I > > think > > (I don't have anything that does TSO to confirm this) that NFS will > > pass > > a list that is longer (34 plus a TCP/IP header). > > This may or may not be the same problem: > > When I switched my desktop box from FreeBSD 7 to 9, NFS read > performance from my media server (running OpenBSD) became extremely > poor. I couldn't even stream a movie any longer. Disabling TSO > on the nfe(4) interface had no effect. My workaround was to switch > from a TCP mount to a UDP one. The problem has persisted to FreeBSD > 10. > > I can now report that switching to [rw]size=32768 with a TCP mount > also works fine. > If it is convenient, trying a 64K TCP mount with a kernel that has the attached patch (which makes it use page size clusters and reduces the # of segments to 18) to see if it works well, would be interesting. rick ps: This is not a patch destined for head and shouldn't be applied to a production box, but I think it is ok for testing. > -- > Christian "naddy" Weisgerber > naddy@mips.inka.de > > _______________________________________________ > 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" > ------=_Part_3089580_2077641633.1391993655510 Content-Type: text/x-patch; name=4kmcl.patch Content-Disposition: attachment; filename=4kmcl.patch Content-Transfer-Encoding: base64 LS0tIGZzL25mcy9uZnNwb3J0Lmguc2F2MgkyMDE0LTAxLTI2IDE4OjQzOjQ3LjAwMDAwMDAwMCAt MDUwMAorKysgZnMvbmZzL25mc3BvcnQuaAkyMDE0LTAxLTI2IDE5OjA0OjI3LjAwMDAwMDAwMCAt MDUwMApAQCAtMTUzLDE0ICsxNTMsMjcgQEAKIAkJCU1HRVRIRFIoKG0pLCBNX1dBSVRPSywgTVRf REFUQSk7IAlcCiAJCX0gCQkJCQkJXAogCX0gd2hpbGUgKDApCi0jZGVmaW5lCU5GU01DTEdFVCht LCB3KQlkbyB7IAkJCQkJXAotCQlNR0VUKChtKSwgTV9XQUlUT0ssIE1UX0RBVEEpOyAJCQlcCi0J CXdoaWxlICgobSkgPT0gTlVMTCApIHsgCQkJCVwKLQkJCSh2b2lkKSBuZnNfY2F0bmFwKFBaRVJP LCAwLCAibmZzbWdldCIpOwlcCi0JCQlNR0VUKChtKSwgTV9XQUlUT0ssIE1UX0RBVEEpOyAJCVwK LQkJfSAJCQkJCQlcCi0JCU1DTEdFVCgobSksICh3KSk7CQkJCVwKKyNpZiBNSlVNUEFHRVNJWkUg PiBNQ0xCWVRFUworI2RlZmluZQlORlNNQ0xHRVQobSwgdykJZG8gewkgCQkJCQlcCisJCShtKSA9 IG1fZ2V0amNsKE1fV0FJVE9LLCBNVF9EQVRBLCAwLCBNSlVNUEFHRVNJWkUpOwlcCisJCXdoaWxl ICgobSkgPT0gTlVMTCkgewkgCQkJCVwKKwkJCSh2b2lkKW5mc19jYXRuYXAoUFpFUk8sIDAsICJu ZnNtZ2V0Iik7CQlcCisJCQlNR0VUKChtKSwgTV9XQUlUT0ssIE1UX0RBVEEpOwkgCQlcCisJCQlp ZiAoKG0pICE9IE5VTEwpCQkJCVwKKwkJCQlNQ0xHRVQoKG0pLCAodykpOwkJCVwKKwkJfQkgCQkJ CQkJXAogCX0gd2hpbGUgKDApCisjZWxzZQorI2RlZmluZQlORlNNQ0xHRVQobSwgdykJZG8gewkg CQkJCQlcCisJCShtKSA9IG1fZ2V0amNsKE1fV0FJVE9LLCBNVF9EQVRBLCAwLCBNQ0xCWVRFUyk7 CQlcCisJCXdoaWxlICgobSkgPT0gTlVMTCkgewkgCQkJCVwKKwkJCSh2b2lkKW5mc19jYXRuYXAo UFpFUk8sIDAsICJuZnNtZ2V0Iik7CQlcCisJCQlNR0VUKChtKSwgTV9XQUlUT0ssIE1UX0RBVEEp OwkgCQlcCisJCQlpZiAoKG0pICE9IE5VTEwpCQkJCVwKKwkJCQlNQ0xHRVQoKG0pLCAodykpOwkJ CVwKKwkJfQkgCQkJCQkJXAorCX0gd2hpbGUgKDApCisjZW5kaWYKICNkZWZpbmUJTkZTTUNMR0VU SERSKG0sIHcpIGRvIHsgCQkJCVwKIAkJTUdFVEhEUigobSksIE1fV0FJVE9LLCBNVF9EQVRBKTsJ CVwKIAkJd2hpbGUgKChtKSA9PSBOVUxMICkgeyAJCQkJXAotLS0gZnMvbmZzc2VydmVyL25mc19u ZnNkcG9ydC5jLnNhdjIJMjAxNC0wMS0yNiAxODo1NDoyOS4wMDAwMDAwMDAgLTA1MDAKKysrIGZz L25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYwkyMDE0LTAxLTI2IDE4OjU2OjA4LjAwMDAwMDAwMCAt MDUwMApAQCAtNTY2LDggKzU2Niw3IEBAIG5mc3Zub19yZWFkbGluayhzdHJ1Y3Qgdm5vZGUgKnZw LCBzdHJ1Y3QKIAlsZW4gPSAwOwogCWkgPSAwOwogCXdoaWxlIChsZW4gPCBORlNfTUFYUEFUSExF TikgewotCQlORlNNR0VUKG1wKTsKLQkJTUNMR0VUKG1wLCBNX1dBSVRPSyk7CisJCU5GU01DTEdF VChtcCwgTV9XQUlUT0spOwogCQltcC0+bV9sZW4gPSBORlNNU0laKG1wKTsKIAkJaWYgKGxlbiA9 PSAwKSB7CiAJCQltcDMgPSBtcDIgPSBtcDsKQEAgLTYzNiw4ICs2MzUsNyBAQCBuZnN2bm9fcmVh ZChzdHJ1Y3Qgdm5vZGUgKnZwLCBvZmZfdCBvZmYsCiAJICovCiAJaSA9IDA7CiAJd2hpbGUgKGxl ZnQgPiAwKSB7Ci0JCU5GU01HRVQobSk7Ci0JCU1DTEdFVChtLCBNX1dBSVRPSyk7CisJCU5GU01D TEdFVChtLCBNX1dBSVRPSyk7CiAJCW0tPm1fbGVuID0gMDsKIAkJc2l6ID0gbWluKE1fVFJBSUxJ TkdTUEFDRShtKSwgbGVmdCk7CiAJCWxlZnQgLT0gc2l6Owo= ------=_Part_3089580_2077641633.1391993655510-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 01:14:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15FA8CB3 for ; Mon, 10 Feb 2014 01:14:06 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EE751A84 for ; Mon, 10 Feb 2014 01:14:05 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id y1so4258175lam.36 for ; Sun, 09 Feb 2014 17:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=r5IgieaYvO4gWrHhjGrV0Bl6BqvBvu1bx6EAtw3+Hfg=; b=iXTldywFndc6Lzu7kDyuJ3dY+4Sc9x8sRp1Yu7MZ9Nt0P8EMOWIlCis49ZGIT2V8oR 3CGG0UfjHl3OGtcNMSjV+/Zshi8hoQb1uuMQ5LGluzXzxuf4REuCHDz6OlggXwiuA2fU +xwkgsa8eIv39TG4murqd2Z96PjSbXzuQXVCSSWxqnlitIMsWlYo5TGXl3fUT79hA6CW DiwPS1MHCkI2ko7vPyngw0mz9a2fc20JfRmmU8OGAtnS4ZQ/12JLRWZZOdJncHlTc32Q o6riONkWrF2F1PWyUlPlG61nh+uq/mM7OyS36bcpDuBuPbFElKb824pwIh1PJQpydMh1 kEQw== MIME-Version: 1.0 X-Received: by 10.112.132.131 with SMTP id ou3mr18550319lbb.29.1391994843370; Sun, 09 Feb 2014 17:14:03 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Sun, 9 Feb 2014 17:14:03 -0800 (PST) Date: Sun, 9 Feb 2014 17:14:03 -0800 X-Google-Sender-Auth: xpLFZxVS3iiUG2aDEoWLlXJjWcY Message-ID: Subject: netmap pipes (Re: vnet + netmap: how is it possible?) From: Luigi Rizzo To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 01:14:06 -0000 On Sun, Feb 9, 2014 at 4:21 PM, Raimundo Santos wrote: > Hello list! > > I am willing to test an idea: modularize network functions using vnet > jails. One vnet jail do the NAT, other do balancing, another one the > traffic shapping, and so on. > For these low level packet processing functions, jails are overkill. The upcoming version of netmap has "netmap pipes", pairs of netmap ports connected back to back and sharing memory, with blocking I/O through select/poll/epoll (and we are looking at supporting kqueue). You can use netmap pipes to build a graph of processes (nodes) which apply the desired transformations to your traffic. Nodes can be anything that speaks netmap (or libpcap), including your custom C code, Click instances, or whatever you like. Netmap pipes have names, so you can dynamically replace nodes in the graph. You can also freely chose how netmap pipes, NICs and VALE switch ports share memory so depending on how much you want to decouple the nodes you can do full zero-copy paths. Performance: you can move up to about 100 Mpps across a pipe, irrespective of the size (because you move metadata through the pipe). Latency is that of an IPC (and really depends on the OS, hw configuration, batch size). Think something in the range 1..10us. NOTE, things become much slower once you start touching data, but the point is that you can forget about performance in moving data around and concentrate on how you want to process things. cheers luigi > > And I wonder if netmap could help to interconnect these vnets, because I > can not see a way to do this. May be using netgraph or epair? But any of > these options are not netmap aware, are they? > > Well, the question is in the air! > > Thank you all, > Raimundo > _______________________________________________ > 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 Feb 10 08:44:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1525953 for ; Mon, 10 Feb 2014 08:44:09 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0FD7134F for ; Mon, 10 Feb 2014 08:44:09 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kp14so5941731pab.9 for ; Mon, 10 Feb 2014 00:44:09 -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=lKe33y9QuGppCWTpB7qcMuBC0f89uANT8rTnrspSnwA=; b=A1b2NiDnzUDcOj1DqYA52SbOZ+0kZt1sIqJ8u6I//XD3HqYzTI/E3d2rZY/THoxlve ENQSyKq2shKiEROKs1u1HNeHqDSHXH0nk+HiWUYAWP5qiccPlB4yqg9SoEmYFDdafqLC nhF1LWreMZVkFbwt1GuHmkIhVgbI6j/njPsxGxPs+2ojsQtMQbqM8pfmYO3VdM3R97II rZS0LcJfnxm4GGaCf8w7QydsR7b6Jf8gHK/7EgIyJGOAi5YO8CCdX6OLMueu+qSyAry4 wqwDeq36emzR7KxTIuqBQwOs6twFNjtL5z73U0YhdjXBOmOj7nsGy9EysUjVXw17iTWg 67ng== MIME-Version: 1.0 X-Received: by 10.68.14.130 with SMTP id p2mr36648168pbc.17.1392021849356; Mon, 10 Feb 2014 00:44:09 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.6.36 with HTTP; Mon, 10 Feb 2014 00:44:09 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Feb 2014 09:44:09 +0100 X-Google-Sender-Auth: p1xxGmULJhv9kcPNU4Mno5yNvmc Message-ID: Subject: Re: netmap pipes (Re: vnet + netmap: how is it possible?) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:44:10 -0000 Hello Luigi, On Mon, Feb 10, 2014 at 2:14 AM, Luigi Rizzo wrote: > On Sun, Feb 9, 2014 at 4:21 PM, Raimundo Santos wrote: > > > Hello list! > > > > I am willing to test an idea: modularize network functions using vnet > > jails. One vnet jail do the NAT, other do balancing, another one the > > traffic shapping, and so on. > > > > For these low level packet processing functions, jails are overkill. > > The upcoming version of netmap has "netmap pipes", > pairs of netmap ports connected back to back and sharing memory, > with blocking I/O through select/poll/epoll (and we are looking > at supporting kqueue). > > You can use netmap pipes to build a graph of processes (nodes) > which apply the desired transformations to your traffic. > Nodes can be anything that speaks netmap (or libpcap), > including your custom C code, Click instances, or whatever > you like. > > Is this netgraph overlayed over netmap or is something rewritten from scratch? > Netmap pipes have names, so you can dynamically > replace nodes in the graph. > > You can also freely chose how netmap pipes, NICs and > VALE switch ports share memory so depending on how > much you want to decouple the nodes you can do > full zero-copy paths. > > Performance: > you can move up to about 100 Mpps across a pipe, > irrespective of the size (because you move metadata through > the pipe). Latency is that of an IPC (and really depends on > the OS, hw configuration, batch size). > Think something in the range 1..10us. > > NOTE, things become much slower once you start touching > data, but the point is that you can forget about > performance in moving data around and concentrate on > how you want to process things. > > cheers > luigi > > > > > > And I wonder if netmap could help to interconnect these vnets, because I > > can not see a way to do this. May be using netgraph or epair? But any of > > these options are not netmap aware, are they? > > > > Well, the question is in the air! > > > > Thank you all, > > Raimundo > > _______________________________________________ > > 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) > -----------------------------------------+------------------------------- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 08:48:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D24CA3A for ; Mon, 10 Feb 2014 08:48:08 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB4F5136C for ; Mon, 10 Feb 2014 08:48:07 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1WCmX8-000Ctj-DF for freebsd-net@freebsd.org; Mon, 10 Feb 2014 12:48:06 +0400 Message-ID: <52F8923E.3020908@smartspb.net> Date: Mon, 10 Feb 2014 12:47:58 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: PF states degrade? References: <52F3366D.3030202@smartspb.net> <52F3BAB6.7090304@shrew.net> <52F48EB7.5010706@smartspb.net> In-Reply-To: <52F48EB7.5010706@smartspb.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140209-2, 09.02.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 08:48:08 -0000 I found the problem, but dont' understand how it had working for a 5 days before. The problem was with absent of explicit allow rule in pf.conf. Until I add explicit "pass out" rule, new translations looked this (noting to "expire" timer): --- pfctl -vvss ... all tcp 109.71.177.182:37473 (10.53.80.224:37473) -> 213.180.204.183:80 ESTABLISHED:ESTABLISHED [2785279666 + 109] [817361085 + 2425] age 00:00:02, expires in 00:00:00, 28:8 pkts, 1456:11600 bytes id: 0300000052f8856e creatorid: a92c1815 .. --- After I start pf.conf with "pass out" rule: --- pfctl -vvss ... lagg0 tcp 109.71.177.180:37474 (10.53.80.224:37474) -> 213.180.204.183:80 ESTABLISHED:ESTABLISHED [3139384483 + 6224] wscale 7 [2721112625 + 180382] wscale 4 age 00:00:09, expires in 01:00:00, 3603:6879 pkts, 190797:9971762 bytes, rule 13 id: 0200000052f885d4 creatorid: 3c9beaba .. --- Much longer, as you can see. So the only question is HOW IT WORKED BEFORE?! I don't understand it at all. Moreover, it STILL working at other FreeBSD 9.0-STABLE server with it 144 days uptime. Will be appreciate for hint and hope my info also helps. 07.02.2014 11:43, Dennis Yusupoff пишет: > Hello, Matthew. > > Definitely not - see limits defined in the pf.conf below. > Moreover, we had tested also after have done "pfctl -Fa -f /etc/pf.conf > && pfctl -d && pfctl -e" with traffic from only one customers. > > > 06.02.2014 20:39, Matthew Grooms пишет: >> On 2/6/2014 1:14 AM, Dennis Yusupoff wrote: >>> ... >>> set limit { states 1000000, frags 80000, src-nodes 100000, table-entries >>> 500000} >>> ... >> Dennis, >> >> Did you run out of pf state table entries? You can use pfctl to list >> the current limit and usage ... >> >> INFO: >> Status: Enabled for 14 days 19:48:29 Debug: Urgent >> >> State Table Total Rate >> current entries 4 >> searches 2030427 1.6/s >> inserts 64990 0.1/s >> removals 64986 0.1/s >> >> LIMITS: >> states hard limit 10000 >> src-nodes hard limit 10000 >> frags hard limit 5000 >> table-entries hard limit 200000 >> >> .. If that is the case, you can increase your state table size by >> inserting some configuration parameters at the top of your pf.conf >> file. For example ... >> >> set limit states 50000 >> set limit src-nodes 50000 >> set limit frags 25000 >> >> -Matthew >> _______________________________________________ >> -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 11: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED66135 for ; Mon, 10 Feb 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0593A1FDE for ; Mon, 10 Feb 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1AB6oH5080118 for ; Mon, 10 Feb 2014 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1AB6oMq080116 for freebsd-net@FreeBSD.org; Mon, 10 Feb 2014 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Feb 2014 11:06:50 GMT Message-Id: <201402101106.s1AB6oMq080116@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/185496 net [re] RTL8169 doesn't receive unicast ethernet packets o kern/185427 net [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with o kern/185023 net [tun] Closing tun interface deconfigures IP address o kern/185022 net [tun] ls /dev/tun creates tun interface o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host p kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129036 net [ipfw] 'ipfw fwd' does not change outgoing interface n o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/25986 net Socket would hang at LAST_ACK forever. f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 467 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 13:47:33 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 028D06EA; Mon, 10 Feb 2014 13:47:33 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C91A61E47; Mon, 10 Feb 2014 13:47:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1ADlWlP035319; Mon, 10 Feb 2014 13:47:32 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1ADlV3u035318; Mon, 10 Feb 2014 14:47:31 +0100 (CET) (envelope-from brueffer) Date: Mon, 10 Feb 2014 14:47:31 +0100 (CET) Message-Id: <201402101347.s1ADlV3u035318@freefall.freebsd.org> To: sven@vyatta.com, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: kern/181823: [ip6] [patch] make ipv6 mroute return same errror codes as IPv4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 13:47:33 -0000 Synopsis: [ip6] [patch] make ipv6 mroute return same errror codes as IPv4 State-Changed-From-To: open->closed State-Changed-By: brueffer State-Changed-When: Mon Feb 10 14:47:04 CET 2014 State-Changed-Why: Duplicate of kern/178472. http://www.freebsd.org/cgi/query-pr.cgi?pr=181823 From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 14:37:28 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2A3171D; Mon, 10 Feb 2014 14:37:27 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C34901326; Mon, 10 Feb 2014 14:37:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1AEbRJH050565; Mon, 10 Feb 2014 14:37:27 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1AEbRbR050564; Mon, 10 Feb 2014 15:37:27 +0100 (CET) (envelope-from brueffer) Date: Mon, 10 Feb 2014 15:37:27 +0100 (CET) Message-Id: <201402101437.s1AEbRbR050564@freefall.freebsd.org> To: sven@vyatta.com, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: kern/178472: [ip6] [patch] make return code consistent with IPv4 code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:37:28 -0000 Synopsis: [ip6] [patch] make return code consistent with IPv4 code State-Changed-From-To: open->closed State-Changed-By: brueffer State-Changed-When: Mon Feb 10 15:37:05 CET 2014 State-Changed-Why: Committed, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=178472 From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 14:40:01 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B2FE8BB for ; Mon, 10 Feb 2014 14:40:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54D511344 for ; Mon, 10 Feb 2014 14:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1AEe1uY050712 for ; Mon, 10 Feb 2014 14:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1AEe1OC050711; Mon, 10 Feb 2014 14:40:01 GMT (envelope-from gnats) Date: Mon, 10 Feb 2014 14:40:01 GMT Message-Id: <201402101440.s1AEe1OC050711@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/178472: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:40:01 -0000 The following reply was made to PR kern/178472; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/178472: commit references a PR Date: Mon, 10 Feb 2014 14:37:04 +0000 (UTC) Author: brueffer Date: Mon Feb 10 14:36:51 2014 New Revision: 261709 URL: http://svnweb.freebsd.org/changeset/base/261709 Log: For IPv6, return the same error code as IPv4 when mrouter is not initialized. PR: 178472 Submitted by: Sven-Thorsten Dietrich Reviewed by: bms Modified: head/sys/netinet6/ip6_mroute.c Modified: head/sys/netinet6/ip6_mroute.c ============================================================================== --- head/sys/netinet6/ip6_mroute.c Mon Feb 10 12:52:33 2014 (r261708) +++ head/sys/netinet6/ip6_mroute.c Mon Feb 10 14:36:51 2014 (r261709) @@ -361,7 +361,7 @@ X_ip6_mrouter_set(struct socket *so, str mifi_t mifi; if (so != V_ip6_mrouter && sopt->sopt_name != MRT6_INIT) - return (EACCES); + return (EPERM); switch (sopt->sopt_name) { case MRT6_INIT: _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 17:28: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 608FEE28; Mon, 10 Feb 2014 17:28:22 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8FFE1383; Mon, 10 Feb 2014 17:28:21 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id pv20so4982465lab.16 for ; Mon, 10 Feb 2014 09:28:19 -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=7kJS6FmVSPzcfvigS287fEQbIdEAY3z0QPRtkm8I6Rw=; b=x4QyKim/nEkgrTot3Kj3AmgKQruM/uA8pOeEvV3AeG1HsjwLjGGK61HPGHEMqLelQg vOY0PS3PQtCmwTFGviKKQokBsAxtR0UaI/gg16mwpnZrIyv8t+a/JDXKc/q3KImbcMrA uHSBllQDF34krhqxwttRavTygW7T6qV9pJqs4NPaflIfQlR+GtkZt2olZw2XxpQOIC0V fDwe9CaH25cc13paV0Y600+Zfj5UDiupkxf4YkZ3nI2qvJYK/aJAtSzolGiBVBviKKFj Motto3kY+AlWuEzrTCY+W4yjqlHFRBem33vo5Vui1+THRXudDPC3LlKYiE/3gWWVSDWx IKaA== MIME-Version: 1.0 X-Received: by 10.112.56.237 with SMTP id d13mr21967797lbq.2.1392053299631; Mon, 10 Feb 2014 09:28:19 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Mon, 10 Feb 2014 09:28:19 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Feb 2014 09:28:19 -0800 X-Google-Sender-Auth: KfF7PgtYsPLw2b4XHlrH2RAs2O0 Message-ID: Subject: Re: netmap pipes (Re: vnet + netmap: how is it possible?) From: Luigi Rizzo To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:28:22 -0000 On Mon, Feb 10, 2014 at 12:44 AM, Ermal Lu=E7i wrote: > > Hello Luigi, > > On Mon, Feb 10, 2014 at 2:14 AM, Luigi Rizzo wrote: > >> On Sun, Feb 9, 2014 at 4:21 PM, Raimundo Santos >> wrote: >> >> > Hello list! >> > >> > I am willing to test an idea: modularize network functions using vnet >> > jails. One vnet jail do the NAT, other do balancing, another one the >> > traffic shapping, and so on. >> > >> >> For these low level packet processing functions, jails are overkill. >> >> The upcoming version of netmap has "netmap pipes", >> pairs of netmap ports connected back to back and sharing memory, >> with blocking I/O through select/poll/epoll (and we are looking >> at supporting kqueue). >> >> You can use netmap pipes to build a graph of processes (nodes) >> which apply the desired transformations to your traffic. >> Nodes can be anything that speaks netmap (or libpcap), >> including your custom C code, Click instances, or whatever >> you like. >> >> > Is this netgraph overlayed over netmap or is something rewritten from > scratch? > nothing to do with netgraph, this is "simply" an extension of the netmap module. Also note this only provides the interconnection, you still have to build the processing modules. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 23:30: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B28C87C for ; Mon, 10 Feb 2014 23:30:21 +0000 (UTC) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3EEAA15ED for ; Mon, 10 Feb 2014 23:30:21 +0000 (UTC) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 2019F197AE3; Tue, 11 Feb 2014 00:30:02 +0100 (CET) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 080DA6F2503; Tue, 11 Feb 2014 00:30:03 +0100 (CET) X-Greylist: Passed host: 188.105.84.234 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-08.arcor-online.net D0ED43AF011 X-Greylist: Passed host: 188.105.84.234 Received: from lorvorc.mips.inka.de (dslb-188-105-084-234.pools.arcor-ip.net [188.105.84.234]) by mail-in-08.arcor-online.net (Postfix) with ESMTPS id D0ED43AF011; Tue, 11 Feb 2014 00:30:02 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id s1ANU2ij002116; Tue, 11 Feb 2014 00:30:02 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id s1ANU2Xi002115; Tue, 11 Feb 2014 00:30:02 +0100 (CET) (envelope-from naddy) Date: Tue, 11 Feb 2014 00:30:02 +0100 From: Christian Weisgerber To: Rick Macklem Subject: Re: Terrible NFS performance under 9.2-RELEASE? Message-ID: <20140210233002.GA2103@lorvorc.mips.inka.de> References: <2059385169.3089582.1391993655512.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2059385169.3089582.1391993655512.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:30:21 -0000 Rick Macklem: > > When I switched my desktop box from FreeBSD 7 to 9, NFS read > > performance from my media server (running OpenBSD) became extremely > > poor. I couldn't even stream a movie any longer. Disabling TSO > > on the nfe(4) interface had no effect. My workaround was to switch > > from a TCP mount to a UDP one. The problem has persisted to FreeBSD > > 10. > > > > I can now report that switching to [rw]size=32768 with a TCP mount > > also works fine. > > > If it is convenient, trying a 64K TCP mount with a kernel that has the > attached patch (which makes it use page size clusters and reduces the > # of segments to 18) to see if it works well, would be interesting. No, this works very poorly. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 23:41:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 472F6DCA for ; Mon, 10 Feb 2014 23:41:11 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 183F1174F for ; Mon, 10 Feb 2014 23:41:11 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kl14so6929170pab.1 for ; Mon, 10 Feb 2014 15:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XjQ30aJHnQyukg/J95giCTYOdW8bch5SRY7DR2Pz/ts=; b=GszR7q7JVaxe6kicfEiz/BKwvUozCzFM+m1PnqxZOfZoYzaQ3fINknxJI7nBLzuWia bMuFDEycHu2J+EfkqMWbhKSrl4duuAXhU3V4oSz1Rkqgd+sRKjrqywsPnNo31nHLxZ/s fI58dcjiZbfFOA+lLcV8Fz25CEj5UJo+miI8ZInTFUYn5uT9rGz0L11lzn9APBeQRIG7 9NNZxRTwyXMIAvp2wAtvkYK4bvIXK+8BRuY/8E8bdpU/9r9agkiHJKkCEElW6qFg6MQf YiaYk4G0HmID4Gz5VUYJAJqxr96TAFvWXrvZjqsHAc9NA9pNpYF9KEqilY9x4xsqCd/r wREQ== X-Received: by 10.66.119.172 with SMTP id kv12mr28715058pab.34.1392075670743; Mon, 10 Feb 2014 15:41:10 -0800 (PST) Received: from briankrusicw.logan.tv ([64.17.255.138]) by mx.google.com with ESMTPSA id zc6sm121598029pab.18.2014.02.10.15.41.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 15:41:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Terrible NFS performance under 9.2-RELEASE? From: aurfalien In-Reply-To: <20140210233002.GA2103@lorvorc.mips.inka.de> Date: Mon, 10 Feb 2014 15:41:05 -0800 Content-Transfer-Encoding: 7bit Message-Id: <77B2BE60-DB3C-4349-B105-6DA1CB2342CA@gmail.com> References: <2059385169.3089582.1391993655512.JavaMail.root@uoguelph.ca> <20140210233002.GA2103@lorvorc.mips.inka.de> To: Christian Weisgerber X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@freebsd.org, Rick Macklem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:41:11 -0000 On Feb 10, 2014, at 3:30 PM, Christian Weisgerber wrote: > Rick Macklem: > >>> When I switched my desktop box from FreeBSD 7 to 9, NFS read >>> performance from my media server (running OpenBSD) became extremely >>> poor. I couldn't even stream a movie any longer. Disabling TSO >>> on the nfe(4) interface had no effect. My workaround was to switch >>> from a TCP mount to a UDP one. The problem has persisted to FreeBSD >>> 10. >>> >>> I can now report that switching to [rw]size=32768 with a TCP mount >>> also works fine. >>> >> If it is convenient, trying a 64K TCP mount with a kernel that has the >> attached patch (which makes it use page size clusters and reduces the >> # of segments to 18) to see if it works well, would be interesting. > > No, this works very poorly. So basically either; TCP w/32K r/w or UDP Correct? - aurf "Janitorial Services" From owner-freebsd-net@FreeBSD.ORG Mon Feb 10 23:50:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B263CF9B for ; Mon, 10 Feb 2014 23:50:37 +0000 (UTC) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6426C17EE for ; Mon, 10 Feb 2014 23:50:37 +0000 (UTC) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 9A20E107A94; Tue, 11 Feb 2014 00:50:19 +0100 (CET) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 9899733E39B; Tue, 11 Feb 2014 00:50:19 +0100 (CET) X-Greylist: Passed host: 188.105.84.234 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-08.arcor-online.net 6D9C63AE84F X-Greylist: Passed host: 188.105.84.234 Received: from lorvorc.mips.inka.de (dslb-188-105-084-234.pools.arcor-ip.net [188.105.84.234]) by mail-in-08.arcor-online.net (Postfix) with ESMTPS id 6D9C63AE84F; Tue, 11 Feb 2014 00:50:19 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.7/8.14.7) with ESMTP id s1ANoJdQ001699; Tue, 11 Feb 2014 00:50:19 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.7/8.14.7/Submit) id s1ANoJje001698; Tue, 11 Feb 2014 00:50:19 +0100 (CET) (envelope-from naddy) Date: Tue, 11 Feb 2014 00:50:19 +0100 From: Christian Weisgerber To: aurfalien Subject: Re: Terrible NFS performance under 9.2-RELEASE? Message-ID: <20140210235019.GA1688@lorvorc.mips.inka.de> References: <2059385169.3089582.1391993655512.JavaMail.root@uoguelph.ca> <20140210233002.GA2103@lorvorc.mips.inka.de> <77B2BE60-DB3C-4349-B105-6DA1CB2342CA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77B2BE60-DB3C-4349-B105-6DA1CB2342CA@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:50:37 -0000 aurfalien: > So basically either; > > TCP w/32K r/w > > or UDP > > Correct? Yes, at least for my usage case. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 05:24:55 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF6FEAE5 for ; Tue, 11 Feb 2014 05:24:55 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94AFF162A for ; Tue, 11 Feb 2014 05:24:55 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id x10so7083975pdj.11 for ; Mon, 10 Feb 2014 21:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=5CerllXpxmx0Vr4ysZlLfWbI8nvvq2z/SGYcgdW4eWc=; b=Q5PbWO+ecwSC4lI9dW+d7VkRsapS75hNEm/xQ7QqolP/IVLf2MOwyeM8AxOPXN9cTC 3kyxEKG6hwIBRFa3a4TY0O9Z5m4rBwvcCpJrw207ecIxaK04ebLWgD8nOy4ocDZespQs IBEKxUAoPRxlcDDDRIFZeDDRdE6Ai6rlSC5RiNN81RvaJm9OC5totOAf0vMukBpRRPdV yYPF3ZxRlcQhbhLXVoNmb5PiIbBjKzbkaWrwmRnEnwcZUEUXtwpauzkqmXAz0Li9fQCC Y6WkHuFUR5TInBstV6nlEcsUEy+ZwAcc2hSn14o2i/QAflCybiJSIVv72a9Ip34xD/Ds jlRw== X-Received: by 10.66.221.199 with SMTP id qg7mr30498116pac.88.1392096295195; Mon, 10 Feb 2014 21:24:55 -0800 (PST) Received: from [192.168.1.64] (108-64-226-69.lightspeed.sntcca.sbcglobal.net. [108.64.226.69]) by mx.google.com with ESMTPSA id qw8sm48487167pbb.27.2014.02.10.21.24.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 21:24:54 -0800 (PST) Subject: netstat for vnets From: Vijay Singh Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) Message-Id: Date: Mon, 10 Feb 2014 21:24:52 -0800 To: FreeBSD Net Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 05:24:55 -0000 How does "jexec netstat -an" get its data from the kernel? I know that= netstat uses kvm, but I'm not sure how it works with vnet-jails. Any pointe= rs would be much appreciated. -vijay= From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 09: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 109A5D4C for ; Tue, 11 Feb 2014 09:00:41 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3FE3190D for ; Tue, 11 Feb 2014 09:00:40 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id c9so12561520qcz.13 for ; Tue, 11 Feb 2014 01:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UF2+wLHwzEmlhSJuzK6GZNPi4c9HdH3McXihsf5tKBs=; b=D+vtY9f6lxsynlbQrnt7KLx4ts9lJHAsHrWoIWsK8Aj3THhWH8e0QNcEhFFkUz6gFE wrx6YmR36RoCxXqrjwxfBBxR+mXJpbrLpKz7ZSxo2/Xb8JIYr1DPx+x8HPHt/XkE615R WP05H2c3gP4HjjVlAcXRXF8DBon7NOX4P1lfQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UF2+wLHwzEmlhSJuzK6GZNPi4c9HdH3McXihsf5tKBs=; b=JiAddRlHyP7irmrJvi2/cy69TTcFMd4BirB0BmzPoqiWZjCdOptgRSwqU5/Nn1RasS lSX90NtzzBnnZ8wjrPrvQb0StL09HqwkVvmEOSW42bND4JTvTUH/wBDasN74Usz4u57p IMcDQtrxXI+7+Jjp/DGYSQMXZEP4Xr7eoZyhd6MCdUr0DYqfNwoGLUPISbFmI8GZ/hmd ITKtYnd2QowgUwTf6kYCaylsBheJj/36byaTIkkA8IHXvu7+anfgUf39wXkME/rVb8wj 8Q/7KJO1XDDBqg0gduifCSq0x/mpsNZKEw2KMcE2CX2ieYIu1k88yOv13KAhg9lOteT+ Ao2Q== X-Gm-Message-State: ALoCoQleIIyRyJdMftxVUKGGEH/6e7Zmg/TguKw+kF8cYF+8m48tYpMxeGaKHACvmH21KkSOyII5 MIME-Version: 1.0 X-Received: by 10.140.82.175 with SMTP id h44mr52550099qgd.68.1392109239910; Tue, 11 Feb 2014 01:00:39 -0800 (PST) Received: by 10.140.97.75 with HTTP; Tue, 11 Feb 2014 01:00:39 -0800 (PST) X-Originating-IP: [75.128.101.59] In-Reply-To: <52D15185.50802@gibfest.dk> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> Date: Tue, 11 Feb 2014 04:00:39 -0500 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: Jason Hellenthal To: Thomas Steen Rasmussen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: lev@freebsd.org, sthaug@nethelp.no, "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 09:00:41 -0000 If you don't mind me saying... That is utter BS without the D. Doing it right and merging these two would leave for more constructive use. Nobody is saying that it really needs to perform v6 & v4 without interaction in the form of the user adding a switch and there is no reason that by default it could not just default to using 4 only leaving room for a later point to just switch its default to v6 when that time comes and calls for it. Secondly just because they would be merged does not mean there won't or can't be a convention of detecting how the program was called. Symlink ping to ping6 for interchangeability sake and the same could be done whenever the default for ping would change to v6 by Symlinking ping to ping4. And there is no reason why ping could not just do both and you as the operator pick up the tab and just learn to call ping4 when you need to. Quite frankly I am tired of seeing the old pessimism and paradigms that projects keep falling into over silly little subtle changes. ping localhost ("grab any name, you just want to know its alive") ping 127.0.0.1 ("you know you are pinging v4 without a doubt") ping ::1 ("you also know you are pinging v6 without a doubt") ping -4 localhost ("you know you are getting v4 without a doubt") ping -6 localhost ("you know you are getting v6 without a doubt") ping -4 ::1 ("must be retarded in some way") There is no reason whatsoever that these utilities cannot be combined. And there is one very valid reason they should be. Maybe someone should call fyodor and ask him to make a nmap6 and a nping6 to follow convention while the rest of the platforms work on combining. On Sat, Jan 11, 2014 at 9:13 AM, Thomas Steen Rasmussen wrote: > On 11-01-2014 14:36, sthaug@nethelp.no wrote: > >> Normal network enabled utilities like telnet or ftp or nc support >>> both because when using those you usually don't care about the >>> address family used, you just want to connect. This is a significant >>> difference from using ping or traceroute where you almost always >>> want a specific address family, depending on what you are testing. >>> >> I strongly disagree with the "almost always want a specific address >> family". I normally want to verify that the IP at the other end is >> alive, or get some idea of how to get there. If I want a specific >> address family I'm very happy to use -4 / -6 options. >> > > The IP at the other end will, by definition, always be either v4 or v6, > so yes, you do want a specific address family - namely the family your > IP belongs to. > > > Best regards, > > Thomas Steen Rasmussen > > > _______________________________________________ > 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 Feb 11 09:26:32 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD6526D8 for ; Tue, 11 Feb 2014 09:26:32 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74CA21B3C for ; Tue, 11 Feb 2014 09:26:32 +0000 (UTC) Received: from [10.10.1.214] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 51FAA12169C; Tue, 11 Feb 2014 09:26:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 51FAA12169C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1392110789; bh=jXx98WIc2CQsLqIJx+SDFHZvRqKzw/BE7yohiQYgWFk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ww/tfw9SNsSQIH4t2w2RWYUksqrRbE45ukbhtszX76qe+J+AtC8RrDezNeTiEvPAf MBGrR8fV/ptKHuUJffJj9OP2lJ1HAiFvEAuklNpA9sy9QKWCXUHu4hK9yknahoEE0Z dyB6BmMjC128+wsQtsGWopxWgnaETeBdgAJmPZdFKaodJaZoEOMSIpcA7t/8accJkW ujJ/ozT1/iJpsqr5DpFg8sTn9006T79exKlrDBVw2NI8bZlSQuZQWRdXxLcXJbZF8N uH9lSoOL94UPDlCIiWCE3W8re5ooFjx5942LWuctYVwvHZlzas/TB8F+S+ofmuDyTk wuLIPuVgDdULw== Message-ID: <52F9ECC1.6000700@gibfest.dk> Date: Tue, 11 Feb 2014 10:26:25 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jason Hellenthal Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 09:26:32 -0000 On 11-02-2014 10:00, Jason Hellenthal wrote: > If you don't mind me saying... That is utter BS without the D. > Since you are being so nice about it I will withdraw my objection. I can see that the consensus seems to want a unified utility, and I wouldn't want to stand in the way of that. /Thomas From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 10:42:57 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A46F1FDE for ; Tue, 11 Feb 2014 10:42:57 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 386D212E8 for ; Tue, 11 Feb 2014 10:42:57 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 11 Feb 2014 11:42:48 +0100 Date: Tue, 11 Feb 2014 11:43:29 +0100 From: Marko Zec To: Vijay Singh Subject: Re: netstat for vnets Message-ID: <20140211114329.43bda628@x23> In-Reply-To: References: Organization: FER X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 10:42:57 -0000 On Mon, 10 Feb 2014 21:24:52 -0800 Vijay Singh wrote: > How does "jexec netstat -an" get its data from the kernel? I > know that netstat uses kvm, but I'm not sure how it works with > vnet-jails. Any pointers would be much appreciated. I think these days libkvm first tries to find "native" symbols via kldsym(), and if it fails, attempts to prepend a "vnet_entry_" prefix in front of the search key, which then get resolved to the proper addres in _kvm_vnet_validaddr() in lib/libkvm/kvm_vnet.c. In the early days of VIMAGE it was the kernel who was responsible for resolving the symbol address in the proper vnet, honestly I do not recall when the magic moved to the userland and why... Btw. Vijay - did the patch I posted here: http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037769.html resolve the panics you complained about? Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 10:56:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1EF79C7 for ; Tue, 11 Feb 2014 10:56:40 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB9713DF for ; Tue, 11 Feb 2014 10:56:40 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3fNgsM0RzKzGMwp for ; Tue, 11 Feb 2014 11:56:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1392116196; x=1394708197; bh=eF8 cvWH/y5wwPVVJ+6LIUB38JWHEVlBd4nIzZ+j7lnU=; b=MCKhNmau61EEzZR4MlD C5YvCwbfXsYigIbYfEHd9L/vWOQkhVNYref0lzHqVvqy2v22XfkonPe5D0cByXSC /gNTTCWKp1hbuVZl9ngcITTu0Bv5oinYqkhg97dZjeJ88vsRW9zwPnp1y/LHVGO7 SPJ9JCGP4C9O0RiKweEc4jcE= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id Gm4RGOffwPdu for ; Tue, 11 Feb 2014 11:56:36 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 11 Feb 2014 11:56:36 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id DB0A9A24 for ; Tue, 11 Feb 2014 11:56:36 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 11 Feb 2014 11:56:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 11 Feb 2014 11:56:36 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single =?UTF-8?Q?utilities=3F?= Organization: J. Stefan Institute In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 10:56:40 -0000 2014-02-11 10:00, Jason Hellenthal wrote: > ping localhost ("grab any name, you just want to know its alive") > ping 127.0.0.1 ("you know you are pinging v4 without a doubt") > ping ::1 ("you also know you are pinging v6 without a doubt") > > ping -4 localhost ("you know you are getting v4 without a doubt") > ping -6 localhost ("you know you are getting v6 without a doubt") > > ping -4 ::1 ("must be retarded in some way") That's how it works in several commercial routers (Cisco, Summit, Juniper, ...) and that's how it works in Windows 7/8. No surprises to a user there, 'does the right thing'. > Doing it right and merging these two would leave for more constructive > use. [...] > There is no reason whatsoever that these utilities cannot be combined. > And > there is one very valid reason they should be. [...] > Quite frankly I am tired of seeing the old pessimism and paradigms that > projects keep falling into over silly little subtle changes. Remember the original PHK's story ( http://bikeshed.com/ ) ? It ended favourably for the sleep(1) command, it got its new feature. What can be learned there is: just needs someone to do it and be persistent enough to be accepted. Looks like a perfect task for Google Summer of Code 2014, time to apply is very near: http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Mark From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 11:07: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B223EC7 for ; Tue, 11 Feb 2014 11:07:01 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DB4C14F7 for ; Tue, 11 Feb 2014 11:07:01 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1WDBAz-0009KG-37; Tue, 11 Feb 2014 15:06:53 +0400 Message-ID: <52FA0444.3060806@smartspb.net> Date: Tue, 11 Feb 2014 15:06:44 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 Subject: Re: netmap pipes (Re: vnet + netmap: how is it possible?) References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140210-1, 10.02.2014), Outbound message X-Antivirus-Status: Clean Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 11:07:01 -0000 Luigi, it will be really brilliant if you would be kind to show more examples of use netmap with pipes, netgraph modules (for example, ng_netflow) and so on, because many of network engineers use FreeBSD without as strong programming skills as you have. At least I'm the one of they. ;) BTW, Ermal, are the any chances to see you patches for work dummynet in the PF? 10.02.2014 21:28, Luigi Rizzo пишет: > On Mon, Feb 10, 2014 at 12:44 AM, Ermal Luçi wrote: > >> Hello Luigi, >> >> On Mon, Feb 10, 2014 at 2:14 AM, Luigi Rizzo wrote: >> >>> On Sun, Feb 9, 2014 at 4:21 PM, Raimundo Santos >>> wrote: >>> >>>> Hello list! >>>> >>>> I am willing to test an idea: modularize network functions using vnet >>>> jails. One vnet jail do the NAT, other do balancing, another one the >>>> traffic shapping, and so on. >>>> >>> For these low level packet processing functions, jails are overkill. >>> >>> The upcoming version of netmap has "netmap pipes", >>> pairs of netmap ports connected back to back and sharing memory, >>> with blocking I/O through select/poll/epoll (and we are looking >>> at supporting kqueue). >>> >>> You can use netmap pipes to build a graph of processes (nodes) >>> which apply the desired transformations to your traffic. >>> Nodes can be anything that speaks netmap (or libpcap), >>> including your custom C code, Click instances, or whatever >>> you like. >>> >>> >> Is this netgraph overlayed over netmap or is something rewritten from >> scratch? >> > nothing to do with netgraph, this is "simply" an > extension of the netmap module. Also note this > only provides the interconnection, you still have > to build the processing modules. > > cheers > luigi > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 13:29:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BB86518 for ; Tue, 11 Feb 2014 13:29:25 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01AF1122D for ; Tue, 11 Feb 2014 13:29:24 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at1so4296072iec.25 for ; Tue, 11 Feb 2014 05:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=k0nGbzPZ+4+jVwE0qVG8deo8mYXqspy5oRBHzfVdYA4=; b=KrtSacEU+dArB7nYNaHb8Ydh/yaccnGcRFoW4OOjrP3bk1jGDhh2ca590zSodIxWvV 0XlD3ck5ue3CYzaaaxuLPs6vku2JLn6lI1bFL+HpD81H9trt/WDwZOslLwLUbgpy+eTf DnIR7lGmPxhdwJTwYczTMUfNClEMSQyp2pbg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=k0nGbzPZ+4+jVwE0qVG8deo8mYXqspy5oRBHzfVdYA4=; b=EFDtl0OPJ5WmncjBp1SY53KoA9q2K9qo/cyaCMGZTzXYqd+kfGctcJWkEldLRonCVC uVLDLW1LZa6eRr3MRtanmhdUC3A/gbqT0OPAyTCMuG6Fop9Vw5lWpeogWuYz838QtWbZ Gc4T3SrPDTuVZ/PXL/Cg07jHd7JOdHYakKy9E0ksKg9iZh3wOPbt0DMV7Rqferxi+O8T vvJxkgmjJDKTQ6kDDuW9/vcfwbdRq3LzQz5av9OjRhM4ZlaEgNOrYJbdAFVuMhP94tIP /Cq3hcJbT+jD5eWFRB37CY9kHscCEbHe1Lnl99nKBBASd156fuzfzf6I1q2b4+H1OUZE xkdw== X-Gm-Message-State: ALoCoQmF+5thn2E7vkaQKrhLsDxHRfhOAbQ/LpTzBu/t2oOHg0aNleQOdcWzfDmEmBCdWPXhcQR8 X-Received: by 10.50.159.194 with SMTP id xe2mr19816669igb.13.1392125364305; Tue, 11 Feb 2014 05:29:24 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id kl8sm17202808igb.3.2014.02.11.05.29.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 05:29:23 -0800 (PST) References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9D9D4CF5-E245-4ACD-9490-F52EA6ABAC1F; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Date: Tue, 11 Feb 2014 08:29:20 -0500 To: Mark Martinec X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 13:29:25 -0000 --Apple-Mail-9D9D4CF5-E245-4ACD-9490-F52EA6ABAC1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Something like this should not be that hard to convince anyone to commit the= change. I've seen three IIRC people in the past that had patches and they a= lso commented on how easy it was. Why on earth I don't understand people need to pull their grey beards out ov= er something that isn't going to interfere with their day to day lives if do= ne correctly. As you say . . . cisco, Juniper, Microsoft, but yet FreeBSD is regarded as .= . . Advanced network operating system. Just because a new protocol is invented doesn't mean that there should be a s= eparate utility. That's an annoyance and a write off to do the right thing. Otherwise we may as well start writing everything to be protocol dependent. Regards to just ping though aren't 9/10 times you are using it because name s= ervices have failed in some way so you are providing an address ? One of my daughters under the age of 10 knows the difference between v4 and v= 6 addresses. Uses windows ping and is confused by *ix systems because ping d= oesn't recognize ::1. Try to explain that to someone under ten. In a way it'= s a little embarrassing. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Feb 11, 2014, at 5:56, Mark Martinec wro= te: >=20 > 2014-02-11 10:00, Jason Hellenthal wrote: >> ping localhost ("grab any name, you just want to know its alive") >> ping 127.0.0.1 ("you know you are pinging v4 without a doubt") >> ping ::1 ("you also know you are pinging v6 without a doubt") >> ping -4 localhost ("you know you are getting v4 without a doubt") >> ping -6 localhost ("you know you are getting v6 without a doubt") >> ping -4 ::1 ("must be retarded in some way") >=20 > That's how it works in several commercial routers (Cisco, Summit, Juniper,= ...) > and that's how it works in Windows 7/8. No surprises to a user there, > 'does the right thing'. >=20 >> Doing it right and merging these two would leave for more constructive us= e. > [...] >> There is no reason whatsoever that these utilities cannot be combined. An= d >> there is one very valid reason they should be. > [...] >> Quite frankly I am tired of seeing the old pessimism and paradigms that >> projects keep falling into over silly little subtle changes. >=20 > Remember the original PHK's story ( http://bikeshed.com/ ) ? > It ended favourably for the sleep(1) command, it got its new feature. > What can be learned there is: just needs someone to do it and be > persistent enough to be accepted. >=20 > Looks like a perfect task for Google Summer of Code 2014, > time to apply is very near: > http://www.google-melange.com/gsoc/homepage/google/gsoc2014 >=20 >=20 > Mark > _______________________________________________ > 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" --Apple-Mail-9D9D4CF5-E245-4ACD-9490-F52EA6ABAC1F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIxMTEzMjkyMVowIwYJKoZIhvcN AQkEMRYEFNupiODTSYfiQ3isgqvrNd9SX6+AMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAOQuhRDjs2OA7SSVzdBVh ubXRzuc/reO/uTjVR8u4PcyZ+HdDTqWGA3iiLselEIDNQO5+wBS7th1RxPmq+QMr+35UTZY9P7tk P9nKEr4s/dF9BPj8bpdwEYCTt/XfpMemXrohus22AQchawGAm9zQotTqC30g7GK0WcxmJA1+m2K4 3ucL6/7KCjKp0zuch1xWPRxD4txSOs9/jhKVjOJX77Tt4rWZjXy5laEZgCn8x46Hw1z6dEgHMg8m I8ZnkMwLyYkHMZXNCD/CtW9LI1mi2J5CPJwfX1z8hkq4whk2/CDF3fL+vYyqgQZXu7kkvFyDCDZm 3wtdxOP8HTjl9L70zQAAAAAAAA== --Apple-Mail-9D9D4CF5-E245-4ACD-9490-F52EA6ABAC1F-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 13:51:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 385C9E55 for ; Tue, 11 Feb 2014 13:51:38 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 068E514F6 for ; Tue, 11 Feb 2014 13:51:38 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id y10so7531633pdj.32 for ; Tue, 11 Feb 2014 05:51:37 -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=4Rm7GLmgUKDo8TZm/Er8fNT/B2y1rd8tKSQgkiGvIK8=; b=Tamu6EfqOxocq8M/xxKmasavYVHWZNhwFc9GssQkA4+JZekq4BXSFjyhKrm/I828+F Id0rGOCQXvP3ULSrVklNMemwygl89AI1NmQdDHcs4AA8+oUXvZhqy7ohD0mN+8LNTY46 vR/uGHhvFUJ7Dbuv2j1syq6xz2Bsn3tQXEcHsw6Ol6Dkj2LvOdC1pmkH3R/oGtnnRpHD HjKfEHfZYob+/C/F2oiLDwxOZRyCArj3PAtaSeO/EzXmFmggO6DMFR9cZvumS24U3+Se A1evFbv8J72mYxbDMSflEGtgdZ+DXF++6TFWiF1QU6rzqAKcpXmUVOi+FcF9IE9JkGpq O2xw== MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr44882372pbc.86.1392126697094; Tue, 11 Feb 2014 05:51:37 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.6.36 with HTTP; Tue, 11 Feb 2014 05:51:37 -0800 (PST) In-Reply-To: <52FA0444.3060806@smartspb.net> References: <52FA0444.3060806@smartspb.net> Date: Tue, 11 Feb 2014 14:51:37 +0100 X-Google-Sender-Auth: nQdnCz3MMsHJROiM4qxdjXXc-t0 Message-ID: Subject: Re: netmap pipes (Re: vnet + netmap: how is it possible?) From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Dennis Yusupoff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Raimundo Santos X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 13:51:38 -0000 On Tue, Feb 11, 2014 at 12:06 PM, Dennis Yusupoff wrote: > Luigi, it will be really brilliant if you would be kind to show more > examples of use netmap with pipes, netgraph modules (for example, > ng_netflow) and so on, because many of network engineers use FreeBSD > without as strong programming skills as you have. At least I'm the one > of they. ;) > > BTW, Ermal, are the any chances to see you patches for work dummynet in > the PF? > > I will try to push them soon as they are validated for newer pf in HEAD/10.= * > 10.02.2014 21:28, Luigi Rizzo =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Mon, Feb 10, 2014 at 12:44 AM, Ermal Lu=C3=A7i wro= te: > > > >> Hello Luigi, > >> > >> On Mon, Feb 10, 2014 at 2:14 AM, Luigi Rizzo > wrote: > >> > >>> On Sun, Feb 9, 2014 at 4:21 PM, Raimundo Santos > >>> wrote: > >>> > >>>> Hello list! > >>>> > >>>> I am willing to test an idea: modularize network functions using vne= t > >>>> jails. One vnet jail do the NAT, other do balancing, another one the > >>>> traffic shapping, and so on. > >>>> > >>> For these low level packet processing functions, jails are overkill. > >>> > >>> The upcoming version of netmap has "netmap pipes", > >>> pairs of netmap ports connected back to back and sharing memory, > >>> with blocking I/O through select/poll/epoll (and we are looking > >>> at supporting kqueue). > >>> > >>> You can use netmap pipes to build a graph of processes (nodes) > >>> which apply the desired transformations to your traffic. > >>> Nodes can be anything that speaks netmap (or libpcap), > >>> including your custom C code, Click instances, or whatever > >>> you like. > >>> > >>> > >> Is this netgraph overlayed over netmap or is something rewritten from > >> scratch? > >> > > nothing to do with netgraph, this is "simply" an > > extension of the netmap module. Also note this > > only provides the interconnection, you still have > > to build the processing modules. > > > > cheers > > luigi > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > > -- > Best regards, > Dennis Yusupoff, > network engineer of > Smart-Telecom ISP > Russia, Saint-Petersburg > > _______________________________________________ > 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 Ermal From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 15:14:08 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C05F79 for ; Tue, 11 Feb 2014 15:14:08 +0000 (UTC) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2091E1C4F for ; Tue, 11 Feb 2014 15:14:07 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id u14so2303649bkz.27 for ; Tue, 11 Feb 2014 07:14:05 -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=N4NPEho5lq1JfGV2mWK1kdhehTH1UfAdFqvgG8hGunU=; b=QsaZNMBsAE9BU+l+eu1PsiO15YP4nHGpdVyHhh3om/0q5Uw59miuw3jimdgQS8/Xr4 yhOCMXl/jqXifzmlsjGgPxwZXE/KckdyvnPlrXwd9LAbFiwdSkSE1A9RLbbfx4g9hlhR kYjHzlcBbpiTl7Xq98m7U3Szh51nIhziA9SMUmpUEmlRObBRRbBKcxSvQAKgAXb6FEGV MAIEP/o4QmMaN5538o6DqsQpPt2EyU+jHOvXbRfG1eKUZBR2YgoZFpsLaoCWhnHNztvE l4Lcj+cWgkIel2f0YohO3QuSBSZLlSH3iH8gF7HcaBGh2b+X6zFBcqyz9rN3rCX76f7G OLfw== MIME-Version: 1.0 X-Received: by 10.204.104.193 with SMTP id q1mr20743702bko.6.1392131645074; Tue, 11 Feb 2014 07:14:05 -0800 (PST) Received: by 10.205.45.202 with HTTP; Tue, 11 Feb 2014 07:14:05 -0800 (PST) Date: Tue, 11 Feb 2014 15:14:05 +0000 Message-ID: Subject: if_qlxgb trouble From: Hakisho Nukama To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:14:08 -0000 I am trying to connect a HP NC523SFP in FreeBSD 10.0-RELEASE over SFP+ to a switch. This is my current progress, any hints are welcome. More information on demand. # kldload -v if_qlxgb ql0: mem 0xfdc00000-0xfddfffff, 0xfdbf0000-0xfdbfffff irq 16 at device 0.0 on pci11 ql0: qla_pci_attach: firmware[4.8.22.1319135230] ql0: Ethernet address: 2c:59:e5:ca:ff:ee ql1: mem 0xfd800000-0xfd9fffff,0xfd7f0000-0xfd7fffff irq 16 at device 0.1 on pci11 ql1: qla_pci_attach: firmware[4.8.22.1319135230] ql1: Ethernet address: 2c:59:e5:ca:ff:ee # sysctl dev.ql dev.ql.0.%desc: Qlogic ISP 80xx PCI CNA Adapter-Ethernet Function v1.1.36 dev.ql.0.%driver: ql dev.ql.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PT02.IPE4. IPE1.PES1 dev.ql.0.%pnpinfo: vendor=0x1077 device=0x8020 subvendor=0x103c subdevice=0x3733 class=0x020000 dev.ql.0.%parent: pci11 dev.ql.0.stats: 0 dev.ql.0.fw_version: 4.8.22.1319135230 dev.ql.0.debug: 0 dev.ql.0.std_replenish: 8 dev.ql.0.jumbo_replenish: 2 dev.ql.0.rcv_pkt_thres: 128 dev.ql.0.rcv_pkt_thres_d: 32 dev.ql.0.snd_pkt_thres: 16 dev.ql.0.free_pkt_thres: 1024 dev.ql.0.num_rds_rings: 2 dev.ql.0.num_sds_rings: 4 dev.ql.1.%desc: Qlogic ISP 80xx PCI CNA Adapter-Ethernet Function v1.1.36 dev.ql.1.%driver: ql dev.ql.1.%location: slot=0 function=1 handle=\_SB_.PCI0.PT02.IPE4.IPE1.PE11 dev.ql.1.%pnpinfo: vendor=0x1077 device=0x8020 subvendor=0x103c subdevice=0x3733 class=0x020000 dev.ql.1.%parent: pci11 dev.ql.1.stats: 0 dev.ql.1.fw_version: 4.8.22.1319135230 dev.ql.1.debug: 0 dev.ql.1.std_replenish: 8 dev.ql.1.jumbo_replenish: 2 dev.ql.1.rcv_pkt_thres: 128 dev.ql.1.rcv_pkt_thres_d: 32 dev.ql.1.snd_pkt_thres: 16 dev.ql.1.free_pkt_thres: 1024 dev.ql.1.num_rds_rings: 2 dev.ql.1.num_sds_rings: 4 # ifconfig ql0 10.13.37.21 ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000002 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000002 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_rds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000003 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000003 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_sds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000004 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000004 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_rules: Q8_CMD_RD_MAX_RULES_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000005 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000005 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_rcv_cntxts: Q8_CMD_RD_MAX_RX_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000006 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000006 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_tx_cntxts: Q8_CMD_RD_MAX_TX_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000018 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000018 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_mtu: Q8_CMD_RD_MAX_MTU failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000019 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000019 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_max_lro: Q8_CMD_RD_MAX_LRO failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000016 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000016 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql0: qla_get_flow_control: Q8_CMD_GET_FLOW_CNTRL failed ql0: qla_issue_cmd: cmd[0x001b2218] = 0x80000007 sig[0x001b2228] = 0xcafe0100 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x15c7d160 arg3[0x001b2224] = 0x00000120 ql0: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000007 arg1 = 0x00000000 arg2 = 0x15c7d160 arg3 = 0x00000120 ql0: qla_init_rcv_cntxt: Q8_CMD_CREATE_RX_CNTXT failed ql0: qla_fw_cmd: xmit queue full # ifconfig ql1 10.13.37.2 ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000002 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000002 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_rds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000003 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000003 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_sds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000004 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000004 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_rules: Q8_CMD_RD_MAX_RULES_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000005 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000005 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_rcv_cntxts: Q8_CMD_RD_MAX_RX_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000006 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000006 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_tx_cntxts: Q8_CMD_RD_MAX_TX_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000018 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000018 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_mtu: Q8_CMD_RD_MAX_MTU failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000019 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000019 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_max_lro: Q8_CMD_RD_MAX_LRO failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000016 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000000 arg2[0x001b2220] = 0x00000000 arg3[0x001b2224] = 0x00000000 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000016 arg1 = 0x00000000 arg2 = 0x00000000 arg3 = 0x00000000 ql1: qla_get_flow_control: Q8_CMD_GET_FLOW_CNTRL failed ql1: qla_issue_cmd: cmd[0x001b2218] = 0x80000007 sig[0x001b2228] = 0xcafe0101 arg1[0x001b221c] = 0x00000002 arg2[0x001b2220] = 0x0923b160 arg3[0x001b2224] = 0x00000120 ql1: qla_issue_cmd: exit (ret = 0xffffffff) rsp = 0x80000007 arg1 = 0x00000002 arg2 = 0x0923b160 arg3 = 0x00000120 ql1: qla_init_rcv_cntxt: Q8_CMD_CREATE_RX_CNTXT failed ql1: qla_fw_cmd: xmit queue full # ifconfig ql0 ql0: flags=8803 metric 0 mtu 1500 options=8013b ether 2c:59:e5:ca:ff:ee inet 10.13.37.2 netmask 0xffffff00 broadcast 10.13.37.255 nd6 options=29 media: Ethernet autoselect status: no carrier # ifconfig ql0 ql1: flags=8803 metric 0 mtu 1500 options=8013b ether 2c:59:e5:ca:ff:ee inet 10.13.37.3 netmask 0xffffff00 broadcast 10.13.37.255 nd6 options=29 media: Ethernet autoselect status: no carrier Best Regards, Hakisho Nukama From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 19:37:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33F82A2A for ; Tue, 11 Feb 2014 19:37:23 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id F368C189C for ; Tue, 11 Feb 2014 19:37:22 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N0U005J1H1WQLC0@st11p09mm-asmtp002.mac.com> for freebsd-net@freebsd.org; Tue, 11 Feb 2014 18:37:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-02-11_06:2014-02-11,2014-02-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=5 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1402110092 From: Kimmo Paasiala Content-type: multipart/signed; boundary="Apple-Mail=_AA7A6E49-C0BB-428D-B32C-D12F0487C831"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-id: MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: gifconfig_gifX not working with cloned_interfaces? Date: Tue, 11 Feb 2014 20:37:03 +0200 References: <3688B949-7F3B-47FE-8C6A-193805AE2B27@icloud.com> To: freebsd-net@freebsd.org In-reply-to: X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:37:23 -0000 --Apple-Mail=_AA7A6E49-C0BB-428D-B32C-D12F0487C831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 22.12.2013, at 12.05, Kimmo Paasiala wrote: >=20 > On 22.12.2013, at 12.01, Olivier Cochard-Labb=E9 = wrote: >=20 >> On Sat, Dec 21, 2013 at 9:27 PM, Kimmo Paasiala = wrote: >>>=20 >>> FreeBSD 10.0-RC2 r259413 i386. >>>=20 >>> I have this set up in rc.conf: >>>=20 >>> cloned_interfaces=3D"gif0" >>> gifconfig_gif0=3D"88.xxx.xxx.xxx 62.yyy.yyy.yyy" >>> ifconfig_gif0_ipv6=3D"inet6 2001:14b8:aaa:bbb::2 = 2001:14b8:aaa:bbb::1 prefixlen 128=94 >>>=20 >>> I=92m not using gif_interfaces=3D=93gif0=94 since it=92s deprecated = as per the warning messages spewed by the rc(8) scripts. >>>=20 >>> However this does not work properly The =91ifconfig gif0 tunnel = 88.xxx.xxx.xxx 62.yyy.yyy.yyy=92 does not get executed. It looks to me = that the tunnel set up is only performed when gif0 is listed in = gif_interfaces. >>>=20 >>> I can work around this by doing this instead of the 'gifconfig_gif0' = line: >>>=20 >>> ifconfig_gif0=3D=93 tunnel 88.xxx.xxx.xxx 62.yyy.yyy.yyy=94 >>>=20 >>=20 >> Hi, >>=20 >> You can configure gif interface like a standard interface (without = using gifconfig_), here is an example: >>=20 >> cloned_interfaces=3D"gif0 gif1" >> ifconfig_gif0=3D"inet 10.0.24.2/24 10.0.24.4 tunnel 10.0.23.2 = 10.0.34.4 up" >> ifconfig_gif1_ipv6=3D"inet6 2001:db8:24::2 prefixlen 64 tunnel = 2001:db8:23::2 2001:db8:34::4 up" >>=20 >> Regards, >>=20 >> Olivier >=20 > Hi, >=20 > Yes I know. I did note that in my workaround for the problem. However, = the rc.conf(5) manual page claims that gifconfig_gifX should still work = and that=92s why I=92m reporting the issue. >=20 > -Kimmo >=20 Hello, Has anyone had time to look at this issue? I could try to come up with a = fix myself but I=92d first like to know what is the proper way configure = gif(4) interfaces with FreeBSD 10. If gif_interfaces is deprecated then = is gifconfig_gifX also deprecated? If gifconfig_gifX is also deprecated = then this is a documentation issue and also the rc(8) scripts should = warn about using it like they do now warn about gif_interfaces. If = gifconfig_gifX is still valid then something must be done about the = handling of cloned_interfaces in rc.conf. -Kimmo --Apple-Mail=_AA7A6E49-C0BB-428D-B32C-D12F0487C831 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS+m3TAAoJEFvLZC0FWRVpVq8H/A+6C2uo0HjYHN+Fhmfyk9p/ wpfiSLQDzCEnAeXNJVg2OlcL0uXzhE7j+wAzu6zZTjRs7wCWehBRqzP64LoBiRuf z6jDD5EOfM34DaIsI4JIto2YgG/RLEdq8Y0Q8rK98CW1D7kI4AZWW0jPf1Y2K5fr OySEzLrzjDr3OJk2GXbuQq0lalhCvp0Lp3tvFkvYH9U+JPq0sqp1CEnpQwr861QK VK+WGchGiJg3qpvSNmw5BPEYsQmMiJLBnyEE8pZDaket3nmGJwTyTinTsqDIQEXz w4DR+yX9ZUGkbMoO5evYeurV7rYDIfiSOtXa1m/zYDmIgIRHwUVR0ApCG7bCU/I= =PedT -----END PGP SIGNATURE----- --Apple-Mail=_AA7A6E49-C0BB-428D-B32C-D12F0487C831-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 19:49:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5FA5278; Tue, 11 Feb 2014 19:49:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D81619AF; Tue, 11 Feb 2014 19:49:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D29AFB9B9; Tue, 11 Feb 2014 14:49:51 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Use of contiguous physical memory in cxgbe driver Date: Tue, 11 Feb 2014 13:48:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <21216.36928.132606.318491@hergotha.csail.mit.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402111348.52135.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Feb 2014 14:49:51 -0500 (EST) Cc: Adrian Chadd , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:49:53 -0000 On Thursday, January 23, 2014 2:32:51 am Adrian Chadd wrote: > It's about time we taught the physmem allocator to be more conducive > to physically contiguous allocations. > > A server with gigabytes of memory should be able to keep a couple tens > of megabytes of 64k sized allocation chunks around for exactly this. Alan Cox already taught the physmem allocator to do this for superpages. However, this change was part of the superpages changes, so you can't count experiences from machines older than about 7.2 when evaluating the effectiveness of the new allocator. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 19:49: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51B22282; Tue, 11 Feb 2014 19:49:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A82419B1; Tue, 11 Feb 2014 19:49:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1D93BB9C7; Tue, 11 Feb 2014 14:49:54 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: ixgbe/NFS m_defrag() instrumentation Date: Tue, 11 Feb 2014 13:58:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <21233.52147.912022.488615@hergotha.csail.mit.edu> In-Reply-To: <21233.52147.912022.488615@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402111358.54764.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 11 Feb 2014 14:49:54 -0500 (EST) Cc: rmacklem@freebsd.org, Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:49:55 -0000 On Wednesday, February 05, 2014 12:27:15 am Garrett Wollman wrote: > I instrumented calls to m_defrag() in ixgbe. As expected, it gets > called *a lot* when NFS is running with the default read size of 64k. > A simple benchmark (single-threaded sequential read of a 128 GB file > which I didn't even run to completion) tells the tale: > > $ sysctl dev.ix.0.mbuf_defrag_attempted > dev.ix.0.mbuf_defrag_attempted: 1737994 > > (There's already a similar counter for m_defrag() failures, which made > it easy to add this counter. Unfortunately, there is no analogous > instrumentation in cxgbe so I couldn't do likewise for that NIC.) Is this due to the other thread Rick has about TSO interacting with NFS? Do these go away if you disable TSO on the interface? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 21:16: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A418E29 for ; Tue, 11 Feb 2014 21:16:28 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1250412FE for ; Tue, 11 Feb 2014 21:16:27 +0000 (UTC) Received: from chombo.houseloki.net (c-76-115-19-22.hsd1.or.comcast.net [76.115.19.22]) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 619422D4FB4; Tue, 11 Feb 2014 13:16:26 -0800 (PST) Received: from [IPv6:2601:7:880:bd0:604d:cd62:f943:4d46] (unknown [IPv6:2601:7:880:bd0:604d:cd62:f943:4d46]) by chombo.houseloki.net (Postfix) with ESMTPSA id E9082AD8; Tue, 11 Feb 2014 13:16:23 -0800 (PST) Message-ID: <52FA9324.9070301@bluerosetech.com> Date: Tue, 11 Feb 2014 13:16:20 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kimmo Paasiala , freebsd-net@freebsd.org Subject: Re: gifconfig_gifX not working with cloned_interfaces? References: <3688B949-7F3B-47FE-8C6A-193805AE2B27@icloud.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: freebsd-net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:16:28 -0000 On 2/11/2014 10:37 AM, Kimmo Paasiala wrote: > Has anyone had time to look at this issue? I could try to come up > with a fix myself but I’d first like to know what is the proper way > configure gif(4) interfaces with FreeBSD 10. If gif_interfaces is > deprecated then is gifconfig_gifX also deprecated? If gifconfig_gifX > is also deprecated then this is a documentation issue and also the > rc(8) scripts should warn about using it like they do now warn about > gif_interfaces. If gifconfig_gifX is still valid then something must > be done about the handling of cloned_interfaces in rc.conf. -Kimmo IMO it's deprecated, a documentation issue and rc should warn. The gifconfig approach is obsolete due to no support for tunneling over IPv6. I asked about it a while back, but got silence. Just use cloned_interfaces and ifconfig: cloned_interfaces="gif0" ifconfig_gif0="inet6 tunnel 2001:db8::1 2001:db8::2 -accept_rtadv" ifconfig_gif0_alias0="inet 192.0.2.1 192.0.2.2 netmask 255.255.255.255" From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 22:12:16 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4672D60D for ; Tue, 11 Feb 2014 22:12:16 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE97B1886 for ; Tue, 11 Feb 2014 22:12:15 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1BMBvEs028865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Feb 2014 07:12:08 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1BMBtGS011810; Wed, 12 Feb 2014 07:11:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 12 Feb 2014 06:50:59 +0900 (JST) Message-Id: <20140212.065059.1470588740590268007.hrs@allbsd.org> To: kpaasial@icloud.com Subject: Re: gifconfig_gifX not working with cloned_interfaces? From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Feb_12_06_50_59_2014_470)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 12 Feb 2014 07:12:08 +0900 (JST) X-Spam-Status: No, score=-94.1 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR2,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:12:16 -0000 ----Security_Multipart(Wed_Feb_12_06_50_59_2014_470)-- Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 S2ltbW8gUGFhc2lhbGEgPGtwYWFzaWFsQGljbG91ZC5jb20+IHdyb3RlDQogIGluIDxGNzNFRjY4 Ni1FQ0ExLTRGNzAtOUQxNS03RDhDMzM2QTRGQjdAaWNsb3VkLmNvbT46DQoNCmtwPiANCmtwPiBP biAyMi4xMi4yMDEzLCBhdCAxMi4wNSwgS2ltbW8gUGFhc2lhbGEgPGtwYWFzaWFsQGljbG91ZC5j b20+IHdyb3RlOg0Ka3A+IA0Ka3A+ID4gDQprcD4gPiBPbiAyMi4xMi4yMDEzLCBhdCAxMi4wMSwg T2xpdmllciBDb2NoYXJkLUxhYmLDqSA8b2xpdmllckBjb2NoYXJkLm1lPg0Ka3A+ID4gd3JvdGU6 DQprcD4gPiANCmtwPiA+PiBPbiBTYXQsIERlYyAyMSwgMjAxMyBhdCA5OjI3IFBNLCBLaW1tbyBQ YWFzaWFsYSA8a3BhYXNpYWxAaWNsb3VkLmNvbT4NCmtwPiA+PiB3cm90ZToNCmtwPiA+Pj4gDQpr cD4gPj4+IEZyZWVCU0QgMTAuMC1SQzIgcjI1OTQxMyBpMzg2Lg0Ka3A+ID4+PiANCmtwPiA+Pj4g SSBoYXZlIHRoaXMgc2V0IHVwIGluIHJjLmNvbmY6DQprcD4gPj4+IA0Ka3A+ID4+PiBjbG9uZWRf aW50ZXJmYWNlcz0iZ2lmMCINCmtwPiA+Pj4gZ2lmY29uZmlnX2dpZjA9Ijg4Lnh4eC54eHgueHh4 IDYyLnl5eS55eXkueXl5Ig0Ka3A+ID4+PiBpZmNvbmZpZ19naWYwX2lwdjY9ImluZXQ2IDIwMDE6 MTRiODphYWE6YmJiOjoyIDIwMDE6MTRiODphYWE6YmJiOjoxDQprcD4gPj4+IHByZWZpeGxlbiAx MjjigJ0NCmtwPiA+Pj4gDQprcD4gPj4+IEnigJltIG5vdCB1c2luZyBnaWZfaW50ZXJmYWNlcz3i gJxnaWYw4oCdIHNpbmNlIGl04oCZcyBkZXByZWNhdGVkIGFzIHBlcg0Ka3A+ID4+PiB0aGUgd2Fy bmluZyBtZXNzYWdlcyBzcGV3ZWQgYnkgdGhlIHJjKDgpIHNjcmlwdHMuDQprcD4gPj4+IA0Ka3A+ ID4+PiBIb3dldmVyIHRoaXMgZG9lcyBub3Qgd29yayBwcm9wZXJseSBUaGUg4oCYaWZjb25maWcg Z2lmMCB0dW5uZWwNCmtwPiA+Pj4gODgueHh4Lnh4eC54eHggNjIueXl5Lnl5eS55eXnigJkgZG9l cyBub3QgZ2V0IGV4ZWN1dGVkLiBJdCBsb29rcyB0byBtZQ0Ka3A+ID4+PiB0aGF0IHRoZSB0dW5u ZWwgc2V0IHVwIGlzIG9ubHkgcGVyZm9ybWVkIHdoZW4gZ2lmMCBpcyBsaXN0ZWQgaW4NCmtwPiA+ Pj4gZ2lmX2ludGVyZmFjZXMuDQprcD4gPj4+IA0Ka3A+ID4+PiBJIGNhbiB3b3JrIGFyb3VuZCB0 aGlzIGJ5IGRvaW5nIHRoaXMgaW5zdGVhZCBvZiB0aGUgJ2dpZmNvbmZpZ19naWYwJw0Ka3A+ID4+ PiBsaW5lOg0Ka3A+ID4+PiANCmtwPiA+Pj4gaWZjb25maWdfZ2lmMD3igJwgdHVubmVsIDg4Lnh4 eC54eHgueHh4IDYyLnl5eS55eXkueXl54oCdDQprcD4gPj4+IA0Ka3A+ID4+IA0Ka3A+ID4+IEhp LA0Ka3A+ID4+IA0Ka3A+ID4+IFlvdSBjYW4gY29uZmlndXJlIGdpZiBpbnRlcmZhY2UgbGlrZSBh IHN0YW5kYXJkIGludGVyZmFjZSAod2l0aG91dA0Ka3A+ID4+IHVzaW5nIGdpZmNvbmZpZ18pLCBo ZXJlIGlzIGFuIGV4YW1wbGU6DQprcD4gPj4gDQprcD4gPj4gY2xvbmVkX2ludGVyZmFjZXM9Imdp ZjAgZ2lmMSINCmtwPiA+PiBpZmNvbmZpZ19naWYwPSJpbmV0IDEwLjAuMjQuMi8yNCAxMC4wLjI0 LjQgdHVubmVsIDEwLjAuMjMuMiAxMC4wLjM0LjQNCmtwPiA+PiB1cCINCmtwPiA+PiBpZmNvbmZp Z19naWYxX2lwdjY9ImluZXQ2IDIwMDE6ZGI4OjI0OjoyIHByZWZpeGxlbiA2NCB0dW5uZWwNCmtw PiA+PiAyMDAxOmRiODoyMzo6MiAyMDAxOmRiODozNDo6NCB1cCINCmtwPiA+PiANCmtwPiA+PiBS ZWdhcmRzLA0Ka3A+ID4+IA0Ka3A+ID4+IE9saXZpZXINCmtwPiA+IA0Ka3A+ID4gSGksDQprcD4g PiANCmtwPiA+IFllcyBJIGtub3cuIEkgZGlkIG5vdGUgdGhhdCBpbiBteSB3b3JrYXJvdW5kIGZv ciB0aGUgcHJvYmxlbS4gSG93ZXZlciwNCmtwPiA+IHRoZSByYy5jb25mKDUpIG1hbnVhbCBwYWdl IGNsYWltcyB0aGF0IGdpZmNvbmZpZ19naWZYIHNob3VsZCBzdGlsbA0Ka3A+ID4gd29yayBhbmQg dGhhdOKAmXMgd2h5IEnigJltIHJlcG9ydGluZyB0aGUgaXNzdWUuDQprcD4gPiANCmtwPiA+IC1L aW1tbw0Ka3A+ID4gDQprcD4gDQprcD4gSGVsbG8sDQprcD4gDQprcD4gSGFzIGFueW9uZSBoYWQg dGltZSB0byBsb29rIGF0IHRoaXMgaXNzdWU/IEkgY291bGQgdHJ5IHRvIGNvbWUgdXAgd2l0aA0K a3A+IGEgZml4IG15c2VsZiBidXQgSeKAmWQgZmlyc3QgbGlrZSB0byBrbm93IHdoYXQgaXMgdGhl IHByb3BlciB3YXkNCmtwPiBjb25maWd1cmUgZ2lmKDQpIGludGVyZmFjZXMgd2l0aCBGcmVlQlNE IDEwLiBJZiBnaWZfaW50ZXJmYWNlcyBpcw0Ka3A+IGRlcHJlY2F0ZWQgdGhlbiBpcyBnaWZjb25m aWdfZ2lmWCBhbHNvIGRlcHJlY2F0ZWQ/IElmIGdpZmNvbmZpZ19naWZYDQprcD4gaXMgYWxzbyBk ZXByZWNhdGVkIHRoZW4gdGhpcyBpcyBhIGRvY3VtZW50YXRpb24gaXNzdWUgYW5kIGFsc28gdGhl DQprcD4gcmMoOCkgc2NyaXB0cyBzaG91bGQgd2FybiBhYm91dCB1c2luZyBpdCBsaWtlIHRoZXkg ZG8gbm93IHdhcm4gYWJvdXQNCmtwPiBnaWZfaW50ZXJmYWNlcy4gSWYgZ2lmY29uZmlnX2dpZlgg aXMgc3RpbGwgdmFsaWQgdGhlbiBzb21ldGhpbmcgbXVzdA0Ka3A+IGJlIGRvbmUgYWJvdXQgdGhl IGhhbmRsaW5nIG9mIGNsb25lZF9pbnRlcmZhY2VzIGluIHJjLmNvbmYuDQoNCiBnaWZjb25maWdf Z2lmTiBpcyBhbHNvIGRlcHJlY2F0ZWQuICBDb21iaW5hdGlvbiBvZiBnaWZfaW50ZXJmYWNlcyBh bmQNCiBnaWZjb25maWdfZ2lmTiBzdGlsbCB3b3JrcywgYnV0IGl0IHNob3VsZCBiZSByZXdyaXR0 ZW4gd2l0aA0KIGNsb25lZF9pbnRlcmZhY2VzIGFuZCBpZmNvbmZpZ19JRi4gIEkgd2lsbCBhZGQg YW4gd2FybmluZyBtZXNzYWdlIHRvDQogZ2lmY29uZmlnX2dpZk4sIHRvby4NCg0KLS0gSGlyb2tp DQo= ----Security_Multipart(Wed_Feb_12_06_50_59_2014_470)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlL6m0MACgkQTyzT2CeTzy0HKACg3Ixwb/+5uqGtXJaYcrD8KAZN /HEAoLeKgp9hZcG6uG6Ewr8iE5o94nL+ =tvoS -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Feb_12_06_50_59_2014_470)---- From owner-freebsd-net@FreeBSD.ORG Tue Feb 11 22:24:01 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE2FEBBE; Tue, 11 Feb 2014 22:24:00 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDBC0199A; Tue, 11 Feb 2014 22:23:59 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s1BLu39S059676; Tue, 11 Feb 2014 13:56:07 -0800 (PST) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s1BLtvqP059670; Tue, 11 Feb 2014 13:55:57 -0800 (PST) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 11 Feb 2014 13:55:57 -0800 (PST) Message-ID: <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> Date: Tue, 11 Feb 2014 13:55:57 -0800 (PST) Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: "Chris H" To: "Jason Hellenthal" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Thomas Steen Rasmussen , lev@freebsd.org, sthaug@nethelp.no, "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:24:01 -0000 > If you don't mind me saying... That is utter BS without the D. > > Doing it right and merging these two would leave for more constructive use. > Nobody is saying that it really needs to perform v6 & v4 without > interaction in the form of the user adding a switch and there is no reason > that by default it could not just default to using 4 only leaving room for > a later point to just switch its default to v6 when that time comes and > calls for it. > > Secondly just because they would be merged does not mean there won't or > can't be a convention of detecting how the program was called. Symlink ping > to ping6 for interchangeability sake and the same could be done whenever > the default for ping would change to v6 by Symlinking ping to ping4. > > And there is no reason why ping could not just do both and you as the > operator pick up the tab and just learn to call ping4 when you need to. > > Quite frankly I am tired of seeing the old pessimism and paradigms that > projects keep falling into over silly little subtle changes. > > ping localhost ("grab any name, you just want to know its alive") > ping 127.0.0.1 ("you know you are pinging v4 without a doubt") > ping ::1 ("you also know you are pinging v6 without a doubt") > > ping -4 localhost ("you know you are getting v4 without a doubt") > ping -6 localhost ("you know you are getting v6 without a doubt") > > ping -4 ::1 ("must be retarded in some way") > > There is no reason whatsoever that these utilities cannot be combined. And > there is one very valid reason they should be. > > Maybe someone should call fyodor and ask him to make a nmap6 and a nping6 > to follow convention while the rest of the platforms work on combining. > > Frankly, I don't see what all the fuss is about. The answer seems so simple; Unify it, then call it ping64. See, now everyone gets what they want. :) Oh, or should that be ping46? ... --Chris > > On Sat, Jan 11, 2014 at 9:13 AM, Thomas Steen Rasmussen > wrote: > >> On 11-01-2014 14:36, sthaug@nethelp.no wrote: >> >>> Normal network enabled utilities like telnet or ftp or nc support >>>> both because when using those you usually don't care about the >>>> address family used, you just want to connect. This is a significant >>>> difference from using ping or traceroute where you almost always >>>> want a specific address family, depending on what you are testing. >>>> >>> I strongly disagree with the "almost always want a specific address >>> family". I normally want to verify that the IP at the other end is >>> alive, or get some idea of how to get there. If I want a specific >>> address family I'm very happy to use -4 / -6 options. >>> >> >> The IP at the other end will, by definition, always be either v4 or v6, >> so yes, you do want a specific address family - namely the family your >> IP belongs to. >> >> >> Best regards, >> >> Thomas Steen Rasmussen >> >> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 Feb 11 23:30:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 790CDEF7; Tue, 11 Feb 2014 23:30:05 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE74A1E50; Tue, 11 Feb 2014 23:30:04 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n7so14429163qcx.30 for ; Tue, 11 Feb 2014 15:30:04 -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=9yVXwaVVqPeN4Fha315zgo3wSTUcvkRhbGan/xgcr9s=; b=k1Gocyu4EHqqeqA0Rst2W+KQYAhMnKqIT6lxfn6ihzRN6wjivEJ71G1f2xbp6iv7LX ezBmkfazgfTS33ZIwbEV7Qr11c5lPgUjzrcd56R07Bz59HJxOuR/PP7EueKnxd5NH+nS tDEYfbC2h7Xjx6H9nlIWTQOsj1DexxlGiMPVWUtPHgBygTTxoKBwKRqGtW0w5rge/+ul SROTJtwzjNwxm13T8wZ78GLW/o1gBX2cHEYbbPD4Z7qxiJW/0mvcvDE2ASal1Pmj2kzh I1SC25hrJr5bXtndFShKXf8D267J5nz9QQF84lI4IwcCcG8wiudK7T1lDa/oRBQEfb7X B3wg== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr50150877qga.87.1392161404108; Tue, 11 Feb 2014 15:30:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 11 Feb 2014 15:30:04 -0800 (PST) In-Reply-To: <201402111348.52135.jhb@freebsd.org> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <21216.36928.132606.318491@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> Date: Tue, 11 Feb 2014 15:30:04 -0800 X-Google-Sender-Auth: -9V2MhqYjWqnZ2N1ad-tNqCJ4XA Message-ID: Subject: Re: Use of contiguous physical memory in cxgbe driver From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 23:30:05 -0000 On 11 February 2014 10:48, John Baldwin wrote: > On Thursday, January 23, 2014 2:32:51 am Adrian Chadd wrote: >> It's about time we taught the physmem allocator to be more conducive >> to physically contiguous allocations. >> >> A server with gigabytes of memory should be able to keep a couple tens >> of megabytes of 64k sized allocation chunks around for exactly this. > > Alan Cox already taught the physmem allocator to do this for superpages. > However, this change was part of the superpages changes, so you can't count > experiences from machines older than about 7.2 when evaluating the > effectiveness of the new allocator. the problem is that we don't have pressure to _not_ fragment the physical memory from the allocator, so all of the memory ends up getting very fragmented versy quickly. the physmem superpage stuff stops being viable after a short while of say, "pound lots of packets around from vm objects" workload, because suddenly we end up chewing through all of physical memory with pages extremely quickly. -a From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 03:33:02 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 863DF80A for ; Wed, 12 Feb 2014 03:33:02 +0000 (UTC) Received: from mx0b-0016ce01.pphosted.com (mx0b-0016ce01.pphosted.com [67.231.156.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44B6C1D56 for ; Wed, 12 Feb 2014 03:33:01 +0000 (UTC) Received: from pps.filterd (m0000643.ppops.net [127.0.0.1]) by mx0b-0016ce01.pphosted.com (8.14.5/8.14.5) with SMTP id s1C3SAf7004475; Tue, 11 Feb 2014 19:28:10 -0800 Received: from avcashub1.qlogic.com (avcashub2.qlogic.com [198.70.193.116]) by mx0b-0016ce01.pphosted.com with ESMTP id 1htwtxuxfb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 Feb 2014 19:28:09 -0800 Received: from AVMB1.qlogic.org ([fe80::c919:8cc:f3ba:c727]) by avcashub2.qlogic.org ([::1]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 19:28:08 -0800 From: David Somayajulu To: Hakisho Nukama , "net@freebsd.org" Subject: RE: if_qlxgb trouble Thread-Topic: if_qlxgb trouble Thread-Index: AQHPJzvzFPWHlOvfe0aGASK4B8Ljapqw9YXw Date: Wed, 12 Feb 2014 03:28:07 +0000 Message-ID: <49F5640B08EAA94DAF2F6B6145E6A08A899173E6@AVMB1.qlogic.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.4.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7346 signatures=668934 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402110188 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 03:33:02 -0000 Hi Hakisho, I am using the same driver on a FreeBSD9.0 system and don't see the proble= m. The only difference is that the firmware version on my board is 4.9.46.1= 325015960 We can take this off line and discuss further. Cheers David S. =3D=3D=3D=3D ql0: mem 0xfa40= 0000-0xfa5fffff,0xfbb30000-0xfbb3ffff irq 24 at device 0.0 on pci9 ql0: qla_pci_attach: firmware[4.9.46.1325015960] ql0: Ethernet address: 00:0e:1e:04:2d:98 ql1: mem 0xfa60= 0000-0xfa7fffff,0xfbbb0000-0xfbbbffff irq 24 at device 0.1 on pci9 ql1: qla_pci_attach: firmware[4.9.46.1325015960] ql1: Ethernet address: 00:0e:1e:04:2d:9c # ifconfig ql0 ql0: flags=3D8843 metric 0 mtu 1500 options=3D8013b ether 00:0e:1e:04:2d:98 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20e:1eff:fe04:2d98%ql0 prefixlen 64 scopeid 0xe nd6 options=3D23 media: Ethernet autoselect (10Gbase-SR ) status: active -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Hakisho Nukama Sent: Tuesday, February 11, 2014 7:14 AM To: net@freebsd.org Subject: if_qlxgb trouble I am trying to connect a HP NC523SFP in FreeBSD 10.0-RELEASE over SFP+ to a switch. This is my current progress, any hints are welcome. More information on demand. # kldload -v if_qlxgb ql0: mem 0xfdc0= 0000-0xfddfffff, 0xfdbf0000-0xfdbfffff irq 16 at device 0.0 on pci11 ql0: qla_pci_attach: firmware[4.8.22.1319135230] ql0: Ethernet address: 2c:59:e5:ca:ff:ee ql1: mem 0xfd80= 0000-0xfd9fffff,0xfd7f0000-0xfd7fffff irq 16 at device 0.1 on pci11 ql1: qla_pci_attach: firmware[4.8.22.1319135230] ql1: Ethernet address: 2c:59:e5:ca:ff:ee # sysctl dev.ql dev.ql.0.%desc: Qlogic ISP 80xx PCI CNA Adapter-Ethernet Function v1.1.36 dev.ql.0.%driver: ql dev.ql.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.PT02.IPE4. IPE1.PES1 dev.ql.0.%pnpinfo: vendor=3D0x1077 device=3D0x8020 subvendor=3D0x103c subdevice=3D0x3733 class=3D0x020000 dev.ql.0.%parent: pci11 dev.ql.0.stats: 0 dev.ql.0.fw_version: 4.8.22.1319135230 dev.ql.0.debug: 0 dev.ql.0.std_replenish: 8 dev.ql.0.jumbo_replenish: 2 dev.ql.0.rcv_pkt_thres: 128 dev.ql.0.rcv_pkt_thres_d: 32 dev.ql.0.snd_pkt_thres: 16 dev.ql.0.free_pkt_thres: 1024 dev.ql.0.num_rds_rings: 2 dev.ql.0.num_sds_rings: 4 dev.ql.1.%desc: Qlogic ISP 80xx PCI CNA Adapter-Ethernet Function v1.1.36 dev.ql.1.%driver: ql dev.ql.1.%location: slot=3D0 function=3D1 handle=3D\_SB_.PCI0.PT02.IPE4.IPE= 1.PE11 dev.ql.1.%pnpinfo: vendor=3D0x1077 device=3D0x8020 subvendor=3D0x103c subdevice=3D0x3733 class=3D0x020000 dev.ql.1.%parent: pci11 dev.ql.1.stats: 0 dev.ql.1.fw_version: 4.8.22.1319135230 dev.ql.1.debug: 0 dev.ql.1.std_replenish: 8 dev.ql.1.jumbo_replenish: 2 dev.ql.1.rcv_pkt_thres: 128 dev.ql.1.rcv_pkt_thres_d: 32 dev.ql.1.snd_pkt_thres: 16 dev.ql.1.free_pkt_thres: 1024 dev.ql.1.num_rds_rings: 2 dev.ql.1.num_sds_rings: 4 # ifconfig ql0 10.13.37.21 ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000002 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000002 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_rds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000003 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000003 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_sds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000004 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000004 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_rules: Q8_CMD_RD_MAX_RULES_PER_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000005 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000005 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_rcv_cntxts: Q8_CMD_RD_MAX_RX_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000006 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000006 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_tx_cntxts: Q8_CMD_RD_MAX_TX_CNTXT failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000018 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000018 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_mtu: Q8_CMD_RD_MAX_MTU failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000019 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000019 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_max_lro: Q8_CMD_RD_MAX_LRO failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000016 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000016 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql0: qla_get_flow_control: Q8_CMD_GET_FLOW_CNTRL failed ql0: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000007 sig[0x001b2228] =3D 0xcafe0100 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x15c7d160 arg3[0x001b2224] =3D 0x00000120 ql0: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000007 arg1 =3D 0x00000000 arg2 =3D 0x15c7d160 arg3 =3D 0x00000120 ql0: qla_init_rcv_cntxt: Q8_CMD_CREATE_RX_CNTXT failed ql0: qla_fw_cmd: xmit queue full # ifconfig ql1 10.13.37.2 ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000002 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000002 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_rds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000003 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000003 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_sds: Q8_CMD_RD_MAX_RDS_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000004 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000004 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_rules: Q8_CMD_RD_MAX_RULES_PER_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000005 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000005 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_rcv_cntxts: Q8_CMD_RD_MAX_RX_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000006 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000006 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_tx_cntxts: Q8_CMD_RD_MAX_TX_CNTXT failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000018 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000018 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_mtu: Q8_CMD_RD_MAX_MTU failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000019 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000019 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_max_lro: Q8_CMD_RD_MAX_LRO failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000016 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000000 arg2[0x001b2220] =3D 0x00000000 arg3[0x001b2224] =3D 0x00000000 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000016 arg1 =3D 0x00000000 arg2 =3D 0x00000000 arg3 =3D 0x00000000 ql1: qla_get_flow_control: Q8_CMD_GET_FLOW_CNTRL failed ql1: qla_issue_cmd: cmd[0x001b2218] =3D 0x80000007 sig[0x001b2228] =3D 0xcafe0101 arg1[0x001b221c] =3D 0x00000002 arg2[0x001b2220] =3D 0x0923b160 arg3[0x001b2224] =3D 0x00000120 ql1: qla_issue_cmd: exit (ret =3D 0xffffffff) rsp =3D 0x80000007 arg1 =3D 0x00000002 arg2 =3D 0x0923b160 arg3 =3D 0x00000120 ql1: qla_init_rcv_cntxt: Q8_CMD_CREATE_RX_CNTXT failed ql1: qla_fw_cmd: xmit queue full # ifconfig ql0 ql0: flags=3D8803 metric 0 mtu 1500 options=3D8013b ether 2c:59:e5:ca:ff:ee inet 10.13.37.2 netmask 0xffffff00 broadcast 10.13.37.255 nd6 options=3D29 media: Ethernet autoselect status: no carrier # ifconfig ql0 ql1: flags=3D8803 metric 0 mtu 1500 options=3D8013b ether 2c:59:e5:ca:ff:ee inet 10.13.37.3 netmask 0xffffff00 broadcast 10.13.37.255 nd6 options=3D29 media: Ethernet autoselect status: no carrier Best Regards, Hakisho Nukama _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 03:25:28 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57CFA41A for ; Wed, 12 Feb 2014 03:25:28 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F2DE1CAB for ; Wed, 12 Feb 2014 03:25:28 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id to1so5311564ieb.0 for ; Tue, 11 Feb 2014 19:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=x7B0zrB8X31ieBiyjjrkj6LuxfW4eQB0nKuAn8u11NU=; b=Qm5rnbGFf5nnFiYxSarJkLSqeSH5OOLM4vLILaCNLNeAJADpzPlx32+nt7VmmqM8T/ 8WmtHhulsbZsn9FpQzamAb0MvR97uCvpI8LteOsY/v0+q7AgTwoSFkxEHwc9zsPo2h+j BQSC3OryUBUX+fNBO+CdUpQ4/IAE4gGqKIxSo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=x7B0zrB8X31ieBiyjjrkj6LuxfW4eQB0nKuAn8u11NU=; b=ictwlV/pVDVNcwyL0jh46WHe1GMTfHnj5dPbvjaQ1v4RmsYcdidKjeZ24mQj8UzNri k8dtVHVbGoSoG6AN/K6AkJzjmTRbk+gwemC5Tat/1/Z76aQA7J1iaLXw9zx1W19oaCEA 4OC03uMBrEDf+AJ32GPjwlXQ2+ruJV0c/N0g/tbreli9NizNhLXeW2dmzulc8rVjsL94 FXSwf7hr89hbFqZS0vvdm7epEcTyzJvhAK6AiG0xC72lEkB6Li03H8AYgy82lMGtkkPO iDsruvsCcxiNZF96t0KB6zhMWfiWt23docTLWINYd/pEpx9NkHmOXFTRCdfUnOi2Yg4R xItA== X-Gm-Message-State: ALoCoQnp2jKJgWjT3yLE990g3xX/k1cf2sP557K3ZLeY1+n0CCsXOj2EBkyEF6qYTT81dfvev2jy X-Received: by 10.50.222.99 with SMTP id ql3mr1711067igc.42.1392175527401; Tue, 11 Feb 2014 19:25:27 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id i3sm4079483igi.3.2014.02.11.19.25.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 19:25:25 -0800 (PST) References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-61706D92-1F83-4F14-826F-32D2255A0885; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Date: Tue, 11 Feb 2014 22:25:22 -0500 To: Chris H X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Thomas Steen Rasmussen , "lev@freebsd.org" , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 03:25:28 -0000 --Apple-Mail-61706D92-1F83-4F14-826F-32D2255A0885 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Haha careful 64 might be considered 64bit protocol support ;-) and someone m= ight confuse 46 as a DHCP option rfc2132 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN On Feb 11, 2014, at 16:55, "Chris H" wrote: >> If you don't mind me saying... That is utter BS without the D. >>=20 >> Doing it right and merging these two would leave for more constructive us= e. >> Nobody is saying that it really needs to perform v6 & v4 without >> interaction in the form of the user adding a switch and there is no reaso= n >> that by default it could not just default to using 4 only leaving room fo= r >> a later point to just switch its default to v6 when that time comes and >> calls for it. >>=20 >> Secondly just because they would be merged does not mean there won't or >> can't be a convention of detecting how the program was called. Symlink pi= ng >> to ping6 for interchangeability sake and the same could be done whenever >> the default for ping would change to v6 by Symlinking ping to ping4. >>=20 >> And there is no reason why ping could not just do both and you as the >> operator pick up the tab and just learn to call ping4 when you need to. >>=20 >> Quite frankly I am tired of seeing the old pessimism and paradigms that >> projects keep falling into over silly little subtle changes. >>=20 >> ping localhost ("grab any name, you just want to know its alive") >> ping 127.0.0.1 ("you know you are pinging v4 without a doubt") >> ping ::1 ("you also know you are pinging v6 without a doubt") >>=20 >> ping -4 localhost ("you know you are getting v4 without a doubt") >> ping -6 localhost ("you know you are getting v6 without a doubt") >>=20 >> ping -4 ::1 ("must be retarded in some way") >>=20 >> There is no reason whatsoever that these utilities cannot be combined. An= d >> there is one very valid reason they should be. >>=20 >> Maybe someone should call fyodor and ask him to make a nmap6 and a nping6= >> to follow convention while the rest of the platforms work on combining. >=20 > Frankly, I don't see what all the fuss is about. The answer seems so simpl= e; > Unify it, then call it ping64. > See, now everyone gets what they want. :) > Oh, or should that be ping46? > ... >=20 > --Chris >=20 >>=20 >> On Sat, Jan 11, 2014 at 9:13 AM, Thomas Steen Rasmussen >> wrote: >>=20 >>>> On 11-01-2014 14:36, sthaug@nethelp.no wrote: >>>>=20 >>>> Normal network enabled utilities like telnet or ftp or nc support >>>>> both because when using those you usually don't care about the >>>>> address family used, you just want to connect. This is a significant >>>>> difference from using ping or traceroute where you almost always >>>>> want a specific address family, depending on what you are testing. >>>> I strongly disagree with the "almost always want a specific address >>>> family". I normally want to verify that the IP at the other end is >>>> alive, or get some idea of how to get there. If I want a specific >>>> address family I'm very happy to use -4 / -6 options. >>>=20 >>> The IP at the other end will, by definition, always be either v4 or v6, >>> so yes, you do want a specific address family - namely the family your >>> IP belongs to. >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Thomas Steen Rasmussen >>>=20 >>>=20 >>> _______________________________________________ >>> 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" >> _______________________________________________ >> 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 --Apple-Mail-61706D92-1F83-4F14-826F-32D2255A0885 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIxMjAzMjUyNFowIwYJKoZIhvcN AQkEMRYEFFC9MpY/A+jtr+1oE8VPx6tNDgf8MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAktywMtMDTZ3TemfKTn1+ k0smUaYC+E0vGBTBZ+Q545lHgsQR3rO4u90hPSyG9zrVOWqZ4jGXaAq3QMaOKBwcP5N/fKUxNWgm mePGOMyfxFmj9zDBCdxfdUf+k1NX4we4VYY2mheanckQRM1BLjH+tY+UvZnpTRMHISJmHJK0oFrB iIRZRaAEnx3EM0+iqeEkUuNji3OAtsk8hTYS0fi/kiawc/z2gL78GjXGw09EzgoFh4MqPANa+dlt LZSTlkkukob2V+RI6YnpfpueahBgGoW7EbIJP3GfYN4wagRLD8kp4pTGfCOFqtk9hj5MmOqxXE90 klXMNnvyZaqupifOPwAAAAAAAA== --Apple-Mail-61706D92-1F83-4F14-826F-32D2255A0885-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 02:47:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 365E3A0B; Wed, 12 Feb 2014 02:47:16 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D86AB1666; Wed, 12 Feb 2014 02:47:15 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so13094160qae.13 for ; Tue, 11 Feb 2014 18:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=4niL9FfnftPB1j7gfKOyMfw6OrBlF2+ci16hFCF2hJA=; b=pQsS3qLDL/90RrgEN3fBHTLoKxtiTRAqwXPcSRRKEzXVaXvcnk/GR+zQ0Imj2W18Y+ eSPKxjMBagXkihg2B80zJxSM3zmPrncdBwO6EM12yyjML8ZABepFhSey6voYqrC5SXI2 jR2v8PFJ7o+gzs3cE6x0/LyYE6CUCQlDm0ktUz2MVzUsV8PSwHEOWFsRKgDC92DNisEI xWD2HvMMHbhXjxbLmmcgjggfE5AeIjtoNhkLEn9bxRj54gtEOmejJe6BAzW5XVzkkLFR iJiPkPhXJzCUTvoT4I/KqpkStc8hOvi2+SSWYfdDrGzXzHllCNCeEXqb5vvv1CPq7XiN Jdtw== MIME-Version: 1.0 X-Received: by 10.224.11.136 with SMTP id t8mr62871475qat.26.1392173234336; Tue, 11 Feb 2014 18:47:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 11 Feb 2014 18:47:14 -0800 (PST) Date: Tue, 11 Feb 2014 18:47:14 -0800 X-Google-Sender-Auth: e3EkuRPK5KGFmk_WZRtv80vt8o8 Message-ID: Subject: [flowtable] don't insert a flowtable entry if the lle isn't yet valid From: Adrian Chadd To: FreeBSD Net , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 02:47:16 -0000 Hi, Some of the collisions stem from the flowtable entry being created and inserted before the lle has completed - subsequent lookups will fail the LLE_VALID check, but inserting them will immediately fail due to a collision. This patch: * doesn't insert a flowtable entry until the lle is valid; * adds a counter to netstat to log when this happens. http://people.freebsd.org/~adrian/netflix/20140211-flowtable-no-insert-on-arp-not-done.diff I'd like to commit this to -HEAD and backport it to -10. Thanks! -a From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 05:26:33 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1037B6ED for ; Wed, 12 Feb 2014 05:26:33 +0000 (UTC) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCE321693 for ; Wed, 12 Feb 2014 05:26:32 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id n16so10338317oag.5 for ; Tue, 11 Feb 2014 21:26:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=sZa+s5icT6qLWgHB1u8RPVe6FXtwYNcPjFy7wchzli0=; b=SfJg8wBIICYT1XPVuwpBiQrsTdttUS5bK522QVL6RO/M9c8t3oAIdoxEQPKeWqvOll NCy7rmEbrIg/if9ftkmupkf2Hl60O2oOkXzVESPc3p6YwQGvwl9aq05UyzhfHasxB65/ Qvvs/KdCz4mJrtz9UOQDZxDoPNyKpu8oiceC9hXpPaqMDsJex2gtkYQqDmc/ryyvZsYe huFRw6CjK1sL/9ZGbr0UfPgJTnA/s8IqwXCG+h+4Fe/oKcSdJdHaxRCQBgWVA+0nLTqk LOTfOwEWWv9Z5vBTKEEfqs+Mlyny3EWzxycFoFy4g7EJr8+3SpKrIFYqeNEUyRxrrQSJ 0UTA== X-Gm-Message-State: ALoCoQlUDkRvju9LQxO/QEauFyVGisBTx9L/jYnHJ3CGzGjESg8JMJ33cqbhe8q50jWc7/v568bT X-Received: by 10.60.232.230 with SMTP id tr6mr34847728oec.23.1392182369944; Tue, 11 Feb 2014 21:19:29 -0800 (PST) Received: from [172.21.0.88] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id bx1sm128718292oec.8.2014.02.11.21.19.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 21:19:27 -0800 (PST) References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: X-Mailer: iPhone Mail (11B554a) From: Jim Thompson Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Date: Tue, 11 Feb 2014 23:19:26 -0600 To: Jason Hellenthal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Thomas Steen Rasmussen , Chris H , "lev@freebsd.org" , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 05:26:33 -0000 > On Feb 11, 2014, at 21:25, Jason Hellenthal wrote= : >=20 > Haha careful 64 might be considered 64bit protocol support ;-) IPv6 addresses are 128 bits, (because: innumeracy).=20 > and someone might confuse 46 as a DHCP option rfc2132 The NetBIOS node type? The joke might be funnier as 0x46, which is the VISA protocol (an instrument= ation bus). From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 05:28:37 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B2ED7A7 for ; Wed, 12 Feb 2014 05:28:37 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE04216A4 for ; Wed, 12 Feb 2014 05:28:36 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id c9so14697326qcz.13 for ; Tue, 11 Feb 2014 21:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aNNykkKffk2pBLDvT+NPqYB/qGVKVHxJ6EBsW2q6G2w=; b=FHzEV1ZK15vkB7zcQ+pYAF4J6rvvkPaKMbQG9DIsa81L6uTeHhIOGg0v8f0JYdv8NQ YogI6IZK7uNB01OzkT9IN3LmVHo3dfU0li5evE3VBAJRiwhVq+pszIH79z5afFGNDvPZ 4w+y+n3/JWvsAA+kIYClc9T+MGqgxfIDDIgdo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aNNykkKffk2pBLDvT+NPqYB/qGVKVHxJ6EBsW2q6G2w=; b=Jxm9A3T4VUBfwViw4raBMpu895z5SFnc/zCjGJd/fxStH9pkiD2ohroOglMDNS2C4s 7LXaw5RyyYB+/0xOwWEgdxDyyZLHUdUeuSN0Nb4x2coavpj1AY2h87tiD2aEIiA+aHeI jlHg//xfKX04cQ+I2tEA9oBg1c9sBqn0ummx7i86Ltsc9ogGqbM2aGmL+6uh3z9mY9y7 N9ROI5KoC5G15lZQsK4WkN2dp0kf0ujJICZfjSevO78S3uGQvAGU/5Awf0Ut6JRc1m00 tCn2TheJy766uxXWhW7hsnu51FNUk88oZBBMemmlAcRjIxX1Bk6jTufixBmtVMBVcbLw d7pw== X-Gm-Message-State: ALoCoQlQB8HI0BNZSlZn7UYPoxZc5Bl6q+8VnTj0B5C6htP9GKJD5bAed/kLDecjTpm6h/CYa2FI MIME-Version: 1.0 X-Received: by 10.140.82.175 with SMTP id h44mr61074698qgd.68.1392182915847; Tue, 11 Feb 2014 21:28:35 -0800 (PST) Received: by 10.140.97.75 with HTTP; Tue, 11 Feb 2014 21:28:35 -0800 (PST) X-Originating-IP: [75.128.101.59] In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Date: Wed, 12 Feb 2014 00:28:35 -0500 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: Jason Hellenthal To: Jim Thompson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Thomas Steen Rasmussen , Chris H , "lev@freebsd.org" , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 05:28:37 -0000 True... ping-rfc1149 & traceroute might be a little tricky, just sayin On Wed, Feb 12, 2014 at 12:19 AM, Jim Thompson wrote: > > > On Feb 11, 2014, at 21:25, Jason Hellenthal > wrote: > > Haha careful 64 might be considered 64bit protocol support ;-) > > > IPv6 addresses are 128 bits, (because: innumeracy). > > and someone might confuse 46 as a DHCP option rfc2132 > > > The NetBIOS node type? > > The joke might be funnier as 0x46, which is the VISA protocol (an instrumentation bus). > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 05:41:47 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F29DF8FD for ; Wed, 12 Feb 2014 05:41:47 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A44C217C1 for ; Wed, 12 Feb 2014 05:41:47 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id j15so13189506qaq.39 for ; Tue, 11 Feb 2014 21:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1L7TMXEEQB1p/1fEAmfH+fV9k9mclVlmjceXwzjtQrY=; b=rHTuACLiUZWlQP211Hqg4VbHhz9r0ZQfd0EN6vYQCqtlEmkM+nboPJA1DMZr4+FsOa aSWansfvdlb5Qs5wjgy/Vbq4iEphZK2vZxSikgOjCCmrQxuqq+xqLVpN0iJbpCQXrcYw anAIHDBPaJyJSeWV8Cbp3tHlEJwDKHuByh8gQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1L7TMXEEQB1p/1fEAmfH+fV9k9mclVlmjceXwzjtQrY=; b=BYde2A1OjF/i+QuttLt7j6uZuuz45UsyCCHsWvQ8JJnJCA18ESEdtcCVS8d36jBVBG OvZvmADLF35kEjlHrsC77/da2xwTA4k37mLfKunkdPw8qpUrw+xhdKD8xGf0kAI23qpM S1+d96hGcm5nIoNiCXtwWbhD7geC1w/WefoVvMNh+hl+KoClrKgupjLTbj8aopVx2hZE e3EoYUodQGnjrDSAK0mw6zGDJ8wnYmJrpJMjt36EnvKNT0cjaFpG8ZAgoaV5YwdSVGyN Ipx7+imkYmPp49jS60JYOanWW5Qy0oBTl0X6PqvP7ZufV/2s+I8jXqWLMWw8EiZgWgzA Jd4w== X-Gm-Message-State: ALoCoQkPaLE6tNYs6fV9uIdXAL/SwVKy9H0XdRriAqAXR/ytsoI4xjVQ/pI4QHYrpf3eYBgNs6Qv X-Received: by 10.140.85.179 with SMTP id n48mr59651639qgd.91.1392183706796; Tue, 11 Feb 2014 21:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.175.169 with HTTP; Tue, 11 Feb 2014 21:41:16 -0800 (PST) In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> From: Eitan Adler Date: Wed, 12 Feb 2014 00:41:16 -0500 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Cc: "lev@freebsd.org" , Thomas Steen Rasmussen , Chris H , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 05:41:48 -0000 On Wed, Feb 12, 2014 at 12:19 AM, Jim Thompson wrote: > > >> On Feb 11, 2014, at 21:25, Jason Hellenthal wrote: >> >> Haha careful 64 might be considered 64bit protocol support ;-) > > IPv6 addresses are 128 bits, (because: innumeracy). > >> and someone might confuse 46 as a DHCP option rfc2132 > > The NetBIOS node type? > The joke might be funnier as 0x46, which is the VISA protocol (an instrumentation bus). I'm just waiting for RFC 1149 support. -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 05:56:20 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1646112 for ; Wed, 12 Feb 2014 05:56:20 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F09718D4 for ; Wed, 12 Feb 2014 05:56:20 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id a108so754253qge.7 for ; Tue, 11 Feb 2014 21:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ks7FFHf0xmuT+4fKfPqch8Jxl0mZYZuBnuqfIas69Io=; b=F5jpZpumSU0xw2YOco1wGBcfaAoRbGwJ+i9EhLT9d+hKvB3HSZ1mQkEMpGffEjQUQL n1jPdmnWKl1oTWMM9vUgRxVseeMMXd4i8gUcTU9maJf9HPWVsQw91G1JwWd/5qZciSxJ 6UAjwxJPn2EMZi4eEL39nC4nx4cVRG4xNFQPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ks7FFHf0xmuT+4fKfPqch8Jxl0mZYZuBnuqfIas69Io=; b=dNPFssswjn8S3rUFPf/yInVJk+DxHkQ538W8u1ZVxs+gkXROX5vEdR0aS33TRIjC3T wVTmiutCRbFsRgeZnoPPN7EhL5zU3jIPatNnWpaVNhKl4Yd+rWvXpVoZrUh0YTRV22Zh ISnAJsbq3LftIUehsA/vM4JIucLv2Ha2ps0GZ+bfX/sNMFCXG7IOsABaIjL2sgkzH77R uKpw+nug//KGNoBqHdDm9u7LyCh6u5USRAKT997jL4yd0Bj0r1YvFxtFnKdCp1TpXVnU 6Whk4SzRo8vlHIUHbYOfc2e+Mx8ZtHYgnytOgjCa5Vf1DDxC4p8f0PhHDXErh0VR0Tdg iUzA== X-Gm-Message-State: ALoCoQkKq6FiMiLVXqhtpJQkHlzbQmv9asm6FDqsQ+VIb0rj6RDKj7UaMZo87a7Uz25D6r9SB8d8 MIME-Version: 1.0 X-Received: by 10.140.80.53 with SMTP id b50mr61032167qgd.43.1392184579317; Tue, 11 Feb 2014 21:56:19 -0800 (PST) Received: by 10.140.97.75 with HTTP; Tue, 11 Feb 2014 21:56:19 -0800 (PST) X-Originating-IP: [75.128.101.59] In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Date: Wed, 12 Feb 2014 00:56:19 -0500 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: Jason Hellenthal To: Eitan Adler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "lev@freebsd.org" , Jim Thompson , Thomas Steen Rasmussen , Chris H , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 05:56:20 -0000 It would be awesome if there was a -rfc1149 flag that would print a ascii pigeon to the terminal... On Wed, Feb 12, 2014 at 12:41 AM, Eitan Adler wrote: > On Wed, Feb 12, 2014 at 12:19 AM, Jim Thompson wrote: > > > > > >> On Feb 11, 2014, at 21:25, Jason Hellenthal > wrote: > >> > >> Haha careful 64 might be considered 64bit protocol support ;-) > > > > IPv6 addresses are 128 bits, (because: innumeracy). > > > >> and someone might confuse 46 as a DHCP option rfc2132 > > > > The NetBIOS node type? > > The joke might be funnier as 0x46, which is the VISA protocol (an > instrumentation bus). > > I'm just waiting for RFC 1149 support. > > > > -- > Eitan Adler > From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 06:25:13 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E51B48B0; Wed, 12 Feb 2014 06:25:12 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8D1D1ADB; Wed, 12 Feb 2014 06:25:12 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so8713163pab.18 for ; Tue, 11 Feb 2014 22:25: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=iKJ2QkNTVTByqscPi65H1/eflrTPeTH9kIIId6tISXk=; b=oz00q7Bm+wZV/hZ65dWSkRiMX9OG52b2qMbM6QKyB3nmuFaGV579qjerYTAoEP/oKq 4VQsb0r8/84foTYT2cC2gGH8T2TOXcSojKio+BS4aDvUnXOF8KYnElQW1zb14ZGHLyVT Ibx2CtxJnuffbQzvxJFolppafMLlNYqTQd4eOs59cCZzVGSmNlBSypYhhCvEVS4Yvn26 tOPY9GHUgd+Kb8LWDgsl2dhIMbGy9PFXPJOuTVKk5TEsGFeupxsXvpzDEgeQzOUpOjrb lnxw19J9/WT2g6uWgpbqJHS5axTwFrmmtz1mMtNe8tktVzJRN9kj9yrKqaSwDMB77uQu soew== MIME-Version: 1.0 X-Received: by 10.66.121.234 with SMTP id ln10mr37182915pab.20.1392186312336; Tue, 11 Feb 2014 22:25:12 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Tue, 11 Feb 2014 22:25:12 -0800 (PST) In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Date: Tue, 11 Feb 2014 22:25:12 -0800 X-Google-Sender-Auth: Or25MvNbKOiJruB4YCglMfAQBM4 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: Kevin Oberman To: Jason Hellenthal Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "lev@freebsd.org" , Jim Thompson , Thomas Steen Rasmussen , Eitan Adler , Chris H , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:25:13 -0000 On Tue, Feb 11, 2014 at 9:56 PM, Jason Hellenthal wrote: > It would be awesome if there was a -rfc1149 flag that would print a ascii > pigeon to the terminal... > > > On Wed, Feb 12, 2014 at 12:41 AM, Eitan Adler > wrote: > > > On Wed, Feb 12, 2014 at 12:19 AM, Jim Thompson wrote: > > > > > > > > >> On Feb 11, 2014, at 21:25, Jason Hellenthal > > wrote: > > >> > > >> Haha careful 64 might be considered 64bit protocol support ;-) > > > > > > IPv6 addresses are 128 bits, (because: innumeracy). > > > > > >> and someone might confuse 46 as a DHCP option rfc2132 > > > > > > The NetBIOS node type? > > > The joke might be funnier as 0x46, which is the VISA protocol (an > > instrumentation bus). > > > > I'm just waiting for RFC 1149 support. > > > > > > > > -- > > Eitan Adler > > > For those who are new at IPv6, the ping6 and traceroute6 commands come from the WIDE KAME project. KAME developed one of the earliest IPv6 stacks and WIDE used FreeBSD. It became the FreeBSD IPv6 stack and the ping6 and traceroute6 utilities were brought in with the rest of the KAME code. When these tools were written, the IPv6 stack and the supporting libraries and APIs were very primitive. I suspect that it was quicker to write new tools than to try to integrate IPv6 into the existing standard tools and , when things were so rough, there was a clear effort to avoid changes to working IPv4 code. Separate IPv4 and IPv6 tools made sense then, but the need has long vanished... probably even before the KAME project ended. But the old, separate tools lived on through simple inertia. And so it is today. Inertia is NO reason that it should be this way forever. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 11:13: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3FD06BB; Wed, 12 Feb 2014 11:13:27 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id B2D4615C8; Wed, 12 Feb 2014 11:13:27 +0000 (UTC) Received: from [10.71.14.30] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N0V00LOGODTE750@st11p09mm-asmtp001.mac.com>; Wed, 12 Feb 2014 10:13:09 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-02-12_03:2014-02-12,2014-02-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1401130000 definitions=main-1402120020 Content-type: multipart/signed; boundary="Apple-Mail=_32E6992C-E0BD-4E35-BEAC-4CC98DE269FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: gifconfig_gifX not working with cloned_interfaces? From: Kimmo Paasiala In-reply-to: <20140212.065059.1470588740590268007.hrs@allbsd.org> Date: Wed, 12 Feb 2014 12:12:57 +0200 Message-id: References: <20140212.065059.1470588740590268007.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 11:13:28 -0000 --Apple-Mail=_32E6992C-E0BD-4E35-BEAC-4CC98DE269FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 11.2.2014, at 23.50, Hiroki Sato wrote: > Kimmo Paasiala wrote > in : >=20 > kp>=20 > kp> On 22.12.2013, at 12.05, Kimmo Paasiala = wrote: > kp>=20 > kp> >=20 > kp> > On 22.12.2013, at 12.01, Olivier Cochard-Labb=C3=A9 = > kp> > wrote: > kp> >=20 > kp> >> On Sat, Dec 21, 2013 at 9:27 PM, Kimmo Paasiala = > kp> >> wrote: > kp> >>>=20 > kp> >>> FreeBSD 10.0-RC2 r259413 i386. > kp> >>>=20 > kp> >>> I have this set up in rc.conf: > kp> >>>=20 > kp> >>> cloned_interfaces=3D"gif0" > kp> >>> gifconfig_gif0=3D"88.xxx.xxx.xxx 62.yyy.yyy.yyy" > kp> >>> ifconfig_gif0_ipv6=3D"inet6 2001:14b8:aaa:bbb::2 = 2001:14b8:aaa:bbb::1 > kp> >>> prefixlen 128=E2=80=9D > kp> >>>=20 > kp> >>> I=E2=80=99m not using gif_interfaces=3D=E2=80=9Cgif0=E2=80=9D = since it=E2=80=99s deprecated as per > kp> >>> the warning messages spewed by the rc(8) scripts. > kp> >>>=20 > kp> >>> However this does not work properly The =E2=80=98ifconfig gif0 = tunnel > kp> >>> 88.xxx.xxx.xxx 62.yyy.yyy.yyy=E2=80=99 does not get executed. = It looks to me > kp> >>> that the tunnel set up is only performed when gif0 is listed = in > kp> >>> gif_interfaces. > kp> >>>=20 > kp> >>> I can work around this by doing this instead of the = 'gifconfig_gif0' > kp> >>> line: > kp> >>>=20 > kp> >>> ifconfig_gif0=3D=E2=80=9C tunnel 88.xxx.xxx.xxx = 62.yyy.yyy.yyy=E2=80=9D > kp> >>>=20 > kp> >>=20 > kp> >> Hi, > kp> >>=20 > kp> >> You can configure gif interface like a standard interface = (without > kp> >> using gifconfig_), here is an example: > kp> >>=20 > kp> >> cloned_interfaces=3D"gif0 gif1" > kp> >> ifconfig_gif0=3D"inet 10.0.24.2/24 10.0.24.4 tunnel 10.0.23.2 = 10.0.34.4 > kp> >> up" > kp> >> ifconfig_gif1_ipv6=3D"inet6 2001:db8:24::2 prefixlen 64 tunnel > kp> >> 2001:db8:23::2 2001:db8:34::4 up" > kp> >>=20 > kp> >> Regards, > kp> >>=20 > kp> >> Olivier > kp> >=20 > kp> > Hi, > kp> >=20 > kp> > Yes I know. I did note that in my workaround for the problem. = However, > kp> > the rc.conf(5) manual page claims that gifconfig_gifX should = still > kp> > work and that=E2=80=99s why I=E2=80=99m reporting the issue. > kp> >=20 > kp> > -Kimmo > kp> >=20 > kp>=20 > kp> Hello, > kp>=20 > kp> Has anyone had time to look at this issue? I could try to come up = with > kp> a fix myself but I=E2=80=99d first like to know what is the proper = way > kp> configure gif(4) interfaces with FreeBSD 10. If gif_interfaces is > kp> deprecated then is gifconfig_gifX also deprecated? If = gifconfig_gifX > kp> is also deprecated then this is a documentation issue and also the > kp> rc(8) scripts should warn about using it like they do now warn = about > kp> gif_interfaces. If gifconfig_gifX is still valid then something = must > kp> be done about the handling of cloned_interfaces in rc.conf. >=20 > gifconfig_gifN is also deprecated. Combination of gif_interfaces and > gifconfig_gifN still works, but it should be rewritten with > cloned_interfaces and ifconfig_IF. I will add an warning message to > gifconfig_gifN, too. >=20 > -- Hiroki Hello, Thanks for the information. I think the rc.conf(5) manual page needs = updating as well for FreeBSD 10. It now says: gif_interfaces (str) This variable is deprecated in favor of cloned_interfaces. Set to the list of gif(4) tunnel = inter=E2=80=90 faces to configure on this host. A = gifconfig_=E2=9F=A8interface=E2=9F=A9 variable is assumed to exist for each value of = interface. The value of this variable is used to configure the = link layer of the tunnel according to the syntax of the = tunnel option to ifconfig(8). Additionally, this option = ensures that each listed interface is created via the create = option to ifconfig(8) before attempting to configure it. This should be reworded so that it says that gifconfig_ is = also a deprecated variable and also mention that it does not work with = cloned_interfaces (the reason for my PR). Also it should be mentioned = that the proper way to configure the tunnel part of the gif(4) interface = is to use ifconfig_gifN=3D=E2=80=9Ctunnel my.ip their.ip=E2=80=9D. Maybe = it=E2=80=99s also worth repeating the information in the gif(4) manual = page? -Kimmo --Apple-Mail=_32E6992C-E0BD-4E35-BEAC-4CC98DE269FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJS+0kwAAoJEFvLZC0FWRVpQ+0H/0GG383qDXMA0V5IhyszlNg4 LytcrXlkE3JfJ2D/7aU7D6GcrjSbp7N2PHifYhqYPOGdc6QhqrsMKF8zmSC1Jt/4 fr3sek1BE5XV6UaAawSbsWtUz0kX6Fy1uzCoNnPbwvY+2G50uKk/BZ8FL07tA4oW /pj9/CSdsmGxrhdLZ94DuKtCywEH+99im1ezYBwUVd7dY6YVuw+eTyyNKCBDE5kI AvqHTPMYpE9ihbNFFvZLOg7Gdu3a0kCXAVAHVn28/xBFPRsmbddSXGqsfGyBIsdw qLPn4a551OmFahcwTpxb3TKBz8gRwUfMZ66cl93OsFPKANAzftaSwNu1Uvsf+h8= =2n5u -----END PGP SIGNATURE----- --Apple-Mail=_32E6992C-E0BD-4E35-BEAC-4CC98DE269FB-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 14:37:26 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABB766E9 for ; Wed, 12 Feb 2014 14:37:26 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60B6B1955 for ; Wed, 12 Feb 2014 14:37:25 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h16so11059864oag.10 for ; Wed, 12 Feb 2014 06:37:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=0rem0/eltFEoTLykQhe4Ll1lF7M02asFpisXp1d/b8s=; b=L4zUOF86vY2OAtnNiRov1jUOgV3CbNwgQbuZMiu7AaMoUuzR9/Zada9rp7B0IFF+n6 383moQblqNLaZ+72zMkDa6gy/wPIxVUzLV+JNZGVgg8DXIGgbSKcvq+4mPBD432zhgif clpfWjgoi/fswdEuc6jl877vDg+1IdVPGkU+Jf+dUkdFYBwgxY6j23OO0Qf6MeY3sSJ9 1yOchfK3eykti3/Tono3QG4tYYhajSftP/qhIvBw8pn7ng5olgOAB0rSE0lwzYaAt1ac hdCOPA+DHiStkzVfXet9ayWKYuXaFMqjGKtLEntOcpSFVkW7bj+GVwbztlFCg3llMSE4 6KIw== X-Gm-Message-State: ALoCoQmMhOu2ew1DNU81cx1B/LqqslHs2CrqhQCeLEGO85AFni8gi4GTykEkPgXnCMIOBmkeoqaO X-Received: by 10.182.160.102 with SMTP id xj6mr37567397obb.19.1392215844975; Wed, 12 Feb 2014 06:37:24 -0800 (PST) Received: from [29.132.213.87] (66-87-121-87.pools.spcsdns.net. [66.87.121.87]) by mx.google.com with ESMTPSA id z5sm53204520obg.13.2014.02.12.06.37.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 06:37:23 -0800 (PST) References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <19669538-A27D-463B-B22E-99C6F5ED3AC9@netgate.com> X-Mailer: iPhone Mail (11B554a) From: Jim Thompson Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Date: Wed, 12 Feb 2014 08:37:21 -0600 To: Jason Hellenthal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "lev@freebsd.org" , Thomas Steen Rasmussen , Eitan Adler , Chris H , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:37:26 -0000 I'm sure you mean rfc6214.=20 (Once again, v4-centric thinking.) -- Jim > On Feb 11, 2014, at 23:56, Jason Hellenthal wrote= : >=20 > It would be awesome if there was a -rfc1149 flag that would print a ascii p= igeon to the terminal... >=20 >=20 >> On Wed, Feb 12, 2014 at 12:41 AM, Eitan Adler wrot= e: >> On Wed, Feb 12, 2014 at 12:19 AM, Jim Thompson wrote: >> > >> > >> >> On Feb 11, 2014, at 21:25, Jason Hellenthal w= rote: >> >> >> >> Haha careful 64 might be considered 64bit protocol support ;-) >> > >> > IPv6 addresses are 128 bits, (because: innumeracy). >> > >> >> and someone might confuse 46 as a DHCP option rfc2132 >> > >> > The NetBIOS node type? >> > The joke might be funnier as 0x46, which is the VISA protocol (an instr= umentation bus). >>=20 >> I'm just waiting for RFC 1149 support. >>=20 >>=20 >>=20 >> -- >> Eitan Adler >=20 From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 14:56:46 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39243BD3 for ; Wed, 12 Feb 2014 14:56:46 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D09C1ADE for ; Wed, 12 Feb 2014 14:56:46 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id rd3so9217974pab.5 for ; Wed, 12 Feb 2014 06:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=XKFBoQH5fO1KePJWvWRwJSLA0i2my8bJs5CnAiWGNgc=; b=IvdcM/vC7sN/wF47/9XFuHMIM6ZZbOtk4zxcVFU0qh7QYTENGRsDkshStp9UhLpxXT ILU8QSP3dZUtxnXq1pZPA4tTXDVROBjY1xtLz71wPnLHxbTJ6AF24gOo7v4d3YHor246 rRkb+RYlRAIZgOIboOt8zGPDtdCc0qDsFTXuyDtcbAuu4Nr4rYOygyV6/9+DL0lDx8K5 1eJT0TtnKYSUM7sHRxjUENLrEZZuHz502qPuFgWM+eYSqhe7Y+pkoFGD+rs8TL2mtoxK ZMnz51YKDiG91lIHxZ5VoJpZO9QUqK+Pa62KHq3+SMkuHb1KMMjDs20nSSBvIYfw1+os woUw== X-Received: by 10.66.164.70 with SMTP id yo6mr40280943pab.85.1392217005595; Wed, 12 Feb 2014 06:56:45 -0800 (PST) Received: from [192.168.1.64] (108-64-226-69.lightspeed.sntcca.sbcglobal.net. [108.64.226.69]) by mx.google.com with ESMTPSA id j3sm64392233pbh.38.2014.02.12.06.56.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 06:56:44 -0800 (PST) References: <20140211114329.43bda628@x23> Mime-Version: 1.0 (1.0) In-Reply-To: <20140211114329.43bda628@x23> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Vijay Singh Subject: Re: netstat for vnets Date: Wed, 12 Feb 2014 06:56:41 -0800 To: Marko Zec Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:56:46 -0000 On Feb 11, 2014, at 2:43 AM, Marko Zec wrote: > On Mon, 10 Feb 2014 21:24:52 -0800 > Vijay Singh wrote: >=20 >> How does "jexec netstat -an" get its data from the kernel? I >> know that netstat uses kvm, but I'm not sure how it works with >> vnet-jails. Any pointers would be much appreciated. >=20 > I think these days libkvm first tries to find "native" symbols via > kldsym(), and if it fails, attempts to prepend a "vnet_entry_" prefix > in front of the search key, which then get resolved to the proper > addres in _kvm_vnet_validaddr() in lib/libkvm/kvm_vnet.c. In the early > days of VIMAGE it was the kernel who was responsible for resolving the > symbol address in the proper vnet, honestly I do not recall when the > magic moved to the userland and why... >=20 > Btw. Vijay - did the patch I posted here: > http://lists.freebsd.org/pipermail/freebsd-net/2014-February/037769.html > resolve the panics you complained about? Marco, I got a chance to test it yesterday and it seems to work. Are you goi= ng to commit it? I think that there is still an issue with the V_loif pointe= r in the mbuf and it seems to me that we should add a refcount for that. It w= ould also help wit the interface hot plug case that Adrian has mentioned in t= he past. Anyhow, this change could go in. Please let me know when you've com= mitted it. -vijay= From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 16:52:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D601527 for ; Wed, 12 Feb 2014 16:52:52 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E91C16D3 for ; Wed, 12 Feb 2014 16:52:52 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s1CGqj7I043721; Wed, 12 Feb 2014 11:52:46 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <52FBA6D5.7010308@sentex.net> Date: Wed, 12 Feb 2014 11:52:37 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nikolay Denev Subject: forwarding performance (was Re: missing missing packets in igb stats ?) References: <52EC573B.109@sentex.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:52:52 -0000 On 2/2/2014 6:49 AM, Nikolay Denev wrote: > > Just a guess, but this might be happening before the driver. > Anything interesting in "netstat -s" for ip and udp? > > There is some inbound traffic on igb0. Are these ICMP udp port unreach? In that example it was. I was overwhelming the traffic sink on the other side I think. Anyways, I have managed to generate errors on the forwarding box. I setup a number of vlan interfaces and using fast boxes on the edge, I can generate errors. Now I have been trying to tweak the forwarding performance of the box as a router/firewall. The one box I am testing (igb nics) seems to max out at around 1.2Mpps kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 kern.random.sys.harvest.point_to_point=0 and hw.igb.max_interrupt_rate=64000 This is a Xeon E31220 @ 3.10GHz. -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 17:17:35 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 041D4B56 for ; Wed, 12 Feb 2014 17:17:35 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB79B18C1 for ; Wed, 12 Feb 2014 17:17:34 +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 81B4F25D37C3; Wed, 12 Feb 2014 17:17:32 +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 2F83EC22BE8; Wed, 12 Feb 2014 17:17:31 +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 a___2eIZfePi; Wed, 12 Feb 2014 17:17:29 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [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 66252C22BD1; Wed, 12 Feb 2014 17:17:27 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: netstat for vnets From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 12 Feb 2014 17:17:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140211114329.43bda628@x23> To: Vijay Singh X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:17:35 -0000 On 12 Feb 2014, at 14:56 , Vijay Singh wrote: >=20 > On Feb 11, 2014, at 2:43 AM, Marko Zec wrote: >=20 >> On Mon, 10 Feb 2014 21:24:52 -0800 >> Vijay Singh wrote: >>=20 >>> How does "jexec netstat -an" get its data from the kernel? I >>> know that netstat uses kvm, but I'm not sure how it works with >>> vnet-jails. Any pointers would be much appreciated. netstat -an should use sycsctls; see net.inet.tcp.pcblist , = net.inet.udp.pcblist , net.inet.raw.pcblist , net.local.stream.pcblist , = net.local.dgram.pcblist , etc. netstat -rn used to be the problem but a quick glance suggests that it = might use a sysctl as well these days? =97=20 Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 22:19:44 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBD33C93; Wed, 12 Feb 2014 22:19:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8E131518; Wed, 12 Feb 2014 22:19:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C3D7B94B; Wed, 12 Feb 2014 17:19:40 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Use of contiguous physical memory in cxgbe driver Date: Wed, 12 Feb 2014 14:46:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402121446.19278.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Feb 2014 17:19:40 -0500 (EST) Cc: FreeBSD Net , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:19:44 -0000 On Tuesday, February 11, 2014 6:30:04 pm Adrian Chadd wrote: > On 11 February 2014 10:48, John Baldwin wrote: > > On Thursday, January 23, 2014 2:32:51 am Adrian Chadd wrote: > >> It's about time we taught the physmem allocator to be more conducive > >> to physically contiguous allocations. > >> > >> A server with gigabytes of memory should be able to keep a couple tens > >> of megabytes of 64k sized allocation chunks around for exactly this. > > > > Alan Cox already taught the physmem allocator to do this for superpages. > > However, this change was part of the superpages changes, so you can't count > > experiences from machines older than about 7.2 when evaluating the > > effectiveness of the new allocator. > > the problem is that we don't have pressure to _not_ fragment the > physical memory from the allocator, so all of the memory ends up > getting very fragmented versy quickly. > > the physmem superpage stuff stops being viable after a short while of > say, "pound lots of packets around from vm objects" workload, because > suddenly we end up chewing through all of physical memory with pages > extremely quickly. Is this because UMA keeps lots of mbufs cached in your workload? The physmem buddy allocator certainly seeks to minimize fragmentation. However, it can't go yank memory out of UMA caches to do so. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Feb 12 23:36:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74EC4F13; Wed, 12 Feb 2014 23:36:40 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3F471AC3; Wed, 12 Feb 2014 23:36:39 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id x13so16361929qcv.5 for ; Wed, 12 Feb 2014 15:36:39 -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=RwfKH+5KON8WTuVODWmO2xavTqFByN5RXO9c/LZIPD4=; b=b9oFWmBnOAaznkB5baajBMS/KnWpGJbH74ztJgAByUvXyIiA0ElWHdFt20gSYmLNeW uyo8/IlwdQNqoeIVT9+k2Q2iubQlB124fZp1pbuk8vbva/WWaJ1XvrFlUTWhv09uJOeb kXGcmtCuxz4HlLmwqNv40BhJl5a9s4xeyxDpVO+2GnglJhvW1TBgiEwlH/0yZQuHcTBn z9jEbzrxmmAXKrBb1oYGhSiOgCAwgpnZcsE127dF7iXxvYCIHyvwB7dnHS2xGuEQZSlx ENyhfVP9vGZSp+MybUw5WjVgeTJy3tFo3wIGm+Lph2q+apPv4FNvtTCNwrChN6hAAL7b m5Xw== MIME-Version: 1.0 X-Received: by 10.140.42.138 with SMTP id c10mr20711264qga.24.1392248199042; Wed, 12 Feb 2014 15:36:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 12 Feb 2014 15:36:38 -0800 (PST) In-Reply-To: <201402121446.19278.jhb@freebsd.org> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> Date: Wed, 12 Feb 2014 15:36:38 -0800 X-Google-Sender-Auth: N3Rn8cmu0ZnH5limp9FP92J-NFc Message-ID: Subject: Re: Use of contiguous physical memory in cxgbe driver From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:36:40 -0000 On 12 February 2014 11:46, John Baldwin wrote: > Is this because UMA keeps lots of mbufs cached in your workload? The physmem > buddy allocator certainly seeks to minimize fragmentation. However, it can't > go yank memory out of UMA caches to do so. I'll ask you on irc, but where's that happening? My read of the code is that once it grabs a larger page and fragments it, it's lost. -a From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 02:02:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 185AE329; Thu, 13 Feb 2014 02:02:16 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BE935161A; Thu, 13 Feb 2014 02:02:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,836,1384318800"; d="scan'208";a="96260376" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Feb 2014 21:02:09 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 20597B4058; Wed, 12 Feb 2014 21:02:09 -0500 (EST) Date: Wed, 12 Feb 2014 21:02:09 -0500 (EST) From: Rick Macklem To: FreeBSD Net Message-ID: <165956022.5235196.1392256929127.JavaMail.root@uoguelph.ca> Subject: NFS threads getting stuck in vmem_bt_alloc() at "btalloc"? (mbuf allocation) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:02:16 -0000 I wrote: > I've been doing some testing using pagesize clusters (4K) for NFS > instead of mclbytes (2K) on a single core i386. > Sometimes I get threads stuck sleeping on "btalloc", which seems > to happen in vmem_bt_alloc(). > > The comment in vmem_bt_alloc() basically says: > out of address space or lost a fill race > Since this is persistent, I suspect it is the first case? > > So, does anyone know what is going on here or what I should look > at to try and resolve this? > > Btw, when I am testing, I don't see the pagesize cluster allocation > exceed 400, so it doesn't seem to be a leak or excessive allocation. > > Thanks in advance for any help, rick I originally posted this to freebsd-hackers@, but since it seems to be related to mbuf allocation, I thought it might be better here. When I posted this, I knew nothing about uma or the current mbuf allocation mechanisms. Now, I know a little bit and the story is getting interesting... Currently, NFS does: MGET(..M_WAITOK); MCLGET(..M_NOWAIT); when it wants an mbuf cluster. It was done this way long ago, because mbuf clusters could become exhausted and this allowed NFS to limp along, using long lists of regular mbufs for the data (NFS RPC messages). Now, it seems that this does the following (MCLGET() is just m_clget(), which is an inline function in sys/mbuf.h): MGET(..M_WAITOK) - always returns an mbuf m_clget(..M_NOWAIT) - calls uma_alloc_arg(zone_clust, M_NOWAIT..) if this fails, it then zone_drain(zone_pack); calls uma_alloc_arg(zone_clust, M_NOWAIT..) again As such, it will zone_drain(zone_pack) when cluster allocations become difficult (including when a uma zone allocation for a boundary tag can't succeed without waiting). I suspect this usually fixes the problem and the second attempt succeeds. However, even if the second attempt fails, NFS still has an mbuf and doesn't get stuck in "btalloc". When I was doing recent testing to see how pagesize clusters would work, I switched to m_getjcl(..M_WAITOK..), which can get stuck in "btalloc" if an attempt to allocate a boundary tag fails, due to lack of kernel address space. I test on i386, but it still isn't obvious how I exhausted kernel address space? One thing I notice is that zone_pack is set to the same limit as the mbuf zone at 168765. However, unlike the mbuf zone, I think that many of the entries in zone_pack will have a cluster associated with them. I am thinking that the limit for zone_pack is on the high side, since zone_clust is limited to 26368 on my i386 and maybe this is how kernel address space gets exhausted? In summary, to play it safe, I think that if NFS is going to use pagesize clusters, it needs to: - call m_getjcl(..M_NOWAIT..); /* call with M_NOWAIT */ - if this fails (returns NULL) then - call MGET(..M_WAITOK..) - call MCLGET(.. M_NOWAIT..) That way, I don't think the NFS threads can get stuck sleeping on "btalloc" and calls to zone_drain(zone_pack) will happen when allocation gets constrained. This means that the length of the mbuf list for a read reply could be - length (64K or whatever) / MLEN for the worst case, since allocation of clusters isn't guaranteed. (Garrett, I think you have to make your iovec that big if you are going to use a fixed size allocation instead of the current code, which malloc()s enough for the list.) It seems to me that m_getcl()/m_getjcl() should do a zone_drain(zone_pack) when an allocation fails (for M_NOWAIT), but that is just a suggestion? What do others think of the above? rick From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 04:50:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB9F0615; Thu, 13 Feb 2014 04:50:00 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5836116BA; Thu, 13 Feb 2014 04:50:00 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1D4nvEQ002577; Wed, 12 Feb 2014 23:49:57 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1D4nvpL002574; Wed, 12 Feb 2014 23:49:57 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21244.20212.423983.960018@hergotha.csail.mit.edu> Date: Wed, 12 Feb 2014 23:49:56 -0500 From: Garrett Wollman To: John Baldwin Subject: Re: Use of contiguous physical memory in cxgbe driver In-Reply-To: <201402121446.19278.jhb@freebsd.org> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 12 Feb 2014 23:49:57 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 04:50:00 -0000 < said: > Is this because UMA keeps lots of mbufs cached in your workload? > The physmem buddy allocator certainly seeks to minimize > fragmentation. However, it can't go yank memory out of UMA caches > to do so. It's not just UMA caches: there are TCP queues, interface queues, the NFS request "cache", and elsewhere. I first discovered this problem in the NFS context: what happens is that you build up very large TCP send buffers (NFS forces the socket buffers to 2M) for many clients (easy if the server is dedicated 10G and the clients are all on shared 1G links). The NIC is eventually unable to replenish its receive ring, and everything just stops. Eventually, the TCP connections time out, the buffers are freed, and the server mysteriously starts working again. (Actually, the last bit never happens in production. It's more like: Eventually, the users start filing trouble tickets, then Nagios starts paging the sysadmins, then someone does a hard reset because that's the fastest way to recover. And then they blame me.) -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 05:21:06 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 464532D8 for ; Thu, 13 Feb 2014 05:21:06 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E76B918C7 for ; Thu, 13 Feb 2014 05:21:05 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id e16so16908977qcx.38 for ; Wed, 12 Feb 2014 21:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IgwaBqRnN9l8XYGkE57opJCc3P/r9Ynmzt35VrEf754=; b=R0/2fbDKdt7GDAOq3VxtzeeokcJCtns8NZ4IFj5GP4/dVe8qy1nJBJmqEKYPMuUBFu 1Po686coLmWhwesM8Gf/WeSbk852+TI/IOtFnXBJk7H/Pa1kscRxvh2gi0gK1wxBm/kJ NQUYoN0ku/iqCWK1TbkHooFCWrSo+kDwo6oTE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IgwaBqRnN9l8XYGkE57opJCc3P/r9Ynmzt35VrEf754=; b=iUTkt37jn0Q0De2HboJCySKBLS961cp0cAiAUQZ/v3fHasTVJevCjKcwBVdm3r0bR3 SFRJ8IdzEVkZD5Wm8IkCK0fFtkne2sKximkzYJAMjZA+zESIOKrMC2/2ZFULnuokWTSt 3nSzPWDYX6cl7VffJKaPoCgo/ItxaZsglHf8EhWzsMAzhKqOGrAMB1KSrZ964MyI57dH 4uiyE7k/F92n2aIAUluahv6Lu9Wp+aKfJ+7xq4IJEecfgehp08PBdJ1Bp8LBqkI8Bz6L t3CpCrT9M/nakI+udPXLWTsFpnQL/PIkjtLmqpC3bVL5lgS4YNq0+ia7Fze9TYuGzaz3 4eXQ== X-Gm-Message-State: ALoCoQnTLgsMSZ/Ess0aUwX3p92z4uqGqtxaXmaa5WzK+g/WlQGjyVl+j2K2DJr8z1YYIfGrOSRp X-Received: by 10.140.96.245 with SMTP id k108mr70360670qge.60.1392268865112; Wed, 12 Feb 2014 21:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.175.169 with HTTP; Wed, 12 Feb 2014 21:20:35 -0800 (PST) In-Reply-To: <19669538-A27D-463B-B22E-99C6F5ED3AC9@netgate.com> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> <19669538-A27D-463B-B22E-99C6F5ED3AC9@netgate.com> From: Eitan Adler Date: Thu, 13 Feb 2014 00:20:35 -0500 Message-ID: Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? To: Jim Thompson Content-Type: text/plain; charset=UTF-8 Cc: "lev@freebsd.org" , Thomas Steen Rasmussen , Chris H , "sthaug@nethelp.no" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 05:21:06 -0000 On Wed, Feb 12, 2014 at 9:37 AM, Jim Thompson wrote: > > I'm sure you mean rfc6214. Yes. > (Once again, v4-centric thinking.) .-''-. / , \ .-'`(o) ; '-==. | `._...-;-. )--""" `-. / . `-. / / `. `-. | \ ; \ `-._________ | \ `.`.; -------`. \ `-. \\\\ `---...| `. `-. ```\.--'._ `---...| `-.....7`-.))\ `-._`-.. / `._\ / `-` `-.,' / / /=(_ -./--' ` hjw ,^-(_ ,--' ` -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 05:48:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18A2196F; Thu, 13 Feb 2014 05:48:16 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92C9C1B9F; Thu, 13 Feb 2014 05:48:14 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s1D5mCGB030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Feb 2014 09:48:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s1D5mCIk030240; Thu, 13 Feb 2014 09:48:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Feb 2014 09:48:12 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: flowtable, collisions, locking and CPU affinity Message-ID: <20140213054812.GK26785@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 05:48:16 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 07, 2014 at 04:12:56PM -0800, Adrian Chadd wrote: A> I've been knee deep in the flowtable code looking at some of the less A> .. predictable ways it behaves. A> A> One of them is the collisions that do pop up from time to time. A> A> I dug into it in quite some depth and found out what's going on. This A> assumes it's a per-CPU flowtable. A> A> * A flowtable lookup is performed, on say CPU #0 A> * the flowtable lookup fails, so it goes to do a flowtable insert A> * .. but since in between the two, the flowtable "lock" is released so A> it can do a route/adjacency lookup, and that grabs a lock A> * .. then the flowtable insert is done on a totally different CPU A> * .. which happens to _have_ the flowtable entry already, so it fails A> as a collision which already has a matching entry. A> A> Now, the reason for this is primarily because there's no CPU pinning A> in the lookup path and if there's contention during the route lookup A> phase, the scheduler may decide to schedule the kernel thread on a A> totally different CPU to the one that was running the code when the A> lock was entered. A> A> Now, Gleb's recent changes seem to have made the instances of this A> drop, but he didn't set out to fix it. So there's something about his A> changes that has changed the locking/contention profile that I was A> using to easily reproduce it. A> A> In any case - the reason it's happening above is because there's no A> actual lock held over the whole lookup/insert path. It's a per-CPU A> critical enter/exit path, so the only way to guarantee consistency is A> to use sched_pin() for the entirety of the function. A> A> I'll go and test that out in a moment and see if it quietens the A> collisions that I see in lab testing. A> A> Has anyone already debugged/diagnosed this? Can anyone think of an A> alternate (better) way to fix this? Can't we just reuse the colliding entry? Can you evaluate patch attached (against head) in your testing conditions? -- Totus tuus, Glebius. --BXVAT5kNtrzKuDFl Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="flowtable_collisions.diff" Index: sys/net/flowtable.c =================================================================== --- sys/net/flowtable.c (revision 261825) +++ sys/net/flowtable.c (working copy) @@ -716,21 +716,39 @@ flow_full(struct flowtable *ft) } static int +flow_matches(struct flentry *fle, uint32_t hash, uint32_t *key, uint8_t + proto, uint32_t fibnum) +{ + + if (fle->f_fhash == hash && + bcmp(&fle->f_flow, key, KEYLEN(fle->f_flags)) == 0 && + proto == fle->f_proto && fibnum == fle->f_fibnum && + (fle->f_rt->rt_flags & RTF_UP) && + fle->f_rt->rt_ifp != NULL && + (fle->f_lle->la_flags & LLE_VALID)) + return (1); + + return (0); +} + +static struct flentry * flowtable_insert(struct flowtable *ft, uint32_t hash, uint32_t *key, uint32_t fibnum, struct route *ro, uint16_t flags) { struct flist *flist; struct flentry *fle, *iter; + bitstr_t *mask; int depth; - bitstr_t *mask; + uint8_t proto; fle = uma_zalloc(flow_zone, M_NOWAIT | M_ZERO); if (fle == NULL) - return (ENOMEM); + return (NULL); + proto = flags_to_proto(flags); bcopy(key, &fle->f_flow, KEYLEN(flags)); fle->f_flags |= (flags & FL_IPV6); - fle->f_proto = flags_to_proto(flags); + fle->f_proto = proto; fle->f_rt = ro->ro_rt; fle->f_lle = ro->ro_lle; fle->f_fhash = hash; @@ -748,21 +766,24 @@ flowtable_insert(struct flowtable *ft, uint32_t ha } depth = 0; - FLOWSTAT_INC(ft, ft_collisions); /* * find end of list and make sure that we were not * preempted by another thread handling this flow */ SLIST_FOREACH(iter, flist, f_next) { - if (iter->f_fhash == hash && !flow_stale(ft, iter)) { + if (flow_matches(iter, hash, key, proto, fibnum)) { /* - * there was either a hash collision - * or we lost a race to insert + * We probably migrated to an other CPU after + * lookup in flowtable_lookup_common() failed. + * It appeared that this CPU already has flow + * entry. */ + iter->f_uptime = time_uptime; + iter->f_flags |= flags; critical_exit(); + FLOWSTAT_INC(ft, ft_collisions); uma_zfree(flow_zone, fle); - - return (EEXIST); + return (iter); } depth++; } @@ -773,8 +794,9 @@ flowtable_insert(struct flowtable *ft, uint32_t ha SLIST_INSERT_HEAD(flist, fle, f_next); skip: critical_exit(); + FLOWSTAT_INC(ft, ft_inserts); - return (0); + return (fle); } struct flentry * @@ -885,12 +907,7 @@ flowtable_lookup_common(struct flowtable *ft, stru critical_enter(); flist = flowtable_list(ft, hash); SLIST_FOREACH(fle, flist, f_next) - if (fle->f_fhash == hash && bcmp(&fle->f_flow, key, - KEYLEN(fle->f_flags)) == 0 && - proto == fle->f_proto && fibnum == fle->f_fibnum && - (fle->f_rt->rt_flags & RTF_UP) && - fle->f_rt->rt_ifp != NULL && - (fle->f_lle->la_flags & LLE_VALID)) { + if (flow_matches(fle, hash, key, proto, fibnum)) { fle->f_uptime = time_uptime; fle->f_flags |= flags; critical_exit(); @@ -968,7 +985,8 @@ flowtable_lookup_common(struct flowtable *ft, stru } ro->ro_lle = lle; - if (flowtable_insert(ft, hash, key, fibnum, ro, flags) != 0) { + fle = flowtable_insert(ft, hash, key, fibnum, ro, flags); + if (fle == NULL) { RTFREE(rt); LLE_FREE(lle); return (NULL); @@ -975,10 +993,11 @@ flowtable_lookup_common(struct flowtable *ft, stru } success: - if (fle != NULL && (m->m_flags & M_FLOWID) == 0) { + if (m->m_flags & M_FLOWID) { m->m_flags |= M_FLOWID; m->m_pkthdr.flowid = fle->f_fhash; } + return (fle); } Index: sys/net/flowtable.h =================================================================== --- sys/net/flowtable.h (revision 261825) +++ sys/net/flowtable.h (working copy) @@ -39,6 +39,7 @@ struct flowtable_stat { uint64_t ft_frees; uint64_t ft_hits; uint64_t ft_lookups; + uint64_t ft_inserts; }; #ifdef _KERNEL Index: usr.bin/netstat/flowtable.c =================================================================== --- usr.bin/netstat/flowtable.c (revision 261825) +++ usr.bin/netstat/flowtable.c (working copy) @@ -52,6 +52,7 @@ print_stats(struct flowtable_stat *stat) p(ft_lookups, "\t%ju lookup%s\n"); p(ft_hits, "\t%ju hit%s\n"); p2(ft_misses, "\t%ju miss%s\n"); + p(ft_inserts, "\t%ju insert%s\n"); p(ft_collisions, "\t%ju collision%s\n"); p(ft_free_checks, "\t%ju free check%s\n"); p(ft_frees, "\t%ju free%s\n"); --BXVAT5kNtrzKuDFl-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 07:48: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 535B0BEB; Thu, 13 Feb 2014 07:48:46 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F408E14E4; Thu, 13 Feb 2014 07:48:45 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so15907890qaq.1 for ; Wed, 12 Feb 2014 23:48:44 -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=GIBQgbflLf5rO4x+eVtCXQ1GsmIzB/ZnL7i8xdLYAHM=; b=gJ0GvDRFMakNvS3Dem1/wZK71qO240T2bzgSeRRqgVYKkEhhsI1uKrfFD1nCqGDaZE mYaj7aHhY0zxdOSYb/+d80OYhQQ5yWAq5YnyZFMKp6WEFu+OFEC+blcG+/sWa4HmZo6F l1ZUXofxGq8w87jtHXCKCB/AlxqzxGfcsn2xsHLT1ss6l+f3u6IPllnEj8SfpwgpOU1s mABJr1x6XcHQmIcXMo1wLkdILRrBq2Kujm+zXzsLKMrYNnFzYgmnECvS+hnlmXBRqC9Q yXfvpKUViu4SK8QX7o98y0cE3FNP6inpWu2xNsySTZWemj1xVrYzYJPybzcpYeg+W01n xyjw== MIME-Version: 1.0 X-Received: by 10.224.61.2 with SMTP id r2mr4720qah.49.1392277724680; Wed, 12 Feb 2014 23:48:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 12 Feb 2014 23:48:44 -0800 (PST) In-Reply-To: <20140213054812.GK26785@FreeBSD.org> References: <20140213054812.GK26785@FreeBSD.org> Date: Wed, 12 Feb 2014 23:48:44 -0800 X-Google-Sender-Auth: dmXUEUTy4Ml4veCRlsMsh-q-qKA Message-ID: Subject: Re: flowtable, collisions, locking and CPU affinity From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:48:46 -0000 On 12 February 2014 21:48, Gleb Smirnoff wrote: > On Fri, Feb 07, 2014 at 04:12:56PM -0800, Adrian Chadd wrote: > A> I've been knee deep in the flowtable code looking at some of the less > A> .. predictable ways it behaves. > A> > A> One of them is the collisions that do pop up from time to time. > A> > A> I dug into it in quite some depth and found out what's going on. This > A> assumes it's a per-CPU flowtable. > A> > A> * A flowtable lookup is performed, on say CPU #0 > A> * the flowtable lookup fails, so it goes to do a flowtable insert > A> * .. but since in between the two, the flowtable "lock" is released so > A> it can do a route/adjacency lookup, and that grabs a lock > A> * .. then the flowtable insert is done on a totally different CPU > A> * .. which happens to _have_ the flowtable entry already, so it fails > A> as a collision which already has a matching entry. > A> > A> Now, the reason for this is primarily because there's no CPU pinning > A> in the lookup path and if there's contention during the route lookup > A> phase, the scheduler may decide to schedule the kernel thread on a > A> totally different CPU to the one that was running the code when the > A> lock was entered. > A> > A> Now, Gleb's recent changes seem to have made the instances of this > A> drop, but he didn't set out to fix it. So there's something about his > A> changes that has changed the locking/contention profile that I was > A> using to easily reproduce it. > A> > A> In any case - the reason it's happening above is because there's no > A> actual lock held over the whole lookup/insert path. It's a per-CPU > A> critical enter/exit path, so the only way to guarantee consistency is > A> to use sched_pin() for the entirety of the function. > A> > A> I'll go and test that out in a moment and see if it quietens the > A> collisions that I see in lab testing. > A> > A> Has anyone already debugged/diagnosed this? Can anyone think of an > A> alternate (better) way to fix this? > > Can't we just reuse the colliding entry? > > Can you evaluate patch attached (against head) in your testing > conditions? It's late and I'm exhausted, but I think one of the things that stood out to me was the uncertainty as to whether the thread being preempted by some work would end up being resumed on the same CPU, or whether it could resume on a different CPU. If that happened whilst the flowtable code ran on a different CPU, things could be freed from underneath the code that's about to use it. I'll look at this in some more depth tomorrow, but I think the safest thing to do right now is to sched_pin() to make the concurrency locking model consistent. The window of opportunity for things to get resumed on a different CPU may be almost-zero, but we're doing this over a million times a second on some forwarding based platforms. Thanks, -a From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 07:57:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 573C6DD2; Thu, 13 Feb 2014 07:57:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30A4F15B2; Thu, 13 Feb 2014 07:57:05 +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 s1D7upI7085332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Feb 2014 23:56: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 s1D7up1i085331; Wed, 12 Feb 2014 23:56:51 -0800 (PST) (envelope-from jmg) Date: Wed, 12 Feb 2014 23:56:51 -0800 From: John-Mark Gurney To: Garrett Wollman Subject: Re: Use of contiguous physical memory in cxgbe driver Message-ID: <20140213075651.GY34851@funkthat.com> Mail-Followup-To: Garrett Wollman , John Baldwin , FreeBSD Net References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21244.20212.423983.960018@hergotha.csail.mit.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Feb 2014 23:56:52 -0800 (PST) Cc: FreeBSD Net , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:57:06 -0000 Garrett Wollman wrote this message on Wed, Feb 12, 2014 at 23:49 -0500: > < said: > > > Is this because UMA keeps lots of mbufs cached in your workload? > > The physmem buddy allocator certainly seeks to minimize > > fragmentation. However, it can't go yank memory out of UMA caches > > to do so. > > It's not just UMA caches: there are TCP queues, interface queues, the > NFS request "cache", and elsewhere. I first discovered this problem > in the NFS context: what happens is that you build up very large TCP > send buffers (NFS forces the socket buffers to 2M) for many clients > (easy if the server is dedicated 10G and the clients are all on shared > 1G links). The NIC is eventually unable to replenish its receive > ring, and everything just stops. Eventually, the TCP connections time > out, the buffers are freed, and the server mysteriously starts working > again. (Actually, the last bit never happens in production. It's > more like: Eventually, the users start filing trouble tickets, then > Nagios starts paging the sysadmins, then someone does a hard reset > because that's the fastest way to recover. And then they blame me.) This is an issue that most ethernet drivers have in that they require the ability to fetch a new mbuf to replace the received one instead of delaying the replacement till later... If the driver allowed the receive ring to be "missing" a few buffers that are potentially filled upon next RX, it would allow the machine forward progress and possibly free up a ton of mbufs... Maybe that dropped frame is an ack that will free up 10 or more mbufs, but we'll never know since we just drop it on the floor... Though we might want to keep a few mbufs reserved for receive now that you mention it... We should never get to the point where we can't allocate even one frame for receive... -- 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 Feb 13 09:14:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85F07C5D for ; Thu, 13 Feb 2014 09:14:39 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 20F5E1BC5 for ; Thu, 13 Feb 2014 09:14:38 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id f8so8203996wiw.15 for ; Thu, 13 Feb 2014 01:14:37 -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=8dmZoOi7TragLODzVSkWFt5AMo1AajHYaiCZCXzxnhk=; b=aKJQKWgA7JCOoMnLVoodYtcmS8Vw0+ME7eLIZXQhFl3Z648WM91yZyVFjDXV3wBgjf 8PRLGMuDwpIc0axLrEFWiOM+MRyGXG4qzPGRtwxZ4SVSgJYInFKSUshPpA2jpOPChxEa 89lzLxjlTHNnNQZeGnnurm39IuI9b8SztpWY/J7qICp7HO42KRX8oe729Qg8P6PBYNUQ AiTd5ikNlh7RxCS7C4jlWGFIvBRgo5sFoExUhrgFKZjCSRQ8uhDTWVx4/yeIYWiT1jQK fi2R+sKTyDkRnA+SQLCKszS0XsDfH6JNoa4BDrONswcp1Q+FqvZ9lH2c+gvDUJ1QGb4N Jumg== MIME-Version: 1.0 X-Received: by 10.180.189.10 with SMTP id ge10mr5451230wic.47.1392282877523; Thu, 13 Feb 2014 01:14:37 -0800 (PST) Received: by 10.194.29.163 with HTTP; Thu, 13 Feb 2014 01:14:37 -0800 (PST) Date: Thu, 13 Feb 2014 09:14:37 +0000 Message-ID: Subject: Recommendations for packet capture From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:14:39 -0000 Hi all, I need to setup some FreeBSD (or Linux, it depends) hosts to use as a packet capture sensors for our infrastrucutre. Searching about software that I could use under FreeBSD, I only find these ones: a) daemonlogger b) streamdb For Linux, it seems exits more alternatives. Any suggestions?? I need to monitor 1 GiB networks. Thanks. From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 13:32:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35FB3997; Thu, 13 Feb 2014 13:32:52 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF6B7147B; Thu, 13 Feb 2014 13:32:51 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id c14so8565620vea.31 for ; Thu, 13 Feb 2014 05:32:51 -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=Ws8Tve3BytE4/BldzPXyw4etfNNmBJd5K+X5uJHBZEI=; b=t0TxK6QS83EyQiX7+Wel7esyUYWHjZ0qnoovUwveh0m+TQQk2JzkYfxn1R/KAfzK2D l7A48a5EyGuDeNX+0qW4trOYH9ru9DCAVbAbZnmpx8ncvH09AJ5+pH60PcNLT4J8lc5f dMB7qVZPQ+nax75Z+HLWG7MQgFeVqM9Dtf0h19umFlUv+5EDG3Xx9i+W23C8N0X9IP66 lz8kraAhP9/QGeIk6jQlIwfJFH7MoELDtmJ36yj/gPYOrKRcIQjgnSixC/JjXg2XCUdO 3Gnhwf8taqz3/k69yj6l3wixeNPv5vhaIoZpWT6C95eTrTwapJhlH38Tsyb+VvYSQUGP aKRw== MIME-Version: 1.0 X-Received: by 10.220.98.204 with SMTP id r12mr68015vcn.48.1392298371023; Thu, 13 Feb 2014 05:32:51 -0800 (PST) Received: by 10.52.180.200 with HTTP; Thu, 13 Feb 2014 05:32:50 -0800 (PST) In-Reply-To: <20140131035303.GT93141@funkthat.com> References: <1856284835.584005.1391139152133.JavaMail.root@uoguelph.ca> <20140131035303.GT93141@funkthat.com> Date: Thu, 13 Feb 2014 22:32:50 +0900 Message-ID: Subject: Re: 64K NFS I/O generates a 34mbuf list for TCP which breaks TSO From: =?ISO-2022-JP?B?GyRCPzk3cjBsGyhC?= To: Rick Macklem , Adrian Chadd , FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:32:52 -0000 4YC54YCE4YCD4YCC4YCB4YCA4YCh4YCj4YCp4YCq4YCn4YCx4YGD4YGE4YGJ4YGI4YCP4YCO4YCN 4YCM4YCL4YC94YC84YCE4YCh4YCj4YCk4YCl4YCm4YCw4YCv4YCu4YCt4YCs4YCr4YCn4YCp4YCq 4YCy4YCx4YC24YC34YC44YC64YGF4YGF4YCE4YCD4YCC4YCB4YCADQrhgLzhgIbhgIfhgIjhgInh gIrhgKvhgKzhgK3hgK7hgK/hgLDhgKrhgKnhgKfhgI/hgI7hgI3hgIzhgIvhgJDhgJHhgJLhgJPh gJThgLHhgLbhgLfhgLjhgLrhgY/hgYnhgIThgInhgIjhgIfhgIbhgIXhgIvhgIzhgI3hgI7hgI/h gJThgJPhgJLhgJHhgJDhgJXhgJbhgJfhgJjhgJkNCuGAvOGBgOGBgeGBguGBieGAj+GAjuGAjeGA jOGAi+GAkOGAkeGAkuGAk+GAlOGAmeGAmOGAl+GAluGAleGAtuGAtuGAtuGAt+GAuOGAuuGAsuGB hOGBheGAlOGAk+GAkuGAkeGAkOGAi+GAjOGAjeGAjuGAj+GAiuGAieGAhOGAg+GAiOGAguGAh+GA geGAhuGAgOGAheGAoeGAo+GApOGApeGApuGAsOGAr+GArg0K4YGA4YCZ4YCY4YCd4YCg4YCc4YCb 4YC84YCa4YGB4YGC4YGD4YGE4YGF4YGG4YGH4YGI4YGJ4YGP4YGO4YGN4YGM4YGL4YGK4YC24YC4 4YC64YCy4YCq4YCu4YC54YC54YCE4YCD4YCC4YCB4YCA4YCK4YCJ4YCP4YCI4YCO4YCH4YCN4YGA 4YGA4YGA4YGC4YGC4YGC4YGG4YGG4YGGDQrhgLHhgKfhgKnhgKrhgLLhgLrhgLjhgLfhgLbhgL/h gJ7hgJ/hgL7hgL3hgJ3hgKDhgJzhgJvhgLzhgLvhgJrhgJXhgJbhgJfhgJjhgJnhgJThgJPhgI7h gI/hgIjhgInhgIrhgIThgIPhgILhgIHhgIDhgIXhgIbhgIfhgIjhgInhgIrhgKvhgKzhgKHhgKMN CuGAo+GApOGApeGApuGAsOGAr+GAruGAreGArOGAp+GAqeGAquGAsuGAseGAtuGAt+GAuOGAuuGB j+GBjuGBjeGBjOGBi+GBiuGBgOGBg+GBheGBh+GBieGAj+GAieGAiuGAhOGAg+GAguGAgeGAgOGA heGAhuGAh+GAjeGAjOGAi+GAjuGAj+GAlOGAk+GAkuGAkeGAkOGAquGAquGAqQ0K4YGE4YGE4YGE 4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE 4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE 4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE 4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGE4YGEDQpD4YCf4oCL4YCp4YCe4YC5IEPhgKnh gJnhgLnhgJnhgK/hgJThgK3hgIXhgJDhgK3hgKnhgJThgLkgQ+GAqeGAhOGAueGAm+GAseGAnuGA ueGAnuGAuS4s4YCk4YCU4YC54YCF4YC54YGK4YCF4YC54YCF4YC54YCF4YC5LuGAkuGAseGBig0K DQoNCg0KMjAxNC0wMS0zMSAxMjo1MyBHTVQrMDk6MDAgSm9obi1NYXJrIEd1cm5leSA8am1nQGZ1 bmt0aGF0LmNvbT46DQoNCj4gUmljayBNYWNrbGVtIHdyb3RlIHRoaXMgbWVzc2FnZSBvbiBUaHUs IEphbiAzMCwgMjAxNCBhdCAyMjozMiAtMDUwMDoNCj4gPiBBZHJpYW4gQ2hhZGQgd3JvdGU6DQo+ ID4gPiBPbiAzMCBKYW51YXJ5IDIwMTQgMDc6MDYsIFJpY2sgTWFja2xlbSA8cm1hY2tsZW1AdW9n dWVscGguY2E+IHdyb3RlOg0KPiA+ID4gPiBIaSwganVzdCBhZGRpbmcgb25lIG1vcmUgaWRlYSBv biB3aGF0IHRvIGRvIGFib3V0IHRoaXMNCj4gPiA+ID4gdG8gdGhlIGxpc3Q6DQo+ID4gPiA+IC0g QWRkIGEgaWZfaHdfdHNvbWF4c2VnIGFuZCBtb2RpZnkgdGhlIGxvb3AgaW4gdGNwX291dHB1dCgp DQo+ID4gPiA+ICAgc28gdGhhdCBpdCB1c2VzIGJvdGggaWZfaHdfdHNvbWF4IGFuZCBpZl9od190 c29tYXhzZWcgdG8NCj4gPiA+ID4gICBkZWNpZGUgaG93IG11Y2ggdG8gaGFuZCB0byB0aGUgZGV2 aWNlIGRyaXZlciBpbiBlYWNoIG1idWYgbGlzdC4NCj4gPiA+ID4gICAoSSBoYXZlbid0IGxvb2tl ZCB0byBzZWUgaG93IGVhc3kgaXQgd291bGQgYmUgdG8gY2hhbmdlIHRoaXMNCj4gPiA+ID4gICBs b29wLikNCj4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5rIHRoYXQncyBhIGhhY2suIEkgdGhpbmsg YWRkaW5nIHRoYXQgYW5kIHNldHRpbmcNCj4gPiA+IHRzb21heHNlZw0KPiA+ID4gdG8gc2F5IDMw IGZvciBub3cgd291bGQgYmUgYSBnb29kIGNvbXByaW1pc2UuDQo+ID4gPg0KPiA+IFdlbGwsIG15 IFRDUCBpcyB2ZXJ5IHJ1c3R5IGFuZCBJIGhhdmUgbm8gd2F5IHRvIHRlc3QgaXQgKEkgZG9uJ3QN Cj4gPiBoYXZlIGFueXRoaW5nIHRoYXQgZG9lcyBUU08pLCBidXQgSSd2ZSBhdHRhY2hlZCBhIHN0 YWIgYXQgYSBwYXRjaA0KPiA+IHRvIGRvIHRoaXMuDQo+ID4NCj4gPiBNYXliZSBpdCBjYW4gYmUg dXNlZCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGlzLCBpZiBvdGhlcnMgdGhpbmsNCj4gPiBp dCBtYWtlcyBzZW5zZS4NCj4gPg0KPiA+IFRoZSAiI2lmZGVmIG5vdHlldCIgaW4gdGhlIHBhdGNo IHdvdWxkIGJlY29tZSBzb21ldGhpbmcgbGlrZToNCj4gPiAjIGlmIF9fRnJlZUJTRF92ZXJzaW9u ID49IE5OTk4NCj4gPiB3aGVuIGEgY2hhbmdlIHRvIGFkZCBpZl9od190c29tYXhzZWcgaXMgZG9u ZSwgd2FzIHdoYXQgSSB3YXMNCj4gPiB0aGlua2luZy4NCj4NCj4gRGVmaW5hdGVseSBuZWVkIHRv IG1ha2Ugc3VyZSB5b3UgZml4IHRoZSBkcml2ZXJzIHRoYXQgc3VwcG9ydCBsYXJnZQ0KPiBlbm91 Z2ggc2cgYXJyYXlzIGxpa2UgaXhnYiB3aGljaCBzdXBwb3J0cyAxMDAuLi4NCj4NCj4gSnVzdCBh IHNhbXBsaW5nIG9mIG9uZXMgdGhhdCB1c2UgYSBfU0NBVFRFUiBkZWZpbmU6DQo+IC4vZTEwMDAv aWZfaWdiLmg6I2RlZmluZSBJR0JfTUFYX1NDQVRURVIgICAgICAgICAgICAgICAgNjQNCj4gLi9l MTAwMC9pZl9sZW0uaDojZGVmaW5lIEVNX01BWF9TQ0FUVEVSICAgICAgICAgNjQNCj4gLi9lMTAw MC9pZl9lbS5oOiNkZWZpbmUgRU1fTUFYX1NDQVRURVIgICAgICAgICAgMzINCj4gLi9uZmUvaWZf bmZlcmVnLmg6I2RlZmluZSAgICAgICBORkVfTUFYX1NDQVRURVIgICAgICAgICAzMg0KPiAuL2l4 Z2JlL2l4Z2JlLmg6I2RlZmluZSBJWEdCRV84MjU5OF9TQ0FUVEVSICAgICAgICAgICAgIDEwMA0K PiAuL2l4Z2JlL2l4Z2JlLmg6I2RlZmluZSBJWEdCRV84MjU5OV9TQ0FUVEVSICAgICAgICAgICAg IDMyDQo+IC4vaXhnYi9pZl9peGdiLmg6I2RlZmluZSBJWEdCX01BWF9TQ0FUVEVSICAgICAgICAg ICAxMDANCj4NCj4gSSB3b25kZXIgaG93IG1hbnkgb2YgdGhlc2UgYXJlIGhhcmR3YXJlIGxpbWl0 cywgb3IganVzdCBJIGRvbid0DQo+IHdhbnQgdG8gYWxsb2NhdGUgdG9vIG11Y2ggc3BhY2Ugb24g dGhlIHN0YWNrLCBhcyAxNiBieXRlcyBwZXINCj4gYnVzX2RtYV9zZWdtZW50X3QgKG9uIGFtZDY0 KSBhZGRzIHVwLi4uDQo+DQo+IFRoZSBvdGhlciBxdWVzdGlvbiBpcyBzaG91bGQgdGhlIGRyaXZl cnMgdy8gYSBsaW1pdCBvbiB0aGUgc2VnbWVudHMNCj4gcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBU U08gcGFja2V0IHNvIHRoYXQgd2UgZG9uJ3QgbmVlZCB0bw0KPiBtX2RlZnJhZy9tX2NvbGxhcHNl IHdoaWNoIGFyZSBleHBlbnNpdmUgb3BlcmF0aW9ucy4uLg0KPg0KPiAtLQ0KPiAgIEpvaG4tTWFy ayBHdXJuZXkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWb2ljZTogKzEgNDE1IDIyNSA1 NTc5DQo+DQo+ICAgICAgIkFsbCB0aGF0IEkgd2lsbCBkbywgaGFzIGJlZW4gZG9uZSwgQWxsIHRo YXQgSSBoYXZlLCBoYXMgbm90LiINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbmV0DQo+ IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmli ZUBmcmVlYnNkLm9yZyINCj4NCg== From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 15:14:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8938137 for ; Thu, 13 Feb 2014 15:14:40 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B41E1DA2 for ; Thu, 13 Feb 2014 15:14:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s1DFEQMN074456; Thu, 13 Feb 2014 07:14:26 -0800 (PST) (envelope-from dg@pki2.com) Subject: Re: Recommendations for packet capture From: Dennis Glatting To: "C. L. Martinez" In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 13 Feb 2014 07:14:26 -0800 Message-ID: <1392304466.63673.23.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1DFEQMN074456 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: dg@pki2.com Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:14:40 -0000 On Thu, 2014-02-13 at 09:14 +0000, C. L. Martinez wrote: > Hi all, > > I need to setup some FreeBSD (or Linux, it depends) hosts to use as a > packet capture sensors for our infrastrucutre. > > Searching about software that I could use under FreeBSD, I only find > these ones: > > a) daemonlogger > b) streamdb > > For Linux, it seems exits more alternatives. Any suggestions?? > > I need to monitor 1 GiB networks. > I've not (yet) used these: /usr/ports/security/sguil-client /usr/ports/security/sguil-sensor /usr/ports/security/sguil-server > Thanks. > _______________________________________________ > 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" -- Dennis Glatting From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 15:38:42 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39B349B1; Thu, 13 Feb 2014 15:38:42 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F5A91127; Thu, 13 Feb 2014 15:38:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s1DFcZpP033359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Feb 2014 19:38:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s1DFcZpj033358; Thu, 13 Feb 2014 19:38:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Feb 2014 19:38:35 +0400 From: Gleb Smirnoff To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Subject: Re: Loosing TCP/IPv4 connections with jails+pf on 10.0-RELEASE Message-ID: <20140213153835.GU26785@FreeBSD.org> References: <52EF67EF.1000803@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52EF67EF.1000803@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@FreeBSD.org, Christopher Faulet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:38:42 -0000 --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Feb 03, 2014 at 10:57:03AM +0100, Jean-Sébastien Pédron wrote: J> With 8.3-RELEASE on another server, this setup was working without J> problem. Now that we switched to a new server and 10.0-RELEASE (we J> skipped 9.x), we see that TCP connections to jails over IPv4 are having J> troubles: J> J> o After around 10 days of uptime, connections from an IRC client J> on the host (not a jail) connected to an IRC server on a jail J> are getting dropped during the night (maybe because of no J> activity on the IRC channel). It seems that packets from the J> host (or a remote computer) to the jail are fine. However, J> packets from the jail never reach the peer. This was tested with J> nc(1) on both sides, so the uptime of the IRC client or server J> isn't related. J> J> o As the time passes, connections are dropped faster and faster: J> even during the day, when there's activity on the IRC channel. J> J> o At some point, connections only live for a few seconds and this J> affects short-lived connections to the SMTP/IMAP and web jails. J> J> A reboot solves the problem, until it comes back a week or more later. J> Troubles start to appear again since this week-end. Can you please try attached patch? My guess is that we got states_cur underflow/overflow due to parallel access in the pf_state_expires() in the line marked with XXXGL. J> IPv6 connections are NOT affected: they work perfectly. That's really strange. Are they running stateless via pf? -- Totus tuus, Glebius. --u65IjBhB3TIa72Vp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pf_counters.diff" Index: sbin/pfctl/pfctl.c =================================================================== --- sbin/pfctl/pfctl.c (revision 261825) +++ sbin/pfctl/pfctl.c (working copy) @@ -791,17 +791,17 @@ pfctl_print_rule_counters(struct pf_rule *rule, in } if (opts & PF_OPT_VERBOSE) { printf(" [ Evaluations: %-8llu Packets: %-8llu " - "Bytes: %-10llu States: %-6u]\n", + "Bytes: %-10llu States: %-6lu]\n", (unsigned long long)rule->evaluations, (unsigned long long)(rule->packets[0] + rule->packets[1]), (unsigned long long)(rule->bytes[0] + - rule->bytes[1]), rule->states_cur); + rule->bytes[1]), (uint64_t)rule->states_cur); if (!(opts & PF_OPT_DEBUG)) printf(" [ Inserted: uid %u pid %u " - "State Creations: %-6u]\n", + "State Creations: %-6lu]\n", (unsigned)rule->cuid, (unsigned)rule->cpid, - rule->states_tot); + (uint64_t)rule->states_tot); } } Index: sys/net/pfvar.h =================================================================== --- sys/net/pfvar.h (revision 261825) +++ sys/net/pfvar.h (working copy) @@ -35,6 +35,7 @@ #include #include +#include #include #include @@ -512,13 +513,9 @@ struct pf_rule { int rtableid; u_int32_t timeout[PFTM_MAX]; - u_int32_t states_cur; - u_int32_t states_tot; u_int32_t max_states; - u_int32_t src_nodes; u_int32_t max_src_nodes; u_int32_t max_src_states; - u_int32_t spare1; /* netgraph */ u_int32_t max_src_conn; struct { u_int32_t limit; @@ -532,6 +529,10 @@ struct pf_rule { uid_t cuid; pid_t cpid; + counter_u64_t states_cur; + counter_u64_t states_tot; + counter_u64_t src_nodes; + u_int16_t return_icmp; u_int16_t return_icmp6; u_int16_t max_mss; Index: sys/netpfil/pf/if_pfsync.c =================================================================== --- sys/netpfil/pf/if_pfsync.c (revision 261825) +++ sys/netpfil/pf/if_pfsync.c (working copy) @@ -438,7 +438,8 @@ pfsync_state_import(struct pfsync_state *sp, u_int else r = &V_pf_default_rule; - if ((r->max_states && r->states_cur >= r->max_states)) + if ((r->max_states && + counter_u64_fetch(r->states_cur) >= r->max_states)) goto cleanup; /* @@ -516,19 +517,16 @@ pfsync_state_import(struct pfsync_state *sp, u_int st->pfsync_time = time_uptime; st->sync_state = PFSYNC_S_NONE; - /* XXX when we have nat_rule/anchors, use STATE_INC_COUNTERS */ - r->states_cur++; - r->states_tot++; - if (!(flags & PFSYNC_SI_IOCTL)) st->state_flags |= PFSTATE_NOSYNC; - if ((error = pf_state_insert(kif, skw, sks, st)) != 0) { - /* XXX when we have nat_rule/anchors, use STATE_DEC_COUNTERS */ - r->states_cur--; + if ((error = pf_state_insert(kif, skw, sks, st)) != 0) goto cleanup_state; - } + /* XXX when we have nat_rule/anchors, use STATE_INC_COUNTERS */ + counter_u64_add(r->states_cur, 1); + counter_u64_add(r->states_tot, 1); + if (!(flags & PFSYNC_SI_IOCTL)) { st->state_flags &= ~PFSTATE_NOSYNC; if (st->state_flags & PFSTATE_ACK) { Index: sys/netpfil/pf/pf.c =================================================================== --- sys/netpfil/pf/pf.c (revision 261825) +++ sys/netpfil/pf/pf.c (working copy) @@ -335,27 +335,27 @@ enum { PF_ICMP_MULTI_NONE, PF_ICMP_MULTI_SOLICITED #define BOUND_IFACE(r, k) \ ((r)->rule_flag & PFRULE_IFBOUND) ? (k) : V_pfi_all -#define STATE_INC_COUNTERS(s) \ - do { \ - s->rule.ptr->states_cur++; \ - s->rule.ptr->states_tot++; \ - if (s->anchor.ptr != NULL) { \ - s->anchor.ptr->states_cur++; \ - s->anchor.ptr->states_tot++; \ - } \ - if (s->nat_rule.ptr != NULL) { \ - s->nat_rule.ptr->states_cur++; \ - s->nat_rule.ptr->states_tot++; \ - } \ +#define STATE_INC_COUNTERS(s) \ + do { \ + counter_u64_add(s->rule.ptr->states_cur, 1); \ + counter_u64_add(s->rule.ptr->states_tot, 1); \ + if (s->anchor.ptr != NULL) { \ + counter_u64_add(s->anchor.ptr->states_cur, 1); \ + counter_u64_add(s->anchor.ptr->states_tot, 1); \ + } \ + if (s->nat_rule.ptr != NULL) { \ + counter_u64_add(s->nat_rule.ptr->states_cur, 1);\ + counter_u64_add(s->nat_rule.ptr->states_tot, 1);\ + } \ } while (0) -#define STATE_DEC_COUNTERS(s) \ - do { \ - if (s->nat_rule.ptr != NULL) \ - s->nat_rule.ptr->states_cur--; \ - if (s->anchor.ptr != NULL) \ - s->anchor.ptr->states_cur--; \ - s->rule.ptr->states_cur--; \ +#define STATE_DEC_COUNTERS(s) \ + do { \ + if (s->nat_rule.ptr != NULL) \ + counter_u64_add(s->nat_rule.ptr->states_cur, -1);\ + if (s->anchor.ptr != NULL) \ + counter_u64_add(s->anchor.ptr->states_cur, -1); \ + counter_u64_add(s->rule.ptr->states_cur, -1); \ } while (0) static MALLOC_DEFINE(M_PFHASH, "pf_hash", "pf(4) hash header structures"); @@ -647,7 +647,7 @@ pf_insert_src_node(struct pf_src_node **sn, struct PF_HASHROW_ASSERT(sh); if (!rule->max_src_nodes || - rule->src_nodes < rule->max_src_nodes) + counter_u64_fetch(rule->src_nodes) < rule->max_src_nodes) (*sn) = uma_zalloc(V_pf_sources_z, M_NOWAIT | M_ZERO); else V_pf_status.lcounters[LCNT_SRCNODES]++; @@ -667,7 +667,7 @@ pf_insert_src_node(struct pf_src_node **sn, struct (*sn)->creation = time_uptime; (*sn)->ruletype = rule->action; if ((*sn)->rule.ptr != NULL) - (*sn)->rule.ptr->src_nodes++; + counter_u64_add((*sn)->rule.ptr->src_nodes, 1); PF_HASHROW_UNLOCK(sh); V_pf_status.scounters[SCNT_SRC_NODE_INSERT]++; V_pf_status.src_nodes++; @@ -692,7 +692,7 @@ pf_unlink_src_node_locked(struct pf_src_node *src) #endif LIST_REMOVE(src, entry); if (src->rule.ptr) - src->rule.ptr->src_nodes--; + counter_u64_add(src->rule.ptr->src_nodes, -1); V_pf_status.scounters[SCNT_SRC_NODE_REMOVALS]++; V_pf_status.src_nodes--; } @@ -1478,7 +1478,7 @@ pf_state_expires(const struct pf_state *state) start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; if (start) { end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; - states = state->rule.ptr->states_cur; /* XXXGL */ + states = counter_u64_fetch(state->rule.ptr->states_cur); } else { start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; @@ -1587,11 +1587,7 @@ pf_unlink_state(struct pf_state *s, u_int flags) if (pfsync_delete_state_ptr != NULL) pfsync_delete_state_ptr(s); - --s->rule.ptr->states_cur; - if (s->nat_rule.ptr != NULL) - --s->nat_rule.ptr->states_cur; - if (s->anchor.ptr != NULL) - --s->anchor.ptr->states_cur; + STATE_DEC_COUNTERS(s); s->timeout = PFTM_UNLINKED; @@ -3606,7 +3602,8 @@ pf_create_state(struct pf_rule *r, struct pf_rule u_short reason; /* check maximums */ - if (r->max_states && (r->states_cur >= r->max_states)) { + if (r->max_states && + (counter_u64_fetch(r->states_cur) >= r->max_states)) { V_pf_status.lcounters[LCNT_STATES]++; REASON_SET(&reason, PFRES_MAXSTATES); return (PF_DROP); Index: sys/netpfil/pf/pf_ioctl.c =================================================================== --- sys/netpfil/pf/pf_ioctl.c (revision 261825) +++ sys/netpfil/pf/pf_ioctl.c (working copy) @@ -229,6 +229,10 @@ pfattach(void) V_pf_default_rule.nr = -1; V_pf_default_rule.rtableid = -1; + V_pf_default_rule.states_cur = counter_u64_alloc(M_WAITOK); + V_pf_default_rule.states_tot = counter_u64_alloc(M_WAITOK); + V_pf_default_rule.src_nodes = counter_u64_alloc(M_WAITOK); + /* initialize default timeouts */ my_timeout[PFTM_TCP_FIRST_PACKET] = PFTM_TCP_FIRST_PACKET_VAL; my_timeout[PFTM_TCP_OPENING] = PFTM_TCP_OPENING_VAL; @@ -398,6 +402,9 @@ pf_free_rule(struct pf_rule *rule) pfi_kif_unref(rule->kif); pf_anchor_remove(rule); pf_empty_pool(&rule->rpool.list); + counter_u64_free(rule->states_cur); + counter_u64_free(rule->states_tot); + counter_u64_free(rule->src_nodes); free(rule, M_PFRULE); } @@ -1149,6 +1156,9 @@ pfioctl(struct cdev *dev, u_long cmd, caddr_t addr bcopy(&pr->rule, rule, sizeof(struct pf_rule)); if (rule->ifname[0]) kif = malloc(sizeof(*kif), PFI_MTYPE, M_WAITOK); + rule->states_cur = counter_u64_alloc(M_WAITOK); + rule->states_tot = counter_u64_alloc(M_WAITOK); + rule->src_nodes = counter_u64_alloc(M_WAITOK); rule->cuid = td->td_ucred->cr_ruid; rule->cpid = td->td_proc ? td->td_proc->p_pid : 0; TAILQ_INIT(&rule->rpool.list); @@ -1265,6 +1275,9 @@ pfioctl(struct cdev *dev, u_long cmd, caddr_t addr #undef ERROUT DIOCADDRULE_error: PF_RULES_WUNLOCK(); + counter_u64_free(rule->states_cur); + counter_u64_free(rule->states_tot); + counter_u64_free(rule->src_nodes); free(rule, M_PFRULE); if (kif) free(kif, PFI_MTYPE); @@ -1336,6 +1349,16 @@ DIOCADDRULE_error: break; } bcopy(rule, &pr->rule, sizeof(struct pf_rule)); + /* + * XXXGL: this is what happens when internal kernel + * structures are used as ioctl API structures. + */ + pr->rule.states_cur = + (counter_u64_t )counter_u64_fetch(rule->states_cur); + pr->rule.states_tot = + (counter_u64_t )counter_u64_fetch(rule->states_tot); + pr->rule.src_nodes = + (counter_u64_t )counter_u64_fetch(rule->src_nodes); if (pf_anchor_copyout(ruleset, rule, pr)) { PF_RULES_WUNLOCK(); error = EBUSY; @@ -1354,7 +1377,7 @@ DIOCADDRULE_error: rule->evaluations = 0; rule->packets[0] = rule->packets[1] = 0; rule->bytes[0] = rule->bytes[1] = 0; - rule->states_tot = 0; + counter_u64_zero(rule->states_tot); } PF_RULES_WUNLOCK(); break; @@ -1394,15 +1417,14 @@ DIOCADDRULE_error: #endif /* INET6 */ newrule = malloc(sizeof(*newrule), M_PFRULE, M_WAITOK); bcopy(&pcr->rule, newrule, sizeof(struct pf_rule)); + if (newrule->ifname[0]) + kif = malloc(sizeof(*kif), PFI_MTYPE, M_WAITOK); + newrule->states_cur = counter_u64_alloc(M_WAITOK); + newrule->states_tot = counter_u64_alloc(M_WAITOK); + newrule->src_nodes = counter_u64_alloc(M_WAITOK); newrule->cuid = td->td_ucred->cr_ruid; newrule->cpid = td->td_proc ? td->td_proc->p_pid : 0; TAILQ_INIT(&newrule->rpool.list); - /* Initialize refcounting. */ - newrule->states_cur = 0; - newrule->entries.tqe_prev = NULL; - - if (newrule->ifname[0]) - kif = malloc(sizeof(*kif), PFI_MTYPE, M_WAITOK); } #define ERROUT(x) { error = (x); goto DIOCCHANGERULE_error; } @@ -1570,8 +1592,12 @@ DIOCADDRULE_error: #undef ERROUT DIOCCHANGERULE_error: PF_RULES_WUNLOCK(); - if (newrule != NULL) + if (newrule != NULL) { + counter_u64_free(newrule->states_cur); + counter_u64_free(newrule->states_tot); + counter_u64_free(newrule->src_nodes); free(newrule, M_PFRULE); + } if (kif != NULL) free(kif, PFI_MTYPE); break; @@ -3427,6 +3453,11 @@ shutdown_pf(void) char nn = '\0'; V_pf_status.running = 0; + + counter_u64_free(V_pf_default_rule.states_cur); + counter_u64_free(V_pf_default_rule.states_tot); + counter_u64_free(V_pf_default_rule.src_nodes); + do { if ((error = pf_begin_rules(&t[0], PF_RULESET_SCRUB, &nn)) != 0) { --u65IjBhB3TIa72Vp-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 16:09:59 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D72C410; Thu, 13 Feb 2014 16:09:59 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF45114DF; Thu, 13 Feb 2014 16:09:58 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WDyrL-000ES5-BD; Thu, 13 Feb 2014 17:09:57 +0100 Message-ID: <52FCEE4E.8090500@FreeBSD.org> Date: Thu, 13 Feb 2014 17:09:50 +0100 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Loosing TCP/IPv4 connections with jails+pf on 10.0-RELEASE References: <52EF67EF.1000803@FreeBSD.org> <20140213153835.GU26785@FreeBSD.org> In-Reply-To: <20140213153835.GU26785@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DnERgcwlq9Bukgbc2LaVrgn6McFs5QQLq" Cc: freebsd-net@FreeBSD.org, Christopher Faulet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:09:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DnERgcwlq9Bukgbc2LaVrgn6McFs5QQLq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 13.02.2014 16:38, Gleb Smirnoff wrote: > Can you please try attached patch? Yes, thank you, I'll rebuild it right now. FWIW, the problem appeared again a few days ago. We stopped pf and unloaded/reloaded the pf module to see if this fixed the problem. That was yesterday and today we have no connection loss. We'll see how it goes for the next few days. > J> IPv6 connections are NOT affected: they work perfectly. >=20 > That's really strange. Are they running stateless via pf? Our jails have their own IPv6 so those connections don't go through pf. We just need pf for IPv4 because we have only one public address. --=20 Jean-S=E9bastien P=E9dron --DnERgcwlq9Bukgbc2LaVrgn6McFs5QQLq 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.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/O5SAAoJEDnpl2Gl/ZTMqeoQANuX4LlCBh1qWAvRoNfO00vZ t6jQ0pWEPrj5jjaiqWCEnUsCNCs16o0AQEcLrhiHuDH7+n8hxlixjcTCmPubaZsN /Wse4wv/1m3vB6xO5Exlu8H/dgS2GEdsOQrvaLRxCfD8mh8XQ9teGnaG3n/0W4tV 65m/l/Uh/2lqr0kzWVspcsyiGhj/08hRP2MOa3rqOagtVDDxuXxXRZ5w+gnS+Zmk 0ktu8nuZP9zA6EdrgdfbbyrrE1RHRSELpD6gqcRzpgNk2ibfaaamodnnMXdMSIiD tD6LNPi/kMJL21kBdPut5v9BUhIo/x9xNscIIF6CcRJ4vmp567/Qwd/7uyR/+7aA c/TBScpaEP83x9eveKyp2muziV9VN4q4yxrztdxRE48pUktu+p1n5tb06YW+dVTA pkeVEhEprV+F60jG75Tflqug360ebzMpZy5GtawKk4UHY3V3lmeKA9scorcNeeJl Js9Ien7pnNf6pn3oI/x2o2kCtd3eo2mOoYB9HGCuyi4kttUaizh6qaQUyBE8akiR ZAR+nkhFR98TwGNr5m0GvFrSHjGkGQpB1yy4m7UU2ExLl0IswBRocBBa8Y9zTjPb 3a7BdtYpJUbDG5xlqOd7NCmSJlBswh25fJd9pvsaTWzn3xdA0WKaFmHH8FUGfVyS U4A3NBF1B2tNGhqK+VwJ =K6hp -----END PGP SIGNATURE----- --DnERgcwlq9Bukgbc2LaVrgn6McFs5QQLq-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 17:44:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 157DC5E1 for ; Thu, 13 Feb 2014 17:44:51 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF45D1D32 for ; Thu, 13 Feb 2014 17:44:50 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1DHiifZ047302; Thu, 13 Feb 2014 12:44:44 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1DHihEk047299; Thu, 13 Feb 2014 12:44:43 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21245.1163.754141.154430@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 12:44:43 -0500 From: Garrett Wollman To: John-Mark Gurney Subject: Re: Use of contiguous physical memory in cxgbe driver In-Reply-To: <20140213075651.GY34851@funkthat.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Feb 2014 12:44:44 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:44:51 -0000 < said: > Though we might want to keep a few mbufs reserved for receive now that > you mention it... We should never get to the point where we can't > allocate even one frame for receive... It's very easy to get to that state if the driver insists on getting three physically contiguous pages (which is what it takes to allocate a single 9k cluster) -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 18:07:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87D15D82 for ; Thu, 13 Feb 2014 18:07:03 +0000 (UTC) Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 347511078 for ; Thu, 13 Feb 2014 18:07:02 +0000 (UTC) Received: from [98.138.100.116] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:05:21 -0000 Received: from [98.138.84.47] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:05:21 -0000 Received: from [127.0.0.1] by smtp115.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:05:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392314721; bh=lUMyH2oRapzQQg3Lud9os5vVWrztGENz1fBfWWP/wE8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=55ViOZVYN+GH2rEVI3lK13QXp6kt5KEABIGk0sTHBo5HA0xvhSgqd7asZIASW56dVgMuBgTZTrHeOV72oEXSMd8ojjG/oMfA3xcJlgctewrUvnc1uBuEix4pqzdC8EY/Y15EGZcaSRnUBehhf8L+4Ttt1U26++s9CKuIXZXt+j4= X-Yahoo-Newman-Id: 102697.20749.bm@smtp115.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pKf4SzkVM1m5cmNOjnT3bOKZHqGqji3nbm31jnEaxI6l59x Ncvb5WGzfdnSdp1DDGFyNLrBMqLvbjgD.LbwrWh2BHa.2WBMKsGcG263YJuz DbLQRWQ0riU5O.QNMmQIBmxE583t61gsv9.Mt2t1vB54xGP0_j0b7cD235_K GTaDKRk3xN8rM9hxBUjFKw2cyVoouFWEE1kace6r.MO5UVCC0uFHtiWNSAt3 QiPdHKSM4EviZrUsW7dZzy90LwLXp729nrJSOawuOJVH.D3worzVmAbG4.mw Nw15Gj3rdsZpjsNR_oeEwpRFD5oMhBO95sLd515A6yVeLpl3DAdvPv2pOc.E bsSNZPmwrfaHwNzhBIsse31aQu3swcy.H72Ao.F9STQVWxfPvS83tFhJW_Bl YKYuTq17lzWNtgZpu7HuTTs1PQBT0vWh2ia.T8KOgdKh.i4bdkLLNM5rAwMm 1_Bvphv_jkfvE_bj2W_bjhyf9DygOAvjdyEIAidgkdcLDAmYs2FXIyIyQptE LiojvoUNTH4PABvumaV2hT28Uf3GUdj4f0MpPoOw5POGvYxQ_KLz7If1kX1s Gqak_RPNHg1Ce0g-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.0.102.27] (scott4long@50.242.69.61 with plain [63.250.193.228]) by smtp115.mail.ne1.yahoo.com with SMTP; 13 Feb 2014 10:05:21 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Use of contiguous physical memory in cxgbe driver From: Scott Long In-Reply-To: <21245.1163.754141.154430@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 10:05:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Net , John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:07:03 -0000 On Feb 13, 2014, at 9:44 AM, Garrett Wollman = wrote: > < said: >=20 >> Though we might want to keep a few mbufs reserved for receive now = that >> you mention it... We should never get to the point where we can't >> allocate even one frame for receive... >=20 > It's very easy to get to that state if the driver insists on getting > three physically contiguous pages (which is what it takes to allocate > a single 9k cluster) >=20 So what you=92re saying is that all of the other memory allocations that = go along with moving data through a socket wind up fragmenting the free memory pool to = the point where it becomes impossible to find 3 contig pages for a 9k jumbo RX = frame. The old Tigon drivers used to solve this by having a private slab = allocator for RX. There was deliberate work more than 5 years ago to eliminate private = allocators like this and have a common jumbo allocator. I think it=92s possible to = say that that has been a theoretical success and a practical failure. Scott From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 18:07:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF838E24 for ; Thu, 13 Feb 2014 18:07:44 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B854B1085 for ; Thu, 13 Feb 2014 18:07:44 +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 s1DI7aiE093381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Feb 2014 10:07:37 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1DI7a4c093380; Thu, 13 Feb 2014 10:07:36 -0800 (PST) (envelope-from jmg) Date: Thu, 13 Feb 2014 10:07:36 -0800 From: John-Mark Gurney To: Garrett Wollman Subject: Re: Use of contiguous physical memory in cxgbe driver Message-ID: <20140213180736.GA34851@funkthat.com> Mail-Followup-To: Garrett Wollman , FreeBSD Net References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21245.1163.754141.154430@hergotha.csail.mit.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 13 Feb 2014 10:07:37 -0800 (PST) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:07:44 -0000 Garrett Wollman wrote this message on Thu, Feb 13, 2014 at 12:44 -0500: > < said: > > > Though we might want to keep a few mbufs reserved for receive now that > > you mention it... We should never get to the point where we can't > > allocate even one frame for receive... > > It's very easy to get to that state if the driver insists on getting > three physically contiguous pages (which is what it takes to allocate > a single 9k cluster) Well, if you're using a cheap NIC that can't do scatter/gather DMA, then you get what you pay for... -- 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 Feb 13 18:14:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7CF4284 for ; Thu, 13 Feb 2014 18:14:23 +0000 (UTC) Received: from nm7-vm3.bullet.mail.ne1.yahoo.com (nm7-vm3.bullet.mail.ne1.yahoo.com [98.138.91.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 377CC1153 for ; Thu, 13 Feb 2014 18:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=gcom1024; t=1392315133; bh=UewvLuXqp8skdCxPd2hFEFft7vVdXRQnqXsDBzOjRkg=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=N9GE5n4MWoS3PZU1heD8jy0ZpZUlX5kuXoN93kkWT7r7VHYY4lAwn1soi7Sz7NyruV7Oumc+QP/W4Hx092DxfwBs9BzAZhNTEjUuUxE1Dt9v+6TZdUmMdIVNNnvTl5fLLNVzOy25ul7BIo+jqiBhaMpbwD6k6hIWq8eJEDwpyyY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=gcom1024; d=yahoo.com; b=ZHthms14U6d910HcMB7CmG4BUKHTRTFncCuBh0vON3OnyJEUOh9q1h/Oks4i+7Bt8ex3nz1K7MIhTkw9+guLzeGmySpm3h7cdi8/GzXCDfOI8SbFVJ4Tk4j7Qf9YovDFshBCtnMUHMWwVB1wMFnof57cchBXxcqzivvZmKvk0GY=; Received: from [98.138.100.118] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:12:13 -0000 Received: from [98.138.226.61] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:12:13 -0000 Received: from [127.0.0.1] by smtp212.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 18:12:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392315133; bh=UewvLuXqp8skdCxPd2hFEFft7vVdXRQnqXsDBzOjRkg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=4HKvyOF3R9qAucX3wpVd+2B61K0tqBsd1sW7BGizu8zbgZVWLc4xvb6iB/A5htmfleiOE/t4grpKqKf/KaFWcS0s3Xy223gLG72wNj64PfHhzSf0ay5Gpi4kq6I8dhLykQg24RWEHOmbuFKXxPepSXfD95rGU8IiUSgZZggLsD8= X-Yahoo-Newman-Id: 667586.72508.bm@smtp212.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7fcJh7AVM1mZa8BxtnezNZjoEmZHkujrLW0qVtpkNeUOmnP FT7EIULNfRyqKA.AMgSN2njoviT1vjOR1pPUiFLWMuP1gqNKLO0cJy1R4aMl a6bQaygvVXiotcLPBv8PEfPN8vUZCQBcQut9cXfX_Nl52PAOvEnqIBANCcYJ lPJNZcoUBpik7wWxqIuqGtROQQqs6YFPcpzv5LKf4waVRqpbWKS.TVPH0WM8 p4tPWQ6wgXTz1nzpJLSaX4C7dC8LQrEFq4FKpVhBHzcXuM5A28LTiylLzM8q _3l.A37RnoqZikckOq5aGQuYU4C5fLii.rDLfEpBV.NGpbtClok.LEh7QtwC mjFKsRkQRJCbeM6gVWR6us4fNGInzRZg9n_2QyeLywKuygkTG2xSK3SyvLwy __S8How6p0gjDzY4q.ONQZsGWCunTziA4z2Mzpv00syQzr2zPF0yk9_OIOMd rARDbq6_82E.cqENsc7Ja9hrU2XQx_xV6vjF7RT1f_Ctv.Rd.vMVe7bkwlXf 4sIj2M6nHdpAo4W4JkY3pRe6NOkaSc7akpd6UTRg9EW5fcJ9TPlKN1Mq310_ io._3u3MF X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [10.0.102.27] (scott4long@50.242.69.61 with plain [63.250.193.228]) by smtp212.mail.ne1.yahoo.com with SMTP; 13 Feb 2014 10:12:13 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Use of contiguous physical memory in cxgbe driver From: Scott Long In-Reply-To: <20140213180736.GA34851@funkthat.com> Date: Thu, 13 Feb 2014 10:12:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> <20140213180736.GA34851@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Net , Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:14:23 -0000 On Feb 13, 2014, at 10:07 AM, John-Mark Gurney wrote: > Garrett Wollman wrote this message on Thu, Feb 13, 2014 at 12:44 = -0500: >> < said: >>=20 >>> Though we might want to keep a few mbufs reserved for receive now = that >>> you mention it... We should never get to the point where we can't >>> allocate even one frame for receive... >>=20 >> It's very easy to get to that state if the driver insists on getting >> three physically contiguous pages (which is what it takes to allocate >> a single 9k cluster) >=20 > Well, if you're using a cheap NIC that can't do scatter/gather DMA, > then you get what you pay for=85 >=20 Like I alluded to in another email, it=92s not a hard problem to address = for these =93cheap=94 cards, it=92s a deliberate design decision from FreeBSD. Scott From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 18:15:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B4AA346 for ; Thu, 13 Feb 2014 18:15:11 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5B661169 for ; Thu, 13 Feb 2014 18:15:10 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1DIF1nA047692; Thu, 13 Feb 2014 13:15:02 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1DIF1eO047689; Thu, 13 Feb 2014 13:15:01 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21245.2981.568824.19800@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 13:15:01 -0500 From: Garrett Wollman To: John-Mark Gurney Subject: Re: Use of contiguous physical memory in cxgbe driver In-Reply-To: <20140213180736.GA34851@funkthat.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> <20140213180736.GA34851@funkthat.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Feb 2014 13:15:02 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:15:11 -0000 < said: >> [I wrote:] >> It's very easy to get to that state if the driver insists on getting >> three physically contiguous pages (which is what it takes to allocate >> a single 9k cluster) > Well, if you're using a cheap NIC that can't do scatter/gather DMA, > then you get what you pay for... No, I'm using expensive 10G NICs, like the Chelsio ones mentioned in the subject header. They have no trouble doing s/g (subject to some reasonable limits on chain length). The problem is when the drivers insist on physical contiguity anyway. I finally gave up and hacked the cxgbe driver never to use anything longer than a physical page. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 18:36:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92A97AB7 for ; Thu, 13 Feb 2014 18:36:25 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 482CB133E for ; Thu, 13 Feb 2014 18:36:25 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n7so18409884qcx.2 for ; Thu, 13 Feb 2014 10:36:24 -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=2n3lZv2ob4axOl1Z0ZQ52rl37trNUOip+2MuO5nKQ50=; b=koq5lRoLwp3BruudrDMWbiCrDahj8FmINjiLLSwDYH/euuroRy8ZNB2E/h9Deqh6Kf tYgrCyOo69o+Ug3e0X+6mNdlzlEj+IBDnsf18z4hb29dqPJGgeDPh433CQcI5r+hiMgF 6DFvyNa5kYGDVDI3nNwQHjULuE1xIeMiJqnr5r73mwkBQ1mdN63Gz98IbOac9lO7oqtm Rf5p5H6WGQaS1mZLGQ75BNtbSg5ycXqTOiZ3TH42RAm2NHXQJNsLjL8PnvSX/vuUILyU JFm6P9mktKcJD/1myK5hZVVBfc9jfbn3yhh/l3N4qYVlidm7JAAIaZrJz06ussnPeNE9 iPOQ== MIME-Version: 1.0 X-Received: by 10.140.98.135 with SMTP id o7mr4859294qge.102.1392316584449; Thu, 13 Feb 2014 10:36:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Thu, 13 Feb 2014 10:36:24 -0800 (PST) In-Reply-To: <21245.2981.568824.19800@hergotha.csail.mit.edu> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> <20140213180736.GA34851@funkthat.com> <21245.2981.568824.19800@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 10:36:24 -0800 X-Google-Sender-Auth: xduvhYHEYMnWejHvtM5PRNzuOQk Message-ID: Subject: Re: Use of contiguous physical memory in cxgbe driver From: Adrian Chadd To: Garrett Wollman Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , John-Mark Gurney X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:36:25 -0000 On 13 February 2014 10:15, Garrett Wollman wrote: > < said: > >>> [I wrote:] >>> It's very easy to get to that state if the driver insists on getting >>> three physically contiguous pages (which is what it takes to allocate >>> a single 9k cluster) > >> Well, if you're using a cheap NIC that can't do scatter/gather DMA, >> then you get what you pay for... > > No, I'm using expensive 10G NICs, like the Chelsio ones mentioned in > the subject header. They have no trouble doing s/g (subject to some > reasonable limits on chain length). The problem is when the drivers > insist on physical contiguity anyway. > > I finally gave up and hacked the cxgbe driver never to use anything > longer than a physical page. Have you tried it at 40G? ISTR np@ commenting on there being benefits to larger (up to 64K) allocations for the 40G T5 NICs that do packet -> buffer packing on receive side. -a From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 18:38: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C269BB2 for ; Thu, 13 Feb 2014 18:38:24 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CC74135D for ; Thu, 13 Feb 2014 18:38:24 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1DIcMRs047897; Thu, 13 Feb 2014 13:38:22 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1DIcM8i047896; Thu, 13 Feb 2014 13:38:22 -0500 (EST) (envelope-from wollman) Date: Thu, 13 Feb 2014 13:38:22 -0500 (EST) Message-Id: <201402131838.s1DIcM8i047896@hergotha.csail.mit.edu> From: wollman@bimajority.org To: scott4long@yahoo.com Subject: Re: Use of contiguous physical memory in cxgbe driver X-Newsgroups: mit.lcs.mail.freebsd-net In-Reply-To: <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Feb 2014 13:38:22 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:38:24 -0000 In article <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com>, Scott Long writes: >So what you’re saying is that all of the other memory allocations that >go along with >moving data through a socket wind up fragmenting the free memory pool to >the point >where it becomes impossible to find 3 contig pages for a 9k jumbo RX frame. Yes. I don't think it's even all that difficult, because drivers that are of this type only ever allocate 9k clusters, and for outbound packets the kernel never allocates anyting bigger than a page. Since the NIC driver allocates a new mbuf immediately to replenish its rx ring, before the upper layers have had a chance to process the packet, it's not hard to see how even a moderately busy system will soon checkerboard all of physical memory. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 19:34:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4802869A for ; Thu, 13 Feb 2014 19:34:04 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D51FC1983 for ; Thu, 13 Feb 2014 19:34:03 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1DJY1xL048517; Thu, 13 Feb 2014 14:34:01 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1DJY1X7048514; Thu, 13 Feb 2014 14:34:01 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21245.7721.789554.761901@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 14:34:01 -0500 From: Garrett Wollman To: Scott Long Subject: Re: Use of contiguous physical memory in cxgbe driver In-Reply-To: <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402111348.52135.jhb@freebsd.org> <201402121446.19278.jhb@freebsd.org> <21244.20212.423983.960018@hergotha.csail.mit.edu> <20140213075651.GY34851@funkthat.com> <21245.1163.754141.154430@hergotha.csail.mit.edu> <5CAE71A4-EA1D-481D-AFBA-3738F8E66087@yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Feb 2014 14:34:02 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:34:04 -0000 <= said: > So what you=92re saying is that all of the other memory allocations t= hat go along with > moving data through a socket wind up fragmenting the free memory pool= to the point > where it becomes impossible to find 3 contig pages for a 9k jumbo RX = frame. I should mention that this behavior is particularly problematic when only some clients are even sending jumbo frames. Demanding three physically contiguous pages when 70% of the packets received are not more than 1514 bytes is particularly wasteful, although hopefully this is mitigated with LRO in the common case. (I don't know if LRO even works with NFS. How would I check?) -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 20:24:47 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 408ADF3B; Thu, 13 Feb 2014 20:24:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12B101E4C; Thu, 13 Feb 2014 20:24:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 28D38B9D8; Thu, 13 Feb 2014 15:24:46 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: Use of contiguous physical memory in cxgbe driver Date: Thu, 13 Feb 2014 15:16:54 -0500 Message-ID: <6154054.5G06XIekg6@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402121446.19278.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 13 Feb 2014 15:24:46 -0500 (EST) Cc: FreeBSD Net , Garrett Wollman , Navdeep Parhar , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:24:47 -0000 On Wednesday, February 12, 2014 03:36:38 PM Adrian Chadd wrote: > On 12 February 2014 11:46, John Baldwin wrote: > > Is this because UMA keeps lots of mbufs cached in your workload? The > > physmem buddy allocator certainly seeks to minimize fragmentation. > > However, it can't go yank memory out of UMA caches to do so. > > I'll ask you on irc, but where's that happening? My read of the code > is that once it grabs a larger page and fragments it, it's lost. It seeks to use the smallest size possible however. It is true that we don't attempt to move a busy page elsewhere to free up memory (e.g. if you had a 2MB free chunk with one busy 4k page in the middle), but we can't really do that safely. Given the existence of the direct map, we can't relocate a page and be sure that we have also relocated all possible pointers to it. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 20:42:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBFBD464; Thu, 13 Feb 2014 20:42:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58C6011A7; Thu, 13 Feb 2014 20:42:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s1DKghYA068199; Thu, 13 Feb 2014 22:42:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s1DKghYA068199 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s1DKghQw068198; Thu, 13 Feb 2014 22:42:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Feb 2014 22:42:43 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Use of contiguous physical memory in cxgbe driver Message-ID: <20140213204243.GT24664@kib.kiev.ua> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402121446.19278.jhb@freebsd.org> <6154054.5G06XIekg6@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5fM1MC9alg+yIaL4" Content-Disposition: inline In-Reply-To: <6154054.5G06XIekg6@ralph.baldwin.cx> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:42:48 -0000 --5fM1MC9alg+yIaL4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2014 at 03:16:54PM -0500, John Baldwin wrote: > On Wednesday, February 12, 2014 03:36:38 PM Adrian Chadd wrote: > > On 12 February 2014 11:46, John Baldwin wrote: > > > Is this because UMA keeps lots of mbufs cached in your workload? The > > > physmem buddy allocator certainly seeks to minimize fragmentation.=20 > > > However, it can't go yank memory out of UMA caches to do so. > >=20 > > I'll ask you on irc, but where's that happening? My read of the code > > is that once it grabs a larger page and fragments it, it's lost. >=20 > It seeks to use the smallest size possible however. It is true that we d= on't=20 > attempt to move a busy page elsewhere to free up memory (e.g. if you had = a 2MB=20 > free chunk with one busy 4k page in the middle), but we can't really do t= hat=20 > safely. Given the existence of the direct map, we can't relocate a page = and=20 > be sure that we have also relocated all possible pointers to it. Well, this depends on the current use of the page. We would be unable to page-out if the statement is completely true. We could relocate the 'user' pages, i.e. pages belonging to active or inactive queues, which are not hold/busy/wired. But I agree that for the load discussed, this is a minority and we indeed cannot relocate the content of the unmanaged page. --5fM1MC9alg+yIaL4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJS/S5CAAoJEJDCuSvBvK1B4gUP/24FZG7RrtEkA8KrsHu+1zol NPlfki66NBnQ0uNdh/KJB/9hJK0ZLQEQhK9B6Z9TkaH54msrAEP+2g8Hr6o3zqdj gV2d6TL4suhvDH1KBkohjaCGRDAGNaPUDgkgEPy4QeJOB57Yr3MVAjR3XhYDLyAa E8RtA1CuswA8xTIlZlaX0iZcZSbFXVqK/rGiC01X2FzsVhbhl5Pl5zcPg25xn162 ZycAZ4saWHipepoCXonk87LzKQeTB5XCZfer2nUra/ZAAjmvgpmYQq1pkLMj0WGi GC1pSM+RhvXvVvAVrSbsS6Axhc1nfYw2I9TPiFoQ3XK8qXAO3JXoHxarEw68QzVZ hZkRw5KTkUSkOC12MdOOJCiWIdWY7zqnhXHTVzeaTKIjSUEA+C3dmvZqMcp+EWhA pTDCZv36wjfCZc4ytFgt+P6viMZpMBj11g2eZgAp0mD0NFbuhRxcDaZTDl593E9W nTmDuE7uEvphH2mx3QR4GToPnCp5BBhrpo3EfPSkrkyaJjjHmtcFjOezXHlAZkJ0 rVDX8vwF6RTrEnf+CWowDPkjnpBmGzTbZJ64nMbZWNNwCY8974e7gCnOLkmZVME3 Fo5aNzmg4WescCrOZePAmi6td6drsT36Fr9UNEVzehZYPbajvMKGV7o3d/eK16Ev SJvznEgF93vnB4hq9lTe =Zsai -----END PGP SIGNATURE----- --5fM1MC9alg+yIaL4-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 13 21:05:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5EA7681; Thu, 13 Feb 2014 21:05:16 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7206313CD; Thu, 13 Feb 2014 21:05:16 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1DL5Enc049484; Thu, 13 Feb 2014 16:05:14 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1DL5ErT049481; Thu, 13 Feb 2014 16:05:14 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21245.13194.145088.287817@hergotha.csail.mit.edu> Date: Thu, 13 Feb 2014 16:05:14 -0500 From: Garrett Wollman To: John Baldwin Subject: Re: Use of contiguous physical memory in cxgbe driver In-Reply-To: <6154054.5G06XIekg6@ralph.baldwin.cx> References: <21216.22944.314697.179039@hergotha.csail.mit.edu> <201402121446.19278.jhb@freebsd.org> <6154054.5G06XIekg6@ralph.baldwin.cx> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 13 Feb 2014 16:05:14 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:05:16 -0000 < said: > It seeks to use the smallest size possible however. It is true that > we don't attempt to move a busy page elsewhere to free up memory > (e.g. if you had a 2MB free chunk with one busy 4k page in the > middle), but we can't really do that safely. Given the existence of > the direct map, we can't relocate a page and be sure that we have > also relocated all possible pointers to it. I doubt that this can be usefully auto-configured. As an administrator, I would be perfectly happy with a situation where I can tell the system to set aside some amount of memory at initialization (say, 16 superpages per (virtual) CPU) and get better performance. It's not a real imposition on a 128-GB server to set aside 1 GB of memory for big contiguous allocations if the applications will benefit from it. But in the absence of a guaranteed allocation, network drivers need to avoid requiring contiguous physical memory when they don't need it. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri Feb 14 01:40:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 195C5C2A; Fri, 14 Feb 2014 01:40:14 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 972BD1AEA; Fri, 14 Feb 2014 01:40:13 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3fQHMv5WdfzGN5h; Fri, 14 Feb 2014 02:40:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1392342007; x=1394934008; bh=kDo KUn3U+RvZMlXJpHmtG0KaTR73yonxHwl56mQFTwU=; b=AwVoyxr0viFQApHnxz1 TNopms1gjcPSIAxe/O89FY4z5yNkBVSv+Vb88ldOaPakgbvCA0bGh9SJ7FvC8wgD L9z8zhdIBT3nDsfRZaAJJofu/zV/lJimrtn1eImkXATBD55sznoDaAQXQpnfHo2f MjYSL9On5dIjnvyhxUvGu+IM= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id tPS2Fa_CqwvM; Fri, 14 Feb 2014 02:40:07 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 14 Feb 2014 02:40:07 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id 96711153; Fri, 14 Feb 2014 02:40:07 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 14 Feb 2014 02:40:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 14 Feb 2014 02:40:07 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single =?UTF-8?Q?utilities=3F?= Organization: J. Stefan Institute In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> Message-ID: <3feb1ef62b087b8bf00f34c42c5c2954@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 Cc: freebsd-hackers@freebsd.org, "Wojciech A. Koszek" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 01:40:14 -0000 2014-02-11, Mark Martinec wrote: > Remember the original PHK's story ( http://bikeshed.com/ ) ? > It ended favourably for the sleep(1) command, it got its new feature. > What can be learned there is: just needs someone to do it and be > persistent enough to be accepted. > > Looks like a perfect task for Google Summer of Code 2014, > time to apply is very near: > http://www.google-melange.com/gsoc/homepage/google/gsoc2014 2014-02-12, Kevin Oberman wrote: > For those who are new at IPv6, the ping6 and traceroute6 commands come > from > the WIDE KAME project. KAME developed one of the earliest IPv6 stacks > and > WIDE used FreeBSD. It became the FreeBSD IPv6 stack and the ping6 and > traceroute6 utilities were brought in with the rest of the KAME code. > > When these tools were written, the IPv6 stack and the supporting > libraries > and APIs were very primitive. I suspect that it was quicker to write > new > tools than to try to integrate IPv6 into the existing standard tools > and, > when things were so rough, there was a clear effort to avoid changes to > working IPv4 code. Separate IPv4 and IPv6 tools made sense then, but > the > need has long vanished... probably even before the KAME project ended. > But > the old, separate tools lived on through simple inertia. > > And so it is today. Inertia is NO reason that it should be this way > forever. I have submitted two entries for FreeBSD Google Summer of Code 2014: https://wiki.freebsd.org/SummerOfCode2014 (should show up there eventually after a review, I hope), one for a unified ping and ping6, the other for a unified traceroute and traceroute6. My first impression was that it may be possible to do both in a single 12 week GSoC job, although after checking existing source code and writing the proposal it now looks to me more like two full-time summer jobs, if they are to be done properly and with attention to details. Looking for one, or preferably two, mentors for students for these tasks. I wonder if Bjoern A. Zeeb wouldn't be the best man for the job ;) Mark From owner-freebsd-net@FreeBSD.ORG Fri Feb 14 03:24:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A6F084B for ; Fri, 14 Feb 2014 03:24:39 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 508231749 for ; Fri, 14 Feb 2014 03:24:39 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so4328163ier.4 for ; Thu, 13 Feb 2014 19:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=o5dK6cIEU7C/Nt+rTWCYeR9vAKfwaTFuBy1toEAIako=; b=LssX3ZwPn8AARx2vDeWShlvreID+Qw51vHZux0Aqe8padHmplpCTcomqxZ0vlglTwa XhEBEugkNvD4HQ3/CHj5P1m72cnqpaV5qa3r14+998kNc3pkjw6RjJAwlh+OxeWsO2H3 mLUovAHzJTDc42a2DARSS0YH6lUnfOzCzOoXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=o5dK6cIEU7C/Nt+rTWCYeR9vAKfwaTFuBy1toEAIako=; b=OVbGLKNtS0z6thoThsZU8HYFmTetSVyjpEs7uqJsSCavNfKQ6v7ZNgrGGja7jDvTr/ /RP285Rv7Djg39a6olmIRK6i7HvL9CYbVoq4VlZQLSTvgi/1qcybKjeQDE2i9Fg7PT05 olxfmeMlckWtw3U4qmXt8duPEw6+KJKp0AvabSDaogT+qeEhGc1W4HT16myGIeyR2uEb VeT+70gEpFYFUQok9now5ITfeaEDmYofMs5tpkTKxD8+My12+9c0rjFBYtwwSMVnF1Ll 0mKMLDmkqRyDd4RUMCFcmlM4Ygp7CmX7+qBoUdKi7wFJNpa7NEPje1zGCOzZSgN/k0Gj oTQA== X-Gm-Message-State: ALoCoQmDWCXJQHyaIS8VMk6cf/OIrkaTagMSPb7i7ItqJCe/kx1LtOGPg5gIBl9yKDS1TwMcfRzS X-Received: by 10.50.137.71 with SMTP id qg7mr431215igb.38.1392348278652; Thu, 13 Feb 2014 19:24:38 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id c17sm590678igo.4.2014.02.13.19.24.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 19:24:36 -0800 (PST) References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> <0c45208d87526a80f559ac09e28163c2.authenticated@ultimatedns.net> <3feb1ef62b087b8bf00f34c42c5c2954@mailbox.ijs.si> Mime-Version: 1.0 (1.0) In-Reply-To: <3feb1ef62b087b8bf00f34c42c5c2954@mailbox.ijs.si> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-DE296154-25EF-470F-8900-A78FBC004AF7; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <05380FA6-4E24-4BFA-AB96-81665C867ABA@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Date: Thu, 13 Feb 2014 22:24:33 -0500 To: Mark Martinec Cc: "freebsd-net@freebsd.org" , "Wojciech A. Koszek" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 03:24:39 -0000 --Apple-Mail-DE296154-25EF-470F-8900-A78FBC004AF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Feb 13, 2014, at 20:40, Mark Martinec wr= ote: >=20 > 2014-02-11, Mark Martinec wrote: >> Remember the original PHK's story ( http://bikeshed.com/ ) ? >> It ended favourably for the sleep(1) command, it got its new feature. >> What can be learned there is: just needs someone to do it and be >> persistent enough to be accepted. >> Looks like a perfect task for Google Summer of Code 2014, >> time to apply is very near: >> http://www.google-melange.com/gsoc/homepage/google/gsoc2014 >=20 >=20 > 2014-02-12, Kevin Oberman wrote: >> For those who are new at IPv6, the ping6 and traceroute6 commands come fr= om >> the WIDE KAME project. KAME developed one of the earliest IPv6 stacks and= >> WIDE used FreeBSD. It became the FreeBSD IPv6 stack and the ping6 and >> traceroute6 utilities were brought in with the rest of the KAME code. >> When these tools were written, the IPv6 stack and the supporting librarie= s >> and APIs were very primitive. I suspect that it was quicker to write new >> tools than to try to integrate IPv6 into the existing standard tools and,= >> when things were so rough, there was a clear effort to avoid changes to >> working IPv4 code. Separate IPv4 and IPv6 tools made sense then, but the >> need has long vanished... probably even before the KAME project ended. Bu= t >> the old, separate tools lived on through simple inertia. >> And so it is today. Inertia is NO reason that it should be this way forev= er. >=20 >=20 > I have submitted two entries for FreeBSD Google Summer of Code 2014: >=20 > https://wiki.freebsd.org/SummerOfCode2014 >=20 > (should show up there eventually after a review, I hope), >=20 > one for a unified ping and ping6, the other for a unified traceroute > and traceroute6. My first impression was that it may be possible to do > both in a single 12 week GSoC job, although after checking existing > source code and writing the proposal it now looks to me more like > two full-time summer jobs, if they are to be done properly and with > attention to details. >=20 > Looking for one, or preferably two, mentors for students for these tasks. > I wonder if Bjoern A. Zeeb wouldn't be the best man for the job ;) >=20 Awesome, personally that would seem like the best route not only to have the= focus on the tool itself but to put focus on achieving one or another eithe= r way it's progress. If we were voting I couldn't agree more with Bjoern if he would accept it.. C= ouldn't imagine someone more in depth to fit the task.= --Apple-Mail-DE296154-25EF-470F-8900-A78FBC004AF7 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIxNDAzMjQzNVowIwYJKoZIhvcN AQkEMRYEFDGGPv6hogiWrNccLz/tj9gXmebDMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEARnUiPZ4zkiVIgPU0MKec rU+oIBY6zFTCoGIp9ymCKwbqj1B/O2cTXcqc8lyDTGxdRJvLQGRgaFk1G4L/fZSTcEYrduDhKubH tNZvN1zGdgCd7K/x8LpXrcOwUo/OsRCK2bRbYSsZaHbddjLcCEKyoCn/e5lQWcGsLt42jGYJENr2 wYkJPOv/X1LghOFbkR8x0OgS2xZdXEbAOcTugiyrw9yk/kN1cEblBy0qwGW9fcJQEdRSAG6ekpx3 Am6Z7hDVXeESjq5cRlLNHt4xilv6bOPHkp7pqSzKijXV4P79D1sbb0jwH/xzOLF+NbOq5WLXGMFr 03UmFkvyMS5UQm3UiAAAAAAAAA== --Apple-Mail-DE296154-25EF-470F-8900-A78FBC004AF7-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 14 07:21:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 888EFEA8 for ; Fri, 14 Feb 2014 07:21:32 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23E891798 for ; Fri, 14 Feb 2014 07:21:31 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u56so8575852wes.30 for ; Thu, 13 Feb 2014 23:21:30 -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=7WQu4+Nz1RCAcYV0Cy1XckFTNRSKyevJaoY6jjkszvc=; b=v3nb5ZcUjBfKPoyh3o7d4rL/yLJ4J/0fysWLNJ8PIpWBdVdZgR5cvsMoIEe8dR+ZNL nkNocvkWaVPeszLbkf/ZChRP7ReuO+HGArsKvnFyUApzpVRZPa76fZd0RrA/EVFwxYf7 Fq8xg2DPZ55ZCohyATrxU15CrelkZNFcVOQncrPOUFlQ1+Wng2a3rmKPyDwXVxjawiMF G7Y1m/AVIHEKQphPFQlGvyu1hwVdDbGFOF7JbwAW8h/mPFjFv9/GX7gfoO4hyHHfZD7T DNV1say9yIQxGhl1+tNZP9X+6r7vyzdBIilZ+XqirLNzDn3EQA4PICxExSQS9OKQB1/D TPsA== MIME-Version: 1.0 X-Received: by 10.194.6.164 with SMTP id c4mr535207wja.38.1392362490622; Thu, 13 Feb 2014 23:21:30 -0800 (PST) Received: by 10.194.29.163 with HTTP; Thu, 13 Feb 2014 23:21:30 -0800 (PST) In-Reply-To: <1392304466.63673.23.camel@btw.pki2.com> References: <1392304466.63673.23.camel@btw.pki2.com> Date: Fri, 14 Feb 2014 07:21:30 +0000 Message-ID: Subject: Re: Recommendations for packet capture From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:21:32 -0000 On Thu, Feb 13, 2014 at 3:14 PM, Dennis Glatting wrote: > On Thu, 2014-02-13 at 09:14 +0000, C. L. Martinez wrote: >> Hi all, >> >> I need to setup some FreeBSD (or Linux, it depends) hosts to use as a >> packet capture sensors for our infrastrucutre. >> >> Searching about software that I could use under FreeBSD, I only find >> these ones: >> >> a) daemonlogger >> b) streamdb >> >> For Linux, it seems exits more alternatives. Any suggestions?? >> >> I need to monitor 1 GiB networks. >> > > I've not (yet) used these: > > /usr/ports/security/sguil-client > /usr/ports/security/sguil-sensor > /usr/ports/security/sguil-server > > >> Thanks. Thanks Dennis, but Sguil is not a packet capture componente. Sguil needs daemonlogger to show you captured data. From owner-freebsd-net@FreeBSD.ORG Fri Feb 14 22:35:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E7273E for ; Fri, 14 Feb 2014 22:35:50 +0000 (UTC) Received: from smtp.novso.com (smtp1.novso.com [IPv6:2a00:14e8:28:3::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 813911DAF for ; Fri, 14 Feb 2014 22:35:49 +0000 (UTC) Message-ID: <1392417340.10711.5.camel@fr-wks3.corp.novso.com> Subject: Re: IPsec filtertunnel broken on FreeBSD 10 From: Nicolas DEFFAYET To: freebsd-net@freebsd.org Date: Fri, 14 Feb 2014 23:35:40 +0100 In-Reply-To: <1391725273.22934.16.camel@fr-wks3.corp.novso.com> References: <1391725273.22934.16.camel@fr-wks3.corp.novso.com> Organization: DEFFAYET.COM Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "Andrey V. Elsukov" , Mike Tancsa X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:35:50 -0000 On Thu, 2014-02-06 at 23:21 +0100, Nicolas DEFFAYET wrote: Hello, The IPsec filtertunnel is broken on FreeBSD 10: incoming packets decapsulated are not going to firewall. > This issue affect 10.0-RELEASE and 10.0-STABLE. > 9.1-RELEASE and 9.2-RELEASE are not affected. > > Of course the systctl show that filtertunnel is enabled: > net.inet.ipsec.filtertunnel=1 > net.inet6.ipsec.filtertunnel=1 > > This issue is serious as it's not possible to use firewall (ipfw/pf) for > secure a gre/gif/l2tp IPsec tunnel as the incoming packets decapsulated > are not seen by the firewall. > > Many peoples have reported the issue on forums.freebsd.org and a bug > report have been open: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/185876 > > For try to provide a fix, i have run a diff on kernel source on net, > netinet, netinet6 and netipsec folders between 9.2-RELEASE and > 10.0-RELEASE but I didn't have found what change can break IPsec > filtertunnel. I have done another couple of tests, please find bellow the traces: host1 re0 192.168.0.1 <- cable -> re0 192.168.0.2 host2 host1 is running FreeBSD 9.1 host2 is running FreeBSD 10.0 Without IPsec, everywork fine: host1 can ssh host2 and vice versa Now IPsec is enable on the link beetwen host1 and host2 host1# cat /etc/ipsec.conf flush; spdflush; spdadd 192.168.0.1/32 192.168.0.2/32 any -P out ipsec esp/tunnel/192.168.0.1-192.168.0.2/require; spdadd 192.168.0.2/32 192.168.0.1/32 any -P in ipsec esp/tunnel/192.168.0.2-192.168.0.1/require; host2# cat /etc/ipsec.conf flush; spdflush; spdadd 192.168.0.2/32 192.168.0.1/32 any -P out ipsec esp/tunnel/192.168.0.2-192.168.0.1/require; spdadd 192.168.0.1/32 192.168.0.2/32 any -P in ipsec esp/tunnel/192.168.0.1-192.168.0.2/require; pf rules are simple and are set for see packets hitting firewall: block out log all block in log all pass log quick on re0 all @0 block drop out log all @1 block drop in log all @2 pass log quick on re0 all flags S/SA keep state Same thing can be done with ipfw. Test n°1: ssh from host1 to host2 Result: FAULT (host 1 can't ssh host 2) host1 pf log: Feb 14 21:42:33 host1 pf: 2014-02-14 21:42:32.698532 rule 2..16777216/0(match): pass in on re0: 192.168.0.2 > 192.168.0.1: 192.168.0.2.22 > 192.168.0.1.52431: Flags [S.], seq 3755304488, ack 3847832139, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4230148293 ecr 948855914], length 0 (ipip-proto-4) Feb 14 21:42:33 host1 pf: 2014-02-14 21:42:32.698648 rule 1..16777216/0(match): block in on re0: 192.168.0.2.22 > 192.168.0.1.52431: Flags [S.], seq 3755304488, ack 3847832139, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4230148293 ecr 948855914], length 0 Feb 14 21:42:36 host1 pf: 2014-02-14 21:42:35.698696 rule 1..16777216/0(match): block in on re0: 192.168.0.2.22 > 192.168.0.1.52431: Flags [S.], seq 3755304488, ack 3847832139, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4230148293 ecr 948855914], length 0 host2 pf log: empty Test n°2: ssh from host2 to host1 Result: SUCCESS (host2 can ssh host1) host1 pf log: Feb 14 21:41:31 host1 pf: 2014-02-14 21:41:30.873695 rule 2..16777216/0(match): pass in on re0: 192.168.0.2.12400 > 192.168.0.1.22: Flags [S], seq 1597516146, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 426470902 ecr 0], length 0 host2 pf log: empty Test n°3: skip interface test a) "set skip on re0" (only) on host1 host1 can ssh host2 host2 can ssh host1 b) "set skip on re0" (only) on host2 host1 can't ssh host2 host2 can ssh host1 c) "set skip on re0" on host1 AND host2 host1 can ssh host2 host2 can ssh host1 Test n°4: decapsulated ipsec traffic seen by enc0 (tcpdump -s0 -nvei enc0) firewall disabled on host1 and host2 a) host1 ssh host2 host1 22:18:50.969341 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48946, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->27bd)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [S], cksum 0xd778 (correct), seq 2948225374, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 951034185 ecr 0], length 0 22:18:50.969351 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48947, offset 0, flags [none], proto IPIP (4), length 80, bad cksum 0 (->67aa)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48946, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.1.14756 > 192.168.0.2.22: Flags [S], cksum 0xd778 (correct), seq 2948225374, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 951034185 ecr 0], length 0 22:18:50.969677 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25667, offset 0, flags [none], proto IPIP (4), length 80) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25666, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.22 > 192.168.0.1.14756: Flags [S.], cksum 0xc1f3 (correct), seq 3114904911, ack 2948225375, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2490767876 ecr 951034185], length 0 22:18:50.969772 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48948, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->27c3)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xecae (correct), ack 1, win 1040, options [nop,nop,TS val 951034185 ecr 2490767876], length 0 22:18:50.969778 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48949, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->67b0)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48948, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xecae (correct), ack 1, win 1040, options [nop,nop,TS val 951034185 ecr 2490767876], length 0 22:18:51.001033 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25669, offset 0, flags [none], proto IPIP (4), length 106) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25668, offset 0, flags [DF], proto TCP (6), length 86) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x7791 (correct), seq 1:35, ack 1, win 1040, options [nop,nop,TS val 2490767907 ecr 951034185], length 34 22:18:51.100989 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48953, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->27be)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xebe9 (correct), ack 35, win 1040, options [nop,nop,TS val 951034317 ecr 2490767907], length 0 22:18:51.100996 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48954, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->67ab)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48953, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xebe9 (correct), ack 35, win 1040, options [nop,nop,TS val 951034317 ecr 2490767907], length 0 22:18:52.857275 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49129, offset 0, flags [DF], proto TCP (6), length 58, bad cksum 0 (->2708)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [P.], cksum 0xfd0b (correct), seq 1:7, ack 35, win 1040, options [nop,nop,TS val 951036073 ecr 2490767907], length 6 22:18:52.857284 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49130, offset 0, flags [none], proto IPIP (4), length 78, bad cksum 0 (->66f5)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49129, offset 0, flags [DF], proto TCP (6), length 58) 192.168.0.1.14756 > 192.168.0.2.22: Flags [P.], cksum 0xfd0b (correct), seq 1:7, ack 35, win 1040, options [nop,nop,TS val 951036073 ecr 2490767907], length 6 22:18:52.857728 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25693, offset 0, flags [none], proto IPIP (4), length 91) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25692, offset 0, flags [DF], proto TCP (6), length 71) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x6121 (correct), seq 35:54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 19 22:18:52.857763 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25695, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25694, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.22 > 192.168.0.1.14756: Flags [F.], cksum 0xddb2 (correct), seq 54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 0 22:18:52.857850 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49131, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->270c)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xddb2 (correct), ack 55, win 1040, options [nop,nop,TS val 951036073 ecr 2490769764], length 0 22:18:52.857857 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49132, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->66f9)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49131, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xddb2 (correct), ack 55, win 1040, options [nop,nop,TS val 951036073 ecr 2490769764], length 0 22:18:52.858107 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49134, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->2709)!) 192.168.0.1.14756 > 192.168.0.2.22: Flags [F.], cksum 0xddb0 (correct), seq 7, ack 55, win 1040, options [nop,nop,TS val 951036074 ecr 2490769764], length 0 22:18:52.858115 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49135, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->66f6)!) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49134, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [F.], cksum 0xddb0 (correct), seq 7, ack 55, win 1040, options [nop,nop,TS val 951036074 ecr 2490769764], length 0 22:18:52.858412 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25697, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25696, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.22 > 192.168.0.1.14756: Flags [.], cksum 0xddaf (correct), ack 8, win 1040, options [nop,nop,TS val 2490769765 ecr 951036074], length 0 host2 22:18:56.095556 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48947, offset 0, flags [none], proto IPIP (4), length 80) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48946, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.1.14756 > 192.168.0.2.22: Flags [S], cksum 0xd778 (correct), seq 2948225374, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 951034185 ecr 0], length 0 22:18:56.095661 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25666, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->82bd)!) 192.168.0.2.22 > 192.168.0.1.14756: Flags [S.], cksum 0xc1f3 (correct), seq 3114904911, ack 2948225375, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2490767876 ecr 951034185], length 0 22:18:56.095669 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25667, offset 0, flags [none], proto IPIP (4), length 80, bad cksum 0 (->c2aa)!) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25666, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.22 > 192.168.0.1.14756: Flags [S.], cksum 0xc1f3 (correct), seq 3114904911, ack 2948225375, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2490767876 ecr 951034185], length 0 22:18:56.095963 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48949, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48948, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xecae (correct), ack 1, win 1040, options [nop,nop,TS val 951034185 ecr 2490767876], length 0 22:18:56.126975 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25668, offset 0, flags [DF], proto TCP (6), length 86, bad cksum 0 (->82a1)!) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x7791 (correct), seq 1:35, ack 1, win 1040, options [nop,nop,TS val 2490767907 ecr 951034185], length 34 22:18:56.126986 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25669, offset 0, flags [none], proto IPIP (4), length 106, bad cksum 0 (->c28e)!) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25668, offset 0, flags [DF], proto TCP (6), length 86) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x7791 (correct), seq 1:35, ack 1, win 1040, options [nop,nop,TS val 2490767907 ecr 951034185], length 34 22:18:56.227206 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 48954, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 48953, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xebe9 (correct), ack 35, win 1040, options [nop,nop,TS val 951034317 ecr 2490767907], length 0 22:18:57.983478 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49130, offset 0, flags [none], proto IPIP (4), length 78) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49129, offset 0, flags [DF], proto TCP (6), length 58) 192.168.0.1.14756 > 192.168.0.2.22: Flags [P.], cksum 0xfd0b (correct), seq 1:7, ack 35, win 1040, options [nop,nop,TS val 951036073 ecr 2490767907], length 6 22:18:57.983671 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25692, offset 0, flags [DF], proto TCP (6), length 71, bad cksum 0 (->8298)!) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x6121 (correct), seq 35:54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 19 22:18:57.983680 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25693, offset 0, flags [none], proto IPIP (4), length 91, bad cksum 0 (->c285)!) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25692, offset 0, flags [DF], proto TCP (6), length 71) 192.168.0.2.22 > 192.168.0.1.14756: Flags [P.], cksum 0x6121 (correct), seq 35:54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 19 22:18:57.983750 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25694, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->82a9)!) 192.168.0.2.22 > 192.168.0.1.14756: Flags [F.], cksum 0xddb2 (correct), seq 54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 0 22:18:57.983756 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25695, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->c296)!) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25694, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.22 > 192.168.0.1.14756: Flags [F.], cksum 0xddb2 (correct), seq 54, ack 7, win 1040, options [nop,nop,TS val 2490769764 ecr 951036073], length 0 22:18:57.984023 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49132, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49131, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [.], cksum 0xddb2 (correct), ack 55, win 1040, options [nop,nop,TS val 951036073 ecr 2490769764], length 0 22:18:57.984282 (authentic,confidential): SPI 0x0377065e: (tos 0x10, ttl 64, id 49135, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x10, ttl 64, id 49134, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.14756 > 192.168.0.2.22: Flags [F.], cksum 0xddb0 (correct), seq 7, ack 55, win 1040, options [nop,nop,TS val 951036074 ecr 2490769764], length 0 22:18:57.984375 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25696, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->82a7)!) 192.168.0.2.22 > 192.168.0.1.14756: Flags [.], cksum 0xddaf (correct), ack 8, win 1040, options [nop,nop,TS val 2490769765 ecr 951036074], length 0 22:18:57.984384 (authentic,confidential): SPI 0x09560d48: (tos 0x0, ttl 64, id 25697, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->c294)!) 192.168.0.2 > 192.168.0.1: (tos 0x0, ttl 64, id 25696, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.22 > 192.168.0.1.14756: Flags [.], cksum 0xddaf (correct), ack 8, win 1040, options [nop,nop,TS val 2490769765 ecr 951036074], length 0 b) host2 ssh host1 host1 22:24:46.905154 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26901, offset 0, flags [none], proto IPIP (4), length 80) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26900, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.16622 > 192.168.0.1.22: Flags [S], cksum 0xa6a1 (correct), seq 3695971359, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 429066912 ecr 0], length 0 22:24:46.905247 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57083, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->804)!) 192.168.0.1.22 > 192.168.0.2.16622: Flags [S.], cksum 0x1975 (correct), seq 548844, ack 3695971360, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 999551379 ecr 429066912], length 0 22:24:46.905255 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57084, offset 0, flags [none], proto IPIP (4), length 80, bad cksum 0 (->47f1)!) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57083, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.1.22 > 192.168.0.2.16622: Flags [S.], cksum 0x1975 (correct), seq 548844, ack 3695971360, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 999551379 ecr 429066912], length 0 22:24:46.905568 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26903, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26902, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4430 (correct), ack 1, win 1040, options [nop,nop,TS val 429066912 ecr 999551379], length 0 22:24:46.930514 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57085, offset 0, flags [DF], proto TCP (6), length 101, bad cksum 0 (->7d9)!) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xce26 (correct), seq 1:50, ack 1, win 1040, options [nop,nop,TS val 999551404 ecr 429066912], length 49 22:24:46.930523 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57086, offset 0, flags [none], proto IPIP (4), length 121, bad cksum 0 (->47c6)!) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57085, offset 0, flags [DF], proto TCP (6), length 101) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xce26 (correct), seq 1:50, ack 1, win 1040, options [nop,nop,TS val 999551404 ecr 429066912], length 49 22:24:47.030842 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26907, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26906, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4368 (correct), ack 50, win 1040, options [nop,nop,TS val 429067038 ecr 999551404], length 0 22:24:48.537355 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26937, offset 0, flags [none], proto IPIP (4), length 78) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26936, offset 0, flags [DF], proto TCP (6), length 58) 192.168.0.2.16622 > 192.168.0.1.22: Flags [P.], cksum 0x5584 (correct), seq 1:7, ack 50, win 1040, options [nop,nop,TS val 429068544 ecr 999551404], length 6 22:24:48.537551 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57171, offset 0, flags [DF], proto TCP (6), length 71, bad cksum 0 (->7a1)!) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xba93 (correct), seq 50:69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 19 22:24:48.537559 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57172, offset 0, flags [none], proto IPIP (4), length 91, bad cksum 0 (->478e)!) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57171, offset 0, flags [DF], proto TCP (6), length 71) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xba93 (correct), seq 50:69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 19 22:24:48.537618 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57173, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7b2)!) 192.168.0.1.22 > 192.168.0.2.16622: Flags [F.], cksum 0x3725 (correct), seq 69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 0 22:24:48.537623 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57174, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->479f)!) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57173, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.22 > 192.168.0.2.16622: Flags [F.], cksum 0x3725 (correct), seq 69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 0 22:24:48.537930 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26939, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26938, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x3724 (correct), ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:48.538116 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26942, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26941, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [F.], cksum 0x3723 (correct), seq 7, ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:48.538187 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57175, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7b0)!) 192.168.0.1.22 > 192.168.0.2.16622: Flags [.], cksum 0x3722 (correct), ack 8, win 1040, options [nop,nop,TS val 999553012 ecr 429068545], length 0 22:24:48.538206 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57176, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->479d)!) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57175, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.22 > 192.168.0.2.16622: Flags [.], cksum 0x3722 (correct), ack 8, win 1040, options [nop,nop,TS val 999553012 ecr 429068545], length 0 host2 22:24:52.028268 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26900, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 0 (->7ddb)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [S], cksum 0xa6a1 (correct), seq 3695971359, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 429066912 ecr 0], length 0 22:24:52.028281 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26901, offset 0, flags [none], proto IPIP (4), length 80, bad cksum 0 (->bdc8)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26900, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.16622 > 192.168.0.1.22: Flags [S], cksum 0xa6a1 (correct), seq 3695971359, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 429066912 ecr 0], length 0 22:24:52.028603 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57084, offset 0, flags [none], proto IPIP (4), length 80) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57083, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.1.22 > 192.168.0.2.16622: Flags [S.], cksum 0x1975 (correct), seq 548844, ack 3695971360, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 999551379 ecr 429066912], length 0 22:24:52.028719 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26902, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7de1)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4430 (correct), ack 1, win 1040, options [nop,nop,TS val 429066912 ecr 999551379], length 0 22:24:52.028728 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26903, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->bdce)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26902, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4430 (correct), ack 1, win 1040, options [nop,nop,TS val 429066912 ecr 999551379], length 0 22:24:52.053884 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57086, offset 0, flags [none], proto IPIP (4), length 121) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57085, offset 0, flags [DF], proto TCP (6), length 101) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xce26 (correct), seq 1:50, ack 1, win 1040, options [nop,nop,TS val 999551404 ecr 429066912], length 49 22:24:52.153958 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26906, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7ddd)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4368 (correct), ack 50, win 1040, options [nop,nop,TS val 429067038 ecr 999551404], length 0 22:24:52.153968 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26907, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->bdca)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26906, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x4368 (correct), ack 50, win 1040, options [nop,nop,TS val 429067038 ecr 999551404], length 0 22:24:53.660457 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26936, offset 0, flags [DF], proto TCP (6), length 58, bad cksum 0 (->7db9)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [P.], cksum 0x5584 (correct), seq 1:7, ack 50, win 1040, options [nop,nop,TS val 429068544 ecr 999551404], length 6 22:24:53.660466 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26937, offset 0, flags [none], proto IPIP (4), length 78, bad cksum 0 (->bda6)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26936, offset 0, flags [DF], proto TCP (6), length 58) 192.168.0.2.16622 > 192.168.0.1.22: Flags [P.], cksum 0x5584 (correct), seq 1:7, ack 50, win 1040, options [nop,nop,TS val 429068544 ecr 999551404], length 6 22:24:53.660903 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57172, offset 0, flags [none], proto IPIP (4), length 91) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57171, offset 0, flags [DF], proto TCP (6), length 71) 192.168.0.1.22 > 192.168.0.2.16622: Flags [P.], cksum 0xba93 (correct), seq 50:69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 19 22:24:53.660947 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57174, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57173, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.22 > 192.168.0.2.16622: Flags [F.], cksum 0x3725 (correct), seq 69, ack 7, win 1040, options [nop,nop,TS val 999553011 ecr 429068544], length 0 22:24:53.661048 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26938, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7dbd)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x3724 (correct), ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:53.661055 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26939, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->bdaa)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26938, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [.], cksum 0x3724 (correct), ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:53.661244 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26941, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->7dba)!) 192.168.0.2.16622 > 192.168.0.1.22: Flags [F.], cksum 0x3723 (correct), seq 7, ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:53.661253 (authentic,confidential): SPI 0x0d865338: (tos 0x10, ttl 64, id 26942, offset 0, flags [none], proto IPIP (4), length 72, bad cksum 0 (->bda7)!) 192.168.0.2 > 192.168.0.1: (tos 0x10, ttl 64, id 26941, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.16622 > 192.168.0.1.22: Flags [F.], cksum 0x3723 (correct), seq 7, ack 70, win 1040, options [nop,nop,TS val 429068545 ecr 999553011], length 0 22:24:53.661541 (authentic,confidential): SPI 0x098f7487: (tos 0x0, ttl 64, id 57176, offset 0, flags [none], proto IPIP (4), length 72) 192.168.0.1 > 192.168.0.2: (tos 0x0, ttl 64, id 57175, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.1.22 > 192.168.0.2.16622: Flags [.], cksum 0x3722 (correct), ack 8, win 1040, options [nop,nop,TS val 999553012 ecr 429068545], length 0 For recall - decapsulated ipsec traffic are seen by enc0 (tcpdump -s0 -nvei enc0) - sysctl are default one and are the same on host1 and host2 net.enc.in.ipsec_bpf_mask: 1 net.enc.in.ipsec_filter_mask: 1 net.enc.out.ipsec_bpf_mask: 3 net.enc.out.ipsec_filter_mask: 1 Any one know why there is a difference between FreeBSD 9.x and 10.x ? There is no major change in sys/netipsec, so something should be broken in sys/net or sys/netinet but i don't know what and how find this. How debug this ? Is it possible to see if the packet is pushed to pfil and to pf/ipfw ? Is it true or not that if a decapsulated ipsec packet is seen by enc0, this don't confirm that the packet have been received by pf/ipfw ? Many thanks for your help. -- Nicolas DEFFAYET From owner-freebsd-net@FreeBSD.ORG Sat Feb 15 20:15:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF1E5288 for ; Sat, 15 Feb 2014 20:15:06 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6888215FB for ; Sat, 15 Feb 2014 20:15:06 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WEldf-0000hb-Qs for freebsd-net@freebsd.org; Sat, 15 Feb 2014 21:15:04 +0100 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Feb 2014 21:15:03 +0100 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Feb 2014 21:15:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Kevin Bowling Subject: FreeBSD 10 network flapping, ix driver unreliable? Date: Sat, 15 Feb 2014 13:14:16 -0700 Lines: 24 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:15:06 -0000 Hi, I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each node has an Intel X520-DA2 dual port 10gig card. One of the ports on each go to a switch using direct attach coaxial cables. The other port is directly connected between the two nodes (think crossover in twisted pair terminology) again using direct attach coaxial cables. On both machines, and on both ports (including the "crossover"), the links flap several times per day. I've pasted the output of lspci -vv and dmesg here: https://gist.github.com/kev009/9024442 There's nothing outstanding about the setup otherwise. I suspected some interaction with the switch initially but the "crossover" has eliminated that suspicion. It seems the ix driver is not very reliable under common conditions, i.e. https://forums.freebsd.org/viewtopic.php?f=7&t=44570 and a search of this list. Any recommendations or tests? Regards, Kevin Bowling From owner-freebsd-net@FreeBSD.ORG Sat Feb 15 23: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38A17D14 for ; Sat, 15 Feb 2014 23:44:46 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0955B14F3 for ; Sat, 15 Feb 2014 23:44:45 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:62950 helo=new-host-2.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WEotY-0000UL-7K; Sat, 15 Feb 2014 18:43:40 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: FreeBSD 10 network flapping, ix driver unreliable? From: George Neville-Neil In-Reply-To: Date: Sat, 15 Feb 2014 18:43:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <61748F81-A763-4504-BC81-132D394F0170@neville-neil.com> References: To: Kevin Bowling X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:44:46 -0000 On Feb 15, 2014, at 15:14 , Kevin Bowling = wrote: > Hi, >=20 > I have FreeBSD 10.0-RELEASE installed on two Dell C6100 nodes. Each = node has an Intel X520-DA2 dual port 10gig card. One of the ports on = each go to a switch using direct attach coaxial cables. The other port = is directly connected between the two nodes (think crossover in twisted = pair terminology) again using direct attach coaxial cables. >=20 > On both machines, and on both ports (including the "crossover"), the = links flap several times per day. >=20 > I've pasted the output of lspci -vv and dmesg here: > https://gist.github.com/kev009/9024442 >=20 > There's nothing outstanding about the setup otherwise. I suspected = some interaction with the switch initially but the "crossover" has = eliminated that suspicion. >=20 > It seems the ix driver is not very reliable under common conditions, = i.e. https://forums.freebsd.org/viewtopic.php?f=3D7&t=3D44570 and a = search of this list. Any recommendations or tests? >=20 Can you post (to your gist link) the output of sysctl dev.ix ? Best, George From owner-freebsd-net@FreeBSD.ORG Sat Feb 15 23:44:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1496D15 for ; Sat, 15 Feb 2014 23:44:49 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AFD5714F4 for ; Sat, 15 Feb 2014 23:44:49 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:62952 helo=new-host-2.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WEoue-0000bo-Ib; Sat, 15 Feb 2014 18:44:48 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Recommendations for packet capture From: George Neville-Neil In-Reply-To: Date: Sat, 15 Feb 2014 18:44:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D9E8EFA-1EB0-4CA6-B26E-CA87553150E3@neville-neil.com> References: <1392304466.63673.23.camel@btw.pki2.com> To: "C. L. Martinez" X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:44:49 -0000 On Feb 14, 2014, at 2:21 , C. L. Martinez wrote: > On Thu, Feb 13, 2014 at 3:14 PM, Dennis Glatting wrote: >> On Thu, 2014-02-13 at 09:14 +0000, C. L. Martinez wrote: >>> Hi all, >>>=20 >>> I need to setup some FreeBSD (or Linux, it depends) hosts to use as = a >>> packet capture sensors for our infrastrucutre. >>>=20 >>> Searching about software that I could use under FreeBSD, I only find >>> these ones: >>>=20 >>> a) daemonlogger >>> b) streamdb >>>=20 >>> For Linux, it seems exits more alternatives. Any suggestions?? >>>=20 >>> I need to monitor 1 GiB networks. >>>=20 >>=20 >> I've not (yet) used these: >>=20 >> /usr/ports/security/sguil-client >> /usr/ports/security/sguil-sensor >> /usr/ports/security/sguil-server >>=20 >>=20 >>> Thanks. >=20 > Thanks Dennis, but Sguil is not a packet capture componente. Sguil > needs daemonlogger to show you captured data. I might be a bit confused. Can you just use tcpdump with the = appropriate flags to limit the size and number of files? What are you trying to achieve? Best, George