From owner-freebsd-net Sun Jun 2 5:53:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 0B21637B405 for ; Sun, 2 Jun 2002 05:53:36 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g52CrAY62954; Sun, 2 Jun 2002 15:53:10 +0300 (EEST) (envelope-from ru) Date: Sun, 2 Jun 2002 15:53:10 +0300 From: Ruslan Ermilov To: Andre Oppermann Cc: freebsd-net@FreeBSD.ORG, silby@silby.com Subject: Re: Bug in net/route.c function rtredirect() Message-ID: <20020602125310.GD58857@sunbay.com> References: <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KdquIMZPjGJQvRdI" Content-Disposition: inline In-Reply-To: <3CF8A6CF.6033679A@pipeline.ch> 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 --KdquIMZPjGJQvRdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 01, 2002 at 12:49:51PM +0200, Andre Oppermann wrote: > Ruslan Ermilov wrote: > >=20 > > On Sat, Jun 01, 2002 at 02:56:37AM +0200, Andre Oppermann wrote: > > > Hi all, > > > > > > I've found another bug in net/route.c in the function rtredirect(). > > > > > > When learning a new gateway from a ICMP redirect icmp_input calls > > > rtredirect() in net/route.c. rtredirect is doing some sanity checks > > > and then creates, if it did not find an existing host route, a new > > > host route tagged with the RTF_DYNAMIC flag. If there was an existing > > > host route it'll simply adjust the gateway and set the RTF_MODIFIED > > > flag. > > > > > OK. > >=20 > > > If no pre-existing host route was found either the default route or > > > an network route is being returned by the route table lookup in the > > > beginning. Neither of these should be modified. It should simply add > > > the new host route. > > > > > This route lookup also increments rt_refcnt. >=20 > Yes. >=20 > > > The bug is that the jump to "create:" (host route) tries to rtfree() > > > the found default route or network route. If the refcount on those > > > routes is one it frees it, otherwise it decrements it by one. This is > > > wrong. There is no reason to decrement the refcount or to free the > > > routes. The bug is even dangerous when you happen to have many > > > redirects, one too much and you'll loose your default route. The > > > refcount drifts away one decrement more with every valid redirecet > > > received. > > > > > There _is_ the reason to decrement the refcount, because nothing is > > going to point to it after we modify it, and if we don't decrement > > it, this will create an "unremovable" route. >=20 > You're right but the refcount decrementation will be done, just in a > different place. In the "done:" section the rtfree() will be done also > in the case when an existing host route was already present. >=20 No it won't be done in "done:", because a few lines later we assign rt =3D NULL: create: if (rt) rt->rt_refcnt--; flags |=3D RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] =3D dst; info.rti_info[RTAX_GATEWAY] =3D gateway; info.rti_info[RTAX_NETMASK] =3D netmask; info.rti_ifa =3D ifa; info.rti_flags =3D flags; rt =3D NULL; > > > The solution is to remove the rtfree() in rtredirect. Diff against > > > -STABLE is attached. Should apply to -CURRENT with some fuzz. > > > > > No, please try the below patch instead. >=20 > The rtfree() I removed is one too many and still has to go. Your patch > doesn't change the problem, it just makes it different. Routes could > go below zero refcount in your version. >=20 The second rt->rt_refcnt-- I added is indeed unnecessary, you're right here. > > > The bug has been introduced by ru in commit 1.67 "Pull post-4.4BSD > > > change from BSD/OS 4.2". This bug is also present in NetBSD and was > > > introduced there before here (1.67 commit is a copy from NetBSD). > > > > > Why you're not mailing me then? The bug was introduced first in > > BSD/OS, FWIW. >=20 > Sorry, Silby fixed the previous bug so I sent this to him again. >=20 > > > I found this by observing a problem on a machine on my network where > > > I have two routers. One is the default router for the machine. Some- > > > times it'll get a redirect to use the second router and then the > > > inconsistencies begun. I only really noticed this problem by using > > > and watching the numbers of the tcp statistics code I posted yesterday > > > (plus route -n monior). This is side-work for an overhaul of the > > > kernel routing table. > > > > > I will see if I can reproduce this, on Monday. > >=20 > > > While being in this area I noticed that host routes created by a > > > redirect never time out and never get removed in a regular fashion. > > > So if you get many of them they clutter the whole routing table. This > > > can become dangerous if you get a lot tcp sessions and your default > > > router is sub-optimal and redirects you all the time to the "real > > > default" router on your network. There can be a redirected route for > > > every host on the Internet. Bad if a new code-red or nimda wave comes > > > by. NetBSD has implemented a purger for the redirect host routes. > > > I'll have a look at it and provide a patch for that for FreeBSD next > > > week. > > > > > Nice catch. > >=20 > > Please try this patch, it's believed to fix both problems. It is > > completely untested: >=20 > I fail to see how you purge the redirect host routes. >=20 I will think about that. > Actually, at the moment I have got some problems following the very > twisted logic of all this... ;-) Lets have another look on monday. >=20 > Anyway, patch attached which I think (at the moment) would be correct. >=20 > --- route.c.old Fri May 31 21:17:50 2002 > +++ route.c Sat Jun 1 12:34:33 2002 > @@ -299,7 +299,7 @@ > int flags; > struct rtentry **rtp; > { > - struct rtentry *rt; > + struct rtentry *rt, *rtn; > int error =3D 0; > short *stat =3D 0; > struct rt_addrinfo info; > @@ -344,8 +344,6 @@ > * Create new route, rather than smashing route to net. > */ > create: > - if (rt) > - rtfree(rt); > flags |=3D RTF_GATEWAY | RTF_DYNAMIC; > bzero((caddr_t)&info, sizeof(info)); > info.rti_info[RTAX_DST] =3D dst; > @@ -353,10 +351,10 @@ > info.rti_info[RTAX_NETMASK] =3D netmask; > info.rti_ifa =3D ifa; > info.rti_flags =3D flags; > - rt =3D NULL; > - error =3D rtrequest1(RTM_ADD, &info, &rt); > - if (rt !=3D NULL) > - flags =3D rt->rt_flags; > + rtn =3D NULL; > + error =3D rtrequest1(RTM_ADD, &info, &rtn); > + if (rtn !=3D NULL) > + flags =3D rtn->rt_flags; > stat =3D &rtstat.rts_dynamic; > } else { > /* Heh, so you in fact tried to rtfree() "rt" in "done:" by adding "rtn". And how *rtp (if rtp !=3D NULL) will become "rtn" then? What about this? %%% Index: route.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.69 diff -u -p -r1.69 route.c --- route.c 19 Mar 2002 21:54:18 -0000 1.69 +++ route.c 2 Jun 2002 12:49:16 -0000 @@ -345,7 +345,7 @@ rtredirect(dst, gateway, netmask, flags, */ create: if (rt) - rtfree(rt); + rt->rt_refcnt--; flags |=3D RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] =3D dst; %%% 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 --KdquIMZPjGJQvRdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE8+hU2Ukv4P6juNwoRAnlUAKCB95oIsFB7PgklcPqyzV+br7BjtQCcDQPH XkraGXh4yJ0IDFtXA+R9qsI= =KrTi -----END PGP SIGNATURE----- --KdquIMZPjGJQvRdI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 2 10:19:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 5B38C37B404 for ; Sun, 2 Jun 2002 10:19:21 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g52HDUN79477 for ; Sun, 2 Jun 2002 10:13:30 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 2 Jun 2002 10:13:30 -0700 (PDT) From: Patrick Thomas To: Subject: an and wi netgraph enabled ? Message-ID: <20020602101156.K18408-100000@utility.clubscholarship.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 Are the `an` and `wi` network drivers "netgraph enabled" ? (cisco aironet and lucent 802.11b cards) If not, does this mean there is no way to use them in a netgraph setting ? thanks, PT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 2 11:15:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id A4AA737B408 for ; Sun, 2 Jun 2002 11:15:52 -0700 (PDT) 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 g52IFoeE021482; Sun, 2 Jun 2002 11:15:50 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g52IFogL021481; Sun, 2 Jun 2002 11:15:50 -0700 Date: Sun, 2 Jun 2002 11:15:50 -0700 From: Brooks Davis To: Patrick Thomas Cc: freebsd-net@FreeBSD.ORG Subject: Re: an and wi netgraph enabled ? Message-ID: <20020602111549.A19588@Odin.AC.HMC.Edu> References: <20020602101156.K18408-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020602101156.K18408-100000@utility.clubscholarship.com>; from root@utility.clubscholarship.com on Sun, Jun 02, 2002 at 10:13:30AM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.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 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 02, 2002 at 10:13:30AM -0700, Patrick Thomas wrote: >=20 > Are the `an` and `wi` network drivers "netgraph enabled" ? >=20 > (cisco aironet and lucent 802.11b cards) >=20 > If not, does this mean there is no way to use them in a netgraph setting ? They work more or less like ethernet devices so they should work with netgraph with the single issue that in normal ad-hoc or infrastructure modes you can't send packets with a different MAC so they can't be bridged. You can do with with prismII cards using hostap mode. -- 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 --vkogqOf2sHV7VnPd 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 iD8DBQE8+mDVXY6L6fI4GtQRAq5pAKCRFNgk6d799wklNf55HANCKWpclQCfTuyA 3VSzUhOs2CjzPQoZ7Lr68L4= =s91r -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 2 11:29:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by hub.freebsd.org (Postfix) with ESMTP id 6189037B404 for ; Sun, 2 Jun 2002 11:29:17 -0700 (PDT) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g52INKR82242; Sun, 2 Jun 2002 11:23:20 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 2 Jun 2002 11:23:20 -0700 (PDT) From: Patrick Thomas To: Brooks Davis Cc: Subject: Re: an and wi netgraph enabled ? In-Reply-To: <20020602111549.A19588@Odin.AC.HMC.Edu> Message-ID: <20020602112252.I18408-100000@utility.clubscholarship.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 Yeah I knew about the bridging problem ... when will that bug be fixed ? --pt On Sun, 2 Jun 2002, Brooks Davis wrote: > On Sun, Jun 02, 2002 at 10:13:30AM -0700, Patrick Thomas wrote: > > > > Are the `an` and `wi` network drivers "netgraph enabled" ? > > > > (cisco aironet and lucent 802.11b cards) > > > > If not, does this mean there is no way to use them in a netgraph setting ? > > They work more or less like ethernet devices so they should work with > netgraph with the single issue that in normal ad-hoc or infrastructure > modes you can't send packets with a different MAC so they can't be > bridged. You can do with with prismII cards using hostap mode. > > -- Brooks > > -- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 2 14:39:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1004A37B401 for ; Sun, 2 Jun 2002 14:39:50 -0700 (PDT) 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 g52LdleE002961; Sun, 2 Jun 2002 14:39:47 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g52LdltQ002960; Sun, 2 Jun 2002 14:39:47 -0700 Date: Sun, 2 Jun 2002 14:39:47 -0700 From: Brooks Davis To: Patrick Thomas Cc: Brooks Davis , freebsd-net@FreeBSD.ORG Subject: Re: an and wi netgraph enabled ? Message-ID: <20020602143947.A2479@Odin.AC.HMC.Edu> References: <20020602111549.A19588@Odin.AC.HMC.Edu> <20020602112252.I18408-100000@utility.clubscholarship.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020602112252.I18408-100000@utility.clubscholarship.com>; from root@utility.clubscholarship.com on Sun, Jun 02, 2002 at 11:23:20AM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.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 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 02, 2002 at 11:23:20AM -0700, Patrick Thomas wrote: >=20 > Yeah I knew about the bridging problem ... when will that bug be fixed ? It's not a bug, it's a feature of the hardware. There is no no real possiability of a solution. -- 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 --2fHTh5uZTiUOsy+g 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 iD8DBQE8+pCjXY6L6fI4GtQRAv6YAJ9D52N9v72GRBdE8mYJrCZgBZXtZACdGsjZ EvM/YdHd1z9eoQ1ED7hkIVQ= =DM+b -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 2 22:59:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id 2574A37B405 for ; Sun, 2 Jun 2002 22:59:15 -0700 (PDT) Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id BAA28608 for ; Mon, 3 Jun 2002 01:59:13 -0400 (EDT) Date: Mon, 3 Jun 2002 01:59:13 -0400 (EDT) From: Nguyen-Tuong Long Le To: freebsd-net@freebsd.org Subject: Problem with SYN cache in FreeBSD 4.5 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 Hi all, Our group has a proprietary web server that can handle 10000 requests/s under FreeBSD 4.3 release. We recently upgraded our system to 4.5 and got very poor performance. While the web server runs, I see lots of messages similar to the following on the console "Limiting open port RST response from 1068 to 200 packets per second". The problem seems to be related to the syncache implementation that drops incoming SYN segments. I've tried to increase the size of the hash table but that didn't seem to help much. Here is the output of "sysctl net.inet.tcp.syncache". net.inet.tcp.syncache.bucketlimit: 512 net.inet.tcp.syncache.cachelimit: 262142 net.inet.tcp.syncache.count: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 (I'm puzzled why SYNs are dropped while the net.inet.tcp.syncache.count is so low). kern.ipc.somaxconn and kern.ipc.nmbclusters are set to 8192 and 65536 respectively. Any help would be very much appreciated! Thanks, -- long P.S. Please kindly cc' your reply to me since I'm not on the list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 3:51:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id E6FA337B406 for ; Mon, 3 Jun 2002 03:51:47 -0700 (PDT) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.35 #1) id 17EpRe-00081r-00 for freebsd-net@freebsd.org; Mon, 03 Jun 2002 12:52:14 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.35 #1) id 17EpRe-00081k-00; Mon, 03 Jun 2002 12:52:14 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 17EpRS-000DUf-00; Mon, 03 Jun 2002 12:52:02 +0200 Date: Mon, 3 Jun 2002 12:52:02 +0200 From: Barry Irwin To: freebsd-net@freebsd.org Subject: GRE on 4.x Message-ID: <20020603125202.F43867@itouchlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Checked: Scanned for any viruses and unauthorized attachments at mx1.dev.itouchnet.net X-iScan-ID: 30863-1023101534-71548@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ 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'm trying to integrate with a business aprner here who have a requirement we use GRE tunnel inside of IPSEC for a number of reasons. While the gif(4) device provides IPIP tunneling (proto 4) this doesnt work when the remote side is expecting true GRE (proto 47). Has any one had any experiance working with GRE tunnels under FBSD. I have tried the following two resources I found but not much success on either. http://mike.spottydogs.org/projects/gre-tun/ http://www.pointless.net/~jasper/consume/docs/my-docs/tunneling.html The latter creates a GRE device, but has issues compiling on 4.3 which is unfortunately what the production system in question runs. Barry -- Barry Irwin bvi@itouchlabs.com +27214875177 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 5: 7:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by hub.freebsd.org (Postfix) with ESMTP id EA96D37B427 for ; Mon, 3 Jun 2002 05:07:03 -0700 (PDT) Received: from veidit.net ([213.88.130.20]) by smtp.wineasy.se with ESMTP id g53C74w12600 for ; Mon, 3 Jun 2002 14:07:04 +0200 Message-ID: <3CFB5BE2.3010209@veidit.net> Date: Mon, 03 Jun 2002 14:06:58 +0200 From: John Angelmo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Subject: Win2k - FreeBSD 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 I'mabout to install a FreeBSD box as a firewall for a school. The box will also be standing as a gateway, my question is could in some way check that the IP(or user) is logged in to the 2k domain before he/she is allowed to surf outside the local net? And I'm also setting up the fbsd box as a VPN server, can I sync the usernames with win2k in some way? ;) /John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 5:48:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from jonkmans.com (dns01.jonkmans.com [64.239.6.30]) by hub.freebsd.org (Postfix) with ESMTP id C512A37B40E for ; Mon, 3 Jun 2002 05:48:36 -0700 (PDT) Received: from xp120634 (localhost.jonkmans.com [127.0.0.1]) by jonkmans.com (8.11.6/8.11.6) with SMTP id g53CmRO57413; Mon, 3 Jun 2002 07:48:28 -0500 (CDT) (envelope-from matt@jonkmans.com) Message-ID: <023501c20afc$832d84f0$2201070a@xp120634> From: "Matt Jonkman" To: "John Angelmo" , References: <3CFB5BE2.3010209@veidit.net> Subject: Re: Win2k - FreeBSD Date: Mon, 3 Jun 2002 07:45:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 If you use squid and the smb_auth module you'll be set. The smb_auth module will authenticate each user to the domain, not check that they're loggged in. But that usually works well. Matt ----- Original Message ----- From: "John Angelmo" To: Sent: Monday, June 03, 2002 7:06 AM Subject: Win2k - FreeBSD > I'mabout to install a FreeBSD box as a firewall for a school. > The box will also be standing as a gateway, my question is could in some > way check that the IP(or user) is logged in to the 2k domain before > he/she is allowed to surf outside the local net? > > And I'm also setting up the fbsd box as a VPN server, can I sync the > usernames with win2k in some way? ;) > > /John > > > 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 Mon Jun 3 6:35:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (Postfix) with ESMTP id 9A08737B40A for ; Mon, 3 Jun 2002 06:35:12 -0700 (PDT) Received: from hardy.lodgenet.com (hardy.lodgenet.com [10.0.104.235]) by garbo.lodgenet.com (8.11.4/8.11.4) with ESMTP id g53DZA519457; Mon, 3 Jun 2002 08:35:10 -0500 (CDT) Received: from chaplin.lodgenet.com (not verified[10.0.104.215]) by hardy.lodgenet.com with MailMarshal (4,2,5,0) id ; Mon, 03 Jun 2002 08:35:10 -0500 Received: by chaplin.lodgenet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 08:30:45 -0500 Message-ID: <3EA88113DE92D211807300805FA7994209149E42@chaplin.lodgenet.com> From: "McKenna, Lee" To: "'Johan Petersson'" , freebsd-net@freebsd.org Subject: RE: Duplex problem with Etherlink XL (3c900B) and xl driver. Date: Mon, 3 Jun 2002 08:30:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 If the switch port is set to auto-negotiate, try setting it to 100/Full Duplex -- this way there is no negotiation between the devices. I've = seen several incompatibilities with auto-negotiate among different vendors equipment over the years. --Lee > -----Original Message----- > From: Johan Petersson [mailto:kjep@yahoo.com] > Sent: Saturday, June 01, 2002 4:46 AM > To: freebsd-net@FreeBSD.ORG > Subject: Duplex problem with Etherlink XL (3c900B) and xl driver. >=20 >=20 > Hi everyone, >=20 > I'm having problems getting FreeBSD to use full duplex with my > 3com Etherlink XL card. The NIC is connected to a 10/100 switch > and during power up and boot the full duplex LED on the switch > is on, until the probing of the NIC (using xl driver). Then the > LED goes out indicating half duplex mode. When I boot DOS the > LED stays on all the time. >=20 > Trying to force full duplex with ifconfig does not seem to work. > There is no error message, but the LED remains off and instead > network thruput falls to about 30 kbit/s... I have tried both > auto (NWAY) and manual settings of the card using a 3com DOS > utility, but no change. >=20 > Relevant (?) lines from dmesg (boot -v): > xl0: <3Com 3c900B-COMBO Etherlink XL> port 0x4000-0x407f mem > 0x60000000-0x600000 > 7f irq 10 at device 15.0 on pci0 > xl0: Ethernet address: 00:50:04:22:a1:a2 > xl0: media options word: 38 > xl0: guessing COMBO (AUI/BNC/TP) > xl0: found 10baseT > xl0: found AUI > xl0: found BNC > xl0: selecting 10baseT transceiver, half duplex >=20 > "ifconfig xl0" gives me: > xl0: flags=3D8843 mtu 1500 > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:50:04:22:a1:a2 > media: Ethernet 10baseT/UTP (10baseT/UTP ) >=20 > Finally, "uname -a": > FreeBSD hawk.sigtuna.lan 4.4-RELEASE FreeBSD 4.4-RELEASE #4:=20 > Fri May 31 > 13:01:43 CEST 2002 =20 > johan@falcon.sigtuna.lan:/usr/src/sys/compile/HAWK i386 >=20 > The computer is an old IBM PC Pentium 133. >=20 > Does anyone have any ideas how to enable full duplex under FreeBSD? >=20 > Regards > Johan Petersson >=20 >=20 > _____________________________________________________ > F=F6lj VM p=E5 n=E4ra h=E5ll p=E5 Yahoo!s officielle VM-sajt = www.yahoo.se/vm2002 > H=E5ll dig ajour med nyheter och resultat, med vinnare och = f=F6rlorare... >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 8:18:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 2B94637B405 for ; Mon, 3 Jun 2002 08:18:33 -0700 (PDT) Received: from isi.edu (0b511af5bfcp2mg0@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g53FIUW17980; Mon, 3 Jun 2002 08:18:31 -0700 (PDT) Message-ID: <3CFB88C6.4070407@isi.edu> Date: Mon, 03 Jun 2002 08:18:30 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: net@FreeBSD.ORG Subject: Re: netgraph documentation? References: <200205312337.g4VNbbs03438@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020902030009000302070801" 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. --------------ms020902030009000302070801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie Cobbs wrote: >>/usr/sbin/ngctl mkpeer iface dummy inet >>/usr/sbin/ngctl mkpeer ng3: ksocket inet inet/stream/tcp >>/usr/sbin/ngctl msg ng3:inet bind inet/10.0.0.1:50505 >>/usr/sbin/ngctl msg ng3:inet listen 1 >>ngctl: send msg: Operation not supported by device >> >> 2. Why can't I listen on a ksocket? > > What you are doing is correct, I don't know why you are getting > that error. The error is coming from solisten(). > > However, when I try this the listen operation does actually > succeed as witnessed by 'netstat -na -f inet'. You're right, I see: [root@hbo: ~larse] netstat -na -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 127.0.0.1.50505 *.* LISTEN So I ignore the error for now, and make the TCP tunnel as follows: Server: /usr/sbin/ngctl mkpeer iface dummy inet /sbin/ifconfig ng0 10.10.10.1 10.10.10.2 /usr/sbin/ngctl mkpeer ng0: ksocket inet inet/stream/tcp /usr/sbin/ngctl msg ng0:inet bind inet/127.0.0.1:50505 /usr/sbin/ngctl msg ng0:inet listen 1 ngctl: send msg: Operation not supported by device Client: /usr/sbin/ngctl mkpeer iface dummy inet /sbin/ifconfig ng1 10.10.10.2 10.10.10.1 /usr/sbin/ngctl mkpeer ng1: ksocket inet inet/stream/tcp /usr/sbin/ngctl msg ng1:inet bind inet/127.0.0.1:50506 /usr/sbin/ngctl msg ng1:inet connect inet/127.0.0.1:50505 ngctl: send msg: Operation now in progress A tcpdump on lo0 shows the 3-way handshake suceeding: [root@hbo: ~larse] tcpdump -i lo0 port 50505 tcpdump: listening on lo0 08:11:29.013658 loopback.50506 > loopback.50505: S 2787661608:2787661608(0) win 65535 (DF) 08:11:29.013710 loopback.50505 > loopback.50506: S 1751674938:1751674938(0) ack 2787661609 win 65535 08:11:29.013754 loopback.50506 > loopback.50505: . ack 1 win 32767 (DF) Pinging 10.10.10.2 results in: [root@hbo: ~larse] ping 10.10.10.2 PING 10.10.10.2 (10.10.10.2): 56 data bytes ping: sendto: Socket is not connected ping: sendto: Socket is not connected ping: sendto: Socket is not connected ^C --- 10.10.10.2 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss A tcpdump on lo0 shows no packets. Pinging 10.10.10.1 results in: [root@hbo: ~larse] ping 10.10.10.1 PING 10.10.10.1 (10.10.10.1): 56 data bytes ^C --- 10.10.10.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss This is captures by tcpdump on lo0: [root@hbo: ~larse] tcpdump -i lo0 port 50505 tcpdump: listening on lo0 08:15:21.228886 loopback.50506 > loopback.50505: P 2787661609:2787661693(84) ack 1751674939 win 32767 (DF) 08:15:21.323163 loopback.50505 > loopback.50506: . ack 84 win 32725 (DF) 08:15:22.233135 loopback.50506 > loopback.50505: P 84:168(84) ack 1 win 32767 (DF) 08:15:22.333089 loopback.50505 > loopback.50506: . ack 168 win 32683 (DF) 08:15:23.243144 loopback.50506 > loopback.50505: P 168:252(84) ack 1 win 32767 (DF) 08:15:23.343084 loopback.50505 > loopback.50506: . ack 252 win 32641 (DF) I don't know enough about the netgraph internals to debug this further myself, but I'd be more than happy to do any tests that'd help you or someone else look into this. (I should probably mention that I'm using 4.5-RELEASE.) Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms020902030009000302070801 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwMzE1MTgzMFowIwYJKoZIhvcNAQkEMRYEFHNquFsg00vO 09Jb1g92KT5tJHF6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAyqNlcUZ7PEua5wMrG2DZ7iZjzcUzCDlRA+a5l5jW/Ql+m xTdwc4pyh2smCAQHlwuZIdAE705pwLbKJpbVX57ApDOCw4Qp+pTlWGrybvOP9nJ2kP/U9ovR sB2SZCci5CQnhEHgwEqFAf+dwi2EP3AxaN5dstyx/QNdIxDtBca5ygAAAAAAAA== --------------ms020902030009000302070801-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 9:39:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id DBE2737B405 for ; Mon, 3 Jun 2002 09:39:33 -0700 (PDT) Received: from isi.edu (rrpc437i936xymix@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g53GdXW02807; Mon, 3 Jun 2002 09:39:33 -0700 (PDT) Message-ID: <3CFB9BC4.9080506@isi.edu> Date: Mon, 03 Jun 2002 09:39:32 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org, Luigi Rizzo Subject: Dummynet WFQ Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080104070603080708070609" 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. --------------ms080104070603080708070609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, the Dummynet page has this example WFQ configuration: ipfw add queue 1 ip from any to 10.1.2.0/24 ipfw queue 1 config weight 5 pipe 2 mask dst-ip 0x000000ff ipfw pipe 2 config bw 300Kbit/s The 300Kbit/s seems to be the bandwidth limit of the uplink. I'd imagine that extra uplink bandwidth would remain unused in this setup, right? Is it possible to do WFQ when the uplink bandwidth is unknown/unspecified? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms080104070603080708070609 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwMzE2MzkzM1owIwYJKoZIhvcNAQkEMRYEFKfKFhHgGSSD 0VHn7wP7Km3fb+a9MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAwc3W7X8fMOjNjvTjXyonPsWXvSojQOQKhtbGFtz9z3ZId ExIs91Zb5vTsNqestzzlsmLwFq3UVtahvcV8Di6GIivvA0N0Z0+oe6uKl0WSk0FWezKbkJKa 20rmGvcmVy2Hsl+Kl5b0YDfxNPnQXbRAx4iN/JsELeGN9Vxn4b1hnAAAAAAAAA== --------------ms080104070603080708070609-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 9:58:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from ruminary.org (chiku.ruminary.org [216.218.185.24]) by hub.freebsd.org (Postfix) with ESMTP id E36E037B400 for ; Mon, 3 Jun 2002 09:58:32 -0700 (PDT) Received: by ruminary.org (Postfix, from userid 1000) id C4C1422E19; Mon, 3 Jun 2002 09:58:25 -0700 (PDT) Date: Mon, 3 Jun 2002 09:58:25 -0700 From: clark shishido To: Nguyen-Tuong Long Le Cc: freebsd-net@freebsd.org Subject: Re: Problem with SYN cache in FreeBSD 4.5 Message-ID: <20020603095825.A47070@ruminary.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from le@cs.unc.edu on Mon, Jun 03, 2002 at 01:59:13AM -0400 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, Jun 03, 2002 at 01:59:13AM -0400, Nguyen-Tuong Long Le wrote: > Hi all, > > Our group has a proprietary web server that can handle 10000 requests/s > under FreeBSD 4.3 release. We recently upgraded our system to 4.5 and got > very poor performance. While the web server runs, I see lots of messages > similar to the following on the console > "Limiting open port RST response from 1068 to 200 packets per second". > > The problem seems to be related to the syncache implementation > that drops incoming SYN segments. 4.5-RELEASE included a new feature, syncookies try turning it off: net.inet.tcp.syncookies: 0 you might also need to patch the kernel: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02%3A20.syncache.asc --clark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 10:12:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d101.as15.nwbl0.wi.voyager.net [169.207.134.229]) by hub.freebsd.org (Postfix) with ESMTP id DCB4137B406 for ; Mon, 3 Jun 2002 10:12:06 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g53HDaOA038456; Mon, 3 Jun 2002 12:13:36 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g53HDWTD038453; Mon, 3 Jun 2002 12:13:34 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 3 Jun 2002 12:13:32 -0500 (CDT) From: Mike Silbersack To: Nguyen-Tuong Long Le Cc: freebsd-net@freebsd.org Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: Message-ID: <20020603121118.Y38431-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, 3 Jun 2002, Nguyen-Tuong Long Le wrote: > Hi all, > > Our group has a proprietary web server that can handle 10000 requests/s > under FreeBSD 4.3 release. We recently upgraded our system to 4.5 and got > very poor performance. While the web server runs, I see lots of messages > similar to the following on the console > "Limiting open port RST response from 1068 to 200 packets per second". > > The problem seems to be related to the syncache implementation > that drops incoming SYN segments. I've tried to increase the size of > the hash table but that didn't seem to help much. Here is the output > of "sysctl net.inet.tcp.syncache". A few questions: 1. Is this 4.5-release, or 4.5-stable (aka 4.6-RC2)? 4.5-release had a few bugs in the syn cache which could cause crashes. 2. Are you using accept filters? Accept filters act oddly on 4.5-release, you'll have to upgrade to 4.5-stable/4.6. 3. Could you use tcpdump to determine what exactly is going wrong and post a url to the log so that we can investigate what is going wrong? Thanks, 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 Mon Jun 3 10:40:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 317DD37B406 for ; Mon, 3 Jun 2002 10:40:15 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603174010.DICD13253.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 3 Jun 2002 17:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA43271; Mon, 3 Jun 2002 10:33:36 -0700 (PDT) Date: Mon, 3 Jun 2002 10:33:35 -0700 (PDT) From: Julian Elischer To: Barry Irwin Cc: freebsd-net@freebsd.org Subject: Re: GRE on 4.x In-Reply-To: <20020603125202.F43867@itouchlabs.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 GRE is used for PPTP use MPD as a PPTP agent and add IPSEC security associations for that pair of machines.. (not SURE that will work but I'm experimenting with exactly this myself.) On Mon, 3 Jun 2002, Barry Irwin wrote: > Hi All > > I'm trying to integrate with a business aprner here who have a requirement > we use GRE tunnel inside of IPSEC for a number of reasons. While the gif(4) > device provides IPIP tunneling (proto 4) this doesnt work when the remote > side is expecting true GRE (proto 47). > > Has any one had any experiance working with GRE tunnels under FBSD. I have > tried the following two resources I found but not much success on either. > > http://mike.spottydogs.org/projects/gre-tun/ > > http://www.pointless.net/~jasper/consume/docs/my-docs/tunneling.html > > The latter creates a GRE device, but has issues compiling on 4.3 which is > unfortunately what the production system in question runs. > > Barry > > -- > Barry Irwin bvi@itouchlabs.com +27214875177 > Systems Administrator: Networks And Security > Itouch Labs http://www.itouchlabs.com South Africa > > > 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 Mon Jun 3 12:14:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 213C037B406 for ; Mon, 3 Jun 2002 12:14:26 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA79988; Mon, 3 Jun 2002 12:14:13 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g53JD7547163; Mon, 3 Jun 2002 12:13:07 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206031913.g53JD7547163@arch20m.dellroad.org> Subject: Race condition with M_EXT ref count? To: freebsd-net@freebsd.org Date: Mon, 3 Jun 2002 12:13:07 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (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 This is a question about M_EXT mbuf reference counts in FreeBSD-stable. There are several instances in kern/uipc_mbuf.c that add a reference to an M_EXT mbuf by either incrementing the entry in the mclrefcnt[] array or invoking the "custom" ext_ref routine. However, it seems that these instances are all broken because they don't wrap these operations within splimp()... Isn't the following C statement *not* atomic? mclrefcnt[mtocl(m->m_ext.ext_buf)]++; And isn't access to mclrefcnt[] supposed to be protected by splimp()? Note: MCLFREE() *does* set splimp() before decrementing M_EXT ref counts. Therefore, isn't there a race condition wrt. the M_EXT reference counts? The functions which fail to set splimp() before adding a reference are: m_copym() m_copypacket() m_split() Thanks for any comments/clarification on this subject.. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 12:29:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id CBE0E37B404 for ; Mon, 3 Jun 2002 12:29:14 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g53JTDC78767; Mon, 3 Jun 2002 12:29:13 -0700 (PDT) (envelope-from rizzo) Date: Mon, 3 Jun 2002 12:29:13 -0700 From: Luigi Rizzo To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ Message-ID: <20020603122913.A78688@iguana.icir.org> References: <3CFB9BC4.9080506@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CFB9BC4.9080506@isi.edu>; from larse@ISI.EDU on Mon, Jun 03, 2002 at 09:39:32AM -0700 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, Jun 03, 2002 at 09:39:32AM -0700, Lars Eggert wrote: > Hi, > > the Dummynet page has this example WFQ configuration: > > ipfw add queue 1 ip from any to 10.1.2.0/24 > ipfw queue 1 config weight 5 pipe 2 mask dst-ip 0x000000ff > ipfw pipe 2 config bw 300Kbit/s > > The 300Kbit/s seems to be the bandwidth limit of the uplink. I'd imagine > that extra uplink bandwidth would remain unused in this setup, right? Is > it possible to do WFQ when the uplink bandwidth is unknown/unspecified? the signal that tell the WFQ algorithm when you can transmit the next packet comes from the pipe. The latter ticks either at a predefined rate (as configured with the 'bw NNN bit/s' parameter), or from the tx interrupt coming from a device (e.g. you can say something like 'bw ed0' to get the transmit clock from device ed0). HOWEVER: i have implemented the necessary machinery in dummynet (it is a function called if_tx_rdy()) and in the user interface, "ipfw", but have not added the hooks to call if_tx_rdy() in each device driver because these calls are somewhat expensive, and you probably do not want them on a 100Mbit/s interface. See http://www.geocrawler.com/archives/3/165/2002/3/0/8222181/ on how to use them (a search for "dummynet if_tx_rdy()" should return some results). I should definitely commit this stuff on the slow interfaces, or perhaps in such a way that the callback is only invoked if there is a client for it, once 4.6R is released. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 12:40:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 384F837B404; Mon, 3 Jun 2002 12:40:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603194008.EUMT2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 3 Jun 2002 19:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA43671; Mon, 3 Jun 2002 12:25:53 -0700 (PDT) Date: Mon, 3 Jun 2002 12:25:52 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <200206031913.g53JD7547163@arch20m.dellroad.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 this is YET ANOTHER case for the Atomic reference counting ABI that jhb has been talking about... On Mon, 3 Jun 2002, Archie Cobbs wrote: > This is a question about M_EXT mbuf reference counts in FreeBSD-stable. > > There are several instances in kern/uipc_mbuf.c that add a reference > to an M_EXT mbuf by either incrementing the entry in the mclrefcnt[] > array or invoking the "custom" ext_ref routine. > > However, it seems that these instances are all broken because they > don't wrap these operations within splimp()... > > Isn't the following C statement *not* atomic? > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > > And isn't access to mclrefcnt[] supposed to be protected by splimp()? > Note: MCLFREE() *does* set splimp() before decrementing M_EXT ref counts. > > Therefore, isn't there a race condition wrt. the M_EXT reference counts? > > The functions which fail to set splimp() before adding a reference are: > > m_copym() > m_copypacket() > m_split() > > Thanks for any comments/clarification on this subject.. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > 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 Mon Jun 3 13:33:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 7F4AD37B406; Mon, 3 Jun 2002 13:33:43 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 52171AE1C1; Mon, 3 Jun 2002 13:33:43 -0700 (PDT) Date: Mon, 3 Jun 2002 13:33:43 -0700 From: Alfred Perlstein To: Julian Elischer Cc: Archie Cobbs , freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603203343.GM64510@elvis.mu.org> References: <200206031913.g53JD7547163@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i 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 * Julian Elischer [020603 12:41] wrote: > this is YET ANOTHER case for the Atomic reference counting ABI that > jhb has been talking about... I was the initial person to request an atomic_t API. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 14: 0:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id A8E6837B404; Mon, 3 Jun 2002 14:00:19 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603210019.IDZJ13253.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 3 Jun 2002 21:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA44012; Mon, 3 Jun 2002 13:53:21 -0700 (PDT) Date: Mon, 3 Jun 2002 13:53:21 -0700 (PDT) From: Julian Elischer To: Alfred Perlstein Cc: Archie Cobbs , freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <20020603203343.GM64510@elvis.mu.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 Not denying that, just that JHB has a preliminary implementation he's been showing around... On Mon, 3 Jun 2002, Alfred Perlstein wrote: > * Julian Elischer [020603 12:41] wrote: > > this is YET ANOTHER case for the Atomic reference counting ABI that > > jhb has been talking about... > > I was the initial person to request an atomic_t API. > > -Alfred > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" 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 Mon Jun 3 15: 0:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id AB58A37B400 for ; Mon, 3 Jun 2002 15:00:06 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA80810; Mon, 3 Jun 2002 14:44:11 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g53Lh5c47636; Mon, 3 Jun 2002 14:43:05 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206032143.g53Lh5c47636@arch20m.dellroad.org> Subject: Re: Race condition with M_EXT ref count? In-Reply-To: "from Julian Elischer at Jun 3, 2002 01:53:21 pm" To: Julian Elischer Date: Mon, 3 Jun 2002 14:43:05 -0700 (PDT) Cc: Alfred Perlstein , Archie Cobbs , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (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 Julian Elischer writes: > Not denying that, just that JHB has a preliminary implementation > he's been showing around... > > > > this is YET ANOTHER case for the Atomic reference counting ABI that > > > jhb has been talking about... > > > > I was the initial person to request an atomic_t API. You guys please stop changing the subject :-) Can somebody confirm that they think this bug is real/valid? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15: 7:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 9748637B40A for ; Mon, 3 Jun 2002 15:07:07 -0700 (PDT) Received: (qmail 22121 invoked from network); 3 Jun 2002 22:06:42 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 3 Jun 2002 22:06:42 -0000 Message-ID: <3CFBE83F.3E7025A4@pipeline.ch> Date: Tue, 04 Jun 2002 00:05:51 +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: freebsd-net@FreeBSD.ORG, silby@silby.com Subject: Re: Bug in net/route.c function rtredirect() References: <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@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: > > On Sat, Jun 01, 2002 at 12:49:51PM +0200, Andre Oppermann wrote: > > You're right but the refcount decrementation will be done, just in a > > different place. In the "done:" section the rtfree() will be done also > > in the case when an existing host route was already present. > > > No it won't be done in "done:", because a few lines later we assign > rt = NULL: > > create: > if (rt) > rt->rt_refcnt--; > flags |= RTF_GATEWAY | RTF_DYNAMIC; > bzero((caddr_t)&info, sizeof(info)); > info.rti_info[RTAX_DST] = dst; > info.rti_info[RTAX_GATEWAY] = gateway; > info.rti_info[RTAX_NETMASK] = netmask; > info.rti_ifa = ifa; > info.rti_flags = flags; > rt = NULL; > > > > > The solution is to remove the rtfree() in rtredirect. Diff against > > > > -STABLE is attached. Should apply to -CURRENT with some fuzz. > > > > > > > No, please try the below patch instead. > > > > The rtfree() I removed is one too many and still has to go. Your patch > > doesn't change the problem, it just makes it different. Routes could > > go below zero refcount in your version. > > > The second rt->rt_refcnt-- I added is indeed unnecessary, you're > right here. After reading this whole redirect stuff a couple of time I've come to the conclusion that the function is right as it is there. There is no such bug as I described it. The rtalloc1() in rtredirect() is incre- menting the refcount on the route found, the two rtfree() after "create:" and "done:" will decrement it as it is must happen (we don't have a reference to that route because we don't clone here). A bug is that host routes created by redirect are never being purged. But that one has been present for a long (?) time. I'm still try to track a problem with the following situation: 1. I get a tcp syn from somewhere, 2. a host route is created by tcp, 3. the synack is sent back, 4. we get a redirect from the router to use a different router, 5. host route created from tcp is updated and replaced by icmp redirect route, 6. I see a RTM_LOSING message and the redirect route is being purged. This happens in, I think, some 5% of the cases. What I'm tracking is why the rtfree() after "create:" is de-refcounting the default route when we should have updated the host route created by tcp before. Maybe this is a side-effect of the tcp syncache and the flow has changed? I'll track what happens there. > Heh, so you in fact tried to rtfree() "rt" in "done:" by adding > "rtn". And how *rtp (if rtp != NULL) will become "rtn" then? > What about this? No. No bug as I said, no need to patch. Sorry for this touble. For the expiration of redirects I'll port/adapt the NetBSD solution and post the patch here. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15:20:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 6FFA537B404 for ; Mon, 3 Jun 2002 15:20:07 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603222007.KFQZ13253.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 3 Jun 2002 22:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA44360; Mon, 3 Jun 2002 15:08:02 -0700 (PDT) Date: Mon, 3 Jun 2002 15:08:01 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Alfred Perlstein , freebsd-net@freebsd.org Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <200206032143.g53Lh5c47636@arch20m.dellroad.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 well, it's a valid problem form the point of view of some interrupt code changing the ext reference at teh same time that some other code is planning on incrementing it, but while Giant is in place it's not likely to affect anything.. I presume you are talking about 4.x however right? we can presume that each manipulator has a reference so it's not going to GA AWAY due to a zero reference being reached, so the link can be followed safely, which just elaves the atomicity of the addition operation. who are the contenders? 1/ network mid-level code? (protected by: splnet and the BGL. Only one cpu at a time.. 2/ Interrupt code running at splimp probably freeing stuff after transmit. (receivers should have pre-allocated buffers) it IS possible that there could need to be an splimp() added but I am not clear on what part the 4.4 BGL (Big Giant Lock) plays in this.. it may make it safe... On Mon, 3 Jun 2002, Archie Cobbs wrote: > Julian Elischer writes: > > Not denying that, just that JHB has a preliminary implementation > > he's been showing around... > > > > > > this is YET ANOTHER case for the Atomic reference counting ABI that > > > > jhb has been talking about... > > > > > > I was the initial person to request an atomic_t API. > > You guys please stop changing the subject :-) > > Can somebody confirm that they think this bug is real/valid? > > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15:26:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from web13307.mail.yahoo.com (web13307.mail.yahoo.com [216.136.175.43]) by hub.freebsd.org (Postfix) with SMTP id DF66D37B409 for ; Mon, 3 Jun 2002 15:26:19 -0700 (PDT) Message-ID: <20020603222619.48900.qmail@web13307.mail.yahoo.com> Received: from [206.220.224.4] by web13307.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 15:26:19 PDT Date: Mon, 3 Jun 2002 15:26:19 -0700 (PDT) From: Maksim Yevmenkin Subject: -current Netgraph (ng_parse) problem To: freebsd-current@freebsd.org Cc: 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 Hackers, I'm having hard time with Netgraph on recent -current. First, there is a lot of warnings (see below) related to initialization of struct ng_parse_struct_info. I think it is related to zero sized "fields" array. Someone else already posted about the same problem. Second, my laptop crashes with Jun 3 15:10:23 beetle kernel: Fatal double fault: Jun 3 15:10:23 beetle kernel: eip = 0xc9c41a61 Jun 3 15:10:23 beetle kernel: esp = 0xc9fc1000 Jun 3 15:10:23 beetle kernel: ebp = 0xc9fc1008 Jun 3 15:10:23 beetle kernel: panic: double fault Jun 3 15:10:23 beetle kernel: panic: from debugger Jun 3 15:10:23 beetle kernel: Uptime: 2h37m34s Jun 3 15:10:23 beetle kernel: pfs_vncache_unload(): 2 entries remaining Jun 3 15:10:23 beetle kernel: /dev/vmmon: Module vmmon: unloaded Jun 3 15:10:23 beetle kernel: Automatic reboot in 15 seconds - press a key on t he console to abort Jun 3 15:10:23 beetle kernel: --> Press a key on the console to reboot, every time i try to use ngctl to get structures from Netgraph nodes. Of course i suspected my own code, until i tried ng_tee. Same crash :( Is there a quick fix? Or is it "doctor it hurts when i press here" thing. thanks, max beetle% gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) beetle% uname -a FreeBSD beetle 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri May 24 13:24:05 PDT 2002 max@beetle:/usr/obj/usr/src/sys/BEETLE i386 beetle% beetle% make Warning: Object directory not changed from original /usr/home/max/bluetooth/freebsd/current/bt3c @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h cc -O -pipe -g -I../hci/ -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -DKLD_MODULE -nostdinc -I- -I../hci/ -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -c bt3c_pccard.c bt3c_pccard.c:205: warning: excess elements in array initializer bt3c_pccard.c:205: warning: (near initialization for `ng_bt3c_stat_type_info.fields') bt3c_pccard.c:206: warning: excess elements in array initializer bt3c_pccard.c:206: warning: (near initialization for `ng_bt3c_stat_type_info.fields') bt3c_pccard.c:207: warning: excess elements in array initializer bt3c_pccard.c:207: warning: (near initialization for `ng_bt3c_stat_type_info.fields') bt3c_pccard.c:208: warning: excess elements in array initializer bt3c_pccard.c:208: warning: (near initialization for `ng_bt3c_stat_type_info.fields') bt3c_pccard.c:209: warning: excess elements in array initializer bt3c_pccard.c:209: warning: (near initialization for `ng_bt3c_stat_type_info.fields') ld -d -warn-common -r -d -o ng_bt3c.kld bt3c_pccard.o touch /usr/home/max/bluetooth/freebsd/current/bt3c/export_syms awk -f /sys/conf/kmod_syms.awk ng_bt3c.kld /usr/home/max/bluetooth/freebsd/current/bt3c/export_syms | xargs -J% objcopy % ng_bt3c.kld ld -Bshareable -d -warn-common -o ng_bt3c.ko ng_bt3c.kld beetle% __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15:33: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 9F78E37B403 for ; Mon, 3 Jun 2002 15:32:57 -0700 (PDT) Received: (qmail 22790 invoked from network); 3 Jun 2002 22:32:32 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 3 Jun 2002 22:32:32 -0000 Message-ID: <3CFBEE4D.80363D65@pipeline.ch> Date: Tue, 04 Jun 2002 00:31:41 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Race condition with M_EXT ref count? References: <200206031913.g53JD7547163@arch20m.dellroad.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 Archie Cobbs wrote: > > This is a question about M_EXT mbuf reference counts in FreeBSD-stable. > > There are several instances in kern/uipc_mbuf.c that add a reference > to an M_EXT mbuf by either incrementing the entry in the mclrefcnt[] > array or invoking the "custom" ext_ref routine. > > However, it seems that these instances are all broken because they > don't wrap these operations within splimp()... > > Isn't the following C statement *not* atomic? > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > > And isn't access to mclrefcnt[] supposed to be protected by splimp()? > Note: MCLFREE() *does* set splimp() before decrementing M_EXT ref counts. > > Therefore, isn't there a race condition wrt. the M_EXT reference counts? Yes, this looks dangerous. If you get hit by an interrupt the thing could change under you. Part of this has been discussed a couple of month ago in a thread about 64bit interface counter and atomic updates for (ref)counters in the network stack. Also patches implementing atomic counters for this purpose and performace numbers have been postet within that thread. The best would be to dig that up. I think the subject was along the lines of "64bit counters" or so. There are a couple of other places which look suspicious in similiar regard. There are some suspicius instances of direct rt_refcnt-- decrements. Normally this should be done via RTFREE() so that routes could end up with refcount zero without getting freed. Also sometimes the function rtfree() is called directly instead of the macro RTFREE as in the vast majority of the places. If time permits I'll look into these cases. -- Andre > The functions which fail to set splimp() before adding a reference are: > > m_copym() > m_copypacket() > m_split() > > Thanks for any comments/clarification on this subject.. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > 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 Mon Jun 3 15:37:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6585637B40A for ; Mon, 3 Jun 2002 15:37:01 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g53Mb0DK018957; Mon, 3 Jun 2002 18:37:00 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g53Mb0h1018954; Mon, 3 Jun 2002 18:37:00 -0400 (EDT) (envelope-from wollman) Date: Mon, 3 Jun 2002 18:37:00 -0400 (EDT) From: Garrett Wollman Message-Id: <200206032237.g53Mb0h1018954@khavrinen.lcs.mit.edu> To: Andre Oppermann Cc: freebsd-net@FreeBSD.ORG Subject: Re: Bug in net/route.c function rtredirect() In-Reply-To: <3CFBE83F.3E7025A4@pipeline.ch> References: <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> 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 < said: > A bug is that host routes created by redirect are never being purged. > But that one has been present for a long (?) time. You are expected to be running a routing process (like `routed' in router-discovery mode) which will delete them for you. I agree that this is not a reasonable expectation, but that was the design intent. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15:43:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id C0A7C37B403; Mon, 3 Jun 2002 15:43:37 -0700 (PDT) Received: from pool0111.cvx22-bradley.dialup.earthlink.net ([209.179.198.111] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17F0Y1-0006cs-00; Mon, 03 Jun 2002 15:43:34 -0700 Message-ID: <3CFBF0F5.21A7EC1B@mindspring.com> Date: Mon, 03 Jun 2002 15:43:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Archie Cobbs , freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? References: 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 Julian Elischer wrote: > this is YET ANOTHER case for the Atomic reference counting ABI that > jhb has been talking about... No, they're not. They occur on m_copym, m_copypacket, and m_split. In practice, these are called seperately in the down and up path, and this isn't a problem (in the up path, SPLNET runs at the call to splx(), and in the down-path, the objects that are the target of the operations are/should_be locked). This sounds like a Netgraph related problem associated with the use of a kernel thread. All three of these operations can result in an allocation, and the allocation requires that the operation that calss it set splimp (comments in the same file). If this is a threaded case (e.g. -current, not 4.5/4.6 or earlier), then you would probably be saved by some of the work that Jeffrey Hsu and John Mini have done recently. For 4.5 and 4.6, it really should not be a problem (I think). -- Terry > > On Mon, 3 Jun 2002, Archie Cobbs wrote: > > > This is a question about M_EXT mbuf reference counts in FreeBSD-stable. > > > > There are several instances in kern/uipc_mbuf.c that add a reference > > to an M_EXT mbuf by either incrementing the entry in the mclrefcnt[] > > array or invoking the "custom" ext_ref routine. > > > > However, it seems that these instances are all broken because they > > don't wrap these operations within splimp()... > > > > Isn't the following C statement *not* atomic? > > > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > > > > And isn't access to mclrefcnt[] supposed to be protected by splimp()? > > Note: MCLFREE() *does* set splimp() before decrementing M_EXT ref counts. > > > > Therefore, isn't there a race condition wrt. the M_EXT reference counts? > > > > The functions which fail to set splimp() before adding a reference are: > > > > m_copym() > > m_copypacket() > > m_split() > > > > Thanks for any comments/clarification on this subject.. > > > > -Archie > > > > __________________________________________________________________________ > > Archie Cobbs * Packet Design * http://www.packetdesign.com > > > > 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-smp" 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 Mon Jun 3 15:45: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3717337B408; Mon, 3 Jun 2002 15:45:03 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA81165; Mon, 3 Jun 2002 15:39:28 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g53McMo47944; Mon, 3 Jun 2002 15:38:22 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206032238.g53McMo47944@arch20m.dellroad.org> Subject: Re: -current Netgraph (ng_parse) problem In-Reply-To: <20020603222619.48900.qmail@web13307.mail.yahoo.com> "from Maksim Yevmenkin at Jun 3, 2002 03:26:19 pm" To: Maksim Yevmenkin Date: Mon, 3 Jun 2002 15:38:22 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Maksim Yevmenkin writes: > I'm having hard time with Netgraph on recent -current. > > First, there is a lot of warnings (see below) related to > initialization of struct ng_parse_struct_info. I think > it is related to zero sized "fields" array. Someone else > already posted about the same problem. This was fixed a couple of days ago. > Second, my laptop crashes with > > Jun 3 15:10:23 beetle kernel: Fatal double fault: > Jun 3 15:10:23 beetle kernel: eip = 0xc9c41a61 > Jun 3 15:10:23 beetle kernel: esp = 0xc9fc1000 > Jun 3 15:10:23 beetle kernel: ebp = 0xc9fc1008 > Jun 3 15:10:23 beetle kernel: panic: double fault > Jun 3 15:10:23 beetle kernel: panic: from debugger > Jun 3 15:10:23 beetle kernel: Uptime: 2h37m34s > Jun 3 15:10:23 beetle kernel: pfs_vncache_unload(): 2 entries remaining > Jun 3 15:10:23 beetle kernel: /dev/vmmon: Module vmmon: unloaded > Jun 3 15:10:23 beetle kernel: Automatic reboot in 15 seconds - press a key on > t > he console to abort > Jun 3 15:10:23 beetle kernel: --> Press a key on the console to reboot, > > every time i try to use ngctl to get structures from Netgraph > nodes. Of course i suspected my own code, until i tried ng_tee. > Same crash :( Try and see if you can get a complete stack trace... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 15:48: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 6B06137B400 for ; Mon, 3 Jun 2002 15:47:59 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.3/8.12.1) with ESMTP id g53MlfMR022141; Mon, 3 Jun 2002 18:47:41 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.3/8.12.1/Submit) id g53MleqI022136; Mon, 3 Jun 2002 18:47:40 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 3 Jun 2002 18:47:40 -0400 From: Bosko Milekic To: Julian Elischer Cc: Archie Cobbs , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603184740.A19963@unixdaemons.com> References: <200206032143.g53Lh5c47636@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Mon, Jun 03, 2002 at 03:08:01PM -0700 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 First of all, this issue is non-existant in -CURRENT, where all reference counting is done via a consistent interface that provides bus-locked reference count manipulations. Secondly, this may not be as much of a problem as you may think. Particularly if you consider the m_split() case, for example. For example, if you're calling m_split() on an mbuf chain that may refer to cluster(s) where none of the clusters has a ref. count greater than 1 -- which is usually the case anyway -- then this is fine; since you have posession of the chain referring to those clusters, and presumably the chain isn't sitting in some queue somewhere (if it is, you'd have to be under the protection of that queue anyway - splimp() or whatever), then you're the only one who has posession of that cluster and you'll be the only candidate incrementing the ref. count, regardless of whether an interrupt comes in or not. Perhaps the real solution would be to do something like: if (ref count > 1) { do atomic inc. } else { do regular inc. } Or, alternately, do what -CURRENT does (and it's probably simpler anyway) and just make it all atomic. I'm sorry to say that I don't develop on -STABLE much anymore (namely, because I don't run it at home) so I cannot make this change any time soon. On Mon, Jun 03, 2002 at 03:08:01PM -0700, Julian Elischer wrote: > well, it's a valid problem form the point of view of some interrupt code > changing the ext reference at teh same time that some other code is > planning on incrementing it, but while Giant is in place it's not > likely to affect anything.. > > > I presume you are talking about 4.x however right? > we can presume that each manipulator has a reference so it's not going to > GA AWAY due to a zero reference being reached, so the link can be followed > safely, which just elaves the atomicity of the addition operation. > > who are the contenders? > 1/ network mid-level code? (protected by: splnet and the BGL. > Only one cpu at a time.. > > 2/ Interrupt code running at splimp > probably freeing stuff after transmit. (receivers should have > pre-allocated buffers) > > it IS possible that there could need to be an splimp() added but I am > not clear on what part the 4.4 BGL (Big Giant Lock) plays in this.. > it may make it safe... > > On Mon, 3 Jun 2002, Archie Cobbs wrote: > > > Julian Elischer writes: > > > Not denying that, just that JHB has a preliminary implementation > > > he's been showing around... > > > > > > > > this is YET ANOTHER case for the Atomic reference counting ABI that > > > > > jhb has been talking about... > > > > > > > > I was the initial person to request an atomic_t API. > > > > You guys please stop changing the subject :-) > > > > Can somebody confirm that they think this bug is real/valid? > > > > Thanks, > > -Archie > > > > __________________________________________________________________________ > > Archie Cobbs * Packet Design * http://www.packetdesign.com > > -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@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 Jun 3 15:48: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 23A9837B403; Mon, 3 Jun 2002 15:48:03 -0700 (PDT) Received: from pool0111.cvx22-bradley.dialup.earthlink.net ([209.179.198.111] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17F0cJ-0004dn-00; Mon, 03 Jun 2002 15:47:59 -0700 Message-ID: <3CFBF1FD.4DF1AED6@mindspring.com> Date: Mon, 03 Jun 2002 15:47:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Julian Elischer , Archie Cobbs , freebsd-net@freebsd.org, smp@freebsd.org Subject: Re: Race condition with M_EXT ref count? References: <200206031913.g53JD7547163@arch20m.dellroad.org> <20020603203343.GM64510@elvis.mu.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 Alfred Perlstein wrote: > * Julian Elischer [020603 12:41] wrote: > > this is YET ANOTHER case for the Atomic reference counting ABI that > > jhb has been talking about... > > I was the initial person to request an atomic_t API. I think the request count was non-atomically incremented by a lot of people, around the same time. If we had only had one at the time, we could assign the credit for the request to have one, properly... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 16:15:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id CFD5637B405 for ; Mon, 3 Jun 2002 16:15:08 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA81376; Mon, 3 Jun 2002 16:02:34 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g53N1To48300; Mon, 3 Jun 2002 16:01:29 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206032301.g53N1To48300@arch20m.dellroad.org> Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <20020603184740.A19963@unixdaemons.com> "from Bosko Milekic at Jun 3, 2002 06:47:40 pm" To: Bosko Milekic Date: Mon, 3 Jun 2002 16:01:29 -0700 (PDT) Cc: Julian Elischer , Archie Cobbs , Alfred Perlstein , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Bosko Milekic writes: > Secondly, this may not be as much of a problem as you may think. > Particularly if you consider the m_split() case, for example. For > example, if you're calling m_split() on an mbuf chain that may refer > to cluster(s) where none of the clusters has a ref. count greater than > 1 -- which is usually the case anyway -- then this is fine; since you > have posession of the chain referring to those clusters, and > presumably the chain isn't sitting in some queue somewhere (if it is, > you'd have to be under the protection of that queue anyway - splimp() > or whatever), then you're the only one who has posession of that The *chain* won't be sitting in a queue, but there may be a different mbuf in a queue somehwere that points to the same cluster. Since mid-level code only increments the ref count, I think the worst that can happen is the ref count is incorrectly too high, which could only cause a memory leak rather than a crash. There's not way for the ref count to be too low, or for the cluster to be free'd twice, because all decrements are protected by splimp(). However, once you start adding in custom code then we may not be so lucky.. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 16:15:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id D1D9D37B401 for ; Mon, 3 Jun 2002 16:15:04 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA81290; Mon, 3 Jun 2002 15:55:08 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g53Ms2O48132; Mon, 3 Jun 2002 15:54:02 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206032254.g53Ms2O48132@arch20m.dellroad.org> Subject: Re: Race condition with M_EXT ref count? In-Reply-To: "from Julian Elischer at Jun 3, 2002 03:08:01 pm" To: Julian Elischer Date: Mon, 3 Jun 2002 15:54:02 -0700 (PDT) Cc: Archie Cobbs , Alfred Perlstein , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (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 Julian Elischer writes: > well, it's a valid problem form the point of view of some interrupt code > changing the ext reference at teh same time that some other code is > planning on incrementing it, but while Giant is in place it's not > likely to affect anything.. > > I presume you are talking about 4.x however right? Yes (see original email). > we can presume that each manipulator has a reference so it's not going to > GA AWAY due to a zero reference being reached, so the link can be followed > safely, which just elaves the atomicity of the addition operation. > > who are the contenders? > 1/ network mid-level code? (protected by: splnet and the BGL. > Only one cpu at a time.. > > 2/ Interrupt code running at splimp > probably freeing stuff after transmit. (receivers should have > pre-allocated buffers) > > it IS possible that there could need to be an splimp() added but I am > not clear on what part the 4.4 BGL (Big Giant Lock) plays in this.. > it may make it safe... If you don't mind, I'll let you deal with the -current case, since I'm not familiar enough with -current locking. Below is my proposed patch for -stable. It should be clear that in -stable at least, there can be a race between an interrupt handler that free's a cluster mbuf and mid-level code that is free'ing the same mbuf, for example. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- sys/kern/uipc_mbuf.c.orig Mon Jun 3 15:43:25 2002 +++ sys/kern/uipc_mbuf.c Mon Jun 3 15:52:28 2002 @@ -707,11 +707,16 @@ n->m_len = min(len, m->m_len - off); if (m->m_flags & M_EXT) { n->m_data = m->m_data + off; - if(!m->m_ext.ext_ref) - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; - else - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, - m->m_ext.ext_size); + if (m->m_ext.ext_ref == NULL) { + atomic_add_char( + &mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); + } else { + int s = splimp(); + + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, + m->m_ext.ext_size); + splx(s); + } n->m_ext = m->m_ext; n->m_flags |= M_EXT; } else @@ -754,11 +759,15 @@ n->m_len = m->m_len; if (m->m_flags & M_EXT) { n->m_data = m->m_data; - if(!m->m_ext.ext_ref) - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; - else - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, - m->m_ext.ext_size); + if (m->m_ext.ext_ref == NULL) + atomic_add_char(&mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); + else { + int s = splimp(); + + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, + m->m_ext.ext_size); + splx(s); + } n->m_ext = m->m_ext; n->m_flags |= M_EXT; } else { @@ -777,11 +786,16 @@ n->m_len = m->m_len; if (m->m_flags & M_EXT) { n->m_data = m->m_data; - if(!m->m_ext.ext_ref) - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; - else - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, - m->m_ext.ext_size); + if (m->m_ext.ext_ref == NULL) { + atomic_add_char( + &mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); + } else { + int s = splimp(); + + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, + m->m_ext.ext_size); + splx(s); + } n->m_ext = m->m_ext; n->m_flags |= M_EXT; } else { @@ -1125,11 +1139,15 @@ if (m->m_flags & M_EXT) { n->m_flags |= M_EXT; n->m_ext = m->m_ext; - if(!m->m_ext.ext_ref) - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; - else - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, - m->m_ext.ext_size); + if (m->m_ext.ext_ref == NULL) + atomic_add_char(&mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); + else { + int s = splimp(); + + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, + m->m_ext.ext_size); + splx(s); + } m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ n->m_data = m->m_data + len; } else { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 16:37:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 38E7137B401 for ; Mon, 3 Jun 2002 16:37:08 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.3/8.12.1) with ESMTP id g53NapMR030131; Mon, 3 Jun 2002 19:36:51 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.3/8.12.1/Submit) id g53NapqZ030129; Mon, 3 Jun 2002 19:36:51 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 3 Jun 2002 19:36:51 -0400 From: Bosko Milekic To: Archie Cobbs Cc: Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603193651.A29296@unixdaemons.com> References: <20020603184740.A19963@unixdaemons.com> <200206032301.g53N1To48300@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206032301.g53N1To48300@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Jun 03, 2002 at 04:01:29PM -0700 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, Jun 03, 2002 at 04:01:29PM -0700, Archie Cobbs wrote: > Bosko Milekic writes: > > Secondly, this may not be as much of a problem as you may think. > > Particularly if you consider the m_split() case, for example. For > > example, if you're calling m_split() on an mbuf chain that may refer > > to cluster(s) where none of the clusters has a ref. count greater than > > 1 -- which is usually the case anyway -- then this is fine; since you > > have posession of the chain referring to those clusters, and > > presumably the chain isn't sitting in some queue somewhere (if it is, > > you'd have to be under the protection of that queue anyway - splimp() > > or whatever), then you're the only one who has posession of that > > The *chain* won't be sitting in a queue, but there may be a different > mbuf in a queue somehwere that points to the same cluster. I did say "if the refcount is exactly 1" !!!! (which is often the case in there). > Since mid-level code only increments the ref count, I think the > worst that can happen is the ref count is incorrectly too high, > which could only cause a memory leak rather than a crash. No, the worse case is that it is too low. increment: read inc write two increments, unprotected: count initially: 1 read 1 inc 1->2 read 1 write 2 inc 1->2 write 2 count finally: 2 (it should be 3 now) Two frees will now result in the cluster being freed instead of 3. The final free will be bogus. > There's not way for the ref count to be too low, or for the cluster > to be free'd twice, because all decrements are protected by splimp(). > > However, once you start adding in custom code then we may not be > so lucky.. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@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 Jun 3 16:39:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 71ECD37B400 for ; Mon, 3 Jun 2002 16:39:34 -0700 (PDT) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.3/8.12.1) with ESMTP id g53NdMMR030519; Mon, 3 Jun 2002 19:39:23 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host bmilekic@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.3/8.12.1/Submit) id g53NdMrJ030516; Mon, 3 Jun 2002 19:39:22 -0400 (EDT) (envelope-from bmilekic) Date: Mon, 3 Jun 2002 19:39:22 -0400 From: Bosko Milekic To: Archie Cobbs Cc: Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? Message-ID: <20020603193922.B29296@unixdaemons.com> References: <200206032254.g53Ms2O48132@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206032254.g53Ms2O48132@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Jun 03, 2002 at 03:54:02PM -0700 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, Jun 03, 2002 at 03:54:02PM -0700, Archie Cobbs wrote: [...] > If you don't mind, I'll let you deal with the -current case, since > I'm not familiar enough with -current locking. Below is my proposed > patch for -stable. -current does not have this "problem." > It should be clear that in -stable at least, there can be a race > between an interrupt handler that free's a cluster mbuf and mid-level > code that is free'ing the same mbuf, for example. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > --- sys/kern/uipc_mbuf.c.orig Mon Jun 3 15:43:25 2002 > +++ sys/kern/uipc_mbuf.c Mon Jun 3 15:52:28 2002 > @@ -707,11 +707,16 @@ > n->m_len = min(len, m->m_len - off); > if (m->m_flags & M_EXT) { > n->m_data = m->m_data + off; > - if(!m->m_ext.ext_ref) > - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > - else > - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > - m->m_ext.ext_size); > + if (m->m_ext.ext_ref == NULL) { > + atomic_add_char( > + &mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); > + } else { > + int s = splimp(); > + > + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, > + m->m_ext.ext_size); > + splx(s); > + } > n->m_ext = m->m_ext; > n->m_flags |= M_EXT; > } else > @@ -754,11 +759,15 @@ > n->m_len = m->m_len; > if (m->m_flags & M_EXT) { > n->m_data = m->m_data; > - if(!m->m_ext.ext_ref) > - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > - else > - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > - m->m_ext.ext_size); > + if (m->m_ext.ext_ref == NULL) > + atomic_add_char(&mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); > + else { > + int s = splimp(); > + > + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, > + m->m_ext.ext_size); > + splx(s); > + } > n->m_ext = m->m_ext; > n->m_flags |= M_EXT; > } else { > @@ -777,11 +786,16 @@ > n->m_len = m->m_len; > if (m->m_flags & M_EXT) { > n->m_data = m->m_data; > - if(!m->m_ext.ext_ref) > - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > - else > - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > - m->m_ext.ext_size); > + if (m->m_ext.ext_ref == NULL) { > + atomic_add_char( > + &mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); > + } else { > + int s = splimp(); > + > + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, > + m->m_ext.ext_size); > + splx(s); > + } > n->m_ext = m->m_ext; > n->m_flags |= M_EXT; > } else { > @@ -1125,11 +1139,15 @@ > if (m->m_flags & M_EXT) { > n->m_flags |= M_EXT; > n->m_ext = m->m_ext; > - if(!m->m_ext.ext_ref) > - mclrefcnt[mtocl(m->m_ext.ext_buf)]++; > - else > - (*(m->m_ext.ext_ref))(m->m_ext.ext_buf, > - m->m_ext.ext_size); > + if (m->m_ext.ext_ref == NULL) > + atomic_add_char(&mclrefcnt[mtocl(m->m_ext.ext_buf)], 1); > + else { > + int s = splimp(); > + > + (*m->m_ext.ext_ref)(m->m_ext.ext_buf, > + m->m_ext.ext_size); > + splx(s); > + } > m->m_ext.ext_size = 0; /* For Accounting XXXXXX danger */ > n->m_data = m->m_data + len; > } else { It would be better if the thing was in a macro to allow for consistent ref. count manipulation, like in -CURRENT. But whatever, I don't really care. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@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 Jun 3 20:58:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from gateway.posi.net (12-236-90-177.client.attbi.com [12.236.90.177]) by hub.freebsd.org (Postfix) with ESMTP id AECFA37B400 for ; Mon, 3 Jun 2002 20:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.3/8.12.3) with ESMTP id g543w8M7033236 for ; Mon, 3 Jun 2002 20:58:14 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Mon, 3 Jun 2002 20:58:08 -0700 (PDT) From: Kelly Yancey To: freebsd-net@FreeBSD.ORG Subject: Request for review: patch to make netstat -rW behave as described in netstat(1) Message-ID: <20020603205104.T33228-200000@gateway.posi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1401783618-1023163088=:33228" 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-1401783618-1023163088=:33228 Content-Type: TEXT/PLAIN; charset=US-ASCII I would appreciate it if someone could review the attached patch which makes netstat calculate column widths for the routing table when the -W flag is specified rather than just picking larger arbitrary values as it does now. Other than making -W more useful, it syncs reality to the documentation; from netstat(1): -W In certain displays, avoid truncating addresses even if this causes some fields to overflow. Basically, all the patch does is add a preliminary pass to calculate the necessary column widths when -W is specified. It is pretty straightforward, but nonetheless, I'de appreciate feedback before I commit it. Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} * Wow, netstat is so far from WARNS-clean, it's scary. --0-1401783618-1023163088=:33228 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="netstat.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20020603205808.V33228@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="netstat.diff" SW5kZXg6IHVzci5iaW4vbmV0c3RhdC9yb3V0ZS5jDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvdXNyLmJpbi9u ZXRzdGF0L3JvdXRlLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjY1DQpk aWZmIC11IC11IC1yMS42NSByb3V0ZS5jDQotLS0gdXNyLmJpbi9uZXRzdGF0 L3JvdXRlLmMJMzEgTWF5IDIwMDIgMDQ6MzY6NTUgLTAwMDAJMS42NQ0KKysr IHVzci5iaW4vbmV0c3RhdC9yb3V0ZS5jCTQgSnVuIDIwMDIgMDM6NDc6NTcg LTAwMDANCkBAIC0xMjYsMTIgKzEyNiwxOCBAQA0KIGludAlOZXdUcmVlID0g MDsNCiANCiBzdGF0aWMgc3RydWN0IHNvY2thZGRyICprZ2V0c2EgKHN0cnVj dCBzb2NrYWRkciAqKTsNCitzdGF0aWMgdm9pZCBzaXplX2NvbHMgKGludCBl Ziwgc3RydWN0IHJhZGl4X25vZGUgKnJuKTsNCitzdGF0aWMgdm9pZCBzaXpl X2NvbHNfdHJlZSAoc3RydWN0IHJhZGl4X25vZGUgKnJuKTsNCitzdGF0aWMg dm9pZCBzaXplX2NvbHNfcnRlbnRyeSAoc3RydWN0IHJ0ZW50cnkgKnJ0KTsN CiBzdGF0aWMgdm9pZCBwX3RyZWUgKHN0cnVjdCByYWRpeF9ub2RlICopOw0K IHN0YXRpYyB2b2lkIHBfcnRub2RlICh2b2lkKTsNCiBzdGF0aWMgdm9pZCBu dHJlZXN0dWZmICh2b2lkKTsNCiBzdGF0aWMgdm9pZCBucF9ydGVudHJ5IChz dHJ1Y3QgcnRfbXNnaGRyICopOw0KIHN0YXRpYyB2b2lkIHBfc29ja2FkZHIg KHN0cnVjdCBzb2NrYWRkciAqLCBzdHJ1Y3Qgc29ja2FkZHIgKiwgaW50LCBp bnQpOw0KK3N0YXRpYyBjb25zdCBjaGFyICpmbXRfc29ja2FkZHIgKHN0cnVj dCBzb2NrYWRkciAqc2EsIHN0cnVjdCBzb2NrYWRkciAqbWFzaywNCisJCQkJ IGludCBmbGFncyk7DQogc3RhdGljIHZvaWQgcF9mbGFncyAoaW50LCBjaGFy ICopOw0KK3N0YXRpYyBjb25zdCBjaGFyICpmbXRfZmxhZ3MoaW50IGYpOw0K IHN0YXRpYyB2b2lkIHBfcnRlbnRyeSAoc3RydWN0IHJ0ZW50cnkgKik7DQog c3RhdGljIHVfbG9uZyBmb3JnZW1hc2sgKHVfbG9uZyk7DQogc3RhdGljIHZv aWQgZG9tYXNrIChjaGFyICosIHVfbG9uZywgdV9sb25nKTsNCkBAIC0xNjYs NiArMTcyLDcgQEANCiAJCQkJCXBfdHJlZShoZWFkLnJuaF90cmVldG9wKTsN CiAJCQkJfQ0KIAkJCX0gZWxzZSBpZiAoYWYgPT0gQUZfVU5TUEVDIHx8IGFm ID09IGkpIHsNCisJCQkJc2l6ZV9jb2xzKGksIGhlYWQucm5oX3RyZWV0b3Ap Ow0KIAkJCQlwcl9mYW1pbHkoaSk7DQogCQkJCWRvX3J0ZW50ID0gMTsNCiAJ CQkJcHJfcnRoZHIoaSk7DQpAQCAtMjI0LDE3ICsyMzEsMTM0IEBADQogDQog LyogY29sdW1uIHdpZHRoczsgZWFjaCBmb2xsb3dlZCBieSBvbmUgc3BhY2Ug Ki8NCiAjaWZuZGVmIElORVQ2DQotI2RlZmluZQlXSURfRFNUKGFmKSAJMTgJ Lyogd2lkdGggb2YgZGVzdGluYXRpb24gY29sdW1uICovDQotI2RlZmluZQlX SURfR1coYWYpCTE4CS8qIHdpZHRoIG9mIGdhdGV3YXkgY29sdW1uICovDQot I2RlZmluZQlXSURfSUYoYWYpCTYJLyogd2lkdGggb2YgbmV0aWYgY29sdW1u ICovDQorI2RlZmluZQlXSURfRFNUX0RFRkFVTFQoYWYpIAkxOAkvKiB3aWR0 aCBvZiBkZXN0aW5hdGlvbiBjb2x1bW4gKi8NCisjZGVmaW5lCVdJRF9HV19E RUZBVUxUKGFmKQkxOAkvKiB3aWR0aCBvZiBnYXRld2F5IGNvbHVtbiAqLw0K KyNkZWZpbmUJV0lEX0lGX0RFRkFVTFQoYWYpCTYJLyogd2lkdGggb2YgbmV0 aWYgY29sdW1uICovDQogI2Vsc2UNCi0jZGVmaW5lCVdJRF9EU1QoYWYpIFwN Ci0JKChhZikgPT0gQUZfSU5FVDYgPyAoV2ZsYWcgPyAzOSA6IChudW1lcmlj X2FkZHIgPyAzMzogMTgpKSA6IDE4KQ0KLSNkZWZpbmUJV0lEX0dXKGFmKSBc DQotCSgoYWYpID09IEFGX0lORVQ2ID8gKFdmbGFnID8gMzEgOiAobnVtZXJp Y19hZGRyID8gMjkgOiAxOCkpIDogMTgpDQotI2RlZmluZQlXSURfSUYoYWYp CSgoYWYpID09IEFGX0lORVQ2ID8gOCA6IDYpDQorI2RlZmluZQlXSURfRFNU X0RFRkFVTFQoYWYpIFwNCisJKChhZikgPT0gQUZfSU5FVDYgPyAobnVtZXJp Y19hZGRyID8gMzM6IDE4KSA6IDE4KQ0KKyNkZWZpbmUJV0lEX0dXX0RFRkFV TFQoYWYpIFwNCisJKChhZikgPT0gQUZfSU5FVDYgPyAobnVtZXJpY19hZGRy ID8gMjkgOiAxOCkgOiAxOCkNCisjZGVmaW5lCVdJRF9JRl9ERUZBVUxUKGFm KQkoKGFmKSA9PSBBRl9JTkVUNiA/IDggOiA2KQ0KICNlbmRpZiAvKklORVQ2 Ki8NCiANCitzdGF0aWMgaW50IHdpZF9kc3Q7DQorc3RhdGljIGludCB3aWRf Z3c7DQorc3RhdGljIGludCB3aWRfZmxhZ3M7DQorc3RhdGljIGludCB3aWRf cmVmczsNCitzdGF0aWMgaW50IHdpZF91c2U7DQorc3RhdGljIGludCB3aWRf bXR1Ow0KK3N0YXRpYyBpbnQgd2lkX2lmOw0KK3N0YXRpYyBpbnQgd2lkX2V4 cGlyZTsNCisNCitzdGF0aWMgdm9pZA0KK3NpemVfY29scyhpbnQgZWYsIHN0 cnVjdCByYWRpeF9ub2RlICpybikNCit7DQorCXdpZF9kc3QgPSBXSURfRFNU X0RFRkFVTFQoZWYpOw0KKwl3aWRfZ3cgPSBXSURfR1dfREVGQVVMVChlZik7 DQorCXdpZF9mbGFncyA9IDY7DQorCXdpZF9yZWZzID0gNjsNCisJd2lkX3Vz ZSA9IDg7DQorCXdpZF9tdHUgPSA2Ow0KKwl3aWRfaWYgPSBXSURfSUZfREVG QVVMVChlZik7DQorCXdpZF9leHBpcmUgPSA2Ow0KKw0KKwlpZiAoV2ZsYWcp DQorCQlzaXplX2NvbHNfdHJlZShybik7DQorfQ0KKw0KK3N0YXRpYyB2b2lk DQorc2l6ZV9jb2xzX3RyZWUoc3RydWN0IHJhZGl4X25vZGUgKnJuKQ0KK3sN CithZ2FpbjoNCisJa2dldChybiwgcm5vZGUpOw0KKwlpZiAocm5vZGUucm5f Yml0IDwgMCkgew0KKwkJaWYgKChybm9kZS5ybl9mbGFncyAmIFJORl9ST09U KSA9PSAwKSB7DQorCQkJa2dldChybiwgcnRlbnRyeSk7DQorCQkJc2l6ZV9j b2xzX3J0ZW50cnkoJnJ0ZW50cnkpOw0KKwkJfQ0KKwkJaWYgKChybiA9IHJu b2RlLnJuX2R1cGVka2V5KSkNCisJCQlnb3RvIGFnYWluOw0KKwl9IGVsc2Ug ew0KKwkJcm4gPSBybm9kZS5ybl9yaWdodDsNCisJCXNpemVfY29sc190cmVl KHJub2RlLnJuX2xlZnQpOw0KKwkJc2l6ZV9jb2xzX3RyZWUocm4pOw0KKwl9 DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQorc2l6ZV9jb2xzX3J0ZW50cnkoc3Ry dWN0IHJ0ZW50cnkgKnJ0KQ0KK3sNCisJc3RhdGljIHN0cnVjdCBpZm5ldCBp Zm5ldCwgKmxhc3RpZjsNCisJc3RydWN0IHJ0ZW50cnkgcGFyZW50Ow0KKwlz dGF0aWMgY2hhciBidWZmZXJbMTAwXTsNCisJY29uc3QgY2hhciAqYnA7DQor CXN0cnVjdCBzb2NrYWRkciAqc2E7DQorCXNhX3UgYWRkciwgbWFzazsNCisJ aW50IGxlbjsNCisNCisJLyoNCisJICogRG9uJ3QgcHJpbnQgcHJvdG9jb2wt Y2xvbmVkIHJvdXRlcyB1bmxlc3MgLWEuDQorCSAqLw0KKwlpZiAocnQtPnJ0 X2ZsYWdzICYgUlRGX1dBU0NMT05FRCAmJiAhYWZsYWcpIHsNCisJCWtnZXQo cnQtPnJ0X3BhcmVudCwgcGFyZW50KTsNCisJCWlmIChwYXJlbnQucnRfZmxh Z3MgJiBSVEZfUFJDTE9OSU5HKQ0KKwkJCXJldHVybjsNCisJfQ0KKw0KKwli emVybygmYWRkciwgc2l6ZW9mKGFkZHIpKTsNCisJaWYgKChzYSA9IGtnZXRz YShydF9rZXkocnQpKSkpDQorCQliY29weShzYSwgJmFkZHIsIHNhLT5zYV9s ZW4pOw0KKwliemVybygmbWFzaywgc2l6ZW9mKG1hc2spKTsNCisJaWYgKHJ0 X21hc2socnQpICYmIChzYSA9IGtnZXRzYShydF9tYXNrKHJ0KSkpKQ0KKwkJ YmNvcHkoc2EsICZtYXNrLCBzYS0+c2FfbGVuKTsNCisJYnAgPSBmbXRfc29j a2FkZHIoJmFkZHIudV9zYSwgJm1hc2sudV9zYSwgcnQtPnJ0X2ZsYWdzKTsN CisJbGVuID0gc3RybGVuKGJwKTsNCisJd2lkX2RzdCA9IE1BWChsZW4sIHdp ZF9kc3QpOw0KKw0KKwlicCA9IGZtdF9zb2NrYWRkcihrZ2V0c2EocnQtPnJ0 X2dhdGV3YXkpLCBOVUxMLCBSVEZfSE9TVCk7DQorCWxlbiA9IHN0cmxlbihi cCk7DQorCXdpZF9ndyA9IE1BWChsZW4sIHdpZF9ndyk7DQorDQorCWJwID0g Zm10X2ZsYWdzKHJ0LT5ydF9mbGFncyk7DQorCWxlbiA9IHN0cmxlbihicCk7 DQorCXdpZF9mbGFncyA9IE1BWChsZW4sIHdpZF9mbGFncyk7DQorDQorCWlm IChhZGRyLnVfc2Euc2FfZmFtaWx5ID09IEFGX0lORVQgfHwgV2ZsYWcpIHsN CisJCWxlbiA9IHNucHJpbnRmKGJ1ZmZlciwgc2l6ZW9mKGJ1ZmZlciksICIl bGQiLCBydC0+cnRfcmVmY250KTsNCisJCXdpZF9yZWZzID0gTUFYKGxlbiwg d2lkX3JlZnMpOw0KKwkJbGVuID0gc25wcmludGYoYnVmZmVyLCBzaXplb2Yo YnVmZmVyKSwgIiVsdSIsIHJ0LT5ydF91c2UpOw0KKwkJd2lkX3VzZSA9IE1B WChsZW4sIHdpZF91c2UpOw0KKwkJaWYgKFdmbGFnICYmIHJ0LT5ydF9ybXgu cm14X210dSAhPSAwKSB7DQorCQkJbGVuID0gc25wcmludGYoYnVmZmVyLCBz aXplb2YoYnVmZmVyKSwNCisJCQkJICAgICAgICIlbHUiLCBydC0+cnRfcm14 LnJteF9tdHUpOw0KKwkJCXdpZF9tdHUgPSBNQVgobGVuLCB3aWRfbXR1KTsN CisJCX0NCisJfQ0KKwlpZiAocnQtPnJ0X2lmcCkgew0KKwkJaWYgKHJ0LT5y dF9pZnAgIT0gbGFzdGlmKSB7DQorCQkJbGVuID0gc25wcmludGYoYnVmZmVy LCBzaXplb2YoYnVmZmVyKSwgIiVkIiwNCisJCQkJICAgICAgIGlmbmV0Lmlm X3VuaXQpOw0KKwkJCWtnZXQocnQtPnJ0X2lmcCwgaWZuZXQpOw0KKwkJCWty ZWFkKCh1X2xvbmcpaWZuZXQuaWZfbmFtZSwgYnVmZmVyLCBzaXplb2YoYnVm ZmVyKSk7DQorCQkJbGFzdGlmID0gcnQtPnJ0X2lmcDsNCisJCQlsZW4gKz0g c3RybGVuKGJ1ZmZlcik7DQorCQkJd2lkX2lmID0gTUFYKGxlbiwgd2lkX2lm KTsNCisJCX0NCisJCWlmIChydC0+cnRfcm14LnJteF9leHBpcmUpIHsNCisJ CQl0aW1lX3QgZXhwaXJlX3RpbWU7DQorDQorCQkJaWYgKChleHBpcmVfdGlt ZSA9DQorCQkJICAgIHJ0LT5ydF9ybXgucm14X2V4cGlyZSAtIHRpbWUoTlVM TCkpID4gMCkgew0KKwkJCQlzbnByaW50ZihidWZmZXIsIHNpemVvZihidWZm ZXIpLCAiJWQiLA0KKwkJCQkJIChpbnQpZXhwaXJlX3RpbWUpOw0KKwkJCQl3 aWRfZXhwaXJlID0gTUFYKGxlbiwgd2lkX2V4cGlyZSk7DQorCQkJfQ0KKwkJ fQ0KKwl9DQorfQ0KKw0KKw0KIC8qDQogICogUHJpbnQgaGVhZGVyIGZvciBy b3V0aW5nIHRhYmxlIGNvbHVtbnMuDQogICovDQpAQCAtMjQ0LDI0ICszNjgs MzUgQEANCiANCiAJaWYgKEFmbGFnKQ0KIAkJcHJpbnRmKCIlLTguOHMgIiwi QWRkcmVzcyIpOw0KLQlpZiAoYWYgPT0gQUZfSU5FVCB8fCBXZmxhZykNCi0J CWlmIChXZmxhZykNCi0JCQlwcmludGYoIiUtKi4qcyAlLSouKnMgJS02LjZz ICU2LjZzICU4LjhzICU2LjZzICUqLipzICU2c1xuIiwNCi0JCQkJV0lEX0RT VChhZiksIFdJRF9EU1QoYWYpLCAiRGVzdGluYXRpb24iLA0KLQkJCQlXSURf R1coYWYpLCBXSURfR1coYWYpLCAiR2F0ZXdheSIsDQotCQkJCSJGbGFncyIs ICJSZWZzIiwgIlVzZSIsICJNdHUiLA0KLQkJCQlXSURfSUYoYWYpLCBXSURf SUYoYWYpLCAiTmV0aWYiLCAiRXhwaXJlIik7DQotCQllbHNlDQotCQkJcHJp bnRmKCIlLSouKnMgJS0qLipzICUtNi42cyAlNi42cyAlOC44cyAlKi4qcyAl NnNcbiIsDQotCQkJCVdJRF9EU1QoYWYpLCBXSURfRFNUKGFmKSwgIkRlc3Rp bmF0aW9uIiwNCi0JCQkJV0lEX0dXKGFmKSwgV0lEX0dXKGFmKSwgIkdhdGV3 YXkiLA0KLQkJCQkiRmxhZ3MiLCAiUmVmcyIsICJVc2UiLA0KLQkJCQlXSURf SUYoYWYpLCBXSURfSUYoYWYpLCAiTmV0aWYiLCAiRXhwaXJlIik7DQotCWVs c2UNCi0JCXByaW50ZigiJS0qLipzICUtKi4qcyAlLTYuNnMgICU4LjhzICU2 c1xuIiwNCi0JCQlXSURfRFNUKGFmKSwgV0lEX0RTVChhZiksICJEZXN0aW5h dGlvbiIsDQotCQkJV0lEX0dXKGFmKSwgV0lEX0dXKGFmKSwgIkdhdGV3YXki LA0KLQkJCSJGbGFncyIsICJOZXRpZiIsICJFeHBpcmUiKTsNCisJaWYgKGFm ID09IEFGX0lORVQgfHwgV2ZsYWcpIHsNCisJCWlmIChXZmxhZykgew0KKwkJ CXByaW50ZigiJS0qLipzICUtKi4qcyAlLSouKnMgJSouKnMgJSouKnMgJSou KnMgJSouKnMgJSpzXG4iLA0KKwkJCQl3aWRfZHN0LAl3aWRfZHN0LAkiRGVz dGluYXRpb24iLA0KKwkJCQl3aWRfZ3csCQl3aWRfZ3csCQkiR2F0ZXdheSIs DQorCQkJCXdpZF9mbGFncywJd2lkX2ZsYWdzLAkiRmxhZ3MiLA0KKwkJCQl3 aWRfcmVmcywJd2lkX3JlZnMsCSJSZWZzIiwNCisJCQkJd2lkX3VzZSwJd2lk X3VzZSwJIlVzZSIsDQorCQkJCXdpZF9tdHUsCXdpZF9tdHUsCSJNdHUiLA0K KwkJCQl3aWRfaWYsCQl3aWRfaWYsCQkiTmV0aWYiLA0KKwkJCQl3aWRfZXhw aXJlLAkJCSJFeHBpcmUiKTsNCisJCX0gZWxzZSB7DQorCQkJcHJpbnRmKCIl LSouKnMgJS0qLipzICUtKi4qcyAlKi4qcyAlKi4qcyAlKi4qcyAlKnNcbiIs DQorCQkJCXdpZF9kc3QsCXdpZF9kc3QsCSJEZXN0aW5hdGlvbiIsDQorCQkJ CXdpZF9ndywJCXdpZF9ndywJCSJHYXRld2F5IiwNCisJCQkJd2lkX2ZsYWdz LAl3aWRfZmxhZ3MsCSJGbGFncyIsDQorCQkJCXdpZF9yZWZzLAl3aWRfcmVm cywJIlJlZnMiLA0KKwkJCQl3aWRfdXNlLAl3aWRfdXNlLAkiVXNlIiwNCisJ CQkJd2lkX2lmLAkJd2lkX2lmLAkJIk5ldGlmIiwNCisJCQkJd2lkX2V4cGly ZSwJCQkiRXhwaXJlIik7DQorCQl9DQorCX0gZWxzZSB7DQorCQlwcmludGYo IiUtKi4qcyAlLSouKnMgJS0qLipzICAlKi4qcyAlKnNcbiIsDQorCQkJd2lk X2RzdCwJd2lkX2RzdCwJIkRlc3RpbmF0aW9uIiwNCisJCQl3aWRfZ3csCQl3 aWRfZ3csCQkiR2F0ZXdheSIsDQorCQkJd2lkX2ZsYWdzLAl3aWRfZmxhZ3Ms CSJGbGFncyIsDQorCQkJd2lkX2lmLAkJd2lkX2lmLAkJIk5ldGlmIiwNCisJ CQl3aWRfZXhwaXJlLAkJCSJFeHBpcmUiKTsNCisJfQ0KIH0NCiANCiBzdGF0 aWMgc3RydWN0IHNvY2thZGRyICoNCkBAIC00MjIsOCArNTU3LDI2IEBADQog c3RhdGljIHZvaWQNCiBwX3NvY2thZGRyKHN0cnVjdCBzb2NrYWRkciAqc2Es IHN0cnVjdCBzb2NrYWRkciAqbWFzaywgaW50IGZsYWdzLCBpbnQgd2lkdGgp DQogew0KLQljaGFyIHdvcmtidWZbMTI4XSwgKmNwbGltOw0KLQlyZWdpc3Rl ciBjaGFyICpjcCA9IHdvcmtidWY7DQorCWNvbnN0IGNoYXIgKmNwOw0KKw0K KwljcCA9IGZtdF9zb2NrYWRkcihzYSwgbWFzaywgZmxhZ3MpOw0KKw0KKwlp ZiAod2lkdGggPCAwICkNCisJCXByaW50ZigiJXMgIiwgY3ApOw0KKwllbHNl IHsNCisJCWlmIChudW1lcmljX2FkZHIpDQorCQkJcHJpbnRmKCIlLSpzICIs IHdpZHRoLCBjcCk7DQorCQllbHNlDQorCQkJcHJpbnRmKCIlLSouKnMgIiwg d2lkdGgsIHdpZHRoLCBjcCk7DQorCX0NCit9DQorDQorc3RhdGljIGNvbnN0 IGNoYXIgKg0KK2ZtdF9zb2NrYWRkcihzdHJ1Y3Qgc29ja2FkZHIgKnNhLCBz dHJ1Y3Qgc29ja2FkZHIgKm1hc2ssIGludCBmbGFncykNCit7DQorCXN0YXRp YyBjaGFyIHdvcmtidWZbMTI4XTsNCisJY2hhciAqY3BsaW07DQorCWNoYXIg KmNwID0gd29ya2J1ZjsNCiANCiAJc3dpdGNoKHNhLT5zYV9mYW1pbHkpIHsN CiAJY2FzZSBBRl9JTkVUOg0KQEAgLTU0MiwyNyArNjk1LDI4IEBADQogCQlj cCA9IHdvcmtidWY7DQogCSAgICB9DQogCX0NCi0JaWYgKHdpZHRoIDwgMCAp DQotCQlwcmludGYoIiVzICIsIGNwKTsNCi0JZWxzZSB7DQotCQlpZiAobnVt ZXJpY19hZGRyKQ0KLQkJCXByaW50ZigiJS0qcyAiLCB3aWR0aCwgY3ApOw0K LQkJZWxzZQ0KLQkJCXByaW50ZigiJS0qLipzICIsIHdpZHRoLCB3aWR0aCwg Y3ApOw0KLQl9DQorDQorCXJldHVybiAoY3ApOw0KIH0NCiANCiBzdGF0aWMg dm9pZA0KIHBfZmxhZ3MoaW50IGYsIGNoYXIgKmZvcm1hdCkNCiB7DQotCWNo YXIgbmFtZVszM10sICpmbGFnczsNCi0JcmVnaXN0ZXIgc3RydWN0IGJpdHMg KnAgPSBiaXRzOw0KKwlwcmludGYoZm9ybWF0LCBmbXRfZmxhZ3MoZikpOw0K K30NCisNCitzdGF0aWMgY29uc3QgY2hhciAqDQorZm10X2ZsYWdzKGludCBm KQ0KK3sNCisJc3RhdGljIGNoYXIgbmFtZVszM107DQorCWNoYXIgKmZsYWdz Ow0KKwlzdHJ1Y3QgYml0cyAqcCA9IGJpdHM7DQogDQogCWZvciAoZmxhZ3Mg PSBuYW1lOyBwLT5iX21hc2s7IHArKykNCiAJCWlmIChwLT5iX21hc2sgJiBm KQ0KIAkJCSpmbGFncysrID0gcC0+Yl92YWw7DQogCSpmbGFncyA9ICdcMCc7 DQotCXByaW50Zihmb3JtYXQsIG5hbWUpOw0KKwlyZXR1cm4gKG5hbWUpOw0K IH0NCiANCiBzdGF0aWMgdm9pZA0KQEAgLTU3MCw4ICs3MjQsOCBAQA0KIHsN CiAJc3RhdGljIHN0cnVjdCBpZm5ldCBpZm5ldCwgKmxhc3RpZjsNCiAJc3Ry dWN0IHJ0ZW50cnkgcGFyZW50Ow0KLQlzdGF0aWMgY2hhciBuYW1lWzE2XTsN Ci0Jc3RhdGljIGNoYXIgcHJldHR5bmFtZVs5XTsNCisJc3RhdGljIGNoYXIg YnVmZmVyWzEyOF07DQorCXN0YXRpYyBjaGFyIHByZXR0eW5hbWVbMTI4XTsN CiAJc3RydWN0IHNvY2thZGRyICpzYTsNCiAJc2FfdSBhZGRyLCBtYXNrOw0K IA0KQEAgLTU5MCwzNiArNzQ0LDM1IEBADQogCWJ6ZXJvKCZtYXNrLCBzaXpl b2YobWFzaykpOw0KIAlpZiAocnRfbWFzayhydCkgJiYgKHNhID0ga2dldHNh KHJ0X21hc2socnQpKSkpDQogCQliY29weShzYSwgJm1hc2ssIHNhLT5zYV9s ZW4pOw0KLQlwX3NvY2thZGRyKCZhZGRyLnVfc2EsICZtYXNrLnVfc2EsIHJ0 LT5ydF9mbGFncywNCi0JICAgIFdJRF9EU1QoYWRkci51X3NhLnNhX2ZhbWls eSkpOw0KLQlwX3NvY2thZGRyKGtnZXRzYShydC0+cnRfZ2F0ZXdheSksIE5V TEwsIFJURl9IT1NULA0KLQkgICAgV0lEX0dXKGFkZHIudV9zYS5zYV9mYW1p bHkpKTsNCi0JcF9mbGFncyhydC0+cnRfZmxhZ3MsICIlLTYuNnMgIik7DQor CXBfc29ja2FkZHIoJmFkZHIudV9zYSwgJm1hc2sudV9zYSwgcnQtPnJ0X2Zs YWdzLCB3aWRfZHN0KTsNCisJcF9zb2NrYWRkcihrZ2V0c2EocnQtPnJ0X2dh dGV3YXkpLCBOVUxMLCBSVEZfSE9TVCwgd2lkX2d3KTsNCisJc25wcmludGYo YnVmZmVyLCBzaXplb2YoYnVmZmVyKSwgIiUlLSVkLiVkcyAiLCB3aWRfZmxh Z3MsIHdpZF9mbGFncyk7DQorCXBfZmxhZ3MocnQtPnJ0X2ZsYWdzLCBidWZm ZXIpOw0KIAlpZiAoYWRkci51X3NhLnNhX2ZhbWlseSA9PSBBRl9JTkVUIHx8 IFdmbGFnKSB7DQotCQlwcmludGYoIiU2bGQgJThsdSAiLCBydC0+cnRfcmVm Y250LCBydC0+cnRfdXNlKTsNCisJCXByaW50ZigiJSpsZCAlKmx1ICIsIHdp ZF9yZWZzLCBydC0+cnRfcmVmY250LA0KKwkJCQkgICAgIHdpZF91c2UsIHJ0 LT5ydF91c2UpOw0KIAkJaWYgKFdmbGFnKSB7DQogCQkJaWYgKHJ0LT5ydF9y bXgucm14X210dSAhPSAwKQ0KLQkJCQlwcmludGYoIiU2bHUgIiwgcnQtPnJ0 X3JteC5ybXhfbXR1KTsNCisJCQkJcHJpbnRmKCIlKmx1ICIsIHdpZF9tdHUs IHJ0LT5ydF9ybXgucm14X210dSk7DQogCQkJZWxzZQ0KLQkJCQlwcmludGYo IiU2cyAiLCAiIik7DQorCQkJCXByaW50ZigiJSpzICIsIHdpZF9tdHUsICIi KTsNCiAJCX0NCiAJfQ0KIAlpZiAocnQtPnJ0X2lmcCkgew0KIAkJaWYgKHJ0 LT5ydF9pZnAgIT0gbGFzdGlmKSB7DQogCQkJa2dldChydC0+cnRfaWZwLCBp Zm5ldCk7DQotCQkJa3JlYWQoKHVfbG9uZylpZm5ldC5pZl9uYW1lLCBuYW1l LCAxNik7DQorCQkJa3JlYWQoKHVfbG9uZylpZm5ldC5pZl9uYW1lLCBidWZm ZXIsIHNpemVvZihidWZmZXIpKTsNCiAJCQlsYXN0aWYgPSBydC0+cnRfaWZw Ow0KLQkJCXNucHJpbnRmKHByZXR0eW5hbWUsIHNpemVvZiBwcmV0dHluYW1l LA0KLQkJCQkgIiVzJWQiLCBuYW1lLCBpZm5ldC5pZl91bml0KTsNCisJCQlz bnByaW50ZihwcmV0dHluYW1lLCBzaXplb2YocHJldHR5bmFtZSksDQorCQkJ CSAiJXMlZCIsIGJ1ZmZlciwgaWZuZXQuaWZfdW5pdCk7DQogCQl9DQotCQlw cmludGYoIiUqLipzIiwgV0lEX0lGKGFkZHIudV9zYS5zYV9mYW1pbHkpLA0K LQkJICAgIFdJRF9JRihhZGRyLnVfc2Euc2FfZmFtaWx5KSwgcHJldHR5bmFt ZSk7DQorCQlwcmludGYoIiUqLipzIiwgd2lkX2lmLCB3aWRfaWYsIHByZXR0 eW5hbWUpOw0KIAkJaWYgKHJ0LT5ydF9ybXgucm14X2V4cGlyZSkgew0KIAkJ CXRpbWVfdCBleHBpcmVfdGltZTsNCiANCiAJCQlpZiAoKGV4cGlyZV90aW1l ID0NCiAJCQkgICAgcnQtPnJ0X3JteC5ybXhfZXhwaXJlIC0gdGltZSgodGlt ZV90ICopMCkpID4gMCkNCi0JCQkJcHJpbnRmKCIgJTZkIiwgKGludClleHBp cmVfdGltZSk7DQorCQkJCXByaW50ZigiICUqZCIsIHdpZF9leHBpcmUsIChp bnQpZXhwaXJlX3RpbWUpOw0KIAkJfQ0KIAkJaWYgKHJ0LT5ydF9ub2Rlc1sw XS5ybl9kdXBlZGtleSkNCiAJCQlwcmludGYoIiA9PiIpOw0K --0-1401783618-1023163088=:33228-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 3 23: 0:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4EB6137B405 for ; Mon, 3 Jun 2002 23:00:06 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA83758; Mon, 3 Jun 2002 22:54:40 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g545rXH49446; Mon, 3 Jun 2002 22:53:33 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206040553.g545rXH49446@arch20m.dellroad.org> Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <20020603193651.A29296@unixdaemons.com> "from Bosko Milekic at Jun 3, 2002 07:36:51 pm" To: Bosko Milekic Date: Mon, 3 Jun 2002 22:53:33 -0700 (PDT) Cc: Archie Cobbs , Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Bosko Milekic writes: > > > Secondly, this may not be as much of a problem as you may think. > > > Particularly if you consider the m_split() case, for example. For > > > example, if you're calling m_split() on an mbuf chain that may refer > > > to cluster(s) where none of the clusters has a ref. count greater than > > > 1 -- which is usually the case anyway -- then this is fine; since you > > > have posession of the chain referring to those clusters, and > > > presumably the chain isn't sitting in some queue somewhere (if it is, > > > you'd have to be under the protection of that queue anyway - splimp() > > > or whatever), then you're the only one who has posession of that > > > > The *chain* won't be sitting in a queue, but there may be a different > > mbuf in a queue somehwere that points to the same cluster. > > I did say "if the refcount is exactly 1" !!!! (which is often the > case in there). Oops, sorry.. right, if the ref count is one there can be no race. > > Since mid-level code only increments the ref count, I think the > > worst that can happen is the ref count is incorrectly too high, > > which could only cause a memory leak rather than a crash. > > No, the worse case is that it is too low. > > increment: > > read > inc > write > > two increments, unprotected: Yes, you are right.. I was thinking that mbuf's were only free'd in interrupt handlers rather than allocated. If they are also allocated then the double-free race happens. We cannot assume that they aren't so this is indeed a more serious, if rare, bug. Re: the -stable patch. I agree we need a more general MFC/cleanup of some of the mbuf improvements from -current into -stable. If I find time perhaps I'll do that as well, but in a separate patch. For the present time, I'll commit this once 4.6-REL is done. Thanks for your comments. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 0: 1:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6E8AF37B400 for ; Tue, 4 Jun 2002 00:01:31 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g5470re85036; Tue, 4 Jun 2002 10:00:53 +0300 (EEST) (envelope-from ru) Date: Tue, 4 Jun 2002 10:00:53 +0300 From: Ruslan Ermilov To: Andre Oppermann , Garrett Wollman Cc: net@FreeBSD.org Subject: Re: Bug in net/route.c function rtredirect() Message-ID: <20020604070053.GA83399@sunbay.com> References: <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> <200206032237.g53Mb0h1018954@khavrinen.lcs.mit.edu> <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <200206032237.g53Mb0h1018954@khavrinen.lcs.mit.edu> <3CFBE83F.3E7025A4@pipeline.ch> 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 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2002 at 12:05:51AM +0200, Andre Oppermann wrote: > Ruslan Ermilov wrote: > >=20 > > On Sat, Jun 01, 2002 at 12:49:51PM +0200, Andre Oppermann wrote: > > > You're right but the refcount decrementation will be done, just in a > > > different place. In the "done:" section the rtfree() will be done also > > > in the case when an existing host route was already present. > > > > > No it won't be done in "done:", because a few lines later we assign > > rt =3D NULL: > >=20 > > create: > > if (rt) > > rt->rt_refcnt--; > > flags |=3D RTF_GATEWAY | RTF_DYNAMIC; > > bzero((caddr_t)&info, sizeof(info)); > > info.rti_info[RTAX_DST] =3D dst; > > info.rti_info[RTAX_GATEWAY] =3D gateway; > > info.rti_info[RTAX_NETMASK] =3D netmask; > > info.rti_ifa =3D ifa; > > info.rti_flags =3D flags; > > rt =3D NULL; > >=20 > > > > > The solution is to remove the rtfree() in rtredirect. Diff against > > > > > -STABLE is attached. Should apply to -CURRENT with some fuzz. > > > > > > > > > No, please try the below patch instead. > > > > > > The rtfree() I removed is one too many and still has to go. Your patch > > > doesn't change the problem, it just makes it different. Routes could > > > go below zero refcount in your version. > > > > > The second rt->rt_refcnt-- I added is indeed unnecessary, you're > > right here. >=20 > After reading this whole redirect stuff a couple of time I've come to > the conclusion that the function is right as it is there. There is no > such bug as I described it. The rtalloc1() in rtredirect() is incre- > menting the refcount on the route found, the two rtfree() after > "create:" and "done:" will decrement it as it is must happen (we don't > have a reference to that route because we don't clone here). >=20 Right. There's just no point in calling rtfree() just to decrement the route's rt_refcnt (we were only looking up the route, we didn't need a reference to it). rtfree() does not free the route because it's still RTF_UP, and calling rtfree() also needlessly calls rnh_close() (in_clsroute() in the PF_INET case). Hence this would still be a slight optimization (tested this time): %%% Index: net/route.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.69 diff -u -p -r1.69 route.c --- net/route.c 19 Mar 2002 21:54:18 -0000 1.69 +++ net/route.c 4 Jun 2002 06:41:42 -0000 @@ -345,7 +345,7 @@ rtredirect(dst, gateway, netmask, flags, */ create: if (rt) - rtfree(rt); + rt->rt_refcnt--; flags |=3D RTF_GATEWAY | RTF_DYNAMIC; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] =3D dst; %%% > A bug is that host routes created by redirect are never being purged. > But that one has been present for a long (?) time. >=20 > I'm still try to track a problem with the following situation: 1. I > get a tcp syn from somewhere, 2. a host route is created by tcp, 3. > the synack is sent back, 4. we get a redirect from the router to use > a different router, 5. host route created from tcp is updated and > replaced by icmp redirect route, 6. I see a RTM_LOSING message and > the redirect route is being purged. >=20 This is handled by in_losing(). in_losing() has all the necessary comments explaining what's going on here. > This happens in, I think, some 5% of the cases. What I'm tracking > is why the rtfree() after "create:" is de-refcounting the default > route when we should have updated the host route created by tcp > before. Maybe this is a side-effect of the tcp syncache and the > flow has changed? I'll track what happens there. >=20 There may be only one reason: there's no (yet) route created by tcp. I can't reproduce it here. > > Heh, so you in fact tried to rtfree() "rt" in "done:" by adding > > "rtn". And how *rtp (if rtp !=3D NULL) will become "rtn" then? > > What about this? >=20 > No. No bug as I said, no need to patch. Sorry for this touble. >=20 > For the expiration of redirects I'll port/adapt the NetBSD solution > and post the patch here. >=20 We could treat RTF_DYNAMIC routes just like RTF_WASCLONED ones. Seems to work just fine here: %%% Index: netinet/in_rmx.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v retrieving revision 1.42 diff -u -p -r1.42 in_rmx.c --- netinet/in_rmx.c 19 Mar 2002 21:25:46 -0000 1.42 +++ netinet/in_rmx.c 4 Jun 2002 06:41:42 -0000 @@ -202,8 +202,10 @@ in_clsroute(struct radix_node *rn, struc if((rt->rt_flags & (RTF_LLINFO | RTF_HOST)) !=3D RTF_HOST) return; =20 - if((rt->rt_flags & (RTF_WASCLONED | RTPRF_OURS)) - !=3D RTF_WASCLONED) + if((rt->rt_flags & RTPRF_OURS) !=3D 0) + return; + + if((rt->rt_flags & (RTF_WASCLONED | RTF_DYNAMIC)) =3D=3D 0) return; =20 /* %%% On Mon, Jun 03, 2002 at 06:37:00PM -0400, Garrett Wollman wrote: > < said: >=20 > > A bug is that host routes created by redirect are never being purged. > > But that one has been present for a long (?) time. >=20 > You are expected to be running a routing process (like `routed' in > router-discovery mode) which will delete them for you. I agree that > this is not a reasonable expectation, but that was the design intent. >=20 I think there's nothing wrong if dynamically created routes (by redirect) will be treated as "temporary" routes, just like protocol-cloned routes. The above patch for in_rmx.c implements this. Let me know what do you think. 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 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE8/GWkUkv4P6juNwoRAildAJ9D3/LSc2AZNpbRv/l21U8JU3B/fwCdEnIi GDg0ZpO+rYY3DaS0bWg7jfA= =bIb9 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 1:26:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 3AE0D37B401 for ; Tue, 4 Jun 2002 01:26:07 -0700 (PDT) Received: (qmail 47874 invoked from network); 4 Jun 2002 08:25:41 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Jun 2002 08:25:41 -0000 Message-ID: <3CFC7951.57285201@pipeline.ch> Date: Tue, 04 Jun 2002 10:24:49 +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: Garrett Wollman , net@FreeBSD.org Subject: Re: Bug in net/route.c function rtredirect() References: <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> <200206032237.g53Mb0h1018954@khavrinen.lcs.mit.edu> <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> <20020604070053.GA83399@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: > > On Tue, Jun 04, 2002 at 12:05:51AM +0200, Andre Oppermann wrote: > > After reading this whole redirect stuff a couple of time I've come to > > the conclusion that the function is right as it is there. There is no > > such bug as I described it. The rtalloc1() in rtredirect() is incre- > > menting the refcount on the route found, the two rtfree() after > > "create:" and "done:" will decrement it as it is must happen (we don't > > have a reference to that route because we don't clone here). > > > Right. There's just no point in calling rtfree() just to decrement > the route's rt_refcnt (we were only looking up the route, we didn't > need a reference to it). rtfree() does not free the route because > it's still RTF_UP, and calling rtfree() also needlessly calls > rnh_close() (in_clsroute() in the PF_INET case). Hence this would > still be a slight optimization (tested this time): This breaks if someone hacks up the routing table. The vast majority is using rtfree() (actually the RTFREE macro which checks ==0 first). To be entirely correct and clean the macro RTFREE would be the right thing to do here. > %%% > Index: net/route.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/route.c,v > retrieving revision 1.69 > diff -u -p -r1.69 route.c > --- net/route.c 19 Mar 2002 21:54:18 -0000 1.69 > +++ net/route.c 4 Jun 2002 06:41:42 -0000 > @@ -345,7 +345,7 @@ rtredirect(dst, gateway, netmask, flags, > */ > create: > if (rt) > - rtfree(rt); > + rt->rt_refcnt--; > flags |= RTF_GATEWAY | RTF_DYNAMIC; > bzero((caddr_t)&info, sizeof(info)); > info.rti_info[RTAX_DST] = dst; > %%% > > > A bug is that host routes created by redirect are never being purged. > > But that one has been present for a long (?) time. > > > > I'm still try to track a problem with the following situation: 1. I > > get a tcp syn from somewhere, 2. a host route is created by tcp, 3. > > the synack is sent back, 4. we get a redirect from the router to use > > a different router, 5. host route created from tcp is updated and > > replaced by icmp redirect route, 6. I see a RTM_LOSING message and > > the redirect route is being purged. > > > This is handled by in_losing(). in_losing() has all the necessary > comments explaining what's going on here. Yes, I see what and why in_losing() is doing it. What I'm wondering is why are the packets lost so in_losing() is being triggered. In my net- work such packet loss is not supposed to happen. Otherwise I could only imagine getting a bugus redirect. That would be a problem on the router (which is also FreeBSD based). Anyway, I'll investigate my problem here further and see where that takes me... > > This happens in, I think, some 5% of the cases. What I'm tracking > > is why the rtfree() after "create:" is de-refcounting the default > > route when we should have updated the host route created by tcp > > before. Maybe this is a side-effect of the tcp syncache and the > > flow has changed? I'll track what happens there. > > > There may be only one reason: there's no (yet) route created by tcp. > I can't reproduce it here. In tcp_input.c is a route lookup (via tcp_rtlookup) in the function tcp_mssopt(). tcp_mssopt is supposed to look up the outgoing inter- face to find out the MSS this host supports. tcp_rtlookup rtalloc's a route and clones it if neccessary. This is before any redirect can happen because it's before we've sent out the packet which triggers the redirect. syncache_respond is doing the same. So there should be a route existing prior to the redirect?! (UDP is not doing this, it does not request a host route but simply takes whichever routes matches, usually default route). > > > Heh, so you in fact tried to rtfree() "rt" in "done:" by adding > > > "rtn". And how *rtp (if rtp != NULL) will become "rtn" then? > > > What about this? > > > > No. No bug as I said, no need to patch. Sorry for this touble. > > > > For the expiration of redirects I'll port/adapt the NetBSD solution > > and post the patch here. > > > We could treat RTF_DYNAMIC routes just like RTF_WASCLONED ones. > Seems to work just fine here: Ah, an even smarter solution! I'll try this on my box this evening! > %%% > Index: netinet/in_rmx.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v > retrieving revision 1.42 > diff -u -p -r1.42 in_rmx.c > --- netinet/in_rmx.c 19 Mar 2002 21:25:46 -0000 1.42 > +++ netinet/in_rmx.c 4 Jun 2002 06:41:42 -0000 > @@ -202,8 +202,10 @@ in_clsroute(struct radix_node *rn, struc > if((rt->rt_flags & (RTF_LLINFO | RTF_HOST)) != RTF_HOST) > return; > > - if((rt->rt_flags & (RTF_WASCLONED | RTPRF_OURS)) > - != RTF_WASCLONED) > + if((rt->rt_flags & RTPRF_OURS) != 0) > + return; > + > + if((rt->rt_flags & (RTF_WASCLONED | RTF_DYNAMIC)) == 0) > return; > > /* > %%% > > On Mon, Jun 03, 2002 at 06:37:00PM -0400, Garrett Wollman wrote: > > < said: > > > > > A bug is that host routes created by redirect are never being purged. > > > But that one has been present for a long (?) time. > > > > You are expected to be running a routing process (like `routed' in > > router-discovery mode) which will delete them for you. I agree that > > this is not a reasonable expectation, but that was the design intent. > > > I think there's nothing wrong if dynamically created routes (by redirect) > will be treated as "temporary" routes, just like protocol-cloned routes. > The above patch for in_rmx.c implements this. Let me know what do you > think. /me thinks this is fine. This reminds of a problem I had in August 2001 with the .CH secondary nameserver ccTLD.tix.ch where I've got more than 303'000 redirects in the routing table. The thread was named "303,000 routes in kernel". Thankfully the network code is quite robust and didn't fall over when it could no longer allocate memory for new routes. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 1:45:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 4524337B408 for ; Tue, 4 Jun 2002 01:44:48 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g548hXp96791; Tue, 4 Jun 2002 11:43:33 +0300 (EEST) (envelope-from ru) Date: Tue, 4 Jun 2002 11:43:33 +0300 From: Ruslan Ermilov To: Andre Oppermann Cc: Garrett Wollman , net@FreeBSD.org Subject: Re: Bug in net/route.c function rtredirect() Message-ID: <20020604084333.GA95488@sunbay.com> References: <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> <200206032237.g53Mb0h1018954@khavrinen.lcs.mit.edu> <3CF81BC5.EAF0ACC@pipeline.ch> <20020601095707.GC50435@sunbay.com> <3CF8A6CF.6033679A@pipeline.ch> <20020602125310.GD58857@sunbay.com> <3CFBE83F.3E7025A4@pipeline.ch> <20020604070053.GA83399@sunbay.com> <3CFC7951.57285201@pipeline.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <3CFC7951.57285201@pipeline.ch> 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 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2002 at 10:24:49AM +0200, Andre Oppermann wrote: > Ruslan Ermilov wrote: > >=20 > > On Tue, Jun 04, 2002 at 12:05:51AM +0200, Andre Oppermann wrote: > > > After reading this whole redirect stuff a couple of time I've come to > > > the conclusion that the function is right as it is there. There is no > > > such bug as I described it. The rtalloc1() in rtredirect() is incre- > > > menting the refcount on the route found, the two rtfree() after > > > "create:" and "done:" will decrement it as it is must happen (we don't > > > have a reference to that route because we don't clone here). > > > > > Right. There's just no point in calling rtfree() just to decrement > > the route's rt_refcnt (we were only looking up the route, we didn't > > need a reference to it). rtfree() does not free the route because > > it's still RTF_UP, and calling rtfree() also needlessly calls > > rnh_close() (in_clsroute() in the PF_INET case). Hence this would > > still be a slight optimization (tested this time): >=20 > This breaks if someone hacks up the routing table. >=20 What do you mean by "hacks"? > The vast majority > is using rtfree() (actually the RTFREE macro which checks =3D=3D0 first). > To be entirely correct and clean the macro RTFREE would be the right > thing to do here. >=20 Well, rtinit() does the same decrementing. > > %%% > > Index: net/route.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /home/ncvs/src/sys/net/route.c,v > > retrieving revision 1.69 > > diff -u -p -r1.69 route.c > > --- net/route.c 19 Mar 2002 21:54:18 -0000 1.69 > > +++ net/route.c 4 Jun 2002 06:41:42 -0000 > > @@ -345,7 +345,7 @@ rtredirect(dst, gateway, netmask, flags, > > */ > > create: > > if (rt) > > - rtfree(rt); > > + rt->rt_refcnt--; > > flags |=3D RTF_GATEWAY | RTF_DYNAMIC; > > bzero((caddr_t)&info, sizeof(info)); > > info.rti_info[RTAX_DST] =3D dst; > > %%% > >=20 > > > A bug is that host routes created by redirect are never being purged. > > > But that one has been present for a long (?) time. > > > > > > I'm still try to track a problem with the following situation: 1. I > > > get a tcp syn from somewhere, 2. a host route is created by tcp, 3. > > > the synack is sent back, 4. we get a redirect from the router to use > > > a different router, 5. host route created from tcp is updated and > > > replaced by icmp redirect route, 6. I see a RTM_LOSING message and > > > the redirect route is being purged. > > > > > This is handled by in_losing(). in_losing() has all the necessary > > comments explaining what's going on here. >=20 > Yes, I see what and why in_losing() is doing it. What I'm wondering is > why are the packets lost so in_losing() is being triggered. In my net- > work such packet loss is not supposed to happen. Otherwise I could only > imagine getting a bugus redirect. That would be a problem on the router > (which is also FreeBSD based). Anyway, I'll investigate my problem here > further and see where that takes me... >=20 OK, you're the best person to try realize that. :-) > > > This happens in, I think, some 5% of the cases. What I'm tracking > > > is why the rtfree() after "create:" is de-refcounting the default > > > route when we should have updated the host route created by tcp > > > before. Maybe this is a side-effect of the tcp syncache and the > > > flow has changed? I'll track what happens there. > > > > > There may be only one reason: there's no (yet) route created by tcp. > > I can't reproduce it here. >=20 > In tcp_input.c is a route lookup (via tcp_rtlookup) in the function > tcp_mssopt(). tcp_mssopt is supposed to look up the outgoing inter- > face to find out the MSS this host supports. tcp_rtlookup rtalloc's > a route and clones it if neccessary. This is before any redirect can > happen because it's before we've sent out the packet which triggers > the redirect. syncache_respond is doing the same. So there should be > a route existing prior to the redirect?! >=20 This TCP-cloned route is only installed after a connection is established. There's the packet flow taking place before it is established. Could it be that you're seeing these RTM_LOOSING during the connection establishment phase? What does tcpdump(1) show you? What does ``route -vn monitor'' tell you? > (UDP is not doing this, it does not request a host route but simply > takes whichever routes matches, usually default route). >=20 I know, there's no per-destination metrics for UDP. :-) > > > > Heh, so you in fact tried to rtfree() "rt" in "done:" by adding > > > > "rtn". And how *rtp (if rtp !=3D NULL) will become "rtn" then? > > > > What about this? > > > > > > No. No bug as I said, no need to patch. Sorry for this touble. > > > > > > For the expiration of redirects I'll port/adapt the NetBSD solution > > > and post the patch here. > > > > > We could treat RTF_DYNAMIC routes just like RTF_WASCLONED ones. > > Seems to work just fine here: >=20 > Ah, an even smarter solution! I'll try this on my box this evening! >=20 OK, I will also wait for what others think about it. > > %%% > > Index: netinet/in_rmx.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v > > retrieving revision 1.42 > > diff -u -p -r1.42 in_rmx.c > > --- netinet/in_rmx.c 19 Mar 2002 21:25:46 -0000 1.42 > > +++ netinet/in_rmx.c 4 Jun 2002 06:41:42 -0000 > > @@ -202,8 +202,10 @@ in_clsroute(struct radix_node *rn, struc > > if((rt->rt_flags & (RTF_LLINFO | RTF_HOST)) !=3D RTF_HOST) > > return; > >=20 > > - if((rt->rt_flags & (RTF_WASCLONED | RTPRF_OURS)) > > - !=3D RTF_WASCLONED) > > + if((rt->rt_flags & RTPRF_OURS) !=3D 0) > > + return; > > + > > + if((rt->rt_flags & (RTF_WASCLONED | RTF_DYNAMIC)) =3D=3D 0) > > return; > >=20 > > /* > > %%% > >=20 > > On Mon, Jun 03, 2002 at 06:37:00PM -0400, Garrett Wollman wrote: > > > < said: > > > > > > > A bug is that host routes created by redirect are never being purge= d. > > > > But that one has been present for a long (?) time. > > > > > > You are expected to be running a routing process (like `routed' in > > > router-discovery mode) which will delete them for you. I agree that > > > this is not a reasonable expectation, but that was the design intent. > > > > > I think there's nothing wrong if dynamically created routes (by redirec= t) > > will be treated as "temporary" routes, just like protocol-cloned routes. > > The above patch for in_rmx.c implements this. Let me know what do you > > think. >=20 > /me thinks this is fine. This reminds of a problem I had in August 2001 > with the .CH secondary nameserver ccTLD.tix.ch where I've got more than > 303'000 redirects in the routing table. The thread was named "303,000 > routes in kernel". Thankfully the network code is quite robust and > didn't fall over when it could no longer allocate memory for new routes. >=20 And if you think about it, dynamically learned routes are just another way of "cloning". Your host learns them from a remote gateway, and that gateway's configuration may change as time goes by, and this route would become stale. 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 --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE8/H21Ukv4P6juNwoRApXsAJ9wZRT5DK3CdYaLBRPsR619k+dKiwCdEFDq 9n4gZ+nM3QD5hZ39OIHrdpo= =mXdq -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 5:55: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from raider.datacom.kiev.ua (ns.datacom.kiev.ua [80.91.160.2]) by hub.freebsd.org (Postfix) with ESMTP id 5152237B400 for ; Tue, 4 Jun 2002 05:54:58 -0700 (PDT) Received: from blend.fc.kiev.ua (fc-data.datacom.kiev.ua [80.91.160.94]) by raider.datacom.kiev.ua (8.12.1/8.12.1) with SMTP id g54Csi1E073128 for ; Tue, 4 Jun 2002 15:54:49 +0300 (EEST) (envelope-from gnut@fc.kiev.ua) Received: from localhost (localhost.fc.kiev.ua [127.0.0.1]) by blend.fc.kiev.ua (Postfix) with SMTP id E503128D1D; Tue, 4 Jun 2002 15:54:44 +0300 (EEST) Received: from 192.168.3.31 (gnut.fc.kiev.ua [192.168.3.31]) by blend.fc.kiev.ua (Postfix) with ESMTP id 620E828C11 for ; Tue, 4 Jun 2002 15:54:44 +0300 (EEST) Date: Tue, 4 Jun 2002 15:54:41 +0300 From: "Oles' Hnatkevych" X-Mailer: The Bat! (v1.60) Reply-To: "Oles' Hnatkevych" Organization: Finance & Credit Banking Corporation X-Priority: 3 (Normal) Message-ID: <152112502610.20020604155441@fc.kiev.ua> Disposition-Notification-To: gnut@fc.kiev.ua To: freebsd-net@freebsd.org Subject: ospf 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 Hello ppl I need rock-solid OSPF daemon that works on FreeBSD-4.5. Zebra has not proved to be that one since tun(4) interfaces are created on the fly - it crashes the box. Please give me some advice what port should I use. With best wishes, Oles' Hnatkevych, http://gnut.kiev.ua, gnut@fc.kiev.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 6:40:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by hub.freebsd.org (Postfix) with ESMTP id B734737B400 for ; Tue, 4 Jun 2002 06:40:15 -0700 (PDT) Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:202:b3ff:fe17:a4cb]) by mailhost.stack.nl (Postfix) with ESMTP id 4375F3D825; Tue, 4 Jun 2002 15:40:14 +0200 (CEST) Received: by dragon.stack.nl (Postfix, from userid 1600) id 5F396988A; Tue, 4 Jun 2002 15:36:58 +0200 (CEST) Date: Tue, 4 Jun 2002 15:36:58 +0200 From: Dean Strik To: Oles' Hnatkevych Cc: freebsd-net@freebsd.org Subject: Re: ospf Message-ID: <20020604133658.GA45943@dragon.stack.nl> References: <152112502610.20020604155441@fc.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152112502610.20020604155441@fc.kiev.ua> User-Agent: Mutt/1.3.99i X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes 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 Oles' Hnatkevych wrote: > I need rock-solid OSPF daemon that works on FreeBSD-4.5. > Zebra has not proved to be that one since tun(4) interfaces > are created on the fly - it crashes the box. Which is not zebra's fault... better fix the system than work around it by using an other program... -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 6:57:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 964CF37B403 for ; Tue, 4 Jun 2002 06:57:20 -0700 (PDT) Received: from moe.cs.duke.edu (moe.cs.duke.edu [152.3.140.74]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA09101; Tue, 4 Jun 2002 09:57:10 -0400 (EDT) Received: (gallatin@localhost) by moe.cs.duke.edu (8.8.5/8.6.9) id JAA03663; Tue, 4 Jun 2002 09:57:10 -0400 (EDT) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15612.50998.79685.943067@moe.cs.duke.edu> Date: Tue, 4 Jun 2002 09:57:10 -0400 (EDT) To: Archie Cobbs Cc: Bosko Milekic , Julian Elischer , Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: Race condition with M_EXT ref count? In-Reply-To: <200206040553.g545rXH49446@arch20m.dellroad.org> References: <20020603193651.A29296@unixdaemons.com> <200206040553.g545rXH49446@arch20m.dellroad.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid 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 Archie Cobbs writes: > Re: the -stable patch. I agree we need a more general MFC/cleanup > of some of the mbuf improvements from -current into -stable. > If I find time perhaps I'll do that as well, but in a separate patch. > For the present time, I'll commit this once 4.6-REL is done. The best improvements (IMHO, anyway) are the changes in the way external mbufs are referenced and dereferenced. It greatly simplifies writing code that uses external mbufs. However, you need to carefully consider what you backport. We want to try to avoid breaking ABI compatibility for 3rd party vendors who ship binary network interface drivers. At Myricom, we offer a binary driver built on 4.1.1-RELEASE and it works through 4.5-RELEASE(*). It would be bad to loose this feature. So I'd oppose MFC'ing anything that breaks binary compatibility for network drivers in the 4.x line. The last thing we want to do is make extra work for the few companies who offer FreeBSD drivers for their hardare. Cheers, Drew (*) We also ship source, but building from source is somewhat of a pain. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 8:47:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D544C37B400 for ; Tue, 4 Jun 2002 08:47:15 -0700 (PDT) Received: from isi.edu (e64zg2wf83eor0un@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g54FlEr12217; Tue, 4 Jun 2002 08:47:14 -0700 (PDT) Message-ID: <3CFCE101.3040108@isi.edu> Date: Tue, 04 Jun 2002 08:47:13 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010605080902010807040704" 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. --------------ms010605080902010807040704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > the signal that tell the WFQ algorithm when you can transmit the > next packet comes from the pipe. The latter ticks either at a > predefined rate (as configured with the 'bw NNN bit/s' parameter), > or from the tx interrupt coming from a device (e.g. you can say > something like 'bw ed0' to get the transmit clock from device ed0). > > HOWEVER: i have implemented the necessary machinery in dummynet (it > is a function called if_tx_rdy()) and in the user interface, "ipfw", > but have not added the hooks to call if_tx_rdy() in each device > driver because these calls are somewhat expensive, and you probably do not want > them on a 100Mbit/s interface. > > See http://www.geocrawler.com/archives/3/165/2002/3/0/8222181/ > on how to use them (a search for "dummynet if_tx_rdy()" should return > some results). I'm trying to merge this into the sis driver, which seems to batch transmissions together. For clarification, do you expect one if_tx_rdy() call per packet or one per batch? Per packet may result in a burst of these calls, does dummynet handle this? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms010605080902010807040704 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwNDE1NDcxNFowIwYJKoZIhvcNAQkEMRYEFAvehpiQ2R3R exvqdnLeICW7WpsHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCpwKTzxfhqRvgw/z34efps7uKbriyRiN8FKBkap78dbtcR R9kugiT+cUQ71HV4QBlK0QGlGRowtaKW7R4We+BFP2SntCpuPQ/GzcGU8pnwO0ff8vAVpVEQ N/dpbNwRAUAaLoESJRACcvEdmaCuxS7T7KfjShIQjPatkKAknsIUJQAAAAAAAA== --------------ms010605080902010807040704-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 8:50:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D77E737B40D for ; Tue, 4 Jun 2002 08:50:45 -0700 (PDT) Received: from isi.edu (od2s4dvh0afp1m52@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g54Fodr16225; Tue, 4 Jun 2002 08:50:39 -0700 (PDT) Message-ID: <3CFCE1CF.2070001@isi.edu> Date: Tue, 04 Jun 2002 08:50:39 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Lars Eggert Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: Dummynet WFQ References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203040108070605080104" 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. --------------ms010203040108070605080104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lars Eggert wrote: > I'm trying to merge this into the sis driver, which seems to batch > transmissions together. For clarification, do you expect one if_tx_rdy() > call per packet or one per batch? Per packet may result in a burst of > these calls, does dummynet handle this? Oh, I'm also using your "polling" version of the sis driver - maybe that'd reduce the overhead of if_tx_rdy() you mentioned? Lars -- Lars Eggert USC Information Sciences Institute --------------ms010203040108070605080104 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwNDE1NTAzOVowIwYJKoZIhvcNAQkEMRYEFLXrzLg50M2s o/d8o0A3QWuhKSM4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCR3/LCMZRni6bb2Mh9zw5afHl5ofznjI4f5emeZu+z4ZUe 2Fni83EYvlXyn2sOxq122rcH4pLxoU6O99DytrDoKcAxCCdM9WSyeiVYMwzm9Fjiy0OY5yX6 riln0BaCf9wWO5J3bNJpm54ZViLN4N9+4/dRHxLIenxcSE/9X/OuAgAAAAAAAA== --------------ms010203040108070605080104-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 9: 7:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 67ADA37B404 for ; Tue, 4 Jun 2002 09:07:21 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g54G7JG88759; Tue, 4 Jun 2002 09:07:19 -0700 (PDT) (envelope-from rizzo) Date: Tue, 4 Jun 2002 09:07:19 -0700 From: Luigi Rizzo To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ Message-ID: <20020604090719.A88701@iguana.icir.org> References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> <3CFCE1CF.2070001@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CFCE1CF.2070001@isi.edu>; from larse@ISI.EDU on Tue, Jun 04, 2002 at 08:50:39AM -0700 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 Most device drivers batch transmissions, but if you use the interface as a clock for the pipe, dummynet will only send a single packet at a time to the device, so you won't have to bother about the batching. The overhead is in the fact that if_tx_rdy() has to scan all pipes to find the one who needs the signal. Polling won't help on this, whereas it would to have a direct pointer from the interface to the pipe (but we'd need to extend the struct ifnet, and do the appropriate garbage collection when interfaces and/or pipes are added/deleted). BTW if you use polling, you have to be careful in the place where you put the call to if_tx_rdy() to make sure that it catches the tx queue becoming empty only once and not at every polling cycle. cheers luigi p.s. the soekris boxes are becoming popular, aren't they! On Tue, Jun 04, 2002 at 08:50:39AM -0700, Lars Eggert wrote: > Lars Eggert wrote: > > I'm trying to merge this into the sis driver, which seems to batch > > transmissions together. For clarification, do you expect one if_tx_rdy() > > call per packet or one per batch? Per packet may result in a burst of > > these calls, does dummynet handle this? > > Oh, I'm also using your "polling" version of the sis driver - maybe > that'd reduce the overhead of if_tx_rdy() you mentioned? > > Lars > -- > Lars Eggert USC Information Sciences Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 9:22:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 43D8A37B404 for ; Tue, 4 Jun 2002 09:22:17 -0700 (PDT) Received: from isi.edu (9cbt17bqzhedn4h7@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g54GMEr12055; Tue, 4 Jun 2002 09:22:15 -0700 (PDT) Message-ID: <3CFCE935.8090603@isi.edu> Date: Tue, 04 Jun 2002 09:22:13 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> <3CFCE1CF.2070001@isi.edu> <20020604090719.A88701@iguana.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030801060900030209000108" 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. --------------ms030801060900030209000108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > BTW if you use polling, you have to be careful in the place where you > put the call to if_tx_rdy() to make sure that it catches the tx queue > becoming empty only once and not at every polling cycle. How about at the very end of sis_intr(), as a new "else" branch of the queue length check, like this: if (ifp->if_snd.ifq_head != NULL) sis_start(ifp); + else + if_tx_ready(ifp); That doesn't seem to be in the codepath that gets executed on each poll, right? > p.s. the soekris boxes are becoming popular, aren't they! They are amazing, I'm really glad the folks on freebsd-small have pointed us at them. Only downside is that you go blind if you look at the case for too long :-) Lars -- Lars Eggert USC Information Sciences Institute --------------ms030801060900030209000108 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwNDE2MjIxNFowIwYJKoZIhvcNAQkEMRYEFEtuksRCLvBs h9cs0hASX/xPmw/EMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYDN69KMNV/zY69MB/ZB+g1ocPh6i/fPdMthrr3/i32lPk0e fVQvSBDPOwcky8fAdlA1aMZmdNbSSitGvfROjdCKYT/8JgCmR/Qm+0cNRcOn+9tyeec53IB3 pNHkDdFM2rhyke18otrPROSOCs3oqC7HRJDm/6uMXT7s6XWE7EDVmQAAAAAAAA== --------------ms030801060900030209000108-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 9:25:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 4C34837B407 for ; Tue, 4 Jun 2002 09:25:48 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g54GPl588957; Tue, 4 Jun 2002 09:25:47 -0700 (PDT) (envelope-from rizzo) Date: Tue, 4 Jun 2002 09:25:47 -0700 From: Luigi Rizzo To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ Message-ID: <20020604092547.B88852@iguana.icir.org> References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> <3CFCE1CF.2070001@isi.edu> <20020604090719.A88701@iguana.icir.org> <3CFCE935.8090603@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CFCE935.8090603@isi.edu>; from larse@ISI.EDU on Tue, Jun 04, 2002 at 09:22:13AM -0700 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, Jun 04, 2002 at 09:22:13AM -0700, Lars Eggert wrote: > Luigi Rizzo wrote: > > BTW if you use polling, you have to be careful in the place where you > > put the call to if_tx_rdy() to make sure that it catches the tx queue > > becoming empty only once and not at every polling cycle. > > How about at the very end of sis_intr(), as a new "else" branch of the > queue length check, like this: except that sis_intr is never called when you use polling :( cheers luigi > if (ifp->if_snd.ifq_head != NULL) > sis_start(ifp); > + > else > + > if_tx_ready(ifp); > > That doesn't seem to be in the codepath that gets executed on each poll, > right? > > > p.s. the soekris boxes are becoming popular, aren't they! > > They are amazing, I'm really glad the folks on freebsd-small have > pointed us at them. Only downside is that you go blind if you look at > the case for too long :-) > > Lars > -- > Lars Eggert USC Information Sciences Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 9:47:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 73C4337B405 for ; Tue, 4 Jun 2002 09:47:24 -0700 (PDT) Received: from isi.edu (4y6soiili3luf4fa@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g54GlNr27266; Tue, 4 Jun 2002 09:47:23 -0700 (PDT) Message-ID: <3CFCEF1A.8090807@isi.edu> Date: Tue, 04 Jun 2002 09:47:22 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> <3CFCE1CF.2070001@isi.edu> <20020604090719.A88701@iguana.icir.org> <3CFCE935.8090603@isi.edu> <20020604092547.B88852@iguana.icir.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090209040706010609040308" 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. --------------ms090209040706010609040308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: >>> BTW if you use polling, you have to be careful in the place >>> where you put the call to if_tx_rdy() to make sure that it >>> catches the tx queue becoming empty only once and not at every >>> polling cycle. >> >> How about at the very end of sis_intr(), as a new "else" branch of >> the queue length check, like this: > > except that sis_intr is never called when you use polling :( Doh. You're right, of course. A new "else" branch of the corresponding "if" in sis_poll() would fire on each poll while the queue is empty, so I guess I'll put the call at the end of the "while" loop in sis_txeof(), after the mbuf is freed. Lars -- Lars Eggert USC Information Sciences Institute --------------ms090209040706010609040308 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwNDE2NDcyM1owIwYJKoZIhvcNAQkEMRYEFOCNjWvKAu9q lNmdokcAA3nXhO6NMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBw8tTPY/+2VLwR3S411Y9tNTbckE2nzD5jgNxuFvgQ7roh 7+HQNtnmrqK+R5Pk0HroJUcXAtp2o+j+3lamrBek7JCRQ2LEtuQ2cfbUi/tj3z6qexzPH1YA TrBk8klf99r0YRLvfKYGQJCjwoF2xJijrSv4TCxo/yoUdJUWpHHH2gAAAAAAAA== --------------ms090209040706010609040308-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 10:30:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4851D37B405 for ; Tue, 4 Jun 2002 10:30:10 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA87446; Tue, 4 Jun 2002 10:14:24 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g54HDHf51449; Tue, 4 Jun 2002 10:13:17 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206041713.g54HDHf51449@arch20m.dellroad.org> Subject: Re: netgraph documentation? In-Reply-To: <3CFB88C6.4070407@isi.edu> "from Lars Eggert at Jun 3, 2002 08:18:30 am" To: Lars Eggert Date: Tue, 4 Jun 2002 10:13:17 -0700 (PDT) Cc: Archie Cobbs , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Lars Eggert writes: > So I ignore the error for now, and make the TCP tunnel as follows: > > Server: > /usr/sbin/ngctl mkpeer iface dummy inet > /sbin/ifconfig ng0 10.10.10.1 10.10.10.2 > /usr/sbin/ngctl mkpeer ng0: ksocket inet inet/stream/tcp > /usr/sbin/ngctl msg ng0:inet bind inet/127.0.0.1:50505 > /usr/sbin/ngctl msg ng0:inet listen 1 > ngctl: send msg: Operation not supported by device > > Client: > /usr/sbin/ngctl mkpeer iface dummy inet > /sbin/ifconfig ng1 10.10.10.2 10.10.10.1 > /usr/sbin/ngctl mkpeer ng1: ksocket inet inet/stream/tcp > /usr/sbin/ngctl msg ng1:inet bind inet/127.0.0.1:50506 > /usr/sbin/ngctl msg ng1:inet connect inet/127.0.0.1:50505 > ngctl: send msg: Operation now in progress > > A tcpdump on lo0 shows the 3-way handshake suceeding: > > [root@hbo: ~larse] tcpdump -i lo0 port 50505 > tcpdump: listening on lo0 > 08:11:29.013658 loopback.50506 > loopback.50505: S > 2787661608:2787661608(0) win 65535 1,nop,nop,timestamp 14010458 0,nop,nop,cc 383> (DF) > 08:11:29.013710 loopback.50505 > loopback.50506: S > 1751674938:1751674938(0) ack 2787661609 win 65535 1,nop,nop,timestamp 14010458 14010458,nop,nop,cc 384,nop,nop,ccecho 383> > 08:11:29.013754 loopback.50506 > loopback.50505: . ack 1 win 32767 > (DF) > > Pinging 10.10.10.2 results in: > > [root@hbo: ~larse] ping 10.10.10.2 > PING 10.10.10.2 (10.10.10.2): 56 data bytes > ping: sendto: Socket is not connected > ping: sendto: Socket is not connected > ping: sendto: Socket is not connected > ^C > --- 10.10.10.2 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss I don't think you can have a point-to-point interface who's remote IP address is also local to your box. In other words, this may not work on the same machine but it might work if you use two different machines... can you try that? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 11:17:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 601FB37B400 for ; Tue, 4 Jun 2002 11:17:51 -0700 (PDT) Received: from isi.edu (z77e92c206g4dkch@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g54IHnr00871; Tue, 4 Jun 2002 11:17:49 -0700 (PDT) Message-ID: <3CFD044C.3080300@isi.edu> Date: Tue, 04 Jun 2002 11:17:48 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: net@FreeBSD.ORG Subject: Re: netgraph documentation? References: <200206041713.g54HDHf51449@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060506010609080306050009" 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. --------------ms060506010609080306050009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie Cobbs wrote: > I don't think you can have a point-to-point interface who's > remote IP address is also local to your box. In other words, > this may not work on the same machine but it might work if > you use two different machines... can you try that? The addresses of the point-to-point interface aren't local to the box, the encapsulation ones are. I do this all the time with gifs and tuns, and it works fine. Anyway, I tried it with two machines, and I see the same thing happening: Ping packets originating on the client make it over the TCP tunnel, and the server sends something back (ICMP reply, I from the looks of it). However, the data gets dropped somewhere after the bpf dumps the packet. Ping packets originating on the server never enter the tunnel, and I see "ping: sendto: Socket is not connected". A UDP tunnel (like in your example) works fine between the same machines using the same addresses. Please let me know if there's anything I can do to help track this down. Lars -- Lars Eggert USC Information Sciences Institute --------------ms060506010609080306050009 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 HAYJKoZIhvcNAQkFMQ8XDTAyMDYwNDE4MTc0OFowIwYJKoZIhvcNAQkEMRYEFH6kb0cVT0Du 1udXq8v/LnV0/pN6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBfxVm3Lz0y8Px4NJXbKEmKH8RagdIZDb/c3VQ+IjCSLgk+ 7jtvNWroyNaAGoXPcD2xlVWnjnmVqz2K2e2z8c4AfRg7z5P4DyQ9c2COLuZT02YSkQwN8Jun qTmv5+Oud95pIH3eBTU+rK98obI93mohdPBaDRKwv93Jb7QQxVDWbgAAAAAAAA== --------------ms060506010609080306050009-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 11:44:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id CB07137B403 for ; Tue, 4 Jun 2002 11:44:52 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g54IipB89833; Tue, 4 Jun 2002 11:44:51 -0700 (PDT) (envelope-from rizzo) Date: Tue, 4 Jun 2002 11:44:51 -0700 From: Luigi Rizzo To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: Dummynet WFQ Message-ID: <20020604114451.A89759@iguana.icir.org> References: <3CFB9BC4.9080506@isi.edu> <20020603122913.A78688@iguana.icir.org> <3CFCE101.3040108@isi.edu> <3CFCE1CF.2070001@isi.edu> <20020604090719.A88701@iguana.icir.org> <3CFCE935.8090603@isi.edu> <20020604092547.B88852@iguana.icir.org> <3CFCEF1A.8090807@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CFCEF1A.8090807@isi.edu>; from larse@ISI.EDU on Tue, Jun 04, 2002 at 09:47:22AM -0700 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, Jun 04, 2002 at 09:47:22AM -0700, Lars Eggert wrote: > Luigi Rizzo wrote: > >>> BTW if you use polling, you have to be careful in the place > >>> where you put the call to if_tx_rdy() to make sure that it > >>> catches the tx queue becoming empty only once and not at every > >>> polling cycle. > >> > >> How about at the very end of sis_intr(), as a new "else" branch of > >> the queue length check, like this: > > > > except that sis_intr is never called when you use polling :( > > Doh. You're right, of course. > > A new "else" branch of the corresponding "if" in sis_poll() would fire > on each poll while the queue is empty, so I guess I'll put the call at > the end of the "while" loop in sis_txeof(), after the mbuf is freed. and _if_ the mbuf is freed. In any case it is more a matter of efficiency than of correctness. Even if you call repeatedly if_tx_rdy() when the device queue is empty (and the pipe is idle, otherwise at the first occurrence it will transmit a packet making the transmit queue not empty anymore) the pipe will not 'accumulate' credits. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 14: 1:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id D7E8137B400 for ; Tue, 4 Jun 2002 14:01:04 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA88717; Tue, 4 Jun 2002 13:45:11 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g54Ki4K52234; Tue, 4 Jun 2002 13:44:04 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206042044.g54Ki4K52234@arch20m.dellroad.org> Subject: Re: netgraph documentation? In-Reply-To: <3CFD044C.3080300@isi.edu> "from Lars Eggert at Jun 4, 2002 11:17:48 am" To: Lars Eggert Date: Tue, 4 Jun 2002 13:44:04 -0700 (PDT) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Lars Eggert writes: > > I don't think you can have a point-to-point interface who's > > remote IP address is also local to your box. In other words, > > this may not work on the same machine but it might work if > > you use two different machines... can you try that? > > The addresses of the point-to-point interface aren't local to the box, > the encapsulation ones are. I do this all the time with gifs and tuns, > and it works fine. > > Anyway, I tried it with two machines, and I see the same thing happening: > > Ping packets originating on the client make it over the TCP tunnel, and > the server sends something back (ICMP reply, I from the looks of it). > However, the data gets dropped somewhere after the bpf dumps the packet. > > Ping packets originating on the server never enter the tunnel, and I see > "ping: sendto: Socket is not connected". Ah yes, now I remember.. the problem is that the listening socket is not the same socket as the socket for the new connection. E.g., notice the way accept(2) works. What you want to do is not supported in -stable. You can try applying these patches from -current: sys/netgraph/ng_ksocket.c rev. 1.20 sys/netgraph/ng_ksocket.h rev. 1.5 -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 14:56:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 3862637B403 for ; Tue, 4 Jun 2002 14:56:37 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g54LuWKZ006648; Tue, 4 Jun 2002 22:56:32 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g54LuUAI034702; Tue, 4 Jun 2002 22:56:30 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Tue, 4 Jun 2002 22:56:29 +0100 From: Brian Somers To: Archie Cobbs Cc: larse@ISI.EDU, archie@dellroad.org, net@FreeBSD.ORG Subject: Re: netgraph documentation? Message-Id: <20020604225629.3e6abd00.brian@Awfulhak.org> In-Reply-To: <200206041713.g54HDHf51449@arch20m.dellroad.org> References: <3CFB88C6.4070407@isi.edu> <200206041713.g54HDHf51449@arch20m.dellroad.org> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 Tue, 4 Jun 2002 10:13:17 -0700 (PDT), Archie Cobbs wrote: [.....] > I don't think you can have a point-to-point interface who's > remote IP address is also local to your box. In other words, > this may not work on the same machine but it might work if > you use two different machines... can you try that? > > -Archie It's ok to do this. I run ppp back-to-back with itself using set device "!ppp -direct in" for testing. In fact, there are examples in ppp.conf.sample :) -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 16:45:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id 1EA0E37B400 for ; Tue, 4 Jun 2002 16:45:33 -0700 (PDT) Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id TAA14128; Tue, 4 Jun 2002 19:45:31 -0400 (EDT) Date: Tue, 4 Jun 2002 19:45:31 -0400 (EDT) From: Nguyen-Tuong Long Le To: freebsd-net@freebsd.org Cc: Nguyen-Tuong Long Le Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: <20020603121118.Y38431-100000@patrocles.silby.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 On Mon, 3 Jun 2002, Mike Silbersack wrote: > A few questions: > > 1. Is this 4.5-release, or 4.5-stable (aka 4.6-RC2)? 4.5-release had a > few bugs in the syn cache which could cause crashes. > > 2. Are you using accept filters? Accept filters act oddly on > 4.5-release, you'll have to upgrade to 4.5-stable/4.6. > > 3. Could you use tcpdump to determine what exactly is going wrong and > post a url to the log so that we can investigate what is going wrong? Hi all, Thanks for all your suggestions. I've tried out all of them but they unfortunately didn't fix the problem. I have this problem with 4.5-RELEASE. I cvsup'ed the source tree and tried 4.5-RELEASE-p6 and 4.6-RC #1 but they didn't fix the problem. Setting net.inet.tcp.syncookies didn't help either. I use poll(). I don't use accept filters. I instrumented some code in tcp_input() that seems to indicate that lots of TCP segments (about 42000 segments in 10 minutes) are dropped because syncache_expand() returns 0. This in turn is caused because syncache_lookup() and syncookie_lookup() return NULL. Why this is happening is beyond my knowledge. I took a 10-minute tcpdump trace and put it up at www.cs.unc.edu/~le/tmp/ti.dump.gz (It's actually two one-way tcpdump traces taken at the fiber tap next to the server. I used tcpslice from tcpdump.org to merge them. I checked that all packets from the two one-way traces are in the merged trace and they seem to be sorted in timestamp order). Here is a typical sequence of exchanges for connections that are reset by the server. The server ack's the first SYN by a SYN/ACK but doesn't ack any segment after that. 18:11:33.461574 152.2.135.14.1827 > 152.2.136.39.6789: S 171182594:171182594(0) win 16384 (DF) 18:11:33.760675 152.2.136.39.6789 > 152.2.135.14.1827: S 4246482515:4246482515(0) ack 171182595 win 16384 18:11:33.761000 152.2.135.14.1827 > 152.2.136.39.6789: . ack 1 win 17376 (DF) 18:11:33.761390 152.2.135.14.1827 > 152.2.136.39.6789: P 1:5(4) ack 1 win 17376 (DF) 18:11:33.761586 152.2.135.14.1827 > 152.2.136.39.6789: P 5:13(8) ack 1 win 17376 (DF) 18:11:33.762172 152.2.135.14.1827 > 152.2.136.39.6789: P 13:293(280) ack 1 win 17376 (DF) 18:11:34.031741 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 18:11:34.046008 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 18:11:34.060284 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 Any hint or suggestion would be very much appreciated. Thanks, -- long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 16:50:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 3AC4037B405 for ; Tue, 4 Jun 2002 16:49:41 -0700 (PDT) Received: from tel.fer.hr (zg07-088.dialin.iskon.hr [213.191.150.89]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g54NnWj28744 for ; Wed, 5 Jun 2002 01:49:34 +0200 (MEST) Message-ID: <3CFD51EC.AD9D7192@tel.fer.hr> Date: Wed, 05 Jun 2002 01:49:01 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Patch for review: source VIPA Content-Type: multipart/mixed; boundary="------------2FB848ED7893B437F014C895" 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. --------------2FB848ED7893B437F014C895 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Bellow is a patch that enables all outgoing sessions to always use the same source IP address by default, no matter what outbound interface is used. If on a multi-homed host the source IP address always originates from an "always-up" internal virtual interface, than the established TCP sessions won't break in case of failure of one of the physical interfaces, or similar serious network topology changes. The idea is not new, as far as I know it was introduced a couple of years ago in OS/390 V2R5 TCP/IP implementation, if not earlier. IBM called this feature "Virtual IP Address - VIPA", so just for fun I also borrowed the name along with the idea... Anyway, after applying the patch (against 4.6-RC3 kernel source), a new sysctl variable net.inet.ip.sourcevipa becomes available, which can be set to an existing IP address of desired internal interface. Although any interface can be used for source-VIPA feature, the patch also provides a new interface type "vipa", which is nothing else than a standard loopback ifc, but without the loopback flag set, so that it can be conveniently advertised via the routed daemon. The following line should be added to your kernel config file in order to make the vipa ifc available: pseudo-device vipa 1 Here is an configuration example: vmbsd# routed vmbsd# ifconfig lnc0: flags=8843 mtu 1500 inet 192.168.201.143 netmask 0xffffff00 broadcast 192.168.201.255 ether 00:50:56:ac:c9:7a lnc1: flags=8843 mtu 1500 inet 192.168.202.143 netmask 0xffffff00 broadcast 192.168.202.255 ether 00:50:56:ac:c9:8c lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 vipa0: flags=61 mtu 1500 inet 192.168.1.1 netmask 0xffffffff vmbsd# sysctl net.inet.ip.sourcevipa net.inet.ip.sourcevipa: none vmbsd# sysctl net.inet.ip.sourcevipa=192.168.1.1 net.inet.ip.sourcevipa: none -> 192.168.1.1 vmbsd# vmbsd# telnet 192.168.201.10 [cut] %who am i marko ttyp2 Jun 5 01:37 (192.168.1.1) Have fun! --------------2FB848ED7893B437F014C895 Content-Type: text/plain; charset=iso-8859-2; name="vipa.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vipa.diff" --- netinet/in_pcb.c Thu May 2 04:36:50 2002 +++ netinet/in_pcb.c.vipa Wed Jun 5 00:14:19 2002 @@ -122,6 +122,50 @@ SYSCTL_PROC(_net_inet_ip_portrange, OID_ SYSCTL_PROC(_net_inet_ip_portrange, OID_AUTO, hilast, CTLTYPE_INT|CTLFLAG_RW, &ipport_hilastauto, 0, &sysctl_net_ipport_check, "I", ""); + +static char sourcevipastr[16] = "none"; +static u_long sourcevipa=0; + +static int +sourcevipa_sysctl(SYSCTL_HANDLER_ARGS) +{ + int error; + u_char i,j; + u_long addr=0; + char *c; + + error = sysctl_handle_string(oidp, + oidp->oid_arg1, oidp->oid_arg2, req); + if (error) + return error; + c=sourcevipastr; + for (i=0;i<4;i++) { + j=0; + while (*c>='0'&&*c<='9') { + j*=10; + j+=*c-'0'; + c++; + } + if (*c!=0) + c++; + addr=(addr<<8)+j; + } + sourcevipa=addr; + if (addr) { + unsigned char *ucp=(u_char *)&addr; + sprintf(sourcevipastr, "%d.%d.%d.%d", + ucp[0], ucp[1], ucp[2], ucp[3]); + } else { + sprintf(sourcevipastr, "none"); + } + return 0; +} + +SYSCTL_PROC(_net_inet_ip, OID_AUTO, sourcevipa, CTLTYPE_STRING|CTLFLAG_RW, + sourcevipastr, sizeof(sourcevipastr), &sourcevipa_sysctl, "A", + "Always try to use this IP address as source"); + + /* * in_pcb.c: manage the Protocol Control Blocks. * @@ -438,7 +482,25 @@ in_pcbladdr(inp, nam, plocal_sin) * to our address on another net goes to loopback). */ if (ro->ro_rt && !(ro->ro_rt->rt_ifp->if_flags & IFF_LOOPBACK)) - ia = ifatoia(ro->ro_rt->rt_ifa); + { + /* + * Use source VIPA, if available + * M. Zec (zec@tel.fer.hr) 2002/06/24 + */ + if (sourcevipa) { + u_long addr = sin->sin_addr.s_addr; + u_short fport = sin->sin_port; + + sin->sin_addr.s_addr = htonl(sourcevipa); + sin->sin_port = 0; + ia = ifatoia(ifa_ifwithaddr(sintosa(sin))); + sin->sin_addr.s_addr = addr; + sin->sin_port = fport; + } + + if (ia == 0) + ia = ifatoia(ro->ro_rt->rt_ifa); + } if (ia == 0) { u_short fport = sin->sin_port; --- net/if_loop.c Thu Dec 20 11:30:16 2001 +++ net/if_loop.c.vipa Wed Jun 5 00:16:40 2002 @@ -38,6 +38,7 @@ * Loopback interface driver for protocol testing and timing. */ #include "loop.h" +#include "vipa.h" #include "opt_atalk.h" #include "opt_inet.h" @@ -53,6 +54,7 @@ #include #include +#include #include #include #include @@ -103,7 +105,7 @@ int looutput __P((struct ifnet *ifp, #define LOMTU 16384 #endif -struct ifnet loif[NLOOP]; +struct ifnet loif[NLOOP+NVIPA]; /* ARGSUSED */ static void @@ -113,11 +115,18 @@ loopattach(dummy) register struct ifnet *ifp; register int i = 0; - for (ifp = loif; i < NLOOP; ifp++) { - ifp->if_name = "lo"; - ifp->if_unit = i++; - ifp->if_mtu = LOMTU; - ifp->if_flags = IFF_LOOPBACK | IFF_MULTICAST; + for (ifp = loif; i < NLOOP+NVIPA; ifp++) { + if (iif_name = "lo"; + ifp->if_unit = i++; + ifp->if_mtu = LOMTU; + ifp->if_flags = IFF_LOOPBACK | IFF_MULTICAST; + } else { + ifp->if_name = "vipa"; + ifp->if_unit = i++ - NLOOP; + ifp->if_mtu = ETHERMTU; + ifp->if_flags = IFF_SMART; /* joke! */ + } ifp->if_ioctl = loioctl; ifp->if_output = looutput; ifp->if_type = IFT_LOOP; --- conf/files Sat May 4 10:48:53 2002 +++ conf/files.vipa Tue Jun 4 23:56:15 2002 @@ -698,6 +698,7 @@ net/if_faith.c optional faith net/if_fddisubr.c optional fddi net/if_gif.c optional gif net/if_loop.c optional loop +net/if_loop.c optional vipa net/if_media.c standard net/if_mib.c standard net/if_ppp.c optional ppp --- i386/conf/LINT Wed Jun 5 00:20:55 2002 +++ i386/conf/LINT.vipa Wed Jun 5 00:19:59 2002 @@ -525,6 +525,8 @@ options ETHER_8023 # enable Ethernet_8 options ETHER_8022 # enable Ethernet_802.2 frame options ETHER_SNAP # enable Ethernet_802.2/SNAP frame +pseudo-device vipa 1 # Virtual IP Address (routable loopback) + # for IPv6 pseudo-device gif #IPv6 and IPv4 tunneling pseudo-device faith 1 #for IPv6 and IPv4 translation --------------2FB848ED7893B437F014C895-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 16:51:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by hub.freebsd.org (Postfix) with ESMTP id 74F5637B403 for ; Tue, 4 Jun 2002 16:51:48 -0700 (PDT) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id g54NpeR03828; Tue, 4 Jun 2002 16:51:40 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.11.0/8.11.0) id g54NpeX45317; Tue, 4 Jun 2002 16:51:40 -0700 (PDT) (envelope-from jayanth) Date: Tue, 4 Jun 2002 16:51:40 -0700 From: jayanth To: Nguyen-Tuong Long Le Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problem with SYN cache in FreeBSD 4.5 Message-ID: <20020604165140.B44498@yahoo-inc.com> References: <20020603121118.Y38431-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from le@cs.unc.edu on Tue, Jun 04, 2002 at 07:45:31PM -0400 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 Can you dump the output of netstat -s -p tcp ? Checking for listen queue overflows and syncache bucket overflows. jayanth Nguyen-Tuong Long Le (le@cs.unc.edu) wrote: > On Mon, 3 Jun 2002, Mike Silbersack wrote: > > > A few questions: > > > > 1. Is this 4.5-release, or 4.5-stable (aka 4.6-RC2)? 4.5-release had a > > few bugs in the syn cache which could cause crashes. > > > > 2. Are you using accept filters? Accept filters act oddly on > > 4.5-release, you'll have to upgrade to 4.5-stable/4.6. > > > > 3. Could you use tcpdump to determine what exactly is going wrong and > > post a url to the log so that we can investigate what is going wrong? > > Hi all, > > Thanks for all your suggestions. I've tried out all of them but > they unfortunately didn't fix the problem. > > I have this problem with 4.5-RELEASE. I cvsup'ed the source tree and > tried 4.5-RELEASE-p6 and 4.6-RC #1 but they didn't fix the problem. > Setting net.inet.tcp.syncookies didn't help either. > > I use poll(). I don't use accept filters. > > I instrumented some code in tcp_input() that seems to indicate > that lots of TCP segments (about 42000 segments in 10 minutes) > are dropped because syncache_expand() returns 0. This in turn > is caused because syncache_lookup() and syncookie_lookup() > return NULL. Why this is happening is beyond my knowledge. > > I took a 10-minute tcpdump trace and put it up at > www.cs.unc.edu/~le/tmp/ti.dump.gz (It's actually two one-way > tcpdump traces taken at the fiber tap next to the server. > I used tcpslice from tcpdump.org to merge them. I checked that all > packets from the two one-way traces are in the merged trace and > they seem to be sorted in timestamp order). Here is a typical > sequence of exchanges for connections that are reset by the server. > The server ack's the first SYN by a SYN/ACK but doesn't ack any > segment after that. > > 18:11:33.461574 152.2.135.14.1827 > 152.2.136.39.6789: S 171182594:171182594(0) win 16384 (DF) > 18:11:33.760675 152.2.136.39.6789 > 152.2.135.14.1827: S 4246482515:4246482515(0) ack 171182595 win 16384 > 18:11:33.761000 152.2.135.14.1827 > 152.2.136.39.6789: . ack 1 win 17376 (DF) > 18:11:33.761390 152.2.135.14.1827 > 152.2.136.39.6789: P 1:5(4) ack 1 win 17376 (DF) > 18:11:33.761586 152.2.135.14.1827 > 152.2.136.39.6789: P 5:13(8) ack 1 win 17376 (DF) > 18:11:33.762172 152.2.135.14.1827 > 152.2.136.39.6789: P 13:293(280) ack 1 win 17376 (DF) > 18:11:34.031741 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 > 18:11:34.046008 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 > 18:11:34.060284 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 > > Any hint or suggestion would be very much appreciated. > > Thanks, > -- long > > > 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 Jun 4 17:45: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d51.as14.nwbl0.wi.voyager.net [169.207.134.51]) by hub.freebsd.org (Postfix) with ESMTP id C898C37B401 for ; Tue, 4 Jun 2002 17:44:39 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g550kHOA044714; Tue, 4 Jun 2002 19:46:17 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g550kEOr044711; Tue, 4 Jun 2002 19:46:15 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 4 Jun 2002 19:46:13 -0500 (CDT) From: Mike Silbersack To: jayanth Cc: Nguyen-Tuong Long Le , Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: <20020604165140.B44498@yahoo-inc.com> Message-ID: <20020604194538.J42854-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 Tue, 4 Jun 2002, jayanth wrote: > Can you dump the output of netstat -s -p tcp ? > Checking for listen queue overflows and syncache bucket overflows. > > jayanth And "netstat -La" too, please. I'm interested in if you're accepting sockets fast enough. 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 Tue Jun 4 20: 0:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id 368C137B400 for ; Tue, 4 Jun 2002 20:00:24 -0700 (PDT) Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id XAA20101; Tue, 4 Jun 2002 23:00:22 -0400 (EDT) Date: Tue, 4 Jun 2002 23:00:22 -0400 (EDT) From: Nguyen-Tuong Long Le To: freebsd-net@FreeBSD.ORG Cc: Nguyen-Tuong Long Le Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: <20020604194538.J42854-100000@patrocles.silby.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 Hi, On Tue, 4 Jun 2002, Mike Silbersack wrote: > > On Tue, 4 Jun 2002, jayanth wrote: > > > Can you dump the output of netstat -s -p tcp ? > > Checking for listen queue overflows and syncache bucket overflows. > > > > jayanth > Here is the output of "netstat -s -p tcp". tcp: 264136 packets sent 104124 data packets (127937368 bytes) 286 data packets (344573 bytes) retransmitted 0 resends initiated by MTU discovery 147203 ack-only packets (127 delayed) 0 URG only packets 2 window probe packets 3 window update packets 12518 control packets 747675 packets received 85799 acks (for 127931017 bytes) 3247 duplicate acks 0 acks for unsent data 83750 packets (11689418 bytes) received in-sequence 89 completely duplicate packets (5552 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 2 out-of-order packets (796 bytes) 0 packets (0 bytes) of data after window 0 window probes 30312 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 14 connection requests 17243 connection accepts 372055 bad connection attempts 87501 listen queue overflows 17257 connections established (including accepts) 16695 connections closed (including 1 drop) 830 connections updated cached RTT on close 830 connections updated cached RTT variance on close 178 connections updated cached ssthresh on close 0 embryonic connections dropped 85798 segments updated rtt (of 50455 attempts) 201 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 376 correct ACK header predictions 61279 correct data packet header predictions 104747 syncache entries added 189 retransmitted 285 dupsyn 0 dropped 17243 completed 0 bucket overflow 0 cache overflow 3 reset 0 stale 87501 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received > And "netstat -La" too, please. I'm interested in if you're accepting > sockets fast enough. Here is the output of "netstat -La" Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 3/0/8192 *.6789 I wonder why the listen queue overflows when there are so few connections in the queue. The number of listen queue overflows is equal to the number of syncache aborts. Is it a coincidence or are they related? Thanks, -- long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 4 20:19:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d51.as14.nwbl0.wi.voyager.net [169.207.134.51]) by hub.freebsd.org (Postfix) with ESMTP id 67DD937B400 for ; Tue, 4 Jun 2002 20:19:10 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g553KoOA045238; Tue, 4 Jun 2002 22:20:50 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g553Kmjn045235; Tue, 4 Jun 2002 22:20:49 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 4 Jun 2002 22:20:48 -0500 (CDT) From: Mike Silbersack To: Nguyen-Tuong Long Le Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: Message-ID: <20020604221848.J42854-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 Tue, 4 Jun 2002, Nguyen-Tuong Long Le wrote: > Here is the output of "netstat -La" > > Current listen queue sizes (qlen/incqlen/maxqlen) > Proto Listen Local Address > tcp4 3/0/8192 *.6789 > > > I wonder why the listen queue overflows when there are so few > connections in the queue. The number of listen queue overflows > is equal to the number of syncache aborts. Is it a coincidence > or are they related? > > Thanks, > -- long It appears that the primary reason a syncache abort would occur is because the system has run out of sockets. Is kern.ipc.numopensockets approaching kern.ipc.maxsockets? 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 Jun 5 0:13:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id 451E437B400 for ; Wed, 5 Jun 2002 00:13:09 -0700 (PDT) Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id DAA01545 for ; Wed, 5 Jun 2002 03:13:08 -0400 (EDT) Date: Wed, 5 Jun 2002 03:13:07 -0400 (EDT) From: Nguyen-Tuong Long Le To: freebsd-net@FreeBSD.ORG Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: <20020604221848.J42854-100000@patrocles.silby.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 > It appears that the primary reason a syncache abort would occur is because > the system has run out of sockets. Is kern.ipc.numopensockets approaching > kern.ipc.maxsockets? Works like a charm. Thanks! I forgot to set this when I upgraded my system from 4.3 to 4.5 release. My bad. Thanks again! I couldn't find the variable kern.ipc.numopensockets. Does it exist in 4.5 or any earlier release? Thanks again, -- long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 4:24: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id F3E8F37B401 for ; Wed, 5 Jun 2002 04:23:58 -0700 (PDT) Received: from ikostov (helo=localhost) by ShadoW.OTEL.net with local-esmtp (Exim 3.36 #1) id 17FYtP-000LVF-00 for freebsd-net@freebsd.org; Wed, 05 Jun 2002 14:23:55 +0300 Date: Wed, 5 Jun 2002 14:23:55 +0300 (EEST) From: Iasen Kostov To: freebsd-net@freebsd.org Subject: host routes for interface addresses Message-ID: <20020605134856.R82177-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 Hi, Some times I don't need addition of host route when I'm setting iface's address like in this case : xl0: flags=8943 mtu 1500 options=3 inet 212.36.9.113 netmask 0xfffffe00 broadcast 212.36.9.255 ether 00:04:76:1b:cb:72 media: Ethernet autoselect (100baseTX ) status: active xl1: flags=8843 mtu 1500 options=3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:50:da:5b:b2:64 media: Ethernet autoselect (100baseTX ) status: active xl2: flags=8843 mtu 1500 options=3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:16:92 media: Ethernet autoselect (10baseT/UTP) status: active xl3: flags=8843 mtu 1500 options=3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:16:97 media: Ethernet autoselect (none) status: no carrier xl4: flags=8843 mtu 1500 options=3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:10:4b:b8:65:2c media: Ethernet autoselect (10baseT/UTP) status: active xl5: flags=8843 mtu 1500 options=3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:15:83 media: Ethernet autoselect (100baseTX) status: active It works fine (just a warrning) with 4.4 kernel and before, but in 4.5 there is a check for host route addition and if it fail to add a route it also fails to set iface address (ofcourse I've patch it for myself). I need this not just for saving IPs but it's somewhat easier to route just throw iface i not to care about iface IPs. And something more, You know that the router has 1 IP and thats it , don't care on which iface Your are connected right now, it has 1 IP and thats your gateway. This scheme looks a bit like Cisco's "ip unnumbered" interfaces and I don't think it's a bad idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 7: 9:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rack.purplecat.net (rack.purplecat.net [208.133.44.46]) by hub.freebsd.org (Postfix) with ESMTP id 14B2037B400 for ; Wed, 5 Jun 2002 07:08:52 -0700 (PDT) Received: (qmail 56377 invoked from network); 5 Jun 2002 14:09:25 -0000 Received: from unknown (HELO micron) (208.150.25.130) by rack.purplecat.net with SMTP; 5 Jun 2002 14:09:25 -0000 From: "Peter Brezny" To: Subject: currently experiencing some kind of DOS attack? Need help! Date: Wed, 5 Jun 2002 10:09:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 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 think i'm experiencng some kind of DOS attack and I need some help pinpointing the bad guys, and cutting them off/reporting them. I've attached a tcpdump that was captured during the latest initial attack. They are coming at 10 minute intervals. The system under attack is 208.133.44.46 The error i'm getting in /var/log/messages: Jun 5 10:05:51 rack /kernel: m_clalloc failed, consider increase NMBCLUSTERS value Jun 5 10:05:51 rack /kernel: xl0: no memory for rx list -- packet dropped! Any help is much appreciated. Peter Brezny Skyrunner.net 09:56:44.778211 208.133.44.46.4181 > 64.90.1.81.25: . ack 1 win 33304 (DF ) 09:56:44.778289 208.133.44.46.4204 > 216.248.13.163.25: S 583871681:583871681(0) win 65535 (DF) 09:56:44.778363 208.133.44.46.4205 > 216.248.13.163.25: S 990811731:990811731(0) win 65535 (DF) 09:56:44.778437 208.133.44.46.4179 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.778509 208.133.44.46.4195 > 12.107.51.89.25: . ack 1 win 33304 ( DF) 09:56:44.778606 208.133.44.46.4135 > 209.130.32.60.25: P 51:80(29) ack 171 win 33304 (DF) 09:56:44.778685 208.133.44.46.4206 > 209.149.145.242.25: S 4218318996:4218318996(0) win 65535 (DF) 09:56:44.778767 208.133.44.46.4207 > 12.18.94.118.25: S 4233576849:4233576849(0) win 65535 (DF) 09:56:44.778844 208.133.44.46.4208 > 66.7.159.141.25: S 2755991554:2755991554(0) win 65535 (DF) 09:56:44.778931 208.133.44.46.53 > 208.133.44.2.53: 15111+ A? lists.wnpt.net. (32) 09:56:44.779019 208.133.44.46.53 > 208.133.44.2.53: 29381+ A? hammer.bw.vallnet.com. (39) 09:56:44.779303 216.141.198.6.25 > 208.133.44.46.4182: S 2677924182:2677924182(0) ack 3722697590 win 8760 (DF) 09:56:44.779412 208.133.44.46.4182 > 216.141.198.6.25: . ack 1 win 65535 (DF) 09:56:44.780186 209.142.136.248.25 > 208.133.44.46.4173: R 1:1(0) ack 1 win 17520 (DF) 09:56:44.782070 216.183.105.175.25 > 208.133.44.46.4184: S 970622662:970622662(0) ack 611002520 win 5792 (DF) 09:56:44.782230 208.133.44.2.53 > 208.133.44.46.53: 39368 1/2/2 A 12.18.94.118 (131) 09:56:44.782304 208.133.44.46.4184 > 216.183.105.175.25: . ack 1 win 33304 (DF) 09:56:44.782681 24.165.200.11.25 > 208.133.44.46.4191: S 2693592169:2693592169(0) ack 2405761779 win 33304 (DF) 09:56:44.782759 208.133.44.46.4209 > 12.18.94.118.25: S 1124694907:1124694907(0) win 65535 (DF) 09:56:44.782841 208.133.44.46.4191 > 24.165.200.11.25: . ack 1 win 33304 ( DF) 09:56:44.783407 208.133.44.2.53 > 208.133.44.46.53: 20554 1/2/2 A 63.85.209.13 (119) 09:56:44.783735 208.0.133.2.25 > 208.133.44.46.4156: P 94:226(132) ack 26 win 8735 (DF) 09:56:44.783820 208.133.44.46.4210 > 63.85.209.13.25: S 2351909802:2351909802(0) win 65535 (DF) 09:56:44.783973 208.133.44.46.4156 > 208.0.133.2.25: P 26:55(29) ack 226 win 65535 (DF) 09:56:44.784436 216.141.198.5.25 > 208.133.44.46.4189: S 3128014607:3128014607(0) ack 3231361719 win 8760 (DF) 09:56:44.784528 64.90.1.81.25 > 208.133.44.46.4192: S 1792359129:1792359129(0) ack 122564349 win 10136 (DF) 09:56:44.784592 208.133.44.46.4189 > 216.141.198.5.25: . ack 1 win 65535 (DF) 09:56:44.784663 208.133.44.46.4192 > 64.90.1.81.25: . ack 1 win 33304 (DF ) 09:56:44.785415 208.133.44.2.53 > 208.133.44.46.53: 10424* 1/3/4 MX[|domain] 09:56:44.786007 208.133.44.46.53 > 208.133.44.2.53: 9865+ A? mail.milanmirrorexchange.com. (46) 09:56:44.786890 208.133.44.2.53 > 208.133.44.46.53: 10699 1/3/4 A 63.238.52.32 (175) 09:56:44.787268 64.12.137.121.25 > 208.133.44.46.4141: P 383:391(8) ack 55 win 33304 (DF) 09:56:44.787376 208.133.44.46.4211 > 63.238.52.89.25: S 822989022:822989022(0) win 65535 (DF) 09:56:44.787529 208.133.44.46.4141 > 64.12.137.121.25: P 55:83(28) ack 391 win 33304 (DF) 09:56:44.787615 64.12.136.121.25 > 208.133.44.46.4134: . ack 8974 win 32768 09:56:44.787689 216.141.198.7.25 > 208.133.44.46.4183: S 2740973361:2740973361(0) ack 3477352929 win 8760 (DF) 09:56:44.787917 208.133.44.2.53 > 208.133.44.46.53: 32840 1/2/2 A 216.248.18.11 (116) 09:56:44.788420 208.133.44.46.4134 > 64.12.136.121.25: . 12642:13166(524) ack 455 win 33012 (DF) 09:56:44.788914 208.133.44.46.4134 > 64.12.136.121.25: . 13166:13690(524) ack 455 win 33012 (DF) 09:56:44.789469 208.133.44.46.4134 > 64.12.136.121.25: . 13690:14214(524) ack 455 win 33012 (DF) 09:56:44.790024 208.133.44.46.4134 > 64.12.136.121.25: . 14214:14738(524) ack 455 win 33012 (DF) 09:56:44.790577 208.133.44.46.4134 > 64.12.136.121.25: . 14738:15262(524) ack 455 win 33012 (DF) 09:56:44.790706 208.133.44.46.4183 > 216.141.198.7.25: . ack 1 win 65535 (DF) 09:56:44.790936 208.133.44.2.53 > 208.133.44.46.53: 65451 1/2/2 A 216.248.18.12 (116) 09:56:44.791024 208.44.30.252.25 > 208.133.44.46.4188: S 1467598258:1467598258(0) ack 1322705327 win 17520 (DF) 09:56:44.791266 208.133.44.2.53 > 208.133.44.46.53: 30931 1/5/5 A[|domain] 09:56:44.791527 208.133.44.46.4188 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.792030 208.44.30.252.25 > 208.133.44.46.4190: S 2949454116:2949454116(0) ack 2714795533 win 17520 (DF) 09:56:44.792102 216.53.195.54.25 > 208.133.44.46.4200: S 414963656:414963656(0) ack 1200813988 win 24616 (DF) 09:56:44.792208 64.12.137.184.25 > 208.133.44.46.4144: . ack 26 win 33304 (DF) 09:56:44.792296 208.133.44.46.4190 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.792399 208.133.44.46.4200 > 216.53.195.54.25: . ack 1 win 33304 (DF) 09:56:44.792540 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 09:56:44.792614 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 09:56:44.793129 208.133.44.46.4134 > 64.12.136.121.25: . 15262:15786(524) ack 455 win 33012 (DF) 09:56:44.793680 208.133.44.46.4134 > 64.12.136.121.25: . 15786:16310(524) ack 455 win 33012 (DF) 09:56:44.794369 208.133.44.46.4134 > 64.12.136.121.25: . 16310:16834(524) ack 455 win 33012 (DF) 09:56:44.794513 208.133.44.46.53 > 208.133.44.2.53: 49539+ A? mx2.mail.twtelecom.net. (40) 09:56:44.795064 64.12.137.184.25 > 208.133.44.46.4144: P 329:383(54) ack 26 win 33304 (DF) 09:56:44.795225 208.133.44.2.53 > 208.133.44.46.53: 23829* 1/2/2 MX[|domain] 09:56:44.795304 205.152.58.3.25 > 208.133.44.46.4158: . ack 55 win 10136 (DF) 09:56:44.795376 64.12.136.121.25 > 208.133.44.46.4134: . ack 12118 win 32768 09:56:44.795924 208.133.44.46.4134 > 64.12.136.121.25: . 16834:17358(524) ack 455 win 33012 (DF) 09:56:44.796419 208.133.44.46.4134 > 64.12.136.121.25: . 17358:17882(524) ack 455 win 33012 (DF) 09:56:44.796918 208.133.44.46.4134 > 64.12.136.121.25: . 17882:18406(524) ack 455 win 33012 (DF) 09:56:44.797408 208.133.44.46.4134 > 64.12.136.121.25: . 18406:18930(524) ack 455 win 33012 (DF) 09:56:44.797895 208.133.44.46.4134 > 64.12.136.121.25: . 18930:19454(524) ack 455 win 33012 (DF) 09:56:44.797994 208.133.44.46.4144 > 64.12.137.184.25: P 26:55(29) ack 383 win 33304 (DF) 09:56:44.798158 208.133.44.46.53 > 208.133.44.2.53: 54617+ A? lucy.multipro.com. (35) 09:56:44.798233 205.152.58.132.25 > 208.133.44.46.4152: . ack 55 win 10136 (DF) 09:56:44.798307 64.12.136.121.25 > 208.133.44.46.4134: . ack 10546 win 32768 09:56:44.798426 206.102.201.11.25 > 208.133.44.46.4199: S 31341815:31341815(0) ack 329832920 win 8760 (DF) 09:56:44.798559 208.133.44.46.4199 > 206.102.201.11.25: . ack 1 win 65535 (DF) 09:56:44.799241 208.133.44.3.53 > 208.133.44.46.53: 15267* 1/3/3 (191) 09:56:44.800389 208.133.44.3.53 > 208.133.44.46.53: 64791* 1/3/3 (194) 09:56:44.801324 208.133.44.46.4212 > 64.75.1.251.25: S 728130978:728130978(0) win 65535 (DF) 09:56:44.803151 209.130.32.61.25 > 208.133.44.46.4136: . ack 51 win 49152 ( DF) 09:56:44.803364 209.130.32.61.25 > 208.133.44.46.4136: P 82:173(91) ack 51 win 49152 (DF) 09:56:44.803482 152.163.224.26.25 > 208.133.44.46.4143: P 329:383(54) ack 26 win 32768 09:56:44.803601 208.133.44.46.4136 > 209.130.32.61.25: P 51:80(29) ack 173 win 33304 (DF) 09:56:44.803695 208.133.44.46.4143 > 152.163.224.26.25: P 26:55(29) ack 383 win 33012 (DF) 09:56:44.804003 12.153.11.240.25 > 208.133.44.46.4177: P 81:121(40) ack 26 win 16535 (DF) 09:56:44.804192 208.133.44.46.4177 > 12.153.11.240.25: P 26:51(25) ack 121 win 32832 (DF) 09:56:44.804430 63.93.245.3.25 > 208.133.44.46.4198: S 143862244:143862244(0) ack 3178198484 win 16352 09:56:44.804611 208.133.44.46.4198 > 63.93.245.3.25: . ack 1 win 65535 (DF) 09:56:44.804743 208.27.252.10.25 > 208.133.44.46.4176: P 118:188(70) ack 26 win 17495 (DF) 09:56:44.804851 205.152.58.1.25 > 208.133.44.46.4157: . ack 55 win 10136 (DF) 09:56:44.806461 149.48.46.26.25 > 208.133.44.46.4140: P 281:322(41) ack 92 win 64296 (DF) 09:56:44.806696 208.133.44.46.4140 > 149.48.46.26.25: P 92:98(6) ack 322 win 32832 (DF) 09:56:44.807059 208.0.133.2.25 > 208.133.44.46.4175: P 1:94(93) ack 1 win 8760 (DF) 09:56:44.807192 203.176.60.186.25 > 208.133.44.46.4166: P 1:77(76) ack 1 win 24616 (DF) 09:56:44.807284 208.133.44.46.4175 > 208.0.133.2.25: P 1:26(25) ack 94 win 65535 (DF) 09:56:44.807413 208.133.44.46.4166 > 203.176.60.186.25: P 1:26(25) ack 77 win 33304 (DF) 09:56:44.807622 208.45.133.107.25 > 208.133.44.46.4180: P 1:68(67) ack 1 win 5840 (DF) 09:56:44.807809 208.133.44.46.4180 > 208.45.133.107.25: P 1:26(25) ack 68 win 65535 (DF) 09:56:44.808143 208.133.44.46.53 > 208.133.44.2.53: 4340+ ANY? care-communications.com. (41) 09:56:44.809188 204.78.60.100.25 > 208.133.44.46.4150: P 101:131(30) ack 26 win 17495 (DF) 09:56:44.809257 216.145.68.3.25 > 208.133.44.46.4174: S 809889280:809889280(0) ack 2587056518 win 17520 (DF) 09:56:44.809360 207.69.235.6.25 > 208.133.44.46.4138: P 104:133(29) ack 26 win 16535 To: Subject: RE: currently experiencing some kind of DOS attack? Need help! Date: Wed, 5 Jun 2002 11:16:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: 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 Discovered this is not a DOS attack, Thanks for your consideration. Looks like my qmail install is sending things out faster than my network card can handle?... Thanks again, Peter Brezny Skyrunner.net -----Original Message----- From: Peter Brezny [mailto:pbrezny@purplecat.net] Sent: Wednesday, June 05, 2002 10:09 AM To: freebsd-net@freebsd.org Subject: currently experiencing some kind of DOS attack? Need help! I think i'm experiencng some kind of DOS attack and I need some help pinpointing the bad guys, and cutting them off/reporting them. I've attached a tcpdump that was captured during the latest initial attack. They are coming at 10 minute intervals. The system under attack is 208.133.44.46 The error i'm getting in /var/log/messages: Jun 5 10:05:51 rack /kernel: m_clalloc failed, consider increase NMBCLUSTERS value Jun 5 10:05:51 rack /kernel: xl0: no memory for rx list -- packet dropped! Any help is much appreciated. Peter Brezny Skyrunner.net 09:56:44.778211 208.133.44.46.4181 > 64.90.1.81.25: . ack 1 win 33304 (DF ) 09:56:44.778289 208.133.44.46.4204 > 216.248.13.163.25: S 583871681:583871681(0) win 65535 (DF) 09:56:44.778363 208.133.44.46.4205 > 216.248.13.163.25: S 990811731:990811731(0) win 65535 (DF) 09:56:44.778437 208.133.44.46.4179 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.778509 208.133.44.46.4195 > 12.107.51.89.25: . ack 1 win 33304 ( DF) 09:56:44.778606 208.133.44.46.4135 > 209.130.32.60.25: P 51:80(29) ack 171 win 33304 (DF) 09:56:44.778685 208.133.44.46.4206 > 209.149.145.242.25: S 4218318996:4218318996(0) win 65535 (DF) 09:56:44.778767 208.133.44.46.4207 > 12.18.94.118.25: S 4233576849:4233576849(0) win 65535 (DF) 09:56:44.778844 208.133.44.46.4208 > 66.7.159.141.25: S 2755991554:2755991554(0) win 65535 (DF) 09:56:44.778931 208.133.44.46.53 > 208.133.44.2.53: 15111+ A? lists.wnpt.net. (32) 09:56:44.779019 208.133.44.46.53 > 208.133.44.2.53: 29381+ A? hammer.bw.vallnet.com. (39) 09:56:44.779303 216.141.198.6.25 > 208.133.44.46.4182: S 2677924182:2677924182(0) ack 3722697590 win 8760 (DF) 09:56:44.779412 208.133.44.46.4182 > 216.141.198.6.25: . ack 1 win 65535 (DF) 09:56:44.780186 209.142.136.248.25 > 208.133.44.46.4173: R 1:1(0) ack 1 win 17520 (DF) 09:56:44.782070 216.183.105.175.25 > 208.133.44.46.4184: S 970622662:970622662(0) ack 611002520 win 5792 (DF) 09:56:44.782230 208.133.44.2.53 > 208.133.44.46.53: 39368 1/2/2 A 12.18.94.118 (131) 09:56:44.782304 208.133.44.46.4184 > 216.183.105.175.25: . ack 1 win 33304 (DF) 09:56:44.782681 24.165.200.11.25 > 208.133.44.46.4191: S 2693592169:2693592169(0) ack 2405761779 win 33304 (DF) 09:56:44.782759 208.133.44.46.4209 > 12.18.94.118.25: S 1124694907:1124694907(0) win 65535 (DF) 09:56:44.782841 208.133.44.46.4191 > 24.165.200.11.25: . ack 1 win 33304 ( DF) 09:56:44.783407 208.133.44.2.53 > 208.133.44.46.53: 20554 1/2/2 A 63.85.209.13 (119) 09:56:44.783735 208.0.133.2.25 > 208.133.44.46.4156: P 94:226(132) ack 26 win 8735 (DF) 09:56:44.783820 208.133.44.46.4210 > 63.85.209.13.25: S 2351909802:2351909802(0) win 65535 (DF) 09:56:44.783973 208.133.44.46.4156 > 208.0.133.2.25: P 26:55(29) ack 226 win 65535 (DF) 09:56:44.784436 216.141.198.5.25 > 208.133.44.46.4189: S 3128014607:3128014607(0) ack 3231361719 win 8760 (DF) 09:56:44.784528 64.90.1.81.25 > 208.133.44.46.4192: S 1792359129:1792359129(0) ack 122564349 win 10136 (DF) 09:56:44.784592 208.133.44.46.4189 > 216.141.198.5.25: . ack 1 win 65535 (DF) 09:56:44.784663 208.133.44.46.4192 > 64.90.1.81.25: . ack 1 win 33304 (DF ) 09:56:44.785415 208.133.44.2.53 > 208.133.44.46.53: 10424* 1/3/4 MX[|domain] 09:56:44.786007 208.133.44.46.53 > 208.133.44.2.53: 9865+ A? mail.milanmirrorexchange.com. (46) 09:56:44.786890 208.133.44.2.53 > 208.133.44.46.53: 10699 1/3/4 A 63.238.52.32 (175) 09:56:44.787268 64.12.137.121.25 > 208.133.44.46.4141: P 383:391(8) ack 55 win 33304 (DF) 09:56:44.787376 208.133.44.46.4211 > 63.238.52.89.25: S 822989022:822989022(0) win 65535 (DF) 09:56:44.787529 208.133.44.46.4141 > 64.12.137.121.25: P 55:83(28) ack 391 win 33304 (DF) 09:56:44.787615 64.12.136.121.25 > 208.133.44.46.4134: . ack 8974 win 32768 09:56:44.787689 216.141.198.7.25 > 208.133.44.46.4183: S 2740973361:2740973361(0) ack 3477352929 win 8760 (DF) 09:56:44.787917 208.133.44.2.53 > 208.133.44.46.53: 32840 1/2/2 A 216.248.18.11 (116) 09:56:44.788420 208.133.44.46.4134 > 64.12.136.121.25: . 12642:13166(524) ack 455 win 33012 (DF) 09:56:44.788914 208.133.44.46.4134 > 64.12.136.121.25: . 13166:13690(524) ack 455 win 33012 (DF) 09:56:44.789469 208.133.44.46.4134 > 64.12.136.121.25: . 13690:14214(524) ack 455 win 33012 (DF) 09:56:44.790024 208.133.44.46.4134 > 64.12.136.121.25: . 14214:14738(524) ack 455 win 33012 (DF) 09:56:44.790577 208.133.44.46.4134 > 64.12.136.121.25: . 14738:15262(524) ack 455 win 33012 (DF) 09:56:44.790706 208.133.44.46.4183 > 216.141.198.7.25: . ack 1 win 65535 (DF) 09:56:44.790936 208.133.44.2.53 > 208.133.44.46.53: 65451 1/2/2 A 216.248.18.12 (116) 09:56:44.791024 208.44.30.252.25 > 208.133.44.46.4188: S 1467598258:1467598258(0) ack 1322705327 win 17520 (DF) 09:56:44.791266 208.133.44.2.53 > 208.133.44.46.53: 30931 1/5/5 A[|domain] 09:56:44.791527 208.133.44.46.4188 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.792030 208.44.30.252.25 > 208.133.44.46.4190: S 2949454116:2949454116(0) ack 2714795533 win 17520 (DF) 09:56:44.792102 216.53.195.54.25 > 208.133.44.46.4200: S 414963656:414963656(0) ack 1200813988 win 24616 (DF) 09:56:44.792208 64.12.137.184.25 > 208.133.44.46.4144: . ack 26 win 33304 (DF) 09:56:44.792296 208.133.44.46.4190 > 208.44.30.252.25: . ack 1 win 33304 (DF) 09:56:44.792399 208.133.44.46.4200 > 216.53.195.54.25: . ack 1 win 33304 (DF) 09:56:44.792540 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 09:56:44.792614 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 09:56:44.793129 208.133.44.46.4134 > 64.12.136.121.25: . 15262:15786(524) ack 455 win 33012 (DF) 09:56:44.793680 208.133.44.46.4134 > 64.12.136.121.25: . 15786:16310(524) ack 455 win 33012 (DF) 09:56:44.794369 208.133.44.46.4134 > 64.12.136.121.25: . 16310:16834(524) ack 455 win 33012 (DF) 09:56:44.794513 208.133.44.46.53 > 208.133.44.2.53: 49539+ A? mx2.mail.twtelecom.net. (40) 09:56:44.795064 64.12.137.184.25 > 208.133.44.46.4144: P 329:383(54) ack 26 win 33304 (DF) 09:56:44.795225 208.133.44.2.53 > 208.133.44.46.53: 23829* 1/2/2 MX[|domain] 09:56:44.795304 205.152.58.3.25 > 208.133.44.46.4158: . ack 55 win 10136 (DF) 09:56:44.795376 64.12.136.121.25 > 208.133.44.46.4134: . ack 12118 win 32768 09:56:44.795924 208.133.44.46.4134 > 64.12.136.121.25: . 16834:17358(524) ack 455 win 33012 (DF) 09:56:44.796419 208.133.44.46.4134 > 64.12.136.121.25: . 17358:17882(524) ack 455 win 33012 (DF) 09:56:44.796918 208.133.44.46.4134 > 64.12.136.121.25: . 17882:18406(524) ack 455 win 33012 (DF) 09:56:44.797408 208.133.44.46.4134 > 64.12.136.121.25: . 18406:18930(524) ack 455 win 33012 (DF) 09:56:44.797895 208.133.44.46.4134 > 64.12.136.121.25: . 18930:19454(524) ack 455 win 33012 (DF) 09:56:44.797994 208.133.44.46.4144 > 64.12.137.184.25: P 26:55(29) ack 383 win 33304 (DF) 09:56:44.798158 208.133.44.46.53 > 208.133.44.2.53: 54617+ A? lucy.multipro.com. (35) 09:56:44.798233 205.152.58.132.25 > 208.133.44.46.4152: . ack 55 win 10136 (DF) 09:56:44.798307 64.12.136.121.25 > 208.133.44.46.4134: . ack 10546 win 32768 09:56:44.798426 206.102.201.11.25 > 208.133.44.46.4199: S 31341815:31341815(0) ack 329832920 win 8760 (DF) 09:56:44.798559 208.133.44.46.4199 > 206.102.201.11.25: . ack 1 win 65535 (DF) 09:56:44.799241 208.133.44.3.53 > 208.133.44.46.53: 15267* 1/3/3 (191) 09:56:44.800389 208.133.44.3.53 > 208.133.44.46.53: 64791* 1/3/3 (194) 09:56:44.801324 208.133.44.46.4212 > 64.75.1.251.25: S 728130978:728130978(0) win 65535 (DF) 09:56:44.803151 209.130.32.61.25 > 208.133.44.46.4136: . ack 51 win 49152 ( DF) 09:56:44.803364 209.130.32.61.25 > 208.133.44.46.4136: P 82:173(91) ack 51 win 49152 (DF) 09:56:44.803482 152.163.224.26.25 > 208.133.44.46.4143: P 329:383(54) ack 26 win 32768 09:56:44.803601 208.133.44.46.4136 > 209.130.32.61.25: P 51:80(29) ack 173 win 33304 (DF) 09:56:44.803695 208.133.44.46.4143 > 152.163.224.26.25: P 26:55(29) ack 383 win 33012 (DF) 09:56:44.804003 12.153.11.240.25 > 208.133.44.46.4177: P 81:121(40) ack 26 win 16535 (DF) 09:56:44.804192 208.133.44.46.4177 > 12.153.11.240.25: P 26:51(25) ack 121 win 32832 (DF) 09:56:44.804430 63.93.245.3.25 > 208.133.44.46.4198: S 143862244:143862244(0) ack 3178198484 win 16352 09:56:44.804611 208.133.44.46.4198 > 63.93.245.3.25: . ack 1 win 65535 (DF) 09:56:44.804743 208.27.252.10.25 > 208.133.44.46.4176: P 118:188(70) ack 26 win 17495 (DF) 09:56:44.804851 205.152.58.1.25 > 208.133.44.46.4157: . ack 55 win 10136 (DF) 09:56:44.806461 149.48.46.26.25 > 208.133.44.46.4140: P 281:322(41) ack 92 win 64296 (DF) 09:56:44.806696 208.133.44.46.4140 > 149.48.46.26.25: P 92:98(6) ack 322 win 32832 (DF) 09:56:44.807059 208.0.133.2.25 > 208.133.44.46.4175: P 1:94(93) ack 1 win 8760 (DF) 09:56:44.807192 203.176.60.186.25 > 208.133.44.46.4166: P 1:77(76) ack 1 win 24616 (DF) 09:56:44.807284 208.133.44.46.4175 > 208.0.133.2.25: P 1:26(25) ack 94 win 65535 (DF) 09:56:44.807413 208.133.44.46.4166 > 203.176.60.186.25: P 1:26(25) ack 77 win 33304 (DF) 09:56:44.807622 208.45.133.107.25 > 208.133.44.46.4180: P 1:68(67) ack 1 win 5840 (DF) 09:56:44.807809 208.133.44.46.4180 > 208.45.133.107.25: P 1:26(25) ack 68 win 65535 (DF) 09:56:44.808143 208.133.44.46.53 > 208.133.44.2.53: 4340+ ANY? care-communications.com. (41) 09:56:44.809188 204.78.60.100.25 > 208.133.44.46.4150: P 101:131(30) ack 26 win 17495 (DF) 09:56:44.809257 216.145.68.3.25 > 208.133.44.46.4174: S 809889280:809889280(0) ack 2587056518 win 17520 (DF) 09:56:44.809360 207.69.235.6.25 > 208.133.44.46.4138: P 104:133(29) ack 26 win 16535 ; Wed, 5 Jun 2002 10:02:21 -0700 (PDT) Received: from bear.com (localhost [127.0.0.1]) by wafw.bear.com (8.9.3/8.9.2) with SMTP id NAA26630 for ; Wed, 5 Jun 2002 13:00:45 -0400 (EDT) Received: from 147.107.147.26 by whmsxvs2.is.bear.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 13:00:45 -0400 Received: by whmsx9.is.bear.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 13:00:45 -0400 Message-ID: From: "Finan, Charles (Exchange)" To: "'freebsd-net@freebsd.org'" Subject: bind log message question Date: Wed, 5 Jun 2002 13:00:42 -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 I'm running a 4.3R system with the standard bind (8.xxx). I'm getting the following messages in the syslog file a hourly intervals: May 7 19:11:36 fw named[255]: denied update from [192.168.1.6].3217 for "chf3.org" May 7 20:11:36 fw named[255]: denied update from [192.168.1.6].3220 for "chf3.org" May 7 21:11:36 fw named[255]: denied update from [192.168.1.6].3226 for "chf3.org" The box being denied update is a Windoze XP-Home system. Does anyone know what can be causing this message?? (Request for time update???) Thanks, Charlie **************************************************************** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 10: 3:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 4168E37B400; Wed, 5 Jun 2002 10:02:30 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g55H2Mn91698; Wed, 5 Jun 2002 20:02:22 +0300 (EEST) (envelope-from ru) Date: Wed, 5 Jun 2002 20:02:22 +0300 From: Ruslan Ermilov To: Garrett Wollman , Qing Li Cc: net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/37606: genmask, rt_fixchange causes kernel panic Message-ID: <20020605170222.GA90718@sunbay.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Tue, Apr 30, 2002 at 11:13:40AM -0700, Qing Li wrote: > > Creating a route entry with -cloning flag and the -genmask > option causes a kernel panic on 4.5-STABLE. > > The cloned entry created is a network route. The problem > appears to be in route.c, in "rtrequest1" function, where > > if (!(rt->rt_flags & RTF_HOST) && (rt_mask(rt) !=0) > > rnh->rnh_walktree_from(..,rt_fixchange,.) > > This newly created entry is immediately removed inside > rt_fixchange. This invalid "rt" pointer is returned back > to the caller. > > This problem did not show up in the previous version of > the code apparently due to the missing flag check on > RTF_CLONING in the code above, > > if (cmd == RTM_RESOLVE) > > if ((*ret_nrt)->rt_flags & RTF_PRCLONING) (old version) > > new version > if ((*ret_nrt)->rt_flags & (RTF_CLONING & RTF_PRCLONING) > > The rt_parent is not assigned so rt_fixchange returned > immediately in the previous version. > > I am also not sure why rt_fixchange is needed if > cmd is RTM_RESOLVE. > I am not sure as well, and hereby asking the original author. Garrett, what was the intent of adding this code to rtrequest1() in rev. 1.22: /* * We repeat the same procedure from rt_setgate() here because * it doesn't fire when we call it there because the node * hasn't been added to the tree yet. */ if (!(rt->rt_flags & RTF_HOST)) { struct rtfc_arg arg; arg.rnh = rnh; arg.rt0 = rt; rnh->rnh_walktree_from(rnh, rt_key(rt), rt_mask(rt), rt_fixchange, &arg); } We are obviously either adding or cloning heer, why do we need to call rt_fixchange() at all? Moreover, the node is already in the tree. Do we probably need to do this in the RTM_ADD case only, if yes, why? > >How-To-Repeat: > > route add -net 10.2.10.5 -netmask 255.255.0.0 -cloning > -genmask 255.255.255.0 64.81.55.1 > > ping 10.2.10.6 > > >Fix: > > *** route.c.org Tue Apr 30 10:19:47 2002 > --- route.c Tue Apr 30 10:20:49 2002 > *************** > *** 846,851 **** > --- 846,854 ---- > printf("rt_fixchange: rt %p, rt0 %p\n", rt, rt0); > #endif > > + if (rt == rt0) > + return 0; > + > if (!rt->rt_parent || (rt->rt_flags & RTF_PINNED)) { > #ifdef DEBUG > if(rtfcdebug) printf("no parent or pinned\n"); -- 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 Wed Jun 5 10:14:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from rhadamanth.submonkey.net (pc1-card5-0-cust12.cdf.cable.ntl.com [80.3.216.12]) by hub.freebsd.org (Postfix) with ESMTP id 04F9A37B405 for ; Wed, 5 Jun 2002 10:14:52 -0700 (PDT) Received: from setantae by rhadamanth.submonkey.net with local (Exim 3.36 #1) id 17FeMy-0004e9-00; Wed, 05 Jun 2002 18:14:48 +0100 Date: Wed, 5 Jun 2002 18:14:48 +0100 From: Ceri Davies To: "Finan, Charles (Exchange)" Cc: "'freebsd-net@freebsd.org'" Subject: Re: bind log message question Message-ID: <20020605171448.GA17667@submonkey.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Wed, Jun 05, 2002 at 01:00:42PM -0400, Finan, Charles (Exchange) wrote: > I'm running a 4.3R system with the standard bind (8.xxx). > I'm getting the following messages in the syslog file a hourly intervals: > > May 7 19:11:36 fw named[255]: denied update from [192.168.1.6].3217 for > "chf3.org" > May 7 20:11:36 fw named[255]: denied update from [192.168.1.6].3220 for > "chf3.org" > May 7 21:11:36 fw named[255]: denied update from [192.168.1.6].3226 for > "chf3.org" > > The box being denied update is a Windoze XP-Home system. > > Does anyone know what can be causing this message?? (Request for time > update???) Reverse DNS update - check RFC 2316. Ceri -- you can't see when light's so strong you can't see when light is gone To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 11: 7:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from gateway.posi.net (12-236-90-177.client.attbi.com [12.236.90.177]) by hub.freebsd.org (Postfix) with ESMTP id A441A37B405 for ; Wed, 5 Jun 2002 11:07:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.3/8.12.3) with ESMTP id g55I7nM7037341; Wed, 5 Jun 2002 11:07:50 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Wed, 5 Jun 2002 11:07:49 -0700 (PDT) From: Kelly Yancey To: Iasen Kostov Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses In-Reply-To: <20020605134856.R82177-100000@shadowhand.OTEL.net> Message-ID: <20020605104046.J37253-100000@gateway.posi.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 Wed, 5 Jun 2002, Iasen Kostov wrote: > It works fine (just a warrning) with 4.4 kernel and before, but in 4.5 > there is a check for host route addition and if it fail to add a route > it also fails to set iface address (ofcourse I've patch it for myself). > I need this not just for saving IPs but it's somewhat easier to route > just throw iface i not to care about iface IPs. And something more, You > know that the router has 1 IP and thats it , don't care on which iface > Your are connected right now, it has 1 IP and thats your gateway. > This scheme looks a bit like Cisco's "ip unnumbered" interfaces and I > don't think it's a bad idea. > You might want to take a look at Marko Zec's VIPA patches that he posted to -net a few days ago. You should be able to find it in the mailing list archives under the subject "Patch for review: source VIPA". If you have the time to review/test his patches, then perhaps we can get it into a future release of FreeBSD (solving your problem with a viable long-term solution). Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 13:46:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from omta04.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by hub.freebsd.org (Postfix) with ESMTP id 0EAC137B407; Wed, 5 Jun 2002 13:45:43 -0700 (PDT) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta04.mta.everyone.net (Postfix) with ESMTP id DE74F4FD3D; Wed, 5 Jun 2002 13:45:42 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id AEE962756; Wed, 5 Jun 2002 13:45:42 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Wed, 5 Jun 2002 13:45:42 -0700 (PDT) From: Muhammad Faisal Rauf Danka To: "Peter Brezny" , freebsd-net@freebsd.org Cc: freebsd-security@freebsd.org Subject: Re: currently experiencing some kind of DOS attack? Need help! Reply-To: mfrd@attitudex.com X-Originating-Ip: [202.5.134.230] Message-Id: <20020605204542.AEE962756@sitemail.everyone.net> 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 It looks like either distributed port scanning via source port 25. Or maybe a stealth scan, which send spoofed syn packets along with the real sender's packet in order to confuse the victim that who actually scanned. Are you using any firewall? and proper mailing list for such an event is freebsd-security@freebsd.org Regards, --------- Muhammad Faisal Rauf Danka Chief Technology Officer Gem Internet Services (Pvt) Ltd. web: www.gem.net.pk Vice President Pakistan Computer Emergency Responce Team (PakCERT) web: www.pakcert.org Chief Security Analyst Applied Technology Research Center (ATRC) web: www.atrc.net.pk --- "Peter Brezny" wrote: >I think i'm experiencng some kind of DOS attack and I need some help >pinpointing the bad guys, and cutting them off/reporting them. > >I've attached a tcpdump that was captured during the latest initial attack. >They are coming at 10 minute intervals. > >The system under attack is 208.133.44.46 > >The error i'm getting in /var/log/messages: >Jun 5 10:05:51 rack /kernel: m_clalloc failed, consider increase >NMBCLUSTERS value >Jun 5 10:05:51 rack /kernel: xl0: no memory for rx list -- packet dropped! > >Any help is much appreciated. > >Peter Brezny >Skyrunner.net > > >09:56:44.778211 208.133.44.46.4181 > 64.90.1.81.25: . ack 1 win 33304 > (DF >) >09:56:44.778289 208.133.44.46.4204 > 216.248.13.163.25: S >583871681:583871681(0) win 65535 ,nop,nop,timestamp 119714228 0> (DF) >09:56:44.778363 208.133.44.46.4205 > 216.248.13.163.25: S >990811731:990811731(0) win 65535 ,nop,nop,timestamp 119714228 0> (DF) >09:56:44.778437 208.133.44.46.4179 > 208.44.30.252.25: . ack 1 win 33304 > (DF) >09:56:44.778509 208.133.44.46.4195 > 12.107.51.89.25: . ack 1 win 33304 > ( >DF) >09:56:44.778606 208.133.44.46.4135 > 209.130.32.60.25: P 51:80(29) ack 171 >win 33304 9191680> (DF) >09:56:44.778685 208.133.44.46.4206 > 209.149.145.242.25: S >4218318996:4218318996(0) win 65535 e 1,nop,nop,timestamp 119714228 0> (DF) >09:56:44.778767 208.133.44.46.4207 > 12.18.94.118.25: S >4233576849:4233576849(0) win 65535 ,nop,nop,timestamp 119714228 0> (DF) >09:56:44.778844 208.133.44.46.4208 > 66.7.159.141.25: S >2755991554:2755991554(0) win 65535 ,nop,nop,timestamp 119714228 0> (DF) >09:56:44.778931 208.133.44.46.53 > 208.133.44.2.53: 15111+ A? >lists.wnpt.net. (32) >09:56:44.779019 208.133.44.46.53 > 208.133.44.2.53: 29381+ A? >hammer.bw.vallnet.com. (39) >09:56:44.779303 216.141.198.6.25 > 208.133.44.46.4182: S >2677924182:2677924182(0) ack 3722697590 win 8760 60> (DF) >09:56:44.779412 208.133.44.46.4182 > 216.141.198.6.25: . ack 1 win 65535 >(DF) >09:56:44.780186 209.142.136.248.25 > 208.133.44.46.4173: R 1:1(0) ack 1 win >17520 (DF) >09:56:44.782070 216.183.105.175.25 > 208.133.44.46.4184: S >970622662:970622662(0) ack 611002520 win 5792 0,nop,nop,timestamp 814152703 119714222,nop,wscale 0> (DF) >09:56:44.782230 208.133.44.2.53 > 208.133.44.46.53: 39368 1/2/2 A >12.18.94.118 (131) >09:56:44.782304 208.133.44.46.4184 > 216.183.105.175.25: . ack 1 win 33304 >> (DF) >09:56:44.782681 24.165.200.11.25 > 208.133.44.46.4191: S >2693592169:2693592169(0) ack 2405761779 win 33304 op,timestamp 53982485 119714224,nop,wscale 1,mss 1460> (DF) >09:56:44.782759 208.133.44.46.4209 > 12.18.94.118.25: S >1124694907:1124694907(0) win 65535 ,nop,nop,timestamp 119714229 0> (DF) >09:56:44.782841 208.133.44.46.4191 > 24.165.200.11.25: . ack 1 win 33304 > ( >DF) >09:56:44.783407 208.133.44.2.53 > 208.133.44.46.53: 20554 1/2/2 A >63.85.209.13 (119) >09:56:44.783735 208.0.133.2.25 > 208.133.44.46.4156: P 94:226(132) ack 26 >win 8735 (DF) >09:56:44.783820 208.133.44.46.4210 > 63.85.209.13.25: S >2351909802:2351909802(0) win 65535 ,nop,nop,timestamp 119714229 0> (DF) >09:56:44.783973 208.133.44.46.4156 > 208.0.133.2.25: P 26:55(29) ack 226 win >65535 (DF) >09:56:44.784436 216.141.198.5.25 > 208.133.44.46.4189: S >3128014607:3128014607(0) ack 3231361719 win 8760 60> (DF) >09:56:44.784528 64.90.1.81.25 > 208.133.44.46.4192: S >1792359129:1792359129(0) ack 122564349 win 10136 imestamp 348692855 119714224,nop,wscale 0,mss 1460> (DF) >09:56:44.784592 208.133.44.46.4189 > 216.141.198.5.25: . ack 1 win 65535 >(DF) >09:56:44.784663 208.133.44.46.4192 > 64.90.1.81.25: . ack 1 win 33304 > (DF >) >09:56:44.785415 208.133.44.2.53 > 208.133.44.46.53: 10424* 1/3/4 >MX[|domain] >09:56:44.786007 208.133.44.46.53 > 208.133.44.2.53: 9865+ A? >mail.milanmirrorexchange.com. (46) >09:56:44.786890 208.133.44.2.53 > 208.133.44.46.53: 10699 1/3/4 A >63.238.52.32 (175) >09:56:44.787268 64.12.137.121.25 > 208.133.44.46.4141: P 383:391(8) ack 55 >win 33304 119714225> (DF) >09:56:44.787376 208.133.44.46.4211 > 63.238.52.89.25: S >822989022:822989022(0) win 65535 op,nop,timestamp 119714229 0> (DF) >09:56:44.787529 208.133.44.46.4141 > 64.12.137.121.25: P 55:83(28) ack 391 >win 33304 243325248> (DF) >09:56:44.787615 64.12.136.121.25 > 208.133.44.46.4134: . ack 8974 win 32768 >25> >09:56:44.787689 216.141.198.7.25 > 208.133.44.46.4183: S >2740973361:2740973361(0) ack 3477352929 win 8760 60> (DF) >09:56:44.787917 208.133.44.2.53 > 208.133.44.46.53: 32840 1/2/2 A >216.248.18.11 (116) >09:56:44.788420 208.133.44.46.4134 > 64.12.136.121.25: . 12642:13166(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.788914 208.133.44.46.4134 > 64.12.136.121.25: . 13166:13690(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.789469 208.133.44.46.4134 > 64.12.136.121.25: . 13690:14214(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.790024 208.133.44.46.4134 > 64.12.136.121.25: . 14214:14738(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.790577 208.133.44.46.4134 > 64.12.136.121.25: . 14738:15262(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.790706 208.133.44.46.4183 > 216.141.198.7.25: . ack 1 win 65535 >(DF) >09:56:44.790936 208.133.44.2.53 > 208.133.44.46.53: 65451 1/2/2 A >216.248.18.12 (116) >09:56:44.791024 208.44.30.252.25 > 208.133.44.46.4188: S >1467598258:1467598258(0) ack 1322705327 win 17520 460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) >09:56:44.791266 208.133.44.2.53 > 208.133.44.46.53: 30931 1/5/5 A[|domain] >09:56:44.791527 208.133.44.46.4188 > 208.44.30.252.25: . ack 1 win 33304 > (DF) >09:56:44.792030 208.44.30.252.25 > 208.133.44.46.4190: S >2949454116:2949454116(0) ack 2714795533 win 17520 460,nop,wscale 0,nop,nop,timestamp 0 0> (DF) >09:56:44.792102 216.53.195.54.25 > 208.133.44.46.4200: S >414963656:414963656(0) ack 1200813988 win 24616 ,timestamp 248050614 119714226,nop,wscale 0,mss 1460> (DF) >09:56:44.792208 64.12.137.184.25 > 208.133.44.46.4144: . ack 26 win 33304 > > (DF) >09:56:44.792296 208.133.44.46.4190 > 208.44.30.252.25: . ack 1 win 33304 > (DF) >09:56:44.792399 208.133.44.46.4200 > 216.53.195.54.25: . ack 1 win 33304 > >(DF) >09:56:44.792540 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 >225> >09:56:44.792614 64.12.136.121.25 > 208.133.44.46.4134: . ack 10022 win 32768 >225> >09:56:44.793129 208.133.44.46.4134 > 64.12.136.121.25: . 15262:15786(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.793680 208.133.44.46.4134 > 64.12.136.121.25: . 15786:16310(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.794369 208.133.44.46.4134 > 64.12.136.121.25: . 16310:16834(524) >ack 455 win 33012 9714230 1156210109> (DF) >09:56:44.794513 208.133.44.46.53 > 208.133.44.2.53: 49539+ A? >mx2.mail.twtelecom.net. (40) >09:56:44.795064 64.12.137.184.25 > 208.133.44.46.4144: P 329:383(54) ack 26 >win 33304 1 119714225> (DF) >09:56:44.795225 208.133.44.2.53 > 208.133.44.46.53: 23829* 1/2/2 >MX[|domain] >09:56:44.795304 205.152.58.3.25 > 208.133.44.46.4158: . ack 55 win 10136 > >(DF) >09:56:44.795376 64.12.136.121.25 > 208.133.44.46.4134: . ack 12118 win 32768 >225> >09:56:44.795924 208.133.44.46.4134 > 64.12.136.121.25: . 16834:17358(524) >ack 455 win 33012 9714230 1156210110> (DF) >09:56:44.796419 208.133.44.46.4134 > 64.12.136.121.25: . 17358:17882(524) >ack 455 win 33012 9714230 1156210110> (DF) >09:56:44.796918 208.133.44.46.4134 > 64.12.136.121.25: . 17882:18406(524) >ack 455 win 33012 9714230 1156210110> (DF) >09:56:44.797408 208.133.44.46.4134 > 64.12.136.121.25: . 18406:18930(524) >ack 455 win 33012 9714230 1156210110> (DF) >09:56:44.797895 208.133.44.46.4134 > 64.12.136.121.25: . 18930:19454(524) >ack 455 win 33012 9714230 1156210110> (DF) >09:56:44.797994 208.133.44.46.4144 > 64.12.137.184.25: P 26:55(29) ack 383 >win 33304 187499961> (DF) >09:56:44.798158 208.133.44.46.53 > 208.133.44.2.53: 54617+ A? >lucy.multipro.com. (35) >09:56:44.798233 205.152.58.132.25 > 208.133.44.46.4152: . ack 55 win 10136 >> (DF) >09:56:44.798307 64.12.136.121.25 > 208.133.44.46.4134: . ack 10546 win 32768 >225> >09:56:44.798426 206.102.201.11.25 > 208.133.44.46.4199: S >31341815:31341815(0) ack 329832920 win 8760 >(DF) >09:56:44.798559 208.133.44.46.4199 > 206.102.201.11.25: . ack 1 win 65535 >(DF) >09:56:44.799241 208.133.44.3.53 > 208.133.44.46.53: 15267* 1/3/3 (191) >09:56:44.800389 208.133.44.3.53 > 208.133.44.46.53: 64791* 1/3/3 (194) >09:56:44.801324 208.133.44.46.4212 > 64.75.1.251.25: S >728130978:728130978(0) win 65535 p,nop,timestamp 119714231 0> (DF) >09:56:44.803151 209.130.32.61.25 > 208.133.44.46.4136: . ack 51 win 49152 > ( >DF) >09:56:44.803364 209.130.32.61.25 > 208.133.44.46.4136: P 82:173(91) ack 51 >win 49152 19714221> (DF) >09:56:44.803482 152.163.224.26.25 > 208.133.44.46.4143: P 329:383(54) ack 26 >win 32768 985 119714223> >09:56:44.803601 208.133.44.46.4136 > 209.130.32.61.25: P 51:80(29) ack 173 >win 33304 7067072> (DF) >09:56:44.803695 208.133.44.46.4143 > 152.163.224.26.25: P 26:55(29) ack 383 >win 33012 1 1156952985> (DF) >09:56:44.804003 12.153.11.240.25 > 208.133.44.46.4177: P 81:121(40) ack 26 >win 16535 119714228> (DF) >09:56:44.804192 208.133.44.46.4177 > 12.153.11.240.25: P 26:51(25) ack 121 >win 32832 41316743> (DF) >09:56:44.804430 63.93.245.3.25 > 208.133.44.46.4198: S >143862244:143862244(0) ack 3178198484 win 16352 >09:56:44.804611 208.133.44.46.4198 > 63.93.245.3.25: . ack 1 win 65535 (DF) >09:56:44.804743 208.27.252.10.25 > 208.133.44.46.4176: P 118:188(70) ack 26 >win 17495 119714228> (DF) >09:56:44.804851 205.152.58.1.25 > 208.133.44.46.4157: . ack 55 win 10136 > >(DF) >09:56:44.806461 149.48.46.26.25 > 208.133.44.46.4140: P 281:322(41) ack 92 >win 64296 119714227> (DF) >09:56:44.806696 208.133.44.46.4140 > 149.48.46.26.25: P 92:98(6) ack 322 win >32832 30419760> (DF) >09:56:44.807059 208.0.133.2.25 > 208.133.44.46.4175: P 1:94(93) ack 1 win >8760 (DF) >09:56:44.807192 203.176.60.186.25 > 208.133.44.46.4166: P 1:77(76) ack 1 win >24616 19714218> (DF) >09:56:44.807284 208.133.44.46.4175 > 208.0.133.2.25: P 1:26(25) ack 94 win >65535 (DF) >09:56:44.807413 208.133.44.46.4166 > 203.176.60.186.25: P 1:26(25) ack 77 >win 33304 396223055> (DF) >09:56:44.807622 208.45.133.107.25 > 208.133.44.46.4180: P 1:68(67) ack 1 win >5840 (DF) >09:56:44.807809 208.133.44.46.4180 > 208.45.133.107.25: P 1:26(25) ack 68 >win 65535 (DF) >09:56:44.808143 208.133.44.46.53 > 208.133.44.2.53: 4340+ ANY? >care-communications.com. (41) >09:56:44.809188 204.78.60.100.25 > 208.133.44.46.4150: P 101:131(30) ack 26 >win 17495 119714225> (DF) >09:56:44.809257 216.145.68.3.25 > 208.133.44.46.4174: S >809889280:809889280(0) ack 2587056518 win 17520 ,wscale 0,eol> (DF) >09:56:44.809360 207.69.235.6.25 > 208.133.44.46.4138: P 104:133(29) ack 26 >win 16535 30245 packets received by filter >4276 packets dropped by kernel > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message _____________________________________________________________ --------------------------- [ATTITUDEX.COM] http://www.attitudex.com/ --------------------------- _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 5 20:17:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from leaf.lumiere.net (leaf.lumiere.net [208.44.192.100]) by hub.freebsd.org (Postfix) with ESMTP id BB7DC37B40A for ; Wed, 5 Jun 2002 20:17:47 -0700 (PDT) Received: by leaf.lumiere.net (Postfix, from userid 1082) id 9B24ACD25; Wed, 5 Jun 2002 20:17:47 -0700 (PDT) Date: Wed, 5 Jun 2002 20:17:47 -0700 From: Derrick John Klise To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: currently experiencing some kind of DOS attack? Need help! Message-ID: <20020605201747.C86927@leaf.lumiere.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from peter@skyrunner.net on Wed, Jun 05, 2002 at 11:16:06AM -0400 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, Jun 05, 2002 at 11:16:06AM -0400, Peter Brezny wrote: > Discovered this is not a DOS attack, Thanks for your consideration. > > Looks like my qmail install is sending things out faster than my network > card can handle?... > > Thanks again, > > Peter Brezny > Skyrunner.net > > Jun 5 10:05:51 rack /kernel: m_clalloc failed, consider increase > NMBCLUSTERS value You are running out of MBUFs; the memory set aside for networking in the kernel. Please see http://www.freebsd.org/handbook/configtuning-kernel-limits.html (6.10.2 Network Limits) for information regarding the NMBCLUSTERS option in the kernel configuration file. -- Derrick John Klise "I went into a general store, and they wouldn't sell me anything specific". -- Steven Wright To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 2:24:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id 878EF37B406 for ; Thu, 6 Jun 2002 02:24:53 -0700 (PDT) Received: from my.egorovv.net.attbi.com ([12.235.54.40]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020606092452.TVGH3995.sccrmhc01.attbi.com@my.egorovv.net.attbi.com> for ; Thu, 6 Jun 2002 09:24:52 +0000 To: freebsd-net@freebsd.org Subject: IP_MULTICAST_LOOP From: Vadim Egorov Date: Thu, 06 Jun 2002 02:24:47 -0700 Message-ID: <86vg8wu5cw.fsf@my.egorovv.net> Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 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 guys! I'm playing with multicasting (-stable), and I want to disable looping back my outgoing packets setting IP_MULTICAST_LOOP option to 0 but it doen't have any effect. My app is listening to the same group it is casting. After some grepping I came across some code in netinet/ip_output.c: (imo == NULL || imo->imo_multicast_loop)) { /* * If we belong to the destination multicast group * on the outgoing interface, and the caller did not * forbid loopback, loop back a copy. */ The comment says 'and' but the code says '||' -- looks like an error to me. Except this I've got no idea what it means - does it make amy sence? -- Thanks, Vadim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 3:51:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 39A0737B400 for ; Thu, 6 Jun 2002 03:51:28 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g56ApQE8026849 for ; Thu, 6 Jun 2002 12:51:26 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Thu, 6 Jun 2002 12:51:26 +0200 From: Christophe Prevotaux To: net@freebsd.org Subject: [HELP] IPless VLAN interfaces Message-Id: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 have a small problem I can't seem to be able to solve on FreeBSD 4-STABLE. I want to setup : - an interface fxp0 with an IP address with a /24 netmask - on this interface fxp0 I set up vlan0 vlan1 vlan2 - each vlan does not have an IP - I setup a route with the -iface option that point to each vlan repesctively on the other side I setup : machines behind each VLAN port each machine has an IP with a /24 netmask the setup works (ie: freebsd does not complain) however pinging a machine does not work so does any other type of traffic this does not work under FreeBSD , however when I do the same thing with Linux it does work. I believe there must be a way to do this under FreeBSD but I can't figure it out. Could someone help me or tell me what I did wrong ? -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 4:36:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id EA13837B406 for ; Thu, 6 Jun 2002 04:36:09 -0700 (PDT) Received: from ikostov (helo=localhost) by ShadoW.OTEL.net with local-esmtp (Exim 3.36 #1) id 17Fuuy-00078X-00; Thu, 06 Jun 2002 13:55:00 +0300 Date: Thu, 6 Jun 2002 13:55:00 +0300 (EEST) From: Iasen Kostov To: Marko Zec Cc: freebsd-net@freebsd.org Subject: Re: Patch for review: source VIPA In-Reply-To: <20020606135057.D26239-200000@shadowhand.OTEL.net> Message-ID: <20020606135202.M27399-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 > Here is an configuration example: > > vmbsd# routed > vmbsd# ifconfig > lnc0: flags=8843 mtu 1500 > inet 192.168.201.143 netmask 0xffffff00 broadcast > 192.168.201.255 > ether 00:50:56:ac:c9:7a > lnc1: flags=8843 mtu 1500 > inet 192.168.202.143 netmask 0xffffff00 broadcast > 192.168.202.255 > ether 00:50:56:ac:c9:8c > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > vipa0: flags=61 mtu 1500 > inet 192.168.1.1 netmask 0xffffffff > vmbsd# sysctl net.inet.ip.sourcevipa > net.inet.ip.sourcevipa: none > vmbsd# sysctl net.inet.ip.sourcevipa=192.168.1.1 > net.inet.ip.sourcevipa: none -> 192.168.1.1 > vmbsd# > vmbsd# telnet 192.168.201.10 > [cut] > %who am i > marko ttyp2 Jun 5 01:37 (192.168.1.1) > > Have fun! > What will happen if I try arpresolve on 192.168.1.1 when I'm in 192.168.1.0/24 net ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 4:36:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id CEFE137B403 for ; Thu, 6 Jun 2002 04:36:39 -0700 (PDT) Received: from ikostov (helo=localhost) by ShadoW.OTEL.net with local-esmtp (Exim 3.36 #1) id 17FvXx-0007I6-00; Thu, 06 Jun 2002 14:35:17 +0300 Date: Thu, 6 Jun 2002 14:35:17 +0300 (EEST) From: Iasen Kostov To: Kelly Yancey Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses In-Reply-To: <20020606135607.V26239-100000@shadowhand.OTEL.net> Message-ID: <20020606140015.B27474-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 > You might want to take a look at Marko Zec's VIPA patches that he posted to > -net a few days ago. You should be able to find it in the mailing list > archives under the subject "Patch for review: source VIPA". > If you have the time to review/test his patches, then perhaps we can get > it into a future release of FreeBSD (solving your problem with a viable > long-term solution). Thanks, > > Kelly > kbyanc@{posi.net,FreeBSD.org} > It will work only if I can arpresolv VIPA and ofcourse resolve it to the right iface lladdr. In other hand we could set same lladdr on all ethernet ifaces. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 5:39:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by hub.freebsd.org (Postfix) with SMTP id 5D82C37B407 for ; Thu, 6 Jun 2002 05:39:02 -0700 (PDT) Received: (qmail 17499 invoked by uid 1031); 6 Jun 2002 12:29:37 -0000 Date: Thu, 6 Jun 2002 12:29:37 +0000 From: Bruce M Simpson To: Barry Irwin Cc: freebsd-net@freebsd.org Subject: Re: GRE on 4.x Message-ID: <20020606122937.B26888@spc.org> Mail-Followup-To: Bruce M Simpson , Barry Irwin , freebsd-net@freebsd.org References: <20020603125202.F43867@itouchlabs.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: <20020603125202.F43867@itouchlabs.com>; from bvi@itouchlabs.com on Mon, Jun 03, 2002 at 12:52:02PM +0200 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 Barry, I have a working GRE driver (tested against 4.5-RELEASE) which we are using as part of Consume (www.consume.net). I would be happy to post the code publicly for peer review, as I'd like to contribute it to FreeBSD. Regards, BMS. On Mon, Jun 03, 2002 at 12:52:02PM +0200, Barry Irwin wrote: > Hi All > > I'm trying to integrate with a business aprner here who have a requirement > we use GRE tunnel inside of IPSEC for a number of reasons. While the gif(4) > device provides IPIP tunneling (proto 4) this doesnt work when the remote > side is expecting true GRE (proto 47). > > Has any one had any experiance working with GRE tunnels under FBSD. I have > tried the following two resources I found but not much success on either. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 6:46:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 4BCA637B426 for ; Thu, 6 Jun 2002 06:45:56 -0700 (PDT) Received: from tel.fer.hr (zg07-074.dialin.iskon.hr [213.191.150.75]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g56DjZg24980; Thu, 6 Jun 2002 15:45:37 +0200 (MEST) Message-ID: <3CFF6761.64ACBAE9@tel.fer.hr> Date: Thu, 06 Jun 2002 15:45:05 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Iasen Kostov Cc: Kelly Yancey , freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses References: <20020606140015.B27474-100000@shadowhand.OTEL.net> 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 Iasen Kostov wrote: > > You might want to take a look at Marko Zec's VIPA patches that he posted to > > -net a few days ago. You should be able to find it in the mailing list > > archives under the subject "Patch for review: source VIPA". > > > It will work only if I can arpresolv VIPA and ofcourse resolve it to the > right iface lladdr. In other hand we could set same lladdr on all ethernet > ifaces. The VIPA interface is an internal loopback, aka "virtual", as its name implies. Therefore it doesn't have an underlying link layer, so you can't do ARP on VIPA. The idea is to dynamically advertise this internal address to the outer world, so that in case one phy ifc would go down, the VIPA could still remain reachable via an alternative path/interface. To accomplish this goal you need to run a routing protocol - in my setup the plain old RIP 1 / routed combination worked just fine, although this was just an example... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 6:56:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 3FD6537B404 for ; Thu, 6 Jun 2002 06:56:39 -0700 (PDT) Received: from tel.fer.hr (zg07-074.dialin.iskon.hr [213.191.150.75]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g56Duag15052 for ; Thu, 6 Jun 2002 15:56:37 +0200 (MEST) Message-ID: <3CFF69FA.A1397E90@tel.fer.hr> Date: Thu, 06 Jun 2002 15:56:10 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Patch for review: source VIPA References: <20020606135202.M27399-100000@shadowhand.OTEL.net> 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 Iasen Kostov wrote: > > Here is an configuration example: > > > > vmbsd# routed > > vmbsd# ifconfig > > lnc0: flags=8843 mtu 1500 > > inet 192.168.201.143 netmask 0xffffff00 broadcast > > 192.168.201.255 > > ether 00:50:56:ac:c9:7a > > lnc1: flags=8843 mtu 1500 > > inet 192.168.202.143 netmask 0xffffff00 broadcast > > 192.168.202.255 > > ether 00:50:56:ac:c9:8c > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > vipa0: flags=61 mtu 1500 > > inet 192.168.1.1 netmask 0xffffffff > > vmbsd# sysctl net.inet.ip.sourcevipa > > net.inet.ip.sourcevipa: none > > vmbsd# sysctl net.inet.ip.sourcevipa=192.168.1.1 > > net.inet.ip.sourcevipa: none -> 192.168.1.1 > > vmbsd# > > vmbsd# telnet 192.168.201.10 > > [cut] > > %who am i > > marko ttyp2 Jun 5 01:37 (192.168.1.1) > > > > Have fun! > > > > What will happen if I try arpresolve on 192.168.1.1 when I'm in > 192.168.1.0/24 net ? Nothing - 192.168.1.1 (VIPA) internal interface is _virtual_, so it won't ARP. You need to route it. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 6:58:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from aline.bs2.com.br (aline.bs2.com.br [200.203.159.61]) by hub.freebsd.org (Postfix) with ESMTP id 944DA37B404 for ; Thu, 6 Jun 2002 06:58:13 -0700 (PDT) Received: from aline.bs2.com.br (IDENT:gpt@localhost [127.0.0.1]) by aline.bs2.com.br (8.12.3/8.12.3) with ESMTP id g56Dw09D089702 for ; Thu, 6 Jun 2002 10:58:00 -0300 (BRT) (envelope-from tirloni@aline.bs2.com.br) Received: (from tirloni@localhost) by aline.bs2.com.br (8.12.3/8.12.3/Submit) id g56Dw0A8089649 for freebsd-net@freebsd.org; Thu, 6 Jun 2002 10:58:00 -0300 (BRT) Date: Thu, 6 Jun 2002 10:58:00 -0300 From: "Giovanni P. Tirloni" To: freebsd-net@freebsd.org Subject: lnc device driver errors Message-ID: <20020606105800.F48420@aline.bs2.com.br> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Info: http://www.tirloni.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 Hi, I have a box with three lnc cards and I'm getting these two errors very often: /kernel: lnc0: Babble error - more than 1519 bytes transmitted /kernel: lnc0: Framing error The man page says the lnc driver is one of the most verbose drivers, should I be worried about these messages? Do they happen with other drivers but they don't show ? They look bad :) This is 4.5-RELEASE. - Giovanni To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 7:30:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 682F037B409 for ; Thu, 6 Jun 2002 07:30:12 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17FyH6-0008hz-00; Thu, 06 Jun 2002 18:30:04 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Christophe Prevotaux Cc: "net@freebsd.org" In-Reply-To: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 18:30:04 +0400 Message-Id: <1023373804.470.20.camel@vbook.express.ru> Mime-Version: 1.0 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 =D0=92 Thu, 06.06.2002, =D0=B2 14:51, Christophe Prevotaux =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BB: > Hello >=20 > I have a small problem I can't seem to be able to solve on > FreeBSD 4-STABLE. >=20 > I want to setup : >=20 > - an interface fxp0 with an IP address with a /24 netmask=20 > - on this interface fxp0 I set up vlan0 vlan1 vlan2=20 > - each vlan does not have an IP=20 > - I setup a route with the -iface option that point to each vlan > repesctively >=20 > on the other side >=20 > I setup : > machines behind each VLAN port=20 > each machine has an IP with a /24 netmask >=20 >=20 >=20 > the setup works (ie: freebsd does not complain)=20 > however pinging a machine does not work so does any other type of > traffic this does not work under FreeBSD , however when I do the same > thing with Linux it does work. I believe there must be a way to=20 > do this under FreeBSD but I can't figure it out.=20 >=20 > Could someone help me or tell me what I did wrong ?=20 first try to specify source address to ping # ping -S 1.1.1.1 dest where 1.1.1.1 - address on fxp0 and you can set on your vlanX interfaces same addreses ad on your fxp0 with netmask 255.255.255.255 # ifconfig fxp0 1.1.1.1/24 # ifconfig vlan0 1.1.1.1 # ifconfig vlan1 1.1.1.1 # ifconfig vlan2 1.1.1.1 >=20 > -- > =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 > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 > 3 All=C3=A9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 =20 > FRANCE HEXANET Network Operation Center =20 > =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 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 7:49:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id A06FC37B403 for ; Thu, 6 Jun 2002 07:49:30 -0700 (PDT) Received: from tel.fer.hr (zg07-146.dialin.iskon.hr [213.191.150.147]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g56En6g26382; Thu, 6 Jun 2002 16:49:07 +0200 (MEST) Message-ID: <3CFF7644.F4F5CC1@tel.fer.hr> Date: Thu, 06 Jun 2002 16:48:36 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir B. Grebenschikov" Cc: Christophe Prevotaux , "net@freebsd.org" Subject: Re: [HELP] IPless VLAN interfaces References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> 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 "Vladimir B. Grebenschikov" wrote: > [snip] > first try to specify source address to ping > > # ping -S 1.1.1.1 dest > > where 1.1.1.1 - address on fxp0 > > and you can set on your vlanX interfaces same addreses ad on your fxp0 > with netmask 255.255.255.255 > > # ifconfig fxp0 1.1.1.1/24 > # ifconfig vlan0 1.1.1.1 > # ifconfig vlan1 1.1.1.1 > # ifconfig vlan2 1.1.1.1 This will never work - you can't have the same IP address/mask on more than one interface. What OS are you running? Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 7:53:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 82FCF37B401 for ; Thu, 6 Jun 2002 07:53:39 -0700 (PDT) Received: from ikostov (helo=localhost) by ShadoW.OTEL.net with local-esmtp (Exim 3.36 #1) id 17Fydl-0008K4-00; Thu, 06 Jun 2002 17:53:29 +0300 Date: Thu, 6 Jun 2002 17:53:29 +0300 (EEST) From: Iasen Kostov To: Marko Zec Cc: Kelly Yancey , Subject: Re: host routes for interface addresses In-Reply-To: <3CFF6761.64ACBAE9@tel.fer.hr> Message-ID: <20020606173742.Q30573-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 Thu, 6 Jun 2002, Marko Zec wrote: > Iasen Kostov wrote: > > > > You might want to take a look at Marko Zec's VIPA patches that he posted to > > > -net a few days ago. You should be able to find it in the mailing list > > > archives under the subject "Patch for review: source VIPA". > > > > > It will work only if I can arpresolv VIPA and ofcourse resolve it to the > > right iface lladdr. In other hand we could set same lladdr on all ethernet > > ifaces. > > The VIPA interface is an internal loopback, aka "virtual", as its name implies. > Therefore it doesn't have an underlying link layer, so you can't do ARP on VIPA. > The idea is to dynamically advertise this internal address to the outer world, so > that in case one phy ifc would go down, the VIPA could still remain reachable via > an alternative path/interface. To accomplish this goal you need to run a routing > protocol - in my setup the plain old RIP 1 / routed combination worked just fine, > although this was just an example... > > Marko > That means that VIPA does not work in my case. This is what I found in the kernel: /*- * Don't add host routes for interface addresses of * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it * possible to assign several such address pairs with consistent * results (no host route) and is required by BOOTP. * * XXX: This is ugly ! There should be a way for the caller to * say that they don't want a host route. */ I don't need host route too not just BOOTP :) and yes there should be a way to miss host route addition. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 8: 1: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from ShadoW.OTEL.net (JuDiCaToR.OTEL.net [212.36.9.113]) by hub.freebsd.org (Postfix) with ESMTP id 6810137B400 for ; Thu, 6 Jun 2002 08:00:51 -0700 (PDT) Received: from ikostov (helo=localhost) by ShadoW.OTEL.net with local-esmtp (Exim 3.36 #1) id 17FykK-0008MT-00; Thu, 06 Jun 2002 18:00:16 +0300 Date: Thu, 6 Jun 2002 18:00:16 +0300 (EEST) From: Iasen Kostov To: Marko Zec Cc: "Vladimir B. Grebenschikov" , Christophe Prevotaux , "net@freebsd.org" Subject: Re: [HELP] IPless VLAN interfaces In-Reply-To: <3CFF7644.F4F5CC1@tel.fer.hr> Message-ID: <20020606175644.I32050-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 Thu, 6 Jun 2002, Marko Zec wrote: > "Vladimir B. Grebenschikov" wrote: > > > [snip] > > first try to specify source address to ping > > > > # ping -S 1.1.1.1 dest > > > > where 1.1.1.1 - address on fxp0 > > > > and you can set on your vlanX interfaces same addreses ad on your fxp0 > > with netmask 255.255.255.255 > > > > # ifconfig fxp0 1.1.1.1/24 > > # ifconfig vlan0 1.1.1.1 > > # ifconfig vlan1 1.1.1.1 > > # ifconfig vlan2 1.1.1.1 > > This will never work - you can't have the same IP address/mask on more than > one interface. Heh who said that ? :) Look in my starting post for "host routes for interface addresses". And I think ISO standart allow this. That's because I started the thread about host routes. > What OS are you running? > > Marko > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 8:10:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 2F7C037B400 for ; Thu, 6 Jun 2002 08:10:15 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17Fytq-0009XN-00; Thu, 06 Jun 2002 19:10:06 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Marko Zec Cc: Christophe Prevotaux , "net@freebsd.org" In-Reply-To: <3CFF7644.F4F5CC1@tel.fer.hr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 19:10:06 +0400 Message-Id: <1023376206.470.40.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Thu, 06.06.2002, =D7 18:48, Marko Zec =CE=C1=D0=C9=D3=C1=CC: > > # ifconfig fxp0 1.1.1.1/24 > > # ifconfig vlan0 1.1.1.1/32 > > # ifconfig vlan1 1.1.1.1/32 > > # ifconfig vlan2 1.1.1.1/32 >=20 > This will never work - you can't have the same IP address/mask on more th= an > one interface. Sure ? Do have try cut and paste my example into xterm ? vbook#/sys/i386/compile/VBOOK 142_> ifconfig -a lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 fxp0: flags=3D8843 mtu 1500 inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 ether 08:00:46:04:31:b3 media: Ethernet autoselect (100baseTX) status: active vbook#/sys/i386/compile/VBOOK 143_> ifconfig lo0 1.1.1.1/32 alias vbook#/sys/i386/compile/VBOOK 144_> ifconfig fxp0 1.1.1.1/32 alias vbook#/sys/i386/compile/VBOOK 145_> uname -a FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 15:49:21 MSD 2002 =20 root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 vbook#/sys/i386/compile/VBOOK 147_> ifconfig -a lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 inet 1.1.1.1 netmask 0xffffffff=20 fxp0: flags=3D8843 mtu 1500 inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 ether 08:00:46:04:31:b3 media: Ethernet autoselect (100baseTX) status: active Both addresses are work: vbook#/sys/i386/compile/VBOOK 153_> ping -R -S 1.1.1.1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) from 1.1.1.1: 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.167 ms RR: localhost (127.0.0.1) 1.1.1.1 64 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.150 ms (same route) vbook#/sys/i386/compile/VBOOK 154_> ping -n -R -S 1.1.1.1 192.168.1.109 PING 192.168.1.109 (192.168.1.109) from 1.1.1.1: 56 data bytes 64 bytes from 192.168.1.109: icmp_seq=3D0 ttl=3D64 time=3D1.836 ms RR: 192.168.1.109 1.1.1.1 64 bytes from 192.168.1.109: icmp_seq=3D1 ttl=3D64 time=3D1.600 ms (same route) (use loopback not best way to do this, but you can try any interface) > What OS are you running? # uname -a FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 15:49:21 MSD 2002 =20 root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 Same setup works well on 4-STABLE =20 > Marko >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 9:42:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from bug.udcast.com (ANice-101-2-1-104.abo.wanadoo.fr [193.251.10.104]) by hub.freebsd.org (Postfix) with ESMTP id ED91C37B40B for ; Thu, 6 Jun 2002 09:41:38 -0700 (PDT) Received: from udcast.com (IDENT:eduros@localhost [127.0.0.1]) by bug.udcast.com (8.11.0/8.11.0) with ESMTP id g56Gf8Y16710 for ; Thu, 6 Jun 2002 18:41:08 +0200 Message-ID: <3CFF90A3.7000400@udcast.com> Date: Thu, 06 Jun 2002 18:41:07 +0200 From: Emmanuel Duros User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Weird TCP behavior with RTT of 1000 ms Content-Type: multipart/mixed; boundary="------------010601000702080005010400" 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. --------------010601000702080005010400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear All, I am currently evaluating TCP with Freebsd 4.4 boxes simulating a very high latency link. For some reasons, I can get a TCP throughput extremely close to what is expected and sometimes, *without* changing any setting in my configuration I can get very poor performance ! Here is my setup: box 1 Router box 2 | | | | ------------------ ------------------- LAN 1 (100BT) LAN 2 (100BT) box 1, Router, and box 2 use FreeBSD 4.4. Router adds 1000ms (1 second) delay to all packets going *from* LAN 1 *to* LAN 2 using dummynet. I changed the TCP window sizes on box 1 and box 2 using sysctl command: box 1 box 2 sendspace 200000 default recvspace default 200000 I use ttcp to transfer data over tcp from box 1 to box 2. (1) When the transfer goes well, I get a 200Kbyte throughput after the slowstart period. This can be seen here with a 'netstat -I xl0 -w 1' on box 2: input (xl0) output packets errs bytes packets errs bytes colls 0 0 0 0 0 0 0 1 0 74 1 0 74 0 2 0 1580 2 0 132 0 2 0 3028 1 0 66 0 3 0 4542 2 0 132 0 5 0 7570 4 0 264 0 9 0 13626 6 0 396 0 15 0 22710 10 0 660 0 25 0 37850 17 0 1122 0 42 0 63588 28 0 1848 0 70 0 105980 47 0 3102 0 117 0 177138 78 0 5148 0 138 0 208932 92 0 6072 0 137 0 207418 91 0 6006 0 137 0 207418 92 0 6072 0 138 0 208932 92 0 6072 0 (2) However, very often the transfer does not happen so well... The transfer starts and gets stuck at 3Kbytes/s, and this can go up to 2 minutes and the slowstart operates again and the troughtput reaches 200KB/s. The netstat looks like: input (xl0) output packets errs bytes packets errs bytes colls 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 74 1 0 74 0 2 0 1580 2 0 132 0 3 0 4542 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 2 0 3028 2 0 132 0 [... for 2 minutes or more ! and then ...] 2 0 3028 1 0 66 0 3 0 4542 2 0 132 0 5 0 7570 4 0 264 0 input (xl0) output packets errs bytes packets errs bytes colls 9 0 13626 6 0 396 0 15 0 22710 10 0 660 0 25 0 37850 17 0 1122 0 42 0 63588 28 0 1848 0 70 0 105980 47 0 3102 0 117 0 177138 78 0 5148 0 138 0 208932 92 0 6072 0 137 0 207418 91 0 6006 0 138 0 208932 92 0 6072 0 134 0 202876 89 0 5874 0 I really want to point out that I am not changing anything in my settings between 2 transfers. I am just starting ttcp again and again on my boxes and TCP behave like (1) or (2). It looks like this behavior is not deterministic. I attached the tcpdump ouput that showes the beginning of the transfer on box 1. As you can see there is no packet loss and this cannot be the reason why the congestion window does not increase... I also noticed that with a 500ms delay instead of 1000ms I have not seen this problem. Is this a bug, a 'feature', ... ??? Thanks a lot and regards, Emmanuel -- Emmanuel Duros http://www.udcast.com 2455 Route des Dolines BP355 | Tel : +33 (0)4 93 00 16 60 06906 Sophia Antipolis France | Fax : +33 (0)4 93 00 16 61 ** Full IP over Broadcast Media ** --------------010601000702080005010400 Content-Type: text/plain; name="tcp-output.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp-output.txt" tcpdump -n -i fxp0 host 192.168.132.2 tcpdump: listening on fxp0 17:34:09.151317 192.168.99.102.1416 > 192.168.132.2.5001: S 3748748564:3748748564(0) win 16384 (DF) 17:34:10.143720 192.168.132.2.5001 > 192.168.99.102.1416: S 2021053759:2021053759(0) ack 3748748565 win 65535 (DF) 17:34:10.143792 192.168.99.102.1416 > 192.168.132.2.5001: . ack 1 win 17376 (DF) 17:34:10.144883 192.168.99.102.1416 > 192.168.132.2.5001: . 1:1449(1448) ack 1 win 17376 (DF) 17:34:11.143652 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1 win 50318 (DF) 17:34:11.230230 192.168.99.102.1416 > 192.168.132.2.5001: . 1:1449(1448) ack 1 win 17376 (DF) 17:34:11.234687 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1449 win 50318 (DF) 17:34:11.234737 192.168.99.102.1416 > 192.168.132.2.5001: . 1449:2897(1448) ack 1 win 17376 (DF) 17:34:11.234760 192.168.99.102.1416 > 192.168.132.2.5001: . 2897:4345(1448) ack 1 win 17376 (DF) 17:34:12.223754 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1449 win 50318 (DF) 17:34:12.233813 192.168.132.2.5001 > 192.168.99.102.1416: . ack 4345 win 49956 (DF) 17:34:12.233870 192.168.99.102.1416 > 192.168.132.2.5001: . 4345:5793(1448) ack 1 win 17376 (DF) 17:34:12.233894 192.168.99.102.1416 > 192.168.132.2.5001: . 5793:7241(1448) ack 1 win 17376 (DF) 17:34:13.353855 192.168.132.2.5001 > 192.168.99.102.1416: . ack 5793 win 50318 (DF) 17:34:13.353940 192.168.99.102.1416 > 192.168.132.2.5001: . 7241:8689(1448) ack 1 win 17376 (DF) 17:34:13.444788 192.168.132.2.5001 > 192.168.99.102.1416: . ack 7241 win 50318 (DF) 17:34:13.444835 192.168.99.102.1416 > 192.168.132.2.5001: . 8689:10137(1448) ack 1 win 17376 (DF) 17:34:14.443749 192.168.132.2.5001 > 192.168.99.102.1416: . ack 10137 win 49956 (DF) 17:34:14.443811 192.168.99.102.1416 > 192.168.132.2.5001: . 10137:11585(1448) ack 1 win 17376 (DF) 17:34:14.443835 192.168.99.102.1416 > 192.168.132.2.5001: . 11585:13033(1448) ack 1 win 17376 (DF) 17:34:15.443816 192.168.132.2.5001 > 192.168.99.102.1416: . ack 11585 win 50318 (DF) 17:34:15.443870 192.168.99.102.1416 > 192.168.132.2.5001: . 13033:14481(1448) ack 1 win 17376 (DF) 17:34:15.534760 192.168.132.2.5001 > 192.168.99.102.1416: . ack 13033 win 50318 (DF) 17:34:15.534803 192.168.99.102.1416 > 192.168.132.2.5001: . 14481:15929(1448) ack 1 win 17376 (DF) 17:34:16.533773 192.168.132.2.5001 > 192.168.99.102.1416: . ack 15929 win 49956 (DF) 17:34:16.533831 192.168.99.102.1416 > 192.168.132.2.5001: . 15929:17377(1448) ack 1 win 17376 (DF) 17:34:16.533854 192.168.99.102.1416 > 192.168.132.2.5001: . 17377:18825(1448) ack 1 win 17376 (DF) 17:34:17.533793 192.168.132.2.5001 > 192.168.99.102.1416: . ack 17377 win 50318 (DF) 17:34:17.533846 192.168.99.102.1416 > 192.168.132.2.5001: . 18825:20273(1448) ack 1 win 17376 (DF) 17:34:17.624800 192.168.132.2.5001 > 192.168.99.102.1416: . ack 18825 win 50318 (DF) 17:34:17.624851 192.168.99.102.1416 > 192.168.132.2.5001: . 20273:21721(1448) ack 1 win 17376 (DF) 17:34:18.623755 192.168.132.2.5001 > 192.168.99.102.1416: . ack 21721 win 49956 (DF) 17:34:18.623882 192.168.99.102.1416 > 192.168.132.2.5001: . 21721:23169(1448) ack 1 win 17376 (DF) 17:34:18.623910 192.168.99.102.1416 > 192.168.132.2.5001: . 23169:24617(1448) ack 1 win 17376 (DF) 17:34:19.623854 192.168.132.2.5001 > 192.168.99.102.1416: . ack 23169 win 50318 (DF) 17:34:19.623913 192.168.99.102.1416 > 192.168.132.2.5001: . 24617:26065(1448) ack 1 win 17376 (DF) 17:34:19.714848 192.168.132.2.5001 > 192.168.99.102.1416: . ack 24617 win 50318 (DF) 17:34:19.714903 192.168.99.102.1416 > 192.168.132.2.5001: . 26065:27513(1448) ack 1 win 17376 (DF) 17:34:20.713755 192.168.132.2.5001 > 192.168.99.102.1416: . ack 27513 win 49956 (DF) 17:34:20.713810 192.168.99.102.1416 > 192.168.132.2.5001: . 27513:28961(1448) ack 1 win 17376 (DF) 17:34:20.713831 192.168.99.102.1416 > 192.168.132.2.5001: . 28961:30409(1448) ack 1 win 17376 (DF) 17:34:21.713862 192.168.132.2.5001 > 192.168.99.102.1416: . ack 28961 win 50318 (DF) 17:34:21.713923 192.168.99.102.1416 > 192.168.132.2.5001: . 30409:31857(1448) ack 1 win 17376 (DF) 17:34:21.811503 192.168.132.2.5001 > 192.168.99.102.1416: . ack 30409 win 50318 (DF) 17:34:21.811550 192.168.99.102.1416 > 192.168.132.2.5001: . 31857:33305(1448) ack 1 win 17376 (DF) 17:34:22.803753 192.168.132.2.5001 > 192.168.99.102.1416: . ack 33305 win 49956 (DF) 17:34:22.803813 192.168.99.102.1416 > 192.168.132.2.5001: . 33305:34753(1448) ack 1 win 17376 (DF) 17:34:22.803838 192.168.99.102.1416 > 192.168.132.2.5001: . 34753:36201(1448) ack 1 win 17376 (DF) 17:34:23.803873 192.168.132.2.5001 > 192.168.99.102.1416: . ack 34753 win 50318 (DF) 17:34:23.803979 192.168.99.102.1416 > 192.168.132.2.5001: . 36201:37649(1448) ack 1 win 17376 (DF) 17:34:23.894946 192.168.132.2.5001 > 192.168.99.102.1416: . ack 36201 win 50318 (DF) 17:34:23.894997 192.168.99.102.1416 > 192.168.132.2.5001: . 37649:39097(1448) ack 1 win 17376 (DF) --------------010601000702080005010400-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 10:34:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from freebsd.linux-site.net (p50853211.dip.t-dialin.net [80.133.50.17]) by hub.freebsd.org (Postfix) with ESMTP id 9536437B408 for ; Thu, 6 Jun 2002 10:34:38 -0700 (PDT) Received: from WKS1 (client1.freebsd.linux-site.net [192.168.0.2]) by freebsd.linux-site.net (8.11.6/8.11.6) with SMTP id g56HXJm04712 for ; Thu, 6 Jun 2002 19:33:19 +0200 (CEST) (envelope-from mario@freebsd.linux-site.net) Reply-To: From: "Mario Schmidt" To: Subject: PPPoE Monitor Date: Thu, 6 Jun 2002 19:34:06 +0200 Message-ID: <000801c20d80$5ce3c080$0200a8c0@WKS1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 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 How to measure/monitor bandwidth on an PPPoE interface? I would like to have a nice GUI/WWW report of current connections/ports/programs/etc. ? TAI Mario ____________________________________________ ms.software Emmastr. 32 D-42287 Wuppertal Germany Tel.: +49-(0)-202-2817766 Fax : +49-(0)-202-2817767 Web : http://freebsd.linux-site.net Mail: mailto:mario@freebsd.linux-site.net ICQ : #160931152 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 10:59:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from web9904.mail.yahoo.com (web9904.mail.yahoo.com [216.136.129.247]) by hub.freebsd.org (Postfix) with SMTP id 76AD037B404 for ; Thu, 6 Jun 2002 10:59:23 -0700 (PDT) Message-ID: <20020606175923.82737.qmail@web9904.mail.yahoo.com> Received: from [216.98.102.241] by web9904.mail.yahoo.com via HTTP; Thu, 06 Jun 2002 10:59:23 PDT Date: Thu, 6 Jun 2002 10:59:23 -0700 (PDT) From: W Alexander Hagen Subject: unsubsribe To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1195267406-1023386363=:82704" 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 --0-1195267406-1023386363=:82704 Content-Type: text/plain; charset=us-ascii unsubscribe If I am sending this incorrectly please advise. --------------------------------- Do You Yahoo!? Sign-up for Video Highlights of 2002 FIFA World Cup --0-1195267406-1023386363=:82704 Content-Type: text/html; charset=us-ascii

unsubscribe

 

If I am sending this incorrectly please advise.

 


Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup --0-1195267406-1023386363=:82704-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 11: 0:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B66EE37B40D for ; Thu, 6 Jun 2002 11:00:18 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020606180018.UAWK2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 6 Jun 2002 18:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA59290; Thu, 6 Jun 2002 10:50:21 -0700 (PDT) Date: Thu, 6 Jun 2002 10:50:20 -0700 (PDT) From: Julian Elischer To: Mario Schmidt Cc: freebsd-net@freebsd.org Subject: Re: PPPoE Monitor In-Reply-To: <000801c20d80$5ce3c080$0200a8c0@WKS1> 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 netstat -I tun0 1? or netstat -I fxp0 1 (depending if you want to account for the ppp & pppoe headers as well.) On Thu, 6 Jun 2002, Mario Schmidt wrote: > How to measure/monitor bandwidth on an PPPoE interface? I would like to have > a nice GUI/WWW report of current connections/ports/programs/etc. ? > > TAI > Mario > > ____________________________________________ > ms.software > Emmastr. 32 > D-42287 Wuppertal > Germany > > Tel.: +49-(0)-202-2817766 > Fax : +49-(0)-202-2817767 > Web : http://freebsd.linux-site.net > Mail: mailto:mario@freebsd.linux-site.net > ICQ : #160931152 > > > > 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 Thu Jun 6 11:36:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from gateway.posi.net (12-236-90-177.client.attbi.com [12.236.90.177]) by hub.freebsd.org (Postfix) with ESMTP id D2F6E37B401 for ; Thu, 6 Jun 2002 11:36:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.3/8.12.3) with ESMTP id g56IaAM7040381; Thu, 6 Jun 2002 11:36:10 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Thu, 6 Jun 2002 11:36:10 -0700 (PDT) From: Kelly Yancey To: Vadim Egorov Cc: freebsd-net@FreeBSD.org Subject: Re: IP_MULTICAST_LOOP In-Reply-To: <86vg8wu5cw.fsf@my.egorovv.net> Message-ID: <20020606113237.N40292-100000@gateway.posi.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 Thu, 6 Jun 2002, Vadim Egorov wrote: > > Hi guys! > > I'm playing with multicasting (-stable), and I want to disable looping back > my outgoing packets setting IP_MULTICAST_LOOP option to 0 but it doen't > have any effect. My app is listening to the same group it is casting. > > After some grepping I came across some code in netinet/ip_output.c: > (imo == NULL || imo->imo_multicast_loop)) { > /* > * If we belong to the destination multicast group > * on the outgoing interface, and the caller did not > * forbid loopback, loop back a copy. > */ > > The comment says 'and' but the code says '||' -- looks like an error to me. > Except this I've got no idea what it means - does it make amy sence? > You definately wouldn't want this to be && because if imo is NULL you certainly wouldn't want to dereference it. :) The comment's logic matches the code, it is just that the phrasing is inverted. Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 11:43:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id A8FA837B406 for ; Thu, 6 Jun 2002 11:43:47 -0700 (PDT) Received: from tel.fer.hr (zg05-220.dialin.iskon.hr [213.191.138.221]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g56IhdT02827; Thu, 6 Jun 2002 20:43:39 +0200 (MEST) Message-ID: <3CFFAD41.441C0E@tel.fer.hr> Date: Thu, 06 Jun 2002 20:43:13 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir B. Grebenschikov" , freebsd-net@freebsd.org Subject: Re: [HELP] IPless VLAN interfaces References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> <1023376206.470.40.camel@vbook.express.ru> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 "Vladimir B. Grebenschikov" wrote: > ÷ Thu, 06.06.2002, × 18:48, Marko Zec ÎÁÐÉÓÁÌ: > > > > # ifconfig fxp0 1.1.1.1/24 > > > # ifconfig vlan0 1.1.1.1/32 > > > # ifconfig vlan1 1.1.1.1/32 > > > # ifconfig vlan2 1.1.1.1/32 > > > > This will never work - you can't have the same IP address/mask on more than > > one interface. > > Sure ? Do have try cut and paste my example into xterm ? > > vbook#/sys/i386/compile/VBOOK 142_> ifconfig -a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > fxp0: flags=8843 mtu 1500 > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > ether 08:00:46:04:31:b3 > media: Ethernet autoselect (100baseTX) > status: active > vbook#/sys/i386/compile/VBOOK 143_> ifconfig lo0 1.1.1.1/32 alias > vbook#/sys/i386/compile/VBOOK 144_> ifconfig fxp0 1.1.1.1/32 alias > vbook#/sys/i386/compile/VBOOK 145_> uname -a > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > 15:49:21 MSD 2002 > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > vbook#/sys/i386/compile/VBOOK 147_> ifconfig -a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet 1.1.1.1 netmask 0xffffffff > fxp0: flags=8843 mtu 1500 > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 > ether 08:00:46:04:31:b3 > media: Ethernet autoselect (100baseTX) > status: active > > Both addresses are work: > > vbook#/sys/i386/compile/VBOOK 153_> ping -R -S 1.1.1.1 127.0.0.1 > PING 127.0.0.1 (127.0.0.1) from 1.1.1.1: 56 data bytes > 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.167 ms > RR: localhost (127.0.0.1) > 1.1.1.1 > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.150 ms (same > route) > vbook#/sys/i386/compile/VBOOK 154_> ping -n -R -S 1.1.1.1 192.168.1.109 > PING 192.168.1.109 (192.168.1.109) from 1.1.1.1: 56 data bytes > 64 bytes from 192.168.1.109: icmp_seq=0 ttl=64 time=1.836 ms > RR: 192.168.1.109 > 1.1.1.1 > 64 bytes from 192.168.1.109: icmp_seq=1 ttl=64 time=1.600 ms (same > route) > > (use loopback not best way to do this, but you can try any interface) > > > What OS are you running? > > # uname -a > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > 15:49:21 MSD 2002 > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > > Same setup works well on 4-STABLE In your original post, you were suggesting to put the same IP/mask on different "real" interfaces, not loopback. Could you pls. try to create a couple of vlan interfaces (ifconfig vlan0 create...), than configure them with the same IP addresses/masks as you suggested earlier, and show us the results of this procedure? On my 4.6-RC system, such thing just don't work, thanks God. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 12:21:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0B7F937B409 for ; Thu, 6 Jun 2002 12:21:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g56JLEQ14062; Thu, 6 Jun 2002 12:21:14 -0700 (PDT) (envelope-from rizzo) Date: Thu, 6 Jun 2002 12:21:13 -0700 From: Luigi Rizzo To: Emmanuel Duros Cc: freebsd-net@FreeBSD.ORG Subject: Re: Weird TCP behavior with RTT of 1000 ms Message-ID: <20020606122113.A13808@iguana.icir.org> References: <3CFF90A3.7000400@udcast.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: <3CFF90A3.7000400@udcast.com>; from Emmanuel.Duros@udcast.com on Thu, Jun 06, 2002 at 06:41:07PM +0200 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 one thing that comes to mind is that FreeBSD caches the initial TCP parameters in the route table, storing something computed in the previous connection. I am not sure about the details, but depending on what happens when you abort (or close) the previous connection, you might start with a very low ssthresh which would explain the behaviour. deleting the route entry might help in making the behaviour more deterministic. On top of this I think i remember 4.4 had some annoying bug in handling timeouts or something like that, so you should really try and see if the same problem still occurs with 4.5 or more recent -- you can easily try that by building a picobsd image based on the newer sources for the two boxes to test, if you do not want to upgrade the entire system. You just need to upgrade crunchgen to the one in RELENG_4, grab the picobsd script and the manpage, and read it. cheers luigi On Thu, Jun 06, 2002 at 06:41:07PM +0200, Emmanuel Duros wrote: > Dear All, > > I am currently evaluating TCP with Freebsd 4.4 boxes simulating a very > high latency link. For some reasons, I can get a TCP throughput > extremely close to what is expected and sometimes, *without* changing > any setting in my configuration I can get very poor performance ! > > Here is my setup: > > box 1 Router box 2 > | | | | > ------------------ ------------------- > LAN 1 (100BT) LAN 2 (100BT) > > box 1, Router, and box 2 use FreeBSD 4.4. > Router adds 1000ms (1 second) delay to all packets going *from* LAN 1 > *to* LAN 2 using dummynet. > > I changed the TCP window sizes on box 1 and box 2 using sysctl command: > > box 1 box 2 > sendspace 200000 default > recvspace default 200000 > > I use ttcp to transfer data over tcp from box 1 to box 2. > > (1) When the transfer goes well, I get a 200Kbyte throughput after the > slowstart period. This can be seen here with a 'netstat -I xl0 -w 1' on > box 2: > > input (xl0) output > packets errs bytes packets errs bytes colls > 0 0 0 0 0 0 0 > 1 0 74 1 0 74 0 > 2 0 1580 2 0 132 0 > 2 0 3028 1 0 66 0 > 3 0 4542 2 0 132 0 > 5 0 7570 4 0 264 0 > 9 0 13626 6 0 396 0 > 15 0 22710 10 0 660 0 > 25 0 37850 17 0 1122 0 > 42 0 63588 28 0 1848 0 > 70 0 105980 47 0 3102 0 > 117 0 177138 78 0 5148 0 > 138 0 208932 92 0 6072 0 > 137 0 207418 91 0 6006 0 > 137 0 207418 92 0 6072 0 > 138 0 208932 92 0 6072 0 > > > (2) However, very often the transfer does not happen so well... The > transfer starts and gets stuck at 3Kbytes/s, and this can go up to 2 > minutes and the slowstart operates again and the troughtput reaches > 200KB/s. The netstat looks like: > > input (xl0) output > packets errs bytes packets errs bytes colls > 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > 1 0 74 1 0 74 0 > 2 0 1580 2 0 132 0 > 3 0 4542 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > 2 0 3028 2 0 132 0 > [... for 2 minutes or more ! and then ...] > 2 0 3028 1 0 66 0 > 3 0 4542 2 0 132 0 > 5 0 7570 4 0 264 0 > input (xl0) output > packets errs bytes packets errs bytes colls > 9 0 13626 6 0 396 0 > 15 0 22710 10 0 660 0 > 25 0 37850 17 0 1122 0 > 42 0 63588 28 0 1848 0 > 70 0 105980 47 0 3102 0 > 117 0 177138 78 0 5148 0 > 138 0 208932 92 0 6072 0 > 137 0 207418 91 0 6006 0 > 138 0 208932 92 0 6072 0 > 134 0 202876 89 0 5874 0 > > I really want to point out that I am not changing anything in my > settings between 2 transfers. I am just starting ttcp again and again on > my boxes and TCP behave like (1) or (2). It looks like this behavior is > not deterministic. > > I attached the tcpdump ouput that showes the beginning of the transfer > on box 1. As you can see there is no packet loss and this cannot be the > reason why the congestion window does not increase... > > I also noticed that with a 500ms delay instead of 1000ms I have not seen > this problem. > > Is this a bug, a 'feature', ... ??? > > Thanks a lot and regards, > Emmanuel > -- > Emmanuel Duros http://www.udcast.com > 2455 Route des Dolines BP355 | Tel : +33 (0)4 93 00 16 60 > 06906 Sophia Antipolis France | Fax : +33 (0)4 93 00 16 61 > ** Full IP over Broadcast Media ** > tcpdump -n -i fxp0 host 192.168.132.2 > tcpdump: listening on fxp0 > 17:34:09.151317 192.168.99.102.1416 > 192.168.132.2.5001: S 3748748564:3748748564(0) win 16384 (DF) > 17:34:10.143720 192.168.132.2.5001 > 192.168.99.102.1416: S 2021053759:2021053759(0) ack 3748748565 win 65535 (DF) > 17:34:10.143792 192.168.99.102.1416 > 192.168.132.2.5001: . ack 1 win 17376 (DF) > 17:34:10.144883 192.168.99.102.1416 > 192.168.132.2.5001: . 1:1449(1448) ack 1 win 17376 (DF) > 17:34:11.143652 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1 win 50318 (DF) > 17:34:11.230230 192.168.99.102.1416 > 192.168.132.2.5001: . 1:1449(1448) ack 1 win 17376 (DF) > 17:34:11.234687 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1449 win 50318 (DF) > 17:34:11.234737 192.168.99.102.1416 > 192.168.132.2.5001: . 1449:2897(1448) ack 1 win 17376 (DF) > 17:34:11.234760 192.168.99.102.1416 > 192.168.132.2.5001: . 2897:4345(1448) ack 1 win 17376 (DF) > 17:34:12.223754 192.168.132.2.5001 > 192.168.99.102.1416: . ack 1449 win 50318 (DF) > 17:34:12.233813 192.168.132.2.5001 > 192.168.99.102.1416: . ack 4345 win 49956 (DF) > 17:34:12.233870 192.168.99.102.1416 > 192.168.132.2.5001: . 4345:5793(1448) ack 1 win 17376 (DF) > 17:34:12.233894 192.168.99.102.1416 > 192.168.132.2.5001: . 5793:7241(1448) ack 1 win 17376 (DF) > 17:34:13.353855 192.168.132.2.5001 > 192.168.99.102.1416: . ack 5793 win 50318 (DF) > 17:34:13.353940 192.168.99.102.1416 > 192.168.132.2.5001: . 7241:8689(1448) ack 1 win 17376 (DF) > 17:34:13.444788 192.168.132.2.5001 > 192.168.99.102.1416: . ack 7241 win 50318 (DF) > 17:34:13.444835 192.168.99.102.1416 > 192.168.132.2.5001: . 8689:10137(1448) ack 1 win 17376 (DF) > 17:34:14.443749 192.168.132.2.5001 > 192.168.99.102.1416: . ack 10137 win 49956 (DF) > 17:34:14.443811 192.168.99.102.1416 > 192.168.132.2.5001: . 10137:11585(1448) ack 1 win 17376 (DF) > 17:34:14.443835 192.168.99.102.1416 > 192.168.132.2.5001: . 11585:13033(1448) ack 1 win 17376 (DF) > 17:34:15.443816 192.168.132.2.5001 > 192.168.99.102.1416: . ack 11585 win 50318 (DF) > 17:34:15.443870 192.168.99.102.1416 > 192.168.132.2.5001: . 13033:14481(1448) ack 1 win 17376 (DF) > 17:34:15.534760 192.168.132.2.5001 > 192.168.99.102.1416: . ack 13033 win 50318 (DF) > 17:34:15.534803 192.168.99.102.1416 > 192.168.132.2.5001: . 14481:15929(1448) ack 1 win 17376 (DF) > 17:34:16.533773 192.168.132.2.5001 > 192.168.99.102.1416: . ack 15929 win 49956 (DF) > 17:34:16.533831 192.168.99.102.1416 > 192.168.132.2.5001: . 15929:17377(1448) ack 1 win 17376 (DF) > 17:34:16.533854 192.168.99.102.1416 > 192.168.132.2.5001: . 17377:18825(1448) ack 1 win 17376 (DF) > 17:34:17.533793 192.168.132.2.5001 > 192.168.99.102.1416: . ack 17377 win 50318 (DF) > 17:34:17.533846 192.168.99.102.1416 > 192.168.132.2.5001: . 18825:20273(1448) ack 1 win 17376 (DF) > 17:34:17.624800 192.168.132.2.5001 > 192.168.99.102.1416: . ack 18825 win 50318 (DF) > 17:34:17.624851 192.168.99.102.1416 > 192.168.132.2.5001: . 20273:21721(1448) ack 1 win 17376 (DF) > 17:34:18.623755 192.168.132.2.5001 > 192.168.99.102.1416: . ack 21721 win 49956 (DF) > 17:34:18.623882 192.168.99.102.1416 > 192.168.132.2.5001: . 21721:23169(1448) ack 1 win 17376 (DF) > 17:34:18.623910 192.168.99.102.1416 > 192.168.132.2.5001: . 23169:24617(1448) ack 1 win 17376 (DF) > 17:34:19.623854 192.168.132.2.5001 > 192.168.99.102.1416: . ack 23169 win 50318 (DF) > 17:34:19.623913 192.168.99.102.1416 > 192.168.132.2.5001: . 24617:26065(1448) ack 1 win 17376 (DF) > 17:34:19.714848 192.168.132.2.5001 > 192.168.99.102.1416: . ack 24617 win 50318 (DF) > 17:34:19.714903 192.168.99.102.1416 > 192.168.132.2.5001: . 26065:27513(1448) ack 1 win 17376 (DF) > 17:34:20.713755 192.168.132.2.5001 > 192.168.99.102.1416: . ack 27513 win 49956 (DF) > 17:34:20.713810 192.168.99.102.1416 > 192.168.132.2.5001: . 27513:28961(1448) ack 1 win 17376 (DF) > 17:34:20.713831 192.168.99.102.1416 > 192.168.132.2.5001: . 28961:30409(1448) ack 1 win 17376 (DF) > 17:34:21.713862 192.168.132.2.5001 > 192.168.99.102.1416: . ack 28961 win 50318 (DF) > 17:34:21.713923 192.168.99.102.1416 > 192.168.132.2.5001: . 30409:31857(1448) ack 1 win 17376 (DF) > 17:34:21.811503 192.168.132.2.5001 > 192.168.99.102.1416: . ack 30409 win 50318 (DF) > 17:34:21.811550 192.168.99.102.1416 > 192.168.132.2.5001: . 31857:33305(1448) ack 1 win 17376 (DF) > 17:34:22.803753 192.168.132.2.5001 > 192.168.99.102.1416: . ack 33305 win 49956 (DF) > 17:34:22.803813 192.168.99.102.1416 > 192.168.132.2.5001: . 33305:34753(1448) ack 1 win 17376 (DF) > 17:34:22.803838 192.168.99.102.1416 > 192.168.132.2.5001: . 34753:36201(1448) ack 1 win 17376 (DF) > 17:34:23.803873 192.168.132.2.5001 > 192.168.99.102.1416: . ack 34753 win 50318 (DF) > 17:34:23.803979 192.168.99.102.1416 > 192.168.132.2.5001: . 36201:37649(1448) ack 1 win 17376 (DF) > 17:34:23.894946 192.168.132.2.5001 > 192.168.99.102.1416: . ack 36201 win 50318 (DF) > 17:34:23.894997 192.168.99.102.1416 > 192.168.132.2.5001: . 37649:39097(1448) ack 1 win 17376 (DF) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 14:43:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 0973937B403 for ; Thu, 6 Jun 2002 14:43:30 -0700 (PDT) Received: from my.egorovv.net.attbi.com ([12.235.54.40]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020606214329.EUPD2751.rwcrmhc52.attbi.com@my.egorovv.net.attbi.com> for ; Thu, 6 Jun 2002 21:43:29 +0000 To: freebsd-net@FreeBSD.org Subject: Re: IP_MULTICAST_LOOP References: <86vg8wu5cw.fsf@my.egorovv.net> <20020606113237.N40292-100000@gateway.posi.net> From: Vadim Egorov Date: Thu, 06 Jun 2002 14:43:23 -0700 In-Reply-To: <20020606113237.N40292-100000@gateway.posi.net> (Kelly Yancey's message of "Thu, 6 Jun 2002 11:36:10 -0700 (PDT)") Message-ID: <86r8jkrslg.fsf@my.egorovv.net> Lines: 48 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 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 Sorry guys for beeng so stupid :( But the problem still in place - it actually boils down to the multicast example from Stivens 'Unix Network Programming' - it casts and lstens to the same group. I tried it on Linux - turning IP_MULTICAST_LOOP off does blocks traffic looping, but on FreeBSD it doesn't seem to have any effect. I think I can live with this, I just feel that somthing is wrong here. > On Thu, 6 Jun 2002, Vadim Egorov wrote: >> I'm playing with multicasting (-stable), and I want to disable looping back >> my outgoing packets setting IP_MULTICAST_LOOP option to 0 but it doen't >> have any effect. My app is listening to the same group it is casting. >> >> > After some grepping I came across some code in netinet/ip_output.c: >> > (imo == NULL || imo->imo_multicast_loop)) { >> > /* >> > * If we belong to the destination multicast group >> > * on the outgoing interface, and the caller did not >> > * forbid loopback, loop back a copy. >> > */ >> > >> > The comment says 'and' but the code says '||' -- looks like an error to me. >> > Except this I've got no idea what it means - does it make amy sence? Kelly Yancey writes: > You definately wouldn't want this to be && because if imo is NULL you > certainly wouldn't want to dereference it. :) The comment's logic matches the > code, it is just that the phrasing is inverted. > > Kelly "Wilbert de Graaf" writes: > Hi Vadim > > I wondered if in general your application does the right thing. You can either: > 1) let the sender listen to another group: logically split your protocol > 2) use IGMPv3 and simply block yourself from listening > I have a patch + examples how to do this at: > http://home.hetnet.nl/~wilbertdg/igmpv3.html > > Thanks, Wilbert -- Thanks, Vadim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 6 15: 3:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 4C78D37B406 for ; Thu, 6 Jun 2002 15:03:30 -0700 (PDT) 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 <20020606220329.FQBH975.sccrmhc02.attbi.com@blossom.cjclark.org>; Thu, 6 Jun 2002 22:03:29 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g56M3Si94140; Thu, 6 Jun 2002 15:03:28 -0700 (PDT) (envelope-from crist.clark@attbi.com) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Thu, 6 Jun 2002 15:03:28 -0700 From: "Crist J. Clark" To: Vadim Egorov Cc: freebsd-net@FreeBSD.ORG Subject: Re: IP_MULTICAST_LOOP Message-ID: <20020606150328.G93321@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <86vg8wu5cw.fsf@my.egorovv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <86vg8wu5cw.fsf@my.egorovv.net>; from egorovv@attbi.com on Thu, Jun 06, 2002 at 02:24:47AM -0700 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 Thu, Jun 06, 2002 at 02:24:47AM -0700, Vadim Egorov wrote: > > Hi guys! > > I'm playing with multicasting (-stable), and I want to disable looping back > my outgoing packets setting IP_MULTICAST_LOOP option to 0 but it doen't > have any effect. My app is listening to the same group it is casting. > > After some grepping I came across some code in netinet/ip_output.c: > (imo == NULL || imo->imo_multicast_loop)) { > /* > * If we belong to the destination multicast group > * on the outgoing interface, and the caller did not > * forbid loopback, loop back a copy. > */ > > The comment says 'and' but the code says '||' -- looks like an error to me. > Except this I've got no idea what it means - does it make amy sence? The line you quote is only checking the "caller did not forbid loopback" portion. It evaluates true when no options are set (imo == NULL) or when the IP_MULTICAST_LOOP (imo->imo_multicast_loop) is non-zero. The first conditional is just defaulting to loopback when no options are present. The "and" part of the conditional was on the previous line. Here's the whole conditional, if (inm != NULL && (imo == NULL || imo->imo_multicast_loop)) { -- 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 Thu Jun 6 17:36:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from web10105.mail.yahoo.com (web10105.mail.yahoo.com [216.136.130.55]) by hub.freebsd.org (Postfix) with SMTP id 370AF37B403 for ; Thu, 6 Jun 2002 17:36:32 -0700 (PDT) Message-ID: <20020607003631.46478.qmail@web10105.mail.yahoo.com> Received: from [151.201.233.84] by web10105.mail.yahoo.com via HTTP; Thu, 06 Jun 2002 17:36:31 PDT Date: Thu, 6 Jun 2002 17:36:31 -0700 (PDT) From: "Joe T." Subject: problems with ifconfig aliases 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, Originally, I had created some aliases with the following command: # ifconfig dc0 alias 192.168.1.111 255.255.255.255 # ifconfig dc0 alias 192.168.1.112 255.255.255.255 ... This worked fine.. i was able to use the aliases for various projects I was playing with. When I was done, I took the aliases out: # ifconfig dc0 -alias 192.168.1.111 255.255.255.255 ... Now, whever I try re-creating those aliases (or any different ones for that matter) I get: # ifconfig dc0 alias 192.168.1.111 255.255.255.255 ifconfig: ioctl (SIOCAIFADDR): File exists # ifconfig dc0 alias 192.168.1.2 255.255.255.255 <-- never used before ifconfig: ioctl (SIOCAIFADDR): File exists What happened here? What did I do wrong? How can I fix it? Any help is appreciated Thanks, Joe __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 1:38:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 2CE6C37B403 for ; Fri, 7 Jun 2002 01:38:23 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17GFGD-0000Bp-00 for net@freebsd.org; Fri, 07 Jun 2002 12:38:17 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: "net@freebsd.org" In-Reply-To: <3CFFAD41.441C0E@tel.fer.hr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> <1023376206.470.40.camel@vbook.express.ru> <3CFFAD41.441C0E@tel.fer.hr> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 12:38:17 +0400 Message-Id: <1023439097.531.8.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Thu, 06.06.2002, =D7 22:43, Marko Zec =CE=C1=D0=C9=D3=C1=CC: > In your original post, you were suggesting to put the same IP/mask on dif= ferent > "real" interfaces, not loopback. Could you pls. try to create a couple of= vlan > interfaces (ifconfig vlan0 create...), than configure them with the same = IP > addresses/masks as you suggested earlier, and show us the results of this > procedure? On my 4.6-RC system, such thing just don't work, thanks God. Ok EEXISTS message you have is because kernel can't add one more route for same address, it need to help kernel a bit: vbook#/home/vova 121_> ifconfig vlan0 create vbook#/home/vova 122_> ifconfig vlan1 create vbook#/home/vova 123_> ifconfig vlan2 create vbook#/home/vova 124_> ifconfig vlan0 vlan 1 vlandev fxp0 vbook#/home/vova 125_> ifconfig vlan1 vlan 2 vlandev fxp0 vbook#/home/vova 126_> ifconfig vlan2 vlan 3 vlandev fxp0 vbook#/home/vova 127_> ifconfig fxp0 1.1.1.1/24 vbook#/home/vova 128_> ifconfig vlan0 1.1.1.1/32 vbook#/home/vova 129_> route delete 1.1.1.1 delete host 1.1.1.1 vbook#/home/vova 130_> ifconfig vlan1 1.1.1.1/32 vbook#/home/vova 131_> route delete 1.1.1.1 delete host 1.1.1.1 vbook#/home/vova 132_> ifconfig vlan2 1.1.1.1/32 vbook#/home/vova 133_> ifconfig -a lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 fxp0: flags=3D8943 mtu 1500 inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255 ether 08:00:46:04:31:b3 media: Ethernet autoselect (100baseTX) status: active vlan0: flags=3D8843 mtu 1500 inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 ether 08:00:46:04:31:b3 vlan: 1 parent interface: fxp0 vlan1: flags=3D8843 mtu 1500 inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 ether 08:00:46:04:31:b3 vlan: 2 parent interface: fxp0 vlan2: flags=3D8843 mtu 1500 inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 ether 08:00:46:04:31:b3 vlan: 3 parent interface: fxp0 (sorry, I forget about such simple thing because rare use more then one=20 address with same mask) PS: about this in kernel code there is beautiful comment (XXX part): /*- * Don't add host routes for interface addresses of * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it * possible to assign several such address pairs with consistent * results (no host route) and is required by BOOTP. * * XXX: This is ugly ! There should be a way for the caller to * say that they don't want a host route. */ =20 > Marko >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 1:43:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id 2D33D37B403 for ; Fri, 7 Jun 2002 01:43:00 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GFKY-000Chz-00; Fri, 07 Jun 2002 11:42:46 +0300 Date: Fri, 7 Jun 2002 11:42:46 +0300 (EEST) From: Iasen Kostov To: Marko Zec Cc: "Vladimir B. Grebenschikov" , Subject: Re: [HELP] IPless VLAN interfaces In-Reply-To: <3CFFAD41.441C0E@tel.fer.hr> Message-ID: <20020607113439.V32865-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN 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 Thu, 6 Jun 2002, Marko Zec wrote: > "Vladimir B. Grebenschikov" wrote: > > > =F7 Thu, 06.06.2002, =D7 18:48, Marko Zec =CE=C1=D0=C9=D3=C1=CC: > > > > > > # ifconfig fxp0 1.1.1.1/24 > > > > # ifconfig vlan0 1.1.1.1/32 > > > > # ifconfig vlan1 1.1.1.1/32 > > > > # ifconfig vlan2 1.1.1.1/32 > > > > > > This will never work - you can't have the same IP address/mask on mor= e than > > > one interface. > > > > Sure ? Do have try cut and paste my example into xterm ? > > > > vbook#/sys/i386/compile/VBOOK 142_> ifconfig -a > > lo0: flags=3D8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > fxp0: flags=3D8843 mtu 1500 > > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > > ether 08:00:46:04:31:b3 > > media: Ethernet autoselect (100baseTX) > > status: active > > vbook#/sys/i386/compile/VBOOK 143_> ifconfig lo0 1.1.1.1/32 alias > > vbook#/sys/i386/compile/VBOOK 144_> ifconfig fxp0 1.1.1.1/32 alias > > vbook#/sys/i386/compile/VBOOK 145_> uname -a > > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > > 15:49:21 MSD 2002 > > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > > vbook#/sys/i386/compile/VBOOK 147_> ifconfig -a > > lo0: flags=3D8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > inet 1.1.1.1 netmask 0xffffffff > > fxp0: flags=3D8843 mtu 1500 > > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > > inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 > > ether 08:00:46:04:31:b3 > > media: Ethernet autoselect (100baseTX) > > status: active > > > > Both addresses are work: > > > > vbook#/sys/i386/compile/VBOOK 153_> ping -R -S 1.1.1.1 127.0.0.1 > > PING 127.0.0.1 (127.0.0.1) from 1.1.1.1: 56 data bytes > > 64 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.167 ms > > RR: localhost (127.0.0.1) > > 1.1.1.1 > > 64 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.150 ms (= same > > route) > > vbook#/sys/i386/compile/VBOOK 154_> ping -n -R -S 1.1.1.1 192.168.1.109 > > PING 192.168.1.109 (192.168.1.109) from 1.1.1.1: 56 data bytes > > 64 bytes from 192.168.1.109: icmp_seq=3D0 ttl=3D64 time=3D1.836 ms > > RR: 192.168.1.109 > > 1.1.1.1 > > 64 bytes from 192.168.1.109: icmp_seq=3D1 ttl=3D64 time=3D1.600 ms (= same > > route) > > > > (use loopback not best way to do this, but you can try any interface) > > > > > What OS are you running? > > > > # uname -a > > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > > 15:49:21 MSD 2002 > > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > > > > Same setup works well on 4-STABLE > > In your original post, you were suggesting to put the same IP/mask on dif= ferent > "real" interfaces, not loopback. Could you pls. try to create a couple of= vlan > interfaces (ifconfig vlan0 create...), than configure them with the same = IP > addresses/masks as you suggested earlier, and show us the results of this > procedure? On my 4.6-RC system, such thing just don't work, thanks God. > > Marko > xl0: flags=3D8943 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xfffffe00 broadcast 212.36.9.255 ether 00:04:76:1b:cb:72 media: Ethernet autoselect (100baseTX ) status: active xl1: flags=3D8843 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:50:da:5b:b2:64 media: Ethernet autoselect (100baseTX ) status: active xl2: flags=3D8843 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:16:92 media: Ethernet autoselect (10baseT/UTP) status: active xl3: flags=3D8843 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:16:97 media: Ethernet autoselect (none) status: no carrier xl4: flags=3D8843 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:10:4b:b8:65:2c media: Ethernet autoselect (10baseT/UTP) status: active xl5: flags=3D8843 mtu 1500 options=3D3 inet 212.36.9.113 netmask 0xffffffff broadcast 212.36.9.113 ether 00:04:76:22:15:83 media: Ethernet autoselect (100baseTX) status: active As you see ip and mask are the same on 5 interfaces - it is realy realy working productional router. FreeBSD ShadoW.OTEL.net 4.5-STABLE FreeBSD 4.5-STABLE #3: Wed Apr 17 11:36:16 EE ST 2002 root@ShadoW.OTEL.net:/usr/src/sys/compile/SH-GW i386 Of course I can do that and on 4.6-RC. Just a little patch in netinet/in.c . And I wander who and why he put this "route addition check" when kernel tries to set host route for the interface. Before it works perfect with just a warring. And I realy need it to be that way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 1:52:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id F057C37B404 for ; Fri, 7 Jun 2002 01:52:07 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17GFTP-0000DH-00; Fri, 07 Jun 2002 12:51:55 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Iasen Kostov Cc: Marko Zec , freebsd-net@freebsd.org In-Reply-To: <20020607113439.V32865-100000@shadowhand.OTEL.net> References: <20020607113439.V32865-100000@shadowhand.OTEL.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 12:51:55 +0400 Message-Id: <1023439915.531.12.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Fri, 07.06.2002, =D7 12:42, Iasen Kostov =CE=C1=D0=C9=D3=C1=CC: > Of course I can do that and on 4.6-RC. Just a little patch in > netinet/in.c . And I wander who and why he put this "route addition check= " > when kernel tries to set host route for the interface. Before it works > perfect with just a warring. And I realy need it to be that way. I agree with you, actually we need have way to direct kernel do not add route while configure interface. =20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 2: 1:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 22C2937B403 for ; Fri, 7 Jun 2002 02:01:33 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17GFcg-0000EJ-00; Fri, 07 Jun 2002 13:01:30 +0400 Subject: Re: problems with ifconfig aliases From: "Vladimir B. " Grebenschikov To: "Joe T." Cc: freebsd-net@freebsd.org In-Reply-To: <20020607003631.46478.qmail@web10105.mail.yahoo.com> References: <20020607003631.46478.qmail@web10105.mail.yahoo.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 13:01:29 +0400 Message-Id: <1023440489.531.15.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Fri, 07.06.2002, =D7 04:36, Joe T. =CE=C1=D0=C9=D3=C1=CC: > Hi, >=20 > Originally, I had created some aliases with the following command: >=20 > # ifconfig dc0 alias 192.168.1.111 255.255.255.255 > # ifconfig dc0 alias 192.168.1.112 255.255.255.255 > ... >=20 > This worked fine.. i was able to use the aliases for various projects I w= as playing with. > When I was done, I took the aliases out: >=20 > # ifconfig dc0 -alias 192.168.1.111 255.255.255.255 > ... >=20 > Now, whever I try re-creating those aliases (or any different ones for th= at matter) I > get: >=20 > # ifconfig dc0 alias 192.168.1.111 255.255.255.255 > ifconfig: ioctl (SIOCAIFADDR): File exists > # ifconfig dc0 alias 192.168.1.2 255.255.255.255 <-- never used before > ifconfig: ioctl (SIOCAIFADDR): File exists >=20 > What happened here? What did I do wrong? How can I fix it? Check you routing table you have host routes for theses addresses in it, remove these routes before. > Any help is appreciated > Thanks, > Joe >=20 > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 4:36:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 06A1837B400 for ; Fri, 7 Jun 2002 04:36:46 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g57BahE8030485; Fri, 7 Jun 2002 13:36:43 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 7 Jun 2002 13:36:43 +0200 From: Christophe Prevotaux To: "Vladimir B. " Grebenschikov , Iasen Kostov Cc: net@freebsd.org Subject: Re: [HELP] IPless VLAN interfaces Message-Id: <20020607133643.066fcda6.c.prevotaux@hexanet.fr> In-Reply-To: <1023373804.470.20.camel@vbook.express.ru> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 All this is very interesting however I don't think this answers my question does it ? On 06 Jun 2002 18:30:04 +0400 "Vladimir B. " Grebenschikov wrote: > Ð_ Thu, 06.06.2002, в 14:51, Christophe Prevotaux напиÑ_ал: > > Hello > > > > I have a small problem I can't seem to be able to solve on > > FreeBSD 4-STABLE. > > > > I want to setup : > > > > - an interface fxp0 with an IP address with a /24 netmask > > - on this interface fxp0 I set up vlan0 vlan1 vlan2 > > - each vlan does not have an IP > > - I setup a route with the -iface option that point to each vlan > > repesctively > > > > on the other side > > > > I setup : > > machines behind each VLAN port > > each machine has an IP with a /24 netmask > > > > > > > > the setup works (ie: freebsd does not complain) > > however pinging a machine does not work so does any other type of > > traffic this does not work under FreeBSD , however when I do the > > same thing with Linux it does work. I believe there must be a way to > > do this under FreeBSD but I can't figure it out. > > > > Could someone help me or tell me what I did wrong ? > > > first try to specify source address to ping > > # ping -S 1.1.1.1 dest > > where 1.1.1.1 - address on fxp0 > > and you can set on your vlanX interfaces same addreses ad on your fxp0 > with netmask 255.255.255.255 > > # ifconfig fxp0 1.1.1.1/24 > # ifconfig vlan0 1.1.1.1 > # ifconfig vlan1 1.1.1.1 > # ifconfig vlan2 1.1.1.1 > > > > > > -- > > =============================================================== > > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > > HEXANET SARL URL: http://www.hexanet.fr/ > > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 > > 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 > > BP202 Fax: +33 (0)3 26 79 30 06 > > 51686 Reims Cedex 2 > > FRANCE HEXANET Network Operation Center > > =============================================================== > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > -- > Vladimir B. Grebenschikov > vova@sw.ru, SWsoft, Inc. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 5: 9:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 1A67D37B409 for ; Fri, 7 Jun 2002 05:09:18 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17GIVn-0000Oi-00; Fri, 07 Jun 2002 16:06:35 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Christophe Prevotaux Cc: Iasen Kostov , "net@freebsd.org" In-Reply-To: <20020607133643.066fcda6.c.prevotaux@hexanet.fr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <20020607133643.066fcda6.c.prevotaux@hexanet.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 16:06:35 +0400 Message-Id: <1023451595.531.20.camel@vbook.express.ru> Mime-Version: 1.0 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 =D0=92 Fri, 07.06.2002, =D0=B2 15:36, Christophe Prevotaux =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BB: > All this is very interesting however I don't think this answers my > question does it ? I am a bit not understand for what you have use such strange setup. And you have not provide enough information, to help you=20 I need as minimum=20 your network topology (how connected and switche(s), what port in trunc(802.1q) mode, what in not trunc) tcpdump -e on your trunc interface (fxp0) and tcpdump's on your client hosts while ping one and another direction > On 06 Jun 2002 18:30:04 +0400 > "Vladimir B. " Grebenschikov wrote: >=20 > > =C3=90_ Thu, 06.06.2002, =C3=90=C2=B2 14:51, Christophe Prevotaux =C3= =90=C2=BD=C3=90=C2=B0=C3=90=C2=BF=C3=90=C2=B8=C3=91_=C3=90=C2=B0=C3=90=C2= =BB: > > > Hello > > >=20 > > > I have a small problem I can't seem to be able to solve on > > > FreeBSD 4-STABLE. > > >=20 > > > I want to setup : > > >=20 > > > - an interface fxp0 with an IP address with a /24 netmask=20 > > > - on this interface fxp0 I set up vlan0 vlan1 vlan2=20 > > > - each vlan does not have an IP=20 > > > - I setup a route with the -iface option that point to each vlan > > > repesctively > > >=20 > > > on the other side > > >=20 > > > I setup : > > > machines behind each VLAN port=20 > > > each machine has an IP with a /24 netmask > > >=20 > > >=20 > > >=20 > > > the setup works (ie: freebsd does not complain)=20 > > > however pinging a machine does not work so does any other type of > > > traffic this does not work under FreeBSD , however when I do the > > > same thing with Linux it does work. I believe there must be a way to > > > do this under FreeBSD but I can't figure it out.=20 > > >=20 > > > Could someone help me or tell me what I did wrong ?=20 > >=20 > >=20 > > first try to specify source address to ping > >=20 > > # ping -S 1.1.1.1 dest > >=20 > > where 1.1.1.1 - address on fxp0 > >=20 > > and you can set on your vlanX interfaces same addreses ad on your fxp0 > > with netmask 255.255.255.255 > >=20 > > # ifconfig fxp0 1.1.1.1/24 > > # ifconfig vlan0 1.1.1.1 > > # ifconfig vlan1 1.1.1.1 > > # ifconfig vlan2 1.1.1.1 > >=20 > >=20 > > >=20 > > > -- > > > =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 > > > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > > > HEXANET SARL URL: http://www.hexanet.fr/ > > > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 > > > 3 All=C3=83=C2=A9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 > > > BP202 Fax: +33 (0)3 26 79 30 06 > > > 51686 Reims Cedex 2 =20 > > > FRANCE HEXANET Network Operation Center =20 > > > =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 > > >=20 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > >=20 > > --=20 > > Vladimir B. Grebenschikov > > vova@sw.ru, SWsoft, Inc. > >=20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > >=20 >=20 >=20 > -- > =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 > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > HEXANET SARL URL: http://www.hexanet.fr/ > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05=20 > 3 All=C3=A9e Thierry Sabine Direct: +33 (0)3 26 61 77 72=20 > BP202 Fax: +33 (0)3 26 79 30 06 > 51686 Reims Cedex 2 =20 > FRANCE HEXANET Network Operation Center =20 > =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 >=20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 5:34: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 83CAC37B400 for ; Fri, 7 Jun 2002 05:33:53 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g57CXpE8030618; Fri, 7 Jun 2002 14:33:51 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 7 Jun 2002 14:33:51 +0200 From: Christophe Prevotaux To: "Vladimir B. " Grebenschikov Cc: net@freebsd.org Subject: Re: [HELP] IPless VLAN interfaces Message-Id: <20020607143351.6889eb27.c.prevotaux@hexanet.fr> In-Reply-To: <1023451595.531.20.camel@vbook.express.ru> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <20020607133643.066fcda6.c.prevotaux@hexanet.fr> <1023451595.531.20.camel@vbook.express.ru> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 As I have said before I am using VLAN on FreeBSD ,which is obviously 802.11Q, connected to a switch configured with VLAN 802.11Q ports attached to the FreeBSD Box on one side thru the ethernet interface of that box. On the other side on the same swtich I have vlan ports (802.11Q obviously) which untag packets and deliver them to the boxen behind these VLAN here is a small picture (I hope this does not gets mangled) 802.11Q | --------------+ +--vlan1--+ +-------------+ | FreeBSD Box +- fxp0-+--vlan2--+---Port1-+ Switch +--port4--Host3 --------------+ +--vlan3--+ +---+------+--+ vlan3 | | 802.11Q port2 port3 vlan1 vlan2 802.11Q 802.11Q | | | +---Host2 | +---- Host1 fxp0 has IP in a /24 vlan1 has no IP vlan2 has no IP vlan3 has no IP Host1 has an IP in the same /24 as the fxp0 Host2 has an IP in the same /24 as the fxp0 Host3 has an IP in the same /24 as the fxp0 802.11Q untagging is done at the port2 , port3 and port4 of the switch I add route using the "-iface" option of the "route" command in order to obtain a route that point to each vlan. All of this works under Linux but not under FreeBSD I hope this clarifies what I am trying to do On 07 Jun 2002 16:06:35 +0400 "Vladimir B. "Grebenschikov wrote: > Ð_ Fri, 07.06.2002, в 15:36, Christophe Prevotaux напиÑ_ал: > > All this is very interesting however I don't think this answers my > > question does it ? > > I am a bit not understand for what you have use such strange setup. > > And you have not provide enough information, to help you > I need as minimum > your network topology (how connected and switche(s), what port in > trunc(802.1q) mode, what in not trunc) > > tcpdump -e on your trunc interface (fxp0) and tcpdump's on your client > hosts > while ping one and another direction > > > > > On 06 Jun 2002 18:30:04 +0400 > > "Vladimir B. " Grebenschikov wrote: > > > > > Ã__ Thu, 06.06.2002, Ã_² 14:51, Christophe Prevotaux Ã_½Ã_°Ã_¿Ã_¸Ã__Ã_°Ã_»: > > > > Hello > > > > > > > > I have a small problem I can't seem to be able to solve on > > > > FreeBSD 4-STABLE. > > > > > > > > I want to setup : > > > > > > > > - an interface fxp0 with an IP address with a /24 netmask > > > > - on this interface fxp0 I set up vlan0 vlan1 vlan2 > > > > - each vlan does not have an IP > > > > - I setup a route with the -iface option that point to each vlan > > > > repesctively > > > > > > > > on the other side > > > > > > > > I setup : > > > > machines behind each VLAN port > > > > each machine has an IP with a /24 netmask > > > > > > > > > > > > > > > > the setup works (ie: freebsd does not complain) > > > > however pinging a machine does not work so does any other type of > > > > traffic this does not work under FreeBSD , however when I do the > > > > same thing with Linux it does work. I believe there must be a way to > > > > do this under FreeBSD but I can't figure it out. > > > > > > > > Could someone help me or tell me what I did wrong ? > > > > > > > > > first try to specify source address to ping > > > > > > # ping -S 1.1.1.1 dest > > > > > > where 1.1.1.1 - address on fxp0 > > > > > > and you can set on your vlanX interfaces same addreses ad on your fxp0 > > > with netmask 255.255.255.255 > > > > > > # ifconfig fxp0 1.1.1.1/24 > > > # ifconfig vlan0 1.1.1.1 > > > # ifconfig vlan1 1.1.1.1 > > > # ifconfig vlan2 1.1.1.1 > > > > > > > > > > > > > > -- > > > > =============================================================== > > > > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > > > > HEXANET SARL URL: http://www.hexanet.fr/ > > > > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 > > > > 3 AllÃ_©e Thierry Sabine Direct: +33 (0)3 26 61 77 72 > > > > BP202 Fax: +33 (0)3 26 79 30 06 > > > > 51686 Reims Cedex 2 > > > > FRANCE HEXANET Network Operation Center > > > > =============================================================== > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > -- > > > Vladimir B. Grebenschikov > > > vova@sw.ru, SWsoft, Inc. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > -- > > =============================================================== > > Christophe Prevotaux Email: c.prevotaux@hexanet.fr > > HEXANET SARL URL: http://www.hexanet.fr/ > > Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 > > 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 > > BP202 Fax: +33 (0)3 26 79 30 06 > > 51686 Reims Cedex 2 > > FRANCE HEXANET Network Operation Center > > =============================================================== > > > -- > Vladimir B. Grebenschikov > vova@sw.ru, SWsoft, Inc. > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 5:47:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id 8538737B404 for ; Fri, 7 Jun 2002 05:47:46 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17GJ9b-0000Qd-00; Fri, 07 Jun 2002 16:47:43 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Christophe Prevotaux Cc: "net@freebsd.org" In-Reply-To: <20020607143351.6889eb27.c.prevotaux@hexanet.fr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <20020607133643.066fcda6.c.prevotaux@hexanet.fr> <1023451595.531.20.camel@vbook.express.ru> <20020607143351.6889eb27.c.prevotaux@hexanet.fr> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 16:47:43 +0400 Message-Id: <1023454063.531.22.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Fri, 07.06.2002, =D7 16:33, Christophe Prevotaux =CE=C1=D0=C9=D3=C1=CC: > As I have said before I am using VLAN on FreeBSD ,which is obviously > 802.11Q, connected to a switch configured with VLAN 802.11Q ports attache= d > to the FreeBSD Box on one side thru the ethernet interface of that box. >=20 > On the other side on the same swtich I have vlan ports (802.11Q obviously= ) > which untag packets and deliver them to the boxen behind these VLAN >=20 >=20 > here is a small picture (I hope this does not gets mangled) >=20 >=20 > 802.11Q > | > --------------+ +--vlan1--+ +-------------+ > | FreeBSD Box +- fxp0-+--vlan2--+---Port1-+ Switch +--port4--Host3 > --------------+ +--vlan3--+ +---+------+--+ vlan3 > | | 802.11Q > port2 port3 > vlan1 vlan2 > 802.11Q 802.11Q > | | > | +---Host2 > | =20 > +---- Host1 >=20 > fxp0 has IP in a /24 > vlan1 has no IP > vlan2 has no IP > vlan3 has no IP > Host1 has an IP in the same /24 as the fxp0=20 > Host2 has an IP in the same /24 as the fxp0 > Host3 has an IP in the same /24 as the fxp0 > 802.11Q untagging is done at the port2 , port3 and port4 of the switch >=20 > I add route using the "-iface" option of the "route" command in order to > obtain a route that point to each vlan. please, send me 'netstat -rn'=20 > All of this works under Linux but not under FreeBSD >=20 > I hope this clarifies what I am trying to do =20 --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 5:50:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id AF60437B403 for ; Fri, 7 Jun 2002 05:50:38 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GJCN-000GxH-00; Fri, 07 Jun 2002 15:50:35 +0300 Date: Fri, 7 Jun 2002 15:50:35 +0300 (EEST) From: Iasen Kostov To: freebsd-net@FreeBSD.ORG Cc: vova@sw.ru Subject: Re: host routes for interface addresses In-Reply-To: <20020606140015.B27474-100000@shadowhand.OTEL.net> Message-ID: <20020607152801.T32865-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 I think it's possible to use SIOCSIFCAP to tell the kernel not to set host route via IFCAP_NOROUTE or something similar which will set IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit() and if it is set no host route will be added. And ofcourse there should be a way to set this by ifconfig ( -noroute for example). What you think about this ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 6:44:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 43EF337B401 for ; Fri, 7 Jun 2002 06:44:23 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g57DiLE8030777; Fri, 7 Jun 2002 15:44:21 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 7 Jun 2002 15:44:20 +0200 From: Christophe Prevotaux To: net@freebsd.org Cc: "Vladimir B. " Grebenschikov Subject: Re: [HELP] IPless VLAN interfaces [variant] Message-Id: <20020607154420.5a7a9222.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 would be equally happy if I could this : 802.11Q | --------------+ +--vlan1--+ +-------------+ | FreeBSD Box +- fxp0-+--vlan2--+---Port1-+ Switch +--port4--Host3 --------------+ +--vlan3--+ +---+------+--+ vlan3 | | 802.11Q port2 port3 vlan1 vlan2 802.11Q 802.11Q | | | +---Host2 | +---- Host1 fxp0 has IP in a /24 (ie: 192.168.1.1/24) vlan1 has the same IP as the fxp0 with a /24 (ie: 192.168.1.1/24) vlan2 has the same IP as the fxp0 with a /24 (ie: 192.168.1.1/24) vlan3 has the same IP as the fxp0 with a /24 (ie: 192.168.1.1/24) Host1 has an IP in the same /24 as the fxp0 (ie: 192.168.1.2/24) Host2 has an IP in the same /24 as the fxp0 (ie: 192.168.1.3/24) Host3 has an IP in the same /24 as the fxp0 (ie: 192.168.1.4/24) 802.11Q untagging is done at the port2 , port3 and port4 of the switch I add route using the "-iface" option of the "route" command in order to obtain a route that point to each vlan. -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 7:27:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id B7A0037B40A for ; Fri, 7 Jun 2002 07:27:48 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GKiQ-000IgB-00; Fri, 07 Jun 2002 17:27:46 +0300 Date: Fri, 7 Jun 2002 17:27:46 +0300 (EEST) From: Iasen Kostov To: freebsd-net@FreeBSD.ORG Cc: vova@sw.ru Subject: Re: host routes for interface addresses In-Reply-To: <20020607152801.T32865-100000@shadowhand.OTEL.net> Message-ID: <20020607170224.G32865-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, 7 Jun 2002, Iasen Kostov wrote: > > I think it's possible to use SIOCSIFCAP to tell the kernel not to set > host route via IFCAP_NOROUTE or something similar which will set > IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit() > and if it is set no host route will be added. And ofcourse there should be > a way to set this by ifconfig ( -noroute for example). > What you think about this ? > Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by SIOCGIFFLAGS ioctl. What you think ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 8:28: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 3821037B404 for ; Fri, 7 Jun 2002 08:27:59 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g57FRvE8031516; Fri, 7 Jun 2002 17:27:58 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Fri, 7 Jun 2002 17:27:57 +0200 From: Christophe Prevotaux To: "Vladimir B. " Grebenschikov Cc: net@freebsd.org Subject: Re: [HELP] IPless VLAN interfaces Message-Id: <20020607172757.4f37c70c.c.prevotaux@hexanet.fr> In-Reply-To: <1023376206.470.40.camel@vbook.express.ru> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> <1023376206.470.40.camel@vbook.express.ru> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 try to setup this (it won't work) your example does not work ifconfig fxp0 inet 192.168.1.1/24 up ifconfig fxp0 inet 192.168.1.1/32 alias ifconfig fxp0 inet 192.168.1.1/32 alias <--- here it will not work anymore this is the same thing with vlan interfaces under FreeBSD you can't have more than 1 interface with the same IP/NETMASK ifconfig fxp0 inet 192.168.1.1/24 up ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/32 up ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/32 up <-- this does not work let's say for the example sake , that you want only to have 1 vlan on the fxp0 then you can setup the interface as shown above but you can't route anything thru it route add 192.168.1.2 -interface vlan0 will not route properly the packets thru vlan0 either because it is a /32 (AFAIK) and even if you could do it , then the problem is that you are limited to having only one vlan per interface, which sucks BIG TIME. under Linux you can have the equivalent of the following setup: 192.168.1.2/24 192.168.1.3/24 192.168.1.4/24 are machines behind the switch vlan 1 2 3 ports respectively ifconfig fxp0 inet 192.168.1.1/24 up ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/24 up ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/24 up ifconfig create vlan2 inet vlan 3 vlandev fxp0 192.168.1.1/24 up etc... etc... and then you do the equivalent of route add 192.168.1.2 -interface vlan0 route add 192.168.1.3 -interface vlan1 route add 192.168.1.4 -interface vlan2 and it works just fine, with no problems whatsoever. What I want to do is just this but under FreeBSD. My question is : How can I do it ? On 06 Jun 2002 19:10:06 +0400 "Vladimir B. " Grebenschikov wrote: > ÷ Thu, 06.06.2002, × 18:48, Marko Zec ÎÁÐÉÓÁÌ: > > > > # ifconfig fxp0 1.1.1.1/24 > > > # ifconfig vlan0 1.1.1.1/32 > > > # ifconfig vlan1 1.1.1.1/32 > > > # ifconfig vlan2 1.1.1.1/32 > > > > This will never work - you can't have the same IP address/mask on more than > > one interface. > > Sure ? Do have try cut and paste my example into xterm ? > > vbook#/sys/i386/compile/VBOOK 142_> ifconfig -a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > fxp0: flags=8843 mtu 1500 > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > ether 08:00:46:04:31:b3 > media: Ethernet autoselect (100baseTX) > status: active > vbook#/sys/i386/compile/VBOOK 143_> ifconfig lo0 1.1.1.1/32 alias > vbook#/sys/i386/compile/VBOOK 144_> ifconfig fxp0 1.1.1.1/32 alias > vbook#/sys/i386/compile/VBOOK 145_> uname -a > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > 15:49:21 MSD 2002 > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > vbook#/sys/i386/compile/VBOOK 147_> ifconfig -a > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet 1.1.1.1 netmask 0xffffffff > fxp0: flags=8843 mtu 1500 > inet 192.168.1.111 netmask 0xffffff00 broadcast 192.168.1.255 > inet 1.1.1.1 netmask 0xffffffff broadcast 1.1.1.1 > ether 08:00:46:04:31:b3 > media: Ethernet autoselect (100baseTX) > status: active > > Both addresses are work: > > vbook#/sys/i386/compile/VBOOK 153_> ping -R -S 1.1.1.1 127.0.0.1 > PING 127.0.0.1 (127.0.0.1) from 1.1.1.1: 56 data bytes > 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.167 ms > RR: localhost (127.0.0.1) > 1.1.1.1 > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.150 ms (same > route) > vbook#/sys/i386/compile/VBOOK 154_> ping -n -R -S 1.1.1.1 192.168.1.109 > PING 192.168.1.109 (192.168.1.109) from 1.1.1.1: 56 data bytes > 64 bytes from 192.168.1.109: icmp_seq=0 ttl=64 time=1.836 ms > RR: 192.168.1.109 > 1.1.1.1 > 64 bytes from 192.168.1.109: icmp_seq=1 ttl=64 time=1.600 ms (same > route) > > (use loopback not best way to do this, but you can try any interface) > > > What OS are you running? > > # uname -a > FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri May 24 > 15:49:21 MSD 2002 > root@vbook.express.ru:/usr/obj/usr/local/src/sys/VBOOK i386 > > Same setup works well on 4-STABLE > > > > Marko > > > -- > Vladimir B. Grebenschikov > vova@sw.ru, SWsoft, Inc. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 13: 0:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id F1AAB37B415 for ; Fri, 7 Jun 2002 13:00:02 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA12231 for ; Fri, 7 Jun 2002 12:57:07 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g57JtrJ65814 for freebsd-net@freebsd.org; Fri, 7 Jun 2002 12:55:53 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206071955.g57JtrJ65814@arch20m.dellroad.org> Subject: m->m_pkthdr.header To: freebsd-net@freebsd.org Date: Fri, 7 Jun 2002 12:55:53 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (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 Hi, I'd like to get rid of this mbuf field "m->m_pkthdr.header". Here are my reasons: - It's broken. Consider this code: copy = m_copypacket(m); m_freem(m); Typically m->m_pkthdr.header points into the data area of 'm'. So now copy->m_pkthdr.header points at the same data, which has already been freed and possibly reused. - It is an obscure thing most people don't know about and is ripe for causing hard to find bugs. - It's only used in two places, (a) for secret communication between the oltr driver and if_ether.c, and (b) as a temporary variable in ip_input.c: $ find . -type f -print | xargs grep -w m_pkthdr.header ./contrib/dev/oltr/if_oltr.c: m0->m_pkthdr.header = (void *)th; ./netinet/if_ether.c: th = (struct iso88025_header *)m->m_pkthdr.header; ./netinet/ip_input.c: m->m_pkthdr.header = ip; ./netinet/ip_input.c:#define GETIP(m) ((struct ip*)((m)->m_pkthdr.header)) My proposal: - Replace the obfuscating GETIP() macro in ip_input.c with a variable. - Rejigger the oltr driver to pass its "secret" information using an auxillary mbuf instead of m->m_pkthdr.header. Any comments/objections? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 13:16:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 7208337B404 for ; Fri, 7 Jun 2002 13:16:52 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g57KFSi88174; Fri, 7 Jun 2002 16:15:28 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 7 Jun 2002 16:15:28 -0400 From: Bosko Milekic To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: m->m_pkthdr.header Message-ID: <20020607161528.A88123@unixdaemons.com> References: <200206071955.g57JtrJ65814@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206071955.g57JtrJ65814@arch20m.dellroad.org>; from archie@dellroad.org on Fri, Jun 07, 2002 at 12:55:53PM -0700 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, Jun 07, 2002 at 12:55:53PM -0700, Archie Cobbs wrote: > Hi, > > I'd like to get rid of this mbuf field "m->m_pkthdr.header". > Here are my reasons: > > - It's broken. Consider this code: > > copy = m_copypacket(m); > m_freem(m); Indeed, this is a bug in m_copypacket(). It should copy the data over, but again, admittedly, this is a very dangerous practise! Ideally, what ought to happen is that the copying over needs to be done by the code calling m_copypacket(), right after the m_copypacket() call but before the m_freem() call. The reason to do it from the caller code and not from m_copypacket() is that there is no reasonable way to determine, from m_copypacket(), whether or not one of our header/mbuf pointers points to a data inside the mbuf or whether it is safe to do the shallow pointer copy. > Typically m->m_pkthdr.header points into the data area of 'm'. > So now copy->m_pkthdr.header points at the same data, which has > already been freed and possibly reused. > > - It is an obscure thing most people don't know about and is > ripe for causing hard to find bugs. > > - It's only used in two places, (a) for secret communication between > the oltr driver and if_ether.c, and (b) as a temporary variable > in ip_input.c: > > $ find . -type f -print | xargs grep -w m_pkthdr.header > ./contrib/dev/oltr/if_oltr.c: m0->m_pkthdr.header = (void *)th; > ./netinet/if_ether.c: th = (struct iso88025_header *)m->m_pkthdr.header; > ./netinet/ip_input.c: m->m_pkthdr.header = ip; > ./netinet/ip_input.c:#define GETIP(m) ((struct ip*)((m)->m_pkthdr.header)) > > My proposal: > > - Replace the obfuscating GETIP() macro in ip_input.c with a variable. > - Rejigger the oltr driver to pass its "secret" information using > an auxillary mbuf instead of m->m_pkthdr.header. > > Any comments/objections? None from here. :-) Just the standard pointer, which you probably already know: -CURRENT first, please. > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com Regards, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 13:30:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0B32537B407 for ; Fri, 7 Jun 2002 13:30:05 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA12398; Fri, 7 Jun 2002 13:18:28 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g57KHEE66016; Fri, 7 Jun 2002 13:17:14 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206072017.g57KHEE66016@arch20m.dellroad.org> Subject: Re: m->m_pkthdr.header In-Reply-To: <200206071955.g57JtrJ65814@arch20m.dellroad.org> "from Archie Cobbs at Jun 7, 2002 12:55:53 pm" To: Archie Cobbs Date: Fri, 7 Jun 2002 13:17:14 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Archie Cobbs writes: > My proposal: > > - Replace the obfuscating GETIP() macro in ip_input.c with a variable. > - Rejigger the oltr driver to pass its "secret" information using > an auxillary mbuf instead of m->m_pkthdr.header. On second thought, it seems that GETIP(m) in ip_input.c is an optimization. So I should leave that alone. The new proposal is simply to: - Rejigger the oltr driver to pass its "secret" information using an auxillary mbuf instead of m->m_pkthdr.header. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 13:40:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 60FE737B405 for ; Fri, 7 Jun 2002 13:40:10 -0700 (PDT) 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 <20020607204010.ZXFN11426.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 7 Jun 2002 20:40:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA65580; Fri, 7 Jun 2002 13:29:37 -0700 (PDT) Date: Fri, 7 Jun 2002 13:29:36 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: m->m_pkthdr.header In-Reply-To: <200206071955.g57JtrJ65814@arch20m.dellroad.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 Fri, 7 Jun 2002, Archie Cobbs wrote: > Hi, > > I'd like to get rid of this mbuf field "m->m_pkthdr.header". > Here are my reasons: > > - It's broken. Consider this code: > > copy = m_copypacket(m); > m_freem(m); > > Typically m->m_pkthdr.header points into the data area of 'm'. > So now copy->m_pkthdr.header points at the same data, which has > already been freed and possibly reused. > > - It is an obscure thing most people don't know about and is > ripe for causing hard to find bugs. the comment says: 82 /* variables for ip and tcp reassembly */ 83 void *header; /* pointer to packet header */ which seems untrue.. in any case it's WAY out of scope. that is a protocol specific thing.. for that matter the use of the header for 84 /* variables for hardware checksum */ 85 int csum_flags; /* flags regarding checksum*/ 86 int csum_data; /* data field used by csum routines */ seem also to be way out of scope. there should be some other protocol-specific way to associate this information with a packet. > > - It's only used in two places, (a) for secret communication between > the oltr driver and if_ether.c, and (b) as a temporary variable > in ip_input.c: are tehy the only things that break if you compile LINT with it commented out? > > $ find . -type f -print | xargs grep -w m_pkthdr.header > ./contrib/dev/oltr/if_oltr.c: m0->m_pkthdr.header = (void *)th; > ./netinet/if_ether.c: th = (struct iso88025_header *)m->m_pkthdr.header; > ./netinet/ip_input.c: m->m_pkthdr.header = ip; > ./netinet/ip_input.c:#define GETIP(m) ((struct ip*)((m)->m_pkthdr.header)) > > My proposal: > > - Replace the obfuscating GETIP() macro in ip_input.c with a variable. well I BELIEVE that this wouldn't work after the packet has been queued for reassembly... but I guess you could manage it.. > - Rejigger the oltr driver to pass its "secret" information using > an auxillary mbuf instead of m->m_pkthdr.header. The whole issue of auxiliary dataa (metadata) and protocol specific data storage needs to be solved once and for all.. (we have our own answer in Netgraph but it's a stopgap) > > Any comments/objections? > > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > 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 Jun 7 14:28:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by hub.freebsd.org (Postfix) with ESMTP id 4045137B401 for ; Fri, 7 Jun 2002 14:28:23 -0700 (PDT) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.12.2/8.12.2) with ESMTP id g57LSL2A063922; Fri, 7 Jun 2002 17:28:21 -0400 (EDT) (envelope-from winter@jurai.net) Date: Fri, 7 Jun 2002 17:28:21 -0400 (EDT) From: "Matthew N. Dodd" To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: m->m_pkthdr.header In-Reply-To: <200206071955.g57JtrJ65814@arch20m.dellroad.org> Message-ID: <20020607172612.G42854-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, 7 Jun 2002, Archie Cobbs wrote: > - Rejigger the oltr driver to pass its "secret" information using > an auxillary mbuf instead of m->m_pkthdr.header. > > Any comments/objections? Please look at the 'kluge' that NetBSD uses. netinet/if_arp.c: trh = (struct token_header *)M_TRHSTART(m); net/if_token.h: /* * This is a kludge to get at the token ring mac header and the source route * information after m_adj() has been used on the mbuf. * Note that m is always an mbuf with a packet header. */ #define M_TRHSTART(m) \ (ALIGN(((m)->m_flags & M_EXT ? (m)->m_ext.ext_buf : &(m)->m_pktdat[0]) \ + sizeof (struct token_header)) - sizeof(struct token_header)) -- | 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 Jun 7 15: 2:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by hub.freebsd.org (Postfix) with ESMTP id 5F40537B400 for ; Fri, 7 Jun 2002 15:02:53 -0700 (PDT) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.1/8.12.1) with ESMTP id g57M2mKs021980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 7 Jun 2002 15:02:48 -0700 (PDT)?g (envelope-from sam@errno.com)œ Message-ID: <001901c20e6f$0fd32610$52557f42@errno.com> From: "Sam Leffler" To: "Julian Elischer" , "Archie Cobbs" Cc: References: Subject: Re: m->m_pkthdr.header Date: Fri, 7 Jun 2002 15:02:47 -0700 Organization: Errno Consulting 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 > The whole issue of auxiliary dataa (metadata) and protocol specific > data storage needs to be solved once and for all.. > (we have our own answer in Netgraph but it's a stopgap) I adopted the openbsd m_tag stuff and jetisoned m_aux entirely. I did this for many reasons, not the least is that it's used to communicate crypto processing done by NICs up to the IPSEC stack. This also cleaned up the KAME code and also sets up removal of all the global variable crud in the IP protocol handling (by ipfw, the bridge code, etc.). The m_tag changes are straightforward but right now there tied up in more extensive mods for hardware crypto acceleration that are unfinished. Going this route also improves compatiblity with openbsd which makes porting drivers simpler. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 7 16: 0:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4A99537B409 for ; Fri, 7 Jun 2002 16:00:48 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA13255; Fri, 7 Jun 2002 15:50:02 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g57MmmE66619; Fri, 7 Jun 2002 15:48:48 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206072248.g57MmmE66619@arch20m.dellroad.org> Subject: Re: m->m_pkthdr.header In-Reply-To: <20020607172612.G42854-100000@sasami.jurai.net> "from Matthew N. Dodd at Jun 7, 2002 05:28:21 pm" To: "Matthew N. Dodd" Date: Fri, 7 Jun 2002 15:48:48 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (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 Matthew N. Dodd writes: > > - Rejigger the oltr driver to pass its "secret" information using > > an auxillary mbuf instead of m->m_pkthdr.header. > > > > Any comments/objections? > > Please look at the 'kluge' that NetBSD uses. > > netinet/if_arp.c: > trh = (struct token_header *)M_TRHSTART(m); > > net/if_token.h: > /* > * This is a kludge to get at the token ring mac header and the source route > * information after m_adj() has been used on the mbuf. > * Note that m is always an mbuf with a packet header. > */ > #define M_TRHSTART(m) \ > (ALIGN(((m)->m_flags & M_EXT ? (m)->m_ext.ext_buf : &(m)->m_pktdat[0]) \ > + sizeof (struct token_header)) - sizeof(struct token_header)) Thanks for the reference. This kludge is only slightly better than FreeBSD's kludge and either way it is the root of the problem. It's simply not valid to rely on data m_adj'ed out of an mbuf always being there. If somebody calls m_copypacket() or m_pullup(), you're out of luck. FYI, the *real* problem I'm trying to solve is that in_arpinput() stomps all over its mbuf without first checking M_WRITABLE(m). The patch below would work nicely except it breaks this token ring hack. I'm tempted to just check it in and let the token ring people fix their own bug instead of doing it for them. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- /sys/netinet/if_ether.c Wed Dec 26 09:36:36 2001 +++ netinet/if_ether.c Fri Jun 7 15:43:30 2002 @@ -675,6 +675,15 @@ m_freem(m); return; } + + /* Ensure the mbuf is writable before stomping on it */ + if (!M_WRITABLE(m)) { + if ((m = m_pullup(m, sizeof(struct ether_arp))) == NULL) + return; + ea = mtod(m, struct ether_arp *); + } + + /* Check the target IP address */ if (itaddr.s_addr == myaddr.s_addr) { /* I am the target */ (void)memcpy(ea->arp_tha, ea->arp_sha, sizeof(ea->arp_sha)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 6:15: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 5F4C437B40A for ; Sat, 8 Jun 2002 06:15:01 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g58DExKZ061293; Sat, 8 Jun 2002 14:15:00 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g58DEw9B099140; Sat, 8 Jun 2002 14:14:58 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 8 Jun 2002 14:14:58 +0100 From: Brian Somers To: "Joe T." Cc: freebsd-net@FreeBSD.ORG Subject: Re: problems with ifconfig aliases Message-Id: <20020608141458.1d12b1cb.brian@Awfulhak.org> In-Reply-To: <20020607003631.46478.qmail@web10105.mail.yahoo.com> References: <20020607003631.46478.qmail@web10105.mail.yahoo.com> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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, 6 Jun 2002 17:36:31 -0700 (PDT), "Joe T." wrote: > Hi, > > Originally, I had created some aliases with the following command: > > # ifconfig dc0 alias 192.168.1.111 255.255.255.255 > # ifconfig dc0 alias 192.168.1.112 255.255.255.255 You forgot the netmask keyword. The missing keyword means that it tries to use 255.255.255.255 as the destination address and silently fails as the interface isn't a pointopoint interface. The failure is due to conflicting host route entries because you didn't give the correct netmask. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 6:51:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id D6A3037B405 for ; Sat, 8 Jun 2002 06:51:38 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g58DpaKZ061394; Sat, 8 Jun 2002 14:51:36 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g58DpY9B099330; Sat, 8 Jun 2002 14:51:34 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 8 Jun 2002 14:51:34 +0100 From: Brian Somers To: Iasen Kostov Cc: freebsd-net@FreeBSD.ORG, vova@sw.ru Subject: Re: host routes for interface addresses Message-Id: <20020608145134.07fda923.brian@Awfulhak.org> In-Reply-To: <20020607170224.G32865-100000@shadowhand.OTEL.net> References: <20020607152801.T32865-100000@shadowhand.OTEL.net> <20020607170224.G32865-100000@shadowhand.OTEL.net> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov wrote: > > > On Fri, 7 Jun 2002, Iasen Kostov wrote: > > > > > I think it's possible to use SIOCSIFCAP to tell the kernel not to set > > host route via IFCAP_NOROUTE or something similar which will set > > IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit() > > and if it is set no host route will be added. And ofcourse there should be > > a way to set this by ifconfig ( -noroute for example). > > What you think about this ? > > > Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by > SIOCGIFFLAGS ioctl. > What you think ? The problem is that ifnet::if_flags is a short and all of it's bits are already used up :( -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 7: 4:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 0575B37B400 for ; Sat, 8 Jun 2002 07:04:28 -0700 (PDT) Received: by hanoi.cronyx.ru id SAA29231 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Sat, 8 Jun 2002 18:02:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id SAA29213 for ; (8.9.3/vak/2.1) Sat, 8 Jun 2002 18:01:40 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <3D021002.8000101@cronyx.ru> Date: Sat, 08 Jun 2002 18:09:06 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: PC-based router characteristic Content-Type: text/plain; charset=KOI8-R; 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, Does anybody know articles about measurement of router characteristics, especially PC-based routers? Best regards, Roman Kurakin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 8:34: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id 0E6D537B406 for ; Sat, 8 Jun 2002 08:33:58 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GiDo-000ILK-00; Sat, 08 Jun 2002 18:33:44 +0300 Date: Sat, 8 Jun 2002 18:33:44 +0300 (EEST) From: Iasen Kostoff To: Brian Somers Cc: Iasen Kostov , , Subject: Re: host routes for interface addresses In-Reply-To: <20020608145134.07fda923.brian@Awfulhak.org> Message-ID: <20020608171620.S34125-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 Sat, 8 Jun 2002, Brian Somers wrote: > On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov wrote: > > > > > > On Fri, 7 Jun 2002, Iasen Kostov wrote: > > > > > > > > I think it's possible to use SIOCSIFCAP to tell the kernel not to set > > > host route via IFCAP_NOROUTE or something similar which will set > > > IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit() > > > and if it is set no host route will be added. And ofcourse there should be > > > a way to set this by ifconfig ( -noroute for example). > > > What you think about this ? > > > > > Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by > > SIOCGIFFLAGS ioctl. > > What you think ? > > The problem is that ifnet::if_flags is a short and all of it's bits are > already used up :( > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > Yep but I think I solve the problem. I found this in net/if.h : /* * 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. */ and decide to use if_ipending utill extend of if_flags. Just add to the ifr_ifru union of the ifreq struct: int ifru_flagslong; and this: #define ifr_flagslong ifr_ifru.ifru_flagslong /* long flags (int) */ than in net/if.c I've changed SIOCGIFFLAGS and SIOCSIFFLAGS handling in ifioctl() function like this: case SIOCGIFFLAGS: flagslong = ifp->if_flags & 0x0000ffff; ifr->ifr_flagslong = flagslong | ifp->if_ipending; break; case SIOCSIFFLAGS: error = suser(p); if (error) return (error); -> ifp->if_ipending = ifr->ifr_flagslong & 0xffff0000; ... than ofcourse I fixed and ifconfig's function setifflags() to use ifr_flagslong value instead of ifr_flags. It's a partial solution. Sysctl that returns iface table should do the same thing as SIOCGIFFLAGS handler. I saw that ifm_flags is int that means there will not be a problem when sysctl is returning the new flags. And I think this doesn't break anything in binary compatibility. To test all this I add this 2 lines to cmds[] declaration in ifconfig.c : { "noroute", IFF_NOROUTE, setifflags }, { "-noroute", -IFF_NOROUTE, setifflags }, and this line to net/if.h : #define IFF_NOROUTE 0x20000 /* Interface doesn't need host route. */ Than a fixed in.c and add a IFF_NOROUTE check in in_ifinit() : ... if (!(ifp->if_ipending & IFF_NOROUTE)) if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY || ... And everything work perfect for me on the test machine : root@test:/sys/netinet on ttyp1 #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 noroute root@test:/sys/netinet on ttyp1 #:> netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 212.36.8.137 UGSc 0 4 ed1 127.0.0.1 127.0.0.1 UH 1 10 lo0 212.36.8/23 link#2 UC 4 0 ed1 root@test:/sys/netinet on ttyp1 #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 -noroute root@test:/sys/netinet on ttyp1 #:> netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 212.36.8.137 UGSc 0 4 ed1 10/16 link#1 UC 0 0 ed0 127.0.0.1 127.0.0.1 UH 1 10 lo0 212.36.8/23 link#2 UC 3 0 ed1 Could it be done that way, what You think ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 9:16:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id E490C37B408 for ; Sat, 8 Jun 2002 09:16:27 -0700 (PDT) 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 g58GG7f07727; Sat, 8 Jun 2002 09:16:07 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g58GG6v03893; Sat, 8 Jun 2002 09:16:06 -0700 (PDT) (envelope-from jdp) Date: Sat, 8 Jun 2002 09:16:06 -0700 (PDT) Message-Id: <200206081616.g58GG6v03893@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: archie@dellroad.org Subject: Re: m->m_pkthdr.header In-Reply-To: <200206071955.g57JtrJ65814@arch20m.dellroad.org> References: <200206071955.g57JtrJ65814@arch20m.dellroad.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 <200206071955.g57JtrJ65814@arch20m.dellroad.org>, Archie Cobbs wrote: > > I'd like to get rid of this mbuf field "m->m_pkthdr.header". [...] > Any comments/objections? Yes, please bear in mind that if you change the layout of the mbuf structures you will probably break binary compatibility with various commercial network drivers that are shipped in binary form. That's a big pain for those of us who are forced to use such drivers. For that reason I don't think you should make this kind of change in -stable. Current is obviously a different kettle of fish, but even there you should add fillers to replace any structure elements you remove, if possible. 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 Sat Jun 8 9:24:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 2469337B40A for ; Sat, 8 Jun 2002 09:24:37 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g58GOZKZ055919; Sat, 8 Jun 2002 17:24:35 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g58GOX9B050707; Sat, 8 Jun 2002 17:24:33 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 8 Jun 2002 17:24:32 +0100 From: Brian Somers To: Iasen Kostoff Cc: ikostov@otel.net, freebsd-net@FreeBSD.ORG, vova@sw.ru Subject: Re: host routes for interface addresses Message-Id: <20020608172432.3f030ceb.brian@Awfulhak.org> In-Reply-To: <20020608171620.S34125-100000@shadowhand.OTEL.net> References: <20020608145134.07fda923.brian@Awfulhak.org> <20020608171620.S34125-100000@shadowhand.OTEL.net> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 This certainly seems to make sense. Could you generate a patch and send it to me ? I can test & commit it, and then maybe look at removing that horrible BOOTP hack :) I haven't looked at it yet, but it'll be worth testing that ifm_flags is populated correctly in routing socket messages... Thanks. On Sat, 8 Jun 2002 18:33:44 +0300 (EEST), Iasen Kostoff wrote: > > > On Sat, 8 Jun 2002, Brian Somers wrote: > > > On Fri, 7 Jun 2002 17:27:46 +0300 (EEST), Iasen Kostov > > wrote: > > > > > > > > > On Fri, 7 Jun 2002, Iasen Kostov wrote: > > > > > > > > > > > I think it's possible to use SIOCSIFCAP to tell the kernel not > > > > to set > > > > host route via IFCAP_NOROUTE or something similar which will set > > > > IFCAP_NOROUTE in uif_capenable. This flag will be checked in > > > > in_ifinit() and if it is set no host route will be added. And > > > > ofcourse there should be a way to set this by ifconfig ( > > > > -noroute for example). > > > > What you think about this ? > > > > > > > Hum or set an iface flag IFF_NOROUTE in struct ifnet.if_flags by > > > SIOCGIFFLAGS ioctl. > > > What you think ? > > > > The problem is that ifnet::if_flags is a short and all of it's bits > > are already used up :( > > > > -- > > Brian > > > > > > > > Don't _EVER_ lose your sense of humour ! > > > > > Yep but I think I solve the problem. > > I found this in net/if.h : > > /* > * 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. > */ > > and decide to use if_ipending utill extend of if_flags. > > Just add to the ifr_ifru union of the ifreq struct: > int ifru_flagslong; > and this: > #define ifr_flagslong ifr_ifru.ifru_flagslong /* long flags (int) */ > > than in net/if.c I've changed SIOCGIFFLAGS and SIOCSIFFLAGS handling > in ifioctl() function like this: > > case SIOCGIFFLAGS: > flagslong = ifp->if_flags & 0x0000ffff; > ifr->ifr_flagslong = flagslong | ifp->if_ipending; > break; > > case SIOCSIFFLAGS: > error = suser(p); > if (error) > return (error); > -> ifp->if_ipending = ifr->ifr_flagslong & 0xffff0000; > ... > > than ofcourse I fixed and ifconfig's function setifflags() to use > ifr_flagslong value instead of ifr_flags. It's a partial solution. > Sysctl that returns iface table should do the same thing as > SIOCGIFFLAGS handler. I saw that ifm_flags is int that means there > will not be a problem when sysctl is returning the new flags. And I > think this doesn't break anything in binary compatibility. > > To test all this I add this 2 lines to cmds[] declaration in > ifconfig.c : > > { "noroute", IFF_NOROUTE, setifflags }, > { "-noroute", -IFF_NOROUTE, setifflags }, > > and this line to net/if.h : > > #define IFF_NOROUTE 0x20000 /* Interface doesn't need host > #route. */ > > Than a fixed in.c and add a IFF_NOROUTE check in in_ifinit() : > > ... > if (!(ifp->if_ipending & IFF_NOROUTE)) > if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY || > ... > > And everything work perfect for me on the test machine : > > root@test:/sys/netinet on ttyp1 > #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 noroute > root@test:/sys/netinet on ttyp1 > #:> netstat -rn > Routing tables > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 212.36.8.137 UGSc 0 4 > ed1 127.0.0.1 127.0.0.1 UH 1 10 > lo0 212.36.8/23 link#2 UC 4 0 > ed1 > > root@test:/sys/netinet on ttyp1 > #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 -noroute > root@test:/sys/netinet on ttyp1 > #:> netstat -rn > Routing tables > Internet: > Destination Gateway Flags Refs Use Netif > Expire default 212.36.8.137 UGSc 0 4 > ed1 10/16 link#1 UC 0 0 > ed0 127.0.0.1 127.0.0.1 UH 1 10 > lo0 212.36.8/23 link#2 UC 3 0 > ed1 > > Could it be done that way, what You think ? > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 10:10:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by hub.freebsd.org (Postfix) with ESMTP id 416A937B401 for ; Sat, 8 Jun 2002 10:10:49 -0700 (PDT) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g58H97a92214; Sat, 8 Jun 2002 13:09:07 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Sat, 8 Jun 2002 13:09:07 -0400 From: Bosko Milekic To: John Polstra Cc: net@FreeBSD.ORG, archie@dellroad.org Subject: Re: m->m_pkthdr.header Message-ID: <20020608130907.A92176@unixdaemons.com> References: <200206071955.g57JtrJ65814@arch20m.dellroad.org> <200206081616.g58GG6v03893@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200206081616.g58GG6v03893@vashon.polstra.com>; from jdp@polstra.com on Sat, Jun 08, 2002 at 09:16:06AM -0700 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, Jun 08, 2002 at 09:16:06AM -0700, John Polstra wrote: > In article <200206071955.g57JtrJ65814@arch20m.dellroad.org>, > Archie Cobbs wrote: > > > > I'd like to get rid of this mbuf field "m->m_pkthdr.header". > [...] > > Any comments/objections? > > Yes, please bear in mind that if you change the layout of the mbuf > structures you will probably break binary compatibility with various > commercial network drivers that are shipped in binary form. That's a > big pain for those of us who are forced to use such drivers. For that > reason I don't think you should make this kind of change in -stable. > Current is obviously a different kettle of fish, but even there you > should add fillers to replace any structure elements you remove, if > possible. While I agree that -STABLE is a more sensitive fish (which is partly why I really don't enjoy dealing with it -- this argument always comes up), I think that these types of changes absolutely need to go into -CURRENT. We shouldn't have to worry about "breaking binary compatibility" in our development releases. I can almost guarantee that a lot of stuff isn't going to work without a rebuild when people decide to go from 4.x to 5.0 anyway. Placing dummy-fillers is just annoying. > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 10:14:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id EBE4E37B404 for ; Sat, 8 Jun 2002 10:14:12 -0700 (PDT) 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 g58HEAf07936; Sat, 8 Jun 2002 10:14:10 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g58HEAM04093; Sat, 8 Jun 2002 10:14:10 -0700 (PDT) (envelope-from jdp) Date: Sat, 8 Jun 2002 10:14:10 -0700 (PDT) Message-Id: <200206081714.g58HEAM04093@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bmilekic@unixdaemons.com Subject: Re: m->m_pkthdr.header In-Reply-To: <20020608130907.A92176@unixdaemons.com> References: <200206071955.g57JtrJ65814@arch20m.dellroad.org> <200206081616.g58GG6v03893@vashon.polstra.com> <20020608130907.A92176@unixdaemons.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 <20020608130907.A92176@unixdaemons.com>, Bosko Milekic wrote: > > While I agree that -STABLE is a more sensitive fish (which is partly > why I really don't enjoy dealing with it -- this argument always comes > up), I think that these types of changes absolutely need to go into > -CURRENT. We shouldn't have to worry about "breaking binary > compatibility" in our development releases. I can almost guarantee > that a lot of stuff isn't going to work without a rebuild when people > decide to go from 4.x to 5.0 anyway. Placing dummy-fillers is just > annoying. OK, I can live with that for -current. 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 Sat Jun 8 11:54:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id BFE6637B405 for ; Sat, 8 Jun 2002 11:54:09 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GlLb-000LvG-00; Sat, 08 Jun 2002 21:53:59 +0300 Date: Sat, 8 Jun 2002 21:53:59 +0300 (EEST) From: Iasen Kostov To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses In-Reply-To: <20020608172432.3f030ceb.brian@Awfulhak.org> Message-ID: <20020608214357.Q9095-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 Here is the patch. I'm now looking in the code to see where kernel replays to the interface table requests. I hope there are not a lot of places where it sets ifm_flags. > This certainly seems to make sense. Could you generate a patch and send > it to me ? I can test & commit it, and then maybe look at removing that > horrible BOOTP hack :) > > I haven't looked at it yet, but it'll be worth testing that ifm_flags is > populated correctly in routing socket messages... > > Thanks. > > On Sat, 8 Jun 2002 18:33:44 +0300 (EEST), Iasen Kostoff > wrote: > > > The problem is that ifnet::if_flags is a short and all of it's bits > > > are already used up :( > > > > > Yep but I think I solve the problem. > > > > I found this in net/if.h : > > > > /* > > * 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. > > */ > > > > and decide to use if_ipending utill extend of if_flags. > > > > Just add to the ifr_ifru union of the ifreq struct: > > int ifru_flagslong; > > and this: > > #define ifr_flagslong ifr_ifru.ifru_flagslong /* long flags (int) */ > > > > than in net/if.c I've changed SIOCGIFFLAGS and SIOCSIFFLAGS handling > > in ifioctl() function like this: > > > > case SIOCGIFFLAGS: > > flagslong = ifp->if_flags & 0x0000ffff; > > ifr->ifr_flagslong = flagslong | ifp->if_ipending; > > break; > > > > case SIOCSIFFLAGS: > > error = suser(p); > > if (error) > > return (error); > > -> ifp->if_ipending = ifr->ifr_flagslong & 0xffff0000; > > ... > > > > than ofcourse I fixed and ifconfig's function setifflags() to use > > ifr_flagslong value instead of ifr_flags. It's a partial solution. > > Sysctl that returns iface table should do the same thing as > > SIOCGIFFLAGS handler. I saw that ifm_flags is int that means there > > will not be a problem when sysctl is returning the new flags. And I > > think this doesn't break anything in binary compatibility. > > > > To test all this I add this 2 lines to cmds[] declaration in > > ifconfig.c : > > > > { "noroute", IFF_NOROUTE, setifflags }, > > { "-noroute", -IFF_NOROUTE, setifflags }, > > > > and this line to net/if.h : > > > > #define IFF_NOROUTE 0x20000 /* Interface doesn't need host > > #route. */ > > > > Than a fixed in.c and add a IFF_NOROUTE check in in_ifinit() : > > > > ... > > if (!(ifp->if_ipending & IFF_NOROUTE)) > > if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY || > > ... > > > > And everything work perfect for me on the test machine : > > > > root@test:/sys/netinet on ttyp1 > > #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 noroute > > root@test:/sys/netinet on ttyp1 > > #:> netstat -rn > > Routing tables > > Internet: > > Destination Gateway Flags Refs Use Netif > > Expire default 212.36.8.137 UGSc 0 4 > > ed1 127.0.0.1 127.0.0.1 UH 1 10 > > lo0 212.36.8/23 link#2 UC 4 0 > > ed1 > > > > root@test:/sys/netinet on ttyp1 > > #:> ifconfig ed0 10.0.0.0 netmask 255.255.0.0 -noroute > > root@test:/sys/netinet on ttyp1 > > #:> netstat -rn > > Routing tables > > Internet: > > Destination Gateway Flags Refs Use Netif > > Expire default 212.36.8.137 UGSc 0 4 > > ed1 10/16 link#1 UC 0 0 > > ed0 127.0.0.1 127.0.0.1 UH 1 10 > > lo0 212.36.8/23 link#2 UC 3 0 > > ed1 > > > > Could it be done that way, what You think ? > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 12:18:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id B1F0737B400 for ; Sat, 8 Jun 2002 12:18:28 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g58JIRKZ010593; Sat, 8 Jun 2002 20:18:27 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g58JIPtv001097; Sat, 8 Jun 2002 20:18:25 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Sat, 8 Jun 2002 20:18:25 +0100 From: Brian Somers To: Iasen Kostov Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses Message-Id: <20020608201825.468bbab6.brian@Awfulhak.org> In-Reply-To: <20020608214357.Q9095-100000@shadowhand.OTEL.net> References: <20020608172432.3f030ceb.brian@Awfulhak.org> <20020608214357.Q9095-100000@shadowhand.OTEL.net> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 Sat, 8 Jun 2002 21:53:59 +0300 (EEST), Iasen Kostov wrote: > Here is the patch. I'm now looking in the code to see where kernel > replays to the interface table requests. I hope there are not a lot > of places where it sets ifm_flags. [.....] I think you forgot to add the patch :*P -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 12:28:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id C715437B403 for ; Sat, 8 Jun 2002 12:28:30 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17Glsv-000MSC-00; Sat, 08 Jun 2002 22:28:25 +0300 Date: Sat, 8 Jun 2002 22:28:25 +0300 (EEST) From: Iasen Kostov To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses In-Reply-To: <20020608201825.468bbab6.brian@Awfulhak.org> Message-ID: <20020608222106.U9095-200000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1265262991-1023564505=:9095" 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-1265262991-1023564505=:9095 Content-Type: TEXT/PLAIN; charset=US-ASCII Oooo...ppzzZ. I think I didn't sleep enough last night :P. But I found what I was looking for :). This is it line 950 of net/rtsock.c : ifm->ifm_flags = (u_short)ifp->if_flags | ifp->if_ipending; And I even try it - it works. But Im not sure if it will work in all cases... On Sat, 8 Jun 2002, Brian Somers wrote: > On Sat, 8 Jun 2002 21:53:59 +0300 (EEST), Iasen Kostov wrote: > > Here is the patch. I'm now looking in the code to see where kernel > > replays to the interface table requests. I hope there are not a lot > > of places where it sets ifm_flags. > [.....] > > I think you forgot to add the patch :*P > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > --0-1265262991-1023564505=:9095 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ifcflags.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020608222825.B9095@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-1265262991-1023564505=:9095-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 13:20:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by hub.freebsd.org (Postfix) with ESMTP id A509437B403 for ; Sat, 8 Jun 2002 13:20:47 -0700 (PDT) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 17GmhU-000NJv-00; Sat, 08 Jun 2002 23:20:40 +0300 Date: Sat, 8 Jun 2002 23:20:40 +0300 (EEST) From: Iasen Kostoff To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: host routes for interface addresses In-Reply-To: <20020608172432.3f030ceb.brian@Awfulhak.org> Message-ID: <20020608231655.J21392-200000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-499592805-1023567640=:21392" 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-499592805-1023567640=:21392 Content-Type: TEXT/PLAIN; charset=US-ASCII This should be the full patch , but I'm not so sure :) I add ifconfig and net/rtsock.c fixes. I hope I don't miss something this time :) --0-499592805-1023567640=:21392 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ifcflags.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020608232040.A21392@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 ZmlnLmMJU2F0IEp1biAgOCAyMzowMDoxOSAyMDAyDQorKysgc2Jpbi9pZmNv bmZpZy9pZmNvbmZpZy5teS5jCVNhdCBKdW4gIDggMjM6MDA6MTQgMjAwMg0K QEAgLTIwNSw2ICsyMDUsOCBAQA0KIAl7ICItYWxpYXMiLAktSUZGX1VQLAlu b3RlYWxpYXMgfSwNCiAJeyAiZGVsZXRlIiwJLUlGRl9VUCwJbm90ZWFsaWFz IH0sDQogCXsgInJlbW92ZSIsCS1JRkZfVVAsCW5vdGVhbGlhcyB9LA0KKwl7 ICJub3JvdXRlIiwgICAgSUZGX05PUk9VVEUsICAgIHNldGlmZmxhZ3MgfSwN CisJeyAiLW5vcm91dGUiLCAgIC1JRkZfTk9ST1VURSwgICBzZXRpZmZsYWdz IH0sDQogI2lmZGVmIG5vdGRlZg0KICNkZWZpbmUJRU5fU1dBQklQUwkweDEw MDANCiAJeyAic3dhYmlwcyIsCUVOX1NXQUJJUFMsCXNldGlmZmxhZ3MgfSwN CkBAIC0xMDI4LDE0ICsxMDMwLDE0IEBADQogIAkJZXhpdCgxKTsNCiAgCX0N CiAJc3RybmNweShteV9pZnIuaWZyX25hbWUsIG5hbWUsIHNpemVvZiAobXlf aWZyLmlmcl9uYW1lKSk7DQotIAlmbGFncyA9IG15X2lmci5pZnJfZmxhZ3M7 DQorCWZsYWdzID0gbXlfaWZyLmlmcl9mbGFnc2xvbmc7DQogDQogCWlmICh2 YWx1ZSA8IDApIHsNCiAJCXZhbHVlID0gLXZhbHVlOw0KIAkJZmxhZ3MgJj0g fnZhbHVlOw0KIAl9IGVsc2UNCiAJCWZsYWdzIHw9IHZhbHVlOw0KLQlteV9p ZnIuaWZyX2ZsYWdzID0gZmxhZ3M7DQorCW15X2lmci5pZnJfZmxhZ3Nsb25n ID0gZmxhZ3M7DQogCWlmIChpb2N0bChzLCBTSU9DU0lGRkxBR1MsIChjYWRk cl90KSZteV9pZnIpIDwgMCkNCiAJCVBlcnJvcih2bmFtZSk7DQogfQ0KQEAg LTEwOTIsNyArMTA5NCw3IEBADQogI2RlZmluZQlJRkZCSVRTIFwNCiAiXDAy MFwxVVBcMkJST0FEQ0FTVFwzREVCVUdcNExPT1BCQUNLXDVQT0lOVE9QT0lO VFw2U01BUlRcN1JVTk5JTkciIFwNCiAiXDEwTk9BUlBcMTFQUk9NSVNDXDEy QUxMTVVMVElcMTNPQUNUSVZFXDE0U0lNUExFWFwxNUxJTkswXDE2TElOSzFc MTdMSU5LMiIgXA0KLSJcMjBNVUxUSUNBU1QiDQorIlwyME1VTFRJQ0FTVFwy MVBPTExJTkdcMjJOT1JPVVRFIg0KIA0KICNkZWZpbmUJSUZDQVBCSVRTIFwN CiAiXDAwM1wxcnhjc3VtXDJ0eGNzdW1cM25ldGNvbnMiDQotLS0gc3lzL25l dGluZXQvaW4uYwlTYXQgSnVuICA4IDIxOjIxOjEyIDIwMDINCisrKyBzeXMv bmV0aW5ldC9pbi5teS5jCVNhdCBKdW4gIDggMjA6NTM6MDYgMjAwMg0KQEAg LTczOSwxNSArNzM5LDE2IEBADQogCSAqIFhYWDogVGhpcyBpcyB1Z2x5ICEg IFRoZXJlIHNob3VsZCBiZSBhIHdheSBmb3IgdGhlIGNhbGxlciB0bw0KIAkg KiAgICAgIHNheSB0aGF0IHRoZXkgZG9uJ3Qgd2FudCBhIGhvc3Qgcm91dGUu DQogCSAqLw0KLQlpZiAoaWEtPmlhX2FkZHIuc2luX2FkZHIuc19hZGRyICE9 IElOQUREUl9BTlkgfHwNCi0JICAgIGlhLT5pYV9uZXRtYXNrICE9IElOX0NM QVNTQV9ORVQgfHwNCi0JICAgIGlhLT5pYV9kc3RhZGRyLnNpbl9hZGRyLnNf YWRkciAhPSBodG9ubChJTl9DTEFTU0FfSE9TVCkpIHsNCi0JCWlmICgoZXJy b3IgPSBydGluaXQoJmlhLT5pYV9pZmEsIChpbnQpUlRNX0FERCwgZmxhZ3Mp KSAhPSAwKSB7DQotCQkJaWEtPmlhX2FkZHIgPSBvbGRhZGRyOw0KLQkJCSAg ICByZXR1cm4gKGVycm9yKTsNCi0JCX0NCi0JCWlhLT5pYV9mbGFncyB8PSBJ RkFfUk9VVEU7DQotCX0NCisJaWYgKCEoaWZwLT5pZl9pcGVuZGluZyAmIElG Rl9OT1JPVVRFKSkNCisJICAgIGlmIChpYS0+aWFfYWRkci5zaW5fYWRkci5z X2FkZHIgIT0gSU5BRERSX0FOWSB8fA0KKwkJaWEtPmlhX25ldG1hc2sgIT0g SU5fQ0xBU1NBX05FVCB8fA0KKwkJaWEtPmlhX2RzdGFkZHIuc2luX2FkZHIu c19hZGRyICE9IGh0b25sKElOX0NMQVNTQV9IT1NUKSkgew0KKwkJICAgIGlm ICgoZXJyb3IgPSBydGluaXQoJmlhLT5pYV9pZmEsIChpbnQpUlRNX0FERCwg ZmxhZ3MpKSAhPSAwKSB7DQorCQkgICAgCWlhLT5pYV9hZGRyID0gb2xkYWRk cjsNCisJCQlyZXR1cm4gKGVycm9yKTsNCisJCSAgICB9DQorCQkgICAgaWEt PmlhX2ZsYWdzIHw9IElGQV9ST1VURTsNCisJICAgIH0NCiANCiAJLyoNCiAJ ICogSWYgdGhlIGludGVyZmFjZSBzdXBwb3J0cyBtdWx0aWNhc3QsIGpvaW4g dGhlICJhbGwgaG9zdHMiDQotLS0gc3lzL25ldC9ydHNvY2suYwlNb24gRmVi IDE4IDE3OjI2OjM1IDIwMDINCisrKyBzeXMvbmV0L3J0c29jay5teS5jCVNh dCBKdW4gIDggMjM6MDE6MTMgMjAwMg0KQEAgLTc0Niw3ICs3NDYsNyBAQA0K IAkJcmV0dXJuOw0KIAlpZm0gPSBtdG9kKG0sIHN0cnVjdCBpZl9tc2doZHIg Kik7DQogCWlmbS0+aWZtX2luZGV4ID0gaWZwLT5pZl9pbmRleDsNCi0JaWZt LT5pZm1fZmxhZ3MgPSAodV9zaG9ydClpZnAtPmlmX2ZsYWdzOw0KKwlpZm0t PmlmbV9mbGFncyA9ICh1X3Nob3J0KWlmcC0+aWZfZmxhZ3MgfCBpZnAtPmlm X2lwZW5kaW5nOw0KIAlpZm0tPmlmbV9kYXRhID0gaWZwLT5pZl9kYXRhOw0K IAlpZm0tPmlmbV9hZGRycyA9IDA7DQogCXJvdXRlX3Byb3RvLnNwX3Byb3Rv Y29sID0gMDsNCkBAIC05NDcsNyArOTQ3LDcgQEANCiANCiAJCQlpZm0gPSAo c3RydWN0IGlmX21zZ2hkciAqKXctPndfdG1lbTsNCiAJCQlpZm0tPmlmbV9p bmRleCA9IGlmcC0+aWZfaW5kZXg7DQotCQkJaWZtLT5pZm1fZmxhZ3MgPSAo dV9zaG9ydClpZnAtPmlmX2ZsYWdzOw0KKwkJCWlmbS0+aWZtX2ZsYWdzID0g KHVfc2hvcnQpaWZwLT5pZl9mbGFncyB8IGlmcC0+aWZfaXBlbmRpbmc7DQog CQkJaWZtLT5pZm1fZGF0YSA9IGlmcC0+aWZfZGF0YTsNCiAJCQlpZm0tPmlm bV9hZGRycyA9IGluZm8ucnRpX2FkZHJzOw0KIAkJCWVycm9yID0gU1lTQ1RM X09VVCh3LT53X3JlcSwoY2FkZHJfdClpZm0sIGxlbik7DQo= --0-499592805-1023567640=:21392-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 14:20:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id F13C037B404 for ; Sat, 8 Jun 2002 14:20:10 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020608212010.NYQY2751.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 8 Jun 2002 21:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA70697; Sat, 8 Jun 2002 14:01:36 -0700 (PDT) Date: Sat, 8 Jun 2002 14:01:35 -0700 (PDT) From: Julian Elischer To: John Polstra Cc: net@freebsd.org, archie@dellroad.org Subject: Re: m->m_pkthdr.header In-Reply-To: <200206081616.g58GG6v03893@vashon.polstra.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 I think there is almost no chance that a 4.x binary driver will run under 5.x On Sat, 8 Jun 2002, John Polstra wrote: > In article <200206071955.g57JtrJ65814@arch20m.dellroad.org>, > Archie Cobbs wrote: > > > > I'd like to get rid of this mbuf field "m->m_pkthdr.header". > [...] > > Any comments/objections? > > Current is obviously a different kettle of fish, but even there you > should add fillers to replace any structure elements you remove, if > possible. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 20: 1:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from CRWdog.demon.co.uk (p69-199.acedsl.com [66.114.69.199]) by hub.freebsd.org (Postfix) with ESMTP id 862B737B401; Sat, 8 Jun 2002 20:01:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by CRWdog.demon.co.uk (Postfix) with ESMTP id 363403E14; Sat, 8 Jun 2002 23:01:08 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: MIB support for network devices in FreeBSD? Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_157521132P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 08 Jun 2002 23:01:08 -0400 From: Andy Sparrow Message-Id: <20020609030108.363403E14@CRWdog.demon.co.uk> 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 --==_Exmh_157521132P Content-Type: text/plain; charset=us-ascii Hi all, (pls Cc: me on any response, not subscribed to either list) Can't find any references to this in the archives. What's the status of MIB support for network interfaces in FreeBSD? Is it deprecated, optional, "would be nice"? Reason for asking is that a dockapp I use has stopped displaying real-time stats since a recent upgrade. This is because the author has switched to using the interface MIB to collect statistics in the latest version[1]. Which in itself seems like a nice approach, except that it doesn't display anything for my 802.11 card, or the loopback device. Digging around a bit with grep (in 4.6-RC) shows that only 3 devices in /usr/src/sys/dev seem to have implemented full MIB support, a couple more increment error counters, and ~20 more NIC drivers (including most all of my NICs) don't apparently implement any support for MIB-based counters whatsoever[2]. Anyway, should the author of the utility be advised: a) Nice approach, little premature b) Nice approach, very premature c) Wrong approach, revert to previous if you want it to work with FreeBSD d) Other? Also, I'd be interested to know which MIBs we intend to support, and from which draft/RFC it's drawn from, if anyone happens to know or can point me at some *BSD docs? TIA. Regards, AS [1] He added FreeBSD support to a previously Solaris/Linux-only app, but doesn't apparently have a FreeBSD box to test on himself, asks for feedback on his webpage. [2] It's obviously not entirely that simple, 'coz I can't find any reference to the xl driver incrementing mib counters /either/, yet the monitor dockapp seems to work for the built-in xl device in my laptop... --==_Exmh_157521132P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9AsTzPHh895bDXeQRAmveAJsEE3ttxN9Q643+eKQIQKZhAOP/RACgunJL 5nrMDLNXUW5SBQk1nxS7Yf8= =iCyz -----END PGP SIGNATURE----- --==_Exmh_157521132P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 20:13:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from lerlaptop.lerctr.org (lerlaptop.lerctr.org [207.158.72.14]) by hub.freebsd.org (Postfix) with ESMTP id 6A24537B400; Sat, 8 Jun 2002 20:13:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lerlaptop (8.12.3/8.12.3) with ESMTP id g593BiDG036472; Sat, 8 Jun 2002 22:11:44 -0500 (CDT) (envelope-from ler@lerctr.org) Subject: Re: MIB support for network devices in FreeBSD? From: Larry Rosenman To: Andy Sparrow Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020609030108.363403E14@CRWdog.demon.co.uk> References: <20020609030108.363403E14@CRWdog.demon.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 08 Jun 2002 22:11:44 -0500 Message-Id: <1023592304.349.20.camel@lerlaptop> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-milter (http://amavis.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 On Sat, 2002-06-08 at 22:01, Andy Sparrow wrote: > > Hi all, > > (pls Cc: me on any response, not subscribed to either list) > > Can't find any references to this in the archives. > > What's the status of MIB support for network interfaces in FreeBSD? Is it > deprecated, optional, "would be nice"? > > Reason for asking is that a dockapp I use has stopped displaying real-time > stats since a recent upgrade. This is because the author has switched to using > the interface MIB to collect statistics in the latest version[1]. > > Which in itself seems like a nice approach, except that it doesn't display > anything for my 802.11 card, or the loopback device. > > Digging around a bit with grep (in 4.6-RC) shows that only 3 devices in > /usr/src/sys/dev seem to have implemented full MIB support, a couple more > increment error counters, and ~20 more NIC drivers (including most all of my > NICs) > don't apparently implement any support for MIB-based counters whatsoever[2]. > > Anyway, should the author of the utility be advised: > > a) Nice approach, little premature > > b) Nice approach, very premature > > c) Wrong approach, revert to previous if you want it to work with FreeBSD > > d) Other? > > > Also, I'd be interested to know which MIBs we intend to support, and from > which draft/RFC it's drawn from, if anyone happens to know or can point me at > some *BSD docs? > > TIA. > > Regards, > > AS > > [1] He added FreeBSD support to a previously Solaris/Linux-only app, but > doesn't apparently have a FreeBSD box to test on himself, asks for feedback on > his webpage. > > [2] It's obviously not entirely that simple, 'coz I can't find any reference > to the xl driver incrementing mib counters /either/, yet the monitor dockapp > seems to work for the built-in xl device in my laptop... > > > I believe you can get this info if you add the net/snmp or net/snmp4 port. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 20:51:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from CRWdog.demon.co.uk (p69-199.acedsl.com [66.114.69.199]) by hub.freebsd.org (Postfix) with ESMTP id 51B7B37B400; Sat, 8 Jun 2002 20:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by CRWdog.demon.co.uk (Postfix) with ESMTP id 55A8F3E2D; Sat, 8 Jun 2002 23:51:46 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Larry Rosenman Cc: Andy Sparrow , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MIB support for network devices in FreeBSD? In-Reply-To: Message from Larry Rosenman of "08 Jun 2002 22:11:44 CDT." <1023592304.349.20.camel@lerlaptop> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_160246690P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 08 Jun 2002 23:51:46 -0400 From: Andy Sparrow Message-Id: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> 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 --==_Exmh_160246690P Content-Type: text/plain; charset=us-ascii > I believe you can get this info if you add the net/snmp or net/snmp4 > port. Hi Larry, Thanks for replying. Hmmm. I'm talking about code that uses a FreeBSD-specific sysctl to interrogate the in-kernel if MIB counters, like this: /* gather stats */ int freebsd_sysctl_get(struct Devices*dev, unsigned long* ip, unsigned long* op, unsigned long* ib, unsigned long* ob) { struct ifmibdata* drvdata = dev->drvdata; int datamib[6]; int len; *ip = *op = *ib = *ob = 0; datamib[0] = CTL_NET; datamib[1] = PF_LINK; datamib[2] = NETLINK_GENERIC; datamib[3] = IFMIB_IFDATA; datamib[4] = 1; /* fill in later */ datamib[5] = IFDATA_GENERAL; datamib[4] = IFMIB_IFCOUNT; len = sizeof(struct ifmibdata); if(sysctl(datamib, 6, drvdata, &len, NULL, 0) < 0) return 1; *ip = drvdata->ifmd_data.ifi_ipackets; *op = drvdata->ifmd_data.ifi_opackets; *ib = drvdata->ifmd_data.ifi_ibytes; *ob = drvdata->ifmd_data.ifi_obytes; return 0; } But these stats don't seem to be collected for at least some network card drivers, presumably because those drivers aren't collecting those stats, e.g. they don't #include , and thus don't allocate a mib structure or increment any counters in that structure. I can confirm that it definately doesn't work for the 'wi' and 'lo' drivers... However, it definately seems to work for the xl driver... Try this: cd /usr/src/sys/dev; find . -exec grep mib {} /dev/null \; 'awi', 'ed' & 'ray' drivers seem to have the most complete implementations, but 'fe' & 'xe' seem to have partial implementations (error counters only). They're relatively short, so here's one by way of illustration: ./xe/if_xe.c:#include ./xe/if_xe.c: scp->ifp->if_linkmib = &scp->mibdata; ./xe/if_xe.c: scp->ifp->if_linkmiblen = sizeof scp->mibdata; ./xe/if_xe.c: scp->mibdata.dot3StatsSingleCollisionFrames++; ./xe/if_xe.c: scp->mibdata.dot3StatsCollFrequencies[0]++; ./xe/if_xe.c: scp->mibdata.dot3StatsMultipleCollisionFrames++; ./xe/if_xe.c: scp->mibdata.dot3StatsCollFrequencies[scp-> tx_collisions-1]++; ./xe/if_xe.c: scp->mibdata.dot3StatsMultipleCollisionFrames += sent; ./xe/if_xe.c: scp->mibdata.dot3StatsExcessiveCollisions++; ./xe/if_xe.c: scp->mibdata.dot3StatsMultipleCollisionFrames++; ./xe/if_xe.c: scp->mibdata.dot3StatsCollFrequencies[15]++; ./xe/if_xe.c: scp->mibData.dot3StatsMissedFrames++; ./xe/if_xe.c: scp->mibdata.dot3StatsFrameTooLongs++; ./xe/if_xe.c: scp->mibdata.dot3StatsFCSErrors++; ./xe/if_xe.c: scp->mibdata.dot3StatsAlignmentErrors++; ./xe/if_xe.c: scp->mibdata.dot3StatsInternalMacReceiveErrors++; ./xe/if_xevar.h: struct ifmib_iso_8802_3 mibdata; However, most of the drivers don't seem to have any code like this in them - and at least some of those drivers don't work with the 3rd-party application code above. Should they? Or is this an older interface? I'd like to advise the author so he can fix a very useful dockapp for me - or, if this is the way to go, I'll badger Bill Paul to fix the 'wi' driver - oh, wait a moment, maybe generating patches would be safer :) Regards, AS --==_Exmh_160246690P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9AtDSPHh895bDXeQRAnOAAKC/77wrv0p3U5+EHRjrXvI9d6ewQACggGG+ hr40XuRET6/Y9oFgrGjqUrY= =4gqz -----END PGP SIGNATURE----- --==_Exmh_160246690P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 20:58:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from lerlaptop.lerctr.org (lerlaptop.lerctr.org [207.158.72.14]) by hub.freebsd.org (Postfix) with ESMTP id 1DEB237B403; Sat, 8 Jun 2002 20:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lerlaptop.lerctr.org (8.12.3/8.12.3) with ESMTP id g593wWdd036779; Sat, 8 Jun 2002 22:58:32 -0500 (CDT) (envelope-from ler@lerctr.org) Subject: Re: MIB support for network devices in FreeBSD? From: Larry Rosenman To: Andy Sparrow Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> References: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 08 Jun 2002 22:58:32 -0500 Message-Id: <1023595112.349.25.camel@lerlaptop> Mime-Version: 1.0 X-Virus-Scanned: by amavisd-milter (http://amavis.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 On Sat, 2002-06-08 at 22:51, Andy Sparrow wrote: > > > I believe you can get this info if you add the net/snmp or net/snmp4 > > port. > > Hi Larry, > > Thanks for replying. > > Hmmm. I'm talking about code that uses a FreeBSD-specific sysctl to > interrogate the in-kernel if MIB counters, like this: > [snip] > > However, most of the drivers don't seem to have any code like this in them - > and at least some of those drivers don't work with the 3rd-party application > code above. Hmm. I'm not a network developer, and have even less knowledge of what's going on in the interfaces stuff. > > Should they? Or is this an older interface? Haven't the foggiest. Have you looked in -CURRENT to see if it's different there? (and if so, see if it's planned to MFC it?) > > I'd like to advise the author so he can fix a very useful dockapp for me - or, > if this is the way to go, I'll badger Bill Paul to fix the 'wi' driver - oh, > wait a moment, maybe generating patches would be safer :) Probably Patches would work better, if their not in -CURRENT yet. But, I'm just a luser here. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 8 22:31:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 9997937B477; Sat, 8 Jun 2002 22:31:20 -0700 (PDT) Received: from pool0193.cvx40-bradley.dialup.earthlink.net ([216.244.42.193] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17GvI7-0004rq-00; Sat, 08 Jun 2002 22:31:04 -0700 Message-ID: <3D02E7F4.432854D0@mindspring.com> Date: Sat, 08 Jun 2002 22:30:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Sparrow Cc: Larry Rosenman , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MIB support for network devices in FreeBSD? References: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> 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 Andy Sparrow wrote: > But these stats don't seem to be collected for at least some network card > drivers, presumably because those drivers aren't collecting those stats, e.g. > they don't #include , and thus don't allocate a mib structure or > increment any counters in that structure. > > I can confirm that it definately doesn't work for the 'wi' and 'lo' drivers... > > However, it definately seems to work for the xl driver... Benchmark the driver. If it's fast, it doesn't collect the statistics. Just like "WITNESS": if your machine is fast, "WITNESS" is disabled. 8-). Bascially, most of these statistics are "manager fluff" (as opposed to "seat cushion fluuf" or "pocket fluff"). What you want is statistics that are managed universally; see "netstat -ibdt" for the usefult statistics kept per interface. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message