From owner-freebsd-net Sun Nov 12 3:45:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id E1BDD37B479; Sun, 12 Nov 2000 03:45:10 -0800 (PST) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id NAA28675; Sun, 12 Nov 2000 13:45:05 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id NAA04100; Sun, 12 Nov 2000 13:45:02 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Sun, 12 Nov 2000 13:44:57 +0200 (EET) From: petro To: question@freebsd.org Cc: freeBSD-net@freebsd.org Subject: IPFW... 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 try to add such ipfw but receive error.. # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 00250 fwd 127.0.0.1,22 tcp from any to any 80 ipfw: setsockopt(IP_FW_ADD): Invalid argument Squid is running on 3128 port.. Thank you... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 4:36:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id D413E37B479 for ; Sun, 12 Nov 2000 04:36:49 -0800 (PST) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id OAA30619 for ; Sun, 12 Nov 2000 14:36:45 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id OAA04172 for ; Sun, 12 Nov 2000 14:36:46 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Sun, 12 Nov 2000 14:36:46 +0200 (EET) From: petro To: freebsd-net@FreeBSD.ORG Subject: IPFW problem.... 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 try to add such ipfw but receive error.. # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 00250 fwd 127.0.0.1,22 tcp from any to any 80 ipfw: setsockopt(IP_FW_ADD): Invalid argument Squid is running on 3128 port.. Thank you... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 5:10:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 535D337B479 for ; Sun, 12 Nov 2000 05:10:35 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 12 Nov 2000 13:10:33 +0000 (GMT) To: Bosko Milekic Cc: iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment In-reply-to: Your message of "Fri, 10 Nov 2000 00:54:09 EST." X-Request-Do: Date: Sun, 12 Nov 2000 13:10:32 +0000 From: David Malone Message-ID: <200011121310.aa19093@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > dwmalone, anything to add? (I modified the behavior in m_pulldown() > just a bit w.r.t. the original patch, so feel free to glance at > that). Ahhh, crap, I ment to reply to you about this before you committed it, but I've been too busy. (I'm also not on freebsd-net, so I didn't notice the post until Ian pointed it out ;-() I was talking to Ian about the ext_type stuff, and there is a problem with it. The problem is that you need to allocate a static number for each type in question, which is not good for loadable modules which might define their own types. In general people are trying to get away from fixed things like major device numbers and this seems to be just another of these things. I can think of two possible alternatives. One is to get rid of the ext_type stuff, as it doesn't really buy us anything, except maybe slightly clearer code or being able to tell the type while debugging. The other option I thought of is to use a char *. You could point to a static string describing the type of external storage. This way is still fast comparing types, just compare the pointers. If you want to know what the type is in human readable format (for debugging) you just look at the string it points at. Also the kernel allocates different addresses for different strings, so it automatically solves the problem of allocating unique numbers to each type. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 5:19:37 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 615D637B479 for ; Sun, 12 Nov 2000 05:19:34 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 12 Nov 2000 13:19:33 +0000 (GMT) To: Bosko Milekic Cc: freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment In-reply-to: Your message of "Fri, 10 Nov 2000 00:54:09 EST." X-Request-Do: Date: Sun, 12 Nov 2000 13:19:33 +0000 From: David Malone Message-ID: <200011121319.aa19357@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is an application of the M_WRITABLE macro I've been testing at home (we're also testing a cruder version in RELENG_4 in college). What this does is allows sbcompress to compress into external storage if it is writable. This can be of great help if you have lots of small packets arriving via an interface which always uses an mbuf cluster for every packet (the fxp driver is one example I think). We were frequently running out of clusters before using this patch. The limit of copying at most MCLBYTES/4 comes from BSDi, which seems to have had a similar patch in place for some time. If Bosko or someone can review this I'd like to commit it. David. Index: uipc_socket2.c =================================================================== RCS file: /cvs/FreeBSD-CVS/src/sys/kern/uipc_socket2.c,v retrieving revision 1.65 diff -u -r1.65 uipc_socket2.c --- uipc_socket2.c 2000/09/05 22:10:24 1.65 +++ uipc_socket2.c 2000/10/15 18:55:58 @@ -718,8 +718,10 @@ m = m_free(m); continue; } - if (n && (n->m_flags & (M_EXT | M_EOR)) == 0 && - (n->m_data + n->m_len + m->m_len) < &n->m_dat[MLEN] && + if (n && (n->m_flags & M_EOR) == 0 && + M_WRITABLE(n) && + (m)->m_len <= MCLBYTES / 4 && + (m)->m_len <= M_TRAILINGSPACE(n) && n->m_type == m->m_type) { bcopy(mtod(m, caddr_t), mtod(n, caddr_t) + n->m_len, (unsigned)m->m_len); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 8:21: 9 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 3291D37B479 for ; Sun, 12 Nov 2000 08:21:06 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3X00MB96QBRV@field.videotron.net> for freebsd-net@freebsd.org; Sun, 12 Nov 2000 11:20:36 -0500 (EST) Date: Sun, 12 Nov 2000 11:25:38 -0500 (EST) From: Bosko Milekic Subject: Re: M_RDONLY: review & comment In-reply-to: <200011121310.aa19093@salmon.maths.tcd.ie> X-Sender: bmilekic@jehovah.technokratis.com To: David Malone Cc: iedowse@maths.tcd.ie, freebsd-net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 12 Nov 2000, David Malone wrote: > Ahhh, crap, I ment to reply to you about this before you committed it, > but I've been too busy. (I'm also not on freebsd-net, so I didn't notice > the post until Ian pointed it out ;-() > > I was talking to Ian about the ext_type stuff, and there is a > problem with it. The problem is that you need to allocate a static > number for each type in question, which is not good for loadable > modules which might define their own types. In general people are > trying to get away from fixed things like major device numbers and > this seems to be just another of these things. Not necessarily. If you'll notice, I changed the type for if_ti, if_wb, etc. to have only ONE type, EXT_NET_DRV. The only real important type is EXT_CLUSTER, because that's the one we always check to see if it's "this one, or all the others." The others are there mainly for debugging purposes. > I can think of two possible alternatives. One is to get rid of the > ext_type stuff, as it doesn't really buy us anything, except maybe > slightly clearer code or being able to tell the type while debugging. > > The other option I thought of is to use a char *. You could point > to a static string describing the type of external storage. This > way is still fast comparing types, just compare the pointers. If > you want to know what the type is in human readable format (for > debugging) you just look at the string it points at. Also the > kernel allocates different addresses for different strings, so > it automatically solves the problem of allocating unique numbers > to each type. > > David. There are flaws with this. One is that there's no way to know ahead of time what type has what address associated to it. I think what we should do is maybe add EXT_MOD_TYPE and all the modules adding their own ext_buf's that are _not_ network drivers can use that. Seems much simpler to me. Note that this is unlike major/minor numbers in that each type does not have to be unique. Note that I will change the short ext_type to an int. It's typically faster on the alpha and it doesn't cost us anything. Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 8:31:57 2000 Delivered-To: freebsd-net@freebsd.org Received: from worldclass.jolt.nu (lgh637b.hn-krukan.AC [212.217.139.112]) by hub.freebsd.org (Postfix) with ESMTP id 9EDE937B479; Sun, 12 Nov 2000 08:31:54 -0800 (PST) Received: from localhost (c4@localhost) by worldclass.jolt.nu (8.9.3/8.9.3) with ESMTP id RAA53313; Sun, 12 Nov 2000 17:30:23 +0100 (CET) (envelope-from c4@worldclass.jolt.nu) Date: Sun, 12 Nov 2000 17:30:14 +0100 (CET) From: Tobias Fredriksson To: petro Cc: question@FreeBSD.ORG, freeBSD-net@FreeBSD.ORG Subject: Re: IPFW... 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, 12 Nov 2000, petro wrote: > Hello! > I try to add such ipfw but receive error.. > # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 > 00250 fwd 127.0.0.1,22 tcp from any to any 80 > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > Squid is running on 3128 port.. > Thank you... you get the setsockopt(IP_FW_ADD): Invalid argument statement when you have not compiled the kernel with options ipfirewall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 12:29: 2 2000 Delivered-To: freebsd-net@freebsd.org Received: from web10002.mail.yahoo.com (web10002.mail.yahoo.com [216.136.130.38]) by hub.freebsd.org (Postfix) with SMTP id 13C3B37B479 for ; Sun, 12 Nov 2000 12:29:00 -0800 (PST) Message-ID: <20001112202859.6614.qmail@web10002.mail.yahoo.com> Received: from [148.221.61.169] by web10002.mail.yahoo.com; Sun, 12 Nov 2000 12:28:59 PST Date: Sun, 12 Nov 2000 12:28:59 -0800 (PST) From: Julio Cesar Ortega Moreno Subject: i need a drives for REALTEK RTL8139A FAST ETHERNET To: net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you has a drive for REALTEK RTL8139A FAST ETHERNET please send me to juliortega73@yahoo.com thanks __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 12:41:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id BED2437B686 for ; Sun, 12 Nov 2000 12:41:30 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13v3xD-00009s-00; Sun, 12 Nov 2000 13:42:20 -0700 Message-ID: <3A0F00AB.519E1D1@softweyr.com> Date: Sun, 12 Nov 2000 13:42:19 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julio Cesar Ortega Moreno Cc: net@FreeBSD.ORG Subject: Re: i need a drives for REALTEK RTL8139A FAST ETHERNET References: <20001112202859.6614.qmail@web10002.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julio Cesar Ortega Moreno wrote: > > If you has a drive for REALTEK RTL8139A FAST ETHERNET > please send me to juliortega73@yahoo.com The rl driver in FreeBSD supports the RTL8139A just fine. We can't send you FreeBSD, but you can download it. http://www.freebsd.org/ -- "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 Sun Nov 12 12:49:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id AA86D37B479; Sun, 12 Nov 2000 12:49:38 -0800 (PST) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id WAA50661; Sun, 12 Nov 2000 22:49:34 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id WAA05286; Sun, 12 Nov 2000 22:49:39 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Sun, 12 Nov 2000 22:49:39 +0200 (EET) From: petro To: Tobias Fredriksson Cc: question@FreeBSD.ORG, freeBSD-net@FreeBSD.ORG Subject: Re: IPFW... 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 I have some ipfw that works fine, but when I try to add this I receive such error..... On Sun, 12 Nov 2000, Tobias Fredriksson wrote: > > > On Sun, 12 Nov 2000, petro wrote: > > > Hello! > > I try to add such ipfw but receive error.. > > # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 > > 00250 fwd 127.0.0.1,22 tcp from any to any 80 > > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > > > Squid is running on 3128 port.. > > Thank you... > > you get the setsockopt(IP_FW_ADD): Invalid argument statement when you > have not compiled the kernel with options ipfirewall > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 12:56:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id CE47137B479 for ; Sun, 12 Nov 2000 12:56:44 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 12 Nov 2000 20:56:43 +0000 (GMT) To: Bosko Milekic Cc: David Malone , iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment In-reply-to: Your message of "Sun, 12 Nov 2000 11:25:38 EST." X-Request-Do: Date: Sun, 12 Nov 2000 20:56:42 +0000 From: David Malone Message-ID: <200011122056.aa55963@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Not necessarily. If you'll notice, I changed the type for if_ti, > if_wb, etc. to have only ONE type, EXT_NET_DRV. The only real important > type is EXT_CLUSTER, because that's the one we always check to see if > it's "this one, or all the others." The others are there mainly for > debugging purposes. Ahh - OK - I missed that. It still seems possible that it might be better to just have a M_ISCLUSTER flag instead. > > The other option I thought of is to use a char *. You could point > > to a static string describing the type of external storage. [snip] > There are flaws with this. One is that there's no way to know ahead > of time what type has what address associated to it. As you point out, we really only need to test for clusters and it would be easy enough to export the address of this and have the linker do the work. Strings would be more valueable while debugging, but given that you're the person most likely to be debugging the mbuf code... ;-) > I think what we > should do is maybe add EXT_MOD_TYPE and all the modules adding their own > ext_buf's that are _not_ network drivers can use that. Seems much simpler > to me. Note that this is unlike major/minor numbers in that each type > does not have to be unique. Sounds reasonable, but again raises the question of why do we have the type field anyway. (Just while I'm thinking of it, I wonder if it is worth implimenting a 8K jumbo cluster type which any Gb/s ethernet driver could use? I guess we should ask Bill Paul and Matt Jacob if they think it would be useful.) > Note that I will change the short ext_type to an int. It's typically > faster on the alpha and it doesn't cost us anything. Cool - I guess we have tons of space left at the end of mbufs with external storage? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 18:52:28 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id C068337B479; Sun, 12 Nov 2000 18:52:25 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA95651; Sun, 12 Nov 2000 18:52:14 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eAD2qED17117; Sun, 12 Nov 2000 18:52:14 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200011130252.eAD2qED17117@curve.dellroad.org> Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <20001108200359.A38693@sunbay.com> "from Ruslan Ermilov at Nov 8, 2000 08:03:59 pm" To: Ruslan Ermilov Date: Sun, 12 Nov 2000 18:52:13 -0800 (PST) Cc: net@FreeBSD.ORG, Charles Mott , Ari Suutari X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > The DifferentialChecksum() function in libalias(3) is used > to efficiently recompute the checksum for altered packets. > Unfortunately, the implementation suffers from the problem > described in RFC 1624. I have implemented the replacement > for it, using the final formula [4] from the RFC. > > The attached C program demonstrates the problem as well as > the new implementation. > > Comments? Wow.. seems like a pretty important thing to fix. We should try to get this into 4.2 if possible. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 22: 5:49 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (mail.rv.scientech.com [198.60.89.9]) by hub.freebsd.org (Postfix) with ESMTP id 5E1BF37B479; Sun, 12 Nov 2000 22:05:46 -0800 (PST) Received: from carcassonne (carcassonne.scientech.com [10.10.25.250]) by if.scientech.com (8.9.3/8.9.3) with ESMTP id XAA18454; Sun, 12 Nov 2000 23:04:11 -0700 Date: Sun, 12 Nov 2000 23:04:10 -0700 (MST) From: Charles Mott To: Archie Cobbs Cc: Ruslan Ermilov , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <200011130252.eAD2qED17117@curve.dellroad.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 Sun, 12 Nov 2000, Archie Cobbs wrote: > Ruslan Ermilov writes: > > The DifferentialChecksum() function in libalias(3) is used > > to efficiently recompute the checksum for altered packets. > > Unfortunately, the implementation suffers from the problem > > described in RFC 1624. I have implemented the replacement > > for it, using the final formula [4] from the RFC. > > > > The attached C program demonstrates the problem as well as > > the new implementation. > > > > Comments? > > Wow.. seems like a pretty important thing to fix. > We should try to get this into 4.2 if possible. I haven't studied the arithmetic yet, but the problem cannot be too serious, or a lot of things would break. My guess is that this has to be an "edge effect". Since Ruslan's example program showed a delta of 1 for so many cases, I'm not sure what it means yet. I would agree that if there is a problem, it should be fixed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 12 23:31: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (mail.rv.scientech.com [198.60.89.9]) by hub.freebsd.org (Postfix) with ESMTP id 3E8CB37B479; Sun, 12 Nov 2000 23:31:04 -0800 (PST) Received: from carcassonne (carcassonne.scientech.com [10.10.25.250]) by if.scientech.com (8.9.3/8.9.3) with ESMTP id AAA32248; Mon, 13 Nov 2000 00:29:32 -0700 Date: Mon, 13 Nov 2000 00:29:32 -0700 (MST) From: Charles Mott To: Archie Cobbs Cc: Ruslan Ermilov , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum 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 Ok, ok -- Ruslan is mathematically correct, but the problem is really neglible, because of how checksums are commonly verified. Even if DifferentialChecksum() incorrectly produces a 0xffff instead of 0x0000, this error does not affect the verification sum computed by a recipient machine. To quote from RF 1624: If an end system verifies the checksum by including the checksum field itself in the one's complement sum and then comparing the result against -0, as recommended by RFC 1071, it does not matter if an intermediate system generated a -0 instead of +0 due to the RFC 1141 property described here. It would be interesting to do some network surveillance to see how often 0xffff shows up in checksum fields. -- Charles Mott On Sun, 12 Nov 2000, Charles Mott wrote: > On Sun, 12 Nov 2000, Archie Cobbs wrote: > > Ruslan Ermilov writes: > > > The DifferentialChecksum() function in libalias(3) is used > > > to efficiently recompute the checksum for altered packets. > > > Unfortunately, the implementation suffers from the problem > > > described in RFC 1624. I have implemented the replacement > > > for it, using the final formula [4] from the RFC. > > > > > > The attached C program demonstrates the problem as well as > > > the new implementation. > > > > > > Comments? > > > > Wow.. seems like a pretty important thing to fix. > > We should try to get this into 4.2 if possible. > > I haven't studied the arithmetic yet, but the problem > cannot be too serious, or a lot of things would break. > My guess is that this has to be an "edge effect". > Since Ruslan's example program showed a delta of 1 > for so many cases, I'm not sure what it means yet. > > I would agree that if there is a problem, it should > be fixed. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 0: 1:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B306737B4C5 for ; Mon, 13 Nov 2000 00:01:43 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAD81Tt35641; Mon, 13 Nov 2000 10:01:29 +0200 (EET) (envelope-from ru) Date: Mon, 13 Nov 2000 10:01:29 +0200 From: Ruslan Ermilov To: petro Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW problem.... Message-ID: <20001113100129.B34671@sunbay.com> Mail-Followup-To: petro , freebsd-net@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from petro@She.wertep.com on Sun, Nov 12, 2000 at 02:36:46PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 12, 2000 at 02:36:46PM +0200, petro wrote: > Hello! > I try to add such ipfw but receive error.. > # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 > 00250 fwd 127.0.0.1,22 tcp from any to any 80 > ipfw: setsockopt(IP_FW_ADD): Invalid argument > The kernel must have been compiled with the IPFIREWALL_FORWARD option. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 0:40: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id CF8E837B479 for ; Mon, 13 Nov 2000 00:39:40 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAD8crq37949; Mon, 13 Nov 2000 10:38:53 +0200 (EET) (envelope-from ru) Date: Mon, 13 Nov 2000 10:38:53 +0200 From: Ruslan Ermilov To: Charles Mott Cc: Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001113103852.E34671@sunbay.com> Mail-Followup-To: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cmott@scientech.com on Mon, Nov 13, 2000 at 12:29:32AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 13, 2000 at 12:29:32AM -0700, Charles Mott wrote: > Ok, ok -- Ruslan is mathematically correct, but > the problem is really neglible, because of how checksums > are commonly verified. Even if DifferentialChecksum() > incorrectly produces a 0xffff instead of 0x0000, this error > does not affect the verification sum computed by a recipient > machine. > > To quote from RF 1624: > > If an end system verifies the checksum by including the checksum > field itself in the one's complement sum and then comparing the > result against -0, as recommended by RFC 1071, it does not matter if > an intermediate system generated a -0 instead of +0 due to the RFC > 1141 property described here. > That's true but it does not mean that there is no problem. The checksum value of 0xffff is incorrect, because one's complement sum is guaranteed to be a non-zero if at least one item is non-zero (which is the case for IP header -- protocol field is non-zero). Actually I do not understand at all how DifferentialChecksum() works currently. What mathematica it is based on? > It would be interesting to do some network surveillance > to see how often 0xffff shows up in checksum fields. > I don't think too often, but it doesn't matter. The bug is there, and should be fixed. I am actually going to commit another patch to libalias(3). It uses the formula 3 from the above mentioned RFC, and is more straightforward to understand. It also has the plus in that you can freely change the signedness of accumulator without affecting the end result. I am attaching the patch here for those interested. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --IS0zKkzwUGydFO0o Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 9 Nov 2000 17:36:29 +0200 From: Ruslan Ermilov To: Brian Somers , Ari Suutari Cc: Charles Mott , Erik Salander Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001109173629.A72896@sunbay.com> References: <20001108200359.A38693@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001108200359.A38693@sunbay.com>; from ru@FreeBSD.org on Wed, Nov 08, 2000 at 08:03:59PM +0200 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 08, 2000 at 08:03:59PM +0200, Ruslan Ermilov wrote: > Hi! > > The DifferentialChecksum() function in libalias(3) is used > to efficiently recompute the checksum for altered packets. > Unfortunately, the implementation suffers from the problem > described in RFC 1624. I have implemented the replacement > for it, using the final formula [4] from the RFC. > I am going to commit the following patch to libalias(3) on Monday until I get any objections or "wait" requests from you till that time. It uses the fomula 3 (rather than 4) from the above mentioned RFC. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: alias_util.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_util.c,v retrieving revision 1.5 diff -u -p -r1.5 alias_util.c --- alias_util.c 2000/04/05 07:45:39 1.5 +++ alias_util.c 2000/11/09 15:18:59 @@ -34,7 +34,7 @@ purposes); u_short PacketAliasInternetChecksum(u_short *ptr, int nbytes) { - int sum, oddbyte; + u_int sum, oddbyte; sum = 0; while (nbytes > 1) @@ -68,7 +68,7 @@ TcpChecksum(struct ip *pip) u_short *ptr; struct tcphdr *tc; int nhdr, ntcp, nbytes; - int sum, oddbyte; + u_int sum, oddbyte; nhdr = pip->ip_hl << 2; ntcp = ntohs(pip->ip_len) - nhdr; @@ -111,31 +111,23 @@ TcpChecksum(struct ip *pip) } +/* + * Incremental Update of Internet Checksum using [Eqn. 3] from RFC 1624. + */ void DifferentialChecksum(u_short *cksum, u_short *new, u_short *old, int n) { int i; - int accumulate; + u_int accumulate; - accumulate = *cksum; + accumulate = (u_short)~*cksum; for (i=0; i> 16) + (accumulate & 0xffff); - accumulate += accumulate >> 16; - *cksum = (u_short) ~accumulate; - } - else - { - accumulate = (accumulate >> 16) + (accumulate & 0xffff); - accumulate += accumulate >> 16; - *cksum = (u_short) accumulate; - } + accumulate = (accumulate >> 16) + (accumulate & 0xffff); + accumulate += accumulate >> 16; + *cksum = (u_short)~accumulate; } - Index: alias_local.h =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_local.h,v retrieving revision 1.18 diff -u -p -r1.18 alias_local.h --- alias_local.h 2000/10/30 17:24:12 1.18 +++ alias_local.h 2000/11/09 15:18:59 @@ -28,29 +28,19 @@ */ /* - The following macro is used to update an - internet checksum. "delta" is a 32-bit - accumulation of all the changes to the - checksum (adding in new 16-bit words and - subtracting out old words), and "cksum" - is the checksum value to be updated. -*/ + * The following macro is used to update an internet checksum. + * "acc" is a 32-bit accumulation of all the changes to the checksum + * (adding in all new 16-bit words and 16-bit one's complements of + * old 16-bit words), and "cksum" is the checksum value to be updated. + */ #define ADJUST_CHECKSUM(acc, cksum) { \ - acc += cksum; \ - if (acc < 0) \ - { \ - acc = -acc; \ - acc = (acc >> 16) + (acc & 0xffff); \ - acc += acc >> 16; \ - cksum = (u_short) ~acc; \ - } \ - else \ - { \ - acc = (acc >> 16) + (acc & 0xffff); \ - acc += acc >> 16; \ - cksum = (u_short) acc; \ - } \ + (acc) += (u_short)~(cksum); \ + (acc) = ((acc) >> 16) + ((acc) & 0xffff); \ + (acc) += (acc) >> 16; \ + (cksum) = (u_short)~(acc); \ } +#define NEW(new) ((u_short) (new)) +#define OLD(old) ((u_short)~(old)) /* Index: alias.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias.c,v retrieving revision 1.27 diff -u -p -r1.27 alias.c --- alias.c 2000/10/30 17:24:12 1.27 +++ alias.c 2000/11/09 15:18:59 @@ -259,8 +259,8 @@ IcmpAliasIn1(struct ip *pip) original_id = GetOriginalPort(link); /* Adjust ICMP checksum */ - accumulate = ic->icmp_id; - accumulate -= original_id; + accumulate = OLD(ic->icmp_id); + accumulate += NEW(original_id); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* Put original sequence number back in */ @@ -333,13 +333,13 @@ IcmpAliasIn2(struct ip *pip) /* Adjust ICMP checksum */ sptr = (u_short *) &(ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; - accumulate += ud->uh_sport; - accumulate -= original_port; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); + accumulate += OLD(ud->uh_sport); + accumulate += NEW(original_port); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* Un-alias address in IP header */ @@ -366,13 +366,13 @@ fragment contained in ICMP data section /* Adjust ICMP checksum */ sptr = (u_short *) &(ip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; - accumulate += ic2->icmp_id; - accumulate -= original_id; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); + accumulate += OLD(ic2->icmp_id); + accumulate += NEW(original_id); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* Un-alias address in IP header */ @@ -452,8 +452,8 @@ IcmpAliasOut1(struct ip *pip) alias_id = GetAliasPort(link); /* Since data field is being modified, adjust ICMP checksum */ - accumulate = ic->icmp_id; - accumulate -= alias_id; + accumulate = OLD(ic->icmp_id); + accumulate += NEW(alias_id); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* Alias sequence number */ @@ -527,13 +527,13 @@ IcmpAliasOut2(struct ip *pip) /* Adjust ICMP checksum */ sptr = (u_short *) &(ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; - accumulate += ud->uh_dport; - accumulate -= alias_port; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); + accumulate += OLD(ud->uh_dport); + accumulate += NEW(alias_port); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* @@ -565,13 +565,13 @@ fragment contained in ICMP data section /* Adjust ICMP checksum */ sptr = (u_short *) &(ip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; - accumulate += ic2->icmp_id; - accumulate -= alias_id; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); + accumulate += OLD(ic2->icmp_id); + accumulate += NEW(alias_id); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* @@ -748,14 +748,14 @@ UdpAliasIn(struct ip *pip) /* is being unaliased and destination address is being altered. */ if (ud->uh_sum != 0) { - accumulate = alias_port; - accumulate -= ud->uh_dport; + accumulate = OLD(alias_port); + accumulate += NEW(ud->uh_dport); sptr = (u_short *) &alias_address; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); ADJUST_CHECKSUM(accumulate, ud->uh_sum) } @@ -819,14 +819,14 @@ UdpAliasOut(struct ip *pip) int accumulate; u_short *sptr; - accumulate = ud->uh_sport; - accumulate -= alias_port; + accumulate = OLD(ud->uh_sport); + accumulate += NEW(alias_port); sptr = (u_short *) &(pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); ADJUST_CHECKSUM(accumulate, ud->uh_sum) } @@ -883,29 +883,29 @@ TcpAliasIn(struct ip *pip) /* Adjust TCP checksum since destination port is being unaliased */ /* and destination port is being altered. */ - accumulate = alias_port; - accumulate -= tc->th_dport; + accumulate = OLD(alias_port); + accumulate += NEW(tc->th_dport); sptr = (u_short *) &alias_address; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); /* If this is a proxy, then modify the TCP source port and checksum accumulation */ if (proxy_port != 0) { - accumulate += tc->th_sport; + accumulate += OLD(tc->th_sport); tc->th_sport = proxy_port; - accumulate -= tc->th_sport; + accumulate += NEW(tc->th_sport); sptr = (u_short *) &pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &proxy_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); } /* See if ACK number needs to be modified */ @@ -917,12 +917,12 @@ TcpAliasIn(struct ip *pip) if (delta != 0) { sptr = (u_short *) &tc->th_ack; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); tc->th_ack = htonl(ntohl(tc->th_ack) - delta); sptr = (u_short *) &tc->th_ack; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); } } @@ -930,24 +930,24 @@ TcpAliasIn(struct ip *pip) /* Restore original IP address */ sptr = (u_short *) &pip->ip_dst; - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); pip->ip_dst = original_address; sptr = (u_short *) &pip->ip_dst; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); /* If this is a transparent proxy packet, then modify the source address */ if (proxy_address.s_addr != 0) { sptr = (u_short *) &pip->ip_src; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); pip->ip_src = proxy_address; sptr = (u_short *) &pip->ip_src; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); } ADJUST_CHECKSUM(accumulate, pip->ip_sum); @@ -987,26 +987,26 @@ TcpAliasOut(struct ip *pip, int maxpacke int accumulate; u_short *sptr; - accumulate = tc->th_dport; + accumulate = OLD(tc->th_dport); tc->th_dport = proxy_server_port; - accumulate -= tc->th_dport; + accumulate += NEW(tc->th_dport); sptr = (u_short *) &(pip->ip_dst); - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &proxy_server_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); ADJUST_CHECKSUM(accumulate, tc->th_sum); sptr = (u_short *) &(pip->ip_dst); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); pip->ip_dst = proxy_server_address; sptr = (u_short *) &(pip->ip_dst); - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); ADJUST_CHECKSUM(accumulate, pip->ip_sum); } @@ -1055,16 +1055,16 @@ TcpAliasOut(struct ip *pip, int maxpacke /* Adjust TCP checksum since source port is being aliased */ /* and source address is being altered */ - accumulate = tc->th_sport; + accumulate = OLD(tc->th_sport); tc->th_sport = alias_port; - accumulate -= tc->th_sport; + accumulate += NEW(tc->th_sport); sptr = (u_short *) &(pip->ip_src); - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &alias_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); /* Modify sequence number if necessary */ if (GetAckModified(link) == 1) @@ -1075,12 +1075,12 @@ TcpAliasOut(struct ip *pip, int maxpacke if (delta != 0) { sptr = (u_short *) &tc->th_seq; - accumulate += *sptr++; - accumulate += *sptr; + accumulate += OLD(*sptr++); + accumulate += OLD(*sptr); tc->th_seq = htonl(ntohl(tc->th_seq) + delta); sptr = (u_short *) &tc->th_seq; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); } } @@ -1088,12 +1088,12 @@ TcpAliasOut(struct ip *pip, int maxpacke /* Change source address */ sptr = (u_short *) &(pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); pip->ip_src = alias_address; sptr = (u_short *) &(pip->ip_src); - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); ADJUST_CHECKSUM(accumulate, pip->ip_sum) @@ -1466,19 +1466,19 @@ PacketUnaliasOut(char *ptr, /* /* Adjust TCP/UDP checksum */ sptr = (u_short *) &(pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); if (pip->ip_p == IPPROTO_UDP) { - accumulate += ud->uh_sport; - accumulate -= original_port; + accumulate += OLD(ud->uh_sport); + accumulate += NEW(original_port); ADJUST_CHECKSUM(accumulate, ud->uh_sum) } else { - accumulate += tc->th_sport; - accumulate -= original_port; + accumulate += OLD(tc->th_sport); + accumulate += NEW(original_port); ADJUST_CHECKSUM(accumulate, tc->th_sum) } @@ -1509,13 +1509,13 @@ PacketUnaliasOut(char *ptr, /* /* Adjust ICMP checksum */ sptr = (u_short *) &(pip->ip_src); - accumulate = *sptr++; - accumulate += *sptr; + accumulate = OLD(*sptr++); + accumulate += OLD(*sptr); sptr = (u_short *) &original_address; - accumulate -= *sptr++; - accumulate -= *sptr; - accumulate += ic->icmp_id; - accumulate -= original_id; + accumulate += NEW(*sptr++); + accumulate += NEW(*sptr); + accumulate += OLD(ic->icmp_id); + accumulate += NEW(original_id); ADJUST_CHECKSUM(accumulate, ic->icmp_cksum) /* Adjust IP checksum */ Index: alias_nbt.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_nbt.c,v retrieving revision 1.5 diff -u -p -r1.5 alias_nbt.c --- alias_nbt.c 2000/08/31 12:54:55 1.5 +++ alias_nbt.c 2000/11/09 15:18:59 @@ -233,14 +233,14 @@ int AliasHandleUdpNbt( if ( uh->uh_sum != 0 ) { int acc; u_short *sptr; - acc = ndh->source_port; - acc -= alias_port; + acc = OLD(ndh->source_port); + acc += NEW(alias_port); sptr = (u_short *) &(ndh->source_ip); - acc += *sptr++; - acc += *sptr; + acc += OLD(*sptr++); + acc += OLD(*sptr); sptr = (u_short *) alias_address; - acc -= *sptr++; - acc -= *sptr; + acc += NEW(*sptr++); + acc += NEW(*sptr); ADJUST_CHECKSUM(acc, uh->uh_sum) } ndh->source_ip = *alias_address; @@ -353,11 +353,11 @@ AliasHandleResourceNB( u_short *sptr; sptr = (u_short *) &(nb->addr); - acc = *sptr++; - acc += *sptr; + acc = OLD(*sptr++); + acc += OLD(*sptr); sptr = (u_short *) &(nbtarg->newaddr); - acc -= *sptr++; - acc -= *sptr; + acc += NEW(*sptr++); + acc += NEW(*sptr); ADJUST_CHECKSUM(acc, *nbtarg->uh_sum) } @@ -421,11 +421,11 @@ AliasHandleResourceA( u_short *sptr; sptr = (u_short *) &(a->addr); /* Old */ - acc = *sptr++; - acc += *sptr; + acc = OLD(*sptr++); + acc += OLD(*sptr); sptr = (u_short *) &nbtarg->newaddr; /* New */ - acc -= *sptr++; - acc -= *sptr; + acc += NEW(*sptr++); + acc += NEW(*sptr); ADJUST_CHECKSUM(acc, *nbtarg->uh_sum) } Index: alias_pptp.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_pptp.c,v retrieving revision 1.4 diff -u -p -r1.4 alias_pptp.c --- alias_pptp.c 2000/10/30 12:39:41 1.4 +++ alias_pptp.c 2000/11/09 15:19:00 @@ -177,14 +177,14 @@ AliasHandlePptpOut(struct ip *pip, / } if (pptp_link != NULL) { - int accumulate = cptr->cid1; + int accumulate = OLD(cptr->cid1); /* alias the Call Id */ cptr->cid1 = GetAliasPort(pptp_link); /* Compute TCP checksum for revised packet */ tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); - accumulate -= cptr->cid1; + accumulate += NEW(cptr->cid1); ADJUST_CHECKSUM(accumulate, tc->th_sum); switch (ctl_type) { @@ -247,14 +247,14 @@ AliasHandlePptpIn(struct ip *pip, /* *pcall_id); if (pptp_link != NULL) { - int accumulate = *pcall_id; + int accumulate = OLD(*pcall_id); /* De-alias the Peer's Call Id. */ *pcall_id = GetOriginalPort(pptp_link); /* Compute TCP checksum for modified packet */ tc = (struct tcphdr *) ((char *) pip + (pip->ip_hl << 2)); - accumulate -= *pcall_id; + accumulate += NEW(*pcall_id); ADJUST_CHECKSUM(accumulate, tc->th_sum); if (ctl_type == PPTP_OutCallReply || ctl_type == PPTP_InCallReply) { Index: alias_proxy.c =================================================================== RCS file: /home/ncvs/src/lib/libalias/alias_proxy.c,v retrieving revision 1.5 diff -u -p -r1.5 alias_proxy.c --- alias_proxy.c 2000/08/29 21:34:55 1.5 +++ alias_proxy.c 2000/11/09 15:19:00 @@ -326,9 +326,9 @@ ProxyEncodeTcpStream(struct alias_link * { int accumulate; - accumulate = pip->ip_len; + accumulate = OLD(pip->ip_len); pip->ip_len = htons(ntohs(pip->ip_len) + slen); - accumulate -= pip->ip_len; + accumulate += NEW(pip->ip_len); ADJUST_CHECKSUM(accumulate, pip->ip_sum); } @@ -385,18 +385,18 @@ ProxyEncodeIpHeader(struct ip *pip, u_short *sptr; sptr = (u_short *) option; - accumulate = 0; + accumulate = OLD(0); for (i=0; iip_hl += OPTION_LEN_INT32; - accumulate -= *sptr; + accumulate += NEW(*sptr); - accumulate += pip->ip_len; + accumulate += OLD(pip->ip_len); pip->ip_len = htons(ntohs(pip->ip_len) + OPTION_LEN_BYTES); - accumulate -= pip->ip_len; + accumulate += NEW(pip->ip_len); ADJUST_CHECKSUM(accumulate, pip->ip_sum); } --BXVAT5kNtrzKuDFl-- --IS0zKkzwUGydFO0o-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 7:40:20 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (mail.rv.scientech.com [198.60.89.9]) by hub.freebsd.org (Postfix) with ESMTP id 4F17737B479; Mon, 13 Nov 2000 07:40:18 -0800 (PST) Received: from carcassonne (carcassonne.scientech.com [10.10.25.250]) by if.scientech.com (8.9.3/8.9.3) with ESMTP id IAA00647; Mon, 13 Nov 2000 08:38:47 -0700 Date: Mon, 13 Nov 2000 08:38:46 -0700 (MST) From: Charles Mott To: Ruslan Ermilov Cc: Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <20001113103852.E34671@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Nov 2000, Ruslan Ermilov wrote: > On Mon, Nov 13, 2000 at 12:29:32AM -0700, Charles Mott wrote: > > Ok, ok -- Ruslan is mathematically correct, but > > the problem is really neglible, because of how checksums > > are commonly verified. Even if DifferentialChecksum() > > incorrectly produces a 0xffff instead of 0x0000, this error > > does not affect the verification sum computed by a recipient > > machine. > > > > To quote from RF 1624: > > > > If an end system verifies the checksum by including the checksum > > field itself in the one's complement sum and then comparing the > > result against -0, as recommended by RFC 1071, it does not matter if > > an intermediate system generated a -0 instead of +0 due to the RFC > > 1141 property described here. > > > That's true but it does not mean that there is no problem. The checksum > value of 0xffff is incorrect, because one's complement sum is guaranteed > to be a non-zero if at least one item is non-zero (which is the case for > IP header -- protocol field is non-zero). It should be corrected. I was just tryng to understand why it has not caused any noticeable problem since 1996. > > Actually I do not understand at all how DifferentialChecksum() works > currently. What mathematica it is based on? I just worked it out myself -- I was unaware of the +0 and -0 paradox. Apparently, I replicated the behavior of RFC 1141 (which is superseded by RFC 1624). Charles Mott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 8:16: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from css-1.cs.iastate.edu (css-1.cs.iastate.edu [129.186.3.24]) by hub.freebsd.org (Postfix) with ESMTP id 8A27837B479 for ; Mon, 13 Nov 2000 08:15:59 -0800 (PST) Received: from popeye.cs.iastate.edu (ghelmer@popeye.cs.iastate.edu [129.186.3.4]) by css-1.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id KAA24116; Mon, 13 Nov 2000 10:15:56 -0600 (CST) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.9.0/8.9.0) with ESMTP id KAA08775; Mon, 13 Nov 2000 10:15:53 -0600 (CST) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Mon, 13 Nov 2000 10:15:52 -0600 (CST) From: Guy Helmer To: Mikel Cc: net@FreeBSD.ORG Subject: Re: "arp: XX is on xx0 but got reply from YY on yy0" message In-Reply-To: <3A0C1163.82FDA989@upan.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 Fri, 10 Nov 2000, Mikel wrote: > could you maybe send a copy (or a mock copy) of your rc.conf files? The relevant lines from rc.conf would look like: network_interfaces="lo0 dc0 aue0" ifconfig_dc0="up" ifconfig_aue0="inet 10.0.0.1 netmask 255.255.255.0" > Guy Helmer wrote: > > > I'm working with a situation where a machine will have two interfaces on > > the same Ethernet segment. One interface does not have an IP address and > > is in promiscuous mode to listen to the segment; the other interface has > > an IP address and is running normally. The kernel logs a lot of "arp: XX > > is on xx0 but got reply from YY on yy0" messages. > > > > Questions also appear on the FreeBSD lists asking about this message when > > people have multiple interfaces in different IP subnets on the same wire. > > > > >From reading the source in for in_arpinput() in > > /sys/netinet/if_ether.c, it appears that the kernel just logs this message > > and harmlessly tosses the packet. If this *is* harmless, would it be OK > > to make the log message conditional on a sysctl toggle? > > > > Guy I'm proposing a sysctl, such as net.link.ether.inet.disablearpwarning, that would turn off the arp warning messages if the variable were set to a non-zero value. Untested patch: Index: if_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v retrieving revision 1.72 diff -u -r1.72 if_ether.c --- if_ether.c 2000/07/13 19:31:01 1.72 +++ if_ether.c 2000/11/13 16:11:51 @@ -102,6 +102,7 @@ static int arp_maxtries = 5; static int useloopback = 1; /* use loopback interface for local traffic */ static int arp_proxyall = 0; +static int disable_arp_warning = 0; SYSCTL_INT(_net_link_ether_inet, OID_AUTO, maxtries, CTLFLAG_RW, &arp_maxtries, 0, ""); @@ -109,6 +110,8 @@ &useloopback, 0, ""); SYSCTL_INT(_net_link_ether_inet, OID_AUTO, proxyall, CTLFLAG_RW, &arp_proxyall, 0, ""); +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, disablearpwarning, CTLFLAG_RW, + &disable_arp_warning, 0, ""); static void arp_rtrequest __P((int, struct rtentry *, struct sockaddr *)); static void arprequest __P((struct arpcom *, @@ -557,11 +560,12 @@ if (la && (rt = la->la_rt) && (sdl = SDL(rt->rt_gateway))) { #ifndef BRIDGE /* the following is not an error when doing bridging */ if (rt->rt_ifp != &ac->ac_if) { - log(LOG_ERR, "arp: %s is on %s%d but got reply from %6D on %s%d\n", - inet_ntoa(isaddr), - rt->rt_ifp->if_name, rt->rt_ifp->if_unit, - ea->arp_sha, ":", - ac->ac_if.if_name, ac->ac_if.if_unit); + if (!disable_arp_warning) + log(LOG_ERR, "arp: %s is on %s%d but got reply from %6D on %s%d\n", + inet_ntoa(isaddr), + rt->rt_ifp->if_name, rt->rt_ifp->if_unit, + ea->arp_sha, ":", + ac->ac_if.if_name, ac->ac_if.if_unit); goto reply; } #endif Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science Research Assistant, Dept. of Computer Science --- ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 10:13:44 2000 Delivered-To: freebsd-net@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id E8FF037B4C5 for ; Mon, 13 Nov 2000 10:13:41 -0800 (PST) Received: from 98wkst ([209.16.228.146]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id NAA01100 for ; Mon, 13 Nov 2000 13:15:27 -0500 Reply-To: From: "Peter Brezny" To: Subject: bind9 Date: Mon, 13 Nov 2000 13:13:43 -0500 Message-ID: <001401c04d9d$7630fca0$92e410d1@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a good reason not to start using bind version 9 with a new install of freebsd-stable? Peter Brezny SysAdmin Services, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 18:33: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 5B08E37B4C5 for ; Mon, 13 Nov 2000 18:32:57 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 13vVtE-0004su-00; Tue, 14 Nov 2000 02:32:04 +0000 Date: Tue, 14 Nov 2000 02:32:04 +0000 From: Tony Finch To: David Malone Cc: Bosko Milekic , iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment Message-ID: <20001114023204.A18645@hand.dotat.at> References: <200011122056.aa55963@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011122056.aa55963@salmon.maths.tcd.ie> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Malone wrote: > >(Just while I'm thinking of it, I wonder if it is worth implimenting >a 8K jumbo cluster type which any Gb/s ethernet driver could use? I >guess we should ask Bill Paul and Matt Jacob if they think it would >be useful.) But 8K isn't big enough for 9K jumbo frames. Tony. -- en oeccget g mtcaa f.a.n.finch v spdlkishrhtewe y dot@dotat.at eatp o v eiti i d. fanf@covalent.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 20:49:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id C30D037B479 for ; Mon, 13 Nov 2000 20:49:10 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id AFDBDE4F0C; Mon, 13 Nov 2000 23:48:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 9B945E4F0B; Mon, 13 Nov 2000 23:48:41 -0500 (EST) Date: Mon, 13 Nov 2000 23:48:41 -0500 (EST) From: "Richard A. Steenbergen" To: Tony Finch Cc: David Malone , Bosko Milekic , iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment In-Reply-To: <20001114023204.A18645@hand.dotat.at> 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, 14 Nov 2000, Tony Finch wrote: > David Malone wrote: > > > >(Just while I'm thinking of it, I wonder if it is worth implimenting > >a 8K jumbo cluster type which any Gb/s ethernet driver could use? I > >guess we should ask Bill Paul and Matt Jacob if they think it would > >be useful.) > > But 8K isn't big enough for 9K jumbo frames. The goal of 9k frames is 8k of data and room for lots of headers... -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 13 21:10: 5 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 9382837B479 for ; Mon, 13 Nov 2000 21:10:00 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.0/8.11.0) with SMTP id eAE59Rx44585; Tue, 14 Nov 2000 00:09:27 -0500 (EST) From: Mike Tancsa To: mikey@kappaisle.com (Mike) Cc: freebsd-net@freebsd.org Subject: Re: VPN over PPPoE (racoon at fault?) Date: Tue, 14 Nov 2000 00:09:27 -0500 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 9 Nov 2000 17:01:58 -0500, in sentex.lists.freebsd.net you wrote: >Hi all, > >Has anyone ever successfully configured VPN (using IPSec protocol) over >PPPoE connection? I have 1 VPN configured over 2 locations with T1 >connections without any problem (using the KAME IPSec on FreeBSD >4.1.1). However, when I tried the same configuration with the 3rd >location running DSL, it seems the IPSec packets can't reach out via = tun0 >device. I can do it with manual keying, but not with racoon. Both transport and tunnel mode work for me, but neither works with racoon. NAT is a bit tricky, but then again with tunnel mode, it doesnt really matter. One end is 4.2-BETA FreeBSD 4.2-BETA #0: Mon Nov 13 13:52:46 EST 2000 other is=20 4.2-BETA FreeBSD 4.2-BETA #0: Sun Nov 5 18:25:14 EST 2000=20 This is via the same sort of DSL you are using i.e. Bell Nexxia type = stuff through a Redback etc... I havent had time to send a note to the KAME folk, but when using racoon = on DSL, I get these sorts of log entries that I dont normally get 2000-11-13 23:46:29: isakmp_agg.c:927:agg_r2recv(): real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting payload type 1. 2000-11-13 23:46:10: isakmp_inf.c:177:isakmp_info_recv(): real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting payload type 89. 2000-11-13 23:52:37: isakmp_inf.c:177:isakmp_info_recv(): real.addr.totally-diff-subnet.4 ignore the packet, received unexpecting payload type 187. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 11: 1:36 2000 Delivered-To: freebsd-net@freebsd.org Received: from greencreek.kappaisle.com (24.65.73.235.on.wave.home.com [24.65.73.235]) by hub.freebsd.org (Postfix) with ESMTP id D922937B4C5 for ; Tue, 14 Nov 2000 11:01:31 -0800 (PST) Received: from localhost (mikey@localhost) by greencreek.kappaisle.com (8.9.3/8.9.3) with ESMTP id OAA92075; Tue, 14 Nov 2000 14:18:30 -0500 (EST) (envelope-from mikey@kappaisle.com) Date: Tue, 14 Nov 2000 14:18:30 -0500 (EST) From: Mike To: Mike Tancsa Cc: freebsd-net@freebsd.org Subject: Re: VPN over PPPoE (racoon at fault?) 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 Mike, I had the same experience here as well. Racoon doesn't seem to like PPPoE for some reason... Mike On Tue, 14 Nov 2000, Mike Tancsa wrote: > On 9 Nov 2000 17:01:58 -0500, in sentex.lists.freebsd.net you wrote: > > >Hi all, > > > >Has anyone ever successfully configured VPN (using IPSec protocol) over > >PPPoE connection? I have 1 VPN configured over 2 locations with T1 > >connections without any problem (using the KAME IPSec on FreeBSD > >4.1.1). However, when I tried the same configuration with the 3rd > >location running DSL, it seems the IPSec packets can't reach out via tun0 > >device. > > I can do it with manual keying, but not with racoon. Both transport and > tunnel mode work for me, but neither works with racoon. NAT is a bit > tricky, but then again with tunnel mode, it doesnt really matter. > > > One end is > 4.2-BETA FreeBSD 4.2-BETA #0: Mon Nov 13 13:52:46 EST 2000 > other is > 4.2-BETA FreeBSD 4.2-BETA #0: Sun Nov 5 18:25:14 EST 2000 > > This is via the same sort of DSL you are using i.e. Bell Nexxia type stuff > through a Redback etc... > > I havent had time to send a note to the KAME folk, but when using racoon on > DSL, I get these sorts of log entries that I dont normally get > > 2000-11-13 23:46:29: isakmp_agg.c:927:agg_r2recv(): > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > payload type 1. > 2000-11-13 23:46:10: isakmp_inf.c:177:isakmp_info_recv(): > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > payload type 89. > 2000-11-13 23:52:37: isakmp_inf.c:177:isakmp_info_recv(): > real.addr.totally-diff-subnet.4 ignore the packet, received unexpecting > payload type 187. > > ---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 Tue Nov 14 11: 7:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 166A237B479 for ; Tue, 14 Nov 2000 11:07:40 -0800 (PST) Received: from simoeon.sentex.net (simeon.sentex.ca [209.112.4.47]) by smtp1.sentex.ca (8.11.0/8.11.0) with ESMTP id eAEJ72W42062; Tue, 14 Nov 2000 14:07:03 -0500 (EST) Message-Id: <5.0.1.4.0.20001114140020.00a64120@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 14 Nov 2000 14:00:48 -0500 To: Mike From: Mike Tancsa Subject: Re: VPN over PPPoE (racoon at fault?) Cc: freebsd-net@freebsd.org In-Reply-To: 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 Actually, I just noticed an updated version of racoon in the ports tree. I am going to give that a go and see if it makes a difference. ---Mike At 02:18 PM 11/14/00 -0500, Mike wrote: >Mike, > >I had the same experience here as well. Racoon doesn't seem to like PPPoE >for some reason... > >Mike > >On Tue, 14 Nov 2000, Mike Tancsa wrote: > > > On 9 Nov 2000 17:01:58 -0500, in sentex.lists.freebsd.net you wrote: > > > > >Hi all, > > > > > >Has anyone ever successfully configured VPN (using IPSec protocol) over > > >PPPoE connection? I have 1 VPN configured over 2 locations with T1 > > >connections without any problem (using the KAME IPSec on FreeBSD > > >4.1.1). However, when I tried the same configuration with the 3rd > > >location running DSL, it seems the IPSec packets can't reach out via tun0 > > >device. > > > > I can do it with manual keying, but not with racoon. Both transport and > > tunnel mode work for me, but neither works with racoon. NAT is a bit > > tricky, but then again with tunnel mode, it doesnt really matter. > > > > > > One end is > > 4.2-BETA FreeBSD 4.2-BETA #0: Mon Nov 13 13:52:46 EST 2000 > > other is > > 4.2-BETA FreeBSD 4.2-BETA #0: Sun Nov 5 18:25:14 EST 2000 > > > > This is via the same sort of DSL you are using i.e. Bell Nexxia type stuff > > through a Redback etc... > > > > I havent had time to send a note to the KAME folk, but when using racoon on > > DSL, I get these sorts of log entries that I dont normally get > > > > 2000-11-13 23:46:29: isakmp_agg.c:927:agg_r2recv(): > > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > > payload type 1. > > 2000-11-13 23:46:10: isakmp_inf.c:177:isakmp_info_recv(): > > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > > payload type 89. > > 2000-11-13 23:52:37: isakmp_inf.c:177:isakmp_info_recv(): > > real.addr.totally-diff-subnet.4 ignore the packet, received unexpecting > > payload type 187. > > > > ---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 Tue Nov 14 13: 1:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id E77D337B4FE for ; Tue, 14 Nov 2000 13:01:39 -0800 (PST) Received: (qmail 21222 invoked by uid 0); 14 Nov 2000 21:01:38 -0000 Received: from p3e9bc345.dip.t-dialin.net (HELO forge.local) (62.155.195.69) by mail.gmx.net (mail04) with SMTP; 14 Nov 2000 21:01:38 -0000 Received: from thomas by forge.local with local (Exim 3.12 #1 (Debian)) id 13vnCf-0000I7-00; Tue, 14 Nov 2000 22:01:17 +0100 Date: Tue, 14 Nov 2000 22:01:17 +0100 To: freebsd-net@freebsd.org Cc: bmilekic@dsuper.net Subject: bug in bridging/dummynet code - PR kern/19551 Message-ID: <20001114220117.A732@forge.local> Mail-Followup-To: tmoestl@gmx.net, freebsd-net@freebsd.org, bmilekic@dsuper.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: Thomas Moestl Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I think I have spotted a bug in the bridge/dummynet code that might be responsible for some panics people have reported recently - see e.g. PR kern/19551. PR kern/21534 seems related and are probably about the same thing, PR kern/19488 goes in the same direction. Bosko, I'm CCing this to you because the PR is currently assigned to you. Here is the relevant section of code from netinet/ip_dummynet.c:402: #ifdef BRIDGE case DN_TO_BDG_FWD : { struct mbuf *m = (struct mbuf *)pkt ; struct ether_header hdr; if (m->m_len < ETHER_HDR_LEN && (m = m_pullup(m, ETHER_HDR_LEN)) == NULL) { m_freem(m); break; } bcopy(mtod(m, struct ether_header *), &hdr, ETHER_HDR_LEN); m_adj(m, ETHER_HDR_LEN); bdg_forward(&m, &hdr, pkt->ifp); if (m) m_freem(m); } break ; #endif Now, pkt is a malloc()ed structure, not an mbuf! Calling m_pullup() on it seems defective, at least because m_free may be called in m_pullup(), which leaks kernel memory if the freed structure is not an mbuf. And of course, the ethernet header should be in the mbuf in pkt->dn_m. Should it be: #ifdef BRIDGE case DN_TO_BDG_FWD : { struct mbuf *m = (struct mbuf *)pkt ; struct ether_header hdr; if (pkt->dn_m->m_len < ETHER_HDR_LEN && (pkt->dn_m = m_pullup(pkt->dn_m, ETHER_HDR_LEN)) == NULL) { m_freem(pkt->dn_m); break; } bcopy(mtod(pkt->dn_m, struct ether_header *), &hdr, ETHER_HDR_LEN); m_adj(pkt->dn_m, ETHER_HDR_LEN); bdg_forward(&m, &hdr, pkt->ifp); if (m) /* bdg_format will put pkt->dn_m into mbuf into m in our case */ m_freem(m); } break ; #endif Hmm, maybe I'm wrong here, but that seems odd to me. Please enlighten me! Unfortunetly, I have no machine I could use to test it at the moment. I just wanted to ask before I add this to the PR. Sorry if I was wrong, - Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 13:11:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 6B63037B479; Tue, 14 Nov 2000 13:11:10 -0800 (PST) Received: from simoeon.sentex.net (simeon.sentex.ca [209.112.4.47]) by smtp1.sentex.ca (8.11.0/8.11.0) with ESMTP id eAELAUM58899; Tue, 14 Nov 2000 16:10:30 -0500 (EST) Message-Id: <5.0.1.4.0.20001114153658.00a58df0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 14 Nov 2000 16:04:04 -0500 To: Mike From: Mike Tancsa Subject: Re: VPN over PPPoE (racoon at fault? - no pilot error) Cc: freebsd-net@freebsd.org, security@freebsd.org In-Reply-To: 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 OK, thanks very much to Mike Cambria, (mcambria@avaya.com) for suggesting adjusting the lifetime settings. I am cc'ing to security@freebsd.org in case others run into this problem of using racoon over slower than ethernet links. Setup is a FreeBSD box running PPPoE over DSL across a few hops to another FreeBSD machine on the ethernet. The trick is to bump up the lifetime value in racoon.conf and to make sure you have a recent version of racoon. I used the one from November 11th. Here is a quick sample config for two machines PPPoE machine's _public_ address on tun0 : 169.1.134.1 PPPoE machine's _private_ address aliased on lo0 : 10.1.2.1 Office Server's _public_ address on fxp0 172.168.93.4 Office Server's _private_ address aliased on lo0 : 10.1.1.1 *Note, if your machine has 2 interfaces, you can of course use the RFC1918 space on it instead. This example assumes you just have the one NIC to play with. #!/bin/sh #PPPoE config ifconfig lo0 10.1.2.1 netmask 255.255.255.0 alias gifconfig gif0 169.1.134.1 172.168.93.4 ifconfig gif0 inet 10.1.2.1 10.1.1.1 netmask 255.255.255.0 setkey -FP setkey -F setkey -c < > On 9 Nov 2000 17:01:58 -0500, in sentex.lists.freebsd.net you wrote: > > > > >Hi all, > > > > > >Has anyone ever successfully configured VPN (using IPSec protocol) over > > >PPPoE connection? I have 1 VPN configured over 2 locations with T1 > > >connections without any problem (using the KAME IPSec on FreeBSD > > >4.1.1). However, when I tried the same configuration with the 3rd > > >location running DSL, it seems the IPSec packets can't reach out via tun0 > > >device. > > > > I can do it with manual keying, but not with racoon. Both transport and > > tunnel mode work for me, but neither works with racoon. NAT is a bit > > tricky, but then again with tunnel mode, it doesnt really matter. > > > > > > One end is > > 4.2-BETA FreeBSD 4.2-BETA #0: Mon Nov 13 13:52:46 EST 2000 > > other is > > 4.2-BETA FreeBSD 4.2-BETA #0: Sun Nov 5 18:25:14 EST 2000 > > > > This is via the same sort of DSL you are using i.e. Bell Nexxia type stuff > > through a Redback etc... > > > > I havent had time to send a note to the KAME folk, but when using racoon on > > DSL, I get these sorts of log entries that I dont normally get > > > > 2000-11-13 23:46:29: isakmp_agg.c:927:agg_r2recv(): > > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > > payload type 1. > > 2000-11-13 23:46:10: isakmp_inf.c:177:isakmp_info_recv(): > > real.addr.totally-diff-subnet.1 ignore the packet, received unexpecting > > payload type 89. > > 2000-11-13 23:52:37: isakmp_inf.c:177:isakmp_info_recv(): > > real.addr.totally-diff-subnet.4 ignore the packet, received unexpecting > > payload type 187. > > > > ---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 Tue Nov 14 13:27:31 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 1FF4037B479; Tue, 14 Nov 2000 13:27:20 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA78999; Tue, 14 Nov 2000 14:27:18 -0700 (MST) (envelope-from ken) Date: Tue, 14 Nov 2000 14:27:18 -0700 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: new zero copy sockets and NFS snapshot Message-ID: <20001114142718.A78985@panzer.kdm.org> 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 [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 14th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The "localhost panic" problem has hopefully been fixed. The fix was to avoid page-flipping pages with a wire count greater than 0. I believe this is the right fix, but I would welcome feedback from someone more familiar with the VM system. - The new external mbuf code has been integrated. As of this release, there are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin . - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. 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 Tue Nov 14 14:59:29 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 47EB637B4CF; Tue, 14 Nov 2000 14:59:23 -0800 (PST) Received: from gaborone-34.budapest.interware.hu ([195.70.52.162] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13vp2q-0002j6-00; Tue, 14 Nov 2000 23:59:16 +0100 Message-ID: <3A112FD3.EB28E58E@elischer.org> Date: Tue, 14 Nov 2000 04:28:03 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: petro Cc: Tobias Fredriksson , question@FreeBSD.ORG, freeBSD-net@FreeBSD.ORG Subject: Re: IPFW... References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Do you have the option that allows the 'fwd' command? petro wrote: > I have some ipfw that works fine, but when I try to add this I receive > such error..... > > On Sun, 12 Nov 2000, Tobias Fredriksson wrote: > > > > > > > On Sun, 12 Nov 2000, petro wrote: > > > > > Hello! > > > I try to add such ipfw but receive error.. > > > # ipfw a 250 fwd 127.0.0.1,3128 tcp from any to any 80 in recv ed1 > > > 00250 fwd 127.0.0.1,22 tcp from any to any 80 > > > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > > > > > Squid is running on 3128 port.. > > > Thank you... > > > > you get the setsockopt(IP_FW_ADD): Invalid argument statement when you > > have not compiled the kernel with options ipfirewall > > > > > > > > > > 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 -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Nov 14 14:59:36 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 8FE1F37B4FE for ; Tue, 14 Nov 2000 14:59:26 -0800 (PST) Received: from gaborone-34.budapest.interware.hu ([195.70.52.162] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13vp2y-0002jq-00; Tue, 14 Nov 2000 23:59:24 +0100 Message-ID: <3A11329A.D54E17E3@elischer.org> Date: Tue, 14 Nov 2000 04:39:54 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: David Malone , iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bosko Milekic wrote: > > On Sun, 12 Nov 2000, David Malone wrote: > > > The other option I thought of is to use a char *. You could point > > to a static string describing the type of external storage. This > > way is still fast comparing types, just compare the pointers. If > > you want to know what the type is in human readable format (for > > debugging) you just look at the string it points at. Also the > > kernel allocates different addresses for different strings, so > > it automatically solves the problem of allocating unique numbers > > to each type. > > > > David. > using char * is unsafe if the aim is to tag mbufs that were allocated by some module, if the midule is unloaded.. (the mbufs may hang around in some queu way afte the module has gone.. and an attempt to follow the char 8 pointer......) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Nov 14 15:15:16 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 E3D6337B4C5 for ; Tue, 14 Nov 2000 15:15:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAENF6N24939; Tue, 14 Nov 2000 15:15:06 -0800 (PST) Date: Tue, 14 Nov 2000 15:15:06 -0800 From: Alfred Perlstein To: Julian Elischer Cc: Bosko Milekic , David Malone , iedowse@maths.tcd.ie, freebsd-net@FreeBSD.ORG Subject: Re: M_RDONLY: review & comment Message-ID: <20001114151506.F11449@fw.wintelcom.net> References: <3A11329A.D54E17E3@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <3A11329A.D54E17E3@elischer.org>; from julian@elischer.org on Tue, Nov 14, 2000 at 04:39:54AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Julian Elischer [001114 14:59] wrote: > Bosko Milekic wrote: > > > > On Sun, 12 Nov 2000, David Malone wrote: > > > > > > The other option I thought of is to use a char *. You could point > > > to a static string describing the type of external storage. This > > > way is still fast comparing types, just compare the pointers. If > > > you want to know what the type is in human readable format (for > > > debugging) you just look at the string it points at. Also the > > > kernel allocates different addresses for different strings, so > > > it automatically solves the problem of allocating unique numbers > > > to each type. > > > > > > David. > > > > using char * is unsafe if the aim is to tag mbufs that were allocated > by some module, if the midule is unloaded.. > (the mbufs may hang around in some queu way afte the module has gone.. > and an attempt to follow the char 8 pointer......) That doesn't have to be true, see src/sys/kern/uipc_accf.c, as long as the char * is malloc'd and not forceably free'd on module unload we're safe although we may leak memory. -- -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 Tue Nov 14 15:19:24 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 C8E8B37B4CF for ; Tue, 14 Nov 2000 15:19:19 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G4100FGYFG50K@field.videotron.net> for freebsd-net@FreeBSD.ORG; Tue, 14 Nov 2000 18:19:17 -0500 (EST) Date: Tue, 14 Nov 2000 18:19:22 -0500 (EST) From: Bosko Milekic Subject: Re: bug in bridging/dummynet code - PR kern/19551 In-reply-to: <20001114220117.A732@forge.local> X-Sender: bmilekic@jehovah.technokratis.com To: Thomas Moestl Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That _DEFFINATELY_ looks EVIL. I'd like to see some debugging info, at the least a stack trace, so that we can see whether everybody "reporting" this problem is referring to a side effect of this. Hopefully I'll have this appended to the PR or in my INBOX by this weekend so that we can look into fixing this. On Tue, 14 Nov 2000, Thomas Moestl wrote: > Hi, > > I think I have spotted a bug in the bridge/dummynet code that might be > responsible for some panics people have reported recently - see e.g. > PR kern/19551. > PR kern/21534 seems related and are probably about the same thing, > PR kern/19488 goes in the same direction. > > Bosko, I'm CCing this to you because the PR is currently assigned to > you. > > Here is the relevant section of code from netinet/ip_dummynet.c:402: > > #ifdef BRIDGE > case DN_TO_BDG_FWD : { > struct mbuf *m = (struct mbuf *)pkt ; > struct ether_header hdr; > > if (m->m_len < ETHER_HDR_LEN > && (m = m_pullup(m, ETHER_HDR_LEN)) == NULL) { > m_freem(m); > break; > } > bcopy(mtod(m, struct ether_header *), &hdr, ETHER_HDR_LEN); > m_adj(m, ETHER_HDR_LEN); > bdg_forward(&m, &hdr, pkt->ifp); > if (m) > m_freem(m); > } > break ; > #endif > > Now, pkt is a malloc()ed structure, not an mbuf! Calling m_pullup() on it > seems defective, at least because m_free may be called in m_pullup(), > which leaks kernel memory if the freed structure is not an mbuf. > And of course, the ethernet header should be in the mbuf in pkt->dn_m. > Should it be: > > #ifdef BRIDGE > case DN_TO_BDG_FWD : { > struct mbuf *m = (struct mbuf *)pkt ; > struct ether_header hdr; > > if (pkt->dn_m->m_len < ETHER_HDR_LEN > && (pkt->dn_m = m_pullup(pkt->dn_m, ETHER_HDR_LEN)) == NULL) { > m_freem(pkt->dn_m); > break; > } > bcopy(mtod(pkt->dn_m, struct ether_header *), &hdr, ETHER_HDR_LEN); > m_adj(pkt->dn_m, ETHER_HDR_LEN); > bdg_forward(&m, &hdr, pkt->ifp); > if (m) > /* bdg_format will put pkt->dn_m into mbuf into m in our case */ > m_freem(m); > } > break ; > #endif > > Hmm, maybe I'm wrong here, but that seems odd to me. Please enlighten > me! Unfortunetly, I have no machine I could use to test it at the moment. > > I just wanted to ask before I add this to the PR. > > Sorry if I was wrong, > - Thomas Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 15:46:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 3E55937B4CF for ; Tue, 14 Nov 2000 15:46:47 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id SAA15148 for ; Tue, 14 Nov 2000 18:47:42 -0500 (EST) Date: Tue, 14 Nov 2000 18:47:41 -0500 (EST) From: Alex Pilosov To: freebsd-net@freebsd.org Subject: netgraph/atm 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 beginning to look into implementing ATM rfc1483 bridging with freebsd. Here's my plan: 1. Add netgraph hooks to ATM HARP stack, in a similar way the LMI/DLCI hooks work for ethernet: ATM physical interfaces should appear as netgraph nodes. I.E. you should be able to do something like this: ngctl mkpeer hfa0:rawdata rfc1483 pvc0/33 encaps_llc_snap to decapsulate snap+llc bridged packets from that PVC. rfc1483 node would output 802.3 ethernet frames, extracted from that VC 2. Create a 'virtual ethernet' node type, which should be similar to current 'iface' type, only it should present actual ethernet-style interface, i.e. with MAC addresses, ARP, etc. Vitaly Belekhov's work should be very useful for me, since he implemented 'virtual ethernet' ng_eiface driver. Hopefully, I won't need to change anything, and can connect hfa0:rawdata:pvc0/33 directly to ng_eiface ;) 3. Then I can use bridging provided by freebsd on these virtual ethernets. Questions: 1) Does my scheme make sense? 2) I'll have probably 50-100 virtual ethernet devices. Should I expect major problems with this? Also, I just wanted to say thanks to netgraph team...Its an awfully simple idea, treating network interfaces as just streams of packets, and using unixish semantics to connect them via filters/edges... Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 16:40: 7 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 B7A1D37B4C5 for ; Tue, 14 Nov 2000 16:40:02 -0800 (PST) Received: from victoria-026.budapest.interware.hu ([195.70.63.26] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13vqcH-0001X5-00; Wed, 15 Nov 2000 01:39:57 +0100 Message-ID: <3A11DB40.E50024F@elischer.org> Date: Tue, 14 Nov 2000 16:39:28 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Pilosov Cc: freebsd-net@freebsd.org Subject: Re: netgraph/atm References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > I'm beginning to look into implementing ATM rfc1483 bridging with freebsd. > > Here's my plan: > > 1. Add netgraph hooks to ATM HARP stack, in a similar way the LMI/DLCI > hooks work for ethernet: ATM physical interfaces should appear as netgraph > nodes. > > I.E. you should be able to do something like this: > ngctl mkpeer hfa0:rawdata rfc1483 pvc0/33 encaps_llc_snap > to decapsulate snap+llc bridged packets from that PVC. > > rfc1483 node would output 802.3 ethernet frames, extracted from that VC yep.. If that's what rfc1483 (the rfc) treats as input and output. > > 2. Create a 'virtual ethernet' node type, which should be similar to > current 'iface' type, only it should present actual ethernet-style > interface, i.e. with MAC addresses, ARP, etc. > > Vitaly Belekhov's work should be very useful for me, since he implemented > 'virtual ethernet' ng_eiface driver. Hopefully, I won't need to change > anything, and can connect hfa0:rawdata:pvc0/33 directly to ng_eiface ;) hopefully. > > 3. Then I can use bridging provided by freebsd on these virtual ethernets. > > Questions: > 1) Does my scheme make sense? yes, though I haven't checked everything... > > 2) I'll have probably 50-100 virtual ethernet devices. Should I expect > major problems with this? no. (but ifconfig and netstat will get long :-) > > Also, I just wanted to say thanks to netgraph team...Its an awfully simple > idea, treating network interfaces as just streams of packets, and using > unixish semantics to connect them via filters/edges... That's what we designed it for.... > > Thanks. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Nov 14 17:10:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by hub.freebsd.org (Postfix) with ESMTP id EEC8637B4CF for ; Tue, 14 Nov 2000 17:10:19 -0800 (PST) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA02759 for ; Tue, 14 Nov 2000 20:10:19 -0500 (EST) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id UAA02740; Tue, 14 Nov 2000 20:10:17 -0500 (EST) Received: from lucent.com (positron.micro.lucent.com [192.19.56.129]) by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id UAA27663; Tue, 14 Nov 2000 20:10:16 -0500 (EST) Message-ID: <3A11E227.4686F196@lucent.com> Date: Tue, 14 Nov 2000 20:08:55 -0500 From: "Gary T. Corcoran" Reply-To: gcorcoran@lucent.com Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alex Pilosov , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm References: <3A11DB40.E50024F@elischer.org> 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 wrote: > > Alex Pilosov wrote: > > > > I'm beginning to look into implementing ATM rfc1483 bridging with freebsd. Cool. > > > > Here's my plan: ... > > rfc1483 node would output 802.3 ethernet frames, extracted from that VC > > yep.. If that's what rfc1483 (the rfc) treats as input and output. Actually RFC1483 has four "flavors", two of which support "bridging" of complete 802.3 ethernet frames including the MAC addresses - either encapsulated with an LLC/SNAP header or "raw" with just a two byte (0x00, 0x00) pad for alignment purposes. Another flavor removes the MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the EtherType and the rest of the frame. The other flavor just routes a PDU (raw packet with no MAC addressses or EtherType) across a VC (ATM virtual channel) with no encapsulation at all. Alex - if you intend to make your code public, and if you feel ambititious, it would be nice if you could support all four flavors of RFC1483. Then we could replace our Win2000 server with a FreeBSD server for testing our DSL implementations of RFC1483... ;-) Don't do this just for me, as our implementations are pretty much done, so we don't do much testing anymore. But if you want to be complete... Just a suggestion... Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 19:15:31 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 5683E37B4CF; Tue, 14 Nov 2000 19:15:24 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAF3FIG60231; Tue, 14 Nov 2000 22:15:19 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011150315.eAF3FIG60231@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Charles Mott Cc: Archie Cobbs , Ruslan Ermilov , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: In-reply-to: Your message of "Mon, 13 Nov 2000 00:29:32 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 2000 22:15:18 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Arithmetically, a value of 0xffff is identical to 0x0000 since they both represent the value of zero when using a one's complement binary representation of values. It turns that this property is used in some network protocols (e.g., UDP) to distinguish between a checksum value that's computed as zero (represented as 0xffff in the packet) from a packet which has no computed checksum at all. This was done in the dark ages when it was deemed "too expensive" to compute a checksum. louie > Ok, ok -- Ruslan is mathematically correct, but > the problem is really neglible, because of how checksums > are commonly verified. Even if DifferentialChecksum() > incorrectly produces a 0xffff instead of 0x0000, this error > does not affect the verification sum computed by a recipient > machine. > > To quote from RF 1624: > > If an end system verifies the checksum by including the checksum > field itself in the one's complement sum and then comparing the > result against -0, as recommended by RFC 1071, it does not matter if > an intermediate system generated a -0 instead of +0 due to the RFC > 1141 property described here. > > It would be interesting to do some network surveillance > to see how often 0xffff shows up in checksum fields. > > -- Charles Mott > > > On Sun, 12 Nov 2000, Charles Mott wrote: > > On Sun, 12 Nov 2000, Archie Cobbs wrote: > > > Ruslan Ermilov writes: > > > > The DifferentialChecksum() function in libalias(3) is used > > > > to efficiently recompute the checksum for altered packets. > > > > Unfortunately, the implementation suffers from the problem > > > > described in RFC 1624. I have implemented the replacement > > > > for it, using the final formula [4] from the RFC. > > > > > > > > The attached C program demonstrates the problem as well as > > > > the new implementation. > > > > > > > > Comments? > > > > > > Wow.. seems like a pretty important thing to fix. > > > We should try to get this into 4.2 if possible. > > > > I haven't studied the arithmetic yet, but the problem > > cannot be too serious, or a lot of things would break. > > My guess is that this has to be an "edge effect". > > Since Ruslan's example program showed a delta of 1 > > for so many cases, I'm not sure what it means yet. > > > > I would agree that if there is a problem, it should > > be fixed. > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 22:16: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAFF737B4C5 for ; Tue, 14 Nov 2000 22:15:58 -0800 (PST) Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5314F6E295B for ; Tue, 14 Nov 2000 22:15:54 -0800 (PST) Received: from cybercable.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id HAA51458 for ; Wed, 15 Nov 2000 07:14:16 +0100 (CET) (envelope-from herbelot@cybercable.fr) Message-ID: <3A1229B8.2B30B23F@cybercable.fr> Date: Wed, 15 Nov 2000 07:14:16 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > I'm beginning to look into implementing ATM rfc1483 bridging with freebsd. > > Here's my plan: > > 1. Add netgraph hooks to ATM HARP stack, in a similar way the LMI/DLCI > hooks work for ethernet: ATM physical interfaces should appear as netgraph > nodes. great ! > > I.E. you should be able to do something like this: > ngctl mkpeer hfa0:rawdata rfc1483 pvc0/33 encaps_llc_snap > to decapsulate snap+llc bridged packets from that PVC. > > rfc1483 node would output 802.3 ethernet frames, extracted from that VC > > 2. Create a 'virtual ethernet' node type, which should be similar to > current 'iface' type, only it should present actual ethernet-style > interface, i.e. with MAC addresses, ARP, etc. > > Vitaly Belekhov's work should be very useful for me, since he implemented > 'virtual ethernet' ng_eiface driver. Hopefully, I won't need to change > anything, and can connect hfa0:rawdata:pvc0/33 directly to ng_eiface ;) > > 3. Then I can use bridging provided by freebsd on these virtual ethernets. > > Questions: > 1) Does my scheme make sense? > > 2) I'll have probably 50-100 virtual ethernet devices. Should I expect > major problems with this? the PCA200e board seems to be limited to 16 PVC : I do not know where this limitation comes from > > Also, I just wanted to say thanks to netgraph team...Its an awfully simple > idea, treating network interfaces as just streams of packets, and using > unixish semantics to connect them via filters/edges... > > Thanks. > -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 14 22:32: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 676BE37B479 for ; Tue, 14 Nov 2000 22:32:07 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id BAA28536; Wed, 15 Nov 2000 01:32:46 -0500 (EST) Date: Wed, 15 Nov 2000 01:32:43 -0500 (EST) From: Alex Pilosov To: "Gary T. Corcoran" Cc: freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm In-Reply-To: <3A11E227.4686F196@lucent.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, 14 Nov 2000, Gary T. Corcoran wrote: > > yep.. If that's what rfc1483 (the rfc) treats as input and output. > > Actually RFC1483 has four "flavors", two of which support "bridging" > of complete 802.3 ethernet frames including the MAC addresses - either > encapsulated with an LLC/SNAP header or "raw" with just a two byte > (0x00, 0x00) pad for alignment purposes. Another flavor removes the > MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the > EtherType and the rest of the frame. The other flavor just routes > a PDU (raw packet with no MAC addressses or EtherType) across a VC > (ATM virtual channel) with no encapsulation at all. Yeah. I'm just implementing it to scratch my itch, and I'll see about support of everything else later. I'm definitely going to try to support llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is already handled just fine by existing ATM stacks. > Alex - if you intend to make your code public, and if you feel > ambititious, it would be nice if you could support all four flavors > of RFC1483. Then we could replace our Win2000 server with a FreeBSD > server for testing our DSL implementations of RFC1483... ;-) Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose 'bridged mac/llc' as preferred method of delivery of DSL, since it has the biggest overhead...But I guess for them transparency was the biggest issue. Oh well. > Don't do this just for me, as our implementations are pretty much > done, so we don't do much testing anymore. But if you want to > be complete... Just a suggestion... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 0: 6:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 04A4E37B4C5 for ; Wed, 15 Nov 2000 00:06:42 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAF847L38221; Wed, 15 Nov 2000 10:04:07 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 10:04:07 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115100407.D36400@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <200011150315.eAF3FIG60231@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011150315.eAF3FIG60231@whizzo.transsys.com>; from louie@TransSys.COM on Tue, Nov 14, 2000 at 10:15:18PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Nov 14, 2000 at 10:15:18PM -0500, Louis A. Mamakos wrote: > > Arithmetically, a value of 0xffff is identical to 0x0000 since they > both represent the value of zero when using a one's complement binary > representation of values. > Except you can't actually receive the value of 0xffff in a checksum field. One's complement sum is guaranteed to be non-zero except if all items are zeroes. Since IP Protocol field is a non-zero value that participates in all checksums (IP, TCP, UDP, ICMP), the checksum value (which is a one's complement of a one's complement sum) is guaranteed to be non-0xffff. > It turns that this property is used in some network protocols (e.g., UDP) > to distinguish between a checksum value that's computed as zero (represented > as 0xffff in the packet) from a packet which has no computed checksum at all. > This was done in the dark ages when it was deemed "too expensive" to > compute a checksum. > From the above it follows that UDP should better be using 0xffff rather than 0x0 to indicate that a packet has no computed checksum. It is quite possible that the computed checksum will have a zero value, in which case the receiving UDP module will consider such a packet as with no computed checksum, which is wrong. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 0:35:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 3A70237B4C5 for ; Wed, 15 Nov 2000 00:35:43 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Nov 2000 08:35:41 +0000 (GMT) To: Julian Elischer Cc: Bosko Milekic , David Malone , iedowse@maths.tcd.ie, freebsd-net@freebsd.org, dwmalone@maths.tcd.ie Subject: Re: M_RDONLY: review & comment In-reply-to: Your message of "Tue, 14 Nov 2000 04:39:54 PST." <3A11329A.D54E17E3@elischer.org> X-Request-Do: Date: Wed, 15 Nov 2000 08:35:40 +0000 From: David Malone Message-ID: <200011150835.aa94058@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > using char * is unsafe if the aim is to tag mbufs that were allocated > by some module, if the midule is unloaded.. > (the mbufs may hang around in some queu way afte the module has gone.. > and an attempt to follow the char 8 pointer......) If a module which is responsible for mbufs with external storage, then the free function for that storage will be in the module. If, after the module is unloaded, mbufs are still allocated which are using this external storage things will blow up when they are freed. So if the free function is still there, so will what the char * points at. (Unless I'm missing something...) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 1: 7:55 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 BA1AC37B4C5 for ; Wed, 15 Nov 2000 01:07:52 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAF97kr10097; Wed, 15 Nov 2000 01:07:46 -0800 (PST) Date: Wed, 15 Nov 2000 01:07:46 -0800 From: Alfred Perlstein To: David Malone Cc: Julian Elischer , Bosko Milekic , iedowse@maths.tcd.ie, freebsd-net@FreeBSD.ORG Subject: Re: M_RDONLY: review & comment Message-ID: <20001115010746.E29448@fw.wintelcom.net> References: <3A11329A.D54E17E3@elischer.org> <200011150835.aa94058@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011150835.aa94058@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Wed, Nov 15, 2000 at 08:35:40AM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Malone [001115 00:35] wrote: > > using char * is unsafe if the aim is to tag mbufs that were allocated > > by some module, if the midule is unloaded.. > > (the mbufs may hang around in some queu way afte the module has gone.. > > and an attempt to follow the char 8 pointer......) > > If a module which is responsible for mbufs with external storage, > then the free function for that storage will be in the module. If, > after the module is unloaded, mbufs are still allocated which are > using this external storage things will blow up when they are freed. > > So if the free function is still there, so will what the char * > points at. (Unless I'm missing something...) Modules using external clusters that point to some internal state should disallow unload until all such references go away. The char * may need to be allocated via MALLOC and leaked when the module is unloaded if mbufs without external storage are to be tagged with a char *. People get upset when I say "just leak the memory" but in reality the memory used will be very small. Another option is garbage collection, the char * could be contained in a special struct or instead of a char * it could be a pointer to a struct. In order to avoid an aditional refcount just for this pointer one could scan stick a loaded/unloaded bit in the struct. When a module is unloaded it marks the struct as unneeded and moves it to a queue/table it then starts a timer (if not started already) to scan and garbage collect the structs. Since afaik the mbufs are all allocated from a single kernel map, and they are all aligned on a specific boundry, one can scan the mbuf map for pointers to the "dead" structs on exiration of the timer, any structs that aren't found still pointed to can be free'd. *phew* :) -- -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 Wed Nov 15 1:11:34 2000 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 2B87A37B479 for ; Wed, 15 Nov 2000 01:11:32 -0800 (PST) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Nov 2000 09:11:31 +0000 (GMT) To: Alfred Perlstein Cc: David Malone , Julian Elischer , Bosko Milekic , iedowse@maths.tcd.ie, freebsd-net@FreeBSD.ORG Subject: Re: M_RDONLY: review & comment In-reply-to: Your message of "Wed, 15 Nov 2000 01:07:46 PST." <20001115010746.E29448@fw.wintelcom.net> X-Request-Do: Date: Wed, 15 Nov 2000 09:11:31 +0000 From: David Malone Message-ID: <200011150911.aa97224@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Modules using external clusters that point to some internal state > should disallow unload until all such references go away. Exactly - I haven't checked if they do yet. > The char * may need to be allocated via MALLOC and leaked when the > module is unloaded if mbufs without external storage are to be > tagged with a char *. If the module can't be unloaded until the mbufs have gone away then it is safe to free the string. It may be a moot point anyway, 'cos I think Bosko prefers using an int for the type and he's the boss ;-) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 3:12: 9 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 93F2337B479; Wed, 15 Nov 2000 03:12:06 -0800 (PST) Received: from gaborone-59.budapest.interware.hu ([195.70.52.187] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w0Tw-00055E-00; Wed, 15 Nov 2000 12:12:01 +0100 Message-ID: <3A126F63.8EB0D49@elischer.org> Date: Wed, 15 Nov 2000 03:11:31 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum References: <20001113103852.E34671@sunbay.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov wrote: > Here's the version I wrote some years ago.. #define FIXSUM16(c, op, np) \ do { \ (c) -= (u_int16_t) ~*((u_int16_t *) (op)); \ if ((c) < 0) { \ (c) += 0xffff; \ } \ (c) -= (u_int16_t) *((u_int16_t *) (np)); \ if ((c) < 0) { \ (c) += 0xffff; \ } \ } while (0) it replaces the 16 bit word at *op with the new value at *np and updates the checksum c -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 4: 6:11 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 A8A8237B479 for ; Wed, 15 Nov 2000 04:06:07 -0800 (PST) Received: from nairobi-40.budapest.interware.hu ([195.70.50.232] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w1KB-0000mA-00; Wed, 15 Nov 2000 13:06:00 +0100 Message-ID: <3A126A2D.7F43B120@elischer.org> Date: Wed, 15 Nov 2000 02:49:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Pilosov Cc: "Gary T. Corcoran" , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > On Tue, 14 Nov 2000, Gary T. Corcoran wrote: > > > > yep.. If that's what rfc1483 (the rfc) treats as input and output. > > > > Actually RFC1483 has four "flavors", two of which support "bridging" > > of complete 802.3 ethernet frames including the MAC addresses - either > > encapsulated with an LLC/SNAP header or "raw" with just a two byte > > (0x00, 0x00) pad for alignment purposes. Another flavor removes the > > MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the > > EtherType and the rest of the frame. The other flavor just routes > > a PDU (raw packet with no MAC addressses or EtherType) across a VC > > (ATM virtual channel) with no encapsulation at all. > Yeah. I'm just implementing it to scratch my itch, and I'll see about > support of everything else later. I'm definitely going to try to support > llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is > already handled just fine by existing ATM stacks. > > > Alex - if you intend to make your code public, and if you feel > > ambititious, it would be nice if you could support all four flavors > > of RFC1483. Then we could replace our Win2000 server with a FreeBSD > > server for testing our DSL implementations of RFC1483... ;-) > Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose > 'bridged mac/llc' as preferred method of delivery of DSL, since it has the > biggest overhead...But I guess for them transparency was the biggest > issue. Oh well. My question is whether there are any boards that can give us the physical interface to a DSL line so that we can run this ATM code over a DSL line? It's one thing having the software but the bits need to get out of the system somehow. One thing I just thought about, is that if we are simulating an ethernet interface and bridging the packets using mac/llc then wouldn;t we require that we have some unique MAC address for that virtual interface so that things don't break? (can we just always use broadcast?) are the packets multiplexed using destination MAC address? Also which of the two ATM stacks in FreeBSD is the most suitable? I'm guessing HARP, but NATM, because it is such a very basic framework, might be suitable for netgraphification.. (I have no idea if I'm talking rubish but a simple netgraph node that does aal1/aal5 would fit into the netgraph world very well.) > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 4: 8: 3 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 E729D37B4C5; Wed, 15 Nov 2000 04:07:58 -0800 (PST) Received: from nairobi-40.budapest.interware.hu ([195.70.50.232] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w1Lz-0000tu-00; Wed, 15 Nov 2000 13:07:52 +0100 Message-ID: <3A127C7A.8B8DAA13@elischer.org> Date: Wed, 15 Nov 2000 04:07:22 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum References: <20001113103852.E34671@sunbay.com> <3A126F63.8EB0D49@elischer.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: uggggh it reformatted it.. obviously the slashes are at the END of the previouse lines! > > Ruslan Ermilov wrote: > > > Here's the version I wrote some years ago.. > #define FIXSUM16(c, op, np) > \ > do { > \ > (c) -= (u_int16_t) ~*((u_int16_t *) (op)); > \ > if ((c) < 0) { > \ > (c) += 0xffff; > \ > } > \ > (c) -= (u_int16_t) *((u_int16_t *) (np)); > \ > if ((c) < 0) { > \ > (c) += 0xffff; > \ > } > \ > } while (0) > > it replaces the 16 bit word at *op with the new value at *np and updates > the > checksum c > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 5: 5:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 0411B37B4C5 for ; Wed, 15 Nov 2000 05:05:22 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFD4XO98846; Wed, 15 Nov 2000 15:04:33 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 15:04:33 +0200 From: Ruslan Ermilov To: Julian Elischer Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115150433.A98014@sunbay.com> Mail-Followup-To: Julian Elischer , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <20001113103852.E34671@sunbay.com> <3A126F63.8EB0D49@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A126F63.8EB0D49@elischer.org>; from julian@elischer.org on Wed, Nov 15, 2000 at 03:11:31AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 03:11:31AM -0800, Julian Elischer wrote: > Ruslan Ermilov wrote: > > > Here's the version I wrote some years ago.. > > #define FIXSUM16(c, op, np) \ > do { \ > (c) -= (u_int16_t) ~*((u_int16_t *) (op)); \ > if ((c) < 0) { \ > (c) += 0xffff; \ > } \ > (c) -= (u_int16_t) *((u_int16_t *) (np)); \ > if ((c) < 0) { \ > (c) += 0xffff; \ > } \ > } while (0) > > it replaces the 16 bit word at *op with the new value at *np and updates > the checksum c > The above is the implementation of 4th equation from RFC 1624, right? But we are talking about the version that allows updating of N 16-bit words, not exactly one word. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 5:45: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by hub.freebsd.org (Postfix) with ESMTP id 1FF1537B4C5 for ; Wed, 15 Nov 2000 05:45:04 -0800 (PST) Received: from localhost (IDENT:mshindo@016.cosine.nttpc.gr.jp [202.229.42.16] (may be forged)) by center.mshindo.net (8.9.3/3.7W/00041811) with ESMTP id XAA75435; Wed, 15 Nov 2000 23:01:11 +0900 (JST) Date: Wed, 15 Nov 2000 22:45:51 +0900 (JST) Message-Id: <20001115.224551.59462131.mshindo@mshindo.net> To: freebsd-net@freebsd.org Cc: KuriyaKK@cpf.navy.mil, Jos Backus Subject: Re: Question regarding 'pptpclient' From: Motonori Shindo In-Reply-To: <20001019.182543.74756319.mshindo@mshindo.net> References: <20001019.182543.74756319.mshindo@mshindo.net> X-Mailer: Mew version 1.95b76 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 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 Folks, From: Motonori Shindo Subject: Re: Question regarding 'pptpclient' Date: Thu, 19 Oct 2000 18:25:43 +0900 (JST) Message-ID: <20001019.182543.74756319.mshindo@mshindo.net> > Kuriyama-san, > > From: "Kuriyama, Kent K Mr (CPF N651KK)" > Subject: Question regarding 'pptpclient' > Date: Wed, 18 Oct 2000 22:28:34 -1000 > > > I'm trying to establish a PPTP connection between our FreeBSD 4.1.1-STABLE > > box and an NT4.0 RAS. I have loaded the pptpclient from the packages > > collection but when I attempt to connect I get the message: > > > > "CHAP 0x81 not supported" > > > > What does this message mean and is there a work around? Thanks. > > CHAP 0x81 is MS-CHAPv2. I'm not using the package version of pptp, > instead, I'm using pptp-linux-1.0.2 slightly modified by myself a > while back. It's working with NT4.0 RAS. Some folks asked me how I made pptp-linux-1.0.2 to work under FreeBSD, so here it goes. (sorry this response is so delayed. I had so many other things to do these days...) What I did for pptp-linux-1.0.2 was basically the same as the patches /usr/ports/net/pptpclient/patches/patch-a[a-f]. I just had to do it myself because there was no "ports" for pptp-linux-1.0.2 when I needed it:-) People using packages/ports version don't have to worry about a couple of bugs in original pptp-linux-1.0.2 (notably one where pptp_gre_call_id is falsely set). Depending on what you're using as a PNS, you may still encounter some problems. What I had when I used NT 4.0 as a PNS was a CHAP authentication issue. In LCP negotiation, initially, NT 4.0 requests pptpclient to use EAP but pptpclient reject it (since it doesn't support it) and suggest to use CHAP-MD5 instead. NT accepts CHAP-MD5, and hence pptpclient calculate CHAP Challenge-Response by CHAP-MD5 algorithm. However, NT is, in fact, expecting MS-CHAP!! So, NT responds with CHAP Auth-Failure!! NT should NOT accept CHAP-MD5 in this case but it does.... Sigh. To alliviate this problem, I had to modify pppd so that it offers MS-CHAPv1 instead of CHAP-MD5 first when there's no auth algorithm that it can agree upon. Here's a small patch for it: *** lcp.c.org Wed Nov 15 13:21:47 2000 --- lcp.c Wed Nov 15 13:24:33 2000 *************** *** 1403,1409 **** if (ao->neg_chap) { PUTCHAR(CILEN_CHAP, nakp); PUTSHORT(PPP_CHAP, nakp); ! PUTCHAR(ao->chap_mdtype, nakp); } else { PUTCHAR(CILEN_SHORT, nakp); PUTSHORT(PPP_PAP, nakp); --- 1403,1410 ---- if (ao->neg_chap) { PUTCHAR(CILEN_CHAP, nakp); PUTSHORT(PPP_CHAP, nakp); ! /* PUTCHAR(ao->chap_mdtype, nakp); */ ! PUTCHAR(CHAP_MICROSOFT, nakp); /* added by mshindo */ } else { PUTCHAR(CILEN_SHORT, nakp); PUTSHORT(PPP_PAP, nakp); I hope this helps. Regards, =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 5:56:24 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 8478037B4C5; Wed, 15 Nov 2000 05:56:20 -0800 (PST) Received: from dakar-55.budapest.interware.hu ([195.70.51.119] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w32p-000157-00; Wed, 15 Nov 2000 14:56:12 +0100 Message-ID: <3A1295DE.6930D125@elischer.org> Date: Wed, 15 Nov 2000 05:55:42 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum References: <20001113103852.E34671@sunbay.com> <3A126F63.8EB0D49@elischer.org> <20001115150433.A98014@sunbay.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov wrote: > > On Wed, Nov 15, 2000 at 03:11:31AM -0800, Julian Elischer wrote: > > Ruslan Ermilov wrote: > > > > > Here's the version I wrote some years ago.. > > > > #define FIXSUM16(c, op, np) \ > > do { \ > > (c) -= (u_int16_t) ~*((u_int16_t *) (op)); \ > > if ((c) < 0) { \ > > (c) += 0xffff; \ > > } \ > > (c) -= (u_int16_t) *((u_int16_t *) (np)); \ > > if ((c) < 0) { \ > > (c) += 0xffff; \ > > } \ > > } while (0) > > > > it replaces the 16 bit word at *op with the new value at *np and updates > > the checksum c > > > The above is the implementation of 4th equation from RFC 1624, right? > But we are talking about the version that allows updating of N 16-bit > words, not exactly one word. I can't remember which it was, but I also had a version that did N words.. the same math applies though.. you just do it in a loop :-) I wrote this myself but read the RFCs does it pass your test cases? > > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 5:58:52 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 EBF3F37B4D7 for ; Wed, 15 Nov 2000 05:58:50 -0800 (PST) Received: from dakar-55.budapest.interware.hu ([195.70.51.119] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w35I-0001G5-00; Wed, 15 Nov 2000 14:58:44 +0100 Message-ID: <3A129677.EAA6836E@elischer.org> Date: Wed, 15 Nov 2000 05:58:15 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Motonori Shindo Cc: freebsd-net@freebsd.org, KuriyaKK@cpf.navy.mil, Jos Backus Subject: Re: Question regarding 'pptpclient' References: <20001019.182543.74756319.mshindo@mshindo.net> <20001115.224551.59462131.mshindo@mshindo.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Motonori Shindo wrote: > > Some folks asked me how I made pptp-linux-1.0.2 to work under FreeBSD, > so here it goes. (sorry this response is so delayed. I had so many > other things to do these days...) > I just used the mpd-netgraph port, which does it all in the kernel. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 6:24:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from gomer.august.net (gomer.august.net [216.87.128.131]) by hub.freebsd.org (Postfix) with ESMTP id E71E837B479 for ; Wed, 15 Nov 2000 06:24:14 -0800 (PST) Received: from localhost (1987 bytes) by gomer.august.net via send-mail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Wed, 15 Nov 2000 08:24:08 -0600 (CST) (Smail-3.2.0.108 1999-Sep-19 #1 built 1999-Oct-11) Message-Id: Date: Wed, 15 Nov 2000 08:24:08 -0600 (CST) From: lgfausak@august.net (Greg Fausak) To: alex@pilosoft.com, gcorcoran@lucent.com Subject: Re: netgraph/atm Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >On Tue, 14 Nov 2000, Gary T. Corcoran wrote: > >> > yep.. If that's what rfc1483 (the rfc) treats as input and output. >> >> Actually RFC1483 has four "flavors", two of which support "bridging" >> of complete 802.3 ethernet frames including the MAC addresses - either >> encapsulated with an LLC/SNAP header or "raw" with just a two byte >> (0x00, 0x00) pad for alignment purposes. Another flavor removes the >> MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the >> EtherType and the rest of the frame. The other flavor just routes >> a PDU (raw packet with no MAC addressses or EtherType) across a VC >> (ATM virtual channel) with no encapsulation at all. >Yeah. I'm just implementing it to scratch my itch, and I'll see about >support of everything else later. I'm definitely going to try to support >llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is >already handled just fine by existing ATM stacks. > >> Alex - if you intend to make your code public, and if you feel >> ambititious, it would be nice if you could support all four flavors >> of RFC1483. Then we could replace our Win2000 server with a FreeBSD >> server for testing our DSL implementations of RFC1483... ;-) >Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose >'bridged mac/llc' as preferred method of delivery of DSL, since it has the >biggest overhead...But I guess for them transparency was the biggest >issue. Oh well. FWIW: One of the guys I work with did the DSL implementation for GTE. I asked him about the choice of bridging. He indicated that there are some legal reasons that bridged connections are delivered rather than routed connections. ---greg Greg Fausak August.Net Services, LLC greg@august.net 972-323-6598 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 6:27: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 12CE637B479 for ; Wed, 15 Nov 2000 06:26:53 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFEQFr03423; Wed, 15 Nov 2000 16:26:15 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 16:26:15 +0200 From: Ruslan Ermilov To: Julian Elischer Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115162615.A3145@sunbay.com> Mail-Followup-To: Julian Elischer , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <20001113103852.E34671@sunbay.com> <3A126F63.8EB0D49@elischer.org> <20001115150433.A98014@sunbay.com> <3A1295DE.6930D125@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A1295DE.6930D125@elischer.org>; from julian@elischer.org on Wed, Nov 15, 2000 at 05:55:42AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 05:55:42AM -0800, Julian Elischer wrote: > Ruslan Ermilov wrote: > > > > On Wed, Nov 15, 2000 at 03:11:31AM -0800, Julian Elischer wrote: > > > Ruslan Ermilov wrote: > > > > > > > Here's the version I wrote some years ago.. > > > > > > #define FIXSUM16(c, op, np) \ > > > do { \ > > > (c) -= (u_int16_t) ~*((u_int16_t *) (op)); \ > > > if ((c) < 0) { \ > > > (c) += 0xffff; \ > > > } \ > > > (c) -= (u_int16_t) *((u_int16_t *) (np)); \ > > > if ((c) < 0) { \ > > > (c) += 0xffff; \ > > > } \ > > > } while (0) > > > > > > it replaces the 16 bit word at *op with the new value at *np and updates > > > the checksum c > > > > > The above is the implementation of 4th equation from RFC 1624, right? > > But we are talking about the version that allows updating of N 16-bit > > words, not exactly one word. > > I can't remember which it was, but I also had a version that did N > words.. > the same math applies though.. > you just do it in a loop :-) > > I wrote this myself but read the RFCs > does it pass your test cases? > I will try your one-word version, but it would be really nice if you have found the N-word version, so I could test it further. I am mostly interested in how to convert two's complement subtraction to one's complement subtraction. I went further, and wrote another test program that demonstrates that both implementation for formula 4 I posted at the very beginning, and the current version in libalias(3) produce wrong results in some cases. By "wrong" here I mean really wrong results, not the 0 -> 0xffff case. See my next posting... -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 6:36:20 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 E991D37B479; Wed, 15 Nov 2000 06:36:17 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFEaHG65417; Wed, 15 Nov 2000 09:36:17 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011151436.eAFEaHG65417@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> In-reply-to: Your message of "Wed, 15 Nov 2000 10:04:07 +0200." <20001115100407.D36400@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 09:36:17 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Tue, Nov 14, 2000 at 10:15:18PM -0500, Louis A. Mamakos wrote: > > > > Arithmetically, a value of 0xffff is identical to 0x0000 since they > > both represent the value of zero when using a one's complement binary > > representation of values. > > > Except you can't actually receive the value of 0xffff in a checksum field. > One's complement sum is guaranteed to be non-zero except if all items are > zeroes. Since IP Protocol field is a non-zero value that participates in > all checksums (IP, TCP, UDP, ICMP), the checksum value (which is a one's > complement of a one's complement sum) is guaranteed to be non-0xffff. For other than UDP, it really doesn't make a difference if the value of the checksum field is 0x0000 (+0) or 0xffff (-0); they both have the (1's complement arithmetic) value of zero. > > It turns that this property is used in some network protocols (e.g., UDP) > > to distinguish between a checksum value that's computed as zero (represented > > as 0xffff in the packet) from a packet which has no computed checksum at all. > > This was done in the dark ages when it was deemed "too expensive" to > > compute a checksum. > > > >From the above it follows that UDP should better be using 0xffff rather than > 0x0 to indicate that a packet has no computed checksum. It is quite possible > that the computed checksum will have a zero value, in which case the receiving > UDP module will consider such a packet as with no computed checksum, which is > wrong. But the checksum is supposed to be the one's complement of the checksum of the payload (which is computed using one's complement arithmetic). If you compute a checksum, and the value is zero, you insert the complemented value (0xffff) into the packet. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 7:17:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (mail.rv.scientech.com [198.60.89.9]) by hub.freebsd.org (Postfix) with ESMTP id 2D9C737B657; Wed, 15 Nov 2000 07:17:35 -0800 (PST) Received: from carcassonne (carcassonne.scientech.com [10.10.25.250]) by if.scientech.com (8.9.3/8.9.3) with ESMTP id IAA19007; Wed, 15 Nov 2000 08:15:52 -0700 Date: Wed, 15 Nov 2000 08:15:52 -0700 (MST) From: Charles Mott To: "Louis A. Mamakos" Cc: Ruslan Ermilov , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <200011151436.eAFEaHG65417@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Nov 2000, Louis A. Mamakos wrote: > But the checksum is supposed to be the one's complement of the checksum > of the payload (which is computed using one's complement arithmetic). If > you compute a checksum, and the value is zero, you insert the complemented > value (0xffff) into the packet. > > louie A 1's complement sum of the payload can never be 0x0000 if any components the payload are non-zero. Therefore a checksum of 0xffff is not possible, since at least the word containing the IP protocol byte is non zero. This is explained in RFC 1624. I think that Ruslan has done his homework on this subject, and there is really no point to dispute the matter further. Charles Mott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 7:25:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7940837B479 for ; Wed, 15 Nov 2000 07:25:14 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFFOZp09981; Wed, 15 Nov 2000 17:24:35 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 17:24:35 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115172435.A9724@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151436.eAFEaHG65417@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 09:36:17AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 09:36:17AM -0500, Louis A. Mamakos wrote: > > On Tue, Nov 14, 2000 at 10:15:18PM -0500, Louis A. Mamakos wrote: > > > > > > Arithmetically, a value of 0xffff is identical to 0x0000 since they > > > both represent the value of zero when using a one's complement binary > > > representation of values. > > > > > Except you can't actually receive the value of 0xffff in a checksum field. > > One's complement sum is guaranteed to be non-zero except if all items are > > zeroes. Since IP Protocol field is a non-zero value that participates in > > all checksums (IP, TCP, UDP, ICMP), the checksum value (which is a one's > > complement of a one's complement sum) is guaranteed to be non-0xffff. > > For other than UDP, it really doesn't make a difference if the value of > the checksum field is 0x0000 (+0) or 0xffff (-0); they both have the > (1's complement arithmetic) value of zero. > It does not matter only in case if the checksum verification is done using the checksum field itself (as most implementations do). In case it is recomputer afresh, and then compared with the value in checksum field, this WILL make a difference. > > > It turns that this property is used in some network protocols (e.g., UDP) > > > to distinguish between a checksum value that's computed as zero (represented > > > as 0xffff in the packet) from a packet which has no computed checksum at all. > > > This was done in the dark ages when it was deemed "too expensive" to > > > compute a checksum. > > > > > >From the above it follows that UDP should better be using 0xffff rather than > > 0x0 to indicate that a packet has no computed checksum. It is quite possible > > that the computed checksum will have a zero value, in which case the receiving > > UDP module will consider such a packet as with no computed checksum, which is > > wrong. > > But the checksum is supposed to be the one's complement of the checksum > of the payload (which is computed using one's complement arithmetic). If > you compute a checksum, and the value is zero, you insert the complemented > value (0xffff) into the packet. > If I compute the sum on IP PACKET, then sum can't be zero, so checksum can never be a 0xffff. This is all explained in RFC 1624, BTW :-) -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 7:41:16 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 BAF8437B4CF; Wed, 15 Nov 2000 07:41:13 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFFf6G65968; Wed, 15 Nov 2000 10:41:06 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011151541.eAFFf6G65968@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Charles Mott Cc: Ruslan Ermilov , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: In-reply-to: Your message of "Wed, 15 Nov 2000 08:15:52 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 10:41:06 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, 15 Nov 2000, Louis A. Mamakos wrote: > > But the checksum is supposed to be the one's complement of the checksum > > of the payload (which is computed using one's complement arithmetic). If > > you compute a checksum, and the value is zero, you insert the complemented > > value (0xffff) into the packet. > > > > louie > > A 1's complement sum of the payload can never be 0x0000 if any > components the payload are non-zero. Therefore a checksum of > 0xffff is not possible, since at least the word containing the > IP protocol byte is non zero. This is explained in RFC 1624. You know, it really depends on how the sum is computed. On the IP stack that I wrote for a UNIVAC 1108, which had one's complement representations of signed integers, the ALU always produced positive zero values when computing the results of an ADD operation. What intermediate values are produced is a function of how you emulate 1's complement arithmetic operations on a 2's complement ALU in your CPU. So your statement about the 1's complement sum never being zero doesn't make sense; by definition it is. Perhaps the fidelity of the emulation is at issue here, rather than the algorithm. > I think that Ruslan has done his homework on this subject, and > there is really no point to dispute the matter further. I suspect the homework to be assigned should be reading some undergraduate computer architecture textbooks. I think it important to consider the checksum operation and how the network protocols use it independently of any particular implementation. 0xFFFE + 0x0001 == 0x0000 on a 16 bit 1's complement CPU with normalized results. This is what the protocol specs assume when they talk about the 1's complement sum. When you take the 1's complement of this value to inserting into the checksum field, you get 0xFFFF (which is still zero) and distinct from 0x0000 which for UDP means "no checksum computed". This special property of 1's complement arithement that results in two representations for zero is used as a hack for the "no checksum" encoding. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 7:41:52 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B09EE37B4C5 for ; Wed, 15 Nov 2000 07:41:33 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFFeW111099; Wed, 15 Nov 2000 17:40:32 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 17:40:31 +0200 From: Ruslan Ermilov To: Julian Elischer , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115174031.A10161@sunbay.com> Mail-Followup-To: Julian Elischer , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <20001113103852.E34671@sunbay.com> <3A126F63.8EB0D49@elischer.org> <20001115150433.A98014@sunbay.com> <3A1295DE.6930D125@elischer.org> <20001115162615.A3145@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001115162615.A3145@sunbay.com>; from ru@FreeBSD.ORG on Wed, Nov 15, 2000 at 04:26:15PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 15, 2000 at 04:26:15PM +0200, Ruslan Ermilov wrote: [...] > > I went further, and wrote another test program that demonstrates that > both implementation for formula 4 I posted at the very beginning, and > the current version in libalias(3) produce wrong results in some cases. > By "wrong" here I mean really wrong results, not the 0 -> 0xffff case. > See my next posting... > The attached program demonstrates problems with both my implementation of RFC1624's equation 4 (see the original message in this thread), and the current implementation of incremental checksum update in libalias. This program takes 11 seconds on my 500MHz Celeron. You may also want to remove the `break' statements to see the whole story. Basically, what it does, is: 1. Constructs two fake IP packets (old and new) 2. Computes the checksum of the old packet (old checksum) 3. Computes the checksum of the new packet (new checksum) 4. Computes new checksum using one or more differential update procedure 5. Compares the checksums obtained in steps 3 and 4. Have fun, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile PROG= inc_cksum NOMAN= YES CFLAGS+=${BDECFLAGS} .if ${MACHINE_ARCH} == i386 CFLAGS+=-O3 .endif CFLAGS+=-DLIBALIAS CFLAGS+=-DRFC1624_3 CFLAGS+=-DRFC1624_4 .include --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="inc_cksum.c" #include #include #include u_short PacketAliasInternetChecksum(u_short *, int nbytes); void test(int, int); #ifdef LIBALIAS void DifferentialChecksum_libalias(u_short *, u_short *, u_short *, int); #endif #ifdef RFC1624_3 void DifferentialChecksum_RFC1624_3(u_short *, u_short *, u_short *, int); #endif #ifdef RFC1624_4 void DifferentialChecksum_RFC1624_4(u_short *, u_short *, u_short *, int); #endif u_short PacketAliasInternetChecksum(u_short *ptr, int nbytes) { int sum, oddbyte; sum = 0; while (nbytes > 1) { sum += *ptr++; nbytes -= 2; } if (nbytes == 1) { oddbyte = 0; ((u_char *) &oddbyte)[0] = *(u_char *) ptr; ((u_char *) &oddbyte)[1] = 0; sum += oddbyte; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return(~sum); } #ifdef LIBALIAS void DifferentialChecksum_libalias(u_short *cksum, u_short *new, u_short *old, int n) { int i; int accumulate; accumulate = *cksum; for (i=0; i> 16) + (accumulate & 0xffff); accumulate += accumulate >> 16; *cksum = (u_short) ~accumulate; } else { accumulate = (accumulate >> 16) + (accumulate & 0xffff); accumulate += accumulate >> 16; *cksum = (u_short) accumulate; } } #endif #ifdef RFC1624_3 /* * Incremental Update of Internet Checksum with [Eqn. 3] from RFC 1624. */ void DifferentialChecksum_RFC1624_3(u_short *cksum, u_short *new, u_short *old, int n) { int i; u_int acc; acc = (u_short)~*cksum; for (i = 0; i < n; i++) { acc += *new++; acc += (u_short)~*old++; } acc = (acc >> 16) + (acc & 0xffff); acc += acc >> 16; *cksum = (u_short)~acc; } #endif #ifdef RFC1624_4 /* * Incremental Update of Internet Checksum with [Eqn. 4] from RFC 1624. */ void DifferentialChecksum_RFC1624_4(u_short *cksum, u_short *new, u_short *old, int n) { int i; int acc; /* should be `signed' */ acc = *cksum; for (i = 0; i < n; i++) { acc -= *new++; acc -= (u_short)~*old++; } acc = (acc >> 16) + (acc & 0xffff); acc += acc >> 16; *cksum = (u_short)acc; } #endif void test(int oldword, int newword) { #define MAXWORDS 32767 u_short old[MAXWORDS], new[MAXWORDS]; int i, nbytes, nwords; u_short oldcksum, newcksum; u_short cksum_libalias, cksum_rfc1624_3, cksum_rfc1624_4; /* Construct the fake packets. */ for (i = 0; i < MAXWORDS; i++) { old[i] = oldword; new[i] = newword; } /* Make sure the sum will be non-zero. */ old[0] = new[0] = 1; /* Try the different lengths. */ for (nwords = 1; nwords <= MAXWORDS; nwords++) { nbytes = nwords << 1; /* Calculate the checksums from scratch. */ oldcksum = cksum_libalias = cksum_rfc1624_3 = cksum_rfc1624_4 = PacketAliasInternetChecksum(old, nbytes); newcksum = PacketAliasInternetChecksum(new, nbytes); /* Calculate the checksums incrementally. */ #ifdef LIBALIAS DifferentialChecksum_libalias(&cksum_libalias, new, old, nwords); #endif #ifdef RFC1624_3 DifferentialChecksum_RFC1624_3(&cksum_rfc1624_3, new, old, nwords); #endif #ifdef RFC1624_4 DifferentialChecksum_RFC1624_4(&cksum_rfc1624_4, new, old, nwords); #endif #ifdef LIBALIAS /* Check the libalias(3) current procedure. */ if (cksum_libalias != newcksum && (cksum_libalias != 0xffff || newcksum != 0)) { printf("cksum_libalias!=newcksum %#hx!=%#hx, nwords=%d\n", cksum_libalias, newcksum, nwords); break; } #endif #ifdef RFC1624_3 /* Check the implementation of algorithm for equation 3. */ if (cksum_rfc1624_3 != newcksum) { printf("cksum_rfc1624_3!=newcksum %#hx!=%#hx, nwords=%d\n", cksum_rfc1624_3, newcksum, nwords); break; } #endif #ifdef RFC1624_4 /* Check the implementation of algorithm for equation 4. */ if (cksum_rfc1624_4 != newcksum) { printf("cksum_rfc1624_4!=newcksum %#hx!=%#hx, nwords=%d\n", cksum_rfc1624_4, newcksum, nwords); break; } #endif } #undef MAXWORDS } int main(void) { test(0xffff, 0x0000); test(0x0000, 0xffff); return (0); } --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 7:48:22 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 DD79837B4D7; Wed, 15 Nov 2000 07:48:19 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFFmJG66031; Wed, 15 Nov 2000 10:48:19 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011151548.eAFFmJG66031@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> In-reply-to: Your message of "Wed, 15 Nov 2000 17:24:35 +0200." <20001115172435.A9724@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 10:48:19 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If I compute the sum on IP PACKET, then sum can't be zero, so checksum can > never be a 0xffff. This is all explained in RFC 1624, BTW :-) I can see you you would think this, given the errornous statement from the RFC: In one's complement, there are two representations of zero: the all zero and the all one bit values, often referred to as +0 and -0. One's complement addition of non-zero inputs can produce -0 as a result, but never +0. Since there is guaranteed to be at least one non-zero field in the IP header, and the checksum field in the protocol header is the complement of the sum, the checksum field can never contain ~(+0), which is -0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000). However, having actually used 1's complement-based ALU's, I can assure you that one's complement addition of non-zero inputs certainlly can produce +0 as the result. I have the core plane from that machine in my office as proof :-) louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 8: 9:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id ABE1837B4CF for ; Wed, 15 Nov 2000 08:09:19 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFG8gb12929; Wed, 15 Nov 2000 18:08:42 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 18:08:42 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115180842.A11913@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151548.eAFFmJG66031@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 10:48:19AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 10:48:19AM -0500, Louis A. Mamakos wrote: > > > If I compute the sum on IP PACKET, then sum can't be zero, so checksum can > > never be a 0xffff. This is all explained in RFC 1624, BTW :-) > > I can see you you would think this, given the errornous statement > from the RFC: > > In one's complement, there are two representations of zero: the all > zero and the all one bit values, often referred to as +0 and -0. > One's complement addition of non-zero inputs can produce -0 as a > result, but never +0. Since there is guaranteed to be at least one > non-zero field in the IP header, and the checksum field in the > protocol header is the complement of the sum, the checksum field can > never contain ~(+0), which is -0 (0xFFFF). It can, however, contain > ~(-0), which is +0 (0x0000). > > However, having actually used 1's complement-based ALU's, I can assure > you that one's complement addition of non-zero inputs certainlly can > produce +0 as the result. I have the core plane from that machine in > my office as proof :-) > If the above would be true that would mean that almost all implementations of computing the checksum are wrong, i.e. they produce the value of 0x0000 as a checksum when it should actually be 0xffff. That would also mean all three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! My understanding of the one's complement sum is as follows: This is the sum (or an algorithm to compute such a sum), which produces the RIGHT results for items represented in one's complement form, the form in which negative numbers are represented by one's complements of a positive number. You mentioned the books... Can you citate from one of these books that states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 rather than 0xFFFF? -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 8:34:47 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 7841737B4C5 for ; Wed, 15 Nov 2000 08:34:43 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id LAA05586; Wed, 15 Nov 2000 11:35:32 -0500 (EST) Date: Wed, 15 Nov 2000 11:35:32 -0500 (EST) From: Alex Pilosov To: Julian Elischer Cc: "Gary T. Corcoran" , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm In-Reply-To: <3A126A2D.7F43B120@elischer.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 Wed, 15 Nov 2000, Julian Elischer wrote: > My question is whether there are any boards that can give us the > physical interface to a DSL line so that we can run this ATM code over > a DSL line? It's one thing having the software but the bits need to > get out of the system somehow. I'm looking at the ISP side of this. To ISP, DSL service is always delivered as normal ATM circuit. For customer's side, its also delivered as low-speed atm connection. There is already a driver for Efficient Networks hardware "lanai" by someone in .ee, which the author plans to netgraph-enable too. > One thing I just thought about, is that if we are simulating an > ethernet interface and bridging the packets using mac/llc > then wouldn;t we require that we have some unique MAC address > for that virtual interface so that things don't break? > (can we just always use broadcast?) are the packets multiplexed > using destination MAC address? True. Cisco in this case generates random number as a mac address. For us, we must add support for SIOCGIFADDR to 'virtual ethernet' device (if its not already there). In case of broadcast, it should be rebroadcast to all VCs in the bridge group, if that's what you are asking. > Also which of the two ATM stacks in FreeBSD is the most suitable? > I'm guessing HARP, but NATM, because it is such a very basic > framework, might be suitable for netgraphification.. I don't think it would be very hard to netgraph-enable HARP. But we'll see, once I start writing code ;) > (I have no idea if I'm talking rubish but > a simple netgraph node that does aal1/aal5 > would fit into the netgraph world very well.) There really isn't a need to do AAL1/5, since its always handled by the ATM card in hardware (you just have to tell it to do it). The cool part is extraction of specific VC traffic as netgraph streams. The very-very ambitious stuff is to have SCSP node (SVC establishment protocol) as a node in netgraph, and reorganize all the HARP code to be nodes and edges, handling routed packets via netgraph as well... But this will require a lot of rethinking, and semantics for routed interface is unclear...At any case, this is stuff for later ;) -alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 8:54:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from papoose.quick.com (unknown [199.120.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 8D96337B4CF for ; Wed, 15 Nov 2000 08:54:19 -0800 (PST) Received: (from jq@localhost) by papoose.quick.com (8.10.1/8.10.1) id eAFGsCC24802 for freebsd-net@freebsd.org; Wed, 15 Nov 2000 11:54:12 -0500 (EST) Message-Id: <200011151654.eAFGsCC24802@papoose.quick.com> MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <5.0.0.25.0.20000923105128.02ee5840@mail.Go2France.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 2.2p1) Received: by NeXT.Mailer (1.118.2) From: "James E. Quick" Date: Wed, 15 Nov 2000 11:54:11 -0500 To: freebsd-net@freebsd.org Subject: I need help with IPSEC Reply-To: jq@quick.com References: <5.0.0.25.0.20000923105128.02ee5840@mail.Go2France.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am in desperate need of help with IPSEC. I have a pair of firewalls configured with: IPSEC IPSEC_ESP IPSEC_DEBUG I started with an attempt using raccoon, then backed off to using manually added entries via skey. I do not see anything in racoon output that looks like an error. The remote end of the gateway is a box running 4.1.1-STABLE. It has a single public IP address via a cable modem with 172.16.1.x addresses behind it. My endpoint is running 4.2-BETA and has an ISP provided /30 subnet externally, with my publicly routable Class C behind. I note that when I try to reach any 172.16.1 address with either form of IPSEC configured I get 'No route to host' errors. This suggests that IPSEC is not encapsulating anything. I would appreciate hearing from anyone who has set up esp style tunnels between either 2 FreeBSDs or between FreeBSD and anything else. There must be something trivial that I am overlooking, because I am not seeing anything that looks like an error. We are both running ipfilt on our ends. The remote site is also running simple ipnat configuration. --- ___ ___ | James E. Quick / / / | Quick & Associates NeXTMail O.K. \_/ (_\/ | If only the HMO would cover my allergy to gravity. ) | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 9:24:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from alice.twopoint.com (unknown [209.64.88.26]) by hub.freebsd.org (Postfix) with ESMTP id 64E6737B4C5 for ; Wed, 15 Nov 2000 09:24:10 -0800 (PST) Received: from twopoint.com (hamilton@fred.twopoint.com [192.168.1.3]) by alice.twopoint.com (8.8.7/8.8.7) with ESMTP id LAA28882 for ; Wed, 15 Nov 2000 11:26:12 -0600 Message-ID: <3A12C77C.3D095AC4@twopoint.com> Date: Wed, 15 Nov 2000 11:27:24 -0600 From: Hamilton Hoover Organization: Two Point Conversions, INC. X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ipsec vpn on firewall Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been given the task of setting up a vpn using ipsec on our firewall. I am somewhat new to FreeBsd and am not sure of how to go about this. We are trying to let home dsl users connect securely to our corporate lan and browse through 'network neighborhood'. Home users are using win9x with PGP Personal Firewall and the Office runs FreeBsd 4.1. The Firewall is nated. All incoming requests are blocked so I also don't know what holes if any to poke in the firewall. I included the FreeBsd ipsec package when I installed the system but after looking at the man pages I don't get it. I have looked for a howto as well as a tutorial and haven't found anything on setting up the vpn. If anyone know of an idiot proof howto or some good resources please let me know. If more info is needed I will do my best to supply it. Thanks, Hamilton Hoover To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 9:33: 1 2000 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 1634F37B4CF for ; Wed, 15 Nov 2000 09:32:59 -0800 (PST) Received: (qmail 1887 invoked by uid 1000); 15 Nov 2000 17:33:31 -0000 Date: Wed, 15 Nov 2000 09:33:31 -0800 From: Jos Backus To: freebsd-net@freebsd.org Subject: Re: Question regarding 'pptpclient' Message-ID: <20001115093331.A371@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-net@freebsd.org References: <20001019.182543.74756319.mshindo@mshindo.net> <20001115.224551.59462131.mshindo@mshindo.net> <3A129677.EAA6836E@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A129677.EAA6836E@elischer.org>; from julian@elischer.org on Wed, Nov 15, 2000 at 05:57:53AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 05:57:53AM -0800, Julian Elischer wrote: > I just used the mpd-netgraph port, which does it all in the kernel. It doesn't support MS-CHAPv2 (yet), though. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 12:36:52 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 81AC537B4CF for ; Wed, 15 Nov 2000 12:36:46 -0800 (PST) Received: from monrovia-18.budapest.interware.hu ([195.70.53.210] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13w9IK-0002iM-00; Wed, 15 Nov 2000 21:36:37 +0100 Message-ID: <3A12F3B7.CA569AAA@elischer.org> Date: Wed, 15 Nov 2000 12:36:07 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Pilosov , "Gary T. Corcoran" , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm References: <3A126A2D.7F43B120@elischer.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just realised that you could even do this without changing the ATM code, as the ATM code can be attached to by sockets and the netgraph system knows how to make socket-like endpoints into nodes. So you using the netgraph "ksocket" type one could open an ATM socket on some channel and attach it via netgraph to the eiface type of node. this effectively gives you an ethernet interface, attached to a PVC (or whatever you open the socket as.) Just a thought.. (though a native Netgraph interface to the ATM code would be cooler). Julian Elischer wrote: > > Alex Pilosov wrote: > > > > On Tue, 14 Nov 2000, Gary T. Corcoran wrote: > > > > > > yep.. If that's what rfc1483 (the rfc) treats as input and output. > > > > > > Actually RFC1483 has four "flavors", two of which support "bridging" > > > of complete 802.3 ethernet frames including the MAC addresses - either > > > encapsulated with an LLC/SNAP header or "raw" with just a two byte > > > (0x00, 0x00) pad for alignment purposes. Another flavor removes the > > > MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the > > > EtherType and the rest of the frame. The other flavor just routes > > > a PDU (raw packet with no MAC addressses or EtherType) across a VC > > > (ATM virtual channel) with no encapsulation at all. > > Yeah. I'm just implementing it to scratch my itch, and I'll see about > > support of everything else later. I'm definitely going to try to support > > llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is > > already handled just fine by existing ATM stacks. > > > > > Alex - if you intend to make your code public, and if you feel > > > ambititious, it would be nice if you could support all four flavors > > > of RFC1483. Then we could replace our Win2000 server with a FreeBSD > > > server for testing our DSL implementations of RFC1483... ;-) > > Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose > > 'bridged mac/llc' as preferred method of delivery of DSL, since it has the > > biggest overhead...But I guess for them transparency was the biggest > > issue. Oh well. > > My question is whether there are any boards that can give us the > physical > interface to a DSL line so that we can run this ATM code over a DSL > line? > It's one thing having the software but the bits need to get out of the > system somehow. > > One thing I just thought about, is that if we are simulating an > ethernet interface and bridging the packets using mac/llc > then wouldn;t we require that we have some unique MAC address > for that virtual interface so that things don't break? > (can we just always use broadcast?) are the packets multiplexed > using destination MAC address? > > Also which of the two ATM stacks in FreeBSD is the most suitable? > I'm guessing HARP, but NATM, because it is such a very basic > framework, might be suitable for netgraphification.. > > (I have no idea if I'm talking rubish but > a simple netgraph node that does aal1/aal5 > would fit into the netgraph world very well.) > > > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Wed Nov 15 12:38:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by hub.freebsd.org (Postfix) with ESMTP id 93E8637B4CF for ; Wed, 15 Nov 2000 12:38:11 -0800 (PST) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA26978 for ; Wed, 15 Nov 2000 15:38:11 -0500 (EST) Received: from mhmail.mh.lucent.com (h135-3-115-8.lucent.com [135.3.115.8]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA26952; Wed, 15 Nov 2000 15:38:10 -0500 (EST) Received: from lucent.com (positron.micro.lucent.com [192.19.56.129]) by mhmail.mh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA00444; Wed, 15 Nov 2000 15:38:08 -0500 (EST) Message-ID: <3A12F3DE.4B3951D9@lucent.com> Date: Wed, 15 Nov 2000 15:36:46 -0500 From: "Gary T. Corcoran" Reply-To: gcorcoran@lucent.com Organization: Lucent Microelectronics - Client Access Broadband Systems X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alex Pilosov , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm References: <3A126A2D.7F43B120@elischer.org> 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 wrote: > > My question is whether there are any boards that can give us the > physical > interface to a DSL line so that we can run this ATM code over a DSL > line? > It's one thing having the software but the bits need to get out of the > system somehow. You mean other than the Lucent DSL boards (which none of you appear to have?) ? :-) No, I haven't had time to look into netgraph'ifying my driver, and I'm getting pulled in another direction now... :( > One thing I just thought about, is that if we are simulating an > ethernet interface and bridging the packets using mac/llc > then wouldn;t we require that we have some unique MAC address > for that virtual interface so that things don't break? Yes, absolutely. The Lucent DSL boards get a unique MAC address programmed into them by the OEM or the board manufacturer, so that they will work properly in the ethernet bridging modes (where they appear as an ethernet card to the PC when in those modes). > (can we just always use broadcast?) No. Only broadcast packets use the broadcast address. > are the packets multiplexed using destination MAC address? I'm not sure what you're asking here. In the usual case where you're only using one VC, the packets are sent through the channel one at a time, in the order they come down to the driver. For multiple VCs, we learn which MAC destination is connected to which particular VC, and only send the packet on that VC. Broadcast packets go out over all active VC's. Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 12:43:25 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 5631637B4C5; Wed, 15 Nov 2000 12:43:23 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFKhMG68318; Wed, 15 Nov 2000 15:43:22 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011152043.eAFKhMG68318@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> In-reply-to: Your message of "Wed, 15 Nov 2000 18:08:42 +0200." <20001115180842.A11913@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 15:43:22 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If the above would be true that would mean that almost all implementations > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > as a checksum when it should actually be 0xffff. That would also mean all > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is negative zero, other other a positive zero.) I think the authors make an error when they conclude that the result of an addition can only be a negative zero rather than a positive zero, but in the end it doesn't really matter which representation of zero you use, because they are arithmetically equal. I think the authors of those RFCs probably had 2's complement CPUs in mind, and were thinking about commonly used emulations of 1's complement arithemetic operations. > My understanding of the one's complement sum is as follows: > > This is the sum (or an algorithm to compute such a sum), which produces > the RIGHT results for items represented in one's complement form, the form > in which negative numbers are represented by one's complements of a > positive number. > > You mentioned the books... Can you citate from one of these books that > states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 > rather than 0xFFFF? The correct result is 0x0001, since 0xffff is -0, and -0 + 1 == 1. 0xFFFE + 0x0001 == 0, because 0xFFFE is -1 and -1 + 1 == 0. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 12:46:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0976337B479; Wed, 15 Nov 2000 12:46:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.9.3/8.9.3) id MAA00949; Wed, 15 Nov 2000 12:46:43 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200011152046.MAA00949@iguana.aciri.org> Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <200011152043.eAFKhMG68318@whizzo.transsys.com> from "Louis A. Mamakos" at "Nov 15, 2000 3:43:22 pm" To: louie@TransSys.COM (Louis A. Mamakos) Date: Wed, 15 Nov 2000 12:46:43 -0800 (PST) Cc: ru@FreeBSD.ORG, cmott@scientech.com, archie@dellroad.org, net@FreeBSD.ORG, ari@suutari.iki.fi X-Mailer: ELM [version 2.4ME+ PL43 (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 > > If the above would be true that would mean that almost all implementations > > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > > as a checksum when it should actually be 0xffff. That would also mean all > > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! > > But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is hmm... from memory: one of the two 'zero' values is used in UDP to indicate NO CHECKSUM. Not sure if the same applies to TCP and IP headers as well, but this would explain why the error (if there) goes unnoticed. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 12:55:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id 2F62537B4E5 for ; Wed, 15 Nov 2000 12:55:23 -0800 (PST) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id PAA29378; Wed, 15 Nov 2000 15:56:13 -0500 (EST) Date: Wed, 15 Nov 2000 15:56:13 -0500 (EST) From: Alex Pilosov To: Julian Elischer Cc: "Gary T. Corcoran" , freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm In-Reply-To: <3A12F3B7.CA569AAA@elischer.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 Excellent point. Only thing to change will be ng_ksocket, and making it understand ATM address family. Thanks :) On Wed, 15 Nov 2000, Julian Elischer wrote: > I just realised that you could even do this without changing the ATM > code, > as the ATM code can be attached to by sockets and the netgraph > system knows how to make socket-like endpoints into nodes. > > So you using the netgraph "ksocket" type one could open > an ATM socket on some channel > and attach it via netgraph to the eiface type of node. > this effectively gives you an ethernet interface, attached to > a PVC (or whatever you open the socket as.) > > Just a thought.. > (though a native Netgraph interface to the ATM code would be cooler). > > > Julian Elischer wrote: > > > > Alex Pilosov wrote: > > > > > > On Tue, 14 Nov 2000, Gary T. Corcoran wrote: > > > > > > > > yep.. If that's what rfc1483 (the rfc) treats as input and output. > > > > > > > > Actually RFC1483 has four "flavors", two of which support "bridging" > > > > of complete 802.3 ethernet frames including the MAC addresses - either > > > > encapsulated with an LLC/SNAP header or "raw" with just a two byte > > > > (0x00, 0x00) pad for alignment purposes. Another flavor removes the > > > > MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the > > > > EtherType and the rest of the frame. The other flavor just routes > > > > a PDU (raw packet with no MAC addressses or EtherType) across a VC > > > > (ATM virtual channel) with no encapsulation at all. > > > Yeah. I'm just implementing it to scratch my itch, and I'll see about > > > support of everything else later. I'm definitely going to try to support > > > llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is > > > already handled just fine by existing ATM stacks. > > > > > > > Alex - if you intend to make your code public, and if you feel > > > > ambititious, it would be nice if you could support all four flavors > > > > of RFC1483. Then we could replace our Win2000 server with a FreeBSD > > > > server for testing our DSL implementations of RFC1483... ;-) > > > Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose > > > 'bridged mac/llc' as preferred method of delivery of DSL, since it has the > > > biggest overhead...But I guess for them transparency was the biggest > > > issue. Oh well. > > > > My question is whether there are any boards that can give us the > > physical > > interface to a DSL line so that we can run this ATM code over a DSL > > line? > > It's one thing having the software but the bits need to get out of the > > system somehow. > > > > One thing I just thought about, is that if we are simulating an > > ethernet interface and bridging the packets using mac/llc > > then wouldn;t we require that we have some unique MAC address > > for that virtual interface so that things don't break? > > (can we just always use broadcast?) are the packets multiplexed > > using destination MAC address? > > > > Also which of the two ATM stacks in FreeBSD is the most suitable? > > I'm guessing HARP, but NATM, because it is such a very basic > > framework, might be suitable for netgraphification.. > > > > (I have no idea if I'm talking rubish but > > a simple netgraph node that does aal1/aal5 > > would fit into the netgraph world very well.) > > > > > > > -- > > __--_|\ Julian Elischer > > / \ julian@elischer.org > > ( OZ ) World tour 2000 > > ---> X_.---._/ presently in: Budapest > > v > > > > 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 Nov 15 12:56:59 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 530C337B4CF; Wed, 15 Nov 2000 12:56:56 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id eAFKuoG68498; Wed, 15 Nov 2000 15:56:50 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200011152056.eAFKuoG68498@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luigi Rizzo Cc: ru@FreeBSD.ORG, cmott@scientech.com, archie@dellroad.org, net@FreeBSD.ORG, ari@suutari.iki.fi X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011152046.MAA00949@iguana.aciri.org> In-reply-to: Your message of "Wed, 15 Nov 2000 12:46:43 PST." <200011152046.MAA00949@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 15:56:50 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > If the above would be true that would mean that almost all implementations > > > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > > > as a checksum when it should actually be 0xffff. That would also mean all > > > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! > > > > But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is > > hmm... from memory: one of the two 'zero' values is used in UDP to > indicate NO CHECKSUM. Not sure if the same applies to TCP and IP > headers as well, but this would explain why the error (if there) > goes unnoticed. The +0 == 0x0000 value in the UDP checksum field indicates "no checksum", while -0 == 0xffff value is the 1's complement of the computed packet checksum value of zero. This all makes sense if you consider that the first implementioon of these protocols were on 1's complement hardware. Set the checksum field to zero, compute the checksum of the packet header, take the 1's complement (e.g., invert all the bigs) and store the computed value in the checksum field. On actual hardware ALUs, the computed checksum will never be 0xFFFF because the ALU implementations typicaly produce a normalized (positive zero) value should the result of an addition be either -0 or +0. When you then complement the computed checksum, you'll get the "correct" value of 0xffff to store in the checksum field of the packet, and you don't have to do anything special to avoid the distinguished "no checksum" value of 0xffff. From RFC 768: Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This information gives protection against misrouted datagrams. This checksum procedure is the same as is used in TCP. 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+ If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 13:50:32 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 5BEDE37B4D7 for ; Wed, 15 Nov 2000 13:50:29 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id OAA56037; Wed, 15 Nov 2000 14:49:50 -0700 (MST) Date: Wed, 15 Nov 2000 14:49:50 -0700 (MST) From: Nick Rogness To: "James E. Quick" Cc: freebsd-net@freebsd.org Subject: Re: I need help with IPSEC In-Reply-To: <200011151654.eAFGsCC24802@papoose.quick.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 Wed, 15 Nov 2000, James E. Quick wrote: > I am in desperate need of help with IPSEC. > I have a pair of firewalls configured with: > IPSEC > IPSEC_ESP > IPSEC_DEBUG > > I started with an attempt using raccoon, then backed off > to using manually added entries via skey. > I do not see anything in racoon output that looks like an > error. > > The remote end of the gateway is a box running 4.1.1-STABLE. > It has a single public IP address via a cable modem with > 172.16.1.x addresses behind it. > My endpoint is running 4.2-BETA and has an ISP provided /30 > subnet externally, with my publicly routable Class C behind. > > I note that when I try to reach any 172.16.1 address > with either form of IPSEC configured I get 'No route to host' > errors. This suggests that IPSEC is not encapsulating anything. > You know I have had the same problems. I haven't quite figured out the tunnelling part of IPSEC yet. So what I did, as a work around, was to add a tunnel interface (gif) and then add IPSEC on top of that in transparent mode (tunnel mode still works). See below. > I would appreciate hearing from anyone who has set up esp > style tunnels between either 2 FreeBSDs or between FreeBSD and > anything else. I used gif interfaces to build a packet tunnel (IPv4 -> IPv4). I then added the appropriate routes for each network, so I could affectively ping across the tunnels. Tested the connection between the 2 using ssh. Everything fine at this point. I then proceeded to add the IPSEC options in the kernel, like you have above. Added the SAD entries with setkey. Added the SPD policies with setkey also. Verified connectivity. Ran a packet sniffer between the 2 networks, seen packet type ESP. Everything worked OK. It did add about 2->4 ms of latency to a 10BaseT connection but that seems logical. > We are both running ipfilt on our ends. > The remote site is also running simple ipnat configuration. I have not added NAT into the equation yet. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 13:52:54 2000 Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (unknown [64.108.240.16]) by hub.freebsd.org (Postfix) with SMTP id 8869B37B4CF for ; Wed, 15 Nov 2000 13:52:51 -0800 (PST) Received: (qmail 95058 invoked by uid 1001); 15 Nov 2000 21:52:53 -0000 Date: Wed, 15 Nov 2000 16:52:53 -0500 (EST) From: Vince Vielhaber To: Subject: PPPoE, nat, dsl, some web sites 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 have a DSL connection that I'm connecting to via PPPoE. This is working. I have a 4.1.1 machine dedicated to it, with two network cards (dc0 and dc1) - one going to the dsl modem and one to a hub. Using lynx I can get to just about every site I've tried, but if I go to another 4.1.1 machine there are some sites that I can't get to. It just sits and hangs. Even if I telnet to port 80 and type GET / HTTP/1.0 it will just hang (yes I have the protocol right, it works from the machine being used as a router). Looking thru the archives it appears the only solutions are to use a proxy server like squid, but I'd rather avoid something messy like that if I can. Could I be running into the MTU problem I've seen described for the windoze boxes? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 13:59:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 3A97437B479 for ; Wed, 15 Nov 2000 13:59:21 -0800 (PST) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 957583A3CB; Wed, 15 Nov 2000 13:59:20 -0800 (PST) Message-ID: <004b01c04f4f$4ebe9f20$0402010a@biohz.net> From: "Renaud Waldura" To: "Vince Vielhaber" Cc: References: Subject: Re: PPPoE, nat, dsl, some web sites Date: Wed, 15 Nov 2000 13:59:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sounds like the infamous PMTU problem. Read this, section 6.3 especially: http://renaud.waldura.com/doc/freebsd-pppoe/ NB: there is an issue with the tcpmssd.rc script presented there. In the meanwhile, start tcpmssd either by hand or from /usr/local/etc/rc.d . --Renaud ----- Original Message ----- From: Vince Vielhaber To: Sent: Wednesday, November 15, 2000 1:52 PM Subject: PPPoE, nat, dsl, some web sites > > I have a DSL connection that I'm connecting to via PPPoE. This is > working. I have a 4.1.1 machine dedicated to it, with two network > cards (dc0 and dc1) - one going to the dsl modem and one to a hub. > Using lynx I can get to just about every site I've tried, but if I > go to another 4.1.1 machine there are some sites that I can't get > to. It just sits and hangs. Even if I telnet to port 80 and type > GET / HTTP/1.0 it will just hang (yes I have the protocol right, it > works from the machine being used as a router). Looking thru the > archives it appears the only solutions are to use a proxy server like > squid, but I'd rather avoid something messy like that if I can. Could > I be running into the MTU problem I've seen described for the windoze > boxes? > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 15:28: 9 2000 Delivered-To: freebsd-net@freebsd.org Received: from paprika.michvhf.com (unknown [64.108.246.248]) by hub.freebsd.org (Postfix) with SMTP id 4B0A637B479 for ; Wed, 15 Nov 2000 15:28:05 -0800 (PST) Received: (qmail 95413 invoked by uid 1001); 15 Nov 2000 23:28:07 -0000 Date: Wed, 15 Nov 2000 18:28:07 -0500 (EST) From: Vince Vielhaber To: Renaud Waldura Cc: Subject: Re: PPPoE, nat, dsl, some web sites In-Reply-To: <004b01c04f4f$4ebe9f20$0402010a@biohz.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 15 Nov 2000, Renaud Waldura wrote: > Sounds like the infamous PMTU problem. Read this, section 6.3 especially: > http://renaud.waldura.com/doc/freebsd-pppoe/ > > NB: there is an issue with the tcpmssd.rc script presented there. In the > meanwhile, start tcpmssd either by hand or from /usr/local/etc/rc.d . That was it! Thanks!!! Vince. > > --Renaud > > > > ----- Original Message ----- > From: Vince Vielhaber > To: > Sent: Wednesday, November 15, 2000 1:52 PM > Subject: PPPoE, nat, dsl, some web sites > > > > > > I have a DSL connection that I'm connecting to via PPPoE. This is > > working. I have a 4.1.1 machine dedicated to it, with two network > > cards (dc0 and dc1) - one going to the dsl modem and one to a hub. > > Using lynx I can get to just about every site I've tried, but if I > > go to another 4.1.1 machine there are some sites that I can't get > > to. It just sits and hangs. Even if I telnet to port 80 and type > > GET / HTTP/1.0 it will just hang (yes I have the protocol right, it > > works from the machine being used as a router). Looking thru the > > archives it appears the only solutions are to use a proxy server like > > squid, but I'd rather avoid something messy like that if I can. Could > > I be running into the MTU problem I've seen described for the windoze > > boxes? > > > > Vince. > > -- > > ========================================================================== > > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > > 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking > > Online Campground Directory http://www.camping-usa.com > > Online Giftshop Superstore http://www.cloudninegifts.com > > ========================================================================== > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 17:33:46 2000 Delivered-To: freebsd-net@freebsd.org Received: from outblaze12.outblaze.com (outblaze12.outblaze.com [209.249.164.196]) by hub.freebsd.org (Postfix) with SMTP id EC27437B4D7 for ; Wed, 15 Nov 2000 17:33:43 -0800 (PST) Received: (qmail 10117 invoked by uid 1001); 16 Nov 2000 01:33:43 -0000 Message-ID: <20001116013343.10116.qmail@bsdmail.org> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Tan Wei Chong" To: freebsd-net@FreeBSD.org Date: Thu, 16 Nov 2000 09:33:43 +0800 Subject: tcpdump newbie Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, can anybody help me to clarify which host/port/interface i should capture if i were to do performance compare between a tunnel 6to4/4to6 (IPv6 tunnel into IPv4 and IPv4 tunnel into IPv6) HTTP/1.1 traffic. Should I issue: tcpdump -i fxp0 tcpdump -i gif0 (i use gifconfig for the tunneling) tcpdump host and tcpdump host and tcpdump src port ??? because so far all the tunnel communication that I try to capture seems to yield empty packets when analyze using tcptrace, however pure IPv6 to IPv6 or IPv4 to IPv4 communication does give result. Note: the 2 host is link-local and isolated from any other computer Thank you. Wei Chong -- Get your free email from http://www.bsdmail.org

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 15 19:24:50 2000 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 98A6F37B4C5 for ; Wed, 15 Nov 2000 19:24:47 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id TAA22128; Wed, 15 Nov 2000 19:24:44 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id eAG3Ohi47268; Wed, 15 Nov 2000 19:24:43 -0800 (PST) (envelope-from jdp) Date: Wed, 15 Nov 2000 19:24:43 -0800 (PST) Message-Id: <200011160324.eAG3Ohi47268@vashon.polstra.com> To: net@freebsd.org From: John Polstra Reply-To: net@freebsd.org Cc: louie@TransSys.COM Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: <200011152043.eAFKhMG68318@whizzo.transsys.com> References: <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> <200011152043.eAFKhMG68318@whizzo.transsys.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <200011152043.eAFKhMG68318@whizzo.transsys.com>, Louis A. Mamakos wrote: > > > You mentioned the books... Can you citate from one of these books that > > states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 > > rather than 0xFFFF? > > The correct result is 0x0001, since 0xffff is -0, and -0 + 1 == 1. > 0xFFFE + 0x0001 == 0, because 0xFFFE is -1 and -1 + 1 == 0. Louie is correct. (And in case there's any doubt, my HP 16c confirms it in 16-bit 1's complement mode.) To add two numbers in 1's complement you do this: 1. Perform a normal 2's complement add, and keep track of whether there was a carry out of the high-order bit. 2. If there was a carry, increment (2's complement) the result. In other words: u_int16_t add1(u_int16_t a, u_int16_t b) { u_int32_t sum; sum = (u_int32_t)a + (u_int32_t)b; /* Carry goes to bit 16 */ sum += sum >> 16; /* Add in the carry */ return (u_int16_t)sum; } They used to call this "wrap-around carry". John Polstra, CDC-1604 survivor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 1: 1:18 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E0D6837B479; Thu, 16 Nov 2000 01:01:04 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAG90To41677; Thu, 16 Nov 2000 11:00:29 +0200 (EET) (envelope-from ru) Date: Thu, 16 Nov 2000 11:00:29 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari , jdp@FreeBSD.ORG Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001116110029.A38288@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari , jdp@FreeBSD.org References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> <200011152043.eAFKhMG68318@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011152043.eAFKhMG68318@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 03:43:22PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 03:43:22PM -0500, Louis A. Mamakos wrote: > > > If the above would be true that would mean that almost all implementations > > of computing the checksum are wrong, i.e. they produce the value of 0x0000 > > as a checksum when it should actually be 0xffff. That would also mean all > > three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! > > But the thing is, both 0xffff and 0x0000 are the same value == 0. (One is > negative zero, other other a positive zero.) I think the authors make > an error when they conclude that the result of an addition can only be > a negative zero rather than a positive zero, but in the end it doesn't > really matter which representation of zero you use, because they are > arithmetically equal. > > I think the authors of those RFCs probably had 2's complement CPUs in > mind, and were thinking about commonly used emulations of 1's complement > arithemetic operations. > > > My understanding of the one's complement sum is as follows: > > > > This is the sum (or an algorithm to compute such a sum), which produces > > the RIGHT results for items represented in one's complement form, the form > > in which negative numbers are represented by one's complements of a > > positive number. > > > > You mentioned the books... Can you citate from one of these books that > > states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 > > rather than 0xFFFF? > > The correct result is 0x0001, since 0xffff is -0, and -0 + 1 == 1. > 0xFFFE + 0x0001 == 0, because 0xFFFE is -1 and -1 + 1 == 0. > Damn, of course I meant the (0xFFFE +' 0x0001) above. You said this will produce the value of 0x0000, while I think it should be 0xFFFF. Read this carefully, word by word: RFC768> If the computed checksum is zero, it is transmitted as all ones RFC768> (the equivalent in one's complement arithmetic). An all zero RFC768> transmitted checksum value means that the transmitter generated RFC768> no checksum. "If the computed checksum is zero" above means that CHECKSUM can be 0x0000, i.e. the one's complement SUM could have a value of 0xFFFF. And if this is the case, the CHECKSUM IS TRANSMITTED as all ones. This also means that the one's complement SUM (for IP purposes) can not have a value of 0x0000, because if there was such a case, then computed checksum value would be all ones by itself, and the UDP receiver would not be able to distinguish this "normal" case from the "no checksum" case above. So, to make a conclusion: 1. The ONE'S COMPLEMENT SUM CAN NEVER HAVE A VALUE OF ALL ZEROES, unless all words are zeroes, which is not the case for IP family protocols, because at least Protocol field is guaranteed to be non-zero, and is participating in all known checksums (e.g. IP, UDP, TCP, ICMP). Hereby, the CHECKSUM value, which is the one's complement of the sum, CAN NEVER HAVE A VALUE OF ALL ONES. 2. UDP uses all zero value in the checksum field to indicate that no checksum have been computed. For this to work, it does the following substituion. If the computed checksum is all zeroes (the could happen only if the one's complement sum is all ones), it is transmitted as all ones. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 2: 9:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E273837B479; Thu, 16 Nov 2000 02:09:40 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAGA9bU47477; Thu, 16 Nov 2000 12:09:37 +0200 (EET) (envelope-from ru) Date: Thu, 16 Nov 2000 12:09:36 +0200 From: Ruslan Ermilov To: Jonathan Lemon Cc: net@FreeBSD.org Subject: Delayed checksums commit broke UDP checksum calculation Message-ID: <20001116120936.A45755@sunbay.com> Mail-Followup-To: Jonathan Lemon , net@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! RFC768> If the computed checksum is zero, it is transmitted as all ones RFC768> (the equivalent in one's complement arithmetic). An all zero RFC768> transmitted checksum value means that the transmitter generated RFC768> no checksum. This (0x0000 -> 0xFFFF) apparently got broken in udp_usrreq.c,v 1.65. --- udp_usrreq.c 1999/12/22 19:13:24 1.64 +++ udp_usrreq.c 2000/03/27 19:14:23 1.65 @@ -688,11 +700,14 @@ udp_output(inp, m, addr, control, p) ui->ui_dport = inp->inp_fport; - ui->ui_ulen = ui->ui_len; + ui->ui_ulen = htons((u_short)len + sizeof(struct udphdr)); /* - * Stuff checksum and output datagram. + * Set up checksum and output datagram. */ - ui->ui_sum = 0; if (udpcksum) { - if ((ui->ui_sum = in_cksum(m, sizeof (struct udpiphdr) + len)) == 0) - ui->ui_sum = 0xffff; + ui->ui_sum = in_pseudo(ui->ui_src.s_addr, ui->ui_dst.s_addr, + htons((u_short)len + sizeof(struct udphdr) + IPPROTO_UDP)); + m->m_pkthdr.csum_flags = CSUM_UDP; + m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum); + } else { + ui->ui_sum = 0; } The attached patch should fix this. Comments? -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.116 diff -u -p -r1.116 ip_output.c --- ip_output.c 2000/11/01 01:59:28 1.116 +++ ip_output.c 2000/11/16 10:05:06 @@ -974,6 +974,8 @@ in_delayed_cksum(struct mbuf *m) ip = mtod(m, struct ip *); offset = IP_VHL_HL(ip->ip_vhl) << 2 ; csum = in_cksum_skip(m, ip->ip_len, offset); + if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) + csum = 0xffff; /* per RFC768 */ offset += m->m_pkthdr.csum_data; /* checksum offset */ if (offset + sizeof(u_short) > m->m_len) { --mP3DRpeJDSE+ciuQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 3:58:24 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id D743B37B479 for ; Thu, 16 Nov 2000 03:58:19 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.0/8.11.0) with SMTP id eAGBvp285455; Thu, 16 Nov 2000 06:57:51 -0500 (EST) From: Mike Tancsa To: hamilton@twopoint.com (Hamilton Hoover) Cc: freebsd-net@freebsd.org Subject: Re: ipsec vpn on firewall Date: Thu, 16 Nov 2000 06:57:50 -0500 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15 Nov 2000 12:24:21 -0500, in sentex.lists.freebsd.net you wrote: >I have been given the task of setting up a vpn using ipsec on our >firewall. I am somewhat new to FreeBsd and am not sure of how to go >about this. We are trying to let home dsl users connect securely to our >corporate lan and browse through 'network neighborhood'. Home users are >using win9x with PGP Personal Firewall and the Office runs FreeBsd 4.1. >The Firewall is nated. All incoming requests are blocked so I also don't >know what holes if any to poke in the firewall. I included the >FreeBsd ipsec package when I installed the system but after looking at >the man pages I don't get it. I have looked for a howto as well as a >tutorial and haven't found anything on setting up the vpn. If anyone >know of an idiot proof howto or some good resources please let me know. >If more info is needed I will do my best to supply it. You will need to let protocol 50 and 51 through your firewall which is = the IP sec stuff. Here is a simple configuration that works for FreeBSD to =46reeBSD one of which using DSL. If you suspect the firewall, try = allowing a single test machine through first and then gradually add back the rules to see where it breaks. e.g ipfw add 12 allow log all from cust.test.machine.ip to any ------------- Setup is a FreeBSD box running PPPoE over DSL across a few hops to = another=20 =46reeBSD machine on the ethernet. The trick is to bump up the lifetime=20 value in racoon.conf and to make sure you have a recent version of = racoon.=20 I used the one from November 11th. Here is a quick sample config for two machines PPPoE machine's _public_ address on tun0 : 169.1.134.1 PPPoE machine's _private_ address aliased on lo0 : 10.1.2.1 Office Server's _public_ address on fxp0 172.168.93.4 Office Server's _private_ address aliased on lo0 : 10.1.1.1 *Note, if your machine has 2 interfaces, you can of course use the = RFC1918=20 space on it instead. This example assumes you just have the one NIC to play with. #!/bin/sh #PPPoE config ifconfig lo0 10.1.2.1 netmask 255.255.255.0 alias gifconfig gif0 169.1.134.1 172.168.93.4 ifconfig gif0 inet 10.1.2.1 10.1.1.1 netmask 255.255.255.0 setkey -FP setkey -F setkey -c < X-Mailer: exmh version 2.1.1 10/15/1999 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox/freebsd To: Ruslan Ermilov Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari , jdp@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: libalias: Incremental Update of Internet Checksum References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> <20001115180842.A11913@sunbay.com> <200011152043.eAFKhMG68318@whizzo.transsys.com> <20001116110029.A38288@sunbay.com> In-reply-to: Your message of "Thu, 16 Nov 2000 11:00:29 +0200." <20001116110029.A38288@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 16 Nov 2000 09:47:53 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Read this carefully, word by word: > > RFC768> If the computed checksum is zero, it is transmitted as all ones > RFC768> (the equivalent in one's complement arithmetic). An all zero > RFC768> transmitted checksum value means that the transmitter generated > RFC768> no checksum. > > "If the computed checksum is zero" above means that CHECKSUM can be 0x0000, > i.e. the one's complement SUM could have a value of 0xFFFF. And if this > is the case, the CHECKSUM IS TRANSMITTED as all ones. > > This also means that the one's complement SUM (for IP purposes) can not > have a value of 0x0000, because if there was such a case, then computed > checksum value would be all ones by itself, and the UDP receiver would > not be able to distinguish this "normal" case from the "no checksum" > case above. > > So, to make a conclusion: > > 1. The ONE'S COMPLEMENT SUM CAN NEVER HAVE A VALUE OF ALL ZEROES, unless > all words are zeroes, which is not the case for IP family protocols, > because at least Protocol field is guaranteed to be non-zero, and is > participating in all known checksums (e.g. IP, UDP, TCP, ICMP). > Hereby, the CHECKSUM value, which is the one's complement of the sum, > CAN NEVER HAVE A VALUE OF ALL ONES. I disagree. You are arguing that the only possible implementation that YOU can think of, which is a particular imperfect emulation of 1's complement arithemtic operations on 2's complement hardware will never produce a zero result after summing a bunch of values. I am arguing that if you have a physical implementation of a 1's complement ALU in your CPU (because you machine architecture is 1's complement) that you will never produce an all 1's result from a simple arithmetic ADD operation on quantities of data. On the particular CPU hardware architecure I have written an IP stack from scratch on, I know this to be ABSOLUTELY TRUE. It has been the case for UNIVAC/Sperry/Unisys 1100/2200 series architectures for more than 30 years. And if you think about it a while, it's important that one's compelement architecture systems produce normalized results (e.g., no negative zero results) so that bitwise tests against +0 are only necessary in code, rather than having to test for both possible result values. The statement you quoted above describes a particular circumstance which may happen as a result of a particular implementation approach, not the only result that could ever possibly appear. For instance, even given a 1's complement CPU ALU, if the arithmetic sum operation is done on e.g., 16 bit quantities on a machine with a native word size of e.g., 36 bits, then the low-order 16 bit sum might appear to be 0xffff, but that's because of the word-size mismatch. (A clever implementation would OR a mask of all 1 bits in the high-order part of the word to automatically "fix" this situation). > 2. UDP uses all zero value in the checksum field to indicate that no > checksum have been computed. For this to work, it does the following > substituion. If the computed checksum is all zeroes (the could happen > only if the one's complement sum is all ones), it is transmitted as > all ones. I would mostly agree. I think the other problem I have is that you're embedding particular architectural assumptions in what is likely machine-architecture independent code. There's a reash in_chksum() is in the machine specific part of the kernel source tree, and performance optimization is only part of it. In the mid 80's, I was on a project which mostly ported the BSD IP stack to the UNIVAC 1100 series machines (1100/90 at the time) when a C compiler appeared. Remarkably, the BSD network stack moved over pretty easily because the architecture specific assumptions were mostly hidden away. There was one particular problem, in fact in netinet/udp_usrreq.c where the UDP checksum field was set to -1 rather than ~0 that I had Mike Karels fix (go look at the ancient SCCS logs..) We never fielded the BSD-based code in production because the machine went away. While it's very unlikely that that 1's complement CPU architectures will become wildly popular again, it's not impossible that the Pentium-13 or some other CPU might add 1's complement ALU capability or acceleration to speed up Internet checksum computation operations. If that's the case, we'll be happy if we've isolated botht he code and the assumptions on how one of two "equivilent" results are computed in well defined places. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 7:20: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id EE5A337B479; Thu, 16 Nov 2000 07:19:56 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eAGFJs762592; Thu, 16 Nov 2000 09:19:54 -0600 (CST) (envelope-from jlemon) Date: Thu, 16 Nov 2000 09:19:54 -0600 From: Jonathan Lemon To: Jonathan Lemon , net@FreeBSD.org Subject: Re: Delayed checksums commit broke UDP checksum calculation Message-ID: <20001116091954.A19895@prism.flugsvamp.com> References: <20001116120936.A45755@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001116120936.A45755@sunbay.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 16, 2000 at 12:09:36PM +0200, Ruslan Ermilov wrote: > Hi! > > RFC768> If the computed checksum is zero, it is transmitted as all ones > RFC768> (the equivalent in one's complement arithmetic). An all zero > RFC768> transmitted checksum value means that the transmitter generated > RFC768> no checksum. > > This (0x0000 -> 0xFFFF) apparently got broken in udp_usrreq.c,v 1.65. Actually, it got broken in a different fashion; I had originally moved the above logic within in_cksum itself, and when that got taken out, the UDP case wasn't updated. > Index: ip_output.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.116 > diff -u -p -r1.116 ip_output.c > --- ip_output.c 2000/11/01 01:59:28 1.116 > +++ ip_output.c 2000/11/16 10:05:06 > @@ -974,6 +974,8 @@ in_delayed_cksum(struct mbuf *m) > ip = mtod(m, struct ip *); > offset = IP_VHL_HL(ip->ip_vhl) << 2 ; > csum = in_cksum_skip(m, ip->ip_len, offset); > + if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) > + csum = 0xffff; /* per RFC768 */ > offset += m->m_pkthdr.csum_data; /* checksum offset */ > > if (offset + sizeof(u_short) > m->m_len) { This would work. Alternatively, you could change it to: if (csum == 0) csum = 0xffff; So that the same logic applies to TCP packets as well. Currently, we can send a TCP packet with a checksum of 0, which is legal. Of possible interest is that Linux doesn't do this; they alwyas send a non-zero checksum in the TCP case, if a checksum was computed. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 10:57:22 2000 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 6F00837B4CF for ; Thu, 16 Nov 2000 10:57:19 -0800 (PST) Received: from fokus.gmd.de (thatrel [193.175.132.249]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id TAA21752 for ; Thu, 16 Nov 2000 19:57:17 +0100 (MET) Message-ID: <3A142E0C.1B1D18DD@fokus.gmd.de> Date: Thu, 16 Nov 2000 19:57:16 +0100 From: Falco Krepel Organization: GMD FOKUS - CATS Group X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en, de-DE MIME-Version: 1.0 To: "freebsd-net@FreeBSD.ORG" Subject: New Protocol over Ethernet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I want to implement my own protocol on top of ethernet. This protocol should should not influence other protocols running on the system. So I must distinguish my own frames from other frames. Because this is my first time to implement such a protocol on FreeBSD I am not sure how I can do this. I have read some documentation about interprocess communication within FreeBSD, the TCP/IP illustrated book, ... Furthermore I study the BSD source code around network communication. But until now it is not clarify how I can do this in the best way. If I understood it right, three approaches exists: 1. I creat with netgraph a hook over ther ethernet interface. With this solution I am not shure how much overhead this adds because it could be possible that this runs into timing problems. 2. I attach direct to the ethernet interface. This means I must add a new protocol class to get only my own frames. Is that right? 3. I use the DL interface with a socket. About the DL interface I haven't found any information how I can use this interface. Now my questions: - Are the three ways correct or I did misunderstand something? - Does exist an implementation which could help me to find the solution? - Has anybody experience with such an implementation? I hope somebody can help me. I am also happy about some hints about good literature helping me to solve this problem. Thanx in advanced Falco -- Falco Krepel Phone: +49-(0)30 - 34 63 - 7 276 GMD-FOKUS Fax: +49-(0)30 - 34 63 - 8 276 Kaiserin-Augusta-Allee 31 e-mail: krepel@fokus.gmd.de 10589 Berlin WWW: http://www.fokus.gmd.de/usr/krepel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 15:39:48 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 7920D37B4C5 for ; Thu, 16 Nov 2000 15:39:45 -0800 (PST) Received: from dakar-18.budapest.interware.hu ([195.70.51.82] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13wYd4-0003fN-00; Fri, 17 Nov 2000 00:39:42 +0100 Message-ID: <3A14701F.4CF92AFB@elischer.org> Date: Thu, 16 Nov 2000 15:39:11 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Falco Krepel Cc: "freebsd-net@FreeBSD.ORG" Subject: Re: New Protocol over Ethernet References: <3A142E0C.1B1D18DD@fokus.gmd.de> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Falco Krepel wrote: > > Hi, > > I want to implement my own protocol on top of ethernet. This protocol > should should not influence other protocols running on the system. So I > must distinguish my own frames from other frames. > > Because this is my first time to implement such a protocol on FreeBSD I > am not sure how I can do this. I have read some documentation about > interprocess communication within FreeBSD, the TCP/IP illustrated book, > ... Furthermore I study the BSD source code around network > communication. But until now it is not clarify how I can do this in the > best way. > > If I understood it right, three approaches exists: > > 1. I creat with netgraph a hook over ther ethernet interface. With this > solution I am not shure how much overhead this adds because it could be > possible that this runs into timing problems. > There will be no more timing load that any other scheme you can think of. Netgraph is very efficient. it would help a bit if you gave more specific information as to the characterisitics of the protocol you want. > 2. I attach direct to the ethernet interface. This means I must add a > new protocol class to get only my own frames. Is that right? Basically you will need to alter the ethernet driver framework. I did this several times and it is why I wrote netgraph. Netgraph can already deliver the packets to you.. > > 3. I use the DL interface with a socket. About the DL interface I > haven't found any information how I can use this interface. > > Now my questions: > > - Are the three ways correct or I did misunderstand something? > - Does exist an implementation which could help me to find the solution? > - Has anybody experience with such an implementation? > many people have done this.. > I hope somebody can help me. I am also happy about some hints about good > literature helping me to solve this problem. > > Thanx in advanced > > Falco > > -- > Falco Krepel Phone: +49-(0)30 - 34 63 - 7 276 > GMD-FOKUS Fax: +49-(0)30 - 34 63 - 8 276 > Kaiserin-Augusta-Allee 31 e-mail: krepel@fokus.gmd.de > 10589 Berlin WWW: http://www.fokus.gmd.de/usr/krepel > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ 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 Thu Nov 16 20:35:42 2000 Delivered-To: freebsd-net@freebsd.org Received: from worldclass.jolt.nu (lgh637b.hn-krukan.AC [212.217.139.112]) by hub.freebsd.org (Postfix) with ESMTP id 475C537B479; Thu, 16 Nov 2000 20:35:37 -0800 (PST) Received: from localhost (c4@localhost) by worldclass.jolt.nu (8.9.3/8.9.3) with ESMTP id FAA43700; Fri, 17 Nov 2000 05:34:27 +0100 (CET) (envelope-from c4@worldclass.jolt.nu) Date: Fri, 17 Nov 2000 05:34:26 +0100 (CET) From: Tobias Fredriksson To: freebsd-net@freebsd.org Cc: freebsd-hardware@freebsd.org Subject: Multiple interfaces on same subnet Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am about to setup a system with 2 diffrent networks and multiple interfaces on atleast one of the isp connections. System specs are at the bottom. Now to my questions. The server will most probably be utilizing 2 Intel PRO/100+ Dual Port Server Adapter all ports being used the system must be able to send 800mbit and recieve 800mbit at a maximum, estimated average is around 200mbit/s, over these two cards alone. These two card will server an "internal" network in our city so input/output rates are very important over these two. The other network adapter which will cover country wide will be an Intel PRO/1000 E Server Adapter, data from all over the country will be sent through this one card and the maximum throughput will ever be 100mbit/s so this shall be more than enough. Will the Intel PRO/100+ Dual Port Server Adapters meet our demands? How do i best configure the system for load-balancing over these two cards? When having multiple interfaces on the same subnet, i have noticed alot of kernel messages like "xxx.xxx.xxx.xxx is on fxp0". How do i prevent this from happening since this will most probably slow down the server with lots of writes to the logs files and consequently the drives ;) System specs: AMD K7 Thunderbird 800mhz+ 512MB PC133 SDRAM or 768MB PC100 SDRAM Adaptec SCSI Card 39160 (Dual Channel Ultra160 SCSI card supporting 30 devices), is this card supported by FreeBSD 4.1.1-STABLE? Atleast 4 or 5 Seagate SCSI 68 pin 73400MB Ultra160 (16MB Cache), has anybody used these and can they give me any good reasons why I should use/or not use these. If i shall not use these i will most probably go with 8 or 10 IBM SCSI 68 pin 36700MB Ultra-160 36LZX 2 Intel PRO/100+ Dual Port Server Adapter Intel PRO/1000 E Server Adapter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 20:49:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.15]) by hub.freebsd.org (Postfix) with ESMTP id B8A6637B479; Thu, 16 Nov 2000 20:49:05 -0800 (PST) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id LAA15625; Fri, 17 Nov 2000 11:48:53 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id LAA13563; Fri, 17 Nov 2000 11:48:51 +0700 (ICT) Date: Fri, 17 Nov 2000 11:48:51 +0700 (ICT) Message-Id: <200011170448.LAA13563@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: c4@worldclass.jolt.nu Cc: freebsd-net@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG In-reply-to: (message from Tobias Fredriksson on Fri, 17 Nov 2000 05:34:26 +0100 (CET)) Subject: Re: Multiple interfaces on same subnet References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tobias, Having 2 dual ethernet cards, how can you reach 800mbps? 2*2*100=400 in each direction, I suppose I beleive the server should handle traffic from the 2 internal subnets as well as some traffic from outside? It should be a very light server to be able to deliver data at the rate you mentionned. I like freebsd, but I am not sure it can handle the load. As for security reasons, spliting the servers could be a good solution too. Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 21:14:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 9C96937B479; Thu, 16 Nov 2000 21:14:31 -0800 (PST) Received: by peorth.iteration.net (Postfix, from userid 1001) id 989B657311; Thu, 16 Nov 2000 23:14:44 -0600 (CST) Date: Thu, 16 Nov 2000 23:14:44 -0600 From: "Michael C . Wu" To: Tobias Fredriksson Cc: freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Multiple interfaces on same subnet Message-ID: <20001116231444.C76289@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Tobias Fredriksson , freebsd-net@freebsd.org, freebsd-hardware@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from c4@worldclass.jolt.nu on Fri, Nov 17, 2000 at 05:34:26AM +0100 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 17, 2000 at 05:34:26AM +0100, Tobias Fredriksson scribbled: | I am about to setup a system with 2 diffrent networks and multiple | interfaces | on atleast one of the isp connections. | | System specs are at the bottom. Since it is obvious that you are not limited by a signicant budget cap, Have you considered a gigabit network on a 64bit PCI bus? Also, try buying a real hardware load balancer/router, they work much better and you can drop your internal systems' specs down to a more affordable level. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 16 21:23:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by hub.freebsd.org (Postfix) with ESMTP id 20B0837B479 for ; Thu, 16 Nov 2000 21:23:40 -0800 (PST) Received: from localhost (IDENT:mshindo@016.cosine.nttpc.gr.jp [202.229.42.16] (may be forged)) by center.mshindo.net (8.9.3/3.7W/00041811) with ESMTP id OAA78198; Fri, 17 Nov 2000 14:40:01 +0900 (JST) Date: Fri, 17 Nov 2000 14:24:16 +0900 (JST) Message-Id: <20001117.142416.63134192.mshindo@mshindo.net> To: julian@elischer.org Cc: freebsd-net@freebsd.org, KuriyaKK@cpf.navy.mil, josb@cncdsl.com Subject: Re: Question regarding 'pptpclient' From: Motonori Shindo In-Reply-To: <3A129677.EAA6836E@elischer.org> References: <20001019.182543.74756319.mshindo@mshindo.net> <20001115.224551.59462131.mshindo@mshindo.net> <3A129677.EAA6836E@elischer.org> X-Mailer: Mew version 1.95b76 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 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, Sorry for my ignorance, but can mpd act as a PAC? I had an impression that mpd can work as a PNS but not as a PAC first time I looked at mpd. Regards, From: Julian Elischer Subject: Re: Question regarding 'pptpclient' Date: Wed, 15 Nov 2000 05:58:15 -0800 Message-ID: <3A129677.EAA6836E@elischer.org> > Motonori Shindo wrote: > > > > Some folks asked me how I made pptp-linux-1.0.2 to work under FreeBSD, > > so here it goes. (sorry this response is so delayed. I had so many > > other things to do these days...) > > > > I just used the mpd-netgraph port, which does it all in the kernel. > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 17 9:55:58 2000 Delivered-To: freebsd-net@freebsd.org Received: from web113.yahoomail.com (web113.mail.yahoo.com [205.180.60.84]) by hub.freebsd.org (Postfix) with SMTP id 129FB37B479 for ; Fri, 17 Nov 2000 09:55:57 -0800 (PST) Received: (qmail 25185 invoked by uid 60001); 17 Nov 2000 17:55:56 -0000 Message-ID: <20001117175556.25184.qmail@web113.yahoomail.com> Received: from [209.88.252.106] by web113.yahoomail.com; Fri, 17 Nov 2000 09:55:56 PST Date: Fri, 17 Nov 2000 09:55:56 -0800 (PST) From: Fabio Miranda Subject: upgrade kernel using especific vendor driver To: freebsd-net@freebsd.org 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 am using a etinc et5025-16 board that recives a 19,2 hdlc internet line on freebsd 3x-release, and we would like to upgrade using cvs, but, we dont know how upgrade process deal with the board loaded modules in kernel, i mean, the board came with kind of "drivers" and there is some .o files involved, so, how can i upgrade the kernel saving the board funcionality? also, each driver is designed for a especific kernel version (example, et5025-fbsd-4.1...etc)so, how is the whole upgrade? thanks alot for your comments, recently i read "adventure: upgrading freebsd" in daemonnews.com and it's pretty usefull.. a big hug to freebsd users worldwide. __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 17 17:39:14 2000 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 34C1537B479 for ; Fri, 17 Nov 2000 17:39:12 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13wwzp-0000Sy-00; Fri, 17 Nov 2000 18:40:49 -0700 Message-ID: <3A15DE21.3E33067A@softweyr.com> Date: Fri, 17 Nov 2000 18:40:49 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Falco Krepel Cc: "freebsd-net@FreeBSD.ORG" Subject: Re: New Protocol over Ethernet References: <3A142E0C.1B1D18DD@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Falco Krepel wrote: > > Hi, > > I want to implement my own protocol on top of ethernet. This protocol > should should not influence other protocols running on the system. So I > must distinguish my own frames from other frames. > > Because this is my first time to implement such a protocol on FreeBSD I > am not sure how I can do this. I have read some documentation about > interprocess communication within FreeBSD, the TCP/IP illustrated book, > ... Furthermore I study the BSD source code around network > communication. But until now it is not clarify how I can do this in the > best way. > > [...] > > 2. I attach direct to the ethernet interface. This means I must add a > new protocol class to get only my own frames. Is that right? Yes, and this would be the "best" way to do this. Preferrably, you would add the middle layer interfaces, using the network interface drivers on the bottom and the socket layer on the top; your protocol would be analagous to IPv4 and IPv6. /usr/src/sys/net* are examples of existing protocols. inet and inet6 are the most developed, of course. -- "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 Fri Nov 17 17:40:12 2000 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id B36D137B4C5 for ; Fri, 17 Nov 2000 17:40:10 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA33304; Fri, 17 Nov 2000 17:40:10 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.0/8.11.0) id eAI1e9T38050; Fri, 17 Nov 2000 17:40:09 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200011180140.eAI1e9T38050@curve.dellroad.org> Subject: Re: New Protocol over Ethernet In-Reply-To: <3A15DE21.3E33067A@softweyr.com> "from Wes Peters at Nov 17, 2000 06:40:49 pm" To: Wes Peters Date: Fri, 17 Nov 2000 17:40:09 -0800 (PST) Cc: Falco Krepel , "freebsd-net@FreeBSD.ORG" X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > > I want to implement my own protocol on top of ethernet. This protocol > > should should not influence other protocols running on the system. So I > > must distinguish my own frames from other frames. > > > > Because this is my first time to implement such a protocol on FreeBSD I > > am not sure how I can do this. I have read some documentation about > > interprocess communication within FreeBSD, the TCP/IP illustrated book, > > ... Furthermore I study the BSD source code around network > > communication. But until now it is not clarify how I can do this in the > > best way. > > > > [...] > > > > 2. I attach direct to the ethernet interface. This means I must add a > > new protocol class to get only my own frames. Is that right? > > Yes, and this would be the "best" way to do this. Preferrably, you > would add the middle layer interfaces, using the network interface > drivers on the bottom and the socket layer on the top; your protocol > would be analagous to IPv4 and IPv6. > > /usr/src/sys/net* are examples of existing protocols. inet and inet6 are > the most developed, of course. Or prototype it all in userland using ng_ether(4) and the "orphans" hook. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 18 0:50:39 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 266B937B479 for ; Sat, 18 Nov 2000 00:50:36 -0800 (PST) Received: from gaborone-56.budapest.interware.hu ([195.70.52.184] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13x3hg-0001w3-00; Sat, 18 Nov 2000 09:50:33 +0100 Message-ID: <3A1642B7.C2FD231F@elischer.org> Date: Sat, 18 Nov 2000 00:49:59 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: Falco Krepel , "freebsd-net@FreeBSD.ORG" Subject: Re: New Protocol over Ethernet References: <3A142E0C.1B1D18DD@fokus.gmd.de> <3A15DE21.3E33067A@softweyr.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters wrote: > > Falco Krepel wrote: > > > > Hi, > > > > I want to implement my own protocol on top of ethernet. This protocol > > should should not influence other protocols running on the system. So I > > must distinguish my own frames from other frames. > > > > Because this is my first time to implement such a protocol on FreeBSD I > > am not sure how I can do this. I have read some documentation about > > interprocess communication within FreeBSD, the TCP/IP illustrated book, > > ... Furthermore I study the BSD source code around network > > communication. But until now it is not clarify how I can do this in the > > best way. > > > > [...] > > > > 2. I attach direct to the ethernet interface. This means I must add a > > new protocol class to get only my own frames. Is that right? > > Yes, and this would be the "best" way to do this. Preferrably, you > would add the middle layer interfaces, using the network interface > drivers on the bottom and the socket layer on the top; your protocol > would be analagous to IPv4 and IPv6. this is not in my opinion the "best" way of doing this. If you do this you will need to keep patching every release of BSD as it comes out. If you use netgraph to get the packets you can make your protocol a module that can be compiled and loaded on any system without editing any code. > > /usr/src/sys/net* are examples of existing protocols. inet and inet6 are > the most developed, of course. > > -- > "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 -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message