From owner-freebsd-net Sun Jan 13 3: 1:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 87D3C37B417; Sun, 13 Jan 2002 03:01:06 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0DB14l08679; Sun, 13 Jan 2002 12:01:04 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0DAuas21303; Sun, 13 Jan 2002 11:56:36 +0100 (CET) (envelope-from andreas) Date: Sun, 13 Jan 2002 11:56:36 +0100 From: Andreas Klemm To: freebsd-net@FreeBSD.ORG Cc: mckusick@FreeBSD.ORG Subject: FIREWALL_FORWARD vs. using /sbin/natd ? Message-ID: <20020113105636.GA88221@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I found a document describing a firewall design only using natd for redirects to internal network resources. (Hi Marshall, therefore Cc: to you, since its yours and I have a question). http://www.rootprompt.net/freebsd_firewall.html Based on these informations I think I could get rid of natd entirely. See my previous mail, my problem was, that I can't get it to run for a typical 2 NIC configuration with internal network, DMZ and a router in front of a 512k leased line. Or is this my NAT problem, that additionally I have to use the kernel option FIREWALL_FORWARD, to get NAT for internal users running, 'though all other documents state out, that only IPFIREWALL and IPDIVERT are needed ??? Therefore the question, is using FIREWALL_FORWARD a good replacement for /sbin/natd if you want to give users of the internal network access to the outside world ? Are there some things to take care of, when using FIREWALL_FORWARD ? Does the logic for firewall rules change, or could I still use the templates in /etc/rc.firewall ??? Thanks for help. Thanks Andreas /// --=20 Andreas Klemm - Powered by FreeBSD Need a magic printfilter today ? http://www.apsfilter.org/ Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8QWfjd3o+lGxvbLoRAhNdAJ0YQeYEmC15RwLXbwkZBGGGWeS25gCcCcJQ xFz+3cKp+1gq4t9d9Tj6S3M= =RvRA -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 13 6:29:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id B44AE37B417 for ; Sun, 13 Jan 2002 06:29:09 -0800 (PST) Received: from user-uiveqtr.dsl.mindspring.com ([165.247.107.187] helo=compaq) by maynard.mail.mindspring.net with smtp (Exim 3.33 #1) id 16PldD-0004Df-00; Sun, 13 Jan 2002 09:29:07 -0500 Message-ID: <002a01c19ca2$f9457bc0$bb6bf7a5@compaq> From: "Naga R Narayanaswamy" To: "Kshitij Gunjikar" , References: Subject: Re: Performance of in_cksum.c Date: Sun, 13 Jan 2002 21:27:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you are referring to the sys/netinet/in_cksum.c file, it is a portable version. For specific architectures look at the following directories. 386 family version: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-stable/src/sys/i386/i386/in_cksum. c Alpha version: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-stable/src/sys/alpha/alpha/in_cksu m.c If you are looking at checksum functions for a wide variety of architectures like arm, powerpc,mips, hp etc, netbsd source code repository is a good source. Use the same directory structure as above to get those. ----- Original Message ----- From: "Kshitij Gunjikar" To: Sent: Saturday, January 12, 2002 6:59 AM Subject: Performance of in_cksum.c > Hi , > I have a question on the in_cksum.c file. Is it optimized to a particular > architecture ? If yes which architecture and what is the performance > accepted? > Regards > kshitij To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 13 9: 1:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by hub.freebsd.org (Postfix) with ESMTP id C05C237B402 for ; Sun, 13 Jan 2002 09:01:34 -0800 (PST) Received: from grand.canyon.xs4all.nl (canyon.xs4all.nl [194.109.195.185]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0DH1X3l018352 for ; Sun, 13 Jan 2002 18:01:33 +0100 (CET) Received: by grand.canyon.xs4all.nl (Postfix, from userid 1000) id E37955FA9; Sun, 13 Jan 2002 18:01:32 +0100 (CET) Received: from meander.tcja.nl (localhost [127.0.0.1]) by grand.canyon.xs4all.nl (Postfix) with ESMTP id AC4E05DB2 for ; Sun, 13 Jan 2002 18:01:32 +0100 (CET) Date: Sun, 13 Jan 2002 18:01:35 +0100 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Filtering packets received through an ipsec tunnel From: Rene de Vries To: net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <3386757E-0847-11D6-882A-00039357FA7A@canyon.xs4all.nl> X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, > This message was already posted to hackers@freebsd.org, but with > limited success. I'm hoping that someone on net@freebsd.org can give me > some more information. By experimenting with ipsec and looking at the source of "ip_input.c" a co-worker and I found the following out. When a ipsec tunnel packet is received this (protocol 50/51) packet is passed through ip-filter (& co). After filtering and when it has been determent that the current host is the destination (tunnel end-point), this packet is decrypted/verified. The decrypted packet is then pushed back into the queue that leads to ip_input(...). So far so good.... But once in ip_input(...) the filtering code is skipped and we were wondering why. I know that ipsec has some handles to be able to filter on address, protocol and/or port. But for more complex situations this is not enough. In these situations it would be nice to be able to use ip-filter (& co) on traffic from the tunnel (and also for traffic going into the tunnel). I was wondering why this is implemented the way it is. Maybe someone on this list could shed a light on this? Rene -- Rene de Vries To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 13 23:25:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 2BE2B37B400; Sun, 13 Jan 2002 23:25:46 -0800 (PST) Received: from dialup-209.244.106.114.dial1.sanjose1.level3.net ([209.244.106.114] helo=blossom.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Q1V2-0006C7-00; Sun, 13 Jan 2002 23:25:45 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0E7PfT25339; Sun, 13 Jan 2002 23:25:41 -0800 (PST) (envelope-from cjc) Date: Sun, 13 Jan 2002 23:25:41 -0800 From: "Crist J . Clark" To: Andreas Klemm Cc: freebsd-net@FreeBSD.ORG Subject: Re: FIREWALL_FORWARD vs. using /sbin/natd ? Message-ID: <20020113232541.E24290@blossom.cjclark.org> References: <20020113105636.GA88221@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020113105636.GA88221@titan.klemm.gtn.com>; from andreas@FreeBSD.ORG on Sun, Jan 13, 2002 at 11:56:36AM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote: > I found a document describing a firewall design only using natd > for redirects to internal network resources. (Hi Marshall, therefore > Cc: to you, since its yours and I have a question). > > http://www.rootprompt.net/freebsd_firewall.html > > Based on these informations I think I could get rid of natd entirely. Why do you say that? His example uses natd(8). > See my previous mail, my problem was, that I can't get it to run > for a typical 2 NIC configuration with internal network, DMZ and > a router in front of a 512k leased line. You didn't inlcude your firewall rules. > Or is this my NAT problem, that additionally I have to use the kernel > option FIREWALL_FORWARD, You don't need it. > to get NAT for internal users running, > 'though all other documents state out, that only IPFIREWALL and > IPDIVERT are needed ??? But it shouldn't cause problems. > Therefore the question, is using FIREWALL_FORWARD a good > replacement for /sbin/natd if you want to give users of > the internal network access to the outside world ? FIREWALL_FORWARD has nothing to do with NAT. > Are there some things to take care of, when using FIREWALL_FORWARD ? Yes, but nothing to do with NAT. > Does the logic for firewall rules change, or could I still use the > templates in /etc/rc.firewall ??? For what? -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 0:50:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 322CD37B417; Mon, 14 Jan 2002 00:50:12 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0E8oAe22605; Mon, 14 Jan 2002 09:50:10 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0E8eND01983; Mon, 14 Jan 2002 09:40:23 +0100 (CET) (envelope-from andreas) Date: Mon, 14 Jan 2002 09:40:23 +0100 From: Andreas Klemm To: "Crist J . Clark" Cc: freebsd-net@FreeBSD.ORG Subject: Re: FIREWALL_FORWARD vs. using /sbin/natd ? Message-ID: <20020114084023.GB1929@titan.klemm.gtn.com> References: <20020113105636.GA88221@titan.klemm.gtn.com> <20020113232541.E24290@blossom.cjclark.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20020113232541.E24290@blossom.cjclark.org> User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote: > On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote: > > I found a document describing a firewall design only using natd > > for redirects to internal network resources. (Hi Marshall, therefore > > Cc: to you, since its yours and I have a question). > >=20 > > http://www.rootprompt.net/freebsd_firewall.html > >=20 > > Based on these informations I think I could get rid of natd entirely. >=20 > Why do you say that? His example uses natd(8). He uses it only on the internal network card to redirect=20 2 application to inside machines. Look in the config ! > > See my previous mail, my problem was, that I can't get it to run > > for a typical 2 NIC configuration with internal network, DMZ and > > a router in front of a 512k leased line. >=20 > You didn't inlcude your firewall rules. I only send it privately. They are, as I told the templates from "simple", I only added ssh ... but this doesn't break the logic. > > Or is this my NAT problem, that additionally I have to use the kernel > > option FIREWALL_FORWARD, >=20 > You don't need it. o.k. > > to get NAT for internal users running, > > 'though all other documents state out, that only IPFIREWALL and > > IPDIVERT are needed ??? >=20 > But it shouldn't cause problems. >=20 > > Therefore the question, is using FIREWALL_FORWARD a good > > replacement for /sbin/natd if you want to give users of > > the internal network access to the outside world ? >=20 > FIREWALL_FORWARD has nothing to do with NAT. >=20 > > Are there some things to take care of, when using FIREWALL_FORWARD ? >=20 > Yes, but nothing to do with NAT. BUT WHAT does FIREWALL_FORWARD actually does ???? What happens if I define it in kernel, stop nat ? Can internal machines communicate to outside then ? What can outside machines do then ? Produces it a whole in the firewall ? Or is it something like NAT staeful ? Andreas /// --=20 Andreas Klemm - Powered by FreeBSD Need a magic printfilter today ? http://www.apsfilter.org/ Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8Qpl2d3o+lGxvbLoRAntbAKC5D2dIiwKTDE1SB/o7jddZdaS9eQCgsLte MHO6ix4+ksKW91txgjUJkXM= =at1W -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 1:19:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 8110437B419; Mon, 14 Jan 2002 01:19:47 -0800 (PST) Received: from dialup-209.244.106.114.dial1.sanjose1.level3.net ([209.244.106.114] helo=blossom.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Q3HN-0002Wc-00; Mon, 14 Jan 2002 01:19:46 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0E9Jd325745; Mon, 14 Jan 2002 01:19:39 -0800 (PST) (envelope-from cjc) Date: Mon, 14 Jan 2002 01:19:39 -0800 From: "Crist J . Clark" To: Andreas Klemm Cc: freebsd-net@FreeBSD.ORG Subject: Re: FIREWALL_FORWARD vs. using /sbin/natd ? Message-ID: <20020114011939.G24290@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020113105636.GA88221@titan.klemm.gtn.com> <20020113232541.E24290@blossom.cjclark.org> <20020114084023.GB1929@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020114084023.GB1929@titan.klemm.gtn.com>; from andreas@FreeBSD.ORG on Mon, Jan 14, 2002 at 09:40:23AM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 14, 2002 at 09:40:23AM +0100, Andreas Klemm wrote: > On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote: > > On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote: > > > I found a document describing a firewall design only using natd > > > for redirects to internal network resources. (Hi Marshall, therefore > > > Cc: to you, since its yours and I have a question). > > > > > > http://www.rootprompt.net/freebsd_firewall.html > > > > > > Based on these informations I think I could get rid of natd entirely. > > > > Why do you say that? His example uses natd(8). > > He uses it only on the internal network card to redirect > 2 application to inside machines. Look in the config ! It is also there for any machine on his 192.168.1.0/24 internal network to communicate with machines out on the Internet, and it is running on the _external_ interface (fxp0) not the internal one. [snip] > > > Are there some things to take care of, when using FIREWALL_FORWARD ? > > > > Yes, but nothing to do with NAT. > > BUT WHAT does FIREWALL_FORWARD actually does ???? Look for 'fwd' in ipfw(8). > What happens if I define it in kernel, stop nat ? Nothing to do with NAT. It's for making 'fwd' rules. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 3:52:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by hub.freebsd.org (Postfix) with SMTP id E730E37B400 for ; Mon, 14 Jan 2002 03:52:21 -0800 (PST) Received: from unknown (HELO kshitij1) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jan 2002 11:52:20 -0000 From: "Kshitij Gunjikar" To: Subject: RE: Filtering packets received through an ipsec tunnel Date: Mon, 14 Jan 2002 17:32:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Rene, I'm wondering why do you want to filter Secure traffic? The very fact that you have a tunnel to a place means you trust that network. Hence, why filter? What are the complex situations you have in mind? Regards Kshitij -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries Sent: Sunday, January 13, 2002 10:32 PM To: net@freebsd.org Subject: Filtering packets received through an ipsec tunnel Hello, > This message was already posted to hackers@freebsd.org, but with > limited success. I'm hoping that someone on net@freebsd.org can give me > some more information. By experimenting with ipsec and looking at the source of "ip_input.c" a co-worker and I found the following out. When a ipsec tunnel packet is received this (protocol 50/51) packet is passed through ip-filter (& co). After filtering and when it has been determent that the current host is the destination (tunnel end-point), this packet is decrypted/verified. The decrypted packet is then pushed back into the queue that leads to ip_input(...). So far so good.... But once in ip_input(...) the filtering code is skipped and we were wondering why. I know that ipsec has some handles to be able to filter on address, protocol and/or port. But for more complex situations this is not enough. In these situations it would be nice to be able to use ip-filter (& co) on traffic from the tunnel (and also for traffic going into the tunnel). I was wondering why this is implemented the way it is. Maybe someone on this list could shed a light on this? Rene -- Rene de Vries To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 4: 9:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id DA50A37B41A for ; Mon, 14 Jan 2002 04:09:27 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id NAA05285 for ; Mon, 14 Jan 2002 13:09:26 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSP960>; Mon, 14 Jan 2002 13:09:26 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: freebsd-net@FreeBSD.ORG Subject: RE: Filtering packets received through an ipsec tunnel Date: Mon, 14 Jan 2002 13:09:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello IPSec Tunnel security is working like this: You have to permit traffic to the Tunnel, this you can du with Access-Lists on a Firewall (ie ipfw) In the Tunnel, only permitted traffic will be transmitted, so you don't have to filter packets comming from the IPSec Tunnel. It's not interesting to transmit all the traffic and filter the traffic on the tunnel-end. Beacause all traffic submitted by the tunnel needs bandwith on the WAN interface. But if you will do this, you can define special Access-lists with ipfw where you deny or permit special kinds of traffic from the Network on the other side of the tunnel. Regards Reto Trachsel Your Partner for Internet & Networking Technologies! ____________________________________________________ NetModule AG Meriedweg 7 / CH-3172 Niederwangen Phone: +41 31 985 25 10 / Fax: +41 31 985 25 11 www.netmodule.com NetModule AG, Java Competence Center Zuercherstrasse 12 / Postfach / CH-8401 Winterthur Phone: +41 52 209 00 44 / Fax: +41 52 209 00 40 ____________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 5: 4:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by hub.freebsd.org (Postfix) with SMTP id 5EA5D37B41A for ; Mon, 14 Jan 2002 05:04:20 -0800 (PST) Received: from unknown (HELO kshitij1) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jan 2002 13:04:17 -0000 From: "Kshitij Gunjikar" To: Subject: DHCP and IP Input Date: Mon, 14 Jan 2002 18:44:07 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, I have one question? If we have a FreeBSD box configured as a router and we are not supporting a DHCP like protocol then do we drop packets with 0.0.0.0 source address? As per RFC 1812 we must. Regards Kshitij _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 5:12:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id 2686137B402 for ; Mon, 14 Jan 2002 05:12:08 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0EDD6G12629; Mon, 14 Jan 2002 14:13:06 +0100 (CET) (envelope-from alexlh) Date: Mon, 14 Jan 2002 14:13:05 +0100 From: Alex Le Heux To: Kshitij Gunjikar Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020114131305.GK75815@funk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I don't think this is quite correct. The fact that I have a tunnel means I have some relation with the other network, and that I do not trust the network(s) between us. It does NOT mean that I trust their security setup and want to receive any packet that they send me. So I would certainly hope that I have the option of filtering. Cheers, Alex Le Heux On Mon, Jan 14, 2002 at 05:32:11PM +0530, Kshitij Gunjikar wrote: > > > Hi Rene, > I'm wondering why do you want to filter Secure traffic? > > The very fact that you have a tunnel to a place means you trust that > network. Hence, why filter? > > What are the complex situations you have in mind? > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > Sent: Sunday, January 13, 2002 10:32 PM > To: net@freebsd.org > Subject: Filtering packets received through an ipsec tunnel > > > Hello, > > > This message was already posted to hackers@freebsd.org, but with > > limited success. I'm hoping that someone on net@freebsd.org can give me > > some more information. > > By experimenting with ipsec and looking at the source of "ip_input.c" a > co-worker and I found the following out. > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > passed through ip-filter (& co). After filtering and when it has been > determent that the current host is the destination (tunnel end-point), > this packet is decrypted/verified. The decrypted packet is then pushed > back into the queue that leads to ip_input(...). So far so good.... > > But once in ip_input(...) the filtering code is skipped and we were > wondering why. > > I know that ipsec has some handles to be able to filter on address, > protocol and/or port. But for more complex situations this is not > enough. In these situations it would be nice to be able to use > ip-filter (& co) on traffic from the tunnel (and also for traffic going > into the tunnel). > > I was wondering why this is implemented the way it is. Maybe someone on > this list could shed a light on this? > > Rene > -- > Rene de Vries > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- "My theory is that the (Internet) industry was started in large part by technologists rather than media people..." - Robin Webster, President, Interactive Advertising Bureau To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 5:30:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by hub.freebsd.org (Postfix) with SMTP id 0457F37B402 for ; Mon, 14 Jan 2002 05:30:51 -0800 (PST) Received: from unknown (HELO kshitij1) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Jan 2002 13:30:48 -0000 From: "Kshitij Gunjikar" To: Subject: RE: Filtering packets received through an ipsec tunnel Date: Mon, 14 Jan 2002 19:10:39 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020114131305.GK75815@funk.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, If you have a IPSec packet you can't see the data(even if u can it's useless as it's encrypted). unless you exchange keys and know what the encryption algorithm we can't decrypt and know the information being passed. Hence, the fact that we are using IPsec gives greater security than any firewall can. You can't possibly break a 128-bit encryption. till now I don't think it has been broken. if you want restrict somebody in your internal network from using IPSec. Then yes we must be able to do it with a firewall. If somebody in your trusted internal network hacks then you are in trouble . If I'm not wrong few firewalls take care of it . Also, if some body corrupts the encrypted packet then we can discard it at time of decryption. Regards Kshitij -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Alex Le Heux Sent: Monday, January 14, 2002 6:43 PM To: Kshitij Gunjikar Cc: freebsd-net@freebsd.org Subject: Re: Filtering packets received through an ipsec tunnel Hi, I don't think this is quite correct. The fact that I have a tunnel means I have some relation with the other network, and that I do not trust the network(s) between us. It does NOT mean that I trust their security setup and want to receive any packet that they send me. So I would certainly hope that I have the option of filtering. Cheers, Alex Le Heux On Mon, Jan 14, 2002 at 05:32:11PM +0530, Kshitij Gunjikar wrote: > > > Hi Rene, > I'm wondering why do you want to filter Secure traffic? > > The very fact that you have a tunnel to a place means you trust that > network. Hence, why filter? > > What are the complex situations you have in mind? > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > Sent: Sunday, January 13, 2002 10:32 PM > To: net@freebsd.org > Subject: Filtering packets received through an ipsec tunnel > > > Hello, > > > This message was already posted to hackers@freebsd.org, but with > > limited success. I'm hoping that someone on net@freebsd.org can give me > > some more information. > > By experimenting with ipsec and looking at the source of "ip_input.c" a > co-worker and I found the following out. > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > passed through ip-filter (& co). After filtering and when it has been > determent that the current host is the destination (tunnel end-point), > this packet is decrypted/verified. The decrypted packet is then pushed > back into the queue that leads to ip_input(...). So far so good.... > > But once in ip_input(...) the filtering code is skipped and we were > wondering why. > > I know that ipsec has some handles to be able to filter on address, > protocol and/or port. But for more complex situations this is not > enough. In these situations it would be nice to be able to use > ip-filter (& co) on traffic from the tunnel (and also for traffic going > into the tunnel). > > I was wondering why this is implemented the way it is. Maybe someone on > this list could shed a light on this? > > Rene > -- > Rene de Vries > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- "My theory is that the (Internet) industry was started in large part by technologists rather than media people..." - Robin Webster, President, Interactive Advertising Bureau To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 5:52:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from rod.inty.net (rod.inty.net [195.224.93.241]) by hub.freebsd.org (Postfix) with ESMTP id 1B71C37B416 for ; Mon, 14 Jan 2002 05:52:38 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by rod.inty.net (8.11.3/8.11.3) with ESMTP id g0EDqPx85356 for ; Mon, 14 Jan 2002 13:52:27 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g0EDqBv5016240 for ; Mon, 14 Jan 2002 13:52:12 GMT From: "Tariq Rashid" To: Subject: mpd-netgraph PPTP and MS encryption. Date: Mon, 14 Jan 2002 13:54:29 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Sender-IP: 10.0.1.156 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 63476 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org an anyone point me to some sample mpd-netgraph (3.3) configurations for Microsoft PPTP clients... using encyption... for all win98 up to win2k? i'm using (with pptp0 up to pptp4, say)... pptp0: new -i ng0 pptp0 pptp0 set iface disable on-demand set iface enable proxy-arp set bundle disable multilink set link yes acfcomp protocomp set link enable pap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 192.168.2.31/32 192.168.2.100/32 set ipcp dns 192.168.2.31 set ipcp nbns 192.168.2.31 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless the connections complete - but the freebsd servers side reports no encrytion enabled? i'm confused as to why ccp sets the encryption in "set ccp..." ? and "show bundle", "show ecp" show no encyryption? am i wrong? regards tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 6: 8:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id 15FC737B400 for ; Mon, 14 Jan 2002 06:08:10 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0EE97n13196; Mon, 14 Jan 2002 15:09:07 +0100 (CET) (envelope-from alexlh) Date: Mon, 14 Jan 2002 15:09:06 +0100 From: Alex Le Heux To: Kshitij Gunjikar Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020114140906.GN75815@funk.org> References: <20020114131305.GK75815@funk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm not worried about people modifying the IPSec packets en route, that's what we have strong crypto for. I am worried about giving the network at the other end of the tunnel full access to mine. In only a few of the many possible IPSec implementations do both ends of the tunnel follow the same security policies. And even then I might want to use filtering. I tend to see an IPSec tunnel more like a leased line that happens to use an IP network as iunderlying transport. Just as with a leased line I want to be able to filter packets going in and out, even though I may not use that filtering capability in all circumstances. Although using filters in this way on a machine that has multiple tunnels that go up and down could cause some headaches... Cheers, Alex On Mon, Jan 14, 2002 at 07:10:39PM +0530, Kshitij Gunjikar wrote: > Hi, > If you have a IPSec packet you can't see the data(even if u can it's > useless as it's encrypted). unless you exchange keys and know what the > encryption algorithm we can't decrypt and know the information being passed. > Hence, the fact that we are using IPsec gives greater security than any > firewall can. You can't possibly break a 128-bit encryption. till now I > don't think it has been broken. > > if you want restrict somebody in your internal network from using IPSec. > Then yes we must be able to do it with a firewall. > If somebody in your trusted internal network hacks then you are in trouble . > If I'm not wrong few firewalls take care of it . > > Also, if some body corrupts the encrypted packet then we can discard it at > time of decryption. > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Alex Le Heux > Sent: Monday, January 14, 2002 6:43 PM > To: Kshitij Gunjikar > Cc: freebsd-net@freebsd.org > Subject: Re: Filtering packets received through an ipsec tunnel > > > Hi, > > I don't think this is quite correct. > > The fact that I have a tunnel means I have some relation with the other > network, and that I do not trust the network(s) between us. > > It does NOT mean that I trust their security setup and want to receive any > packet that they send me. > > So I would certainly hope that I have the option of filtering. > > Cheers, > > Alex Le Heux > > On Mon, Jan 14, 2002 at 05:32:11PM +0530, Kshitij Gunjikar wrote: > > > > > > Hi Rene, > > I'm wondering why do you want to filter Secure traffic? > > > > The very fact that you have a tunnel to a place means you trust that > > network. Hence, why filter? > > > > What are the complex situations you have in mind? > > > > Regards > > Kshitij > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org > > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > > Sent: Sunday, January 13, 2002 10:32 PM > > To: net@freebsd.org > > Subject: Filtering packets received through an ipsec tunnel > > > > > > Hello, > > > > > This message was already posted to hackers@freebsd.org, but with > > > limited success. I'm hoping that someone on net@freebsd.org can give me > > > some more information. > > > > By experimenting with ipsec and looking at the source of "ip_input.c" a > > co-worker and I found the following out. > > > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > > passed through ip-filter (& co). After filtering and when it has been > > determent that the current host is the destination (tunnel end-point), > > this packet is decrypted/verified. The decrypted packet is then pushed > > back into the queue that leads to ip_input(...). So far so good.... > > > > But once in ip_input(...) the filtering code is skipped and we were > > wondering why. > > > > I know that ipsec has some handles to be able to filter on address, > > protocol and/or port. But for more complex situations this is not > > enough. In these situations it would be nice to be able to use > > ip-filter (& co) on traffic from the tunnel (and also for traffic going > > into the tunnel). > > > > I was wondering why this is implemented the way it is. Maybe someone on > > this list could shed a light on this? > > > > Rene > > -- > > Rene de Vries > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- > "My theory is that the (Internet) industry was started in > large part by technologists rather than media people..." > - Robin Webster, President, Interactive Advertising Bureau > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- "Although the force from the engine is a lot for a motorcycle, the Earth is not impressed. The Motorcycle and I loose the 'F' and 'm' battle and have to consume all the 'a' in the form of sheer unadulterated acceleration." - Ian Orr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 6:19:55 2002 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 0C12237B41F for ; Mon, 14 Jan 2002 06:19:25 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id g0EEJOE73252 for ; Mon, 14 Jan 2002 09:19:24 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200201141419.g0EEJOE73252@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Filtering packets received through an ipsec tunnel References: In-reply-to: Your message of "Mon, 14 Jan 2002 13:09:22 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 09:19:24 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The problem, of course, is that tunnel-mode IPSEC is too coarse a mechanism to implement security policy for some people. Imagine if you will that you're using IPSEC in an "extranet" situation; that is, to secure communication between two different parties. Perhaps between you and your suppliers. You'd like to secure traffic over that tunnel so that you can place orders for widgets and not have that be intercepted. But you're unwilling to allow the Widget manufacturer to send you NFS traffic or have access to abritratry services on your network. This is why you'd like to apply additional policy to the traffic which emerges (and perhaps enters) an IPSEC tunnel. The problem is there is no logical interface associated with an IPSEC tunnel, which is likely a mistake. If you could synthesize interfaces for the tunnels, then you have a handle to hang the firewall processing on. And before you suggest that the gif tunnels seen in all those IPSEC examples actually have anything to do with IPSEC tunnels, please try it and look again. It's completely uninvolved other than introducing a route as a side-effect. louie > Hello > > IPSec Tunnel security is working like this: You have to permit traffic to > the Tunnel, this you can du with Access-Lists on a Firewall (ie ipfw) > > In the Tunnel, only permitted traffic will be transmitted, so you don't have > to filter packets comming from the IPSec Tunnel. It's not interesting to > transmit all the traffic and filter the traffic on the tunnel-end. Beacause > all traffic submitted by the tunnel needs bandwith on the WAN interface. But > if you will do this, you can define special Access-lists with ipfw where you > deny or permit special kinds of traffic from the Network on the other side > of the tunnel. > > Regards > Reto Trachsel > > Your Partner for Internet & Networking Technologies! > ____________________________________________________ > NetModule AG > Meriedweg 7 / CH-3172 Niederwangen > Phone: +41 31 985 25 10 / Fax: +41 31 985 25 11 > www.netmodule.com > > NetModule AG, Java Competence Center > Zuercherstrasse 12 / Postfach / CH-8401 Winterthur > Phone: +41 52 209 00 44 / Fax: +41 52 209 00 40 > ____________________________________________________ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 6:26:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from jane.inty.net (jane.inty.net [195.224.93.242]) by hub.freebsd.org (Postfix) with ESMTP id CAD1737B416 for ; Mon, 14 Jan 2002 06:26:33 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by jane.inty.net (8.11.3/8.11.3) with ESMTP id g0EEQTt76524 for ; Mon, 14 Jan 2002 14:26:30 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g0EEQIv5021943; Mon, 14 Jan 2002 14:26:18 GMT From: "Tariq Rashid" To: "Tariq Rashid" , Subject: RE: mpd-netgraph PPTP and MS encryption. Date: Mon, 14 Jan 2002 14:28:35 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Sender-IP: 10.0.1.156 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 11037 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org oops - sounds liek MPPE encryption is a subprotocol of the compression protocol... hence the confusion! t -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Tariq Rashid Sent: 14 January 2002 13:54 To: freebsd-net@freebsd.org Subject: mpd-netgraph PPTP and MS encryption. an anyone point me to some sample mpd-netgraph (3.3) configurations for Microsoft PPTP clients... using encyption... for all win98 up to win2k? i'm using (with pptp0 up to pptp4, say)... pptp0: new -i ng0 pptp0 pptp0 set iface disable on-demand set iface enable proxy-arp set bundle disable multilink set link yes acfcomp protocomp set link enable pap set link enable chap set link keep-alive 60 180 set ipcp yes vjcomp set ipcp ranges 192.168.2.31/32 192.168.2.100/32 set ipcp dns 192.168.2.31 set ipcp nbns 192.168.2.31 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless the connections complete - but the freebsd servers side reports no encrytion enabled? i'm confused as to why ccp sets the encryption in "set ccp..." ? and "show bundle", "show ecp" show no encyryption? am i wrong? regards tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 7:28:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id A8D6937B41D for ; Mon, 14 Jan 2002 07:28:33 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id QAA10421; Mon, 14 Jan 2002 16:28:28 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSP906>; Mon, 14 Jan 2002 16:28:28 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: "'Alex Le Heux'" , Kshitij Gunjikar Cc: freebsd-net@FreeBSD.ORG Subject: RE: Filtering packets received through an ipsec tunnel Date: Mon, 14 Jan 2002 16:28:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all Ok, at this time I would handle this problem like this: Connect the two sides with an IPSec Tunnel and write an access-list with ipfw that allow only the specified traffic from the other side network to your network. This would be the fastest way to handle this problem. For this, you have to enable the Firewall Feature on FreeBSD and enter the rouls with the ipfw programm (/etc/rc.firewall or an other included Script.) The script could look like this: ipfw add allow tcp from 192.168.10.0/24 22 to 192.168.20.0/24 22 ipfw add allow tcp from 192.168.20.0/24 22 to 192.168.10.0/24 22 ipfw add deny ip from any to any This example permit all SSH Connections from the External to the Internal Network where the External Net: 192.168.10.0/24 and the Internal Net: 192.168.20.0/24. More Informations about the Firewall and its roules: man ipfw Regards Reto Trachsel Your Partner for Internet & Networking Technologies! ____________________________________________________ NetModule AG Meriedweg 7 / CH-3172 Niederwangen Phone: +41 31 985 25 10 / Fax: +41 31 985 25 11 www.netmodule.com NetModule AG, Java Competence Center Zuercherstrasse 12 / Postfach / CH-8401 Winterthur Phone: +41 52 209 00 44 / Fax: +41 52 209 00 40 ____________________________________________________ -----Original Message----- From: Alex Le Heux [mailto:alexlh@funk.org] Sent: Montag, 14. Januar 2002 15:09 To: Kshitij Gunjikar Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel ... I am worried about giving the network at the other end of the tunnel full access to mine. In only a few of the many possible IPSec implementations do both ends of the tunnel follow the same security policies. And even then I might want to use filtering. ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 8:41:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from shark.amis.net (shark.amis.net [212.18.32.14]) by hub.freebsd.org (Postfix) with ESMTP id 0B30637B405 for ; Mon, 14 Jan 2002 08:41:56 -0800 (PST) Received: from baracuda.amis.net (baracuda.amis.net [212.18.32.4]) by shark.amis.net (Postfix) with ESMTP id 7FEA37C0E; Mon, 14 Jan 2002 17:41:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baracuda.amis.net (Postfix) with ESMTP id 4C5F79B06; Mon, 14 Jan 2002 17:41:54 +0100 (CET) Received: from titanic.medinet.si (titanic.medinet.si [212.18.42.5]) by baracuda.amis.net (Postfix) with ESMTP id 733E59B05; Mon, 14 Jan 2002 17:41:53 +0100 (CET) Received: by titanic.medinet.si (Postfix, from userid 1000) id 68C9E55411; Mon, 14 Jan 2002 17:41:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by titanic.medinet.si (Postfix) with ESMTP id 5DEA555404; Mon, 14 Jan 2002 17:41:50 +0100 (CET) Date: Mon, 14 Jan 2002 17:41:50 +0100 (CET) From: Blaz Zupan X-X-Sender: blaz@titanic.medinet.si To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel In-Reply-To: <200201141419.g0EEJOE73252@whizzo.transsys.com> Message-ID: <20020114173900.I2807-100000@titanic.medinet.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > And before you suggest that the gif tunnels seen in all those IPSEC > examples actually have anything to do with IPSEC tunnels, please try > it and look again. It's completely uninvolved other than introducing > a route as a side-effect. I'm not sure what you mean here, but shouldn't the following work: we create a gif tunnel between the two endpoints and just encrypt the gif traffic itself. Then we can filter the packets that go in and out of the gif interface. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 9:12:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 79DD537B41A for ; Mon, 14 Jan 2002 09:12:42 -0800 (PST) Received: from isi.edu (zw6n8uwjt0nv7v5v@b.postel.org [128.9.112.66]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0EHCGN19293; Mon, 14 Jan 2002 09:12:16 -0800 (PST) Message-ID: <3C431170.5080506@isi.edu> Date: Mon, 14 Jan 2002 09:12:16 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011203 X-Accept-Language: en, de MIME-Version: 1.0 To: Blaz Zupan Cc: "Louis A. Mamakos" , freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel References: <20020114173900.I2807-100000@titanic.medinet.si> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Blaz Zupan wrote: >>And before you suggest that the gif tunnels seen in all those IPSEC >>examples actually have anything to do with IPSEC tunnels, please try >>it and look again. It's completely uninvolved other than introducing >>a route as a side-effect. >> > > I'm not sure what you mean here, but shouldn't the following work: we create a > gif tunnel between the two endpoints and just encrypt the gif traffic itself. > Then we can filter the packets that go in and out of the gif interface. He was referring to using gif tunnels together with IPsec tunnel mode SAs (are you?) This "works" but precisely because of the side effect that Louis mentioned. A clean solution would user *either* IPIP tunnels (i.e. gif devices) and IPsec transport mode *or* IPsec tunnel mode (and no gifs). See the KAME IMPLEMENTATION file for details, or draft-touch-ipsec-vpn-02.txt (shameless plug :-). Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 9:16: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from shark.amis.net (shark.amis.net [212.18.32.14]) by hub.freebsd.org (Postfix) with ESMTP id C0B7537B41A for ; Mon, 14 Jan 2002 09:15:52 -0800 (PST) Received: from baracuda.amis.net (baracuda.amis.net [212.18.32.4]) by shark.amis.net (Postfix) with ESMTP id 4AAF97CCE; Mon, 14 Jan 2002 18:15:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baracuda.amis.net (Postfix) with ESMTP id 15F4E9B0D; Mon, 14 Jan 2002 18:15:46 +0100 (CET) Received: from titanic.medinet.si (titanic.medinet.si [212.18.42.5]) by baracuda.amis.net (Postfix) with ESMTP id 92EB49B0C; Mon, 14 Jan 2002 18:15:44 +0100 (CET) Received: by titanic.medinet.si (Postfix, from userid 1000) id 4951755411; Mon, 14 Jan 2002 18:15:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by titanic.medinet.si (Postfix) with ESMTP id 4684D55404; Mon, 14 Jan 2002 18:15:44 +0100 (CET) Date: Mon, 14 Jan 2002 18:15:44 +0100 (CET) From: Blaz Zupan X-X-Sender: blaz@titanic.medinet.si To: Lars Eggert Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel In-Reply-To: <3C431170.5080506@isi.edu> Message-ID: <20020114181510.S3425-100000@titanic.medinet.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > He was referring to using gif tunnels together with IPsec tunnel mode > SAs (are you?) This "works" but precisely because of the side effect > that Louis mentioned. A clean solution would user *either* IPIP tunnels > (i.e. gif devices) and IPsec transport mode *or* IPsec tunnel mode (and > no gifs). See the KAME IMPLEMENTATION file for details, or > draft-touch-ipsec-vpn-02.txt (shameless plug :-). Oh, ok, that was a misunderstanding, I was talkin about gif tunnels over IPsec transport mode of course. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 9:55:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by hub.freebsd.org (Postfix) with ESMTP id 6089537B419 for ; Mon, 14 Jan 2002 09:55:28 -0800 (PST) Received: from grand.canyon.xs4all.nl (canyon.xs4all.nl [194.109.195.185]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0EHtQP5033818; Mon, 14 Jan 2002 18:55:26 +0100 (CET) Received: by grand.canyon.xs4all.nl (Postfix, from userid 1000) id C56EF5FA9; Mon, 14 Jan 2002 18:55:25 +0100 (CET) Received: from meandrix.tunix.nl (localhost [127.0.0.1]) by grand.canyon.xs4all.nl (Postfix) with ESMTP id 8CC785DB2; Mon, 14 Jan 2002 18:55:25 +0100 (CET) Date: Mon, 14 Jan 2002 18:55:28 +0100 Subject: Re: Filtering packets received through an ipsec tunnel Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: net@freebsd.org To: "Kshitij Gunjikar" From: Rene de Vries In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kshitij, As some other people already mentioned: It might be the case that both ends of the tunnel are not within the same administrative domain. The connection is secure, this does not mean that the traffic is also so. A good solution, from my point of view, would be, instead of passing evering thing from an ipsec tunnel, using ip-filter (&co, but without dummyet) on emerging packets. These packets should then have a different interface or a special flag for easy testing in ip-filter (&co). I don't know what the best solution would be, extending ip-filter with an extra flag or adding a special (dummy) interface. My gut feeling is a special flag makes more sense, but will break current ip-filter/ipfw syntax/configurations. I think it is generally usefull to be able to filter/nat traffic into/from an ipsec tunnel. When you trust the other side as your own, simply don't use it, but otherwise it is essential. The filtering in ipsec (with setkey) is simply not enough. Rene On Monday, January 14, 2002, at 01:02 , Kshitij Gunjikar wrote: > I'm wondering why do you want to filter Secure traffic? > > The very fact that you have a tunnel to a place means you trust that > network. Hence, why filter? > > What are the complex situations you have in mind? > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > Sent: Sunday, January 13, 2002 10:32 PM > To: net@freebsd.org > Subject: Filtering packets received through an ipsec tunnel > > > Hello, > >> This message was already posted to hackers@freebsd.org, but with >> limited success. I'm hoping that someone on net@freebsd.org can give me >> some more information. > > By experimenting with ipsec and looking at the source of "ip_input.c" a > co-worker and I found the following out. > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > passed through ip-filter (& co). After filtering and when it has been > determent that the current host is the destination (tunnel end-point), > this packet is decrypted/verified. The decrypted packet is then pushed > back into the queue that leads to ip_input(...). So far so good.... > > But once in ip_input(...) the filtering code is skipped and we were > wondering why. > > I know that ipsec has some handles to be able to filter on address, > protocol and/or port. But for more complex situations this is not > enough. In these situations it would be nice to be able to use > ip-filter (& co) on traffic from the tunnel (and also for traffic going > into the tunnel). > > I was wondering why this is implemented the way it is. Maybe someone on > this list could shed a light on this? -- Rene de Vries To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 10: 5:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by hub.freebsd.org (Postfix) with ESMTP id 7AD9037B405 for ; Mon, 14 Jan 2002 10:05:52 -0800 (PST) Received: from grand.canyon.xs4all.nl (canyon.xs4all.nl [194.109.195.185]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g0EI5oiY024639; Mon, 14 Jan 2002 19:05:50 +0100 (CET) Received: by grand.canyon.xs4all.nl (Postfix, from userid 1000) id F183C5FA9; Mon, 14 Jan 2002 19:05:49 +0100 (CET) Received: from meandrix.tunix.nl (localhost [127.0.0.1]) by grand.canyon.xs4all.nl (Postfix) with ESMTP id B8DF75DB2; Mon, 14 Jan 2002 19:05:49 +0100 (CET) Date: Mon, 14 Jan 2002 19:05:52 +0100 Subject: Re: Filtering packets received through an ipsec tunnel Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Lars Eggert To: net@freebsd.org From: Rene de Vries In-Reply-To: <3C431170.5080506@isi.edu> Message-Id: <58FB1C50-0919-11D6-AC08-00039357FA7A@canyon.xs4all.nl> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Gif tunnels are not the samething as ipsec tunnels. For one some ipsec implementations simply won't work with gif tunnels. Furthermore the administrative overhead when there are more than a few tunnels is enormous. It is much simpler to have racoon do some (a lot) of the work for you. Say, for example, you have about 200(1) tunnel partners, of which only about 30 are connected at the same time. This would mean 200 extra interfaces, a totally unmanagable situation. Whereas the ip-filter rules could be very simple/generic for all of them. The only configuration issue you will have to face is generating the SPDs and filling racoon with the correct keys. But this can't be helped. 1) These number are an example, not reallife... On Monday, January 14, 2002, at 06:12 , Lars Eggert wrote: > Blaz Zupan wrote: > >>> And before you suggest that the gif tunnels seen in all those IPSEC >>> examples actually have anything to do with IPSEC tunnels, please try >>> it and look again. It's completely uninvolved other than introducing >>> a route as a side-effect. >>> >> I'm not sure what you mean here, but shouldn't the following work: we >> create a gif tunnel between the two endpoints and just encrypt the gif >> traffic itself. >> Then we can filter the packets that go in and out of the gif interface. > > He was referring to using gif tunnels together with IPsec tunnel mode > SAs (are you?) This "works" but precisely because of the side effect > that Louis mentioned. A clean solution would user *either* IPIP tunnels > (i.e. gif devices) and IPsec transport mode *or* IPsec tunnel mode (and > no gifs). See the KAME IMPLEMENTATION file for details, or > draft-touch-ipsec-vpn-02.txt (shameless plug :-). -- Rene de Vries To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 11:20:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 8B25337B404; Mon, 14 Jan 2002 11:20:04 -0800 (PST) Received: from pool0325.cvx40-bradley.dialup.earthlink.net ([216.244.43.70] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16QCeC-00071p-00; Mon, 14 Jan 2002 11:19:57 -0800 Message-ID: <3C432F3A.FE136FD@mindspring.com> Date: Mon, 14 Jan 2002 11:19:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "James E. Housley" Cc: Bosko Milekic , Thomas Hurst , net@FreeBSD.org Subject: Re: 64 bit counters again References: <3C41F3FD.4ECC8CD@mindspring.com> <20020113231459.GA30349@voi.aagh.net> <3C42390A.F9E9F533@mindspring.com> <3C42E899.CB21BD0A@FreeBSD.org> <20020114105859.A24635@technokratis.com> <3C4305E5.65BB32A6@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ ... Moved to -net ... ] "James E. Housley" wrote: > I am just trying to count bytes in and out, too keep track of usage and > head off a large overage and a larger bill then necessary. Counting > packets is worthless. But just do the math. With a GigE NIC, at what > data rate do you start overflowing the counters too quickly. I suppose > there is another possibility, that the ti GigE driver is counting the > data multiple times. But I don't think so, because at 200Mbits/sec the > counter should overflow in 172 seconds. And this machine is easily > doing this most of the day. Do you get billed on retransmits? I'm pretty sure that they are not counted, unless you have a Tigon II, and have rewritten the firmware, or have a non-disclosure with another vendor, a license for their firmware, and have rewritten the firmware. I think the place to count this stuff is at the router. If your router *is* the FreeBSD box, then it makes sense for you to do the counting; but it doesn't make sense for the rest of us to do the counting. Is your problem with packet granularity that it doesn't give you better than an estimate based on an average packet size of the amount of data you send? You can keep a modular counter based on kilobytes (or even on megabytes), where keep an exact byte count at that level of granularity, but don't reflect that granularity out into the counter itself. In other words, make it accurate, but not precise. > That all sounds reasonable. And it make sense to move the counters > under existing locks. But, 32-bit machines are going to be around for > awhile longer and fast network connections are going to get faster and > more common. Maybe the counters should be completely removed from the > 32-bit arch.s since they give such misleading results and only have them > on the 64-bit machines. That way no one will be confused by the data. > > Of course I am not completely serious about removing the counters, but > it is not hard to make them very wrong. The problem with this is that it appears that you have a very specific problem domain that, if fully mapped, will damage the performance for the rest of us: a system in-the-neighborhood-of gigabit throughput, for which every byte is counted against you as part of a cost metric (most people at that level have an optical cable in from a NAP, and really don't care about bytes transited because they are one of the top tier backbone providers). I would be much more comfortable with you slowing you down, and not the rest of us. To my mind, the ability to meter based on this type of metric acts against flat rate pipes, and comes down on the wrong side of the technology wall between the users, who want to buy based on size of water pipe, and the providers, who want to charge based on how much water goes through the pipe, so that they can get their tax on every drop. In other words, if I had my way, it would be technologically impossible to meter based on a metric like this (it's the one merit to a direct ATM interconnect, IMO: inability to even store accounting records fast enough without a supercomputer). "...Of course I am not completely serious about removing the counters..." 8-) Frankly, I have a hard time believing that you really have the problem that you think you have. Specifically, I have worked on Gigabit equipment, and while it's nice and impressive sounding to be able to say "GigaBit!" in an "I've just had my cake frosted!" excited voice, in practice, there's not a real colocation center on the planet that would let you talk out their pipes at anywhere near that rate, and you would be really hard put to find one that could talk fast enough to allow you to pump a fully saturated 100Mbit interface out of your box. I helped put a single Gigabit box in front of three of the top ten porn sites in the U.S., and even while the damn thing was starting up under load and before startup had fully completed, the thing never got over 7% load, and in operation, it ran at around 4% load steady-state, and that's *CPU load* on a 1GHz Pentium, not even network load (which was a hell of a lot less). -- This is getting way off topic, but here is a business case illustration. Are you perhaps doing what the Q/A people at a previous job were doing, and stress-testing the crap out of a machine on a Gigabit LAN, at or near wire speeds, when in the field, the equipment is *NEVER*, *EVER* going to have to handle anywhere near even 1/40th of the load you are placing on it? While it is natural -- even, in some ways, admirable -- for Q/A people to want to test their products to destruction, you are going to manufacture sev-1 bugs where none will exist in deployment at customer sites, and these putative "show stoppers" will cost you in time to market and other areas where you really can't afford to be pissing away time over nothing (e.g. if your sales force gets wind of them, they will lose confidence in the products ability to make your customers happy, when in fact no such problem really exists). While customers are likey to set up a test network like yours, and stress test it, they are unlikely to be able to duplicate your load. In practice, this means anything that can't be repeated with standard test tools (e.g. http_load, etc.) in under 24 hours will not show up, even under their "stress test" scenarios. Customers care about equipment not failing, not about equipment being infallable. For example, if you have a problem that occurs once a day at that level of amplification, in the field it will perhaps occur once every month and a half, assuming that your customer keeps the load up at that level, and the problem is unrelated to resource starvation (e.g. a small memory leak in an uncommon failure mode, where an allocation is not freed, when the machine is under stress). In other words, if someone were to DDOS them for a month and a half at a dual OC3 facility like Exodus or UUNet in San Jose, and they did absolutely nothing to stop or curb the attack, then you might expect to see the problem in the field in a month. If your problem occurs once a week, then that grows to almost a year before the problem is seen in the field, assuming that there are no upgrades or anything else requiring a "bugfix"... so half-life that: you have six months to come up with a fix for it, and push it off as a "security upgrade" -- technically, it is one -- assuming the customer plugs in your box and then forgets it. If they reboot or reconfigure, requiring a reboot, then the clock starts all over again. In fact, this assumes linear amplification: "multiply the data rate by 40, and you multiply the failure rate by 40"; in the real world, this relationship is exponential: something you see at the stress breaking point of your product will be almost impossible to repeat in the field. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 12: 1:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id DC39E37B404 for ; Mon, 14 Jan 2002 12:01:42 -0800 (PST) Received: (from rousskov@localhost) by measurement-factory.com (8.9.3/8.9.3) id NAA19322; Mon, 14 Jan 2002 13:01:41 -0700 (MST) (envelope-from rousskov) Date: Mon, 14 Jan 2002 13:01:41 -0700 (MST) From: Alex Rousskov To: Terry Lambert Cc: net@FreeBSD.ORG Subject: Re: 64 bit counters again In-Reply-To: <3C432F3A.FE136FD@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 14 Jan 2002, Terry Lambert wrote: > This is getting way off topic, but here is a business case > illustration. > > Are you perhaps doing what the Q/A people at a previous job were > doing, and stress-testing the crap out of a machine on a Gigabit > LAN, at or near wire speeds, when in the field, the equipment is > *NEVER*, *EVER* going to have to handle anywhere near even 1/40th > of the load you are placing on it? > In fact, this assumes linear amplification: "multiply the data > rate by 40, and you multiply the failure rate by 40"; in the > real world, this relationship is exponential: something you see > at the stress breaking point of your product will be almost > impossible to repeat in the field. In my experience, this logic and conclusion do not hold in general. Yes, there are cases where beating the crap out of a machine is useless. However, in many cases, stress-testing at performance limits is one of the fastest and simplest ways of finding bugs that would otherwise be exposed under real (and possibly less stressful) conditions. And not just performance-related bugs, I must add! This kind of testing is never sufficient, of course. Disclaimer: I beat the crap out of machines for a living. This probably makes me biased (but Terry is probably biased the other way around since it is "his" box that is being beaten). This also makes me exposed to real-world cases where beating has been very useful... Alex. P.S. I am not implying that 32 bit counters is a bug. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 13:29:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from goofy.epylon.com (sf-gw.epylon.com [63.93.9.98]) by hub.freebsd.org (Postfix) with ESMTP id 089FE37B416 for ; Mon, 14 Jan 2002 13:29:43 -0800 (PST) Received: by goofy.epylon.lan with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 12:44:08 -0800 Message-ID: <657B20E93E93D4118F9700D0B73CE3EA02FFF373@goofy.epylon.lan> From: Jason DiCioccio To: "'freebsd-net@freebsd.org'" Subject: "VPN Server" with NT Domain authentication? Date: Mon, 14 Jan 2002 12:44:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to replace our current NT (PPTP) vpn with a FreeBSD VPN with minimal impact. Is there any way to run a PPTP server using mpd and have it authenticate against an NT domains (perhaps with PAM?). Or are there any other packages I can use that will do this? I am also open to using IPSec if I can find a method with IPSec to apply firewall rules to certain users based upon their credentials. mpd allows me to do this by assigning users a range of IPs, but if there are alternative implementations that I can use to get this done then I am open to hearing about them too :). I've been searching around and have been unable to find anything to let me do this. Thanks in advance, Jason DiCioccio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 20:30: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id C5DC537B404 for ; Mon, 14 Jan 2002 20:30:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA39745; Mon, 14 Jan 2002 20:21:02 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g0F4L1R10840; Mon, 14 Jan 2002 20:21:01 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200201150421.g0F4L1R10840@arch20m.dellroad.org> Subject: Re: "VPN Server" with NT Domain authentication? In-Reply-To: <657B20E93E93D4118F9700D0B73CE3EA02FFF373@goofy.epylon.lan> "from Jason DiCioccio at Jan 14, 2002 12:44:02 pm" To: Jason DiCioccio Date: Mon, 14 Jan 2002 20:21:01 -0800 (PST) Cc: "'freebsd-net@freebsd.org'" X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jason DiCioccio writes: > I'm trying to replace our current NT (PPTP) vpn with a FreeBSD VPN > with minimal impact. Is there any way to run a PPTP server using mpd and > have it authenticate against an NT domains (perhaps with PAM?). Or are > there any other packages I can use that will do this? Mpd doesn't support NT domain authentication. The best you could do is to copy everybody's passwords into the mpd.secrets file... not a great answer. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 22:37:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 6993C37B404 for ; Mon, 14 Jan 2002 22:37:29 -0800 (PST) Received: from dialup-209.245.141.91.dial1.sanjose1.level3.net ([209.245.141.91] helo=blossom.cjclark.org) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16QNDm-0007Wj-00; Mon, 14 Jan 2002 22:37:25 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0F6ap729657; Mon, 14 Jan 2002 22:36:51 -0800 (PST) (envelope-from cjc) Date: Mon, 14 Jan 2002 22:36:47 -0800 From: "Crist J . Clark" To: Kshitij Gunjikar Cc: freebsd-net@FreeBSD.ORG Subject: Re: DHCP and IP Input Message-ID: <20020114223647.B28767@blossom.cjclark.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 kshitijgunjikar@yahoo.com on Mon, Jan 14, 2002 at 06:44:07PM +0530 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jan 14, 2002 at 06:44:07PM +0530, Kshitij Gunjikar wrote: > Hi All, > I have one question? If we have a FreeBSD box configured as a router and > we are not supporting a DHCP like protocol then do we drop packets with > 0.0.0.0 source address? As per RFC 1812 we must. You need to run a BOOTP or DHCP service to do the forwarding. See bootpgw(8) which is in the base system or dhcrelay(8) is part of the DHCPD port. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 14 23:42:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19]) by hub.freebsd.org (Postfix) with ESMTP id 1D3BD37B417 for ; Mon, 14 Jan 2002 23:42:52 -0800 (PST) Received: from there (coffee.syncrontech.com [62.71.8.37]) by guinness.syncrontech.com (8.11.1/8.11.1) with SMTP id g0F7Xww91320; Tue, 15 Jan 2002 09:33:58 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-Id: <200201150733.g0F7Xww91320@guinness.syncrontech.com> Content-Type: text/plain; charset="iso-8859-1" From: Ari Suutari To: Rene de Vries , "Kshitij Gunjikar" Subject: Re: Filtering packets received through an ipsec tunnel Date: Tue, 15 Jan 2002 09:42:37 +0200 X-Mailer: KMail [version 1.3.2] Cc: net@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, On Monday 14 January 2002 19:55, Rene de Vries wrote: > Kshitij, > A good solution, from my point of view, would be, instead of passing > evering thing from an ipsec tunnel, using ip-filter (&co, but without > dummyet) on emerging packets. These packets should then have a different > interface or a special flag for easy testing in ip-filter (&co). > I don't know what the best solution would be, extending ip-filter with > an extra flag or adding a special (dummy) interface. My gut feeling is a > special flag makes more sense, but will break current ip-filter/ipfw > syntax/configurations. > This kind of flag might be easy to add to ipfw, I think. Currently, in ip_input there is: if (ipsec_gethist(m, NULL) goto pass; Maybe one could remove this, add 'ipsec' flag to ipfw (which would use the above ipsec_gethist to match it) so the syntax would be something like this: ipfw add pass tcp from a to b ipsec setup # matches only packets that came via ipsec stack ipfw add pass 50 from a to b # matches packets that didn't come via ipsec I think that this would be much cleaner than fake interfaces most implementations seem to use. Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 0:29: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by hub.freebsd.org (Postfix) with SMTP id 3F5D137B41D for ; Tue, 15 Jan 2002 00:28:57 -0800 (PST) Received: from unknown (HELO kshitij1) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jan 2002 08:28:55 -0000 From: "Kshitij Gunjikar" To: Subject: Filtering on the IPsec Tunnel Date: Tue, 15 Jan 2002 14:08:42 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, What I think is that we shouldn't send all packets to IPSec. This reduces the performance of the box as IPSec algorithms are really compute intensive. Only configured tunnels to a few locations can be IPSeced. This ensures that the normal traffic which is mostly TCP traffic can be as fast as possible. (Hey, We all complain when we see our mails being downloaded slowly or web pages being loaded slowly) Also, for generic security we can use the IP filter for normal traffic. The IPSec itself does authentication so why send it to a filter? Regards Kshitij _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 1: 5: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 8CA3737B400 for ; Tue, 15 Jan 2002 01:04:56 -0800 (PST) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 16QPYI-0005iB-00 for freebsd-net@freebsd.org; Tue, 15 Jan 2002 11:06:42 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 16QPYH-0005hu-00; Tue, 15 Jan 2002 11:06:41 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 16QPbm-0004Ng-00; Tue, 15 Jan 2002 11:10:18 +0200 Date: Tue, 15 Jan 2002 11:10:18 +0200 From: Barry Irwin To: Kshitij Gunjikar Cc: freebsd-net@freebsd.org Subject: Re: Filtering on the IPsec Tunnel Message-ID: <20020115111018.K5446@itouchlabs.com> 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 kshitijgunjikar@yahoo.com on Tue, Jan 15, 2002 at 02:08:42PM +0530 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 21953-1011085601-93607@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All I came across this problem a few months ago, and its mpact is actually greater than expected. I have ttached a patch below which I have been running on our production firewalls for 3 months now with no issues to speak of. The patch includes a sysctl to turn off the reinjection action. The problem is caused by rows 401-404 in ip_input.c (the particular version I am working with is from the RELENG_4_4. By my understanding, is the packet comming in was previously an IPSEC encapsulated, packet, the pass rule is hit, rather than the normal action of being re-injected into the stack, and subject to another pass through the ruleset. * $FreeBSD: src/sys/netinet/ip_input.c,v 1.130.2.25 2001/08/29 21:41:37 jesper Exp $ #ifdef IPSEC if (ipsec_gethist(m, NULL)) goto pass; #endif This action was NOT present in the 4.3 Release code, but ufortunately I have not had time to tract down exactly when it was introduced. The case where I came across the problem is that I have a Firewall performing NAT, and the resultant NAT packets are injected into an IPSEC tunnel to a business partner. The problem comes when a packet is received from the partner, and decapsulated, since it is not being re-injected into the stack, the ipfw/ipfilter rules cannot pick it up for further processing. Thus I was unable to get the packet passed onto the NATD for processing. What drew my attention to this (in addition to connections not working) was the fact that I was getting lots of traffic logged in vain on the firewall Nat address itself. The ports corresponded to the port used by the client system. The patch below introduces a sysctl net.inet.ip.ipsecinject, which wraps the offending lines of code with an if conditional. By default it skips these and the packet injection continues as normal. This was instituted so that a backout could be performed if I experienced problems ( the machines in question were sitting about 20 000km away :> ) I believe that the current implementation is incorrect as it stands. A better method in my opinion is to possibly do a comparison of the address in the packet following decapsulation, if the address is an address local to the system then it shoudl be re-injected. Although this still doesnt address the problem of one wanting to do filtering. Yes it does induce a slight performance hit, but I certainly do not want to trust the security of my network to that of my bsiness partners. How about a sysctl similar to net.inet.ip.fw.one_pass , which is on by default causing packets to be passed through the rules prior to, and that an informed administrator can explicityly turn off if he does not want this function. This problem is still present in the RELENG_4 branch being used for 4.5. * $FreeBSD: src/sys/netinet/ip_input.c,v 1.130.2.30 2001/12/14 20:08:22 jlemon Exp $ Although I dont think any changes will make it into 4.5 would be nice to get a commit in soon after release to fix this. Other thought I had is that the 'correct' place for the sysctl is probably under the ipsec tree, unfortunately I dont have a box handy to make the change on and run a test, so here is the patch anyway. Cheers Barry -- Barry Irwin Systems Administrator: Networks and Security Itouch Labs bvi@itouchlabs.com PATCH agains 4.4-SECURITY branch. bash-2.05# diff -u ip_input.c.orig ip_input.c --- ip_input.c.orig Sun Oct 28 20:25:38 2001 +++ ip_input.c Sun Oct 28 20:25:12 2001 @@ -129,6 +129,12 @@ &ip_maxfragpackets, 0, "Maximum number of IPv4 fragment reassembly queue entries"); +static int ip_ipsecinject = 1; +SYSCTL_INT(_net_inet_ip, OID_AUTO, ipsecinject, CTLFLAG_RW, + &ip_ipsecinject, 0, + "Enable IPSEC reinject to fw stack fixes NAT"); + + /* * XXX - Setting ip_checkinterface mostly implements the receive side of * the Strong ES model described in RFC 1122, but since the routing table @@ -399,8 +405,10 @@ } #ifdef IPSEC - if (ipsec_gethist(m, NULL)) - goto pass; + if (!ip_ipsecinject) { + if (ipsec_gethist(m, NULL)) + goto pass; + } #endif /* bash-2.05# To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 4:18:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id B1C0E37B416 for ; Tue, 15 Jan 2002 04:18:16 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0FCILJ27515; Tue, 15 Jan 2002 13:18:21 +0100 (CET) (envelope-from alexlh) Date: Tue, 15 Jan 2002 13:18:21 +0100 From: Alex Le Heux To: Ari Suutari Cc: Rene de Vries , Kshitij Gunjikar , net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020115121821.GU75815@funk.org> References: <200201150733.g0F7Xww91320@guinness.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201150733.g0F7Xww91320@guinness.syncrontech.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 15, 2002 at 09:42:37AM +0200, Ari Suutari wrote: > Hi, > > On Monday 14 January 2002 19:55, Rene de Vries wrote: > > Kshitij, > > A good solution, from my point of view, would be, instead of passing > > evering thing from an ipsec tunnel, using ip-filter (&co, but without > > dummyet) on emerging packets. These packets should then have a different > > interface or a special flag for easy testing in ip-filter (&co). > > I don't know what the best solution would be, extending ip-filter with > > an extra flag or adding a special (dummy) interface. My gut feeling is a > > special flag makes more sense, but will break current ip-filter/ipfw > > syntax/configurations. > > [snip] > Maybe one could remove this, add 'ipsec' flag to ipfw > (which would use the above ipsec_gethist to match it) > so the syntax would be something like this: > > ipfw add pass tcp from a to b ipsec setup # matches only packets that came > via ipsec stack > ipfw add pass 50 from a to b # matches packets that didn't come via ipsec [snip] This looks like it would work for most situations. What one would not be able to do this way is prevent spoofing. In an ideal world I would also want to filter packets that come from the wrong tunnel. That would require the ipfw rules to somehow identify the tunnel. I'm not entirely sure if this could be accomplished without major pain though. Regards, Alex Le Heux -- "The difference between men and boys is the speed of their toys..." - Motul ad in Motor Magazine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 4:32:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19]) by hub.freebsd.org (Postfix) with ESMTP id 787B737B419 for ; Tue, 15 Jan 2002 04:32:39 -0800 (PST) Received: from there (coffee.syncrontech.com [62.71.8.37]) by guinness.syncrontech.com (8.11.1/8.11.1) with SMTP id g0FCDbw92015; Tue, 15 Jan 2002 14:13:38 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-Id: <200201151213.g0FCDbw92015@guinness.syncrontech.com> Content-Type: text/plain; charset="iso-8859-1" From: Ari Suutari To: Alex Le Heux Subject: Re: Filtering packets received through an ipsec tunnel Date: Tue, 15 Jan 2002 14:22:17 +0200 X-Mailer: KMail [version 1.3.2] Cc: Rene de Vries , Kshitij Gunjikar , net@FreeBSD.ORG References: <200201150733.g0F7Xww91320@guinness.syncrontech.com> <20020115121821.GU75815@funk.org> In-Reply-To: <20020115121821.GU75815@funk.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, On Tuesday 15 January 2002 14:18, Alex Le Heux wrote: > > > Maybe one could remove this, add 'ipsec' flag to ipfw > > (which would use the above ipsec_gethist to match it) > > so the syntax would be something like this: > > > > ipfw add pass tcp from a to b ipsec setup # matches only packets that came > > via ipsec stack > > ipfw add pass 50 from a to b # matches packets that didn't come via ipsec > > [snip] > > This looks like it would work for most situations. > > What one would not be able to do this way is prevent spoofing. In an ideal > world I would also want to filter packets that come from the wrong tunnel. But doesn't ipsec stack already take care of this ? I think (hope) that is doesn't process the packet if it is coming from wrong tunnel because the packet does not match the policy. Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 4:34:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id 286BE37B419 for ; Tue, 15 Jan 2002 04:34:06 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0FCYTf27746; Tue, 15 Jan 2002 13:34:29 +0100 (CET) (envelope-from alexlh) Date: Tue, 15 Jan 2002 13:34:29 +0100 From: Alex Le Heux To: Ari Suutari Cc: Rene de Vries , Kshitij Gunjikar , net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020115123429.GV75815@funk.org> References: <200201150733.g0F7Xww91320@guinness.syncrontech.com> <20020115121821.GU75815@funk.org> <200201151213.g0FCDbw92015@guinness.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201151213.g0FCDbw92015@guinness.syncrontech.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 15, 2002 at 02:22:17PM +0200, Ari Suutari wrote: > Hi, > > On Tuesday 15 January 2002 14:18, Alex Le Heux wrote: > > > > > Maybe one could remove this, add 'ipsec' flag to ipfw > > > (which would use the above ipsec_gethist to match it) > > > so the syntax would be something like this: > > > > > > ipfw add pass tcp from a to b ipsec setup # matches only packets that > came > > > via ipsec stack > > > ipfw add pass 50 from a to b # matches packets that didn't come via ipsec > > > > [snip] > > > > This looks like it would work for most situations. > > > > What one would not be able to do this way is prevent spoofing. In an ideal > > world I would also want to filter packets that come from the wrong tunnel. > > But doesn't ipsec stack already take care of this ? I think (hope) > that is doesn't process the packet if it is coming from wrong tunnel > because the packet does not match the policy. I'm not sure if it actually drops 'wrong' packets coming from the tunnel. I'll see if I have some time soon to look into it. Regards, Alex Le Heux -- "Although the force from the engine is a lot for a motorcycle, the Earth is not impressed. The Motorcycle and I loose the 'F' and 'm' battle and have to consume all the 'a' in the form of sheer unadulterated acceleration." - Ian Orr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 7:39:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from r4k.net (r4k.net [194.109.74.241]) by hub.freebsd.org (Postfix) with ESMTP id A671637B416 for ; Tue, 15 Jan 2002 07:39:07 -0800 (PST) Received: (from alexlh@localhost) by r4k.net (8.11.3/8.11.1) id g0FFdP629568; Tue, 15 Jan 2002 16:39:25 +0100 (CET) (envelope-from alexlh) Date: Tue, 15 Jan 2002 16:39:25 +0100 From: Alex Le Heux To: Ari Suutari Cc: Rene de Vries , Kshitij Gunjikar , net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020115153925.GY75815@funk.org> References: <200201150733.g0F7Xww91320@guinness.syncrontech.com> <20020115121821.GU75815@funk.org> <200201151213.g0FCDbw92015@guinness.syncrontech.com> <20020115123429.GV75815@funk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115123429.GV75815@funk.org> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 15, 2002 at 01:34:29PM +0100, Alex Le Heux wrote: > > > > But doesn't ipsec stack already take care of this ? I think (hope) > > that is doesn't process the packet if it is coming from wrong tunnel > > because the packet does not match the policy. > > I'm not sure if it actually drops 'wrong' packets coming from the tunnel. > I'll see if I have some time soon to look into it. Sorry for replying to my own mail... It seems to do something like it, see sysctl net.inet.ipsec.def_policy in ipsec(4). It's not exactly the same though and certainly doesn't give very fine grained control. Although I can't really think of any situations that one can't cover this way. Regards, Alex Le Heux -- Happiness is a side effect of doing something that's got nothing to do with it, baby. - Bootsy Collins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 13:27:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id 9F22B37B400 for ; Tue, 15 Jan 2002 13:27:45 -0800 (PST) Received: from fwd05.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16Qb2e-00032U-03; Tue, 15 Jan 2002 22:22:48 +0100 Received: from frolic.no-support.loc (520094253176-0001@[80.130.206.106]) by fmrl05.sul.t-online.com with esmtp id 16Qb2O-146bxoC; Tue, 15 Jan 2002 22:22:32 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.6/8.9.3) id g0FLKvJ04945 for freebsd-net@FreeBSD.ORG; Tue, 15 Jan 2002 22:20:57 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Tue, 15 Jan 2002 22:20:56 +0100 To: freebsd-net@FreeBSD.ORG Subject: bridged interfaces don't see broadcasts Message-ID: <20020115212056.GA3520@frolic.no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.3.25i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, on a NIS and NFS serving machine I bridged two ethernet NICs: net.link.ether.bridge_cfg: vr0:0,ed1:0 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 vr0: flags=3D8943 mtu 1500 inet6 fe80::250:baff:fe23:df3%vr0 prefixlen 64 scopeid 0x1=20 inet 192.168.43.1 netmask 0xffffff00 broadcast 192.168.43.255 ether 00:50:ba:23:0d:f3=20 media: Ethernet autoselect (100baseTX ) status: active ed1: flags=3D8943 mtu 1500 inet6 fe80::24f:4cff:fe02:4a4c%ed1 prefixlen 64 scopeid 0x3=20 ether 00:4f:4c:02:4a:4c=20 ed1 is an old 10-Base2/10-Base-T. It seems that broadcasts (coming from the ed1 segment) are transmitted by the bridge to the vr0 segment (as it should be). But vr0 never sees any of these broadcast packets. That's why NIS does not work on any client that sits on the ed1 segment. As an experiment I enabled net.inet.icmp.bmcastecho on the server (192.168.43.1) and on some clients on both segments. When pinging 192.168.43.255 from a vr0 segment client everything is fine. When pinging from an ed1 segment client the response from 192.168.43.1 is always missing. -Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 14:20:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 712E437B402 for ; Tue, 15 Jan 2002 14:20:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020115222019.QOPN5944.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 15 Jan 2002 22:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA83204; Tue, 15 Jan 2002 14:07:37 -0800 (PST) Date: Tue, 15 Jan 2002 14:07:37 -0800 (PST) From: Julian Elischer To: Bjoern Fischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: bridged interfaces don't see broadcasts In-Reply-To: <20020115212056.GA3520@frolic.no-support.loc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What happens if you use netgraph bridging? (/usr/share/examples/netgraph) On Tue, 15 Jan 2002, Bjoern Fischer wrote: > Hello, >=20 > on a NIS and NFS serving machine I bridged two ethernet NICs: >=20 > net.link.ether.bridge_cfg: vr0:0,ed1:0 > net.link.ether.bridge: 1 > net.link.ether.bridge_ipfw: 0 > net.link.ether.bridge_ipfw_drop: 0 > net.link.ether.bridge_ipfw_collisions: 0 >=20 > vr0: flags=3D8943 mtu 150= 0 > inet6 fe80::250:baff:fe23:df3%vr0 prefixlen 64 scopeid 0x1=20 > inet 192.168.43.1 netmask 0xffffff00 broadcast 192.168.43.255 > ether 00:50:ba:23:0d:f3=20 > media: Ethernet autoselect (100baseTX ) > status: active > ed1: flags=3D8943 mtu 150= 0 > inet6 fe80::24f:4cff:fe02:4a4c%ed1 prefixlen 64 scopeid 0x3=20 > ether 00:4f:4c:02:4a:4c=20 >=20 > ed1 is an old 10-Base2/10-Base-T. >=20 > It seems that broadcasts (coming from the ed1 segment) are transmitted > by the bridge to the vr0 segment (as it should be). But vr0 never sees > any of these broadcast packets. That's why NIS does not work on any > client that sits on the ed1 segment. >=20 > As an experiment I enabled net.inet.icmp.bmcastecho on the server > (192.168.43.1) and on some clients on both segments. When pinging > 192.168.43.255 from a vr0 segment client everything is fine. When > pinging from an ed1 segment client the response from 192.168.43.1 > is always missing. >=20 > -Bj=F6rn >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 14:52:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id 1F50837B402 for ; Tue, 15 Jan 2002 14:52:48 -0800 (PST) Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16QcRe-0005M6-06; Tue, 15 Jan 2002 23:52:42 +0100 Received: from frolic.no-support.loc (520094253176-0001@[80.130.206.106]) by fmrl01.sul.t-online.com with esmtp id 16QcRV-1zDpnEC; Tue, 15 Jan 2002 23:52:33 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.6/8.9.3) id g0FMnXW06086; Tue, 15 Jan 2002 23:49:33 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Tue, 15 Jan 2002 23:49:33 +0100 To: Julian Elischer Cc: Bjoern Fischer , freebsd-net@FreeBSD.ORG Subject: Re: bridged interfaces don't see broadcasts Message-ID: <20020115224933.GB3520@frolic.no-support.loc> References: <20020115212056.GA3520@frolic.no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.3.25i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Julian, > What happens if you use netgraph bridging? > (/usr/share/examples/netgraph) I knew that you would advertise this ;-) Ok, since I'm already using netgraph for pppoe on the same machine, I tried netgraph bridging at first. But with netgraph bridging it was even worse: Not even the clients on the vr0 segment could reach the server via broadcast (192.168.43.255). All our production workstations are on this segment. All of them are diskless clients using DHCP, amd with NIS maps, NIS for user DBs; so that broadcast feature was heavily needed. With Luigi's bridging code at least the vr0 segment was working normally. Only the broadcast problem on the ed1 segment. I could live with that up till now. -Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 15: 0:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 9BCB337B404 for ; Tue, 15 Jan 2002 15:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020115230017.KCHC3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 15 Jan 2002 23:00:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA83371; Tue, 15 Jan 2002 14:58:06 -0800 (PST) Date: Tue, 15 Jan 2002 14:58:04 -0800 (PST) From: Julian Elischer To: Bjoern Fischer Cc: freebsd-net@FreeBSD.ORG Subject: Re: bridged interfaces don't see broadcasts In-Reply-To: <20020115224933.GB3520@frolic.no-support.loc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ok.. I'll see if I can come up with a way to hook multiple netgraph nodes to an ethernet node... (but since my daughter was born yesterday I'm a little deistracted at the moment :-) julian On Tue, 15 Jan 2002, Bjoern Fischer wrote: > Hello Julian, >=20 > > What happens if you use netgraph bridging? > > (/usr/share/examples/netgraph) >=20 > I knew that you would advertise this ;-) >=20 > Ok, since I'm already using netgraph for pppoe on the same machine, > I tried netgraph bridging at first. But with netgraph bridging it > was even worse: Not even the clients on the vr0 segment could reach > the server via broadcast (192.168.43.255). All our production > workstations are on this segment. All of them are diskless clients > using DHCP, amd with NIS maps, NIS for user DBs; so that broadcast > feature was heavily needed. >=20 > With Luigi's bridging code at least the vr0 segment was working > normally. Only the broadcast problem on the ed1 segment. I could > live with that up till now. >=20 > -Bj=F6rn >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 15:20:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7262C37B402 for ; Tue, 15 Jan 2002 15:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020115232008.SNHU5944.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 15 Jan 2002 23:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA83450; Tue, 15 Jan 2002 15:04:31 -0800 (PST) Date: Tue, 15 Jan 2002 15:04:29 -0800 (PST) From: Julian Elischer To: Bjoern Fischer Cc: freebsd-net@FreeBSD.ORG Subject: Brian: pppoe question. In-Reply-To: <20020115224933.GB3520@frolic.no-support.loc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brian, would it be possible to specify to ppp, an arbitrary node/hook on which to attach the pppoe node? (instead of, say, xl0: I'd want to hook to etf0:pppoehook (which may have been set up beforehand by a script) (maybe a 'hookname' variable that is "orphan" by default..) may also allow other types of tunnelling. Julian (if I had this I could probably do what Bjo:rn is looking for..) On Tue, 15 Jan 2002, Bjoern Fischer wrote: > Hello Julian, >=20 > > What happens if you use netgraph bridging? > > (/usr/share/examples/netgraph) >=20 > I knew that you would advertise this ;-) >=20 > Ok, since I'm already using netgraph for pppoe on the same machine, > I tried netgraph bridging at first. But with netgraph bridging it > was even worse: Not even the clients on the vr0 segment could reach > the server via broadcast (192.168.43.255). All our production > workstations are on this segment. All of them are diskless clients > using DHCP, amd with NIS maps, NIS for user DBs; so that broadcast > feature was heavily needed. >=20 > With Luigi's bridging code at least the vr0 segment was working > normally. Only the broadcast problem on the ed1 segment. I could > live with that up till now. >=20 > -Bj=F6rn >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 15:22:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id 05C3A37B402 for ; Tue, 15 Jan 2002 15:22:41 -0800 (PST) Received: from fwd09.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16Qcud-00070d-02; Wed, 16 Jan 2002 00:22:39 +0100 Received: from frolic.no-support.loc (520094253176-0001@[80.130.206.106]) by fmrl09.sul.t-online.com with esmtp id 16QcuX-0rTjiyC; Wed, 16 Jan 2002 00:22:33 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.6/8.9.3) id g0FNKTk08633; Wed, 16 Jan 2002 00:20:29 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Wed, 16 Jan 2002 00:20:29 +0100 To: Julian Elischer Cc: Bjoern Fischer , freebsd-net@FreeBSD.ORG Subject: Re: bridged interfaces don't see broadcasts Message-ID: <20020115232029.GC3520@frolic.no-support.loc> References: <20020115224933.GB3520@frolic.no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.3.25i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 15, 2002 at 02:58:04PM -0800, Julian Elischer wrote: > ok.. > I'll see if I can come up with a way to hook multiple netgraph nodes to an > ethernet node... Thank you. I don't know if it does matter, but neither ed1 nor vr0 is involved in pppoe, so the example in /usr/share/examples/netgraph/ether.bri= dge should be fully applicable. The pppoe interface is ed0, this is the node li= st when not using netgraph bridging: There are 7 total nodes: Name: ngctl8544 Type: socket ID: 00000007 Num hooks: 0 Name: Type: pppoe ID: 00000006 Num hooks: 2 Name: Type: socket ID: 00000005 Num hooks: 1 Name: vlan0 Type: ether ID: 00000004 Num hooks: 0 Name: ed1 Type: ether ID: 00000003 Num hooks: 0 Name: ed0 Type: ether ID: 00000002 Num hooks: 1 Name: vr0 Type: ether ID: 00000001 Num hooks: 0 > (but since my daughter was born yesterday I'm a little deistracted at the > moment :-) Conratulations and best wishes. Uh, no need to, umm, disrupt your distraction. ;-) -Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 15:26:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (artemis.drwilco.net [209.167.6.62]) by hub.freebsd.org (Postfix) with ESMTP id CB76737B400 for ; Tue, 15 Jan 2002 15:26:52 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g0FNQkR68790 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 15 Jan 2002 18:26:48 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020116003008.02a4d650@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jan 2002 00:35:58 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: bridged interfaces don't see broadcasts Cc: freebsd-net@freebsd.org In-Reply-To: References: <20020115224933.GB3520@frolic.no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org the 'all' mode on one2many maybe? Doc At 14:58 15-1-2002 -0800, you wrote: >ok.. >I'll see if I can come up with a way to hook multiple netgraph nodes to an >ethernet node... >(but since my daughter was born yesterday I'm a little deistracted at the >moment :-) > >julian > > >On Tue, 15 Jan 2002, Bjoern Fischer wrote: > > > Hello Julian, > > > > > What happens if you use netgraph bridging? > > > (/usr/share/examples/netgraph) > > > > I knew that you would advertise this ;-) > > > > Ok, since I'm already using netgraph for pppoe on the same machine, > > I tried netgraph bridging at first. But with netgraph bridging it > > was even worse: Not even the clients on the vr0 segment could reach > > the server via broadcast (192.168.43.255). All our production > > workstations are on this segment. All of them are diskless clients > > using DHCP, amd with NIS maps, NIS for user DBs; so that broadcast > > feature was heavily needed. > > > > With Luigi's bridging code at least the vr0 segment was working > > normally. Only the broadcast problem on the ed1 segment. I could > > live with that up till now. > > > > -Bj=F6rn > > > > > > >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 Jan 15 16: 0:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2F1BB37B41C for ; Tue, 15 Jan 2002 16:00:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020116000011.JWYG10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 16 Jan 2002 00:00:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA83629; Tue, 15 Jan 2002 15:55:46 -0800 (PST) Date: Tue, 15 Jan 2002 15:55:45 -0800 (PST) From: Julian Elischer To: "Rogier R. Mulhuijzen" Cc: freebsd-net@freebsd.org Subject: Re: bridged interfaces don't see broadcasts In-Reply-To: <5.1.0.14.0.20020116003008.02a4d650@mail.drwilco.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 2 points... 1/ apparent;y this should not be needed for bjo:rn's problem.. I'll have to check more.. 2/ it would be a little more complicated than to just use the one2many (though you may be able to do it if you just used 'broadcast' mode,=20 but the ethernet card needs to be set into promiscuous mode and the one2many node doesn't know how to pass that command through. (yet) On Wed, 16 Jan 2002, Rogier R. Mulhuijzen wrote: > the 'all' mode on one2many maybe? >=20 > Doc >=20 > At 14:58 15-1-2002 -0800, you wrote: > >ok.. > >I'll see if I can come up with a way to hook multiple netgraph nodes to = an > >ethernet node... > >(but since my daughter was born yesterday I'm a little deistracted at th= e > >moment :-) > > > >julian > > > > > >On Tue, 15 Jan 2002, Bjoern Fischer wrote: > > > > > Hello Julian, > > > > > > > What happens if you use netgraph bridging? > > > > (/usr/share/examples/netgraph) > > > > > > I knew that you would advertise this ;-) > > > > > > Ok, since I'm already using netgraph for pppoe on the same machine, > > > I tried netgraph bridging at first. But with netgraph bridging it > > > was even worse: Not even the clients on the vr0 segment could reach > > > the server via broadcast (192.168.43.255). All our production > > > workstations are on this segment. All of them are diskless clients > > > using DHCP, amd with NIS maps, NIS for user DBs; so that broadcast > > > feature was heavily needed. > > > > > > With Luigi's bridging code at least the vr0 segment was working > > > normally. Only the broadcast problem on the ed1 segment. I could > > > live with that up till now. > > > > > > -Bj=F6rn > > > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 15 17:27:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id C5DCC37B419 for ; Tue, 15 Jan 2002 17:27:37 -0800 (PST) Received: from fwd01.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16QerX-0004s2-00; Wed, 16 Jan 2002 02:27:35 +0100 Received: from frolic.no-support.loc (520094253176-0001@[80.130.206.106]) by fmrl01.sul.t-online.com with esmtp id 16QerW-27KVCCC; Wed, 16 Jan 2002 02:27:34 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.6/8.9.3) id g0G1OAn09492; Wed, 16 Jan 2002 02:24:10 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Wed, 16 Jan 2002 02:24:10 +0100 To: freebsd-net@FreeBSD.ORG Cc: Luigi Rizzo Subject: Re: bridged interfaces don't see broadcasts [update] Message-ID: <20020116012410.GA9286@frolic.no-support.loc> References: <20020115212056.GA3520@frolic.no-support.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020115212056.GA3520@frolic.no-support.loc> User-Agent: Mutt/1.3.25i X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Here an update. While Julian is looking for an netgraph solution, I looked into Luigi's bridging code. And found something, I believe: > net.link.ether.bridge_cfg: vr0:0,ed1:0 > net.link.ether.bridge: 1 > vr0: flags=3D8943 mtu 1500 > inet 192.168.43.1 netmask 0xffffff00 broadcast 192.168.43.255 > ether 00:50:ba:23:0d:f3=20 > ed1: flags=3D8943 mtu 1500 > ether 00:4f:4c:02:4a:4c=20 Watch for ed1, it is not ifconfiged i.e. has no ip address. I can see broadcasts from the vr0 segment on 192.168.43.1 but no broadcasts from the ed1 segment. I added some debug messages to bridge.c and if_ethersubr.c. I can see that broadcast packets coming from vr0 are properly passed to ether_demux() in if_ethersubr.c:ether_input() after going through the bridge forwarding code. Then as an experiment I ifconfiged ed1 although in bridge.c Luigi suggests to use only one ifconfiged interface per bridge cluster: ifconfig inet 192.168.43.2 netmask 0xffffff00 ed1 And that did it. Almost. Now I can see broadcasts from the ed1 segment on 192.168.43.2. Is this the way it should work? Or should a broadcast packet, that is bdg_forward()ed in ether_input() and therefore sent through vr0, also be passed to the upper network layer? Then one actually *must not* ifconfig more than one interface per bridge cluster or broadcasts will be received twice or even more often. Uh, ugly. There was an issue shortly on the list, a general "interface can't see it's own broadcast", I tried the patch but it didn't help. -Bj=F6rn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 16 4:16: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id 10E0537B405 for ; Wed, 16 Jan 2002 04:15:57 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id NAA15645 for ; Wed, 16 Jan 2002 13:15:54 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSP07S>; Wed, 16 Jan 2002 13:15:55 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: "'net@freebsd.org'" Subject: ICMP Redirect Date: Wed, 16 Jan 2002 13:15:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All I have some problems with ICMP Redirect. I'm using a FreeBSD-4.5-RC machine as default Rrouter for our network. If i'm doing a ping to an external host, a ICMP Redirect message is sended by the router-machine, but not only once... it is sended every time a ICMP echo-request is detected. The Host doesn't enter the route from the ICMP redirect into his table. With other Systems (ie RH Linux and CISCO Routers), this will work on this host correctly. Is there a posibility to switch on/off the ICMP redirect? How can i configure, which hosts to redirect? I saw the configs for sysctrl, but no way to enable or disable the sending of these packets. Du you have an idea? net.inet.icmp.drop_redirect = 0 net.inet.icmp.log_redirect = 1 Regards Reto Trachsel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 16 9:31:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe28.pav1.hotmail.com [64.4.30.85]) by hub.freebsd.org (Postfix) with ESMTP id E598037B404; Wed, 16 Jan 2002 09:31:29 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Jan 2002 09:31:29 -0800 X-Originating-IP: [216.95.234.92] From: "jack xiao" To: , Subject: pppd with radius Date: Wed, 16 Jan 2002 12:21:19 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C19E88.4D9F2220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 16 Jan 2002 17:31:29.0779 (UTC) FILETIME=[A2070C30:01C19EB3] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C19E88.4D9F2220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am using pppd for some application and also need radius function to = communicate with the remote radius server. In the FreeBSD man page of = pppd, I could not get anything about radius. As far as I know, in Linux = there are some radius patch for pppd, but in FreeBSD, I found nothing. = Does anybody has such experience or any idea.=20 Thanks in advance. Jack ------=_NextPart_000_008F_01C19E88.4D9F2220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am using pppd for some application = and also need=20 radius function to communicate with the remote radius server. In the = FreeBSD man=20 page of pppd, I could not get anything about radius. As far as I = know, in=20 Linux there are some radius patch for pppd, but in FreeBSD, I found = nothing.=20 Does anybody has such experience or any idea.
 
