From owner-freebsd-net Sun Aug 11 7:39:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A8EC37B400 for ; Sun, 11 Aug 2002 07:39:22 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC0A43E42 for ; Sun, 11 Aug 2002 07:39:21 -0700 (PDT) (envelope-from freebsd@epx.com) Received: from ux340prd.epx.com (ux340prd.epx.com [192.168.12.94]) by exchange.epx.com (8.12.3/8.12.3) with ESMTP id g7BEeVWE000479 for ; Sun, 11 Aug 2002 10:40:31 -0400 (EDT) (envelope-from freebsd@epx.com) Content-Type: text/plain; charset="us-ascii" From: freebsd To: net@freebsd.org Subject: A way to control/dictate the order in which NIC drivers load? Date: Sun, 11 Aug 2002 10:40:31 -0400 X-Mailer: KMail [version 1.4] Organization: epx.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208111040.31076.freebsd@epx.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a Znyx card and a generic card that uses DC driver. I want to implement the netrain features of the Znyx, which tells me to=20 disable the dc & de drivers in the kernal config file. I would like to use both cards. Is there a way to tell FreeBSD (4.6) to load the Znyx driver first, then = the=20 dc driver? Or any other way to create a net alias file so perhaps by hw=20 addresses I can map driver --> interface? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 11 14:54:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1957F37B400; Sun, 11 Aug 2002 14:54:44 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-67-115-73-77.dsl.lsan03.pacbell.net [67.115.73.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89EB343E6E; Sun, 11 Aug 2002 14:54:43 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A516A66DDD; Sun, 11 Aug 2002 14:54:39 -0700 (PDT) Date: Sun, 11 Aug 2002 14:54:38 -0700 From: Kris Kennaway To: Ruslan Ermilov Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_input.c Message-ID: <20020811215438.GA76543@xor.obsecurity.org> References: <200207222231.g6MMVA5Y009413@freefall.freebsd.org> <20020722223455.GA34550@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020722223455.GA34550@sunbay.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jul 23, 2002 at 01:34:55AM +0300, Ruslan Ermilov wrote: > On Mon, Jul 22, 2002 at 03:31:10PM -0700, Ruslan Ermilov wrote: > > ru 2002/07/22 15:31:10 PDT > > > > Modified files: > > sys/netinet tcp_input.c > > Log: > > Don't shrink socket buffers in tcp_mss(), application might have already > > configured them with setsockopt(SO_*BUF), for RFC1323's scaled windows. > > > > PR: kern/11966 > > MFC after: 1 week > > > > Revision Changes Path > > 1.166 +4 -2 src/sys/netinet/tcp_input.c > > > The attached program could be used as a regression test. Perhaps this should be committed. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 2:27:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC97637B400 for ; Mon, 12 Aug 2002 02:27:26 -0700 (PDT) Received: from hotmail.com (f102.law9.hotmail.com [64.4.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B549B43E5E for ; Mon, 12 Aug 2002 02:27:26 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 02:27:26 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 12 Aug 2002 09:27:26 GMT X-Originating-IP: [62.217.112.191] From: "soheil h" To: freebsd-net@freebsd.org Subject: TCP CHECKSUM ( emergency ) Date: Mon, 12 Aug 2002 13:57:26 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Aug 2002 09:27:26.0541 (UTC) FILETIME=[78D49FD0:01C241E2] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list as R. Stevens says in TCP/IP Ill. Vol.1 the tcp checksum is computed on the data and its own header. but ip checksum is computed only on the ip header. i want to know if the tcp checksum is computed on the ip header or not and if i have a "struct mbuf m" that its m->m_data points to an ip packet and i know the tcp cksum is not true how can i compute the tcp cksum the ip packet is passing through my FreeBSD gateway something goes wrong on tcp checksums i want to compute it again . some where in ip_input.c if i know everything ,but this, is true. (by the way ,using in_cksum() ,does this code work for me ? : th->th_sum = in_cksum(m, m->m_len) ) _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 11:39: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CAB837B400 for ; Mon, 12 Aug 2002 11:39:02 -0700 (PDT) Received: from web10411.mail.yahoo.com (web10411.mail.yahoo.com [216.136.128.125]) by mx1.FreeBSD.org (Postfix) with SMTP id C339243E70 for ; Mon, 12 Aug 2002 11:39:01 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20020812183901.29824.qmail@web10411.mail.yahoo.com> Received: from [67.112.212.200] by web10411.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 11:39:01 PDT Date: Mon, 12 Aug 2002 11:39:01 -0700 (PDT) From: Oleg Polyakov Subject: Re: Initial congestion window increase To: Jeffrey Hsu , Mike Silbersack Cc: Oleg Polyakov , freebsd-net@freebsd.org In-Reply-To: <0H0N0076BWTMDO@mta5.snfc21.pbi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Jeffrey Hsu wrote: > There are a couple more places you have to change if you > really > want to implement that RFC. > Oh, yes - it seemed too easy initially ;) __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 12:25:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31EE337B400 for ; Mon, 12 Aug 2002 12:25:50 -0700 (PDT) Received: from web10409.mail.yahoo.com (web10409.mail.yahoo.com [216.136.128.122]) by mx1.FreeBSD.org (Postfix) with SMTP id EDF4A43E65 for ; Mon, 12 Aug 2002 12:25:49 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20020812192549.24783.qmail@web10409.mail.yahoo.com> Received: from [67.112.212.200] by web10409.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 12:25:49 PDT Date: Mon, 12 Aug 2002 12:25:49 -0700 (PDT) From: Oleg Polyakov Subject: Re: Initial congestion window increase To: Mike Silbersack Cc: freebsd-net@freebsd.org In-Reply-To: <20020810215044.O62906-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Mike Silbersack wrote: > > On Fri, 9 Aug 2002, Oleg Polyakov wrote: > > > Here is a patch allowing to increase TCP's initial > congestion > > window up to 4 mss but less then 4380 bytes as specified in > > experimental RFC 2414 and draft-ietf-tsvwg-initwin-04.txt. > > It doesn't touch idle congestion window as per draft. > > Despite this change being in an RFC, I'm not sure that it's > really worth > implementing. While increasing the slowstart flightsize might > do wonders > for benchmarks of short connections, the actual effect on real > world tests > seems much more murky. Yes, real world is murky;) RFC2414 references RFC2415 - Simulation Studies of Increased Initial TCP Window Size which shows significantly increased throughput and decreased delays and some increased drop rate - around 1% more for connections with initial window=3. It also references RFC2416 - When TCP Starts Up With Four Packets Into Only Three Buffers where experiment shows decreased delays and "no harm" for transmission. > I believe that there _is_ an argument for using mss * 2 as the > default > flightsize, however. Supposedly, some OSes using delayed ACKs > will delay > the first ack, causing a 200ms delay which can really slow > down the > transfer of small web pages / etc. If you can find (tcpdump) > evidence to > back this up, I could agree with raising the value to 2 * mss. > Beyond > that, however, seems like a cheap way to inflate benchmarks > and cause > congestion. Well, if we have congestion with cwnd = 2 * mss, we have it regardless of initial window. Just in case of initial window = 2 * mss we have congestion 1 rtt earlier... By the way looking into tcpdump revealed we have initial window = 2 * mss in case of slowstart_flightsize = 1. I've seen it on FreeBSD 4.5 and 4.6 . What is this - an ancient bug in BSD stack? If I set slowstart_flightsize to 0 then tcpdump shows we starting with initial window 1... > Mike "Silby" Silbersack > > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 13: 6:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6CEB37B400 for ; Mon, 12 Aug 2002 13:06:44 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51F9043E42 for ; Mon, 12 Aug 2002 13:06:43 -0700 (PDT) (envelope-from thomas.r.henderson@boeing.com) Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA17953; Mon, 12 Aug 2002 15:06:39 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id NAA19363; Mon, 12 Aug 2002 13:06:38 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g7CK6bm23472; Mon, 12 Aug 2002 13:06:37 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Aug 2002 13:06:39 -0700 Message-ID: <00EBC850E752CC46B8509DAB4D0D2CB910695B@xch-nw-29.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "'Oleg Polyakov'" Cc: freebsd-net@freebsd.org Subject: RE: Initial congestion window increase Date: Mon, 12 Aug 2002 13:06:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > By the way looking into tcpdump revealed we have initial window > = 2 * mss in case of slowstart_flightsize = 1. I've seen it on > FreeBSD 4.5 and 4.6 . > What is this - an ancient bug in BSD stack? > This used to be a bug/feature of the Net/3 TCP code (ack of syn caused cwnd increment). The snippet below seems to be aimed at preventing this in current FreeBSD, but perhaps something else is incrementing initial window to be 2 (not that this is a bad thing). from tcp_input.c:1795 /* * If no data (only SYN) was ACK'd, * skip rest of ACK processing. */ if (acked == 0) goto step6; Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 13:21: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C972A37B400; Mon, 12 Aug 2002 13:20:57 -0700 (PDT) Received: from hotmail.com (f116.law9.hotmail.com [64.4.9.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9034E43E42; Mon, 12 Aug 2002 13:20:57 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 12 Aug 2002 13:20:57 -0700 Received: from 62.217.121.115 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 12 Aug 2002 20:20:54 GMT X-Originating-IP: [62.217.121.115] From: "soheil h" To: hsu@FreeBSD.org Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP CHECKSUM ( emergency ) Date: Tue, 13 Aug 2002 00:50:54 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Aug 2002 20:20:57.0594 (UTC) FILETIME=[C4707DA0:01C2423D] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i know how easy it is but i use that function i said it doesn't work for me ( th->th_sum = in_cksum(m, len)) i use the TcpCksum (struct ip *) and it doesn't work for us because the FreeBSD mbuf data is not continues and maybe it is fragmented i want to know if the in_cksum i use is correct or not ? if not please verify me how i can correct that and if yes i will try to find any error else ( and of course i am a b.s. student of C.E. 4th term and i will get network class 2 terms later , so i don't have networking assignment but i am so greedy to find anything about TCP/IP that's it ) if you can help me please help!!!!!! thanx >From: Jeffrey Hsu >To: soheil h >Subject: Re: TCP CHECKSUM ( emergency ) >Date: Mon, 12 Aug 2002 13:03:12 -0700 > >Is this for a homework assignment or for work? :-) _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 15:49: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8631937B400 for ; Mon, 12 Aug 2002 15:48:57 -0700 (PDT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3782D43E65 for ; Mon, 12 Aug 2002 15:48:57 -0700 (PDT) (envelope-from julian@vicor.com) Received: from vicor.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E33075922B for ; Mon, 12 Aug 2002 15:48:56 -0700 (PDT) Message-ID: <3D583B58.3A132F@vicor.com> Date: Mon, 12 Aug 2002 15:48:56 -0700 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: Racoon question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a (probably silly) question about racoon.. I have racoon working to some extent. I have it working in transport mode. However I notice that if I have a problem on one system it sometimes needs to wait until the running SA has expired until things can be restarted.. For example if one system is rebooted, I need to reset the racoon on the other system and clear SAs etc. before things can resync. It occured to me that this may be because the racoons need to talk across the transport connection that is toasted so it's a catch-22. I tried setting up port 500 as an excpetion using 'none' in /etc/ipsec.conf but that seems to confuse things.. it seems unable to decide for any given connection whether to use the [500] or [any] sessions. There is no documentation as to whether one can set up a generic SA between machines A and B and then have an exception for a particular port number and protocol. If I DO put the line spdadd bla [500] bla [500] none; into the file things apparently get very confused.. If I don't, as I said, the racoons can not talk to each other until everything on both sides of the link have been reset. does anyone know whether racoon can is supposed to be able to communicate across a broken transport connection? if not then it seems to be rather useless.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 17:30:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED01337B400 for ; Mon, 12 Aug 2002 17:30:43 -0700 (PDT) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8EAA43E3B for ; Mon, 12 Aug 2002 17:30:43 -0700 (PDT) (envelope-from jeff@expertcity.com) Received: from [10.4.1.134] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 17ePa7-0001qh-00 for net@freebsd.org; Mon, 12 Aug 2002 17:30:43 -0700 Message-ID: <3D585310.8010709@expertcity.com> Date: Mon, 12 Aug 2002 17:30:08 -0700 From: Jeff Behl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: net@freebsd.org Subject: MTU not working? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We're seeing something odd that is seriously impacting our service for some clients. Even though a the box seems to have the correct MTU in the routing table, it doesn't seem to follow it in all cases. dell350-12.snv#sysctl -a | grep mtu net.inet.tcp.path_mtu_discovery: 1 dell350-12.snv#uname -a FreeBSD dell350-12.snv 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Fri Aug 2 03:24:36 PDT 2002 root@dell350-12.snv:/usr/src/sys/compile/COMMS44-2 i386 dell350-12.snv#netstat -rnal | grep 10.4.1.134 10.4.1.134 63.xxx.224.129 UGHW 1 2268 1420 fxp0 but tcpdump shows: 17:21:43.497275 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack 248 win 17520 (DF) 17:21:51.497212 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack 248 win 17520 (DF) 17:22:07.497065 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack 248 win 17520 (DF) obviosly the packet isn't making it back to the client as it's too big. any ideas? I don't see any bug reports on it. We believe the same situation exsits with a 4.6 server but I haven't checked that thorougly enough yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 21:53:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C09637B400 for ; Mon, 12 Aug 2002 21:53:11 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7283943E4A for ; Mon, 12 Aug 2002 21:53:10 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g7D4qxa55144 for ; Mon, 12 Aug 2002 21:52:59 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.2/8.12.1/meer) with ESMTP id g7D4r9dH018120 for ; Mon, 12 Aug 2002 21:53:09 -0700 (PDT) Message-Id: <200208130453.g7D4r9dH018120@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org Subject: Error in UDP output processing? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Aug 2002 21:53:09 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Folks, I'm looking at the -STABLE sources for a bug we're having at work with a high capacity server that uses UDP. The bug is that when we run out of mbufs in udp_output() we do NOT disconnect the socket that caused the error. All error cases goto release: which is after the in_pcbdisconnect() call. Is this intentional? Thanks, George -- George V. Neville-Neil gnn@neville-neil.com Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 21:57:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B35437B400 for ; Mon, 12 Aug 2002 21:57:31 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C3F43E77 for ; Mon, 12 Aug 2002 21:57:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813045727.CZAZ19356.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 13 Aug 2002 04:57:27 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7D4vQJK002151; Mon, 12 Aug 2002 21:57:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7D4vO41002150; Mon, 12 Aug 2002 21:57:24 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 12 Aug 2002 21:57:24 -0700 From: "Crist J. Clark" To: Ulrich Kiermayr Cc: freebsd-net@FreeBSD.ORG Subject: Re: Source Based Routing of locally originated connections Message-ID: <20020813045724.GC1675@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20020810213354.A1086673@ap.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020810213354.A1086673@ap.univie.ac.at> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Aug 10, 2002 at 09:33:54PM +0200, Ulrich Kiermayr wrote: > Hello list, > > I have the following Question: I know that i can use either ipfinler > (fastroute) or ipfw (fwd) to acomplish source based touting of packets > going through my machine. > > Now I have a machine with several ip-Addresses, and i want to route > packets differenly depending on which of the local addresses is the > source address of the packet. > > Is this possible, and if yes how? ipfw(8) doesn't care if the packets originate locally or are being forwarded. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 22:26:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B88C137B400 for ; Mon, 12 Aug 2002 22:26:26 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DCB543E42 for ; Mon, 12 Aug 2002 22:26:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813052625.OSXP23732.sccrmhc01.attbi.com@blossom.cjclark.org>; Tue, 13 Aug 2002 05:26:25 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7D5QOJK002236; Mon, 12 Aug 2002 22:26:24 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7D5QJV3002235; Mon, 12 Aug 2002 22:26:19 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 12 Aug 2002 22:26:19 -0700 From: "Crist J. Clark" To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: Racoon question Message-ID: <20020813052619.GD1675@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <3D583B58.3A132F@vicor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D583B58.3A132F@vicor.com> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 12, 2002 at 03:48:56PM -0700, Julian Elischer wrote: > I have a (probably silly) question about racoon.. > > I have racoon working to some extent. > I have it working in transport mode. > > However I notice that if I have a problem on one system it sometimes > needs to wait until the running SA has expired until things can be > restarted.. For example if one system is rebooted, I need to reset the > racoon on the > other system and clear SAs etc. before things can resync. Yeah, known issue which comes up from time to time. It is a common headache in IPsec. 'Coulda sworn there was a sysctl(8) to change this behavior, but I can't find it. Nor can I Google anything except other {Free,Net,Open}BSD and Linux people complaining about the problem. This IETF draft explains some of the issues, http://search.ietf.org/internet-drafts/draft-spencer-ipsec-ike-implementation-02.txt Maybe you can find some of the solutions that have been offered. It's been discussed on various lists (-net, -security, and -questions) many times. But just so you know, > It occured to me that this may be because the racoons need to talk > across the > transport connection that is toasted so it's a catch-22. > > I tried setting up port 500 as an excpetion using 'none' > in /etc/ipsec.conf but that seems to confuse things.. it seems unable to > decide for > any given connection whether > to use the [500] or [any] > sessions. This actually is not the problem. IKE/IPsec implementations have to be smart enough to handle the negotiations "OOB." -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 22:37:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6241537B400 for ; Mon, 12 Aug 2002 22:37:32 -0700 (PDT) Received: from lancer.sasktel.net (lancer.sasktel.net [142.165.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD57E43E4A for ; Mon, 12 Aug 2002 22:37:31 -0700 (PDT) (envelope-from topcat@sk.sympatico.ca) Received: from sk.sympatico.ca (regnsk01d050201153.sk.sympatico.ca [142.165.25.153]) by lancer.sasktel.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H0R004CBOYD16@lancer.sasktel.net> for freebsd-net@freebsd.org; Mon, 12 Aug 2002 23:37:26 -0600 (CST) Content-return: allowed Date: Mon, 12 Aug 2002 23:37:25 -0600 From: TOPCAT CONSULTING Subject: routing problem To: freebsd-net@freebsd.org Message-id: <3D589B14.90E62433@sk.sympatico.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 3.1-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a dial-up ppp connection from PC_1 to PC_2 set up and working good. PC_2 has an ethernet network connection as well, connecting to PC_3 on a different network address The ppp connection is from 192.168.0.2 --> 192.168.0.1 I need to route as follows: from 192.168.0.2 --> 192.168.0.1 --> 10.0.0.1 in other words from PC_1 --> PC_2 --> PC_3 where 1-->2 is ppp and 2 -->3 is ethernet After the ppp connection from 1 --> 2 is established the route table on PC_1 is as follows: DEST GATEWAY GENMASK FLAGS IFACE 192.168.0.1 * 255.0.0.0 UH ppp0 127.0.0.0 * 255.0.0.0 U lo default 192.168.0.1 0.0.0.0 UG ppp0 pppd is enabled with option "defaultroute" and "proxyarp" at all nodes. I can't get from 1 -->3 What might I be missing? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 12 23: 0:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1C4537B405; Mon, 12 Aug 2002 23:00:20 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3239343E4A; Mon, 12 Aug 2002 23:00:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813060012.DQGT221.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 13 Aug 2002 06:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA14802; Mon, 12 Aug 2002 22:42:43 -0700 (PDT) Date: Mon, 12 Aug 2002 22:42:42 -0700 (PDT) From: Julian Elischer To: "Crist J. Clark" Cc: Julian Elischer , net@FreeBSD.ORG Subject: Re: Racoon question In-Reply-To: <20020813052619.GD1675@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 12 Aug 2002, Crist J. Clark wrote: > On Mon, Aug 12, 2002 at 03:48:56PM -0700, Julian Elischer wrote: > > Yeah, known issue which comes up from time to time. It is a common > headache in IPsec. 'Coulda sworn there was a sysctl(8) to change this > behavior, but I can't find it. Nor can I Google anything except other > {Free,Net,Open}BSD and Linux people complaining about the > problem. This IETF draft explains some of the issues, > > http://search.ietf.org/internet-drafts/draft-spencer-ipsec-ike-implementation-02.txt > > Maybe you can find some of the solutions that have been offered. It's > been discussed on various lists (-net, -security, and -questions) many > times. > > But just so you know, > > > It occured to me that this may be because the racoons need to talk > > across the > > transport connection that is toasted so it's a catch-22. > > > > I tried setting up port 500 as an excpetion using 'none' > > in /etc/ipsec.conf but that seems to confuse things.. it seems unable to > > decide for > > any given connection whether > > to use the [500] or [any] > > sessions. > > This actually is not the problem. IKE/IPsec implementations have to be > smart enough to handle the negotiations "OOB." So how does racoon talk "OOB"? does it add it's own SA? how does it stop it's own packets from being thrown away at the far end when they are not encrypted correctly for the transport layer ipsec? thanks for the pointer .. I'm amazed that no-one has an answer for this.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 1:16: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA6A037B400 for ; Tue, 13 Aug 2002 01:15:57 -0700 (PDT) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A4A43E3B for ; Tue, 13 Aug 2002 01:15:57 -0700 (PDT) (envelope-from saju.pillai@oracle.com) Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g7D8Fut24115 for ; Tue, 13 Aug 2002 01:15:56 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g7D8Ftl24104 for ; Tue, 13 Aug 2002 01:15:55 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g7D8Fsr07032 for ; Tue, 13 Aug 2002 02:15:54 -0600 (MDT) Received: from oracle.com (incq171sc.idc.oracle.com [152.69.202.171]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g7D8Fph06916; Tue, 13 Aug 2002 02:15:52 -0600 (MDT) Message-ID: <3D58C0F5.9C17D340@oracle.com> Date: Tue, 13 Aug 2002 13:49:01 +0530 From: Saju R Pillai X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: TOPCAT CONSULTING Cc: freebsd-net@FreeBSD.ORG Subject: Re: routing problem References: <3D589B14.90E62433@sk.sympatico.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I am not sure if this is correct (I am a CORE Newbie) ...... but I think the first line in your routing table is saying that P3 is connected directly to P1 ( The 'H' flag and absence of a GATEWAY entry. Does deleteing the first line, so that the 'default' entry kicks in, helps ? (or maybe P2 is not configured to fwd packets ? ) regards srp TOPCAT CONSULTING wrote: > I have a dial-up ppp connection from PC_1 to PC_2 set up and working > good. PC_2 has an ethernet network connection as well, connecting to > PC_3 on a different network address > > The ppp connection is from 192.168.0.2 --> 192.168.0.1 > > I need to route as follows: > > from 192.168.0.2 --> 192.168.0.1 --> 10.0.0.1 > in other words from PC_1 --> PC_2 --> PC_3 where 1-->2 is ppp and 2 > -->3 is ethernet > > After the ppp connection from 1 --> 2 is established the route table on > PC_1 is as follows: > > DEST GATEWAY GENMASK FLAGS IFACE > 192.168.0.1 * 255.0.0.0 UH ppp0 > 127.0.0.0 * 255.0.0.0 U lo > default 192.168.0.1 0.0.0.0 UG ppp0 > > pppd is enabled with option "defaultroute" and "proxyarp" at all nodes. > > I can't get from 1 -->3 What might I be missing? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 2:13:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53A9237B400; Tue, 13 Aug 2002 02:13:34 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD86B43E42; Tue, 13 Aug 2002 02:13:33 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7D9DXE04820; Tue, 13 Aug 2002 02:13:33 -0700 (PDT) (envelope-from rizzo) Date: Tue, 13 Aug 2002 02:13:33 -0700 From: Luigi Rizzo To: Ruslan Ermilov Cc: net@FreeBSD.org Subject: Consistency of cached routes Message-ID: <20020813021333.A4507@iguana.icir.org> References: <200208091449.g79EnNRh005472@freefall.freebsd.org> <20020809080953.B62786@iguana.icir.org> <20020811105249.GB11677@sunbay.com> <20020811054337.B84502@iguana.icir.org> <20020812123953.GB41233@sunbay.com> <20020812145105.B148@iguana.icir.org> <20020813085122.GC54451@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020813085122.GC54451@sunbay.com>; from ru@FreeBSD.org on Tue, Aug 13, 2002 at 11:51:22AM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [moved to -net because more relevant there] Summary of previous discussion: ip_forward, ipflow and TCP/UDP sockets cache a copy of the result of route lookups, but these entries might be out-of-date when a routing update is performed. Ruslan just MFC'ed a fix to invalidate the (one-entry) cache in ip_forward, but the other two can still be inconsistent. On Tue, Aug 13, 2002 at 11:51:22AM +0300, Ruslan Ermilov wrote: ... > > so, I have a question here... i believe TCP sockets cache a > > host route to the destination (say 10.0.0.1 in your example), > > possibly cloning one from a more generic one (e.g. 10/8). > > Now how does the invalidation works if someone adds say > > a different 10.0.0/24 route ? The 10/8 is still alive... > > > Yes, this is a known bug, and that is why PR kern/10778 is still > open. ok, so i guess it is time to instrument route lookups and see how expensive they are, and sort out what is the best way to solve the tradeoff between caching and potential inconsistencies. The timestamp idea is good because it has constant cost, though on a box with many routing updates it might completely defeat the cache. The second thing you propose has less impact on the cache, but has potentially a very high cost when doing the route update. Ideas anyone ? This might be a problem with a known efficient solution. cheers luigi > The idea was to add the timestamping facility to the routing table > and for the cache entries. Whenever a new route is added to the > routing table, the routing table's timestamp would get updated, > and all cache entries that were cached earlier would then be pruned > on the first access. > > I then gave up on this idea since I had a somewhat better one: when > a new route is added to the routing table, mark all less-specific > entries with refcnt > 0 as "potentially outdate", and perform the > lazy pruning of cache entries as before. > > What you proposed (to use ipflow hash for IP forwarding) would just > re-introduce this bug there. > > > Cheers, > -- > Ruslan Ermilov Sysadmin and DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 6:57:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50EE937B400; Tue, 13 Aug 2002 06:57:43 -0700 (PDT) Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C047043E75; Tue, 13 Aug 2002 06:57:41 -0700 (PDT) (envelope-from mcambria@avaya.com) Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id <30ZWHJVK>; Tue, 13 Aug 2002 09:57:30 -0400 Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7E4EC98@rerun.avayactc.com> From: "Cambria, Mike" To: 'Julian Elischer' , "Crist J. Clark" Cc: "'freebsd-net@freebsd.org'" Subject: RE: Racoon question Date: Tue, 13 Aug 2002 09:57:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Mon, 12 Aug 2002, Crist J. Clark wrote: > > > On Mon, Aug 12, 2002 at 03:48:56PM -0700, Julian Elischer wrote: > > > > Yeah, known issue which comes up from time to time. It is a common > > headache in IPsec. 'Coulda sworn there was a sysctl(8) to > change this > > behavior, but I can't find it. Nor can I Google anything > except other > > {Free,Net,Open}BSD and Linux people complaining about the > > problem. This IETF draft explains some of the issues, > > > > http://search.ietf.org/internet-drafts/draft-spencer-ipsec-ike-implementatio n-02.txt > > Maybe you can find some of the solutions that have been offered. It's > been discussed on various lists (-net, -security, and -questions) many > times. > > But just so you know, > > > It occured to me that this may be because the racoons need to talk > > across the > > transport connection that is toasted so it's a catch-22. > > > > I tried setting up port 500 as an excpetion using 'none' > > in /etc/ipsec.conf but that seems to confuse things.. it seems unable to > > decide for > > any given connection whether > > to use the [500] or [any] > > sessions. > > This actually is not the problem. IKE/IPsec implementations have to be > smart enough to handle the negotiations "OOB." So how does racoon talk "OOB"? does it add it's own SA? how does it stop it's own packets from being thrown away at the far end when they are not encrypted correctly for the transport layer ipsec? The IKE connection between 2 endpoints (port 500 on both ends usually) does _not_ get protected by a SA. So there should not be any racoon.conf nor IPsec configuration for these ports. Regardless of tunnel mode or transport mode, implementations need to "poke a hole" in the SPD so to speak to allow for this (and possibly other, like DNS) traffic. Just in case you still need it, here is syntax that works for me for racoon.conf and setkey to setup specific ports/protocols. racoon: sainfo address 100.1.1./24 [23] tcp address 100.1.2.0/24 [any] tcp { } setkey: spdadd 10.1.1.0/24[23] 10.1.2.0/24[any] tcp -P in ipsec esp/tunnel/10.1.1.1-10.1.2.1/require ; MikeC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 10:22:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C210D37B400; Tue, 13 Aug 2002 10:22:22 -0700 (PDT) Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5483043E42; Tue, 13 Aug 2002 10:22:22 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id NAA21497; Tue, 13 Aug 2002 13:22:21 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200208131722.NAA21497@wellington.cnchost.com> To: Luigi Rizzo Cc: Ruslan Ermilov , net@FreeBSD.ORG Subject: Re: Consistency of cached routes In-reply-to: Your message of "Tue, 13 Aug 2002 02:13:33 PDT." <20020813021333.A4507@iguana.icir.org> Date: Tue, 13 Aug 2002 10:22:19 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > ip_forward, ipflow and TCP/UDP sockets cache a copy > of the result of route lookups, but these entries might be > out-of-date when a routing update is performed. Ruslan just MFC'ed > a fix to invalidate the (one-entry) cache in ip_forward, but > the other two can still be inconsistent. If a host route to ADDR is cloned from a route to ADDR/n and a route to ADDR/n+k is added, the cloned route to ADDR must be deleted. This is already taken care of in rt_fixchange() -- see the last comment in this function. The next time a pkt to ADDR is delivered, a new ADDR route will be cloned from ADDR/n+k. TCP/UDP sockets cache a host route. If it is a cloned route it will get the above treatment. So the issue is really only for cached net routes that are less specific than a newly added route. Does ipflow cache those? > ok, so i guess it is time to instrument route lookups and see > how expensive they are, and sort out what is the best way to > solve the tradeoff between caching and potential inconsistencies. Any incosistency needs to be fixed. > The timestamp idea is good because it has constant cost, though > on a box with many routing updates it might completely defeat > the cache. You can use a long long counter as a virtual timestamp. Even if you allow a million route changes per second, this number won't roll over for almost 300000 years! But this will cause all cached entries to be flushed any time the route table was updated + every cache use just got a little more expensive. On the other hand now you can afford to keep a bigger cache. Caching just one forwarding entry doesn't make a lot of sense for a router. > Ideas anyone ? This might be a problem with a known efficient solution. I just thought of a simple way. When a route to ADDR/n is added, for all routes to ADD/n-k, (k in 0,1..n) with refcnt > 0, *move* the route entry! That is, allocate a new data structure, do a memcpy from old to new and move its sole route table reference from the old entry to the new entry. Mark the original rtentry data structure as down. It still exists but is not accessible from the route table; it is accessible only from its cached references. Upon next use of such a ref it will be found to be down, so its refcount gets decremented (and the structure deleted when refcnt drops to 0) and a new rtalloc will be done. Second, this entirely avoids the need to walk the whole tree on addition/deletion/change of any route. Third, we can dispense with the silliness of cloned routes alltogether and go back to keeping a separate host route cache. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 10:55:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEE837B400 for ; Tue, 13 Aug 2002 10:55:10 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55A4F43E42 for ; Tue, 13 Aug 2002 10:55:09 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:8050:201:14:65a2:e185:e446:903a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7DHssT05232; Wed, 14 Aug 2002 02:54:54 +0900 (JST) Date: Wed, 14 Aug 2002 02:55:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "George V. Neville-Neil" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: <200208130453.g7D4r9dH018120@mail.meer.net> References: <200208130453.g7D4r9dH018120@mail.meer.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 12 Aug 2002 21:53:09 -0700, >>>>> "George V. Neville-Neil" said: > I'm looking at the -STABLE sources for a bug we're having at work with > a high capacity server that uses UDP. > The bug is that when we run out of mbufs in udp_output() we do NOT > disconnect the socket that caused the error. All error cases goto release: > which > is after the in_pcbdisconnect() call. Is this intentional? I don't think so. The socket should be disconnected before returning the error. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 11:29: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6189337B400 for ; Tue, 13 Aug 2002 11:29:00 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id DFE6043E77 for ; Tue, 13 Aug 2002 11:28:58 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 2313 invoked from network); 13 Aug 2002 18:27:09 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 13 Aug 2002 18:27:09 -0000 Message-ID: <3D594F92.72503A3C@pipeline.ch> Date: Tue, 13 Aug 2002 20:27:30 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Luigi Rizzo , Ruslan Ermilov , net@FreeBSD.ORG Subject: Re: Consistency of cached routes References: <200208131722.NAA21497@wellington.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > Third, we can dispense with the silliness of cloned routes > alltogether and go back to keeping a separate host route > cache. This is being worked on, "tcphostcache". When gets the new FreeBSD developer status report pulished? -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 11:31:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4186137B400 for ; Tue, 13 Aug 2002 11:31:26 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80EA443E77 for ; Tue, 13 Aug 2002 11:31:22 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g7DIU8e31997; Tue, 13 Aug 2002 21:30:08 +0300 (EEST) (envelope-from ru) Date: Tue, 13 Aug 2002 21:30:08 +0300 From: Ruslan Ermilov To: Bakul Shah Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Consistency of cached routes Message-ID: <20020813183008.GA29747@sunbay.com> References: <20020813021333.A4507@iguana.icir.org> <200208131722.NAA21497@wellington.cnchost.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <200208131722.NAA21497@wellington.cnchost.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2002 at 10:22:19AM -0700, Bakul Shah wrote: > > ip_forward, ipflow and TCP/UDP sockets cache a copy > > of the result of route lookups, but these entries might be > > out-of-date when a routing update is performed. Ruslan just MFC'ed > > a fix to invalidate the (one-entry) cache in ip_forward, but > > the other two can still be inconsistent. >=20 > If a host route to ADDR is cloned from a route to ADDR/n and > a route to ADDR/n+k is added, the cloned route to ADDR must > be deleted. This is already taken care of in rt_fixchange() > -- see the last comment in this function. The next time a > pkt to ADDR is delivered, a new ADDR route will be cloned > from ADDR/n+k. >=20 Correct. > TCP/UDP sockets cache a host route. If it is a cloned route > it will get the above treatment. So the issue is really only > for cached net routes that are less specific than a newly > added route. Does ipflow cache those? >=20 Everything that is allocated using rtalloc_ign(, RTF_PRCLONING) should be taken care of (or a raw form using rtalloc1()). > > ok, so i guess it is time to instrument route lookups and see > > how expensive they are, and sort out what is the best way to > > solve the tradeoff between caching and potential inconsistencies. >=20 > Any incosistency needs to be fixed. >=20 > > The timestamp idea is good because it has constant cost, though > > on a box with many routing updates it might completely defeat > > the cache. >=20 > You can use a long long counter as a virtual timestamp. Even > if you allow a million route changes per second, this number > won't roll over for almost 300000 years! But this will cause > all cached entries to be flushed any time the route table was > updated + every cache use just got a little more expensive. > On the other hand now you can afford to keep a bigger cache. > Caching just one forwarding entry doesn't make a lot of sense > for a router. >=20 > > Ideas anyone ? This might be a problem with a known efficient solution. >=20 > I just thought of a simple way. >=20 > When a route to ADDR/n is added, for all routes to ADD/n-k, > (k in 0,1..n) with refcnt > 0, *move* the route entry! That > is, allocate a new data structure, do a memcpy from old to > new and move its sole route table reference from the old > entry to the new entry. Mark the original rtentry data > structure as down. It still exists but is not accessible > from the route table; it is accessible only from its cached > references. Upon next use of such a ref it will be found to > be down, so its refcount gets decremented (and the structure > deleted when refcnt drops to 0) and a new rtalloc will be > done. >=20 Hmm, it has a non-obvious impact on rt_gwroute's, but the idea sounds promising. > Second, this entirely avoids the need to walk the whole tree > on addition/deletion/change of any route. >=20 It was never an intent. > Third, we can dispense with the silliness of cloned routes > alltogether and go back to keeping a separate host route > cache. >=20 Stevens says, in TCP/IP Ill. Vol 2 in section 18.12: : The Patricia tree data structure is well suited to routing tables. : Routing table lookups occur much more frequently than adding or : deleting routes, so from a performance standpoint using Patricia : trees for the routing table makes sense. Patricia trees provide : fast lookups at the expense of additional work in adding and : deleting. Measurements in [Sklower 1991] comparing the radix : tree approach to the Net/1 hash table show that the radix tree : method is about two times faster in building a test tree and : four times faster in searching. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9WVAwUkv4P6juNwoRAt9CAJ9FVrSbs+lD7yce5lyRYo0f5RzMagCfRaG7 K0v5v0ICyXrzknwSiPHTTpc= =7Gn+ -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 11:48:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5B6837B405 for ; Tue, 13 Aug 2002 11:48:37 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BF2543E72 for ; Tue, 13 Aug 2002 11:48:36 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 3196 invoked from network); 13 Aug 2002 18:46:47 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 13 Aug 2002 18:46:47 -0000 Message-ID: <3D59542C.6796FC6D@pipeline.ch> Date: Tue, 13 Aug 2002 20:47:08 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Bakul Shah , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Consistency of cached routes References: <20020813021333.A4507@iguana.icir.org> <200208131722.NAA21497@wellington.cnchost.com> <20020813183008.GA29747@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov wrote: > Stevens says, in TCP/IP Ill. Vol 2 in section 18.12: > > : The Patricia tree data structure is well suited to routing tables. > : Routing table lookups occur much more frequently than adding or > : deleting routes, so from a performance standpoint using Patricia > : trees for the routing table makes sense. Patricia trees provide > : fast lookups at the expense of additional work in adding and > : deleting. Measurements in [Sklower 1991] comparing the radix > : tree approach to the Net/1 hash table show that the radix tree > : method is about two times faster in building a test tree and > : four times faster in searching. This is correct for routing when you have to do a longest match on a prefix. For explicit host routes this is not true. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 11:51:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C54237B400 for ; Tue, 13 Aug 2002 11:51:29 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BE0343E6A for ; Tue, 13 Aug 2002 11:51:28 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813185127.JAWA11061.sccrmhc01.attbi.com@blossom.cjclark.org>; Tue, 13 Aug 2002 18:51:27 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7DIpRJK005121; Tue, 13 Aug 2002 11:51:27 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7DIpPxb005120; Tue, 13 Aug 2002 11:51:25 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 13 Aug 2002 11:51:25 -0700 From: "Crist J. Clark" To: Mike Burgett Cc: Julian Elischer , net@FreeBSD.ORG Subject: Re: Racoon question Message-ID: <20020813185125.GB5009@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020813052619.GD1675@blossom.cjclark.org> <200208131150.g7DBoC4h030141@dragon.awen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208131150.g7DBoC4h030141@dragon.awen.com> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 13, 2002 at 04:50:12AM -0700, Mike Burgett wrote: > On Mon, 12 Aug 2002 22:26:19 -0700, Crist J. Clark wrote: > > >On Mon, Aug 12, 2002 at 03:48:56PM -0700, Julian Elischer wrote: > [ ... ] > >> However I notice that if I have a problem on one system it sometimes > >> needs to wait until the running SA has expired until things can be > >> restarted.. For example if one system is rebooted, I need to reset the > >> racoon on the > >> other system and clear SAs etc. before things can resync. > > > >Yeah, known issue which comes up from time to time. It is a common > >headache in IPsec. 'Coulda sworn there was a sysctl(8) to change this > >behavior, but I can't find it. > > Hello, > > Try : net.key.prefered_oldsa=0 > > This worked for me on a -stable box, awhile back. There it is. Silly me looking for it above net.inet.ipsec. forces me to wonder, "Why _aren't_ this and the other net.key sysctl(8)s actually net.inet.ipsec.key (or something like that)?" I see the code lives in src/sys/netkey, but isn't all of this purely IPsec related? And all of the net.inet.ipsec code actually lives in netinet6, so things are already inconsistent in making sysctl(8) names reflect where something lies in the tree. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 11:53:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4197437B400 for ; Tue, 13 Aug 2002 11:53:48 -0700 (PDT) Received: from daydreamer.dk (213.237.14.128.adsl.ho.worldonline.dk [213.237.14.128]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A74C43E4A for ; Tue, 13 Aug 2002 11:53:47 -0700 (PDT) (envelope-from trm@daydreamer.dk) Received: (qmail 93344 invoked from network); 13 Aug 2002 18:53:52 -0000 Received: from unknown (HELO dpws) (192.168.1.3) by 192.168.1.25 with SMTP; 13 Aug 2002 18:53:52 -0000 Message-ID: <045c01c242fa$8b407630$0301a8c0@dpws> From: "Dennis Pedersen" To: Subject: Date: Tue, 13 Aug 2002 20:52:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org auth 7ade293b unsubscribe freebsd-net trm@daydreamer.dk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 12:11: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D9A537B400 for ; Tue, 13 Aug 2002 12:11:03 -0700 (PDT) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id C429943E42 for ; Tue, 13 Aug 2002 12:11:02 -0700 (PDT) (envelope-from anthonyv@brainlink.com) Received: from [66.228.0.30] (account anthonyv HELO brainlink.com) by brainlink.com (CommuniGate Pro SMTP 3.5.3) with ESMTP id 15097902 for net@freebsd.org; Tue, 13 Aug 2002 14:59:28 -0400 Message-ID: <3D5959BF.7060803@brainlink.com> Date: Tue, 13 Aug 2002 15:10:55 -0400 From: Anthony Volodkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Subject: pppoed in 4.6/4.6.1-RELEASE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I've recently configured a PPPoE server on a 4.3-RELEASE machine and also on a 4.5-PRERELEASE box. On both boxes it works well. My setup involves /usr/libexec/pppoed running as a daemon, which in turn starts a copy of ppp. For the most part, I used this document to set it all up: http://www.rensel.com/wireless/pppoe.cfm Today, I upgraded the 4.5-PRERELEASE machine to 4.6.1-RELEASE and pppoed no longer works. I tried running it with the -d flag to try to diagnose the problem but it appeared that the daemon would simply never receive client requests. Using tcpdump, I verified that the requests do get to the pppoed interface. Did anyone encounter this issue before? I can send ppp configs, and anything else necessary. I would love to use mpd for this task, however it seems to be unable to be a PPPoE server. :( Regards, Anthony Volodkin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 12:38:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8C1937B400; Tue, 13 Aug 2002 12:38:14 -0700 (PDT) Received: from agamemnon.cnchost.com (agamemnon.cnchost.com [207.155.252.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CE2243E65; Tue, 13 Aug 2002 12:38:14 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by agamemnon.cnchost.com id PAA04492; Tue, 13 Aug 2002 15:35:21 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200208131935.PAA04492@agamemnon.cnchost.com> To: Ruslan Ermilov Cc: Bakul Shah , Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Consistency of cached routes In-reply-to: Your message of "Tue, 13 Aug 2002 21:30:08 +0300." <20020813183008.GA29747@sunbay.com> Date: Tue, 13 Aug 2002 12:35:21 -0700 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hmm, it has a non-obvious impact on rt_gwroute's, but the idea > sounds promising. Not a problem as far as I can see. rt_gwroute points to a host route (of a directly connected next hop). If this host route needs to be invalidated (because it is cloned from a less specific route than a newly added one), this will be caught when rt_gwroute gets used for forwarding. I should point at present something very similar occurs when a route is deleted. If a netroute is deleted, all cloned routes are also deleted but routes using such a cloned route don't know about it until they tried to use it. > > Second, this entirely avoids the need to walk the whole tree > > on addition/deletion/change of any route. > > > It was never an intent. What I meant is this: by moving an rtentry we get rid of the treewalking already present in the code to deal with cloned routes (see rtrequest, rt_setgate and rtsock.c). This can be a big expense when you have 50k+ routes in your table! > > Third, we can dispense with the silliness of cloned routes > > alltogether and go back to keeping a separate host route > > cache. > > > Stevens says, in TCP/IP Ill. Vol 2 in section 18.12: > > : The Patricia tree data structure is well suited to routing tables. > : Routing table lookups occur much more frequently than adding or > : deleting routes, so from a performance standpoint using Patricia > : trees for the routing table makes sense. Patricia trees provide > : fast lookups at the expense of additional work in adding and > : deleting. Measurements in [Sklower 1991] comparing the radix > : tree approach to the Net/1 hash table show that the radix tree > : method is about two times faster in building a test tree and > : four times faster in searching. During the "bubble" years a lot of research was done to speed up route lookups: some of these newfangled methods can do a route lookup on the order of a couple of microseconds (on a 200Mhz Ppro). So yes, a separate host route cache doesn't necessarily help performance. My main issue with cloned routes is the complications they introduce. I see them as a different beast from normal routes. It has been a while so I don't remember all the details but for example, a normal route is added either statically or by a routing daemon. A cloned route is created on the fly -- in effect it is kind of a cache. Ideally you don't want to report cloned route changes on a routing socket (the routing daemon doesn't care). There is some duplication of link level information due to both having an arp cache and a cloned route and one can see strange behavior if you change ip address of a directly connected host. I found it simplified things if cloned routes were treated as just another kind of cache. Let me hasten to add, I am only talking about moving out cloned routes, not host routes (added statically or by a routing daemon) which stay in the routing table. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 13: 0:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F26C337B42F for ; Tue, 13 Aug 2002 13:00:32 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1590F43E6E for ; Tue, 13 Aug 2002 13:00:32 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813200031.LRIX13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 13 Aug 2002 20:00:31 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA17968; Tue, 13 Aug 2002 12:54:19 -0700 (PDT) Date: Tue, 13 Aug 2002 12:54:19 -0700 (PDT) From: Julian Elischer To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: "George V. Neville-Neil" , freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 14 Aug 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Mon, 12 Aug 2002 21:53:09 -0700, > >>>>> "George V. Neville-Neil" said: > > > I'm looking at the -STABLE sources for a bug we're having at work with > > a high capacity server that uses UDP. > > > The bug is that when we run out of mbufs in udp_output() we do NOT > > disconnect the socket that caused the error. All error cases goto release: > > which > > is after the in_pcbdisconnect() call. Is this intentional? > > I don't think so. The socket should be disconnected before returning > the error. Why? dropping a udp packet due to lack of local resources shouldn't affect the state of the socket.. just as having a router drop the packet shouldn't affect it.. I don't understnad the question I guess. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 13:31:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43EA737B400 for ; Tue, 13 Aug 2002 13:31:21 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9715C43E72 for ; Tue, 13 Aug 2002 13:31:20 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813203119.MYLK13899.sccrmhc02.attbi.com@blossom.cjclark.org>; Tue, 13 Aug 2002 20:31:19 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7DKVJJK005650; Tue, 13 Aug 2002 13:31:19 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7DKVHEd005649; Tue, 13 Aug 2002 13:31:17 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 13 Aug 2002 13:31:17 -0700 From: "Crist J. Clark" To: Julian Elischer Cc: Julian Elischer , net@FreeBSD.ORG Subject: Re: Racoon question Message-ID: <20020813203117.GD5009@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020813052619.GD1675@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 12, 2002 at 10:42:42PM -0700, Julian Elischer wrote: [snip] > > This actually is not the problem. IKE/IPsec implementations have to be > > smart enough to handle the negotiations "OOB." > > So how does racoon talk "OOB"? does it add it's own SA? > how does it stop it's own packets from being thrown away at the > far end when they are not encrypted correctly for the transport layer > ipsec? I believe racoon(8) does it by forcing a "bypass" policy on the socket it opens for the ISAKMP negotiations. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 13:33:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4A8937B400 for ; Tue, 13 Aug 2002 13:33:11 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79DCC43E6A for ; Tue, 13 Aug 2002 13:33:11 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g7DKX0a76732; Tue, 13 Aug 2002 13:33:00 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.2/8.12.1/meer) with ESMTP id g7DKXAxe020475; Tue, 13 Aug 2002 13:33:10 -0700 (PDT) Message-Id: <200208132033.g7DKXAxe020475@mail.meer.net> To: Julian Elischer Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: Message from Julian Elischer of "Tue, 13 Aug 2002 12:54:19 PDT." Date: Tue, 13 Aug 2002 13:33:10 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org UDP sockets are temporarily connected when the transmit is done in udp_output(). It should be disconnected if there is an error. The target of the goto is a bit late in the function for that. Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 13:54:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5920737B400 for ; Tue, 13 Aug 2002 13:54:42 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BBE143E65 for ; Tue, 13 Aug 2002 13:54:40 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:8050:201:14:65a2:e185:e446:903a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7DKsVT06373; Wed, 14 Aug 2002 05:54:31 +0900 (JST) Date: Wed, 14 Aug 2002 05:54:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Julian Elischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 13 Aug 2002 12:54:19 -0700 (PDT), >>>>> Julian Elischer said: >> > I'm looking at the -STABLE sources for a bug we're having at work with >> > a high capacity server that uses UDP. >> >> > The bug is that when we run out of mbufs in udp_output() we do NOT >> > disconnect the socket that caused the error. All error cases goto release: >> > which >> > is after the in_pcbdisconnect() call. Is this intentional? >> >> I don't think so. The socket should be disconnected before returning >> the error. > Why? > dropping a udp packet due to lack of local resources shouldn't affect the > state of the socket.. just as having a router drop the packet shouldn't > affect it.. I don't understnad the question I guess. I guess I was not clear. I read the original message to mean temporarily connected UDP sockets. With the current code (I'm looking at the rev. 1.64.2.15 of udp_usrreq.c) once the error happens the socket will be locked as connected, and will not be able to receive from other sources than the foreign address (while it should be, because it is not connected by the application). The fix would be like this (btw: we may want to combine the disconnect part to avoid code duplication): --- udp_usrreq.c.orig Tue Aug 13 13:49:50 2002 +++ udp_usrreq.c Tue Aug 13 13:52:34 2002 @@ -704,9 +704,7 @@ M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT); if (m == 0) { error = ENOBUFS; - if (addr) - splx(s); - goto release; + goto disconnect; } /* @@ -741,7 +739,7 @@ #ifdef IPSEC if (ipsec_setsocket(m, inp->inp_socket) != 0) { error = ENOBUFS; - goto release; + goto disconnect; } #endif /*IPSEC*/ error = ip_output(m, inp->inp_options, &inp->inp_route, @@ -754,6 +752,13 @@ splx(s); } return (error); + +disconnect: + if (addr) { + in_pcbdisconnect(inp); + inp->inp_laddr = laddr; /* XXX rehash? */ + splx(s); + } release: m_freem(m); JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 14: 0:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D31D037B418 for ; Tue, 13 Aug 2002 14:00:15 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3130C43E4A for ; Tue, 13 Aug 2002 14:00:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813210014.OFHQ13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 13 Aug 2002 21:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA18194; Tue, 13 Aug 2002 13:53:45 -0700 (PDT) Date: Tue, 13 Aug 2002 13:53:44 -0700 (PDT) From: Julian Elischer To: "George V. Neville-Neil" Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: <200208132033.g7DKXAxe020475@mail.meer.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ah I thought you were talkign about the 'permanent' type of connect, not the 'hack' connect for packet-by-packet stuff. On Tue, 13 Aug 2002, George V. Neville-Neil wrote: > UDP sockets are temporarily connected when the transmit is done in > udp_output(). It should be disconnected if there is an error. The > target of the goto is a bit late in the function for that. > > Later, > George > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 14: 1:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3A5737B400 for ; Tue, 13 Aug 2002 14:01:47 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED9E43E4A for ; Tue, 13 Aug 2002 14:01:47 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g7DL1aa77833; Tue, 13 Aug 2002 14:01:36 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.2/8.12.1/meer) with ESMTP id g7DL1jxe024775; Tue, 13 Aug 2002 14:01:46 -0700 (PDT) Message-Id: <200208132101.g7DL1jxe024775@mail.meer.net> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: Error in UDP output processing? In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Wed, 14 Aug 2002 05:54:38 +0900." Date: Tue, 13 Aug 2002 14:01:45 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes, this is what I would consider the correct fix UNLESS someone knows of a reason to leave the socket like that for some odd reason that I do not fathom. Do I need to put in a PR? Later, GEorge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 22:17:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3328337B400 for ; Tue, 13 Aug 2002 22:17:28 -0700 (PDT) Received: from hotmail.com (f224.law9.hotmail.com [64.4.9.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2B0243E65 for ; Tue, 13 Aug 2002 22:17:27 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Aug 2002 22:17:27 -0700 Received: from 62.217.121.113 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 14 Aug 2002 05:17:27 GMT X-Originating-IP: [62.217.121.113] From: "soheil h" To: freebsd-net@FreeBSD.ORG Subject: DifferentialChecksum libalias RFC1624 Date: Wed, 14 Aug 2002 09:47:27 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Aug 2002 05:17:27.0877 (UTC) FILETIME=[E1C19F50:01C24351] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi list does the function DifferentialChecksum in libalias(3) for RFC1624 works true or not (any bug reported ? ) ? thanx _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 13 22:40:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77A5937B400 for ; Tue, 13 Aug 2002 22:40:44 -0700 (PDT) Received: from patrocles.silby.com (d171.as13.nwbl0.wi.voyager.net [169.207.136.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD4543E6E for ; Tue, 13 Aug 2002 22:40:42 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g7E5iVB1093352; Wed, 14 Aug 2002 00:44:31 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g7E5iTkw093349; Wed, 14 Aug 2002 00:44:30 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 14 Aug 2002 00:44:28 -0500 (CDT) From: Mike Silbersack To: Oleg Polyakov Cc: freebsd-net@freebsd.org Subject: Re: Initial congestion window increase In-Reply-To: <20020812192549.24783.qmail@web10409.mail.yahoo.com> Message-ID: <20020814003743.U93223-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 12 Aug 2002, Oleg Polyakov wrote: > Yes, real world is murky;) > RFC2414 references RFC2415 - Simulation Studies of Increased > Initial TCP Window Size which shows significantly increased > throughput and decreased delays and some increased drop rate - > around 1% more for connections with initial window=3. > It also references RFC2416 - When TCP Starts Up With Four > Packets > Into Only Three Buffers where experiment shows decreased delays > and "no harm" for transmission. I've read those over, and I'm still not sure what to believe. I have a few other TCP things on my plate right now, so I'd rather concentrate on those for the moment. > By the way looking into tcpdump revealed we have initial window > = 2 * mss in case of slowstart_flightsize = 1. I've seen it on > FreeBSD 4.5 and 4.6 . > What is this - an ancient bug in BSD stack? > > If I set slowstart_flightsize to 0 then tcpdump shows we > starting > with initial window 1... Hrm, interesting. If you can figure out how to fix it so that slowstart_flightsize is accurate, that would be appreciated. After that, then maybe we can worry about changing the default. Incidently, I think that the formula min (4*MSS, max (2*MSS, 4380 bytes)) is bogus. We really have three cases: MTU 512 bytes MTU 1500 bytes (and 1480 or whatever PPPoE uses) MTU 9000 bytes (jumbo frames) The formula above would penalize jumbo frames, while sending a lot of packets for the 512 byte case. Just using MSS * X, where X is a constant for all of the above seems like a better idea. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 5:17: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C26A37B400 for ; Wed, 14 Aug 2002 05:17:03 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A8E43E70 for ; Wed, 14 Aug 2002 05:17:02 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g7ECH2Xr028144; Wed, 14 Aug 2002 08:17:02 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g7ECH2wX028143; Wed, 14 Aug 2002 08:17:02 -0400 (EDT) Date: Wed, 14 Aug 2002 08:17:02 -0400 From: Barney Wolff To: Mike Silbersack Cc: Oleg Polyakov , freebsd-net@FreeBSD.ORG Subject: Re: Initial congestion window increase Message-ID: <20020814121701.GA27934@tp.databus.com> References: <20020812192549.24783.qmail@web10409.mail.yahoo.com> <20020814003743.U93223-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020814003743.U93223-100000@patrocles.silby.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You're assuming that the jumbo will be the successful MTU. But at the start of a connection PMTUD has yet to run, and you could be sending jumbos into a choppy link somewhere on the path. The tcp-impl IETF WG had (and the email list still has) a very smart bunch of people with decades of experience with TCP. Those RFCs didn't just come out of somebody's idle thought. Slowstart flightsize doesn't matter a whole lot on a lan (as long as it's at least 2 to compensate for delayed ack) other than for locker-room comparisons with Linux. But it does matter a lot on long pipes, whether fat or thin, and that's where the risk of an overaggressive strategy is that you can congest the Internet. On Wed, Aug 14, 2002 at 12:44:28AM -0500, Mike Silbersack wrote: > > Incidently, I think that the formula > > min (4*MSS, max (2*MSS, 4380 bytes)) > > is bogus. We really have three cases: > > MTU 512 bytes > MTU 1500 bytes (and 1480 or whatever PPPoE uses) > MTU 9000 bytes (jumbo frames) > > The formula above would penalize jumbo frames, while sending a lot of > packets for the 512 byte case. Just using MSS * X, where X is a constant > for all of the above seems like a better idea. -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 8: 5: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 453E837B400 for ; Wed, 14 Aug 2002 08:05:04 -0700 (PDT) Received: from firehouse.net (dsl-64-130-18-61.telocity.com [64.130.18.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 52ED743E3B for ; Wed, 14 Aug 2002 08:05:03 -0700 (PDT) (envelope-from alan-dated-1029769499.cdd32f@clegg.com) Received: (qmail 3480 invoked by uid 85); 14 Aug 2002 15:05:01 -0000 Date: Wed, 14 Aug 2002 11:04:59 -0400 To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: SNMP statistics from bridged interfaces.. (wireless roaming) Message-ID: <20020814110459.A3136@shazam.wetworks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i From: "Alan B. Clegg" X-Delivery-Agent: TMDA/0.52 (Python 2.2 on FreeBSD/i386) X-TMDA-Fingerprint: mcj9pWl/zXmRXDPHd+oZKuG/dZ4 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just created a bridged network to allow two FreeBSD boxes to act as wireless access points in such a way that clients can roam between them, keeping IP address and sessions intact. All of that works like a charm, but now I have a different problem... I initially had each wireless interface on it's own subnet, and as such was able to pull SNMP statistics to show the amount of traffic on the wireless branches, on the backbone, etc.. now, however, with the bridge=20 up and running, SNMP nolonger sees the wireless / wired interfaces, only the primary interface creates statistics, and, thusly, I only see the overall traffic on the backbone. I've looked at the archives of -net, but I don't see anything that addresses this. =20 Does anyone know how/if I can pull out per-interface statistics on bridged interfaces? BTW, I'm using the netgraph bridging method. Thanks, AlanC --=20 | Alan Clegg | Networks | Security | UNIX | 802.11 |=20 "you just have to be smarter than what you're working on." - Scott Lauren --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE9WnGbyJP8xSfQVdsRAvEvAJ9oO954sNvOyuNkX6YMeK+SsiEpbgCfTDBS 0+JKUgmspismheCbZnWxEHg= =aVto -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 9:32:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6866937B400 for ; Wed, 14 Aug 2002 09:32:20 -0700 (PDT) Received: from www.example.org (dhcp-nic-val-26-81.cisco.com [64.103.26.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 62B8243E77 for ; Wed, 14 Aug 2002 09:32:14 -0700 (PDT) (envelope-from molter@tin.it) Received: (qmail 22942 invoked by uid 1000); 14 Aug 2002 16:32:05 -0000 Message-ID: <20020814163205.22941.qmail@cobweb.example.org> Date: Wed, 14 Aug 2002 18:32:05 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Subject: 4-port PCI ethernet card? X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, could you suggest/comment on 2-port or 4-port ethernet cards that work with FreeBSD -stable? Here is what I found on http://www.freebsd.org/releases/4.6R/hardware-i386.html#ETHERNET o Adaptec Duralink PCI Fast Ethernet adapters based on the Adaptec AIC-6915 Fast Ethernet controller chip (sf(4) driver) - ANA-62044 64-bit quad port 10/100baseTX adapter o Texas Instruments ThunderLAN PCI NICs (tl(4) driver) - Compaq Netelligent 10, 10/100, 10/100 Dual-Port thanks marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 9:56:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F38A37B400 for ; Wed, 14 Aug 2002 09:56:22 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD31F43E75 for ; Wed, 14 Aug 2002 09:56:21 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7EGu6wu003231; Wed, 14 Aug 2002 09:56:06 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7EGu6U9003230; Wed, 14 Aug 2002 09:56:06 -0700 Date: Wed, 14 Aug 2002 09:56:06 -0700 From: Brooks Davis To: Bruce Evans Cc: Brooks Davis , "M. Warner Losh" , net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit Message-ID: <20020814095606.A32608@Odin.AC.HMC.Edu> References: <20020730101533.A29988@Odin.AC.HMC.Edu> <20020731041621.H56544-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020731041621.H56544-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, Jul 31, 2002 at 04:22:23AM +1000 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2002 at 04:22:23AM +1000, Bruce Evans wrote: > On Tue, 30 Jul 2002, Brooks Davis wrote: >=20 > > On Mon, Jul 29, 2002 at 10:38:34PM -0600, M. Warner Losh wrote: > > > : @@ -280,8 +280,7 @@ ep_attach(sc) > > > : attached =3D (ifp->if_softc !=3D 0); > > > : > > > : ifp->if_softc =3D sc; > > > : - ifp->if_unit =3D sc->unit; > > > : - ifp->if_name =3D "ep"; > > > : + sprintf(ifp->if_xname, "ep%d", sc->unit); > > > > > > strcpy(ifp->if_xname, device_get_name(sc->dev)); > > > > > > might be better, don't you think? >=20 > I think this point has already been covered better by noticing that the > name is already stored in several other places (not just new-bus). >=20 > > Yes, that's probably better. At least it's one less place that needs to > > know the name of the device. >=20 > Except it gets the name wrong (it should use device_get_nameunit()), and > it is not so clear that the name fits in the buffer. I'm trying to figure out what the best idiom would be. While a >15 character name seems unlikely, we probably shouldn't trust device_get_nameunit(). In that case, I'm not sure what the best thing to use. The obvious thing is strlcpy, but I don't think we have that in the kernel. We could use strncpy with the usual tricks or snprintf. Another option would be something like in if.[ch]: void if_setxnamefromdev(struct ifnet *ifp, device_t dev) { KASSERT(strlen(device_get_nameunit(dev)) < sizeof(ifp->if_xname), ("%s: name too big for if_xname", device_get_nameunit(dev))); strncpy(ifp->if_xname, device_get_nameunit(dev), sizeof(ifp->if_xname) - 1); ifp->if_xname[sizeof(ifp->if_xname) - 1] =3D '\0'; } I kind of like that idea because it means we've got one function to hide the mess and we find out if someone does manage to make a name that's too long. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9WoulXY6L6fI4GtQRAhBgAJ0SYXvqqNY/ywImSNBkv5FcYPGEIgCfXEag nGawHEIyrTdXHGaD5J53P+o= =PDKs -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 10: 3: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A9437B400; Wed, 14 Aug 2002 10:02:46 -0700 (PDT) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4811743E65; Wed, 14 Aug 2002 10:02:46 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 521; Wed, 14 Aug 2002 10:02:44 -0700 Message-ID: <3D5A8D68.AE7B43A5@expertcity.com> Date: Wed, 14 Aug 2002 10:03:36 -0700 From: Steve Francis X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: pmtu-d broken Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I find this hard to believe, but it seem PMTU-D is broken up to and including 4.6.1-RELEASE-p10 (the latest I've tried. Also tried 4.4) The behaviour of FreeBSD is such that when it sends a too large packet, and receives a fragmentation required-DF bit set ICMP, it does not honor it for the packet that caused the ICMP. It does correctly put the new MTU in its cloned route table, and does correctly send future packets in segment of size < the mtu, but it keeps retransmitting the packet that caused the ICMP in the original, too big size, so it never makes it, and just keeps generating more ICMPs. tcpdump examples: First, note that there is no specific entry for 10.4.0.80 dell350-12# netstat -anlr | grep 10.4 10.4.1.55 63.251.224.129 UGHW 1 990 1500 fxp0 10.4.1.58 63.251.224.129 UGHW 7 478339 1420 fxp0 10.4.1.233 63.251.224.129 UGHW3 0 2735 1420 fxp0 dell350-12# From 10.4.0.80, which is on the other side of a VPN tunnel with MTU of 1420 bytes, I do wget: Note that despite the ICMP messages telling it fragmentation is required, the freeBSD box keeps sending 1500 byte packets with DF set. dell350-12# tcpdump -vvi fxp0 host wonko.corp or host 10.16.5.8 tcpdump: listening on fxp0 09:40:25.938609 10.4.0.80.2793 > dell350-12.snv.http: S [tcp sum ok] 3671603378: 3671603378(0) win 16384 ( DF) (ttl 61, id 35804, len 60) 09:40:25.938665 dell350-12.snv.http > 10.4.0.80.2793: S [tcp sum ok] 3749220980: 3749220980(0) ack 3671603379 win 17376 (DF) (ttl 64, id 43056, len 60) 09:40:25.960106 10.4.0.80.2793 > dell350-12.snv.http: . [tcp sum ok] 1:1(0) ack 1 win 17376 (DF) (ttl 61, id 35806, len 52) 09:40:25.961626 10.4.0.80.2793 > dell350-12.snv.http: P 1:147(146) ack 1 win 173 76 (DF) (ttl 61, id 35823, len 198) 09:40:25.961647 dell350-12.snv.http > 10.4.0.80.2793: . [tcp sum ok] 1:1(0) ack 147 win 17230 (DF) (ttl 64, id 43078, l en 52) 09:40:25.962318 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 43079, len 1500 ) 09:40:25.962337 dell350-12.snv.http > 10.4.0.80.2793: . 1449:2897(1448) ack 147 win 17376 (DF) (ttl 64, id 43080, len 1 500) 09:40:25.962352 dell350-12.snv.http > 10.4.0.80.2793: . 2897:4345(1448) ack 147 win 17376 (DF) (ttl 64, id 43081, len 1 500) 09:40:25.963573 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43079, len 1500) (ttl 254, id 16874, len 56) 09:40:25.963696 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43080, len 1500) (ttl 254, id 16875, len 56) 09:40:25.963826 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43081, len 1500) (ttl 254, id 16876, len 56) 09:40:26.953112 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 43456, len 1500 ) 09:40:26.954116 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 43456, len 1500) (ttl 254, id 17435, len 56) 09:40:28.953114 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 44025, len 1500 ) 09:40:28.954114 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 44025, len 1500) (ttl 254, id 18997, len 56) 09:40:32.953061 dell350-12.snv.http > 10.4.0.80.2793: . 1:1449(1448) ack 147 win 17376 (DF) (ttl 64, id 45089, len 1500 ) 09:40:32.954454 10.16.5.8 > dell350-12.snv: icmp: 10.4.0.80 unreachable - need t o frag (mtu 1420) for dell350-12.snv.http > 10.4.0.80.2793: [|tcp] (DF) (ttl 62, id 45089, len 1500) (ttl 254, id 22545, len 56) ^C However, we do see that it correcltly updated the mtu: dell350-12# netstat -anlr | grep 10.4 10.4.0.80 63.251.224.129 UGHW 1 2736 1420 fxp0 10.4.1.55 63.251.224.129 UGHW 1 990 1500 fxp0 10.4.1.58 63.251.224.129 UGHW 7 478423 1420 fxp0 dell350-12# And a repeated wget works fine: dell350-12# tcpdump -vvi fxp0 host wonko.corp or host 10.16.5.8 tcpdump: listening on fxp0 09:40:59.134496 10.4.0.80.1979 > dell350-12.snv.http: S [tcp sum ok] 926911706:9 26911706(0) win 16384 (DF ) (ttl 61, id 38108, len 60) 09:40:59.134532 dell350-12.snv.http > 10.4.0.80.1979: S [tcp sum ok] 422570166:4 22570166(0) ack 926911707 win 16416 (DF) (ttl 64, id 53036, len 60) 09:40:59.156451 10.4.0.80.1979 > dell350-12.snv.http: . [tcp sum ok] 1:1(0) ack 1 win 17376 (DF) (ttl 61, id 38170, len 52) 09:40:59.156820 10.4.0.80.1979 > dell350-12.snv.http: P 1:147(146) ack 1 win 173 76 (DF) (ttl 61, id 38171, len 198) 09:40:59.156842 dell350-12.snv.http > 10.4.0.80.1979: . [tcp sum ok] 1:1(0) ack 147 win 16270 (DF) (ttl 64, id 53037, l en 52) 09:40:59.157780 dell350-12.snv.http > 10.4.0.80.1979: . 1:1369(1368) ack 147 win 16416 (DF) (ttl 64, id 53038, len 1420 ) 09:40:59.157799 dell350-12.snv.http > 10.4.0.80.1979: . 1369:2737(1368) ack 147 win 16416 (DF) (ttl 64, id 53039, len 1 420) 09:40:59.157816 dell350-12.snv.http > 10.4.0.80.1979: . 2737:4105(1368) ack 147 win 16416 (DF) (ttl 64, id 53040, len 1 420) sending nothing larger than 1420 bytes. So freeBSD is behaving in a broken way that violates the RFC, unless I'm much mistaken. Unfortunately, I am not a coder, so cant go poking at source to verify or fix this. (Well, it would take me a very long time.) Anyone care to confirm (and ideally, fix)? I can replicate this at will, so can easily gather more data if people want. TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 10:40:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B06E437B406 for ; Wed, 14 Aug 2002 10:40:12 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C8B43E65 for ; Wed, 14 Aug 2002 10:40:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020814174011.EOSW13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Wed, 14 Aug 2002 17:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA22381; Wed, 14 Aug 2002 10:25:25 -0700 (PDT) Date: Wed, 14 Aug 2002 10:25:23 -0700 (PDT) From: Julian Elischer To: Brooks Davis Cc: Bruce Evans , "M. Warner Losh" , net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit In-Reply-To: <20020814095606.A32608@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 14 Aug 2002, Brooks Davis wrote: > > I'm trying to figure out what the best idiom would be. While a >15 > character name seems unlikely, we probably shouldn't trust > device_get_nameunit(). In that case, I'm not sure what the best thing > to use. The obvious thing is strlcpy, but I don't think we have that in > the kernel. We could use strncpy with the usual tricks or snprintf. > Another option would be something like in if.[ch]: > [...] I'd like to start using symbolic names such as "Chicago_sprint-12" and "New_York_uunet-2" and "San_Francisco_virtella-3" to describe my p2p interfaces.. note that the last one is 24 characters long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 10:59:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83A9237B400 for ; Wed, 14 Aug 2002 10:59:09 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1EBA43E3B for ; Wed, 14 Aug 2002 10:59:08 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7EHx4wu011291; Wed, 14 Aug 2002 10:59:04 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7EHx4g1011290; Wed, 14 Aug 2002 10:59:04 -0700 Date: Wed, 14 Aug 2002 10:59:03 -0700 From: Brooks Davis To: Julian Elischer Cc: Brooks Davis , Bruce Evans , "M. Warner Losh" , net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit Message-ID: <20020814105903.A8808@Odin.AC.HMC.Edu> References: <20020814095606.A32608@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Wed, Aug 14, 2002 at 10:25:23AM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2002 at 10:25:23AM -0700, Julian Elischer wrote: >=20 >=20 > On Wed, 14 Aug 2002, Brooks Davis wrote: > >=20 > > I'm trying to figure out what the best idiom would be. While a >15 > > character name seems unlikely, we probably shouldn't trust > > device_get_nameunit(). In that case, I'm not sure what the best thing > > to use. The obvious thing is strlcpy, but I don't think we have that in > > the kernel. We could use strncpy with the usual tricks or snprintf. > > Another option would be something like in if.[ch]: > >=20 > [...] >=20 > I'd like to start using symbolic names such as > "Chicago_sprint-12" > and=20 > "New_York_uunet-2" > and > "San_Francisco_virtella-3" >=20 > to describe my p2p interfaces.. > note that the last one is 24 characters long What I was actually refering to was >15 character default device names. I'm pretty sure anyone who tried to commit a device with a name like acme_corporation_gigabit_ethernet_controler0 would be taken out back and shot. :-) I'd say we should probably be checking of overflow, just on principle though. If you want to support 24 character names, you'd have to increase IFNAMSIZ, probably to 32 characters which would change a lot of structure sizes. That's not necessicairly all that bad, but I'm sure there are some hardcoded 16's in the kernel. If nothing else, the linux compat stuff would get weird if you had non-ethernet devices which weren't unique in the first 15 characters. IMO, that's a seperate issue for the move to if_xname though it does need to be decided soon if it's a change we want to make since it would break binary compatability pretty badly. I realize that the if_xname change does have a real effect in that it moves us from sort of freeform strings to a fixed length field, but I think it mostly just clarfies an existing limit. After all, IFNAMSIZ appears 92 times in the kernel according to glimpse so I'm sure you'd see all sorts of weird bugs if you set if_name to something really long. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9WppnXY6L6fI4GtQRAtyxAKCtCc/oiB038dMeotzryuuK2liibQCgieNS 3PZ79/wo9cK00aXYBqjbzHE= =WYyM -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 11:26: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5972E37B400 for ; Wed, 14 Aug 2002 11:26:04 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47C9F43E6E for ; Wed, 14 Aug 2002 11:26:03 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.5/8.12.3) with ESMTP id g7EIPr9R067666; Wed, 14 Aug 2002 12:25:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Aug 2002 12:25:15 -0600 (MDT) Message-Id: <20020814.122515.26283996.imp@bsdimp.com> To: brooks@one-eyed-alien.net Cc: julian@elischer.org, bde@zeta.org.au, net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit From: "M. Warner Losh" In-Reply-To: <20020814105903.A8808@Odin.AC.HMC.Edu> References: <20020814095606.A32608@Odin.AC.HMC.Edu> <20020814105903.A8808@Odin.AC.HMC.Edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <20020814105903.A8808@Odin.AC.HMC.Edu> Brooks Davis writes: : > > to use. The obvious thing is strlcpy, but I don't think we have that in : > > the kernel. We could use strncpy with the usual tricks or snprintf. strlcpy is in the kernel now. As for long device names, that's orthogonal to what we're talking about. I'd just go ahead and do this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 11:35:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 724EA37B401 for ; Wed, 14 Aug 2002 11:35:14 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E089443E3B for ; Wed, 14 Aug 2002 11:35:13 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7EIZ9wu016299; Wed, 14 Aug 2002 11:35:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7EIZ94k016298; Wed, 14 Aug 2002 11:35:09 -0700 Date: Wed, 14 Aug 2002 11:35:09 -0700 From: Brooks Davis To: "M. Warner Losh" Cc: brooks@one-eyed-alien.net, julian@elischer.org, bde@zeta.org.au, net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit Message-ID: <20020814113509.A15848@Odin.AC.HMC.Edu> References: <20020814095606.A32608@Odin.AC.HMC.Edu> <20020814105903.A8808@Odin.AC.HMC.Edu> <20020814.122515.26283996.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020814.122515.26283996.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Aug 14, 2002 at 12:25:15PM -0600 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2002 at 12:25:15PM -0600, M. Warner Losh wrote: > In message: <20020814105903.A8808@Odin.AC.HMC.Edu> > Brooks Davis writes: > : > > to use. The obvious thing is strlcpy, but I don't think we have th= at in > : > > the kernel. We could use strncpy with the usual tricks or snprintf. >=20 > strlcpy is in the kernel now. OK, I think I'll use: strlcpy(ifp->if_xname, device_get_nameunit(dev), IFNAMSIZ); > As for long device names, that's orthogonal to what we're talking > about. I'd just go ahead and do this. Yah, it's pretty much unrelated. If anything this should make that change easier. -- Brooks PS. Does anyone have a Perforce for Dummies document handy? I was thinking this might be a good project to give it a try with. --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9WqLcXY6L6fI4GtQRAgy8AKCcoCYFerFWhJicQiCzAqdTXny59QCffkr3 ZFspL8pV6sOFj/T3jjEka0A= =sPp3 -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 12:10:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F97D37B400 for ; Wed, 14 Aug 2002 12:10:54 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3DA43E4A for ; Wed, 14 Aug 2002 12:10:53 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7EJAmwu021990; Wed, 14 Aug 2002 12:10:48 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7EJAm6e021985; Wed, 14 Aug 2002 12:10:48 -0700 Date: Wed, 14 Aug 2002 12:10:48 -0700 From: Brooks Davis To: "M. Warner Losh" Cc: brooks@one-eyed-alien.net, julian@elischer.org, bde@zeta.org.au, net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit Message-ID: <20020814121047.A21107@Odin.AC.HMC.Edu> References: <20020814095606.A32608@Odin.AC.HMC.Edu> <20020814105903.A8808@Odin.AC.HMC.Edu> <20020814.122515.26283996.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020814.122515.26283996.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Aug 14, 2002 at 12:25:15PM -0600 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2002 at 12:25:15PM -0600, M. Warner Losh wrote: > In message: <20020814105903.A8808@Odin.AC.HMC.Edu> > Brooks Davis writes: > : > > to use. The obvious thing is strlcpy, but I don't think we have th= at in > : > > the kernel. We could use strncpy with the usual tricks or snprintf. >=20 > strlcpy is in the kernel now. I'm not seeing it anywhere. Are you sure? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Wqs3XY6L6fI4GtQRAuLXAKCvTc1JhVN356E2+uu1AUNPGbCahACePTli +HqsTBJkhqVyKyjkI0HPf8A= =b1Si -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 13:49:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC28137B400 for ; Wed, 14 Aug 2002 13:49:55 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D8443E4A for ; Wed, 14 Aug 2002 13:49:54 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.5/8.12.3) with ESMTP id g7EKnm9R068169; Wed, 14 Aug 2002 14:49:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Aug 2002 14:17:10 -0600 (MDT) Message-Id: <20020814.141710.82047657.imp@bsdimp.com> To: brooks@one-eyed-alien.net Cc: julian@elischer.org, bde@zeta.org.au, net@FreeBSD.ORG Subject: Re: switching to if_xname from if_name and if_unit From: "M. Warner Losh" In-Reply-To: <20020814121047.A21107@Odin.AC.HMC.Edu> References: <20020814105903.A8808@Odin.AC.HMC.Edu> <20020814.122515.26283996.imp@bsdimp.com> <20020814121047.A21107@Odin.AC.HMC.Edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <20020814121047.A21107@Odin.AC.HMC.Edu> Brooks Davis writes: : On Wed, Aug 14, 2002 at 12:25:15PM -0600, M. Warner Losh wrote: : > In message: <20020814105903.A8808@Odin.AC.HMC.Edu> : > Brooks Davis writes: : > : > > to use. The obvious thing is strlcpy, but I don't think we have that in : > : > > the kernel. We could use strncpy with the usual tricks or snprintf. : > : > strlcpy is in the kernel now. : : I'm not seeing it anywhere. Are you sure? I was sure until I checked :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 20:57:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BA6837B400 for ; Wed, 14 Aug 2002 20:57:44 -0700 (PDT) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C50943E6E for ; Wed, 14 Aug 2002 20:57:43 -0700 (PDT) (envelope-from mike@sentex.net) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.5/8.12.5) with SMTP id g7F3vfMW095222; Wed, 14 Aug 2002 23:57:42 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Marco Molteni Cc: freebsd-net@freebsd.org Subject: Re: 4-port PCI ethernet card? Date: Wed, 14 Aug 2002 23:58:06 -0400 Message-ID: <9g9mluogtircgc6hvj0blhth6iflrmd3pv@4ax.com> References: <20020814163205.22941.qmail@cobweb.example.org> In-Reply-To: <20020814163205.22941.qmail@cobweb.example.org> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 14 Aug 2002 18:32:05 +0200, in sentex.lists.freebsd.net you = wrote: >Hi, > >could you suggest/comment on 2-port or 4-port ethernet cards that work = with >FreeBSD -stable? Dlink DFE-580TX. Works quite well. I have it in my news server which = pushes over 30Mb/s sustained on 3 of the 4 links. http://www.dlink.com/products/adapters/dfe580tx/ uses the dc driver. Plays well with other devices in the same box = (adaptec SCSI and 3ware IDE RAID) dc0: port 0xa800-0xa87f mem 0xf6800000-0xf68003ff irq 12 at device 4.0 on pci2 dc0: Ethernet address: 00:80:c8:cd:35:9d miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0xa400-0xa47f mem 0xf6000000-0xf60003ff irq 11 at device 5.0 on pci2 dc1: Ethernet address: 00:80:c8:cd:35:9e miibus1: on dc1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc2: port 0xa000-0xa07f mem 0xf5800000-0xf58003ff irq 5 at device 6.0 on pci2 dc2: Ethernet address: 00:80:c8:cd:35:9f miibus2: on dc2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc3: port 0x9800-0x987f mem 0xf5000000-0xf50003ff irq 10 at device 7.0 on pci2 dc3: Ethernet address: 00:80:c8:cd:35:a0 miibus3: on dc3 ukphy3: on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto --Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 22: 2:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9028C37B400 for ; Wed, 14 Aug 2002 22:02:16 -0700 (PDT) Received: from patrocles.silby.com (d25.as3.nwbl0.wi.voyager.net [169.207.92.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AB243E6E for ; Wed, 14 Aug 2002 22:02:11 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g7F55wB1097923; Thu, 15 Aug 2002 00:05:58 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g7F55Zer097920; Thu, 15 Aug 2002 00:05:49 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 15 Aug 2002 00:05:35 -0500 (CDT) From: Mike Silbersack To: Barney Wolff Cc: Oleg Polyakov , Subject: Re: Initial congestion window increase In-Reply-To: <20020814121701.GA27934@tp.databus.com> Message-ID: <20020814233935.F97690-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 14 Aug 2002, Barney Wolff wrote: > You're assuming that the jumbo will be the successful MTU. But at > the start of a connection PMTUD has yet to run, and you could be > sending jumbos into a choppy link somewhere on the path. > > The tcp-impl IETF WG had (and the email list still has) a very smart > bunch of people with decades of experience with TCP. Those RFCs > didn't just come out of somebody's idle thought. > > Slowstart flightsize doesn't matter a whole lot on a lan (as long > as it's at least 2 to compensate for delayed ack) other than for > locker-room comparisons with Linux. But it does matter a lot on > long pipes, whether fat or thin, and that's where the risk of > an overaggressive strategy is that you can congest the Internet. Hrm, I'm not sure that PMTUD is a strong enough argument against X*MSS slowstart for gigabit networks. Think about the following cases: 1. Server with MTU 1500, client with MTU 1480 (they're going over PPPoE or something similar.) - All four 1500 byte packets sent back to back, all 4 bounced with ICMP too big messages. Bandwidth wasted: All 4 packets traversing the net, all 4 icmps coming back across the net. 2. Server with MTU 9000, client with MTU 1500. - All four 9000 byte packets sent back to back, bounced back at local border router with MTU of 1500. Bandwidth wasted: Internal network bandwidth only. Perhaps less than 4 packets, if all data fit into a single 9000 byte packet. Considering this, I don't believe that the gigabit host using jumbo frames would be any more harmful than a 100mbps host using normal ethernet frames. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 22:33:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A37837B400 for ; Wed, 14 Aug 2002 22:33:39 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D027E43E65 for ; Wed, 14 Aug 2002 22:33:38 -0700 (PDT) (envelope-from barney@databus.com) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.5/8.12.5) with ESMTP id g7F5XLXr038183; Thu, 15 Aug 2002 01:33:21 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.5/8.12.5/Submit) id g7F5XLjx038182; Thu, 15 Aug 2002 01:33:21 -0400 (EDT) Date: Thu, 15 Aug 2002 01:33:21 -0400 From: Barney Wolff To: Mike Silbersack Cc: Barney Wolff , Oleg Polyakov , freebsd-net@FreeBSD.ORG Subject: Re: Initial congestion window increase Message-ID: <20020815053321.GA37994@tp.databus.com> References: <20020814121701.GA27934@tp.databus.com> <20020814233935.F97690-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020814233935.F97690-100000@patrocles.silby.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org RFC2414-5 say no more than 4380, so your first example is wrong. And why do you assume that the jumbo stops at your border? Lots of people connect over non-local areas at gigE, these days. I don't know that they use jumbo, but I don't know that they don't. Internet congestion is measured in bits, not packets. Links don't care about packets and these days neither do routers. Generally, we should just do what the RFCs say, rather than trying to rethink every issue. It's really quite rare that the TCP RFCs are shown to be wrong, and the people who do it get famous. The OS's that deliberately flout the RFCs get famous too, in another way. On Thu, Aug 15, 2002 at 12:05:35AM -0500, Mike Silbersack wrote: > > Hrm, I'm not sure that PMTUD is a strong enough argument against X*MSS > slowstart for gigabit networks. Think about the following cases: > > 1. Server with MTU 1500, client with MTU 1480 (they're going over PPPoE > or something similar.) > > - All four 1500 byte packets sent back to back, all 4 bounced with ICMP > too big messages. Bandwidth wasted: All 4 packets traversing the net, > all 4 icmps coming back across the net. > > 2. Server with MTU 9000, client with MTU 1500. > > - All four 9000 byte packets sent back to back, bounced back at local > border router with MTU of 1500. Bandwidth wasted: Internal network > bandwidth only. Perhaps less than 4 packets, if all data fit into a > single 9000 byte packet. > > Considering this, I don't believe that the gigabit host using jumbo frames > would be any more harmful than a 100mbps host using normal ethernet > frames. -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 14 23:44:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B0E437B400 for ; Wed, 14 Aug 2002 23:44:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97EA43E4A for ; Wed, 14 Aug 2002 23:44:14 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7F6iAr12235; Wed, 14 Aug 2002 23:44:10 -0700 (PDT) Message-ID: <3D5B4D6D.9080203@isi.edu> Date: Wed, 14 Aug 2002 23:42:53 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff Cc: Mike Silbersack , Oleg Polyakov , freebsd-net@FreeBSD.ORG Subject: Re: Initial congestion window increase References: <20020814121701.GA27934@tp.databus.com> <20020814233935.F97690-100000@patrocles.silby.com> <20020815053321.GA37994@tp.databus.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050800090406080307020603" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050800090406080307020603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barney Wolff wrote: > Generally, we should just do what the RFCs say, rather than trying > to rethink every issue. It's really quite rare that the TCP RFCs > are shown to be wrong, and the people who do it get famous. The > OS's that deliberately flout the RFCs get famous too, in another way. I agree with Barney, haven't seen anything published that would argue against larger initial windows, and since it passed the bar in TSVWG, it should go into the stack. (As should the Eifel mods, once they pass.) BSD used to be the platform of choice for networking research, but it's slowly being surpassed by Linux, which tends to have implementations for new features faster these days. I'm not saying that FreeBSD should deliberately try to add experimental features to its network stack, but once something becomes an RFC, it is beyond discussion as far as the IETF is concerned, and supporting it can only be a good thing IMO. Lars -- Lars Eggert USC Information Sciences Institute --------------ms050800090406080307020603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxNTA2NDI1M1owIwYJKoZIhvcNAQkEMRYEFE8R/+6v/c6z hEQAOu/22EWPX2xrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCwwaFcyjMfovUzJGR0QmMK1qEXdtKNlikwZdmsGd3MPBG4 AgyYBiWiTvM82/fLH1jMBsqLAyX6MlOWaSnZeHQKQxe2xNEAWlUh0+oByhefmbFPs5XVeuXL QgsaBhiWxhRrh3FbNA9UzccMdWnlMXx2iOxMKKNHu1qxweYIcltY7AAAAAAAAA== --------------ms050800090406080307020603-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 7:39:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC56E37B400 for ; Thu, 15 Aug 2002 07:39:12 -0700 (PDT) Received: from terror.org.pl (terror.org.pl [193.219.28.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EACC43E6E for ; Thu, 15 Aug 2002 07:39:12 -0700 (PDT) (envelope-from ofca@terror.org.pl) Received: from ofca (helo=localhost) by terror.org.pl with local-esmtp id 17fLmG-0008OM-00 for ; Thu, 15 Aug 2002 16:39:08 +0200 Date: Thu, 15 Aug 2002 16:39:08 +0200 (CEST) From: Pawel X-X-Sender: ofca@terror.org.pl To: freebsd-net@FreeBSD.org Subject: IPFW + NATd & "real" ident responses (libalias?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I just wanted to ask if it would be a big problem to add some facility allowing identds like oidentd to answer with non-random replies for queries involving machines behind NAT? Such support exists in ipnat, however I prefer using ipfw+natd. This is only feature i'm missing in natd, or is it there already and I missed something? Best regards. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 11:43: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C870937B400; Thu, 15 Aug 2002 11:42:27 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0694B43E42; Thu, 15 Aug 2002 11:42:25 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7FIgGZ43573; Thu, 15 Aug 2002 21:42:16 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7FIg9We001362; Thu, 15 Aug 2002 21:42:09 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3D5BF635.3764C796@FreeBSD.org> Date: Thu, 15 Aug 2002 21:43:01 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: hackers@FreeBSD.org, net@FreeBSD.org Subject: Increasing size of if_flags field in the ifnet structure [patch for review] Content-Type: multipart/mixed; boundary="------------6E58B69EA83C65AC034DB0DB" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------6E58B69EA83C65AC034DB0DB Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Folks, When implementing ability to switch interface into promisc mode using ifconfig(8) I've stumbled into the problem with already exhausted space in the `short if_flags' field in the ifnet structure. I need to allocate one new flag, while we already have 16 IFF_* flags, and even one additional flag which is implemented using currently free if_ipending field of the said structure. Attached patch is aimed at increasing size of if_flags to 32 bits, as well as to clean-up if_ipending abuse. Granted, it will break backward ABI compatibility, but IMO it is not a big problem. Comments and suggestions are greatly appreciated. Thanks! -Maxim --------------6E58B69EA83C65AC034DB0DB Content-Type: text/plain; charset=koi8-r; name="if_flags.32bit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_flags.32bit.patch" Index: src/share/man/man4/netintro.4 =================================================================== RCS file: /home/ncvs/src/share/man/man4/netintro.4,v retrieving revision 1.20 diff -d -u -r1.20 netintro.4 --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 @@ -197,7 +197,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags; + int ifru_flags; int ifru_metric; int ifru_mtu; int ifru_phys; Index: src/share/man/man9/ifnet.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/ifnet.9,v retrieving revision 1.25 diff -d -u -r1.25 ifnet.9 --- src/share/man/man9/ifnet.9 10 Jan 2002 11:57:10 -0000 1.25 +++ src/share/man/man9/ifnet.9 15 Aug 2002 18:33:43 -0000 @@ -284,7 +284,7 @@ (Set by driver, decremented by generic watchdog code.) .It Va if_flags -.Pq Vt short +.Pq Vt int Flags describing operational parameters of this interface (see below). (Manipulated by both driver and generic code.) .It Va if_capabilities Index: src/sys/compat/linux/linux_ioctl.c =================================================================== RCS file: /home/ncvs/src/sys/compat/linux/linux_ioctl.c,v retrieving revision 1.86 diff -d -u -r1.86 linux_ioctl.c --- src/sys/compat/linux/linux_ioctl.c 26 Jun 2002 15:53:11 -0000 1.86 +++ src/sys/compat/linux/linux_ioctl.c 15 Aug 2002 18:33:45 -0000 @@ -1963,7 +1963,7 @@ { l_short flags; - flags = ifp->if_flags; + flags = ifp->if_flags & 0xffff; /* these flags have no Linux equivalent */ flags &= ~(IFF_SMART|IFF_OACTIVE|IFF_SIMPLEX| IFF_LINK0|IFF_LINK1|IFF_LINK2); Index: src/sys/dev/fxp/if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v retrieving revision 1.138 diff -d -u -r1.138 if_fxp.c --- src/sys/dev/fxp/if_fxp.c 9 Aug 2002 01:48:28 -0000 1.138 +++ src/sys/dev/fxp/if_fxp.c 15 Aug 2002 18:33:46 -0000 @@ -1193,7 +1193,7 @@ #ifdef DEVICE_POLLING struct ifnet *ifp = &sc->sc_if; - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) return; if (ether_poll_register(fxp_poll, ifp)) { /* disable interrupts */ @@ -1785,7 +1785,7 @@ * ... but only do that if we are not polling. And because (presumably) * the default is interrupts on, we need to disable them explicitly! */ - if ( ifp->if_ipending & IFF_POLLING ) + if ( ifp->if_flags & IFF_POLLING ) CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE); else #endif /* DEVICE_POLLING */ Index: src/sys/dev/vx/if_vx.c =================================================================== RCS file: /home/ncvs/src/sys/dev/vx/if_vx.c,v retrieving revision 1.36 diff -d -u -r1.36 if_vx.c --- src/sys/dev/vx/if_vx.c 20 Mar 2002 02:07:47 -0000 1.36 +++ src/sys/dev/vx/if_vx.c 15 Aug 2002 18:33:47 -0000 @@ -285,7 +285,7 @@ register struct ifnet *ifp = &sc->arpcom.ac_if; int i, j, k; char *reason, *warning; - static short prev_flags; + static int prev_flags; static char prev_conn = -1; if (prev_conn == -1) { Index: src/sys/kern/kern_poll.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_poll.c,v retrieving revision 1.9 diff -d -u -r1.9 kern_poll.c --- src/sys/kern/kern_poll.c 4 Aug 2002 21:00:49 -0000 1.9 +++ src/sys/kern/kern_poll.c 15 Aug 2002 18:33:48 -0000 @@ -383,7 +383,7 @@ for (i = 0 ; i < poll_handlers ; i++) { if (pr[i].handler && pr[i].ifp->if_flags & IFF_RUNNING) { - pr[i].ifp->if_ipending &= ~IFF_POLLING; + pr[i].ifp->if_flags &= ~IFF_POLLING; pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); } pr[i].handler=NULL; @@ -415,7 +415,7 @@ return 0; if ( !(ifp->if_flags & IFF_UP) ) /* must be up */ return 0; - if (ifp->if_ipending & IFF_POLLING) /* already polling */ + if (ifp->if_flags & IFF_POLLING) /* already polling */ return 0; s = splhigh(); @@ -440,7 +440,7 @@ pr[poll_handlers].handler = h; pr[poll_handlers].ifp = ifp; poll_handlers++; - ifp->if_ipending |= IFF_POLLING; + ifp->if_flags |= IFF_POLLING; splx(s); if (idlepoll_sleeping) wakeup(&idlepoll_sleeping); @@ -459,14 +459,14 @@ int i; mtx_lock(&Giant); - if ( !ifp || !(ifp->if_ipending & IFF_POLLING) ) { + if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { mtx_unlock(&Giant); return 0; } for (i = 0 ; i < poll_handlers ; i++) if (pr[i].ifp == ifp) /* found it */ break; - ifp->if_ipending &= ~IFF_POLLING; /* found or not... */ + ifp->if_flags &= ~IFF_POLLING; /* found or not... */ if (i == poll_handlers) { mtx_unlock(&Giant); printf("ether_poll_deregister: ifp not found!!!\n"); Index: src/sys/net/if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.144 diff -d -u -r1.144 if.c --- src/sys/net/if.c 1 Aug 2002 21:15:53 -0000 1.144 +++ src/sys/net/if.c 15 Aug 2002 18:33:48 -0000 @@ -1438,7 +1438,7 @@ struct ifnet *ifp; struct ifreq *ifr; int error; - short oif_flags; + int oif_flags; switch (cmd) { case SIOCGIFCONF: Index: src/sys/net/if.h =================================================================== RCS file: /home/ncvs/src/sys/net/if.h,v retrieving revision 1.73 diff -d -u -r1.73 if.h --- src/sys/net/if.h 25 May 2002 20:17:04 -0000 1.73 +++ src/sys/net/if.h 15 Aug 2002 18:33:49 -0000 @@ -139,14 +139,6 @@ #define IFF_LINK2 0x4000 /* per link layer defined bit */ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connection */ #define IFF_MULTICAST 0x8000 /* supports multicast */ - -/* - * The following flag(s) ought to go in if_flags, but we cannot change - * struct ifnet because of binary compatibility, so we store them in - * if_ipending, which is not used so far. - * If possible, make sure the value is not conflicting with other - * IFF flags, so we have an easier time when we want to merge them. - */ #define IFF_POLLING 0x10000 /* Interface is in polling mode. */ /* flags set internally only: */ @@ -232,7 +224,7 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags[2]; + int ifru_flags[2]; short ifru_index; int ifru_metric; int ifru_mtu; Index: src/sys/net/if_tap.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_tap.c,v retrieving revision 1.19 diff -d -u -r1.19 if_tap.c --- src/sys/net/if_tap.c 6 May 2002 19:31:28 -0000 1.19 +++ src/sys/net/if_tap.c 15 Aug 2002 18:33:49 -0000 @@ -654,7 +654,7 @@ struct ifnet *ifp = &tp->tap_if; struct tapinfo *tapp = NULL; int s; - short f; + int f; switch (cmd) { case TAPSIFINFO: @@ -728,7 +728,7 @@ break; case VMIO_SIOCSIFFLAGS: /* VMware/VMnet SIOCSIFFLAGS */ - f = *(short *)data; + f = *(int *)data; f &= 0x0fff; f &= ~IFF_CANTCHANGE; f |= IFF_UP; Index: src/sys/net/if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.48 diff -d -u -r1.48 if_var.h --- src/sys/net/if_var.h 14 Aug 2002 01:37:22 -0000 1.48 +++ src/sys/net/if_var.h 15 Aug 2002 18:33:50 -0000 @@ -138,7 +138,7 @@ u_short if_index; /* numeric abbreviation for this if */ short if_unit; /* sub-unit for lower level driver */ short if_timer; /* time 'til if_watchdog called */ - short if_flags; /* up/down, broadcast, etc. */ + int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ int if_ipending; /* interrupts pending */ Index: src/sys/net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.75 diff -d -u -r1.75 rtsock.c --- src/sys/net/rtsock.c 18 Jun 2002 07:42:01 -0000 1.75 +++ src/sys/net/rtsock.c 15 Aug 2002 18:33:51 -0000 @@ -757,7 +757,7 @@ return; ifm = mtod(m, struct if_msghdr *); ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; route_proto.sp_protocol = 0; @@ -958,7 +958,7 @@ ifm = (struct if_msghdr *)w->w_tmem; ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = info.rti_addrs; error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); Index: src/sys/netatm/atm_if.c =================================================================== RCS file: /home/ncvs/src/sys/netatm/atm_if.c,v retrieving revision 1.14 diff -d -u -r1.14 atm_if.c --- src/sys/netatm/atm_if.c 14 Jun 2002 16:59:38 -0000 1.14 +++ src/sys/netatm/atm_if.c 15 Aug 2002 18:33:51 -0000 @@ -1057,7 +1057,7 @@ break; case SIOCGIFFLAGS: - *(short *)data = ifp->if_flags; + *(int *)data = ifp->if_flags; break; case SIOCSIFFLAGS: Index: src/sys/netinet6/in6_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_var.h,v retrieving revision 1.10 diff -d -u -r1.10 in6_var.h --- src/sys/netinet6/in6_var.h 19 Apr 2002 04:46:22 -0000 1.10 +++ src/sys/netinet6/in6_var.h 15 Aug 2002 18:33:51 -0000 @@ -234,7 +234,7 @@ union { struct sockaddr_in6 ifru_addr; struct sockaddr_in6 ifru_dstaddr; - short ifru_flags; + int ifru_flags; int ifru_flags6; int ifru_metric; caddr_t ifru_data; Index: src/sys/nfsclient/bootp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/nfsclient/bootp_subr.c,v retrieving revision 1.41 diff -d -u -r1.41 bootp_subr.c --- src/sys/nfsclient/bootp_subr.c 31 May 2002 11:52:34 -0000 1.41 +++ src/sys/nfsclient/bootp_subr.c 15 Aug 2002 18:33:53 -0000 @@ -385,7 +385,7 @@ printf("%s%d flags %x, addr ", ifp->if_name, ifp->if_unit, - (unsigned short) ifp->if_flags); + ifp->if_flags); print_sin_addr((struct sockaddr_in *) ifa->ifa_addr); printf(", broadcast "); print_sin_addr((struct sockaddr_in *) ifa->ifa_dstaddr); Index: src/sys/pci/if_dc.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.74 diff -d -u -r1.74 if_dc.c --- src/sys/pci/if_dc.c 30 Jun 2002 22:05:46 -0000 1.74 +++ src/sys/pci/if_dc.c 15 Aug 2002 18:33:55 -0000 @@ -2483,7 +2483,7 @@ while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -2885,7 +2885,7 @@ DC_LOCK(sc); ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(dc_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, DC_IMR, 0x00000000); @@ -3265,7 +3265,7 @@ * the case of polling. Some cards (e.g. fxp) turn interrupts on * after a reset. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, DC_IMR, 0x00000000); else #endif Index: src/sys/pci/if_rl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.72 diff -d -u -r1.72 if_rl.c --- src/sys/pci/if_rl.c 30 Jul 2002 17:31:42 -0000 1.72 +++ src/sys/pci/if_rl.c 15 Aug 2002 18:33:56 -0000 @@ -1187,7 +1187,7 @@ while((CSR_READ_1(sc, RL_COMMAND) & RL_CMD_EMPTY_RXBUF) == 0) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1416,7 +1416,7 @@ ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(rl_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_2(sc, RL_IMR, 0x0000); @@ -1654,7 +1654,7 @@ /* * Disable interrupts if we are polling. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_2(sc, RL_IMR, 0); else /* otherwise ... */ #endif /* DEVICE_POLLING */ Index: src/sys/pci/if_sis.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_sis.c,v retrieving revision 1.53 diff -d -u -r1.53 if_sis.c --- src/sys/pci/if_sis.c 7 Aug 2002 16:08:54 -0000 1.53 +++ src/sys/pci/if_sis.c 15 Aug 2002 18:33:57 -0000 @@ -1285,7 +1285,7 @@ while(SIS_OWNDESC(&sc->sis_ldata.sis_rx_list[i])) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1508,7 +1508,7 @@ SIS_LOCK(sc); #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(sis_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, SIS_IER, 0); @@ -1810,7 +1810,7 @@ * ... only enable interrupts if we are not polling, make sure * they are off otherwise. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, SIS_IER, 0); else #endif /* DEVICE_POLLING */ Index: src/usr.sbin/mrouted/config.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mrouted/config.c,v retrieving revision 1.14 diff -d -u -r1.14 config.c --- src/usr.sbin/mrouted/config.c 28 Aug 1999 01:17:03 -0000 1.14 +++ src/usr.sbin/mrouted/config.c 15 Aug 2002 18:33:57 -0000 @@ -32,7 +32,7 @@ register vifi_t vifi; int n; u_int32 addr, mask, subnet; - short flags; + int flags; int num_ifreq = 32; ifc.ifc_len = num_ifreq * sizeof(struct ifreq); --------------6E58B69EA83C65AC034DB0DB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 11:48:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C341C37B400; Thu, 15 Aug 2002 11:48:35 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46AB343E65; Thu, 15 Aug 2002 11:48:35 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7FImXwu022758; Thu, 15 Aug 2002 11:48:33 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7FImXWR022757; Thu, 15 Aug 2002 11:48:33 -0700 Date: Thu, 15 Aug 2002 11:48:33 -0700 From: Brooks Davis To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] Message-ID: <20020815114830.A21334@Odin.AC.HMC.Edu> References: <3D5BF635.3764C796@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5BF635.3764C796@FreeBSD.org>; from sobomax@FreeBSD.ORG on Thu, Aug 15, 2002 at 09:43:01PM +0300 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2002 at 09:43:01PM +0300, Maxim Sobolev wrote: >=20 > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. Sounds reasionable to me. We're going to break the API and ABI shortly for if_xname conversion anyway. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9W/d9XY6L6fI4GtQRAr3vAKCUSyK4GTaJ6GgWK9kQA3MEkr4vDwCgvaSc Js83NCI5VNTe5la9WqMTMFY= =Xecb -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 12: 0:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A48E37B401; Thu, 15 Aug 2002 12:00:24 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427D043E65; Thu, 15 Aug 2002 12:00:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815190021.UEJW1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 19:00:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA27740; Thu, 15 Aug 2002 11:51:00 -0700 (PDT) Date: Thu, 15 Aug 2002 11:50:59 -0700 (PDT) From: Julian Elischer To: Maxim Sobolev Cc: hackers@FreeBSD.org, net@FreeBSD.org Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <3D5BF635.3764C796@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you cannot break ABIs in 4.x in 5.x it will probably be ok until (say) 5.1 or something. On Thu, 15 Aug 2002, Maxim Sobolev wrote: > Folks, > > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. > > Comments and suggestions are greatly appreciated. Thanks! > > -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 13:33:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F68037B400 for ; Thu, 15 Aug 2002 13:33:18 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 060D043E65 for ; Thu, 15 Aug 2002 13:33:18 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7FKXFwu007339 for ; Thu, 15 Aug 2002 13:33:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7FKXFx4007338 for net@freebsd.org; Thu, 15 Aug 2002 13:33:15 -0700 Date: Thu, 15 Aug 2002 13:33:14 -0700 From: Brooks Davis To: net@freebsd.org Subject: adding if_printf() Message-ID: <20020815133314.A5037@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I propose we create a new function if_printf() which is just like device_printf() except that it takes a (struct ifnet *) instead of a device_t. It prints things like: an0: message Since this is what the vast majority of printfs in interface code, using this function would be cleaner and easier. Additionaly, it potentialy gives driver authors a say to keep their source more compatable between 4.x and 5.x after the if_xname conversion. A patch to add if_printf is below. Does this seem like a good idea to other people? -- Brooks Index: if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if.c,v retrieving revision 1.144 diff -u -p -r1.144 if.c --- if.c 1 Aug 2002 21:15:53 -0000 1.144 +++ if.c 15 Aug 2002 19:40:57 -0000 @@ -55,6 +55,7 @@ #include #include #include +#include =20 #include #include @@ -1951,6 +1952,19 @@ ifmaof_ifpforaddr(sa, ifp) break; =20 return ifma; +} + +int +if_printf(struct ifnet *ifp, const char * fmt, ...) +{ + va_list ap; + int retval; + + retval =3D printf("%s%d: ", ifp->if_name, ifp->if_unit); + va_start(ap, fmt); + retval +=3D vprintf(fmt, ap); + va_end(ap); + return (retval); } =20 SYSCTL_NODE(_net, PF_LINK, link, CTLFLAG_RW, 0, "Link layers"); Index: if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/net/if_var.h,v retrieving revision 1.48 diff -u -p -r1.48 if_var.h --- if_var.h 14 Aug 2002 01:37:22 -0000 1.48 +++ if_var.h 15 Aug 2002 20:14:00 -0000 @@ -422,6 +422,7 @@ void if_attach(struct ifnet *); int if_delmulti(struct ifnet *, struct sockaddr *); void if_detach(struct ifnet *); void if_down(struct ifnet *); +int if_printf(struct ifnet *, const char *, ...) __printflike(2, 3); void if_route(struct ifnet *, int flag, int fam); int if_setlladdr(struct ifnet *, const u_char *, int); void if_unroute(struct ifnet *, int flag, int fam); --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9XBAKXY6L6fI4GtQRAszrAJ9VRVhfV908nkgwA9gBqXJeFDcdFwCgm2er 1YMdwVcQAabGdlMPgokXzM0= =+Ok6 -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 16:16:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFB3337B400 for ; Thu, 15 Aug 2002 16:16:54 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 729B743E3B for ; Thu, 15 Aug 2002 16:16:54 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g7FNGSI57701; Thu, 15 Aug 2002 16:16:28 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200208152316.g7FNGSI57701@ambrisko.com> Subject: Re: 4-port PCI ethernet card? In-Reply-To: <9g9mluogtircgc6hvj0blhth6iflrmd3pv@4ax.com> To: Mike Tancsa Date: Thu, 15 Aug 2002 16:16:28 -0700 (PDT) Cc: Marco Molteni , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa writes: | On Wed, 14 Aug 2002 18:32:05 +0200, in sentex.lists.freebsd.net you wrote: | >could you suggest/comment on 2-port or 4-port ethernet cards that work with | >FreeBSD -stable? | | Dlink DFE-580TX. Works quite well. I have it in my news server which pushes | over 30Mb/s sustained on 3 of the 4 links. No that's the DFE-570TX (ie the good one) the DFE-580TX is not so good :-( I commited code to make the 580 behave better and it has been MFC'ed into -stable. The 570 uses the ste(4) driver. The Znyx cards work better since the are dc(4) cards. I have a few around here now that you can only buy the 580 cards. So the 580 is stable now but not a top performer. You won't sustain 30mbs RX on the ports you might get 40mbs total. If you run only one port then you can get good speed. The RX engine appears to hog the bus. | http://www.dlink.com/products/adapters/dfe580tx/ | | uses the dc driver. Plays well with other devices in the same box (adaptec | SCSI and 3ware IDE RAID) Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 15 22:37:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 699F937B401 for ; Thu, 15 Aug 2002 22:37:03 -0700 (PDT) Received: from priv-edtnes15-hme0.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ABCC43E42 for ; Thu, 15 Aug 2002 22:37:02 -0700 (PDT) (envelope-from blah@blah.com) Received: from blah.com ([66.183.134.71]) by priv-edtnes15-hme0.telusplanet.net (InterMail vM.5.01.04.01 201-253-122-122-101-20011014) with ESMTP id <20020816053701.TZPU3365.priv-edtnes15-hme0.telusplanet.net@blah.com> for ; Thu, 15 Aug 2002 23:37:01 -0600 Message-ID: <3D5C90B4.9030705@blah.com> Date: Thu, 15 Aug 2002 22:42:12 -0700 From: Krusty User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020812 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Inconsistent connections when using WinXP and MPD 3.8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'd really appreciate some help on this one... I have mpd3.8 running on FreeBSD 4.5. I have win2k and winXP clients connecting to this server from behind a NAT gateway. The whole reason I went with mpd3.8 was to get the multiple connections from one ip address (which is a big help to me). If I connect using Win2k ( I have a few machines ), they can connect with out any configuration changes, etc... very smooth. If I connect from my WinXP laptop, again, very smooth. If I connect from my WinXP desktop, the connection fails while hanging on the message "Verifying username and password". It then craps out with a usually helpful windows error :) Are there any service packs, critical updates, etc... that affect pptp connections? Because i'm a little confused as to why one XP box can connect, but another can't. Thanks! James I have my mpd logs here from the WinXP desktop connections: mpd: PPTP connection from 123.123.123.123:60966 pptp0: attached to connection with 123.123.123.123:60966 [pptp0] IFACE: Open event [pptp0] IPCP: Open event [pptp0] IPCP: state change Initial --> Starting [pptp0] IPCP: LayerStart [pptp0] IPCP: Open event [pptp0] bundle: OPEN event in state CLOSED [pptp0] opening link "pptp0"... [pptp0] link: OPEN event [pptp0] LCP: Open event [pptp0] LCP: state change Initial --> Starting [pptp0] LCP: LayerStart [pptp0] device: OPEN event in state DOWN [pptp0] attaching to peer's outgoing call [pptp0] device is now in state OPENING [pptp0] device: UP event in state OPENING [pptp0] device is now in state UP [pptp0] link: UP event [pptp0] link: origination is remote [pptp0] LCP: Up event [pptp0] LCP: state change Starting --> Req-Sent [pptp0] LCP: phase shift DEAD --> ESTABLISH [pptp0] LCP: SendConfigReq #11 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 pptp0-0: ignoring SetLinkInfo [pptp0] LCP: SendConfigReq #12 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #13 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #14 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #15 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #16 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #17 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #18 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #19 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: SendConfigReq #20 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 0217860f AUTHPROTO CHAP MSOFTv2 [pptp0] LCP: state change Req-Sent --> Stopped [pptp0] LCP: LayerFinish [pptp0] LCP: parameter negotiation failed [pptp0] LCP: LayerFinish [pptp0] device: CLOSE event in state UP pptp0-0: clearing call pptp0-0: killing channel [pptp0] PPTP call terminated [pptp0] IFACE: Close event [pptp0] IPCP: Close event [pptp0] IPCP: state change Starting --> Initial [pptp0] IPCP: LayerFinish [pptp0] IFACE: Close event pptp0: closing connection with 123.123.123.123:60966 [pptp0] IFACE: Close event [pptp0] device is now in state CLOSING [pptp0] bundle: CLOSE event in state OPENED [pptp0] closing link "pptp0"... [pptp0] device: CLOSE event in state CLOSING [pptp0] device is now in state CLOSING [pptp0] link: CLOSE event [pptp0] LCP: Close event [pptp0] LCP: state change Stopped --> Closed [pptp0] device: DOWN event in state CLOSING [pptp0] device is now in state DOWN [pptp0] link: DOWN event [pptp0] LCP: Down event [pptp0] LCP: state change Closed --> Initial [pptp0] LCP: phase shift ESTABLISH --> DEAD [pptp0] device: DOWN event in state DOWN [pptp0] device is now in state DOWN [pptp0] link: DOWN event [pptp0] LCP: Down event pptp0: killing connection with 123.123.123.123:60966 mpd.conf: default: load pptp0 pptp0: new -i ng0 pptp0 pptp0 set ipcp ranges 10.0.2.1/32 10.0.2.200/32 load pptp-std pptp-std: set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink # for winnt clients set link enable no-orig-auth set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 142.58.103.1 192.75.245.2 set ipcp nbns 10.0.2.100 set bundle enable compression set ccp yes mppc #set ccp yes mpp-compress #set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 1:15:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F412937B400 for ; Fri, 16 Aug 2002 01:15:41 -0700 (PDT) Received: from www.example.org (dhcp-nic-val-26-81.cisco.com [64.103.26.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 549C943E42 for ; Fri, 16 Aug 2002 01:15:35 -0700 (PDT) (envelope-from molter@tin.it) Received: (qmail 30618 invoked by uid 1000); 16 Aug 2002 08:15:31 -0000 Message-ID: <20020816081531.30617.qmail@cobweb.example.org> Date: Fri, 16 Aug 2002 10:15:31 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Subject: SUMMARY: 4-port PCI ethernet card? In-Reply-To: <20020814163205.22941.qmail@cobweb.example.org> References: <20020814163205.22941.qmail@cobweb.example.org> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > could you suggest/comment on 2-port or 4-port ethernet cards that work > with FreeBSD -stable? Thanks everybody who responded. Here is a summary of the replies I got: o The FreeBSD release notes for 4.6 http://www.freebsd.org/releases/4.6R/hardware-i386.html#ETHERNET: + Adaptec Duralink PCI Fast Ethernet adapters based on the Adaptec AIC-6915 Fast Ethernet controller chip (sf(4) driver) - ANA-62044 64-bit quad port 10/100baseTX adapter + Texas Instruments ThunderLAN PCI NICs (tl(4) driver) - Compaq Netelligent 10, 10/100, 10/100 Dual-Port o D-Link DFE-570TX, suggested by 4 persons. http://www.dlink.com/products/adapters/dfe570tx/ o D-Link DFE-580TX, suggested by 2 persons. http://www.dlink.com/products/adapters/dfe580tx/ Seems that the 570 performs better than the 580. New code has just been committed in -current and -stable to make the 580 more stable. o Compaq, unknown model, based on the Intel EtherExpress Pro chip (fxp driver), suggested by 1 person. o Znyx, suggested by 3 persons. (dc/de driver or Znyx-provided driver) http://www.znyx.com/products/hardware/zx340q.htm o Adaptec, suggested by 1 person. o Phobos, now Sonicwall, based on Intel 21143, suggested by 1 person. marco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 3:19:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A648637B400; Fri, 16 Aug 2002 03:19:40 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0D843E81; Fri, 16 Aug 2002 03:19:39 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17feCY-0008Wo-00; Fri, 16 Aug 2002 13:19:30 +0300 Date: Fri, 16 Aug 2002 13:19:30 +0300 (EEST) From: Iasen Kostov To: Julian Elischer Cc: Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: Message-ID: <20020816131654.H18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please take a look at this patch. It implement 1 more flag to if_flags and ofcourse it increases size of this flag field by using if_ipending which is unused. On Thu, 15 Aug 2002, Julian Elischer wrote: > you cannot break ABIs in 4.x > in 5.x it will probably be ok until (say) 5.1 or something. > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > Folks, > > > > When implementing ability to switch interface into promisc mode using > > ifconfig(8) I've stumbled into the problem with already exhausted > > space in the `short if_flags' field in the ifnet structure. I need to > > allocate one new flag, while we already have 16 IFF_* flags, and even > > one additional flag which is implemented using currently free > > if_ipending field of the said structure. Attached patch is aimed at > > increasing size of if_flags to 32 bits, as well as to clean-up > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > but IMO it is not a big problem. > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > -Maxim > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 3:38:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 506D237B405; Fri, 16 Aug 2002 03:38:10 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E2143E42; Fri, 16 Aug 2002 03:38:08 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17feUP-0008m2-00; Fri, 16 Aug 2002 13:37:57 +0300 Date: Fri, 16 Aug 2002 13:37:57 +0300 (EEST) From: Iasen Kostov To: Julian Elischer Cc: Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <20020816131654.H18061-100000@shadowhand.OTEL.net> Message-ID: <20020816133655.U18061-200000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1999923416-1029494277=:18061" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1999923416-1029494277=:18061 Content-Type: TEXT/PLAIN; charset=US-ASCII Ops here is the patch (not enough sleep again :(). On Fri, 16 Aug 2002, Iasen Kostov wrote: > Please take a look at this patch. It implement 1 more flag to if_flags > and ofcourse it increases size of this flag field by using if_ipending > which is unused. > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > you cannot break ABIs in 4.x > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > Folks, > > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > -Maxim > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > --0-1999923416-1029494277=:18061 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ifcflags.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020816133757.Y18061@shadowhand.OTEL.net> Content-Description: Content-Disposition: attachment; filename="ifcflags.patch" LS0tIHN5cy9uZXQvaWYuYwlTdW4gQXByIDI4IDA4OjQwOjI1IDIwMDINCisr KyBzeXMvbmV0L2lmLm15LmMJU2F0IEp1biAgOCAyMDo1MjoxMiAyMDAyDQpA QCAtOTUyLDYgKzk1Miw3IEBADQogCXN0cnVjdCBpZnN0YXQgKmlmczsNCiAJ aW50IGVycm9yOw0KIAlzaG9ydCBvaWZfZmxhZ3M7DQorCWludCBmbGFnc2xv bmc7DQogDQogCXN3aXRjaCAoY21kKSB7DQogDQpAQCAtOTgwLDcgKzk4MSw4 IEBADQogCXN3aXRjaCAoY21kKSB7DQogDQogCWNhc2UgU0lPQ0dJRkZMQUdT Og0KLQkJaWZyLT5pZnJfZmxhZ3MgPSBpZnAtPmlmX2ZsYWdzOw0KKwkJZmxh Z3Nsb25nID0gaWZwLT5pZl9mbGFncyAmIDB4MDAwMGZmZmY7DQorCQlpZnIt Pmlmcl9mbGFnc2xvbmcgPSBmbGFnc2xvbmcgfCBpZnAtPmlmX2lwZW5kaW5n Ow0KIAkJYnJlYWs7DQogDQogCWNhc2UgU0lPQ0dJRkNBUDoNCkBAIC0xMDA0 LDYgKzEwMDYsNyBAQA0KIAkJZXJyb3IgPSBzdXNlcihwKTsNCiAJCWlmIChl cnJvcikNCiAJCQlyZXR1cm4gKGVycm9yKTsNCisJCWlmcC0+aWZfaXBlbmRp bmcgPSBpZnItPmlmcl9mbGFnc2xvbmcgJiAweGZmZmYwMDAwOw0KIAkJaWZy LT5pZnJfcHJldmZsYWdzID0gaWZwLT5pZl9mbGFnczsNCiAJCWlmIChpZnAt PmlmX2ZsYWdzICYgSUZGX1NNQVJUKSB7DQogCQkJLyogU21hcnQgZHJpdmVy cyB0d2lkZGxlIHRoZWlyIG93biByb3V0ZXMgKi8NCi0tLSBzeXMvbmV0L2lm LmgJU3VuIEZlYiAxMCAwMTowMjozOSAyMDAyDQorKysgc3lzL25ldC9pZi5t eS5oCVNhdCBKdW4gIDggMjA6NTI6MjAgMjAwMg0KQEAgLTEzOSw2ICsxMzks NyBAQA0KICAqIElGRiBmbGFncywgc28gd2UgaGF2ZSBhbiBlYXNpZXIgdGlt ZSB3aGVuIHdlIHdhbnQgdG8gbWVyZ2UgdGhlbS4NCiAgKi8NCiAjZGVmaW5l CUlGRl9QT0xMSU5HCTB4MTAwMDAJCS8qIEludGVyZmFjZSBpcyBpbiBwb2xs aW5nIG1vZGUuICovDQorI2RlZmluZQlJRkZfTk9ST1VURQkweDIwMDAwCQkv KiBJbnRlcmZhY2UgZG9lc24ndCBuZWVkIGhvc3Qgcm91dGUuICovDQogDQog LyogZmxhZ3Mgc2V0IGludGVybmFsbHkgb25seTogKi8NCiAjZGVmaW5lCUlG Rl9DQU5UQ0hBTkdFIFwNCkBAIC0yMjQsNiArMjI1LDcgQEANCiAJCXN0cnVj dAlzb2NrYWRkciBpZnJ1X2RzdGFkZHI7DQogCQlzdHJ1Y3QJc29ja2FkZHIg aWZydV9icm9hZGFkZHI7DQogCQlzaG9ydAlpZnJ1X2ZsYWdzWzJdOw0KKwkJ aW50CWlmcnVfZmxhZ3Nsb25nOw0KIAkJaW50CWlmcnVfbWV0cmljOw0KIAkJ aW50CWlmcnVfbXR1Ow0KIAkJaW50CWlmcnVfcGh5czsNCkBAIC0yMzYsNiAr MjM4LDcgQEANCiAjZGVmaW5lCWlmcl9icm9hZGFkZHIJaWZyX2lmcnUuaWZy dV9icm9hZGFkZHIJLyogYnJvYWRjYXN0IGFkZHJlc3MgKi8NCiAjZGVmaW5l CWlmcl9mbGFncwlpZnJfaWZydS5pZnJ1X2ZsYWdzWzBdCS8qIGZsYWdzICov DQogI2RlZmluZQlpZnJfcHJldmZsYWdzCWlmcl9pZnJ1LmlmcnVfZmxhZ3Nb MV0JLyogZmxhZ3MgKi8NCisjZGVmaW5lCWlmcl9mbGFnc2xvbmcJaWZyX2lm cnUuaWZydV9mbGFnc2xvbmcJLyogbG9uZyBmbGFncyAoaW50KSAqLw0KICNk ZWZpbmUJaWZyX21ldHJpYwlpZnJfaWZydS5pZnJ1X21ldHJpYwkvKiBtZXRy aWMgKi8NCiAjZGVmaW5lCWlmcl9tdHUJCWlmcl9pZnJ1LmlmcnVfbXR1CS8q IG10dSAqLw0KICNkZWZpbmUgaWZyX3BoeXMJaWZyX2lmcnUuaWZydV9waHlz CS8qIHBoeXNpY2FsIHdpcmUgKi8NCi0tLSBzYmluL2lmY29uZmlnL2lmY29u ZmlnLmMJV2VkIEFwciAgMyAxNDo0ODo0OCAyMDAyDQorKysgc2Jpbi9pZmNv bmZpZy9pZmNvbmZpZy5teS5jCVNhdCBKdW4gIDggMjE6MDU6MDAgMjAwMg0K QEAgLTIwNSw2ICsyMDUsOCBAQA0KIAl7ICItYWxpYXMiLAktSUZGX1VQLAlu b3RlYWxpYXMgfSwNCiAJeyAiZGVsZXRlIiwJLUlGRl9VUCwJbm90ZWFsaWFz IH0sDQogCXsgInJlbW92ZSIsCS1JRkZfVVAsCW5vdGVhbGlhcyB9LA0KKwl7 ICJub3JvdXRlIiwgICAgSUZGX05PUk9VVEUsICAgIHNldGlmZmxhZ3MgfSwN CisJeyAiLW5vcm91dGUiLCAgIC1JRkZfTk9ST1VURSwgICBzZXRpZmZsYWdz IH0sDQogI2lmZGVmIG5vdGRlZg0KICNkZWZpbmUJRU5fU1dBQklQUwkweDEw MDANCiAJeyAic3dhYmlwcyIsCUVOX1NXQUJJUFMsCXNldGlmZmxhZ3MgfSwN CkBAIC0xMDI4LDE0ICsxMDMwLDE0IEBADQogIAkJZXhpdCgxKTsNCiAgCX0N CiAJc3RybmNweShteV9pZnIuaWZyX25hbWUsIG5hbWUsIHNpemVvZiAobXlf aWZyLmlmcl9uYW1lKSk7DQotIAlmbGFncyA9IG15X2lmci5pZnJfZmxhZ3M7 DQorCWZsYWdzID0gbXlfaWZyLmlmcl9mbGFnc2xvbmc7DQogDQogCWlmICh2 YWx1ZSA8IDApIHsNCiAJCXZhbHVlID0gLXZhbHVlOw0KIAkJZmxhZ3MgJj0g fnZhbHVlOw0KIAl9IGVsc2UNCiAJCWZsYWdzIHw9IHZhbHVlOw0KLQlteV9p ZnIuaWZyX2ZsYWdzID0gZmxhZ3M7DQorCW15X2lmci5pZnJfZmxhZ3Nsb25n ID0gZmxhZ3M7DQogCWlmIChpb2N0bChzLCBTSU9DU0lGRkxBR1MsIChjYWRk cl90KSZteV9pZnIpIDwgMCkNCiAJCVBlcnJvcih2bmFtZSk7DQogfQ0KLS0t IHN5cy9uZXRpbmV0L2luLmMJU2F0IEp1biAgOCAyMToyMToxMiAyMDAyDQor Kysgc3lzL25ldGluZXQvaW4ubXkuYwlTYXQgSnVuICA4IDIwOjUzOjA2IDIw MDINCkBAIC03MzksMTUgKzczOSwxNiBAQA0KIAkgKiBYWFg6IFRoaXMgaXMg dWdseSAhICBUaGVyZSBzaG91bGQgYmUgYSB3YXkgZm9yIHRoZSBjYWxsZXIg dG8NCiAJICogICAgICBzYXkgdGhhdCB0aGV5IGRvbid0IHdhbnQgYSBob3N0 IHJvdXRlLg0KIAkgKi8NCi0JaWYgKGlhLT5pYV9hZGRyLnNpbl9hZGRyLnNf YWRkciAhPSBJTkFERFJfQU5ZIHx8DQotCSAgICBpYS0+aWFfbmV0bWFzayAh PSBJTl9DTEFTU0FfTkVUIHx8DQotCSAgICBpYS0+aWFfZHN0YWRkci5zaW5f YWRkci5zX2FkZHIgIT0gaHRvbmwoSU5fQ0xBU1NBX0hPU1QpKSB7DQotCQlp ZiAoKGVycm9yID0gcnRpbml0KCZpYS0+aWFfaWZhLCAoaW50KVJUTV9BREQs IGZsYWdzKSkgIT0gMCkgew0KLQkJCWlhLT5pYV9hZGRyID0gb2xkYWRkcjsN Ci0JCQkgICAgcmV0dXJuIChlcnJvcik7DQotCQl9DQotCQlpYS0+aWFfZmxh Z3MgfD0gSUZBX1JPVVRFOw0KLQl9DQorCWlmICghKGlmcC0+aWZfaXBlbmRp bmcgJiBJRkZfTk9ST1VURSkpDQorCSAgICBpZiAoaWEtPmlhX2FkZHIuc2lu X2FkZHIuc19hZGRyICE9IElOQUREUl9BTlkgfHwNCisJCWlhLT5pYV9uZXRt YXNrICE9IElOX0NMQVNTQV9ORVQgfHwNCisJCWlhLT5pYV9kc3RhZGRyLnNp bl9hZGRyLnNfYWRkciAhPSBodG9ubChJTl9DTEFTU0FfSE9TVCkpIHsNCisJ CSAgICBpZiAoKGVycm9yID0gcnRpbml0KCZpYS0+aWFfaWZhLCAoaW50KVJU TV9BREQsIGZsYWdzKSkgIT0gMCkgew0KKwkJICAgIAlpYS0+aWFfYWRkciA9 IG9sZGFkZHI7DQorCQkJcmV0dXJuIChlcnJvcik7DQorCQkgICAgfQ0KKwkJ ICAgIGlhLT5pYV9mbGFncyB8PSBJRkFfUk9VVEU7DQorCSAgICB9DQogDQog CS8qDQogCSAqIElmIHRoZSBpbnRlcmZhY2Ugc3VwcG9ydHMgbXVsdGljYXN0 LCBqb2luIHRoZSAiYWxsIGhvc3RzIg0K --0-1999923416-1029494277=:18061-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 4: 1:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 625DA37B400; Fri, 16 Aug 2002 04:01:22 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F82643E70; Fri, 16 Aug 2002 04:01:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA30936; Fri, 16 Aug 2002 11:01:18 GMT Date: Fri, 16 Aug 2002 21:08:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, Subject: Re: Increasing size of if_flags field in the ifnet structure [patch for review] In-Reply-To: <3D5BF635.3764C796@FreeBSD.org> Message-ID: <20020816204055.N6621-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 15 Aug 2002, Maxim Sobolev wrote: > When implementing ability to switch interface into promisc mode using > ifconfig(8) I've stumbled into the problem with already exhausted > space in the `short if_flags' field in the ifnet structure. I need to > allocate one new flag, while we already have 16 IFF_* flags, and even > one additional flag which is implemented using currently free > if_ipending field of the said structure. Attached patch is aimed at > increasing size of if_flags to 32 bits, as well as to clean-up > if_ipending abuse. Granted, it will break backward ABI compatibility, > but IMO it is not a big problem. Why isn't it a bug problem? It affects an application ABI (most socket ioctls). We have whole syscalls whose purpose is to avoid breaking application ABIs back to about 4.3BSD. Some of them may even work. > Index: src/share/man/man4/netintro.4 > =================================================================== > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > retrieving revision 1.20 > diff -d -u -r1.20 netintro.4 > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > @@ -197,7 +197,7 @@ > struct sockaddr ifru_addr; > struct sockaddr ifru_dstaddr; > struct sockaddr ifru_broadaddr; > - short ifru_flags; > + int ifru_flags; > int ifru_metric; > int ifru_mtu; > int ifru_phys; This particular ABI seems to have been broken before (in if.h 1.50 on 1999/02/09), since the actual struct has "short ifru_flags[2];" followed by "short if_index;" instead of "short ifru_flags;", and it has 2 new struct members at the end too. If the struct were actually as above, then changing the short to an int would almost be binary compatible since it would just expand ifru_flags to use the 2 bytes of unnamed padding caused by the poor layout, so the struct wouldn't expand and the other members wouldn't move. Enlarging ifru_flags itself might only break big-endian machines (little-endian ones wouldn't notice providing the padding is zeroed). > Index: src/share/man/man9/ifnet.9 Breaking kernel ABIs isn't so important. They should only be compatible within major releases. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 4:34:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE3EF37B400; Fri, 16 Aug 2002 04:34:24 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF1643E6A; Fri, 16 Aug 2002 04:34:21 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GBY4Z79168; Fri, 16 Aug 2002 14:34:07 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GBXvWe005227; Fri, 16 Aug 2002 14:33:57 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GBXnIX005225; Fri, 16 Aug 2002 14:33:49 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161133.g7GBXnIX005225@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: ikostov@otel.net (Iasen Kostov) Date: Fri, 16 Aug 2002 14:33:49 +0300 (EEST) Cc: julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816131654.H18061-100000@shadowhand.OTEL.net> from "Iasen Kostov" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Please take a look at this patch. It implement 1 more flag to if_flags > and ofcourse it increases size of this flag field by using if_ipending > which is unused. There is no much point in this patch, because it will increase size of struct ifreq, which means that no ioctl's from older apps will be accepted anyway. Therefore, there is no difference between those two, while my approach is obviously cleaner. -Maxim > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > you cannot break ABIs in 4.x > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > Folks, > > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > -Maxim > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5: 8:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B291537B400; Fri, 16 Aug 2002 05:08:49 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B7FA43E3B; Fri, 16 Aug 2002 05:08:48 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17ffu3-000AQU-00; Fri, 16 Aug 2002 15:08:31 +0300 Date: Fri, 16 Aug 2002 15:08:31 +0300 (EEST) From: Iasen Kostov To: Maxim Sobolev Cc: Julian Elischer , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161133.g7GBXnIX005225@vega.vega.com> Message-ID: <20020816150159.T18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > > > Please take a look at this patch. It implement 1 more flag to if_flags > > and ofcourse it increases size of this flag field by using if_ipending > > which is unused. > > There is no much point in this patch, because it will increase size of > struct ifreq, which means that no ioctl's from older apps will be accepted > anyway. Therefore, there is no difference between those two, while my > approach is obviously cleaner. It does not increase size of struct ifreq. This is a union not a struct as You see. union { struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; short ifru_flags[2]; int ifru_flagslong; int ifru_metric; int ifru_mtu; int ifru_phys; int ifru_media; caddr_t ifru_data; int ifru_cap[2]; } ifr_ifru; > > -Maxim > > > > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > > > you cannot break ABIs in 4.x > > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > > > Folks, > > > > > > > > When implementing ability to switch interface into promisc mode using > > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > > space in the `short if_flags' field in the ifnet structure. I need to > > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > > one additional flag which is implemented using currently free > > > > if_ipending field of the said structure. Attached patch is aimed at > > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > > but IMO it is not a big problem. > > > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > > > -Maxim > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5:11:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE3CE37B400; Fri, 16 Aug 2002 05:11:47 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C302B43E72; Fri, 16 Aug 2002 05:11:43 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GCBQZ80641; Fri, 16 Aug 2002 15:11:27 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GCBKWe005352; Fri, 16 Aug 2002 15:11:20 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GCBDrL005351; Fri, 16 Aug 2002 15:11:13 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161211.g7GCBDrL005351@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: bde@zeta.org.au (Bruce Evans) Date: Fri, 16 Aug 2002 15:11:13 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816204055.N6621-100000@gamplex.bde.org> from "Bruce Evans" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > When implementing ability to switch interface into promisc mode using > > ifconfig(8) I've stumbled into the problem with already exhausted > > space in the `short if_flags' field in the ifnet structure. I need to > > allocate one new flag, while we already have 16 IFF_* flags, and even > > one additional flag which is implemented using currently free > > if_ipending field of the said structure. Attached patch is aimed at > > increasing size of if_flags to 32 bits, as well as to clean-up > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > but IMO it is not a big problem. > > Why isn't it a bug problem? It affects an application ABI (most socket > ioctls). We have whole syscalls whose purpose is to avoid breaking > application ABIs back to about 4.3BSD. Some of them may even work. > > > Index: src/share/man/man4/netintro.4 > > =================================================================== > > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > > retrieving revision 1.20 > > diff -d -u -r1.20 netintro.4 > > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > > @@ -197,7 +197,7 @@ > > struct sockaddr ifru_addr; > > struct sockaddr ifru_dstaddr; > > struct sockaddr ifru_broadaddr; > > - short ifru_flags; > > + int ifru_flags; > > int ifru_metric; > > int ifru_mtu; > > int ifru_phys; > > This particular ABI seems to have been broken before (in if.h 1.50 on > 1999/02/09), since the actual struct has "short ifru_flags[2];" followed > by "short if_index;" instead of "short ifru_flags;", and it has 2 new > struct members at the end too. If the struct were actually as above, > then changing the short to an int would almost be binary compatible > since it would just expand ifru_flags to use the 2 bytes of unnamed > padding caused by the poor layout, so the struct wouldn't expand and > the other members wouldn't move. Enlarging ifru_flags itself might > only break big-endian machines (little-endian ones wouldn't notice > providing the padding is zeroed). > > > Index: src/share/man/man9/ifnet.9 > > Breaking kernel ABIs isn't so important. They should only be compatible > within major releases. BTW, I've just realised that we can easily avoid breaking application ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) for storing another 16 flags. What do people think? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5:22:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE54837B400; Fri, 16 Aug 2002 05:22:29 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953C243E65; Fri, 16 Aug 2002 05:22:27 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GCMEZ81179; Fri, 16 Aug 2002 15:22:14 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GCM8We005389; Fri, 16 Aug 2002 15:22:08 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GCM8Rt005388; Fri, 16 Aug 2002 15:22:08 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161222.g7GCM8Rt005388@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: ikostov@otel.net (Iasen Kostov) Date: Fri, 16 Aug 2002 15:22:07 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816150159.T18061-100000@shadowhand.OTEL.net> from "Iasen Kostov" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > There is no much point in this patch, because it will increase size of > > struct ifreq, which means that no ioctl's from older apps will be accepted > > anyway. Therefore, there is no difference between those two, while my > > approach is obviously cleaner. > > It does not increase size of struct ifreq. > This is a union not a struct as You see. Oh, yes, you are obviously correct. However, I still wonder if your patch is endianless-safe. -Maxim > union { > struct sockaddr ifru_addr; > struct sockaddr ifru_dstaddr; > struct sockaddr ifru_broadaddr; > short ifru_flags[2]; > int ifru_flagslong; > int ifru_metric; > int ifru_mtu; > int ifru_phys; > int ifru_media; > caddr_t ifru_data; > int ifru_cap[2]; > } ifr_ifru; > > > > -Maxim > > > > > > > > On Thu, 15 Aug 2002, Julian Elischer wrote: > > > > > > > you cannot break ABIs in 4.x > > > > in 5.x it will probably be ok until (say) 5.1 or something. > > > > > > > > > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > > > > > Folks, > > > > > > > > > > When implementing ability to switch interface into promisc mode using > > > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > > > space in the `short if_flags' field in the ifnet structure. I need to > > > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > > > one additional flag which is implemented using currently free > > > > > if_ipending field of the said structure. Attached patch is aimed at > > > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > > > but IMO it is not a big problem. > > > > > > > > > > Comments and suggestions are greatly appreciated. Thanks! > > > > > > > > > > -Maxim > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5:28:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F7F37B401; Fri, 16 Aug 2002 05:28:30 -0700 (PDT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5067443E65; Fri, 16 Aug 2002 05:28:29 -0700 (PDT) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17fgDB-000AmP-00; Fri, 16 Aug 2002 15:28:17 +0300 Date: Fri, 16 Aug 2002 15:28:17 +0300 (EEST) From: Iasen Kostov To: Maxim Sobolev Cc: Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161211.g7GCBDrL005351@vega.vega.com> Message-ID: <20020816152555.Y18061-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > > > On Thu, 15 Aug 2002, Maxim Sobolev wrote: > > > > > When implementing ability to switch interface into promisc mode using > > > ifconfig(8) I've stumbled into the problem with already exhausted > > > space in the `short if_flags' field in the ifnet structure. I need to > > > allocate one new flag, while we already have 16 IFF_* flags, and even > > > one additional flag which is implemented using currently free > > > if_ipending field of the said structure. Attached patch is aimed at > > > increasing size of if_flags to 32 bits, as well as to clean-up > > > if_ipending abuse. Granted, it will break backward ABI compatibility, > > > but IMO it is not a big problem. > > > > Why isn't it a bug problem? It affects an application ABI (most socket > > ioctls). We have whole syscalls whose purpose is to avoid breaking > > application ABIs back to about 4.3BSD. Some of them may even work. > > > > > Index: src/share/man/man4/netintro.4 > > > =================================================================== > > > RCS file: /home/ncvs/src/share/man/man4/netintro.4,v > > > retrieving revision 1.20 > > > diff -d -u -r1.20 netintro.4 > > > --- src/share/man/man4/netintro.4 18 Mar 2002 12:39:32 -0000 1.20 > > > +++ src/share/man/man4/netintro.4 15 Aug 2002 18:33:42 -0000 > > > @@ -197,7 +197,7 @@ > > > struct sockaddr ifru_addr; > > > struct sockaddr ifru_dstaddr; > > > struct sockaddr ifru_broadaddr; > > > - short ifru_flags; > > > + int ifru_flags; > > > int ifru_metric; > > > int ifru_mtu; > > > int ifru_phys; > > > > This particular ABI seems to have been broken before (in if.h 1.50 on > > 1999/02/09), since the actual struct has "short ifru_flags[2];" followed > > by "short if_index;" instead of "short ifru_flags;", and it has 2 new > > struct members at the end too. If the struct were actually as above, > > then changing the short to an int would almost be binary compatible > > since it would just expand ifru_flags to use the 2 bytes of unnamed > > padding caused by the poor layout, so the struct wouldn't expand and > > the other members wouldn't move. Enlarging ifru_flags itself might > > only break big-endian machines (little-endian ones wouldn't notice > > providing the padding is zeroed). > > > > > Index: src/share/man/man9/ifnet.9 > > > > Breaking kernel ABIs isn't so important. They should only be compatible > > within major releases. > > BTW, I've just realised that we can easily avoid breaking application > ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > for storing another 16 flags. What do people think? If something uses ifr_prevflags this could break compatibility, but if not it is the best solution I think :). > > -Maxim > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5:30:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CAA37B400; Fri, 16 Aug 2002 05:30:16 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2310543E72; Fri, 16 Aug 2002 05:30:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fgEw-0003pR-00; Fri, 16 Aug 2002 05:30:06 -0700 Message-ID: <3D5CEEB8.EFDBF659@mindspring.com> Date: Fri, 16 Aug 2002 05:23:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: Iasen Kostov , Julian Elischer , Maxim Sobolev , hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch References: <200208161222.g7GCM8Rt005388@vega.vega.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Maxim Sobolev wrote: > > > There is no much point in this patch, because it will increase size of > > > struct ifreq, which means that no ioctl's from older apps will be accepted > > > anyway. Therefore, there is no difference between those two, while my > > > approach is obviously cleaner. > > > > It does not increase size of struct ifreq. > > This is a union not a struct as You see. > > Oh, yes, you are obviously correct. However, I still wonder if your patch > is endianless-safe. It's not, unless the structure packing is "just so". First thing I notices, and exactly what Bruce was pointing out when he referred to "other architectures", I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 5:36:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FF3937B401; Fri, 16 Aug 2002 05:36:24 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D9743E6E; Fri, 16 Aug 2002 05:36:22 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GCaF204836; Fri, 16 Aug 2002 14:36:15 +0200 (MEST) Date: Fri, 16 Aug 2002 14:36:15 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161211.g7GCBDrL005351@vega.vega.com> Message-ID: <20020816143437.D24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>BTW, I've just realised that we can easily avoid breaking application MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>for storing another 16 flags. What do people think? The ifr_prevflags may be used by snmp daemons to provide the necessary atomic rollback. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 6:56: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A15837B400; Fri, 16 Aug 2002 06:55:31 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C8A43E6E; Fri, 16 Aug 2002 06:55:28 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GDt8Z84931; Fri, 16 Aug 2002 16:55:08 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GDt1We005701; Fri, 16 Aug 2002 16:55:01 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GDsoup005697; Fri, 16 Aug 2002 16:54:50 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161354.g7GDsoup005697@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: brandt@fokus.gmd.de (Harti Brandt) Date: Fri, 16 Aug 2002 16:54:50 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), bde@zeta.org.au (Bruce Evans), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816143437.D24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.5686.1029506090--%" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --%--multipart-mixed-boundary-1.5686.1029506090--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > MS>BTW, I've just realised that we can easily avoid breaking application > MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > MS>for storing another 16 flags. What do people think? > > The ifr_prevflags may be used by snmp daemons to provide the necessary > atomic rollback. Could you please verify? Nothing in the base system uses it. Initially, ifr_prevflags was added with the following log message (rev.1.50): Since ifru_flags is a short, we can fit in a copy of the flags before they got changed. This can help eliminate much of the gymnastics drivers do in their ioctl routines to figure this out. but no drivers are using it so far. Just in the case, attached is updated patch, which utilises ifr_prevflags for extending ifr_flags. -Maxim --%--multipart-mixed-boundary-1.5686.1029506090--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: 'diff' output text Content-Disposition: attachment; filename="if_flags.32bit.patch" diff -druN src.preflags/sbin/ifconfig/ifconfig.c src/sbin/ifconfig/ifconfig.c --- src.preflags/sbin/ifconfig/ifconfig.c Thu Aug 15 09:47:46 2002 +++ src/sbin/ifconfig/ifconfig.c Fri Aug 16 16:12:09 2002 @@ -999,14 +999,15 @@ exit(1); } strncpy(my_ifr.ifr_name, name, sizeof (my_ifr.ifr_name)); - flags = my_ifr.ifr_flags; + flags = my_ifr.ifr_flags | (my_ifr.ifr_flagshigh << 16); if (value < 0) { value = -value; flags &= ~value; } else flags |= value; - my_ifr.ifr_flags = flags; + my_ifr.ifr_flags = flags & 0xffff; + my_ifr.ifr_flagshigh = flags >> 16; if (ioctl(s, SIOCSIFFLAGS, (caddr_t)&my_ifr) < 0) Perror(vname); } diff -druN src.preflags/share/man/man4/netintro.4 src/share/man/man4/netintro.4 --- src.preflags/share/man/man4/netintro.4 Thu Aug 15 09:47:47 2002 +++ src/share/man/man4/netintro.4 Fri Aug 16 16:11:11 2002 @@ -197,20 +197,21 @@ struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; - short ifru_flags; + short ifru_flags[2]; int ifru_metric; int ifru_mtu; int ifru_phys; caddr_t ifru_data; } ifr_ifru; -#define ifr_addr ifr_ifru.ifru_addr /* address */ -#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ +#define ifr_addr ifr_ifru.ifru_addr /* address */ +#define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ -#define ifr_flags ifr_ifru.ifru_flags /* flags */ -#define ifr_metric ifr_ifru.ifru_metric /* metric */ -#define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ -#define ifr_phys ifr_ifru.ifru_phys /* physical wire */ -#define ifr_data ifr_ifru.ifru_data /* for use by interface */ +#define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ +#define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ +#define ifr_metric ifr_ifru.ifru_metric /* metric */ +#define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ +#define ifr_phys ifr_ifru.ifru_phys /* physical wire */ +#define ifr_data ifr_ifru.ifru_data /* for use by interface */ }; .Ed .Pp diff -druN src.preflags/share/man/man9/ifnet.9 src/share/man/man9/ifnet.9 --- src.preflags/share/man/man9/ifnet.9 Thu Aug 15 09:47:48 2002 +++ src/share/man/man9/ifnet.9 Thu Aug 15 11:36:46 2002 @@ -284,7 +284,7 @@ (Set by driver, decremented by generic watchdog code.) .It Va if_flags -.Pq Vt short +.Pq Vt int Flags describing operational parameters of this interface (see below). (Manipulated by both driver and generic code.) .It Va if_capabilities diff -druN src.preflags/sys/compat/linux/linux_ioctl.c src/sys/compat/linux/linux_ioctl.c --- src.preflags/sys/compat/linux/linux_ioctl.c Thu Aug 15 09:47:48 2002 +++ src/sys/compat/linux/linux_ioctl.c Thu Aug 15 11:48:59 2002 @@ -1963,7 +1963,7 @@ { l_short flags; - flags = ifp->if_flags; + flags = ifp->if_flags & 0xffff; /* these flags have no Linux equivalent */ flags &= ~(IFF_SMART|IFF_OACTIVE|IFF_SIMPLEX| IFF_LINK0|IFF_LINK1|IFF_LINK2); diff -druN src.preflags/sys/dev/fxp/if_fxp.c src/sys/dev/fxp/if_fxp.c --- src.preflags/sys/dev/fxp/if_fxp.c Thu Aug 15 09:47:50 2002 +++ src/sys/dev/fxp/if_fxp.c Thu Aug 15 21:17:11 2002 @@ -1193,7 +1193,7 @@ #ifdef DEVICE_POLLING struct ifnet *ifp = &sc->sc_if; - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) return; if (ether_poll_register(fxp_poll, ifp)) { /* disable interrupts */ @@ -1785,7 +1785,7 @@ * ... but only do that if we are not polling. And because (presumably) * the default is interrupts on, we need to disable them explicitly! */ - if ( ifp->if_ipending & IFF_POLLING ) + if ( ifp->if_flags & IFF_POLLING ) CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE); else #endif /* DEVICE_POLLING */ diff -druN src.preflags/sys/dev/vx/if_vx.c src/sys/dev/vx/if_vx.c --- src.preflags/sys/dev/vx/if_vx.c Thu Aug 15 09:47:57 2002 +++ src/sys/dev/vx/if_vx.c Thu Aug 15 13:51:27 2002 @@ -285,7 +285,7 @@ register struct ifnet *ifp = &sc->arpcom.ac_if; int i, j, k; char *reason, *warning; - static short prev_flags; + static int prev_flags; static char prev_conn = -1; if (prev_conn == -1) { diff -druN src.preflags/sys/kern/kern_poll.c src/sys/kern/kern_poll.c --- src.preflags/sys/kern/kern_poll.c Thu Aug 15 09:47:58 2002 +++ src/sys/kern/kern_poll.c Thu Aug 15 21:18:02 2002 @@ -383,7 +383,7 @@ for (i = 0 ; i < poll_handlers ; i++) { if (pr[i].handler && pr[i].ifp->if_flags & IFF_RUNNING) { - pr[i].ifp->if_ipending &= ~IFF_POLLING; + pr[i].ifp->if_flags &= ~IFF_POLLING; pr[i].handler(pr[i].ifp, POLL_DEREGISTER, 1); } pr[i].handler=NULL; @@ -415,7 +415,7 @@ return 0; if ( !(ifp->if_flags & IFF_UP) ) /* must be up */ return 0; - if (ifp->if_ipending & IFF_POLLING) /* already polling */ + if (ifp->if_flags & IFF_POLLING) /* already polling */ return 0; s = splhigh(); @@ -440,7 +440,7 @@ pr[poll_handlers].handler = h; pr[poll_handlers].ifp = ifp; poll_handlers++; - ifp->if_ipending |= IFF_POLLING; + ifp->if_flags |= IFF_POLLING; splx(s); if (idlepoll_sleeping) wakeup(&idlepoll_sleeping); @@ -459,14 +459,14 @@ int i; mtx_lock(&Giant); - if ( !ifp || !(ifp->if_ipending & IFF_POLLING) ) { + if ( !ifp || !(ifp->if_flags & IFF_POLLING) ) { mtx_unlock(&Giant); return 0; } for (i = 0 ; i < poll_handlers ; i++) if (pr[i].ifp == ifp) /* found it */ break; - ifp->if_ipending &= ~IFF_POLLING; /* found or not... */ + ifp->if_flags &= ~IFF_POLLING; /* found or not... */ if (i == poll_handlers) { mtx_unlock(&Giant); printf("ether_poll_deregister: ifp not found!!!\n"); diff -druN src.preflags/sys/net/if.c src/sys/net/if.c --- src.preflags/sys/net/if.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/if.c Fri Aug 16 16:32:50 2002 @@ -1234,6 +1234,7 @@ struct ifreq *ifr; struct ifstat *ifs; int error = 0; + int new_flags; ifr = (struct ifreq *)data; switch (cmd) { @@ -1242,7 +1243,8 @@ break; case SIOCGIFFLAGS: - ifr->ifr_flags = ifp->if_flags; + ifr->ifr_flags = ifp->if_flags & 0xffff; + ifr->ifr_flagshigh = ifp->if_flags >> 16; break; case SIOCGIFCAP: @@ -1272,22 +1274,22 @@ error = suser(td); if (error) return (error); - ifr->ifr_prevflags = ifp->if_flags; + new_flags = ifr->ifr_flags | (ifr->ifr_flagshigh << 16); if (ifp->if_flags & IFF_SMART) { /* Smart drivers twiddle their own routes */ } else if (ifp->if_flags & IFF_UP && - (ifr->ifr_flags & IFF_UP) == 0) { + (new_flags & IFF_UP) == 0) { int s = splimp(); if_down(ifp); splx(s); - } else if (ifr->ifr_flags & IFF_UP && + } else if (new_flags & IFF_UP && (ifp->if_flags & IFF_UP) == 0) { int s = splimp(); if_up(ifp); splx(s); } ifp->if_flags = (ifp->if_flags & IFF_CANTCHANGE) | - (ifr->ifr_flags &~ IFF_CANTCHANGE); + (new_flags &~ IFF_CANTCHANGE); if (ifp->if_ioctl) (void) (*ifp->if_ioctl)(ifp, cmd, data); getmicrotime(&ifp->if_lastchange); @@ -1438,7 +1440,7 @@ struct ifnet *ifp; struct ifreq *ifr; int error; - short oif_flags; + int oif_flags; switch (cmd) { case SIOCGIFCONF: @@ -1573,7 +1575,8 @@ return (0); ifp->if_flags &= ~IFF_PROMISC; } - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); if (error == 0) { log(LOG_INFO, "%s%d: promiscuous mode %s\n", @@ -1695,7 +1698,8 @@ if (onswitch) { if (ifp->if_amcount++ == 0) { ifp->if_flags |= IFF_ALLMULTI; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = ifp->if_ioctl(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); } } else { @@ -1704,7 +1708,8 @@ } else { ifp->if_amcount = 0; ifp->if_flags &= ~IFF_ALLMULTI; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff;; + ifr.ifr_flagshigh = ifp->if_flags >> 16; error = ifp->if_ioctl(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); } } @@ -1919,10 +1924,12 @@ */ if ((ifp->if_flags & IFF_UP) != 0) { ifp->if_flags &= ~IFF_UP; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); ifp->if_flags |= IFF_UP; - ifr.ifr_flags = ifp->if_flags; + ifr.ifr_flags = ifp->if_flags & 0xffff; + ifr.ifr_flagshigh = ifp->if_flags >> 16; (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t)&ifr); #ifdef INET /* diff -druN src.preflags/sys/net/if.h src/sys/net/if.h --- src.preflags/sys/net/if.h Thu Aug 15 09:47:58 2002 +++ src/sys/net/if.h Fri Aug 16 16:09:01 2002 @@ -139,14 +139,6 @@ #define IFF_LINK2 0x4000 /* per link layer defined bit */ #define IFF_ALTPHYS IFF_LINK2 /* use alternate physical connection */ #define IFF_MULTICAST 0x8000 /* supports multicast */ - -/* - * The following flag(s) ought to go in if_flags, but we cannot change - * struct ifnet because of binary compatibility, so we store them in - * if_ipending, which is not used so far. - * If possible, make sure the value is not conflicting with other - * IFF flags, so we have an easier time when we want to merge them. - */ #define IFF_POLLING 0x10000 /* Interface is in polling mode. */ /* flags set internally only: */ @@ -244,8 +236,8 @@ #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ -#define ifr_flags ifr_ifru.ifru_flags[0] /* flags */ -#define ifr_prevflags ifr_ifru.ifru_flags[1] /* flags */ +#define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ +#define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_metric ifr_ifru.ifru_metric /* metric */ #define ifr_mtu ifr_ifru.ifru_mtu /* mtu */ #define ifr_phys ifr_ifru.ifru_phys /* physical wire */ diff -druN src.preflags/sys/net/if_tap.c src/sys/net/if_tap.c --- src.preflags/sys/net/if_tap.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/if_tap.c Thu Aug 15 19:30:15 2002 @@ -654,7 +654,7 @@ struct ifnet *ifp = &tp->tap_if; struct tapinfo *tapp = NULL; int s; - short f; + int f; switch (cmd) { case TAPSIFINFO: @@ -728,7 +728,7 @@ break; case VMIO_SIOCSIFFLAGS: /* VMware/VMnet SIOCSIFFLAGS */ - f = *(short *)data; + f = *(int *)data; f &= 0x0fff; f &= ~IFF_CANTCHANGE; f |= IFF_UP; diff -druN src.preflags/sys/net/if_var.h src/sys/net/if_var.h --- src.preflags/sys/net/if_var.h Thu Aug 15 09:47:58 2002 +++ src/sys/net/if_var.h Thu Aug 15 19:30:41 2002 @@ -138,7 +138,7 @@ u_short if_index; /* numeric abbreviation for this if */ short if_unit; /* sub-unit for lower level driver */ short if_timer; /* time 'til if_watchdog called */ - short if_flags; /* up/down, broadcast, etc. */ + int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ int if_ipending; /* interrupts pending */ diff -druN src.preflags/sys/net/rtsock.c src/sys/net/rtsock.c --- src.preflags/sys/net/rtsock.c Thu Aug 15 09:47:58 2002 +++ src/sys/net/rtsock.c Thu Aug 15 19:36:03 2002 @@ -757,7 +757,7 @@ return; ifm = mtod(m, struct if_msghdr *); ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; route_proto.sp_protocol = 0; @@ -958,7 +958,7 @@ ifm = (struct if_msghdr *)w->w_tmem; ifm->ifm_index = ifp->if_index; - ifm->ifm_flags = (u_short)ifp->if_flags; + ifm->ifm_flags = ifp->if_flags; ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = info.rti_addrs; error = SYSCTL_OUT(w->w_req,(caddr_t)ifm, len); diff -druN src.preflags/sys/netatm/atm_if.c src/sys/netatm/atm_if.c --- src.preflags/sys/netatm/atm_if.c Thu Aug 15 09:47:58 2002 +++ src/sys/netatm/atm_if.c Thu Aug 15 21:32:44 2002 @@ -1057,7 +1057,7 @@ break; case SIOCGIFFLAGS: - *(short *)data = ifp->if_flags; + *(int *)data = ifp->if_flags; break; case SIOCSIFFLAGS: diff -druN src.preflags/sys/netinet6/in6_var.h src/sys/netinet6/in6_var.h --- src.preflags/sys/netinet6/in6_var.h Thu Aug 15 09:47:58 2002 +++ src/sys/netinet6/in6_var.h Thu Aug 15 20:24:38 2002 @@ -234,7 +234,7 @@ union { struct sockaddr_in6 ifru_addr; struct sockaddr_in6 ifru_dstaddr; - short ifru_flags; + int ifru_flags; int ifru_flags6; int ifru_metric; caddr_t ifru_data; diff -druN src.preflags/sys/nfsclient/bootp_subr.c src/sys/nfsclient/bootp_subr.c --- src.preflags/sys/nfsclient/bootp_subr.c Thu Aug 15 09:47:59 2002 +++ src/sys/nfsclient/bootp_subr.c Thu Aug 15 20:38:55 2002 @@ -385,7 +385,7 @@ printf("%s%d flags %x, addr ", ifp->if_name, ifp->if_unit, - (unsigned short) ifp->if_flags); + ifp->if_flags); print_sin_addr((struct sockaddr_in *) ifa->ifa_addr); printf(", broadcast "); print_sin_addr((struct sockaddr_in *) ifa->ifa_dstaddr); diff -druN src.preflags/sys/pci/if_dc.c src/sys/pci/if_dc.c --- src.preflags/sys/pci/if_dc.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_dc.c Thu Aug 15 21:18:57 2002 @@ -2483,7 +2483,7 @@ while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -2885,7 +2885,7 @@ DC_LOCK(sc); ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(dc_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, DC_IMR, 0x00000000); @@ -3265,7 +3265,7 @@ * the case of polling. Some cards (e.g. fxp) turn interrupts on * after a reset. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, DC_IMR, 0x00000000); else #endif diff -druN src.preflags/sys/pci/if_rl.c src/sys/pci/if_rl.c --- src.preflags/sys/pci/if_rl.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_rl.c Thu Aug 15 21:18:25 2002 @@ -1187,7 +1187,7 @@ while((CSR_READ_1(sc, RL_COMMAND) & RL_CMD_EMPTY_RXBUF) == 0) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1416,7 +1416,7 @@ ifp = &sc->arpcom.ac_if; #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(rl_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_2(sc, RL_IMR, 0x0000); @@ -1654,7 +1654,7 @@ /* * Disable interrupts if we are polling. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_2(sc, RL_IMR, 0); else /* otherwise ... */ #endif /* DEVICE_POLLING */ diff -druN src.preflags/sys/pci/if_sis.c src/sys/pci/if_sis.c --- src.preflags/sys/pci/if_sis.c Thu Aug 15 09:47:59 2002 +++ src/sys/pci/if_sis.c Thu Aug 15 21:18:41 2002 @@ -1285,7 +1285,7 @@ while(SIS_OWNDESC(&sc->sis_ldata.sis_rx_list[i])) { #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) { + if (ifp->if_flags & IFF_POLLING) { if (sc->rxcycles <= 0) break; sc->rxcycles--; @@ -1508,7 +1508,7 @@ SIS_LOCK(sc); #ifdef DEVICE_POLLING - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) goto done; if (ether_poll_register(sis_poll, ifp)) { /* ok, disable interrupts */ CSR_WRITE_4(sc, SIS_IER, 0); @@ -1810,7 +1810,7 @@ * ... only enable interrupts if we are not polling, make sure * they are off otherwise. */ - if (ifp->if_ipending & IFF_POLLING) + if (ifp->if_flags & IFF_POLLING) CSR_WRITE_4(sc, SIS_IER, 0); else #endif /* DEVICE_POLLING */ diff -druN src.preflags/usr.sbin/mrouted/config.c src/usr.sbin/mrouted/config.c --- src.preflags/usr.sbin/mrouted/config.c Thu Aug 15 09:48:00 2002 +++ src/usr.sbin/mrouted/config.c Thu Aug 15 20:59:36 2002 @@ -32,7 +32,7 @@ register vifi_t vifi; int n; u_int32 addr, mask, subnet; - short flags; + int flags; int num_ifreq = 32; ifc.ifc_len = num_ifreq * sizeof(struct ifreq); --%--multipart-mixed-boundary-1.5686.1029506090--%-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 7:13:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0661E37B400; Fri, 16 Aug 2002 07:13:46 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D27943E3B; Fri, 16 Aug 2002 07:13:44 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GEDV222632; Fri, 16 Aug 2002 16:13:31 +0200 (MEST) Date: Fri, 16 Aug 2002 16:13:31 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Harti Brandt , Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161354.g7GDsoup005697@vega.vega.com> Message-ID: <20020816160306.S24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020816160306.B24938@beagle.fokus.gmd.de> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>BTW, I've just realised that we can easily avoid breaking application MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> atomic rollback. MS> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>ifr_prevflags was added with the following log message (rev.1.50): MS> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS> before they got changed. This can help eliminate much of the MS> gymnastics drivers do in their ioctl routines to figure this out. MS> MS>but no drivers are using it so far. I veryfied only net-snmp-current. It doesn't use it (I guess that variable is not SNMP-writeable in net-snmp). I use it however in the bsnmp daemon for NgATM. Its the only way to guarantee the atomicity required by SNMP. Removing something from the ABI which you cannot do otherwise from userspace is always a problem, because it may break 3rd party software (I mean not binary breakage, but functional breakage). Well, while thinking about it: With a user settable PROXY flag there is no way for an application to find out whether the flag was already set or not if the application sets it, excpect by inspecting the ifr_prevflags field. So two applications fiddling with this bit may entirly confuse each other. Count me as a vote for keeping the field and breaking binary compatibility instead of functionality. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 7:27: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CAA37B400; Fri, 16 Aug 2002 07:27:01 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8225243E6E; Fri, 16 Aug 2002 07:26:59 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226] (may be forged)) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g7GEQhZ86553; Fri, 16 Aug 2002 17:26:44 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.5/8.11.3) with ESMTP id g7GEQbWe005814; Fri, 16 Aug 2002 17:26:37 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.5/8.12.5/Submit) id g7GEQaxc005813; Fri, 16 Aug 2002 17:26:36 +0300 (EEST) From: Maxim Sobolev Message-Id: <200208161426.g7GEQaxc005813@vega.vega.com> Subject: Re: Increasing size of if_flags field in the ifnet structure [patch To: brandt@fokus.gmd.de (Harti Brandt) Date: Fri, 16 Aug 2002 17:26:36 +0300 (EEST) Cc: max@vega.com (Maxim Sobolev), brandt@fokus.gmd.de (Harti Brandt), bde@zeta.org.au (Bruce Evans), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <20020816160306.S24938-100000@beagle.fokus.gmd.de> from "Harti Brandt" at Á×Ç 16, 2002 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > On Fri, 16 Aug 2002, Maxim Sobolev wrote: > > MS>> > MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: > MS>> > MS>> MS>BTW, I've just realised that we can easily avoid breaking application > MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) > MS>> MS>for storing another 16 flags. What do people think? > MS>> > MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary > MS>> atomic rollback. > MS> > MS>Could you please verify? Nothing in the base system uses it. Initially, > MS>ifr_prevflags was added with the following log message (rev.1.50): > MS> > MS> Since ifru_flags is a short, we can fit in a copy of the flags > MS> before they got changed. This can help eliminate much of the > MS> gymnastics drivers do in their ioctl routines to figure this out. > MS> > MS>but no drivers are using it so far. > > I veryfied only net-snmp-current. It doesn't use it (I guess that > variable is not SNMP-writeable in net-snmp). I use it however in the > bsnmp daemon for NgATM. Its the only way to guarantee the atomicity > required by SNMP. > > Removing something from the ABI which you cannot do otherwise from > userspace is always a problem, because it may break 3rd party software > (I mean not binary breakage, but functional breakage). > > Well, while thinking about it: With a user settable PROXY flag there is no > way for an application to find out whether the flag was already set or not > if the application sets it, excpect by inspecting the ifr_prevflags field. > So two applications fiddling with this bit may entirly confuse each other. > Count me as a vote for keeping the field and breaking binary compatibility > instead of functionality. Hmm, I do not really see how this flag may help your application. To set or reset some flag from if_flags you have to read current values of those flags, so that you can use that value instead of ifr_prevflags. Of course it introduces some tiny race condition, but I do not see how presence of ifr_prevflags can help you in this case. Moreover, possibility of such race IMO is quite low, as interface flags are usually updated very rarely. Instead your bsnmp daemons should be using other ways to serialise write access to interface flags (e.g. lock file). -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 7:34:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA53A37B400; Fri, 16 Aug 2002 07:34:36 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BED843E6A; Fri, 16 Aug 2002 07:34:35 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7GEYP226473; Fri, 16 Aug 2002 16:34:26 +0200 (MEST) Date: Fri, 16 Aug 2002 16:34:25 +0200 (CEST) From: Harti Brandt To: Maxim Sobolev Cc: Harti Brandt , Bruce Evans , Maxim Sobolev , , Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161426.g7GEQaxc005813@vega.vega.com> Message-ID: <20020816162923.S24938-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>> On Fri, 16 Aug 2002, Maxim Sobolev wrote: MS>> MS>> MS>> MS>> MS>BTW, I've just realised that we can easily avoid breaking application MS>> MS>> MS>ABI by using currently unused ifr_ifru.ifru_flags[2] (aka. ifr_prevflags) MS>> MS>> MS>for storing another 16 flags. What do people think? MS>> MS>> MS>> MS>> The ifr_prevflags may be used by snmp daemons to provide the necessary MS>> MS>> atomic rollback. MS>> MS> MS>> MS>Could you please verify? Nothing in the base system uses it. Initially, MS>> MS>ifr_prevflags was added with the following log message (rev.1.50): MS>> MS> MS>> MS> Since ifru_flags is a short, we can fit in a copy of the flags MS>> MS> before they got changed. This can help eliminate much of the MS>> MS> gymnastics drivers do in their ioctl routines to figure this out. MS>> MS> MS>> MS>but no drivers are using it so far. MS>> MS>> I veryfied only net-snmp-current. It doesn't use it (I guess that MS>> variable is not SNMP-writeable in net-snmp). I use it however in the MS>> bsnmp daemon for NgATM. Its the only way to guarantee the atomicity MS>> required by SNMP. MS>> MS>> Removing something from the ABI which you cannot do otherwise from MS>> userspace is always a problem, because it may break 3rd party software MS>> (I mean not binary breakage, but functional breakage). MS>> MS>> Well, while thinking about it: With a user settable PROXY flag there is no MS>> way for an application to find out whether the flag was already set or not MS>> if the application sets it, excpect by inspecting the ifr_prevflags field. MS>> So two applications fiddling with this bit may entirly confuse each other. MS>> Count me as a vote for keeping the field and breaking binary compatibility MS>> instead of functionality. MS> MS>Hmm, I do not really see how this flag may help your application. To set or MS>reset some flag from if_flags you have to read current values of those MS>flags, so that you can use that value instead of ifr_prevflags. Of course MS>it introduces some tiny race condition, but I do not see how presence of MS>ifr_prevflags can help you in this case. Moreover, possibility of such MS>race IMO is quite low, as interface flags are usually updated very rarely. Well, yes, you are right that I cannot prevent the race. MS>Instead your bsnmp daemons should be using other ways to serialise write MS>access to interface flags (e.g. lock file). This would require all programs that fiddle with interface flags to use that same lock file (including ifconfig). It seems rather silly to me to use a heavy weight lock file, to fiddle with a kernel flag. Ok, I take my vote back :-) kill ifr_prevflags harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 8:41:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB60E37B401 for ; Fri, 16 Aug 2002 08:41:19 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 8653943E91 for ; Fri, 16 Aug 2002 08:41:18 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 88916 invoked from network); 16 Aug 2002 15:39:25 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 16 Aug 2002 15:39:25 -0000 Message-ID: <3D5D1D0B.17988AC5@pipeline.ch> Date: Fri, 16 Aug 2002 17:40:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni Cc: freebsd-net@freebsd.org Subject: Re: SUMMARY: 4-port PCI ethernet card? References: <20020814163205.22941.qmail@cobweb.example.org> <20020816081531.30617.qmail@cobweb.example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marco Molteni wrote: > > > could you suggest/comment on 2-port or 4-port ethernet cards that work > > with FreeBSD -stable? > > Thanks everybody who responded. Here is a summary of the replies I got: There is one more card, MLAN-104 from ICP. It can host two modules with two Ethernet chips each. Available are Intel Etherexpress, Realtek and Broadcomm Gigabit. The pricing is also quite ok, approx. EURO 250 with four fxp ports. Link is here: http://www.iei.com.tw/cgi-bin/ncommerce3/ExecMacro/index.d2w/html?nurl=/news/N20020604/mlan_104_en.htm -- Andre > o The FreeBSD release notes for 4.6 > http://www.freebsd.org/releases/4.6R/hardware-i386.html#ETHERNET: > > + Adaptec Duralink PCI Fast Ethernet adapters based on the Adaptec > AIC-6915 Fast Ethernet controller chip (sf(4) driver) > - ANA-62044 64-bit quad port 10/100baseTX adapter > > + Texas Instruments ThunderLAN PCI NICs (tl(4) driver) > - Compaq Netelligent 10, 10/100, 10/100 Dual-Port > > o D-Link DFE-570TX, suggested by 4 persons. > http://www.dlink.com/products/adapters/dfe570tx/ > > o D-Link DFE-580TX, suggested by 2 persons. > http://www.dlink.com/products/adapters/dfe580tx/ > > Seems that the 570 performs better than the 580. New code has just > been committed in -current and -stable to make the 580 more stable. > > o Compaq, unknown model, based on the Intel EtherExpress Pro chip > (fxp driver), suggested by 1 person. > > o Znyx, suggested by 3 persons. (dc/de driver or Znyx-provided driver) > http://www.znyx.com/products/hardware/zx340q.htm > > o Adaptec, suggested by 1 person. > > o Phobos, now Sonicwall, based on Intel 21143, suggested by 1 person. > > marco > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 9:19:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B72537B400; Fri, 16 Aug 2002 09:19:49 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F31743E65; Fri, 16 Aug 2002 09:19:48 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g7GGJlf74392; Fri, 16 Aug 2002 09:19:47 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g7GGJl2x074161; Fri, 16 Aug 2002 09:19:47 -0700 (PDT) (envelope-from jdp) Date: Fri, 16 Aug 2002 09:19:47 -0700 (PDT) Message-Id: <200208161619.g7GGJl2x074161@vashon.polstra.com> To: ambrisko@FreeBSD.org From: John Polstra Cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208072218.g77MIXPA082326@freefall.freebsd.org> References: <200208072218.g77MIXPA082326@freefall.freebsd.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200208072218.g77MIXPA082326@freefall.freebsd.org>, Doug Ambrisko wrote: > ambrisko 2002/08/07 15:18:33 PDT > > Modified files: > sys/dev/mii mii.c > Log: > Only attach one PHY device to a controller. NetBSD has similar code. > The D-Link DFE-580 card will otherwise show 2 miibuses for each controller > and therefore 2 ukphy's. [cc to -net] This change seems wrong to me. Since the MII bus is a bus and since phys have addresses on the bus, I've always assumed that the intent was to be able to have more than one phy on an MII bus. While I don't know of any NICs that actually use that feature, I hate to see it get disabled without careful consideration. If a particular NIC has a problem with this, I think the fix should be in the driver for that NIC, not in the generic MII code. See, for example, bge_miibus_readreg() in sys/dev/bge/if_bge.c. On the BCM5701 chips the phy address is not decoded, so 32 phys probe as present. The real phy is at address 1, and the driver works around the lack of decoding like this: static int bge_miibus_readreg(dev, phy, reg) device_t dev; int phy, reg; { struct bge_softc *sc; struct ifnet *ifp; u_int32_t val; int i; sc = device_get_softc(dev); ifp = &sc->arpcom.ac_if; if (sc->bge_asicrev == BGE_ASICREV_BCM5701_B5 && phy != 1) return(0); [...] Can't a similar NIC-specific hack be put into the DFE-580 driver? John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 13:28: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD4C337B401; Fri, 16 Aug 2002 13:28:03 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D8943E65; Fri, 16 Aug 2002 13:28:02 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g7GKRjE95057; Fri, 16 Aug 2002 13:27:45 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200208162027.g7GKRjE95057@ambrisko.com> Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208161619.g7GGJl2x074161@vashon.polstra.com> To: John Polstra Date: Fri, 16 Aug 2002 13:27:45 -0700 (PDT) Cc: ambrisko@FreeBSD.org, net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: | In article <200208072218.g77MIXPA082326@freefall.freebsd.org>, | Doug Ambrisko wrote: | > ambrisko 2002/08/07 15:18:33 PDT | > | > Modified files: | > sys/dev/mii mii.c | > Log: | > Only attach one PHY device to a controller. NetBSD has similar code. | > The D-Link DFE-580 card will otherwise show 2 miibuses for each controller | > and therefore 2 ukphy's. | | [cc to -net] | | This change seems wrong to me. Since the MII bus is a bus and since | phys have addresses on the bus, I've always assumed that the intent | was to be able to have more than one phy on an MII bus. While I don't | know of any NICs that actually use that feature, I hate to see it get | disabled without careful consideration. Although I don't disagree that you have a potential solution. I question whether there isn't a technical issue if you have multiple PHY's attached to a NIC. In the current stuff how would you ifconfig the other PHYs? If you can't access the other PHYs then why attach them. Did you look at the NetBSD code? When I read it they avoid probing more then one PHY in the MII code. Since we got this code from them shouldn't we follow suit? Did I mis-understand their code? Thanks, Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 13:33:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59CBD37B400; Fri, 16 Aug 2002 13:33:56 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id C262643E3B; Fri, 16 Aug 2002 13:33:55 -0700 (PDT) (envelope-from winter@jurai.net) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.5/8.12.2) with ESMTP id g7GKXmOw087371; Fri, 16 Aug 2002 16:33:48 -0400 (EDT) (envelope-from winter@jurai.net) Date: Fri, 16 Aug 2002 16:33:48 -0400 (EDT) From: "Matthew N. Dodd" To: Doug Ambrisko Cc: John Polstra , , Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208162027.g7GKRjE95057@ambrisko.com> Message-ID: <20020816163042.D788-100000@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Doug Ambrisko wrote: > whether there isn't a technical issue if you have multiple PHY's > attached to a NIC. In the current stuff how would you ifconfig the > other PHYs? If you can't access the other PHYs then why attach them. Because some cards pretend to have an MII PHY to represent the interal PHY and use an external MII PHY to implement fast ethernet. Some cards support both fiber and copper interfaces and use a different MII PHY for each. Some cards have a MII connector for attaching an external MII PHY to. Ideally each supported mode on each MII PHY should be selectable. You are correct that the existing code doesn't exactly allow you to do this. The original assumption of the code was that there would never be multiple MII PHYs present that supported the same media. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 15:17:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DDDA37B400 for ; Fri, 16 Aug 2002 15:17:39 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A7243E4A for ; Fri, 16 Aug 2002 15:17:38 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g7GMHSf75706; Fri, 16 Aug 2002 15:17:28 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g7GMHSei074716; Fri, 16 Aug 2002 15:17:28 -0700 (PDT) (envelope-from jdp) Date: Fri, 16 Aug 2002 15:17:28 -0700 (PDT) Message-Id: <200208162217.g7GMHSei074716@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: ambrisko@ambrisko.com Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208162027.g7GKRjE95057@ambrisko.com> References: <200208162027.g7GKRjE95057@ambrisko.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200208162027.g7GKRjE95057@ambrisko.com>, Doug Ambrisko wrote: > John Polstra writes: > | In article <200208072218.g77MIXPA082326@freefall.freebsd.org>, > | Doug Ambrisko wrote: > | > ambrisko 2002/08/07 15:18:33 PDT > | > > | > Modified files: > | > sys/dev/mii mii.c > | > Log: > | > Only attach one PHY device to a controller. NetBSD has similar code. > | > The D-Link DFE-580 card will otherwise show 2 miibuses for each controller > | > and therefore 2 ukphy's. > | > | [cc to -net] > | > | This change seems wrong to me. Since the MII bus is a bus and since > | phys have addresses on the bus, I've always assumed that the intent > | was to be able to have more than one phy on an MII bus. While I don't > | know of any NICs that actually use that feature, I hate to see it get > | disabled without careful consideration. > > Although I don't disagree that you have a potential solution. I question > whether there isn't a technical issue if you have multiple PHY's > attached to a NIC. In the current stuff how would you ifconfig the > other PHYs? If you can't access the other PHYs then why attach them. I think Matthew Dodd's answer is right, that the code assumes only one of the PHYs supports any given media type. Just about all of the MII code (e.g., mii_mediachg()) communicates with every PHY when a significant event happens. If the media is changed to something that the currently active PHY can't handle, it should disable itself appropriately so it stays out of the way. I don't know for sure whether this actually works in the current code, but it was clearly the intent. See for example mii.c revision 1.2, whose log message reads, "Handle buses with multiple PHYs correctly." > Did you look at the NetBSD code? When I read it they avoid probing > more then one PHY in the MII code. Since we got this code from them > shouldn't we follow suit? Did I mis-understand their code? I haven't studied NetBSD's code, but in our code all of the data structures and functions are clearly set up with the idea of supporting multiple PHYs per MII bus. Maybe NetBSD simply punted on that. BTW, I also noticed that your change leaks memory by not freeing the list of devices that device_get_children() returns. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 16: 0:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85A0937B400 for ; Fri, 16 Aug 2002 16:00:04 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E24D643E72 for ; Fri, 16 Aug 2002 16:00:03 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g7GMxYp99777; Fri, 16 Aug 2002 15:59:34 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200208162259.g7GMxYp99777@ambrisko.com> Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208162217.g7GMHSei074716@vashon.polstra.com> To: John Polstra Date: Fri, 16 Aug 2002 15:59:33 -0700 (PDT) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: | In article <200208162027.g7GKRjE95057@ambrisko.com>, | Doug Ambrisko wrote: | > John Polstra writes: | > | In article <200208072218.g77MIXPA082326@freefall.freebsd.org>, | > | Doug Ambrisko wrote: | > | > ambrisko 2002/08/07 15:18:33 PDT | > | > | > | > Modified files: | > | > sys/dev/mii mii.c | > | > Log: | > | > Only attach one PHY device to a controller. NetBSD has similar code. | > | > The D-Link DFE-580 card will otherwise show 2 miibuses for each controller | > | > and therefore 2 ukphy's. | > | | > | [cc to -net] | > | | > | This change seems wrong to me. Since the MII bus is a bus and since | > | phys have addresses on the bus, I've always assumed that the intent | > | was to be able to have more than one phy on an MII bus. While I don't | > | know of any NICs that actually use that feature, I hate to see it get | > | disabled without careful consideration. | > | > Although I don't disagree that you have a potential solution. I question | > whether there isn't a technical issue if you have multiple PHY's | > attached to a NIC. In the current stuff how would you ifconfig the | > other PHYs? If you can't access the other PHYs then why attach them. | | I think Matthew Dodd's answer is right, that the code assumes only | one of the PHYs supports any given media type. Just about all of | the MII code (e.g., mii_mediachg()) communicates with every PHY when | a significant event happens. If the media is changed to something | that the currently active PHY can't handle, it should disable itself | appropriately so it stays out of the way. Okay how about this patch to revert the mii change and only probe the first PHY. I tested it on -stable and I'm now testing it on -current. Thanks, Index: pci/if_ste.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_ste.c,v retrieving revision 1.14.2.6 diff -u -r1.14.2.6 if_ste.c --- pci/if_ste.c 14 Aug 2002 15:03:16 -0000 1.14.2.6 +++ pci/if_ste.c 16 Aug 2002 22:48:34 -0000 @@ -383,6 +383,9 @@ sc = device_get_softc(dev); + if (phy != 0) + return (0); + bzero((char *)&frame, sizeof(frame)); frame.mii_phyaddr = phy; Index: dev/mii/mii.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/mii.c,v retrieving revision 1.6.2.1 diff -u -r1.6.2.1 mii.c --- dev/mii/mii.c 14 Aug 2002 14:59:16 -0000 1.6.2.1 +++ dev/mii/mii.c 16 Aug 2002 22:48:34 -0000 @@ -106,17 +106,14 @@ { struct mii_attach_args ma, *args; struct mii_data *mii; - device_t child = NULL, parent, *children; - int bmsr, capmask = 0xFFFFFFFF, nchildren; + device_t child = NULL, parent; + int bmsr, capmask = 0xFFFFFFFF; mii = device_get_softc(dev); parent = device_get_parent(dev); LIST_INIT(&mii->mii_phys); for (ma.mii_phyno = 0; ma.mii_phyno < MII_NPHY; ma.mii_phyno++) { - device_get_children(dev, &children, &nchildren); - if (nchildren) - break; /* * Check to see if there is a PHY at this address. Note, * many braindead PHYs report 0/0 in their ID registers, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 16: 7:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 239EC37B400 for ; Fri, 16 Aug 2002 16:07:28 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BB543E4A for ; Fri, 16 Aug 2002 16:07:27 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g7GN7Pf75869; Fri, 16 Aug 2002 16:07:25 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g7GN7PDA074791; Fri, 16 Aug 2002 16:07:25 -0700 (PDT) (envelope-from jdp) Date: Fri, 16 Aug 2002 16:07:25 -0700 (PDT) Message-Id: <200208162307.g7GN7PDA074791@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: ambrisko@ambrisko.com Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208162259.g7GMxYp99777@ambrisko.com> References: <200208162259.g7GMxYp99777@ambrisko.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200208162259.g7GMxYp99777@ambrisko.com>, Doug Ambrisko wrote: > Okay how about this patch to revert the mii change and only probe > the first PHY. I tested it on -stable and I'm now testing it on > -current. Looks good, as long as the PHY always has address 0 in this device. Thanks! John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 16:16: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75D2C37B400 for ; Fri, 16 Aug 2002 16:16:03 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0002243E42 for ; Fri, 16 Aug 2002 16:16:02 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g7GNFuj00405; Fri, 16 Aug 2002 16:15:56 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200208162315.g7GNFuj00405@ambrisko.com> Subject: Re: cvs commit: src/sys/dev/mii mii.c In-Reply-To: <200208162307.g7GN7PDA074791@vashon.polstra.com> To: John Polstra Date: Fri, 16 Aug 2002 16:15:56 -0700 (PDT) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: | In article <200208162259.g7GMxYp99777@ambrisko.com>, Doug Ambrisko | wrote: | > Okay how about this patch to revert the mii change and only probe | > the first PHY. I tested it on -stable and I'm now testing it on | > -current. | | Looks good, as long as the PHY always has address 0 in this device. Well it is built in on this chip. I'm adding code to check to see if it is the D-Link part only via: if (pci_get_vendor(dev) == DL_VENDORID && pci_get_device(dev) == DL_DEVICEID_550TX && phy != 0) return (0); If someone has a Sundance chip to test they can change it if needed. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 16:40:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE6B37B400; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9171243E3B; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 6B56E2A7D6; Fri, 16 Aug 2002 16:40:50 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxim Sobolev Cc: ikostov@otel.net (Iasen Kostov), julian@elischer.org (Julian Elischer), sobomax@FreeBSD.ORG (Maxim Sobolev), hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Increasing size of if_flags field in the ifnet structure [patch In-Reply-To: <200208161222.g7GCM8Rt005388@vega.vega.com> Date: Fri, 16 Aug 2002 16:40:50 -0700 From: Peter Wemm Message-Id: <20020816234050.6B56E2A7D6@canning.wemm.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Maxim Sobolev wrote: > > > There is no much point in this patch, because it will increase size of > > > struct ifreq, which means that no ioctl's from older apps will be accept ed > > > anyway. Therefore, there is no difference between those two, while my > > > approach is obviously cleaner. > > > > It does not increase size of struct ifreq. > > This is a union not a struct as You see. > > Oh, yes, you are obviously correct. However, I still wonder if your patch > is endianless-safe. FWIW, for 4.x, endianness is not a problem since all the 4.x platforms are little-endian. For 5.x we should make a clean break. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 19:34: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F83B37B400; Fri, 16 Aug 2002 19:33:43 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22ED743E6E; Fri, 16 Aug 2002 19:33:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7H2Xgdc047570; Fri, 16 Aug 2002 19:33:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7H2XgqG047569; Fri, 16 Aug 2002 19:33:42 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Aug 2002 19:33:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200208170233.g7H2XgqG047569@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Commit schedule for bandwidth delay product pipeline limiting for TCP References: <200207200103.g6K135Ap081155@apollo.backplane.com> <3D3AB5AF.F2F637C3@pipeline.ch> <200207211747.g6LHlKHv003686@apollo.backplane.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well, I'm back from vacation. I see nobody in the general group has commented much on my bandwidth delay product code. A couple of people have corresponded with me in email and generally the response is positive. Since this code must be enabled via a sysctl I feel it is safe to commit it to -current. I also intend to MFC it to -stable prior to the freeze (MFC after: 1 week). I believe that we can eventually enable the sysctl by default. I intend to commit this code on Saturday (tomorrow). I've included the patch set below for those who need a reminder of what this is. Generally speaking this code is very similar, though not intended to duplicate, the algorithm described by the TCP Vegas paper. I will also commit manual page updates to tcp(4) and tuning(7) to describe the effects of the sysctls. -Matt Index: netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.169 diff -u -r1.169 tcp_input.c --- netinet/tcp_input.c 15 Aug 2002 18:51:26 -0000 1.169 +++ netinet/tcp_input.c 17 Aug 2002 02:24:01 -0000 @@ -1018,6 +1018,7 @@ else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); acked = th->th_ack - tp->snd_una; tcpstat.tcps_rcvackpack++; tcpstat.tcps_rcvackbyte += acked; @@ -1819,6 +1820,7 @@ tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) tcp_xmit_timer(tp, ticks - tp->t_rtttime); + tcp_xmit_bandwidth_limit(tp, th->th_ack); /* * If all outstanding data is acked, stop retransmit @@ -2445,6 +2447,8 @@ delta -= tp->t_rttvar >> (TCP_RTTVAR_SHIFT - TCP_DELTA_SHIFT); if ((tp->t_rttvar += delta) <= 0) tp->t_rttvar = 1; + if (tp->t_rttbest > tp->t_srtt + tp->t_rttvar) + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } else { /* * No rtt measurement yet - use the unsmoothed rtt. @@ -2453,6 +2457,7 @@ */ tp->t_srtt = rtt << TCP_RTT_SHIFT; tp->t_rttvar = rtt << (TCP_RTTVAR_SHIFT - 1); + tp->t_rttbest = tp->t_srtt + tp->t_rttvar; } tp->t_rtttime = 0; tp->t_rxtshift = 0; @@ -2592,6 +2597,7 @@ if (rt->rt_rmx.rmx_locks & RTV_RTT) tp->t_rttmin = rtt / (RTM_RTTUNIT / hz); tp->t_srtt = rtt / (RTM_RTTUNIT / (hz * TCP_RTT_SCALE)); + tp->t_rttbest = tp->t_srtt + TCP_RTT_SCALE; tcpstat.tcps_usedrtt++; if (rt->rt_rmx.rmx_rttvar) { tp->t_rttvar = rt->rt_rmx.rmx_rttvar / Index: netinet/tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.67 diff -u -r1.67 tcp_output.c --- netinet/tcp_output.c 12 Aug 2002 03:22:46 -0000 1.67 +++ netinet/tcp_output.c 17 Aug 2002 02:24:01 -0000 @@ -168,6 +168,7 @@ sendalot = 0; off = tp->snd_nxt - tp->snd_una; win = min(tp->snd_wnd, tp->snd_cwnd); + win = min(win, tp->snd_bwnd); flags = tcp_outflags[tp->t_state]; /* @@ -780,7 +781,7 @@ tp->snd_max = tp->snd_nxt; /* * Time this transmission if not a retransmission and - * not currently timing anything. + * not currently timing anything. */ if (tp->t_rtttime == 0) { tp->t_rtttime = ticks; Index: netinet/tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.140 diff -u -r1.140 tcp_subr.c --- netinet/tcp_subr.c 1 Aug 2002 03:54:43 -0000 1.140 +++ netinet/tcp_subr.c 17 Aug 2002 02:24:01 -0000 @@ -146,6 +146,32 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, isn_reseed_interval, CTLFLAG_RW, &tcp_isn_reseed_interval, 0, "Seconds between reseeding of ISN secret"); +static int tcp_inflight_enable = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_enable, CTLFLAG_RW, + &tcp_inflight_enable, 0, "Enable automatic TCP inflight data limiting"); + +static int tcp_inflight_debug = 1; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_debug, CTLFLAG_RW, + &tcp_inflight_debug, 0, "Debug TCP inflight calculations"); + +static int tcp_inflight_min = 1024; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_min, CTLFLAG_RW, + &tcp_inflight_min, 0, "Lower-bound for TCP inflight window"); + +static int tcp_inflight_max = TCP_MAXWIN << TCP_MAX_WINSHIFT; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_max, CTLFLAG_RW, + &tcp_inflight_max, 0, "Upper-bound for TCP inflight window"); + +#if 0 +static int tcp_inflight_attack = 20; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_attack, CTLFLAG_RW, + &tcp_inflight_attack, 0, "TCP inflight compensation attack rate (%)"); + +static int tcp_inflight_shift = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, inflight_shift, CTLFLAG_RW, + &tcp_inflight_shift, 0, "TCP inflight compensation shift (+/-100) "); +#endif + static void tcp_cleartaocache(void); static struct inpcb *tcp_notify(struct inpcb *, int); @@ -566,8 +592,10 @@ tp->t_rttmin = tcp_rexmit_min; tp->t_rxtcur = TCPTV_RTOBASE; tp->snd_cwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->snd_ssthresh = TCP_MAXWIN << TCP_MAX_WINSHIFT; tp->t_rcvtime = ticks; + tp->t_bw_rtttime = ticks; /* * IPv4 TTL initialization is necessary for an IPv6 socket as well, * because the socket may be bound to an IPv6 wildcard address, @@ -1531,3 +1559,101 @@ tcp_cleartaocache() { } + +/* + * This code attempts to calculate the bandwidth-delay product. + * The problem with calculating this product is that our manipulation + * of the congestion window modifies both the perceived bandwidth + * and the srtt. It is possible to get a fairly stable maximal + * bandwidth by increasing the congestion window. The bandwidth + * calculation will be fairly good even if bwnd is set very high. + * However, figuring out the minimal srtt is far more difficult + * because we do not want the TCP stream to suffer greatly and therefore + * cannot reduce the congestion window to something very small. + * + * What we do is first increase the congestion window to try to + * obtain a maximal (or at least a 'larger') bandwidth, then decrease + * the congestion window to try to obtain a minimal (or at least a 'smaller') + * rtt. We also have to detect the case where BWND is too high and + * neither increasing nor decreasing it has the desired effect on the + * calculation. By detecting this special case we can stabilize the + * algorithm and recalculate bwnd within a reasonable period of time. + */ +void +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) +{ + u_long bw; + u_long bwnd; + int save_ticks; + + /* + * If inflight_enable is disabled in the middle of a tcp connection, + * make sure snd_bwnd is effectively disabled. + */ + if (tcp_inflight_enable == 0) { + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; + tp->snd_bandwidth = 0; + return; + } + + /* + * Figure out the bandwidth. Due to the tick granularity this + * is a very rough number and it MUST be averaged over a fairly + * long period of time. + */ + save_ticks = ticks; + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) + return; + + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz / + (save_ticks - tp->t_bw_rtttime); + tp->t_bw_rtttime = save_ticks; + tp->t_bw_rtseq = ack_seq; + if (tp->t_bw_rtttime == 0) + return; + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; + + tp->snd_bandwidth = bw; + + /* + * Calculate the semi-static bandwidth delay product, plus two maximal + * segments. The additional slop puts us squarely in the sweet + * spot and also handles the bandwidth run-up case. Without the + * slop we could be locking ourselves into a lower bandwidth. + * + * Situations Handled: + * (1) prevents over-queueing of packets on LANs, especially + * high speed LANs, allowing larger TCP buffers to be + * specified. + * + * (2) able to handle increased network loads (bandwidth drops + * so bwnd drops). + * + * (3) Randomly changes the window size in order to force + * bandwidth balancing between connections. + */ +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; + + if (tcp_inflight_debug > 0) { + static int ltime; + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { + ltime = ticks; + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n", + tp, + bw, + tp->t_rttbest, + tp->t_srtt, + bwnd + ); + } + } + if ((long)bwnd < tcp_inflight_min) + bwnd = tcp_inflight_min; + if (bwnd > tcp_inflight_max) + bwnd = tcp_inflight_max; + if ((long)bwnd < tp->t_maxseg * 2) + bwnd = tp->t_maxseg * 2; + tp->snd_bwnd = bwnd; +} + Index: netinet/tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.79 diff -u -r1.79 tcp_usrreq.c --- netinet/tcp_usrreq.c 29 Jul 2002 09:01:39 -0000 1.79 +++ netinet/tcp_usrreq.c 17 Aug 2002 02:24:01 -0000 @@ -875,6 +875,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* @@ -961,6 +962,7 @@ tp->t_state = TCPS_SYN_SENT; callout_reset(tp->tt_keep, tcp_keepinit, tcp_timer_keep, tp); tp->iss = tcp_new_isn(tp); + tp->t_bw_rtseq = tp->iss; tcp_sendseqinit(tp); /* Index: netinet/tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.82 diff -u -r1.82 tcp_var.h --- netinet/tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 +++ netinet/tcp_var.h 21 Jul 2002 02:26:36 -0000 @@ -124,10 +124,12 @@ u_long snd_wnd; /* send window */ u_long snd_cwnd; /* congestion-controlled window */ + u_long snd_bwnd; /* bandwidth-controlled window */ u_long snd_ssthresh; /* snd_cwnd size threshold for * for slow start exponential to * linear switch */ + u_long snd_bandwidth; /* calculated bandwidth or 0 */ tcp_seq snd_recover; /* for use in fast recovery */ u_int t_maxopd; /* mss plus options */ @@ -137,6 +139,9 @@ int t_rtttime; /* round trip time */ tcp_seq t_rtseq; /* sequence number being timed */ + int t_bw_rtttime; /* used for bandwidth calculation */ + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ + int t_rxtcur; /* current retransmit value (ticks) */ u_int t_maxseg; /* maximum segment size */ int t_srtt; /* smoothed round-trip time */ @@ -144,6 +149,7 @@ int t_rxtshift; /* log(2) of rexmt exp. backoff */ u_int t_rttmin; /* minimum rtt allowed */ + u_int t_rttbest; /* best rtt we've seen */ u_long t_rttupdated; /* number of times rtt sampled */ u_long max_sndwnd; /* largest window peer has offered */ @@ -473,6 +479,7 @@ struct tcpcb * tcp_timers(struct tcpcb *, int); void tcp_trace(int, int, struct tcpcb *, void *, struct tcphdr *, int); +void tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq); void syncache_init(void); void syncache_unreach(struct in_conninfo *, struct tcphdr *); int syncache_expand(struct in_conninfo *, struct tcphdr *, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 20: 3:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EEB937B400 for ; Fri, 16 Aug 2002 20:03:41 -0700 (PDT) Received: from zeus.havoc2k.or.id (kencana.or.id [202.143.98.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B70E443E4A for ; Fri, 16 Aug 2002 20:03:39 -0700 (PDT) (envelope-from havoc2k@kencana.or.id) Received: by zeus.havoc2k.or.id (Postmaster, from userid 1007) id BCD385C4; Sat, 17 Aug 2002 10:03:27 +0700 (JAVT) Date: Sat, 17 Aug 2002 10:03:27 +0700 From: Hendry To: freebsd-net@FreeBSD.ORG Subject: IPFW2 strange results Message-ID: <20020817030327.GA1311@zeus.havoc2k.or.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dear all; i just finished build a new ipfw2 regarding to luigi post at 2002-07-23. run cvsup ; doing install da world + build da kernel ; mergemaster works like a charm. follow up the instruction from luigi. by adding options IPFW2 on kernel config ( finished build ) compile install /usr/src/sbin/ipfw and /usr/src/lib/libalias with FLAGS IPFW2. running make -DIPFW2 both on sbin/ipfw , lib/libalias works great. after doing restarting all the rules loading well and more fast of course due to completely patern which ipfw2 offered. But i found the strange when ipfw doing forwarding stuff for the reference i run transparent proxy and put ipfw show result below 00351 1163 155021 fwd 202.143.98.142,3128 tcp from 192.168.12.0/28 to any 80 it seems that the rules hit the target. but nothing progress transparent mode didnt work ; event from the proxy logs. probably i already run this transparent mode for long time and i quit sure that is nothing wrong with the proxy aplication its just uknown where the forward result fly .. or maybe from kernel config ? options IPDIVERT options IPFILTER options IPFILTER_LOG options IPFW2 options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD or maybe i need to change IPFIREWALL_FORWARD to IPFW2_FORWARD ? =P but i think its moron since luigi didnt recomended that and also when i add the ipfw rule which related with fwd stuff it didnt encountered any error message or else. My best Solution for now is back to use the old ipfw. any clue or suggestion ? or did i miss something heh ? any comments will be apreciated cheers Hendry S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 16 21:18:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 699A037B400; Fri, 16 Aug 2002 21:18:15 -0700 (PDT) Received: from patrocles.silby.com (d129.as9.nwbl0.wi.voyager.net [169.207.133.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BAD943E77; Fri, 16 Aug 2002 21:18:14 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g7H4MJB1006877; Fri, 16 Aug 2002 23:22:19 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g7H4MI8V006874; Fri, 16 Aug 2002 23:22:19 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 16 Aug 2002 23:22:18 -0500 (CDT) From: Mike Silbersack To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP In-Reply-To: <200208170233.g7H2XgqG047569@apollo.backplane.com> Message-ID: <20020816232011.E6515-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 16 Aug 2002, Matthew Dillon wrote: > Since this code must be enabled via a sysctl I feel it is safe to > commit it to -current. I also intend to MFC it to -stable prior > to the freeze (MFC after: 1 week). I believe that we can eventually > enable the sysctl by default. That seems reasonable, it'll be interesting to see results as users play around with the feature. You still have a few lines of #if 0 in there, you might want to clean them up before committing. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 17 10:49:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B0AD37B401 for ; Sat, 17 Aug 2002 10:49:18 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 93D8343E4A for ; Sat, 17 Aug 2002 10:49:17 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 47464 invoked by uid 1000); 17 Aug 2002 17:49:18 -0000 Date: Sat, 17 Aug 2002 10:49:18 -0700 (PDT) From: Nate Lawson To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP In-Reply-To: <200208170233.g7H2XgqG047569@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Comments below. Consider them only semi-informed. :) On Fri, 16 Aug 2002, Matthew Dillon wrote: > +void > +tcp_xmit_bandwidth_limit(struct tcpcb *tp, tcp_seq ack_seq) > +{ > + u_long bw; > + u_long bwnd; > + int save_ticks; > + > + /* > + * If inflight_enable is disabled in the middle of a tcp connection, > + * make sure snd_bwnd is effectively disabled. > + */ > + if (tcp_inflight_enable == 0) { > + tp->snd_bwnd = TCP_MAXWIN << TCP_MAX_WINSHIFT; > + tp->snd_bandwidth = 0; > + return; > + } > + > + /* > + * Figure out the bandwidth. Due to the tick granularity this > + * is a very rough number and it MUST be averaged over a fairly > + * long period of time. > + */ > + save_ticks = ticks; > + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) > + return; If tp->t_bw_rtttime is greater than save_ticks, the unsigned compare will fail. Can this ever happen (say with the "tick count goes backwards" issue)? Why not do this as a signed compare and check for <= 0? > + bw = (int64_t)(ack_seq - tp->t_bw_rtseq) * hz / > + (save_ticks - tp->t_bw_rtttime); > + tp->t_bw_rtttime = save_ticks; > + tp->t_bw_rtseq = ack_seq; > + if (tp->t_bw_rtttime == 0) > + return; > + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; I'm not familiar with the paper -- where does 15 come from? I'm guessing this is a cheap way to perturb the lower bits. > + tp->snd_bandwidth = bw; > + > + /* > + * Calculate the semi-static bandwidth delay product, plus two maximal > + * segments. The additional slop puts us squarely in the sweet > + * spot and also handles the bandwidth run-up case. Without the > + * slop we could be locking ourselves into a lower bandwidth. > + * > + * Situations Handled: > + * (1) prevents over-queueing of packets on LANs, especially > + * high speed LANs, allowing larger TCP buffers to be > + * specified. > + * > + * (2) able to handle increased network loads (bandwidth drops > + * so bwnd drops). > + * > + * (3) Randomly changes the window size in order to force > + * bandwidth balancing between connections. > + */ > +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) > + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; Would prefer an #undef USERTT after you're done with it. > + if (tcp_inflight_debug > 0) { > + static int ltime; What happens when multiple packets arrive at once. Can they make the calculation below fail? Do you want splimp or a lock on ltime? > + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { Why the division by a debug enable/disable int? Is it possible for this to ever be 0 at this point? > + ltime = ticks; > + printf("%p bw %ld rttbest %d srtt %d bwnd %ld\n", > + tp, > + bw, > + tp->t_rttbest, > + tp->t_srtt, > + bwnd > + ); > + } > + } > + if ((long)bwnd < tcp_inflight_min) > + bwnd = tcp_inflight_min; > + if (bwnd > tcp_inflight_max) > + bwnd = tcp_inflight_max; > + if ((long)bwnd < tp->t_maxseg * 2) > + bwnd = tp->t_maxseg * 2; > + tp->snd_bwnd = bwnd; > +} > + > Index: netinet/tcp_var.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v > retrieving revision 1.82 > diff -u -r1.82 tcp_var.h > --- netinet/tcp_var.h 19 Jul 2002 18:27:39 -0000 1.82 > +++ netinet/tcp_var.h 21 Jul 2002 02:26:36 -0000 > > @@ -137,6 +139,9 @@ > int t_rtttime; /* round trip time */ > tcp_seq t_rtseq; /* sequence number being timed */ > > + int t_bw_rtttime; /* used for bandwidth calculation */ Does this need to be signed? > + tcp_seq t_bw_rtseq; /* used for bandwidth calculation */ > + > int t_rxtcur; /* current retransmit value (ticks) */ > u_int t_maxseg; /* maximum segment size */ > int t_srtt; /* smoothed round-trip time */ > @@ -144,6 +149,7 @@ > > int t_rxtshift; /* log(2) of rexmt exp. backoff */ > u_int t_rttmin; /* minimum rtt allowed */ > + u_int t_rttbest; /* best rtt we've seen */ > u_long t_rttupdated; /* number of times rtt sampled */ > u_long max_sndwnd; /* largest window peer has offered */ -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 17 11:36:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 497DF37B400; Sat, 17 Aug 2002 11:36:21 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D258043E70; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7HIaKdc067941; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7HIaKZ3067940; Sat, 17 Aug 2002 11:36:20 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Aug 2002 11:36:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200208171836.g7HIaKZ3067940@apollo.backplane.com> To: Nate Lawson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Commit schedule for bandwidth delay product pipeline limiting for TCP References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Comments below. Consider them only semi-informed. :) : :> + save_ticks = ticks; :> + if ((u_int)(save_ticks - tp->t_bw_rtttime) < 1) :> + return; : :If tp->t_bw_rtttime is greater than save_ticks, the unsigned compare will :fail. Can this ever happen (say with the "tick count goes :backwards" issue)? Why not do this as a signed compare and check for :<= 0? Yes, when ticks rolls over. This is on purpose and is designed to handle both the rollover condition and someone setting the time of day on the machine (though perhaps 'ticks' doesn't reverse index in that case, I wasn't sure). e.g. if ticks rolls over we fall through the conditional and proceed to the calculation, which resets t_bw_rtttime. :> + tp->t_bw_rtseq = ack_seq; :> + if (tp->t_bw_rtttime == 0) :> + return; :> + bw = ((int64_t)tp->snd_bandwidth * 15 + bw) >> 4; : :I'm not familiar with the paper -- where does 15 come from? I'm guessing :this is a cheap way to perturb the lower bits. It's a cheap way to do an exponential average. The >> 4 is a divide by 16. So the equivalent is: bw = (average_bw * 15 + bw) / 16 average_bw = bw; That should be more obvious to you... a long term exponential average of the bandwidth. :> + * bandwidth balancing between connections. :> + */ :> +#define USERTT ((tp->t_srtt + tp->t_rttbest) / 2) :> + bwnd = (int64_t)bw * USERTT / (hz << TCP_RTT_SHIFT) + 2 * tp->t_maxseg; : :Would prefer an #undef USERTT after you're done with it. Too late, I just did the commit. I'll make the addition in my local tree. I expect to make more commits in the future to this segment of code and it will show up in one of those. :> + if (tcp_inflight_debug > 0) { :> + static int ltime; : :What happens when multiple packets arrive at once. Can they make the :calculation below fail? Do you want splimp or a lock on ltime? No, this is just debugging code designed to limit the rate of kernel printfs. A tcp_inflight_debug of 1 limits the rate to 1/sec. 2 will be 2/sec. 3 will be 3/sec. It's just debugging code, it isn't meant to be 100% robust. :> + if ((u_int)(ticks - ltime) >= hz / tcp_inflight_debug) { : :Why the division by a debug enable/disable int? Is it possible for this :to ever be 0 at this point? No, because of the check above. Though I suppose in -current there could be a race. :> tcp_seq t_rtseq; /* sequence number being timed */ :> :> + int t_bw_rtttime; /* used for bandwidth calculation */ : :Does this need to be signed? I think you meant unsigned. No, it doesn't need to be unsigned. Hmm. though it's possible rollover will skew the 'bw' calculation for a few milliseconds. I'll look into that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 17 19:17:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B742337B400 for ; Sat, 17 Aug 2002 19:17:41 -0700 (PDT) Received: from web21104.mail.yahoo.com (web21104.mail.yahoo.com [216.136.227.106]) by mx1.FreeBSD.org (Postfix) with SMTP id 73A9D43E6A for ; Sat, 17 Aug 2002 19:17:41 -0700 (PDT) (envelope-from geekvinod@yahoo.com) Message-ID: <20020818021741.56051.qmail@web21104.mail.yahoo.com> Received: from [152.15.26.29] by web21104.mail.yahoo.com via HTTP; Sat, 17 Aug 2002 19:17:41 PDT Date: Sat, 17 Aug 2002 19:17:41 -0700 (PDT) From: Vinod Subject: dynamic packet filtering to reduce congestion To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there.I am thinking of trying to avoid congestion in my network by selectively dropping incoming packets at my gateway.Actually it's part of a research project where i am trying to avoid congestion and provide a better connection to machines assigned a higher priority.This will be at the cost of machines assigned a lower priority.Dropping packets ,destined for low priority machines, at the gateway will decrease congestion in the network and will keep the connection quality to high priority machines high. How do i drop packets selectively(to certain destinations) from my freebsd gateway?can the ipfiltering tools be used? its important to note that i will be filtering packets only when i detect congestion.as soon as congestion is under reasonable control i intend to stop my filtering.what would be the best approach?what tools should i use? Thanks, Vinod __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message