From owner-freebsd-net@FreeBSD.ORG Sun Oct 29 03:45:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EBDB16A54D for ; Sun, 29 Oct 2006 03:45:01 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67ED543D53 for ; Sun, 29 Oct 2006 03:45:00 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so860122nzf for ; Sat, 28 Oct 2006 20:44:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gJvzXWXFOPgRMLIgQjw3KrUAyMl11htlbfHZzKvyptUtw2t4gefrcg/Gp5VeMFUcky56zlGZWjDBBVMJRGlbYkq3ktNWCpq4i14dnprQrEG+CE/33p8bv9Lv/ZyTmvTM+TMOC8aoM+gs6r/SiuNdonBt4212tESPjE1D96pjLLY= Received: by 10.35.72.1 with SMTP id z1mr1635946pyk; Sat, 28 Oct 2006 20:44:59 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Sat, 28 Oct 2006 20:44:59 -0700 (PDT) Message-ID: <2a41acea0610282044k51ac6c1do87675aa03defb000@mail.gmail.com> Date: Sat, 28 Oct 2006 20:44:59 -0700 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: 82542 ID is back X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2006 03:45:01 -0000 Contrary to what I was told there are still users with 82542 hardware. I promised that if anyone spoke up I'd replace it, so its back. So Intel test and validation isnt always right, who knew :) Enjoy, Jack From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 07:44:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21B8616A40F for ; Mon, 30 Oct 2006 07:44:22 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.91.193.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA8643D45 for ; Mon, 30 Oct 2006 07:44:21 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F6912201DE for ; Mon, 30 Oct 2006 13:14:29 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 60F8A220366 for ; Mon, 30 Oct 2006 13:14:29 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:14:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Oct 2006 13:13:12 +0530 Message-ID: <821C7AD2A9F78942B86059792262577315B049@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: TSO patch for current Thread-Index: AcbROYB1Rf1yJ1cwQEG3PZW6avyqWQqvWjIg From: To: X-OriginalArrivalTime: 30 Oct 2006 07:44:18.0911 (UTC) FILETIME=[34DE36F0:01C6FBF7] Cc: freebsd-net@freebsd.org Subject: RE: RFC: TSO patch for current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 07:44:22 -0000 =0D Hi Jack, Do you the patch for 6.0 FreeBSD kernel? If so can you please send it me. I would like to test TSO on my system. Thanks, ~Siva -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel Sent: Wednesday, September 06, 2006 3:53 AM To: Andre Oppermann Cc: freebsd-net; freebsd-current Subject: Re: RFC: TSO patch for current On 9/5/06, Andre Oppermann wrote: > Jack Vogel wrote: > > On 9/5/06, Andre Oppermann wrote: > >> Prafulla Deuskar wrote: > >> > Your patch looks good and is the way to go. > >> > > >> > So after Jack confirms that your patch works with the em driver=0D > >> > would you commit to to -current? > >> > >> Absolutely. :-) > >> > >> > The driver related changes can follow.. > >> > > >> > Later we also need to fix ifconfig so that user can=0D > >> > enable/disable > >> TSO on the interface. > >> > >> I'll do that together with the TSO code. > > > > OK, I've built and done some touch testing of this. I like it, the=0D > > driver has some counters of the number of TSO bursts it does, and I=0D > > think I see more per netperf test with your patch than mine. > > > > Hard to do real performance testing with all that WITNESS stuff in,=0D > > but I will be making a 6.1 version of your patch to test with since=0D > > I have my driver running on that anyway. > > You can disable WITNESS and INVARIANTS pretty easily in -current and=0D > get the full performance with it. Last time I tried that I think the kernel wouldnt build, but that was like 6 months ago, so I just kicked off a build with this stuff off, and we'll see how it looks :) > > If you do the ifconfig changes there will need to be a small amount=0D > > of code added to em_ioctl() but it should be trivial. > > > > You want me to reissue a driver patch with changes for your code? > > Yes, please do so. I've got a dual-em card which I can test with myself. OK, attached new patch, this one even has the ioctl change so when you get the ifconfig change in it will be ready. Cheers, Jack The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 09:34:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C1F716A40F for ; Mon, 30 Oct 2006 09:34:08 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id C835343D53 for ; Mon, 30 Oct 2006 09:34:07 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 10:34:05 +0100 Date: Mon, 30 Oct 2006 10:34:06 +0100 (CET) From: Hartmut Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Thomas In-Reply-To: <45424017.2030905@bsdunix.ch> Message-ID: <20061030102241.V60872@knop-beagle.kn.op.dlr.de> References: <4541AB5C.2060009@bsdunix.ch> <20061027104553.D27619@knop-beagle.kn.op.dlr.de> <454226C7.10505@bsdunix.ch> <20061027173957.S27619@knop-beagle.kn.op.dlr.de> <45424017.2030905@bsdunix.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 30 Oct 2006 09:34:05.0659 (UTC) FILETIME=[8AE032B0:01C6FC06] Cc: freebsd-net@freebsd.org Subject: Re: paket loss on freebsd router if (b)snmpd is running##SPAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 09:34:08 -0000 Hi Thomas, it seems that 5.4 has the old routing table code. This code used a TAILQ to hold all the routes. This turned out to be a problem for large routing tables so I replaced it with a red-black tree. This happened between 6.0 and 6.1 - 6.0 has still the old code, 6.1 the new one. The old code consumes a huge amount of memory (I think around 600 byte per route) and a huge amount of time, because it needs to loop through the ordered tailq for each routing update. It is espacially bad for the initial full read of the routing table and the full read that happens periodically (when you do an SNMP operation on the routing table), because it builds and ordered list from an ordered input set. Because the daemon opens the routing socket to get routing updates, it will do some work even when no SNMP requests come in. I suppose this is what is happening in your case. As a first step I would recommend to update the bsnmp daemon to at least RELENG_6_1. Updating contrib/bsnmp, lib/libbsnmp and usr.sbin/bsnmp and rebuilding/installing first the library and then the daemon should do the trick. 6.1 should also have the 64-bit counters in the interface statistics if I interpret the CVS log correctly. In any case it is still a question why a user space program doing work causes the interfaces to loose packets. I don't know enough about the POLLING stuff though to make a qualified guess. harti On Fri, 27 Oct 2006, Thomas wrote: T>Hello Harti T> T>Harti Brandt schrieb: T>> On Fri, 27 Oct 2006, Thomas wrote: T>> T>> T>Hello Harti T>> T> T>> T>Harti Brandt schrieb: T>> T>> On Fri, 27 Oct 2006, Thomas wrote: T>> T>> T>> T>> T>Hello T>> T>> T> T>> T>> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The T>> T>> T>average traffic is 300mbit/s (em interfaces with polling enabled). It T>> T>> T>works more or less. T>> T>> T> T>> T>> T>Problem: T>> T>> T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the T>> T>> T>router has some significant packet loss. We are talking about 3-15% of T>> T>> T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). T>> T>> T>> T>> Does this happen also if you walk only the interface tables? What size is T>> T>> your routing table? T>> T> T>> T>The routing table has approx. 200k entries. I've to correct my T>> T>statement. I don't walk over the RoutingTable. T>> T>> Oh. That would be a nice test how good the RB-tree implementation of the T>> routing table is :-) T>> T>> T>It's only an interface table walk (IF-MIB). bsnmpd consumes approx. T>> T>6-10% cpu. I already have significant packet loss if bsnmpd is started. T>> T> T>> T>bsnmpd not running: T>> T> T>> T>ping www.switch.ch T>> T> T>> T>--- oreius.switch.ch ping statistics --- T>> T>44 packets transmitted, 44 packets received, 0% packet loss T>> T>round-trip min/avg/max/stddev = 6.825/7.425/8.007/0.252 ms T>> T> T>> T>zero packet loss. T>> T> T>> T> T>> T>netstat -w 1 shows no error. T>> T> T>> T> input (Total) output T>> T> packets errs bytes packets errs bytes colls T>> T> 39877 0 34330807 38614 0 34087518 0 T>> T> 45522 0 38730142 44124 0 38424881 0 T>> T> 44671 0 38783909 43455 0 38604698 0 T>> T> 43140 0 36939542 42059 0 36691583 0 T>> T> 43428 0 36858817 42213 0 36700954 0 T>> T> 43748 0 37994949 42687 0 37780190 0 T>> T> 42698 0 36451927 41409 0 36270936 0 T>> T> 38695 0 32184588 37119 0 31791417 0 T>> T> T>> T> T>> T> T>> T> T>> T>bsnmpd started: T>> T> T>> T>ping www.switch.ch T>> T>--- oreius.switch.ch ping statistics --- T>> T>57 packets transmitted, 53 packets received, 7% packet loss T>> T>round-trip min/avg/max/stddev = 6.715/12.638/95.183/19.041 ms T>> T> T>> T>7% packet loss. T>> T> T>> T> T>> T>netstat shows some errors too. T>> T>netstat -w 1 T>> T> input (Total) output T>> T> packets errs bytes packets errs bytes colls T>> T> 33597 0 27508009 32433 0 27344720 0 T>> T> 38204 0 32117848 36950 0 31852251 0 T>> T> 39171 0 33870984 37999 0 33696346 0 T>> T> 32160 0 26825650 31065 0 26591079 0 T>> T> 26915 726 20902878 25771 0 20791170 0 T>> T> 35167 0 29173014 33945 0 28904867 0 T>> T> 33282 370 27478393 32140 0 27297079 0 T>> T> 29738 0 23859586 28464 0 23524984 0 T>> T> 38456 598 31559055 36881 0 31313396 0 T>> T> 34738 0 28088584 33247 0 27743827 0 T>> T> 38193 648 30854513 36657 0 30556948 0 T>> T> T>> T> T>> T>A snmpwalk makes it a bit worse but not much. I already have packet loss T>> T>if bsnmpd is just started without any walks. T>> T>> You mean, you have loss if it is just ideling around? The only thing T>> bsnmpd does in this situation is polling the interface statistics, which T>> is needed because the kernel has only 32-bit counters. Could you please T>> check what the polling interval is? You find this in the BEGEMOT-MIB2-MIB. T>> Something like T>> T> T>Yes, bsnmpd is just ideling. T> T>> snmpwalk ... begemotMib2 T> T>On this freebsd 5.4 machine I have bsnmpd-1.12: T>share/snmp/mibs/BEGEMOT-MIB.txt T>share/snmp/mibs/BEGEMOT-NTP-MIB.txt T>share/snmp/mibs/BEGEMOT-SNMPD.txt T> T>but no BEGEMOT-MIB2-MIB. T> T> T>snmpwalk -v 2c -m /usr/share/snmp/mibs/BEGEMOT-MIB.txt -c public T>localhost BEGEMOT T>BEGEMOT-MIB::begemot.1.1.1.1.0 = INTEGER: 2048 T>BEGEMOT-MIB::begemot.1.1.1.2.0 = INTEGER: 2048 T>BEGEMOT-MIB::begemot.1.1.1.3.0 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.1.4.0 = IpAddress: 0.0.0.0 T>BEGEMOT-MIB::begemot.1.1.1.5.0 = Gauge32: 3 T>BEGEMOT-MIB::begemot.1.1.2.1.3.192.168.1.10.162 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.2.1.4.192.168.1.10.162 = STRING: "SNTrap" T>BEGEMOT-MIB::begemot.1.1.2.1.5.192.168.1.10.162 = INTEGER: 2 T>BEGEMOT-MIB::begemot.1.1.4.1.3.127.0.0.1.161 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.4.1.3.192.168.1.100.161 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.6.1.2.5.109.105.98.73.73 = STRING: T>"/usr/local/lib/snmp_mibII.so" T>BEGEMOT-MIB::begemot.1.1.6.1.3.5.109.105.98.73.73 = STRING: "This module T>implements the interface and ip groups." T>BEGEMOT-MIB::begemot.1.1.7.1.0 = Counter32: 0 T>BEGEMOT-MIB::begemot.1.1.7.2.0 = Counter32: 0 T>BEGEMOT-MIB::begemot.1.1.7.3.0 = Counter32: 0 T>BEGEMOT-MIB::begemot.1.1.7.4.0 = Counter32: 0 T>BEGEMOT-MIB::begemot.1.1.8.1.0 = INTEGER: 2 T>BEGEMOT-MIB::begemot.1.1.8.2.0 = Gauge32: 0 T>BEGEMOT-MIB::begemot.1.1.8.3.0 = INTEGER: 7 T>BEGEMOT-MIB::begemot.1.1.9.1.2.19.47.118.97.114.47.114.117.110.47.115.110.109.112.100.46.115.111.99.107 T>= INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.9.1.3.19.47.118.97.114.47.114.117.110.47.115.110.109.112.100.46.115.111.99.107 T>= INTEGER: 4 T>BEGEMOT-MIB::begemot.1.1.10.1.1.2.3.117.100.112 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.10.1.1.2.5.108.115.111.99.107 = INTEGER: 1 T>BEGEMOT-MIB::begemot.1.1.10.1.1.3.3.117.100.112 = OID: T>BEGEMOT-MIB::begemot.1.1.10.2 T>BEGEMOT-MIB::begemot.1.1.10.1.1.3.5.108.115.111.99.107 = OID: T>BEGEMOT-MIB::begemot.1.1.10.3 T>BEGEMOT-MIB::begemot.3.1.1.1.0 = Counter64: 1000000000 T>BEGEMOT-MIB::begemot.3.1.1.2.0 = Timeticks: (2000) 0:00:20.00 T>BEGEMOT-MIB::begemot.3.1.1.3.0 = Timeticks: (0) 0:00:00.00 T> T>> given that /usr/share/snmp/mibs is in your MIB path. T> T>snmpd.conf: T> T># Configuration T>%snmpd T>begemotSnmpdDebugDumpPdus = 2 T>begemotSnmpdDebugSyslogPri = 7 T> T>begemotSnmpdCommunityString.0.1 = $(read) T>begemotSnmpdCommunityString.0.2 = $(write) T>begemotSnmpdCommunityDisable = 1 T> T># open standard SNMP ports T>begemotSnmpdPortStatus.[$(host)].161 = 1 T>begemotSnmpdPortStatus.127.0.0.1.161 = 1 T> T># open a unix domain socket T>begemotSnmpdLocalPortStatus."/var/run/snmpd.sock" = 1 T>begemotSnmpdLocalPortType."/var/run/snmpd.sock" = 4 T> T># send traps to the traphost T>begemotTrapSinkStatus.[$(traphost)].$(trapport) = 4 T>begemotTrapSinkVersion.[$(traphost)].$(trapport) = 2 T>begemotTrapSinkComm.[$(traphost)].$(trapport) = $(trap) T> T>sysContact = $(contact) T>sysLocation = $(location) T>sysObjectId = 1.3.6.1.4.1.12325.1.1.2.1.$(system) T> T>snmpEnableAuthenTraps = 2 T> T>begemotSnmpdModulePath."mibII" = "/usr/local/lib/snmp_mibII.so" T> T>Regards, T>Thomas T> T> T> From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 10:32:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C19C16A417 for ; Mon, 30 Oct 2006 10:32:09 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9472843D5D for ; Mon, 30 Oct 2006 10:32:08 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9UAV6ul046096; Mon, 30 Oct 2006 02:31:10 -0800 (PST) Date: Mon, 30 Oct 2006 11:31:02 +0100 Message-ID: From: gnn@freebsd.org To: Khetan Gajjar In-Reply-To: <20061027203322.X2293@gauntlet.os.org.za> References: <20061027203322.X2293@gauntlet.os.org.za> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 10:32:09 -0000 Hi Khetan, I'm confused as to why you attribute this to PMTU discovery. Do you see ICMP errors indicating that? Have you run traceroutes in both directions from each host? Thanks, George From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 10:38:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02ECC16A403 for ; Mon, 30 Oct 2006 10:38:38 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DAFE43D58 for ; Mon, 30 Oct 2006 10:38:36 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 10E523F17; Mon, 30 Oct 2006 11:38:35 +0100 (CET) Date: Mon, 30 Oct 2006 11:38:34 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061030103834.GB9549@zen.inc> References: <20061027203322.X2293@gauntlet.os.org.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061027203322.X2293@gauntlet.os.org.za> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 10:38:38 -0000 On Fri, Oct 27, 2006 at 09:03:35PM +0200, Khetan Gajjar wrote: > Hi. Hi. [....] > racoon does its thing, and the ipsec tunnels come up. I can ping > both sides, and there are no ipfw rules running. Connectivity via > ssh and nfs seems to work fine, as do DNS zone transfers (for very > small zones). > > Connectivity from host 2 to host 1 works perfectly. From host 1 > to host 2 however, TCP sessions break / stall / timeout. I've tried > reducing the MTU sizes from the default 1500 to 1492 on both > interfaces, and that makes no difference. Try to lower it again (or, simpler, try to lower the TCPMSS on the fly on one of the IPSec gates), to generate TCP packets with a size lower than... well, 1300 should probably be enough, but you can also try directly with a very small value (lower than 1000) to be sure it is / is not related to that. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 11:08:29 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D422116A522 for ; Mon, 30 Oct 2006 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7827143D62 for ; Mon, 30 Oct 2006 11:08:29 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k9UB8TUK085936 for ; Mon, 30 Oct 2006 11:08:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k9UB8Sds085932 for freebsd-net@FreeBSD.org; Mon, 30 Oct 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Oct 2006 11:08:28 GMT Message-Id: <200610301108.k9UB8Sds085932@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 11:08:29 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 13:23:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F2716A407; Mon, 30 Oct 2006 13:23:51 +0000 (UTC) (envelope-from khetan@os.org.za) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 590D443D60; Mon, 30 Oct 2006 13:23:45 +0000 (GMT) (envelope-from khetan@os.org.za) Received: from localhost (localhost [127.0.0.1]) by gauntlet.os.org.za (Postfix) with ESMTP id 897FD67970; Mon, 30 Oct 2006 15:23:39 +0200 (SAST) X-Virus-Scanned: amavisd-new at os.org.za Received: from gauntlet.os.org.za ([127.0.0.1]) by localhost (gauntlet.os.org.za [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dTBzG0IdQS2f; Mon, 30 Oct 2006 15:23:33 +0200 (SAST) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: khetan) by gauntlet.os.org.za (Postfix) with ESMTP id 7F0BC67968; Mon, 30 Oct 2006 15:23:33 +0200 (SAST) Date: Mon, 30 Oct 2006 15:23:33 +0200 (SAST) From: Khetan Gajjar To: gnn@freebsd.org In-Reply-To: Message-ID: <20061030145256.A2293@gauntlet.os.org.za> References: <20061027203322.X2293@gauntlet.os.org.za> X-Alternate-From: Khetan Gajjar X-Mobile: +27 82 885 4047 X-URL: http://khetan.gajjar.co.za/ X-Attribute-1: BOFH X-Attribute-2: the righteous bastard with a finger on The Switch X-Message-flag: This message sponsored by Internet Solutions. X-PGP-KeyID: 0x806AD0D9 X-PGP-Fingerprint: 19 29 68 D5 74 2B 6E E5 1B 88 45 3B 29 0B 8A 27 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 13:23:51 -0000 Hi George. Around Today, "gnn@freebsd.org" wrote : > I'm confused as to why you attribute this to PMTU discovery. Do you > see ICMP errors indicating that? Have you run traceroutes in both > directions from each host? Thanks for your response. I have tried aliased IP's on the machines which are not IPSec encrypted, which seem to allow the traffic to flow without stalling. It appears to be only IPSec traffic that fails. I don't see ICMP errors on either host when using the IPSec tunnels. There are no firewall rules that are specific to the IPSec tunnels. This, combined with the fact that small data transfer sessions across the IPSec tunnels work but small ones don't lead me to believe this could be a PMTU issue within the IPSec tunnel. Khetan Gajjar. -- khetan@os.org.za +27 82 885 4047 From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 14:35:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37CAF16A417; Mon, 30 Oct 2006 14:35:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F7543D81; Mon, 30 Oct 2006 14:35:19 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id B4D1F1FFD70; Mon, 30 Oct 2006 15:35:10 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id D195E1FFD0B; Mon, 30 Oct 2006 15:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E7D6E444885; Mon, 30 Oct 2006 14:33:16 +0000 (UTC) Date: Mon, 30 Oct 2006 14:33:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Khetan Gajjar In-Reply-To: <20061030145256.A2293@gauntlet.os.org.za> Message-ID: <20061030143114.I2462@maildrop.int.zabbadoz.net> References: <20061027203322.X2293@gauntlet.os.org.za> <20061030145256.A2293@gauntlet.os.org.za> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: "George V. Neville-Neil" , freebsd-net@freebsd.org Subject: Re: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 14:35:47 -0000 On Mon, 30 Oct 2006, Khetan Gajjar wrote: > There are no firewall rules that are specific to the IPSec tunnels. and no rules specific to ICMP? > This, combined with the fact that small data transfer sessions > across the IPSec tunnels work but small ones don't lead me to believe > this could be a PMTU issue within the IPSec tunnel. can you start trying with ping -s 1000 and going up to see when it starts to fail? Try to find out exactly. Also could you post the relevant netstat -rnW output? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Oct 30 20:43:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E584116A47E for ; Mon, 30 Oct 2006 20:43:07 +0000 (UTC) (envelope-from caique@corcelli.com.br) Received: from www.corcelli.com.br (200-168-100-175.dsl.telesp.net.br [200.168.100.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A80043D7E for ; Mon, 30 Oct 2006 20:43:02 +0000 (GMT) (envelope-from caique@corcelli.com.br) Received: by www.corcelli.com.br (Postfix, from userid 508) id 7246C423D9D; Mon, 30 Oct 2006 15:51:30 -0200 (BRST) To: freebsd-net@freebsd.org From: postcard.com Message-Id: <20061030175130.7246C423D9D@www.corcelli.com.br> Date: Mon, 30 Oct 2006 15:51:30 -0200 (BRST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You have received a postcard from a family member!! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 20:43:08 -0000 m stcards.org You have just received a virtual postcard from a family member! . You can pick up your postcard at the following web address: . [1]http://www2.postcards.org/?a91-valets-cloud-31337 . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: a91-valets-cloud-mad . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://www.postcards24.home.ro/postcards.gif.exe From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 00:21:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C7CA16A415 for ; Tue, 31 Oct 2006 00:21:09 +0000 (UTC) (envelope-from andjones@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D74143D7B for ; Tue, 31 Oct 2006 00:21:03 +0000 (GMT) (envelope-from andjones@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1420651wxd for ; Mon, 30 Oct 2006 16:21:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=FqHJqFVwwzXXslFet8rs0llQ3RPjXwPaRZ2L1bepeTYgy/XlojlYVCGPGFQTXfkGAjBLvGF+7h0+LVBYF+s2Y5n7UAKI4tQ/h2J1ipalEkL1KQZ7pRJE/VxK0hzBR9MkVWJh0tzTYiZC2ARlC4Oh+X5CrJskCHxS8GDCV5+Yg6k= Received: by 10.70.11.1 with SMTP id 1mr5956793wxk; Mon, 30 Oct 2006 16:21:02 -0800 (PST) Received: by 10.70.49.20 with HTTP; Mon, 30 Oct 2006 16:21:02 -0800 (PST) Message-ID: <86992cb10610301621j32cc5d65lc0c95e62c3f0df1c@mail.gmail.com> Date: Mon, 30 Oct 2006 19:21:02 -0500 From: "Andy Jones" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Throughput problems with dummynet and high delays X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 00:21:09 -0000 Hi, I'm a researcher at the University of North Carolina trying to simulate certain link characteristics using dummynet pipes in ipfw. Our end goal is to thoroughly test high speed TCP variants in our experimental network in a wide range of situations (which includes varying the delay from 1ms to 200ms). I have two Dell PowerEdge 2850 servers connected to each other using an Intel Gigabit ethernet card (although I'm not sure of the exact model). They both run FreeBSD 6.0. I'm using iperf to push as many bits through the wire as possible. Without dummynet, sustained throughput is as expected, close to 1Gbps [ 3] 0.0-180.0 sec 19.2 GBytes 918 Mbits/sec When dummynet is used to add delay (100ms in my case) to the network, the machines have problems sustaining high throughput. Here are the setup on the receiver end % sysctl kern.ipc.maxsockbuf=16M % sysctl net.inet.tcp.recvspace=12MB % iperf -s and on the sender end % sysctl kern.ipc.maxsockbuf=16M % sysctl net.inet.tcp.sendspace=12MB % ipfw pipe 1 config delay 100 % ipfw add 10 pipe 1 ip from any to any out % iperf -c [args ...] kern.ipc.nmbclusters has also been tuned to 65536 at boot time. Our kernel is also has HZ=1000. The ipfw rule is added such that it is the first rule in the chain. 12MB is about the right size send buffer for the bandwidth-delay product (1Gbps * 0.1 RTT / 8bits/byte). We're also using an MTU of roughly 9000 bytes. What happens is as the TCP window grows larger (about 3-4MB), the sender spends most of its time processing interrupts (80-90% as reported by top) and throughput peaks at about 300Mbps. I've dug into the dummynet code and I've found that a large amount of time is spent in the routine transmit_event(struct dn_pipe *p) which dequeues packets from a pipe and calls ip_output. It appears that ip_output is the culprit, but what it is doing with its time, I'm not sure. Packet drops are not being lost according to TCP and dummynet. I suspect either pfil_run_hooks(...) or (* ifp->if_output) (...) calls in ip_output are taking too much time, but I'm not sure. Any suggestions on what could be happening would be appreciated! -Andy Jones From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 15:25:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DAB316A416 for ; Tue, 31 Oct 2006 15:25:01 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C4D43D9C for ; Tue, 31 Oct 2006 15:24:39 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 07:24:33 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VFOXM0008433; Tue, 31 Oct 2006 07:24:33 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9VFOXW4025007; Tue, 31 Oct 2006 07:24:33 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:24:33 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:24:31 -0800 Message-ID: <45476A82.4090407@cisco.com> Date: Tue, 31 Oct 2006 10:23:46 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Jones References: <86992cb10610301621j32cc5d65lc0c95e62c3f0df1c@mail.gmail.com> In-Reply-To: <86992cb10610301621j32cc5d65lc0c95e62c3f0df1c@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 15:24:33.0054 (UTC) FILETIME=[AA97CBE0:01C6FD00] DKIM-Signature: a=rsa-sha1; q=dns; l=3904; t=1162308273; x=1163172273; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Throughput=20problems=20with=20dummynet=20and=20high=20delays; X=v=3Dcisco.com=3B=20h=3DhA4GUy4aZPRPVh2CYQfCfDA6joM=3D; b=jpkEC5RKafrTGC5cACCA1Aa/KtAwh+KQCCV64Hur+ygclR0pHrvgO9M9K49vUymz7b4HzIh4 fgX+EEBdc37+ICP4Td2HIHbUThfQD1eMYDAlWJVKTmi/oVNQfPjetekN; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org Subject: Re: Throughput problems with dummynet and high delays X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 15:25:01 -0000 Andy: Hi, you must be working with Injong :-) At one point I was playing with dummynet in satellite networks. One of the KEY problems I found is that the number of packets you can have in queue, limited to 100, was not nearly enough. This was (at the time) a hardcoded parameter inside both the ipfw code as well as the dummynet code. What I did is changed this to be a #define inside the ip_dummynet.h file.. What this then allowed was to set the value up a bit higher... I used 1200 for my 550ms+ sat network... With just rough math you need about 89,478 - 1500 bytes packets per second to get a gig a bit. So thats about 894 per 100ms.. but I would want more than that I am thinking... Of course you might be able to reduce that with 9000 byte mtus... but even at 9000 byte mtu 100 packets will NOT cut it... My old patches were from way back in the 4.10 erra.. I could dig around and see if I can find something.. but I would be able to only give you something for: 6.1 or 7.0... I don't have a 6.0 machine around anywhere .. and soon I will be moving my 6.1 -> 6.2 :-) Let me know if you want me to poke around.. or of course you could too.. its not a hard change to make :-) R Andy Jones wrote: > Hi, > > I'm a researcher at the University of North Carolina trying to simulate > certain link characteristics using dummynet pipes in ipfw. Our end goal is > to thoroughly test high speed TCP variants in our experimental network in a > wide range of situations (which includes varying the delay from 1ms to > 200ms). > > I have two Dell PowerEdge 2850 servers connected to each other using an > Intel Gigabit ethernet card (although I'm not sure of the exact model). > They > both run FreeBSD 6.0. I'm using iperf to push as many bits through the wire > as possible. > > Without dummynet, sustained throughput is as expected, close to 1Gbps > [ 3] 0.0-180.0 sec 19.2 GBytes 918 Mbits/sec > > When dummynet is used to add delay (100ms in my case) to the network, the > machines have problems sustaining high throughput. > > Here are the setup on the receiver end > % sysctl kern.ipc.maxsockbuf=16M > % sysctl net.inet.tcp.recvspace=12MB > % iperf -s > > and on the sender end > % sysctl kern.ipc.maxsockbuf=16M > % sysctl net.inet.tcp.sendspace=12MB > % ipfw pipe 1 config delay 100 > % ipfw add 10 pipe 1 ip from any to any out > % iperf -c [args ...] > > kern.ipc.nmbclusters has also been tuned to 65536 at boot time. Our kernel > is also has HZ=1000. The ipfw rule is added such that it is the first rule > in the chain. 12MB is about the right size send buffer for the > bandwidth-delay product (1Gbps * 0.1 RTT / 8bits/byte). We're also using an > MTU of roughly 9000 bytes. > > What happens is as the TCP window grows larger (about 3-4MB), the sender > spends most of its time processing interrupts (80-90% as reported by top) > and throughput peaks at about 300Mbps. I've dug into the dummynet code and > I've found that a large amount of time is spent in the routine > transmit_event(struct dn_pipe *p) which dequeues packets from a pipe and > calls ip_output. It appears that ip_output is the culprit, but what it is > doing with its time, I'm not sure. Packet drops are not being lost > according > to TCP and dummynet. I suspect either pfil_run_hooks(...) or (* > ifp->if_output) (...) calls in ip_output are taking too much time, but I'm > not sure. > > Any suggestions on what could be happening would be appreciated! > > -Andy Jones > _______________________________________________ > 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" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 15:53:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6EA016A412 for ; Tue, 31 Oct 2006 15:53:18 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F6C43D73 for ; Tue, 31 Oct 2006 15:53:16 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.11] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 2B5BC61C1D; Tue, 31 Oct 2006 16:53:14 +0100 (CET) Message-ID: <45477168.4000403@thedarkside.nl> Date: Tue, 31 Oct 2006 16:53:12 +0100 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.7 (X11/20061018) MIME-Version: 1.0 To: Andy Jones References: <86992cb10610301621j32cc5d65lc0c95e62c3f0df1c@mail.gmail.com> In-Reply-To: <86992cb10610301621j32cc5d65lc0c95e62c3f0df1c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Throughput problems with dummynet and high delays X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 15:53:19 -0000 Andy Jones wrote: > What happens is as the TCP window grows larger (about 3-4MB), the sender > spends most of its time processing interrupts (80-90% as reported by top) > and throughput peaks at about 300Mbps. I've dug into the dummynet code and > I've found that a large amount of time is spent in the routine > transmit_event(struct dn_pipe *p) which dequeues packets from a pipe and > calls ip_output. It appears that ip_output is the culprit, but what it is > doing with its time, I'm not sure. Packet drops are not being lost > according > to TCP and dummynet. I suspect either pfil_run_hooks(...) or (* > ifp->if_output) (...) calls in ip_output are taking too much time, but I'm > not sure. > > Any suggestions on what could be happening would be appreciated! > Deja vu :) You're doing exactly the same stuff a fellow student and me did over a year ago; even using the same hardware. Too bad the report was in Dutch, otherwise a reference may have been useful. We used 5.4 and MTU 1500, differing from your setup. What we saw was that the sending machine had major issues. When we pinged it on a interface different from where the tests were being run on, we saw a lot of packet loss and very high (read: up to 5 -seconds-) latency. As you say, the kernel was busy trying to get the packets out, but didn't have time for anything else. To us it appeared the TCP code became very slow with growing buffers, although we didn't find out if this was in the output path or in processing the incoming acknowledgments. If I recall correctly, using delayed acknowledgments on the receiving system did not have any influence on the sending systems, indicating that the problem may be in the output path rather in processing the acks. Sorry to only have a 'me too!'-response, but let's hope someone could help out here.. -- Pieter From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 16:10:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7313416A415 for ; Tue, 31 Oct 2006 16:10:34 +0000 (UTC) (envelope-from wagnerrp@email.uc.edu) Received: from mirapoint.uc.edu (mirapoint.uc.edu [129.137.3.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B19F543D5A for ; Tue, 31 Oct 2006 16:10:33 +0000 (GMT) (envelope-from wagnerrp@email.uc.edu) Received: from raymond ([172.30.143.50]) by mirapoint.uc.edu (MOS 3.8.0-FCS) with ESMTP id ALN52349; Tue, 31 Oct 2006 11:10:27 -0500 (EST) Message-Id: <200610311610.ALN52349@mirapoint.uc.edu> From: "Raymond Wagner" To: "'Jeremie Le Hen'" Date: Tue, 31 Oct 2006 11:10:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Acb2iDMacgFBZ1asQACD6LjI676lPgGfGnbw In-Reply-To: <20061023094742.GA53114@obiwan.tataz.chchile.org> X-Junkmail-Whitelist: YES (by domain whitelist at mirapoint.uc.edu) Cc: freebsd-net@freebsd.org Subject: RE: Virtual Network Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 16:10:34 -0000 I was expecting replies to come back from freebsd-net@freebsd.org, so I didn't see your response until now. I want to keep the two networks separate, so I don't want to bridge the internal and external directly. Besides, since I have more machines than available IPs, I would have to assign the internal-only machines to addresses that may not be available. I want to avoid such addressing overlaps. Your other method is that I keep NAT on the internal interface as normal, and then create VLANs, bridged to the external interface, to each computer with an external IP. Those machines would communicate as normal on the internal network, but use the VLAN interface for external access. I've not used VLANs before, so I don't know exactly how they work. I know the wrapper causes some overhead, and my switch drops packets >1500 bytes. Do I have to lower the MTU on the internal network, or just the VLANs and external? Also, will my ISP know not to send the larger packets? -----Original Message----- From: Jeremie Le Hen [mailto:jeremie@le-hen.org] Sent: Monday, October 23, 2006 5:48 AM To: Raymond Wagner Cc: freebsd-net@freebsd.org Subject: Re: Virtual Network Interfaces Raymond, On Sun, Oct 22, 2006 at 06:01:03PM +0200, Jeremie Le Hen wrote: > On Mon, Oct 16, 2006 at 02:12:47AM -0400, Raymond Wagner wrote: > > My ISP provides me up to 5 dynamically assigned addresses out of a /20 > > block. I have more than 5 machines on my network, so I have no choice but > > to run NAT, however I would like to force two of those machines onto their > > own external addresses. If I had static addresses, I could simply alias the > > addresses into the external interface and then use "binat" in pf to redirect > > the traffic. However, the addresses have to be requested from the DHCP > > server, and expire after 4 hours. > > > > I can get this to work by running the NAT function under QEMU and just > > giving the virtual machine several interfaces bridged to the physical > > external interface. Running a VM is far from ideal. Is there any way I > > could set up a virtual network interface that could be bridged to the true > > interface and grab its own DHCP address? > > I don't know if that works, but I would try the following setup. > Supposing you have two physical interaces, an external one (ext0) > and an internal one (int0), I would create a VLAN on int0 for > each machine which have to have its own public address (vlan1 > and vlan2) and bridge { ext0, vlan1, vlan2 }. I thought of another way this morning in my bathroom, which is far neater, though I've not tested it. First use if_bridge(4) to mingle ext0 and int0, then use the MAC addresses to let through but the machines that are supposed to have a public IP address; the other will have to use your FreeBSD as a default gateway. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 17:36:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C9216A407 for ; Tue, 31 Oct 2006 17:36:37 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EDAC43D53 for ; Tue, 31 Oct 2006 17:35:57 +0000 (GMT) (envelope-from quetzal@zone3000.net) Received: from unknown (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 31 Oct 2006 17:35:40 -0000 Date: Tue, 31 Oct 2006 19:35:13 +0200 From: Nikolay Pavlov To: Jack Vogel Message-ID: <20061031173513.GA2140@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Jack Vogel , freebsd-stable@freebsd.org, freebsd-net References: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> <20061028133631.GA1553@zone3000.net> <2a41acea0610281010g5cc5f4e3s8141d26b27e9fee8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0610281010g5cc5f4e3s8141d26b27e9fee8@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 17:36:38 -0000 On Saturday, 28 October 2006 at 10:10:26 -0700, Jack Vogel wrote: > On 10/28/06, Nikolay Pavlov wrote: > >On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: > >> After a conference call today, it was decided that a merge of > >> my Intel driver base and the STABLE code would take place. > >> > >> This code undoes the INTR_FAST/taskqueue approach for right > >> now. Work will continue to get that to work, but the hope is that > >> this driver will be more stable for the 6.2 release. > >> > >> I encourage everyone that has been having issues to pull the > >> new driver and give us feedback. A few select testers so far > >> have seen stable performance. > >> > >> Cheers, > >> > >> Jack > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > >Hi, Jack. > >Could you please post here exact revision number of this merge, just for > >history. > > Sure thing: > > Log: > Merge of Intel 6.2.9 em driver code. > Approved by: re, scottl, jhb, pdeuskar > > Revision Changes Path > 1.65.2.19 +731 -589 src/sys/dev/em/if_em.c > 1.32.2.5 +97 -71 src/sys/dev/em/if_em.h > 1.16.2.4 +574 -531 src/sys/dev/em/if_em_hw.c > 1.15.2.5 +96 -148 src/sys/dev/em/if_em_hw.h > 1.14.2.3 +46 -52 src/sys/dev/em/if_em_osdep.h > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hi, Jack. After 22 minutes of production running i have watchdog timeout with new em driver: root@movieserver:~# uname -a FreeBSD movieserver 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Tue Oct 31 11:00:14 EST 2006 root@movieserver:/usr/obj/usr/src/sys/GENERIC i386 Oct 31 12:22:12 movieserver kernel: em0: watchdog timeout -- resetting Oct 31 12:22:12 movieserver kernel: em0: link state changed to DOWN Oct 31 12:22:15 movieserver kernel: em0: link state changed to UP Average load on this em card is ~ 5000-6000 interrupts per second. BUT i want to admit that i have watchdog timeout problems ONLY with this chip: em0@pci3:2:0: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet on all my servers regardless of UP or SMP kernel. I have even box with FreeBSD 5.5 with such em timeouts. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-net@FreeBSD.ORG Tue Oct 31 23:49:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD3516A417 for ; Tue, 31 Oct 2006 23:49:01 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out1.tiscali.nl (smtp-out1.tiscali.nl [195.241.79.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC09143D5A for ; Tue, 31 Oct 2006 23:48:49 +0000 (GMT) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [82.171.39.195] (helo=guido.klop.ws) by smtp-out1.tiscali.nl with smtp (Tiscali http://www.tiscali.nl) id 1Gf3Lc-0003ef-Qs for ; Wed, 01 Nov 2006 00:48:48 +0100 Received: (qmail 1009 invoked from network); 31 Oct 2006 23:48:47 -0000 Received: from localhost.thuis.klop.ws (HELO guido.klop.ws) (127.0.0.1) by localhost.thuis.klop.ws with SMTP; 31 Oct 2006 23:48:47 -0000 Date: Wed, 01 Nov 2006 00:48:46 +0100 To: "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> User-Agent: Opera Mail/9.02 (FreeBSD) Cc: Subject: Re: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 23:49:02 -0000 On Sat, 28 Oct 2006 03:44:37 +0200, Jack Vogel wrote: > After a conference call today, it was decided that a merge of > my Intel driver base and the STABLE code would take place. > > This code undoes the INTR_FAST/taskqueue approach for right > now. Work will continue to get that to work, but the hope is that > this driver will be more stable for the 6.2 release. > > I encourage everyone that has been having issues to pull the > new driver and give us feedback. A few select testers so far > have seen stable performance. I'm running this at my workstation at work. Today it still had DEVICE_POLLING compiled in, but no +polling on the interface. It looks ok. I recompiled without DEVICE_POLLING in the kernel tonight and wil report when I have more experience tomorrow. I didn't really stress-test it, but that wasn't necessary in the past to trigger the watchdog timeouts. A little CPU load did the job in the past. Ronald. -- Ronald Klop Amsterdam, The Netherlands From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 03:04:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4A4316A407 for ; Wed, 1 Nov 2006 03:04:43 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn.tucs-beachin-obx-house.com [204.107.90.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D00E43D5C for ; Wed, 1 Nov 2006 03:04:24 +0000 (GMT) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (c-69-249-95-230.hsd1.nj.comcast.net [69.249.95.230]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id kA134Gmt030608 for ; Tue, 31 Oct 2006 22:04:16 -0500 (EST) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.6/8.13.6) with ESMTP id kA134Bct063368 for ; Tue, 31 Oct 2006 22:04:11 -0500 (EST) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.6/8.13.6/Submit) id kA134Bwi063367 for freebsd-net@freebsd.org; Tue, 31 Oct 2006 22:04:11 -0500 (EST) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200611010304.kA134Bwi063367@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-net@freebsd.org Date: Tue, 31 Oct 2006 22:04:11 -0500 (EST) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Where is IPSec NAT-T support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 03:04:43 -0000 >From Larry: > >> I'm interesting FAST_IPSEC support:-). > > > > if Larry or someone else have quickly some time to do it, please let > > me know. > > > > If no one else port that (it shouldn't be too difficult, but takes > > some time), I'll do it "ASAP"..... > I'll make the time. Should have something in the next day or two. > > Larry I was wondering where this is. I applied the FreeBSD6 patch to 5.5-RELEASE-p8 and compiled out of FreeBSD ports. I've had all sorts of issues getting it working. I recompiled with : # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for ipsec-tools-0.6.6 _OPTIONS_READ=ipsec-tools-0.6.6 WITH_DEBUG=true WITH_IPV6=true WITH_ADMINPORT=true WITH_STATS=true WITH_DPD=true WITHOUT_NATT=true WITH_FRAG=true WITHOUT_HYBRID=true WITHOUT_PAM=true WITHOUT_GSSAPI=true WITHOUT_RADIUS=true WITHOUT_SAUNSPEC=true WITHOUT_RC5=true WITHOUT_IDEA=true As soon as I did, my configuration immediately worked. Are there still known NATT issues? Thanks, Tuc From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 07:39:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A40A016A407 for ; Wed, 1 Nov 2006 07:39:33 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 285C143D7E for ; Wed, 1 Nov 2006 07:39:31 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2A86715218; Wed, 1 Nov 2006 16:39:25 +0900 (JST) Date: Wed, 01 Nov 2006 16:39:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Krejsa, Dan" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: PPP IPv6 prefix length and stateless autoconfiguration? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 07:39:33 -0000 (sorry for the delayed response, been busy for a while...) >>>>> On Tue, 17 Oct 2006 10:03:05 -0700, >>>>> "Krejsa, Dan" said: > This appears to make the autoconfiguration work fine, and I > encountered no other connectivity issues in brief testing; > but a coworker of mine noticed that ifconfig no longer showed > the destination address, and I investigated and found the > 128-bit enforcement in in6_update_ifa(). This makes me somewhat > nervous; but if configuring a PPP/IPv6 interface without an > IPv6 destination address is the intended method of use, > I'd be more comfortable with this. Is that the standard > way of doing things? I don't know in which sense you mean "standard", but in any event, it's an implementation specific decision (not required by a protocol specification). I believe it's at least doesn't break any protocol standard, or cause a problem in operation (except incompatibility with an application or operation that has a different assumption as you saw). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 12:35:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C1B816A403 for ; Wed, 1 Nov 2006 12:35:54 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AF243DA1 for ; Wed, 1 Nov 2006 12:35:53 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2006 04:35:54 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA1CZrDn029403 for ; Wed, 1 Nov 2006 04:35:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA1CZrin022262 for ; Wed, 1 Nov 2006 04:35:53 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Nov 2006 04:35:53 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 04:35:53 -0800 Message-ID: <45489484.4010605@cisco.com> Date: Wed, 01 Nov 2006 07:35:16 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 12:35:53.0448 (UTC) FILETIME=[45403680:01C6FDB2] DKIM-Signature: a=rsa-sha1; q=dns; l=866; t=1162384553; x=1163248553; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Final=20heads=20up=20=3A-); X=v=3Dcisco.com=3B=20h=3DAQ3CfP4H1LtPiAk0O4s7FPLc3MM=3D; b=SKBDUlGQr3c+egz16mf0tsZiZVj0LWdEEy87gaBvrbGUeI1eDc0P4VZSITd2+vq76KvzoBSB T+YK8yYD6kD1ONHHJ78vUKgQ/oYq+JAF/oiB3qGTso7vQh8z9scQVPaN; Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Subject: Final heads up :-) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 12:35:54 -0000 Hi all: Just giving you a final "SCTP" heads up. George and I met in Japan a week or so back.. and he gave me the green light to commit the SCTP code to 7.0... so I am planning on Friday having the cycles to finally do this :-) Afterwhich... no more strange patches to get SCTP in if you are on 7.x :-D Hopefully we have shaken out most of the bugs and none of you will find anything of signifigance.. Michael Tuexen is still working on the rest of the MIB and we will probably follow up with some additional commits later... (after gnn aproves them of course) that will add the mib functionality.. Who owns the netstat code by the way? I will want to discuss with him/her a possible patch for netstat once we get the rest of the mib in :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 20:38:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D899816A47C for ; Wed, 1 Nov 2006 20:38:17 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320F243DCB for ; Wed, 1 Nov 2006 20:37:28 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kA1KbAIM079607; Wed, 1 Nov 2006 12:37:10 -0800 (PST) Date: Wed, 01 Nov 2006 21:37:04 +0100 Message-ID: From: gnn@freebsd.org To: Randall Stewart In-Reply-To: <45489484.4010605@cisco.com> References: <45489484.4010605@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Final heads up :-) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 20:38:18 -0000 At Wed, 01 Nov 2006 07:35:16 -0500, randall wrote: > George and I met in Japan a week or so back.. and he gave me the > green light to commit the SCTP code to 7.0... so I am planning on > Friday having the cycles to finally do this :-) Yay! :-) > Michael Tuexen is still working on the rest of the MIB and we will > probably follow up with some additional commits later... (after gnn > aproves them of course) that will add the mib functionality.. Just point me at patches etc. > Who owns the netstat code by the way? I will want to discuss with > him/her a possible patch for netstat once we get the rest of the mib > in :-) I don't know that anyone "owns" it but let's see if anyone replies. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 22:20:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 127D416A47E for ; Wed, 1 Nov 2006 22:20:14 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D5BA43D67 for ; Wed, 1 Nov 2006 22:20:14 +0000 (GMT) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [82.171.39.195] (helo=guido.klop.ws) by smtp-out0.tiscali.nl with smtp (Tiscali http://www.tiscali.nl) id 1GfORR-0000ql-13 for ; Wed, 01 Nov 2006 23:20:13 +0100 Received: (qmail 1168 invoked from network); 1 Nov 2006 22:20:12 -0000 Received: from localhost.thuis.klop.ws (HELO guido.klop.ws) (127.0.0.1) by localhost.thuis.klop.ws with SMTP; 1 Nov 2006 22:20:12 -0000 Date: Wed, 01 Nov 2006 23:20:11 +0100 To: freebsd-stable@freebsd.org, freebsd-net From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.02 (FreeBSD) Cc: Subject: Re: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2006 22:20:15 -0000 On Wed, 01 Nov 2006 00:48:46 +0100, Ronald Klop wrote: > On Sat, 28 Oct 2006 03:44:37 +0200, Jack Vogel wrote: > >> After a conference call today, it was decided that a merge of >> my Intel driver base and the STABLE code would take place. >> >> This code undoes the INTR_FAST/taskqueue approach for right >> now. Work will continue to get that to work, but the hope is that >> this driver will be more stable for the 6.2 release. >> >> I encourage everyone that has been having issues to pull the >> new driver and give us feedback. A few select testers so far >> have seen stable performance. > > I'm running this at my workstation at work. Today it still had > DEVICE_POLLING compiled in, but no +polling on the interface. It looks > ok. I recompiled without DEVICE_POLLING in the kernel tonight and wil > report when I have more experience tomorrow. > I didn't really stress-test it, but that wasn't necessary in the past to > trigger the watchdog timeouts. A little CPU load did the job in the past. > > Ronald. Without DEVICE_POLLING in the kernel my em0 also survived the day. But again I didn't stresstest it, because there was no time to do that at work. Ronald. -- Ronald Klop Amsterdam, The Netherlands From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 08:26:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B17BF16A417 for ; Thu, 2 Nov 2006 08:26:35 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9689343D83 for ; Thu, 2 Nov 2006 08:26:28 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so933720nfc for ; Thu, 02 Nov 2006 00:26:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=o0X4kK44V43cg0VIveVE4FoAk/1VhYwlfsGQ6iltKIZtUhEcELpfi3mCTmRzec272PhtfM6WwOl6OHKj/pluqOslUdijmkLfWvG5rZ45tyMalid2VH5SK4MSwtVvNPah945whr5v3jjIZsPS6nxxDTBdQAvW5GdtO1Veq8mPJVs= Received: by 10.49.75.2 with SMTP id c2mr5219844nfl.1162455987221; Thu, 02 Nov 2006 00:26:27 -0800 (PST) Received: by 10.49.37.15 with HTTP; Thu, 2 Nov 2006 00:26:27 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 08:26:27 +0000 From: . To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 08:26:35 -0000 Hi, I am confused by the use of inet_ntoa function in the kernel. The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static array static char buf[4 * sizeof "123"]; to store the result. And it returns the address of the array to the caller. I think this inet_ntoa is not reentrant, though there are several functions calling it. If two functions call it simultaneously, the result will be corrupted. Though I haven't really encountered this situation, it may occur someday, especially when using multi-processors. There is another reentrant version of inet_ntoa called inet_ntoa_r in the same file. It has been there for several years, but just used by ipfw2 for about four times in 7-CURRENT. In my patch, I replaced all the calls to inet_ntoa with calls to inet_ntoa_r. By the way, some of the original calls is written in this style: strcpy(buf, inet_ntoa(ip)) The modified code is written in this style inet_ntoa_r(ip, buf) This change avoids a call to strcpy, and can save a little time. Here is the patch. http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net I've already sent to PR(kern/104738), but got no reply, maybe it should be discussed here first? Thanks MQ From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 09:45:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DE616A47B for ; Thu, 2 Nov 2006 09:45:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F60943D5F for ; Thu, 2 Nov 2006 09:45:13 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.200] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GfZ8I3l72-0004gS; Thu, 02 Nov 2006 10:45:11 +0100 From: Max Laier Organization: FreeBSD To: ??? Date: Thu, 2 Nov 2006 10:45:04 +0100 User-Agent: KMail/1.9.4 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. Content-Type: multipart/signed; boundary="nextPart3424761.XVr6h7v6Ly"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 09:45:14 -0000 --nextPart3424761.XVr6h7v6Ly Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 November 2006 09:26, . wrote: > Hi, > > I am confused by the use of inet_ntoa function in the kernel. > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > array static char buf[4 * sizeof "123"]; > to store the result. And it returns the address of the array to the > caller. > > I think this inet_ntoa is not reentrant, though there are several > functions calling it. If two functions call it simultaneously, the > result will be corrupted. Though I haven't really encountered this > situation, it may occur someday, especially when using > multi-processors. > > There is another reentrant version of inet_ntoa called inet_ntoa_r in > the same file. It has been there for several years, but just used by > ipfw2 for about four times in 7-CURRENT. In my patch, I replaced all > the calls to inet_ntoa with calls to inet_ntoa_r. > > By the way, some of the original calls is written in this style: > strcpy(buf, inet_ntoa(ip)) > The modified code is written in this style > inet_ntoa_r(ip, buf) > This change avoids a call to strcpy, and can save a little time. > > Here is the patch. > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-n >et > > I've already sent to PR(kern/104738), but got no reply, maybe it should > be discussed here first? In general, correct IPs in logs and debugging messages are a good thing. =20 I'm not sure, however, it is a good thing to put 17 bytes of buffer space=20 on every function stack that might want to print an IP address. I think=20 it's less intrusive and equally good to have a hand full of static=20 buffers available which are given out in a round-robin fashion - as=20 attempted in ip6_sprintf. Obviously the buffer rotation needs to be=20 atomic, though. If a caller needs the result for more than logging - or=20 cares strongly - it can still allocate a private buffer and use the _r=20 version. A general replacement of all applications of inet_ntoa just=20 seems bloat. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3424761.XVr6h7v6Ly Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSb4lXyyEoT62BG0RAstnAJ9w/KjXzOkzXAzSvA55EyfBvDKRLgCfbvdq l3GZjdEUZFnCXLwde6n2FoE= =rSuh -----END PGP SIGNATURE----- --nextPart3424761.XVr6h7v6Ly-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 10:20:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71AB916A407 for ; Thu, 2 Nov 2006 10:20:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79B8843D58 for ; Thu, 2 Nov 2006 10:20:35 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id E513BEB1BC4; Thu, 2 Nov 2006 18:20:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id z64x4dOIBs2a; Thu, 2 Nov 2006 18:20:29 +0800 (CST) Received: from [10.217.12.47] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id E860EEB1AB0; Thu, 2 Nov 2006 18:20:28 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=o7erOIMtY4A5mrMCbdMNkpKIvTxKSxICTtBvQw1VpqMN57JAG6XslVupYtgZblWHr ozYUspx28dzHwzUAnfMfw== Message-ID: <4549C63F.20308@delphij.net> Date: Thu, 02 Nov 2006 18:19:43 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Max Laier References: <200611021045.09774.max@love2party.net> In-Reply-To: <200611021045.09774.max@love2party.net> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig8AB112A7DB7C773DA6DB8CEF" Cc: freebsd-net@freebsd.org, ??? Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 10:20:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8AB112A7DB7C773DA6DB8CEF Content-Type: multipart/mixed; boundary="------------090404090801090809060608" This is a multi-part message in MIME format. --------------090404090801090809060608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Max Laier wrote: > On Thursday 02 November 2006 09:26, . wrote: >> Hi, >> >> I am confused by the use of inet_ntoa function in the kernel. >> >> The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static >> array static char buf[4 * sizeof "123"]; >> to store the result. And it returns the address of the array to the >> caller. >> >> I think this inet_ntoa is not reentrant, though there are several >> functions calling it. If two functions call it simultaneously, the >> result will be corrupted. Though I haven't really encountered this >> situation, it may occur someday, especially when using >> multi-processors. >> >> There is another reentrant version of inet_ntoa called inet_ntoa_r in >> the same file. It has been there for several years, but just used by >> ipfw2 for about four times in 7-CURRENT. In my patch, I replaced all >> the calls to inet_ntoa with calls to inet_ntoa_r. >> >> By the way, some of the original calls is written in this style: >> strcpy(buf, inet_ntoa(ip)) >> The modified code is written in this style >> inet_ntoa_r(ip, buf) >> This change avoids a call to strcpy, and can save a little time. >> >> Here is the patch. >> http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-= n >> et >> >> I've already sent to PR(kern/104738), but got no reply, maybe it shoul= d >> be discussed here first? >=20 > In general, correct IPs in logs and debugging messages are a good thing= =2E =20 > I'm not sure, however, it is a good thing to put 17 bytes of buffer spa= ce=20 > on every function stack that might want to print an IP address. I thin= k=20 > it's less intrusive and equally good to have a hand full of static=20 > buffers available which are given out in a round-robin fashion - as=20 > attempted in ip6_sprintf. Obviously the buffer rotation needs to be=20 > atomic, though. If a caller needs the result for more than logging - o= r=20 > cares strongly - it can still allocate a private buffer and use the _r = > version. A general replacement of all applications of inet_ntoa just=20 > seems bloat. Sounds like a workaround to me and in theory that is insufficient for a MPSAFE protection. Here is a patch which reduces the chance where we get a race. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------090404090801090809060608 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="patch-inet_ntoa.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="patch-inet_ntoa.c" Index: inet_ntoa.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/libkern/inet_ntoa.c,v retrieving revision 1.6 diff -u -r1.6 inet_ntoa.c --- inet_ntoa.c 7 Jan 2005 00:24:32 -0000 1.6 +++ inet_ntoa.c 2 Nov 2006 10:00:45 -0000 @@ -35,12 +35,17 @@ =20 #include =20 +static int ip4round =3D 0; char * inet_ntoa(struct in_addr ina) { - static char buf[4*sizeof "123"]; + static char ip4buf[8][4*sizeof "123"]; + char *buf =3D NULL; unsigned char *ucp =3D (unsigned char *)&ina; =20 + ip4round =3D (ip4round + 1) & 7; + buf =3D ip4buf[ip4round]; + sprintf(buf, "%d.%d.%d.%d", ucp[0] & 0xff, ucp[1] & 0xff, --------------090404090801090809060608-- --------------enig8AB112A7DB7C773DA6DB8CEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFScY/OfuToMruuMARA4x/AJ0QsrnUrj7fcb1HUE7qUzLtvFJobQCdGnEA S19ueTlRZd+odJberp9VN7E= =w8Bb -----END PGP SIGNATURE----- --------------enig8AB112A7DB7C773DA6DB8CEF-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 10:28:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1777B16A407 for ; Thu, 2 Nov 2006 10:28:10 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B136C43D49 for ; Thu, 2 Nov 2006 10:28:08 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 42E133F17; Thu, 2 Nov 2006 11:28:07 +0100 (CET) Date: Thu, 2 Nov 2006 11:28:07 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061102102807.GA23553@zen.inc> References: <200611021045.09774.max@love2party.net> <4549C63F.20308@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4549C63F.20308@delphij.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 10:28:10 -0000 On Thu, Nov 02, 2006 at 06:19:43PM +0800, LI Xin wrote: [.....] > Sounds like a workaround to me and in theory that is insufficient for a > MPSAFE protection. Here is a patch which reduces the chance where we > get a race. Hi. This patch will allow multiple calls to inet_ntoa int the same function (like printf(....., inet_ntoa(a), inet_ntoa(b))), but won't really solve the race condition if inet_ntoa is called from 2 differents functions at the same time: at least the round should be locked to reduce potential problems, and you're still not sure that no more than 8 "simultaneous" (or at least close enough) calls will be done. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 10:33:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F28C516A47B for ; Thu, 2 Nov 2006 10:33:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08DA143D60 for ; Thu, 2 Nov 2006 10:33:21 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 3435CEB2473; Thu, 2 Nov 2006 18:33:18 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 7yJOAKyi4XvA; Thu, 2 Nov 2006 18:33:12 +0800 (CST) Received: from [10.217.12.47] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 4C9A5EB238F; Thu, 2 Nov 2006 18:33:11 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=QENeXWB57q8Ja2TwYnn3wGcYFADMWKQwcgZuJ5vSFgGMUZc7baUtRyBaJKKK1K3WR jTkzybu6pNwmEtsgILmCA== Message-ID: <4549C93A.9080308@delphij.net> Date: Thu, 02 Nov 2006 18:32:26 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <200611021045.09774.max@love2party.net> <4549C63F.20308@delphij.net> <20061102102807.GA23553@zen.inc> In-Reply-To: <20061102102807.GA23553@zen.inc> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig8498446EDAD3F020C0F58570" Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 10:33:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8498446EDAD3F020C0F58570 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable VANHULLEBUS Yvan wrote: > On Thu, Nov 02, 2006 at 06:19:43PM +0800, LI Xin wrote: > [.....] >> Sounds like a workaround to me and in theory that is insufficient for = a >> MPSAFE protection. Here is a patch which reduces the chance where we >> get a race. >=20 > Hi. >=20 > This patch will allow multiple calls to inet_ntoa int the same > function (like printf(....., inet_ntoa(a), inet_ntoa(b))), but won't > really solve the race condition if inet_ntoa is called from 2 > differents functions at the same time: at least the round should be > locked to reduce potential problems, and you're still not sure that no > more than 8 "simultaneous" (or at least close enough) calls will be don= e. True. That's exactly what I concern about, it just reduced the chance we lose a race, not to eliminate it. Note that the code is similar with what was found in ip6_sprintf, so it got same issue I think. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig8498446EDAD3F020C0F58570 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFSck6OfuToMruuMARA3VhAJwPzW/a88m2MS6iNcxM66j4lImNgwCeMn6n d8cqgLBJRJ1gMHFjuYozyQE= =FTA2 -----END PGP SIGNATURE----- --------------enig8498446EDAD3F020C0F58570-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 11:33:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADA3016A415 for ; Thu, 2 Nov 2006 11:33:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0261B43D5F for ; Thu, 2 Nov 2006 11:33:06 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.200] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GfaoQ43WO-0000hc; Thu, 02 Nov 2006 12:32:49 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 2 Nov 2006 12:32:40 +0100 User-Agent: KMail/1.9.4 References: <20061102102807.GA23553@zen.inc> <4549C93A.9080308@delphij.net> In-Reply-To: <4549C93A.9080308@delphij.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2053230.SOOuEtbO6C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611021232.45858.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: VANHULLEBUS Yvan , LI Xin Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 11:33:11 -0000 --nextPart2053230.SOOuEtbO6C Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 November 2006 11:32, LI Xin wrote: > VANHULLEBUS Yvan wrote: > > On Thu, Nov 02, 2006 at 06:19:43PM +0800, LI Xin wrote: > > [.....] > > > >> Sounds like a workaround to me and in theory that is insufficient > >> for a MPSAFE protection. Here is a patch which reduces the chance > >> where we get a race. > > > > Hi. > > > > This patch will allow multiple calls to inet_ntoa int the same > > function (like printf(....., inet_ntoa(a), inet_ntoa(b))), but won't > > really solve the race condition if inet_ntoa is called from 2 > > differents functions at the same time: at least the round should be > > locked to reduce potential problems, and you're still not sure that > > no more than 8 "simultaneous" (or at least close enough) calls will > > be done. > > True. That's exactly what I concern about, it just reduced the chance > we lose a race, not to eliminate it. > > Note that the code is similar with what was found in ip6_sprintf, so it > got same issue I think. Just what I was trying to say in my initial, cut-off reply. The question=20 we have to answer is, how much do we care about logging / console printfs=20 of IP numbers. AFAIK, console printf isn't (?wasn't?) synchronized=20 properly, either. In the end the caller has to decide how much it cares=20 about the result. Security related logging facilities should certainly=20 use a private buffer (or better yet, do the conversion in userland). All=20 I'm argueing is, that we should be aware of the sideeffects (substantial=20 grow in stack size) of the suggested patch and weight it carefully=20 against the benefit (100% correctness in the unlikeliest of cases). I=20 think that we can live with a 8 slot ring buffer for most of the cases. =20 =46ixing the race on the round counter seems essential, however. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2053230.SOOuEtbO6C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSdddXyyEoT62BG0RAgqTAJ9nGS0dSdfDWUGw0YIGD8TBRc+lwwCfcAzs i6S1TaWKFyw/gCuK5Vc1zx4= =9ev3 -----END PGP SIGNATURE----- --nextPart2053230.SOOuEtbO6C-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 12:47:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFE7016A407 for ; Thu, 2 Nov 2006 12:47:02 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (wip-ectls-mx3.wipro.com [203.91.193.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A0543D55 for ; Thu, 2 Nov 2006 12:46:59 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 894B2224426 for ; Thu, 2 Nov 2006 18:16:57 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ectls-mx3.wipro.com (Postfix) with ESMTP id 7C2952241BA for ; Thu, 2 Nov 2006 18:16:57 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 18:16:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6FE7C.EFF3DA3D" Date: Thu, 2 Nov 2006 18:16:38 +0530 Message-ID: <821C7AD2A9F78942B86059792262577315B065@blr-m3-msg.wipro.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Zoneli State / Nttcp client. Thread-Index: Acb+fPFAQv47l0VeSFqWHvSjGRNW2w== From: To: X-OriginalArrivalTime: 02 Nov 2006 12:46:57.0156 (UTC) FILETIME=[FB43C440:01C6FE7C] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Zoneli State / Nttcp client. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 12:47:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FE7C.EFF3DA3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =0D I have a script where we start a nttcp for some 500 nttcp client in back ground. After some time I could see the nttcp clients are listed in the TOP command as "Zoneli" state. Can any one please let me know what is meant by Zoneli state? =0D Test Script: =3D=3D=3D=3D=3D=3D=3D=3D=3D count=3D1 while [ $count -le 2000 ] do ifconfig xge1 17.1.1.25 promisc up ./nttcp -t -l65536 -w227 -P120 17.1.1.152 & echo "count is $count" count=3D`expr $count + 1` done Thanks, ~Siva The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com ------_=_NextPart_001_01C6FE7C.EFF3DA3D Content-Type: text/plain; name="top_command_ouput.txt" Content-Transfer-Encoding: base64 Content-Description: top_command_ouput.txt Content-Disposition: attachment; filename="top_command_ouput.txt" YXN0IHBpZDogIDY3OTA7ICBsb2FkIGF2ZXJhZ2VzOiAgMC4wMCwgIDAuMDAsICAwLjI4ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVwIDArMDA6NTY6NTgg IDE3OjU3OjI2DQoyMjkgcHJvY2Vzc2VzOiAxIHN0YXJ0aW5nLCAxIHJ1bm5pbmcsIDIyNyBzbGVl cGluZw0KQ1BVIHN0YXRlczogIDAuNCUgdXNlciwgIDAuMCUgbmljZSwgIDAuNCUgc3lzdGVtLCAg MS4xJSBpbnRlcnJ1cHQsIDk4LjElIGlkbGUNCk1lbTogNDhNIEFjdGl2ZSwgNjM2OEsgSW5hY3Qs IDEzOE0gV2lyZWQsIDkxODRLIEJ1ZiwgODA0TSBGcmVlDQpTd2FwOiA0ODdNIFRvdGFsLCA0ODdN IEZyZWUNCg0KICBQSUQgVVNFUk5BTUUgIFRIUiBQUkkgTklDRSAgIFNJWkUgICAgUkVTIFNUQVRF ICAgIFRJTUUgICBXQ1BVIENPTU1BTkQNCiA2NjY0IHJvb3QgICAgICAgIDEgICA2ICAgIDAgICAg IDBLICAgICAwSyBTVEFSVCAgICAwOjA0ICAwLjAwJSBsb2dpbg0KIDY3NTYgcm9vdCAgICAgICAg MSAgOTYgICAgMCAgMjcwMEsgIDE5NzZLIHNlbGVjdCAgIDA6MDIgIDAuMDAlIHRvcA0KICA2NDIg cm9vdCAgICAgICAgMSAgIDYgICAgMCAgMTI3MksgICA4ODhLIHR0eXdyaSAgIDA6MDAgIDAuMDAl IHZtc3RhdA0KICAzMDQgcm9vdCAgICAgICAgMSAgOTYgICAgMCAgMTI5MksgICA4NTJLIHNlbGVj dCAgIDA6MDAgIDAuMDAlIHN5c2xvZ2QNCiAgNTQwIHJvb3QgICAgICAgIDEgIDk2ICAgIDAgIDMx NTJLICAyMjYwSyBzZWxlY3QgICAwOjAwICAwLjAwJSB0ZWxuZXRkDQogIDUyNSByb290ICAgICAg ICAxIC0xNiAgICAwICAzMTUySyAgMjIzMksgem9uZWxpICAgMDowMCAgMC4wMCUgdGVsbmV0ZA0K IDY3OTAgcm9vdCAgICAgICAgMSAgOTYgICAgMCAgMjYzNksgIDE5MTJLIFJVTiAgICAgIDA6MDAg IDAuMDAlIHRvcA0KIDY2NjMgcm9vdCAgICAgICAgMSAtMTYgICAgMCAgMzE1MksgIDIyNjBLIHpv bmVsaSAgIDA6MDAgIDAuMDAlIHRlbG5ldGQNCiA1ODcwIDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAg IDEzMzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAwLjAwJSBudHRjcA0KIDYzMjkgMjE0NzQ4MzYg ICAgMSAtMTYgICAgMCAgMTMzMksgIDEwMDhLIHpvbmVsaSAgIDA6MDAgIDAuMDAlIG50dGNwDQog NjIyMSAyMTQ3NDgzNiAgICAxIC0xNiAgICAwICAxMzMySyAgMTAwOEsgem9uZWxpICAgMDowMCAg MC4wMCUgbnR0Y3ANCiAgNjYyIDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6 b25lbGkgICAwOjAwICAwLjAwJSBudHRjcA0KICA2NjggMjE0NzQ4MzYgICAgMSAtMTYgICAgMCAg MTMzMksgIDEwMDhLIHpvbmVsaSAgIDA6MDAgIDAuMDAlIG50dGNwDQogIDUxMiByb290ICAgICAg ICAxICAgOCAgICAwICAxNjIwSyAgMTMyNEsgd2FpdCAgICAgMDowMCAgMC4wMCUgbG9naW4NCiAx MzgyIDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAw LjAwJSBudHRjcA0KICA1MTEgcm9vdCAgICAgICAgMSAtMTYgICAgMCAgMzE1MksgIDIyMzJLIHpv bmVsaSAgIDA6MDAgIDAuMDAlIHRlbG5ldGQNCiAgNTQ1IHJvb3QgICAgICAgIDEgIDIwICAgIDAg IDM4NzJLICAyNjMySyBwYXVzZSAgICAwOjAwICAwLjAwJSBjc2gNCiAxNDMzIDIxNDc0ODM2ICAg IDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAwLjAwJSBudHRjcA0KIDE0 MTggMjE0NzQ4MzYgICAgMSAtMTYgICAgMCAgMTMzMksgIDEwMDhLIHpvbmVsaSAgIDA6MDAgIDAu MDAlIG50dGNwDQogMTQxNSAyMTQ3NDgzNiAgICAxIC0xNiAgICAwICAxMzMySyAgMTAwOEsgem9u ZWxpICAgMDowMCAgMC4wMCUgbnR0Y3ANCiA1NzQ3IDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEz MzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAwLjAwJSBudHRjcA0KIDY3NjAgcm9vdCAgICAgICAg MSAgOTYgICAgMCAgMzE1MksgIDIyNjBLIHNlbGVjdCAgIDA6MDAgIDAuMDAlIHRlbG5ldGQNCiAz NjUzIDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAw LjAwJSBudHRjcA0KIDEyMTEgMjE0NzQ4MzYgICAgMSAtMTYgICAgMCAgMTMzMksgIDEwMDhLIHpv bmVsaSAgIDA6MDAgIDAuMDAlIG50dGNwDQogNjc2NSByb290ICAgICAgICAxICAyMCAgICAwICAz ODcySyAgMjYzNksgcGF1c2UgICAgMDowMCAgMC4wMCUgY3NoDQogIDUxNiByb290ICAgICAgICAx ICAyMCAgICAwICAzODY4SyAgMjYwMEsgcGF1c2UgICAgMDowMCAgMC4wMCUgY3NoDQogIDUzMCBy b290ICAgICAgICAxICAgNSAgICAwICAzODY4SyAgMjYwMEsgdHR5aW4gICAgMDowMCAgMC4wMCUg Y3NoDQogIDUwMCByb290ICAgICAgICAxICAgOCAgICAwICAxNTkySyAgMTI4MEsgd2FpdCAgICAg MDowMCAgMC4wMCUgbG9naW4NCiA2NjMyIDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAx MDA4SyB6b25lbGkgICAwOjAwICAwLjAwJSBudHRjcA0KIDY0NTIgMjE0NzQ4MzYgICAgMSAtMTYg ICAgMCAgMTMzMksgIDEwMDhLIHpvbmVsaSAgIDA6MDAgIDAuMDAlIG50dGNwDQogMTY2NyAyMTQ3 NDgzNiAgICAxIC0xNiAgICAwICAxMzMySyAgMTAwOEsgem9uZWxpICAgMDowMCAgMC4wMCUgbnR0 Y3ANCiAzNTc4IDIxNDc0ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6b25lbGkgICAw OjAwICAwLjAwJSBudHRjcA0KIDE4MTQgMjE0NzQ4MzYgICAgMSAtMTYgICAgMCAgMTMzMksgIDEw MDhLIHpvbmVsaSAgIDA6MDAgIDAuMDAlIG50dGNwDQogNjQxMyAyMTQ3NDgzNiAgICAxIC0xNiAg ICAwICAxMzMySyAgMTAwOEsgem9uZWxpICAgMDowMCAgMC4wMCUgbnR0Y3ANCiAxNTYyIDIxNDc0 ODM2ICAgIDEgLTE2ICAgIDAgIDEzMzJLICAxMDA4SyB6b25lbGkgICAwOjAwICAwLjAwJSBudHRj cA0K ------_=_NextPart_001_01C6FE7C.EFF3DA3D-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 14:25:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA1B16A494 for ; Thu, 2 Nov 2006 14:25:52 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05F2243D53 for ; Thu, 2 Nov 2006 14:25:51 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061102142550m9100ekn5ge>; Thu, 2 Nov 2006 14:25:50 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kA2EPm1W071399; Thu, 2 Nov 2006 08:25:48 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kA2EPhBX071398; Thu, 2 Nov 2006 08:25:43 -0600 (CST) (envelope-from brooks) Date: Thu, 2 Nov 2006 08:25:43 -0600 From: Brooks Davis To: "." Message-ID: <20061102142543.GC70915@lor.one-eyed-alien.net> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfjH4zxOES6UT95V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 14:25:52 -0000 --kfjH4zxOES6UT95V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > Hi, >=20 > I am confused by the use of inet_ntoa function in the kernel. >=20 > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static array > static char buf[4 * sizeof "123"]; > to store the result. And it returns the address of the array to the calle= r. >=20 > I think this inet_ntoa is not reentrant, though there are several functio= ns > calling it. If two functions call it simultaneously, the result will be > corrupted. Though I haven't really encountered this situation, it may occ= ur > someday, especially when using multi-processors. >=20 > There is another reentrant version of inet_ntoa called inet_ntoa_r in the > same file. It has been there for several years, but just used by ipfw2 for > about four times in 7-CURRENT. In my patch, I replaced all the calls to > inet_ntoa with calls to inet_ntoa_r. >=20 > By the way, some of the original calls is written in this style: > strcpy(buf, inet_ntoa(ip)) > The modified code is written in this style > inet_ntoa_r(ip, buf) > This change avoids a call to strcpy, and can save a little time. >=20 > Here is the patch. > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net >=20 > I've already sent to PR(kern/104738), but got no reply, maybe it should be > discussed here first? I've got to agree with other posters that the stack variable allocations are ugly. What about extending log and printf to understand ip4v addresses? That's 90% of the uses and the others appears to have buffers already. -- Brooks --kfjH4zxOES6UT95V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFSf/mXY6L6fI4GtQRAq3/AKCzT92xeif23vFSDc2k1b3ZpFdolACgx8n6 da2TOJtPJpXc2Q3N9Ih7Ju0= =GyRC -----END PGP SIGNATURE----- --kfjH4zxOES6UT95V-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 17:11:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDA9316A417; Thu, 2 Nov 2006 17:11:58 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F89143D66; Thu, 2 Nov 2006 17:11:47 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 4563F4A402; Thu, 2 Nov 2006 18:11:46 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id D6BD69E6C2; Thu, 2 Nov 2006 17:12:22 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id C176C405D; Thu, 2 Nov 2006 18:12:22 +0100 (CET) Date: Thu, 2 Nov 2006 18:12:22 +0100 From: 'Jeremie Le Hen' To: Raymond Wagner Message-ID: <20061102171222.GV20405@obiwan.tataz.chchile.org> References: <20061023094742.GA53114@obiwan.tataz.chchile.org> <200610311610.ALN52349@mirapoint.uc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610311610.ALN52349@mirapoint.uc.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org, 'Jeremie Le Hen' , Andrew Thompson Subject: Re: Virtual Network Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 17:11:58 -0000 Hi Raymond, On Tue, Oct 31, 2006 at 11:10:47AM -0500, Raymond Wagner wrote: > Your other method is that I keep NAT on the internal interface as normal, > and then create VLANs, bridged to the external interface, to each computer > with an external IP. Those machines would communicate as normal on the > internal network, but use the VLAN interface for external access. I've not > used VLANs before, so I don't know exactly how they work. I know the > wrapper causes some overhead, and my switch drops packets >1500 bytes. Do I > have to lower the MTU on the internal network, or just the VLANs and > external? Also, will my ISP know not to send the larger packets? 802.1q (namely VLAN) adds a 4-bytes header which means your network adapter must support a MTU of 1504 bytes. AFAIK, most of network cards do this. I haven't heard of problems like this so far. I've Cc'ed Andrew Thompson which has imported if_bridge(4) from OpenBSD into FreeBSD. He will likely be able to answer your question and tell whether it is possible to bridge two VLAN interfaces (attached to a physical interface) with another physical interface. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 17:28:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 879C816A62F for ; Thu, 2 Nov 2006 17:28:59 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF0C343D93 for ; Thu, 2 Nov 2006 17:28:52 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 8C2981CC26; Fri, 3 Nov 2006 06:28:51 +1300 (NZDT) Date: Fri, 3 Nov 2006 06:28:51 +1300 From: Andrew Thompson To: 'Jeremie Le Hen' Message-ID: <20061102172851.GA26723@heff.fud.org.nz> References: <20061023094742.GA53114@obiwan.tataz.chchile.org> <200610311610.ALN52349@mirapoint.uc.edu> <20061102171222.GV20405@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061102171222.GV20405@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 Cc: Raymond Wagner , freebsd-net@freebsd.org Subject: Re: Virtual Network Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 17:28:59 -0000 On Thu, Nov 02, 2006 at 06:12:22PM +0100, 'Jeremie Le Hen' wrote: > Hi Raymond, > > On Tue, Oct 31, 2006 at 11:10:47AM -0500, Raymond Wagner wrote: > > Your other method is that I keep NAT on the internal interface as normal, > > and then create VLANs, bridged to the external interface, to each computer > > with an external IP. Those machines would communicate as normal on the > > internal network, but use the VLAN interface for external access. I've not > > used VLANs before, so I don't know exactly how they work. I know the > > wrapper causes some overhead, and my switch drops packets >1500 bytes. Do I > > have to lower the MTU on the internal network, or just the VLANs and > > external? Also, will my ISP know not to send the larger packets? > > 802.1q (namely VLAN) adds a 4-bytes header which means your network > adapter must support a MTU of 1504 bytes. AFAIK, most of network > cards do this. I haven't heard of problems like this so far. > > I've Cc'ed Andrew Thompson which has imported if_bridge(4) from > OpenBSD into FreeBSD. He will likely be able to answer your question > and tell whether it is possible to bridge two VLAN interfaces > (attached to a physical interface) with another physical interface. That will work fine. The area where the bridge lacks is bridging vlan trunks but you do not appear to be doing that. Andrew From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 01:45:53 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8148E16A416 for ; Fri, 3 Nov 2006 01:45:53 +0000 (UTC) (envelope-from newroswell@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E915A43D4C for ; Fri, 3 Nov 2006 01:45:52 +0000 (GMT) (envelope-from newroswell@gmail.com) Received: by nf-out-0910.google.com with SMTP id p77so1194394nfc for ; Thu, 02 Nov 2006 17:45:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WWZixVhIMOohx07MD2+Gv0cEOeTD6ooR8SXCtFhssuqrs6uS25n6E6fDG3kRKK9uk9vu3boLF6V/6VMY4O/2MXWaaM+TY3L3+J6Mu0NRLtxvJqVlb0i1SnZAOM3dTbqLPlK3Dj+1cZ4Kw1MJHoSkFbyvPCGRoFB9xecQ00MQbFw= Received: by 10.78.128.11 with SMTP id a11mr1851604hud.1162518350781; Thu, 02 Nov 2006 17:45:50 -0800 (PST) Received: by 10.78.192.15 with HTTP; Thu, 2 Nov 2006 17:45:50 -0800 (PST) Message-ID: <375baf50611021745m6d097245y4670d5741ffbd64a@mail.gmail.com> Date: Thu, 2 Nov 2006 17:45:50 -0800 From: "Kevin Sanders" To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: pfil on bridge interface, looking for ether_header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 01:45:53 -0000 I've written a kernel module that has pfil_add_hook'ed into the pfil framework. When my input packet filter function is called, I can mtod(*m, struct IP *) to the IP header, but haven't found a way to find the original ethernet header. (*m)->m_pkthdr.header always seems to be NULL (I'm not even sure what it's used for but I gave it try). Any advice sure would be welcome, thanks in advance. Kevin From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 01:52:21 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3945F16A494 for ; Fri, 3 Nov 2006 01:52:21 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id D046C43D60 for ; Fri, 3 Nov 2006 01:52:17 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id E1C281CC29; Fri, 3 Nov 2006 14:52:15 +1300 (NZDT) Date: Fri, 3 Nov 2006 14:52:15 +1300 From: Andrew Thompson To: Kevin Sanders Message-ID: <20061103015215.GA31234@heff.fud.org.nz> References: <375baf50611021745m6d097245y4670d5741ffbd64a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <375baf50611021745m6d097245y4670d5741ffbd64a@mail.gmail.com> User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: pfil on bridge interface, looking for ether_header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 01:52:21 -0000 On Thu, Nov 02, 2006 at 05:45:50PM -0800, Kevin Sanders wrote: > I've written a kernel module that has pfil_add_hook'ed into the pfil > framework. When my input packet filter function is called, I can > mtod(*m, struct IP *) to the IP header, but haven't found a way to > find the original ethernet header. (*m)->m_pkthdr.header always seems > to be NULL (I'm not even sure what it's used for but I gave it try). > Any advice sure would be welcome, thanks in advance. If you look in if_bridge.c:bridge_pfil you will see that the ethernet header is stripped from the mbuf before passing to pfil. You may want to create another hook such as ether_pfil_hook and modify the bridge to use it. Alternatively see the recent discussion between Julian and Andre on the matter. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 09:31:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4384516A47B for ; Fri, 3 Nov 2006 09:31:18 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id D803C43D77 for ; Fri, 3 Nov 2006 09:31:15 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1361920nfe for ; Fri, 03 Nov 2006 01:31:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kO9/W0LIr54i9B4dueTcmdPom5lozyrtbAxarOBIduxoew6nD/GtGVlNm9HPh6vR0oagCrN6cyn01m4v7dasn5yabPJbi6U96aDdotRnlqdTdt03x+LWtHq9Z6AdkxifbQbsKsCOLX3s1P1oYJxDXelVM8MHXb9s5QgIbiXSK+U= Received: by 10.49.92.18 with SMTP id u18mr977509nfl.1162546273785; Fri, 03 Nov 2006 01:31:13 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 01:31:13 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 09:31:13 +0000 From: MQ To: "Max Laier" In-Reply-To: <200611021045.09774.max@love2party.net> MIME-Version: 1.0 References: <200611021045.09774.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 09:31:18 -0000 2006/11/2, Max Laier : > > On Thursday 02 November 2006 09:26, . wrote: > > Hi, > > > > I am confused by the use of inet_ntoa function in the kernel. > > > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > > array static char buf[4 * sizeof "123"]; > > to store the result. And it returns the address of the array to the > > caller. > > > > I think this inet_ntoa is not reentrant, though there are several > > functions calling it. If two functions call it simultaneously, the > > result will be corrupted. Though I haven't really encountered this > > situation, it may occur someday, especially when using > > multi-processors. > > > > There is another reentrant version of inet_ntoa called inet_ntoa_r in > > the same file. It has been there for several years, but just used by > > ipfw2 for about four times in 7-CURRENT. In my patch, I replaced all > > the calls to inet_ntoa with calls to inet_ntoa_r. > > > > By the way, some of the original calls is written in this style: > > strcpy(buf, inet_ntoa(ip)) > > The modified code is written in this style > > inet_ntoa_r(ip, buf) > > This change avoids a call to strcpy, and can save a little time. > > > > Here is the patch. > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-n > >et > > > > I've already sent to PR(kern/104738), but got no reply, maybe it should > > be discussed here first? > > In general, correct IPs in logs and debugging messages are a good thing. > I'm not sure, however, it is a good thing to put 17 bytes of buffer space > on every function stack that might want to print an IP address. I think > it's less intrusive and equally good to have a hand full of static > buffers available which are given out in a round-robin fashion - as > attempted in ip6_sprintf. Obviously the buffer rotation needs to be > atomic, though. If a caller needs the result for more than logging - or > cares strongly - it can still allocate a private buffer and use the _r > version. A general replacement of all applications of inet_ntoa just > seems bloat. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News Yes, not all the occurrence of inet_ntoa should be replaced. I've replaced several inet_ntoa in /sys/boot/ just to be consistent with other files. MAYBE they will never be corrupted by *simultaneous*ly calling inet_ntoa. But the calls in the network stack can really break the results. If that happens, the users will be confused by the strange outputs and/or logs. So I think adding 16 bytes of memory consumption on the stack is worthy. From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 09:46:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DA116A40F for ; Fri, 3 Nov 2006 09:46:50 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE22943D46 for ; Fri, 3 Nov 2006 09:46:48 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1367465nfe for ; Fri, 03 Nov 2006 01:46:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fppNh1ElLE6V2IAgil+gWFRi6zSY1+esiOqgvmlMco5SoU3asZiybGiV59NAJ9LlRrc9SGd7zovw5O6WhO5deaUZ27akfHQRkmDZW+2PVjFAlVSupwrFTkCHBHItuYdSibbK0/csquK8KlYh+7Gja+2q+nX+YFMItsEaFxdxbik= Received: by 10.49.49.4 with SMTP id b4mr976943nfk.1162547207511; Fri, 03 Nov 2006 01:46:47 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 01:46:47 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 09:46:47 +0000 From: MQ To: "Brooks Davis" In-Reply-To: <20061102142543.GC70915@lor.one-eyed-alien.net> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 09:46:50 -0000 2006/11/2, Brooks Davis : > > On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > > Hi, > > > > I am confused by the use of inet_ntoa function in the kernel. > > > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > array > > static char buf[4 * sizeof "123"]; > > to store the result. And it returns the address of the array to the > caller. > > > > I think this inet_ntoa is not reentrant, though there are several > functions > > calling it. If two functions call it simultaneously, the result will be > > corrupted. Though I haven't really encountered this situation, it may > occur > > someday, especially when using multi-processors. > > > > There is another reentrant version of inet_ntoa called inet_ntoa_r in > the > > same file. It has been there for several years, but just used by ipfw2 > for > > about four times in 7-CURRENT. In my patch, I replaced all the calls to > > inet_ntoa with calls to inet_ntoa_r. > > > > By the way, some of the original calls is written in this style: > > strcpy(buf, inet_ntoa(ip)) > > The modified code is written in this style > > inet_ntoa_r(ip, buf) > > This change avoids a call to strcpy, and can save a little time. > > > > Here is the patch. > > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > > > > I've already sent to PR(kern/104738), but got no reply, maybe it should > be > > discussed here first? > > I've got to agree with other posters that the stack variable allocations > are ugly. What about extending log and printf to understand ip4v > addresses? That's 90% of the uses and the others appears to have > buffers already. > > -- Brooks > > > Ugly? Why? Don't you use local variables in your sources? By the way, implementing a printf/log which understands ipv4 address is tedious, perhaps. From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 10:35:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7F9216A417 for ; Fri, 3 Nov 2006 10:35:30 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 004E943D46 for ; Fri, 3 Nov 2006 10:35:29 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1384478nfe for ; Fri, 03 Nov 2006 02:35:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tJqF8UZopgiOBOTf4y9bjuNQ+KOPXSMjUEEYo3QlJI2ztw7dZRw7JlAhb4rEnq3r9tgFu2TM1VRrlMktD0KpCnAeOi4iKhDZ8oVVMeXSEoFT2Hq0OQJKCPTU3PPUXQE22/Z2xjTYXPH/a3YoeBDstTmYQ2lIfM/XYquot8Gyt68= Received: by 10.49.8.10 with SMTP id l10mr1061387nfi.1162550128463; Fri, 03 Nov 2006 02:35:28 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 02:35:28 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 10:35:28 +0000 From: MQ To: "Max Laier" In-Reply-To: <200611021232.45858.max@love2party.net> MIME-Version: 1.0 References: <20061102102807.GA23553@zen.inc> <4549C93A.9080308@delphij.net> <200611021232.45858.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 10:35:30 -0000 2006/11/2, Max Laier : > > On Thursday 02 November 2006 11:32, LI Xin wrote: > > VANHULLEBUS Yvan wrote: > > > On Thu, Nov 02, 2006 at 06:19:43PM +0800, LI Xin wrote: > > > [.....] > > > > > >> Sounds like a workaround to me and in theory that is insufficient > > >> for a MPSAFE protection. Here is a patch which reduces the chance > > >> where we get a race. > > > > > > Hi. > > > > > > This patch will allow multiple calls to inet_ntoa int the same > > > function (like printf(....., inet_ntoa(a), inet_ntoa(b))), but won't > > > really solve the race condition if inet_ntoa is called from 2 > > > differents functions at the same time: at least the round should be > > > locked to reduce potential problems, and you're still not sure that > > > no more than 8 "simultaneous" (or at least close enough) calls will > > > be done. > > > > True. That's exactly what I concern about, it just reduced the chance > > we lose a race, not to eliminate it. > > > > Note that the code is similar with what was found in ip6_sprintf, so it > > got same issue I think. > > Just what I was trying to say in my initial, cut-off reply. The question > we have to answer is, how much do we care about logging / console printfs > of IP numbers. AFAIK, console printf isn't (?wasn't?) synchronized > properly, either. In the end the caller has to decide how much it cares > about the result. Security related logging facilities should certainly > use a private buffer (or better yet, do the conversion in userland). All > I'm argueing is, that we should be aware of the sideeffects (substantial > grow in stack size) of the suggested patch and weight it carefully > against the benefit (100% correctness in the unlikeliest of cases). I > think that we can live with a 8 slot ring buffer for most of the cases. > Fixing the race on the round counter seems essential, however. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > By the way, maybe printf should get better synchronized. When I was addressing some problems in the bge(4), the ill-synchronized printf made my console freezing before I restarted the machine. From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 11:13:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1966A16A416; Fri, 3 Nov 2006 11:13:17 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.91.193.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D50643D45; Fri, 3 Nov 2006 11:13:15 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DF1D22050C; Fri, 3 Nov 2006 16:43:24 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 03196220004; Fri, 3 Nov 2006 16:43:24 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 16:43:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Nov 2006 16:43:05 +0530 Message-ID: <821C7AD2A9F78942B86059792262577315B06A@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: TSO patch for current Thread-Index: AcbROYB1Rf1yJ1cwQEG3PZW6avyqWQt/xkAg From: To: , X-OriginalArrivalTime: 03 Nov 2006 11:13:13.0266 (UTC) FILETIME=[0D940120:01C6FF39] Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: RFC: TSO patch for current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 11:13:17 -0000 Hi, I have a patch that I got from the mailing list. But it does not contain the changes that adds tso_segsz to mbuffer header structure. Can any one please send me the latest patch for TSO that contains stack changes? Thanks, ~Siva -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel Sent: Wednesday, September 06, 2006 3:53 AM To: Andre Oppermann Cc: freebsd-net; freebsd-current Subject: Re: RFC: TSO patch for current On 9/5/06, Andre Oppermann wrote: > Jack Vogel wrote: > > On 9/5/06, Andre Oppermann wrote: > >> Prafulla Deuskar wrote: > >> > Your patch looks good and is the way to go. > >> > > >> > So after Jack confirms that your patch works with the em driver=0D > >> > would you commit to to -current? > >> > >> Absolutely. :-) > >> > >> > The driver related changes can follow.. > >> > > >> > Later we also need to fix ifconfig so that user can=0D > >> > enable/disable > >> TSO on the interface. > >> > >> I'll do that together with the TSO code. > > > > OK, I've built and done some touch testing of this. I like it, the=0D > > driver has some counters of the number of TSO bursts it does, and I=0D > > think I see more per netperf test with your patch than mine. > > > > Hard to do real performance testing with all that WITNESS stuff in,=0D > > but I will be making a 6.1 version of your patch to test with since=0D > > I have my driver running on that anyway. > > You can disable WITNESS and INVARIANTS pretty easily in -current and=0D > get the full performance with it. Last time I tried that I think the kernel wouldnt build, but that was like 6 months ago, so I just kicked off a build with this stuff off, and we'll see how it looks :) > > If you do the ifconfig changes there will need to be a small amount=0D > > of code added to em_ioctl() but it should be trivial. > > > > You want me to reissue a driver patch with changes for your code? > > Yes, please do so. I've got a dual-em card which I can test with myself. OK, attached new patch, this one even has the ioctl change so when you get the ifconfig change in it will be ready. Cheers, Jack The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 11:21:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32CF16A40F for ; Fri, 3 Nov 2006 11:21:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B22443D4C for ; Fri, 3 Nov 2006 11:21:01 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.55] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gfx6V1Unc-0007Yv; Fri, 03 Nov 2006 12:20:56 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 3 Nov 2006 12:20:47 +0100 User-Agent: KMail/1.9.4 References: <20061102142543.GC70915@lor.one-eyed-alien.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13722607.rEsWsyqbVX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611031220.53791.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: MQ Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 11:21:02 -0000 --nextPart13722607.rEsWsyqbVX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello "MQ", your email client is seriously mis-configured, could you please look into=20 this as it is a bit annoying. On Friday 03 November 2006 10:46, MQ wrote: > 2006/11/2, Brooks Davis : > > On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > > > Hi, > > > > > > I am confused by the use of inet_ntoa function in the kernel. > > > > > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a > > > static > > > > array > > > > > static char buf[4 * sizeof "123"]; > > > to store the result. And it returns the address of the array to the > > > > caller. > > > > > I think this inet_ntoa is not reentrant, though there are several > > > > functions > > > > > calling it. If two functions call it simultaneously, the result > > > will be corrupted. Though I haven't really encountered this > > > situation, it may > > > > occur > > > > > someday, especially when using multi-processors. > > > > > > There is another reentrant version of inet_ntoa called inet_ntoa_r > > > in > > > > the > > > > > same file. It has been there for several years, but just used by > > > ipfw2 > > > > for > > > > > about four times in 7-CURRENT. In my patch, I replaced all the > > > calls to inet_ntoa with calls to inet_ntoa_r. > > > > > > By the way, some of the original calls is written in this style: > > > strcpy(buf, inet_ntoa(ip)) > > > The modified code is written in this style > > > inet_ntoa_r(ip, buf) > > > This change avoids a call to strcpy, and can save a little time. > > > > > > Here is the patch. > > > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah > >-net > > > > > I've already sent to PR(kern/104738), but got no reply, maybe it > > > should > > > > be > > > > > discussed here first? > > > > I've got to agree with other posters that the stack variable > > allocations are ugly. What about extending log and printf to > > understand ip4v addresses? That's 90% of the uses and the others > > appears to have buffers already. > > > > -- Brooks > > > > Ugly? Why? Don't you use local variables in your sources? You have to understand, that stack space is a limited resource in the=20 kernel. Some of the functions are leaf nodes in quite long call paths,=20 which means adding those buffers can hit quite hard. I guess what Brooks and I are trying to say is, that this needs to be=20 considered carefully. A simple search and replace won't do. BTW, I took the PR for now and will look into it. I don't think it's=20 something we need to rush, as I haven't seen any reports or indication of=20 real problems yet - fwiw we don't spew a lot of IP addresses to console=20 or log in normal operation. > By the way, implementing a printf/log which understands ipv4 address is > tedious, perhaps. Actually, it's a ~15 line patch, I will see if I can get to it later=20 today. If we reuse the number buffer we can even get away without=20 increase in stack space usage. Whether or not this is a good idea is on=20 another page, but %I and %lI (for IPv6) would be available and we already=20 have %D and %b as special cases in the kernel. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart13722607.rEsWsyqbVX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSyYVXyyEoT62BG0RAiK5AJ0ePyHawzNTWzi9ICYwfEi5+ljVQwCfcViP I5x2oUBUWdAeJIgoDioVXRw= =ic6M -----END PGP SIGNATURE----- --nextPart13722607.rEsWsyqbVX-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 12:02:19 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96AFB16A40F for ; Fri, 3 Nov 2006 12:02:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3C543D9E for ; Fri, 3 Nov 2006 12:02:08 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (fybura@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kA3C21vR078494; Fri, 3 Nov 2006 13:02:06 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kA3C20nl078493; Fri, 3 Nov 2006 13:02:00 +0100 (CET) (envelope-from olli) Date: Fri, 3 Nov 2006 13:02:00 +0100 (CET) Message-Id: <200611031202.kA3C20nl078493@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG, aburke@nullplusone.net In-Reply-To: X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 03 Nov 2006 13:02:07 +0100 (CET) Cc: Subject: Re: VLAN switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG, aburke@nullplusone.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 12:02:19 -0000 Aaron Burke wrote: > If your ok with 100/Full, I recomend the Intel510T for Layer 2 managed > switching. If you need Layer3 switching, the Intel520T should work. I think you'll need a 550 for layer3 ("routing switch"). The 510 and 520 are both layer2 (i.e. normal switches). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 14:08:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D476216A494 for ; Fri, 3 Nov 2006 14:08:23 +0000 (UTC) (envelope-from colin@spakka.net) Received: from scratchy.xcalibre.co.uk (scratchy.xcalibre.co.uk [195.173.23.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3718443D58 for ; Fri, 3 Nov 2006 14:08:22 +0000 (GMT) (envelope-from colin@spakka.net) Envelope-to: freebsd-net@freebsd.org Received: from loki.xcalibre.co.uk ([195.173.23.48]) by scratchy.xcalibre.co.uk with esmtpa (Exim 4.43) id 1GfziX-0005h1-Fy for freebsd-net@freebsd.org; Fri, 03 Nov 2006 14:08:21 +0000 Message-ID: <454B4D55.6060603@spakka.net> Date: Fri, 03 Nov 2006 14:08:21 +0000 From: Colin Petrie User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Authenticated-User: cpetrie Subject: Redundant gateway with OSPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 14:08:23 -0000 Hi all, Can anyone give me some advice on an issue I'm having? I have 2 FreeBSD 6.1-RELEASE routers connected to an OSPF area, and want them to provide a redundant gateway to a subnet. Here is a badly drawn diagram: /-----------------\ | OSPF area | \-----------------/ | | /----\ /----\ | r1 | | r2 | \----/ \----/ | | /---------------\ | switch | \---------------/ | | | | hosts I am investigating various techniques for providing a redundant gateway for the hosts on the switch. Initially I started looking at FreeVRRPd from the ports collection, but came across an issue. Assuming I wanted the 2 routers to be 192.168.1.253/24 and 192.168.1.254/24, and want to provide 192.168.1.1/24 as the network default gateway. However because the routers can see each other via OSPF and are redistributing connected interfaces, when I add 192.168.1.253/24 to r1, i then cannot add 192.168.1.254/24 to r2 because r2 now has a route to 192.168.1.0/24 installed in its routing table, with a gateway of r1. What I want is for both routers to be on the /24 with different IPs, and for only the one which VRRP has decided has the gateway address to be advertising the route to the rest of the network. I would also be interested in getting rid of the requirement for both routers to use IPs on the subnet, ideally only the one which is currently the gateway should be using any IPs at all, but the only way i can see of doing this is with the carpdev functionality in OpenBSD. I don't think I can tell OSPF not to distribute the /24 because I do want it distributed, but only by the router which is currently the master. Would this need to be done using the 'masterscript' and 'backupscript' options in freevrrpd? For info, i am using quagga 0.99.5 for the ospf stuff. Can anyone suggest a way of doing this? I've looked at freevrrpd and carp so far but if there's something that can avoid installing a route into the kernel for the /24 until the router in question is actually the master in the pair, i would appreciate being pointed in the right direction. Hoping someone can point me in the right direction :) Cheers, Colin P From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 14:18:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C997B16A407 for ; Fri, 3 Nov 2006 14:18:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90A5143D67 for ; Fri, 3 Nov 2006 14:17:47 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20061103141746m9200kmi9ie>; Fri, 3 Nov 2006 14:17:46 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kA3EHXfo087661; Fri, 3 Nov 2006 08:17:34 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kA3EHWYH087660; Fri, 3 Nov 2006 08:17:32 -0600 (CST) (envelope-from brooks) Date: Fri, 3 Nov 2006 08:17:32 -0600 From: Brooks Davis To: MQ Message-ID: <20061103141732.GA87515@lor.one-eyed-alien.net> References: <20061102142543.GC70915@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 14:18:03 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 03, 2006 at 09:46:47AM +0000, MQ wrote: > 2006/11/2, Brooks Davis : > > > >On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > >> Hi, > >> > >> I am confused by the use of inet_ntoa function in the kernel. > >> > >> The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > >array > >> static char buf[4 * sizeof "123"]; > >> to store the result. And it returns the address of the array to the > >caller. > >> > >> I think this inet_ntoa is not reentrant, though there are several > >functions > >> calling it. If two functions call it simultaneously, the result will be > >> corrupted. Though I haven't really encountered this situation, it may > >occur > >> someday, especially when using multi-processors. > >> > >> There is another reentrant version of inet_ntoa called inet_ntoa_r in > >the > >> same file. It has been there for several years, but just used by ipfw2 > >for > >> about four times in 7-CURRENT. In my patch, I replaced all the calls to > >> inet_ntoa with calls to inet_ntoa_r. > >> > >> By the way, some of the original calls is written in this style: > >> strcpy(buf, inet_ntoa(ip)) > >> The modified code is written in this style > >> inet_ntoa_r(ip, buf) > >> This change avoids a call to strcpy, and can save a little time. > >> > >> Here is the patch. > >> > >http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > >> > >> I've already sent to PR(kern/104738), but got no reply, maybe it should > >be > >> discussed here first? > > > >I've got to agree with other posters that the stack variable allocations > >are ugly. What about extending log and printf to understand ip4v > >addresses? That's 90% of the uses and the others appears to have > >buffers already. > > > >-- Brooks > > > > > >Ugly? Why? Don't you use local variables in your sources? The particular definition used is excedingly ugly. At a minimum there needs to be a define or a constant "16" for the lenght rather than the 4*sizeof("123") nonsense. -- Brooks --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFS097XY6L6fI4GtQRAoOPAKDLTwMk9dwS7nfGbcRPXpcCRn8RSQCggTqp qV/yvysM1DeTsM2fHlCp3Vk= =Wwt0 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 16:33:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6DFA16A416 for ; Fri, 3 Nov 2006 16:33:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5BFE43D4C for ; Fri, 3 Nov 2006 16:33:07 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id z59so328117pyg for ; Fri, 03 Nov 2006 08:33:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j7Wq3cVUv1IPRspbNQQWK3cq+w3pBg6/EVFcNV0UCMrak97O03ofBZCazdsLbi4qSep6mR6qeF04x8sYlSNpzpOc3qrujEo8L7tMZBp89WjeE8f27NGdNHJOyQ8wiWAmU/N/cCX2xPLv7eA7GGo4WTWE6peSdpr5e6G8fo4MpmE= Received: by 10.35.77.1 with SMTP id e1mr3605868pyl.1162571585340; Fri, 03 Nov 2006 08:33:05 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 3 Nov 2006 08:33:04 -0800 (PST) Message-ID: <2a41acea0611030833m57f3443eq89a6527f66545389@mail.gmail.com> Date: Fri, 3 Nov 2006 08:33:05 -0800 From: "Jack Vogel" To: "sivakumar.subramani@wipro.com" In-Reply-To: <821C7AD2A9F78942B86059792262577315B06A@blr-m3-msg.wipro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <821C7AD2A9F78942B86059792262577315B06A@blr-m3-msg.wipro.com> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: RFC: TSO patch for current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 16:33:09 -0000 On 11/3/06, sivakumar.subramani@wipro.com wrote: > Hi, > > I have a patch that I got from the mailing list. But it does not contain > the changes that adds tso_segsz to mbuffer header structure. > > Can any one please send me the latest patch for TSO that contains stack > changes? > > Thanks, > ~Siva > You mean I assume a patch for STABLE because the changes are integrated into CURRENT :) The em driver that now is in 6.2 BETA 3 DOES have TSO support in it BTW, its just #ifdef EM_TSO which isnt defined. For right now the only way to get the kernel patch you need is to pull it out of the official Intel tarball. I just looked and the Intel website now DOES have my 6.2.9 driver available to download. Go to: downloadfinder.intel.com On the left select network connectivity, then server adapters, then pick one (I dont know that it matters which). You will get a pulldown menu, select FreeBSD and the next screen should have the new driver at the top. When you untar the thing there is a patches directory, and in that is a TSO patch, I have not applied it against BETA3 but it should apply. You will then need to compile the em driver with that defined. I expect this will be MFC'd before 6.3. Good luck, Jack From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 18:52:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1FE716A4FA for ; Fri, 3 Nov 2006 18:52:16 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (nebula.thdo.uk.alastria.net [212.13.198.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2796243D5C for ; Fri, 3 Nov 2006 18:52:14 +0000 (GMT) (envelope-from peter@alastria.net) Received: from neon.alastria.lan (88-96-139-33.dsl.zen.co.uk [88.96.139.33]) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id kA3IqHrV084760 for ; Fri, 3 Nov 2006 18:52:17 GMT (envelope-from peter@alastria.net) Received: from 10.10.4.10 (SquirrelMail authenticated user peter) by neon.alastria.lan with HTTP; Fri, 3 Nov 2006 18:52:11 -0000 (GMT) Message-ID: <2864.10.10.4.10.1162579931.squirrel@neon.alastria.lan> Date: Fri, 3 Nov 2006 18:52:11 -0000 (GMT) From: peter@alastria.net To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.228 () FORGED_RCVD_HELO,NO_REAL_NAME X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: IPSEC, isakmpd, tunnel/transport encapsulation... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 18:52:17 -0000 Good Evening, I apologise for what may end up being a stupid question, I'm getting towards my wits end. I've got a FreeBSD 6.2-PRERELEASE (cvsup of about 1300 GMT today) gateway which I'm attempting to run IPSEC/L2TP for wireless security. My client computers are Windows XP and Mac OS X, and the issue happens with both. No client has a fixed IP, so I want to permit any IP to establish a IPSEC session providing they know the preshared key. I'm using isakmpd for setup of the IPSEC side of things and hopefully SL2TPS for the L2TP side, although I'm not there yet. My issue is that none of my client can establish a L2TP session for what looks to be a mismatch of encapsulation types. For example, the first packet bellow is from my laptop to the gateway, the second is the reply. 18:18:56.540995 (authentic,confidential): SPI 0x1b79c065: IP 10.10.3.254.1701 > 10.10.2.1.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() FIRM_VER(1280) |... 18:18:56.541039 (authentic,confidential): SPI 0x136223d4: IP 10.10.2.1 > 10.10.3.254: IP 10.10.2.1.1701 > 10.10.3.254.1701: l2tp:[TLS](20/0) Ns=1,Nr=1 ZLB (ipip-proto-4) This seems to be causing issues as the remote host isn't expecting the IPIP encapsulation there. I don't believe it has anything to do with SL2TPS because if I try and ICMP Ping 10.10.3.254 from 10.10.2.1, the ICMP request is IPSEC'd with the IPIP encapsulation. Has anyone seen this before? I'm using a fairly simplistic isakmpd.conf (which may be my issue)... [General] Listen-on = 10.10.2.1 [Phase 1] Default = local-peers [Phase 2] Passive-connections = authenticated-peers [local-peers] Phase = 1 Local-address = 10.10.2.1 Authentication = mypresharedkey Configuration = isakmp-main-mode [authenticated-peers] Phase = 2 ISAKMP-peer = local-peers Local-ID = local-network Remote-ID = remote-network #Configuration = ipsec-quick-mode [local-network] ID-type = IPV4_ADDR_SUBNET Network = 0.0.0.0 Netmask = 0.0.0.0 [remote-network] ID-type = IPV4_ADDR_SUBNET Network = 10.10.2.0 Netmask = 255.255.254.0 [isakmp-main-mode] EXCHANGE_TYPE = ID_PROT Transforms= 3DES-SHA [ipsec-quick-mode] EXCHANGE_TYPE = QUICK_MODE I have a isakmpd.policy of... KeyNote-Version: 2 Authorizer: "POLICY" Conditions: app_domain == "IPsec policy" && esp_present == "yes" -> "true"; I have tried specifying Tranforms/Suites on ipsec-quick-mode that should use transport encapsulation, I've even tried tunnel encapsulation to see if it'll solve it. I've added esp_encapsulation == "transport" to the policy file, and that hasn't helped either. Does anyone have a clue what I'm doing wrong? I sadly know very little about IPSEC, although I've learnt a lot today. If anyone had any sample configs of doing this kind of thing, that would be great. Google is some what lacking in info on this one. Many thanks for any help or suggestions! Cheers, Peter. From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 21:00:38 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4860516A503 for ; Fri, 3 Nov 2006 21:00:38 +0000 (UTC) (envelope-from newroswell@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 379AE43D8C for ; Fri, 3 Nov 2006 21:00:27 +0000 (GMT) (envelope-from newroswell@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so469344uge for ; Fri, 03 Nov 2006 13:00:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FK5SHSm80Ccb5mmP7ED3oEX2TLm+gpsMPNDU7ryhzTl62VAerD4l6GbBwbPsteTDLCo+FUR0QxuDmFIWJUhYDc8/uJVPKLWgj9vdlbFAQXAC+UFeul0CL5+ESQqb9kWVcwj97q9LPrXdbxkVEX3sd1yb0mmoClWDnqze94BxKYA= Received: by 10.78.17.1 with SMTP id 1mr119205huq.1162587625268; Fri, 03 Nov 2006 13:00:25 -0800 (PST) Received: by 10.78.192.15 with HTTP; Fri, 3 Nov 2006 13:00:20 -0800 (PST) Message-ID: <375baf50611031300n6a8088cbx49f121dfe1e6a644@mail.gmail.com> Date: Fri, 3 Nov 2006 13:00:20 -0800 From: "Kevin Sanders" To: "Andrew Thompson" In-Reply-To: <20061103015215.GA31234@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <375baf50611021745m6d097245y4670d5741ffbd64a@mail.gmail.com> <20061103015215.GA31234@heff.fud.org.nz> Cc: net@freebsd.org Subject: Re: pfil on bridge interface, looking for ether_header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 21:00:38 -0000 On 11/2/06, Andrew Thompson wrote: > On Thu, Nov 02, 2006 at 05:45:50PM -0800, Kevin Sanders wrote: > > I've written a kernel module that has pfil_add_hook'ed into the pfil > > framework. When my input packet filter function is called, I can > > mtod(*m, struct IP *) to the IP header, but haven't found a way to > > find the original ethernet header. > > If you look in if_bridge.c:bridge_pfil you will see that the ethernet > header is stripped from the mbuf before passing to pfil. You may want to > create another hook such as ether_pfil_hook and modify the bridge to use > it. Alternatively see the recent discussion between Julian and Andre on > the matter. I've got a simple fix for this that solves my immediate need (to be able to reach the ethernet header). I grepped around, and don't see much use of the m_pkthdr.header value anymore, and this doesn't appear to break anything yet. *** if_bridge.c 21 Oct 2006 12:10:39 -0700 1.11.2.40 --- if_bridge.c 03 Nov 2006 11:46:15 -0800 *************** *** 2781,2786 **** --- 2781,2787 ---- ipfwpass: error = 0; + (*mp)->m_pkthdr.header = &eh2; /* * Run the packet through pfil *************** *** 2902,2907 **** --- 2903,2909 ---- if (*mp == NULL) return (error); bcopy(&eh2, mtod(*mp, caddr_t), ETHER_HDR_LEN); + (*mp)->m_pkthdr.header = NULL; return (0); From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 01:15:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0502016A503 for ; Sat, 4 Nov 2006 01:15:43 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from nora.synergetica.dn.ua (synergetica.dn.ua [82.207.115.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 466A543D5F for ; Sat, 4 Nov 2006 01:15:32 +0000 (GMT) (envelope-from c.kworr@gmail.com) Received: from [172.30.0.159] (yarn.lan [172.30.0.159]) (authenticated bits=0) by nora.synergetica.dn.ua (8.13.8/8.13.8) with ESMTP id kA41FQsu067238; Sat, 4 Nov 2006 03:15:27 +0200 (EET) (envelope-from c.kworr@gmail.com) Message-ID: <454BE9AE.4020008@gmail.com> Date: Sat, 04 Nov 2006 03:15:26 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.0.7) Gecko/20061019 SeaMonkey/1.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: mpd4 on sparc64 problem (maybe netgraph involved) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 01:15:43 -0000 0k, I've finally get my hands to this stuff... I have a host machine (i386) with many i386 clients and one sparc64 all configured the same way. All i386 client work just fine, while sparc64 one refuses to do so. This is a config sample: out0: new -n -i ng0 SG PPPoE set auth authname negative1 set bundle no multilink compression set bundle yes encryption set ecp enable des set iface addrs 1.1.1.1 2.2.2.2 set iface disable on-demand proxy-arp tcpmssfix set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set link no pap chap set link accept chap-md5 set link yes acfcomp protocomp open This config works just fine on i386, but fails on sparc. The problem seems to be in echo/reply handling. On sparc64 echo/reply looks this way: 21:49:14.140583 PPPoE [ses 0x230] LCP, Echo-Request (0x09), id 139, length 10 encoded length 8 (=Option(s) length 4) Magic-Num 0xa00fbb83 21:49:14.141577 PPPoE [ses 0x230] LCP, Echo-Reply (0x0a), id 139, length 10 encoded length 8 (=Option(s) length 4) Magic-Num 0xf09f2427 And on i386 like this: 21:49:13.441359 PPPoE [ses 0x218] LCP, Echo-Request (0x09), id 174, length 10 encoded length 8 (=Option(s) length 4) Magic-Num 0x98036415 21:49:13.443434 PPPoE [ses 0x218] LCP, Echo-Reply (0x0a), id 174, length 10 encoded length 8 (=Option(s) length 4) Magic-Num 0x357f56e9 The i386 version is just fine, while sparc64 one results in following logs on the host machine: Nov 3 21:49:14 nora mpd: [pppoe5] LCP: magic number is wrong: 0xf09f2427 != 0x00000000 Nov 3 21:49:14 nora mpd: [pppoe5] LCP: received an invalid magic number Nov 3 21:49:14 nora mpd: [pppoe5] LCP: LayerFinish Nov 3 21:49:14 nora mpd: [pppoe5] LCP: LayerStart Nov 3 21:49:14 nora mpd: [pppoe5] LCP: state change Opened --> Starting Nov 3 21:49:14 nora mpd: [pppoe5] LCP: phase shift NETWORK --> DEAD Nov 3 21:49:14 nora mpd: [pppoe5] RADIUS: RadiusAccount for: negative1 Nov 3 21:49:14 nora mpd: [pppoe5] RADIUS: using /usr/local/etc/raddb/radius.conf Nov 3 21:49:14 nora mpd: [pppoe5] RADIUS: RadiusAddServer Adding 127.0.0.1 Nov 3 21:49:14 nora mpd: [pppoe5] RADIUS: Termination cause: Protocol error:PPP layer LCP failed: received an invalid magic number, RADIUS: 15 Mercy! I'm down... PS: host# uname -a FreeBSD nora.synergetica.dn.ua 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #6: Tue Oct 31 15:39:50 EET 2006 arcade@nora.synergetica.dn.ua:/usr/obj/mnt/storage/usr/src/sys/NORA i386 client_sparc64# uname -a FreeBSD blade.lan 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #5: Tue Oct 31 13:43:16 UTC 2006 arcade@blade.lan:/usr/obj/.amd_mnt/nora/host/mnt/storage/usr/src/sys/BLADE sparc64 MPD4 beta 5 -- Sphinx of black quartz judge my vow! From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 02:23:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED1B416A412 for ; Sat, 4 Nov 2006 02:23:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5148643D46 for ; Sat, 4 Nov 2006 02:23:13 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id z59so409779pyg for ; Fri, 03 Nov 2006 18:22:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GyQAFgqYnGgcMgq/Y5N0sSWM+wTrORBK0fCD2tom2xuguYSjDvmBcwPeAKwlYJwI1M1KK7Lk9lkVYws4/1BjIj+hw0VqhY0HNRhmrUKVRTdF8DyoP8yVmitbyYUcQbs/ZNft2l9SOgJeRGDX2IGHFZo5pGWlju2Q6Q8BjFjVDjM= Received: by 10.35.46.11 with SMTP id y11mr4639882pyj.1162606593651; Fri, 03 Nov 2006 18:16:33 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 3 Nov 2006 18:16:33 -0800 (PST) Message-ID: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Date: Fri, 3 Nov 2006 18:16:33 -0800 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_43447_15205892.1162606593613" Cc: Subject: New em patch for 6.2 BETA 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 02:23:14 -0000 ------=_Part_43447_15205892.1162606593613 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have been hard at work trying to understand and fix the remaining issues with the em driver. What I have here is a patch that has gotten rid of any issues that I can reproduce. It solves the intermittent watchdogs that have been happening. It also fixes the problem noted with jumbo frame tx I, and re, would very much appreciate any test feedback you can give on this code. I am happy with the changes, I hope these get rid of everyone's issues. Thanks to Gleb and Scott and John for all the help! Jack ------=_Part_43447_15205892.1162606593613 Content-Type: text/x-patch; name=em-stable.patch; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_eu3t3js5 Content-Disposition: attachment; filename="em-stable.patch" ZGlmZiAtTmF1ciBzdGFibGUvZGV2L2VtL2lmX2VtLmMgamZ2L2Rldi9lbS9pZl9lbS5jCi0tLSBz dGFibGUvZGV2L2VtL2lmX2VtLmMJRnJpIE5vdiAgMyAwMjowMjoyOSAyMDA2CisrKyBqZnYvZGV2 L2VtL2lmX2VtLmMJU2F0IE5vdiAgNCAwOToxODo0OCAyMDA2CkBAIC0yMDQsNyArMjA0LDcgQEAK IHN0YXRpYyB2b2lkCWVtX3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsKIHN0YXRpYyB2b2lkCWVtX3N0 YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCk7CiBzdGF0aWMgaW50CWVtX2lvY3RsKHN0cnVj dCBpZm5ldCAqLCB1X2xvbmcsIGNhZGRyX3QpOwotc3RhdGljIHZvaWQJZW1fd2F0Y2hkb2coc3Ry dWN0IGlmbmV0ICopOworc3RhdGljIHZvaWQJZW1fd2F0Y2hkb2codm9pZCAqKTsKIHN0YXRpYyB2 b2lkCWVtX2luaXQodm9pZCAqKTsKIHN0YXRpYyB2b2lkCWVtX2luaXRfbG9ja2VkKHN0cnVjdCBh ZGFwdGVyICopOwogc3RhdGljIHZvaWQJZW1fc3RvcCh2b2lkICopOwpAQCAtMjUzLDggKzI1Myw3 IEBACiBzdGF0aWMgaW50CWVtXzgyNTQ3X2ZpZm9fd29ya2Fyb3VuZChzdHJ1Y3QgYWRhcHRlciAq LCBpbnQpOwogc3RhdGljIHZvaWQJZW1fODI1NDdfdXBkYXRlX2ZpZm9faGVhZChzdHJ1Y3QgYWRh cHRlciAqLCBpbnQpOwogc3RhdGljIGludAllbV84MjU0N190eF9maWZvX3Jlc2V0KHN0cnVjdCBh ZGFwdGVyICopOwotc3RhdGljIHZvaWQJZW1fODI1NDdfbW92ZV90YWlsKHZvaWQgKmFyZyk7Ci1z dGF0aWMgdm9pZAllbV84MjU0N19tb3ZlX3RhaWxfbG9ja2VkKHN0cnVjdCBhZGFwdGVyICopOwor c3RhdGljIHZvaWQJZW1fODI1NDdfbW92ZV90YWlsKHZvaWQgKik7CiBzdGF0aWMgaW50CWVtX2Rt YV9tYWxsb2Moc3RydWN0IGFkYXB0ZXIgKiwgYnVzX3NpemVfdCwKIAkJc3RydWN0IGVtX2RtYV9h bGxvYyAqLCBpbnQpOwogc3RhdGljIHZvaWQJZW1fZG1hX2ZyZWUoc3RydWN0IGFkYXB0ZXIgKiwg c3RydWN0IGVtX2RtYV9hbGxvYyAqKTsKQEAgLTQwNiw4ICs0MDUsOSBAQAogCSAgICBPSURfQVVU TywgInN0YXRzIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywgYWRhcHRlciwgMCwKIAkgICAgZW1f c3lzY3RsX3N0YXRzLCAiSSIsICJTdGF0aXN0aWNzIik7CiAKLQljYWxsb3V0X2luaXQoJmFkYXB0 ZXItPnRpbWVyLCBDQUxMT1VUX01QU0FGRSk7Ci0JY2FsbG91dF9pbml0KCZhZGFwdGVyLT50eF9m aWZvX3RpbWVyLCBDQUxMT1VUX01QU0FGRSk7CisJY2FsbG91dF9pbml0X210eCgmYWRhcHRlci0+ dGltZXIsICZhZGFwdGVyLT5tdHgsIDApOworCWNhbGxvdXRfaW5pdF9tdHgoJmFkYXB0ZXItPndh dGNoZG9nLCAmYWRhcHRlci0+bXR4LCAwKTsKKwljYWxsb3V0X2luaXRfbXR4KCZhZGFwdGVyLT50 eF9maWZvX3RpbWVyLCAmYWRhcHRlci0+bXR4LCAwKTsKIAogCS8qIERldGVybWluZSBoYXJkd2Fy ZSByZXZpc2lvbiAqLwogCWVtX2lkZW50aWZ5X2hhcmR3YXJlKGFkYXB0ZXIpOwpAQCAtNjIyLDYg KzYyMiw5IEBACiAJRU1fVU5MT0NLKGFkYXB0ZXIpOwogCWV0aGVyX2lmZGV0YWNoKGFkYXB0ZXIt PmlmcCk7CiAKKwljYWxsb3V0X2RyYWluKCZhZGFwdGVyLT50aW1lcik7CisJY2FsbG91dF9kcmFp bigmYWRhcHRlci0+dHhfZmlmb190aW1lcik7CisKIAllbV9mcmVlX3BjaV9yZXNvdXJjZXMoYWRh cHRlcik7CiAJYnVzX2dlbmVyaWNfZGV0YWNoKGRldik7CiAJaWZfZnJlZShpZnApOwpAQCAtNzM5 LDcgKzc0Miw3IEBACiAJCUJQRl9NVEFQKGlmcCwgbV9oZWFkKTsKIAogCQkvKiBTZXQgdGltZW91 dCBpbiBjYXNlIGhhcmR3YXJlIGhhcyBwcm9ibGVtcyB0cmFuc21pdHRpbmcuICovCi0JCWlmcC0+ aWZfdGltZXIgPSBFTV9UWF9USU1FT1VUOworCQljYWxsb3V0X3Jlc2V0KCZhZGFwdGVyLT53YXRj aGRvZywgNSAqIGh6LCBlbV93YXRjaGRvZywgYWRhcHRlcik7CiAJfQogfQogCkBAIC05NDcsMTcg Kzk1MCwyOCBAQAogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiovCiAKIHN0YXRpYyB2b2lkCi1lbV93YXRjaGRvZyhz dHJ1Y3QgaWZuZXQgKmlmcCkKK2VtX3dhdGNoZG9nKHZvaWQgKmFyZykKIHsKLQlzdHJ1Y3QgYWRh cHRlciAqYWRhcHRlciA9IGlmcC0+aWZfc29mdGM7CisJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIg PSBhcmc7CisJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5pZnA7CisKKwkvKgorCSoqIElm IHdlIGFyZSBhYm92ZSB0aGUgY2xlYW4gdGhyZXNob2xkIGRpc2FybSBjYWxsYmFjaworCSoqIGVs c2UgcmVhcm0gZm9yIDUgc2Vjcy4KKwkqLworCWlmIChhZGFwdGVyLT5udW1fdHhfZGVzY19hdmFp bCA+IEVNX1RYX0NMRUFOVVBfVEhSRVNIT0xEKSB7CisJCWNhbGxvdXRfc3RvcCgmYWRhcHRlci0+ d2F0Y2hkb2cpOworCQlyZXR1cm47CisJfSBlbHNlIGlmIChhZGFwdGVyLT5udW1fdHhfZGVzY19h dmFpbCA+IEVNX1RYX09QX1RIUkVTSE9MRCkgeworCQljYWxsb3V0X3Jlc2V0KCZhZGFwdGVyLT53 YXRjaGRvZywgNSAqIGh6LCBlbV93YXRjaGRvZywgYWRhcHRlcik7CisJCXJldHVybjsKKwl9CiAK LQlFTV9MT0NLKGFkYXB0ZXIpOwogCS8qIElmIHdlIGFyZSBpbiB0aGlzIHJvdXRpbmUgYmVjYXVz ZSBvZiBwYXVzZSBmcmFtZXMsIHRoZW4KIAkgKiBkb24ndCByZXNldCB0aGUgaGFyZHdhcmUuCiAJ ICovCiAJaWYgKEUxMDAwX1JFQURfUkVHKCZhZGFwdGVyLT5odywgU1RBVFVTKSAmIEUxMDAwX1NU QVRVU19UWE9GRikgewotCQlpZnAtPmlmX3RpbWVyID0gRU1fVFhfVElNRU9VVDsKLQkJRU1fVU5M T0NLKGFkYXB0ZXIpOworCQljYWxsb3V0X3N0b3AoJmFkYXB0ZXItPndhdGNoZG9nKTsKIAkJcmV0 dXJuOwogCX0KIApAQCAtOTY4LDcgKzk4Miw2IEBACiAJYWRhcHRlci0+d2F0Y2hkb2dfZXZlbnRz Kys7CiAKIAllbV9pbml0X2xvY2tlZChhZGFwdGVyKTsKLQlFTV9VTkxPQ0soYWRhcHRlcik7CiB9 CiAKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKQEAgLTExNTQsNiArMTE2Nyw4IEBACiAgKiAgSW50ZXJydXB0IFNl cnZpY2Ugcm91dGluZSAgCiAgKgogICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKyNkZWZpbmUgRU1fTUFYX0lOVFIg MTAKKwogc3RhdGljIHZvaWQKIGVtX2ludHIodm9pZCAqYXJnKQogewpAQCAtMTE2Miw3ICsxMTc3 LDYgQEAKIAl1aW50MzJfdAlyZWdfaWNyOwogCiAJRU1fTE9DSyhhZGFwdGVyKTsKLQogCWlmcCA9 IGFkYXB0ZXItPmlmcDsKIAogI2lmZGVmIERFVklDRV9QT0xMSU5HCkBAIC0xMTcyLDI4ICsxMTg2 LDI0IEBACiAJfQogI2VuZGlmIC8qIERFVklDRV9QT0xMSU5HICovCiAKLQlmb3IgKDs7KSB7Ci0J CXJlZ19pY3IgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIElDUik7Ci0JCWlmIChhZGFw dGVyLT5ody5tYWNfdHlwZSA+PSBlbV84MjU3MSAmJgotCQkgICAgKHJlZ19pY3IgJiBFMTAwMF9J Q1JfSU5UX0FTU0VSVEVEKSA9PSAwKQotCQkJYnJlYWs7Ci0JCWVsc2UgaWYgKHJlZ19pY3IgPT0g MCkKLQkJCWJyZWFrOworCXJlZ19pY3IgPSBFMTAwMF9SRUFEX1JFRygmYWRhcHRlci0+aHcsIElD Uik7CiAKLQkJLyoKLQkJICogWFhYOiBzb21lIGxhcHRvcHMgdHJpZ2dlciBzZXZlcmFsIHNwdXJp b3VzIGludGVycnVwdHMKLQkJICogb24gZW0oNCkgd2hlbiBpbiB0aGUgcmVzdW1lIGN5Y2xlLiBU aGUgSUNSIHJlZ2lzdGVyCi0JCSAqIHJlcG9ydHMgYWxsLW9uZXMgdmFsdWUgaW4gdGhpcyBjYXNl LiBQcm9jZXNzaW5nIHN1Y2gKLQkJICogaW50ZXJydXB0cyB3b3VsZCBsZWFkIHRvIGEgZnJlZXpl LiBJIGRvbid0IGtub3cgd2h5LgotCQkgKi8KLQkJaWYgKHJlZ19pY3IgPT0gMHhmZmZmZmZmZikK LQkJCWJyZWFrOworCWlmICgocmVnX2ljciA9PSAwKSB8fCAoYWRhcHRlci0+aHcubWFjX3R5cGUg Pj0gZW1fODI1NzEgJiYKKwkgICAgKHJlZ19pY3IgJiBFMTAwMF9JQ1JfSU5UX0FTU0VSVEVEKSA9 PSAwKSB8fAorCS8qCisJICogWFhYOiBzb21lIGxhcHRvcHMgdHJpZ2dlciBzZXZlcmFsIHNwdXJp b3VzIGludGVycnVwdHMKKwkgKiBvbiBlbSg0KSB3aGVuIGluIHRoZSByZXN1bWUgY3ljbGUuIFRo ZSBJQ1IgcmVnaXN0ZXIKKwkgKiByZXBvcnRzIGFsbC1vbmVzIHZhbHVlIGluIHRoaXMgY2FzZS4g UHJvY2Vzc2luZyBzdWNoCisJICogaW50ZXJydXB0cyB3b3VsZCBsZWFkIHRvIGEgZnJlZXplLiBJ IGRvbid0IGtub3cgd2h5LgorCSAqLworCSAgICAocmVnX2ljciA9PSAweGZmZmZmZmZmKSkKKwkJ Z290byBsZWF2aW5nOwogCisJZm9yIChpbnQgaSA9IDA7aSA8IEVNX01BWF9JTlRSOyArK2kpIHsK IAkJaWYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSB7Ci0JCQllbV9yeGVv ZihhZGFwdGVyLCAtMSk7CisJCQllbV9yeGVvZihhZGFwdGVyLCAxMDApOwogCQkJZW1fdHhlb2Yo YWRhcHRlcik7CiAJCX0KLQogCQkvKiBMaW5rIHN0YXR1cyBjaGFuZ2UgKi8KIAkJaWYgKHJlZ19p Y3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykpIHsKIAkJCWNhbGxvdXRfc3Rv cCgmYWRhcHRlci0+dGltZXIpOwpAQCAtMTIwOCwxMCArMTIxOCwxMCBAQAogCQkJYWRhcHRlci0+ cnhfb3ZlcnJ1bnMrKzsKIAl9CiAKK2xlYXZpbmc6CiAJaWYgKGlmcC0+aWZfZHJ2X2ZsYWdzICYg SUZGX0RSVl9SVU5OSU5HICYmCiAJICAgICFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkp CiAJCWVtX3N0YXJ0X2xvY2tlZChpZnApOwotCiAJRU1fVU5MT0NLKGFkYXB0ZXIpOwogfQogCkBA IC0xMzY4LDIwICsxMzc4LDEzIEBACiAgICAgICAgICAqLwogCWlmIChhZGFwdGVyLT5udW1fdHhf ZGVzY19hdmFpbCA8PSBFTV9UWF9DTEVBTlVQX1RIUkVTSE9MRCkgewogCQllbV90eGVvZihhZGFw dGVyKTsKLQkJaWYgKGFkYXB0ZXItPm51bV90eF9kZXNjX2F2YWlsIDw9IEVNX1RYX0NMRUFOVVBf VEhSRVNIT0xEKSB7CisJCS8qIE5vdyBkbyB3ZSBhdCBsZWFzdCBoYXZlIGEgbWluaW1hbD8gKi8K KwkJaWYgKGFkYXB0ZXItPm51bV90eF9kZXNjX2F2YWlsIDw9IEVNX1RYX09QX1RIUkVTSE9MRCkg ewogCQkJYWRhcHRlci0+bm9fdHhfZGVzY19hdmFpbDErKzsKIAkJCXJldHVybihFTk9CVUZTKTsK IAkJfQogICAgICAgICB9CiAKLQkvKgotCSAqIENhcHR1cmUgdGhlIGZpcnN0IGRlc2NyaXB0b3Ig aW5kZXgsCi0JICogdGhpcyBkZXNjcmlwdG9yIHdpbGwgaGF2ZSB0aGUgaW5kZXgKLQkgKiBvZiB0 aGUgRU9QIHdoaWNoIGlzIHRoZSBvbmx5IG9uZSB0aGF0Ci0JICogbm93IGdldHMgYSBET05FIGJp dCB3cml0ZWJhY2suCi0JICovCi0JZmlyc3QgPSBhZGFwdGVyLT5uZXh0X2F2YWlsX3R4X2Rlc2M7 Ci0KICAgICAgICAgLyogRmluZCBvdXQgaWYgd2UgYXJlIGluIHZsYW4gbW9kZSAqLwogICAgICAg ICBtdGFnID0gVkxBTl9PVVRQVVRfVEFHKGlmcCwgbV9oZWFkKTsKIApAQCAtMTQzMyw2ICsxNDM2 LDE0IEBACiAJCQlyZXR1cm4gKEVOT0JVRlMpOwogCX0KIAorCS8qCisJICogQ2FwdHVyZSB0aGUg Zmlyc3QgZGVzY3JpcHRvciBpbmRleCwKKwkgKiB0aGlzIGRlc2NyaXB0b3Igd2lsbCBoYXZlIHRo ZSBpbmRleAorCSAqIG9mIHRoZSBFT1Agd2hpY2ggaXMgdGhlIG9ubHkgb25lIHRoYXQKKwkgKiBu b3cgZ2V0cyBhIERPTkUgYml0IHdyaXRlYmFjay4KKwkgKi8KKwlmaXJzdCA9IGFkYXB0ZXItPm5l eHRfYXZhaWxfdHhfZGVzYzsKKwogICAgICAgICAvKgogICAgICAgICAgKiBNYXAgdGhlIHBhY2tl dCBmb3IgRE1BLgogICAgICAgICAgKi8KQEAgLTE0NTIsNiArMTQ2Myw3IEBACiAJCQlyZXR1cm4g KEVOT0JVRlMpOwogCQl9CiAJCSptX2hlYWRwID0gbTsKKwogCQkvKiBUcnkgaXQgYWdhaW4gKi8K IAkJZXJyb3IgPSBidXNfZG1hbWFwX2xvYWRfbWJ1Zl9zZyhhZGFwdGVyLT50eHRhZywgdHhfYnVm ZmVyLT5tYXAsCiAJCSAgICAqbV9oZWFkcCwgc2VncywgJm5zZWdzLCBCVVNfRE1BX05PV0FJVCk7 CkBAIC0xNjM4LDcgKzE2NTAsNyBAQAogCSAgICBCVVNfRE1BU1lOQ19QUkVSRUFEIHwgQlVTX0RN QVNZTkNfUFJFV1JJVEUpOwogCWlmIChhZGFwdGVyLT5ody5tYWNfdHlwZSA9PSBlbV84MjU0NyAm JgogCSAgICBhZGFwdGVyLT5saW5rX2R1cGxleCA9PSBIQUxGX0RVUExFWCkKLQkJZW1fODI1NDdf bW92ZV90YWlsX2xvY2tlZChhZGFwdGVyKTsKKwkJZW1fODI1NDdfbW92ZV90YWlsKGFkYXB0ZXIp OwogCWVsc2UgewogCQlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBURFQsIGkpOwogCQlp ZiAoYWRhcHRlci0+aHcubWFjX3R5cGUgPT0gZW1fODI1NDcpCkBAIC0xNjYyLDggKzE2NzQsOSBA QAogICoKICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqLwogc3RhdGljIHZvaWQKLWVtXzgyNTQ3X21vdmVfdGFpbF9s b2NrZWQoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCitlbV84MjU0N19tb3ZlX3RhaWwodm9pZCAq YXJnKQogeworCXN0cnVjdCBhZGFwdGVyICphZGFwdGVyID0gYXJnOwogCXVpbnQxNl90IGh3X3Rk dDsKIAl1aW50MTZfdCBzd190ZHQ7CiAJc3RydWN0IGVtX3R4X2Rlc2MgKnR4X2Rlc2M7CkBAIC0x Njk2LDE1ICsxNzA5LDYgQEAKIAl9CQogfQogCi1zdGF0aWMgdm9pZAotZW1fODI1NDdfbW92ZV90 YWlsKHZvaWQgKmFyZykKLXsKLQlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IGFyZzsKLQotCUVN X0xPQ0soYWRhcHRlcik7Ci0JZW1fODI1NDdfbW92ZV90YWlsX2xvY2tlZChhZGFwdGVyKTsKLQlF TV9VTkxPQ0soYWRhcHRlcik7Ci19CiAKIHN0YXRpYyBpbnQKIGVtXzgyNTQ3X2ZpZm9fd29ya2Fy b3VuZChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciwgaW50IGxlbikKQEAgLTE4OTMsNyArMTg5Nyw3 IEBACiAJc3RydWN0IGFkYXB0ZXIJKmFkYXB0ZXIgPSBhcmc7CiAJc3RydWN0IGlmbmV0CSppZnAg PSBhZGFwdGVyLT5pZnA7CiAKLQlFTV9MT0NLKGFkYXB0ZXIpOworCUVNX0xPQ0tfQVNTRVJUKGFk YXB0ZXIpOwogCiAJZW1fY2hlY2tfZm9yX2xpbmsoJmFkYXB0ZXItPmh3KTsKIAllbV91cGRhdGVf bGlua19zdGF0dXMoYWRhcHRlcik7CkBAIC0xOTA0LDcgKzE5MDgsNiBAQAogCiAJY2FsbG91dF9y ZXNldCgmYWRhcHRlci0+dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAKLQlF TV9VTkxPQ0soYWRhcHRlcik7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0yMjI5LDcgKzIyMzIsOCBA QAogCWlmcC0+aWZfZmxhZ3MgPSBJRkZfQlJPQURDQVNUIHwgSUZGX1NJTVBMRVggfCBJRkZfTVVM VElDQVNUOwogCWlmcC0+aWZfaW9jdGwgPSBlbV9pb2N0bDsKIAlpZnAtPmlmX3N0YXJ0ID0gZW1f c3RhcnQ7Ci0JaWZwLT5pZl93YXRjaGRvZyA9IGVtX3dhdGNoZG9nOworCWlmcC0+aWZfdGltZXIg PSAwOwkvKiBEaXNhYmxlIG5ldCBsYXllciB3YXRjaGRvZyAqLworCWlmcC0+aWZfd2F0Y2hkb2cg PSBOVUxMOwogCUlGUV9TRVRfTUFYTEVOKCZpZnAtPmlmX3NuZCwgYWRhcHRlci0+bnVtX3R4X2Rl c2MgLSAxKTsKIAlpZnAtPmlmX3NuZC5pZnFfZHJ2X21heGxlbiA9IGFkYXB0ZXItPm51bV90eF9k ZXNjIC0gMTsKIAlJRlFfU0VUX1JFQURZKCZpZnAtPmlmX3NuZCk7CkBAIC0yNDUzLDI2ICsyNDU3 LDE5IEBACiB7CiAJZGV2aWNlX3QgZGV2ID0gYWRhcHRlci0+ZGV2OwogCXN0cnVjdCBlbV9idWZm ZXIgKnR4X2J1ZmZlcjsKLQlidXNfc2l6ZV90IHNpemUsIHNlZ3NpemU7CiAJaW50IGVycm9yLCBp OwogCi0jaWZkZWYgRU1fVFNPCi0Jc2l6ZSA9IEVNX1RTT19TSVpFOwotCXNlZ3NpemUgPSBQQUdF X1NJWkU7Ci0jZWxzZQotCXNlZ3NpemUgPSBzaXplID0gcm91bmR1cDIoYWRhcHRlci0+aHcubWF4 X2ZyYW1lX3NpemUsIE1DTEJZVEVTKTsKLSNlbmRpZgogCS8qCi0JICogU2V0dXAgRE1BIGRlc2Ny aXB0b3IgYXJlYXMuCisJICogQ3JlYXRlIERNQSB0YWdzIGZvciB0eCBkZXNjcmlwdG9ycwogCSAq LwogCWlmICgoZXJyb3IgPSBidXNfZG1hX3RhZ19jcmVhdGUoTlVMTCwJCS8qIHBhcmVudCAqLwog CQkJCTEsIDAsCQkJLyogYWxpZ25tZW50LCBib3VuZHMgKi8KIAkJCQlCVVNfU1BBQ0VfTUFYQURE UiwJLyogbG93YWRkciAqLwogCQkJCUJVU19TUEFDRV9NQVhBRERSLAkvKiBoaWdoYWRkciAqLwog CQkJCU5VTEwsIE5VTEwsCQkvKiBmaWx0ZXIsIGZpbHRlcmFyZyAqLwotCQkJCXNpemUsCQkJLyog bWF4c2l6ZSAqLworCQkJCUVNX1RTT19TSVpFLAkJLyogbWF4c2l6ZSAqLwogCQkJCUVNX01BWF9T Q0FUVEVSLAkJLyogbnNlZ21lbnRzICovCi0JCQkJc2Vnc2l6ZSwJCS8qIG1heHNlZ3NpemUgKi8K KwkJCQlQQUdFX1NJWkUsCQkvKiBtYXhzZWdzaXplICovCiAJCQkJMCwJCQkvKiBmbGFncyAqLwog CQkJCU5VTEwsCQkvKiBsb2NrZnVuYyAqLwogCQkJCU5VTEwsCQkvKiBsb2NrYXJnICovCkBAIC0y NDg5LDYgKzI0ODYsNyBAQAogCQlnb3RvIGZhaWw7CiAJfQogCisJLyogQ3JlYXRlIHRoZSBkZXNj cmlwdG9yIGJ1ZmZlciBkbWEgbWFwcyAqLwogCXR4X2J1ZmZlciA9IGFkYXB0ZXItPnR4X2J1ZmZl cl9hcmVhOwogCWZvciAoaSA9IDA7IGkgPCBhZGFwdGVyLT5udW1fdHhfZGVzYzsgaSsrKSB7CiAJ CWVycm9yID0gYnVzX2RtYW1hcF9jcmVhdGUoYWRhcHRlci0+dHh0YWcsIDAsICZ0eF9idWZmZXIt Pm1hcCk7CkBAIC0yNTE3LDYgKzI1MTUsNyBAQAogCXN0cnVjdCBlbV9idWZmZXIgKnR4X2J1ZmZl cjsKIAlpbnQgaTsKIAorCS8qIENsZWFyIHRoZSBvbGQgcmluZyBjb250ZW50cyAqLwogCWJ6ZXJv KGFkYXB0ZXItPnR4X2Rlc2NfYmFzZSwKIAkgICAgKHNpemVvZihzdHJ1Y3QgZW1fdHhfZGVzYykp ICogYWRhcHRlci0+bnVtX3R4X2Rlc2MpOwogCkBAIC0yODU3LDggKzI4NTYsMTAgQEAKICAgICAg ICAgZW9wX2Rlc2MgPSAmYWRhcHRlci0+dHhfZGVzY19iYXNlW2xhc3RdOwogCiAJLyoKLQkgKiBO b3cgY2FjdWxhdGUgdGhlIHRlcm1pbmF0aW5nIGluZGV4Ci0JICogZm9yIHRoZSBjbGVhbnVwIGxv b3AgYmVsb3cKKwkgKiBXaGF0IHRoaXMgZG9lcyBpcyBnZXQgdGhlIGluZGV4IG9mIHRoZQorCSAq IGZpcnN0IGRlc2NyaXB0b3IgQUZURVIgdGhlIEVPUCBvZiB0aGUgCisJICogZmlyc3QgcGFja2V0 LCB0aGF0IHdheSB3ZSBjYW4gZG8gdGhlCisJICogc2ltcGxlIGNvbXBhcmlzb24gb24gdGhlIGlu bmVyIHdoaWxlIGxvb3AuCiAJICovCiAJaWYgKCsrbGFzdCA9PSBhZGFwdGVyLT5udW1fdHhfZGVz YykgbGFzdCA9IDA7CiAJZG9uZSA9IGxhc3Q7CkBAIC0yOTE2LDkgKzI5MTcsMTAgQEAKICAgICAg ICAgaWYgKG51bV9hdmFpbCA+IEVNX1RYX0NMRUFOVVBfVEhSRVNIT0xEKSB7ICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgIGlmcC0+aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX09BQ1RJ VkU7CiAgICAgICAgICAgICAgICAgaWYgKG51bV9hdmFpbCA9PSBhZGFwdGVyLT5udW1fdHhfZGVz YykKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmcC0+aWZfdGltZXIgPSAwOworCQkJY2FsbG91 dF9zdG9wKCZhZGFwdGVyLT53YXRjaGRvZyk7CiAgICAgICAgICAgICAgICAgZWxzZSBpZiAobnVt X2F2YWlsICE9IGFkYXB0ZXItPm51bV90eF9kZXNjX2F2YWlsKQotICAgICAgICAgICAgICAgICAg ICAgICAgaWZwLT5pZl90aW1lciA9IEVNX1RYX1RJTUVPVVQ7CisJCQljYWxsb3V0X3Jlc2V0KCZh ZGFwdGVyLT53YXRjaGRvZywgNSAqIGh6LAorCQkJICAgIGVtX3dhdGNoZG9nLCBhZGFwdGVyKTsK ICAgICAgICAgfQogICAgICAgICBhZGFwdGVyLT5udW1fdHhfZGVzY19hdmFpbCA9IG51bV9hdmFp bDsKICAgICAgICAgcmV0dXJuOwpAQCAtMzc5Niw2ICszNzk4LDggQEAKIAkgICAgYWRhcHRlci0+ bWJ1Zl9jbHVzdGVyX2ZhaWxlZCk7CiAJZGV2aWNlX3ByaW50ZihkZXYsICJEcml2ZXIgZHJvcHBl ZCBwYWNrZXRzID0gJWxkXG4iLAogCSAgICBhZGFwdGVyLT5kcm9wcGVkX3BrdHMpOworCWRldmlj ZV9wcmludGYoZGV2LCAiRHJpdmVyIHR4IGRtYSBmYWlsdXJlIGluIGVuY2FwID0gJWxkXG4iLAor CQlhZGFwdGVyLT5ub190eF9kbWFfc2V0dXApOwogfQogCiBzdGF0aWMgdm9pZApkaWZmIC1OYXVy IHN0YWJsZS9kZXYvZW0vaWZfZW0uaCBqZnYvZGV2L2VtL2lmX2VtLmgKLS0tIHN0YWJsZS9kZXYv ZW0vaWZfZW0uaAlGcmkgTm92ICAzIDAyOjAyOjM5IDIwMDYKKysrIGpmdi9kZXYvZW0vaWZfZW0u aAlTYXQgTm92ICA0IDA2OjI2OjU4IDIwMDYKQEAgLTE1NCw2ICsxNTQsNyBAQAogICogdHJhbnNt aXQgZGVzY3JpcHRvcnMuCiAgKi8KICNkZWZpbmUgRU1fVFhfQ0xFQU5VUF9USFJFU0hPTEQJCShh ZGFwdGVyLT5udW1fdHhfZGVzYyAvIDgpCisjZGVmaW5lIEVNX1RYX09QX1RIUkVTSE9MRAkJOAog CiAvKgogICogVGhpcyBwYXJhbWV0ZXIgY29udHJvbHMgd2hldGhlciBvciBub3QgYXV0b25lZ290 YXRpb24gaXMgZW5hYmxlZC4KQEAgLTMyOCw2ICszMjksNyBAQAogCXN0cnVjdCBpZm1lZGlhCW1l ZGlhOwogCXN0cnVjdCBjYWxsb3V0CXRpbWVyOwogCXN0cnVjdCBjYWxsb3V0CXR4X2ZpZm9fdGlt ZXI7CisJc3RydWN0IGNhbGxvdXQJd2F0Y2hkb2c7CiAJaW50CQlpb19yaWQ7CiAJaW50CQlpZl9m bGFnczsKIAlzdHJ1Y3QgbXR4CW10eDsK ------=_Part_43447_15205892.1162606593613-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 02:46:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C6A316A407 for ; Sat, 4 Nov 2006 02:46:35 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD9643D53 for ; Sat, 4 Nov 2006 02:46:32 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1676855nfe for ; Fri, 03 Nov 2006 18:46:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bnh0RuuAkBSY3rj2roaJ/ykXNmUDCq36kNX1aUusZ7zU7DHM0PFFCI5QPLjLh/ZDgsCocK9C3572ihV0beHeBec8aRBr2k22FusOECVJ8ymhQiUpVZch380c3662gs8b8w9HyXkLcdZoJ91V61xBLnoy/Je+IPoJgZ1G5AiLofg= Received: by 10.49.49.4 with SMTP id b4mr2297220nfk.1162608390912; Fri, 03 Nov 2006 18:46:30 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 18:46:30 -0800 (PST) Message-ID: Date: Sat, 4 Nov 2006 02:46:30 +0000 From: MQ To: "Brooks Davis" In-Reply-To: <20061103141732.GA87515@lor.one-eyed-alien.net> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> <20061103141732.GA87515@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 02:46:35 -0000 2006/11/3, Brooks Davis : > > On Fri, Nov 03, 2006 at 09:46:47AM +0000, MQ wrote: > > 2006/11/2, Brooks Davis : > > > > > >On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > > >> Hi, > > >> > > >> I am confused by the use of inet_ntoa function in the kernel. > > >> > > >> The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > > >array > > >> static char buf[4 * sizeof "123"]; > > >> to store the result. And it returns the address of the array to the > > >caller. > > >> > > >> I think this inet_ntoa is not reentrant, though there are several > > >functions > > >> calling it. If two functions call it simultaneously, the result will > be > > >> corrupted. Though I haven't really encountered this situation, it may > > >occur > > >> someday, especially when using multi-processors. > > >> > > >> There is another reentrant version of inet_ntoa called inet_ntoa_r in > > >the > > >> same file. It has been there for several years, but just used by > ipfw2 > > >for > > >> about four times in 7-CURRENT. In my patch, I replaced all the calls > to > > >> inet_ntoa with calls to inet_ntoa_r. > > >> > > >> By the way, some of the original calls is written in this style: > > >> strcpy(buf, inet_ntoa(ip)) > > >> The modified code is written in this style > > >> inet_ntoa_r(ip, buf) > > >> This change avoids a call to strcpy, and can save a little time. > > >> > > >> Here is the patch. > > >> > > > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net > > >> > > >> I've already sent to PR(kern/104738), but got no reply, maybe it > should > > >be > > >> discussed here first? > > > > > >I've got to agree with other posters that the stack variable > allocations > > >are ugly. What about extending log and printf to understand ip4v > > >addresses? That's 90% of the uses and the others appears to have > > >buffers already. > > > > > >-- Brooks > > > > > > > > >Ugly? Why? Don't you use local variables in your sources? > > The particular definition used is excedingly ugly. At a minimum there > needs to be a define or a constant "16" for the lenght rather than the > 4*sizeof("123") nonsense. > > -- Brooks > > > Oh, I see. This kind of definition is really annoying, and hard to keep all the occurrences consistent. Maybe a better way is use a macro to make that clear? #define IPV4_ADDRSZ (4 * sizeof "123") char buf[IPV4_ADDRSZ]; This "ugly" definition comes from inet_ntoa() in /sys/libkern/inet_ntoa.c, I just copied the style without too much consideration, it's my fault. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 03:01:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5667816A412 for ; Sat, 4 Nov 2006 03:01:03 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D0E243D46 for ; Sat, 4 Nov 2006 03:01:02 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1679933nfe for ; Fri, 03 Nov 2006 19:01:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=edD/uXgjG+GYptJUkc5Vclnv6xVjnvbWIQmo+7UxM0lMpN/2WSrvsXKbDmkmCin0sG1w2o+08jFX06bzkkedn1H4ztLbJvolGTjvcJKCmbnupLtcG0T1c5iyJjGBLIctwojtx6XCXPplklo+yrpwaJ9ZLlEyQdRtzecVgcVoUso= Received: by 10.49.90.4 with SMTP id s4mr2320854nfl.1162609260760; Fri, 03 Nov 2006 19:01:00 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 19:01:00 -0800 (PST) Message-ID: Date: Sat, 4 Nov 2006 03:01:00 +0000 From: MQ To: "Max Laier" In-Reply-To: <200611031220.53791.max@love2party.net> MIME-Version: 1.0 References: <20061102142543.GC70915@lor.one-eyed-alien.net> <200611031220.53791.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 03:01:03 -0000 I use google mail web interface to post messages, I can't connect to the google mail POP server because someone disabled it on the firewall :( I don't know if this post will be better? 2006/11/3, Max Laier : > > Hello "MQ", > > your email client is seriously mis-configured, could you please look into > this as it is a bit annoying. > > On Friday 03 November 2006 10:46, MQ wrote: > > 2006/11/2, Brooks Davis : > > > On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote: > > > > Hi, > > > > > > > > I am confused by the use of inet_ntoa function in the kernel. > > > > > > > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a > > > > static > > > > > > array > > > > > > > static char buf[4 * sizeof "123"]; > > > > to store the result. And it returns the address of the array to the > > > > > > caller. > > > > > > > I think this inet_ntoa is not reentrant, though there are several > > > > > > functions > > > > > > > calling it. If two functions call it simultaneously, the result > > > > will be corrupted. Though I haven't really encountered this > > > > situation, it may > > > > > > occur > > > > > > > someday, especially when using multi-processors. > > > > > > > > There is another reentrant version of inet_ntoa called inet_ntoa_r > > > > in > > > > > > the > > > > > > > same file. It has been there for several years, but just used by > > > > ipfw2 > > > > > > for > > > > > > > about four times in 7-CURRENT. In my patch, I replaced all the > > > > calls to inet_ntoa with calls to inet_ntoa_r. > > > > > > > > By the way, some of the original calls is written in this style: > > > > strcpy(buf, inet_ntoa(ip)) > > > > The modified code is written in this style > > > > inet_ntoa_r(ip, buf) > > > > This change avoids a call to strcpy, and can save a little time. > > > > > > > > Here is the patch. > > > > > > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah > > >-net > > > > > > > I've already sent to PR(kern/104738), but got no reply, maybe it > > > > should > > > > > > be > > > > > > > discussed here first? > > > > > > I've got to agree with other posters that the stack variable > > > allocations are ugly. What about extending log and printf to > > > understand ip4v addresses? That's 90% of the uses and the others > > > appears to have buffers already. > > > > > > -- Brooks > > > > > > > Ugly? Why? Don't you use local variables in your sources? > > You have to understand, that stack space is a limited resource in the > kernel. Some of the functions are leaf nodes in quite long call paths, > which means adding those buffers can hit quite hard. > > I guess what Brooks and I are trying to say is, that this needs to be > considered carefully. A simple search and replace won't do. > > BTW, I took the PR for now and will look into it. I don't think it's > something we need to rush, as I haven't seen any reports or indication of > real problems yet - fwiw we don't spew a lot of IP addresses to console > or log in normal operation. > > > By the way, implementing a printf/log which understands ipv4 address is > > tedious, perhaps. > > Actually, it's a ~15 line patch, I will see if I can get to it later > today. If we reuse the number buffer we can even get away without > increase in stack space usage. Whether or not this is a good idea is on > another page, but %I and %lI (for IPv6) would be available and we already > have %D and %b as special cases in the kernel. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > I know for sure that the kernel stack is much smaller than that in userland programms, but is the kernel stack too small to contain another 32 bytes at most? I've no idea, and is there any way to trace the usage of the kernel stack? KGDB? The reason why I don't like the idea that adding the facility into printf is we already had the converter inet_ntoa, adding the facility seems duplicated. But if implemented, and use a local buffer, this should be a really good way to solve the reentrant problem. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 04:51:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AE3D16A412 for ; Sat, 4 Nov 2006 04:51:43 +0000 (UTC) (envelope-from antinvidia@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id A670F43D49 for ; Sat, 4 Nov 2006 04:51:42 +0000 (GMT) (envelope-from antinvidia@gmail.com) Received: by qb-out-0506.google.com with SMTP id q17so195015qba for ; Fri, 03 Nov 2006 20:51:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=uvAFFm3DMnolBqtEXRz4HIBoQqkLKUEimufGHGXycy448Jv2Vr0r/sILQK6tHakjssxgCsPnKwe9UqFpgXhr0lyxjdO1Yv2L/rxCquPovJHDHbXa1yzGzruuW1Ne2+3II6uty6UIB3yzeYGUbB29ZOH5aiMygkTkpJ+U93gcOuo= Received: by 10.49.1.12 with SMTP id d12mr516766nfi.1162612344162; Fri, 03 Nov 2006 19:52:24 -0800 (PST) Received: by 10.49.37.15 with HTTP; Fri, 3 Nov 2006 19:52:24 -0800 (PST) Message-ID: Date: Sat, 4 Nov 2006 03:52:24 +0000 From: MQ To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: davidch@freebsd.org Subject: device polling problem with the bge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 04:51:43 -0000 Hi, I have two boxes running bge(4). One is ARIMA SW330 with two 5780 on board, another is HP NC6000 notebook with 5701. After I enabled device polling, I found the lost_polls is always increasing. I looked through the codes in /sys/dev/bge/if_bge.c, and finally found that the problem lies in the function bge_tick. More exactly, the problem is caused by mii_tick. It is called frequently, and normally returns in 0.5ms. But it always get one chance to cost 4~5ms in every 4s. This behavior causes the BGE_LOCK statement in bge_poll() to delay 4~5ms, and finally makes the lost_polls increasing. Additionally, the HZ for bge(4), at least for my bge(4) cards, is limited to at most 2000, or there will be lost_polls every second. I hope this is a fixable problem, and fixed soon. Thanks. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 05:02:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 548C016A403; Sat, 4 Nov 2006 05:02:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA3C43D58; Sat, 4 Nov 2006 05:02:35 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kA452YLx092717; Sat, 4 Nov 2006 00:02:35 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kA452YK6086204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Nov 2006 00:02:34 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611040502.kA452YK6086204@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Nov 2006 00:04:43 -0500 To: "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net From: Mike Tancsa In-Reply-To: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.co m> References: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: Re: New em patch for 6.2 BETA 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 05:02:36 -0000 At 09:16 PM 11/3/2006, Jack Vogel wrote: >I, and re, would very much appreciate any test feedback you can Thanks very much for working on this! I was not able to easily reproduce the timeouts in the first place, but so far on the one box I have been testing, it seems to be fine (netrate with various small packets). I will load up some more boxes tomorrow and see how it goes. I tested on an acpi0: on motherboard with the onboard NIC. ---Mike From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 05:21:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6235916A403 for ; Sat, 4 Nov 2006 05:21:08 +0000 (UTC) (envelope-from dfs@goodshepherdmissions.com) Received: from host.pwpmall.com (host.pwpmall.com [65.109.239.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9B9C43D58 for ; Sat, 4 Nov 2006 05:21:07 +0000 (GMT) (envelope-from dfs@goodshepherdmissions.com) Received: (from udel@localhost) by host.pwpmall.com (8.12.11.20060614/8.12.10) id kA45L6w3006522; Sat, 4 Nov 2006 00:21:06 -0500 Date: Sat, 4 Nov 2006 00:21:06 -0500 From: dfs@goodshepherdmissions.com Message-Id: <200611040521.kA45L6w3006522@host.pwpmall.com> X-Authentication-Warning: host.pwpmall.com: udel set sender to dfs@goodshepherdmissions.com using -f To: freebsd-net@freebsd.org References: <200611040521.kA45L49p006173@host.pwpmall.com> In-Reply-To: <200611040521.kA45L49p006173@host.pwpmall.com> X-Loop: outOfSpace Precedence: junk Subject: MESSAGE NOT DELIVERED: Mail Delivery (failure dfs@goodshepherdmissions.com) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 05:21:08 -0000 Your message could not be delivered. The User is out of space. Please try to send your message again at a later time. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 05:27:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BE5C16A5C3 for ; Sat, 4 Nov 2006 05:27:32 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F99C43D58 for ; Sat, 4 Nov 2006 05:27:30 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id i2so1709520nfe for ; Fri, 03 Nov 2006 21:27:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KSxkMcfTZbRr8uEcHujCZpwNEhkIaIQT/iZ5LzakKQX7Lhr7/ThohT/Xu3zvDvQbBluuaEzAHd/ROhh7RTJYEEGCnthyUsf6GaheBbcVMrtEdy1qi0KLcn0aHgQvP0+EWzHTRJp2WoEfqBHI9cNg2zBipvBAxcTK2YVCOjSNTds= Received: by 10.82.135.13 with SMTP id i13mr943106bud.1162618046608; Fri, 03 Nov 2006 21:27:26 -0800 (PST) Received: by 10.82.191.20 with HTTP; Fri, 3 Nov 2006 21:27:24 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 21:27:26 -0800 From: "Kip Macy" To: "Jack Vogel" In-Reply-To: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> MIME-Version: 1.0 References: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: New em patch for 6.2 BETA 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 05:27:34 -0000 If you create a patch against -CURRENT I can test on sun4v. The timeouts with em on sun4v are so severe that I have to use the driver from June for any kind of workload. -Kip On 11/3/06, Jack Vogel wrote: > > I have been hard at work trying to understand and fix the > remaining issues with the em driver. What I have here is > a patch that has gotten rid of any issues that I can reproduce. > > It solves the intermittent watchdogs that have been happening. > It also fixes the problem noted with jumbo frame tx > > I, and re, would very much appreciate any test feedback you can > give on this code. I am happy with the changes, I hope these get > rid of everyone's issues. > > Thanks to Gleb and Scott and John for all the help! > > Jack > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 05:32:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE3816A417 for ; Sat, 4 Nov 2006 05:32:00 +0000 (UTC) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.twinthornes.com (mail.twinthornes.com [65.75.198.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A0643D60 for ; Sat, 4 Nov 2006 05:31:59 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from [10.9.70.3] (c-71-56-148-19.hsd1.or.comcast.net [71.56.148.19]) by mail.twinthornes.com (Postfix) with ESMTP id 1037CF26 for ; Fri, 3 Nov 2006 21:31:58 -0800 (PST) Message-ID: <454C25CD.5010008@bitfreak.org> Date: Fri, 03 Nov 2006 21:31:57 -0800 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <200611040521.kA45L49p006173@host.pwpmall.com> <200611040521.kA45L6w3006522@host.pwpmall.com> In-Reply-To: <200611040521.kA45L6w3006522@host.pwpmall.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: MESSAGE NOT DELIVERED X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 05:32:00 -0000 dfs@goodshepherdmissions.com wrote: > Your message could not be delivered. The User is out of space. I empathize with the user. I have days where I feel like I'm zero-dimensional as well. -- Darren Pilgrim From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 06:37:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDFAC16A403; Sat, 4 Nov 2006 06:37:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from dhreinsvgw02.danahermail.com (mx6.danahermail.com [193.221.156.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B695D43D45; Sat, 4 Nov 2006 06:37:26 +0000 (GMT) (envelope-from mike@sentex.net) Received: from dhreinsvxf02.messaging.danaherad.com (dhreinsvxf02.messaging.danaherad.com [172.29.216.76]) by dhreinsvgw02.danahermail.com (BorderWare MXtreme Mail Firewall) with ESMTP id 49A3A385MA; Sat, 4 Nov 2006 07:37:15 +0100 (CET) Received: from mail pickup service by dhreinsvxf02.messaging.danaherad.com with Microsoft SMTPSVC; Sat, 4 Nov 2006 07:36:58 +0100 Received: from dhreinsvgw01.danahermail.com ([172.29.216.80]) by dhreinsvxf02.messaging.danaherad.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Sat, 4 Nov 2006 06:07:17 +0100 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by dhreinsvgw01.danahermail.com (BorderWare MXtreme Mail Firewall) with ESMTP id 947DF0E3AL for ; Sat, 4 Nov 2006 06:07:16 +0100 (CET) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 4AEA6731F8; Sat, 4 Nov 2006 05:02:51 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5EA8716A5DA; Sat, 4 Nov 2006 05:02:41 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 548C016A403; Sat, 4 Nov 2006 05:02:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA3C43D58; Sat, 4 Nov 2006 05:02:35 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kA452YLx092717; Sat, 4 Nov 2006 00:02:35 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kA452YK6086204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Nov 2006 00:02:34 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611040502.kA452YK6086204@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Nov 2006 00:04:43 -0500 To: "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net From: Mike Tancsa In-Reply-To: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.co m> References: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-STA-Metric: 0 (engine=022) X-STA-NotSpam: url:mailman url:listinfo header:Errors-To:1 nic skip:__ 40 X-STA-Spam: re, thisl this! testing, proto:http X-BTI-AntiSpam: score:0, sta:0/022, dcc:off, dnsbl:off, sw:passed, bsn:13/passed, Brightmail:passed, spf:off, dk:off, pbmf:none, ipr:0/8, trusted:no, ts:no, ubl:off X-OriginalArrivalTime: 04 Nov 2006 05:07:17.0499 (UTC) FILETIME=[195594B0:01C6FFCF] Cc: Subject: Re: New em patch for 6.2 BETA 3 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: Sat, 04 Nov 2006 06:37:28 -0000 At 09:16 PM 11/3/2006, Jack Vogel wrote: >I, and re, would very much appreciate any test feedback you can Thanks very much for working on this! I was not able to easily reproduce the timeouts in the first place, but so far on the one box I have been testing, it seems to be fine (netrate with various small packets). I will load up some more boxes tomorrow and see how it goes. I tested on an acpi0: on motherboard with the onboard NIC. ---Mike _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 07:10:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FE3416A40F for ; Sat, 4 Nov 2006 07:10:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB7B43D55 for ; Sat, 4 Nov 2006 07:10:51 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id z59so446453pyg for ; Fri, 03 Nov 2006 23:10:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KpyOy72GuKEEazTCAdh76zp3/O/PJ/vN7OUo1bd4S9CSDqvviA7hPdtIel8QbZYYQfgdcudsHIVeNYEl99kQlOaXK8WRnxR9xN5R2D0uXBJAxcuwno5Yhv8uWU4F9ldESlDrDw0sEAPFfkrHqJV45nZnEKF8fKp6/ueaEYVHVtE= Received: by 10.35.81.1 with SMTP id i1mr5052666pyl.1162624217774; Fri, 03 Nov 2006 23:10:17 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 3 Nov 2006 23:10:17 -0800 (PST) Message-ID: <2a41acea0611032310v419c94a2k6d535842d05ee2cf@mail.gmail.com> Date: Fri, 3 Nov 2006 23:10:17 -0800 From: "Jack Vogel" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0611031816n1af99819rdc6b99e9dd2deb7c@mail.gmail.com> Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: New em patch for 6.2 BETA 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 07:10:52 -0000 On 11/3/06, Kip Macy wrote: > If you create a patch against -CURRENT I can test on sun4v. The timeouts > with em on sun4v are so severe that I have to use the driver from June for > any kind of workload. > > -Kip > I believe Gleb was going to merge code to current so you should have something before long, part of the changes are already there in John's recent checkins. Jack From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 09:04:07 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E485516A40F for ; Sat, 4 Nov 2006 09:04:06 +0000 (UTC) (envelope-from olderro@france-transactions.fr) Received: from france-transactions.fr (aix96.neoplus.adsl.tpnet.pl [83.25.231.96]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BFE843D55 for ; Sat, 4 Nov 2006 09:03:51 +0000 (GMT) (envelope-from olderro@france-transactions.fr) Message-ID: <00cc01c6ff08$3afe58e0$2740c3a0@evoluminousd> From: "Tamikae Lucy" To: Date: Sat, 04 Nov 2006 10:03:46 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Attention, terrific growth! ck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tamikae Lucy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 09:04:07 -0000 THIS ONE IS BEING PROMOTED, TAKE ADVANTAGE This advisory is based on exclusive insiders/agents information. (AVLN.OB) Avalon Energy Corporation has an undivided 85% working interest in the Shotgun Draw Prospect in the prolific natural gas producing Uinta Basin , located in the US Rockies, Utah . The lease comprises 13,189 acres with a potential 4 TCF recoverable gas and is overpressured by a 0.55 . 0.85 gradient. ON MONDAY NOV 6th: - Volume: 389,001 - Volume: + 50% - Price: +5.77% The key to any tade is buying low and selling high, WELL the energy market has bottomed out and time to get in is now. We specialise in calling market bottom and when it comes to energy THIS IS THE BOTTOM, SO GET IN FOLKS WIN WIN WIN WITH THIS COMPANY WIN WIN WIN WITH THIS COMPANY Two days after the accident, the Federal Aviation Administration ordered small, fixed-wing planes not to fly over the East River unless the pilot is in contact with air traffic controllers. The report issued Friday said the airplane was flying along the East River between Manhattan and Queens when it attempted a U-turn with only 1,300 feet of room for the turn. To make a successful turn, the aircraft would have had to bank so steeply that it might have stalled, the NTSB said in an update on the crash. The report issued Friday said the airplane was flying along the East River between Manhattan and Queens when it attempted a U-turn with only 1,300 feet of room for the turn. To make a successful turn, the aircraft would have had to bank so steeply that it might have stalled, the NTSB said in an update on the crash. Democrats say they are ahead in many races because of the public's growing dissatisfaction with the war in Iraq. And polls show that a clear majority of Americans see the war as a mistake and far fewer support the president's handling of it. From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 18:47:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D3116A539 for ; Sat, 4 Nov 2006 18:47:37 +0000 (UTC) (envelope-from multifariousexe@trimension-inc.com) Received: from trimension-inc.com (59-116-185-213.dynamic.hinet.net [59.116.185.213]) by mx1.FreeBSD.org (Postfix) with SMTP id 4EB1743D69 for ; Sat, 4 Nov 2006 18:47:16 +0000 (GMT) (envelope-from multifariousexe@trimension-inc.com) Message-ID: <020e01c6ff86$3ebe28c0$5186c5b0@pbattleshipm> From: "PShawn Pearl" To: Date: Sun, 05 Nov 2006 02:47:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wall Street Watch q X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PShawn Pearl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 18:47:37 -0000 THE PR CAMPAIGN IS ON GET IN FIRST THING IN THE MORNING This advisory is based on exclusive insiders/agents information. (NHVP.PK) NHVP has provided investors with 1000% + gains during the real estate boom, and now with the sector at its bottom, is ready to provide with results yet again.. OCT 13th: Northeast Development Corp. to Receive Funding from European Investment Firm. Preliminary discussions suggest figures of -3 million with a combination of real estate and equity collateralization. GET IN ON MONDAY NOV 6th: at 08 cents its a STEAL - Volume: 8,000 - Volume: + 100% - Price: +100% The key to any tade is buying low and selling high, WELL the REAL ESTATE market has bottomed out and time to get in is now. We specialise in calling market bottom and when it comes to REAL ESTATE THIS IS THE BOTTOM, SO GET IN FOLKS USA SMALL CAP WINNER USA SMALL CAP WINNER Previewing his weekend at his Texas ranch, Bush said he planned to be with his wife, Laura, to celebrate her birthday Saturday. Last week's fire was stoked by Santa Ana winds as it swept southwest through the mountains about 90 miles east of Los Angeles. The flames overran the fire crew, destroyed 34 homes and charred more than 60 square miles before being contained Monday. "Nine days ago, one of the worst tragedies in the 100-year history of the Forest Service took the lives of five heroes," U.S. Forest Service Chaplain Steve Seltzner said as the service began. "It has shaken this agency and the men and women of the San Benardino National Forest to its very core and shocked the entire world." "If they say they want to win the war on terror, but call for America to pull out of what al Qaeda says is the central front in this war, ask them this question: 'What's your plan?' " Bush said at a rally for Missouri Sen. Jim Talent, who is seeking re-election in one of the tightest races in the nation. (Watch how Bush is picking his election battles -- 1:36 ) From owner-freebsd-net@FreeBSD.ORG Sat Nov 4 23:44:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D301116A407 for ; Sat, 4 Nov 2006 23:44:06 +0000 (UTC) (envelope-from chris.scott@uk.tiscali.com) Received: from mk-ironport-1-in.mail.uk.tiscali.com (mk-ironport-1-in.mail.uk.tiscali.com [212.74.96.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44A5C43D4C for ; Sat, 4 Nov 2006 23:44:05 +0000 (GMT) (envelope-from chris.scott@uk.tiscali.com) Received: from internal.mail.uk.tiscali.com ([212.74.96.51]) by mk-ironport-1-in.mail.uk.tiscali.com with ESMTP; 04 Nov 2006 23:44:04 +0000 X-BrightmailFiltered: true X-IronPort-AV: i="4.09,388,1157324400"; d="scan'208"; a="51664702:sNHT24384020" Received: from [10.44.30.67] (port=36334 helo=[10.44.30.67]) by internal.mail.uk.tiscali.com with esmtp (Exim 4.43 #1 (FreeBSD)) id 1GgVBE-0007gS-8g; Sat, 04 Nov 2006 23:44:04 +0000 Message-ID: <454D25C4.2000503@uk.tiscali.com> Date: Sat, 04 Nov 2006 23:44:04 +0000 From: chris scott User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: peter@alastria.net References: <2864.10.10.4.10.1162579931.squirrel@neon.alastria.lan> In-Reply-To: <2864.10.10.4.10.1162579931.squirrel@neon.alastria.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPSEC, isakmpd, tunnel/transport encapsulation... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2006 23:44:07 -0000 I tried to setup something exactly like you did. I could do it fine with freebsd boxes as I would do it via username not ip. Never really got the problem sorted for windows though. I ended up using openVPN instead. I would seriously recommend you try this solution as its far easier to setup. Being as it runs over udp or tcp it running into no issues with NAT like you do with IPSEC. If you run the server on tcp port 443 you can also get it to run through corp firewalls that require you to use a web proxy. Chris peter@alastria.net wrote: > Good Evening, > > I apologise for what may end up being a stupid question, I'm getting > towards my wits end. I've got a FreeBSD 6.2-PRERELEASE (cvsup of about > 1300 GMT today) gateway which I'm attempting to run IPSEC/L2TP for > wireless security. > > My client computers are Windows XP and Mac OS X, and the issue happens > with both. No client has a fixed IP, so I want to permit any IP to > establish a IPSEC session providing they know the preshared key. > > I'm using isakmpd for setup of the IPSEC side of things and hopefully > SL2TPS for the L2TP side, although I'm not there yet. > > My issue is that none of my client can establish a L2TP session for what > looks to be a mismatch of encapsulation types. For example, the first > packet bellow is from my laptop to the gateway, the second is the reply. > > 18:18:56.540995 (authentic,confidential): SPI 0x1b79c065: IP > 10.10.3.254.1701 > 10.10.2.1.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 > *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() > FIRM_VER(1280) |... > > 18:18:56.541039 (authentic,confidential): SPI 0x136223d4: IP 10.10.2.1 > > 10.10.3.254: IP 10.10.2.1.1701 > 10.10.3.254.1701: l2tp:[TLS](20/0) > Ns=1,Nr=1 ZLB (ipip-proto-4) > > This seems to be causing issues as the remote host isn't expecting the > IPIP encapsulation there. I don't believe it has anything to do with > SL2TPS because if I try and ICMP Ping 10.10.3.254 from 10.10.2.1, the ICMP > request is IPSEC'd with the IPIP encapsulation. > > Has anyone seen this before? I'm using a fairly simplistic isakmpd.conf > (which may be my issue)... > > [General] > Listen-on = 10.10.2.1 > > [Phase 1] > Default = local-peers > > [Phase 2] > Passive-connections = authenticated-peers > > [local-peers] > Phase = 1 > Local-address = 10.10.2.1 > Authentication = mypresharedkey > Configuration = isakmp-main-mode > > [authenticated-peers] > Phase = 2 > ISAKMP-peer = local-peers > Local-ID = local-network > Remote-ID = remote-network > #Configuration = ipsec-quick-mode > > [local-network] > ID-type = IPV4_ADDR_SUBNET > Network = 0.0.0.0 > Netmask = 0.0.0.0 > > [remote-network] > ID-type = IPV4_ADDR_SUBNET > Network = 10.10.2.0 > Netmask = 255.255.254.0 > > [isakmp-main-mode] > EXCHANGE_TYPE = ID_PROT > Transforms= 3DES-SHA > > [ipsec-quick-mode] > EXCHANGE_TYPE = QUICK_MODE > > I have a isakmpd.policy of... > > KeyNote-Version: 2 > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && > esp_present == "yes" -> "true"; > > I have tried specifying Tranforms/Suites on ipsec-quick-mode that should > use transport encapsulation, I've even tried tunnel encapsulation to see > if it'll solve it. I've added esp_encapsulation == "transport" to the > policy file, and that hasn't helped either. > > Does anyone have a clue what I'm doing wrong? I sadly know very little > about IPSEC, although I've learnt a lot today. If anyone had any sample > configs of doing this kind of thing, that would be great. Google is some > what lacking in info on this one. > > Many thanks for any help or suggestions! > > Cheers, > > Peter. > > > _______________________________________________ > 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" > >