From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 00:37:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AF2D16A4E8 for ; Sun, 3 Sep 2006 00:37:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DDA343D76 for ; Sun, 3 Sep 2006 00:37:25 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1959314pye for ; Sat, 02 Sep 2006 17:37:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h1LMo8NQBfV2QhXdTxU1WNzKdF7AMPvb3YY6G1vxp7QY/SImZKeo6CuytQE2sSPtN9qMEUPfjH+ttPXGoLXt2ValRDrSI9W+Ps0v15Tdo5nKNv7WNYdGAkZxgXvOvT5/mhCnVSOpS7ym2Rm7sGCW0leOPRRr9Sm6JyH6O+TH6dA= Received: by 10.35.45.1 with SMTP id x1mr6472137pyj; Sat, 02 Sep 2006 17:37:24 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Sat, 2 Sep 2006 17:37:24 -0700 (PDT) Message-ID: <2a41acea0609021737q72d1af79kbc9ef45ac0102f7e@mail.gmail.com> Date: Sat, 2 Sep 2006 17:37:24 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44F9384C.9070902@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 03 Sep 2006 00:37:33 -0000 On 9/2/06, Andre Oppermann wrote: > Jack Vogel wrote: > > This is a patch for the stack and the em driver to enable TSO > > on CURRENT. Previously I had problems getting it to work, but > > this is functional. > > > > I should note that CURRENT is being a pain right now, when > > I comment out em in the config the kernel panics coming up, > > so I had to substitute this code into the tree. Rather bizarre :) > > > > I have this functionality running on a 6.1 based system, and > > our test group is already testing against that driver, so far > > things are looking good. > > > > I have designed it so the driver can continue to be built > > without support. There is also a sysctl in the stack code > > so you can set net.inet.tcp.tso_enable on or off and > > compare. > > > > I know there may be some refinements to add in, but I > > would like to get this into CURRENT as a start. > > I can't comment on the em part but the tcp_output.c stuff looks > very much like a straight port from NetBSD. If we take code from > the other BSDs we have to remark this in the emails we send with > patches and the commit message (otherwise we get accused of 'stealing > without attribution'). Although the code would work I have some ideas > to implement this in a different way for our stack (we have certain > divergence from the other BSDs). If you don't get an alternative > patch form me until this Thursday be free to go with this patch taking > into consideration Robert's comments and mine from your earlier version. Yes, I was planning on adding the code Robert talked about, it doesnt change anything fundamental in this patch. What I would like to see in some ways is an idea from what Linux does, but it would change the stack more than this does. We would remove all code that segments from tcp and do it just before calling the driver, in effect the routine Robert is talking about would be the normal path, doing software segmentation, and at that same point we would discover that the interface was TSO capable and call that. I think at that point we would have easy access to the ifp struct and it would eliminate the need for the discovery routine in tcp_subr.c. What were you thinking of doing? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 00:41:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE6316A4FF for ; Sun, 3 Sep 2006 00:41:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC45943D5F for ; Sun, 3 Sep 2006 00:41:53 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1960794pye for ; Sat, 02 Sep 2006 17:41:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AzxKvQb49BBLGFjckjGHMRGCSCA6BJWYTvJG0u8quwtowVibxrx8TPMUppq1//bUyzEUHb7ABzToyQDsADEhxbr4l60cZwykZsLfqI/L7Vrtg+khPrh6YxZvbm/6adf8EL6EC+6tZ6gRwViNqx8EgVADUj96DhosqSGPiASymhs= Received: by 10.35.60.15 with SMTP id n15mr6492232pyk; Sat, 02 Sep 2006 17:41:53 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Sat, 2 Sep 2006 17:41:53 -0700 (PDT) Message-ID: <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> Date: Sat, 2 Sep 2006 17:41:53 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44F9384C.9070902@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 03 Sep 2006 00:41:57 -0000 On 9/2/06, Andre Oppermann wrote: > I can't comment on the em part but the tcp_output.c stuff looks > very much like a straight port from NetBSD. If we take code from > the other BSDs we have to remark this in the emails we send with > patches and the commit message (otherwise we get accused of 'stealing > without attribution'). I dont know that I'd call it a straight port, rather I was working from some prototype code that Prafulla had working back on 4.7, but I think at that time that he may have patterned it after NetBSD. I certainly don't claim any grand originality here, we stop the tcp stack from segmenting so the hardware can do it :), but I have no problem attributing the NetBSD crew. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 02:20:29 2006 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 [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1675F16A4DF for ; Sun, 3 Sep 2006 02:20:29 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D41B243D5C for ; Sun, 3 Sep 2006 02:20:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k832KQFr011086 for ; Sun, 3 Sep 2006 02:20:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k832KQji011085; Sun, 3 Sep 2006 02:20:26 GMT (envelope-from gnats) Date: Sun, 3 Sep 2006 02:20:26 GMT Message-Id: <200609030220.k832KQji011085@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: George Mitchell Cc: Subject: Re: kern/102035: [plip] plip networking disables parallel port printing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: George Mitchell List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2006 02:20:29 -0000 The following reply was made to PR kern/102035; it has been noted by GNATS. From: George Mitchell To: bug-followup@freebsd.org Cc: Subject: Re: kern/102035: [plip] plip networking disables parallel port printing Date: Sat, 2 Sep 2006 19:12:18 -0700 (PDT) My apologies for the multiple screwed-up mailings of this patch! Here is the proper patch correctly formatted. Here is a corrected patch for this problem. In a default installation with IPv6 enabled, there will be attempts by both IPv4 and IPv6 to bring up plip[012]. The patch to rc.d/network_ipv6 detects when ipv6_ifconfig_plipn is set to NOAUTO. The patch to defaults/rc.conf sets both ifconfig_plip[012] and ipv6_ifconfig_plip[012] to NOAUTO, keeping the plip interfaces from being brought UP automatically. --- etc/defaults/rc.conf.orig Sat May 6 21:00:25 2006 +++ etc/defaults/rc.conf Sat Sep 2 10:29:53 2006 @@ -158,6 +158,10 @@ cloned_interfaces="" # List of cloned network interfaces to create. #cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config. ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. +# Average user does not want to start networking on plip[012]. +ifconfig_plip0="NOAUTO" +ifconfig_plip1="NOAUTO" +ifconfig_plip2="NOAUTO" #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0xffffffff" # Sample alias entry. #ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry. #ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0. @@ -358,6 +362,10 @@ #ipv6_prefix_ep0="fec0:0000:0000:0003 fec0:0000:0000:0004" # Examples for rtr. #ipv6_ifconfig_ed0="fec0:0:0:5::1 prefixlen 64" # Sample manual assign entry #ipv6_ifconfig_ed0_alias0="fec0:0:0:5::2 prefixlen 64" # Sample alias entry. +# Average user does not want to start networking on plip[012]. +ipv6_ifconfig_plip0="NOAUTO" +ipv6_ifconfig_plip!="NOAUTO" +ipv6_ifconfig_plip2="NOAUTO" ipv6_default_interface="NO" # Default output interface for scoped addrs. # Now this works only for IPv6 link local # multicast addrs. --- etc/rc.d/network_ipv6.orig Sat May 6 21:00:26 2006 +++ etc/rc.d/network_ipv6 Sat Sep 2 10:13:21 2006 @@ -47,8 +47,19 @@ case ${ipv6_network_interfaces} in [Aa][Uu][Tt][Oo]) - # Get a list of network interfaces - ipv6_network_interfaces="`ifconfig -l`" + # Get a list of network interfaces, minus the NOAUTO ones + ipv6_network_interfaces='' + _args="`ifconfig -l`" + for i in $_args; do + eval _arg=\$ipv6_ifconfig_$i + case $_arg in + [Nn][Oo][Aa][Uu][Tt][Oo]) + ;; + *) + ipv6_network_interfaces="$ipv6_network_interfaces $i" + ;; + esac + done ;; [Nn][Oo][Nn][Ee]) ipv6_network_interfaces='' From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 04:20:57 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9520516A4DD for ; Sun, 3 Sep 2006 04:20:57 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3835743D46 for ; Sun, 3 Sep 2006 04:20:53 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k834KpbY037189 for ; Sun, 3 Sep 2006 13:20:51 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sun, 3 Sep 2006 13:20:50 +0900 From: Norikatsu Shigemura To: freebsd-net@FreeBSD.org Message-Id: <20060903132050.454e2078.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 03 Sep 2006 13:20:51 +0900 (JST) Cc: Subject: How to use ng_atmllc(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: Sun, 03 Sep 2006 04:20:57 -0000 I am sometime using the environment IEEE802.1a SNAP on ethernet. But FreeBSD's network stack supports only EtherframeII as IP. So I researched how to use on IEEE802.1a SNAP. I think that following approch is good. But I couldn't do it:-(. # ngctl mkpeer . eiface if_ngeth ether # ngctl mkpeer . atmllc . ether (Does not create a node) # ngctl list There are 5 total nodes: Name: ngctl61978 Type: socket ID: 000000be Num hooks: 0 Name: ngeth0 Type: ether ID: 000000ae Num hooks: 0 Name: Type: eiface ID: 000000ad Num hooks: 0 Name: iwi0 Type: ether ID: 00000002 Num hooks: 0 Name: rl0 Type: ether ID: 00000001 Num hooks: 0 | +----+----+ | ngeth0 | +----+----+ | EtherframeII +----+----+ |ng_atmllc| +----+----+ | IEEE802.1a SNAP +----+----+ | rl0 | +----+----+ | Sorry, I cannot draw above network graph like 'ngctl dot' stlye. So I don't know that above graph is whether OK or NG. From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 04:48:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B3FE16A4DA for ; Sun, 3 Sep 2006 04:48:12 +0000 (UTC) (envelope-from nork@ninth-nine.com) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B517E43D45 for ; Sun, 3 Sep 2006 04:48:08 +0000 (GMT) (envelope-from nork@ninth-nine.com) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k834m5wT037785 for ; Sun, 3 Sep 2006 13:48:06 +0900 (JST) (envelope-from nork@ninth-nine.com) Date: Sun, 3 Sep 2006 13:48:05 +0900 From: Norikatsu Shigemura To: freebsd-net@freebsd.org Message-Id: <20060903134805.6712617e.nork@ninth-nine.com> In-Reply-To: <20060903132050.454e2078.nork@FreeBSD.org> References: <20060903132050.454e2078.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sun, 03 Sep 2006 13:48:06 +0900 (JST) Subject: Re: How to use ng_atmllc(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: Sun, 03 Sep 2006 04:48:12 -0000 On Sun, 3 Sep 2006 13:20:50 +0900 Norikatsu Shigemura wrote: > I am sometime using the environment IEEE802.1a SNAP on ethernet. > But FreeBSD's network stack supports only EtherframeII as IP. So > I researched how to use on IEEE802.1a SNAP. I think that following > approch is good. But I couldn't do it:-(. > # ngctl mkpeer . eiface if_ngeth ether > # ngctl mkpeer . atmllc . ether (Does not create a node) > # ngctl list > There are 5 total nodes: > Name: ngctl61978 Type: socket ID: 000000be Num hooks: 0 > Name: ngeth0 Type: ether ID: 000000ae Num hooks: 0 > Name: Type: eiface ID: 000000ad Num hooks: 0 > Name: iwi0 Type: ether ID: 00000002 Num hooks: 0 > Name: rl0 Type: ether ID: 00000001 Num hooks: 0 Oops, I missed. I'm testing until following level. # ngctl mkpeer . eiface if_ngeth ether # ngctl mkpeer ngeth0: atmllc lower ether # ngctl list There are 6 total nodes: Name: ngctl1269 Type: socket ID: 0000000f Num hooks: 0 Name: Type: atmllc ID: 0000000a Num hooks: 1 Name: ngeth0 Type: ether ID: 00000007 Num hooks: 1 Name: Type: eiface ID: 00000006 Num hooks: 0 Name: iwi0 Type: ether ID: 00000003 Num hooks: 0 Name: rl0 Type: ether ID: 00000002 Num hooks: 0 I have no idea to connect ngeth0 <-> rl0. > | > +----+----+ > | ngeth0 | > +----+----+ > | EtherframeII > +----+----+ > |ng_atmllc| > +----+----+ > | IEEE802.1a SNAP > +----+----+ > | rl0 | > +----+----+ > | > > Sorry, I cannot draw above network graph like 'ngctl dot' stlye. > So I don't know that above graph is whether OK or NG. From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 05:20:26 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C794216A4DE for ; Sun, 3 Sep 2006 05:20:26 +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 3951843D45 for ; Sun, 3 Sep 2006 05:20:26 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 13507 invoked by uid 399); 3 Sep 2006 05:20:25 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 3 Sep 2006 05:20:25 -0000 Message-ID: <44FA6616.8080806@FreeBSD.org> Date: Sat, 02 Sep 2006 22:20:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: George Mitchell References: <200609030220.k832KQji011085@freefall.freebsd.org> In-Reply-To: <200609030220.k832KQji011085@freefall.freebsd.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/102035: [plip] plip networking disables parallel port printing 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, 03 Sep 2006 05:20:26 -0000 Your approach is interesting, but I'm not sure I like the idea of adding a new semantic to the defaults file. Would you consider instead modifying network6_interface_setup in network.subr to not automatically configure a plip interface if ipv6_ifconfig_plipN is unset or null? That would accomplish the same thing, but it would be behind the scenes. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 11:50:25 2006 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 [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 222EB16A4DF for ; Sun, 3 Sep 2006 11:50:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC96643D46 for ; Sun, 3 Sep 2006 11:50:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k83BoOoA061850 for ; Sun, 3 Sep 2006 11:50:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k83BoOQw061848; Sun, 3 Sep 2006 11:50:24 GMT (envelope-from gnats) Date: Sun, 3 Sep 2006 11:50:24 GMT Message-Id: <200609031150.k83BoOQw061848@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stefan Bethke Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stefan Bethke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2006 11:50:25 -0000 The following reply was made to PR kern/102607; it has been noted by GNATS. From: Stefan Bethke To: bug-followup@FreeBSD.org, Radim Kolar Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address Date: Sun, 3 Sep 2006 13:40:05 +0200 The example obviously should read ifconfig_bridge0="link 12:34:56:78:9a:bc addm em0 addm em1 DHCP" Thanks Radim for pointing this out. From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 12:49:55 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA15A16A4DA for ; Sun, 3 Sep 2006 12:49:54 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6768643D45 for ; Sun, 3 Sep 2006 12:49:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k83CnpXY070561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Sep 2006 16:49:52 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k83Cnpos070560; Sun, 3 Sep 2006 16:49:51 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 3 Sep 2006 16:49:51 +0400 From: Gleb Smirnoff To: Rob Watt Message-ID: <20060903124951.GK40020@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Rob Watt , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Intel em receive hang and possible pr #72970 + some offtop 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, 03 Sep 2006 12:49:55 -0000 Rob, to compile the driver taken from RELENG_6 branch on the 6.0-RELEASE (or 6.1-RELEASE) system you need to also merge this commit into your system: http://lists.freebsd.org/pipermail/cvs-src/2006-July/065867.html After this driver from RELENG_6 will be buildable. I wonder, why noone in the thread had mention this? .... And I will also add my opinion on this thread, since many people has expressed theirs. If one experiences a bug in a FreeBSD release, and he/she asserts that he/she is not going to install STABLE branch snapshop on their system, because he/she has a very mission critical installation and STABLE branch is a crap, then he/she has three options: - Merge the necessary bugfix and its dependencies theirselves. If one has such mission critical installation, then he/she should have an employee experienced enough to run few cvs(1) commands. - Find a person who can do this. Pay him. - Find a person who can do this for free. Ask him kindly, and he will help. It took me 15 seconds to find the URL above. It will take me 5 - 10 minutes to prepare ready patch for 6.1-RELEASE. I'll probably help one, if he/she asks me. However, I'd prefer to point at actual CVS revisions and ask to do the merge theirselves. Well, I've already moved this post to offtopic, and I will continue. Rob, the below isn't said directly to you. This is what I'd like to say to many FreeBSD users. I'm always disappointed when I read about somebody strongly refusing to install STABLE. You know, the releases you trust in are cut from this branch! The more people install STABLE, the better the release would be, because more bugs will be uncovered. This is the community's contribution to the FreeBSD, the price of the free software. One may say that his installation is too commercially important to test STABLE on it, and refuse to do so. Well, apart from the fact that this man is using a free thingie without giving anything back, it may happen that he didn't avoid the bugs he tried to. It may happen, that the bug he would found if installed STABLE, was not found during release process and leaked into next FreeBSD release. Then he installs release and experiences this bug. Due to his "release only" policy, he needs to wait for the next one, again not testing it. Believe me, I've seen several such cases. At my job, I install STABLE on important servers about two or three times between releases. And this servers aren't less important than someone's else. There are a number of ways to test new software (and hardware as well) in a safe manner, so that if anything goes wrong, you have ability either switch to backup, or quickly rollback to previous version. This is a day to day sysadmin job - test forthcoming changes. For example, this week we have upgraded few servers to STABLE, so that we test it and 6.2-RELEASE won't give us any surprises. If we find any bugs, we would report about them or fix them ourselves. And when 6.2-RELEASE comes out, we will upgrade the rest of the servers being sure in this release. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 13:22:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8A4716A4DE for ; Sun, 3 Sep 2006 13:22:19 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5067143D46 for ; Sun, 3 Sep 2006 13:22:18 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 3F5B833CAF; Sun, 3 Sep 2006 15:22:14 +0200 (SAST) Date: Sun, 3 Sep 2006 15:22:14 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20060903132214.GA40993@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ipv6 host routes 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, 03 Sep 2006 13:22:19 -0000 Hi, Does anybody know how to add a direct IPv6 host route that actually works? What I mean is not through a gateway, but for one directly reachable. I know it normally isn't needed because it will just work, but I'm trying to add FreeBSD IPv6 capability to net/olsrd. It looks like I have most of the rest working, but this is one of the last things tripping me up. I have played for most of the morning with various incantations of "route add -inet6 -host ..." and just get various non working routes. For my test I have the machines configured on the same IPv6 subnet and without adding anything special I can ping them, but not after adding a route. The reason they (the olsr guys) do it is so that a router can have multiple WiFi interfaces all configured on the same subnet. Then when they get comms with a machine, they can add a route to it through that interface. At the moment I'm not even at the point of trying to get multiple interfaces on the same subnet working, although I would like to do that in the future. It would help if you have a high-site with multiple antennas and radios. So anybody that know how to add a direct IPv6 host route on FreeBSD? Thanks. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 14:14:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7BB916A4E1 for ; Sun, 3 Sep 2006 14:14:12 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A2F243D66 for ; Sun, 3 Sep 2006 14:14:11 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 5455 invoked from network); 3 Sep 2006 13:59:45 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Sep 2006 13:59:45 -0000 Message-ID: <44FAE332.4010209@freebsd.org> Date: Sun, 03 Sep 2006 16:14:10 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org, silby@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Improved TCP syncookie implementation 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, 03 Sep 2006 14:14:12 -0000 I've pretty much rewritten our implementation of TCP syncookies to get rid of some locking in TCP syncache and to improve their functionality. The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK optional feature information. This means that a FreeBSD host may run with syncookies only and not degrade TCP connections made through it. All important TCP connection setup negotiated options are preserved (send/receive window scaling, SACK, MSS) without storing any state on the host during the SYN-SYN/ACK phase. As a nice side effect the timestamps we respond with are randomized instead of directly using ticks (which reveals out uptime). http://people.freebsd.org/~andre/syncookies-20060903.diff Please test and report any problems. To run with syncookies only do: sysctl net.inet.tcp.syncookies_only=1 More information about syncookies below my sig. -- Andre /* * The purpose of SYN cookies is to avoid keeping track of all SYN's we * receive and to be able to handle SYN floods from bogus source addresses * (where we will never receive any reply). SYN floods try to exhaust all * our memory and available slots in the SYN cache table to cause a denial * of service to legitimate users of the local host. * * The idea of SYN cookies is to encode and include all necessary information * about the connection setup state within the SYN-ACK we send back and thus * to get along without keeping any local state until the ACK to the SYN-ACK * arrives (if ever). Everything we need to know should be available from * the information we encoded in the SYN-ACK. * * More information about the theory behind SYN cookies and its first * discussion and specification can be found at: * http://cr.yp.to/syncookies.html (overview) * http://cr.yp.to/syncookies/archive (gory details) * * This implementation extends the orginal idea and first implementation * of FreeBSD by using not only the initial sequence number field to store * information but also the timestamp field if present. This way we can * keep track of the entire state we need to know to recreate the session in * its original form. Almost all TCP speakers implement RFC1323 timestamps * these days. For those that do not we still have to live with the known * shortcomings of the ISN only SYN cookies. * * Cookie layers: * * Initial sequence number we send: * 31|................................|0 * DDDDDDDDDDDDDDDDDDDDDDDDDMMMRRRP * D = MD5 Digest (first dword) * M = MSS index * R = Rotation of secret * P = Odd or Even secret * * The MD5 Digest is computed with over following parameters: * a) randomly rotated secret * b) struct in_conninfo containing the remote/local ip/port (IPv4&IPv6) * c) the received initial sequence number from remote host * * Timestamp we send: * 31|................................|0 * DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 * D = MD5 Digest (third dword) (only as filler) * S = Requested send window scale * R = Requested receive window scale * A = SACK allowed * 5 = TCP-MD5 enabled (not implemented yet) * XORed with MD5 Digest (forth dword) * * The timestamp isn't cryptographically secure and doesn't need to be. * The double use of the MD5 digest dwords ties it to a specific remote/ * local host/port, remote initial sequence number and our local time * limited secret. A received timestamp is reverted (XORed) and then * the contained MD5 dword is compared to the computed one to ensure the * timestamp belongs to the SYN-ACK we sent. The other parameters may * have been tampered with but this isn't different from supplying bogus * values in the SYN in the first place. * * Some problems with SYN cookies remain however: * * Consider the problem of a recreated (and retransmitted) cookie. If the * original SYN was accepted, the connection is established. The second * SYN is inflight, and if it arrives with an ISN that falls within the * receive window, the connection is killed. */ From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 17:16:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CC5216A4DA; Sun, 3 Sep 2006 17:16:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F4C43D5C; Sun, 3 Sep 2006 17:16:18 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060903171616m9100h3qo8e>; Sun, 3 Sep 2006 17:16:17 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k83HGFui046267; Sun, 3 Sep 2006 12:16:15 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k83HGF1i046266; Sun, 3 Sep 2006 12:16:15 -0500 (CDT) (envelope-from brooks) Date: Sun, 3 Sep 2006 12:16:11 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20060903171610.GB45627@lor.one-eyed-alien.net> References: <200609030220.k832KQji011085@freefall.freebsd.org> <44FA6616.8080806@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <44FA6616.8080806@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, George Mitchell Subject: Re: kern/102035: [plip] plip networking disables parallel port printing 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, 03 Sep 2006 17:16:19 -0000 --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 02, 2006 at 10:20:22PM -0700, Doug Barton wrote: > Your approach is interesting, but I'm not sure I like the idea of adding a > new semantic to the defaults file. >=20 > Would you consider instead modifying network6_interface_setup in > network.subr to not automatically configure a plip interface if > ipv6_ifconfig_plipN is unset or null? That would accomplish the same thin= g, > but it would be behind the scenes. That's a fairly significant change since there's no requirement to explicit= ly set an address for an IPv6 interface and this would suddenly require it. It may be that the right thing to do with IPv6 interfaces is to require that ipv6_ifconfig_ifn be set to something but that would be a change. In many ways I think the best thing to do is remove plip from GENERIC and be done with it. -- Brooks --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE+w3aXY6L6fI4GtQRAgGjAKCYZSf77LUkUobgql1c/w7CmbBnNACghDv4 ZJ1Qm5wck6jAYO/brE3CWEY= =63KJ -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 19:09:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21EBD16A4DD; Sun, 3 Sep 2006 19:09:45 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 836A243D49; Sun, 3 Sep 2006 19:09:44 +0000 (GMT) (envelope-from george@m5p.com) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) by mailhost.m5p.com (8.13.7/8.13.7) with ESMTP id k83J9gSU021684 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK); Sun, 3 Sep 2006 12:09:42 -0700 (PDT) Received: (from defang@localhost) by m5p.com (8.13.7/8.13.7/Submit) id k83J4nm1021633; Sun, 3 Sep 2006 12:04:49 -0700 (PDT) X-Authentication-Warning: ashmont.m5p.com: defang set sender to using -f Received: from m5p.com (ssh.m5p.com [2001:418:3fd::fb]) by mailhost.m5p.com (envelope-sender ) (MIMEDefang) with ESMTP id k83J4nRa021632; Sun, 03 Sep 2006 12:04:49 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.13.7/8.13.7/Submit) id k83J4kJL008654; Sun, 3 Sep 2006 12:04:46 -0700 (PDT) Date: Sun, 3 Sep 2006 12:04:46 -0700 (PDT) From: George Mitchell Message-Id: <200609031904.k83J4kJL008654@m5p.com> To: brooks@one-eyed-alien.net, dougb@freebsd.org In-Reply-To: <20060903171610.GB45627@lor.one-eyed-alien.net> X-Spam-Score: -2.313 () BAYES_00,NO_RELAYS X-Scanned-By: MIMEDefang 2.56 on IPv6:2001:418:3fd::f7 Cc: freebsd-net@freebsd.org, george@m5p.com Subject: Re: kern/102035: [plip] plip networking disables parallel port printing 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, 03 Sep 2006 19:09:45 -0000 Brooks Davis wrote: > > On Sat, Sep 02, 2006 at 10:20:22PM -0700, Doug Barton wrote: > > Your approach is interesting, but I'm not sure I like the idea of adding a > > new semantic to the defaults file. > >=20 > > Would you consider instead modifying network6_interface_setup in > > network.subr to not automatically configure a plip interface if > > ipv6_ifconfig_plipN is unset or null? That would accomplish the same thin= > g, > > but it would be behind the scenes. > > That's a fairly significant change since there's no requirement to explicit= > ly > set an address for an IPv6 interface and this would suddenly require it. > It may be that the right thing to do with IPv6 interfaces is to require > that ipv6_ifconfig_ifn be set to something but that would be a change. There's no need to require an address for IPv6 interfaces in general. All I would like to see is recognizing 'ipv6_ifconfig_="NOAUTO"', which certainly parallels the IPv4 situation. > In many ways I think the best thing to do is remove plip from GENERIC > and be done with it. > > -- Brooks I've discovered I omitted an important precondition to my bug: it requires ipv6_gateway_enable to be set to YES. So, here is the true set of circumstances which leads to the problem: ipv6_enable="YES" ipv6_gateway_enable="YES" GENERIC kernel Removing plip from GENERIC would definitely solve this problem. -- George Mitchell P.S. Speaking of IPv6 networking, could someone take a quick look at bug 102701, with my patch for an IPv6 ifconfig problem? From owner-freebsd-net@FreeBSD.ORG Sun Sep 3 19:29:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D9C316A4E5 for ; Sun, 3 Sep 2006 19:29:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 046D943D6E for ; Sun, 3 Sep 2006 19:29:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 7456 invoked from network); 3 Sep 2006 19:15:11 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Sep 2006 19:15:11 -0000 Message-ID: <44FB2D21.2020604@freebsd.org> Date: Sun, 03 Sep 2006 21:29:37 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021737q72d1af79kbc9ef45ac0102f7e@mail.gmail.com> In-Reply-To: <2a41acea0609021737q72d1af79kbc9ef45ac0102f7e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 03 Sep 2006 19:29:46 -0000 Jack Vogel wrote: > On 9/2/06, Andre Oppermann wrote: >> Jack Vogel wrote: >> > This is a patch for the stack and the em driver to enable TSO >> > on CURRENT. Previously I had problems getting it to work, but >> > this is functional. >> > >> > I should note that CURRENT is being a pain right now, when >> > I comment out em in the config the kernel panics coming up, >> > so I had to substitute this code into the tree. Rather bizarre :) >> > >> > I have this functionality running on a 6.1 based system, and >> > our test group is already testing against that driver, so far >> > things are looking good. >> > >> > I have designed it so the driver can continue to be built >> > without support. There is also a sysctl in the stack code >> > so you can set net.inet.tcp.tso_enable on or off and >> > compare. >> > >> > I know there may be some refinements to add in, but I >> > would like to get this into CURRENT as a start. >> >> I can't comment on the em part but the tcp_output.c stuff looks >> very much like a straight port from NetBSD. If we take code from >> the other BSDs we have to remark this in the emails we send with >> patches and the commit message (otherwise we get accused of 'stealing >> without attribution'). Although the code would work I have some ideas >> to implement this in a different way for our stack (we have certain >> divergence from the other BSDs). If you don't get an alternative >> patch form me until this Thursday be free to go with this patch taking >> into consideration Robert's comments and mine from your earlier version. > > Yes, I was planning on adding the code Robert talked about, it doesnt > change anything fundamental in this patch. > > What I would like to see in some ways is an idea from what Linux does, > but it would change the stack more than this does. We would remove > all code that segments from tcp and do it just before calling the driver, > in effect the routine Robert is talking about would be the normal path, > doing software segmentation, and at that same point we would discover > that the interface was TSO capable and call that. I think at that point > we would have easy access to the ifp struct and it would eliminate the > need for the discovery routine in tcp_subr.c. I'm not sure this is necessarily the way to go. We don't want to marry the higher layer code too closely to the lower layers. > What were you thinking of doing? Please check out my TSO patch here: http://people.freebsd.org/~andre/tso-20060903.diff It compiles but I haven't tested it live traffic yet. My approach is quite different from the NetBSD one your patch is based on. IMO the NetBSD approach is not entirely correct given the actual code flow in tcp_output. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 02:44:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31F9416A4DA for ; Mon, 4 Sep 2006 02:44:26 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF7543D49 for ; Mon, 4 Sep 2006 02:44:25 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k842iFjv011846; Sun, 3 Sep 2006 19:44:15 -0700 (PDT) Date: Mon, 04 Sep 2006 11:04:44 +0900 Message-ID: From: gnn@freebsd.org To: John Hay In-Reply-To: <20060903132214.GA40993@zibbi.meraka.csir.co.za> References: <20060903132214.GA40993@zibbi.meraka.csir.co.za> 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.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host routes 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, 04 Sep 2006 02:44:26 -0000 At Sun, 3 Sep 2006 15:22:14 +0200, John Hay wrote: > > Hi, > > Does anybody know how to add a direct IPv6 host route that actually works? > What I mean is not through a gateway, but for one directly reachable. > > I know it normally isn't needed because it will just work, but I'm > trying to add FreeBSD IPv6 capability to net/olsrd. It looks like I have > most of the rest working, but this is one of the last things tripping > me up. > > I have played for most of the morning with various incantations of > "route add -inet6 -host ..." and just get various non working > routes. For my test I have the machines configured on the same IPv6 > subnet and without adding anything special I can ping them, but not > after adding a route. > > The reason they (the olsr guys) do it is so that a router can have > multiple WiFi interfaces all configured on the same subnet. Then > when they get comms with a machine, they can add a route to it > through that interface. > > At the moment I'm not even at the point of trying to get multiple > interfaces on the same subnet working, although I would like to > do that in the future. It would help if you have a high-site with > multiple antennas and radios. > > So anybody that know how to add a direct IPv6 host route on FreeBSD? > Can you show us the commands, network layout and the output of netstat -r and ndp -a? Best, George From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 02:48:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CB3A16A4E2; Mon, 4 Sep 2006 02:48:36 +0000 (UTC) (envelope-from cmzaogodmf@flying.to) Received: from flying.to (59-114-244-178.dynamic.hinet.net [59.114.244.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C6B143D49; Mon, 4 Sep 2006 02:48:33 +0000 (GMT) (envelope-from cmzaogodmf@flying.to) Date: Mon, 04 Sep 2006 10:48:30 +0800 From: "lenzcbt ccfgjse" X-Sender: cmzaogodmf@flying.to To: , , , , Message-Id: <0830624409.Deudpa-55365598-1894@flying.to> MIME-Version: 1.0 Content-Type: text/plain Cc: Subject: Investor Edge SBNS . PK 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, 04 Sep 2006 02:48:37 -0000 Health Care Sector has been booming since decades, this is the next big one. This is the best kept secret in entertainment SHALLBETTER INDUSTRIES INC (SBNS. PK) Company: SHALLBETTER INDUSTRIES INC Symbol: SBNS. PK Current Price: .98 Expected: Steady Climb for the TOP This quick rising stock is a good long term winner. This stock is going high due to superb business solutions and creative partnerships in thebusiness world. Below is the companys most recent headline. Shallbetter Industries, Inc. Announces New President HONOLULU--(BUSINESS WIRE)--Aug. 28, 2006--Shallbetter Industries Inc. is pleased to announce the appointment of a new President and Corporate Finance Group. Mr. Bruce Pridmore B.Sc. M.B.A has been retained as Shallbetter's new President and Chief Financial Officer. Mr. Pridmore is the founding Partner of London Asia Capital Canada and past Executive Director of Pacific Asia for the National Research Council of Canada. Mr. Pridmore brings extensive knowledge of Asian business practices as well as comprehensive understanding of capital markets both in North America and throughout the European Economic Community. Mr. Pridmore will assume the day to day operation of the company and the organization of a new drilling program once additional capital has been raised. It is anticipated the additional capital will be raised by way of debt, equity or a combination thereof. Dont miss the boat, this is a new issue, is thinly traded and could move up quickly. We anticipate that shares of SBNS will be much higher in the short-term. ACT ON IT! About SHALLBETTER INDUSTRIES INC Shallbetter Industries Inc is an international mining company with operations focused in Mongolia. Shallbetter has been granted exclusive government mining rights to many highly sought after mining locations. Having exclusive rights to land rich with gold in regions of the world that are fairly inexpensive in labor makes the profit outlook of many Shallbetter projects very alluring to investors. Shallbetter seeks to carry out highly profitable projects with the utmost in environmental and social responsibility in mind. All projects are given due diligence in research before conclusions are made as to accurate projections of profitability and feasibility. Any of the above statements with respect to the future predications or goals and events may be seen as only Foward speculation and nothing else. All information inside this email pertaining to any sort of financial advice need to be understood as just information and not any real advice. None of the information above can be constructed as any sort of financial advice. Confidentiality Statemen Once you see you'll know why you cannot afford to be left out of this one ----------------------- Put that in your pipe and smoke it. What's good for the goose is good for the gander. Survival of the fittest. Sweating blood. A tree does not move unless there is wind. Plain as water. Sitting on the fence. Tastes like chicken. Throw pearls before swine. Raking it in. Walking on thin ice. Plain as water. Up a tree. Stop and smell the roses. You have to separate the chaff from the wheat. Weed 'um and reap. We'll cross that bridge when we come to it. We hung them out to dry. Spring to mind. Your name is mud. Your all washed up. Your barking up the wrong tree. Shake like a leaf. Timber! Rise and shine. Welcome to my garden. Weed out. A stepping stone to. You never miss the water till the well runs dry. Weed out. Read the tea leaves. She's a nut. Pull it up by the roots. Your name is mud. Sow dry and set wet. When pigs fly. Sweet as honey. Plant kindness and gather love. Watch and wait. Too little too late. You can lead a horse to water but you can't make him drink. Walking on cloud nine. Waking up with the chickens. Through the grapevine. Spring to mind. Water under the bridge. Till the cows come home. Your barking up the wrong tree. A snail's pace. From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 07:23:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C2BB16A4DA; Mon, 4 Sep 2006 07:23:18 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4AB843D45; Mon, 4 Sep 2006 07:23:16 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E9EF833CAE; Mon, 4 Sep 2006 09:23:13 +0200 (SAST) Date: Mon, 4 Sep 2006 09:23:13 +0200 From: John Hay To: gnn@freebsd.org Message-ID: <20060904072313.GA83757@zibbi.meraka.csir.co.za> References: <20060903132214.GA40993@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host routes 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, 04 Sep 2006 07:23:18 -0000 On Mon, Sep 04, 2006 at 11:04:44AM +0900, gnn@freebsd.org wrote: > At Sun, 3 Sep 2006 15:22:14 +0200, > John Hay wrote: > > > > Hi, > > > > Does anybody know how to add a direct IPv6 host route that actually works? > > What I mean is not through a gateway, but for one directly reachable. > > > > I know it normally isn't needed because it will just work, but I'm > > trying to add FreeBSD IPv6 capability to net/olsrd. It looks like I have > > most of the rest working, but this is one of the last things tripping > > me up. ... > > > > So anybody that know how to add a direct IPv6 host route on FreeBSD? > > > > Can you show us the commands, network layout and the output of netstat > -r and ndp -a? Well maybe I should start with how it works on IPv4. You can see the code in work/olsrd-0.4.10/src/bsd/kernel_routes.c if you extract the net/olsrd port. In the case where the machine is directly connected, ie. not through a gateway, a network route with a /32 netmask is added with the cloning flag. So if you use the 10.1.9.0/24 network and have two hosts that can "see" each other, 10.1.9.1 and 10.1.9.2, on 10.1.9.1 you will see a route like this added: 10.1.9.2/32 link#2 UC 0 0 ath1 and as soon as there is traffic the arp will cause this: 10.1.9.2 00:02:6f:34:21:a2 UHLW 2 2286102 ath1 1176 => So I guess I want to imitate something like this in a way that the linux boxes that also run olsr can interoperate. My current test setup have 3 boxes on the 2001:4200:7000:15:: subnet, so ifconfig on rtrg looks like this: ################ ath0: flags=8843 mtu 1500 inet6 fe80::202:6fff:fe22:9547%ath0 prefixlen 64 scopeid 0x3 inet6 2001:4200:7000:15:202:6fff:fe22:9547 prefixlen 64 inet6 2001:4200:7000:15:: prefixlen 64 anycast ether 00:02:6f:22:95:47 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid koppiemesh channel 149 bssid 02:02:6f:41:19:27 authmode OPEN privacy OFF txpowmax 24 bmiss 7 burst bintval 100 ################ To lessen my typing I have these entries in /etc/hosts: 2001:4200:7000:15:202:6fff:fe22:9547 rtrg 2001:4200:7000:15:202:6fff:fe41:1927 rtr2 The machine I am working on is the first one, rtrg. If I don't do anything, I can ping6 rtr2, but I would like to add a route and still have it work. I have tried many things on rtrg but none seem to give me something that works. Some of the ones I have tried: route add -inet6 -host rtr2 -interface ath0 route add -inet6 -host rtr2 -interface ath0 -cloning -nostatic --llinfo route add -inet6 -net rtr2 -prefixlen 128 -interface ath0 -cloning -nostatic --llinfo route add -inet6 -host rtr2 fe80::202:6fff:fe22:9547%ath0 -ifp ath0 route add -inet6 -host rtr2 -interface fe80::202:6fff:fe22:9547%ath0 -ifp ath0 route add -inet6 -host rtr2 rtrg -cloning -nostatic Thanks. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 07:35:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 501B416A4E1 for ; Mon, 4 Sep 2006 07:35:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id A565043D49 for ; Mon, 4 Sep 2006 07:35:05 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 16277 invoked by uid 399); 4 Sep 2006 07:35:02 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 4 Sep 2006 07:35:02 -0000 Message-ID: <44FBD71D.5040900@FreeBSD.org> Date: Mon, 04 Sep 2006 00:34:53 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brooks Davis References: <200609030220.k832KQji011085@freefall.freebsd.org> <44FA6616.8080806@FreeBSD.org> <20060903171610.GB45627@lor.one-eyed-alien.net> In-Reply-To: <20060903171610.GB45627@lor.one-eyed-alien.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, George Mitchell Subject: Re: kern/102035: [plip] plip networking disables parallel port printing 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, 04 Sep 2006 07:35:06 -0000 Brooks Davis wrote: > In many ways I think the best thing to do is remove plip from GENERIC > and be done with it. That works for me, and would match what I believe is the reasonable expectation of our users. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 08:00:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C05716A4E0 for ; Mon, 4 Sep 2006 08:00:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2977343D5A for ; Mon, 4 Sep 2006 08:00:15 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2789105pye for ; Mon, 04 Sep 2006 01:00:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=SQ/pCZ8SdijetmLna9xPYIDNRWYUuK1VjetfGvLeKVXz8h/AkFtmKKRMaB2o8OASmKkQMG5nuNbUtk0qhNndKuVu5BIPV/q9a9GYcShgvf2oZzsj0AdIVMEiqVMGYqpwIkmQq3QoxhhrTn8YEJtRayu8niihHQo0ruGQPLUYmac= Received: by 10.35.128.1 with SMTP id f1mr9588909pyn; Mon, 04 Sep 2006 01:00:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 38sm2361681nza.2006.09.04.01.00.13; Mon, 04 Sep 2006 01:00:14 -0700 (PDT) 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 k847wOHD002106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2006 16:58:24 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k847wNDx002105; Mon, 4 Sep 2006 16:58:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 4 Sep 2006 16:58:23 +0900 From: Pyun YongHyeon To: Jack Vogel Message-ID: <20060904075823.GA1210@cdnetworks.co.kr> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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: Mon, 04 Sep 2006 08:00:16 -0000 On Fri, Sep 01, 2006 at 03:51:21PM -0700, Jack Vogel wrote: > This is a patch for the stack and the em driver to enable TSO > on CURRENT. Previously I had problems getting it to work, but > this is functional. > > I should note that CURRENT is being a pain right now, when > I comment out em in the config the kernel panics coming up, > so I had to substitute this code into the tree. Rather bizarre :) > > I have this functionality running on a 6.1 based system, and > our test group is already testing against that driver, so far > things are looking good. > > I have designed it so the driver can continue to be built > without support. There is also a sysctl in the stack code > so you can set net.inet.tcp.tso_enable on or off and > compare. > > I know there may be some refinements to add in, but I > would like to get this into CURRENT as a start. > > Comments? > It seems that 8254x also supports UDP segmentation offloading feature. Have you tried to implement it? According to the data sheet checksums are not accurate above 12K frame size but I couldn't find frame size restrictions in TSO path. What is maximum frame size supported by TSO? It seems that TSO assumes IP/TCP/UDP checksum offloading is always enabled by hardware. What if users disable IP/TCP/UDP checksum offloading with ifconfig(8)? What happen if users disable hardware VLAN tag insertion with ifconfig(8)? It woud be even better if users can disable/enable TSO capability for each network devices with ifconfig(8) instead of relying on global sysctl MIB(net.inet.tcp.tso_enable). Btw, do you have benchmark numbers? > Jack -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 10:08:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C47DF16A4E7 for ; Mon, 4 Sep 2006 10:08:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C5643D53 for ; Mon, 4 Sep 2006 10:08:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 18418 invoked from network); 4 Sep 2006 09:53:25 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Sep 2006 09:53:25 -0000 Message-ID: <44FBFAFF.3030702@freebsd.org> Date: Mon, 04 Sep 2006 12:07:59 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Robert Watson References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org> In-Reply-To: <20060902065044.V84468@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 04 Sep 2006 10:08:02 -0000 Robert Watson wrote: > On Fri, 1 Sep 2006, Jack Vogel wrote: > >> This is a patch for the stack and the em driver to enable TSO on >> CURRENT. Previously I had problems getting it to work, but this is >> functional. >> >> I should note that CURRENT is being a pain right now, when I comment >> out em in the config the kernel panics coming up, so I had to >> substitute this code into the tree. Rather bizarre :) >> >> I have this functionality running on a 6.1 based system, and our test >> group is already testing against that driver, so far things are >> looking good. >> >> I have designed it so the driver can continue to be built without >> support. There is also a sysctl in the stack code so you can set >> net.inet.tcp.tso_enable on or off and compare. >> >> I know there may be some refinements to add in, but I would like to >> get this into CURRENT as a start. > > > Per my earlier comments, I would like to see the issue of doing an > on-demand segmentation of TCP at the IP layer in the event that the > early route decision becomes stale (i.e., ipfw fwd, ipsec, etc), as > occurs in the NetBSD code. Likewise, I think Andre's comment about > making the routing decision up front for the TCP connection as part of > the existing search for PMTU information makes sense. I'm more > interested in seeing the former addressed than the latter before the > commit, though, which can quite easily follow. In the patch I posted yesterday into this thread the TSO decision is done at connection setup time in tcp_mss() where all other initial TCP connection parameters are initilized as well. If the same interface we took the MTU values from, is found to support TSO it gets enabled for this connection too. Should the egress interface change during the lifetime of the connection and the new one doesn't support TSO we get an EMSGSIZE error from ip_output(), disable TSO for this connection and have tcp_output() resend the data again while doing the segmentation itself as usual. Should the connection change back to the TSO capable interface later on we don't re-enable TSO for the connection though. OTOH having a bulk transfer TCP session (where TSO actually helps) migrate between interface is a *very* rare occurence and not worth special casing for it. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 10:41:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 651BD16A4DF for ; Mon, 4 Sep 2006 10:41:32 +0000 (UTC) (envelope-from DBila@care.org.mz) Received: from gate.care.org.mz (cust251-2.netcabo.co.mz [196.46.2.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E57A43D6E for ; Mon, 4 Sep 2006 10:41:22 +0000 (GMT) (envelope-from DBila@care.org.mz) Received: from gate.care.org.mz (localhost.care.org.mz [127.0.0.1]) by gate.care.org.mz (Postfix) with ESMTP id 9606E61C6D for ; Mon, 4 Sep 2006 13:13:31 +0200 (CAT) Received: from care.org.mz (unknown [192.168.40.60]) by gate.care.org.mz (Postfix) with ESMTP id 71A8D61C2E for ; Mon, 4 Sep 2006 13:13:30 +0200 (CAT) Received: from WorldClient by care.org.mz (MDaemon.PRO.v8.0.3.R) with ESMTP id md50000259118.msg for ; Mon, 04 Sep 2006 12:40:58 +0200 Received: from [192.168.40.130] via WorldClient with HTTP; Mon, 04 Sep 2006 12:40:53 +0200 Date: Mon, 04 Sep 2006 12:40:53 +0200 From: "David Bila" To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: X-Mailer: WorldClient 8.0.3 X-Authenticated-Sender: DBila@care.org.mz X-Spam-Processed: mail.care.org.mz, Mon, 04 Sep 2006 12:40:58 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 127.0.0.1 X-Return-Path: DBila@care.org.mz X-MDaemon-Deliver-To: freebsd-net@freebsd.org X-MDAV-Processed: mail.care.org.mz, Mon, 04 Sep 2006 12:40:58 +0200 X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Two ISP connections with Natd 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, 04 Sep 2006 10:41:32 -0000 Dear All, I am running freebsd as getway for my office. I Just acquired second Internet last week. I wonder if there is a way trhough route add -net and ipfw I can manipulate my traffic in a such way that some traffic to a selected network can go through one ISP while the rest goes through the default gateway. I am using natd and my FreeBSD box has got 3 NICs, one for internal network and other two for each ISP. Please Help, David From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 11:08:37 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF9D16A4DD for ; Mon, 4 Sep 2006 11:08:37 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DC6B43D45 for ; Mon, 4 Sep 2006 11:08:37 +0000 (GMT) (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 k84B8aqB094454 for ; Mon, 4 Sep 2006 11:08:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k84B8YZh094451 for freebsd-net@FreeBSD.org; Mon, 4 Sep 2006 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Sep 2006 11:08:34 GMT Message-Id: <200609041108.k84B8YZh094451@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, 04 Sep 2006 11:08:37 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor o kern/100172 net [arp] Transfer of large file fails with host is down m o kern/102653 net TCP stack sends infinite retries for connection in LAS 4 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 kern/31686 net Problem with the timestamp option when flag equals zer 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 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/102607 net [if_bridge] don't generate random L2 address 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 13:08:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2854616A4E1; Mon, 4 Sep 2006 13:08:29 +0000 (UTC) (envelope-from marcelo@registro.br) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C06BE43D45; Mon, 4 Sep 2006 13:08:28 +0000 (GMT) (envelope-from marcelo@registro.br) Received: by clone.registro.br (Postfix, from userid 1014) id 66D0E2A4E5; Mon, 4 Sep 2006 10:08:27 -0300 (BRT) Date: Mon, 4 Sep 2006 10:08:27 -0300 From: Marcelo Gardini do Amaral To: Jack Vogel Message-ID: <20060904130827.GE12975@registro.br> References: <2a41acea0608301145j7bbed961j33ce903a27d8963d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0608301145j7bbed961j33ce903a27d8963d@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Danny Braniss , freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tcp/udp performance 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, 04 Sep 2006 13:08:29 -0000 > > > >Any help? > > > > danny > > Have discussed this some internally, the best idea I've heard is that > UDP is not giving us the interrupt rate that TCP would, so we end up > not cleaning up as often, and thus descriptors might not be as quickly > available.. Its just speculation at this point. > > Try this: the default is only to have 256 descriptors, try going for the MAX > which is 4K. > I've made some udp performance tests with FreeBSD 6-STABLE. The results were poor. I had the best results with 4.11. Does anybody made some test like that? -- Att., Marcelo Gardini NIC .br From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:10:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 119B216A4E0 for ; Mon, 4 Sep 2006 17:10:53 +0000 (UTC) (envelope-from cgi-mailer-bounces-70781051@kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 235A743D45 for ; Mon, 4 Sep 2006 17:10:52 +0000 (GMT) (envelope-from cgi-mailer-bounces-70781051@kundenserver.de) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1GKHyF-0006t1-00 for freebsd-net@freebsd.org; Mon, 04 Sep 2006 19:10:51 +0200 Received: from [212.227.127.18] (helo=infong175 ident=8) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1GKHyF-0001QK-00 for freebsd-net@freebsd.org; Mon, 04 Sep 2006 19:10:51 +0200 Received: from [82.128.5.56](IP may be forged by CGI script) by infong175.kundenserver.de with HTTP; Mon, 4 Sep 2006 19:10:51 +0200 Date: Mon, 4 Sep 2006 19:10:51 +0200 Precedence: bulk To: freebsd-net@freebsd.org From: National Online Talent Management MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: X-Provags-ID: kundenserver.de abuse@kundenserver.de sender-info:70781051@infong175 Subject: Need new Artist/Models(workers) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: admins@notm.com.au List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2006 17:10:53 -0000 No experience required Trainning provided No joining fee National Online Talent Management Australia’s Fastest Growing Modeling & Casting Agency We are currently submitting both workers and people who are willing to be our agents in Australia(representatives), models and actors for TV commercial work and other TV/Film work. Work is casual and pays will vary from $400.32 per hour to $25,000 per day for models/artist while $15,000AUD for Workers and Agents who works for NOTM (National Online Talent Management). We are looking for male and female models for national and international modeling contracts pays vary from $5,000 to $25,000 per week all expenses paid. (No nudity) NOTM is seeking people of all ages, nationalities and looks to use as extras, models & promotional staff. Successful applicants will be promoted to our clients for briefs that are casting\work. In some cases no prior experience is necessary and some of our new recruits have earned up to $3,000 a week working as an extra. Applications for these production briefs will close soon. Our Workers/Agent(representatives) work will be receive payment on behalf of the NOTM from any company who is willing to sponsor any of our Films/Movies and also they can features in the film shoot if they are willing only. Every worker/Agent of the NOTM will have a discount of 10% on payment made from the sponsor companies If you’ve been told you should be on Television by family or friends or you like to work only as a worker of the NOTM or as an agent for the NOTM, maybe you've thought you could but didn't know where to start? Being cast as an extra is a good place to start. If your old, young, inexperienced or overly qualified - we have room for a number of different ages, sexes, and looks - chances are we need you so, apply online with correct contact details and a small photo if possible by filling the details requested below: > - Full Name: > - Full Address: > - Phone Number: > - Mobile Number: > - Please summit your details to this Admin Detp. through this email only: franklin116@katamail.com Kindly get back with all the informations required by the NOTM if you are willing to work with the NOTM as a representative who will be in direct contact with all the NOTM sponsor companies in Australia. James Gabriels (Mr.) Talent Co-ordinators National Online Talent Management (NOTM) From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:21:32 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C58C16A4E2 for ; Mon, 4 Sep 2006 17:21:32 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55A5543DB8 for ; Mon, 4 Sep 2006 17:21:29 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k84HLMX9020120 for ; Tue, 5 Sep 2006 02:21:25 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Tue, 5 Sep 2006 02:21:20 +0900 From: Norikatsu Shigemura To: freebsd-net@FreeBSD.org Message-Id: <20060905022120.19c6d62d.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Tue, 05 Sep 2006 02:21:27 +0900 (JST) Cc: Subject: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:21:32 -0000 I'm finding IPSec NAT-Traversal support patch for 6-stable and 7-current. But I could only find it for 6.0-R and 4-stable:-(. Where is IPSec NAT-T support patch? And why does IPSec NAT-T support be comitted into src tree? NetBSD already supports IPSec NAT-Traversal. From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:24:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A59A16A4DE for ; Mon, 4 Sep 2006 17:24:47 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48DBC43D66 for ; Mon, 4 Sep 2006 17:24:46 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1836010uge for ; Mon, 04 Sep 2006 10:24:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rFEqnSLXtgQ/chTx8A3qrlNYgJLi7tBqgJOLSeVNdh6hAoHjCveueTlbPtQAST02QRYX/Y418cVdw9Gc7xY6Inqx+2F1+35rFfzk95vMKJz18EGusHEvZRcgz5A+hdiM9OW3+6L5N6QFXR8yTc8zSr9uBS/AsYAyt2KrqdLFZw8= Received: by 10.66.249.11 with SMTP id w11mr3094830ugh; Mon, 04 Sep 2006 10:24:45 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Mon, 4 Sep 2006 10:24:45 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2006 13:24:45 -0400 From: "Scott Ullrich" To: "Norikatsu Shigemura" In-Reply-To: <20060905022120.19c6d62d.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060905022120.19c6d62d.nork@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:24:47 -0000 On 9/4/06, Norikatsu Shigemura wrote: > I'm finding IPSec NAT-Traversal support patch for 6-stable and > 7-current. But I could only find it for 6.0-R and 4-stable:-(. > Where is IPSec NAT-T support patch? > And why does IPSec NAT-T support be comitted into src tree? > NetBSD already supports IPSec NAT-Traversal. When building the security/ipsec-tools package this gem is displayed: ===> ------------------------------------------------------------------------- ===> ATTENTION: You need a kernel patch to enable NAT-Traversal functionality! ===> You can download the patch here: ===> http://ipsec-tools.sf.net/freebsd6-natt.diff ===> You might possibly have to do some steps manually if it fails to apply. ===> ------------------------------------------------------------------------- However, it does not compile and work on RELENG_6_1. I too would like to see NAT-T support committed as its a commonly requested feature for pfSense. This would also benefit m0n0wall if it was committed. Scott From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:35:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E0816A4E1 for ; Mon, 4 Sep 2006 17:35:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C0243D4C for ; Mon, 4 Sep 2006 17:35:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 8F1351FFDD3 for ; Mon, 4 Sep 2006 19:35:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 3581E1FFD0B; Mon, 4 Sep 2006 19:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5D3174448D6 for ; Mon, 4 Sep 2006 17:33:19 +0000 (UTC) Date: Mon, 4 Sep 2006 17:33:19 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: Message-ID: <20060904172700.W44392@maildrop.int.zabbadoz.net> References: <20060905022120.19c6d62d.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:35:21 -0000 On Mon, 4 Sep 2006, Scott Ullrich wrote: > On 9/4/06, Norikatsu Shigemura wrote: >> I'm finding IPSec NAT-Traversal support patch for 6-stable and >> 7-current. But I could only find it for 6.0-R and 4-stable:-(. >> Where is IPSec NAT-T support patch? >> And why does IPSec NAT-T support be comitted into src tree? >> NetBSD already supports IPSec NAT-Traversal. > > When building the security/ipsec-tools package this gem is displayed: > > ------------------------------------------------------------------------- .. > ===> You can download the patch here: > ===> http://ipsec-tools.sf.net/freebsd6-natt.diff .. > ------------------------------------------------------------------------- Was also posted multiple times by the author to this and other lists. > However, it does not compile and work on RELENG_6_1. I too would like It does apply and compile to RELENG_6_1 and RELENG_6 of some days ago (unless you do not enable the option after applying the patch). At least it did for me. I am partly fine with the "does not work" (in all cases). I am currently debugging this. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:45:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5BE616A4DE for ; Mon, 4 Sep 2006 17:45:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDF2243D45 for ; Mon, 4 Sep 2006 17:45:38 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1842232uge for ; Mon, 04 Sep 2006 10:45:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IRxl6Af5Twheop9e1J1QsV40HM8qeXia67LoGZrHwYOmVfQh3M2rs/2j4/qaQM8l/iUnd+JXdDJWXT6yAGisRrYSpQT7rk+YSUG/brNNGC6HtSEHa/+2rtXX4vHAZ9FTvrmEv7WjRKNIdLhjnPxaWh4kbUjqI3dwc5N/TdCwq0s= Received: by 10.67.10.12 with SMTP id n12mr3092086ugi; Mon, 04 Sep 2006 10:45:37 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Mon, 4 Sep 2006 10:45:37 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2006 13:45:37 -0400 From: "Scott Ullrich" To: "Bjoern A. Zeeb" In-Reply-To: <20060904172700.W44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:45:39 -0000 On 9/4/06, Bjoern A. Zeeb wrote: > It does apply and compile to RELENG_6_1 and RELENG_6 of some days ago > (unless you do not enable the option after applying the patch). > At least it did for me. > I am partly fine with the "does not work" (in all cases). I am > currently debugging this. I should know better to make statements like this and not backup my claim with hard data :) The problem is that after applying the patch and building a kernel, the kernel build errors out with this: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/netinet/udp_usrreq.c In file included from /usr/src/sys/netinet6/ipsec.h:46, from /usr/src/sys/netinet/udp_usrreq.c:88: /usr/src/sys/netkey/keydb.h:54: error: redefinition of `struct secasindex' /usr/src/sys/netkey/keydb.h:64: error: redefinition of `struct secashead' /usr/src/sys/netkey/keydb.h:74: error: redefinition of `struct _satree' /usr/src/sys/netkey/keydb.h:86: error: redefinition of `struct secasvar' /usr/src/sys/netkey/keydb.h:127: error: redefinition of `struct secreplay' /usr/src/sys/netkey/keydb.h:137: error: redefinition of `struct secreg' /usr/src/sys/netkey/keydb.h:145: error: redefinition of `struct secacq' /usr/src/sys/netkey/keydb.h:169: warning: redundant redeclaration of 'keydb_newsecpolicy' /usr/src/sys/netipsec/keydb.h:172: warning: previous declaration of 'keydb_newsecpolicy' was here /usr/src/sys/netkey/keydb.h:171: warning: redundant redeclaration of 'keydb_delsecpolicy' /usr/src/sys/netipsec/keydb.h:173: warning: previous declaration of 'keydb_delsecpolicy' was here /usr/src/sys/netkey/keydb.h:175: warning: redundant redeclaration of 'keydb_newsecashead' /usr/src/sys/netipsec/keydb.h:175: warning: previous declaration of 'keydb_newsecashead' was here /usr/src/sys/netkey/keydb.h:176: warning: redundant redeclaration of 'keydb_delsecashead' /usr/src/sys/netipsec/keydb.h:176: warning: previous declaration of 'keydb_delsecashead' was here /usr/src/sys/netkey/keydb.h:178: warning: redundant redeclaration of 'keydb_newsecasvar' /usr/src/sys/netipsec/keydb.h:178: warning: previous declaration of 'keydb_newsecasvar' was here /usr/src/sys/netkey/keydb.h:181: warning: redundant redeclaration of 'keydb_newsecreplay' /usr/src/sys/netipsec/keydb.h:182: warning: previous declaration of 'keydb_newsecreplay' was here /usr/src/sys/netkey/keydb.h:182: warning: redundant redeclaration of 'keydb_delsecreplay' /usr/src/sys/netipsec/keydb.h:183: warning: previous declaration of 'keydb_delsecreplay' was here /usr/src/sys/netkey/keydb.h:184: warning: redundant redeclaration of 'keydb_newsecreg' /usr/src/sys/netipsec/keydb.h:185: warning: previous declaration of 'keydb_newsecreg' was here /usr/src/sys/netkey/keydb.h:185: warning: redundant redeclaration of 'keydb_delsecreg' /usr/src/sys/netipsec/keydb.h:186: warning: previous declaration of 'keydb_delsecreg' was here In file included from /usr/src/sys/netinet/udp_usrreq.c:88: /usr/src/sys/netinet6/ipsec.h:56: error: redefinition of `struct secpolicyindex' /usr/src/sys/netinet6/ipsec.h:71: error: redefinition of `struct secpolicy' /usr/src/sys/netinet6/ipsec.h:111: error: redefinition of `struct ipsecrequest' /usr/src/sys/netinet6/ipsec.h:126: error: redefinition of `struct inpcbpolicy' /usr/src/sys/netinet6/ipsec.h:141: error: redefinition of `struct secspacq' /usr/src/sys/netinet6/ipsec.h:212: error: redefinition of `struct ipsecstat' /usr/src/sys/netinet6/ipsec.h:302: error: redefinition of `struct ipsec_output_state' /usr/src/sys/netinet6/ipsec.h:309: error: redefinition of `struct ipsec_history' /usr/src/sys/netinet6/ipsec.h:314: warning: redundant redeclaration of 'ipsec_debug' /usr/src/sys/netipsec/ipsec.h:332: warning: previous declaration of 'ipsec_debug' was here /usr/src/sys/netinet6/ipsec.h:318: error: conflicting types for 'ip4_def_policy' /usr/src/sys/netipsec/ipsec.h:335: error: previous declaration of 'ip4_def_policy' was here /usr/src/sys/netinet6/ipsec.h:318: error: conflicting types for 'ip4_def_policy' /usr/src/sys/netipsec/ipsec.h:335: error: previous declaration of 'ip4_def_policy' was here /usr/src/sys/netinet6/ipsec.h:319: warning: redundant redeclaration of 'ip4_esp_trans_deflev' /usr/src/sys/netipsec/ipsec.h:336: warning: previous declaration of 'ip4_esp_trans_deflev' was here /usr/src/sys/netinet6/ipsec.h:320: warning: redundant redeclaration of 'ip4_esp_net_deflev' /usr/src/sys/netipsec/ipsec.h:337: warning: previous declaration of 'ip4_esp_net_deflev' was here /usr/src/sys/netinet6/ipsec.h:321: warning: redundant redeclaration of 'ip4_ah_trans_deflev' /usr/src/sys/netipsec/ipsec.h:338: warning: previous declaration of 'ip4_ah_trans_deflev' was here /usr/src/sys/netinet6/ipsec.h:322: warning: redundant redeclaration of 'ip4_ah_net_deflev' /usr/src/sys/netipsec/ipsec.h:339: warning: previous declaration of 'ip4_ah_net_deflev' was here /usr/src/sys/netinet6/ipsec.h:323: warning: redundant redeclaration of 'ip4_ah_cleartos' /usr/src/sys/netipsec/ipsec.h:340: warning: previous declaration of 'ip4_ah_cleartos' was here /usr/src/sys/netinet6/ipsec.h:324: warning: redundant redeclaration of 'ip4_ah_offsetmask' /usr/src/sys/netipsec/ipsec.h:341: warning: previous declaration of 'ip4_ah_offsetmask' was here /usr/src/sys/netinet6/ipsec.h:325: warning: redundant redeclaration of 'ip4_ipsec_dfbit' /usr/src/sys/netipsec/ipsec.h:342: warning: previous declaration of 'ip4_ipsec_dfbit' was here /usr/src/sys/netinet6/ipsec.h:326: warning: redundant redeclaration of 'ip4_ipsec_ecn' /usr/src/sys/netipsec/ipsec.h:343: warning: previous declaration of 'ip4_ipsec_ecn' was here /usr/src/sys/netinet6/ipsec.h:327: warning: redundant redeclaration of 'ip4_esp_randpad' /usr/src/sys/netipsec/ipsec.h:344: warning: previous declaration of 'ip4_esp_randpad' was here In file included from /usr/src/sys/netinet/udp_usrreq.c:88: /usr/src/sys/netinet6/ipsec.h:330:1: "ipseclog" redefined In file included from /usr/src/sys/netinet/udp_usrreq.c:79: /usr/src/sys/netipsec/ipsec.h:347:1: this is the location of the previous definition /usr/src/sys/netinet6/ipsec.h:345: error: conflicting types for 'ipsec_get_reqlevel' /usr/src/sys/netipsec/ipsec.h:372: error: previous declaration of 'ipsec_get_reqlevel' was here /usr/src/sys/netinet6/ipsec.h:345: error: conflicting types for 'ipsec_get_reqlevel' /usr/src/sys/netipsec/ipsec.h:372: error: previous declaration of 'ipsec_get_reqlevel' was here /usr/src/sys/netinet6/ipsec.h:347: warning: redundant redeclaration of 'ipsec4_set_policy' /usr/src/sys/netipsec/ipsec.h:375: warning: previous declaration of 'ipsec4_set_policy' was here /usr/src/sys/netinet6/ipsec.h:348: warning: redundant redeclaration of 'ipsec4_get_policy' /usr/src/sys/netipsec/ipsec.h:377: warning: previous declaration of 'ipsec4_get_policy' was here /usr/src/sys/netinet6/ipsec.h:350: warning: redundant redeclaration of 'ipsec4_delete_pcbpolicy' /usr/src/sys/netipsec/ipsec.h:379: warning: previous declaration of 'ipsec4_delete_pcbpolicy' was here /usr/src/sys/netinet6/ipsec.h:351: warning: redundant redeclaration of 'ipsec4_in_reject' /usr/src/sys/netipsec/ipsec.h:380: warning: previous declaration of 'ipsec4_in_reject' was here /usr/src/sys/netinet6/ipsec.h:356: warning: redundant redeclaration of 'ipsec_chkreplay' /usr/src/sys/netipsec/ipsec.h:384: warning: previous declaration of 'ipsec_chkreplay' was here /usr/src/sys/netinet6/ipsec.h:357: warning: redundant redeclaration of 'ipsec_updatereplay' /usr/src/sys/netipsec/ipsec.h:385: warning: previous declaration of 'ipsec_updatereplay' was here /usr/src/sys/netinet6/ipsec.h:359: warning: redundant redeclaration of 'ipsec4_hdrsiz' /usr/src/sys/netipsec/ipsec.h:387: warning: previous declaration of 'ipsec4_hdrsiz' was here /usr/src/sys/netinet6/ipsec.h:360: warning: redundant redeclaration of 'ipsec_hdrsiz_tcp' /usr/src/sys/netipsec/ipsec.h:388: warning: previous declaration of 'ipsec_hdrsiz_tcp' was here /usr/src/sys/netinet6/ipsec.h:364: warning: redundant redeclaration of 'ipsec_logsastr' /usr/src/sys/netipsec/ipsec.h:392: warning: previous declaration of 'ipsec_logsastr' was here /usr/src/sys/netinet6/ipsec.h:366: warning: redundant redeclaration of 'ipsec_dumpmbuf' /usr/src/sys/netipsec/ipsec.h:394: warning: previous declaration of 'ipsec_dumpmbuf' was here /usr/src/sys/netinet6/ipsec.h:372: warning: redundant redeclaration of 'ipsec_copypkt' /usr/src/sys/netipsec/ipsec.h:409: warning: previous declaration of 'ipsec_copypkt' was here In file included from /usr/src/sys/netinet/udp_usrreq.c:89: /usr/src/sys/netinet6/esp.h:101: warning: redundant redeclaration of 'esp4_input' /usr/src/sys/netipsec/ipsec.h:399: warning: previous declaration of 'esp4_input' was here /usr/src/sys/netinet/udp_usrreq.c: In function `udp_append': /usr/src/sys/netinet/udp_usrreq.c:492: warning: implicit declaration of function `udp4_espinudp' /usr/src/sys/netinet/udp_usrreq.c:492: warning: nested extern declaration of `udp4_espinudp' *** Error code 1 Stop in /usr/obj/usr/src/sys/pfSense.6. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. builder# Scott From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:55:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAC8816A4DE for ; Mon, 4 Sep 2006 17:55:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 287F043D46 for ; Mon, 4 Sep 2006 17:55:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 08A841FFDC1 for ; Mon, 4 Sep 2006 19:55:10 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 89CEF1FFBB6; Mon, 4 Sep 2006 19:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7B7924448D6 for ; Mon, 4 Sep 2006 17:53:36 +0000 (UTC) Date: Mon, 4 Sep 2006 17:53:36 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: Message-ID: <20060904175127.F44392@maildrop.int.zabbadoz.net> References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:55:11 -0000 On Mon, 4 Sep 2006, Scott Ullrich wrote: > On 9/4/06, Bjoern A. Zeeb wrote: >> It does apply and compile to RELENG_6_1 and RELENG_6 of some days ago >> (unless you do not enable the option after applying the patch). >> At least it did for me. >> I am partly fine with the "does not work" (in all cases). I am >> currently debugging this. > > I should know better to make statements like this and not backup my > claim with hard data :) > > The problem is that after applying the patch and building a kernel, > the kernel build errors out with this: Are you sure this is a clean RELENG_6_1 with the correct patch? MD5 (freebsd6-natt.diff) = 5e7bb5a3203c8959928bf910d5498140 I compiled this on i386 and am64 just a few days ago and everything was fine. Perhaps contact me off-list and we'll post a summary once we found the problem? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 17:59:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E908116A4DE for ; Mon, 4 Sep 2006 17:59:49 +0000 (UTC) (envelope-from sullrich@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 4DFB243D45 for ; Mon, 4 Sep 2006 17:59:49 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1847136uge for ; Mon, 04 Sep 2006 10:59:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Bw/HvAD7pxGKXvvk0i/on1vkGa/fnsN0PpgeDO5mES00JAKB4+ftyFWVYax5D/U8mfUyADSZ8+AyU0nNdX8S85VvSmldGSvPAoHHkE4mZ7t7S0kFiR886+6jykGubhQxeC0UFzHjFXx3TPkUEFvqq+Oh0mE2k1IXIY6AXH167Fk= Received: by 10.67.119.5 with SMTP id w5mr3109079ugm; Mon, 04 Sep 2006 10:59:48 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Mon, 4 Sep 2006 10:59:47 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2006 13:59:47 -0400 From: "Scott Ullrich" To: "Bjoern A. Zeeb" In-Reply-To: <20060904175127.F44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 17:59:50 -0000 On 9/4/06, Bjoern A. Zeeb wrote: > Are you sure this is a clean RELENG_6_1 with the correct patch? > MD5 (freebsd6-natt.diff) = 5e7bb5a3203c8959928bf910d5498140 Yes it was a clean RELENG_6_1. > I compiled this on i386 and am64 just a few days ago and everything > was fine. > > Perhaps contact me off-list and we'll post a summary once we found the > problem? Maybe it is because I am including FAST_IPSEC? I have attempted to build and use a NAT-T kernel on atleast 7 attempts now. Last of which was a couple months ago. The Kernel configuration file that I am trying to build is http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense.6?rev=1.32 with the added options IPSEC_NAT_T option. Maybe I am overlooking something simple? Scott From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 18:10:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97DF916A512 for ; Mon, 4 Sep 2006 18:10:46 +0000 (UTC) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7768643E56 for ; Mon, 4 Sep 2006 18:08:45 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 2845A4FBBC; Mon, 4 Sep 2006 20:08:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 4E241CD6A; Mon, 4 Sep 2006 20:08:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nII182WJgiKr; Mon, 4 Sep 2006 20:08:19 +0200 (CEST) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id A0838CD35; Mon, 4 Sep 2006 20:08:19 +0200 (CEST) To: "Scott Ullrich" From: Eric Masson In-Reply-To: (Scott Ullrich's message of "Mon, 4 Sep 2006 13:59:47 -0400") References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> X-Operating-System: FreeBSD 5.5-RELEASE-p3 i386 Date: Mon, 04 Sep 2006 20:08:19 +0200 Message-ID: <86y7szijxo.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b27 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 18:10:46 -0000 "Scott Ullrich" writes: Hi, > Maybe it is because I am including FAST_IPSEC? I have attempted to > build and use a NAT-T kernel on atleast 7 attempts now. Last of which > was a couple months ago. Yvan's patch addresses NATT only with KAME stack. He's been talking about work in progress regarding NATT support with FAST_IPSEC on ipsec-tools-devel. Regards Éric Masson -- J'avais une préférence de Netscape sur Explorer, mais même NN 4.0 se révèle instable (MTBM* environ 15 minutes). [...] * MTBF = Mean Time Between Macsbug -+- JYB in Guide du Macounet Pervers : MTBM ta mère -+- From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 18:10:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F7416A548 for ; Mon, 4 Sep 2006 18:10:56 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B988E43DDB for ; Mon, 4 Sep 2006 18:10:16 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 1D63A1FFDD4 for ; Mon, 4 Sep 2006 20:10:10 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id B2CD41FFDD8; Mon, 4 Sep 2006 20:10:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D360D4448D6 for ; Mon, 4 Sep 2006 18:06:56 +0000 (UTC) Date: Mon, 4 Sep 2006 18:06:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: Message-ID: <20060904180515.V44392@maildrop.int.zabbadoz.net> References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 18:10:56 -0000 On Mon, 4 Sep 2006, Scott Ullrich wrote: > Maybe it is because I am including FAST_IPSEC? I have attempted to > build and use a NAT-T kernel on atleast 7 attempts now. Last of which > was a couple months ago. the patch only support kame ipsec. I guess that's the problem. Could you try it building with kame ipsec instead of fast_ipsec and let us know if that worked? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 18:11:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F316F16A4E0 for ; Mon, 4 Sep 2006 18:11:09 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE6643D45 for ; Mon, 4 Sep 2006 18:11:09 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1850629uge for ; Mon, 04 Sep 2006 11:11:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fIb19wqbpDbaEYQUJxf/5+jjLdDX9A6I1UMK5ELfTOaYysiiNiCtmT24EXc2f3nvdS5IIJLf16WYRC3pWFw4NsMRurl9opjZO/zf5+lUGjiQ+d0EUjxCTq28MaiSVzh3auX0uDlKwuAqVC4F9TW7jM6vmSl+e3x5RIv1delUtUE= Received: by 10.66.221.19 with SMTP id t19mr3120176ugg; Mon, 04 Sep 2006 11:11:08 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Mon, 4 Sep 2006 11:11:08 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2006 14:11:08 -0400 From: "Scott Ullrich" To: "Eric Masson" In-Reply-To: <86y7szijxo.fsf@srvbsdnanssv.interne.kisoft-services.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> <86y7szijxo.fsf@srvbsdnanssv.interne.kisoft-services.com> Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 18:11:10 -0000 On 9/4/06, Eric Masson wrote: > Yvan's patch addresses NATT only with KAME stack. > > He's been talking about work in progress regarding NATT support with > FAST_IPSEC on ipsec-tools-devel. > Thanks for the clarification. I look forward to when this works with FAST_IPSEC as well :) Scott From owner-freebsd-net@FreeBSD.ORG Mon Sep 4 18:16:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB86216A4E5 for ; Mon, 4 Sep 2006 18:16:10 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 119D243D55 for ; Mon, 4 Sep 2006 18:16:09 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1852157uge for ; Mon, 04 Sep 2006 11:16:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U0memvQWmaX5gRjuMtIHjnKiCprSw+5vXiTs4oms0/PI/d1zxRdtsrtaKhCVrG/GlAuGwfRwmqIpYmTdwW8ioZefGVG0Mm+2EoTRiuKocYkulK1+ezsUznyF48aOX1MSFZ3VrVddBw6hC+qgSp1CGvS2Fe29rAN2Ogy15tv0hI0= Received: by 10.66.224.3 with SMTP id w3mr3124317ugg; Mon, 04 Sep 2006 11:16:08 -0700 (PDT) Received: by 10.67.28.14 with HTTP; Mon, 4 Sep 2006 11:16:08 -0700 (PDT) Message-ID: Date: Mon, 4 Sep 2006 14:16:08 -0400 From: "Scott Ullrich" To: "Bjoern A. Zeeb" In-Reply-To: <20060904180515.V44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> <20060904180515.V44392@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: Where is IPSec NAT-T 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: Mon, 04 Sep 2006 18:16:11 -0000 On 9/4/06, Bjoern A. Zeeb wrote: > the patch only support kame ipsec. I guess that's the problem. Could > you try it building with kame ipsec instead of fast_ipsec and let us > know if that worked? That may work okay but then would I loose HIFN support, etc? Scott From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 01:40:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5251816A4DE; Tue, 5 Sep 2006 01:40:59 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from ms-smtp-01.socal.rr.com (ms-smtp-01.socal.rr.com [66.75.162.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB50043D45; Tue, 5 Sep 2006 01:40:58 +0000 (GMT) (envelope-from dave@dogwood.com) Received: from white.dogwood.com (white.dogwood.com [66.91.140.178]) by ms-smtp-01.socal.rr.com (8.13.6/8.13.6) with ESMTP id k851era6029246; Mon, 4 Sep 2006 18:40:54 -0700 (PDT) Received: from Gecko.dogwood.com (dhcp-31.dogwood.com [192.168.231.31]) by white.dogwood.com (8.13.4/8.13.4) with ESMTP id k851eoBD071692; Mon, 4 Sep 2006 15:40:52 -1000 (HST) (envelope-from dave@dogwood.com) Message-Id: <7.0.1.0.2.20060904152932.024c4b78@dogwood.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 04 Sep 2006 15:41:58 -1000 To: John Hay , gnn@freebsd.org From: David Cornejo In-Reply-To: <20060904072313.GA83757@zibbi.meraka.csir.co.za> References: <20060903132214.GA40993@zibbi.meraka.csir.co.za> <20060904072313.GA83757@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (white.dogwood.com [192.168.231.150]); Mon, 04 Sep 2006 15:40:53 -1000 (HST) X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host routes 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, 05 Sep 2006 01:40:59 -0000 as the author of the route code in olsr I can explain what I was trying to do: for routing purposes what we need are point-to-point routes, the subnets on the mesh interfaces are there only to facilitate broadcasting the routing packets. because of the way freebsd is wired, to support multiple interfaces i resorted to a raw packet library. i never much liked this, but it works the reason for the broadcast is to provide an undirected address to send packets to that everyone would receive. with no subnet we'd have to send OLSR packets to each and every other host we're directly connected to. if i had to do it over again, i'd probably use multicast. i actually used another protocol (TBRPF) and IPv4 multicast successfully in a prior project. multicast would eliminate the need for subnetting and would cope with the problem you have with multiple host interfaces that have the same address but aren't connected to each other. dave c At 09:23 PM 9/3/2006, John Hay wrote: >On Mon, Sep 04, 2006 at 11:04:44AM +0900, gnn@freebsd.org wrote: > > At Sun, 3 Sep 2006 15:22:14 +0200, > > John Hay wrote: > > > > > > Hi, > > > > > > Does anybody know how to add a direct IPv6 host route that > actually works? > > > What I mean is not through a gateway, but for one directly reachable. > > > > > > I know it normally isn't needed because it will just work, but I'm > > > trying to add FreeBSD IPv6 capability to net/olsrd. It looks like I have > > > most of the rest working, but this is one of the last things tripping > > > me up. >... > > > > > > So anybody that know how to add a direct IPv6 host route on FreeBSD? > > > > > > > Can you show us the commands, network layout and the output of netstat > > -r and ndp -a? > >Well maybe I should start with how it works on IPv4. You can see the code >in work/olsrd-0.4.10/src/bsd/kernel_routes.c if you extract the net/olsrd >port. In the case where the machine is directly connected, ie. not through >a gateway, a network route with a /32 netmask is added with the cloning >flag. So if you use the 10.1.9.0/24 network and have two hosts that can >"see" each other, 10.1.9.1 and 10.1.9.2, on 10.1.9.1 you will see a route >like this added: > >10.1.9.2/32 link#2 UC 0 0 ath1 > >and as soon as there is traffic the arp will cause this: > >10.1.9.2 00:02:6f:34:21:a2 UHLW 2 2286102 ath1 1176 => > >So I guess I want to imitate something like this in a way that the linux >boxes that also run olsr can interoperate. > >My current test setup have 3 boxes on the 2001:4200:7000:15:: subnet, so >ifconfig on rtrg looks like this: > >################ >ath0: flags=8843 mtu 1500 > inet6 fe80::202:6fff:fe22:9547%ath0 prefixlen 64 scopeid 0x3 > inet6 2001:4200:7000:15:202:6fff:fe22:9547 prefixlen 64 > inet6 2001:4200:7000:15:: prefixlen 64 anycast > ether 00:02:6f:22:95:47 > media: IEEE 802.11 Wireless Ethernet autoselect > (autoselect ) > status: associated > ssid koppiemesh channel 149 bssid 02:02:6f:41:19:27 > authmode OPEN privacy OFF txpowmax 24 bmiss 7 burst bintval 100 >################ > >To lessen my typing I have these entries in /etc/hosts: > >2001:4200:7000:15:202:6fff:fe22:9547 rtrg >2001:4200:7000:15:202:6fff:fe41:1927 rtr2 > >The machine I am working on is the first one, rtrg. If I don't do >anything, I can ping6 rtr2, but I would like to add a route and still >have it work. I have tried many things on rtrg but none seem to give >me something that works. Some of the ones I have tried: > >route add -inet6 -host rtr2 -interface ath0 >route add -inet6 -host rtr2 -interface ath0 -cloning -nostatic --llinfo >route add -inet6 -net rtr2 -prefixlen 128 -interface ath0 -cloning >-nostatic --llinfo >route add -inet6 -host rtr2 fe80::202:6fff:fe22:9547%ath0 -ifp ath0 >route add -inet6 -host rtr2 -interface fe80::202:6fff:fe22:9547%ath0 -ifp ath0 >route add -inet6 -host rtr2 rtrg -cloning -nostatic > >Thanks. > >John >-- >John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 02:18:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A9F816A4DA for ; Tue, 5 Sep 2006 02:18:02 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864AA43D49 for ; Tue, 5 Sep 2006 02:18:01 +0000 (GMT) (envelope-from smw2010@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so837734nzn for ; Mon, 04 Sep 2006 19:18:00 -0700 (PDT) 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=dlTDJQjTNHY1HTNRh9kLsuouqlvQu53zo2BkY7DvqxkGfae6XxieZwWGudKkfd6CLv0t59jEB9ZfdtHxQqCF6Okj7AXCdWhdtwXwrCHn7oAOoyusTEWxFzFRmaOkHxfKQA4OPefbCiXZpDAkC7b/cebF6N/JN0Sz6GBT1sUqt44= Received: by 10.65.73.16 with SMTP id a16mr4015689qbl; Mon, 04 Sep 2006 19:18:00 -0700 (PDT) Received: by 10.64.148.18 with HTTP; Mon, 4 Sep 2006 19:18:00 -0700 (PDT) Message-ID: Date: Tue, 5 Sep 2006 12:18:00 +1000 From: "Sam Wun" 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 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: half-duplex 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, 05 Sep 2006 02:18:02 -0000 Hi, I am running a FreeBSD 5.4 stable as a network router. I don't know any reason why one of the ethernet ports becomes half-duplex. Here is its detail: em1: flags=8843 mtu 1500 options=b inet 60.1.2.3 netmask 0xfffffffc broadcast 220.233.99.39 ether 00:04:23:bc:3a:d1 media: Ethernet autoselect (10baseT/UTP ) status: active em2: flags=8843 mtu 1500 options=b inet 10.1.10.1 netmask 0xffffff00 broadcast 10.1.10.255 ether 00:04:23:bc:3a:d2 media: Ethernet autoselect (1000baseTX ) status: active This network card is a Quat Port Intel card. Is there any way I can "reset" it to full-duplex and 1000baseT without close down the network connection on em1? I know I can use following command to change it: ifconfig em1 media 100baseTX mediaopt full-duplex but if this not work, it will close down the entire internet connection, which I try to avoid. Thanks S From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 03:04:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C97C216A4DA for ; Tue, 5 Sep 2006 03:04:45 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE7D43D46 for ; Tue, 5 Sep 2006 03:04:40 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.7/8.13.1) with ESMTP id k8534bvW069896; Mon, 4 Sep 2006 23:04:37 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.7/8.13.1/Submit) id k8534Vkn069895; Mon, 4 Sep 2006 23:04:31 -0400 (EDT) (envelope-from bv) Date: Mon, 4 Sep 2006 23:04:31 -0400 From: Bill Vermillion To: Sam Wun Message-ID: <20060905030431.GC69355@wjv.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on bilver.wjv.com Cc: freebsd-net@freebsd.org Subject: Re: half-duplex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2006 03:04:45 -0000 On Tue, Sep 05, 2006 at 12:18 , after knocking over a stack of dishes on the heat sink Sam Wun wondered out loud about: > Hi, > I am running a FreeBSD 5.4 stable as a network router. > I don't know any reason why one of the ethernet ports becomes half-duplex. > Here is its detail: > em1: flags=8843 mtu 1500 > options=b > inet 60.1.2.3 netmask 0xfffffffc broadcast 220.233.99.39 > ether 00:04:23:bc:3a:d1 > media: Ethernet autoselect (10baseT/UTP ) > status: active > em2: flags=8843 mtu 1500 > options=b > inet 10.1.10.1 netmask 0xffffff00 broadcast 10.1.10.255 > ether 00:04:23:bc:3a:d2 > media: Ethernet autoselect (1000baseTX ) > status: active > This network card is a Quat Port Intel card. Is there any way > I can "reset" it to full-duplex and 1000baseT without close > down the network connection on em1? I know I can use following > command to change it: ifconfig em1 media 100baseTX mediaopt > full-duplex Well 'em1' shows it is alos 10Mg second. Autoselect >usually< works well but there can be problems with some switches. I am assuming you are using a switch and not a hub - as that won't work FDX. You should be able to set the startup in the settings in your rc.conf with the meidaopt argument. man 4 em shows that only FDX is supported at high speeds - 1000mb/sec. And you are getting only 10mb. Is that what you want. If you are connected to a switch capable of 1000mbit, check the switch settings. Cicso had release notes and indicated 6 ways things will NOT work and one way it will. > but if this not work, it will close down the entire internet > connection, which I try to avoid. I don't know if using the 'mediopt' argument will shut down the entire connection - but you probably are going to have to try. If it works from the commnand line be sure to add it to the startup script so it gets fixed on a reboot. It SHOULD work with auto-select unless you have switch and/or cabling problems. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 03:09:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 803BF16A4DE for ; Tue, 5 Sep 2006 03:09:45 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from ms-smtp-04.socal.rr.com (ms-smtp-04.socal.rr.com [66.75.162.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28E3043D45 for ; Tue, 5 Sep 2006 03:09:44 +0000 (GMT) (envelope-from dave@dogwood.com) Received: from white.dogwood.com (white.dogwood.com [66.91.140.178]) by ms-smtp-04.socal.rr.com (8.13.6/8.13.6) with ESMTP id k8539hGE007212; Mon, 4 Sep 2006 20:09:44 -0700 (PDT) Received: from Gecko.dogwood.com (dhcp-31.dogwood.com [192.168.231.31]) by white.dogwood.com (8.13.4/8.13.4) with ESMTP id k8539gJn072265; Mon, 4 Sep 2006 17:09:43 -1000 (HST) (envelope-from dave@dogwood.com) Message-Id: <7.0.1.0.2.20060904170746.024fe928@dogwood.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 04 Sep 2006 17:10:49 -1000 To: "Sam Wun" , freebsd-net@freebsd.org From: David Cornejo In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (white.dogwood.com [192.168.231.150]); Mon, 04 Sep 2006 17:09:43 -1000 (HST) X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: Re: half-duplex 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, 05 Sep 2006 03:09:45 -0000 At 04:18 PM 9/4/2006, Sam Wun wrote: >Hi, > >I am running a FreeBSD 5.4 stable as a network router. >I don't know any reason why one of the ethernet ports becomes half-duplex. >Here is its detail: > >em1: flags=8843 mtu 1500 > options=b > inet 60.1.2.3 netmask 0xfffffffc broadcast 220.233.99.39 > ether 00:04:23:bc:3a:d1 > media: Ethernet autoselect (10baseT/UTP ) > status: active >em2: flags=8843 mtu 1500 > options=b > inet 10.1.10.1 netmask 0xffffff00 broadcast 10.1.10.255 > ether 00:04:23:bc:3a:d2 > media: Ethernet autoselect (1000baseTX ) > status: active > >This network card is a Quat Port Intel card. >Is there any way I can "reset" it to full-duplex and 1000baseT without close >down the network connection on em1? >I know I can use following command to change it: >ifconfig em1 media 100baseTX mediaopt full-duplex > >but if this not work, it will close down the entire internet connection, >which I try to avoid. > >Thanks >S >_______________________________________________ >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" Check and make sure there's nothing wrong with what it's connected to. It's also possible the auto detection is having problems. To force the adapter use this command: ifconfig em0 media 1000baseTX mediaopt full-duplex dave c From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 03:10:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E949D16A4DA for ; Tue, 5 Sep 2006 03:10:54 +0000 (UTC) (envelope-from wwwrun@h5497.serverkompetenz.net) Received: from h5497.serverkompetenz.net (nickeys.de [81.169.174.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F7A443D46 for ; Tue, 5 Sep 2006 03:10:54 +0000 (GMT) (envelope-from wwwrun@h5497.serverkompetenz.net) Received: by h5497.serverkompetenz.net (Postfix, from userid 30) id 79F35865B7D; Tue, 5 Sep 2006 05:02:20 +0200 (CEST) To: freebsd-net@freebsd.org From: WellsFargo Online Content-Transfer-Encoding: 8bit Message-Id: <20060905030220.79F35865B7D@h5497.serverkompetenz.net> Date: Tue, 5 Sep 2006 05:02:20 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Urgent Action : Your Account Has Been Suspended 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, 05 Sep 2006 03:10:55 -0000 [logo_62sq.gif] [coach.gif] Dear valued WellsFargo member: Due to concerns, for the safety and integrity of the wellsfargo account we have issued this warning message We have noticed that your Wells Fargo online account needs to be updated onceagain, please enteryour online account information, because we haveto verify all of the online accounts after we have updated our Wells FargoOnline Banking site. To verify your online account and access your bank account, please click on the link below: [1][al_continue_off.gif] [2]Continue to Stop Payment This e-mail was sent to all of our Wells Fargo customers. Recently, we have found that manyaccounts were hacked. For furtherinformation, please contact our Customer Services. Consumer Credit Card Services: Customer Service: 1-800-642-4720 Application Status: 1-800-967-9521 Security Issues: Phone: 415-623-7706 Fax: 415-544-0826 Email: [3]myershh@wellsfargo.com Sincerely, Wells FargoMember Services Team Thank You [4]About Wells Fargo | [5]Employment | [6]Report Email Fraud | [7]Privacy, Security & Legal | [8]Home 1995 - 2006 Wells Fargo. All rights reserved. References 1. http://www.piles.gr/themes/piles/images/.sec/www.wellsfargo.com/updateyouracount/index.html?wellsfargo.comlogin.uersr 2. http://www.piles.gr/themes/piles/images/.sec/www.wellsfargo.com/updateyouracount/index.html?wellsfargo.comlogin.uersr 3. http://mail.yahoo.com/config/login?/ym/Compose?To=myershh@wellsfargo.com 4. http://www.wellsfargo.com/about/about.jhtml 5. http://www.wellsfargo.com/employment 6. http://www.wellsfargo.com/privacy_security/email_fraud/report.jhtml 7. http://www.wellsfargo.com/privacy_security/index.jhtml 8. http://www.wellsfargo.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 03:12:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6494C16A75C for ; Tue, 5 Sep 2006 03:12:09 +0000 (UTC) (envelope-from wwwrun@h5497.serverkompetenz.net) Received: from h5497.serverkompetenz.net (nickeys.de [81.169.174.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id C70D643D45 for ; Tue, 5 Sep 2006 03:12:08 +0000 (GMT) (envelope-from wwwrun@h5497.serverkompetenz.net) Received: by h5497.serverkompetenz.net (Postfix, from userid 30) id 2348886687D; Tue, 5 Sep 2006 05:04:34 +0200 (CEST) To: freebsd-net@freebsd.org From: WellsFargo Online Content-Transfer-Encoding: 8bit Message-Id: <20060905030434.2348886687D@h5497.serverkompetenz.net> Date: Tue, 5 Sep 2006 05:04:34 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Urgent Action : Your Account Has Been Suspended 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, 05 Sep 2006 03:12:09 -0000 [logo_62sq.gif] [coach.gif] Dear valued WellsFargo member: Due to concerns, for the safety and integrity of the wellsfargo account we have issued this warning message We have noticed that your Wells Fargo online account needs to be updated onceagain, please enteryour online account information, because we haveto verify all of the online accounts after we have updated our Wells FargoOnline Banking site. To verify your online account and access your bank account, please click on the link below: [1][al_continue_off.gif] [2]Continue to Stop Payment This e-mail was sent to all of our Wells Fargo customers. Recently, we have found that manyaccounts were hacked. For furtherinformation, please contact our Customer Services. Consumer Credit Card Services: Customer Service: 1-800-642-4720 Application Status: 1-800-967-9521 Security Issues: Phone: 415-623-7706 Fax: 415-544-0826 Email: [3]myershh@wellsfargo.com Sincerely, Wells FargoMember Services Team Thank You [4]About Wells Fargo | [5]Employment | [6]Report Email Fraud | [7]Privacy, Security & Legal | [8]Home 1995 - 2006 Wells Fargo. All rights reserved. References 1. http://www.piles.gr/themes/piles/images/.sec/www.wellsfargo.com/updateyouracount/index.html?wellsfargo.comlogin.uersr 2. http://www.piles.gr/themes/piles/images/.sec/www.wellsfargo.com/updateyouracount/index.html?wellsfargo.comlogin.uersr 3. http://mail.yahoo.com/config/login?/ym/Compose?To=myershh@wellsfargo.com 4. http://www.wellsfargo.com/about/about.jhtml 5. http://www.wellsfargo.com/employment 6. http://www.wellsfargo.com/privacy_security/email_fraud/report.jhtml 7. http://www.wellsfargo.com/privacy_security/index.jhtml 8. http://www.wellsfargo.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 06:21:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABBAD16A4E2 for ; Tue, 5 Sep 2006 06:21:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40DEE43D5D for ; Tue, 5 Sep 2006 06:21:03 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c39so2693078pyd for ; Mon, 04 Sep 2006 23:21:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JIPyAKjbgRNge/7HSUnPjr8vSvJZOrj0DeaDcOhFyrjDQu+NgHPLmXFRsJEbm4arh2SFy81CEM28UF14/vowultovbv0F52n6tGr9K+TwFYDyF/JgJSclGZ8PhPy0blA1r7HZLVcTzYCY+D5b/VT1NvHiF1u4tUEFqgJ4Ckuuuw= Received: by 10.35.60.15 with SMTP id n15mr11777642pyk; Mon, 04 Sep 2006 23:21:02 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Mon, 4 Sep 2006 23:21:02 -0700 (PDT) Message-ID: <2a41acea0609042321h97feecal9b50979aa964c257@mail.gmail.com> Date: Mon, 4 Sep 2006 23:21:02 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44FBFAFF.3030702@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060902065044.V84468@fledge.watson.org> <44FBFAFF.3030702@freebsd.org> Cc: freebsd-net , freebsd-current , Robert Watson Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 06:21:06 -0000 On 9/4/06, Andre Oppermann wrote: > Robert Watson wrote: > > On Fri, 1 Sep 2006, Jack Vogel wrote: > > > >> This is a patch for the stack and the em driver to enable TSO on > >> CURRENT. Previously I had problems getting it to work, but this is > >> functional. > >> > >> I should note that CURRENT is being a pain right now, when I comment > >> out em in the config the kernel panics coming up, so I had to > >> substitute this code into the tree. Rather bizarre :) > >> > >> I have this functionality running on a 6.1 based system, and our test > >> group is already testing against that driver, so far things are > >> looking good. > >> > >> I have designed it so the driver can continue to be built without > >> support. There is also a sysctl in the stack code so you can set > >> net.inet.tcp.tso_enable on or off and compare. > >> > >> I know there may be some refinements to add in, but I would like to > >> get this into CURRENT as a start. > > > > > > Per my earlier comments, I would like to see the issue of doing an > > on-demand segmentation of TCP at the IP layer in the event that the > > early route decision becomes stale (i.e., ipfw fwd, ipsec, etc), as > > occurs in the NetBSD code. Likewise, I think Andre's comment about > > making the routing decision up front for the TCP connection as part of > > the existing search for PMTU information makes sense. I'm more > > interested in seeing the former addressed than the latter before the > > commit, though, which can quite easily follow. > > In the patch I posted yesterday into this thread the TSO decision is > done at connection setup time in tcp_mss() where all other initial TCP > connection parameters are initilized as well. If the same interface > we took the MTU values from, is found to support TSO it gets enabled for > this connection too. Should the egress interface change during the > lifetime of the connection and the new one doesn't support TSO we get > an EMSGSIZE error from ip_output(), disable TSO for this connection and > have tcp_output() resend the data again while doing the segmentation > itself as usual. Should the connection change back to the TSO capable > interface later on we don't re-enable TSO for the connection though. > OTOH having a bulk transfer TCP session (where TSO actually helps) migrate > between interface is a *very* rare occurence and not worth special casing > for it. This looks cool Andre, I've been in vacation mode the past couple days, but when I get to work tomorrow I'll look at it more closely and give it a try with my driver changes. Thanks :) Jack From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 08:45:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DEFE16A4DA for ; Tue, 5 Sep 2006 08:45:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC8343D49 for ; Tue, 5 Sep 2006 08:45:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id B2BF61FFDD6 for ; Tue, 5 Sep 2006 10:45:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 58CFC1FFDD4; Tue, 5 Sep 2006 10:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 736664448D6 for ; Tue, 5 Sep 2006 08:43:06 +0000 (UTC) Date: Tue, 5 Sep 2006 08:43:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: Message-ID: <20060905084243.U44392@maildrop.int.zabbadoz.net> References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> <20060904180515.V44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: Where is IPSec NAT-T 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, 05 Sep 2006 08:45:12 -0000 On Mon, 4 Sep 2006, Scott Ullrich wrote: > On 9/4/06, Bjoern A. Zeeb wrote: >> the patch only support kame ipsec. I guess that's the problem. Could >> you try it building with kame ipsec instead of fast_ipsec and let us >> know if that worked? > > That may work okay but then would I loose HIFN support, etc? for IPSec. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 08:53:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 284F316A4DE for ; Tue, 5 Sep 2006 08:53:02 +0000 (UTC) (envelope-from spadge@fromley.net) Received: from cht-smtp-002.bulldogdsl.com (smtp.bulldogdsl.com [83.146.21.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B0543D70 for ; Tue, 5 Sep 2006 08:52:52 +0000 (GMT) (envelope-from spadge@fromley.net) Received: by cht-smtp-002.bulldogdsl.com (Postfix, from userid 1002) id CCFD31E43FD; Tue, 5 Sep 2006 09:52:50 +0100 (BST) X-Spam-Abuse: Please report all spam/abuse matters to abuse@bulldogdsl.com X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on cht-smtp-002.bulldogdsl.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=8.0 tests=RCVD_IN_SORBS_WEB autolearn=disabled version=3.1.3 Received: from tobermory.home (host-84-9-161-102.bulldogdsl.com [84.9.161.102]) by cht-smtp-002.bulldogdsl.com (Postfix) with ESMTP id D19A71E439D; Tue, 5 Sep 2006 09:52:49 +0100 (BST) Received: from webmail.fromley.net (localhost.home [127.0.0.1]) by tobermory.home (Postfix) with ESMTP id F3141A6DBE; Tue, 5 Sep 2006 09:52:50 +0100 (BST) Received: from 213.123.179.188 (SquirrelMail authenticated user spadge) by webmail.fromley.net with HTTP; Tue, 5 Sep 2006 09:52:51 +0100 (BST) Message-ID: <34276.213.123.179.188.1157446371.squirrel@webmail.fromley.net> In-Reply-To: References: Date: Tue, 5 Sep 2006 09:52:51 +0100 (BST) From: "Spadge Fromley" To: "Sam Wun" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-net@freebsd.org Subject: Re: half-duplex 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, 05 Sep 2006 08:53:02 -0000 > em1: flags=8843 mtu 1500 > options=b > inet 60.1.2.3 netmask 0xfffffffc broadcast 220.233.99.39 > ether 00:04:23:bc:3a:d1 > media: Ethernet autoselect (10baseT/UTP ) > status: active It's quite possibly picking that up from the thing it's plugged into, ie the modem (I'm guessing here - I assume that's what it's plugged into). If the modem doesn't go over 10mbits half-duplex, then neither will the card it's plugged into. Further information required for further comment. -- Spadge 'Intoccabile' From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 09:08:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A065D16A4DD for ; Tue, 5 Sep 2006 09:08:22 +0000 (UTC) (envelope-from syncman0x@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76DA443D49 for ; Tue, 5 Sep 2006 09:08:20 +0000 (GMT) (envelope-from syncman0x@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so2062319uge for ; Tue, 05 Sep 2006 02:08:19 -0700 (PDT) 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:content-transfer-encoding:content-disposition; b=C7eJP4izkIXDVNe6weNw88x+2OqnXS1TbhZzDb2yQcNP+meV4Zqb2ec4uDpBdL7MEGUTHxjAXlPuUfEC1SVhcrA5fq1pzK6Szv3EMRpC0cMvrCAr85AiogDy5UJoWJi31LwRqV+hUSSaesMbd/roTFsRQyAfn243hiiWPUWzkDw= Received: by 10.67.97.18 with SMTP id z18mr3470249ugl; Tue, 05 Sep 2006 02:08:19 -0700 (PDT) Received: by 10.67.100.19 with HTTP; Tue, 5 Sep 2006 02:08:19 -0700 (PDT) Message-ID: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> Date: Tue, 5 Sep 2006 19:08:19 +1000 From: "Andrew Sinclair" 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: Request status on sk(4) for 88E8053 Yukon PCI-E GbE 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, 05 Sep 2006 09:08:22 -0000 Attempting to diagnose an undetected NIC: $ uname -a FreeBSD FreeSBIE.LiveCD 6.1-RC2 FreeBSD 6.1-RC2 #3: $ pciconf -lv ... none2@pci2:0:0: class=0x020000 card=0x00011179 chip=0x436211ab rev=0x15 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' class = network subclass = ethernet ... Tried the live disc above and 6.1-RELEASE. A friend suggested this list with this info: You could try asking on -net. There _is_ active code to support the 88E8053 but the bit to probe it is disabled. (#ifdef not_yet) Computer is a Toshiba TECRA PTM40A-0NU009 From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 09:20:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F350F16A4DD for ; Tue, 5 Sep 2006 09:20:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E0C843D45 for ; Tue, 5 Sep 2006 09:20:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 6A1D61FFDD8; Tue, 5 Sep 2006 11:20:10 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 09B681FFDD6; Tue, 5 Sep 2006 11:20:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E757F4448D6; Tue, 5 Sep 2006 09:19:07 +0000 (UTC) Date: Tue, 5 Sep 2006 09:19:07 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Sinclair In-Reply-To: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> Message-ID: <20060905091820.A44392@maildrop.int.zabbadoz.net> References: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: Request status on sk(4) for 88E8053 Yukon PCI-E GbE 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, 05 Sep 2006 09:20:12 -0000 On Tue, 5 Sep 2006, Andrew Sinclair wrote: > $ pciconf -lv > ... > none2@pci2:0:0: class=0x020000 card=0x00011179 chip=0x436211ab rev=0x15 > hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' > class = network > subclass = ethernet > ... This is becoming a FAQ;) Search the archives of this list for example. Maybe start with http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 16:21:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93C1116A4DE for ; Tue, 5 Sep 2006 16:21:13 +0000 (UTC) (envelope-from junics-fbsdstable@atlantis.maniacs.se) Received: from mammoth.unixsh.net (mammoth.unixsh.net [195.35.83.67]) by mx1.FreeBSD.org (Postfix) with SMTP id 07E8443D68 for ; Tue, 5 Sep 2006 16:21:09 +0000 (GMT) (envelope-from junics-fbsdstable@atlantis.maniacs.se) Received: (qmail 4951 invoked from network); 5 Sep 2006 16:21:08 -0000 Received: from localhost.maniacs.se (HELO ?192.168.0.34?) (127.0.0.1) by localhost.maniacs.se with SMTP; 5 Sep 2006 16:21:08 -0000 Message-ID: <44FDA3F3.6090003@atlantis.maniacs.se> Date: Tue, 05 Sep 2006 18:21:07 +0200 From: Thomas Herrlin User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Danny Braniss References: <2a41acea0608301145j7bbed961j33ce903a27d8963d@mail.gmail.com> In-Reply-To: <2a41acea0608301145j7bbed961j33ce903a27d8963d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tcp/udp performance 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, 05 Sep 2006 16:21:13 -0000 Jack Vogel wrote: > On 8/30/06, Danny Braniss wrote: >> >> ever since 6.1 I've seen fluctuations in the performance of >> the em (Intel(R) PRO/1000 Gigabit Ethernet). >> >> motherboard OBN (On Board NIC) >> ---------------- ------------------ >> 1- Intel SE7501WV2S Intel 82546EB::2.1 >> 2- Intel SE7320VP2D2 INTEL 82541 >> 3- Sun Fire X4100 Server Intel(R) PRO/1000 >> >> test 1: writing to a NetApp filer via NFS/UDP >> FreeBSD Linux >> MegaBytes/sec >> 1- Average: 18.48 32.61 >> 2- Average: 15.69 35.72 >> 3- Average: 16.61 29.69 >> (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in >> speed of >> around 60% on FreeBSD but none on Linux) >> >> test2: iperf using 1 as server: >> FreeBSD(*) Linux >> Mbits/sec >> 1- 926 905 (this machine was busy) >> 2- 545 798 >> 3- 910 912 >> *: did a 'sysctl net.inet.tcp.sendspace=65536' >> >> >> So, it seems to me something is not that good in the UDP department, but >> I can't find what to tweek. >> >> Any help? >> >> danny > > Have discussed this some internally, the best idea I've heard is that > UDP is not giving us the interrupt rate that TCP would, so we end up > not cleaning up as often, and thus descriptors might not be as quickly > available.. Its just speculation at this point. If a high interrupt rate is a problem and your NIC+driver supports it, then try enabling polling(4) aswell. This has helped me for bulk transfers on slower boxes but i have noticed problems with ALTQ/dummynet and other highly realtime dependent networking code. YMMV. More info in the man 4 polling. I think recent linux kernels/drivers have this implemented so it will enable it dynamically on high load. However i only skimmed the documents and i'm not a linux expert so i may be wrong on that. /Junics > > Try this: the default is only to have 256 descriptors, try going for > the MAX > which is 4K. > > Cheers, > > Jack > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 16:25:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id 6C3A516A4E8; Tue, 5 Sep 2006 16:25:42 +0000 (UTC) Date: Tue, 5 Sep 2006 16:25:42 +0000 From: Prafulla Deuskar To: Jack Vogel Message-ID: <20060905162542.GA63869@hub.freebsd.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-STABLE on an i386 Cc: freebsd-net , freebsd-current , Andre Oppermann Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 16:25:42 -0000 Jack Vogel [jfvogel@gmail.com] wrote: > On 9/2/06, Andre Oppermann wrote: > > >I can't comment on the em part but the tcp_output.c stuff looks > >very much like a straight port from NetBSD. If we take code from > >the other BSDs we have to remark this in the emails we send with > >patches and the commit message (otherwise we get accused of 'stealing > >without attribution'). > > I dont know that I'd call it a straight port, rather I was working from some > prototype code that Prafulla had working back on 4.7, but I think at that > time that he may have patterned it after NetBSD. I don't think NetBSD had TSO support in 2002 when I first did the 4.7 patch for internal testing. Prafulla From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 16:49:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1595716A4DF for ; Tue, 5 Sep 2006 16:49:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9915A43D60 for ; Tue, 5 Sep 2006 16:49:55 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3514937pye for ; Tue, 05 Sep 2006 09:49:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=toY3mn8PMuCG0gBZcx55FB6V4+bSPfYZFjmnt+McZAxZdIM0kS/PYTwup2CTACBoOpaTEfhugb2R7acvlz5Bvx66XfJxwGJ6JEBOf1MdPaOWR0r5cGgA4m65URQebnDsnpTNK75tN6606hz+veCDMQW+bOnKoLKXN/87EWCHlb4= Received: by 10.35.41.12 with SMTP id t12mr12827824pyj; Tue, 05 Sep 2006 09:49:55 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Tue, 5 Sep 2006 09:49:54 -0700 (PDT) Message-ID: <2a41acea0609050949v2b49ceeemc914abd6a273c540@mail.gmail.com> Date: Tue, 5 Sep 2006 09:49:55 -0700 From: "Jack Vogel" To: "Prafulla Deuskar" In-Reply-To: <20060905162542.GA63869@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> Cc: freebsd-net , freebsd-current , Andre Oppermann Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 16:49:58 -0000 On 9/5/06, Prafulla Deuskar wrote: > Jack Vogel [jfvogel@gmail.com] wrote: > > On 9/2/06, Andre Oppermann wrote: > > > > >I can't comment on the em part but the tcp_output.c stuff looks > > >very much like a straight port from NetBSD. If we take code from > > >the other BSDs we have to remark this in the emails we send with > > >patches and the commit message (otherwise we get accused of 'stealing > > >without attribution'). > > > > I dont know that I'd call it a straight port, rather I was working from some > > prototype code that Prafulla had working back on 4.7, but I think at that > > time that he may have patterned it after NetBSD. > > I don't think NetBSD had TSO support in 2002 when I first did the 4.7 patch > for internal testing. Sorry if I misspoke Prafulla, you would know better than I :) Jack From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 17:08:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30A5A16A4DD for ; Tue, 5 Sep 2006 17:08:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 635AE43D58 for ; Tue, 5 Sep 2006 17:08:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34107 invoked from network); 5 Sep 2006 16:53:35 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2006 16:53:35 -0000 Message-ID: <44FDAF08.20407@freebsd.org> Date: Tue, 05 Sep 2006 19:08:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Prafulla Deuskar References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> In-Reply-To: <20060905162542.GA63869@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 17:08:31 -0000 Prafulla Deuskar wrote: > Jack Vogel [jfvogel@gmail.com] wrote: > >>On 9/2/06, Andre Oppermann wrote: >> >> >>>I can't comment on the em part but the tcp_output.c stuff looks >>>very much like a straight port from NetBSD. If we take code from >>>the other BSDs we have to remark this in the emails we send with >>>patches and the commit message (otherwise we get accused of 'stealing >>>without attribution'). >> >>I dont know that I'd call it a straight port, rather I was working from some >>prototype code that Prafulla had working back on 4.7, but I think at that >>time that he may have patterned it after NetBSD. > > I don't think NetBSD had TSO support in 2002 when I first did the 4.7 patch > for internal testing. OK, perhaps they lifted it from your patch then. They just looks awfully similiar that's why I thought it came from NetBSD. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 18:23:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id A826F16A4DF; Tue, 5 Sep 2006 18:23:13 +0000 (UTC) Date: Tue, 5 Sep 2006 18:23:13 +0000 From: Prafulla Deuskar To: Andre Oppermann Message-ID: <20060905182313.GA85389@hub.freebsd.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FDAF08.20407@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-STABLE on an i386 Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 18:23:13 -0000 Andre Oppermann [andre@freebsd.org] wrote: > Prafulla Deuskar wrote: > >Jack Vogel [jfvogel@gmail.com] wrote: > > > >>On 9/2/06, Andre Oppermann wrote: > >> > >> > >>>I can't comment on the em part but the tcp_output.c stuff looks > >>>very much like a straight port from NetBSD. If we take code from > >>>the other BSDs we have to remark this in the emails we send with > >>>patches and the commit message (otherwise we get accused of 'stealing > >>>without attribution'). > >> > >>I dont know that I'd call it a straight port, rather I was working from > >>some > >>prototype code that Prafulla had working back on 4.7, but I think at that > >>time that he may have patterned it after NetBSD. > > > >I don't think NetBSD had TSO support in 2002 when I first did the 4.7 > >patch for internal testing. > > OK, perhaps they lifted it from your patch then. They just looks awfully > similiar that's why I thought it came from NetBSD. > Your patch looks good and is the way to go. So after Jack confirms that your patch works with the em driver would you commit to to -current? The driver related changes can follow.. Later we also need to fix ifconfig so that user can enable/disable TSO on the interface. Thanks, -Prafulla > From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 19:57:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCECA16A5B6 for ; Tue, 5 Sep 2006 19:57:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5BAB43E00 for ; Tue, 5 Sep 2006 19:56:16 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35418 invoked from network); 5 Sep 2006 19:41:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2006 19:41:20 -0000 Message-ID: <44FDD65C.6070109@freebsd.org> Date: Tue, 05 Sep 2006 21:56:12 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Prafulla Deuskar References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> <20060905182313.GA85389@hub.freebsd.org> In-Reply-To: <20060905182313.GA85389@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 19:57:20 -0000 Prafulla Deuskar wrote: > Andre Oppermann [andre@freebsd.org] wrote: >> Prafulla Deuskar wrote: >>> Jack Vogel [jfvogel@gmail.com] wrote: >>> >>>> On 9/2/06, Andre Oppermann wrote: >>>> >>>> >>>>> I can't comment on the em part but the tcp_output.c stuff looks >>>>> very much like a straight port from NetBSD. If we take code from >>>>> the other BSDs we have to remark this in the emails we send with >>>>> patches and the commit message (otherwise we get accused of 'stealing >>>>> without attribution'). >>>> I dont know that I'd call it a straight port, rather I was working from >>>> some >>>> prototype code that Prafulla had working back on 4.7, but I think at that >>>> time that he may have patterned it after NetBSD. >>> I don't think NetBSD had TSO support in 2002 when I first did the 4.7 >>> patch for internal testing. >> OK, perhaps they lifted it from your patch then. They just looks awfully >> similiar that's why I thought it came from NetBSD. >> > Your patch looks good and is the way to go. > > So after Jack confirms that your patch works with the em driver > would you commit to to -current? Absolutely. :-) > The driver related changes can follow.. > > Later we also need to fix ifconfig so that user can enable/disable TSO on the interface. I'll do that together with the TSO code. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 20:00:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB64916A516 for ; Tue, 5 Sep 2006 20:00:46 +0000 (UTC) (envelope-from linux@giboia.org) Received: from nf-out-f131.google.com (nf-out-f131.google.com [64.233.182.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45BFC43D60 for ; Tue, 5 Sep 2006 20:00:36 +0000 (GMT) (envelope-from linux@giboia.org) Received: by nf-out-f131.google.com with SMTP id x9so120152nfb for ; Tue, 05 Sep 2006 13:00:35 -0700 (PDT) Received: by 10.90.106.18 with SMTP id e18mr180868agc; Tue, 05 Sep 2006 13:00:35 -0700 (PDT) Received: by 10.90.120.19 with HTTP; Tue, 5 Sep 2006 13:00:34 -0700 (PDT) Message-ID: <6e6841490609051300t25a5f0admf9051099597947cb@mail.gmail.com> Date: Tue, 5 Sep 2006 17:00:34 -0300 From: "Gilberto Villani Brito" To: freebsd-net@freebsd.org In-Reply-To: <001501c6cde0$7da71c70$08e009d9@misho> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001501c6cde0$7da71c70$08e009d9@misho> Subject: Re: routing problem? 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, 05 Sep 2006 20:00:47 -0000 Do you have gateway_enable=YES in your /etc/rc.conf???? Look the net.inet.ip.forwarding: # sysctl net.inet.ip.forwarding Gilberto 2006/9/1, Mihail Balikov : > Hello, > > Running "route -n monitor" I see a lot of strange RTM_MISS messages : > > got message of size 96 on Fri Sep 1 19:00:54 2006 > RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > default > > #route -n get default > route to: default > destination: default > mask: default > gateway: X.X.X.X > interface: vlanXXX > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu > expire > 0 0 0 0 0 0 1500 > 0 > > #netstat -rs > routing: > 0 bad routing redirects > 0 dynamically created routes > 0 new gateways due to redirects > 4294943810 destinations found unreachable > 0 uses of a wildcard route > 0 routes not in table but not freed > > > This is happening on FreeBSD 4.11, any ideas? > > regards, > Mihail Balikov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 21:10:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3624116A4FE for ; Tue, 5 Sep 2006 21:10:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F6243D58 for ; Tue, 5 Sep 2006 21:10:09 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3587209pye for ; Tue, 05 Sep 2006 14:10:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R1uUdUhDGWJwPezGFm+JSdWjh5v3ghJsKUW3GLPWdB7TwoWrvBulJcmUNj2rYdca2saLhDqk4Y0ykQGKbGEdIzzTrHjTBby5XTlDZUCSm7xO6SJ+4dvVO/geQChTOuLxKlxXXth15Tx7UDiLVXiwi2+FiKbPsULap23Cj4izL0E= Received: by 10.35.123.10 with SMTP id a10mr13253143pyn; Tue, 05 Sep 2006 14:10:09 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Tue, 5 Sep 2006 14:10:09 -0700 (PDT) Message-ID: <2a41acea0609051410i7d968b88ocf240514ff410452@mail.gmail.com> Date: Tue, 5 Sep 2006 14:10:09 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44FDD65C.6070109@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> <20060905182313.GA85389@hub.freebsd.org> <44FDD65C.6070109@freebsd.org> Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 21:10:18 -0000 On 9/5/06, Andre Oppermann wrote: > Prafulla Deuskar wrote: > > Andre Oppermann [andre@freebsd.org] wrote: > >> Prafulla Deuskar wrote: > >>> Jack Vogel [jfvogel@gmail.com] wrote: > >>> > >>>> On 9/2/06, Andre Oppermann wrote: > >>>> > >>>> > >>>>> I can't comment on the em part but the tcp_output.c stuff looks > >>>>> very much like a straight port from NetBSD. If we take code from > >>>>> the other BSDs we have to remark this in the emails we send with > >>>>> patches and the commit message (otherwise we get accused of 'stealing > >>>>> without attribution'). > >>>> I dont know that I'd call it a straight port, rather I was working from > >>>> some > >>>> prototype code that Prafulla had working back on 4.7, but I think at that > >>>> time that he may have patterned it after NetBSD. > >>> I don't think NetBSD had TSO support in 2002 when I first did the 4.7 > >>> patch for internal testing. > >> OK, perhaps they lifted it from your patch then. They just looks awfully > >> similiar that's why I thought it came from NetBSD. > >> > > Your patch looks good and is the way to go. > > > > So after Jack confirms that your patch works with the em driver > > would you commit to to -current? > > Absolutely. :-) > > > The driver related changes can follow.. > > > > Later we also need to fix ifconfig so that user can enable/disable TSO on the interface. > > I'll do that together with the TSO code. OK, I've built and done some touch testing of this. I like it, the driver has some counters of the number of TSO bursts it does, and I think I see more per netperf test with your patch than mine. Hard to do real performance testing with all that WITNESS stuff in, but I will be making a 6.1 version of your patch to test with since I have my driver running on that anyway. If you do the ifconfig changes there will need to be a small amount of code added to em_ioctl() but it should be trivial. You want me to reissue a driver patch with changes for your code? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 21:31:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB9DC16A4E0 for ; Tue, 5 Sep 2006 21:31:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CEC43D4C for ; Tue, 5 Sep 2006 21:31:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 36190 invoked from network); 5 Sep 2006 21:16:42 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2006 21:16:42 -0000 Message-ID: <44FDECB6.2040304@freebsd.org> Date: Tue, 05 Sep 2006 23:31:34 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> <20060905182313.GA85389@hub.freebsd.org> <44FDD65C.6070109@freebsd.org> <2a41acea0609051410i7d968b88ocf240514ff410452@mail.gmail.com> In-Reply-To: <2a41acea0609051410i7d968b88ocf240514ff410452@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 21:31:35 -0000 Jack Vogel wrote: > On 9/5/06, Andre Oppermann wrote: >> Prafulla Deuskar wrote: >> > Your patch looks good and is the way to go. >> > >> > So after Jack confirms that your patch works with the em driver >> > would you commit to to -current? >> >> Absolutely. :-) >> >> > The driver related changes can follow.. >> > >> > Later we also need to fix ifconfig so that user can enable/disable >> TSO on the interface. >> >> I'll do that together with the TSO code. > > OK, I've built and done some touch testing of this. I like it, the > driver has > some counters of the number of TSO bursts it does, and I think I see more > per netperf test with your patch than mine. > > Hard to do real performance testing with all that WITNESS stuff in, but > I will be making a 6.1 version of your patch to test with since I have my > driver running on that anyway. You can disable WITNESS and INVARIANTS pretty easily in -current and get the full performance with it. > If you do the ifconfig changes there will need to be a small amount of > code added to em_ioctl() but it should be trivial. > > You want me to reissue a driver patch with changes for your code? Yes, please do so. I've got a dual-em card which I can test with myself. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 5 22:23:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7525016A4DD for ; Tue, 5 Sep 2006 22:23:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 084A343D62 for ; Tue, 5 Sep 2006 22:23:25 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3608804pye for ; Tue, 05 Sep 2006 15:23:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jbxqA+tHO/u0dhDk3EUOBsXEDcpp5NIyOeas/anRtUGyaDtOWQmeUlHHfOEU2Bl+ppZjrj68VHM9+MD5i//os1bvu6mNqkS1fFXfo+eT/1dPjVy57aOBsdgVR3SaX8++yy3RdCdjbOLnj9mn56scbJS491bGnbhl/2+NXB90ZeU= Received: by 10.35.106.15 with SMTP id i15mr13365521pym; Tue, 05 Sep 2006 15:23:25 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Tue, 5 Sep 2006 15:23:18 -0700 (PDT) Message-ID: <2a41acea0609051523w55939cdeu71ee9857f40d1294@mail.gmail.com> Date: Tue, 5 Sep 2006 15:23:18 -0700 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <44FDECB6.2040304@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_70789_13758717.1157494998466" References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> <20060905182313.GA85389@hub.freebsd.org> <44FDD65C.6070109@freebsd.org> <2a41acea0609051410i7d968b88ocf240514ff410452@mail.gmail.com> <44FDECB6.2040304@freebsd.org> Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 05 Sep 2006 22:23:30 -0000 ------=_Part_70789_13758717.1157494998466 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/5/06, Andre Oppermann wrote: > Jack Vogel wrote: > > On 9/5/06, Andre Oppermann wrote: > >> Prafulla Deuskar wrote: > >> > Your patch looks good and is the way to go. > >> > > >> > So after Jack confirms that your patch works with the em driver > >> > would you commit to to -current? > >> > >> Absolutely. :-) > >> > >> > The driver related changes can follow.. > >> > > >> > Later we also need to fix ifconfig so that user can enable/disable > >> TSO on the interface. > >> > >> I'll do that together with the TSO code. > > > > OK, I've built and done some touch testing of this. I like it, the > > driver has > > some counters of the number of TSO bursts it does, and I think I see more > > per netperf test with your patch than mine. > > > > Hard to do real performance testing with all that WITNESS stuff in, but > > I will be making a 6.1 version of your patch to test with since I have my > > driver running on that anyway. > > You can disable WITNESS and INVARIANTS pretty easily in -current and > get the full performance with it. Last time I tried that I think the kernel wouldnt build, but that was like 6 months ago, so I just kicked off a build with this stuff off, and we'll see how it looks :) > > If you do the ifconfig changes there will need to be a small amount of > > code added to em_ioctl() but it should be trivial. > > > > You want me to reissue a driver patch with changes for your code? > > Yes, please do so. I've got a dual-em card which I can test with myself. OK, attached new patch, this one even has the ioctl change so when you get the ifconfig change in it will be ready. Cheers, Jack ------=_Part_70789_13758717.1157494998466 Content-Type: text/x-patch; name="em-current-tso.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="em-current-tso.patch" X-Attachment-Id: f_err9p7yd ZGlmZiAtTmF1ciAvdXNyL3NyYy9zeXMuZGlzdC9kZXYvZW0vaWZfZW0uYyAvdXNyL3NyYy9zeXMv ZGV2L2VtL2lmX2VtLmMKLS0tIC91c3Ivc3JjL3N5cy5kaXN0L2Rldi9lbS9pZl9lbS5jCUZyaSBB dWcgIDQgMDA6NTY6MzMgMjAwNgorKysgL3Vzci9zcmMvc3lzL2Rldi9lbS9pZl9lbS5jCVR1ZSBT ZXAgIDUgMTU6NTg6NDIgMjAwNgpAQCAtNzIsNiArNzIsOCBAQAogI2luY2x1ZGUgPG5ldGluZXQv dGNwLmg+CiAjaW5jbHVkZSA8bmV0aW5ldC91ZHAuaD4KIAorI2luY2x1ZGUgPG1hY2hpbmUvaW5f Y2tzdW0uaD4KKwogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3Bj aS9wY2lyZWcuaD4KICNpbmNsdWRlIDxkZXYvZW0vaWZfZW1faHcuaD4KQEAgLTIyOSw2ICsyMzEs MTAgQEAKIAkJICAgIHN0cnVjdCBtYnVmICopOwogc3RhdGljIHZvaWQJZW1fdHJhbnNtaXRfY2hl Y2tzdW1fc2V0dXAoc3RydWN0IGFkYXB0ZXIgKiwgc3RydWN0IG1idWYgKiwKIAkJICAgIHVpbnQz Ml90ICosIHVpbnQzMl90ICopOworI2lmZGVmIEVNX1RTTworc3RhdGljIGJvb2xlYW5fdCBlbV90 c29fc2V0dXAoc3RydWN0IGFkYXB0ZXIgKiwgc3RydWN0IG1idWYgKiwgdV9pbnQzMl90ICosCisg ICAgICAgICAgICAgICAgICAgIHVpbnQzMl90ICopOworI2VuZGlmCiBzdGF0aWMgdm9pZAllbV9z ZXRfcHJvbWlzYyhzdHJ1Y3QgYWRhcHRlciAqKTsKIHN0YXRpYyB2b2lkCWVtX2Rpc2FibGVfcHJv bWlzYyhzdHJ1Y3QgYWRhcHRlciAqKTsKIHN0YXRpYyB2b2lkCWVtX3NldF9tdWx0aShzdHJ1Y3Qg YWRhcHRlciAqKTsKQEAgLTMwMiw2ICszMDgsNyBAQAogCiAjZGVmaW5lIEUxMDAwX1RJQ0tTX1RP X1VTRUNTKHRpY2tzKQkoKDEwMjQgKiAodGlja3MpICsgNTAwKSAvIDEwMDApCiAjZGVmaW5lIEUx MDAwX1VTRUNTX1RPX1RJQ0tTKHVzZWNzKQkoKDEwMDAgKiAodXNlY3MpICsgNTEyKSAvIDEwMjQp CisjZGVmaW5lIE1fVFNPX0xFTgkJCTY2CiAKIHN0YXRpYyBpbnQgZW1fdHhfaW50X2RlbGF5X2Rm bHQgPSBFMTAwMF9USUNLU19UT19VU0VDUyhFTV9USURWKTsKIHN0YXRpYyBpbnQgZW1fcnhfaW50 X2RlbGF5X2RmbHQgPSBFMTAwMF9USUNLU19UT19VU0VDUyhFTV9SRFRSKTsKQEAgLTkwNSw2ICs5 MTIsMTAgQEAKIAkJCWlmcC0+aWZfY2FwZW5hYmxlIF49IElGQ0FQX0hXQ1NVTTsKIAkJCXJlaW5p dCA9IDE7CiAJCX0KKwkJaWYgKG1hc2sgJiBJRkNBUF9UU08pIHsKKwkJCWlmcC0+aWZfY2FwZW5h YmxlIF49IElGQ0FQX1RTTzsKKwkJCXJlaW5pdCA9IDE7CisJCX0KIAkJaWYgKG1hc2sgJiBJRkNB UF9WTEFOX0hXVEFHR0lORykgewogCQkJaWZwLT5pZl9jYXBlbmFibGUgXj0gSUZDQVBfVkxBTl9I V1RBR0dJTkc7CiAJCQlyZWluaXQgPSAxOwpAQCAtMTA2MSwxMSArMTA3MiwxNCBAQAogCWlmcC0+ aWZfZHJ2X2ZsYWdzIHw9IElGRl9EUlZfUlVOTklORzsKIAlpZnAtPmlmX2Rydl9mbGFncyAmPSB+ SUZGX0RSVl9PQUNUSVZFOwogCisJaWZwLT5pZl9od2Fzc2lzdCA9IDA7CiAJaWYgKGFkYXB0ZXIt Pmh3Lm1hY190eXBlID49IGVtXzgyNTQzKSB7CiAJCWlmIChpZnAtPmlmX2NhcGVuYWJsZSAmIElG Q0FQX1RYQ1NVTSkKIAkJCWlmcC0+aWZfaHdhc3Npc3QgPSBFTV9DSEVDS1NVTV9GRUFUVVJFUzsK LQkJZWxzZQotCQkJaWZwLT5pZl9od2Fzc2lzdCA9IDA7CisjaWZkZWYgRU1fVFNPCisJCWlmIChp ZnAtPmlmX2NhcGVuYWJsZSAmIElGQ0FQX1RTTykKKwkJCWlmcC0+aWZfaHdhc3Npc3QgfD0gRU1f VENQU0VHX0ZFQVRVUkVTOworI2VuZGlmCiAJfQogCiAJY2FsbG91dF9yZXNldCgmYWRhcHRlci0+ dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7CkBAIC0xNDE2LDExICsxNDMwLDE3 IEBACiAJc3RydWN0IG1fdGFnCQkqbXRhZzsKIAl1aW50MzJfdAkJdHhkX3VwcGVyLCB0eGRfbG93 ZXIsIHR4ZF91c2VkLCB0eGRfc2F2ZWQ7CiAJaW50CQkJbnNlZ3MsIGksIGo7Ci0JaW50CQkJZXJy b3I7CisJaW50CQkJZXJyb3IsIGRvX3RzbywgdHNvX2Rlc2MgPSAwOwogCiAJbV9oZWFkID0gKm1f aGVhZHA7CiAJY3VycmVudF90eF9kZXNjID0gTlVMTDsKLQl0eGRfdXNlZCA9IHR4ZF9zYXZlZCA9 IDA7CisJdHhkX3VwcGVyID0gdHhkX2xvd2VyID0gdHhkX3VzZWQgPSB0eGRfc2F2ZWQgPSAwOwor CisjaWZkZWYgRU1fVFNPCisgICAgICAgIGRvX3RzbyA9ICgobV9oZWFkLT5tX3BrdGhkci5jc3Vt X2ZsYWdzICYgQ1NVTV9UU08pICE9IDApOworI2Vsc2UKKyAgICAgICAgZG9fdHNvID0gMDsKKyNl bmRpZgogCiAJLyoKIAkgKiBGb3JjZSBhIGNsZWFudXAgaWYgbnVtYmVyIG9mIFRYIGRlc2NyaXB0 b3JzCkBAIC0xNDczLDYgKzE0OTMsMTcgQEAKIAkJKm1faGVhZHAgPSBtX2hlYWQ7CiAJfQogCisg ICAgICAgIC8qCisgICAgICAgICAqIFRTTyB3b3JrYXJvdW5kOgorICAgICAgICAgKiAgSWYgYW4g bWJ1ZiBpcyBvbmx5IGhlYWRlciB3ZSBuZWVkCisgICAgICAgICAqICAgICB0byBwdWxsIDQgYnl0 ZXMgb2YgZGF0YSBpbnRvIGl0LgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKGRvX3RzbyAmJiAo bV9oZWFkLT5tX2xlbiA8PSBNX1RTT19MRU4pKSB7CisgICAgICAgICAgICAgICAgbV9oZWFkID0g bV9wdWxsdXAobV9oZWFkLCBNX1RTT19MRU4gKyA0KTsKKyAgICAgICAgICAgICAgICBpZiAobV9o ZWFkID09IE5VTEwpCisgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gKEVOT0JVRlMpOwor ICAgICAgICB9CisKIAkvKgogCSAqIE1hcCB0aGUgcGFja2V0IGZvciBETUEuCiAJICovCkBAIC0x NDg3LDIzICsxNTE4LDQzIEBACiAJfQogCUtBU1NFUlQobnNlZ3MgIT0gMCwgKCJlbV9lbmNhcDog ZW1wdHkgcGFja2V0IikpOwogCi0JaWYgKG5zZWdzID4gYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZh aWwpIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogVFNPIEhhcmR3YXJlIHdvcmthcm91bmQsIGlm IHRoaXMgcGFja2V0IGlzIG5vdAorICAgICAgICAgKiBUU08sIGFuZCBpcyBvbmx5IGEgc2luZ2xl IGRlc2NyaXB0b3IgbG9uZywgYW5kCisgICAgICAgICAqIGl0IGZvbGxvd3MgYSBUU08gYnVyc3Qs IHRoZW4gd2UgbmVlZCB0byBhZGQgYQorICAgICAgICAgKiBzZW50aW5lbCBkZXNjcmlwdG9yIHRv IHByZXZlbnQgcHJlbWF0dXJlIHdyaXRlYmFjay4KKyAgICAgICAgICovCisgICAgICAgIGlmICgo ZG9fdHNvID09IDApICYmIChhZGFwdGVyLT50eF90c28gPT0gVFJVRSkpIHsKKyAgICAgICAgICAg ICAgICBpZiAobnNlZ3MgPT0gMSkKKyAgICAgICAgICAgICAgICAgICAgICAgIHRzb19kZXNjID0g VFJVRTsKKyAgICAgICAgICAgICAgICBhZGFwdGVyLT50eF90c28gPSBGQUxTRTsKKyAgICAgICAg fQorCisJaWYgKG5zZWdzID4gYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZhaWwgLSAyKSB7CiAJCWFk YXB0ZXItPm5vX3R4X2Rlc2NfYXZhaWwyKys7CiAJCWVycm9yID0gRU5PQlVGUzsKIAkJZ290byBl bmNhcF9mYWlsOwogCX0KIAotCWlmIChpZnAtPmlmX2h3YXNzaXN0ID4gMCkKLQkJZW1fdHJhbnNt aXRfY2hlY2tzdW1fc2V0dXAoYWRhcHRlciwgIG1faGVhZCwgJnR4ZF91cHBlciwgJnR4ZF9sb3dl cik7Ci0JZWxzZQotCQl0eGRfdXBwZXIgPSB0eGRfbG93ZXIgPSAwOworICAgICAgICAvKiBEbyBo YXJkd2FyZSBhc3Npc3RzICovCisgICAgICAgIGlmICggaWZwLT5pZl9od2Fzc2lzdCA+IDApIHsK KyNpZmRlZiBFTV9UU08KKyAgICAgICAgICAgICAgICBpZiAoZW1fdHNvX3NldHVwKGFkYXB0ZXIs IG1faGVhZCwgJnR4ZF91cHBlciwgJnR4ZF9sb3dlcikpIHsKKyAgICAgICAgICAgICAgICAgICAg ICAgIC8qIHdlIG5lZWQgdG8gbWFrZSBhIGZpbmFsIHNlbnRpbmVsIHRyYW5zbWl0IGRlc2MgKi8K KyAgICAgICAgICAgICAgICAgICAgICAgIHRzb19kZXNjID0gVFJVRTsKKyAgICAgICAgICAgICAg ICB9IGVsc2UKKyNlbmRpZgorICAgICAgICAgICAgICAgICAgICAgICAgZW1fdHJhbnNtaXRfY2hl Y2tzdW1fc2V0dXAoYWRhcHRlciwgIG1faGVhZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmdHhkX3VwcGVyLCAmdHhkX2xvd2VyKTsKKyAgICAgICAgfQogCiAJaSA9IGFkYXB0ZXItPm5l eHRfYXZhaWxfdHhfZGVzYzsKLQlpZiAoYWRhcHRlci0+cGNpeF84MjU0NCkgeworCWlmIChhZGFw dGVyLT5wY2l4XzgyNTQ0KQogCQl0eGRfc2F2ZWQgPSBpOwotCQl0eGRfdXNlZCA9IDA7Ci0JfQor CiAJZm9yIChqID0gMDsgaiA8IG5zZWdzOyBqKyspIHsKKyAgICAgICAgICAgICAgICBidXNfc2l6 ZV90IHNlZ19sZW47CisgICAgICAgICAgICAgICAgYnVzX2FkZHJfdCBzZWdfYWRkcjsKIAkJLyog SWYgYWRhcHRlciBpcyA4MjU0NCBhbmQgb24gUENJWCBidXMuICovCiAJCWlmKGFkYXB0ZXItPnBj aXhfODI1NDQpIHsKIAkJCURFU0NfQVJSQVkJZGVzY19hcnJheTsKQEAgLTE1MzcsMjYgKzE1ODgs NTcgQEAKIAkJCQl0eGRfdXNlZCsrOwogCQkJfQogCQl9IGVsc2UgewotCQkJdHhfYnVmZmVyID0g JmFkYXB0ZXItPnR4X2J1ZmZlcl9hcmVhW2ldOwotCQkJY3VycmVudF90eF9kZXNjID0gJmFkYXB0 ZXItPnR4X2Rlc2NfYmFzZVtpXTsKLQotCQkJY3VycmVudF90eF9kZXNjLT5idWZmZXJfYWRkciA9 IGh0b2xlNjQoc2Vnc1tqXS5kc19hZGRyKTsKLQkJCWN1cnJlbnRfdHhfZGVzYy0+bG93ZXIuZGF0 YSA9IGh0b2xlMzIoCi0JCQkJYWRhcHRlci0+dHhkX2NtZCB8IHR4ZF9sb3dlciB8IHNlZ3Nbal0u ZHNfbGVuKTsKLQkJCWN1cnJlbnRfdHhfZGVzYy0+dXBwZXIuZGF0YSA9IGh0b2xlMzIodHhkX3Vw cGVyKTsKLQotCQkJaWYgKCsraSA9PSBhZGFwdGVyLT5udW1fdHhfZGVzYykKLQkJCQlpID0gMDsK LQotCQkJdHhfYnVmZmVyLT5tX2hlYWQgPSBOVUxMOworICAgICAgICAgICAgICAgICAgICAgICB0 eF9idWZmZXIgPSAmYWRhcHRlci0+dHhfYnVmZmVyX2FyZWFbaV07CisgICAgICAgICAgICAgICAg ICAgICAgICBjdXJyZW50X3R4X2Rlc2MgPSAmYWRhcHRlci0+dHhfZGVzY19iYXNlW2ldOworICAg ICAgICAgICAgICAgICAgICAgICAgc2VnX2FkZHIgPSBodG9sZTY0KHNlZ3Nbal0uZHNfYWRkcik7 CisgICAgICAgICAgICAgICAgICAgICAgICBzZWdfbGVuICA9IHNlZ3Nbal0uZHNfbGVuOworICAg ICAgICAgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgICAgICAgICoqIFRTTyBX b3JrYXJvdW5kOgorICAgICAgICAgICAgICAgICAgICAgICAgKiogSWYgdGhpcyBpcyB0aGUgbGFz dCBkZXNjcmlwdG9yLCB3ZSB3YW50IHRvCisgICAgICAgICAgICAgICAgICAgICAgICAqKiBzcGxp dCBpdCBzbyB3ZSBoYXZlIGEgc21hbGwgZmluYWwgc2VudGluZWwKKyAgICAgICAgICAgICAgICAg ICAgICAgICovCisgICAgICAgICAgICAgICAgICAgICAgICBpZiAodHNvX2Rlc2MgJiYgKGogPT0g KG5zZWdzIC0xKSkgJiYgKHNlZ19sZW4gPiA4KSkgeworICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzZWdfbGVuIC09IDQ7CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGN1 cnJlbnRfdHhfZGVzYy0+YnVmZmVyX2FkZHIgPSBzZWdfYWRkcjsKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY3VycmVudF90eF9kZXNjLT5sb3dlci5kYXRhID0gaHRvbGUzMigKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRhcHRlci0+dHhkX2NtZCB8IHR4ZF9sb3dl ciB8IHNlZ19sZW4pOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50X3R4 X2Rlc2MtPnVwcGVyLmRhdGEgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aHRvbGUzMih0eGRfdXBwZXIpOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAo KytpID09IGFkYXB0ZXItPm51bV90eF9kZXNjKQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGkgPSAwOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBO b3cgbWFrZSB0aGUgc2VudGluZWwgKi8KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Kyt0eGRfdXNlZDsgLyogdXNpbmcgYW4gZXh0cmEgdHhkICovCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGN1cnJlbnRfdHhfZGVzYyA9ICZhZGFwdGVyLT50eF9kZXNjX2Jhc2VbaV07 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR4X2J1ZmZlciA9ICZhZGFwdGVyLT50 eF9idWZmZXJfYXJlYVtpXTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVu dF90eF9kZXNjLT5idWZmZXJfYWRkciA9CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzZWdfYWRkciArIHNlZ19sZW47CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGN1cnJlbnRfdHhfZGVzYy0+bG93ZXIuZGF0YSA9IGh0b2xlMzIoCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFkYXB0ZXItPnR4ZF9jbWQgfCB0eGRfbG93ZXIgfCA0KTsKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudF90eF9kZXNjLT51cHBlci5kYXRhID0K KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0b2xlMzIodHhkX3VwcGVyKTsK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCsraSA9PSBhZGFwdGVyLT5udW1f dHhfZGVzYykKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpID0gMDsK KyAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxzZSB7CisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGN1cnJlbnRfdHhfZGVzYy0+YnVmZmVyX2FkZHIgPSBzZWdfYWRkcjsKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudF90eF9kZXNjLT5sb3dlci5kYXRhID0g aHRvbGUzMigKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRhcHRlci0+dHhkX2Nt ZCB8IHR4ZF9sb3dlciB8IHNlZ19sZW4pOworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjdXJyZW50X3R4X2Rlc2MtPnVwcGVyLmRhdGEgPQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHRvbGUzMih0eGRfdXBwZXIpOworICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpZiAoKytpID09IGFkYXB0ZXItPm51bV90eF9kZXNjKQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGkgPSAwOworICAgICAgICAgICAgICAgICAgICAgICAg fQorICAgICAgICAgICAgICAgICAgICAgICAgdHhfYnVmZmVyLT5tX2hlYWQgPSBOVUxMOwogCQl9 CiAJfQogCiAJYWRhcHRlci0+bmV4dF9hdmFpbF90eF9kZXNjID0gaTsKIAlpZiAoYWRhcHRlci0+ cGNpeF84MjU0NCkKIAkJYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZhaWwgLT0gdHhkX3VzZWQ7Ci0J ZWxzZQorCWVsc2UgewogCQlhZGFwdGVyLT5udW1fdHhfZGVzY19hdmFpbCAtPSBuc2VnczsKKyAg ICAgICAgICAgICAgICBpZiAodHNvX2Rlc2MpIC8qIFRTTyB1c2VkIGFuIGV4dHJhIGZvciBzZW50 aW5lbCAqLworICAgICAgICAgICAgICAgICAgICAgICAgYWRhcHRlci0+bnVtX3R4X2Rlc2NfYXZh aWwgLT0gdHhkX3VzZWQ7CisgICAgICAgIH0KIAogCWlmIChtdGFnICE9IE5VTEwpIHsKIAkJLyog U2V0IHRoZSB2bGFuIGlkLiAqLwpAQCAtMjIyNiw2ICsyMzA4LDE1IEBACiAJCWlmcC0+aWZfY2Fw ZW5hYmxlIHw9IElGQ0FQX0hXQ1NVTSB8IElGQ0FQX1ZMQU5fSFdDU1VNOwogCX0KIAorI2lmZGVm IEVNX1RTTworICAgICAgICAvKiBFbmFibGUgVFNPIGlmIGF2YWlsYWJsZSAqLworICAgICAgICBp ZiAoKGFkYXB0ZXItPmh3Lm1hY190eXBlID4gZW1fODI1NDQpICYmCisgICAgICAgICAgICAoYWRh cHRlci0+aHcubWFjX3R5cGUgIT0gZW1fODI1NDcpKSB7CisgICAgICAgICAgICAgICAgaWZwLT5p Zl9jYXBhYmlsaXRpZXMgfD0gSUZDQVBfVFNPOworICAgICAgICAgICAgICAgIGlmcC0+aWZfY2Fw ZW5hYmxlIHw9IElGQ0FQX1RTTzsKKyAgICAgICAgfQorI2VuZGlmCisKIAkvKgogCSAqIFRlbGwg dGhlIHVwcGVyIGxheWVyKHMpIHdlIHN1cHBvcnQgbG9uZyBmcmFtZXMuCiAJICovCkBAIC0yNDM2 LDE1ICsyNTI3LDI3IEBACiBzdGF0aWMgaW50CiBlbV9zZXR1cF90cmFuc21pdF9zdHJ1Y3R1cmVz KHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKQogeworI2lmZGVmIEVNX1RTTworICAgICAgICBzdHJ1 Y3QgaWZuZXQgICAqaWZwID0gYWRhcHRlci0+aWZwOworI2VuZGlmCiAJZGV2aWNlX3QgZGV2ID0g YWRhcHRlci0+ZGV2OwogCXN0cnVjdCBlbV9idWZmZXIgKnR4X2J1ZmZlcjsKLQlidXNfc2l6ZV90 IHNpemU7CisJYnVzX3NpemVfdCBzaXplLCBzZWdzaXplOwogCWludCBlcnJvciwgaTsKIAogCS8q CiAJICogU2V0dXAgRE1BIGRlc2NyaXB0b3IgYXJlYXMuCiAJICovCi0Jc2l6ZSA9IHJvdW5kdXAy KGFkYXB0ZXItPmh3Lm1heF9mcmFtZV9zaXplLCBNQ0xCWVRFUyk7CisJc2Vnc2l6ZSA9IHNpemUg PSByb3VuZHVwMihhZGFwdGVyLT5ody5tYXhfZnJhbWVfc2l6ZSwgTUNMQllURVMpOworCisjaWZk ZWYgRU1fVFNPCisgICAgICAgIC8qIE92ZXJyaWRlcyBmb3IgVFNPIC0gd2FudCBsYXJnZSBzaXpl cyAqLworICAgICAgICBpZiAoaWZwLT5pZl9od2Fzc2lzdCAmIEVNX1RDUFNFR19GRUFUVVJFUykg eworICAgICAgICAgICAgICAgIHNpemUgPSBFTV9UU09fU0laRTsKKyAgICAgICAgICAgICAgICBz ZWdzaXplID0gUEFHRV9TSVpFOworICAgICAgICB9CisjZW5kaWYKKwogCWlmICgoZXJyb3IgPSBi dXNfZG1hX3RhZ19jcmVhdGUoTlVMTCwJCS8qIHBhcmVudCAqLwogCQkJCTEsIDAsCQkJLyogYWxp Z25tZW50LCBib3VuZHMgKi8KIAkJCQlCVVNfU1BBQ0VfTUFYQUREUiwJLyogbG93YWRkciAqLwpA QCAtMjQ1Miw3ICsyNTU1LDcgQEAKIAkJCQlOVUxMLCBOVUxMLAkJLyogZmlsdGVyLCBmaWx0ZXJh cmcgKi8KIAkJCQlzaXplLAkJCS8qIG1heHNpemUgKi8KIAkJCQlFTV9NQVhfU0NBVFRFUiwJCS8q IG5zZWdtZW50cyAqLwotCQkJCXNpemUsCQkJLyogbWF4c2Vnc2l6ZSAqLworCQkJCXNlZ3NpemUs CQkvKiBtYXhzZWdzaXplICovCiAJCQkJMCwJCQkvKiBmbGFncyAqLwogCQkJCU5VTEwsCQkvKiBs b2NrZnVuYyAqLwogCQkJCU5VTEwsCQkvKiBsb2NrYXJnICovCkBAIC0yNzEzLDYgKzI4MTYsODcg QEAKIAlhZGFwdGVyLT5uZXh0X2F2YWlsX3R4X2Rlc2MgPSBjdXJyX3R4ZDsKIH0KIAorI2lmZGVm IEVNX1RTTworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioKKyAqCisgKiAgU2V0dXAgd29yayBmb3IgaGFyZHdhcmUg c2VnbWVudGF0aW9uIG9mZmxvYWQgKFRTTykKKyAqCisgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KK3N0YXRpYyBi b29sZWFuX3QKK2VtX3Rzb19zZXR1cChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciwKKyAgICAgICAg ICAgICBzdHJ1Y3QgbWJ1ZiAqbXAsCisgICAgICAgICAgICAgdV9pbnQzMl90ICp0eGRfdXBwZXIs CisgICAgICAgICAgICAgdV9pbnQzMl90ICp0eGRfbG93ZXIpCit7CisgICAgICAgIHN0cnVjdCBl bV9jb250ZXh0X2Rlc2MgKlRYRDsKKyAgICAgICAgc3RydWN0IGVtX2J1ZmZlciAqdHhfYnVmZmVy OworICAgICAgICBzdHJ1Y3QgaXAgKmlwOworICAgICAgICBzdHJ1Y3QgdGNwaGRyICp0aDsKKyAg ICAgICAgaW50IGN1cnJfdHhkLCBoZHJfbGVuLCBpcF9obGVuLCB0Y3BfaGxlbjsKKworICAgICAg ICBpZiAoKChtcC0+bV9wa3RoZHIuY3N1bV9mbGFncyAmIENTVU1fVFNPKSA9PSAwKSB8fAorICAg ICAgICAgICAgKG1wLT5tX3BrdGhkci5sZW4gPD0gRTEwMDBfVFhfQlVGRkVSX1NJWkUpKSB7Cisg ICAgICAgICAgICAgICAgcmV0dXJuIEZBTFNFOworICAgICAgICB9CisKKyAgICAgICAgKnR4ZF9s b3dlciA9IChFMTAwMF9UWERfQ01EX0RFWFQgfAorICAgICAgICAgICAgICAgICAgICAgIEUxMDAw X1RYRF9EVFlQX0QgfAorICAgICAgICAgICAgICAgICAgICAgIEUxMDAwX1RYRF9DTURfVFNFKTsK KworICAgICAgICAqdHhkX3VwcGVyID0gKEUxMDAwX1RYRF9QT1BUU19JWFNNIHwKKyAgICAgICAg ICAgICAgICAgICAgICBFMTAwMF9UWERfUE9QVFNfVFhTTSkgPDwgODsKKworICAgICAgICBjdXJy X3R4ZCA9IGFkYXB0ZXItPm5leHRfYXZhaWxfdHhfZGVzYzsKKyAgICAgICAgdHhfYnVmZmVyID0g JmFkYXB0ZXItPnR4X2J1ZmZlcl9hcmVhW2N1cnJfdHhkXTsKKyAgICAgICAgVFhEID0gKHN0cnVj dCBlbV9jb250ZXh0X2Rlc2MgKikgJmFkYXB0ZXItPnR4X2Rlc2NfYmFzZVtjdXJyX3R4ZF07CisK KyAgICAgICAgbXAtPm1fZGF0YSArPSBzaXplb2Yoc3RydWN0IGV0aGVyX2hlYWRlcik7CisgICAg ICAgIGlwID0gbXRvZChtcCwgc3RydWN0IGlwICopOworICAgICAgICBpcC0+aXBfbGVuID0gMDsK KyAgICAgICAgaXAtPmlwX3N1bSA9IDA7CisgICAgICAgIGlwX2hsZW4gPSBpcC0+aXBfaGwgPDwg MiA7CisgICAgICAgIHRoID0gKHN0cnVjdCB0Y3BoZHIgKikoKGNhZGRyX3QpaXAgKyBpcF9obGVu KTsKKyAgICAgICAgdGNwX2hsZW4gPSB0aC0+dGhfb2ZmIDw8IDI7CisKKyAgICAgICAgaGRyX2xl biA9IEVUSEVSX0hEUl9MRU4gKyBpcF9obGVuICsgdGNwX2hsZW47CisgICAgICAgIHRoLT50aF9z dW0gPSBpbl9wc2V1ZG8oaXAtPmlwX3NyYy5zX2FkZHIsCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGlwLT5pcF9kc3Quc19hZGRyLAorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBodG9ucyhJUFBST1RPX1RDUCkpOworCisgICAgICAgIG1wLT5tX2RhdGEgLT0gc2l6ZW9m KHN0cnVjdCBldGhlcl9oZWFkZXIpOworICAgICAgICBUWEQtPmxvd2VyX3NldHVwLmlwX2ZpZWxk cy5pcGNzcyA9IEVUSEVSX0hEUl9MRU47CisgICAgICAgIFRYRC0+bG93ZXJfc2V0dXAuaXBfZmll bGRzLmlwY3NvID0KKyAgICAgICAgICAgICAgICBFVEhFUl9IRFJfTEVOICsgb2Zmc2V0b2Yoc3Ry dWN0IGlwLCBpcF9zdW0pOworICAgICAgICBUWEQtPmxvd2VyX3NldHVwLmlwX2ZpZWxkcy5pcGNz ZSA9CisgICAgICAgICAgICAgICAgaHRvbGUxNihFVEhFUl9IRFJfTEVOICsgaXBfaGxlbiAtIDEp OworCisgICAgICAgIFRYRC0+dXBwZXJfc2V0dXAudGNwX2ZpZWxkcy50dWNzcyA9CisgICAgICAg ICAgICAgICAgRVRIRVJfSERSX0xFTiArIGlwX2hsZW47CisgICAgICAgIFRYRC0+dXBwZXJfc2V0 dXAudGNwX2ZpZWxkcy50dWNzZSA9IDA7CisgICAgICAgIFRYRC0+dXBwZXJfc2V0dXAudGNwX2Zp ZWxkcy50dWNzbyA9CisgICAgICAgICAgICAgICAgRVRIRVJfSERSX0xFTiArIGlwX2hsZW4gKwor ICAgICAgICAgICAgICAgIG9mZnNldG9mKHN0cnVjdCB0Y3BoZHIsIHRoX3N1bSk7CisgICAgICAg IFRYRC0+dGNwX3NlZ19zZXR1cC5maWVsZHMubXNzID0gaHRvbGUxNihtcC0+bV9wa3RoZHIudHNv X3NlZ3N6KTsKKyAgICAgICAgVFhELT50Y3Bfc2VnX3NldHVwLmZpZWxkcy5oZHJfbGVuID0gaGRy X2xlbjsKKyAgICAgICAgVFhELT5jbWRfYW5kX2xlbmd0aCA9IGh0b2xlMzIoYWRhcHRlci0+dHhk X2NtZCB8CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUxMDAwX1RYRF9DTURfREVY VCB8CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUxMDAwX1RYRF9DTURfVFNFIHwK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRTEwMDBfVFhEX0NNRF9JUCB8IEUxMDAw X1RYRF9DTURfVENQIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG1wLT5tX3Br dGhkci5sZW4gLSAoaGRyX2xlbikpKTsKKworICAgICAgICB0eF9idWZmZXItPm1faGVhZCA9IE5V TEw7CisKKyAgICAgICAgaWYgKCsrY3Vycl90eGQgPT0gYWRhcHRlci0+bnVtX3R4X2Rlc2MpCisg ICAgICAgICAgICAgICAgY3Vycl90eGQgPSAwOworCisgICAgICAgIGFkYXB0ZXItPm51bV90eF9k ZXNjX2F2YWlsLS07CisgICAgICAgIGFkYXB0ZXItPm5leHRfYXZhaWxfdHhfZGVzYyA9IGN1cnJf dHhkOworICAgICAgICBhZGFwdGVyLT50eF90c28gPSBUUlVFOworCisgICAgICAgIHJldHVybiBU UlVFOworfQorI2VuZGlmIC8qIEVNX1RTTyAqLworCiAvKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICoKICAqICBF eGFtaW5lIGVhY2ggdHhfYnVmZmVyIGluIHRoZSB1c2VkIHF1ZXVlLiBJZiB0aGUgaGFyZHdhcmUg aXMgZG9uZQpAQCAtMzYzOSw2ICszODIzLDEyIEBACiAJICAgIChsb25nIGxvbmcpYWRhcHRlci0+ c3RhdHMuZ3ByYyk7CiAJZGV2aWNlX3ByaW50ZihkZXYsICJHb29kIFBhY2tldHMgWG10ZCA9ICVs bGRcbiIsCiAJICAgIChsb25nIGxvbmcpYWRhcHRlci0+c3RhdHMuZ3B0Yyk7CisjaWZkZWYgRU1f VFNPCisgICAgICAgIGRldmljZV9wcmludGYoZGV2LCAiVFNPIENvbnRleHRzIFhtdGQgPSAlbGxk XG4iLAorICAgICAgICAgICAgKGxvbmcgbG9uZylhZGFwdGVyLT5zdGF0cy50c2N0Yyk7CisgICAg ICAgIGRldmljZV9wcmludGYoZGV2LCAiVFNPIENvbnRleHRzIEZhaWxlZCA9ICVsbGRcbiIsCisg ICAgICAgICAgICAobG9uZyBsb25nKWFkYXB0ZXItPnN0YXRzLnRzY3RmYyk7CisjZW5kaWYKIH0K IAogc3RhdGljIGludApkaWZmIC1OYXVyIC91c3Ivc3JjL3N5cy5kaXN0L2Rldi9lbS9pZl9lbS5o IC91c3Ivc3JjL3N5cy9kZXYvZW0vaWZfZW0uaAotLS0gL3Vzci9zcmMvc3lzLmRpc3QvZGV2L2Vt L2lmX2VtLmgJVGh1IEF1ZyAgMyAxMjowNTowNCAyMDA2CisrKyAvdXNyL3NyYy9zeXMvZGV2L2Vt L2lmX2VtLmgJVHVlIFNlcCAgNSAxNDoyOToxOSAyMDA2CkBAIC0zNiw2ICszNiw5IEBACiAjaWZu ZGVmIF9FTV9IX0RFRklORURfCiAjZGVmaW5lIF9FTV9IX0RFRklORURfCiAKKy8qIFVuZGVmaW5l IHRoaXMgdG8gcmVtb3ZlIFRTTyBmcm9tIGRyaXZlciAqLworI2RlZmluZSBFTV9UU08KKwogLyog VHVuYWJsZXMgKi8KIAogLyoKQEAgLTEzOCw2ICsxNDEsMTEgQEAKICNkZWZpbmUgRU1fQ0hFQ0tT VU1fRkVBVFVSRVMgICAgICAgICAgICAoQ1NVTV9UQ1AgfCBDU1VNX1VEUCkKIAogLyoKKyAqIElu Zm9ybSB0aGUgc3RhY2sgYWJvdXQgdHJhbnNtaXQgc2VnbWVudGF0aW9uIG9mZmxvYWQgY2FwYWJp bGl0aWVzLgorICovCisjZGVmaW5lIEVNX1RDUFNFR19GRUFUVVJFUwkJQ1NVTV9UU08KKworLyoK ICAqIFRoaXMgcGFyYW1ldGVyIGNvbnRyb2xzIHRoZSBkdXJhdGlvbiBvZiB0cmFuc21pdCB3YXRj aGRvZyB0aW1lci4KICAqLwogI2RlZmluZSBFTV9UWF9USU1FT1VUICAgICAgICAgICAgICAgICAg IDUgICAgLyogc2V0IHRvIDUgc2Vjb25kcyAqLwpAQCAtMjI1LDYgKzIzMyw3IEBACiAjZGVmaW5l IEVNX1JYQlVGRkVSXzE2Mzg0ICAgICAgMTYzODQKIAogI2RlZmluZSBFTV9NQVhfU0NBVFRFUiAg ICAgICAgICAgIDY0CisjZGVmaW5lIEVNX1RTT19TSVpFCQk2NTUzNQogCiB0eXBlZGVmIGVudW0g X1hTVU1fQ09OVEVYVF9UIHsKIAlPRkZMT0FEX05PTkUsCkBAIC0zMDcsNiArMzE2LDcgQEAKICAg ICAgICAgdWludDMyX3QJCXR4ZF9jbWQ7CiAJc3RydWN0IGVtX2J1ZmZlcgkqdHhfYnVmZmVyX2Fy ZWE7CiAJYnVzX2RtYV90YWdfdAkJdHh0YWc7CQkvKiBkbWEgdGFnIGZvciB0eCAqLworCXVpbnQz Ml90CQl0eF90c287CQkvKiBsYXN0IHR4IHdhcyB0c28gKi8KIAogCS8qIAogCSAqIFJlY2VpdmUg ZGVmaW5pdGlvbnMK ------=_Part_70789_13758717.1157494998466-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 05:58:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A517416A4DA; Wed, 6 Sep 2006 05:58:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3613943D45; Wed, 6 Sep 2006 05:58:15 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GKqQN-000HHF-O2; Wed, 06 Sep 2006 08:58:11 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Thomas Herrlin In-reply-to: Your message of Tue, 05 Sep 2006 18:21:07 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Sep 2006 08:58:11 +0300 From: Danny Braniss Message-ID: Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tcp/udp performance 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, 06 Sep 2006 05:58:15 -0000 > Jack Vogel wrote: > > On 8/30/06, Danny Braniss wrote: > >> > >> ever since 6.1 I've seen fluctuations in the performance of > >> the em (Intel(R) PRO/1000 Gigabit Ethernet). > >> > >> motherboard OBN (On Board NIC) > >> ---------------- ------------------ > >> 1- Intel SE7501WV2S Intel 82546EB::2.1 > >> 2- Intel SE7320VP2D2 INTEL 82541 > >> 3- Sun Fire X4100 Server Intel(R) PRO/1000 > >> > >> test 1: writing to a NetApp filer via NFS/UDP > >> FreeBSD Linux > >> MegaBytes/sec > >> 1- Average: 18.48 32.61 > >> 2- Average: 15.69 35.72 > >> 3- Average: 16.61 29.69 > >> (interstingly, doing NFS/TCP instead of NFS/UDP shows an increase in > >> speed of > >> around 60% on FreeBSD but none on Linux) > >> > >> test2: iperf using 1 as server: > >> FreeBSD(*) Linux > >> Mbits/sec > >> 1- 926 905 (this machine was busy) > >> 2- 545 798 > >> 3- 910 912 > >> *: did a 'sysctl net.inet.tcp.sendspace=65536' > >> > >> > >> So, it seems to me something is not that good in the UDP department, but > >> I can't find what to tweek. > >> > >> Any help? > >> > >> danny > > > > Have discussed this some internally, the best idea I've heard is that > > UDP is not giving us the interrupt rate that TCP would, so we end up > > not cleaning up as often, and thus descriptors might not be as quickly > > available.. Its just speculation at this point. > If a high interrupt rate is a problem and your NIC+driver supports it, > then try enabling polling(4) aswell. This has helped me for bulk > transfers on slower boxes but i have noticed problems with ALTQ/dummynet > and other highly realtime dependent networking code. YMMV. > More info in the man 4 polling. > I think recent linux kernels/drivers have this implemented so it will > enable it dynamically on high load. However i only skimmed the documents > and i'm not a linux expert so i may be wrong on that. > /Junics as far as i know, polling only works on UP machines, besides, TCP performance is much better than UDP - which goes against basic instincts. the packets arriving at the NIC get processed - interrupt - before you can tell that they are IP/TCP/UDP, so the iterrupt latency should be the same for all. > > > > Try this: the default is only to have 256 descriptors, try going for > > the MAX > > which is 4K. > > > > Cheers, > > > > Jack From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 06:35:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 122B616A4DD for ; Wed, 6 Sep 2006 06:35:56 +0000 (UTC) (envelope-from misho@interbgc.com) Received: from mail.interbgc.com (mx02.cablebg.net [217.9.224.228]) by mx1.FreeBSD.org (Postfix) with SMTP id E94F243D46 for ; Wed, 6 Sep 2006 06:35:54 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 6860 invoked from network); 6 Sep 2006 06:35:52 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.0/8.0):. Processed in 0.613616 secs); 06 Sep 2006 06:35:52 -0000 X-Spam-Status: No, hits=0.0 required=8.0 Received: from topilapi-wlan.ddns.cablebg.net (HELO misho) (85.130.19.239) by mx02.interbgc.com with SMTP; 6 Sep 2006 06:35:51 -0000 Message-ID: <001801c6d17e$b28198c0$ef138255@misho> From: "Mihail Balikov" To: "Gilberto Villani Brito" , References: <001501c6cde0$7da71c70$08e009d9@misho> <6e6841490609051300t25a5f0admf9051099597947cb@mail.gmail.com> Date: Wed, 6 Sep 2006 09:35:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Cc: Subject: Re: routing problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2006 06:35:56 -0000 Yes, forwarding is enabled, this machine works like router ----- Original Message ----- From: "Gilberto Villani Brito" To: Sent: Tuesday, September 05, 2006 11:00 PM Subject: Re: routing problem? > Do you have gateway_enable=YES in your /etc/rc.conf???? > Look the net.inet.ip.forwarding: > # sysctl net.inet.ip.forwarding > > > Gilberto > > 2006/9/1, Mihail Balikov : > > Hello, > > > > Running "route -n monitor" I see a lot of strange RTM_MISS messages : > > > > got message of size 96 on Fri Sep 1 19:00:54 2006 > > RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, > > flags: > > locks: inits: > > sockaddrs: > > default > > > > #route -n get default > > route to: default > > destination: default > > mask: default > > gateway: X.X.X.X > > interface: vlanXXX > > flags: > > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu > > expire > > 0 0 0 0 0 0 1500 > > 0 > > > > #netstat -rs > > routing: > > 0 bad routing redirects > > 0 dynamically created routes > > 0 new gateways due to redirects > > 4294943810 destinations found unreachable > > 0 uses of a wildcard route > > 0 routes not in table but not freed > > > > > > This is happening on FreeBSD 4.11, any ideas? > > > > regards, > > Mihail Balikov > > > > _______________________________________________ > > 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" > > > __________ NOD32 1.1672 (20060721) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 07:01:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0ADF16A4E1 for ; Wed, 6 Sep 2006 07:01:49 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AEB643D53 for ; Wed, 6 Sep 2006 07:01:48 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k8671fHq029403 for ; Wed, 6 Sep 2006 09:01:46 +0200 Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id 2DDE63F17 for ; Wed, 6 Sep 2006 09:01:36 +0200 (CEST) Received: by jayce.zen.inc (Postfix, from userid 1000) id 327502E25A; Wed, 6 Sep 2006 09:01:36 +0200 (CEST) Date: Wed, 6 Sep 2006 09:01:35 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060906070135.GA1003@jayce.zen.inc> References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Where is IPSec NAT-T 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, 06 Sep 2006 07:01:50 -0000 Hi. On Mon, Sep 04, 2006 at 01:59:47PM -0400, Scott Ullrich wrote: > On 9/4/06, Bjoern A. Zeeb wrote: > >Are you sure this is a clean RELENG_6_1 with the correct patch? > >MD5 (freebsd6-natt.diff) = 5e7bb5a3203c8959928bf910d5498140 > > Yes it was a clean RELENG_6_1. > > >I compiled this on i386 and am64 just a few days ago and everything > >was fine. > > > >Perhaps contact me off-list and we'll post a summary once we found the > >problem? > > Maybe it is because I am including FAST_IPSEC? I have attempted to > build and use a NAT-T kernel on atleast 7 attempts now. Last of which > was a couple months ago. Actually, I did NOT make the FAST_IPSEC part of the patch. Here is probably the good location and the good time for a small summary of the patch's state: - The public patch (A) works for IPSEC, and should apply on both RELENG_6 and RELENG_6_1 (some minor patching issues may need to be solved by hand, but it's just some indentation changes in the source code between the two versions). - This public patch does NOT provide support for multiple peers behind the same NAT device. - I have a newer version of the patch (B), against RELENG_6_1, which provides such support for multiples peers behind the same NAT device. I was about to put it in public place when someone raised a discutable implementation choice in the way ipsec-tools and kernel exchange some datas specific to that NAT-T support (I ported it from Manu's work on NetBSD). - I guessed I would have quickly the time to look at it and to clean it up for both FreeBSD and NetBSD (and perhaps Linux), but I drastically lacked free time those last months. - Some FreeBSD developpers already had a look at the patch, and are in contact with me to include it in the kernel, but it has been reported several times for various reasons. - FAST_IPSEC support will be quite easy to do when all the other problems will be solved, and I guess Larry Baird will do it if I don't have free time for that quickly. As I reported that work several time on the last months, I guess I'll publish the actual version of the patch (B) those days, which will already solve some problems for most people, then I'll start to do the rest of the stuff (FAST_IPSEC and solve kernel/ipsec-tools commnication design). > The Kernel configuration file that I am trying to build is > http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense.6?rev=1.32 > with the added options IPSEC_NAT_T > option. > > Maybe I am overlooking something simple? FAST_IPSEC.... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 08:35:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A2516A4DD for ; Wed, 6 Sep 2006 08:35:42 +0000 (UTC) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 0E2DA43D46 for ; Wed, 6 Sep 2006 08:35:39 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 90668 invoked by uid 0); 6 Sep 2006 08:35:32 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 6 Sep 2006 08:35:32 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.6/8.13.4) with ESMTP id k868QtjN013053; Wed, 6 Sep 2006 16:26:55 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <44FE864F.9040500@alphaque.com> Date: Wed, 06 Sep 2006 16:26:55 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20060213 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> <20060905091820.A44392@maildrop.int.zabbadoz.net> In-Reply-To: <20060905091820.A44392@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andrew Sinclair Subject: Re: Request status on sk(4) for 88E8053 Yukon PCI-E GbE 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, 06 Sep 2006 08:35:42 -0000 On 09/05/06 17:19 Bjoern A. Zeeb said the following: > On Tue, 5 Sep 2006, Andrew Sinclair wrote: > >> $ pciconf -lv >> ... >> none2@pci2:0:0: class=0x020000 card=0x00011179 chip=0x436211ab >> rev=0x15 hdr=0x00 >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' >> class = network >> subclass = ethernet >> ... > This is becoming a FAQ;) Search the archives of this list for example. > Maybe start with > http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html we've got a device with the same NIC (0x432611ab). however our attempts to get it to work took two paths, both with less then stellar results: 1. attempting to force the sk(4) driver to recognize this card by commenting out the ifdef not_yet works in that the driver recognizes the card, but it then subsequently fails to work or receive/xmit packets. constant "can not stop transfer of Tx descriptor" and "can not stop transfer of Rx descriptor" messages which indicate a timeout failure on reading a register. 2. using the driver provided by the link above, and it's newer 8.12.2.3 version from the marvell website has the NIC recognized and working as a myk(4) device with one caveat: the moment IPFILTER is turned on and even with rules which permit all packets the card stops transmitting/receiving packets. this wont do for us as the primary function of the box is a firewall and we're using IPFILTER without an option of using PF or IPFW at the moment. so my current observations, limited though they may be, are that this chipset is still less than desirable on freebsd. in addition, comments in the above thread indicate issues with bus_dma and the myk(4) driver sources above. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.openmalaysiablog.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 08:38:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72F3216A4E1 for ; Wed, 6 Sep 2006 08:38:00 +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 27F6143D49 for ; Wed, 6 Sep 2006 08:37:59 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k868bhB1024099 for ; Wed, 6 Sep 2006 01:37:44 -0700 (PDT) Date: Wed, 06 Sep 2006 17:37:43 +0900 Message-ID: From: gnn@freebsd.org To: freebsd-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.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: ALpha Release 0.2 of Packet Construction Set 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, 06 Sep 2006 08:38:00 -0000 This release includes checksumming for IP and ICMP packets (based on the algorithm in RFC 792) and LengthValue fields so you can easily encode things like DNS labels and the like. About half the work was done by Clement, our SoC student working on IPv6 security issues. As always comments welcome. http://pcs.sourceforge.net I hope to start writing some actual tests now that I have the ability to handle most of the relevant packet level code. BTW The package comes with quite a bit of documentation for an alpha release, as well as demo and test scripts to play with. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 10:31:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D39816A4DD for ; Wed, 6 Sep 2006 10:31:21 +0000 (UTC) (envelope-from linux@giboia.org) Received: from nf-out-f131.google.com (nf-out-f131.google.com [64.233.182.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD90443D45 for ; Wed, 6 Sep 2006 10:31:20 +0000 (GMT) (envelope-from linux@giboia.org) Received: by nf-out-f131.google.com with SMTP id x9so137649nfb for ; Wed, 06 Sep 2006 03:31:19 -0700 (PDT) Received: by 10.90.28.12 with SMTP id b12mr354918agb; Wed, 06 Sep 2006 03:31:19 -0700 (PDT) Received: by 10.90.120.19 with HTTP; Wed, 6 Sep 2006 03:31:18 -0700 (PDT) Message-ID: <6e6841490609060331h7d337665jfaa930f0f8e60b61@mail.gmail.com> Date: Wed, 6 Sep 2006 07:31:18 -0300 From: "Gilberto Villani Brito" To: freebsd-net@freebsd.org In-Reply-To: <001801c6d17e$b28198c0$ef138255@misho> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001501c6cde0$7da71c70$08e009d9@misho> <6e6841490609051300t25a5f0admf9051099597947cb@mail.gmail.com> <001801c6d17e$b28198c0$ef138255@misho> Subject: Re: routing problem? 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, 06 Sep 2006 10:31:21 -0000 So, I don't know, but you can check your rules of firewall and if your vlan is ok. Gilberto 2006/9/6, Mihail Balikov : > Yes, forwarding is enabled, this machine works like router > > ----- Original Message ----- > From: "Gilberto Villani Brito" > To: > Sent: Tuesday, September 05, 2006 11:00 PM > Subject: Re: routing problem? > > > > Do you have gateway_enable=YES in your /etc/rc.conf???? > > Look the net.inet.ip.forwarding: > > # sysctl net.inet.ip.forwarding > > > > > > Gilberto > > > > 2006/9/1, Mihail Balikov : > > > Hello, > > > > > > Running "route -n monitor" I see a lot of strange RTM_MISS messages : > > > > > > got message of size 96 on Fri Sep 1 19:00:54 2006 > > > RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, > > > flags: > > > locks: inits: > > > sockaddrs: > > > default > > > > > > #route -n get default > > > route to: default > > > destination: default > > > mask: default > > > gateway: X.X.X.X > > > interface: vlanXXX > > > flags: > > > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu > > > expire > > > 0 0 0 0 0 0 1500 > > > 0 > > > > > > #netstat -rs > > > routing: > > > 0 bad routing redirects > > > 0 dynamically created routes > > > 0 new gateways due to redirects > > > 4294943810 destinations found unreachable > > > 0 uses of a wildcard route > > > 0 routes not in table but not freed > > > > > > > > > This is happening on FreeBSD 4.11, any ideas? > > > > > > regards, > > > Mihail Balikov > > > > > > _______________________________________________ > > > 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" > > > > > > __________ NOD32 1.1672 (20060721) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com > > > > > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 14:33:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB80416A6BE for ; Wed, 6 Sep 2006 14:33:08 +0000 (UTC) (envelope-from ericx_lists@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3541643D45 for ; Wed, 6 Sep 2006 14:33:08 +0000 (GMT) (envelope-from ericx_lists@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 52A6991577 for ; Wed, 6 Sep 2006 10:33:07 -0400 (EDT) X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n0ujtl4ClsmV for ; Wed, 6 Sep 2006 10:33:06 -0400 (EDT) Received: from [204.17.195.113] (cheesenip.vineyard.net [204.17.195.113]) by vineyard.net (Postfix) with ESMTP id DC91D9154C for ; Wed, 6 Sep 2006 10:33:06 -0400 (EDT) Message-ID: <44FEDD18.8060506@vineyard.net> Date: Wed, 06 Sep 2006 10:37:12 -0400 From: "Eric W. Bates" Organization: Vineyard.NET, Inc. User-Agent: Thunderbird 1.5.0.2 (X11/20060427) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: showing esp tunnels in routing table 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, 06 Sep 2006 14:33:11 -0000 When you establish an esp tunnel, the subnets on the remote end of the tunnel do not seem to appear in either "netstat -nr" or 'route get xxx.xxx.xxx.xxx' Is there a way to display those routes other than using setkey to dump the SPD's? Thanks for your time. From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 14:41:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F19AB16A4E1 for ; Wed, 6 Sep 2006 14:41:04 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74EF443D7E for ; Wed, 6 Sep 2006 14:40:58 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id 82D4B6340A9; Wed, 6 Sep 2006 16:40:56 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 06438-03; Wed, 6 Sep 2006 16:40:55 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id 6F00A6340B5; Wed, 6 Sep 2006 16:40:55 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 1B65278C31; Wed, 6 Sep 2006 16:40:03 +0200 (CEST) Date: Wed, 6 Sep 2006 16:40:03 +0200 From: Phil Regnauld To: "Eric W. Bates" Message-ID: <20060906144002.GI30554@catpipe.net> References: <44FEDD18.8060506@vineyard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FEDD18.8060506@vineyard.net> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net Cc: freebsd-net@freebsd.org Subject: Re: showing esp tunnels in routing table 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, 06 Sep 2006 14:41:05 -0000 Eric W. Bates (ericx_lists) writes: > When you establish an esp tunnel, the subnets on the remote end of the > tunnel do not seem to appear in either "netstat -nr" or 'route get > xxx.xxx.xxx.xxx' > > Is there a way to display those routes other than using setkey to dump > the SPD's? No, because there are no routes. The IPSec layer "hijacks" the packets and they are encapsulated before the routing table gets a chance to see them. You would have to setup transport ESP + gif/gre tunnels to see routing entries. Phil -- _ _ |_ | regnauld@catpipe.net catpipe ApS | (_(_||_ | *BSD solutions, consulting, development | | Tlf.: +45 7021 0050 http://www.catpipe.net/ | From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 14:58:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0327E16A4DA for ; Wed, 6 Sep 2006 14:58:21 +0000 (UTC) (envelope-from ericx_lists@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED0C43D53 for ; Wed, 6 Sep 2006 14:58:20 +0000 (GMT) (envelope-from ericx_lists@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 05FAD915BB; Wed, 6 Sep 2006 10:58:20 -0400 (EDT) X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mxkjnqWs50oI; Wed, 6 Sep 2006 10:58:19 -0400 (EDT) Received: from [204.17.195.113] (cheesenip.vineyard.net [204.17.195.113]) by vineyard.net (Postfix) with ESMTP id 86A729157C; Wed, 6 Sep 2006 10:58:19 -0400 (EDT) Message-ID: <44FEE301.2090008@vineyard.net> Date: Wed, 06 Sep 2006 11:02:25 -0400 From: "Eric W. Bates" Organization: Vineyard.NET, Inc. User-Agent: Thunderbird 1.5.0.2 (X11/20060427) MIME-Version: 1.0 To: Phil Regnauld References: <44FEDD18.8060506@vineyard.net> <20060906144002.GI30554@catpipe.net> In-Reply-To: <20060906144002.GI30554@catpipe.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: showing esp tunnels in routing table 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, 06 Sep 2006 14:58:21 -0000 Phil Regnauld wrote: > Eric W. Bates (ericx_lists) writes: >> When you establish an esp tunnel, the subnets on the remote end of the >> tunnel do not seem to appear in either "netstat -nr" or 'route get >> xxx.xxx.xxx.xxx' >> >> Is there a way to display those routes other than using setkey to dump >> the SPD's? > > No, because there are no routes. The IPSec layer "hijacks" the packets > and they are encapsulated before the routing table gets a chance > to see them. > > You would have to setup transport ESP + gif/gre tunnels to see routing > entries. Apparently, openbsd's implementation of netstat allows one to view ESP 'flows' (I believe that is how they refer to them) by examining the family 'encap' netstat -rnf encap We have no such equivalent? > Phil From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 15:18:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDB1716A4DA for ; Wed, 6 Sep 2006 15:18:13 +0000 (UTC) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C134B43D4C for ; Wed, 6 Sep 2006 15:18:12 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (moof.catpipe.net [195.249.214.130]) by localhost.catpipe.net (Postfix) with ESMTP id 034ED6340FD; Wed, 6 Sep 2006 17:18:12 +0200 (CEST) Received: from moof.catpipe.net ([195.249.214.130]) by localhost (moof.catpipe.net [195.249.214.130]) (amavisd-new, port 10024) with ESMTP id 11314-07; Wed, 6 Sep 2006 17:18:11 +0200 (CEST) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id 2653A6340C6; Wed, 6 Sep 2006 17:18:11 +0200 (CEST) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 0D68E78C31; Wed, 6 Sep 2006 17:17:19 +0200 (CEST) Date: Wed, 6 Sep 2006 17:17:19 +0200 From: Phil Regnauld To: "Eric W. Bates" Message-ID: <20060906151718.GL30554@catpipe.net> References: <44FEDD18.8060506@vineyard.net> <20060906144002.GI30554@catpipe.net> <44FEE301.2090008@vineyard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FEE301.2090008@vineyard.net> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at catpipe.net Cc: freebsd-net@freebsd.org Subject: Re: showing esp tunnels in routing table 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, 06 Sep 2006 15:18:14 -0000 Eric W. Bates (ericx_lists) writes: > > Apparently, openbsd's implementation of netstat allows one to view ESP > 'flows' (I believe that is how they refer to them) by examining the > family 'encap' > > netstat -rnf encap > > We have no such equivalent? There are patches for allowing to listen on "enc" devices -- search the archives for this list, from about 1.5 years to now, this topic has popped up quite a few times. Don't know about the "routes" stuff though. From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 15:26:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6E4E16A5D9 for ; Wed, 6 Sep 2006 15:26:53 +0000 (UTC) (envelope-from nikolas.britton@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64CDC43D70 for ; Wed, 6 Sep 2006 15:26:40 +0000 (GMT) (envelope-from nikolas.britton@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2683473wxd for ; Wed, 06 Sep 2006 08:26:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MS8+68oMZUuXGi5f0+wKMPg13oZ4b0A3uphy3JvVXbt4SmHGxG/bOlReOY+Htg6YBfPTymN6kFAAFpcOS6NQgRgEA/Z7vjtAAo165P/Py2DO0XHtH7nIyIkwc9hMXi0Rl8RXtCI8hZ4r54Pmy7YDkjJaNery8fnsLFT/sPb7pSk= Received: by 10.70.34.3 with SMTP id h3mr9989437wxh; Wed, 06 Sep 2006 08:26:39 -0700 (PDT) Received: by 10.70.49.3 with HTTP; Wed, 6 Sep 2006 08:26:37 -0700 (PDT) Message-ID: Date: Wed, 6 Sep 2006 10:26:38 -0500 From: "Nikolas Britton" To: "Dinesh Nair" In-Reply-To: <44FE864F.9040500@alphaque.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> <20060905091820.A44392@maildrop.int.zabbadoz.net> <44FE864F.9040500@alphaque.com> Cc: "Bjoern A. Zeeb" , Andrew Sinclair , freebsd-net@freebsd.org Subject: Re: Request status on sk(4) for 88E8053 Yukon PCI-E GbE 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, 06 Sep 2006 15:26:53 -0000 On 9/6/06, Dinesh Nair wrote: > > > On 09/05/06 17:19 Bjoern A. Zeeb said the following: > > On Tue, 5 Sep 2006, Andrew Sinclair wrote: > > > >> $ pciconf -lv > >> ... > >> none2@pci2:0:0: class=0x020000 card=0x00011179 chip=0x436211ab > >> rev=0x15 hdr=0x00 > >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > >> device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' > >> class = network > >> subclass = ethernet > >> ... > > This is becoming a FAQ;) Search the archives of this list for example. > > Maybe start with > > http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html > > we've got a device with the same NIC (0x432611ab). however our attempts to > get it to work took two paths, both with less then stellar results: > > 1. attempting to force the sk(4) driver to recognize this card by > commenting out the ifdef not_yet works in that the driver recognizes the > card, but it then subsequently fails to work or receive/xmit packets. > constant "can not stop transfer of Tx descriptor" and "can not stop > transfer of Rx descriptor" messages which indicate a timeout failure on > reading a register. > > 2. using the driver provided by the link above, and it's newer 8.12.2.3 > version from the marvell website has the NIC recognized and working as a > myk(4) device with one caveat: the moment IPFILTER is turned on and even > with rules which permit all packets the card stops transmitting/receiving > packets. this wont do for us as the primary function of the box is a > firewall and we're using IPFILTER without an option of using PF or IPFW at > the moment. > I've had similar happen with this driver. If you change the net.inet.tcp.sendspace and net.inet.tcp.recvspace sysctls the card will do the same thing. My solution was to buy a new motherboard with Intel 82563EB connections. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 15:56:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D2BB16A506 for ; Wed, 6 Sep 2006 15:56:57 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02AE943D7F for ; Wed, 6 Sep 2006 15:56:50 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k86Fuf7n066605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Sep 2006 08:56:43 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44FEEFB9.2060408@errno.com> Date: Wed, 06 Sep 2006 08:56:41 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: "Eric W. Bates" References: <44FEDD18.8060506@vineyard.net> <20060906144002.GI30554@catpipe.net> <44FEE301.2090008@vineyard.net> In-Reply-To: <44FEE301.2090008@vineyard.net> 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: showing esp tunnels in routing table 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, 06 Sep 2006 15:56:57 -0000 Eric W. Bates wrote: > > Phil Regnauld wrote: >> Eric W. Bates (ericx_lists) writes: >>> When you establish an esp tunnel, the subnets on the remote end of the >>> tunnel do not seem to appear in either "netstat -nr" or 'route get >>> xxx.xxx.xxx.xxx' >>> >>> Is there a way to display those routes other than using setkey to dump >>> the SPD's? >> No, because there are no routes. The IPSec layer "hijacks" the packets >> and they are encapsulated before the routing table gets a chance >> to see them. >> >> You would have to setup transport ESP + gif/gre tunnels to see routing >> entries. > > Apparently, openbsd's implementation of netstat allows one to view ESP > 'flows' (I believe that is how they refer to them) by examining the > family 'encap' > > netstat -rnf encap > > We have no such equivalent? openbsd integrated the SAD w/ the routing table; something I've wanted to do forever. Sam From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 16:17:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B679916A4DA for ; Wed, 6 Sep 2006 16:17:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C3543D6E for ; Wed, 6 Sep 2006 16:17:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 50496 invoked from network); 6 Sep 2006 16:02:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Sep 2006 16:02:58 -0000 Message-ID: <44FEF4B4.3000807@freebsd.org> Date: Wed, 06 Sep 2006 18:17:56 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Leffler References: <44FEDD18.8060506@vineyard.net> <20060906144002.GI30554@catpipe.net> <44FEE301.2090008@vineyard.net> <44FEEFB9.2060408@errno.com> In-Reply-To: <44FEEFB9.2060408@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eric W. Bates" , freebsd-net@freebsd.org Subject: Re: showing esp tunnels in routing table 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, 06 Sep 2006 16:17:59 -0000 Sam Leffler wrote: > Eric W. Bates wrote: >> Phil Regnauld wrote: >>> Eric W. Bates (ericx_lists) writes: >>>> When you establish an esp tunnel, the subnets on the remote end of the >>>> tunnel do not seem to appear in either "netstat -nr" or 'route get >>>> xxx.xxx.xxx.xxx' >>>> >>>> Is there a way to display those routes other than using setkey to dump >>>> the SPD's? >>> No, because there are no routes. The IPSec layer "hijacks" the packets >>> and they are encapsulated before the routing table gets a chance >>> to see them. >>> >>> You would have to setup transport ESP + gif/gre tunnels to see routing >>> entries. >> Apparently, openbsd's implementation of netstat allows one to view ESP >> 'flows' (I believe that is how they refer to them) by examining the >> family 'encap' >> >> netstat -rnf encap >> >> We have no such equivalent? > > openbsd integrated the SAD w/ the routing table; something I've wanted > to do forever. Having it in a separate radix tree (aka routing table) is just fine. Integrating it with the IPv4/6 routing table is evil and would cause me some heartburn. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 16:53:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E7A116A4DE; Wed, 6 Sep 2006 16:53:13 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDEC643D4C; Wed, 6 Sep 2006 16:53:10 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k86Gr9bn066983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Sep 2006 09:53:10 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44FEFCF5.2010409@errno.com> Date: Wed, 06 Sep 2006 09:53:09 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.4 (X11/20060724) MIME-Version: 1.0 To: Andre Oppermann References: <44FEDD18.8060506@vineyard.net> <20060906144002.GI30554@catpipe.net> <44FEE301.2090008@vineyard.net> <44FEEFB9.2060408@errno.com> <44FEF4B4.3000807@freebsd.org> In-Reply-To: <44FEF4B4.3000807@freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Eric W. Bates" , freebsd-net@freebsd.org Subject: Re: showing esp tunnels in routing table 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, 06 Sep 2006 16:53:13 -0000 Andre Oppermann wrote: > Sam Leffler wrote: >> Eric W. Bates wrote: >>> Phil Regnauld wrote: >>>> Eric W. Bates (ericx_lists) writes: >>>>> When you establish an esp tunnel, the subnets on the remote end of the >>>>> tunnel do not seem to appear in either "netstat -nr" or 'route get >>>>> xxx.xxx.xxx.xxx' >>>>> >>>>> Is there a way to display those routes other than using setkey to dump >>>>> the SPD's? >>>> No, because there are no routes. The IPSec layer "hijacks" the >>>> packets >>>> and they are encapsulated before the routing table gets a chance >>>> to see them. >>>> >>>> You would have to setup transport ESP + gif/gre tunnels to see >>>> routing >>>> entries. >>> Apparently, openbsd's implementation of netstat allows one to view ESP >>> 'flows' (I believe that is how they refer to them) by examining the >>> family 'encap' >>> >>> netstat -rnf encap >>> >>> We have no such equivalent? >> >> openbsd integrated the SAD w/ the routing table; something I've wanted >> to do forever. > > Having it in a separate radix tree (aka routing table) is just fine. > Integrating it with the IPv4/6 routing table is evil and would cause > me some heartburn. > The main point is to integrate routing decisions. I've also felt the locking overhead in IPsec could be significantly reduced by flattening the data structures. I don't care how things are implemented. Sam From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 17:18:19 2006 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 [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F1FD16A4E5; Wed, 6 Sep 2006 17:18:19 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 271E443D67; Wed, 6 Sep 2006 17:18:18 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k86HIIDR014448; Wed, 6 Sep 2006 17:18:18 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k86HIHWZ014444; Wed, 6 Sep 2006 17:18:17 GMT (envelope-from andre) Date: Wed, 6 Sep 2006 17:18:17 GMT From: Andre Oppermann Message-Id: <200609061718.k86HIHWZ014444@freefall.freebsd.org> To: hsn@netmag.cz, andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Cc: Subject: Re: kern/102653: TCP stack sends infinite retries for connection in LAST_ACK state 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, 06 Sep 2006 17:18:19 -0000 Synopsis: TCP stack sends infinite retries for connection in LAST_ACK state State-Changed-From-To: open->feedback State-Changed-By: andre State-Changed-When: Wed Sep 6 17:17:10 UTC 2006 State-Changed-Why: Take over. Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Wed Sep 6 17:17:10 UTC 2006 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=102653 From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 17:23:56 2006 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 [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4376916A4DD; Wed, 6 Sep 2006 17:23:56 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CBE143D62; Wed, 6 Sep 2006 17:23:55 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k86HNtqL015602; Wed, 6 Sep 2006 17:23:55 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k86HNtYY015598; Wed, 6 Sep 2006 17:23:55 GMT (envelope-from andre) Date: Wed, 6 Sep 2006 17:23:55 GMT From: Andre Oppermann Message-Id: <200609061723.k86HNtYY015598@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org Cc: Subject: Re: kern/100172: [arp] Transfer of large file fails with host is down message 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, 06 Sep 2006 17:23:56 -0000 Synopsis: [arp] Transfer of large file fails with host is down message Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: andre Responsible-Changed-When: Wed Sep 6 17:23:25 UTC 2006 Responsible-Changed-Why: Send over to Gleb Smirnoff, he's our ARP hacker. http://www.freebsd.org/cgi/query-pr.cgi?pr=100172 From owner-freebsd-net@FreeBSD.ORG Wed Sep 6 17:26:34 2006 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 [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 545D716A4DA; Wed, 6 Sep 2006 17:26:34 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF8BE43D5D; Wed, 6 Sep 2006 17:26:27 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k86HQRQp015673; Wed, 6 Sep 2006 17:26:27 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k86HQRaL015669; Wed, 6 Sep 2006 17:26:27 GMT (envelope-from andre) Date: Wed, 6 Sep 2006 17:26:27 GMT From: Andre Oppermann Message-Id: <200609061726.k86HQRaL015669@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Cc: Subject: Re: kern/31686: Problem with the timestamp option when flag equals zero 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, 06 Sep 2006 17:26:34 -0000 Synopsis: Problem with the timestamp option when flag equals zero Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Wed Sep 6 17:25:48 UTC 2006 Responsible-Changed-Why: Take this PR into safekeeping. I was the last one touching IP options stuff. http://www.freebsd.org/cgi/query-pr.cgi?pr=31686 From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 02:56:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 811E216A4DF for ; Thu, 7 Sep 2006 02:56:51 +0000 (UTC) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (bewilderbeast.blackhelicopters.org [198.22.63.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07B6243D45 for ; Thu, 7 Sep 2006 02:56:50 +0000 (GMT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: from bewilderbeast.blackhelicopters.org (mwlucas@localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10) with ESMTP id k872unfw022175 for ; Wed, 6 Sep 2006 22:56:49 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.12.10/8.12.10/Submit) id k872umFs022174 for net@freebsd.org; Wed, 6 Sep 2006 22:56:49 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 6 Sep 2006 22:56:48 -0400 From: "Michael W. Lucas" To: net@freebsd.org Message-ID: <20060907025648.GA22003@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: (0) X-Scanned-By: MIMEDefang 2.39 Cc: Subject: problems with ng_fec 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, 07 Sep 2006 02:56:51 -0000 Hi, (asked this first on -questions, but it seems that this exceeds their wisdom...) I'm using a recent -current on amd64, and trying to use ng_fec to hopefully provide a wide-bandwidth connection with cable-level redundancy, and instead I get get errors and sporadic connectivity. I configured fec0 as such: #!/bin/sh ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em3"' ngctl msg fec0: add_iface '"em7"' ngctl msg fec0: set_mode_inet ifconfig fec0 up ifconfig fec0 inet 10.184.1.19 netmask 255.255.0.0 The Cisco 6509 I was attached to had ports configured with: switchport trunk encapsulation dot1q switchport mode trunk When I tried to ping various hosts, however, I got sporadic and intermittent connectivity to other hosts on the network. Dmesg follows after log entries. Any suggestions? Thanks, ==ml Aug 25 11:43:13 aubsr019 kernel: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Aug 25 11:48:40 aubsr019 kernel: em3: link state changed to DOWN Aug 25 11:48:42 aubsr019 kernel: em3: link state changed to UP Aug 25 11:49:48 aubsr019 kernel: em3: link state changed to DOWN Aug 25 11:49:48 aubsr019 kernel: em7: link state changed to DOWN Aug 25 11:49:49 aubsr019 kernel: fec0: port em3 in bundle is down Aug 25 11:49:49 aubsr019 kernel: fec0: port em7 in bundle is down Aug 25 11:49:50 aubsr019 kernel: em7: link state changed to UP Aug 25 11:49:50 aubsr019 kernel: em3: link state changed to UP Aug 25 11:49:50 aubsr019 kernel: fec0: port em3 in bundle is up Aug 25 11:49:50 aubsr019 kernel: fec0: port em7 in bundle is up Aug 25 11:50:40 aubsr019 kernel: em3: link state changed to DOWN Aug 25 11:50:40 aubsr019 kernel: em7: link state changed to DOWN Aug 25 11:50:41 aubsr019 kernel: fec0: port em3 in bundle is down Aug 25 11:50:41 aubsr019 kernel: fec0: port em7 in bundle is down Aug 25 11:50:42 aubsr019 kernel: em7: link state changed to UP Aug 25 11:50:42 aubsr019 kernel: em3: link state changed to UP Aug 25 11:50:42 aubsr019 kernel: fec0: port em3 in bundle is up Aug 25 11:50:42 aubsr019 kernel: fec0: port em7 in bundle is up Aug 25 11:51:12 aubsr019 kernel: arp: 10.184.0.9 is on em3 but got reply from 00:11:bb:c2:34:40 on fec0 Aug 25 11:51:15 aubsr019 last message repeated 3 times Aug 25 11:51:15 aubsr019 kernel: arp: 10.184.1.11 is on em3 but got reply from 00:04:23:c2:91:38 on fec0 Aug 25 11:51:15 aubsr019 kernel: arp: 10.184.1.11 is on em3 but got reply from 00:04:23:c2:91:38 on fec0 Aug 25 11:51:16 aubsr019 kernel: arp: 10.184.0.9 is on em3 but got reply from 00:11:bb:c2:34:40 on fec0 Aug 25 11:51:19 aubsr019 last message repeated 3 times Aug 25 11:51:30 aubsr019 kernel: arp: 10.184.1.8 is on em3 but got reply from 00:50:04:1c:be:06 on fec0 Aug 25 11:51:54 aubsr019 last message repeated 12 times Aug 25 11:52:20 aubsr019 last message repeated 2 times Aug 25 11:52:22 aubsr019 kernel: arp: 10.184.202.99 is on em3 but got reply from 00:90:f5:48:aa:65 on fec0 Aug 25 11:52:25 aubsr019 last message repeated 5 times Aug 25 11:52:29 aubsr019 kernel: arp: 10.184.1.6 is on em3 but got reply from aa:00:04:00:10:08 on fec0 Aug 25 11:52:34 aubsr019 last message repeated 5 times Copyright (c) 1992-2006 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 7.0-CURRENT #1: Wed Aug 23 12:14:08 EDT 2006 system_mwl@aubsr019.us.add:/usr/obj/usr/src/sys/LOGHOST WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 Logical CPUs per core: 2 usable memory = 2139070464 (2039 MB) avail memory = 2064818176 (1969 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xf80f0000-0xf80fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:13:72:64:cc:9d pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:13:72:64:cc:9e pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 em2: port 0xccc0-0xccff mem 0xfe1e0000-0xfe1fffff irq 106 at device 4.0 on pci9 em2: Ethernet address: 00:04:23:ce:45:d6 em3: port 0xcc80-0xccbf mem 0xfe1c0000-0xfe1dffff irq 107 at device 4.1 on pci9 em3: Ethernet address: 00:04:23:ce:45:d7 pcib10: at device 0.2 on pci8 pci10: on pcib10 em4: port 0xbcc0-0xbcff mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff irq 96 at device 2.0 on pci10 em4: Ethernet address: 00:04:23:c2:91:02 em5: port 0xbc80-0xbcbf mem 0xfdfc0000-0xfdfdffff,0xfdf40000-0xfdf7ffff irq 97 at device 2.1 on pci10 em5: Ethernet address: 00:04:23:c2:91:03 em6: port 0xbc40-0xbc7f mem 0xfdf20000-0xfdf3ffff irq 101 at device 3.0 on pci10 em6: Ethernet address: 00:04:23:ce:4c:2a em7: port 0xbc00-0xbc3f mem 0xfdf00000-0xfdf1ffff irq 102 at device 3.1 on pci10 em7: Ethernet address: 00:04:23:ce:4c:2b uhci0: port 0x9ce0-0x9cff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x9cc0-0x9cdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x9ca0-0x9cbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0xac00-0xacff mem 0xf0000000-0xf7ffffff,0xfdcf0000-0xfdcfffff irq 18 at device 13.0 on pci11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 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: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 1430400MB (2929459200 sectors) RAID 5 (optimal) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/amrd0s1a -- Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur -- Michael W. Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP & GPG -- http://www.pgpandgpg.com "The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 03:04:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2701B16A4DE for ; Thu, 7 Sep 2006 03:04:58 +0000 (UTC) (envelope-from syncman0x@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 351A643D46 for ; Thu, 7 Sep 2006 03:04:56 +0000 (GMT) (envelope-from syncman0x@gmail.com) Received: by ug-out-1314.google.com with SMTP id j40so62459ugd for ; Wed, 06 Sep 2006 20:04:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hPefjShjge/dXIrLf+YO5tb9ZBdSUPy1BO2w7fiTv0P8Er9TrAQTUYx06wMoo4wwWG2OAFMykVc5wBlYE1w6p+q+4Of9ATu1rHe5+x4Ycj1EGASqcarludrreE/qj4cBmmt/wdHj7eZRNw5D4e5k1YLvPps2c2Wkg14bkJ39PhM= Received: by 10.66.220.17 with SMTP id s17mr114807ugg; Wed, 06 Sep 2006 20:04:55 -0700 (PDT) Received: by 10.67.100.19 with HTTP; Wed, 6 Sep 2006 20:04:55 -0700 (PDT) Message-ID: <7a5fe4980609062004r699c6efl505ff9a28488ae12@mail.gmail.com> Date: Thu, 7 Sep 2006 13:04:55 +1000 From: "Andrew Sinclair" To: "Nikolas Britton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7a5fe4980609050208g716dc998l44b34360133cca46@mail.gmail.com> <20060905091820.A44392@maildrop.int.zabbadoz.net> <44FE864F.9040500@alphaque.com> Cc: Dinesh Nair , "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: Request status on sk(4) for 88E8053 Yukon PCI-E GbE 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, 07 Sep 2006 03:04:58 -0000 On 9/7/06, Nikolas Britton wrote: > On 9/6/06, Dinesh Nair wrote: > > > > > > On 09/05/06 17:19 Bjoern A. Zeeb said the following: > > > On Tue, 5 Sep 2006, Andrew Sinclair wrote: > > > > > >> $ pciconf -lv > > >> ... > > >> none2@pci2:0:0: class=0x020000 card=0x00011179 chip=0x436211ab > > >> rev=0x15 hdr=0x00 > > >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > >> device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' > > >> class = network > > >> subclass = ethernet > > >> ... > > > This is becoming a FAQ;) Search the archives of this list for example. > > > Maybe start with > > > http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html > > > > we've got a device with the same NIC (0x432611ab). however our attempts to > > get it to work took two paths, both with less then stellar results: > > > > 1. attempting to force the sk(4) driver to recognize this card by > > commenting out the ifdef not_yet works in that the driver recognizes the > > card, but it then subsequently fails to work or receive/xmit packets. > > constant "can not stop transfer of Tx descriptor" and "can not stop > > transfer of Rx descriptor" messages which indicate a timeout failure on > > reading a register. > > > > 2. using the driver provided by the link above, and it's newer 8.12.2.3 > > version from the marvell website has the NIC recognized and working as a > > myk(4) device with one caveat: the moment IPFILTER is turned on and even > > with rules which permit all packets the card stops transmitting/receiving > > packets. this wont do for us as the primary function of the box is a > > firewall and we're using IPFILTER without an option of using PF or IPFW at > > the moment. > > > > I've had similar happen with this driver. If you change the > net.inet.tcp.sendspace and net.inet.tcp.recvspace sysctls the card > will do the same thing. My solution was to buy a new motherboard with > Intel 82563EB connections. > Thank you all for the information. I intend to test this more thoroughly later today. I just can't have BSD on this system full time right now. For what its worth, a recent Ubuntu installation handles the card without a problem. E-Mail me if you would like me to provide any relevant technical details. From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 09:15:30 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC5BC16A4DA for ; Thu, 7 Sep 2006 09:15:30 +0000 (UTC) (envelope-from robert@guldan.demon.nl) Received: from post-23.mail.nl.demon.net (post-23.mail.nl.demon.net [194.159.73.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FF9B43D55 for ; Thu, 7 Sep 2006 09:15:30 +0000 (GMT) (envelope-from robert@guldan.demon.nl) Received: from guldan-dsl.demon.nl ([83.160.7.100]:56589) by post-23.mail.nl.demon.net with esmtp (Exim 4.51) id 1GLFyq-0009rd-PE; Thu, 07 Sep 2006 09:15:28 +0000 Received: from bombur.guldan.demon.nl ([192.168.201.3] helo=localhost) by guldan-dsl.demon.nl with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GLFyh-000Mnn-LY; Thu, 07 Sep 2006 11:15:27 +0200 Date: Thu, 7 Sep 2006 11:15:20 +0200 From: Robert Blacquiere To: "Michael W. Lucas" Message-ID: <20060907091520.GB87346@bombur.guldan.demon.nl> References: <20060907025648.GA22003@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907025648.GA22003@bewilderbeast.blackhelicopters.org> User-Agent: Mutt/1.4.1i X-Disclaimer: running FreeBSD X-SA-Exim-Connect-IP: 192.168.201.3 X-SA-Exim-Mail-From: robert@guldan.demon.nl X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on mail.guldan.demon.nl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.3 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on guldan-dsl.demon.nl) Cc: net@freebsd.org Subject: Re: problems with ng_fec 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, 07 Sep 2006 09:15:30 -0000 On Wed, Sep 06, 2006 at 10:56:48PM -0400, Michael W. Lucas wrote: > > Hi, > > (asked this first on -questions, but it seems that this exceeds their > wisdom...) > > I'm using a recent -current on amd64, and trying to use ng_fec to > hopefully provide a wide-bandwidth connection with cable-level > redundancy, and instead I get get errors and sporadic connectivity. > > I configured fec0 as such: > > #!/bin/sh > > ngctl mkpeer fec dummy fec > ngctl msg fec0: add_iface '"em3"' > ngctl msg fec0: add_iface '"em7"' > ngctl msg fec0: set_mode_inet > ifconfig fec0 up > ifconfig fec0 inet 10.184.1.19 netmask 255.255.0.0 > > The Cisco 6509 I was attached to had ports configured with: > > switchport trunk encapsulation dot1q > switchport mode trunk You need a port channel interface and make the switchports member of the port channel. some thing like: ! interface Port-channel1 description 2 combined interfaces to freebsd fec0 switchport ! only needed for vlan tagging... ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address interface GigabitEthernet5/1 description UPLINK #1 switchport ! needer only for vlan tagging ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address no cdp enable channel-group 1 mode on interface GigabitEthernet5/2 description UPLINK #2 switchport ! needer only for vlan tagging ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address no cdp enable channel-group 1 mode on > > When I tried to ping various hosts, however, I got sporadic and > intermittent connectivity to other hosts on the network. This is spanning tree behavour.... > > Dmesg follows after log entries. > > Any suggestions? > > Thanks, > ==ml Hopeful this will give you a head start in configuring the cisco. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 09:37:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 800E316A4DD for ; Thu, 7 Sep 2006 09:37:26 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id F408843D73 for ; Thu, 7 Sep 2006 09:37:24 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k879akpO051559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 7 Sep 2006 11:36:46 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <529C787B-47A5-431F-987F-E99767027016@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Thu, 7 Sep 2006 11:37:04 +0200 To: David Bila X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Two ISP connections with Natd 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, 07 Sep 2006 09:37:26 -0000 Am 04.09.2006 um 12:40 schrieb David Bila: > I am running freebsd as getway for my office. I Just acquired second > Internet last week. I wonder if there is a way trhough route add - > net and > ipfw I can manipulate my traffic in a such way that some traffic to a > selected network can go through one ISP while the rest goes through > the > default gateway. I am using natd and my FreeBSD box has got 3 NICs, > one for > internal network and other two for each ISP. The short answer: yes, it is possible to configure ipfw (or pf) to route some connections over ISP A and others over ISP B. If you want more specific hints, you should give us more details: how are those two ISPs connected to your FreeBSD machine? Direct IP network, PPPoE? Which connections specifically do you want routed through which ISP? Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 10:09:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF83016A4DE; Thu, 7 Sep 2006 10:09:52 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DBD443D49; Thu, 7 Sep 2006 10:09:50 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 993A733CAF; Thu, 7 Sep 2006 12:09:44 +0200 (SAST) Date: Thu, 7 Sep 2006 12:09:44 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20060907100944.GA68587@zibbi.meraka.csir.co.za> References: <20060903132214.GA40993@zibbi.meraka.csir.co.za> <20060904072313.GA83757@zibbi.meraka.csir.co.za> <7.0.1.0.2.20060904152932.024c4b78@dogwood.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060904152932.024c4b78@dogwood.com> User-Agent: Mutt/1.4.2.1i Cc: gnn@freebsd.org Subject: Re: ipv6 host routes 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, 07 Sep 2006 10:09:52 -0000 Ok, I still have no joy adding an IPv6 route. Can anybody tell me what I do wrong? What I understand from the route(8) man page is that this command should work: route add -inet6 rtr2 rtrg -interface Where rtr2 is the destination address and rtrg is my address on the interface that rtr2 is connected to. I have the following lines in my /etc/hosts file: 2001:4200:7000:15:202:6fff:fe22:9547 rtrg 2001:4200:7000:15:202:6fff:fe41:1927 rtr2 When I do the route add command the kernel prints this message: nd6_rtrequest: bad gateway value: ath0 Ifconfig of the interface looks ok to me: ifconfig ath0 ath0: flags=8843 mtu 1500 inet6 fe80::202:6fff:fe22:9547%ath0 prefixlen 64 scopeid 0x3 inet6 2001:4200:7000:15:202:6fff:fe22:9547 prefixlen 64 inet6 2001:4200:7000:15:: prefixlen 64 anycast ether 00:02:6f:22:95:47 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid koppiemesh channel 149 bssid 02:02:6f:22:95:47 authmode OPEN privacy OFF txpowmax 24 bmiss 7 burst bintval 100 After the route add, this new entry arrived in the routing table according to: netstat -rnf inet6 2001:4200:7000:15:202:6fff:fe41:1927 2001:4200:7000:15:202:6fff:fe22:9547 UHS ath0 I looked with ndp -a, but nothing was added there. Anybody got any ideas? This is the last part of getting olsrd to work properly on FreeBSD using IPv6. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 14:02:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E88316A4EB for ; Thu, 7 Sep 2006 14:02:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A2A43D4C for ; Thu, 7 Sep 2006 14:02:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 60200 invoked from network); 7 Sep 2006 13:46:52 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Sep 2006 13:46:52 -0000 Message-ID: <45002659.9050203@freebsd.org> Date: Thu, 07 Sep 2006 16:02:01 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <44F9384C.9070902@freebsd.org> <2a41acea0609021741y481a04c0r42902166eaba78d7@mail.gmail.com> <20060905162542.GA63869@hub.freebsd.org> <44FDAF08.20407@freebsd.org> <20060905182313.GA85389@hub.freebsd.org> <44FDD65C.6070109@freebsd.org> <2a41acea0609051410i7d968b88ocf240514ff410452@mail.gmail.com> <44FDECB6.2040304@freebsd.org> <2a41acea0609051523w55939cdeu71ee9857f40d1294@mail.gmail.com> In-Reply-To: <2a41acea0609051523w55939cdeu71ee9857f40d1294@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current Subject: Re: RFC: TSO patch for current 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, 07 Sep 2006 14:02:04 -0000 Jack Vogel wrote: > On 9/5/06, Andre Oppermann wrote: >> > If you do the ifconfig changes there will need to be a small amount of >> > code added to em_ioctl() but it should be trivial. >> > >> > You want me to reissue a driver patch with changes for your code? >> >> Yes, please do so. I've got a dual-em card which I can test with myself. > > OK, attached new patch, this one even has the ioctl change so when > you get the ifconfig change in it will be ready. The TSO code is committed. There has been a slight change with the ifcapabilities to differentiate between TSO for IPv4 and IPv6 which can be set independently. The pseudo-header checksum is always provided in m_pkthdr.csum_data, you don't have to compute it yourself in the driver. TSO for IPv6 is not yet functional as it is missing the in6_pseudo() function and some changes to ip6_output(). I have contacted one of our IPv6 gurus to develop the patches and get it fully functional as well. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 14:10:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B20416A4E6 for ; Thu, 7 Sep 2006 14:10:33 +0000 (UTC) (envelope-from julienabeille@yahoo.fr) Received: from web26604.mail.ukl.yahoo.com (web26604.mail.ukl.yahoo.com [217.146.176.54]) by mx1.FreeBSD.org (Postfix) with SMTP id 27D1043D4C for ; Thu, 7 Sep 2006 14:10:20 +0000 (GMT) (envelope-from julienabeille@yahoo.fr) Received: (qmail 92001 invoked by uid 60001); 7 Sep 2006 14:10:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=eGyDhNvA9WPpsAUr/Gt/iw5ROYRd3eLvV661mRzK4NzDzdNRnOXDIy12z1U4Iqz5JssztARqBDPblwubwlPp1jXH1IOTLG57poK+EzwTd3I+flrXzFJSJ95GMNJ+P1SBgqA8hgSJ1RfAFIS5dQa377VM8O/opkWIfjRm0KiJG+I= ; Message-ID: <20060907141019.91998.qmail@web26604.mail.ukl.yahoo.com> Received: from [195.37.70.39] by web26604.mail.ukl.yahoo.com via HTTP; Thu, 07 Sep 2006 14:10:19 GMT Date: Thu, 7 Sep 2006 14:10:19 +0000 (GMT) From: =?iso-8859-1?q?Julien=20Abeill=E9?= To: John Hay , freebsd-net@freebsd.org In-Reply-To: <20060907100944.GA68587@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re : ipv6 host routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?q?Julien=20Abeill=E9?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2006 14:10:33 -0000 Hi John, I use v6 hosts routes on FreeBSD 4.11. The main purpose for me is through i= pv6 in ipv6 tunnels, so it is different. I tried to install host routes as you do:=20 In your case rtr2 and rtrg seem to be on the same prefix. In this case the = prefix route is enough, but if you want to add a host route, indeed the rou= te command does not work: If i do not add a host route, but use the prefix route, the machine sending= traffic (rtrg) will make a neighbor sollicitation, then get a neighbor adv= , and add the entry in the routing table with the correct interface and the= correct gateway MAC address (rtr2 MAC address). If i add a host route, I have the same entry excepty that the gateway MAC a= ddress is my MAC address (rtrg) To solve that, I do not add a route with route, but: add the v6 address of = the destination in /etc/hosts, then: ndp -s . Then the route is correctly a= dded to the routing table. I hope it works for you and you have the MAC address of the destination but= still I find the behavior of the route command in this case strange. Best regards, Julien =20 ----- Message d'origine ---- De : John Hay =C0 : freebsd-net@freebsd.org Cc : gnn@freebsd.org Envoy=E9 le : Jeudi, 7 Septembre 2006, 12h09mn 44s Objet : Re: ipv6 host routes Ok, I still have no joy adding an IPv6 route. Can anybody tell me what I do wrong? What I understand from the route(8) man page is that this command should work: route add -inet6 rtr2 rtrg -interface Where rtr2 is the destination address and rtrg is my address on the interface that rtr2 is connected to. I have the following lines in my /etc/hosts file: 2001:4200:7000:15:202:6fff:fe22:9547 rtrg 2001:4200:7000:15:202:6fff:fe41:1927 rtr2 When I do the route add command the kernel prints this message: nd6_rtrequest: bad gateway value: ath0 Ifconfig of the interface looks ok to me:=20 ifconfig ath0 ath0: flags=3D8843 mtu 1500 inet6 fe80::202:6fff:fe22:9547%ath0 prefixlen 64 scopeid 0x3 inet6 2001:4200:7000:15:202:6fff:fe22:9547 prefixlen 64 inet6 2001:4200:7000:15:: prefixlen 64 anycast ether 00:02:6f:22:95:47 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect= ) status: associated ssid koppiemesh channel 149 bssid 02:02:6f:22:95:47 authmode OPEN privacy OFF txpowmax 24 bmiss 7 burst bintval 100 After the route add, this new entry arrived in the routing table according to: netstat -rnf inet6 2001:4200:7000:15:202:6fff:fe41:1927 2001:4200:7000:15:202:6fff:fe22:9547 U= HS ath0 I looked with ndp -a, but nothing was added there. Anybody got any ideas? This is the last part of getting olsrd to work properly on FreeBSD using IPv6. John --=20 John Hay -- John.Hay@meraka.csir.co.za / jhay@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 Thu Sep 7 15:07:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EEB716A4DA for ; Thu, 7 Sep 2006 15:07:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E24BF43D7F for ; Thu, 7 Sep 2006 15:07:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 60814 invoked from network); 7 Sep 2006 14:52:16 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Sep 2006 14:52:16 -0000 Message-ID: <450035AD.3040600@freebsd.org> Date: Thu, 07 Sep 2006 17:07:25 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yar@comp.chem.msu.su Subject: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 07 Sep 2006 15:07:34 -0000 With the recent addition of a 16bit field for TSO into the mbuf packet header we've got 16bits left over. I've reserved these bits for the ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. The change is rather mechanical. Patch available here: http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff The big advantage is that we don't have to do a UMA zalloc for very incoming vlan tagged packet. The m_pkthdr.ether_vlan field is always present and its validity depends on the M_VLANTAG flag. Testing & reviews encouraged. :-) -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 18:32:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EF1C16A4DA for ; Thu, 7 Sep 2006 18:32:38 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id A511743E35 for ; Thu, 7 Sep 2006 18:31:05 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 07 Sep 2006 11:28:21 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id k87IUtKL034481 for ; Thu, 7 Sep 2006 11:30:55 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id k87IUt5a034480 for freebsd-net@freebsd.org; Thu, 7 Sep 2006 11:30:55 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200609071830.k87IUt5a034480@ambrisko.com> To: freebsd-net@freebsd.org Date: Thu, 7 Sep 2006 11:30:55 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: patch to not route on down interfaces 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, 07 Sep 2006 18:32:38 -0000 Hi guys, We "hack" a feature to have 2 NIC's configured with the same IP and netmask. We down one and up the other to bounce between then. We also set the MAC's to be the same. This fixes a few routing problems in which the route would be tied to the down interface and not the up one :-( --- ../src/sys/net/if.c Tue Feb 14 19:37:15 2006 +++ ./sys/net/if.c Tue Sep 5 12:21:46 2006 @@ -986,7 +986,9 @@ ifa_ifwithaddr(struct sockaddr *addr) struct ifaddr *ifa; IFNET_RLOCK(); - TAILQ_FOREACH(ifp, &ifnet, if_link) + TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!ifp->if_flags & IFF_UP) + continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) continue; @@ -999,6 +1001,7 @@ ifa_ifwithaddr(struct sockaddr *addr) sa_equal(ifa->ifa_broadaddr, addr)) goto done; } + } ifa = NULL; done: IFNET_RUNLOCK(); @@ -1017,6 +1020,8 @@ ifa_ifwithdstaddr(struct sockaddr *addr) IFNET_RLOCK(); TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!ifp->if_flags & IFF_UP) + continue; if ((ifp->if_flags & IFF_POINTOPOINT) == 0) continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { @@ -1062,6 +1067,8 @@ ifa_ifwithnet(struct sockaddr *addr) */ IFNET_RLOCK(); TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!ifp->if_flags & IFF_UP) + continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { char *cp, *cp2, *cp3; --- ../src/sys/netinet/in.c Tue Jan 31 08:11:37 2006 +++ ./sys/netinet/in.c Tue Sep 5 16:09:00 2006 @@ -870,6 +871,8 @@ in_scrubprefix(target) } TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (ia->ia_ifp && !(ia->ia_ifp->if_flags & IFF_UP)) + continue; if (rtinitflags(ia)) p = ia->ia_dstaddr.sin_addr; else { Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 18:51:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1496216A5BA for ; Thu, 7 Sep 2006 18:51:31 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B8B43E5A for ; Thu, 7 Sep 2006 18:50:31 +0000 (GMT) (envelope-from kes-kes@yandex.ru) Received: from [82.207.99.31] ([82.207.99.31]:11219 "EHLO homekes" smtp-auth: "kes-kes" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2076679AbWIGSu1 (ORCPT ); Thu, 7 Sep 2006 22:50:27 +0400 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: kes-kes Date: Thu, 7 Sep 2006 21:21:12 +0300 From: KES X-Mailer: The Bat! (v3.62.12) Professional Organization: SaftTen X-Priority: 3 (Normal) Message-ID: <19710703252.20060907212112@yandex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: NEW IDEAS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KES List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2006 18:51:31 -0000 Hello, freebsd-net. What about this? Archie Cobbs wrote: >>KES wrote: >> Hello, archie. >> >> How about 'ALTQ' node? or may be 'queue' node >> for packets scheduling >> >> in--->|policy|--->out >> >> policy may be CBQ, PRIO, HFSC or HTB.... >> >> I want this: >> >> in-->HTB-->out - - - in-->PRIO-->out >Sounds neat.. ask around on freebsd-net@freebsd.org as there may >be others interested, etc. -- KES mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 19:03:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D759C16A4DE; Thu, 7 Sep 2006 19:03:54 +0000 (UTC) (envelope-from prvs=julian=39828977f@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4679943D58; Thu, 7 Sep 2006 19:03:54 +0000 (GMT) (envelope-from prvs=julian=39828977f@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 07 Sep 2006 12:03:51 -0700 Message-ID: <45006D19.4040607@elischer.org> Date: Thu, 07 Sep 2006 12:03:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <450035AD.3040600@freebsd.org> In-Reply-To: <450035AD.3040600@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, yar@comp.chem.msu.su, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 07 Sep 2006 19:03:55 -0000 Andre Oppermann wrote: > With the recent addition of a 16bit field for TSO into the mbuf packet > header we've got 16bits left over. I've reserved these bits for the > ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. > > The change is rather mechanical. Patch available here: > > http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff > > The big advantage is that we don't have to do a UMA zalloc for very > incoming > vlan tagged packet. The m_pkthdr.ether_vlan field is always present > and its > validity depends on the M_VLANTAG flag. > > Testing & reviews encouraged. :-) > You are adding these fields to the mbuf pktheader in an unconditional manner. This means that even protocols that have no need or understanding of these fields are paying the price. I understand that at this point in history 99.999% of packets are for protocols for which these make sense but I wonder if we should consider whether mbufs should have some 'protocol specific' fields. mbuf tags are one way of doing this but maybe we can work out some method of doing this that doesn't require as much overhead (no extra allocations). Possibly by making some scheme whereby tags are allocated as part of the mbuf. I would suggest that each protocol have its own mbuf allocator that does preallocations according to what the active protocols might require. just vague ideas. From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 19:20:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 245DE16A4F3; Thu, 7 Sep 2006 19:20:12 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5622543D46; Thu, 7 Sep 2006 19:20:11 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 07 Sep 2006 12:20:11 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k87JKBWA009361; Thu, 7 Sep 2006 12:20:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k87JKA6W022249; Thu, 7 Sep 2006 12:20:11 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 12:20:09 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 12:20:08 -0700 Message-ID: <450070CC.7070701@cisco.com> Date: Thu, 07 Sep 2006 15:19:40 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <44F35A65.3080605@cisco.com> <20060828224452.GK37035@funkthat.com> <44F45A2A.8030405@freebsd.org> <20060902081043.J32527@mp2.macomnet.net> <44F9386A.30804@freebsd.org> In-Reply-To: <44F9386A.30804@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2006 19:20:08.0522 (UTC) FILETIME=[A1AE8AA0:01C6D2B2] DKIM-Signature: a=rsa-sha1; q=dns; l=2177; t=1157656811; x=1158520811; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Problem=20with=20uipc_mbuf.c; X=v=3Dcisco.com=3B=20h=3DGX4otkzfuvQkPAK8JGkm7Q3VVZc=3D; b=Lv81Dz7Q6K6O+HtuRVXN0qCZf0u+XXwwhhF4mwDB5n4NZXa2h72Rb166ggVrLYS5dxeZZhuG 1zKKNgEANerCHDkmsZHLZdgoRScdqS7oNVGhRQzosW50/UcNtVlYkMF/; Authentication-Results: sj-dkim-8.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: Problem with uipc_mbuf.c 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, 07 Sep 2006 19:20:12 -0000 Andre: Without the "fix" SCTP leaks mbufs when running netpipe.. for some reason my other tests (utilites) do not do so.. but I think it has to do with the back-and-forth nature of netpipe.. it sends and then receives constantly while most of the other things I play with have a source and a sink.. Anyway.. without the fix we leak clusters like crazy on a SMP machine.. maybe not like crazy.. but at least 1 cluster per every few megabytes transfered by netpipe.. I think the fix is really quite good.. it will only affect you if you have multiple CPU's operating on the mbuf (mfree()) at the same time.. The majority case takes the first part of the if.. R Andre Oppermann wrote: > Maxim Konovalov wrote: > >> On Tue, 29 Aug 2006, 17:15+0200, Andre Oppermann wrote: >> >>> John-Mark Gurney wrote: >>> >>>> Randall Stewart wrote this message on Mon, Aug 28, 2006 at 17:04 -0400: >>>> >>>>> atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 0) { >>>> >>>> ^ >>>> >>>> This should be 1 not 0.. as apparently fetchadd_int returns the >>>> old value (at least that's what atomic(9) says), which means that >>>> if we ever race on this comparision, we won't free though we >>>> should of... >>>> >>>> if we look at refcount.h, it does: >>>> return (atomic_fetchadd_int(count, -1) == 1); >>>> >>>> which release a reference and apparently returns true if it needs to >>>> be free'd... >>>> >>>> Though the wierd part is that andre, "fixed" it to be 0 in 1.157: >>>> Fix a logic error introduced with mandatory mbuf cluster >>>> refcounting and freeing of mbufs+clusters back to the packet zone. >>> >>> Honestly I'm a bit confused myself now and have to dig up things from >>> when I did the change. However I'm certain there was a problem and the >>> commit fixed it in some way (not necessarily the correct way). Before >>> the 'fix' there were some larger leaks going on. >> >> >> So what's the conclusion? Perhaps it's worth to add an XXX comment in >> meantime. > > > Please give me until Thursday to resolve this issue. > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Sep 7 19:25:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC4D216A4DD for ; Thu, 7 Sep 2006 19:25:36 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14FC343D7F for ; Thu, 7 Sep 2006 19:25:33 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.1.43] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GLPVB0cpQ-0005k9; Thu, 07 Sep 2006 21:25:32 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org, KES Date: Thu, 7 Sep 2006 21:25:19 +0200 User-Agent: KMail/1.9.3 References: <19710703252.20060907212112@yandex.ru> In-Reply-To: <19710703252.20060907212112@yandex.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2814107.morlUgbMXX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609072125.25957.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: NEW IDEAS 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, 07 Sep 2006 19:25:36 -0000 --nextPart2814107.morlUgbMXX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ Your caps-lock is broken ] On Thursday 07 September 2006 20:21, KES wrote: > Hello, freebsd-net. > > What about this? > > Archie Cobbs wrote: > >>KES wrote: > >> Hello, archie. > >> > >> How about 'ALTQ' node? or may be 'queue' node > >> for packets scheduling > >> > >> in--->|policy|--->out > >> > >> policy may be CBQ, PRIO, HFSC or HTB.... > >> > >> I want this: > >> > >> in-->HTB-->out - - - in-->PRIO-->out > > > >Sounds neat.. ask around on freebsd-net@freebsd.org as there may > >be others interested, etc. The problem is, how do you classify your traffic for queueing? i.e. where= =20 and how do you decide whether to put a given packet into queue A or B? In the normal processing path, this happens inside the packet filters=20 (either pf or ipfw at this time). On a given "firewall" rule you can=20 decide which queue will be used for packets that match the rule (or the=20 state created by this rule). This information is later used as the=20 packet is enqueued in the ALTQ on the network interface. If you want a=20 netgraph node (I belive that is what you are talking about) to do ALTQ,=20 you need a classifier somewhere as well. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2814107.morlUgbMXX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFAHIlXyyEoT62BG0RAmA4AJ9k3KsYg/nlzWddWxuTdX29mFQ06wCfQ0xQ eWU4Kd64nYI5dUskNP6leFY= =hDHc -----END PGP SIGNATURE----- --nextPart2814107.morlUgbMXX-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 01:08:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9C4316A4E5 for ; Fri, 8 Sep 2006 01:08:46 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt3.ihug.co.nz (grunt3.ihug.co.nz [203.109.254.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FAAD43D55 for ; Fri, 8 Sep 2006 01:08:42 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt3.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GLUrE-0001Bt-00; Fri, 08 Sep 2006 13:08:36 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3C92D1CC23; Fri, 8 Sep 2006 13:08:35 +1200 (NZST) Date: Fri, 8 Sep 2006 13:08:35 +1200 From: Andrew Thompson To: Andre Oppermann Message-ID: <20060908010835.GA6334@heff.fud.org.nz> References: <450035AD.3040600@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <450035AD.3040600@freebsd.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, yar@comp.chem.msu.su, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 08 Sep 2006 01:08:46 -0000 On Thu, Sep 07, 2006 at 05:07:25PM +0200, Andre Oppermann wrote: > With the recent addition of a 16bit field for TSO into the mbuf packet > header we've got 16bits left over. I've reserved these bits for the > ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. > > The change is rather mechanical. Patch available here: > > http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff > RCS file: /home/ncvs/src/sys/netgraph/ng_vlan.c,v retrieving revision 1.3 diff -u -p -r1.3 ng_vlan.c --- netgraph/ng_vlan.c 20 Apr 2005 14:19:20 -0000 1.3 +++ netgraph/ng_vlan.c 7 Sep 2006 15:03:58 -0000 <...> - vlan = EVL_VLANOFTAG(VLAN_TAG_VALUE(mtag)); + vlan = m->m_pkthdr.ether_vlan; (void)&evl; /* XXX silence GCC */ I think this is a typeo, EVL_VLANOFTAG is still needed. I like the change and it helps out a few related projects that people are working on. Andrew From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 07:26:44 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0544416A4DA for ; Fri, 8 Sep 2006 07:26:44 +0000 (UTC) (envelope-from den@FreeBSD.org) Received: from volginfo.ru (ns.volginfo.ru [217.23.84.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 805BE43D46 for ; Fri, 8 Sep 2006 07:26:43 +0000 (GMT) (envelope-from den@FreeBSD.org) Received: from volginfo.ru (localhost.volginfo.ru [127.0.0.1]) by volginfo.ru (Postfix) with ESMTP id 181131F15 for ; Fri, 8 Sep 2006 11:26:44 +0400 (MSD) Received: from [192.168.1.32] (llp-13.vistcom.ru [217.23.84.68]) by volginfo.ru (Postfix) with ESMTP id C39D51F14 for ; Fri, 8 Sep 2006 11:26:43 +0400 (MSD) Message-ID: <45011B31.1080103@FreeBSD.org> Date: Fri, 08 Sep 2006 11:26:41 +0400 From: Denis Peplin User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: ng_ether and interface naming (bug or feature?) 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, 08 Sep 2006 07:26:44 -0000 Hello! I have found, that changing interface names from rc.conf can break ng_ether when it loaded from loader.conf or compiled into kernel. For example, when mpd is used as PPPoE server, rc.conf contain ifconfig_fxp0_name="net1" and /boot/loader.conf contain ng_ether_load="YES", the mpd logs: exec: /sbin/ifconfig net1 up Cannot send a netgraph message: net1::No such file or directory Error in creation ng_pppoe node on net1: There only two workarounds: avoid using interface naming, or loading ng_ether after renaming interfaces. Is this a bug or a feature, that just wait somebody to document it? From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 08:49:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD2D816A4E0 for ; Fri, 8 Sep 2006 08:49:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B9C43D53 for ; Fri, 8 Sep 2006 08:49:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 71335 invoked from network); 8 Sep 2006 08:34:28 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Sep 2006 08:34:28 -0000 Message-ID: <45012EAA.4010303@freebsd.org> Date: Fri, 08 Sep 2006 10:49:46 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Andrew Thompson References: <450035AD.3040600@freebsd.org> <20060908010835.GA6334@heff.fud.org.nz> In-Reply-To: <20060908010835.GA6334@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, yar@comp.chem.msu.su, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 08 Sep 2006 08:49:49 -0000 Andrew Thompson wrote: > On Thu, Sep 07, 2006 at 05:07:25PM +0200, Andre Oppermann wrote: >> With the recent addition of a 16bit field for TSO into the mbuf packet >> header we've got 16bits left over. I've reserved these bits for the >> ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. >> >> The change is rather mechanical. Patch available here: >> >> http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff >> > > RCS file: /home/ncvs/src/sys/netgraph/ng_vlan.c,v > retrieving revision 1.3 > diff -u -p -r1.3 ng_vlan.c > --- netgraph/ng_vlan.c 20 Apr 2005 14:19:20 -0000 1.3 > +++ netgraph/ng_vlan.c 7 Sep 2006 15:03:58 -0000 > > <...> > > - vlan = EVL_VLANOFTAG(VLAN_TAG_VALUE(mtag)); > + vlan = m->m_pkthdr.ether_vlan; > (void)&evl; /* XXX silence GCC */ > > I think this is a typeo, EVL_VLANOFTAG is still needed. I like the > change and it helps out a few related projects that people are working > on. Fixed. Thanks for the review! -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 09:09:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A73DD16A4DA for ; Fri, 8 Sep 2006 09:09:09 +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 0548D43D45 for ; Fri, 8 Sep 2006 09:09:08 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k8898jKb015283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Sep 2006 13:08:45 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k8898jDC015282; Fri, 8 Sep 2006 13:08:45 +0400 (MSD) (envelope-from oleg) Date: Fri, 8 Sep 2006 13:08:44 +0400 From: Oleg Bulyzhin To: Doug Ambrisko Message-ID: <20060908090844.GB14414@lath.rinet.ru> References: <200609071830.k87IUt5a034480@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609071830.k87IUt5a034480@ambrisko.com> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: patch to not route on down interfaces 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, 08 Sep 2006 09:09:09 -0000 On Thu, Sep 07, 2006 at 11:30:55AM -0700, Doug Ambrisko wrote: > Hi guys, > > We "hack" a feature to have 2 NIC's configured with the same IP and > netmask. We down one and up the other to bounce between then. We > also set the MAC's to be the same. This fixes a few routing problems > in which the route would be tied to the down interface and not the > up one :-( > > --- ../src/sys/net/if.c Tue Feb 14 19:37:15 2006 > +++ ./sys/net/if.c Tue Sep 5 12:21:46 2006 > @@ -986,7 +986,9 @@ ifa_ifwithaddr(struct sockaddr *addr) > struct ifaddr *ifa; > > IFNET_RLOCK(); > - TAILQ_FOREACH(ifp, &ifnet, if_link) > + TAILQ_FOREACH(ifp, &ifnet, if_link) { > + if (!ifp->if_flags & IFF_UP) > + continue; > TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { > if (ifa->ifa_addr->sa_family != addr->sa_family) > continue; > @@ -999,6 +1001,7 @@ ifa_ifwithaddr(struct sockaddr *addr) > sa_equal(ifa->ifa_broadaddr, addr)) > goto done; > } > + } > ifa = NULL; > done: > IFNET_RUNLOCK(); > @@ -1017,6 +1020,8 @@ ifa_ifwithdstaddr(struct sockaddr *addr) > > IFNET_RLOCK(); > TAILQ_FOREACH(ifp, &ifnet, if_link) { > + if (!ifp->if_flags & IFF_UP) > + continue; > if ((ifp->if_flags & IFF_POINTOPOINT) == 0) > continue; > TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { > @@ -1062,6 +1067,8 @@ ifa_ifwithnet(struct sockaddr *addr) > */ > IFNET_RLOCK(); > TAILQ_FOREACH(ifp, &ifnet, if_link) { > + if (!ifp->if_flags & IFF_UP) > + continue; > TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { > char *cp, *cp2, *cp3; > > --- ../src/sys/netinet/in.c Tue Jan 31 08:11:37 2006 > +++ ./sys/netinet/in.c Tue Sep 5 16:09:00 2006 > @@ -870,6 +871,8 @@ in_scrubprefix(target) > } > > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > + if (ia->ia_ifp && !(ia->ia_ifp->if_flags & IFF_UP)) > + continue; > if (rtinitflags(ia)) > p = ia->ia_dstaddr.sin_addr; > else { > > Thanks, > > Doug A. > _______________________________________________ > 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" I guess this one is wrong: > + if (!ifp->if_flags & IFF_UP) it would lead to ((!ifp->if_flags) & IFF_UP), whereas it should be: (!(ifp->if_flags & IFF_UP)) -- Oleg. From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 11:03:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CE7816A4DE; Fri, 8 Sep 2006 11:03:14 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.host-h.net [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E84643D55; Fri, 8 Sep 2006 11:03:13 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GLe8a-000In3-6a; Fri, 08 Sep 2006 13:03:08 +0200 To: Andre Oppermann From: Ian FREISLICH In-Reply-To: Message from Andre Oppermann of "Thu, 07 Sep 2006 16:02:01 +0200." <45002659.9050203@freebsd.org> X-Attribution: BOFH Date: Fri, 08 Sep 2006 13:03:08 +0200 Message-Id: Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 08 Sep 2006 11:03:14 -0000 Andre Oppermann wrote: > Jack Vogel wrote: > > On 9/5/06, Andre Oppermann wrote: > >> > If you do the ifconfig changes there will need to be a small amount of > >> > code added to em_ioctl() but it should be trivial. > >> > > >> > You want me to reissue a driver patch with changes for your code? > >> > >> Yes, please do so. I've got a dual-em card which I can test with myself. > > > > OK, attached new patch, this one even has the ioctl change so when > > you get the ifconfig change in it will be ready. > > The TSO code is committed. There has been a slight change with the > ifcapabilities to differentiate between TSO for IPv4 and IPv6 which > can be set independently. > > The pseudo-header checksum is always provided in m_pkthdr.csum_data, > you don't have to compute it yourself in the driver. > > TSO for IPv6 is not yet functional as it is missing the in6_pseudo() > functionand some changes to ip6_output(). I have contacted one of our > IPv6 gurus to develop the patches and get it fully functional as well. Since this change, I get the following output from ifconfig: em0: flags=8843 mtu 1500 options=cb ether 00:04:23:d4:74:46 media: Ethernet autoselect (1000baseTX ) status: active If I disable polling: em0: flags=8843 mtu 1500 options=8b ether 00:04:23:d4:74:46 media: Ethernet autoselect (1000baseTX ) I'm not sure if this hardware supports TSO or even if the em driver part has been committed yet. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 11:41:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D16FD16A4DE for ; Fri, 8 Sep 2006 11:41:41 +0000 (UTC) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id B661D43D7D for ; Fri, 8 Sep 2006 11:41:40 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 54998 invoked by uid 0); 8 Sep 2006 11:34:58 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 8 Sep 2006 11:34:58 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.6/8.13.4) with ESMTP id k88BTBqL000133; Fri, 8 Sep 2006 19:29:11 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <45015407.4000700@alphaque.com> Date: Fri, 08 Sep 2006 19:29:11 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20060213 MIME-Version: 1.0 To: Dima Roshin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Gigabit ethernet questions? 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, 08 Sep 2006 11:41:41 -0000 On 08/09/06 20:12 Dima Roshin said the following: > Thanks Jon, I did it on both sides, thats much better now: > > gate1# sysctl kern.polling.idle_poll=1 this however does max out your CPU, even if there're no packets on the queue. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.openmalaysiablog.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 12:37:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB2CF16A4E6 for ; Fri, 8 Sep 2006 12:37:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B54343D4C for ; Fri, 8 Sep 2006 12:37:15 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 73565 invoked from network); 8 Sep 2006 12:21:54 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Sep 2006 12:21:54 -0000 Message-ID: <450163FA.5090908@freebsd.org> Date: Fri, 08 Sep 2006 14:37:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 08 Sep 2006 12:37:17 -0000 Ian FREISLICH wrote: > Andre Oppermann wrote: > >>Jack Vogel wrote: >> >>>On 9/5/06, Andre Oppermann wrote: >>> >>>>>If you do the ifconfig changes there will need to be a small amount of >>>>>code added to em_ioctl() but it should be trivial. >>>>> >>>>>You want me to reissue a driver patch with changes for your code? >>>> >>>>Yes, please do so. I've got a dual-em card which I can test with myself. >>> >>>OK, attached new patch, this one even has the ioctl change so when >>>you get the ifconfig change in it will be ready. >> >>The TSO code is committed. There has been a slight change with the >>ifcapabilities to differentiate between TSO for IPv4 and IPv6 which >>can be set independently. >> >>The pseudo-header checksum is always provided in m_pkthdr.csum_data, >>you don't have to compute it yourself in the driver. >> >>TSO for IPv6 is not yet functional as it is missing the in6_pseudo() >>functionand some changes to ip6_output(). I have contacted one of our >>IPv6 gurus to develop the patches and get it fully functional as well. > > > Since this change, I get the following output from ifconfig: > em0: flags=8843 mtu 1500 > options=cb > ether 00:04:23:d4:74:46 > media: Ethernet autoselect (1000baseTX ) > status: active > > If I disable polling: > em0: flags=8843 mtu 1500 > options=8b > ether 00:04:23:d4:74:46 > media: Ethernet autoselect (1000baseTX ) > > I'm not sure if this hardware supports TSO or even if the em driver > part has been committed yet. This is a problem with the pintb() function in ifconfig.c which apparently can't deal with digits in the bit description text. I'm looking for a fix. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 13:30:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBC7A16A4E1 for ; Fri, 8 Sep 2006 13:30:56 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B37643D49 for ; Fri, 8 Sep 2006 13:30:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 74007 invoked from network); 8 Sep 2006 13:15:34 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Sep 2006 13:15:34 -0000 Message-ID: <4501708E.6020805@freebsd.org> Date: Fri, 08 Sep 2006 15:30:54 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 08 Sep 2006 13:30:57 -0000 Ian FREISLICH wrote: > Andre Oppermann wrote: > >>Jack Vogel wrote: >> >>>On 9/5/06, Andre Oppermann wrote: >>> >>>>>If you do the ifconfig changes there will need to be a small amount of >>>>>code added to em_ioctl() but it should be trivial. >>>>> >>>>>You want me to reissue a driver patch with changes for your code? >>>> >>>>Yes, please do so. I've got a dual-em card which I can test with myself. >>> >>>OK, attached new patch, this one even has the ioctl change so when >>>you get the ifconfig change in it will be ready. >> >>The TSO code is committed. There has been a slight change with the >>ifcapabilities to differentiate between TSO for IPv4 and IPv6 which >>can be set independently. >> >>The pseudo-header checksum is always provided in m_pkthdr.csum_data, >>you don't have to compute it yourself in the driver. >> >>TSO for IPv6 is not yet functional as it is missing the in6_pseudo() >>functionand some changes to ip6_output(). I have contacted one of our >>IPv6 gurus to develop the patches and get it fully functional as well. > > > Since this change, I get the following output from ifconfig: > em0: flags=8843 mtu 1500 > options=cb > ether 00:04:23:d4:74:46 > media: Ethernet autoselect (1000baseTX ) > status: active > > If I disable polling: > em0: flags=8843 mtu 1500 > options=8b > ether 00:04:23:d4:74:46 > media: Ethernet autoselect (1000baseTX ) > > I'm not sure if this hardware supports TSO or even if the em driver > part has been committed yet. This is fixed now. I got the octal bit position wrong in the interface capabilities description string. Sorry for the confusion. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 16:02:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC0E16A4DF; Fri, 8 Sep 2006 16:02:48 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F8CF43D53; Fri, 8 Sep 2006 16:02:48 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 08 Sep 2006 09:00:13 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id k88G2ltQ002238; Fri, 8 Sep 2006 09:02:47 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id k88G2lNZ002237; Fri, 8 Sep 2006 09:02:47 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200609081602.k88G2lNZ002237@ambrisko.com> In-Reply-To: <20060908090844.GB14414@lath.rinet.ru> To: Oleg Bulyzhin Date: Fri, 8 Sep 2006 09:02:47 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: patch to not route on down interfaces 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, 08 Sep 2006 16:02:48 -0000 Oleg Bulyzhin writes: | On Thu, Sep 07, 2006 at 11:30:55AM -0700, Doug Ambrisko wrote: | > Hi guys, | > | > We "hack" a feature to have 2 NIC's configured with the same IP and | > netmask. We down one and up the other to bounce between then. We | > also set the MAC's to be the same. This fixes a few routing problems | > in which the route would be tied to the down interface and not the | > up one :-( | | I guess this one is wrong: | > + if (!ifp->if_flags & IFF_UP) | | it would lead to ((!ifp->if_flags) & IFF_UP), whereas it should be: | (!(ifp->if_flags & IFF_UP)) Fixed it. It seems that with how things are different now versus 4.x we almost never hit the if.c part mostly just the in.c change. Here is the new one: --- ../src/sys/net/if.c Tue Feb 14 19:37:15 2006 +++ ./sys/net/if.c Tue Sep 5 12:21:46 2006 @@ -986,7 +986,9 @@ ifa_ifwithaddr(struct sockaddr *addr) struct ifaddr *ifa; IFNET_RLOCK(); - TAILQ_FOREACH(ifp, &ifnet, if_link) + TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!(ifp->if_flags & IFF_UP)) + continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) continue; @@ -999,6 +1001,7 @@ ifa_ifwithaddr(struct sockaddr *addr) sa_equal(ifa->ifa_broadaddr, addr)) goto done; } + } ifa = NULL; done: IFNET_RUNLOCK(); @@ -1017,6 +1020,8 @@ ifa_ifwithdstaddr(struct sockaddr *addr) IFNET_RLOCK(); TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!(ifp->if_flags & IFF_UP)) + continue; if ((ifp->if_flags & IFF_POINTOPOINT) == 0) continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { @@ -1062,6 +1067,8 @@ ifa_ifwithnet(struct sockaddr *addr) */ IFNET_RLOCK(); TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (!(ifp->if_flags & IFF_UP)) + continue; TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { char *cp, *cp2, *cp3; --- ../src/sys/netinet/in.c Tue Jan 31 08:11:37 2006 +++ ./sys/netinet/in.c Tue Sep 5 16:09:00 2006 @@ -870,6 +871,8 @@ in_scrubprefix(target) } TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (ia->ia_ifp && !(ia->ia_ifp->if_flags & IFF_UP)) + continue; if (rtinitflags(ia)) p = ia->ia_dstaddr.sin_addr; else { Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 16:15:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E60F16A4DD for ; Fri, 8 Sep 2006 16:15:22 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED1843D49 for ; Fri, 8 Sep 2006 16:15:19 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 853CD33CAF; Fri, 8 Sep 2006 18:15:14 +0200 (SAST) Date: Fri, 8 Sep 2006 18:15:14 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20060908161514.GA42016@zibbi.meraka.csir.co.za> References: <20060907100944.GA68587@zibbi.meraka.csir.co.za> <20060907141019.91998.qmail@web26604.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060907141019.91998.qmail@web26604.mail.ukl.yahoo.com> User-Agent: Mutt/1.4.2.1i Subject: Re: ipv6 host routes 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, 08 Sep 2006 16:15:22 -0000 Ok, I have made some progress. Again I have two machines, called rtrg, which I'm working on and rtr2, the one I want to "route" to. So my /etc/hosts have this in: 2001:4200:7000:15:202:6fff:fe22:9547 rtrg 2001:4200:7000:15:202:6fff:fe41:1927 rtr2 If I add a route (on rtrg) like this, I do not get an error while adding it: route add -inet6 rtr2 rtrg -interface -llinfo But the first time I use it, the kernel spits out this message: nd6_storelladdr: sdl_alen == 0 So I had a look and tweaked sys/netinet6/nd6.c:nd6_rtrequest() a little and now it is working. Now I won't pretend that I have my head around all the IPv6 routing/ndp intricasies, so I would really like some more eyes over this. With this and my FreeBSD/IPv6 port of olsrd I can run multiple wireless interfaces with the same IPv6 subnet and olsrd can make it all work. The diff is against RELENG_6 Index: nd6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v retrieving revision 1.48.2.13 diff -u -r1.48.2.13 nd6.c --- nd6.c 17 Jun 2006 17:58:33 -0000 1.48.2.13 +++ nd6.c 8 Sep 2006 09:16:58 -0000 @@ -1392,6 +1392,8 @@ ip6_sprintf(&llsol), error)); } } + } else if (req == RTM_ADD && SDL(gate)->sdl_alen == 0) { + ln->ln_state = ND6_LLINFO_INCOMPLETE; } break; John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 17:28:54 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 374CE16A4ED; Fri, 8 Sep 2006 17:28:54 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FA4143D46; Fri, 8 Sep 2006 17:28:53 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k88HSpMg027424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Sep 2006 21:28:52 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k88HSpvB027423; Fri, 8 Sep 2006 21:28:51 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 8 Sep 2006 21:28:51 +0400 From: Gleb Smirnoff To: Denis Peplin Message-ID: <20060908172851.GM40020@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Denis Peplin , freebsd-net@freebsd.org References: <45011B31.1080103@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45011B31.1080103@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: ng_ether and interface naming (bug or feature?) 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, 08 Sep 2006 17:28:54 -0000 On Fri, Sep 08, 2006 at 11:26:41AM +0400, Denis Peplin wrote: D> I have found, that changing interface names from rc.conf D> can break ng_ether when it loaded from loader.conf or D> compiled into kernel. D> D> For example, when mpd is used as PPPoE server, rc.conf D> contain ifconfig_fxp0_name="net1" and /boot/loader.conf D> contain ng_ether_load="YES", the mpd logs: D> D> exec: /sbin/ifconfig net1 up D> Cannot send a netgraph message: net1::No such file or directory D> Error in creation ng_pppoe node on net1: D> D> There only two workarounds: avoid using interface naming, or D> loading ng_ether after renaming interfaces. D> D> Is this a bug or a feature, that just wait somebody to document it? This is probably a bug, not a feature. We have several PRs about this. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Sep 8 22:07:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2619516A40F; Fri, 8 Sep 2006 22:07:43 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail33.syd.optusnet.com.au (mail33.syd.optusnet.com.au [211.29.132.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BDFE43D4C; Fri, 8 Sep 2006 22:07:41 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail33.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k88M7ART009581 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 9 Sep 2006 08:07:11 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k88M7ANH009793; Sat, 9 Sep 2006 08:07:10 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k88M799V009792; Sat, 9 Sep 2006 08:07:10 +1000 (EST) (envelope-from peter) Date: Sat, 9 Sep 2006 08:07:09 +1000 From: Peter Jeremy To: Andre Oppermann Message-ID: <20060908220709.GA759@turion.vk2pj.dyndns.org> References: <450035AD.3040600@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <450035AD.3040600@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org, yar@comp.chem.msu.su, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) 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, 08 Sep 2006 22:07:43 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2006-Sep-07 17:07:25 +0200, Andre Oppermann wrote: >With the recent addition of a 16bit field for TSO into the mbuf packet >header we've got 16bits left over. I've reserved these bits for the >ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. Sounds reasonable. My only comment is that there doesn't appear to be any way for bpf(4) to filter/capture VLAN information. Before hardware tagging, you could run tcpdump on the vlan parent device and filter on the VLAN tag as well as see the VLAN associated with each packet. I found this very useful for monitoring routed data as well as finding cases where packets were appearing in the wrong VLAN. With hardware tagging (with or without this patch), bpf doesn't have access to the tag information. This is a PITA. --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFAemM/opHv/APuIcRArkBAJ9852B/iR8hYOI7MadjjLF8agOe8QCggGDt yqMeEEkto8RSebNvfYMF1WA= =5Yab -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 9 00:14:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3BF816A415 for ; Sat, 9 Sep 2006 00:14:19 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BC6D43D46 for ; Sat, 9 Sep 2006 00:14:19 +0000 (GMT) (envelope-from mattjreimer@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so813337wxd for ; Fri, 08 Sep 2006 17:14:18 -0700 (PDT) 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:content-transfer-encoding:content-disposition; b=N2TP8NL/qOTNdsBXknsUqqYBm98lYtqdmH1DHZZeskp3l6s49UlwO/c9mgRzN3j4A8KOejcn5y3li0ZgnLlc6bvatmLmnpVAzJV1sYZSLLufUiKeraRY+GKHdAkQShsRADc0iJvMGyTEwPr+b/DGjJNNcDeIFtzbE8ZIfIq5DWQ= Received: by 10.90.106.18 with SMTP id e18mr1182370agc; Fri, 08 Sep 2006 17:14:18 -0700 (PDT) Received: by 10.90.25.19 with HTTP; Fri, 8 Sep 2006 17:14:18 -0700 (PDT) Message-ID: Date: Fri, 8 Sep 2006 17:14:18 -0700 From: "Matt Reimer" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Can someone take a look at PR 89061 (ipv6 autoconfigure 6to4) 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, 09 Sep 2006 00:14:19 -0000 Can someone take a look at PR 89061 (http://www.freebsd.org/cgi/query-pr.cgi?pr=89061). It contains a patch adding an /etc/rc.conf knob to autoconfigure an RFC 3068 6to4 address. Matt From owner-freebsd-net@FreeBSD.ORG Sat Sep 9 07:00:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id E69A516A412; Sat, 9 Sep 2006 07:00:15 +0000 (UTC) Date: Sat, 9 Sep 2006 07:00:15 +0000 From: Prafulla Deuskar To: Pyun YongHyeon Message-ID: <20060909070015.GA71855@hub.freebsd.org> References: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> <20060904075823.GA1210@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060904075823.GA1210@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-STABLE on an i386 Cc: freebsd-net , freebsd-current , Jack Vogel Subject: Re: RFC: TSO patch for current 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, 09 Sep 2006 07:00:16 -0000 Pyun YongHyeon [pyunyh@gmail.com] wrote: > On Fri, Sep 01, 2006 at 03:51:21PM -0700, Jack Vogel wrote: > > This is a patch for the stack and the em driver to enable TSO > > on CURRENT. Previously I had problems getting it to work, but > > this is functional. > > > > I should note that CURRENT is being a pain right now, when > > I comment out em in the config the kernel panics coming up, > > so I had to substitute this code into the tree. Rather bizarre :) > > > > I have this functionality running on a 6.1 based system, and > > our test group is already testing against that driver, so far > > things are looking good. > > > > I have designed it so the driver can continue to be built > > without support. There is also a sysctl in the stack code > > so you can set net.inet.tcp.tso_enable on or off and > > compare. > > > > I know there may be some refinements to add in, but I > > would like to get this into CURRENT as a start. > > > > Comments? > > > > It seems that 8254x also supports UDP segmentation offloading > feature. Have you tried to implement it? UDP requires IP fragmentation support in hardware - we don't support UDP offload. > According to the data sheet checksums are not accurate above 12K > frame size but I couldn't find frame size restrictions in TSO path. > What is maximum frame size supported by TSO? This is bounded by the MTU. > It seems that TSO assumes IP/TCP/UDP checksum offloading is always > enabled by hardware. What if users disable IP/TCP/UDP checksum > offloading with ifconfig(8)? TSO requires checksum offload - even if user disables checksum offload with ifconfig we will use it for TSO >What happen if users disable hardware > VLAN tag insertion with ifconfig(8)? TSO requires that VLAN tag insertion is done by hardware > It woud be even better if users can disable/enable TSO capability > for each network devices with ifconfig(8) instead of relying on > global sysctl MIB(net.inet.tcp.tso_enable). > > Btw, do you have benchmark numbers? > > > Jack > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 9 11:32:03 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08FB216A417 for ; Sat, 9 Sep 2006 11:32:03 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4458F43D60 for ; Sat, 9 Sep 2006 11:31:48 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.6/8.13.6/NinthNine) with ESMTP id k89BVlDW093359; Sat, 9 Sep 2006 20:31:48 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 9 Sep 2006 20:31:47 +0900 From: Norikatsu Shigemura To: VANHULLEBUS Yvan Message-Id: <20060909203147.219ae160.nork@FreeBSD.org> In-Reply-To: <20060906070135.GA1003@jayce.zen.inc> References: <20060905022120.19c6d62d.nork@FreeBSD.org> <20060904172700.W44392@maildrop.int.zabbadoz.net> <20060904175127.F44392@maildrop.int.zabbadoz.net> <20060906070135.GA1003@jayce.zen.inc> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__9_Sep_2006_20_31_47_+0900_LsJNF2y__AcBQXgZ" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Sat, 09 Sep 2006 20:31:48 +0900 (JST) Cc: freebsd-net@FreeBSD.org Subject: Re: Where is IPSec NAT-T 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, 09 Sep 2006 11:32:03 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__9_Sep_2006_20_31_47_+0900_LsJNF2y__AcBQXgZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 6 Sep 2006 09:01:35 +0200 VANHULLEBUS Yvan wrote: > > Yes it was a clean RELENG_6_1. > > >I compiled this on i386 and am64 just a few days ago and everything > > >was fine. > > >Perhaps contact me off-list and we'll post a summary once we found the > > >problem? > > Maybe it is because I am including FAST_IPSEC? I have attempted to > > build and use a NAT-T kernel on atleast 7 attempts now. Last of which > > was a couple months ago. > Actually, I did NOT make the FAST_IPSEC part of the patch. Hummmm.... :-) > Here is probably the good location and the good time for a small > summary of the patch's state: Oh! > - The public patch (A) works for IPSEC, and should apply on both > RELENG_6 and RELENG_6_1 (some minor patching issues may need to be > solved by hand, but it's just some indentation changes in the source > code between the two versions). > - This public patch does NOT provide support for multiple peers behind > the same NAT device. > - I have a newer version of the patch (B), against RELENG_6_1, which > provides such support for multiples peers behind the same NAT > device. I was about to put it in public place when someone raised a > discutable implementation choice in the way ipsec-tools and kernel > exchange some datas specific to that NAT-T support (I ported it from > Manu's work on NetBSD). How to get the patch(B)? I'm interesting new version of the patch. > - I guessed I would have quickly the time to look at it and to clean > it up for both FreeBSD and NetBSD (and perhaps Linux), but I > drastically lacked free time those last months. > - Some FreeBSD developpers already had a look at the patch, and are in > contact with me to include it in the kernel, but it has been > reported several times for various reasons. > - FAST_IPSEC support will be quite easy to do when all the other > problems will be solved, and I guess Larry Baird will do it if I > don't have free time for that quickly. > As I reported that work several time on the last months, I guess I'll > publish the actual version of the patch (B) those days, which will > already solve some problems for most people, then I'll start to do the > rest of the stuff (FAST_IPSEC and solve kernel/ipsec-tools > commnication design). I'm interesting FAST_IPSEC support:-). > > The Kernel configuration file that I am trying to build is > > http://pfsense.com/cgi-bin/cvsweb.cgi/tools/builder_scripts/conf/pfSense.6?rev=1.32 > > with the added options IPSEC_NAT_T > > option. > > Maybe I am overlooking something simple? > FAST_IPSEC.... ..... I made a patch for 6-stable, based on MD5 (freebsd6-natt.diff) = 5e7bb5a3203c8959928bf910d5498140. But I didn't compile, yet:-). --Multipart=_Sat__9_Sep_2006_20_31_47_+0900_LsJNF2y__AcBQXgZ Content-Type: text/plain; name="freebsd6s-natt.diff" Content-Disposition: attachment; filename="freebsd6s-natt.diff" Content-Transfer-Encoding: 7bit --- sys/conf/options.orig Sat Sep 2 22:12:08 2006 +++ sys/conf/options Sat Sep 9 19:44:12 2006 @@ -352,6 +352,7 @@ INET6 opt_inet6.h IPSEC opt_ipsec.h IPSEC_ESP opt_ipsec.h +IPSEC_NAT_T opt_ipsec.h IPSEC_DEBUG opt_ipsec.h IPSEC_FILTERGIF opt_ipsec.h FAST_IPSEC opt_ipsec.h --- sys/net/pfkeyv2.h.orig Fri Jan 7 10:45:35 2005 +++ sys/net/pfkeyv2.h Sat Sep 9 19:46:21 2006 @@ -75,7 +75,8 @@ #define SADB_X_SPDSETIDX 20 #define SADB_X_SPDEXPIRE 21 #define SADB_X_SPDDELETE2 22 /* by policy id */ -#define SADB_MAX 22 +#define SADB_X_NAT_T_NEW_MAPPING 23 +#define SADB_MAX 23 struct sadb_msg { u_int8_t sadb_msg_version; @@ -255,6 +256,25 @@ */ }; +/* NAT traversal type, see RFC 3948 */ +/* sizeof(struct sadb_x_nat_t_type) == 8 */ +struct sadb_x_nat_t_type { + u_int16_t sadb_x_nat_t_type_len; + u_int16_t sadb_x_nat_t_type_exttype; + u_int8_t sadb_x_nat_t_type_type; + u_int8_t sadb_x_nat_t_type_reserved[3]; +}; + +/* NAT traversal source or destination port */ +/* sizeof(struct sadb_x_nat_t_port) == 8 */ +struct sadb_x_nat_t_port { + u_int16_t sadb_x_nat_t_port_len; + u_int16_t sadb_x_nat_t_port_exttype; + u_int16_t sadb_x_nat_t_port_port; + u_int16_t sadb_x_nat_t_port_reserved; +}; + + #define SADB_EXT_RESERVED 0 #define SADB_EXT_SA 1 #define SADB_EXT_LIFETIME_CURRENT 2 @@ -275,7 +295,11 @@ #define SADB_X_EXT_KMPRIVATE 17 #define SADB_X_EXT_POLICY 18 #define SADB_X_EXT_SA2 19 -#define SADB_EXT_MAX 19 +#define SADB_X_EXT_NAT_T_TYPE 20 +#define SADB_X_EXT_NAT_T_SPORT 21 +#define SADB_X_EXT_NAT_T_DPORT 22 +#define SADB_X_EXT_NAT_T_OA 23 +#define SADB_EXT_MAX 23 #define SADB_SATYPE_UNSPEC 0 #define SADB_SATYPE_AH 2 --- sys/netinet/in_pcb.h.orig Mon Aug 21 04:28:43 2006 +++ sys/netinet/in_pcb.h Sat Sep 9 19:48:02 2006 @@ -298,6 +298,11 @@ #define IN6P_RFC2292 0x40000000 /* used RFC2292 API on the socket */ #define IN6P_MTU 0x80000000 /* receive path MTU */ +/* XXX should move to an UDP control block */ +#define INP_ESPINUDP 0x100 /* ESP over UDP for NAT-T */ +#define INP_ESPINUDP_NON_IKE 0x200 /* ESP over UDP for NAT-T */ +#define INP_ESPINUDP_ALL (INP_ESPINUDP|INP_ESPINUDP_NON_IKE) + #define INP_CONTROLOPTS (INP_RECVOPTS|INP_RECVRETOPTS|INP_RECVDSTADDR|\ INP_RECVIF|INP_RECVTTL|\ IN6P_PKTINFO|IN6P_HOPLIMIT|IN6P_HOPOPTS|\ --- sys/netinet/in_proto.c.orig Tue Jan 3 17:15:32 2006 +++ sys/netinet/in_proto.c Sat Sep 9 19:50:09 2006 @@ -122,7 +122,7 @@ .pr_flags = PR_ATOMIC|PR_ADDR, .pr_input = udp_input, .pr_ctlinput = udp_ctlinput, - .pr_ctloutput = ip_ctloutput, + .pr_ctloutput = udp_ctloutput, .pr_init = udp_init, .pr_usrreqs = &udp_usrreqs }, --- sys/netinet/udp.h.orig Fri Jan 7 10:45:45 2005 +++ sys/netinet/udp.h Sat Sep 9 19:56:15 2006 @@ -44,4 +44,17 @@ u_short uh_sum; /* udp checksum */ }; +/* socket options for UDP */ +#define UDP_ENCAP 100 + +/* Encapsulation types */ +#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */ +#define UDP_ENCAP_ESPINUDP 2 /* draft-ietf-ipsec-udp-encaps-02+ */ + +/* Default encapsulation port */ +#define UDP_ENCAP_ESPINUDP_PORT 500 + +/* Maximum UDP fragment size for ESP over UDP */ +#define UDP_ENCAP_ESPINUDP_MAXFRAGLEN 552 + #endif --- sys/netinet/udp_usrreq.c.orig Tue May 16 16:27:48 2006 +++ sys/netinet/udp_usrreq.c Sat Sep 9 19:52:13 2006 @@ -86,6 +86,9 @@ #include +#include +#include + /* * UDP protocol implementation. * Per RFC 768, August, 1980. @@ -128,6 +131,11 @@ static int udp_detach(struct socket *so); static int udp_output(struct inpcb *, struct mbuf *, struct sockaddr *, struct mbuf *, struct thread *); +#ifdef IPSEC +#ifdef INET +static int udp4_espinudp (struct mbuf *, int, struct sockaddr *, struct socket *); +#endif +#endif static void udp_zone_change(void *tag) @@ -464,6 +472,41 @@ return; } #endif /*IPSEC || FAST_IPSEC*/ +#ifdef IPSEC_NAT_T + /* Handle ESP over UDP */ + if (last->inp_flags & INP_ESPINUDP_ALL) { + struct sockaddr_in src; + struct sockaddr *sa = (struct sockaddr *)(&src); + size_t minlen; + + bzero(&src, sizeof(src)); + src.sin_family = AF_INET; + src.sin_len = sizeof(struct sockaddr_in); + bcopy(&ip->ip_src, &src.sin_addr, sizeof(src.sin_addr)); + src.sin_port = udp_in->sin_port; + + /* + * Collapse the mbuf chain if the first mbuf is too short + * The longest case is: UDP + non ESP marker + ESP + */ + minlen = off + sizeof(struct udphdr) + sizeof(u_int64_t) + sizeof(struct esp); + if (minlen > n->m_pkthdr.len) + minlen = n->m_pkthdr.len; + + if ((n = m_pullup(n, minlen)) == NULL) { + printf("udp_append: m_pullup failed\n"); + m_freem(n); + return; + } + + if (udp4_espinudp(n, off, sa, last->inp_socket) != 0) { + m_freem(n); + return; + } + + /* Normal UDP processing will take place */ + } +#endif #ifdef MAC if (mac_check_inpcb_deliver(last, n) != 0) { m_freem(n); @@ -702,6 +745,80 @@ CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_PRISON, 0, 0, udp_getcred, "S,xucred", "Get the xucred of a UDP connection"); + +int +udp_ctloutput(so, sopt) + struct socket *so; + struct sockopt *sopt; +{ + int error, optval, s; + struct inpcb *inp; + int family; + + error = 0; + family = so->so_proto->pr_domain->dom_family; + + s = splnet(); + if (sopt->sopt_level != IPPROTO_UDP) { +#ifdef INET6 + if (INP_CHECK_SOCKAF(so, AF_INET6)) + error = ip6_ctloutput(so, sopt); + else +#endif /* INET6 */ + error = ip_ctloutput(so, sopt); + splx(s); + return (error); + } + inp = sotoinpcb(so); + + switch (sopt->sopt_dir) { + case SOPT_SET: + switch (sopt->sopt_name) { + case UDP_ENCAP: + error = sooptcopyin(sopt, &optval, sizeof optval, + sizeof optval); + if (error) + break; + + switch(optval){ + case 0: + inp->inp_flags &= ~INP_ESPINUDP_ALL; + break; + + case UDP_ENCAP_ESPINUDP: + inp->inp_flags |= INP_ESPINUDP; + break; + + case UDP_ENCAP_ESPINUDP_NON_IKE: + inp->inp_flags |= INP_ESPINUDP_NON_IKE; + break; + + default: + error = EINVAL; + goto end; + break; + } + break; + + default: + error = ENOPROTOOPT; + goto end; + break; + } + break; + + default: + error = EINVAL; + goto end; + break; + } + +end: + splx(s); + return error; +} + + static int udp_output(inp, m, addr, control, td) register struct inpcb *inp; @@ -922,6 +1039,115 @@ m_freem(m); return (error); } + +#ifdef IPSEC +#ifdef INET +/* + * Returns: + * 1 if the packet was processed + * 0 if normal UDP processing should take place + */ +static int +udp4_espinudp(m, off, src, so) + struct mbuf *m; + int off; + struct sockaddr *src; + struct socket *so; +{ + size_t len; + caddr_t data; + struct inpcb *inp; + size_t skip = 0; + size_t minlen; + size_t iphdrlen; + struct ip *ip; + struct mbuf *n; + + /* + * Cannot collapse the mbuf chain here, must have been done in + * calling function + * The longest case is: UDP + non ESP marker + ESP + */ + minlen = off + sizeof(u_int64_t) + sizeof(struct esp); + if (minlen > m->m_pkthdr.len) + minlen = m->m_pkthdr.len; + + if (m->m_len < minlen) + return 0; + + len = m->m_len - off; + data = mtod(m, caddr_t) + off; + inp = sotoinpcb(so); + + /* Ignore keepalive packets */ + if ((len == 1) && (data[0] == '\xff')) { + return 1; + } + + /* + * Check that the payload is long enough to hold + * an ESP header and compute the length of encapsulation + * header to remove + */ + if (inp->inp_flags & INP_ESPINUDP) { + u_int32_t *st = (u_int32_t *)data; + + if ((len <= sizeof(struct esp)) || (*st == 0)) + return 0; /* Normal UDP processing */ + + skip = sizeof(struct udphdr); + } + + if (inp->inp_flags & INP_ESPINUDP_NON_IKE) { + u_int64_t *st = (u_int64_t *)data; + + if ((len <= sizeof(u_int64_t) + sizeof(struct esp)) + || (*st != 0)) + return 0; /* Normal UDP processing */ + + skip = sizeof(struct udphdr) + sizeof(u_int64_t); + } + + /* + * Remove the UDP header (and possibly the non ESP marker) + * IP header lendth is iphdrlen + * Before: + * <--- off ---> + * +----+------+-----+ + * | IP | UDP | ESP | + * +----+------+-----+ + * <-skip-> + * After: + * +----+-----+ + * | IP | ESP | + * +----+-----+ + * <-skip-> + */ + iphdrlen = off - sizeof(struct udphdr); + ovbcopy(mtod(m, caddr_t), mtod(m, caddr_t) + skip, iphdrlen); + m_adj(m, skip); + + ip = mtod(m, struct ip *); + ip->ip_len = htons(ntohs(ip->ip_len) - skip); + ip->ip_p = IPPROTO_ESP; + + /* + * Copy the mbuf to avoid multiple free, as both + * esp4_input (which we call) and udp_input (which + * called us) free the mbuf. + */ + if ((n = m_dup(m, M_DONTWAIT)) == NULL) { + printf("udp4_espinudp: m_dup failed\n"); + return 0; + } + + esp4_input(n, iphdrlen); + + /* We handled it, it shoudln't be handled by UDP */ + return 1; +} +#endif +#endif u_long udp_sendspace = 9216; /* really max datagram size */ /* 40 1K datagrams */ --- sys/netinet/udp_var.h.orig Fri Jan 7 10:45:45 2005 +++ sys/netinet/udp_var.h Sat Sep 9 19:54:50 2006 @@ -100,6 +100,7 @@ extern int log_in_vain; void udp_ctlinput(int, struct sockaddr *, void *); +int udp_ctloutput(struct socket *, struct sockopt *sopt); void udp_init(void); void udp_input(struct mbuf *, int); --- sys/netinet6/esp_output.c.orig Fri Jan 7 11:30:34 2005 +++ sys/netinet6/esp_output.c Sat Sep 9 19:57:55 2006 @@ -56,6 +56,8 @@ #include #include +#include + #ifdef INET6 #include #include @@ -139,6 +141,17 @@ hdrsiz = sizeof(struct newesp) + ivlen + 9 + authlen; } +#ifdef IPSEC_NAT_T + /* + * If NAT-T is enabled, add the space for UDP encapsulation + */ + if (sav->natt_type != 0) { + hdrsiz += sizeof(struct udphdr); + if (sav->natt_type == UDP_ENCAP_ESPINUDP_NON_IKE) + hdrsiz += sizeof(u_int64_t); + } +#endif + return hdrsiz; estimate: @@ -149,8 +162,14 @@ * 9 = (maximum padding length without random padding length) * + (Pad Length field) + (Next Header field). * 16 = maximum ICV we support. + * sizeof(struct udphdr) in case NAT traversal is used */ +#if defined (IPSEC_NAT_T) + return sizeof(struct newesp) + esp_max_ivlen() + 9 + 16 + + sizeof(u_int64_t) + sizeof(struct udphdr); +#else return sizeof(struct newesp) + esp_max_ivlen() + 9 + 16; +#endif } /* @@ -196,6 +215,9 @@ size_t extendsiz; int error = 0; struct ipsecstat *stat; +#ifdef IPSEC_NAT_T + struct udphdr *udp = NULL; +#endif switch (af) { #ifdef INET @@ -334,10 +356,25 @@ espoff = m->m_pkthdr.len - plen; +#ifdef IPSEC_NAT_T + if (sav->natt_type != 0) { + esphlen += sizeof(struct udphdr); + espoff += sizeof(struct udphdr); + + if (sav->natt_type == UDP_ENCAP_ESPINUDP_NON_IKE) { + /* NON-IKE marker */ + esphlen += sizeof(u_int64_t); + espoff += sizeof(u_int64_t); + } + } +#endif + /* * grow the mbuf to accomodate ESP header. * before: IP ... payload - * after: IP ... ESP IV payload + * after (without NAT-T): IP ... ESP IV payload + * after (with older NAT-T): IP ... UDP non-IKE-marker ESP IV payload + * after (with newer NAT-T): IP ... UDP ESP IV payload */ if (M_LEADINGSPACE(md) < esphlen || (md->m_flags & M_EXT) != 0) { MGET(n, M_DONTWAIT, MT_DATA); @@ -358,6 +395,21 @@ esp = mtod(md, struct esp *); } +#ifdef IPSEC_NAT_T + if (sav->natt_type != 0) { + udp = (struct udphdr *)esp; + esp = (struct esp *)(udp + 1); + + if (sav->natt_type == UDP_ENCAP_ESPINUDP_NON_IKE) { + u_int64_t *data = (u_int64_t *)esp; + + *data = 0; /* NON-IKE marker */ + esp = (struct esp *)(data + 1); + } + } +#endif + + nxt = *nexthdrp; *nexthdrp = IPPROTO_ESP; switch (af) { @@ -523,6 +575,26 @@ break; } +#ifdef IPSEC_NAT_T + if (sav->natt_type != 0) { + *nexthdrp = IPPROTO_UDP; + + /* + * Create the UDP encapsulation header for NAT-T + * uh_len is set later, when the size is known. + */ + if (sav->natt_type == UDP_ENCAP_ESPINUDP_NON_IKE) + udp->uh_sport = htons(UDP_ENCAP_ESPINUDP_PORT); + else + udp->uh_sport = htons(sav->local_ike_port); + + udp->uh_dport = htons(sav->remote_ike_port); + udp->uh_sum = 0; + } else { + *nexthdrp = IPPROTO_ESP; + } +#endif + /* initialize esp trailer. */ esptail = (struct esptail *) (mtod(n, u_int8_t *) + n->m_len - sizeof(struct esptail)); @@ -665,6 +737,18 @@ #endif } } + +#ifdef IPSEC_NAT_T + if (sav->natt_type != 0) { + struct ip *ip; + ip = mtod(m, struct ip *); +#ifdef _IP_VHL + udp->uh_ulen = htons(ntohs(ip->ip_len) - (IP_VHL_HL(ip->ip_vhl) << 2)); +#else + udp->uh_ulen = htons(ntohs(ip->ip_len) - (ip->ip_hl << 2)); +#endif + } +#endif noantireplay: if (!m) { --- sys/netkey/key.c.orig Sat Nov 5 05:26:16 2005 +++ sys/netkey/key.c Sat Sep 9 20:01:27 2006 @@ -194,6 +194,10 @@ 0, /* SADB_X_EXT_KMPRIVATE */ sizeof(struct sadb_x_policy), /* SADB_X_EXT_POLICY */ sizeof(struct sadb_x_sa2), /* SADB_X_SA2 */ + sizeof(struct sadb_x_nat_t_type), /* SADB_X_EXT_NAT_T_TYPE */ + sizeof(struct sadb_x_nat_t_port), /* SADB_X_EXT_NAT_T_SPORT */ + sizeof(struct sadb_x_nat_t_port), /* SADB_X_EXT_NAT_T_DPORT */ + sizeof(struct sadb_address), /* SADB_X_EXT_NAT_T_OA */ }; static const int maxsize[] = { sizeof(struct sadb_msg), /* SADB_EXT_RESERVED */ @@ -216,6 +220,10 @@ 0, /* SADB_X_EXT_KMPRIVATE */ 0, /* SADB_X_EXT_POLICY */ sizeof(struct sadb_x_sa2), /* SADB_X_SA2 */ + sizeof(struct sadb_x_nat_t_type), /* SADB_X_EXT_NAT_T_TYPE */ + sizeof(struct sadb_x_nat_t_port), /* SADB_X_EXT_NAT_T_SPORT */ + sizeof(struct sadb_x_nat_t_port), /* SADB_X_EXT_NAT_T_DPORT */ + 0, /* SADB_X_EXT_NAT_T_OA */ }; static int ipsec_esp_keymin = 256; @@ -384,6 +392,8 @@ const struct sadb_msghdr *); static int key_spddump(struct socket *, struct mbuf *, const struct sadb_msghdr *); +static int key_nat_map(struct socket *, struct mbuf *, + const struct sadb_msghdr *); static struct mbuf *key_setdumpsp(struct secpolicy *, u_int8_t, u_int32_t, u_int32_t); static u_int key_getspreqmsglen(struct secpolicy *); @@ -2475,6 +2485,62 @@ return 0; } +/* + * SADB_X_NAT_T_NEW_MAPPING + */ +static int +key_nat_map(so, m, mhp) + struct socket *so; + struct mbuf *m; + const struct sadb_msghdr *mhp; +{ + struct sadb_x_nat_t_type *type; + struct sadb_x_nat_t_port *sport; + struct sadb_x_nat_t_port *dport; + struct sadb_address *addr; + + /* sanity check */ + if (so == NULL || m == NULL || mhp == NULL || mhp->msg == NULL) + panic("key_nat_map: NULL pointer is passed."); + + if (mhp->ext[SADB_X_EXT_NAT_T_TYPE] == NULL || + mhp->ext[SADB_X_EXT_NAT_T_SPORT] == NULL || + mhp->ext[SADB_X_EXT_NAT_T_DPORT] == NULL) { + ipseclog((LOG_DEBUG, "key_nat_map: invalid message.\n")); + return key_senderror(so, m, EINVAL); + } + if ((mhp->extlen[SADB_X_EXT_NAT_T_TYPE] < sizeof(*type)) || + (mhp->extlen[SADB_X_EXT_NAT_T_SPORT] < sizeof(*sport)) || + (mhp->extlen[SADB_X_EXT_NAT_T_DPORT] < sizeof(*dport))) { + ipseclog((LOG_DEBUG, "key_nat_map: invalid message.\n")); + return key_senderror(so, m, EINVAL); + } + + if ((mhp->ext[SADB_X_EXT_NAT_T_OA] != NULL) && + (mhp->extlen[SADB_X_EXT_NAT_T_OA] < sizeof(*addr))) { + ipseclog((LOG_DEBUG, "key_nat_map: invalid message\n")); + return key_senderror(so, m, EINVAL); + } + + type = (struct sadb_x_nat_t_type *)mhp->ext[SADB_X_EXT_NAT_T_TYPE]; + sport = (struct sadb_x_nat_t_port *)mhp->ext[SADB_X_EXT_NAT_T_SPORT]; + dport = (struct sadb_x_nat_t_port *)mhp->ext[SADB_X_EXT_NAT_T_DPORT]; + addr = (struct sadb_address *)mhp->ext[SADB_X_EXT_NAT_T_OA]; + + printf("sadb_nat_map: type %d, sport = %d, dport = %d\n", + type->sadb_x_nat_t_type_type, + sport->sadb_x_nat_t_port_port, + dport->sadb_x_nat_t_port_port); + + /* + * XXX handle that, it should also contain a SA, or anything + * that enable to update the SA information. + */ + + return 0; +} + + static struct mbuf * key_setdumpsp(sp, type, seq, pid) struct secpolicy *sp; @@ -3025,6 +3091,9 @@ sav->lft_c = NULL; sav->lft_h = NULL; sav->lft_s = NULL; + sav->natt_type = 0; + sav->remote_ike_port = 0; + sav->local_ike_port = 0; /* SA */ if (mhp->ext[SADB_EXT_SA] != NULL) { @@ -5223,6 +5292,50 @@ } /* + * Handle NAT-T info if present + */ + if (mhp->ext[SADB_X_EXT_NAT_T_OA] != NULL) { + printf("add: NAT-T OA present\n"); + } + if ((mhp->ext[SADB_X_EXT_NAT_T_TYPE] != NULL) && + (mhp->ext[SADB_X_EXT_NAT_T_SPORT] != NULL) && + (mhp->ext[SADB_X_EXT_NAT_T_DPORT] != NULL)) { + struct sadb_x_nat_t_type *type; + struct sadb_x_nat_t_port *sport; + struct sadb_x_nat_t_port *dport; + struct sadb_address *addr; + + if ((mhp->extlen[SADB_X_EXT_NAT_T_TYPE] < sizeof(*type)) || + (mhp->extlen[SADB_X_EXT_NAT_T_SPORT] < sizeof(*sport)) || + (mhp->extlen[SADB_X_EXT_NAT_T_DPORT] < sizeof(*dport))) { + ipseclog((LOG_DEBUG, "key_add: " + "invalid message.\n")); + return key_senderror(so, m, EINVAL); + } + + if ((mhp->ext[SADB_X_EXT_NAT_T_OA] != NULL) && + (mhp->extlen[SADB_X_EXT_NAT_T_OA] < sizeof(*addr))) { + ipseclog((LOG_DEBUG, "key_add: invalid message\n")); + return key_senderror(so, m, EINVAL); + } + + type = (struct sadb_x_nat_t_type *) + mhp->ext[SADB_X_EXT_NAT_T_TYPE]; + sport = (struct sadb_x_nat_t_port *) + mhp->ext[SADB_X_EXT_NAT_T_SPORT]; + dport = (struct sadb_x_nat_t_port *) + mhp->ext[SADB_X_EXT_NAT_T_DPORT]; + addr = (struct sadb_address *) + mhp->ext[SADB_X_EXT_NAT_T_OA]; + + newsav->natt_type = type->sadb_x_nat_t_type_type; + newsav->local_ike_port = ntohs(sport->sadb_x_nat_t_port_port); + newsav->remote_ike_port = ntohs(dport->sadb_x_nat_t_port_port); + } + + + + /* * don't call key_freesav() here, as we would like to keep the SA * in the database on success. */ @@ -6875,6 +6988,7 @@ key_spdadd, /* SADB_X_SPDSETIDX */ NULL, /* SADB_X_SPDEXPIRE */ key_spddelete2, /* SADB_X_SPDDELETE2 */ + key_nat_map, /* SADB_X_NAT_T_NEW_MAPPING */ }; /* @@ -7227,6 +7341,12 @@ case SADB_EXT_SPIRANGE: case SADB_X_EXT_POLICY: case SADB_X_EXT_SA2: +#ifdef IPSEC_NAT_T + case SADB_X_EXT_NAT_T_TYPE: + case SADB_X_EXT_NAT_T_SPORT: + case SADB_X_EXT_NAT_T_DPORT: + case SADB_X_EXT_NAT_T_OA: +#endif /* duplicate check */ /* * XXX Are there duplication payloads of either --- sys/netkey/keydb.h.orig Fri Jan 7 10:45:48 2005 +++ sys/netkey/keydb.h Sat Sep 9 20:05:00 2006 @@ -114,6 +114,11 @@ pid_t pid; /* message's pid */ struct secashead *sah; /* back pointer to the secashead */ + /* For NAT-Traversal + */ + u_int16_t natt_type; + u_int16_t remote_ike_port; + u_int16_t local_ike_port; /* ??? */ u_int32_t id; /* SA id */ }; --Multipart=_Sat__9_Sep_2006_20_31_47_+0900_LsJNF2y__AcBQXgZ-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 9 20:52:13 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2862D16A415; Sat, 9 Sep 2006 20:52:13 +0000 (UTC) (envelope-from gybvmaj@epochworks.net) Received: from epochworks.net (avl180.neoplus.adsl.tpnet.pl [83.27.45.180]) by mx1.FreeBSD.org (Postfix) with SMTP id A018143D46; Sat, 9 Sep 2006 20:52:10 +0000 (GMT) (envelope-from gybvmaj@epochworks.net) Date: Sat, 09 Sep 2006 22:52:09 +0100 From: "xgvenk ppwwplhx" X-Sender: gybvmaj@epochworks.net To: , , , Message-Id: <4264654820.ucLAaI-42066627-1972@epochworks.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Subject: Trader's Daily Report AETR . PK 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, 09 Sep 2006 20:52:13 -0000 W A T C H O U T! Here comes the big one! All signs show that AETR is going to Explode! ALLIANCE ENTERPRISE (AETR) Current Price 0.50 Add this gem to your watch list, and watch it trad closely! NEWS RELEASE TAECORP ANNOUNCES BREAKTHROUGH IN REMOVING DEADLY LANDMINES. TaeCorp Announces That NASA Technology Will Be a Key Contributor to Resolving World's Landmine Dilemma Sept. 6, 2006--The Alliance Enterprise Corporation ("TaeCorp") is pleased to announce that NASA technology will be the key component in keeping our landmine locator (LML) system operational year round, especially in inclement weather. TaeCorp and Ice Management have agreed that Ice Management will customize their de-icer system exclusively for TaeCorp's LML air vehicles that are to be deployed for landmine removal and home security MILL VALLEY, CALIFORNIA August 25, 2006 - The Alliance Enterprise Corporation announced today a BREAKTHROUGH in developing an Aerial Landmine System aimed at locating, detecting and mapping deadly landmines. More than 100 million landmines in 83 countries are holding international communities and industries hostage, preventing the investment in and development of productive lands and the re-building of infrastructure. A broad variety of landmines have been scattered over productive areas effectively crippling the economy and disabling thousands of children and adults. There are no reliable records that accurately show where these devastating landmines lie in wait for their victims. With the present day costs to clear a single land mine ranging between ,000 to ,500, solving the problem of de-mining lands will reach billions of dollars. TaeCorp has developed a technology based, cost effective solution to this problem using its three tiered approach to scanning, mapping and removing landmines. TaeCorp's System will provide many social and economic benefits to countries and their industries including oil and gas, mining, agriculture, roads and infrastructure development. About TaeCorp. TaeCorp's vision is to be the recognized leader in providing Aerial Detection Systems including global de-mining, clearing a path to a safer planet for all humankind. TaeCorp's mission is to reclaim lands around the globe embedded with landmines that victimize countries and their stakeholders. Watch AETR like a HAWK come Monday You will be convinced if you see ----------------------- We'll hand you out to dry. Weed it out. Two peas in a pod. Shiver me timber. The season of goodwill. Save it for a rainy day. Walking on water. Where man is not nature is barren. When the cows come home. Thick as a brick. The scum of the earth. Up a tree. Schools out for summer. Season of mists and mellow fruitfulness. Spring rain, Fall gold. Tastes like chicken. Under the weather. Throw pearls before swine. When we love - we grow. Shake like a leaf. Plant kindness and gather love. You say potayto, I say potahto. She's the apple of my eye. That's water under the bridge. Raking it in. Watch and wait. Up one side and down the other. Sweet as honey. A thorn in my side. Spill the beans. She has a green thumb. Through the grapevine.