Thanks in advance.
 
Jack
------=_NextPart_000_008F_01C19E88.4D9F2220-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 16 15:57: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20204.mail.yahoo.com (web20204.mail.yahoo.com [216.136.226.59]) by hub.freebsd.org (Postfix) with SMTP id B054337B402 for ; Wed, 16 Jan 2002 15:56:55 -0800 (PST) Message-ID: <20020116235654.3630.qmail@web20204.mail.yahoo.com> Received: from [128.114.49.49] by web20204.mail.yahoo.com via HTTP; Wed, 16 Jan 2002 15:56:54 PST Date: Wed, 16 Jan 2002 15:56:54 -0800 (PST) From: radhika sinha Subject: urgent question regarding IP-in-IP encapsulation To: freebsd-hackers@FreeBSD.org Cc: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a question regarding Ip-in-IP encapsulation in freeBSD. In my implementation, I want a multicast router to encapsulate multicast packets destined for certain groups with an extra IP header before forwarding them out. I am giving below some of the code: if(IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { struct in_multi *inm; if(ip_mrouter){ 1) Check if the destination address belongs to the group of packets that need to be encapsulated 2)calls my encapsulation function which returns an MBUF with the extra header 3)The encapsulated packet is then sent to ip_mforward } For some reason this does not seem to be working correctly, I would appreciate if someone can point out the mistake I am making here. Thanks a lot, Radhika __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 16 17:44: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id D994D37B435 for ; Wed, 16 Jan 2002 17:43:15 -0800 (PST) Received: from dialup-209.244.107.170.dial1.sanjose1.level3.net ([209.244.107.170] helo=blossom.cjclark.org) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16R1a4-0003DA-00; Wed, 16 Jan 2002 17:43:09 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0H1I9n36977; Wed, 16 Jan 2002 17:18:09 -0800 (PST) (envelope-from cjc) Date: Wed, 16 Jan 2002 17:18:09 -0800 From: "Crist J . Clark" To: "Reto Trachsel (NetModule)" Cc: "'net@freebsd.org'" Subject: Re: ICMP Redirect Message-ID: <20020116171809.E35910@blossom.cjclark.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 reto.trachsel@netmodule.com on Wed, Jan 16, 2002 at 01:15:54PM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jan 16, 2002 at 01:15:54PM +0100, Reto Trachsel (NetModule) wrote: > Hi All > > I have some problems with ICMP Redirect. I'm using a FreeBSD-4.5-RC machine > as default Rrouter for our network. If i'm doing a ping to an external host, > a ICMP Redirect message is sended by the router-machine, but not only > once... it is sended every time a ICMP echo-request is detected. The Host > doesn't enter the route from the ICMP redirect into his table. With other > Systems (ie RH Linux and CISCO Routers), this will work on this host > correctly. I am a little unclear on this. Is "router-machine" the FreeBSD router in question? What kind of machine is "Host?" Are we trying to get "router-machine" to stop sending redirects? Or are we trying to get "Host" to accept and use the redirects? > Is there a posibility to switch on/off the ICMP redirect? How can i > configure, which hosts to redirect? You can turn sending/receiving redirects on and off with sysctl(8), but not on per-host basis. You could simulate this behavior to some degree using firewalling. > I saw the configs for sysctrl, but no way to enable or disable the sending > of these packets. Du you have an idea? > > net.inet.icmp.drop_redirect = 0 A machine will ignore incoming redirects. If you want "Host" to use the redirects, set this to one. > net.inet.icmp.log_redirect = 1 This logs the event. The other sysctl(8) you may be interested in is, net.inet.ip.redirect Which controls whether a router sends redirects. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 0:53:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by hub.freebsd.org (Postfix) with SMTP id 8F00F37B402 for ; Thu, 17 Jan 2002 00:53:48 -0800 (PST) Received: from unknown (HELO kshitij1) (203.124.128.243) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jan 2002 08:53:46 -0000 From: "Kshitij Gunjikar" To: Subject: RE: urgent question regarding IP-in-IP encapsulation Date: Thu, 17 Jan 2002 14:33:54 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020116235654.3630.qmail@web20204.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Radhika, It's not clear what is not working correctly. The encapsulation, the forwarding ? Also, please ensure that the interface you are forwarding to supports multicasting and you put the source address of the outgoing interface. Regards Kshitij -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org]On Behalf Of radhika sinha Sent: Thursday, January 17, 2002 5:27 AM To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: urgent question regarding IP-in-IP encapsulation Hi, I have a question regarding Ip-in-IP encapsulation in freeBSD. In my implementation, I want a multicast router to encapsulate multicast packets destined for certain groups with an extra IP header before forwarding them out. I am giving below some of the code: if(IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { struct in_multi *inm; if(ip_mrouter){ 1) Check if the destination address belongs to the group of packets that need to be encapsulated 2)calls my encapsulation function which returns an MBUF with the extra header 3)The encapsulated packet is then sent to ip_mforward } For some reason this does not seem to be working correctly, I would appreciate if someone can point out the mistake I am making here. Thanks a lot, Radhika __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 1:15:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id 6DB3A37B405 for ; Thu, 17 Jan 2002 01:15:13 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id KAA16034 for ; Thu, 17 Jan 2002 10:15:11 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSQA24>; Thu, 17 Jan 2002 10:15:12 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: "'net@freebsd.org'" Subject: RE: ICMP Redirect Date: Thu, 17 Jan 2002 10:15:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Crist Hi, i'll describe a little more in detail: "Router" FreeBSD-4.5-RC Machine, configured as Router with multiple aliases on a interface "WinHost" A Client machine with Windows 2000 "BSDHost" A FreeBSD-Current machine Sysctl settings on Router and BSDHost: net.inet.ip.redirect: 1 -> Sending ICMP Redirect net.inet.icmp.drop_redirect: 0 -> Does not drop net.inet.icmp.log_redirect: 1 -> Logging ICMP Redirect Problem Cases: BSDHost/WinHost and Router The Router send a ICMP Redirect, but not only once, every time a icmp packet is recived. The BSDHost doesn't add the routing table. BSDHost/WinHost and Linux or CISCO Router The Router (Linux/CISCO) send once a ICMP Redirect package. The Client add the route to his routing table. The client side work well. Is there a problem with ICMP Redirect on the same interface? Why doesn't accept the clients the ICMP Redirect? Regards Reto Trachsel -----Original Message----- From: Crist J . Clark [mailto:cjc@FreeBSD.ORG] Sent: Donnerstag, 17. Januar 2002 02:18 To: Reto Trachsel (NetModule) Cc: 'net@freebsd.org' Subject: Re: ICMP Redirect On Wed, Jan 16, 2002 at 01:15:54PM +0100, Reto Trachsel (NetModule) wrote: > Hi All > > I have some problems with ICMP Redirect. I'm using a FreeBSD-4.5-RC machine > as default Rrouter for our network. If i'm doing a ping to an external host, > a ICMP Redirect message is sended by the router-machine, but not only > once... it is sended every time a ICMP echo-request is detected. The Host > doesn't enter the route from the ICMP redirect into his table. With other > Systems (ie RH Linux and CISCO Routers), this will work on this host > correctly. I am a little unclear on this. Is "router-machine" the FreeBSD router in question? What kind of machine is "Host?" Are we trying to get "router-machine" to stop sending redirects? Or are we trying to get "Host" to accept and use the redirects? > Is there a posibility to switch on/off the ICMP redirect? How can i > configure, which hosts to redirect? You can turn sending/receiving redirects on and off with sysctl(8), but not on per-host basis. You could simulate this behavior to some degree using firewalling. > I saw the configs for sysctrl, but no way to enable or disable the sending > of these packets. Du you have an idea? > > net.inet.icmp.drop_redirect = 0 A machine will ignore incoming redirects. If you want "Host" to use the redirects, set this to one. > net.inet.icmp.log_redirect = 1 This logs the event. The other sysctl(8) you may be interested in is, net.inet.ip.redirect Which controls whether a router sends redirects. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 2:46:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 5DBF737B417 for ; Thu, 17 Jan 2002 02:46:46 -0800 (PST) Received: from dialup-209.244.107.170.dial1.sanjose1.level3.net ([209.244.107.170] helo=blossom.cjclark.org) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16RA4D-0001xm-00; Thu, 17 Jan 2002 02:46:45 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0HAkhM39151; Thu, 17 Jan 2002 02:46:43 -0800 (PST) (envelope-from cjc) Date: Thu, 17 Jan 2002 02:46:43 -0800 From: "Crist J . Clark" To: "Reto Trachsel (NetModule)" Cc: "'net@freebsd.org'" Subject: Re: ICMP Redirect Message-ID: <20020117024643.B38776@blossom.cjclark.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 reto.trachsel@netmodule.com on Thu, Jan 17, 2002 at 10:15:11AM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jan 17, 2002 at 10:15:11AM +0100, Reto Trachsel (NetModule) wrote: > Hi Crist > > Hi, i'll describe a little more in detail: > > "Router" FreeBSD-4.5-RC Machine, configured as Router with multiple > aliases on a interface > "WinHost" A Client machine with Windows 2000 > "BSDHost" A FreeBSD-Current machine > > Sysctl settings on Router and BSDHost: > > net.inet.ip.redirect: 1 -> Sending ICMP Redirect > net.inet.icmp.drop_redirect: 0 -> Does not drop > net.inet.icmp.log_redirect: 1 -> Logging ICMP Redirect > > Problem Cases: > > BSDHost/WinHost and Router > > The Router send a ICMP Redirect, but not only once, every time a icmp packet > is recived. The BSDHost doesn't add the routing table. Run, # tcpdump -vvXs 1500 'icmp' On BSDHost and show us the packet. Also show us, $ netstat -rn $ ifconfig -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 3: 3:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id 493B437B404 for ; Thu, 17 Jan 2002 03:03:03 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id MAA19015 for ; Thu, 17 Jan 2002 12:03:02 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSQALB>; Thu, 17 Jan 2002 12:03:03 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: "'net@freebsd.org'" Subject: RE: ICMP Redirect Date: Thu, 17 Jan 2002 12:03:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Crist Here the Logs and outputs for you Regards Reto # tcpdump -vvXs 1500 'icmp' 172.16.224.24 -> BSD Host 172.16.1.254 -> BSD Router 12:00:43.658869 172.16.1.254 > 172.16.224.24: icmp: redirect 172.24.0.2 to host 172.16.1.252 for 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id 2963 2, len 84) (ttl 64, id 12073, len 56) 0x0000 4500 0038 2f29 0000 4001 1165 ac10 01fe E..8/)..@..e.... 0x0010 ac10 e018 0501 f014 ac10 01fc 4500 0054 ............E..T 0x0020 73c0 0000 4001 cea5 ac10 e018 ac18 0002 s...@........... 0x0030 0800 8337 bba5 1600 ...7.... 12:00:44.668972 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id 29634 , len 84) 0x0000 4500 0054 73c2 0000 4001 cea3 ac10 e018 E..Ts...@....... 0x0010 ac18 0002 0800 5f10 bba5 1700 4bae 463c ......_.....K.F< 0x0020 475c 0200 0809 0a0b 0c0d 0e0f 1011 1213 G\.............. 0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050 3435 3637 4567 12:00:44.669009 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 63, id 29634 , len 84) 0x0000 4500 0054 73c2 0000 3f01 cfa3 ac10 e018 E..Ts...?....... 0x0010 ac18 0002 0800 5f10 bba5 1700 4bae 463c ......_.....K.F< 0x0020 475c 0200 0809 0a0b 0c0d 0e0f 1011 1213 G\.............. 0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050 3435 3637 4567 12:00:44.669034 172.16.1.254 > 172.16.224.24: icmp: redirect 172.24.0.2 to host 172.16.1.252 for 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id 2963 4, len 84) (ttl 64, id 12154, len 56) 0x0000 4500 0038 2f7a 0000 4001 1114 ac10 01fe E..8/z..@....... 0x0010 ac10 e018 0501 133c ac10 01fc 4500 0054 .......<....E..T 0x0020 73c2 0000 4001 cea3 ac10 e018 ac18 0002 s...@........... 0x0030 0800 5f10 bba5 1700 .._..... 12:00:44.755969 172.16.1.254 > 172.16.1.22: icmp: redirect 172.24.0.2 to host 17 2.16.1.252 for 172.16.1.22.139 > 172.24.0.2.1026: [|tcp] (DF) (ttl 128, id 53011 , len 1500) (DF) (ttl 64, id 12175, len 56) 0x0000 4500 0038 2f8f 4000 4001 b001 ac10 01fe E..8/.@.@....... 0x0010 ac10 0116 0501 2f26 ac10 01fc 4500 05dc ....../&....E... 0x0020 cf13 4000 8006 ccc7 ac10 0116 ac18 0002 ..@............. 0x0030 008b 0402 000b 1934 .......4 12:00:44.756062 172.16.1.254 > 172.16.1.22: icmp: redirect 172.24.0.2 to host 17 2.16.1.252 for 172.16.1.22.139 > 172.24.0.2.1026: [|tcp] (DF) (ttl 128, id 53267 , len 1500) (DF) (ttl 64, id 12176, len 56) 0x0000 4500 0038 2f90 4000 4001 b000 ac10 01fe E..8/.@.@....... 0x0010 ac10 0116 0501 2972 ac10 01fc 4500 05dc ......)r....E... 0x0020 d013 4000 8006 cbc7 ac10 0116 ac18 0002 ..@............. 0x0030 008b 0402 000b 1ee8 $ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.1 UGSc 2 263 fxp0 127.0.0.1 127.0.0.1 UH 1 2 lo0 139.79.35.95 172.16.1.2 UGHS 0 0 fxp0 139.79.35.195 172.16.1.2 UGHS 0 0 fxp0 139.79.35.201 172.16.1.2 UGHS 0 0 fxp0 139.79.69/24 172.16.1.2 UGSc 0 0 fxp0 172.16 link#1 UC 79 0 fxp0 172.16.1.1 0:2:b9:1d:27:20 UHLW 2 11978 fxp0 1181 172.16.1.2 0:10:7b:cc:49:2f UHLW 6 1642 fxp0 1166 ... a lot of different hosts loke the two above ... 172.17/24 link#2 UC 0 0 fxp1 => 172.17 172.17.10.250 UGSc 0 10326 fxp1 172.17.1/24 link#2 UC 0 0 fxp1 172.17.1.1 172.16.64.90 UGHS 0 0 fxp0 172.17.10/24 link#2 UC 1 0 fxp1 172.17.10.250 link#2 UHRLW 1 0 fxp1 7 172.18.1/24 link#2 UC 1 0 fxp1 172.18.1.52 0:e0:4c:39:a:36 UHLW 1 3 fxp1 1098 172.19 172.19.1.2 UGSc 1 83 fxp1 172.19.1/24 link#2 UC 1 0 fxp1 172.19.1.2 0:30:2b:0:28:84 UHLW 1 0 fxp1 1062 172.24 172.16.1.252 UGSc 0 10 fxp0 192.168.65.64/29 172.16.1.2 UGSc 0 0 fxp0 192.168.65.72/29 172.16.1.2 UGSc 0 0 fxp0 $ ifconfig fxp0: flags=8843 mtu 1500 inet 172.16.1.12 netmask 0xffff0000 broadcast 172.16.255.255 inet 172.16.1.11 netmask 0xffff0000 broadcast 172.16.255.255 inet 172.16.1.254 netmask 0xffff0000 broadcast 172.16.255.255 inet 172.16.1.10 netmask 0xffff0000 broadcast 172.16.255.255 ether 00:02:b3:86:12:38 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 mtu 1500 inet 172.18.1.10 netmask 0xffffff00 broadcast 172.18.1.255 inet 172.19.1.10 netmask 0xffffff00 broadcast 172.19.1.255 inet 172.17.10.10 netmask 0xffffff00 broadcast 172.17.10.255 inet 172.17.0.1 netmask 0xffffff00 broadcast 172.17.0.255 inet 172.17.1.10 netmask 0xffffff00 broadcast 172.17.1.255 ether 00:02:b3:86:12:39 media: Ethernet autoselect (100baseTX) status: active -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 6:18:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 0373037B41C for ; Thu, 17 Jan 2002 06:18:21 -0800 (PST) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g0HEIKh68602; Thu, 17 Jan 2002 08:18:20 -0600 (CST) (envelope-from tinguely) Date: Thu, 17 Jan 2002 08:18:20 -0600 (CST) From: mark tinguely Message-Id: <200201171418.g0HEIKh68602@web.cs.ndsu.nodak.edu> To: radsinha@yahoo.com Subject: Re: urgent question regarding IP-in-IP encapsulation Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have a question regarding Ip-in-IP encapsulation in > freeBSD. In my implementation, I want a multicast > router to encapsulate multicast packets destined for > certain groups with an extra IP header before > forwarding them out. What you describe is exactly a DVMRP tunnel. mrouted(8) performs this function and several other required tasks. Are you trying to do something beyond tunneling multicast over an IPv4 network, such as tunneling inside the DVMRP tunnel or PIM network? --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 6:59:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from blues.viagenie.qc.ca (blues.viagenie.qc.ca [206.123.31.135]) by hub.freebsd.org (Postfix) with ESMTP id E1B3D37B402 for ; Thu, 17 Jan 2002 06:59:39 -0800 (PST) Received: from blues.viagenie.qc.ca (blues-local [127.0.0.1]) by blues.viagenie.qc.ca (8.11.6/8.11.3) with ESMTP id g0HExiC02530 for ; Thu, 17 Jan 2002 09:59:44 -0500 (EST) (envelope-from Florent.Parent@viagenie.qc.ca) Date: Thu, 17 Jan 2002 09:59:37 -0500 From: Florent Parent To: freebsd-net@FreeBSD.ORG Subject: netgraph: how to setsockopt on ksocket node ? Message-ID: <31440000.1011279577@blues.viagenie.qc.ca> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-PGP-Fingerprint: B718 4543 977C BE73 2BCC 23D5 3E20 4FC9 2A90 872C MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anyone has an example on how to setsockopt on a ksocket node in netgraph? struct opts { int level; int name; int value; } myopts = { SOL_SOCKET, SO_REUSEADDR, 1 }; ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, (struct ng_ksocket_sockopt *)&myopts, sizeof(myopts))); return error 14 "Bad address". Did some tracing in ng_ksocket.c and the struct sockopt sent as argument to sosetopt() seems to contains sane values: sopt.sopt_val = 0xc182452c (pointer dereferences to 1) sopt.sopt_valsize = 4 Help appreciated. Thanks Florent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 9:39:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2328B37B420; Thu, 17 Jan 2002 09:39:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0HHdBK98436; Thu, 17 Jan 2002 09:39:11 -0800 (PST) (envelope-from rizzo) Date: Thu, 17 Jan 2002 09:39:11 -0800 From: Luigi Rizzo To: ipfw@freebsd.org Subject: dummynet byte counters Message-ID: <20020117093911.C98289@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, i got request from some people on how can i know how many bytes were used by a dummynet pipe -- essentially i guess for accounting reasons, or to export these values with mrtg as some people do, etc. For this to work you would need to count packets and bytes coming out of the queue. But at the moment, dummynet pipes only count packets and bytes _in_, plus packet drops. There are two ways to implement this feature (which i think is useful): + add to struct dn_flow_queue a counter for bytes dropped (and while we are at it, extend the packet drop counter to 64 bits). This has the problem of requiring a reinstallation of /sbin/ipfw because the size of structures passed with getsockopt changes; + use the tot_pkts/tot_bytes field to count traffic _out_ of the pipe instead of traffic going in. This way the size of dn_flow_queue does not change, but the meaning of these two fields changes; on the other hand, some people who wrote me already thought these field counted data out. For what is worth, the wording in /sbin/ipfw's output is sufficiently vague not to require any change in that program. Obviously I am not thinking of changing before 4.5 is released, but right after that it is definitely something to do. Any preference on the solution to use ? I see some good in both of them, and the second one is to some degree a bit more transparet than the first one. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 9:58:45 2002 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 568CC37B402 for ; Thu, 17 Jan 2002 09:58:28 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g0HHwQR15093 for ; Thu, 17 Jan 2002 18:58:26 +0100 (MET) Date: Thu, 17 Jan 2002 18:58:26 +0100 (CET) From: Harti Brandt To: net@freebsd.org Subject: interface creation notification Message-ID: <20020117185451.V97177-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, how is a daemon supposed to get informed that a network interface has been created? I had hoped, that an RTM_IFINFO message would be created on the routing socket, but this is not the case. If an interface is destroyed, the routing socket gets a message for whatever reason. Wouldn't it be simple to just create an RTM_IFINFO message? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 10: 2:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (artemis.drwilco.net [209.167.6.62]) by hub.freebsd.org (Postfix) with ESMTP id D141737B400 for ; Thu, 17 Jan 2002 10:02:43 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g0HI2MR29607 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 17 Jan 2002 13:02:24 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020117190855.01d15fb8@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Jan 2002 19:11:45 +0100 To: Florent Parent From: "Rogier R. Mulhuijzen" Subject: Re: netgraph: how to setsockopt on ksocket node ? Cc: freebsd-net@freebsd.org In-Reply-To: <31440000.1011279577@blues.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, > (struct ng_ksocket_sockopt *)&myopts, > sizeof(myopts))); > >return error 14 "Bad address". Could it be that your path to the node is not correct? (missing a : maybe...?) Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 10:36:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from blues.viagenie.qc.ca (blues.viagenie.qc.ca [206.123.31.135]) by hub.freebsd.org (Postfix) with ESMTP id 1422B37B421 for ; Thu, 17 Jan 2002 10:36:53 -0800 (PST) Received: from blues.viagenie.qc.ca (blues-local [127.0.0.1]) by blues.viagenie.qc.ca (8.11.6/8.11.3) with ESMTP id g0HIatC02870 for ; Thu, 17 Jan 2002 13:36:55 -0500 (EST) (envelope-from Florent.Parent@viagenie.qc.ca) Date: Thu, 17 Jan 2002 13:36:52 -0500 From: Florent Parent To: freebsd-net@freebsd.org Subject: Re: netgraph: how to setsockopt on ksocket node ? Message-ID: <96000000.1011292612@blues.viagenie.qc.ca> In-Reply-To: <5.1.0.14.0.20020117190855.01d15fb8@mail.drwilco.net> References: <5.1.0.14.0.20020117190855.01d15fb8@mail.drwilco.net> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-PGP-Fingerprint: B718 4543 977C BE73 2BCC 23D5 3E20 4FC9 2A90 872C MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --On 2002-01-17 19:11:45 +0100 drwilco@drwilco.net wrote: > >> ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, >> (struct ng_ksocket_sockopt *)&myopts, >> sizeof(myopts))); >> >> return error 14 "Bad address". > > Could it be that your path to the node is not correct? (missing a : > maybe...?) > > Doc No. I'm able to CONNECT and BIND on that same path. I'm able to trace to call to the ng_ksocket module so it is going to the correct path. Florent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 11:51:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 710E737B404 for ; Thu, 17 Jan 2002 11:51:26 -0800 (PST) Received: from keg (ras32.isi.edu [128.9.176.132]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0HJpMN21336 for ; Thu, 17 Jan 2002 11:51:23 -0800 (PST) Reply-To: From: "Lars Eggert" To: Subject: which 802.11b card for 4.4? Date: Thu, 17 Jan 2002 11:51:21 -0800 Organization: USC Information Sciences Institute Message-ID: <005a01c19f90$57bf5af0$8f7ba8c0@keg> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 MIME-Version: 1.0 Importance: Normal Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01C19F4D.45855A30" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C19F4D.45855A30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, we're looking to buy a bunch of 802.11b cards that need to work under FreeBSD-4.4 (soon 4.5) with 128bit WEP and Cisco access points (which are not under our direct administration). The cheapest right now seems to be the "Netgear MA401NA 802.11b Wireless PC Card" ($49 at Outpost.com) - but people reported problems with it. Have these been resolved? Another cheap cards are the "D-Link DWL-650 WirelessLAN 802.11b PC Card" ($59 at computers4sure.com). Anyone have experiences with these? Are there any others you'd recommend? (Ideally, we'd buy Cisco cards, but since we're a .edu, saving a few bucks is good... :-) Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_0055_01C19F4D.45855A30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDWjCCA1YCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIVMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDExNzE5NTExN1owIwYJ KoZIhvcNAQkEMRYEFOs7rmrBkkZ4pjaBB+QuyIzVcqDvMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG CCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYA1RR92uTIi9HpzxYvwTOOAyJZXZa+p HchlfljefNYR2W5L58FV0POdmbxoZ7dVD9/LJ/6evuKqUnlMjgSezLh/EFa0tygv5g5IKrl42L1b jULwuHk6QtFgBaPHYgKPmWCR+QCdZ0Vn9hnjF5wx9t58rwBJZyktiVa0yy2bdRTqsAAAAAAAAA== ------=_NextPart_000_0055_01C19F4D.45855A30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 12: 1:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id CB7EF37B405 for ; Thu, 17 Jan 2002 12:01:40 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id g0HK1db04890; Thu, 17 Jan 2002 12:01:39 -0800 Date: Thu, 17 Jan 2002 12:01:39 -0800 From: Brooks Davis To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Re: which 802.11b card for 4.4? Message-ID: <20020117120139.A4391@Odin.AC.HMC.Edu> References: <005a01c19f90$57bf5af0$8f7ba8c0@keg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005a01c19f90$57bf5af0$8f7ba8c0@keg>; from larse@ISI.EDU on Thu, Jan 17, 2002 at 11:51:21AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2002 at 11:51:21AM -0800, Lars Eggert wrote: > we're looking to buy a bunch of 802.11b cards that need to work under > FreeBSD-4.4 (soon 4.5) with 128bit WEP and Cisco access points (which > are not under our direct administration). >=20 > The cheapest right now seems to be the "Netgear MA401NA 802.11b Wireless > PC Card" ($49 at Outpost.com) - but people reported problems with it. > Have these been resolved? >=20 > Another cheap cards are the "D-Link DWL-650 WirelessLAN 802.11b PC Card" > ($59 at computers4sure.com). Anyone have experiences with these? >=20 > Are there any others you'd recommend? (Ideally, we'd buy Cisco cards, > but since we're a .edu, saving a few bucks is good... :-) The Lucent cards are generally superior to the various Prism II designs. You can get gold cards for $87 on pricewatch. That's more then the cheap stuff, but quite a bit less then the $130 I've heard as the best prices for Ciscos. I'd certaintly suggest you pick up one of anything you're considering before you buy a bunch with possiable exception of Lucent or Cisco cards. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Ry2jXY6L6fI4GtQRAtdMAKCoJf1jc0+8ChLCO4jkJPl8pJ722ACfRCni JfDOQEGbFtzlfPXuNDTg6PU= =t6H2 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 12:20:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id AE54037B416 for ; Thu, 17 Jan 2002 12:20:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020117202019.HAPR5944.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 17 Jan 2002 20:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA92794; Thu, 17 Jan 2002 12:18:42 -0800 (PST) Date: Thu, 17 Jan 2002 12:18:42 -0800 (PST) From: Julian Elischer To: Florent Parent Cc: freebsd-net@freebsd.org Subject: Re: netgraph: how to setsockopt on ksocket node ? In-Reply-To: <96000000.1011292612@blues.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org archie is Mr ksocket. On Thu, 17 Jan 2002, Florent Parent wrote: > > > --On 2002-01-17 19:11:45 +0100 drwilco@drwilco.net wrote: > > > > >> ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, > >> (struct ng_ksocket_sockopt *)&myopts, > >> sizeof(myopts))); > >> > >> return error 14 "Bad address". > > > > Could it be that your path to the node is not correct? (missing a : > > maybe...?) > > > > Doc > > No. I'm able to CONNECT and BIND on that same path. I'm able to trace to > call to the ng_ksocket module so it is going to the correct path. > > Florent. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 17:32:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from samuel.interplex.ca (abi.ca [216.18.127.185]) by hub.freebsd.org (Postfix) with ESMTP id B24BD37B419 for ; Thu, 17 Jan 2002 17:32:10 -0800 (PST) Received: from interplex.ca (smart-x.ctlc.interplex.ca [209.71.202.73]) by samuel.interplex.ca (8.11.3/8.11.3) with ESMTP id g0I1YP668744 for ; Thu, 17 Jan 2002 20:34:25 -0500 (EST) (envelope-from db@interplex.ca) Message-ID: <3C477BD4.50001@interplex.ca> Date: Thu, 17 Jan 2002 20:35:16 -0500 From: Dominic Blais User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020111 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPNAT -- Can't send file thru it with any instant messengers..... Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! I'm using IPNAT in order to split many local IPs over 5 external IPs. I can receive ICQ or MSN file transfers but I can't send any of those thru the NAT.... I have a friend which uses natd and he can send/receive files without any problems.... So.. I'm just wondering what's the big difference between natd and ipnat and can I send files with ICQ or MSN thru a NAT that uses IPNAT ??? Answer me on my email address please... or CC it... Thanks a lot! -- Dominic Blais Administrateur reseau Interplex telecom -=[ http://www.interplex.ca ]=- Email: db@interplex.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jan 17 18:30: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 109C337B400 for ; Thu, 17 Jan 2002 18:30:06 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA61968; Thu, 17 Jan 2002 18:16:09 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g0I2G8k23055; Thu, 17 Jan 2002 18:16:08 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200201180216.g0I2G8k23055@arch20m.dellroad.org> Subject: Re: netgraph: how to setsockopt on ksocket node ? In-Reply-To: <31440000.1011279577@blues.viagenie.qc.ca> "from Florent Parent at Jan 17, 2002 09:59:37 am" To: Florent Parent Date: Thu, 17 Jan 2002 18:16:08 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Florent Parent writes: > Anyone has an example on how to setsockopt on a ksocket node in netgraph? > > struct opts { > int level; > int name; > int value; > } myopts = { SOL_SOCKET, SO_REUSEADDR, 1 > }; > > ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, > (struct ng_ksocket_sockopt *)&myopts, > sizeof(myopts))); > > return error 14 "Bad address". > > Did some tracing in ng_ksocket.c and the struct sockopt sent as argument to > sosetopt() seems to contains sane values: > > sopt.sopt_val = 0xc182452c (pointer dereferences to 1) > sopt.sopt_valsize = 4 What kind of socket? What version of FreeBSD? That should work.. if the error is coming from the sosetopt() call then it's a socket problem rather than a netgraph problem. What if you create the socket normally and call setsockopt()? Cheers, -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 Thu Jan 17 19:58:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from blues.viagenie.qc.ca (modemcable114.39-130-66.mtl.mc.videotron.ca [66.130.39.114]) by hub.freebsd.org (Postfix) with ESMTP id 4553137B405 for ; Thu, 17 Jan 2002 19:58:30 -0800 (PST) Received: from blues.viagenie.qc.ca (blues-local [127.0.0.1]) by blues.viagenie.qc.ca (8.11.6/8.11.3) with ESMTP id g0I3wTC06695; Thu, 17 Jan 2002 22:58:29 -0500 (EST) (envelope-from Florent.Parent@viagenie.qc.ca) Date: Thu, 17 Jan 2002 22:58:22 -0500 From: Florent Parent To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: netgraph: how to setsockopt on ksocket node ? Message-ID: <214190000.1011326302@blues.viagenie.qc.ca> In-Reply-To: <200201180216.g0I2G8k23055@arch20m.dellroad.org> References: <200201180216.g0I2G8k23055@arch20m.dellroad.org> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-PGP-Fingerprint: B718 4543 977C BE73 2BCC 23D5 3E20 4FC9 2A90 872C MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========2018479384==========" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --==========2018479384========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline --On 2002-01-17 18:16:08 -0800 archie@dellroad.org wrote: > Florent Parent writes: >> Anyone has an example on how to setsockopt on a ksocket node in netgraph? >> >> struct opts { >> int level; >> int name; >> int value; >> } myopts = { SOL_SOCKET, SO_REUSEADDR, 1 >> }; >> >> ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, >> (struct ng_ksocket_sockopt *)&myopts, >> sizeof(myopts))); >> >> return error 14 "Bad address". >> >> Did some tracing in ng_ksocket.c and the struct sockopt sent as argument >> to sosetopt() seems to contains sane values: >> >> sopt.sopt_val = 0xc182452c (pointer dereferences to 1) >> sopt.sopt_valsize = 4 > > What kind of socket? UDP > > What version of FreeBSD? 4.5-PRERELEASE (~ 2 weeks old) > That should work.. if the error is coming from the sosetopt() > call then it's a socket problem rather than a netgraph problem. > > What if you create the socket normally and call setsockopt()? Well that works just fine. I've attached normal.c which is a dummy example using standard socket calls, and I've attached netgraph.c which wants to do the same thing using a ksocket node. The latter fails with the following debug: netgraph: SENDING MESSAGE: netgraph: SOCKADDR: { fam=32 len=9 addr=".dummy" } netgraph: NG_MESG : netgraph: vers 2 netgraph: arglen 12 netgraph: flags 0 netgraph: token 3 netgraph: cookie KSOCKET (942710669) netgraph: cmd 7 netgraph: args (12 bytes) netgraph: 0000: ff ff 00 00 00 02 00 00 01 00 00 00 ............ netgraph: sendto(.dummy): Bad address .dummy Cannot setopt the ksocket node: Bad address It has to be the way I'm presenting the socket options arguments through the netgraph interface. This is why I originally asked for any example on doing a setsockopt through netgraph. Thanks for the help Florent. --==========2018479384========== Content-Type: application/octet-stream; name="netgraph.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="netgraph.c"; size=2265 CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzdGRsaWIu aD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8bmV0aW5ldC9pbi5oPgojaW5jbHVk ZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8YXJwYS9pbmV0Lmg+CiNpbmNsdWRlIDxlcnJuby5o PgoKI2luY2x1ZGUgPG5ldGdyYXBoLmg+CiNpbmNsdWRlIDxuZXRncmFwaC9uZ19tZXNzYWdlLmg+ CiNpbmNsdWRlIDxuZXRncmFwaC9uZ19rc29ja2V0Lmg+CgojZGVmaW5lIERFQlVHCgojZGVmaW5l IFNFUlZBRERSICIxOTIuMTY4LjMxLjIiIAojZGVmaW5lIFNFUlZfUE9SVCAyMDAyICAKCmludCBt YWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewogICAgaW50IGNzLCBkczsKICAgIGludCByZXQ7 CiAgICBzdHJ1Y3QgbmdtX21rcGVlciBrc29jazsKICAgIHN0cnVjdCBzb2NrYWRkcl9pbiBzaW47 CiAgICBjaGFyIGVwYXRoWzEyOF07CgogICAgc3RydWN0IG9wdHMgewogICAgICAgIGludCBsZXZl bDsKICAgICAgICBpbnQgbmFtZTsKICAgICAgICBpbnQgdmFsdWU7CiAgICB9IG15b3B0czsKCiAg ICBteW9wdHMubGV2ZWwgPSBTT0xfU09DS0VUOwogICAgbXlvcHRzLm5hbWUgID0gU09fUkVVU0VQ T1JUOwogICAgbXlvcHRzLnZhbHVlID0gMTsKICAgIAogICAgICAvKiBDcmVhdGUgYSBzb2NrZXQg bm9kZSAqLwogICAgaWYgKE5nTWtTb2NrTm9kZShOVUxMLCAmY3MsICZkcykgPT0gLTEpIHsKICAg ICAgICBwZXJyb3IoIkNhbm5vdCBjcmVhdGUgbmV0Z3JhcGggc29ja2V0IG5vZGUiKTsKICAgICAg ICByZXR1cm4gLTE7CiAgICB9CiAgICBzcHJpbnRmKGVwYXRoLCAiLiIpOwogICAgc25wcmludGYo a3NvY2sudHlwZSwgc2l6ZW9mIChrc29jay50eXBlKSwgIiVzIiwgTkdfS1NPQ0tFVF9OT0RFX1RZ UEUpOwogICAgc25wcmludGYoa3NvY2sub3VyaG9vaywgc2l6ZW9mIChrc29jay5vdXJob29rKSwg IiVzIiwgImR1bW15Iik7CiAgICBzbnByaW50Zihrc29jay5wZWVyaG9vaywgc2l6ZW9mIChrc29j ay5wZWVyaG9vayksICIlcyIsICJpbmV0L2RncmFtL3VkcCIpOwoKICAgIGlmICggKHJldCA9IE5n U2VuZE1zZyhjcywgZXBhdGgsIE5HTV9HRU5FUklDX0NPT0tJRSwgTkdNX01LUEVFUiwgJmtzb2Nr LCBzaXplb2Yga3NvY2spKSA8IDApIHsKICAgICAgZnByaW50ZihzdGRlcnIsICIlcyBDYW5ub3Qg Y3JlYXRlIGFuIGtzb2NrZXQgbm9kZTogJXNcbiIsCiAgICAgICAgICAgICAgZXBhdGgsIHN0cmVy cm9yKGVycm5vKSk7CiAgICAgIGV4aXQoLTEpOwogICAgfQogICAgCiNpZmRlZiBERUJVRwogICAg TmdTZXREZWJ1ZygyKTsKI2VuZGlmCiAgICAKICAgIHNwcmludGYoZXBhdGgsICIuJXMiLCBrc29j ay5vdXJob29rKTsKICAgIAogICAgaWYgKCAocmV0ID0gTmdTZW5kTXNnKGNzLCBlcGF0aCwgTkdN X0tTT0NLRVRfQ09PS0lFLCBOR01fS1NPQ0tFVF9TRVRPUFQsCiAgICAgICAgICAgICAgICAgICAg ICAgICAgKHN0cnVjdCBuZ19rc29ja2V0X3NvY2tvcHQgKikmbXlvcHRzLCBzaXplb2YobXlvcHRz KSkpIDwgMCkgewogICAgICAgIGZwcmludGYoc3RkZXJyLCAiJXMgQ2Fubm90IHNldG9wdCB0aGUg a3NvY2tldCBub2RlOiAlc1xuIiwKICAgICAgICAgICAgICAgIGVwYXRoLCBzdHJlcnJvcihlcnJu bykpOwovLyAgICAgICAgZXhpdCAoLTEpOwogICAgfQogCiAgICAKICAgICAgICAvKiBCaW5kIHRo ZSBrc29ja2V0IHRvIG91ciBJUHY0IGFkZHJlc3MgYW5kIG91ciBVRFAgc291cmNlIHBvcnQgKi8K ICAgIGJ6ZXJvKCZzaW4sIHNpemVvZihzaW4pKTsKICAgIHNpbi5zaW5fbGVuID0gc2l6ZW9mKHNp bik7CiAgICBzaW4uc2luX2ZhbWlseSA9IEFGX0lORVQ7CiAgICBzaW4uc2luX3BvcnQgPSBodG9u cyhTRVJWX1BPUlQpOwogICAgaW5ldF9wdG9uKEFGX0lORVQsIFNFUlZBRERSLCAmc2luLnNpbl9h ZGRyKTsKCiAgICBpZiAoIChyZXQgPSBOZ1NlbmRNc2coY3MsIGVwYXRoLCBOR01fS1NPQ0tFVF9D T09LSUUsIE5HTV9LU09DS0VUX0JJTkQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0cnVj dCBzb2NrYWRkciAqKSZzaW4sIHNpemVvZihzaW4pKSkgPCAwKSB7CiAgICAgICAgZnByaW50Zihz dGRlcnIsICIlcyBDYW5ub3QgYmluZCB0aGUga3NvY2tldCBub2RlOiAlc1xuIiwKICAgICAgICAg ICAgICAgIGVwYXRoLCBzdHJlcnJvcihlcnJubykpOwogICAgICAgIGV4aXQgKC0xKTsKICAgIH0K ICAgIAogICAgZ2V0Y2hhcigpOwogICAgCiAgICBleGl0ICgwKTsKfQoK --==========2018479384========== Content-Type: application/octet-stream; name="normal.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="normal.c"; size=909 CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CiNpbmNsdWRlIDxzeXMvdHlw ZXMuaD4KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2lu Y2x1ZGUgPGFycGEvaW5ldC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KCgojZGVmaW5lIFNFUlZBRERS ICIxOTIuMTY4LjMxLjIiIAojZGVmaW5lIFNFUlZfUE9SVCAyMDAyICAKCmludCBtYWluKGludCBh cmdjLCBjaGFyICoqYXJndikKewogICAgaW50IHNvY2tmZDsKICAgIHN0cnVjdCBzb2NrYWRkcl9p biBzZXJ2YWRkcjsgCiAgICBjb25zdCBpbnQgb24gPSAxOwogICAgCiAgICBiemVybygmc2VydmFk ZHIsIHNpemVvZihzZXJ2YWRkcikpOwogICAgc2VydmFkZHIuc2luX2ZhbWlseSA9IEFGX0lORVQ7 CiAgICBzZXJ2YWRkci5zaW5fcG9ydCA9IGh0b25zKFNFUlZfUE9SVCk7CiAgICBpbmV0X3B0b24o QUZfSU5FVCwgU0VSVkFERFIsICZzZXJ2YWRkci5zaW5fYWRkcik7CiAgICAKICAgIHNvY2tmZCA9 IHNvY2tldChBRl9JTkVULCBTT0NLX0RHUkFNLCAwKTsKICAgIGlmIChzb2NrZmQgPT0gLTEpIHsK ICAgICAgICBwZXJyb3IoInNvY2tldCIpOwogICAgICAgIGV4aXQoMSk7CiAgICB9CiAgICBpZiAo c2V0c29ja29wdChzb2NrZmQsIFNPTF9TT0NLRVQsIFNPX1JFVVNFUE9SVCwgJm9uLCBzaXplb2Yo b24pKSA9PSAtMSkgewogICAgICAgIHBlcnJvcigic29ja29wdCIpOwogICAgICAgIGV4aXQoMSk7 CiAgICB9CiAgICBpZiAoYmluZChzb2NrZmQsIChzdHJ1Y3Qgc29ja2FkZHIgKikgJnNlcnZhZGRy LCBzaXplb2Yoc2VydmFkZHIpKSA9PSAtMSkgewogICAgICAgIHBlcnJvcigiYmluZCIpOwogICAg ICAgIGV4aXQoMSk7CiAgICB9CiAgICBnZXRjaGFyKCk7CiAgICBleGl0KDApOwogICAgCn0K --==========2018479384==========-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 0:20:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 29C9D37B41A for ; Fri, 18 Jan 2002 00:20:03 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0I8K1019644 for freebsd-net@FreeBSD.ORG; Fri, 18 Jan 2002 09:20:01 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0HMstE01376 for freebsd-net@FreeBSD.ORG; Thu, 17 Jan 2002 23:54:55 +0100 (CET) (envelope-from andreas) Date: Thu, 17 Jan 2002 23:54:55 +0100 From: Andreas Klemm To: freebsd-net@FreeBSD.ORG Subject: Re: FIREWALL_FORWARD vs. using /sbin/natd ? Message-ID: <20020117225455.GA1340@titan.klemm.gtn.com> References: <20020113105636.GA88221@titan.klemm.gtn.com> <20020113232541.E24290@blossom.cjclark.org> <20020114084023.GB1929@titan.klemm.gtn.com> <20020114011939.G24290@blossom.cjclark.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20020114011939.G24290@blossom.cjclark.org> User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 14, 2002 at 01:19:39AM -0800, Crist J . Clark wrote: > On Mon, Jan 14, 2002 at 09:40:23AM +0100, Andreas Klemm wrote: > > On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote: > > > On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote: >=20 > It is also there for any machine on his 192.168.1.0/24 internal > network to communicate with machines out on the Internet, and it is > running on the _external_ interface (fxp0) not the internal one. You are right, on the external. Don't know why I mixed it, sorry. > > > Yes, but nothing to do with NAT. > >=20 > > BUT WHAT does FIREWALL_FORWARD actually does ???? >=20 > Look for 'fwd' in ipfw(8). O.k., thanks. Andreas /// --=20 Andreas Klemm - Powered by FreeBSD Need a magic printfilter today ? http://www.apsfilter.org/ Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8R1Y+d3o+lGxvbLoRAvrdAKCw9MneTnNETMcfyJToTG0I0RjUNwCePnNf 5kLuIgp/I0v7/yCJ5TeZKMs= =BkUG -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 0:52:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id F2DF937B419 for ; Fri, 18 Jan 2002 00:52:07 -0800 (PST) Received: from dialup-209.244.107.191.dial1.sanjose1.level3.net ([209.244.107.191] helo=blossom.cjclark.org) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16RUkf-00005t-00; Fri, 18 Jan 2002 00:52:02 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0I8p8442602; Fri, 18 Jan 2002 00:51:08 -0800 (PST) (envelope-from cjc) Date: Fri, 18 Jan 2002 00:51:07 -0800 From: "Crist J . Clark" To: "Reto Trachsel (NetModule)" Cc: "'net@freebsd.org'" Subject: Re: ICMP Redirect Message-ID: <20020118005107.E40472@blossom.cjclark.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 reto.trachsel@netmodule.com on Thu, Jan 17, 2002 at 12:03:02PM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jan 17, 2002 at 12:03:02PM +0100, Reto Trachsel (NetModule) wrote: > Hi Crist > > Here the Logs and outputs for you > > Regards > Reto > > # tcpdump -vvXs 1500 'icmp' > > 172.16.224.24 -> BSD Host > 172.16.1.254 -> BSD Router > > 12:00:43.658869 172.16.1.254 > 172.16.224.24: icmp: redirect 172.24.0.2 to > host > 172.16.1.252 for 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id > 2963 > 2, len 84) (ttl 64, id 12073, len 56) Ouch. Severe line-wrap damage. > 0x0000 4500 0038 2f29 0000 4001 1165 ac10 01fe E..8/)..@..e.... > 0x0010 ac10 e018 0501 f014 ac10 01fc 4500 0054 ............E..T > 0x0020 73c0 0000 4001 cea5 ac10 e018 ac18 0002 s...@........... > 0x0030 0800 8337 bba5 1600 ...7.... > 12:00:44.668972 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id > 29634 > , len 84) > 0x0000 4500 0054 73c2 0000 4001 cea3 ac10 e018 E..Ts...@....... > 0x0010 ac18 0002 0800 5f10 bba5 1700 4bae 463c ......_.....K.F< > 0x0020 475c 0200 0809 0a0b 0c0d 0e0f 1011 1213 G\.............. > 0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# > 0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 > 0x0050 3435 3637 4567 > 12:00:44.669009 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 63, id > 29634 > , len 84) > 0x0000 4500 0054 73c2 0000 3f01 cfa3 ac10 e018 E..Ts...?....... > 0x0010 ac18 0002 0800 5f10 bba5 1700 4bae 463c ......_.....K.F< > 0x0020 475c 0200 0809 0a0b 0c0d 0e0f 1011 1213 G\.............. > 0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# > 0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 > 0x0050 3435 3637 4567 > 12:00:44.669034 172.16.1.254 > 172.16.224.24: icmp: redirect 172.24.0.2 to > host > 172.16.1.252 for 172.16.224.24 > 172.24.0.2: icmp: echo request (ttl 64, id > 2963 > 4, len 84) (ttl 64, id 12154, len 56) > 0x0000 4500 0038 2f7a 0000 4001 1114 ac10 01fe E..8/z..@....... > 0x0010 ac10 e018 0501 133c ac10 01fc 4500 0054 .......<....E..T > 0x0020 73c2 0000 4001 cea3 ac10 e018 ac18 0002 s...@........... > 0x0030 0800 5f10 bba5 1700 .._..... > $ netstat -rn I was interested in the routing table on BSDHost, not the router. However... > $ ifconfig > > fxp0: flags=8843 mtu 1500 > inet 172.16.1.12 netmask 0xffff0000 broadcast 172.16.255.255 > inet 172.16.1.11 netmask 0xffff0000 broadcast 172.16.255.255 > inet 172.16.1.254 netmask 0xffff0000 broadcast 172.16.255.255 > inet 172.16.1.10 netmask 0xffff0000 broadcast 172.16.255.255 This is a misconfiguration. Only one of those addresses should have a 0xffff0000 netmask and the rest should be 0xffffffff. But I was interested in BSDHost. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 1:10:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6A05437B419 for ; Fri, 18 Jan 2002 01:10:18 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0I99vC05784; Fri, 18 Jan 2002 11:09:57 +0200 (EET) (envelope-from ru) Date: Fri, 18 Jan 2002 11:09:56 +0200 From: Ruslan Ermilov To: Harti Brandt Cc: net@FreeBSD.ORG Subject: Re: interface creation notification Message-ID: <20020118110956.C1997@sunbay.com> References: <20020117185451.V97177-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020117185451.V97177-100000@beagle.fokus.gmd.de> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: > > Hi, > > how is a daemon supposed to get informed that a network interface has been > created? I had hoped, that an RTM_IFINFO message would be created on the > routing socket, but this is not the case. If an interface is destroyed, > the routing socket gets a message for whatever reason. Wouldn't it be > simple to just create an RTM_IFINFO message? > It does get created (you can check with the ``route -vn monitor'' command), but please see PR kern/33747 for one small pitfall. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 1:39:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from jane.inty.net (jane.inty.net [195.224.93.242]) by hub.freebsd.org (Postfix) with ESMTP id 6D40237B41D for ; Fri, 18 Jan 2002 01:39:20 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by jane.inty.net (8.11.3/8.11.3) with ESMTP id g0I9dGo55461 for ; Fri, 18 Jan 2002 09:39:16 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g0I9d6dj019998 for ; Fri, 18 Jan 2002 09:39:06 GMT From: "Tariq Rashid" To: Subject: what is the corect ISEC behaviour for new connections over old ones? Date: Fri, 18 Jan 2002 09:41:47 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender-IP: 10.0.1.156 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 3536 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i know there's been some debate on this... but what is the current thinking in the light of any possible changes to KAME? the problem is that classic one: two ipsec hosts negotiate keys.. one's a server, one's a client... establish SAs and all is well. now, if one ike daemon is gracefully pulled down it sends a delete to itself and the other host, clearing the spds and sad entries... all is fine too. (i'm using isakmpd). now - what __should__ happen if one of the hosts, client or server, is ungracefully rebooted... should the server NOT respond to a new phase 1 negotiation? ... or should it waiut till the full phase 1 time out which could be 8 hours or more!!! or should it accept the new negotiation? i think (i may be wrong) that freebsd4.4r does accept new negotiations, and new entries are placed in the sad BUT: the machine accapts new SPI streams... but sends back old-SPI streams... confusing the rebooted machine. any light on this? tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 1:42:22 2002 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 16B4F37B416; Fri, 18 Jan 2002 01:42:00 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g0I9fwR08791; Fri, 18 Jan 2002 10:41:58 +0100 (MET) Date: Fri, 18 Jan 2002 10:41:58 +0100 (CET) From: Harti Brandt To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: interface creation notification In-Reply-To: <20020118110956.C1997@sunbay.com> Message-ID: <20020118103502.J97177-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 18 Jan 2002, Ruslan Ermilov wrote: RE>On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: RE>> RE>> Hi, RE>> RE>> how is a daemon supposed to get informed that a network interface has been RE>> created? I had hoped, that an RTM_IFINFO message would be created on the RE>> routing socket, but this is not the case. If an interface is destroyed, RE>> the routing socket gets a message for whatever reason. Wouldn't it be RE>> simple to just create an RTM_IFINFO message? RE>> RE>It does get created (you can check with the ``route -vn monitor'' command), RE>but please see PR kern/33747 for one small pitfall. That's exactly what I did, but it doesn't work. The only places, that I can find when rt_ifmsg is called are: - interface goes up (if_route) - interface goes down (if_unroute) - change MTU (if_hwioctl) - prom. mode (ifpromisc) - allmulti (if_allmulti) No one seems to call it when I just create an interface. The RTM_IFINFO when I delete it probably comes from the if_unroute. The RTM_IFINFO you see for an ifconfig gif0 create is probably a side effect of setting the MTU or so. I think it would make sense to do an rt_ifmsg somehere in if_attach/if_detach. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 2: 7:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C1C1B37B417 for ; Fri, 18 Jan 2002 02:07:45 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0IA7RA12771; Fri, 18 Jan 2002 12:07:27 +0200 (EET) (envelope-from ru) Date: Fri, 18 Jan 2002 12:07:27 +0200 From: Ruslan Ermilov To: Harti Brandt Cc: net@FreeBSD.ORG Subject: Re: interface creation notification Message-ID: <20020118120727.A12660@sunbay.com> References: <20020118110956.C1997@sunbay.com> <20020118103502.J97177-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020118103502.J97177-100000@beagle.fokus.gmd.de> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jan 18, 2002 at 10:41:58AM +0100, Harti Brandt wrote: > On Fri, 18 Jan 2002, Ruslan Ermilov wrote: > > RE>On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: > RE>> > RE>> Hi, > RE>> > RE>> how is a daemon supposed to get informed that a network interface has been > RE>> created? I had hoped, that an RTM_IFINFO message would be created on the > RE>> routing socket, but this is not the case. If an interface is destroyed, > RE>> the routing socket gets a message for whatever reason. Wouldn't it be > RE>> simple to just create an RTM_IFINFO message? > RE>> > RE>It does get created (you can check with the ``route -vn monitor'' command), > RE>but please see PR kern/33747 for one small pitfall. > > That's exactly what I did, but it doesn't work. The only places, that I > can find when rt_ifmsg is called are: > > - interface goes up (if_route) > - interface goes down (if_unroute) > - change MTU (if_hwioctl) > - prom. mode (ifpromisc) > - allmulti (if_allmulti) > > No one seems to call it when I just create an interface. The RTM_IFINFO > when I delete it probably comes from the if_unroute. The RTM_IFINFO you > see for an ifconfig gif0 create is probably a side effect of setting the > MTU or so. > > I think it would make sense to do an rt_ifmsg somehere in > if_attach/if_detach. > OK, I will send a patch within an hour or so. NetBSD already has something to address this. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 2:28:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.netmodule.com (mail.netmodule.com [195.49.111.194]) by hub.freebsd.org (Postfix) with ESMTP id B8DAF37B41D for ; Fri, 18 Jan 2002 02:28:25 -0800 (PST) Received: from tigris.pacific (tigris.pacific [172.16.1.30]) by mail.netmodule.com (8.9.3/8.9.3) with ESMTP id LAA23098 for ; Fri, 18 Jan 2002 11:28:16 +0100 Received: by tigris.pacific with Internet Mail Service (5.5.2653.19) id <4WSSQAZJ>; Fri, 18 Jan 2002 11:28:17 +0100 Message-ID: From: "Reto Trachsel (NetModule)" To: "'net@freebsd.org'" Subject: RE: ICMP Redirect Date: Fri, 18 Jan 2002 11:28:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Good Morning Crist Ok, this with the Network-IP aliases, you are right, tnx for the tip. I think you are intrested in the Flags, D for dynamic redirect and M for modified dynamical from redirect. On the BSDClient, there are no entries in the routing table with the D or M Flag. I detected two "mistakes": 1. Router don't send ICMP Redirect messages, if the target rediredt Router is the default router. 2. The Clients don't accept the ICMP Redirect packets from the BSD-Router. Problem 1 --------- If i'm doing a ping to an external address, on the router machine i can see two ICMP request packets: 10:41:33.868478 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:33.868501 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:34.878624 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:34.878664 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:35.890321 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:35.890361 172.16.224.24 > 157.161.7.7: icmp: echo request On the BSDClient it looks all right. Every ICMP request gets a reply 10:41:28.973126 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:28.994275 157.161.7.7 > 172.16.224.24: icmp: echo reply 10:41:29.978672 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:29.989218 157.161.7.7 > 172.16.224.24: icmp: echo reply 10:41:30.988690 172.16.224.24 > 157.161.7.7: icmp: echo request 10:41:31.004373 157.161.7.7 > 172.16.224.24: icmp: echo reply The Router doesn't send ICMP Redirects to the WAN-Router (Cisco 2600) on the address 172.16.1.1 which is connected to the Internet and is the default router of the BSD Routing Machine. The ICMP Redirect should work like this: RFC 792 [Page 12]: The gateway sends a redirect message to a host in the following situation. A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. The gateway forwards the original datagram's data to its internet destination. The router don't send this ICMP Redirects, if the redirect Router is the default router. That's badly. Problem 2 --------- If the router isn't the default router, the ICMP Redirect will be send. But this ICMP Redirect Packets are not acceptet (don't create a routing table entry with Flag M or D) by the Hosts (Windows and BSD). Both hosts work with a RedHat Routing Machine. tcpdump on the Router: 10:57:58.838278 172.16.224.24 > 172.24.0.100: icmp: echo request 10:57:58.838330 172.16.224.24 > 172.24.0.100: icmp: echo request 10:57:58.838357 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to host 172.16.1.252 10:57:59.848649 172.16.224.24 > 172.24.0.100: icmp: echo request 10:57:59.848683 172.16.224.24 > 172.24.0.100: icmp: echo request 10:57:59.848707 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to host 172.16.1.252 And more detailed: 11:07:51.542808 172.16.224.24 > 172.24.0.100: icmp: echo request (ttl 63, id 226 56, len 84) 0x0000 4500 0054 5880 0000 3f01 ea83 ac10 e018 E..TX...?....... 0x0010 ac18 0064 0800 7b4f 95ac 0200 58f3 473c ...d..{O....X.G< 0x0020 4dd1 0c00 0809 0a0b 0c0d 0e0f 1011 1213 M............... 0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050 3435 3637 4567 11:07:51.542832 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to host 172.16.1.252 for 172.16.224.24 > 172.24.0.100: icmp: echo request (ttl 64, id 2 2656, len 84) (ttl 64, id 20386, len 56) 0x0000 4500 0038 4fa2 0000 4001 f1dd ac10 010c E..8O...@....... 0x0010 ac10 e018 0501 31f6 ac10 01fc 4500 0054 ......1.....E..T 0x0020 5880 0000 4001 e983 ac10 e018 ac18 0064 X...@..........d 0x0030 0800 7b4f 95ac 0200 ..{O.... The ICMP packet is sended with a Code 1 Message: Redirect datagrams for the Host. The packet looks like it have to be! (RFC792 Page 11), but the Hosts doesn't accept this messages. (No entry in the Routing tables with D or M Flag) On the BSD Client and Router, the sysctl settings are: net.inet.icmp.drop_redirect: 0 net.inet.ip.redirect: 1 net.inet.ip.sourceroute: 0 Regards Reto Trachsel Your Partner for Internet & Networking Technologies! ____________________________________________________ NetModule AG Meriedweg 7 / CH-3172 Niederwangen Phone: +41 31 985 25 10 / Fax: +41 31 985 25 11 www.netmodule.com NetModule AG, Java Competence Center Zuercherstrasse 12 / Postfach / CH-8401 Winterthur Phone: +41 52 209 00 44 / Fax: +41 52 209 00 40____________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 2:45:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (artemis.drwilco.net [209.167.6.62]) by hub.freebsd.org (Postfix) with ESMTP id 8A08F37B41C for ; Fri, 18 Jan 2002 02:45:53 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g0IAjkR53332 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Fri, 18 Jan 2002 05:45:48 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020118114410.01bc2d00@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 11:55:09 +0100 To: Florent Parent From: "Rogier R. Mulhuijzen" Subject: Re: netgraph: how to setsockopt on ksocket node ? Cc: freebsd-net@freebsd.org In-Reply-To: <214190000.1011326302@blues.viagenie.qc.ca> References: <200201180216.g0I2G8k23055@arch20m.dellroad.org> <200201180216.g0I2G8k23055@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Florent, You use: struct opts { int level; int name; int value; } myopts; myopts.level = SOL_SOCKET; myopts.name = SO_REUSEPORT; myopts.value = 1; But socket options (on this level) are a predefined struct. Here's an example from some code I am working on: struct sockopt sopt; /* some code removed */ bzero(&sopt, sizeof(sopt)); sopt.sopt_level = SOL_SOCKET; sopt.sopt_name = SO_SNDBUF; bufsiz = 128 * 1024; /* XXX */ sopt.sopt_val = &bufsiz; sopt.sopt_valsize = sizeof(bufsiz); Hope this clears a few things up =) (BTW, I'm not using netgraph after this code, but I know from reading the netgraph source that this struct sockopt is what is used). Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 6:24:12 2002 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 3CCFA37BAD0; Fri, 18 Jan 2002 06:23:13 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g0IEN9R17269; Fri, 18 Jan 2002 15:23:09 +0100 (MET) Date: Fri, 18 Jan 2002 15:23:09 +0100 (CET) From: Harti Brandt To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: interface creation notification In-Reply-To: <20020118120727.A12660@sunbay.com> Message-ID: <20020118151656.K97177-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 18 Jan 2002, Ruslan Ermilov wrote: RE>On Fri, Jan 18, 2002 at 10:41:58AM +0100, Harti Brandt wrote: RE>> On Fri, 18 Jan 2002, Ruslan Ermilov wrote: RE>> RE>> RE>On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: RE>> RE>> RE>> RE>> Hi, RE>> RE>> RE>> RE>> how is a daemon supposed to get informed that a network interface has been RE>> RE>> created? I had hoped, that an RTM_IFINFO message would be created on the RE>> RE>> routing socket, but this is not the case. If an interface is destroyed, RE>> RE>> the routing socket gets a message for whatever reason. Wouldn't it be RE>> RE>> simple to just create an RTM_IFINFO message? RE>> RE>> RE>> RE>It does get created (you can check with the ``route -vn monitor'' command), RE>> RE>but please see PR kern/33747 for one small pitfall. RE>> RE>> That's exactly what I did, but it doesn't work. The only places, that I RE>> can find when rt_ifmsg is called are: RE>> RE>> - interface goes up (if_route) RE>> - interface goes down (if_unroute) RE>> - change MTU (if_hwioctl) RE>> - prom. mode (ifpromisc) RE>> - allmulti (if_allmulti) RE>> RE>> No one seems to call it when I just create an interface. The RTM_IFINFO RE>> when I delete it probably comes from the if_unroute. The RTM_IFINFO you RE>> see for an ifconfig gif0 create is probably a side effect of setting the RE>> MTU or so. RE>> RE>> I think it would make sense to do an rt_ifmsg somehere in RE>> if_attach/if_detach. RE>> RE>OK, I will send a patch within an hour or so. NetBSD already RE>has something to address this. I just had a look at this and, yes, that's what I mean. Just one question: is there any locking that does a user process prevent from seeing the interface still on the interface list after the message is sent, but before the interface is removed from the list? (I mean on an SMP system). The DEPARTURE message is sent before the interface is unlinked from the list. thanks for your help, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 6:45:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E613637B416 for ; Fri, 18 Jan 2002 06:44:57 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0IEihe51409; Fri, 18 Jan 2002 16:44:43 +0200 (EET) (envelope-from ru) Date: Fri, 18 Jan 2002 16:44:43 +0200 From: Ruslan Ermilov To: Harti Brandt Cc: net@FreeBSD.ORG Subject: Re: interface creation notification Message-ID: <20020118164443.A48141@sunbay.com> References: <20020118120727.A12660@sunbay.com> <20020118151656.K97177-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020118151656.K97177-100000@beagle.fokus.gmd.de> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jan 18, 2002 at 03:23:09PM +0100, Harti Brandt wrote: > On Fri, 18 Jan 2002, Ruslan Ermilov wrote: > > RE>On Fri, Jan 18, 2002 at 10:41:58AM +0100, Harti Brandt wrote: > RE>> On Fri, 18 Jan 2002, Ruslan Ermilov wrote: > RE>> > RE>> RE>On Thu, Jan 17, 2002 at 06:58:26PM +0100, Harti Brandt wrote: > RE>> RE>> > RE>> RE>> Hi, > RE>> RE>> > RE>> RE>> how is a daemon supposed to get informed that a network interface has been > RE>> RE>> created? I had hoped, that an RTM_IFINFO message would be created on the > RE>> RE>> routing socket, but this is not the case. If an interface is destroyed, > RE>> RE>> the routing socket gets a message for whatever reason. Wouldn't it be > RE>> RE>> simple to just create an RTM_IFINFO message? > RE>> RE>> > RE>> RE>It does get created (you can check with the ``route -vn monitor'' command), > RE>> RE>but please see PR kern/33747 for one small pitfall. > RE>> > RE>> That's exactly what I did, but it doesn't work. The only places, that I > RE>> can find when rt_ifmsg is called are: > RE>> > RE>> - interface goes up (if_route) > RE>> - interface goes down (if_unroute) > RE>> - change MTU (if_hwioctl) > RE>> - prom. mode (ifpromisc) > RE>> - allmulti (if_allmulti) > RE>> > RE>> No one seems to call it when I just create an interface. The RTM_IFINFO > RE>> when I delete it probably comes from the if_unroute. The RTM_IFINFO you > RE>> see for an ifconfig gif0 create is probably a side effect of setting the > RE>> MTU or so. > RE>> > RE>> I think it would make sense to do an rt_ifmsg somehere in > RE>> if_attach/if_detach. > RE>> > RE>OK, I will send a patch within an hour or so. NetBSD already > RE>has something to address this. > > I just had a look at this and, yes, that's what I mean. > I've just committed this feature. > Just one question: > is there any locking that does a user process prevent from seeing the > interface still on the interface list after the message is sent, but > before the interface is removed from the list? (I mean on an SMP system). > The DEPARTURE message is sent before the interface is unlinked from the > list. > In -STABLE, splnet() does the necessary locking. In SMPng'ed -CURRENT, I do not believe any ifnet-related mutexes code was committed. I think that the locking is done with Giant at the moment, but I may be wrong. In any case, the code I have committed does not make things any worse, as if_detach() should be able to modify the ifnet list of interfaces, and any ifnet-traversing code should block if the modification is in progress. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 6:47:14 2002 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 3E76F37B41F; Fri, 18 Jan 2002 06:46:59 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g0IEkuR23965; Fri, 18 Jan 2002 15:46:56 +0100 (MET) Date: Fri, 18 Jan 2002 15:46:56 +0100 (CET) From: Harti Brandt To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: interface creation notification In-Reply-To: <20020118164443.A48141@sunbay.com> Message-ID: <20020118154603.W97177-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 18 Jan 2002, Ruslan Ermilov wrote: RE>On Fri, Jan 18, 2002 at 03:23:09PM +0100, Harti Brandt wrote: RE>> On Fri, 18 Jan 2002, Ruslan Ermilov wrote: ... RE>> RE>I've just committed this feature. RE> RE>> Just one question: RE>> is there any locking that does a user process prevent from seeing the RE>> interface still on the interface list after the message is sent, but RE>> before the interface is removed from the list? (I mean on an SMP system). RE>> The DEPARTURE message is sent before the interface is unlinked from the RE>> list. RE>> RE>In -STABLE, splnet() does the necessary locking. In SMPng'ed -CURRENT, RE>I do not believe any ifnet-related mutexes code was committed. I think RE>that the locking is done with Giant at the moment, but I may be wrong. RE>In any case, the code I have committed does not make things any worse, RE>as if_detach() should be able to modify the ifnet list of interfaces, RE>and any ifnet-traversing code should block if the modification is in RE>progress. Ok, yes. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 21:14:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from blues.viagenie.qc.ca (modemcable114.39-130-66.mtl.mc.videotron.ca [66.130.39.114]) by hub.freebsd.org (Postfix) with ESMTP id 1F31A37B402 for ; Fri, 18 Jan 2002 21:14:25 -0800 (PST) Received: from blues.viagenie.qc.ca (blues-local [127.0.0.1]) by blues.viagenie.qc.ca (8.11.6/8.11.3) with ESMTP id g0J5EN801863; Sat, 19 Jan 2002 00:14:23 -0500 (EST) (envelope-from Florent.Parent@viagenie.qc.ca) Date: Sat, 19 Jan 2002 00:14:11 -0500 From: Florent Parent To: freebsd-net@freebsd.org Cc: "Rogier R. Mulhuijzen" Subject: Re: netgraph: how to setsockopt on ksocket node ? Message-ID: <26540000.1011417251@blues.viagenie.qc.ca> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-PGP-Fingerprint: B718 4543 977C BE73 2BCC 23D5 3E20 4FC9 2A90 872C MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --On 2002-01-18 11:55:09 +0100 drwilco@drwilco.net wrote: > But socket options (on this level) are a predefined struct. Here's an > example from some code I am working on: > > struct sockopt sopt; > > /* some code removed */ > > bzero(&sopt, sizeof(sopt)); > sopt.sopt_level = SOL_SOCKET; > sopt.sopt_name = SO_SNDBUF; > bufsiz = 128 * 1024; /* XXX */ > sopt.sopt_val = &bufsiz; > sopt.sopt_valsize = sizeof(bufsiz); > > Hope this clears a few things up =) (BTW, I'm not using netgraph after > this code, but I know from reading the netgraph source that this struct > sockopt is what is used). > > Doc Hi, However I need to use the netgraph interface to access the socket. I cannot use the struct sockopt directly. struct sockopt is set in ng_ksocket_rcvmsg(). Poking around sosetopt(): sopt.sopt_p is used to determine whether copyin() or bcopy() will be used to copy data from sopt.sopt_val. The struct sockopt and the sopt_p member is set inside ng_ksocket_rcvmsg(). I commented out the sopt_p definition to force the use of bcopy() instead of copyin() and now my code now works ok. Could it be that sopt_val points to kernel space instead of user space and causes copyin() to fail with EFAULT ? Florent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 21:42: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id F268437B482 for ; Fri, 18 Jan 2002 21:41:30 -0800 (PST) Received: from dialup-209.247.143.249.dial1.sanjose1.level3.net ([209.247.143.249] helo=blossom.cjclark.org) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16RoFi-0002Ug-00; Fri, 18 Jan 2002 21:41:20 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0J5emr56483; Fri, 18 Jan 2002 21:40:48 -0800 (PST) (envelope-from cjc) Date: Fri, 18 Jan 2002 21:40:48 -0800 From: "Crist J . Clark" To: "Reto Trachsel (NetModule)" Cc: "'net@freebsd.org'" Subject: Re: ICMP Redirect Message-ID: <20020118214048.N40472@blossom.cjclark.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 reto.trachsel@netmodule.com on Fri, Jan 18, 2002 at 11:28:12AM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jan 18, 2002 at 11:28:12AM +0100, Reto Trachsel (NetModule) wrote: > Problem 1 > --------- > > If i'm doing a ping to an external address, on the router machine i can see > two ICMP request packets: > > 10:41:33.868478 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:33.868501 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:34.878624 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:34.878664 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:35.890321 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:35.890361 172.16.224.24 > 157.161.7.7: icmp: echo request I doubt this is a problem. Run tcpdump(1) with '-e'. One packet is from 172.16.224.24 and the other is the one the router is generating to forward. > On the BSDClient it looks all right. Every ICMP request gets a reply > > 10:41:28.973126 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:28.994275 157.161.7.7 > 172.16.224.24: icmp: echo reply > 10:41:29.978672 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:29.989218 157.161.7.7 > 172.16.224.24: icmp: echo reply > 10:41:30.988690 172.16.224.24 > 157.161.7.7: icmp: echo request > 10:41:31.004373 157.161.7.7 > 172.16.224.24: icmp: echo reply You have not given us a clear picture of your network setup, but again, run with '-e'. My guess is the client sees its own ping, it _doesn't_ see the one the router forwards (a switched LAN?), and then gets the ping back. The routing is probably asymmetric so the pongs don't go by the above router. But again, I don't see any problems here. Or at least this all seems consistent. > Problem 2 > --------- > > If the router isn't the default router, the ICMP Redirect will be send. But > this ICMP Redirect Packets are not acceptet (don't create a routing table > entry with Flag M or D) by the Hosts (Windows and BSD). Both hosts work with > a RedHat Routing Machine. > > tcpdump on the Router: > 10:57:58.838278 172.16.224.24 > 172.24.0.100: icmp: echo request > 10:57:58.838330 172.16.224.24 > 172.24.0.100: icmp: echo request > 10:57:58.838357 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to > host > 172.16.1.252 > 10:57:59.848649 172.16.224.24 > 172.24.0.100: icmp: echo request > 10:57:59.848683 172.16.224.24 > 172.24.0.100: icmp: echo request > 10:57:59.848707 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to > host > 172.16.1.252 You still didn't provide the info for the BSDHost. My best guess is that it is ignoring the redirects because it does not believe that the other host, 172.16.1.252 is local. If this isn't the problem, I'm not sure what else to look for. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jan 18 21:45:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 6F7DC37B400 for ; Fri, 18 Jan 2002 21:45:05 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA70472; Fri, 18 Jan 2002 21:30:03 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g0J5U0T27493; Fri, 18 Jan 2002 21:30:00 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200201190530.g0J5U0T27493@arch20m.dellroad.org> Subject: Re: netgraph: how to setsockopt on ksocket node ? In-Reply-To: <214190000.1011326302@blues.viagenie.qc.ca> "from Florent Parent at Jan 17, 2002 10:58:22 pm" To: Florent Parent Date: Fri, 18 Jan 2002 21:30:00 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, julian@elischer.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Florent Parent writes: > >> Anyone has an example on how to setsockopt on a ksocket node in netgraph? > >> > >> struct opts { > >> int level; > >> int name; > >> int value; > >> } myopts = { SOL_SOCKET, SO_REUSEADDR, 1 > >> }; > >> > >> ret = NgSendMsg(cs, epath, NGM_KSOCKET_COOKIE, NGM_KSOCKET_SETOPT, > >> (struct ng_ksocket_sockopt *)&myopts, > >> sizeof(myopts))); > >> > >> return error 14 "Bad address". > >> > >> Did some tracing in ng_ksocket.c and the struct sockopt sent as argument > >> to sosetopt() seems to contains sane values: > >> > >> sopt.sopt_val = 0xc182452c (pointer dereferences to 1) > >> sopt.sopt_valsize = 4 > netgraph: sendto(.dummy): Bad address Hmm.. I wonder if the problem is that this has never worked :-) That is, maybe setsockopt() is expecting the value pointer to point into user memory, while ng_ksocket is using a pointer that points into kernel memory? In which case, I don't know how to go about fixing it.. Julian? -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 Jan 19 4:34: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from pf39.warszawa.sdi.tpnet.pl (pf39.warszawa.sdi.tpnet.pl [213.25.209.39]) by hub.freebsd.org (Postfix) with ESMTP id 5EC9137B417; Sat, 19 Jan 2002 04:33:55 -0800 (PST) Received: (from zaks@localhost) by pf39.warszawa.sdi.tpnet.pl (8.11.6/8.11.6) id g0JCZCa07672; Sat, 19 Jan 2002 13:35:12 +0100 (CET) (envelope-from zaks) From: Slawek Zak To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Reply-To: zaks@prioris.mini.pw.edu.pl Subject: PPP callback and SecurID Content-MD5: 57a7bf53567c127ff4fc55a75702d023 Date: Sat, 19 Jan 2002 13:35:12 +0100 Message-ID: <87ofjqo6wv.fsf@pf39.warszawa.sdi.tpnet.pl> Lines: 52 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.5 (asparagus, i386-unknown-freebsd4.4) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've a problem with my callback. I'd like to automate it somehow, but there is a problem with LCP. The hard way is to do something like: # ppp ras ppp ON pf39> term deflink: Entering terminal mode on /dev/cuaa1 Type `~?' for help atdt CONNECT 57600 User Access Verification Username: Enter PASSCODE: Callback initiated - line is disconnected NO CARRIER RING RING ATA ...... (the connection) I tried to do something like this: [ppp.conf] ... callback: disable pap disable chap set speed 57600 set phone set cd off set device /dev/cuaa1 allow users * set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 10 \"\" ATZ OK ATDT\\T TIMEOUT 40 CONNECT" set login "TIMEOUT 15 sername: szak PASSCODE: \"!/usr/X11R6/bin/ssh-askpass\" Callback ATA" But it bails out, because the connection is apparently considered open by ppp after the disconnection, so I can't make the modem accept connections with ATA command in this state. Does anyone have other ideas how to make it work without typing the sequence everytime with term? Thanks, /S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 19 8:57:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from blues.viagenie.qc.ca (modemcable114.39-130-66.mtl.mc.videotron.ca [66.130.39.114]) by hub.freebsd.org (Postfix) with ESMTP id DE65337B417 for ; Sat, 19 Jan 2002 08:57:44 -0800 (PST) Received: from blues.viagenie.qc.ca (blues-local [127.0.0.1]) by blues.viagenie.qc.ca (8.11.6/8.11.3) with ESMTP id g0JGvdf00627; Sat, 19 Jan 2002 11:57:39 -0500 (EST) (envelope-from Florent.Parent@viagenie.qc.ca) Date: Sat, 19 Jan 2002 11:57:35 -0500 From: Florent Parent To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG, julian@elischer.org Subject: Re: netgraph: how to setsockopt on ksocket node ? Message-ID: <5390000.1011459455@blues.viagenie.qc.ca> In-Reply-To: <200201190530.g0J5U0T27493@arch20m.dellroad.org> References: <200201190530.g0J5U0T27493@arch20m.dellroad.org> X-Mailer: Mulberry/2.1.2 (Linux/x86) X-PGP-Fingerprint: B718 4543 977C BE73 2BCC 23D5 3E20 4FC9 2A90 872C MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --On 2002-01-18 21:30:00 -0800 archie@dellroad.org wrote: >> netgraph: sendto(.dummy): Bad address > > Hmm.. I wonder if the problem is that this has never worked :-) That would explain why I couldn't find any examples on using this ;-) > That is, maybe setsockopt() is expecting the value pointer to point > into user memory, while ng_ksocket is using a pointer that points > into kernel memory? > > In which case, I don't know how to go about fixing it.. Julian? This is what I did to make it work for me. A better fix would probably be=20 around the struct proc definition. If fact, you had noted "broken"=20 probably as a memo to fix something here... struct proc *p =3D curproc ? curproc : &proc0; /* XXX broken */ *** ng_ksocket.c.orig Sat Jan 19 11:05:28 2002 --- ng_ksocket.c Sat Jan 19 11:45:23 2002 *************** *** 759,765 **** sopt.sopt_name =3D ksopt->name; sopt.sopt_val =3D ksopt->value; sopt.sopt_valsize =3D valsize; ! sopt.sopt_p =3D p; error =3D sosetopt(so, &sopt); break; } --- 759,765 ---- sopt.sopt_name =3D ksopt->name; sopt.sopt_val =3D ksopt->value; sopt.sopt_valsize =3D valsize; ! sopt.sopt_p =3D 0; error =3D sosetopt(so, &sopt); break; } Florent. -- Florent Parent Viag=E9nie http://www.viagenie.qc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jan 19 15:20:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from pf39.warszawa.sdi.tpnet.pl (pf39.warszawa.sdi.tpnet.pl [213.25.209.39]) by hub.freebsd.org (Postfix) with ESMTP id 771E737B405; Sat, 19 Jan 2002 15:20:49 -0800 (PST) Received: (from zaks@localhost) by pf39.warszawa.sdi.tpnet.pl (8.11.6/8.11.6) id g0JNM0W01471; Sun, 20 Jan 2002 00:22:00 +0100 (CET) (envelope-from zaks) From: Slawek Zak To: "Joe & Fhe Barbish" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: PPP callback and SecurID References: Content-MD5: 5214dcd710afb627ba72e0cd2242b521 Date: Sun, 20 Jan 2002 00:22:00 +0100 In-Reply-To: ("Joe & Fhe Barbish"'s message of "Sat, 19 Jan 2002 09:37:29 -0500") Message-ID: <871ygmapuv.fsf@pf39.warszawa.sdi.tpnet.pl> Lines: 10 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.5 (asparagus, i386-unknown-freebsd4.4) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 19 Jan 2002, Joe Barbish Fhe Barbish uttered the following: > Please clarify what you are trying to do. > Are you trying to use ppp to call your ISP and have them > call you back and then login to your FBSD box? > OR have some user call your FBSD box and you call them back? I call them, give my SecurID, they call me back so I could use the net without paying for call time. /S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message