From owner-freebsd-net Sun Apr 23 0:10:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 35D1B37B90F; Sun, 23 Apr 2000 00:10:23 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id JAA10996; Sun, 23 Apr 2000 09:11:20 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004230711.JAA10996@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004230411.VAA17652@bubba.whistle.com> from Archie Cobbs at "Apr 22, 2000 09:11:45 pm" To: Archie Cobbs Date: Sun, 23 Apr 2000 09:11:20 +0200 (CEST) Cc: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So, I've got a proposal :-) These are not all my ideas, but > here they are collected in one place.. Hi, to respond to some of your ideas: 1. i fully agree on the need for putting the bpf/bridging hooks into ether_input(), so we can avoid duplicate code when necessary. I would actually create a new function, ether_input_something(), which does all the stuff and then calls the current ether_input(). The motivations would be: - to keep the existing ether_input() unchanged; - to let those drivers which need to be able to do some optimizations (a case i have in mind: when doing bridging, the 'ed' driver only reads the ethernet header first, and fetches the whole packet only if really needed. This is an important optimization given that bridging often discards a lot of packets and this way we save a lot of CPU/bus bandwidth). Also I am not sure how well a generic function can deal with special drivers (such as "de") which seem to do some not-as-straightforward management of mbufs. 2. I am not sure if the second parm is really needed, or we should just go ahead and check the dest.MAC address for all incoming packets anyways. Not doing so only seems a minor optimization and i am not even sure if passing an additional parameter and checking if address check needs to be done is actually cheaper than doing the 6-byte comparison right away. But whatever... 3.-6. i still have not found the time to look into netgraph so i cannot comment on these. I trust you that these are good ideas :) 6bis Note that even now you _can_ do bridging on arbitrary subsets of interfaces, controlled by net.link.ether.bridge_cfg . The variable (which is really the basis of a VLAN bridge which i am hopefully to release in a few months) defines clusters of interfaces, and bridging is performed separately on each cluster, and only on the interfaces listed by that variable. Each cluster has a numeric identifier (from 1 up) which in the VLAN version corresponds to the VLAN ID. When the VLAN code is committed, you will be able to define a cluster numbered 0 which is a set of TRUNK interfaces -- packets bridged through the trunk will have the VLAN header added/removed as required. Speaking of etherfw(8)... somebody posted this code 1-2 months ago. Havent committed it yet. Also, and again, some amt of filtering for ethernet packets is already present in ipfw(8). You can select bridged packets, and if they have IP payload also do all ordinary tests. There is even some hack already committed which lets you filter basing on ethernet type (for sure one needs more). 7. I would be against removing option BRIDGE as requiring netgraph instead would probably increase the kernel footprint, and i think a lot of people uses bridging in PicoBSD situations where memory is a concern. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 0:26:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 5223837B5E8; Sun, 23 Apr 2000 00:26:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from gothic.iinet.net.au (gothic.iinet.net.au [203.59.24.252]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id PAA06119; Sun, 23 Apr 2000 15:26:11 +0800 Received: from jules.elischer.org (reggae-09-137.nv.iinet.net.au [203.59.67.137]) by gothic.iinet.net.au (8.8.5/8.8.5) with SMTP id PAA25610; Sun, 23 Apr 2000 15:26:06 +0800 Message-ID: <3902A56B.167EB0E7@elischer.org> Date: Sun, 23 Apr 2000 00:25:31 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: pavel@alum.mit.edu, nsayer@sftw.com, luigi@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph References: <200004230411.VAA17652@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > [...] > > The current situation with Ethernet drivers, Bridging, BPF, and > Netgraph is that it's all a bit klugey and gross. As evidence of > this, every single Ethernet driver (I've counted 45) must contain > the same duplicated code to handle both BPF and bridging.. With or without netgraph, this has called for cleaning up for a while. > > The reason for this being that both of these require putting the > device in promiscuous mode, but ether_input() is only supposed to > get "real" packets, and so the driver must "shield" ether_input() > from seeing packets which it wouldn't normally see. However, BPF > and bridging must be "unshielded". The result is that each driver > has to contain logic to handle BPF and briding, because by the > time packets get to ether_input(), it's too late. > So, the first part of the proposal is: > > 1 Move the BPF and BRIDGE code out of all of the Ethernet drivers > and put it into ether_input() sure > > 2 Add a new parameter to ether_input() which a driver will set > to non-zero indicating ``IFF_PROMISC was set and this packet > came in, but it's not really supposed to be received so don't > send it up the networking stack.'' Theoretically this is not needed. We already have the address of the ifnet structure and thus the arpcom, so we have the flags, AND the local ethernet address, so we can just do the same test that is presently done in the drivers. We have all the the info we need. > > Secondly, the ng_ether netgraph node is not as elegant as it could be. > For example, it should be possible to do bridging using a "ng_bridge" > netgraph node.. but that's not possible right now. No, because I wanted to put the ng_ether code into the generic ehter code and to make it as unintrusive as possible so that no-one could complain that it was slowing down the mainline. As has been noted the generic code doesn't get packets not destined to this machine. (maybe a separate hook to catch these?). Also I didn't add a way to give these packes back to the system if netgraph didn't need them. This is the second place where a "give it back" facility would be useful. and so I have decided that I will put forward a proposal to allow 'Packet return' facility in netgraph.. Basically this will allow netgraph to have 'processing 'stubs' where you hand a packet to a hook and it may come back to you modified in some way. (or duplicated or whatever). I can see a lot of uses for this and it's actually a very small change to the protocol. It's also backwards compatible. > > Also, you have to compile your kernel with options NETGRAPH in order > to get netgraph node Ethernet support.. there's no ng_ether.ko KLD. > > So, the next part of the proposal.. > > 3 Move the netgraph part of if_ethersubr.c into a new file ng_ether.c > and make it so the Ethernet node type can be a KLD and still work. Tricky, but the main reason i didn't do this in the forst place is that I wanted the netgraph code in if_ethersubr.c to be COMPLETELY removable if option NETGRAPH were not used so that the traditionalists wouldn't be able to complain that I was slowing up the critical path. > > 4 Change the ng_ether node type to have these two hooks: > "device" -- connection down to the raw Ethernet device > "stack" -- connection to the Ethernet stack and upper stacks This is a fair idea, though I'd like to add the 'stub' option as well. (to save on kernel stack and processing time). > > 5 Add netgraph control messages to get the associated interface name > and index, so that it's possible to set promiscuous mode, multicast > addresses, etc. by: > from the kernel - getting the interface structure (using > ifindex2ifnet[if_index]), and then calling ifioctl() > (small note: ifioctl() will be made to handle p == NULL) > from userland - using the normal ioctl() mechanism The ifindex is a hack that should go away (in my opinion). > > 6 Minor fix to ppp(8), etc. to handle different ng_ether hook names > > Re #4: When neither hook is connected, they are effectively connected > together -- i.e., the interface functions normally. Otherwise, you > get the obvious data connection, allowing both sending and recieving > raw frames to the device, but also input/output from the Ethernet > stack associated with the interface. Filtering Ethernet frames based > on interface would be easy .. etherfw(8) anyone? :-) Sure. > > Finally.. > > 6 Convert BRIDGE into a netgraph node. This would make it more > powerful because you could do bridging on any arbitrary subset > of interfaces. > > 7 (Optional) Remove existing BRIDGE support in favor of netgraph version > Only if people want to for simplicity. > > What do people think? > > -Archie > Personally I like it and it's teh kind of thing that I wrote teh original netgraph design to handle. I really do think that a pass-back facility would round out the protocol, but that's a different issue I will discuss separately. Julian > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 0:33:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 4A31137B59D; Sun, 23 Apr 2000 00:33:17 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id JAA11091; Sun, 23 Apr 2000 09:34:14 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004230734.JAA11091@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <3902A56B.167EB0E7@elischer.org> from Julian Elischer at "Apr 23, 2000 00:25:31 am" To: Julian Elischer Date: Sun, 23 Apr 2000 09:34:14 +0200 (CEST) Cc: Archie Cobbs , pavel@alum.mit.edu, nsayer@sftw.com, luigi@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 5 Add netgraph control messages to get the associated interface name > > and index, so that it's possible to set promiscuous mode, multicast > > addresses, etc. by: > > from the kernel - getting the interface structure (using > > ifindex2ifnet[if_index]), and then calling ifioctl() > > (small note: ifioctl() will be made to handle p == NULL) > > from userland - using the normal ioctl() mechanism > > The ifindex is a hack that should go away (in my opinion). I definitely agree on this ! cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 1: 9:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.Co.Jp [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 1DE8437B7D6 for ; Sun, 23 Apr 2000 01:09:23 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (root@hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000030111/smtpfeed 1.01) with ESMTP id RAA86416; Sun, 23 Apr 2000 17:09:14 +0900 (JST) Received: from localhost (kjc@[127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.8/3.7Ws3/hotaka/2000030111) with ESMTP id RAA24605; Sun, 23 Apr 2000 17:09:13 +0900 (JST) To: luigi@info.iet.unipi.it Cc: julian@elischer.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004230734.JAA11091@info.iet.unipi.it> References: <3902A56B.167EB0E7@elischer.org> <200004230734.JAA11091@info.iet.unipi.it> X-Mailer: Mew version 1.95b3 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000423170912H.kjc@csl.sony.co.jp> Date: Sun, 23 Apr 2000 17:09:12 +0900 From: Kenjiro Cho X-Dispatcher: imput version 991025(IM133) Lines: 20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > 5 Add netgraph control messages to get the associated interface name > > > and index, so that it's possible to set promiscuous mode, multicast > > > addresses, etc. by: > > > from the kernel - getting the interface structure (using > > > ifindex2ifnet[if_index]), and then calling ifioctl() > > > (small note: ifioctl() will be made to handle p == NULL) > > > from userland - using the normal ioctl() mechanism > > > > The ifindex is a hack that should go away (in my opinion). > > I definitely agree on this ! You can't just remove if_index. if_index is part of standard API defined in RFC2553 (Basic Socket Interface Extention for IPv6) and RFC2292 (Advanced Socket API for IPv6). -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 5:59:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.alltel.net (mail.alltel.net [166.102.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 55E7037B6E6 for ; Sun, 23 Apr 2000 05:59:44 -0700 (PDT) (envelope-from jbstrt@alltel.net) Received: from alltel.net (r-174.151.alltel.net [166.102.174.151]) by mail.alltel.net (8.9.3/ALLTEL Messaging Service) with ESMTP id HAA02316 for ; Sun, 23 Apr 2000 07:59:41 -0500 (CDT) Message-ID: <3902F515.996E52AF@alltel.net> Date: Sun, 23 Apr 2000 09:05:25 -0400 From: Robert Fulford X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: Stand-alone routers,fbsd, & Dynamic ISP addresses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have 2 W2k boxes & 1 Fbsd box...I would love to use the fbsd box as a dfgw/ipfw/natd for the other 2 boxes when connecting to the internet...I am just now learning fbsd, so I am very confused! I am planning on getting ISDN from my only local ISP soon, but I am sure the IP they will give my router will be dynamic....If I can't locate an internal USRobotics Sportster 128k non-PnP, I will buy a Nortel RT338 stand-alone ISDN Router... My quandary is this.....how in the heck can I tell the fbsd box that the router,which doesn't have an IP from the ISP yet, is where packets are to be routed? I have been told by others that I won't be using pppd, ppp, or even pppoed in this type of setup...I am leaning toward the Nortel, as it would allow me to have net access if the hd on the bsd box were to die. I do not want the ISDN router to control the NAT for my network, or use it's DHCP capabilities.... Thanks, Jeb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 6:20:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from MailAndNews.com (MailAndNews.com [199.29.68.160]) by hub.freebsd.org (Postfix) with ESMTP id 7393837B5EA for ; Sun, 23 Apr 2000 06:20:26 -0700 (PDT) (envelope-from darkcolony@MailAndNews.com) X-WM-Posted-At: MailAndNews.com; Sun, 23 Apr 00 09:20:23 -0400 X-WebMail-UserID: darkcolony Date: Sun, 23 Apr 2000 09:20:23 -0400 From: Miguel Ruiz To: freebsd-net@FreeBSD.ORG X-EXP32-SerialNo: 00000000 Subject: Message-ID: <39087384@MailAndNews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.61.02 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all: I was looking at this server, and it was generating a bunch of natd processes. To the best of my memory there should only be one natd process running. I tried to correct this and made a mistake and did a killall -9 natd. This machine needs natd to be running or else it shut down all ip interfaces. Oops. Nothing is hard coded all they have to do is reboot. The problem is we need to find out why it was creating multiple natd process. Does anyone know how 2 shutdown the xtra processes? thanx! M1k3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 8: 7:40 2000 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 BE40237B614; Sun, 23 Apr 2000 08:07:38 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA29893; Sun, 23 Apr 2000 11:07:35 -0400 (EDT) (envelope-from wollman) Date: Sun, 23 Apr 2000 11:07:35 -0400 (EDT) From: Garrett Wollman Message-Id: <200004231507.LAA29893@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: Archie Cobbs , pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <3902A56B.167EB0E7@elischer.org> References: <200004230411.VAA17652@bubba.whistle.com> <3902A56B.167EB0E7@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > The ifindex is a hack that should go away (in my opinion). ifindex is required by standards. It can't go away, regardless of your opinion. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 8:46:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from game.over.net (game.over.net [193.189.189.100]) by hub.freebsd.org (Postfix) with ESMTP id 342D537B76E for ; Sun, 23 Apr 2000 08:46:43 -0700 (PDT) (envelope-from tomaz.borstnar@over.net) Received: from [193.189.182.167] ([193.189.182.167]:5928 "EHLO user.over.net") by mail.over.net with ESMTP id ; Sun, 23 Apr 2000 17:46:30 +0200 Message-Id: <4.3.1.2.20000423174128.035fd280@193.189.189.100> X-Sender: tmail@193.189.189.100 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 23 Apr 2000 17:45:23 -0100 To: freebsd-net@freebsd.org From: Tomaz Borstnar Subject: enforcing DHCP usage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Anyone know a solution where one can enforce usage of DHCP ie. nobody will be able to communicate outside its physical ethernet if it doesn't acquire proper address via DHCP server. There are some possible kludges where a script would check DHCP leases and block traffic for all but properly leased addresses, but was wondering about other possibilities. Thanks in advance. Tomaz ---- Tomaz Borstnar "Love is the answer to the final question you ask" - Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 8:49:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 42B0637B641; Sun, 23 Apr 2000 08:49:30 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id RAA09217; Sun, 23 Apr 2000 17:49:34 +0200 (CEST) (envelope-from assar) To: Robert Watson Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) References: From: Assar Westerlund Date: 23 Apr 2000 17:49:34 +0200 In-Reply-To: Robert Watson's message of "Sat, 22 Apr 2000 14:24:23 -0400 (EDT)" Message-ID: <5ln1mkom0h.fsf@assaris.sics.se> Lines: 11 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > Any idea what the default idle time before keepalives kick in is? Is it really keep-alive that's interesting here? Isn't it the retransmission timer? If somebody is doing "mbuf exhaustion", we will have un-acked outstanding data. And it should be the same case with "process saturation". /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 9: 7:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from ms1.meiway.com (ms1.meiway.com [212.73.210.73]) by hub.freebsd.org (Postfix) with ESMTP id 0490A37B88C for ; Sun, 23 Apr 2000 09:07:14 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from sv.Go2France.com [212.73.210.79] by ms1.meiway.com with ESMTP (SMTPD32-5.05) id A0EA1ED0242; Sun, 23 Apr 2000 18:12:26 +0200 Message-Id: <4.3.1.2.20000423174956.00e06900@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 23 Apr 2000 18:05:58 +0200 To: freebsd-net@freebsd.org From: Len Conrad Subject: Re: Stand-alone routers,fbsd, & Dynamic ISP addresses In-Reply-To: <3902F515.996E52AF@alltel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >ISDN from my only local ISP soon, but I am sure the IP >they will give my router will be dynamic. It will be much, much easier if you can obtain a fixed ip for the "outside" interface of your FreeBSD router. of course, that would probably cost more to rent. >...If I can't >locate an internal USRobotics Sportster 128k non-PnP, >I will buy a Nortel RT338 stand-alone ISDN Router... These "Nortel" are very nice boxes, but they are Nortel-badged and -boxed Zyxel cards. We use these boxes for all our ISDN clients. You might look at Zyxel price, they've come down in price recently, at least here in France. We'd like to have the Zyxels dial into a FreeBSD "Remote Access Server" router with a www.LanMedia.com 1504P channelized PRI card, but that seems to be a ways off. >My quandary is this.....how in the heck can I tell the >fbsd box that the router,which doesn't have an IP from >the ISP yet, is where packets are to be routed? The zyxel box has two intefaces, WAN outside and Ethernet inside, of course. The outside will be the public ip DHCP'd from the ISP. But did you know that the Zyxel's can be bridges only? This may be your best bet, since it seems that you want the Nortel/Zyxel to provide only an ISDN interface and dialing functions, and maybe ip connection spoofing, for when you fall asleep at the keyboard. As to how you'd get the FreeBSD router to address the Ethernet inside of the Nortel that has no fixed ip, I'll leave that to someone else. vbg Len To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 9: 9:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id DA2A937B565 for ; Sun, 23 Apr 2000 09:09:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id AAA27819; Mon, 24 Apr 2000 00:09:00 +0800 Received: from jules.elischer.org (reggae-09-142.nv.iinet.net.au [203.59.67.142]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with SMTP id AAA11352; Mon, 24 Apr 2000 00:08:47 +0800 Message-ID: <39031FC6.59E2B600@elischer.org> Date: Sun, 23 Apr 2000 09:07:34 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Kenjiro Cho Cc: luigi@info.iet.unipi.it, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph References: <3902A56B.167EB0E7@elischer.org> <200004230734.JAA11091@info.iet.unipi.it> <20000423170912H.kjc@csl.sony.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenjiro Cho wrote: > > Luigi Rizzo wrote: > > > > 5 Add netgraph control messages to get the associated interface name > > > > and index, so that it's possible to set promiscuous mode, multicast > > > > addresses, etc. by: > > > > from the kernel - getting the interface structure (using > > > > ifindex2ifnet[if_index]), and then calling ifioctl() > > > > (small note: ifioctl() will be made to handle p == NULL) > > > > from userland - using the normal ioctl() mechanism > > > > > > The ifindex is a hack that should go away (in my opinion). > > > > I definitely agree on this ! > > You can't just remove if_index. > if_index is part of standard API defined in RFC2553 (Basic Socket > Interface Extention for IPv6) and RFC2292 (Advanced Socket API for > IPv6). yeah.. having not really looked at those RFCs I didn't realise this. What a pitty. it's so unsuitable for some environments. > > -Kenjiro -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 9:11:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 35E8437B565 for ; Sun, 23 Apr 2000 09:11:19 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA05698; Sun, 23 Apr 2000 12:11:10 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sun, 23 Apr 2000 12:11:09 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Assar Westerlund Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <5ln1mkom0h.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23 Apr 2000, Assar Westerlund wrote: > Robert Watson writes: > > Any idea what the default idle time before keepalives kick in is? > > Is it really keep-alive that's interesting here? Isn't it the > retransmission timer? > > If somebody is doing "mbuf exhaustion", we will have un-acked > outstanding data. And it should be the same case with "process > saturation". Regardless of the mechanism, presumably the goal would be to sever connections early on if they aren't demonstrating decent properties. I.e., acknowledging data transmissions, et al. So give them 30 seconds, and if they haven't acknowledged anything, cut them off. Far better than the multi-minute delay, although still not ideal. The reason for the keepalive timer suggestion was that it's already a mechanism for detecting hosts that are not responding properly to TCP and therefore should be disconnected. Making it slightly more agressive early in the connection would have the effect of weeding out hosts that build connections to make a request, but then ``disappear''. Avoiding fragility and brittleness is a big issue, however. For example, unwillingness to accept data quickly is not the same as unwillingness to accept data at all. Of course, none of this solves the fundamental issue with denial of service: if you offer a service that costs you something to provide, and the capacity exists for someone to consume that service very cheaply, then there is the opportunity for denial of service. The goal is to sufficiently raise the bar that denial of service is relatively costly to perform, which can be done by reducing opportunities for flooding, reducing vulnerability to the easy attack channels, et al. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 9:44:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id EBE7D37B999 for ; Sun, 23 Apr 2000 09:44:16 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Sun, 23 Apr 2000 11:44:08 -0500 From: Richard Wackerbarth To: Tomaz Borstnar Subject: Re: enforcing DHCP usage Date: Sun, 23 Apr 2000 11:44:07 -0500 X-Mailer: KMail [version 1.1.40] Content-Type: text/plain References: <4.3.1.2.20000423174128.035fd280@193.189.189.100> In-Reply-To: <4.3.1.2.20000423174128.035fd280@193.189.189.100> Cc: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Message-Id: <00042311440700.14566@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Apr 2000, Tomaz Borstnar wrote: > Anyone know a solution where one can enforce usage of DHCP ie. nobody will > be able to communicate outside its physical ethernet if it doesn't acquire > proper address via DHCP server. There are some possible kludges where a > script would check DHCP leases and block traffic for all but properly > leased addresses Fundamentally, that is all that you can do. Remember that the purpose of DHCP is to assist a machine in getting configuration information. It is not an enforcement mechanism. Any host can attempt to use ANY IP address and there is nothing technical that you can do to stop it. Your only leverage is either "administrative edict" ( ... or else you're fired ) or some filter that refuses to accept unauthorized packets. Even in the latter case, you will have a lot of trouble and expense distinguishing between someone "squatting" on an IP address and the one who is using it properly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 11:29:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id A95FE37B842 for ; Sun, 23 Apr 2000 11:29:23 -0700 (PDT) (envelope-from ryan@sasknow.com) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id MAA68164; Sun, 23 Apr 2000 12:30:16 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sun, 23 Apr 2000 12:30:15 -0600 (CST) From: Ryan Thompson To: Miguel Ruiz Cc: freebsd-net@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <39087384@MailAndNews.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Miguel Ruiz wrote to freebsd-net@FreeBSD.ORG: > Hey all: > > I was looking at this server, and it was generating a bunch of natd > processes. A bunch = 2 or 3? 20 or 30? 200 or 300? > 1000? In the first case (or two), I would suspect human error.. I.e., an administrator manually running too many natd processes where kill -HUP should be used. In the latter cases, I would suspect someone has created an automated script that was perhaps designed to keep natd running in the event it stopped, but their script obviously has some issues :-) > To the best of my memory there should only be one natd process > running. I tried to correct this and made a mistake and did a killall -9 > natd. This machine needs natd to be running or else it shut down all ip > interfaces. Oops. Nothing is hard coded all they have to do is reboot. The good news is if natd forces the link down for some reason, an ifconfig UP will generally reset it. > The problem is we need to find out why it was creating multiple natd > process. I've never witnessed this personally... Perhaps it was operator error? (Ran natd again instead of kill -HUP, or perhaps there is some homemade script that is responsible for the extra processes). > Does anyone know how 2 shutdown the xtra processes? You should be able to kill the extras individually by process ID, unless there are hundreds or thousands of them, in which case killall -9 natd IS the way to go. > thanx! > > M1k3 Virtually yours, - Ryan -- Ryan Thompson Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 15: 2:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 06F8D37B695; Sun, 23 Apr 2000 15:02:20 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id SAA47172; Sun, 23 Apr 2000 18:02:18 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200004232202.SAA47172@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Watson Cc: Assar Westerlund , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: netkill - generic remote DoS attack (fwd) References: In-reply-to: Your message of "Sun, 23 Apr 2000 12:11:09 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 18:02:18 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On 23 Apr 2000, Assar Westerlund wrote: > > > Robert Watson writes: > > > Any idea what the default idle time before keepalives kick in is? > > > > Is it really keep-alive that's interesting here? Isn't it the > > retransmission timer? > > > > If somebody is doing "mbuf exhaustion", we will have un-acked > > outstanding data. And it should be the same case with "process > > saturation". > > Regardless of the mechanism, presumably the goal would be to sever > connections early on if they aren't demonstrating decent properties. Yes, but the difficulty is that there is no commonly agreed upon description of "decent properties." Just because you don't use TCP in a certain way, on unusal paths doesn't mean that it's wrong. > I.e., acknowledging data transmissions, et al. So give them 30 seconds, > and if they haven't acknowledged anything, cut them off. Far better than > the multi-minute delay, although still not ideal. Well, hell, a V.90 modem can tie itself into knots for 30 seconds trying to retrain. This is a little quick on the trigger, don't you think? Not to mention folks trying to use TCP on long-delay, crappy paths with connectivity that might be intermittant. TCP will sever connections on it's own if there is unacknowledge data. If you have a reasonable measurement of the RTT, you might choose to bias the timeout based on that; but to simply pick a number out of your hat which might reasonably be too small is wrong. > The reason for the keepalive timer suggestion was that it's already a > mechanism for detecting hosts that are not responding properly to TCP and > therefore should be disconnected. Making it slightly more agressive early > in the connection would have the effect of weeding out hosts that build > connections to make a request, but then ``disappear''. The keepalive mechanism is both poorly named (it's really a MAKE-DEAD mechansim), and a crock. If an application cares about idleness, then it should contain the mechanism to detect it. There's no reason why my TCP connection should be needlessly aborted when there's no unacknowledged data from either endpoint, and there's a transient connectivity failure. > Avoiding fragility and brittleness is a big issue, however. For example, > unwillingness to accept data quickly is not the same as unwillingness to > accept data at all. Of course, none of this solves the fundamental issue > with denial of service: if you offer a service that costs you something to > provide, and the capacity exists for someone to consume that service very > cheaply, then there is the opportunity for denial of service. The goal is > to sufficiently raise the bar that denial of service is relatively costly > to perform, which can be done by reducing opportunities for flooding, > reducing vulnerability to the easy attack channels, et al. I really wish folks would be much less quick to leap into screwing with the implementation of TCP. It has evolved to the state it's in over many years of painful experience and hard-won knowledge. Breaking TCP for perfectly reasonable uses is also a denial-of-service attack of sorts. Perhaps if you're concerned that random people are attacking your system by using the way TCP functions, you should instead use IPSEC to authenticate the remote party before allowing the connection to open? That at least addresses the a problem in a direct way, rather than introducing further unintended consequences by changing the way the TCP works. louie > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > 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 Sun Apr 23 15:56:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 0324937BAAD for ; Sun, 23 Apr 2000 15:56:15 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA15132; Sun, 23 Apr 2000 23:55:40 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA00515; Sun, 23 Apr 2000 21:41:19 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200004232041.VAA00515@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Fulford Cc: freebsd-net@freebsd.org, brian@hak.lan.Awfulhak.org Subject: Re: Stand-alone routers,fbsd, & Dynamic ISP addresses In-Reply-To: Message from Robert Fulford of "Sun, 23 Apr 2000 09:05:25 EDT." <3902F515.996E52AF@alltel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Apr 2000 21:41:19 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Buy yourself a PCI Fritz ISDN card and look at /usr/share/examples/ppp/*isdn* Dynamic IPs are no problem. > I have 2 W2k boxes & 1 Fbsd box...I would love to use > the fbsd box as a dfgw/ipfw/natd for the other 2 boxes > when connecting to the internet...I am just now learning > fbsd, so I am very confused! I am planning on getting > ISDN from my only local ISP soon, but I am sure the IP > they will give my router will be dynamic....If I can't > locate an internal USRobotics Sportster 128k non-PnP, > I will buy a Nortel RT338 stand-alone ISDN Router... > My quandary is this.....how in the heck can I tell the > fbsd box that the router,which doesn't have an IP from > the ISP yet, is where packets are to be routed? I > have been told by others that I won't be using pppd, > ppp, or even pppoed in this type of setup...I am > leaning toward the Nortel, as it would allow me to > have net access if the hd on the bsd box were to die. > I do not want the ISDN router to control the NAT for > my network, or use it's DHCP capabilities.... > Thanks, > Jeb -- 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 Sun Apr 23 19:21:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id F11C537B750 for ; Sun, 23 Apr 2000 19:21:24 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id VAA06065; Sun, 23 Apr 2000 21:29:42 -0500 (EST) (envelope-from csg) Date: Sun, 23 Apr 2000 21:29:42 -0500 From: "C. Stephen Gunn" To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000423212942.A5453@waterspout.com> References: <200004230411.VAA17652@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004230411.VAA17652@bubba.whistle.com>; from archie@whistle.com on Sat, Apr 22, 2000 at 09:11:45PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Apr 22, 2000 at 09:11:45PM -0700, Archie Cobbs wrote: > So, I've got a proposal :-) These are not all my ideas, but > here they are collected in one place.. It's good to see someone else has been pondering these issues. If the goal is to overhaul the networking code in FreeBSD, we should spend significant time planning, and researching other solutions to the improvements we want. > 1 Move the BPF and BRIDGE code out of all of the Ethernet drivers > and put it into ether_input() I brought up some discussion on doing exactly this a few weeks ago. To quote Garrett Wollman "go for it." > 2 Add a new parameter to ether_input() which a driver will set > to non-zero indicating ``IFF_PROMISC was set and this packet > came in, but it's not really supposed to be received so don't > send it up the networking stack.'' While Ethernet is certainly the most popular packet network interface that people use on FreeBSD. I'd rather see the API for all layer-1 and layer-2 devices converge. ether_input(), token_input(), atm_input() and media_input() should certainly be orthogonal, if not identical. For any given media, assuming your suggestion [#1], media_input() would take a pointer to the device structure, and a mbuf chain containing the packet, with the link-layer header intact. media_input() should handle BPF taps, remove the link-header if appropriate, and then route the packet up to one of the registered layer-2 protocols. I think anything outside this should be in the device flags. I'm voting to have flags in struct ifnet that apply to _ANY_ device, and another media flags for each specific link layer. The default behavior for any given device should be to present itself to userland just like it always have. I plug in a 3c905B-TX card, and I still end up with an xl device. Assuming, I've not done something more advanced with the configuration. You mention this below in [#4]. Since deletion of interfaces works now, there are some significant advantages of having an generic "media-like" interface. This could be used for more advanced configs like Bridging and VLANs. It should allow for aggregation/bonding of interfaces, and perhaps get something like Cisco-ISL or Fast EtherChannel in there as well. > 3 Move the netgraph part of if_ethersubr.c into a new file ng_ether.c > and make it so the Ethernet node type can be a KLD and still work. Sounds good to me. > 4 Change the ng_ether node type to have these two hooks: > "device" -- connection down to the raw Ethernet device > "stack" -- connection to the Ethernet stack and upper stacks ng_ether would seem to be a good starting point for any ethernet-like interface on top of a group of (or logical seperation of) physical interfaces. > 5 Add netgraph control messages to get the associated interface name > and index, so that it's possible to set promiscuous mode, multicast > addresses, etc. by: > from the kernel - getting the interface structure (using > ifindex2ifnet[if_index]), and then calling ifioctl() > (small note: ifioctl() will be made to handle p == NULL) > from userland - using the normal ioctl() mechanism Mmm.. Cleaning out the "garbage can of system calls" eh? > 6 Minor fix to ppp(8), etc. to handle different ng_ether hook names > > Re #4: When neither hook is connected, they are effectively connected > together -- i.e., the interface functions normally. Otherwise, you > get the obvious data connection, allowing both sending and recieving > raw frames to the device, but also input/output from the Ethernet > stack associated with the interface. Filtering Ethernet frames based > on interface would be easy .. etherfw(8) anyone? :-) That's one of the obvious advantages to a more-complete netgraph deployment in the kernel. Filtering/tapping packet flows nearly anywhere in the kernel. Drool... > 6 Convert BRIDGE into a netgraph node. This would make it more > powerful because you could do bridging on any arbitrary subset > of interfaces. Its a logical step. > 7 (Optional) Remove existing BRIDGE support in favor of netgraph version > Only if people want to for simplicity. I'd have no problems with this, providing the rest of it works well of course. It's appropriately at the end of your list. I've got a few daydreams to add to your list: - Appropriate improvements to other media types to keep them up to speed with the improvements made to ethernet. - Planning for, if not the implementation of run-time loadable protocol stacks. I'm not entirely sure what all this involves, but it minimally requires an API to register a protocol with each media handler. Hello? I'm the tcp/ip stack that joe-user just loaded, send me ethernet frames with a ether_type of ETHERTYPE_IP. Nope, don't need a copy of the link header. Oh by the way, I need ARP, so load up my bud as well. Time to go register with ATM or other physical/link layer devices I know how to talk to. I know this will require some rework on the protocol-socket interface as well, but that's certainly not my forte. - Like you said above, a generic filter module for netgraph. Something that's more efficient thatn IPFW. Perhaps something that has a compiler for the filter language. - Alternate queing mechanisms. Something like the fair weighted queue's that Luigi has on his experiments page. Make sure we support bonded/shared interfaces well. Have support for priority tags with 802.1q or the like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 20:23:16 2000 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 6C04C37B68B for ; Sun, 23 Apr 2000 20:23:14 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA31753; Sun, 23 Apr 2000 23:23:08 -0400 (EDT) (envelope-from wollman) Date: Sun, 23 Apr 2000 23:23:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200004240323.XAA31753@khavrinen.lcs.mit.edu> To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <200004232202.SAA47172@whizzo.transsys.com> References: <200004232202.SAA47172@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Perhaps if you're concerned that random people are attacking your system > by using the way TCP functions, you should instead use IPSEC to authenticate > the remote party before allowing the connection to open? Not helpful. The reason why these DoS attacks are so successful is that it's the server-operator's business to offer service to all comers. To restrict access (particularly to the tiny subset of the population which would be authenticable using IPSEC) would defeat the entire purpose of the server. Unfortunately, this particular DoS is inherent in the TCP design. There are a whole bunch of others that are not as widely known, which have (relatively) easier solutions. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 20:33: 5 2000 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 0D43837B505; Sun, 23 Apr 2000 20:33:03 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA31816; Sun, 23 Apr 2000 23:33:00 -0400 (EDT) (envelope-from wollman) Date: Sun, 23 Apr 2000 23:33:00 -0400 (EDT) From: Garrett Wollman Message-Id: <200004240333.XAA31816@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: Archie Cobbs , pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <3902A56B.167EB0E7@elischer.org> References: <200004230411.VAA17652@bubba.whistle.com> <3902A56B.167EB0E7@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Theoretically this is not needed. We already have the address of > the ifnet structure and thus the arpcom, so we have the flags, AND > the local ethernet address, so we can just do the same test that > is presently done in the drivers. We have all the the info we need. Some drivers are kind enough to tell is without needing to test. A suitable microbenchmark would tell whether or not it's worth it. (I expect it's a wash, personally -- the MAC address is likely to already be in cache by the time we care, and it's no more than eight bytes long.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 20:37:44 2000 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 3942437B55B for ; Sun, 23 Apr 2000 20:37:41 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA31858; Sun, 23 Apr 2000 23:37:40 -0400 (EDT) (envelope-from wollman) Date: Sun, 23 Apr 2000 23:37:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200004240337.XAA31858@khavrinen.lcs.mit.edu> To: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004240333.XAA31816@khavrinen.lcs.mit.edu> References: <200004230411.VAA17652@bubba.whistle.com> <3902A56B.167EB0E7@elischer.org> <200004240333.XAA31816@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < Some drivers are kind enough to tell is without needing to test. What I meant to say is: Some hardware is kind enough to tell us whether the packet matched our address, so that a software comparison is unnecessary. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 23 22: 7:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id BF1CF37B9AB for ; Sun, 23 Apr 2000 22:07:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA06597; Sun, 23 Apr 2000 23:07:15 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3903D68F.9A217B9B@softweyr.com> Date: Sun, 23 Apr 2000 23:07:27 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph References: <200004230411.VAA17652@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > So, I've got a proposal :-) These are not all my ideas, but > here they are collected in one place.. > > The current situation with Ethernet drivers, Bridging, BPF, and > Netgraph is that it's all a bit klugey and gross. As evidence of > this, every single Ethernet driver (I've counted 45) must contain > the same duplicated code to handle both BPF and bridging.. > > What do people think? Yes. What we have now is fugly, and this sounds like a great clean-up. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 0:13:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2AC4437B93D for ; Mon, 24 Apr 2000 00:13:26 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id DAA16031; Mon, 24 Apr 2000 03:13:10 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 24 Apr 2000 03:13:10 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Louis A. Mamakos" Cc: Assar Westerlund , freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <200004232202.SAA47172@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Apr 2000, Louis A. Mamakos wrote: > ... These are all decent points, and in a number senses reiterate the point I made about avoiding the introduction of new fragility and brittleness into the TCP stack. I don't think anyone here is under the impression that: 1) Changes should happen immediately without extensive testing 2) Changes should be enabled by default (there's a fair degree of precedent for minor TCP changes to avoid specific attacks, but having them enabled by run-time sysctls) 3) The scope of the changes should be broad and dramatically change the properties of long-term connections and behavior Thus far, this has been a brain-storming session to address a very specific attack in very specific environments. All ideas thrown in by various participants have been purely suggestions, and figures (such as ``30 seconds'') were ballparks to be used in back-of-napkin calculations concerning balancing effectiveness and risk. That said, while it is true (as you point out) that TCP is a well-honed tool, researched, developed, and adapted by experienced and competent people, it is also true that TCP has had to change in a number of ways over the years to reflect changing needs and environments. TCP was not designed to address denial of service attacks, and it makes sense to harden the TCP implementation against these attacks given the (relatively) recent desire by users of the protocol to resist these attacks. Given your clear experience in the area, would you have any suggestions for addressing this attack? Given exchanges with a number of victims of denial of service attacks, I respectfully suggest that for many providers, being able to accept any connections at all is still an improvement over accepting no connections :-). Knowing when to act, and when not to act, is important but should not rule out brainstorming for solutions. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 1:46:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id F298337B628; Mon, 24 Apr 2000 01:45:56 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA13700; Mon, 24 Apr 2000 10:46:31 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004240846.KAA13700@info.iet.unipi.it> Subject: Re: Draft bridging chapter for handbook In-Reply-To: <4.2.2.20000420122909.039d9140@mail.virtation.com> from Steve Peterson at "Apr 20, 2000 12:34:04 pm" To: Steve Peterson Date: Mon, 24 Apr 2000 10:46:31 +0200 (CEST) Cc: freebsd-doc@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Having just gone through the work to set up bridging on FreeBSD 4.0, I > thought I'd take a whack at writing a manual section on it. It's at > http://www.virtation.com/home/stevep/freebsd-bridging.txt and I'd > appreciate your feedback. I'm not a subscriber to these lists, so if you > could copy me directly with your comments that would be great. for sure there is a mistake, the kernel option is "BRIDGE" and not "BRIDGING" as you mention. cheers luigi > Steve Peterson > > -- > Steve Peterson +1 952 948 9729 > Principal Consultant FAX +1 612 677 3050 > Virtation Technologies, Inc. http://virtation.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 Apr 24 8:45: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3BDB837BB54; Mon, 24 Apr 2000 08:45:01 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id KAA16081; Mon, 24 Apr 2000 10:47:56 -0500 (CDT) (envelope-from jlemon) Date: Mon, 24 Apr 2000 10:47:56 -0500 (CDT) From: Jonathan Lemon Message-Id: <200004241547.KAA16081@prism.flugsvamp.com> To: rwatson@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: > >Thus far, this has been a brain-storming session to address a very >specific attack in very specific environments. All ideas thrown in by >various participants have been purely suggestions, and figures (such as >``30 seconds'') were ballparks to be used in back-of-napkin calculations >concerning balancing effectiveness and risk. Given a quick look at netkill, it appears that it mainly acts as a DoS by establishing a connection, then dropping its end, leaving the server to maintain the connection until TCP gives up. The server will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 state, depending on the traffic patterns, and what the attacker does. As was pointed out, it is difficult to discern when a connection in this state is the result of legitimate traffic, or the result of an attack. However, a strong indication that the machine is under attack is a large number of connections from the same IP address. Unlike a SYN flood, the attacker must complete the TCP handshake, so the server will have the IP address of the attacker (leaving the issue of packet sniffing aside at the moment). RFC 2140 (which FreeBSD implements in some form) provides for a shared control block for TCP connections. Would it make sense to add some kind of connection counter to this structure as well? Then, armed with this information (and if the sysctl knob allows), the server can make decisions for connections from a certain host: 1. refuse to accept any more connections 2. drop existing TCP connections 3. accelerate the timeout This might catch most of the "ankle-biter" attacks without interfering with normal traffic, but also might be a problem for people who are connecting through some type of NAT service, where all connections appear to be from a single host. Unfortunately, the shared information is currently stored in a route entry, so this would require a little restructuring of how things work. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 9:25:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B463C37B596 for ; Mon, 24 Apr 2000 09:25:25 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA18011; Mon, 24 Apr 2000 12:25:23 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 24 Apr 2000 12:25:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jonathan Lemon Cc: net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) In-Reply-To: <200004241547.KAA16081@prism.flugsvamp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Apr 2000, Jonathan Lemon wrote: > Given a quick look at netkill, it appears that it mainly acts as > a DoS by establishing a connection, then dropping its end, leaving > the server to maintain the connection until TCP gives up. The server > will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 > state, depending on the traffic patterns, and what the attacker does. Sounds right to me, although the technique really applies to any part of the state machine--presumably you select one of those states because they provide the longest timeouts before automated garbage collection or connection verification ``keepalive''. At this point with the ESTABLISHED case, as Louis has pointed out, it is generally assumed that the application level will take care of detecting dead end-hosts not responding in a timely manner. However, if the application layer does do this and perform a close(), the state still hangs around in the FIN_WAIT1 stage for a long time, so I don't see any purely application layer solution helping us. The question seems to be: is it acceptable to more agressively manage state and timeouts, possible limited to specific circumstances, so as to improve the performance of the FreeBSD TCP stack under conditions of load similar to this attack (i.e., high levels of state consumption and/or exhaustion), without substantially breaking normal behavior. > As was pointed out, it is difficult to discern when a connection in > this state is the result of legitimate traffic, or the result of an > attack. However, a strong indication that the machine is under > attack is a large number of connections from the same IP address. > Unlike a SYN flood, the attacker must complete the TCP handshake, so > the server will have the IP address of the attacker (leaving the issue > of packet sniffing aside at the moment). I'd agree that the consistent IP address assumption is certainly valid for a single connection, and likely to be valid for multiple connections given the common attack environments. You can imagine other environments, but it's probably not worth discussing them in detail. > RFC 2140 (which FreeBSD implements in some form) provides for a shared > control block for TCP connections. Would it make sense to add some kind > of connection counter to this structure as well? Then, armed with this > information (and if the sysctl knob allows), the server can make decisions > for connections from a certain host: > > 1. refuse to accept any more connections > 2. drop existing TCP connections > 3. accelerate the timeout > > This might catch most of the "ankle-biter" attacks without interfering > with normal traffic, but also might be a problem for people who are > connecting through some type of NAT service, where all connections appear > to be from a single host. I see this as effectively a show-stopper in most environments, given the predominence of: 1) Network Address Translation 2) Firewalls 3) Proxy caches in front of large networks. 4) Web performance testers that use a small number of machines to simulate high load levels for marketing foo However, it still might be a useful piece of functionality for many environments. You can imagine: sysctl -w net.inet.tcp.max_connections_per_ip=20 Or the like. We'd have to handle the FIN states carefully, as technically they are not connections (application level has waved goodbye on both sides in normal situations) but state is still consumed for a substantial period of time. > Unfortunately, the shared information is currently stored in a > route entry, so this would require a little restructuring of how > things work. Is RTT estimate measurement currently stored per-host or per-connection? Ideally, per-host, in which case wherever that is stored might be the right place to look (routing entries?). I'm not to familiar with that aspect of our TCP stack, unfortunately, and currently in a time crunch. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 9:39:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.prophetnetworks.net (mail.pns.net [63.71.252.9]) by hub.freebsd.org (Postfix) with ESMTP id DE74E37B645; Mon, 24 Apr 2000 09:39:22 -0700 (PDT) (envelope-from bvaughn@pns.net) Received: from radium (radium.noc.prophetnetworks.net [63.71.252.245]) by mail.prophetnetworks.net (8.9.3/8.9.1) with SMTP id LAA61595; Mon, 24 Apr 2000 11:39:20 -0500 (EST) (envelope-from bvaughn@pns.net) From: "Ben Vaughn" To: Cc: Subject: fxp0: device timed out - Possible netkill? Date: Mon, 24 Apr 2000 11:39:10 -0500 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, We recently got a Dell Poweredge 4400 with an onboard Intel Pro 100/b. The machine acts as a shell server, so it catches DoS attacks often. However, since we have been putting this box up, we will get "fxp0: device timed out" many times on the console. The box freezes up completely, and does not even reboot. MAXUSERS is 1024. I've never had this problem on a previous dell machine with an fxp card. Does anybody have any idea? Thanks in advance, Ben Vaughn Prophet Network Systems To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 10:11:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by hub.freebsd.org (Postfix) with ESMTP id C959837B7ED for ; Mon, 24 Apr 2000 10:11:02 -0700 (PDT) (envelope-from shalunov@att.com) Received: from tuzik.lz.att.com ([135.25.200.84]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA04303 for ; Mon, 24 Apr 2000 13:10:49 -0400 (EDT) Received: (from shalunov@localhost) by tuzik.lz.att.com (8.9.2/8.9.2) id NAA44530; Mon, 24 Apr 2000 13:10:42 -0400 (EDT) (envelope-from shalunov@att.com) Date: Mon, 24 Apr 2000 13:10:42 -0400 (EDT) Message-Id: <200004241710.NAA44530@tuzik.lz.att.com> From: stanislav shalunov To: freebsd-net@freebsd.org References: Subject: Re: netkill - generic remote DoS attack Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I missed part of the discussion about FIN_WAIT flooding (term coined by Aleph1) a.k.a. netkill, catching up reading the archives. > From: Robert Watson > The easy solutions that come to mind all increase the brittleness of the > network, but are probably better than being toasted: > 1) Decrease timeout on connections that don't respond to ACKs > 2) Enable keep-alives on all connections by default (we should probably do > this anyway for other reasons) > 3) Decrease the wait period in FIN-WAIT-1, especially if no ACKs received It seems none of these work to prevent netkill. The root cause--kernel doesn't know what to do when mbuf space is all taken--remains. The solution must possess the following properties: 1. When there's no attack everything should work as reliably as before; 2. When there's an attack the system must be able to serve at least some requests; 3. Older connections must not be penalized at the expense of bad connections; 4. Ideally, the algorithm used should heuristically identify mostly the bad connections and hurt them, not the good ones. It follows from (1) that until the mbuf space is full kernel shouldn't do anything unusual. It follows from (2) that when memory gets full the system mustn't panic as it does now, and it must do either of these: (a) stop accepting new connections until old ones time out; (b) free some mbuf memory forcibly. To do (b) properly, we can't just throw away pieces of send queues. We must tear down some connections and send an RST to the remote end and return ENOBUFS to the application, if any, using them locally. The solution (a) removes the obvious bug (system panics), but doesn't solve the problem. It appears that some variation of (b) must be deployed. The remaining question is what algorithm to use to identify the connections that need to be torn down (taking into account points (3) and (4)). I strongly suggest some sort of randomness in the selection. This way, even if some good connection possesses properties of what we identify as a bad connection, the remote end still has some chance of getting through when it retries. It's also important to free up a lot of memory. Tearing down connection is better than a panic, but it's bad. Better tear down a lot rarely than randomly kill a connection here and a connection there. This way, there are brief periods when it doesn't work, and it all returns back to normal and stays at least for a few minutes. -- stanislav shalunov, WHPD, shalunov@att.com 732-576-3252 1:10PM up 190 days, 2:32, 6 users, load averages: 0.04, 0.03, 0.02 Conscience is what hurts when everything else feels so good. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 12:38:40 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id A900737BBAB for ; Mon, 24 Apr 2000 12:38:37 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FTJ009OSD31A2@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 24 Apr 2000 15:35:26 -0400 (EDT) Date: Mon, 24 Apr 2000 15:36:22 -0400 (EDT) From: Bosko Milekic Subject: Re: netkill - generic remote DoS attack In-reply-to: <200004241710.NAA44530@tuzik.lz.att.com> X-Sender: bmilekic@jehovah.technokratis.com To: stanislav shalunov Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Apr 2000, stanislav shalunov wrote: > (a) stop accepting new connections until old ones time out; > (b) free some mbuf memory forcibly. > > To do (b) properly, we can't just throw away pieces of send queues. > We must tear down some connections and send an RST to the remote end > and return ENOBUFS to the application, if any, using them locally. > > The solution (a) removes the obvious bug (system panics), but doesn't > solve the problem. It appears that some variation of (b) must be > deployed. > Well, with regards to (b) -- somewhat -- I have been thinking about a solution for `local' processes swallowing up sockbuf space and, consequently, mbufs. I'm sure you can think of something else to append to that and have similiar behavior for remote attacks. I've had little time to continue working on this right now, mainly due to lack of interest (apart from a few people who offered comments, notably Eivind Eklund) and also, of course, upcoming finals. I'm very willing to continue the work once this is all over, which will hopefully be in approximately 3 weeks. In the meantime, feel free to look it over yourself, since you've obviously gotten the point: http://pages.infinit.net/bmilekic/sockclnd/index.html -Bosko -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 13:13: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by hub.freebsd.org (Postfix) with ESMTP id 6420C37BA25 for ; Mon, 24 Apr 2000 13:12:52 -0700 (PDT) (envelope-from shalunov@att.com) Received: from tuzik.lz.att.com ([135.25.200.84]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA16871 for ; Mon, 24 Apr 2000 16:12:49 -0400 (EDT) Received: (from shalunov@localhost) by tuzik.lz.att.com (8.9.2/8.9.2) id QAA46910; Mon, 24 Apr 2000 16:12:38 -0400 (EDT) (envelope-from shalunov@att.com) Date: Mon, 24 Apr 2000 16:12:38 -0400 (EDT) Message-Id: <200004242012.QAA46910@tuzik.lz.att.com> From: stanislav shalunov To: bmilekic@dsuper.net Cc: freebsd-net@FreeBSD.ORG In-reply-to: (message from Bosko Milekic on Mon, 24 Apr 2000 15:36:22 -0400 (EDT)) Subject: Re: netkill - generic remote DoS attack References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Bosko Milekic > > Well, with regards to (b) -- somewhat -- I have been thinking about > a solution for `local' processes swallowing up sockbuf space and, > consequently, mbufs. I'm sure you can think of something else to append to > that and have similiar behavior for remote attacks. I've looked at your paper draft (printed it out, even). I'm not a real kernel hacker to appreciate what's difficult and what's possible, but it seems to me that the daemon design you describe would suffer because of its out-of-layer placement. While it's a noble goal to try to prevent local DoS attacks, it's probably not really possible in Unix model (a virtual machine would help). I think it'd make more sense to concentrate on remote attacks, and limit oneself to AF_INET family. UDP is fine: We send it and forget about it. If we are short of any resource, we drop it. An attack such as netkill requires protection of TCP stack that amounts to killing TCP connections. To make intelligent decisions, we need some information about connections (queues, rtt, time of last packet from remote, etc.) TCP code has all the information for TCP packets. How easy would it be to look for it from a separate daemon? How maintanable would it be? If something changes later, how easy would it be to forget about the daemon? And since it'll only show under attack, testing might not reveal such omission. Since something has to happen pretty fast when there's no mbuf space for new connections or for growing send queues, it'd seem that kernel itself might seem like a natural place for such action, no? > I'm very willing to continue the work once this is all over, which > will hopefully be in approximately 3 weeks. I'm willing to provide input and to discuss what the system should do in my opinion as long as the kernel is a black box. My expertise is insufficient to discuss placement of those actions in particular places in kernel. --Stanislav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 13:39:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 96ECC37BBD7 for ; Mon, 24 Apr 2000 13:39:43 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FTJ00DM3FV2P2@field.videotron.net> for freebsd-net@FreeBSD.ORG; Mon, 24 Apr 2000 16:35:26 -0400 (EDT) Date: Mon, 24 Apr 2000 16:36:19 -0400 (EDT) From: Bosko Milekic Subject: Re: netkill - generic remote DoS attack In-reply-to: <200004242012.QAA46910@tuzik.lz.att.com> X-Sender: bmilekic@jehovah.technokratis.com To: stanislav shalunov Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Apr 2000, stanislav shalunov wrote: > While it's a noble goal to try to prevent local DoS attacks, it's > probably not really possible in Unix model (a virtual machine would > help). Given the argument of an already existing sockbuf limiting implementation, and the argument you've brought up above, then the conclusion that you have drawn seems justified. However, solutions must exist even in cases were configuration limits fail. The `daemon,' perhaps a misleading term, simply means in this case the it is to run as a so-called `kernel process,' like `bufdaemon,' for example. The layout that you've seen probably suffers from certain specific issues, but it nonetheless offers system-wide mbuf-exhaustion prevention for local processes. Limiting sockbuf space is great, but no matter to how low you may want to limit, enough [limited] offenders could eventually exhaust available resources -- this is primarily when the `daemon' is to be invoked. > > I think it'd make more sense to concentrate on remote attacks, and > limit oneself to AF_INET family. > > UDP is fine: We send it and forget about it. If we are short of any > resource, we drop it. > > An attack such as netkill requires protection of TCP stack that > amounts to killing TCP connections. Yes, this is exactly what makes things like this difficult. You want to implement something very flexible and reliable in-all-cases, but at the same time, you wan't to keep it clean and easily modifiable (as opposed to scattered all around the place). > > To make intelligent decisions, we need some information about > connections (queues, rtt, time of last packet from remote, etc.) > > TCP code has all the information for TCP packets. > > How easy would it be to look for it from a separate daemon? > How maintanable would it be? If something changes later, how easy > would it be to forget about the daemon? And since it'll only show > under attack, testing might not reveal such omission. > > Since something has to happen pretty fast when there's no mbuf space > for new connections or for growing send queues, it'd seem that kernel > itself might seem like a natural place for such action, no? As I said, the so-called `daemon' is a `kernel process,' and it runs in a kernel context with access to the kernel's global lists, and so on. Regardless, your point regarding speed in the case of remote-attacks is valid. This is specifically why I split the problem in two: (a) The local case; (b) The remote case. The approaches, as you've noticed, are entirely different. > I'm willing to provide input and to discuss what the system should do > in my opinion as long as the kernel is a black box. > > My expertise is insufficient to discuss placement of those actions in > particular places in kernel. > > --Stanislav > I'm glad that you've already commented as you have and hope that you'll find time to perhaps "take the dive" and implement (or assist in) points (b) and (a) above. I'm also curious to see what changes are to come (if any) to this area of the tree as an indirect consequence of the WC/BSDi merger. -Bosko -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 13:49:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by hub.freebsd.org (Postfix) with SMTP id B15CE37B57F for ; Mon, 24 Apr 2000 13:49:50 -0700 (PDT) (envelope-from barney@databus.databus.com) From: Barney Wolff To: freebsd-net@freebsd.org Date: Mon, 24 Apr 2000 16:38 EDT Subject: Re: netkill - generic remote DoS attack Content-Length: 588 Content-Type: text/plain Message-ID: <3904b36a0.4ed4@databus.databus.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I suggest, strongly, that whoever attempts to mess with the tcp stack be very familiar with all the discussion that has gone on in the last few years on these sorts of problems. As a start, the end2end list (majordomo@zephyr.isi.edu, subscribe end2end-interest) and the tcp-impl list (majordomo@grc.nasa.gov, subscribe tcp-impl) and their archives will help you avoid embarassing flubs. Reinventing the wheel for freebsd, while fun, is not helpful. And of course, the BSDI folks know all about these issues. If I'm not smoking something, isn't there now a relationship? Barney Wolff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 17:41:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 0AE0337B737 for ; Mon, 24 Apr 2000 17:41:09 -0700 (PDT) (envelope-from ryan@sasknow.com) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id SAA42834 for ; Mon, 24 Apr 2000 18:06:02 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 24 Apr 2000 18:06:02 -0600 (CST) From: Ryan Thompson To: freebsd-net@freebsd.org Subject: Max T1. Throughput? Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the slightly off-topic post, here. Couldn't think of a better forum to inquire in, though. There seems to be some confusion around our region on what the maximum throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line from a local ISP. The package was sold to us as a burstable T1). My preliminary tests seem to show a segregation between up and down... Each maxing out at about 96KB/sec when the other is practically idle. Not the near-198KB/sec that I think I should be getting. Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? Thanks, - Ryan -- Ryan Thompson Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 18:41: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from www.bellnetworks.net (www.bellnetworks.net [208.177.187.234]) by hub.freebsd.org (Postfix) with ESMTP id 7DDF237B68A for ; Mon, 24 Apr 2000 18:40:59 -0700 (PDT) (envelope-from jerry@bellnetworks.net) Received: from itbell (dhcp-247.bellnetworks.net [208.177.187.247]) by www.bellnetworks.net (8.9.3/8.9.3) with SMTP id VAA68969; Mon, 24 Apr 2000 21:35:37 -0400 (EDT) (envelope-from jerry@bellnetworks.net) Message-ID: <001f01bfae56$9a79d780$f7bbb1d0@netrex.com> From: "Jerry Bell" To: "Ryan Thompson" , References: Subject: Re: Max T1. Throughput? Date: Mon, 24 Apr 2000 21:35:56 -0400 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.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org SDSL does mean that you should get the line speed (1.5Mbps in this case) in both directions. Typically, there is a bit more protocol overhead with sdsl, since it is usually run via atm. If you're getting 96k bytes/s, you either have 1) found the limit of your upstream provider, or 2) are paying for a 1.544Mbps line and only getting a 768kbps line. I think its a little more than coincidence that you're seeing 96k bytes/s, which works out to be exactly 768kbps, which is a common sdsl bandwidth. I'd have your provider check the equipment on both sides for a possibly misconfiguration, or a line problem forcing the lower speed. Good luck, Jerry ----- Original Message ----- From: Ryan Thompson To: Sent: Monday, April 24, 2000 8:06 PM Subject: Max T1. Throughput? > Sorry for the slightly off-topic post, here. Couldn't think of a better > forum to inquire in, though. > > There seems to be some confusion around our region on what the maximum > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > from a local ISP. The package was sold to us as a burstable T1). > > My preliminary tests seem to show a segregation between up and > down... Each maxing out at about 96KB/sec when the other is practically > idle. Not the near-198KB/sec that I think I should be getting. > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? > > Thanks, > - Ryan > > > -- > Ryan Thompson > Systems Administrator, Accounts > Phone: +1 (306) 664-1161 > > SaskNow Technologies http://www.sasknow.com > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > 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 Apr 24 19:19:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 4F77C37B737; Mon, 24 Apr 2000 19:19:25 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id TAA30215; Mon, 24 Apr 2000 19:14:44 -0700 (PDT) From: Archie Cobbs Message-Id: <200004250214.TAA30215@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <3902A56B.167EB0E7@elischer.org> from Julian Elischer at "Apr 23, 2000 00:25:31 am" To: julian@elischer.org (Julian Elischer) Date: Mon, 24 Apr 2000 19:14:44 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), pavel@alum.mit.edu, nsayer@sftw.com, luigi@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > Archie Cobbs wrote: > > The current situation with Ethernet drivers, Bridging, BPF, and > > Netgraph is that it's all a bit klugey and gross. As evidence of > > this, every single Ethernet driver (I've counted 45) must contain > > the same duplicated code to handle both BPF and bridging.. OK, here's a patch ready for review & test.. this patch does one thing, which is move the calls to BPF and BRIDGE'ing out of each Ethernet driver and into ether_input(). ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch Since it intersects with a zillion differnet Ethernet drivers, and my current machine only has one, it's kindof hard to test. It does seem to work OK with the fxp driver. If people can test these that would be much appreciated.. especially BPF, BRIDGE'ing, and multicast. Most of these patches are straightforward, however a few are more tricky.. in particular: - pci/if_de.c (what does TULIP_HASHONLY mean exactly?) - dev/ed/if_ed.c (contained a BRIDGE optimization) - dev/ie/if_ie.c (contained a BPF optimization) Also, although it's obvious for some, I can't know for certain which drivers are shared with other BSD's.. and therefore need the code that was ripped out put back (inside #ifndef __FreeBSD__). Thanks! -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 19:49:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id E9C1137BC33; Mon, 24 Apr 2000 19:49:17 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id WAA54708; Mon, 24 Apr 2000 22:49:17 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200004250249.WAA54708@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Watson Cc: Jonathan Lemon , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: netkill - generic remote DoS attack (fwd) References: In-reply-to: Your message of "Mon, 24 Apr 2000 12:25:22 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Apr 2000 22:49:17 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, 24 Apr 2000, Jonathan Lemon wrote: > > > Given a quick look at netkill, it appears that it mainly acts as > > a DoS by establishing a connection, then dropping its end, leaving > > the server to maintain the connection until TCP gives up. The server > > will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 > > state, depending on the traffic patterns, and what the attacker does. > > Sounds right to me, although the technique really applies to any part of > the state machine--presumably you select one of those states because they > provide the longest timeouts before automated garbage collection or > connection verification ``keepalive''. At this point with the ESTABLISHED > case, as Louis has pointed out, it is generally assumed that the > application level will take care of detecting dead end-hosts not > responding in a timely manner. However, if the application layer does do > this and perform a close(), the state still hangs around in the FIN_WAIT1 > stage for a long time, so I don't see any purely application layer > solution helping us. Actually, it shouldn't hang around in this state. When the local application does a close(), the local sends a TCP segment to the remote host with a FIN flag set, and wants this FIN to be acked. In the netkill attack, presumably the remote host won't be answering and the connection will get timed out. After the local host's FIN is ACKed, the connection state moves to FIN-WAIT-2 awaiting the remote host to send a FIN from it's side. > The question seems to be: is it acceptable to more agressively manage > state and timeouts, possible limited to specific circumstances, so as to > improve the performance of the FreeBSD TCP stack under conditions of load > similar to this attack (i.e., high levels of state consumption and/or > exhaustion), without substantially breaking normal behavior. Assuming you've got a good round trip time estimation, the timeout shouldn't need to take very long. But there is some administrative notion on how how aggresively you want to reduce the ACK timeout interval. I do like the notion of perhaps performing some sort of admission control on new connections based on the resources consumed by the remote host already. This also addresses the resources consumed on the *system* (e.g., process slots, etc) and not just by the network stack. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 20: 4:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 9A32D37BDCF for ; Mon, 24 Apr 2000 20:04:30 -0700 (PDT) (envelope-from ryan@sasknow.com) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id VAA46790; Mon, 24 Apr 2000 21:05:18 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Mon, 24 Apr 2000 21:05:18 -0600 (CST) From: Ryan Thompson To: Jerry Bell Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? In-Reply-To: <001f01bfae56$9a79d780$f7bbb1d0@netrex.com> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jerry Bell wrote to Ryan Thompson and freebsd-net@FreeBSD.ORG: > SDSL does mean that you should get the line speed (1.5Mbps in this case) in > both directions. Typically, there is a bit more protocol overhead with > sdsl, since it is usually run via atm. > > If you're getting 96k bytes/s, you either have 1) found the limit of your > upstream provider, or 2) are paying for a 1.544Mbps line and only getting a > 768kbps line. > > I think its a little more than coincidence that you're seeing 96k bytes/s, > which works out to be exactly 768kbps, which is a common sdsl bandwidth. > I'd have your provider check the equipment on both sides for a possibly > misconfiguration, or a line problem forcing the lower speed. Yes... I kind of thought that 96KB/sec was an interesting number myself... So I contacted the guru in charge of my uplink and he seems to think there is a misconfiguration on his end. Maximum bandwidth has always been a non-issue with my ISP... They have considerably more than they use, and I'm on a leased line directly to their downtown POP in my city, here, on a dedicated switch. (My router, plus two 1.5ms hops to outside network... Pretty low-latency setup.. Barely a ms or two over their own Ethernet co-lo times). So, I'm now in the process of getting what I paid for :-) > > Good luck, > > Jerry Thanks, Jerry (and all others who replied). You put a little more fuel in my fire. (Wasn't much of a fire... I says "D--, I think I'm only getting about 96K a second here" and he says "That's funny, Ry.. You should get a lot more than that... I'll check into it" and I says "Thanks" :-) Virtually yours, - Ryan -- Ryan Thompson Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 20:12:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 5A16837BBB4; Mon, 24 Apr 2000 20:12:41 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id WAA36787; Mon, 24 Apr 2000 22:15:26 -0500 (CDT) (envelope-from jlemon) Date: Mon, 24 Apr 2000 22:15:26 -0500 From: Jonathan Lemon To: "Louis A. Mamakos" Cc: Robert Watson , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) Message-ID: <20000424221526.F31449@prism.flugsvamp.com> References: <200004250249.WAA54708@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004250249.WAA54708@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 24, 2000 at 10:49:17PM -0400, Louis A. Mamakos wrote: > > On Mon, 24 Apr 2000, Jonathan Lemon wrote: > > > > > Given a quick look at netkill, it appears that it mainly acts as > > > a DoS by establishing a connection, then dropping its end, leaving > > > the server to maintain the connection until TCP gives up. The server > > > will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 > > > state, depending on the traffic patterns, and what the attacker does. > > > > Sounds right to me, although the technique really applies to any part of > > the state machine--presumably you select one of those states because they > > provide the longest timeouts before automated garbage collection or > > connection verification ``keepalive''. At this point with the ESTABLISHED > > case, as Louis has pointed out, it is generally assumed that the > > application level will take care of detecting dead end-hosts not > > responding in a timely manner. However, if the application layer does do > > this and perform a close(), the state still hangs around in the FIN_WAIT1 > > stage for a long time, so I don't see any purely application layer > > solution helping us. > > Actually, it shouldn't hang around in this state. When the local application > does a close(), the local sends a TCP segment to the remote host with > a FIN flag set, and wants this FIN to be acked. In the netkill attack, > presumably the remote host won't be answering and the connection will get > timed out. After the local host's FIN is ACKed, the connection state > moves to FIN-WAIT-2 awaiting the remote host to send a FIN from > it's side. Yes, but when in FIN_WAIT_1, the connection sits around waiting for its FIN to be acked, and keeps re-transmitting the FIN until TCP gives up. The timeout for this is essentially the retransmit interval, and TCP drops the connection after reaching maxrexmt, but this period is long (the same as a timeout in ESTABLISHED state). For FIN_WAIT_2, we start a timer at 2MSL, which is shorter than a full blown rexmt timeout. (yes, this violates the spec, but its better than sitting around forever) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 20:16:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from daemon.best.ca (cr262311-a.lngly1.bc.wave.home.com [24.113.173.186]) by hub.freebsd.org (Postfix) with ESMTP id 54D5237BFB7 for ; Mon, 24 Apr 2000 20:16:37 -0700 (PDT) (envelope-from rfurda@best.ca) Received: from winblowz (winblowz [10.254.254.2]) by daemon.best.ca (Postfix) with ESMTP id 10360D72E1; Mon, 24 Apr 2000 18:07:09 -0700 (PDT) Message-Id: <4.2.0.58.20000424175005.0095a590@best.ca> X-Sender: riso@best.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 24 Apr 2000 18:06:58 -0700 To: Ryan Thompson From: Richard Furda Subject: Re: Max T1. Throughput? Cc: freebsd-net@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_60627404==_.ALT" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --=====================_60627404==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, At 06:06 PM 4/24/00 -0600, you wrote: >There seems to be some confusion around our region on what the maximum >throughput of a T1 is. A T1 digital stream consists of 24 64kbps multiplexed time slots which come to a total of 1.536mbps, extra 8kbps is for framing. Thus, possible maximum throughput of a T1'd be: 192Kbytes/sec. >(Actually, we are on a 1.544Mbps leased SDSL line >from a local ISP. The package was sold to us as a burstable T1). A 'burstable' T1 IMHO implies that it can burst up to 1.544 but not steady 1.544mbps. >Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong >way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? Symetric means, both up/down, or 'both ways' if you will. Cable modem ISPs usually provide asymmetric access, thus high download rate, slow upload rate. Rich --- Richard Furda PGP public key: http://www.best.ca/rfurda.pkr --=====================_60627404==_.ALT Content-Type: text/html; charset="us-ascii"
        Hello,

At 06:06 PM 4/24/00 -0600, you wrote:
There seems to be some confusion around our region on what the maximum
throughput of a T1 is. 

A T1 digital stream consists of 24 64kbps multiplexed time slots which come
to a total of 1.536mbps, extra 8kbps is for framing. Thus, possible maximum
throughput of a T1'd be: 192Kbytes/sec.

(Actually, we are on a 1.544Mbps leased SDSL line
from a local ISP.  The package was sold to us as a burstable T1).

A 'burstable' T1 IMHO implies that it can burst up to 1.544 but
not steady 1.544mbps.

Is SDSL the key, here?  Perhaps I took "Synchronous" in the wrong
way.  Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2?

Symetric means, both up/down, or 'both ways' if you will. Cable
modem ISPs usually provide asymmetric access, thus high download
rate, slow upload rate.

        Rich




---
Richard Furda           
PGP public key:    http://www.best.ca/rfurda.pkr --=====================_60627404==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 22: 1:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id 76AB537BC49 for ; Mon, 24 Apr 2000 22:01:36 -0700 (PDT) (envelope-from marisombra@mindspring.com) Received: from gaea.mindspring.com (user-2ive4q9.dialup.mindspring.com [165.247.19.73]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA32753; Tue, 25 Apr 2000 01:01:22 -0400 (EDT) Message-Id: <4.3.2.20000425005848.045f38e0@pop.mindspring.com> X-Sender: marisombra@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 25 Apr 2000 01:01:30 -0400 To: "Jerry Bell" , "Ryan Thompson" , From: "Daniel J. Zaccariello" Subject: Re: Max T1. Throughput? In-Reply-To: <001f01bfae56$9a79d780$f7bbb1d0@netrex.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greets, In SDSL, the synchronous doesn't mean full duplex. You have a line speed of 1.5Mbps up and down, but not 1.5Mbps up and down at the same time. For this you'd need something like HDSL (there may be another *dsl that can do this). At 04/24/2000 09:35 PM Monday, Jerry Bell wrote: >SDSL does mean that you should get the line speed (1.5Mbps in this case) in >both directions. Typically, there is a bit more protocol overhead with >sdsl, since it is usually run via atm. >Good luck, > >Jerry > >----- Original Message ----- >From: Ryan Thompson >To: >Sent: Monday, April 24, 2000 8:06 PM >Subject: Max T1. Throughput? > > > > Sorry for the slightly off-topic post, here. Couldn't think of a better > > forum to inquire in, though. > > > > There seems to be some confusion around our region on what the maximum > > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > > from a local ISP. The package was sold to us as a burstable T1). > > > > My preliminary tests seem to show a segregation between up and > > down... Each maxing out at about 96KB/sec when the other is practically > > idle. Not the near-198KB/sec that I think I should be getting. > > > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? > > > > Thanks, > > - Ryan > > > > > > -- > > Ryan Thompson > > Systems Administrator, Accounts > > Phone: +1 (306) 664-1161 > > > > SaskNow Technologies http://www.sasknow.com > > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 24 23: 4: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 6E84C37B85C; Mon, 24 Apr 2000 23:04:05 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id IAA18486; Tue, 25 Apr 2000 08:04:49 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004250604.IAA18486@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004250214.TAA30215@bubba.whistle.com> from Archie Cobbs at "Apr 24, 2000 07:14:44 pm" To: Archie Cobbs Date: Tue, 25 Apr 2000 08:04:49 +0200 (CEST) Cc: Julian Elischer , pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > OK, here's a patch ready for review & test.. this patch does one i generally like the patch. As you notice: > Most of these patches are straightforward, however a few are > more tricky.. in particular: > > - pci/if_de.c (what does TULIP_HASHONLY mean exactly?) > - dev/ed/if_ed.c (contained a BRIDGE optimization) > - dev/ie/if_ie.c (contained a BPF optimization) this is why i suggested having some way to preserve the old ether_input() behaviour, either by definining a new function which does the bpf/bridge stuff and then calls ether_input(), or maybe by using some special argument to ether_input() to tell that we want the 'new' behaviour (one which immediately comes to mind: use eh == NULL to mean that we want the 'new' behaviour, since the ethernet header for bridging/bpf to work needs to be in the mbuf.) cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 0:25:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasi.com (sasi.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 39E9D37BCD7 for ; Tue, 25 Apr 2000 00:25:37 -0700 (PDT) (envelope-from gbnaidu@sasi.com) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id MAA26599 for ; Tue, 25 Apr 2000 12:55:19 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by sasi.com; Tue, 25 Apr 2000 12:55:17 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id NAA26539 for ; Tue, 25 Apr 2000 13:06:03 +0530 (IST) Date: Tue, 25 Apr 2000 13:06:03 +0530 (IST) From: "G.B.Naidu" To: freebsd-net@FreeBSD.ORG Subject: Kernel debugging... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I would like to know how to do a kernel debugging. Though I am not entirely new but am not confident about it. So some body help me to find out some pointers about this. I am going through the handbook. But still some insights will be appreciated. I didn't find kgdb command on my machine. Do I need to get it separately from net? I am running FreeBSD 3.1 version. thanks --gb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 0:54:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from daemon.norlight.net (daemon.norlight.net [207.170.1.4]) by hub.freebsd.org (Postfix) with ESMTP id DBAA937B92A for ; Tue, 25 Apr 2000 00:54:10 -0700 (PDT) (envelope-from r.hyunseog@ieee.org) Received: from ieee.org (dsl-64-34-46-105.telocity.com [64.34.46.105]) by daemon.norlight.net (8.9.3/8.9.3) with ESMTP id CAA08822; Tue, 25 Apr 2000 02:53:48 -0500 (CDT) (envelope-from r.hyunseog@ieee.org) Message-ID: <39054FA3.B947CBD6@ieee.org> Date: Tue, 25 Apr 2000 02:56:19 -0500 From: HyunSeog Ryu X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en,ko MIME-Version: 1.0 To: "Daniel J. Zaccariello" Cc: Jerry Bell , Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? References: <4.3.2.20000425005848.045f38e0@pop.mindspring.com> Content-Type: multipart/mixed; boundary="------------0D8085963DA78D092440A3DA" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------0D8085963DA78D092440A3DA Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Hmmm.... Isn't it that SDSL is one pair version of HDSL? ;> HDSL use two pairs for transmission. Am I wrong? ;> Hyun "Daniel J. Zaccariello" wrote: > > Greets, > > In SDSL, the synchronous doesn't mean full duplex. You have a line speed > of 1.5Mbps up and down, but not 1.5Mbps up and down at the same time. For > this you'd need something like HDSL (there may be another *dsl that can do > this). > > At 04/24/2000 09:35 PM Monday, Jerry Bell wrote: > >SDSL does mean that you should get the line speed (1.5Mbps in this case) in > >both directions. Typically, there is a bit more protocol overhead with > >sdsl, since it is usually run via atm. > > > > >Good luck, > > > >Jerry > > > >----- Original Message ----- > >From: Ryan Thompson > >To: > >Sent: Monday, April 24, 2000 8:06 PM > >Subject: Max T1. Throughput? > > > > > > > Sorry for the slightly off-topic post, here. Couldn't think of a better > > > forum to inquire in, though. > > > > > > There seems to be some confusion around our region on what the maximum > > > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > > > from a local ISP. The package was sold to us as a burstable T1). > > > > > > My preliminary tests seem to show a segregation between up and > > > down... Each maxing out at about 96KB/sec when the other is practically > > > idle. Not the near-198KB/sec that I think I should be getting. > > > > > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > > > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? > > > > > > Thanks, > > > - Ryan > > > > > > > > > -- > > > Ryan Thompson > > > Systems Administrator, Accounts > > > Phone: +1 (306) 664-1161 > > > > > > SaskNow Technologies http://www.sasknow.com > > > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --------------0D8085963DA78D092440A3DA Content-Type: text/x-vcard; charset=EUC-KR; name="r.hyunseog.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for HyunSeog Ryu Content-Disposition: attachment; filename="r.hyunseog.vcf" begin:vcard n:Ryu;HyunSeog x-mozilla-html:FALSE url:http://home.earthlink.net/~moonhunt adr:;;;;;; version:2.1 email;internet:r.hyunseog@ieee.org note;quoted-printable:HR201-ARIN=0D=0AHR1-APNIC=0D=0AHR201=0D=0A x-mozilla-cpt:;13376 fn:HyunSeog Ryu end:vcard --------------0D8085963DA78D092440A3DA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 1:59: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id 3B61737BCD7; Tue, 25 Apr 2000 01:59:01 -0700 (PDT) (envelope-from os@alkar.net) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id LWR10742; Tue, 25 Apr 2000 11:58:58 +0300 (envelope-from os@alkar.net) From: os@alkar.net To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Re: fxp0: device timed out - Possible netkill? Date: 25 Apr 2000 08:39:15 GMT Organization: Alkar-Teleport News server Message-ID: <8e3ljj$28n7$1@pandora.alkar.net> References: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/3.4-RELEASE (i386)) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 27 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, 4400 use onboard Intel Pro/100+ Server Adapter. FreeBSD don't support it unfortunattely. Oleg Shpak. P.S. I will be happy if I am wrong in this issue :) In lucky.freebsd.isp Ben Vaughn wrote: > Hi all, > We recently got a Dell Poweredge 4400 with an onboard Intel Pro 100/b. The > machine acts as a shell server, so it catches DoS attacks often. However, > since we have been putting this box up, we will get "fxp0: device timed out" > many times on the console. The box freezes up completely, and does not even > reboot. MAXUSERS is 1024. I've never had this problem on a previous dell > machine with an fxp card. Does anybody have any idea? > Thanks in advance, > Ben Vaughn > Prophet Network Systems > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" 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 Apr 25 4:59:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from www.bellnetworks.net (www.bellnetworks.net [208.177.187.234]) by hub.freebsd.org (Postfix) with ESMTP id D850B37B6B3 for ; Tue, 25 Apr 2000 04:59:54 -0700 (PDT) (envelope-from jerry@bellnetworks.net) Received: from itbell (dhcp-247.bellnetworks.net [208.177.187.247]) by www.bellnetworks.net (8.9.3/8.9.3) with SMTP id HAA73165; Tue, 25 Apr 2000 07:59:18 -0400 (EDT) (envelope-from jerry@bellnetworks.net) Message-ID: <003f01bfaead$c04e10a0$f7bbb1d0@netrex.com> From: "Jerry Bell" To: "HyunSeog Ryu" , "Daniel J. Zaccariello" Cc: "Ryan Thompson" , References: <4.3.2.20000425005848.045f38e0@pop.mindspring.com> <39054FA3.B947CBD6@ieee.org> Subject: Re: Max T1. Throughput? Date: Tue, 25 Apr 2000 07:59:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="EUC-KR" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You are correct. SDSL is the single pair form of HDSL. I just did a few tests on my 384k sdsl, ftp'ing a large file in and out simultaneously and was getting ~48k bytes/s in each direction, at the same time. Jerry ----- Original Message ----- From: HyunSeog Ryu To: Daniel J. Zaccariello Cc: Jerry Bell ; Ryan Thompson ; Sent: Tuesday, April 25, 2000 3:56 AM Subject: Re: Max T1. Throughput? > > Hmmm.... > Isn't it that SDSL is one pair version of HDSL? ;> > HDSL use two pairs for transmission. > Am I wrong? ;> > > Hyun > > > "Daniel J. Zaccariello" wrote: > > > > Greets, > > > > In SDSL, the synchronous doesn't mean full duplex. You have a line speed > > of 1.5Mbps up and down, but not 1.5Mbps up and down at the same time. For > > this you'd need something like HDSL (there may be another *dsl that can do > > this). > > > > At 04/24/2000 09:35 PM Monday, Jerry Bell wrote: > > >SDSL does mean that you should get the line speed (1.5Mbps in this case) in > > >both directions. Typically, there is a bit more protocol overhead with > > >sdsl, since it is usually run via atm. > > > > > > > > >Good luck, > > > > > >Jerry > > > > > >----- Original Message ----- > > >From: Ryan Thompson > > >To: > > >Sent: Monday, April 24, 2000 8:06 PM > > >Subject: Max T1. Throughput? > > > > > > > > > > Sorry for the slightly off-topic post, here. Couldn't think of a better > > > > forum to inquire in, though. > > > > > > > > There seems to be some confusion around our region on what the maximum > > > > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > > > > from a local ISP. The package was sold to us as a burstable T1). > > > > > > > > My preliminary tests seem to show a segregation between up and > > > > down... Each maxing out at about 96KB/sec when the other is practically > > > > idle. Not the near-198KB/sec that I think I should be getting. > > > > > > > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > > > > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? > > > > > > > > Thanks, > > > > - Ryan > > > > > > > > > > > > -- > > > > Ryan Thompson > > > > Systems Administrator, Accounts > > > > Phone: +1 (306) 664-1161 > > > > > > > > SaskNow Technologies http://www.sasknow.com > > > > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > > >with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 5:59:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id DFE7637B64D for ; Tue, 25 Apr 2000 05:59:33 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from sol.cs.binghamton.edu (sol.cs.binghamton.edu [128.226.123.100]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id IAA20883; Tue, 25 Apr 2000 08:59:09 -0400 (EDT) Date: Tue, 25 Apr 2000 08:59:00 -0400 (EDT) From: Zhihui Zhang To: "G.B.Naidu" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Kernel debugging... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Apr 2000, G.B.Naidu wrote: > > Hi, > > I would like to know how to do a kernel debugging. Though I am not > entirely new but am not confident about it. So some body help me to > find out some pointers about this. I am going through the handbook. But > still some insights will be appreciated. > > I didn't find kgdb command on my machine. Do I need to get it separately > from net? I am running FreeBSD 3.1 version. > The FreeBSD handbook should contain most of what you want. If there are still problems, search the mailing list archive. Both are online. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 7: 9:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from shell01.pns.net (shell01.pns.net [63.71.252.10]) by hub.freebsd.org (Postfix) with ESMTP id AD40E37B60A; Tue, 25 Apr 2000 07:09:26 -0700 (PDT) (envelope-from bvaughn@shell01.pns.net) Received: from localhost (bvaughn@localhost) by shell01.pns.net (8.9.3/8.9.3) with SMTP id JAA03462; Tue, 25 Apr 2000 09:08:23 -0500 (EST) (envelope-from bvaughn@shell01.pns.net) Date: Tue, 25 Apr 2000 09:08:23 -0500 (EST) From: Ben Vaughn To: os@alkar.net Cc: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: fxp0: device timed out - Possible netkill? In-Reply-To: <8e3ljj$28n7$1@pandora.alkar.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oleg, Well, the card works fine at all other times...The machine has now been up for 1 day. -biv On 25 Apr 2000 os@alkar.net wrote: > Hi, > > 4400 use onboard Intel Pro/100+ Server Adapter. > FreeBSD don't support it unfortunattely. > > Oleg Shpak. > > P.S. I will be happy if I am wrong in this issue :) > > In lucky.freebsd.isp Ben Vaughn wrote: > > Hi all, > > We recently got a Dell Poweredge 4400 with an onboard Intel Pro 100/b. The > > machine acts as a shell server, so it catches DoS attacks often. However, > > since we have been putting this box up, we will get "fxp0: device timed out" > > many times on the console. The box freezes up completely, and does not even > > reboot. MAXUSERS is 1024. I've never had this problem on a previous dell > > machine with an fxp card. Does anybody have any idea? > > > > Thanks in advance, > > Ben Vaughn > > Prophet Network Systems > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-isp" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" 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 Apr 25 7:22:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by hub.freebsd.org (Postfix) with ESMTP id 235E537BD0B for ; Tue, 25 Apr 2000 07:22:45 -0700 (PDT) (envelope-from shalunov@att.com) Received: from tuzik.lz.att.com ([135.25.200.84]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA21216; Tue, 25 Apr 2000 10:21:47 -0400 (EDT) Received: (from shalunov@localhost) by tuzik.lz.att.com (8.9.2/8.9.2) id KAA54917; Tue, 25 Apr 2000 10:20:48 -0400 (EDT) (envelope-from shalunov@att.com) Date: Tue, 25 Apr 2000 10:20:48 -0400 (EDT) Message-Id: <200004251420.KAA54917@tuzik.lz.att.com> From: stanislav shalunov To: louie@TransSys.COM Cc: net@FreeBSD.ORG In-reply-to: <200004250249.WAA54708@whizzo.transsys.com> (louie@TransSys.COM) Subject: Re: netkill - generic remote DoS attack (fwd) References: <200004250249.WAA54708@whizzo.transsys.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: "Louis A. Mamakos" > Assuming you've got a good round trip time estimation, the timeout > shouldn't need to take very long. Generally reducing timeouts (even when there's no attack) is bad. Also, reducing timeouts only linearly affects the amount of consumed memory and doesn't therefore solve the problem. Additionally, connection in FIN_WAIT_1 state may need dozens of round-trip times to time out. Since I fake RTT in netkill (artificially delaying second packet) there's not much space to lower the timeout. It should also be pointed out that TCP keepalive options are irrelevant: the retransmit timer gets started immediately, because there's outstanding data. Keepalives would never kick in, and aren't necessary. -- stanislav shalunov, WHPD, shalunov@att.com 732-576-3252 10:20AM up 190 days, 23:43, 6 users, load averages: 0.00, 0.00, 0.07 "I must have a prodigious quantity of mind; it takes me as much as a week sometimes to make it up." -- Mark Twain, "The Innocents Abroad" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 8:51: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 84DCB37BF28; Tue, 25 Apr 2000 08:51:04 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id KAA00674; Tue, 25 Apr 2000 10:59:26 -0500 (EST) (envelope-from csg) Date: Tue, 25 Apr 2000 10:59:26 -0500 From: "C. Stephen Gunn" To: Archie Cobbs Cc: Julian Elischer , pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000425105926.A518@waterspout.com> References: <3902A56B.167EB0E7@elischer.org> <200004250214.TAA30215@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004250214.TAA30215@bubba.whistle.com>; from archie@whistle.com on Mon, Apr 24, 2000 at 07:14:44PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 24, 2000 at 07:14:44PM -0700, Archie Cobbs wrote: > OK, here's a patch ready for review & test.. this patch does one > thing, which is move the calls to BPF and BRIDGE'ing out of each > Ethernet driver and into ether_input(). Why not also modify ether_input() to remove the Ethernet header when appropriate? Instead of the monkey business to add the Ethernet Header back on. There are a couple of places in ether_input() that do this already, and you're proposing another for passing the packet to bpf. I proposed this a few weeks ago, but never cleaned up my patch for submission. It would certainly prevent some of the kludges to deal with the Ethernet Header for things that want a peek at it, like VLANs. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 9:17:26 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id E27EA37BDF3; Tue, 25 Apr 2000 09:17:23 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id JAA32979; Tue, 25 Apr 2000 09:15:14 -0700 (PDT) From: Archie Cobbs Message-Id: <200004251615.JAA32979@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <20000425105926.A518@waterspout.com> from "C. Stephen Gunn" at "Apr 25, 2000 10:59:26 am" To: csg@waterspout.com (C. Stephen Gunn) Date: Tue, 25 Apr 2000 09:15:14 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), julian@elischer.org (Julian Elischer), pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org C. Stephen Gunn writes: > > OK, here's a patch ready for review & test.. this patch does one > > thing, which is move the calls to BPF and BRIDGE'ing out of each > > Ethernet driver and into ether_input(). > > Why not also modify ether_input() to remove the Ethernet header > when appropriate? Instead of the monkey business to add the Ethernet > Header back on. > > There are a couple of places in ether_input() that do this already, > and you're proposing another for passing the packet to bpf. > > I proposed this a few weeks ago, but never cleaned up my patch > for submission. > > It would certainly prevent some of the kludges to deal with the > Ethernet Header for things that want a peek at it, like VLANs. I started doing that, but there are some reasons not too.. 1. Less code changes => fewer new bugs 2. NFS requires that the IP packet be longword aligned (or something). If you start the mbuf with a 14-byte Ethernet header, then this is broken (?? is this still true ??) 3. Some code actually reads the header and the payload into different buffers. Putting them together, and then separating them again later would be slower than it is now. But the main reason was #1 - i.e., "one thing at a time" :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 9:36:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 99CCD37BDE6; Tue, 25 Apr 2000 09:36:35 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id SAA40157; Tue, 25 Apr 2000 18:32:59 +0200 (CEST) Message-Id: <200004251632.SAA40157@luxren2.boostworks.com> Date: Tue, 25 Apr 2000 18:33:07 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: csg@waterspout.com Cc: archie@whistle.com, julian@elischer.org, pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20000425105926.A518@waterspout.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 25 Apr, C. Stephen Gunn wrote: > On Mon, Apr 24, 2000 at 07:14:44PM -0700, Archie Cobbs wrote: > >> OK, here's a patch ready for review & test.. this patch does one >> thing, which is move the calls to BPF and BRIDGE'ing out of each >> Ethernet driver and into ether_input(). > > Why not also modify ether_input() to remove the Ethernet header > when appropriate? Instead of the monkey business to add the Ethernet > Header back on. > > There are a couple of places in ether_input() that do this already, > and you're proposing another for passing the packet to bpf. > > I proposed this a few weeks ago, but never cleaned up my patch > for submission. > > It would certainly prevent some of the kludges to deal with the > Ethernet Header for things that want a peek at it, like VLANs. > That's correct. the patch break the bridging due to the ether header ripping. It would be preferable (at least for speeding up bridging) to adjust the packet after all bridging/BPF stuff. RN. ItM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 9:53:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id A152E37BD42; Tue, 25 Apr 2000 09:53:27 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id SAA40276; Tue, 25 Apr 2000 18:52:15 +0200 (CEST) Message-Id: <200004251652.SAA40276@luxren2.boostworks.com> Date: Tue, 25 Apr 2000 18:52:24 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: archie@whistle.com Cc: csg@waterspout.com, julian@elischer.org, pavel@alum.mit.edu, nsayer@sftw.com, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200004251615.JAA32979@bubba.whistle.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 25 Apr, Archie Cobbs wrote: > C. Stephen Gunn writes: >> > OK, here's a patch ready for review & test.. this patch does one >> > thing, which is move the calls to BPF and BRIDGE'ing out of each >> > Ethernet driver and into ether_input(). >> >> Why not also modify ether_input() to remove the Ethernet header >> when appropriate? Instead of the monkey business to add the Ethernet >> Header back on. >> >> There are a couple of places in ether_input() that do this already, >> and you're proposing another for passing the packet to bpf. >> >> I proposed this a few weeks ago, but never cleaned up my patch >> for submission. >> >> It would certainly prevent some of the kludges to deal with the >> Ethernet Header for things that want a peek at it, like VLANs. > > I started doing that, but there are some reasons not too.. > > 1. Less code changes => fewer new bugs > > 2. NFS requires that the IP packet be longword aligned (or something). > If you start the mbuf with a 14-byte Ethernet header, then this > is broken (?? is this still true ??) > > 3. Some code actually reads the header and the payload into different > buffers. Putting them together, and then separating them again later > would be slower than it is now. > > But the main reason was #1 - i.e., "one thing at a time" :-) > This means that bridge_in() must receive the ether header as a parameter instead of extracting it. Also true for the forwarder part of the bridge code..... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 11:53:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from Gloria.CAM.ORG (Gloria.CAM.ORG [205.151.116.34]) by hub.freebsd.org (Postfix) with ESMTP id 8AB6A37B810 for ; Tue, 25 Apr 2000 11:53:17 -0700 (PDT) (envelope-from intmktg@CAM.ORG) Received: from localhost (intmktg@localhost) by Gloria.CAM.ORG (8.9.3/8.9.3) with ESMTP id OAA01432 for ; Tue, 25 Apr 2000 14:43:15 -0400 Date: Tue, 25 Apr 2000 14:43:15 -0400 (EDT) From: Marc Tardif To: freebsd-net@freebsd.org Subject: clustering and netbooting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am currently running 3 freebsd boxes sharing tasks for the same domain: 192.168.0.1 web.server.com web 192.168.0.2 sql.server.com sql 192.168.0.3 mail.server.com mail Problem is: how can I avoid having to build/install world and, to a lesser extent, the kernel for each machine (same hardware)? Solution 1: netbooting I have already encountered the problem of compiling the kernel in aout format instead of the default elf format on 3.x in order to be able to netboot the kernel. Once that will be settled, one of the three machines will act as the boot server for the other two. These machines will then mount only need the local hdd to mount swap and the following directories: /etc, /tmp, /var, /usr/local. Problem is: even though my objective is reached and only one build/install will be necessary, how much compromise in performance or potential problems can I expect from such a setup? Solution 2: mounting directories from fstab If possible, this option would mount the directories installed during "make installworld". This will prevent me from having to build/install world on each machine, but I'll still have to install a kernel for each machine. Problem is: how do I know which directories must be mounted in order to avoid having to build/install world on each machine? Also, can I expect any compromise in performance or potential problems for this kind of setup also? Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 14:31:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 38BB837BF1A for ; Tue, 25 Apr 2000 14:31:41 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id QAA02702; Tue, 25 Apr 2000 16:40:27 -0500 (EST) (envelope-from csg) Date: Tue, 25 Apr 2000 16:40:27 -0500 From: "C. Stephen Gunn" To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000425164027.A2553@waterspout.com> References: <20000425105926.A518@waterspout.com> <200004251615.JAA32979@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004251615.JAA32979@bubba.whistle.com>; from archie@whistle.com on Tue, Apr 25, 2000 at 09:15:14AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 25, 2000 at 09:15:14AM -0700, Archie Cobbs wrote: > 1. Less code changes => fewer new bugs > But the main reason was #1 - i.e., "one thing at a time" :-) I certainly understand this motivation. > 2. NFS requires that the IP packet be longword aligned (or something). > If you start the mbuf with a 14-byte Ethernet header, then this > is broken (?? is this still true ??) Perhaps I misunderstand something here, but the packet-header should be long-since-gone by the time it gets to NFS. If NFS needs the packet aligned, I'd assume that NFS takes care that monkey-business. It's the ethernet driver's responsibility to take care of the IP/NFS alignment issues. This should be taken care of long before we just trim the ether_header to pass the mbuf chain to ether_input(). Since this change still a call to m_adj(m,sizeof(struct ether_header)), the byte alignment shouldn't change by defering the call. After a check for ether_type(s) that still require the header for processing, and of course Bridging and BPF taps. > 3. Some code actually reads the header and the payload into > different buffers. Putting them together, and then separating > them again later would be slower than it is now. I did a quick sampling of Ethernet devices in the kernel, and I couldn't find any that didn't call m_adj() right before ether_input(). This was back in January, so I can't be sure now it was an exhaustive search. I originally asked the question of why the two (the header, and the payload) were passed to ether_input() seperately. The historical answer, from Garrett Wollman, was that it was needed for TRAILERS. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 17: 0:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from pogo.caustic.org (pogo.caustic.org [208.44.193.69]) by hub.freebsd.org (Postfix) with ESMTP id 9EB7337B5BE for ; Tue, 25 Apr 2000 17:00:36 -0700 (PDT) (envelope-from jan@caustic.org) Received: from localhost (jan@localhost) by pogo.caustic.org (8.10.0/ignatz) with ESMTP id e3Q03T439899; Tue, 25 Apr 2000 17:03:29 -0700 (PDT) Date: Tue, 25 Apr 2000 17:03:29 -0700 (PDT) From: "f.johan.beisser" To: Marc Tardif Cc: freebsd-net@FreeBSD.ORG Subject: Re: clustering and netbooting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org here's what worked for me, but it isn't really recommended.. i had machineA, the buildmaster, that had all the compiled stuff on it, and machineB, a laptop. MachineB would mount /usr/src and /usr/obj from machineA, then do a "make installworld" from the NFS mounts. the real trick is that machineA has to be able to read and write to and from the NFS mounts. the reasons for not doing this are pretty obvious, ranging from security (NFS is not the most secure protocol), to relativly high overhead of doing this over NFS. i've seen (it's in the archives, somewhere) something about using rsynch over ssh to duplicate everything over the machines, and that it'd match things by md5 checksum. as with anything in unix, there's many ways to solve this one problem. On Tue, 25 Apr 2000, Marc Tardif wrote: > I am currently running 3 freebsd boxes sharing tasks for the same domain: > 192.168.0.1 web.server.com web > 192.168.0.2 sql.server.com sql > 192.168.0.3 mail.server.com mail > > Problem is: how can I avoid having to build/install world and, to a lesser > extent, the kernel for each machine (same hardware)? > > Solution 1: netbooting > I have already encountered the problem of compiling the kernel in aout > format instead of the default elf format on 3.x in order to be able to > netboot the kernel. Once that will be settled, one of the three machines > will act as the boot server for the other two. These machines will then > mount only need the local hdd to mount swap and the following directories: > /etc, /tmp, /var, /usr/local. > > Problem is: even though my objective is reached and only one build/install > will be necessary, how much compromise in performance or potential > problems can I expect from such a setup? > > Solution 2: mounting directories from fstab > If possible, this option would mount the directories installed during > "make installworld". This will prevent me from having to build/install > world on each machine, but I'll still have to install a kernel for each > machine. > > Problem is: how do I know which directories must be mounted in order to > avoid having to build/install world on each machine? Also, can I expect > any compromise in performance or potential problems for this kind of setup > also? > > Marc > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > +-----/ f. johan beisser /------------------------------+ email: jan[at]caustic.org web: http://www.caustic.org/~jan "knowledge is power. power corrupts. study hard, be evil." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 17: 4:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D504A37B684 for ; Tue, 25 Apr 2000 17:04:41 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id RAA55104; Tue, 25 Apr 2000 17:03:57 -0700 (PDT) From: Archie Cobbs Message-Id: <200004260003.RAA55104@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <20000425164027.A2553@waterspout.com> from "C. Stephen Gunn" at "Apr 25, 2000 04:40:27 pm" To: csg@waterspout.com (C. Stephen Gunn) Date: Tue, 25 Apr 2000 17:03:57 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org C. Stephen Gunn writes: > > 2. NFS requires that the IP packet be longword aligned (or something). > > If you start the mbuf with a 14-byte Ethernet header, then this > > is broken (?? is this still true ??) > > Perhaps I misunderstand something here, but the packet-header should > be long-since-gone by the time it gets to NFS. If NFS needs the > packet aligned, I'd assume that NFS takes care that monkey-business. Well, the mbuf is aligned.. so if the IP header starts at mbuf + 14, then it's not aligned... and m_adj() won't help either.. but I don't know whether this is still valid though. However, a couple of drivers take pains to handle this. > > 3. Some code actually reads the header and the payload into > > different buffers. Putting them together, and then separating > > them again later would be slower than it is now. > > I did a quick sampling of Ethernet devices in the kernel, and I > couldn't find any that didn't call m_adj() right before ether_input(). > This was back in January, so I can't be sure now it was an exhaustive > search. See dev/ie/if_ie.c for an example.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 17:13: 8 2000 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 9245B37B534 for ; Tue, 25 Apr 2000 17:13:04 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA41341; Tue, 25 Apr 2000 20:12:57 -0400 (EDT) (envelope-from wollman) Date: Tue, 25 Apr 2000 20:12:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200004260012.UAA41341@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: csg@waterspout.com (C. Stephen Gunn), freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004260003.RAA55104@bubba.whistle.com> References: <20000425164027.A2553@waterspout.com> <200004260003.RAA55104@bubba.whistle.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Well, the mbuf is aligned.. so if the IP header starts at mbuf + > 14, then it's not aligned... and m_adj() won't help either.. but > I don't know whether this is still valid though. However, a couple > of drivers take pains to handle this. It's vitally important for fast networking -- not just for NFS -- to have the IP header naturally aligned (as appropriate for the CPU). Unfortunately, some NICs (like the DEC Tulip) have broken DMA engines that can't start a transfer on an unaligned boundary, so those drivers end up having to copy some amount of data. (On some processors, it's faster to copy the whole packet than to take the unaligned accesses.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 17:55: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 59CAD37B6F1; Tue, 25 Apr 2000 17:55:06 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id RAA55462; Tue, 25 Apr 2000 17:55:05 -0700 (PDT) From: Archie Cobbs Message-Id: <200004260055.RAA55462@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004251652.SAA40276@luxren2.boostworks.com> from Remy Nonnenmacher at "Apr 25, 2000 06:52:24 pm" To: luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org Date: Tue, 25 Apr 2000 17:55:05 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs writes: > OK, here's a patch ready for review & test.. this patch does one > thing, which is move the calls to BPF and BRIDGE'ing out of each > Ethernet driver and into ether_input(). Thanks for the input! The patch has been updated.. ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.2 Again, the only purpose of this patch is to move the BPF and BRIDGE taps out of the individual ethernet drivers and up into ether_input(). Changes to the patch include: - If the 'eh' parameter to ether_input() is NULL, then don't do any of the link-layer stuff. This allows the existing optimization in the if_ed.c driver to work the same. - Smaller change to the optimization in if_ed.c: simply NULL out 'eh' before calling ether_input() - Changed bridge_in() and bridge_dst_lookup() prototypes to take a struct ether_header * instead of an mbuf -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 19:11:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 1FEF437B77D; Tue, 25 Apr 2000 19:11:31 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id WAA61401; Tue, 25 Apr 2000 22:11:28 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200004260211.WAA61401@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Archie Cobbs Cc: luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Proposal for ethernet, bridging, netgraph References: <200004260055.RAA55462@bubba.whistle.com> In-reply-to: Your message of "Tue, 25 Apr 2000 17:55:05 PDT." <200004260055.RAA55462@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Apr 2000 22:11:28 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a thought while looking at this code - in if_ethersubr.c where the bpf process has been moved, the same idiom is repeated that was in the drivers: /* Check for a BPF tap */ if (ifp->if_bpf != NULL) { struct mbuf m0; /* OK because BPF treats the mbuf as read-only */ m0.m_next = m; m0.m_data = (char *)eh; m0.m_len = ETHER_HDR_LEN; bpf_mtap(ifp, &m0); } Now that mbufs are 256 bytes long, is this getting to be too much data to stick on the kernel stack? It seems like it's not a problem now, but this code is now going to be invoked deeper in the stack than before. If this code is running at splnet(), then it ought to be safe to just have a static mbuf laying about for this purpose, rather than allocating a local on the kernel stack. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 19:30:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 5549137B8DF; Tue, 25 Apr 2000 19:30:23 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id TAA56138; Tue, 25 Apr 2000 19:29:49 -0700 (PDT) From: Archie Cobbs Message-Id: <200004260229.TAA56138@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004260211.WAA61401@whizzo.transsys.com> from "Louis A. Mamakos" at "Apr 25, 2000 10:11:28 pm" To: louie@TransSys.COM (Louis A. Mamakos) Date: Tue, 25 Apr 2000 19:29:49 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Louis A. Mamakos writes: > Just a thought while looking at this code - in if_ethersubr.c where > the bpf process has been moved, the same idiom is repeated that > was in the drivers: > > /* Check for a BPF tap */ > if (ifp->if_bpf != NULL) { > struct mbuf m0; > > /* OK because BPF treats the mbuf as read-only */ > m0.m_next = m; > m0.m_data = (char *)eh; > m0.m_len = ETHER_HDR_LEN; > bpf_mtap(ifp, &m0); > } > > Now that mbufs are 256 bytes long, is this getting to be too much data > to stick on the kernel stack? It seems like it's not a problem now, but > this code is now going to be invoked deeper in the stack than before. > > If this code is running at splnet(), then it ought to be safe to just > have a static mbuf laying about for this purpose, rather than allocating > a local on the kernel stack. Good point.. we could just use a struct m_hdr.. and in any case it should be able to be a static variable.. we're at splnet(). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 19:31:23 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 6403B37B6BD; Tue, 25 Apr 2000 19:31:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from gothic.iinet.net.au (gothic.iinet.net.au [203.59.24.252]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id KAA17891; Wed, 26 Apr 2000 10:31:07 +0800 Received: from jules.elischer.org (reggae-11-129.nv.iinet.net.au [203.59.69.129]) by gothic.iinet.net.au (8.8.5/8.8.5) with SMTP id KAA27352; Wed, 26 Apr 2000 10:30:47 +0800 Message-ID: <39065497.237C228A@elischer.org> Date: Tue, 25 Apr 2000 19:29:46 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph References: <200004260055.RAA55462@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > Archie Cobbs writes: > > OK, here's a patch ready for review & test.. this patch does one > > thing, which is move the calls to BPF and BRIDGE'ing out of each > > Ethernet driver and into ether_input(). > > Thanks for the input! The patch has been updated.. > > ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.2 > > Again, the only purpose of this patch is to move the BPF and > BRIDGE taps out of the individual ethernet drivers and up into > ether_input(). > > Changes to the patch include: > > - If the 'eh' parameter to ether_input() is NULL, then don't > do any of the link-layer stuff. This allows the existing > optimization in the if_ed.c driver to work the same. > > - Smaller change to the optimization in if_ed.c: simply NULL > out 'eh' before calling ether_input() > > - Changed bridge_in() and bridge_dst_lookup() prototypes to > take a struct ether_header * instead of an mbuf > > -Archie > I liked the original patch, and most of this is of course the same. I am not sure I like this as the if_ed driver is now still calling the bridging code directly, which means that changes to the if_ethersubr.c cod eneed to be duplicated into that driver (if the writer knows to do this). Also, not having the 'eh' available is going to make it kinda hard to work out what the ether_type is, is it not? I cannot see how you avoid getting a "using uninitialised variable" warning. I feel uncomfortable about it anyway. > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 20:17:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id CD2FA37B6BD; Tue, 25 Apr 2000 20:17:31 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id UAA56331; Tue, 25 Apr 2000 20:16:57 -0700 (PDT) From: Archie Cobbs Message-Id: <200004260316.UAA56331@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <39065497.237C228A@elischer.org> from Julian Elischer at "Apr 25, 2000 07:29:46 pm" To: julian@elischer.org (Julian Elischer) Date: Tue, 25 Apr 2000 20:16:57 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer writes: > > - If the 'eh' parameter to ether_input() is NULL, then don't > > do any of the link-layer stuff. This allows the existing > > optimization in the if_ed.c driver to work the same. > > Also, not having the 'eh' available is going to make it kinda hard to > work out what the ether_type is, is it not? Oops.. uh, nevermind that idea.. :-) Luigi really wants to keep the optimization, so something is needed.. I'll go back to the previous version.. which has the small disadvantage that you may make two calls to bridge_in() when bridging.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 23: 2:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by hub.freebsd.org (Postfix) with ESMTP id E6A9837B765; Tue, 25 Apr 2000 23:02:49 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id BAA01401; Wed, 26 Apr 2000 01:11:34 -0500 (EST) (envelope-from csg) Date: Wed, 26 Apr 2000 01:11:34 -0500 From: "C. Stephen Gunn" To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG, luigi@FreeBSD.ORG, remy@boostworks.com, pavel@alum.mit.edu, nsayer@sftw.com, juliam@elischer.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000426011134.A768@waterspout.com> References: <20000425164027.A2553@waterspout.com> <200004260003.RAA55104@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004260003.RAA55104@bubba.whistle.com>; from archie@whistle.com on Tue, Apr 25, 2000 at 05:03:57PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 25, 2000 at 05:03:57PM -0700, Archie Cobbs wrote: > Well, the mbuf is aligned.. so if the IP header starts at mbuf + > 14, then it's not aligned... and m_adj() won't help either.. but > I don't know whether this is still valid though. However, a couple > of drivers take pains to handle this. You're Correct I discussed this with Bill Paul on IRC just to make sure that I wasn't insane. Several drivers go through horrible pain to make sure that the mbuf chain is 32-bit word aligned _after_ the removal of the Ethernet header. Like Garrett said, apparently some Ethernet hardware (the "better" cards mind you) can DMA to any address, others can only do it on 16-bit or 32-bit boundaries, hence the flaming hoops. Whatever the case, it should be fair to assume that an mbuf coming into ether_input() should be aligned correctly. A deferral of the m_adj() call shouldn't hurt anything, and cleans up a lot. > See dev/ie/if_ie.c for an example.. From reading the code, the driver doesn't have to operate this way. It just allocates an ether_header seperate from the mbuf chain. This data could be in the mbuf (with some alignment haggling) with very little drop in performance. I'd be happy to author/test/contrib these changes, but I need to get by hands on an if_ie card. I've put out some feelers to see if I can find/borrow one. Looks like the other culprits are: sys/dev/ie/if_ie.c sys/i386/isa/if_el.c sys/i386/isa/if_le.c sys/i386/isa/if_wl.c As far as I can tell, these are all old ISA cards. So the performace hit on a modern machine can't be that bad. Someone is taking a performance hit. I'd vote that it shouldn't be high-end configurations like Gigabit + VLANs, or anybody with a BPF open (think about DHCP). Don't get me wrong here, I'm not saying we should do anything to break support for older hardware, simply to optimize for the the average Ethernet hardware available today. > - If the 'eh' parameter to ether_input() is NULL, then don't > do any of the link-layer stuff. This allows the existing > optimization in the if_ed.c driver to work the same. As Julian pointed out, this won't work since we need the the ether_type inside ether_input(). This is certainly available if it hasn't been trimmed from the mbuf chain yet. (See above) Luigi -- Could you please remark about the optimizations in if_ed.c? I want to fully udnerstand your motivations. Is it simply due to having the ed device in promisc mode for bridging, and trying to optimize the "we don't need to forward this packet" case? - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 25 23:47:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 02B4537BCEE; Tue, 25 Apr 2000 23:47:32 -0700 (PDT) (envelope-from julian@elischer.org) Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id OAA13917; Wed, 26 Apr 2000 14:47:27 +0800 Received: from jules.elischer.org (reggae-09-116.nv.iinet.net.au [203.59.67.116]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with SMTP id OAA02734; Wed, 26 Apr 2000 14:47:15 +0800 Message-ID: <390690B8.4487EB71@elischer.org> Date: Tue, 25 Apr 2000 23:46:16 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: "Louis A. Mamakos" , luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph References: <200004260229.TAA56138@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs wrote: > > Louis A. Mamakos writes: > > > > Now that mbufs are 256 bytes long, is this getting to be too much data > > to stick on the kernel stack? It seems like it's not a problem now, but > > this code is now going to be invoked deeper in the stack than before. > > > > If this code is running at splnet(), then it ought to be safe to just > > have a static mbuf laying about for this purpose, rather than allocating > > a local on the kernel stack. > > Good point.. we could just use a struct m_hdr.. and in any case > it should be able to be a static variable.. we're at splnet(). i think it is bad style to do a static one.. we cannot know what will happen WRT SMP in the near future and we are setting ourselves up for future problems if we do that. I think we could get away with a m_hdr. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 1:45:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 0CFD437BE1F; Wed, 26 Apr 2000 01:45:30 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA23270; Wed, 26 Apr 2000 10:46:00 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004260846.KAA23270@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <20000426011134.A768@waterspout.com> from "C. Stephen Gunn" at "Apr 26, 2000 01:11:34 am" To: "C. Stephen Gunn" Date: Wed, 26 Apr 2000 10:46:00 +0200 (CEST) Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG, luigi@FreeBSD.ORG, remy@boostworks.com, pavel@alum.mit.edu, nsayer@sftw.com, juliam@elischer.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Luigi -- Could you please remark about the optimizations in > if_ed.c? I want to fully udnerstand your motivations. > > Is it simply due to having the ed device in promisc mode for > bridging, and trying to optimize the "we don't need to forward > this packet" case? the problem is, "ed" transfers the packet using programmed I/O, which is terribly slow on the ISA bus (twice wire speed i think) and painfully slow on the PCI bus as well (i dont remember the figures but i don't think we reach 10MB/s which means that you monopolise the PCI bus and the CPU for 10-20% of the time (irrespective of CPU speed, mind you!) _just_ to transfer the packets from one interface. Because there is some likelyhood that most packets need not to be bridged, the optimization first transfers the 14-byte header, then calls bridge_in(), and then transfers the rest of the packet only if really necessary. I think you can have a 10x improvement by doing this. One could say "who cares about the 'ed' cards" but i think this is wrong attitude being these cards so cheap, widespread, and often (e.g. here) the only cards left on the market with a BNC connector. Anyways, my point for retaining the old semantics for ether_input is so that one does need to fix all drivers at once (and some are problematic, e.g. i am not really sure how to make "de" work.) cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 2:14:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 8B60F37B8F9; Wed, 26 Apr 2000 02:14:16 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id CAA14088; Wed, 26 Apr 2000 02:11:06 -0700 (PDT) Message-Id: <200004260911.CAA14088@implode.root.com> To: "Louis A. Mamakos" Cc: Archie Cobbs , luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-reply-to: Your message of "Tue, 25 Apr 2000 22:11:28 EDT." <200004260211.WAA61401@whizzo.transsys.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 26 Apr 2000 02:11:06 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Just a thought while looking at this code - in if_ethersubr.c where >the bpf process has been moved, the same idiom is repeated that >was in the drivers: > > /* Check for a BPF tap */ > if (ifp->if_bpf != NULL) { > struct mbuf m0; > > /* OK because BPF treats the mbuf as read-only */ > m0.m_next = m; > m0.m_data = (char *)eh; > m0.m_len = ETHER_HDR_LEN; > bpf_mtap(ifp, &m0); > } > >Now that mbufs are 256 bytes long, is this getting to be too much data >to stick on the kernel stack? It seems like it's not a problem now, but >this code is now going to be invoked deeper in the stack than before. Pretty disgusting code. The mbuf isn't even initialized fully, leaving it in a state with a bunch of garbage pointers and other cruft. It's amazing that it even works. This must be something new that someone added - I don't recall seeing this before. This could/should be done using a struct bpf_pkthdr (or something) that has an mbuf pointer, a protocol header pointer, and header length. It could also be done by just adding a few more arguments to bpf_mtap(). Abusing an mbuf for this is wrong no matter how you slice it. >If this code is running at splnet(), then it ought to be safe to just >have a static mbuf laying about for this purpose, rather than allocating >a local on the kernel stack. Not a good thing for SMP. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 2:20:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 31BD637B56A for ; Wed, 26 Apr 2000 02:20:52 -0700 (PDT) (envelope-from core@kame.net) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA16079 for ; Wed, 26 Apr 2000 18:20:49 +0900 (JST) From: core@kame.net Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA21713 for ; Wed, 26 Apr 2000 18:20:49 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA19801 for ; Wed, 26 Apr 2000 18:20:47 +0900 (JST) Date: Wed, 26 Apr 2000 18:20:20 +0900 (JST) Message-Id: <20000426.182020.39156048.kazu@Mew.org> To: net@FreeBSD.ORG Subject: KAME stable 20000425 X-Mailer: Mew version 1.95b34 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As usual, KAME Project has released "stable" packages of IPv6/IPsec network code for the following BSD variants. --- netbsd NetBSD 1.4.2 http://www.netbsd.org/ freebsd2 FreeBSD 2.2.8-RELEASE http://www.freebsd.org/ bsdi3 BSDI BSD/OS http://www.bsdi.com/ kernel: BSD/OS 3.1 patchlevel 0 userland: BSD/OS 3.0 patchlevel 0 include: BSD/OS 3.0 patchlevel 0 + ISC BIND 4.9.7 freebsd3 FreeBSD 3.4-RELEASE http://www.freebsd.org/ openbsd OpenBSD 2.6 http://www.openbsd.org/ bsdi4 BSDI BSD/OS 4.1 patchlevel 0 http://www.bsdi.com/ --- Note: {Free,Net,Open}BSD-current have already merged the KAME source code, from *past* versions of KAME codebase. For differences between KAME kits and *BSD tree, please visit: http://www.kame.net/project-overview.html#release These packages have been tested by the TAHI team(http://www.tahi.org). They are free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ To know the changes from the previous stable package, please refer to the CHANGELOG/RELNOTES file. --KAME Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 3:20:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 30D4D37BC0D; Wed, 26 Apr 2000 03:20:30 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id MAA43188; Wed, 26 Apr 2000 12:19:33 +0200 (CEST) Message-Id: <200004261019.MAA43188@luxren2.boostworks.com> Date: Wed, 26 Apr 2000 12:19:42 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: archie@whistle.com Cc: luigi@FreeBSD.ORG, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG In-Reply-To: <200004260055.RAA55462@bubba.whistle.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 25 Apr, Archie Cobbs wrote: > Archie Cobbs writes: >> OK, here's a patch ready for review & test.. this patch does one >> thing, which is move the calls to BPF and BRIDGE'ing out of each >> Ethernet driver and into ether_input(). > > Thanks for the input! The patch has been updated.. > > ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.2 > >..... Well but the tricky thing is the bdg_forward() function. As it may be called from the if_xx codes and from ether_output(), the work implied will be probably a lot more important than delaying the ether header ripping after the bridging in ether_input(). What about: 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); ether_input()} 2) Call ether_input2() from any simple drivers doing the ripping. 3) keep all 'strange' or not-reviewed drivers using the standard ether_input() 4) carefully move all these drivers needing review to ether_input2() 5) merge ether_input2 into ether_input when there will be no more driver using the standard ether_input. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 7:31:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 188B937BDED; Wed, 26 Apr 2000 07:31:07 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id QAA24137; Wed, 26 Apr 2000 16:31:42 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004261431.QAA24137@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004261019.MAA43188@luxren2.boostworks.com> from Remy Nonnenmacher at "Apr 26, 2000 12:19:42 pm" To: remy@boostworks.com Date: Wed, 26 Apr 2000 16:31:41 +0200 (CEST) Cc: archie@whistle.com, luigi@FreeBSD.ORG, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What about: > > 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); > ether_input()} > 2) Call ether_input2() from any simple drivers doing the ripping. > 3) keep all 'strange' or not-reviewed drivers using the standard > ether_input() > 4) carefully move all these drivers needing review to ether_input2() > 5) merge ether_input2 into ether_input when there will be no more > driver using the standard ether_input. which is basically my proposal, with step 5 left to the guys in northern europe who do all the dirty works :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 9:21:17 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 2EA6E37C175; Wed, 26 Apr 2000 09:21:14 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id JAA58836; Wed, 26 Apr 2000 09:19:52 -0700 (PDT) From: Archie Cobbs Message-Id: <200004261619.JAA58836@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <390690B8.4487EB71@elischer.org> from Julian Elischer at "Apr 25, 2000 11:46:16 pm" To: julian@elischer.org (Julian Elischer) Date: Wed, 26 Apr 2000 09:19:52 -0700 (PDT) Cc: archie@whistle.com (Archie Cobbs), louie@TransSys.COM (Louis A. Mamakos), luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, new version of the patch.. ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.3 Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 11:46:26 2000 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 CF7BF37B9E2 for ; Wed, 26 Apr 2000 11:46:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA44415; Wed, 26 Apr 2000 14:46:18 -0400 (EDT) (envelope-from wollman) Date: Wed, 26 Apr 2000 14:46:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200004261846.OAA44415@khavrinen.lcs.mit.edu> To: dg@root.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004260911.CAA14088@implode.root.com> References: <200004260211.WAA61401@whizzo.transsys.com> <200004260911.CAA14088@implode.root.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Pretty disgusting code. The mbuf isn't even initialized fully, leaving it > in a state with a bunch of garbage pointers and other cruft. It's amazing > that it even works. This must be something new that someone added - I don't > recall seeing this before. It's been there next to forever. > This could/should be done using a struct bpf_pkthdr (or something) that > has an mbuf pointer, a protocol header pointer, and header length. It could > also be done by just adding a few more arguments to bpf_mtap(). Abusing > an mbuf for this is wrong no matter how you slice it. Far better to simply always put the link header into the front of the mbuf and be done with it (even if it does require some extra copying). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 11:47:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 1AA2937BBC3; Wed, 26 Apr 2000 11:47:09 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id LAA59380; Wed, 26 Apr 2000 11:46:01 -0700 (PDT) From: Archie Cobbs Message-Id: <200004261846.LAA59380@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004261431.QAA24137@info.iet.unipi.it> from Luigi Rizzo at "Apr 26, 2000 04:31:41 pm" To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Wed, 26 Apr 2000 11:46:01 -0700 (PDT) Cc: remy@boostworks.com, archie@whistle.com, luigi@FreeBSD.ORG, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo writes: > > 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); > > ether_input()} > > 2) Call ether_input2() from any simple drivers doing the ripping. > > 3) keep all 'strange' or not-reviewed drivers using the standard > > ether_input() > > 4) carefully move all these drivers needing review to ether_input2() > > 5) merge ether_input2 into ether_input when there will be no more > > driver using the standard ether_input. > > which is basically my proposal, with step 5 left to the guys > in northern europe who do all the dirty works :) Isn't this essentially what I've already done (steps 1-5)? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 12:29:37 2000 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 C110237B970; Wed, 26 Apr 2000 12:29:31 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA44573; Wed, 26 Apr 2000 15:28:52 -0400 (EDT) (envelope-from wollman) Date: Wed, 26 Apr 2000 15:28:52 -0400 (EDT) From: Garrett Wollman Message-Id: <200004261928.PAA44573@khavrinen.lcs.mit.edu> To: "C. Stephen Gunn" Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG, luigi@FreeBSD.ORG, remy@boostworks.com, pavel@alum.mit.edu, nsayer@sftw.com, juliam@elischer.org Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <20000426011134.A768@waterspout.com> References: <20000425164027.A2553@waterspout.com> <200004260003.RAA55104@bubba.whistle.com> <20000426011134.A768@waterspout.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Like Garrett said, apparently some Ethernet hardware (the "better" > cards mind you) can DMA to any address, others can only do it on > 16-bit or 32-bit boundaries, hence the flaming hoops. 16-bit is not a problem (unless some loser invents a link layer with odd-length headers). 32-bit is a problem, for the reasons which have already been developed. > From reading the code, the driver doesn't have to operate this way. > It just allocates an ether_header seperate from the mbuf chain. This > data could be in the mbuf (with some alignment haggling) with very > little drop in performance. Speaking as the perpetrator of that driver (although I will disclaim all knowledge if you ask me questions), I probably did that because I didn't know anything at the time about writing network interface drivers (or indeed UNIX device drivers at all). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 12:49:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 4AE3F37B72A; Wed, 26 Apr 2000 12:49:53 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id OAA01501; Wed, 26 Apr 2000 14:58:26 -0500 (EST) (envelope-from csg) Date: Wed, 26 Apr 2000 14:58:26 -0500 From: "C. Stephen Gunn" To: Archie Cobbs Cc: Julian Elischer , "Louis A. Mamakos" , luigi@FreeBSD.ORG, remy@boostworks.com, pavel@alum.mit.edu, nsayer@sftw.com, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000426145826.A1209@waterspout.com> References: <390690B8.4487EB71@elischer.org> <200004261619.JAA58836@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261619.JAA58836@bubba.whistle.com>; from archie@whistle.com on Wed, Apr 26, 2000 at 09:19:52AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Apr 26, 2000 at 09:19:52AM -0700, Archie Cobbs wrote: > OK, new version of the patch.. > > ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.3 I've got some "operational" questions on the new ether_input(). I promise not to mention trimming or not trimming the header in this message. (whoops!) I think the Bridge/BPF code should happen after we check the interface for IFF_UP, and before the NG_DIVERT action. I question the validity of calling bdg_forward() on packets that are received on an interface that isn't IFF_UP|IFF_RUNNING. For instance, when I "ifconfig down", I expect the interface to not show me any traffic whatsoever. I also think that the IFF_UP check should be modified to also check IFF_RUNNING like this: /* Discard packet if interface is not up */ if (ifp->if_flags & (IFF_UP|IFF_RUNNING) != (IFF_UP|IFF_RUNNING)) { m_freem(m); return; } I don't have a good feel on the interface statistics. Personally I expect to see the counters get incremented for _any_ packet received on an interface. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 13:22:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 45BFE37B72A; Wed, 26 Apr 2000 13:22:05 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id PAA01699; Wed, 26 Apr 2000 15:31:00 -0500 (EST) (envelope-from csg) Date: Wed, 26 Apr 2000 15:31:00 -0500 From: "C. Stephen Gunn" To: Remy Nonnenmacher Cc: archie@whistle.com, luigi@FreeBSD.ORG, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000426153100.A1623@waterspout.com> References: <200004260055.RAA55462@bubba.whistle.com> <200004261019.MAA43188@luxren2.boostworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261019.MAA43188@luxren2.boostworks.com>; from remy@boostworks.com on Wed, Apr 26, 2000 at 12:19:42PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Apr 26, 2000 at 12:19:42PM +0200, Remy Nonnenmacher wrote: > Well but the tricky thing is the bdg_forward() function. As it may be > called from the if_xx codes and from ether_output(), the work implied > will be probably a lot more important than delaying the ether header > ripping after the bridging in ether_input(). But bridging is a layer-2 operation. Shouldn't it happen with the layer-2 processing, not in the driver for the physical device? I don't think this is the direction FreeBSD should be headed: Hey! My IP Stack gets faster if I educate if_ti.c about the protocol-socket interface and have it do all the dirty work at splnet(). Now we get to maintain TCP/IP two places in the kernel. > 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); > ether_input()} > 2) Call ether_input2() from any simple drivers doing the ripping. > 3) keep all 'strange' or not-reviewed drivers using the standard > ether_input() > 4) carefully move all these drivers needing review to ether_input2() > 5) merge ether_input2 into ether_input when there will be no more > driver using the standard ether_input. Isn't that what Archie has been doing? Couldn't this entire migration take place _now_ as a patchkit before bringing in any new special-purpose functions to the kernel? - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 13:35:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id C2CA237B95C; Wed, 26 Apr 2000 13:35:19 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id WAA45549; Wed, 26 Apr 2000 22:34:21 +0200 (CEST) Message-Id: <200004262034.WAA45549@luxren2.boostworks.com> Date: Wed, 26 Apr 2000 22:34:31 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: archie@whistle.com Cc: luigi@info.iet.unipi.it, luigi@FreeBSD.ORG, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG In-Reply-To: <200004261846.LAA59380@bubba.whistle.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26 Apr, Archie Cobbs wrote: > Luigi Rizzo writes: >> > 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); >> > ether_input()} >> > 2) Call ether_input2() from any simple drivers doing the ripping. >> > 3) keep all 'strange' or not-reviewed drivers using the standard >> > ether_input() >> > 4) carefully move all these drivers needing review to ether_input2() >> > 5) merge ether_input2 into ether_input when there will be no more >> > driver using the standard ether_input. >> >> which is basically my proposal, with step 5 left to the guys >> in northern europe who do all the dirty works :) > > Isn't this essentially what I've already done (steps 1-5)? > > -Archie > Essentially...no. Remains the problem of the place for ether header ripping. We have two choices: 1) Let drivers call ether_input() as now and have hard time in the bpf/bridging code to reconstitute the parameters awaited. (bottom-up way, One big rewriting) 2) Modify all drivers to let ether_input() do the ripping and use the unmodified bridging code. (top-down way, many little modifications) With the simplification of the ether_input2() step, it would not be too difficult. Have a look at bdg_forward() and mind the modifications... Also, while we are at this level, it would be a good idea to coordinate with current BGL push-down/pull-up work under SMP. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 13:38:38 2000 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 C38D237B904 for ; Wed, 26 Apr 2000 13:38:33 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA44813; Wed, 26 Apr 2000 16:38:26 -0400 (EDT) (envelope-from wollman) Date: Wed, 26 Apr 2000 16:38:26 -0400 (EDT) From: Garrett Wollman Message-Id: <200004262038.QAA44813@khavrinen.lcs.mit.edu> To: "C. Stephen Gunn" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <20000426153100.A1623@waterspout.com> References: <200004260055.RAA55462@bubba.whistle.com> <200004261019.MAA43188@luxren2.boostworks.com> <20000426153100.A1623@waterspout.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > But bridging is a layer-2 operation. Shouldn't it happen with the > layer-2 processing, not in the driver for the physical device? To quote Dave Clark: # Layering can be a good way to design protocols, but is not necessarily # a good way to implement them, if you care about performance. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 14: 2: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id C0D2437BBC3; Wed, 26 Apr 2000 14:01:56 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id XAA45605; Wed, 26 Apr 2000 23:01:24 +0200 (CEST) Message-Id: <200004262101.XAA45605@luxren2.boostworks.com> Date: Wed, 26 Apr 2000 23:01:33 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: csg@waterspout.com Cc: archie@whistle.com, luigi@FreeBSD.ORG, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG In-Reply-To: <20000426153100.A1623@waterspout.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26 Apr, C. Stephen Gunn wrote: > On Wed, Apr 26, 2000 at 12:19:42PM +0200, Remy Nonnenmacher wrote: > >> Well but the tricky thing is the bdg_forward() function. As it may be >> called from the if_xx codes and from ether_output(), the work implied >> will be probably a lot more important than delaying the ether header >> ripping after the bridging in ether_input(). > > But bridging is a layer-2 operation. Shouldn't it happen with the > layer-2 processing, not in the driver for the physical device? Yes. That's why Archie initially proposed to rework this. > > I don't think this is the direction FreeBSD should be headed: > > Hey! My IP Stack gets faster if I educate if_ti.c about the > protocol-socket interface and have it do all the dirty work at > splnet(). Now we get to maintain TCP/IP two places in the kernel. > In the mean time, you must keep in mind some trends, like ether chips off-load IP checksums flying around, need to match sessions as soon as possible for filtering/forwarding, etc... never heard about 'active networks' ? >> 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); >> ether_input()} >> 2) Call ether_input2() from any simple drivers doing the ripping. >> 3) keep all 'strange' or not-reviewed drivers using the standard >> ether_input() >> 4) carefully move all these drivers needing review to ether_input2() >> 5) merge ether_input2 into ether_input when there will be no more >> driver using the standard ether_input. > > Isn't that what Archie has been doing? Couldn't this entire > migration take place _now_ as a patchkit before bringing in any > new special-purpose functions to the kernel? > Until the problem of where the ether header ripping takes place is solved, we can hardly move forward. Anyway, the whole rework process will however take place (and we will be soon be able to use bridging from vmware ;). RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 16:29:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 7538F37B8E1 for ; Wed, 26 Apr 2000 16:29:28 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA15823; Wed, 26 Apr 2000 16:26:19 -0700 (PDT) Message-Id: <200004262326.QAA15823@implode.root.com> To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-reply-to: Your message of "Wed, 26 Apr 2000 14:46:18 EDT." <200004261846.OAA44415@khavrinen.lcs.mit.edu> From: David Greenman Reply-To: dg@root.com Date: Wed, 26 Apr 2000 16:26:19 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> This could/should be done using a struct bpf_pkthdr (or something) that >> has an mbuf pointer, a protocol header pointer, and header length. It could >> also be done by just adding a few more arguments to bpf_mtap(). Abusing >> an mbuf for this is wrong no matter how you slice it. > >Far better to simply always put the link header into the front of the >mbuf and be done with it (even if it does require some extra copying). Except that BPF won't necessarily know the size of the link layer header, but maybe that doesn't matter since it should be implied with the type speced in the bpf_attach. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 19:46:50 2000 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 BED6437B671 for ; Wed, 26 Apr 2000 19:46:47 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id WAA45834; Wed, 26 Apr 2000 22:46:38 -0400 (EDT) (envelope-from wollman) Date: Wed, 26 Apr 2000 22:46:38 -0400 (EDT) From: Garrett Wollman Message-Id: <200004270246.WAA45834@khavrinen.lcs.mit.edu> To: dg@root.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004262326.QAA15823@implode.root.com> References: <200004261846.OAA44415@khavrinen.lcs.mit.edu> <200004262326.QAA15823@implode.root.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Except that BPF won't necessarily know the size of the link layer header, BPF has never needed to know the size of the link layer header. It's the BPF application's responsibility to determine the interface type and emit appropriate filter code to examine and skip over it, as necessary for the particular application. (Hint: look at how the match condition `ip' is implemented in libpcap.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Apr 26 19:49:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id E500937BB29 for ; Wed, 26 Apr 2000 19:49:22 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers (heathers [199.89.192.5]) by heathers.stdio.com (8.9.3/8.8.8) with ESMTP id WAA72382; Wed, 26 Apr 2000 22:49:22 -0400 (EDT) (envelope-from lile@stdio.com) Date: Wed, 26 Apr 2000 22:49:21 -0400 (EDT) From: Larry Lile To: freebsd-net@freebsd.org Cc: Archie Cobbs Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After reading along with this thread I thought I might point out a way for us to further reduce redundant code in the network stack. It would allow any driver token-ring, atm, ethernet, ... to use ether_input directly without having to either replicate the code or fake ethernet headers. So after discussing this with Archie he thought I should post it to -net. So here goes, please feel free to make suggestions or comments. Currently ethernet drivers call ether_input(ifp, eh, m) and the token-ring driver calls iso88025_input(ifp, th, m). The two functions are orthoganal. The real difference is how you arrive at ether_type. So ether_input & iso88025_input are basically a big switch that moves the packet into the appropriate stack. What has been suggested is moving the bpf & bridging code into ether_input. That is fine for ethernet drivers, but it does little or nothing for non-ethernet drivers. The only real reason that it can't be used for other devices is that it can't find the ether_type for non-ethernet frames. The llc gunk should be moved out of ether_input and into a seperate function that calls ether_input when neccesary. People have been going round and round about where to store the link-level (mac/dlc) header. Applications have generally made the broken assumption that the mac header starts 14 bytes before the data. This is true for ethernet but not everything :-( There is a field in the mbufs just for this, m->m_pkthdr.header. This is how I recover source-routing data for arp. All of the ethernet drivers set it to NULL. If all the drivers set m->m_pkthdr.header to point to the mac header then every layer would know where to find it and there would be no need to pass "eh" into ether_input. If m->m_pkthdr.header is set correctly then all of the upper layers automatically have access to the mac header, no matter what the interface type is or where the header physically resides. This could also be helpful for tcpdump, dhcp, arp, bridging... So what I was proposing is change ether_input(ifp, eh, m) to ether_input(struct *ifnet, u_short ether_type, struct mbuf *m). Anyone who needs to know how to interpret the mac header from this point on/up should be able do it using ifp->if_type.if_data.ifi_type. For instance ether_input only uses the mac header to keep track of the number of multicast packets and broadcasts. Then you hit the switch(ether_type) which goes into the upper layers. The llc code should be split out (and down). It would look like this: Remove Remove llc MAC header header. +------+ +-----------+ Route packets | oltr |--llc->| llc_input |\ based on ether_type +------+\ +-----------+ | +-------------+ [bridge] Remove \--non-llc---------+------>| ether_input | - ->[netgraph] MAC header | +-------------+ [vlan] +------+ | (ether_type) | ed |--------------------/ / | | \ \ +------+ / [arp][ip][ipv6][ipx][...] | fddi |----------------/ (may need llc?) +------+ / | atm |------------/ (may need llc?) +------+ By Removing the * header, I mean adjusting m_data, m_len, m_pkthdr.len, ... Not actually destroying them. Of course this is assuming the neccesary changes for the bridge code being moved in to ether_input. I don't see a need to add link headers, length, ... in the call to ether_input that is why ifi_type and m_pkthdr.* exist. Currently the network stack is way too ethernet-centric, but then I guess there is a lot of ethernet in the world :-) I will save my comments about ether_output and the arp code until later, but they should be modified in a similar fashion. -- Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 2:13: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 49A1C37B57C for ; Thu, 27 Apr 2000 02:12:57 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id LAA15780; Thu, 27 Apr 2000 11:12:42 +0200 (CEST) (envelope-from asmodai) Date: Thu, 27 Apr 2000 11:12:42 +0200 From: Jeroen Ruigrok van der Werven To: Garrett Wollman Cc: "C. Stephen Gunn" , freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000427111242.C15268@lucifer.bart.nl> References: <200004260055.RAA55462@bubba.whistle.com> <200004261019.MAA43188@luxren2.boostworks.com> <20000426153100.A1623@waterspout.com> <200004262038.QAA44813@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004262038.QAA44813@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Apr 26, 2000 at 04:38:26PM -0400 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000426 22:45], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: >< said: > >> But bridging is a layer-2 operation. Shouldn't it happen with the >> layer-2 processing, not in the driver for the physical device? > >To quote Dave Clark: > ># Layering can be a good way to design protocols, but is not necessarily ># a good way to implement them, if you care about performance. Correct, but there is also a difference between a more cleaned up and structured approach and the current `let's patch it' approach. I have already been discussing some things with C. Stephen about producing a bit of a smallish paper investigating the current stuff, what could be changed, what problems we currently have with the code, etc etc. Kind of like the VM restructuring, the newbus structuring. I am sure that I cannot do this completely on my own, and I think it would benefit everybody if we would concentrate on this piece of code for the coming time. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Answering the questions that no one asks... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 4:31:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster2.pipeline.ch (mailtoaster2.pipeline.ch [62.48.0.71]) by hub.freebsd.org (Postfix) with ESMTP id EF10F37B5B3 for ; Thu, 27 Apr 2000 04:31:33 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 71370 invoked from network); 27 Apr 2000 11:32:25 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster2.pipeline.ch (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 27 Apr 2000 11:32:25 -0000 Message-ID: <3908253F.98A0B55C@pipeline.ch> Date: Thu, 27 Apr 2000 13:32:15 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Larry Lile Cc: freebsd-net@freebsd.org, Archie Cobbs Subject: Re: Proposal for ethernet, bridging, netgraph References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Larry Lile wrote: > > After reading along with this thread I thought I might point > out a way for us to further reduce redundant code in the > network stack. It would allow any driver token-ring, atm, > ethernet, ... to use ether_input directly without having > to either replicate the code or fake ethernet headers. > So after discussing this with Archie he thought I should > post it to -net. So here goes, please feel free to make > suggestions or comments. > > Currently ethernet drivers call ether_input(ifp, eh, m) and the > token-ring driver calls iso88025_input(ifp, th, m). The two functions > are orthoganal. The real difference is how you arrive at ether_type. > So ether_input & iso88025_input are basically a big switch that > moves the packet into the appropriate stack. > > What has been suggested is moving the bpf & bridging code into > ether_input. That is fine for ethernet drivers, but it does > little or nothing for non-ethernet drivers. The only real reason > that it can't be used for other devices is that it can't find the > ether_type for non-ethernet frames. The llc gunk should be moved > out of ether_input and into a seperate function that calls > ether_input when neccesary. If this is becoming a general input packet handling routine then please don't call it ether_input() anymore. Maybe packet_input() is suitable name. > People have been going round and round about where to store > the link-level (mac/dlc) header. Applications have generally made the > broken assumption that the mac header starts 14 bytes before the data. > This is true for ethernet but not everything :-( There is a > field in the mbufs just for this, m->m_pkthdr.header. This is > how I recover source-routing data for arp. All of the ethernet > drivers set it to NULL. If all the drivers set m->m_pkthdr.header > to point to the mac header then every layer would know where to > find it and there would be no need to pass "eh" into ether_input. > > If m->m_pkthdr.header is set correctly then all of the upper layers > automatically have access to the mac header, no matter what the > interface type is or where the header physically resides. This could > also be helpful for tcpdump, dhcp, arp, bridging... If we are discussing such deep changes we IMHO we should look at the big picture and take also a replacement of the current (ethernet specific) ARP code with NetBSD's into consideration: http://www.daemonnews.org/199809/underhood.html I certainly would volunteer to port it from NetBSD to FreeBSD but that would be my first coding dive into the network stack. > So what I was proposing is change ether_input(ifp, eh, m) to > ether_input(struct *ifnet, u_short ether_type, struct mbuf *m). > Anyone who needs to know how to interpret the mac header from > this point on/up should be able do it using ifp->if_type.if_data.ifi_type. > For instance ether_input only uses the mac header to keep track of > the number of multicast packets and broadcasts. Then you hit the > switch(ether_type) which goes into the upper layers. The llc code > should be split out (and down). > > It would look like this: > > Remove Remove llc > MAC header header. > +------+ +-----------+ Route packets > | oltr |--llc->| llc_input |\ based on ether_type > +------+\ +-----------+ | +-------------+ [bridge] > Remove \--non-llc---------+------>| ether_input | - ->[netgraph] > MAC header | +-------------+ [vlan] > +------+ | (ether_type) > | ed |--------------------/ / | | \ \ > +------+ / [arp][ip][ipv6][ipx][...] > | fddi |----------------/ (may need llc?) > +------+ / > | atm |------------/ (may need llc?) > +------+ > > By Removing the * header, I mean adjusting m_data, m_len, > m_pkthdr.len, ... Not actually destroying them. > > Of course this is assuming the neccesary changes for the bridge > code being moved in to ether_input. I don't see a need to add > link headers, length, ... in the call to ether_input that is > why ifi_type and m_pkthdr.* exist. > > Currently the network stack is way too ethernet-centric, but > then I guess there is a lot of ethernet in the world :-) > > I will save my comments about ether_output and the arp code > until later, but they should be modified in a similar fashion. See my comments. -- Andre AO6-RIPE/AO137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 6: 8:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id EEB5B37B53F for ; Thu, 27 Apr 2000 06:08:38 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id UAA87738; Thu, 27 Apr 2000 20:02:17 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Thu, 27 Apr 2000 20:02:17 +0700 (NSS) From: Max Khon To: Andre Oppermann Cc: Larry Lile , freebsd-net@FreeBSD.org, Archie Cobbs Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <3908253F.98A0B55C@pipeline.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, there! On Thu, 27 Apr 2000, Andre Oppermann wrote: > If we are discussing such deep changes we IMHO we should look at the > big picture and take also a replacement of the current (ethernet > specific) ARP code with NetBSD's into consideration: > http://www.daemonnews.org/199809/underhood.html > > I certainly would volunteer to port it from NetBSD to FreeBSD but > that would be my first coding dive into the network stack. that would not be hard -- I've already done this once about a year ago /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 9:27:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from hawaii.rr.com (hnlmail3.hawaii.rr.com [24.25.227.37]) by hub.freebsd.org (Postfix) with ESMTP id AF2EB37BCC9 for ; Thu, 27 Apr 2000 09:27:14 -0700 (PDT) (envelope-from jjames@terranetsystems.com) Received: from ps ([24.94.89.182]) by hawaii.rr.com with Microsoft SMTPSVC(5.5.1877.447.44); Thu, 27 Apr 2000 06:27:11 -1000 Message-ID: <001601bfb065$d59d3b20$b6595e18@hawaii.rr.com> From: "Jeramey" To: Subject: WaveLAN to work with stable 4.0 Date: Thu, 27 Apr 2000 06:30:00 -1000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am having trouble getting the WaveLAN 2mbps PCMCIA card w/ISA bridge adapter to be seen at all by a newly installed 4.0 system. The kernel has the correct device entries by default and both the rc.conf and pccard.conf files have been edited according what I have found. However, using the "wicontrol" config utility will/cannot find a configured card on the "wi0" interface. How do I do the initial config for this card so the driver is working and the system sees it? Thanks. Jeramey James Terranet Systems Brookings, OR Honolulu, HI To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 10:40:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 9385337B94F; Thu, 27 Apr 2000 10:40:02 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id KAA66052; Thu, 27 Apr 2000 10:40:01 -0700 (PDT) From: Archie Cobbs Message-Id: <200004271740.KAA66052@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004262034.WAA45549@luxren2.boostworks.com> from Remy Nonnenmacher at "Apr 26, 2000 10:34:31 pm" To: committers@freebsd.org Date: Thu, 27 Apr 2000 10:40:01 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CC: to -committers I'm planning to check in this patch soon: ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.3 The goal of the patch is simply to move the BPF and BRIDGE taps on Ethernet frame input from the individual drivers up into ether_input(), while attempting to preserve any existing "avoid unnecessarily reading packets" optimizations (specifically in the if_ed.c and if_ie.c drivers). The result: 1140 lines removed 187 lines added This patch has been reviewed by freebsd-net already, but I'm trying to give a lot of warning because.. o I don't have all 47 types of Ethernet cards to test. In fact my -current machine only has one so I can't even test BRIDGE'ing. At least BPF still works :-) o It's not completely clear which drivers are shared with other versions of 'BSD -- if I've missed any, they will need some #ifdef __FreeBSD__ modifications. Thanks! -Archie P.S.: there are lots of other "cleanups" that could be done; please discuss these on freebsd-net (i.e., remove -committers). ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 11:15:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 75B6D37B813 for ; Thu, 27 Apr 2000 11:15:31 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id UAA49981; Thu, 27 Apr 2000 20:15:05 +0200 (CEST) Message-Id: <200004271815.UAA49981@luxren2.boostworks.com> Date: Thu, 27 Apr 2000 20:15:14 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: archie@whistle.com Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <200004271740.KAA66052@bubba.whistle.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 27 Apr, Archie Cobbs wrote: > CC: to -committers > > I'm planning to check in this patch soon: > > ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.3 > > The goal of the patch is simply to move the BPF and BRIDGE taps on > Ethernet frame input from the individual drivers up into ether_input(), > while attempting to preserve any existing "avoid unnecessarily > reading packets" optimizations (specifically in the if_ed.c and > if_ie.c drivers). > > The result: > > 1140 lines removed > 187 lines added > > This patch has been reviewed by freebsd-net already, but I'm trying > to give a lot of warning because.. > > o I don't have all 47 types of Ethernet cards to test. In fact > my -current machine only has one so I can't even test BRIDGE'ing. > At least BPF still works :-) > > o It's not completely clear which drivers are shared with other > versions of 'BSD -- if I've missed any, they will need some > #ifdef __FreeBSD__ modifications. > > Thanks! > -Archie > > P.S.: there are lots of other "cleanups" that could be done; > please discuss these on freebsd-net (i.e., remove -committers). > Archie, in case you've not got my previous message: this patch _breaks_ the bridging: someone (hi Luigi ?) will have really hard work getting it back on. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 12:32:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 2121B37B639 for ; Thu, 27 Apr 2000 12:32:36 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id MAA66897; Thu, 27 Apr 2000 12:31:24 -0700 (PDT) From: Archie Cobbs Message-Id: <200004271931.MAA66897@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004271815.UAA49981@luxren2.boostworks.com> from Remy Nonnenmacher at "Apr 27, 2000 08:15:14 pm" To: remy@boostworks.com Date: Thu, 27 Apr 2000 12:31:24 -0700 (PDT) Cc: luigi@info.iet.unipi.it, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher writes: > Archie, in case you've not got my previous message: this patch _breaks_ > the bridging: someone (hi Luigi ?) will have really hard work getting > it back on. I certainly don't want to break anything... You are sure you're using the lastest patch (#3)? Can you help track down the problem? Which driver are you using? Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 15:41:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 31C2B37B889 for ; Thu, 27 Apr 2000 15:41:52 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustidentd@obie.softweyr.com [204.68.178.33]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id QAA16200; Thu, 27 Apr 2000 16:41:35 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3908C23B.177C942D@softweyr.com> Date: Thu, 27 Apr 2000 16:42:03 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryan Thompson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ryan Thompson wrote: > > Sorry for the slightly off-topic post, here. Couldn't think of a better > forum to inquire in, though. > > There seems to be some confusion around our region on what the maximum > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > from a local ISP. The package was sold to us as a burstable T1). > > My preliminary tests seem to show a segregation between up and > down... Each maxing out at about 96KB/sec when the other is practically > idle. Not the near-198KB/sec that I think I should be getting. > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? SDSL is not "Synchronus", it is "Symmetrical", in other words you get the same bandwidth in both directions, as opposed to Assymmetrical DSL where (usually) the "download" bandwidth is greater than "upload." Most (all?) DSL providers quote the total throughput. If you buy 512K SDSL, you get 256K up and down. 512K ADSL is usually 384K downstream and 128K upstream. If you can get 768K bps down and 768K bps up simultaneously, you're getting exactly what you paid for, even if it is not what you wanted or expected. You should also note that DSL and T1 have nothing to do with each other. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 15:46:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id E980A37BCFE for ; Thu, 27 Apr 2000 15:46:30 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 76F331C4A; Thu, 27 Apr 2000 18:46:30 -0400 (EDT) Date: Thu, 27 Apr 2000 18:46:30 -0400 From: Bill Fumerola To: Wes Peters Cc: Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? Message-ID: <20000427184630.B40387@jade.chc-chimes.com> References: <3908C23B.177C942D@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3908C23B.177C942D@softweyr.com>; from wes@softweyr.com on Thu, Apr 27, 2000 at 04:42:03PM -0600 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 27, 2000 at 04:42:03PM -0600, Wes Peters wrote: > You should also note that DSL and T1 have nothing to do with each other. Ameritech recently delivered a DS-1 to a friend of mine in the form of DSL to his location and a device to give a ds-1 signal through the DSL. TELCO ----DSL---> MAGIC-DEVICE ---DS-1--> DS1 equipment The magic device was actually at his house. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 15:58: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.dbitech.bc.ca (i.caniserv.com [139.142.95.1]) by hub.freebsd.org (Postfix) with SMTP id 8333437BF88 for ; Thu, 27 Apr 2000 15:57:57 -0700 (PDT) (envelope-from darcy@ok-connect.com) Received: (qmail 20890 invoked from network); 27 Apr 2000 22:57:56 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253) by 139.142.95.8 with SMTP; 27 Apr 2000 22:57:56 -0000 Message-Id: <3.0.32.20000427160001.02819a80@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Apr 2000 16:00:02 +0100 To: Ryan Thompson , freebsd-net@FreeBSD.ORG From: Darcy Buskermolen Subject: Re: Max T1. Throughput? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We also have one of these magic boxes.. It converts a HDSL line to a PRI bundel (aka a T1 or DS1). At 06:46 PM 4/27/00 -0400, you wrote: >On Thu, Apr 27, 2000 at 04:42:03PM -0600, Wes Peters wrote: > >> You should also note that DSL and T1 have nothing to do with each other. > >Ameritech recently delivered a DS-1 to a friend of mine in the form of DSL >to his location and a device to give a ds-1 signal through the DSL. > >TELCO ----DSL---> MAGIC-DEVICE ---DS-1--> DS1 equipment > >The magic device was actually at his house. > >-- >Bill Fumerola - Network Architect >Computer Horizons Corp - CVM >e-mail: billf@chc-chimes.com / billf@FreeBSD.org >Office: 800-252-2421 x128 / Cell: 248-761-7272 > > > > > >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 Apr 27 16:34:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 4645E37BD8F for ; Thu, 27 Apr 2000 16:34:20 -0700 (PDT) (envelope-from jrs@enteract.com) Received: from shell-2.enteract.com (jrs@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id SAA87553; Thu, 27 Apr 2000 18:34:14 -0500 (CDT) (envelope-from jrs@enteract.com) Date: Thu, 27 Apr 2000 18:34:14 -0500 (CDT) From: John Sconiers To: Bill Fumerola Cc: Wes Peters , Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? In-Reply-To: <20000427184630.B40387@jade.chc-chimes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Magic device == dsl convertor > On Thu, Apr 27, 2000 at 04:42:03PM -0600, Wes Peters wrote: > > You should also note that DSL and T1 have nothing to do with each other. > Ameritech recently delivered a DS-1 to a friend of mine in the form of DSL > to his location and a device to give a ds-1 signal through the DSL. > TELCO ----DSL---> MAGIC-DEVICE ---DS-1--> DS1 equipment > The magic device was actually at his house. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 16:34:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from www.bellnetworks.net (www.bellnetworks.net [208.177.187.234]) by hub.freebsd.org (Postfix) with ESMTP id C0B2237BB5A for ; Thu, 27 Apr 2000 16:34:47 -0700 (PDT) (envelope-from jerry@bellnetworks.net) Received: from itbell (dhcp-247.bellnetworks.net [208.177.187.247]) by www.bellnetworks.net (8.9.3/8.9.3) with SMTP id TAA09673; Thu, 27 Apr 2000 19:34:00 -0400 (EDT) (envelope-from jerry@bellnetworks.net) Message-ID: <001f01bfb0a1$27690340$f7bbb1d0@netrex.com> From: "Jerry Bell" To: "Wes Peters" , "Ryan Thompson" Cc: References: <3908C23B.177C942D@softweyr.com> Subject: Re: Max T1. Throughput? Date: Thu, 27 Apr 2000 19:34:38 -0400 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.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yikes, who is advertising like this? All of the providers in this area (Detroit) sell a 512k SDSL connection as 512k up and down (simutlaneously). Jerry ----- Original Message ----- From: Wes Peters To: Ryan Thompson Cc: Sent: Thursday, April 27, 2000 6:42 PM Subject: Re: Max T1. Throughput? > Ryan Thompson wrote: > > > > Sorry for the slightly off-topic post, here. Couldn't think of a better > > forum to inquire in, though. > > > > There seems to be some confusion around our region on what the maximum > > throughput of a T1 is. (Actually, we are on a 1.544Mbps leased SDSL line > > from a local ISP. The package was sold to us as a burstable T1). > > > > My preliminary tests seem to show a segregation between up and > > down... Each maxing out at about 96KB/sec when the other is practically > > idle. Not the near-198KB/sec that I think I should be getting. > > > > Is SDSL the key, here? Perhaps I took "Synchronous" in the wrong > > way. Does "Synchronous" imply UP = DOWN = 1.54Mbps / 2? > > SDSL is not "Synchronus", it is "Symmetrical", in other words you get > the same bandwidth in both directions, as opposed to Assymmetrical DSL > where (usually) the "download" bandwidth is greater than "upload." > > Most (all?) DSL providers quote the total throughput. If you buy 512K > SDSL, you get 256K up and down. 512K ADSL is usually 384K downstream > and 128K upstream. If you can get 768K bps down and 768K bps up > simultaneously, you're getting exactly what you paid for, even if it > is not what you wanted or expected. > > You should also note that DSL and T1 have nothing to do with each other. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.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 Thu Apr 27 16:36:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster2.pipeline.ch (mailtoaster2.pipeline.ch [62.48.0.71]) by hub.freebsd.org (Postfix) with ESMTP id E31B337BD8F for ; Thu, 27 Apr 2000 16:36:29 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 71884 invoked from network); 27 Apr 2000 23:37:28 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster2.pipeline.ch (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 27 Apr 2000 23:37:28 -0000 Message-ID: <3908CF32.E665178E@pipeline.ch> Date: Fri, 28 Apr 2000 01:37:22 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darcy Buskermolen Cc: Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? References: <3.0.32.20000427160001.02819a80@mail.ok-connect.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darcy Buskermolen wrote: > > We also have one of these magic boxes.. > It converts a HDSL line to a PRI bundel (aka a T1 or DS1). This "magic box" is actually called a "CSU/DSU" and converts the serial data stream on the Telco side (through a DSL connection) into a sync serial interface (X.21,V.35 or so) on your side. -- Andre AO6-RIPE/AO137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 17:14:53 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id BB10137B97C for ; Thu, 27 Apr 2000 17:14:51 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 8F5ED1C4A; Thu, 27 Apr 2000 20:14:47 -0400 (EDT) Date: Thu, 27 Apr 2000 20:14:47 -0400 From: Bill Fumerola To: John Sconiers Cc: Wes Peters , Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? Message-ID: <20000427201447.C40387@jade.chc-chimes.com> References: <20000427184630.B40387@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jrs@enteract.com on Thu, Apr 27, 2000 at 06:34:14PM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 27, 2000 at 06:34:14PM -0500, John Sconiers wrote: > Magic device == dsl convertor I assume there is a more complicated name for the device then both of the above. I, however, don't know it, so I used magical device. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 17:15:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 9D06F37B7DC for ; Thu, 27 Apr 2000 17:15:52 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 49A3F1C4A; Thu, 27 Apr 2000 20:15:52 -0400 (EDT) Date: Thu, 27 Apr 2000 20:15:52 -0400 From: Bill Fumerola To: Andre Oppermann Cc: Darcy Buskermolen , Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? Message-ID: <20000427201552.D40387@jade.chc-chimes.com> References: <3.0.32.20000427160001.02819a80@mail.ok-connect.com> <3908CF32.E665178E@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3908CF32.E665178E@pipeline.ch>; from oppermann@pipeline.ch on Fri, Apr 28, 2000 at 01:37:22AM +0200 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Apr 28, 2000 at 01:37:22AM +0200, Andre Oppermann wrote: > > We also have one of these magic boxes.. > > It converts a HDSL line to a PRI bundel (aka a T1 or DS1). > > This "magic box" is actually called a "CSU/DSU" and converts the > serial data stream on the Telco side (through a DSL connection) into > a sync serial interface (X.21,V.35 or so) on your side. No. If it was a CSU/DSU, I would have called it that. It converts a DSL signal to a DS1 signal, which is _then_ handled by a DS1 CSU/DSU. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 20:19:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id C447E37B626 for ; Thu, 27 Apr 2000 20:19:25 -0700 (PDT) (envelope-from jrs@enteract.com) Received: from shell-2.enteract.com (jrs@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id WAA33208; Thu, 27 Apr 2000 22:19:20 -0500 (CDT) (envelope-from jrs@enteract.com) Date: Thu, 27 Apr 2000 22:19:20 -0500 (CDT) From: John Sconiers To: Bill Fumerola Cc: Wes Peters , Ryan Thompson , freebsd-net@FreeBSD.ORG Subject: Re: Max T1. Throughput? In-Reply-To: <20000427201447.C40387@jade.chc-chimes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Magic device == dsl convertor > I assume there is a more complicated name for the device then both of the > above. I, however, don't know it, so I used magical device. No. It's just called a "dsl convertor". It is not a CSU/DSU as some one stated before. JRS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Apr 27 20:29:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.dbitech.bc.ca (i.caniserv.com [139.142.95.1]) by hub.freebsd.org (Postfix) with SMTP id 5D10737B8A1 for ; Thu, 27 Apr 2000 20:29:48 -0700 (PDT) (envelope-from darcy@ok-connect.com) Received: (qmail 852 invoked from network); 28 Apr 2000 03:29:47 -0000 Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253) by 139.142.95.8 with SMTP; 28 Apr 2000 03:29:47 -0000 Message-Id: <3.0.32.20000427203152.02237890@mail.ok-connect.com> X-Sender: darcyb@mail.ok-connect.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Apr 2000 20:31:52 +0100 To: freebsd-net@FreeBSD.ORG From: Darcy Buskermolen Subject: Re: Max T1. Throughput? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is the URL to the unit I have hanging on the wall http://www.pairgain.com/products/t1%5Fe1/hru_412.asp it is not a CSU/DSU it is in fact a DSL converter. It is uses to provision T1 over HDSL at longer then regular Local Loop Lengths with out requiring repeaters. At 10:19 PM 4/27/00 -0500, John Sconiers wrote: >> > Magic device == dsl convertor >> I assume there is a more complicated name for the device then both of the >> above. I, however, don't know it, so I used magical device. > >No. It's just called a "dsl convertor". It is not a CSU/DSU as some one >stated before. > >JRS > > > >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 Apr 28 1: 2:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id BA8B937B83A for ; Fri, 28 Apr 2000 01:02:05 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id KAA27962; Fri, 28 Apr 2000 10:57:35 +0300 (EEST) (envelope-from ru) Date: Fri, 28 Apr 2000 10:57:35 +0300 From: Ruslan Ermilov To: Archie Cobbs Cc: julian@elischer.org, brian@Awfulhak.org, cmott@scientech.com, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander Subject: Re: Improved PPTP support for libalias(3) Message-ID: <20000428105735.A20760@relay.ucb.crimea.ua> Mail-Followup-To: Archie Cobbs , julian@elischer.org, brian@Awfulhak.org, cmott@scientech.com, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, Erik Salander References: <20000419115513.A42767@relay.ucb.crimea.ua> <200004191819.LAA27198@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <200004191819.LAA27198@bubba.whistle.com>; from Archie Cobbs on Wed, Apr 19, 2000 at 11:19:33AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Apr 19, 2000 at 11:19:33AM -0700, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > Sure there is: the Call ID. > > > > > > We are probably going to implement the remaining bit of this here > > > at Whistle in the next couple of weeks.. and will submit when done. > > > > > This patch should (hopefully) allow for concurrent PPTP tunnels from > > multiple local PACs to the same remote PNS to work behind NAT (rfc2637 > > terminology is being used). > > > > Could someone please test this patch, since I do not have enough test > > environment here? > > > > Note please, that you DO NOT need PacketAliasRedirectPptp() for this > > to work. Just running natd(8) with the default set of options should > > be enough. > > > > If someone is going to test this, please mail me the output of `natd -v' > > while trying PPTP to the same PNS from two or more local PACs. > > I'm not that familiar with the libalias code (erik@whistle.com is > more familiar), but am familiar with PPTP. Are you swizzling the > TCP stream (port 1723) at all? If not, then it's probably not going > to work .. or at least, not when two clients use the same Call ID. > > PPTP is like active mode FTP in that the Call ID (FTP -> port #) is > embedded in the TCP stream and must be swizzled. Unlike FTP however, > the TCP stream won't shrink or expand. > Well, I have some spare time now, and if you (at Whistle) did not start this work yet, I could probably do it. I am not that familiar with PPTP (read: have no practical experience) like you, and if you could give me an exact algorithm (in terms of RFC 2637) how/what to intercept/alias/dealias, I will implement it in libalias(3). Also, is the poptop/pptpclient pair from the ports collection a good enough test bed? As a first step, I would like to get rid of PacketAliasRedirectPptp() and replace it with more generic PacketAliasRedirectProto(). Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 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 Fri Apr 28 10: 2: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 6C8BE37BFB5; Fri, 28 Apr 2000 10:02:06 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id KAA72944; Fri, 28 Apr 2000 10:02:01 -0700 (PDT) From: Archie Cobbs Message-Id: <200004281702.KAA72944@bubba.whistle.com> Subject: Re: Improved PPTP support for libalias(3) In-Reply-To: <20000428105735.A20760@relay.ucb.crimea.ua> from Ruslan Ermilov at "Apr 28, 2000 10:57:35 am" To: ru@FreeBSD.ORG (Ruslan Ermilov) Date: Fri, 28 Apr 2000 10:02:01 -0700 (PDT) Cc: julian@elischer.org, brian@Awfulhak.org, cmott@scientech.com, ari@suutari.iki.fi, perhaps@yes.no, net@FreeBSD.ORG, erik@whistle.com (Erik Salander) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > Well, I have some spare time now, and if you (at Whistle) did not > start this work yet, I could probably do it. Erik has started working on it.. you two should probably communicate directly.. he can give you more specifics about where is is and what he's doing. I think he's on vacation today though, back on Monday. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 28 11:23:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A2AA037B912; Fri, 28 Apr 2000 11:23:20 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA49562; Fri, 28 Apr 2000 14:23:03 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 28 Apr 2000 14:23:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs Cc: committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004271740.KAA66052@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I haven't had a chance to review this code as I'm travelling, but the chances are it breaks bridge+ipfw as that code is rather fragile and sensitive to mbuf foo. I've been using a cleaned up version of the bridge+ipfw code that causes ipfw to only affect IP, and cleans up a lot of the behavior (although it doesn't fix the general DUMMYNET problem of prefixing mbufs with a DUMMYNET tag). It also doesn't fix the bug that only allowed one DUMMYNET pipe to be applied to bridged packets, as any pipe command in essence also acts as an accept (this should go into our release ERRATA, btw). I'm flying back to Massachusetts this evening, and may have a chance to put up diffs at that point or tomorrow, but I think coordinating these patches to go in at the same time would make sense. As such, please hold off on committing until I can either get you the patches and we can decide if that's a good idea or not :-) On Thu, 27 Apr 2000, Archie Cobbs wrote: > CC: to -committers > > I'm planning to check in this patch soon: > > ftp://ftp.whistle.com/pub/archie/misc/net.cleanup.patch.3 > > The goal of the patch is simply to move the BPF and BRIDGE taps on > Ethernet frame input from the individual drivers up into ether_input(), > while attempting to preserve any existing "avoid unnecessarily > reading packets" optimizations (specifically in the if_ed.c and > if_ie.c drivers). > > The result: > > 1140 lines removed > 187 lines added > > This patch has been reviewed by freebsd-net already, but I'm trying > to give a lot of warning because.. > > o I don't have all 47 types of Ethernet cards to test. In fact > my -current machine only has one so I can't even test BRIDGE'ing. > At least BPF still works :-) > > o It's not completely clear which drivers are shared with other > versions of 'BSD -- if I've missed any, they will need some > #ifdef __FreeBSD__ modifications. > > Thanks! > -Archie > > P.S.: there are lots of other "cleanups" that could be done; > please discuss these on freebsd-net (i.e., remove -committers). > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 28 11:48:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BBAEC37B824; Fri, 28 Apr 2000 11:48:50 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id OAA49713; Fri, 28 Apr 2000 14:48:47 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 28 Apr 2000 14:48:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs Cc: committers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Per my comment a little bit ago, please find patches that clean up the bridge/ipfw code a little at: http://www.watson.org/~robert/bridge.patch Because I'm travelling, I haven't had a chance to build or use the code in a few weeks, so don't guaranty it will apply cleanly. I also threw in by bridge0 interface support, which allows BPF to be used to monitor packets across the bridge rather than individual interfaces, which I've found useful for debugging. Caveats apply as a bridge can't accurately present the ordering and dropping of packets on various segments, but I've still found it useful. This restructures the bridge.c code to seperate out IP filtering code, as well as open up the possibility for hooks for other types of filtering. I also inserted a few comments pointing out possible limitations in the code, and emulated the existing ipfw/bridge bugpool. In particular, the following bugs still apply: o IPFW divert/fwd are not implemented These are both troubled due to the code paths associated with bridging vs. packet forwarding vs. local delivery, and the possibility of duplicate delivery. I'm beginning to suspect that the real solution here is the ability to construct arbitrary virtual topologies of interfaces in kernel, and then bind services to virtual interfaces and topologies. I.e., bind IP services to a virtual bridge interface instead of to individual interfaces, as that might be more intellectually pleasing from the perspective of avoiding duplicate delivery, as well as maintaining source interface (which is important for bridging so as to not send the packet back out the source port, which is bad). o IPFW DUMMYNET still implicit ACCEPT When using IPFW and DUMMYNET with BRIDGE, PIPE commands implicitely ACCEPT after the packet has suffered from traffic shaping. This is bad, should be in our ERRATA for various releases, and probably fixed. If fixed, it should be documented as such. BTW, on the DUMMYNET front, my feeling is that rather than using mbuf queueing routines for managing queues, it would be better/easier to use some sort of DUMMYNET queue structure that maintained meta-data, as opposed to the current insertion of DUMMYNET data at the front of the mbuf. The current behavior causes some unpleasentness as the bridge code can't easily determine what type of packet it is based on the front of the mbuf due to the header. Moving to providing ETHERTYPE as an argument to the bridge code would substantially fix this, but I think storing DUMMYNET data somewhere other than the mbuf makes sense for a variety of reasons. On an unrelated note, it would be a good idea if we did real spanning tree stuff--I have a copy of the appropriate IEEE spec, but haven't had a chance to review it for complexity/et al as yet due to travel. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 28 11:52:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C563637B56E; Fri, 28 Apr 2000 11:52:54 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id LAA75594; Fri, 28 Apr 2000 11:52:54 -0700 (PDT) From: Archie Cobbs Message-Id: <200004281852.LAA75594@bubba.whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: from Robert Watson at "Apr 28, 2000 02:23:02 pm" To: rwatson@freebsd.org (Robert Watson) Date: Fri, 28 Apr 2000 11:52:54 -0700 (PDT) Cc: committers@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > I haven't had a chance to review this code as I'm travelling, but the > chances are it breaks bridge+ipfw as that code is rather fragile and > sensitive to mbuf foo. I've been using a cleaned up version of the > bridge+ipfw code that causes ipfw to only affect IP, and cleans up a lot > of the behavior (although it doesn't fix the general DUMMYNET problem of > prefixing mbufs with a DUMMYNET tag). It also doesn't fix the bug that > only allowed one DUMMYNET pipe to be applied to bridged packets, as any > pipe command in essence also acts as an accept (this should go into our > release ERRATA, btw). > > I'm flying back to Massachusetts this evening, and may have a chance to > put up diffs at that point or tomorrow, but I think coordinating these > patches to go in at the same time would make sense. > > As such, please hold off on committing until I can either get you the > patches and we can decide if that's a good idea or not :-) OK.. why don't you just commit your patches and I'll wait for them. My patch breaks bridging anyway and I need to fix that... and that will probably be easier after your patch.. the code is not pretty :-) Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Apr 28 17:52:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id 9D8E737BA2A; Fri, 28 Apr 2000 17:52:12 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id CAA55633; Sat, 29 Apr 2000 02:51:51 +0200 (CEST) Message-Id: <200004290051.CAA55633@luxren2.boostworks.com> Date: Sat, 29 Apr 2000 02:52:01 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: rwatson@FreeBSD.ORG Cc: archie@whistle.com, committers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28 Apr, Robert Watson wrote: > > Per my comment a little bit ago, please find patches that clean up the > bridge/ipfw code a little at: > > http://www.watson.org/~robert/bridge.patch > > Because I'm travelling, I haven't had a chance to build or use the code in >.... Nice try Robert, but the topic of the discussion haven't reached the bridging code level. Next step. RN. ItM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 3: 9:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id BD28F37B76B; Sat, 29 Apr 2000 03:09:47 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA36762; Sat, 29 Apr 2000 12:10:38 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004291010.MAA36762@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: from Robert Watson at "Apr 28, 2000 02:48:46 pm" To: Robert Watson Date: Sat, 29 Apr 2000 12:10:38 +0200 (CEST) Cc: Archie Cobbs , committers@FreeBSD.org, freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert, thanks for your code. Will try to have a look at it during the weekend. I have/need a few comments if you dont mind: > a few weeks, so don't guaranty it will apply cleanly. I also threw in by > bridge0 interface support, which allows BPF to be used to monitor packets this is interesting. I wonder, though, if your 'bridge0' interface is one for the whole machine, or you have one for each cluster of interfaces as defined in net.link.ether.bridge_cfg > o IPFW divert/fwd are not implemented > > These are both troubled due to the code paths associated with bridging vs. > packet forwarding vs. local delivery, and the possibility of duplicate > delivery. I'm beginning to suspect that the real solution here is the because divert/fwd (at least as defined now) is a functionality above level 2, i think the easy (and maybe most correct) way to implement it is to interpret divert/fwd as a DENY for bridged packet, and when the same packet gets to ip_input() do the required action. The tricky part is that when a bridged packet matches a divert/fwd rule, its tag should be changed by bdg_forward() so that it is passed to ether_input() even if it does not have a local addr. > o IPFW DUMMYNET still implicit ACCEPT > > When using IPFW and DUMMYNET with BRIDGE, PIPE commands implicitely ACCEPT > after the packet has suffered from traffic shaping. This is bad, should > be in our ERRATA for various releases, and probably fixed. If fixed, it > should be documented as such. you are a committer, arent you :) > BTW, on the DUMMYNET front, my feeling is that rather than using mbuf > queueing routines for managing queues, it would be better/easier to use > some sort of DUMMYNET queue structure that maintained meta-data, as this was done to avoid changing the interface of ip_input() and ip_output(), which i really don't think we want to change. Yes we can replace the fake mbuf with some other data structure, but other than making the code a bit more readable i don;t think it fundamentally changes things. > On an unrelated note, it would be a good idea if we did real spanning tree > stuff--I have a copy of the appropriate IEEE spec, but haven't had a > chance to review it for complexity/et al as yet due to travel. the spanning tree is not much complex, it is just boring code to write and debug... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 7:25:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 56F7637B647; Sat, 29 Apr 2000 07:25:07 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id KAA01554; Sat, 29 Apr 2000 10:24:53 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 29 Apr 2000 10:24:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo Cc: Archie Cobbs , committers@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004291010.MAA36762@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 29 Apr 2000, Luigi Rizzo wrote: > Robert, thanks for your code. Will try to have a look at it during > the weekend. I have/need a few comments if you dont mind: Steve Gunn has also pointed out a couple of bugs which may or may not have been inheritted from the original code, with regards to the IP packet sanity checking section, and a missing m_pullup(). > > a few weeks, so don't guaranty it will apply cleanly. I also threw in by > > bridge0 interface support, which allows BPF to be used to monitor packets > > this is interesting. I wonder, though, if your 'bridge0' interface > is one for the whole machine, or you have one for each cluster > of interfaces as defined in net.link.ether.bridge_cfg You are correct -- I haven't had a chance to really understand the cluster behavior, but really we should be allocating one bridge interface per cluster. What I'd actually be interested is a more generalized approach, in which virtual networks are defined, and actually physical and logical resources are assigned to the virtual network. This would be particularly useful from the perspective of the jail code--right now IP addresses are assigned to jails, but imagine instead that each jail was assigned a virtual interface, on which it could perform all the normal activities (raw sockets, BPF, binding, etc) but limited by the scope of the resources assigned to the virtual interface from outside the jail. In this way, we could far more effectively and with greater flexibility define the network resources for a jail. To some extent, netgraph may already be able to offer us some of this functionality--I wonder if it would make sense to push both the jail code, and filtering capabilities, into netgraph nodes. I don't think netgraph is currently capable of expressing the ``you have only yay much of a packet, to get more ask for more,'' which would give you the same performance problem with the multiple edX case. > > o IPFW divert/fwd are not implemented > > > > These are both troubled due to the code paths associated with bridging vs. > > packet forwarding vs. local delivery, and the possibility of duplicate > > delivery. I'm beginning to suspect that the real solution here is the > > because divert/fwd (at least as defined now) is a functionality above > level 2, i think the easy (and maybe most correct) way to implement > it is to interpret divert/fwd as a DENY for bridged packet, and > when the same packet gets to ip_input() do the required action. > The tricky part is that when a bridged packet matches a divert/fwd > rule, its tag should be changed by bdg_forward() so that it is > passed to ether_input() even if it does not have a local addr. That was my conclusion also. However, part of the problem here is that unlike IP forwarding layer stuff, you don't ``know'' if the packet was intended to pass to a node on the other side or not, and as such if divert were used to perform a packet transformation (say, a proxy of some sort), that would fairly seriously break the semantic that both sides of the bridge see similar things, as well as making it unclear when the proxy should be applied without a priori knowledge. I.e., you could no longer just say, ``Proxy all TCP connections'' because it's not clear when a SYN packet is destined for two nodes on the same segment, or two nodes seperated by the bridge. > > o IPFW DUMMYNET still implicit ACCEPT > > > > When using IPFW and DUMMYNET with BRIDGE, PIPE commands implicitely ACCEPT > > after the packet has suffered from traffic shaping. This is bad, should > > be in our ERRATA for various releases, and probably fixed. If fixed, it > > should be documented as such. > > you are a committer, arent you :) I'm more interested in the, ``fix'' solution, and haven't tried to tackle it yet as I wasn't clear on the reasons for not implementing it. Were there specific problems doing so that I have not yet come across, or is it just a ``change the gotos appropriately'' kind of arrangement? I'm not familiar with the ERRATA process but will inquire. > > BTW, on the DUMMYNET front, my feeling is that rather than using mbuf > > queueing routines for managing queues, it would be better/easier to use > > some sort of DUMMYNET queue structure that maintained meta-data, as > > this was done to avoid changing the interface of ip_input() and > ip_output(), which i really don't think we want to change. > Yes we can replace the fake mbuf with some other data structure, > but other than making the code a bit more readable i don;t think > it fundamentally changes things. Yes -- it's not a big functional change, but I think it would sort out a few of the layering problems I experienced when cleaning up the bridge/ipfw code. I.e., when the packet pops out of a pipe, being able to determine it's an IP packet based on the ethernet type and pass it back into the ipfw code based on that knowledge. If the mbuf packet header pointer is set to the ethernet header (I suspect not) then that could also be used. > > On an unrelated note, it would be a good idea if we did real spanning tree > > stuff--I have a copy of the appropriate IEEE spec, but haven't had a > > chance to review it for complexity/et al as yet due to travel. > > the spanning tree is not much complex, it is just boring code to > write and debug... That was my impression. :-) Any thoughts on filtering of outgoing packets to bridged ethernet segments? It depends I suppose, conceptually, on whether you think of the bridged segment as a number of adjacent ethernet segments, each potentially with its own network configuration (IP, IPX, et al), or if you think of it as, in effect, one segment. I.e., your IP address would be a property of bridge0, built from dc0 and dc1. In the first case, you might expect bridge filtering to occur only on the copies of the packets bridged from the segment where it was sent out onto other segments. In the second case, you might expect outgoing packets to be filtered when heading to any segment. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 7:38:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B1AC137B5C0; Sat, 29 Apr 2000 07:38:08 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id KAA01679; Sat, 29 Apr 2000 10:38:02 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 29 Apr 2000 10:38:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Remy Nonnenmacher Cc: archie@whistle.com, committers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: <200004290051.CAA55633@luxren2.boostworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 29 Apr 2000, Remy Nonnenmacher wrote: > On 28 Apr, Robert Watson wrote: > > > > Per my comment a little bit ago, please find patches that clean up the > > bridge/ipfw code a little at: > > > > http://www.watson.org/~robert/bridge.patch > > > > Because I'm travelling, I haven't had a chance to build or use the code in > >.... > > Nice try Robert, but the topic of the discussion haven't reached the > bridging code level. Next step. On the contrary -- one of the fundamental problems we've been discussing here is that the layering needs sorting out -- physical layer, link layer, and above, are all mixed up. We're pushing the bridging and packet sniffing interaction further up the stack, and as such some interfaces are changing. As the current bridge code is transparent at the link layer, it makes sense to me that it would be cleaned at the same time. In fact, in order that we properly clean the physical/link layer code, we need to better understand and simplify the bridge code so that we can do the job right. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 10:51:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 231CD37B74D; Sat, 29 Apr 2000 10:51:25 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id TAA37925; Sat, 29 Apr 2000 19:52:15 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004291752.TAA37925@info.iet.unipi.it> Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: from Robert Watson at "Apr 29, 2000 10:24:52 am" To: Robert Watson Date: Sat, 29 Apr 2000 19:52:15 +0200 (CEST) Cc: Archie Cobbs , committers@FreeBSD.org, freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > this is interesting. I wonder, though, if your 'bridge0' interface > > is one for the whole machine, or you have one for each cluster > > of interfaces as defined in net.link.ether.bridge_cfg > > You are correct -- I haven't had a chance to really understand the cluster > behavior, but really we should be allocating one bridge interface per > cluster. you are pointing out a lot of interesting things but i believe they require a lot of effort to implement, and the usefulness might not be that general. > > > o IPFW divert/fwd are not implemented ... > intended to pass to a node on the other side or not, and as such if divert > were used to perform a packet transformation (say, a proxy of some sort), > that would fairly seriously break the semantic that both sides of the > bridge see similar things, as well as making it unclear when the proxy but when you implement a filtering bridge you are already breaking the above semantics, and i think 90% of the people using the bridging code under freebsd do so just because it can do filtering. > > > o IPFW DUMMYNET still implicit ACCEPT ... > > you are a committer, arent you :) > > I'm more interested in the, ``fix'' solution, and haven't tried to tackle well the fix should be trivial, just act according to net.inet.ip.fw.one_pass. The reason i forced it to ACCEPT was that this is by far the most common usage, and i did not have the time to check how it would work with cascades of pipes. So, it is probably just "change the gotos and test", but it is very low low priority task in my list... > > > BTW, on the DUMMYNET front, my feeling is that rather than using mbuf ... > > this was done to avoid changing the interface of ip_input() and > > ip_output(), which i really don't think we want to change. ... > Yes -- it's not a big functional change, but I think it would sort out a > few of the layering problems I experienced when cleaning up the > bridge/ipfw code. I.e., when the packet pops out of a pipe, being able to > determine it's an IP packet based on the ethernet type and pass it back there is already a field (pkt->dn_dir) in the fake mbuf which tells you if it came from ip_input, ip_output or bdg_forward. Check usage in ip_dummynet.c:transmit_event(). Do you need something more/different ? > Any thoughts on filtering of outgoing packets to bridged ethernet > segments? It depends I suppose, conceptually, on whether you think of the depending on the output interface you mean ? Implementation would be relatively straightforward, i.e. move the ipfw calls in the loop where you scan interfaces to find the one(s) where the pkt should be retransmitted. However: 1) it really only makes sense for multicast/broadcast traffic, as usually there is only one interface matching a packet for normal traffic; 2) i wonder how useful this is... cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 19:20:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (adam042-051.resnet.wisc.edu [146.151.42.51]) by hub.freebsd.org (Postfix) with SMTP id 150EC37BB6F for ; Sat, 29 Apr 2000 19:20:13 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 903 invoked by uid 1000); 30 Apr 2000 02:20:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Apr 2000 02:20:11 -0000 Date: Sat, 29 Apr 2000 21:20:11 -0500 (CDT) From: Mike Silbersack To: net@freebsd.org Subject: Additional rate limiting for icmp Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1928537973-957060913=:880" Content-ID: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk 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-1928537973-957060913=:880 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I've thrown together a patch that extends icmp_bandlim to limit the rate of icmp echo and tstamp responses. I've tested it on my 3.4 box, though the patch appears to apply to 4 and current equally well; there haven't been any significant changes to the codepath. I haven't tested its operation on a 4 or current box yet. At the same time, I've enhanced the logging so that you can see which type of response it is rate limiting (icmp unreach / rst / echo / tstamp). Note that since each type of response is limited by a seperate bucket, this patch won't affect the operation of the existing icmp unreach / rst rate limting at all. A echo flood won't cause rst to be suppressed. While the patch doesn't totally negate the effect of being flooded with icmp echo or tstamp requests, it does ensure that you don't waste your outgoing bandwidth responding to a bogus flood, and should help boxes handle such floods better. I'd appreciate it if someone could review this patch and see if it's ready to be committed to current/4/3. Thanks, Mike "Silby" Silbersack --0-1928537973-957060913=:880 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ip_icmp.c.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ip_icmp.c.patch" KioqIGlwX2ljbXAuYy4zLjQJRnJpIEFwciAyOCAxNjoyMDo1NSAyMDAwDQot LS0gaXBfaWNtcC5jLjMuNC5zaWxieQlTYXQgQXByIDI5IDIwOjU4OjI4IDIw MDANCioqKioqKioqKioqKioqKg0KKioqIDQxMCw0MTUgKioqKg0KLS0tIDQx MCw0MTkgLS0tLQ0KICAJCQlpY21wc3RhdC5pY3BzX2JtY2FzdGVjaG8rKzsN CiAgCQkJYnJlYWs7DQogIAkJfQ0KKyAjaWZkZWYgSUNNUF9CQU5ETElNDQor IAkJaWYgKGJhZHBvcnRfYmFuZGxpbSgyKSA8IDApDQorIAkJCWJyZWFrOw0K KyAjZW5kaWYNCiAgCQlpY3AtPmljbXBfdHlwZSA9IElDTVBfRUNIT1JFUExZ Ow0KICAJCWdvdG8gcmVmbGVjdDsNCiAgDQoqKioqKioqKioqKioqKioNCioq KiA0MjMsNDI4ICoqKioNCi0tLSA0MjcsNDM2IC0tLS0NCiAgCQkJaWNtcHN0 YXQuaWNwc19iYWRsZW4rKzsNCiAgCQkJYnJlYWs7DQogIAkJfQ0KKyAjaWZk ZWYgSUNNUF9CQU5ETElNDQorIAkJaWYgKGJhZHBvcnRfYmFuZGxpbSgzKSA8 IDApDQorIAkJCSBicmVhazsNCisgI2VuZGlmDQogIAkJaWNwLT5pY21wX3R5 cGUgPSBJQ01QX1RTVEFNUFJFUExZOw0KICAJCWljcC0+aWNtcF9ydGltZSA9 IGlwdGltZSgpOw0KICAJCWljcC0+aWNtcF90dGltZSA9IGljcC0+aWNtcF9y dGltZTsJLyogYm9ndXMsIGRvIGxhdGVyISAqLw0KKioqKioqKioqKioqKioq DQoqKiogNzY3LDc3MiAqKioqDQotLS0gNzc1LDc4MiAtLS0tDQogICAqCUZv ciBub3cgd2Ugc2VwYXJhdGUgdGhlIFRDUCBhbmQgVURQIHN1YnN5c3RlbXMg dy8gZGlmZmVyZW50ICd3aGljaCcNCiAgICoJdmFsdWVzLiAgV2UgbWF5IGV2 ZW50dWFsbHkgcmVtb3ZlIHRoaXMgc2VwYXJhdGlvbiAoYW5kIHNpbXBsaWZ5 IHRoZQ0KICAgKgljb2RlIGZ1cnRoZXIpLg0KKyAgKgkNCisgICoJMCA9PSBV RFAsIDEgPT0gVENQLCAyID09IElDTVBfRUNITywgMyA9PSBJQ01QX1RTVEFN UA0KICAgKg0KICAgKglOb3RlIHRoYXQgdGhlIHByaW50aW5nIG9mIHRoZSBl cnJvciBtZXNzYWdlIGlzIGRlbGF5ZWQgc28gd2UgY2FuDQogICAqCXByb3Bl cmx5IHByaW50IHRoZSBpY21wIGVycm9yIHJhdGUgdGhhdCB0aGUgc3lzdGVt IHdhcyB0cnlpbmcgdG8gZG8NCioqKioqKioqKioqKioqKg0KKioqIDc3NSw3 OTMgKioqKg0KICAgKglkZWxheSB3aXRoIG1vcmUgY29tcGxleCBjb2RlLg0K ICAgKi8NCiAgDQogIGludA0KICBiYWRwb3J0X2JhbmRsaW0oaW50IHdoaWNo KQ0KICB7DQohIAlzdGF0aWMgaW50IGx0aWNrc1syXTsNCiEgCXN0YXRpYyBp bnQgbHBhY2tldHNbMl07DQogIAlpbnQgZHRpY2tzOw0KICANCiAgCS8qDQog IAkgKiBSZXR1cm4gb2sgc3RhdHVzIGlmIGZlYXR1cmUgZGlzYWJsZWQgb3Ig YXJndW1lbnQgb3V0IG9mDQogIAkgKiByYW5hZ2UuDQogIAkgKi8NCiAgDQoh IAlpZiAoaWNtcGxpbSA8PSAwIHx8IHdoaWNoID49IDIgfHwgd2hpY2ggPCAw KQ0KICAJCXJldHVybigwKTsNCiAgCWR0aWNrcyA9IHRpY2tzIC0gbHRpY2tz W3doaWNoXTsNCiAgDQotLS0gNzg1LDgwNiAtLS0tDQogICAqCWRlbGF5IHdp dGggbW9yZSBjb21wbGV4IGNvZGUuDQogICAqLw0KICANCisgI2RlZmluZSBu dW1wYWNrZXR0eXBlcyA0DQorIA0KICBpbnQNCiAgYmFkcG9ydF9iYW5kbGlt KGludCB3aGljaCkNCiAgew0KISAJc3RhdGljIGludCBsdGlja3NbbnVtcGFj a2V0dHlwZXNdOw0KISAJc3RhdGljIGludCBscGFja2V0c1tudW1wYWNrZXR0 eXBlc107DQogIAlpbnQgZHRpY2tzOw0KKyAJY29uc3QgY2hhciAqcGFja2V0 dHlwZVtdID0geyJpY21wIHBvcnQgdW5yZWFjaGFibGUiLCJSU1QiLCJpY21w IGVjaG8iLCJpY21wIHRzdGFtcCJ9Ow0KICANCiAgCS8qDQogIAkgKiBSZXR1 cm4gb2sgc3RhdHVzIGlmIGZlYXR1cmUgZGlzYWJsZWQgb3IgYXJndW1lbnQg b3V0IG9mDQogIAkgKiByYW5hZ2UuDQogIAkgKi8NCiAgDQohIAlpZiAoaWNt cGxpbSA8PSAwIHx8IHdoaWNoID49IG51bXBhY2tldHR5cGVzIHx8IHdoaWNo IDwgMCkNCiAgCQlyZXR1cm4oMCk7DQogIAlkdGlja3MgPSB0aWNrcyAtIGx0 aWNrc1t3aGljaF07DQogIA0KKioqKioqKioqKioqKioqDQoqKiogNzk3LDgw MyAqKioqDQogIA0KICAJaWYgKCh1bnNpZ25lZCBpbnQpZHRpY2tzID4gaHop IHsNCiAgCQlpZiAobHBhY2tldHNbd2hpY2hdID4gaWNtcGxpbSkgew0KISAJ CQlwcmludGYoImljbXAtcmVzcG9uc2UgYmFuZHdpZHRoIGxpbWl0ICVkLyVk IHBwc1xuIiwNCiAgCQkJCWxwYWNrZXRzW3doaWNoXSwNCiAgCQkJCWljbXBs aW0NCiAgCQkJKTsNCi0tLSA4MTAsODE3IC0tLS0NCiAgDQogIAlpZiAoKHVu c2lnbmVkIGludClkdGlja3MgPiBoeikgew0KICAJCWlmIChscGFja2V0c1t3 aGljaF0gPiBpY21wbGltKSB7DQohIAkJCXByaW50ZigiJXMtcmVzcG9uc2Ug YmFuZHdpZHRoIGxpbWl0ICVkLyVkIHBwc1xuIiwNCiEgCQkJCXBhY2tldHR5 cGVbd2hpY2hdLA0KICAJCQkJbHBhY2tldHNbd2hpY2hdLA0KICAJCQkJaWNt cGxpbQ0KICAJCQkpOw0K --0-1928537973-957060913=:880-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 22:32:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id ADBFF37B509; Sat, 29 Apr 2000 22:32:46 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 355FC1E04C; Sun, 30 Apr 2000 01:32:41 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id BAA29278; Sun, 30 Apr 2000 01:32:31 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id WAA03189; Sat, 29 Apr 2000 22:31:20 -0700 (PDT) Message-Id: <200004300531.WAA03189@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: archie@whistle.com Subject: Re: Improved PPTP support for libalias(3) Cc: ru@freebsd.org, julian@elischer.org, brian@awfulhak.org, cmott@scientech.com, ari@suutari.iki.fi, perhaps@yes.no, net@freebsd.org, erik@whistle.com Date: Sat, 29 Apr 2000 22:31:19 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org BTW, I have some code to translate generic IP (no port smashing) that handles ESP and some uses of GRE. I needed natd to handle ESP so that my wife could use her VPN and I decided to just implement IP-address only translation. I haven't committed the patches yet for various stupid reasons, but if anyone would like to review them I'd appreciate it. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Apr 29 23:21:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasi.com (sasi.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 7C6E037B54C for ; Sat, 29 Apr 2000 23:21:33 -0700 (PDT) (envelope-from gbnaidu@sasi.com) Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA09385 for ; Sun, 30 Apr 2000 11:51:03 +0530 (IST) Received: from hpd14.sasi.com ([10.0.16.14]) by sasi.com; Sun, 30 Apr 2000 11:51:01 +0000 (IST) Received: from localhost (gbnaidu@localhost) by hpd14.sasi.com (8.9.1/8.9.1) with ESMTP id MAA01223 for ; Sun, 30 Apr 2000 12:02:07 +0530 (IST) Date: Sun, 30 Apr 2000 12:02:07 +0530 (IST) From: "G.B.Naidu" To: freebsd-net@FreeBSD.ORG Subject: How do I login as root using telnet? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I would like to know how to enable superuser logins using telnet? thanks --gb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message