From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 02:53:00 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8CB8106566B; Sun, 29 Jan 2012 02:53:00 +0000 (UTC) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF6AF8FC13; Sun, 29 Jan 2012 02:53:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0T2r08D060554; Sun, 29 Jan 2012 02:53:00 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0T2r0Eg060550; Sun, 29 Jan 2012 02:53:00 GMT (envelope-from csjp) Date: Sun, 29 Jan 2012 02:53:00 GMT Message-Id: <201201290253.q0T2r0Eg060550@freefall.freebsd.org> To: csjp@FreeBSD.org, freebsd-net@FreeBSD.org, csjp@FreeBSD.org From: csjp@FreeBSD.org Cc: Subject: Re: kern/164534: [bpf] net.bpf.zerocopy_enable=1 makes pflogd eat cpu and hang X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 02:53:01 -0000 Synopsis: [bpf] net.bpf.zerocopy_enable=1 makes pflogd eat cpu and hang Responsible-Changed-From-To: freebsd-net->csjp Responsible-Changed-By: csjp Responsible-Changed-When: Sun Jan 29 02:52:14 UTC 2012 Responsible-Changed-Why: Take, we have fixes for this, but not real sure we have a solution agreed upon yet. http://www.freebsd.org/cgi/query-pr.cgi?pr=164534 From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 04:19:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B461065672; Sun, 29 Jan 2012 04:19:44 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 7627D8FC0A; Sun, 29 Jan 2012 04:19:44 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrMEv-000ItR-If; Sun, 29 Jan 2012 04:19:42 +0000 Date: Sun, 29 Jan 2012 13:19:40 +0900 Message-ID: From: Randy Bush To: Marius Strobl In-Reply-To: <20120128213857.GB39861@alchemy.franken.de> References: <20120128121830.GA38513@alchemy.franken.de> <20120128131830.GZ44286@alchemy.franken.de> <20120128213857.GB39861@alchemy.franken.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Stable , FreeBSD Net Subject: Re: 9-stable - ifmedia_set: no match for 0x0/0xfffffff X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 04:19:45 -0000 > What happens if you set hw.bge.allow_asf to 0 and use auto-negotiation > on both sides? it works! the switch was already auto-neg, and i forced auto-neg on the server side. thanks. this was not pleasant. did i remember to whine that i am in tokyo and the server is on the beast coast of the states? :) i think a bit of a warning about hw.bge.allow_asf in UPDATING might help folk. thank you *very* much for your help. randy From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 07:13:23 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E5E106564A; Sun, 29 Jan 2012 07:13:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 81F0F8FC08; Sun, 29 Jan 2012 07:13:23 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0T75otE054565 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 29 Jan 2012 00:05:50 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 29 Jan 2012 00:05:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> To: Juli Mallett X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 29 Jan 2012 00:05:53 -0700 (MST) Cc: Aleksandr Rybalko , Stefan Bethke , freebsd-net@FreeBSD.org, Adrian Chadd , Aleksandr Rybalko , freebsd-arch@FreeBSD.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 07:13:23 -0000 On Jan 28, 2012, at 4:00 PM, Juli Mallett wrote: > It makes me wonder if the understanding of the relationship in FreeBSD > isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but > you can conceptualize of it as a child of the PHY, rather than the > parent of it, especially in systems with switch chipsets. Especially > in systems where there is a switch chipset attached to multiple MACs. >=20 > In that model, it makes sense to semi-generically attach a > CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) > to a MAC generically, but that doesn't meant that the switch itself is > attached generically to the MAC. I think that the main issue here is that we have an assumption that we = have a tree structure. However, it is more of a DAG across different = domains. The hierarchy works well when each device owns all the devices = below it and only interacted with them. Most devices are that way. = However, in the embedded world, there's lots of reach-accrosses that are = expected that break the model. Plus, MDIO is more than what we call mii/phy, so there's an imperfect = match there. Warner From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 09:38:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7BCD106566C; Sun, 29 Jan 2012 09:38:43 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E03F28FC0A; Sun, 29 Jan 2012 09:38:42 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:24ed:86dc:9f3b:9149]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 1861F4AC2D; Sun, 29 Jan 2012 13:38:39 +0400 (MSK) Date: Sun, 29 Jan 2012 13:38:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1076713525.20120129133839@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------5C7120A21F19B1B" Cc: jfv@FreeBSD.org, jhb@FreeBSD.org Subject: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 09:38:44 -0000 ------------5C7120A21F19B1B Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Freebsd-net. My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. It looks like undetected hardware hang-up: no packets could be sent or received, and no any output in dmesg or log files. Interface up/down with ifconfig and cable unplugging doesn't help: ifaces sees all these changes, but no packets could be sent/received anyway. I was forced to reboot server to make it work again. IT is rather old 8-STABLE (Oct 2011), but it sems, that last change in e1000 for 8-STABLE was r223675, in Jun 2011, so it is "fresh" sources (I don't believe, that r229147 is related). Output of `sysctl dev.em' when card is not working (but after some up/down events) is attached. NIC is: em0: port 0xd880-0xd89f mem 0x= fea40000-0xfea5ffff,0xfea7a000-0xfea7afff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:8c:75:03:0d em0@pci0:0:25:0: class=3D0x020000 card=3D0x82681043 chip=3D0x10bd808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class =3D network subclass =3D ethernet --=20 // Black Lion AKA Lev Serebryakov ------------5C7120A21F19B1B Content-Type: text/plain; name="sysctl-dev-em.txt" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="sysctl-dev-em.txt" ZGV2LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3 LjIuMwpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRpb246IHNsb3Q9MjUg ZnVuY3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4wLiVwbnBpbmZvOiB2 ZW5kb3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9 MHg4MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVtLjAu bnZtOiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50X2RlbGF5OiAwCmRl di5lbS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2ludF9kZWxheTogNjYK ZGV2LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfcHJvY2Vzc2luZ19s aW1pdDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0uMC5lZWVfY29udHJv bDogMApkZXYuZW0uMC5saW5rX2lycTogMApkZXYuZW0uMC5tYnVmX2FsbG9jX2ZhaWw6IDAK ZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWlsOiAwCmRldi5lbS4wLmRyb3BwZWQ6IDAKZGV2 LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVtLjAucnhfb3ZlcnJ1bnM6IDc3NDIKZGV2LmVt LjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVtLjAuZGV2aWNlX2NvbnRyb2w6IDE0Nzc0 NDQxNjAKZGV2LmVtLjAucnhfY29udHJvbDogNjcxNDE2MzQKZGV2LmVtLjAuZmNfaGlnaF93 YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0ZXI6IDY2OTIKZGV2LmVtLjAucXVldWUw LnR4ZF9oZWFkOiAxNTgKZGV2LmVtLjAucXVldWUwLnR4ZF90YWlsOiAxMjUKZGV2LmVtLjAu cXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1ZTAubm9fZGVzY19hdmFpbDogMApkZXYu ZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDM2MjQKZGV2LmVtLjAucXVldWUwLnJ4ZF90YWlsOiAz NjIzCmRldi5lbS4wLnF1ZXVlMC5yeF9pcnE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLmV4Y2Vz c19jb2xsOiAwCmRldi5lbS4wLm1hY19zdGF0cy5zaW5nbGVfY29sbDogMApkZXYuZW0uMC5t YWNfc3RhdHMubXVsdGlwbGVfY29sbDogMApkZXYuZW0uMC5tYWNfc3RhdHMubGF0ZV9jb2xs OiAwCmRldi5lbS4wLm1hY19zdGF0cy5jb2xsaXNpb25fY291bnQ6IDAKZGV2LmVtLjAubWFj X3N0YXRzLnN5bWJvbF9lcnJvcnM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnNlcXVlbmNlX2Vy cm9yczogMApkZXYuZW0uMC5tYWNfc3RhdHMuZGVmZXJfY291bnQ6IDM0MDQyNzEKZGV2LmVt LjAubWFjX3N0YXRzLm1pc3NlZF9wYWNrZXRzOiAxNDM2MTYKZGV2LmVtLjAubWFjX3N0YXRz LnJlY3Zfbm9fYnVmZjogMApkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl91bmRlcnNpemU6IDAK ZGV2LmVtLjAubWFjX3N0YXRzLnJlY3ZfZnJhZ21lbnRlZDogNzMKZGV2LmVtLjAubWFjX3N0 YXRzLnJlY3Zfb3ZlcnNpemU6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJlY3ZfamFiYmVyOiAw CmRldi5lbS4wLm1hY19zdGF0cy5yZWN2X2VycnM6IDE1NDUKZGV2LmVtLjAubWFjX3N0YXRz LmNyY19lcnJzOiAxNjEwCmRldi5lbS4wLm1hY19zdGF0cy5hbGlnbm1lbnRfZXJyczogMApk ZXYuZW0uMC5tYWNfc3RhdHMuY29sbF9leHRfZXJyczogNgpkZXYuZW0uMC5tYWNfc3RhdHMu eG9uX3JlY3ZkOiAzNTYwNjI0CmRldi5lbS4wLm1hY19zdGF0cy54b25fdHhkOiAwCmRldi5l bS4wLm1hY19zdGF0cy54b2ZmX3JlY3ZkOiA0MzU0MTMyOQpkZXYuZW0uMC5tYWNfc3RhdHMu eG9mZl90eGQ6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnRvdGFsX3BrdHNfcmVjdmQ6IDEzOTM2 NDUyMzgKZGV2LmVtLjAubWFjX3N0YXRzLmdvb2RfcGt0c19yZWN2ZDogMTM0NjQ2NDQ5OQpk ZXYuZW0uMC5tYWNfc3RhdHMuYmNhc3RfcGt0c19yZWN2ZDogMzA3NDQKZGV2LmVtLjAubWFj X3N0YXRzLm1jYXN0X3BrdHNfcmVjdmQ6IDg3NjMKZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2Zy YW1lc182NDogMApkZXYuZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzY1XzEyNzogMApkZXYu ZW0uMC5tYWNfc3RhdHMucnhfZnJhbWVzXzEyOF8yNTU6IDAKZGV2LmVtLjAubWFjX3N0YXRz LnJ4X2ZyYW1lc18yNTZfNTExOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfNTEy XzEwMjM6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc18xMDI0XzE1MjI6IDAKZGV2 LmVtLjAubWFjX3N0YXRzLmdvb2Rfb2N0ZXRzX3JlY3ZkOiAxNTc3NzEyOTY1MzQKZGV2LmVt LjAubWFjX3N0YXRzLmdvb2Rfb2N0ZXRzX3R4ZDogMzEwNTc5OTM3OTQwNApkZXYuZW0uMC5t YWNfc3RhdHMudG90YWxfcGt0c190eGQ6IDIyODk5MTQyNzgKZGV2LmVtLjAubWFjX3N0YXRz Lmdvb2RfcGt0c190eGQ6IDIyODk5MTQyNzgKZGV2LmVtLjAubWFjX3N0YXRzLmJjYXN0X3Br dHNfdHhkOiA0Nzc2CmRldi5lbS4wLm1hY19zdGF0cy5tY2FzdF9wa3RzX3R4ZDogMTAxNzkw CmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfNjQ6IDAKZGV2LmVtLjAubWFjX3N0YXRz LnR4X2ZyYW1lc182NV8xMjc6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4X2ZyYW1lc18xMjhf MjU1OiAwCmRldi5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfMjU2XzUxMTogMApkZXYuZW0u MC5tYWNfc3RhdHMudHhfZnJhbWVzXzUxMl8xMDIzOiAwCmRldi5lbS4wLm1hY19zdGF0cy50 eF9mcmFtZXNfMTAyNF8xNTIyOiAwCmRldi5lbS4wLm1hY19zdGF0cy50c29fdHhkOiA2NTIy NDA3ODkKZGV2LmVtLjAubWFjX3N0YXRzLnRzb19jdHhfZmFpbDogMApkZXYuZW0uMC5pbnRl cnJ1cHRzLmFzc2VydHM6IDEzNzUwNDEwMzEKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9wa3Rf dGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9hYnNfdGltZXI6IDAKZGV2LmVtLjAu aW50ZXJydXB0cy50eF9wa3RfdGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9hYnNf dGltZXI6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy50eF9xdWV1ZV9lbXB0eTogMApkZXYuZW0u MC5pbnRlcnJ1cHRzLnR4X3F1ZXVlX21pbl90aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0 cy5yeF9kZXNjX21pbl90aHJlc2g6IDAKZGV2LmVtLjAuaW50ZXJydXB0cy5yeF9vdmVycnVu OiAwCmRldi5lbS4wLndha2U6IDAK ------------5C7120A21F19B1B-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 11:14:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7389E1065672; Sun, 29 Jan 2012 11:14:55 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 189FE8FC08; Sun, 29 Jan 2012 11:14:53 +0000 (UTC) Received: by eekb47 with SMTP id b47so1236538eek.13 for ; Sun, 29 Jan 2012 03:14:53 -0800 (PST) Received: by 10.14.8.196 with SMTP id 44mr4216886eer.21.1327835692938; Sun, 29 Jan 2012 03:14:52 -0800 (PST) Received: from rnote.ddteam.net (238-239-92-178.pool.ukrtel.net. [178.92.239.238]) by mx.google.com with ESMTPS id e12sm56906377eea.5.2012.01.29.03.14.50 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 03:14:51 -0800 (PST) Date: Sun, 29 Jan 2012 13:14:37 +0200 From: Aleksandr Rybalko To: Juli Mallett Message-Id: <20120129131437.27981686.ray@ddteam.net> In-Reply-To: References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Stefan Bethke , freebsd-net@freebsd.org, Aleksandr, Rybalko , freebsd-arch@freebsd.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 11:14:55 -0000 On Sat, 28 Jan 2012 15:00:01 -0800 Juli Mallett wrote: > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko > wrote: > > As I see from your patch, mdio/miiproxy require special bits in MAC > > driver. When I design switch framework, I keeping in mind that > > MAC drivers should be standard as possible > > I don't understand why this is desirable in practice. It's a nice > theory, but it falls down when one thinks in depth about how Ethernet > interfaces are used and administered vs. how switches are used and > administered. What should media report? What should media changes > do? What is link status? Do you show the CPU-to-switch port, or all > switch ports? IMO, if we about why to make MAC driver more "standard", it is desired because most MAC, used in SoC's, used also in NIC cards or other SoC's which have no switch, but MII and MDIO pins to attach external PHY. Real example bfe(4), it is supported long ago as PCI card, but also found in BCM4701 family SoC's. In BCM5354 it attached to embedded switch. In BCM5836 it is two independent MAC. Last one used in D-Link DIR-330, there is one MAC attached to PHY, second to BCM5325 switch). Since BCM4701 family have internal SSB bus, a.k.a siba(4), I add only siba(4) bus glue. So if we able to attach switch driver to regular MAC drivers it will make our life simpler :) > > It makes me wonder if the understanding of the relationship in FreeBSD > isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but > you can conceptualize of it as a child of the PHY, rather than the > parent of it, especially in systems with switch chipsets. Especially > in systems where there is a switch chipset attached to multiple MACs. > > In that model, it makes sense to semi-generically attach a > CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) > to a MAC generically, but that doesn't meant that the switch itself is > attached generically to the MAC. > > There are a lot of switches out there that don't look or act much like > MII-driven PHYs, but which are connected over MDIO, as I've tried to > stress before. Yeah, for that case Marius commit phymask support for our miibus, to not touch reserved PHY IDs. >I hope there will be as much separation between the > MII work that is being done and the switch work that is being done as > possible. I think anything else will prove rapidly-obsolete and > perhaps even obstructive as soon as anyone seeks to add support for > more switch chipsets to FreeBSD. > > I suppose the most likely reality, though, is that people simply won't > add switch support to FreeBSD, and will administer them out-of-band > from userland, using gross kernel shims. That is probably true > whether any of the currently-outstanding work is committed or not, > unfortunately :( I just hope we'll end up with something flexible > enough, broad enough in applicability, narrow enough in requirements, > etc., that we'll have feature-rich support for a few chipsets in tree > that work in sufficiently-different manners that they can be models > for other drivers in the future. > > Thanks, > Juli. Thank you for comments Juli! WBW -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 12:26:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8BF8106566C; Sun, 29 Jan 2012 12:26:02 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 915038FC12; Sun, 29 Jan 2012 12:26:02 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C7D632772C; Sun, 29 Jan 2012 12:26:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sun, 29 Jan 2012 13:26:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> To: Juli Mallett X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:26:03 -0000 Am 29.01.2012 um 00:00 schrieb Juli Mallett: > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko = wrote: >> As I see from your patch, mdio/miiproxy require special bits in MAC >> driver. When I design switch framework, I keeping in mind that >> MAC drivers should be standard as possible >=20 > I don't understand why this is desirable in practice. It's a nice > theory, but it falls down when one thinks in depth about how Ethernet > interfaces are used and administered vs. how switches are used and > administered. What should media report? What should media changes > do? What is link status? Do you show the CPU-to-switch port, or all > switch ports? The main thrust here is to reuse the existing PHY code to be able to = configure the PHYs that are embedded in the switch chips. To confuse = things, one of these PHYs might be connected to the SoCs ethernet = interface via MII, GMII, etc. To confuse things further, these PHYs are = controlled by an MDIO bus that has it's master in the switch chip, while = the switch chip is a slave to the MDIO master in the ethernet = controller. The goal is to be able to configure the switch ports and set media on = one of them, for example. That code path could be entirely independent = from the ethernet infrastructure, if dev/miibus didn't require if_media = and hence a struct ifnet. This discussion is also about how to deal = with this entanglement. The MII connection between the ethernet controller and the switch chip = (usually referred to as the "CPU" port) is hard-coded and has no media = settings, so there's no question what if_media settings should be = presented on the interface. > are a lot of switches out there that don't look or act much like > MII-driven PHYs, but which are connected over MDIO, as I've tried to > stress before. I hope there will be as much separation between the > MII work that is being done and the switch work that is being done as > possible. I think anything else will prove rapidly-obsolete and > perhaps even obstructive as soon as anyone seeks to add support for > more switch chipsets to FreeBSD. >=20 > I suppose the most likely reality, though, is that people simply won't > add switch support to FreeBSD, and will administer them out-of-band > from userland, using gross kernel shims. That is probably true > whether any of the currently-outstanding work is committed or not, > unfortunately :( I just hope we'll end up with something flexible > enough, broad enough in applicability, narrow enough in requirements, > etc., that we'll have feature-rich support for a few chipsets in tree > that work in sufficiently-different manners that they can be models > for other drivers in the future. Which is a valid approach from a vendor's viewpoint. The reason we're = talking is to try and make it easier to write a switch driver for this = framework than roll your own hack. :-) Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 12:44:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 128CF1065672; Sun, 29 Jan 2012 12:44:31 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3B488FC14; Sun, 29 Jan 2012 12:44:28 +0000 (UTC) Received: by eaaa14 with SMTP id a14so1254080eaa.13 for ; Sun, 29 Jan 2012 04:44:28 -0800 (PST) Received: by 10.213.102.12 with SMTP id e12mr2259927ebo.128.1327841067864; Sun, 29 Jan 2012 04:44:27 -0800 (PST) Received: from rnote.ddteam.net (238-239-92-178.pool.ukrtel.net. [178.92.239.238]) by mx.google.com with ESMTPS id t11sm30969724eea.10.2012.01.29.04.44.25 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 04:44:27 -0800 (PST) Date: Sun, 29 Jan 2012 14:44:13 +0200 From: Aleksandr Rybalko To: Stefan Bethke Message-Id: <20120129144413.a8045873.ray@ddteam.net> In-Reply-To: <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Juli Mallett , FreeBSD Net , Adrian Chadd , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:44:31 -0000 On Sun, 29 Jan 2012 13:26:00 +0100 Stefan Bethke wrote: > Am 29.01.2012 um 00:00 schrieb Juli Mallett: > > > On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko > > wrote: > >> As I see from your patch, mdio/miiproxy require special bits in MAC > >> driver. When I design switch framework, I keeping in mind that > >> MAC drivers should be standard as possible > > > > I don't understand why this is desirable in practice. It's a nice > > theory, but it falls down when one thinks in depth about how > > Ethernet interfaces are used and administered vs. how switches are > > used and administered. What should media report? What should > > media changes do? What is link status? Do you show the > > CPU-to-switch port, or all switch ports? > > The main thrust here is to reuse the existing PHY code to be able to > configure the PHYs that are embedded in the switch chips. To confuse > things, one of these PHYs might be connected to the SoCs ethernet > interface via MII, GMII, etc. To confuse things further, these PHYs > are controlled by an MDIO bus that has it's master in the switch > chip, while the switch chip is a slave to the MDIO master in the > ethernet controller. > > The goal is to be able to configure the switch ports and set media on > one of them, for example. That code path could be entirely > independent from the ethernet infrastructure, if dev/miibus didn't > require if_media and hence a struct ifnet. This discussion is also > about how to deal with this entanglement. > > The MII connection between the ethernet controller and the switch > chip (usually referred to as the "CPU" port) is hard-coded and has no > media settings, so there's no question what if_media settings should > be presented on the interface. Most switches (AR8x16 for example) have configurable MII port, so you can choose to use MII/RMII/GMII/RGMII. If you decide to use MII media can not be higher than 100baseTX. So it is possible to use some auto-negotiation here. > > > are a lot of switches out there that don't look or act much like > > MII-driven PHYs, but which are connected over MDIO, as I've tried to > > stress before. I hope there will be as much separation between the > > MII work that is being done and the switch work that is being done > > as possible. I think anything else will prove rapidly-obsolete and > > perhaps even obstructive as soon as anyone seeks to add support for > > more switch chipsets to FreeBSD. > > > > I suppose the most likely reality, though, is that people simply > > won't add switch support to FreeBSD, and will administer them > > out-of-band from userland, using gross kernel shims. That is > > probably true whether any of the currently-outstanding work is > > committed or not, unfortunately :( I just hope we'll end up with > > something flexible enough, broad enough in applicability, narrow > > enough in requirements, etc., that we'll have feature-rich support > > for a few chipsets in tree that work in sufficiently-different > > manners that they can be models for other drivers in the future. > > Which is a valid approach from a vendor's viewpoint. The reason > we're talking is to try and make it easier to write a switch driver > for this framework than roll your own hack. :-) > > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > > -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 12:49:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D800A106566B; Sun, 29 Jan 2012 12:49:26 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDE38FC0C; Sun, 29 Jan 2012 12:49:26 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 8E6AC27835; Sun, 29 Jan 2012 12:49:25 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120129144413.a8045873.ray@ddteam.net> Date: Sun, 29 Jan 2012 13:49:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DD20168-B908-4737-9983-3570E2BF32D3@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <045BA867-B83B-4C2E-AB4F-4D09E49B7F3D@lassitu.de> <20120129144413.a8045873.ray@ddteam.net> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1251.1) Cc: Juli Mallett , FreeBSD Net , Adrian Chadd , Aleksandr Rybalko , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:49:26 -0000 Am 29.01.2012 um 13:44 schrieb Aleksandr Rybalko: >> The MII connection between the ethernet controller and the switch >> chip (usually referred to as the "CPU" port) is hard-coded and has no >> media settings, so there's no question what if_media settings should >> be presented on the interface. >=20 > Most switches (AR8x16 for example) have configurable MII port, so you > can choose to use MII/RMII/GMII/RGMII. If you decide to use MII > media can not be higher than 100baseTX. So it is possible to use some > auto-negotiation here. The point is that the admin has no need to change it, it's hard coded in = the driver or statically configured via hints. And for all of this = discussion, I'm using MII as a synonym for all xMII busses. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 12:55:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E19381065680; Sun, 29 Jan 2012 12:55:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABF88FC0C; Sun, 29 Jan 2012 12:55:01 +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.5/8.14.4) with ESMTP id q0TCsxVV068919; Sun, 29 Jan 2012 07:54:59 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F2541A3.8020401@sentex.net> Date: Sun, 29 Jan 2012 07:54:59 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: lev@freebsd.org References: <1076713525.20120129133839@serebryakov.spb.ru> In-Reply-To: <1076713525.20120129133839@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: jfv@freebsd.org, freebsd-net@freebsd.org, jhb@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:55:02 -0000 On 1/29/2012 4:38 AM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > My home server lost connection on em0 this night again. It was > persistent problem some times ago, but with version 7.2.3 it is first > time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) ---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 Sun Jan 29 13:14:44 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804E51065672; Sun, 29 Jan 2012 13:14:44 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 3930A8FC0A; Sun, 29 Jan 2012 13:14:44 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id EE9D827A42; Sun, 29 Jan 2012 13:14:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sun, 29 Jan 2012 14:14:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 13:14:44 -0000 Am 29.01.2012 um 08:05 schrieb Warner Losh: > I think that the main issue here is that we have an assumption that we = have a tree structure. However, it is more of a DAG across different = domains. The hierarchy works well when each device owns all the devices = below it and only interacted with them. Most devices are that way. = However, in the embedded world, there's lots of reach-accrosses that are = expected that break the model. What do people think would be a good approach to solve the concrete = issue without too much hackery? Aleksandr and I have presented three = possible approaches: 1. have a PHY driver that acts as a proxy and talks to a separate MDIO = master 2. have a proxy between the ethernet driver and the miibus driver 3. modify miibus to have a separate device for mediachg() etc. All three suffer from a dependency problem: miibus attachment can only = complete successfully when both the ethernet driver and the mdio driver = have been attached. In the current model, the ethernet driver provides = both the MDIO access as well as the target for the mediachg, etc. = messages, so there's no attachment ordering issue. In my miiproxy patch (2.), it is necessary for the ethernet driver to = cooperate in this delayed attachment, by splitting out the miibus = attachment from the device_attach method implementation. That's a = fairly intrusive change, and that would need to be made to any ethernet = driver that is to support such a split MDIO/MII setup. I tried delaying just the call to mii_attach(), but it seems that = interacts badly with an already attached interface. Specifically, I got = a non-working interface when I tried to call mii_attach() long after = if_etherattach(). Additionally, if_arge (and probably most other = drivers) assumes that the miibus is attached after they've successfully = attached themselves, and subsequently runs into null pointer issues when = it isn't. Would it be possible to attach miibus without having a working PHY, and = only attach the PHYs once the MDIO device has been attached? For the mips/atheros platforms, we could introduce ordering hints for = nexus to make sure the mdio driver gets attached before the arge's. = That's a fairly small changes (two lines), and does work, but it's more = a hack than a general solution. With my proposed change to miibus = (split devices), that would bring down the necessary changes to just a = handful of lines. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 15:32:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FE75106564A; Sun, 29 Jan 2012 15:32:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id ED6358FC0C; Sun, 29 Jan 2012 15:32:07 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0TFW0AG044415; Sun, 29 Jan 2012 16:32:01 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0TFVxEk044414; Sun, 29 Jan 2012 16:31:59 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 16:31:59 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120129153159.GA44362@alchemy.franken.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 15:32:08 -0000 On Sun, Jan 29, 2012 at 02:14:42PM +0100, Stefan Bethke wrote: > Am 29.01.2012 um 08:05 schrieb Warner Losh: > > > I think that the main issue here is that we have an assumption that we have a tree structure. However, it is more of a DAG across different domains. The hierarchy works well when each device owns all the devices below it and only interacted with them. Most devices are that way. However, in the embedded world, there's lots of reach-accrosses that are expected that break the model. > > What do people think would be a good approach to solve the concrete issue without too much hackery? Aleksandr and I have presented three possible approaches: > 1. have a PHY driver that acts as a proxy and talks to a separate MDIO master > 2. have a proxy between the ethernet driver and the miibus driver > 3. modify miibus to have a separate device for mediachg() etc. > > All three suffer from a dependency problem: miibus attachment can only complete successfully when both the ethernet driver and the mdio driver have been attached. In the current model, the ethernet driver provides both the MDIO access as well as the target for the mediachg, etc. messages, so there's no attachment ordering issue. > > In my miiproxy patch (2.), it is necessary for the ethernet driver to cooperate in this delayed attachment, by splitting out the miibus attachment from the device_attach method implementation. That's a fairly intrusive change, and that would need to be made to any ethernet driver that is to support such a split MDIO/MII setup. > > I tried delaying just the call to mii_attach(), but it seems that interacts badly with an already attached interface. Specifically, I got a non-working interface when I tried to call mii_attach() long after if_etherattach(). Additionally, if_arge (and probably most other drivers) assumes that the miibus is attached after they've successfully attached themselves, and subsequently runs into null pointer issues when it isn't. > > Would it be possible to attach miibus without having a working PHY, and only attach the PHYs once the MDIO device has been attached? This would break the concept of knowing that when mii_attach() returns success you can talk to all the hardware necessary to present a working interface. So you'll just need another way instead to ensure that there's also at least a single PHY before attaching the whole thing which I don't see getting us further with the attach ordering problem of the MDIO provider. > > For the mips/atheros platforms, we could introduce ordering hints for nexus to make sure the mdio driver gets attached before the arge's. That's a fairly small changes (two lines), and does work, but it's more a hack than a general solution. With my proposed change to miibus (split devices), that would bring down the necessary changes to just a handful of lines. > How about adding the MDIO provider via multi-pass probing? That idea of that model was to attach things like drivers for interrupt controllers before any other driver that requires that resource. This seems like a perfect match here and requires neither a specific hack to the nexus (the platform generally needs to be multi-pass aware though and the thing enabled in subr_bus.c) nor a hack to miibus(4). We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place. Marius From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 16:00:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BEF81065678; Sun, 29 Jan 2012 16:00:41 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 537CC8FC18; Sun, 29 Jan 2012 16:00:41 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B69E927CAD; Sun, 29 Jan 2012 16:00:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120129153159.GA44362@alchemy.franken.de> Date: Sun, 29 Jan 2012 17:00:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 16:00:41 -0000 Am 29.01.2012 um 16:31 schrieb Marius Strobl: > How about adding the MDIO provider via multi-pass probing? That idea > of that model was to attach things like drivers for interrupt = controllers > before any other driver that requires that resource. This seems like a > perfect match here and requires neither a specific hack to the nexus > (the platform generally needs to be multi-pass aware though and the > thing enabled in subr_bus.c) nor a hack to miibus(4). Please recall the devinfo graph that I posted earlier. The PHY arge0 = needs to talk to is attached to the MDIO master on the switch = controller, which in turn is attached to GE1's MDIO master. This would = require early attachment of the switch, in turn requiring early = attachment of arge_mdio, in turn requiring early attachment of = mips/mips/nexus. > We really need > to find a proper way of dealing with the constraints of the embedded- > world rather than to sprinkle hacks all over the place. Why is the above is less of a hack than making the ordering in nexus = configurable through a hint? Stefan --=20 Stefan Bethke Fon +49 151 14070811 diff --git a/sys/mips/mips/nexus.c b/sys/mips/mips/nexus.c index b51357d..c4c207a 100644 --- a/sys/mips/mips/nexus.c +++ b/sys/mips/mips/nexus.c @@ -240,8 +240,11 @@ nexus_hinted_child(device_t bus, const char *dname, = int dunit) int result; int irq; int mem_hints_count; + int order; =20 - child =3D BUS_ADD_CHILD(bus, 0, dname, dunit); + order =3D 1000; /* there should be a define for the default = order */ + resource_int_value(dname, dunit, "order", &order); + child =3D BUS_ADD_CHILD(bus, order, dname, dunit); if (child =3D=3D NULL) return; From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 16:19:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B98106566C; Sun, 29 Jan 2012 16:19:44 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 374F08FC18; Sun, 29 Jan 2012 16:19:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0TGJcXQ044634; Sun, 29 Jan 2012 17:19:38 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0TGJcnA044633; Sun, 29 Jan 2012 17:19:38 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 17:19:38 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120129161938.GD39861@alchemy.franken.de> References: <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 16:19:44 -0000 On Sun, Jan 29, 2012 at 05:00:38PM +0100, Stefan Bethke wrote: > Am 29.01.2012 um 16:31 schrieb Marius Strobl: > > > How about adding the MDIO provider via multi-pass probing? That idea > > of that model was to attach things like drivers for interrupt controllers > > before any other driver that requires that resource. This seems like a > > perfect match here and requires neither a specific hack to the nexus > > (the platform generally needs to be multi-pass aware though and the > > thing enabled in subr_bus.c) nor a hack to miibus(4). > > Please recall the devinfo graph that I posted earlier. The PHY arge0 needs to talk to is attached to the MDIO master on the switch controller, which in turn is attached to GE1's MDIO master. This would require early attachment of the switch, in turn requiring early attachment of arge_mdio, in turn requiring early attachment of mips/mips/nexus. > Yes > > We really need > > to find a proper way of dealing with the constraints of the embedded- > > world rather than to sprinkle hacks all over the place. > > Why is the above is less of a hack than making the ordering in nexus configurable through a hint? > If it's generally true that driver A must be attached before driver B as B has a dependency on A than this should be expressed and configured in the drivers themselves and not need an extra hint to configure it at the runtime of the kernel. Marius From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 16:21:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3635106564A; Sun, 29 Jan 2012 16:21:54 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 585B68FC1E; Sun, 29 Jan 2012 16:21:54 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 7352827D58; Sun, 29 Jan 2012 16:21:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120129161938.GD39861@alchemy.franken.de> Date: Sun, 29 Jan 2012 17:21:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5785C7EF-B886-459B-911C-870A4594AC4C@lassitu.de> References: <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> <20120129161938.GD39861@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 16:21:54 -0000 Am 29.01.2012 um 17:19 schrieb Marius Strobl: >>> We really need >>> to find a proper way of dealing with the constraints of the = embedded- >>> world rather than to sprinkle hacks all over the place. >>=20 >> Why is the above is less of a hack than making the ordering in nexus = configurable through a hint? >>=20 >=20 > If it's generally true that driver A must be attached before driver > B as B has a dependency on A than this should be expressed and > configured in the drivers themselves and not need an extra hint to > configure it at the runtime of the kernel. Except that it is not generally true, but only in specific = configurations. Other boards have other combinations of devices. The = Atheros family of switches is available both embedded into certain SoC = as well as separate silicon. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 16:43:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A6F1106564A for ; Sun, 29 Jan 2012 16:43:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB9738FC18 for ; Sun, 29 Jan 2012 16:43:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:24ed:86dc:9f3b:9149]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6929A4AC31; Sun, 29 Jan 2012 20:43:29 +0400 (MSK) Date: Sun, 29 Jan 2012 20:43:28 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1146850915.20120129204328@serebryakov.spb.ru> To: Mike Tancsa In-Reply-To: <4F2541A3.8020401@sentex.net> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:43:31 -0000 Hello, Mike. You wrote 29 =FF=ED=E2=E0=F0=FF 2012 =E3., 16:54:59: >> My home server lost connection on em0 this night again. It was >> persistent problem some times ago, but with version 7.2.3 it is first >> time, but with worse symptoms. > 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon = :) I'm afraid, that "MFC'd" means "to 9-STABLE" now :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 17:32:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A25BF106564A; Sun, 29 Jan 2012 17:32:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 17F1B8FC13; Sun, 29 Jan 2012 17:32:22 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0THWHLE044852; Sun, 29 Jan 2012 18:32:17 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0THWHrX044851; Sun, 29 Jan 2012 18:32:17 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 18:32:17 +0100 From: Marius Strobl To: Stefan Bethke Message-ID: <20120129173217.GF39861@alchemy.franken.de> References: <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> <3B5A749B-9553-4152-9441-3F343BA219FB@lassitu.de> <20120129161938.GD39861@alchemy.franken.de> <5785C7EF-B886-459B-911C-870A4594AC4C@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5785C7EF-B886-459B-911C-870A4594AC4C@lassitu.de> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Aleksandr Rybalko , Adrian Chadd , Warner Losh , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 17:32:23 -0000 On Sun, Jan 29, 2012 at 05:21:52PM +0100, Stefan Bethke wrote: > > Am 29.01.2012 um 17:19 schrieb Marius Strobl: > > >>> We really need > >>> to find a proper way of dealing with the constraints of the embedded- > >>> world rather than to sprinkle hacks all over the place. > >> > >> Why is the above is less of a hack than making the ordering in nexus configurable through a hint? > >> > > > > If it's generally true that driver A must be attached before driver > > B as B has a dependency on A than this should be expressed and > > configured in the drivers themselves and not need an extra hint to > > configure it at the runtime of the kernel. > > Except that it is not generally true, but only in specific configurations. Other boards have other combinations of devices. The Atheros family of switches is available both embedded into certain SoC as well as separate silicon. > It still seems to be true to me that as soon as you have a separate MDIO driver that this one needs to be attached before any Ethernet, switch or whatever driver that needs to talk via the MDIO lines of the former. Similarly, if the switch attaches to an MDIO instance directly, that switch would need to be attached before the Ethernet driver (if there is one) that the switch is the MDIO master for (this isn't exactly the problematic arge-case). Multi-pass is per driver module, so if the switch attaches to a "regular" Ethernet driver providing both the MAC and the MDIO master instead, you can leave the default probe order and attach the switch after the Ethernet driver. So for the problematic arge-case you would attach the MDIO driver first (corresponding to the MDIO of arge1), then the switch to the MDIO driver and both arge0 and arge1 in whatever order last. Allowing that one special case to work properly shouldn't interfere with other device combinations as it basically boils down to the presence of a separate MDIO instance. Actually that should also work just fine when the MDIO master sits on the IIC bus as that again would mean that it needs to be attached before a Ethernet or switch driver can use it. Marius From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 18:21:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39704106566B for ; Sun, 29 Jan 2012 18:21:43 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 920C78FC0C for ; Sun, 29 Jan 2012 18:21:42 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so3635529wgb.31 for ; Sun, 29 Jan 2012 10:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yGUJqg1q1kFWF6mcNX4XZMwNoGMTBm5GDGFbnVGyfn0=; b=GNk/qSMqOgDeHxlfN02sSP0w2s0ckkQG71/xM18NOKDMsm2uLhfG8PXRQo055ETSHR LxfNO8ydfp31X+C5YkJabLRDb5A4Fg+163GcNXuwilHU8KlVIXEXmYBCN99QbU3CIsob 7jB0ELEgC1XRwGnXMlnBQ1YBA6Qkznz9eIM7E= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr28925816wib.3.1327861301406; Sun, 29 Jan 2012 10:21:41 -0800 (PST) Received: by 10.180.75.137 with HTTP; Sun, 29 Jan 2012 10:21:41 -0800 (PST) In-Reply-To: <1146850915.20120129204328@serebryakov.spb.ru> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> Date: Sun, 29 Jan 2012 10:21:41 -0800 Message-ID: From: Jack Vogel To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 18:21:43 -0000 No, I told Mike I'd get it into 8.x, have just been busy, but will try and get it pushed up in the queue. Jack 2012/1/29 Lev Serebryakov > Hello, Mike. > You wrote 29 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2012 =D0=B3., 16:54:59: > > >> My home server lost connection on em0 this night again. It was > >> persistent problem some times ago, but with version 7.2.3 it is first > >> time, but with worse symptoms. > > 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soo= n > :) > I'm afraid, that "MFC'd" means "to 9-STABLE" now :( > > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 18:47:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9A61065672 for ; Sun, 29 Jan 2012 18:47:15 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6296E8FC08 for ; Sun, 29 Jan 2012 18:47:14 +0000 (UTC) Received: by werm13 with SMTP id m13so1740462wer.13 for ; Sun, 29 Jan 2012 10:47:14 -0800 (PST) Received: by 10.180.81.35 with SMTP id w3mr22890510wix.10.1327862834181; Sun, 29 Jan 2012 10:47:14 -0800 (PST) Received: from dfleuriot.local ([82.241.189.111]) by mx.google.com with ESMTPS id q2sm13419727wiy.7.2012.01.29.10.47.12 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 10:47:13 -0800 (PST) Message-ID: <4F25942C.9080006@my.gd> Date: Sun, 29 Jan 2012 19:47:08 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 18:47:15 -0000 On 1/29/12 7:21 PM, Jack Vogel wrote: > No, I told Mike I'd get it into 8.x, have just been busy, but will try > and get it pushed up in the queue. > > Jack > > > 2012/1/29 Lev Serebryakov > >> Hello, Mike. >> You wrote 29 января 2012 г., 16:54:59: >> >>>> My home server lost connection on em0 this night again. It was >>>> persistent problem some times ago, but with version 7.2.3 it is first >>>> time, but with worse symptoms. >>> 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon >> :) >> I'm afraid, that "MFC'd" means "to 9-STABLE" now :( >> >> >> -- >> // Black Lion AKA Lev Serebryakov >> Hello Jack, Any chance to get this in 8.3-RELEASE ? I'm afraid we don't track -STABLE, at work. From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 19:00:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EBF1065675; Sun, 29 Jan 2012 19:00:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 66D188FC0A; Sun, 29 Jan 2012 19:00:23 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3624036vcm.13 for ; Sun, 29 Jan 2012 11:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=S+16ggzHz2I9dV8lc5XXjT/wxLTJd8WnLPIbAgQx6NM=; b=nQwbq6s1P0vfu2yKG9gxhK4U6G5xnzDS/rRt91+IqRA7FuH0ArJXxTJf7eqOy64gpH Q8DnF/y8gRJ2IG6AOGKM9YOFiu3bicIqG+FMQ8sOTQlZKJcBWysRT9+I+rnPG2kdhg9p zzfjB12QUTk1RPlio628QMmGlh/xSsjBjJvAE= MIME-Version: 1.0 Received: by 10.220.156.199 with SMTP id y7mr4940381vcw.2.1327863622709; Sun, 29 Jan 2012 11:00:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.172.37 with HTTP; Sun, 29 Jan 2012 11:00:22 -0800 (PST) In-Reply-To: <20120129153159.GA44362@alchemy.franken.de> References: <20120120221319.ca8b631f.ray@freebsd.org> <30A45A1E-CA13-4AC8-86FB-F8E06301D1F6@lassitu.de> <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> Date: Sun, 29 Jan 2012 11:00:22 -0800 X-Google-Sender-Auth: -AkCx4Pg7npYgNDM18SU2ksap2M Message-ID: From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Aleksandr Rybalko , Stefan Bethke , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 19:00:28 -0000 I think for switches, that doesn't necessarily hold. ie, mii_attach() for single-PHY devices may work that way, but the weird and wonderful world of embedded switch SoC's doesn't. You're lucky in most instances since the bootloader does give you a mostly-working switch config. But I doubt that's a guarantee on all platforms. So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ necessarily presenting a working PHY may be acceptable. For now it's going to be a subset, to having it export an MDIO bus and doing late MII attachment may not be as architecturally "no-no" as I interpret your post. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 19:51:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00139106566B for ; Sun, 29 Jan 2012 19:51:53 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 810508FC13 for ; Sun, 29 Jan 2012 19:51:53 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so2967116wgb.1 for ; Sun, 29 Jan 2012 11:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aA7xK+SkIJ7GFrcG+2aSoiwEQ3W7hvXqRRYFTb3MZUg=; b=cUy/iBGFRRqlntd1Cghx1BG02UqfsgL9rhP2Xy4ISVSApoBYQKBeMZKDw5Rkhifn4S 5x6XNbcxvmVnHa3OBxQY1hciYVv6D80IkpYvFpb0CM+iOeVsePcgxEXPod+OEYgEl4Xq G8FDgL6G80vrdXWS9KpXTREfa+Aj2fDrxXivA= MIME-Version: 1.0 Received: by 10.180.106.202 with SMTP id gw10mr30185431wib.3.1327866711111; Sun, 29 Jan 2012 11:51:51 -0800 (PST) Received: by 10.180.75.137 with HTTP; Sun, 29 Jan 2012 11:51:51 -0800 (PST) In-Reply-To: <4F25942C.9080006@my.gd> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> <4F25942C.9080006@my.gd> Date: Sun, 29 Jan 2012 11:51:51 -0800 Message-ID: From: Jack Vogel To: Damien Fleuriot Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 19:51:54 -0000 Yes, the whole reason to get it into that stable is to make the 8.3 release= . Jack On Sun, Jan 29, 2012 at 10:47 AM, Damien Fleuriot wrote: > On 1/29/12 7:21 PM, Jack Vogel wrote: > > No, I told Mike I'd get it into 8.x, have just been busy, but will try > > and get it pushed up in the queue. > > > > Jack > > > > > > 2012/1/29 Lev Serebryakov > > > >> Hello, Mike. > >> You wrote 29 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2012 =D0=B3., 16:54:= 59: > >> > >>>> My home server lost connection on em0 this night again. It was > >>>> persistent problem some times ago, but with version 7.2.3 it is firs= t > >>>> time, but with worse symptoms. > >>> 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd > soon > >> :) > >> I'm afraid, that "MFC'd" means "to 9-STABLE" now :( > >> > >> > >> -- > >> // Black Lion AKA Lev Serebryakov > >> > > > Hello Jack, > > > Any chance to get this in 8.3-RELEASE ? > > I'm afraid we don't track -STABLE, at work. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jan 29 22:13:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01AF1065787; Sun, 29 Jan 2012 22:13:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 321A58FC17; Sun, 29 Jan 2012 22:13:18 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0TMDGq3046343; Sun, 29 Jan 2012 23:13:17 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0TMDGhq046342; Sun, 29 Jan 2012 23:13:16 +0100 (CET) (envelope-from marius) Date: Sun, 29 Jan 2012 23:13:16 +0100 From: Marius Strobl To: Adrian Chadd Message-ID: <20120129221316.GG39861@alchemy.franken.de> References: <20120122195130.360261ce.ray@freebsd.org> <0E31FEC4-963D-4AC8-9AB7-EE6D6D7F86EE@lassitu.de> <20120129001251.7e4cfe83.ray@ddteam.net> <81B88904-6894-4AC3-80F3-2866216E494B@lassitu.de> <20120129153159.GA44362@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Aleksandr Rybalko , Stefan Bethke , FreeBSD-arch Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 22:13:19 -0000 On Sun, Jan 29, 2012 at 11:00:22AM -0800, Adrian Chadd wrote: > I think for switches, that doesn't necessarily hold. Err, what exactly doesn't hold? The suggestion about using multi-pass probing was just for the case when there's a separate MDIO master other drivers depend on. The latter would just use the default ordering (unless there are again ordering constraints whithin them). So if there's no separate MDIO master driver invovled that is attached first, the other drivers would still just be attached in the default ordering. > > ie, mii_attach() for single-PHY devices may work that way, but the weird What way? > and wonderful world of embedded switch SoC's doesn't. You're lucky in most > instances since the bootloader does give you a mostly-working switch > config. But I doubt that's a guarantee on all platforms. > > So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ > necessarily presenting a working PHY may be acceptable. For now it's going If there isn't a single working PHY, why would one want to attach miibus(4) in the first place? What is about the opposite case, when all you have is a MDIO master and a switch connected to it, but no MAC on the MII lines of the switch? > to be a subset, to having it export an MDIO bus and doing late MII > attachment may not be as architecturally "no-no" as I interpret your post. > Originally, Stefan said that he wants to find a way to support all the odd combinations found in the embedded-world and I try to come up with model that is able to do that without needing hacks and hints left and right. As imp@ said, interrupt controllers and GPIO basically suffer the same dependency constraints across otherwise unrelated devices there, so we really should find a way to properly deal with that situation without again needing another set of hacks and hints in other types of drivers. As for MDIO you actually can have another layer of dependencies between MDIO master, Ethernet switch and PHY, f.e. at work we use a single MDIO master and switch it to different slave busses using a multiplexer managed via GPIO ... not that I'd ever wanted to support this via generic means in FreeBSD. Marius From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 04:10:47 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 560C6106566B; Mon, 30 Jan 2012 04:10:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 278D48FC08; Mon, 30 Jan 2012 04:10:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0U4AlVW086333; Mon, 30 Jan 2012 04:10:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0U4Alfw086329; Mon, 30 Jan 2012 04:10:47 GMT (envelope-from linimon) Date: Mon, 30 Jan 2012 04:10:47 GMT Message-Id: <201201300410.q0U4Alfw086329@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164569: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 04:10:47 -0000 Old Synopsis: msk network driver cause freeze in FreeBSD 9.0 i386 New Synopsis: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 30 04:10:16 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 11:07:43 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8D11106566B for ; Mon, 30 Jan 2012 11:07:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C55AA8FC23 for ; Mon, 30 Jan 2012 11:07:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UB7h6M005483 for ; Mon, 30 Jan 2012 11:07:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UB7gTH005481 for freebsd-net@FreeBSD.org; Mon, 30 Jan 2012 11:07:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Jan 2012 11:07:42 GMT Message-Id: <201201301107.q0UB7gTH005481@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 11:07:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 386 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 11:08:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C2381065672 for ; Mon, 30 Jan 2012 11:08:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 138F78FC24 for ; Mon, 30 Jan 2012 11:08:47 +0000 (UTC) Received: from [82.113.106.85] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Rrp6M-0003Jy-I9 for freebsd-net@freebsd.org; Mon, 30 Jan 2012 12:08:46 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q0UB9Lmx001286 for ; Mon, 30 Jan 2012 12:09:21 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q0UB9KOq001285 for freebsd-net@freebsd.org; Mon, 30 Jan 2012 12:09:20 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Mon, 30 Jan 2012 12:09:20 +0100 From: Matthias Apitz To: freebsd-net@freebsd.org Message-ID: <20120130110919.GA1249@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.106.85 Subject: UMTS Huawei monitor X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:08:48 -0000 Hello, I'm used to connect my FreeBSD laptop or netbooks to Internet using Huawei USB modems (E220 or E1750) with good results, if the networks coverage of the provider is good enough in the place in question. While monitoring my modems and searching around in Google I see that the modems are providing not only the port used by the ppp(8) daemon, in my case /dev/cuaU0.0, but also some additional monitor port, the E1750 as /dev/cuaU0.3. If you just hook a terminal or kermit(1) to that port you see from time to time lines like this one: ^RSSI: 11 which gives the signal quality in a range from 0 (poor) to 31 (best) and in addition every 2 seconds a line of: ^DSFLOWRPT:00000B3A,00000054,00000054,00000000001B0785,0000000000573ABA,000BB800,000E2900 with the following meaning of the hex values: ^DSFLOWRPT: N1, N2, N3, N4, N5, N6, N7 N1: Connection duration in seconds N2: current upload speed (bytes per second) N3: current download speed (bytes per second) N4: number of sent bytes N5: number of received bytes N6: connection, supported by the maximum upload speed N7: connection, supported by a maximum download speed I'm thinking in writing a small, ncurses(3) based tool which will just read the RSSI and DSFLOWRPT lines from the modem and building some semi graphical representation of them as seen below, which gets updated every two seconds. Any comments about this or any pointers to existing software which could be adopted for this? Thanks matthias +========================================================================+ |uptime: hh:mm:ss | |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, 11, 11]| | (Mbps): 0.........1.........2.........3.........4.........5..| |cur. upload speed: [---------->| ]| |c. download speed: [---------------------------------->| ]| |total bytes upld: 1.554.561 | |total bytes down: 5.477.584 | +========================================================================+ -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 11:45:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583A11065673 for ; Mon, 30 Jan 2012 11:45:31 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id C07478FC13 for ; Mon, 30 Jan 2012 11:45:30 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Mon, 30 Jan 2012 12:42:42 +0100 id 00033C37.4F268232.0000D754 Date: Mon, 30 Jan 2012 12:45:20 +0100 From: Milan Obuch To: Matthias Apitz Message-ID: <20120130124520.40f830c0@atom.dino.sk> In-Reply-To: <20120130110919.GA1249@tiny> References: <20120130110919.GA1249@tiny> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: UMTS Huawei monitor X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 11:45:31 -0000 On Mon, 30 Jan 2012 12:09:20 +0100 Matthias Apitz wrote: > > Hello, > > I'm used to connect my FreeBSD laptop or netbooks to Internet using > Huawei USB modems (E220 or E1750) with good results, if the networks > coverage of the provider is good enough in the place in question. > > While monitoring my modems and searching around in Google I see that > the modems are providing not only the port used by the ppp(8) daemon, > in my case /dev/cuaU0.0, but also some additional monitor port, the > E1750 as /dev/cuaU0.3. If you just hook a terminal or kermit(1) to > that port you see from time to time lines like this one: > > ^RSSI: 11 > > which gives the signal quality in a range from 0 (poor) to 31 (best) > and in addition every 2 seconds a line of: > > ^DSFLOWRPT:00000B3A,00000054,00000054,00000000001B0785,0000000000573ABA,000BB800,000E2900 > > with the following meaning of the hex values: > > ^DSFLOWRPT: N1, N2, N3, N4, N5, N6, N7 > N1: Connection duration in seconds > N2: current upload speed (bytes per second) > N3: current download speed (bytes per second) > N4: number of sent bytes > N5: number of received bytes > N6: connection, supported by the maximum upload speed > N7: connection, supported by a maximum download speed > > I'm thinking in writing a small, ncurses(3) based tool which will just > read the RSSI and DSFLOWRPT lines from the modem and building some > semi graphical representation of them as seen below, which gets > updated every two seconds. > > Any comments about this or any pointers to existing software which > could be adopted for this? > > Thanks > > matthias > > > +========================================================================+ > |uptime: > hh:mm:ss | > |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, 11, > 11]| | (Mbps): > 0.........1.........2.........3.........4.........5..| |cur. upload > speed: [---------->| ]| |c. > download speed: [---------------------------------->| > ]| |total bytes upld: > 1.554.561 | |total bytes > down: 5.477.584 | > +========================================================================+ > Did you look at e169-stats in ports? It should either do what you would like or at least be a good entry point for you... Regards, Milan From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 12:01:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F549106568B for ; Mon, 30 Jan 2012 12:01:15 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2E1A8FC23 for ; Mon, 30 Jan 2012 12:01:14 +0000 (UTC) Received: by iaeo4 with SMTP id o4so8601258iae.13 for ; Mon, 30 Jan 2012 04:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=FeHYu7d1tTjWpxmtUJ1WScN0I/NkCXD358qLaAITq5g=; b=lbEfpNIMtSUC0SGOCkdOSBMVC/7Vdg4WS7MzKA8lDGQ2yKxXvDSmH0vntXjJfOt50U LTGBWsqNP4XE7aZaddG3Gj1xy5fPgKhSJLRMr3fZJuSai4Ss7oDysSDTpKaTmSYepB9G jGOq9C/BPfjzS3y1nhv7YDqOZQq8Wxstf3Mj0= MIME-Version: 1.0 Received: by 10.50.189.194 with SMTP id gk2mr18027409igc.0.1327924873243; Mon, 30 Jan 2012 04:01:13 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.134.198 with HTTP; Mon, 30 Jan 2012 04:01:13 -0800 (PST) Date: Mon, 30 Jan 2012 13:01:13 +0100 X-Google-Sender-Auth: fR_g5CNymvbpIxq5T0sM5ysdytQ Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: freebsd-net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 12:01:15 -0000 Hello, from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! Comments/Feedback expected, Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 14:36:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6251065674 for ; Mon, 30 Jan 2012 14:36:41 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 797F28FC0C for ; Mon, 30 Jan 2012 14:36:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RrsLV-0006cd-Rz for freebsd-net@freebsd.org; Mon, 30 Jan 2012 15:36:37 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Jan 2012 15:36:37 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Jan 2012 15:36:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Mon, 30 Jan 2012 15:36:25 +0100 Lines: 23 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120110 Thunderbird/9.0 In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 14:36:41 -0000 On 30/01/2012 13:01, Ermal Luçi wrote: > Surely i know that this is not the best way to implement generically ... probably, because it's similar to VNET... > What i would like to know is if there is interest to see such > functionality in FreeBSD? > > I am asking first to see if there is some consensus about this as a > feature, needed or not! > If interest is shown i will transform the patch to allow: > - ipfw(8) to manage the contextes create/destroy > - ipfw(8) to manage interface membership. Closing the race of two > parallell clients modifying different contextes. > It is quite handy feature, which can be exploited even to scale on SMP > machines by extending it to bind a specific instance(with its > interaces) to a specific CPU/core?! ... which is also done by VNET+JAILS. You should probably port it to VNET :) From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 15:15:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 997C7106566C; Mon, 30 Jan 2012 15:15:36 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3049A8FC13; Mon, 30 Jan 2012 15:15:35 +0000 (UTC) Received: by ggnk5 with SMTP id k5so1225601ggn.13 for ; Mon, 30 Jan 2012 07:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kXkCi0hPJDoz1lD+HTZ2cvV8w6bpTbavkpr6twsPJYU=; b=H71McfNozWSXLbV/TaurY5s/qgPmWEvWmzpPkdULJHFKwQnfaK1CnDU17zZQuwkStI K+GdxXAgCh2bF05Hn0H3wAT3cn+K9jLSA05h70rx9Knu4VCO8kIQVHMXFq0oxIymbiPu H9W+1YWwHfapUtSCsRk6g7RB7NqgMQsVyT3Fk= MIME-Version: 1.0 Received: by 10.50.207.72 with SMTP id lu8mr18131290igc.0.1327936534195; Mon, 30 Jan 2012 07:15:34 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.134.198 with HTTP; Mon, 30 Jan 2012 07:15:34 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Jan 2012 16:15:34 +0100 X-Google-Sender-Auth: rY-rq-MiUoRkyi1VdRs5bCXF2yU Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 15:15:36 -0000 On Mon, Jan 30, 2012 at 3:36 PM, Ivan Voras wrote: > On 30/01/2012 13:01, Ermal Lu=E7i wrote: > >> Surely i know that this is not the best way to implement generically > > > ... probably, because it's similar to VNET... > It depends on the comparison. The same argument would hold true for multiple routing tables but still they coexist. Both usages have their scopes. > >> What i would like to know is if there is interest to see such >> functionality in FreeBSD? >> >> I am asking first to see if there is some consensus about this as a >> feature, needed or not! >> If interest is shown i will transform the patch to allow: >> - ipfw(8) to manage the contextes create/destroy >> - ipfw(8) to manage interface membership. Closing the race of two >> parallell clients modifying different contextes. > > >> It is quite handy feature, which can be exploited even to scale on SMP >> machines by extending it to bind a specific instance(with its >> interaces) to a specific CPU/core?! > > > ... which is also done by VNET+JAILS. > > You should probably port it to VNET :) See above. Nevertheless, VNET is still not production use so.... > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 18:44:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D487106566B; Mon, 30 Jan 2012 18:44:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E9A258FC0C; Mon, 30 Jan 2012 18:44:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id A3A9646B06; Mon, 30 Jan 2012 13:44:24 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 18831B95C; Mon, 30 Jan 2012 13:44:24 -0500 (EST) From: John Baldwin To: lev@freebsd.org Date: Mon, 30 Jan 2012 09:22:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1076713525.20120129133839@serebryakov.spb.ru> In-Reply-To: <1076713525.20120129133839@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201201300922.26995.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jan 2012 13:44:24 -0500 (EST) Cc: jfv@freebsd.org, freebsd-net@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 18:44:25 -0000 On Sunday, January 29, 2012 4:38:39 am Lev Serebryakov wrote: > Hello, Freebsd-net. > > My home server lost connection on em0 this night again. It was > persistent problem some times ago, but with version 7.2.3 it is first > time, but with worse symptoms. > > It looks like undetected hardware hang-up: no packets could be sent > or received, and no any output in dmesg or log files. Interface > up/down with ifconfig and cable unplugging doesn't help: ifaces sees > all these changes, but no packets could be sent/received anyway. I > was forced to reboot server to make it work again. > > IT is rather old 8-STABLE (Oct 2011), but it sems, that last change > in e1000 for 8-STABLE was r223675, in Jun 2011, so it is "fresh" > sources (I don't believe, that r229147 is related). > > Output of `sysctl dev.em' when card is not working (but after some up/down > events) is attached. Can you grab two snapshots after sending some traffic to it? You have several non-zero error counters, but it would be good to see which ones are changing while you are in this state. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 21:08:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718F5106566B for ; Mon, 30 Jan 2012 21:08:37 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFA98FC18 for ; Mon, 30 Jan 2012 21:08:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RrySq-0006bH-7b for freebsd-net@freebsd.org; Mon, 30 Jan 2012 22:08:36 +0100 Received: from broadband-77-37-240-109.nationalcablenetworks.ru ([77.37.240.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Jan 2012 22:08:36 +0100 Received: from vadim_nuclight by broadband-77-37-240-109.nationalcablenetworks.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Jan 2012 22:08:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Mon, 30 Jan 2012 21:08:25 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 91 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: broadband-77-37-240-109.nationalcablenetworks.ru X-Comment-To: Ermal Lu?i User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:08:37 -0000 Hi Ermal Lu?i! On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple instances of ipfw(4)': > from needs on pfSense a patch for allowing multiple intances of > ipfw(4) in kernel to co-exist was developed. > It can be found here > https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff Hmm, looking at the lines if (oif && !(oif->if_flags & IFF_IPFW_FILTER)) return (IP_FW_PASS); it appears that a patch is made against somewhat private, I couldn't find that in stock FreeBSD. > It is used in conjuction with this tool > https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c > It allows creation of contextes/instances and assignment of specific > interfaces to specific contexts/instances. It is not clear how to add a rule to a specific instance with this program. > Surely i know that this is not the best way to implement generically > but it gets the job done for us as it is, read below. > What i would like to know is if there is interest to see such > functionality in FreeBSD? > I am asking first to see if there is some consensus about this as a > feature, needed or not! > If interest is shown i will transform the patch to allow: > - ipfw(8) to manage the contextes create/destroy > - ipfw(8) to manage interface membership. Closing the race of two > parallell clients modifying different contextes. > There is another design choice to be made about storing the membership > of interfaces into contexts/instances, but i do not see that as > blocking. > It is quite handy feature, which can be exploited even to scale on SMP > machines by extending it to bind a specific instance(with its > interaces) to a specific CPU/core?! Not so simple/straightforward questions. On the one hand, there are at least /some/ people who need this. So the ipfw 'call'/'return' actions were already implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to ipfw table allowing matching againt ifname, setting tablearg, which in conjunction with 'call' or 'skipto' could be used to make essentially the same functionality as your proposed patch, already in stock FreeBSD. On the other hand, both ipfw contexts and ipfw 'call' are very half-measures. The only goal was to give people something right now, and see how much this will be demanded, what feedback they'll give, etc. It is obvious there is no wide testing of 9.0-R (and 8.3-R too) right now. What I mean here about half-measures? The ipfw 'call' is just a sketch of my old ideas to completely reorganize ipfw to support multiple rulesets. To be generic and Right Thing(tm), this is a HUGE work, because: - each ipfw chain becomes independent netgraph(4) node - generic ng_pfil node usable not only for firewalls - chains may be called from each other (see iptables) - chains (actually netgraph nodes) may be bind to ifaces or any other place - main unnamed chain is called from pfil as before - rewrite ipfw & dummynet management from setsockopt() to netgraph messages - completely rewrite ipfw dynamic rules to not conflict with multiple rulesets, as now they just jump to parent static rule (need to be more like pf or iptables states). This item is hard but essential (you'll get a mess jumping to another ruleset), and ipfw contexts don't handle ot - while here, do other needed things, e.g. adding support for modules in both kernel and userland, loadable opcodes, keywords, etc. Even if not add something like bpf, that's ipfw_ng is probably a more major change than both ipfw2 and ipfw3 :) Due to various reasons in my private life, I was unable to do it in my spare time previous years. My new employer is a provider using FreeBSD on most machines, so I hope I could finally begin doing it at work (and for work), but only several months later after more actual tasks. But, all of this only makes sense to be generic for needs of broad masses of our users. And in pfSense ipfw users are actually only it's authors (all others see web interface), so it's better and more practical to not rely on such complex solution, but rather on something more simple and specialized for their needs. Such as your proposed ipfw contexts. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] From owner-freebsd-net@FreeBSD.ORG Mon Jan 30 22:22:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC240106566B; Mon, 30 Jan 2012 22:22:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 81E268FC17; Mon, 30 Jan 2012 22:22:53 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0UMMkFm003197 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 14:22:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F271882.602@freebsd.org> Date: Mon, 30 Jan 2012 14:24:02 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net , freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Jan 2012 22:22:53 -0000 On 1/30/12 4:01 AM, Ermal Lui wrote: > Hello, > > from needs on pfSense a patch for allowing multiple intances of > ipfw(4) in kernel to co-exist was developed. > It can be found here > https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff > > It is used in conjuction with this tool > https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c > It allows creation of contextes/instances and assignment of specific > interfaces to specific contexts/instances. > > Surely i know that this is not the best way to implement generically > but it gets the job done for us as it is, read below. > > What i would like to know is if there is interest to see such > functionality in FreeBSD? > > I am asking first to see if there is some consensus about this as a > feature, needed or not! > If interest is shown i will transform the patch to allow: > - ipfw(8) to manage the contextes create/destroy > - ipfw(8) to manage interface membership. Closing the race of two > parallell clients modifying different contextes. > > There is another design choice to be made about storing the membership > of interfaces into contexts/instances, but i do not see that as > blocking. > > It is quite handy feature, which can be exploited even to scale on SMP > machines by extending it to bind a specific instance(with its > interaces) to a specific CPU/core?! for this I use multiple vimages, but just as there is room for multiplt routing tables AND vimage, there is probably room for multiple firewalls AND vimage. this is a bit more in the iptables direction I guess. > Comments/Feedback expected, > Ermal > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 08:53:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736241065677; Tue, 31 Jan 2012 08:53:31 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 172038FC14; Tue, 31 Jan 2012 08:53:30 +0000 (UTC) Received: by iaeo4 with SMTP id o4so10620269iae.13 for ; Tue, 31 Jan 2012 00:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EqXGhg4V/rlM5rzkuz1bpB1/onweZIQ8GUV+rTL+1WM=; b=OaG8+W7gGxNU3L3ohYS9bZ5RJk7YJZvxy/cxe/V2ms33HFoZc3ksAGi3v/fVQcIBZD oDV7DEH5MAdxJGJ0peNzB4vET7MR5MO9/1+8OUvb8Z7+lo24FgAVcrIIoBxo9JBhpRYc LSKsPNjYpl7Puf3/LjllK6ojHhm27ib+xcC9c= MIME-Version: 1.0 Received: by 10.50.88.163 with SMTP id bh3mr21138643igb.0.1328000010299; Tue, 31 Jan 2012 00:53:30 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.134.198 with HTTP; Tue, 31 Jan 2012 00:53:30 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 09:53:30 +0100 X-Google-Sender-Auth: zgwPPma5VZs-sQfTlSf4HGDFMZQ Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 08:53:31 -0000 On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov wrote: > Hi Ermal Lu?i! > > On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multi= ple instances of ipfw(4)': > >> from needs on pfSense a patch for allowing multiple intances of >> ipfw(4) in kernel to co-exist was developed. >> It can be found here >> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_= 9_0/CP_multi_instance_ipfw.diff > > Hmm, looking at the lines > > =A0 =A0 =A0 =A0if (oif && !(oif->if_flags & IFF_IPFW_FILTER)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (IP_FW_PASS); > > it appears that a patch is made against somewhat private, I couldn't find= that > in stock FreeBSD. Yeah its not so polished patch, and the remaining parts are still there in the same repo. Though its redundant to this patch. > >> It is used in conjuction with this tool >> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_co= ntext/files/ipfw_context.c >> It allows creation of contextes/instances and assignment of specific >> interfaces to specific contexts/instances. > > It is not clear how to add a rule to a specific instance with this progra= m. > Simple example: - Create a context with members ipfw_context -a testctx ipfw_context -a testctx -n myiface0 ipfw_context -a testctx -n myiface1 - Set the context ipfw_context -s testctx - Continue business as usual with ipfw/dummynet ipfw add .... ipfw pipe create .... ipfw table add .... >> Surely i know that this is not the best way to implement generically >> but it gets the job done for us as it is, read below. > >> What i would like to know is if there is interest to see such >> functionality in FreeBSD? > >> I am asking first to see if there is some consensus about this as a >> feature, needed or not! >> If interest is shown i will transform the patch to allow: >> - ipfw(8) to manage the contextes create/destroy >> - ipfw(8) to manage interface membership. Closing the race of two >> parallell clients modifying different contextes. > >> There is another design choice to be made about storing the membership >> of interfaces into contexts/instances, but i do not see that as >> blocking. > >> It is quite handy feature, which can be exploited even to scale on SMP >> machines by extending it to bind a specific instance(with its >> interaces) to a specific CPU/core?! > > Not so simple/straightforward questions. On the one hand, there are at le= ast > /some/ people who need this. So the ipfw 'call'/'return' actions were alr= eady > implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches = to > ipfw table allowing matching againt ifname, setting tablearg, which in > conjunction with 'call' or 'skipto' could be used to make essentially the= same > functionality as your proposed patch, already in stock FreeBSD. > Well it tends to get messy if you do not have a smart consumer handling the jumps. Its almost as reprogramming in ipfw language and somehow an admin needs to read this! The intention was be practical and allow easy troubleshooting. > On the other hand, both ipfw contexts and ipfw 'call' are very half-measu= res. > The only goal was to give people something right now, and see how much th= is > will be demanded, what feedback they'll give, etc. It is obvious there is= no > wide testing of 9.0-R (and 8.3-R too) right now. > It depends on the needs, surely and how colorful you want it to be. > What I mean here about half-measures? The ipfw 'call' is just a sketch of= my > old ideas to completely reorganize ipfw to support multiple rulesets. To = be > generic and Right Thing(tm), this is a HUGE work, because: > > - each ipfw chain becomes independent netgraph(4) node > - generic ng_pfil node usable not only for firewalls > - chains may be called from each other (see iptables) > - chains (actually netgraph nodes) may be bind to ifaces or any other pla= ce > - main unnamed chain is called from pfil as before > - rewrite ipfw & dummynet management from setsockopt() to netgraph messag= es > - completely rewrite ipfw dynamic rules to not conflict with multiple > =A0rulesets, as now they just jump to parent static rule (need to be more= like > =A0pf or iptables states). This item is hard but essential (you'll get a = mess > =A0jumping to another ruleset), and ipfw contexts don't handle ot > - while here, do other needed things, e.g. adding support for modules in = both > =A0kernel and userland, loadable opcodes, keywords, etc. > if you write a ip/tcp/udp/... stack on netgraph than i will write this :) Though its a matter of preference and how much work its needed to accomplish this! Surely ipfw has seen a lot of hacks in the past and will see in the future but i thik usability is more of a target rather than fancy design. But surely nothing should stop both ways. > Even if not add something like bpf, that's ipfw_ng is probably a more maj= or > change than both ipfw2 and ipfw3 :) > > Due to various reasons in my private life, I was unable to do it in my sp= are > time previous years. My new employer is a provider using FreeBSD on most > machines, so I hope I could finally begin doing it at work (and for work)= , > but only several months later after more actual tasks. > > But, all of this only makes sense to be generic for needs of broad masses= of > our users. And in pfSense ipfw users are actually only it's authors (all > others see web interface), so it's better and more practical to not rely = on > such complex solution, but rather on something more simple and specialize= d for > their needs. Such as your proposed ipfw contexts. > Surely enough you can take shortcuts in a customization but its not the point here. > -- > WBR, Vadim Goncharov. ICQ#166852181 =A0 =A0 =A0 mailto:vadim_nuclight@mai= l.ru > [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 09:20:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1030C106566C; Tue, 31 Jan 2012 09:20:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D53648FC14; Tue, 31 Jan 2012 09:20:10 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0V9K72Z005065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 01:20:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F27B293.5000605@freebsd.org> Date: Tue, 31 Jan 2012 01:21:23 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: vadim_nuclight@mail.ru, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 09:20:11 -0000 On 1/31/12 12:53 AM, Ermal Lui wrote: > On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov > wrote: >> Hi Ermal Lu?i! >> >> On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple instances of ipfw(4)': >> >>> from needs on pfSense a patch for allowing multiple intances of >>> ipfw(4) in kernel to co-exist was developed. >>> It can be found here >>> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff >> Hmm, looking at the lines >> >> if (oif&& !(oif->if_flags& IFF_IPFW_FILTER)) >> return (IP_FW_PASS); >> >> it appears that a patch is made against somewhat private, I couldn't find that >> in stock FreeBSD. > Yeah its not so polished patch, and the remaining parts are still > there in the same repo. > Though its redundant to this patch. > >>> It is used in conjuction with this tool >>> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c >>> It allows creation of contextes/instances and assignment of specific >>> interfaces to specific contexts/instances. >> It is not clear how to add a rule to a specific instance with this program. >> > Simple example: > - Create a context with members > ipfw_context -a testctx > ipfw_context -a testctx -n myiface0 > ipfw_context -a testctx -n myiface1 > - Set the context > ipfw_context -s testctx > - Continue business as usual with ipfw/dummynet > ipfw add .... > ipfw pipe create .... > ipfw table add .... > > >>> Surely i know that this is not the best way to implement generically >>> but it gets the job done for us as it is, read below. >>> What i would like to know is if there is interest to see such >>> functionality in FreeBSD? >>> I am asking first to see if there is some consensus about this as a >>> feature, needed or not! >>> If interest is shown i will transform the patch to allow: >>> - ipfw(8) to manage the contextes create/destroy >>> - ipfw(8) to manage interface membership. Closing the race of two >>> parallell clients modifying different contextes. >>> There is another design choice to be made about storing the membership >>> of interfaces into contexts/instances, but i do not see that as >>> blocking. >>> It is quite handy feature, which can be exploited even to scale on SMP >>> machines by extending it to bind a specific instance(with its >>> interaces) to a specific CPU/core?! >> Not so simple/straightforward questions. On the one hand, there are at least >> /some/ people who need this. So the ipfw 'call'/'return' actions were already >> implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to >> ipfw table allowing matching againt ifname, setting tablearg, which in >> conjunction with 'call' or 'skipto' could be used to make essentially the same >> functionality as your proposed patch, already in stock FreeBSD. >> > Well it tends to get messy if you do not have a smart consumer > handling the jumps. > Its almost as reprogramming in ipfw language and somehow an admin > needs to read this! > The intention was be practical and allow easy troubleshooting. > >> On the other hand, both ipfw contexts and ipfw 'call' are very half-measures. >> The only goal was to give people something right now, and see how much this >> will be demanded, what feedback they'll give, etc. It is obvious there is no >> wide testing of 9.0-R (and 8.3-R too) right now. >> > It depends on the needs, surely and how colorful you want it to be. > >> What I mean here about half-measures? The ipfw 'call' is just a sketch of my >> old ideas to completely reorganize ipfw to support multiple rulesets. To be >> generic and Right Thing(tm), this is a HUGE work, because: >> >> - each ipfw chain becomes independent netgraph(4) node what about the existing netgraph ipfw node someone wrote a few years ago? I saw it but don't know if it was sent out publicly. >> - generic ng_pfil node usable not only for firewalls >> - chains may be called from each other (see iptables) >> - chains (actually netgraph nodes) may be bind to ifaces or any other place >> - main unnamed chain is called from pfil as before >> - rewrite ipfw& dummynet management from setsockopt() to netgraph messages >> - completely rewrite ipfw dynamic rules to not conflict with multiple >> rulesets, as now they just jump to parent static rule (need to be more like >> pf or iptables states). This item is hard but essential (you'll get a mess >> jumping to another ruleset), and ipfw contexts don't handle ot >> - while here, do other needed things, e.g. adding support for modules in both >> kernel and userland, loadable opcodes, keywords, etc. >> > if you write a ip/tcp/udp/... stack on netgraph than i will write this :) > Though its a matter of preference and how much work its needed to > accomplish this! > Surely ipfw has seen a lot of hacks in the past and will see in the > future but i thik usability is more of a target > rather than fancy design. > > But surely nothing should stop both ways. > >> Even if not add something like bpf, that's ipfw_ng is probably a more major >> change than both ipfw2 and ipfw3 :) >> >> Due to various reasons in my private life, I was unable to do it in my spare >> time previous years. My new employer is a provider using FreeBSD on most >> machines, so I hope I could finally begin doing it at work (and for work), >> but only several months later after more actual tasks. >> >> But, all of this only makes sense to be generic for needs of broad masses of >> our users. And in pfSense ipfw users are actually only it's authors (all >> others see web interface), so it's better and more practical to not rely on >> such complex solution, but rather on something more simple and specialized for >> their needs. Such as your proposed ipfw contexts. >> > Surely enough you can take shortcuts in a customization but its not > the point here. > >> -- >> WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru >> [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 09:43:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A095106567E for ; Tue, 31 Jan 2012 09:43:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id E914A8FC13 for ; Tue, 31 Jan 2012 09:43:39 +0000 (UTC) Received: from [82.113.119.148] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RsAFV-0003Vp-MU for freebsd-net@freebsd.org; Tue, 31 Jan 2012 10:43:38 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q0V9iE9O001343 for ; Tue, 31 Jan 2012 10:44:15 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q0V9iEwX001342 for freebsd-net@freebsd.org; Tue, 31 Jan 2012 10:44:14 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 31 Jan 2012 10:44:14 +0100 From: Matthias Apitz To: freebsd-net@freebsd.org Message-ID: <20120131094413.GA1306@tiny> References: <20120130110919.GA1249@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120130110919.GA1249@tiny> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.119.148 Subject: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:43:40 -0000 El da Monday, January 30, 2012 a las 12:09:20PM +0100, Matthias Apitz escribi: > > Hello, > > I'm used to connect my FreeBSD laptop or netbooks to Internet using > Huawei USB modems (E220 or E1750) with good results, if the networks > coverage of the provider is good enough in the place in question. > > ... > > +========================================================================+ > |uptime: hh:mm:ss | > |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, 11, 11]| > | (Mbps): 0.........1.........2.........3.........4.........5..| > |cur. upload speed: [---------->| ]| > |c. download speed: [---------------------------------->| ]| > |total bytes upld: 1.554.561 | > |total bytes down: 5.477.584 | > +========================================================================+ Hello, I was thinking about a Huawei USB modem monitor and got a pointer to the ports/net/e169-stats (thanks to Milan for this); I have checked it out and it does mostly what I was thinking of; I have a few questions which are not answered in the documentation (because there is no manual or other doc :-)) ... anybody out here who is using this tool and could answer perhaps my question? Thanks in advance matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 10:01:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FF711065672 for ; Tue, 31 Jan 2012 10:01:14 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id AC1E98FC20 for ; Tue, 31 Jan 2012 10:01:13 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Tue, 31 Jan 2012 10:58:20 +0100 id 00033CEA.4F27BB3C.00010A39 Date: Tue, 31 Jan 2012 11:01:00 +0100 From: Milan Obuch To: Matthias Apitz Message-ID: <20120131110100.0da8b89e@atom.dino.sk> In-Reply-To: <20120131094413.GA1306@tiny> References: <20120130110919.GA1249@tiny> <20120131094413.GA1306@tiny> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 10:01:14 -0000 On Tue, 31 Jan 2012 10:44:14 +0100 Matthias Apitz wrote: > El d=EDa Monday, January 30, 2012 a las 12:09:20PM +0100, Matthias > Apitz escribi=F3: >=20 > >=20 > > Hello, > >=20 > > I'm used to connect my FreeBSD laptop or netbooks to Internet using > > Huawei USB modems (E220 or E1750) with good results, if the networks > > coverage of the provider is good enough in the place in question. > >=20 > > ... > >=20 > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > |uptime: > > hh:mm:ss | > > |RSSI: current 11 of 31 [last values: 13, 11, 12, 11, 11. 11. 11, > > 11, 11]| | (Mbps): > > 0.........1.........2.........3.........4.........5..| |cur. upload > > speed: [---------->| ]| |c. > > download speed: [---------------------------------->| > > ]| |total bytes upld: > > 1.554.561 | |total > > bytes down: 5.477.584 | > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >=20 > Hello, >=20 > I was thinking about a Huawei USB modem monitor and got a pointer to > the ports/net/e169-stats (thanks to Milan for this); I have checked > it out and it does mostly what I was thinking of; I have a few > questions which are not answered in the documentation (because there > is no manual or other doc :-)) ... anybody out here who is using this > tool and could answer perhaps my question? Thanks in advance >=20 > matthias Hi, just ask here, I think - maybe add edwin@mavetju.org to CC as he wrote this and should have definite answers, I think. I use some Huawei occasionally with e169-stats to see signal properties. I bet there are others out there using it as well, so "someone" (tm) should know :) Regards, Milan From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 10:19:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C341065677 for ; Tue, 31 Jan 2012 10:19:02 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB418FC13 for ; Tue, 31 Jan 2012 10:19:01 +0000 (UTC) Received: from [82.113.119.148] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RsAni-0003im-AG; Tue, 31 Jan 2012 11:18:58 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q0VAJYkR001389; Tue, 31 Jan 2012 11:19:35 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q0VAJVI6001388; Tue, 31 Jan 2012 11:19:31 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 31 Jan 2012 11:19:31 +0100 From: Matthias Apitz To: Milan Obuch Message-ID: <20120131101930.GA1371@tiny> References: <20120130110919.GA1249@tiny> <20120131094413.GA1306@tiny> <20120131110100.0da8b89e@atom.dino.sk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120131110100.0da8b89e@atom.dino.sk> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.119.148 Cc: freebsd-net@freebsd.org, edwin@mavetju.org Subject: Re: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:19:02 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El da Tuesday, January 31, 2012 a las 11:01:00AM +0100, Milan Obuch escribi: > > I was thinking about a Huawei USB modem monitor and got a pointer to > > the ports/net/e169-stats (thanks to Milan for this); I have checked > > it out and it does mostly what I was thinking of; I have a few > > questions which are not answered in the documentation (because there > > is no manual or other doc :-)) ... anybody out here who is using this > > tool and could answer perhaps my question? Thanks in advance > > > > matthias > > Hi, > > just ask here, I think - maybe add edwin@mavetju.org to CC as he wrote > this and should have definite answers, I think. I use some Huawei > occasionally with e169-stats to see signal properties. I bet there are > others out there using it as well, so "someone" (tm) should know :) Hi, I'm attaching a cut&paste of the xterm where e169-stats runs and added to this line nunmbers (1-24) and columns (1-80). The upper part, lines 1-12 is all clear; in the lower part I do not understand the values in line 13 and the moving chars (like 'v', ...) which are moving every two seconds (as resultat of DSFLOWRPT) one position from left to right; what they should express exactly? (use a xterm of more the 80 columns to see the file /tmp/xterm.txt correctly) Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xterm.txt" 10 20 30 40 50 60 70 80 1........|.........|.........|.........|.........|.........|.........|.........| 1 E169 stats (80 x 24) 2 Time online: 1:16:02 3 Mode: HSPA7 / SRVST: 2 09:49 2562 B / 2562 B 4 RSSI: -97 dBm (8) 09:50 2562 B / 2562 B 5 Total: 1568.88 KiB / 5372.76 KiB 09:51 2604 B / 2604 B 6 Now: 500 B / 500 B 09:52 2562 B / 2562 B 7 09:53 2562 B / 2562 B 8 09:54 2604 B / 2604 B 9 09:55 2562 B / 2562 B 10 09:56 35.85 KiB / 299.74 KiB 11 09:57 71.89 KiB / 718.20 KiB 12 09:58 491.69 KiB / 1462.97 KiB 13 400kB -51dBm v 14 v 15 16 17 v 18 19 v v 20 v ^ 21 v v v ^ 22 ################################################v############vv####^########### 23 v v v ^ v 24 vvv^^vvvvvvvvv^vvvvvvvvvvvvvvvvvvvvvv^^^vvvvvvvv^^vvvvvvvvvv^^^^^^^vvvvvvvv^vvv 1........|.........|.........|.........|.........|.........|.........|.........| 10 20 30 40 50 60 70 80 --IS0zKkzwUGydFO0o-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 10:44:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90671106566C for ; Tue, 31 Jan 2012 10:44:35 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 34A868FC0C for ; Tue, 31 Jan 2012 10:44:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DA28F7300A; Tue, 31 Jan 2012 12:02:04 +0100 (CET) Date: Tue, 31 Jan 2012 12:02:04 +0100 From: Luigi Rizzo To: Ermal Lu?i Message-ID: <20120131110204.GA95472@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.4.2.3i Cc: freebsd-net , freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 10:44:35 -0000 On Mon, Jan 30, 2012 at 01:01:13PM +0100, Ermal Lu?i wrote: > Hello, > > from needs on pfSense a patch for allowing multiple intances of > ipfw(4) in kernel to co-exist was developed. > It can be found here > https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff > > It is used in conjuction with this tool > https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c > It allows creation of contextes/instances and assignment of specific > interfaces to specific contexts/instances. > > Surely i know that this is not the best way to implement generically > but it gets the job done for us as it is, read below. > > What i would like to know is if there is interest to see such > functionality in FreeBSD? > > I am asking first to see if there is some consensus about this as a > feature, needed or not! > If interest is shown i will transform the patch to allow: > - ipfw(8) to manage the contextes create/destroy > - ipfw(8) to manage interface membership. Closing the race of two > parallell clients modifying different contextes. > > There is another design choice to be made about storing the membership > of interfaces into contexts/instances, but i do not see that as > blocking. > > It is quite handy feature, which can be exploited even to scale on SMP > machines by extending it to bind a specific instance(with its > interaces) to a specific CPU/core?! > > Comments/Feedback expected, if i understand what the patch does, i think it makes sense to be able to hook ipfw instances to specific interfaces/sets of interfaces, as it permits the writing of more readable rulesets. Right now the workaround is start the ruleset with skipto rules matching on interface names, and then use some discipline in "reserving" a range of rule numbers to each interface. Before making more changes to the code, it would help if you could give a high level description of 1. what the change does and how specific cases are handled. E.g. With this change you can create multiple rulesets (contexts ?) and bind one or more interfaces to a context. - what happens with outgoing packets where the context to be picked up depend on the route in effect at the time of the transmission ? - what happens with encapsulated interfaces (vlan) ? - can you skipto across contexts (i guess not) ? 2. how intrusive are code changes ? The kernel patch you show seems small, which makes sense as i believe all is needed is to start from a specific chain instead of the default one when an interface is bound to a context. A few comments: - if you use one of the if_ispare directly, instead of renaming it to if_context, this would make backporting and testing easier. - I think the explosion of sockopt names is a bad thing. The IP_FW3 command was introduced exactly to have a single entry point to the firewall and avoid a ton of new names in raw_ip.c and in.h - can you reduce the number of global ipfw-related variables ? There used to be one (layer3_chain), now you have 3 of them. You should delete layer3_chain and replace it with another single global (could be ip_fw_contexts) which contains the whole firewall state. - how do you handle reinjects (e.g. from dummynet or divert) ? I don't remember if the metadata that stores where you reinject the packet also has a pointer to the root of the chain. - i don't completely follow the connection between ip_fw_chain, ip_fw_ctx_iflist, ip_fw_ctxmember, ip_fw_ctx, ip_fw_ctx_list. The way i see it: - the ip_fw_chain could be embedded in the ip_fw_ctx, as they map 1:1 - why do you need ip_fw_ctx_iflist and ip_fw_ctxmember ? You should never need to determine context membership during packet processing, and for sockopt calls you could as well iterate over the list of interfaces; cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 10:53:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A901106566B for ; Tue, 31 Jan 2012 10:53:56 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id A78FC8FC24 for ; Tue, 31 Jan 2012 10:53:54 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Tue, 31 Jan 2012 11:51:02 +0100 id 00033CF2.4F27C796.00010CAF Date: Tue, 31 Jan 2012 11:53:48 +0100 From: Milan Obuch To: Matthias Apitz Message-ID: <20120131115348.0748df3a@atom.dino.sk> In-Reply-To: <20120131101930.GA1371@tiny> References: <20120130110919.GA1249@tiny> <20120131094413.GA1306@tiny> <20120131110100.0da8b89e@atom.dino.sk> <20120131101930.GA1371@tiny> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, edwin@mavetju.org Subject: Re: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 10:53:56 -0000 On Tue, 31 Jan 2012 11:19:31 +0100 Matthias Apitz wrote: > El d=EDa Tuesday, January 31, 2012 a las 11:01:00AM +0100, Milan Obuch > escribi=F3: >=20 > > > I was thinking about a Huawei USB modem monitor and got a pointer > > > to the ports/net/e169-stats (thanks to Milan for this); I have > > > checked it out and it does mostly what I was thinking of; I have > > > a few questions which are not answered in the documentation > > > (because there is no manual or other doc :-)) ... anybody out > > > here who is using this tool and could answer perhaps my question? > > > Thanks in advance > > >=20 > > > matthias > >=20 > > Hi, > >=20 > > just ask here, I think - maybe add edwin@mavetju.org to CC as he > > wrote this and should have definite answers, I think. I use some > > Huawei occasionally with e169-stats to see signal properties. I bet > > there are others out there using it as well, so "someone" (tm) > > should know :) >=20 > Hi, >=20 > I'm attaching a cut&paste of the xterm where e169-stats runs and added > to this line nunmbers (1-24) and columns (1-80). The upper part, lines > 1-12 is all clear; in the lower part I do not understand the values in > line 13 and the moving chars (like 'v', ...) which are moving every > two seconds (as resultat of DSFLOWRPT) one position from left to > right; what they should express exactly? >=20 > (use a xterm of more the 80 columns to see the file /tmp/xterm.txt > correctly) >=20 > Thanks >=20 > matthias Hi, I will test it later to see, but AFAIR this should be running/moving/live graph presentation of signal strength and data transfer (load/speed) done in ASCII, so a bit rough. Not as nice as done in 'properly graphical' way, but usable. If you have steady signal strength, it is not obvious, but when you move a bit, you could see the change. Just guessing now - # is for signal, v is download momentary speed and ^ is for upload. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 12:43:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F95106566C for ; Tue, 31 Jan 2012 12:43:21 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id EAC7C8FC08 for ; Tue, 31 Jan 2012 12:43:20 +0000 (UTC) Received: from [82.113.119.148] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RsD3M-0007pn-PB; Tue, 31 Jan 2012 13:43:17 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q0VChqEf001530; Tue, 31 Jan 2012 13:43:53 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q0VChm7b001529; Tue, 31 Jan 2012 13:43:48 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 31 Jan 2012 13:43:48 +0100 From: Matthias Apitz To: Milan Obuch Message-ID: <20120131124347.GA1493@tiny> References: <20120130110919.GA1249@tiny> <20120131094413.GA1306@tiny> <20120131110100.0da8b89e@atom.dino.sk> <20120131101930.GA1371@tiny> <20120131115348.0748df3a@atom.dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120131115348.0748df3a@atom.dino.sk> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.119.148 Cc: freebsd-net@freebsd.org, edwin@mavetju.org Subject: Re: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 12:43:21 -0000 El da Tuesday, January 31, 2012 a las 11:53:48AM +0100, Milan Obuch escribi: > Hi, > > I will test it later to see, but AFAIR this should be > running/moving/live graph presentation of signal strength and data > transfer (load/speed) done in ASCII, so a bit rough. Not as nice as > done in 'properly graphical' way, but usable. If you have steady signal > strength, it is not obvious, but when you move a bit, you could see the > change. Just guessing now - # is for signal, v is download momentary > speed and ^ is for upload. Hi, At the end I decided to understand the source code. Btw: the device port /dev/cuaU0.n is hardcoded set to .2, while mine is .3 for the E1750; the -51 dBm value is just nothing more than the best possible RSSI value 31; the #-line (which is in real a fine line of some ncurses(3) symbol, don't know why cut&paste changed this) is a scaled representation of the RSSI values of the last 80x two seconds; the byte value in line 13 of 400kB is always calculated as the max or RX or TX values of the last 80x two seconds history; and finally 'v' and '^' are used to represent the current RX or TX value in scale with this maximum; I will now watch this movie for a while and see if I can draw some clue from that graphic :-) matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 15:46:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4557B106566C for ; Tue, 31 Jan 2012 15:46:35 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D080F8FC15 for ; Tue, 31 Jan 2012 15:46:34 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so105141wgb.31 for ; Tue, 31 Jan 2012 07:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VnqklrpF597hWWo/9cds1jwRxtlaZCvPNmqrhYEPGTM=; b=yE72XnLuAhXN/gAl38gZATxp08PA6hTmCVJsIQhVt9i3Es4ZJHhY534dILmNRmOTId UpxaUCzBk7nkDXX6Idyp6fyiOr+1bK5azbtmfS5hnl33bx5va32mAJPPczPCVJ9TTZl0 IPXqGeYFNB/N9GV2bCH+4qbAddnlcf0vH760U= MIME-Version: 1.0 Received: by 10.180.101.101 with SMTP id ff5mr4622111wib.14.1328024793984; Tue, 31 Jan 2012 07:46:33 -0800 (PST) Received: by 10.216.82.2 with HTTP; Tue, 31 Jan 2012 07:46:33 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 10:46:33 -0500 Message-ID: From: Arnaud Lacombe To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: msk0: watchdog timeout interface hang X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 15:46:35 -0000 Hi, On Wed, Jan 25, 2012 at 10:20 PM, Arnaud Lacombe wrote= : > Hi, > > On Wed, Jan 25, 2012 at 3:26 PM, Kim Culhan wrote: >> Running 10-curent from 01-20-12 >> the msk0 interface hung, on the console: >> >> msk0: watchdog timeout >> msk0: prefetch unit stuck? >> msk0: initialization failed: no memory for Rx buffers >> >> Verbose boot dmesg output attached. >> > known issue affecting at least 8-STABLE, 9-STABLE (assumed) and > -current. Already reported in these threads: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030635.html > > http://lists.freebsd.org/pipermail/freebsd-questions/2011-November/235646= .html > FWIW, 8-STABLE from yesterday keeps hanging. I'm moving the box to Linux, it became really ridiculous to have such a network driver hang with no more than 3Mbps of traffic (ok, it might be a bit spiky too). =A0- Arnaud > >> Any help is greatly appreciated. >> >> -kim >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 20:45:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1170D1065672 for ; Tue, 31 Jan 2012 20:45:59 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.161.93.240]) by mx1.freebsd.org (Postfix) with ESMTP id C699B8FC16 for ; Tue, 31 Jan 2012 20:45:58 +0000 (UTC) Received: by gvr.gvr.org (Postfix, from userid 657) id D37626E33E; Tue, 31 Jan 2012 21:27:41 +0100 (CET) Date: Tue, 31 Jan 2012 21:27:41 +0100 From: Guido van Rooij To: freebsd-net@freebsd.org Message-ID: <20120131202741.GA4335@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Difference in address selection between ICMP and TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 20:45:59 -0000 Consider the following: ifconfig em0 inet 1.2.3.4/24 ping 1.2.3.4 Then a tcpdump on lo0 shows: 21:15:56.641571 IP 127.0.0.1 > 1.2.3.4: ICMP echo request, id 36105, seq 10, length 64 21:15:56.641582 IP 1.2.3.4 > 127.0.0.1: ICMP echo reply, id 36105, seq 10, length 64 I think that the address used should have been 1.2.3.4 and not 127.0.0.1. Now when I do a telnet 1.2.3.4 22, I see: 21:17:55.955475 IP 1.2.3.4.38534 > 1.2.3.4.22: Flags [S], seq 904951907, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1850412 ecr 0], length 0 21:17:55.955487 IP 1.2.3.4.22 > 1.2.3.4.38534: Flags [R.], seq 0, ack 904951908, win 0, length 0 So in this case we actually do use 1.2.3.4! This is on a 8.1 system. A 8.2 system shows the same behaviour and a 7.4 system behaves correctly (i.e.: uses the same address for icmp as for tcp). I tried to investigate the souce code, but my knwoledge about it is a bit rusty :-( -Guido NB: perhaps related: When I do the ping in a vimage on a different VIMAGE-kernel, the ping fails because the source address is never filled in (i.e. is 0.0.0.0) From owner-freebsd-net@FreeBSD.ORG Tue Jan 31 23:52:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B20106564A for ; Tue, 31 Jan 2012 23:52:54 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8C68D8FC08 for ; Tue, 31 Jan 2012 23:52:53 +0000 (UTC) Received: (qmail 57170 invoked from network); 31 Jan 2012 22:13:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Jan 2012 22:13:14 -0000 Message-ID: <4F287ED0.70804@freebsd.org> Date: Wed, 01 Feb 2012 00:52:48 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Guido van Rooij References: <20120131202741.GA4335@gvr.gvr.org> In-Reply-To: <20120131202741.GA4335@gvr.gvr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Difference in address selection between ICMP and TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Jan 2012 23:52:54 -0000 On 31.01.2012 21:27, Guido van Rooij wrote: > > Consider the following: > ifconfig em0 inet 1.2.3.4/24 > ping 1.2.3.4 > > Then a tcpdump on lo0 shows: > 21:15:56.641571 IP 127.0.0.1> 1.2.3.4: ICMP echo request, id 36105, seq 10, length 64 > 21:15:56.641582 IP 1.2.3.4> 127.0.0.1: ICMP echo reply, id 36105, seq 10, length 64 > > I think that the address used should have been 1.2.3.4 and not 127.0.0.1. > > Now when I do a telnet 1.2.3.4 22, I see: > 21:17:55.955475 IP 1.2.3.4.38534> 1.2.3.4.22: Flags [S], seq 904951907, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1850412 ecr 0], length 0 > 21:17:55.955487 IP 1.2.3.4.22> 1.2.3.4.38534: Flags [R.], seq 0, ack 904951908, win 0, length 0 > > So in this case we actually do use 1.2.3.4! > > This is on a 8.1 system. A 8.2 system shows the same behaviour and a 7.4 > system behaves correctly (i.e.: uses the same address for icmp as for > tcp). > > I tried to investigate the souce code, but my knwoledge about it is a > bit rusty :-( The way the source address is determined is different between ping-icmp and TCP. For ping-icmp the source address is filled in ip_output() based on the outgoing interface. For all local addresses, including those on real interfaces the loopback interface is used. You can see that by doing a "netstat -ran". > -Guido > > NB: perhaps related: When I do the ping in a vimage on a different > VIMAGE-kernel, the ping fails because the source address is never > filled in (i.e. is 0.0.0.0) The loopback interface is inaccessible from a jail and thus the source address is never filled in and stays at INADDR_ANY. A fix for either issue is not entirely trivial and fraught with other potential undesired side effects. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 05:04:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE2710681C0 for ; Wed, 1 Feb 2012 05:04:07 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01C028FC21 for ; Wed, 1 Feb 2012 05:04:06 +0000 (UTC) Received: by qcmt40 with SMTP id t40so592828qcm.13 for ; Tue, 31 Jan 2012 21:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericx.net; s=selector0; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7NrmjJ0J49zo8QT5DAloPeYUG8G3+qnJCPMw8HVDyys=; b=gDjWAv5Khx2bIX3GuAyXDLxLqxEudHYCBzZWsSy4BNYvVQ+m7XwErkW56Za0s7Dfqu ANd6uPOvHReNo4TIOOxBssBXHep1fv76zB20mlQjySI/KULkE4CtbSf03BNiSsaADp3U pM/yNEdzMbbHtPHZMjizThqS0NfJtVyKo0O7o= Received: by 10.229.77.15 with SMTP id e15mr7930482qck.66.1328071004125; Tue, 31 Jan 2012 20:36:44 -0800 (PST) Received: from ?IPv6:2001:470:1f07:a3a:0:dead:d00d:ff02? ([2001:470:1f07:a3a:0:dead:d00d:ff02]) by mx.google.com with ESMTPS id dm8sm6946066qab.18.2012.01.31.20.36.43 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 20:36:43 -0800 (PST) Message-ID: <4F28C168.9010206@ericx.net> Date: Tue, 31 Jan 2012 23:36:56 -0500 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 05:04:17 -0000 Seems like a silly question; but how does one allow the packets composing a gif tunnel thru ipfw? I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: $fwcmd add 00140 allow ipencap from $he_tun to me $fwcmd add 00141 allow ipencap from me to $he_tun ($he_tun is an Hurricane Electric provider); but neither of them are hit; so that's wrong... tcpdump -i em_vlan5 -nnvvs0 ip proto 4 doesn't show any packets either... I also have the rule to allow icmp6 thru the gif: $fwcmd add 30132 allow icmp6 from me to any out via gif0 keep-state but that doesn't get hit either. Bottom line: I cannot ping the far end of my ipv6 tunnel. I receive the error "permission denied" ** root@olivia ** ~ ** Tue Jan 31 23:31:43 # ping6 2001:****:****:****::1 PING6(56=40+8+8 bytes) 2001:****:****:****::2 --> 2001:****:****:****::1 ping6: sendmsg: Permission denied ping6: wrote 2001:****:****:****::1 16 chars, ret=-1 ping6: sendmsg: Permission denied Am I even correct in assuming that my gif packets are being blocked? Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 06:17:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821ED1065677 for ; Wed, 1 Feb 2012 06:17:28 +0000 (UTC) (envelope-from edward@carrel.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4803D8FC0A for ; Wed, 1 Feb 2012 06:17:27 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1642157iae.13 for ; Tue, 31 Jan 2012 22:17:27 -0800 (PST) Received: by 10.50.153.133 with SMTP id vg5mr5193157igb.8.1328075675353; Tue, 31 Jan 2012 21:54:35 -0800 (PST) Received: from rowlf.sea.carrel.org (dsl231-050-036.sea1.dsl.speakeasy.net. [216.231.50.36]) by mx.google.com with ESMTPS id mr24sm24746047ibb.1.2012.01.31.21.54.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 21:54:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Edward Carrel In-Reply-To: <4F1E8EAA.2020905@incore.de> Date: Tue, 31 Jan 2012 21:54:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <643377FE-567E-4E40-8E3A-069F3F004133@carrel.org> References: <4F1E8EAA.2020905@incore.de> To: Andreas Longwitz , freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1251.1) Cc: Subject: Re: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 06:17:28 -0000 On Jan 24, 2012, at 2:57 AM, Andreas Longwitz wrote: > Hi Ed, >=20 >> I am running into a roadblock getting PF to filter traffic on >> a Netgraph interface representing an L2TP/IPSec connection. >=20 >> The problem I have is that PF only sees traffic on the outbound >> side of the netgraph interface. >=20 > This happens because the L2TP packets are tagged with an IPSEC-flag = for > later use by ipfw, and this flag is passed to the packets coming from > ng0. Thats done by the netgraph under control of mpd, or better: mpd > does nothing to clear this flag. I was exploring the netgraph sources after sending my original question, = and was developing a suspicion that this is what was going on. =46rom my digging, it didn't look like that mpd would be involved enough = in the communication channel to be able to clear the flag, even if it = wanted to. It would have to be one of the netgraph nodes to do it as the = packet passed by, since mpd only gets informed if a control packet hits = the l2tp note. Or perhaps I am misunderstanding what you mean, or I am = misreading how the data flows around. >=20 > With net.inet.ipsec.filtertunnel=3D1 you can ignore this IPSEC-flag = but > only global for all interfaces in the system. Thats probably not what > you want, especially not for the real hardware interface the > IPSEC-tunnel is going through. It isn't my desired alternative, having already explored that avenue a = while back. I could imagine that I would end up with a severely = complicated pf ruleset even if I could get things to work. >=20 > I think L2TP under control of mpd should work independent of the > existence of an IPSEC-tunnel and therefore clear this flag: >=20 > --- ng_l2tp.c.orig 2010-04-15 14:40:02.000000000 +0200 > +++ ng_l2tp.c 2012-01-23 17:09:41.000000000 +0100 > @@ -752,6 +752,7 @@ > hookpriv_p hpriv =3D NULL; > hook_p hook =3D NULL; > struct mbuf *m; > + struct m_tag *mtag; > u_int16_t tid, sid; > u_int16_t hdr; > u_int16_t ns, nr; > @@ -996,6 +997,11 @@ > ERROUT(0); > } >=20 > + /* Delete an existing ipsec tag */ > + mtag =3D m_tag_find(m, PACKET_TAG_IPSEC_IN_DONE, NULL); > + if (mtag !=3D NULL) > + m_tag_delete(m, mtag); > + > /* Deliver data */ > NG_FWD_NEW_DATA(error, item, hook, m); >=20 > This patch for the l2tp netgraph node does the job and you can use pf = on > the ng0 interface without any restrictions. Very cool. Thanks. I will give this patch a spin, and report back with = my results. A thought that comes to mind; are there other netgraph modules that = would be affected similarly by a packet that comes in with this flag = already set?=20 =46rom what I gathered reading the sources, the same mbuf gets used for = both the L2TP data packet, and the packet encapsulated within -- it = simply trims the header from the mbuf. As such, the mbuf_tags from the = L2TP packet propagate across. This seems like this would not be the most = obvious behavior, at least in some circumstances. I can see perhaps = wanting to propagate things like PF tags from the L2TP packet to the = encapsulated packet across from one interface to another, but I can also = see not wanting to have that happen. If this same sort of thing happens elsewhere, I wonder if this sort of = manipulation wants to happen the moment the packet enters the netgraph = system from a ksocket. Perhaps this will break netgraph behavior = elsewhere that depends on this? I'm also wondering if making the = encapsulated packet even less derivative of the L2TP packet would make = unexpected behavior like what I was observing less likely. Again, I'm = not familiar enough with all the netgraph modules to know what might = depend on this behavior, or if there are historical or functional = reasons to keep the behavior as it is. Thanks, Ed Carrel= From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 06:55:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A4DC1065676 for ; Wed, 1 Feb 2012 06:55:32 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id B00EE8FC18 for ; Wed, 1 Feb 2012 06:55:31 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q116t3EB042495; Wed, 1 Feb 2012 13:55:03 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4F28E1C7.4060209@grosbein.pp.ru> Date: Wed, 01 Feb 2012 13:55:03 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Eric W. Bates" References: <4F28C168.9010206@ericx.net> In-Reply-To: <4F28C168.9010206@ericx.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 06:55:32 -0000 01.02.2012 11:36, Eric W. Bates : > Seems like a silly question; but how does one allow the packets > composing a gif tunnel thru ipfw? > > I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: > > $fwcmd add 00140 allow ipencap from $he_tun to me > $fwcmd add 00141 allow ipencap from me to $he_tun > > ($he_tun is an Hurricane Electric provider); but neither of them are > hit; so that's wrong... > > tcpdump -i em_vlan5 -nnvvs0 ip proto 4 > > doesn't show any packets either... Try: tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 08:06:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3C3721065670 for ; Wed, 1 Feb 2012 08:06:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4BFA91504DE; Wed, 1 Feb 2012 08:06:29 +0000 (UTC) Message-ID: <4F28F284.7070301@FreeBSD.org> Date: Wed, 01 Feb 2012 00:06:28 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20120129 Thunderbird/9.0 MIME-Version: 1.0 To: Eugene Grosbein References: <4F28C168.9010206@ericx.net> <4F28E1C7.4060209@grosbein.pp.ru> In-Reply-To: <4F28E1C7.4060209@grosbein.pp.ru> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 08:06:30 -0000 If it's a hurricane electric tunnel don't you want protocol 41? On 01/31/2012 22:55, Eugene Grosbein wrote: > 01.02.2012 11:36, Eric W. Bates пишет: >> Seems like a silly question; but how does one allow the packets >> composing a gif tunnel thru ipfw? >> >> I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: >> >> $fwcmd add 00140 allow ipencap from $he_tun to me >> $fwcmd add 00141 allow ipencap from me to $he_tun >> >> ($he_tun is an Hurricane Electric provider); but neither of them are >> hit; so that's wrong... >> >> tcpdump -i em_vlan5 -nnvvs0 ip proto 4 >> >> doesn't show any packets either... > > Try: > > tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp > > Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. > > Eugene Grosbein > _______________________________________________ > 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" > -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 08:32:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67B7106566B for ; Wed, 1 Feb 2012 08:32:40 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4B18FC0C for ; Wed, 1 Feb 2012 08:32:40 +0000 (UTC) Received: from ameno.mahoroba.org (IDENT:RIqS4j4zkXJW65g8NEulSKD4ulaD/V8eykinXaGzOoBnRLPu00XHexCTACeXua1v@ameno.mahoroba.org [IPv6:2001:2f0:104:8010:20a:79ff:fe69:ee6b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id q118WQro044376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 17:32:31 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 01 Feb 2012 17:32:26 +0900 Message-ID: From: Hajimu UMEMOTO To: "Eric W. Bates" In-Reply-To: <4F28C168.9010206@ericx.net> References: <4F28C168.9010206@ericx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-RELEASE-p5 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 01 Feb 2012 17:32:32 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 08:32:40 -0000 Hi, >>>>> On Tue, 31 Jan 2012 23:36:56 -0500 >>>>> "Eric W. Bates" said: ericx> Seems like a silly question; but how does one allow the packets ericx> composing a gif tunnel thru ipfw? ericx> I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: ericx> $fwcmd add 00140 allow ipencap from $he_tun to me ericx> $fwcmd add 00141 allow ipencap from me to $he_tun ericx> ($he_tun is an Hurricane Electric provider); but neither of them are ericx> hit; so that's wrong... ericx> tcpdump -i em_vlan5 -nnvvs0 ip proto 4 ericx> doesn't show any packets either... ericx> I also have the rule to allow icmp6 thru the gif: ericx> $fwcmd add 30132 allow icmp6 from me to any out via gif0 keep-state ericx> but that doesn't get hit either. Bottom line: I cannot ping the far ericx> end of my ipv6 tunnel. I receive the error "permission denied" ericx> ** root@olivia ** ~ ** Tue Jan 31 23:31:43 ericx> # ping6 2001:****:****:****::1 ericx> PING6(56=40+8+8 bytes) 2001:****:****:****::2 --> 2001:****:****:****::1 ericx> ping6: sendmsg: Permission denied ericx> ping6: wrote 2001:****:****:****::1 16 chars, ret=-1 ericx> ping6: sendmsg: Permission denied ericx> Am I even correct in assuming that my gif packets are being blocked? Are you trying to pass an IPv6 over IPv4 tunnel? If so, $fwcmd add 00140 allow ip4 from $he_tun to me proto ipv6 $fwcmd add 00141 allow ip4 from me to $he_tun proto ipv6 should work for you. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 14:14:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19FB11065675 for ; Wed, 1 Feb 2012 14:14:03 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C38F88FC0A for ; Wed, 1 Feb 2012 14:14:02 +0000 (UTC) Received: by qcmt40 with SMTP id t40so929622qcm.13 for ; Wed, 01 Feb 2012 06:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericx.net; s=selector0; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mYgmjrqoxLeqhI3zEdMWCLzNAdhglF1E9h+lVc2Gu7s=; b=M7NJoBvwKyXm59vh5Fr0kZge9OCcpRygulcWdjMC5FDPzVjjp0O+hwoG1UIdEsA0fN ykjGi/vgyyjm7wwZmfVp03PGSnm7IMwi3rFQTL5BZmkq5B1ab8JRemkk810ntxGDfwiM phz7Q44Tjbcw5+DvFv7dhR7/5ngkMBVOSyxto= Received: by 10.229.77.134 with SMTP id g6mr10534116qck.33.1328105641627; Wed, 01 Feb 2012 06:14:01 -0800 (PST) Received: from [10.0.0.54] (fw.educompmv.com. [75.150.112.177]) by mx.google.com with ESMTPS id dm7sm47848017qab.5.2012.02.01.06.14.00 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:14:01 -0800 (PST) Message-ID: <4F294839.6060803@ericx.net> Date: Wed, 01 Feb 2012 09:12:09 -0500 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Doug Barton References: <4F28C168.9010206@ericx.net> <4F28E1C7.4060209@grosbein.pp.ru> <4F28F284.7070301@FreeBSD.org> In-Reply-To: <4F28F284.7070301@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Eugene Grosbein Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 14:14:03 -0000 On 2/1/2012 3:06 AM, Doug Barton wrote: > If it's a hurricane electric tunnel don't you want protocol 41? Well, it's a straight up gif. Right this second I'm trying to suss out which protocol gif's use. If it's documented, I can't find it. The closest bit I can find on the man page is: The behavior of gif is mainly based on RFC2893 IPv6-over-IPv4 configured tunnel. I tried to read the pertinent parts of the RFC, but it doesn't really discuss "type" or "protocol". It does talk about some header size issues. Since ipfw is obviously blocking something and I can't get a handle on it with tcpdump, I'm groping for an understanding of the shape of the gif packets. > On 01/31/2012 22:55, Eugene Grosbein wrote: >> 01.02.2012 11:36, Eric W. Bates пишет: >>> Seems like a silly question; but how does one allow the packets >>> composing a gif tunnel thru ipfw? >>> >>> I assumed a gif was made up of ipencap (IP proto 4) packets and added rules: >>> >>> $fwcmd add 00140 allow ipencap from $he_tun to me >>> $fwcmd add 00141 allow ipencap from me to $he_tun >>> >>> ($he_tun is an Hurricane Electric provider); but neither of them are >>> hit; so that's wrong... >>> >>> tcpdump -i em_vlan5 -nnvvs0 ip proto 4 >>> >>> doesn't show any packets either... >> >> Try: >> >> tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp >> >> Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. >> >> Eugene Grosbein >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 14:17:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 488A21065673 for ; Wed, 1 Feb 2012 14:17:09 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 0333F8FC0A for ; Wed, 1 Feb 2012 14:17:08 +0000 (UTC) Received: by qadz30 with SMTP id z30so4007803qad.13 for ; Wed, 01 Feb 2012 06:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericx.net; s=selector0; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CcDZBWdgXxFL0RUVS7ppXJTdbYg7H39/Pux1UurJ/f0=; b=bl1Wlrw20ezHZsnviJhPiMIiZEBUBA/xSKucSqmt9p1TZQW3I/BeTyV+/sExBQqpTR Me+A7HZtv5f0zgrBdhg5qQMFkZgv+dE9tlw1SHU1koTE+q758Dbe2uy7dU4o4sVN+R84 bTNdGGilbei0CfLDaS+OcBfVAlYowhV9DL01M= Received: by 10.224.86.206 with SMTP id t14mr854903qal.59.1328105828429; Wed, 01 Feb 2012 06:17:08 -0800 (PST) Received: from [10.0.0.54] (fw.educompmv.com. [75.150.112.177]) by mx.google.com with ESMTPS id s18sm47849042qaz.15.2012.02.01.06.17.07 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 06:17:07 -0800 (PST) Message-ID: <4F2948F3.1060408@ericx.net> Date: Wed, 01 Feb 2012 09:15:15 -0500 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <4F28C168.9010206@ericx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 14:17:09 -0000 On 2/1/2012 3:32 AM, Hajimu UMEMOTO wrote: > Hi, > ericx> Am I even correct in assuming that my gif packets are being blocked? > > Are you trying to pass an IPv6 over IPv4 tunnel? If so, > > $fwcmd add 00140 allow ip4 from $he_tun to me proto ipv6 > $fwcmd add 00141 allow ip4 from me to $he_tun proto ipv6 > > should work for you. Yes, I'm trying to tunnel in ipv6 from HE. Really? I'm allowing ipv6 packets on the gif0 interface; but not on the lan interface simply because I assumed that like IPSec the encapsulated packets would not be seen as ipv6 on the ethernet interface? > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 14:23:46 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A251E106564A; Wed, 1 Feb 2012 14:23:46 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6688FC14; Wed, 1 Feb 2012 14:23:45 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q11ENdSM045086; Wed, 1 Feb 2012 21:23:39 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4F294AEB.3060405@grosbein.pp.ru> Date: Wed, 01 Feb 2012 21:23:39 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Eric W. Bates" References: <4F28C168.9010206@ericx.net> <4F28E1C7.4060209@grosbein.pp.ru> <4F28F284.7070301@FreeBSD.org> <4F294839.6060803@ericx.net> In-Reply-To: <4F294839.6060803@ericx.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, Doug Barton Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 14:23:46 -0000 01.02.2012 21:12, Eric W. Bates : > On 2/1/2012 3:06 AM, Doug Barton wrote: >> If it's a hurricane electric tunnel don't you want protocol 41? > > Well, it's a straight up gif. Right this second I'm trying to suss out > which protocol gif's use. If it's documented, I can't find it. The > closest bit I can find on the man page is: > > The behavior of gif is mainly based on RFC2893 IPv6-over-IPv4 configured > tunnel. > > I tried to read the pertinent parts of the RFC, but it doesn't really > discuss "type" or "protocol". It does talk about some header size issues. > > Since ipfw is obviously blocking something and I can't get a handle on > it with tcpdump, I'm groping for an understanding of the shape of the > gif packets. Have you tried "tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp" ? I do not use IPv6 over IPv4 tunnels and not sure. Perhaps, that is IPIP protocol (number 94 decimal)? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 15:14:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25CD51065670 for ; Wed, 1 Feb 2012 15:14:40 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 014678FC15 for ; Wed, 1 Feb 2012 15:14:38 +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.5/8.14.5) with ESMTP/inet6 id q11FEL6F036727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 00:14:25 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 02 Feb 2012 00:14:21 +0900 Message-ID: From: Hajimu UMEMOTO To: "Eric W. Bates" In-Reply-To: <4F2948F3.1060408@ericx.net> References: <4F28C168.9010206@ericx.net> <4F2948F3.1060408@ericx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 02 Feb 2012 00:14:25 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 15:14:40 -0000 Hi, >>>>> On Wed, 01 Feb 2012 09:15:15 -0500 >>>>> "Eric W. Bates" said: ericx> On 2/1/2012 3:32 AM, Hajimu UMEMOTO wrote: > Hi, > ericx> Am I even correct in assuming that my gif packets are being blocked? > > Are you trying to pass an IPv6 over IPv4 tunnel? If so, > > $fwcmd add 00140 allow ip4 from $he_tun to me proto ipv6 > $fwcmd add 00141 allow ip4 from me to $he_tun proto ipv6 > > should work for you. ericx> Yes, I'm trying to tunnel in ipv6 from HE. Okay. ericx> Really? I'm allowing ipv6 packets on the gif0 interface; but not on ericx> the lan interface simply because I assumed that like IPSec the ericx> encapsulated packets would not be seen as ipv6 on the ethernet ericx> interface? Still, you need to allow an inner protocol number 41 to use an IPv6 over IPv4 gif tunnel. An inner protocol number of an IPv6 over IPv4 tunnel is 41 which is defined as `ipv6' in /etc/protocols. The ipfw commands I mentioned in my previous mail should do it. Please take notice that `ip4' is an outer protocol and an `ipv6' in a proto option is treated as an inner protocol. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 15:23:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E3E106566B; Wed, 1 Feb 2012 15:23:45 +0000 (UTC) (envelope-from ericx@ericx.net) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id C9F408FC0A; Wed, 1 Feb 2012 15:23:44 +0000 (UTC) Received: by qadz30 with SMTP id z30so4065486qad.13 for ; Wed, 01 Feb 2012 07:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericx.net; s=selector0; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1doiTSI9rzarwZEmnaDMkwI3LMqKmMAXLlINvTnL4cA=; b=Xbma32nUBmlJ6/LJV0tUDL8b9CucTOfXmaDzWRVOZa4DgsxqYwv4T9yxns5unKKTTS MLTzlnpCAUD4Bx8gN8YpEAuGqoX7yiIpjvbot8EjqPPEcWlmFqnIZvCw1LOxsxd/adcj +D3nHcb/OaOZNd7CXxrLSqSUL4r7xC41v22F8= Received: by 10.224.111.147 with SMTP id s19mr33775807qap.45.1328109824212; Wed, 01 Feb 2012 07:23:44 -0800 (PST) Received: from [10.0.0.54] (fw.educompmv.com. [75.150.112.177]) by mx.google.com with ESMTPS id m20sm48160451qaj.14.2012.02.01.07.23.43 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 07:23:43 -0800 (PST) Message-ID: <4F29588F.2090603@ericx.net> Date: Wed, 01 Feb 2012 10:21:51 -0500 From: "Eric W. Bates" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <4F28C168.9010206@ericx.net> <4F2948F3.1060408@ericx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 15:23:45 -0000 [sigh] I stand enlightened with increased understanding. Thank you very much. That is exactly what I've been seeing on my pfSense machine and could not replicate on my stand-alone FBSD box. On 2/1/2012 10:14 AM, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Wed, 01 Feb 2012 09:15:15 -0500 >>>>>> "Eric W. Bates" said: > > ericx> On 2/1/2012 3:32 AM, Hajimu UMEMOTO wrote: >> Hi, > >> ericx> Am I even correct in assuming that my gif packets are being blocked? >> >> Are you trying to pass an IPv6 over IPv4 tunnel? If so, >> >> $fwcmd add 00140 allow ip4 from $he_tun to me proto ipv6 >> $fwcmd add 00141 allow ip4 from me to $he_tun proto ipv6 >> >> should work for you. > > ericx> Yes, I'm trying to tunnel in ipv6 from HE. > > Okay. > > ericx> Really? I'm allowing ipv6 packets on the gif0 interface; but not on > ericx> the lan interface simply because I assumed that like IPSec the > ericx> encapsulated packets would not be seen as ipv6 on the ethernet > ericx> interface? > > Still, you need to allow an inner protocol number 41 to use an IPv6 > over IPv4 gif tunnel. An inner protocol number of an IPv6 over IPv4 > tunnel is 41 which is defined as `ipv6' in /etc/protocols. > The ipfw commands I mentioned in my previous mail should do it. > Please take notice that `ip4' is an outer protocol and an `ipv6' in a > proto option is treated as an inner protocol. > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 15:41:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808C0106566C for ; Wed, 1 Feb 2012 15:41:11 +0000 (UTC) (envelope-from kirk.davis@epsb.ca) Received: from OWA01.EDU.epsb.ca (owa01.epsb.ca [198.161.119.28]) by mx1.freebsd.org (Postfix) with ESMTP id 537068FC15 for ; Wed, 1 Feb 2012 15:41:11 +0000 (UTC) Received: from Exchange26.EDU.epsb.ca ([10.0.5.123]) by OWA01.EDU.epsb.ca with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 08:41:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Feb 2012 08:40:35 -0700 Message-ID: <529374128DC1B04D9D037911B8E8F0531095BC8B@Exchange26.EDU.epsb.ca> In-Reply-To: <4F294AEB.3060405@grosbein.pp.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: allowing gif thru ipfw Thread-Index: Aczg7TbpPTj5/ipNQQ6PQK9MLR6unAACccUA References: <4F28C168.9010206@ericx.net> <4F28E1C7.4060209@grosbein.pp.ru><4F28F284.7070301@FreeBSD.org> <4F294839.6060803@ericx.net> <4F294AEB.3060405@grosbein.pp.ru> From: "Kirk Davis" To: X-OriginalArrivalTime: 01 Feb 2012 15:41:10.0556 (UTC) FILETIME=[EBDCC5C0:01CCE0F7] Subject: RE: allowing gif thru ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 15:41:11 -0000 On Wednesday, February 01, 2012 7:24 AM wrote Eugene Grosbein >01.02.2012 21:12, Eric W. Bates =D0=C9=DB=C5=D4: >> On 2/1/2012 3:06 AM, Doug Barton wrote: >>> If it's a hurricane electric tunnel don't you want protocol 41? >>=20 >> Well, it's a straight up gif. Right this second I'm trying to suss = out=20 >> which protocol gif's use. If it's documented, I can't find it. The=20 >> closest bit I can find on the man page is: >>=20 >> The behavior of gif is mainly based on RFC2893 IPv6-over-IPv4=20 >> configured tunnel. >>=20 >> I tried to read the pertinent parts of the RFC, but it doesn't really = >> discuss "type" or "protocol". It does talk about some header size = issues. >>=20 >> Since ipfw is obviously blocking something and I can't get a handle = on=20 >> it with tcpdump, I'm groping for an understanding of the shape of the = >> gif packets. > >Have you tried "tcpdump -i em_vlan5 -nnvvs0 host $he_tun and not tcp = and not udp and not icmp" ? > >I do not use IPv6 over IPv4 tunnels and not sure. >Perhaps, that is IPIP protocol (number 94 decimal)? I use a number of gif tunnels with ipfw and I have always used 'ipencap' = (protocol 4) for my ipfw rules. One you break it out of the tunnel = though you can then use ipfw one the inside tunnel traffic. I don't = have one with HE right now so they may be different but this is what I = use for a standard ipv4-ipv4 gif tunnel. ---- kirk From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 19:08:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1DF7106564A for ; Wed, 1 Feb 2012 19:08:07 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70ACB8FC17 for ; Wed, 1 Feb 2012 19:08:07 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so1860542bkb.13 for ; Wed, 01 Feb 2012 11:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=2q5+SQyVRVwbxpEtPD4R3ZvNrV2JjsuMrthIXf7oaSg=; b=YJQPFG6PO5DvfqaerY5HOF63xpUbN6Tb2x9zuLM2P3PU2V/okMgvUXnKJa95gjoNxc EyjSUAS9JdyccvEWALtsXSc9EhACEx7BiLiZGi5vmlri8cVXDKrqcfwQb9rnrcT8xlh0 86/GscU1oj3o3BURL49BfFrIA4rS5kykcOMRc= Received: by 10.204.154.86 with SMTP id n22mr12921497bkw.85.1328123286293; Wed, 01 Feb 2012 11:08:06 -0800 (PST) Received: from rimwks1w7x64 ([31.47.167.64]) by mx.google.com with ESMTPS id cg2sm57128104bkb.12.2012.02.01.11.08.04 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 11:08:05 -0800 (PST) From: rozhuk.im@gmail.com To: Date: Thu, 2 Feb 2012 04:07:59 +0900 Message-ID: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: AczhFNASZ92ND36BSlmguxtx4FjCnA== Subject: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 19:08:08 -0000 Hello! The function always returns an error and remove the chain MBUF for two or more generated on the same host. If the pre-call m_defrag no error occurs. This is normal behavior? How to know in advance the maximum size for MBUF that does not cause a failure in m_pullup? mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 20:45:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC52E106566B for ; Wed, 1 Feb 2012 20:45:27 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 620C28FC08 for ; Wed, 1 Feb 2012 20:45:26 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so1972562bkb.13 for ; Wed, 01 Feb 2012 12:45:26 -0800 (PST) Received: by 10.204.152.7 with SMTP id e7mr48306bkw.70.1328129125930; Wed, 01 Feb 2012 12:45:25 -0800 (PST) Received: from [10.254.254.77] (ppp95-165-137-107.pppoe.spdop.ru. [95.165.137.107]) by mx.google.com with ESMTPS id o26sm252749bko.14.2012.02.01.12.45.25 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 12:45:25 -0800 (PST) Message-ID: <4F29A464.3080302@zonov.org> Date: Thu, 02 Feb 2012 00:45:24 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 20:45:27 -0000 Hi, I'm trying to tune machine with 8.2-STABLE for heavy network load and now playing with netisr. Could anyone explain me why actually works only one netisr thread if I set them to 8? loader.conf: net.isr.maxthreads=8 net.isr.bindthreads=0 (also tried set to 1) hw.em.rxd=4096 (net.isr.numthreads is 8 after reboot, `procstat -t 12' shows me 8 netisr threads) sysctl.conf: net.isr.direct=0 net.isr.direct_force=0 (also tried hybrid mode when direct=1, but force_direct=0) NIC: em0@pci0:4:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 EB (Intel PRO/1000 EB)' class = network subclass = ethernet No polling. top: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -44 - 0K 512K CPU7 7 1:18 100.00% {swi1: netisr 7} 11 root 171 ki31 0K 128K CPU3 3 2:15 94.38% {idle: cpu3} 11 root 171 ki31 0K 128K CPU6 6 2:06 90.19% {idle: cpu6} 11 root 171 ki31 0K 128K CPU2 2 2:42 88.67% {idle: cpu2} 11 root 171 ki31 0K 128K CPU1 1 2:22 84.18% {idle: cpu1} 11 root 171 ki31 0K 128K CPU5 5 2:29 75.29% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 4 2:28 69.97% {idle: cpu4} 11 root 171 ki31 0K 128K RUN 0 2:29 69.68% {idle: cpu0} -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 21:14:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0631065687 for ; Wed, 1 Feb 2012 21:14:47 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 846AE8FC15 for ; Wed, 1 Feb 2012 21:14:46 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RshVx-000MXS-5J; Thu, 02 Feb 2012 01:14:49 +0400 Message-ID: <4F29E2C8.5000909@FreeBSD.org> Date: Thu, 02 Feb 2012 01:11:36 +0000 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Andrey Zonov References: <4F29A464.3080302@zonov.org> In-Reply-To: <4F29A464.3080302@zonov.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 21:14:47 -0000 On 01.02.2012 20:45, Andrey Zonov wrote: > Hi, > > I'm trying to tune machine with 8.2-STABLE for heavy network load and > now playing with netisr. Could anyone explain me why actually works only > one netisr thread if I set them to 8? Can you please supply `nestat -Q` output and clarify you usage pattern ? (I mean, this is router/web server/some kind of traffic receiver/etc..). For example, flow policy does not balance traffic from single flow between different CPUs. > > loader.conf: > net.isr.maxthreads=8 > net.isr.bindthreads=0 (also tried set to 1) > hw.em.rxd=4096 > > (net.isr.numthreads is 8 after reboot, `procstat -t 12' shows me 8 > netisr threads) > > sysctl.conf: > net.isr.direct=0 > net.isr.direct_force=0 (also tried hybrid mode when direct=1, but > force_direct=0) > > NIC: > em0@pci0:4:0:0: class=0x020000 card=0x109615d9 chip=0x10968086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel PRO/1000 EB (Intel PRO/1000 EB)' > class = network > subclass = ethernet > > No polling. > > top: > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root -44 - 0K 512K CPU7 7 1:18 100.00% {swi1: netisr 7} > 11 root 171 ki31 0K 128K CPU3 3 2:15 94.38% {idle: cpu3} > 11 root 171 ki31 0K 128K CPU6 6 2:06 90.19% {idle: cpu6} > 11 root 171 ki31 0K 128K CPU2 2 2:42 88.67% {idle: cpu2} > 11 root 171 ki31 0K 128K CPU1 1 2:22 84.18% {idle: cpu1} > 11 root 171 ki31 0K 128K CPU5 5 2:29 75.29% {idle: cpu5} > 11 root 171 ki31 0K 128K RUN 4 2:28 69.97% {idle: cpu4} > 11 root 171 ki31 0K 128K RUN 0 2:29 69.68% {idle: cpu0} > From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 21:28:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2CD3106566C; Wed, 1 Feb 2012 21:28:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 836F68FC13; Wed, 1 Feb 2012 21:28:01 +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.5/8.14.4) with ESMTP id q11LRxR4071539; Wed, 1 Feb 2012 16:27:59 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F29AE63.6050602@sentex.net> Date: Wed, 01 Feb 2012 16:28:03 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jack Vogel References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 21:28:01 -0000 On 1/29/2012 1:21 PM, Jack Vogel wrote: > No, I told Mike I'd get it into 8.x, have just been busy, but will try > and get it pushed up in the queue. Thanks Jack, I see its now MFC'd into RELENG_8! em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] Just curious, does RELENG_9 have this version as well ? ---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 Wed Feb 1 21:50:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC27106566B; Wed, 1 Feb 2012 21:50:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 22C578FC0C; Wed, 1 Feb 2012 21:50:23 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so1911793wgb.31 for ; Wed, 01 Feb 2012 13:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8yrsOM1tNreSorPuik0s//nQN6XDxhHvnyE09COW/4w=; b=A3zwW8042rSLcpmp8iDllG30jhfitW+gyRKRz64wG2W8a8NSesbhYQeffRA96GCRN2 qXTm+yLk4yphFqATHkk9Q0g+VVcljpJtovHF0VVsdpQQ7k1uPhRjOUnJQ2a6PVj04UA7 xWNLDxrWp9CpHLFuCLOxgw/GRW0cMxPrU5YTc= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr686030wib.3.1328133023116; Wed, 01 Feb 2012 13:50:23 -0800 (PST) Received: by 10.180.75.137 with HTTP; Wed, 1 Feb 2012 13:50:23 -0800 (PST) In-Reply-To: <4F29AE63.6050602@sentex.net> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> <4F29AE63.6050602@sentex.net> Date: Wed, 1 Feb 2012 13:50:23 -0800 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, lev@freebsd.org Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 21:50:24 -0000 Huh? I MFC'd into stable/8 does that show up as RELENG? And, I had planned to put it into stable/9 just hadn't gotten to it yet. Making sure the drivers are in 8.3 seems to be the most wanted target. Jack On Wed, Feb 1, 2012 at 1:28 PM, Mike Tancsa wrote: > On 1/29/2012 1:21 PM, Jack Vogel wrote: > > No, I told Mike I'd get it into 8.x, have just been busy, but will try > > and get it pushed up in the queue. > > Thanks Jack, I see its now MFC'd into RELENG_8! > > em1: port 0x2000-0x201f mem > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 > em1: Using MSIX interrupts with 3 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > > Just curious, does RELENG_9 have this version as well ? > > ---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 Wed Feb 1 22:04:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B1D106566B; Wed, 1 Feb 2012 22:04:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD998FC14; Wed, 1 Feb 2012 22:04:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id E771C46B06; Wed, 1 Feb 2012 17:04:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E789B93E; Wed, 1 Feb 2012 17:04:34 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 1 Feb 2012 17:04:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1076713525.20120129133839@serebryakov.spb.ru> <4F29AE63.6050602@sentex.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202011704.19917.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 01 Feb 2012 17:04:34 -0500 (EST) Cc: lev@freebsd.org, Jack Vogel , Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 22:04:35 -0000 On Wednesday, February 01, 2012 4:50:23 pm Jack Vogel wrote: > Huh? I MFC'd into stable/8 does that show up as RELENG? And, I had planned > to > put it into stable/9 just hadn't gotten to it yet. Making sure the drivers > are in 8.3 seems > to be the most wanted target. Err, normally things are merged to newer branches first (e.g. 9 before 8, HEAD before stable, etc.). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 23:05:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89B8106566B; Wed, 1 Feb 2012 23:05:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDA878FC0A; Wed, 1 Feb 2012 23:05:48 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so2052970wib.13 for ; Wed, 01 Feb 2012 15:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cffi2v31T8y90Z7JS48QRHURzO5hmonidxQiBZW0azM=; b=cakujNeTsrLBWAufMwNlg2JoVY/Q5hnwmeZYMcPj/idp98zzU4TJ30VsKodg9bm7I3 ct5i3nW466H2LomGneEjYaKnF8g87RxSb8vhF5G4nSzi/5Pu4fxeYoLhv9M3NJi88L6I gFiVyJPFTgdKBjB7DumcCFj6ObVH1uZq3RJ5M= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr1106735wib.3.1328137546596; Wed, 01 Feb 2012 15:05:46 -0800 (PST) Received: by 10.180.75.137 with HTTP; Wed, 1 Feb 2012 15:05:46 -0800 (PST) In-Reply-To: <201202011704.19917.jhb@freebsd.org> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F29AE63.6050602@sentex.net> <201202011704.19917.jhb@freebsd.org> Date: Wed, 1 Feb 2012 15:05:46 -0800 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, lev@freebsd.org, Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 23:05:49 -0000 Normally, except I have real world customers that have explicitly told me they needed something in 8.3 whereas no one has said they cared about stable/9, that's why I did it first, I've never been aware that there was some 'trickle-down' hierarchy, have always assumed its head or its stable :) Jack On Wed, Feb 1, 2012 at 2:04 PM, John Baldwin wrote: > On Wednesday, February 01, 2012 4:50:23 pm Jack Vogel wrote: > > Huh? I MFC'd into stable/8 does that show up as RELENG? And, I had > planned > > to > > put it into stable/9 just hadn't gotten to it yet. Making sure the > drivers > > are in 8.3 seems > > to be the most wanted target. > > Err, normally things are merged to newer branches first (e.g. 9 before 8, > HEAD before stable, etc.). > > -- > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 23:34:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE87106564A; Wed, 1 Feb 2012 23:34:21 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 333418FC0A; Wed, 1 Feb 2012 23:34:21 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rsjgk-00033l-Ek; Wed, 01 Feb 2012 18:34:06 -0500 Date: Wed, 1 Feb 2012 18:34:06 -0500 From: Gary Palmer To: Jack Vogel Message-ID: <20120201233406.GA10082@in-addr.com> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> <4F29AE63.6050602@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org, lev@freebsd.org, Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 23:34:21 -0000 On Wed, Feb 01, 2012 at 01:50:23PM -0800, Jack Vogel wrote: > Huh? I MFC'd into stable/8 does that show up as RELENG? I suspect different SCMs here is causing terminology confusion. RELENG_8 is the CVS version of the stable/8 branch in SVN. Gary From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 23:59:42 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82AA106564A; Wed, 1 Feb 2012 23:59:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BEC3F8FC13; Wed, 1 Feb 2012 23:59:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q11Nxga9043799; Wed, 1 Feb 2012 23:59:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q11NxgnI043795; Wed, 1 Feb 2012 23:59:42 GMT (envelope-from linimon) Date: Wed, 1 Feb 2012 23:59:42 GMT Message-Id: <201202012359.q11NxgnI043795@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164696: [netinet] [patch] VIMAGE + carp panics the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Feb 2012 23:59:43 -0000 Old Synopsis: VIMAGE + carp panics the kernel New Synopsis: [netinet] [patch] VIMAGE + carp panics the kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 1 23:59:08 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164696 From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 06:23:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67CA11065672 for ; Thu, 2 Feb 2012 06:23:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9CD8FC1D for ; Thu, 2 Feb 2012 06:23:16 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q126NER1016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Feb 2012 22:23:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F2A2C1F.1060609@freebsd.org> Date: Wed, 01 Feb 2012 22:24:31 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Rozhuk.IM@gmail.com References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> In-Reply-To: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 06:23:17 -0000 On 2/1/12 11:07 AM, rozhuk.im@gmail.com wrote: > Hello! > > > The function always returns an error and remove the chain MBUF for two or > more generated on the same host. > If the pre-call m_defrag no error occurs. > This is normal behavior? > How to know in advance the maximum size for MBUF that does not cause a > failure in m_pullup? > send the list more information.. like where it is being called from, or a stack trace, or what are you trying to do? > mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 > mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > _______________________________________________ > 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 Feb 2 06:35:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A84106564A for ; Thu, 2 Feb 2012 06:35:31 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC3C28FC0C for ; Thu, 2 Feb 2012 06:35:30 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so2406586bkb.13 for ; Wed, 01 Feb 2012 22:35:29 -0800 (PST) Received: by 10.204.150.69 with SMTP id x5mr724271bkv.53.1328164529078; Wed, 01 Feb 2012 22:35:29 -0800 (PST) Received: from [10.254.254.77] (ppp95-165-140-229.pppoe.spdop.ru. [95.165.140.229]) by mx.google.com with ESMTPS id ek9sm3995560bkb.10.2012.02.01.22.35.28 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 22:35:28 -0800 (PST) Message-ID: <4F2A2EAB.3010700@zonov.org> Date: Thu, 02 Feb 2012 10:35:23 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> In-Reply-To: <4F29E2C8.5000909@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 06:35:31 -0000 On 02.02.2012 5:11, Alexander V. Chernikov wrote: > On 01.02.2012 20:45, Andrey Zonov wrote: >> Hi, >> >> I'm trying to tune machine with 8.2-STABLE for heavy network load and >> now playing with netisr. Could anyone explain me why actually works only >> one netisr thread if I set them to 8? > > Can you please supply `nestat -Q` output and clarify you usage pattern ? > (I mean, this is router/web server/some kind of traffic receiver/etc..). > For example, flow policy does not balance traffic from single flow > between different CPUs. > This is a web server with multiple nginx instances. 5k/sec accepted connections. Input packet rate is 35kpps, output - 25kpps. I thought of changing policy for IP, but how can I do this (without patching)? Is it safe? netstat -Q (I turned on direct & direct force for now): Configuration: Setting Value Maximum Thread count 8 8 Default queue limit 256 10240 Direct dispatch enabled n/a Forced direct dispatch enabled n/a Threads bound to CPUs enabled n/a Protocols: Name Proto QLimit Policy Flags ip 1 5000 flow --- igmp 2 256 source --- rtsock 3 256 source --- arp 7 256 source --- ip6 10 256 flow --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 0 1125716 0 0 0 1125716 igmp 0 0 0 0 0 0 0 rtsock 0 1 0 0 0 102 102 arp 0 0 27 0 0 0 27 ip6 0 0 0 0 0 0 0 1 1 ip 0 0 1222701 0 0 0 1222701 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 46 0 0 0 46 ip6 0 0 0 0 0 0 0 2 2 ip 0 0 1184381 0 0 0 1184381 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 45 0 0 0 45 ip6 0 0 0 0 0 0 0 3 3 ip 0 0 1191094 0 0 0 1191094 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 54 0 0 0 54 ip6 0 0 0 0 0 0 0 4 4 ip 0 0 846165 0 0 0 846165 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 19 0 0 0 19 ip6 0 0 0 0 0 0 0 5 5 ip 0 0 849478 0 0 0 849478 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 27 0 0 0 27 ip6 0 0 0 0 0 0 0 6 6 ip 0 0 870836 0 0 0 870836 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 0 29 0 0 0 29 ip6 0 0 0 0 0 0 0 7 7 ip 0 5000 594320 5 910862 3453459 4047784 igmp 0 0 0 0 0 0 0 rtsock 0 0 0 0 0 0 0 arp 0 5 21 0 0 109 130 ip6 0 1 0 0 0 1 1 -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 06:53:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F083C1065675 for ; Thu, 2 Feb 2012 06:53:48 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF2508FC21 for ; Thu, 2 Feb 2012 06:53:48 +0000 (UTC) Received: by qcmt40 with SMTP id t40so1649036qcm.13 for ; Wed, 01 Feb 2012 22:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EVpvmCW21ZFp6BmpZJQzQB8hNGh+D5xLzEBxkVR4fls=; b=K/cYqki3M9KcCcczNa00UQ65OzlqTX+aQrZgUhOdwWyKPx7EkHe73ybw1fgLYpSfFL 61QUaNcwiN1DzT4Kccg0/S/y3IzEJSgByj2lOmPC4qlTmsivA1bEyInIJQfWroGifu9d QdekyHdI8jQSlaoyJHII6H5vlY0rfQ0mBocE0= MIME-Version: 1.0 Received: by 10.224.10.19 with SMTP id n19mr2144338qan.68.1328165628060; Wed, 01 Feb 2012 22:53:48 -0800 (PST) Received: by 10.229.222.202 with HTTP; Wed, 1 Feb 2012 22:53:48 -0800 (PST) In-Reply-To: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> Date: Wed, 1 Feb 2012 22:53:48 -0800 Message-ID: From: Navdeep Parhar To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 06:53:49 -0000 On Wed, Feb 1, 2012 at 11:07 AM, wrote: > Hello! > > > The function always returns an error and remove the chain MBUF for two or > more generated on the same host. > If the pre-call m_defrag no error occurs. > This is normal behavior? > How to know in advance the maximum size for MBUF that does not cause a > failure in m_pullup? You can't pullup more than MHLEN bytes into a pkthdr mbuf if it's not associated with an external cluster. See the last sentence in this excerpt from mbuf(9): m_pullup(mbuf, len) Arrange that the first len bytes of an mbuf chain are contiguous and lay in the data area of mbuf, so they are accessible with mtod(mbuf, type). It is important to remember that this may involve reallocating some mbufs and moving data so all pointers referencing data within the old mbuf chain must be recalculated or made invalid. Return the new mbuf chain on success, NULL on fail- ure (the mbuf chain is freed in this case). Note: It does not allocate any mbuf clusters, so len must be less than MHLEN. Regards, Navdeep > > > mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 > mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > _______________________________________________ > 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 Feb 2 08:34:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323E0106564A for ; Thu, 2 Feb 2012 08:34:11 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id B22218FC1A for ; Thu, 2 Feb 2012 08:34:10 +0000 (UTC) Received: from [89.204.137.128] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Rss7K-0004Nr-Fn; Thu, 02 Feb 2012 09:34:07 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q128YlM2001187; Thu, 2 Feb 2012 09:34:49 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q128YilJ001186; Thu, 2 Feb 2012 09:34:44 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 2 Feb 2012 09:34:44 +0100 From: Matthias Apitz To: Milan Obuch , freebsd-net@freebsd.org, edwin@mavetju.org Message-ID: <20120202083441.GA1171@tiny> References: <20120130110919.GA1249@tiny> <20120131094413.GA1306@tiny> <20120131110100.0da8b89e@atom.dino.sk> <20120131101930.GA1371@tiny> <20120131115348.0748df3a@atom.dino.sk> <20120131124347.GA1493@tiny> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120131124347.GA1493@tiny> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.137.128 Cc: Subject: Re: ports/net/e169-stats (was: UMTS Huawei monitor) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 08:34:11 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit El da Tuesday, January 31, 2012 a las 01:43:47PM +0100, Matthias Apitz escribi: > At the end I decided to understand the source code. Btw: the device port > /dev/cuaU0.n is hardcoded set to .2, while mine is .3 for the E1750; Hello, While digging into the source, I saw that I was wrong saying that; only the default is hardcoded set to .2 and if one provides an argument on the cmd line, this is used; don't know how I have overlooked that; Edwin, please accept my honestly sorry for this; I did some minor cosmetic changes (attached) for your consideration; in any case, now I have it clear why in some place where I sit reading with my netbook, the bandwidth and speed is so poor: the RSSI value there is only 2-3 in that place; it is a relatively new building with a lot of steel and concrete; the distance from the table to the windows is around 5-6 meters; when I move to the window the RSSI value is ~14, outside as well; in short words: your tool, Edwin, helped me a lot to get a clear picture of my problem; thanks! matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff *** e169-stats.c.orig 2011-03-08 07:47:40.000000000 +0100 --- e169-stats.c 2012-01-31 22:14:32.000000000 +0100 *************** *** 120,126 **** v3 /= 1000; } ! mvwprintw(screen, Y - 1 - (v2 * yscale) / v1, 0, "%u%cB", v3, prefix); return (v1); } --- 120,128 ---- v3 /= 1000; } ! wattrset(screen, colour[scbar[0].sb_mode]); ! mvwprintw(screen, Y - 1 - (v2 * yscale) / v1, 0, "%u%cbps", v3*8, prefix); ! wattrset(screen, colour[1]); return (v1); } *************** *** 153,160 **** bytestosomething(rxtotal, srxtotal, sizeof(srxtotal)); bytestosomething(txtotal, stxtotal, sizeof(stxtotal)); ! bytestosomething(rxnow, srxnow, sizeof(srxnow)); ! bytestosomething(txnow, stxnow, sizeof(stxnow)); int X = getmaxx(screen); int Y = getmaxy(screen); --- 155,164 ---- bytestosomething(rxtotal, srxtotal, sizeof(srxtotal)); bytestosomething(txtotal, stxtotal, sizeof(stxtotal)); ! // bytestosomething(rxnow, srxnow, sizeof(srxnow)); ! // bytestosomething(txnow, stxnow, sizeof(stxnow)); ! snprintf(srxnow, sizeof(srxnow), "%1.03f Mbps", (double)rxnow*8/1024/1024); ! snprintf(stxnow, sizeof(stxnow), "%1.03f Mbps", (double)txnow*8/1024/1024); int X = getmaxx(screen); int Y = getmaxy(screen); *************** *** 176,183 **** mvwprintw(screen, 3, 0, "RSSI: %d dBm (%d)", 2 * scbar[0].sb_ssi - 113, scbar[0].sb_ssi); mvwprintw(screen, 4, 0, "Total: %s / %s", stxtotal, srxtotal); mvwprintw(screen, 5, 0, "Now: %s / %s", stxnow, srxnow); ! // mvwprintw(screen, 6, 0, "Last: %d / %d", scbar[0].sb_tx, scbar[0].sb_rx); int i; for (i = -9; i <= 0; i++) { --- 180,189 ---- mvwprintw(screen, 3, 0, "RSSI: %d dBm (%d)", 2 * scbar[0].sb_ssi - 113, scbar[0].sb_ssi); mvwprintw(screen, 4, 0, "Total: %s / %s", stxtotal, srxtotal); + wattrset(screen, colour[scbar[0].sb_mode]); mvwprintw(screen, 5, 0, "Now: %s / %s", stxnow, srxnow); ! wattrset(screen, colour[1]); ! // mvwprintw(screen, 6, 0, "Last: %d / %d", scbar[1].sb_tx, scbar[1].sb_rx); int i; for (i = -9; i <= 0; i++) { *************** *** 216,230 **** mvwaddch(screen, Y - 1 - (ssi / LENGTH(c)), X - i, colour[scbar[i].sb_mode] | c[ssi % LENGTH(c)]); } if (scbar[i].sb_tx > 0) { mvwaddch(screen, Y - 1 - (scbar[i].sb_tx * yscale) / vol, X - i, colour[scbar[i].sb_mode] | '^'); } if (scbar[i].sb_rx > 0) { mvwaddch(screen, Y - 1 - (scbar[i].sb_rx * yscale) / vol, ! X - i, colour[scbar[i].sb_mode] | 'v'); } if (scbar[i].sb_rx == 0 && scbar[i].sb_tx == 0) { mvwaddch(screen, Y - 1, --- 222,244 ---- mvwaddch(screen, Y - 1 - (ssi / LENGTH(c)), X - i, colour[scbar[i].sb_mode] | c[ssi % LENGTH(c)]); } + int y1, y2; + int v; if (scbar[i].sb_tx > 0) { + y1 = Y - 1 - (scbar[i].sb_tx * yscale) / vol; mvwaddch(screen, Y - 1 - (scbar[i].sb_tx * yscale) / vol, X - i, colour[scbar[i].sb_mode] | '^'); } if (scbar[i].sb_rx > 0) { + y2 = Y - 1 - (scbar[i].sb_rx * yscale) / vol; + v = 'v'; + /* 'v' and '^' don't fit into same place + * if so we use 'x' */ + if (y1 == y2) v = 'x'; mvwaddch(screen, Y - 1 - (scbar[i].sb_rx * yscale) / vol, ! X - i, colour[scbar[i].sb_mode] | v); } if (scbar[i].sb_rx == 0 && scbar[i].sb_tx == 0) { mvwaddch(screen, Y - 1, *************** *** 282,288 **** int i; fd_set fdset; int empty = 0; ! const char *dev = "/dev/cuaU0.2"; struct timeval timeout; int isfile; --- 296,302 ---- int i; fd_set fdset; int empty = 0; ! const char *dev = "/dev/cuaU0.3"; struct timeval timeout; int isfile; --RnlQjJ0d97Da+TV1-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 08:59:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 838491065672; Thu, 2 Feb 2012 08:59:37 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward8.mail.yandex.net (forward8.mail.yandex.net [IPv6:2a02:6b8:0:202::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2388FC13; Thu, 2 Feb 2012 08:59:36 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward8.mail.yandex.net (Yandex) with ESMTP id A57C0F61FC7; Thu, 2 Feb 2012 12:59:34 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328173174; bh=Z66qFfSUmvG8yBgLP67s6h0ctmCW0H/VhodzloIW89s=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=udMCSdvw4NN4uPt3RyonmS6SXjyDzRfAg7+OPcPm/GLYdUr3WvWIsj2hp8FlbsPx0 jida+4YFe96C+oSaHYg7xj6CO3pDGpbtBRuD81Y/kDd37/W6EtHUcbg8sJ+q88oZ5C 2r9FSoGV+qAfxCilH29Sedkm6bkeNsf6V85ES6RY= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id 6F9D41B604F8; Thu, 2 Feb 2012 12:59:34 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328173174; bh=Z66qFfSUmvG8yBgLP67s6h0ctmCW0H/VhodzloIW89s=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=udMCSdvw4NN4uPt3RyonmS6SXjyDzRfAg7+OPcPm/GLYdUr3WvWIsj2hp8FlbsPx0 jida+4YFe96C+oSaHYg7xj6CO3pDGpbtBRuD81Y/kDd37/W6EtHUcbg8sJ+q88oZ5C 2r9FSoGV+qAfxCilH29Sedkm6bkeNsf6V85ES6RY= Received: from unknown (unknown [77.93.52.19]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id xXtuKItO-xXtudeWl; Thu, 2 Feb 2012 12:59:34 +0400 X-Yandex-Spam: 1 Date: Thu, 2 Feb 2012 10:59:12 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <1446971288.20120202105912@yandex.ru> To: Andrey Zonov In-Reply-To: <4F2A2EAB.3010700@zonov.org> References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, "Alexander V. Chernikov" Subject: Re[2]: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 08:59:37 -0000 , Andrey. 2 2012 ., 8:35:23: AZ> On 02.02.2012 5:11, Alexander V. Chernikov wrote: >> On 01.02.2012 20:45, Andrey Zonov wrote: >>> Hi, >>> >>> I'm trying to tune machine with 8.2-STABLE for heavy network load and >>> now playing with netisr. Could anyone explain me why actually works only >>> one netisr thread if I set them to 8? >> >> Can you please supply `nestat -Q` output and clarify you usage pattern ? >> (I mean, this is router/web server/some kind of traffic receiver/etc..). >> For example, flow policy does not balance traffic from single flow >> between different CPUs. >> AZ> This is a web server with multiple nginx instances. 5k/sec accepted AZ> connections. Input packet rate is 35kpps, output - 25kpps. AZ> I thought of changing policy for IP, but how can I do this (without AZ> patching)? Is it safe? AZ> netstat -Q (I turned on direct & direct force for now): AZ> Configuration: AZ> Setting Value Maximum AZ> Thread count 8 8 AZ> Default queue limit 256 10240 AZ> Direct dispatch enabled n/a AZ> Forced direct dispatch enabled n/a AZ> Threads bound to CPUs enabled n/a AZ> Protocols: AZ> Name Proto QLimit Policy Flags AZ> ip 1 5000 flow --- AZ> igmp 2 256 source --- AZ> rtsock 3 256 source --- AZ> arp 7 256 source --- AZ> ip6 10 256 flow --- AZ> Workstreams: AZ> WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled AZ> 0 0 ip 0 0 1125716 0 0 0 1125716 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 1 0 0 0 102 102 AZ> arp 0 0 27 0 0 0 27 AZ> ip6 0 0 0 0 0 0 AZ> 1 1 ip 0 0 1222701 0 0 0 1222701 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 46 0 0 0 46 AZ> ip6 0 0 0 0 0 0 AZ> 2 2 ip 0 0 1184381 0 0 0 1184381 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 45 0 0 0 45 AZ> ip6 0 0 0 0 0 0 AZ> 3 3 ip 0 0 1191094 0 0 0 1191094 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 54 0 0 0 54 AZ> ip6 0 0 0 0 0 0 AZ> 4 4 ip 0 0 846165 0 0 0 846165 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 19 0 0 0 19 AZ> ip6 0 0 0 0 0 0 AZ> 5 5 ip 0 0 849478 0 0 0 849478 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 27 0 0 0 27 AZ> ip6 0 0 0 0 0 0 AZ> 6 6 ip 0 0 870836 0 0 0 870836 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 0 29 0 0 0 29 AZ> ip6 0 0 0 0 0 0 AZ> 7 7 ip 0 5000 594320 5 910862 3453459 4047784 AZ> igmp 0 0 0 0 0 0 AZ> rtsock 0 0 0 0 0 0 AZ> arp 0 5 21 0 0 109 130 AZ> ip6 0 1 0 0 0 1 same problem, it is because one netisr take 100% so other threads stops?? to work fine. or packet scheduler has disbalanced scheduler and still trying to schedule packet to netisr:7 despite on it is 100% busy. -- , mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 09:12:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 465F41065672; Thu, 2 Feb 2012 09:12:32 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E28488FC0A; Thu, 2 Feb 2012 09:12:31 +0000 (UTC) Received: by ggnk5 with SMTP id k5so1506226ggn.13 for ; Thu, 02 Feb 2012 01:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E4zsNyKPzGse+l82R6RaU/UefCXXR2lwDY3nI9vTKB4=; b=r6JJbbLrzJgbQ7d87/5BxSSQeJOjHerlYpbrEreappI5o4wOt06hjsJLJGfAFt+Yoy wTuSxbbP6WsiiTQvr3BdqRpPbSxs7lDk65ENP317EJVZU48fPN41jQVJbBwcXn7cQG8e 0Lj/nihFy1gQRGmXhP3X54yFRpZ051ABYT+hw= MIME-Version: 1.0 Received: by 10.50.170.41 with SMTP id aj9mr2358525igc.0.1328173950167; Thu, 02 Feb 2012 01:12:30 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.134.198 with HTTP; Thu, 2 Feb 2012 01:12:30 -0800 (PST) In-Reply-To: <20120131110204.GA95472@onelab2.iet.unipi.it> References: <20120131110204.GA95472@onelab2.iet.unipi.it> Date: Thu, 2 Feb 2012 10:12:30 +0100 X-Google-Sender-Auth: ufuFW3M-I2wlrwobm5UDMiQ62OM Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 09:12:32 -0000 On Tue, Jan 31, 2012 at 12:02 PM, Luigi Rizzo wrote: > On Mon, Jan 30, 2012 at 01:01:13PM +0100, Ermal Lu?i wrote: >> Hello, >> >> from needs on pfSense a patch for allowing multiple intances of >> ipfw(4) in kernel to co-exist was developed. >> It can be found here >> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_= 9_0/CP_multi_instance_ipfw.diff >> >> It is used in conjuction with this tool >> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_co= ntext/files/ipfw_context.c >> It allows creation of contextes/instances and assignment of specific >> interfaces to specific contexts/instances. >> >> Surely i know that this is not the best way to implement generically >> but it gets the job done for us as it is, read below. >> >> What i would like to know is if there is interest to see such >> functionality in FreeBSD? >> >> I am asking first to see if there is some consensus about this as a >> feature, needed or not! >> If interest is shown i will transform the patch to allow: >> - ipfw(8) to manage the contextes create/destroy >> - ipfw(8) to manage interface membership. Closing the race of two >> parallell clients modifying different contextes. >> >> There is another design choice to be made about storing the membership >> of interfaces into contexts/instances, but i do not see that as >> blocking. >> >> It is quite handy feature, which can be exploited even to scale on SMP >> machines by extending it to bind a specific instance(with its >> interaces) to a specific CPU/core?! >> >> Comments/Feedback expected, > > if i understand what the patch does, i think it makes sense to be > able to hook ipfw instances to specific interfaces/sets of interfaces, > as it permits the writing of more readable rulesets. Right now the > workaround is start the ruleset with skipto rules matching on > interface names, and then use some discipline in "reserving" a range > of rule numbers to each interface. > > Before making more changes to the code, > it would help if you could give a high level description of > > 1. what the change does and how specific cases are handled. E.g. > =A0 =A0 =A0 =A0With this change you can create multiple rulesets (context= s ?) > =A0 =A0 =A0 =A0and bind one or more interfaces to a context. In man simple words it can give you multiple rulesets in ipfw(4) together with ability to restrict the ruleset to specific interfaces. As it is written today it forces you to create the relation of interface(s) and rulesets explicitly. Though its debatable you would want the freedom of one interface to more than one ruleset. The target of this patch was strictly layer2 filtering with ipfw(4) and allowing easy managebility of multiple instances of an userland application using ipfw(4) at layer2 for filtering/forwarding/QoS purposes. > =A0 =A0 =A0 =A0- what happens with outgoing packets where the context > =A0 =A0 =A0 =A0 =A0to be picked up depend on the route in effect at the t= ime > =A0 =A0 =A0 =A0 =A0of the transmission ? For this i have not given much thought but makes sense only on satetful tracking of sessions in ipfw(4). See below for a solution implemented along with this patch. > =A0 =A0 =A0 =A0- what happens with encapsulated interfaces (vlan) ? Well by the very nature of this patch is that you have to explicitly assign an interface to the ruleset. This by definition of vlan/cloned interfaces in FreeBSD means you have to assign them to the ruleset explicitly too. In pfSense for example, since ipfw(4) is used exlusivly at layer2 it was necessary to introduce another flag and be very explicit on which interface is considered for filtering in ipfw(4). Also problems were faced on determining what was considered incoming and what outgoing when calling the ipfw hooks. This was changed to be explicit as well. Otherwise you have to play a tricky game of rules and what interface a particual pattern of traffic belongs and write respective rules about it, which is no fun at all from implementations and administration point of vie= w. > =A0 =A0 =A0 =A0- can you skipto across contexts (i guess not) ? > No its not there but it can be a possible addition. > 2. how intrusive are code changes ? The kernel patch you show > =A0 seems small, which makes sense as i believe all is needed is > =A0 to start from a specific chain instead of the default one when > =A0 an interface is bound to a context. A few comments: > =A0 =A0 =A0 =A0- if you use one of the if_ispare directly, instead of > =A0 =A0 =A0 =A0 =A0renaming it to if_context, this would make backporting= and > =A0 =A0 =A0 =A0 =A0testing easier. > =A0 =A0 =A0 =A0- I think the explosion of sockopt names is a bad thing. > =A0 =A0 =A0 =A0 =A0The IP_FW3 command was introduced exactly to have a si= ngle > =A0 =A0 =A0 =A0 =A0entry point to the firewall and avoid a ton of new nam= es > =A0 =A0 =A0 =A0 =A0in raw_ip.c and in.h > =A0 =A0 =A0 =A0- can you reduce the number of global ipfw-related variabl= es ? > =A0 =A0 =A0 =A0 =A0There used to be one (layer3_chain), now you have 3 of= them. > =A0 =A0 =A0 =A0 =A0You should delete layer3_chain and replace it with ano= ther > =A0 =A0 =A0 =A0 =A0single global (could be ip_fw_contexts) which contains= the > =A0 =A0 =A0 =A0 =A0whole firewall state. > =A0 =A0 =A0 =A0- how do you handle reinjects (e.g. from dummynet or diver= t) ? > =A0 =A0 =A0 =A0 =A0I don't remember if the metadata that stores where you > =A0 =A0 =A0 =A0 =A0reinject the packet also has a pointer to the root of = the > =A0 =A0 =A0 =A0 =A0chain. As described above a change to explicitly mark a packet incoming/outgoing interface in ipfw(4) metadata(mbuf tag) was needed. This is a patch, which is a bit verbose with other changed things in ipfw https://github.com/bsdperimeter/pfsense-tools/blob/master/patches/RELE= NG_9_0/CP_speedup.diff, has also the various bits i am talking for saving the interface and direction explicitly. > =A0 =A0 =A0 =A0- i don't completely follow the connection between ip_fw_c= hain, > =A0 =A0 =A0 =A0 =A0ip_fw_ctx_iflist, ip_fw_ctxmember, ip_fw_ctx, ip_fw_ct= x_list. > =A0 =A0 =A0 =A0 =A0The way i see it: > =A0 =A0 =A0 =A0 =A0- the ip_fw_chain could be embedded in the ip_fw_ctx, = as they > =A0 =A0 =A0 =A0 =A0 =A0map 1:1 yep that is probably a better place to put the chain and easys the integration with ipfw(8) command. > =A0 =A0 =A0 =A0 =A0- why do you need ip_fw_ctx_iflist and ip_fw_ctxmember= ? > =A0 =A0 =A0 =A0 =A0 =A0You should never need to determine context members= hip > =A0 =A0 =A0 =A0 =A0 =A0during packet processing, and for sockopt calls yo= u could > =A0 =A0 =A0 =A0 =A0 =A0as well iterate over the list of interfaces; ip_fw_ctx_iflist is used for being able to reassign an interface to its configured context. This is useful on dynamic interfaces that come and go example vlan(4). Its easier to handle this in kernel than in userland, where you have to detect the event and do the various reconfiguration things. ip_fw_ctxmember is just a simple way for the various new sockopt to pass the argument. It for sure can be recycled and implemented in a more clean way. I will try to make a patch with your recommandations and integrate the add/remove/delete of interfaces/contexts in ipfw and resend again. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 09:33:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A121065672; Thu, 2 Feb 2012 09:33:39 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward18.mail.yandex.net (forward18.mail.yandex.net [IPv6:2a02:6b8:0:1402::3]) by mx1.freebsd.org (Postfix) with ESMTP id 006E98FC12; Thu, 2 Feb 2012 09:33:37 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward18.mail.yandex.net (Yandex) with ESMTP id 4214C178209C; Thu, 2 Feb 2012 13:33:36 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328175216; bh=UaJgGsKTAL+QVyNaqsVEdVRK8vcW4wmcu18Z6Kt4Q3A=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:MIME-Version: Content-Type; b=OoiJbku+mrUMBdieNIp8H95pOe3AS+/Ls6qL7oYC4PikdtJpYztdceIdGHi18OKsd Bj7MyF8rio+Stx03cyZYwdbrvS5or2piNddGRzFdrGfq+URCvwDjoKkmaRBfuyBDsO kUjvClzuoWU4t6ruNhUpPd1Uc3OiPlPn+b39APQc= Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 1C02B18A0195; Thu, 2 Feb 2012 13:33:36 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328175216; bh=UaJgGsKTAL+QVyNaqsVEdVRK8vcW4wmcu18Z6Kt4Q3A=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:MIME-Version: Content-Type; b=OoiJbku+mrUMBdieNIp8H95pOe3AS+/Ls6qL7oYC4PikdtJpYztdceIdGHi18OKsd Bj7MyF8rio+Stx03cyZYwdbrvS5or2piNddGRzFdrGfq+URCvwDjoKkmaRBfuyBDsO kUjvClzuoWU4t6ruNhUpPd1Uc3OiPlPn+b39APQc= Received: from unknown (unknown [77.93.52.19]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id XZ9W6KLV-XZ9i5ukR; Thu, 2 Feb 2012 13:33:35 +0400 X-Yandex-Spam: 1 Date: Thu, 2 Feb 2012 11:33:14 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <67410574.20120202113314@yandex.ru> To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------121AA244ACEB5B4" Cc: freebsd-net@freebsd.org Subject: HowTo easy use IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:33:39 -0000 ------------121AA244ACEB5B4 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit this is the mine script which helps me keep my firewall very clean and safe. It is easy to understand even if you have a thousands rules, I think =) please comment. PS. If anybody may, please put into ports tree. thank you. ------------121AA244ACEB5B4 Content-Type: application/octet-stream; name="usr-local-etc-firewall.rar" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="usr-local-etc-firewall.rar" UmFyIRoHAM+QcwAADQAAAAAAAABWaXQgkEQANwIAAHsEAAACE3YJNhlbQkAdMx8AIAAAAHVz ci1sb2NhbC1ldGMtZmlyZXdhbGxcZi5yZWFkbWUAsDrTdA3BDMzM/RwVvefCkL4zykaks/l7 w1E10uFAglAw11G8sFm05GIm1M025r97wCt0mhTiKYc1t1F+BTwbjC48e4nm/jh7iUi+JLKH cvxRAXqvbVPPs9zz2s6rsp57tBnlJinhPS8aGk0sB4fvFHMfaZCLoLkRatfUkbQiQx0nmDkc 9sk6Ua072Y0QKgIol5+/dvYsl0u5e34RK39fuN6cItE8ZcJEmYHMxYJQo2k7g18q+Pr78c2j 7Ez5dHI42nZgmW2EaiJZ/Gk2GUoe8dxqMEhgY7XVyAFpwRCStV8yWaI0A2N4pV1kD+Twzp7O 3R9OR+1AcRD79iB1q4qGDvINTGYnN19WXpzczl7CeAI1B/yS0SfgOETE5JZjpcKmoRxfrLxF a49jVLFhKVqTsD0yZCVSd4r1vau3u47T7VtxbZvJvdQlMbEoE0Cwk95Crn63BSt/wsRa65m4 t6h87gRdchNW/ZwEaTwjTC929bGx8/JxXlr3mzgcHKkkIIzUc0gix+jTX1r69EWOnshu+xw4 bg8K59CvP/1uBTvfmg+58pzzrc692UAvjrPYAOx66Sq6pQ0+BbByXjpF13Q82FbD7SqxL+cS 2JflT3tqWNbH6ugZFsi96qpDkaQobFhM1aPdHQI+fWA+PwzLnz9nd/tV7T+b0YdTP5GymbGC E6XB/RHLpRdMysx/cDeH1LKt8mZrSuTRgmVjtEGpEfDSWfAm2g7rP6Jq9S01n+wlqrJ8O35W 1Di2wu2v2vywdCCQRABaCQAAVR0AAALDiCvtq1pCQB0zHwAgAAAAdXNyLWxvY2FsLWV0Yy1m aXJld2FsbFxmaXJld2FsbADwLKxtEB2REIkZfJHVu+/hVIHPbRRQHNHvuI6TBHRGKDwB5nPY wcG0LFIQuxu7HRxw5925GCopdhM1VXpAt0ZGdHOhyMgrRNTXk6amqm/i8/wkfvPJnomYmqqY rvh5ke4utH5LCke2mtZQQh6HtP5mN9ISXcY5lVtMn0VU51ekk25ypqDjzdDfSsWbxzpr6Af/ Y7ElKyfXorXDabZZckwnGJYrk7FbhLSXZ4PQ9p/IXliFTJ1JLKYiOVeUW6uwtYqsGt7LUqWn p7Ny0CSShLrXYSJtb3DR3NUkmUSHv+RpEnT7/85pJm5Lnbc3ZKRbM358O3eJDM4di3X6i4Y2 KlW1WwMjHXFXA4CMp3L5EqvPctjnJx69hZPCtZsx8WNnF9o4K5zlNeylhoAj0K/QGCOFsbW7 Qm/WXvb2Bc1AhIVtozDwybD9zQgvRoXRcTuPMCHgFwFHNxAWYcgwdsz5tEqJfWfQ+hNXNKY0 qzK/j8PhIkErJqNZWVeUgBxmaytryAYDCo/gn6KAUhrsJ28GKrEKPTJDXxOpzhVqW8pctUQJ C3y4G7tUfKdt02bMBDXl6jw/N27sDmVKNKXM+gJhFMQzpdIDVheKyN1wdBe5yAA1MVeGe1+a 2KntQIIYzWhqmGot0ltawpi+hTN/Z0/FIQXUzM/1pMp5n5CtIlSmpCKQ8eUy+MxpzDGopNdQ H/44esqpVqgWDBtW2moTa3IzV+oKa6InguyCkoEvcIy50+ciOF1c1iyniJ1GXazaFrx/vm6O drxYfiRI8STHlEoJ2lelMgqAaZYXEkUT62DB1ltNfOhxyKrGtMzB9OjztaEZrbYBs+LlNc53 wdnx7zWMcF7YNPXM4CJMTkT5fGGEYS+yku5sVSo1xihqR7Aaysq16rgm2zXwTPQyCKsjrgg4 ldH6bvB44HRW5ggTNV5mnbYNTKasVMSoTV/6BxBTIA0Eoi4cG05IdT0QzNDJKe1dKYbYPvk2 O0zp2hrdol93BcYDs4x6rZVCPXa3JRmVY7KzjeoL6xd2tdmad9oDMXFi4QtioUZHc3pqPnVC axNIucYuBD1464LxYVFEqdbtkxvddi028QsDAiwuyXcTpBYGifMkSJKJMGkbv+4cCAPeYB8z 3p4fmrM97O/5fGwuBAij7JaH/OLxtfTp534E75QYybrQEh9sbFxSQjGc2BTlzn24fyBf3dqZ lAQKl8faWmpF6/9XoQNCPsF5hB4OiHZ5qn/SJ9AcrLOSa5O8D802yASp7ximsFJ34ILo0UTl +x/nhm31lyfSlZJ0dGZfqcgqO+NmALaU/Zn5l8B+ZOrzhGc3sAwB3FDu2J1nY6jG9x/KJU8B fBNdg+QO6uO70NMM/Jd8k3ovkf77c8sI4R6WCfx/BKyrcJDZh37wYjypkEnbhTBZ8YhZEfyv hG2QdplWFY302Ejo3Cb1RYn7rgNDnBdjTgQcJJBgwZAufn5UNDLfHNDkGUr2OUH+4EDA+ieC e/hoPQB8ST6ASx1PuKUDUuBSJpepBuvR4N7dpFZf5oPMSwYRF8UXgagTgdUdAT8fgHsZHy+S PpjTtb1N3IbLJvLCN4CydXpx21fpHD4XkrcxL9dqwx3YuKPX9gOv9A7viqnf3BkPvvbyL2PN YYJR6TCykntmFfK9/OdZLKQy+xX18QXlIGXGwqPXdglDnUIPWHNFlrxRkEBa+1Pqp53EF+Lr lwdBvPx/3uMhXJZpTYTCaaolaGaphumKqMAAQt20lpJvzS/PuGbcGmHFHC9wrBcnH+8bqISc Inwcs/G9JIsrJZg3vhBRkmsUA6jIdZ0B+VzcuBYPlnedAe+/WXQnbv52w59PKBlTp5N+XSmb hNqfQwql3BE+RS3GUND0p5QYUvNrDaumo5uOZWTrh1f6zvTXEzXcffpnMkpypnU4Mxp1FfS4 v3e7jGeTDyEfTPjmx/k+qmVNik3f2cQFsnaChZV7WCjIRoTaXDQnNwh5Gfm2krbjup+yzH+9 Ue2+5NZP/Lnx48p7ivp5tQZ5T3NuvLidlcOxPBat5EF5Opd8w03X3a4Kp7AcWAigMn/mcTRi DzG7NtWtq23rff0Gt5YQTJ86lN/36ifecoCOD1AsiSf2ofa1cDUH1Gu488LF4zxZS3xRki4/ PwAhfCLLv/lFeNl5TneK+q+dfLz3l2dt17LujwKhdra9SoZkv/1qHhVk2kWEznnJliIZTrz7 81/Kg9Lr5sw7zSCTf6Kb5Ms8cHIlauKRxke9Hj6Mm2S1EFCl2iD6djsuwtnLqmc5FjqLyeQ9 1S1XzFFHJZpvEjlvYhkNGguWTGelXeiA5E3mwwmNJYnWNPIA5YGjLY9eEoT7SnVldh5PmbDI WTYuLKF1DlBLd/gt4D35e7O8gyhpUtEAXJ1WGGqho+B6ZtV5q1hYiJarRZVqpWY7SlVyoMt0 /2zYXY1SalepnawVG097Yl0Nv/R5bZrcUtG6Gk2EbMJtmLTp+Wx0hSdwU6mt3sNkwSAycpTY +yyuqArwpg9yXZDTK4/3a4GDAfb4DGFmQMOmYgvHIPKAhqtq+lIN2c/VcqBkpAqpwUncUI6H w8Kpd3KE2wI57jAB3On2Ml/wOymCbzq4X3aD0ap9b0KIm1CI+2U/tjCla6N8y74JjaNAV6ye 8IroXhyL17XZOz6TXKQe09WvUd70OTTwPb05r9nTacmobw8moce0qAjtO8NCG3Wpoz6mjPKZ /UNyD3YeOpdB7Tl8Hei4Ghj7e3ISH36mrNoqH1W2fa5EQ6b1KboFvFquSJNM+J3yzcYSXWja xTDCOzUzkWCCG+BRmlcAjH5zDIpj1FhCHvy53Dg8p3iDFD9pHEQeMd26NKMCta3ErKJ9oe1+ qLKc+ETIlP6xyYwyeKFAViX27sv7Wroeqdn9q7Q9rE3nu1ABU67rtIsJx2NB3snzEnrYYXBQ nzJtGiQzOyUOHeD4laJeWBHLcCj5mT8Ft7D4LYLak6OjEhjZ4oRMdrhpH5PmHeE4eAk/e2SN nZB58HwvMtrPvkm8YKWKh5TaZ2DMOITI1k/C8L8gnjlZbLGYFJHmcV6sr8gHjOLBlvkl8HBv f2Sdhm76PfjF5rqmzfI1y+26V72ZjGpqD4JgMecT1H+QL7X92ZNGq9wFv1hpoD1zQlfciaxJ Jn6VjSalA6Xy9XC7b/I/RIBMBzjcRHkkq4EWAGBgwCr120BH6H/kVD90IIA8AIEAAADMAAAA Atr6UlMqg486HTMcACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXGZfbG8wCVUQkP4RN7wq gZukcmmScKnBrFcmIMtBxzMHvc1QV1IQJgQnA7rRWn1F8lqv6/hVHj3Dkp+8hI7m+YcYiUWh ZZtzDICcNBsRyEqteVR4tcsrVRjo+kixgmMHZWFN74be4xjDzUHO+t61cQ4OxJbd7sac/xsO fTiq85df+dw+eiPS+6F0IJBKADQGAADQMQAAAmHnqCWYu4w9HTMlACAAAAB1c3ItbG9jYWwt ZXRjLWZpcmV3YWxsXGZfcGlwZXMucmVhZG1lAPAk/T0MAY0MzM38nBm97+FHWDC2gWOcuX9w Db0Wt78KLhJBa8NvWw4mnGtG2nWk7JPme+Hb4E7NXc9JY7I7sNcJsLhOTibSTfck287JLP0k sjktbgiRXcePdxPM+ElP4t4f84/xxHhSI5cQiCCCvOPIDpcuToSLhGjaGjK8Pgk54eHQDND+ fytblmuUi4+qvu1g9bvs2NuG236/eDR+6Ua7r/AN9yvEcxoUX6rPpr2g8+/a/sN4Nnc9lrdr 7j4f2ux5bEBVbBfmuq/tLbxvzj7Ud5N8PbdfrseoNrbsPvtVu8ay9Fnb9MC4ezarfrv7NaFI uraswF9retWd2y9XaKlt3ZNorcrfxZ9Fi1ve7AgRgsBZtB/j5/0slItVtvasGQZTGy67/nf9 fHvH+t/Fq2P3sQK5/CCoHu/qxA5YcDvvYPGNGzDrz1NilqBmyHbyAcKOTpIgVu5rgQTHc2Ae IRxruK6foMmMfBJ45k+7ND7Pt0dGQU8KVoM1KMyhBddroHBm8BevxheZGzAtyDiDpvNS7E0q rYLzFp4TqDOsDbITWJ05eovSeamxTXaNv/NeWkzd8wtwtciqxJxYGoy+J+s+ozV1HhYbut46 UOJjkCz8Zs0qyYfO53J8pU8wtRpuAuba9F98C8CQsR+OIoyMYgOvGLebEc4EWsy8DGoGneBS Q1QozGrg1UWzXsAWvOwfLzj+YFStIEPOvC5x7sIzT62HJuQQk1pskqAQRfh2eBceLdX4fFp3 y85ozJLrom7okDVCOXJfLVXdXh7j6IKKq2qu213cdtf/vHJkBrS/LDkZyro/6/jLbnmVveR1 zEnkWmYzKYVOixxtXZ5dXhCxtX843mWxzfrCIk3zBaP27/ilBpFW0EvhHkZq1Flw8OlnU2aj csiGtZci9W3HcbKffB3q33dPYbLsjSKT3+AJFSm4iEFRVX4vmN9Pc4XvcuBR4f7FanYCFECJ CWboIyOQI8qSM45A8vVO5Il3+QVBM8xD+zxRMoGT9HEYm4vEZ45or87mXHWF8FntuAE+bo63 kVbbiKpG3+L9xDkRRI6N1i9MG6OWDc9cGplFfC8TOxnosp66j0TC/9OZDxwE2ozTeC5zmagH YSB9bvScPK1z5cuhHJ5xPDsnfZ7ID0gCIZkrkWKCScwonflK2tG+UJSF3wJJK6Bqn82d75UL W5BX3JrrRPTADLLPU47qbJ7qc90csIXUcPAqOBdLcd1MxE6cxOmqU0FVfphs4bIePD34UTzN 1PEddn3VGYti2tgQuDS/PNE4d3cLB9RvMhE0fNHLPUeeeXBvrWXY1J7YHYWC5dgTKkjQEoig CRxyiCZw8UOO8w0MK0hk9Dy+Ai5aLISOPIit8xFRTEtHDuEHRw/9HKUBeHgiEBlpfDwdanzK mNF3uZRdP/AlUmcYF3HB0ZpUNh6l6FCZsZfAz85ocHJXSlDic5LL6jrAR09M6Hsc+tC2STQG MBle1nm31hSH8PQjzALjL6joI9yjI3KRw0Ey9VExIiF0YQkhhF0yXKVcqIGHcepcz4C1Cq0x cu70aVYDxwO1aBRNsSewUh8vrwTVGKJhlDzHHgxZZnw8pYTWHRc01emNXw25mqXH1ry1UuFf PFrvrkVTq+vV/LUt0kh1yKr01nuX0t4Sib0YheqBfZdKpYnsShtQy+lvxKQzzEDRQPTS7ABY SdHLDsNLc5fBP/m+Xzc4oZLTrWX0Aj/Ly0iB5vVBJIpKGkAFVQmXuaotqqfCSX/yZGOGOI+G h79Nb5zL5nfOUvkLoHvczkVIQ90xC43vwxdA/AJqJE7TGNDsAKBN06czX7yy2kylCEYYEmJ6 trMNzzA0Q8cvq7kcPIUFKcGw8b1Psef8arUQrpfzJBsPCc4cN29PW7fUwYnEA7+LA150Bb1k 3Cjo4dNCXGhKmuQhK4vzfmCCcxQjGRIJHxUEe+XIIOrSoMFWIvNybA+5PznL6s2kp30VYuw0 0rZE9QSLgRTEnxamVl9WaiVAGnbUaSjhE+6SodBNXjQZPDtCsj6pCIhnjuVCDCT+GlJ8EqTI z8esqvrlFgci8pmnmGDGPhCu0adymVSz/5mcWDjpzNNigw3sG8Zq/mYWX98K7KsNrINX8/1A 0XZ0IIBNAKwAAAAtAQAAAglYn0Uqg486HTMtACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxs XG1haW4uZXhhbXBsZVxmX2JyaWRnZTAJVREMvhE35wqgjwCCMBmhQigpASKMjuSEcxYGMwMm ZFe9ozQkcVkRFCE4Jey6s9RfIrqj4Uf03r9q9wWB6ISmF7vxyFC5kl37UTH6CoTlUSvGqYmf TDsyEDbroh1aH4rvhp+ACLW9mfysXfcbFlMs1bpKPtf4fA72jOdHK3DdPIWr+xylZs58ZVfm 4e1uK7QY8TIsklZ/eTMehPn6mgu4GQnyGrhVBOpZjE6oupZ0IIBOAE0EAACHEgAAAuQ6yypZ rEk9HTMuACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxmX2RlZmF1 bHRzEBlRDI0PzUFb2D8VlUeD3ZUi3OhJCU83IzahW7AdMJH6SkwSGo0CIjpbn/qUWGtsSNzE IXYBPc8HTFnL5fRy+Yj81fRy+jL6cqzLWVSL++tXme9jAJjDhEM/wgsLOT09844Jp53GIg0i E9ZTWqLO7ufddeQYWH/Ti3dUkGcJSjzWoIOWHLlQgTeWI+XKfwLJFPw/IqcUTvDzZ/yyuvZx LDr2OnJl0n30pJ05GarojpyBDBfKJlA8LZShKfxXf8vS5GEV9LeQTzODSLJi/CvLwkryiVCd jCd7G89WUX3dG83zxt+w85vmlUrZnL7FQyCbhdawszOfRll0LZ6GyItR10k+FnTLGW4TZx3F JELfaH0JpWZeT0rHsB6KJab8IGZIWOQUJxg+hgjpkp/8H0w6C7zZmqsqEJPZ1RsIWlthCQlQ xahuUuM2oYBQsukgJ8qVQxe1FAHMwMryJCOHl6X01ooNvLQZXG2tQ23J8Meq8VGwYlpNj3F6 yKJj7AIcnkdzyOW5JHFT+cUocLkdicRC9mvYuXb9v9bX5i72RY9H3KhNc/i3m9hjwc3G7kcO 5xrOy9Aw3B1qRIz8jWj20TR9rOGAMXhvTYf59o9IIYF2WePdF2XLx6u/zQztjNt0+Y/2zOua TwMEUiUrNOP68a9iTwIoRxvweYe9EmNOZvGlAnnngqrg1eoljwYdCWB3HDmjhyLxSiT7oGTc RViCsXfr2C/ntuVAgnDRtAnkAEDiLrNrTD/Oqs/4dI+uFEsJ1EwHWXBgZzQonbuWr4tXy9we PCadeOnvnu+325jwnHR8eKfU8w003gRsLK0c1NuOIVHvcWJnCf7brF1Q8TD2LqQSHmtuU2zf F8ICdDPxPs/wyd/Dr9j6vD3W173NuyRNSDnJg/ghv9x6DFayL2+b4/OlCSvUSgP3QE9QWEWj yH2f2x5aP9bqBCqXCZ9/k64wJOomLJ/6Pbr7n6XXm8/9eSpqgykTr6N5HaUCL2Ahm/0tXpQQ KKQg/3b1MVEqXPqaOLSCVu4L4Seor41UIoOsHeQJvft19l3v6OGRxSpRVAJhNy9LyaKaEs8w oj73kB+vJnd1eVDGVmykuZIyp/0SHHlw13Wuv6i7bt32ImyXrV/52/0jYxC0q/a7jtOkLST9 vSU3SWMKTwxA4y6za0w+5TexgCBQoy1hz28kBR6yAdv7YSAgwtmGUly7aEBBhUlFqw6OuhKL SegDECY2d1WfEwmYw9OBqc6X+DLeUBs9DBSA4wQ7LvFjK/G7/F/lszKAKFOFF2RCnbNTQ8TC 19mMTDDE5ghMBYniZjFBT2IKCQ01NYuUFhumgxkuswhUjGigkJlTMcmGE5U+hY9Godu5GoUP 6aKKiGAGBigTAyfMD7Nq7MYrPrUVCMDz1DMCEGBMCrA5gKYOYEWC8wKsD9/qc1RkwCYMsBmh 9myD2YbNmLswTDk4+zJNWqBqRUwWv/yADy90IIBJAGkBAACnAwAAAr4OMa72jo86HTMpACAA AAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxmX25nMAwZDQjP1YEXueFN QvC3jEEKVU4WpSxK1CQoVWF7VFJulEtNEiEkt97qsissm7IyEs/G2EvgJ0bz7G9w3fHcea2w 1vHrWfcvuH2eCLxAeGgGQimOWSMJChzZuGIgYTzkj9NCm+AzjAShZe7bg5N8fl8kW8H73n3L Aw44F7xedg46hd26AQeVvvduIWywwOmJe0qyHF6ixbMt9gWm2Nm2qW6rWvZlBwaZ/W2iGMTs JjAWeaXOD6eqJgsaG9TE50F6LCov+LlJxAoNctvPDen0QjLp6abYXyCE00agNR02t1GS+l8d s6XGKcRNjGYVZ4K3gBuS40lP+cGRb+vwzfvLJl1TPVaLjFpcas2mnLLLVqy01u5Dgr9VPK6e ZVaRb6tibflmsMrxSk5Bzhl19AKam9MFAqTMuhm3qOqu7VFSenqerkU6df8/VV6WX4dvYkJI c+ExMCSdRmvyfz4hGLqbSZR7Z4GCjCUq3yjvbXQggEkAigEAAGUEAAACS0PGoUg5jzsdMykA IAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXGZfbmcxDBURCM19FBF3 nxVpk0SaWgMjchokScaUiEmm4pB7oiEzCCR4NYxtyf9xQFH1jzJgEfhAeRru82F1XMoysw+c u6y/Aq/Atc5qpK6rRfwCroROSAuDscRH3gfIHJp3HRhmiKN7ynWD3DUMo5FFcN5v+c6PFZaU 7sXjj7FAWZZDx78DTfDTqtYQBvwvdrV/WtdZZENM8dV+JBp3P+ar9M93PmqXTdqxUyWw2YYl Mj+Q+UjnnANwv3K5BABCxw6hEf2SMLVOHlXFzWq75D01l+9gwIUlng6rURkwExsl6YeBewUh HYEildzHFhTPAgRTH/AVdayAYPnZWoaR6EV9VOkIb69QbeH6TwkqOLG3LLm3Yf/Gn9oX5ioN ViJoQIZFbYEzbXP5bELdK/177tE4ontcQYe6nrvZ9SxKpHwXa1eYtYEFuhLXsI0wPRxK/96u U4DEvqmv5LsoqYXb0BWybqzUmo6GJkDm9NjgFOsm2HX1GCMGXMfPKYko6fwQXOhqSMpjJPXV AyyZiEU+EAcidCCASQAaAgAAmgYAAAI2nD00YYyjPB0zKQAgAAAAdXNyLWxvY2FsLWV0Yy1m aXJld2FsbFxtYWluLmV4YW1wbGVcZl9uZ18MGREI0P0YEXueFWmThHwCZgMGZwkSc1Samk09 immqdIjWwcFDQaHgST3vUse64afjMI9etn4c3wAEGJYX9dUruwPG8y7sy6qrzClXG/wlX1Xf gKefI2D+sBiV3I2d0Ebsrsex0JIZjq+8UMH8PtTcqSdiFitxG4TMyXT1dfZ8UgEKhrZ+Z/Fi CHUIJX3Ea2N8ZqHQQG1Tl0uw0NQRagcggB6OLumB9gsX+ZJ+fc1O2IoML1g9j7zmh29FbJLF XJ+G0/QzmLH/DXFBtps7fEIHX9M2VtK6pNPLnAG/rk+eXoSPJUOaIpIS8qz5MyHRkzZgPXrp +ykuuEFAqPhfgR1XGsaPG8/2zLiaCLHthpUirS3m1Pz6jd0S8c8a2jvoUjRcR+FGWGBCuTxD WujC7wOzuGsuojux5yHj1dquWhRBeiKzHsBXO2B32sYcFlOHCsKkPXS46FcU5HxYVby6ZcOC 8dxA6hQR6HbNUbtc9/5bFehDEQSCov1bEjCf97wJwDM2PGqSi5dlWo06yQ0rrGjq7GzYwYvJ mRtb13Jp4rnKYmGcaEyw+6AJ//vufLwftPwRDFbEM7NqVQEJblTNTd7aHLeseLDguWTzxtC9 TKOHyXMlvHpc0+YyNvk/q4GXP8m0Qc2TP6rH/tY9tGC7sZae2iDvA2cd2RXeOQ+HvpLpMjkq x2bVTLX+MRyu6aG4o6Ay/iaBsLI88l3o6QB0IIBLAJ0CAACfFAAAAjHYwMlurUk9HTMrACAA AAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxmX3BpcGVzDBlMzMz9GBV7 54UgH3bRIr8NMDCgYbQbYbWW627wCWfixiyVzOO2X3zDFNXSx2uWNyufjQRuXsQED6In8ieB I8ZXjCJSR4jw8KIggDgPPgog+H7tctktXLhDFJ++274JDExQwRQEft4cRIO2Infhf/xDgPWc mzJv6Aw/2Ehu2+70z7MfE/izibcHZef6idOQikpOrpkIr45vUkmG1j6yY4bfuzLIXvvTYJ1S DSRl95ShX8k65/Cys05YB9NzHEPsnm/MXmjepw3OjqiKCpQitPNRxyY+YDoaJlUE4RuQaYlh xk86nS1JPSBlGsFvkMzzdSOQUBkIbvVuQWWpGUz7Is2KGVawTLXRykEAtY71t7MtdGXW/mbF tlYllrw58dQtLqqsmxit70xPbwy8PiR2esJninVH6Yn01FgAFedMmr0wmDdBU2vrWr9m4RPw CAFtFgc5kJdCr8pjI3QTbjiDi1AhAtosBQZ5Hj6I0Kb3ZckQkWqEKFuywuVlo5XH3Zc6IdFq xCxbRYSoHpeLjEAMN4NueEcIwoBAC0Bh06MxTsQAw3g20IwBmNYABjWQs61qKKAGI+Ed0YY9 gY49HbsbO4QpqDxxshMt9YToK4RPx2g7NznRLjTclUXWk8eiZN+6TTPlRup1b4Ypiro1XbED nTipXXKtUhQ/7fr/hxwjnr+y4ny/HJZsfMn5/VjwefL9ByTOXpZpI70EMv3IrrJ8OL085+ma 0Z1lurtOeTGS7ld+KX+KpWjNrOfV+5+K710LCH/Oj9F4Wc9HJzc1iz0E5/r8eX7WfpWc2rFa kfen8sObViJuOn8vbntjFDntrENhXmO/alGWsGAkUNqR+S/J56XyYoIYvPnil2NlrObVloEq 3hYbiTNZgs9LA/iASuh0IIBJAPoAAACsAQAAAg2lwncArUk9HTMpACAAAAB1c3ItbG9jYWwt ZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxmX3JsMAmZEMzP3Re68K0JeFvCqpJ2Rt8LQloW jCkkLHe1GOpOsHEqJpyye9wHwccTLFSkhWPw3NzP/zfIFpm5hmBmrh+fdP/Bc2WMJ/oH3xwv DeyDMQoVJWeb3UmjaFopOwVhirwvPPp9vAQEhhDTo9IoxYXHFFmAI/XL5ReIdJSE6+1r+ptT Y7pXGSUUAhatVoTdWxX/RTp4n8usOidEkp20bojr5X3fhwi1VM5mY66Cs+Z4JeFp4YySYC80 wsJhlyQDJY9m/clcodh2ap2ck1/+eXoHZ0x/i4VoYOTK/bhsw7+5sWyXVQeluPxf9/hevjlQ pdwbPm2BSypCBbkZW3QggEkAvwAAACcBAAACQp22a6mplTsdMykAIAAAAHVzci1sb2NhbC1l dGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXGZfcmwzCBEUzL4Re8+K8FeC8FZQVJeCgqClBFRt fgK1kGBbYEstX/xCcEpLWx4N434X3uWmGZ9H7huabunuOYZ0z4UXwcXhb+UHXYIBvPBBz4Pw iFeg4/xAIemvc/tDC6MePMx+Jlai6E5VGP2qQRSSAZKJbdcjf0LCApATIU3L92UlboM2Np6P IHmBJY6QwHNFGW/tRQq67OtIuJ/Sad6lOq5F6mGrSyLJJokLOzFettlnKaS97M0JrDV4qn0p VBjC9oB26nQggEkA9QIAAFEJAAACZnTb/cesST0dMykAIAAAAHVzci1sb2NhbC1ldGMtZmly ZXdhbGxcbWFpbi5leGFtcGxlXGZfcmw0DAEMzMzfzcGX7fp4UhXgN+vwkrT/mN4DYCW6yiCy yUWy6/SB2RuV6OtvONzXb3rDG2USNuJKRuOON4XwChx0RM9x5cUS540ieJ4kolIjjxSKQRRQ 5H7HXrWATTwhn2Bj9pawkKFx9jJhdcb/QtIzMQVjtsCzZsLI2EVLCB46SHxCcXgEssLFqVlr ITWxtaBigwvOv6ngxbJMTqMBP5Knzprpo6xP44JVui/293LWEeQ27eu7cwU8OdcvCFg7LVu5 zC/+NU+ulE/jiqNE8iOyTx9tuyGrttiZfd8tIckxgdN/kE9azhFRizi+DTK+JgRNkwvEkBIa 4xc1q7dLo9HfXzvRHriR1wtNl+SwhPJrp8Izl/Bthd+dJuI2lIYPj4pZZvyohck158BO1u/z X+oxaMIHuKdjTK6AptKP+Ottw+Zo1AIRDgnSZKQQmCdkOb4g6IUkoGOI/kQSmC/X7r5Yf20Y OkHhSxuTHfldbXEl6unVp7ZJ3P9NMr53X2oMOVREwlSrlaW+pOlpx30KR+5stPcFYY80Fc3I 5ImSm5nx3dJH+T3tPBCe988P8YWxhYGF4YJz3vHggTufLgWo2+zsPxUfDY5FnUhcOZQQ60AK oLvYs0A0VUljVPu/ng8VNhu3+7Buw1pgyoGMZQf9j86ucWbxXeYwvtyP/iFj2SL4bH9ldrQ/ IqVMOOwbsihnrdh1D5+TUE21TgFUZQ3HG+zdQWFUFox8rTxWQTgiHHKkrIEDqmTU3PjUqial miTyI49i5MjRcttAhkmQl6NVj/GQKAYKJnMDgOzAfbrvFiy3VaCMKqBZA7NLyIN60FNixV21 er3OsjK2UB7fRCLeSr2cW9yvSl5AEowvel9EN+G6Rb2paWJo8A+dF+kt/bvcKIG9yhttq9Dw FSuRjHFojjKzWizSPkxKmqAgseGEt+oZ31pBiAS28/J7t0gKIZhc2OXV7P01+RfT565Ncr8M cWb0D7Bvx4fzkCMuvxmQeOmCzQQss1v4gH+hdCCASwDKAAAAYQEAAAJVQPQmbEaOOx0zKwAg AAAAdXNyLWxvY2FsLWV0Yy1maXJld2FsbFxtYWluLmV4YW1wbGVcVGZfZ2lmMAgRFQyX3RN+ cK8D/Quh+ZisCTQoKgpARUZP8AWOYuBJMDJkive0cQhHJPs0yaZwz3qurvkXg9dXd6rCrK2U F8CFOXlwWvc9/aBANxwHt+x18QrkLzu0Af4Z9TukL5Bjw5GPwMrQSBIVRj8qEHGGEDJRF96/ pCTznrGMFI+RH4A8YJLBMHQ5h1yYl+au4/ZTqOsyO1nj8WcYC3e/RKq3aaXm1rdiVZ3eI6rU XKYZsrIskmWEsjMU6/btXaZi86tUJpDV1on+YqUxheV9QXQggEoARQIAAC8GAAACStEf5l28 ajsdMyoAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXFRmX3JsMAwB DMzM/RgZf9n4UhZgNr+K60k27H+NgJtrcINdLhbKN/IHZW5Xo408/hLdvesKpBLM04U5I3Pm L4A2w2Eke48UeT8c4pEoko8SR3cEuIC4cgfALVi2J50Xtybd1wUsETl64aB/+CyiNyRQOqx4 U+vV2dvyUEs00Ls/HTZt7uGrWbQhW+ux0WfmL3jWW5F5n8c1RlWFdMiiQT5rwm33xOxGwZRA jKQ1HwjE6MAT27h0p8CJlh8xFIsnA693TMb7n3G4tQucVGUiofHxaS/rk6gDRnY6hE7is1Fa /oM6A/srdD8vkmMIdlP4HjCs5hKQOuWP3HRT1HjCIFuUi9IT6fpu/L/XkhVz/GVakr+b5n2x L40xv0vzB7WxZm3wmiekuX2SpDs7+Ur66c+z0BsRXWq2w9DtWq745OSFEEgW1UCLYOEtRs3W G0VUhWkRzgKlZ2bLTXXa8wHTeO1pbprHV226mssHNc6QMwE8d8e/TSEXkpXynK01ARpZ9PLA 96ET6wCmRpX/784o/BuFy5/0mR+5XMiIYXu3aiYCdnOS0YA75a9RVpbPWY3xYtwC3PfGSLtG gKAP/w5jnOA/gh+QGk4CTO3QO9Ni0mKs2ue2k6Ge2wRkNTKynOOiTVMSEuguOYg9HPE2L2/X bXqVlJWQ+pAXrCzQ7TY0EmbzgNJBe16XJpkuBzaaNnDpixnjX281MO4BIeNHETVp9uB4p+yw J2WHwKM3XFAvj8M0maWKVEUeIROUf/MWEAjpokGSeGWCjklddU/yjPF0IIBKAHAAAACZAAAA AqI2aukqg486HTMqACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxU Zl9ybDEJVVTJPg0vmivA5oBlksxpa1oVuw+MikGE/BXMwzfaDRBqiDgZRmivHu+77VfA7T05 fzQtXe0NwHaOV7B5fmzHwb3fBwNGaovBLWFKGmTYan9z00upIiTbyKa7LqEBM845/hmcmJzv 1SKnms/f/PsgNqB0IIBKAHAAAACZAAAAAqI2aukqg486HTMqACAAAAB1c3ItbG9jYWwtZXRj LWZpcmV3YWxsXG1haW4uZXhhbXBsZVxUZl9ybDIJVVTJPg0vmivA5oBlksxpa1oVuw+MikGE /BXMwzfaDRBqiDgZRmivHu+77VfA7T05fzQtXe0NwHaOV7B5fmzHwb3fBwNGaovBLWFKGmTY an9z00upIiTbyKa7LqEBM845/hmcmJzv1SKnms/f/PsgtIZ0IIBOAM8AAABAAQAAAsVaIFeM nY86HTMuACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVxUZl9ybDRf TEFOCZUVDJPVgRd9+FUEzQuiY3AiEmjMBUFIEFRkm7CC3BsbZaXdyL74hAgpLfxmnATMzwLv dfQ7z7yfnKCgqtH1HNFeEkI564TNokmxi8V2GG+CBwpXgvcfgxIUh/6jxZxOhAoUneKUsDxf f73BAGJ9eNZ5/PrRitNEmmOKVuRP0RyJqol1YssWRvT1p1/w+6vRL5MniD02ja6x7Hon1m/i GiaX8jhs0FlBZ01dneW87P/kHz8XRukqpBl3Ybt4asyqzbO+iVNDZt6wLZVRQTmgssh0IIBQ AK0BAADBBAAAAlplU1fYjY86HTMwACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4u ZXhhbXBsZVxUZl9zdGF0ZWZ1bGwIHUzMzX0cFb3nwplvQ270OsjklvZPTGxgvjjGN8Bekc/g rscG3Ltd96xXQusssbkxd2y7Wm92MbBv8uLjaXx5JPiQknxJCS8ElwEI/c98MRIx0lShprDf xUIOwwJzJBFMckPvJOOOaHTKc1Mkq+WOMlUT6ZBpJ5j0IqpZxPSoMnfWhhWUPyKQDwLcRlpR Lxco4ogQCCJ+AL7gXHnAbkih9azISZw1lp5sJiU+6oT7u1OsDjZrtfY6c81jZ9AT0801tTH+ VL/41wWoWKywWqBPQXPzMY04R0yUoS9SyAut+eT+fVXXJ3Vh+Ph1duTraAJvc4jLNQuqLFbF hlKCM5s2wT6GVpXsw9AqxOiVqpwszjXq38BBNOBdpGcH6mjHDuxwxXWpRQWbfa/tgo15GeKP 0I4JKxjphoUuC33vS9+8F9e+uSJN9y6ISuGbPt8T7uVjTlq2VKaPhTwJn2fbXmuwXZJSH+UZ bHhqCHL/UWNJJqoQKKxPIDYceL//48LQ0spwW/vXXnKQlFyC+Wvud2pImvBauxSk1rK4yPma YuQS1azt7b5c7dVglfOqJ7K+l3QggFQAYAAAAIAAAAACwn/yISqDjzodMzQAIAAAAHVzci1s b2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJlbnRcYWRzbDEub24JVBDJPg0v nCsTUIDTjKW9G2DweOTIsDCIMU2jR7u2waGrbng36Pf5h4PcT+VDlGQz0UoeJ7CmpOQT3IYR 2P7Rp/gFyzsWBA807AdNX+jBxHjyy25ft/gGF7Wg580YrpDtcHQggFQAYAAAAIAAAAACASzf CiqDjzodMzQAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJl bnRcYWRzbDIub24JVBDJPg0vnCsTUIDTitDejbDeDxyZFgYRBjo0I93bYNDU3bwb9Hv8w8Hu J/KBxhEZZqUP6WopoTUE9iF8NT3m09gFxyqWBA407Ac9TxB7SP7zZXcv/f4BhexgNdJLVdJh 4HQggFUAOAAAADgAAAACjBhEECqDjzodMDUAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxc bWFpbi5leGFtcGxlXHRvcnJlbnRcZi1hcnQub2ZmIyEvYmluL3NoCgovdXNyL2xvY2FsL2V0 Yy9maXJld2FsbC9maXJld2FsbCAtIG9mZiBmLWFydAoB0HQggFQANwAAADcAAAACeHxRvSqD jzodMzQAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJlbnRc Zi1hcnQub24JQUyT5M75hUTrk/k05FGBBQio762uAOFeq9q/0B+thipENYcNeSMJ5kKK899b ehxO9jpFHyXEUfd0IIBWAA0BAABOAgAAAvlXgM0QnCE8HTM2ACAAAAB1c3ItbG9jYWwtZXRj LWZpcmV3YWxsXG1haW4uZXhhbXBsZVx0b3JyZW50XGd3LmluZm9jb20N2QzMz9XA13XhRomd FbTasjgekFwuM3uziSciATTYSbct97oroFrrUaTdEtwoFk3X8BJEnu4rvIe7iTx/gHD9r9j9 4Fo7B7kKGzgIWgdjFjTSWZIz1lHOhZ+N7Tz6BABQmMYInY1BPxvMZNcMTsx90scsoPqJ100X hXoFdOXBMEtgBoJbQVv7esSZLvjihfrVclIMkn6UU2Vh50I+RadLcurVa+h+5QfP7Ynttj3C irCwGOlsH1UeHSRfzI08r5OiYLrGHhs27eS/BuO8/j5QbMo/eCkJfsX/FDnvc0JMypmA3Era lXX4MhyywmGqbFPHZmLdWZ7lfzhTT9zgPyFnTgr91s3t9+bAdKML1RpwdCCAWQAOAQAATQIA AAKSSHB0G5whPB0zOQAgAAAAdXNyLWxvY2FsLWV0Yy1maXJld2FsbFxtYWluLmV4YW1wbGVc dG9ycmVudFxndy51a3J0ZWxlY29tDhkMzM39IA13XhRomdFbTSEjgekFwuM3uziSciATTYSb ct97oruFdajSbotuH4D9Juv8BJEnu4rvICePE8TwBw/tfsfvAtXcPglY28hC1DtawaqjTqGi ww6EsRzwavzoEQGCc5wkfjYFHPAkLtjkfknhMSaYIUaGVU4BfqFlWfBcUugBwJrgXx7+0S5b /JJHDWy9MUZZf4s1W2B6Up+RitbsuzWtvU/epRp90UG02DgTXjYDoU6D6omPSyf5ka+l8vVM B9iDx3b9/Rfk7Hijy84t2ccgLSqGxf+Ive97Uy6FjcRvKrq130WYbDRnGufJLLVuTVeh9ne3 i3HcHiP2FpSis+F0/v9+bQfKOL2QhSF0IIBYAIQAAACsAAAAAuAN2Ysqg486HTM4ACAAAAB1 c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBsZVx0b3JyZW50XGtlcy5hZHNsMS5v bglRUQy+ETfOFWihgTRlyOhknCXg8lt4uBczAzIqIj3dERCSKRdE3PBvnyqK5TVaKCg97h+n QNjXDHhJIPGMBR5VoJ3ELGwPne0zwCnb5VAQbjTEB37V1aysj29p5qFf6+RBH0wWwJg+/Mg+ 3yq1rn2UrqXT4ufhDugfFgxyXLKP6HuHuqpgdCCAWACEAAAArAAAAAI84Wi2KoOPOh0zOAAg AAAAdXNyLWxvY2FsLWV0Yy1maXJld2FsbFxtYWluLmV4YW1wbGVcdG9ycmVudFxrZXMuYWRz bDIub24JkZTMvhE33hXkUIF0T1rotl4S8Ht8+iwJZAkqoiPd3QiEtUq6HdeDfn5mGcpzNGBg ffcP16huY4Y8Zph5RgLXla0TwIVsgfSTb/wCHcJ0AQbzbkA5bZ2Yu0j3d6aK0aV8yCPpit0k H35cH3+Vm1NNSk2JVQGD8Yd1D4sGWS55x/Q9w+HpanQggFcAhAAAAKwAAAAChDgLzSqDjzod MzcAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJlbnRca2Vz LmluZm8ub24JkZTMvhE33hX6KEB0T1qgtvCXg9vn0WBGQJKqIj3d0IhbVKuh3PBvz8zDOU5m jAwPvuH5chWNeUt80xcZRJ0DrcSWmTGxTnc3fsBT92dQMbUdgBLtm6tZWabO1E+tX+viQl5X rYNI+fMjDh4VaF0aqV1LpnFsL4f0HtYYZPljH7D1D3RlWXQggFUAUwAAANkAAAACQDOcPCqD jzodMzUAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJlbnRc bGltaXQub2ZmDRAMy+TO+YUxGAMMMKjBgijCJNNpOOI30oCgLy4mC/Ty/Jf5L8B6vsHvuHWa DTeEBrRhNY6GMniJTaXHjP6ATbAFIgdW9FHyS2WdX/Jjb77+nKCcr3QggFQAUgAAANUAAAAC fZdjkiqDjzodMzQAIAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRv cnJlbnRcbGltaXQub24NERDL5M53RTEUBwUYRFDA0xjS9f6Xv2i/SAIAnJh0LsOLak3FtB5H lD33DWZim7nCtFBJDQhFoDaax48ZfQ85YPQ3si+gbZHarOrfkxtt93Tl7sx0IIBVADwAAAA8 AAAAAsByPDwqg486HTA1ACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXG1haW4uZXhhbXBs ZVx0b3JyZW50XHNoYXBlLm9mZiMhL2Jpbi9zaAoKL3Vzci9sb2NhbC9ldGMvZmlyZXdhbGwv ZmlyZXdhbGwgLSBvZmYgc2hhcGVfcmw0CsD+dCCAVAA7AAAAOwAAAAKNqTTlKoOPOh0wNAAg AAAAdXNyLWxvY2FsLWV0Yy1maXJld2FsbFxtYWluLmV4YW1wbGVcdG9ycmVudFxzaGFwZS5v biMhL2Jpbi9zaAoKL3Vzci9sb2NhbC9ldGMvZmlyZXdhbGwvZmlyZXdhbGwgLSBvbiBzaGFw ZV9ybDQK7BR0IIA9AMEBAAAlAwAAAlR0tZxauUw9HTMdACAAAAB1c3ItbG9jYWwtZXRjLWZp cmV3YWxsXE5PVElDRQ2BDMzQ/RgRe68KIF42gWvY3IJolAnCgSi3leF3e+hRJNxCP86vxs2e 90aw9jbSTLn4G9b4A+DBSGZhxYT48sRSOYjhQI+JB4kDOGeARxB47mrCUq2BRUdAKR5tTcYF Py7Rq2kNxMNYVoVaKbehyPmmkC+l/LMj6Btazt3zlYilznVLh+15S0zUplSPFk/Ek9XAUBqq HMU78wMqGzLO6l83hwSzc55aLW1zT309+gzsRBZs71kv8pqVQWfm4fUnw6+tk/Qu2ER70/pc BmZL+m7i9sv1cR20UceddXlkWQmOcCkdFIHhFKhQvOSacSEl6DqFkB2VwAEeXzrJp0Dasahj lWJwR5ouTHp5X3c82LvlALz16pMX8dNYhQNxU1x6otWq90L/5NZ7ISWW6LIZ7NIYCnOJgK01 48R3TwmVcysWBx560JuKZUZuwUdnSWeHPxSDenQG3OqUarAEzQa4A/fe+wq7hajfbDAzesvX 4JnZeqLxmk7oCd2flC99k3JZI62WVEkiD91OuLolnavcH8/HiCmjtZhWf2+VodBvIEmPvu/D KPsfSOR5LsaO+T3bPiSyeDGn4h+v7+dnT3UGpyf5jWV0IJBDAFsAAABbAAAAAgw+SrQBW0JA HTAeACAAAAB1c3ItbG9jYWwtZXRjLWZpcmV3YWxsXHJjLmNvbmYAsDicHGFkZCB0aGlzIHRv IC9ldGMvcmMuY29uZg0KDQoNCiMjIEZJUkVXQUxMDQpmaXJld2FsbF9lbmFibGU9IllFUyIN CiAgZmlyZXdhbGxfdHlwZT0iS0VTIg0KDQqhZ3QgkE0A6AAAAIABAAACOdpVTPBaQkAdMygA IAAAAHVzci1sb2NhbC1ldGMtZmlyZXdhbGxccmMuZmlyZXdhbGwucGF0Y2gAsFyZWg3ZDQjP 1cEXvUr4O1FeMJQ00sLaB2nKKScJKrwiFUIun8K7Ai0BCFEe7xLYQ4SxH8UoHg747ix/Zj3y Nr5tLMbxNL88bzi/BkKQDNpOPmJK0UqUJn3QPm56QNTUwDWBNZdXOuP3BRMY/HwROwysIxpr qey6ec9Qo9YwCvoPzp/ULWa6nTu3alo0A/sYYom/4kZ364KfT+W+7Iej5lo3LjJmOrL0E6ts VezMeikiMIsLfewRI2xXf1/ovHb0QwWn3P1XuwYMnlyuP+o5uJJ8gMsBG8SC867KjZW+H3OG CDhWnYsTNlZ25zSjy3TgkFAAAAAAAAAAAAACAAAAAMZaQkAUMCsAEAAAAHVzci1sb2NhbC1l dGMtZmlyZXdhbGxcbWFpbi5leGFtcGxlXHRvcnJlbnQA8DicHBQvdOCQSAAAAAAAAAAAAAIA AAAAxVpCQBQwIwAQAAAAdXNyLWxvY2FsLWV0Yy1maXJld2FsbFxtYWluLmV4YW1wbGUAsBxO DgZ1dOCQOwAAAAAAAAAAAAIAAAAA+FpCQBQwFgAQAAAAdXNyLWxvY2FsLWV0Yy1maXJld2Fs bADw+ocoxD17AEAHAA== ------------121AA244ACEB5B4-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 15:10:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECCE106566C for ; Thu, 2 Feb 2012 15:10:33 +0000 (UTC) (envelope-from mjr@cs.wisc.edu) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8D9658FC12 for ; Thu, 2 Feb 2012 15:10:33 +0000 (UTC) Received: from Core (71-90-102-157.dhcp.ftbg.wi.charter.com [71.90.102.157]) (authenticated bits=0) by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id q12EhH4w000673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 2 Feb 2012 08:43:17 -0600 From: "Matt Renzelmann" To: Date: Thu, 2 Feb 2012 08:43:09 -0600 Message-ID: <003101cce1b8$fe7def80$fb79ce80$@cs.wisc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczhuKfG3tvQ8A2kSBKOh7Nz7sn5WA== Content-Language: en-us Subject: 8139 driver question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 15:10:33 -0000 Hello, This will seem a bit off the wall, but I just noticed a discrepancy between the registers defined in the pci/if_rlreg.h directory and those specified on the RealTek datasheets for the antique RealTek 8139. In particular, as defined in the header, the registers in question are: #define RL_CFG0 0x0051 /* config register #0 */ #define RL_CFG1 0x0052 /* config register #1 */ #define RL_CFG2 0x0053 /* config register #2 */ #define RL_CFG3 0x0054 /* config register #3 */ #define RL_CFG4 0x0055 /* config register #4 */ #define RL_CFG5 0x0056 /* config register #5 */ The RealTek data sheets for the 8139, however, all indicate that these should be set to something like this: #define RL_CFG0 0x0051 /* config register #0 */ #define RL_CFG1 0x0052 /* config register #1 */ // No Config2 #define RL_CFG3 0x0059 /* config register #3 */ #define RL_CFG4 0x005A /* config register #4 */ #define RL_CFG5 0x00D8 /* config register #5 */ The datasheets I'm referencing are available here: http://realtek.info/pdf/ Specifically: http://realtek.info/pdf/rtl8139d.pdf http://realtek.info/pdf/rtl8139cp.pdf I believe the registers currently used apply to the 8169, but not necessarily the 8139 family -- can someone, hopefully easily, verify that the 8139 driver is using the right registers? The 8139 series may need the slightly different values used above to enable functionality like wake-on-lan. Thanks and regards, Matt From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 15:51:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D33AF106566C for ; Thu, 2 Feb 2012 15:51:26 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 1E73014DF5B; Thu, 2 Feb 2012 15:51:24 +0000 (UTC) Message-ID: <4F2AB0A9.70905@FreeBSD.org> Date: Thu, 02 Feb 2012 19:50:01 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111117 Thunderbird/8.0 MIME-Version: 1.0 To: =?windows-1251?Q?=CA=EE=ED=FC=EA=EE=E2_=C5=E2=E3=E5=ED=E8=E9?= References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> <1446971288.20120202105912@yandex.ru> In-Reply-To: <1446971288.20120202105912@yandex.ru> Content-Type: multipart/mixed; boundary="------------030901040500010706090507" Cc: freebsd-net@freebsd.org, Andrey Zonov Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 15:51:27 -0000 This is a multi-part message in MIME format. --------------030901040500010706090507 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit On 02.02.2012 12:59, wrote: > , Andrey. > > 2 2012 ., 8:35:23: > > AZ> On 02.02.2012 5:11, Alexander V. Chernikov wrote: >>> On 01.02.2012 20:45, Andrey Zonov wrote: >>>> Hi, >>>> >>>> I'm trying to tune machine with 8.2-STABLE for heavy network load and >>>> now playing with netisr. Could anyone explain me why actually works only >>>> one netisr thread if I set them to 8? >>> >>> Can you please supply `nestat -Q` output and clarify you usage pattern ? >>> (I mean, this is router/web server/some kind of traffic receiver/etc..). >>> For example, flow policy does not balance traffic from single flow >>> between different CPUs. >>> > > AZ> This is a web server with multiple nginx instances. 5k/sec accepted > AZ> connections. Input packet rate is 35kpps, output - 25kpps. > > AZ> I thought of changing policy for IP, but how can I do this (without > AZ> patching)? Is it safe? > > AZ> netstat -Q (I turned on direct& direct force for now): > AZ> Configuration: > AZ> Setting Value Maximum > AZ> Thread count 8 8 > AZ> Default queue limit 256 10240 > AZ> Direct dispatch enabled n/a > AZ> Forced direct dispatch enabled n/a > AZ> Threads bound to CPUs enabled n/a > > AZ> Protocols: > AZ> Name Proto QLimit Policy Flags > AZ> ip 1 5000 flow --- > AZ> igmp 2 256 source --- > AZ> rtsock 3 256 source --- > AZ> arp 7 256 source --- > AZ> ip6 10 256 flow --- > > AZ> Workstreams: > AZ> WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled > AZ> 0 0 ip 0 0 1125716 0 0 0 1125716 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 1 0 0 0 102 102 > AZ> arp 0 0 27 0 0 0 27 > AZ> ip6 0 0 0 0 0 0 > AZ> 1 1 ip 0 0 1222701 0 0 0 1222701 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 46 0 0 0 46 > AZ> ip6 0 0 0 0 0 0 > AZ> 2 2 ip 0 0 1184381 0 0 0 1184381 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 45 0 0 0 45 > AZ> ip6 0 0 0 0 0 0 > AZ> 3 3 ip 0 0 1191094 0 0 0 1191094 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 54 0 0 0 54 > AZ> ip6 0 0 0 0 0 0 > AZ> 4 4 ip 0 0 846165 0 0 0 846165 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 19 0 0 0 19 > AZ> ip6 0 0 0 0 0 0 > AZ> 5 5 ip 0 0 849478 0 0 0 849478 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 27 0 0 0 27 > AZ> ip6 0 0 0 0 0 0 > AZ> 6 6 ip 0 0 870836 0 0 0 870836 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 0 29 0 0 0 29 > AZ> ip6 0 0 0 0 0 0 > AZ> 7 7 ip 0 5000 594320 5 910862 3453459 4047784 > AZ> igmp 0 0 0 0 0 0 > AZ> rtsock 0 0 0 0 0 0 > AZ> arp 0 5 21 0 0 109 130 > AZ> ip6 0 1 0 0 0 1 > > same problem, it is because one netisr take 100% so other threads > stops?? to work fine. or packet scheduler has disbalanced scheduler > and still trying to schedule packet to netisr:7 despite on it is 100% > busy. Can you please try an attached patch? Rebuild kernel with this patch and set net.isr.dispatch to deferred / hybrid P.S. it is also reasonable to set net.isr.bindthreads to 1 > > > -- WBR, Alexander --------------030901040500010706090507 Content-Type: text/plain; name="netisr_ip_flowid.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="netisr_ip_flowid.diff" Index: sys/netinet/ip_input.c =================================================================== --- sys/netinet/ip_input.c (revision 230910) +++ sys/netinet/ip_input.c (working copy) @@ -78,6 +78,11 @@ __FBSDID("$FreeBSD$"); #include #endif /* IPSEC */ +#include +#include +#include +#include + #include #include @@ -145,9 +150,13 @@ SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, check_inte VNET_DEFINE(struct pfil_head, inet_pfil_hook); /* Packet filter hooks */ +static VNET_DEFINE(uint32_t, flow_hashjitter); +#define V_flow_hashjitter VNET(flow_hashjitter) +static struct mbuf * ip_hash_mbuf(struct mbuf *m, uintptr_t source); static struct netisr_handler ip_nh = { .nh_name = "ip", .nh_handler = ip_input, + .nh_m2flow = ip_hash_mbuf, .nh_proto = NETISR_IP, .nh_policy = NETISR_POLICY_FLOW, }; @@ -305,6 +314,9 @@ ip_init(void) NULL, UMA_ALIGN_PTR, 0); maxnipq_update(); + if (V_flow_hashjitter == 0) + V_flow_hashjitter = arc4random(); + /* Initialize packet filter hooks. */ V_inet_pfil_hook.ph_type = PFIL_TYPE_AF; V_inet_pfil_hook.ph_af = AF_INET; @@ -390,6 +402,73 @@ ip_fini(void *xtp) callout_stop(&ipport_tick_callout); } +static struct mbuf * +ip_hash_mbuf(struct mbuf *m, uintptr_t source) +{ + struct ip *ip; + uint8_t proto; + int iphlen, offset; + uint32_t key[3]; + struct tcphdr *th; + struct udphdr *uh; + struct sctphdr *sh; + uint16_t sport = 0, dport = 0; + uint32_t flowid, pullup_len = 0; + +#define M_CHECK(length) do { \ + pullup_len += length; \ + if ((m)->m_pkthdr.len < (pullup_len)) \ + return (m); \ + if ((m)->m_len < (pullup_len) && \ + (((m) = m_pullup((m),(pullup_len))) == NULL)) \ + return NULL; \ +} while (0) + + M_CHECK(sizeof(struct ip)); + ip = mtod(m, struct ip *); + + proto = ip->ip_p; + iphlen = ip->ip_hl << 2; /* XXX options? */ + + key[0] = 0; + key[1] = ip->ip_src.s_addr; + key[2] = ip->ip_dst.s_addr; + + switch (proto) { + case IPPROTO_TCP: + M_CHECK(sizeof(struct tcphdr)); + th = (struct tcphdr *)((caddr_t)ip + iphlen); + sport = th->th_sport; + dport = th->th_dport; + break; + case IPPROTO_UDP: + M_CHECK(sizeof(struct udphdr)); + uh = (struct udphdr *)((caddr_t)ip + iphlen); + sport = uh->uh_sport; + dport = uh->uh_dport; + break; + case IPPROTO_SCTP: + M_CHECK(sizeof(struct sctphdr)); + sh = (struct sctphdr *)((caddr_t)ip + iphlen); + sport = sh->src_port; + dport = sh->dest_port; + break; + } + + if (sport > 0) { + ((uint16_t *)key)[0] = sport; + ((uint16_t *)key)[1] = dport; + offset = 0; + } else + offset = V_flow_hashjitter + proto; + + flowid = jenkins_hashword(key, 3, offset); + m->m_flags |= M_FLOWID; + m->m_pkthdr.flowid = flowid; + + return m; +} + /* * Ip input routine. Checksum and byte swap header. If fragmented * try to reassemble. Process options. Pass to next level. --------------030901040500010706090507-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 16:36:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546EB106566B for ; Thu, 2 Feb 2012 16:36:19 +0000 (UTC) (envelope-from adrian.minta@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCE6E8FC08 for ; Thu, 2 Feb 2012 16:36:18 +0000 (UTC) Received: by eekb47 with SMTP id b47so926538eek.13 for ; Thu, 02 Feb 2012 08:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IxN+SXvxyGuttdhbCRIwpUNCqjhqqqU4lU/Oiw2FXOc=; b=Kc1mbn1cVkeJ6QFhMpxSpfw+wKk6glMQ2qYQ7YapnW1U/0oiiIHGCnPnn/T6WrJgJ7 8v84ZnvJpr/h0FnHbJTrauiyoOhbRUKLeugVDc7WD4eBM1JDji6FZ95a7y0ARuXsgpyw XeGkmknVwIRdQZSeQ5ksAjpszwBeNMbgLztgM= Received: by 10.14.99.2 with SMTP id w2mr1120544eef.69.1328198976540; Thu, 02 Feb 2012 08:09:36 -0800 (PST) Received: from [192.168.10.10] ([188.26.157.100]) by mx.google.com with ESMTPS id b3sm10715458een.2.2012.02.02.08.09.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 08:09:35 -0800 (PST) Message-ID: <4F2AB53D.7080503@gmail.com> Date: Thu, 02 Feb 2012 18:09:33 +0200 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F29A464.3080302@zonov.org> In-Reply-To: <4F29A464.3080302@zonov.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 16:36:19 -0000 A multiqueue network card may help, like a dualport Intel igb E1G42ET. From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 17:10:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD1AC1065670 for ; Thu, 2 Feb 2012 17:10:22 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8187F8FC1B for ; Thu, 2 Feb 2012 17:10:22 +0000 (UTC) Received: by ghbg15 with SMTP id g15so1598380ghb.13 for ; Thu, 02 Feb 2012 09:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to; bh=t4PEGrhQIkRkPSMqpV999q+vrjJEBCAos2LsW3J0Qi0=; b=vp9xUSknowlA25+RW9Cf45bIIQvQs5BqqTenpbbSlSiYfzlKVmR91xqQmIcREHLoZk Ax+oPTn6aEQHhoT73VNiMEGrQhxuWIftHMbh7retb0Svff1KVshMygX68F58+TnGp152 DQJkyNlti1NQZ1IG+UAw7A8/fp531qhYpC7VU= Received: by 10.50.10.225 with SMTP id l1mr4265295igb.9.1328202621710; Thu, 02 Feb 2012 09:10:21 -0800 (PST) Received: from DataIX.net ([99.19.42.1]) by mx.google.com with ESMTPS id vr4sm689079igb.1.2012.02.02.09.10.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 09:10:19 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q12HAFxu037778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Feb 2012 12:10:15 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q12HAEQE037769; Thu, 2 Feb 2012 12:10:14 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Thu, 2 Feb 2012 12:10:14 -0500 From: Jason Hellenthal To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= Message-ID: <20120202171014.GA96674@DataIX.net> References: <67410574.20120202113314@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <67410574.20120202113314@yandex.ru> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: HowTo easy use IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 17:10:22 -0000 You are welcome to create a port and submit it for reccomendation... For that you should review the documents etc... at http://freebsd.org/docs Good Luck On Thu, Feb 02, 2012 at 11:33:14AM +0200, Коньков Евгений wrote: > this is the mine script which helps me keep my firewall very clean and safe. > > It is easy to understand even if you have a thousands rules, I think =) > > please comment. > > PS. If anybody may, please put into ports tree. thank you. > _______________________________________________ > 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" -- ;s =; From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 17:16:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2FA51065670 for ; Thu, 2 Feb 2012 17:16:48 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [IPv6:2a02:6b8:0:202::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7FD8FC08 for ; Thu, 2 Feb 2012 17:16:48 +0000 (UTC) Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward7.mail.yandex.net (Yandex) with ESMTP id 7EB221C37B1; Thu, 2 Feb 2012 21:16:46 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328203006; bh=yhYnpop8Kcv46h9D70k5q7ObRAy8aPlnYvar4vibPvA=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qbEJzKWC9Gl1qi4kptRulzz3E3l23bv+AChUvhaxbZFjw6VQFkT5FXlLxdlJmipH+ gLOSJI5wLomvlHI50/RWI0Fgd00/fMqsfv3v2gzLrc1f6h2M6+n5430sttow+iwy/U iATku/1jO7xvnT4+yhxBD94DIge44db0TFFcrLxE= Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id 59BC01520506; Thu, 2 Feb 2012 21:16:46 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1328203006; bh=yhYnpop8Kcv46h9D70k5q7ObRAy8aPlnYvar4vibPvA=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qbEJzKWC9Gl1qi4kptRulzz3E3l23bv+AChUvhaxbZFjw6VQFkT5FXlLxdlJmipH+ gLOSJI5wLomvlHI50/RWI0Fgd00/fMqsfv3v2gzLrc1f6h2M6+n5430sttow+iwy/U iATku/1jO7xvnT4+yhxBD94DIge44db0TFFcrLxE= Received: from unknown (unknown [77.93.52.19]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id GjEWSvCN-GjEaubtC; Thu, 2 Feb 2012 21:16:46 +0400 X-Yandex-Spam: 1 Date: Thu, 2 Feb 2012 19:16:44 +0200 From: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?utf-8?B?0KfQnyDQmtC+0L3RjNC60L7QsiwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <944787000.20120202191644@yandex.ru> To: Adrian Minta In-Reply-To: <4F2AB53D.7080503@gmail.com> References: <4F29A464.3080302@zonov.org> <4F2AB53D.7080503@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re[2]: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 17:16:48 -0000 , Adrian. 2 2012 ., 18:09:33: AM> A multiqueue network card may help, like a dualport Intel igb E1G42ET. actually it is not. Intel have hardware separation to interrupts. So having only pptp trafic on interface cause next problem: only one thread process packets instead of 4 posible. -- , mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 17:34:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9451065670; Thu, 2 Feb 2012 17:34:20 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7F78FC1F; Thu, 2 Feb 2012 17:34:18 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so2962342wgb.31 for ; Thu, 02 Feb 2012 09:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R3A85hxCoRQB2ulCiuVvLOmrBA8sILKGlFE8NzcA2NI=; b=mO6Y5GohmCeJwE7fT4rIuWvXkfuYmlbIejTPpTBjcH3riFdb5Y0btoU92rLwihMBRc 4gq/FoN40xXHbLQxySB9Z95ndSJGBLtoly7CgJJGcVb/K1fOzPf1Qn1OR+dvFB0oBRBL MsAvzVzpY1siUzTqs/QQUMaC0BrX/v3lDORAU= MIME-Version: 1.0 Received: by 10.180.94.68 with SMTP id da4mr5892940wib.22.1328202445023; Thu, 02 Feb 2012 09:07:25 -0800 (PST) Received: by 10.180.106.129 with HTTP; Thu, 2 Feb 2012 09:07:24 -0800 (PST) In-Reply-To: <4F2AB0A9.70905@FreeBSD.org> References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> <1446971288.20120202105912@yandex.ru> <4F2AB0A9.70905@FreeBSD.org> Date: Thu, 2 Feb 2012 12:07:24 -0500 Message-ID: From: Ryan Stone To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= , Andrey Zonov Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 17:34:20 -0000 2012/2/2 Alexander V. Chernikov : > P.S. it is also reasonable to set net.isr.bindthreads to 1 I really don't recommend setting this in any release. There is currently a bug with binding kernel threads that causes unrelated threads to be unnecessarily bound to CPUs. In the specific case of net.isr.bindthreads this will cause(among others) the softclock threads to all be bound to the same CPU, which may well obviate any performance increase from binding the netisr threads. From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 19:10:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ED8201065670 for ; Thu, 2 Feb 2012 19:10:42 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 76CA614FF5C; Thu, 2 Feb 2012 19:10:41 +0000 (UTC) Message-ID: <4F2ADF5C.1030900@FreeBSD.org> Date: Thu, 02 Feb 2012 23:09:16 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111117 Thunderbird/8.0 MIME-Version: 1.0 To: Ryan Stone References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> <1446971288.20120202105912@yandex.ru> <4F2AB0A9.70905@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?UTF-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?= , Andrey Zonov Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 19:10:43 -0000 On 02.02.2012 21:07, Ryan Stone wrote: > 2012/2/2 Alexander V. Chernikov: >> P.S. it is also reasonable to set net.isr.bindthreads to 1 > > I really don't recommend setting this in any release. There is > currently a bug with binding kernel threads that causes unrelated > threads to be unnecessarily bound to CPUs. In the specific case of > net.isr.bindthreads this will cause(among others) the softclock > threads to all be bound to the same CPU, which may well obviate any > performance increase from binding the netisr threads. > As far as I understand, the only effect of setting bindthreads to 1 causes intr_event_bind() to bind soft netisr to appropriate CPU. Can you point me to ML discussion or some other info clarifying this bug? Okay, so one can manually bind those netisrs to CPUs using `procstat -t 0` and cpuset -l X -t ... -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 19:33:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB4BC1065674 for ; Thu, 2 Feb 2012 19:33:35 +0000 (UTC) (envelope-from adrian.minta@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 61ADE8FC0A for ; Thu, 2 Feb 2012 19:33:35 +0000 (UTC) Received: by eekb47 with SMTP id b47so996595eek.13 for ; Thu, 02 Feb 2012 11:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=plcwtFw28bl+XYIABWn756gfa8c1icbZeXCH4NngrBo=; b=hN58uvHSbysQeXt3TDXFur4NkPbdMssu2ebX+PZig9pjDAKVb2tFlAIvPOCpQyJYrE oWyuu6C5Ua1tIIA1omIkA11QKIEwDm4cP+erzwHxbZUT+WQX+5xj3PE4ykEEUaRHJi7J Uadq/RVLaBlhphPE9Tb4M5AFwv7g1mbxbU5j0= Received: by 10.14.53.74 with SMTP id f50mr1361647eec.5.1328211214363; Thu, 02 Feb 2012 11:33:34 -0800 (PST) Received: from [192.168.10.10] ([188.26.157.100]) by mx.google.com with ESMTPS id n56sm12540198eeh.6.2012.02.02.11.33.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 11:33:33 -0800 (PST) Message-ID: <4F2AE50B.2030500@gmail.com> Date: Thu, 02 Feb 2012 21:33:31 +0200 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F29A464.3080302@zonov.org> <4F2AB53D.7080503@gmail.com> <944787000.20120202191644@yandex.ru> In-Reply-To: <944787000.20120202191644@yandex.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 19:33:35 -0000 On 02/02/12 19:16, wrote: > , Adrian. > > 2 2012 ., 18:09:33: > > AM> A multiqueue network card may help, like a dualport Intel igb E1G42ET. > > actually it is not. Intel have hardware separation to interrupts. > So having only pptp trafic on interface cause next problem: > only one thread process packets instead of 4 posible. > Andrey Zonov sed something about a "web server with multiple nginx instances". From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 19:51:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E86106564A; Thu, 2 Feb 2012 19:51:11 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0FC8FC0C; Thu, 2 Feb 2012 19:51:10 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3122426wgb.31 for ; Thu, 02 Feb 2012 11:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OVP83S0OyVh6itxiLlLB0r28OVKY8SuYYiD5KyvBXts=; b=uBmw40U1VPVNpL6ruE8hO1T0b3PC0iWEdH1MUTmnTfneKmpqhm1Vks5R7kKqRIOtMv R0FYs9XYe/O8jQ5kbmyrmuW+xokHgrre5SfyQRX11awiJo8NkPOHeZ2rAqY6sA0+FsVU KCPVEHUp6s31rNbGb6PO7SMmZIOHj94XLdNc8= MIME-Version: 1.0 Received: by 10.180.78.168 with SMTP id c8mr6794492wix.19.1328212270077; Thu, 02 Feb 2012 11:51:10 -0800 (PST) Received: by 10.180.106.129 with HTTP; Thu, 2 Feb 2012 11:51:10 -0800 (PST) In-Reply-To: <4F2ADF5C.1030900@FreeBSD.org> References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> <1446971288.20120202105912@yandex.ru> <4F2AB0A9.70905@FreeBSD.org> <4F2ADF5C.1030900@FreeBSD.org> Date: Thu, 2 Feb 2012 14:51:10 -0500 Message-ID: From: Ryan Stone To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= , Andrey Zonov Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 19:51:11 -0000 On Thu, Feb 2, 2012 at 2:09 PM, Alexander V. Chernikov wrote: > As far as I understand, the only effect of setting bindthreads to 1 causes > intr_event_bind() to bind soft netisr to appropriate CPU. Can you point me > to ML discussion or some other info clarifying this bug? http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037597.html The intended behaviour is as you describe, unfortunately subsequent threads that are spawned in the intr process inherit the CPU affinity of the last netisr through to be bound to a CPU. From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 19:53:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2358D106566B; Thu, 2 Feb 2012 19:53:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78CAE8FC12; Thu, 2 Feb 2012 19:53:46 +0000 (UTC) Received: by werm13 with SMTP id m13so3375008wer.13 for ; Thu, 02 Feb 2012 11:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nv2/+IC1ZUXH03sQbvlXBmFylHaOCYy9l435LxfFJ/0=; b=aum/bILXEm63fZZdDqJCc+nviDb96gScu+uXapTJb6F2Vm/3PZlVVqm8XmUhxRLZuV WLBkH+95W6VvDsugXv3fI3AYIDbm+j4nIedm/lj5Lfw8AMMFU09A5QsBbf8RlNJ+EEgK VLjq7IY+oEARQ3e0nnMVOwmTJyRUE582DLB9A= MIME-Version: 1.0 Received: by 10.216.131.67 with SMTP id l45mr1728581wei.21.1328212425278; Thu, 02 Feb 2012 11:53:45 -0800 (PST) Received: by 10.180.106.129 with HTTP; Thu, 2 Feb 2012 11:53:45 -0800 (PST) In-Reply-To: References: <4F29A464.3080302@zonov.org> <4F29E2C8.5000909@FreeBSD.org> <4F2A2EAB.3010700@zonov.org> <1446971288.20120202105912@yandex.ru> <4F2AB0A9.70905@FreeBSD.org> <4F2ADF5C.1030900@FreeBSD.org> Date: Thu, 2 Feb 2012 14:53:45 -0500 Message-ID: From: Ryan Stone To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= , Andrey Zonov Subject: Re: netisr defered - active only one thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 19:53:47 -0000 On Thu, Feb 2, 2012 at 2:51 PM, Ryan Stone wrote: > of the last netisr through to be bound to a CPU. *sigh*, that should read "netisr thread" of course. From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 20:07:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEEDD106567B for ; Thu, 2 Feb 2012 20:07:55 +0000 (UTC) (envelope-from confirmation@bounces.fanbridge.com) Received: from r234-m4.fanbridge.com (r234-m4.fanbridge.com [174.37.97.234]) by mx1.freebsd.org (Postfix) with ESMTP id 830B38FC1A for ; Thu, 2 Feb 2012 20:07:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=r234-m4; d=fanbridge.com; h=From:To:Subject:Message-ID:Sender:List-Unsubscribe:List-Id:Date:Content-Type:MIME-Version; i=noreply@fanbridge.com; bh=WFJsPfop947gA92YWHUfeRJNttM=; b=ehX55JDB1Sw97NbD/eeFXdW2CBsrCWVuTfMpackG8IFOu2EjOStQefAx5b4u2EX0uNN/Rqs3LLOl 3Riug7yIhA== DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=r234-m4; d=fanbridge.com; b=cv6y8IMI/oIgSwMh+Bz34aU/IKynm3L5w+grjTPDFlANH6j3CIpaORZybBm1fgScQogeVpPneZLF /fCpks8pmQ==; Received: from 127.0.0.1 (74.86.115.74) by r234-m4.fanbridge.com (PowerMTA(TM) v3.5r15) id h5bmhm1cibcm for ; Thu, 2 Feb 2012 14:32:49 -0500 (envelope-from ) From: "775HipHop.com" To: "freebsd-net@freebsd.org" Message-ID: Sender: FanBridge X-fbridge-uid: 139058 X-fbridge-sid: 189247939 X-fbridge-cfc: ce73673PFXYtPdbhKehFa567Pd X-fbridge-collection: collection-171300 Date: Thu, 02 Feb 2012 14:32:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Please confirm your email for 775HipHop.com's list X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Feb 2012 20:07:55 -0000 Congratulations! You have been added to the fan list! Click on the foll= owing link to confirm/add your details: http://fburls.com/updt/139058|ce73673PFXYtPdbhKehFa567Pd|freebsd-net@fre= ebsd.org IMPORTANT: Be sure to add dhubbard775@gmail.com to your safe senders lis= t to ensure that you get these messages every time. This list is powered by FanBridge the world's leading provider of fan re= lationship management. With FanBridge, your information is kept safe and= never sold to third parties. http://www.fanbridge.com ---------------------------------------- 775HipHop.com sent this email to freebsd-net@freebsd.org Questions? Contact dhubbard775@gmail.com or 775HipHop.com, c/o FanBridge= , Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United=20= States Update Your Information - http://fburls.com/updt/139058|ce73673PFXYtPdbh= KehFa567Pd|freebsd-net@freebsd.org Unsubscribe - http://fburls.com/usub/139058|ce73673PFXYtPdbhKehFa567Pd|1= 89247939 Privacy Policy - http://www.fanbridge.com/learn/privacy.php This email message is powered by FanBridge: http://www.fanbridge.com/b.php?id=3D139058 Powering Valuable Fan Relationships ---------------------------------------- 775HipHop.com sent this email to freebsd-net@freebsd.org Questions? Contact dhubbard775@gmail.com or 775HipHop.com, c/o FanBridge= , Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United=20= States Update Your Information - http://fburls.com/updt/139058|ce73673PFXYtPdbh= KehFa567Pd|freebsd-net@freebsd.org Unsubscribe - http://fburls.com/usub/139058|ce73673PFXYtPdbhKehFa567Pd|1= 89247939 Privacy Policy - http://www.fanbridge.com/learn/privacy.php This email message is powered by FanBridge: http://www.fanbridge.com/b.php?id=3D139058 Powering Valuable Fan Relationships From owner-freebsd-net@FreeBSD.ORG Thu Feb 2 21:35:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A4D106566B for ; Thu, 2 Feb 2012 21:35:07 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4BF68FC0A for ; Thu, 2 Feb 2012 21:35:06 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so3491687bkb.13 for ; Thu, 02 Feb 2012 13:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=4t049EILxu8I/is1orxZWLsYDTlLA1oozBfUC9FLzMM=; b=uB5OejTJbZmp8IqZmXEGn20tYKxaFE1A437Tyus+Dp+tWsh9UEZlNUWqKQtOw7m0Ws ljySeTGTDaqk/LS+Uxi7TxgFU6/9x2llY9von7YLYJpCo8PMpiRMTCTaXQS9D2j33ABI oxR/0eLrZVfI5mvMBMvljSiR+6GfCo51gm4nM= Received: by 10.204.128.146 with SMTP id k18mr631741bks.92.1328218505634; Thu, 02 Feb 2012 13:35:05 -0800 (PST) Received: from rimwks1w7x64 ([31.47.167.64]) by mx.google.com with ESMTPS id cg2sm10539612bkb.12.2012.02.02.13.35.03 (version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 13:35:04 -0800 (PST) From: rozhuk.im@gmail.com To: "'Navdeep Parhar'" References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> In-Reply-To: Date: Fri, 3 Feb 2012 06:34:57 +0900 Message-ID: <4f2b0188.82b7cc0a.2dad.ffff88e9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: Aczhd2nXLNgvfTXZRBuxTnSGGa9qNAAeGNxA Cc: freebsd-net@freebsd.org Subject: RE: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 21:35:07 -0000 The function does not allow access to data if m_flags & M_EXT size and more MHLEN, although the data is actually available. Why if there is no m_flags & M_PKTHDR size anyway MHLEN instead MLEN? As an improvement, you can try to copy the data from the current m in m_next, if m is not enough space and enough m_next (case m_flags & M_EXT). If I figured out MBUF then m_pullup should take maximum length according to this macro #define M_PULLUP_MAX(m) \ ((m)->m_flags & M_EXT ? \ (M_WRITABLE(m) ? (m)->m_ext.ext_size : 0) : \ (m)->m_flags & M_PKTHDR ? MHLEN : MLEN ) /usr/src/sys/sys/param.h:#define MSIZE 256 /* size of an mbuf */ /usr/src/sys/sys/mbuf.h:#define MLEN (MSIZE - sizeof(struct m_hdr)) /* normal data len */ /usr/src/sys/sys/mbuf.h:#define MHLEN (MLEN - sizeof(struct pkthdr)) /* data len w/pkthdr */ #define M_EXT 0x00000001 /* has associated external storage */ /* * If first mbuf has no cluster, and has room for len bytes * without shifting current data, pullup into it, * otherwise allocate a new mbuf to prepend to the chain. */ if ((n->m_flags & M_EXT) == 0 && n->m_data + len < &n->m_dat[MLEN] && n->m_next) { if (n->m_len >= len) return (n); m = n; n = n->m_next; len -= m->m_len; } else { if (len > MHLEN) goto bad; MGET(m, M_DONTWAIT, n->m_type); if (m == NULL) goto bad; m->m_len = 0; if (n->m_flags & M_PKTHDR) M_MOVE_PKTHDR(m, n); } > -----Original Message----- > From: Navdeep Parhar [mailto:nparhar@gmail.com] > Sent: Thursday, February 02, 2012 3:54 PM > To: Rozhuk.IM@gmail.com > Cc: freebsd-net@freebsd.org > Subject: Re: m_pullup - fail > > On Wed, Feb 1, 2012 at 11:07 AM, wrote: > > Hello! > > > > > > The function always returns an error and remove the chain MBUF for > two > > or more generated on the same host. > > If the pre-call m_defrag no error occurs. > > This is normal behavior? > > How to know in advance the maximum size for MBUF that does not cause > a > > failure in m_pullup? > > You can't pullup more than MHLEN bytes into a pkthdr mbuf if it's not > associated with an external cluster. See the last sentence in this > excerpt from mbuf(9): > > m_pullup(mbuf, len) > Arrange that the first len bytes of an mbuf chain are > contiguous > and lay in the data area of mbuf, so they are accessible > with > mtod(mbuf, type). It is important to remember that this may > involve reallocating some mbufs and moving data so all > pointers > referencing data within the old mbuf chain must be > recalculated or > made invalid. Return the new mbuf chain on success, NULL on > fail- > ure (the mbuf chain is freed in this case). Note: It does > not > allocate any mbuf clusters, so len must be less than MHLEN. > > Regards, > Navdeep > > > > > > mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 > > mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 > > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > > > > > _______________________________________________ > > 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 Feb 2 22:03:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB18F106564A for ; Thu, 2 Feb 2012 22:03:20 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 190828FC08 for ; Thu, 2 Feb 2012 22:03:19 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so3516450bkb.13 for ; Thu, 02 Feb 2012 14:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=6JTdty3Oa8gxqRA9ruDAonjGmzNpxtfkfiYdhy3mulU=; b=qdPJaey1eU9vGQt0vv3dI531oOPMTGrVz/vw4GGBN0L7PnZGajlj7VJdffssPqHMBw 5kt112tgTRnShHNR+PG3Jc+ov7OeZK4JEXvKw46rl8+0BTLsALCDINnh5/JJG6+iajlI aU2csFprOv79S1CfskorGKhLoK7kkqMaJmEws= Received: by 10.205.129.141 with SMTP id hi13mr2201020bkc.7.1328220198865; Thu, 02 Feb 2012 14:03:18 -0800 (PST) Received: from rimwks1w7x64 ([31.47.167.64]) by mx.google.com with ESMTPS id fg16sm10680113bkb.16.2012.02.02.14.03.17 (version=SSLv3 cipher=OTHER); Thu, 02 Feb 2012 14:03:18 -0800 (PST) From: rozhuk.im@gmail.com To: "'Julian Elischer'" References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> <4F2A2C1F.1060609@freebsd.org> In-Reply-To: <4F2A2C1F.1060609@freebsd.org> Date: Fri, 3 Feb 2012 07:03:11 +0900 Message-ID: <4f2b0826.10cbcc0a.5660.ffff8aa9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru thread-index: Aczhcyesh/MFazsJSL6FchqEExpIUAAf2Dew Cc: freebsd-net@freebsd.org Subject: RE: m_pullup - fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:03:20 -0000 I am writing a netgraph node for processing UDP packets passing through the router / bridge. Node must fully inspect the entire contents of the package, in some cases, change them. Node is connected to ng_ether (lower, upper). I was faced with the fact that all packets are processed normally, except for packets generated by the router / bridge that is larger than MHLEN. Packet from the network: mbuf: 0xfffffe00a9e27a00 len: 899, next: 0, 3 About the same package generated a router: mbuf: 0xfffffe00a4d59900 len: 42, next: 0xfffffe010a5c4000, 2 mbuf: 0xfffffe010a5c4000 len: 857, next: 0, 1 In this case m_pullup (m, m-> m_pkthdr.len) - returns NULL, though he could move 42 bytes to an external storage (ext) and remove the second mbuf (m_next). > -----Original Message----- > From: Julian Elischer [mailto:julian@freebsd.org] > Sent: Thursday, February 02, 2012 3:25 PM > To: Rozhuk.IM@gmail.com > Cc: freebsd-net@freebsd.org > Subject: Re: m_pullup - fail > > On 2/1/12 11:07 AM, rozhuk.im@gmail.com wrote: > > Hello! > > > > > > The function always returns an error and remove the chain MBUF for > two > > or more generated on the same host. > > If the pre-call m_defrag no error occurs. > > This is normal behavior? > > How to know in advance the maximum size for MBUF that does not cause > a > > failure in m_pullup? > > > > send the list more information.. > like where it is being called from, or a stack trace, or what are you > trying to do? > > > mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2 > > mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1 > > FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252 > > > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net- > unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Feb 3 12:57:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC34A106566C for ; Fri, 3 Feb 2012 12:57:02 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 6861D8FC0C for ; Fri, 3 Feb 2012 12:57:02 +0000 (UTC) Received: from [82.113.106.201] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RtIhH-0000hv-Sj; Fri, 03 Feb 2012 13:57:00 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q13CuvTw002227; Fri, 3 Feb 2012 13:56:57 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q13CuuxY002226; Fri, 3 Feb 2012 13:56:56 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 3 Feb 2012 13:56:56 +0100 From: Matthias Apitz To: freebsd-net@freebsd.org Message-ID: <20120203125655.GA2143@tiny> References: <20120117190847.GA1255@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120117190847.GA1255@tiny> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.106.201 Cc: "Alfred E. Heggestad" Subject: Re: PPP to UMTS provider && incoming traffic (TCP, UDP) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 12:57:03 -0000 El da Tuesday, January 17, 2012 a las 08:08:48PM +0100, Matthias Apitz escribi: > Hello, > > I'm used to connect my FreeBSD 10-CURRENT netbook to Internet via PPP; > the provider in question is a German O2 UMTS provider; so far so good, > i.e. all is working as it should: outbound HTTP, SSH, SMTP (I'm just > sending this mail through such a connection), ... > > what does not work is VoIP; the call is established via SIP (using a > STUN server), but remote audio RTP packages are not coming down; I > checked this with TCPDUMP: only upstream RTP is send, no incoming UDP; the above (only upstream RTP) looks like this in TCPDUMP: 13:32:40.345152 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.366523 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.387812 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.398505 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.419845 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.441164 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.462554 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.483815 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 13:32:40.505161 IP 10.59.47.201.1028 > 86.64.162.35.12978: UDP, length 172 no UDP from 86.64.162.35 (ekiga.net) is coming through while connected via O2 UMTS network; I've borrowed another SIM card from Vodafone.de and with this it looks better like this: 12:07:42.541558 IP 86.64.162.35.11108 > 127.0.0.1.1024: UDP, length 172 12:07:42.549452 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 12:07:42.551554 IP 86.64.162.35.11108 > 127.0.0.1.1024: UDP, length 172 12:07:42.570774 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 12:07:42.572426 IP 86.64.162.35.11108 > 127.0.0.1.1024: UDP, length 172 12:07:42.592137 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 12:07:42.592243 IP 86.64.162.35.11108 > 127.0.0.1.1024: UDP, length 172 12:07:42.611989 IP 86.64.162.35.11108 > 127.0.0.1.1024: UDP, length 172 12:07:42.613485 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 12:07:42.634805 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 12:07:42.656108 IP 109.43.97.247.1024 > 86.64.162.35.11108: UDP, length 172 ... i.e. there is coming RTP traffic down with destination 127.0.0.1 (localhost); but the SIP client 'baresip' does not see this; in 'baresip' only the outbound bit/s shows some value ~64255 bit/s, while the inbound stucks with zero; any idea? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-net@FreeBSD.ORG Fri Feb 3 18:03:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 485E7106566C for ; Fri, 3 Feb 2012 18:03:32 +0000 (UTC) (envelope-from alex323@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA4F78FC14 for ; Fri, 3 Feb 2012 18:03:31 +0000 (UTC) Received: by qcmt40 with SMTP id t40so3174207qcm.13 for ; Fri, 03 Feb 2012 10:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; bh=/n1tu9PvACri3sgIAIKOYx+Qye9mqhxuH3S7k8+IXHA=; b=Lo7M0+/U63BLwI+XiJs75VklyyoBPQ2ykXE+eOZeZHiFECxBJkUwplqHtHcQ8okAf0 zNuEPph05i9YgwCgW0mt/OS3Ipk1dggjCyYCYOgAzdZeDiZGqKwvsTSjdMj5DyCYaDTA ZsfKwrVkIE621nVVjmkVG/GvPIA1j4kTa4XXw= Received: by 10.229.111.165 with SMTP id s37mr3204028qcp.80.1328290433501; Fri, 03 Feb 2012 09:33:53 -0800 (PST) Received: from poseidon (student1-829.unh.edu. [132.177.51.229]) by mx.google.com with ESMTPS id k19sm7734238qak.4.2012.02.03.09.33.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Feb 2012 09:33:52 -0800 (PST) Date: Fri, 3 Feb 2012 12:33:46 -0500 From: Alex To: freebsd-net@freebsd.org Message-ID: <20120203123346.7fad1800@poseidon> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/FKzu6zkx6lJy6FS/JmY+jC1"; protocol="application/pgp-signature" Subject: Kernel panic when destroying a jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Feb 2012 18:03:32 -0000 --Sig_/FKzu6zkx6lJy6FS/JmY+jC1 Content-Type: multipart/mixed; boundary="MP_/d0cLc4djrluDlAu9NSIzsg4" --MP_/d0cLc4djrluDlAu9NSIzsg4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello. I have found that you can make a GENERIC 9.0-RELEASE kernel crash if you kldload pf, create a jail, and then destroy it. See the attached stack trace. --=20 Alex --MP_/d0cLc4djrluDlAu9NSIzsg4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=core.txt agoravm dumped core - see /var/crash/vmcore.0 Fri Feb 3 12:15:28 EST 2012 FreeBSD agoravm 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 2 23:15:10 EST= 2012 root@agoravm:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x11 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff81623012 stack pointer =3D 0x28:0xffffff80003cb540 frame pointer =3D 0x28:0xffffff80003cb550 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1311 (jail) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff80869cde at kdb_backtrace+0x5e #1 0xffffffff808345c7 at panic+0x187 #2 0xffffffff80b342b0 at trap_fatal+0x290 #3 0xffffffff80b345f9 at trap_pfault+0x1f9 #4 0xffffffff80b34abf at trap+0x3df #5 0xffffffff80b1efef at calltrap+0x8 #6 0xffffffff8162461e at pfi_cleanup+0x16e #7 0xffffffff816293c8 at vnet_pf_uninit+0x1b8 #8 0xffffffff80908f37 at vnet_sysuninit+0x47 #9 0xffffffff80909083 at vnet_destroy+0xe3 #10 0xffffffff8080f405 at prison_deref+0x145 #11 0xffffffff8080fcc1 at sys_jail_remove+0x311 #12 0xffffffff80b33ba0 at amd64_syscall+0x450 #13 0xffffffff80b1f2d7 at Xfast_syscall+0xf7 Uptime: 3m47s Dumping 83 out of 1005 MB:..20%..39%..58%..77%..96% Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel= /pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff80834105 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:442 #2 0xffffffff808345b1 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:607 #3 0xffffffff80b342b0 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" is = not available. ) at /usr/src/sys/amd64/amd64/trap.c:819 #4 0xffffffff80b345f9 in trap_pfault (frame=3D0xffffff80003cb490, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:735 #5 0xffffffff80b34abf in trap (frame=3D0xffffff80003cb490) at /usr/src/sys/amd64/amd64/trap.c:474 #6 0xffffffff80b1efef in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff81623012 in pfi_ifhead_RB_MINMAX (head=3D0xffffff8000a55d70,= =20 val=3D-1) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:130 #8 0xffffffff8162461e in pfi_cleanup () at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:205 #9 0xffffffff816293c8 in vnet_pf_uninit (unused=3DVariable "unused" is not= available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:4415 #10 0xffffffff80908f37 in vnet_sysuninit () at /usr/src/sys/net/vnet.c:634 #11 0xffffffff80909083 in vnet_destroy (vnet=3D0xfffffe000244f440) at /usr/src/sys/net/vnet.c:290 #12 0xffffffff8080f405 in prison_deref (pr=3D0xfffffe00029e2000, flags=3D16) at /usr/src/sys/kern/kern_jail.c:2508 #13 0xffffffff8080fcc1 in sys_jail_remove (td=3D0xfffffe000291f8c0,=20 uap=3D0xffffff80003cbbc0) at /usr/src/sys/kern/kern_jail.c:2169 #14 0xffffffff80b33ba0 in amd64_syscall (td=3D0xfffffe000291f8c0, traced=3D= 0) at subr_syscall.c:131 #15 0xffffffff80b1f2d7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #16 0x0000000800cb92bc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -52 0 0 0 - DLs ?? 0:00.00 [kernel] 0 1 0 0 20 0 6280 0 - RLs ?? 0:00.00 [init] 0 2 0 0 -16 0 0 0 waitin DL ?? 0:00.00 [sctp_i= tera 0 3 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_th= rd] 0 4 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [pageda= emon 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [vmdaem= on] 0 6 0 0 155 0 0 0 pgzero DL ?? 0:00.00 [pageze= ro] 0 7 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [bufdae= mon] 0 8 0 0 -16 0 0 0 vlruwt DL ?? 0:00.00 [vnlru] 0 9 0 0 16 0 0 0 syncer DL ?? 0:00.00 [syncer] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL ?? 3:43.87 [idle] 0 12 0 0 -84 0 0 0 - WL ?? 0:00.17 [intr] 0 13 0 0 -8 0 0 0 - DL ?? 0:00.10 [geom] 0 14 0 0 -16 0 0 0 - DL ?? 0:00.00 [yarrow] 0 15 0 0 -68 0 0 0 - DL ?? 0:00.00 [usb] 0 16 0 0 -16 0 0 0 sdflus DL ?? 0:00.00 [softde= pflu 0 130 1 0 52 0 10060 0 pause Ds ?? 0:00.00 [adjker= ntz] 0 484 1 0 52 0 10052 0 select Ds ?? 0:00.00 [dhclie= nt] 65 522 1 0 20 0 10052 0 select Ds ?? 0:00.00 [dhclie= nt] 0 538 1 0 52 0 10372 0 select Ds ?? 0:00.00 [devd] 0 670 1 0 20 0 12184 0 select Ds ?? 0:00.00 [syslog= d] 0 914 1 0 20 0 20384 0 select Ds ?? 0:00.00 [sendma= il] 25 918 1 0 52 0 20384 0 pause Ds ?? 0:00.00 [sendma= il] 0 924 1 0 20 0 14260 0 nanslp Ds ?? 0:00.00 [cron] 0 982 1 0 25 0 41300 0 wait Ds ?? 0:00.00 [login] 0 983 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 984 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 985 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 986 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 987 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 988 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 989 1 0 52 0 12184 0 ttyin Ds+ ?? 0:00.00 [getty] 0 990 982 0 23 0 14612 0 pause D ?? 0:00.01 [csh] 0 1000 0 0 -16 0 0 0 pftm DL ?? 0:00.00 [pfpurg= e] 0 1196 1 0 -100 0 0 0 - ZW ?? 0:00.00 0 1311 990 0 23 0 14256 0 - R+ ?? 0:00.01 [jail] ------------------------------------------------------------------------ vmstat -s 49875 cpu context switches 3201 device interrupts 11278 software interrupts 111426 traps 154005 system calls 18 kernel threads created 1346 fork() calls 35 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 276 vnode pager pageins 2123 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 76 pages reactivated 44452 copy-on-write faults 415 copy-on-write optimized faults 32249 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 104095 total VM faults taken 0 pages affected by kernel thread creation 684686 pages affected by fork() 17113 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 113025 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 2614 pages active 2123 pages inactive 4 pages in VM cache 8218 pages wired down 236554 pages free 4096 bytes per page 19438 total name lookups cache hits (84% pos + 8% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) ata_pci 1 1K - 1 64 feeder 12 1K - 14 32,128 isadev 8 1K - 8 128 cdev 8 2K - 8 256 acpidev 22 2K - 22 64 mixer 1 4K - 1 4096 sigio 1 1K - 1 64 filedesc 36 18K - 1400 512 kenv 99 12K - 110 16,32,64,128 kqueue 0 0K - 26 256,2048 proc-args 19 1K - 485 16,32,64,128,256 hhook 4 1K - 4 128 ithread 60 11K - 60 32,128,256 prison 1 4K - 1 4096 KTRACE 100 13K - 100 128 linker 170 139K - 178 16,32,64,128,256,512,1024,2048= ,4096 lockf 17 2K - 65 64,128 loginclass 2 1K - 6 64 ip6ndp 6 1K - 11 64,128 temp 20 1K - 6238 16,32,64,128,256,1024,2048,4096 devbuf 400 1315K - 422 16,32,64,128,256,512,1024,2048= ,4096 module 449 57K - 449 128 mtx_pool 2 16K - 2 =20 subproc 89 174K - 1452 512,4096 proc 2 16K - 2 =20 session 17 3K - 19 128 pgrp 19 3K - 44 128 cred 32 5K - 3668 64,256 uidinfo 4 3K - 5 128,2048 plimit 13 4K - 210 256 sysctltmp 0 0K - 300 16,32,64,128,4096 sysctloid 1818 90K - 1852 16,32,64,128 sysctl 0 0K - 504 16,32,64 tidhash 1 16K - 1 =20 umtx 174 22K - 174 128 p1003.1b 1 1K - 1 16 SWAP 2 141K - 2 64 bus-sc 30 52K - 1236 16,32,128,256,512,1024,2048,40= 96 bus 910 74K - 2827 16,32,64,128,256,1024 devstat 10 21K - 10 32,4096 eventhandler 98 8K - 104 64,128 pci_link 8 1K - 8 16,128 kobj 322 1288K - 459 4096 Per-cpu 1 1K - 1 32 rman 89 11K - 254 32,128 sbuf 0 0K - 1010 16,32,64,128,256,512,1024,2048= ,4096 stack 0 0K - 2 256 taskqueue 17 2K - 17 16,32,128 Unitno 14 1K - 3530 32,64 iov 0 0K - 180 64,128,256,512 select 7 1K - 7 128 ioctlops 0 0K - 1343 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 =20 tty 19 19K - 21 1024,2048 mbuf_tag 0 0K - 31 32 shmfd 1 8K - 1 =20 pcb 15 157K - 48 16,32,128,1024,2048,4096 soname 3 1K - 264 16,32,128 vfscache 1 1024K - 1 =20 vfs_hash 1 512K - 1 =20 acpiintr 1 1K - 1 64 vnodes 2 1K - 2 256 acpica 2040 230K - 21415 16,32,64,128,256,1024,4096 vnodemarker 0 0K - 105 512 mount 61 3K - 181 16,32,64,128,256,1024 BPF 10 10K - 11 128,512,4096 ether_multi 15 1K - 44 16,32,64 ifaddr 62 21K - 87 32,64,128,256,512,2048,4096 ifnet 7 11K - 8 128,2048 clone 8 32K - 10 4096 epair 2 1K - 2 128 arpcom 3 1K - 3 16 lltable 14 6K - 22 256,512 USBdev 4 2K - 4 64,128,1024 USB 7 3K - 7 16,32,128,2048 acpitask 1 2K - 1 2048 CAM dev queue 3 1K - 3 128 CAM queue 13 1K - 51 16,32 routetbl 36 6K - 141 32,64,128,256,512 vnet_data_free 1 1K - 1 32 vnet_data 2 56K - 2 =20 vnet 2 1K - 2 64 igmp 5 2K - 8 256 acpisem 16 2K - 16 128 CAM SIM 3 1K - 3 256 in_multi 2 1K - 4 256 sctp_iter 0 0K - 3 256 sctp_ifn 2 1K - 3 128 sctp_ifa 6 1K - 6 128 sctp_vrf 1 1K - 2 64 sctp_a_it 0 0K - 3 16 hostcache 1 28K - 2 =20 syncache 1 96K - 2 =20 scsi_cd 0 0K - 4 16 in6_multi 12 2K - 18 32,256 entropy 1024 64K - 1024 64 CAM periph 6 2K - 20 16,32,64,128,256 mld 5 1K - 8 128 rpc 2 1K - 2 256 audit_evclass 179 6K - 218 32 jblocks 8 2K - 8 128,256 savedino 0 0K - 33 256 sbdep 0 0K - 11 64 jsegdep 4 1K - 118 64 jseg 3 1K - 11 128 jfreefrag 0 0K - 1 128 jnewblk 0 0K - 41 128 jremref 0 0K - 33 128 jaddref 0 0K - 43 128 freework 3 1K - 32 128 newdirblk 0 0K - 6 64 dirrem 0 0K - 21 128 mkdir 0 0K - 12 128 diradd 1 1K - 31 128 freefile 0 0K - 19 64 freeblks 2 1K - 31 128 freefrag 0 0K - 1 128 newblk 3 65K - 42 256 bmsafemap 2 9K - 14 256 inodedep 3 513K - 51 512 pagedep 2 65K - 17 256 ufs_dirhash 39 8K - 39 16,32,64,128,512 ufs_mount 12 50K - 12 512,4096 vm_pgdata 2 129K - 2 128 CAM XPT 36 16K - 109 32,64,128,1024,2048 kbdmux 6 18K - 6 16,512,1024,2048 DEVFS1 82 41K - 99 512 DEVFS3 99 25K - 120 256 DEVFS 18 1K - 19 16,128 DEVFSP 1 1K - 1 64 atkbddev 2 1K - 2 64 apmdev 1 1K - 1 128 pfs_nodes 21 6K - 21 256 io_apic 1 2K - 1 2048 LED 2 1K - 2 16,128 GEOM 75 15K - 792 16,32,64,128,256,512,1024,2048 nexusdev 3 1K - 3 16 ac97 2 1K - 2 16,512 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 120, 33, 140, 0, 0 UMA Zones: 512, 0, 120, 20, 140, 0, 0 UMA Slabs: 568, 0, 845, 9, 1335, 0, 0 UMA RCntSlabs: 568, 0, 195, 1, 195, 0, 0 UMA Hash: 256, 0, 3, 12, 3, 0, 0 16 Bucket: 152, 0, 40, 10, 44, 0, 0 32 Bucket: 280, 0, 26, 2, 26, 0, 0 64 Bucket: 536, 0, 17, 4, 17, 57, 0 128 Bucket: 1048, 0, 20, 4, 24, 568, 0 VM OBJECT: 216, 0, 971, 127, 17549, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 55862, 25, 130, 1446, 0, 0 MAP ENTRY: 120, 0, 382, 207, 39522, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 305, 6, 305, 0, 0 16: 16, 0, 1023, 153, 11299, 0, 0 32: 32, 0, 1080, 132, 8269, 0, 0 64: 64, 0, 2472, 160, 14619, 0, 0 128: 128, 0, 3387, 122, 5449, 0, 0 256: 256, 0, 340, 50, 2977, 0, 0 512: 512, 0, 256, 31, 2381, 0, 0 1024: 1024, 0, 38, 58, 1604, 0, 0 2048: 2048, 0, 30, 4, 137, 0, 0 4096: 4096, 0, 408, 15, 7118, 0, 0 Files: 80, 0, 49, 86, 5887, 0, 0 TURNSTILE: 136, 0, 88, 12, 88, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 36, 15, 1399, 0, 0 THREAD: 1112, 0, 75, 12, 75, 0, 0 SLEEPQUEUE: 80, 0, 88, 28, 88, 0, 0 VMSPACE: 392, 0, 19, 21, 1383, 0, 0 cpuset: 72, 0, 3, 97, 6, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 256, 141, 280, 0, 0 mbuf: 256, 0, 2, 139, 139, 0, 0 mbuf_cluster: 2048, 25600, 384, 6, 384, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 64, 4708, 0, 0 ttyinq: 160, 0, 120, 24, 255, 0, 0 ttyoutq: 256, 0, 64, 11, 136, 0, 0 ata_request: 328, 0, 1, 23, 3337, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 VNODE: 480, 0, 688, 8, 709, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 12, 9179, 0, 0 S VFS Cache: 108, 0, 690, 36, 1281, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 56, 0, 56, 0, 0 NCLNODE: 560, 0, 0, 0, 0, 0, 0 Mountpoints: 768, 0, 5, 5, 5, 0, 0 pipe: 728, 0, 1, 9, 871, 0, 0 ksiginfo: 112, 0, 42, 1014, 51, 0, 0 itimer: 344, 0, 0, 0, 0, 0, 0 KNOTE: 128, 0, 0, 58, 26, 0, 0 bridge_rtnode: 64, 0, 0, 0, 0, 0, 0 socket: 680, 25602, 11, 7, 217, 0, 0 unpcb: 240, 25600, 6, 26, 57, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 2, 18, 138, 0, 0 udpcb: 16, 25704, 2, 166, 138, 0, 0 tcp_inpcb: 392, 25600, 1, 19, 3, 0, 0 tcpcb: 976, 25600, 1, 7, 3, 0, 0 tcptw: 72, 5150, 0, 0, 0, 0, 0 syncache: 152, 15375, 0, 0, 0, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 1680, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1368, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2280, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 144, 3, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 1, 19, 1, 0, 0 rtentry: 200, 0, 13, 25, 14, 0, 0 selfd: 56, 0, 16, 110, 292, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 658, 2, 677, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 658, 32, 677, 0, 0 pfsrctrpl: 152, 0, 0, 0, 0, 0, 0 pfrulepl: 936, 0, 0, 0, 0, 0, 0 pfstatepl: 288, 10010, 0, 0, 0, 0, 0 pfstatekeypl: 288, 0, 0, 0, 0, 0, 0 pfstateitempl: 288, 0, 0, 0, 0, 0, 0 pfaltqpl: 240, 0, 0, 0, 0, 0, 0 pfpooladdrpl: 88, 0, 0, 0, 0, 0, 0 pfrktable: 1296, 0, 0, 0, 0, 0, 0 pfrkentry: 160, 0, 0, 0, 0, 0, 0 pffrent: 32, 5050, 0, 0, 0, 0, 0 pffrag: 80, 0, 0, 0, 0, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0, 0 pfstatescrub: 40, 0, 0, 0, 0, 0, 0 pfiaddrpl: 120, 0, 0, 0, 0, 0, 0 pfospfen: 112, 0, 0, 0, 0, 0, 0 pfosfp: 40, 0, 0, 0, 0, 0, 0 pfsrctrpl: 152, 0, 0, 0, 0, 0, 0 pfrulepl: 936, 0, 0, 0, 0, 0, 0 pfstatepl: 288, 10010, 0, 0, 0, 0, 0 pfstatekeypl: 288, 0, 0, 0, 0, 0, 0 pfstateitempl: 288, 0, 0, 0, 0, 0, 0 pfaltqpl: 240, 0, 0, 0, 0, 0, 0 pfpooladdrpl: 88, 0, 0, 0, 0, 0, 0 pfrktable: 1296, 0, 0, 0, 0, 0, 0 pfrkentry: 160, 0, 0, 0, 0, 0, 0 pffrent: 32, 5050, 0, 0, 0, 0, 0 pffrag: 80, 0, 0, 0, 0, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0, 0 pfstatescrub: 40, 0, 0, 0, 0, 0, 0 pfiaddrpl: 120, 0, 0, 0, 0, 0, 0 pfospfen: 112, 0, 0, 0, 0, 0, 0 pfosfp: 40, 0, 0, 0, 0, 0, 0 rtentry: 200, 0, 0, 38, 6, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 852 85 irq14: ata0 2299 229 irq15: ata1 17 1 irq19: em0 32 3 cpu0:timer 9310 931 Total 12510 1251 ------------------------------------------------------------------------ pstat -T 49/12328 files 0M/1023M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0p3 2096896 0 2096896 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 cd0 pass0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 16.74 147 2.40 0.00 1 0.00 0.00 0 0.00 0 0 1 0 99 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP = CBYTES QNUM QBYTES LSPI= D LRPID STIME RTIME CTIME =20 Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NATTCH SEGSZ CPID LPID ATIME DTIME CTIM= E =20 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NSEMS OTIME CTIME =20 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Mi= sses 0 0 0 0 0 0 0 = 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Mi= sses 0 0 0 0 0 0 0 = 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 2 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 13 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 13 delivered 13 datagrams output 0 times multicast source filter matched ip: 14 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 13 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 13 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 2 ARP requests sent 0 ARP replies sent 0 ARP requests received 1 ARP reply received 1 ARP packet received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 258/280/538 mbufs in use (current/cache/total) 243/147/390/25600 mbuf clusters in use (current/cache/total/max) 256/141 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 550K/364K/914K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts O= errs Coll Drop em0 1500 08:00:27:cc:ee:43 15 0 0 16 = 0 0 0=20 em0 1500 10.0.2.0 10.0.2.15 13 - - 13 = - - -=20 usbus 0 0 0 0 0 = 0 0 0=20 lo0 16384 0 0 0 0 = 0 0 0=20 lo0 16384 localhost ::1 0 - - 0 = - - -=20 lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 = - - -=20 lo0 16384 your-net localhost 0 - - 0 = - - -=20 epair 1500 02:95:54:00:04:0a 0 0 0 0 = 0 0 0=20 epair 1500 02:95:54:00:05:0b 0 0 0 0 = 4 0 0=20 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.2.2 UGS 0 13 em0 10.0.2.0/24 link#1 U 0 0 em0 10.0.2.15 link#1 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 0 lo0 Internet6: Destination Gateway Flags = Netif Expire ::/96 ::1 UGRS = lo0 ::1 ::1 UH = lo0 ::ffff:0.0.0.0/96 ::1 UGRS = lo0 fe80::/10 ::1 UGRS = lo0 fe80::%lo0/64 link#3 U = lo0 fe80::1%lo0 link#3 UHS = lo0 ff01::%lo0/32 ::1 U = lo0 ff02::/16 ::1 UGRS = lo0 ff02::%lo0/32 ::1 U = lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address = (state) fffffe00028b6b70 tcp4 0 0 127.0.0.1.25 *.* = LISTEN fffffe000270d188 udp4 0 0 *.514 *.* = =20 fffffe000270d000 udp6 0 0 *.514 *.* = =20 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe0002693d20 stream 0 0 fffffe0002706780 0 0 = 0 /var/run/devd.pipe fffffe0002693870 dgram 0 0 0 fffffe00026935a0 0 ff= fffe0002693690 fffffe0002693780 dgram 0 0 0 fffffe00026934b0 0 = 0 fffffe0002693690 dgram 0 0 0 fffffe00026935a0 0 = 0 fffffe00026935a0 dgram 0 0 fffffe00027d4d20 0 fffffe00026= 93870 0 /var/run/logpriv fffffe00026934b0 dgram 0 0 fffffe00027d5000 0 fffffe00026= 93780 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address =20 tcp4 0/0/10 localhost.smtp =20 unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root jail 1311 root / 2 drwxr-xr-x 1024 r root jail 1311 wd /var 189441 drwxr-x--- 512 r root jail 1311 text /usr 142193 -r-xr-xr-x 16264 r root jail 1311 ctty /dev 42 crw------- ttyv0 rw root jail 1311 0 /dev 42 crw------- ttyv0 rw root jail 1311 1 /dev 42 crw------- ttyv0 rw root jail 1311 2 /dev 42 crw------- ttyv0 rw root pfpurge 1000 root / 2 drwxr-xr-x 1024 r root pfpurge 1000 wd / 2 drwxr-xr-x 1024 r root csh 990 root / 2 drwxr-xr-x 1024 r root csh 990 wd /var 189441 drwxr-x--- 512 r root csh 990 text / 33192 -r-xr-xr-x 368896 r root csh 990 ctty /dev 42 crw------- ttyv0 rw root csh 990 15 /dev 42 crw------- ttyv0 rw root csh 990 16 /dev 42 crw------- ttyv0 rw root csh 990 17 /dev 42 crw------- ttyv0 rw root csh 990 18 /dev 42 crw------- ttyv0 rw root csh 990 19 /dev 42 crw------- ttyv0 rw root getty 989 root / 2 drwxr-xr-x 1024 r root getty 989 wd / 2 drwxr-xr-x 1024 r root getty 989 text /usr 331531 -r-xr-xr-x 27512 r root getty 989 ctty /dev 49 crw------- ttyv7 rw root getty 989 0 /dev 49 crw------- ttyv7 rw root getty 989 1 /dev 49 crw------- ttyv7 rw root getty 989 2 /dev 49 crw------- ttyv7 rw root getty 988 root / 2 drwxr-xr-x 1024 r root getty 988 wd / 2 drwxr-xr-x 1024 r root getty 988 text /usr 331531 -r-xr-xr-x 27512 r root getty 988 ctty /dev 48 crw------- ttyv6 rw root getty 988 0 /dev 48 crw------- ttyv6 rw root getty 988 1 /dev 48 crw------- ttyv6 rw root getty 988 2 /dev 48 crw------- ttyv6 rw root getty 987 root / 2 drwxr-xr-x 1024 r root getty 987 wd / 2 drwxr-xr-x 1024 r root getty 987 text /usr 331531 -r-xr-xr-x 27512 r root getty 987 ctty /dev 47 crw------- ttyv5 rw root getty 987 0 /dev 47 crw------- ttyv5 rw root getty 987 1 /dev 47 crw------- ttyv5 rw root getty 987 2 /dev 47 crw------- ttyv5 rw root getty 986 root / 2 drwxr-xr-x 1024 r root getty 986 wd / 2 drwxr-xr-x 1024 r root getty 986 text /usr 331531 -r-xr-xr-x 27512 r root getty 986 ctty /dev 46 crw------- ttyv4 rw root getty 986 0 /dev 46 crw------- ttyv4 rw root getty 986 1 /dev 46 crw------- ttyv4 rw root getty 986 2 /dev 46 crw------- ttyv4 rw root getty 985 root / 2 drwxr-xr-x 1024 r root getty 985 wd / 2 drwxr-xr-x 1024 r root getty 985 text /usr 331531 -r-xr-xr-x 27512 r root getty 985 ctty /dev 45 crw------- ttyv3 rw root getty 985 0 /dev 45 crw------- ttyv3 rw root getty 985 1 /dev 45 crw------- ttyv3 rw root getty 985 2 /dev 45 crw------- ttyv3 rw root getty 984 root / 2 drwxr-xr-x 1024 r root getty 984 wd / 2 drwxr-xr-x 1024 r root getty 984 text /usr 331531 -r-xr-xr-x 27512 r root getty 984 ctty /dev 44 crw------- ttyv2 rw root getty 984 0 /dev 44 crw------- ttyv2 rw root getty 984 1 /dev 44 crw------- ttyv2 rw root getty 984 2 /dev 44 crw------- ttyv2 rw root getty 983 root / 2 drwxr-xr-x 1024 r root getty 983 wd / 2 drwxr-xr-x 1024 r root getty 983 text /usr 331531 -r-xr-xr-x 27512 r root getty 983 ctty /dev 43 crw------- ttyv1 rw root getty 983 0 /dev 43 crw------- ttyv1 rw root getty 983 1 /dev 43 crw------- ttyv1 rw root getty 983 2 /dev 43 crw------- ttyv1 rw root login 982 root / 2 drwxr-xr-x 1024 r root login 982 wd / 16516 drwxr-xr-x 512 r root login 982 text /usr 1136858 -r-sr-xr-x 25096 r root login 982 ctty /dev 42 crw------- ttyv0 rw root login 982 0 /dev 42 crw------- ttyv0 rw root login 982 1 /dev 42 crw------- ttyv0 rw root login 982 2 /dev 42 crw------- ttyv0 rw root login 982 3* local dgram fffffe0002693870 <-> fffffe0002= 6935a0 root cron 924 root / 2 drwxr-xr-x 1024 r root cron 924 wd /var 94721 drwxr-x--- 512 r root cron 924 text /usr 142147 -r-xr-xr-x 41344 r root cron 924 0 /dev 28 crw-rw-rw- null rw root cron 924 1 /dev 28 crw-rw-rw- null rw root cron 924 2 /dev 28 crw-rw-rw- null rw root cron 924 3 /var 47391 -rw------- 3 w smmsp sendmail 918 root / 2 drwxr-xr-x 1024 r smmsp sendmail 918 wd /var 94730 drwxrwx--- 512 r smmsp sendmail 918 text /usr 331579 -r-xr-sr-x 707160 r smmsp sendmail 918 0 /dev 28 crw-rw-rw- null r smmsp sendmail 918 1 /dev 28 crw-rw-rw- null w smmsp sendmail 918 2 /dev 28 crw-rw-rw- null w smmsp sendmail 918 3* local dgram fffffe0002693780 <-> fffffe0002= 6934b0 smmsp sendmail 918 4 /var 94751 -rw------- 49 w root sendmail 914 root / 2 drwxr-xr-x 1024 r root sendmail 914 wd /var 94727 drwxr-xr-x 512 r root sendmail 914 text /usr 331579 -r-xr-sr-x 707160 r root sendmail 914 0 /dev 28 crw-rw-rw- null r root sendmail 914 1 /dev 28 crw-rw-rw- null w root sendmail 914 2 /dev 28 crw-rw-rw- null w root sendmail 914 3* internet stream tcp fffffe00028b6b70 root sendmail 914 4* local dgram fffffe0002693690 <-> fffffe0002= 6935a0 root sendmail 914 5 /var 47388 -rw------- 78 w root syslogd 670 root / 2 drwxr-xr-x 1024 r root syslogd 670 wd / 2 drwxr-xr-x 1024 r root syslogd 670 text /usr 142313 -r-xr-xr-x 39808 r root syslogd 670 0 /dev 28 crw-rw-rw- null rw root syslogd 670 1 /dev 28 crw-rw-rw- null rw root syslogd 670 2 /dev 28 crw-rw-rw- null rw root syslogd 670 3 /var 47381 -rw------- 3 w root syslogd 670 4* local dgram fffffe00026934b0 root syslogd 670 5* local dgram fffffe00026935a0 root syslogd 670 6* internet6 dgram udp fffffe000270d000 root syslogd 670 7* internet dgram udp fffffe000270d188 root syslogd 670 8 /dev 7 crw------- klog r root syslogd 670 10 - - bad - root syslogd 670 11 /var 142106 -rw-r--r-- 20011 w root syslogd 670 12 /var 142108 -rw------- 62 w root syslogd 670 13 /var 142101 -rw------- 398 w root syslogd 670 14 /var 142105 -rw-r----- 797 w root syslogd 670 15 /var 142104 -rw-r--r-- 62 w root syslogd 670 16 /var 142109 -rw------- 62 w root syslogd 670 17 /var 142102 -rw------- 882 w root syslogd 670 18 /var 142103 -rw------- 62 w root syslogd 670 19 /var 142107 -rw-r----- 62 w root devd 538 root / 2 drwxr-xr-x 1024 r root devd 538 wd / 2 drwxr-xr-x 1024 r root devd 538 text / 33042 -r-xr-xr-x 423552 r root devd 538 0 /dev 28 crw-rw-rw- null rw root devd 538 1 /dev 28 crw-rw-rw- null rw root devd 538 2 /dev 28 crw-rw-rw- null rw root devd 538 3 /dev 6 crw------- devctl r root devd 538 4* local stream fffffe0002693d20 root devd 538 5 /var 47374 -rw------- 3 w _dhcp dhclient 522 root /var 94722 dr-xr-xr-x 512 r _dhcp dhclient 522 wd /var 94722 dr-xr-xr-x 512 r _dhcp dhclient 522 jail /var 94722 dr-xr-xr-x 512 r _dhcp dhclient 522 text / 33044 -r-xr-xr-x 92328 r _dhcp dhclient 522 0 /dev 28 crw-rw-rw- null rw _dhcp dhclient 522 1 /dev 28 crw-rw-rw- null rw _dhcp dhclient 522 2 /dev 28 crw-rw-rw- null rw _dhcp dhclient 522 4* route raw 0 fffffe000270c000 _dhcp dhclient 522 5* pipe fffffe0002639158 <-> fffffe0002639000 = 0 rw _dhcp dhclient 522 6 /var 142100 ---------- 856 w _dhcp dhclient 522 7 /dev 11 crw------- bpf rw _dhcp dhclient 522 8* internet raw ip fffffe0002817000 root dhclient 484 root / 2 drwxr-xr-x 1024 r root dhclient 484 wd / 2 drwxr-xr-x 1024 r root dhclient 484 text / 33044 -r-xr-xr-x 92328 r root dhclient 484 0 /dev 28 crw-rw-rw- null rw root dhclient 484 1 /dev 28 crw-rw-rw- null rw root dhclient 484 2 /dev 28 crw-rw-rw- null rw root dhclient 484 4* pipe fffffe0002639000 <-> fffffe0002639158 = 0 rw root adjkerntz 130 root / 2 drwxr-xr-x 1024 r root adjkerntz 130 wd / 2 drwxr-xr-x 1024 r root adjkerntz 130 text / 33031 -r-xr-xr-x 9248 r root adjkerntz 130 0 /dev 28 crw-rw-rw- null rw root adjkerntz 130 1 /dev 28 crw-rw-rw- null rw root adjkerntz 130 2 /dev 28 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 33068 -r-xr-xr-x 772528 r root kernel 0 root / 2 drwxr-xr-x 1024 r root kernel 0 wd / 2 drwxr-xr-x 1024 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Thu Feb 2 23:15:10 EST 2012 root@agoravm:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3392.40-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a St= epping =3D 7 Features=3D0x783fbff Features2=3D0x209 AMD Features=3D0x20100800 AMD Features2=3D0x1 real memory =3D 1073676288 (1023 MB) avail memory =3D 1011130368 (964 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: WARNING: VIMAGE (virtualized network stack) is a highly experimental featur= e. ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 vgapci0: mem 0xe0000000-0xe0ffffff irq 18 at devic= e 2.0 on pci0 em0: port 0xd010-0xd017= mem 0xf0000000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:cc:ee:43 pci0: at device 4.0 (no driver attached) pcm0: port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at devi= ce 5.0 on pci0 pcm0: ohci0: mem 0xf0804000-0xf0804fff irq 22 at = device 6.0 on pci0 usbus0: on ohci0 pci0: at device 7.0 (no driver attached) acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 attimer0: port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 37383 Hz usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 30720MB (62914560 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Timecounter "TSC" frequency 3392402500 Hz quality 800 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw]... Setting hostuuid: 7e34803e-fdf9-40a7-a49f-44831c3ddec4. Setting hostid: 0xfd3fe22c. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 93433 free (433 frags, 11625 blocks, 0.2% fragmentation) /dev/ada0p4: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p4: clean, 1022384 free (40 frags, 127793 blocks, 0.0% fragmentati= on) /dev/ada0p5: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p5: clean, 127865 free (33 frags, 15979 blocks, 0.0% fragmentation) /dev/ada0p6: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p6: clean, 5326551 free (1255 frags, 665662 blocks, 0.0% fragmenta= tion) Mounting local file systems:. Setting hostname: agoravm. Starting Network: lo0 em0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:cc:ee:43 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active Starting devd. Starting Network: usbus0. DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 10.0.2.15 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Creating and/or trimming log files. Starting syslogd. No core dumps found. ELF ldconfig path: /lib /usr/lib /usr/lib/compat 32-bit compatibility ldconfig path: /usr/lib32 Clearing /tmp (X related). Updating motd:. Configuring syscons: blanktime. Starting cron. Starting background file system checks in 60 seconds. Fri Feb 3 12:11:23 EST 2012 Feb 3 12:11:25 agoravm login: ROOT LOGIN (root) ON ttyv0 epair0a: Ethernet address: 02:95:54:00:04:0a epair0b: Ethernet address: 02:95:54:00:05:0b epair0a: link state changed to UP epair0b: link state changed to UP Freed UMA keg was not empty (20 items). Lost 2 pages of memory. Freed UMA keg was not empty (168 items). Lost 1 pages of memory. Freed UMA keg was not empty (20 items). Lost 2 pages of memory. Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x11 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff81623012 stack pointer =3D 0x28:0xffffff80003cb540 frame pointer =3D 0x28:0xffffff80003cb550 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1311 (jail) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff80869cde at kdb_backtrace+0x5e #1 0xffffffff808345c7 at panic+0x187 #2 0xffffffff80b342b0 at trap_fatal+0x290 #3 0xffffffff80b345f9 at trap_pfault+0x1f9 #4 0xffffffff80b34abf at trap+0x3df #5 0xffffffff80b1efef at calltrap+0x8 #6 0xffffffff8162461e at pfi_cleanup+0x16e #7 0xffffffff816293c8 at vnet_pf_uninit+0x1b8 #8 0xffffffff80908f37 at vnet_sysuninit+0x47 #9 0xffffffff80909083 at vnet_destroy+0xe3 #10 0xffffffff8080f405 at prison_deref+0x145 #11 0xffffffff8080fcc1 at sys_jail_remove+0x311 #12 0xffffffff80b33ba0 at amd64_syscall+0x450 #13 0xffffffff80b1f2d7 at Xfast_syscall+0xf7 Uptime: 3m47s Dumping 83 out of 1005 MB:..20%..39%..58%..77%..96% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions DEBUG=3D-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options VIMAGE options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=3D128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=3D5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device epair device if_bridge device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device twe device tws device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device firewire device fwe device fwip device dcons device dcons_crom device sound device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist --MP_/d0cLc4djrluDlAu9NSIzsg4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=info.txt Dump header from device /dev/ada0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 87834624B (83 MB) Blocksize: 512 Dumptime: Fri Feb 3 12:15:05 2012 Hostname: agoravm Magic: FreeBSD Kernel Dump Version String: FreeBSD 9.0-RELEASE #0: Thu Feb 2 23:15:10 EST 2012 root@agoravm:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 491129092 Bounds: 0 Dump Status: good --MP_/d0cLc4djrluDlAu9NSIzsg4-- --Sig_/FKzu6zkx6lJy6FS/JmY+jC1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJPLBp/AAoJEKzcYuuXBo1s9e4QAJGmjJ1kitpDPM7xcXRpIU0C 6KW0bf+hLwjLGWKeCZ1zTYRnqpwppOnnO/Sm36dZSy/ejAJRNQj/XGUgE/Vpn7wM 9CurYr2TqA0zQEpQjWu1E0oMGEZR8phLZ6zjFat+lwTFulS0iNu9PSSyGGFRSWfw B3aGSkTYUfAFOQxPRXb10Ow/HVH3TaysFCB6NEscROLDeXdNdYubtFjkFh02f6ab p8wl0o0aoPChnJ3f5BZVjsSpKpBSEnwegJPw4dMIZ8ZlPa7/pLvLquv0ZdN9Nb4c NKjrSY/0L1ALZ25Ro4oF7enXFyR9a1+rFYdWDGozTotWDJ1hTEt2AN6kCS+NMdKv XAzFqLxL9kvHD6uHou3KvDoT4HQdL+4cDxtN2R/Zh22vYTQsyo2g8M0WrAT/VV6R Tmn6BjK/lTbTIR5RBjqpNW4KqM3xoovPgWux2jYug4R6Bbet4mM6pumgqtCD3PTd 2+xkO5wOPrch0dhBQoqddGujVUEQEA1EVWd0j0uQRWfZvWnX/x6Zivx1TScwTKwW bG/nz6BOMm8GROVawEIp3/zdwbY41e8bi9pg+8BnEnnDzhnVau8r2/VKs+vASeJo tzBRKg18WXdUs04DFH66UAlhtpkdPu+beGXneM0GOHShJdZVHtE/IebBrByvkRfA ZlExJZj+7p4s14bQtxVy =N1FV -----END PGP SIGNATURE----- --Sig_/FKzu6zkx6lJy6FS/JmY+jC1-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 3 23:59:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20B051065675 for ; Fri, 3 Feb 2012 23:59:55 +0000 (UTC) (envelope-from sureprofit@gmail.com) Received: from mail.eyes-e-tools.net (mail.eyes-e-tools.net [212.123.22.194]) by mx1.freebsd.org (Postfix) with ESMTP id AB4248FC18 for ; Fri, 3 Feb 2012 23:59:54 +0000 (UTC) Received: from smtp.axmatrix.be ([192.168.1.80]) by mail.eyes-e-tools.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 00:42:44 +0100 Received: from apoc ([192.168.1.235]) by smtp.axmatrix.be with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 00:42:44 +0100 MIME-Version: 1.0 From: "Eyes-e-tools.net namens Steven Rounds" To: freebsd-net@freebsd.org Date: 4 Feb 2012 00:42:44 +0100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 03 Feb 2012 23:42:44.0869 (UTC) FILETIME=[870A8B50:01CCE2CD] Subject: Interessante pagina op www.eyes-e-tools.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steven Rounds List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:59:55 -0000 Beste Friend,=0D=0A=0D=0ASteven Rounds doorbladerde www.eyes-e-tools.net= en vond informatie die u zou kunnen interesseren:=0D=0Ahttp://www.eyes-e-tools.net/site/= =0D=0A=0D=0ASteven Rounds zegt hierover:=0D=0ADear Friend, =0D=0A=0D=0A= =0D=0AFrom: Steven Rounds 'Ex PayPal Guy'=0D=0A=0D=0AEx Paypal Insider Creats= Underground Software =0D=0AThat FORCED Him To Profit.Up TO $35,000 A Month!= =0D=0A =0D=0AIm About To Show You How It Works.So Anyone,=0D=0AEven You= Can Make Money 3 Minutes Now.=0D=0A=0D=0AHERE'S PAYPAL CERTIFIED PROOF!= That's $5,311 =0D=0A$7,490 And $5,837 In Just 9 Days!=0D=0A=0D=0AThe Beauty= Is...The Software Works For You.=0D=0AYou're Not Glued To Your Computer= 24/7=0D=0A=0D=0AI Was Constanly Staring At Millions Of Dollars =0D=0AIn= Cash And None Of It Was Mine.=0D=0A=0D=0AImagine Your bank Account Always= Flush With =0D=0ACold Hard Cash..All Your Bills Are Paid On Time...=0D=0AAnd= The Fat Chunk Of Money In Your Bank Is Your'=0D=0As To Do With Whatever= You Please...=0D=0A=0D=0ABecause You Had The Only Software That Actually= =0D=0ABrings Money To You.To Live Your Dreams.=0D=0A=0D=0A=0D=0A=3D=3D>>= http://www.paygear.com/2584/sureprofit/=0D=0A=0D=0A=0D=0AI don't know you.= =0D=0A=0D=0AYou don't know me. Yet. But one thing you and I both =0D=0Aknow.= Somehow you found this page because you want out.=0D=0A=0D=0AOut of your= current financial situation.=0D=0A=0D=0AOut of living paycheck to paycheck.= =0D=0A=0D=0AOut of struggling to pay the bills.=0D=0A=0D=0AOut of the 9-5= grind.=0D=0A=0D=0AOut of long rush hour traffic.=0D=0A=0D=0AOut of your= job.=0D=0A=0D=0AOut of whatever is holding you back from making =0D=0Amore= money a month than 99.999999% of the =0D=0Arest of the world makes in a= year.=0D=0A=0D=0AYou're in luck if any of the above is YOU.=0D=0A=0D=0A= =0D=0A=3D=3D>> http://www.paygear.com/2584/sureprofit/=0D=0A=0D=0A=0D=0ABecause= you somehow just landed on the one single page =0D=0Aonline that has the= answer to all of those problems.=0D=0A=0D=0AI would know.=0D=0A=0D=0ABecause= I created the only software that actually forces =0D=0Ayou to profit in= world that doesn't involve gaming Google =0D=0Awith autobloggers or spinning= endless articles into a =0D=0Amassive web of worthless content that nobody= cares about.=0D=0A=0D=0A=0D=0AThis software taps into a little known but= ASTRONOMIC =0D=0Asource of traffic that only the most elite Super =0D=0AAffiliates= know about and literally makes you make money.=0D=0A=0D=0AHow much money?= =0D=0A=0D=0AIt's entirely up to you...=0D=0A=0D=0A=0D=0ASuccess,Steven Rounds= =0D=0A=0D=0A9547 colgate way, hamilton, OH 45011, USA =0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0AMet vriendelijke groeten,=0D=0A=0D=0AanaXis= =0D=0A=0D=0Ahttp://www.eyes-e-tools.net From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 00:58:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E941065670 for ; Sat, 4 Feb 2012 00:58:59 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id ED9258FC15 for ; Sat, 4 Feb 2012 00:58:58 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 00E6225D3870; Sat, 4 Feb 2012 00:58:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 38A74BD99E0; Sat, 4 Feb 2012 00:58:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id cKCm0uD9Ri57; Sat, 4 Feb 2012 00:58:56 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4D841BD99DE; Sat, 4 Feb 2012 00:58:56 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120203123346.7fad1800@poseidon> Date: Sat, 4 Feb 2012 00:58:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <713F3B68-EB54-412E-B199-4DDA9878011D@lists.zabbadoz.net> References: <20120203123346.7fad1800@poseidon> To: Alex X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic when destroying a jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 00:58:59 -0000 On 3. Feb 2012, at 17:33 , Alex wrote: > Hello. I have found that you can make a GENERIC 9.0-RELEASE kernel > crash if you kldload pf, create a jail, and then destroy it. See the > attached stack trace. Doesn't look like a GENERIC but a VIMAGE kernel to me and VIMAGE is = still considered experimental. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 09:48:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A67CB10656DA; Sat, 4 Feb 2012 09:48:58 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 109CD8FC14; Sat, 4 Feb 2012 09:48:57 +0000 (UTC) Received: by werm13 with SMTP id m13so5171323wer.13 for ; Sat, 04 Feb 2012 01:48:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Q9zRSELmeEBEJJ/YHjJjWLpQpWCp4lIPvvlPS/hRCf8=; b=S0I2xuTlem64eS8BOKichTeW+ImpmY8RWWoPn5cAzSOvYSTKdCjLF3YqDSj5syti0n SmP8zUE0/NwdIm7n9OhYCOUvLBwldA9mRaaKs+zMdb3ermsgQPv5VOb6t++GiiU4grTn dJQ0GhtTMDsspr4PK/++qsNsBXj0L9eF+xQ5Q= Received: by 10.216.133.12 with SMTP id p12mr4124428wei.49.1328347431731; Sat, 04 Feb 2012 01:23:51 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id j16sm25534715wie.4.2012.02.04.01.23.48 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 01:23:50 -0800 (PST) Message-ID: <4F2CF91B.8050604@gmail.com> Date: Sat, 04 Feb 2012 12:53:39 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Jack Vogel References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, lev@freebsd.org, Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 09:48:58 -0000 Dear Jack Is the problem related to link loss fixed in this version? The problem was that if if_snd fills up during a "link_active == 0" period, stack never calls em_start again, because em does not kick off tx when link becomes active again. On 1/29/2012 9:51 PM, Jack Vogel wrote: > No, I told Mike I'd get it into 8.x, have just been busy, but will try > and get it pushed up in the queue. > > Jack > > > 2012/1/29 Lev Serebryakov > >> Hello, Mike. >> You wrote 29 января 2012 г., 16:54:59: >> >>>> My home server lost connection on em0 this night again. It was >>>> persistent problem some times ago, but with version 7.2.3 it is first >>>> time, but with worse symptoms. >>> 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon >> :) >> I'm afraid, that "MFC'd" means "to 9-STABLE" now :( >> >> >> -- >> // Black Lion AKA Lev Serebryakov >> >> _______________________________________________ >> 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 Sat Feb 4 18:33:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D5EF106564A; Sat, 4 Feb 2012 18:33:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDCAC8FC17; Sat, 4 Feb 2012 18:33:34 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5338666wib.13 for ; Sat, 04 Feb 2012 10:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Z/R27c4kZgSeUhpoVH++OFVX7pw+ggmRtBB4xjse2I=; b=q8PinatOiiS0wgWwnLIqjzwryaeb4Mu9ck0Hm2dhe5wHpS0P1Ued/T8fgKMu5oN3GQ C7MKkLs5AsGkzRoKuXh6hHcwKP/s48v7hBJYRbC/w3Io7hovIC3IsK+x4XZk764km6yi Kom2/JUn/DK2fhcopl/LLOVKJfVd6g0XcbfBY= MIME-Version: 1.0 Received: by 10.180.7.231 with SMTP id m7mr5339846wia.3.1328380413753; Sat, 04 Feb 2012 10:33:33 -0800 (PST) Received: by 10.180.75.137 with HTTP; Sat, 4 Feb 2012 10:33:33 -0800 (PST) In-Reply-To: <4F2CF91B.8050604@gmail.com> References: <1076713525.20120129133839@serebryakov.spb.ru> <4F2541A3.8020401@sentex.net> <1146850915.20120129204328@serebryakov.spb.ru> <4F2CF91B.8050604@gmail.com> Date: Sat, 4 Feb 2012 10:33:33 -0800 Message-ID: From: Jack Vogel To: Hooman Fazaeli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, lev@freebsd.org, Mike Tancsa Subject: Re: em0 hangs on 8-STABLE again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 18:33:35 -0000 Am not positive, why don't you test it and see? Was there a change that had been proposed to fix this? Thanks, Jack On Sat, Feb 4, 2012 at 1:23 AM, Hooman Fazaeli wro= te: > Dear Jack > > Is the problem related to link loss fixed in this version? > The problem was that if if_snd fills up during a "link_active =3D=3D 0" > period, stack never calls em_start again, because em does not > kick off tx when link becomes active again. > > > > On 1/29/2012 9:51 PM, Jack Vogel wrote: > >> No, I told Mike I'd get it into 8.x, have just been busy, but will try >> and get it pushed up in the queue. >> >> Jack >> >> >> 2012/1/29 Lev Serebryakov >> >> Hello, Mike. >>> You wrote 29 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2012 =D0=B3., 16:54:5= 9: >>> >>> My home server lost connection on em0 this night again. It was >>>>> persistent problem some times ago, but with version 7.2.3 it is first >>>>> time, but with worse symptoms. >>>>> >>>> 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd so= on >>>> >>> :) >>> I'm afraid, that "MFC'd" means "to 9-STABLE" now :( >>> >>> >>> -- >>> // Black Lion AKA Lev Serebryakov >>> >>> ______________________________**_________________ >>> 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<= freebsd-net-unsubscribe@freebsd.org> >> " >> >> From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 19:22:03 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A69A1065673; Sat, 4 Feb 2012 19:22:03 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id D4DAD8FC15; Sat, 4 Feb 2012 19:22:01 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q14JLaHR007940; Sun, 5 Feb 2012 04:21:48 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q14JLWmj073958; Sun, 5 Feb 2012 04:21:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 05 Feb 2012 03:35:32 +0900 (JST) Message-Id: <20120205.033532.381149506660559829.hrs@allbsd.org> To: net@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Feb__5_03_35_32_2012_376)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sun, 05 Feb 2012 04:21:54 +0900 (JST) X-Spam-Status: No, score=-100.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, T_FRT_STOCK2, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: mark@mivok.net, sem@FreeBSD.org Subject: [CFT] multiple FIB support in route(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 19:22:03 -0000 ----Security_Multipart0(Sun_Feb__5_03_35_32_2012_376)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Feb__5_03_35_32_2012_925)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Feb__5_03_35_32_2012_925)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Can anyone review/test the attached patch to add "-fib number" option to route(8)? This should simplify static route configuration across multiple FIBs in rc.conf. Just adding an -fib option like the following will do the trick without changing rc.d/routing: static_routes="foo bar" route_foo="10.1.1.1/24 192.168.2.1 -fib 2" route_bar="10.1.1.1/24 192.168.2.1 -fib 3" The -fib option is supported in all subcommands but monitor. -- Hiroki ----Next_Part(Sun_Feb__5_03_35_32_2012_925)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="route-fib.20120205-1.diff" Index: sbin/route/route.c =================================================================== --- sbin/route/route.c (revision 230991) +++ sbin/route/route.c (working copy) @@ -99,6 +99,8 @@ struct rt_metrics rt_metrics; u_long rtm_inits; uid_t uid; +int fib; +int numfibs; static int atalk_aton(const char *, struct at_addr *); static char *atalk_ntoa(struct at_addr); @@ -123,6 +125,8 @@ static const char *routename(struct sockaddr *); static int rtmsg(int, int); static void set_metric(char *, int); +static void set_sofib(int); +static void set_procfib(int); static void sockaddr(char *, struct sockaddr *); static void sodump(sup, const char *); extern char *iso_ntoa(void); @@ -144,6 +148,7 @@ main(int argc, char **argv) { int ch; + size_t len; if (argc < 2) usage(NULL); @@ -180,6 +185,16 @@ s = socket(PF_ROUTE, SOCK_RAW, 0); if (s < 0) err(EX_OSERR, "socket"); + + len = sizeof(numfibs); + if (sysctlbyname("net.fibs", (void *)&numfibs, &len, NULL, 0) == -1) + numfibs = -1; + + len = sizeof(fib); + if (numfibs != -1 && + sysctlbyname("net.my_fibnum", (void *)&fib, &len, NULL, 0) == -1) + fib = -1; + if (*argv != NULL) switch (keyword(*argv)) { case K_GET: @@ -207,6 +222,31 @@ /* NOTREACHED */ } +static void +set_sofib(int f) +{ + int error; + + if (f > 0) { + error = setsockopt(s, SOL_SOCKET, SO_SETFIB, (void *)&f, + sizeof(f)); + if (error) + errx(EX_OSERR, "setsockopt(SO_SETFIB, %d) failed", f); + } +} + +static void +set_procfib(int f) +{ + int error; + + if (f > 0) { + error = setfib(f); + if (error) + errx(EX_OSERR, "setfib(%d) failed", f); + } +} + /* * Purge all entries in the routing tables not * associated with network interfaces. @@ -223,29 +263,39 @@ errx(EX_NOPERM, "must be root to alter routing table"); } shutdown(s, SHUT_RD); /* Don't want to read back our messages */ - if (argc > 1) { + while (argc > 1) { + argc--; argv++; - if (argc == 2 && **argv == '-') - switch (keyword(*argv + 1)) { - case K_INET: - af = AF_INET; - break; + if (**argv != '-') + usage(*argv); + switch (keyword(*argv + 1)) { + case K_INET: + af = AF_INET; + break; #ifdef INET6 - case K_INET6: - af = AF_INET6; - break; + case K_INET6: + af = AF_INET6; + break; #endif - case K_ATALK: - af = AF_APPLETALK; - break; - case K_LINK: - af = AF_LINK; - break; - default: - goto bad; - } else -bad: usage(*argv); + case K_ATALK: + af = AF_APPLETALK; + break; + case K_LINK: + af = AF_LINK; + break; + case K_FIB: + if (!--argc) + usage(*argv); + fib = strtol(*++argv, NULL, 0); + if (fib == 0 && errno == EINVAL) + usage(*argv); + break; + default: + usage(*argv); + } } + set_sofib(fib); + set_procfib(fib); retry: mib[0] = CTL_NET; mib[1] = PF_ROUTE; @@ -657,6 +707,13 @@ case K_NOSTICK: flags &= ~RTF_STICKY; break; + case K_FIB: + if (!--argc) + usage(NULL); + fib = strtol(*++argv, NULL, 0); + if (fib == 0 && errno == EINVAL) + usage(NULL); + break; case K_IFA: if (!--argc) usage(NULL); @@ -751,6 +808,7 @@ so_dst.sinarp.sin_other = SIN_PROXY; flags |= RTF_ANNOUNCE; } + set_sofib(fib); for (attempts = 1; ; attempts++) { errno = 0; if ((ret = rtmsg(*cmd, flags)) == 0) @@ -777,6 +835,9 @@ (void) printf(" (%s)", inet_ntoa(((struct sockaddr_in *)&route.rt_gateway)->sin_addr)); } + if (fib > 0) + printf(" fib %u", (unsigned int)fib); + if (ret == 0) { (void) printf("\n"); } else { @@ -1490,6 +1551,8 @@ } if (gate && rtm->rtm_flags & RTF_GATEWAY) (void)printf(" gateway: %s\n", routename(gate)); + if (fib > 0) + (void)printf(" fib: %u\n", (unsigned int)fib); if (ifp) (void)printf(" interface: %.*s\n", ifp->sdl_nlen, ifp->sdl_data); Index: sbin/route/route.8 =================================================================== --- sbin/route/route.8 (revision 230991) +++ sbin/route/route.8 (working copy) @@ -28,7 +28,7 @@ .\" @(#)route.8 8.3 (Berkeley) 3/19/94 .\" $FreeBSD$ .\" -.Dd October 2, 2005 +.Dd January 29, 2012 .Dt ROUTE 8 .Os .Sh NAME @@ -124,6 +124,7 @@ .Op Fl n .Cm flush .Op Ar family +.Op Fl fib Ar number .Ed .Pp If the @@ -140,6 +141,10 @@ .Fl inet modifiers, only routes having destinations with addresses in the delineated family will be deleted. +When an +.Fl fib +option is specified, the operation will be applied to +the specified FIB. .Pp The other commands have the following syntax: .Pp @@ -310,6 +315,21 @@ .Fl lockrest meta-modifier. .Pp +The optional modifier +.Fl fib Ar number +specifies the command will be applied to a different routing table. +The +.Ar number +must be smaller than the +.Va net.fibs +.Xr sysctl 8 +MIB. +When this modifier is not specified, +the default routing table shown in the +.Va net.my_fibnum +.Xr sysctl 8 +MIB will be used. +.Pp In a .Cm change or Index: sbin/route/keywords =================================================================== --- sbin/route/keywords (revision 230991) +++ sbin/route/keywords (working copy) @@ -10,6 +10,7 @@ delete dst expire +fib flush gateway genmask ----Next_Part(Sun_Feb__5_03_35_32_2012_925)---- ----Security_Multipart0(Sun_Feb__5_03_35_32_2012_376)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8tenQACgkQTyzT2CeTzy1cEgCcCsL7zB/6zDebaA5tC7n4ITb0 6vsAniV6vitNWcvn4zqMs7eYiJlhykXJ =lMQY -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Feb__5_03_35_32_2012_376)---- From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 19:56:03 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F6E1065673; Sat, 4 Feb 2012 19:56:03 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14F648FC08; Sat, 4 Feb 2012 19:56:02 +0000 (UTC) Received: by iaeo4 with SMTP id o4so9905706iae.13 for ; Sat, 04 Feb 2012 11:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=XNOMcm57BZC6zNjM+P/AvzDlQ3+Uq6dkodZpKJCl930=; b=GIN5Oz7nM0nNqLwr50RkBd7HSgiYR9o0buJ1r3Q8eMHufTP76rHdPDHn5jRgWs3Eds 6IVCGduX3Al0Cc4yDP2saNfhsNr6Mzzya1tcjWK0M0Rut/Q7DcPTfwgwqpKf5KIRmDZ6 F1M4DKq9M/yrNl1cludOCMeBbw1WCG5+xzXbo= Received: by 10.50.149.162 with SMTP id ub2mr2950665igb.1.1328383760124; Sat, 04 Feb 2012 11:29:20 -0800 (PST) Received: from DataIX.net (adsl-99-181-135-57.dsl.klmzmi.sbcglobal.net. [99.181.135.57]) by mx.google.com with ESMTPS id e17sm10957116ibe.0.2012.02.04.11.29.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 11:29:19 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q14JTFiV084645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Feb 2012 14:29:15 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q14JTFQZ084288; Sat, 4 Feb 2012 14:29:15 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sat, 4 Feb 2012 14:29:15 -0500 From: Jason Hellenthal To: Hiroki Sato Message-ID: <20120204192915.GA63412@DataIX.net> References: <20120205.033532.381149506660559829.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120205.033532.381149506660559829.hrs@allbsd.org> Cc: sem@freebsd.org, mark@mivok.net, net@freebsd.org Subject: Re: [CFT] multiple FIB support in route(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 19:56:03 -0000 On Sun, Feb 05, 2012 at 03:35:32AM +0900, Hiroki Sato wrote: > Hello, > > Can anyone review/test the attached patch to add "-fib number" option > to route(8)? This should simplify static route configuration across > multiple FIBs in rc.conf. Just adding an -fib option like the > following will do the trick without changing rc.d/routing: > > static_routes="foo bar" > route_foo="10.1.1.1/24 192.168.2.1 -fib 2" > route_bar="10.1.1.1/24 192.168.2.1 -fib 3" > > The -fib option is supported in all subcommands but monitor. > Awesome! I will give this a test ASAP. From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 20:02:57 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD87D106564A; Sat, 4 Feb 2012 20:02:57 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DADC8FC1B; Sat, 4 Feb 2012 20:02:57 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Rtlp6-000KwG-5X; Sun, 05 Feb 2012 00:03:00 +0400 Message-ID: <4F2DC674.4070401@FreeBSD.org> Date: Sat, 04 Feb 2012 23:59:48 +0000 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120205.033532.381149506660559829.hrs@allbsd.org> In-Reply-To: <20120205.033532.381149506660559829.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sem@FreeBSD.org, mark@mivok.net, net@FreeBSD.org Subject: Re: [CFT] multiple FIB support in route(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 20:02:57 -0000 On 04.02.2012 18:35, Hiroki Sato wrote: > Hello, > > Can anyone review/test the attached patch to add "-fib number" option > to route(8)? This should simplify static route configuration across > multiple FIBs in rc.conf. Just adding an -fib option like the > following will do the trick without changing rc.d/routing: > > static_routes="foo bar" > route_foo="10.1.1.1/24 192.168.2.1 -fib 2" > route_bar="10.1.1.1/24 192.168.2.1 -fib 3" > > The -fib option is supported in all subcommands but monitor. Why should we leave `monitor` as is? And, even if we really need to do so why "route monitor" silently accepts and ignores -fib X key? > > -- Hiroki From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 21:06:52 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C9E106564A; Sat, 4 Feb 2012 21:06:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 728188FC13; Sat, 4 Feb 2012 21:06:51 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q14L6QoA033178; Sun, 5 Feb 2012 06:06:37 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q14L6Mx1074669; Sun, 5 Feb 2012 06:06:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 05 Feb 2012 06:05:17 +0900 (JST) Message-Id: <20120205.060517.982494808613553569.hrs@allbsd.org> To: melifaro@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F2DC674.4070401@FreeBSD.org> References: <20120205.033532.381149506660559829.hrs@allbsd.org> <4F2DC674.4070401@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Feb__5_06_05_18_2012_027)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sun, 05 Feb 2012 06:06:44 +0900 (JST) X-Spam-Status: No, score=-100.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, T_FRT_STOCK2, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: sem@FreeBSD.org, mark@mivok.net, net@FreeBSD.org Subject: Re: [CFT] multiple FIB support in route(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 21:06:52 -0000 ----Security_Multipart0(Sun_Feb__5_06_05_18_2012_027)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Feb__5_06_05_17_2012_496)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Feb__5_06_05_17_2012_496)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Alexander V. Chernikov" wrote in <4F2DC674.4070401@FreeBSD.org>: me> On 04.02.2012 18:35, Hiroki Sato wrote: me> > Hello, me> > me> > Can anyone review/test the attached patch to add "-fib number" option me> > to route(8)? This should simplify static route configuration across me> > multiple FIBs in rc.conf. Just adding an -fib option like the me> > following will do the trick without changing rc.d/routing: me> > me> > static_routes="foo bar" me> > route_foo="10.1.1.1/24 192.168.2.1 -fib 2" me> > route_bar="10.1.1.1/24 192.168.2.1 -fib 3" me> > me> > The -fib option is supported in all subcommands but monitor. me> Why should we leave `monitor` as is? me> me> And, even if we really need to do so why "route monitor" silently me> accepts and ignores -fib X key? No specific reason. The monitor originally supports no flag to filter rt messages and silently ignores any flag. Is this a suggestion that it should support -fib or just from your curiosity? I do not think we really need to leave it. The attached patch is enough to support it, too. -- Hiroki ----Next_Part(Sun_Feb__5_06_05_17_2012_496)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="route-fib.20120205-2.diff" Index: sbin/route/route.c =================================================================== --- sbin/route/route.c (revision 230991) +++ sbin/route/route.c (working copy) @@ -99,6 +99,8 @@ struct rt_metrics rt_metrics; u_long rtm_inits; uid_t uid; +int fib; +int numfibs; static int atalk_aton(const char *, struct at_addr *); static char *atalk_ntoa(struct at_addr); @@ -112,7 +114,7 @@ #endif static void interfaces(void); static void mask_addr(void); -static void monitor(void); +static void monitor(int, char*[]); static const char *netname(struct sockaddr *); static void newroute(int, char **); static void pmsg_addrs(char *, int, size_t); @@ -123,6 +125,8 @@ static const char *routename(struct sockaddr *); static int rtmsg(int, int); static void set_metric(char *, int); +static void set_sofib(int); +static void set_procfib(int); static void sockaddr(char *, struct sockaddr *); static void sodump(sup, const char *); extern char *iso_ntoa(void); @@ -144,6 +148,7 @@ main(int argc, char **argv) { int ch; + size_t len; if (argc < 2) usage(NULL); @@ -180,6 +185,16 @@ s = socket(PF_ROUTE, SOCK_RAW, 0); if (s < 0) err(EX_OSERR, "socket"); + + len = sizeof(numfibs); + if (sysctlbyname("net.fibs", (void *)&numfibs, &len, NULL, 0) == -1) + numfibs = -1; + + len = sizeof(fib); + if (numfibs != -1 && + sysctlbyname("net.my_fibnum", (void *)&fib, &len, NULL, 0) == -1) + fib = -1; + if (*argv != NULL) switch (keyword(*argv)) { case K_GET: @@ -195,7 +210,7 @@ /* NOTREACHED */ case K_MONITOR: - monitor(); + monitor(argc, argv); /* NOTREACHED */ case K_FLUSH: @@ -207,6 +222,31 @@ /* NOTREACHED */ } +static void +set_sofib(int f) +{ + int error; + + if (f > 0) { + error = setsockopt(s, SOL_SOCKET, SO_SETFIB, (void *)&f, + sizeof(f)); + if (error) + errx(EX_OSERR, "setsockopt(SO_SETFIB, %d) failed", f); + } +} + +static void +set_procfib(int f) +{ + int error; + + if (f > 0) { + error = setfib(f); + if (error) + errx(EX_OSERR, "setfib(%d) failed", f); + } +} + /* * Purge all entries in the routing tables not * associated with network interfaces. @@ -223,29 +263,39 @@ errx(EX_NOPERM, "must be root to alter routing table"); } shutdown(s, SHUT_RD); /* Don't want to read back our messages */ - if (argc > 1) { + while (argc > 1) { + argc--; argv++; - if (argc == 2 && **argv == '-') - switch (keyword(*argv + 1)) { - case K_INET: - af = AF_INET; - break; + if (**argv != '-') + usage(*argv); + switch (keyword(*argv + 1)) { + case K_INET: + af = AF_INET; + break; #ifdef INET6 - case K_INET6: - af = AF_INET6; - break; + case K_INET6: + af = AF_INET6; + break; #endif - case K_ATALK: - af = AF_APPLETALK; - break; - case K_LINK: - af = AF_LINK; - break; - default: - goto bad; - } else -bad: usage(*argv); + case K_ATALK: + af = AF_APPLETALK; + break; + case K_LINK: + af = AF_LINK; + break; + case K_FIB: + if (!--argc) + usage(*argv); + fib = strtol(*++argv, NULL, 0); + if (fib == 0 && errno == EINVAL) + usage(*argv); + break; + default: + usage(*argv); + } } + set_sofib(fib); + set_procfib(-1); retry: mib[0] = CTL_NET; mib[1] = PF_ROUTE; @@ -657,6 +707,13 @@ case K_NOSTICK: flags &= ~RTF_STICKY; break; + case K_FIB: + if (!--argc) + usage(NULL); + fib = strtol(*++argv, NULL, 0); + if (fib == 0 && errno == EINVAL) + usage(NULL); + break; case K_IFA: if (!--argc) usage(NULL); @@ -751,6 +808,7 @@ so_dst.sinarp.sin_other = SIN_PROXY; flags |= RTF_ANNOUNCE; } + set_sofib(fib); for (attempts = 1; ; attempts++) { errno = 0; if ((ret = rtmsg(*cmd, flags)) == 0) @@ -777,6 +835,9 @@ (void) printf(" (%s)", inet_ntoa(((struct sockaddr_in *)&route.rt_gateway)->sin_addr)); } + if (fib > 0) + printf(" fib %u", (unsigned int)fib); + if (ret == 0) { (void) printf("\n"); } else { @@ -1165,11 +1226,30 @@ } static void -monitor(void) +monitor(int argc, char *argv[]) { int n; char msg[2048]; + while (argc > 1) { + argc--; + argv++; + if (**argv != '-') + usage(*argv); + switch (keyword(*argv + 1)) { + case K_FIB: + if (!--argc) + usage(*argv); + fib = strtol(*++argv, NULL, 0); + if (fib == 0 && errno == EINVAL) + usage(*argv); + break; + default: + usage(*argv); + } + } + set_sofib(fib); + verbose = 1; if (debugonly) { interfaces(); @@ -1490,6 +1570,8 @@ } if (gate && rtm->rtm_flags & RTF_GATEWAY) (void)printf(" gateway: %s\n", routename(gate)); + if (fib > 0) + (void)printf(" fib: %u\n", (unsigned int)fib); if (ifp) (void)printf(" interface: %.*s\n", ifp->sdl_nlen, ifp->sdl_data); Index: sbin/route/route.8 =================================================================== --- sbin/route/route.8 (revision 230991) +++ sbin/route/route.8 (working copy) @@ -28,7 +28,7 @@ .\" @(#)route.8 8.3 (Berkeley) 3/19/94 .\" $FreeBSD$ .\" -.Dd October 2, 2005 +.Dd January 29, 2012 .Dt ROUTE 8 .Os .Sh NAME @@ -124,6 +124,7 @@ .Op Fl n .Cm flush .Op Ar family +.Op Fl fib Ar number .Ed .Pp If the @@ -140,6 +141,10 @@ .Fl inet modifiers, only routes having destinations with addresses in the delineated family will be deleted. +When an +.Fl fib +option is specified, the operation will be applied to +the specified FIB. .Pp The other commands have the following syntax: .Pp @@ -310,6 +315,21 @@ .Fl lockrest meta-modifier. .Pp +The optional modifier +.Fl fib Ar number +specifies the command will be applied to a different routing table. +The +.Ar number +must be smaller than the +.Va net.fibs +.Xr sysctl 8 +MIB. +When this modifier is not specified, +the default routing table shown in the +.Va net.my_fibnum +.Xr sysctl 8 +MIB will be used. +.Pp In a .Cm change or Index: sbin/route/keywords =================================================================== --- sbin/route/keywords (revision 230991) +++ sbin/route/keywords (working copy) @@ -10,6 +10,7 @@ delete dst expire +fib flush gateway genmask ----Next_Part(Sun_Feb__5_06_05_17_2012_496)---- ----Security_Multipart0(Sun_Feb__5_06_05_18_2012_027)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8tnY4ACgkQTyzT2CeTzy1GTQCfco2WYvfhzDCl4UyD/4wf4kED XAsAoMQgLFJ/tsNDb6VbAtJw6zOWmXae =V5E/ -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Feb__5_06_05_18_2012_027)---- From owner-freebsd-net@FreeBSD.ORG Sat Feb 4 21:25:00 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18327106566B; Sat, 4 Feb 2012 21:25:00 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id A31678FC16; Sat, 4 Feb 2012 21:24:59 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Rtn6U-000LNu-DC; Sun, 05 Feb 2012 01:25:02 +0400 Message-ID: <4F2DD9AE.7040805@FreeBSD.org> Date: Sun, 05 Feb 2012 01:21:50 +0000 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120205.033532.381149506660559829.hrs@allbsd.org> <4F2DC674.4070401@FreeBSD.org> <20120205.060517.982494808613553569.hrs@allbsd.org> In-Reply-To: <20120205.060517.982494808613553569.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sem@FreeBSD.org, mark@mivok.net, net@FreeBSD.org Subject: Re: [CFT] multiple FIB support in route(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Feb 2012 21:25:00 -0000 On 04.02.2012 21:05, Hiroki Sato wrote: > "Alexander V. Chernikov" wrote > in<4F2DC674.4070401@FreeBSD.org>: > > me> On 04.02.2012 18:35, Hiroki Sato wrote: > me> > Hello, > me> > > me> > Can anyone review/test the attached patch to add "-fib number" option > me> > to route(8)? This should simplify static route configuration across > me> > multiple FIBs in rc.conf. Just adding an -fib option like the > me> > following will do the trick without changing rc.d/routing: > me> > > me> > static_routes="foo bar" > me> > route_foo="10.1.1.1/24 192.168.2.1 -fib 2" > me> > route_bar="10.1.1.1/24 192.168.2.1 -fib 3" > me> > > me> > The -fib option is supported in all subcommands but monitor. > me> Why should we leave `monitor` as is? > me> > me> And, even if we really need to do so why "route monitor" silently > me> accepts and ignores -fib X key? > > No specific reason. The monitor originally supports no flag to > filter rt messages and silently ignores any flag. `setfib 5 route monitor` listening to fib 5 vs `route monitor -fib 5` listening to fib 0 is obviously not expected behavior :) > > Is this a suggestion that it should support -fib or just from your There is no reason to leave it inconsistent with other route subcommands. Route monitor is useful in various debugging related to dynamic routing software (and it should be fib-aware). > curiosity? I do not think we really need to leave it. The attached > patch is enough to support it, too. Thanks. Btw, I've tested patch from previous email on my 8-S box, it works correctly. > > -- Hiroki