From owner-freebsd-net Sun Jul 9 11:38:33 2000 Delivered-To: freebsd-net@freebsd.org Received: from wat-border.sentex.ca (waterloo-hespler.sentex.ca [199.212.135.66]) by hub.freebsd.org (Postfix) with ESMTP id 0A55037B8F0 for ; Sun, 9 Jul 2000 11:38:30 -0700 (PDT) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by wat-border.sentex.ca (8.9.3/8.9.3) with ESMTP id OAA12533 for ; Sun, 9 Jul 2000 14:38:28 -0400 (EDT) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id OAA27109 for ; Sun, 9 Jul 2000 14:38:28 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: freebsd-net@freebsd.org Subject: Re: Hardware crypto (Re: KAME stable 20000704) Date: Sun, 09 Jul 2000 18:34:07 GMT Message-ID: <3968c576.625945101@mail.sentex.net> References: <4.3.2.7.2.20000707162836.03d4ead0@mail.Go2France.com> In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 8 Jul 2000 02:23:30 -0400, in sentex.lists.freebsd.net you wrote: >On Fri, 7 Jul 2000, Len Conrad wrote: > >> Are there any hardware-encryption boards for KAME or OpenSSL? > >Bill Paul is looking at this for FreeBSD. http://www.powercrypt.com/ supposedly is updating their drivers for FreeBSD 4.x as well. ---Mike Mike Tancsa (mdtancsa@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 14: 4:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E805537BFFD for ; Sun, 9 Jul 2000 14:04:42 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e69L4fJ03861 for net@freebsd.org; Sun, 9 Jul 2000 14:04:41 -0700 (PDT) Date: Sun, 9 Jul 2000 14:04:41 -0700 From: Alfred Perlstein To: net@freebsd.org Subject: weird things with M_EXT and large packets Message-ID: <20000709140441.T25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have some code here sending a mbuf via: error = (*so->so_proto->pr_usrreqs->pru_send)(so, 0, m, 0, 0, p); m is setup like so: m->m_ext.ext_free = kblob_mbuf_free; m->m_ext.ext_ref = kblob_mbuf_ref; m->m_ext.ext_buf = (void *)kb; m->m_ext.ext_size = kb->kb_len; m->m_data = (char *) kb->kb_data + uap->offset; m->m_flags |= M_EXT; m->m_pkthdr.len = m->m_len = uap->nbytes; uap->nbytes is 59499. It looks like the packet is being broken up or referenced to be sent, but at a certain point it hangs. this is a sort of trace going on: kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_ref: size = 59499 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 4 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 3 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_ref: size = 59499 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 4 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 3 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 2 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 which is the output of the ext_free and ext_ref functions, after that for a couple of seconds i get this as long as the remote side doesn't close the connection: kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 1 ... kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 1 kblob_mbuf_ref: size = 59499 kblob_mbuf_free: size = 59499 deref, id = 0, refcnt = 1 as if it's retrying. after the remote side closes the connection, the mbuf is finally free'd after a short delay. Is there some weird limit i'm bumping into? Will I have to break this down into multiple mbufs with external storage? FYI I'm using fxp and: 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Jul 2 11:59:25 PDT 2000 thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 15: 0:16 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 D6F3D37BAF8 for ; Sun, 9 Jul 2000 15:00:14 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id EEEBC1C6C; Sun, 9 Jul 2000 18:00:13 -0400 (EDT) Date: Sun, 9 Jul 2000 18:00:13 -0400 From: Bill Fumerola To: Bosko Milekic Cc: Mike Silbersack , "Richard A. Steenbergen" , freebsd-net@FreeBSD.ORG Subject: Re: stuck in LAST_ACK Message-ID: <20000709180013.R4034@jade.chc-chimes.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bmilekic@dsuper.net on Fri, Jul 07, 2000 at 06:28:12PM -0400 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jul 07, 2000 at 06:28:12PM -0400, Bosko Milekic wrote: > > OTOH, the high number of mbufs/mbuf clusters you have is almost > > worrysome; a netkill on that box could eat up a LOT of memory, which won't > > get freed. > > Yes, another reason to look into the mbuf subsystem free pages patch. I could have sworn I said that in another mail... :-> -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: billf@chimesnet.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 15:21:46 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 0CCEE37BF38 for ; Sun, 9 Jul 2000 15:21:36 -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 SAA00894; Sun, 9 Jul 2000 18:21:31 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007092221.SAA00894@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mike@sentex.net (Mike Tancsa) Cc: freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Hardware crypto (Re: KAME stable 20000704) References: <4.3.2.7.2.20000707162836.03d4ead0@mail.Go2France.com> <3968c576.625945101@mail.sentex.net> In-reply-to: Your message of "Sun, 09 Jul 2000 18:34:07 GMT." <3968c576.625945101@mail.sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Jul 2000 18:21:31 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On 8 Jul 2000 02:23:30 -0400, in sentex.lists.freebsd.net you wrote: > > >On Fri, 7 Jul 2000, Len Conrad wrote: > > > >> Are there any hardware-encryption boards for KAME or OpenSSL? > > > >Bill Paul is looking at this for FreeBSD. > > http://www.powercrypt.com/ supposedly is updating their drivers for FreeBSD > 4.x as well. Note that their drivers export a user-mode device, which might be usable for TLS/SSL hardware assist, isn't applicable for IPSEC assist. See the OpenBSD driver for software that addresses that need. That being said, the folks that sell the powercrypt board have been very helpful and supportive to folks using their products on UNIX platforms. I've been very pleased in my interactions with them. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 16: 4:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from phoenix.dynamine.net (phoenix.dynamine.net [64.14.25.210]) by hub.freebsd.org (Postfix) with ESMTP id A34AA37B59F for ; Sun, 9 Jul 2000 16:04:54 -0700 (PDT) (envelope-from michael@dynamine.net) Received: from angeline (1Cust54.tnt13.sjc4.da.uu.net [63.42.98.54]) by phoenix.dynamine.net (Postfix) with SMTP id 51C3D183970 for ; Sun, 9 Jul 2000 16:04:53 -0700 (PDT) From: "Michael S. Fischer" To: Subject: bpf problem with lo0 interface Date: Sun, 9 Jul 2000 16:04:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.2919.6600 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, Running 4.0-STABLE, I seem to be having difficulty getting any of the packet capture/analysis tools (with the exception of tcpdump, which prints the headers correctly) to give me packet _data_ information when I sniff the lo0 interface. Tools I've tested: - tcpshow(1) - tcpflow(1) Here's an example: # tcpdump -s 1518 -i lo0 -lenx port 143 | tcpshow -cooked -noEtherNames tcpdump: listening on lo0 --------------------------------------------------------------------------- Packet 1 TIME: 16:03:25.186986 LINK: 64:14:25:21:.1:84 -> 0>::å¿:æ#:(L:( type=64.14.25.210.143: <*** No decode support for encapsulated protocol ***> --------------------------------------------------------------------------- Packet 2 TIME: 16:03:25.187048 (0.000062) LINK: 64:14:25:21:.1:03 -> 0>:(::å::$:((:( type=64.14.25.210.1284: <*** No decode support for encapsulated protocol ***> ... and tcpflow shows, well, nothing at all. I am able to successfully sniff/analyze captured data using the two tools above when using the fxp0 interface. Can someone please assist? Thanks, -- Michael S. Fischer AKA Otterley _O_ Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA | Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 | "From the bricks of shame is built the hope"--Alan Wilder net.goth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 20:51:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B766B37C43F; Sun, 9 Jul 2000 20:51:24 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6A3pOG14828; Sun, 9 Jul 2000 20:51:24 -0700 (PDT) Date: Sun, 9 Jul 2000 20:51:24 -0700 From: Alfred Perlstein To: net@freebsd.org Cc: dg@freebsd.org, wollman@freebsd.org Subject: argh! Re: weird things with M_EXT and large packets Message-ID: <20000709205124.A25571@fw.wintelcom.net> References: <20000709140441.T25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000709140441.T25571@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Jul 09, 2000 at 02:04:41PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alfred Perlstein [000709 14:04] wrote: > I have some code here sending a mbuf via: > > error = (*so->so_proto->pr_usrreqs->pru_send)(so, 0, m, 0, 0, p); > > m is setup like so: > > m->m_ext.ext_free = kblob_mbuf_free; > m->m_ext.ext_ref = kblob_mbuf_ref; > m->m_ext.ext_buf = (void *)kb; > m->m_ext.ext_size = kb->kb_len; > m->m_data = (char *) kb->kb_data + uap->offset; > m->m_flags |= M_EXT; > m->m_pkthdr.len = m->m_len = uap->nbytes; > > uap->nbytes is 59499. > > It looks like the packet is being broken up or referenced to be sent, > but at a certain point it hangs. I'm 99.99% sure what's going on is that since I'm using normal kernel malloc for these external clusters what's happening is that the device driver is failing to notice that the data contained crosses a page boundry and isn't breaking the data up properly. Since the memory is fragmented it's passing garbage over the wire that doesn't match the checksum (hence the resending of the data) Doing a transfer over localhost works fine. If use contigmalloc to allocate the buffers then it works, I would really rather not use contigmalloc because frankly it scares me. Is there a specific reason the network drivers (or at least fxp) don't seem to check page boundries so that discontig kmem can be passed to the drivers in large chunks? I'd rather not have to allocate size/PAGE_SIZE mbuf headers for each send. This may only fxp doing this incorrectly, or I may be just be totally off, does this all make sense? thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 21:23:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id B41C937B730; Sun, 9 Jul 2000 21:23:45 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA20554; Sun, 9 Jul 2000 22:23:42 -0600 (MDT) (envelope-from ken) Date: Sun, 9 Jul 2000 22:23:41 -0600 From: "Kenneth D. Merry" To: Alfred Perlstein Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: argh! Re: weird things with M_EXT and large packets Message-ID: <20000709222341.A20360@panzer.kdm.org> References: <20000709140441.T25571@fw.wintelcom.net> <20000709205124.A25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000709205124.A25571@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Jul 09, 2000 at 08:51:24PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jul 09, 2000 at 20:51:24 -0700, Alfred Perlstein wrote: > * Alfred Perlstein [000709 14:04] wrote: > > I have some code here sending a mbuf via: > > > > error = (*so->so_proto->pr_usrreqs->pru_send)(so, 0, m, 0, 0, p); > > > > m is setup like so: > > > > m->m_ext.ext_free = kblob_mbuf_free; > > m->m_ext.ext_ref = kblob_mbuf_ref; > > m->m_ext.ext_buf = (void *)kb; > > m->m_ext.ext_size = kb->kb_len; > > m->m_data = (char *) kb->kb_data + uap->offset; > > m->m_flags |= M_EXT; > > m->m_pkthdr.len = m->m_len = uap->nbytes; > > > > uap->nbytes is 59499. > > > > It looks like the packet is being broken up or referenced to be sent, > > but at a certain point it hangs. > > I'm 99.99% sure what's going on is that since I'm using normal kernel > malloc for these external clusters what's happening is that the device > driver is failing to notice that the data contained crosses a page > boundry and isn't breaking the data up properly. Since the memory is > fragmented it's passing garbage over the wire that doesn't match the > checksum (hence the resending of the data) > > Doing a transfer over localhost works fine. > > If use contigmalloc to allocate the buffers then it works, I would really > rather not use contigmalloc because frankly it scares me. I had the same problem earlier this year, except it was with pages passed from userland into the kernel. My solution was to walk each incoming buffer and detect boundaries between chunks of contiguous pages. (So I wound up with a set of physical pointers and lengths.) > Is there a specific reason the network drivers (or at least fxp) > don't seem to check page boundries so that discontig kmem can be > passed to the drivers in large chunks? I'd rather not have to > allocate size/PAGE_SIZE mbuf headers for each send. > > This may only fxp doing this incorrectly, or I may be just be > totally off, does this all make sense? It does make sense. I would bet that most, if not all, network drivers don't check for contiguous memory. There are numerous reasons for this, but I think the bottom line is that it's too much trouble for too little gain. Most network devices that FreeBSD supports have a MTU of 1500 bytes or so, and at least in standard mbufs, the drivers don't have to worry about the chunk of data they get crossing page boundaries. Even with drivers with larger MTUs, like gigabit ethernet drivers, they typically take chains of mbufs, and do a separate vtophys() on each element in the chain, ans pass it down to the card. Again, they expect that each mbuf points to a physically contiguous chunk of memory. One thing to keep in mind, at least about allocating huge chunks of memory and passing them down the network stack, is that the big chunks will get split up, either by the TCP layer or the IP layer. The big chunks will get split into multiple pieces, each with its own mbuf header. The zero copy send code that Drew Gallatin wrote uses page-sized chunks to pass things around. With a gigabit ethernet jumbo MTU (9000 bytes), that is very efficient on the Alpha, with its 8K page size, but less efficient on the i386, with its 4K page size. (Since you end up with double the number of chunks.) From the benchmarks I've done, increasing the chunk size from 4K to 8K on the i386 would cut CPU utilization in half on sends over gigabit ethernet. The problem in that instance (according to Drew) is getting the COW stuff right for chunks of data bigger than a page. Another thing I learned from doing benchmarks is that increasing the chunk size to something larger than your MTU doesn't help CPU utilization much, if at all, since the larger chunks eventually get broken up into MTU-sized chunks. The most efficient chunk size for larger MTU adapters (i.e. more than 4K) is the nearest page multiple that is less than the MTU size. I'm not sure if this will work with what you're trying to do, but you could use contigmalloc() to allocate a large chunk of memory (say multiple megabytes in size) and then break it up into smaller chunks of memory that are then tacked onto mbufs. The ti(4) driver uses that approach in its stock (i.e. non-zero-copy) jumbo receive buffer allocation code, since the type of jumbo receive buffers it uses by default are expected to consist of one contiguous piece of memory. (The Tigon firmware also supports another type of jumbo receive buffer with 4 S/G entries.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jul 9 23: 5:42 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 7272137B7D7; Sun, 9 Jul 2000 23:05:38 -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 WAA01544; Sun, 9 Jul 2000 22:53:46 -0700 (PDT) Message-Id: <200007100553.WAA01544@implode.root.com> To: Alfred Perlstein Cc: net@freebsd.org, dg@freebsd.org, wollman@freebsd.org Subject: Re: argh! Re: weird things with M_EXT and large packets In-reply-to: Your message of "Sun, 09 Jul 2000 20:51:24 PDT." <20000709205124.A25571@fw.wintelcom.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 09 Jul 2000 22:53:46 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >* Alfred Perlstein [000709 14:04] wrote: >> I have some code here sending a mbuf via: >> >> error = (*so->so_proto->pr_usrreqs->pru_send)(so, 0, m, 0, 0, p); >> >> m is setup like so: >> >> m->m_ext.ext_free = kblob_mbuf_free; >> m->m_ext.ext_ref = kblob_mbuf_ref; >> m->m_ext.ext_buf = (void *)kb; >> m->m_ext.ext_size = kb->kb_len; >> m->m_data = (char *) kb->kb_data + uap->offset; >> m->m_flags |= M_EXT; >> m->m_pkthdr.len = m->m_len = uap->nbytes; >> >> uap->nbytes is 59499. >> >> It looks like the packet is being broken up or referenced to be sent, >> but at a certain point it hangs. > >I'm 99.99% sure what's going on is that since I'm using normal kernel >malloc for these external clusters what's happening is that the device >driver is failing to notice that the data contained crosses a page >boundry and isn't breaking the data up properly. Since the memory is >fragmented it's passing garbage over the wire that doesn't match the >checksum (hence the resending of the data) > >Doing a transfer over localhost works fine. > >If use contigmalloc to allocate the buffers then it works, I would really >rather not use contigmalloc because frankly it scares me. > >Is there a specific reason the network drivers (or at least fxp) >don't seem to check page boundries so that discontig kmem can be >passed to the drivers in large chunks? I'd rather not have to >allocate size/PAGE_SIZE mbuf headers for each send. > >This may only fxp doing this incorrectly, or I may be just be >totally off, does this all make sense? You're correct that the fxp driver doesn't try to detect page breaks. It (wrongfully in your case) assumes that buffers are 1 page or less in size and don't cross physical page boundries. The driver was written to be fast, and doing multiple vtophys operations to detect a case which previously would never happen isn't a good thing for performance. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer 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 Sun Jul 9 23:36: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from lychee.itojun.org (dialup0.itojun.org [210.160.95.108]) by hub.freebsd.org (Postfix) with ESMTP id 9B9A537B6FC for ; Sun, 9 Jul 2000 23:36:00 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e6A6YW401036; Mon, 10 Jul 2000 15:34:32 +0900 (JST) To: "Louis A. Mamakos" Cc: mike@sentex.net (Mike Tancsa), freebsd-net@FreeBSD.ORG In-reply-to: louie's message of Sun, 09 Jul 2000 18:21:31 -0400. <200007092221.SAA00894@whizzo.transsys.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Hardware crypto (Re: KAME stable 20000704) From: Jun-ichiro itojun Hagino Date: Mon, 10 Jul 2000 15:34:32 +0900 Message-ID: <1034.963210872@localhost> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Note that their drivers export a user-mode device, which might be usable >for TLS/SSL hardware assist, isn't applicable for IPSEC assist. See the >OpenBSD driver for software that addresses that need. > >That being said, the folks that sell the powercrypt board have been very >helpful and supportive to folks using their products on UNIX platforms. >I've been very pleased in my interactions with them. In case anyone got confused: please note that "IPsec support for crypto card" and "crypto card support as user-mode device file" are totally different thing. Former one needs MAJOR work in network IP layer design (BSD IP layer runs under software interrupt, killing possibility for offloading CPU). OpenBSD did a truely super job on this. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 10 0: 2:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B90E637B7A7; Mon, 10 Jul 2000 00:02:39 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6A72bc19546; Mon, 10 Jul 2000 00:02:37 -0700 (PDT) Date: Mon, 10 Jul 2000 00:02:37 -0700 From: Alfred Perlstein To: David Greenman Cc: net@freebsd.org, dg@freebsd.org, wollman@freebsd.org, ken@kdm.org Subject: Re: argh! Re: weird things with M_EXT and large packets Message-ID: <20000710000237.C25571@fw.wintelcom.net> References: <20000709205124.A25571@fw.wintelcom.net> <200007100553.WAA01544@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007100553.WAA01544@implode.root.com>; from dg@root.com on Sun, Jul 09, 2000 at 10:53:46PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Greenman [000709 23:05] wrote: > >* Alfred Perlstein [000709 14:04] wrote: > > > >I'm 99.99% sure what's going on is that since I'm using normal kernel > >malloc for these external clusters what's happening is that the device > >driver is failing to notice that the data contained crosses a page > >boundry and isn't breaking the data up properly. Since the memory is > >fragmented it's passing garbage over the wire that doesn't match the > >checksum (hence the resending of the data) > > > >Doing a transfer over localhost works fine. > > > >If use contigmalloc to allocate the buffers then it works, I would really > >rather not use contigmalloc because frankly it scares me. > > > >Is there a specific reason the network drivers (or at least fxp) > >don't seem to check page boundries so that discontig kmem can be > >passed to the drivers in large chunks? I'd rather not have to > >allocate size/PAGE_SIZE mbuf headers for each send. > > > >This may only fxp doing this incorrectly, or I may be just be > >totally off, does this all make sense? > > You're correct that the fxp driver doesn't try to detect page breaks. It > (wrongfully in your case) assumes that buffers are 1 page or less in size and > don't cross physical page boundries. The driver was written to be fast, and > doing multiple vtophys operations to detect a case which previously would > never happen isn't a good thing for performance. Actually, it does happen, you still need to vtophys once per mbuf/cluster, allowing someone to present super large clusters reduces allocation in the mbuf systems and cache utilization. The detection of this situation is simply: if ((mh_flags & M_EXT) != 0 && m->m_ext.ext_free != NULL && (m_data % PAGE_SIZE) + m_len > PAGE_SIZE) { /* split */ } The mod operation acting on a power of two should reduce to a bitmask, so the overhead of doing this isn't that great. The test could probably dispense with the EXT and ext_free checks and wind up faster than with them in. Mike Smith pointed me at some macros/functions that NetBSD uses to accomplish this, I'll be investigating them as I'd rather make a single allocation than one per 4k page. I would like to know ahead of time what your opinion on bringing this in would be, it looks to me like the overhead is so small that the increase in functionality would be very worth it. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 10 0:32:10 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id E9EF037BC7F for ; Mon, 10 Jul 2000 00:32:06 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from bagabeedaboo.security.at12.de (dial-195-14-226-101.netcologne.de [195.14.226.101]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id JAA18431; Mon, 10 Jul 2000 09:32:05 +0200 (MET DST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by bagabeedaboo.security.at12.de (8.10.2/8.10.2) with ESMTP id e6A7Vq000294; Mon, 10 Jul 2000 09:31:52 +0200 (CEST) Date: Mon, 10 Jul 2000 09:31:51 +0200 (CEST) From: Paul Herman To: "Michael S. Fischer" Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf problem with lo0 interface 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 Sun, 9 Jul 2000, Michael S. Fischer wrote: > Running 4.0-STABLE, I seem to be having difficulty getting any of the packet > capture/analysis tools (with the exception of tcpdump, which prints the > headers correctly) to give me packet _data_ information when I sniff the lo0 > interface. I don't know about tcpflow, but tcpshow doesn't handle NULL layer links (lo0, tun0, etc...). In fact, I think it only handles ethernet type link layers. Sorry, you are stuck with 'tcpdump -x'. For what it's worth, I wrote a program to print packets for just this reason. It is 'packetdump' and is hidden in: http://www.frenchfries.net/paul/tcpstat/tcpstat-1.3pre.tar.gz (after compiling it is in the src/ directory.) The output may not be as tcpshow yet, but it gets the job done. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 10 8:18: 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 882C737C58F for ; Mon, 10 Jul 2000 08:18:05 -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 LAA53686; Mon, 10 Jul 2000 11:17:57 -0400 (EDT) (envelope-from wollman) Date: Mon, 10 Jul 2000 11:17:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200007101517.LAA53686@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@freebsd.org Subject: argh! Re: weird things with M_EXT and large packets In-Reply-To: <20000709205124.A25571@fw.wintelcom.net> References: <20000709140441.T25571@fw.wintelcom.net> <20000709205124.A25571@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Is there a specific reason the network drivers (or at least fxp) > don't seem to check page boundries so that discontig kmem can be > passed to the drivers in large chunks? Yes -- because it ``can't happen'', and in the normal case it would never happen so there's no point in wasting cycles to check for it. -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 Mon Jul 10 11:20:33 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 5165337BBB9 for ; Mon, 10 Jul 2000 11:20:29 -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 LAA03191; Mon, 10 Jul 2000 11:08:44 -0700 (PDT) Message-Id: <200007101808.LAA03191@implode.root.com> To: Alfred Perlstein Cc: net@freebsd.org Subject: Re: argh! Re: weird things with M_EXT and large packets In-reply-to: Your message of "Mon, 10 Jul 2000 00:02:37 PDT." <20000710000237.C25571@fw.wintelcom.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 10 Jul 2000 11:08:44 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I would like to know ahead of time what your opinion on bringing >this in would be, it looks to me like the overhead is so small that >the increase in functionality would be very worth it. It's fine by me. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer 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 Mon Jul 10 12:44: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 2392637BD4C; Mon, 10 Jul 2000 12:43:57 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA26975; Mon, 10 Jul 2000 13:43:47 -0600 (MDT) (envelope-from ken) Date: Mon, 10 Jul 2000 13:43:47 -0600 From: "Kenneth D. Merry" To: Alfred Perlstein Cc: David Greenman , net@freebsd.org, dg@freebsd.org, wollman@freebsd.org Subject: Re: argh! Re: weird things with M_EXT and large packets Message-ID: <20000710134346.A26914@panzer.kdm.org> References: <20000709205124.A25571@fw.wintelcom.net> <200007100553.WAA01544@implode.root.com> <20000710000237.C25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000710000237.C25571@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jul 10, 2000 at 12:02:37AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jul 10, 2000 at 00:02:37 -0700, Alfred Perlstein wrote: > Actually, it does happen, you still need to vtophys once per > mbuf/cluster, allowing someone to present super large clusters > reduces allocation in the mbuf systems and cache utilization. > > The detection of this situation is simply: > > if ((mh_flags & M_EXT) != 0 && m->m_ext.ext_free != NULL > && (m_data % PAGE_SIZE) + m_len > PAGE_SIZE) { > /* split */ > } > > The mod operation acting on a power of two should reduce to a > bitmask, so the overhead of doing this isn't that great. > > The test could probably dispense with the EXT and ext_free checks > and wind up faster than with them in. Another way to do it would be to have a flag that tells the driver that it should check for fragmentation. You'll just need to make sure that the flag gets copied in the right places in the mbuf code when mbufs are copied, etc. (An easy way to check that out is to see what the mbuf code does with M_EXT.) > Mike Smith pointed me at some macros/functions that NetBSD uses to > accomplish this, I'll be investigating them as I'd rather make a > single allocation than one per 4k page. Yeah, if we're going to do this, we'll want a common set of routines to traverse the memory and pull out the various chunks. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 10 16:29:36 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 D22F837B865; Mon, 10 Jul 2000 16:29:29 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com ([208.187.122.225]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id RAA25574; Mon, 10 Jul 2000 17:28:31 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <396751EA.F7EF2EC6@softweyr.com> Date: Sat, 08 Jul 2000 10:08:10 -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: Nick Rogness Cc: "Louis A. Mamakos" , Narvi , Sean Lutner , Nick Evans , "'freebsd-hackers@freebsd.org'" , "'freebsd-net@freebsd.org'" Subject: Re: bridging References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Fri, 7 Jul 2000, Louis A. Mamakos wrote: > > > They can't be in the same collision domain -- the only way to do that > > is to have an Ethernet repeater which repeats bit by bit fron one > > segment to another, and propagating a collision on one segment as a > > jam on another. > > > > On a FreeBSD box, where you interfaces to ethernet segments are NIC > > cards, you can't get your hands on the ethernet frame until the > > NIC has received it completely. Thus, you don't have to opportunity > > to act as a repeater (not that you'd want to anyway) to have a > > single collision domain. > > You know, you are right...never thought it > through completely before I sent my reply. Sorry > everyone for the wasted bandwidth. > > Have 1 more question (has to do with this bridging deal): > > Anyone working on load-sharing/load-balancing or clustering > network solution with FreeBSD? Eddieware? http://www.eddieware.org/ IIRC. -- "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 Jul 10 23:11:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a13c249.neo.rr.com [204.210.212.249]) by hub.freebsd.org (Postfix) with ESMTP id CF89037BD3F for ; Mon, 10 Jul 2000 23:11:17 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id e6B6Acn02099 for ; Tue, 11 Jul 2000 02:10:38 -0400 Date: Tue, 11 Jul 2000 02:10:38 -0400 (EDT) From: Mike Nowlin To: freebsd-net@freebsd.org Subject: FDDI 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 (This is more of a networking physical-layer question, for those of you browsing the first 3 lines & deleting messages that don't interest you.) :) I have an old DEC Alpha (3000/500S) machine that has a built-in cheapish 10Mbps ethernet interface. A certain feature that runs every night (backup via network) is starting to take way too long. Ingenious solution: 100BTx network card. Problem: they don't make them for this box. New ingenious solution: FDDI card. So now I have this lovely TurboChannel FDDI card that I don't have anything else to connect to. The backup server is a FreeBSD box with plenty of PCI slots available. The 10Mbps connection right now is through a HP 2424M switch. I've done lots of reading on FDDI, but haven't found any answers to "simple" problems - everything I've found is referring to campus-wide backbone networks with eight zillion hosts connected to them. Is is possible to "null-modem" two FDDI cards directly together by flopping the TX & RX fibers? If so, what cards are recommended for FreeBSD (the backup server)? tnx - mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jul 10 23:44:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9187B37BCB2 for ; Mon, 10 Jul 2000 23:44:41 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id CAA36898; Tue, 11 Jul 2000 02:43:15 -0400 (EDT) Date: Tue, 11 Jul 2000 02:43:15 -0400 (EDT) From: "Matthew N. Dodd" To: Mike Nowlin Cc: freebsd-net@FreeBSD.ORG Subject: Re: FDDI 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, 11 Jul 2000, Mike Nowlin wrote: > Is is possible to "null-modem" two FDDI cards directly together by > flopping the TX & RX fibers? Yes. > If so, what cards are recommended for FreeBSD (the backup server)? DEFPA(pci) or DEFEA(eisa) Your Alpha probably has a DEFTA(turbochannel) no? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 0: 0:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id 2AFF137B859 for ; Tue, 11 Jul 2000 00:00:46 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id JAA27326; Tue, 11 Jul 2000 09:00:33 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id IAA06652; Tue, 11 Jul 2000 08:48:17 +0200 (CEST) (envelope-from andreas) Date: Tue, 11 Jul 2000 08:48:17 +0200 From: Andreas Klemm To: zebra@zebra.org Cc: freebsd-net@freebsd.org Subject: fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all Message-ID: <20000711084817.A6604@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2i X-Operating-System: FreeBSD 5.0-CURRENT SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OSPF died with titan-ospf# conf t titan-ospf(config)# router ospf OSPF: Router-ID[OLD:0.0.0.0]: Update OSPF: Router-ID[NEW:172.16.2.1]: Update titan-ospf(config-router)# redistribute connected titan-ospf(config-router)# redistribute static metric 50 titan-ospf(config-router)# network 172.16.2.0/24 area 0 OSPF: interface xl0 join AllSPFRouters Multicast group. titan-ospf(config-router)# OSPF: LSA[Refresh]: Timer (router-LSA Refresh expire)OSPF: Z: counting fully adjacent virtual neighbors in area 0.0.0.0 OSPF: Z: there are 0 of them OSPF: new_lsdb_insert: Newly install OSPF: SPF: calculation timer scheduled OSPF: SPF: calculation timer delay = 1572866 titan-ospf(config-router)# OSPF: Hello received from [172.16.200.2] via [xl0] OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* OSPF: NSM[xl0:0.0.0.0]: start OSPF: Z: make_hello: options: 70, int: xl0 OSPF: Hello sent to [224.0.0.5] via [xl0]. OSPF: Hello received from [172.16.200.2] via [xl0] OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* OSPF: Z: make_hello: options: 70, int: xl0 OSPF: Hello sent to [224.0.0.5] via [xl0]. titan-ospf(config-router)# network 172.16.2.0/24 area OSPF: Hello received from [172.16.200.2] via [xl0] OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* OSPF: Z: make_hello: options: 70, int: xl0 OSPF: Hello sent to [224.0.0.5] via [xl0]. titan-ospf(config-router)# end titan-ospf# sh ip ospf neigh Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 172.16.200.2 100 Init/DROther 00:00:32 172.16.2.2 xl0 0 0 0 titan-ospf# OSPF: Hello received from [172.16.200.2] via [xl0] OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* OSPF: DR-Election[1st]: Backup 0.0.0.0 OSPF: DR-Election[1st]: DR 0.0.0.0 OSPF: DR-Election[2nd]: Backup 0.0.0.0 OSPF: DR-Election[2nd]: DR 0.0.0.0 Connection closed by foreign host. [1] + Done ethereal root@titan{522} $ cd /var/lo Cisco never shows neighbor... I don't get OSPF running on FreeBSD 5.0 (-current), no matter what I do. Some other people running zebra on -current ??? Andreas /// ! ! Zebra configuration saved from vty ! 2000/07/11 08:38:51 ! hostname titan-ospf password c enable password c log file /var/log/zebra-ospfd.log log stdout log record-priority ! ! ! interface xl0 ! interface ed0 ! interface lo0 ! router ospf redistribute connected redistribute static metric 50 network 172.16.2.0/24 area 0 ! line vty exec-timeout 0 0 ! ! ! Zebra configuration saved from vty ! 2000/06/27 19:27:50 ! hostname titan-zebra password c enable password c log file /var/log/zebra.log log record-priority service advanced-vty ! interface xl0 description DMZ ! interface ed0 description internal ! interface ppp0 ! interface lo0 description loopback ! interface gif0 ! interface gif1 ! interface gif2 ! interface gif3 ! interface stf0 ! interface faith0 ! line vty exec-timeout 0 0 ! -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 3:56:19 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0080537B963; Tue, 11 Jul 2000 03:56:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id DAA98036; Tue, 11 Jul 2000 03:56:15 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 11 Jul 2000 03:56:15 -0700 (PDT) From: Kris Kennaway To: arch@freebsd.org Cc: net@freebsd.org, jkh@freebsd.org, Hajimu UMEMOTO Subject: Merge of KAME code 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'm still intending to merge back the KAME code into 4.0 in a few days, to give something approaching adequate shakedown time in 4.0 before release. With the exception of the rcmd_af() bug found by Peter, and missing functionality in IPv6 multicast (see recent post to -net by itojun) I haven't heard of any problems with the new code. I'm still nervous about merging back the libc changes because (as demonstrated already) they have a larger chance to affect IPv4 operation. Umemoto-san, do you have any opinions about the wisdom of this? (As a reminder, my motivation for pushing this is to have 4.1 be capable of running racoon, the KAME IKE daemon, which makes IPSEC *much* more functional and usable in real-world situations (including interoperation with other platforms). Secondary, but still important, is to push FreeBSD as a viable platform for IPv6 and IPSEC research - based on the traffic I see on the KAME mailing list, FreeBSD is already a major research platform but users until now had to use the 4.0-REL KAME snaps) If anyone has problems with the new KAME they've been keeping to themselves, or intends to exercise some kind of veto, please let me know! Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 4: 9: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from pr.infosec.ru (pr.infosec.ru [194.135.141.98]) by hub.freebsd.org (Postfix) with ESMTP id C58A037BE33 for ; Tue, 11 Jul 2000 04:09:02 -0700 (PDT) (envelope-from blaze@infosec.ru) Received: from blaze (WS_BLAZE [200.0.0.51]) by pr.infosec.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3WLXZ1N9; Tue, 11 Jul 2000 15:09:14 +0400 Date: Tue, 11 Jul 2000 15:08:37 +0400 (MSD) From: Andrey Sverdlichenko X-Sender: blaze@blaze To: freebsd-net@freebsd.org Subject: Re: Hardware crypto (Re: KAME stable 20000704) 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, 10 Jul 2000, Jun-ichiro itojun Hagino wrote: > In case anyone got confused: please note that "IPsec support for > crypto card" and "crypto card support as user-mode device file" > are totally different thing. Former one needs MAJOR work in > network IP layer design (BSD IP layer runs under software interrupt, > killing possibility for offloading CPU). OpenBSD did a truely > super job on this. Hmmm... i don't know about KAME/IPSEC, but in our cryptorouter i made it in easy way: 1) in software interrupt context packet goes to "crypto task queue" 2) kernel process gets packet from this queue and passes it to encryption/decryption functions (currently software, but i see nothing special in hardware support) 3) after processing packet injected back to ip_input()/ip_output(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 5:31:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by hub.freebsd.org (Postfix) with ESMTP id 5241037B9D2; Tue, 11 Jul 2000 05:31:16 -0700 (PDT) (envelope-from ume@bisd.hitachi.co.jp) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id VAA29364; Tue, 11 Jul 2000 21:31:07 +0900 (JST) Received: from plum.ssr.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id VAA15772; Tue, 11 Jul 2000 21:31:06 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Received: from localhost (IDENT:TnWloJykWU499Texbnpyz7+L7aXQQU/kh9ySh/cxpbi11sA6dAzw5ukJkKVt7Fug@localhost [::1]) by plum.ssr.bisd.hitachi.co.jp (8.10.1/3.7W-plum) with ESMTP id e6BCV6F67499; Tue, 11 Jul 2000 21:31:06 +0900 (JST) (envelope-from ume@bisd.hitachi.co.jp) Message-Id: <200007111231.e6BCV6F67499@plum.ssr.bisd.hitachi.co.jp> To: kris@FreeBSD.org Cc: arch@freebsd.org, net@freebsd.org, jkh@freebsd.org Subject: Re: Merge of KAME code From: Hajimu UMEMOTO In-Reply-To: References: X-Mailer: xcite1.20> Mew version 1.94.2 on XEmacs 21.1 (Bryce Canyon) X-PGP-Fingerprint: D3 3D D3 54 88 13 DE 22 3F 31 C4 4D A1 08 84 7B X-PGP-Public-Key: http://www.imasy.org/~ume/ume@bisd.hitachi.co.jp.asc X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 4.0-STABLE Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Jul 2000 21:31:05 +0900 X-Dispatcher: imput version 20000414(IM141) Lines: 27 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> On Tue, 11 Jul 2000 03:56:15 -0700 (PDT) >>>>> kris@FreeBSD.org (Kris Kennaway) said: kris> I'm still nervous about merging back the libc changes because (as kris> demonstrated already) they have a larger chance to affect IPv4 operation. kris> Umemoto-san, do you have any opinions about the wisdom of this? The merges to res_init.c, res_send.c and getaddrinfo.c before merging latest KAME issue is aready MFCed. Though, the change to getaddrinfo.c is slightly big, it corrects the behavior of mapped address and saves IPv4 users. I believe the problem of DNS IPv6 transport support was gone and I've never heared the problem anymore. DNS IPv6 transport is desireble for IPv6 users to live under IPv6 only environment. I wrote IPv6 code for installer and intend to commit it for 4.1-RELEASE. It supports installation under IPv6 only environment. It requires DNS IPv6 transport. I think other parts are no problem for IPv4 users. There are some changes which are not merged into 5.0-CURRENT yet. I think such parts are rather experimental and shouldn't be merged in this time. -- Hajimu UMEMOTO @ Business Solution System Development Div., Hitachi Ltd. E-Mail: ume@bisd.hitachi.co.jp ume@mahoroba.org ume@FreeBSD.org URL: http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 6:58:35 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 1134D37C25F; Tue, 11 Jul 2000 06:58:24 -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 JAA64577; Tue, 11 Jul 2000 09:58:22 -0400 (EDT) (envelope-from wollman) Date: Tue, 11 Jul 2000 09:58:22 -0400 (EDT) From: Garrett Wollman Message-Id: <200007111358.JAA64577@khavrinen.lcs.mit.edu> To: Kris Kennaway Cc: net@FreeBSD.ORG Subject: Merge of KAME code In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > If anyone has problems with the new KAME they've been keeping to > themselves, or intends to exercise some kind of veto, please let me know! I don't have any machines running current -current right now, but I'd like to give my strong support for this plan. Functioning IPsec with IKE is going to become a necessity in the very near future, and if we desire to maintain our momentum it's necessary to support both in the active release train. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 8:39:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 4A9FA37B988; Tue, 11 Jul 2000 08:39:42 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id AAA05864; Wed, 12 Jul 2000 00:39:41 +0900 (JST) To: Kris Kennaway Cc: arch@freebsd.org, net@freebsd.org, jkh@freebsd.org, Hajimu UMEMOTO In-reply-to: kris's message of Tue, 11 Jul 2000 03:56:15 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Merge of KAME code From: itojun@iijlab.net Date: Wed, 12 Jul 2000 00:39:41 +0900 Message-ID: <5862.963329981@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >With the exception of the rcmd_af() bug found by Peter, and missing >functionality in IPv6 multicast (see recent post to -net by itojun) I >haven't heard of any problems with the new code. it's already in the main trunc. sys/net/if_ethersubr.c revision 1.79. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 8:55:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by hub.freebsd.org (Postfix) with ESMTP id 5A8AB37B637 for ; Tue, 11 Jul 2000 08:55:48 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from sv.Go2France.com [212.73.210.79] by mail.Go2France.com with ESMTP (SMTPD32-6.03) id A37661D005C; Tue, 11 Jul 2000 17:55:34 +0200 Message-Id: <4.3.2.7.2.20000711174522.03075a20@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2000 17:53:24 +0200 To: freebsd-net@freebsd.org From: Len Conrad Subject: Re: Merge of KAME code In-Reply-To: <200007111358.JAA64577@khavrinen.lcs.mit.edu> 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 >Functioning IPsec with IKE is going to become a necessity in the very near >future, and if we >desire to maintain our momentum it's necessary to support both in the >active release train. For the common situ of one-to-many tunneling, I hope that the "one" (server) gets some hardware-assist for IPsec encryption to keep up with the many tunnels. That couple with the many's running FBSD + IPsec would be a winner with industrial capacity. Has anybody benchmarked or simulated how many tunnels and bits/sec one software-only FreeBSD IPsec server can support? Len Len http://BIND8NT.MEIway.com: ISC BIND 8 installable binary for NT4 http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 10:22: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from euler.ece.iisc.ernet.in (euler.ece.iisc.ernet.in [144.16.64.198]) by hub.freebsd.org (Postfix) with ESMTP id 0DC3A37C078 for ; Tue, 11 Jul 2000 10:21:52 -0700 (PDT) (envelope-from pandu@euler.ece.iisc.ernet.in) Received: from localhost (pandu@localhost) by euler.ece.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA23971; Tue, 11 Jul 2000 14:32:17 +0530 Date: Tue, 11 Jul 2000 14:32:17 +0530 (IST) From: Sira Panduranga Rao To: Andreas Klemm Cc: zebra@zebra.org, freebsd-net@freebsd.org Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all In-Reply-To: <20000711084817.A6604@titan.klemm.gtn.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 Hi, I think the problem is in your options. In your hello (options=70 ,i.e, 0x46 => u have the O-bit , MC-bit and E-bit set in the OSPF options field). Cisco doesn't not support MOSPF (MC-bit and maybe not O-bit...I would prefer a CISCO person to correct me if i am wrong in this.) Also which ver. of CISCO are using. In the Cisco option field i do not see the DC-bit set? Zebra doesn't support Opaque LSAs or MOSPF yet. The options don't match and so probably Cisco rejects your Hello. Kindly correct me if i am wrong. Bye, Regards Panduranga On Tue, 11 Jul 2000, Andreas Klemm wrote: > OSPF died with > > titan-ospf# conf t > titan-ospf(config)# router ospf > OSPF: Router-ID[OLD:0.0.0.0]: Update > OSPF: Router-ID[NEW:172.16.2.1]: Update > titan-ospf(config-router)# redistribute connected > titan-ospf(config-router)# redistribute static metric 50 > titan-ospf(config-router)# network 172.16.2.0/24 area 0 > OSPF: interface xl0 join AllSPFRouters Multicast group. > titan-ospf(config-router)# OSPF: LSA[Refresh]: Timer (router-LSA Refresh expire)OSPF: Z: counting fully adjacent virtual neighbors in area 0.0.0.0 > OSPF: Z: there are 0 of them > OSPF: new_lsdb_insert: Newly install > OSPF: SPF: calculation timer scheduled > OSPF: SPF: calculation timer delay = 1572866 > > titan-ospf(config-router)# OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: NSM[xl0:0.0.0.0]: start > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > > titan-ospf(config-router)# network 172.16.2.0/24 area OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > > titan-ospf(config-router)# end > titan-ospf# sh ip ospf neigh > > Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL > 172.16.200.2 100 Init/DROther 00:00:32 172.16.2.2 xl0 0 0 0 > titan-ospf# OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: DR-Election[1st]: Backup 0.0.0.0 > OSPF: DR-Election[1st]: DR 0.0.0.0 > OSPF: DR-Election[2nd]: Backup 0.0.0.0 > OSPF: DR-Election[2nd]: DR 0.0.0.0 > Connection closed by foreign host. > [1] + Done ethereal > root@titan{522} $ cd /var/lo > > > Cisco never shows neighbor... > > I don't get OSPF running on FreeBSD 5.0 (-current), > no matter what I do. > > Some other people running zebra on -current ??? > > Andreas /// > > > ! > ! Zebra configuration saved from vty > ! 2000/07/11 08:38:51 > ! > hostname titan-ospf > password c > enable password c > log file /var/log/zebra-ospfd.log > log stdout > log record-priority > ! > ! > ! > interface xl0 > ! > interface ed0 > ! > interface lo0 > ! > router ospf > redistribute connected > redistribute static metric 50 > network 172.16.2.0/24 area 0 > ! > line vty > exec-timeout 0 0 > ! > > > ! > ! Zebra configuration saved from vty > ! 2000/06/27 19:27:50 > ! > hostname titan-zebra > password c > enable password c > log file /var/log/zebra.log > log record-priority > service advanced-vty > ! > interface xl0 > description DMZ > ! > interface ed0 > description internal > ! > interface ppp0 > ! > interface lo0 > description loopback > ! > interface gif0 > ! > interface gif1 > ! > interface gif2 > ! > interface gif3 > ! > interface stf0 > ! > interface faith0 > ! > line vty > exec-timeout 0 0 > ! > > -- > Andreas Klemm http://people.FreeBSD.ORG/~andreas > http://www.freebsd.org/~fsmp/SMP/SMP.html > powered by Symmetric MultiProcessor FreeBSD > New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 10:29:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 5164437B577 for ; Tue, 11 Jul 2000 10:29:32 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA04105; Tue, 11 Jul 2000 10:29:13 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200007111729.KAA04105@gndrsh.dnsmgr.net> Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all In-Reply-To: <20000711084817.A6604@titan.klemm.gtn.com> from Andreas Klemm at "Jul 11, 2000 08:48:17 am" To: zebra@dml.com Date: Tue, 11 Jul 2000 10:29:12 -0700 (PDT) Cc: zebra@zebra.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 Due to the fact that BSD unix's won't send any multicast packets until the have a multicast route of some form you have to do this: route add 224.0.0.5 127.0.0.1 route add 224.0.0.6 127.0.0.1 Before you start ospfd, I show command line route add's above, you can also do it with zebra static routes. > OSPF died with > > titan-ospf# conf t > titan-ospf(config)# router ospf > OSPF: Router-ID[OLD:0.0.0.0]: Update > OSPF: Router-ID[NEW:172.16.2.1]: Update > titan-ospf(config-router)# redistribute connected > titan-ospf(config-router)# redistribute static metric 50 > titan-ospf(config-router)# network 172.16.2.0/24 area 0 > OSPF: interface xl0 join AllSPFRouters Multicast group. > titan-ospf(config-router)# OSPF: LSA[Refresh]: Timer (router-LSA Refresh expire)OSPF: Z: counting fully adjacent virtual neighbors in area 0.0.0.0 > OSPF: Z: there are 0 of them > OSPF: new_lsdb_insert: Newly install > OSPF: SPF: calculation timer scheduled > OSPF: SPF: calculation timer delay = 1572866 > > titan-ospf(config-router)# OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: NSM[xl0:0.0.0.0]: start > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > > titan-ospf(config-router)# network 172.16.2.0/24 area OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: Z: make_hello: options: 70, int: xl0 > OSPF: Hello sent to [224.0.0.5] via [xl0]. > > titan-ospf(config-router)# end > titan-ospf# sh ip ospf neigh > > Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL > 172.16.200.2 100 Init/DROther 00:00:32 172.16.2.2 xl0 0 0 0 > titan-ospf# OSPF: Hello received from [172.16.200.2] via [xl0] > OSPF: Packet[Hello:RECV]: Options *|*|-|-|-|-|E|* > OSPF: DR-Election[1st]: Backup 0.0.0.0 > OSPF: DR-Election[1st]: DR 0.0.0.0 > OSPF: DR-Election[2nd]: Backup 0.0.0.0 > OSPF: DR-Election[2nd]: DR 0.0.0.0 > Connection closed by foreign host. > [1] + Done ethereal > root@titan{522} $ cd /var/lo > > > Cisco never shows neighbor... > > I don't get OSPF running on FreeBSD 5.0 (-current), > no matter what I do. > > Some other people running zebra on -current ??? > > Andreas /// > > > ! > ! Zebra configuration saved from vty > ! 2000/07/11 08:38:51 > ! > hostname titan-ospf > password c > enable password c > log file /var/log/zebra-ospfd.log > log stdout > log record-priority > ! > ! > ! > interface xl0 > ! > interface ed0 > ! > interface lo0 > ! > router ospf > redistribute connected > redistribute static metric 50 > network 172.16.2.0/24 area 0 > ! > line vty > exec-timeout 0 0 > ! > > > ! > ! Zebra configuration saved from vty > ! 2000/06/27 19:27:50 > ! > hostname titan-zebra > password c > enable password c > log file /var/log/zebra.log > log record-priority > service advanced-vty > ! > interface xl0 > description DMZ > ! > interface ed0 > description internal > ! > interface ppp0 > ! > interface lo0 > description loopback > ! > interface gif0 > ! > interface gif1 > ! > interface gif2 > ! > interface gif3 > ! > interface stf0 > ! > interface faith0 > ! > line vty > exec-timeout 0 0 > ! > > -- > Andreas Klemm http://people.FreeBSD.ORG/~andreas > http://www.freebsd.org/~fsmp/SMP/SMP.html > powered by Symmetric MultiProcessor FreeBSD > New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas > > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 14: 6:39 2000 Delivered-To: freebsd-net@freebsd.org Received: from kx2.lh.net (kx2.lh.net [216.81.128.204]) by hub.freebsd.org (Postfix) with ESMTP id 9923E37B7D5 for ; Tue, 11 Jul 2000 14:06:21 -0700 (PDT) (envelope-from freebsd-q@cambridge.lh.net) Received: from cambridge.lh.net ([216.81.128.29]) by kx2.lh.net (InterMail vK.4.02.00.10 201-232-116-110 license fa447d7e5453d7b15649594624cecde5) with ESMTP id <20000711210432.CCAH353.kx2@cambridge.lh.net> for <@mail.lh.net:freebsd-net@freebsd.org>; Tue, 11 Jul 2000 16:04:32 -0500 Received: from localhost by cambridge.lh.net via ESMTP (8.9.3/970220.SGI.BM.8.8.5) for id VAA10864; Tue, 11 Jul 2000 21:06:11 GMT Date: Tue, 11 Jul 2000 16:06:11 -0500 From: Trumpy To: freebsd-net@freebsd.org Subject: Routed and multiple routes... 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 my situation... I have two nameservers that about 7500 people are looking to for primary name services. Both these boxes are running FreeBSD 3.4-STABLE and need to be renumbered in a new subnet. What I want to do is run two network cards in each machine, connected to the two different subnets (old and new) such that the following conditions are met: 1) All services are reachable via both IPs. (easy part) 2) Two default routes, one out to a router on the new subnet, and one out to a router on the old subnet, the first more preferenced such that if it goes down, default traffic will start going out to a router on the old subnet. I've tried running routed, but when I enter the default routes in /etc/gateways and then start routed, I get: Jul 11 16:06:47 god routed[26243] unreachable gateway 192.168.0.254 in /etc/gateways When, in fact, I can *ping* 192.168.0.254 from the FreeBSD box, and the subnet and broadcast are most definitely set correctly. Diagram: (192.168.0.0/24 is the new, 10.0.0.0/24 is the old) 192.168.0.254 10.0.0.254 ___________ ___________ | NEW | | OLD | | BORDER |----------------| BORDER | | ROUTER | | ROUTER | |_________| |_________| | | | | (preferred | | route) | ________________ | | | FreeBSD 3.4 | | | | | | 192.168.0.25 -> ------|eth0 eth1|------- <- 10.0.0.25 | | |--------------| Any ideas? Do I need to try gated? Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 14:22:59 2000 Delivered-To: freebsd-net@freebsd.org Received: from security1.noc.flyingcroc.net (security1.noc.flyingcroc.net [207.246.128.54]) by hub.freebsd.org (Postfix) with ESMTP id 4D78C37B91D; Tue, 11 Jul 2000 14:22:48 -0700 (PDT) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by security1.noc.flyingcroc.net (8.9.3/8.9.3) with ESMTP id OAA02393; Tue, 11 Jul 2000 14:22:46 -0700 (PDT) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Tue, 11 Jul 2000 14:22:46 -0700 (PDT) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: freebsd-security@freebsd.org, freebsd-net@freebsd.org Subject: IPF performance data 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 Greetings, Does anyone out there have any data pertaining to possible degradation of tcp performance using IPF? (pre-ruleset/pass all) Thanks. - Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 15: 7:25 2000 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 899FC37B8EA; Tue, 11 Jul 2000 15:07:22 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id PAA97953; Tue, 11 Jul 2000 15:07:22 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Tue, 11 Jul 2000 15:07:22 -0700 (PDT) From: Kris Kennaway To: Len Conrad Cc: freebsd-net@freebsd.org Subject: Re: Merge of KAME code In-Reply-To: <4.3.2.7.2.20000711174522.03075a20@mail.Go2France.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 Tue, 11 Jul 2000, Len Conrad wrote: > Has anybody benchmarked or simulated how many tunnels and bits/sec one > software-only FreeBSD IPsec server can support? My P120 can do about 2.5MBps :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 15:33:45 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 7A40037B74E; Tue, 11 Jul 2000 15:33:43 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id PAA39900; Tue, 11 Jul 2000 15:33:32 -0700 (PDT) From: Archie Cobbs Message-Id: <200007112233.PAA39900@bubba.whistle.com> Subject: ether_ifattach()/ether_ifdetach() patch To: freebsd-net@freebsd.org Date: Tue, 11 Jul 2000 15:33:32 -0700 (PDT) Cc: julian@elischer.org, csg@waterspout.com, ache@freebsd.org, wpaul@freebsd.org, imp@village.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 To any interested parties, here is a patch to review. This changes all ethernet drivers to only call ether_ifattach() and ether_ifdetach(), consolidating some common actions, namely, calls to if_attach(), bpfattach(), ng_ether_attach(), if_detach(), bpfdetach(), and ng_ether_detach(). This also fixes the problem where detaching an ethernet interface previously used for ng_ether(4) would panic (which resulted from fixing the build to not require 'device ether' (which resulted from making ng_ether(4) a loadable KLD)). ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.1 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 Tue Jul 11 15:46: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id A534F37B842 for ; Tue, 11 Jul 2000 15:45:51 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id AAA25373; Wed, 12 Jul 2000 00:45:17 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id AAA05460; Wed, 12 Jul 2000 00:42:31 +0200 (CEST) (envelope-from andreas) Date: Wed, 12 Jul 2000 00:42:30 +0200 From: Andreas Klemm To: "Rodney W. Grimes" Cc: zebra@dml.com, zebra@zebra.org, freebsd-net@FreeBSD.ORG Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all Message-ID: <20000712004230.A4919@titan.klemm.gtn.com> References: <20000711084817.A6604@titan.klemm.gtn.com> <200007111729.KAA04105@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007111729.KAA04105@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Tue, Jul 11, 2000 at 10:29:12AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jul 11, 2000 at 10:29:12AM -0700, Rodney W. Grimes wrote: > Due to the fact that BSD unix's won't send any multicast packets until > the have a multicast route of some form you have to do this: > > route add 224.0.0.5 127.0.0.1 > route add 224.0.0.6 127.0.0.1 > > Before you start ospfd, I show command line route add's above, you > can also do it with zebra static routes. I'm using that ,,,, # multicast and other routes route add 172.16.1.1 -interface lo0 route add 172.16.2.1 -interface lo0 route add 224.0.0.0/24 -interface lo0 Now I added: route add 224.0.0.5 127.0.0.1 route add 224.0.0.6 127.0.0.1 root@titan{542} $ netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 172.16.2.2 UGSc 3 12 xl0 127.0.0.1 127.0.0.1 UH 8 1044 lo0 172.16.1/24 link#2 UC 0 0 ed0 => 172.16.1.1 lo0 UHS 0 0 lo0 172.16.1.255 ff:ff:ff:ff:ff:ff UHLWb 2 63 ed0 172.16.2/24 link#1 UC 0 0 xl0 => 172.16.2.1 lo0 UHS 3 30 lo0 172.16.2.2 0:e0:b0:55:56:3 UHLW 7 696 xl0 996 172.16.2.200 link#1 UHLW 1 2 xl0 => 172.16.2.255 ff:ff:ff:ff:ff:ff UHLWb 3 126 xl0 172.16.200.1 172.16.200.1 UH 0 0 lo0 224 lo0 US 0 694 lo0 224.0.0.5 127.0.0.1 UGHS 1 116 lo0 224.0.0.6 127.0.0.1 UGHS 1 18 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::%ed0/64 link#2 UC ed0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%ed0/32 link#2 UC ed0 ff02::%lo0/32 fe80::1%lo0 UC lo0 root@titan{543} $ ethereal shows, that no OSPF hello packet will be sent out on my xl0 interface .... The Cisco (running 12.1(2)T sends hellos out. What else could be wrong. Does somebody run -current ??? Here kernel config file and rc.conf... machine i386 cpu I686_CPU ident TITAN maxusers 64 hints "TITAN.hints" #Default places to look for devices. options MSGBUF_SIZE=40960 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options INCLUDE_CONFIG_FILE # Include this file in kernel options ROOTDEVNAME=\"ufs:ad4s2a\" options RANDOMDEV options INET #InterNETworking options INET6 #IPv6 communications protocols options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about dropped packets options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPDIVERT #divert sockets options IPSTEALTH #support for stealth forwarding options DUMMYNET options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options FFS_EXTATTR options SOFTUPDATES options MFS #Memory Filesystem options MSDOSFS #MSDOS Filesystem options NTFS #NT File System options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options FDESC #File descriptor filesystem options KERNFS #Kernel filesystem options NULLFS #NULL filesystem options UMAPFS #UID map filesystem options UNION #Union filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AUTO_EOI_1 options AUTO_EOI_2 options BLKDEV_IOSIZE=8192 options MROUTING # Multicast routing options PQ_HUGECACHE # color for 1024k/16k cache options COMPAT_LINUX # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=8 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa device pci #options COMPAT_OLDISA # compatability shims for lnc, fe, le #options COMPAT_OLDPCI # compatability shims for lnc, vx # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_ALLOW_MEMIO # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 device atkbd device psm device vga # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 # Floating point support - do not disable. device npx # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed # Sound device pcm # Pseudo devices - the number indicates how many units to allocated. device loop # Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp 1 # Kernel PPP options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpf) device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device gif 4 # IPv6 and IPv4 tunneling device faith 1 # IPv6-to-IPv4 relaying (translation) device vn #Vnode driver (turns a file into a device) device snp #Snoop device - to look at pty/vty/etc.. #device vlan 1 #VLAN support # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # This file now contains just the overrides from /etc/defaults/rc.conf # please make all changes to this file. # -- sysinstall generated deltas -- # # startup files... local_startup="/home/local/etc/rc.d /usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # network interface card configuration hostname="titan.klemm.gtn.com" network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. ifconfig_lo0_alias0="inet 172.16.200.1 netmask 0xffffffff" ifconfig_xl0="inet 172.16.2.1 netmask 255.255.255.0" ifconfig_ed0="inet 172.16.1.1 netmask 255.255.255.0" # OSPF Routing defaultrouter="172.16.2.2" router_enable="YES" router="/usr/local/sbin/zebractl" router_flags="start" # TCP/IP gateway_enable="YES" named_enable="YES" # Run named, the DNS server (or NO). named_flags="" # Flags for named #named_flags="-u bind -g bind" # Flags for named tcp_extensions="NO" # Set to YES to turn on RFC1323 extensions. # syslog syslogd_enable="YES" # Run syslog daemon (or NO). syslogd_flags="" # Flags to syslogd (if enabled). # Network Time ntpdate_enable="YES" # Run ntpdate to sync time on boot (or NO). ntpdate_flags="ntp0.fau.de ntp1.fau.de ntp2.fau.de" # Flags to ntpdate (if enabled). xntpd_enable="YES" # Run ntpd Network Time Protocol (or NO). # Security firewall_enable="YES" firewall_type="open" # SSH sshd_enable="YES" # Enable sshd # NAT (Network Address Translation) natd_enable="YES" # Enable natd (if firewall_enable == YES). natd_program="/sbin/natd" # path to natd, if you want a different one. natd_flags="-log -s -m" # Additional flags for natd. natd_interface="xl0" # Public interface or IPaddress to use. # Network services nfs_server_enable="YES" nfs_client_enable="YES" amd_enable="YES" # Run amd service with $amd_flags (or NO). lpd_enable="YES" # Run the line printer daemon. sendmail_flags="-bd -q1m" # Flags to sendmail (if enabled) # Emulations linux_enable="YES" # Console configuration moused_enable="NO" saver="logo" font8x8="iso-8x8" font8x14="iso-8x14" font8x16="iso-8x16" scrnmap="iso-8859-1_to_cp437" keyrate="fast" keymap="german.iso" -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 16: 0: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 92E6C37B86C; Tue, 11 Jul 2000 15:59:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from harare-34.budapest.interware.hu ([195.70.50.34] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13C90M-0004Kv-00; Wed, 12 Jul 2000 00:59:54 +0200 Message-ID: <396BA6D8.15FB7483@elischer.org> Date: Tue, 11 Jul 2000 15:59:36 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org, csg@waterspout.com, ache@freebsd.org, wpaul@freebsd.org, imp@village.org Subject: Re: ether_ifattach()/ether_ifdetach() patch References: <200007112233.PAA39900@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: > > To any interested parties, here is a patch to review. > > This changes all ethernet drivers to only call ether_ifattach() > and ether_ifdetach(), consolidating some common actions, namely, > calls to if_attach(), bpfattach(), ng_ether_attach(), if_detach(), > bpfdetach(), and ng_ether_detach(). > > This also fixes the problem where detaching an ethernet interface > previously used for ng_ether(4) would panic (which resulted from > fixing the build to not require 'device ether' (which resulted > from making ng_ether(4) a loadable KLD)). > > ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.1 The constant 1 (2nd argument to ether_attach) should be defined as something meaningful in the ethernet include file. e.g. USE_BPF vs NO_BPF Ether definitions should be removed from if_var.h and also put in an ether specific include file, but that would be a different patch. > > Thanks, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 16: 8:30 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 892EC37B979 for ; Tue, 11 Jul 2000 16:08:21 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id RAA82914; Tue, 11 Jul 2000 17:08:15 -0600 (MDT) Date: Tue, 11 Jul 2000 17:08:15 -0600 (MDT) From: Nick Rogness To: Trumpy Cc: freebsd-net@freebsd.org Subject: Re: Routed and multiple routes... 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, 11 Jul 2000, Trumpy wrote: > 2) Two default routes, one out to a router on the new > subnet, and one out to a router on the old subnet, the > first more preferenced such that if it goes down, default > traffic will start going out to a router on the old subnet. I have had this problem before with 2 default routes to the same network for different gateways. Read more below. > I've tried running routed, but when I enter the default > routes in /etc/gateways and then start routed, I get: > > Jul 11 16:06:47 god routed[26243] unreachable gateway > 192.168.0.254 in /etc/gateways > Haven't tried this with routed. > > 192.168.0.254 10.0.0.254 > ___________ ___________ > | NEW | | OLD | > | BORDER |----------------| BORDER | > | ROUTER | | ROUTER | > |_________| |_________| > | | > | | > (preferred | | > route) | ________________ | > | | FreeBSD 3.4 | | > | | | | > 192.168.0.25 -> ------|eth0 eth1|------- <- 10.0.0.25 > | | > |--------------| > > Any ideas? Do I need to try gated? Gated may still not help much (haven't tried it). This is what I have done in the past (easier): # Prefered gateway route add -net 0.0.0.0 -netmask 128.0.0.0 192.168.0.254 route add -net 128.0.0.0 -netmask 128.0.0.0 192.168.0.254 #Backup gateway route add -net 0.0.0.0 -netmask 0.0.0.0 10.0.0.254 This will work because the first 2 routes are more specific than the backup route...so it is the preferred route. They still point to basically the same network, one is a supernetted version of the 2 smaller networks. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 16:46:40 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 8EB1837B786; Tue, 11 Jul 2000 16:46:37 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id QAA41027; Tue, 11 Jul 2000 16:46:03 -0700 (PDT) From: Archie Cobbs Message-Id: <200007112346.QAA41027@bubba.whistle.com> Subject: Re: ether_ifattach()/ether_ifdetach() patch In-Reply-To: <396BA6D8.15FB7483@elischer.org> from Julian Elischer at "Jul 11, 2000 03:59:36 pm" To: julian@elischer.org (Julian Elischer) Date: Tue, 11 Jul 2000 16:46:03 -0700 (PDT) Cc: freebsd-net@freebsd.org, csg@waterspout.com, ache@freebsd.org, wpaul@freebsd.org, imp@village.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: > > To any interested parties, here is a patch to review. > > > > This changes all ethernet drivers to only call ether_ifattach() > > and ether_ifdetach(), consolidating some common actions, namely, > > calls to if_attach(), bpfattach(), ng_ether_attach(), if_detach(), > > bpfdetach(), and ng_ether_detach(). > > > > This also fixes the problem where detaching an ethernet interface > > previously used for ng_ether(4) would panic (which resulted from > > fixing the build to not require 'device ether' (which resulted > > from making ng_ether(4) a loadable KLD)). > > > > ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.1 > > The constant 1 (2nd argument to ether_attach) should be > defined as something meaningful in the ethernet include file. > e.g. USE_BPF vs NO_BPF Thanks for the comment.. here's a revised version: ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.2 -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 Jul 11 16:56:32 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 4DD7337B97D; Tue, 11 Jul 2000 16:56:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from harare-34.budapest.interware.hu ([195.70.50.34] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13C9ss-0006ou-00; Wed, 12 Jul 2000 01:56:14 +0200 Message-ID: <396BB40C.41C67EA6@elischer.org> Date: Tue, 11 Jul 2000 16:55:56 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org, csg@waterspout.com, ache@freebsd.org, wpaul@freebsd.org, imp@village.org Subject: Re: ether_ifattach()/ether_ifdetach() patch References: <200007112346.QAA41027@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: > > Julian Elischer writes: > > > To any interested parties, here is a patch to review. > > > > > > This changes all ethernet drivers to only call ether_ifattach() > > > and ether_ifdetach(), consolidating some common actions, namely, > > > calls to if_attach(), bpfattach(), ng_ether_attach(), if_detach(), > > > bpfdetach(), and ng_ether_detach(). > > > > > > This also fixes the problem where detaching an ethernet interface > > > previously used for ng_ether(4) would panic (which resulted from > > > fixing the build to not require 'device ether' (which resulted > > > from making ng_ether(4) a loadable KLD)). > > > > > > ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.1 > > > > The constant 1 (2nd argument to ether_attach) should be > > defined as something meaningful in the ethernet include file. > > e.g. USE_BPF vs NO_BPF > > Thanks for the comment.. here's a revised version: > > ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.2 ok so you use ETHER_BPF_SUPPORTED... but I never saw a case where it was not supported.. why is it needed? > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 19: 4:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by hub.freebsd.org (Postfix) with ESMTP id A2F2037B673 for ; Tue, 11 Jul 2000 19:04:04 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e6C22jQ07095 for ; Wed, 12 Jul 2000 11:02:45 +0900 (JST) To: net@freebsd.org Subject: candidate fix to INET6 if detach problem X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Wed, 12 Jul 2000 11:02:45 +0900 Message-ID: <7093.963367365@localhost> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org if you have FreeBSD-current on laptop, please try the following diff: http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/net/if.c.diff?r1=1.1&r2=1.2 and let me know if it solves FreeBSD PR 17909 (panic on pccard interface removal, if you have used IPv6 on the interface). i'm still wondering if this should go into FreeBSD-current (and 4STABLE) or not, so your report will be very important. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 20:12: 4 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 E142F37BB53; Tue, 11 Jul 2000 20:11:52 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id UAA41826; Tue, 11 Jul 2000 20:10:35 -0700 (PDT) From: Archie Cobbs Message-Id: <200007120310.UAA41826@bubba.whistle.com> Subject: Re: ether_ifattach()/ether_ifdetach() patch In-Reply-To: <396BB40C.41C67EA6@elischer.org> from Julian Elischer at "Jul 11, 2000 04:55:56 pm" To: julian@elischer.org (Julian Elischer) Date: Tue, 11 Jul 2000 20:10:35 -0700 (PDT) Cc: freebsd-net@freebsd.org, csg@waterspout.om, ache@freebsd.org, wpaul@freebsd.org, imp@village.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: > > ftp://ftp.whistle.com/pub/archie/misc/ETHERATTACH.patch.2 > ok so you use ETHER_BPF_SUPPORTED... > > but I never saw a case where it was not supported.. > why is it needed? So drivers explicitly have to declare it.. otherwise it's not obvious that supporting BPF is required. -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 Jul 11 21:50:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from amazhan.bitstream.net (amazhan.bitstream.net [216.243.128.132]) by hub.freebsd.org (Postfix) with SMTP id 853BC37B9D4 for ; Tue, 11 Jul 2000 21:50:17 -0700 (PDT) (envelope-from airboss@bitstream.net) Received: (qmail 28750 invoked by uid 79); 12 Jul 2000 04:50:16 -0000 Received: from dmitri-dsl.bitstream.net (216.243.168.18) by mail.bitstream.net with SMTP; 12 Jul 2000 04:50:16 -0000 Date: Tue, 11 Jul 2000 23:57:19 -0500 (CDT) From: Dan Debertin To: freebsd-net@freebsd.org Subject: multicast forwarding and OSPF 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'm running FreeBSD-4.0-STABLE on my set of firewalls, each of which are equipped with two fxp cards. On each side of those firewalls, I have a router that runs OSPF. I can see, via tcpdump, that there are hellos happening on either side of the firewalls, but none of them are getting through to the other side -- i.e. I don't see the hellos from the internal router coming out the external interface, and vice versa. This happens regardless of whether I have firewalling enabled or not, so I'm sure it's not my ipfw ruleset. The first thing that occurs to me is that there's something I'm missing as far as kernel configuration or sysctls. I compiled with options MROUTING, but that didn't seem to do the trick. Do i need to run mrouted? Please advise ... Thanks. ~Dan D. -- __________________________________________________________________ -- The trouble with doing something right the first time is that -- nobody appreciates how difficult it was. ++ Dan Debertin ++ Senior Systems Administrator ++ Bitstream Underground, LLC ++ airboss@bitstream.net ++ (612)321-9290 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 22:17: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 275A437BDB9 for ; Tue, 11 Jul 2000 22:16:56 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA14542; Wed, 12 Jul 2000 14:16:49 +0900 (JST) To: Dan Debertin Cc: freebsd-net@freebsd.org In-reply-to: airboss's message of Tue, 11 Jul 2000 23:57:19 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: multicast forwarding and OSPF From: itojun@iijlab.net Date: Wed, 12 Jul 2000 14:16:49 +0900 Message-ID: <14540.963379009@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm running FreeBSD-4.0-STABLE on my set of firewalls, each of which are >equipped with two fxp cards. On each side of those firewalls, I have a >router that runs OSPF. I can see, via tcpdump, that there are hellos >happening on either side of the firewalls, but none of them are getting >through to the other side -- i.e. I don't see the hellos from the internal >router coming out the external interface, and vice versa. This happens >regardless of whether I have firewalling enabled or not, so I'm sure it's >not my ipfw ruleset. IIRC OSPF hello does not go across the routers. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jul 11 23:24:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from fork.computel.sk (fork.computel.sk [195.28.96.96]) by hub.freebsd.org (Postfix) with ESMTP id 00E1237BBEC for ; Tue, 11 Jul 2000 23:24:25 -0700 (PDT) (envelope-from pavol_adamec@tempest.sk) Received: from tempest.sk (t74.tempest.sk [195.28.100.74]) by fork.computel.sk with ESMTP id IAA06839 for ; Wed, 12 Jul 2000 08:24:15 +0200 Message-ID: <396C0F11.F561E688@tempest.sk> Date: Wed, 12 Jul 2000 08:24:17 +0200 From: Pavol Adamec Organization: Tempest X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Merge of KAME code References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've done last week some tests with FBSD on P200 + racoon, the other side was TimeStep's Permit 4520 (max IPsec throughput at 10Mbps). Netperf in TCP_STREAM with messages over 512 bytes in size resulted in 3.06 Mbps. I've tested just DES+SHA1 IPsec tunneled SA. paul Kris Kennaway wrote: > > On Tue, 11 Jul 2000, Len Conrad wrote: > > > Has anybody benchmarked or simulated how many tunnels and bits/sec one > > software-only FreeBSD IPsec server can support? > > My P120 can do about 2.5MBps :-) > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > > 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 Wed Jul 12 0:15:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from minbar.b5.nu (minbar.b5.nu [203.43.74.97]) by hub.freebsd.org (Postfix) with ESMTP id 8011237BC20 for ; Wed, 12 Jul 2000 00:15:39 -0700 (PDT) (envelope-from claus@b5.nu) Received: (from claus@localhost) by minbar.b5.nu (8.9.3/8.9.3) id RAA87069; Wed, 12 Jul 2000 17:15:28 +1000 (EST) (envelope-from claus@b5.nu) From: Claus Endres Message-Id: <200007120715.RAA87069@minbar.b5.nu> Subject: Re: multicast forwarding and OSPF To: airboss@bitstream.net (Dan Debertin) Date: Wed, 12 Jul 2000 17:15:28 +1000 (EST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: from "Dan Debertin" at Jul 11, 2000 11:57:19 PM X-Mailer: ELM [version 2.5 PL3] 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 Multicasts do not get routed across the two fxp interface cards without some agent that understands the multicast protocol involved. In your case you need an agent understanding OSPF. The simplest one for that is gated. So you need to install gated (e.g. from the ports collection), configure OSPF on both interfaces (in /etc/gated.conf), and your FreeBSD system will become a router talking routing protocols. Claus. > > I'm running FreeBSD-4.0-STABLE on my set of firewalls, each of which are > equipped with two fxp cards. On each side of those firewalls, I have a > router that runs OSPF. I can see, via tcpdump, that there are hellos > happening on either side of the firewalls, but none of them are getting > through to the other side -- i.e. I don't see the hellos from the internal > router coming out the external interface, and vice versa. This happens > regardless of whether I have firewalling enabled or not, so I'm sure it's > not my ipfw ruleset. > > The first thing that occurs to me is that there's something I'm missing as > far as kernel configuration or sysctls. I compiled with options MROUTING, > but that didn't seem to do the trick. Do i need to run mrouted? Please > advise ... Thanks. > > ~Dan D. > -- > __________________________________________________________________ > -- The trouble with doing something right the first time is that > -- nobody appreciates how difficult it was. > > ++ Dan Debertin > ++ Senior Systems Administrator > ++ Bitstream Underground, LLC > ++ airboss@bitstream.net > ++ (612)321-9290 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- ======================================================== Claus Endres | e-mail: claus@b5.nu | Fax: +61-3-59982540 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 0:21:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 1E10837B736 for ; Wed, 12 Jul 2000 00:21:37 -0700 (PDT) (envelope-from mike@adept.org) Received: by snafu.adept.org (Postfix, from userid 1000) id 09E899EE01; Wed, 12 Jul 2000 00:21:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id EB6CD9B001 for ; Wed, 12 Jul 2000 00:21:35 -0700 (PDT) Date: Wed, 12 Jul 2000 00:21:35 -0700 (PDT) From: Mike Hoskins To: freebsd-net@freebsd.org Subject: BSD Firewall 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 Hello, I'm relatively new to BSD-based firewalling, and have a couple questions... Hopefully, this is the right forum. I'm running 4.0-STABLE with ipfw... FreeBSD snafu.adept.org 4.0-STABLE FreeBSD 4.0-STABLE #0: Sat Jul 8 01:18:17 PDT 2000 mike@snafu.adept.org:/usr/src/sys/compile/SNAFU i386 I have a privately addressed /24 on fxp1, and a DSL connection on fxp0. The box also runs NATD. My ruleset is as follows: 00100 divert 8668 ip from any to any via fxp0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 01000 check-state 01100 allow ip from 63.201.63.44 to any keep-state 01200 allow ip from 192.168.0.0/24 to any keep-state 01300 allow tcp from any to 63.201.63.44 80 setup 01400 allow tcp from any to 63.201.63.44 443 setup 01500 allow tcp from any to 63.201.63.44 22 setup 01600 allow tcp from any to 63.201.63.44 25 setup 01700 allow tcp from 206.136.108.7 to 63.201.63.44 53 setup 01800 allow udp from 206.136.108.7 to 63.201.63.44 53 01900 allow udp from 63.201.63.44 53 to any 02000 allow tcp from 204.152.184.72 to 63.201.63.44 123 setup 02100 allow udp from 204.152.184.72 to 63.201.63.44 123 02200 allow tcp from any to 63.201.63.44 113 setup 02300 allow udp from any to 63.201.63.44 113 65535 deny ip from any to any 1000-2300 are my rules, the rest are system defaults. The intent is to allow anything out (statefully), since it's a small, 'trusted' LAN, and allow only HTTP, SSL, SSH, SMTP, DNS, NTP and IDENT in. This seems to work... but, having never played with ipfw before AND only finding decent refernece in ipfw(8), does this look ok? I looked for the old ipfw examples site, but it seems to have moved. One problem was the existence of example rules w/o an explanation of why the rule was needed or what it really did... Primarily, I had some confusion over: In order to protect a site from flood attacks involving fake TCP packets, it is safer to use dynamic rules: ipfw add check-state ipfw add deny tcp from any to any established ipfw add allow tcp from my-net to any setup keep-state Ok... I want to be protected from flood attacks (and this, indeed, seems to be the problem noted below), but why is the deny placed before the allow? I'd thought the 'rule chain' was inspected on a first-match basis. I didn't understand this, and, as best I remember, this didn't work for me... so I made modifications (remove rule, test, add rule, test, etc...) until something both worked and looked 'sane'. Furthermore, inspection of /etc/rc.firewall yielded confusion when I noted that the 'simple' firewall explicitly adds 'deny' statements... Is this really needed when the final rule in the chain is to deny all? I noticed the following warnin in ipfw(8) relating to stateful operation: BEWARE: stateful rules can be subject to denial-of-service attacks by a SYN-flood which opens a huge number of dynamic rules. The effects of such attacks can be partially limited by acting on a set of sysctl(8) variables which control the operation of the firewall. Is said 'SYN-flood' externally originated or internally? Like I mentioned above, I don't have to worry about internal hosts... As for external... How do the kernel options TCP_DROP_SYNFIN and TCP_RESTRICT_RST handle SYN floods? A day or so after setting up ipfw, I started notcing that when I would ssh to my gw from work, my connection would freeze up... If I opened a new ssh session, it'c connect immediately... but leaving it idle for any time at all (well, 5-10 seconds) would result in another freeze. I have net.inet.icmp.icmplim set to 200, and noticed 'icmp-response bandwidth limit 223/200 pps' in messages... repeated many times. My first thought was some valid service or a misconfiguration of ipfw since I'm new to this... but inspection of ipfw list|wc yielded almost 1000 dynamic rules... most of which, when verified, I could not account for. These were rules from a single, remote IP (technical contacts for supporting network(s) contacted) which I had never heard of... It seems that, somehow, the remote user was 'tricking' the fw into injecting dynamic rules into my chain. System performance was getting slower, and I figured this was the real reason for my ssh freezes. Now... I turned net.inet.ip.fw.dyn_max down to 256, net.inet.ip.fw.dyn_ack_lifetime to 200, flushed and reloaded my ruleset... Now ipfw list|grep for the source IP yields a high number of port 80 rules... Yet I have not accessed the remote host's webserver. This is different than before, however, as the previously generated rules seemed to my random ports. I've just cvsup'd and rebuilt my system... To ensure the recent security release relating to ip options isn't to blame... but I had built after that release... Which leads me to believe there is still an ipfw misconfiguration I'm overlooking. Pointers please... -mrh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 0:34:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8B70737BC4E for ; Wed, 12 Jul 2000 00:34:07 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA07865; Wed, 12 Jul 2000 00:33:47 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200007120733.AAA07865@gndrsh.dnsmgr.net> Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all In-Reply-To: <20000712004230.A4919@titan.klemm.gtn.com> from Andreas Klemm at "Jul 12, 2000 00:42:30 am" To: andreas@klemm.gtn.com (Andreas Klemm) Date: Wed, 12 Jul 2000 00:33:46 -0700 (PDT) Cc: zebra@dml.com, zebra@zebra.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 > On Tue, Jul 11, 2000 at 10:29:12AM -0700, Rodney W. Grimes wrote: > > Due to the fact that BSD unix's won't send any multicast packets until > > the have a multicast route of some form you have to do this: > > > > route add 224.0.0.5 127.0.0.1 > > route add 224.0.0.6 127.0.0.1 > > > > Before you start ospfd, I show command line route add's above, you > > can also do it with zebra static routes. > > I'm using that ,,,, And you even have a default route out your xl0 interface, which should take care of the bug I had seen in the past. Humm... rip out all your 224.x.x.x and those direct -lo0 routes too, just have your xl0 and ed0 link layer routes and a default, then give it a shot. > # multicast and other routes > route add 172.16.1.1 -interface lo0 > route add 172.16.2.1 -interface lo0 You don't need those two, the kernel should do that automagically internally and this may be causing some problems. > route add 224.0.0.0/24 -interface lo0 Rip this out, as the problem should be taken care of by the default route already. > > Now I added: > route add 224.0.0.5 127.0.0.1 > route add 224.0.0.6 127.0.0.1 Rip them out too... just try it with the default route only. No funny stuff with -interface. > > > root@titan{542} $ netstat -rn > Routing tables ... whack ... > ethereal shows, that no OSPF hello packet will be sent out > on my xl0 interface .... The Cisco (running 12.1(2)T sends > hellos out. > > What else could be wrong. Does somebody run -current ??? Sorry... not lately. One other thing to try if ripping all the routes out down to the default doesn't do it is this: route add 224.0.0.0/4 -interface xl0 or route add 224.0.0.0/4 172.16.2.1 One of those should work... if not I'll go pull the -current files out of the repository and read through the multicast output packet path and see if I can see what changed and what magic we need to make it work now. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 1:29:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from snafu.adept.org (adsl-63-201-63-44.dsl.snfc21.pacbell.net [63.201.63.44]) by hub.freebsd.org (Postfix) with ESMTP id 27DE137BCFD for ; Wed, 12 Jul 2000 01:29:39 -0700 (PDT) (envelope-from mike@adept.org) Received: by snafu.adept.org (Postfix, from userid 1000) id BD21B9EE01; Wed, 12 Jul 2000 01:29:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by snafu.adept.org (Postfix) with ESMTP id 7A2939B001 for ; Wed, 12 Jul 2000 01:29:33 -0700 (PDT) Date: Wed, 12 Jul 2000 01:29:33 -0700 (PDT) From: Mike Hoskins To: freebsd-net@freebsd.org Subject: BSD Firewall - II 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 A quick note, Regarding my previous post... Please disregard the part about not understanding the exemplified stateful firewall setup in ipfw(8). Upon using my eyes and reading more carefully, I see that stateful/dynamic rules are checked as soon as a check-state or keep-state line is reached... Sorry for the waste of bandwidth. -mrh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 6:32:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from www.caravan.ru (www.caravan.ru [212.24.52.9]) by hub.freebsd.org (Postfix) with ESMTP id 3F3B337BE35; Wed, 12 Jul 2000 06:32:04 -0700 (PDT) (envelope-from skiv@caravan.ru) Received: from mag.caravan.ru ([212.24.53.226] helo=localhost) by www.caravan.ru with esmtp (Exim 3.14 #1) id 13CMdG-0000AW-00; Wed, 12 Jul 2000 17:32:58 +0400 Date: Wed, 12 Jul 2000 17:33:36 +0400 (MSD) From: "Sergey V. Artjushkin" To: freebsd-net@FreeBSD.ORG Cc: freebsd-isp@FreeBSD.ORG Subject: gre tunnel?? 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 Hello colleagues. I have some questions about tunneling in FreeBSD. I have two routers. On the first of them is installed FreeBSD 4.0 and on the other is Linux (don't remember the version). I need to organize some tunnel between this routers. I tried to use vtund software to do this, but tunnel was not stable. After this I tried to organize IP over IP tunnel with nos-tun software, but I could not make it even between to FreeBSD routers. Both end of tunnel was not ping. The last idea waht I have is that try to organize GRE tunnel between Linux and FreeBSD. How can I do it? How can I add GRE support in my FreeBSD router? What tunnels I can organize in my situation and what is the best way? Thank you for advance. ---------------------------------------------------------------- Sergey Artjushkin ISP Tel: +7 095 203-10-72 "CARAVAN" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 10:28:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from decoy.sfc.keio.ac.jp (decoy.sfc.keio.ac.jp [133.27.84.101]) by hub.freebsd.org (Postfix) with ESMTP id 2736C37BF62; Wed, 12 Jul 2000 10:28:00 -0700 (PDT) (envelope-from say@sfc.wide.ad.jp) Received: from localhost (localhost.sfc.keio.ac.jp [127.0.0.1]) by decoy.sfc.keio.ac.jp (8.9.3/8.9.3) with ESMTP id CAA01372; Thu, 13 Jul 2000 02:27:16 +0900 (JST) (envelope-from say@sfc.wide.ad.jp) To: freebsd-net@FreeBSD.ORG Cc: lconrad@Go2France.com, kris@FreeBSD.ORG Subject: IPsec Performance (Re: Merge of KAME code) From: ARIGA Seiji In-Reply-To: References: <4.3.2.7.2.20000711174522.03075a20@mail.Go2France.com> X-Mailer: Mew version 1.95b3 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-Publickey: http://decoy.sfc.keio.ac.jp/~say/key.txt X-PGP-Fingerprint: 8E 70 AB 20 44 E6 8A 8A 1C 49 B3 30 44 1B B3 BA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000713022715E.say@decoy.sfc.keio.ac.jp> Date: Thu, 13 Jul 2000 02:27:15 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 33 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, On Tue, 11 Jul 2000 15:07:22 -0700 (PDT), Kris Kennaway wrote, : > Has anybody benchmarked or simulated how many tunnels and bits/sec one : > software-only FreeBSD IPsec server can support? : My P120 can do about 2.5MBps :-) I used to benchmarked IPsec performance on following platform with netperf. - PentiumIII 500MHz - 256MB Memory - Intel Ether Express Pro 100 (100Mbps) - FreeBSD 2.2.8 - KAME 19990809 stable - connect two machines directly - IPv4 - IPsec transport mode - ESP with 3DES-CBC - AH with HMAC-SHA1 And the results are about, TCP STREAM TEST UDP STREAM TEST NONE: 60Mbps NONE: 94Mbps AH: 23Mbps AH: 30Mbps ESP: 11Mbps ESP: 11Mbps AH+ESP: 8Mbps AH+ESP: 9Mbps P.S. The same tests with IPv6 produced almost the same results. // ARIGA Seiji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 10:35:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.Go2France.com (ms1.meiway.com [212.73.210.73]) by hub.freebsd.org (Postfix) with ESMTP id 9F7BD37C039 for ; Wed, 12 Jul 2000 10:35:35 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from sv.Go2France.com [212.73.210.79] by mail.Go2France.com with ESMTP (SMTPD32-6.03) id AC573014028C; Wed, 12 Jul 2000 19:35:19 +0200 Message-Id: <4.3.2.7.2.20000712192913.052a9bb0@mail.Go2France.com> X-Sender: lconrad%Go2France.com@mail.Go2France.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 19:33:44 +0200 To: freebsd-net@FreeBSD.ORG From: Len Conrad Subject: Re: IPsec Performance (Re: Merge of KAME code) In-Reply-To: <20000713022715E.say@decoy.sfc.keio.ac.jp> References: <4.3.2.7.2.20000711174522.03075a20@mail.Go2France.com> 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 > TCP STREAM TEST UDP STREAM TEST > NONE: 60Mbps NONE: 94Mbps > AH: 23Mbps AH: 30Mbps > ESP: 11Mbps ESP: 11Mbps > AH+ESP: 8Mbps AH+ESP: 9Mbps At those limits, the process was CPU bound, or protocol-turnaround bound, or what? That's for one tunnel, but is there significant additional overhead in running 10's or 100's of tunnels or sessions? for the one-server-to-many-clients situation. Thanks, Len Len http://BIND8NT.MEIway.com: ISC BIND 8 installable binary for NT4 http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 11:30:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from decoy.sfc.keio.ac.jp (decoy.sfc.keio.ac.jp [133.27.84.101]) by hub.freebsd.org (Postfix) with ESMTP id 8149337BF1B; Wed, 12 Jul 2000 11:30:06 -0700 (PDT) (envelope-from say@sfc.wide.ad.jp) Received: from localhost (localhost.sfc.keio.ac.jp [127.0.0.1]) by decoy.sfc.keio.ac.jp (8.9.3/8.9.3) with ESMTP id DAA01707; Thu, 13 Jul 2000 03:29:22 +0900 (JST) (envelope-from say@sfc.wide.ad.jp) To: freebsd-net@FreeBSD.ORG Cc: lconrad@Go2France.com, kris@FreeBSD.ORG Subject: Re: IPsec Performance (Re: Merge of KAME code) From: ARIGA Seiji In-Reply-To: <20000713022715E.say@decoy.sfc.keio.ac.jp> References: <4.3.2.7.2.20000711174522.03075a20@mail.Go2France.com> <20000713022715E.say@decoy.sfc.keio.ac.jp> X-Mailer: Mew version 1.95b3 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-Publickey: http://decoy.sfc.keio.ac.jp/~say/key.txt X-PGP-Fingerprint: 8E 70 AB 20 44 E6 8A 8A 1C 49 B3 30 44 1B B3 BA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000713032922M.say@decoy.sfc.keio.ac.jp> Date: Thu, 13 Jul 2000 03:29:22 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 28 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 13 Jul 2000 02:27:15 +0900, ARIGA Seiji wrote, : : > Has anybody benchmarked or simulated how many tunnels and bits/sec one : : > software-only FreeBSD IPsec server can support? : : My P120 can do about 2.5MBps :-) : I used to benchmarked IPsec performance on following platform with netperf. : - PentiumIII 500MHz : - 256MB Memory : - Intel Ether Express Pro 100 (100Mbps) : - FreeBSD 2.2.8 : - KAME 19990809 stable Ah, I told a lie, sorry. I used two clients and one router. client - router - client Above is a router spec. Client (IPsec machine) spec is, - PentiumII 450MHz - 128MB Memory - Intel Ether Express Pro 100 (100Mbps) - FreeBSD 2.2.8 - KAME 19990809 stable I used static IPsec configuration (No IKE). // ARIGA Seiji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 11:42: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id EB92437BF69 for ; Wed, 12 Jul 2000 11:42:04 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id DAA25458 for ; Thu, 13 Jul 2000 03:42:02 +0900 (JST) To: net@freebsd.org Subject: change to struct route X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 13 Jul 2000 03:42:01 +0900 Message-ID: <25456.963427321@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i'll want to do it for freebsd too (maybe post-4.1 item). are you guys happy with this? the reason why we do not change the type for ro_dst (into sockaddr_storage) is that, if we do so, it will add too many typecasts in existing code. itojun ------- Forwarded Message Return-Path: Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with SMTP id DAA23920 for ; Thu, 13 Jul 2000 03:16:19 +0900 (JST) Received: (qmail 21594 invoked by uid 1176); 12 Jul 2000 18:16:06 -0000 Delivered-To: itojun@netbsd.org Received: (qmail 21411 invoked by uid 605); 12 Jul 2000 18:16:03 -0000 Received: (qmail 21404 invoked from network); 12 Jul 2000 18:16:02 -0000 Received: from dhcp0.itojun.org (HELO lychee.itojun.org) (210.160.95.106) by mail.netbsd.org with SMTP; 12 Jul 2000 18:16:02 -0000 Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e6CIEkH07639; Thu, 13 Jul 2000 03:14:46 +0900 (JST) To: tech-net@netbsd.org cc: core@kame.net Subject: struct route X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Thu, 13 Jul 2000 03:14:46 +0900 Message-ID: <7637.963425686@localhost> Sender: tech-net-owner@netbsd.org Precedence: list Delivered-To: tech-net@netbsd.org X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org sys/net/route.h has struct route, which is like this: struct route { struct rtentry *ro_rt; struct sockaddr ro_dst; }; This cannot hold sockaddr_iso or sockaddr_in6 (as sizeof(sockaddr) < sizeof(sockaddr_in6)), so there are local declarations for struct route-lookalike, in netiso (sys/netiso/iso_pcb.h) and netinet6 (sys/netinet6/in6.h). the approach has three issues, I believe: (1) maintenance nightmare. (2) offsetof(struct route, ro_dst) may not be equal to offsetof(struct route_in6, ro_dst), as we are unsure about struct packing rule by the compiler (3) if we mistakenly make a struct route_in6 * point to struct route region, we will easily make a overrun. so, we'd like to change it as follows: struct route { struct rtentry *ro_rt; struct sockaddr ro_dst; char padding[sizeof(struct sockaddr_storage) - sizeof(struct sockaddr)]; }; and nuke special route-like structure in netiso/netinet6. the above change should not raise type issue against existing code (like sys/netinet), as we do not change the type of ro_dst. since struct route is kernel-only structure, the change should not raise binary compatibility problem against the userland. is it okay for you guys? we are now testing this in kame tree and is working fine. itojun ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 12:49: 6 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 B308137B701 for ; Wed, 12 Jul 2000 12:49: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 PAA74525; Wed, 12 Jul 2000 15:48:54 -0400 (EDT) (envelope-from wollman) Date: Wed, 12 Jul 2000 15:48:54 -0400 (EDT) From: Garrett Wollman Message-Id: <200007121948.PAA74525@khavrinen.lcs.mit.edu> To: itojun@iijlab.net Cc: net@FreeBSD.ORG Subject: change to struct route In-Reply-To: <25456.963427321@coconut.itojun.org> References: <25456.963427321@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < i'll want to do it for freebsd too (maybe post-4.1 item). > are you guys happy with this? the reason why we do not change > the type for ro_dst (into sockaddr_storage) is that, if we do so, > it will add too many typecasts in existing code. > struct route { > struct rtentry *ro_rt; > struct sockaddr ro_dst; > char padding[sizeof(struct sockaddr_storage) - sizeof(struct sockaddr)]; > }; I'd rather see: struct route { struct rtentry *ro_rt; union { struct sockaddr dstu_dst; struct sockaddr_storage dstu_dstss; } ro_dstu; }; #define ro_dst ro_dstu.dstu_dst #define ro_dstss ro_dstu.dstu_dstss ...which would be the Traditional BSD Way to do it. -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 Jul 12 15:19:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from mrout1.yahoo.com (mrout1.yahoo.com [208.48.125.95]) by hub.freebsd.org (Postfix) with ESMTP id 04CC837BC42 for ; Wed, 12 Jul 2000 15:19:45 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout1.yahoo.com (8.10.0/8.10.0/y.out) with ESMTP id e6CMJP476846 for ; Wed, 12 Jul 2000 15:19:25 -0700 (PDT) Received: (from jayanth@localhost) by milk.yahoo.com (8.8.8/8.6.12) id PAA23754 for net@FreeBSD.ORG; Wed, 12 Jul 2000 15:19:25 -0700 (PDT) Date: Wed, 12 Jul 2000 15:19:25 -0700 From: jayanth To: net@FreeBSD.ORG Subject: diffs for deleting routing clones Message-ID: <20000712151925.A22978@yahoo-inc.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" X-Mailer: Mutt 1.0.1us Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii This is a hack for freeing up some memory from the routing table. It happens only when a connection is dropped due to listen q overflow and the associated route has no data cached in it. Any feedback would be helpful. jayanth --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="syn.patch" Index: route.h =================================================================== RCS file: /home/ncvs/src/sys/net/route.h,v retrieving revision 1.36 diff -u -p -u -r1.36 route.h --- route.h 2000/02/13 03:31:56 1.36 +++ route.h 2000/07/11 21:19:40 @@ -139,7 +139,7 @@ struct ortentry { #define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */ #define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */ #define RTF_DONE 0x40 /* message confirmed */ -/* 0x80 unused */ +#define RTF_DELCLONE 0x80 /* delete cloned route */ #define RTF_CLONING 0x100 /* generate new routes on use */ #define RTF_XRESOLVE 0x200 /* external daemon resolves name */ #define RTF_LLINFO 0x400 /* generated by link layer (e.g. ARP) */ Index: in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.66 diff -u -p -r1.66 in_pcb.c --- in_pcb.c 2000/07/04 16:35:05 1.66 +++ in_pcb.c 2000/07/12 22:07:41 @@ -531,6 +531,7 @@ in_pcbdetach(inp) { struct socket *so = inp->inp_socket; struct inpcbinfo *ipi = inp->inp_pcbinfo; + struct rt_entry *rt = = inp->inp_route.ro_rt; #ifdef IPSEC ipsec4_delete_pcbpolicy(inp); @@ -541,8 +542,25 @@ in_pcbdetach(inp) sofree(so); if (inp->inp_options) (void)m_free(inp->inp_options); - if (inp->inp_route.ro_rt) - rtfree(inp->inp_route.ro_rt); + if (rt){ + /* route delete requires reference count to be <= zero */ + if((rt->rt_flags & RTF_DELCLONE) && + (rt->rt_flags & RTF_WASCLONED)){ + if(--rt->rt_refcnt <= 0){ + rt->rt_flags &= ~RTF_UP; + rtrequest(RTM_DELETE, rt_key(rt), + rt->rt_gateway, rt_mask(rt), + rt->rt_flags, (struct rtentry **)0); + } + else + /* more than one reference, bump it up + * again. + */ + rt->rt_refcnt++; + } + else + rtfree(rt); + } ip_freemoptions(inp->inp_moptions); inp->inp_vflag = 0; zfreei(ipi->ipi_zone, inp); Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.117 diff -u -p -r1.117 tcp_input.c --- tcp_input.c 2000/07/09 13:01:59 1.117 +++ tcp_input.c 2000/07/12 22:07:41 @@ -121,6 +121,10 @@ SYSCTL_INT(_net_inet_tcp, OID_AUTO, dela &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +int tcp_lq_overflow = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, tcp_lq_overflow, CTLFLAG_RW, + &tcp_lq_overflow, 0, + "Listen Queue Overflow"); #ifdef TCP_DROP_SYNFIN static int drop_synfin = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, @@ -710,6 +714,9 @@ findpcb: tcpstat.tcps_listendrop++; so2 = sodropablereq(so); if (so2) { + if(tcp_lq_overflow) + sototcpcb(so2)->t_flags |= + TF_LQ_OVERFLOW; tcp_drop(sototcpcb(so2), ETIMEDOUT); so2 = sonewconn(so, 0); } Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.78 diff -u -p -r1.78 tcp_subr.c --- tcp_subr.c 2000/07/04 16:35:05 1.78 +++ tcp_subr.c 2000/07/12 22:07:41 @@ -680,6 +680,17 @@ tcp_close(tp) tcpstat.tcps_cachedssthresh++; } } + rt = inp->inp_route.ro_rt; + if(rt){ + /* mark route for delete if no information is + * cached + */ + if ((tp->t_flags & TF_LQ_OVERFLOW) && + ((rt->rt_rmx.rmx_locks & RTV_RTT) == 0)){ + if(rt->rt_rmx.rmx_rtt == 0) + rt->rt_flags |= RTF_DELCLONE; + } + } no_valid_rt: /* free the reassembly queue, if any */ while((q = LIST_FIRST(&tp->t_segq)) != NULL) { Index: tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.59 diff -u -p -r1.59 tcp_var.h --- tcp_var.h 2000/05/26 02:05:47 1.59 +++ tcp_var.h 2000/07/12 22:07:41 @@ -94,6 +94,7 @@ struct tcpcb { #define TF_RCVD_CC 0x04000 /* a CC was received in SYN */ #define TF_SENDCCNEW 0x08000 /* send CCnew instead of CC in SYN */ #define TF_MORETOCOME 0x10000 /* More data to be appended to sock */ +#define TF_LQ_OVERFLOW 0x20000 /* listen queue overflow */ int t_force; /* 1 if forcing out a byte */ tcp_seq snd_una; /* send unacknowledged */ --YZ5djTAD1cGYuMQK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 16:30:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 35AE937B87D for ; Wed, 12 Jul 2000 16:30:53 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA28561; Thu, 13 Jul 2000 08:30:42 +0900 (JST) To: Garrett Wollman Cc: net@FreeBSD.ORG In-reply-to: wollman's message of Wed, 12 Jul 2000 15:48:54 -0400. <200007121948.PAA74525@khavrinen.lcs.mit.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: change to struct route From: itojun@iijlab.net Date: Thu, 13 Jul 2000 08:30:42 +0900 Message-ID: <28559.963444642@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> struct route { >> struct rtentry *ro_rt; >> struct sockaddr ro_dst; >> char padding[sizeof(struct sockaddr_storage) - sizeof(struct sockaddr)]; >> }; > >I'd rather see: > >struct route { > struct rtentry *ro_rt; > union { > struct sockaddr dstu_dst; > struct sockaddr_storage dstu_dstss; > } ro_dstu; >}; > >#define ro_dst ro_dstu.dstu_dst >#define ro_dstss ro_dstu.dstu_dstss > >...which would be the Traditional BSD Way to do it. thanks for comment, we now are trying to do just like your suggestion. (we got comment from thorpej@netbsd as well) actually this breaks when someone tries to use ro_dst as other struct member name (4.4BSD netiso does it), but we need to change that portion anyways. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jul 12 23:45:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id C741137BC5C for ; Wed, 12 Jul 2000 23:45:53 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id IAA26200; Thu, 13 Jul 2000 08:45:16 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id HAA30477; Thu, 13 Jul 2000 07:34:50 +0200 (CEST) (envelope-from andreas) Date: Thu, 13 Jul 2000 07:34:50 +0200 From: Andreas Klemm To: "Rodney W. Grimes" Cc: zebra@dml.com, zebra@zebra.org, freebsd-net@FreeBSD.ORG Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all Message-ID: <20000713073450.A30456@titan.klemm.gtn.com> References: <20000712004230.A4919@titan.klemm.gtn.com> <200007120733.AAA07865@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007120733.AAA07865@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Wed, Jul 12, 2000 at 12:33:46AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Solved, many thanks to Rodney ... Culprit was a static route to the loopback interface, which was necessary in the past to get multicasts out of BSDs IP stack ... Now you need nothing anymore... it simply works !!! Thanks again !!! Andreas /// -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 13 8:23: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 020D737BF8B for ; Thu, 13 Jul 2000 08:23:02 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id IAA12565; Thu, 13 Jul 2000 08:22:41 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200007131522.IAA12565@gndrsh.dnsmgr.net> Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all In-Reply-To: <20000713073450.A30456@titan.klemm.gtn.com> from Andreas Klemm at "Jul 13, 2000 07:34:50 am" To: andreas@klemm.gtn.com (Andreas Klemm) Date: Thu, 13 Jul 2000 08:22:41 -0700 (PDT) Cc: zebra@dml.com, zebra@zebra.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 > Solved, > > many thanks to Rodney ... > > Culprit was a static route to the loopback interface, which was > necessary in the past to get multicasts out of BSDs IP stack ... > > Now you need nothing anymore... it simply works !!! _NOTHING_???? Or did you end up with just a default route? In the past is what I had found was you either needed a default route, or a route for 224.0.0.0/4 to an interface, and it couldn't be a -interface route, it needed to be 224.0.0.0/4 -> some local ip on a physical ethernet device capable of multicast (It didn't matter if it was the one you where trying to start ospf up on or not though, any interface would do). > Thanks again !!! Welcome, just glad it has been found!! (I'm still waiting on zebra ospf to become a far bit less of a moving target before doing much of anything real with it, I don't think it is quite ready to deal with a 36 ospf router network that has some very complex multi-pathing in it.) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 13 9:31:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [192.109.159.1]) by hub.freebsd.org (Postfix) with ESMTP id 9400137C4EE for ; Thu, 13 Jul 2000 09:31:12 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by picalon.gun.de (8.9.3/8.9.3) id SAA07890; Thu, 13 Jul 2000 18:30:23 +0200 (MET DST) >Received: (from andreas@localhost) by klemm.gtn.com (8.9.3/8.9.3) id SAA78202; Thu, 13 Jul 2000 18:03:12 +0200 (CEST) (envelope-from andreas) Date: Thu, 13 Jul 2000 18:03:10 +0200 From: Andreas Klemm To: "Rodney W. Grimes" Cc: Andreas Klemm , zebra@dml.com, zebra@zebra.org, freebsd-net@FreeBSD.ORG Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all Message-ID: <20000713180309.A78179@titan.klemm.gtn.com> References: <20000713073450.A30456@titan.klemm.gtn.com> <200007131522.IAA12565@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007131522.IAA12565@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Thu, Jul 13, 2000 at 08:22:41AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT SMP X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jul 13, 2000 at 08:22:41AM -0700, Rodney W. Grimes wrote: > > Solved, > > > > many thanks to Rodney ... > > > > Culprit was a static route to the loopback interface, which was > > necessary in the past to get multicasts out of BSDs IP stack ... > > > > Now you need nothing anymore... it simply works !!! > > _NOTHING_???? Or did you end up with just a default route? Yes, nothing. root@titan{615} $ netstat -rn | less Routing tables Internet: Destination Gateway Flags Netif Expire default 172.16.2.2 UGSc 8 6080 xl0 127.0.0.1 127.0.0.1 UH 11 2934 lo0 172.16.1/24 link#2 UC 0 0 ed0 => 172.16.1.255 ff:ff:ff:ff:ff:ff UHLWb 2 133 ed0 172.16.2/24 link#1 UC 0 0 xl0 => 172.16.2.1 0:60:97:aa:3a:db UHLW 7 23321 lo0 172.16.2.2 0:e0:b0:55:56:3 UHLW 9 90704 xl0 652 172.16.2.255 ff:ff:ff:ff:ff:ff UHLWb 3 266 xl0 172.16.200.1 172.16.200.1 UH 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::%ed0/64 link#2 UC ed0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%ed0/32 link#2 UC ed0 ff02::%lo0/32 fe80::1%lo0 UC lo0 -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jul 13 15:32:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 99FE837B6A2 for ; Thu, 13 Jul 2000 15:32:49 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA13617; Thu, 13 Jul 2000 15:32:12 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200007132232.PAA13617@gndrsh.dnsmgr.net> Subject: Re: [zebra 4398] fbsd-5.0/zebra 0.87: ospf stuck in INIT and dies after debug ospf packet all In-Reply-To: <20000713180309.A78179@titan.klemm.gtn.com> from Andreas Klemm at "Jul 13, 2000 06:03:10 pm" To: andreas@klemm.gtn.com (Andreas Klemm) Date: Thu, 13 Jul 2000 15:32:11 -0700 (PDT) Cc: zebra@dml.com, zebra@zebra.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 > On Thu, Jul 13, 2000 at 08:22:41AM -0700, Rodney W. Grimes wrote: > > > Solved, > > > > > > many thanks to Rodney ... > > > > > > Culprit was a static route to the loopback interface, which was > > > necessary in the past to get multicasts out of BSDs IP stack ... > > > > > > Now you need nothing anymore... it simply works !!! > > > > _NOTHING_???? Or did you end up with just a default route? ^^^^^^^^^^^^^^^^^^^^^ > > Yes, nothing. A default route != nothing. You have a default route below, thay will be fine for you probably, but for those of us who run ospf/bgp interacting AS's default routes are _not_ an option. > root@titan{615} $ netstat -rn | less > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 172.16.2.2 UGSc 8 6080 xl0 > 127.0.0.1 127.0.0.1 UH 11 2934 lo0 > 172.16.1/24 link#2 UC 0 0 ed0 => ... > -- > Andreas Klemm http://people.FreeBSD.ORG/~andreas > http://www.freebsd.org/~fsmp/SMP/SMP.html > powered by Symmetric MultiProcessor FreeBSD > New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 8:52:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id ACA8537C953 for ; Fri, 14 Jul 2000 08:52:23 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e6EFqKB11933 for ; Fri, 14 Jul 2000 17:52:21 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6EFqK512400 for ; Fri, 14 Jul 2000 17:52:20 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e6EFqKa71534 for freebsd-net@freebsd.org; Fri, 14 Jul 2000 17:52:20 +0200 (CEST) Date: Fri, 14 Jul 2000 17:52:20 +0200 From: Andre Albsmeier To: freebsd-net@freebsd.org Subject: routed: possible netmask problem ... Message-ID: <20000714175220.A92642@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am using fxp0 with an ipalias: root@webfix:~>ifconfig fxp0 fxp0: flags=8843 mtu 1500 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 ether 00:a0:c9:ca:18:64 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP When starting routed I always see the following error message: root@webfix:~>routed: possible netmask problem between fxp0:192.168.1.4/32 and fxp0:192.168.1.0/24 routed: Send mcast sendto(fxp0, 224.0.0.9.520): No route to host All that is on a 3.5-STABLE machine. Can someone tell me what I am doing wrong here ?!? Thanks a lot, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 10:42: 4 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 3C5EB37B7DF for ; Fri, 14 Jul 2000 10:42:00 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id LAA94806; Fri, 14 Jul 2000 11:41:50 -0600 (MDT) Date: Fri, 14 Jul 2000 11:41:50 -0600 (MDT) From: Nick Rogness To: Andre Albsmeier Cc: freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... In-Reply-To: <20000714175220.A92642@curry.mchp.siemens.de> 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 Fri, 14 Jul 2000, Andre Albsmeier wrote: > Hi, > > I am using fxp0 with an ipalias: > > root@webfix:~>ifconfig fxp0 > fxp0: flags=8843 mtu 1500 > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 ^^ you have a /32 netmask on 1.4, change it to a /24 address (255.255.255.0) and see if that helps. >When starting routed I always see the following error message: > root@webfix:~>routed: possible netmask problem between > fxp0:192.168.1.4/32 and fxp0:192.168.1.0/24 >routed: Send mcast sendto(fxp0, 224.0.0.9.520): No route to host route add -net 224.0.0.0 -netmask 240.0.0.0 127.0.0.1 Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 11:10: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 AB35337B73F for ; Fri, 14 Jul 2000 11:10:13 -0700 (PDT) (envelope-from robert@fledge.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 OAA86504; Fri, 14 Jul 2000 14:09:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 14 Jul 2000 14:09:50 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nick Rogness Cc: Andre Albsmeier , freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... 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 Fri, 14 Jul 2000, Nick Rogness wrote: > > root@webfix:~>ifconfig fxp0 > > fxp0: flags=8843 mtu 1500 > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > > you have a /32 netmask on 1.4, change it to a /24 address > (255.255.255.0) and see if that helps. I don't have much experience with routed, but I can tell you that the /32 here is correct in my experience -- the two addresses are in the same /24 subnet. Putting both in with a netmask of /24 will cause problems due to muliple routing entries with the same prefix/netmask. 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 Jul 14 11:29:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 867E337BFD6; Fri, 14 Jul 2000 11:29:42 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id MAA16628; Fri, 14 Jul 2000 12:29:39 -0600 (MDT) Date: Fri, 14 Jul 2000 12:29:39 -0600 (MDT) From: Nick Rogness To: Andre Albsmeier Cc: Robert Watson , freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... 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 Fri, 14 Jul 2000, Robert Watson wrote: > On Fri, 14 Jul 2000, Nick Rogness wrote: > > > > root@webfix:~>ifconfig fxp0 > > > fxp0: flags=8843 mtu 1500 > > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > > > > you have a /32 netmask on 1.4, change it to a /24 address > > (255.255.255.0) and see if that helps. > > I don't have much experience with routed, but I can tell you that the /32 > here is correct in my experience -- the two addresses are in the same /24 > subnet. Putting both in with a netmask of /24 will cause problems due to > muliple routing entries with the same prefix/netmask. > I don't have much experience with routed either. I do agree in "specific" situations, setting both netmasks to /24 could be a problem. I have used /32 within the same network, but I binded it to the loopback interface and used arp (pub). That might solve your problems. I've also run gated without problems with this type of setup. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 12:52:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 204E037C6B2 for ; Fri, 14 Jul 2000 12:52:49 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id VAA14294 for freebsd-net@freebsd.org; Fri, 14 Jul 2000 21:52:46 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 8B97787AE; Fri, 14 Jul 2000 21:01:20 +0200 (CEST) Date: Fri, 14 Jul 2000 21:01:20 +0200 From: Ollivier Robert To: freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... Message-ID: <20000714210120.A72450@keltia.freenix.fr> Mail-Followup-To: freebsd-net@freebsd.org References: <20000714175220.A92642@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nick@rapidnet.com on Fri, Jul 14, 2000 at 11:41:50AM -0600 X-Operating-System: FreeBSD 5.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Nick Rogness: > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > ^^ > > you have a /32 netmask on 1.4, change it to a /24 address > (255.255.255.0) and see if that helps. No, that's correct because 1.4 is an IP alias on the same subnet. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 16: 2:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with SMTP id 8DD3137B9AE for ; Fri, 14 Jul 2000 16:02:41 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 11853 invoked by uid 1000); 14 Jul 2000 23:02:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jul 2000 23:02:40 -0000 Date: Fri, 14 Jul 2000 18:02:40 -0500 (CDT) From: Mike Silbersack To: ARIGA Seiji Cc: freebsd-net@FreeBSD.ORG, lconrad@Go2France.com, kris@FreeBSD.ORG Subject: Re: IPsec Performance (Re: Merge of KAME code) In-Reply-To: <20000713022715E.say@decoy.sfc.keio.ac.jp> 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 Thu, 13 Jul 2000, ARIGA Seiji wrote: > And the results are about, > > TCP STREAM TEST UDP STREAM TEST > NONE: 60Mbps NONE: 94Mbps > AH: 23Mbps AH: 30Mbps > ESP: 11Mbps ESP: 11Mbps > AH+ESP: 8Mbps AH+ESP: 9Mbps > > P.S. The same tests with IPv6 produced almost the same results. > > // ARIGA Seiji Question. Is the time spent in the IPSec layer accounted to the user processor, or just thrown in with kernel time? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 22:53: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from saturn.home.ben.com (c1058885-a.bvrtn1.or.home.com [24.12.186.106]) by hub.freebsd.org (Postfix) with ESMTP id CD92A37B9CD; Fri, 14 Jul 2000 22:52:59 -0700 (PDT) (envelope-from ben@ben.com) Received: from pulsar.home.ben.com (pulsar.home.ben.com [172.17.42.9]) by saturn.home.ben.com (8.9.3/8.9.3) with ESMTP id WAA07260; Fri, 14 Jul 2000 22:52:53 -0700 (PDT) Received: from pulsar.home.ben.com (bjj@localhost) by pulsar.home.ben.com (8.9.3/8.6.12) with ESMTP id WAA03437; Fri, 14 Jul 2000 22:52:51 -0700 (PDT) Message-Id: <200007150552.WAA03437@pulsar.home.ben.com> To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Cc: matthewr@moreton.com.au Subject: port of MPPE (microsoft VPN encryption) to FreeBSD Date: Fri, 14 Jul 2000 22:52:51 -0700 From: Ben Jackson Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I needed MPPE to tunnel into work and found: http://www.moretonbay.com/vpn/releases/ppp-2.3.10-openssl-norc4-mppe.patch.gz which applies to ppp-2.3.10 and adds MS CHAP v1 and v2 and MPPE to pppd and the related kernel code. Imagine my surprise when I found that only the CHAP parts were portable and the MPPE was only available for Linux! So, in a process not unlike hammering a square peg into a round hole, I got the kernel components working under FreeBSD 3.4. Has anyone else already done this? Is anyone mbuf-savvy interetested in suggesting more elegant ways of supporting this code for BSD? My main purpose in sending this is to make sure any interested parties pester me so I get around to sharing the results... --Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 23:31:55 2000 Delivered-To: freebsd-net@freebsd.org Received: from decoy.sfc.keio.ac.jp (decoy.sfc.keio.ac.jp [133.27.84.101]) by hub.freebsd.org (Postfix) with ESMTP id 1998637C3F5; Fri, 14 Jul 2000 23:31:52 -0700 (PDT) (envelope-from say@sfc.wide.ad.jp) Received: from localhost (localhost.sfc.keio.ac.jp [127.0.0.1]) by decoy.sfc.keio.ac.jp (8.9.3/8.9.3) with ESMTP id PAA17232; Sat, 15 Jul 2000 15:31:04 +0900 (JST) (envelope-from say@sfc.wide.ad.jp) To: freebsd-net@FreeBSD.ORG Cc: silby@silby.com, lconrad@Go2France.com, kris@FreeBSD.ORG Subject: Re: IPsec Performance (Re: Merge of KAME code) From: ARIGA Seiji In-Reply-To: References: <20000713022715E.say@decoy.sfc.keio.ac.jp> X-Mailer: Mew version 1.95b3 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-Publickey: http://decoy.sfc.keio.ac.jp/~say/key.txt X-PGP-Fingerprint: 8E 70 AB 20 44 E6 8A 8A 1C 49 B3 30 44 1B B3 BA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000715153103V.say@decoy.sfc.keio.ac.jp> Date: Sat, 15 Jul 2000 15:31:03 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 15 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14 Jul 2000 18:02:40 -0500 (CDT), Mike Silbersack wrote, : > TCP STREAM TEST UDP STREAM TEST : > NONE: 60Mbps NONE: 94Mbps : > AH: 23Mbps AH: 30Mbps : > ESP: 11Mbps ESP: 11Mbps : > AH+ESP: 8Mbps AH+ESP: 9Mbps : Question. Is the time spent in the IPSec layer accounted to the user : processor, or just thrown in with kernel time? I used netperf to measure the performance of IPsec. So, I think it is accounted to the user processor. // ARIGA Seiji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jul 14 23:37:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id B7D1E37C414; Fri, 14 Jul 2000 23:37:42 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id PAA07695; Sat, 15 Jul 2000 15:37:40 +0900 (JST) To: Mike Silbersack Cc: ARIGA Seiji , freebsd-net@FreeBSD.ORG, lconrad@Go2France.com, kris@FreeBSD.ORG In-reply-to: silby's message of Fri, 14 Jul 2000 18:02:40 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPsec Performance (Re: Merge of KAME code) From: itojun@iijlab.net Date: Sat, 15 Jul 2000 15:37:40 +0900 Message-ID: <7693.963643060@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> And the results are about, >> >> TCP STREAM TEST UDP STREAM TEST >> NONE: 60Mbps NONE: 94Mbps >> AH: 23Mbps AH: 30Mbps >> ESP: 11Mbps ESP: 11Mbps >> AH+ESP: 8Mbps AH+ESP: 9Mbps >> >> P.S. The same tests with IPv6 produced almost the same results. >> >> // ARIGA Seiji > >Question. Is the time spent in the IPSec layer accounted to the user >processor, or just thrown in with kernel time? the current IPsec code does encryption (like actual DES/3DES encryption of the packet) in the kernel, so it will appear as kernel time. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 5:55:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from wat-border.sentex.ca (waterloo-hespler.sentex.ca [199.212.135.66]) by hub.freebsd.org (Postfix) with ESMTP id A292B37B74F for ; Sat, 15 Jul 2000 05:55:38 -0700 (PDT) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by wat-border.sentex.ca (8.9.3/8.9.3) with ESMTP id IAA85675; Sat, 15 Jul 2000 08:55:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id IAA08098; Sat, 15 Jul 2000 08:55:37 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: andre.albsmeier@mchp.siemens.de (Andre Albsmeier) Cc: freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... Date: Sat, 15 Jul 2000 12:50:33 GMT Message-ID: <39705db6.118593488@mail.sentex.net> References: In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14 Jul 2000 12:39:05 -0400, in sentex.lists.freebsd.net you wrote: >Hi, > >I am using fxp0 with an ipalias: > >root@webfix:~>ifconfig fxp0 >fxp0: flags=8843 mtu 1500 > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > ether 00:a0:c9:ca:18:64 > media: 100baseTX status: active > supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP > > >When starting routed I always see the following error message: > >root@webfix:~>routed: possible netmask problem between fxp0:192.168.1.4/32 and fxp0:192.168.1.0/24 routed: Send mcast sendto(fxp0, 224.0.0.9.520): No route to host > > >All that is on a 3.5-STABLE machine. Can someone tell me what I am >doing wrong here ?!? You might try aliasing the loopback interface instead. And if necessary and a static arp entry for the IP so hosts on the subnet will know where to go. ---Mike Mike Tancsa (mdtancsa@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 6:55: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 6789437B946; Sat, 15 Jul 2000 06:55:07 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6FDt6U13871; Sat, 15 Jul 2000 06:55:06 -0700 (PDT) Date: Sat, 15 Jul 2000 06:55:06 -0700 From: Alfred Perlstein To: net@freebsd.org Cc: dg@freebsd.org, dillon@freebsd.org Subject: mbuf refcnt and sendfile Message-ID: <20000715065506.Y25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org http://www.freebsd.org/cgi/query-pr.cgi?pr=19866 David, I'm pretty sure you didn't like the 'fix' for the mbuf cluster refcount presented in this PR (linking all copies using a doubly linked list), I have presented an alternative: Instead of keeping them in a linked list there should be an int/char * in the mbuf header that works the same way mclrefcnt does. Instead of managing a linked list all one has to do is copy the pointer into the new mbuf header and increment it, and decrease it on free, when it's zero the deref code is called. I was wondering what your thoughts on this are? I also had an idea to save on sf_buf's in sendfile: Forget about them, set the m_ext->ext_buf to point directly at the vm_page_t backing the mbuf, you don't need the extra indirection. I think that could work if you did a vm_page_wire and pmap_qenter for each mbuf ref callback and a vm_page_unwire and pmap_qremove for each mbuf free callback. With the callback reducing optimization for mbuf clusters mentioned first I think we may have pretty good optimization. What do you guys think? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 9:22:47 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 2BCC237B5E2; Sat, 15 Jul 2000 09:22:44 -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 <0FXQ000DRYTS2X@falla.videotron.net>; Sat, 15 Jul 2000 12:22:41 -0400 (EDT) Date: Sat, 15 Jul 2000 12:25:03 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf refcnt and sendfile In-reply-to: <20000715065506.Y25571@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, dillon@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 Sat, 15 Jul 2000, Alfred Perlstein wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=19866 > > David, I'm pretty sure you didn't like the 'fix' for the mbuf > cluster refcount presented in this PR (linking all copies using > a doubly linked list), I have presented an alternative: > > Instead of keeping them in a linked list there should be an int/char * > in the mbuf header that works the same way mclrefcnt does. Instead > of managing a linked list all one has to do is copy the pointer into > the new mbuf header and increment it, and decrease it on free, when > it's zero the deref code is called. This takes away from the transparency of the system and further adds the necessity of having to splimp() for something as simple as checking whether an mbuf's ext_buf is referenced by more than one object. If you keep the counter outside of the isolated mbuf (which is what you're suggesting with the pointer idea), then you have to splimp() before you check the value of the referred counter. > I was wondering what your thoughts on this are? > > I also had an idea to save on sf_buf's in sendfile: > > Forget about them, set the m_ext->ext_buf to point directly at the > vm_page_t backing the mbuf, you don't need the extra indirection. If the ext_buf referencing remains transparent, then you don't really need the extra indirection management, as far as I know! But I'm not sure! David probably knows this interface WAAAY better (he wrote it!) :-) > I think that could work if you did a vm_page_wire and pmap_qenter > for each mbuf ref callback and a vm_page_unwire and pmap_qremove > for each mbuf free callback. > > With the callback reducing optimization for mbuf clusters mentioned > first I think we may have pretty good optimization. > > What do you guys think? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 9:38:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7466237BBC5; Sat, 15 Jul 2000 09:38:51 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6FGciX18881; Sat, 15 Jul 2000 09:38:44 -0700 (PDT) Date: Sat, 15 Jul 2000 09:38:44 -0700 From: Alfred Perlstein To: Bosko Milekic Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: mbuf refcnt and sendfile Message-ID: <20000715093844.D25571@fw.wintelcom.net> References: <20000715065506.Y25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bmilekic@dsuper.net on Sat, Jul 15, 2000 at 12:25:03PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Bosko Milekic [000715 09:22] wrote: > > > On Sat, 15 Jul 2000, Alfred Perlstein wrote: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=19866 > > > > David, I'm pretty sure you didn't like the 'fix' for the mbuf > > cluster refcount presented in this PR (linking all copies using > > a doubly linked list), I have presented an alternative: > > > > Instead of keeping them in a linked list there should be an int/char * > > in the mbuf header that works the same way mclrefcnt does. Instead > > of managing a linked list all one has to do is copy the pointer into > > the new mbuf header and increment it, and decrease it on free, when > > it's zero the deref code is called. > > This takes away from the transparency of the system and further adds > the necessity of having to splimp() for something as simple as checking > whether an mbuf's ext_buf is referenced by more than one object. If you > keep the counter outside of the isolated mbuf (which is what you're > suggesting with the pointer idea), then you have to splimp() before you > check the value of the referred counter. And why exactly don't you have to splimp if it's a linked list? I assume you mean an object may be referenced by more than just mbufs, the solution is simple, you just keep that count seperate: if (myobj->mbrefcnt == 0 && myobj->otherrefcnt == 0) myfree(myobj); Of course your ext_free function will have to do the same, but you can't avoid this. Also, the refcounting can be done with atomic operations therefore you won't need spl, if you atomically decrease the ref and it's zero, then the network stack doesn't have access to it. Lastly your changes bloat the size of an mbuf by 12 bytes, although really only 8 because ext_args isn't needed. > > I was wondering what your thoughts on this are? > > > > I also had an idea to save on sf_buf's in sendfile: > > > > Forget about them, set the m_ext->ext_buf to point directly at the > > vm_page_t backing the mbuf, you don't need the extra indirection. > > If the ext_buf referencing remains transparent, then you don't really > need the extra indirection management, as far as I know! But I'm not > sure! David probably knows this interface WAAAY better (he wrote it!) :-) All the code I've seen really doesn't use it for external clusters that aren't mbuf clusters. Here's the response to the PR: * Bosko Milekic [000715 08:30] wrote: > > I disagree. Especially since you haven't said why it's better than > what's proposed. The overhead of the list management isn't good, a single count can be manipulated atomically which will be a win when we SMP-ify things. > Of course, here's the reason why: If you are holding a POINTER to an > outside reference counter, then you make think > that you're accomodating things for counters outside the subsystem > but in reality, if you are allocating objects of dynamic size with > malloc() at some point, you don't really want to have to allocate and > manage a reference count scheme for that one object anyway. > I don't know about you but I want to be able to do malloc(), > MEXTADD() the ext_buf to the mbuf, and be ready to go. Then, if > m_copym ever gets called on my mbuf (or my mbuf is in the chain), I > want it to be taken care of by itself, such that when the mbuf is > freed, the ext_buf necessarily won't be. I don't want to have to > malloc() extra space for a counter. You don't need to, the mbuf system can still do that for you. > So the point is: the mbuf subsystem is supposed to transparently > manage the reference count scheme for itself and if the ext_free > routine is called and there is an external reference (you can pass it > using the ext_args pointer) then you don't necessarily need to free > the object. > > If you still think it should be otherwise, let me know why and I'll > change it, but I would like to get this off my back as soon as > possible. I strongly object to the implemetation you propose, however I also strongly agree that it the current way isn't good. You can either malloc() extra space for a counter, or you can allocate them seperately like so: struct mbrefcnt { struct mbrefcnt *mbref_next; /* freelist */ char mbref_cnt; /* count */ }; and have the mbuf code manage these structures. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 9:46:56 2000 Delivered-To: freebsd-net@freebsd.org Received: from mercury.spvi.com (h194.spvi.com [208.150.70.194]) by hub.freebsd.org (Postfix) with ESMTP id 2117E37B59B; Sat, 15 Jul 2000 09:46:51 -0700 (PDT) (envelope-from steve@spvi.com) Received: (from steve@localhost) by mercury.spvi.com (8.9.3/8.9.3) id LAA56675; Sat, 15 Jul 2000 11:46:12 -0500 (EST) (envelope-from steve@spvi.com) Date: Sat, 15 Jul 2000 11:46:12 -0500 (EST) Message-Id: <200007151646.LAA56675@mercury.spvi.com> X-Authentication-Warning: mercury.spvi.com: steve set sender to steve@spvi.com using -f From: Steve Spicklemire To: ben@ben.com Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, matthewr@moreton.com.au In-reply-to: <200007150552.WAA03437@pulsar.home.ben.com> (message from Ben Jackson on Fri, 14 Jul 2000 22:52:51 -0700) Subject: Re: port of MPPE (microsoft VPN encryption) to FreeBSD Reply-To: steve@spvi.com References: <200007150552.WAA03437@pulsar.home.ben.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Ben, If you can go to 4.0s, there is /usr/ports/net/mpd-netgraph which works great already, and doesn't requre poptop at all. It does require a buildworld with the most recent sources... -steve >>>>> "Ben" == Ben Jackson writes: Ben> I needed MPPE to tunnel into work and found: Ben> http://www.moretonbay.com/vpn/releases/ppp-2.3.10-openssl-norc4-mppe.patch.gz Ben> which applies to ppp-2.3.10 and adds MS CHAP v1 and v2 and Ben> MPPE to pppd and the related kernel code. Imagine my Ben> surprise when I found that only the CHAP parts were portable Ben> and the MPPE was only available for Linux! So, in a process Ben> not unlike hammering a square peg into a round hole, I got Ben> the kernel components working under FreeBSD 3.4. Ben> Has anyone else already done this? Is anyone mbuf-savvy Ben> interetested in suggesting more elegant ways of supporting Ben> this code for BSD? My main purpose in sending this is to Ben> make sure any interested parties pester me so I get around to Ben> sharing the results... Ben> --Ben Ben> To Unsubscribe: send mail to majordomo@FreeBSD.org with Ben> "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 Sat Jul 15 10:48:27 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 BCA5037BC9F; Sat, 15 Jul 2000 10:48:23 -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 <0FXR007K52OUJD@falla.videotron.net>; Sat, 15 Jul 2000 13:46:06 -0400 (EDT) Date: Sat, 15 Jul 2000 13:48:29 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf refcnt and sendfile In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, dillon@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 > When you increase the reference count, it's not exactly atomic as > you may be offsetting into a location, it may produce more than one > instruction in which case you may catch an interrupt in between where > things will get broken. I just thought of something that would essentially change this and make your assumption correct for the issue of atomicity. However, I still think that it's better to not maintain an external reference counter for each ext_buf mainly for the reason of transparency. But I guess what you could do, if you really insist on it is, in m_ext: union { u_int counter; u_int *countr; } count; The first referrer can use the u_int counter and the rest can point their *countr's to this first mbuf's counter. This would avoid the external management of a reference counter. It might indeed make these operations more optimized. I made the changes already so I'll post them a little later today, if you want. Personally, though, I preferred to have all of the mbufs referring to the same external object easily accessible through any of the isolated mbufs. --Bosko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 10:48:40 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 BAAE637B6DD; Sat, 15 Jul 2000 10:48:35 -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 <0FXQ00LULZYR5D@field.videotron.net>; Sat, 15 Jul 2000 12:47:15 -0400 (EDT) Date: Sat, 15 Jul 2000 12:49:38 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf refcnt and sendfile In-reply-to: <20000715093844.D25571@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, dillon@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 Sat, 15 Jul 2000, Alfred Perlstein wrote: > And why exactly don't you have to splimp if it's a linked list? Because you're checking the pointer in the isolated mbuf which cannot be modified by anything but the owner. If you check the reference counter which is general, it can be incremented or manipulated by any other code. > I assume you mean an object may be referenced by more than just mbufs, > the solution is simple, you just keep that count seperate: Yes, which is feasible presently without the need for the thing you suggested. [...] > Also, the refcounting can be done with atomic operations therefore > you won't need spl, if you atomically decrease the ref and it's > zero, then the network stack doesn't have access to it. When you increase the reference count, it's not exactly atomic as you may be offsetting into a location, it may produce more than one instruction in which case you may catch an interrupt in between where things will get broken. > Lastly your changes bloat the size of an mbuf by 12 bytes, although > really only 8 because ext_args isn't needed. You don't need that data anyway. When you M_EXT, you don't use the data area of the mbuf. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 10:48:41 2000 Delivered-To: freebsd-net@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 8B2F137B665; Sat, 15 Jul 2000 10:48:33 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e6FHmVB06191; Sat, 15 Jul 2000 19:48:31 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6FHmVT01942; Sat, 15 Jul 2000 19:48:31 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e6FHmVa79389; Date: Sat, 15 Jul 2000 19:48:30 +0200 From: Andre Albsmeier To: Robert Watson Cc: Nick Rogness , Andre Albsmeier , freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... Message-ID: <20000715194830.A6971@curry.mchp.siemens.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from rwatson@freebsd.org on Fri, Jul 14, 2000 at 02:09:50PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14-Jul-2000 at 14:09:50 -0400, Robert Watson wrote: > On Fri, 14 Jul 2000, Nick Rogness wrote: > > > > root@webfix:~>ifconfig fxp0 > > > fxp0: flags=8843 mtu 1500 > > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > > > > you have a /32 netmask on 1.4, change it to a /24 address > > (255.255.255.0) and see if that helps. > > I don't have much experience with routed, but I can tell you that the /32 > here is correct in my experience -- the two addresses are in the same /24 > subnet. Putting both in with a netmask of /24 will cause problems due to > muliple routing entries with the same prefix/netmask. Well, my setup used to work until Feb 17 when Peter Wemm MFC'ed some stuff into RELENG_3. From this day on it started to spit out the above messages. I asked peter for a hint but never got a reply. I also filed a PR since I am sure my setup is correct, see also the FAQ: Q: How can I setup Ethernet aliases? A: Add ``netmask 0xffffffff'' to your ifconfig command-line like the following: ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff -Andre > > 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 -- Your mouse has moved. Windows NT must be restarted for the change to take effect! Reboot now? [OK] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 11:37:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 0E34B37B613; Sat, 15 Jul 2000 11:37:14 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e6FIb9R27853; Sat, 15 Jul 2000 20:37:09 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6FIb8T05735; Sat, 15 Jul 2000 20:37:09 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e6FIb8a79606; Date: Sat, 15 Jul 2000 20:37:08 +0200 From: Andre Albsmeier To: Nick Rogness Cc: Andre Albsmeier , Robert Watson , freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... Message-ID: <20000715203708.A11638@curry.mchp.siemens.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from nick@rapidnet.com on Fri, Jul 14, 2000 at 12:29:39PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 14-Jul-2000 at 12:29:39 -0600, Nick Rogness wrote: > On Fri, 14 Jul 2000, Robert Watson wrote: > > > On Fri, 14 Jul 2000, Nick Rogness wrote: > > > > > > root@webfix:~>ifconfig fxp0 > > > > fxp0: flags=8843 mtu 1500 > > > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > > > > > > you have a /32 netmask on 1.4, change it to a /24 address > > > (255.255.255.0) and see if that helps. > > > > I don't have much experience with routed, but I can tell you that the /32 > > here is correct in my experience -- the two addresses are in the same /24 > > subnet. Putting both in with a netmask of /24 will cause problems due to > > muliple routing entries with the same prefix/netmask. > > > > I don't have much experience with routed either. I do agree in > "specific" situations, setting both netmasks to /24 could be a > problem. > > I have used /32 within the same network, but I binded it to the > loopback interface and used arp (pub). That might solve your Tried that (it is a different machine now for experimenting...) root@messfix2:~>ifconfig -a fxp0: flags=8843 mtu 1500 inet 192.168.17.21 netmask 0xffffff00 broadcast 192.168.17.255 ether 00:a0:c9:ca:b0:8d media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 root@messfix2:~>ifconfig lo0 192.168.17.254 netmask 0xffffff00 alias But at this moment the same error appears in the syslog: Jul 15 20:28:45 messfix2 routed[110]: possible netmask problem between lo0:192.168.17.254/32 and fxp0:192.168.17.0/24 Interestingly, it says lo0:192.168.17.254/32 but I intentionally specified 0xffffff00 ... > problems. I've also run gated without problems with this type of > setup. Well, it works here as well (both, your and my version). I think the problem lies within routed since it appeared exactly when Peter Wemm commited the changes... -Andre > > > Nick Rogness > - Speak softly and carry a Gigabit switch. > > -- Your mouse has moved. Windows NT must be restarted for the change to take effect! Reboot now? [OK] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 11:38:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id D18C537B613 for ; Sat, 15 Jul 2000 11:38:31 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e6FIcSB08905; Sat, 15 Jul 2000 20:38:28 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e6FIcRT05823; Sat, 15 Jul 2000 20:38:27 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e6FIcRa79618; Date: Sat, 15 Jul 2000 20:38:27 +0200 From: Andre Albsmeier To: Mike Tancsa Cc: Andre Albsmeier , freebsd-net@freebsd.org Subject: Re: routed: possible netmask problem ... Message-ID: <20000715203827.B11638@curry.mchp.siemens.de> References: <39705db6.118593488@mail.sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <39705db6.118593488@mail.sentex.net>; from mike@sentex.net on Sat, Jul 15, 2000 at 12:50:33PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 15-Jul-2000 at 12:50:33 +0000, Mike Tancsa wrote: > On 14 Jul 2000 12:39:05 -0400, in sentex.lists.freebsd.net you wrote: > > >Hi, > > > >I am using fxp0 with an ipalias: > > > >root@webfix:~>ifconfig fxp0 > >fxp0: flags=8843 mtu 1500 > > inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 > > inet 192.168.1.4 netmask 0xffffffff broadcast 192.168.1.4 > > ether 00:a0:c9:ca:18:64 > > media: 100baseTX status: active > > supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP > > > > > >When starting routed I always see the following error message: > > > >root@webfix:~>routed: possible netmask problem between fxp0:192.168.1.4/32 and fxp0:192.168.1.0/24 routed: Send mcast sendto(fxp0, 224.0.0.9.520): No route to host > > > > > >All that is on a 3.5-STABLE machine. Can someone tell me what I am > >doing wrong here ?!? > > You might try aliasing the loopback interface instead. And if necessary and > a static arp entry for the IP so hosts on the subnet will know where to go. Tried that (see my other email to the group). Similar error message in syslog (it is another machine now): Jul 15 20:28:45 messfix2 routed[110]: possible netmask problem between lo0:192.168.17.254/32 and fxp0:192.168.17.0/24 Thanks, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 12:16:57 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 6132837B79D; Sat, 15 Jul 2000 12:16:55 -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 MAA20589; Sat, 15 Jul 2000 12:04:39 -0700 (PDT) Message-Id: <200007151904.MAA20589@implode.root.com> To: Alfred Perlstein Cc: net@freebsd.org, dillon@freebsd.org Subject: Re: mbuf refcnt and sendfile In-reply-to: Your message of "Sat, 15 Jul 2000 06:55:06 PDT." <20000715065506.Y25571@fw.wintelcom.net> From: David Greenman Reply-To: dg@root.com Date: Sat, 15 Jul 2000 12:04:39 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >http://www.freebsd.org/cgi/query-pr.cgi?pr=19866 > >David, I'm pretty sure you didn't like the 'fix' for the mbuf >cluster refcount presented in this PR (linking all copies using >a doubly linked list), I have presented an alternative: > > Instead of keeping them in a linked list there should be an int/char * > in the mbuf header that works the same way mclrefcnt does. Instead > of managing a linked list all one has to do is copy the pointer into > the new mbuf header and increment it, and decrease it on free, when > it's zero the deref code is called. > >I was wondering what your thoughts on this are? I thought it seemed very clever. >I also had an idea to save on sf_buf's in sendfile: > > Forget about them, set the m_ext->ext_buf to point directly at the > vm_page_t backing the mbuf, you don't need the extra indirection. > >I think that could work if you did a vm_page_wire and pmap_qenter >for each mbuf ref callback and a vm_page_unwire and pmap_qremove >for each mbuf free callback. This one makes my brain hurt (too much to consider). There's only one mapping address, so multiple pmap_qenter's would be a no-op and the first pmap_qremove would remove the mapping, which is not what you want. You can't use the wire count == 0 to decide when to remove the mapping either, since it is used all over the system for other purposes. Basically, you have to have a seperate counter of sendfile consumers of the page - I don't see any way around that. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer 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 Sat Jul 15 14:27: 8 2000 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3F8A137B565; Sat, 15 Jul 2000 14:27:05 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6FLR3G26773; Sat, 15 Jul 2000 14:27:03 -0700 (PDT) Date: Sat, 15 Jul 2000 14:27:03 -0700 From: Alfred Perlstein To: David Greenman Cc: net@freebsd.org, dillon@freebsd.org Subject: Re: mbuf refcnt and sendfile Message-ID: <20000715142703.E25571@fw.wintelcom.net> References: <20000715065506.Y25571@fw.wintelcom.net> <200007151904.MAA20589@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007151904.MAA20589@implode.root.com>; from dg@root.com on Sat, Jul 15, 2000 at 12:04:39PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Greenman [000715 12:16] wrote: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=19866 > > > >David, I'm pretty sure you didn't like the 'fix' for the mbuf > >cluster refcount presented in this PR (linking all copies using > >a doubly linked list), I have presented an alternative: > > > > Instead of keeping them in a linked list there should be an int/char * > > in the mbuf header that works the same way mclrefcnt does. Instead > > of managing a linked list all one has to do is copy the pointer into > > the new mbuf header and increment it, and decrease it on free, when > > it's zero the deref code is called. > > > >I was wondering what your thoughts on this are? > > I thought it seemed very clever. The linked list method or the pointer refcount method? > >I also had an idea to save on sf_buf's in sendfile: > > > > Forget about them, set the m_ext->ext_buf to point directly at the > > vm_page_t backing the mbuf, you don't need the extra indirection. > > > >I think that could work if you did a vm_page_wire and pmap_qenter > >for each mbuf ref callback and a vm_page_unwire and pmap_qremove > >for each mbuf free callback. > > This one makes my brain hurt (too much to consider). > > There's only one mapping address, so multiple pmap_qenter's would be a > no-op and the first pmap_qremove would remove the mapping, which is not > what you want. You can't use the wire count == 0 to decide when to remove > the mapping either, since it is used all over the system for other > purposes. Basically, you have to have a seperate counter of sendfile > consumers of the page - I don't see any way around that. Ok, I see what's going on, if you have multiple sf_bufs you have the same page mapped in at different offsets (multiple times), you still need the refcount, you could hash on the object/offset and share sf_bufs with multiple sends when you have overlap, but that could pessimize the case when you have a large working set and it's unlikely to have overlap. I was trying to figure out some trick, some sort of existing refcount method for mapping pages in but I haven't found one yet. It could be useful to have a generic refcount scheme for vm pages, perhaps Andrew Gallatin would like it for his zero copy stuff so he can avoid multiple mappings. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 14:40:49 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 37A6337BBD2 for ; Sat, 15 Jul 2000 14:40:44 -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 <0FXR003RDDJU1B@falla.videotron.net> for net@FreeBSD.ORG; Sat, 15 Jul 2000 17:40:42 -0400 (EDT) Date: Sat, 15 Jul 2000 17:43:05 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf refcnt and sendfile In-reply-to: <20000715142703.E25571@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: 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 Sat, 15 Jul 2000, Alfred Perlstein wrote: > > >I was wondering what your thoughts on this are? > > > > I thought it seemed very clever. > > The linked list method or the pointer refcount method? Alfred, the linked list method turns out to be simpler overall, and much cleaner at that. Here's why: * If you implement the counter in one of the mbufs (as I suggested in my previous mbuf), you'll have to deal with extra hysterics for what concerns mbufs referring to external buffers. You'll have one mbuf which has the actual counter, and the rest which hold pointers to that counter. This method is awful (I've given it some thought) because if you free one such mbuf and it happens to be the one holding the counter, well... you get the picture. * If you implement the counter externally, you're really going back to what already existed and what this patch tries to move away from. You might as well keep the global. Cheers, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jul 15 19:44: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 5071937B5DC for ; Sat, 15 Jul 2000 19:43:57 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA19904 for ; Sun, 16 Jul 2000 11:43:55 +0900 (JST) To: net@freebsd.org In-reply-to: itojun's message of Wed, 12 Jul 2000 11:02:45 JST. <7093.963367365@localhost> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: candidate fix to INET6 if detach problem From: itojun@iijlab.net Date: Sun, 16 Jul 2000 11:43:55 +0900 Message-ID: <19902.963715435@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > if you have FreeBSD-current on laptop, please try the following diff: > http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/net/if.c.diff?r1=1.1&r2=1.2 > and let me know if it solves FreeBSD PR 17909 (panic on pccard > interface removal, if you have used IPv6 on the interface). > i'm still wondering if this should go into FreeBSD-current (and > 4STABLE) or not, so your report will be very important. this now is in the main trunc. please test. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message