From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 01:12:47 2004 Return-Path: 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 15C9716A4CE for ; Sun, 4 Apr 2004 01:12:47 -0800 (PST) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82FCE43D5E for ; Sun, 4 Apr 2004 01:12:46 -0800 (PST) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by files.a-quadrat.at (Postfix) with ESMTP id 072575CF39; Sun, 4 Apr 2004 11:12:41 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56110-08; Sun, 4 Apr 2004 11:12:37 +0200 (CEST) Received: from localhost.a-quadrat.at (files.a-quadrat.at [192.168.90.9]) by files.a-quadrat.at (Postfix) with ESMTP id 7C3625C12A; Sun, 4 Apr 2004 11:12:37 +0200 (CEST) Date: Sun, 4 Apr 2004 11:12:36 +0200 (=?ISO-8859-15?Q?Westeurop=E4ische_Sommerzeit?=) From: Michael Bretterklieber To: Omer Faruk Sen In-Reply-To: <20040403202800.72025.qmail@istanbul.enderunix.org> Message-ID: References: <20040403202800.72025.qmail@istanbul.enderunix.org> X-X-Sender: mbretter@localhost.a-quadrat.at MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at a-quadrat.at cc: freebsd-net@freebsd.org Subject: Re: mpd and pptpclient X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 09:12:47 -0000 Hi, On Sat, 3 Apr 2004, Omer Faruk Sen wrote: > > I am trying to use pptpclient but on my mpd server when I try to send > package (such as pinging mpd server) I get those errors on the mpd server. I > have no idea why can that be... Any comments? > > ptp1] rec'd unexpected protocol 0x00b1 on link -1, rejecting > [pptp1] rec'd proto 0xe21d on MP link! (ignoring) > [pptp1] rec'd unexpected protocol 0xa0ab on link -1, rejecting > [pptp1] rec'd unexpected protocol 0x0007 on link -1, rejecting > [pptp1] rec'd unexpected protocol 0x00dd on link -1, rejecting this usualy happens, if the key-material for MPPE is wrong, i.e. one side has generated wrong send/recv keys. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 12:36:58 2004 Return-Path: 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 31CA516A4CE; Sun, 4 Apr 2004 12:36:58 -0700 (PDT) Received: from starburst.demon.co.uk (adsl-02-198.abel.net.uk [193.109.51.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4509D43D46; Sun, 4 Apr 2004 12:36:54 -0700 (PDT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id UAA07933; Sun, 4 Apr 2004 20:38:31 +0100 From: Richard Wendland Message-Id: <200404041938.UAA07933@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Sun, 4 Apr 2004 20:38:31 +0100 (BST) In-Reply-To: <406B3CC0.C277B933@freebsd.org> from "Andre Oppermann" at Mar 31, 2004 11:48:48 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "Jacques A. Vidrine" cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 19:36:58 -0000 > We have the following sysctl's to withstand such an attack: > > net.inet.ip.maxfragpackets [800] > net.inet.ip.maxfragsperpacket [16] > Of course, when the maxfragpackets limit is reached by malicous > packets we are unable to process legitimate fragmented IP packets > until the malicous ones start to time out. There is nothing else > one can do to fight off such an attack. It would be possible to improve matters somewhat by having per-protocol limits. So for TCP, which with MSS and DF rarely fragments, there could be low limits. But for UDP (eg for NFS) which frequently fragments, there could be generous limits. So systems that only permit TCP and ICMP from non-trusted hosts could in an indirect way limit external attack, without eg hampering local UDP. This idea isn't even much of a layer violation, as the fragmentation id value is per protocol, so IP reassembly already takes account of which higher level protocol is involved. It would be reasonable to argue this is too inelegant for only a small improvement; and not worthwhile. What do you think? Taking this approach further would have packet filter rules controlling fragmentation limits. But that's adding a lot of complexity. NB Strictly shouldn't 'maxfragsperpacket' be 'maxfragsperdatagram' :-) Richard -- Richard Wendland richard@wendland.org.uk From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 12:59:56 2004 Return-Path: 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 1E7A416A4CE for ; Sun, 4 Apr 2004 12:59:56 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A767A43D31 for ; Sun, 4 Apr 2004 12:59:55 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i34Jxooq020668; Sun, 4 Apr 2004 15:59:50 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i34JxovK020667; Sun, 4 Apr 2004 15:59:50 -0400 (EDT) (envelope-from barney) Date: Sun, 4 Apr 2004 15:59:50 -0400 From: Barney Wolff To: richard@wendland.org.uk Message-ID: <20040404195950.GA20607@pit.databus.com> References: <406B3CC0.C277B933@freebsd.org> <200404041938.UAA07933@starburst.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404041938.UAA07933@starburst.demon.co.uk> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.39 cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 19:59:56 -0000 On Sun, Apr 04, 2004 at 08:38:31PM +0100, Richard Wendland wrote: > > It would be possible to improve matters somewhat by having per-protocol > limits. So for TCP, which with MSS and DF rarely fragments, there could > be low limits. But for UDP (eg for NFS) which frequently fragments, > there could be generous limits. > > So systems that only permit TCP and ICMP from non-trusted hosts could > in an indirect way limit external attack, without eg hampering local UDP. I'd prefer either per-interface limits or a trusted/non-trusted per-interface bit, if anything at all. Per-protocol limits would simply cause the attackers to attack the other protocol. In truth, running NFS over UDP with 65k packets over the Internet is suicidal anyway. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 14:18:08 2004 Return-Path: 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 8FB0116A4CE for ; Sun, 4 Apr 2004 14:18:08 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 26D0C43D39 for ; Sun, 4 Apr 2004 14:18:08 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 99474 invoked from network); 4 Apr 2004 21:18:07 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 4 Apr 2004 21:18:07 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 4 Apr 2004 16:18:05 -0500 (CDT) From: Mike Silbersack To: Barney Wolff In-Reply-To: <20040404195950.GA20607@pit.databus.com> Message-ID: <20040404160909.D29958@odysseus.silby.com> References: <406B3CC0.C277B933@freebsd.org> <200404041938.UAA07933@starburst.demon.co.uk> <20040404195950.GA20607@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: richard@wendland.org.uk Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 21:18:08 -0000 On Sun, 4 Apr 2004, Barney Wolff wrote: > On Sun, Apr 04, 2004 at 08:38:31PM +0100, Richard Wendland wrote: > > > > It would be possible to improve matters somewhat by having per-protocol > > limits. So for TCP, which with MSS and DF rarely fragments, there could > > be low limits. But for UDP (eg for NFS) which frequently fragments, > > there could be generous limits. > > > > So systems that only permit TCP and ICMP from non-trusted hosts could > > in an indirect way limit external attack, without eg hampering local UDP. > > I'd prefer either per-interface limits or a trusted/non-trusted per-interface > bit, if anything at all. Per-protocol limits would simply cause the > attackers to attack the other protocol. In truth, running NFS over UDP > with 65k packets over the Internet is suicidal anyway. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf Per-protocol limits _could_ have some advantages; the 16 frags per packet limit was chosen to account for NFS over UDP. For TCP, we could drop that to 3 frags per packet, allowing more packets within the same amount of mbuf clusters. But, as you point out, that really won't make much of a difference overall. I think that per-interface or perhaps per-trusted hosts (trust hosts that we have had legitimate tcp sessions with?) would be a good improvement, but it's a lot of work. An improvement which I had considered last year when I implemented the per-packet frag limits was doing coalescing of fragments as they arrived, changing the limit from "fragments per packet" to "holes per packet". This would negate any attack which relied upon using the fact that even 8 byte fragments eat up an entire mbuf cluster. However, under a high bandwidth attack, this improvement would still not really help legitimate hosts get through, so I haven't spent time implementing it. Yeah, limits as you suggest are probably the only good way, IP fragmentation was implemented in a way that just encourages DoS attacks. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 14:27:35 2004 Return-Path: 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 0BC8D16A4CE for ; Sun, 4 Apr 2004 14:27:35 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94BD043D39 for ; Sun, 4 Apr 2004 14:27:34 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (sccrmhc11) with SMTP id <2004040421273301100c8is9e>; Sun, 4 Apr 2004 21:27:33 +0000 Message-Id: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Sun, 04 Apr 2004 15:27:41 -0600 To: freebsd-net@freebsd.org From: Brandon Erhart Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 21:27:35 -0000 Hello everyone, I am writing a network application that mirrors a given website (such as a suped-up "wget"). I use a lot of FDs, and was getting connect() errors when I would run out of local_ip:local_port tuples. I lowered the MSL so that TIME_WAIT would timeout very quick (yes, I know, this is "bad", but I'm going for sheer speed here), and it alleviated the problem a bit. However, I have run into a new problem. I am getting a good amount of blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a long while. I have been unable to find must information on a timeout for these states. I came across a small patch that modified tcp_timer.c in /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: if (tp->t_state != TCPS_TIME_WAIT && to if (tp->t_state < FIN_WAIT_2 && I also tried changing that to ".. <= FIN_WAIT_2 .." However, I still end up with quite a few stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK after the program exits (and whilst the program is running of course). They don't seem to timeout in the same interval that TIME_WAIT does. Any ideas? Did I modify the right piece of code? I was told to post here as you all would more than likely know! I am stumped. Thank you all in advance, Brandon From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 14:54:55 2004 Return-Path: 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 AA83216A4CE for ; Sun, 4 Apr 2004 14:54:55 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4792143D2D for ; Sun, 4 Apr 2004 14:54:55 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Sun, 4 Apr 2004 17:54:54 -0400 Message-ID: From: Don Bowman To: 'Brandon Erhart' , freebsd-net@freebsd.org Date: Sun, 4 Apr 2004 17:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 21:54:55 -0000 From: Brandon Erhart [mailto:berhart@ErhartGroup.COM] > Hello everyone, > > I am writing a network application that mirrors a given > website (such as a > suped-up "wget"). I use a lot of FDs, and was getting > connect() errors when > I would run out of local_ip:local_port tuples. I lowered the > MSL so that > TIME_WAIT would timeout very quick (yes, I know, this is > "bad", but I'm > going for sheer speed here), and it alleviated the problem a bit. > > However, I have run into a new problem. I am getting a good amount of > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick > around for a > long while. I have been unable to find must information on a > timeout for > these states. I came across a small patch that modified > tcp_timer.c in > /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: > > if (tp->t_state != TCPS_TIME_WAIT && > > to > > if (tp->t_state < FIN_WAIT_2 && > > I also tried changing that to ".. <= FIN_WAIT_2 .." > > However, I still end up with quite a few stuck in FIN_WAIT_1, > FIN_WAIT_2 or > LAST_ACK after the program exits (and whilst the program is > running of > course). They don't seem to timeout in the same interval that > TIME_WAIT does. > > Any ideas? Did I modify the right piece of code? I was told > to post here as > you all would more than likely know! > Perhaps you want to lower net.inet.tcp.msl sysctl? From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 14:58:18 2004 Return-Path: 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 D4E9716A4CE for ; Sun, 4 Apr 2004 14:58:18 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 972EF43D49 for ; Sun, 4 Apr 2004 14:58:18 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (sccrmhc12) with SMTP id <20040404215817012002ki4me>; Sun, 4 Apr 2004 21:58:17 +0000 Message-Id: <6.0.2.0.2.20040404155725.01c90c10@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Sun, 04 Apr 2004 15:58:25 -0600 To: Don Bowman From: Brandon Erhart In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: RE: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 21:58:18 -0000 Don, I have lowered the MSL .. please note what I said in my original post. This seems to have no effect on FIN_WAIT_[1,2] nor LAST_ACK. At 03:54 PM 4/4/2004, you wrote: >From: Brandon Erhart [mailto:berhart@ErhartGroup.COM] > > Hello everyone, > > > > I am writing a network application that mirrors a given > > website (such as a > > suped-up "wget"). I use a lot of FDs, and was getting > > connect() errors when > > I would run out of local_ip:local_port tuples. I lowered the > > MSL so that > > TIME_WAIT would timeout very quick (yes, I know, this is > > "bad", but I'm > > going for sheer speed here), and it alleviated the problem a bit. > > > > However, I have run into a new problem. I am getting a good amount of > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick > > around for a > > long while. I have been unable to find must information on a > > timeout for > > these states. I came across a small patch that modified > > tcp_timer.c in > > /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: > > > > if (tp->t_state != TCPS_TIME_WAIT && > > > > to > > > > if (tp->t_state < FIN_WAIT_2 && > > > > I also tried changing that to ".. <= FIN_WAIT_2 .." > > > > However, I still end up with quite a few stuck in FIN_WAIT_1, > > FIN_WAIT_2 or > > LAST_ACK after the program exits (and whilst the program is > > running of > > course). They don't seem to timeout in the same interval that > > TIME_WAIT does. > > > > Any ideas? Did I modify the right piece of code? I was told > > to post here as > > you all would more than likely know! > > > >Perhaps you want to lower net.inet.tcp.msl sysctl? From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:03:11 2004 Return-Path: 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 EC20C16A4CE for ; Sun, 4 Apr 2004 15:03:11 -0700 (PDT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D3D743D39 for ; Sun, 4 Apr 2004 15:03:09 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040404220308.EEIR6671.out003.verizon.net@mac.com>; Sun, 4 Apr 2004 17:03:08 -0500 Message-ID: <4070860F.6030701@mac.com> Date: Sun, 04 Apr 2004 18:02:55 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.160.247.127] at Sun, 4 Apr 2004 17:03:08 -0500 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:03:12 -0000 Brandon Erhart wrote: > I am writing a network application that mirrors a given website (such as > a suped-up "wget"). I use a lot of FDs, and was getting connect() errors > when I would run out of local_ip:local_port tuples. I lowered the MSL so > that TIME_WAIT would timeout very quick (yes, I know, this is "bad", but > I'm going for sheer speed here), and it alleviated the problem a bit. > > However, I have run into a new problem. I am getting a good amount of > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for > a long while. I have been unable to find must information on a timeout > for these states. Well, these are defined in RFC-791 (aka STD-5). If you want to mirror the content of a given website rapidly, a good approach would be to use a tool like rsync and duplicate the changed portions at the filesystem level rather than mirroring via HTTP requests. It would also be the case that using HTTP/1.1 pipelining ought to greatly reduce the number of new connections you need to open, which ought to speed up your program significantly while reducing load on the servers you're mirroring. Since I've given some helpful advice (or so I think :-), perhaps you'll be willing to listen to a word of caution: if your client is pushing so hard that it exhausts the local machine's resources, you're very probably doing something that reasonable website administrators would consider to be abusive and you may cause denial-of-service conditions for other users of that site. Does your tool pay attention to /robots.txt? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:07:31 2004 Return-Path: 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 1476816A4D0 for ; Sun, 4 Apr 2004 15:07:31 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id C951B43D5C for ; Sun, 4 Apr 2004 15:07:30 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (sccrmhc11) with SMTP id <2004040422072901100c5c9ve>; Sun, 4 Apr 2004 22:07:30 +0000 Message-Id: <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Sun, 04 Apr 2004 16:07:38 -0600 To: Chuck Swiger From: Brandon Erhart In-Reply-To: <4070860F.6030701@mac.com> References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:07:31 -0000 Yes, it pays attention to /robots.txt. But, I am writing my own -- I don't want to use rsync, wget, anything like that. This is part of an archiving project, and it uses so many FDs because it has tons of connections opened to DIFFERENT servers at different times .. not just one site. Any advice on the timeouts? I don't really care about the RFC , honestly :-P. Like I said, I'm going for sheer speed. Brandon At 04:02 PM 4/4/2004, you wrote: >Brandon Erhart wrote: >>I am writing a network application that mirrors a given website (such as >>a suped-up "wget"). I use a lot of FDs, and was getting connect() errors >>when I would run out of local_ip:local_port tuples. I lowered the MSL so >>that TIME_WAIT would timeout very quick (yes, I know, this is "bad", but >>I'm going for sheer speed here), and it alleviated the problem a bit. >>However, I have run into a new problem. I am getting a good amount of >>blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for >>a long while. I have been unable to find must information on a timeout >>for these states. > >Well, these are defined in RFC-791 (aka STD-5). > >If you want to mirror the content of a given website rapidly, a good >approach would be to use a tool like rsync and duplicate the changed >portions at the filesystem level rather than mirroring via HTTP requests. > >It would also be the case that using HTTP/1.1 pipelining ought to greatly >reduce the number of new connections you need to open, which ought to >speed up your program significantly while reducing load on the servers >you're mirroring. > >Since I've given some helpful advice (or so I think :-), perhaps you'll be >willing to listen to a word of caution: if your client is pushing so hard >that it exhausts the local machine's resources, you're very probably doing >something that reasonable website administrators would consider to be >abusive and you may cause denial-of-service conditions for other users of >that site. > >Does your tool pay attention to /robots.txt? > >-- >-Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:26:45 2004 Return-Path: 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 AFFA816A4CE for ; Sun, 4 Apr 2004 15:26:45 -0700 (PDT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C58643D1D for ; Sun, 4 Apr 2004 15:26:45 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040404222644.FMEC29216.out009.verizon.net@mac.com>; Sun, 4 Apr 2004 17:26:44 -0500 Message-ID: <40708B96.4050905@mac.com> Date: Sun, 04 Apr 2004 18:26:30 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.160.247.127] at Sun, 4 Apr 2004 17:26:44 -0500 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:26:45 -0000 Brandon Erhart wrote: [ ... ] > Any advice on the timeouts? I don't really care about the RFC , honestly > :-P. Like I said, I'm going for sheer speed. My advice was to read the RFC as it contains significant discussion about these timeouts, but you're free to disregard it if you please. In particular, the discussion of FIN/ACK handling is relevant, since a TCP implementation ought to move through the various FIN_WAIT states rapidly if both sides agree to close and don't have more data to send. Using tcpdump to verify what's going on might help you figure out why the connections are lingering around... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:31:04 2004 Return-Path: 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 69B3616A4CE for ; Sun, 4 Apr 2004 15:31:04 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB92043D3F for ; Sun, 4 Apr 2004 15:31:01 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (sccrmhc11) with SMTP id <2004040422310001100c1gq4e>; Sun, 4 Apr 2004 22:31:01 +0000 Message-Id: <6.0.2.0.2.20040404163034.01c82c80@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Sun, 04 Apr 2004 16:31:09 -0600 To: Chuck Swiger From: Brandon Erhart In-Reply-To: <40708B96.4050905@mac.com> References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> <40708B96.4050905@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:31:04 -0000 I want to explicitly get it out of those states, without any help from the other end. What must I modify to achieve this? Brandon At 04:26 PM 4/4/2004, you wrote: >Brandon Erhart wrote: >[ ... ] >>Any advice on the timeouts? I don't really care about the RFC , honestly >>:-P. Like I said, I'm going for sheer speed. > >My advice was to read the RFC as it contains significant discussion about >these timeouts, but you're free to disregard it if you please. > >In particular, the discussion of FIN/ACK handling is relevant, since a TCP >implementation ought to move through the various FIN_WAIT states rapidly >if both sides agree to close and don't have more data to send. Using >tcpdump to verify what's going on might help you figure out why the >connections are lingering around... > >-- >-Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:32:12 2004 Return-Path: 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 AC20516A4CE for ; Sun, 4 Apr 2004 15:32:12 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A12943D5A for ; Sun, 4 Apr 2004 15:32:12 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 13406 invoked from network); 4 Apr 2004 22:32:10 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 4 Apr 2004 22:32:10 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 4 Apr 2004 17:32:09 -0500 (CDT) From: Mike Silbersack To: Brandon Erhart In-Reply-To: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> Message-ID: <20040404172904.M33929@odysseus.silby.com> References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:32:12 -0000 On Sun, 4 Apr 2004, Brandon Erhart wrote: > Hello everyone, > > I am writing a network application that mirrors a given website (such as a > suped-up "wget"). I use a lot of FDs, and was getting connect() errors when > I would run out of local_ip:local_port tuples. I lowered the MSL so that > TIME_WAIT would timeout very quick (yes, I know, this is "bad", but I'm > going for sheer speed here), and it alleviated the problem a bit. In 5.2, I added code which automatically recycles TIME_WAIT sockets so that this problem doesn't happen. That's one possible solution that that sub-problem, but as you've solved it with the msl change it's hardly a large enough reason to change. > However, I have run into a new problem. I am getting a good amount of > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > long while. I have been unable to find must information on a timeout for > these states. I came across a small patch that modified tcp_timer.c in > /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: If you can recreate this problem frequently, could you try capturing a connection "hanging" with tcpdump? Perhaps there is a problem in our TCP state engine that needs to be fixed. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:46:26 2004 Return-Path: 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 797EB16A4CE for ; Sun, 4 Apr 2004 15:46:26 -0700 (PDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F9D43D46 for ; Sun, 4 Apr 2004 15:46:26 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040404224625.USWB18295.out012.verizon.net@mac.com>; Sun, 4 Apr 2004 17:46:25 -0500 Message-ID: <40709033.9010301@mac.com> Date: Sun, 04 Apr 2004 18:46:11 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> <40708B96.4050905@mac.com> <6.0.2.0.2.20040404163034.01c82c80@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040404163034.01c82c80@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [68.160.247.127] at Sun, 4 Apr 2004 17:46:25 -0500 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:46:26 -0000 Brandon Erhart wrote: > I want to explicitly get it out of those states, without any help from > the other end. What must I modify to achieve this? See tcp_usrclosed() in /usr/src/sys/netinet/tcp_usrreq.c. Replace that code with something like (untested): tp->t_state = TCPS_CLOSED; tp = tcp_close(tp); return tp; ...and you'll break your TCP/IP stack in the fashion you've asked for. If other things break too, you can keep all of the pieces. :-) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 16:10:41 2004 Return-Path: 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 3969016A4CE for ; Sun, 4 Apr 2004 16:10:41 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AB043D2D for ; Sun, 4 Apr 2004 16:10:41 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (rwcrmhc11) with SMTP id <200404042310400130011t2me>; Sun, 4 Apr 2004 23:10:40 +0000 Message-Id: <6.0.2.0.2.20040404171017.01c764d8@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Sun, 04 Apr 2004 17:10:48 -0600 To: Chuck Swiger From: Brandon Erhart In-Reply-To: <40709033.9010301@mac.com> References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> <40708B96.4050905@mac.com> <6.0.2.0.2.20040404163034.01c82c80@mx1.erhartgroup.com> <40709033.9010301@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 23:10:41 -0000 Chuck, That worked perfectly :) Thank you all so much for your help. I'm sure I'll be back with more questions during the course of this project! Brandon At 04:46 PM 4/4/2004, you wrote: >Brandon Erhart wrote: >>I want to explicitly get it out of those states, without any help from >>the other end. What must I modify to achieve this? > >See tcp_usrclosed() in /usr/src/sys/netinet/tcp_usrreq.c. Replace that >code with something like (untested): > > tp->t_state = TCPS_CLOSED; > tp = tcp_close(tp); > return tp; > >...and you'll break your TCP/IP stack in the fashion you've asked for. >If other things break too, you can keep all of the pieces. :-) > >-- >-Chuck > From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 19:56:58 2004 Return-Path: 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 493F016A4CF for ; Sun, 4 Apr 2004 19:56:58 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F8A043D5C for ; Sun, 4 Apr 2004 19:56:56 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i352ujio021169; Mon, 5 Apr 2004 10:56:50 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4070CAC9.92AD0256@kuzbass.ru> Date: Mon, 05 Apr 2004 10:56:09 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Andrey Alekseyev References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: nfs_getpages: error 70 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 02:56:58 -0000 Andrey Alekseyev wrote: > > > I've applied both patches (and defined Z_NFS_EXTENSIONS). > > It does not help. How do I handle it? > > Did you set open_retry_stale sysctl to 1? It does not help too. Moreover, httpd childs sometimes die with SIGSEGV now. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 01:56:08 2004 Return-Path: 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 D31B016A4CE for ; Mon, 5 Apr 2004 01:56:08 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA6C43D5F for ; Mon, 5 Apr 2004 01:56:04 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i358ttiJ045633; Mon, 5 Apr 2004 16:55:59 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40711F0F.AEED33CF@kuzbass.ru> Date: Mon, 05 Apr 2004 16:55:43 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Andrey Alekseyev References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: nfs_getpages: error 70 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 08:56:08 -0000 Andrey Alekseyev wrote: > > > It does not help too. Moreover, httpd childs sometimes die with > > SIGSEGV now. > > Sorry :) Are you still using Apache with mmap for reading files > over NFS? :) I'm afraid my patch isn't compatible with the > mmap issues... Well, I think Apache uses mmap. Eugene From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 02:35:37 2004 Return-Path: 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 98DA816A4CE for ; Mon, 5 Apr 2004 02:35:37 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91DE143D60 for ; Mon, 5 Apr 2004 02:35:36 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i359ZR0i051003; Mon, 5 Apr 2004 17:35:28 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40712853.24DD5875@kuzbass.ru> Date: Mon, 05 Apr 2004 17:35:15 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Andrey Alekseyev , net@freebsd.org References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: Re: nfs_getpages: error 70 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 09:35:38 -0000 Andrey Alekseyev wrote: > > > Well, I think Apache uses mmap. > > Back in time there was a discussion between you and Matt Dillon > about your NFS-based environment, Apache, mmap and NFS > inconsistencies. Do you remember? :) Of course. These are the same Apache and NFS server and the same html file. > If you ever try Apache w/o mmap() for reading files, let > me know whether my open_retry_stale modification solves your > problem.... I'm afraid I could not find time to dig. Most probably, I will place a limit to the frequency of updating server's file. But who knows... Anyway, thanks for your efforts. Sometimes I'll try. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 06:13:10 2004 Return-Path: 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 90D4616A4CE for ; Mon, 5 Apr 2004 06:13:10 -0700 (PDT) Received: from ACSV12.aimccf.net (mail22.aimccf.net [212.11.24.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9109243D1D for ; Mon, 5 Apr 2004 06:13:09 -0700 (PDT) (envelope-from spetit@selectbourse.com) Received: from sdef-dsi-117.bum.sub.fr.hsbc (unverified [10.79.10.67]) by ACSV12.aimccf.net (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Mon, 5 Apr 2004 15:13:23 +0200 Received: from fr0010090585 ([10.39.10.188]) by sdef-dsi-117.bum.sub.fr.hsbc; Mon, 05 Apr 2004 15:06:46 +0200 Message-ID: <003b01c41b0f$b1e4fc90$bc0a270a@bum.sub.fr.hsbc> From: "Sebastien Petit" To: Date: Mon, 5 Apr 2004 15:12:49 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: SOCK_RAW sockets and IPPROTO_AH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 13:13:10 -0000 Hi, Is there a way to receive AH packets in userland with a SOCK_RAW socket ? ie: socket(AF_INET, SOCK_RAW, IPPROTO_AH) ? I found that this socket call doesn't work under FreeBSD. On OpenBSD, it wo= rks but a recvfrom/read doesn't return any AH packets when it was received = on an interface. Is there another proper way to receive AH packets in Userland under FreeBSD= ? (bpf/pcap is not a solution because I want to have a socket opened for m= ulticast join) Any help will be appreciated. Regards, Sebastien. --=20 spetit@selectbourse.com spe@selectbourse.net FreeVRRPd project http://www.b0l.org/ Les informations contenues dans ce message sont confidentielles et peuvent = constituer des informations privilegiees. Si vous n etes pas le destinatair= e de ce message, il vous est interdit de le copier, de le faire suivre, de = le divulguer ou d en utiliser tout ou partie. Si vous avez recu ce message = par erreur, merci de le supprimer de votre systeme, ainsi que toutes ses co= pies, et d en avertir immediatement l expediteur par message de retour.. Il est impossible de garantir que les communications par messagerie electro= nique arrivent en temps utile, sont securisees ou denuees de toute erreur o= u virus. En consequence, l expediteur n accepte aucune responsabilite du fa= it des erreurs ou omissions qui pourraient en resulter. --- ----------------------------------------------------- --- The information contained in this e-mail is confidential. It may also be le= gally privileged. If you are not the addressee you may not copy, forward, d= isclose or use any part of it. If you have received this message in error, = please delete it and all copies from your system and notify the sender imme= diately by return e-mail. E-mail communications cannot be guaranteed to be timely secure, error or vi= rus-free. The sender does not accept liability for any errors or omissions = which arise as a result. From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 06:14:29 2004 Return-Path: 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 880DA16A4CE for ; Mon, 5 Apr 2004 06:14:29 -0700 (PDT) Received: from mailhost.packetfront.com (mailhost.packetfront.com [212.247.6.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67BE843D31 for ; Mon, 5 Apr 2004 06:14:28 -0700 (PDT) (envelope-from anders.lowinger@packetfront.com) Received: from [212.247.6.198] (helo=maillab.packetfront.com) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 1BAQVZ-00070q-00; Mon, 05 Apr 2004 11:35:09 +0200 Received: from packetfront.com (unknown [192.168.1.194]) by maillab.packetfront.com (Postfix) with ESMTP id 28BCA73B6C; Mon, 5 Apr 2004 11:44:47 +0200 (CEST) Message-ID: <40712A8F.9000704@packetfront.com> Date: Mon, 05 Apr 2004 11:44:47 +0200 From: Anders Lowinger User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20040331005914.A6934@xorpc.icir.org> In-Reply-To: <20040331005914.A6934@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 13:14:29 -0000 Luigi Rizzo wrote: > Hi, > i was wondering if anyone knows what kind of support we have > in FreeBSD networking code, for non contiguous netmasks. > While it is trivial to support them for interface addresses, > managing them in the routing table is probably far from trivial > and I believe also mostly useless... and anyways, i have no > idea how our kernel code deals with them Not sure why you wonder? Do you need it? If we implement a mtrie for faster routing-lookups, non-contiguous masks need to go. Not even Cisco implements anything else than contiguous masks, and I have a very hard time to understand why they are needed. /Anders From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 06:41:31 2004 Return-Path: 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 178C416A4D1 for ; Mon, 5 Apr 2004 06:41:31 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E63C43D41 for ; Mon, 5 Apr 2004 06:41:30 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 15076 invoked from network); 5 Apr 2004 13:41:29 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2004 13:41:29 -0000 Message-ID: <40716208.808CF084@freebsd.org> Date: Mon, 05 Apr 2004 15:41:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Lowinger References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 13:41:31 -0000 Anders Lowinger wrote: > > Luigi Rizzo wrote: > > Hi, > > i was wondering if anyone knows what kind of support we have > > in FreeBSD networking code, for non contiguous netmasks. > > While it is trivial to support them for interface addresses, > > managing them in the routing table is probably far from trivial > > and I believe also mostly useless... and anyways, i have no > > idea how our kernel code deals with them > > Not sure why you wonder? Do you need it? > > If we implement a mtrie for faster routing-lookups, > non-contiguous masks need to go. > > Not even Cisco implements anything else than contiguous masks, > and I have a very hard time to understand why they are needed. So far I haven't found any useful application of non-contignous mask in network applications. It can probably go away. But step by step. Currently Luigi has teamed up with me to do the per-if ARP table stuff and the removal of cloning from the routing table. That alone will make network life in the kernel much easier. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 07:02:54 2004 Return-Path: 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 950AA16A4CE for ; Mon, 5 Apr 2004 07:02:54 -0700 (PDT) Received: from mta1.adelphia.net (mta1.adelphia.net [68.168.78.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49F0A43D41 for ; Mon, 5 Apr 2004 07:02:54 -0700 (PDT) (envelope-from rneese@adelphia.net) Received: from 69-160-8-12.bflony.adelphia.net ([69.160.8.12]) by mta13.adelphia.netESMTP <20040405123259.KKVL13425.mta13.adelphia.net@69-160-8-12.bflony.adelphia.net> for ; Mon, 5 Apr 2004 08:32:59 -0400 From: Richard Neese To: net@freebsd.org Date: Mon, 5 Apr 2004 08:33:02 -0400 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200404050833.03295.rneese@adelphia.net> Subject: Driver porting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 14:02:54 -0000 can any of the driver writers or porters help with porting the atw driver from netbsd to freebsd. this is for the admtek 802.11b network based cards. From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 10:18:00 2004 Return-Path: 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 9193116A4CE for ; Mon, 5 Apr 2004 10:18:00 -0700 (PDT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DADC43D2D for ; Mon, 5 Apr 2004 10:18:00 -0700 (PDT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id 3670A7802; Mon, 5 Apr 2004 10:18:00 -0700 (PDT) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 24C227804; Mon, 5 Apr 2004 10:17:57 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id CBE7C7802; Mon, 5 Apr 2004 10:17:56 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 90E3BF8F2; Mon, 5 Apr 2004 10:17:56 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Brandon Erhart In-Reply-To: Message from Brandon Erhart <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1837888328P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 05 Apr 2004 10:17:56 -0700 From: Eli Dart Message-Id: <20040405171756.90E3BF8F2@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 17:18:00 -0000 --==_Exmh_-1837888328P Content-Type: text/plain; charset=us-ascii In reply to Brandon Erhart : > Hello everyone, > However, I have run into a new problem. I am getting a good amount of > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > long while. Could you define "long" in this case? Are we talking about 60 seconds, or 60 minutes? I get the feeling that your requirements might make your perception of "long" different from others' notion of "long." The reason I ask is that there was a bug once upon a time that made some connections stick in LAST_ACK forever.... --eli --==_Exmh_-1837888328P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFAcZTELTFEeF+CsrMRAj/4AJ4nBm39rFmQ1e2u/Mgn0Ps8loHA8wCePU0z 3vpA2mlgN2fDIIahrArwYrs= =Vgbu -----END PGP SIGNATURE----- --==_Exmh_-1837888328P-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 11:01:37 2004 Return-Path: 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 A36EF16A4CE for ; Mon, 5 Apr 2004 11:01:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8555443D48 for ; Mon, 5 Apr 2004 11:01:37 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i35I1bbv069795 for ; Mon, 5 Apr 2004 11:01:37 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i35I1a8j069789 for freebsd-net@freebsd.org; Mon, 5 Apr 2004 11:01:36 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 5 Apr 2004 11:01:36 -0700 (PDT) Message-Id: <200404051801.i35I1a8j069789@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 18:01:37 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 12:32:43 2004 Return-Path: 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 F020116A4CE for ; Mon, 5 Apr 2004 12:32:43 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 812B343D4C for ; Mon, 5 Apr 2004 12:32:43 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (sccrmhc12) with SMTP id <20040405193242012002iicie>; Mon, 5 Apr 2004 19:32:42 +0000 Message-Id: <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Mon, 05 Apr 2004 13:32:49 -0600 To: Eli Dart From: Brandon Erhart In-Reply-To: <20040405171756.90E3BF8F2@gemini.nersc.gov> References: <20040405171756.90E3BF8F2@gemini.nersc.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 19:32:44 -0000 Well, I responded to the group that I had taken one of the fellows advice posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c. So all is well -- it gets TCPS_CLOSED state and the tcps_close() function called on the tuple IMMEDIATELY. It doesn't switch states depending on which state the connection is currently in. I also made a sysctl variable for it (to turn the "feature" on or off), and will post the small patch along w/ some other small changes I have made soon. Thanks, Brandon At 11:17 AM 4/5/2004, you wrote: >In reply to Brandon Erhart : > > > Hello everyone, > > > However, I have run into a new problem. I am getting a good amount of > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > > long while. > >Could you define "long" in this case? Are we talking about 60 >seconds, or 60 minutes? I get the feeling that your requirements >might make your perception of "long" different from others' notion of >"long." > >The reason I ask is that there was a bug once upon a time that made >some connections stick in LAST_ACK forever.... > > --eli > > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 13:10:56 2004 Return-Path: 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 96F8A16A4CE for ; Mon, 5 Apr 2004 13:10:56 -0700 (PDT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858C643D2D for ; Mon, 5 Apr 2004 13:10:56 -0700 (PDT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id 52EBF7773; Mon, 5 Apr 2004 13:10:56 -0700 (PDT) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 814B97802; Mon, 5 Apr 2004 13:10:52 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id E88CB7773; Mon, 5 Apr 2004 13:10:50 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id D5B2EF8F2; Mon, 5 Apr 2004 13:10:50 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Brandon Erhart In-Reply-To: Message from Brandon Erhart <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1956043834P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 05 Apr 2004 13:10:50 -0700 From: Eli Dart Message-Id: <20040405201050.D5B2EF8F2@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 20:10:56 -0000 --==_Exmh_-1956043834P Content-Type: text/plain; charset=us-ascii In reply to Brandon Erhart : > Well, I responded to the group that I had taken one of the fellows advice > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c. I understand that -- I was trying to discover if you'd come across something that needed a more general fix (see note from Mike Silbersack). If your application can't wait for whatever the standard timeout is, that's fine -- you've got your fix, and you're good to go. However, if there is a problem with connections hanging out forever in the process of closing, that something that might be good to look at independently. So, do you remember how long the "problem connections" were sticking around in FIN_WAIT_? or LAST_ACK? Are we talking seconds, minutes, hours, days? Thanks, --eli > > So all is well -- it gets TCPS_CLOSED state and the tcps_close() function > called on the tuple IMMEDIATELY. It doesn't switch states depending on > which state the connection is currently in. I also made a sysctl variable > for it (to turn the "feature" on or off), and will post the small patch > along w/ some other small changes I have made soon. > > Thanks, > > Brandon > > At 11:17 AM 4/5/2004, you wrote: > > >In reply to Brandon Erhart : > > > > > Hello everyone, > > > > > However, I have run into a new problem. I am getting a good amount of > > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > > > long while. > > > >Could you define "long" in this case? Are we talking about 60 > >seconds, or 60 minutes? I get the feeling that your requirements > >might make your perception of "long" different from others' notion of > >"long." > > > >The reason I ask is that there was a bug once upon a time that made > >some connections stick in LAST_ACK forever.... > > > > --eli > > > > > > > --==_Exmh_-1956043834P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFAcb1KLTFEeF+CsrMRAioFAJ4t/qpNiTuq1oIBXJBeKhpsFJp2vACdEm4p mHfzleA1edTD8cE1d70U744= =Tqw9 -----END PGP SIGNATURE----- --==_Exmh_-1956043834P-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 13:28:08 2004 Return-Path: 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 12EA716A4E2 for ; Mon, 5 Apr 2004 13:28:08 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81AC943D5F for ; Mon, 5 Apr 2004 13:28:02 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <200404052028010130013u80e>; Mon, 5 Apr 2004 20:28:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA22684; Mon, 5 Apr 2004 13:28:00 -0700 (PDT) Date: Mon, 5 Apr 2004 13:27:58 -0700 (PDT) From: Julian Elischer To: Eli Dart In-Reply-To: <20040405201050.D5B2EF8F2@gemini.nersc.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brandon Erhart cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 20:28:08 -0000 On Mon, 5 Apr 2004, Eli Dart wrote: > > In reply to Brandon Erhart : > > > Well, I responded to the group that I had taken one of the fellows advice > > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c. > > > I understand that -- I was trying to discover if you'd come across > something that needed a more general fix (see note from Mike > Silbersack). If your application can't wait for whatever the > standard timeout is, that's fine -- you've got your fix, and you're > good to go. However, if there is a problem with connections hanging > out forever in the process of closing, that something that might be > good to look at independently. > > So, do you remember how long the "problem connections" were sticking > around in FIN_WAIT_? or LAST_ACK? Are we talking seconds, minutes, > hours, days? > > Thanks, On the topic of Session shutdown... I have noticed an increasing number of machines on the net are terminating their session (usually the server, but not always) with a RESET packet instead of a FIN packet. In particular it seems that if the machine in question recieves a FIN packet, and has no more data to send, it replies with a RESET. I don't know what kind of machines this is but next time I see it I guess I'll look at it harder. Julian From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 15:02:54 2004 Return-Path: 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 2054516A4CE for ; Mon, 5 Apr 2004 15:02:54 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D4E43D41 for ; Mon, 5 Apr 2004 15:02:53 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 72077 invoked from network); 5 Apr 2004 22:02:52 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2004 22:02:52 -0000 Message-ID: <4071D78C.9B03AEA1@freebsd.org> Date: Tue, 06 Apr 2004 00:02:52 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brandon Erhart References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 22:02:54 -0000 Brandon Erhart wrote: > > Hello everyone, > > I am writing a network application that mirrors a given website (such as a > suped-up "wget"). I use a lot of FDs, and was getting connect() errors when > I would run out of local_ip:local_port tuples. I lowered the MSL so that > TIME_WAIT would timeout very quick (yes, I know, this is "bad", but I'm > going for sheer speed here), and it alleviated the problem a bit. You should enlarge the local port space especially on 4.9: sysctl -w net.inet.ip.portrange.hifirst=10000 sysctl -w net.inet.ip.portrange.hilast=65535 Normal is 49152 which give you only 16383 ports to choose from. And with the number of connections you have you're running of them because of the TIME_WAIT states. -- Andre > However, I have run into a new problem. I am getting a good amount of > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > long while. I have been unable to find must information on a timeout for > these states. I came across a small patch that modified tcp_timer.c in > /usr/src/sys/netinet. It changed line #484 (in FreeBSD 4.9-REL) from: > > if (tp->t_state != TCPS_TIME_WAIT && > > to > > if (tp->t_state < FIN_WAIT_2 && > > I also tried changing that to ".. <= FIN_WAIT_2 .." > > However, I still end up with quite a few stuck in FIN_WAIT_1, FIN_WAIT_2 or > LAST_ACK after the program exits (and whilst the program is running of > course). They don't seem to timeout in the same interval that TIME_WAIT does. > > Any ideas? Did I modify the right piece of code? I was told to post here as > you all would more than likely know! > > I am stumped. > > Thank you all in advance, > > Brandon > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 15:09:41 2004 Return-Path: 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 B7C5E16A4CE for ; Mon, 5 Apr 2004 15:09:41 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE34643D53 for ; Mon, 5 Apr 2004 15:09:40 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 72460 invoked from network); 5 Apr 2004 22:09:39 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2004 22:09:39 -0000 Message-ID: <4071D923.A7E0D93F@freebsd.org> Date: Tue, 06 Apr 2004 00:09:39 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brandon Erhart References: <20040405171756.90E3BF8F2@gemini.nersc.gov> <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 22:09:41 -0000 Brandon Erhart wrote: > > Well, I responded to the group that I had taken one of the fellows advice > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c. > > So all is well -- it gets TCPS_CLOSED state and the tcps_close() function > called on the tuple IMMEDIATELY. It doesn't switch states depending on > which state the connection is currently in. I also made a sysctl variable > for it (to turn the "feature" on or off), and will post the small patch > along w/ some other small changes I have made soon. As far as I am aware (I was looking through and testing the FIN_WAIT states in 5.2 around last christmas) our TCP stack is behaving correctly. Do the FIN_WAIT_1|2 and LAST_ACK time out after 2MSL or do they stick around forever? If they stick around forever, then there is something broken. But I suspect you are just running out of the small space of local ports with your application as I said in the previous email. -- Andre > Thanks, > > Brandon > > At 11:17 AM 4/5/2004, you wrote: > > >In reply to Brandon Erhart : > > > > > Hello everyone, > > > > > However, I have run into a new problem. I am getting a good amount of > > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick around for a > > > long while. > > > >Could you define "long" in this case? Are we talking about 60 > >seconds, or 60 minutes? I get the feeling that your requirements > >might make your perception of "long" different from others' notion of > >"long." > > > >The reason I ask is that there was a bug once upon a time that made > >some connections stick in LAST_ACK forever.... > > > > --eli > > > > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 15:14:50 2004 Return-Path: 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 97B7A16A4CE for ; Mon, 5 Apr 2004 15:14:50 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D5C643D4C for ; Mon, 5 Apr 2004 15:14:50 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 72766 invoked from network); 5 Apr 2004 22:14:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Apr 2004 22:14:47 -0000 Message-ID: <4071DA57.D67316AD@freebsd.org> Date: Tue, 06 Apr 2004 00:14:47 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Brandon Erhart cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 22:14:50 -0000 Julian Elischer wrote: > On the topic of Session shutdown... > > I have noticed an increasing number of machines on the net > are terminating their session (usually the server, but not always) > with a RESET packet instead of a FIN packet. > In particular it seems that if the machine in question recieves > a FIN packet, and has no more data to send, it replies with > a RESET. > > I don't know what kind of machines this is but next time I see it I > guess I'll look at it harder. I'd guess that are stateful firewalls in the path doing that. But finding it out with proof is better. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 16:07:41 2004 Return-Path: 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 8AA5716A4CE for ; Mon, 5 Apr 2004 16:07:41 -0700 (PDT) Received: from starburst.demon.co.uk (adsl-02-198.abel.net.uk [193.109.51.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3734843D48 for ; Mon, 5 Apr 2004 16:07:40 -0700 (PDT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id AAA04582; Tue, 6 Apr 2004 00:09:29 +0100 From: Richard Wendland Message-Id: <200404052309.AAA04582@starburst.demon.co.uk> To: silby@silby.com (Mike Silbersack) Date: Tue, 6 Apr 2004 00:09:28 +0100 (BST) In-Reply-To: <20040404160909.D29958@odysseus.silby.com> from "Mike Silbersack" at Apr 04, 2004 04:18:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 23:07:41 -0000 > Per-protocol limits _could_ have some advantages; the 16 frags per packet > limit was chosen to account for NFS over UDP. For TCP, we could drop that > to 3 frags per packet, The 16 frags per packet limit seems low to me for TCP already, blocking plausible RFC-compliant TCP connections, let alone a limit of 3 for TCP. Consider two endpoints using jumbo frames on gigE; MSS would be 9140. Say the remote TCP stack does not use/implement PMTUD (DF). On the route a backup SLIP link has to be temporarily deployed with a MTU of 512, causing the jumbo segments to form 19 fragments. Is this so implausible that the default FreeBSD configuration with maxfragsperpacket=16 should block communication in this RFC-compliant situation? How about if the maxfragsperpacket limit was only enforced when FreeBSD perceived itself to be under reassembly 'stress' (possible DoS), so low-throughput heavily fragmented IP connections would generally work as specified in the RFCs? So for example there would be a tide mark count of waiting fragments below which the maxfragsperpacket limit wasn't enforced. This tide mark could perhaps be half of net.inet.ip.maxfragpackets, or be an explicit sysctl value like net.inet.ip.highfragpackets. Richard -- Richard Wendland richard@wendland.org.uk From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 17:12:25 2004 Return-Path: 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 0865616A4CE; Mon, 5 Apr 2004 17:12:25 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A872A43D1D; Mon, 5 Apr 2004 17:12:24 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (rwcrmhc12) with SMTP id <2004040600113001400s8c0ge>; Tue, 6 Apr 2004 00:11:30 +0000 Message-Id: <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Mon, 05 Apr 2004 18:11:41 -0600 To: Andre Oppermann From: Brandon Erhart In-Reply-To: <4071D923.A7E0D93F@freebsd.org> References: <20040405171756.90E3BF8F2@gemini.nersc.gov> <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> <4071D923.A7E0D93F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 00:12:25 -0000 Hello, They are not timing out after 2MSL. I set my MSL to the lowest possible setting (10) as to make TIME_WAIT connections disappear. The FIN_WAIT_[1,2] and LAST_ACK seem to be sticking around for a while. However, not ALL of them stick around for a "long time"(more on this in a sec) -- e.g., after I kill my program, and say I've got 6,000 connections sitting in FIN_WAIT_[1,2] or LAST_ACK, about a minute afterwards 90% of them have disappeared. There seem to be a few stick around for as long as 30 minutes or more, and in fact, a few of them stuck around until I rebooted the computer. Is this bad? :) Brandon At 04:09 PM 4/5/2004, you wrote: >Brandon Erhart wrote: > > > > Well, I responded to the group that I had taken one of the fellows advice > > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c. > > > > So all is well -- it gets TCPS_CLOSED state and the tcps_close() function > > called on the tuple IMMEDIATELY. It doesn't switch states depending on > > which state the connection is currently in. I also made a sysctl variable > > for it (to turn the "feature" on or off), and will post the small patch > > along w/ some other small changes I have made soon. > >As far as I am aware (I was looking through and testing the FIN_WAIT states >in 5.2 around last christmas) our TCP stack is behaving correctly. > >Do the FIN_WAIT_1|2 and LAST_ACK time out after 2MSL or do they stick >around forever? If they stick around forever, then there is something >broken. > >But I suspect you are just running out of the small space of local ports >with your application as I said in the previous email. > >-- >Andre > > > > Thanks, > > > > Brandon > > > > At 11:17 AM 4/5/2004, you wrote: > > > > >In reply to Brandon Erhart : > > > > > > > Hello everyone, > > > > > > > However, I have run into a new problem. I am getting a good amount of > > > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick > around for a > > > > long while. > > > > > >Could you define "long" in this case? Are we talking about 60 > > >seconds, or 60 minutes? I get the feeling that your requirements > > >might make your perception of "long" different from others' notion of > > >"long." > > > > > >The reason I ask is that there was a bug once upon a time that made > > >some connections stick in LAST_ACK forever.... > > > > > > --eli > > > > > > > > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 5 19:38:58 2004 Return-Path: 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 A7B1E16A4CE for ; Mon, 5 Apr 2004 19:38:58 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85CDE43D2D for ; Mon, 5 Apr 2004 19:38:56 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:1c2:50e1:bec4:b1a4]) by tachyon.jinmei.org (Postfix) with ESMTP id 40F3A353E0; Tue, 6 Apr 2004 11:37:34 +0900 (JST) Date: Tue, 06 Apr 2004 11:38:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Sebastien Petit" In-Reply-To: <003b01c41b0f$b1e4fc90$bc0a270a@bum.sub.fr.hsbc> References: <003b01c41b0f$b1e4fc90$bc0a270a@bum.sub.fr.hsbc> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: SOCK_RAW sockets and IPPROTO_AH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 02:38:58 -0000 >>>>> On Mon, 5 Apr 2004 15:12:49 +0200, >>>>> "Sebastien Petit" said: > Hi, > Is there a way to receive AH packets in userland with a SOCK_RAW socket ? > ie: socket(AF_INET, SOCK_RAW, IPPROTO_AH) ? > I found that this socket call doesn't work under FreeBSD. On OpenBSD, it works but a recvfrom/read doesn't return any AH packets when it was received on an interface. > Is there another proper way to receive AH packets in Userland under FreeBSD ? (bpf/pcap is not a solution because I want to have a socket opened for multicast join) Unfortunately, bpf/pcap is the only solution. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 01:15:45 2004 Return-Path: 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 9689616A4CF for ; Tue, 6 Apr 2004 01:15:45 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-17.noos.net [212.198.2.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id B51FB43D5E for ; Tue, 6 Apr 2004 01:15:44 -0700 (PDT) (envelope-from spe@selectbourse.net) Received: (qmail 7733 invoked by uid 0); 6 Apr 2004 08:15:21 -0000 Received: from unknown (HELO a91821794s3ti7g) ([81.64.25.123]) (envelope-sender ) by 212.198.2.117 (qmail-ldap-1.03) with SMTP ; 6 Apr 2004 08:15:21 -0000 Message-ID: <003001c41baf$5316dad0$6400a8c0@a91821794s3ti7g> From: "Sebastien Petit" To: <"JINMEI Tatuya/ $B?@L"@C#:"H".FreeBSD.ORG (B )> References: <003b01c41b0f$b1e4fc90$bc0a270a@bum.sub.fr.hsbc> Date: Tue, 6 Apr 2004 10:15:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: SOCK_RAW sockets and IPPROTO_AH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 08:15:45 -0000 Unfortunatly, I can't use bpf/pcap solution because I must do some setsockopts (like IP_MULTICAST_IF, IP_MULTICAST_TTL, IP_MULTICAST_ADD_MEMBER etc.) and this can't be done on bpf/pcap. When I'm using IPPROTO_VRRP (ip proto 112), All work fine (and other ip proto type I think). What is the reason that SOCK_RAW don't work with IPPROTO_AH (ip proto 51). For me, it's an IP packet in two cases. Is there a good way for making a patch with SOCK_RAW, IPPROTO_AH ? I've found another strange thing in SOCK_RAW with IPPROTO_VRRP (112) and IP_HDRINCL setted on it. All received packet contains an IP Header with a bad ip_len. If the packet is 60 bytes long, the ip->ip_len contains 40 bytes. When the packet is 100 bytes long, the ip->ip_len contains 80 bytes. So there is a difference of 20 bytes. I think that the ip header size is substract from ip_len by error on the kernel. What are you think about it ? Regards, Sebastien. -- spetit@selectbourse.com spe@selectbourse.net FreeVRRPd project http://www.b0l.org/ ----- Original Message ----- From: )> To: "Sebastien Petit" Cc: Sent: Tuesday, April 06, 2004 4:38 AM Subject: Re: SOCK_RAW sockets and IPPROTO_AH > >>>>> On Mon, 5 Apr 2004 15:12:49 +0200, > >>>>> "Sebastien Petit" said: > > > Hi, > > Is there a way to receive AH packets in userland with a SOCK_RAW socket ? > > ie: socket(AF_INET, SOCK_RAW, IPPROTO_AH) ? > > I found that this socket call doesn't work under FreeBSD. On OpenBSD, it works but a recvfrom/read doesn't return any AH packets when it was received on an interface. > > > Is there another proper way to receive AH packets in Userland under FreeBSD ? (bpf/pcap is not a solution because I want to have a socket opened for multicast join) > > Unfortunately, bpf/pcap is the only solution. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 01:16:22 2004 Return-Path: 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 983FC16A4CE for ; Tue, 6 Apr 2004 01:16:22 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3027143D4C for ; Tue, 6 Apr 2004 01:16:22 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 41584 invoked from network); 6 Apr 2004 08:15:52 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 6 Apr 2004 08:15:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 6 Apr 2004 03:15:51 -0500 (CDT) From: Mike Silbersack To: richard@wendland.org.uk In-Reply-To: <200404052309.AAA04582@starburst.demon.co.uk> Message-ID: <20040406025632.J40565@odysseus.silby.com> References: <200404052309.AAA04582@starburst.demon.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 08:16:22 -0000 On Tue, 6 Apr 2004, Richard Wendland wrote: > > Per-protocol limits _could_ have some advantages; the 16 frags per packet > > limit was chosen to account for NFS over UDP. For TCP, we could drop that > > to 3 frags per packet, > > The 16 frags per packet limit seems low to me for TCP already, blocking > plausible RFC-compliant TCP connections, let alone a limit of 3 for TCP. > > Consider two endpoints using jumbo frames on gigE; MSS would be 9140. > Say the remote TCP stack does not use/implement PMTUD (DF). On the route > a backup SLIP link has to be temporarily deployed with a MTU of 512, > causing the jumbo segments to form 19 fragments. > > Is this so implausible that the default FreeBSD configuration with > maxfragsperpacket=16 should block communication in this RFC-compliant > situation? Yes, a system using jumbo frames w/o PMTUD working is a stretch. The problems of DoS attacks using IP fragments are much more real and are what the code needs to be tuned for. > How about if the maxfragsperpacket limit was only enforced when FreeBSD > perceived itself to be under reassembly 'stress' (possible DoS), so > low-throughput heavily fragmented IP connections would generally work > as specified in the RFCs? > > So for example there would be a tide mark count of waiting fragments > below which the maxfragsperpacket limit wasn't enforced. This tide mark > could perhaps be half of net.inet.ip.maxfragpackets, or be an explicit > sysctl value like net.inet.ip.highfragpackets. That seems like a workable idea. In order to ensure that a single packet can not eat up all mbufs we'd still need some limit on the lower end, but it could be relaxed. Perhaps you could do: ---- 0 packets frag limit = 32 ---- maxfragpackets / 2 frag limit = 8 ---- maxfragpackets If there was no limit for the < maxfragpackets / 2 case, then we would need to go back through and purge out the hyper-fragmented packets once we hit the higher limits, which I would like to avoid doing. NetBSD presently uses an approach whereby each fragment is counted, then when the total fragment count reaches a threshold, random reassembly queues are dropped. Depending on the type of DoS, that may be more or less successful, I haven't sat down to play with it. If you'd like to code up the threshold idea above, I could look into integrating it. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 02:23:50 2004 Return-Path: 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 C1D2C16A4CF for ; Tue, 6 Apr 2004 02:23:50 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9187A43D4C for ; Tue, 6 Apr 2004 02:23:50 -0700 (PDT) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1BAmnY-0006bq-00; Tue, 06 Apr 2004 10:23:12 +0100 To: julian@elischer.org From: Tony Finch In-Reply-To: References: <20040405201050.D5B2EF8F2@gemini.nersc.gov> Message-Id: Sender: Tony Finch Date: Tue, 06 Apr 2004 10:23:12 +0100 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 09:23:50 -0000 Julian Elischer wrote: > > I have noticed an increasing number of machines on the net >are terminating their session (usually the server, but not always) >with a RESET packet instead of a FIN packet. > >I don't know what kind of machines this is but next time I see it I >guess I'll look at it harder. I understand this to be a characteristic of Windows TCP. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE: NORTH OR NORTHEAST 3 OR 4 INCREASING 4 OR 5. OCCASIONAL RAIN OR SQUALLY SHOWERS. GOOD OCCASIONALLY MODERATE. From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 04:20:11 2004 Return-Path: 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 A014616A4CF; Tue, 6 Apr 2004 04:20:11 -0700 (PDT) Received: from mailhost.packetfront.com (mailhost.packetfront.com [212.247.6.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C866643D49; Tue, 6 Apr 2004 04:20:10 -0700 (PDT) (envelope-from anders.lowinger@packetfront.com) Received: from [212.247.6.198] (helo=maillab.packetfront.com) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 1BAoSs-00038z-00; Tue, 06 Apr 2004 13:09:58 +0200 Received: from packetfront.com (unknown [192.168.1.173]) by maillab.packetfront.com (Postfix) with ESMTP id B951673BDB; Tue, 6 Apr 2004 13:19:40 +0200 (CEST) Message-ID: <4072916D.101@packetfront.com> Date: Tue, 06 Apr 2004 13:15:57 +0200 From: Anders Lowinger User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> In-Reply-To: <40716208.808CF084@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 11:20:11 -0000 > So far I haven't found any useful application of non-contignous > mask in network applications. The only reason I've ever heard is when joining two separate subnets, for example (sorry my cisco style, i'm a routing guy) interface ethernet 0 ip address 192.168.0.0 mask 255.255.255.0 interface ethernet 1 ip address 192.168.2.0 mask 255.255.255.0 if those are combined on one interface you could write interface ethernet 0 ip address 192.168.0.0 mask 255.255.253.0 This is normally solved by secondaries (aliases) interface ethernet 0 ip address 192.168.0.0 mask 255.255.255.0 ip address 192.168.2.0 mask 255.255.255.0 secondary which gives the same functionality with contigious netmasks. > Currently Luigi has teamed up with me to do the per-if > ARP table stuff and the removal of cloning from the routing table. > That alone will make network life in the kernel much easier. Sounds great! So, what is the goal? Will the ARP functions generate host routes instead of the cloned routes? During forwarding to a nexthop with unknown L2/ARP entry, will you trigger ARP? We would really need an Mtrie for faster route lookups and combine the forwarding lookup with the check for packets destined to the router/ connected addresses. The scalability of many L3 interfaces today is not that great. (caveeat, not 100% updated on the -current) I'll dig around, I have some old mtrie code I could try to do some patches for.... /Anders From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 04:59:21 2004 Return-Path: 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 9CA2916A4CE for ; Tue, 6 Apr 2004 04:59:21 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B791443D3F for ; Tue, 6 Apr 2004 04:59:20 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 74782 invoked from network); 6 Apr 2004 11:58:50 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 Apr 2004 11:58:50 -0000 Message-ID: <40729B7A.2C984BD3@freebsd.org> Date: Tue, 06 Apr 2004 13:58:50 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Lowinger References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> <4072916D.101@packetfront.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 11:59:21 -0000 Anders Lowinger wrote: > > > So far I haven't found any useful application of non-contignous > > mask in network applications. > > The only reason I've ever heard is when joining two separate subnets, > for example (sorry my cisco style, i'm a routing guy) > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.255.0 > > interface ethernet 1 > ip address 192.168.2.0 mask 255.255.255.0 > > if those are combined on one interface you could write > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.253.0 This is simply a supernet (aka classless) but *not* a non-contignous netmask. A non-contignous netmask would look like 255.254.255.0. > This is normally solved by secondaries (aliases) > > interface ethernet 0 > ip address 192.168.0.0 mask 255.255.255.0 > ip address 192.168.2.0 mask 255.255.255.0 secondary > > which gives the same functionality with contigious netmasks. Not really. With the your second example hosts on the network have to have different default gateways (192.168.0.1 and 192.168.2.1) depending in which network range they are. In your first example you just have one default gateway for all of them. However the netmask has to match on all hosts otherwise you run into all sorts of wierd trouble. > > Currently Luigi has teamed up with me to do the per-if > > ARP table stuff and the removal of cloning from the routing table. > > That alone will make network life in the kernel much easier. > > Sounds great! So, what is the goal? > Will the ARP functions generate host routes instead of the cloned routes? No. ARP will be completely removed from the routing table and become a link layer specific L3-L2 mapping hash list. In the routing table only the network entry to the interface will remain. > During forwarding to a nexthop with unknown L2/ARP entry, will you > trigger ARP? Of course, you have to. > We would really need an Mtrie for faster route lookups and combine the > forwarding lookup with the check for packets destined to the router/ > connected addresses. The scalability of many L3 interfaces today is not that > great. (caveeat, not 100% updated on the -current) The routing table would be cleaned up with these changes and lose all cloning functionality because it no longer needed (I removed the protocol cloning last year already). > I'll dig around, I have some old mtrie code I could try > to do some patches for.... If you have some you can post it, otherwise we have some other code ready in the closet. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 05:28:46 2004 Return-Path: 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 D661F16A4CE; Tue, 6 Apr 2004 05:28:46 -0700 (PDT) Received: from mailhost.packetfront.com (mailhost.packetfront.com [212.247.6.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 177F243D5A; Tue, 6 Apr 2004 05:28:46 -0700 (PDT) (envelope-from anders.lowinger@packetfront.com) Received: from [212.247.6.198] (helo=maillab.packetfront.com) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 1BApWs-0004Hw-00; Tue, 06 Apr 2004 14:18:10 +0200 Received: from packetfront.com (unknown [192.168.1.173]) by maillab.packetfront.com (Postfix) with ESMTP id 9865D73BDB; Tue, 6 Apr 2004 14:27:52 +0200 (CEST) Message-ID: <4072A169.9010206@packetfront.com> Date: Tue, 06 Apr 2004 14:24:09 +0200 From: Anders Lowinger User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> <4072916D.101@packetfront.com> <40729B7A.2C984BD3@freebsd.org> In-Reply-To: <40729B7A.2C984BD3@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 12:28:47 -0000 Andre Oppermann wrote: >> interface ethernet 0 >> ip address 192.168.0.0 mask 255.255.253.0 > > This is simply a supernet (aka classless) but *not* a non-contignous > netmask. A non-contignous netmask would look like 255.254.255.0. Nope, 255.255.253.0 binary is 11111111.11111111.11111101.00000000 which is non-contignous. >> interface ethernet 0 >> ip address 192.168.0.0 mask 255.255.255.0 >> ip address 192.168.2.0 mask 255.255.255.0 secondary >> >>which gives the same functionality with contigious netmasks. > > Not really. Agree, not exactly the same > With the your second example hosts on the network have > to have different default gateways (192.168.0.1 and 192.168.2.1) > depending in which network range they are. In your first example > you just have one default gateway for all of them. However the > netmask has to match on all hosts otherwise you run into all sorts > of wierd trouble. In this case, the above is normally only used during a migration phase (as I mentioned, this is the only use of non-contignous i've seen, joining two separate subnets), so the hosts already have the correct default-route in their subnet. Hosts could optionally then be migrated to a common subnet. /Anders From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 05:36:46 2004 Return-Path: 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 F075716A4CE for ; Tue, 6 Apr 2004 05:36:46 -0700 (PDT) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5E7843D49 for ; Tue, 6 Apr 2004 05:36:46 -0700 (PDT) (envelope-from krishnan.n@myrealbox.com) Received: from calvin krishnan.n@smtp-send.myrealbox.com [219.65.225.107] $ on Novell NetWare via secured & encrypted transport (TLS); Tue, 06 Apr 2004 06:36:24 -0600 Content-Type: text/plain; charset="iso-8859-1" From: "krishnan.n (shyam)" Organization: gai To: rneese@adelphia.net Date: Thu, 8 Apr 2004 03:10:27 +0530 User-Agent: KMail/1.4.3 References: <20040405190057.5ECFF16A4E3@hub.freebsd.org> In-Reply-To: <20040405190057.5ECFF16A4E3@hub.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200404080310.27699.krishnan.n@myrealbox.com> cc: freebsd-net@freebsd.org Subject: Re: Driver porting. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 12:36:47 -0000 Hello, >can any of the driver writers or porters help with porting the atw driver > from netbsd to freebsd. this is for the admtek 802.11b network based cards. > Would like to help in the port. I have and SMC AP, a PCMCIA card and PCI card. Let me know how/when to get started. I will need help getting the sources, etc. thanks, krishnan Ranikhet, India. From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 06:03:34 2004 Return-Path: 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 5E6FB16A4CE for ; Tue, 6 Apr 2004 06:03:34 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FAE743D55 for ; Tue, 6 Apr 2004 06:03:33 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 88735 invoked from network); 6 Apr 2004 13:03:13 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 Apr 2004 13:03:13 -0000 Message-ID: <4072AA91.DA00A9F3@freebsd.org> Date: Tue, 06 Apr 2004 15:03:13 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Lowinger References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> <4072916D.101@packetfront.com> <40729B7A.2C984BD3@freebsd.org> <4072A169.9010206@packetfront.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 13:03:34 -0000 Anders Lowinger wrote: > > Andre Oppermann wrote: > > >> interface ethernet 0 > >> ip address 192.168.0.0 mask 255.255.253.0 > > > > This is simply a supernet (aka classless) but *not* a non-contignous > > netmask. A non-contignous netmask would look like 255.254.255.0. > > Nope, 255.255.253.0 binary is 11111111.11111111.11111101.00000000 > which is non-contignous. You are right. I was looking to quickly. However at least my Cisco doesn't like it: "Bad mask 0xFFFFFD00 for address", IOS 12.2(10). > > With the your second example hosts on the network have > > to have different default gateways (192.168.0.1 and 192.168.2.1) > > depending in which network range they are. In your first example > > you just have one default gateway for all of them. However the > > netmask has to match on all hosts otherwise you run into all sorts > > of wierd trouble. > > In this case, the above is normally only used during a migration > phase (as I mentioned, this is the only use of non-contignous i've > seen, joining two separate subnets), so the hosts already have the > correct default-route in their subnet. Hosts could optionally then > be migrated to a common subnet. Never heard of that (only supernets/subnets with respect to classful notation), never done it and at least my Cisco 7500 doesn't like it. So I doubt others have got their Cisco to like it. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 06:19:38 2004 Return-Path: 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 C6B6F16A4CF for ; Tue, 6 Apr 2004 06:19:38 -0700 (PDT) Received: from hotmail.com (bay16-dav64.bay16.hotmail.com [65.54.186.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id A69F443D45 for ; Tue, 6 Apr 2004 06:19:38 -0700 (PDT) (envelope-from fuhuayin@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Apr 2004 06:18:34 -0700 Received: from 193.190.247.201 by bay16-dav64.bay16.hotmail.com with DAV; Tue, 06 Apr 2004 13:18:34 +0000 X-Originating-IP: [193.190.247.201] X-Originating-Email: [fuhuayin@hotmail.com] X-Sender: fuhuayin@hotmail.com From: "Fuhua Yin" To: Date: Tue, 6 Apr 2004 15:18:27 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 06 Apr 2004 13:18:34.0924 (UTC) FILETIME=[AA1F2EC0:01C41BD9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: PIM-SM OVER FREEBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 13:19:38 -0000 Hello Freebsdnet-list, Is there anyone who knows how to run PIM-SM over Freebsd? I only found mrouted, but I would to try PIM-SM since it claims to = implement this. Many thanks in advance, fuhua From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 06:32:41 2004 Return-Path: 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 E4A8C16A4CE; Tue, 6 Apr 2004 06:32:41 -0700 (PDT) Received: from mailhost.packetfront.com (mailhost.packetfront.com [212.247.6.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D54A743D39; Tue, 6 Apr 2004 06:32:40 -0700 (PDT) (envelope-from anders.lowinger@packetfront.com) Received: from [212.247.6.198] (helo=maillab.packetfront.com) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 1BAqWG-0005Pn-00; Tue, 06 Apr 2004 15:21:36 +0200 Received: from packetfront.com (unknown [192.168.1.173]) by maillab.packetfront.com (Postfix) with ESMTP id 6480073940; Tue, 6 Apr 2004 15:31:19 +0200 (CEST) Message-ID: <4072B048.2000509@packetfront.com> Date: Tue, 06 Apr 2004 15:27:36 +0200 From: Anders Lowinger User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <20040331005914.A6934@xorpc.icir.org> <40712A8F.9000704@packetfront.com> <40716208.808CF084@freebsd.org> <4072916D.101@packetfront.com> <40729B7A.2C984BD3@freebsd.org> <4072A169.9010206@packetfront.com> <4072AA91.DA00A9F3@freebsd.org> In-Reply-To: <4072AA91.DA00A9F3@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 13:32:42 -0000 > You are right. I was looking to quickly. However at least my Cisco > doesn't like it: "Bad mask 0xFFFFFD00 for address", IOS 12.2(10). As I mentioned in my first email, Cisco only supports contignous netmasks. I was just trying to elaborate on when/why non-contignous netmasks would be good to have. I'm pretty sure no-one is using them.... > Never heard of that (only supernets/subnets with respect to classful > notation), never done it and at least my Cisco 7500 doesn't like it. > So I doubt others have got their Cisco to like it. Correct. This is one of the first thing they mention in the manuals. /Anders From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 08:21:11 2004 Return-Path: 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 2EBB516A4CE; Tue, 6 Apr 2004 08:21:11 -0700 (PDT) Received: from tachyon.jinmei.org (kame207.kame.net [203.178.141.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 591EA43D48; Tue, 6 Apr 2004 08:21:10 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:4819:64a9:7819:e195:d1b1]) by tachyon.jinmei.org (Postfix) with ESMTP id 9C31F35135; Wed, 7 Apr 2004 00:20:35 +0900 (JST) Date: Wed, 07 Apr 2004 00:21:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Sebastien Petit" In-Reply-To: <003001c41baf$5316dad0$6400a8c0@a91821794s3ti7g> <200403211226.13690.spe@selectbourse.net> References: <003b01c41b0f$b1e4fc90$bc0a270a@bum.sub.fr.hsbc> <003001c41baf$5316dad0$6400a8c0@a91821794s3ti7g> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Wed_Apr__7_00:21:07_2004-1" cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: SOCK_RAW sockets and IPPROTO_AH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 15:21:11 -0000 --Multipart_Wed_Apr__7_00:21:07_2004-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 6 Apr 2004 10:15:29 +0200, >>>>> "Sebastien Petit" said: > Unfortunatly, I can't use bpf/pcap solution because I must do some > setsockopts (like IP_MULTICAST_IF, IP_MULTICAST_TTL, IP_MULTICAST_ADD_MEMBER > etc.) and this can't be done on bpf/pcap. > When I'm using IPPROTO_VRRP (ip proto 112), All work fine (and other ip > proto type I think). What is the reason that SOCK_RAW don't work with > IPPROTO_AH (ip proto 51). > For me, it's an IP packet in two cases. Let me check, why do you have to include AH by the application in the first place? Is that related to the question you made the other day (attached below)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Apr__7_00:21:07_2004-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Sun Mar 21 20:27:00 2004 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Sun, 21 Mar 2004 20:45:52 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9D1EB15210 for ; Sun, 21 Mar 2004 20:27:00 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 7DC11330FB for ; Sun, 21 Mar 2004 20:27:00 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id UAA24453 for ; Sun, 21 Mar 2004 20:27:00 +0900 (JST) Received: from mx4.toshiba.co.jp (mx4.toshiba.co.jp [133.199.160.112]) i2LBQx100075 for ; Sun, 21 Mar 2004 20:26:59 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id UAA03644; Sun, 21 Mar 2004 20:26:59 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i2LBQwQD012005 for ; Sun, 21 Mar 2004 20:26:58 +0900 (JST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by inet-tsb5.toshiba.co.jp with ESMTP id i2LBQv4u013439 for ; Sun, 21 Mar 2004 20:26:57 +0900 (JST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 4E2FF569A6; Sun, 21 Mar 2004 03:26:38 -0800 (PST) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E935816A4DC; Sun, 21 Mar 2004 03:26:36 -0800 (PST) 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 AB31816A4CE for ; Sun, 21 Mar 2004 03:26:22 -0800 (PST) Received: from smtp.noos.fr (nan-smtp-17.noos.net [212.198.2.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C5343D2D for ; Sun, 21 Mar 2004 03:26:21 -0800 (PST) (envelope-from spe@selectbourse.net) Received: (qmail 19099 invoked by uid 0); 21 Mar 2004 11:26:20 -0000 Received: from unknown (HELO 192.168.0.3) ([81.64.25.123]) (envelope-sender ) by 212.198.2.117 (qmail-ldap-1.03) with SMTP for ; 21 Mar 2004 11:26:20 -0000 From: Sebastien Petit Organization: BSDShell To: freebsd-net@freebsd.org Date: Sun, 21 Mar 2004 12:26:13 +0100 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403211226.13690.spe@selectbourse.net> Subject: IPSec and setsockopt MULTICAST_IF interaction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-UIDL: %!$"!=@7!!G&~"!h89!! X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on ocean.jinmei.org X-Spam-Status: No, hits=1.5 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.61 Hi Team, I want to use IPsec engine with AH Security Association and SPD on multicast destination adress. When I comment the setsockopt MULTICAST_IF option, all work fine and destination packets to the multicast adress have AH added before IP Header. But when I use the setsockopt MULTICAST_IF, no packets are sended from the interface (packet seems to be destroyed silently by kernel). Is there an issue about using MUTLICAST_IF option and IPsec ? Any help will be greatly appreciated. Regards, spe. -- spe@selectbourse.net _______________________________________________ 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" --Multipart_Wed_Apr__7_00:21:07_2004-1-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 09:10:26 2004 Return-Path: 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 7A42F16A4CE for ; Tue, 6 Apr 2004 09:10:26 -0700 (PDT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 192D243D46 for ; Tue, 6 Apr 2004 09:10:26 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040406160912.PLEB27801.out008.verizon.net@mac.com>; Tue, 6 Apr 2004 11:09:12 -0500 Message-ID: <4072D627.9060909@mac.com> Date: Tue, 06 Apr 2004 12:09:11 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <20040405171756.90E3BF8F2@gemini.nersc.gov> <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> <4071D923.A7E0D93F@freebsd.org> <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [68.160.247.127] at Tue, 6 Apr 2004 11:09:11 -0500 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 16:10:26 -0000 Brandon Erhart wrote: > They are not timing out after 2MSL. I set my MSL to the lowest possible > setting (10) as to make TIME_WAIT connections disappear. The > FIN_WAIT_[1,2] and LAST_ACK seem to be sticking around for a while. > However, not ALL of them stick around for a "long time"(more on this in > a sec) -- e.g., after I kill my program, and say I've got 6,000 > connections sitting in FIN_WAIT_[1,2] or LAST_ACK, about a minute > afterwards 90% of them have disappeared. There seem to be a few stick > around for as long as 30 minutes or more, and in fact, a few of them > stuck around until I rebooted the computer. People are starting to set up honeynets or tarpits which will "persist capture" TCP connections "forever" by responding with a zero window size. Such things slow down the spread of worms/virii effectively, but they also make nmap or other scanning tools (perhaps Brandon's) unhappy. It might be interesting to retest one of these stuck connections by hand and see whether the remote machine generates a normal response. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 09:14:37 2004 Return-Path: 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 6676C16A4CE for ; Tue, 6 Apr 2004 09:14:37 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C22D43D46 for ; Tue, 6 Apr 2004 09:14:37 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (rwcrmhc13) with SMTP id <20040406161413015003s386e>; Tue, 6 Apr 2004 16:14:14 +0000 Message-Id: <6.0.2.0.2.20040406100638.01c6f288@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Tue, 06 Apr 2004 10:14:26 -0600 To: freebsd-net@freebsd.org From: Brandon Erhart Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: The Almighty KQueue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 16:14:37 -0000 Hi, I told you all I'd be back for more :) I am not sure if this is the most appropriate place to post this, but it seems that you all know what the hell you're talking about, so I figure you can help me out here. As I said in my previous post about the FIN_WAIT states, I am writing a web sucker downer (mirror). What I don't believe I mentioned before is that I am using the KQueue API in FreeBSD 4.9-REL to take care of watching over my sockets. I seem to be running into a nasty problem, however. Here's a scenario. I set the outgoing connections to, say, 5000. The problem is, the amount of connections my program shows as being connected is roughly 1/2 to sometimes even 1/8th of what is actually connected. I see what is "actually connected" by doing a netstat. The program would say 750/5000 connections, while a netstat would show 4500 connections in the ESTABLISHED state. You may be saying, "it must be a bug in your connection tracking logic". I honestly don't think that's it. I have only TWO places in my code where I check if the connection was successful (and therefore increasing the global connection counter) -- in the callback function for data read() from KQueue-monitored fds (all of the sockets), and then also in my main loop (I check for read, write and connect timeouts there, right after my call to kevent()). Basically the main loop looks like, in psuedo-code of course: while (there_is_still_events) { if (kevent()) <-- i pull one event from the kqueue { execute_the_callback_function; } check_for_read()_write()_and_connect()_timeouts; check_for_"client_descriptors(basically just a structure that holds info on the kqueue event)"_that_need_to_be_connected_to_the_next_server_and_do_so; } It's pretty straight forward. I have no idea why my program would be reporting a smaller amount. Is it possible that my program is not getting ALL the information it needs from kevent()? Perhaps the KQueue is becoming "full"? Is this possible? Should I be pulling more than one event off the kqueue at a time? I have been up ALL NIGHT trying to debug this, and cannot figure it out. Any and all help is appreciated! Thanks, Brandon From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 09:15:35 2004 Return-Path: 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 AA87616A4CF for ; Tue, 6 Apr 2004 09:15:35 -0700 (PDT) Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FC6543D60 for ; Tue, 6 Apr 2004 09:15:34 -0700 (PDT) (envelope-from daved@tamu.edu) Received: from [128.194.177.82] (dhcp-test-14.net.tamu.edu [128.194.177.82]) by smtp-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id i36GFGhT004203 for ; Tue, 6 Apr 2004 11:15:17 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v613) To: net@freebsd.org Message-Id: <94823836-87E5-11D8-BD67-000A956E58AC@tamu.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--118303430; protocol="application/pkcs7-signature" From: David J Duchscher Date: Tue, 6 Apr 2004 11:15:11 -0500 X-Mailer: Apple Mail (2.613) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Broadcast and Multicast counter (omcasts) - fxp driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 16:15:35 -0000 --Apple-Mail-3--118303430 Content-Type: multipart/mixed; boundary=Apple-Mail-2--118303614 --Apple-Mail-2--118303614 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I started using SNMP to monitor some floppy based routers we have and I have noticed that outgoing broadcast packets do not show up in the counters. Multicast packets where fine. I dug into some and SNMP daemon is reported what the OS is telling it. Does anybody have an idea what is wrong or where I should start looking through the kernel? I am not that familiar with the kernel sources so pointers would be helpful. DaveD --Apple-Mail-2--118303614 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0600; name="dmesg.txt" Content-Disposition: attachment; filename=dmesg.txt Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FBox 1.10.4 (FreeBSD 4.9-RELEASE-p4) Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 266615783 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80f9ff real memory = 268435456 (262144K bytes) avail memory = 252706816 (246784K bytes) Pentium Pro MTRR support enabled md1: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at 7.1 pci0: at 7.2 irq 9 chip1: port 0x7000-0x700f at device 7.3 on pci0 pci0: (vendor=0x1274, dev=0x5000) at 13.0 irq 11 fxp0: port 0xfc40-0xfc7f mem 0xfede0000-0xfedfffff,0xfeddf000-0xfeddffff irq 10 at device 14.0 on pci0 fxp0: Ethernet address 00:02:b3:c7:7a:3d inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xfc00-0xfc3f mem 0xfeda0000-0xfedbffff,0xfedde000-0xfeddefff irq 15 at device 15.0 on pci0 fxp1: Ethernet address 00:02:b3:c7:7b:e4 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: