From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 19:58:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 134B527D for ; Sun, 4 Jan 2015 19:58:51 +0000 (UTC) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id F15D93448 for ; Sun, 4 Jan 2015 19:58:50 +0000 (UTC) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id DBD4DF7A372 for ; Sun, 4 Jan 2015 11:58:49 -0800 (PST) Date: Sun, 4 Jan 2015 12:58:49 -0700 (MST) From: topper727 To: freebsd-net@freebsd.org Message-ID: <1420401529827-5978277.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Anyone seen this error on em ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:58:51 -0000 Using Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. And my WIFI PCI card and dual legacy intel NIC PCI will cause system to HALT on boot. If I pull those cards out the system will boot but only one port will work that is built on the motherboard. If I disable both with jumpers then I can use a PCI card in the system. Refer to all the notes I did here https://forum.pfsense.org/index.php?topic=84909.0 Here is my dmesg log http://pastebin.com/tW9Qe3g2 Code: em0: port 0x4000-0x401f irq 16 at device 0.0 on pci2 pcib0: allocated type 3 (0xd0200000-0xd02fffff) for rid 20 of pcib2 pcib2: allocated initial memory window of 0xd0200000-0xd02fffff pcib2: allocated memory range (0xd0200000-0xd021ffff) for rid 10 of em0 em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xd0200000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 51 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: Setup of Shared code failed device_attach: em0 attach returned 6 -- View this message in context: http://freebsd.1045724.n5.nabble.com/Anyone-seen-this-error-on-em-tp4016166p5978277.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 21:04:42 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93CE23FD; Sun, 4 Jan 2015 21:04:42 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5845964F94; Sun, 4 Jan 2015 21:04:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9D07E7300A; Sun, 4 Jan 2015 22:09:19 +0100 (CET) Date: Sun, 4 Jan 2015 22:09:19 +0100 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org, tegge@freebsd.org Subject: BOOTP_SETTLE_DELAY in sys/nfs/bootp_subr.c ? Message-ID: <20150104210919.GA22198@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 21:04:42 -0000 [I realize this is code from 15 years ago so i am not sure if anyone still knows or remembers the answer] sys/nfs/bootp_subr.c is used to request via bootp or dhcp an address and a boot path. The negotiation is done in a loop, and apparently when replies are received on _all_ interfaces, the code extends the loop by another 3 seconds (BOOTP_SETTLE_DELAY) with a logic that is not documented and I do not follow. Any idea ? I would understand not stopping at the first reply in case we want to pick the 'best' one from multiple responses (which is implemented, to some degree, in bootpc_received() ). But if that is the case, one should either 1) use an unconditionally large timeout, or 2) take the first incoming packet (not necessarily valid) on _any_ interface as a signal that "ok this interface is now on" and apply the grace period from there. Why do i care ? I am booting a diskless kernel with bhyve and BOOTP_SETTLE_DELAY unnecessarily extends the boot time a lot, and even worse delays happen if you have multiple interfaces that do not respond due to some other unclear logic. Depending on what is the original intention i would like to implement either option #1 or #2 above. Also, I would like to use environment variables to set/override the in-kernel bootp settings cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 03:22:04 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92D5CB21 for ; Mon, 5 Jan 2015 03:22:04 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C8F92CBB for ; Mon, 5 Jan 2015 03:22:04 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t053M4km053998 for ; Mon, 5 Jan 2015 03:22:04 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t053M40c053997; Mon, 5 Jan 2015 03:22:04 GMT (envelope-from root) Date: Mon, 5 Jan 2015 03:22:04 +0000 To: freebsd-net@freebsd.org From: "gnn (George Neville-Neil)" Subject: [Differential] [Accepted] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSqA1w= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 03:22:04 -0000 gnn accepted this revision. gnn added a reviewer: gnn. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 03:40:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E65A9EF5 for ; Mon, 5 Jan 2015 03:40:36 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD1562E51 for ; Mon, 5 Jan 2015 03:40:36 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:51291 helo=[192.168.1.17]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Y7yWw-0007sI-No; Sun, 04 Jan 2015 22:40:35 -0500 From: "George Neville-Neil" To: "Isaac (.ike) Levy" Subject: Re: 10Gbit Interface Testing Date: Sun, 04 Jan 2015 22:40:34 -0500 Message-ID: In-Reply-To: <201412092110.sB9LA9Po018390@rs103.luxsci.com> References: <201412092110.sB9LA9Po018390@rs103.luxsci.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r5029) 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@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 03:40:37 -0000 On 9 Dec 2014, at 16:10, Isaac (.ike) Levy wrote: > Hi All, > > In our relatively small environment, I'm looking for pointers in > testing 10Gbit network performance, for internet-facing connectivity. > Our enviornment employs pairs of routers running FreeBSD- also > utilizing PF, CARP, and PFSYNC. > > We have 2 core problems testing the 10Gbit interfaces: > > 1) A lack of external options on the internet for testing. We've > found it non-trivial to adequately saturate a 10Gbit internet > connection in 2014, (without having one or two more 10Gbit connections > to saturate). We simply don't have enough outside resources we > control to saturate our lines for reasonable tests. > > 2) We've done our homework on testing, but would love any input from > this audience about ways to measure any of these: > - PPS (easier) > - Maximum Socket Connections (easier) > - New Socket Connections per Second (harder!) > - Redline Throughput (easier) > - Ways to measure PF performance, (state handling, etc...) > - Ways to start measure/test ALTQ based shaping, as we experiment with > it. > > Thanks for any input! Take a look at some of the scripts in my netperf project: git@github.com:gvnn3/netperf.git That uses Conductor: https://github.com/gvnn3/conductor which is still under development, but the packet generation is just pkt-gen on FreeBSD with netmap capable 10G cards (Chelsio or Intel). Bet, George From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 04:12:48 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D5B423C for ; Mon, 5 Jan 2015 04:12:48 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B10973F4A for ; Mon, 5 Jan 2015 04:12:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t054CPFW024596 for ; Mon, 5 Jan 2015 04:12:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196035] Subsequent connect on ready socket returns EINVAL instead of ECONNREFUSED Date: Mon, 05 Jan 2015 04:12:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: harrison.grundy@astrodoggroup.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gnn@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:12:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196035 Harrison Grundy changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |gnn@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 05:54:48 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2AA5446 for ; Mon, 5 Jan 2015 05:54:48 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CFCB2443 for ; Mon, 5 Jan 2015 05:54:48 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id k15so12077898qaq.7 for ; Sun, 04 Jan 2015 21:54:47 -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=cIOMR9vEXJIRQKl8VjcFT8vewF8xVMI77IKBhEoXT7w=; b=gfPVou4ci36rGPon2KOPF2LnWWJO0rYHDCV71e1YLaOOZTSw/z6UBWrNsCURYZpKvt czWJ6CLjHRrOzH/2R4kaMDF25XKXwftbTFnwRS4aHL+xLlnzbpyf/wRDqWPqup4Wv9Bv wNWZjlRKbCn3CDnu6zDd/nrwbR2zG5zLgru8JfLwAmF8cTX2n9Dv4xOtmRi+6WO4vKZp TZDh/l7QTmffESmDdCQALFFP2zSDJojyclomBR6anJUk1rNcHn+BZbn6aoxEPMUoo/rq p8orH9Gq2Jcr4ywUg1trUKkUj/gbG+aUHTU2ViYLMcNoDD4TU+zWJsJj/2/QHZ/WEjuh bvAw== MIME-Version: 1.0 X-Received: by 10.224.171.129 with SMTP id h1mr97598589qaz.74.1420437287682; Sun, 04 Jan 2015 21:54:47 -0800 (PST) Received: by 10.96.76.201 with HTTP; Sun, 4 Jan 2015 21:54:47 -0800 (PST) Date: Sun, 4 Jan 2015 21:54:47 -0800 Message-ID: Subject: netmap over virtio giving packets with extra 12 bytes From: Avinash Sridharan To: net@freebsd.org, Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 05:54:48 -0000 I am using netmap with the click modular router, running the click-modular router in user space. A while back I was using this combination with the e1000 device driver, with a slightly older netmap code-base. Recently I updated my netmap code base and am trying to use the click-modular router with netmap over a virtio-net device driver (over KVM). With this combination, though I was able to receive packets I was unable to interpret any packets coming from the FromDevice element. To debug this issue (and to negate any changes I made to the click-modular router), I ran the pkt-gen application with the "dump payload" option: sudo ~/pkt-gen -i eth1 -f rx -X This showed that packets are being received correctly from the netmap-enabled interface, but there are an extra "12" bytes appended to the packet. 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ << extra 12 bytes 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... 64: 00 00 00 00 bc 9b f6 74 As we can see, the above is an STP BPDU, and there are 12 leading bytes in the payload. The extra leading bytes screw up the packet interpretation. So is this is an artifact of the virtio-net driver or has something changed in the netmap device driver? Thanks, Avinash From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 06:57:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC042978 for ; Mon, 5 Jan 2015 06:57:33 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A79B1CDA for ; Mon, 5 Jan 2015 06:57:33 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id x13so9214473wgg.12 for ; Sun, 04 Jan 2015 22:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kbtWz2v6x7QA5gtIKtFHYw568TZzx16kt/lHtXRp384=; b=tQAm+YE8BraVUX6/T0CLqhpT3/jVF8UJGcCZEeV3MVwkmaO3sMDTFtAl9V+Apo1IGZ +OY3f2UVlCTYNCfUHEB4nfxC3m1qIgx61HcAfKKFzxUosheaFz1p2mSgXpg4c2kgRU6w S4QGdX67/zWEIULAFf3iSGFWOdUOo5gCGNeexAOKT1WPBFXszTlN56AF7fogcWn40frh J+RLpfntJ+Srlmo0mTKFuDFLW89o4TEGmyPi2Ajcmg2vMFwV4//wKZNo7ePU0JwOZtCc cv3bH8Q2uJqVrN9JJz9sa3FTK4q2VzVc/Th31c/1AQW4u6XMwmaLcRruxcyl9hMX1pJN 1WBw== X-Received: by 10.194.184.204 with SMTP id ew12mr118380818wjc.85.1420441051585; Sun, 04 Jan 2015 22:57:31 -0800 (PST) Received: from [10.99.0.3] ([213.188.107.182]) by mx.google.com with ESMTPSA id e18sm74171857wjz.27.2015.01.04.22.57.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 22:57:31 -0800 (PST) Message-ID: <54AA35DD.8080704@gmail.com> Date: Mon, 05 Jan 2015 07:57:33 +0100 From: Sascha User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-net@freebsd.org Subject: Re: CARP Problem/Bug? on 10.1-RELEASE References: <54A69F72.6060405@gmail.com> <54A6B5E3.5090200@multiplay.co.uk> In-Reply-To: <54A6B5E3.5090200@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 06:57:33 -0000 Hi Steven, you made my day! It's working again. But I continue my research. Rebooting takes the Port-Channel on the switch down. When the machine comes up the port-channel on the switch needs some seconds until it's up. During that time, traffic is not forwarded. Sometimes I could see on the console screen something like "send error 50 on vlan...... demoted by 0 to 720... " After setting "net.inet.carp.senderr_demotion_factor=0" I could see still the message. But then the Interface is demoted from 0 to 0. With this setting the "net.inet.carp.demotion" remains at 0. When the Port-Channel on the switch is up packets are forwarded again. Then the designated Backup machine goes back in the Backup state and machine 1 is getting the master again. So everything works now like expected! I think these new "send error" feature makes some adjustment necessary when using Link Aggregation or when the switch port takes some seconds until it forwards the traffic (not using spanning-tree portfast feature). It could be useful when the dev team would release some description how the new carp features work together. The manual explains what parameters you can set. But without understanding whats going on it gets some trial and error. Maybe there is still a description and I didn't find it until now. Thanks for the help! Best regards Sascha On 02/01/2015 16:14, Steven Hartland wrote: > Since 10 we're had to use the following settings in sysctl for carp to > work as expected: > net.inet.carp.preempt=1 > net.inet.carp.senderr_demotion_factor=0 > > See if these help for your setup too? > > Regards > Steve > > On 02/01/2015 13:38, Sascha wrote: >> Hi and a happy new year to everyone! >> >> I have problems with my carp setup between two Routers/Firewalls >> after upgrade from 10.0 RELEASE to 10.1 RELEASE. >> Before the upgrade my setup worked without any problems! >> >> After the upgrade I checked the carp status. Machine 2 (Backup >> machine) is in Master state for all Interfaces. Machine 1 remains in >> Backup state. Machine 1 is my primary Machine and should be the master! >> >> I restarted both machines several times and checked the rc.conf for >> errors. But Machine 2 gets every time the master. Machine 1 gets >> only the master when I turn off Machine 2. >> All interfaces remain in Master state even when I manually take a >> Interface for example igb4 with ifconfig on Machine 2 down. Then igb4 >> on Machine 1 goes into Master state.But the other interfaces remain >> in Backup state on Machine 1. >> >> preemt Option is set to 1 >> >> The machines are connected with Link Aggregation to the switch and >> they do VLAN Tagging. The CARP Interface is the Gateway for the clients. >> The address on the physical interface is used to bind demons for >> network services. >> PF Sync is done over a cross cable direct attached to both machines. >> PF is not blocking any carp traffic. >> >> >> I Think the problem has something to do with the net.inet.carp.demotion >> >> You can see in my output that machine 1 had this value >> net.inet.carp.demotion: 3840 >> >> Is this a bug or does someone see a configuration error in the config? >> >> >> >> Detailed config(Some output is cleared or omitted): >> >> rc.conf Machine 1: >> >> ################################################################################################################################################################################ >> >> ifconfig_igb0="up" >> ifconfig_igb1="up" >> ifconfig_igb2="up" >> ifconfig_igb3="up" >> ifconfig_igb4="up" >> ifconfig_igb5="up" >> >> ifconfig_igb4="inet xxx.xxx.0.253 netmask 255.255.255.0" >> ifconfig_igb4_alias0="vhid 1 pass secret xxx.xxx.0.1/32" >> >> # PF Sync Interface >> ifconfig_igb5="inet xxx.xxx.255.253/30" >> >> # Create Virutal Interfaces >> cloned_interfaces="lagg0 vlan10 vlan25 vlan35 vlan90 vlan95 vlan97 >> vlan98 vlan99 vlan100 vlan101 vlan102 vlan103 vlan106 vlan107 vlan108 >> vlan109" >> # lagg Interface >> ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 laggport >> igb2 laggport igb3" >> >> # VLAN Interfaces >> ifconfig_vlanxx0="inet xxx.xxxx.xxx.197/27" >> ifconfig_vlanxx0alias0="inet vhid 2 pass secret xxx.xxx.xxx.199/32 >> vlan xx0 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.25.253/24" >> ifconfig_vlanxx5_alias0="inet vhid 3 pass secret xxx.xxx.25.1/32 vlan >> xx5 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.35.253/24" >> ifconfig_vlanxx5_alias0="inet vhid 4 pass secret xxx.35.1/32 vlan xx5 >> vlandev lagg0" >> ifconfig_vlanxx0="inet xxx.xxx.7.253/21" >> ifconfig_vlanxx0_alias0="inet vhid 5 pass secret xxx.xxx.7.1/32 vlan >> xx0 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.95.253/24" >> ifconfig_vlanxx5_alias0="inet vhid 6 pass secret xxx.xxx.95.1/32 vlan >> xx5 vlandev lagg0" >> ifconfig_vlanxx7="inet xxx.xxx.90.253/16" >> ifconfig_vlanxx7_alias0="inet vhid 7 pass secret xxx.xxx.90.6/32 vlan >> xx7 vlandev lagg0" >> ifconfig_vlanxx8="inet xxx.xxx.239.253/21" >> ifconfig_vlanxx8_alias0="inet vhid 8 pass secret xxx.xxx.232.1/32 >> vlan xx8 vlandev lagg0" >> ifconfig_vlanxx9="inet xxx.xxx.0.29/27" >> ifconfig_vlanxx9_alias0="inet vhid 9 pass secret xxx.xxx.0.1/32 vlan >> xx9 vlandev lagg0" >> ifconfig_vlanxx0="inet xxx.xxx.100.253/24" >> ifconfig_vlanxx0_alias0="inet vhid 10 pass secret xxx.xxx.100.1/32 >> vlan xx0 vlandev lagg0" >> ifconfig_vlanxx1="inet xxx.xxx.1.253/24" >> ifconfig_vlanxx1_alias0="inet vhid 11 pass secret xxx.xxx.1.1/32 vlan >> xx1 vlandev lagg0" >> ifconfig_vlanxx2="inet xxx.xxx.116.253/24" >> ifconfig_vlanxx2_alias0="inet vhid 12 pass secret xxx.xxx.116.1/32 >> vlan xx2 vlandev lagg0" >> ifconfig_vlanxx3="inet xxx.xxx.10.253/24" >> ifconfig_vlanxx3_alias0="inet vhid 13 pass secret xxx.xxx.10.1/32 >> vlan xx3 vlandev lagg0" >> ifconfig_vlanxx6="inet xxx.xxx.255.252/16" >> ifconfig_vlanxx6_alias0="inet vhid 14 pass secret xxx.xxx.255.254/32 >> vlan xx6 vlandev lagg0" >> ifconfig_vlanxx7="inet xxx.xxx.90.253/16" >> ifconfig_vlanxx7_alias0="inet vhid 15 pass secret xxx.xxx.90.140/32 >> vlan xx7 vlandev lagg0" >> ifconfig_vlanxx8="inet xxx.xxx.89.12/29" >> ifconfig_vlanxx8_alias0="inet vhid 16 pass secret xxx.xxx.89.14/32 >> vlan xx8 vlandev lagg0" >> ifconfig_vlanxx9="inet xxx.xxx.110.253/24" >> ifconfig_vlanxx9_alias0="inet vhid 17 pass secret xxx.xxx.110.1/32 >> vlan xx9 vlandev lagg0" >> >> igb4: flags=8943 >> metric 0 mtu 1500 >> options=403bb >> >> ether 00:1b:21:96:65:78 >> inet xxx.xxx.0.253 netmask 0xffffff00 broadcast xxx.xxx.0.255 >> inet xxx.xxx.0.1 netmask 0xffffffff broadcast xxx.xxxx.0.1 >> vhid 1 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> carp: BACKUP vhid 1 advbase 1 advskew 0 >> >> vlanxx0: flags=8943 >> metric 0 mtu 1500 >> options=303 >> ether 00:1b:21:96:c0:38 >> inet xxx.xxx.xxx.197 netmask 0xffffffe0 broadcast >> xxx.xxx.xxx.223 >> inet xxx.xxx.xxx.199 netmask 0xffffffff broadcast >> xxx.xxx.xxx.199 vhid 2 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> vlan: 10 parent interface: lagg0 >> carp: BACKUP vhid 2 advbase 1 advskew 0 >> >> >> >> root@xxx1:/# sysctl net.inet.carp >> net.inet.carp.allow: 1 >> net.inet.carp.preempt: 1 >> net.inet.carp.log: 2 >> net.inet.carp.demotion: 3840 >> net.inet.carp.senderr_demotion_factor: 240 >> net.inet.carp.ifdown_demotion_factor: 240 >> >> >> Log File when restarting machine 2 >> >> root@xxx1:/# less /var/log/messages >> >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 15@vlanxx7: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 16@vlanxx8: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 17@vlanxx9: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 1@igb4: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 2@vlanxx0: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 3@vlanxx5: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 4@vlanxx5: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 5@vlanxx0: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 6@vlanxx5: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 7@vlanxx7: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 8@vlanxx8: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 10@vlanxx0: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 9@vlanxx9: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 11@vlanxx1: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 12@vlanxx2: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 13@vlanxx3: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:11 xxx1 kernel: carp: VHID 14@vlanxx6: BACKUP -> MASTER >> (master down) >> Jan 2 12:29:12 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:29:14 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:29:14 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:29:20 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:29:22 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:29:22 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:29:23 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:29:24 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:29:24 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:29:35 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:29:37 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:29:37 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:31:06 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:31:08 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:31:08 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:31:17 xxx1 kernel: igb5: link state changed to DOWN >> Jan 2 12:31:19 xxx1 kernel: igb5: link state changed to UP >> Jan 2 12:31:19 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart >> igb5' >> Jan 2 12:31:21 xxx1 kernel: carp: VHID 1@igb4: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 2@vlanxx0: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 3@vlanxx5: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 5@vlanxx0: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 6@vlanxx5: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 9@vlanxx9: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 8@vlanxx8: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 7@vlanxx7: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 14@vlanxx6: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 10@vlanxx0: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 16@vlanxx8: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 11@vlanxx1: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 12@vlanxx2: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 15@vlanxx7: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 13@vlanxx3: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 17@vlanxx9: MASTER -> BACKUP >> (more frequent advertisement received) >> Jan 2 12:31:52 xxx1 kernel: carp: VHID 4@vlanxx5: MASTER -> BACKUP >> (more frequent advertisement received) >> >> >> TCP Dump on machine 1 during restarting machine 2 >> >> root@xxx1:/# sudo tcpdump -npi igb4 -T carp dst 224.0.0.18 >> >> 13:47:55.455580 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=100 authlen=7 counter=50029484353167172 >> 13:47:56.881428 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=100 authlen=7 counter=50029484353167173 >> 13:47:59.883366 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=240 authlen=7 counter=50029484353167174 >> 13:48:00.894534 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=240 authlen=7 counter=50029484353167175 >> . >> . >> 13:50:07.842383 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=240 authlen=7 counter=50029484353167240 >> 13:50:09.782055 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=240 authlen=7 counter=50029484353167241 >> 13:50:09.782914 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=100 authlen=7 counter=50029484353167242 >> 13:50:11.206767 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=100 authlen=7 counter=50029484353167243 >> 13:50:11.510203 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=240 authlen=7 counter=50029484353167244 >> 13:50:12.450678 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: >> vhid=1 advbase=1 advskew=100 authlen=7 counter=50029484353167245 >> ################################################################################################################################################################################ >> >> >> >> rc.conf Machine 2: >> >> ################################################################################################################################################################################ >> >> ifconfig_igb0="up" >> ifconfig_igb1="up" >> ifconfig_igb2="up" >> ifconfig_igb3="up" >> ifconfig_igb4="up" >> ifconfig_igb5="up" >> >> ifconfig_igb4="inet xxx.xxx.0.254 netmask 255.255.255.0" >> ifconfig_igb4_alias0="vhid 1 advskew 100 pass secret xxx.xxx.0.1/32" >> >> # PF Sync Interface >> ifconfig_igb5="inet 192.168.255.254/30" >> >> # Create Virutal Interfaces >> cloned_interfaces="lagg0 vlan10 vlan25 vlan35 vlan90 vlan95 vlan97 >> vlan98 vlan99 vlan100 vlan101 vlan102 vlan103 vlan106 vlan107 vlan108 >> vlan109" >> # lagg Interface >> ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 laggport >> igb2 laggport igb3" >> >> # VLAN Interfaces >> ifconfig_vlanxx0="inet xxx.xxx.22.198/27" >> ifconfig_vlanxx0_alias0="inet vhid 2 advskew 100 pass secret >> xxx.xxx.22.199/32 vlan 10 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.25.254/24" >> ifconfig_vlanxx5_alias0="inet vhid 3 advskew 100 pass secret >> xxx.xxx.25.1/32 vlan 25 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.35.254/24" >> ifconfig_vlanxx5_alias0="inet vhid 4 advskew 100 pass secret >> xxx.xxx.35.1/32 vlan 35 vlandev lagg0" >> ifconfig_vlanxx0="inet xxx.xxx.7.254/21" >> ifconfig_vlanxx0_alias0="inet vhid 5 advskew 100 pass secret >> xxx.xxx.0.1/32 vlan 90 vlandev lagg0" >> ifconfig_vlanxx5="inet xxx.xxx.95.254/24" >> ifconfig_vlanxx5_alias0="inet vhid 6 advskew 100 pass secret >> xxx.xxx.95.1/32 vlan 95 vlandev lagg0" >> ifconfig_vlanxx7="inet xxx.xxx.90.254/16" >> ifconfig_vlanxx7_alias0="inet vhid 7 advskew 100 pass secret >> xxx.xxx.90.6/32 vlan 97 vlandev lagg0" >> ifconfig_vlanxx8="inet xxx.xxx.239.254/21" >> ifconfig_vlanxx8_alias0="inet vhid 8 advskew 100 pass secret >> xxx.xxx.232.1/32 vlan 98 vlandev lagg0" >> ifconfig_vlanxx9="inet xxx.xxx.0.30/27" >> ifconfig_vlanxx9_alias0="inet vhid 9 advskew 100 pass secret >> xxx.xxx.0.1/32 vlan 99 vlandev lagg0" >> ifconfig_vlanxx0="inet xxx.xxx.100.254/24" >> ifconfig_vlanxx0_alias0="inet vhid 10 advskew 100 pass secret >> xxx.xxx.100.1/32 vlan 100 vlandev lagg0" >> ifconfig_vlanxx1="inet xxx.xxx.1.254/24" >> ifconfig_vlanxx1_alias0="inet vhid 11 advskew 100 pass secret >> xxx.xxx.1.1/32 vlan 101 vlandev lagg0" >> ifconfig_vlanxx2="inet xxx.xxx.116.254/24" >> ifconfig_vlanxx2_alias0="inet vhid 12 advskew 100 pass secret >> xxx.xxx.116.1/32 vlan 102 vlandev lagg0" >> ifconfig_vlanxx3="inet xxx.xxx.10.254/24" >> ifconfig_vlanxx3_alias0="inet vhid 13 advskew 100 pass secret >> xxx.xxx.10.1/32 vlan 103 vlandev lagg0" >> ifconfig_vlanxx6="inet xxx.xxx.255.253/16" >> ifconfig_vlanxx6_alias0="inet vhid 14 advskew 100 pass secret >> xxx.xxx.255.254/32 vlan 106 vlandev lagg0" >> ifconfig_vlanxx7="inet xxx.xxx.90.254/16" >> ifconfig_vlanxx7_alias0="inet vhid 15 advskew 100 pass secret >> xxx.xxx.90.140/32 vlan 107 vlandev lagg0" >> ifconfig_vlanxx8="inet xxx.xxx.89.13/29" >> ifconfig_vlanxx8_alias0="inet vhid 16 advskew 100 pass secret >> xxx.xxx.89.14/32 vlan 108 vlandev lagg0" >> ifconfig_vlanxx9="inet xxx.xxx.110.254/24" >> ifconfig_vlanxx9_alias0="inet vhid 17 advskew 100 pass secret >> xxx.xxx.110.1/32 vlan 109 vlandev lagg0" >> >> >> >> igb4: flags=8943 >> metric 0 mtu 1500 >> options=403bb >> >> ether 00:1b:21:96:66:70 >> inet xxx.xxx.0.254 netmask 0xffffff00 broadcast xxx.xxx.0.255 >> inet xxx.xxx.0.1 netmask 0xffffffff broadcast xxx.xxx.0.1 vhid 1 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> carp: MASTER vhid 1 advbase 1 advskew 100 >> >> vlanxx0: flags=8943 >> metric 0 mtu 1500 >> options=303 >> ether 00:1b:21:96:65:68 >> inet xxx.xxx.xxx.198 netmask 0xffffffe0 broadcast >> xxx.xxx.xxx.223 >> inet xxx.xxx.xxx.199 netmask 0xffffffff broadcast >> xxx.xxx.xxx.199 vhid 2 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> vlan: 10 parent interface: lagg0 >> carp: MASTER vhid 2 advbase 1 advskew 100 >> >> >> >> >> root@xxx2:/# sysctl net.inet.carp >> net.inet.carp.allow: 1 >> net.inet.carp.preempt: 1 >> net.inet.carp.log: 2 >> net.inet.carp.demotion: 720 >> net.inet.carp.senderr_demotion_factor: 240 >> net.inet.carp.ifdown_demotion_factor: 240 >> root@xxx2:/# >> ################################################################################################################################################################################ >> >> _______________________________________________ >> 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 Mon Jan 5 12:19:47 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AF5424E for ; Mon, 5 Jan 2015 12:19:47 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E9C464D37 for ; Mon, 5 Jan 2015 12:19:46 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id l4so17779065lbv.11 for ; Mon, 05 Jan 2015 04:19: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=BiyvOswKDXd7072Wyktz9T8FKwENMisV1f0ChHAg9Pc=; b=J8h1y8UFEc2+2yv9Q8HC9U8SW1u+w0BnKUs1oI3MrLLDCbtTq11B39RJnHlLTF7rEk 62lG5TfRTzU3GQPenBCPV7Y9RtQ16YpA1J5YNZr+HZ/3GcOQFU2q6q6bYTDztsqrec/c wTxKA0Ht3lrtcRtSFi+5eZEuYDgERRo+urEx8oT12mWIOyJTAL1p/cX/Aw6/AePfSocZ 4VLnSQHI1XsYnUD9qgdkNVKAhmGFjTEyatkibCSETRAHNNKLPBQ7DBzkgIFciDOiUKAC UtUHeoIXAt9fqAATd1jUB0QFVQKvz0VcuGzyd/5Q/3JeHuH4klVDVMVwZW/lXs1e+Y4V nt2g== MIME-Version: 1.0 X-Received: by 10.152.19.71 with SMTP id c7mr91830093lae.79.1420460384384; Mon, 05 Jan 2015 04:19:44 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.10.168 with HTTP; Mon, 5 Jan 2015 04:19:44 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Jan 2015 13:19:44 +0100 X-Google-Sender-Auth: Z68FiKdQPw8HVNgNO7PxRIlNuDk Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Luigi Rizzo To: Avinash Sridharan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 12:19:47 -0000 What you see is a virtio issue. virtio prepends a 10 or 12-byte "virtio header" to all packets, which is used to define what sort of NIC accelerations (checksum, tso etc.) are expected on the link. I do not remember if there is a way in qemu-kvm to remove the header. Maybe Vincenzo (in Cc) remembers. cheers luigi On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan < avinash.sridharan@gmail.com> wrote: > I am using netmap with the click modular router, running the click-modular > router in user space. A while back I was using this combination with the > e1000 device driver, with a slightly older netmap code-base. > > Recently I updated my netmap code base and am trying to use the > click-modular router with netmap over a virtio-net device driver (over > KVM). With this combination, though I was able to receive packets I was > unable to interpret any packets coming from the FromDevice element. > > To debug this issue (and to negate any changes I made to the click-modular > router), I ran the pkt-gen application with the "dump payload" option: > > sudo ~/pkt-gen -i eth1 -f rx -X > > This showed that packets are being received correctly from the > netmap-enabled interface, but there are an extra "12" bytes appended to the > packet. > > 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) > > ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] > > 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ << > extra 12 bytes > > 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... > > 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... > > 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... > > 64: 00 00 00 00 bc 9b f6 74 > > > As we can see, the above is an STP BPDU, and there are 12 leading bytes in > the payload. > > > The extra leading bytes screw up the packet interpretation. > > > So is this is an artifact of the virtio-net driver or has something > changed in the netmap device driver? > > > Thanks, > > Avinash > -- -----------------------------------------+------------------------------- 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 Jan 5 16:33:19 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFC9EB57 for ; Mon, 5 Jan 2015 16:33:19 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63B0F2C31 for ; Mon, 5 Jan 2015 16:33:19 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so4471415wib.5 for ; Mon, 05 Jan 2015 08:33:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KYlw8E1C/Uxbc5JIR12e8U3fiofNMYS2cgLOHnCEsqo=; b=LGabfHnGe9E4CK1rjtvQ+OphgK4R0XSTFg/5UmkprGjPxQD/fszdP9o663klMVSZiW c9B2n2dNpcn40hsco3ebr4yW4FSIfZwknQlkfQgRg3bRHriV2aGVNR9EvKWobCaIDqs5 USMHO6HbR5qoaxSWcQjDy6AEnfIjUBrjf3QZ0ekn4/CqPaGhCMg6pzBlbGz+cvKVITu7 WcnGAtVEUKb07oR7MPg/0nSxYayYCclaGEC8E+zYHLMedsbeJr9p6Lpw4NnNNV9/kqPz dH9ZEFGVzg3IedH7qwy/elIUG7bsxY8WsawMQgk+tMwZ65oXTnEJKQasq23mrpEUiJBn LRpw== MIME-Version: 1.0 X-Received: by 10.180.87.36 with SMTP id u4mr27067895wiz.20.1420475597717; Mon, 05 Jan 2015 08:33:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 08:33:17 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Jan 2015 08:33:17 -0800 X-Google-Sender-Auth: Tc1AttoaeTFqVrvhzxg4bDS0SxI Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Avinash Sridharan , Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:33:19 -0000 ... surely virtio should be skipping over those bytes in the netmap rx side before handing them up? (It won't be the only hardware that puts the RX descriptor status in the RX frame itself..) -adrian On 5 January 2015 at 04:19, Luigi Rizzo wrote: > What you see is a virtio issue. > > virtio prepends a 10 or 12-byte "virtio header" > to all packets, which is used to define what sort > of NIC accelerations (checksum, tso etc.) are > expected on the link. > > I do not remember if there is a way in qemu-kvm to > remove the header. Maybe Vincenzo (in Cc) remembers. > > cheers > luigi > > On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan < > avinash.sridharan@gmail.com> wrote: > >> I am using netmap with the click modular router, running the click-modular >> router in user space. A while back I was using this combination with the >> e1000 device driver, with a slightly older netmap code-base. >> >> Recently I updated my netmap code base and am trying to use the >> click-modular router with netmap over a virtio-net device driver (over >> KVM). With this combination, though I was able to receive packets I was >> unable to interpret any packets coming from the FromDevice element. >> >> To debug this issue (and to negate any changes I made to the click-modular >> router), I ran the pkt-gen application with the "dump payload" option: >> >> sudo ~/pkt-gen -i eth1 -f rx -X >> >> This showed that packets are being received correctly from the >> netmap-enabled interface, but there are an extra "12" bytes appended to the >> packet. >> >> 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) >> >> ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] >> >> 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ << >> extra 12 bytes >> >> 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... >> >> 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... >> >> 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... >> >> 64: 00 00 00 00 bc 9b f6 74 >> >> >> As we can see, the above is an STP BPDU, and there are 12 leading bytes in >> the payload. >> >> >> The extra leading bytes screw up the packet interpretation. >> >> >> So is this is an artifact of the virtio-net driver or has something >> changed in the netmap device driver? >> >> >> Thanks, >> >> Avinash >> > > > > -- > -----------------------------------------+------------------------------- > 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" From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 17:00:46 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E803886; Mon, 5 Jan 2015 17:00:46 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF5764028; Mon, 5 Jan 2015 17:00:45 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A74047300A; Mon, 5 Jan 2015 18:05:30 +0100 (CET) Date: Mon, 5 Jan 2015 18:05:30 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: netmap over virtio giving packets with extra 12 bytes Message-ID: <20150105170530.GB22916@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Avinash Sridharan , Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:00:46 -0000 On Mon, Jan 05, 2015 at 08:33:17AM -0800, Adrian Chadd wrote: > ... surely virtio should be skipping over those bytes in the netmap rx > side before handing them up? > > (It won't be the only hardware that puts the RX descriptor status in > the RX frame itself..) it is not the rx descriptor, those 12 bytes are also present on the tx side. Think of them as an encapsulation whose presence is negotiated when KVM connects to the TAP port, and after that is present on all packets bidirectionally. Now, surely we could add/remove those bytes in the virtio-netmap code (at the price of an additional data copy). I need to investigate further. Avinash, could you tell us exactly your configuration -- what is the network backend for QEMU/KVM, and whether you are using virtio in native or emulated netmap mode ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 17:24:40 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18DF7F7A; Mon, 5 Jan 2015 17:24:40 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1B9D3448; Mon, 5 Jan 2015 17:24:39 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id x3so15797211qcv.1; Mon, 05 Jan 2015 09:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tGn0eqXokYQ3VloU40/JdqF4Lqt7MvzUlJ4uJncqFEU=; b=jA2ynq8YglO+2EraRdE03H7SPyacCCUyJyjG3PN7+U1ZpDplnmSfbKLIVF3/76AOQW D93ppUe/8nHwvS6mx463TdWZKIDrUl6F5lC79WXUijex9gOLfQhwc0cY1epLDwLP3tz4 mGu+JauJiCgP2p35N6hQkw2NBo7paZn6EB2kIb6/ggMfMMwqNc+z9JyYgvecUSGvTISH XA/uLKlpjhlPppcqzAbyT5Cg1uLtMs+j6V6SXnzjivSO3yn8Cnh9RiQ4vuW+iCqxNTbH 41x4W9gbgAsY+xx0/NPk2qLJQL7llkB1dQrk5QHvnKqshNo5JdVlWNY65OOGsEWMAF8k RpgA== MIME-Version: 1.0 X-Received: by 10.140.95.71 with SMTP id h65mr75218570qge.92.1420478678950; Mon, 05 Jan 2015 09:24:38 -0800 (PST) Received: by 10.96.76.201 with HTTP; Mon, 5 Jan 2015 09:24:38 -0800 (PST) In-Reply-To: <20150105170530.GB22916@onelab2.iet.unipi.it> References: <20150105170530.GB22916@onelab2.iet.unipi.it> Date: Mon, 5 Jan 2015 09:24:38 -0800 Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Avinash Sridharan To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:24:40 -0000 I used virsh to start the VM over qemu-kvm. Here is a dump of the network XML that was fed to libvirt, while creating the domain:
The network backend is a bridge interface running over gentoo. The bridge has a single port, which is a realtek r8169 NIC. I didn't quite understand the question about using "virtio in native or emulated netmap mode "? While running the above experiment I just replaced the virtio-net drivers with the netmap enabled virtio-net drivers. *asridharan@stitch-dp-1** ~/stitch-click/kernel $* lsmod Module Size Used by virtio_net 24612 0 netmap 95166 1 virtio_net mii 3875 0 *asridharan@stitch-dp-1** ~/stitch-click/kernel $* modinfo ./virtio_net.ko filename: /home/asridharan/stitch-click/kernel/./virtio_net.ko license: GPL description: Virtio network driver alias: virtio:d00000001v* depends: netmap vermagic: 3.14.14-gentoo SMP mod_unload parm: napi_weight:int parm: csum:bool parm: gso:bool *asridharan@stitch-dp-1** ~/stitch-click/kernel $* modinfo ./netmap.ko filename: /home/asridharan/stitch-click/kernel/./netmap.ko license: Dual BSD/GPL description: The netmap packet I/O framework author: http://info.iet.unipi.it/~luigi/netmap/ depends: vermagic: 3.14.14-gentoo SMP mod_unload parm: verbose:int parm: no_timestamp:int parm: mitigate:int parm: no_pendintr:int parm: txsync_retry:int parm: adaptive_io:int parm: flags:int parm: fwd:int parm: mmap_unreg:int parm: admode:int parm: generic_mit:int parm: generic_ringsize:int parm: generic_rings:int parm: default_pipes:int parm: bridge_batch:int parm: if_size:int parm: if_curr_size:int parm: if_num:int parm: if_curr_num:int parm: priv_if_size:int parm: priv_if_num:int parm: ring_size:int parm: ring_curr_size:int parm: ring_num:int parm: ring_curr_num:int parm: priv_ring_size:int parm: priv_ring_num:int parm: buf_size:int parm: buf_curr_size:int parm: buf_num:int parm: buf_curr_num:int parm: priv_buf_size:int parm: priv_buf_num:int Please ping me if I haven't given enough data. Thanks, Avinash On Mon, Jan 5, 2015 at 9:05 AM, Luigi Rizzo wrote: > On Mon, Jan 05, 2015 at 08:33:17AM -0800, Adrian Chadd wrote: > > ... surely virtio should be skipping over those bytes in the netmap rx > > side before handing them up? > > > > (It won't be the only hardware that puts the RX descriptor status in > > the RX frame itself..) > > it is not the rx descriptor, those 12 bytes are also present on the tx > side. > Think of them as an encapsulation whose presence is negotiated when KVM > connects > to the TAP port, and after that is present on all packets bidirectionally. > > Now, surely we could add/remove those bytes in the virtio-netmap code > (at the price of an additional data copy). > > I need to investigate further. > Avinash, could you tell us exactly your configuration -- what is the > network backend for QEMU/KVM, and whether you are using virtio in > native or emulated netmap mode ? > > cheers > luigi > From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 18:00:38 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CB2E2CD for ; Mon, 5 Jan 2015 18:00:38 +0000 (UTC) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC2DE3C0E for ; Mon, 5 Jan 2015 18:00:37 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id f15so20675360lbj.9 for ; Mon, 05 Jan 2015 10:00:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gb/y0hHfxBpfqu4v75V9royPydC/5I8JiPh47Zk9LyA=; b=C2BifWZGXMFGHkrMxh2B0PD9e0XlJJ+6FTzFWREYUfcqsSWE1rSLJYNDu52UX2zhVK zQO8EOT64qCJwdng/w98zT3yFCEABfdaxuSQiOHDQQS8GS2ktfrbFiZK7ZNvHZ/ii/dX O5eUTfTYdVeakN4Vps3si52fJwvpFOhYIuRkFDJxuyI8qvo+heaKVhWCvLzyE7vJZfgR 6X6mnXy7v6nrenYcIURcFm0hRQ5wj12KBmHSj4ucXU97kBFdbpIoZ5RCTo7z75MP5k39 axhmKCBcPWUYCgqXejLLYvgRph28RN1oo/hgiQlPqks2gY1p1IjI2XUKGrjgITakR7f2 A1eQ== X-Gm-Message-State: ALoCoQlGyTCbe7j+tZI9r1GSmSuEwFqI5yEOux0SGbZcGpAkOvkTsTUpNs8ThD0uB4t++7oI1bBh X-Received: by 10.152.87.46 with SMTP id u14mr7393892laz.36.1420480835517; Mon, 05 Jan 2015 10:00:35 -0800 (PST) From: Steven Hartland Mime-Version: 1.0 (1.0) References: <54A69F72.6060405@gmail.com> <54A6B5E3.5090200@multiplay.co.uk> <54AA35DD.8080704@gmail.com> In-Reply-To: <54AA35DD.8080704@gmail.com> Date: Mon, 5 Jan 2015 19:00:33 +0100 Message-ID: <-1236321233328843964@unknownmsgid> Subject: Re: CARP Problem/Bug? on 10.1-RELEASE To: Sascha Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:00:38 -0000 Yes indeed I didn't have time to investigate more > On 5 Jan 2015, at 07:57, Sascha wrote: > > Hi Steven, > > you made my day! It's working again. But I continue my research. > > Rebooting takes the Port-Channel on the switch down. When the machine com= es up the port-channel on the switch needs some seconds until it's up. Duri= ng that time, traffic is not forwarded. Sometimes I could see on the consol= e screen something like "send error 50 on vlan...... demoted by 0 to 720...= " > > After setting "net.inet.carp.senderr_demotion_factor=3D0" I could see st= ill the message. But then the Interface is demoted from 0 to 0. With this s= etting the "net.inet.carp.demotion" remains at 0. When the Port-Channel on = the switch is up packets are forwarded again. Then the designated Backup ma= chine goes back in the Backup state and machine 1 is getting the master aga= in. > > So everything works now like expected! > > I think these new "send error" feature makes some adjustment necessary wh= en using Link Aggregation or when the switch port takes some seconds until = it forwards the traffic (not using spanning-tree portfast feature). > It could be useful when the dev team would release some description how t= he new carp features work together. The manual explains what parameters you= can set. But without understanding whats going on it gets some trial and e= rror. Maybe there is still a description and I didn't find it until now. > > Thanks for the help! > Best regards > Sascha > >> On 02/01/2015 16:14, Steven Hartland wrote: >> Since 10 we're had to use the following settings in sysctl for carp to w= ork as expected: >> net.inet.carp.preempt=3D1 >> net.inet.carp.senderr_demotion_factor=3D0 >> >> See if these help for your setup too? >> >> Regards >> Steve >> >>> On 02/01/2015 13:38, Sascha wrote: >>> Hi and a happy new year to everyone! >>> >>> I have problems with my carp setup between two Routers/Firewalls after = upgrade from 10.0 RELEASE to 10.1 RELEASE. >>> Before the upgrade my setup worked without any problems! >>> >>> After the upgrade I checked the carp status. Machine 2 (Backup machine)= is in Master state for all Interfaces. Machine 1 remains in Backup state. = Machine 1 is my primary Machine and should be the master! >>> >>> I restarted both machines several times and checked the rc.conf for err= ors. But Machine 2 gets every time the master. Machine 1 gets only the mas= ter when I turn off Machine 2. >>> All interfaces remain in Master state even when I manually take a Inter= face for example igb4 with ifconfig on Machine 2 down. Then igb4 on Machine= 1 goes into Master state.But the other interfaces remain in Backup state o= n Machine 1. >>> >>> preemt Option is set to 1 >>> >>> The machines are connected with Link Aggregation to the switch and they= do VLAN Tagging. The CARP Interface is the Gateway for the clients. >>> The address on the physical interface is used to bind demons for networ= k services. >>> PF Sync is done over a cross cable direct attached to both machines. PF= is not blocking any carp traffic. >>> >>> >>> I Think the problem has something to do with the net.inet.carp.demotion >>> >>> You can see in my output that machine 1 had this value net.inet.carp.de= motion: 3840 >>> >>> Is this a bug or does someone see a configuration error in the config? >>> >>> >>> >>> Detailed config(Some output is cleared or omitted): >>> >>> rc.conf Machine 1: >>> >>> #######################################################################= ###########################################################################= ############################## >>> ifconfig_igb0=3D"up" >>> ifconfig_igb1=3D"up" >>> ifconfig_igb2=3D"up" >>> ifconfig_igb3=3D"up" >>> ifconfig_igb4=3D"up" >>> ifconfig_igb5=3D"up" >>> >>> ifconfig_igb4=3D"inet xxx.xxx.0.253 netmask 255.255.255.0" >>> ifconfig_igb4_alias0=3D"vhid 1 pass secret xxx.xxx.0.1/32" >>> >>> # PF Sync Interface >>> ifconfig_igb5=3D"inet xxx.xxx.255.253/30" >>> >>> # Create Virutal Interfaces >>> cloned_interfaces=3D"lagg0 vlan10 vlan25 vlan35 vlan90 vlan95 vlan97 vl= an98 vlan99 vlan100 vlan101 vlan102 vlan103 vlan106 vlan107 vlan108 vlan109= " >>> # lagg Interface >>> ifconfig_lagg0=3D"laggproto lacp laggport igb0 laggport igb1 laggport i= gb2 laggport igb3" >>> >>> # VLAN Interfaces >>> ifconfig_vlanxx0=3D"inet xxx.xxxx.xxx.197/27" >>> ifconfig_vlanxx0alias0=3D"inet vhid 2 pass secret xxx.xxx.xxx.199/32 vl= an xx0 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.25.253/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 3 pass secret xxx.xxx.25.1/32 vlan= xx5 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.35.253/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 4 pass secret xxx.35.1/32 vlan xx5= vlandev lagg0" >>> ifconfig_vlanxx0=3D"inet xxx.xxx.7.253/21" >>> ifconfig_vlanxx0_alias0=3D"inet vhid 5 pass secret xxx.xxx.7.1/32 vlan = xx0 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.95.253/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 6 pass secret xxx.xxx.95.1/32 vlan= xx5 vlandev lagg0" >>> ifconfig_vlanxx7=3D"inet xxx.xxx.90.253/16" >>> ifconfig_vlanxx7_alias0=3D"inet vhid 7 pass secret xxx.xxx.90.6/32 vlan= xx7 vlandev lagg0" >>> ifconfig_vlanxx8=3D"inet xxx.xxx.239.253/21" >>> ifconfig_vlanxx8_alias0=3D"inet vhid 8 pass secret xxx.xxx.232.1/32 vla= n xx8 vlandev lagg0" >>> ifconfig_vlanxx9=3D"inet xxx.xxx.0.29/27" >>> ifconfig_vlanxx9_alias0=3D"inet vhid 9 pass secret xxx.xxx.0.1/32 vlan = xx9 vlandev lagg0" >>> ifconfig_vlanxx0=3D"inet xxx.xxx.100.253/24" >>> ifconfig_vlanxx0_alias0=3D"inet vhid 10 pass secret xxx.xxx.100.1/32 vl= an xx0 vlandev lagg0" >>> ifconfig_vlanxx1=3D"inet xxx.xxx.1.253/24" >>> ifconfig_vlanxx1_alias0=3D"inet vhid 11 pass secret xxx.xxx.1.1/32 vlan= xx1 vlandev lagg0" >>> ifconfig_vlanxx2=3D"inet xxx.xxx.116.253/24" >>> ifconfig_vlanxx2_alias0=3D"inet vhid 12 pass secret xxx.xxx.116.1/32 vl= an xx2 vlandev lagg0" >>> ifconfig_vlanxx3=3D"inet xxx.xxx.10.253/24" >>> ifconfig_vlanxx3_alias0=3D"inet vhid 13 pass secret xxx.xxx.10.1/32 vla= n xx3 vlandev lagg0" >>> ifconfig_vlanxx6=3D"inet xxx.xxx.255.252/16" >>> ifconfig_vlanxx6_alias0=3D"inet vhid 14 pass secret xxx.xxx.255.254/32 = vlan xx6 vlandev lagg0" >>> ifconfig_vlanxx7=3D"inet xxx.xxx.90.253/16" >>> ifconfig_vlanxx7_alias0=3D"inet vhid 15 pass secret xxx.xxx.90.140/32 v= lan xx7 vlandev lagg0" >>> ifconfig_vlanxx8=3D"inet xxx.xxx.89.12/29" >>> ifconfig_vlanxx8_alias0=3D"inet vhid 16 pass secret xxx.xxx.89.14/32 vl= an xx8 vlandev lagg0" >>> ifconfig_vlanxx9=3D"inet xxx.xxx.110.253/24" >>> ifconfig_vlanxx9_alias0=3D"inet vhid 17 pass secret xxx.xxx.110.1/32 vl= an xx9 vlandev lagg0" >>> >>> igb4: flags=3D8943 metr= ic 0 mtu 1500 >>> options=3D403bb >>> ether 00:1b:21:96:65:78 >>> inet xxx.xxx.0.253 netmask 0xffffff00 broadcast xxx.xxx.0.255 >>> inet xxx.xxx.0.1 netmask 0xffffffff broadcast xxx.xxxx.0.1 vhid = 1 >>> nd6 options=3D29 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> carp: BACKUP vhid 1 advbase 1 advskew 0 >>> >>> vlanxx0: flags=3D8943 m= etric 0 mtu 1500 >>> options=3D303 >>> ether 00:1b:21:96:c0:38 >>> inet xxx.xxx.xxx.197 netmask 0xffffffe0 broadcast xxx.xxx.xxx.22= 3 >>> inet xxx.xxx.xxx.199 netmask 0xffffffff broadcast xxx.xxx.xxx.19= 9 vhid 2 >>> nd6 options=3D29 >>> media: Ethernet autoselect >>> status: active >>> vlan: 10 parent interface: lagg0 >>> carp: BACKUP vhid 2 advbase 1 advskew 0 >>> >>> >>> >>> root@xxx1:/# sysctl net.inet.carp >>> net.inet.carp.allow: 1 >>> net.inet.carp.preempt: 1 >>> net.inet.carp.log: 2 >>> net.inet.carp.demotion: 3840 >>> net.inet.carp.senderr_demotion_factor: 240 >>> net.inet.carp.ifdown_demotion_factor: 240 >>> >>> >>> Log File when restarting machine 2 >>> >>> root@xxx1:/# less /var/log/messages >>> >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 15@vlanxx7: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 16@vlanxx8: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 17@vlanxx9: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 1@igb4: BACKUP -> MASTER (maste= r down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 2@vlanxx0: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 3@vlanxx5: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 4@vlanxx5: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 5@vlanxx0: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 6@vlanxx5: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 7@vlanxx7: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 8@vlanxx8: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 10@vlanxx0: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 9@vlanxx9: BACKUP -> MASTER (ma= ster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 11@vlanxx1: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 12@vlanxx2: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 13@vlanxx3: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:11 xxx1 kernel: carp: VHID 14@vlanxx6: BACKUP -> MASTER (m= aster down) >>> Jan 2 12:29:12 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:29:14 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:29:14 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:29:20 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:29:22 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:29:22 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:29:23 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:29:24 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:29:24 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:29:35 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:29:37 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:29:37 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:31:06 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:31:08 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:31:08 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:31:17 xxx1 kernel: igb5: link state changed to DOWN >>> Jan 2 12:31:19 xxx1 kernel: igb5: link state changed to UP >>> Jan 2 12:31:19 xxx1 devd: Executing '/etc/rc.d/dhclient quietstart igb= 5' >>> Jan 2 12:31:21 xxx1 kernel: carp: VHID 1@igb4: MASTER -> BACKUP (more = frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 2@vlanxx0: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 3@vlanxx5: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 5@vlanxx0: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 6@vlanxx5: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 9@vlanxx9: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 8@vlanxx8: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 7@vlanxx7: MASTER -> BACKUP (mo= re frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 14@vlanxx6: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 10@vlanxx0: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 16@vlanxx8: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 11@vlanxx1: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 12@vlanxx2: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 15@vlanxx7: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 13@vlanxx3: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 17@vlanxx9: MASTER -> BACKUP (m= ore frequent advertisement received) >>> Jan 2 12:31:52 xxx1 kernel: carp: VHID 4@vlanxx5: MASTER -> BACKUP (mo= re frequent advertisement received) >>> >>> >>> TCP Dump on machine 1 during restarting machine 2 >>> >>> root@xxx1:/# sudo tcpdump -npi igb4 -T carp dst 224.0.0.18 >>> >>> 13:47:55.455580 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D100 authlen=3D7 counter=3D50029484353167172 >>> 13:47:56.881428 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D100 authlen=3D7 counter=3D50029484353167173 >>> 13:47:59.883366 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D240 authlen=3D7 counter=3D50029484353167174 >>> 13:48:00.894534 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D240 authlen=3D7 counter=3D50029484353167175 >>> . >>> . >>> 13:50:07.842383 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D240 authlen=3D7 counter=3D50029484353167240 >>> 13:50:09.782055 IP xxx.xxx.0.253 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D240 authlen=3D7 counter=3D50029484353167241 >>> 13:50:09.782914 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D100 authlen=3D7 counter=3D50029484353167242 >>> 13:50:11.206767 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D100 authlen=3D7 counter=3D50029484353167243 >>> 13:50:11.510203 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D240 authlen=3D7 counter=3D50029484353167244 >>> 13:50:12.450678 IP xxx.xxx.0.254 > 224.0.0.18: CARPv2-advertise 36: vhi= d=3D1 advbase=3D1 advskew=3D100 authlen=3D7 counter=3D50029484353167245 >>> #######################################################################= ###########################################################################= ############################## >>> >>> >>> rc.conf Machine 2: >>> >>> #######################################################################= ###########################################################################= ############################## >>> ifconfig_igb0=3D"up" >>> ifconfig_igb1=3D"up" >>> ifconfig_igb2=3D"up" >>> ifconfig_igb3=3D"up" >>> ifconfig_igb4=3D"up" >>> ifconfig_igb5=3D"up" >>> >>> ifconfig_igb4=3D"inet xxx.xxx.0.254 netmask 255.255.255.0" >>> ifconfig_igb4_alias0=3D"vhid 1 advskew 100 pass secret xxx.xxx.0.1/32" >>> >>> # PF Sync Interface >>> ifconfig_igb5=3D"inet 192.168.255.254/30" >>> >>> # Create Virutal Interfaces >>> cloned_interfaces=3D"lagg0 vlan10 vlan25 vlan35 vlan90 vlan95 vlan97 vl= an98 vlan99 vlan100 vlan101 vlan102 vlan103 vlan106 vlan107 vlan108 vlan109= " >>> # lagg Interface >>> ifconfig_lagg0=3D"laggproto lacp laggport igb0 laggport igb1 laggport i= gb2 laggport igb3" >>> >>> # VLAN Interfaces >>> ifconfig_vlanxx0=3D"inet xxx.xxx.22.198/27" >>> ifconfig_vlanxx0_alias0=3D"inet vhid 2 advskew 100 pass secret xxx.xxx.= 22.199/32 vlan 10 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.25.254/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 3 advskew 100 pass secret xxx.xxx.= 25.1/32 vlan 25 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.35.254/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 4 advskew 100 pass secret xxx.xxx.= 35.1/32 vlan 35 vlandev lagg0" >>> ifconfig_vlanxx0=3D"inet xxx.xxx.7.254/21" >>> ifconfig_vlanxx0_alias0=3D"inet vhid 5 advskew 100 pass secret xxx.xxx.= 0.1/32 vlan 90 vlandev lagg0" >>> ifconfig_vlanxx5=3D"inet xxx.xxx.95.254/24" >>> ifconfig_vlanxx5_alias0=3D"inet vhid 6 advskew 100 pass secret xxx.xxx.= 95.1/32 vlan 95 vlandev lagg0" >>> ifconfig_vlanxx7=3D"inet xxx.xxx.90.254/16" >>> ifconfig_vlanxx7_alias0=3D"inet vhid 7 advskew 100 pass secret xxx.xxx.= 90.6/32 vlan 97 vlandev lagg0" >>> ifconfig_vlanxx8=3D"inet xxx.xxx.239.254/21" >>> ifconfig_vlanxx8_alias0=3D"inet vhid 8 advskew 100 pass secret xxx.xxx.= 232.1/32 vlan 98 vlandev lagg0" >>> ifconfig_vlanxx9=3D"inet xxx.xxx.0.30/27" >>> ifconfig_vlanxx9_alias0=3D"inet vhid 9 advskew 100 pass secret xxx.xxx.= 0.1/32 vlan 99 vlandev lagg0" >>> ifconfig_vlanxx0=3D"inet xxx.xxx.100.254/24" >>> ifconfig_vlanxx0_alias0=3D"inet vhid 10 advskew 100 pass secret xxx.xxx= .100.1/32 vlan 100 vlandev lagg0" >>> ifconfig_vlanxx1=3D"inet xxx.xxx.1.254/24" >>> ifconfig_vlanxx1_alias0=3D"inet vhid 11 advskew 100 pass secret xxx.xxx= .1.1/32 vlan 101 vlandev lagg0" >>> ifconfig_vlanxx2=3D"inet xxx.xxx.116.254/24" >>> ifconfig_vlanxx2_alias0=3D"inet vhid 12 advskew 100 pass secret xxx.xxx= .116.1/32 vlan 102 vlandev lagg0" >>> ifconfig_vlanxx3=3D"inet xxx.xxx.10.254/24" >>> ifconfig_vlanxx3_alias0=3D"inet vhid 13 advskew 100 pass secret xxx.xxx= .10.1/32 vlan 103 vlandev lagg0" >>> ifconfig_vlanxx6=3D"inet xxx.xxx.255.253/16" >>> ifconfig_vlanxx6_alias0=3D"inet vhid 14 advskew 100 pass secret xxx.xxx= .255.254/32 vlan 106 vlandev lagg0" >>> ifconfig_vlanxx7=3D"inet xxx.xxx.90.254/16" >>> ifconfig_vlanxx7_alias0=3D"inet vhid 15 advskew 100 pass secret xxx.xxx= .90.140/32 vlan 107 vlandev lagg0" >>> ifconfig_vlanxx8=3D"inet xxx.xxx.89.13/29" >>> ifconfig_vlanxx8_alias0=3D"inet vhid 16 advskew 100 pass secret xxx.xxx= .89.14/32 vlan 108 vlandev lagg0" >>> ifconfig_vlanxx9=3D"inet xxx.xxx.110.254/24" >>> ifconfig_vlanxx9_alias0=3D"inet vhid 17 advskew 100 pass secret xxx.xxx= .110.1/32 vlan 109 vlandev lagg0" >>> >>> >>> >>> igb4: flags=3D8943 metr= ic 0 mtu 1500 >>> options=3D403bb >>> ether 00:1b:21:96:66:70 >>> inet xxx.xxx.0.254 netmask 0xffffff00 broadcast xxx.xxx.0.255 >>> inet xxx.xxx.0.1 netmask 0xffffffff broadcast xxx.xxx.0.1 vhid 1 >>> nd6 options=3D29 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> carp: MASTER vhid 1 advbase 1 advskew 100 >>> >>> vlanxx0: flags=3D8943 m= etric 0 mtu 1500 >>> options=3D303 >>> ether 00:1b:21:96:65:68 >>> inet xxx.xxx.xxx.198 netmask 0xffffffe0 broadcast xxx.xxx.xxx.22= 3 >>> inet xxx.xxx.xxx.199 netmask 0xffffffff broadcast xxx.xxx.xxx.19= 9 vhid 2 >>> nd6 options=3D29 >>> media: Ethernet autoselect >>> status: active >>> vlan: 10 parent interface: lagg0 >>> carp: MASTER vhid 2 advbase 1 advskew 100 >>> >>> >>> >>> >>> root@xxx2:/# sysctl net.inet.carp >>> net.inet.carp.allow: 1 >>> net.inet.carp.preempt: 1 >>> net.inet.carp.log: 2 >>> net.inet.carp.demotion: 720 >>> net.inet.carp.senderr_demotion_factor: 240 >>> net.inet.carp.ifdown_demotion_factor: 240 >>> root@xxx2:/# >>> #######################################################################= ###########################################################################= ############################## >>> _______________________________________________ >>> 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 Mon Jan 5 20:39:00 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A64C17D9 for ; Mon, 5 Jan 2015 20:39:00 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3767528DD for ; Mon, 5 Jan 2015 20:39:00 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so8648200wes.18 for ; Mon, 05 Jan 2015 12:38:58 -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=USaaifkoB9t9PMo9PpwRN6W+0Px+0HF/kOUYUtaM5pw=; b=wICUekXT0Ha46vBRH2/VMdsOgad6eztZ1CIjAK/OIxWABHpDPIWNtf+1lyd3ZXvcm0 NJbG5BJhhn3g05NCOXB8bZq99aQXsD9Vl8QWPmTa438dN1jK3/bYSC3IrrozoyLmnftd ykJ2hdM3pIbCB9eGKSLWeq/000xFyXillZUf2NGRdSM2BPuDKqIXMD0ZTA5g4xNQdcAv EdcIKzdkca8cape2j46LWNhqnszGMBzxbBq7ImNVTUoy9dFu80rf/IAAxHUuJhEXzm2Q nHavqzyF1IBfytK06Ztf3NbTyNpAXS6X3DDaf5CFnQ8I5L5yUuGz0Nn01bmib2QWyo+G EUCg== MIME-Version: 1.0 X-Received: by 10.180.87.36 with SMTP id u4mr29135301wiz.20.1420490338640; Mon, 05 Jan 2015 12:38:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 12:38:58 -0800 (PST) In-Reply-To: <20150105170530.GB22916@onelab2.iet.unipi.it> References: <20150105170530.GB22916@onelab2.iet.unipi.it> Date: Mon, 5 Jan 2015 12:38:58 -0800 X-Google-Sender-Auth: 0VHPIlplfMvOlCd4kO-GJ4x9ZLw Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Avinash Sridharan , Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:39:00 -0000 On 5 January 2015 at 09:05, Luigi Rizzo wrote: > On Mon, Jan 05, 2015 at 08:33:17AM -0800, Adrian Chadd wrote: >> ... surely virtio should be skipping over those bytes in the netmap rx >> side before handing them up? >> >> (It won't be the only hardware that puts the RX descriptor status in >> the RX frame itself..) > > it is not the rx descriptor, those 12 bytes are also present on the tx side. > Think of them as an encapsulation whose presence is negotiated when KVM connects > to the TAP port, and after that is present on all packets bidirectionally. > > Now, surely we could add/remove those bytes in the virtio-netmap code > (at the price of an additional data copy). Right, but I have similar issues with other wifi devices who put RX descriptor completion info in the header of the mbuf you pass to the NIC. So in the driver RX path, I have to += the data pointer /past/ the header. So, maybe for netmap you need to consider adding something that lets you specify how many bytes into the RX buffer the payload starts. -adrian From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 21:53:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EACE042C for ; Mon, 5 Jan 2015 21:53:51 +0000 (UTC) Received: from mail.premiumlistz.com (premiumlistz.com [182.71.240.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5993C3653 for ; Mon, 5 Jan 2015 21:53:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.premiumlistz.com (Postfix) with ESMTP id 161ED9811FD for ; Tue, 6 Jan 2015 03:22:15 +0530 (IST) Received: from mail.premiumlistz.com ([127.0.0.1]) by localhost (mail.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HJEsmzjHU00 for ; Tue, 6 Jan 2015 03:22:15 +0530 (IST) Received: from WSC48 (unknown [125.99.254.7]) by mail.premiumlistz.com (Postfix) with ESMTPA id 040789811EA for ; Tue, 6 Jan 2015 03:22:13 +0530 (IST) From: "Harriet Jones" To: Subject: Label and Packaging Date: Mon, 5 Jan 2015 13:43:25 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdApMKKvLqVLaZPbQTijhz/qC8TXcg== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:53:52 -0000 Hello , Would you be interested in acquiring contacts from Label & Package Printing Industry Lists 2015? which includes complete verified email addresses of - All Key Decision makers List, All C-level executives List of - Manufacturers, Packaging Professionals, Food & Beverages Manufacturers, Web printing Companies, Overprinting & Inspection Professionals, Pre-press, Radio frequency Professionals, Security Managers, Industrial Production Managers, Food Batch makers, Book/Magazines Publishers, Equipment Manufacturers, Foil Manufacturers, Rubber & Plastic Manufacturers, Graphic Designers, Supply & logistics Managers, Product development managers, Buyers, Suppliers, Importers/Exporters and many more! across US/UK/Global. Our List Includes : Label printers/converters Flexible packaging printers/converters Folding carton printers/converters Packaging printers/converters General printers/converters Brand owners Label designers Industry suppliers and many more.. If your target audience is not mentioned above, kindly let me know. Kindly confirm your exact target audience (Geographic Location / Business Vertical / Job Titles) so that we can send you few sample records for your internal review. Looking forward to connect with you! Thanks, Harriet Jones | Inside Sales We are expertise in:- B2B and B2C Email List, Email Appending, Reverse Appending, Email Campaign, Data Appending, Fax Appending, Phone Appending Services. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 00:16:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA443ACC for ; Tue, 6 Jan 2015 00:16:45 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 241A52BBF for ; Tue, 6 Jan 2015 00:16:45 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id q1so19581916lam.33 for ; Mon, 05 Jan 2015 16:16:41 -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=8tJZOy4UvP9qUYM8H3jkk7BCfRvBTL70RWMbMZ64S6g=; b=tYOyI3+udjTlVHOhOPiVWX0OAt/QF92UxhhegfE+cKMAnvrvKzhZ35xqjp1GRdhPsA 3QYeZnAM2Qe8JUGHDdpSPWf9SfHTjlli/nqCWsCyyqSlU24Ey1db0kAZgrAag3UhaNKw 7uWlID7bxltG5eIKWy6o6gE0kM+JYf/YS2bdXpvTm8auExkWkNo3pnc9A1sVSN0yKVYa vJX5nBzOsas3+5RkFvu2OUw4bJkT0Qx8vDSGWY2/8PwSRaxfhFa9Ad65jyl5zNcVSa5M PibSfEinvTxT8uz505tCuD6575cAns1cfGAvNJivH+V3W8ZLFjUFCDyrMGjW7jZrdpOD EODA== X-Received: by 10.112.180.135 with SMTP id do7mr54028072lbc.23.1420503401749; Mon, 05 Jan 2015 16:16:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.36.215 with HTTP; Mon, 5 Jan 2015 16:16:01 -0800 (PST) In-Reply-To: References: From: Carlos Ferreira Date: Tue, 6 Jan 2015 00:16:01 +0000 Message-ID: Subject: Re: Regarding Netmap internal memory allocation. To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 00:16:46 -0000 First of all, Happy New Year :) Now, to more serious developments.. I was unable to reduce the netmap memory usage by manipulating the buf_num value. The lowest I could get was around the 20MB which is still high. I'm going to change the strategy and try to directly mmap the RX and TX buffers from the interface sockets. The results are going to be worse and I know that I'm not going to have Zero-Copy capability between interfaces but... oh well, I guess at least I'm going to be able to do something better than basic layer 2 sockets. Thank you for the info regarding netmap. On 30 December 2014 at 18:55, Carlos Ferreira wrote: > Well... due to budget constraints I'm using USB 100Mb ports :) > This is for experimental purposes only for now. > > Btw, can netmap work with wireless interfaces? I believe you once answered > this question, but I could not find it in the mail list. > > On 30 December 2014 at 18:40, Luigi Rizzo wrote: > >> On Tue, Dec 30, 2014 at 6:38 PM, Carlos Ferreira >> wrote: >> > Ok, I'm having some trouble in tuning the amount of memory for netmap. >> > >> > I have been following the man page from FreeBSD in other to understand >> the >> > values at /sys/modules/netmap/parameters for linux but I'm having some >> > trouble in understanding what each value actually means. >> > For the following values: >> > >> > dev.netmap.ring_num: 200 -> Is this the number of rings in the Ring >> Buffer >> > Pool? >> >> yes. For interfaces with a single queue you need 4 rings (rx+tx for the >> nic and >> another rx+tx for the host port) >> >> > dev.netmap.ring_size: 36864 -> Is this value, the number of slots per >> ring? >> >> this is the size in bytes of each ring. The number of slots is set by the >> hardware (low end devices as in the openwrt devices will probably use >> 256 or 512 slots, so 10-12k should suffice. But this is not worth >> changing. >> >> Instead, you should reduce the number of buffers, though 8MB is only 4000 >> buffers and it is a bit on the low side for 5 ports. >> >> However, as far as I know most openwrt devices only have one physical NIC, >> and a switch implementing various vlans. >> >> cheers >> luigi >> >> > >> > I'm trying to keep the amount of memory used by netmap as low as 4MB - >> 8MB >> > since I'm going to use only up to 4 NICs and one TAP. >> > >> > Thanks for the help! >> > >> > >> > On 30 December 2014 at 16:16, Luigi Rizzo wrote: >> >> >> >> you can #undefine WITH_VALE. >> >> But it is only 20K of code (and 150K of data structures, which you >> >> can further reduce by lowering NM_BRIDGS). >> >> The saving is probably not worth the effort. >> >> >> >> cheers >> >> luigi >> >> >> >> On Tue, Dec 30, 2014 at 5:08 PM, Carlos Ferreira < >> carlosmf.pt@gmail.com> >> >> wrote: >> >> > By the way, another question. >> >> > Is there a way to not compile the code regarding the VALE switch? I'm >> >> > only >> >> > interested in using netmap with Tap Devices and NICs, so I was >> hoping to >> >> > save some memory. >> >> > >> >> > On 30 December 2014 at 15:47, Carlos Ferreira > > >> >> > wrote: >> >> >> >> >> >> You mean netmap_mem2.c ? It was there where I found the >> >> >> NETMAP_BUF_MAX_NUM >> >> >> define. >> >> >> >> >> >> >> >> >> >> >> >> On 30 December 2014 at 15:43, Carlos Ferreira < >> carlosmf.pt@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> Ok thanks. I was hoping not having to recompile the module, but >> it's >> >> >>> ok. >> >> >>> Thank you for the info! >> >> >>> >> >> >>> >> >> >>> On 30 December 2014 at 15:38, Luigi Rizzo >> wrote: >> >> >>>> >> >> >>>> you can reduce the amount of ram (buffers, mostly) by >> >> >>>> tweaking the values in netmap_mem2.c :: >> >> >>>> struct netmap_obj_params netmap_params[NETMAP_POOLS_NR] = { >> >> >>>> ... >> >> >>>> } >> >> >>>> >> >> >>>> or you can simply modify the constant >> >> >>>> >> >> >>>> netmap_mem2.h:#define NETMAP_BUF_MAX_NUM 20*4096*2 >> >> >>>> >> >> >>>> to something smaller that suits an openwrt box >> >> >>>> (in which i am very interested, as I'd like to deploy one of these >> >> >>>> soon) >> >> >>>> >> >> >>>> cheers >> >> >>>> luigi >> >> >>>> >> >> >>>> >> >> >>>> On Tue, Dec 30, 2014 at 4:12 PM, Carlos Ferreira >> >> >>>> >> >> >>>> wrote: >> >> >>>> > Update: >> >> >>>> > >> >> >>>> > I noticed that the netmap module was still crashing, after >> >> >>>> > changing >> >> >>>> > the >> >> >>>> > OpenWRT VM ram to 256MB. I now raised to 1GB and it no longer >> >> >>>> > crashed. >> >> >>>> > The >> >> >>>> > netmap module is now consuming about 350MB of Ram, which for my >> >> >>>> > objectives >> >> >>>> > is just too much... >> >> >>>> > >> >> >>>> > On 30 December 2014 at 14:06, Carlos Ferreira >> >> >>>> > >> >> >>>> > wrote: >> >> >>>> > >> >> >>>> >> To Luigi and to whom may be able to help >> >> >>>> >> >> >> >>>> >> Hello all. >> >> >>>> >> >> >> >>>> >> Is it possible to reduce the size of the memory buffer >> allocated >> >> >>>> >> by >> >> >>>> >> the >> >> >>>> >> netmap module? >> >> >>>> >> I'm asking this because I was implementing some testing code, >> >> >>>> >> using >> >> >>>> >> NICs >> >> >>>> >> and a Tap device in an OpenWRT VM with 64MB of RAM. >> >> >>>> >> Because of the small RAM amount, the nm_open crashed when the >> >> >>>> >> program >> >> >>>> >> tried to netmap the tap device, after I previously netmapped >> one >> >> >>>> >> NIC >> >> >>>> >> successfully. >> >> >>>> >> After the crash, I bumped the VM RAM to 256MB and the test >> program >> >> >>>> >> ran >> >> >>>> >> well, but not without me noticing that the VM RAM consumption >> was >> >> >>>> >> increased about 90 MB by netmap. >> >> >>>> >> >> >> >>>> >> Resuming, I want to know if there is a way to reduce the memory >> >> >>>> >> buffer >> >> >>>> >> allocation, without recompiling the netmap kernel module. >> >> >>>> >> >> >> >>>> >> Thank you for the attention. >> >> >>>> >> >> >> >>>> >> -- >> >> >>>> >> >> >> >>>> >> Carlos Miguel Ferreira >> >> >>>> >> Researcher at Telecommunications Institute >> >> >>>> >> Aveiro - Portugal >> >> >>>> >> Work E-mail - cmf@av.it.pt >> >> >>>> >> Skype & GTalk -> carlosmf.pt@gmail.com >> >> >>>> >> LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> >>>> >> >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > -- >> >> >>>> > >> >> >>>> > Carlos Miguel Ferreira >> >> >>>> > Researcher at Telecommunications Institute >> >> >>>> > Aveiro - Portugal >> >> >>>> > Work E-mail - cmf@av.it.pt >> >> >>>> > Skype & GTalk -> carlosmf.pt@gmail.com >> >> >>>> > LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> >>>> > _______________________________________________ >> >> >>>> > 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) >> >> >>>> >> >> >>>> >> >> >>>> >> -----------------------------------------+------------------------------- >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> >> >> >>> Carlos Miguel Ferreira >> >> >>> Researcher at Telecommunications Institute >> >> >>> Aveiro - Portugal >> >> >>> Work E-mail - cmf@av.it.pt >> >> >>> Skype & GTalk -> carlosmf.pt@gmail.com >> >> >>> LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Carlos Miguel Ferreira >> >> >> Researcher at Telecommunications Institute >> >> >> Aveiro - Portugal >> >> >> Work E-mail - cmf@av.it.pt >> >> >> Skype & GTalk -> carlosmf.pt@gmail.com >> >> >> LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > Carlos Miguel Ferreira >> >> > Researcher at Telecommunications Institute >> >> > Aveiro - Portugal >> >> > Work E-mail - cmf@av.it.pt >> >> > Skype & GTalk -> carlosmf.pt@gmail.com >> >> > LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> >> >> >> >> >> >> -- >> >> >> -----------------------------------------+------------------------------- >> >> 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) >> >> >> -----------------------------------------+------------------------------- >> > >> > >> > >> > >> > -- >> > >> > Carlos Miguel Ferreira >> > Researcher at Telecommunications Institute >> > Aveiro - Portugal >> > Work E-mail - cmf@av.it.pt >> > Skype & GTalk -> carlosmf.pt@gmail.com >> > LinkedIn -> http://www.linkedin.com/in/carlosmferreira >> >> >> >> -- >> -----------------------------------------+------------------------------- >> 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) >> -----------------------------------------+------------------------------- >> > > > > -- > > Carlos Miguel Ferreira > Researcher at Telecommunications Institute > Aveiro - Portugal > Work E-mail - cmf@av.it.pt > Skype & GTalk -> carlosmf.pt@gmail.com > LinkedIn -> http://www.linkedin.com/in/carlosmferreira > -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 01:39:14 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16D01EB for ; Tue, 6 Jan 2015 01:39:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F141E6461E for ; Tue, 6 Jan 2015 01:39:13 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t061dDho088899 for ; Tue, 6 Jan 2015 01:39:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Tue, 06 Jan 2015 01:39:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc product component assigned_to version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:39:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Intel 82573 nic built on my |[em] Intel 82573 nic built |pdsbm-ln2 1U server and |on my pdsbm-ln2 1U server |only one port will work. |and only one port will | |work. Product|Ports & Packages |Base System Component|Individual Port(s) |kern Assignee|freebsd-ports-bugs@FreeBSD. |freebsd-net@FreeBSD.org |org | Version|Latest |10.1-RELEASE --- Comment #2 from Mark Linimon --- reclassify. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:00:25 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD52C569 for ; Tue, 6 Jan 2015 08:00:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4277644FB for ; Tue, 6 Jan 2015 08:00:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0680Pe5070619 for ; Tue, 6 Jan 2015 08:00:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191468] [vimage] options VIMAGE + Infiniband - kernel panic, crashes during system boot Date: Tue, 06 Jan 2015 08:00:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:00:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191468 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: rodrigc Date: Tue Jan 6 07:59:51 UTC 2015 New revision: 276744 URL: https://svnweb.freebsd.org/changeset/base/276744 Log: Merge r275599: Use CURVNET macros inside inet_get_local_port_range() function. Without this fix, a kernel with VIMAGE + Infiniband will panic on bootup. Certain necessary #include statements require LIST_HEAD. Add these includes to ofed/include/linux/list.h, because LIST_HEAD is specifically overridden in this file. PR: 191468 Differential Revision: D1279 Reviewed by: hselasky Changes: _U stable/10/ stable/10/sys/ofed/include/linux/list.h stable/10/sys/ofed/include/net/ip.h -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:03:28 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB71C75A for ; Tue, 6 Jan 2015 08:03:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1DB9645F8 for ; Tue, 6 Jan 2015 08:03:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0683S4i001925 for ; Tue, 6 Jan 2015 08:03:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191468] [vimage] options VIMAGE + Infiniband - kernel panic, crashes during system boot Date: Tue, 06 Jan 2015 08:03:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:03:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191468 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: rodrigc Date: Tue Jan 6 08:03:03 UTC 2015 New revision: 276745 URL: https://svnweb.freebsd.org/changeset/base/276745 Log: Merge r276744: Use CURVNET macros inside inet_get_local_port_range() function. Without this fix, a kernel with VIMAGE + Infiniband will panic on bootup. Certain necessary #include statements require LIST_HEAD. Add these includes to ofed/include/linux/list.h, because LIST_HEAD is specifically overridden in this file. PR: 191468 Differential Revision: D1279 Reviewed by: hselasky Changes: _U stable/9/sys/ stable/9/sys/ofed/include/linux/list.h stable/9/sys/ofed/include/net/ip.h -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:03:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CB027F8 for ; Tue, 6 Jan 2015 08:03:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8435D64613 for ; Tue, 6 Jan 2015 08:03:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0683lCd002046 for ; Tue, 6 Jan 2015 08:03:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 191468] [vimage] options VIMAGE + Infiniband - kernel panic, crashes during system boot Date: Tue, 06 Jan 2015 08:03:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:03:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191468 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:39:38 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79471E80 for ; Tue, 6 Jan 2015 08:39:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60B1064A60 for ; Tue, 6 Jan 2015 08:39:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t068dc2a088823 for ; Tue, 6 Jan 2015 08:39:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Tue, 06 Jan 2015 08:39:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:39:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #15 from commit-hook@freebsd.org --- A commit references this bug: Author: rodrigc Date: Tue Jan 6 08:39:09 UTC 2015 New revision: 276746 URL: https://svnweb.freebsd.org/changeset/base/276746 Log: Merge: r258322 from projects/pf branch Split functions that initialize various pf parts into their vimage parts and global parts. Since global parts appeared to be only mutex initializations, just abandon them and use MTX_SYSINIT() instead. Kill my incorrect VNET_FOREACH() iterator and instead use correct approach with VNET_SYSINIT(). PR: 194515 Differential Revision: D1309 Submitted by: glebius, Nikos Vassiliadis Reviewed by: trociny, zec, gnn Changes: head/sys/net/pfvar.h head/sys/netpfil/pf/pf.c head/sys/netpfil/pf/pf_if.c head/sys/netpfil/pf/pf_ioctl.c head/sys/netpfil/pf/pf_norm.c head/sys/netpfil/pf/pf_table.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:44:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B9CDF86 for ; Tue, 6 Jan 2015 08:44:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D984364B7B for ; Tue, 6 Jan 2015 08:44:33 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t068iXXZ004810 for ; Tue, 6 Jan 2015 08:44:33 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t068iX6R004809; Tue, 6 Jan 2015 08:44:33 GMT (envelope-from root) Date: Tue, 6 Jan 2015 08:44:33 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Closed] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSroHE= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:44:34 -0000 rodrigc closed this revision. rodrigc added a comment. Committed REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, bz, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:49:19 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C530175 for ; Tue, 6 Jan 2015 08:49:19 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4667D64BF2 for ; Tue, 6 Jan 2015 08:49:19 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t068nJLo008738 for ; Tue, 6 Jan 2015 08:49:19 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t068nJ1N008735; Tue, 6 Jan 2015 08:49:19 GMT (envelope-from root) Date: Tue, 6 Jan 2015 08:49:18 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Abandoned] D1312: VIMAGE PF fixes #2 Message-ID: <418774b2807989b489d0193d133cbb67@localhost.localdomain> X-Priority: 3 Thread-Topic: D1312: VNET PF fixes #2 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OTEzZmU1MDE5NzRjYjllYzQxMmNjNjQyZWM1IFSroY4= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:49:19 -0000 rodrigc abandoned this revision. rodrigc added a comment. Committed as part of D1309 REVISION DETAIL https://reviews.freebsd.org/D1312 To: rodrigc, bz, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson Cc: freebsd-pf, freebsd-virtualization, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 08:52:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 514012E2 for ; Tue, 6 Jan 2015 08:52:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6290564E53 for ; Tue, 6 Jan 2015 08:51:38 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t068pc6T012691 for ; Tue, 6 Jan 2015 08:51:38 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t068pcSf012690; Tue, 6 Jan 2015 08:51:38 GMT (envelope-from root) Date: Tue, 6 Jan 2015 08:51:38 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Abandoned] D1313: VIMAGE PF fixes #3 Message-ID: X-Priority: 3 Thread-Topic: D1313: VIMAGE PF fixes #3 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: N2E2YTZiYWMwMDJmYzAzMTFiODgwZDc5MmEyIFSroho= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 08:52:44 -0000 rodrigc abandoned this revision. rodrigc added a comment. Committed as part of D1309 REVISION DETAIL https://reviews.freebsd.org/D1313 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, zec Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 09:03:43 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 471BF7E4 for ; Tue, 6 Jan 2015 09:03:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EC252FED for ; Tue, 6 Jan 2015 09:03:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0693haT007433 for ; Tue, 6 Jan 2015 09:03:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Tue, 06 Jan 2015 09:03:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:03:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #16 from commit-hook@freebsd.org --- A commit references this bug: Author: rodrigc Date: Tue Jan 6 09:03:04 UTC 2015 New revision: 276747 URL: https://svnweb.freebsd.org/changeset/base/276747 Log: Instead of creating a purge thread for every vnet, create a single purge thread and clean up all vnets from this thread. PR: 194515 Differential Revision: D1315 Submitted by: Nikos Vassiliadis Changes: head/sys/netpfil/pf/pf.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 09:06:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 976298B8 for ; Tue, 6 Jan 2015 09:06:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7002666031 for ; Tue, 6 Jan 2015 09:06:59 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t0696xRc028328 for ; Tue, 6 Jan 2015 09:06:59 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t0696x94028325; Tue, 6 Jan 2015 09:06:59 GMT (envelope-from root) Date: Tue, 6 Jan 2015 09:06:59 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Accepted] D1315: VIMAGE PF fixes #4 Message-ID: <83e16bb1aaa0e71bac5623b8a7c3a4f2@localhost.localdomain> X-Priority: 3 Thread-Topic: D1315: VIMAGE PF fixes #4 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZGI1YWY1MTBmYjU4M2RhM2FhZDQyNzA4YWQ1IFSrpbM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:06:59 -0000 rodrigc accepted this revision. rodrigc added a reviewer: rodrigc. rodrigc added a comment. This revision is now accepted and ready to land. Committed in rS276747 REVISION DETAIL https://reviews.freebsd.org/D1315 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, zec Cc: zec, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 09:07:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A543989 for ; Tue, 6 Jan 2015 09:07:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73C7A66049 for ; Tue, 6 Jan 2015 09:07:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t06976tq028478 for ; Tue, 6 Jan 2015 09:07:06 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t06976Ya028473; Tue, 6 Jan 2015 09:07:06 GMT (envelope-from root) Date: Tue, 6 Jan 2015 09:07:06 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Closed] D1315: VIMAGE PF fixes #4 Message-ID: <14002e94e1cb1ac03349e983e329cb63@localhost.localdomain> X-Priority: 3 Thread-Topic: D1315: VIMAGE PF fixes #4 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZGI1YWY1MTBmYjU4M2RhM2FhZDQyNzA4YWQ1IFSrpbo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:07:06 -0000 rodrigc closed this revision. REVISION DETAIL https://reviews.freebsd.org/D1315 To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, gnn, hiren, rwatson, zec Cc: zec, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 13:08:03 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2661F316 for ; Tue, 6 Jan 2015 13:08:03 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DDB164812 for ; Tue, 6 Jan 2015 13:08:03 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t06D820H000812 for ; Tue, 6 Jan 2015 13:08:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194672] [carp] Changing advskew to 0 from another value doesn't work Date: Tue, 06 Jan 2015 13:08:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:08:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194672 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: loos Date: Tue Jan 6 13:07:14 UTC 2015 New revision: 276751 URL: https://svnweb.freebsd.org/changeset/base/276751 Log: Remove the check that prevent carp(4) advskew to be set to '0'. CARP devices are created with advskew set to '0' and once you set it to any other value in the valid range (0..254) you can't set it back to zero. The code in question is also used to prevent that zeroed values overwrite the CARP defaults when a new CARP device is created. Since advskew already defaults to '0' for newly created devices and the new value is guaranteed to be within the valid range, it is safe to overwrite it here. PR: 194672 Reported by: cmb@pfsense.org In collaboration with: garga Tested by: garga MFC after: 2 weeks Changes: head/sys/netinet/ip_carp.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 14:02:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33CBBC93 for ; Tue, 6 Jan 2015 14:02:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DFE26618F for ; Tue, 6 Jan 2015 14:02:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t06E25e6041261 for ; Tue, 6 Jan 2015 14:02:05 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t06E25Ko041260; Tue, 6 Jan 2015 14:02:05 GMT (envelope-from root) Date: Tue, 6 Jan 2015 14:02:05 +0000 To: freebsd-net@freebsd.org From: "bz (Bjoern A. Zeeb)" Subject: [Differential] [Reopened] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSr6t0= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:02:06 -0000 bz reopened this revision. bz added a comment. This revision is now accepted and ready to land. Even if this would have been merged properly and not broken the build there's still stuff that is wrong for initialisation with different net contexts in this and that needs to be fixed properly. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:17:55 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEB5BDA9 for ; Tue, 6 Jan 2015 16:17:54 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0C7C2D96 for ; Tue, 6 Jan 2015 16:17:54 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id uz6so3382322obc.5 for ; Tue, 06 Jan 2015 08:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2bKXd9p6rtsocaCoawhBvl41V3fyPMIJA/ei6RI1rXU=; b=zJA4jIDHeVUAnybiD8EGNgp/hRMhG+Z0Rm4adZYyAlCO8ibS2KqReyrPLR1nbNkkMU axswVDDF3q6puisKtgipN+EzHU/HTWXtELv2W30I7PExYek5xQFds91tcJDUsPAvOko5 Lxo464wD4jz35ht/WN29sbwdo20F0/PrklVbtQ4ifg64EpZGm4lrs4WmVVyN4u2OtxIH XBzmDCq1vcxiX5SBrVmfNpfm2sP25cuSIOqgMZxAqvK5EKoG2T2SlaLFRVC9YnbC6i+E X1IDPGzL8x7rg9Zj8U2uJGAiMcotE3l4tB1dF2qugRzRq/IabdvXcu6tCnLlc2j9dQK1 2kmg== MIME-Version: 1.0 X-Received: by 10.60.77.2 with SMTP id o2mr57217393oew.34.1420561073876; Tue, 06 Jan 2015 08:17:53 -0800 (PST) Received: by 10.60.22.105 with HTTP; Tue, 6 Jan 2015 08:17:53 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 17:17:53 +0100 Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Vincenzo Maffione To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Avinash Sridharan , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:17:55 -0000 Hello, From what I can guess you are dealing with a QEMU-KVM guest that uses virtio-net device(s) and runs netmap over that device(s). Then, you connect the guest to the host (gentoo) network stack using a standard linux bridge: a TAP device is used by QEMU to forward guest traffic from/to the host network stack. Is that correct? Following Luigi's explanations, the virtio-net header is part of the virtio standard, and its purpose is to carry offloading info (checksum, TSO) across the guests and host kernels. For instance, your guest kernel can offload the TCP checksum to the virtio-net device, which in turn uses the virtio-net header (that requires TAP driver support) to postpone the checksum to the host kernel. If packets arrive to a physical NIC that supports checksum offloading (e.g. a r8169 NIC attached to the same bridge to which the TAP is attached), you have effectively offloaded the checksum computation from the guest kernel straight to the physical NIC in the physical host. If you see the virtio-net header with "pkt-gen -f rx", it means that you are using netmap in "native" mode, that is you use the specific virtio netmap adapter to send/receive packets from the (virtual) NIC. If you used netmap over virtio-net in "emulated" mode you wouldn't see the virtio-net header, because netmap would be using the standard driver (slow) datapath under the hood: In the rx datapath, the driver converts the virtio-net header into skbuffs/mbufs metadata, so you don't see it. I don't remember having tried to make QEMU use a TAP with no virtio-net-header extension, but I see that it is possible to disable it invoking qemu from command line $ x86_64-softmmu/qemu-system-x86_64 --help | grep tap -net tap[,vlan=n][,name=str][,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n] use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag -netdev [user|tap|bridge|vde|netmap|vhost-user|socket|hubport],id=str[,option][,option][,...] where you see that you can specify "vnet_hdr=off" when declaring the qemu "backend" associated to the virtio-net guest device. Never tried, but it should work. In the worst case you can recompile the tap driver without IFF_VNET_HDR extension, so that QEMU does not find it. Cheers, Vincenzo 2015-01-05 13:19 GMT+01:00 Luigi Rizzo : > What you see is a virtio issue. > > virtio prepends a 10 or 12-byte "virtio header" > to all packets, which is used to define what sort > of NIC accelerations (checksum, tso etc.) are > expected on the link. > > I do not remember if there is a way in qemu-kvm to > remove the header. Maybe Vincenzo (in Cc) remembers. > > cheers > luigi > > On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan > wrote: >> >> I am using netmap with the click modular router, running the click-modular >> router in user space. A while back I was using this combination with the >> e1000 device driver, with a slightly older netmap code-base. >> >> Recently I updated my netmap code base and am trying to use the >> click-modular router with netmap over a virtio-net device driver (over KVM). >> With this combination, though I was able to receive packets I was unable to >> interpret any packets coming from the FromDevice element. >> >> To debug this issue (and to negate any changes I made to the click-modular >> router), I ran the pkt-gen application with the "dump payload" option: >> >> sudo ~/pkt-gen -i eth1 -f rx -X >> >> This showed that packets are being received correctly from the >> netmap-enabled interface, but there are an extra "12" bytes appended to the >> packet. >> >> 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) >> >> ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] >> >> 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ << >> extra 12 bytes >> >> 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... >> >> 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... >> >> 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... >> >> 64: 00 00 00 00 bc 9b f6 74 >> >> >> As we can see, the above is an STP BPDU, and there are 12 leading bytes in >> the payload. >> >> >> The extra leading bytes screw up the packet interpretation. >> >> >> So is this is an artifact of the virtio-net driver or has something >> changed in the netmap device driver? >> >> >> Thanks, >> >> Avinash > > > > > -- > -----------------------------------------+------------------------------- > 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) > -----------------------------------------+------------------------------- -- Vincenzo Maffione From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:31:09 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28FA4312 for ; Tue, 6 Jan 2015 16:31:09 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0CD92F4B for ; Tue, 6 Jan 2015 16:31:08 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id i50so16605481qgf.24 for ; Tue, 06 Jan 2015 08:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ft0jmi9W/DD6B3aS64WyrHvTrP2i49JggC9IbnJz+H4=; b=BopE2NMPy9a38dWQE8yD7RuT+sqTk8PTXlLmg5dBOaU6RZqJX9f8A+oMsat1/UTpSt 4r2d7N0cYKKmwtGnaBpvYgvfFMMMKvU2bWUesPl9JQa0FatjbfAAHuNjRsrGcN9ct+V4 Ja+aJx4fIIfttnNYhu/CiujDZ2+G+8rwNbUn9ii8XtLVxeo7DpzC/5Q6UbJqoQlc8cjq Msa6ixlTCfXpNVVwDqX0nQB/ii9ydVvMpOm+Qo4xNmBMkNwAZfgD34I5ziMh97XMP23+ ZAZ4iyJEYCGnobVYOzk2qV97UvaM+yzYkPRCundHcTub0DWvy6zD1q4KThnbHEDLrtuZ Rpdw== MIME-Version: 1.0 X-Received: by 10.224.69.200 with SMTP id a8mr154154991qaj.40.1420561867658; Tue, 06 Jan 2015 08:31:07 -0800 (PST) Received: by 10.96.76.201 with HTTP; Tue, 6 Jan 2015 08:31:07 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 08:31:07 -0800 Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Avinash Sridharan To: Vincenzo Maffione Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:31:09 -0000 Hi Vincenzo, Thanks for the explanation. From your explanation it seems like the netmap in "native" mode over virtio-net should be giving some indication of how many extra bytes have been added by the virtio-net driver (or for that matter any other driver that provides this type of rx-descriptor). Otherwise, the application will have to store knowledge about the specifics of the underlying devices which dosen't seem that clean. (I think Adrian was referring to the same issue) That said, how do we handle TX in this case? Since the underlying driver (netmap + virtio-net) expects an extra 12 bytes of header that the application should know when to add. Or is this optional? On Tue, Jan 6, 2015 at 8:17 AM, Vincenzo Maffione wrote: > Hello, > > From what I can guess you are dealing with a QEMU-KVM guest that > uses virtio-net device(s) and runs netmap over that device(s). > Then, you connect the guest to the host (gentoo) network stack using a > standard linux bridge: a TAP device is used by QEMU to forward guest > traffic from/to the host network stack. > > Is that correct? > > Following Luigi's explanations, the virtio-net header is part of the > virtio standard, and its purpose is to carry offloading info > (checksum, TSO) across the guests and host kernels. For instance, your > guest kernel can offload the TCP checksum to the virtio-net device, > which in turn uses the virtio-net header (that requires TAP driver > support) to postpone the checksum to the host kernel. If packets > arrive to a physical NIC that supports checksum offloading (e.g. a > r8169 NIC attached to the same bridge to which the TAP is attached), > you have effectively offloaded the checksum computation from the guest > kernel straight to the physical NIC in the physical host. > > If you see the virtio-net header with "pkt-gen -f rx", it means that > you are using netmap in "native" mode, that is you use the specific > virtio netmap adapter to send/receive packets from the (virtual) NIC. > If you used netmap over virtio-net in "emulated" mode you wouldn't see > the virtio-net header, because netmap would be using the standard > driver (slow) datapath under the hood: In the rx datapath, the driver > converts the virtio-net header into skbuffs/mbufs metadata, so you > don't see it. > > I don't remember having tried to make QEMU use a TAP with no > virtio-net-header extension, but I see that it is possible to disable > it invoking qemu from command line > > $ x86_64-softmmu/qemu-system-x86_64 --help | grep tap > > -net > tap[,vlan=n][,name=str][,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n] > use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap > flag > -netdev > [user|tap|bridge|vde|netmap|vhost-user|socket|hubport],id=str[,option][,option][,...] > > where you see that you can specify "vnet_hdr=off" when declaring the > qemu "backend" associated to the virtio-net guest device. > Never tried, but it should work. In the worst case you can recompile > the tap driver without IFF_VNET_HDR extension, so that QEMU does not > find it. > > > Cheers, > Vincenzo > > 2015-01-05 13:19 GMT+01:00 Luigi Rizzo : > > What you see is a virtio issue. > > > > virtio prepends a 10 or 12-byte "virtio header" > > to all packets, which is used to define what sort > > of NIC accelerations (checksum, tso etc.) are > > expected on the link. > > > > I do not remember if there is a way in qemu-kvm to > > remove the header. Maybe Vincenzo (in Cc) remembers. > > > > cheers > > luigi > > > > On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan > > wrote: > >> > >> I am using netmap with the click modular router, running the > click-modular > >> router in user space. A while back I was using this combination with the > >> e1000 device driver, with a slightly older netmap code-base. > >> > >> Recently I updated my netmap code base and am trying to use the > >> click-modular router with netmap over a virtio-net device driver (over > KVM). > >> With this combination, though I was able to receive packets I was > unable to > >> interpret any packets coming from the FromDevice element. > >> > >> To debug this issue (and to negate any changes I made to the > click-modular > >> router), I ran the pkt-gen application with the "dump payload" option: > >> > >> sudo ~/pkt-gen -i eth1 -f rx -X > >> > >> This showed that packets are being received correctly from the > >> netmap-enabled interface, but there are an extra "12" bytes appended to > the > >> packet. > >> > >> 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) > >> > >> ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] > >> > >> 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ > << > >> extra 12 bytes > >> > >> 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... > >> > >> 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... > >> > >> 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... > >> > >> 64: 00 00 00 00 bc 9b f6 74 > >> > >> > >> As we can see, the above is an STP BPDU, and there are 12 leading bytes > in > >> the payload. > >> > >> > >> The extra leading bytes screw up the packet interpretation. > >> > >> > >> So is this is an artifact of the virtio-net driver or has something > >> changed in the netmap device driver? > >> > >> > >> Thanks, > >> > >> Avinash > > > > > > > > > > -- > > -----------------------------------------+------------------------------- > > 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) > > -----------------------------------------+------------------------------- > > > > -- > Vincenzo Maffione > From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:31:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04892454 for ; Tue, 6 Jan 2015 16:31:44 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D195B2FB8 for ; Tue, 6 Jan 2015 16:31:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t06GVhWc098736 for ; Tue, 6 Jan 2015 16:31:43 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t06GVh0P098735; Tue, 6 Jan 2015 16:31:43 GMT (envelope-from root) Date: Tue, 6 Jan 2015 16:31:43 +0000 To: freebsd-net@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Changed Subscribers] D1309: VIMAGE PF fixes #1 Message-ID: X-Priority: 3 Thread-Topic: D1309: VIMAGE PF fixes #1 X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NzA2ZjJlODRkOGZmNmYwM2M1MmQ1N2YzYTJkIFSsDe8= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:31:44 -0000 emaste added a subscriber: emaste. REVISION DETAIL https://reviews.freebsd.org/D1309 To: rodrigc, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: emaste, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:33:20 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9ED592 for ; Tue, 6 Jan 2015 16:33:20 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FCB864095 for ; Tue, 6 Jan 2015 16:33:20 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id dc16so16729492qab.9 for ; Tue, 06 Jan 2015 08:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3PyS61ecQAO8Vy1A3P9msdvzJgytUrWM5wGu9HWDgbE=; b=GTGG5dnEFHH9KqwnYe3EGoLfsYJxnPQ+U1JRiFasW6U6za2fbci71xnKq5pqsrh5j9 ZCCXJDCYlNPhMgilVXCscCm3jXczQ09CX9wS0XLcxDssZL/aqSfPCqzamsuDep8eW9jB wafJgUJYRdzG2oD1C2pSaLPU2d2gGKaxj7NLTSCHc2bH1LbMz0n/s3R11QMS4OFpP8cZ ywnixSnUZfAjcoYvujF/BoiaOlQi6OHP9j3tEFIszeJ7ZOa0uOLDIgzuLL4p2u/1Dq7N 27xwOOsP7jZDmY0bcD2nzV8ANVm4Xd3uVr5p/dA32CkpFqn7hMfgV7a4O5OUh5ESqI63 hbOg== MIME-Version: 1.0 X-Received: by 10.140.37.115 with SMTP id q106mr89296128qgq.38.1420561999450; Tue, 06 Jan 2015 08:33:19 -0800 (PST) Received: by 10.96.76.201 with HTTP; Tue, 6 Jan 2015 08:33:19 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 08:33:19 -0800 Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Avinash Sridharan To: Vincenzo Maffione Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:33:21 -0000 By the way, Vincenzo, your assumptions about my system setup: "From what I can guess you are dealing with a QEMU-KVM guest that uses virtio-net device(s) and runs netmap over that device(s). Then, you connect the guest to the host (gentoo) network stack using a standard linux bridge: a TAP device is used by QEMU to forward guest traffic from/to the host network stack." are correct. On Tue, Jan 6, 2015 at 8:31 AM, Avinash Sridharan < avinash.sridharan@gmail.com> wrote: > Hi Vincenzo, > Thanks for the explanation. From your explanation it seems like the > netmap in "native" mode over virtio-net should be giving some indication of > how many extra bytes have been added by the virtio-net driver (or for that > matter any other driver that provides this type of rx-descriptor). > Otherwise, the application will have to store knowledge about the specifics > of the underlying devices which dosen't seem that clean. (I think Adrian > was referring to the same issue) > > That said, how do we handle TX in this case? Since the underlying driver > (netmap + virtio-net) expects an extra 12 bytes of header that the > application should know when to add. Or is this optional? > > > > > > On Tue, Jan 6, 2015 at 8:17 AM, Vincenzo Maffione > wrote: > >> Hello, >> >> From what I can guess you are dealing with a QEMU-KVM guest that >> uses virtio-net device(s) and runs netmap over that device(s). >> Then, you connect the guest to the host (gentoo) network stack using a >> standard linux bridge: a TAP device is used by QEMU to forward guest >> traffic from/to the host network stack. >> >> Is that correct? >> >> Following Luigi's explanations, the virtio-net header is part of the >> virtio standard, and its purpose is to carry offloading info >> (checksum, TSO) across the guests and host kernels. For instance, your >> guest kernel can offload the TCP checksum to the virtio-net device, >> which in turn uses the virtio-net header (that requires TAP driver >> support) to postpone the checksum to the host kernel. If packets >> arrive to a physical NIC that supports checksum offloading (e.g. a >> r8169 NIC attached to the same bridge to which the TAP is attached), >> you have effectively offloaded the checksum computation from the guest >> kernel straight to the physical NIC in the physical host. >> >> If you see the virtio-net header with "pkt-gen -f rx", it means that >> you are using netmap in "native" mode, that is you use the specific >> virtio netmap adapter to send/receive packets from the (virtual) NIC. >> If you used netmap over virtio-net in "emulated" mode you wouldn't see >> the virtio-net header, because netmap would be using the standard >> driver (slow) datapath under the hood: In the rx datapath, the driver >> converts the virtio-net header into skbuffs/mbufs metadata, so you >> don't see it. >> >> I don't remember having tried to make QEMU use a TAP with no >> virtio-net-header extension, but I see that it is possible to disable >> it invoking qemu from command line >> >> $ x86_64-softmmu/qemu-system-x86_64 --help | grep tap >> >> -net >> tap[,vlan=n][,name=str][,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n] >> use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap >> flag >> -netdev >> [user|tap|bridge|vde|netmap|vhost-user|socket|hubport],id=str[,option][,option][,...] >> >> where you see that you can specify "vnet_hdr=off" when declaring the >> qemu "backend" associated to the virtio-net guest device. >> Never tried, but it should work. In the worst case you can recompile >> the tap driver without IFF_VNET_HDR extension, so that QEMU does not >> find it. >> >> >> Cheers, >> Vincenzo >> >> 2015-01-05 13:19 GMT+01:00 Luigi Rizzo : >> > What you see is a virtio issue. >> > >> > virtio prepends a 10 or 12-byte "virtio header" >> > to all packets, which is used to define what sort >> > of NIC accelerations (checksum, tso etc.) are >> > expected on the link. >> > >> > I do not remember if there is a way in qemu-kvm to >> > remove the header. Maybe Vincenzo (in Cc) remembers. >> > >> > cheers >> > luigi >> > >> > On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan >> > wrote: >> >> >> >> I am using netmap with the click modular router, running the >> click-modular >> >> router in user space. A while back I was using this combination with >> the >> >> e1000 device driver, with a slightly older netmap code-base. >> >> >> >> Recently I updated my netmap code base and am trying to use the >> >> click-modular router with netmap over a virtio-net device driver (over >> KVM). >> >> With this combination, though I was able to receive packets I was >> unable to >> >> interpret any packets coming from the FromDevice element. >> >> >> >> To debug this issue (and to negate any changes I made to the >> click-modular >> >> router), I ran the pkt-gen application with the "dump payload" option: >> >> >> >> sudo ~/pkt-gen -i eth1 -f rx -X >> >> >> >> This showed that packets are being received correctly from the >> >> netmap-enabled interface, but there are an extra "12" bytes appended >> to the >> >> packet. >> >> >> >> 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) >> >> >> >> ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] >> >> >> >> 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 >> ................ << >> >> extra 12 bytes >> >> >> >> 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... >> >> >> >> 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... >> >> >> >> 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... >> >> >> >> 64: 00 00 00 00 bc 9b f6 74 >> >> >> >> >> >> As we can see, the above is an STP BPDU, and there are 12 leading >> bytes in >> >> the payload. >> >> >> >> >> >> The extra leading bytes screw up the packet interpretation. >> >> >> >> >> >> So is this is an artifact of the virtio-net driver or has something >> >> changed in the netmap device driver? >> >> >> >> >> >> Thanks, >> >> >> >> Avinash >> > >> > >> > >> > >> > -- >> > >> -----------------------------------------+------------------------------- >> > 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) >> > >> -----------------------------------------+------------------------------- >> >> >> >> -- >> Vincenzo Maffione >> > > From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:47:30 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 133E2AA4 for ; Tue, 6 Jan 2015 16:47:30 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF5B36429F for ; Tue, 6 Jan 2015 16:47:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t06GlTSD047745 for ; Tue, 6 Jan 2015 16:47:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Tue, 06 Jan 2015 16:47:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:47:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 --- Comment #17 from commit-hook@freebsd.org --- A commit references this bug: Author: rodrigc Date: Tue Jan 6 16:47:04 UTC 2015 New revision: 276756 URL: https://svnweb.freebsd.org/changeset/base/276756 Log: Reapply previous patch to fix build. PR: 194515 Changes: head/sys/net/pfvar.h head/sys/netpfil/pf/pf.c head/sys/netpfil/pf/pf_if.c head/sys/netpfil/pf/pf_ioctl.c head/sys/netpfil/pf/pf_norm.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 16:57:25 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92AB1E0A for ; Tue, 6 Jan 2015 16:57:25 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 526CD64447 for ; Tue, 6 Jan 2015 16:57:25 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wp4so66589821obc.6 for ; Tue, 06 Jan 2015 08:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MU/Y1nyqGDwFGuqKiiEv5xNGWDuuZ/90kCWHRB5xtto=; b=etAlSB6h7E8i9MnnqrMD8ATrmkhwP1YcGPuNKexSyjtqCEMAbxIP2Yg1GC28/zPpqD LB3Y45uLqDkZL+2akRlozEuSpbXUK2ftcVfM6i5RKVPh8MxSFOl7oSBRgvqJqe/km9Qb Q2YDurvrvNQ2AKX0ZlSZr+64+9d7rfDHvWNOQQjOBJ9FCaNF8HSsuROGMb6uVO+WUnpz 4XzuYAG8YJXRp+aZ+mn8PI7VNX8dtvHI9pVKa43ydmXy2QhvJhuznR77XqMiS+vK+Ea/ roy05dAJ2swgGnOoyRPSfffd/e/K67I19jF+rGaRBIZ/ggIkKehUooRwwSQ5xTZNYDPI FUHg== MIME-Version: 1.0 X-Received: by 10.202.75.81 with SMTP id y78mr54358733oia.80.1420563444591; Tue, 06 Jan 2015 08:57:24 -0800 (PST) Received: by 10.60.22.105 with HTTP; Tue, 6 Jan 2015 08:57:24 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 17:57:24 +0100 Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Vincenzo Maffione To: Avinash Sridharan Content-Type: text/plain; charset=UTF-8 Cc: Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:57:25 -0000 2015-01-06 17:31 GMT+01:00 Avinash Sridharan : > Hi Vincenzo, > Thanks for the explanation. From your explanation it seems like the netmap > in "native" mode over virtio-net should be giving some indication of how > many extra bytes have been added by the virtio-net driver (or for that > matter any other driver that provides this type of rx-descriptor). > Otherwise, the application will have to store knowledge about the specifics > of the underlying devices which dosen't seem that clean. (I think Adrian was > referring to the same issue) I understand the problem (this was left as an open problem), and it's not clear to me what should be the best solution. On one hand, one could modify the native virtio-net adapter so that it discards the extra header. This can be done with a copy - as Luigi suggests - or with some trick involving scatter-gather virtio support - e.g. trying to make the virtio-net headers go in some other buffers parallel to the "official" netmap buffers (i.e. the ones your application reads from). On the other end, the virtio-net header carry some information (mainly TCP/UDP related) that you may not want to discard - even when using netmap - and this depends on the specific application. So to avoid making a one-for-all decision, I thought it was better to leave it to the application. > > That said, how do we handle TX in this case? Since the underlying driver > (netmap + virtio-net) expects an extra 12 bytes of header that the > application should know when to add. Or is this optional? Yes you have to add it, otherwise it won't work! It's not optional. In order to make tests for virtio-net tx, I added a "-H" option to pkt-gen, which pushes an empty virtio-net-header before the ethernet frame. You can use "-H 12" for your tests. Again, it's not clear (at least to me) how we should manage this virtio-net peculiarity at the netmap API level. Cheers, Vincenzo > > > > > > On Tue, Jan 6, 2015 at 8:17 AM, Vincenzo Maffione > wrote: >> >> Hello, >> >> From what I can guess you are dealing with a QEMU-KVM guest that >> uses virtio-net device(s) and runs netmap over that device(s). >> Then, you connect the guest to the host (gentoo) network stack using a >> standard linux bridge: a TAP device is used by QEMU to forward guest >> traffic from/to the host network stack. >> >> Is that correct? >> >> Following Luigi's explanations, the virtio-net header is part of the >> virtio standard, and its purpose is to carry offloading info >> (checksum, TSO) across the guests and host kernels. For instance, your >> guest kernel can offload the TCP checksum to the virtio-net device, >> which in turn uses the virtio-net header (that requires TAP driver >> support) to postpone the checksum to the host kernel. If packets >> arrive to a physical NIC that supports checksum offloading (e.g. a >> r8169 NIC attached to the same bridge to which the TAP is attached), >> you have effectively offloaded the checksum computation from the guest >> kernel straight to the physical NIC in the physical host. >> >> If you see the virtio-net header with "pkt-gen -f rx", it means that >> you are using netmap in "native" mode, that is you use the specific >> virtio netmap adapter to send/receive packets from the (virtual) NIC. >> If you used netmap over virtio-net in "emulated" mode you wouldn't see >> the virtio-net header, because netmap would be using the standard >> driver (slow) datapath under the hood: In the rx datapath, the driver >> converts the virtio-net header into skbuffs/mbufs metadata, so you >> don't see it. >> >> I don't remember having tried to make QEMU use a TAP with no >> virtio-net-header extension, but I see that it is possible to disable >> it invoking qemu from command line >> >> $ x86_64-softmmu/qemu-system-x86_64 --help | grep tap >> >> -net >> tap[,vlan=n][,name=str][,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n] >> use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap >> flag >> -netdev >> [user|tap|bridge|vde|netmap|vhost-user|socket|hubport],id=str[,option][,option][,...] >> >> where you see that you can specify "vnet_hdr=off" when declaring the >> qemu "backend" associated to the virtio-net guest device. >> Never tried, but it should work. In the worst case you can recompile >> the tap driver without IFF_VNET_HDR extension, so that QEMU does not >> find it. >> >> >> Cheers, >> Vincenzo >> >> 2015-01-05 13:19 GMT+01:00 Luigi Rizzo : >> > What you see is a virtio issue. >> > >> > virtio prepends a 10 or 12-byte "virtio header" >> > to all packets, which is used to define what sort >> > of NIC accelerations (checksum, tso etc.) are >> > expected on the link. >> > >> > I do not remember if there is a way in qemu-kvm to >> > remove the header. Maybe Vincenzo (in Cc) remembers. >> > >> > cheers >> > luigi >> > >> > On Mon, Jan 5, 2015 at 6:54 AM, Avinash Sridharan >> > wrote: >> >> >> >> I am using netmap with the click modular router, running the >> >> click-modular >> >> router in user space. A while back I was using this combination with >> >> the >> >> e1000 device driver, with a slightly older netmap code-base. >> >> >> >> Recently I updated my netmap code base and am trying to use the >> >> click-modular router with netmap over a virtio-net device driver (over >> >> KVM). >> >> With this combination, though I was able to receive packets I was >> >> unable to >> >> interpret any packets coming from the FromDevice element. >> >> >> >> To debug this issue (and to negate any changes I made to the >> >> click-modular >> >> router), I ran the pkt-gen application with the "dump payload" option: >> >> >> >> sudo ~/pkt-gen -i eth1 -f rx -X >> >> >> >> This showed that packets are being received correctly from the >> >> netmap-enabled interface, but there are an extra "12" bytes appended to >> >> the >> >> packet. >> >> >> >> 381.088570 main_thread [1446] 1 pps (1 pkts in 1001088 usec) >> >> >> >> ring 0x7f133bca6000 cur 1 [buf 516 flags 0x0000 len 72] >> >> >> >> 0: 00 00 00 00 00 00 00 00 00 00 01 00 01 80 c2 00 ................ >> >> << >> >> extra 12 bytes >> >> >> >> 16: 00 00 40 16 7e 5b 50 f0 00 26 42 42 03 00 00 00 ..@.~[P..&BB.... >> >> >> >> 32: 00 00 80 00 40 16 7e 5b 50 f0 00 00 00 00 80 00 ....@.~[P....... >> >> >> >> 48: 40 16 7e 5b 50 f0 80 01 00 00 14 00 02 00 00 00 @.~[P........... >> >> >> >> 64: 00 00 00 00 bc 9b f6 74 >> >> >> >> >> >> As we can see, the above is an STP BPDU, and there are 12 leading bytes >> >> in >> >> the payload. >> >> >> >> >> >> The extra leading bytes screw up the packet interpretation. >> >> >> >> >> >> So is this is an artifact of the virtio-net driver or has something >> >> changed in the netmap device driver? >> >> >> >> >> >> Thanks, >> >> >> >> Avinash >> > >> > >> > >> > >> > -- >> > >> > -----------------------------------------+------------------------------- >> > 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) >> > >> > -----------------------------------------+------------------------------- >> >> >> >> -- >> Vincenzo Maffione > > -- Vincenzo Maffione From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 20:04:09 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A186462; Tue, 6 Jan 2015 20:04:09 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7F5652FF7; Tue, 6 Jan 2015 18:37:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5B70A7300A; Tue, 6 Jan 2015 19:42:20 +0100 (CET) Date: Tue, 6 Jan 2015 19:42:20 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: netmap over virtio giving packets with extra 12 bytes Message-ID: <20150106184220.GA35485@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Vincenzo Maffione , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:04:09 -0000 On Tue, Jan 06, 2015 at 10:15:02AM -0800, Adrian Chadd wrote: ... > This won't be the first time that there'll be useful data at the front > end of an RX mbuf that isn't related to the mbuf payload. > > It'd be nice if there were something in each rx ring slot saying how > far to skip into the buffer to get the beginning of the packet. I am not opposed in principle, this is something we have been looking at since day one. The blocking issue is that incompatible hw constraints make it hard to make a decent choice. Examples: 1. the rx buffer size you tell to ixgbe must be a power of two. If you want to write at some offset into the netmap buffer, you need to allocate one twice the size you pass to the driver. 2. some NICs may want buffers aligned to 4, 8, 16 bytes, so input offsets for headers cannot be arbitrary (12 is almost as bad as 14!) 3. irrespective of functionality, performance drops badly with small packets (where it matters the most) when buffers are not aligned to 64 byte boundaries. The above makes me think that for small packets, copying is the only reasonable way to go, and for large packets i have no idea how to deal with #1 and #2 without having to do scatter-gather. If you have a good suggestion please speak up. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 20:04:44 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D69452 for ; Tue, 6 Jan 2015 20:04:44 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D8DB2758 for ; Tue, 6 Jan 2015 18:15:05 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so20273wid.6 for ; Tue, 06 Jan 2015 10:15:03 -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=qF6zKavVBwPzGOQ2qEL9vK5M71oQgBlr+dYk1TJJjNQ=; b=F3vWNd4nwCY1U8mTA8pNWMpwVr766g99loJ0Z9giDuuZn+LhAO+AnrNV/wuC899utA 4DtVA4LzuYGmGc9BFa7n+bYLs6v/RWCZfjIH5Sq7E+WrmFrz+ZA74FLDgJen3459tO0q LbUk/j2hqjB2Eipi9hTjpyX9UxIDF+klk9EKe74Je3jk1FOT28r1ntcf+UZzOJq4Byc0 spq7/xYs5iXCBzJOTV8bLXVjv9iYvqBy36rW95aYZE4/m3p5kmwBSlzvgRlHZhRf6IPf JEH0c4tcxSDe09dQ/k/gmiz6VaQBQPMFwL7MqP3//Pw+IoSoByTw76n+V7/HKmyDypAu pviQ== MIME-Version: 1.0 X-Received: by 10.180.20.6 with SMTP id j6mr38670767wie.59.1420568102531; Tue, 06 Jan 2015 10:15:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 10:15:02 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Jan 2015 10:15:02 -0800 X-Google-Sender-Auth: xC_spDNs7VURUjs7ymxYQpEgb7Q Message-ID: Subject: Re: netmap over virtio giving packets with extra 12 bytes From: Adrian Chadd To: Vincenzo Maffione Content-Type: text/plain; charset=UTF-8 Cc: Avinash Sridharan , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:04:44 -0000 On 6 January 2015 at 08:57, Vincenzo Maffione wrote: > 2015-01-06 17:31 GMT+01:00 Avinash Sridharan : >> Hi Vincenzo, >> Thanks for the explanation. From your explanation it seems like the netmap >> in "native" mode over virtio-net should be giving some indication of how >> many extra bytes have been added by the virtio-net driver (or for that >> matter any other driver that provides this type of rx-descriptor). >> Otherwise, the application will have to store knowledge about the specifics >> of the underlying devices which dosen't seem that clean. (I think Adrian was >> referring to the same issue) > > I understand the problem (this was left as an open problem), and it's > not clear to me what should be the best solution. > > On one hand, one could modify the native virtio-net adapter so that it > discards the extra header. This can be done with a copy - as Luigi > suggests - or with some trick involving scatter-gather virtio support > - e.g. trying to make the virtio-net headers go in some other buffers > parallel to the "official" netmap buffers (i.e. the ones your > application reads from). > > On the other end, the virtio-net header carry some information (mainly > TCP/UDP related) that you may not want to discard - even when using > netmap - and this depends on the specific application. > > So to avoid making a one-for-all decision, I thought it was better to > leave it to the application. > >> >> That said, how do we handle TX in this case? Since the underlying driver >> (netmap + virtio-net) expects an extra 12 bytes of header that the >> application should know when to add. Or is this optional? > > Yes you have to add it, otherwise it won't work! It's not optional. In > order to make tests for virtio-net tx, I added a "-H" option to > pkt-gen, which pushes an empty virtio-net-header before the ethernet > frame. You can use "-H 12" for your tests. > > Again, it's not clear (at least to me) how we should manage this > virtio-net peculiarity at the netmap API level. This won't be the first time that there'll be useful data at the front end of an RX mbuf that isn't related to the mbuf payload. It'd be nice if there were something in each rx ring slot saying how far to skip into the buffer to get the beginning of the packet. -adrian From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 22:51:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F8EBBAD; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4376EA7C; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so662831pad.3; Tue, 06 Jan 2015 14:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=MLYqA08tpZfW3b/KQ1uxabWL2zqtt2DEQdMWp75P6Zf9B3kmtHGQAlgEssx5lDyJ+M MQUKerOP/saWugo11gcAxnlN0R+DGqqR6lAJSsIglywOAdLt3r4UAkOBGrTcOMdXOAUK 1P9VmbzblFz9bTbtgcS+S6ZUVCOVCyppZvti2sLroHwIuPr1gnHXtscFEKhALq2gK9ND 6ScI2GWc6s8rsrAhGirwKKsWx+sFLw4ymHig5E1cxwMZZTjtv5v8Hfb2fHkWP6P0yH/b A1R7XM5dTnOD362FM7gLK7XJ/WnvmbJh4SX7EFzv4c8g6jxusBXLioyc6cuM8iYr2343 NVyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=rFrBsV4aBVqY+t+pm55ToPCafZNeEWaqJMIVVUkaWr6Tz9j73i7JU5U+iJe9S7iYJ9 Un5Q3Ej0C81zxbfe/imDovu3KeplGxfwxnKcuTSZ8nUIJY8NA22lZVdbRjvom1c4IiZd QB76YPCvqctkzGA+qnmEuh53t90UHZP9hSH2E= X-Received: by 10.66.141.197 with SMTP id rq5mr112415979pab.118.1420584668801; Tue, 06 Jan 2015 14:51:08 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Tue, 6 Jan 2015 14:50:28 -0800 (PST) In-Reply-To: <201412130106.sBD16tgl072730@mail.karels.net> References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> From: Eric Joyner Date: Tue, 6 Jan 2015 14:50:28 -0800 X-Google-Sender-Auth: ipy0MCiE36PaVM6w-CtdKxEn9js Message-ID: Subject: Re: Adding new media types to if_media.h To: mike@karels.net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 22:51:09 -0000 Then going with what Mike says about leaving backwards compatibility, I suppose we should do something like what Adrian suggested, and add a separate struct. We can indicate that the separate struct exists by setting the media type value in the if_media word to 0xc0, since that's the last unused value. Then existing programs won't have to support any new features if they don't want to. Adrian -- where can I look for more information on what net80211 does for media types? Do you mean what it does with MCS values, or something more; I've looked at it a bit, but I don't know very much about how Wi-Fi works. - Eric On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: > > On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: > > > I think I'd go along with Mike, keeping it simpler seems like a good > idea. > > > > > > Jack > > > If the userland ABI impact isn't too broad I think this is fine. Mike, > do you > > know off hand how many user-facing things would be affected? > > I didn't know off hand, but I have a glimpse index at $WORK (it's for > McAfee > Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references > to > if_media.h at user level, including "ports" that we use, and excluding our > own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, > atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h > in the kernel. > > This suggests that we should preserve a backward-compatible user API, even > if it has limits. Unfortunately, the media word I mentioned is a plain > int, > not a typedef. I would propose a similar API that is not limited, but easy > to convert (e.g. using a new typedef). I'd be willing to sketch out > something > like that. > > > > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > > > Any other thoughts, or should I start looking at seeing what I can > take > > > > > copy from net80211? > > > > > > > > > > Also adding -net, since this is pretty relevant. > > > > > > > > I had the same reaction as Adrian initially, as an int with numerous > > > > fields > > > > seems really messy. However, I don't think we have the challenges of > > > > 802.11, > > > > and the only real problem is that the subtype field has run out of > bits. > > > > And both ifconfig and the drivers are cast in the form of a scalar > "media > > > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | > > > > IFM_FDX > > > > (assuming that all the bits are in a scalar). > > > > > > > > Instead, I would propose that we simply change the media word from > 32 bits > > > > to 64, and move the subtype from its current location to a new field > (e.g. > > > > 16 bits) in the new space. I believe this can be KPI compatible, > and it > > > > is relatively easy to provide a backward-compatible ABI. There > should be > > > > a reserved subtype for "other" that can be encoded in the existing > field > > > > for use when the subtype can't fit in the old field. This seems much > > > > easier, > > > > can be KPI compatible, and will make it much easier to backport > drivers. > > > > A backport could simply define the new subtypes as "other", and the > KPI > > > > would still be compatible. > > > > > > > > Thoughts? > > > > > > > > Mike > > > -- > > John Baldwin > > Mike > From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 23:46:07 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF9E7EF4 for ; Tue, 6 Jan 2015 23:46:07 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77A90643EE for ; Tue, 6 Jan 2015 23:46:07 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Y8dp0-0007bw-DZ; Wed, 07 Jan 2015 03:45:58 +0400 Date: Wed, 7 Jan 2015 03:45:58 +0400 From: Slawa Olhovchenkov To: Luigi Rizzo Subject: Re: netmap pipes Message-ID: <20150106234558.GG49169@zxy.spb.ru> References: <20150103164035.GC49169@zxy.spb.ru> <20150103172139.GB95134@onelab2.iet.unipi.it> <20150103173255.GD49169@zxy.spb.ru> <20150103174207.GC95134@onelab2.iet.unipi.it> <20150103175721.GE49169@zxy.spb.ru> <20150103181304.GE95134@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150103181304.GE95134@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:46:07 -0000 On Sat, Jan 03, 2015 at 07:13:04PM +0100, Luigi Rizzo wrote: > > Can I write to slave and read from master? > > pipes are bidirectional and blocking. So you can write > on one and read from the other, in any order. What you mean 'blocking'? Can't be used in select/poll (as blocking disk IO)? > This is a 'power user' feature which maybe is not what you need > (and at the moment I don't have time to explain in more detail > or update the manpage). > Pipes share memory with the netmap port (VALE port or NIC) with the > same basename, and since memory allocation occurs at once, on the > first open you need to tell the OS how many pipes need to share > memory with the same port -- that is the role of nr_arg1. Can you also explain relations between dev.netmap.ring_size dev.netmap.buf_num open interfaces rings per interfaces slots per rings and zerocopy conditions? From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 00:09:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E482D448; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7574B646FF; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so248605wgg.19; Tue, 06 Jan 2015 16:09: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=NS44vkc7bgIl/ds//nP+CVEerhOgsy/9PEhblCmvucY=; b=wrNWe6NaiRqhtuKuGZ53IdrZ5fL7V9bjrlh5FN/qW8fWVVv4fqcxAj8sIl+53b6QR+ WASwPUfkLCVFtB4PYa+EIH+sz5b5nAF8pxzFR/mAc7t5KL9J9qSW84I1XgPBXJj3e6lT fD1aZOHwCbh1Pq27lIxC+ZM2ZOyElev2dC+5DAJ0w/W/KYidNPLAi9SWFj9iwiBFhv7w 15anMI450a8Tq3PajKtXDVN0TaVOzcZRbSFsllhn136TUdRtGrRRaUh57DFwV7yxmW3r pY00YkTRQiTxpJzDvS2sHeDNJsNzIMwmg/zUgHKZhhEjG/K++Ok3dq+xIFP3FmlvV9Yo W7cA== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr371489wjp.20.1420589364856; Tue, 06 Jan 2015 16:09:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 16:09:24 -0800 (PST) In-Reply-To: References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> Date: Tue, 6 Jan 2015 16:09:24 -0800 X-Google-Sender-Auth: zTxRoPSVw4orkcXeKarMLcJHczg Message-ID: Subject: Re: Adding new media types to if_media.h From: Adrian Chadd To: Eric Joyner Content-Type: text/plain; charset=UTF-8 Cc: mike@karels.net, Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:09:27 -0000 On 6 January 2015 at 14:50, Eric Joyner wrote: > Then going with what Mike says about leaving backwards compatibility, I > suppose we should do something like what Adrian suggested, and add a > separate struct. We can indicate that the separate struct exists by setting > the media type value in the if_media word to 0xc0, since that's the last > unused value. Then existing programs won't have to support any new features > if they don't want to. > > Adrian -- where can I look for more information on what net80211 does for > media types? Do you mean what it does with MCS values, or something more; > I've looked at it a bit, but I don't know very much about how Wi-Fi works. Well, my idea is that there's parts of ifmedia that's related to the interface state that we care about, and some of it is just presentation related stuff that's opaque to the stack and only relevant for userland and for the driver/phy bits. The tricky bit is breaking the ifmedia API. It's not included as a pointer inside things - it's embedded as an actual struct. It's embedded inside net80211, but other than that and if_lagg I think it's mostly done inside drivers. So maybe we want to turn its use into allocate/free rather than embedded inside the struct; maybe we don't. Second is how we split up the bits that are mediatype-dependent versus the bits that are related to the network stack. My idea is just to break out each ifmedia field into an int each: * if_media Options word: * Bits Use * ---- ------- * 0-4 Media variant * 5-7 Media type * 8-15 Type specific options * 16-18 Mode (for multi-mode devices) * 19 RFU * 20-27 Shared (global) options * 28-31 Instance .. because I think it'll be easier in the long run to just have uint32_t fields for each of these. The general network stack shouldn't care about type, options and mode. It'll be a lot of churn, but I think it's cleaner than trying to continue doing dirty bitmap things. So: * do we break ifmedia use up into a pointer / allocated thing, rather than an embedded struct, with all the driver churn that'll entail; * do we just add a new field for type/options and have a magic type that's "other", or do we just go for breaking each option out into a field in a struct and have accessor methods to get access to things. What do people think? -adrian From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 01:02:04 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A34B354 for ; Wed, 7 Jan 2015 01:02:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C5581037 for ; Wed, 7 Jan 2015 01:02:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t07124mA085146 for ; Wed, 7 Jan 2015 01:02:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Wed, 07 Jan 2015 01:02:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:02:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ricera10@gmail.com --- Comment #3 from Eric Joyner --- I installed 10.1-RELEASE amd64 on an old system we have with two 82573 ports, and they both attached fine. Here's the relevant pciconf output: em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Gigabit Ethernet Controller' class = network subclass = ethernet I don't know what to say about your problem. The shared code setup failure indicates that attach fails very early in the driver load, so it seems like a hardware problem of some sort. Especially since both devices in your case seem to be the same, but only one fails to attach. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 07:51:10 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 082D7AB7 for ; Wed, 7 Jan 2015 07:51:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8E101F95 for ; Wed, 7 Jan 2015 07:51:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t077p9fL023353 for ; Wed, 7 Jan 2015 07:51:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Wed, 07 Jan 2015 07:51:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ken73.chen@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 07:51:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 ken73.chen@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken73.chen@gmail.com --- Comment #4 from ken73.chen@gmail.com --- There is no problem on FreeBSD 8.4, but same problem on 10.1 i386 platform. Dec 25 22:36:25 db2 kernel: FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014 Dec 25 22:36:25 db2 kernel: em0: 0x20 bytes of rid 0x20 res 4 failed (0, 0xffffffff). Dec 25 22:36:25 db2 kernel: em0: Unable to allocate bus resource: ioport Dec 25 22:36:25 db2 kernel: em0: Allocation of PCI resources failed Dec 25 22:36:25 db2 kernel: device_attach: em0 attach returned 6 Dec 25 22:36:25 db2 kernel: em0: mem 0xfe6e0000-0xfe6fffff,0xfe6c0000-0xfe6dffff irq 49 at device 3.0 on pci5 Dec 25 22:36:25 db2 kernel: em0: 0x20 bytes of rid 0x20 res 4 failed (0, 0xffffffff). Dec 25 22:36:25 db2 kernel: em0: Unable to allocate bus resource: ioport Dec 25 22:36:25 db2 kernel: em0: Allocation of PCI resources failed ================================== pciconf -lv none3@pci0:5:2:0: class=0x020000 card=0x30001458 chip=0x100d8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82544GC Gigabit Ethernet Controller (LOM)' class = network subclass = ethernet none4@pci0:5:3:0: class=0x020000 card=0x30001458 chip=0x100d8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82544GC Gigabit Ethernet Controller (LOM)' class = network subclass = ethernet -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 23:23:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9A18AF0 for ; Wed, 7 Jan 2015 23:23:36 +0000 (UTC) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [193.138.118.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6A87AFFE for ; Wed, 7 Jan 2015 23:23:35 +0000 (UTC) Received: from [192.168.0.103] (89-77-160-163.dynamic.chello.pl [89.77.160.163]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 27B52582A02 for ; Thu, 8 Jan 2015 00:13:46 +0100 (CET) Message-ID: <54ADBDDC.3040901@frasunek.com> Date: Thu, 08 Jan 2015 00:14:36 +0100 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Corrupted IPv6 routing table Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 23:23:36 -0000 Dear all, We are running FreeBSD 9.2-RELEASE-p3 on few PPPoE access servers, each servicing about 1000 customers. Each server exchanges customers' /32 (for IPv4) and /64 (for IPv6) routes using OSPF and BIRD. Few times in a month, we are experiencing routing table corruption, which causes spurious IPv6 routes appearing with prefixlen 0: # netstat -nr -f inet6 | grep "/\0" 2a02:2928:6:989e::/0 fe80::21e:67ff:fe02:e82b%vlan0 UG1 vlan0 2a02:2928:6:989f::/0 fe80::21e:67ff:fe02:e82b%vlan0 UG1 vlan0 It is impossible to delete such routes and they override default route, making IPv6 networking nonfunctional. They definitely does not originate from OSPF, as there is an export filter which denies prefixlen < 32. Has anyone seen this before? From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 00:57:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DA4B924 for ; Thu, 8 Jan 2015 00:57:08 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54E3EAFD for ; Thu, 8 Jan 2015 00:57:08 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id f12so293684qad.6 for ; Wed, 07 Jan 2015 16:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e8RnZnX8b1nvQTcLH6bBFQm/d42EzkfOqDKwsLm8otE=; b=bEBZA57ZyEsZV1BZvYc+2Rtq5x7LU3n9zzN9OSK9abHaWxwlIAizv/igKFVOzcb4RF hKdD3g8Mlt8CdaNsjn7xJ3KhTOr1MxNdk3yiXXq7Exu4GcSeE62vmvypiHuk4KYAvzfe 0iu8UBluSTavQ13tY2I053uECqUPeWRtrd7q4T+i33Hu7U6jj8QP5FoGGyfHfzS25f5E k+i01Td6QPRLKvX344a5faCTBP8tx+MPyXhv/4HmX2D1csJb0U9112X6jJMtAs+g8sBq 90zwplXdI/RRZfPgUXfy5LBP4KaBd0lRZ0JJkem2N7D3IJlg5zKjNC2YdkS/jl8Y37Jy lPew== MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr9768650qas.99.1420678618315; Wed, 07 Jan 2015 16:56:58 -0800 (PST) Received: by 10.96.73.69 with HTTP; Wed, 7 Jan 2015 16:56:58 -0800 (PST) In-Reply-To: <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> Date: Wed, 7 Jan 2015 16:56:58 -0800 Message-ID: Subject: Re: ntpd bind() failure: Can't assign requested address From: hiren panchasara To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 Cc: "" , "schrodinger@konundrum.org" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 00:57:08 -0000 I see this message on july 2014 time-frame -CURRENT. I tried to disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without success. Has this been fixed? Or any workarounds? From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 11:55:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28F73C54 for ; Thu, 8 Jan 2015 11:55:27 +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)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6CC8605 for ; Thu, 8 Jan 2015 11:55:26 +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.9/8.14.9) with ESMTP id t08BtL7r061192; Thu, 8 Jan 2015 06:55:21 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <54AE6FF4.6030504@sentex.net> Date: Thu, 08 Jan 2015 06:54:28 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Przemyslaw Frasunek , freebsd-net@freebsd.org Subject: Re: Corrupted IPv6 routing table References: <54ADBDDC.3040901@frasunek.com> In-Reply-To: <54ADBDDC.3040901@frasunek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:55:27 -0000 On 1/7/2015 6:14 PM, Przemyslaw Frasunek wrote: > Dear all, > > We are running FreeBSD 9.2-RELEASE-p3 on few PPPoE access servers, each > servicing about 1000 customers. Each server exchanges customers' /32 (for IPv4) > and /64 (for IPv6) routes using OSPF and BIRD. > > Few times in a month, we are experiencing routing table corruption, which causes > spurious IPv6 routes appearing with prefixlen 0: I saw this a few yrs ago when I tried mpd with ipv6 after about a month. There are some threads (i think on freebsd-net) about it and some of the areas that needed to be fixed. I had to give up on v6 and mpd as a result. I seem to recall some commits to RELENG_10 that might had addresses some of the bugs I saw, but thats just speculation. Have you tried RELENG_10 as an LNS ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 12:18:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387116F5 for ; Thu, 8 Jan 2015 12:18:14 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla.connectionlost.com.br [131.72.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Tiago Felipe Gon????alves", Issuer "Tiago Felipe Gon????alves" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D904B897 for ; Thu, 8 Jan 2015 12:18:13 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla [131.72.200.69]) by valhalla.connectionlost.com.br (Postfix) with ESMTP id 97596B0D2D for ; Thu, 8 Jan 2015 10:07:37 -0200 (BRST) Authentication-Results: valhalla.connectionlost.com.br; dkim=pass reason="1024-bit key" header.d=connectionlost.com.br header.i=@connectionlost.com.br header.b=IqARuben; dkim-adsp=pass Received: from [186.250.58.220] (unknown [186.250.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by valhalla.connectionlost.com.br (Postfix) with ESMTPSA id 17381B0B53 for ; Thu, 8 Jan 2015 10:07:36 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=connectionlost.com.br; s=valhalla; t=1420718857; bh=FPHXUQbu1Z9uGTS0Ocks0npJ0hFYCITIwe6EMn9LWhw=; h=Date:From:To:Subject:References:In-Reply-To; b=IqARubenkPodEfg3lqqkt/WsICKJa3uszOZ61UUno9yPjrTlo+ihx+X55IOvCZo2a ybQZ/ErVLT7mqACO/ydlRbsci1sq+vDNxtI2QOeGIKvveP4zl/f6ZeX77Tapw68mZl XHfXDxsGzREga2Qp30vcCmXDFlpNDQ81wJiof/+E= Message-ID: <54AE7332.1070408@connectionlost.com.br> Date: Thu, 08 Jan 2015 10:08:18 -0200 From: Tiago Felipe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Corrupted IPv6 routing table References: <54ADBDDC.3040901@frasunek.com> <54AE6FF4.6030504@sentex.net> In-Reply-To: <54AE6FF4.6030504@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:18:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I use mpd5 v4 and v6 in freebsd 10.0 and 10.1, I had no problem just like your for now. On 01/08/2015 09:54 AM, Mike Tancsa wrote: > On 1/7/2015 6:14 PM, Przemyslaw Frasunek wrote: >> Dear all, >> >> We are running FreeBSD 9.2-RELEASE-p3 on few PPPoE access >> servers, each servicing about 1000 customers. Each server >> exchanges customers' /32 (for IPv4) and /64 (for IPv6) routes >> using OSPF and BIRD. >> >> Few times in a month, we are experiencing routing table >> corruption, which causes spurious IPv6 routes appearing with >> prefixlen 0: > > I saw this a few yrs ago when I tried mpd with ipv6 after about a > month. There are some threads (i think on freebsd-net) about it and > some of the areas that needed to be fixed. I had to give up on v6 > and mpd as a result. I seem to recall some commits to RELENG_10 > that might had addresses some of the bugs I saw, but thats just > speculation. Have you tried RELENG_10 as an LNS ? > > ---Mike > > - -- ============================================================================= Tiago Felipe Gonçalves. Gerente de Infraestrutura de TI. +55 19 981811543 PGP Fingerprint - A2:82:BD:48:EE:8D:C4:99:C2:4E:81:D4:C4:7B:1C:2E:C7:F3:04:C9 ============================================================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUrnMuAAoJEMR7HC7H8wTJMXcP/3SGWpZOayZSoFr0eatFu+m7 LskNoUkszQLqy/7L+sGdomPQHi3Cudb+1+PyxKtpWwPcbQJXFyGrB4vxkyzqV5LZ 8te1/Zw0JBD7y9CKE3NswXpbZvggojTyxvr9GVna2rTIa8LQJnxbiVZFnzmcSlq4 fDv/NlPO58qqhI7cXa9JXpbb6wGM/IF5R/f1Hg1LOkf6nEfxalAeDV4R6g37bKgL OS/gcf+33VCQWirnNlCNgJ/rIV9YB5n+5BTj+ZsWpg1W/ZpN00hbttOnqQhpLLPV eLS/vBgjmoxwHWpdjonEpLYVKOuZK3bADeg1u0PuyVT4qCi9t7rzhMMRKlKxWvnv vbIGIt7BtnlnlqbvFvDbHT0GNt0LqcrW3lmTnSV0qbWdbT5oOWVQIQQOBZ5MmDYG cqew8rK0i5dSokYaA4eaQzQDqndVWbwQaiXXm+rAmoG+HsF1602Ez98ilkxjY0DH fCvFGJHhWJgjSKgl+XEMeLEXD/FfWG52n9UmOEEoRsLm2nGnvmtmln61pyjLz/dt InUBS3zu935FXEuveaFZEmbEjdmqEndQOwfF8Xkt8fdvZ8X+wii0Uq6/aq8o3Eib s1iG/LFPHuE2UlMSKj/HqIu5Il3s68xe1zYr2e3fbzwsx/7FMJL9Mrf93IP4UQmP EC2pHoxaqHqDmUYGHC7D =bkKO -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 12:36:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EBE1B61 for ; Thu, 8 Jan 2015 12:36:28 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5BDFA59 for ; Thu, 8 Jan 2015 12:36:27 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y9CK8-00089t-7b; Thu, 08 Jan 2015 16:36:24 +0400 Message-ID: <54AE797A.2050209@FreeBSD.org> Date: Thu, 08 Jan 2015 15:35:06 +0300 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Przemyslaw Frasunek , freebsd-net@freebsd.org Subject: Re: Corrupted IPv6 routing table References: <54ADBDDC.3040901@frasunek.com> In-Reply-To: <54ADBDDC.3040901@frasunek.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:36:28 -0000 On 08.01.2015 02:14, Przemyslaw Frasunek wrote: > Dear all, > > We are running FreeBSD 9.2-RELEASE-p3 on few PPPoE access servers, each > servicing about 1000 customers. Each server exchanges customers' /32 (for IPv4) > and /64 (for IPv6) routes using OSPF and BIRD. > > Few times in a month, we are experiencing routing table corruption, which causes > spurious IPv6 routes appearing with prefixlen 0: > > # netstat -nr -f inet6 | grep "/\0" > 2a02:2928:6:989e::/0 fe80::21e:67ff:fe02:e82b%vlan0 UG1 vlan0 > 2a02:2928:6:989f::/0 fe80::21e:67ff:fe02:e82b%vlan0 UG1 vlan0 > > It is impossible to delete such routes and they override default route, making > IPv6 networking nonfunctional. They definitely does not originate from OSPF, as > there is an export filter which denies prefixlen < 32. > > Has anyone seen this before? Fixed in 9 by r257389 (So you should try either stable or 10.x). > _______________________________________________ > 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 Thu Jan 8 13:18:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED505731 for ; Thu, 8 Jan 2015 13:18:17 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFB6EE14 for ; Thu, 8 Jan 2015 13:18:17 +0000 (UTC) Received: from BY1PR0301MB0902.namprd03.prod.outlook.com (25.160.195.141) by BY1PR0301MB0902.namprd03.prod.outlook.com (25.160.195.141) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 13:18:10 +0000 Received: from BY1PR0301MB0902.namprd03.prod.outlook.com ([25.160.195.141]) by BY1PR0301MB0902.namprd03.prod.outlook.com ([25.160.195.141]) with mapi id 15.01.0049.002; Thu, 8 Jan 2015 13:18:10 +0000 From: Wei Hu To: "freebsd-net@freebsd.org" Subject: How to get the IP and TCP fields in mbuf Thread-Topic: How to get the IP and TCP fields in mbuf Thread-Index: AdArRYKRzYk6g22kSDSqzVansN1vJg== Date: Thu, 8 Jan 2015 13:18:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [114.91.138.61] authentication-results: spf=none (sender IP is ) smtp.mailfrom=weh@microsoft.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BY1PR0301MB0902; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0902; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(99286002)(105586002)(92566001)(66066001)(229853001)(106356001)(107886001)(2351001)(107046002)(19580395003)(86362001)(2656002)(87936001)(110136001)(31966008)(558084003)(4396001)(54206007)(76576001)(101416001)(99396003)(64706001)(20776003)(40100003)(122556002)(16236675004)(120916001)(68736005)(19625215002)(74316001)(33656002)(19300405004)(21056001)(97736003)(50986999)(77156002)(450100001)(62966003)(2900100001)(54356999)(102836002)(54606007)(15975445007)(86612001)(46102003)(15583001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0902; H:BY1PR0301MB0902.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 13:18:10.8324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0902 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 13:18:18 -0000 Hi, I am wondering if there is existing macros in the FreeBSD kernel to extract= to get to the point of the IP and TCP head in a given mbuf. Thanks, Wei From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 14:15:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DADFBA2 for ; Thu, 8 Jan 2015 14:15:45 +0000 (UTC) Received: from smtp2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C9986B4 for ; Thu, 8 Jan 2015 14:15:44 +0000 (UTC) Received: from [131.159.50.43] (homer.sec.in.tum.de [131.159.50.43]) by services.sec.in.tum.de (Postfix) with ESMTPSA id 80F6710110D41; Thu, 8 Jan 2015 15:08:12 +0100 (CET) Message-ID: <54AE8F6D.8010900@sec.in.tum.de> Date: Thu, 08 Jan 2015 15:08:45 +0100 From: Julian Kirsch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: How to get the IP and TCP fields in mbuf References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: weh@microsoft.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:15:45 -0000 Hi Wei, Are you looking for something like this? + struct ip *ip = mtod(m, struct ip *); m is a struct mbuf *. You cann look into my knock-patch for FreeBSD [0] for further examples. Best, Julian [0] https://gnunet.org/knock On 08.01.2015 14:18, Wei Hu wrote: > Hi, > > I am wondering if there is existing macros in the FreeBSD kernel to extract to get to the point of the IP and TCP head in a given mbuf. > > Thanks, > Wei > > > _______________________________________________ > 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" > -- Julian Kirsch Chair for IT-Security (I20) Department of Computer Science, Technische Universität München Boltzmannstrasse 3, D-85748 Garching bei München Phone: +49-89-289-18587 Room: 01.08.53 From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 15:41:52 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F2A6E83; Thu, 8 Jan 2015 15:41:52 +0000 (UTC) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 23618FB3; Thu, 8 Jan 2015 15:41:52 +0000 (UTC) Received: from [10.255.0.126] (fw-vrrp.atmsoftware.pl [217.17.44.148]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id B8E32582A0E; Thu, 8 Jan 2015 16:40:57 +0100 (CET) Message-ID: <54AEA53C.50106@frasunek.com> Date: Thu, 08 Jan 2015 16:41:48 +0100 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: Corrupted IPv6 routing table References: <54ADBDDC.3040901@frasunek.com> <54AE797A.2050209@FreeBSD.org> In-Reply-To: <54AE797A.2050209@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:41:52 -0000 >> Has anyone seen this before? > Fixed in 9 by r257389 (So you should try either stable or 10.x). Thanks a lot! I'll schedule an upgrade. From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 15:45:31 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18EFDFB for ; Thu, 8 Jan 2015 15:45:31 +0000 (UTC) Received: from smtp.lamaiziere.net (net.lamaiziere.net [37.59.62.186]) by mx1.freebsd.org (Postfix) with ESMTP id D4661FD7 for ; Thu, 8 Jan 2015 15:45:30 +0000 (UTC) Received: from mr185083.univ-rennes1.fr (mr185083.univ-rennes1.fr [129.20.185.83]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 33A2762A3; Thu, 8 Jan 2015 16:45:27 +0100 (CET) Received: from mr185083 (localhost [127.0.0.1]) by mr185083.univ-rennes1.fr (Postfix) with ESMTP id 822727390; Thu, 8 Jan 2015 16:45:26 +0100 (CET) Date: Thu, 8 Jan 2015 16:45:26 +0100 From: Patrick Lamaiziere To: freebsd-net@freebsd.org Subject: Re: CARP Problem/Bug? on 10.1-RELEASE Message-ID: <20150108164526.3c979751@mr185083> In-Reply-To: <54AA35DD.8080704@gmail.com> References: <54A69F72.6060405@gmail.com> <54A6B5E3.5090200@multiplay.co.uk> <54AA35DD.8080704@gmail.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (smtp.lamaiziere.net [0.0.0.0]); Thu, 08 Jan 2015 16:45:27 +0100 (CET) Cc: Sascha X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:45:31 -0000 Le Mon, 05 Jan 2015 07:57:33 +0100, Sascha a écrit : Hello, > you made my day! It's working again. But I continue my research. > > Rebooting takes the Port-Channel on the switch down. When the machine > comes up the port-channel on the switch needs some seconds until it's > up. Any spanning tree on the port switch ? You can try to disable it Regards, From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 17:29:26 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16AA4349 for ; Thu, 8 Jan 2015 17:29:26 +0000 (UTC) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3D4DCF5 for ; Thu, 8 Jan 2015 17:29:25 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.9/8.14.9) with ESMTP/inet6 id t08HSvuT051333 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 9 Jan 2015 02:29:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 09 Jan 2015 02:28:56 +0900 Message-ID: From: Hajimu UMEMOTO To: hiren panchasara Subject: Re: ntpd bind() failure: Can't assign requested address In-Reply-To: References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.4 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 10.1-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Fri_Jan__9_02:28:55_2015-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 09 Jan 2015 02:29:05 +0900 (JST) X-Virus-Scanned: clamav-milter 0.98.5 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on asuka.mahoroba.org Cc: "" , "Eggert, Lars" , "schrodinger@konundrum.org" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:29:26 -0000 --Multipart_Fri_Jan__9_02:28:55_2015-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Wed, 7 Jan 2015 16:56:58 -0800 >>>>> hiren panchasara said: hiren> I see this message on july 2014 time-frame -CURRENT. I tried to hiren> disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without hiren> success. hiren> Has this been fixed? Or any workarounds? Perhaps, your interface has an IPv6 link-local address which is tentative state. Please try the attached patch. This patch ignores a tentative address. Sincerely, --Multipart_Fri_Jan__9_02:28:55_2015-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ntp_io.c-tentative.diff" Content-Transfer-Encoding: 7bit Index: contrib/ntp/ntpd/ntp_io.c =================================================================== --- contrib/ntp/ntpd/ntp_io.c (revision 276829) +++ contrib/ntp/ntpd/ntp_io.c (working copy) @@ -1176,12 +1176,13 @@ #ifdef INCLUDE_IPV6_SUPPORT static isc_boolean_t -is_anycast(struct sockaddr *sa, char *name) +is_not_bindable(struct sockaddr *sa, char *name) { -#if defined(SIOCGIFAFLAG_IN6) && defined(IN6_IFF_ANYCAST) +#if defined(SIOCGIFAFLAG_IN6) && \ + (defined(IN6_IFF_ANYCAST) || defined(IN6_IFF_NOTREADY)) struct in6_ifreq ifr6; int fd; - u_int32_t flags6; + u_int32_t flags6, exclude = 0; if (sa->sa_family != AF_INET6) return ISC_FALSE; @@ -1197,9 +1198,15 @@ } close(fd); flags6 = ifr6.ifr_ifru.ifru_flags6; - if ((flags6 & IN6_IFF_ANYCAST) != 0) +#if defined(IN6_IFF_ANYCAST) + exclude |= IN6_IFF_ANYCAST; +#endif +#if defined(IN6_IFF_NOTREADY) + exclude |= IN6_IFF_NOTREADY; +#endif + if ((flags6 & exclude) != 0) return ISC_TRUE; -#endif /* !SIOCGIFAFLAG_IN6 || !IN6_IFF_ANYCAST */ +#endif /* !SIOCGIFAFLAG_IN6 || !(IN6_IFF_ANYCAST && IN6_IFF_NOTREADY) */ return ISC_FALSE; } #endif /* !INCLUDE_IPV6_SUPPORT */ @@ -1344,7 +1351,7 @@ continue; #ifdef INCLUDE_IPV6_SUPPORT - if (is_anycast((struct sockaddr *)&interface.sin, isc_if.name)) + if (is_not_bindable((struct sockaddr *)&interface.sin, isc_if.name)) continue; #endif /* !INCLUDE_IPV6_SUPPORT */ --Multipart_Fri_Jan__9_02:28:55_2015-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ --Multipart_Fri_Jan__9_02:28:55_2015-1-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 17:48:05 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A81795B; Thu, 8 Jan 2015 17:48:05 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5420F2F; Thu, 8 Jan 2015 17:48:04 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i17so3392241qcy.4; Thu, 08 Jan 2015 09:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RJ2FjCk+G4MsT/TaCd6aY/8o/O6X9KG1oGV2EFbVOiY=; b=CmuEvf2dKCvNGt+ziicBEEJOUB5qdbCLKnyBds18ILq5rtTkNz/fV9GFBE/c/X10cF 8NO1wuRES+rRY7iS0UA4J2OAIylGRBwKA79CaXtpMy4RZXAJfKcLd71zhA0jWw5MUfd2 qSWL6spxnwIvcSTibymtyQRryiVFn0E9KUcC5t1lm2y8m3Ku0Vh0nHcaeWHNYTe8yw3e PlSmaKBxuCfDYXBwo2JtKv0oR+bW5ql7o/1Pgl8xVv3S30DfCaiUSWSHopoOd1CHT3Nl jC30d4ZRO2qNKZ7hEPSqZhRbl34OUQqyvm8YRQ5/xyBQSAk/JiNj9JrMHPDU/LN330OC puxQ== MIME-Version: 1.0 X-Received: by 10.140.101.135 with SMTP id u7mr17015257qge.2.1420739282870; Thu, 08 Jan 2015 09:48:02 -0800 (PST) Received: by 10.96.73.69 with HTTP; Thu, 8 Jan 2015 09:48:02 -0800 (PST) In-Reply-To: References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> Date: Thu, 8 Jan 2015 09:48:02 -0800 Message-ID: Subject: Re: ntpd bind() failure: Can't assign requested address From: hiren panchasara To: Hajimu UMEMOTO Content-Type: text/plain; charset=UTF-8 Cc: "" , "Eggert, Lars" , "schrodinger@konundrum.org" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 17:48:05 -0000 On Thu, Jan 8, 2015 at 9:28 AM, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Wed, 7 Jan 2015 16:56:58 -0800 >>>>>> hiren panchasara said: > > hiren> I see this message on july 2014 time-frame -CURRENT. I tried to > hiren> disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without > hiren> success. > > hiren> Has this been fixed? Or any workarounds? > > Perhaps, your interface has an IPv6 link-local address which is > tentative state. > Please try the attached patch. This patch ignores a tentative > address. Indeed its in tentative state and I figured it was causing the issue. Getting it out of tentative state (by enabling IPv6 by 'inet6 -ifdisabled' "fixed" the problem.) But your patch seems like a right way to do it. I'll try it out and report back. Btw, do you mind opening a phabricator review request so we can get a closure on this? cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 20:52:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CD275D7; Thu, 8 Jan 2015 20:52:37 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31DC98CF; Thu, 8 Jan 2015 20:52:37 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id z107so4749417qgd.4; Thu, 08 Jan 2015 12:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3MYA7CJgG6D09MXsvh/PXduordQbffJZXjtsp6tsIx0=; b=J6sXUptSm6nmxUf+QIpk0GEujhhCqa8lXkDbQA+JCG5WOa/hBy2ObU2HPXxs+G6KIP I4QQb1zQgGf6HFK1Gtjk/tt9AOs+sMtP3rbLcCaHKRu21ZUnS8FVzu8qjk4u638TnmuY sFZJDIO4h6jMcSNLN3qYjr7XeNl2e+y2C4v92e8vZsIZnVXAYtNllTeMeIQMoFXr3DqM QV6f8IUQWpIkRTQav+mrRXLiJTAo63qPuAwqdYDIvDGYRfZpWWSuwi+B5m5xVQeW81nG p9QzIWGIRoY02dmxI+gCEB+nQGMaLiyAq/Mxvx9CmkH12q3zu+yyyEoxlvhwTx5h/on+ SS4g== MIME-Version: 1.0 X-Received: by 10.224.26.132 with SMTP id e4mr19335211qac.7.1420750356341; Thu, 08 Jan 2015 12:52:36 -0800 (PST) Received: by 10.96.73.69 with HTTP; Thu, 8 Jan 2015 12:52:36 -0800 (PST) In-Reply-To: References: <1364308780.51602.YahooMailClassic@web31809.mail.mud.yahoo.com> <02416974-D249-4432-9CE6-6093CA9FCCD7@netapp.com> Date: Thu, 8 Jan 2015 12:52:36 -0800 Message-ID: Subject: Re: ntpd bind() failure: Can't assign requested address From: hiren panchasara To: Hajimu UMEMOTO Content-Type: text/plain; charset=UTF-8 Cc: "" , "Eggert, Lars" , "schrodinger@konundrum.org" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 20:52:37 -0000 On Thu, Jan 8, 2015 at 9:48 AM, hiren panchasara wrote: > On Thu, Jan 8, 2015 at 9:28 AM, Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Wed, 7 Jan 2015 16:56:58 -0800 >>>>>>> hiren panchasara said: >> >> hiren> I see this message on july 2014 time-frame -CURRENT. I tried to >> hiren> disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without >> hiren> success. >> >> hiren> Has this been fixed? Or any workarounds? >> >> Perhaps, your interface has an IPv6 link-local address which is >> tentative state. >> Please try the attached patch. This patch ignores a tentative >> address. > > Indeed its in tentative state and I figured it was causing the issue. > Getting it out of tentative state (by enabling IPv6 by 'inet6 > -ifdisabled' "fixed" the problem.) > But your patch seems like a right way to do it. I'll try it out and report back. > Attached patch is fixing the problem for me. cheers, Hiren > Btw, do you mind opening a phabricator review request so we can get a > closure on this? From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 05:42:20 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AD6AA26 for ; Fri, 9 Jan 2015 05:42:20 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA831DD for ; Fri, 9 Jan 2015 05:42:20 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so343375wib.1 for ; Thu, 08 Jan 2015 21:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0Yx/S/D0ecPSqUwG28zrg+jWjBVmTGhW2nkPzGyf8KI=; b=c3YLbpgqsv9dwET4rLmYihOuvcE1iUb5lFgGdDSGmTGx7Yn/LmpI3/UW+G2y4RYI2/ ulE10p0vxXfAyc4yfotMiokZURctCCg3/YG26kZ7PBhIbU2gs9Kq7OK5LaU0JMncCZOk JRtZhPRVsHIeXSrRERRC7ajwTuVRiSijQosnbWHlS00KG/p8eGEsyWU1m6bSdLvl158Z J9UfAusNIEu0kl+RiM3XxlsAccVvrBEgdMUHG4znkxLvBJick9+ANtJeJigtUOLaI5dx cwj0V6dBoUkEK2Wdz67ycjQe8sFFB7N08E1kkEO6GFNabucJ8W+bcpVbVmri48Kocaqf XjWw== X-Received: by 10.180.72.33 with SMTP id a1mr1585892wiv.18.1420782138441; Thu, 08 Jan 2015 21:42:18 -0800 (PST) Received: from [10.99.0.3] ([213.188.107.182]) by mx.google.com with ESMTPSA id 18sm8626509wjr.46.2015.01.08.21.42.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 21:42:17 -0800 (PST) Message-ID: <54AF6A3E.8050009@gmail.com> Date: Fri, 09 Jan 2015 06:42:22 +0100 From: Sascha User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Patrick Lamaiziere , freebsd-net@freebsd.org Subject: Re: CARP Problem/Bug? on 10.1-RELEASE References: <54A69F72.6060405@gmail.com> <54A6B5E3.5090200@multiplay.co.uk> <54AA35DD.8080704@gmail.com> <20150108164526.3c979751@mr185083> In-Reply-To: <20150108164526.3c979751@mr185083> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 05:42:20 -0000 Spanning Tree is disabled on the ports. Best Regards On 08/01/2015 16:45, Sascha wrote: > Le Mon, 05 Jan 2015 07:57:33 +0100, > Sascha a écrit : > > Hello, > >> you made my day! It's working again. But I continue my research. >> >> Rebooting takes the Port-Channel on the switch down. When the machine >> comes up the port-channel on the switch needs some seconds until it's >> up. > Any spanning tree on the port switch ? You can try to disable it > > Regards, From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 05:57:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F7F8BB7 for ; Fri, 9 Jan 2015 05:57:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0719C322 for ; Fri, 9 Jan 2015 05:57:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t095vkNd096021 for ; Fri, 9 Jan 2015 05:57:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Fri, 09 Jan 2015 05:57:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 05:57:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #5 from Mark --- Here is my pciconf -lv none1@pci0:2:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 class = network subclass = ethernet em0@pci0:3:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 class = network subclass = ethernet Please note when this happens I can not install PCI card.. Either a wifi one or Intel 2 port pci.. which is slightly older chips. They work fine if you turn off both built on ports then you can use PCI and both older Intel work but I need more then 2 ports so I am stuck -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 05:59:01 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 483F4C8A for ; Fri, 9 Jan 2015 05:59:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F835333 for ; Fri, 9 Jan 2015 05:59:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t095x1tK096467 for ; Fri, 9 Jan 2015 05:59:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Fri, 09 Jan 2015 05:59:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 05:59:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 Mark changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://pastebin.com/tW9Qe3g | |2 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 06:02:49 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AE80D37 for ; Fri, 9 Jan 2015 06:02:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22E233ED for ; Fri, 9 Jan 2015 06:02:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0962ns2035786 for ; Fri, 9 Jan 2015 06:02:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Fri, 09 Jan 2015 06:02:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:02:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #6 from Mark --- And not a hardware problem, Ubuntu works fine, Windows works fine, only thing that I seen this problem with is going from 8.1 to 10.1 .. Never had any problems and will not have problem if I go back to 8.1 or run some other system -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 06:05:15 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60BF5DE7 for ; Fri, 9 Jan 2015 06:05:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 488DD5E0 for ; Fri, 9 Jan 2015 06:05:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0965FKr041147 for ; Fri, 9 Jan 2015 06:05:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Fri, 09 Jan 2015 06:05:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 06:05:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #7 from Mark --- Note: I read your reply again. I noticed you do not have a dual port but 2 different chips running. That might by why you can run both -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 17:56:32 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B8F46B7 for ; Fri, 9 Jan 2015 17:56:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42E937BA for ; Fri, 9 Jan 2015 17:56:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t09HuWPH083077 for ; Fri, 9 Jan 2015 17:56:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Fri, 09 Jan 2015 17:56:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 17:56:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #8 from Eric Joyner --- Well, would you be willing to use a patch to em that prints out more debugging information? It would require recompiling your kernel, but it would help indicate what exactly is failing. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 03:15:11 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10973959 for ; Sat, 10 Jan 2015 03:15:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBE87822 for ; Sat, 10 Jan 2015 03:15:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0A3FAZX018715 for ; Sat, 10 Jan 2015 03:15:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 196501] [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. Date: Sat, 10 Jan 2015 03:15:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: topper727@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 03:15:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196501 --- Comment #9 from Mark --- (In reply to Eric Joyner from comment #8) What patch? I would try yes. I just need to know how. As I am not the best at freebsd commands yet. I know some but not all -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 14:54:21 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DA7A74B for ; Sat, 10 Jan 2015 14:54:21 +0000 (UTC) Received: from mx.aknet.kg (mx.aknet.kg [212.112.96.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1F5D67 for ; Sat, 10 Jan 2015 14:54:19 +0000 (UTC) Received: from mx.aknet.kg (localhost.aknet.kg [127.0.0.1]) by mx.aknet.kg (Postfix) with ESMTP id D57F41CE01 for ; Sat, 10 Jan 2015 20:36:10 +0600 (KGT) Received: (from nobody@localhost) by mx.aknet.kg (8.13.8/8.13.8/Submit) id t0AEaAgN071333; Sat, 10 Jan 2015 20:36:10 +0600 (KGT) (envelope-from info@aknet.kg) X-Authentication-Warning: mx.aknet.kg: nobody set sender to info@aknet.kg using -f To: Subject: Netmap-Ipfw: dramatic perfomance degrade after certain load and ruleset insertions X-PHP-Originating-Script: 501:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 10 Jan 2015 20:36:10 +0600 From: info@aknet.kg Message-ID: X-Sender: info@aknet.kg User-Agent: Roundcube Webmail/0.7.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 14:54:21 -0000 Hello, All (NetMap dev. Team) ! We use netmap-ipfw server for traffic pre-processing before the main filtering bridge (ordinary dummynet) and met the situation, that netmap-ipfw dramatically degrades perfomance (point B below) from stable work (point A below) after some actions with ruleset. A. Server with netmap-ipfw shows very stable work with following settings: 1. kipfw starts as ./kipfw netmap:ix0 netmap:ix1 2. current statement of sysctl variables: ... dev.netmap.ring_size: 128000 dev.netmap.ring_curr_size: 128000 dev.netmap.buf_curr_size: 4096 dev.netmap.buf_num: 896000 dev.netmap.buf_curr_num: 896000 dev.netmap.ix_rx_miss: 2020539039 dev.netmap.ix_rx_miss_bufs: 1478979631 .... in /boot/loader.conf : hw.ix.rxd=4096 hw.ix.txd=4096 3. traffic at one of interfaces (ix1): root@bridge-netmap:/usr/local/netmap-ipfw/ipfw # netstat -bdh -w1 -I ix1 input ix1 output packets errs idrops bytes packets errs bytes colls drops 628K 0 0 737M 517K 0 106M 0 0 636K 0 0 749M 522K 0 105M 0 0 633K 0 0 744M 527K 0 105M 0 0 635K 0 0 744M 523K 0 107M 0 0 4. system load: CPU 0: 58.7% user, 0.0% nice, 33.5% system, 3.9% interrupt, 3.9% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 3.9% interrupt, 96.1% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 3.5% interrupt, 96.5% idle CPU 3: 0.0% user, 0.0% nice, 0.4% system, 2.8% interrupt, 96.9% idle Mem: 22M Active, 243M Inact, 4125M Wired, 814M Buf, 3429M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 853 root 101 0 7087M 415M CPU0 0 17.5H 93.90% kipfw Sometimes kipfw takes all 100% of the first core (20-40 sec) but without any affect to traffic volume. B. Unstable work of the server begins when we add such rules to the ruleset: ./ipfw pipe 10 config mask dst-ip 0xffffffff bw 5120Kbit/s ./ipfw add pipe 10 ip from any to 192.168.0.0/16 by these rules we assign the same bandwidth to each IP's from 192.168.0.0/16 (approx 20K in a whole) After entering rules the server some minutes works good, and we see that in this time RES figure grows (not fast) from 415M to 500M, and than RES jumps from about 510M to 540M and network traffic downs at least twice, kipfw takes 100%, large packet drops (up to 30%) and delay grows. root@bridge-netmap:/usr/local/etc/rc.d # netstat -bdh -w1 -I ix1 input ix1 output packets errs idrops bytes packets errs bytes colls drops 648K 0 0 762M 534K 0 110M 0 0 643K 0 0 755M 529K 0 111M 0 0 648K 0 0 763M 534K 0 112M 0 0 648K 0 0 760M 537K 0 113M 0 0 215K 0 0 240M 211K 0 35M 0 0 !!!! (rules were entered into ruleset) 220K 0 0 235M 210K 0 34M 0 0 212K 0 0 236M 211K 0 35M 0 0 215K 0 0 240M 212K 0 35M 0 0 May be there is any limit (for example 512Mb) of mem usage ? If yes - can it be increased ? We can give any additional information if it be useful for investigating of this issue. Azamat IT Dep AkNet ISP