From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 01:07:27 2005 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 F14D416A41C for ; Sun, 5 Jun 2005 01:07:27 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 815A943D48 for ; Sun, 5 Jun 2005 01:07:25 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 70429 invoked from network); 5 Jun 2005 01:07:24 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 5 Jun 2005 01:07:24 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 4 Jun 2005 20:07:12 -0500 (CDT) From: Mike Silbersack To: jun lu In-Reply-To: <20050601032104.65888.qmail@web15502.mail.cnb.yahoo.com> Message-ID: <20050604200407.U14750@odysseus.silby.com> References: <20050601032104.65888.qmail@web15502.mail.cnb.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: some question about mbuf reuse 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, 05 Jun 2005 01:07:28 -0000 On Wed, 1 Jun 2005, jun lu wrote: > our project write a web server in freebsd kernel. we can receive and > send data directly in kernel.Now i have some idea, i think i can creat a > mbuf with cluster buffer before i send some data,because the data i want > to send are all in kernel,so i can take thest data in cluster i create > before,and transfer this mbuf to sosend(),then i make tcp/ip cann't > release this mbuf after it received the ack.In this way, i can send data > in kernel next time use the same mbuf with different cluster.i am not > sure whether this way can enhance the performance.So,i hope some one can > discuss with me I don't think that what you are proposing would work. Mbuf clusters can be used in multiple mbuf chains at the same time, but I don't see how you could do that with mbufs. You probably should focus your optimization efforts elsewhere, because changing the mbuf api would make your code diverge too much from the standard FreeBSD kernel to be useful to anyone. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 02:54:05 2005 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 2C4F416A442; Sun, 5 Jun 2005 02:54:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C61243D55; Sun, 5 Jun 2005 02:54:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j552rJmS057165; Sat, 4 Jun 2005 20:53:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 04 Jun 2005 20:54:06 -0600 (MDT) Message-Id: <20050604.205406.98086467.imp@bsdimp.com> To: omestre@freeshell.org From: "M. Warner Losh" In-Reply-To: <20050603195256.GE2065@pro-pae-5513.procergs.reders> References: <20050603195256.GE2065@pro-pae-5513.procergs.reders> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: USB CDC ACM 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, 05 Jun 2005 02:54:05 -0000 I beleive that umodem implements the usb cdc acm interface. Warner From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 11:35:48 2005 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 1AEEA16A41C for ; Sun, 5 Jun 2005 11:35:48 +0000 (GMT) (envelope-from distantly@donnatofal.com) Received: from ppp83-237-226-201.pppoe.mtu-net.ru (ppp83-237-226-201.pppoe.mtu-net.ru [83.237.226.201]) by mx1.FreeBSD.org (Postfix) with SMTP id A91D243D48 for ; Sun, 5 Jun 2005 11:35:46 +0000 (GMT) (envelope-from distantly@donnatofal.com) Received: from [107.29.60.180] (port=4007 helo=[bauble]) by ppp83-237-226-201.pppoe.mtu-net.ru with esmtp id 1761266470harry6870 for freebsd-net@freebsd.org; Sun, 5 Jun 2005 15:35:43 +0400 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <2909040320.8084955366@ppp83-237-226-201.pppoe.mtu-net.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Philip Date: Sun, 5 Jun 2005 15:35:42 +0400 X-Mailer: Apple Mail (2.728) Subject: Top software brands and independece you can trust. 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, 05 Jun 2005 11:35:48 -0000 Software by the original manufacturer&at generic prices& http://artyoss.t0fqeab4q3ti8ct.wafddiwafd8.com To me, old age is always 15 years older than I am. All we are saying is give peace a chance. From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 16:27:44 2005 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 04A6F16A41C; Sun, 5 Jun 2005 16:27:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F23B43D4C; Sun, 5 Jun 2005 16:27:42 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 13D95651F4; Sun, 5 Jun 2005 17:25:42 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 84704-02-3; Sun, 5 Jun 2005 17:25:41 +0100 (BST) Received: from empiric.dek.spc.org (82-35-114-35.cable.ubr07.dals.blueyonder.co.uk [82.35.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EBC41651EE; Sun, 5 Jun 2005 17:25:39 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id C01DC61E6; Sun, 5 Jun 2005 17:27:34 +0100 (BST) Date: Sun, 5 Jun 2005 17:27:34 +0100 From: Bruce M Simpson To: Julian Elischer Message-ID: <20050605162734.GA773@empiric.icir.org> Mail-Followup-To: Julian Elischer , Andrew Thompson , freebsd-net@freebsd.org References: <20050603020140.GA22870@heff.fud.org.nz> <42A0C4F4.8010009@elischer.org> <20050603211400.GA26676@heff.fud.org.nz> <42A0CE82.5040306@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A0CE82.5040306@elischer.org> Cc: freebsd-net@freebsd.org, Andrew Thompson Subject: Re: xxconfig for if_bridge 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, 05 Jun 2005 16:27:44 -0000 Hi, Many of these points were covered in the thread from over a year ago which Andrew helpfully posted the link to. On Fri, Jun 03, 2005 at 02:41:22PM -0700, Julian Elischer wrote: > and I still don't see why it is better to import Yet another bridge > module rather > than adding it to the 2 we already have. > You can do things with ng_bridge that you can't do with if_bridge.. > for example bridge together 3 remote sites connected by ipsec tunnels. Don't get me wrong, I'm not knocking Netgraph -- it is a nice concept, but it needs more work in order to offer our users the same performance as more traditional ifnet layer code. It is also obscure to configure for many of our users. I think the benefits are quite concrete and speak for themselves. 1) Common code with NetBSD and OpenBSD. This should be obvious -- code which has been shown to be good in these other two BSDs will enable us to pick up fixes and improvements from those lines of development. Where Netgraph bridge implementations are concerned, it has to be pointed out: Netgraph is not part of NetBSD or OpenBSD, so further development of ng_bridge(4) does not offer this particular benefit. 2) Working firewall support through the use of the appropriate mbuf tags. Whilst this is something which may be *possible* with Netgraph, I have yet to see working code for it, which is why I'm puzzled by the persistent argument of 'you should do it with Netgraph!' by the Netgraph devotees. 3) New features, particularly spanning tree. Not only have we been behind the other BSDs in terms of feature set, we've also been behind Linux. Spanning Tree is one of the real wins from importing if_bridge(4). 4) It serves as a good example and basis of how to do Layer 2 things at the ifnet layer for future projects. Based on my reading of the code, it's cleaner than bridge(4). if_bridge(4) incorporates spanning tree as above -- this is a concrete starting point for doing things like 802.11s Mesh. The forwarding table for spanning tree has a clear logical separation from the existing ARP code. 5) It does not suffer from the same issues which bridge(4) has had. bridge(4) has had a number of issues. In particular I'm thinking of things such as disabling and reenabling hardware checksumming. 6) Performance is roughly equal and in some cases better than bridge(4). With this in mind, bridge(4) should be deprecated sooner than later -- I would hope that 6-CURRENT gets enough test coverage that this can happen either in time for 6-RELEASE, if not 7. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sun Jun 5 16:29:02 2005 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 04E6316A452; Sun, 5 Jun 2005 16:29:02 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DE9343D53; Sun, 5 Jun 2005 16:29:01 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 65D68651F4; Sun, 5 Jun 2005 17:27:02 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 84704-02-5; Sun, 5 Jun 2005 17:27:01 +0100 (BST) Received: from empiric.dek.spc.org (82-35-114-35.cable.ubr07.dals.blueyonder.co.uk [82.35.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id CF6CD651EE; Sun, 5 Jun 2005 17:27:01 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7118261E6; Sun, 5 Jun 2005 17:28:57 +0100 (BST) Date: Sun, 5 Jun 2005 17:28:57 +0100 From: Bruce M Simpson To: Ruslan Ermilov , freebsd-net@freebsd.org Message-ID: <20050605162857.GB773@empiric.icir.org> Mail-Followup-To: Ruslan Ermilov , freebsd-net@freebsd.org References: <20050603181636.GA54906@gicco.homeip.net> <20050603191351.GA54164@ip.net.ua> <20050603202109.GA22098@gargantuan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050603202109.GA22098@gargantuan.com> Cc: Subject: Re: route metric 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, 05 Jun 2005 16:29:02 -0000 On Fri, Jun 03, 2005 at 04:21:09PM -0400, Michael W. Oliver wrote: > there used to be patches floating around for 4.x that would allow a kind > of metric, but IIRC you couldn't use two (or more) same-metric routes > for per-packet balancing, rather the metric would be degraded for each > packet that was forwarded to a particular destination (it's been a while > since I looked, so I may be all wet on this). We need to retool the PF_ROUTE ABI before we can do this. This task should be on the 'Google Summer of Code' laundry list shortly. BMS From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 00:35:21 2005 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 9B14116A41C for ; Mon, 6 Jun 2005 00:35:21 +0000 (GMT) (envelope-from shiner_chen@yahoo.com.cn) Received: from web15507.mail.cnb.yahoo.com (web15507.mail.cnb.yahoo.com [202.165.102.36]) by mx1.FreeBSD.org (Postfix) with SMTP id C8F2F43D1D for ; Mon, 6 Jun 2005 00:35:20 +0000 (GMT) (envelope-from shiner_chen@yahoo.com.cn) Received: (qmail 52377 invoked by uid 60001); 6 Jun 2005 00:35:19 -0000 Message-ID: <20050606003519.52375.qmail@web15507.mail.cnb.yahoo.com> Received: from [61.187.16.2] by web15507.mail.cnb.yahoo.com via HTTP; Mon, 06 Jun 2005 08:35:19 CST Date: Mon, 6 Jun 2005 08:35:19 +0800 (CST) From: shiner chen To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to active the received function when the data arrived the socket in kld 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, 06 Jun 2005 00:35:21 -0000 Inorder to impliment the dynamic load freeback policy ,I wrote a kld on the front-end of cluster server for collecting the load of back nodes. I don't want the acceptive thread to detect the data arrived socket continuously,because ,which will affect the performance of the front-end.i want to know whether i can active the acceptive thread to receive the data when the data arrive the socket established. how shuld i do in the kernel ? thanks!! --------------------------------- DO YOU YAHOO!? »¶Ó­Ê¹ÓÃÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 02:55:30 2005 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 9194C16A41C for ; Mon, 6 Jun 2005 02:55:30 +0000 (GMT) (envelope-from timt@sharktech.net) Received: from sharktech.net (usr1-123.sharktech.net [66.90.92.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD8B843D1D for ; Mon, 6 Jun 2005 02:55:29 +0000 (GMT) (envelope-from timt@sharktech.net) Received: (qmail 37172 invoked from network); 6 Jun 2005 02:55:28 -0000 Received: from localhost.ushells.net (HELO localhost) (127.0.0.1) by localhost.ushells.net with SMTP; 6 Jun 2005 02:55:28 -0000 Received: from 69.146.27.144 ([69.146.27.144]) by webmail.sharktech.net (IMP) with HTTP for ; Sun, 5 Jun 2005 21:55:28 -0500 Message-ID: <1118026528.42a3bb20a76ce@webmail.sharktech.net> Date: Sun, 5 Jun 2005 21:55:28 -0500 From: timt@sharktech.net To: freebsd-bugs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 69.146.27.144 Cc: freebsd-net@freebsd.org Subject: LSI MegaRaid 150-6 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, 06 Jun 2005 02:55:30 -0000 Hello, This is the 2nd time I search for a resolution on this matter I could not find any documents online regarding this issue. We are building a system with the following hardware: Tyan S2882 Dual Opteron Board (latest BIOS) 2 x Opteron 244 CPU's 2 x 1GB DDR PC3200+ LSI MegaRaid 150-6 (Intel SRCS16) (latest firmware) Intel Pro SC 1000 Fiber NIC 5 x 200GB 7.2KRPM 8MBuffer Western Digital (each hard drive has been checked for any problem) At first we started installing FreeBSD5.4-RELEASE AMD64 LSI Megaraid was detected and raid was running in optimal. When it asked me to choose the slice it gave me a warning that the geometry for the drive is incorrect and to check with the BIOS for the true geometry and if this is a SCSI please check with the controller's algorithem (something). Which I searched online for with no clues. Anyways went to system installation it starts installing bursting to 2600KB/s and after 55% it goes down to 800KB/s than when reaching ports it goes down to 33KB/s and this is CDROM installation!! When system is installed completly we ran dd on the system a constant average of 2.1MB/s is the BEST performance we could get! We tried installing Windows XP for testing and performance was decent bursting to 70MB/s (which is the average on this controller). We tried FreeBSD5.3(I386) and FreeBSD4.11(i386) same problem. Please if anyone have any idea whats going on we really don't wanna go with Linux on this system!! Thanks in advanced. Tim Timrawi ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 05:51:08 2005 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 B90C716A41C for ; Mon, 6 Jun 2005 05:51:08 +0000 (GMT) (envelope-from samspeedu@mail.ru) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A0BE43D53 for ; Mon, 6 Jun 2005 05:51:08 +0000 (GMT) (envelope-from samspeedu@mail.ru) Received: from [213.129.119.20] (port=3698 helo=192.168.168.7) by mx2.mail.ru with esmtp id 1DfAVu-000HTe-00 for freebsd-net@freebsd.org; Mon, 06 Jun 2005 09:51:06 +0400 Date: Mon, 6 Jun 2005 09:50:36 +0400 From: Andrey Smagin X-Mailer: The Bat! (v1.62r) Organization: DiP X-Priority: 3 (Normal) Message-ID: <17710356039.20050606095036@mail.ru> To: freebsd-net@freebsd.org In-Reply-To: <20050530133303.Y82220@mp2.macomnet.net> References: <862239983.20050530124214@mail.ru> <20050530133303.Y82220@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: connect 2 subnet by WiFi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: SAMU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 05:51:08 -0000 Hi all! Need to connect 2 ethernet subnet. Now for it used D-Link DI-624 Wireless Router and DWL-G520. Problem that Server can ping any another PC in net, subnet A can ping Server but can't ping subnet B, subnet B also can ping Server but can't ping subnet A. topology and configs: 192.168.1.3 |by wire subnet A | 192.168.1.6 \ | Air 192.168.1.100 192.168.1.7 > (Switch) --- DI-624 ~~~~~~ (ath0)Server(fxp0) 192.168.1.8 / by wire | (Switch) | subnet B | 192.168.1.5 192.168.1.1 rc.conf ... ifconfig_ath0="inet up ssid my_net" ifconfig_fxp0="inet 192.168.1.100 netmask 255.255.255.0" ... sysctl.conf ... sysctl net.link.ether.bridge_cfg="ath0:1,fxp0:1" sysctl net.link.ether.bridge=1 sysctl net.inet.ip.check_interface=0 ... -- Best regards, Andrey mailto:samspeedu@mail.ru From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 08:17:42 2005 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 439D716A41C for ; Mon, 6 Jun 2005 08:17:42 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7CE943D5D for ; Mon, 6 Jun 2005 08:17:41 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt14.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DfCnj-00037e-00; Mon, 06 Jun 2005 20:17:39 +1200 Received: from mjl by lycra.luckie.org.nz with local (Exim 4.51 (FreeBSD)) id 1DfCml-000JFd-0c for freebsd-net@freebsd.org; Mon, 06 Jun 2005 20:16:39 +1200 Date: Mon, 6 Jun 2005 20:16:38 +1200 From: Matthew Luckie To: freebsd-net@freebsd.org Message-ID: <20050606081637.GA73886@lycra.luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4295A6CA.8080409@luckie.org.nz> User-Agent: Mutt/1.4.2.1i Subject: Re: bpf writes on tun device 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, 06 Jun 2005 08:17:42 -0000 > I can successfully write BPF packets up to 1500 bytes in size (1496 IP > bytes without the address family integer). Writes larger than this > return EMSGSIZE. http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007371.html Just for the record, the patch below fixes this on 4.11; the same problem exists in HEAD today. I'm pondering making an effort to add write support to all interface types. I would do this by adding an extra parameter to bpf_if that specifies the size of the 'link layer' it expects to encounter when bpfwrite is called. struct bpf_if { LIST_ENTRY(bpf_if) bif_next; /* list of all interfaces */ LIST_HEAD(, bpf_d) bif_dlist; /* descriptor list */ struct bpf_if **bif_driverp; /* pointer into softc */ u_int bif_dlt; /* link layer type */ - u_int bif_hdrlen; /* length of header (with padding) */ + u_int bif_hdrlen_rx; /* link header passed to bpf reader */ + u_int bif_hdrlen_tx; /* link header passed by bpf writer */ struct ifnet *bif_ifp; /* corresponding interface */ struct mtx bif_mtx; /* mutex for interface */ }; If I was to pursue this, would someone on this list consider committing the work to current? Index: bpf.c =================================================================== RCS file: /home/ncvs/src/sys/net/bpf.c,v retrieving revision 1.59.2.13 diff -u -p -r1.59.2.13 bpf.c --- bpf.c 21 Aug 2003 23:50:54 -0000 1.59.2.13 +++ bpf.c 6 Jun 2005 07:54:12 -0000 @@ -120,7 +120,7 @@ static void bpf_detachd __P((struct bpf_ static void bpf_freed __P((struct bpf_d *)); static void bpf_mcopy __P((const void *, void *, size_t)); static int bpf_movein __P((struct uio *, int, - struct mbuf **, struct sockaddr *, int *)); + struct mbuf **, struct sockaddr *, struct ifnet *)); static int bpf_setif __P((struct bpf_d *, struct ifreq *)); static void bpf_timed_out __P((void *)); static inline void @@ -164,9 +164,10 @@ static struct filterops bpfread_filtops { 1, NULL, filt_bpfdetach, filt_bpfread }; static int -bpf_movein(uio, linktype, mp, sockp, datlen) +bpf_movein(uio, linktype, mp, sockp, ifp) register struct uio *uio; - int linktype, *datlen; + int linktype; + struct ifnet *ifp; register struct mbuf **mp; register struct sockaddr *sockp; { @@ -209,11 +210,18 @@ bpf_movein(uio, linktype, mp, sockp, dat break; case DLT_RAW: - case DLT_NULL: sockp->sa_family = AF_UNSPEC; hlen = 0; break; + case DLT_NULL: + sockp->sa_family = AF_UNSPEC; + if(strcmp(ifp->if_name, "tun") == 0) + hlen = sizeof(int); + else + hlen = 0; + break; + #ifdef __FreeBSD__ case DLT_ATM_RFC1483: /* @@ -235,7 +243,10 @@ bpf_movein(uio, linktype, mp, sockp, dat } len = uio->uio_resid; - *datlen = len - hlen; + + if (len - hlen > ifp->if_mtu) + return (EMSGSIZE); + if ((unsigned)len > MCLBYTES) return (EIO); @@ -619,7 +630,6 @@ bpfwrite(dev, uio, ioflag) struct mbuf *m; int error, s; static struct sockaddr dst; - int datlen; if (d->bd_bif == 0) return (ENXIO); @@ -629,12 +639,9 @@ bpfwrite(dev, uio, ioflag) if (uio->uio_resid == 0) return (0); - error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, &m, &dst, &datlen); + error = bpf_movein(uio, (int)d->bd_bif->bif_dlt, &m, &dst, ifp); if (error) return (error); - - if (datlen > ifp->if_mtu) - return (EMSGSIZE); if (d->bd_hdrcmplt) dst.sa_family = pseudo_AF_HDRCMPLT; Index: if_tun.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_tun.c,v retrieving revision 1.74.2.8 diff -u -p -r1.74.2.8 if_tun.c --- if_tun.c 13 Feb 2002 00:43:11 -0000 1.74.2.8 +++ if_tun.c 6 Jun 2005 07:54:13 -0000 @@ -328,10 +328,8 @@ tunoutput(ifp, m0, dst, rt) /* BPF write needs to be handled specially */ if (dst->sa_family == AF_UNSPEC) { - dst->sa_family = *(mtod(m0, int *)); - m0->m_len -= sizeof(int); - m0->m_pkthdr.len -= sizeof(int); - m0->m_data += sizeof(int); + bcopy(dst->sa_data, &s, 4); + dst->sa_family = s; } if (ifp->if_bpf) { From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 11:01:51 2005 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 BFEFC16A43C for ; Mon, 6 Jun 2005 11:01:51 +0000 (GMT) (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 8202143D1F for ; Mon, 6 Jun 2005 11:01:51 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56B1pb0065627 for ; Mon, 6 Jun 2005 11:01:51 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56B1o3k065621 for freebsd-net@freebsd.org; Mon, 6 Jun 2005 11:01:50 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Jun 2005 11:01:50 GMT Message-Id: <200506061101.j56B1o3k065621@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter 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, 06 Jun 2005 11:01:52 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/05/19] ia64/81284 net Unaligned Reference with pf on 5.4/IA64 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 12:08:56 2005 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 8F1AA16A420 for ; Mon, 6 Jun 2005 12:08:56 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DCD443D5E for ; Mon, 6 Jun 2005 12:08:56 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D159765371; Mon, 6 Jun 2005 13:06:55 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 94191-03-2; Mon, 6 Jun 2005 13:06:55 +0100 (BST) Received: from empiric.dek.spc.org (host81-134-123-217.in-addr.btopenworld.com [81.134.123.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 52C1E65319; Mon, 6 Jun 2005 13:06:54 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id ACF336266; Mon, 6 Jun 2005 13:08:51 +0100 (BST) Date: Mon, 6 Jun 2005 13:08:51 +0100 From: Bruce M Simpson To: Matthew Luckie Message-ID: <20050606120851.GD734@empiric.icir.org> Mail-Followup-To: Matthew Luckie , freebsd-net@freebsd.org References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050606081637.GA73886@lycra.luckie.org.nz> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 06 Jun 2005 12:08:56 -0000 On Mon, Jun 06, 2005 at 08:16:38PM +1200, Matthew Luckie wrote: > If I was to pursue this, would someone on this list consider committing the > work to current? ... > + case DLT_NULL: > + sockp->sa_family = AF_UNSPEC; > + if(strcmp(ifp->if_name, "tun") == 0) > + hlen = sizeof(int); > + else > + hlen = 0; > + break; Maybe this won't work if an instance of tun is renamed? I'd compare "tun" with ifp->if_dname (driver name) to be on the safe side. Because tun instances allow their if_type to be set, one cannot use if_type as the sole key for determining if the ifnet is of type 'tun'; this would be ambiguous, as tun instances may have their if_type set by an ioctl. Another way of dealing with this would be to ask the tcpdump.org guys to define a DLT type for tun interfaces, rather than special-casing it for DLT_NULL. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 14:19:00 2005 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 C07E516A41C for ; Mon, 6 Jun 2005 14:19:00 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75EDD43D1F for ; Mon, 6 Jun 2005 14:19:00 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so2298744nzk for ; Mon, 06 Jun 2005 07:18:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UP0AcQkRPDOETW8Xs8ueH5/vhv67cnz3jYC6SVWJbh6SA1ssP/yXJVgCq75UW4wxn2aNOFcVpHBiv79uNG+/UZulkUmK978oDc6apWb1f5NStRgq7Wn1Df5HMTSRlrmygR44nxsUk8tnYnR5MTe+vg5hGPRNzv6/xGFlNds+umY= Received: by 10.36.129.6 with SMTP id b6mr548602nzd; Mon, 06 Jun 2005 07:18:57 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Mon, 6 Jun 2005 07:18:57 -0700 (PDT) Message-ID: <79722fad050606071818c24c6f@mail.gmail.com> Date: Mon, 6 Jun 2005 17:18:57 +0300 From: Vlad GALU To: freebsd-net@freebsd.org In-Reply-To: <20050606003519.52375.qmail@web15507.mail.cnb.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20050606003519.52375.qmail@web15507.mail.cnb.yahoo.com> Subject: Re: how to active the received function when the data arrived the socket in kld X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 14:19:00 -0000 T24gNi82LzA1LCBzaGluZXIgY2hlbiA8c2hpbmVyX2NoZW5AeWFob28uY29tLmNuPiB3cm90ZToK PiBJbm9yZGVyIHRvIGltcGxpbWVudCB0aGUgZHluYW1pYyBsb2FkIGZyZWViYWNrIHBvbGljeSAs SSB3cm90ZSBhIGtsZCBvbgo+IHRoZSBmcm9udC1lbmQgb2YgY2x1c3RlciBzZXJ2ZXIgZm9yIGNv bGxlY3RpbmcgdGhlIGxvYWQgb2YgIGJhY2sgbm9kZXMuCj4gSSBkb24ndCB3YW50IHRoZSBhY2Nl cHRpdmUgdGhyZWFkIHRvIGRldGVjdCB0aGUgZGF0YSBhcnJpdmVkIHNvY2tldAo+IGNvbnRpbnVv dXNseSxiZWNhdXNlICx3aGljaCB3aWxsIGFmZmVjdCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIGZy b250LWVuZC5pIHdhbnQgdG8ga25vdyB3aGV0aGVyIGkgY2FuIGFjdGl2ZSB0aGUgYWNjZXB0aXZl IHRocmVhZCB0byByZWNlaXZlIHRoZQo+IGRhdGEgd2hlbiB0aGUgZGF0YSBhcnJpdmUgdGhlIHNv Y2tldCBlc3RhYmxpc2hlZC4gaG93IHNodWxkIGkgZG8gaW4gdGhlCj4ga2VybmVsID8gdGhhbmtz ISEKPiAKIAogIElmIHlvdSdyZSB0YWxraW5nIGFib3V0IG5vbi1ibG9ja2luZyBhY2NlcHQoKSwg eW91IHNob3VsZCB1c2UKc2VsZWN0KCksIHBvbGwoKSBvciBrcXVldWUoKSBpbiB5b3VyIG1haW4g bG9vcC4gSWYgeW91IHdpc2ggbm90IHRvCmNyZWF0ZSBzdGF0ZSBmb3IgbmV3IHNvY2tldHMgdW5s ZXNzIHRoZXJlIGlzIGF2YWlsYWJsZSBpbi1iYW5kIGRhdGEsCnRha2UgYSBsb29rIGF0IGFjY2Zf ZGF0YSg5KS4KCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gRE8g WU9VIFlBSE9PIT8KPiAgILu2063KudPD0cW7orOstPPI3cG/w+K30dPKz+QKPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGZyZWVic2QtbmV0QGZyZWVi c2Qub3JnIG1haWxpbmcgbGlzdAo+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZyZWVic2QtbmV0Cj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZy ZWVic2QtbmV0LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgo+IAoKCi0tIApJZiBpdCdzIHRoZXJl LCBhbmQgeW91IGNhbiBzZWUgaXQsIGl0J3MgcmVhbC4KSWYgaXQncyBub3QgdGhlcmUsIGFuZCB5 b3UgY2FuIHNlZSBpdCwgaXQncyB2aXJ0dWFsLgpJZiBpdCdzIHRoZXJlLCBhbmQgeW91IGNhbid0 IHNlZSBpdCwgaXQncyB0cmFuc3BhcmVudC4KSWYgaXQncyBub3QgdGhlcmUsIGFuZCB5b3UgY2Fu J3Qgc2VlIGl0LCB5b3UgZXJhc2VkIGl0Lgo= From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 16:04:17 2005 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 5C8D916A484; Mon, 6 Jun 2005 16:04:17 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E4343D4C; Mon, 6 Jun 2005 16:04:17 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56G4HY2008422; Mon, 6 Jun 2005 16:04:17 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56G4HXj008418; Mon, 6 Jun 2005 16:04:17 GMT (envelope-from arved) Date: Mon, 6 Jun 2005 16:04:17 GMT From: Tilman Linneweh Message-Id: <200506061604.j56G4HXj008418@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored 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, 06 Jun 2005 16:04:17 -0000 Synopsis: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Mon Jun 6 16:03:57 GMT 2005 Responsible-Changed-Why: Over to freebsd-net Mailinglist for evaluation http://www.freebsd.org/cgi/query-pr.cgi?pr=81813 From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 17:20:04 2005 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 26CA816A41C for ; Mon, 6 Jun 2005 17:20:04 +0000 (GMT) (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 E21B343D48 for ; Mon, 6 Jun 2005 17:20:03 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56HK3D9020801 for ; Mon, 6 Jun 2005 17:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56HK3Hg020800; Mon, 6 Jun 2005 17:20:03 GMT (envelope-from gnats) Date: Mon, 6 Jun 2005 17:20:03 GMT Message-Id: <200506061720.j56HK3Hg020800@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Maxim Konovalov Cc: Subject: Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Konovalov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 17:20:04 -0000 The following reply was made to PR kern/81813; it has been noted by GNATS. From: Maxim Konovalov To: Dan Lukes Cc: bug-followup@freebsd.org, andre@freebsd.org Subject: Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored Date: Mon, 6 Jun 2005 21:19:03 +0400 (MSD) Hi Dan, We have a bit different code in HEAD and it seems for me it works correctly with zero icmp_nextmtu. All we need is to ask Andre to merge his work to RELENG_5. I'd prepare a patch if you have chance to test. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 17:33:40 2005 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 E430216A41C; Mon, 6 Jun 2005 17:33:40 +0000 (GMT) (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 AF99C43D1F; Mon, 6 Jun 2005 17:33:40 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56HXe7U023131; Mon, 6 Jun 2005 17:33:40 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56HXexw023127; Mon, 6 Jun 2005 17:33:40 GMT (envelope-from andre) Date: Mon, 6 Jun 2005 17:33:40 GMT From: Andre Oppermann Message-Id: <200506061733.j56HXexw023127@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Cc: Subject: Re: kern/81813: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored 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, 06 Jun 2005 17:33:41 -0000 Synopsis: [ PATCH ] ICMP_UNREACH_NEEDFRAG with unspecified icmp_nextmtu are ignored Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Mon Jun 6 17:32:39 GMT 2005 Responsible-Changed-Why: Take over. Patch just needs MFC. http://www.freebsd.org/cgi/query-pr.cgi?pr=81813 From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 17:38:24 2005 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 C6FF916A41C; Mon, 6 Jun 2005 17:38:24 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from mail.astra-sw.com (mail.astra-sw.com [82.140.87.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3261843D48; Mon, 6 Jun 2005 17:38:23 +0000 (GMT) (envelope-from Nickolay.Kritsky@astra-sw.com) Received: from exchange.stardevelopers4msi.com (exchange.stardevelopers4msi.com [10.1.2.201] (may be forged)) by mail.astra-sw.com (8.12.11/8.12.11) with ESMTP id j56HcLsa018451; Mon, 6 Jun 2005 21:38:21 +0400 (MSD) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jun 2005 21:38:38 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FREEBSD between two trunks Thread-Index: AcVpMW2rMXJCuRrfSjSsXL0PRh7iuABjI88A From: "Nickolay Kritsky" To: "John-Mark Gurney" , Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: RE: FREEBSD between two trunks 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, 06 Jun 2005 17:38:24 -0000 There was an old funny thing about bridging vlans: if you bridge vlanXX interfaces without bridging parents - do not forget to put parent in up and promiscuous mode. For 4.6 kernel it also required some patching. What version are you running? Nick -----Original Message----- From: John-Mark Gurney [mailto:gurney_j@resnet.uoregon.edu]=20 Sent: Saturday, June 04, 2005 10:15 PM To: sferreira@comcast.net Cc: freebsd-ipfw@freebsd.org; freebsd-net@freebsd.org Subject: Re: FREEBSD between two trunks sferreira@comcast.net wrote this message on Fri, Jun 03, 2005 at 20:44 +0000: > I'm trying to setup DUMMYNET to emulate long delays, such as those encountered in satellite links. The problem is that I have to place my freebsd host between two trunks passing vlans (2,3,4,5,6). >=20 > So the setup is: >=20 > cisco swictch trunks vlan 2,3,4,5,6 <-> freebsd <--> cisco switch trunks vlan 2,3,4,5,6 >=20 >=20 > All the documents I could find related to this subject matter has the freebsd as an endpoint and not connecting two trunks. Also the freebsd has to be an invisible hop on the network, so it can not route this traffic. I had setup my freebsd in bridge mode but I could not get this setup to work. You may need to increase your mtu to allow the full sized packets to pass through... or you could setup a vlan w/ and id that isn't used and let that adjust the mtu for you.. --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 18:23:54 2005 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 EA19616A41C; Mon, 6 Jun 2005 18:23:54 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 805C143D1F; Mon, 6 Jun 2005 18:23:54 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j56INgrw068998; Mon, 6 Jun 2005 11:23:42 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j56INdL7068997; Mon, 6 Jun 2005 11:23:39 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Jun 2005 11:23:39 -0700 From: John-Mark Gurney To: Nickolay Kritsky Message-ID: <20050606182338.GE655@funkthat.com> Mail-Followup-To: Nickolay Kritsky , sferreira@comcast.net, freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: sferreira@comcast.net, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: FREEBSD between two trunks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 18:23:55 -0000 Nickolay Kritsky wrote this message on Mon, Jun 06, 2005 at 21:38 +0400: > There was an old funny thing about bridging vlans: if you bridge vlanXX > interfaces without bridging parents - do not forget to put parent in up > and promiscuous mode. For 4.6 kernel it also required some patching. > What version are you running? What I was thinking he was going to due was not bridge the vlans themselves, but the two interfaces, and let dummynet handle the vlan packets just as any other normal packet.. He didn't say he needed each vlan to have a seperate delay or bandwidth limit.. I've never done any bridging of vlans, so I don't know the specifics.. I am using vlans so my firewall only has to have one interface.. :) It seems just setup the two interfaces to bridge, increase the mtu so that they accept the larger vlan packets, configure dummynet properly, and then route all packets through dummynet.. just my thoughts.. > -----Original Message----- > From: John-Mark Gurney [mailto:gurney_j@resnet.uoregon.edu] > Sent: Saturday, June 04, 2005 10:15 PM > To: sferreira@comcast.net > Cc: freebsd-ipfw@freebsd.org; freebsd-net@freebsd.org > Subject: Re: FREEBSD between two trunks > > sferreira@comcast.net wrote this message on Fri, Jun 03, 2005 at 20:44 > +0000: > > I'm trying to setup DUMMYNET to emulate long delays, such as those > encountered in satellite links. The problem is that I have to place my > freebsd host between two trunks passing vlans (2,3,4,5,6). > > > > So the setup is: > > > > cisco swictch trunks vlan 2,3,4,5,6 <-> freebsd <--> cisco switch > trunks vlan 2,3,4,5,6 > > > > > > All the documents I could find related to this subject matter has the > freebsd as an endpoint and not connecting two trunks. Also the freebsd > has to be an invisible hop on the network, so it can not route this > traffic. I had setup my freebsd in bridge mode but I could not get this > setup to work. > > You may need to increase your mtu to allow the full sized packets to > pass > through... or you could setup a vlan w/ and id that isn't used and let > that > adjust the mtu for you.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Jun 6 20:41:20 2005 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 30D1016A41C for ; Mon, 6 Jun 2005 20:41:20 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E24743D48 for ; Mon, 6 Jun 2005 20:41:18 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt14.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DfOPJ-0000Lo-00; Tue, 07 Jun 2005 08:41:13 +1200 Received: from mjl by lycra.luckie.org.nz with local (Exim 4.51 (FreeBSD)) id 1DfOOK-000Nna-Cd; Tue, 07 Jun 2005 08:40:12 +1200 Date: Tue, 7 Jun 2005 08:40:12 +1200 From: Matthew Luckie To: Bruce M Simpson Message-ID: <20050606204008.GA91353@lycra.luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050606120851.GD734@empiric.icir.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 06 Jun 2005 20:41:20 -0000 > > If I was to pursue this, would someone on this list consider committing the > > work to current? > ... > > + case DLT_NULL: > > + sockp->sa_family = AF_UNSPEC; > > + if(strcmp(ifp->if_name, "tun") == 0) > > + hlen = sizeof(int); > > + else > > + hlen = 0; > > + break; > > Maybe this won't work if an instance of tun is renamed? I'd compare "tun" > with ifp->if_dname (driver name) to be on the safe side. right. although the patch was against 4.11 which does not have if_dname. does 4.11 support renaming interfaces? it doesn't appear to. i wasn't really suggesting that we'd add a series of strcmp to see which driver corresponds to the DLT_NULL, just that if if_tun was handled specially then bpf writes would work correctly on it. > Another way of dealing with this would be to ask the tcpdump.org guys to > define a DLT type for tun interfaces, rather than special-casing it for > DLT_NULL. is there a good reason why _all_ DLT_NULL bpf devices could not simply have writes supported? the user space application would pass the address family in the first 4 bytes of the packet; this is currently done anyway for if_disc, if_loop, if_tun, if_faith, and ng_iface. ip_carp could get bpf writes for free with AF_UNSPEC added to the carp_looutput() switch statement. [mjl@mylar sys]$ egrep -r 'bpfattach.+DLT_NULL' * dev/iicbus/if_ic.c: bpfattach(ifp, DLT_NULL, ICHDRLEN); dev/ppbus/if_plip.c: bpfattach(ifp, DLT_NULL, sizeof(u_int32_t)); i4b/driver/i4b_ipr.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_disc.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); net/if_faith.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_gif.c: bpfattach(&sc->gif_if, DLT_NULL, sizeof(u_int)); net/if_gre.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); net/if_loop.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); net/if_stf.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); net/if_tun.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); netgraph/ng_iface.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); netgraph/ng_sppp.c: bpfattach (&pp->pp_if, DLT_NULL, sizeof(u_int)); netinet/ip_carp.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 09:37:21 2005 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 1044B16A41C for ; Tue, 7 Jun 2005 09:37:21 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44D0F43D1F for ; Tue, 7 Jun 2005 09:37:18 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 46C70856A7; Tue, 7 Jun 2005 19:07:17 +0930 (CST) Date: Tue, 7 Jun 2005 19:07:17 +0930 From: Greg 'groggy' Lehey To: FreeBSD-net@FreeBSD.org Message-ID: <20050607093717.GA76296@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Subject: Re: Problems with gif tunnels 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, 07 Jun 2005 09:37:21 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I posted this message to the -questions list an hour or so ago. Possibly it's of interest to people on this list. Certainly the problem is non-obvious, so even (as I suspect) if it's my fault, it would be interesting to document the problem. Greg ----- Forwarded message from Greg 'groggy' Lehey ----- > Date: Tue, 7 Jun 2005 17:56:14 +0930 > From: Greg 'groggy' Lehey > To: FreeBSD Questions > Subject: Problems with gif tunnels > > I've just installed an ADSL line, and I'm trying to route a class C > network. For some reason the ISP does this kind of routing via a GRE > tunnel, and I'm having the devil's own job getting it to work. Here's > the current situation: > > 1. ADSL line is up and running. I have a /30 with the following > addresses: > > 150.101.14.9 gateway address > 150.101.14.10 local address > > 2. To this line, I want to install a tunnel for 192.109.197.0/24. > The ISP tells me to set up a tunnel between the local address > (150.101.14.10) and their tunnel address 203.16.215.227. > According to recent (5.x) documentation, this should be done with: > > ifconfig gif0 tunnel 150.101.14.10 203.16.215.227 up > > 3. Obviously I also need to have IP forwarding enabled. > > So I do all this and get: > > xl0: flags=8843 mtu 1500 > options=9 > inet 192.109.197.143 netmask 0xffffff00 broadcast 192.109.197.255 > inet6 fe80::204:75ff:fefa:a80%xl0 prefixlen 64 scopeid 0x1 > ether 00:04:75:fa:0a:80 > media: Ethernet autoselect (10baseT/UTP) > status: active > rl0: flags=8843 mtu 1500 > options=8 > inet6 fe80::202:44ff:fe59:7076%rl0 prefixlen 64 scopeid 0x2 > inet 150.101.14.10 netmask 0xfffffffc broadcast 150.101.14.11 > ether 00:02:44:59:70:76 > media: Ethernet autoselect (10baseT/UTP) > status: active > gif0: flags=8051 mtu 1452 > tunnel inet 150.101.14.10 --> 203.16.215.227 > inet6 fe80::204:75ff:fefa:a80%gif0 prefixlen 64 scopeid 0x5 > > Destination Gateway Flags Refs Use Netif Expire > default 150.101.14.9 UGS 0 7 rl0 > 150.101.14.8/30 link#2 UC 0 0 rl0 > 150.101.14.9 00:90:1a:40:09:98 UHLW 2 2 rl0 903 > 192.109.197 link#1 UC 0 0 xl0 > 192.109.197.135 00:10:4b:66:1e:e9 UHLW 0 6757 xl0 1056 > 192.109.197.137 00:50:da:cf:07:35 UHLW 0 99336 xl0 1188 > 192.109.197.255 ff:ff:ff:ff:ff:ff UHLWb 0 34521 xl0 > 203.16.215.227 150.101.14.9 UGHS 1 4 rl0 > > net.inet.ip.forwarding: 1 > > I then get somebody from the other end to ping me: > > 17:49:10.228597 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6908 > 17:49:11.229188 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6909 > > But that's all. Nothing goes out. I've tried this on different > systems, and I know somebody else who is using what looks like an > identical configuration with this ISP, and it works fine. I've tried > different systems, one and two NICs, 4.x and 5.x, all with the same > (non)result. What am I missing? > > Greg > -- > The virus contained in this message was not detected. > > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original recipients. > For more information, see http://www.lemis.com/questions.html > > Finger grog@FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. ----- End forwarded message ----- -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCpWrNIubykFB6QiMRAnV0AJ9NuehKLb6BySLK3wHx8ZUelXTEogCdEvhV Ny5EqOnThlqd60s20TE3Lyg= =t1/p -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 09:48:51 2005 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 5FDC116A41C; Tue, 7 Jun 2005 09:48:51 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC8443D48; Tue, 7 Jun 2005 09:48:50 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id E0A731F0B2; Tue, 7 Jun 2005 11:48:48 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id BE21361CA; Tue, 7 Jun 2005 11:48:48 +0200 (CEST) Date: Tue, 7 Jun 2005 11:48:48 +0200 From: Marc Olzheim To: Greg 'groggy' Lehey Message-ID: <20050607094848.GB16223@stack.nl> References: <20050607093717.GA76296@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <20050607093717.GA76296@wantadilla.lemis.com> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: FreeBSD-net@FreeBSD.org Subject: Re: Problems with gif tunnels 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, 07 Jun 2005 09:48:51 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 07, 2005 at 07:07:17PM +0930, Greg 'groggy' Lehey wrote: > I posted this message to the -questions list an hour or so ago. > Possibly it's of interest to people on this list. Certainly the > problem is non-obvious, so even (as I suspect) if it's my fault, it > would be interesting to document the problem. The interface on the default route is rl0 instead of gif0... Could you try with -interface gif0 ? Probably you added the route before the gif0 was brought up ? Marc --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCpW2AezjnobFOgrERAq9CAJ4teL0nchBDtenU7yadopfIYcEEnACgyv54 Xzvn60h8NZ8QUxX2AGA+6qY= =K0Im -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 10:10:14 2005 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 2C12D16A41C; Tue, 7 Jun 2005 10:10:14 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6EA043D1D; Tue, 7 Jun 2005 10:10:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id A27FC317DDF; Tue, 7 Jun 2005 12:10:12 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id CE467407E; Tue, 7 Jun 2005 12:09:58 +0200 (CEST) Date: Tue, 7 Jun 2005 12:09:58 +0200 From: Jeremie Le Hen To: Greg 'groggy' Lehey Message-ID: <20050607100958.GU41050@obiwan.tataz.chchile.org> References: <20050607093717.GA76296@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050607093717.GA76296@wantadilla.lemis.com> User-Agent: Mutt/1.5.9i Cc: FreeBSD-net@FreeBSD.org Subject: Re: Problems with gif tunnels 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, 07 Jun 2005 10:10:14 -0000 Hi Greg, > > Destination Gateway Flags Refs Use Netif Expire > > default 150.101.14.9 UGS 0 7 rl0 > > 150.101.14.8/30 link#2 UC 0 0 rl0 > > 150.101.14.9 00:90:1a:40:09:98 UHLW 2 2 rl0 903 > > 192.109.197 link#1 UC 0 0 xl0 > > 192.109.197.135 00:10:4b:66:1e:e9 UHLW 0 6757 xl0 1056 > > 192.109.197.137 00:50:da:cf:07:35 UHLW 0 99336 xl0 1188 > > 192.109.197.255 ff:ff:ff:ff:ff:ff UHLWb 0 34521 xl0 > > 203.16.215.227 150.101.14.9 UGHS 1 4 rl0 I guess you need a route to something like 192.83.231.0/24 through gif0. Try %%% route add -host 192.83.231.16 -interface gif0 %%% > > I then get somebody from the other end to ping me: > > > > 17:49:10.228597 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6908 > > 17:49:11.229188 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6909 > > > > But that's all. Nothing goes out. I've tried this on different > > systems, and I know somebody else who is using what looks like an > > identical configuration with this ISP, and it works fine. I've tried > > different systems, one and two NICs, 4.x and 5.x, all with the same > > (non)result. What am I missing? It would be worth knowing if the ICMP packet goes out from your ``internal'' interface (xl0). In this case, you should also see the ICMP echo-reply. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 10:20:41 2005 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 5218F16A41C for ; Tue, 7 Jun 2005 10:20:41 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt11.ihug.co.nz (grunt11.ihug.co.nz [203.109.254.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB73443D49 for ; Tue, 7 Jun 2005 10:20:36 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt11.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DfbC9-0006M9-00; Tue, 07 Jun 2005 22:20:29 +1200 Received: from mjl by lycra.luckie.org.nz with local (Exim 4.51 (FreeBSD)) id 1DfbBB-000Pmh-8Y; Tue, 07 Jun 2005 22:19:29 +1200 Date: Tue, 7 Jun 2005 22:19:29 +1200 From: Matthew Luckie To: freebsd-net@freebsd.org Message-ID: <20050607101927.GA99034@lycra.luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050606204008.GA91353@lycra.luckie.org.nz> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: bpf writes on tun device 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, 07 Jun 2005 10:20:41 -0000 > is there a good reason why _all_ DLT_NULL bpf devices could not simply > have writes supported? the user space application would pass the > address family in the first 4 bytes of the packet; this is currently > done anyway for if_disc, if_loop, if_tun, if_faith, and ng_iface. > ip_carp could get bpf writes for free with AF_UNSPEC added to the > carp_looutput() switch statement. http://www.wand.net.nz/~mjl12/freebsd-current-dlt_null-write.diff I spent some time going through all drivers in -current that export DLT_NULL bpf devices that may support writing raw packets using BPF. I did this by running egrep -r 'bpfattach.+DLT_NULL' * which corresponded to the following drivers: sys/net/if_disc.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); sys/net/if_faith.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); sys/net/if_gif.c: bpfattach(&sc->gif_if, DLT_NULL, sizeof(u_int)); sys/net/if_gre.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); sys/net/if_loop.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); sys/net/if_stf.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); sys/net/if_tun.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); sys/netgraph/ng_iface.c: bpfattach(ifp, DLT_NULL, sizeof(u_int)); sys/netgraph/ng_sppp.c: bpfattach (&pp->pp_if, DLT_NULL, sizeof(u_int)); sys/dev/iicbus/if_ic.c: bpfattach(ifp, DLT_NULL, ICHDRLEN); sys/dev/ppbus/if_plip.c: bpfattach(ifp, DLT_NULL, sizeof(u_int32_t)); sys/i4b/driver/i4b_ipr.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); sys/netinet/ip_carp.c: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int32_t)); BPF writes were already supported (for packets up to 4 bytes less than the IP MTU of the interface) for the following drivers: - if_disc - if_faith - if_gif - if_gre - if_loop - if_tun - ng_iface I went through and altered the way BPF writes are handled in these drivers. The code was basically changed as follows: /* BPF write needs to be handled specially */ if (dst->sa_family == AF_UNSPEC) { - dst->sa_family = *(mtod(m0, int *)); - m0->m_len -= sizeof(int); - m0->m_pkthdr.len -= sizeof(int); - m0->m_data += sizeof(int); + bcopy(dst->sa_data, &af, sizeof(af)); + dst->sa_family = af; } The exception is if_loop.c, where the bpf write handling was in a weird place. BPF write was checked in if_simloop, rather than looutput. However, anything supplying if_simloop a packet to write is not a DLT_NULL BPF device, unless it is looutput. So I shifted the BPF write check to looutput. Otherwise, i added BPF write support to the remaining drivers (if_stf, if_ic, if_plip, i4b_ipr.c, and ip_carp.c). I did not determine how to include the appropriate bpf write code in ng_sppp.c - it does not appear to require it. Please review. Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 11:23:46 2005 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 730EE16A41C for ; Tue, 7 Jun 2005 11:23:46 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1835943D48 for ; Tue, 7 Jun 2005 11:23:45 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E92F165371; Tue, 7 Jun 2005 12:21:43 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07309-01-3; Tue, 7 Jun 2005 12:21:43 +0100 (BST) Received: from empiric.dek.spc.org (host81-134-123-217.in-addr.btopenworld.com [81.134.123.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 18C18651EB; Tue, 7 Jun 2005 12:21:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E4F4E640F; Tue, 7 Jun 2005 12:23:40 +0100 (BST) Date: Tue, 7 Jun 2005 12:23:40 +0100 From: Bruce M Simpson To: Matthew Luckie Message-ID: <20050607112340.GC812@empiric.icir.org> Mail-Followup-To: Matthew Luckie , freebsd-net@freebsd.org References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050607101927.GA99034@lycra.luckie.org.nz> Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 07 Jun 2005 11:23:46 -0000 On Tue, Jun 07, 2005 at 10:19:29PM +1200, Matthew Luckie wrote: > Please review. This is good and useful work. It looks like something which has been in need of cleanup for a while. Unfortunately my current situation re resources (time and infrastructure) means that whilst I can review and commit code it's difficult for me to test it (unless it's userland) hopefully this will improve in the next week or two. I'd be wary of changing the definition of DLT_NULL however -- it literally means 'there's nothing here apart from raw data', and changing this notion would mean that we have to change it everywhere, including bpf clients, because the change being proposed would make DLT_NULL mean 'there's a 32-bit integer in front of everything else which is raw data', which is something else. I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to get review for the change from the NetBSD and OpenBSD guys too, as well as the tcpdump.org guys. Looking at style, it might be better if the driver(s) were changed to explicitly use a 32-bit wide int type such as u_int32_t for the address family header field in their bpfattach() calls. ICHDRLEN is odd man out, but it is #define'd to be the same thing; I would update it there also. A white space pass should probably also be done last thing to be sure. I have no idea about ng_sppp.c I'm afraid. It helps my dayjob because we're currently looking at what it would take to integrate a code drop of the IS-IS routing protocol by one of our students -- unfortunately to remain backwards compatible with existing IS-IS deployments out there, we need to be able to speak link layer IS-IS as well as IPv4 encapsulated IS-IS. Of course to do this, we need bpf write support for the appropriate link layers. The more link layers we have support for bpf writes, particularly across the software loopback and tunnel type links, the better it is for testing and integration, as well as running IS-IS directly over a VPN on FreeBSD. Thanks, BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 13:35:51 2005 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 5A7CE16A41C for ; Tue, 7 Jun 2005 13:35:51 +0000 (GMT) (envelope-from olivier_casasole@yahoo.fr) Received: from web26502.mail.ukl.yahoo.com (web26502.mail.ukl.yahoo.com [217.146.176.39]) by mx1.FreeBSD.org (Postfix) with SMTP id B44A443D4C for ; Tue, 7 Jun 2005 13:35:50 +0000 (GMT) (envelope-from olivier_casasole@yahoo.fr) Received: (qmail 72646 invoked by uid 60001); 7 Jun 2005 13:35:49 -0000 Message-ID: <20050607133549.72644.qmail@web26502.mail.ukl.yahoo.com> Received: from [137.73.11.190] by web26502.mail.ukl.yahoo.com via HTTP; Tue, 07 Jun 2005 15:35:49 CEST Date: Tue, 7 Jun 2005 15:35:49 +0200 (CEST) From: Olivier Casasole To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: installation 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, 07 Jun 2005 13:35:51 -0000 Hi, I am trying to install Freebsd 5.3 on a station which has both Pentium and Celeron. I put the boot floppy and Kernel 1 and 2. Then, my system was stuck. I obtained something like that: APIC: Using the MADT enumerator MADT: Found CPU ID 0 ACPI ID 1: enabled MADT: Found CPU ID 0 ACPI ID 1: enabled Any idea what it means? thanks, Olivier _____________________________________________________________________________ Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 14:12:34 2005 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 9259516A41C for ; Tue, 7 Jun 2005 14:12:34 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31DC443D1D for ; Tue, 7 Jun 2005 14:12:34 +0000 (GMT) (envelope-from richardtector@thekeelecentre.com) Received: from av.mx0.thekeelecentre.com (av.mx0.thekeelecentre.com [217.206.238.166]) by mx0.thekeelecentre.com (Postfix) with ESMTP id AD821429E; Tue, 7 Jun 2005 15:12:32 +0100 (BST) Received: from mx0.thekeelecentre.com ([217.206.238.167]) by av.mx0.thekeelecentre.com (av.mx0.thekeelecentre.com [217.206.238.166]) (amavisd-new, port 10024) with ESMTP id 03418-10; Tue, 7 Jun 2005 15:12:32 +0100 (BST) Received: from [217.206.238.190] (host-190.thekeelecentre.com [217.206.238.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTP id 74F254099; Tue, 7 Jun 2005 15:12:32 +0100 (BST) Message-ID: <42A5AB53.4010101@thekeelecentre.com> Date: Tue, 07 Jun 2005 15:12:35 +0100 From: Richard Tector User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Olivier Casasole References: <20050607133549.72644.qmail@web26502.mail.ukl.yahoo.com> In-Reply-To: <20050607133549.72644.qmail@web26502.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Cc: freebsd-net@freebsd.org Subject: Re: installation 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, 07 Jun 2005 14:12:34 -0000 Olivier Casasole wrote: >I am trying to install Freebsd 5.3 on a station which >has both Pentium and Celeron. > > Are you saying that you are using both processors in the same machine? If so, that is unsupported. You need two identical processors. >I put the boot floppy and Kernel 1 and 2. >Then, my system was stuck. >I obtained something like that: > >APIC: Using the MADT enumerator >MADT: Found CPU ID 0 ACPI ID 1: enabled >MADT: Found CPU ID 0 ACPI ID 1: enabled > > Kind regards, Richard Tector From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 15:27:40 2005 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 E3F0716A420 for ; Tue, 7 Jun 2005 15:27:40 +0000 (GMT) (envelope-from christian@kuhtz.com) Received: from athenaeum.kuhtz.com (athenaeum.kuhtz.com [68.16.106.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F05743D5E for ; Tue, 7 Jun 2005 15:27:40 +0000 (GMT) (envelope-from christian@kuhtz.com) Received: by athenaeum.kuhtz.com (Postfix, from userid 507) id 0558290C013; Tue, 7 Jun 2005 11:27:39 -0400 (EDT) Received: from [192.168.100.233] (sntlabfw [205.152.56.163]) by athenaeum.kuhtz.com (Postfix) with ESMTP id BD6BA90C00C for ; Tue, 7 Jun 2005 11:27:38 -0400 (EDT) Message-ID: <42A5BCEB.8020109@kuhtz.com> Date: Tue, 07 Jun 2005 11:27:39 -0400 From: Christian Kuhtz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on athenaeum.kuhtz.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=4.9 tests=AWL autolearn=ham version=3.0.3 Subject: divert sock api q 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, 07 Jun 2005 15:27:41 -0000 Hello, I'm using the DIVERT socket API for a proof of concept lab setup here, and I could use some help.. Two boxes are involved, packets traverse both in series. The first one, lets call her A, is taking the UDP packet off the wire, inserts a few bytes after the UDP header, and sticks it back on the wire. The second machine, lets call her B, grabs the packet as it comes in, strips the bytes we inserted, and sticks it back on the wire. Or so goes the theory. What I'm running into is the following.. When I sendto() the modified frame on A, the size is correctly reported as what the frame was modified to be. When the frame arrives on B, I only recvfrom() as many bytes as the virgin packet used to be when it entered A prior to the modification. Anyone have any idea what's going on here and how to fix this length mismatch? I thought the API updates the length when the frame is sent, and sendto() does report the correct length.. I apologize for being so exceptionally dense, this is driving me completely up the walls.. Regards, Christian From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 17:14:06 2005 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 79D4C16A41C for ; Tue, 7 Jun 2005 17:14:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4838543D5C for ; Tue, 7 Jun 2005 17:14:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 1D3CA7A403; Tue, 7 Jun 2005 10:14:06 -0700 (PDT) Message-ID: <42A5D5DE.2010407@elischer.org> Date: Tue, 07 Jun 2005 10:14:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Christian Kuhtz References: <42A5BCEB.8020109@kuhtz.com> In-Reply-To: <42A5BCEB.8020109@kuhtz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 17:14:06 -0000 Christian Kuhtz wrote: > > Hello, > > I'm using the DIVERT socket API for a proof of concept lab setup here, > and I could use some help.. > > Two boxes are involved, packets traverse both in series. The first > one, lets call her A, is taking the UDP packet off the wire, inserts a > few bytes after the UDP header, and sticks it back on the wire. The > second machine, lets call her B, grabs the packet as it comes in, > strips the bytes we inserted, and sticks it back on the wire. > > Or so goes the theory. > > What I'm running into is the following.. When I sendto() the modified > frame on A, the size is correctly reported as what the frame was > modified to be. When the frame arrives on B, I only recvfrom() as > many bytes as the virgin packet used to be when it entered A prior to > the modification. > > Anyone have any idea what's going on here and how to fix this length > mismatch? I thought the API updates the length when the frame is > sent, and sendto() does report the correct length.. > > I apologize for being so exceptionally dense, this is driving me > completely up the walls.. if you are receiving the entire IP packet in user space (first byte is 0x42 or 0x45 usually) then you need to update teh packet length field of the IP packet, as well as changing the number of bytes written back. > > Regards, > Christian > > _______________________________________________ > 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 Jun 7 17:41:31 2005 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 DB4D516A41C for ; Tue, 7 Jun 2005 17:41:30 +0000 (GMT) (envelope-from joel@starman.ee) Received: from mx1.starman.ee (smtp-out.starman.ee [85.253.0.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5576643D4C for ; Tue, 7 Jun 2005 17:41:29 +0000 (GMT) (envelope-from joel@starman.ee) Received: from barton (ip110.cab14.ktln.starman.ee [82.131.14.110]) by mx1.starman.ee (Postfix) with ESMTP id E629319340A for ; Tue, 7 Jun 2005 20:40:23 +0300 (EEST) From: "Joel V." To: Date: Tue, 7 Jun 2005 20:42:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVriD9c4XWMVxdASKyIMi+UESvd+g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050607174023.E629319340A@mx1.starman.ee> X-Virus-Scanned: by Amavisd-New at mx1.starman.ee Subject: Welcome to networking hell - ssh, samba, apache and the dreaded CLOSED_WAIT 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, 07 Jun 2005 17:41:31 -0000 First of all, I want to thank everyone in advance who decide to help me. THANK YOU! Now, here's some background info: I have a P4 2.4 server with 512mb of RAM and 160GB hdd. There are two intel NICs, 192.168.0.254 and 82.131.xxx.xx The box is running FreeBSD 4.8 and it's behind a fast 5mbit line. Services running on the server are gateway/NAT, DNS, default "open" firewall, Samba (I think 2.2.8), Qmail + vpopmail, proftpd, apache 1.3.27 + php, MySQL. There are 7 computers with WinXP SP1 in the office and 2 computers with Win2k SP4. Yesterday I got a call from the office saying there are some problems with getting and sending e-mail. I go sit behind one WinXP machine, and I can't send/receive mail at all with Outlook XP. All transfers are timing out. I try to access Samba shares, and I have to wait 1-2min before I can see them. Now once I access them, they're all fast for a short period of time, after a while it goes slow again. Then I try to see our homepage which is hosted at our server and guess what - it takes 3-4min to load it. But.. accessing other sites is fine. The internet in general is working like a charm from all machines! Now here's the funny thing. Both Win2k machines can access the Samba shares OK without any lag (but our website still comes on slow). I go to the server and shut down all services except for Samba. Voila! I can access the server shares again with (a bit worse than) usual 1-2 sec delay. Now I open up e-mail account settings and notice that the incoming server is 192.168.0.254 - I change that to mail.xxxxxx.ee (our mailserver) just to test it and everything is OK again. Now, when I launch apache, try to view our site from within the LAN and send/receive e-mail, I get timeouts again. Shut down apache and it's working. Now here's another thing I haven't mentioned. I can't also use ssh inside our office. When I enter the username when connecting to the server it just times out without asking me for a password (only ONCE did I see a password prompt but it was too late, the timeout had already occured). I have to connect to another server I have running, and then connect from there. ARP data seems to be OK, but netstat showed some odd states for some connections when I was trying to access our homepage - CLOSED_WAIT. I've tried restarting the services, restarting the server, restarting the switch and our workstations - nothing. Inside our office it's networking hell when Apache is running (and ssh hell even when Apache is not running). There is enough room on all partitions, I checked all the logs and didn't notice anything strange. When I connect from home, everything is working as it should - ssh, e-mail, ftp, you name it. Did I mention I haven't changed any configuration settings for a long time and the server has been running for 2 years almost without any problems? I've shut down apache and moved our homepage to my friend's server, and everything seems to be working for now. But I have to get this thing fixed and to be honest with, I have no more ideas what to try. Here's where I need your help. Thanks again. I am not a member of the mailing list, so I would be very grateful if you could send me a response directly at joel@starman.ee - thanks! - Joel From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 19:46:13 2005 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 9AE0216A41F for ; Tue, 7 Jun 2005 19:46:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E35743D55 for ; Tue, 7 Jun 2005 19:46:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id j57JkAIU023943; Tue, 7 Jun 2005 12:46:10 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j57Jk5tO026126; Tue, 7 Jun 2005 12:46:07 -0700 (PDT) In-Reply-To: <42A5D5DE.2010407@elischer.org> References: <42A5BCEB.8020109@kuhtz.com> <42A5D5DE.2010407@elischer.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 15:46:03 -0400 To: Julian Elischer X-Mailer: Apple Mail (2.730) Cc: Christian Kuhtz , freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 19:46:13 -0000 On Jun 7, 2005, at 1:14 PM, Julian Elischer wrote: >> I apologize for being so exceptionally dense, this is driving me >> completely up the walls.. > > if you are receiving the entire IP packet in user space (first byte > is 0x42 or 0x45 usually) then you need to update teh packet length > field of the IP packet, as well as changing the number of bytes > written back. I agree with your suggestion, but how can you have an ip_vhl of 0x42? Doesn't a valid IP packet need to have a header length of at least 5 (5 << 2 == 20 bytes)? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 19:54:37 2005 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 8292B16A41C for ; Tue, 7 Jun 2005 19:54:37 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt2.ihug.co.nz (grunt2.ihug.co.nz [203.109.254.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF02943D5D for ; Tue, 7 Jun 2005 19:54:36 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt2.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1Dfk9f-0007QB-00; Wed, 08 Jun 2005 07:54:32 +1200 Received: from 203-173-146-91.bliink.ihug.co.nz ([203.173.146.91] helo=[192.168.1.6]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1Dfk8h-0003pF-58; Wed, 08 Jun 2005 07:53:31 +1200 Message-ID: <42A5FB72.4010603@luckie.org.nz> Date: Wed, 08 Jun 2005 07:54:26 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> In-Reply-To: <20050607112340.GC812@empiric.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 07 Jun 2005 19:54:37 -0000 > I'd be wary of changing the definition of DLT_NULL however -- it literally > means 'there's nothing here apart from raw data', and changing this notion > would mean that we have to change it everywhere, including bpf clients, > because the change being proposed would make DLT_NULL mean 'there's a 32-bit > integer in front of everything else which is raw data', which is something > else. this was the behaviour expected of most DLT_NULL bpf devices already (passing a 32bit int when writing). It is important to note that the behaviour of BPF writers does not change in these cases, and my patch is merely a bug fix. the other interface output functions probably did not work with BPF, as bpfwrite was passing the sockaddr dst structure with dst->sa_family == AF_UNPSEC, which would have caused most of the rest to return EAFNOTSUPPORTED or whatever. I think the exceptions to this are if_stf and if_ic, but i'm not sure how many bpf writers in the wild this patch would affect; i am not aware how many people actually use these interfaces. > I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to > get review for the change from the NetBSD and OpenBSD guys too, as well as > the tcpdump.org guys. i will pursue the review with other BSD systems. this is something important to me, and something i'd like to see fixed. but my argument is going to be for DLT_NULL for the reasons above. > Looking at style, it might be better if the driver(s) were changed to > explicitly use a 32-bit wide int type such as u_int32_t for the address > family header field in their bpfattach() calls. ICHDRLEN is odd man out, > but it is #define'd to be the same thing; I would update it there also. the last parameter to bpfattach specifies the size of the psuedo header attached on bpf rx; that's a separate thing to fix, but one that does need to be made self-consistent. > It helps my dayjob because we're currently looking at what it would take to > integrate a code drop of the IS-IS routing protocol by one of our students -- > unfortunately to remain backwards compatible with existing IS-IS deployments > out there, we need to be able to speak link layer IS-IS as well as IPv4 > encapsulated IS-IS. > > Of course to do this, we need bpf write support for the appropriate link > layers. The more link layers we have support for bpf writes, particularly > across the software loopback and tunnel type links, the better it is for > testing and integration, as well as running IS-IS directly over a VPN > on FreeBSD. My situation is related to work i'm doing with ports/net/scamper, which needs to have some probe packets passed without interference by the IP stack to the wire. I'll see if I can get consensus with NetBSD / OpenBSD / Darwin / tcpdump-workers. Thanks. Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 20:47:12 2005 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 C279716A41C for ; Tue, 7 Jun 2005 20:47:12 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C9FC43D5D for ; Tue, 7 Jun 2005 20:47:12 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id j57KlAGI006168; Tue, 7 Jun 2005 13:47:10 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j57Kl5hg023792; Tue, 7 Jun 2005 13:47:06 -0700 (PDT) In-Reply-To: <42A5FB72.4010603@luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> <42A5FB72.4010603@luckie.org.nz> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 16:47:02 -0400 To: Matthew Luckie X-Mailer: Apple Mail (2.730) Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 07 Jun 2005 20:47:13 -0000 On Jun 7, 2005, at 3:54 PM, Matthew Luckie wrote: >> I'd be wary of changing the definition of DLT_NULL however -- it >> literally >> means 'there's nothing here apart from raw data', and changing >> this notion >> would mean that we have to change it everywhere, including bpf >> clients, >> because the change being proposed would make DLT_NULL mean >> 'there's a 32-bit >> integer in front of everything else which is raw data', which is >> something >> else. > > this was the behaviour expected of most DLT_NULL bpf devices > already (passing a 32bit int when writing). It is important to > note that the behaviour of BPF writers does not change in these > cases, and my patch is merely a bug fix. Agreed. When you use BPF or PCAP to capture packets, for the DTL_NULL case there is a 4-byte offset between where PCAP says the packet starts and where the actual raw IP packet starts. If you want BPF/PCAP to return packets without the 4-byte offset, the associated datalink type is actually called DLT_RAW. Note that the behavior of DLT_NULL is useful in practice, since you can find out what the "ether type" of the packet was per : #define ETHERTYPE_IP 0x0800 /* IP protocol */ #define ETHERTYPE_ARP 0x0806 /* Addr. resolution protocol */ #define ETHERTYPE_REVARP 0x8035 /* reverse Addr. resolution protocol */ #define ETHERTYPE_VLAN 0x8100 /* IEEE 802.1Q VLAN tagging */ #define ETHERTYPE_IPV6 0x86dd /* IPv6 */ #define ETHERTYPE_LOOPBACK 0x9000 /* used to test interfaces */ ...to distinguish between IPv4, IPv6, ARP traffic, and so forth. I've written some code that needed to do packet capture and run on a range of platforms-- FreeBSD, NetBSD, Linux, Darwin, Solaris. I haven't tested all of the datalink types, so I won't promise that the offsets below are entirely correct, but this might still be helpful: /* some platforms define ETHER_HDR_LEN, but not all of them do */ #define DLH_EN (14) int datalink_offset(int dltype) { switch (dltype) { case DLT_NULL: return 4; case DLT_EN10MB: return DLH_EN; case DLT_IEEE802: return 22; case DLT_ARCNET: return 4; /* not sure */ case DLT_SLIP: return 16; case DLT_PPP: return 24; case DLT_FDDI: return 21; case DLT_ATM_RFC1483: return 8; /* not sure */ case DLT_RAW: return 0; #if !defined(__NetBSD__) case DLT_LOOP: return 4; case DLT_LINUX_SLL: return 16; #endif default: logwarn("unknown/unsupported PCAP datalink type\n"); return 0; } } -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 20:56:44 2005 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 95D7C16A41C for ; Tue, 7 Jun 2005 20:56:44 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35A5043D1F for ; Tue, 7 Jun 2005 20:56:43 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt14.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1Dfl7q-0006gz-00; Wed, 08 Jun 2005 08:56:42 +1200 Received: from 203-173-146-91.bliink.ihug.co.nz ([203.173.146.91] helo=[192.168.1.6]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1Dfl6r-00043M-G8; Wed, 08 Jun 2005 08:55:41 +1200 Message-ID: <42A60A03.2000101@luckie.org.nz> Date: Wed, 08 Jun 2005 08:56:35 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Swiger References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> <42A5FB72.4010603@luckie.org.nz> <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> In-Reply-To: <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 07 Jun 2005 20:56:44 -0000 >> this was the behaviour expected of most DLT_NULL bpf devices already >> (passing a 32bit int when writing). It is important to note that the >> behaviour of BPF writers does not change in these cases, and my patch >> is merely a bug fix. > > Agreed. When you use BPF or PCAP to capture packets, for the DTL_NULL > case there is a 4-byte offset between where PCAP says the packet starts > and where the actual raw IP packet starts. > > If you want BPF/PCAP to return packets without the 4-byte offset, the > associated datalink type is actually called DLT_RAW. Note that the > behavior of DLT_NULL is useful in practice, since you can find out what > the "ether type" of the packet was per : unless i'm mistaken, the 4 byte field is actually the address family of the packet. so AF_INET, AF_INET6, etc. the ethertype thing is for DLT_EN10MB devices. Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 21:29:28 2005 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 D038C16A41C for ; Tue, 7 Jun 2005 21:29:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97F6743D55 for ; Tue, 7 Jun 2005 21:29:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 2F6E57A403; Tue, 7 Jun 2005 14:29:28 -0700 (PDT) Message-ID: <42A611B8.7040102@elischer.org> Date: Tue, 07 Jun 2005 14:29:28 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Charles Swiger References: <42A5BCEB.8020109@kuhtz.com> <42A5D5DE.2010407@elischer.org> <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> In-Reply-To: <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christian Kuhtz , freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 21:29:28 -0000 Charles Swiger wrote: > On Jun 7, 2005, at 1:14 PM, Julian Elischer wrote: > >>> I apologize for being so exceptionally dense, this is driving me >>> completely up the walls.. >> >> >> if you are receiving the entire IP packet in user space (first byte >> is 0x42 or 0x45 usually) then you need to update teh packet length >> field of the IP packet, as well as changing the number of bytes >> written back. > > > I agree with your suggestion, but how can you have an ip_vhl of > 0x42? Doesn't a valid IP packet need to have a header length of at > least 5 (5 << 2 == 20 bytes)? > huh? the first byte of an IP packet is not the length.. the first byte you see on a packet trace will be the 4 bit version followed by a 4 bit HEADER length, followed by 8 bits of TOS (type of Service) and 16 bits of total packet length. you need to change the 16 bit value.. (it's in big-endian format.. beware) From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 21:36:08 2005 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 3415B16A41C for ; Tue, 7 Jun 2005 21:36:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7D1143D5D for ; Tue, 7 Jun 2005 21:36:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id j57La6Re021100; Tue, 7 Jun 2005 14:36:07 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j57La46V013163; Tue, 7 Jun 2005 14:36:05 -0700 (PDT) In-Reply-To: <42A60A03.2000101@luckie.org.nz> References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> <42A5FB72.4010603@luckie.org.nz> <43393A5D-A13B-4385-A6E3-EDD21343277A@mac.com> <42A60A03.2000101@luckie.org.nz> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C52F579-B9E9-43DF-A169-561209DA010B@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 17:36:02 -0400 To: Matthew Luckie X-Mailer: Apple Mail (2.730) Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 07 Jun 2005 21:36:08 -0000 On Jun 7, 2005, at 4:56 PM, Matthew Luckie wrote: >> Agreed. When you use BPF or PCAP to capture packets, for the >> DTL_NULL case there is a 4-byte offset between where PCAP says >> the packet starts and where the actual raw IP packet starts. >> If you want BPF/PCAP to return packets without the 4-byte offset, >> the associated datalink type is actually called DLT_RAW. Note >> that the behavior of DLT_NULL is useful in practice, since you >> can find out what the "ether type" of the packet was per > ethernet.h>: > > unless i'm mistaken, the 4 byte field is actually the address > family of the packet. so AF_INET, AF_INET6, etc. the ethertype > thing is for DLT_EN10MB devices. If you're trying to write traffic using socket(), sure, you might very well specify AF_INET as the first argument (domain), but the machine doesn't actually put the value of the address family into the link-level header of the packet that goes out across the wire. I agree that the ethertype thing is supposed to be for ethernet-style devices, but try sending some traffic over lo0, and capture it, and take a look at the first four bytes. Maybe I'm confused, but I remember seeing 0x0800 and 0x86dd, respectively, not 0x2 (AF_INET) or 30 (AF_INET6). When writing packets, I found that even using SOCK_RAW the kernel would fill in a lot of stuff that I didn't want it to, and instead I needed to talk with BPF directly or use something like libnet to build the packets. I am pretty sure this is why the ISC DHCP software depends on BPF, because it can't generate ARPOP_REQUESTS and so forth using the normal socket mechanisms to query whether an IP addr is in use...? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 21:49:07 2005 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 A712716A41C for ; Tue, 7 Jun 2005 21:49:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7403A43D1D for ; Tue, 7 Jun 2005 21:49:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout11/MantshX 4.0) with ESMTP id j57Ln4A5025149; Tue, 7 Jun 2005 14:49:04 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j57Ln2ZJ000262; Tue, 7 Jun 2005 14:49:03 -0700 (PDT) In-Reply-To: <42A611B8.7040102@elischer.org> References: <42A5BCEB.8020109@kuhtz.com> <42A5D5DE.2010407@elischer.org> <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> <42A611B8.7040102@elischer.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <188A3523-CCA5-4765-BCA4-3E0E8B3375B0@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 17:49:00 -0400 To: Julian Elischer X-Mailer: Apple Mail (2.730) Cc: Christian Kuhtz , freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 21:49:07 -0000 On Jun 7, 2005, at 5:29 PM, Julian Elischer wrote: >> I agree with your suggestion, but how can you have an ip_vhl of >> 0x42? Doesn't a valid IP packet need to have a header length of >> at least 5 (5 << 2 == 20 bytes)? > > huh? > the first byte of an IP packet is not the length.. the first byte > you see on a > packet trace will be the 4 bit version followed by a 4 bit HEADER > length, > followed by 8 bits of TOS (type of Service) and 16 bits of total > packet length. Agreed, but note that I said "header length" above, too. The smallest possible IP packet, without any IP options set, has an IP header length of 20, yes? http://www.ietf.org/rfc/rfc0791.txt, page 10, says: " IHL: 4 bits Internet Header Length is the length of the internet header in 32 bit words, and thus points to the beginning of the data. Note that the minimum value for a correct header is 5." ...and from : #define IPVERSION 4 /* * Structure of an internet header, naked of options. */ struct ip { #ifdef _IP_VHL u_char ip_vhl; /* version << 4 | header length >> 2 */ #else #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, /* header length */ ip_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN u_int ip_v:4, /* version */ ip_hl:4; /* header length */ #endif [ ... ] #define IP_VHL_BORING 0x45 0x45 means ip_v == 4 (IPv4) and ip_hl == 5 (five 32-bit words, or 20 bytes >> 2). > (it's in big-endian format.. beware) Sure. Network wire order is always big endian. :-) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 22:17:27 2005 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 373A016A41C for ; Tue, 7 Jun 2005 22:17:27 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56D1243D48 for ; Tue, 7 Jun 2005 22:17:25 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 3933 invoked by uid 207); 7 Jun 2005 22:17:24 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.151):. Processed in 0.639113 secs); 07 Jun 2005 22:17:24 -0000 Received: from dialup151.ach.sch.gr (HELO gothmog.gr) ([81.186.70.151]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Jun 2005 22:17:23 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j57H5wFr002291; Tue, 7 Jun 2005 20:05:58 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j57H5wgN002290; Tue, 7 Jun 2005 20:05:58 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 7 Jun 2005 20:05:58 +0300 From: Giorgos Keramidas To: Christian Kuhtz Message-ID: <20050607170558.GC1811@gothmog.gr> References: <42A5BCEB.8020109@kuhtz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A5BCEB.8020109@kuhtz.com> Cc: freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 22:17:27 -0000 On 2005-06-07 11:27, Christian Kuhtz wrote: > I'm using the DIVERT socket API for a proof of concept lab setup here, > and I could use some help.. > > Two boxes are involved, packets traverse both in series. The first one, > lets call her A, is taking the UDP packet off the wire, inserts a few > bytes after the UDP header, and sticks it back on the wire. The second > machine, lets call her B, grabs the packet as it comes in, strips the > bytes we inserted, and sticks it back on the wire. > > Or so goes the theory. > > What I'm running into is the following.. When I sendto() the modified > frame on A, the size is correctly reported as what the frame was > modified to be. When the frame arrives on B, I only recvfrom() as many > bytes as the virgin packet used to be when it entered A prior to the > modification. Maybe this is a silly question, as it's been a long while since I last worked with DUMMYNET, but are you also updating the IP header ip_len? From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 22:31:37 2005 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 A2B0716A41C for ; Tue, 7 Jun 2005 22:31:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A8A43D48 for ; Tue, 7 Jun 2005 22:31:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 96FD07A423; Tue, 7 Jun 2005 15:31:36 -0700 (PDT) Message-ID: <42A62048.50403@elischer.org> Date: Tue, 07 Jun 2005 15:31:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Charles Swiger References: <42A5BCEB.8020109@kuhtz.com> <42A5D5DE.2010407@elischer.org> <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> <42A611B8.7040102@elischer.org> <188A3523-CCA5-4765-BCA4-3E0E8B3375B0@mac.com> In-Reply-To: <188A3523-CCA5-4765-BCA4-3E0E8B3375B0@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christian Kuhtz , freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 22:31:37 -0000 Charles Swiger wrote: > On Jun 7, 2005, at 5:29 PM, Julian Elischer wrote: > >>> I agree with your suggestion, but how can you have an ip_vhl of >>> 0x42? Doesn't a valid IP packet need to have a header length of at >>> least 5 (5 << 2 == 20 bytes)? >> >> sorry misread you.. yes.. on my net segment there are a lot of other non IP packets floating around and I am used to seeing 45 and 42 and didn't stop to think that the 42 are not IP :-) From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 22:52:16 2005 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 B008316A41C for ; Tue, 7 Jun 2005 22:52:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC7B43D4C for ; Tue, 7 Jun 2005 22:52:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id j57MqELj020436; Tue, 7 Jun 2005 15:52:14 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j57MqCMQ011991; Tue, 7 Jun 2005 15:52:13 -0700 (PDT) In-Reply-To: <42A62048.50403@elischer.org> References: <42A5BCEB.8020109@kuhtz.com> <42A5D5DE.2010407@elischer.org> <70FFA13A-E2C1-4CCE-B430-F948EECC1B96@mac.com> <42A611B8.7040102@elischer.org> <188A3523-CCA5-4765-BCA4-3E0E8B3375B0@mac.com> <42A62048.50403@elischer.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Jun 2005 18:52:11 -0400 To: Julian Elischer X-Mailer: Apple Mail (2.730) Cc: freebsd-net@freebsd.org Subject: Re: divert sock api q 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, 07 Jun 2005 22:52:16 -0000 On Jun 7, 2005, at 6:31 PM, Julian Elischer wrote: [ ...about the ip_vhl byte... ] > sorry misread you.. > yes.. OK. > on my net segment there are a lot of other non IP packets floating > around and I am used to seeing 45 and 42 and didn't stop to think > that the 42 are not IP :-) No problem, then. I'm sure you know your networking, but this had me worried for a second, since I'm not always convinced that I know what *I'm* doing. :-) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jun 7 23:12:21 2005 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 CEE3216A41C for ; Tue, 7 Jun 2005 23:12:21 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262F443D1D for ; Tue, 7 Jun 2005 23:12:19 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 408E385642; Wed, 8 Jun 2005 08:42:18 +0930 (CST) Date: Wed, 8 Jun 2005 08:42:18 +0930 From: Greg 'groggy' Lehey To: Marc Olzheim , Jeremie Le Hen Message-ID: <20050607231218.GD64194@wantadilla.lemis.com> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J9fO++IT6debZ01Z" Content-Disposition: inline In-Reply-To: <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607094848.GB16223@stack.nl> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD-net@FreeBSD.org Subject: Re: Problems with gif tunnels 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, 07 Jun 2005 23:12:22 -0000 --J9fO++IT6debZ01Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 7 June 2005 at 11:48:48 +0200, Marc Olzheim wrote: > On Tue, Jun 07, 2005 at 07:07:17PM +0930, Greg 'groggy' Lehey wrote: >> I posted this message to the -questions list an hour or so ago. >> Possibly it's of interest to people on this list. Certainly the >> problem is non-obvious, so even (as I suspect) if it's my fault, it >> would be interesting to document the problem. > > The interface on the default route is rl0 instead of gif0... > Could you try with -interface gif0 ? On Tuesday, 7 June 2005 at 12:09:58 +0200, Jeremie Le Hen wrote: > Hi Greg, > >>> Destination Gateway Flags Refs Use Netif Expire >>> default 150.101.14.9 UGS 0 7 rl0 >>> 150.101.14.8/30 link#2 UC 0 0 rl0 >>> 150.101.14.9 00:90:1a:40:09:98 UHLW 2 2 rl0 903 >>> 192.109.197 link#1 UC 0 0 xl0 >>> 192.109.197.135 00:10:4b:66:1e:e9 UHLW 0 6757 xl0 1056 >>> 192.109.197.137 00:50:da:cf:07:35 UHLW 0 99336 xl0 1188 >>> 192.109.197.255 ff:ff:ff:ff:ff:ff UHLWb 0 34521 xl0 >>> 203.16.215.227 150.101.14.9 UGHS 1 4 rl0 > > I guess you need a route to something like 192.83.231.0/24 through gif0. > Try >>>> > route add -host 192.83.231.16 -interface gif0 >>>> Well, this is the default interface, but yes, for outgoing traffic this is obviously correct. It also appears to work. > >>> I then get somebody from the other end to ping me: >>> >>> 17:49:10.228597 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6908 >>> 17:49:11.229188 IP 203.16.215.227 > 150.101.14.10: IP 192.83.231.16 > 192.109.197.145: icmp 64: echo request seq 6909 >>> >>> But that's all. Nothing goes out. I've tried this on different >>> systems, and I know somebody else who is using what looks like an >>> identical configuration with this ISP, and it works fine. I've tried >>> different systems, one and two NICs, 4.x and 5.x, all with the same >>> (non)result. What am I missing? > > It would be worth knowing if the ICMP packet goes out from your > ``internal'' interface (xl0). No, of course not. It goes out from the other end (at the ISP). It comes in on the rl0 interface. > In this case, you should also see the ICMP echo-reply. I don't see any reply. But that's not surprising, since the echo packet doesn't get delivered. To summarize again: - rl0 is the external interface (-> DSL), IP 150.101.14.10. - xl0 is the internal interface, IP 192.109.197.143. - encapsulated packet comes in from 203.16.215.227 with data from IP 192.83.231.16 for 192.109.197.145. It should go out xl0. - It doesn't. No further indication of why not. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --J9fO++IT6debZ01Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCpinSIubykFB6QiMRAiaJAJ4qUVeTWOwaQI4PIK18pzjixaHe0wCfbNqu SpnrVVDAilkO8LOpv1ppfhk= =j4X1 -----END PGP SIGNATURE----- --J9fO++IT6debZ01Z-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 06:19:35 2005 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 D9A3E16A41C for ; Wed, 8 Jun 2005 06:19:35 +0000 (GMT) (envelope-from hostap-bounces+net=freebsd.org@shmoo.com) Received: from mail.iocaine.com (mail.iocaine.com [209.169.14.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1AD943D1D for ; Wed, 8 Jun 2005 06:19:32 +0000 (GMT) (envelope-from hostap-bounces+net=freebsd.org@shmoo.com) Received: from incognito.shmoo.com (localhost [127.0.0.1]) by mail.iocaine.com (Postfix) with ESMTP id 84DD9134035 for ; Wed, 8 Jun 2005 00:29:07 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: hostap-bounces@shmoo.com To: net@freebsd.org Message-ID: Date: Wed, 08 Jun 2005 00:29:05 -0600 Precedence: bulk X-BeenThere: hostap@shmoo.com X-Mailman-Version: 2.1.6b1 X-List-Administrivia: yes Sender: hostap-bounces+net=freebsd.org@shmoo.com Errors-To: hostap-bounces+net=freebsd.org@shmoo.com Cc: Subject: Your message to HostAP awaits moderator approval X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 06:19:36 -0000 Your mail to 'HostAP' with the subject Re: Mail Server Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.shmoo.com/mailman/confirm/hostap/06a25a5c856a2b3fd55523e4d791eaa3716db06e From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 08:39:05 2005 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 EE4D416A41C for ; Wed, 8 Jun 2005 08:39:05 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from 62-15-215-235.inversas.jazztel.es (62-15-215-235.inversas.jazztel.es [62.15.215.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B4043D53 for ; Wed, 8 Jun 2005 08:39:04 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by 62-15-215-235.inversas.jazztel.es (8.13.3/8.13.3) with ESMTP id j588cw3S060311 for ; Wed, 8 Jun 2005 10:38:58 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j588cwXR039483 for freebsd-net@freebsd.org; Wed, 8 Jun 2005 10:38:58 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: freebsd-net Date: Wed, 8 Jun 2005 10:38:58 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506081038.58376.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.15; VDF: 6.30.0.207; host: antares.redesjm.local) Subject: tftpd blksize option for stock tftpd 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, 08 Jun 2005 08:39:06 -0000 Hi, I ports PR bin/67550 time ago, with minor fixes to tftpd protocol impl. and support for blksize option. Can someone review this before RELENG_6? Tested here with pxelinux clients. -- josemi From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 08:45:55 2005 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 8587B16A41C for ; Wed, 8 Jun 2005 08:45:55 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D98A243D53 for ; Wed, 8 Jun 2005 08:45:54 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j588jmiN026780; Wed, 8 Jun 2005 12:45:48 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 8 Jun 2005 12:45:48 +0400 (MSD) From: Maxim Konovalov To: Jose M Rodriguez In-Reply-To: <200506081038.58376.josemi@redesjm.local> Message-ID: <20050608124008.E26720@mp2.macomnet.net> References: <200506081038.58376.josemi@redesjm.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net Subject: Re: tftpd blksize option for stock tftpd 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, 08 Jun 2005 08:45:55 -0000 On Wed, 8 Jun 2005, 10:38+0200, Jose M Rodriguez wrote: > Hi, > > I ports PR bin/67550 time ago, with minor fixes to tftpd protocol impl. > and support for blksize option. > > Can someone review this before RELENG_6? Tested here with pxelinux > clients. I'm slowly working on merging blocksize and timeout options (RFC 2347 - 2349) from NetBSD. I don't finish my work before RELENG_6 definitly. http://maxim.int.ru/stuff/netbsd.tftp.diff -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 08:50:03 2005 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 96E4F16A41C; Wed, 8 Jun 2005 08:50:03 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4970F43D1F; Wed, 8 Jun 2005 08:50:03 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 4A0F4317DE5; Wed, 8 Jun 2005 10:50:02 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 54393407E; Wed, 8 Jun 2005 10:49:46 +0200 (CEST) Date: Wed, 8 Jun 2005 10:49:46 +0200 From: Jeremie Le Hen To: Greg 'groggy' Lehey Message-ID: <20050608084946.GI41050@obiwan.tataz.chchile.org> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050607231218.GD64194@wantadilla.lemis.com> User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , FreeBSD-net@FreeBSD.org, Jeremie Le Hen Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 08:50:03 -0000 Hi Greg, > I don't see any reply. But that's not surprising, since the echo > packet doesn't get delivered. To summarize again: > > - rl0 is the external interface (-> DSL), IP 150.101.14.10. > - xl0 is the internal interface, IP 192.109.197.143. > - encapsulated packet comes in from 203.16.215.227 with data from IP > 192.83.231.16 for 192.109.197.145. It should go out xl0. > - It doesn't. No further indication of why not. I saw your commit on gif(4) manual page precising that gif(4) does not do GRE tunnels. Does it represent a solution to your problem ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 09:57:07 2005 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 3705A16A41C for ; Wed, 8 Jun 2005 09:57:07 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D65443D1F for ; Wed, 8 Jun 2005 09:57:06 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 7F57885A01; Wed, 8 Jun 2005 19:27:03 +0930 (CST) Date: Wed, 8 Jun 2005 19:27:03 +0930 From: Greg 'groggy' Lehey To: Jeremie Le Hen Message-ID: <20050608095703.GM64194@wantadilla.lemis.com> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MqkwUViToTQK+HjE" Content-Disposition: inline In-Reply-To: <20050608084946.GI41050@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Marc Olzheim , FreeBSD-net@FreeBSD.org Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 09:57:07 -0000 --MqkwUViToTQK+HjE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 8 June 2005 at 10:49:46 +0200, Jeremie Le Hen wrote: > Hi Greg, > >> I don't see any reply. But that's not surprising, since the echo >> packet doesn't get delivered. To summarize again: >> >> - rl0 is the external interface (-> DSL), IP 150.101.14.10. >> - xl0 is the internal interface, IP 192.109.197.143. >> - encapsulated packet comes in from 203.16.215.227 with data from IP >> 192.83.231.16 for 192.109.197.145. It should go out xl0. >> - It doesn't. No further indication of why not. > > I saw your commit on gif(4) manual page precising that gif(4) does not > do GRE tunnels. Does it represent a solution to your problem ? Heh. Yes :-) It's currently pushing 7:30 pm, and I was going to send out a reply tomorrow. But indeed, it seems that Linux people prefer GRE tunnels, we prefer (with good reason) IP tunnels, and the whole issue was one of documentation. After changing my tunnel from GRE to IP, it worked (and works) like a charm. But there's more to come, including a docco for Internode to hand to their FreeBSD customers (sadly, once they were FreeBSD, but they moved to Linux). Watch this space. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --MqkwUViToTQK+HjE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCpsDvIubykFB6QiMRAnovAJ4mGc+CdZs8TJI7KqfxJdlMWgCKygCaA7lF YeHELiOFRT9Ft/z6oyejoCk= =YN+s -----END PGP SIGNATURE----- --MqkwUViToTQK+HjE-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 09:59:41 2005 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 558F516A41C; Wed, 8 Jun 2005 09:59:41 +0000 (GMT) (envelope-from root@Neo-Vortex.net) Received: from Neo-Vortex.net (203-173-58-65.dyn.iinet.net.au [203.173.58.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34C3643D49; Wed, 8 Jun 2005 09:59:39 +0000 (GMT) (envelope-from root@Neo-Vortex.net) Received: from localhost.Neo-Vortex.net (Neo-Vortex@localhost.Neo-Vortex.net [127.0.0.1]) by Neo-Vortex.net (8.13.1/8.12.10) with ESMTP id j589xan0065386; Wed, 8 Jun 2005 19:59:36 +1000 (EST) (envelope-from root@Neo-Vortex.net) Date: Wed, 8 Jun 2005 19:59:36 +1000 (EST) From: Neo-Vortex To: "Greg 'groggy' Lehey" In-Reply-To: <20050608095703.GM64194@wantadilla.lemis.com> Message-ID: <20050608195837.Q65103@Neo-Vortex.net> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Marc Olzheim , FreeBSD-net@freebsd.org, Jeremie Le Hen Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 09:59:41 -0000 On Wed, 8 Jun 2005, Greg 'groggy' Lehey wrote: > On Wednesday, 8 June 2005 at 10:49:46 +0200, Jeremie Le Hen wrote: > > Hi Greg, > > > >> I don't see any reply. But that's not surprising, since the echo > >> packet doesn't get delivered. To summarize again: > >> > >> - rl0 is the external interface (-> DSL), IP 150.101.14.10. > >> - xl0 is the internal interface, IP 192.109.197.143. > >> - encapsulated packet comes in from 203.16.215.227 with data from IP > >> 192.83.231.16 for 192.109.197.145. It should go out xl0. > >> - It doesn't. No further indication of why not. > > > > I saw your commit on gif(4) manual page precising that gif(4) does not > > do GRE tunnels. Does it represent a solution to your problem ? > > Heh. Yes :-) > > It's currently pushing 7:30 pm, and I was going to send out a reply > tomorrow. But indeed, it seems that Linux people prefer GRE tunnels, > we prefer (with good reason) IP tunnels, and the whole issue was one > of documentation. After changing my tunnel from GRE to IP, it worked > (and works) like a charm. > > But there's more to come, including a docco for Internode to hand to > their FreeBSD customers (sadly, once they were FreeBSD, but they moved > to Linux). Watch this space. > > Greg > -- > The virus contained in this message was not detected. > > Finger grog@FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > What is the difference between gre and gif tunnels anyway... the man mages were not that informative... ~NVX From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 10:41:09 2005 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 41BF416A41C; Wed, 8 Jun 2005 10:41:09 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEFB443D1D; Wed, 8 Jun 2005 10:41:08 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 47DEA1734FA; Wed, 8 Jun 2005 12:41:07 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 3B0CD407E; Wed, 8 Jun 2005 12:40:53 +0200 (CEST) Date: Wed, 8 Jun 2005 12:40:53 +0200 From: Jeremie Le Hen To: Neo-Vortex Message-ID: <20050608104053.GK41050@obiwan.tataz.chchile.org> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608195837.Q65103@Neo-Vortex.net> User-Agent: Mutt/1.5.9i Cc: Greg 'groggy' Lehey , Marc Olzheim , Jeremie Le Hen , FreeBSD-net@freebsd.org Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 10:41:09 -0000 > > It's currently pushing 7:30 pm, and I was going to send out a reply > > tomorrow. But indeed, it seems that Linux people prefer GRE tunnels, > > we prefer (with good reason) IP tunnels, and the whole issue was one > > of documentation. After changing my tunnel from GRE to IP, it worked > > (and works) like a charm. IIRC, - Linux uses the ipip module to do IP-over-IP tunnel - FreeBSD uses the gre(4) interface to do GRE tunnels - GRE is a Cisco product and means ``Generic Routing Encapsulation''. I don't know what they mean with the term "Generic" because I have only seen IP encapsulated tunnel so far. According to the GRE header, I guess GRE is far more powerful than a simple IP-over-IP encapsulation, and I would be glad if someone could explain us what are the benefits of this protocol. I would conclude by saying that indeed Linux users tend to use GRE tunnels whereas a IP-over-IP tunnel would be enough, because they used to be trendy. > What is the difference between gre and gif tunnels anyway... the man mages > were not that informative... Read above. Usually gre(4) tunnels are used as simple IP-over-IP tunnel, so a gif(4) would do the same with less overload (due to GRE header size). GRE seems far more powerful, but I don't know its benefits. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 12:20:54 2005 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 C1E0116A41C for ; Wed, 8 Jun 2005 12:20:54 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F0A243D48 for ; Wed, 8 Jun 2005 12:20:53 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j58CKpMq018160; Wed, 8 Jun 2005 15:20:52 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) by orion.daedalusnetworks.priv (8.13.4/8.13.4) with ESMTP id j58CKp5c001768; Wed, 8 Jun 2005 15:20:51 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by orion.daedalusnetworks.priv (8.13.4/8.13.4/Submit) id j58CKpKh001767; Wed, 8 Jun 2005 15:20:51 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Wed, 8 Jun 2005 15:20:51 +0300 From: Giorgos Keramidas To: Jeremie Le Hen , freebsd-net@FreeBSD.org Message-ID: <20050608122051.GA1650@orion.daedalusnetworks.priv> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608104053.GK41050@obiwan.tataz.chchile.org> Cc: Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 12:20:54 -0000 On 2005-06-08 12:40, Jeremie Le Hen wrote: > > IIRC, > - Linux uses the ipip module to do IP-over-IP tunnel > - FreeBSD uses the gre(4) interface to do GRE tunnels > - GRE is a Cisco product and means ``Generic Routing > Encapsulation''. I don't know what they mean with the term > "Generic" because I have only seen IP encapsulated tunnel so > far. It's not mandatory to tunnel IP over GRE. Other, non IPv4 protocols can be encapsulated in the GRE payload. > According to the GRE header, I guess GRE is far more powerful > than a simple IP-over-IP encapsulation, and I would be glad if > someone could explain us what are the benefits of this protocol. GRE is not a simple encapsulation of an IP packet as the payload of an IP packet. It also includes fields in the outter IP header that may support, among other things: - Source routing - A crude form of authentication (key & sequence number pair) - Separation of tunelled "flows" without the payload inspection IP-IP tunnels may require From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 21:45:36 2005 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 CA56616A41C; Wed, 8 Jun 2005 21:45:36 +0000 (GMT) (envelope-from conallob@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 094CE43D1D; Wed, 8 Jun 2005 21:45:35 +0000 (GMT) (envelope-from conallob@maths.tcd.ie) Date: Wed, 8 Jun 2005 22:45:30 +0100 From: Conall O'Brien To: timt@sharktech.net Message-ID: <20050608214529.GA12932@salmon.maths.tcd.ie> References: <1118026528.42a3bb20a76ce@webmail.sharktech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118026528.42a3bb20a76ce@webmail.sharktech.net> X-Operating-System: FreeBSD salmon.maths.tcd.ie 4.11-STABLE FreeBSD 4.11-STABLE X-GPG-FingerPrint: E3D4 A863 33E4 69FD 3FA9 C7DC 560D 0861 EE7D C74E X-GPG-Key-ID: EE7DC74E http://www.keyserver.net/ "Reply-To: conall+freebsd@maths.tcd.ie" User-Agent: Mutt/1.5.8i Sender: conallob@maths.tcd.ie Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: LSI MegaRaid 150-6 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, 08 Jun 2005 21:45:36 -0000 On Sun, Jun 05, 2005 at 09:55:28PM -0500, timt@sharktech.net wrote: > This is the 2nd time I search for a resolution on this matter I could not find > any documents online regarding this issue. > We are building a system with the following hardware: > > Tyan S2882 Dual Opteron Board (latest BIOS) > 2 x Opteron 244 CPU's > 2 x 1GB DDR PC3200+ > LSI MegaRaid 150-6 (Intel SRCS16) (latest firmware) > Intel Pro SC 1000 Fiber NIC > 5 x 200GB 7.2KRPM 8MBuffer Western Digital (each hard drive has been checked for > any problem) > > At first we started installing FreeBSD5.4-RELEASE AMD64 LSI Megaraid was > detected and raid was running in optimal. When it asked me to choose the slice > it gave me a warning that the geometry for the drive is incorrect and to check > with the BIOS for the true geometry and if this is a SCSI please check with the > controller's algorithem (something). Which I searched online for with no clues. What RAID configuration are you using? 0, 1, 5, 10 or 50? Is your RAID array partitioned or sliced at all? If so, how many partitions and/or slices do you have and of what sizes? > Anyways went to system installation it starts installing bursting to 2600KB/s > and after 55% it goes down to 800KB/s than when reaching ports it goes down to > 33KB/s and this is CDROM installation!! > > When system is installed completly we ran dd on the system a constant average of > 2.1MB/s is the BEST performance we could get! > > We tried installing Windows XP for testing and performance was decent bursting > to 70MB/s (which is the average on this controller). We tried FreeBSD5.3(I386) > and FreeBSD4.11(i386) same problem. Please if anyone have any idea whats going > on we really don't wanna go with Linux on this system!! I've the 150-6 setup in an old Digital Alpha system with 4 x 250GB Hitachi Deskstar disks. Under both 4.11 (well, RELENG_4) and 5.4 (RELENG_5) I have no performance issues with my RAID 5 setup. I've seen write speeds over 15MB/s (yes, B not b) when transferring large CAD related files onto my fileserver. Can you provide some better benchmark data please? I'd recommend using bonnie++ (See benchmarks/bonnie++ in the Port Collection) and we'll see if we can find the problem. -- Regards, Conall O'Brien Systems and Network Administrator School Of Mathematics University Of Dublin, Trinity College From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 23:31:39 2005 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 DB2EE16A41C for ; Wed, 8 Jun 2005 23:31:39 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0291643D49 for ; Wed, 8 Jun 2005 23:31:38 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id D0F86857BB; Thu, 9 Jun 2005 09:01:36 +0930 (CST) Date: Thu, 9 Jun 2005 09:01:36 +0930 From: Greg 'groggy' Lehey To: Jeremie Le Hen Message-ID: <20050608233136.GX64194@wantadilla.lemis.com> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DNzU1U2E89wy37K+" Content-Disposition: inline In-Reply-To: <20050608104053.GK41050@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Marc Olzheim , FreeBSD-net@freebsd.org, Neo-Vortex Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 23:31:40 -0000 --DNzU1U2E89wy37K+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 8 June 2005 at 12:40:53 +0200, Jeremie Le Hen wrote: >>> It's currently pushing 7:30 pm, and I was going to send out a reply >>> tomorrow. But indeed, it seems that Linux people prefer GRE tunnels, >>> we prefer (with good reason) IP tunnels, and the whole issue was one >>> of documentation. After changing my tunnel from GRE to IP, it worked >>> (and works) like a charm. > > IIRC, > - Linux uses the ipip module to do IP-over-IP tunnel > - FreeBSD uses the gre(4) interface to do GRE tunnels > - GRE is a Cisco product and means ``Generic Routing > Encapsulation''. I don't know what they mean with the term > "Generic" because I have only seen IP encapsulated tunnel so far. > According to the GRE header, I guess GRE is far more powerful > than a simple IP-over-IP encapsulation, and I would be glad if > someone could explain us what are the benefits of this protocol. > I would conclude by saying that indeed Linux users tend to use > GRE tunnels whereas a IP-over-IP tunnel would be enough, because > they used to be trendy. > >> What is the difference between gre and gif tunnels anyway... the man mages >> were not that informative... > > Read above. Usually gre(4) tunnels are used as simple IP-over-IP tunnel, > so a gif(4) would do the same with less overload (due to GRE header size). > GRE seems far more powerful, but I don't know its benefits. My understanding is that GRE is to IP as PPP is to SLIP: it allows multiple protocols to be encapsulated. I've done some tracing with Ethereal, and the only difference is a four-byte header in front of the payload for GRE; in an IP tunnel, it's simply missing. I've written this up in my diary (http://www.lemis.com/grog/diary-jun2005.html#8), along with the traces. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --DNzU1U2E89wy37K+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCp3/YIubykFB6QiMRAvJhAJ9ZXgVqwnVxPcT/cpV1Ld5q7BHmVQCgkn/U VXCnZJmSsXNWjpPERF6tlJ0= =TJXq -----END PGP SIGNATURE----- --DNzU1U2E89wy37K+-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 8 23:46:18 2005 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 62B1716A41C; Wed, 8 Jun 2005 23:46:18 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A36043D49; Wed, 8 Jun 2005 23:46:17 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 547CB1734E4; Thu, 9 Jun 2005 01:46:16 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id A712D407E; Thu, 9 Jun 2005 01:46:00 +0200 (CEST) Date: Thu, 9 Jun 2005 01:46:00 +0200 From: Jeremie Le Hen To: Greg 'groggy' Lehey Message-ID: <20050608234559.GS41050@obiwan.tataz.chchile.org> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050608233136.GX64194@wantadilla.lemis.com> User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , FreeBSD-net@freebsd.org, Jeremie Le Hen , Neo-Vortex Subject: Re: Problems with gif tunnels 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, 08 Jun 2005 23:46:18 -0000 Greg, > My understanding is that GRE is to IP as PPP is to SLIP: it allows > multiple protocols to be encapsulated. I've done some tracing with > Ethereal, and the only difference is a four-byte header in front of > the payload for GRE; in an IP tunnel, it's simply missing. I've > written this up in my diary > (http://www.lemis.com/grog/diary-jun2005.html#8), along with the > traces. yes it's usually a simple four-byte header when doing a simple tunnel. But from what I have read [1] and according to what Giorgos said, it seems it can be a lot more longer, depending on the value of the five first bits of the GRE header. Enjoy your tunnel ;-). [1] http://www.networksorcery.com/enp/protocol/gre.htm -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 00:10:07 2005 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 5AB7816A41C for ; Thu, 9 Jun 2005 00:10:07 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9003843D1F for ; Thu, 9 Jun 2005 00:10:06 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 86238856C6; Thu, 9 Jun 2005 09:40:04 +0930 (CST) Date: Thu, 9 Jun 2005 09:40:04 +0930 From: Greg 'groggy' Lehey To: Jeremie Le Hen Message-ID: <20050609001004.GB64194@wantadilla.lemis.com> References: <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lUWNHpMBvmChTRKs" Content-Disposition: inline In-Reply-To: <20050608234559.GS41050@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: Marc Olzheim , FreeBSD-net@freebsd.org, Neo-Vortex Subject: Re: Problems with gif tunnels 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, 09 Jun 2005 00:10:07 -0000 --lUWNHpMBvmChTRKs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thursday, 9 June 2005 at 1:46:00 +0200, Jeremie Le Hen wrote: > Greg, > >> My understanding is that GRE is to IP as PPP is to SLIP: it allows >> multiple protocols to be encapsulated. I've done some tracing with >> Ethereal, and the only difference is a four-byte header in front of >> the payload for GRE; in an IP tunnel, it's simply missing. I've >> written this up in my diary >> (http://www.lemis.com/grog/diary-jun2005.html#8), along with the >> traces. > > yes it's usually a simple four-byte header when doing a simple tunnel. > But from what I have read [1] and according to what Giorgos said, > it seems it can be a lot more longer, depending on the value of the > five first bits of the GRE header. Ah, that seems reasonable. =20 Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --lUWNHpMBvmChTRKs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCp4jcIubykFB6QiMRAswaAJ45MEqco5cqsqwMaWaQECsvpqsMhgCgofKb 1nIXTVo6qr4XMLHFJNN+NGM= =AxVZ -----END PGP SIGNATURE----- --lUWNHpMBvmChTRKs-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 06:16:25 2005 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 030DA16A41C; Thu, 9 Jun 2005 06:16:25 +0000 (GMT) (envelope-from gmarco@masternet.it) Received: from freebsd.giovannelli.com (freebsd.giovannelli.com [83.149.149.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id E56B843D1D; Thu, 9 Jun 2005 06:16:22 +0000 (GMT) (envelope-from gmarco@masternet.it) Received: from usul.giovannelli.it (usul.giovannelli.com [10.254.254.4]) by freebsd.giovannelli.com (8.13.3/8.13.3) with ESMTP id j596EnAq009216; Thu, 9 Jun 2005 08:14:50 +0200 (CEST) (envelope-from gmarco@masternet.it) Message-Id: <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 09 Jun 2005 08:13:54 +0200 To: "Greg 'groggy' Lehey" From: Gianmarco Giovannelli In-Reply-To: <20050609001004.GB64194@wantadilla.lemis.com> References: <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiVirus: checked by AVIRA Milter (version: 1.0.0-6; AIE: 6.30.0.12; VDF: 6.30.0.184; host: localhost) Cc: FreeBSD-net@freebsd.org Subject: Re: Problems with gif tunnels 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, 09 Jun 2005 06:16:25 -0000 At 02.10 09/06/2005, Greg 'groggy' Lehey wrote: >On Thursday, 9 June 2005 at 1:46:00 +0200, Jeremie Le Hen wrote: >> Greg, >> >>> My understanding is that GRE is to IP as PPP is to SLIP: it allows >>> multiple protocols to be encapsulated. I've done some tracing with >>> Ethereal, and the only difference is a four-byte header in front of >>> the payload for GRE; in an IP tunnel, it's simply missing. I've >>> written this up in my diary >>> (http://www.lemis.com/grog/diary-jun2005.html#8), along with the >>> traces. >> >> yes it's usually a simple four-byte header when doing a simple tunnel. >> But from what I have read [1] and according to what Giorgos said, >> it seems it can be a lot more longer, depending on the value of the >> five first bits of the GRE header. > >Ah, that seems reasonable. Hi Greg, I have follow with interest this thread because I had a similar problem sometimes ago and we din't succeded in resolve it as I like ... I had to connect a couple of a nets with a freebsd box and a linux box (not managed by me). They insist to use the ipip tunnel (p:4) and I think I should use the nos-tun interface we had in the base system to let things works ourside. But it didn't do the job so we had to switch on an ipsec tunnel (esp only) which works quite well except a few things... Now I see I could simply use the gif interface (which I wrongly suppose did only GRE tunnel :-) to connect to an ipip linux tunnel. Is this right ? And the nos-tun utility is so a basic replacement of the gif interface ? Thanks .... From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 06:44:55 2005 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 EE54516A41C; Thu, 9 Jun 2005 06:44:55 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F3F43D49; Thu, 9 Jun 2005 06:44:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j596iqxi006097; Wed, 8 Jun 2005 23:44:52 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j596iqFF006096; Wed, 8 Jun 2005 23:44:52 -0700 Date: Wed, 8 Jun 2005 23:44:52 -0700 From: Brooks Davis To: current@freebsd.org Message-ID: <20050609064452.GC1595@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uh9ZiVrAOUUm9fzH" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: net@freebsd.org Subject: HEADSUP: internal network interface changes 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, 09 Jun 2005 06:44:56 -0000 --uh9ZiVrAOUUm9fzH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I plan to commit a major rework of network interface related storage Friday morning PDT. This is a massive change touching every network driver in the system. This change was discussed at the BSDCan dev summit and derives from discussions at EuroBSDCon on dealing with dynamic network devices. You can view the diff at: http://people.freebsd.org/~brooks/patches/ifnet.diff I'm not posting the diff to the list as it is nearly 700K. Below, you will find the diff to ifnet(9) for a more technical view of the API change. In short, the change removes the embedded struct ifnet and layer 2 common structures (struct arpcom, struct ifatm, struct sppp, etc) from driver softcs and replaces them with a struct ifnet pointer which is allocated with a new function, if_alloc which takes an interface type. For certain types, if_alloc also fills in the new struct ifnet member, if_l2com with an initialized layer 2 common structure. The benefits of this change are: - The size of struct ifnet and the layer 2 common structures is no longer part of the network interface ABI. This means we add features to the generic interface code so long as they do not require action on the part of the driver without breaking the ABI. - Since storage is no longer tied to the softc, we will able to reference count struct ifnet more easily which is a prerequisite for fixing the panics on removing an interface which is configured with dummynet. - This patch eliminates many ugly casts and the historically weakly documented requirement that softc's be castable to ifnet's and arpcom's. Things to note about this change: - External drivers including those in ports will panic if loaded until they are converted to the new API. Things to note about this patch: - There are nearly 100 drivers in the tree and I only use a small set of them so there are likely to be some small bugs in this patch. The changes were mostly mechanical, but varying naming conventions, plus the occasional driver written entirely from scratch introduce the possibility of errors. Use care when updating, particularly with remote systems. - In most cases, this patch does not address the issue of keeping source compatible with previous releases or other systems. I will supply patches to do so in any case where there is a need, but I intend to wait until after committing to do so. I hope the set of drivers requiring these changes will be small. -- Brooks P.S. the posted patch contains a bug in the udav driver. It will be fixed before commit. --- freebsd/share/man/man9/ifnet.9 Sun Jun 5 13:33:05 2005 +++ ifnet/share/man/man9/ifnet.9 Sun Jun 5 20:20:03 2005 @@ -46,9 +46,17 @@ .In net/if_types.h .\" .Ss "Interface Manipulation Functions" +.Ft "struct ifnet *" +.Fn if_alloc "u_char type" .Ft void .Fn if_attach "struct ifnet *ifp" .Ft void +.Fn if_detach "struct ifnet *ifp" +.Ft void +.Fn if_free "struct ifnet *ifp" +.Ft void +.Fn if_free_type "struct ifnet *ifp" "u_char type" +.Ft void .Fn if_down "struct ifnet *ifp" .Ft int .Fn ifioctl "struct socket *so" "u_long cmd" "caddr_t data" "struct thread= *td" @@ -219,6 +227,11 @@ .Pq Vt "void *" A pointer to the driver's private state block. (Initialized by driver.) +.It Va if_l2com +.Pq Vt "void *" +A pointer to the common data for the interface's layer 2 protocol. +(Initialized by +.Fn if_alloc .) .It Va if_link .Pq Fn TAILQ_ENTRY ifnet .Xr queue 3 @@ -270,6 +283,8 @@ to refer to a particular interface by index (see .Xr link_addr 3 ) . +(Initialized by +.Fn if_alloc .) .It Va if_timer .Pq Vt short Number of seconds until the watchdog timer @@ -988,6 +1003,14 @@ .El .Ss Interface Manipulation Functions .Bl -ohang -offset indent +.It Fn if_alloc +Allocate and initalize an +.Fa ifp . +Initalization includes the allocation of an interface index and may +include the allocation of a +.Fa type +specific structure in +.Va if_l2com . .It Fn if_attach Link the specified interface .Fa ifp @@ -999,6 +1022,29 @@ (A pointer to this address structure is saved in the global array .Va ifnet_addrs . ) +The +.Fa ifp +must have been allocted by +.Fn if_alloc . +.It Fn if_detach +Shutdown and unlink the specified +.Fa ifp +from the interface list. +.It Fn if_free +Free the given +.Fa ifp +back to the system. +The interface must have been previously detached if it was ever attached. +.It Fn if_free_type +Identical to +.Fn if_free +except that the given +.Fa type + is used to free=20 + .Va if_l2com + instead of the type in + .Va if_type . + This is intended for use with drivers that change their interface type. .It Fn if_down Mark the interface .Fa ifp --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --uh9ZiVrAOUUm9fzH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCp+VjXY6L6fI4GtQRAiZ+AJ9EqZCRd5aoXmm9vFO2DeLcL1qDnACfZDyv RKUK1aWZnYOq+PvkmDsz0FM= =FHKv -----END PGP SIGNATURE----- --uh9ZiVrAOUUm9fzH-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 07:44:57 2005 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 82C7D16A41C; Thu, 9 Jun 2005 07:44:57 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 236E943D1D; Thu, 9 Jun 2005 07:44:56 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id DC387C0DE; Thu, 9 Jun 2005 09:44:55 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id E0A70407E; Thu, 9 Jun 2005 09:44:39 +0200 (CEST) Date: Thu, 9 Jun 2005 09:44:39 +0200 From: Jeremie Le Hen To: Gianmarco Giovannelli Message-ID: <20050609074439.GT41050@obiwan.tataz.chchile.org> References: <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> User-Agent: Mutt/1.5.9i Cc: Greg 'groggy' Lehey , FreeBSD-net@freebsd.org Subject: Re: Problems with gif tunnels 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, 09 Jun 2005 07:44:57 -0000 Hi Gianmarco, > Hi Greg, I have follow with interest this thread because I had a similar > problem sometimes ago and we din't succeded in resolve it as I like ... > > I had to connect a couple of a nets with a freebsd box and a linux box > (not managed by me). They insist to use the ipip tunnel (p:4) and I think I > should use the nos-tun interface we had in the base system to let things > works ourside. But it didn't do the job so we had to switch on an ipsec > tunnel (esp only) which works quite well except a few things... > > Now I see I could simply use the gif interface (which I wrongly suppose did > only GRE tunnel :-) to connect to an ipip linux tunnel. Is this right ? > And the nos-tun utility is so a basic replacement of the gif interface ? Given the simplicity of gif(4) IP-encapsulated packets, I wonder how Linux guys could have implemented something else in their IPIP module :-). I never set up such a tunnel between Linux and FreeBSD myself, but from what I read [1], it seems to work well. Please, would you keep us informed whether this setup works for you or not, it would be certainly worthwhile for the archives. Regards, [1] http://hashbang.org.uk/index.php/GIF_to_IPIP_Tunnels -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 07:54:11 2005 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 1EE2716A41C for ; Thu, 9 Jun 2005 07:54:11 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFECE43D48 for ; Thu, 9 Jun 2005 07:54:09 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id C7D8B85622; Thu, 9 Jun 2005 17:24:07 +0930 (CST) Date: Thu, 9 Jun 2005 17:24:07 +0930 From: Greg 'groggy' Lehey To: Gianmarco Giovannelli , Jeremie Le Hen Message-ID: <20050609075407.GE87456@wantadilla.lemis.com> References: <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <20050609074439.GT41050@obiwan.tataz.chchile.org> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD-net@freebsd.org Subject: Re: Problems with gif tunnels 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, 09 Jun 2005 07:54:11 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 9 June 2005 at 8:13:54 +0200, Gianmarco Giovannelli wrote: > At 02.10 09/06/2005, Greg 'groggy' Lehey wrote: >> On Thursday, 9 June 2005 at 1:46:00 +0200, Jeremie Le Hen wrote: >>> Greg, >>> >>>> My understanding is that GRE is to IP as PPP is to SLIP: it allows >>>> multiple protocols to be encapsulated. I've done some tracing with >>>> Ethereal, and the only difference is a four-byte header in front of >>>> the payload for GRE; in an IP tunnel, it's simply missing. I've >>>> written this up in my diary >>>> (http://www.lemis.com/grog/diary-jun2005.html#8), along with the >>>> traces. >>> >>> yes it's usually a simple four-byte header when doing a simple tunnel. >>> But from what I have read [1] and according to what Giorgos said, >>> it seems it can be a lot more longer, depending on the value of the >>> five first bits of the GRE header. >> >> Ah, that seems reasonable. > > Hi Greg, I have follow with interest this thread because I had a similar > problem sometimes ago and we din't succeded in resolve it as I like ... > > I had to connect a couple of a nets with a freebsd box and a linux box > (not managed by me). They insist to use the ipip tunnel (p:4) What does p:4 mean? > and I think I should use the nos-tun interface we had in the base > system to let things works ourside. But it didn't do the job so we > had to switch on an ipsec tunnel (esp only) which works quite well > except a few things... Like performance? > Now I see I could simply use the gif interface (which I wrongly > suppose did only GRE tunnel :-) Indeed. It doesn't. > to connect to an ipip linux tunnel. Is this right ? Certainly you can do an IP tunnel with the gif interface. > And the nos-tun utility is so a basic replacement of the gif > interface ? I've also been told by people who have done it that nos-tun also works, though it looks a bit kludgy to me, so I haven't tried it. On Thursday, 9 June 2005 at 9:44:39 +0200, Jeremie Le Hen wrote: > > Given the simplicity of gif(4) IP-encapsulated packets, I wonder how > Linux guys could have implemented something else in their IPIP > module :-). Indeed. I'd guess that they got their terminology mixed up, and that they really meant a GRE tunnel. I have spent a *lot* of time scratching my head about this in the last couple of days. The documentation is anything but clear, but it does seem that Linux people prefer GRE. > I never set up such a tunnel between Linux and FreeBSD myself, but > from what I read [1], it seems to work well. > > Please, would you keep us informed whether this setup works for you > or not, it would be certainly worthwhile for the archives. Agreed. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCp/WfIubykFB6QiMRAh4uAJ4zqz2A6qMJ7+snZz5Ktz0d+SDOsACdGivA GWlwr00l+6DCCY/YEzoJ2YQ= =EX9h -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 08:25:33 2005 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 4FE3B16A41C; Thu, 9 Jun 2005 08:25:33 +0000 (GMT) (envelope-from sobomax@web.portaone.com) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6353B43D1F; Thu, 9 Jun 2005 08:25:32 +0000 (GMT) (envelope-from sobomax@web.portaone.com) Received: from www.portaone.com (localhost [127.0.0.1]) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j598PVnV053729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jun 2005 10:25:31 +0200 (CEST) (envelope-from sobomax@web.portaone.com) Received: (from sobomax@localhost) by www.portaone.com (8.12.11/8.12.11/Submit) id j598PUdT053728; Thu, 9 Jun 2005 10:25:30 +0200 (CEST) (envelope-from sobomax) Date: Thu, 9 Jun 2005 10:25:30 +0200 From: Maxim Sobolev To: Brooks Davis Message-ID: <20050609082530.GA44274@www.portaone.com> References: <20050609064452.GC1595@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050609064452.GC1595@odin.ac.hmc.edu> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on www.portaone.com X-Virus-Status: Clean Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: HEADSUP: internal network interface changes 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, 09 Jun 2005 08:25:33 -0000 Hi, I've noticed that in some cases you have removed bcopy() into arpcom.ac_enaddr completely, while in some others have modified it to use IFP2AC(). I wonder if it's a mistake or if there is some logic behind that. Also, it looks like in cdce(4) driver you are referencing if_softc before it's been assigned by if_alloc(): @@ -282,9 +283,13 @@ } } - bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN); + bcopy(eaddr, (char *)&GET_ARPCOM(sc)->ac_enaddr, ETHER_ADDR_LEN); - ifp = GET_IFP(sc); + ifp = GET_IFP(sc) = if_alloc(IFT_ETHER); + if (ifp == NULL) { + printf("%s: can not if_alloc()\n", USBDEVNAME(sc->cdce_dev)); + USB_ATTACH_ERROR_RETURN; + } ifp->if_softc = sc; if_initname(ifp, "cdce", sc->cdce_unit); ifp->if_mtu = ETHERMTU; @@ -323,6 +328,7 @@ GET_ARPCOM(sc) basically dereferences sc->cdce_ifp, which isn't initialized before if_alloc() on the next line. -Maxim On Wed, Jun 08, 2005 at 11:44:52PM -0700, Brooks Davis wrote: > I plan to commit a major rework of network interface related storage > Friday morning PDT. This is a massive change touching every network > driver in the system. This change was discussed at the BSDCan dev > summit and derives from discussions at EuroBSDCon on dealing with > dynamic network devices. You can view the diff at: > > http://people.freebsd.org/~brooks/patches/ifnet.diff > > I'm not posting the diff to the list as it is nearly 700K. Below, you > will find the diff to ifnet(9) for a more technical view of the API > change. > > In short, the change removes the embedded struct ifnet and layer 2 common > structures (struct arpcom, struct ifatm, struct sppp, etc) from driver > softcs and replaces them with a struct ifnet pointer which is allocated > with a new function, if_alloc which takes an interface type. For > certain types, if_alloc also fills in the new struct ifnet member, > if_l2com with an initialized layer 2 common structure. > > The benefits of this change are: > - The size of struct ifnet and the layer 2 common structures is no > longer part of the network interface ABI. This means we add > features to the generic interface code so long as they do not require > action on the part of the driver without breaking the ABI. > - Since storage is no longer tied to the softc, we will able to > reference count struct ifnet more easily which is a prerequisite for > fixing the panics on removing an interface which is configured with > dummynet. > - This patch eliminates many ugly casts and the historically weakly > documented requirement that softc's be castable to ifnet's and > arpcom's. > > Things to note about this change: > - External drivers including those in ports will panic if loaded until > they are converted to the new API. > > Things to note about this patch: > - There are nearly 100 drivers in the tree and I only use a small set > of them so there are likely to be some small bugs in this patch. The > changes were mostly mechanical, but varying naming conventions, plus > the occasional driver written entirely from scratch introduce the > possibility of errors. Use care when updating, particularly with > remote systems. > - In most cases, this patch does not address the issue of keeping > source compatible with previous releases or other systems. I will > supply patches to do so in any case where there is a need, but I > intend to wait until after committing to do so. I hope the set of > drivers requiring these changes will be small. > > -- Brooks > > P.S. the posted patch contains a bug in the udav driver. It will be > fixed before commit. > > --- freebsd/share/man/man9/ifnet.9 Sun Jun 5 13:33:05 2005 > +++ ifnet/share/man/man9/ifnet.9 Sun Jun 5 20:20:03 2005 > @@ -46,9 +46,17 @@ > .In net/if_types.h > .\" > .Ss "Interface Manipulation Functions" > +.Ft "struct ifnet *" > +.Fn if_alloc "u_char type" > .Ft void > .Fn if_attach "struct ifnet *ifp" > .Ft void > +.Fn if_detach "struct ifnet *ifp" > +.Ft void > +.Fn if_free "struct ifnet *ifp" > +.Ft void > +.Fn if_free_type "struct ifnet *ifp" "u_char type" > +.Ft void > .Fn if_down "struct ifnet *ifp" > .Ft int > .Fn ifioctl "struct socket *so" "u_long cmd" "caddr_t data" "struct thread *td" > @@ -219,6 +227,11 @@ > .Pq Vt "void *" > A pointer to the driver's private state block. > (Initialized by driver.) > +.It Va if_l2com > +.Pq Vt "void *" > +A pointer to the common data for the interface's layer 2 protocol. > +(Initialized by > +.Fn if_alloc .) > .It Va if_link > .Pq Fn TAILQ_ENTRY ifnet > .Xr queue 3 > @@ -270,6 +283,8 @@ > to refer to a particular interface by index > (see > .Xr link_addr 3 ) . > +(Initialized by > +.Fn if_alloc .) > .It Va if_timer > .Pq Vt short > Number of seconds until the watchdog timer > @@ -988,6 +1003,14 @@ > .El > .Ss Interface Manipulation Functions > .Bl -ohang -offset indent > +.It Fn if_alloc > +Allocate and initalize an > +.Fa ifp . > +Initalization includes the allocation of an interface index and may > +include the allocation of a > +.Fa type > +specific structure in > +.Va if_l2com . > .It Fn if_attach > Link the specified interface > .Fa ifp > @@ -999,6 +1022,29 @@ > (A pointer to > this address structure is saved in the global array > .Va ifnet_addrs . ) > +The > +.Fa ifp > +must have been allocted by > +.Fn if_alloc . > +.It Fn if_detach > +Shutdown and unlink the specified > +.Fa ifp > +from the interface list. > +.It Fn if_free > +Free the given > +.Fa ifp > +back to the system. > +The interface must have been previously detached if it was ever attached. > +.It Fn if_free_type > +Identical to > +.Fn if_free > +except that the given > +.Fa type > + is used to free > + .Va if_l2com > + instead of the type in > + .Va if_type . > + This is intended for use with drivers that change their interface type. > .It Fn if_down > Mark the interface > .Fa ifp > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 08:30:11 2005 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 6219B16A41C; Thu, 9 Jun 2005 08:30:11 +0000 (GMT) (envelope-from sobomax@web.portaone.com) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B51B643D1D; Thu, 9 Jun 2005 08:30:10 +0000 (GMT) (envelope-from sobomax@web.portaone.com) Received: from www.portaone.com (localhost [127.0.0.1]) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j598U9Ra054156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jun 2005 10:30:09 +0200 (CEST) (envelope-from sobomax@web.portaone.com) Received: (from sobomax@localhost) by www.portaone.com (8.12.11/8.12.11/Submit) id j598U9K8054155; Thu, 9 Jun 2005 10:30:09 +0200 (CEST) (envelope-from sobomax) Date: Thu, 9 Jun 2005 10:30:09 +0200 From: Maxim Sobolev To: Brooks Davis Message-ID: <20050609083009.GB44274@www.portaone.com> References: <20050609064452.GC1595@odin.ac.hmc.edu> <20050609082530.GA44274@www.portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050609082530.GA44274@www.portaone.com> User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on www.portaone.com X-Virus-Status: Clean Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: HEADSUP: internal network interface changes 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, 09 Jun 2005 08:30:11 -0000 On Thu, Jun 09, 2005 at 10:25:30AM +0200, Maxim Sobolev wrote: > Also, it looks like in cdce(4) driver you are referencing > if_softc before it's been assigned by if_alloc(): ^^^^^^^^ <- cdce_ifp -Maxim From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 09:48:35 2005 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 3B8B816A41C for ; Thu, 9 Jun 2005 09:48:35 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt9.ihug.co.nz (grunt9.ihug.co.nz [203.109.254.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F4A43D1D for ; Thu, 9 Jun 2005 09:48:33 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt9.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1DgJeF-0000cK-00; Thu, 09 Jun 2005 21:48:27 +1200 Received: from 203-173-146-91.bliink.ihug.co.nz ([203.173.146.91] helo=[192.168.1.6]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1DgJeE-0004sw-6s; Thu, 09 Jun 2005 21:48:26 +1200 Message-ID: <42A81065.8010603@luckie.org.nz> Date: Thu, 09 Jun 2005 21:48:21 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <4295A6CA.8080409@luckie.org.nz> <20050606081637.GA73886@lycra.luckie.org.nz> <20050606120851.GD734@empiric.icir.org> <20050606204008.GA91353@lycra.luckie.org.nz> <20050607101927.GA99034@lycra.luckie.org.nz> <20050607112340.GC812@empiric.icir.org> In-Reply-To: <20050607112340.GC812@empiric.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bpf writes on tun device 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, 09 Jun 2005 09:48:35 -0000 > I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to > get review for the change from the NetBSD and OpenBSD guys too, as well as > the tcpdump.org guys. I posted a patch to netbsd tech-kern and have had positive feedback: http://mail-index.netbsd.org/tech-net/2005/06/09/0003.html I posted to tcpdump-workers and have had no response at this time: http://marc.theaimsgroup.com/?l=tcpdump-workers&m=111818619022560&w=2 I do, however, feel that this is a safe patch to apply, and one that I'd really like to see make it to 6.0. > Looking at style, it might be better if the driver(s) were changed to > explicitly use a 32-bit wide int type such as u_int32_t for the address > family header field in their bpfattach() calls. ICHDRLEN is odd man out, > but it is #define'd to be the same thing; I would update it there also. I'll do some house keeping on the patch and then re-send it. I take it a PR is the right place to send the patch? > A white space pass should probably also be done last thing to be sure. > I have no idea about ng_sppp.c I'm afraid. I'll make a note in the PR about ng_sppp.c; but there does not appear to be any output function specific to ng_sppp so I think it is safe to leave alone. Thanks Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 15:40:20 2005 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 118DA16A41C; Thu, 9 Jun 2005 15:40:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE32143D4C; Thu, 9 Jun 2005 15:40:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j59FeIQw012531; Thu, 9 Jun 2005 08:40:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j59FeI2Y012530; Thu, 9 Jun 2005 08:40:18 -0700 Date: Thu, 9 Jun 2005 08:40:18 -0700 From: Brooks Davis To: Maxim Sobolev Message-ID: <20050609154017.GC9171@odin.ac.hmc.edu> References: <20050609064452.GC1595@odin.ac.hmc.edu> <20050609082530.GA44274@www.portaone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: <20050609082530.GA44274@www.portaone.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: HEADSUP: internal network interface changes 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, 09 Jun 2005 15:40:20 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2005 at 10:25:30AM +0200, Maxim Sobolev wrote: > Hi, >=20 > I've noticed that in some cases you have removed bcopy() > into arpcom.ac_enaddr completely, while in some others > have modified it to use IFP2AC(). I wonder if it's a mistake > or if there is some logic behind that. Good catch, these are bugs. I'll do another sweep. The problems is that I did the inital sweep based on some macros and not quite everything was converted. > Also, it looks like in cdce(4) driver you are referencing > if_softc before it's been assigned by if_alloc(): >=20 > @@ -282,9 +283,13 @@ > } > } > =20 > - bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN); > + bcopy(eaddr, (char *)&GET_ARPCOM(sc)->ac_enaddr, ETHER_ADDR_LEN); > =20 > - ifp =3D GET_IFP(sc); > + ifp =3D GET_IFP(sc) =3D if_alloc(IFT_ETHER); > + if (ifp =3D=3D NULL) { > + printf("%s: can not if_alloc()\n", USBDEVNAME(sc->cdce_dev)); > + USB_ATTACH_ERROR_RETURN; > + } > ifp->if_softc =3D sc; > if_initname(ifp, "cdce", sc->cdce_unit); > ifp->if_mtu =3D ETHERMTU; > @@ -323,6 +328,7 @@ >=20 > GET_ARPCOM(sc) basically dereferences sc->cdce_ifp, which isn't > initialized before if_alloc() on the next line. Yup, I got tripped up becuase this doesn't use the macro I introduced. Thanks for the review! -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCqGLhXY6L6fI4GtQRAgEMAKDeENIFYi8flScFRxZ0tG2Dapo3mACeNI9o 9zjNKeE9vqrTpJzVuIZswc0= =aC7l -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 21:12:11 2005 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 9B09316A41C for ; Thu, 9 Jun 2005 21:12:11 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 593B343D1F for ; Thu, 9 Jun 2005 21:12:11 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so364618nzo for ; Thu, 09 Jun 2005 14:12:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VHtMo43vBv1nj3+g8m0LWox1A7DlsKJ4vAMBffmc11TrA/xT1LN96GL/2xoMYxBrWBrJggmR8mZR+3hYrms40Lykd1kwp97PzvYrrNA9FWBW98xgAaoLLzbSbP/QTLNhfjO6Fb3yfp4GqsJ7VwIglBWlDeGx5TU0qmS5e3PDfSg= Received: by 10.36.46.20 with SMTP id t20mr662385nzt; Thu, 09 Jun 2005 14:12:07 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 9 Jun 2005 14:12:07 -0700 (PDT) Message-ID: <79722fad05060914123edd1004@mail.gmail.com> Date: Fri, 10 Jun 2005 00:12:07 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Please review & test this X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 21:12:11 -0000 As you may all know, the packet classifier in ALTQ is very slow on large numbers of classes, because it stores them linearly, in an array. I rewrote the way classes are stored, replacing the array with a hash table. I tested [1] on a system with about 8000 classes and noticed a remarkable performance difference (the system went from almost unusable to nice & smooth). It breaks the ABI by adding an extra TAILQ_ENTRY member to the HFSC class structure, though. If anyone reviews and tests it, I would be grateful. [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff P.S. please keep in mind that I'm not exactly a black belt in kernel programming, so glitches might exist. I would be most happy to hear some suggestions. --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 21:42:17 2005 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 6289916A41C for ; Thu, 9 Jun 2005 21:42:17 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id C87DB43D53 for ; Thu, 9 Jun 2005 21:42:16 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so123370nzp for ; Thu, 09 Jun 2005 14:42:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=PILJNZ1v3iTIK9b8juHQNbIrv7yqkcWaSCLBq2MrIm1uBFZLhQMIIYf9FNtTHAFNqD3X+VOaHsO89e4GxtfPxUNnc7M8Jdpb6cRGQjLdjU0rXiihWYOihbRNeTCi9VbcnSgI+dR0ZuOjON8CnydZW9aW18Ur00Gs0V9IrkIFr6w= Received: by 10.36.222.42 with SMTP id u42mr773775nzg; Thu, 09 Jun 2005 14:42:16 -0700 (PDT) Received: by 10.36.58.12 with HTTP; Thu, 9 Jun 2005 14:42:16 -0700 (PDT) Message-ID: <37273927050609144244862086@mail.gmail.com> Date: Thu, 9 Jun 2005 17:42:16 -0400 From: Aziz Kezzou To: freebsd-hackers , freebsd-net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: How to do a routing lookup inside the kernel in FreeBSD ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aziz Kezzou List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 21:42:17 -0000 Hi all, I am trying to figure out from the kernel source code (FreeBSD 5.3) how can I perform a routing lookup in a KLD module. Since I am short in time, if anyone knows how do to do this I would appreciate. Any pointers to the right portion of the code are also apperciated. Thanks, -aziz From owner-freebsd-net@FreeBSD.ORG Thu Jun 9 22:10:13 2005 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 01E1316A41C for ; Thu, 9 Jun 2005 22:10:13 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CD443D4C for ; Thu, 9 Jun 2005 22:10:12 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so385687nzo for ; Thu, 09 Jun 2005 15:10:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mr6oUfqzLFEeY/3sv9sHSjTTPiOhzpJvzY2AmbYNbxMITig0JmQVIBB28T2K5diClY4AayAP2UOD07ZHqRatY93Tfd3JWfqf6bsVou9Tyo96jxJdConTOq000WQLk/smZ73Sbf0Y/NwcrTmhNZgKbyYOd+O95f2hyjeqGgC3qN8= Received: by 10.36.34.2 with SMTP id h2mr710951nzh; Thu, 09 Jun 2005 15:10:11 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 9 Jun 2005 15:10:11 -0700 (PDT) Message-ID: <79722fad050609151068c71c91@mail.gmail.com> Date: Fri, 10 Jun 2005 01:10:11 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad05060914123edd1004@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 22:10:13 -0000 On 6/10/05, Vlad GALU wrote: > As you may all know, the packet classifier in ALTQ is very > slow on large numbers of classes, because it stores them linearly, in > an array. I rewrote the way classes are stored, replacing the array > with a hash table. I tested [1] on a system with about 8000 classes > and noticed a remarkable performance difference (the system went from > almost unusable to nice & smooth). It breaks the ABI by adding an > extra TAILQ_ENTRY member to the HFSC class structure, though.=20 And also replaces the class array in struct hfsc_if with the hash table. > If anyone reviews and tests it, I would be grateful. >=20 > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff >=20 > P.S. please keep in mind that I'm not exactly a black belt in kernel > programming, so glitches might exist. I would be most happy to hear > some suggestions. >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 06:23:44 2005 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 0AF5E16A41C for ; Fri, 10 Jun 2005 06:23:44 +0000 (GMT) (envelope-from martin@mullet.se) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D6943D4C for ; Fri, 10 Jun 2005 06:23:42 +0000 (GMT) (envelope-from martin@mullet.se) Received: from as6-1-5.kr.m.bonet.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20050610062341.CSFA19329.mxfep01.bredband.com@as6-1-5.kr.m.bonet.se>; Fri, 10 Jun 2005 08:23:41 +0200 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id 646ED6786C; Fri, 10 Jun 2005 08:23:41 +0200 (CEST) Message-ID: <42A931ED.8020601@mullet.se> Date: Fri, 10 Jun 2005 08:23:41 +0200 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: timt@sharktech.net References: <1118026528.42a3bb20a76ce@webmail.sharktech.net> In-Reply-To: <1118026528.42a3bb20a76ce@webmail.sharktech.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: LSI MegaRaid 150-6 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, 10 Jun 2005 06:23:44 -0000 timt@sharktech.net wrote: > Hello, > > This is the 2nd time I search for a resolution on this matter I could not find > any documents online regarding this issue. Why do you post to -net & -bugs, these are not the right lists for this kind of questions. stable or questions is better, and please don't cross-post. > At first we started installing FreeBSD5.4-RELEASE AMD64 LSI Megaraid was > detected and raid was running in optimal. When it asked me to choose the slice > it gave me a warning that the geometry for the drive is incorrect and to check > with the BIOS for the true geometry and if this is a SCSI please check with the > controller's algorithem (something). Which I searched online for with no clues. This is probably harmless, I've never had any problems with it. > Anyways went to system installation it starts installing bursting to 2600KB/s > and after 55% it goes down to 800KB/s than when reaching ports it goes down to > 33KB/s and this is CDROM installation!! The ports are lots of small files it takes time to write these to disk, this is normal. > When system is installed completly we ran dd on the system a constant average of > 2.1MB/s is the BEST performance we could get! Check that the write cache are enabled on all your SATA disks in CTRL-M objects->physical drive. I have run the 150-4/6 at over 100MB/s in FreeBSD so there should be no problem with this setup. Best Regards, Martin -- Martin Nilsson, CTO & Founder, Mullet Scandinavia AB, Malmö, SWEDEN E-mail: martin@mullet.se, Phone: +46-(0)708-606170, Web: www.mullet.se Our business is well engineered servers optimised for FreeBSD & Linux From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 07:41:11 2005 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 C5A2E16A484; Fri, 10 Jun 2005 07:41:11 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 079BC43D48; Fri, 10 Jun 2005 07:41:10 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5A7f9b8039040; Fri, 10 Jun 2005 10:41:09 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 38127-09; Fri, 10 Jun 2005 10:41:08 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5A7f89i039037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2005 10:41:08 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j5A7fake078777; Fri, 10 Jun 2005 10:41:36 +0300 (EEST) (envelope-from ru) Date: Fri, 10 Jun 2005 10:41:26 +0300 From: Ruslan Ermilov To: Aziz Kezzou Message-ID: <20050610074126.GD78035@ip.net.ua> References: <37273927050609144244862086@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nYySOmuH/HDX6pKp" Content-Disposition: inline In-Reply-To: <37273927050609144244862086@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-hackers , freebsd-net Subject: Re: How to do a routing lookup inside the kernel in FreeBSD ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 07:41:12 -0000 --nYySOmuH/HDX6pKp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2005 at 05:42:16PM -0400, Aziz Kezzou wrote: > Hi all, > I am trying to figure out from the kernel source code (FreeBSD 5.3) > how can I perform a routing lookup in a KLD module. > Since I am short in time, if anyone knows how do to do this I would > appreciate. Any pointers to the right portion of the code are also > apperciated. >=20 man 9 rtalloc Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --nYySOmuH/HDX6pKp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqUQmqRfpzJluFF4RAugrAJ9Nblt1pnzg8l3oprv+yhX4lg3xnwCgjp+e baQpYwlk9OI9cIpofqzWim0= =Mry1 -----END PGP SIGNATURE----- --nYySOmuH/HDX6pKp-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 09:48:03 2005 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 8C81C16A43A for ; Fri, 10 Jun 2005 09:48:03 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B28443D1F for ; Fri, 10 Jun 2005 09:48:02 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id B5F67A3F6C for ; Fri, 10 Jun 2005 11:48:00 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14006-03 for ; Fri, 10 Jun 2005 11:48:00 +0200 (CEST) Received: from [192.168.1.159] (pf-raglon.int.packetfront.com [192.168.1.159]) by mail.packetfront.com (Postfix) with ESMTP id 74228A3F67 for ; Fri, 10 Jun 2005 11:48:00 +0200 (CEST) Message-ID: <42A961CA.5030706@packetfront.com> Date: Fri, 10 Jun 2005 11:47:54 +0200 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <200505192159.j4JLxNhb060631@atalus.net> <428DF2FF.3010408@oxygen.az> In-Reply-To: <428DF2FF.3010408@oxygen.az> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Subject: IPC between vimage instances? 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, 10 Jun 2005 09:48:03 -0000 Hello, I've been using vimage on FreeBSD 4.11 along with Netgraph to setup a system that simulates many physical client machines for the purpose of testing broadband Internet access hardware. I have hundreds of vimages, each with its own ngeth0 network interface connected via Netgraph to a real physical interface. It is working very well indeed but now I'm trying to setup logging from the various vimage instances and have run into problems. Each vimage runs applications that I want to log the output from in an orderly manner. I'd like to use syslog but as it turns out, the processes inside a vimage cannot communicate with the syslogd in the "default" vimage. I tried logging to the Unix domain socket /var/run/log but that didn't work from within a vimage (other than "default" of course). What ways are there to do IPC between applications in different vimages? I know I can connect them using Netgraph and virtual network interfaces but setting up more network interfaces means a lot of housekeeping as those interfaces can't be removed when I remove vimages from the system. I dont want to send actual traffic out onto the network either, as that might interfere with the test traffic to/from the machine. Any ideas? Regards, /Ragnar From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 13:40:27 2005 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 E6AD516A41C for ; Fri, 10 Jun 2005 13:40:27 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F48943D49 for ; Fri, 10 Jun 2005 13:40:26 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5ADeOx1003765 for ; Fri, 10 Jun 2005 16:40:24 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 54297-14 for ; Fri, 10 Jun 2005 16:40:23 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5ADeNCS003762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jun 2005 16:40:23 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j5ADepKl080797 for net@FreeBSD.org; Fri, 10 Jun 2005 16:40:51 +0300 (EEST) (envelope-from ru) Date: Fri, 10 Jun 2005 16:40:41 +0300 From: Ruslan Ermilov To: net@FreeBSD.org Message-ID: <20050610134041.GC79872@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c3bfwLpm8qysLVxt" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Subject: ng_dummy(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: Fri, 10 Jun 2005 13:40:28 -0000 --c3bfwLpm8qysLVxt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've ported Marco Zec's ng_dummy(4) to work under 5.x/6.x. If anyone finds this useful, here's the link: http://people.FreeBSD.org/~ru/ng_dummy.c The rest of sources is available from: http://www.tel.fer.hr/zec/BSD/ng_dummy/ng_dummy-20021015.tgz I plan on more cleanup, and will post here when updates are ready. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --c3bfwLpm8qysLVxt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqZhZqRfpzJluFF4RAgQLAKCX1o3eO+JH7xADNojv3yFzl9qFZACdHy7r jYxYnuPot7PUa8rZAegpGb4= =Rw1R -----END PGP SIGNATURE----- --c3bfwLpm8qysLVxt-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 16:00:33 2005 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 D2DD916A420 for ; Fri, 10 Jun 2005 16:00:33 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6541943D48 for ; Fri, 10 Jun 2005 16:00:33 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so701811wri for ; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mvVhETEiTR+1IgEmzf3MVqh0Ena5MIhhPFD5yKWeyPv/4yHgCH0DB+KnWgaVNhjClHxUO0g6lrRviuP4KpoAc3bkDflQkEVeBvpL4GFbLhmiP7Ea7Me/FX50/TLdmFGhyqmlBDzNCoN6I5wDfgf2px3WqE15eiIOszddaRbBPlA= Received: by 10.54.33.53 with SMTP id g53mr1045620wrg; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Fri, 10 Jun 2005 09:00:32 -0700 (PDT) Message-ID: <7c8f2792050610090049064e11@mail.gmail.com> Date: Fri, 10 Jun 2005 12:00:32 -0400 From: Josh Kayse To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Carp Suppression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 16:00:33 -0000 I am cross-posting this to -net and -pf because I am not sure where it goes= . I am running 2 carp interfaces on a pair of transparent firewalls running FreeBSD 5.4. One of the interfaces is a xl interface and the other is a plip interface. I am having trouble in that the carp interfaces are not failing over between the 2 machines. When I check net.inet.carp.suppress_preempt it returns 1 and I do not understand why that is. Can anyone shed some light on this? If you need any more information, just let me know. Thanks Josh --=20 Joshua Kayse Computer Engineering From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 16:26:01 2005 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 9755C16A41C; Fri, 10 Jun 2005 16:26:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5221543D53; Fri, 10 Jun 2005 16:26:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5AGQ0jv014247; Fri, 10 Jun 2005 09:26:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5AGQ0ut014246; Fri, 10 Jun 2005 09:26:00 -0700 Date: Fri, 10 Jun 2005 09:26:00 -0700 From: Brooks Davis To: Brooks Davis Message-ID: <20050610162600.GA12928@odin.ac.hmc.edu> References: <20050609064452.GC1595@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20050609064452.GC1595@odin.ac.hmc.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org, net@freebsd.org Subject: Re: HEADSUP: internal network interface changes 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, 10 Jun 2005 16:26:01 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Look out! :-) This change is incoming sortly (pending final cvs updates). -- Brooks On Wed, Jun 08, 2005 at 11:44:52PM -0700, Brooks Davis wrote: > I plan to commit a major rework of network interface related storage > Friday morning PDT. This is a massive change touching every network > driver in the system. This change was discussed at the BSDCan dev > summit and derives from discussions at EuroBSDCon on dealing with > dynamic network devices. You can view the diff at: >=20 > http://people.freebsd.org/~brooks/patches/ifnet.diff >=20 > I'm not posting the diff to the list as it is nearly 700K. Below, you > will find the diff to ifnet(9) for a more technical view of the API > change. >=20 > In short, the change removes the embedded struct ifnet and layer 2 common > structures (struct arpcom, struct ifatm, struct sppp, etc) from driver > softcs and replaces them with a struct ifnet pointer which is allocated > with a new function, if_alloc which takes an interface type. For > certain types, if_alloc also fills in the new struct ifnet member, > if_l2com with an initialized layer 2 common structure. >=20 > The benefits of this change are: > - The size of struct ifnet and the layer 2 common structures is no > longer part of the network interface ABI. This means we add > features to the generic interface code so long as they do not require > action on the part of the driver without breaking the ABI. > - Since storage is no longer tied to the softc, we will able to > reference count struct ifnet more easily which is a prerequisite for > fixing the panics on removing an interface which is configured with > dummynet. > - This patch eliminates many ugly casts and the historically weakly > documented requirement that softc's be castable to ifnet's and > arpcom's. >=20 > Things to note about this change: > - External drivers including those in ports will panic if loaded until > they are converted to the new API. >=20 > Things to note about this patch: > - There are nearly 100 drivers in the tree and I only use a small set > of them so there are likely to be some small bugs in this patch. The > changes were mostly mechanical, but varying naming conventions, plus > the occasional driver written entirely from scratch introduce the > possibility of errors. Use care when updating, particularly with > remote systems. > - In most cases, this patch does not address the issue of keeping > source compatible with previous releases or other systems. I will > supply patches to do so in any case where there is a need, but I > intend to wait until after committing to do so. I hope the set of > drivers requiring these changes will be small. >=20 > -- Brooks >=20 > P.S. the posted patch contains a bug in the udav driver. It will be > fixed before commit. >=20 > --- freebsd/share/man/man9/ifnet.9 Sun Jun 5 13:33:05 2005 > +++ ifnet/share/man/man9/ifnet.9 Sun Jun 5 20:20:03 2005 > @@ -46,9 +46,17 @@ > .In net/if_types.h > .\" > .Ss "Interface Manipulation Functions" > +.Ft "struct ifnet *" > +.Fn if_alloc "u_char type" > .Ft void > .Fn if_attach "struct ifnet *ifp" > .Ft void > +.Fn if_detach "struct ifnet *ifp" > +.Ft void > +.Fn if_free "struct ifnet *ifp" > +.Ft void > +.Fn if_free_type "struct ifnet *ifp" "u_char type" > +.Ft void > .Fn if_down "struct ifnet *ifp" > .Ft int > .Fn ifioctl "struct socket *so" "u_long cmd" "caddr_t data" "struct thre= ad *td" > @@ -219,6 +227,11 @@ > .Pq Vt "void *" > A pointer to the driver's private state block. > (Initialized by driver.) > +.It Va if_l2com > +.Pq Vt "void *" > +A pointer to the common data for the interface's layer 2 protocol. > +(Initialized by > +.Fn if_alloc .) > .It Va if_link > .Pq Fn TAILQ_ENTRY ifnet > .Xr queue 3 > @@ -270,6 +283,8 @@ > to refer to a particular interface by index > (see > .Xr link_addr 3 ) . > +(Initialized by > +.Fn if_alloc .) > .It Va if_timer > .Pq Vt short > Number of seconds until the watchdog timer > @@ -988,6 +1003,14 @@ > .El > .Ss Interface Manipulation Functions > .Bl -ohang -offset indent > +.It Fn if_alloc > +Allocate and initalize an > +.Fa ifp . > +Initalization includes the allocation of an interface index and may > +include the allocation of a > +.Fa type > +specific structure in > +.Va if_l2com . > .It Fn if_attach > Link the specified interface > .Fa ifp > @@ -999,6 +1022,29 @@ > (A pointer to > this address structure is saved in the global array > .Va ifnet_addrs . ) > +The > +.Fa ifp > +must have been allocted by > +.Fn if_alloc . > +.It Fn if_detach > +Shutdown and unlink the specified > +.Fa ifp > +from the interface list. > +.It Fn if_free > +Free the given > +.Fa ifp > +back to the system. > +The interface must have been previously detached if it was ever attached. > +.It Fn if_free_type > +Identical to > +.Fn if_free > +except that the given > +.Fa type > + is used to free=20 > + .Va if_l2com > + instead of the type in > + .Va if_type . > + This is intended for use with drivers that change their interface type. > .It Fn if_down > Mark the interface > .Fa ifp >=20 > --=20 > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCqb8XXY6L6fI4GtQRAtjvAJ0do2XnwBUmAVPz4H+upM2DHtkQbACfazeW oZ11O5VqBMPEfr40rPGrs9Y= =6O8l -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 16:37:51 2005 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 1DDA316A41C for ; Fri, 10 Jun 2005 16:37:51 +0000 (GMT) (envelope-from lysergius2001@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C3743D4C for ; Fri, 10 Jun 2005 16:37:50 +0000 (GMT) (envelope-from lysergius2001@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so898512wra for ; Fri, 10 Jun 2005 09:37:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=o4mBwhR3w5JjQ7622xj1JGKoDIoC9eExCNzePER5Len8fe5lV51L1pciO9fzsOTrU0yXkhIvKIt2mkl431U/CWyQCDJGVZMM1Tp60lF9xishQg9w/yagj5VVEmgqdQqmeslubeh6OW0AyYlQSV0h28itA+IHiPfv5v2q5LIdPAo= Received: by 10.54.36.66 with SMTP id j66mr1057942wrj; Fri, 10 Jun 2005 09:37:49 -0700 (PDT) Received: by 10.54.66.3 with HTTP; Fri, 10 Jun 2005 09:37:49 -0700 (PDT) Message-ID: Date: Fri, 10 Jun 2005 17:37:49 +0100 From: lysergius2001 To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ndiscvt make failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lysergius2001 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 16:37:51 -0000 Make of ndiscvt breaks with the following error message. Can anyone help? I= =20 am still stuck. =20 Warning: Object directory not changed from original=20 /usr/src/sys/modules/if_ndis cc -O -pipe -march=3Dathlon-xp -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@= =20 -I@/contrib/altq -I@/../include -finline-limit=3D8000 -fno-common=20 -mno-align-long-strings -mpreferred-stack-boundary=3D2 -ffreestanding -Wall= =20 -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes= =20 -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=3Dc99 -c=20 /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c=20 *** Error code 1 Stop in /usr/src/sys/modules/if_ndis. Many thanks --=20 Lysergius says, "Stay light, but trust gravity" From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 16:57:26 2005 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 2314F16A41C; Fri, 10 Jun 2005 16:57:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD2FD43D49; Fri, 10 Jun 2005 16:57:25 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5AGvOXg018509; Fri, 10 Jun 2005 09:57:24 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5AGvOnl018508; Fri, 10 Jun 2005 09:57:24 -0700 Date: Fri, 10 Jun 2005 09:57:24 -0700 From: Brooks Davis To: Brooks Davis Message-ID: <20050610165724.GA17120@odin.ac.hmc.edu> References: <20050609064452.GC1595@odin.ac.hmc.edu> <20050610162600.GA12928@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20050610162600.GA12928@odin.ac.hmc.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org, net@freebsd.org Subject: Re: HEADSUP: internal network interface changes 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, 10 Jun 2005 16:57:26 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2005 at 09:26:00AM -0700, Brooks Davis wrote: > Look out! :-) >=20 > This change is incoming sortly (pending final cvs updates). I've committed the change bumping __FreeBSD_version. Hopefully the ride won't be too bumpy. If you have any problems, please report them on -current as well as to me directly. Most problems should be fairly simple to fix. I will be checking my e-mail regularly for at least the next 14 hours. -- Brooks > On Wed, Jun 08, 2005 at 11:44:52PM -0700, Brooks Davis wrote: > > I plan to commit a major rework of network interface related storage > > Friday morning PDT. This is a massive change touching every network > > driver in the system. This change was discussed at the BSDCan dev > > summit and derives from discussions at EuroBSDCon on dealing with > > dynamic network devices. You can view the diff at: > >=20 > > http://people.freebsd.org/~brooks/patches/ifnet.diff > >=20 > > I'm not posting the diff to the list as it is nearly 700K. Below, you > > will find the diff to ifnet(9) for a more technical view of the API > > change. > >=20 > > In short, the change removes the embedded struct ifnet and layer 2 comm= on > > structures (struct arpcom, struct ifatm, struct sppp, etc) from driver > > softcs and replaces them with a struct ifnet pointer which is allocated > > with a new function, if_alloc which takes an interface type. For > > certain types, if_alloc also fills in the new struct ifnet member, > > if_l2com with an initialized layer 2 common structure. > >=20 > > The benefits of this change are: > > - The size of struct ifnet and the layer 2 common structures is no > > longer part of the network interface ABI. This means we add > > features to the generic interface code so long as they do not require > > action on the part of the driver without breaking the ABI. > > - Since storage is no longer tied to the softc, we will able to > > reference count struct ifnet more easily which is a prerequisite for > > fixing the panics on removing an interface which is configured with > > dummynet. > > - This patch eliminates many ugly casts and the historically weakly > > documented requirement that softc's be castable to ifnet's and > > arpcom's. > >=20 > > Things to note about this change: > > - External drivers including those in ports will panic if loaded until > > they are converted to the new API. > >=20 > > Things to note about this patch: > > - There are nearly 100 drivers in the tree and I only use a small set > > of them so there are likely to be some small bugs in this patch. The > > changes were mostly mechanical, but varying naming conventions, plus > > the occasional driver written entirely from scratch introduce the > > possibility of errors. Use care when updating, particularly with > > remote systems. > > - In most cases, this patch does not address the issue of keeping > > source compatible with previous releases or other systems. I will > > supply patches to do so in any case where there is a need, but I > > intend to wait until after committing to do so. I hope the set of > > drivers requiring these changes will be small. > >=20 > > -- Brooks > >=20 > > P.S. the posted patch contains a bug in the udav driver. It will be > > fixed before commit. > >=20 > > --- freebsd/share/man/man9/ifnet.9 Sun Jun 5 13:33:05 2005 > > +++ ifnet/share/man/man9/ifnet.9 Sun Jun 5 20:20:03 2005 > > @@ -46,9 +46,17 @@ > > .In net/if_types.h > > .\" > > .Ss "Interface Manipulation Functions" > > +.Ft "struct ifnet *" > > +.Fn if_alloc "u_char type" > > .Ft void > > .Fn if_attach "struct ifnet *ifp" > > .Ft void > > +.Fn if_detach "struct ifnet *ifp" > > +.Ft void > > +.Fn if_free "struct ifnet *ifp" > > +.Ft void > > +.Fn if_free_type "struct ifnet *ifp" "u_char type" > > +.Ft void > > .Fn if_down "struct ifnet *ifp" > > .Ft int > > .Fn ifioctl "struct socket *so" "u_long cmd" "caddr_t data" "struct th= read *td" > > @@ -219,6 +227,11 @@ > > .Pq Vt "void *" > > A pointer to the driver's private state block. > > (Initialized by driver.) > > +.It Va if_l2com > > +.Pq Vt "void *" > > +A pointer to the common data for the interface's layer 2 protocol. > > +(Initialized by > > +.Fn if_alloc .) > > .It Va if_link > > .Pq Fn TAILQ_ENTRY ifnet > > .Xr queue 3 > > @@ -270,6 +283,8 @@ > > to refer to a particular interface by index > > (see > > .Xr link_addr 3 ) . > > +(Initialized by > > +.Fn if_alloc .) > > .It Va if_timer > > .Pq Vt short > > Number of seconds until the watchdog timer > > @@ -988,6 +1003,14 @@ > > .El > > .Ss Interface Manipulation Functions > > .Bl -ohang -offset indent > > +.It Fn if_alloc > > +Allocate and initalize an > > +.Fa ifp . > > +Initalization includes the allocation of an interface index and may > > +include the allocation of a > > +.Fa type > > +specific structure in > > +.Va if_l2com . > > .It Fn if_attach > > Link the specified interface > > .Fa ifp > > @@ -999,6 +1022,29 @@ > > (A pointer to > > this address structure is saved in the global array > > .Va ifnet_addrs . ) > > +The > > +.Fa ifp > > +must have been allocted by > > +.Fn if_alloc . > > +.It Fn if_detach > > +Shutdown and unlink the specified > > +.Fa ifp > > +from the interface list. > > +.It Fn if_free > > +Free the given > > +.Fa ifp > > +back to the system. > > +The interface must have been previously detached if it was ever attach= ed. > > +.It Fn if_free_type > > +Identical to > > +.Fn if_free > > +except that the given > > +.Fa type > > + is used to free=20 > > + .Va if_l2com > > + instead of the type in > > + .Va if_type . > > + This is intended for use with drivers that change their interface typ= e. > > .It Fn if_down > > Mark the interface > > .Fa ifp > >=20 > > --=20 > > Any statement of the form "X is the one, true Y" is FALSE. > > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 >=20 >=20 > --=20 > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCqcZzXY6L6fI4GtQRAh4/AKCFsF2nC2uqoGgSyyer6jAxCt53YgCeMd6l pmH2ttrG7PdVscM32rpMegY= =j52+ -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 18:11:52 2005 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 D3C2B16A41C for ; Fri, 10 Jun 2005 18:11:52 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5DA043D1D for ; Fri, 10 Jun 2005 18:11:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 133667A424; Fri, 10 Jun 2005 11:11:51 -0700 (PDT) Message-ID: <42A9D7E7.1020504@elischer.org> Date: Fri, 10 Jun 2005 11:11:51 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ragnar Lonn References: <200505192159.j4JLxNhb060631@atalus.net> <428DF2FF.3010408@oxygen.az> <42A961CA.5030706@packetfront.com> In-Reply-To: <42A961CA.5030706@packetfront.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPC between vimage instances? 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, 10 Jun 2005 18:11:52 -0000 Ragnar Lonn wrote: > Hello, > > I've been using vimage on FreeBSD 4.11 along with Netgraph to setup a > system > that simulates many physical client machines for the purpose of > testing broadband > Internet access hardware. I have hundreds of vimages, each with its > own ngeth0 > network interface connected via Netgraph to a real physical interface. > It is working > very well indeed but now I'm trying to setup logging from the various > vimage > instances and have run into problems. Each vimage runs applications that > I want to log the output from in an orderly manner. I'd like to use > syslog but as > it turns out, the processes inside a vimage cannot communicate with > the syslogd > in the "default" vimage. I tried logging to the Unix domain socket > /var/run/log but > that didn't work from within a vimage (other than "default" of course). did you ask syslog to open sockets in all the chroots? I assume yes.. I hadn't realised that the vimage code separates unix domain sockets etc. but I guess that makes sense. As you mention, the usual answer is to get the syslog on each system to forward everything to one logging system. you could add a second interface to each vimage just for logging to keep it separate from the testing.. > > What ways are there to do IPC between applications in different vimages? > > I know I can connect them using Netgraph and virtual network > interfaces but > setting up more network interfaces means a lot of housekeeping as > those interfaces > can't be removed when I remove vimages from the system. I dont want to > send > actual traffic out onto the network either, as that might interfere > with the test > traffic to/from the machine. > > Any ideas? > > Regards, > > /Ragnar > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 18:18:25 2005 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 68B7316A41C; Fri, 10 Jun 2005 18:18:25 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42CE643D48; Fri, 10 Jun 2005 18:18:25 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 239AD7A403; Fri, 10 Jun 2005 11:18:25 -0700 (PDT) Message-ID: <42A9D971.10405@elischer.org> Date: Fri, 10 Jun 2005 11:18:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ruslan Ermilov References: <20050610134041.GC79872@ip.net.ua> In-Reply-To: <20050610134041.GC79872@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ng_dummy(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: Fri, 10 Jun 2005 18:18:25 -0000 you can remove the whistle copyright line.. this is unrecognisable from whatever he started with :-) Ruslan Ermilov wrote: >Hi, > >I've ported Marco Zec's ng_dummy(4) to work under 5.x/6.x. If >anyone finds this useful, here's the link: > > http://people.FreeBSD.org/~ru/ng_dummy.c > >The rest of sources is available from: > > http://www.tel.fer.hr/zec/BSD/ng_dummy/ng_dummy-20021015.tgz > >I plan on more cleanup, and will post here when updates are ready. > > >Cheers, > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 18:56:58 2005 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 EB71116A41C for ; Fri, 10 Jun 2005 18:56:58 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4529F43D49 for ; Fri, 10 Jun 2005 18:56:57 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5AIuqWP020283; Fri, 10 Jun 2005 21:56:52 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 64650-10; Fri, 10 Jun 2005 21:56:51 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5AIupmU020280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2005 21:56:51 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j5AIvJeF082234; Fri, 10 Jun 2005 21:57:19 +0300 (EEST) (envelope-from ru) Date: Fri, 10 Jun 2005 21:57:14 +0300 From: Ruslan Ermilov To: Julian Elischer Message-ID: <20050610185713.GD79474@ip.net.ua> References: <20050610134041.GC79872@ip.net.ua> <42A9D971.10405@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <42A9D971.10405@elischer.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: net@freebsd.org Subject: Re: ng_dummy(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: Fri, 10 Jun 2005 18:56:59 -0000 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2005 at 11:18:25AM -0700, Julian Elischer wrote: > you can remove the whistle copyright line.. >=20 > this is unrecognisable from whatever he started with :-) >=20 OK. --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --FN+gV9K+162wdwwF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqeKJqRfpzJluFF4RAhC3AJ90F0taekLSsoG+3b+r2fQQtKdkdACgla1b NFB8xz76I8eTBv8Bxz02VOI= =A3br -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 22:01:36 2005 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 4408516A41C; Fri, 10 Jun 2005 22:01:36 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D29543D4C; Fri, 10 Jun 2005 22:01:35 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from thompsa by heff.fud.org.nz with local (Exim 4.50 (FreeBSD)) id 1DgrZF-000IIB-Nh; Sat, 11 Jun 2005 10:01:33 +1200 Date: Sat, 11 Jun 2005 10:01:33 +1200 From: Andrew Thompson To: Brooks Davis Message-ID: <20050610220133.GA69748@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Brooks Davis , current@freebsd.org, net@freebsd.org References: <20050609064452.GC1595@odin.ac.hmc.edu> <20050610162600.GA12928@odin.ac.hmc.edu> <20050610165724.GA17120@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050610165724.GA17120@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Sender: Andrew Thompson Cc: current@freebsd.org, net@freebsd.org Subject: Re: HEADSUP: internal network interface changes 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, 10 Jun 2005 22:01:36 -0000 On Fri, Jun 10, 2005 at 09:57:24AM -0700, Brooks Davis wrote: > On Fri, Jun 10, 2005 at 09:26:00AM -0700, Brooks Davis wrote: > > Look out! :-) > > > > This change is incoming sortly (pending final cvs updates). > > I've committed the change bumping __FreeBSD_version. Hopefully the > ride won't be too bumpy. If you have any problems, please report them > on -current as well as to me directly. Most problems should be fairly > simple to fix. I will be checking my e-mail regularly for at least the > next 14 hours. > Im getting a panic with if_bridge, it seems to have been missed from the if_alloc() changes. cheers, Andrew Index: sys/net/if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.6 diff -u -r1.6 if_bridge.c --- sys/net/if_bridge.c 10 Jun 2005 16:49:18 -0000 1.6 +++ sys/net/if_bridge.c 10 Jun 2005 21:55:30 -0000 @@ -422,7 +422,11 @@ sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); BRIDGE_LOCK_INIT(sc); - ifp = sc->sc_ifp; + ifp = sc->sc_ifp = if_alloc(IFT_BRIDGE); + if (ifp == NULL) { + free(sc, M_DEVBUF); + return (ENOSPC); + } sc->sc_brtmax = BRIDGE_RTABLE_MAX; sc->sc_brttimeout = BRIDGE_RTABLE_TIMEOUT; @@ -447,7 +451,6 @@ ifp->if_output = bridge_output; ifp->if_start = bridge_start; ifp->if_init = bridge_init; - ifp->if_type = IFT_BRIDGE; IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; IFQ_SET_READY(&ifp->if_snd); @@ -499,6 +502,7 @@ mtx_unlock(&bridge_list_mtx); ether_ifdetach(ifp); + if_free(ifp); /* Tear down the routing table. */ bridge_rtable_fini(sc); From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 22:08:16 2005 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 044F916A41F; Fri, 10 Jun 2005 22:08:16 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F2FD43D53; Fri, 10 Jun 2005 22:08:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5AM8FEw020630; Fri, 10 Jun 2005 15:08:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5AM8FBa020629; Fri, 10 Jun 2005 15:08:15 -0700 Date: Fri, 10 Jun 2005 15:08:15 -0700 From: Brooks Davis To: Andrew Thompson , Brooks Davis , current@freebsd.org, net@freebsd.org Message-ID: <20050610220815.GA17775@odin.ac.hmc.edu> References: <20050609064452.GC1595@odin.ac.hmc.edu> <20050610162600.GA12928@odin.ac.hmc.edu> <20050610165724.GA17120@odin.ac.hmc.edu> <20050610220133.GA69748@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20050610220133.GA69748@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: HEADSUP: internal network interface changes 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, 10 Jun 2005 22:08:16 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 11, 2005 at 10:01:33AM +1200, Andrew Thompson wrote: > On Fri, Jun 10, 2005 at 09:57:24AM -0700, Brooks Davis wrote: > > On Fri, Jun 10, 2005 at 09:26:00AM -0700, Brooks Davis wrote: > > > Look out! :-) > > >=20 > > > This change is incoming sortly (pending final cvs updates). > >=20 > > I've committed the change bumping __FreeBSD_version. Hopefully the > > ride won't be too bumpy. If you have any problems, please report them > > on -current as well as to me directly. Most problems should be fairly > > simple to fix. I will be checking my e-mail regularly for at least the > > next 14 hours. > >=20 >=20 > Im getting a panic with if_bridge, it seems to have been missed from the > if_alloc() changes. Sorry about that, I remember converting if_bridge, but looking at it, I clearly did not. The patch isn't quite right. You will have to keep the setting of if_type and call if_alloc(IFT_ETHER) and then use a matching if_free_type(ifp, IFT_ETHER). Alternativly, you could register functions to allocate the arpcom for IFT_BRIDGE as at the bottom of if_ethersubr.c. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCqg9OXY6L6fI4GtQRAnxVAKCuQg/WoQtLfaIZUDddtMnrUVXrYACfSeW6 ZYBOTLA1rRhu/oIEryOyC+4= =3ChO -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 10 22:12:20 2005 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 8161316A41C; Fri, 10 Jun 2005 22:12:20 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCF243D1F; Fri, 10 Jun 2005 22:12:18 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.3/8.13.3) with ESMTP id j5AMCG0S013844; Sat, 11 Jun 2005 02:12:16 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sat, 11 Jun 2005 02:12:16 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: freebsd-net@freebsd.org Message-ID: <20050611020140.R27835@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alfred Perlstein Subject: setsockopt() can not remove the accept filter 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, 10 Jun 2005 22:12:20 -0000 Hi, man setsockopt(2) states that "passing in an optval of NULL will remove the filter", however, setsockopt() always return EINVAL in this case, because do_setopt_accept_filter() removes the filter if sopt == NULL, but not if sopt->val == NULL. The fix is easy: - if (sopt == NULL) { + if (sopt == NULL || sopt->val == NULL) { By the way, is it easy to add timeout for dataready and httpready filters ? Now the stale connections may live for long time. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 02:07:09 2005 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 54DD716A41C; Sat, 11 Jun 2005 02:07:09 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A17E43D4C; Sat, 11 Jun 2005 02:07:09 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5B278GI010758; Fri, 10 Jun 2005 19:07:08 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5B278Uk010757; Fri, 10 Jun 2005 19:07:08 -0700 Date: Fri, 10 Jun 2005 19:07:08 -0700 From: Brooks Davis To: net@freebsd.org Message-ID: <20050611020708.GA10602@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: scottl@freebsd.org, imp@freebsd.org Subject: RFC: mii_phy_probe API change 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, 11 Jun 2005 02:07:09 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to change mii_phy_probe to take an additional argument, a pointer to the parent's struct ifnet. This would allow use to remove the disgusting cast from the first bit of the softc to an ifnet. The following totally untested diff is what I'm thinking about. Is there anything wrong with the idea? -- Brooks Index: miivar.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/mii/miivar.h,v retrieving revision 1.15 diff -u -r1.15 miivar.h --- miivar.h 4 May 2002 11:00:30 -0000 1.15 +++ miivar.h 11 Jun 2005 02:00:44 -0000 @@ -203,7 +203,7 @@ int mii_mediachg(struct mii_data *); void mii_tick(struct mii_data *); void mii_pollstat(struct mii_data *); -int mii_phy_probe(device_t, device_t *, ifm_change_cb_t, ifm_stat_cb_t); +int mii_phy_probe(device_t, struct ifnet, device_t *, ifm_change_cb_t, ifm= _stat_cb_t); void mii_add_media(struct mii_softc *); void mii_phy_add_media(struct mii_softc *); =20 Index: mii.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.26 diff -u -r1.26 mii.c --- mii.c 11 Jun 2005 00:20:38 -0000 1.26 +++ mii.c 11 Jun 2005 02:00:44 -0000 @@ -171,14 +171,10 @@ struct mii_data *mii; =20 mii =3D device_get_softc(dev); - /* - * Note that each NIC's softc must start with an ifnet pointer. - * XXX: EVIL HACK! - */ - mii->mii_ifp =3D *(struct ifnet**)device_get_softc(device_get_parent(dev)= ); v =3D device_get_ivars(dev); ifmedia_upd =3D v[0]; ifmedia_sts =3D v[1]; + mii->mii_ifp =3D v[2]; ifmedia_init(&mii->mii_media, IFM_IMASK, ifmedia_upd, ifmedia_sts); bus_generic_attach(dev); =20 @@ -265,11 +261,7 @@ link_state =3D LINK_STATE_DOWN; } else link_state =3D LINK_STATE_UNKNOWN; - /* - * Note that each NIC's softc must start with an ifnet pointer. - * XXX: EVIL HACK! - */ - if_link_state_change(*(struct ifnet**)device_get_softc(parent), link_stat= e); + if_link_state_change(mii->mii_ifp, link_state); } =20 static void @@ -295,18 +287,19 @@ } =20 int -mii_phy_probe(device_t dev, device_t *child, ifm_change_cb_t ifmedia_upd, - ifm_stat_cb_t ifmedia_sts) +mii_phy_probe(device_t dev, struct ifnet *ifp, device_t *child, + ifm_change_cb_t ifmedia_upd, ifm_stat_cb_t ifmedia_sts) { void **v; int bmsr, i; =20 - v =3D malloc(sizeof(vm_offset_t) * 2, M_DEVBUF, M_NOWAIT); + v =3D malloc(sizeof(vm_offset_t) * 3, M_DEVBUF, M_NOWAIT); if (v =3D=3D 0) { return (ENOMEM); } v[0] =3D ifmedia_upd; v[1] =3D ifmedia_sts; + v[2] =3D ifp; *child =3D device_add_child(dev, "miibus", -1); device_set_ivars(*child, v); =20 --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCqkdLXY6L6fI4GtQRAgmEAKCE08lXaZJxBvpX/a5WCiF1FlyfewCgvKD2 Q4dreIia4W1IHAJeaTjbkWI= =dTLZ -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 05:26:04 2005 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 8521F16A41C; Sat, 11 Jun 2005 05:26:04 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163B643D48; Sat, 11 Jun 2005 05:26:04 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: by dino.dnsalias.com (Postfix, from userid 1000) id 93C0611F74B; Fri, 10 Jun 2005 22:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.30185.318421.273508@localhost.localdomain> Date: Fri, 10 Jun 2005 22:26:01 -0700 To: Jeremie Le Hen In-Reply-To: <20050609074439.GT41050@obiwan.tataz.chchile.org> References: <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> <20050609074439.GT41050@obiwan.tataz.chchile.org> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) Cc: Greg 'groggy' Lehey , FreeBSD-net@freebsd.org, Gianmarco Giovannelli Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 05:26:04 -0000 Jeremie Le Hen writes: > Given the simplicity of gif(4) IP-encapsulated packets, I wonder > how Linux guys could have implemented something else in their IPIP > module :-). They didn't, Linux IPIP exactly what it sounds like it does: IP in IP encapsulation. The confusion seems to be on the part of FreeBSD guys who can't tell their gre(4) from their gif(4) :-) From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 05:28:04 2005 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 6B75B16A41F for ; Sat, 11 Jun 2005 05:28:04 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6549343D49 for ; Sat, 11 Jun 2005 05:28:02 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 44DBA85675; Sat, 11 Jun 2005 14:58:01 +0930 (CST) Date: Sat, 11 Jun 2005 14:58:01 +0930 From: Greg 'groggy' Lehey To: "Stephen J. Bevan" Message-ID: <20050611052801.GQ87456@wantadilla.lemis.com> References: <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> <20050609074439.GT41050@obiwan.tataz.chchile.org> <17066.30185.318421.273508@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zywvytGCXzdVpkje" Content-Disposition: inline In-Reply-To: <17066.30185.318421.273508@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD-net@freebsd.org, Jeremie Le Hen , Gianmarco Giovannelli Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 05:28:04 -0000 --zywvytGCXzdVpkje Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 10 June 2005 at 22:26:01 -0700, Stephen J. Bevan wrote: > Jeremie Le Hen writes: >> Given the simplicity of gif(4) IP-encapsulated packets, I wonder >> how Linux guys could have implemented something else in their IPIP >> module :-). > > They didn't, Linux IPIP exactly what it sounds like it does: IP in IP > encapsulation. The confusion seems to be on the part of FreeBSD guys > who can't tell their gre(4) from their gif(4) :-) Certainly that confusion exists. But it doesn't seem to be the problem here: the original poster (Gianmarco?) stated that he had tried to set up a tunnel with gif(4), which would mean an IP-IP tunnel. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --zywvytGCXzdVpkje Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCqnZhIubykFB6QiMRAtg5AJ9g3+XRlZK4Z1EvITObJdBiJppa+ACfd4Zb W82X5P75sz+vb56PRKmwavM= =Nvk5 -----END PGP SIGNATURE----- --zywvytGCXzdVpkje-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 05:39:51 2005 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 E5C8B16A41C; Sat, 11 Jun 2005 05:39:51 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C9C43D1F; Sat, 11 Jun 2005 05:39:51 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: by dino.dnsalias.com (Postfix, from userid 1000) id 1C10F11F74B; Fri, 10 Jun 2005 22:39:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.31012.973142.395772@localhost.localdomain> Date: Fri, 10 Jun 2005 22:39:48 -0700 To: Greg 'groggy' Lehey In-Reply-To: <20050608095703.GM64194@wantadilla.lemis.com> References: <20050607093717.GA76296@wantadilla.lemis.com> <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) Cc: Marc Olzheim , FreeBSD-net@FreeBSD.org, Jeremie Le Hen Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 05:39:52 -0000 Greg 'groggy' Lehey writes: > It's currently pushing 7:30 pm, and I was going to send out a reply > tomorrow. But indeed, it seems that Linux people prefer GRE tunnels, > we prefer (with good reason) IP tunnels, ... Like FreeBSD, Linux supports both GRE and IPIP. It is not a Linux thing to use on over the other, rather GRE is/was much more common for creating tunnels because a) it is multiprotocol and so can easily carry Appletalk or IPX as well as IP and b) because of a) Cisco docs are full of example of how to setup GRE tunnels which means almost any network sysadmin is familar with using them and so often defaults to using them. Now that Appletalk and IPX are (almost) a distant memory and Cisco hegemony is not quite so strong then IPIP are becoming more common. From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 05:56:09 2005 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 C25BF16A41C; Sat, 11 Jun 2005 05:56:09 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1953443D48; Sat, 11 Jun 2005 05:56:08 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: by dino.dnsalias.com (Postfix, from userid 1000) id DDA9D11F74B; Fri, 10 Jun 2005 22:56:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.31990.772727.369096@localhost.localdomain> Date: Fri, 10 Jun 2005 22:56:06 -0700 To: Gianmarco Giovannelli In-Reply-To: <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> References: <20050607100958.GU41050@obiwan.tataz.chchile.org> <20050607093717.GA76296@wantadilla.lemis.com> <20050607094848.GB16223@stack.nl> <20050607231218.GD64194@wantadilla.lemis.com> <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) Cc: Greg 'groggy' Lehey , FreeBSD-net@freebsd.org Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 05:56:09 -0000 Gianmarco Giovannelli writes: > Hi Greg, I have follow with interest this thread because I had a similar > problem sometimes ago and we din't succeded in resolve it as I like ... > > I had to connect a couple of a nets with a freebsd box and a linux box > (not managed by me). They insist to use the ipip tunnel (p:4) and I think I > should use the nos-tun interface ... If Linux is using ipip then to connect to it from *BSD you should use gif(4). > Now I see I could simply use the gif interface (which I wrongly suppose did > only GRE tunnel :-) to connect to an ipip linux tunnel. Is this right ? Yes. From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 06:00:03 2005 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 057E316A41C; Sat, 11 Jun 2005 06:00:03 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A69143D1F; Sat, 11 Jun 2005 06:00:02 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: by dino.dnsalias.com (Postfix, from userid 1000) id C1C0D11F74B; Fri, 10 Jun 2005 22:59:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.32221.665435.20574@localhost.localdomain> Date: Fri, 10 Jun 2005 22:59:57 -0700 To: Greg 'groggy' Lehey In-Reply-To: <20050611052801.GQ87456@wantadilla.lemis.com> References: <20050608084946.GI41050@obiwan.tataz.chchile.org> <20050608095703.GM64194@wantadilla.lemis.com> <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> <20050609074439.GT41050@obiwan.tataz.chchile.org> <17066.30185.318421.273508@localhost.localdomain> <20050611052801.GQ87456@wantadilla.lemis.com> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) Cc: FreeBSD-net@freebsd.org, Jeremie Le Hen , Gianmarco Giovannelli Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 06:00:03 -0000 Greg 'groggy' Lehey writes: > Certainly that confusion exists. But it doesn't seem to be the > problem here: the original poster (Gianmarco?) stated that he had > tried to set up a tunnel with gif(4), which would mean an IP-IP > tunnel. If you were referring to Gianmarco then as the following exerpts from his message show, he initially used nos-tun(4) rather than gif(4) because he thought gif(4) did GRE ... > They insist to use the ipip tunnel (p:4) and I think I should use > the nos-tun interface ... ... > Now I see I could simply use the gif interface (which I wrongly > suppose did only GRE tunnel :-) to connect to an ipip linux > tunnel. ... From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 06:48:03 2005 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 DA19816A41C for ; Sat, 11 Jun 2005 06:48:03 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E7143D1D for ; Sat, 11 Jun 2005 06:48:02 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id D585985672; Sat, 11 Jun 2005 16:18:00 +0930 (CST) Date: Sat, 11 Jun 2005 16:18:00 +0930 From: Greg 'groggy' Lehey To: "Stephen J. Bevan" Message-ID: <20050611064800.GR87456@wantadilla.lemis.com> References: <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> <20050609074439.GT41050@obiwan.tataz.chchile.org> <17066.30185.318421.273508@localhost.localdomain> <20050611052801.GQ87456@wantadilla.lemis.com> <17066.32221.665435.20574@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sf3MmCJcUNNLokcm" Content-Disposition: inline In-Reply-To: <17066.32221.665435.20574@localhost.localdomain> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: FreeBSD-net@freebsd.org, Jeremie Le Hen , Gianmarco Giovannelli Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 06:48:04 -0000 --Sf3MmCJcUNNLokcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 10 June 2005 at 22:59:57 -0700, Stephen J. Bevan wrote: > Greg 'groggy' Lehey writes: >> Certainly that confusion exists. But it doesn't seem to be the >> problem here: the original poster (Gianmarco?) stated that he had >> tried to set up a tunnel with gif(4), which would mean an IP-IP >> tunnel. > > If you were referring to Gianmarco then as the following exerpts from > his message show, he initially used nos-tun(4) rather than gif(4) > because he thought gif(4) did GRE ... Ah, my bad. But nos-tun also does IP-IP, so he was using the correct tool. So that doesn't seem to be the problem here. Greg -- The virus contained in this message was not detected. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --Sf3MmCJcUNNLokcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCqokgIubykFB6QiMRAt8eAJ9mhov9cc6JKCcMYzpfKKHnnOd98ACfVJaP QIqXmZdISnEj8uH4kJTyAQk= =vAYr -----END PGP SIGNATURE----- --Sf3MmCJcUNNLokcm-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 07:14:03 2005 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 849AC16A41C; Sat, 11 Jun 2005 07:14:03 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: from dino.dnsalias.com (S010600e02994cd40.vc.shawcable.net [24.80.250.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 106E843D48; Sat, 11 Jun 2005 07:14:03 +0000 (GMT) (envelope-from stephen@dino.dnsalias.com) Received: by dino.dnsalias.com (Postfix, from userid 1000) id 0ABD411F765; Sat, 11 Jun 2005 00:14:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17066.36664.822624.172889@localhost.localdomain> Date: Sat, 11 Jun 2005 00:14:00 -0700 To: Greg 'groggy' Lehey In-Reply-To: <20050611064800.GR87456@wantadilla.lemis.com> References: <20050608195837.Q65103@Neo-Vortex.net> <20050608104053.GK41050@obiwan.tataz.chchile.org> <20050608233136.GX64194@wantadilla.lemis.com> <20050608234559.GS41050@obiwan.tataz.chchile.org> <20050609001004.GB64194@wantadilla.lemis.com> <6.2.1.2.2.20050609080446.05c897d0@83.149.160.120> <20050609074439.GT41050@obiwan.tataz.chchile.org> <17066.30185.318421.273508@localhost.localdomain> <20050611052801.GQ87456@wantadilla.lemis.com> <17066.32221.665435.20574@localhost.localdomain> <20050611064800.GR87456@wantadilla.lemis.com> X-Mailer: VM 7.07 under Emacs 21.3.1 From: stephen@dino.dnsalias.com (Stephen J. Bevan) Cc: FreeBSD-net@freebsd.org, Jeremie Le Hen , Gianmarco Giovannelli Subject: Re: Problems with gif tunnels 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, 11 Jun 2005 07:14:03 -0000 Greg 'groggy' Lehey writes: > Ah, my bad. But nos-tun also does IP-IP, so he was using the correct > tool. So that doesn't seem to be the problem here. By default non-tun uses protocol 94 which is not compatible with gif(4) and Linux IPIP, both of which protocol 4. There is an option (-p) to tell nos-tun to use protocol 4 but either Gianmarco didn't use it or there was some other kind of problem. From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 07:25:03 2005 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 5AF2916A41C; Sat, 11 Jun 2005 07:25:03 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A6E43D4C; Sat, 11 Jun 2005 07:25:02 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j5B7P0iH005539; Sat, 11 Jun 2005 11:25:00 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sat, 11 Jun 2005 11:25:00 +0400 (MSD) From: Maxim Konovalov To: Igor Sysoev In-Reply-To: <20050611020140.R27835@is.park.rambler.ru> Message-ID: <20050611111530.I5448@mp2.macomnet.net> References: <20050611020140.R27835@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Alfred Perlstein , rwatson@freebsd.org Subject: Re: setsockopt() can not remove the accept filter 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, 11 Jun 2005 07:25:03 -0000 [ CC'ed rwatson ] On Sat, 11 Jun 2005, 02:12+0400, Igor Sysoev wrote: > Hi, > > man setsockopt(2) states that "passing in an optval of NULL will remove > the filter", however, setsockopt() always return EINVAL in this case, > because do_setopt_accept_filter() removes the filter if sopt == NULL, but > not if sopt->val == NULL. The fix is easy: > > - if (sopt == NULL) { > + if (sopt == NULL || sopt->val == NULL) { Yep, your observation is correct. The second (mis)feature: getsockopt(SO_ACCEPTFILTER) always returns success on listen socket even we didn't install accept filter on the socket. I extended the regression test for accept filter for these bugs. That makes the name of the test misleading though because now it tests detach case as well. Index: sys/kern/uipc_accf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_accf.c,v retrieving revision 1.18 diff -u -p -r1.18 uipc_accf.c --- sys/kern/uipc_accf.c 12 Mar 2005 12:57:17 -0000 1.18 +++ sys/kern/uipc_accf.c 11 Jun 2005 06:53:47 -0000 @@ -176,8 +176,10 @@ do_getopt_accept_filter(struct socket *s error = EINVAL; goto out; } - if ((so->so_options & SO_ACCEPTFILTER) == 0) + if ((so->so_options & SO_ACCEPTFILTER) == 0) { + error = EINVAL; goto out; + } strcpy(afap->af_name, so->so_accf->so_accept_filter->accf_name); if (so->so_accf->so_accept_filter_str != NULL) strcpy(afap->af_arg, so->so_accf->so_accept_filter_str); @@ -200,7 +202,7 @@ do_setopt_accept_filter(struct socket *s /* * Handle the simple delete case first. */ - if (sopt == NULL) { + if (sopt == NULL || sopt->sopt_val == NULL) { SOCK_LOCK(so); if ((so->so_options & SO_ACCEPTCONN) == 0) { SOCK_UNLOCK(so); Index: tools/regression/sockets/accf_data_attach/accf_data_attach.c =================================================================== RCS file: /home/ncvs/src/tools/regression/sockets/accf_data_attach/accf_data_attach.c,v retrieving revision 1.3 diff -u -p -r1.3 accf_data_attach.c --- tools/regression/sockets/accf_data_attach/accf_data_attach.c 11 Nov 2004 19:47:53 -0000 1.3 +++ tools/regression/sockets/accf_data_attach/accf_data_attach.c 11 Jun 2005 07:06:41 -0000 @@ -54,6 +54,8 @@ * state. * - That once an accept filter is attached, we can query to make sure it is * attached. + * - That once an accept filter is attached, we can remove it and query to + * make sure it is removed. */ int main(int argc, char *argv[]) @@ -145,38 +147,72 @@ main(int argc, char *argv[]) printf("ok 7 - listen\n"); /* - * Step 7: After listen(). This call to setsockopt() should succeed. + * Step 7: Getsockopt() after listen(). Should fail with EINVAL, + * since we have not installed accept filter yep. + */ + len = sizeof(afa); + ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); + if (ret == 0) + errx(-1, "not ok 8 - getsockopt() after listen() but before " + "setsockopt() succeeded"); + if (errno != EINVAL) + errx(-1, "not ok 8 - getsockopt() after listen() but before " + "setsockopt() failed with %d (%s)", errno, strerror(errno)); + printf("ok 8 - getsockopt\n"); + + /* + * Step 8: After listen(). This call to setsockopt() should succeed. */ bzero(&afa, sizeof(afa)); strcpy(afa.af_name, ACCF_NAME); ret = setsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa)); if (ret != 0) - errx(-1, "not ok 8 - setsockopt() after listen() failed with %d " + errx(-1, "not ok 9 - setsockopt() after listen() failed with %d " "(%s)", errno, strerror(errno)); if (len != sizeof(afa)) - errx(-1, "not ok 8 - setsockopt() after listen() returned wrong " + errx(-1, "not ok 9 - setsockopt() after listen() returned wrong " "size (%d vs expected %d)", len, sizeof(afa)); - printf("ok 8 - setsockopt\n"); + printf("ok 9 - setsockopt\n"); /* - * Step 8: After setsockopt(). Should succeed and identify + * Step 9: After setsockopt(). Should succeed and identify * ACCF_NAME. */ bzero(&afa, sizeof(afa)); len = sizeof(afa); ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); if (ret != 0) - errx(-1, "not ok 9 - getsockopt() after listen() setsockopt() " + errx(-1, "not ok 10 - getsockopt() after listen() setsockopt() " "failed with %d (%s)", errno, strerror(errno)); if (len != sizeof(afa)) - errx(-1, "not ok 9 - getsockopt() after setsockopet() after " + errx(-1, "not ok 10 - getsockopt() after setsockopet() after " "listen() returned wrong size (got %d expected %d)", len, sizeof(afa)); if (strcmp(afa.af_name, ACCF_NAME) != 0) - errx(-1, "not ok 9 - getsockopt() after setsockopt() after " + errx(-1, "not ok 10 - getsockopt() after setsockopt() after " "listen() mismatch (got %s expected %s)", afa.af_name, ACCF_NAME); - printf("ok 9 - getsockopt\n"); + printf("ok 10 - getsockopt\n"); + + /* + * Step 10: Remove accept filter. After removing the accept filter + * getsockopt() should fail with EINVAL. + */ + ret = setsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, NULL, 0); + if (ret != 0) + errx(-1, "not ok 11 - setsockopt() after listen() " + "failed with %d (%s)", errno, strerror(errno)); + bzero(&afa, sizeof(afa)); + len = sizeof(afa); + ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); + if (ret == 0) + errx(-1, "not ok 11 - getsockopt() after removing " + "the accept filter returns valid accept filter %s", + afa.af_name); + if (errno != EINVAL) + errx(-1, "not ok 11 - getsockopt() after removing the accept" + "filter failed with %d (%s)", errno, strerror(errno)); + printf("ok 11 - setsockopt\n"); close(lso); return (0); %%% -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 09:28:08 2005 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 0420A16A41F for ; Sat, 11 Jun 2005 09:28:08 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F2B643D4C for ; Sat, 11 Jun 2005 09:28:07 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so568344nzp for ; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ob5jeVavrwnpLKmiW0zugJaINgYVBV/zHwKTtEN4v9OdIzwUw4stKnotxHej6fw0gc83Xlw1mWh1lzTNF5XznCbaDizpBdFQS9LPQ/2AlFa3UBe46GeXF0NSImlFKyH6yNQF+hR0/7jAij7nbl4t1/9+x531Mqk6+2bfzbe3qPI= Received: by 10.36.106.20 with SMTP id e20mr1703304nzc; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Sat, 11 Jun 2005 02:28:06 -0700 (PDT) Message-ID: <79722fad0506110228538ee434@mail.gmail.com> Date: Sat, 11 Jun 2005 12:28:06 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad050609151068c71c91@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> <79722fad050609151068c71c91@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 09:28:08 -0000 On 6/10/05, Vlad GALU wrote: > On 6/10/05, Vlad GALU wrote: > > As you may all know, the packet classifier in ALTQ is very > > slow on large numbers of classes, because it stores them linearly, in > > an array. I rewrote the way classes are stored, replacing the array > > with a hash table. I tested [1] on a system with about 8000 classes > > and noticed a remarkable performance difference (the system went from > > almost unusable to nice & smooth). It breaks the ABI by adding an > > extra TAILQ_ENTRY member to the HFSC class structure, though. >=20 > And also replaces the class array in struct hfsc_if with the hash table= . Bummer. Increasing the number of classes led to locking the machine up. Something slipped my eye: the filters are also linearly searched for. I'll try to do something about them as well and come back with something. >=20 > > If anyone reviews and tests it, I would be grateful. > > > > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff > > > > P.S. please keep in mind that I'm not exactly a black belt in kernel > > programming, so glitches might exist. I would be most happy to hear > > some suggestions. > > > > -- > > If it's there, and you can see it, it's real. > > If it's not there, and you can see it, it's virtual. > > If it's there, and you can't see it, it's transparent. > > If it's not there, and you can't see it, you erased it. > > >=20 >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 09:36:41 2005 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 66C2116A41C; Sat, 11 Jun 2005 09:36:41 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E2543D1D; Sat, 11 Jun 2005 09:36:41 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 259FA5CA6C; Sat, 11 Jun 2005 02:36:41 -0700 (PDT) Date: Sat, 11 Jun 2005 02:36:41 -0700 From: Alfred Perlstein To: Maxim Konovalov Message-ID: <20050611093640.GB17867@elvis.mu.org> References: <20050611020140.R27835@is.park.rambler.ru> <20050611111530.I5448@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050611111530.I5448@mp2.macomnet.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Igor Sysoev , rwatson@freebsd.org Subject: Re: setsockopt() can not remove the accept filter 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, 11 Jun 2005 09:36:41 -0000 Looks cool. Can you commit it? Or should I? * Maxim Konovalov [050611 00:25] wrote: > [ CC'ed rwatson ] > > On Sat, 11 Jun 2005, 02:12+0400, Igor Sysoev wrote: > > > Hi, > > > > man setsockopt(2) states that "passing in an optval of NULL will remove > > the filter", however, setsockopt() always return EINVAL in this case, > > because do_setopt_accept_filter() removes the filter if sopt == NULL, but > > not if sopt->val == NULL. The fix is easy: > > > > - if (sopt == NULL) { > > + if (sopt == NULL || sopt->val == NULL) { > > Yep, your observation is correct. The second (mis)feature: > getsockopt(SO_ACCEPTFILTER) always returns success on listen socket > even we didn't install accept filter on the socket. > > I extended the regression test for accept filter for these bugs. > That makes the name of the test misleading though because now it tests > detach case as well. > > Index: sys/kern/uipc_accf.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_accf.c,v > retrieving revision 1.18 > diff -u -p -r1.18 uipc_accf.c > --- sys/kern/uipc_accf.c 12 Mar 2005 12:57:17 -0000 1.18 > +++ sys/kern/uipc_accf.c 11 Jun 2005 06:53:47 -0000 > @@ -176,8 +176,10 @@ do_getopt_accept_filter(struct socket *s > error = EINVAL; > goto out; > } > - if ((so->so_options & SO_ACCEPTFILTER) == 0) > + if ((so->so_options & SO_ACCEPTFILTER) == 0) { > + error = EINVAL; > goto out; > + } > strcpy(afap->af_name, so->so_accf->so_accept_filter->accf_name); > if (so->so_accf->so_accept_filter_str != NULL) > strcpy(afap->af_arg, so->so_accf->so_accept_filter_str); > @@ -200,7 +202,7 @@ do_setopt_accept_filter(struct socket *s > /* > * Handle the simple delete case first. > */ > - if (sopt == NULL) { > + if (sopt == NULL || sopt->sopt_val == NULL) { > SOCK_LOCK(so); > if ((so->so_options & SO_ACCEPTCONN) == 0) { > SOCK_UNLOCK(so); > Index: tools/regression/sockets/accf_data_attach/accf_data_attach.c > =================================================================== > RCS file: /home/ncvs/src/tools/regression/sockets/accf_data_attach/accf_data_attach.c,v > retrieving revision 1.3 > diff -u -p -r1.3 accf_data_attach.c > --- tools/regression/sockets/accf_data_attach/accf_data_attach.c 11 Nov 2004 19:47:53 -0000 1.3 > +++ tools/regression/sockets/accf_data_attach/accf_data_attach.c 11 Jun 2005 07:06:41 -0000 > @@ -54,6 +54,8 @@ > * state. > * - That once an accept filter is attached, we can query to make sure it is > * attached. > + * - That once an accept filter is attached, we can remove it and query to > + * make sure it is removed. > */ > int > main(int argc, char *argv[]) > @@ -145,38 +147,72 @@ main(int argc, char *argv[]) > printf("ok 7 - listen\n"); > > /* > - * Step 7: After listen(). This call to setsockopt() should succeed. > + * Step 7: Getsockopt() after listen(). Should fail with EINVAL, > + * since we have not installed accept filter yep. > + */ > + len = sizeof(afa); > + ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); > + if (ret == 0) > + errx(-1, "not ok 8 - getsockopt() after listen() but before " > + "setsockopt() succeeded"); > + if (errno != EINVAL) > + errx(-1, "not ok 8 - getsockopt() after listen() but before " > + "setsockopt() failed with %d (%s)", errno, strerror(errno)); > + printf("ok 8 - getsockopt\n"); > + > + /* > + * Step 8: After listen(). This call to setsockopt() should succeed. > */ > bzero(&afa, sizeof(afa)); > strcpy(afa.af_name, ACCF_NAME); > ret = setsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, sizeof(afa)); > if (ret != 0) > - errx(-1, "not ok 8 - setsockopt() after listen() failed with %d " > + errx(-1, "not ok 9 - setsockopt() after listen() failed with %d " > "(%s)", errno, strerror(errno)); > if (len != sizeof(afa)) > - errx(-1, "not ok 8 - setsockopt() after listen() returned wrong " > + errx(-1, "not ok 9 - setsockopt() after listen() returned wrong " > "size (%d vs expected %d)", len, sizeof(afa)); > - printf("ok 8 - setsockopt\n"); > + printf("ok 9 - setsockopt\n"); > > /* > - * Step 8: After setsockopt(). Should succeed and identify > + * Step 9: After setsockopt(). Should succeed and identify > * ACCF_NAME. > */ > bzero(&afa, sizeof(afa)); > len = sizeof(afa); > ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); > if (ret != 0) > - errx(-1, "not ok 9 - getsockopt() after listen() setsockopt() " > + errx(-1, "not ok 10 - getsockopt() after listen() setsockopt() " > "failed with %d (%s)", errno, strerror(errno)); > if (len != sizeof(afa)) > - errx(-1, "not ok 9 - getsockopt() after setsockopet() after " > + errx(-1, "not ok 10 - getsockopt() after setsockopet() after " > "listen() returned wrong size (got %d expected %d)", len, > sizeof(afa)); > if (strcmp(afa.af_name, ACCF_NAME) != 0) > - errx(-1, "not ok 9 - getsockopt() after setsockopt() after " > + errx(-1, "not ok 10 - getsockopt() after setsockopt() after " > "listen() mismatch (got %s expected %s)", afa.af_name, > ACCF_NAME); > - printf("ok 9 - getsockopt\n"); > + printf("ok 10 - getsockopt\n"); > + > + /* > + * Step 10: Remove accept filter. After removing the accept filter > + * getsockopt() should fail with EINVAL. > + */ > + ret = setsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, NULL, 0); > + if (ret != 0) > + errx(-1, "not ok 11 - setsockopt() after listen() " > + "failed with %d (%s)", errno, strerror(errno)); > + bzero(&afa, sizeof(afa)); > + len = sizeof(afa); > + ret = getsockopt(lso, SOL_SOCKET, SO_ACCEPTFILTER, &afa, &len); > + if (ret == 0) > + errx(-1, "not ok 11 - getsockopt() after removing " > + "the accept filter returns valid accept filter %s", > + afa.af_name); > + if (errno != EINVAL) > + errx(-1, "not ok 11 - getsockopt() after removing the accept" > + "filter failed with %d (%s)", errno, strerror(errno)); > + printf("ok 11 - setsockopt\n"); > > close(lso); > return (0); > %%% > > -- > Maxim Konovalov -- - Alfred Perlstein - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 09:45:34 2005 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 C296D16A41C; Sat, 11 Jun 2005 09:45:34 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E20B43D48; Sat, 11 Jun 2005 09:45:33 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j5B9jWEx061531; Sat, 11 Jun 2005 13:45:32 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sat, 11 Jun 2005 13:45:32 +0400 (MSD) From: Maxim Konovalov To: Alfred Perlstein In-Reply-To: <20050611093640.GB17867@elvis.mu.org> Message-ID: <20050611134453.I43831@mp2.macomnet.net> References: <20050611020140.R27835@is.park.rambler.ru> <20050611111530.I5448@mp2.macomnet.net> <20050611093640.GB17867@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Igor Sysoev , rwatson@freebsd.org Subject: Re: setsockopt() can not remove the accept filter 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, 11 Jun 2005 09:45:34 -0000 On Sat, 11 Jun 2005, 02:36-0700, Alfred Perlstein wrote: > Looks cool. Can you commit it? Or should I? I'll commit and handle MFC. Thanks for review Alfred. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 12:05:09 2005 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 33BC516A41C; Sat, 11 Jun 2005 12:05:09 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DDC243D1D; Sat, 11 Jun 2005 12:05:08 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received-SPF: pass (mp2.macomnet.net: domain of maxim@FreeBSD.org designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@FreeBSD.org; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j5BC56EM005783; Sat, 11 Jun 2005 16:05:07 +0400 (MSD) (envelope-from maxim@FreeBSD.org) Date: Sat, 11 Jun 2005 16:05:06 +0400 (MSD) From: Maxim Konovalov To: Igor Sysoev In-Reply-To: <20050611020140.R27835@is.park.rambler.ru> Message-ID: <20050611160250.K5756@mp2.macomnet.net> References: <20050611020140.R27835@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@FreeBSD.org, Alfred Perlstein Subject: Re: setsockopt() can not remove the accept filter 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, 11 Jun 2005 12:05:09 -0000 Igor, On Sat, 11 Jun 2005, 02:12+0400, Igor Sysoev wrote: > Hi, > > man setsockopt(2) states that "passing in an optval of NULL will remove > the filter", however, setsockopt() always return EINVAL in this case, > because do_setopt_accept_filter() removes the filter if sopt == NULL, but > not if sopt->val == NULL. The fix is easy: > > - if (sopt == NULL) { > + if (sopt == NULL || sopt->val == NULL) { I committed fixes for this and related bug and will MFC them in two weeks. Thanks! -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 20:07:23 2005 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 DC65116A41C for ; Sat, 11 Jun 2005 20:07:22 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88C4F43D49 for ; Sat, 11 Jun 2005 20:07:22 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1396144nzk for ; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qeT43F/MNyo/BJ1Gwq0EsjxSDOV81CqPF0aElAgOUSrUd6efLXrvtdKtungb3/I0ZT/rd++aKK/KGYZdeLw323Trxs/2mWowA31hBHC8Xx8QRs1RalOZv9d7JWa6FaPtZNLqKOVGSTqNuIiQ0GJiZEPu7YCoFJciGrAJeWUjm1I= Received: by 10.36.115.1 with SMTP id n1mr1934741nzc; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Sat, 11 Jun 2005 13:07:21 -0700 (PDT) Message-ID: <79722fad050611130734c36979@mail.gmail.com> Date: Sat, 11 Jun 2005 23:07:21 +0300 From: Vlad GALU To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <79722fad0506110228538ee434@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <79722fad05060914123edd1004@mail.gmail.com> <79722fad050609151068c71c91@mail.gmail.com> <79722fad0506110228538ee434@mail.gmail.com> Cc: Subject: Re: Please review & test this X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 20:07:23 -0000 On 6/11/05, Vlad GALU wrote: > On 6/10/05, Vlad GALU wrote: > > On 6/10/05, Vlad GALU wrote: > > > As you may all know, the packet classifier in ALTQ is very > > > slow on large numbers of classes, because it stores them linearly, in > > > an array. I rewrote the way classes are stored, replacing the array > > > with a hash table. I tested [1] on a system with about 8000 classes > > > and noticed a remarkable performance difference (the system went from > > > almost unusable to nice & smooth). It breaks the ABI by adding an > > > extra TAILQ_ENTRY member to the HFSC class structure, though. > > > > And also replaces the class array in struct hfsc_if with the hash tab= le. >=20 > Bummer. Increasing the number of classes led to locking the machine > up. Something slipped my eye: the filters are also linearly searched > for. I'll try to do something about them as well and come back with > something. >=20 Duhhh, I need more coffee. I didn't notice the ALTQ3_COMPAT ifdef in the source. Luckily, the patch in my first mail deals with it as well. The classifying is entirely done by pf, so I guess it only depends on how (un)optimized your ruleset is. > > > > > If anyone reviews and tests it, I would be grateful. > > > > > > [1] http://night.rdslink.ro/dudu/altq/altq_hfschash.diff > > > > > > P.S. please keep in mind that I'm not exactly a black belt in kernel > > > programming, so glitches might exist. I would be most happy to hear > > > some suggestions. > > > > > > -- > > > If it's there, and you can see it, it's real. > > > If it's not there, and you can see it, it's virtual. > > > If it's there, and you can't see it, it's transparent. > > > If it's not there, and you can't see it, you erased it. > > > > > > > > > -- > > If it's there, and you can see it, it's real. > > If it's not there, and you can see it, it's virtual. > > If it's there, and you can't see it, it's transparent. > > If it's not there, and you can't see it, you erased it. > > >=20 >=20 > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 23:02:16 2005 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 98C2716A41F for ; Sat, 11 Jun 2005 23:02:16 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 233EA43D53 for ; Sat, 11 Jun 2005 23:02:13 +0000 (GMT) (envelope-from josh.kayse@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so634448wra for ; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AHYOpTqFzDdtVqjmxK8qMcFY6e3W2RxJ98z0tRa6pbxS3WM186lPvxbpYXDmXVZRlxVhAQ1duhILIyfROtqisMakB28G6AmlRcLtfDq5rmO508UUirHe/UrendyLm7HIvLjVk1j7Z6TWYG3nuTNkZhGPjjypb4/YOfLECn8AHSw= Received: by 10.54.116.2 with SMTP id o2mr1682681wrc; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) Received: by 10.54.23.52 with HTTP; Sat, 11 Jun 2005 16:02:13 -0700 (PDT) Message-ID: <7c8f279205061116021f55e8da@mail.gmail.com> Date: Sat, 11 Jun 2005 19:02:13 -0400 From: Josh Kayse To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <7c8f2792050610090049064e11@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7c8f2792050610090049064e11@mail.gmail.com> Cc: Subject: Re: Carp Suppression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gtg062h@mail.gatech.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 23:02:16 -0000 I think I've narrowed it down to the plip interface, but I'm not completely sure. Has anyone gotten carp running over a plip interface? On 6/10/05, Josh Kayse wrote: > I am cross-posting this to -net and -pf because I am not sure where it go= es. >=20 > I am running 2 carp interfaces on a pair of transparent firewalls > running FreeBSD 5.4. >=20 > One of the interfaces is a xl interface and the other is a plip interface= . >=20 > I am having trouble in that the carp interfaces are not failing over > between the 2 machines. >=20 > When I check net.inet.carp.suppress_preempt it returns 1 and I do not > understand why that is. >=20 > Can anyone shed some light on this? >=20 > If you need any more information, just let me know. >=20 > Thanks >=20 > Josh > -- > Joshua Kayse > Computer Engineering >=20 --=20 Joshua Kayse Computer Engineering From owner-freebsd-net@FreeBSD.ORG Sat Jun 11 23:23:06 2005 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 DA5D416A41C; Sat, 11 Jun 2005 23:23:06 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8667B43D1D; Sat, 11 Jun 2005 23:23:06 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j5BNN3Y4013756; Sat, 11 Jun 2005 19:23:03 -0400 (EDT) Received: from volatile.chemikals.org (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.3/8.13.3) with ESMTP id j5BNN1YE027876; Sat, 11 Jun 2005 19:23:02 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost) by volatile.chemikals.org (8.13.3/8.13.3/Submit) with ESMTP id j5BNMxvm027873; Sat, 11 Jun 2005 19:22:59 -0400 (EDT) (envelope-from morganw@chemikals.org) X-Authentication-Warning: volatile.chemikals.org: morganw owned process doing -bs Date: Sat, 11 Jun 2005 19:22:56 -0400 (EDT) From: Wesley Morgan To: usb@freebsd.org, net@freebsd.org Message-ID: <20050611181241.D27697@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: network <-> USB2 blocks process? 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, 11 Jun 2005 23:23:07 -0000 I'm using a cardbus usb2 adapter in my laptop to transfer data to an external drive. It works great transferring local data, and of course the network itself works great... But combining the two isn't working out. Copying from an NFS share to the USB drive results in a non-fatal hang: 4635 morganw 1 -16 0 1416K 764K wdrain 0:01 0.12% cp The final read() from the NFS mount succeeds but the following write() blocks (as indicated by top). Eventually (a LONG eventually) whatever is blocking will correct itself and the transfer proceeds again until whatever is filling up is full again. Anyone have any ideas to what might be going on?