From owner-freebsd-net@FreeBSD.ORG Sun Feb 4 17:04:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA63616A401 for ; Sun, 4 Feb 2007 17:04:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9104513C46B for ; Sun, 4 Feb 2007 17:04:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id F19481A8ED4; Sun, 4 Feb 2007 12:04:56 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sun, 04 Feb 2007 12:04:57 -0500 X-Sasl-enc: QEwVk60Sf32AwiH8hJ3uddKId3g6Fn8CgbSL877WjP2c 1170608696 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5C29A10B96; Sun, 4 Feb 2007 12:04:56 -0500 (EST) Message-ID: <45C61237.3030406@FreeBSD.org> Date: Sun, 04 Feb 2007 17:04:55 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <45C3DDC8.6070109@FreeBSD.org> In-Reply-To: <45C3DDC8.6070109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Landon Fuller Subject: Re: [patch] tun(4) and tap(4) if_clone support. 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, 04 Feb 2007 17:04:57 -0000 This patch has now been committed to -CURRENT. A conservative MFC schedule of at least 1 month is suggested. Devfs cloning remains enabled by default as it breaks ppp, ssh, and many ports. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sun Feb 4 18:16:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E963A16A401 for ; Sun, 4 Feb 2007 18:16:08 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.freebsd.org (Postfix) with ESMTP id A56E613C481 for ; Sun, 4 Feb 2007 18:16:08 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id 96E9292FD29; Sun, 4 Feb 2007 18:54:25 +0100 (CET) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 74043-04; Sun, 4 Feb 2007 18:54:24 +0100 (CET) Received: from [10.0.2.125] (evilcoder.xs4all.nl [195.64.94.120]) (Authenticated sender: remko@evilcoder.org) by caelis.elvandar.org (Postfix) with ESMTP id 9C35892FCF8; Sun, 4 Feb 2007 18:54:23 +0100 (CET) Message-ID: <45C61E40.2000005@FreeBSD.org> Date: Sun, 04 Feb 2007 18:56:16 +0100 From: Remko Lodder User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 at elvandar.org Cc: freebsd-net@freebsd.org Subject: Re: SIMPLEX network device? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@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, 04 Feb 2007 18:16:09 -0000 Ivan Voras wrote: > I've noticed in ifconfig report for a gigabit NIC based on Realtek 8169S > chip that it has the SIMPLEX flag set. What does it mean in practice, > considering the media type is (correctly) autonegotiated for 1000baseTX > full-duplex? > Hello, One of the first hits on google showed: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=719227&admit=-682735245+1170611618963+28353475 //Remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 10:22:53 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BEE916A411 for ; Mon, 5 Feb 2007 10:22:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E965513C4A6 for ; Mon, 5 Feb 2007 10:22:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E79771A8C7A for ; Mon, 5 Feb 2007 05:22:47 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 05 Feb 2007 05:22:47 -0500 X-Sasl-enc: w1q35VBLqG4RQsumkRgvhNysrYOrZ9Vram2pucWVOOs/ 1170670967 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2FCF919D86; Mon, 5 Feb 2007 05:22:47 -0500 (EST) Message-ID: <45C70576.3010502@FreeBSD.org> Date: Mon, 05 Feb 2007 10:22:46 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Bruce M Simpson References: <45C428D7.20900@incunabulum.net> In-Reply-To: <45C428D7.20900@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: [PATCH] ip_fastfwd forwards directed broadcasts 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, 05 Feb 2007 10:22:53 -0000 This has now been applied to -CURRENT after testing by a 3rd party. From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 11:11:41 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D33E16A402 for ; Mon, 5 Feb 2007 11:11:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id EAFDE13C4A6 for ; Mon, 5 Feb 2007 11:11:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l15BBeS9026038 for ; Mon, 5 Feb 2007 11:11:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l15BBdvk026034 for freebsd-net@FreeBSD.org; Mon, 5 Feb 2007 11:11:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Feb 2007 11:11:39 GMT Message-Id: <200702051111.l15BBdvk026034@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 05 Feb 2007 11:11:41 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/106999 net [netgraph] [patch] ng_ksocket fails to clear multicast 10 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 14:05:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B88CE16A402 for ; Mon, 5 Feb 2007 14:05:58 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id D05D513C48D for ; Mon, 5 Feb 2007 14:05:57 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 33520 invoked by uid 1008); 5 Feb 2007 13:38:33 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7-unknown (2006-10-05) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.1.7-unknown Received: from unknown (HELO ?10.0.0.1?) (daniel@dgnetwork.com.br@200.243.216.36) by mail.mastercabo.com.br with SMTP; 5 Feb 2007 13:38:28 -0000 Message-ID: <45C73377.8040502@dgnetwork.com.br> Date: Mon, 05 Feb 2007 11:39:03 -0200 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Nat Log X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 14:06:00 -0000 It is possible to record logs of all connections nated with the PF? Already tried to use "nat log on...", without success. Thanks. -- Daniel Dias Gonçalves DGNET Network Solutions daniel@dgnetwork.com.br http://www.dgnetwork.com.br/ +55 37-99824809 +55 37-32421109 From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 14:59:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D62116A402 for ; Mon, 5 Feb 2007 14:59:23 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.149.33.74]) by mx1.freebsd.org (Postfix) with ESMTP id E8B9E13C467 for ; Mon, 5 Feb 2007 14:59:22 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id 0B401544BE; Mon, 5 Feb 2007 14:40:59 +0000 (GMT) From: "Greg Hennessy" To: , , References: <45C73377.8040502@dgnetwork.com.br> In-Reply-To: <45C73377.8040502@dgnetwork.com.br> Date: Mon, 5 Feb 2007 14:40:47 -0000 Message-ID: <000001c74933$9fea4a40$dfbedec0$@Hennessy@nviz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcdJMopAwZfcDT9JSZm4nNLOlXy5gAAAJsXQ Content-Language: en-gb x-cr-hashedpuzzle: AbOK A9mZ F0JU Gt79 I2Og Ka6W PZqh R+gw TNpV UdfG VPuZ VZ2D YRje aeeD bkRv c74z; 3; ZABhAG4AaQBlAGwAQABkAGcAbgBlAHQAdwBvAHIAawAuAGMAbwBtAC4AYgByADsAZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnADsAZgByAGUAZQBiAHMAZAAtAHAAZgBAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA=; Sosha1_v1; 7; {2A5DDBD9-4FF6-46C5-AACD-04E3E54906F7}; ZwByAGUAZwAuAGgAZQBuAG4AZQBzAHMAeQBAAG4AdgBpAHoALgBuAGUAdAA=; Mon, 05 Feb 2007 14:40:40 GMT; UgBFADoAIABOAGEAdAAgAEwAbwBnAA== x-cr-puzzleid: {2A5DDBD9-4FF6-46C5-AACD-04E3E54906F7} Cc: Subject: RE: Nat Log 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, 05 Feb 2007 14:59:23 -0000 > > It is possible to record logs of all connections nated with the PF? > Already tried to use "nat log on...", without success. > The version of PF used in FreeBSD (OpenBSD rev 3.7 I believe) doesn't have the log option for either nat pass or rdr pass. That facility came in later versions of PF. Greg From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 15:27:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12ED516A406 for ; Mon, 5 Feb 2007 15:27:57 +0000 (UTC) (envelope-from karol.kwiat@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 76C4913C494 for ; Mon, 5 Feb 2007 15:27:56 +0000 (UTC) (envelope-from karol.kwiat@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1270208uge for ; Mon, 05 Feb 2007 07:27:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type; b=HmwX/A39RAATmUZ7XLHst+2tjjradWNtBPFMx3+P5/SuKM+HSPaWty6eMY4WUGCujTOijYOKGCa07w1zjMpNvvU3FUoZcngmCMst2Z1Y5g5iESiPW6lkd9lOrY8Szg3bl6w2xnbofa7jQQGiSVX3fIF4Dkzj2hp81M2wUTi3Zko= Received: by 10.67.26.7 with SMTP id d7mr2841154ugj.1170687670449; Mon, 05 Feb 2007 07:01:10 -0800 (PST) Received: from blackacidevil.orchid.homeunix.org ( [83.27.44.12]) by mx.google.com with ESMTP id o24sm10476328ugd.2007.02.05.07.01.08; Mon, 05 Feb 2007 07:01:09 -0800 (PST) Message-ID: <45C746A6.7090300@gmail.com> Date: Mon, 05 Feb 2007 16:00:54 +0100 From: Karol Kwiatkowski User-Agent: Thunderbird 2.0b2 (X11/20070130) MIME-Version: 1.0 To: Konrad Heuer References: <20070205115123.L90859@gwdu114.gwdg.de> In-Reply-To: <20070205115123.L90859@gwdu114.gwdg.de> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=06E09309; url=http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7849A6C555A2B47B71658A5E" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: tcp_fin_timeout analogon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: karol.kwiat@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 15:27:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7849A6C555A2B47B71658A5E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Konrad Heuer wrote: >=20 > Hello everyone, >=20 > is there an analogon to the Linux sysctl variable "tcp_fin_timeout" in > FreeBSD to force the system to close still open TCP connections after > some time? >=20 > Any hint would be great. If I understand correctly, 'tcp_fin_timeout' on Linux sets timeout on a connection in FIN_WAIT_2 state. You could do that with pf(4) and it's 'set timeout tcp.closing' option. I'm not sure if it's possible with sysctl, cc'ing @freebsd-net. HTH, Karol > Best regards >=20 > Konrad Heuer --=20 Karol Kwiatkowski OpenPGP 0x06E09309 --------------enig7849A6C555A2B47B71658A5E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFx0atezeoPAwGIYsRCH9eAKCDekvIhuqKzA14di+6xOtdgMG8tACeMAQj nL6ohSJjJ0f5NNUYyA3Kb/M= =SE2q -----END PGP SIGNATURE----- --------------enig7849A6C555A2B47B71658A5E-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 21:01:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B28A916A4A7 for ; Mon, 5 Feb 2007 21:01:45 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 7B32F13C508 for ; Mon, 5 Feb 2007 21:01:45 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1034821ana for ; Mon, 05 Feb 2007 13:01:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QYe/l8TKf8CCNlG8P3fz9WSS+yTPwI+cMdEomOgOH+S2IhcN0hXsduAqHKusxXSp+7/p0ED6Zv0mD8WGvuaZbzoIbH53ul0Hd7VY1I2Qzd0G2Hw9IX/BKink1nW6pA5VJ5QAyuZI8rCJoRB2ZWM7YU9YwgOZ8kz7QhHDl7fTHyg= Received: by 10.114.175.16 with SMTP id x16mr672620wae.1170707590813; Mon, 05 Feb 2007 12:33:10 -0800 (PST) Received: by 10.114.12.1 with HTTP; Mon, 5 Feb 2007 12:33:01 -0800 (PST) Message-ID: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> Date: Mon, 5 Feb 2007 21:33:01 +0100 From: "Jouke Witteveen" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ioctl: SIOCADDMULTI (howto?) 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, 05 Feb 2007 21:01:46 -0000 Hello all, I'm in need of some information on how to utilize SIOCADDMULTI. It is supposed to be demonstrated by the mtest [1] program, but that doesn't do anything (on an SIOCDELMULTI rn it appears nothing was added: ENOENT), At least not for the values I tested, 1.80.c2.0.0.1 in particular. I presume it doesn't work because the program has not been revised in 3 years and revision 1.4 notes that it might not work. If this ioctl is depricated then please tell me what is the best way to receive multicast messages from the 01.80.c2.00.00.0x (802.1) range? It is ofcourse possible to go into ALLMULTI-mode and check on all datagrams, but the NIC's I use are suited with a very nice hardware filter (21143 chip) that should be able to do this more effectively. Anyway, I believe Linux still programs the hardware filter through SIOCADDMULTI so is a bit easier on this. I tracked down the source from the ioctl call to the network driver for some time now and could find no obvious fault, except for quite much casting, and inconsistent use of types (checks happen on all sorts of casts: socket, sokcet_dl, multiaddr, ...). Thanks in advance. Regards, - Jouke [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/mtest/ From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 21:06:51 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0997416A412 for ; Mon, 5 Feb 2007 21:06:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id BB90713C4B5 for ; Mon, 5 Feb 2007 21:06:48 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E1D2D1A9174 for ; Mon, 5 Feb 2007 16:06:47 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 05 Feb 2007 16:06:47 -0500 X-Sasl-enc: mi4QKTaBNjO6n1k2mJK3Pi78rMfcwk64CJxBZq6pZU/3 1170709607 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 92B48B958 for ; Mon, 5 Feb 2007 16:06:46 -0500 (EST) Message-ID: <45C79C65.8080605@incunabulum.net> Date: Mon, 05 Feb 2007 21:06:45 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Seeking to hear from people with broken IFF_ALLMULTI cards 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, 05 Feb 2007 21:06:51 -0000 Hi, If any of you out there have network interfaces which have broken ALLMULTI handling (i.e. they can't handle multicast routing), I would love to hear from you. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 21:30:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD74E16A56B for ; Mon, 5 Feb 2007 21:30:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC2313C4A6 for ; Mon, 5 Feb 2007 21:30:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 4437BAEE0B; Mon, 5 Feb 2007 16:30:35 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 05 Feb 2007 16:30:35 -0500 X-Sasl-enc: jJbDASUmjDhFjrFirrYtuhk12Qktb/5tI4Or6rsKnyXk 1170711034 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A4F9310E25; Mon, 5 Feb 2007 16:30:34 -0500 (EST) Message-ID: <45C7A1F9.20306@FreeBSD.org> Date: Mon, 05 Feb 2007 21:30:33 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Jouke Witteveen References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> In-Reply-To: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ioctl: SIOCADDMULTI (howto?) 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, 05 Feb 2007 21:30:40 -0000 Jouke Witteveen wrote: > Hello all, > > I'm in need of some information on how to utilize SIOCADDMULTI. It is > supposed to be demonstrated by the mtest [1] program, but that doesn't > do anything (on an SIOCDELMULTI rn it appears nothing was added: > ENOENT), At least not for the values I tested, 1.80.c2.0.0.1 in > particular. I presume it doesn't work because the program has not been > revised in 3 years and revision 1.4 notes that it might not work. > If this ioctl is depricated then please tell me what is the best way > to receive multicast messages from the 01.80.c2.00.00.0x (802.1) > range? It is ofcourse possible to go into ALLMULTI-mode and check on > all datagrams, but the NIC's I use are suited with a very nice > hardware filter (21143 chip) that should be able to do this more > effectively. Anyway, I believe Linux still programs the hardware > filter through SIOCADDMULTI so is a bit easier on this. > I tracked down the source from the ioctl call to the network driver > for some time now and could find no obvious fault, except for quite > much casting, and inconsistent use of types (checks happen on all > sorts of casts: socket, sokcet_dl, multiaddr, ...). It's quite possible that path is broken, as hardly anyone else out there needs to directly join a link-layer multicast group, and there is no regression test for it. The IP paths are known to work A-OK. If you didn't have code hooked up to ether_demux() to see this traffic, you'd never see it in userland anyway. As such, it's not a priority for me to fix , but will try to help anyway. Are there specific performance constraints for your app? If not you should just be able to use pcap (or bpf) to get the traffic. Admittedly this is a performance hit, but with the optimization work on bpf and ever more powerful CPUs, this shouldn't be a big issue. You can write a regression test for this though with getifmaddrs(). anglepoise:~/head/src/sys/net % s mtest Password: multicast membership test program; enter ? for list of commands a fxp0 01.80.c2.00.00.02 ether address added should yield route -nv monitor output got message of size 128 on Mon Feb 5 21:23:57 2007 RTM_NEWMADDR: new multicast group membership on iface: len 128, sockaddrs: fxp0:0.90.27.59.40.2c 1.80.c2.0.0.2 Of course, netstat -g won't show you this, because it's concerned with IP/IPv6 only. netstat -ian should however tell you which link-layer multicast addresses are configured. When I add an ethernet multicast address manually with mtest, I see vmstat -m | grep ether_multi increment as I'd expect. It looks like there may be a missing piece somewhere. The code which I see is OK but the results aren't as I'd expect. I am quite tired at the moment so I may be way off. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Feb 5 23:42:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E098E16A400 for ; Mon, 5 Feb 2007 23:42:47 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id B4C2E13C467 for ; Mon, 5 Feb 2007 23:42:46 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l15NS0VL047367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Feb 2007 02:28:00 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l15NS0UR047366; Tue, 6 Feb 2007 02:28:00 +0300 (MSK) (envelope-from oleg) Date: Tue, 6 Feb 2007 02:28:00 +0300 From: Oleg Bulyzhin To: Robin Gruyters Message-ID: <20070205232800.GA45487@lath.rinet.ru> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 05 Feb 2007 23:42:48 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 25, 2007 at 05:05:32PM +0100, Robin Gruyters wrote: > On 13-Jan-2007 Oleg Bulyzhin wrote: > > > >> Could you please test attached patch? It should fix ierrs issue > >and should not > >> break link events (would be fine to test it: unplug/plug cable, > >try to change > >> media with ifconfig, change media on other end of wire). > >> > Hi ya, > > Just wondering will this patch/update be available for RELENG_6? I > have the same problems here with 3 of our servers. > > Here is dmesg from our development server: > > [...] > Copyright (c) 1992-2007 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 6.2-RELEASE #1: Mon Jan 15 15:34:19 CET 2007 > root@server.yirdis.net:/data/obj/data/src_6_2/sys/YIRDIS > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 > > Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20000000 > Logical CPUs per core: 2 > real memory = 2147430400 (2047 MB) > avail memory = 2100547584 (2003 MB) > ACPI APIC Table: > Security auditing service present > BSM auditing present > ioapic1: Changing APIC ID to 9 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > ioapic3 irqs 72-95 on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 > cpu0: on acpi0 > pcib0: on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci13: on pcib1 > pcib2: at device 4.0 on pci0 > pci6: on pcib2 > pcib3: at device 0.0 on pci6 > pci7: on pcib3 > pcib4: at device 0.2 on pci6 > pci10: on pcib4 > pcib5: at device 1.0 on pci10 > pci11: on pcib5 > ste0: port 0x5000-0x507f irq 72 at > device 4.0 on pci11 > miibus0: on ste0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ste0: Ethernet address: 00:0d:88:fc:c8:cc > ste1: port 0x5080-0x50ff irq 73 at > device 5.0 on pci11 > miibus1: on ste1 > ukphy1: on miibus1 > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ste1: Ethernet address: 00:0d:88:fc:c8:cd > ste2: port 0x5400-0x547f irq 74 at > device 6.0 on pci11 > miibus2: on ste2 > ukphy2: on miibus2 > ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ste2: Ethernet address: 00:0d:88:fc:c8:ce > ste3: port 0x5480-0x54ff irq 75 at > device 7.0 on pci11 > miibus3: on ste3 > ukphy3: on miibus3 > ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ste3: Ethernet address: 00:0d:88:fc:c8:cf > pcib6: at device 6.0 on pci0 > pci3: on pcib6 > pcib7: at device 28.0 on pci0 > pci2: on pcib7 > ciss0: port 0x4000-0x40ff mem > 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 24 at device 1.0 on pci2 > ciss0: [GIANT-LOCKED] > bge0: mem > 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > miibus4: on bge0 > brgphy0: on miibus4 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:12:79:94:ed:12 > bge1: mem > 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > miibus5: on bge1 > brgphy1: on miibus5 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:12:79:94:ed:11 > pci0: at device 29.0 (no driver attached) > pci0: at device 29.1 (no driver attached) > pci0: at device 29.4 (no driver attached) > pci0: at device 29.5 (no > driver attached) > pci0: at device 29.7 (no driver attached) > pcib8: at device 30.0 on pci0 > pci1: on pcib8 > pci1: at device 3.0 (no driver attached) > pci1: at device 4.0 (no driver attached) > pci1: at device 4.2 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 18 at device 31.1 > on pci0 > ata0: on atapci0 > ata1: on atapci0 > acpi_tz0: 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 > sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 3000124702 Hz quality 800 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master PIO4 > da0 at ciss0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-0 device > da0: 135.168MB/s transfers > da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) > Trying to mount root from ufs:/dev/da0s1a > Accounting enabled > [...] > > And here the netstat interface statistics: > [...] > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > ste0* 1500 00:0d:88:fc:c8:cc 0 0 0 > 0 0 > ste1* 1500 00:0d:88:fc:c8:cd 0 0 0 > 0 0 > ste2* 1500 00:0d:88:fc:c8:ce 0 0 0 > 0 0 > ste3* 1500 00:0d:88:fc:c8:cf 0 0 0 > 0 0 > bge0 1500 00:12:79:94:ed:12 11343768 2114510 20564242 > 0 0 > bge1* 1500 00:12:79:94:ed:11 0 0 0 > 0 0 > pflog 33208 0 0 0 > 0 0 > lo0 16384 60221421 0 60221421 > 0 0 > [...] > > If you have a patch for FreeBSD 6.2, i'm quite happily to test it on > our development server. > > Regards, > > Robin Gruyters > Sorry for the late reply - i was AFK for some time and didnt read mails. Patch against 6.2R attached, please let me know does it helps or not. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_link.r62.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.36.2.8.2.1 diff -u -r1.36.2.8.2.1 if_bgereg.h --- sys/dev/bge/if_bgereg.h 21 Dec 2006 21:53:54 -0000 1.36.2.8.2.1 +++ sys/dev/bge/if_bgereg.h 5 Feb 2007 23:23:22 -0000 @@ -2460,8 +2460,13 @@ uint32_t bge_tx_buf_ratio; int bge_if_flags; int bge_txcnt; - int bge_link; /* link state */ - int bge_link_evt; /* pending link event */ + uint32_t bge_sts; +#define BGE_STS_LINK 0x00000001 /* MAC link status */ +#define BGE_STS_LINK_EVT 0x00000002 /* pending link event */ +#define BGE_STS_AUTOPOLL 0x00000004 /* PHY auto-polling */ +#define BGE_STS_BIT(sc, x) ((sc)->bge_sts & (x)) +#define BGE_STS_SETBIT(sc, x) ((sc)->bge_sts |= (x)) +#define BGE_STS_CLRBIT(sc, x) ((sc)->bge_sts &= ~(x)) struct callout bge_stat_ch; char *bge_vpd_prodname; char *bge_vpd_readonly; Index: sys/dev/bge/if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.91.2.18.2.1 diff -u -r1.91.2.18.2.1 if_bge.c --- sys/dev/bge/if_bge.c 21 Dec 2006 21:53:54 -0000 1.91.2.18.2.1 +++ sys/dev/bge/if_bge.c 5 Feb 2007 23:23:29 -0000 @@ -602,6 +602,7 @@ /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_CLRBIT(sc, BGE_STS_AUTOPOLL); BGE_CLRBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -615,6 +616,7 @@ } if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -1456,6 +1458,7 @@ if (sc->bge_tbi) { CSR_WRITE_4(sc, BGE_MI_STS, BGE_MISTS_LINK); } else { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL|10<<16); if (sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) @@ -2645,12 +2648,12 @@ /* Note link event. It will be processed by POLL_AND_CHECK_STATUS cmd */ if (statusword & BGE_STATFLAG_LINKSTATE_CHANGED) - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); if (cmd == POLL_AND_CHECK_STATUS) if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - sc->bge_link_evt || sc->bge_tbi) + BGE_STS_BIT(sc, BGE_STS_LINK_EVT) || sc->bge_tbi) bge_link_upd(sc); sc->rxcycles = count; @@ -2699,7 +2702,7 @@ if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - statusword || sc->bge_link_evt) + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) bge_link_upd(sc); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { @@ -2733,8 +2736,10 @@ bge_stats_update(sc); if (!sc->bge_tbi) { - mii = device_get_softc(sc->bge_miibus); - mii_tick(mii); + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + mii = device_get_softc(sc->bge_miibus); + mii_tick(mii); + } } else { /* * Since in TBI mode auto-polling can't be used we should poll @@ -2746,7 +2751,7 @@ if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING)) #endif { - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); } } @@ -2988,7 +2993,7 @@ sc = ifp->if_softc; - if (!sc->bge_link || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + if (!BGE_STS_BIT(sc, BGE_STS_LINK) || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) return; prodidx = sc->bge_tx_prodidx; @@ -3264,7 +3269,7 @@ return (0); } - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); mii = device_get_softc(sc->bge_miibus); if (mii->mii_instance) { struct mii_softc *miisc; @@ -3563,9 +3568,9 @@ * lead to hardware deadlock. So we just clearing MAC's link state * (PHY may still have link UP). */ - if (bootverbose && sc->bge_link) + if (bootverbose && BGE_STS_BIT(sc, BGE_STS_LINK)) if_printf(sc->bge_ifp, "link DOWN\n"); - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); } @@ -3623,12 +3628,12 @@ bge_link_upd(struct bge_softc *sc) { struct mii_data *mii; - uint32_t link, status; + uint32_t status; BGE_LOCK_ASSERT(sc); /* Clear 'pending link event' flag. */ - sc->bge_link_evt = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK_EVT); /* * Process link state changes. @@ -3649,20 +3654,18 @@ sc->bge_chipid != BGE_CHIPID_BCM5700_B2) { status = CSR_READ_4(sc, BGE_MAC_STS); if (status & BGE_MACSTAT_MI_INTERRUPT) { - callout_stop(&sc->bge_stat_ch); - bge_tick_locked(sc); - mii = device_get_softc(sc->bge_miibus); - if (!sc->bge_link && + mii_pollstat(mii); + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && mii->mii_media_status & IFM_ACTIVE && IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && (!(mii->mii_media_status & IFM_ACTIVE) || IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); } @@ -3680,8 +3683,8 @@ if (sc->bge_tbi) { status = CSR_READ_4(sc, BGE_MAC_STS); if (status & BGE_MACSTAT_TBI_PCS_SYNCHED) { - if (!sc->bge_link) { - sc->bge_link++; + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (sc->bge_asicrev == BGE_ASICREV_BCM5704) BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_TBI_SEND_CFGS); @@ -3691,42 +3694,38 @@ if_link_state_change(sc->bge_ifp, LINK_STATE_UP); } - } else if (sc->bge_link) { - sc->bge_link = 0; + } else if (BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); if_link_state_change(sc->bge_ifp, LINK_STATE_DOWN); } - /* Discard link events for MII/GMII cards if MI auto-polling disabled */ - } else if (CSR_READ_4(sc, BGE_MI_MODE) & BGE_MIMODE_AUTOPOLL) { - /* - * Some broken BCM chips have BGE_STATFLAG_LINKSTATE_CHANGED bit - * in status word always set. Workaround this bug by reading - * PHY link status directly. - */ - link = (CSR_READ_4(sc, BGE_MI_STS) & BGE_MISTS_LINK) ? 1 : 0; - - if (link != sc->bge_link || - sc->bge_asicrev == BGE_ASICREV_BCM5700) { - callout_stop(&sc->bge_stat_ch); - bge_tick_locked(sc); - - mii = device_get_softc(sc->bge_miibus); - if (!sc->bge_link && - mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; - if (bootverbose) - if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && - (!(mii->mii_media_status & IFM_ACTIVE) || - IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; - if (bootverbose) - if_printf(sc->bge_ifp, "link DOWN\n"); - } - } - } + /* + * Discard link events for MII/GMII cards if MI auto-polling disabled. + * This should not happen since mii callouts are locked now, but + * we keep this check for debug. + */ + } else if (BGE_STS_BIT(sc, BGE_STS_AUTOPOLL)) { + mii = device_get_softc(sc->bge_miibus); + mii_pollstat(mii); + + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && + mii->mii_media_status & IFM_ACTIVE && + IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link UP\n"); + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && + (!(mii->mii_media_status & IFM_ACTIVE) || + IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link DOWN\n"); + } + } else + /* Should not happen, see above. */ + if_printf(sc->bge_ifp, + "link event discarded: PHY auto-polling is off.\n"); /* Clear the attention. */ CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| Index: sys/dev/mii/brgphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v retrieving revision 1.34.2.7 diff -u -r1.34.2.7 brgphy.c --- sys/dev/mii/brgphy.c 21 Oct 2006 00:26:41 -0000 1.34.2.7 +++ sys/dev/mii/brgphy.c 5 Feb 2007 23:23:39 -0000 @@ -464,6 +464,9 @@ return; } + if (bmsr & BRGPHY_BMSR_LINK) + sc->mii_ticks = 0; /* Reset autoneg timer. */ + switch (PHY_READ(sc, BRGPHY_MII_AUXSTS) & BRGPHY_AUXSTS_AN_RES) { case BRGPHY_RES_1000FD: --k+w/mQv8wyuph6w0-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 01:14:01 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF48016A406 for ; Tue, 6 Feb 2007 01:14:01 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx1.nttmcl.com (mx1.nttmcl.com [216.69.64.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9721613C4B5 for ; Tue, 6 Feb 2007 01:14:01 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from [216.69.70.37] (ramen.nttmcl.com [216.69.70.37]) by mx1.nttmcl.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l160unci009171 for ; Mon, 5 Feb 2007 16:56:54 -0800 Message-ID: <45C7D251.8060004@ab.ote.we.lv> Date: Mon, 05 Feb 2007 16:56:49 -0800 From: "Eugene M. Kim" User-Agent: Thunderbird 1.5.0.8 (X11/20061130) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mx1.nttmcl.com Cc: Subject: rtadvd(8) and deprecated prefixes 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, 06 Feb 2007 01:14:02 -0000 Greetings, Unless disabled with -s flag, rtadvd(8) automatically picks up on-link prefixes from the routing table and includes them in RA messages. In doing so, rtadvd does not seem to distinguish preferred prefixes (preferred lifetime > 0) from distinguished ones (pltime = 0), but simply advertises both kinds using the default pltime set in rtadvd.conf(5) for fresh, preferred prefixes. As a result, deprecated prefixes end up being advertised as valid (i.e. pltime > 0), demonstrated in the following two ifconfig(8) outputs (the first on the router, the second on a host that receives RA from the router): home 16:37:24 ~ $ 5 /sbin/ifconfig fxp0 inet6 fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::2a0:c9ff:feaa:106%fxp0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f00:3605:2a0:c9ff:feaa:106 prefixlen 64 inet6 2001:470:1f00:3605:: prefixlen 64 anycast inet6 2001:470:1f01:3222:: prefixlen 64 anycast deprecated seerajeane 16:39:13 ~ $ 3 /sbin/ifconfig em0 inet6 em0: flags=8843 mtu 1500 options=19b inet6 fe80::2e0:81ff:fe51:1e73%em0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f00:3605:2e0:81ff:fe51:1e73 prefixlen 64 autoconf inet6 2001:470:1f01:3222:2e0:81ff:fe51:1e73 prefixlen 64 autoconf Note that the two automatically configured addresses on em0 are still preferred, while the prefix 2001:470:1f01:3222::/64 is deprecated on the router. I believe rtadvd(8) should advertise deprecated on-link prefixes with pltime of 0, but I still wanted to know what other people think about this before working on actual code. So, here is the question: Is this really something to be fixed? Regards, Eugene From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 01:43:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50D4116A4FC for ; Tue, 6 Feb 2007 01:43:23 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: from web58607.mail.re3.yahoo.com (web58607.mail.re3.yahoo.com [68.142.236.205]) by mx1.freebsd.org (Postfix) with SMTP id E76D213C46B for ; Tue, 6 Feb 2007 01:43:22 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: (qmail 47543 invoked by uid 60001); 6 Feb 2007 01:43:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OQnKXVrlwuRB71D5UWiFqgB0FIY5SvicoSkltgABU37YZoMXHJtm5nILEu7enqVuHMQKk6YE7hVwsz5KGQ1FIArscywe8NXSF66XNvJshmCeDaeN4tzZ6Oy1obbim5Wum5aRcm3j+eNakT/AuyAB3mDCJtHNz0ePw2dbNiu4fww=; X-YMail-OSG: K09TwdEVM1m.MQOSua8xOve9IRWHT_AJ8uNI.Qea.3i5HL9sk3vPVLWscZnumFe2jQ-- Received: from [75.72.230.91] by web58607.mail.re3.yahoo.com via HTTP; Mon, 05 Feb 2007 17:43:22 PST Date: Mon, 5 Feb 2007 17:43:22 -0800 (PST) From: Arone Silimantia To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <414243.47093.qm@web58607.mail.re3.yahoo.com> X-Mailman-Approved-At: Tue, 06 Feb 2007 03:18:46 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: santy check: adding an ipv6 address for the first time ... 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, 06 Feb 2007 01:43:24 -0000 Hello, I am running a 6.1-RELEASE system, one IP (v4) address configured, everything is wonderful. Now, in the past I have added additional IPv4 addresses with this command: ifconfig fxp0 alias 192.168.0.2 netmask 255.255.255.255 Easy. So now, I need to add a ipv6 address for the first time, and I am very nervous - the system is very far away from me and it costs a LOT to have someone go reboot it or attach a KVM, etc. so I am _very_ worried about issuing the wrong command and knocking it off the network. Now, I have a real ipv6 connection, and am not tunneling or anything like that, so I don't need to do anything with gif0, do I ? Can I just run this command: ifconfig fxp0 inet6 alias 1234:4567:1234::2 netmask ?? and then: route add -inet6 default 1234:4567:1234::1 and that will work, and NOT knock me off of my ipv4 ? Also, I put ?? in place of my netmask above - what is the ipv6 netmask for a /48 ? Finally, when my provider told me about my ipv6 allocation, they said: "We have created a ::/48 for you, ::1 is your gateway" "inet6number: 1234:5678:1234::/48" So am I correct that my ifconfig IP (see above) should be: 234:5678:1234::2 Or am I misunderstanding how to write that out ? Many thanks. --------------------------------- Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 04:19:39 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F8D616A406 for ; Tue, 6 Feb 2007 04:19:39 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3C99B13C4AA for ; Tue, 6 Feb 2007 04:19:39 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so1820034nzh for ; Mon, 05 Feb 2007 20:19:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Zug9WIEz8hFiPMGQtg5ABnksVbiTdqG7V2/41Gt3FPjUEG7DzHHtgY9W9P85ZYo7U3JgW/T9QFLUbtvlEsA2edAput2pWD3IrjTKNCaS2stme7C7JSBfVz3rz5dPTvsnLZtLWzWwpFRt/VU9pPNdPUWoe5NJA+NWh6xHdHGvu6w= Received: by 10.35.91.10 with SMTP id t10mr15323050pyl.1170733943234; Mon, 05 Feb 2007 19:52:23 -0800 (PST) Received: by 10.35.58.13 with HTTP; Mon, 5 Feb 2007 19:52:23 -0800 (PST) Message-ID: Date: Tue, 6 Feb 2007 03:52:23 +0000 From: MQ To: "Oleg Bulyzhin" In-Reply-To: <20061214092248.GA21394@lath.rinet.ru> MIME-Version: 1.0 References: <20061206085401.GH32700@cell.sick.ru> <20061212224351.GE91560@lath.rinet.ru> <20061214092248.GA21394@lath.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: [antinvidia@gmail.com: some questions about bge(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, 06 Feb 2007 04:19:39 -0000 2006/12/14, Oleg Bulyzhin : > > On Thu, Dec 14, 2006 at 12:55:51AM +0000, MQ wrote: > > 2006/12/12, Oleg Bulyzhin : > > > > > >On Wed, Dec 06, 2006 at 11:54:01AM +0300, Gleb Smirnoff wrote: > > >> Forwarding to net@ list and to Oleg, who has made polling > > >> support for bge(4). > > >> > > >> ----- Forwarded message from MQ < antinvidia@gmail.com> ----- > > >> > > >> From: MQ > > >> To: glebius@freebsd.org , davidch@broadcom.com > > >> Subject: some questions about bge(4) > > >> Date: Sat, 2 Dec 2006 09:32:27 +0000 > > >> Delivered-To: glebius@freebsd.org > > >> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; > > >> s=beta; d=gmail.com; > > >> > > >h=received:message-id:date:from:to:subject:mime-version:content-type; > > >> > > > >b=ZL3ZZ1zR0mt4LaUN2Rr+jXTPSzQgJYRwLiwKnv95r2UCEids5Wl7oA2BNgicJ2QRG8OalJ7DqY7lM1HBgv0OVTlXOhGQ9aFmKQAuTNi6ueZA817XUacXyViEepnj0oNyYgAnkbaaBO1+nl2Fpb3IxV+MIe575WRlqbglF8kdOek= > > > > > >> > > >> Hi David and Gleb, > > >> I'm using several chips whose driver is bge(4). And now I have > some > > >> questions about the driver, would you please an answer for me? > > >> My confusion is related with some codes in /sys/dev/mii/brgphy.c. > The > > > > > >> bge(4) uses the callout to drive the watchdog. And the > brgphy_service() > > >is > > >> called once per second. It calls brgphy_mii_phy_auto() every 5 > seconds > > >to > > >> autonegotiate the media. Normally, it costs about 0.5ms in the first > > >> function brgphy_service(), and about 5ms when autonegotiation is > > >proceeded. > > > > > >brgphy_mii_phy_auto() is called only if there is no link. > > > > > >> I haven't done streestest on it, consequently I don't know if this > > >delay > > >> will cause packets to be dropped. But I've enabled device polling > with > > >the > > >> bge(4) on FreeBSD 6.1-RELEASE. If HZ is set to a high value(e.g. > 4000), > > >this > > >> delay will cause the kern.polling.lost_polls to increase by one or > two > > >every > > >> second. And for about five seconds, the lost poll will increase by at > > >least > > >> 16 regularly. So I think this behavior has some impact on the systems > > >that > > >> enables device polling. Could we get something to make the bge(4) a > bit > > >more > > >> friendly to the device polling? I don't know if autonegotiation is > > >really > > >> needed to be called so frequently when we are connected to a good > > >network > > >> environment. Can I modify the interval between two autonegotiations > to > > >have > > >> less lost_polls? However, I have no idea about the long time spent in > > >the > > >> brgphy_service(), please take a look at the problem when you have > enough > > >> time. > > > > > >If you have lost poll it does not guarantee packet loss. > > >Packets can be retrieved by next poll or even by idle_poll thread. > > >bge_tick() is doing couple of pci register reads (it's polling phy > status > > >and > > >updates some statistic counters), this why it takes some time. > > > > > >Anyway, you are right about too short autonegotiation timer, i'll fix > it > > >soon. > > > > > >> > > >> Regards > > >> MQ > > >> > > >> ----- End forwarded message ----- > > >> > > >> -- > > >> Totus tuus, Glebius. > > >> GLEBIUS-RIPN GLEB-RIPE > > > > > >-- > > >Oleg. > > > > > >================================================================ > > >=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > > >================================================================ > > > > > > > > > > Oh, I didn't connect to switch in my previous testings, so I didn't > notice > > that the brgphy_mii_phy_auto() is called only there is no link. It's my > > fault. Therefore there won't be a problem with this. > > > > By the way, bge_tick() takes about 0.5ms to finish its work, this > results > > the lost poll every second when HZ is higher. Lower HZ will limit the > > performance under heavy traffic, and may result packet loss in that > > situation. And higher HZ will make a confusing situation that whether we > > > have encountered a packet loss? It's really hard to make a decision > between > > these two kinds of situation. > > IMO, high HZ would not give perfomance gain if you have idle polling on > (sysctl kern.polling.idle_poll=1 ). > So it's better to have HZ=1000 & idle polling, than HZ=10000 and idle > polling > disabled. > > -- > Oleg. > > ================================================================ > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > ================================================================ > > I see, I'll test when I get enough time and a new box with Broadcom NICs From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 05:04:52 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70D1516A401 for ; Tue, 6 Feb 2007 05:04:52 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id 40D4C13C46B for ; Tue, 6 Feb 2007 05:04:52 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [IPv6:2001:200:1b1:1010:34fe:f192:b4d7:be48]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A21027301D; Tue, 6 Feb 2007 13:38:53 +0900 (JST) Date: Tue, 06 Feb 2007 13:38:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Eugene M. Kim" In-Reply-To: <45C7D251.8060004@ab.ote.we.lv> References: <45C7D251.8060004@ab.ote.we.lv> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: rtadvd(8) and deprecated prefixes 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, 06 Feb 2007 05:04:52 -0000 >>>>> On Mon, 05 Feb 2007 16:56:49 -0800, >>>>> "Eugene M. Kim" said: > Note that the two automatically configured addresses on em0 are still > preferred, while the prefix 2001:470:1f01:3222::/64 is deprecated on the > router. > I believe rtadvd(8) should advertise deprecated on-link prefixes with > pltime of 0, but I still wanted to know what other people think about > this before working on actual code. So, here is the question: Is this > really something to be fixed? I'm pretty sure different people have different opinions on this matter, but I personally think we should not try to "fix" it. This feature originally intended to make rtadvd as much configuration-free as possible in the most typical cases, that is, all addresses on the router is configured by hand and the associated prefixes are advertised with the default parameters defined in RFC2461. This is because why rtadvd does not allow the administrator to specify just prefix lifetimes while letting the daemon get the prefixes from the kernel. So, treating a prefix lifetime of 0 separately is at least against the original design policy (believe me, I'm confident because it's me who implemented this:-) Also, once we open the Pandora's box, we'll encounter all other non-default issues that beg customized behavior or require detailed considerations on corner cases. One example is to allow the user to specify the lifetimes (without specifying prefixes). We might also want to have rtadvd follow decreasing lifetimes in real time. Others may want to restrict the advertised prefixes to some subset of ones retrieved from the routing table, etc, etc. So, (again) I'd personally keep the current feature and requires the administrator to configure the router explicitly to handle any non-default cases. (If we agree on that) we may have to note in the man page about the implementation policy, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 07:54:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8512616A401 for ; Tue, 6 Feb 2007 07:54:47 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 2650113C48E for ; Tue, 6 Feb 2007 07:54:47 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 96582 invoked from network); 6 Feb 2007 07:54:37 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay00.pair.com with SMTP; 6 Feb 2007 07:54:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 6 Feb 2007 01:54:36 -0600 (CST) From: Mike Silbersack To: Randall Stewart In-Reply-To: <45B7631A.3070001@cisco.com> Message-ID: <20070206014950.S25997@odysseus.silby.com> References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org> <45B7631A.3070001@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 06 Feb 2007 07:54:47 -0000 On Wed, 24 Jan 2007, Randall Stewart wrote: > Well.. no I believe someone (was in Lin) mentioned that > you can get a live-lock if you allow a reduction.. and > thus the mbuf clusters were NOT allowed to be reduced.. I messed around with this a bit when changing the limit on net.inet.tcp.maxtcptw. It looked to me as if lowering the limit on a zone, even one that has UMA_ZONE_NOFREE, worked as expected. (As expected in the UMA_ZONE_NOFREE case was that the zone could not shrink below the maximum that was ever allocated in it.) I can see how problems could result if someone starts changing that setting while the system is in some sort of mbuf exhaustion state, but I think that the benefit of being able to tune it most of the time far outweighs the disadvantage of things going wrong in a few cases. Granted, I haven't even looked at your patch, so I could be missing something subtle. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 08:05:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57DE416A400 for ; Tue, 6 Feb 2007 08:05:03 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id E306B13C494 for ; Tue, 6 Feb 2007 08:05:02 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 94430 invoked from network); 6 Feb 2007 07:38:21 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay00.pair.com with SMTP; 6 Feb 2007 07:38:21 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 6 Feb 2007 01:38:03 -0600 (CST) From: Mike Silbersack To: Ricardo Nabinger Sanchez In-Reply-To: <20070117135629.a02ada2f.rnsanchez@wait4.org> Message-ID: <20070206013506.M25997@odysseus.silby.com> References: <20070117135629.a02ada2f.rnsanchez@wait4.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: network related benchmark 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, 06 Feb 2007 08:05:03 -0000 On Wed, 17 Jan 2007, Ricardo Nabinger Sanchez wrote: > Hello, > > Accidentally I got into this PDF: > > http://www.dcs.qmul.ac.uk/~awm/slides/masterclass2006/monitor-hardware.pdf > > Quite interesting results, and nice future work. Has anybody seen it > already? I believe that there is a FreeBSD developer working on an updated version of BPF that will perform even better than it does already. I'll let him reveal himself if he wishes. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 11:49:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFC8716A405 for ; Tue, 6 Feb 2007 11:49:07 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by mx1.freebsd.org (Postfix) with ESMTP id 67C5A13C46B for ; Tue, 6 Feb 2007 11:49:07 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by logos.uptel.net (Postfix) with ESMTP id C16FF33C4F for ; Tue, 6 Feb 2007 13:17:53 +0200 (EET) Date: Tue, 6 Feb 2007 13:17:53 +0200 (EET) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20070206131612.P36262@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Carp, vlan, routing... 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, 06 Feb 2007 11:49:07 -0000 Hello ALL! I have a problem with CARP on FreeBSD 6.2 in the following scheme: +--------------+ +-----------------------+ +-----------------+ | A | | B | | C | | vlan20 |-//->| vlan20 vlan10 |-//-| vlan10 | +--------------+ +-----------------------+ +-----------------+ vlan20 10.10.10.2/26 vlan20 10.10.10.1/26 gateway 10.10.10.1 vlan10 10.10.9.1/26 vlan10 10.10.9.2/26 carp10 10.10.9.3/26 carp10 10.10.9.3/26 advskew 0 advskew 1 carp11 10.10.9.4/26 carp11 10.10.9.4/26 advskew 1 advskew 0 i.e. server B MASTER for 10.10.9.3/26, BACKUP for 10.10.9.4/26 server C BACKUP for 10.10.9.3/26, MASTER for 10.10.9.4/26 But if to send icmp request from server A -> to server C on ip 10.10.9.4, server B replay from BACKUP iface carp11 !?!? This is trouble or feature of realization ????? ------------------------------------------------- serverB> ifconfig carp* carp10: flags=49 mtu 1500 inet 10.10.9.3 netmask 0xffffffc0 carp: MASTER vhid 100 advbase 1 advskew 0 carp11: flags=49 mtu 1500 inet 10.10.9.4 netmask 0xffffffc0 carp: BACKUP vhid 101 advbase 1 advskew 1 serverC> ifconfig carp* carp10: flags=49 mtu 1500 inet 10.10.9.3 netmask 0xffffffc0 carp: BACKUP vhid 100 advbase 1 advskew 1 carp11: flags=49 mtu 1500 inet 10.10.9.4 netmask 0xffffffc0 carp: MASTER vhid 101 advbase 1 advskew 0 /etc/sysctl.conf: net.inet.carp.preempt=1 From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 12:44:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83C8916A405 for ; Tue, 6 Feb 2007 12:44:06 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109]) by mx1.freebsd.org (Postfix) with ESMTP id EFD5913C471 for ; Tue, 6 Feb 2007 12:44:05 +0000 (UTC) (envelope-from r.gruyters@yirdis.nl) Received: from server.yirdis.net (localhost [127.0.0.1]) by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l16Ci2bQ023407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Feb 2007 13:44:02 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) Received: (from www@localhost) by server.yirdis.net (8.13.6/8.13.6/Submit) id l16ChxeU023393; Tue, 6 Feb 2007 13:43:59 +0100 (CET) (envelope-from r.gruyters@yirdis.nl) X-Authentication-Warning: server.yirdis.net: www set sender to r.gruyters@yirdis.nl using -f Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27]) by server.yirdis.net (Horde MIME library) with HTTP; Tue, 06 Feb 2007 13:43:59 +0100 Message-ID: <20070206134359.36a01xthhcosogws@server.yirdis.net> Date: Tue, 06 Feb 2007 13:43:59 +0100 From: Robin Gruyters To: Oleg Bulyzhin References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> In-Reply-To: <20070205232800.GA45487@lath.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4 X-Virus-Scanned: OK Cc: freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 06 Feb 2007 12:44:06 -0000 Ok, I have patched and rebuild the kernel. Looks ok now. Here some info: media 100baseTX mediaopt full-duplex serverA (Broadcom BCM5705K) <192.168.254.1/30> (iperf server) serverB (Broadcom BCM5704) <192.168.254.2/30> (iperf client) # iperf -c 192.168.254.1 -t 60 -i 5 ------------------------------------------------------------ Client connecting to 192.168.254.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.2 port 56356 connected with 192.168.254.1 port 5001 [ 3] 0.0- 5.0 sec 55.1 MBytes 92.4 Mbits/sec [ 3] 5.0-10.0 sec 55.8 MBytes 93.7 Mbits/sec [ 3] 10.0-15.0 sec 54.0 MBytes 90.6 Mbits/sec [ 3] 15.0-20.0 sec 55.7 MBytes 93.5 Mbits/sec [ 3] 20.0-25.0 sec 55.7 MBytes 93.4 Mbits/sec [ 3] 25.0-30.0 sec 53.9 MBytes 90.4 Mbits/sec [ 3] 30.0-35.0 sec 55.8 MBytes 93.6 Mbits/sec [ 3] 35.0-40.0 sec 56.0 MBytes 93.9 Mbits/sec [ 3] 40.0-45.0 sec 55.8 MBytes 93.5 Mbits/sec [ 3] 45.0-50.0 sec 54.9 MBytes 92.2 Mbits/sec [ 3] 50.0-55.0 sec 56.0 MBytes 93.9 Mbits/sec [ 3] 55.0-60.0 sec 55.5 MBytes 93.2 Mbits/sec [ 3] 0.0-60.0 sec 664 MBytes 92.9 Mbits/sec [netstat -ni -f link] bge1 1500 00:12:79:94:ed:11 756917 0 971564 =20 0 0 [/end] media 1000baseTX mediaopt full-duplex serverA (Broadcom BCM5705K) <192.168.254.1/30> (iperf server) serverB (Broadcom BCM5704) <192.168.254.2/30> (iperf client) iperf -c 192.168.254.1 -t 60 -i 5 ------------------------------------------------------------ Client connecting to 192.168.254.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.254.2 port 56295 connected with 192.168.254.1 port 5001 [ 3] 0.0- 5.0 sec 275 MBytes 461 Mbits/sec [ 3] 5.0-10.0 sec 291 MBytes 488 Mbits/sec [ 3] 10.0-15.0 sec 291 MBytes 488 Mbits/sec [ 3] 15.0-20.0 sec 271 MBytes 454 Mbits/sec [ 3] 20.0-25.0 sec 288 MBytes 484 Mbits/sec [ 3] 25.0-30.0 sec 291 MBytes 489 Mbits/sec [ 3] 30.0-35.0 sec 281 MBytes 471 Mbits/sec [ 3] 35.0-40.0 sec 290 MBytes 487 Mbits/sec [ 3] 40.0-45.0 sec 291 MBytes 489 Mbits/sec [ 3] 45.0-50.0 sec 290 MBytes 486 Mbits/sec [ 3] 50.0-55.0 sec 258 MBytes 434 Mbits/sec [ 3] 55.0-60.0 sec 287 MBytes 482 Mbits/sec [ 3] 0.0-60.0 sec 3.33 GBytes 476 Mbits/sec [netstat -ni -f link] bge1 1500 00:12:79:94:ed:11 2342915 0 3433038 =20 0 0 [/end] Regards, Robin Gruyters Network and Security Engineer Yirdis B.V. I: http://yirdis.com P: +31 (0)36 5300394 F: +31 (0)36 5489119 Quoting Oleg Bulyzhin : > On Thu, Jan 25, 2007 at 05:05:32PM +0100, Robin Gruyters wrote: >> On 13-Jan-2007 Oleg Bulyzhin wrote: >> > >> >> Could you please test attached patch? It should fix ierrs issue >> >and should not >> >> break link events (would be fine to test it: unplug/plug cable, >> >try to change >> >> media with ifconfig, change media on other end of wire). >> >> >> Hi ya, >> >> Just wondering will this patch/update be available for RELENG_6? I >> have the same problems here with 3 of our servers. >> >> Here is dmesg from our development server: >> >> [...] >> Copyright (c) 1992-2007 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 6.2-RELEASE #1: Mon Jan 15 15:34:19 CET 2007 >> root@server.yirdis.net:/data/obj/data/src_6_2/sys/YIRDIS >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU) >> Origin =3D "GenuineIntel" Id =3D 0xf41 Stepping =3D 1 >> >> Features=3D0xbfebfbff >> Features2=3D0x641d> >> AMD Features=3D0x20000000 >> Logical CPUs per core: 2 >> real memory =3D 2147430400 (2047 MB) >> avail memory =3D 2100547584 (2003 MB) >> ACPI APIC Table: >> Security auditing service present >> BSM auditing present >> ioapic1: Changing APIC ID to 9 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> ioapic2 irqs 48-71 on motherboard >> ioapic3 irqs 72-95 on motherboard >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 >> cpu0: on acpi0 >> pcib0: on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci13: on pcib1 >> pcib2: at device 4.0 on pci0 >> pci6: on pcib2 >> pcib3: at device 0.0 on pci6 >> pci7: on pcib3 >> pcib4: at device 0.2 on pci6 >> pci10: on pcib4 >> pcib5: at device 1.0 on pci10 >> pci11: on pcib5 >> ste0: port 0x5000-0x507f irq 72 at >> device 4.0 on pci11 >> miibus0: on ste0 >> ukphy0: on miibus0 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ste0: Ethernet address: 00:0d:88:fc:c8:cc >> ste1: port 0x5080-0x50ff irq 73 at >> device 5.0 on pci11 >> miibus1: on ste1 >> ukphy1: on miibus1 >> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ste1: Ethernet address: 00:0d:88:fc:c8:cd >> ste2: port 0x5400-0x547f irq 74 at >> device 6.0 on pci11 >> miibus2: on ste2 >> ukphy2: on miibus2 >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ste2: Ethernet address: 00:0d:88:fc:c8:ce >> ste3: port 0x5480-0x54ff irq 75 at >> device 7.0 on pci11 >> miibus3: on ste3 >> ukphy3: on miibus3 >> ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ste3: Ethernet address: 00:0d:88:fc:c8:cf >> pcib6: at device 6.0 on pci0 >> pci3: on pcib6 >> pcib7: at device 28.0 on pci0 >> pci2: on pcib7 >> ciss0: port 0x4000-0x40ff mem >> 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 24 at device 1.0 on pci2 >> ciss0: [GIANT-LOCKED] >> bge0: mem >> 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 >> miibus4: on bge0 >> brgphy0: on miibus4 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX-FDX, auto >> bge0: Ethernet address: 00:12:79:94:ed:12 >> bge1: mem >> 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 >> miibus5: on bge1 >> brgphy1: on miibus5 >> brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX-FDX, auto >> bge1: Ethernet address: 00:12:79:94:ed:11 >> pci0: at device 29.0 (no driver attached) >> pci0: at device 29.1 (no driver attached) >> pci0: at device 29.4 (no driver attached) >> pci0: at device 29.5 (no >> driver attached) >> pci0: at device 29.7 (no driver attached) >> pcib8: at device 30.0 on pci0 >> pci1: on pcib8 >> pci1: at device 3.0 (no driver attached) >> pci1: at device 4.0 (no driver attached) >> pci1: at device 4.2 (no driver attached) >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 18 at device 31.1 >> on pci0 >> ata0: on atapci0 >> ata1: on atapci0 >> acpi_tz0: 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 >> sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> sio0: type 16550A >> fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acp= i0 >> fdc0: [FAST] >> fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >> pmtimer0 on isa0 >> orm0: at iomem >> 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=3D0x300> >> sio1 at port 0x2f8-0x2ff irq 3 on isa0 >> sio1: type 16550A >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> Timecounter "TSC" frequency 3000124702 Hz quality 800 >> Timecounters tick every 1.000 msec >> acd0: CDROM at ata0-master PIO4 >> da0 at ciss0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-0 device >> da0: 135.168MB/s transfers >> da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C) >> Trying to mount root from ufs:/dev/da0s1a >> Accounting enabled >> [...] >> >> And here the netstat interface statistics: >> [...] >> Name Mtu Network Address Ipkts Ierrs Opkts >> Oerrs Coll >> ste0* 1500 00:0d:88:fc:c8:cc 0 0 0 >> 0 0 >> ste1* 1500 00:0d:88:fc:c8:cd 0 0 0 >> 0 0 >> ste2* 1500 00:0d:88:fc:c8:ce 0 0 0 >> 0 0 >> ste3* 1500 00:0d:88:fc:c8:cf 0 0 0 >> 0 0 >> bge0 1500 00:12:79:94:ed:12 11343768 2114510 20564242 >> 0 0 >> bge1* 1500 00:12:79:94:ed:11 0 0 0 >> 0 0 >> pflog 33208 0 0 0 >> 0 0 >> lo0 16384 60221421 0 60221421 >> 0 0 >> [...] >> >> If you have a patch for FreeBSD 6.2, i'm quite happily to test it on >> our development server. >> >> Regards, >> >> Robin Gruyters >> > > Sorry for the late reply - i was AFK for some time and didnt read mails. > Patch against 6.2R attached, please let me know does it helps or not. > > -- > Oleg. > > =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 Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =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 > > From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 13:34:44 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9D9316A400; Tue, 6 Feb 2007 13:34:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 612D113C48D; Tue, 6 Feb 2007 13:34:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id C20EA5A1C3E; Wed, 7 Feb 2007 00:34:42 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 008338C0F; Wed, 7 Feb 2007 00:34:40 +1100 (EST) Date: Wed, 7 Feb 2007 00:34:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: MQ In-Reply-To: Message-ID: <20070206234100.S31484@besplex.bde.org> References: <20061206085401.GH32700@cell.sick.ru> <20061212224351.GE91560@lath.rinet.ru> <20061214092248.GA21394@lath.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Oleg Bulyzhin , net@FreeBSD.org Subject: Re: [antinvidia@gmail.com: some questions about bge(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, 06 Feb 2007 13:34:44 -0000 On Tue, 6 Feb 2007, MQ wrote: > 2006/12/14, Oleg Bulyzhin : >> >> On Thu, Dec 14, 2006 at 12:55:51AM +0000, MQ wrote: >> > 2006/12/12, Oleg Bulyzhin : >> > > >> > >On Wed, Dec 06, 2006 at 11:54:01AM +0300, Gleb Smirnoff wrote: >> > >> Forwarding to net@ list and to Oleg, who has made polling >> > >> support for bge(4). >> > >> >> > >> ----- Forwarded message from MQ < antinvidia@gmail.com> ----- >> > >> >> > >> From: MQ >> > >> To: glebius@freebsd.org , davidch@broadcom.com >> > >> Subject: some questions about bge(4) >> > >> Date: Sat, 2 Dec 2006 09:32:27 +0000 >> > >> Delivered-To: glebius@freebsd.org >> > >> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; >> > >> s=beta; d=gmail.com; >> > >> >> > >h=received:message-id:date:from:to:subject:mime-version:content-type; >> > >> >> > >> >b=ZL3ZZ1zR0mt4LaUN2Rr+jXTPSzQgJYRwLiwKnv95r2UCEids5Wl7oA2BNgicJ2QRG8OalJ7DqY7lM1HBgv0OVTlXOhGQ9aFmKQAuTNi6ueZA817XUacXyViEepnj0oNyYgAnkbaaBO1+nl2Fpb3IxV+MIe575WRlqbglF8kdOek= >> > > >> > >> >> > >> Hi David and Gleb, >> > >> I'm using several chips whose driver is bge(4). And now I have >> some >> > >> questions about the driver, would you please an answer for me? >> > >> My confusion is related with some codes in /sys/dev/mii/brgphy.c. >> The >> > > >> > >> bge(4) uses the callout to drive the watchdog. And the >> brgphy_service() >> > >is >> > >> called once per second. It calls brgphy_mii_phy_auto() every 5 >> seconds >> > >to >> > >> autonegotiate the media. Normally, it costs about 0.5ms in the first >> > >> function brgphy_service(), and about 5ms when autonegotiation is >> > >proceeded. >> > > >> > >brgphy_mii_phy_auto() is called only if there is no link. I haven't seen more than 50-100 uS for an average brgphy_service(), but even 500 uS shouldn't be a problem except near the maximum theoretical packet rate of ~1500 kpps, since the device has buffering for 512-1024 packets (512 @ 1500 kpps = 341 uS = not quite 500 uS). Half of the available rx buffering for non-jumbo packets is not being used, so the worst case is actually 170 uS of buffering @ 1500 kpps. However, known bugs cause brgphy_service() to often lose a packet. >> > >> I haven't done streestest on it, consequently I don't know if this >> > >delay >> > >> will cause packets to be dropped. But I've enabled device polling >> with >> > >the >> > >> bge(4) on FreeBSD 6.1-RELEASE. If HZ is set to a high value(e.g. >> 4000), >> > >this >> > >> delay will cause the kern.polling.lost_polls to increase by one or >> two >> > >every >> > >> second. And for about five seconds, the lost poll will increase by at >> > >least >> > >> 16 regularly. So I think this behavior has some impact on the systems >> > >that >> > >> enables device polling. Lost polls shouldn't be much more of a problem. Polls are only lost if the system can't actually poll at 1/HZ. Increasing HZ won't make the worst case any better. Polls are lost at HZ = 1000 then the worst case extra delay is >= 1mS the 512-1024 packets of buffering starts becoming a problem. It is alread a problem at the maximum packet rate, since at least 1500 packets of buffering would be needed for polling at 1000 Hz to have any chacne of keeping up. The practival limits for polling at 1000 Hz with bge are now close to 256 kpps for rx (since half the buffering is not configured) and 512 kpps for tx. >> Could we get something to make the bge(4) a >> bit >> > >more >> > >> friendly to the device polling? I don't know if autonegotiation is >> > >really >> > >> needed to be called so frequently when we are connected to a good >> > >network >> > >> environment. Can I modify the interval between two autonegotiations > ... >> > >If you have lost poll it does not guarantee packet loss. It hould never result in packet loss, due to buffering being adequate. >> > >Packets can be retrieved by next poll or even by idle_poll thread. >> > >bge_tick() is doing couple of pci register reads (it's polling phy >> status >> > >and >> > >updates some statistic counters), this why it takes some time. I don't believe in polling, but occasionally test it to check that interrupt handling doesn't lose to it :-). I mostly use HZ = 100 and get up to 640 kpps (tx) where polling at 1000 Hz is limited to 512 kpps. Polling in idle can work better if the system is actually idle. Interrupt handling still loses to it for latency -- I have a ping latency of 50-60 uS with interrupt handling and 40-50 uS with polling in idle. However, something (perhaps excessive PCI reads to check the link checks on every poll) limits packet rates for polling -- large values of HZ work as expected, and polling in idle should work better provided the system is actually idle, but in practice polling in idle with low HZ doesn't work as well for throughput as not polling in idle with a large HZ. (I guess this is because the PCI reads take several cycles per poll and each poll delivers an average of <= 1 packet. For a ping latency of 40 uS, the few extra uS are not dominant, but at 100's of kpps they become dominant.) >> > By the way, bge_tick() takes about 0.5ms to finish its work, this >> results >> > the lost poll every second when HZ is higher. Lower HZ will limit the >> > performance under heavy traffic, and may result packet loss in that >> > situation. And higher HZ will make a confusing situation that whether we >> >> > have encountered a packet loss? It's really hard to make a decision >> between >> > these two kinds of situation. >> >> IMO, high HZ would not give perfomance gain if you have idle polling on >> (sysctl kern.polling.idle_poll=1 ). >> So it's better to have HZ=1000 & idle polling, than HZ=10000 and idle >> polling >> disabled. A higher HZ can work better than idle polling. If the system is rarely idle, then idle polling is useless. At any reasonable value of HZ, latency is very bad unless idle polling is used and the system is often idle. Unreasonably large values of HZ (10000 - 100000 are probably possible) can be used to reduced the latency. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 13:54:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B95DF16A401 for ; Tue, 6 Feb 2007 13:54:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 87CA213C441 for ; Tue, 6 Feb 2007 13:54:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 1E6A84C1A3; Tue, 6 Feb 2007 08:54:08 -0500 (EST) Date: Tue, 6 Feb 2007 13:54:07 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070206014950.S25997@odysseus.silby.com> Message-ID: <20070206135217.A32369@fledge.watson.org> References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org> <45B7631A.3070001@cisco.com> <20070206014950.S25997@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , Randall Stewart , freebsd-net Subject: Re: mbuf patch with sysctl suggestions too 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, 06 Feb 2007 13:54:09 -0000 On Tue, 6 Feb 2007, Mike Silbersack wrote: > On Wed, 24 Jan 2007, Randall Stewart wrote: > >> Well.. no I believe someone (was in Lin) mentioned that you can get a >> live-lock if you allow a reduction.. and thus the mbuf clusters were NOT >> allowed to be reduced.. > > I messed around with this a bit when changing the limit on > net.inet.tcp.maxtcptw. It looked to me as if lowering the limit on a zone, > even one that has UMA_ZONE_NOFREE, worked as expected. (As expected in the > UMA_ZONE_NOFREE case was that the zone could not shrink below the maximum > that was ever allocated in it.) > > I can see how problems could result if someone starts changing that setting > while the system is in some sort of mbuf exhaustion state, but I think that > the benefit of being able to tune it most of the time far outweighs the > disadvantage of things going wrong in a few cases. > > Granted, I haven't even looked at your patch, so I could be missing > something subtle. :) A work-around for the "leaking" of clusters has recently been committed by Mohan, and is on the MFC path. The underlying problem here is that UMA only partially understands the relationship between mbufs and clusters, and doesn't recognize that clusters cached with free mbufs (for joint allocation) are, in fact, free, so as the "Packet" zone cache fills, clusters for independent allocation are no longer seen as free. This will hopefully correct the observed problems with "zoneli" wait channels and very high cluster allocation seen in some environments. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 14:04:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA9BF16A403 for ; Tue, 6 Feb 2007 14:04:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8D56D13C4A3 for ; Tue, 6 Feb 2007 14:04:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 392AD46E4C; Tue, 6 Feb 2007 09:04:49 -0500 (EST) Date: Tue, 6 Feb 2007 14:04:49 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20070206013506.M25997@odysseus.silby.com> Message-ID: <20070206135638.Y32369@fledge.watson.org> References: <20070117135629.a02ada2f.rnsanchez@wait4.org> <20070206013506.M25997@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ricardo Nabinger Sanchez Subject: Re: network related benchmark 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, 06 Feb 2007 14:04:52 -0000 On Tue, 6 Feb 2007, Mike Silbersack wrote: > On Wed, 17 Jan 2007, Ricardo Nabinger Sanchez wrote: > >> Accidentally I got into this PDF: >> >> http://www.dcs.qmul.ac.uk/~awm/slides/masterclass2006/monitor-hardware.pdf >> >> Quite interesting results, and nice future work. Has anybody seen it >> already? > > I believe that there is a FreeBSD developer working on an updated version of > BPF that will perform even better than it does already. I'll let him reveal > himself if he wishes. :) Heh. Indeed. I've created a zero-copy (well, one-copy) BPF implementation under contract to a customer. We're still working on refining and measuring performance of the implementation, but we're already seeing marked performance improvement as a result of reduced memory copies. We don't currently have a CVS merge ETA, but I think there's a reasonable chance the implementation will appear in FreeBSD 6.3. Those interested in perusing the WIP can find it in the FreeBSD Perforce repository: //depot/projects/zcopybpf/... It includes a modified version of libpcap. We're still working on improving the event model--in particular, we are working in improving the ioctl set to allow "timeouts" to be more easily supported. Be warned that this code is very much "under development" and further changes to the ioctl API are expected. Just to clarify the copying point: right now the FreeBSD BPF implementation performs a minimum of two memory copies per packet sniffed: one copy from the mbufs/mbuf clusters to the BPF buffer, and then one copy from the BPF buffer to user space. This implementation allows user space to register user memory buffers with the kernel, which are mapped into the kernel address space, pinned into memory, and then used in place of kernel memory buffers and written to directly during capture. This does not eliminate the in-kernel copy, just the kernel->userspace copy. For a variety of reasons, eliminating the in-kernel copy is difficult and possibly undesirable. As the in-kernel memory layout for BPF buffers is identical to the layout of memory copied to in userspace, libpcap (and other BPF consumers) require modifications to their event handling and ioctl handling, but not to packet parsing routines, so changes are pretty minimal. Consumers accessing BPF through libpcap will not require any modification. I hope to start looking at 10gbps performance in the next week or two; until now we've been doing 1gbps measurement as the testing is occuring at the customer site. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 14:31:44 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E946116A4D4; Tue, 6 Feb 2007 14:31:43 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8725D13C48E; Tue, 6 Feb 2007 14:31:43 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 3517F5A7FC5; Wed, 7 Feb 2007 01:31:42 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 75F0D8C0E; Wed, 7 Feb 2007 01:31:40 +1100 (EST) Date: Wed, 7 Feb 2007 01:31:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oleg Bulyzhin In-Reply-To: <20070205232800.GA45487@lath.rinet.ru> Message-ID: <20070207003539.I31484@besplex.bde.org> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robin Gruyters , freebsd-net@FreeBSD.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 06 Feb 2007 14:31:44 -0000 On Tue, 6 Feb 2007, Oleg Bulyzhin wrote: > Sorry for the late reply - i was AFK for some time and didnt read mails. > Patch against 6.2R attached, please let me know does it helps or not. I didn't test the old version of this since I have too many local changes in my non-6.x versions. I might test the 6.x version. I use jdp's quicker fix. It works fine for detecting cable unplug and replug, but link detection is still very bad at boot time and after down/up (seems to be worse for down/up than unplug/replug?). Link detection in -current generally seems to be much worse than in 5.2. On some systems I use two ping -c2's early in the boot to wait for the link to actually be up. The first ping tends to fail and the second tends to work, both long after the lonk claims to be up. Then other network activity still takes too long to start. Without the pings, an "ntpdate -b" early in the boot fails about half the time and gives messed up timing activity when it fails, and initial nfs mounts tak 30-60 seconds. Later after down/up and waiting for the "up" message, ttcp -u usually fails to connect the first time and then works normally with no failure or connection delay the second time. % Index: sys/dev/bge/if_bgereg.h % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v % retrieving revision 1.36.2.8.2.1 % diff -u -r1.36.2.8.2.1 if_bgereg.h % --- sys/dev/bge/if_bgereg.h 21 Dec 2006 21:53:54 -0000 1.36.2.8.2.1 % +++ sys/dev/bge/if_bgereg.h 5 Feb 2007 23:23:22 -0000 % @@ -2460,8 +2460,13 @@ % uint32_t bge_tx_buf_ratio; % int bge_if_flags; % int bge_txcnt; % - int bge_link; /* link state */ % - int bge_link_evt; /* pending link event */ % + uint32_t bge_sts; % +#define BGE_STS_LINK 0x00000001 /* MAC link status */ % +#define BGE_STS_LINK_EVT 0x00000002 /* pending link event */ % +#define BGE_STS_AUTOPOLL 0x00000004 /* PHY auto-polling */ % +#define BGE_STS_BIT(sc, x) ((sc)->bge_sts & (x)) % +#define BGE_STS_SETBIT(sc, x) ((sc)->bge_sts |= (x)) % +#define BGE_STS_CLRBIT(sc, x) ((sc)->bge_sts &= ~(x)) Style bugs: - inconsistents tabs. bge mostly consitently doesn't follow KNF for the tab after #define. - I don't like obfuscating bit testing and setting using macros. The above macros are quite different from the BGE and PCI SETBIT and CLRBIT macros -- the latter operate on hardware bits and do something useful by hiding the details of the hardware accesses, and aren't assoicated with bit testing macros. Apart from the above, testing of hardware bits and testing an setting of software bits is always done using direct "&" and "|" operations in bge. % Index: sys/dev/bge/if_bge.c % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v % retrieving revision 1.91.2.18.2.1 % diff -u -r1.91.2.18.2.1 if_bge.c % --- sys/dev/bge/if_bge.c 21 Dec 2006 21:53:54 -0000 1.91.2.18.2.1 % +++ sys/dev/bge/if_bge.c 5 Feb 2007 23:23:29 -0000 % @@ -2645,12 +2648,12 @@ % % /* Note link event. It will be processed by POLL_AND_CHECK_STATUS cmd */ % if (statusword & BGE_STATFLAG_LINKSTATE_CHANGED) % - sc->bge_link_evt++; % + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); % % if (cmd == POLL_AND_CHECK_STATUS) % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || % - sc->bge_link_evt || sc->bge_tbi) % + BGE_STS_BIT(sc, BGE_STS_LINK_EVT) || sc->bge_tbi) % bge_link_upd(sc); I suspected this is the cause of slowness for polling in idle (see previous mail), but since it doesn't do any PCI access directly it should be fast enough. The macros make it unclear that it doesn't do any PCI accesses directly. % @@ -2699,7 +2702,7 @@ % % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || % - statusword || sc->bge_link_evt) % + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) % bge_link_upd(sc); % % if (ifp->if_drv_flags & IFF_DRV_RUNNING) { The software link status handling causes a problem in the interrupt handler. To avoid pessimizing the case of shared interrupts, the interrupt handler should be able to read the status word from the status block and return without doing anything if the interrupt is not for it. This can be done without acquiring the driver lock (since the driver lock is neither necessary nor sufficient for accessing the status block). Software link status gets in the way of this, since accessing it requires the driver lock. (Note that `statusword' in the above is now bogusly named. It used to be the status word from the status block but is now the mac status for a PCI register. It is still from the status block in similar code in bge_poll(). Not pessimizing the case of shared interrupts requires using the status block again, and then the read from the PCI register might become a dummy.) Elsewhere, you added code to force interrupt after link status changes. I think this is to get the interrupt handler to look at the software link status in the above. When I first saw it, I thought that forcing an interrupt is needed in more places. There are also complications to work around hardware bugs in reporting the link status. Maybe the complications can be avoided by pushing them to the tick routine. My version doesn't worry about them except in a commment and returns early without locking if the status block doesn't claim to have been updated. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 15:41:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DC6D16A408 for ; Tue, 6 Feb 2007 15:41:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4607613C4A5 for ; Tue, 6 Feb 2007 15:41:31 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 5C4DB1A9044 for ; Tue, 6 Feb 2007 10:41:30 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 06 Feb 2007 10:41:30 -0500 X-Sasl-enc: MfsOjrJVLF1S+ZJDfQqnFapcmNv3c/WiEj1q+BQk9WRl 1170776490 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C93A031FD8; Tue, 6 Feb 2007 10:41:29 -0500 (EST) Message-ID: <45C8A1A9.5000806@FreeBSD.org> Date: Tue, 06 Feb 2007 15:41:29 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Bruce M Simpson References: <45C3CAD7.8040704@incunabulum.net> In-Reply-To: <45C3CAD7.8040704@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] tun(4) does not clean up after itself 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, 06 Feb 2007 15:41:31 -0000 This change has now been committed on -CURRENT (reviewed by bz@) so it is now settling in. From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 20:43:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBCA916A402 for ; Tue, 6 Feb 2007 20:43:56 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id C65F813C4BA for ; Tue, 6 Feb 2007 20:43:56 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id A115710BBD90; Tue, 6 Feb 2007 12:18:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3 Received: from [192.168.1.101] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 558B710BBCF9 for ; Tue, 6 Feb 2007 12:18:50 -0800 (PST) Message-ID: <45C8E2A2.9040204@sk1llz.net> Date: Tue, 06 Feb 2007 12:18:42 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues 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, 06 Feb 2007 20:43:56 -0000 It was suggested I post this to freebsd-net rather than isp and questions to get a different caliber of replies, here goes; I've been running some tests with using FreeBSD to filter and rate limit traffic. My first thoughts were to goto the latest stable release, which was 6.1 at the time. I've since done the same test under 6.2 and haven't seen any difference. I later migrated to running 4.11 to get away from these issues, but have discovered others. I've tested on an AMD 3200+ system with dual Intel 1000 series NICs, an AMD Opteron 165 with the same, and a Xeon 2.8 with the same. I've used both stock and intel drivers. 6.x; Normal traffic isn't a problem. The second you get into the realm of abusive traffic, such a DoS/DDoS (over 100mbps) UDP floods the machine falls over. Little packets with ip lengths of 28-29 bytes seem to do the most damage. I've tried playing with various sysctl values and have seen no difference at all. By "falls over" I mean "stops sending all traffic in any direction". TCP syn packets have the same effect, tho not quite as rapidly (200~230mbps). I then tried moving filtering off to a transparent bridge. This improved the situation somewhat, but an extra 30-40mbps of UDP data and it would ultimately crumble. Overall the machine would be able to move between 300k-600k PPS before becoming a cripple, depending on packet length, protocol, and any flags. Without a specific pf or ipfw rule to deal with a packet the box would fall over, with specific block rules it would manage an extra 30-40mbps and then fall over. 4.11; Again, normal traffic isn't a problem. When routing & filtering on the same system some of the problems found in 6.x are still apparent, but to a lesser degree. Splitting the task into a transparent filtering bridge with a separate routing box appears to clear it up entirely. UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). TCP syn attacks are also better handled, again a block rule makes it seem as if there were no attack at all. The system also appears to be able to move 800-900k PPS of any one protocol at a time. However, the second you try and queue abusive traffic the machine will fall over. Inbound floods appear to cause ALL inbound traffic to lag horrifically (while rate limiting/piping), which inherently causes a lot of outbound loss due to broken TCP. Now, I'm not sure if this is something to do with dummynet being horribly inefficient, or if there's some sysctl value to deal with inbound that I'm missing. I suppose my concerns are two-fold. Why is 6.x collapsing under traffic that 4.11 could easily block and run merrily along with, and is there a queueing mechanism in place that doesn't tie up the box so much on inbound flows that it ignores all other relevant traffic? (as a note, all tests were done with device polling enabled. Without it systems fall over pretty quickly. I also tried tests using 3com cards and had the same results) In the event anybody is looking for basic errors, device polling is enabled and running at 4000 hz, which has proved to net the highest thruput in PPS. ADAPTIVE_GIANT is on, all the other monitoring features are disabled, and here are my sysctl modifications related to networking (if there's something glaring let me know!); kern.polling.enable=1 kern.polling.burst_max=1000 kern.polling.each_burst=80 kern.polling.idle_poll=1 kern.polling.user_frac=20 kern.polling.reg_frac=50 net.inet.tcp.recvspace=262144 net.inet.tcp.sendspace=262144 kern.ipc.maxsockbuf=1048576 net.inet.tcp.always_keepalive=1 net.inet.ip.portrange.first=10000 kern.ipc.somaxconn=65535 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=30 net.inet.ip.forwarding=1 net.inet.ip.portrange.randomized=0 net.inet.udp.checksum=0 net.inet.udp.recvspace=8192 (I've tried large and small, thinking perhaps I was fulling up buffers on udp floods and then causing it to drop tcp, there appears to be no difference) net.inet.ip.intr_queue_maxlen=512 net.inet.tcp.delayed_ack=0 net.inet.tcp.rfc1323=1 net.inet.tcp.newreno=0 (I'd try this, but, the biggest problem is still with UDP, and I'd prefer something compatible with everything for now) net.inet.tcp.delacktime=10 net.inet.tcp.msl=2500 net.inet.ip.rtmaxcache=1024 net.inet.raw.recvspace=262144 net.inet.ip.dummynet.hash_size=512 net.inet.ip.fw.dyn_ack_lifetime=30 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=10 net.inet.ip.fw.dyn_max=16192 net.link.ether.bridge.enable=0 (or 1 on when setup to bridge, obviously) net.inet.ip.fastforwarding=1 From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 21:12:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0C5016A402 for ; Tue, 6 Feb 2007 21:12:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6A08A13C4B5 for ; Tue, 6 Feb 2007 21:12:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 5CEBB1CCC3; Tue, 6 Feb 2007 21:43:14 +0100 (CET) Date: Tue, 6 Feb 2007 21:43:14 +0100 From: Ed Schouten To: freebsd-net@freebsd.org Message-ID: <20070206204314.GB27282@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J9YdZykiGPT3Jhx7" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: shigeaki@se.hiroshima-u.ac.jp, rink@stack.nl Subject: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 06 Feb 2007 21:12:57 -0000 --J9YdZykiGPT3Jhx7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, When we (Rink and I) ported FreeBSD to the Xbox, Rink patched the kernel to allow the nve(4) driver to attach properly. I recently removed the dust from my Xbox and installed FreeBSD on it. This time I started using the nfe(4) driver. When compared to the nve(4) driver, the nfe(4) seems a lot faster (and not as interrupt-hungry). I did have some issues with it, however. When the machine boots, I often have to plug out/in the network cable before I get a link. My switch, a HP2626, sometimes temporarily shuts down the port with the message: FFI: port 9-Excessive CRC/alignment errors. See help. Because the issues seemed more link-related, I tried looking at the phy code. After booting my machine with bootverbose, it seems I had an ICS1893 PHY, using the ukphy(4) driver. NetBSD has a driver for it, called icsphy(4). I decided to port it to FreeBSD. Porting was quite easy. Just smack the C file in the tree and edit it until it compiles. I had some problems at first, because even with the icsphy(4) driver I didn't get a link. I discovered that the BMSR register kept returning BMSR_ISO, until I unplugged the cable. I added MIIF_NOISOLATE to the mii_flags and voila: it works. I can now boot my Xbox without plugging around all the time. The CRC/alignment errors have also vanished. http://g-rave.nl/junk/freebsd-icsphy.diff Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --J9YdZykiGPT3Jhx7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFyOhi52SDGA2eCwURAkggAJ9WPbUAycUHVk/JoUraX673bu3PWwCdEFU+ /jIABAOhNZo7RtSeO/kiNJo= =sG+M -----END PGP SIGNATURE----- --J9YdZykiGPT3Jhx7-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 21:14:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9307F16A402 for ; Tue, 6 Feb 2007 21:14:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 77B3A13C4B8 for ; Tue, 6 Feb 2007 21:14:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 06 Feb 2007 12:37:45 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4A61B125B34; Tue, 6 Feb 2007 13:00:04 -0800 (PST) Message-ID: <45C8EC53.8020803@elischer.org> Date: Tue, 06 Feb 2007 13:00:03 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Justin Robertson References: <45C8E2A2.9040204@sk1llz.net> In-Reply-To: <45C8E2A2.9040204@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues 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, 06 Feb 2007 21:14:28 -0000 Justin Robertson wrote: > > Splitting the task into a transparent filtering bridge > with a separate routing box appears to clear it up entirely. how does that differ from using mac level ipfw? i.e. turning on filtering at the NIC (layer 2). (have you tried doing that?) From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 21:27:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7674816A401 for ; Tue, 6 Feb 2007 21:27:58 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id D497513C48E for ; Tue, 6 Feb 2007 21:27:57 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 86E1DD4C5E; Tue, 6 Feb 2007 22:08:11 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MISpODnIgcBZ; Tue, 6 Feb 2007 22:08:02 +0100 (CET) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id F3E2BD4C5B; Tue, 6 Feb 2007 22:08:01 +0100 (CET) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l16L81uH043845; Tue, 6 Feb 2007 22:08:01 +0100 (CET) (envelope-from rink) Date: Tue, 6 Feb 2007 22:08:01 +0100 From: Rink Springer To: Ed Schouten Message-ID: <20070206210801.GA99390@rink.nu> References: <20070206204314.GB27282@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <20070206204314.GB27282@hoeg.nl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org, shigeaki@se.hiroshima-u.ac.jp, rink@stack.nl Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 06 Feb 2007 21:27:58 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi people, On Tue, Feb 06, 2007 at 09:43:14PM +0100, Ed Schouten wrote: > http://g-rave.nl/junk/freebsd-icsphy.diff I'll take a look at this; I've noticed mostly timeouts on the nfe(4) interface which could be attributed to this fact. Thank you for your work; whenever I find a working IDE disk for my XBOX, you'll hear from me ... --=20 Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya --FCuugMFkClbJLl1L Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIJawYJKoZIhvcNAQcCoIIJXDCCCVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuIwggObMIIDBKADAgECAhAiuN7bs9pg6t3I0n6G5OOTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjExMDgwOTI2 NTNaFw0wNzExMDgwOTI2NTNaMIHSMREwDwYDVQQEEwhTcHJpbmdlcjEaMBgGA1UEKhMRUmlu ayBQZXRlciBXeWNoZXIxIzAhBgNVBAMTGlJpbmsgUGV0ZXIgV3ljaGVyIFNwcmluZ2VyMRsw GQYJKoZIhvcNAQkBFgxtYWlsQHJpbmsubnUxHzAdBgkqhkiG9w0BCQEWEHJpbmtAZnJlZWJz ZC5vcmcxIDAeBgkqhkiG9w0BCQEWEXJpbmtAaWwuZm9udHlzLm5sMRwwGgYJKoZIhvcNAQkB Fg1yaW5rQHN0YWNrLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryGDfel YzzENX7wodkbVY1NALfaiPfNEG10YjD8ZWdK9zkN26Tc878Shbqapq0KYFD8TACGfEhKoMvo qbf0PHAS/gNYr81Arqa9FRPUfzvtDE/cMbhvI+p7ufBITyYnPJp9MUD72iT+DohRR2ISVi3i NAEgDuSbYYNxctnvXqU6O6EPy3mzoFPDoiOQwBfVtFrjxBbND9BUK2bjtUyGt4x8I/Vulzrt qLPTokva+b97DHRgbCA/aLLYIrU6QoqOFJ8GrAbro/FZLYh4m1oJk3FEHVQOKkk7xzIaFmmP QGJRL8m6nrIZFTrQ+X2wmzfLD55K/UiqbekOuMiWbY9EbwIDAQABo10wWzBLBgNVHREERDBC gQxtYWlsQHJpbmsubnWBEHJpbmtAZnJlZWJzZC5vcmeBEXJpbmtAaWwuZm9udHlzLm5sgQ1y aW5rQHN0YWNrLm5sMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAIfIcieRjePBA wjZqvOdGpyPcNDnK/ubeQSTV5Y4AHWxm1sXhQxB/XrQ3RVdz1qDnBRL1AjkEBAl8e9+am4s6 D6TaSlmJeNXn6ZPJTQecisz3M+AKiMckShM3oAeUi0ktn1yNYR+hz5aQN612XT5OZRYznJVZ kPf1DiA2RVVyz+MwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYICUTCCAk0CAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECK43tuz2mDq3cjS fobk45MwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzAyMDYyMTA4MDFaMCMGCSqGSIb3DQEJBDEWBBRnKhKOUo8bzQSMIJDtv9v4 LpNrBjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBQ +t8y2nelBR5gnujz9DyWM5IiACSvdAEGlh5BET6HSXbnNPN86rvCKOOxoMjfjHo4iYgyWf2D jKK+o27x8zHKeO5M+S2cw+wT9MldlfH1v9SlknNbwylF8P+c8YVrsT0knNLhxDceMU7R9ZSb wOCecfGLAhuSB5VIeYTS9hSIkLEp9G8CS3g9d5A8AeXCuhc2n5ayaWkc0mOZX0nks03GMVN5 1RftemCXf30c7KTJ4fA+d4exEkyGbQmjhtnUDI6c746oFMfnidkIZMaZDTVoVidIEL0iWoZ5 4mQza1+e35+HX9LIbxaiGySpWtS/Py6wHri2OaemWq0PHP/Ya1eI --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 21:29:49 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97D3C16A402 for ; Tue, 6 Feb 2007 21:29:49 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx1.nttmcl.com (mx1.nttmcl.com [216.69.64.132]) by mx1.freebsd.org (Postfix) with ESMTP id 65A1A13C4A8 for ; Tue, 6 Feb 2007 21:29:49 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from [216.69.70.37] (ramen.nttmcl.com [216.69.70.37]) by mx1.nttmcl.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l16LTisA027827; Tue, 6 Feb 2007 13:29:46 -0800 Message-ID: <45C8F348.8000708@ab.ote.we.lv> Date: Tue, 06 Feb 2007 13:29:44 -0800 From: "Eugene M. Kim" User-Agent: Thunderbird 1.5.0.8 (X11/20061130) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <45C7D251.8060004@ab.ote.we.lv> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mx1.nttmcl.com Cc: net@freebsd.org Subject: Re: rtadvd(8) and deprecated prefixes 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, 06 Feb 2007 21:29:49 -0000 Jinmei-san, Thank you for the response. What I wonder is how one would define the "typical, default" case. Although RFC 2461/2462 does not say much about it, I am having a hard time seeing in which case it would be beneficial to advertise deprecated prefixes as preferred by default. On the other hand, it does break the case where automated, or configuration-free, router renumbering is used in combination with a gradual renumbering procedure, e.g. one described in RFC 4192, which was in fact what I was trying to put into test on my home router :-p. If the router were instructed to wait until completion of all sessions using the old prefix before removing it (RFC 4192, sections 2.6.2 and 2.7), it might have to wait indefinitely as hosts keep creating new connections because the hosts never see the old prefix as deprecated; even if the router were instructed to remove the prefix after a planned grace period, there would be much more hard communication failures stemming from broken connections because of the apparent lack of grace period (from hosts' POV). For these reasons, I believe it is more sensible to define it "typical" for a router to advertise a prefix as deprecated (i.e. with zero pltime) if it sees the prefix is deprecated on the interface. I understand that it is your decision whether the above is an obscure corner case worth little/no support from rtadvd because you are the author ^_^. However RFC 4192 was the (only) v6ops document that I could find about gradual renumbering, so I think it is more than a corner case and is actually worth supporting. Regards, Eugene P.S. While you are on this topic: What problems did the current rrenum code have so that it had to be disabled? I am interested in improving it back into a usable state... JINMEI Tatuya / 神明é”哉 wrote: > I'm pretty sure different people have different opinions on this > matter, but I personally think we should not try to "fix" it. > > This feature originally intended to make rtadvd as much > configuration-free as possible in the most typical cases, that is, all > addresses on the router is configured by hand and the associated > prefixes are advertised with the default parameters defined in > RFC2461. This is because why rtadvd does not allow the administrator > to specify just prefix lifetimes while letting the daemon get the > prefixes from the kernel. So, treating a prefix lifetime of 0 > separately is at least against the original design policy (believe me, > I'm confident because it's me who implemented this:-) > > Also, once we open the Pandora's box, we'll encounter all other > non-default issues that beg customized behavior or require detailed > considerations on corner cases. One example is to allow the user to > specify the lifetimes (without specifying prefixes). We might also > want to have rtadvd follow decreasing lifetimes in real time. Others > may want to restrict the advertised prefixes to some subset of ones > retrieved from the routing table, etc, etc. > > So, (again) I'd personally keep the current feature and requires the > administrator to configure the router explicitly to handle any > non-default cases. (If we agree on that) we may have to note in the > man page about the implementation policy, though. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 22:19:02 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8083D16A400 for ; Tue, 6 Feb 2007 22:19:02 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id E93DA13C428 for ; Tue, 6 Feb 2007 22:19:00 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l16MIxJD067499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Feb 2007 01:18:59 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l16MIvDA067498; Wed, 7 Feb 2007 01:18:57 +0300 (MSK) (envelope-from oleg) Date: Wed, 7 Feb 2007 01:18:57 +0300 From: Oleg Bulyzhin To: Bruce Evans Message-ID: <20070206221857.GA66675@lath.rinet.ru> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> <20070207003539.I31484@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207003539.I31484@besplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Robin Gruyters , freebsd-net@FreeBSD.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 06 Feb 2007 22:19:02 -0000 On Wed, Feb 07, 2007 at 01:31:39AM +1100, Bruce Evans wrote: > On Tue, 6 Feb 2007, Oleg Bulyzhin wrote: > > >Sorry for the late reply - i was AFK for some time and didnt read mails. > >Patch against 6.2R attached, please let me know does it helps or not. > > I didn't test the old version of this since I have too many local changes > in my non-6.x versions. I might test the 6.x version. > > I use jdp's quicker fix. It works fine for detecting cable unplug > and replug, but link detection is still very bad at boot time and > after down/up (seems to be worse for down/up than unplug/replug?). > Link detection in -current generally seems to be much worse than > in 5.2. On some systems I use two ping -c2's early in the boot to > wait for the link to actually be up. The first ping tends to fail > and the second tends to work, both long after the lonk claims to > be up. Then other network activity still takes too long to start. > Without the pings, an "ntpdate -b" early in the boot fails about > half the time and gives messed up timing activity when it fails, > and initial nfs mounts tak 30-60 seconds. Later after down/up and > waiting for the "up" message, ttcp -u usually fails to connect the > first time and then works normally with no failure or connection > delay the second time. Could you please give some more details? I'm intersted in: - chip version - are you using 'auto' media or fixed one? - have you tried verbose boot? (MAC's link state (bge_link) reported with it). - is there recipe how to trigger erroneous behaviour? i'll try it on mine bge cards. (i have bcm5721 5700 & 5701, but i didnt notice errors in link handling with -current driver (and i had problems with 5.x driver)) The fact 'ping' workaround does help looks like lost interrupt. > > % Index: sys/dev/bge/if_bgereg.h > % =================================================================== > % RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v > % retrieving revision 1.36.2.8.2.1 > % diff -u -r1.36.2.8.2.1 if_bgereg.h > % --- sys/dev/bge/if_bgereg.h 21 Dec 2006 21:53:54 -0000 1.36.2.8.2.1 > % +++ sys/dev/bge/if_bgereg.h 5 Feb 2007 23:23:22 -0000 > % @@ -2460,8 +2460,13 @@ > % uint32_t bge_tx_buf_ratio; > % int bge_if_flags; > % int bge_txcnt; > % - int bge_link; /* link state */ > % - int bge_link_evt; /* pending link event */ > % + uint32_t bge_sts; > % +#define BGE_STS_LINK 0x00000001 /* MAC link status */ > % +#define BGE_STS_LINK_EVT 0x00000002 /* pending link > event */ > % +#define BGE_STS_AUTOPOLL 0x00000004 /* PHY auto-polling > */ > % +#define BGE_STS_BIT(sc, x) ((sc)->bge_sts & (x)) > % +#define BGE_STS_SETBIT(sc, x) ((sc)->bge_sts |= (x)) > % +#define BGE_STS_CLRBIT(sc, x) ((sc)->bge_sts &= ~(x)) > > Style bugs: > - inconsistents tabs. bge mostly consitently doesn't follow KNF for the > tab after #define. mea culpa. > - I don't like obfuscating bit testing and setting using macros. The > above macros are quite different from the BGE and PCI SETBIT and CLRBIT > macros -- the latter operate on hardware bits and do something useful > by hiding the details of the hardware accesses, and aren't assoicated > with bit testing macros. Apart from the above, testing of hardware bits > and testing an setting of software bits is always done using direct > "&" and "|" operations in bge. I'm going to agree with you. (I was hesitating about using macros here and your arguments look reasonable.) > > % Index: sys/dev/bge/if_bge.c > % =================================================================== > % RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > % retrieving revision 1.91.2.18.2.1 > % diff -u -r1.91.2.18.2.1 if_bge.c > % --- sys/dev/bge/if_bge.c 21 Dec 2006 21:53:54 -0000 1.91.2.18.2.1 > % +++ sys/dev/bge/if_bge.c 5 Feb 2007 23:23:29 -0000 > % @@ -2645,12 +2648,12 @@ > % > % /* Note link event. It will be processed by POLL_AND_CHECK_STATUS > cmd */ > % if (statusword & BGE_STATFLAG_LINKSTATE_CHANGED) > % - sc->bge_link_evt++; > % + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); > % > % if (cmd == POLL_AND_CHECK_STATUS) > % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && > % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || > % - sc->bge_link_evt || sc->bge_tbi) > % + BGE_STS_BIT(sc, BGE_STS_LINK_EVT) || sc->bge_tbi) > % bge_link_upd(sc); > > I suspected this is the cause of slowness for polling in idle (see previous > mail), but since it doesn't do any PCI access directly it should be fast > enough. > The macros make it unclear that it doesn't do any PCI accesses > directly. Agree. > > % @@ -2699,7 +2702,7 @@ > % > % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && > % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || > % - statusword || sc->bge_link_evt) > % + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) > % bge_link_upd(sc); > % > % if (ifp->if_drv_flags & IFF_DRV_RUNNING) { > > The software link status handling causes a problem in the interrupt > handler. To avoid pessimizing the case of shared interrupts, the > interrupt handler should be able to read the status word from the > status block and return without doing anything if the interrupt is not > for it. This can be done without acquiring the driver lock (since the > driver lock is neither necessary nor sufficient for accessing the > status block). Software link status gets in the way of this, since > accessing it requires the driver lock. You are right, but at the moment, bge_intr() is locked and does not care about shared interrupts. If we are going to fix this i would vote for using taskqueue api - in this case we can test 'link event' flag inside locked taskqueue thread. >(Note that `statusword' in the > above is now bogusly named. It used to be the status word from the > status block but is now the mac status for a PCI register. It is still > from the status block in similar code in bge_poll(). Not pessimizing > the case of shared interrupts requires using the status block again, > and then the read from the PCI register might become a dummy.) We can not avoid pci register read before syncing status block - we should flush data posted at pci bridge, otherwise we can 'miss' interrupt. > > Elsewhere, you added code to force interrupt after link status changes. > I think this is to get the interrupt handler to look at the software > link status in the above. When I first saw it, I thought that forcing > an interrupt is needed in more places. Forced interrupt used for TBI cards since they do not have PHY auto-polling. > > There are also complications to work around hardware bugs in reporting > the link status. Maybe the complications can be avoided by pushing > them to the tick routine. My version doesn't worry about them except > in a commment and returns early without locking if the status block > doesn't claim to have been updated. > > Bruce -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 00:27:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3847716A412 for ; Wed, 7 Feb 2007 00:27:23 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id 14A7B13C4E5 for ; Wed, 7 Feb 2007 00:27:22 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id D324210BBE4F; Tue, 6 Feb 2007 16:27:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3 Received: from [192.168.1.101] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 7777710BBCF9 for ; Tue, 6 Feb 2007 16:27:20 -0800 (PST) Message-ID: <45C91CDF.7000509@sk1llz.net> Date: Tue, 06 Feb 2007 16:27:11 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45C8E2A2.9040204@sk1llz.net> <45C8EC53.8020803@elischer.org> In-Reply-To: <45C8EC53.8020803@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues 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, 07 Feb 2007 00:27:23 -0000 Err, forgot to reply to -net, at anyrate, layer 2 isn't useful as it doesn't undertand ip addresses, ports, protocols, etc. Julian Elischer wrote: > Justin Robertson wrote: >> > > > >> Splitting the task into a transparent filtering bridge with a >> separate routing box appears to clear it up entirely. > > how does that differ from using mac level ipfw? > > i.e. turning on filtering at the NIC (layer 2). > > (have you tried doing that?) > From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 00:37:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 194B416A403 for ; Wed, 7 Feb 2007 00:37:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id B6E2013C461 for ; Wed, 7 Feb 2007 00:37:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so50623nzh for ; Tue, 06 Feb 2007 16:37:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ikOh20vDj/Pjp2lWxKGVcSi2EcFjvuCsCWtkNCJm/eQnej0xLYP4y5ubAjiKu98PYqDvo10zMPd+AgsgHm2sL6Tv0Bt5AKSHEyZoRk3QogEh4rZX6aV253hlYetxxnzVu9AaA7ADJOYx43xnVr0K7Qlr0J0euhRWQusg/Q537f4= Received: by 10.35.60.15 with SMTP id n15mr13768778pyk.1170808647710; Tue, 06 Feb 2007 16:37:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 39sm834846nzk.2007.02.06.16.37.25; Tue, 06 Feb 2007 16:37:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l170c3BM038158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Feb 2007 09:38:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l170buDO038157; Wed, 7 Feb 2007 09:37:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 7 Feb 2007 09:37:56 +0900 From: Pyun YongHyeon To: Ed Schouten Message-ID: <20070207003756.GA37911@cdnetworks.co.kr> References: <20070206204314.GB27282@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070206204314.GB27282@hoeg.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, shigeaki@se.hiroshima-u.ac.jp, rink@stack.nl Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@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, 07 Feb 2007 00:37:34 -0000 On Tue, Feb 06, 2007 at 09:43:14PM +0100, Ed Schouten wrote: > Hello, > > When we (Rink and I) ported FreeBSD to the Xbox, Rink patched the kernel > to allow the nve(4) driver to attach properly. I recently removed the > dust from my Xbox and installed FreeBSD on it. This time I started using > the nfe(4) driver. > > When compared to the nve(4) driver, the nfe(4) seems a lot faster (and > not as interrupt-hungry). I did have some issues with it, however. When Would you try overhauled nfe(4)? http://people.freebsd.org/~yongari/nfe/if_nfe.c http://people.freebsd.org/~yongari/nfe/if_nfereg.c http://people.freebsd.org/~yongari/nfe/if_nfevar.c The new nfe(4) should perform better than nve(4) or stock nfe(4). I'm still not satisfied with its excessive generation of interrtups but it's better than stock nfe(4). After switching to adaptive polling I saw noticeable performance boost. If you find any issues please let me know. > the machine boots, I often have to plug out/in the network cable before > I get a link. My switch, a HP2626, sometimes temporarily shuts down the > port with the message: > > FFI: port 9-Excessive CRC/alignment errors. See help. > > Because the issues seemed more link-related, I tried looking at the phy > code. After booting my machine with bootverbose, it seems I had an > ICS1893 PHY, using the ukphy(4) driver. NetBSD has a driver for it, > called icsphy(4). I decided to port it to FreeBSD. > > Porting was quite easy. Just smack the C file in the tree and edit it > until it compiles. I had some problems at first, because even with the > icsphy(4) driver I didn't get a link. I discovered that the BMSR > register kept returning BMSR_ISO, until I unplugged the cable. I added > MIIF_NOISOLATE to the mii_flags and voila: it works. > > I can now boot my Xbox without plugging around all the time. The > CRC/alignment errors have also vanished. > > http://g-rave.nl/junk/freebsd-icsphy.diff > > Yours, > -- > Ed Schouten > WWW: http://g-rave.nl/ -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 02:14:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9AE8A16A402 for ; Wed, 7 Feb 2007 02:14:13 +0000 (UTC) (envelope-from www-data@alpha.web.expressmedia.de) Received: from mailrelay.int.expressmedia.de (mailrelay.int.expressmedia.de [212.12.114.18]) by mx1.freebsd.org (Postfix) with ESMTP id 542E913C474 for ; Wed, 7 Feb 2007 02:14:12 +0000 (UTC) (envelope-from www-data@alpha.web.expressmedia.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay.int.expressmedia.de (Postfix) with ESMTP id D9BEE128A80 for ; Wed, 7 Feb 2007 02:43:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailrelay.web.expressmedia.de Received: from mailrelay.int.expressmedia.de ([127.0.0.1]) by localhost (mailrelay.web.expressmedia.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MK55k4cUCcc for ; Wed, 7 Feb 2007 02:43:16 +0100 (CET) Received: from alpha.web.expressmedia.de (alpha.mail-out2.expressmedia.de [212.12.114.36]) by mailrelay.int.expressmedia.de (Postfix) with ESMTP for ; Wed, 7 Feb 2007 02:43:11 +0100 (CET) Received: from alpha.web.expressmedia.de (localhost.localdomain [127.0.0.1]) by alpha.web.expressmedia.de (8.13.4/8.13.4/Debian-3) with ESMTP id l171gOL9026987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Feb 2007 02:42:24 +0100 Received: (from www-data@localhost) by alpha.web.expressmedia.de (8.13.4/8.13.4/Submit) id l171gOt3026956; Wed, 7 Feb 2007 02:42:24 +0100 Date: Wed, 7 Feb 2007 02:42:24 +0100 Message-Id: <200702070142.l171gOt3026956@alpha.web.expressmedia.de> To: freebsd-net@freebsd.org From: Mou Xinsheng MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Subject: # Money X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fufeng_beijing@yahoo.com.hk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 02:14:16 -0000 Hello, I want to solicit your attention to recieve money on my behalf. The purpose of my contacting you is because you live in western world. When you reply this message,i will send you the full details and more information about myself and the funds. My personal email is: fufeng_beijing@yahoo.com.hk Thank you. Mou Xinsheng. From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 02:24:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E733816A402 for ; Wed, 7 Feb 2007 02:24:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id C189413C4B5 for ; Wed, 7 Feb 2007 02:24:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 06 Feb 2007 18:02:29 -0800 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id AB162125B04; Tue, 6 Feb 2007 18:24:50 -0800 (PST) Message-ID: <45C93872.8050100@elischer.org> Date: Tue, 06 Feb 2007 18:24:50 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Justin Robertson References: <45C8E2A2.9040204@sk1llz.net> <45C8EC53.8020803@elischer.org> <45C91CDF.7000509@sk1llz.net> In-Reply-To: <45C91CDF.7000509@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues 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, 07 Feb 2007 02:24:54 -0000 Justin Robertson wrote: > Err, forgot to reply to -net, at anyrate, layer 2 isn't useful as it > doesn't undertand ip addresses, ports, protocols, etc. filtereing at the NIC (sysctl net.link.ether.ipfw=1 or something similar) lets you do layer 3 filtereing at the NIC layer.. > > Julian Elischer wrote: >> Justin Robertson wrote: >>> >> >> >> >>> Splitting the task into a transparent filtering bridge with a >>> separate routing box appears to clear it up entirely. >> >> how does that differ from using mac level ipfw? >> >> i.e. turning on filtering at the NIC (layer 2). >> >> (have you tried doing that?) >> > > _______________________________________________ > 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 7 02:52:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 346AC16A500 for ; Wed, 7 Feb 2007 02:52:52 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1D08A13C4A7 for ; Wed, 7 Feb 2007 02:52:52 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id EB39010BBE4F; Tue, 6 Feb 2007 18:52:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3 Received: from [192.168.1.101] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id BDE3F10BBCF9; Tue, 6 Feb 2007 18:52:49 -0800 (PST) Message-ID: <45C93EF8.4040204@sk1llz.net> Date: Tue, 06 Feb 2007 18:52:40 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Julian Elischer , freebsd-net@freebsd.org References: <45C8E2A2.9040204@sk1llz.net> <45C8EC53.8020803@elischer.org> <45C91CDF.7000509@sk1llz.net> <45C93872.8050100@elischer.org> In-Reply-To: <45C93872.8050100@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues 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, 07 Feb 2007 02:52:53 -0000 So in a sense I should be able to do away with the transparent bridge. However, 6.x in any mode (bridge or not) was still incapable of pushing the traffic that 4.x could. This would certainly help remove one machine from the mix, but still requires running 4.x to get any real performance. :-\ Julian Elischer wrote: > Justin Robertson wrote: >> Err, forgot to reply to -net, at anyrate, layer 2 isn't useful as it >> doesn't undertand ip addresses, ports, protocols, etc. > > filtereing at the NIC (sysctl net.link.ether.ipfw=1 or something > similar) lets you do layer 3 filtereing at the NIC layer.. > >> >> Julian Elischer wrote: >>> Justin Robertson wrote: >>>> >>> >>> >>> >>>> Splitting the task into a transparent filtering bridge with a >>>> separate routing box appears to clear it up entirely. >>> >>> how does that differ from using mac level ipfw? >>> >>> i.e. turning on filtering at the NIC (layer 2). >>> >>> (have you tried doing that?) >>> >> >> _______________________________________________ >> 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 7 03:01:49 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D6CB16A412 for ; Wed, 7 Feb 2007 03:01:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id D3E7313C49D for ; Wed, 7 Feb 2007 03:01:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C67F61A9184 for ; Tue, 6 Feb 2007 22:01:43 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 06 Feb 2007 22:01:43 -0500 X-Sasl-enc: xNxJALfHlzwhvTTjYAMP7G0sysg+vn5svF6dD0Z65z6+ 1170817303 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2D25B29376 for ; Tue, 6 Feb 2007 22:01:42 -0500 (EST) Message-ID: <45C94116.3090404@FreeBSD.org> Date: Wed, 07 Feb 2007 03:01:42 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org References: <45C39CBF.7010105@incunabulum.net> In-Reply-To: <45C39CBF.7010105@incunabulum.net> Content-Type: multipart/mixed; boundary="------------040700060803040801030400" Cc: Subject: Re: Proposal: remove encap from MROUTING 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, 07 Feb 2007 03:01:49 -0000 This is a multi-part message in MIME format. --------------040700060803040801030400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I count no objections and +1 in favour from Andre. To maintain POLA, I will decapitate (Argh, pun) it from HEAD with no MFC to begin with. Arguments in favour: * mrouted was removed from the base system. * PIM does not use MROUTING's IPIP tunnels, and PIM is regarded as the standard these days for multicast routing. * MROUTING's internal tunnels do not have any management capabilities; gif(4) has. * It achieves some diff reduction with OpenBSD. * Reduces locking/netisr fandango. * The MROUTING paths could do with some overall cleanup anyway, and it doesn't seem appropriate to merge back such work, except as a backport. I plan to commit this patch some time this week. Regards, BMS --------------040700060803040801030400 Content-Type: text/x-patch; name="mroute-notunnels.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mroute-notunnels.diff" Index: ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.122 diff -u -p -r1.122 ip_mroute.c --- ip_mroute.c 6 Nov 2006 13:42:04 -0000 1.122 +++ ip_mroute.c 7 Feb 2007 02:57:07 -0000 @@ -181,33 +181,7 @@ static struct callout expire_upcalls_ch; static struct tbf tbftable[MAXVIFS]; #define TBF_REPROCESS (hz / 100) /* 100x / second */ -/* - * 'Interfaces' associated with decapsulator (so we can tell - * packets that went through it from ones that get reflected - * by a broken gateway). These interfaces are never linked into - * the system ifnet list & no routes point to them. I.e., packets - * can't be sent this way. They only exist as a placeholder for - * multicast source verification. - */ -static struct ifnet multicast_decap_if[MAXVIFS]; - #define ENCAP_TTL 64 -#define ENCAP_PROTO IPPROTO_IPIP /* 4 */ - -/* prototype IP hdr for encapsulated packets */ -static struct ip multicast_encap_iphdr = { -#if BYTE_ORDER == LITTLE_ENDIAN - sizeof(struct ip) >> 2, IPVERSION, -#else - IPVERSION, sizeof(struct ip) >> 2, -#endif - 0, /* tos */ - sizeof(struct ip), /* total length */ - 0, /* id */ - 0, /* frag offset */ - ENCAP_TTL, ENCAP_PROTO, - 0, /* checksum */ -}; /* * Bandwidth meter variables and constants @@ -287,14 +261,6 @@ static vifi_t reg_vif_num = VIFI_INVALID * Private variables. */ static vifi_t numvifs; -static const struct encaptab *encap_cookie; - -/* - * one-back cache used by mroute_encapcheck to locate a tunnel's vif - * given a datagram's src ip address. - */ -static u_long last_encap_src; -static struct vif *last_encap_vif; /* * Callout for queue processing. @@ -325,7 +291,6 @@ static int set_assert(int); static void expire_upcalls(void *); static int ip_mdq(struct mbuf *, struct ifnet *, struct mfc *, vifi_t); static void phyint_send(struct ip *, struct vif *, struct mbuf *); -static void encap_send(struct ip *, struct vif *, struct mbuf *); static void tbf_control(struct vif *, struct mbuf *, struct ip *, u_long); static void tbf_queue(struct vif *, struct mbuf *); static void tbf_process_q(struct vif *); @@ -792,14 +757,6 @@ X_ip_mrouter_done(void) ip_mrouter = NULL; mrt_api_config = 0; - VIF_LOCK(); - if (encap_cookie) { - const struct encaptab *c = encap_cookie; - encap_cookie = NULL; - encap_detach(c); - } - VIF_UNLOCK(); - callout_stop(&tbf_reprocess_ch); VIF_LOCK(); @@ -859,8 +816,6 @@ X_ip_mrouter_done(void) /* * Reset de-encapsulation cache */ - last_encap_src = INADDR_ANY; - last_encap_vif = NULL; #ifdef PIM reg_vif_num = VIFI_INVALID; #endif @@ -924,90 +879,6 @@ set_api_config(uint32_t *apival) } /* - * Decide if a packet is from a tunnelled peer. - * Return 0 if not, 64 if so. XXX yuck.. 64 ??? - */ -static int -mroute_encapcheck(const struct mbuf *m, int off, int proto, void *arg) -{ - struct ip *ip = mtod(m, struct ip *); - int hlen = ip->ip_hl << 2; - - /* - * don't claim the packet if it's not to a multicast destination or if - * we don't have an encapsulating tunnel with the source. - * Note: This code assumes that the remote site IP address - * uniquely identifies the tunnel (i.e., that this site has - * at most one tunnel with the remote site). - */ - if (!IN_MULTICAST(ntohl(((struct ip *)((char *)ip+hlen))->ip_dst.s_addr))) - return 0; - if (ip->ip_src.s_addr != last_encap_src) { - struct vif *vifp = viftable; - struct vif *vife = vifp + numvifs; - - last_encap_src = ip->ip_src.s_addr; - last_encap_vif = NULL; - for ( ; vifp < vife; ++vifp) - if (vifp->v_rmt_addr.s_addr == ip->ip_src.s_addr) { - if ((vifp->v_flags & (VIFF_TUNNEL|VIFF_SRCRT)) == VIFF_TUNNEL) - last_encap_vif = vifp; - break; - } - } - if (last_encap_vif == NULL) { - last_encap_src = INADDR_ANY; - return 0; - } - return 64; -} - -/* - * De-encapsulate a packet and feed it back through ip input (this - * routine is called whenever IP gets a packet that mroute_encap_func() - * claimed). - */ -static void -mroute_encap_input(struct mbuf *m, int off) -{ - struct ip *ip = mtod(m, struct ip *); - int hlen = ip->ip_hl << 2; - - if (hlen > sizeof(struct ip)) - ip_stripoptions(m, (struct mbuf *) 0); - m->m_data += sizeof(struct ip); - m->m_len -= sizeof(struct ip); - m->m_pkthdr.len -= sizeof(struct ip); - - m->m_pkthdr.rcvif = last_encap_vif->v_ifp; - - netisr_queue(NETISR_IP, m); /* mbuf is free'd on failure. */ - /* - * normally we would need a "schednetisr(NETISR_IP)" - * here but we were called by ip_input and it is going - * to loop back & try to dequeue the packet we just - * queued as soon as we return so we avoid the - * unnecessary software interrrupt. - * - * XXX - * This no longer holds - we may have direct-dispatched the packet, - * or there may be a queue processing limit. - */ -} - -extern struct domain inetdomain; -static struct protosw mroute_encap_protosw = -{ - .pr_type = SOCK_RAW, - .pr_domain = &inetdomain, - .pr_protocol = IPPROTO_IPV4, - .pr_flags = PR_ATOMIC|PR_ADDR, - .pr_input = mroute_encap_input, - .pr_ctloutput = rip_ctloutput, - .pr_usrreqs = &rip_usrreqs -}; - -/* * Add a vif to the vif table */ static int @@ -1055,42 +926,10 @@ add_vif(struct vifctl *vifcp) ifp = ifa->ifa_ifp; } - if (vifcp->vifc_flags & VIFF_TUNNEL) { - if ((vifcp->vifc_flags & VIFF_SRCRT) == 0) { - /* - * An encapsulating tunnel is wanted. Tell - * mroute_encap_input() to start paying attention - * to encapsulated packets. - */ - if (encap_cookie == NULL) { - int i; - - encap_cookie = encap_attach_func(AF_INET, IPPROTO_IPV4, - mroute_encapcheck, - (struct protosw *)&mroute_encap_protosw, NULL); - - if (encap_cookie == NULL) { - printf("ip_mroute: unable to attach encap\n"); - VIF_UNLOCK(); - return EIO; /* XXX */ - } - for (i = 0; i < MAXVIFS; ++i) { - if_initname(&multicast_decap_if[i], "mdecap", i); - } - } - /* - * Set interface to fake encapsulator interface - */ - ifp = &multicast_decap_if[vifcp->vifc_vifi]; - /* - * Prepare cached route entry - */ - bzero(&vifp->v_route, sizeof(vifp->v_route)); - } else { - log(LOG_ERR, "source routed tunnels not supported\n"); - VIF_UNLOCK(); - return EOPNOTSUPP; - } + if ((vifcp->vifc_flags & VIFF_TUNNEL) != 0) { + log(LOG_ERR, "tunnels are no longer supported\n"); + VIF_UNLOCK(); + return EOPNOTSUPP; #ifdef PIM } else if (vifcp->vifc_flags & VIFF_REGISTER) { ifp = &multicast_register_if; @@ -1179,11 +1018,6 @@ del_vif_locked(vifi_t vifi) if (!(vifp->v_flags & (VIFF_TUNNEL | VIFF_REGISTER))) if_allmulti(vifp->v_ifp, 0); - if (vifp == last_encap_vif) { - last_encap_vif = NULL; - last_encap_src = INADDR_ANY; - } - /* * Free packets queued at the interface */ @@ -1781,9 +1615,7 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp * separate. */ #define MC_SEND(ip,vifp,m) { \ - if ((vifp)->v_flags & VIFF_TUNNEL) \ - encap_send((ip), (vifp), (m)); \ - else \ + if (((vifp)->v_flags & VIFF_TUNNEL) == 0) \ phyint_send((ip), (vifp), (m)); \ } @@ -1968,75 +1800,6 @@ phyint_send(struct ip *ip, struct vif *v tbf_control(vifp, mb_copy, mtod(mb_copy, struct ip *), ip->ip_len); } -static void -encap_send(struct ip *ip, struct vif *vifp, struct mbuf *m) -{ - struct mbuf *mb_copy; - struct ip *ip_copy; - int i, len = ip->ip_len; - - VIF_LOCK_ASSERT(); - - /* Take care of delayed checksums */ - if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { - in_delayed_cksum(m); - m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; - } - - /* - * copy the old packet & pullup its IP header into the - * new mbuf so we can modify it. Try to fill the new - * mbuf since if we don't the ethernet driver will. - */ - MGETHDR(mb_copy, M_DONTWAIT, MT_DATA); - if (mb_copy == NULL) - return; -#ifdef MAC - mac_create_mbuf_multicast_encap(m, vifp->v_ifp, mb_copy); -#endif - mb_copy->m_data += max_linkhdr; - mb_copy->m_len = sizeof(multicast_encap_iphdr); - - if ((mb_copy->m_next = m_copypacket(m, M_DONTWAIT)) == NULL) { - m_freem(mb_copy); - return; - } - i = MHLEN - M_LEADINGSPACE(mb_copy); - if (i > len) - i = len; - mb_copy = m_pullup(mb_copy, i); - if (mb_copy == NULL) - return; - mb_copy->m_pkthdr.len = len + sizeof(multicast_encap_iphdr); - - /* - * fill in the encapsulating IP header. - */ - ip_copy = mtod(mb_copy, struct ip *); - *ip_copy = multicast_encap_iphdr; - ip_copy->ip_id = ip_newid(); - ip_copy->ip_len += len; - ip_copy->ip_src = vifp->v_lcl_addr; - ip_copy->ip_dst = vifp->v_rmt_addr; - - /* - * turn the encapsulated IP header back into a valid one. - */ - ip = (struct ip *)((caddr_t)ip_copy + sizeof(multicast_encap_iphdr)); - --ip->ip_ttl; - ip->ip_len = htons(ip->ip_len); - ip->ip_off = htons(ip->ip_off); - ip->ip_sum = 0; - mb_copy->m_data += sizeof(multicast_encap_iphdr); - ip->ip_sum = in_cksum(mb_copy, ip->ip_hl << 2); - mb_copy->m_data -= sizeof(multicast_encap_iphdr); - - if (vifp->v_rate_limit == 0) - tbf_send_packet(vifp, mb_copy); - else - tbf_control(vifp, mb_copy, ip, ip_copy->ip_len); -} - /* * Token bucket filter module */ @@ -2196,9 +1959,7 @@ tbf_send_packet(struct vif *vifp, struct { VIF_LOCK_ASSERT(); - if (vifp->v_flags & VIFF_TUNNEL) /* If tunnel options */ - ip_output(m, NULL, &vifp->v_route, IP_FORWARDING, NULL, NULL); - else { + if ((vifp->v_flags & VIFF_TUNNEL) == 0) { struct ip_moptions imo; struct in_multi *imm[2]; int error; --------------040700060803040801030400-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 09:11:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9234616A400; Wed, 7 Feb 2007 09:11:19 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4A97F13C4A5; Wed, 7 Feb 2007 09:11:16 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 76BD85A7D1C; Wed, 7 Feb 2007 20:11:14 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id C51388C06; Wed, 7 Feb 2007 20:11:12 +1100 (EST) Date: Wed, 7 Feb 2007 20:11:11 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oleg Bulyzhin In-Reply-To: <20070206221857.GA66675@lath.rinet.ru> Message-ID: <20070207193426.P35180@besplex.bde.org> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> <20070207003539.I31484@besplex.bde.org> <20070206221857.GA66675@lath.rinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robin Gruyters , freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 07 Feb 2007 09:11:19 -0000 On Wed, 7 Feb 2007, Oleg Bulyzhin wrote: > On Wed, Feb 07, 2007 at 01:31:39AM +1100, Bruce Evans wrote: >> I use jdp's quicker fix. It works fine for detecting cable unplug >> and replug, but link detection is still very bad at boot time and >> after down/up (seems to be worse for down/up than unplug/replug?). >> Link detection in -current generally seems to be much worse than >> in 5.2. On some systems I use two ping -c2's early in the boot to >> wait for the link to actually be up. The first ping tends to fail >> and the second tends to work, both long after the lonk claims to >> be up. Then other network activity still takes too long to start. >> Without the pings, an "ntpdate -b" early in the boot fails about >> half the time and gives messed up timing activity when it fails, >> and initial nfs mounts tak 30-60 seconds. Later after down/up and >> waiting for the "up" message, ttcp -u usually fails to connect the >> first time and then works normally with no failure or connection >> delay the second time. > > Could you please give some more details? I'm intersted in: > - chip version 5701 and 5705. > - are you using 'auto' media or fixed one? Auto. > - have you tried verbose boot? (MAC's link state (bge_link) reported with it). Not recently. > - is there recipe how to trigger erroneous behaviour? i'll try it on mine > bge cards. (i have bcm5721 5700 & 5701, but i didnt notice errors in > link handling with -current driver (and i had problems with 5.x driver)) Just boot or down/up. > The fact 'ping' workaround does help looks like lost interrupt. Ah, it could be my returning immediately in bge_intr() if the status block hasn't been updated. This wouldn't notice changes to the software link status. >> % @@ -2699,7 +2702,7 @@ >> % >> % if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && >> % sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || >> % - statusword || sc->bge_link_evt) >> % + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) >> % bge_link_upd(sc); >> % >> % if (ifp->if_drv_flags & IFF_DRV_RUNNING) { >> >> The software link status handling causes a problem in the interrupt >> handler. To avoid pessimizing the case of shared interrupts, the >> interrupt handler should be able to read the status word from the >> status block and return without doing anything if the interrupt is not >> for it. This can be done without acquiring the driver lock (since the >> driver lock is neither necessary nor sufficient for accessing the >> status block). Software link status gets in the way of this, since >> accessing it requires the driver lock. > You are right, but at the moment, bge_intr() is locked and does not care > about shared interrupts. If we are going to fix this i would vote for > using taskqueue api - in this case we can test 'link event' flag inside > locked taskqueue thread. It is fixed in mine :-). Except for the complications with the link status. I haven't really tested this because I try not to configure shared interrupts, but accidentally configured an inactive rl device on the same interrupt, so the case of an inactive rl with an active bge got tested. This case isn't so interesting -- the bge_intr() always does something and gets slowed down by rl_intr() deciding that it has nothing to do. At least the old version of rl that I use does a single PCI read in rl_intr() to decide what to do, so the slowdown is minimal. The taskqueue would be easiest to program. I'm not sure if it is good for efficiency. Certainly not while the interrupt hander is a normal one. >> (Note that `statusword' in the >> above is now bogusly named. It used to be the status word from the >> status block but is now the mac status for a PCI register. It is still >> from the status block in similar code in bge_poll(). Not pessimizing >> the case of shared interrupts requires using the status block again, >> and then the read from the PCI register might become a dummy.) > We can not avoid pci register read before syncing status block - we should > flush data posted at pci bridge, otherwise we can 'miss' interrupt. Actually, that might be avoidable too -- handle any missed interrupts by polling. If interrupts are rarely missed then the extra latency for polling wouldn't matter. BTW, avoiding the PCI read in bge_start_locked() (rev.1.108) gives a remarkably large difference in performance for small packets. Rev.1.108 claims a 1.8% speedup, but I got over 50% (370 kpps -> 560 kpps) when I applied 1.108 to an old version. The PCI read was adding about 60% to (the already very large) per-packet CPU overheads for small packets, since for small packets the CPU can't keep up, so tx queue lengths are always 0 or 1 and the PCI read is never amortized across multple packets. PCI read in bge_intr() is only expensive in similar cases -- when there are only a few packets per interrupt. >> Elsewhere, you added code to force interrupt after link status changes. >> I think this is to get the interrupt handler to look at the software >> link status in the above. When I first saw it, I thought that forcing >> an interrupt is needed in more places. > Forced interrupt used for TBI cards since they do not have PHY auto-polling. Do they set BGE_STATFLAG_UPDATED? Bruce From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 09:16:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 051A416A401; Wed, 7 Feb 2007 09:16:31 +0000 (UTC) (envelope-from sebosik@demax.sk) Received: from mail.demax.sk (mail.demax.sk [213.215.102.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6963813C467; Wed, 7 Feb 2007 09:16:19 +0000 (UTC) (envelope-from sebosik@demax.sk) Received: from mail.demax.sk (localhost [127.0.0.1]) by nod32.demax.sk (Postfix) with ESMTP id DF61142ACD; Wed, 7 Feb 2007 09:51:19 +0100 (CET) X-Virus-Scanner: This message was checked by NOD32 Antivirus system NOD32 for Linux Mail Server. For more information on NOD32 Antivirus System, please, visit our website: http://www.nod32.com/. Received: from [192.168.1.2] (2D204.demax.sk [195.62.17.204]) by mail.demax.sk (Postfix) with ESMTP id C122342AC7; Wed, 7 Feb 2007 09:51:19 +0100 (CET) Message-ID: <45C99336.3010508@demax.sk> Date: Wed, 07 Feb 2007 09:52:06 +0100 From: Jan Sebosik User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Packet rate limiter 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, 07 Feb 2007 09:16:32 -0000 Hi is there any way how to limit packet per second [PPS] rate to specified IP (group of IP) ? Linux can achieve this via IPtables. I`ve searched a lot of web, but nothing interesting found (for PF, IPFilter, and IPFW). Best regards --- Jan Sebosik, Slovakia From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 09:42:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D401C16A401 for ; Wed, 7 Feb 2007 09:42:43 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id BE9FD13C461 for ; Wed, 7 Feb 2007 09:42:43 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id 9A42410BBE5B; Wed, 7 Feb 2007 01:42:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3 Received: from [192.168.1.101] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 3603D10BBE4C for ; Wed, 7 Feb 2007 01:42:41 -0800 (PST) Message-ID: <45C99F10.7010703@sk1llz.net> Date: Wed, 07 Feb 2007 01:42:40 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45C99336.3010508@demax.sk> In-Reply-To: <45C99336.3010508@demax.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Packet rate limiter 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, 07 Feb 2007 09:42:44 -0000 Newp. You're stuck to good old bps with ipfw or bps/cpse (connections per second established) with pf. The other method would be to use cisco netflow export data from a router being polled - then limiting traffic with one of the methods mentioned above... or just place pps limits on your router itself. Jan Sebosik wrote: > Hi > > is there any way how to limit packet per second [PPS] rate to > specified IP (group of IP) ? Linux can achieve this via IPtables. > I`ve searched a lot of web, but nothing interesting found (for PF, > IPFilter, and IPFW). > > Best regards > > --- > Jan Sebosik, Slovakia > _______________________________________________ > 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 7 10:08:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62A0316A411 for ; Wed, 7 Feb 2007 10:08:52 +0000 (UTC) (envelope-from sebosik@demax.sk) Received: from mail.demax.sk (mail.demax.sk [213.215.102.234]) by mx1.freebsd.org (Postfix) with ESMTP id AD71113C471 for ; Wed, 7 Feb 2007 10:08:49 +0000 (UTC) (envelope-from sebosik@demax.sk) Received: from mail.demax.sk (localhost [127.0.0.1]) by nod32.demax.sk (Postfix) with ESMTP id 2C38C42ACF for ; Wed, 7 Feb 2007 11:08:48 +0100 (CET) X-Virus-Scanner: This message was checked by NOD32 Antivirus system NOD32 for Linux Mail Server. For more information on NOD32 Antivirus System, please, visit our website: http://www.nod32.com/. Received: from [192.168.1.2] (2D204.demax.sk [195.62.17.204]) by mail.demax.sk (Postfix) with ESMTP id 1749042AC7 for ; Wed, 7 Feb 2007 11:08:47 +0100 (CET) Message-ID: <45C9A55E.2080807@demax.sk> Date: Wed, 07 Feb 2007 11:09:34 +0100 From: Jan Sebosik User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45C99336.3010508@demax.sk> <45C99EF2.9010201@sk1llz.net> In-Reply-To: <45C99EF2.9010201@sk1llz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Packet rate limiter 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, 07 Feb 2007 10:08:55 -0000 Hmm, but if have done traffic shaping via bps limit. But I also wanted to limit packet rate, because P2P and skype uses small packets, but in high volumes....And it will stop P2P and Skype if I set on 512 kbps 40 packets/s [pps] > Newp. You're stuck to good old bps with ipfw or bps/cpse (connections > per second established) with pf. The other method would be to use > cisco netflow export data from a router being polled - then limiting > traffic with one of the methods mentioned above... or just place pps > limits on your router itself. > > > Jan Sebosik wrote: >> Hi >> >> is there any way how to limit packet per second [PPS] rate to >> specified IP (group of IP) ? Linux can achieve this via IPtables. >> I`ve searched a lot of web, but nothing interesting found (for PF, >> IPFilter, and IPFW). >> >> Best regards >> >> --- >> Jan Sebosik, Slovakia >> _______________________________________________ >> 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 7 10:35:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 386BA16A48F for ; Wed, 7 Feb 2007 10:35:08 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9054413C481 for ; Wed, 7 Feb 2007 10:35:08 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l17AZ3Jc063737; Wed, 7 Feb 2007 02:35:03 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l17AZ3p2063736; Wed, 7 Feb 2007 02:35:03 -0800 (PST) (envelope-from rizzo) Date: Wed, 7 Feb 2007 02:35:03 -0800 From: Luigi Rizzo To: Jan Sebosik Message-ID: <20070207023503.B63529@xorpc.icir.org> References: <45C99336.3010508@demax.sk> <45C99EF2.9010201@sk1llz.net> <45C9A55E.2080807@demax.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45C9A55E.2080807@demax.sk>; from sebosik@demax.sk on Wed, Feb 07, 2007 at 11:09:34AM +0100 Cc: freebsd-net@freebsd.org Subject: Re: Packet rate limiter 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, 07 Feb 2007 10:35:10 -0000 On Wed, Feb 07, 2007 at 11:09:34AM +0100, Jan Sebosik wrote: > Hmm, > > but if have done traffic shaping via bps limit. But I also wanted to > limit packet rate, because P2P and skype uses small packets, but in high > volumes....And it will stop P2P and Skype if I set on 512 kbps 40 > packets/s [pps] only a trick (but sometimes a useful one) would be to pass packets to different pipes basing on the size (or protocol - the small ones tend to be UDP because with TCP you have very little control on the packet size) and then set the limit differently on the two pipes cheers luigi > > > > Newp. You're stuck to good old bps with ipfw or bps/cpse (connections > > per second established) with pf. The other method would be to use > > cisco netflow export data from a router being polled - then limiting > > traffic with one of the methods mentioned above... or just place pps > > limits on your router itself. > > > > > > Jan Sebosik wrote: > >> Hi > >> > >> is there any way how to limit packet per second [PPS] rate to > >> specified IP (group of IP) ? Linux can achieve this via IPtables. > >> I`ve searched a lot of web, but nothing interesting found (for PF, > >> IPFilter, and IPFW). > >> > >> Best regards > >> > >> --- > >> Jan Sebosik, Slovakia > >> _______________________________________________ > >> 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 Wed Feb 7 12:05:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B933E16A419 for ; Wed, 7 Feb 2007 12:05:38 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id B9B3913C4A8 for ; Wed, 7 Feb 2007 12:05:37 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-32-135.51-151.net24.it [151.51.135.32]) (authenticated bits=128) by parrot.aev.net (8.13.8/8.13.8) with ESMTP id l17BvNGC024092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Feb 2007 12:57:30 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.13.8/8.13.8) with ESMTP id l17BkLhG075540 for ; Wed, 7 Feb 2007 12:46:21 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45C9BC01.5010803@netfence.it> Date: Wed, 07 Feb 2007 12:46:09 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 212.31.247.179 Subject: Bridging with two subnets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 12:05:39 -0000 Hello. I've got a firewall which has public IP xxx.xxx.xxx.2 on its first NIC. This is bridged with a second NIC which holds xxx.xxx.xxx.0/24. (I also have a third and fourth NIC which runs two private IP networks, which are NATted, but I don't think this matters). Everything is ok, but now I'm in need to also have a second public IP network on the second NIC, let's say yyy.yyy.yyy.0/24. A single upstream router provides us both public nets, but obviously with two different gateways (xxx.xxx.xxx.1 and yyy.yyy.yyy.1). The question is: is this possible? Do I only need to attach the additional yyy.yyy.yyy.0/24 boxes to the same switch? Do I need to ifconfig alias yyy.yyy.yyy.2 on the first NIC? What about the gateway then? Do I still set the first one only? My answers would be: Yes, No, Yes. I thought I'd ask, however. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 15:25:25 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C0B116A409 for ; Wed, 7 Feb 2007 15:25:25 +0000 (UTC) (envelope-from fenner@research.att.com) Received: from mail-red.research.att.com (mail-red.research.att.com [192.20.225.110]) by mx1.freebsd.org (Postfix) with ESMTP id 347FB13C4AC for ; Wed, 7 Feb 2007 15:25:25 +0000 (UTC) (envelope-from fenner@research.att.com) Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id D4E14147AFA; Wed, 7 Feb 2007 10:04:14 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.13.1/8.12.10/Submit) id l17F4EJx001944; Wed, 7 Feb 2007 07:04:14 -0800 From: Bill Fenner Message-Id: <200702071504.l17F4EJx001944@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: "Bruce M. Simpson" References: <45C39CBF.7010105@incunabulum.net> <45C94116.3090404@FreeBSD.org> Date: Wed, 7 Feb 2007 07:04:14 -0800 Versions: dmail (linux) 2.7/makemail 2.14 Cc: net@freebsd.org Subject: Re: Proposal: remove encap from MROUTING 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, 07 Feb 2007 15:25:25 -0000 >I plan to commit this patch some time this week. >---mroute-notunnels.diff, text/x-patch follows--- Please do. Only one comment: >@@ -859,8 +816,6 @@ X_ip_mrouter_done(void) > /* > * Reset de-encapsulation cache > */ >- last_encap_src = INADDR_ANY; >- last_encap_vif = NULL; > #ifdef PIM > reg_vif_num = VIFI_INVALID; > #endif I think that comment goes with the removed lines so should be removed with them. While you're thinking about removing stuff, think about removing the tbf code next. There are way more flexible ways of rate limiting traffic in the base system, so the tbf hack can and should just die. Just return an error when trying to create a vif with a rate limit. Bill From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 16:33:57 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C81C16A404 for ; Wed, 7 Feb 2007 16:33:57 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1675D13C48E for ; Wed, 7 Feb 2007 16:33:57 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id DEAF81A92D6 for ; Wed, 7 Feb 2007 11:33:55 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 07 Feb 2007 11:33:55 -0500 X-Sasl-enc: +Oqli6WFUgj02ud+uRlwqdZ1i59S/yzFuWZ4DW3db/wR 1170866035 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 876E01AA8D for ; Wed, 7 Feb 2007 11:33:55 -0500 (EST) Message-ID: <45C9FF72.7090102@incunabulum.net> Date: Wed, 07 Feb 2007 16:33:54 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Who was making IPPROTO_foo dynamic? 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, 07 Feb 2007 16:33:57 -0000 Hi, Somebody somewhere was making IP protocols dynamically loadable. I would like to make PIM the default in -CURRENT in ip_mroute.ko so that it may be dynamically loaded into GENERIC. At the moment, that isn't possible, because PIM requires hookup to ip_input() by way of a ipprotosw. Please make yourself known to me, our work overlaps... Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 16:51:57 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00C3F16A405 for ; Wed, 7 Feb 2007 16:51:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id CCCE913C4A8 for ; Wed, 7 Feb 2007 16:51:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 9DBC81A96F9; Wed, 7 Feb 2007 11:51:55 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 07 Feb 2007 11:51:55 -0500 X-Sasl-enc: m+315IdCifYPqqaqv4+sBT4cqvEdljFOfW+OtDj7tNod 1170867115 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C9D9118E6E; Wed, 7 Feb 2007 11:51:54 -0500 (EST) Message-ID: <45CA03AA.6040507@FreeBSD.org> Date: Wed, 07 Feb 2007 16:51:54 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Bill Fenner References: <45C39CBF.7010105@incunabulum.net> <45C94116.3090404@FreeBSD.org> <200702071504.l17F4EJx001944@bright.research.att.com> In-Reply-To: <200702071504.l17F4EJx001944@bright.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Proposal: remove encap from MROUTING 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, 07 Feb 2007 16:51:57 -0000 Bill Fenner wrote: >> I plan to commit this patch some time this week. >> > > Please do. Committed, with doc and version bumps. It doesn't look like the TBF can be removed straight away; there are consumers. BMS "And I've been dreaming of sleep... and ape-men with metal parts." -- David Bowie From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 18:50:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D3D216A40A; Wed, 7 Feb 2007 18:50:40 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id F10BF13C46B; Wed, 7 Feb 2007 18:50:39 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id C33AD109A7E; Thu, 8 Feb 2007 05:50:35 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id CE8108C03; Thu, 8 Feb 2007 05:50:36 +1100 (EST) Date: Thu, 8 Feb 2007 05:50:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oleg Bulyzhin In-Reply-To: <20070207193426.P35180@besplex.bde.org> Message-ID: <20070208043101.K687@besplex.bde.org> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> <20070207003539.I31484@besplex.bde.org> <20070206221857.GA66675@lath.rinet.ru> <20070207193426.P35180@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robin Gruyters , freebsd-net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 07 Feb 2007 18:50:40 -0000 On Wed, 7 Feb 2007, Bruce Evans wrote: > On Wed, 7 Feb 2007, Oleg Bulyzhin wrote: > >> On Wed, Feb 07, 2007 at 01:31:39AM +1100, Bruce Evans wrote: >>> I use jdp's quicker fix. It works fine for detecting cable unplug >>> and replug, but link detection is still very bad at boot time and I've now tested your fix in 6.2. It works to fix the few dropped packets every second, like jdp's fix does in -current. I didn't notice any other effect. >>> after down/up (seems to be worse for down/up than unplug/replug?). >>> Link detection in -current generally seems to be much worse than >>> in 5.2.On some systems I use two ping -c2's early in the boot to >>> wait for the link to actually be up. The first ping tends to fail >>> and the second tends to work, both long after the lonk claims to >>> be up. Then other network activity still takes too long to start. >>> Without the pings, an "ntpdate -b" early in the boot fails about >>> half the time and gives messed up timing activity when it fails, >>> and initial nfs mounts tak 30-60 seconds. Later after down/up and >>> waiting for the "up" message, ttcp -u usually fails to connect the >>> first time and then works normally with no failure or connection >>> delay the second time. >> >> Could you please give some more details? I'm intersted in: Further testing seems to show that the problem has little or nothing to do with link detection or the FreeBSD version, but is related to route expiry and the possibly the driver's interaction with this. Both of the following give similar bad behaviour on a simple network with static routes: (1) ifconfig $interface down up # bge, sk, xl, fxp all have the problem # but it seems to be much smaller for # fxp sleep 1 # longer doesn't help unless the other # side establishes the route netstat -r # shows empty expire time route get $remotehost # shows negative expire time ping -c1 $remotehost # first ping always fails (unless other # side establishes route beforehand) ping -c1 $anothremotehost # similarly for all other remote hosts netstat -r # still shows empty expire time ping -c1 $remotehost # second ping usually works netstat -r # shows expire time of ~1200 seconds ping -c1 $remotehost # third ping works if second one didn't (2) ifconfig $interface down sh /etc/netstart [rest as above] (3) route delete $remotehost [rest as above, for one host only] (1a-3a) as above, but use "ttcp -nlarge ..." instead of "ping -c1". The first ttcp fails with EHOSTDOWN. Well, that was under FreeBSD-mumble. On retesting (3) under 6.2 with your fix, the behaviour is much better -- the first ping usually works instantly. (3a) still fails on the first ttcp. 6.2 seems to be missing your fix for the time_uptime time warp -- after "route delete #remotehost", the negative expire time is slightly less than the uptime under 6.2, but it apparently should be slightly less than 0 as in ~5.2 and -current. I don't understand the expire times -- are they really supposed to go negative? Back under ~5.2, (3) is still misbehaving. Next I tried "ping -fq -c[1-10]" to try to avoid the delay getting the route established. This didn't work. There was still a delay; for small counts all except the last packet were lost; for large counts, most packets caused EHOSTDOWN. I now remember that debugging of "ttcp -nlarge" showed similar behaviour -- sendto() succeeded for the first few packets after down/up and then EHOSTDOWN was returned and ttcp aborted. The behaviour after booting seems to be the same, but I haven't checked it using netstat etc. yet. Normally there is a more important utility than ping that is the first one to access the network. Network initialization doesn't seem to do anything to ensure that the routes are actually usable immediately, at least in the old version of userland that I use, so it is left to the first utility that uses a route to retry after the first few packets are dropped. My configuration runs either ntpdate or nfs first, and these don't seem to handle the problem well: - ntpdate now usually succeeds after 10-20 seconds, but sometimes it fails after 10-20 seconds. I think it may be retrying once but not twice, so it fails in cases where 3 ping -c1's would have been needed to establish the route. Or maybe 2 retries with success on the last, where 4 pings would have been needed. Under the 6.2 kernel, messages about 2 sendto failures were printed before the success in one successful case. I haven't noticed these messages under -current or ~5.2. - nfs now usually takes 55 seconds to succeed on one client. It used to take < 1 or 2 seconds when the client and server were both fxp (now the client is sk and the server is bge). On another client wth bge and with ping before nfs, nfs takes ony 10-20 seconds to succeed despite the pings being to the ntp server and not the nfs server. >> - is there recipe how to trigger erroneous behaviour? i'll try it on mine >> bge cards. (i have bcm5721 5700 & 5701, but i didnt notice errors in >> link handling with -current driver (and i had problems with 5.x driver)) > > Just boot or down/up. route delete followed by ttcp is easiest. >> The fact 'ping' workaround does help looks like lost interrupt. > > Ah, it could be my returning immediately in bge_intr() if the status > block hasn't been updated. This wouldn't notice changes to the software > link status. It wasn't that. Debugging showed that the early return never happened. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 18:56:02 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54AF616A400 for ; Wed, 7 Feb 2007 18:56:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 25A9213C481 for ; Wed, 7 Feb 2007 18:56:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 23AD04813E; Wed, 7 Feb 2007 13:56:01 -0500 (EST) Date: Wed, 7 Feb 2007 18:56:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce M Simpson In-Reply-To: <45C9FF72.7090102@incunabulum.net> Message-ID: <20070207184948.D62141@fledge.watson.org> References: <45C9FF72.7090102@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Re: Who was making IPPROTO_foo dynamic? 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, 07 Feb 2007 18:56:02 -0000 On Wed, 7 Feb 2007, Bruce M Simpson wrote: > Somebody somewhere was making IP protocols dynamically loadable. > > I would like to make PIM the default in -CURRENT in ip_mroute.ko so that it > may be dynamically loaded into GENERIC. At the moment, that isn't possible, > because PIM requires hookup to ip_input() by way of a ipprotosw. > > Please make yourself known to me, our work overlaps... I believe that that was Andre Oppermann. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 19:12:53 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0794F16A407; Wed, 7 Feb 2007 19:12:51 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id C18CB13C471; Wed, 7 Feb 2007 19:12:50 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id 750495A1F95; Thu, 8 Feb 2007 06:12:49 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 835EC2740B; Thu, 8 Feb 2007 06:12:48 +1100 (EST) Date: Thu, 8 Feb 2007 06:12:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Oleg Bulyzhin In-Reply-To: <20070208043101.K687@besplex.bde.org> Message-ID: <20070208060101.V762@besplex.bde.org> References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net> <20070205232800.GA45487@lath.rinet.ru> <20070207003539.I31484@besplex.bde.org> <20070206221857.GA66675@lath.rinet.ru> <20070207193426.P35180@besplex.bde.org> <20070208043101.K687@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Robin Gruyters , freebsd-net@FreeBSD.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] 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, 07 Feb 2007 19:12:54 -0000 On Thu, 8 Feb 2007, I wrote: > 6.2 seems to be missing your fix for the time_uptime time warp -- after > "route delete #remotehost", the negative expire time is slightly less $ > than the uptime under 6.2, but it apparently should be slightly less > than 0 as in ~5.2 and -current. I don't understand the expire times > -- are they really supposed to go negative? The negative expire time seems to be actually the negative of the time since the last down/up, not the negative of the uptime, and this behaviour is the same in ~5.2, 6.2 and -current. 6.2 doesn't need your fix since it still uses time_second. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 20:39:39 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDD7716A402 for ; Wed, 7 Feb 2007 20:39:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id A42B813C49D for ; Wed, 7 Feb 2007 20:39:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id CECE61CCC3; Wed, 7 Feb 2007 21:39:38 +0100 (CET) Date: Wed, 7 Feb 2007 21:39:38 +0100 From: Ed Schouten To: Pyun YongHyeon Message-ID: <20070207203938.GE27282@hoeg.nl> References: <20070206204314.GB27282@hoeg.nl> <20070207003756.GA37911@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2NVUe83uzBILE3UT" Content-Disposition: inline In-Reply-To: <20070207003756.GA37911@cdnetworks.co.kr> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org, shigeaki@se.hiroshima-u.ac.jp, Rink Springer Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 07 Feb 2007 20:39:40 -0000 --2NVUe83uzBILE3UT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, * Pyun YongHyeon wrote: > Would you try overhauled nfe(4)? >=20 > http://people.freebsd.org/~yongari/nfe/if_nfe.c > http://people.freebsd.org/~yongari/nfe/if_nfereg.c > http://people.freebsd.org/~yongari/nfe/if_nfevar.c >=20 > The new nfe(4) should perform better than nve(4) or stock nfe(4). > I'm still not satisfied with its excessive generation of interrtups > but it's better than stock nfe(4). After switching to adaptive > polling I saw noticeable performance boost. If you find any issues > please let me know. I just compiled and installed a kernel with the new nfe(4) driver and DEVICE_POLLING enabled. Below are the results of some scp(1) transfers: stock nfe(4): 2.5 MB/sec new nfe(4): 3.7 MB/sec polling: 4.1 MB/sec The driver is a lot better than the stock nfe(4). Are there any plans to add the new nfe(4) to the sourcetree? --=20 Ed Schouten WWW: http://g-rave.nl/ --2NVUe83uzBILE3UT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFyjkK52SDGA2eCwURAlT0AJ9LWV5b+UVsW2xp758lmZbyCWw6QACeKFCz vi5CPVWyTdWKuMGv6a+tFLs= =sUXL -----END PGP SIGNATURE----- --2NVUe83uzBILE3UT-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 20:49:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC6BC16A400 for ; Wed, 7 Feb 2007 20:49:23 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id 697AD13C474 for ; Wed, 7 Feb 2007 20:49:23 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 7D5CDD4C62; Wed, 7 Feb 2007 21:46:49 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+1BNXxK3OyN; Wed, 7 Feb 2007 21:46:40 +0100 (CET) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id D9C6AD4C5E; Wed, 7 Feb 2007 21:46:39 +0100 (CET) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l17KkaVi088885; Wed, 7 Feb 2007 21:46:36 +0100 (CET) (envelope-from rink) Date: Wed, 7 Feb 2007 21:46:36 +0100 From: Rink Springer To: Ed Schouten Message-ID: <20070207204636.GG70525@rink.nu> References: <20070206204314.GB27282@hoeg.nl> <20070207003756.GA37911@cdnetworks.co.kr> <20070207203938.GE27282@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20070207203938.GE27282@hoeg.nl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Pyun YongHyeon , freebsd-net@freebsd.org, shigeaki@se.hiroshima-u.ac.jp, Rink Springer Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 07 Feb 2007 20:49:23 -0000 On Wed, Feb 07, 2007 at 09:39:38PM +0100, Ed Schouten wrote: > I just compiled and installed a kernel with the new nfe(4) driver and > DEVICE_POLLING enabled. Below are the results of some scp(1) transfers: scp(1) isn't really the best way to test this; the XBOX CPU cannot satisfy a 100mbit link using scp(1). FTP would be a much better idea, preferably with a large file. > The driver is a lot better than the stock nfe(4). Are there any plans to > add the new nfe(4) to the sourcetree? I concur, nfe(4) really needed some work, and it appears Pyon has done a good job. Thumbs up! --=20 Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya From owner-freebsd-net@FreeBSD.ORG Wed Feb 7 21:25:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FEE716A403; Wed, 7 Feb 2007 21:25:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 29CEB13C441; Wed, 7 Feb 2007 21:25:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l17KrBQi082774; Wed, 7 Feb 2007 14:53:11 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l17KrAxR082773; Wed, 7 Feb 2007 14:53:10 -0600 (CST) (envelope-from brooks) Date: Wed, 7 Feb 2007 14:53:10 -0600 From: Brooks Davis To: Rink Springer Message-ID: <20070207205310.GA82708@lor.one-eyed-alien.net> References: <20070206204314.GB27282@hoeg.nl> <20070207003756.GA37911@cdnetworks.co.kr> <20070207203938.GE27282@hoeg.nl> <20070207204636.GG70525@rink.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20070207204636.GG70525@rink.nu> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 07 Feb 2007 14:53:11 -0600 (CST) Cc: Pyun YongHyeon , freebsd-net@freebsd.org, Ed Schouten , shigeaki@se.hiroshima-u.ac.jp, Rink Springer Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 07 Feb 2007 21:25:07 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 07, 2007 at 09:46:36PM +0100, Rink Springer wrote: > On Wed, Feb 07, 2007 at 09:39:38PM +0100, Ed Schouten wrote: > > I just compiled and installed a kernel with the new nfe(4) driver and > > DEVICE_POLLING enabled. Below are the results of some scp(1) transfers: >=20 > scp(1) isn't really the best way to test this; the XBOX CPU cannot > satisfy a 100mbit link using scp(1). FTP would be a much better idea, > preferably with a large file. Much better (unless you want to see the effect of disk I/O) would be something like benchmarks/netpipe. -- Brooks --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFyjw2XY6L6fI4GtQRAvQjAKC3jF8wysx6TwlnktXfeoV8yn23UACg5KW6 C5SxqBLkBLWZpR4tkMd41+U= =tlld -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 03:17:06 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8BA516A403 for ; Thu, 8 Feb 2007 03:17:05 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 0ECCC13C478 for ; Thu, 8 Feb 2007 03:17:03 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so198238pye for ; Wed, 07 Feb 2007 19:17:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hg4Rbrueb5hz/W/dMx9UDc6+oENBrg99JPnX2oDEr99ARRUkpdhzjh5/MoJqg5tSWtAOKIH+gtrt99jsicngahv2twmWbaH0oA+/l5bDNXlhW0YkKVN+A0YK6hOZWnp7Fw1HTiJGXsB122V+cOK9dPOAe+s8dDLqyCfWUuUptHw= Received: by 10.35.82.16 with SMTP id j16mr20715613pyl.1170904623388; Wed, 07 Feb 2007 19:17:03 -0800 (PST) Received: by 10.35.58.13 with HTTP; Wed, 7 Feb 2007 19:17:03 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 03:17:03 +0000 From: MQ To: "Bruce Evans" In-Reply-To: <20070206234100.S31484@besplex.bde.org> MIME-Version: 1.0 References: <20061206085401.GH32700@cell.sick.ru> <20061212224351.GE91560@lath.rinet.ru> <20061214092248.GA21394@lath.rinet.ru> <20070206234100.S31484@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Oleg Bulyzhin , net@freebsd.org Subject: Re: [antinvidia@gmail.com: some questions about bge(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, 08 Feb 2007 03:17:06 -0000 2007/2/6, Bruce Evans : > > On Tue, 6 Feb 2007, MQ wrote: > > > 2006/12/14, Oleg Bulyzhin : > >> > >> On Thu, Dec 14, 2006 at 12:55:51AM +0000, MQ wrote: > >> > 2006/12/12, Oleg Bulyzhin : > >> > > > >> > >On Wed, Dec 06, 2006 at 11:54:01AM +0300, Gleb Smirnoff wrote: > >> > >> Forwarding to net@ list and to Oleg, who has made polling > >> > >> support for bge(4). > >> > >> > >> > >> ----- Forwarded message from MQ < antinvidia@gmail.com> ----- > >> > >> > >> > >> From: MQ > >> > >> To: glebius@freebsd.org , davidch@broadcom.com > >> > >> Subject: some questions about bge(4) > >> > >> Date: Sat, 2 Dec 2006 09:32:27 +0000 > >> > >> Delivered-To: glebius@freebsd.org > >> > >> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; > >> > >> s=beta; d=gmail.com; > >> > >> > >> > > >h=received:message-id:date:from:to:subject:mime-version:content-type; > >> > >> > >> > > >> > >b=ZL3ZZ1zR0mt4LaUN2Rr+jXTPSzQgJYRwLiwKnv95r2UCEids5Wl7oA2BNgicJ2QRG8OalJ7DqY7lM1HBgv0OVTlXOhGQ9aFmKQAuTNi6ueZA817XUacXyViEepnj0oNyYgAnkbaaBO1+nl2Fpb3IxV+MIe575WRlqbglF8kdOek= > >> > > > >> > >> > >> > >> Hi David and Gleb, > >> > >> I'm using several chips whose driver is bge(4). And now I have > >> some > >> > >> questions about the driver, would you please an answer for me? > >> > >> My confusion is related with some codes in > /sys/dev/mii/brgphy.c. > >> The > >> > > > >> > >> bge(4) uses the callout to drive the watchdog. And the > >> brgphy_service() > >> > >is > >> > >> called once per second. It calls brgphy_mii_phy_auto() every 5 > >> seconds > >> > >to > >> > >> autonegotiate the media. Normally, it costs about 0.5ms in the > first > >> > >> function brgphy_service(), and about 5ms when autonegotiation is > >> > >proceeded. > >> > > > >> > >brgphy_mii_phy_auto() is called only if there is no link. > > I haven't seen more than 50-100 uS for an average brgphy_service(), but > even 500 uS shouldn't be a problem except near the maximum theoretical > packet rate of ~1500 kpps, since the device has buffering for 512-1024 > packets (512 @ 1500 kpps = 341 uS = not quite 500 uS). Half of the > available rx buffering for non-jumbo packets is not being used, so the > worst case is actually 170 uS of buffering @ 1500 kpps. > > However, known bugs cause brgphy_service() to often lose a packet. > > >> > >> I haven't done streestest on it, consequently I don't know if > this > >> > >delay > >> > >> will cause packets to be dropped. But I've enabled device polling > >> with > >> > >the > >> > >> bge(4) on FreeBSD 6.1-RELEASE. If HZ is set to a high value(e.g. > >> 4000), > >> > >this > >> > >> delay will cause the kern.polling.lost_polls to increase by one or > >> two > >> > >every > >> > >> second. And for about five seconds, the lost poll will increase by > at > >> > >least > >> > >> 16 regularly. So I think this behavior has some impact on the > systems > >> > >that > >> > >> enables device polling. > > Lost polls shouldn't be much more of a problem. Polls are only lost > if the system can't actually poll at 1/HZ. Increasing HZ won't make > the worst case any better. Polls are lost at HZ = 1000 then the worst > case extra delay is >= 1mS the 512-1024 packets of buffering starts > becoming a problem. It is alread a problem at the maximum packet rate, > since at least 1500 packets of buffering would be needed for polling > at 1000 Hz to have any chacne of keeping up. The practival limits for > polling at 1000 Hz with bge are now close to 256 kpps for rx (since > half the buffering is not configured) and 512 kpps for tx. > > >> Could we get something to make the bge(4) a > >> bit > >> > >more > >> > >> friendly to the device polling? I don't know if autonegotiation is > >> > >really > >> > >> needed to be called so frequently when we are connected to a good > >> > >network > >> > >> environment. Can I modify the interval between two > autonegotiations > > ... > >> > >If you have lost poll it does not guarantee packet loss. > > It hould never result in packet loss, due to buffering being adequate. > > >> > >Packets can be retrieved by next poll or even by idle_poll thread. > >> > >bge_tick() is doing couple of pci register reads (it's polling phy > >> status > >> > >and > >> > >updates some statistic counters), this why it takes some time. > > I don't believe in polling, but occasionally test it to check that > interrupt handling doesn't lose to it :-). I mostly use HZ = 100 and > get up to 640 kpps (tx) where polling at 1000 Hz is limited to 512 > kpps. Polling in idle can work better if the system is actually idle. > Interrupt handling still loses to it for latency -- I have a ping > latency of 50-60 uS with interrupt handling and 40-50 uS with polling > in idle. However, something (perhaps excessive PCI reads to check the > link checks on every poll) limits packet rates for polling -- large > values of HZ work as expected, and polling in idle should work better > provided the system is actually idle, but in practice polling in idle > with low HZ doesn't work as well for throughput as not polling in > idle with a large HZ. (I guess this is because the PCI reads take > several cycles per poll and each poll delivers an average of <= 1 packet. > For a ping latency of 40 uS, the few extra uS are not dominant, but > at 100's of kpps they become dominant.) > > >> > By the way, bge_tick() takes about 0.5ms to finish its work, this > >> results > >> > the lost poll every second when HZ is higher. Lower HZ will limit the > >> > performance under heavy traffic, and may result packet loss in that > >> > situation. And higher HZ will make a confusing situation that whether > we > >> > >> > have encountered a packet loss? It's really hard to make a decision > >> between > >> > these two kinds of situation. > >> > >> IMO, high HZ would not give perfomance gain if you have idle polling on > >> (sysctl kern.polling.idle_poll=1 ). > >> So it's better to have HZ=1000 & idle polling, than HZ=10000 and idle > >> polling > >> disabled. > > A higher HZ can work better than idle polling. If the system is rarely > idle, then idle polling is useless. At any reasonable value of HZ, > latency is very bad unless idle polling is used and the system is often > idle. Unreasonably large values of HZ (10000 - 100000 are probably > possible) can be used to reduced the latency. > > Bruce > I don't know if you really have used bge(4) with device polling (or maybe the chips you used had some big differences from mine), but I can't agree with you on some of your points. The 0.5ms delay of the brgphy codes causes the abnormal lost_polls, which may disturb us from identifying the real situation and loads of the machine. Moreover, this delay causes packets to accumulate in the packet buffer. Device polling uses poll burst to describe how many packets can be get in a poll, the delay interrupts this mechanism from working properly under high HZ. The poll codes do NOT check the link very often. I don't know what do you mean by 'PCI reads', maybe you were referring to the bge card registers? At last you mentioned the higher HZ problem, that's why I initially posted to this mailing list. HZ more than 2000 causes lost_polls to increase regularly every second. As I said before, this abnormal lost_polls prevent me from getting the actual status of the machine. If you really filled HZ with 10000, you will get at least 5 lost_polls per second. From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 07:13:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F66816A400 for ; Thu, 8 Feb 2007 07:13:19 +0000 (UTC) (envelope-from robert@mpe.mpg.de) Received: from mpemail.mpe.mpg.de (mpemail.mpe-garching.mpg.de [130.183.137.110]) by mx1.freebsd.org (Postfix) with ESMTP id 36F9613C467 for ; Thu, 8 Feb 2007 07:13:19 +0000 (UTC) (envelope-from robert@mpe.mpg.de) Received: from robert3.mpe-garching.mpg.de ([130.183.136.84]) by mpemail.mpe.mpg.de with esmtpa (Exim 4.50) id 1HF3Sx-0003X1-S9 for freebsd-net@freebsd.org; Thu, 08 Feb 2007 08:13:16 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Klaus Robert Suetterlin Date: Thu, 8 Feb 2007 08:13:08 +0100 X-Mailer: Apple Mail (2.752.3) X-Authenticated-Id: robert Subject: Is there a GigE vision standard frame grabber support on FreeBSD 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, 08 Feb 2007 07:13:19 -0000 Hi all, has anyone experience with using GigE vision standard based cameras and using them under FreeBSD? I am glad for any and all pointers and especially if there was someone with first hand experience. Thanks, --Robert S. From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 09:23:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CCA016A401; Thu, 8 Feb 2007 09:23:50 +0000 (UTC) (envelope-from steven@unix-solutions.be) Received: from smtp.unix-solutions.be (smtp01.unix-solutions.be [82.146.126.214]) by mx1.freebsd.org (Postfix) with ESMTP id 072F513C47E; Thu, 8 Feb 2007 09:23:45 +0000 (UTC) (envelope-from steven@unix-solutions.be) Received: from cloe ([172.16.0.170]) by home.lan with MailEnable ESMTP; Thu, 08 Feb 2007 10:08:21 +0100 From: "Steven Bens" To: Date: Thu, 8 Feb 2007 10:07:41 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdLYDqSAa3XD+ouQDWXvIzq1+u0IQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070208092346.072F513C47E@mx1.freebsd.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: Serious Bind issue 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, 08 Feb 2007 09:23:50 -0000 Dear mailinglist members, I have an serious issue with bind. System information: Dual P3 1 GHz 6.1-RELEASE-p12 FreeBSD SMP kernel I'm running BIND 9.3.2 on this box (the one that is standard delivered with 6.1) And when the named is running for a copple of hours. Bind doesn't accept TCP connections and i see this in my /var/log/messages: Feb 8 06:44:13 gms01 named[417]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1876: unexpected error: Feb 8 06:44:13 gms01 named[417]: internal_accept: accept() failed: Invalid argument Feb 8 06:46:55 gms01 named[417]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1876: unexpected error: Feb 8 06:46:55 gms01 named[417]: internal_accept: accept() failed: Invalid argument Feb 8 06:47:43 gms01 named[417]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1876: unexpected error: Feb 8 06:47:43 gms01 named[417]: internal_accept: accept() failed: Invalid argument Feb 8 07:00:08 gms01 named[417]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1876: unexpected error: Feb 8 07:00:08 gms01 named[417]: internal_accept: accept() failed: Invalid argument Feb 8 07:00:13 gms01 named[417]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1876: unexpected error: Feb 8 07:00:13 gms01 named[417]: internal_accept: accept() failed: Invalid argument Does anybody knows what this is ? I have an exact copy this server running next to this one. But that server is not SMP and it doesn't have this problems. Kind regards, Steven Bens CEO Unix-Solutions www.Unix-Solutions.be From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 19:33:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19FAC16A400 for ; Thu, 8 Feb 2007 19:33:30 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id E70CD13C4B5 for ; Thu, 8 Feb 2007 19:33:29 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HFElt-0000Mi-VQ for freebsd-net@freebsd.org; Thu, 08 Feb 2007 11:17:29 -0800 Message-ID: <8872206.post@talk.nabble.com> Date: Thu, 8 Feb 2007 11:17:29 -0800 (PST) From: "Dr. Reda" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: reda.reda@siemens.com Subject: ICAS 2007 & ICNS 2007, Athens, June 19-25, 2007 DEADLINE EXTENDED FEBRUARY 10 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, 08 Feb 2007 19:33:30 -0000 Invitation Please consider contributing to ICAS 2007, ICNS 2007 and the associated workshops listed below. Conference: June 19-25, 2007, Athens, Greece Important deadline for full paper submission: February 10, 2007 Please forward the Call for Submissions to the appropriate groups. ======================================= CALL FOR PAPERS ICAS 2007: The Third International Conference on Autonomic and Autonomous Systems: http://www.iaria.org/conferences2007/ICAS07.html ICNS 2007: The Third International Conference on Networking and Services http://www.iaria.org/conferences2007/ICNS07.html ======================================== Featuring also the workshops: - SELF 2007: The Second International Workshop on Self-adaptability and Self-management of Context-aware Systems http://www.iaria.org/conferences2007/SELF.html - KUI 2007: The First International Workshop on Knowledge-based User Interface http://www.iaria.org/conferences2007/KUI.html - IPv6DFI 2007: The Second International Workshop on Deploying the Future Infrastructure http://www.iaria.org/conferences2007/IPV6DFI.html - IPDy 2007: The Second International Workshop on Internet Packet Dynamics http://www.iaria.org/conferences2007/IPDY.html - GOBS 2007: The First International Workshop on GRID over Optical Burst Switching Networks http://www.iaria.org/conferences2007/GOBS.html =============================== Published by IEEE Computer Society Press Published in the IEEE Xplore Digital Library Indexing: http://www.computer.org/portal/pages/cscps/cps/cps_indexing.html =============================== ICAS 2007 Main Tracks: SYSAT: Advances in system automation AUTSY: Theory and practice of autonomous systems AWARE: Design and deployment of context-awareness networks, services and applications AUTONOMIC: Autonomic computing: design and management of self-behavioural networks and services MCMAC: Monitoring, control, and management of autonomous self-aware and context-aware systems CASES: Automation in specialized mobile environments ALCOC: Algorithms and theory for control and computation MODEL: Modelling, virtualization, any-on-demand, MDA, SOA ============================================= ICNS 2007 Main Tracks: ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications -- View this message in context: http://www.nabble.com/ICAS-2007---ICNS-2007%2C-Athens%2C-June-19-25%2C-2007-DEADLINE-EXTENDED-FEBRUARY-10-tf3195339.html#a8872206 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 20:46:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DC3116A400 for ; Thu, 8 Feb 2007 20:46:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 2CDDC13C428 for ; Thu, 8 Feb 2007 20:46:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9466 invoked by uid 399); 8 Feb 2007 20:46:51 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 8 Feb 2007 20:46:51 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45CB8C33.7020608@FreeBSD.org> Date: Thu, 08 Feb 2007 12:46:43 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Steven Bens References: <20070208092346.072F513C47E@mx1.freebsd.org> In-Reply-To: <20070208092346.072F513C47E@mx1.freebsd.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Serious Bind issue 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, 08 Feb 2007 20:46:52 -0000 In the future, please don't cross post to both freebsd-questions, and another list at the same time. Thanks. Steven Bens wrote: > Dear mailinglist members, > > I have an serious issue with bind. > > System information: > Dual P3 1 GHz > 6.1-RELEASE-p12 FreeBSD > SMP kernel > > I'm running BIND 9.3.2 on this box (the one that is standard delivered with > 6.1) > And when the named is running for a copple of hours. Bind doesn't accept TCP > connections In an ideal world you would upgrade to the latest RELENG_6 and pick up all the bug fixes in the OS, plus the latest version of BIND. If that's not possible for some reason, your best bet is to upgrade to the latest BIND from the ports, make sure that you build it WITHOUT threads, and see if that resolves the issue for you. If it doesn't resolve your issue, you'd be better off sending a message to the bind-users@isc.org list. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 21:15:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1F4C16A400 for ; Thu, 8 Feb 2007 21:15:56 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9B713C48E for ; Thu, 8 Feb 2007 21:15:56 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HFGSD-0005jH-7x; Thu, 08 Feb 2007 21:05:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HFGP2-0000y4-3J; Thu, 08 Feb 2007 13:02:00 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17867.36807.577658.322763@roam.psg.com> Date: Thu, 8 Feb 2007 13:01:59 -0800 To: Andre Oppermann Cc: freebsd-net@freebsd.org Subject: tuning 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: Thu, 08 Feb 2007 21:15:56 -0000 any suggestions for how to tune freebsd tcp for very large bandwidth delay product. doing daily rsync from oregon to australia over I2 and aarnet. getting mediocre transfers. hints appreciated. From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 21:18:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3222116A402; Thu, 8 Feb 2007 21:18:28 +0000 (UTC) (envelope-from javier@kjsl.com) Received: from skywagon.kjsl.com (skywagon.kjsl.com [69.36.240.252]) by mx1.freebsd.org (Postfix) with ESMTP id 1F24A13C4A3; Thu, 8 Feb 2007 21:18:28 +0000 (UTC) (envelope-from javier@kjsl.com) Received: from [199.46.16.11] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: javier) by skywagon.kjsl.com (Postfix) with ESMTP id 1E4E42A68CC; Thu, 8 Feb 2007 15:51:52 -0500 (EST) In-Reply-To: <45CB8C33.7020608@FreeBSD.org> References: <20070208092346.072F513C47E@mx1.freebsd.org> <45CB8C33.7020608@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Javier Henderson Date: Thu, 8 Feb 2007 15:51:48 -0500 To: Doug Barton X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Steven Bens Subject: Re: Serious Bind issue 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, 08 Feb 2007 21:18:28 -0000 On Feb 8, 2007, at 3:46 PM, Doug Barton wrote: > In the future, please don't cross post to both freebsd-questions, and > another list at the same time. Thanks. > > Steven Bens wrote: >> Dear mailinglist members, >> >> I have an serious issue with bind. >> >> System information: >> Dual P3 1 GHz >> 6.1-RELEASE-p12 FreeBSD >> SMP kernel >> >> I'm running BIND 9.3.2 on this box (the one that is standard >> delivered with >> 6.1) >> And when the named is running for a copple of hours. Bind doesn't >> accept TCP >> connections > > In an ideal world you would upgrade to the latest RELENG_6 and pick up > all the bug fixes in the OS, plus the latest version of BIND. If > that's not possible for some reason, your best bet is to upgrade to > the latest BIND from the ports, make sure that you build it WITHOUT > threads, and see if that resolves the issue for you. FWIW, I was running BIND 9.3.2 for a while and in awe at the amount of memory it would use, and how it would go CPU bound after it hit any operating system imposed memory quotas. I went back to BIND 8.latest, and my problems went away. -jav From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 21:29:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8E8416A405 for ; Thu, 8 Feb 2007 21:29:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 572A113C48D for ; Thu, 8 Feb 2007 21:29:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 32339 invoked by uid 399); 8 Feb 2007 21:29:56 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 8 Feb 2007 21:29:56 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45CB964C.8090409@FreeBSD.org> Date: Thu, 08 Feb 2007 13:29:48 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Javier Henderson References: <20070208092346.072F513C47E@mx1.freebsd.org> <45CB8C33.7020608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Steven Bens Subject: Re: Serious Bind issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2007 21:29:57 -0000 Javier Henderson wrote: > FWIW, I was running BIND 9.3.2 for a while and in awe at the amount of > memory it would use, and how it would go CPU bound after it hit any > operating system imposed memory quotas. Many people have reported this problem, but no one has been able to follow up on getting it fixed. > I went back to BIND 8.latest, and my problems went away. ... but only for the short term. Development has stopped on BIND 8, and I'm planning to deprecate the BIND 8 ports now that FreeBSD 4.x has been EOL'ed. BIND 9 is not even the wave of the future, it's now the present, and if it's not working for you it's incumbent on you to contact the bind-users@isc.org list and do what you can to help diagnose this problem, and test the fixes. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 21:32:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A2FC16A400 for ; Thu, 8 Feb 2007 21:32:20 +0000 (UTC) (envelope-from javier@kjsl.com) Received: from skywagon.kjsl.com (skywagon.kjsl.com [69.36.240.252]) by mx1.freebsd.org (Postfix) with ESMTP id 2928C13C428 for ; Thu, 8 Feb 2007 21:32:20 +0000 (UTC) (envelope-from javier@kjsl.com) Received: from [199.46.16.11] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: javier) by skywagon.kjsl.com (Postfix) with ESMTP id 8EB772A68CC; Thu, 8 Feb 2007 16:32:19 -0500 (EST) In-Reply-To: <45CB964C.8090409@FreeBSD.org> References: <20070208092346.072F513C47E@mx1.freebsd.org> <45CB8C33.7020608@FreeBSD.org> <45CB964C.8090409@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18F7B6AF-0997-4209-B92E-1E7D4CCDEA19@kjsl.com> Content-Transfer-Encoding: 7bit From: Javier Henderson Date: Thu, 8 Feb 2007 16:32:16 -0500 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.2) Cc: Steven Bens Subject: Re: Serious Bind issue 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, 08 Feb 2007 21:32:20 -0000 On Feb 8, 2007, at 4:29 PM, Doug Barton wrote: > Javier Henderson wrote: > >> FWIW, I was running BIND 9.3.2 for a while and in awe at the >> amount of >> memory it would use, and how it would go CPU bound after it hit any >> operating system imposed memory quotas. > > Many people have reported this problem, but no one has been able to > follow up on getting it fixed. > >> I went back to BIND 8.latest, and my problems went away. > > ... but only for the short term. Development has stopped on BIND 8, > and I'm planning to deprecate the BIND 8 ports now that FreeBSD 4.x > has been EOL'ed. BIND 9 is not even the wave of the future, it's now > the present, and if it's not working for you it's incumbent on you to > contact the bind-users@isc.org list and do what you can to help > diagnose this problem, and test the fixes. Sure. What would you like me to do? I can easily set up a test box to mirror my main nameserver, which is authoritative for over 2000 domains, and test away. -jav From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 21:54:12 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76C2216A401 for ; Thu, 8 Feb 2007 21:54:12 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id 67BEB13C471 for ; Thu, 8 Feb 2007 21:54:12 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l18LgXSj003487 for ; Thu, 8 Feb 2007 13:42:34 -0800 (PST) Date: Thu, 08 Feb 2007 13:42:27 -0800 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.92 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Announcing the packet debugger (and PCS 0.4) and a FreeBSD Networking Blog 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, 08 Feb 2007 21:54:12 -0000 Hi, These should (I hope) be in ports soon but I also wanted to announce them here. I've now updated PCS, the Packet Construction Set, to 0.4 Beta. The changes etc. are in the changelog with the release at http://pcs.sf.net. I have also written something I think all the network folks will like called the Packet Debugger. http://pktdbg.sf.net/ The Packet Debugger (pdb) is a program which allows people to work with packet streams as if they were working with a source code debugger. Users can list, inspect, modify, and retransmit any packet from captured files as well as work with live packet capture. There is a 12 page manual that accompanies the the debugger. Finally, I have set up a Networking blog at: http://blogs.freebsdish.org/gnn/ Where I'll be posting stuff about my work with IPv6, IPsec, virtual machines and other kernel and networking stuff. Best, George PS The port for PCS is net/pcs and my proposed port for pdb is net/pktdbg From owner-freebsd-net@FreeBSD.ORG Thu Feb 8 22:15:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E986716A401 for ; Thu, 8 Feb 2007 22:15:43 +0000 (UTC) (envelope-from destan@sdu.edu.tr) Received: from virus.sdu.edu.tr (virus.sdu.edu.tr [193.140.181.25]) by mx1.freebsd.org (Postfix) with ESMTP id 94EFB13C4B8 for ; Thu, 8 Feb 2007 22:15:43 +0000 (UTC) (envelope-from destan@sdu.edu.tr) Received: from localhost (localhost [127.0.0.1]) by virus.sdu.edu.tr (Postfix) with ESMTP id 7E67662D419; Thu, 8 Feb 2007 23:52:24 +0200 (EET) X-Virus-Scanned: amavisd-new at sdu.edu.tr Received: from virus.sdu.edu.tr ([127.0.0.1]) by localhost (virus.sdu.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2NwHU5F0IXd; Thu, 8 Feb 2007 23:52:21 +0200 (EET) Received: from mail.sdu.edu.tr (unknown [192.168.1.2]) by virus.sdu.edu.tr (Postfix) with ESMTP id 610D162D418; Thu, 8 Feb 2007 23:52:21 +0200 (EET) Received: from localhost (gokhan.sdu.edu.tr [193.140.181.123]) by mail.sdu.edu.tr (Postfix) with ESMTP id 499B3418341; Thu, 8 Feb 2007 23:55:46 +0200 (EET) Received: from mstr81213-16172.dial-in.ttnet.net.tr (mstr81213-16172.dial-in.ttnet.net.tr [81.213.63.44]) by wwm.sdu.edu.tr (IMP) with HTTP for ; Thu, 8 Feb 2007 23:55:51 +0200 Message-ID: <1170971751.45cb9c67a3b6c@wwm.sdu.edu.tr> Date: Thu, 8 Feb 2007 23:55:51 +0200 From: Destan YILANCI To: Randy Bush References: <17867.36807.577658.322763@roam.psg.com> In-Reply-To: <17867.36807.577658.322763@roam.psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-9 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 81.213.63.44 Cc: freebsd-net@freebsd.org Subject: Re: tuning 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: Thu, 08 Feb 2007 22:15:44 -0000 Hi, You may look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html especially "section 11.13.2.2" Also addresses below are useful; take a look: http://www-didc.lbl.gov/TCP-tuning/FreeBSD.html http://www.wormulon.net/files/pub/FreeBSD_Network_Tuning_-_slides.pdf Aktarýlýyor Randy Bush : > any suggestions for how to tune freebsd tcp for very large bandwidth > delay product. doing daily rsync from oregon to australia over I2 > and aarnet. getting mediocre transfers. hints appreciated. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Best Regards Destan YILANCI ---------------------------------------------- Süleyman Demirel Üniversitesi - ISPARTA 2007 From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 01:08:18 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A40416A402 for ; Fri, 9 Feb 2007 01:08:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4D59C13C441 for ; Fri, 9 Feb 2007 01:08:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l1917c57036740 for ; Thu, 8 Feb 2007 17:07:38 -0800 (PST) Date: Thu, 08 Feb 2007 17:07:31 -0800 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.92 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Networking FreeBSD Wiki 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, 09 Feb 2007 01:08:18 -0000 Hi, I've started a Wiki page in the FreeBSD Wiki in an attempt to coordinate some of the clean up work and networking projects that aren't already covered. Please see: http://wiki.freebsd.org/Networking and update (if you're a committer) or email me corrections etc. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 01:49:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E72316A400; Fri, 9 Feb 2007 01:49:46 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5291813C478; Fri, 9 Feb 2007 01:49:46 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l191ngX7023368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Feb 2007 17:49:43 -0800 Message-ID: <45CBD32E.40005@freebsd.org> Date: Thu, 08 Feb 2007 17:49:34 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dimitry Andric References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org> <45B676A2.5090009@andric.com> In-Reply-To: <45B676A2.5090009@andric.com> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6089CF940E21F2E6AA5806B" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? 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, 09 Feb 2007 01:49:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6089CF940E21F2E6AA5806B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Dimitry Andric wrote: > Bruce A. Mah wrote: > I mean that it may be that between -RELEASE and -STABLE, other things > have changed, e.g. network rc scripts, /sbin/route itself, etc, which > may also influence this behaviour. I'm sure more than only nd6.c > changed. :) The testing I did doesn't require any of that stuff, only a kernel, a shell, and ifconfig(8). I'm not aware of anything relevant. (As one of the RE types, I do follow commit mails pretty closely, especially during and just after a release cycle.) > However, for me, with the whole system at -STABLE (as of Jan 11), I > verified the following results again just now: >=20 > nd6.c rev state > --------- ----- > 1.48.2.12 works > 1.48.2.13 works > 1.48.2.14 works > 1.48.2.15 works > 1.48.2.16 doesn't work I've convinced myself that this problem needs to be tested in isolation (i.e. you have complete control over both ends of the tunnel) because incoming packets over the tunnel cause the host route to get added automatically if it wasn't there already. After reading the code and discussing this with a couple folks, I've managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their analogues on HEAD) need to go away. I've committed diffs that back these out, and they solve the problem for me in my testing (which I've done with two VMs in isolation). The applicable revisions for nd6.c are 1.74 (HEAD) and 1.48.2.18 (RELENG_6). Updating up to (or beyond) these revisions should clear up the problem. Testing reports from people who were having problems would be appreciated= =2E Bruce. --------------enigF6089CF940E21F2E6AA5806B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFy9My2MoxcVugUsMRAp5NAKC7+ik0mksLdVyNSUPaB/vlRuYVjgCg5wWD 4bgeibxwy1LGUijmNSAF4zo= =4R4l -----END PGP SIGNATURE----- --------------enigF6089CF940E21F2E6AA5806B-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 02:39:20 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8F0316A400; Fri, 9 Feb 2007 02:39:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B21C813C461; Fri, 9 Feb 2007 02:39:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l192dKbr034601; Fri, 9 Feb 2007 02:39:20 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l192dKgN034597; Fri, 9 Feb 2007 02:39:20 GMT (envelope-from bms) Date: Fri, 9 Feb 2007 02:39:20 GMT From: Bruce M Simpson Message-Id: <200702090239.l192dKgN034597@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-net@FreeBSD.org, bms@FreeBSD.org Cc: Subject: Re: kern/106999: [netgraph] [patch] ng_ksocket fails to clear multicast flag on mbuf before passing to stack 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, 09 Feb 2007 02:39:20 -0000 Synopsis: [netgraph] [patch] ng_ksocket fails to clear multicast flag on mbuf before passing to stack Responsible-Changed-From-To: freebsd-net->bms Responsible-Changed-By: bms Responsible-Changed-When: Fri Feb 9 02:39:10 UTC 2007 Responsible-Changed-Why: I'll take this http://www.freebsd.org/cgi/query-pr.cgi?pr=106999 From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 03:37:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 890E716A402 for ; Fri, 9 Feb 2007 03:37:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4B17E13C46B for ; Fri, 9 Feb 2007 03:37:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id CE3301A9015 for ; Thu, 8 Feb 2007 22:37:01 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Thu, 08 Feb 2007 22:37:01 -0500 X-Sasl-enc: 4gdHupjx03y2v3jUa7u62HywaZ3lo6Gh7aYBqgmlC5iV 1170992221 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 21E592973B for ; Thu, 8 Feb 2007 22:37:00 -0500 (EST) Message-ID: <45CBEC5C.4060900@incunabulum.net> Date: Fri, 09 Feb 2007 03:37:00 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------070503090209060701040608" Subject: [PATCH] make netinet MROUTING dynamically loadable with PIM 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, 09 Feb 2007 03:37:03 -0000 This is a multi-part message in MIME format. --------------070503090209060701040608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I plan to commit this soon as part of the mrouting cleanup. --------------070503090209060701040608 Content-Type: text/x-patch; name="ipv4-pim-module.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipv4-pim-module.diff" Bring the IPv4 multicast forwarding code more into line with the IPv6 version, by unconditionally building with PIM support enabled, and allowing it to be built as a loadable module. Use encap_attach_func() to hookup the IPPROTO_PIM input path. Keep the reserved identifier _PIM_VT around as some folks use this. TODO: Make the IPv6 multicast forwarding code dynamically loadable. Index: sys/conf/NOTES =================================================================== RCS file: /home/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1409 diff -u -p -r1.1409 NOTES --- sys/conf/NOTES 7 Feb 2007 18:55:29 -0000 1.1409 +++ sys/conf/NOTES 9 Feb 2007 01:59:43 -0000 @@ -807,10 +807,7 @@ device stf #6to4 IPv6 over IPv4 encap # Internet family options: # # MROUTING enables the kernel multicast packet forwarder, which works -# with mrouted(8). -# -# PIM enables Protocol Independent Multicast in the kernel. -# Requires MROUTING enabled. +# with mrouted and XORP. # # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends @@ -854,7 +851,6 @@ device stf #6to4 IPv6 over IPv4 encap # using the trpt(8) utility. # options MROUTING # Multicast routing -options PIM # Protocol Independent Multicast options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity Index: sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.575 diff -u -p -r1.575 options --- sys/conf/options 7 Feb 2007 18:55:29 -0000 1.575 +++ sys/conf/options 9 Feb 2007 01:59:43 -0000 @@ -352,7 +352,6 @@ ETHER_8023 opt_ef.h ETHER_8022 opt_ef.h ETHER_SNAP opt_ef.h MROUTING opt_mrouting.h -PIM opt_mrouting.h INET opt_inet.h INET6 opt_inet6.h IPSEC opt_ipsec.h Index: sys/netinet/in_proto.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_proto.c,v retrieving revision 1.82 diff -u -p -r1.82 in_proto.c --- sys/netinet/in_proto.c 3 Nov 2006 15:23:14 -0000 1.82 +++ sys/netinet/in_proto.c 9 Feb 2007 01:59:43 -0000 @@ -56,9 +56,6 @@ #include #include #include -#ifdef PIM -#include -#endif #include #include #include @@ -345,17 +342,6 @@ struct protosw inetsw[] = { .pr_usrreqs = &rip_usrreqs }, #endif -#ifdef PIM -{ - .pr_type = SOCK_RAW, - .pr_domain = &inetdomain, - .pr_protocol = IPPROTO_PIM, - .pr_flags = PR_ATOMIC|PR_ADDR|PR_LASTHDR, - .pr_input = pim_input, - .pr_ctloutput = rip_ctloutput, - .pr_usrreqs = &rip_usrreqs -}, -#endif /* PIM */ #ifdef DEV_PFSYNC { .pr_type = SOCK_RAW, @@ -438,9 +424,6 @@ SYSCTL_NODE(_net_inet, IPPROTO_AH, ipsec #endif /* IPSEC */ #endif /* !FAST_IPSEC */ SYSCTL_NODE(_net_inet, IPPROTO_RAW, raw, CTLFLAG_RW, 0, "RAW"); -#ifdef PIM -SYSCTL_NODE(_net_inet, IPPROTO_PIM, pim, CTLFLAG_RW, 0, "PIM"); -#endif #ifdef DEV_PFSYNC SYSCTL_NODE(_net_inet, IPPROTO_PFSYNC, pfsync, CTLFLAG_RW, 0, "PFSYNC"); #endif Index: sys/netinet/ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.126 diff -u -p -r1.126 ip_mroute.c --- sys/netinet/ip_mroute.c 8 Feb 2007 23:05:08 -0000 1.126 +++ sys/netinet/ip_mroute.c 9 Feb 2007 01:59:45 -0000 @@ -58,9 +58,7 @@ #include "opt_mac.h" #include "opt_mrouting.h" -#ifdef PIM #define _PIM_VT 1 -#endif #include #include @@ -91,10 +89,8 @@ #include #include #include -#ifdef PIM #include #include -#endif #include #include @@ -197,12 +193,27 @@ static u_int bw_upcalls_n; /* # of pendi static struct callout bw_upcalls_ch; #define BW_UPCALLS_PERIOD (hz) /* periodical flush of bw upcalls */ -#ifdef PIM static struct pimstat pimstat; + +SYSCTL_NODE(_net_inet, IPPROTO_PIM, pim, CTLFLAG_RW, 0, "PIM"); SYSCTL_STRUCT(_net_inet_pim, PIMCTL_STATS, stats, CTLFLAG_RD, &pimstat, pimstat, "PIM Statistics (struct pimstat, netinet/pim_var.h)"); +extern struct domain inetdomain; +struct protosw in_pim_protosw = { + .pr_type = SOCK_RAW, + .pr_domain = &inetdomain, + .pr_protocol = IPPROTO_PIM, + .pr_flags = PR_ATOMIC|PR_ADDR|PR_LASTHDR, + .pr_input = pim_input, + .pr_output = (pr_output_t*)rip_output, + .pr_ctloutput = rip_ctloutput, + .pr_usrreqs = &rip_usrreqs +}; +static const struct encaptab *pim_encap_cookie; +static int pim_encapcheck(const struct mbuf *, int, int, void *); + /* * Note: the PIM Register encapsulation adds the following in front of a * data packet: @@ -247,7 +258,6 @@ static struct pim_encap_pimhdr pim_encap static struct ifnet multicast_register_if; static vifi_t reg_vif_num = VIFI_INVALID; -#endif /* PIM */ /* * Private variables. @@ -296,7 +306,6 @@ static void bw_meter_process(void); static void expire_bw_upcalls_send(void *); static void expire_bw_meter_process(void *); -#ifdef PIM static int pim_register_send(struct ip *, struct vif *, struct mbuf *, struct mfc *); static int pim_register_send_rp(struct ip *, struct vif *, @@ -304,7 +313,6 @@ static int pim_register_send_rp(struct i static int pim_register_send_upcall(struct ip *, struct vif *, struct mbuf *, struct mfc *); static struct mbuf *pim_register_prepare(struct ip *, struct mbuf *); -#endif /* * whether or not special PIM assert processing is enabled. @@ -603,7 +611,7 @@ ip_mrouter_reset(void) callout_init(&bw_meter_ch, NET_CALLOUT_MPSAFE); } -static struct mtx mrouter_mtx; /* used to synch init/done work */ +static struct mtx mrouter_mtx; static void if_detached_event(void *arg __unused, struct ifnet *ifp) @@ -788,9 +796,7 @@ X_ip_mrouter_done(void) bzero(bw_meter_timers, sizeof(bw_meter_timers)); MFC_UNLOCK(); -#ifdef PIM reg_vif_num = VIFI_INVALID; -#endif mtx_unlock(&mrouter_mtx); @@ -883,7 +889,6 @@ add_vif(struct vifctl *vifcp) } /* Find the interface with an address in AF_INET family */ -#ifdef PIM if (vifcp->vifc_flags & VIFF_REGISTER) { /* * XXX: Because VIFF_REGISTER does not really need a valid @@ -891,9 +896,7 @@ add_vif(struct vifctl *vifcp) * check its address. */ ifp = NULL; - } else -#endif - { + } else { sin.sin_addr = vifcp->vifc_lcl_addr; ifa = ifa_ifwithaddr((struct sockaddr *)&sin); if (ifa == NULL) { @@ -907,7 +910,6 @@ add_vif(struct vifctl *vifcp) log(LOG_ERR, "tunnels are no longer supported\n"); VIF_UNLOCK(); return EOPNOTSUPP; -#ifdef PIM } else if (vifcp->vifc_flags & VIFF_REGISTER) { ifp = &multicast_register_if; if (mrtdebug) @@ -918,7 +920,6 @@ add_vif(struct vifctl *vifcp) multicast_register_if.if_flags = IFF_LOOPBACK; reg_vif_num = vifcp->vifc_vifi; } -#endif } else { /* Make sure the interface supports multicast */ if ((ifp->if_flags & IFF_MULTICAST) == 0) { VIF_UNLOCK(); @@ -984,10 +985,8 @@ del_vif_locked(vifi_t vifi) if (!(vifp->v_flags & (VIFF_TUNNEL | VIFF_REGISTER))) if_allmulti(vifp->v_ifp, 0); -#ifdef PIM if (vifp->v_flags & VIFF_REGISTER) reg_vif_num = VIFI_INVALID; -#endif bzero((caddr_t)vifp, sizeof (*vifp)); @@ -1571,12 +1570,10 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp * (since vifi_t is u_short, -1 becomes MAXUSHORT, which > numvifs.) */ if (xmt_vif < numvifs) { -#ifdef PIM if (viftable[xmt_vif].v_flags & VIFF_REGISTER) - pim_register_send(ip, viftable + xmt_vif, m, rt); + pim_register_send(ip, viftable + xmt_vif, m, rt); else -#endif - phyint_send(ip, viftable + xmt_vif, m); + phyint_send(ip, viftable + xmt_vif, m); return 1; } @@ -1603,10 +1600,8 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp struct timeval now; u_long delta; -#ifdef PIM if (ifp == &multicast_register_if) pimstat.pims_rcv_registers_wrongiif++; -#endif /* Get vifi for the incoming packet */ for (vifi=0; vifi < numvifs && viftable[vifi].v_ifp != ifp; vifi++) @@ -1674,12 +1669,10 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp if ((rt->mfc_ttls[vifi] > 0) && (ip->ip_ttl > rt->mfc_ttls[vifi])) { viftable[vifi].v_pkt_out++; viftable[vifi].v_bytes_out += plen; -#ifdef PIM if (viftable[vifi].v_flags & VIFF_REGISTER) pim_register_send(ip, viftable + vifi, m, rt); else -#endif - phyint_send(ip, viftable + vifi, m); + phyint_send(ip, viftable + vifi, m); } /* @@ -2516,7 +2509,6 @@ expire_bw_meter_process(void *unused) * End of bandwidth monitoring code */ -#ifdef PIM /* * Send the packet up to the user daemon, or eventually do kernel encapsulation * @@ -2739,6 +2731,21 @@ pim_register_send_rp(struct ip *ip, stru * (used by PIM-SM): the PIM header is stripped off, and the inner packet * is passed to if_simloop(). */ +static int +pim_encapcheck(const struct mbuf *m, int off, int proto, void *arg) +{ + struct ip *ip = mtod(m, struct ip *); + int hlen = ip->ip_hl << 2; + +#ifdef DIAGNOSTIC + KASSERT(proto == IPPROTO_PIM, ("not for IPPROTO_PIM")); +#endif + if (!IN_MULTICAST(ntohl(((struct ip *)((char *)ip+hlen))->ip_dst.s_addr))) + return 0; + + return 64; +} + void pim_input(struct mbuf *m, int off) { @@ -2971,7 +2978,6 @@ pim_input_to_daemon: return; } -#endif /* PIM */ static int ip_mroute_modevent(module_t mod, int type, void *unused) @@ -2982,6 +2988,15 @@ ip_mroute_modevent(module_t mod, int typ MFC_LOCK_INIT(); VIF_LOCK_INIT(); ip_mrouter_reset(); + pim_encap_cookie = encap_attach_func(AF_INET, IPPROTO_PIM, + pim_encapcheck, &in_pim_protosw, NULL); + if (pim_encap_cookie == NULL) { + printf("ip_mroute: unable to attach pim encap\n"); + VIF_LOCK_DESTROY(); + MFC_LOCK_DESTROY(); + mtx_destroy(&mrouter_mtx); + return (EINVAL); + } ip_mcast_src = X_ip_mcast_src; ip_mforward = X_ip_mforward; ip_mrouter_done = X_ip_mrouter_done; @@ -3006,6 +3021,11 @@ ip_mroute_modevent(module_t mod, int typ if (ip_mrouter) return EINVAL; + if (pim_encap_cookie) { + encap_detach(pim_encap_cookie); + pim_encap_cookie = NULL; + } + X_ip_mrouter_done(); ip_mcast_src = NULL; ip_mforward = NULL; --------------070503090209060701040608-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 03:39:52 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB66C16A408 for ; Fri, 9 Feb 2007 03:39:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id C1AC113C442 for ; Fri, 9 Feb 2007 03:39:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 74A101A9917; Thu, 8 Feb 2007 22:39:51 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Thu, 08 Feb 2007 22:39:51 -0500 X-Sasl-enc: R5DGLeYF4RhUpE2Il+5LSajOiF11CIG5je6pQp+32Nav 1170992391 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 018BF1434B; Thu, 8 Feb 2007 22:39:50 -0500 (EST) Message-ID: <45CBED06.3040800@FreeBSD.org> Date: Fri, 09 Feb 2007 03:39:50 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: gnn@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Networking FreeBSD Wiki 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, 09 Feb 2007 03:39:53 -0000 George, Thanks. I can think of a whole bunch of things to drop in here. gnn@freebsd.org wrote: > Hi, > > I've started a Wiki page in the FreeBSD Wiki in an attempt to > coordinate some of the clean up work and networking projects that > aren't already covered. Please see: > > http://wiki.freebsd.org/Networking > > and update (if you're a committer) or email me corrections etc. > > The ip_icmp.c change is low hanging fruit. ppsratecheck() beckons. BMS From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 08:27:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C81B016A401 for ; Fri, 9 Feb 2007 08:27:17 +0000 (UTC) (envelope-from Artis.Caune@latnet.lv) Received: from esbens.latnet.lv (esbens.latnet.lv [159.148.19.115]) by mx1.freebsd.org (Postfix) with ESMTP id 8265A13C49D for ; Fri, 9 Feb 2007 08:27:17 +0000 (UTC) (envelope-from Artis.Caune@latnet.lv) Received: from localhost (localhost.localdomain [127.0.0.1]) by esbens.latnet.lv (Postfix) with ESMTP id 726EE11DB53; Fri, 9 Feb 2007 10:00:10 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at esbens.latnet.lv Received: from esbens.latnet.lv ([127.0.0.1]) by localhost (esbens.latnet.lv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6A26ADYGzBw; Fri, 9 Feb 2007 10:00:05 +0200 (EET) Received: from [159.148.108.180] (artis.latnet.lv [159.148.108.180]) by esbens.latnet.lv (Postfix) with ESMTP id 81889FE619; Fri, 9 Feb 2007 10:00:05 +0200 (EET) Message-ID: <45CC2A05.3010801@latnet.lv> Date: Fri, 09 Feb 2007 10:00:05 +0200 From: Artis Caune User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070208092346.072F513C47E@mx1.freebsd.org> <45CB8C33.7020608@FreeBSD.org> <45CB964C.8090409@FreeBSD.org> In-Reply-To: <45CB964C.8090409@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steven Bens , Javier Henderson Subject: Re: Serious Bind issue 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, 09 Feb 2007 08:27:17 -0000 Doug Barton wrote: > Javier Henderson wrote: > >> FWIW, I was running BIND 9.3.2 for a while and in awe at the amount of >> memory it would use, and how it would go CPU bound after it hit any >> operating system imposed memory quotas. > > Many people have reported this problem, but no one has been able to > follow up on getting it fixed. > >> I went back to BIND 8.latest, and my problems went away. > > ... but only for the short term. Development has stopped on BIND 8, > and I'm planning to deprecate the BIND 8 ports now that FreeBSD 4.x > has been EOL'ed. BIND 9 is not even the wave of the future, it's now > the present, and if it's not working for you it's incumbent on you to > contact the bind-users@isc.org list and do what you can to help > diagnose this problem, and test the fixes. > > Doug > We have no problem with BIND 9.3.x. on 2.4 Xeon, 1G RAM: Getting ~1.6K queries per second. CPU: 11.5% user, 0.0% nice, 0.0% system, 1.9% interrupt, 86.5% idle PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 613 53 1 96 0 747M 746M RUN 0 62.7H 37.74% named # /boot/loader.conf kern.maxdsiz=1073741824 # named.conf max-cache-size 512M; recursive-clients 8192; and BIND is compiled with following changes: DNS_CACHE_CLEANERINCREMENT=256 in lib/dns/cache.c ISC_MEM_USE_INTERNAL_MALLOC=1 in lib/isc/mem.c And we get 1-3ms responses even while BIND is periodicaly cleaning cache and CPU is always idle. From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 08:30:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FAC116A402 for ; Fri, 9 Feb 2007 08:30:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6D513C4B4 for ; Fri, 9 Feb 2007 08:30:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so373060pye for ; Fri, 09 Feb 2007 00:30:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=QF/N2K09BaqtBzqFnyKeQrsxUB09eJ+OpJUTIk5w6FL9nL0xRPDl5jc3K4qXvDXWXV+H6HrFyyFnuSjyuvHRpMau+T+xzBxpC0PWV5q1cawg9FqRp+m5KpPNi8nTktu4bkPknBe1H68O7N0MGxdiyg4++oKMywfkQtKPka6Q3UY= Received: by 10.35.121.9 with SMTP id y9mr9678172pym.1171009808433; Fri, 09 Feb 2007 00:30:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 15sm15283856nzn.2007.02.09.00.30.06; Fri, 09 Feb 2007 00:30:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l198VEqR048164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 17:31:14 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l198VAMp048163; Fri, 9 Feb 2007 17:31:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 9 Feb 2007 17:31:10 +0900 From: Pyun YongHyeon To: Ed Schouten Message-ID: <20070209083110.GB37911@cdnetworks.co.kr> References: <20070206204314.GB27282@hoeg.nl> <20070207003756.GA37911@cdnetworks.co.kr> <20070207203938.GE27282@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207203938.GE27282@hoeg.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, shigeaki@se.hiroshima-u.ac.jp, Rink Springer Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 08:30:09 -0000 On Wed, Feb 07, 2007 at 09:39:38PM +0100, Ed Schouten wrote: > Hello, > > * Pyun YongHyeon wrote: > > Would you try overhauled nfe(4)? > > > > http://people.freebsd.org/~yongari/nfe/if_nfe.c > > http://people.freebsd.org/~yongari/nfe/if_nfereg.c > > http://people.freebsd.org/~yongari/nfe/if_nfevar.c > > > > The new nfe(4) should perform better than nve(4) or stock nfe(4). > > I'm still not satisfied with its excessive generation of interrtups > > but it's better than stock nfe(4). After switching to adaptive > > polling I saw noticeable performance boost. If you find any issues > > please let me know. > > I just compiled and installed a kernel with the new nfe(4) driver and > DEVICE_POLLING enabled. Below are the results of some scp(1) transfers: > > stock nfe(4): 2.5 MB/sec > new nfe(4): 3.7 MB/sec > polling: 4.1 MB/sec > > The driver is a lot better than the stock nfe(4). Are there any plans to > add the new nfe(4) to the sourcetree? > Yes, that's my goal. ATM I'm waiting for obrien@'s reply/review for the patched driver. Anyway thanks for reporting. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 10:27:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDE3116A400 for ; Fri, 9 Feb 2007 10:27:50 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6353F13C461 for ; Fri, 9 Feb 2007 10:27:50 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.8/8.13.8) with ESMTP id l199mvmF096593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 09:48:59 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <45CC4359.2070406@unsane.co.uk> Date: Fri, 09 Feb 2007 09:48:09 +0000 From: Vince User-Agent: Thunderbird 1.5.0.9 (X11/20070129) MIME-Version: 1.0 To: Randy Bush References: <17867.36807.577658.322763@roam.psg.com> In-Reply-To: <17867.36807.577658.322763@roam.psg.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: tuning 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: Fri, 09 Feb 2007 10:27:50 -0000 Randy Bush wrote: > any suggestions for how to tune freebsd tcp for very large bandwidth > delay product. doing daily rsync from oregon to australia over I2 > and aarnet. getting mediocre transfers. hints appreciated. > By the fact you CCed Andre, I assume you have tried the automatic TCP send and receive socket buffer sizing patches mentioned in the last status report? [http://www.freebsd.org/news/status/report-oct-2006-dec-2006.html#Automatic-TCP-Send-and-Receive-Socket-Buffer-Sizing] If not they might be worth a look. Vince > _______________________________________________ > 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 9 11:16:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE51C16A402 for ; Fri, 9 Feb 2007 11:16:15 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id DB2CD13C491 for ; Fri, 9 Feb 2007 11:16:14 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 57117 invoked by uid 1008); 9 Feb 2007 11:17:02 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7-unknown (2006-10-05) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.7 tests=AWL,BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.1.7-unknown Received: from unknown (HELO ?10.0.0.1?) (daniel@dgnetwork.com.br@200.243.216.36) by mail.mastercabo.com.br with SMTP; 9 Feb 2007 11:16:58 -0000 Message-ID: <45CC57ED.6090409@dgnetwork.com.br> Date: Fri, 09 Feb 2007 09:15:57 -0200 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: PF NAT LOG X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 11:16:15 -0000 I need to record logs of all connections nated from PF, has some way? Thanks. -- Daniel Dias Gonçalves DGNET Network Solutions daniel@dgnetwork.com.br http://www.dgnetwork.com.br/ +55 37-99824809 +55 37-32421109 From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 12:43:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD79016A400 for ; Fri, 9 Feb 2007 12:43:18 +0000 (UTC) (envelope-from tomas@tutus.se) Received: from fw-y.tutus.se (static-213-115-50-13.sme.bredbandsbolaget.se [213.115.50.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7701913C4A7 for ; Fri, 9 Feb 2007 12:43:17 +0000 (UTC) (envelope-from tomas@tutus.se) Received: from munin.tutus.se (munin.tutus.se [193.181.0.67]) by fw-y.tutus.se (omb_smtp 1.7) with ESMTP; (cipher=AES256-SHA from= verify=NO) Fri, 09 Feb 2007 13:26:29 +0100 (CET) Received: from [193.181.0.112] ([193.181.0.112]) by munin.tutus.se (8.13.6.20060614/8.13.6) with ESMTP id l19CQNZn006932 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 9 Feb 2007 13:26:26 +0100 (CET) Message-ID: <45CC686F.1050409@tutus.se> Date: Fri, 09 Feb 2007 13:26:23 +0100 From: Tomas Svensson User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: problem with ng_device as tun replacement 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, 09 Feb 2007 12:43:18 -0000 Hi, I am trying to replace the tun interface using netgraph by linking ng_device and ng_iface: ngctl mkpeer iface dummy inet ngctl mkpeer ng0: device inet inet then I try to use it as a drop-in replacement for tun, but it doesn't really work: 1. If I send an IP packet through /dev/ngd0 (after doing a normal open()), the packet doesn't get sent until I write a second packet to the device. 2. If i route packets to ng0: it works even worse, with very long and strange delays. I can do the same with tun and it works fine. I also tried using the netgraph user library to open a socket, and this works too (but I can't use it since the performance is very poor). Any ideas? -Tomas From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 12:48:08 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87D9416A401; Fri, 9 Feb 2007 12:48:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5F53613C4AA; Fri, 9 Feb 2007 12:48:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B31394CCB5; Fri, 9 Feb 2007 07:48:07 -0500 (EST) Date: Fri, 9 Feb 2007 12:48:07 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Bruce M. Simpson" In-Reply-To: <45CBED06.3040800@FreeBSD.org> Message-ID: <20070209124739.S55394@fledge.watson.org> References: <45CBED06.3040800@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: Networking FreeBSD Wiki 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, 09 Feb 2007 12:48:08 -0000 On Fri, 9 Feb 2007, Bruce M. Simpson wrote: > George, > > Thanks. I can think of a whole bunch of things to drop in here. I've added a reference to my personal network stack todo list page on the wiki also. Not sure if I should merge the two lists -- mine is rather long. Robert N M Watson Computer Laboratory University of Cambridge > > gnn@freebsd.org wrote: >> Hi, >> >> I've started a Wiki page in the FreeBSD Wiki in an attempt to >> coordinate some of the clean up work and networking projects that >> aren't already covered. Please see: >> >> http://wiki.freebsd.org/Networking >> >> and update (if you're a committer) or email me corrections etc. >> > > The ip_icmp.c change is low hanging fruit. ppsratecheck() beckons. > > BMS > _______________________________________________ > 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 9 13:28:18 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8CB116A406; Fri, 9 Feb 2007 13:28:18 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av9-1-sn3.vrr.skanova.net (av9-1-sn3.vrr.skanova.net [81.228.9.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6A79213C481; Fri, 9 Feb 2007 13:28:17 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1CB51385E2; Fri, 9 Feb 2007 13:55:38 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 038EF383DC; Fri, 9 Feb 2007 13:55:38 +0100 (CET) Received: from [192.168.1.192] (81-234-214-163-no68.tbcn.telia.com [81.234.214.163]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D7B8537E44; Fri, 9 Feb 2007 13:55:37 +0100 (CET) From: Joel Dahl To: gnn@freebsd.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 09 Feb 2007 13:55:50 +0100 Message-Id: <1171025750.1368.4.camel@dude.automatvapen.se> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Networking FreeBSD Wiki 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, 09 Feb 2007 13:28:18 -0000 Tor 2007-02-08 klockan 17:07 -0800 skrev gnn@freebsd.org: > Hi, > > I've started a Wiki page in the FreeBSD Wiki in an attempt to > coordinate some of the clean up work and networking projects that > aren't already covered. Please see: > > http://wiki.freebsd.org/Networking > > and update (if you're a committer) or email me corrections etc. How about moving stuff from the (outdated) dingo[*] project page to this wiki page instead? [*] http://www.freebsd.org/projects/dingo/ -- Joel From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 13:51:35 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E405816A400; Fri, 9 Feb 2007 13:51:35 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id B222413C4C2; Fri, 9 Feb 2007 13:51:35 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C19CA1AA008; Fri, 9 Feb 2007 08:51:33 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Fri, 09 Feb 2007 08:51:33 -0500 X-Sasl-enc: ffroEuywsm/2tyn1mtQ3inKnZNUKc+iOhQObI9X2XM7K 1171029093 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2823311050; Fri, 9 Feb 2007 08:51:32 -0500 (EST) Message-ID: <45CC7C65.4070800@FreeBSD.org> Date: Fri, 09 Feb 2007 13:51:33 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Joel Dahl References: <1171025750.1368.4.camel@dude.automatvapen.se> In-Reply-To: <1171025750.1368.4.camel@dude.automatvapen.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, net@freebsd.org Subject: Re: Networking FreeBSD Wiki 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, 09 Feb 2007 13:51:36 -0000 Joel Dahl wrote: > > How about moving stuff from the (outdated) dingo[*] project page to this > wiki page instead? > > [*] http://www.freebsd.org/projects/dingo/ > That's what he did. I feel a twinge of responsibility for this, and the stupid name. I have just totally steamrollered in and edited (merged some of my own tasks). I have a bunch of other stuff on my list which I'll add...! BMS From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 13:58:23 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 689F016A401 for ; Fri, 9 Feb 2007 13:58:23 +0000 (UTC) (envelope-from Artis.Caune@latnet.lv) Received: from krauklis.latnet.lv (krauklis.latnet.lv [159.148.19.113]) by mx1.freebsd.org (Postfix) with ESMTP id 20D2113C49D for ; Fri, 9 Feb 2007 13:58:23 +0000 (UTC) (envelope-from Artis.Caune@latnet.lv) Received: from localhost (localhost.localdomain [127.0.0.1]) by krauklis.latnet.lv (Postfix) with ESMTP id B3CE82BDF37 for ; Fri, 9 Feb 2007 15:58:21 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at krauklis.latnet.lv Received: from krauklis.latnet.lv ([127.0.0.1]) by localhost (krauklis.latnet.lv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+ieJXnYwt2q for ; Fri, 9 Feb 2007 15:58:21 +0200 (EET) Received: from [159.148.108.180] (artis.latnet.lv [159.148.108.180]) by krauklis.latnet.lv (Postfix) with ESMTP id 0EE012BDBFA for ; Fri, 9 Feb 2007 15:58:21 +0200 (EET) Message-ID: <45CC7DFC.7020306@latnet.lv> Date: Fri, 09 Feb 2007 15:58:20 +0200 From: Artis Caune User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: synchronising information between kernel modules 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, 09 Feb 2007 13:58:23 -0000 I would like to hear some ideas about how to synchronise information over network between two or more kernel modules. Topology: We have to FreeBSD boxes, which sit between two cisco switches and do traffic policy(shaping). Switches are connected with GigaChannel link (two physical links) and load balance traffic based on src,dst IP address. FreeBSD boxes sit between each physical GigaChannel link. Kernel module: It simpy pass or drop packets and increment counters. After every pass or drop or configuration change I need to tell other boxes about this action. I can use multicasts, like pfsync does, but multicasts are not reliable. If pfsync update is lost, it will be updated in next update or state time out. If our update is lost, specialy configuration update, bad things can happen. And there is problem with registering this module as kernel level multicast protocol - need to modify kernel sorurce and recompile. I can use ip_output and catch it on other box with pfil hooks, but it's not reliable. Maybe some kind of send_update + wait_for_ack option? I can also use userland daemon which establish conection with all peers and send/receive updates. Updates must be copied between kernel and userland. From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 14:09:09 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDA3316A406; Fri, 9 Feb 2007 14:09:09 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by mx1.freebsd.org (Postfix) with ESMTP id A1D7D13C4B7; Fri, 9 Feb 2007 14:09:09 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe ([134.130.3.36]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JD700J625UQDT40@mta-2.ms.rz.RWTH-Aachen.de>; Fri, 09 Feb 2007 14:08:50 +0100 (CET) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Fri, 09 Feb 2007 14:08:44 +0100 (MET) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.1/1) with ESMTP id l19D8aa6023384; Fri, 09 Feb 2007 14:08:42 +0100 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1HFTbV-0004K4-V3; Fri, 09 Feb 2007 12:07:45 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 962BD3F41B; Fri, 09 Feb 2007 12:07:45 +0100 (CET) Date: Fri, 09 Feb 2007 12:07:45 +0100 From: Christian Brueffer In-reply-to: To: gnn@freebsd.org Message-id: <20070209110745.GB1686@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=l76fUT7nc3MelDdI Content-disposition: inline X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: Networking FreeBSD Wiki 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, 09 Feb 2007 14:09:10 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 08, 2007 at 05:07:31PM -0800, gnn@freebsd.org wrote: > Hi, >=20 > I've started a Wiki page in the FreeBSD Wiki in an attempt to > coordinate some of the clean up work and networking projects that > aren't already covered. Please see: >=20 > http://wiki.freebsd.org/Networking >=20 > and update (if you're a committer) or email me corrections etc. >=20 Some of the stuff seems to come from http://www.freebsd.org/projects/dingo/ . Should we move all the entries to the wiki and simply nuke the dingo page? - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFzFYBbHYXjKDtmC0RAn/fAJ4uPdPz6KOSLneLRbXCh9KvoWVOQACgvA6J cAZhShqW1BQWK/YQ+NVe7uk= =9S6M -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 14:53:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44FAD16A400; Fri, 9 Feb 2007 14:53:16 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.149.33.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1156713C47E; Fri, 9 Feb 2007 14:53:15 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from d620 (84-12-184-253.dyn.gotadsl.co.uk [84.12.184.253]) by smtp.nildram.co.uk (Postfix) with ESMTP id 933E44F3AD; Fri, 9 Feb 2007 14:53:12 +0000 (GMT) From: "Greg Hennessy" To: , , Date: Fri, 9 Feb 2007 14:53:21 -0000 Message-ID: <000601c74c5a$0ed77f80$0201a8c0@d620> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45CC57ED.6090409@dgnetwork.com.br> Thread-Index: AcdMPdAEZYzNis8GSk2OMnMXajQh/gAG9Vwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: Subject: RE: PF NAT LOG 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, 09 Feb 2007 14:53:16 -0000 > > I need to record logs of all connections nated from PF, has some way? > Tag the nat rule and then apply that tag to an egress rule of the form pass out log quick on blah.... tagged natted Greg -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.17.32/677 - Release Date: 08/02/2007 21:04 From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 20:02:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B807816A402 for ; Fri, 9 Feb 2007 20:02:43 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id F19A213C4A5 for ; Fri, 9 Feb 2007 20:02:42 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id l19K2fCG084726 for ; Fri, 9 Feb 2007 23:02:41 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id l19K2eTx084725 for freebsd-net@freebsd.org; Fri, 9 Feb 2007 23:02:40 +0300 (MSK) (envelope-from yar) Date: Fri, 9 Feb 2007 23:02:40 +0300 From: Yar Tikhiy To: freebsd-net@freebsd.org Message-ID: <20070209200240.GI31439@comp.chem.msu.su> References: <45C9BC01.5010803@netfence.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45C9BC01.5010803@netfence.it> User-Agent: Mutt/1.5.9i Subject: Re: Bridging with two subnets 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, 09 Feb 2007 20:02:43 -0000 On Wed, Feb 07, 2007 at 12:46:09PM +0100, Andrea Venturoli wrote: > Hello. > I've got a firewall which has public IP xxx.xxx.xxx.2 on its first NIC. > This is bridged with a second NIC which holds xxx.xxx.xxx.0/24. > (I also have a third and fourth NIC which runs two private IP networks, > which are NATted, but I don't think this matters). > > Everything is ok, but now I'm in need to also have a second public IP > network on the second NIC, let's say yyy.yyy.yyy.0/24. > A single upstream router provides us both public nets, but obviously > with two different gateways (xxx.xxx.xxx.1 and yyy.yyy.yyy.1). > > The question is: is this possible? > > Do I only need to attach the additional yyy.yyy.yyy.0/24 boxes to the > same switch? > Do I need to ifconfig alias yyy.yyy.yyy.2 on the first NIC? > What about the gateway then? Do I still set the first one only? > > My answers would be: Yes, No, Yes. I thought I'd ask, however. My bet is Yes Yes No. Since your firewall does bridging between the two NICs, your yyy.* hosts attached to the second NIC should see yyy.1 transparently via the bridge. Just make sure your ipfw doesn't filter the traffic if you filter bridged packets. The only little problem will be that your firewall itself will see yyy.1 via its default route to xxx.1. Oh, and of course your yyy.* hosts must have their default routes set to yyy.1, not to yyy.2, which isn't there. Your xxx.* hosts' default route is xxx.1, isn't it? And IIRC you should assign IP addresses to the if_bridge interface itself if you want the bridging host to participate in the bridged network. -- Yar From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 20:06:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF74016A405; Fri, 9 Feb 2007 20:06:51 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 3A29513C467; Fri, 9 Feb 2007 20:06:50 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id l19JjFOU084134; Fri, 9 Feb 2007 22:45:15 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id l19Jj9tS084133; Fri, 9 Feb 2007 22:45:09 +0300 (MSK) (envelope-from yar) Date: Fri, 9 Feb 2007 22:45:09 +0300 From: Yar Tikhiy To: Brooks Davis Message-ID: <20070209194509.GH31439@comp.chem.msu.su> References: <20070206204314.GB27282@hoeg.nl> <20070207003756.GA37911@cdnetworks.co.kr> <20070207203938.GE27282@hoeg.nl> <20070207204636.GG70525@rink.nu> <20070207205310.GA82708@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207205310.GA82708@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.9i Cc: Pyun YongHyeon , Rink Springer , freebsd-net@freebsd.org, Ed Schouten , shigeaki@se.hiroshima-u.ac.jp, Rink Springer Subject: Re: icsphy(4) for nfe(4) - better Microsoft Xbox support 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, 09 Feb 2007 20:06:51 -0000 On Wed, Feb 07, 2007 at 02:53:10PM -0600, Brooks Davis wrote: > On Wed, Feb 07, 2007 at 09:46:36PM +0100, Rink Springer wrote: > > On Wed, Feb 07, 2007 at 09:39:38PM +0100, Ed Schouten wrote: > > > I just compiled and installed a kernel with the new nfe(4) driver and > > > DEVICE_POLLING enabled. Below are the results of some scp(1) transfers: > > > > scp(1) isn't really the best way to test this; the XBOX CPU cannot > > satisfy a 100mbit link using scp(1). FTP would be a much better idea, > > preferably with a large file. > > Much better (unless you want to see the effect of disk I/O) would be > something like benchmarks/netpipe. For simple benchmarking, I ftp /dev/zero to /dev/null with stock ftp(1) and ftpd(8), and it works. It can saturate FastEthernet on a sub-GHz CPU, giving the theoretical maximum of 11.2 Mbyte/s, if all the software and hardware involved DTRT. As to its sensitivity, once I could notice using the benchmark in NetBSD that ex(4) sucked by 20% against fxp(4). And the same benchmark via loopback in FreeBSD-CURRENT w/o any debug stuff showed a funny thing: just leaving BPF out from the kernel _reduced_ throughput by 1.41+-0.36% at 95% confidence. -- Yar From owner-freebsd-net@FreeBSD.ORG Fri Feb 9 20:54:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5576716A402 for ; Fri, 9 Feb 2007 20:54:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5AB13C441 for ; Fri, 9 Feb 2007 20:54:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 09 Feb 2007 12:31:21 -0800 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id BDC33125ADE; Fri, 9 Feb 2007 12:54:03 -0800 (PST) Message-ID: <45CCDF66.90505@elischer.org> Date: Fri, 09 Feb 2007 12:53:58 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Tomas Svensson References: <45CC686F.1050409@tutus.se> In-Reply-To: <45CC686F.1050409@tutus.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: problem with ng_device as tun replacement 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, 09 Feb 2007 20:54:06 -0000 Tomas Svensson wrote: > Hi, > > I am trying to replace the tun interface using netgraph by linking > ng_device and ng_iface: > > ngctl mkpeer iface dummy inet > ngctl mkpeer ng0: device inet inet > > then I try to use it as a drop-in replacement for tun, but it doesn't > really work: > > 1. If I send an IP packet through /dev/ngd0 (after doing a normal > open()), the packet doesn't get sent until I write a second packet to > the device. Do you know it the ng-device device is hanging onto it, or the ng_iface device is getting it but not passing it on? If you don't know, you can put a 'tee' node between them and use nghook(8) to see when the packet is passed between the nodes. > > 2. If i route packets to ng0: it works even worse, with very long and > strange delays. once again.. please use a TEE node to isolate the delays.. > > I can do the same with tun and it works fine. I also tried using the > netgraph user library to open a socket, and this works too (but I can't > use it since the performance is very poor). > Any ideas? > > -Tomas > > _______________________________________________ > 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 9 22:21:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FFB916A412; Fri, 9 Feb 2007 22:21:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [213.154.244.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF1F13C4B4; Fri, 9 Feb 2007 22:21:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTP id 0BDE2B80E; Fri, 9 Feb 2007 23:21:33 +0100 (CET) Message-ID: <45CCF3ED.1090704@andric.com> Date: Fri, 09 Feb 2007 23:21:33 +0100 From: Dimitry Andric User-Agent: Thunderbird 2.0pre (Windows/20070129) MIME-Version: 1.0 To: "Bruce A. Mah" References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121.020741.59649277.hrs@allbsd.org> <45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com> <45B421D4.2050008@freebsd.org> <45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org> <45B676A2.5090009@andric.com> <45CBD32E.40005@freebsd.org> In-Reply-To: <45CBD32E.40005@freebsd.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jhay@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? 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, 09 Feb 2007 22:21:36 -0000 Bruce A. Mah wrote: > I've convinced myself that this problem needs to be tested in isolation > (i.e. you have complete control over both ends of the tunnel) because > incoming packets over the tunnel cause the host route to get added > automatically if it wasn't there already. > > After reading the code and discussing this with a couple folks, I've > managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their > analogues on HEAD) need to go away. I've committed diffs that back > these out, and they solve the problem for me in my testing (which I've > done with two VMs in isolation). The applicable revisions for nd6.c are > 1.74 (HEAD) and 1.48.2.18 (RELENG_6). Updating up to (or beyond) these > revisions should clear up the problem. Confirmed. I've updated the machine on which I originally had this problem to -STABLE as of today, and the problem has disappeared. Thanks! From owner-freebsd-net@FreeBSD.ORG Sat Feb 10 17:00:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6798716A400 for ; Sat, 10 Feb 2007 17:00:10 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1DAEB13C474 for ; Sat, 10 Feb 2007 17:00:09 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 521851AA07F for ; Sat, 10 Feb 2007 12:00:08 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 10 Feb 2007 12:00:08 -0500 X-Sasl-enc: Ns+n6mBiogPGKvRRFtRfc5lr/Pm2EbgUd6HCjNy9kpIn 1171126807 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C0501111CB for ; Sat, 10 Feb 2007 12:00:07 -0500 (EST) Message-ID: <45CDFA18.3030102@incunabulum.net> Date: Sat, 10 Feb 2007 17:00:08 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------000001090107000501060704" Subject: [PATCH] Part 1 of low level 802.1p priority support 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, 10 Feb 2007 17:00:10 -0000 This is a multi-part message in MIME format. --------------000001090107000501060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is the first patch to bring in 802.1p Packet Priority to FreeBSD; this is to support Differentiated Services and Quality-of-Service. This builds on the M_VLANTAG support introduced by Andre last September. This first stage enables FreeBSD to pass packets for 802.1q with VLAN 0 to the main input path in the stack, which is the IEEE standards-compliant behaviour. With the attached patch and test packet, you can test this for yourself. Currently this is limited to interfaces which support VLAN_HWTAGGING. To make the change universal, an architectural change is needed; some of the inline 802.1q processing needs to be moved from if_vlan.c to if_ethersubr.c. To use this: 1. Apply attached patch on a separate machine to be used as a test peer. 2. Process attached hex dump with xxd from Vim distribution (editors/vim) to convert back to a binary pcap file. 3. Configure test address on test peer, preferably using a separate physical LAN. 4. Use ports/net-mgmt/tcpreplay to inject the traffic, with the appropriate IP and MAC addresses. 5. Observe that you get an ICMP echo reply back WITHOUT 802.1q encapsulation. Currently, the code deals only with receiving VLAN tags at a low level and does nothing about sending them. This is just the low level stuff -- QoS is not magically happening right now. Comments... testing... suggestions... Regards, BMS --------------000001090107000501060704 Content-Type: text/x-patch; name="8021p-part1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="8021p-part1.diff" ? .swp Index: if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.222 diff -u -p -r1.222 if_ethersubr.c --- if_ethersubr.c 24 Dec 2006 08:52:13 -0000 1.222 +++ if_ethersubr.c 10 Feb 2007 16:46:42 -0000 @@ -618,6 +618,7 @@ ether_demux(struct ifnet *ifp, struct mb struct ether_header *eh; int isr; u_short ether_type; + uint16_t vlanid; #if defined(NETATALK) struct llc *l; #endif @@ -627,6 +628,7 @@ ether_demux(struct ifnet *ifp, struct mb KASSERT(ifp != NULL, ("ether_demux: NULL interface pointer")); + vlanid = 0; eh = mtod(m, struct ether_header *); ether_type = ntohs(eh->ether_type); @@ -708,36 +710,44 @@ post_stats: */ if (m->m_flags & M_VLANTAG) { /* - * If no VLANs are configured, drop. + * Deal with numbered 802.1q VLANs, by passing frames for + * specifically numbered VLANs to the VLAN input handler. */ - if (ifp->if_vlantrunk == NULL) { - ifp->if_noproto++; - m_freem(m); + vlanid = EVL_VLANOFTAG(m->m_pkthdr.ether_vtag); + if (ifp->if_vlantrunk != NULL && vlanid != 0) { + KASSERT(vlan_input_p != NULL, + ("ether_input: VLAN not loaded!")); + (*vlan_input_p)(ifp, m); return; } /* - * vlan_input() will either recursively call ether_input() - * or drop the packet. + * Drop frames with VLAN encapsulation if VLANs are not + * configured on this interface, if and only if they did + * not contain 802.1p priority information. + * Such frames are preserved, because code further up the + * stack may use the 802.1p information. */ - KASSERT(vlan_input_p != NULL,("ether_input: VLAN not loaded!")); - (*vlan_input_p)(ifp, m); - return; + if (ifp->if_vlantrunk == NULL && vlanid != 0) { + ifp->if_noproto++; + m_freem(m); + return; + } } /* * Handle protocols that expect to have the Ethernet header * (and possibly FCS) intact. */ - switch (ether_type) { - case ETHERTYPE_VLAN: + if (ether_type == ETHERTYPE_VLAN && vlanid != 0) { if (ifp->if_vlantrunk != NULL) { - KASSERT(vlan_input_p,("ether_input: VLAN not loaded!")); + KASSERT(vlan_input_p, + ("ether_input: VLAN not loaded!")); (*vlan_input_p)(ifp, m); } else { ifp->if_noproto++; m_freem(m); + return; } - return; } /* Strip off Ethernet header. */ --------------000001090107000501060704 Content-Type: text/plain; name="8021qping.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="8021qping.txt" 0000000: d4c3 b2a1 0200 0400 0000 0000 0000 0000 ................ 0000010: ffff 0000 0100 0000 51ed cd45 e444 0d00 ........Q..E.D.. 0000020: 6600 0000 6600 0000 ffff ffff ffff 0010 f...f........... 0000030: c6bb 16f4 8100 0000 0800 4500 0054 258f ..........E..T%. 0000040: 0000 4001 4110 0a00 0005 0a00 0006 0800 ..@.A........... 0000050: ca41 4154 0000 45cd ed51 000c ce3b 0809 .AAT..E..Q...;.. 0000060: 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 ................ 0000070: 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 ...... !"#$%&'() 0000080: 2a2b 2c2d 2e2f 3031 3233 3435 3637 *+,-./01234567 --------------000001090107000501060704-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 10 18:28:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0766616A400 for ; Sat, 10 Feb 2007 18:28:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id BE0FB13C49D for ; Sat, 10 Feb 2007 18:28:43 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 10F511AA5A4 for ; Sat, 10 Feb 2007 13:28:42 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sat, 10 Feb 2007 13:28:42 -0500 X-Sasl-enc: nYCcm0Awt1WYZ47eo33+ireFqi32xCj4vaNwqvrTLVt/ 1171132121 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 638F42A45C for ; Sat, 10 Feb 2007 13:28:41 -0500 (EST) Message-ID: <45CE0ED9.1010905@FreeBSD.org> Date: Sat, 10 Feb 2007 18:28:41 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45CDFA18.3030102@incunabulum.net> In-Reply-To: <45CDFA18.3030102@incunabulum.net> Content-Type: multipart/mixed; boundary="------------010103080400010007000103" Subject: [PATCH] Part 2 of low level 802.1p priority support 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, 10 Feb 2007 18:28:44 -0000 This is a multi-part message in MIME format. --------------010103080400010007000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This updated patch moves VLAN tag decapsulation into if_ethersubr.c and always uses M_VLANTAG, which is also passed to the upper layer. Tests with ping: fxp (no VLAN_HWTAGGING support) OK msk (VLAN_HWTAGGING enabled) OK msk (VLAN_HWTAGGING disanabled) FAIL I am concerned that this may need review and testing to support situations where we do nested VLANs or with bridge(4) before it can be committed. Further testing with drivers is needed (I can't be 100% sure it fails with msk(4) because something strange is happening when vlan tagging is turned off). Perhaps Pyun knows? Regards, BMS --------------010103080400010007000103 Content-Type: text/x-patch; name="8021q-part2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="8021q-part2.diff" Index: if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.222 diff -u -p -r1.222 if_ethersubr.c --- if_ethersubr.c 24 Dec 2006 08:52:13 -0000 1.222 +++ if_ethersubr.c 10 Feb 2007 18:16:54 -0000 @@ -701,43 +701,50 @@ post_stats: } } #endif - /* - * Check to see if the device performed the VLAN decapsulation and - * provided us with the tag. + * If the device did not perform decapsulation of the 802.1q VLAN + * header itself, do this now, and tag the mbuf with M_VLANTAG. + * Remove the 802.1q header by copying the Ethernet addresses over + * it and adjusting the beginning of the data in the mbuf. + * Re-inspect the ether_type field so we do the right thing + * for VLAN 0. */ - if (m->m_flags & M_VLANTAG) { - /* - * If no VLANs are configured, drop. - */ - if (ifp->if_vlantrunk == NULL) { - ifp->if_noproto++; - m_freem(m); + if ((ether_type == ETHERTYPE_VLAN) && !(m->m_flags & M_VLANTAG)) { + struct ether_vlan_header *evl; + + if (m->m_len < sizeof(*evl) && + (m = m_pullup(m, sizeof(*evl))) == NULL) { + if_printf(ifp, "cannot pullup VLAN header\n"); return; } - /* - * vlan_input() will either recursively call ether_input() - * or drop the packet. - */ - KASSERT(vlan_input_p != NULL,("ether_input: VLAN not loaded!")); - (*vlan_input_p)(ifp, m); - return; + + evl = mtod(m, struct ether_vlan_header *); + m->m_pkthdr.ether_vtag = ntohs(evl->evl_tag); + m->m_flags |= M_VLANTAG; + bcopy((char *)evl, (char *)evl + ETHER_VLAN_ENCAP_LEN, + ETHER_HDR_LEN - ETHER_TYPE_LEN); + m_adj(m, ETHER_VLAN_ENCAP_LEN); + /* We need to see the inner type field in case of reentry. */ + eh = mtod(m, struct ether_header *); + ether_type = ntohs(eh->ether_type); } /* - * Handle protocols that expect to have the Ethernet header - * (and possibly FCS) intact. + * Deal with numbered 802.1q VLANs, by passing these frames to + * the VLAN input handler. Frames destined for VLAN 0 are for + * the main input path. Otherwise, drop frames with VLAN tags. */ - switch (ether_type) { - case ETHERTYPE_VLAN: + if ((m->m_flags & M_VLANTAG) && + EVL_VLANOFTAG(m->m_pkthdr.ether_vtag) != EVL_VLAN_ZERO) { if (ifp->if_vlantrunk != NULL) { - KASSERT(vlan_input_p,("ether_input: VLAN not loaded!")); + KASSERT(vlan_input_p, + ("ether_input: VLAN not loaded!")); (*vlan_input_p)(ifp, m); } else { ifp->if_noproto++; m_freem(m); + return; } - return; } /* Strip off Ethernet header. */ Index: if_vlan.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.117 diff -u -p -r1.117 if_vlan.c --- if_vlan.c 30 Dec 2006 21:10:25 -0000 1.117 +++ if_vlan.c 10 Feb 2007 18:16:54 -0000 @@ -911,51 +911,9 @@ vlan_input(struct ifnet *ifp, struct mbu uint16_t tag; KASSERT(trunk != NULL, ("%s: no trunk", __func__)); + KASSERT((m->m_flags & M_VLANTAG),("%s: M_VLANTAG not set", __func__)); - if (m->m_flags & M_VLANTAG) { - /* - * Packet is tagged, but m contains a normal - * Ethernet frame; the tag is stored out-of-band. - */ - tag = EVL_VLANOFTAG(m->m_pkthdr.ether_vtag); - m->m_flags &= ~M_VLANTAG; - } else { - struct ether_vlan_header *evl; - - /* - * Packet is tagged in-band as specified by 802.1q. - */ - switch (ifp->if_type) { - case IFT_ETHER: - if (m->m_len < sizeof(*evl) && - (m = m_pullup(m, sizeof(*evl))) == NULL) { - if_printf(ifp, "cannot pullup VLAN header\n"); - return; - } - evl = mtod(m, struct ether_vlan_header *); - tag = EVL_VLANOFTAG(ntohs(evl->evl_tag)); - - /* - * Remove the 802.1q header by copying the Ethernet - * addresses over it and adjusting the beginning of - * the data in the mbuf. The encapsulated Ethernet - * type field is already in place. - */ - bcopy((char *)evl, (char *)evl + ETHER_VLAN_ENCAP_LEN, - ETHER_HDR_LEN - ETHER_TYPE_LEN); - m_adj(m, ETHER_VLAN_ENCAP_LEN); - break; - - default: -#ifdef INVARIANTS - panic("%s: %s has unsupported if_type %u", - __func__, ifp->if_xname, ifp->if_type); -#endif - m_freem(m); - ifp->if_noproto++; - return; - } - } + tag = EVL_VLANOFTAG(m->m_pkthdr.ether_vtag); TRUNK_RLOCK(trunk); #ifdef VLAN_ARRAY Index: if_vlan_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan_var.h,v retrieving revision 1.25 diff -u -p -r1.25 if_vlan_var.h --- if_vlan_var.h 17 Sep 2006 13:33:29 -0000 1.25 +++ if_vlan_var.h 10 Feb 2007 18:16:54 -0000 @@ -43,6 +43,7 @@ struct ether_vlan_header { #define EVL_VLID_MASK 0x0FFF #define EVL_VLANOFTAG(tag) ((tag) & EVL_VLID_MASK) #define EVL_PRIOFTAG(tag) (((tag) >> 13) & 7) +#define EVL_VLAN_ZERO 0 /* 802.1p priority frames use VLAN 0. */ /* sysctl(3) tags, for compatibility purposes */ #define VLANCTL_PROTO 1 --------------010103080400010007000103-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 10 21:17:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EDDD16A400 for ; Sat, 10 Feb 2007 21:17:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id D8C9413C491 for ; Sat, 10 Feb 2007 21:17:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 28D911A9ACE for ; Sat, 10 Feb 2007 16:17:53 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 10 Feb 2007 16:17:53 -0500 X-Sasl-enc: IUcyb5tWDtwrGwhCr2gJJoSbHGJVTZLKob5lY2BhObhn 1171142272 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 91BC71569C for ; Sat, 10 Feb 2007 16:17:52 -0500 (EST) Message-ID: <45CE3680.2010103@incunabulum.net> Date: Sat, 10 Feb 2007 21:17:52 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------030408010207040301060400" Subject: [PATCH] Introduce M_PROMISC to lower part of Ethernet code 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, 10 Feb 2007 21:17:55 -0000 This is a multi-part message in MIME format. --------------030408010207040301060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Thunderbird keeps crashing whenever I draft these messages, which is frustrating. Can we discuss this change? I would like to get it in as we get the following wins: 1. Potentially cleaner code in ether_demux()/ether_input() 2. Ways of detecting and preventing L2/L3 forwarding loops 3. Being able to do more with promiscuous mode in general e.g. using it to emulate broken IFF_ALLMULTI with network cards which can't support multicast routing properly. Feedback eagerly looked forward to; this is not a complete change; this is strictly development quality at the moment. Regards, BMS --------------030408010207040301060400 Content-Type: text/x-patch; name="promisc2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="promisc2.diff" Index: net/if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.222 diff -u -p -r1.222 if_ethersubr.c --- net/if_ethersubr.c 24 Dec 2006 08:52:13 -0000 1.222 +++ net/if_ethersubr.c 10 Feb 2007 20:59:39 -0000 @@ -582,6 +582,7 @@ ether_input(struct ifnet *ifp, struct mb if (IFP2AC(ifp)->ac_netgraph != NULL) { KASSERT(ng_ether_input_p != NULL, ("ng_ether_input_p is NULL")); + m->m_flags &= ~M_PROMISC; (*ng_ether_input_p)(ifp, &m); if (m == NULL) return; @@ -598,6 +599,7 @@ ether_input(struct ifnet *ifp, struct mb * at the src/sys/netgraph/ng_ether.c:ng_ether_rcv_upper() */ if (ifp->if_bridge) { + m->m_flags &= ~M_PROMISC; BRIDGE_INPUT(ifp, m); if (m == NULL) return; @@ -634,6 +636,14 @@ ether_demux(struct ifnet *ifp, struct mb if (rule) /* packet was already bridged */ goto post_stats; #endif + /* + * If the frame was received promiscuously, mark it as such. + */ + if ((ifp->if_flags & IFF_PROMISC) && + !ETHER_IS_MULTICAST(eh->ether_dhost) && + bcmp(eh->ether_dhost, IF_LLADDR(ifp), ETHER_ADDR_LEN) != 0) { + m->m_flags |= M_PROMISC; + } if (!(ifp->if_bridge) && !((ether_type == ETHERTYPE_VLAN || m->m_flags & M_VLANTAG) && @@ -648,8 +658,10 @@ ether_demux(struct ifnet *ifp, struct mb * evaluation, to see if the carp ether_dhost values break any * of these checks! */ - if (ifp->if_carp && carp_forus(ifp->if_carp, eh->ether_dhost)) + if (ifp->if_carp && carp_forus(ifp->if_carp, eh->ether_dhost)) { + m->m_flags &= ~M_PROMISC; goto pre_stats; + } #endif /* * Discard packet if upper layers shouldn't see it because it @@ -662,14 +674,16 @@ ether_demux(struct ifnet *ifp, struct mb * give them a chance to consider it as well (e. g. in case * bridging is only active on a VLAN). They will drop it if * it's undesired. + * + * XXX: There is no way this check can be invoked if + * there are no VLANs attached to this parent interface, + * which is likely to cause recursion if we're acting + * as an IP forwarder... */ - if ((ifp->if_flags & IFF_PROMISC) != 0 - && !ETHER_IS_MULTICAST(eh->ether_dhost) - && bcmp(eh->ether_dhost, - IF_LLADDR(ifp), ETHER_ADDR_LEN) != 0 - && (ifp->if_flags & IFF_PPROMISC) == 0) { - m_freem(m); - return; + if ((m->m_flags & M_PROMISC) && + (ifp->if_flags & IFF_PPROMISC) == 0) { + m_freem(m); + return; } } @@ -720,6 +734,7 @@ post_stats: * or drop the packet. */ KASSERT(vlan_input_p != NULL,("ether_input: VLAN not loaded!")); + m->m_flags &= ~M_PROMISC; (*vlan_input_p)(ifp, m); return; } @@ -732,6 +747,7 @@ post_stats: case ETHERTYPE_VLAN: if (ifp->if_vlantrunk != NULL) { KASSERT(vlan_input_p,("ether_input: VLAN not loaded!")); + m->m_flags &= ~M_PROMISC; (*vlan_input_p)(ifp, m); } else { ifp->if_noproto++; Index: sys/mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.202 diff -u -p -r1.202 mbuf.h --- sys/mbuf.h 25 Jan 2007 01:05:23 -0000 1.202 +++ sys/mbuf.h 10 Feb 2007 20:59:40 -0000 @@ -182,6 +182,7 @@ struct mbuf { #define M_FIRSTFRAG 0x1000 /* packet is first fragment */ #define M_LASTFRAG 0x2000 /* packet is last fragment */ #define M_VLANTAG 0x10000 /* ether_vtag is valid */ +#define M_PROMISC 0x20000 /* packet was not for us */ /* * External buffer types: identify ext_buf type. @@ -203,7 +204,7 @@ struct mbuf { #define M_COPYFLAGS (M_PKTHDR|M_EOR|M_RDONLY|M_PROTO1|M_PROTO1|M_PROTO2|\ M_PROTO3|M_PROTO4|M_PROTO5|M_SKIP_FIREWALL|\ M_BCAST|M_MCAST|M_FRAG|M_FIRSTFRAG|M_LASTFRAG|\ - M_VLANTAG) + M_VLANTAG|M_PROMISC) /* * Flags to purge when crossing layers. --------------030408010207040301060400-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 10 22:09:08 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC8D016A4CB for ; Sat, 10 Feb 2007 22:09:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 86F7013C46B for ; Sat, 10 Feb 2007 22:09:06 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 95F331AA086; Sat, 10 Feb 2007 17:09:04 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 10 Feb 2007 17:09:04 -0500 X-Sasl-enc: OiUOOF8IVN6ZlJeF57JPYuYYds2njrLooFOTFVTY2nTg 1171145344 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id B13961570D; Sat, 10 Feb 2007 17:09:03 -0500 (EST) Message-ID: <45CE427F.7070308@incunabulum.net> Date: Sat, 10 Feb 2007 22:09:03 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Pavlin Radoslavov , Bill Fenner Content-Type: multipart/mixed; boundary="------------050805040700080004050009" Cc: net@FreeBSD.org Subject: [PATCH] Make INET6 MROUTING dynamically loadable in GENERIC 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, 10 Feb 2007 22:09:08 -0000 This is a multi-part message in MIME format. --------------050805040700080004050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This should do what it says on the tin... Regards, BMS --------------050805040700080004050009 Content-Type: text/x-patch; name="mrouting-ipv6-dyn.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mrouting-ipv6-dyn.diff" Make IPv6 multicast forwarding dynamically loadable into a GENERIC kernel. Index: conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.1175 diff -u -p -r1.1175 files --- conf/files 7 Feb 2007 18:55:29 -0000 1.1175 +++ conf/files 10 Feb 2007 22:07:19 -0000 @@ -1759,6 +1759,7 @@ netinet/ip_icmp.c optional inet netinet/ip_input.c optional inet netinet/ip_ipsec.c optional ipsec netinet/ip_ipsec.c optional fast_ipsec +netinet/ip_mroute.c optional inet | inet6 netinet/ip_mroute.c optional mrouting netinet/ip_options.c optional inet netinet/ip_output.c optional inet @@ -1814,7 +1815,7 @@ netinet6/in6_src.c optional inet6 netinet6/ip6_forward.c optional inet6 netinet6/ip6_id.c optional inet6 netinet6/ip6_input.c optional inet6 -netinet6/ip6_mroute.c optional inet6 +netinet6/ip6_mroute.c optional mrouting inet6 netinet6/ip6_output.c optional inet6 netinet6/ipcomp_core.c optional ipsec netinet6/ipcomp_input.c optional ipsec Index: modules/ip_mroute_mod/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/ip_mroute_mod/Makefile,v retrieving revision 1.14 diff -u -p -r1.14 Makefile --- modules/ip_mroute_mod/Makefile 9 Feb 2007 01:42:43 -0000 1.14 +++ modules/ip_mroute_mod/Makefile 10 Feb 2007 22:07:19 -0000 @@ -1,13 +1,21 @@ # $FreeBSD: src/sys/modules/ip_mroute_mod/Makefile,v 1.14 2007/02/09 01:42:43 bms Exp $ -.PATH: ${.CURDIR}/../../netinet +.PATH: ${.CURDIR}/../../netinet ${.CURDIR}/../../netinet6 KMOD= ip_mroute -SRCS= ip_mroute.c opt_mac.h opt_mrouting.h +SRCS= ip_mroute.c +SRCS+= ip6_mroute.c +SRCS+= opt_inet.h opt_inet6.h opt_mac.h opt_mrouting.h .if !defined(KERNBUILDDIR) +opt_inet.h: + echo "#define INET 1" > ${.TARGET} + +opt_inet6.h: + echo "#define INET6 1" > ${.TARGET} + opt_mrouting.h: - echo "#define MROUTING 1" > ${.TARGET} + echo "#define MROUTING 1" > ${.TARGET} .endif .include Index: netinet/ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.128 diff -u -p -r1.128 ip_mroute.c --- netinet/ip_mroute.c 10 Feb 2007 14:48:42 -0000 1.128 +++ netinet/ip_mroute.c 10 Feb 2007 22:07:20 -0000 @@ -55,6 +55,8 @@ * $FreeBSD: src/sys/netinet/ip_mroute.c,v 1.128 2007/02/10 14:48:42 bms Exp $ */ +#include "opt_inet.h" +#include "opt_inet6.h" #include "opt_mac.h" #include "opt_mrouting.h" @@ -217,6 +219,12 @@ struct protosw in_pim_protosw = { .pr_usrreqs = &rip_usrreqs }; static const struct encaptab *pim_encap_cookie; + +#ifdef INET6 +extern struct protosw in6_pim_protosw; /* ip6_mroute.c: struct in6_protosw */ +static const struct encaptab *pim6_encap_cookie; +#endif + static int pim_encapcheck(const struct mbuf *, int, int, void *); /* @@ -2737,7 +2745,7 @@ pim_register_send_rp(struct ip *ip, stru } /* - * pim_encapcheck() is called by the encap4_input() path at runtime to + * pim_encapcheck() is called by the encap[46]_input() path at runtime to * determine if a packet is for PIM; allowing PIM to be dynamically loaded * into the kernel. */ @@ -2995,6 +3003,10 @@ pim_input_to_daemon: return; } +/* + * XXX: This is common code for dealing with initialization for both + * the IPv4 and IPv6 multicast forwarding paths. It could do with cleanup. + */ static int ip_mroute_modevent(module_t mod, int type, void *unused) { @@ -3006,6 +3018,7 @@ ip_mroute_modevent(module_t mod, int typ ip_mrouter_reset(); TUNABLE_ULONG_FETCH("net.inet.pim.squelch_wholepkt", &pim_squelch_wholepkt); + pim_encap_cookie = encap_attach_func(AF_INET, IPPROTO_PIM, pim_encapcheck, &in_pim_protosw, NULL); if (pim_encap_cookie == NULL) { @@ -3015,6 +3028,23 @@ ip_mroute_modevent(module_t mod, int typ mtx_destroy(&mrouter_mtx); return (EINVAL); } + +#ifdef INET6 + pim6_encap_cookie = encap_attach_func(AF_INET6, IPPROTO_PIM, + pim_encapcheck, &in6_pim_protosw, NULL); + if (pim6_encap_cookie == NULL) { + printf("ip_mroute: unable to attach pim6 encap\n"); + if (pim_encap_cookie) { + encap_detach(pim_encap_cookie); + pim_encap_cookie = NULL; + } + VIF_LOCK_DESTROY(); + MFC_LOCK_DESTROY(); + mtx_destroy(&mrouter_mtx); + return (EINVAL); + } +#endif + ip_mcast_src = X_ip_mcast_src; ip_mforward = X_ip_mforward; ip_mrouter_done = X_ip_mrouter_done; @@ -3039,6 +3069,12 @@ ip_mroute_modevent(module_t mod, int typ if (ip_mrouter) return EINVAL; +#ifdef INET6 + if (pim6_encap_cookie) { + encap_detach(pim6_encap_cookie); + pim6_encap_cookie = NULL; + } +#endif if (pim_encap_cookie) { encap_detach(pim_encap_cookie); pim_encap_cookie = NULL; Index: netinet6/in6_proto.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_proto.c,v retrieving revision 1.40 diff -u -p -r1.40 in6_proto.c --- netinet6/in6_proto.c 3 Nov 2006 15:23:15 -0000 1.40 +++ netinet6/in6_proto.c 10 Feb 2007 22:07:21 -0000 @@ -335,7 +335,7 @@ struct ip6protosw inet6sw[] = { .pr_domain = &inet6domain, .pr_protocol = IPPROTO_PIM, .pr_flags = PR_ATOMIC|PR_ADDR|PR_LASTHDR, - .pr_input = pim6_input, + .pr_input = encap6_input, .pr_output = rip6_output, .pr_ctloutput = rip6_ctloutput, .pr_usrreqs = &rip6_usrreqs Index: netinet6/ip6_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_mroute.c,v retrieving revision 1.39 diff -u -p -r1.39 ip6_mroute.c --- netinet6/ip6_mroute.c 12 Dec 2006 12:17:57 -0000 1.39 +++ netinet6/ip6_mroute.c 10 Feb 2007 22:07:22 -0000 @@ -114,6 +114,7 @@ #include #include #include +#include #include #include @@ -130,6 +131,18 @@ static int socket_send __P((struct socke static int register_send __P((struct ip6_hdr *, struct mif6 *, struct mbuf *)); +extern struct domain inetdomain; +struct ip6protosw in6_pim_protosw = { + .pr_type = SOCK_RAW, + .pr_domain = &inetdomain, + .pr_protocol = IPPROTO_PIM, + .pr_flags = PR_ATOMIC|PR_ADDR|PR_LASTHDR, + .pr_input = pim6_input, + .pr_output = rip6_output, + .pr_ctloutput = rip6_ctloutput, + .pr_usrreqs = &rip6_usrreqs +}; + /* * Globals. All but ip6_mrouter, ip6_mrtproto and mrt6stat could be static, * except for netstat or debugging purposes. --------------050805040700080004050009-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 10 22:57:17 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3977516A406 for ; Sat, 10 Feb 2007 22:57:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2365113C4A3 for ; Sat, 10 Feb 2007 22:57:15 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 14F451787FD for ; Sat, 10 Feb 2007 17:57:14 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sat, 10 Feb 2007 17:57:14 -0500 X-Sasl-enc: V3mgNr9pyLuUaXS4w5aBoWObAIkhdbCSByxjB0SdMyln 1171148233 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5252617B8E for ; Sat, 10 Feb 2007 17:57:13 -0500 (EST) Message-ID: <45CE4DC9.4050605@incunabulum.net> Date: Sat, 10 Feb 2007 22:57:13 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: multipart/mixed; boundary="------------050407040501050603060107" Cc: Subject: [PATCH] netstat(1) should print CIDR prefixes 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, 10 Feb 2007 22:57:17 -0000 This is a multi-part message in MIME format. --------------050407040501050603060107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is a POLA violating 'let's move with the times' patch that gets rid of the special treatment of classful IPv4 network prefixes in 'netstat -rn' output. Comments please! Rgards, BMS --------------050407040501050603060107 Content-Type: text/x-patch; name="route-cidr-pola.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="route-cidr-pola.diff" Index: route.c =================================================================== RCS file: /home/ncvs/src/usr.bin/netstat/route.c,v retrieving revision 1.76 diff -u -p -r1.76 route.c --- route.c 13 May 2005 16:31:10 -0000 1.76 +++ route.c 10 Feb 2007 22:55:50 -0000 @@ -865,32 +865,7 @@ netname(u_long in, u_long mask) strncpy(line, cp, sizeof(line) - 1); line[sizeof(line) - 1] = '\0'; } else { - switch (dmask) { - case IN_CLASSA_NET: - if ((i & IN_CLASSA_HOST) == 0) { - sprintf(line, "%lu", C(i >> 24)); - break; - } - /* FALLTHROUGH */ - case IN_CLASSB_NET: - if ((i & IN_CLASSB_HOST) == 0) { - sprintf(line, "%lu.%lu", - C(i >> 24), C(i >> 16)); - break; - } - /* FALLTHROUGH */ - case IN_CLASSC_NET: - if ((i & IN_CLASSC_HOST) == 0) { - sprintf(line, "%lu.%lu.%lu", - C(i >> 24), C(i >> 16), C(i >> 8)); - break; - } - /* FALLTHROUGH */ - default: - sprintf(line, "%lu.%lu.%lu.%lu", - C(i >> 24), C(i >> 16), C(i >> 8), C(i)); - break; - } + inet_ntop(AF_INET, (char *)&in, line, sizeof(line) - 1); } domask(line + strlen(line), i, mask); return (line); --------------050407040501050603060107--