From owner-freebsd-net Sun Nov 4 4: 6:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail2.bigmailbox.com (mail2.bigmailbox.com [209.132.220.33]) by hub.freebsd.org (Postfix) with ESMTP id 3F02737B417 for ; Sun, 4 Nov 2001 04:06:40 -0800 (PST) Received: (from www@localhost) by mail2.bigmailbox.com (8.10.0/8.10.0) id fA4C6c614801; Sun, 4 Nov 2001 04:06:38 -0800 Date: Sun, 4 Nov 2001 04:06:38 -0800 Message-Id: <200111041206.fA4C6c614801@mail2.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [200.204.151.121] From: "irado@nettaxi.com" To: freebsd-net@FreeBSD.ORG Subject: dummynet (user confused) 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 am somewhat confuse on *how* to really use dummynet for bandwidth limitation. Im my (mis)understanding, ipfw functions act in a 'hit and run' way, say: the first one which corresponds to 'this' packet will be the only to be followed, there are no new verification on this packet with the next rule. dummynet needs ipfw to build a pipe.. but if this rule is hit does it means that any other will have no effect at all?? what are the correct order to run in the following situation: ipfilter and ipnat for these things. ipfw with dummynet for the following: machine 192.168.1.xa and machne 192.168.1.xb will have full bandwidth while machines in the 192.168.1.0/24 (except xa and xb) will have bandwidth limited to 8 kb/s. I ask you to please at least clarify on how to get such thing running. Pointing me to a 'real world' user url will be great!! saudações, irado furioso com tudo GNU/Linux user CASSADO nossa solidariedade é inversamente proporcional às nossas posses por favor, clique aqui: http://www.thehungersite.com e aqui também: http://cf6.uol.com.br/umminuto/ ------------------------------------------------------------ Nettaxi would like to ask for your help in donations to the RED CROSS today! http://www.nyredcross.org/donate/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 4 8:28:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.25]) by hub.freebsd.org (Postfix) with ESMTP id 0D54937B405 for ; Sun, 4 Nov 2001 08:28:49 -0800 (PST) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep16-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20011104162524.NGZI2039.amsfep16-int.chello.nl@daemon.chronias.ninth-circle.org>; Sun, 4 Nov 2001 17:25:24 +0100 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.6/8.11.6) id fA4GS2983833; Sun, 4 Nov 2001 17:28:02 +0100 (CET) (envelope-from asmodai) Date: Sun, 4 Nov 2001 17:28:01 +0100 From: Jeroen Ruigrok/Asmodai To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: unused interfaces in if_var.h Message-ID: <20011104172801.E83053@daemon.ninth-circle.org> References: <20011101172051.B36115@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011101172051.B36115@iguana.aciri.org> User-Agent: Mutt/1.3.23i Organisation: Ninth-Circle Enterprises 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 [20011102 02:30], Luigi Rizzo (rizzo@aciri.org) wrote: >Would people object to doing a similar change to the code >in STABLE ? No, I wouldn't mind. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Take thy beak from out my heart and take thy form from off my door! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 4 14: 0:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from server.kibernet.net (8-158.ta.cable.kks.net [213.161.8.158]) by hub.freebsd.org (Postfix) with ESMTP id 0F32137B405 for ; Sun, 4 Nov 2001 14:00:06 -0800 (PST) Received: from spider.suxx.eu.org (unknown [194.249.141.2]) by server.kibernet.net (Postfix) with ESMTP id B943F243AB for ; Sun, 4 Nov 2001 23:02:59 +0100 (CET) Received: by spider.suxx.eu.org (Postfix, from userid 1000) id 732131748F; Sun, 4 Nov 2001 23:04:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by spider.suxx.eu.org (Postfix) with ESMTP id 0B79232632; Sun, 4 Nov 2001 23:04:42 +0100 (CET) Date: Sun, 4 Nov 2001 23:04:39 +0100 (CET) From: David Delibasic To: "irado@nettaxi.com" Cc: Subject: Re: dummynet (user confused) In-Reply-To: <200111041206.fA4C6c614801@mail2.bigmailbox.com> Message-ID: <20011104224755.E66562-100000@spider.suxx.eu.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 On Sun, 4 Nov 2001, irado@nettaxi.com wrote: > Im my (mis)understanding, ipfw functions act in a 'hit and run' way, say: the first one which corresponds to 'this' packet will be the only to be followed, there are no new verification on this packet with the next rule. This is not always true...in some cases packet is passed again to the firewall code, starting from next rule. > dummynet needs ipfw to build a pipe.. but if this rule is hit does it means that any other will have no effect at all?? When "pipe" action is found that correspondes with packet, it is passed to dummynet code and then packet is passed to the forewalling code again starting from next rule. > machine 192.168.1.xa and machne 192.168.1.xb will have full bandwidth while > machines in the 192.168.1.0/24 (except xa and xb) will have bandwidth limited to 8 kb/s. Example 1: ipfw pipe 1 config bw 8Kbit/s ipfw pipe 2 config bw 8Kbit/s ipfw add pipe 1 ip from any to 192.168.1.xa ipfw add pipe 2 ip from any to 192.168.1.xb This will only limit downloads from machine a and machine b to 8Kbit/s Example 2: Machines a and b share bandwidth of 8Kbit/s ipfw pipe 1 config bw 8Kbit/s ipfw add pipe 1 ip from any to 192.168.1.xa ipfw add pipe 1 ip from any to 192.168.1.xb Example 3 (this is what you wanted): ipfw pipe 1 config bw 8Kbit/s mask dst-ip 0x000000ff ipfw add accept ip from any to 192.168.1.xa ipfw add accept ip from any to 192.168.1.xb ipfw add pipe 1 ip from any to 192.168.1.0/24 With Regards, D. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 4 14:47:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f221.pav2.hotmail.com [64.4.37.221]) by hub.freebsd.org (Postfix) with ESMTP id EADF237B405 for ; Sun, 4 Nov 2001 14:47:53 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Nov 2001 14:47:53 -0800 Received: from 204.178.20.13 by pv2fd.pav2.hotmail.msn.com with HTTP; Sun, 04 Nov 2001 22:47:53 GMT X-Originating-IP: [204.178.20.13] From: "murthy kn" To: maddave@suxx.eu.org Cc: freebsd-net@FreeBSD.ORG Subject: Re: dummynet (user confused) Date: Mon, 05 Nov 2001 04:17:53 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Nov 2001 22:47:53.0917 (UTC) FILETIME=[BD4CDED0:01C16582] 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 not always true...in some cases packet is passed again to the >firewall code, starting from next rule. > > > dummynet needs ipfw to build a pipe.. but if this rule is hit does it >means that any other will have no effect at all?? > >When "pipe" action is found that correspondes with packet, it is passed to >dummynet code and then packet is passed to the forewalling code again >starting from next rule. -------> A small addition from the "man ipfw" This is the behaviour when "net.inet.ip.fw.one_pass" is not set. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 4 16:18:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 21E1C37B405 for ; Sun, 4 Nov 2001 16:18:18 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id C7E8981D07; Sun, 4 Nov 2001 18:18:12 -0600 (CST) Date: Sun, 4 Nov 2001 18:18:12 -0600 From: Bill Fumerola To: "irado@nettaxi.com" Cc: freebsd-net@FreeBSD.ORG Subject: Re: dummynet (user confused) Message-ID: <20011104181812.R51024@elvis.mu.org> References: <200111041206.fA4C6c614801@mail2.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111041206.fA4C6c614801@mail2.bigmailbox.com>; from irado@nettaxi.com on Sun, Nov 04, 2001 at 04:06:38AM -0800 X-Operating-System: FreeBSD 4.4-FEARSOME-20010909 i386 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, Nov 04, 2001 at 04:06:38AM -0800, irado@nettaxi.com wrote: > > I am somewhat confuse on *how* to really use dummynet for bandwidth limitation. > > Im my (mis)understanding, ipfw functions act in a 'hit and run' way, > say: the first one which corresponds to 'this' packet will be the only > to be followed, there are no new verification on this packet with the > next rule. you need to change the sysctl 'net.inet.ip.fw.one_pass'. see ipfw(8). -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 5:43:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id 06C3C37B416 for ; Mon, 5 Nov 2001 05:43:35 -0800 (PST) Received: by gvr.gvr.org (Postfix, from userid 657) id 36C315808; Mon, 5 Nov 2001 14:43:30 +0100 (CET) Date: Mon, 5 Nov 2001 14:43:30 +0100 From: Guido van Rooij To: freebsd-net@freebsd.org Subject: patch regarding icmp bandwidth limiting Message-ID: <20011105144330.A29038@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Does anyone mind the followning patch? The reason for it is that if I ping flood localhost I get the following messages: Limiting icmp ping response from 250 to 200 packets per second Limiting icmp ping response from 249 to 200 packets per second Limiting icmp ping response from 249 to 200 packets per second Limiting icmp ping response from 249 to 200 packets per second Limiting icmp ping response from 249 to 200 packets per second Limiting icmp ping response from 248 to 200 packets per second This doesn't make much sense because it seems that the limiting is trying to be set to 200 but somehow is stuck at 250. -Guido Index: ip_icmp.c =================================================================== RCS file: /scratch/cvsup/freebsd/CVS/src/sys/netinet/ip_icmp.c,v retrieving revision 1.62 diff -u -r1.62 ip_icmp.c --- ip_icmp.c 2001/10/25 05:56:30 1.62 +++ ip_icmp.c 2001/11/05 13:41:53 @@ -862,9 +862,10 @@ * bump packet count */ - if (++lpackets[which] > icmplim) { + if (lpackets[which] >= icmplim) { return(-1); } + lpackets[which]++; return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 8:24:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 6E3B737B405 for ; Mon, 5 Nov 2001 08:24:13 -0800 (PST) Received: (qmail 29710 invoked by uid 1000); 5 Nov 2001 16:23:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Nov 2001 16:23:42 -0000 Date: Mon, 5 Nov 2001 10:23:42 -0600 (CST) From: Mike Silbersack To: Guido van Rooij Cc: Subject: Re: patch regarding icmp bandwidth limiting In-Reply-To: <20011105144330.A29038@gvr.gvr.org> Message-ID: <20011105102130.H29695-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 5 Nov 2001, Guido van Rooij wrote: > Does anyone mind the followning patch? The reason for it is that if > I ping flood localhost I get the following messages: > Limiting icmp ping response from 250 to 200 packets per second > Limiting icmp ping response from 249 to 200 packets per second > Limiting icmp ping response from 249 to 200 packets per second > Limiting icmp ping response from 249 to 200 packets per second > Limiting icmp ping response from 249 to 200 packets per second > Limiting icmp ping response from 248 to 200 packets per second > > This doesn't make much sense because it seems that the limiting is > trying to be set to 200 but somehow is stuck at 250. > > -Guido The first number is the rate at which the machine would be responding without limiting enabled. The second number tells you the rate at which it is responding. Changing from a pre to a post increment isn't going to change what you're seeing. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 9: 4:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by hub.freebsd.org (Postfix) with ESMTP id 5D6CF37B416 for ; Mon, 5 Nov 2001 09:04:20 -0800 (PST) Received: by gvr.gvr.org (Postfix, from userid 657) id 70F6D5809; Mon, 5 Nov 2001 18:04:18 +0100 (CET) Date: Mon, 5 Nov 2001 18:04:18 +0100 From: Guido van Rooij To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: patch regarding icmp bandwidth limiting Message-ID: <20011105180418.A32828@gvr.gvr.org> References: <20011105144330.A29038@gvr.gvr.org> <20011105102130.H29695-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011105102130.H29695-100000@achilles.silby.com>; from silby@silby.com on Mon, Nov 05, 2001 at 10:23:42AM -0600 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, Nov 05, 2001 at 10:23:42AM -0600, Mike Silbersack wrote: > The first number is the rate at which the machine would be responding > without limiting enabled. The second number tells you the rate at which > it is responding. Changing from a pre to a post increment isn't going to > change what you're seeing. > I was thinking the same, but still the message puzzled me. How about changing it from: Limiting icmp ping response to %d packet per second for %d received -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 9:11:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 97D7237B417 for ; Mon, 5 Nov 2001 09:11:13 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA5H7ZY75153; Mon, 5 Nov 2001 09:07:35 -0800 (PST) (envelope-from rizzo) Date: Mon, 5 Nov 2001 09:07:35 -0800 From: Luigi Rizzo To: freebsd-net@FreeBSD.ORG Subject: limiting outgoing ICMP's Message-ID: <20011105090735.A75119@iguana.aciri.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 There seems to be no knob to limit outgoing icmp's (redirects, no route, and the like). Wouldn't it be the case to add a sysctl variable to rate-limit or disable such messages ? I do not think it makes a lot of sense to let our routers become reflectors for certain types of DoS attacks. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 11:19: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 2125637B419 for ; Mon, 5 Nov 2001 11:19:02 -0800 (PST) Received: (qmail 30409 invoked by uid 1000); 5 Nov 2001 19:19:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Nov 2001 19:19:00 -0000 Date: Mon, 5 Nov 2001 13:19:00 -0600 (CST) From: Mike Silbersack To: Guido van Rooij Cc: Subject: Re: patch regarding icmp bandwidth limiting In-Reply-To: <20011105180418.A32828@gvr.gvr.org> Message-ID: <20011105131741.T29695-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 5 Nov 2001, Guido van Rooij wrote: > On Mon, Nov 05, 2001 at 10:23:42AM -0600, Mike Silbersack wrote: > > The first number is the rate at which the machine would be responding > > without limiting enabled. The second number tells you the rate at which > > it is responding. Changing from a pre to a post increment isn't going to > > change what you're seeing. > > > > I was thinking the same, but still the message puzzled me. > > How about changing it from: > Limiting icmp ping response to %d packet per second for %d received > > -Guido I'm not sure that's any more clear. If you can find a wording which is more clear for all the types of limiting, I'll be happy to commit it, but I don't think you're there yet. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 13:25:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from rose.niw.com.au (cerberus.apdata.com.au [202.14.95.17]) by hub.freebsd.org (Postfix) with ESMTP id 7B91437B417 for ; Mon, 5 Nov 2001 13:24:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id 2E2E89721C for ; Tue, 6 Nov 2001 07:54:53 +1030 (CST) Received: by rose.niw.com.au (Postfix, from userid 1000) id B9DAD97215; Tue, 6 Nov 2001 07:54:51 +1030 (CST) Date: Tue, 6 Nov 2001 07:54:51 +1030 From: Ian West To: freebsd-net@freebsd.org Subject: Results from RTM_GET on route socket ? Message-ID: <20011106075451.E34308@rose.niw.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 I am a bit confused about the results of RTM_GET. Below is a hexdump of the response I am getting, The response rtm_addrs field is 0x37 which I believe indicates I should have values for the following in top down order. #define RTA_DST 0x1 /* destination sockaddr present */ #define RTA_GATEWAY 0x2 /* gateway sockaddr present */ #define RTA_NETMASK 0x4 /* netmask sockaddr present */ #define RTA_IFP 0x10 /* interface name sockaddr present */ #define RTA_IFA 0x20 /* interface addr sockaddr present */ Starting at the * (Offset 5c, sizeof(struct rt_msghdr) I have 16 bytes for RTA_DST, 16 bytes for RTA_GATEWAY, and then 4 null bytes. After this there seems to be a valid RTA_IFP, and RTA_IFA. My understanding is that the items should be sockaddr's, what is the correct way to interpret the null bytes ? (I don't want to write iffy code that breaks later :-) 0x0000: c8 00 05 04 02 00 00 00 43 08 01 00 37 00 00 00 H C 7 0x0010: ef 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 o 0x0020: 00 00 00 00 00 00 00 00 dc 05 00 00 00 00 00 00 \ 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 d5 17 00 00 00 00 00 00 U 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00*10 02 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 10 02 00 00 0x0070: c0 a8 01 0a 00 00 00 00 00 00 00 00 00 00 00 00 @( 0x0080: 38 12 02 00 06 03 06 00 64 63 30 00 80 c8 cd 23 8 dc0 HM# 0x0090: fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 } 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00b0: 00 00 00 00 00 00 00 00 10 02 00 00 c0 a8 01 09 @( 0x00c0: 00 00 00 00 00 00 00 00 -- -- -- -- -- -- -- -- Thanks for any feedback.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 13:57: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7BC3437B416 for ; Mon, 5 Nov 2001 13:57:05 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fA5Lutl92439; Mon, 5 Nov 2001 16:56:55 -0500 (EST) (envelope-from wollman) Date: Mon, 5 Nov 2001 16:56:55 -0500 (EST) From: Garrett Wollman Message-Id: <200111052156.fA5Lutl92439@khavrinen.lcs.mit.edu> To: Ian West Cc: freebsd-net@FreeBSD.ORG Subject: Results from RTM_GET on route socket ? In-Reply-To: <20011106075451.E34308@rose.niw.com.au> References: <20011106075451.E34308@rose.niw.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Starting at the * (Offset 5c, sizeof(struct rt_msghdr) I have 16 bytes > for RTA_DST, 16 bytes for RTA_GATEWAY, and then 4 null bytes. The first null byte is the length of the netmask, indicating that you have a zero-length netmask, and the remaining three nulls are padding. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 14:39: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 348E137B418 for ; Mon, 5 Nov 2001 14:39:00 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fA5Mcrt82182 for ; Mon, 5 Nov 2001 17:38:53 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Mon, 5 Nov 2001 17:38:52 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: freebsd-net@FreeBSD.org Subject: in_pcb patch -- force sin_zero & copy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This patch was "inspired by" pr 31704. It first copies the sockaddr structure passed into us (in_pcbbind()) and then utilizes that new structure as the local sockaddr_in to modify/use. Also, it forces sin_zero to be 0, since it is meant to be a padding to sockaddr. Could the appropriate people check this out? I'm currently running it now as of 7 minutes ago -- but should not be an issue. patch url: http://people.freebsd.org/~arr/patches/in_pcb-sin.diff Cheers, Andrew -- Andrew R. Reiter arr@watson.org arr@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 Nov 5 15:47:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 54F8737B405; Mon, 5 Nov 2001 15:47:23 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fA5NlM894010; Mon, 5 Nov 2001 18:47:22 -0500 (EST) (envelope-from wollman) Date: Mon, 5 Nov 2001 18:47:22 -0500 (EST) From: Garrett Wollman Message-Id: <200111052347.fA5NlM894010@khavrinen.lcs.mit.edu> To: "Andrew R. Reiter" Cc: freebsd-net@FreeBSD.ORG Subject: in_pcb patch -- force sin_zero & copy In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > This patch was "inspired by" pr 31704. It first copies the sockaddr > structure passed into us There's no reason to do this. in_pcbbind() is ultimately called from bind(2), which is already giving us a fresh copy. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 16: 4:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 487E137B418 for ; Mon, 5 Nov 2001 16:04:08 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fA603vf83064; Mon, 5 Nov 2001 19:03:58 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Mon, 5 Nov 2001 19:03:57 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Garrett Wollman Cc: freebsd-net@FreeBSD.org, jdp@polstra.com Subject: Re: in_pcb patch -- force sin_zero & copy In-Reply-To: <200111052347.fA5NlM894010@khavrinen.lcs.mit.edu> 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, 5 Nov 2001, Garrett Wollman wrote: :There's no reason to do this. in_pcbbind() is ultimately called from :bind(2), which is already giving us a fresh copy. : mmm, good point. Then the fix should just be just to zero out the sin_zero field forcefully... jdp, any comments? Andrew -- Andrew R. Reiter arr@watson.org arr@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 Nov 5 16:15:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 0AF1837B417; Mon, 5 Nov 2001 16:15:18 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id fA60FHY12396; Mon, 5 Nov 2001 16:15:17 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id fA60FHZ53456; Mon, 5 Nov 2001 16:15:17 -0800 (PST) (envelope-from jdp) Date: Mon, 5 Nov 2001 16:15:17 -0800 (PST) Message-Id: <200111060015.fA60FHZ53456@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: arr@freebsd.org Subject: Re: in_pcb patch -- force sin_zero & copy In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article , Andrew R. Reiter wrote: > On Mon, 5 Nov 2001, Garrett Wollman wrote: > > :There's no reason to do this. in_pcbbind() is ultimately called from > :bind(2), which is already giving us a fresh copy. > : > > mmm, good point. Then the fix should just be just to zero out the > sin_zero field forcefully... > > jdp, any comments? As I said before in private mail: 1) It is Just Wrong for in_pcbbind to be scribbling into the sockaddr_in struct, but 2) there is already code there which overwrites the sin_port field, complete with a comment that says "yech...", and 3) it doesn't offend me enough to make a stink about it. It's wrong, but it's not wrong enough to merit this much hand-wringing. Just do it. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 16:55:20 2001 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 D021C37B405 for ; Mon, 5 Nov 2001 16:55:17 -0800 (PST) Received: from dialup-209.245.130.246.dial1.sanjose1.level3.net ([209.245.130.246] helo=blossom.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 160uWJ-0000Zv-00; Mon, 05 Nov 2001 16:55:17 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA60snk01385; Mon, 5 Nov 2001 16:54:49 -0800 (PST) (envelope-from cjc) Date: Mon, 5 Nov 2001 16:54:49 -0800 From: "Crist J. Clark" To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: limiting outgoing ICMP's Message-ID: <20011105165448.D745@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011105090735.A75119@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011105090735.A75119@iguana.aciri.org>; from rizzo@aciri.org on Mon, Nov 05, 2001 at 09:07:35AM -0800 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, Nov 05, 2001 at 09:07:35AM -0800, Luigi Rizzo wrote: > There seems to be no knob to limit outgoing icmp's (redirects, no > route, and the like). Wouldn't it be the case to add a sysctl > variable to rate-limit or disable such messages ? I do not think > it makes a lot of sense to let our routers become reflectors for > certain types of DoS attacks. The a quick look at ip_icmp.c seems to indicate ICMP_BANDLIM only watches echo replies, unreachables, and timestamp responses (and TCP RSTs (?!), which aren't actually ICMP). I guess it would be straight forward to cover all ICMP error messages, Redirect Source Quench Time Exceeded Parameter Problem As well as query responses for, Information Address Mask To cover everything. I don't think each type needs its own rate limiting knob. I am not sure of how much use being able to turn off individual types might be. You can always run a firewall on the host to block 'em. -- 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 Nov 5 17: 7:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0446D37B405 for ; Mon, 5 Nov 2001 17:07:30 -0800 (PST) Received: (qmail 31596 invoked by uid 1000); 6 Nov 2001 01:07:28 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Nov 2001 01:07:28 -0000 Date: Mon, 5 Nov 2001 19:07:28 -0600 (CST) From: Mike Silbersack To: Cc: Luigi Rizzo , Subject: Re: limiting outgoing ICMP's In-Reply-To: <20011105165448.D745@blossom.cjclark.org> Message-ID: <20011105190408.F31486-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 5 Nov 2001, Crist J. Clark wrote: > On Mon, Nov 05, 2001 at 09:07:35AM -0800, Luigi Rizzo wrote: > > There seems to be no knob to limit outgoing icmp's (redirects, no > > route, and the like). Wouldn't it be the case to add a sysctl > > variable to rate-limit or disable such messages ? I do not think > > it makes a lot of sense to let our routers become reflectors for > > certain types of DoS attacks. > > The a quick look at ip_icmp.c seems to indicate ICMP_BANDLIM only > watches echo replies, unreachables, and timestamp responses (and TCP > RSTs (?!), which aren't actually ICMP). I guess it would be straight > forward to cover all ICMP error messages, > > Redirect > Source Quench > Time Exceeded > Parameter Problem > > As well as query responses for, > > Information > Address Mask > > To cover everything. I don't think each type needs its own rate > limiting knob. > > I am not sure of how much use being able to turn off individual types > might be. You can always run a firewall on the host to block 'em. > -- > Crist J. Clark | cjclark@alum.mit.edu I (or whoever's interested) could add rate limiting for those types in about 5 minutes. The only issue is testing; I didn't have a setup to test those types, and were unaware that they could be easily abused, hence I did not add them last time I was in there. True, RSTs aren't icmp, but it wdidn't seem worth it to rename the function. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 17:21:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from rose.niw.com.au (cerberus.apdata.com.au [202.14.95.17]) by hub.freebsd.org (Postfix) with ESMTP id 2C56F37B416 for ; Mon, 5 Nov 2001 17:21:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id 933BD97248; Tue, 6 Nov 2001 11:51:21 +1030 (CST) Received: by rose.niw.com.au (Postfix, from userid 1000) id 2546697247; Tue, 6 Nov 2001 11:51:20 +1030 (CST) Date: Tue, 6 Nov 2001 11:51:20 +1030 From: Ian West To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Results from RTM_GET on route socket ? Message-ID: <20011106115119.L34308@rose.niw.com.au> References: <20011106075451.E34308@rose.niw.com.au> <200111052156.fA5Lutl92439@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111052156.fA5Lutl92439@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, Nov 05, 2001 at 04:56:55PM -0500 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 On Mon, Nov 05, 2001 at 04:56:55PM -0500, Garrett Wollman wrote: > < said: > > > Starting at the * (Offset 5c, sizeof(struct rt_msghdr) I have 16 bytes > > for RTA_DST, 16 bytes for RTA_GATEWAY, and then 4 null bytes. > > The first null byte is the length of the netmask, indicating that you > have a zero-length netmask, and the remaining three nulls are padding. > > -GAWollman > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message Thanks for that, makes sense :-) More questions though, the following is a response to a request for 192.168.20.1. The response is a general subnet route, how should I interpret the mask field ? (It is actually class C) I can't find a reference to a AF_ type for -1 or 255, but the field is a bit small for a sockaddr_in. 0x0000: cc 00 05 04 02 00 00 00 43 08 01 00 37 00 00 00 L C 7 0x0010: de 11 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ^ 0x0020: 00 00 00 00 00 00 00 00 dc 05 00 00 00 00 00 00 \ 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 10 02 00 00 0x0060: c0 a8 14 00 00 00 00 00 00 00 00 00 10 02 00 00 @( 0x0070: c0 a8 01 05 00 00 00 00 00 00 00 00 07 ff ff ff @( 0x0080: ff ff ff 00 38 12 02 00 06 03 06 00 64 63 30 00 8 dc0 0x0090: 80 c8 cd 23 fd 00 00 00 00 00 00 00 00 00 00 00 HM#} 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 10 02 00 00 0x00c0: c0 a8 01 09 00 00 00 00 00 00 00 00 -- -- -- -- @( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 18:52:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B2CB237B405 for ; Mon, 5 Nov 2001 18:52:39 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA62mvh79504; Mon, 5 Nov 2001 18:48:57 -0800 (PST) (envelope-from rizzo) Date: Mon, 5 Nov 2001 18:48:57 -0800 From: Luigi Rizzo To: Mike Silbersack Cc: cjclark@alum.mit.edu, freebsd-net@FreeBSD.ORG Subject: Re: limiting outgoing ICMP's Message-ID: <20011105184856.B79198@iguana.aciri.org> References: <20011105165448.D745@blossom.cjclark.org> <20011105190408.F31486-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011105190408.F31486-100000@achilles.silby.com> 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 Am i wrong or all of the ICMP_BANDLIM stuff only deals with _incoming_ ICMP messages, and udp badport ? I see no way to intercept calls to icmp_error(), which is invoked both by ip_input and ip_fw. BTW, why the check to badport_bandlim is not moved inside icmp_error itself ? For the records, the problem came out when sending packets to a FreeBSD router box which did not have a default route nor a route for the intended destination of the packet. Pretty easy to test. cheers luigi On Mon, Nov 05, 2001 at 07:07:28PM -0600, Mike Silbersack wrote: > > On Mon, 5 Nov 2001, Crist J. Clark wrote: > > > On Mon, Nov 05, 2001 at 09:07:35AM -0800, Luigi Rizzo wrote: > > > There seems to be no knob to limit outgoing icmp's (redirects, no > > > route, and the like). Wouldn't it be the case to add a sysctl > > > variable to rate-limit or disable such messages ? I do not think > > > it makes a lot of sense to let our routers become reflectors for > > > certain types of DoS attacks. > > > > The a quick look at ip_icmp.c seems to indicate ICMP_BANDLIM only > > watches echo replies, unreachables, and timestamp responses (and TCP > > RSTs (?!), which aren't actually ICMP). I guess it would be straight > > forward to cover all ICMP error messages, > > > > Redirect > > Source Quench > > Time Exceeded > > Parameter Problem > > > > As well as query responses for, > > > > Information > > Address Mask > > > > To cover everything. I don't think each type needs its own rate > > limiting knob. > > > > I am not sure of how much use being able to turn off individual types > > might be. You can always run a firewall on the host to block 'em. > > -- > > Crist J. Clark | cjclark@alum.mit.edu > > I (or whoever's interested) could add rate limiting for those types in > about 5 minutes. The only issue is testing; I didn't have a setup to test > those types, and were unaware that they could be easily abused, hence I > did not add them last time I was in there. > > True, RSTs aren't icmp, but it wdidn't seem worth it to rename the > function. :) > > Mike "Silby" Silbersack > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 5 19:19:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 11DBD37B416 for ; Mon, 5 Nov 2001 19:19:23 -0800 (PST) Received: (qmail 31866 invoked by uid 1000); 6 Nov 2001 03:19:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Nov 2001 03:19:22 -0000 Date: Mon, 5 Nov 2001 21:19:22 -0600 (CST) From: Mike Silbersack To: Luigi Rizzo Cc: , Subject: Re: limiting outgoing ICMP's In-Reply-To: <20011105184856.B79198@iguana.aciri.org> Message-ID: <20011105211012.V31861-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 5 Nov 2001, Luigi Rizzo wrote: > Am i wrong or all of the ICMP_BANDLIM stuff only deals with > _incoming_ ICMP messages, and udp badport ? The current setup is that badport_bandlim is called whenever a packet with an abuseable response is received; if more than X per second have been responded to, no more replies will be issued that second. However, it could be just as easily used if hooked in at the output stage. > I see no way to intercept calls to icmp_error(), which is > invoked both by ip_input and ip_fw. > > BTW, why the check to badport_bandlim is not moved inside > icmp_error itself ? You could add a new limiting type inside icmp_error if you wish; there's no such call at present because nobody thought of it yet. > For the records, the problem came out when sending packets to > a FreeBSD router box which did not have a default route nor a route > for the intended destination of the packet. Pretty easy to test. > > cheers > luigi Ah, that issue hadn't come up on my little LAN. :) Sounds like a good place to rate limit replies, though. Just add your new types into icmp_var.h, add the new string into ip_icmp.c, add calls to badport_bandlim at appropriate locations, and you should be done. I'd be glad to give a quick glance over the finished patch. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 3:14:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [194.98.140.18]) by hub.freebsd.org (Postfix) with ESMTP id 7934937B41A for ; Tue, 6 Nov 2001 03:14:40 -0800 (PST) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.11.6/8.11.6) with SMTP id fA6BEcr01312 for ; Tue, 6 Nov 2001 12:14:38 +0100 (CET) (envelope-from c.prevotaux@hexanet.fr) Date: Tue, 6 Nov 2001 12:14:38 +0100 From: Christophe Prévotaux To: net@freebsd.org Subject: Satellite Message-Id: <20011106121438.120754aa.c.prevotaux@hexanet.fr> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.7; i386--freebsd4.4) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I would like to know if some sort of of ACK spoofing options are implemented in FreeBSD 4.x because we are using a satellite link and we need to be able to do these things in order to accelerate IPSEC tunnels over satellite links -- =================================================================== Christophe Prévotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 BP415 Fax: +33 (0)3 26 79 30 06 51689 Reims Cedex 2 FRANCE =================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 3:28:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from bluenugget.net (bsd.st [64.3.150.188]) by hub.freebsd.org (Postfix) with ESMTP id 4200B37B416 for ; Tue, 6 Nov 2001 03:28:43 -0800 (PST) Received: from bluenugget.net (windows.box [64.3.150.191]) by bluenugget.net (Postfix) with ESMTP id C057E1360A for ; Tue, 6 Nov 2001 03:33:32 -0800 (PST) Message-ID: <3BE7C9D9.9020306@bluenugget.net> Date: Tue, 06 Nov 2001 03:30:33 -0800 From: Jason DiCioccio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Tunnels with IPv6 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 Is there an FAQ somewhere on how to delegate ipv6 blocks via gif or some other means? I have a /48 prefix through cisco and 2 boxes using it (using ipv6 autoconfig too).. However, I also have a box behind a NAT that I would like to be able to involve in the fun :). I think the only way to do that though that i've found is to have it tunnel to my freebsd box (the box behind the NAT is an alpha running Tru64 5.1).. I have, obviously, successfully been delegated a block. However how do I delegate a block, or even an IP, to this other machine? Any help is greatly appreciated. -JD- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 5:13:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 0D37837B405 for ; Tue, 6 Nov 2001 05:13:44 -0800 (PST) Received: by hanoi.cronyx.ru id QAA06819; (8.9.3/vak/2.1) Tue, 6 Nov 2001 16:12:21 +0300 (MSK) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id QAA06804; (8.9.3/vak/2.1) Tue, 6 Nov 2001 16:12:20 +0300 (MSK) Message-ID: <3BE7E1E5.4040500@cronyx.ru> Date: Tue, 06 Nov 2001 16:13:09 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-net@FreeBSD.ORG, vak@cronyx.ru Subject: Re: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011103182927.F43204@uriah.heep.sax.de> 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 Hi, Joerg Wunsch wrote: >As Roman Kurakin wrote: > >>>You've already got one from me. >>> >>I thought someone else maintains this part of kernel. Was I wrong? >> I could have been more curious and checked developer list. >Probably. At least it was me who wrote larger parts of the current >sppp implementation. As mentioned, it's very unfortunate that a >number of offspring implementations evolved in the past, mainly in >ISDN4BSD and in NetBSD. It's still my goal to merge the ISDN4BSD >version completely (there's no need to have two functionally very >similar implementations in our source tree, and i promised this merge >to Hellmuth Michaelis), and my review of NetBSD so far has shown that >they've also fixed a number of bugs (and added some useful features). > Original version was written by Serge Vakulenko ( vak@cronyx.ru ), and we together keep on development and fixing current version. (we have numerous fixes in PPP and CISCO code and we could offer new Frame Relay code). >Get me right, i wouldn't mind passing this task to someone else :), >but the issue here is that both trees should not be merged as a large >blurb diff, but patches should rather be taken piecewise from their >trees so our CVS history remains clear and the impact can be >overlooked by someone else by just following CVS. The NetBSD CVS is >now publically available, and i've also got the ISDN4BSD CVS tree >here. > We might synchronize our efforts somehow, but I am not strong in NetBSD... :( I plan to make set of patches, but I it would be easy for me to make a new one only after previous, cause some of them could depend one from another. >The downside of all this is that it takes a FreeBSD committer to do it >(i expect some two dozens of committs approximately), and someone >who's got quite a bit of time at hand. > I thought all FreeBSD developers have access to FreeBSD tree? Best regards, Kurakin Roman > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 8: 5:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by hub.freebsd.org (Postfix) with ESMTP id EEF5237B417 for ; Tue, 6 Nov 2001 08:05:05 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 4125374406; Tue, 6 Nov 2001 18:07:45 +0200 (EET) Received: from nomadiclab.com (ws211.nomadiclab.com [195.165.196.211]) by ws34.nomadiclab.com (Postfix) with ESMTP id E3544BA21; Tue, 6 Nov 2001 18:05:00 +0200 (EET) Message-ID: <3BE80A2C.5020809@nomadiclab.com> Date: Tue, 06 Nov 2001 18:05:00 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5+) Gecko/20011101 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net Cc: Marco Molteni Subject: A minimal IEEE 802.1x aka EAPOL implementation available 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 Hi, My IEEE 802.1x EAPOL implementation is now minimally functional and tested. It doesn't include any EAP modules, but the EAPOL state machines seem to work fine. I'd appreciate if someone with more experience with netgraph would read the code and send comments how it should be improved so that it could be included into -CURRENT at some later date. I'm especially worried about memory leaks, I've tried to check the paths to make sure that mbufs are always freed correctly, but most probably I have missed a case or two. The code is available at http://www.tml.hut.fi/~pnr/eapol/ Right now I have only tested it under 4.4-STABLE, but it shouldn't be too hard to modify it for -CURRENT. My problem is that I haven't got any test machines running -CURRENT available. Yours, --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 9:54:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from Ag.arizona.edu (ag.arizona.edu [150.135.40.100]) by hub.freebsd.org (Postfix) with ESMTP id 38F4237B405 for ; Tue, 6 Nov 2001 09:54:13 -0800 (PST) Received: from petros ([150.135.40.122]) by Ag.arizona.edu (8.10.2+Sun/8.11.2) with SMTP id fA6HsCY02133 for ; Tue, 6 Nov 2001 10:54:13 -0700 (MST) From: "Erik Norvelle" To: Subject: 4.4-CURRENT problems getting IPSec to function Date: Tue, 6 Nov 2001 10:54:10 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01C166B1.5C2B7140" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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_0010_01C166B1.5C2B7140 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0011_01C166B1.5C2B7140" ------=_NextPart_001_0011_01C166B1.5C2B7140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Greetings: I've been banging my head against the wall trying to get an IPSec VPN going between two FreeBSD 4.4-CURRENT machines, which are also running IPFILTER and IPNAT. I cannot ping or otherwise send traffic between the two private networks. I have read and followed the directions I could find on the net, and have done what debugging I could, but am finally stumped. For the following discussion of my setup, I have attached a .tgz file for each gateway machine that includes all of the relevant configuration files. My setup is as follows: Network #1 (192.168.1.0/24) | | Gateway #1 (inner interface [xl0] = 192.168.1.1) (outer interface [fxp0] = xxx.yyy.40.122) | | (internet) | | Gateway #2 (outer interface [fxp0] = xxx.yyy.40.135) (inner interface [xl0] = 10.20.0.1) | | Network #2 (10.20.0.0/24) The result of my setup is that I get the gif0 interface created and configured properly (in tunnel mode, using ESP), and I setup my policy database using setkey. However, I cannot ping across the two networks. For instance, "ping -S 10.20.0.1 192.168.1.1" gets me nothing (all packets lost), and a "traceroute 192.168.1.1" (from 10.20.0.1) reports that there is no route to the host. When I use tcpdump to inspect traffic, I find that my ICMP requests are being forwarded through the external interface (fxp0), which tries to forward them to the internet, where our router naturally dumps them. I am under the impression that either the gif0 or xl0 interface ought to be receiving the packets, under the routing rules that the "ifconfig gif0 inet 10.20.0.1 192.168.1.1 netmask 255.255.255.0" command should set up. The kernel seems to be oblivious to the fact that there is a tunnel set up, and is happily forwarding *all* packets to the external interface, with no ESP encapsulation. netstat -sn reveals that there is some UDP key exchange traffic going on (at least, once I start racoon). However, there is *no* ESP traffic -- all the counters are zero. I have included the following files for each machine (tar/gzipped): 1) The VPN setup script (tunnel.sh) from my /usr/local/etc/rc.d directory 2) ipf.rules and ipnat.rules 3) rc.conf 4) racoon.conf and psk.txt 5) netstat -sn and -rn output 6) ifconfig output I have done the following: * Installed and setup IPFILTER and IPNAT. These are working great on their own, however there may be conflicts with IPSec that are caused by how I have filtering/NAT setup. IPFILTER is set up to allow ISAKMP traffic, as well as ESP protocol traffic through. * Compiled IPSec into the kernel on each machine with the following: options IPSEC options IPSEC_ESP options IPSEC_DEBUG pseudo-device gif 4 * Setup a VPN startup script which creates the gif0 interface, configures it, and uses setkey to setup IPSec policy. This script is attached, and is called "tunnel.sh". It gets run by being stuck in /usr/local/etc/rc.d. * Setup racooon to do automatic key exchange. I have setup a private shared key file, and then I have added an entry to rc.local to start racoon on boot. Racoon runs with a pretty straight racoon.conf file... I have only modified USER_FQDN settings and other minor stuff (I think). ------=_NextPart_001_0011_01C166B1.5C2B7140 Content-Type: application/x-compressed; name="gateway1.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gateway1.tgz" H4sIANMi6DsAA+xc62/cNrbv18xfQbQo6gCxI1KiHkS3QJr2tkHTxEicu/vtQiNRsRCNNCtpanv/ +ntI6sGjEW2ncdKLi2rRzVgifzw873P0KIusqYvy/Vl/3X/1mQ7qeaHnka+IOpb/EsJ4SAmJ/Ih5 jHqMEUIpj9hXxPtcBNnHoevTlpCv2qa5lQFXl1JWX4KgL3tcV54gRZW+7/4Rx4H//bvzJz++ef3s p+fP3l48efPu1asXr3558vbF7+cvf/7Xk9/fvbx4oa78QHb9gVDueZtHZS17QhN2RsP4jJ5RAn/v 0u4D8a4LfYDot22T5lna2QMZ52ZySAoZe0KA8AVPi0IUMgxFxAL6LVBH9q0syutK1iQMSJc1e1nm gE3J5pHsL2VLPE/omULPEoG6spN5mQrysxqg6EsPfdPJSmY9OQF13KadvPjX480jEH5/6ARJs778 Q26K6/2DsOP6+vrs5ubmLPDOKCj0giMZ4sg01l9hSeqJLNEs4bmgURh8q0h08YSRtfWDI4kUxdr6 euwKAE3uD0CTNQo+AoCtAsQfARBbeqHZJzTrBHDqT+tFZasF9b4/f/3i1cVr/f+3akPVzPO8IFHq 9PL16/Mfnz3/bdKm5bzQj4NRC4SglqwVH7B+0G9hBZc2BKM2UBadefA/bJqePshmv7c25y02t7ap bnYZ2XL8yxevfmPLWZyzTZGW/aW1jud9v4b9viysQZwqjtn4LqaxGEyvP9S1rMiaBZ6e/oBO+Xf7 HkWKi7UxWfF7ag2w4LPxP2/NE27+aoe/OMp9cdYeKtl9xjVuj/+UQuBfxn9Kg7/j/5c4vvnEY/MN eX3ouzKX5EXdy7ZIM7n5ZNDNN6efdgBZz6qquSLNAZx8VZGL5+dPyLufzkla5+TF89/PSd+CvZfZ E33mg5R7opy+JE1Nyh7mdw3pL9Me/viuUxDNlczJNs0+gIM5+3QC92nXaer+fSgBE1YdInvTw8LZ nhRtswPabgj8rf6ZSbx97iH/83PLbHfr5IeQy49VA+tqfCMBw+asSstdp9bcSkPC12Wt9OpruA5n ylZegRQAYAvEX12W2SUpOxWgD3D6hjRt+b6s076s35vpjVHLBxDVVlNc1qRq3i/YpleygsBTyLYM 2+6cBZfT6rKB9OWeEzwdxL2nPrvvDDsawX/WzIczMFg9k22fwr9gY7NMG9LJ9g/Zdka8FaRRINnL EowN5AnTR4mSk7QCW6ulzDst6q/bvP2a5HBZJ1+dWuKp7LOn5R7ka6LV44fYwH+/ej7Sa8wCFrrT GvdN25MfCAQqX23SqmcUe/XVfxCeQLyzfAocsN4buWvgj2f5Dhb66IWdiwVxkhwv9uvFxflbWxy/ TNb/Sdv07ZUDf33hz7xuvMLct29//cyrQmZy16q/gxk8wKrxHasuWfwZll1jsV725FwNiL04fPzZ SYjDu4jgX4AIfkzET6+QaeXVH6cqfyQnyotBmlA0LflnWTNVYOXNTjnHNMtkB37rz9l7YDsX/yie O/CWqcB98I61a9zdA3A2uEPDXpy/lRmcviHyOrtM6/eSnChwKwGAfAwK9uJ2Rk4bxzXfEABxbWhz AirQPw9rpwEYc9zYxcDUE9ntDWTWVMudmKXUiI/YwTKtuwXE7HgBopGP965rYJPjeGdM9xCGDAfn PA+aGOY6nVGibqUyHZXRjeqYNTv1Z1kvtAKmnw4AKgu5KvtLQCJv3l4oYnfpBwl6Q9L9XkKxl8Im Cz1dpSilKlhA/cqu/k7lKV0v1ZIWoiobRkRdOmjv865uZQpKuq1ASfOy75vH1pxj0tV6TQW+Ie0u y6YGL3GV3jxUctrK/tDWpy1kk6vpoLOswPNV/n+adqe57PoTpcCnh7p9fBvkSrVxW1qqRPXp5SHY U/3/sOT8VAKOSzvTP/9TFeU89aMLynnqXfWk0ZSjyUZLHkoeKvj+ZeKwvenHSWN95n2EsT7zfrJY zn0og33ZNHvdPPk/abISCtWb/nLqHShfXY0UlyPF5GTsCZkKFoLR/gDXSAaBoU+rD4qrY3ry8Oqj Wv1KHMcGN16B42P7f1ZN/Tnai/q46/5vCPnIov8b+P7f/d8vcUAJK3ty2GuVfyX7q6b9QJ7leQvF ispX665Ke0hXyMmrZxePSSFTSBRUI5BcrLVq8kbnvadQAF2lbQ4GdXZ2prBvwEgOncSpPJiLarTq +28wvbohLei1JHswO9l3uowq621zAP/cyn8fICvRHcKx4WQahJDeZWC6sjvbfDN0dYDec9m3TbcB Ak3mgW9zTgm67tSc/mC3VqwL4KeXfZv7Q+u+zBq0vmCgda0FkLpdsQpIkwkwXlDqT6dnsLf3RlPN mzU4dd7gqebGfdHUPbYVMDiNN6pL9HXOuTcar2wUNSLuDxyHDmi4sAbOPwqcu8A5Zum98JYsjRcs VU0IwJrK83W8uZnBF/IOptOA9xQSC0tM9wZdiipAohrdxC7dW26CyFpVTTqIGeMG3/KEbG901bTf 66oJptUNVDQwRg0GpMHaU+OcYPpJeSa1c5nWvz67fmwNgI2oqy/Ox3OA0hRr7YSzDSxsNjrvxVO1 LuzOG3erxgy8Us0NLkKo7r27pt4N3TbXQ9Ok6Pfqv6ewypfx/zX4WUj/Ttv68z0Bdnv8Zzz07Oe/ fIj/jLLw7/j/JY43YF/a3rRFbjY6PQelEJufINrqG2pgRcOhIsFVekOs47/UoxrqxxtZdObUOwjz KpUoC/Lz9R7sbJPLIj1UvT3PdifDqXe/vM2Gn36gHwxIGAvhh7KdzfwQy3SsnHr36/zbQz8gR97M iz5VaaY+XdYfvmE2ZeTd82kBGpl/wzAa6Vgh3BO5J7aZkLmg8NPQ8fKf4164TYf2AxqZ2lD+BGUe ZUsKwUMRpBhq2BKQk9hQQWRDBRNU6IlYJFL4TKQZcUDxcIYiIU1sKD5BUeELFosoEbkkTihuQfGE 2VDRBMU9EYgoUtQl1AkVuDdI6UwVE0EkokIUuYuqhI+8Qhj+iJF6ggVKbluxTZ3kUGtnzIsRVGDx OwFqYsGY8ItVKJJEFhSlNLSh2MDwWABRAJYJ3xNF4KAqCBGTIrRBFo1UbbV6FpEoRJysQxEexRaU xxC/uYeh0q1IEtB3B6+oDUVDRFU0QWVAkuZ8Foo8d0CpWDDrZuQjqEkLjARZKmQhwtgFZRkfSfwA QSUjlASdAvFBYE9EsHWwPY5sKI42GE8b9JVmpr6IMpE69SqwNkiph9geMwSV5Ir9UjqhbOOjEVLR eNJ2ML48FTzSKurwLjy2JEhAyxDUpO1M84rHwHNB+SoU8SmzN+gjnxdzi6pApFI9vWsoXZXgmguO wxHD+M1UxLkIt04mWRZDIg95qHiyGOVWWCQCLgZXs+ZWYhsqwX5TM9DidxwIH2KD7+A3tVwwWAzS gmRikjE+SZXF6HC0AuUltnfxGPIuyYJXEGO2oaAuO+ZIzRdUTbyaLSYSnDk2GKHIhwNDMvBq8Hlx JLbsOIhOVEU224MAKVSSIKgMdCoR2h2tOyrEduyJIWVdQkXG5a0qQ2Cr+YLtYNYDrwAoLQTz1Y/I 4V1wEI2wHYN8B6j5wWaQoGuDyLt4AcdBlB1BcbFNHFCh7T7jZBGPgyVULrgz4QhsvYq9AEPxAQri Q1Do4J6KwEUVRSqK9WpoTtye4C2SxKMswXRzPhEjxFvioijgt2NLzE7HkpBiqPgByHkAtvijlGbd CcR2mfEY30mTENkZ8zHUyB2dywU6zDlzOe4hjfawnfnxAKXDifIiUuSFAyr0UJoSYePwRzszJusn Sg23Dqcbog16HJss98cNaqfLIKsPRbIeLxfGEYRYo6PRZMHpbiHoUhHmwr8XVMywBCN/BYo7rd9y b1CbYZONgiMoSHlcoSCxqAJrxxKMxw1CgRACv0WUi8Lhv5nnIShcT9F41CtVBGWQ2ivydPi/Ky+g XrigavTfwwaZgFLPkUnjDZIIJ5o0HvUqgMwpELFReZcEE+R0F7xKFmyHqAL/OqiKUAGTYGVg3ghl 2J4KKgV1GU5ks534UYChYgQVqbwncoaCBJWxITIcRrHhJELGInbVQnOBTo6dDGOjBJWTyaRKNanT ySyS8kVZxcYNmmIPEp/AnWLwCFEVI3Nm/rhBU8AkgchDoQW16q9sG4wYxVBIgj5UHVQ4U9fY3iCB cmaGUrcohrHGi8a6gOGOhFoZIbFTDM+GWvY0IPEJoHSUrg3akY/bXpRaPY1xg2CFznSMB9i3I6i5 p5F4KsuHuhGyDO6oG4MEl+vUhgpXqQpdVHFL20lkl1XUao/YUC5t53aSCF4UQcUz20HbwRdvC5G7 yirCEluvkiCxoZKFBJNYsSt01o02VJwgZaBTYTxQlVGIrA6qIC7YaX4Yhwhq7v9YepW7qqsIdUl8 H0FNNbat7a4am0f2BuEEgppq7JkqDtnROlTojzaIMKbiemYSTZ1MQsW153EENdWNugsIWVqSiNxp MSjURFih6Fw3DjlaIkLuogo5KurFiKq5lQTJcA61VQhOL3BBxTGCihC/o4kqLTqp0qo8dvIqsi3G CxHbo2gJFQ8N0/W2G0r3YmzHUyvJVxkVhdo/Eb5ToewcjXo+oiq2LMZXeaOUYH0Oqkjio6jFkM+L J4sx+SzVDdjIlc/iDh5LsMXYiZXIIlFwwZwbRHlH5GM7nsKyaQknogDDcbE9pMglRFjbmZX756kK f4kU2XoPFhwVzoYYhkpmKE2VFMXWRRXnyOcx7BI4nSQIeQcXcSgGh7OqDEivPMwrjlJjP1bOhbu6 JBxF+IQtPMNYvUHmyBJFFBRwrsYpj1GO5mFe8XCFKuaiykflOl1ATTkaqGigyohtJnyH++RY23Es pXxUBt04hczYhxTZyXYPKQP2DDT0lrwK1SbvpQw8wlCjMpjMEZK+CHyEs05CycKC7SFWBnANvshd FUnI0AYXYSIck1BjOAxKZqidnc0pZIMhUlHm0RlKJcUi2YrQmQ1Ru8+VRD6GGqkaeAW1vGlUrlNl 8yr2FlB8htLpCy/E1umvYnzHIcBQRq/YUFPGElwDdXbfKMocQ46hpkJwMJyEC+nIshkN0AaxijLs RaG0Uf1h5x0HdB8kwF6UMdRBSVPFLpNI3MmrhCcYCnlRqL4ToIusQxGObl5EHFM11Ummptwq1cpc G4zRPaPY9u3MumGrQmpeqPDFnZ7BC3CYiG0oZkExlREVBVihC2rRIkpCG8pfgYpdd1kZw2UE9W2o wIKCDYLZgPE4C0FEFQlttjOrItGG4wNlonBuEEswjBPEds+CUndIwbdzU8uvdgVQRUIx1OJmK3gG 0IbIkfuHIVJRu23NrLRW65XyfBAvXP4qDJEy2H0ddsan3F/zSjkGSBpchoPbaQlHEuRT3m5StaTQ 3RgXrzjyVxyp6BCcCWeq1+Sp/gmEVO6634Oisx/jDU4Z8nDXLxRBLmJXmED+inAMNWXIow1uhVH2 FSgeJkivsIqGU/UGwVS1FkRATRNztdLFd+ywBKk3ZjIxoOU6GQVP6tCrCOUMUKcgKGbfWVHNE/Ds gjn6OjhDTmLsrzhKtkEXoI7zXflVGNq8CgJMVYQDPRRevg9ZjQPKzvpwH1pBjWHCJEUQUFNIs9ah COMoDgbJZnoKjkyHvhth/U3w3Yix0WIwrytvYz9TO16zbz+FRy05M4765talerVBh2W2sZ9ZnaCo VijwUn5gYs3Rzljsm3sXBopwz4YKZij7/tr6LWCoXkwDb6DKi+0N8jWoUND11BiY5VlQoIwb+wlS e4M81coeifX2JYQpk0gPG0yS2IJKZihft7MVxzLHgwChZ+4mTxsEO8ZfyjHCsT6mMxzO57nUm4nz 02rh6uNqi2Pl6TXrmB5kWzy7JgR1zBiP20fYO1DPoJnvDakvmz0Ng9UZK8Zg41l2oSzh1m+n6ePo 82gL+l6u0acM1kHgyq3Ddfp0e+v2D5kZ+haf6boPffDTxT/701gr9GXz7xnPNXra7/pSbvqUft7G v3jtisab+ad1/PbvU90Db0lf4VEhnvpOAd6lz/ZODB4b9NmB+ZH6bPC0/q0DfqT+GTylLw767tiv RZ+1Xy3fW+i7t3z/4ud/x+e/u7/s+W8a0bXnv/9+/+uLHH22F5tHic+nl646WfebR4/US3l52qfT +ZMgUWnh9qZXn9959MhbXPaGS+pdcvXe2K7se5nrga0E0Fy9zVj2JUThXL3r8fvFO5KXXdaody9h mA9aAFinTV3dzKgs8Ukuq/RG5mbRd29+IfYQffKqrPPmSr1IsZVrFw77PO3tK4xkTd23TTWfg8Iz nNZtZSbLPzT5IWS2cBZoUa+jAROSYGYC8Oiwr8pMoatBelE9Wg0+1IqZmk9wIfJm/BM/CAM2c8ys Bgw67dR7bnUmNZJ6w7SSvXozbl7niON6qPq0wNEYfWUcrz9h0DU7qcadGemNGOrUyOHm0J82xWnT 5rJ1LHYs9KYwgGmhXog1bD8Sze0y8Y64P6BlVdMZfih9SdvxCyvbNCfZpQRuH3ad4/qlTNU2mqLo ZE+KUlb5cuhWmlcTzeqkbxrSXTYtGIESQF2rl5YgqRxfQNw88u3T6rsue3XWM/RYV0D/d8Ml81kJ AggHSZTGF1VztYDqCMCnWxh6CVSdlHVWHdQblOMSwPoIDdd8QSNhW22z10KiNimG10BdminsNxcX 6t2oka93Df0jbcsUVNKe4yFKFpO6rr8Em7+0JnhE7rbtTVPrj3jMMxW9e2VnocfB9bzfgcHMeG3f kxNQLXVxZOfjjfYoo48hfbmT6ltvR0QN0Oa9smtrqALYy7Yru/vNXoxV09V786n+phkCmE8bfR+d qRN6mrB5BLEPRrXqHTny7Plvo+buW5mXZiKoSxBMYyzvuzb2kCvHTpOYwxw19n2b7mzH5hmHAMoz OJkBZbqi1FkvUsn6PfytjQddHY1vOlk31jk/Bk857jUHve8bNaBrFMmwX5/S+Ru+T3eHqi/113xn Yt2TveW14lBVw1WyPRQFiEyNqpteu4LLVBvVPtsqnjDfT1RUAUa0ihVwJvB8a2EQ6B4EXSoW8iSm QQRr9Gm1Eh88281Y3mjgSFf+R5Jul1YVXO4v05rsIAruLJ5pFuth39vsngW0HwXwA9ml1+rvQepq 0jRsoGAY+v0MixearqPxSKrNftA2S0OMyqnP+SkfUR92W6MoRZsOJmtzZD47SukE4gsBOajPFoA9 d7AD+Xh9qPH5tqlOPE+7DrxIBYOaD6BAHo1BMPbL4v1l2RH1TUV7nonEH+rmqn4KEfmwV29aKmUY PsAESHHsR9yecGVCw4mFolRzugK001EMg46pC/pNVVD840hmEUFmVX/fNoe98Wfm7djRY9AkUQ+P 2TnZ+GWKaYcBvqxlVaTbVmcAudKT2aCNQk8Tjg0LbKZ7QmSfna0Nn2LlPEG/qW+NnY1nFOlSFzIQ 4HByHmy+/ZmqTy/p737aU833nFVcGwmxRhfqS5JQQWG4SYmHF37VBzQGLqjvn4jBK2Vgj/pLAurk /8i2bTSX9I9OC/S9rGWr+fhddviPzq7+t71rb27bRuJ/i58CR3vmmhlZL1tqYsczl8Z242kevirp TafXYWkSkpBIpI6kbOsy+e63vwX4FGXZ6cXp9cRpY5FYLBbYxWKxBHdnhM8dS3GN+FFUz2q80V0n liQh2if0DelNaHDkfLo8xGGYb+mRX3BNLfKoUYcCtKBdg7lAvhf6MrNWCgBPU/VRmLgVM6gOXQ6c y54h1ERVUOMgjPSw5yCYhGSSzOY1cOdBbdfTTuPfbMSIE3PSKERRNqyEACF4UjZxmOwczI0khA6j 5FtqzIwr9Kuoa1Ye6l7DihvJa22e3gJXXcZmEqotntDsoR5HaqW1tcWpsryi9dzXvPtGGyuFSiQY pHzW4qwWfxZO1jWsWVjEdajca0RfnYbBeE1lVjtqHkuPhzqNupFOPNKVCF8I227BgQyx3i7rIK9U OHWNegUgYfYWkUrwgTttTmrrpLbD8Jlwr1w11Wq0k3W8Al+HYkTVcv2kSM0jtJOCYqTehlFtu6bS WCb8DfTw4vwWKJq8z17wzHaXWmRuBz4dXmyEJqsQMQ0iLHuLZELUKu92rBkYqxOjf+/KqxXQuzBr pdImblUr1CK5E7/WNq0XHzUfsLCuN83+SybYH9EqykF4UZQ3ng49OlW007nNbOrcyWLSZk7x4YqZ U2O19G+3WDp/doulZKdkk4vzRgiOsVVeXzOxTlW0HwLt+1DRzH5FHeTQbLTEKi8+1L6ZQIoZFWQ3 8ibJHyTXIcSJpk+xoOABIjak2zy9yIKp8ISpYBEu4nsZXWuHGkvvjLSeaYeHlGb7IkJEFupSuIi8 LIxLGv1J6zIjX9qPQMZFsvpwpuKYbTk99+9jyaWOnjpjTtfA6MXhRgS40xPNaOE6QzBns3b+0PTV iy2ZSPtUHkg1nlxyg6RqDapD0XtQg/BFSjE4o4cgA9ah+LPeawHM5xEcnYiIRRioXIfvomVkoi5V 6ve9lMswMPJvKmimF6xg7fhD7JuVh7k/7lKNtYCT/jOqTrADSCUrzzN9t+QidCogpRmnO17jxqAi NOiF44AUvy8CTJhU/VQLtfI3vmyt8wwQ7+gKY1xv61ZZoKdIsBSvT4oLyyqfyuV4Uis2Wc0VKNen 5YlUiJzppbUMxqzcgMrAbEBkRqVUMHepF3Dz61DOsbYvB1sDc2tg/m8YmPPRB7nE67F8/8uGC+Kw xjKaugHN7f2+eY9TU5YtCPD1phoiWc4llGkkx1gYokNxQHej6SKe0NJAP2+ceO6TquTFQN/5C9oD 54U5cFVppGNU9dnWQ6Wm6wawIuU1sKU3JmUMeqg5fY4WqNQUWAXNX16RJpZBbKSvnqIMhGlaDxe7 GwDSFanQZpXbbMXmPH08OCjyu1L6oBxPQjaMYtItU5n5xgcrAG7mG8d7zpwsXZpShfkcZhPqrnz8 2i+wt9fvuubxhy+Z+pWvDfF/9VfEpfMfnX6/sz3/8RAXUlNcHbSvBnnYTCvL9aDP5/T2D/qD/sDa Ee+Gpz86Z38/eW2x5f+3MWnr1mypM5y0PKSJyIEZrlRYuDK4r93///crcr0wBHuC0RdrY8P8H3Tw GWxp/ncPOt3t/H+Ia0fs/vDs1emhKAhCSwXNK9FtdR9DNXfbncft7kB0OCzBAZnhSfh+EeB8tNhF hF8b+zxbzGgk4TCgDYnHvpIR3FAqgWm4mOIBzCS/RTV+DhccMx8HYa5pNyCNB2xJz305UoH0m5zm L68NRwxcL8aeB5kL2D0ti3eZ+giMFHZ7EUdtTq3HKeN0r2xxZO1kIBGH8+aeooAjkLsRNc+eyhFt G9gzOo+kE09cMoscJCRiMwgnYeBKOD9BkiLTdgWwnoS2WWhNi/ohISXLbBqGH7hFhDVXI20DMxlK xy/WW2uyv5qIgqzjFxdg28V6xnSlDc1yGtLGXOU+aENuEbpKK8oMhfY0HNsinkuPgMkMpNsx9rBT eSWnLSHOE+AehWlizKWQitMu28QqNVraTWH78nIxthF0OTI3PbtlISsM3xwZ6fFxdsk2nI/1EbW5 Sza0TPjoljAg1CokpyARSbhgvslYoncMZX20GjP3Bj4xx+yCep2jxo4wD1NsZovUshoRWe7hDO7/ cDQ6ahCoDlAt8oIMNk4i5SUOb7g1eAati/RenCDlDclbTAPvJGQqZ7A3CfE+EVM4BuHADb1EJi3r k6V5S3tPc1YsD5dN45zygeZFSXQ0KJJ5cA6kbLtcSFqRres08gyOAdpRsfthNuezz7982+l0fj3K H5IebvUOnrS6Xc4e/kvfFPOiz+C9X3mYyv6/v8baj4djTbM5PNc0CjtmwAwVR4KqQUYVuySoC3m0 7lSB8I7cjMhQ99vsOXDI0IQSTmciPH9Ry+I/3DHxFtJA5VPSFFAyhFH7n3wc5BJ69tM4IzVow6O2 IGR97k8qIUm0hIBwoc5kCYIaPKaEmAYIfoyiTGVFSWhOuxI8zo3RL9Fl5BzRnF8RaZE2vhS41kwD oJ47wtrg2lU6MnOYHQMV8I+K+cSFuDf4b1fsa2LMfU90+/qexs/01Q3CYDmDfx8DlGZWc2Yh504g Ze+Ox+AB8fCI5bZQnhc1AUrlfqgEO/Ic+kX3sUoWmj3Kh+MoWTo4n3uE7syWjn5IohulrKY65efY PTujf/mBsNfYlTa6J2k4719tp6DvHHZg3PQ7T4Q9W2plRz/mkbqyQS+Nk0e6HBO+O6C6UzWS7Frm f7pwtYPp1Pcm/WySHoogFTjUPHXwGgUzO8QgmVNGzkzNB/rJPArnYQw4rTou5RK48LeZqg6sAUiD a+Xg4iMOVgRetGQ3sONOxyGtmJOZ2PclhrKBo22Fx7QSdfG47MdzSJdOQr+6VgHQnzh8WED0cPup IDesHJCq/deHFpw/kXx8ZVbG1NVRWFYB81Fs4Lornci0yVpCgbpCUQ4wmbmeY+iG1mIRKEGQAodH WBwVqTNOuF5nH1+XtromRALekNSWkWWKRHO/qy936srM739WTzB1+CXl6pNNVA82cqAp8Fqx23tM RjJZXyMVT/C5b/NuXQJ3mlnvxN2697W3KdvrC12R92X3/rg25f/qIjhXxf/X6233/w9xwV5Od71B eM2HQUiVxeI9rHHOWUqb9EhBtfCrDt4nGis8bhvxIUv9YirJ/NSpVmHXm3e+fCAkbYFMXFNTv1Q+ tosRTW1rrL/QdvSG6tj++XRocw6hRcSJt84vzs5fvj39scmEfTc8ydL4pOdV3DGOhVFbhL2MRs1n pN5qHo3w4fexvXcSXwV4FrjJKgHU3Jh2Z9mu6pv4EbZlOrvQ8PS5OTYjyLxZkHWT5zjUBk8J3w5h cjIQahrfgXIzz2ko1XgR6TRp6RYnB21xkmR8qWza5qLAndYkK0TeNZONmjZk7wJ1A88LPgrP6nI6 pXyjyOd8XJzmcuk/YZhhTokhH6JHDQU6RRyh4u+3DS58AFODDBtXSftTIiCnFrtdg6U0CugWyANe W1hq5PFoOPTs2FZUoxQfgO75zHApjICd1wIWU60U/bpXU7NXqkl0pO2l+WWYOSZPHnsnkFFqqkje aS0u5ITMs0pVdue866dacZlAh5HU0nlQ20P6365D0a1B0X1yLxS9Oiruh2K/DsXj9Si2VsXXv7Te asWTL9jGhvV/vzNY8f/TtV3/H+La+Uv7UgXteGLtWCcvf3LO/uGcXxzbBVVrp88v3n3HZWV9mhW/ Pn1brIcMd7b1/NnL4U/nJ6dvMsTpu8VKWR3y/X4FSDdhMOgGvj8/66QrKP1+/ub12fn3x9qvHaNn 41RR2VahmIvykhdvhm9fP3t1evwbjwZOKwfuTP5mUYuvng1/OLYr64zFX8/Y/wyGJD3spuOF3pgB WHv1gs4HiFMzgcq1fbDnS6Sdb+LkBq2VxogS13z610cOYf29WNzK1CwHizAHki3Lg6m1m1JNC6uF iTS6Lnk3HlnFN667ae/FLsYsNVh2S8wVuzVMuRUNK/zdTHIqCPDADGEJS86eWCbwXuydXWwC2FDu iadPxembMpg+VZPRR6RUCMQTeBn2LvgQPjOxhEHG87Yeqvbux6ybn/Z2P1Y6+qlt3NpHtRSstFqk yVCAjLa3E1Btc69IU04AhmGnwePEY6Sz6mqL/BZSiNVc6egoFSey+OIrMuzCFtmi/w4DtyX9xSMN tU6gaiSoImX19bUkrYhPQbRSSWqsFaF1JesKMqFp3JdXubQ0PpdLpTbvIqGZfKw2eUfJvF0w1tJQ EAwZu95npBnfXttre22v7fUHu/4D59P6zwCgAAA= ------=_NextPart_001_0011_01C166B1.5C2B7140 Content-Type: application/x-compressed; name="gateway2.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gateway2.tgz" H4sIAEkj6DsAA+xcbXPcNpLOV82vQNlbFbnKGpHgOy6bOsdxElUSW2dJtXufUhgS1HDNIWf5Ykn7 668bfAM4hKSN3+6uzKrEIxJ40Gh0P92NGTBL47JIs+t1c9t884ku27J8yyLfELzm/xJi2x4lJHAC alGbulTeCexviPWpBFKvtm54Rcg3VVneq4CbrRD55xDo817p7d5iJM35df3XMHSd767On//w9s2L H1++uLh8/vbq9euz1z8/vzj7/fy3V39//vvVb5dn+OR7smtaYnuWtTrKCtGQ29vb9d3d3dq11rbj Ebi14/U7Yt2meMWw/Juq5EnMa6Wts6aetzraiSTjjLxqtqJCLN42ZS1yETfkGGxnw2tx+fdnqyNY qaatGeFxk70Xq9v8o0huW2tqrUHsudCpJvTQ7EGJi7IQirBFSWJeVZmoVnk5CWy5EQr825s35z+8 ePnrKO9cTt8J3UFQGqwPBbXkRVbXWaqgezain785e335Rv7fOAANQRFNWxQiJ0sreXLyvXaL0gO9 YRNQy3r4z1oU8Etb+tdr6cr26bpqc1F/wjEe4H/fod6c/23L+8r/n+N6+oHX6il50zZ1lghyVjSi SnksVh8Munp68mEXiPUiz8sbUrbAznlOLl+ePydXP54TXiTk7OXv56SpeJpm8XN5550Qe4KULUhZ kKyB/nVJmi1v4I9va4Qob0RCNjx+BzS5/nAB97yupXT/bDPAhFExFJN9VTYwcLwnaVXuQLY7An/j P5OI9/dtkz/fN4t393b+eOuSFSQWVcPhX1iaYTFwyFpU70VVd8rPIdCTjdhmsEYQbKF7mlXiBlf0 mOewRIUQCbYV5EmVVE9IAo9lelDjEKeiiU+zfcGbjuSefYwJXFz8osr709/WMYjyHlyg7LQLAz+4 qPuyasj3EESpgyB60D11aNfgr4RS1TbhAgHOzi9EDLfviLiNt7y4FveOOzcI41iQEx1YyiMxx2TA DDfIfdmr7ljU+w4tLvNns9G6UbCFHEVPQHCMpXnMbfsekG7eMxCJfDhtzKw6BDuia9sP1zbMk7r6 vKn7Ubzjh7yEUZGS8vJaMlclduAlWXE9Gl1c7vDPrECjAssfXAK6n/QA6FM3WbMFJPL24hJF3fF3 AsiM8P1eQMTjMMlUdkeHy5C1wbqyuvgWva5uBA6pICJ3DoiSP89xla+KSnCwwU0uyHGSNU35TOlz KDqOV+YJSXm9zSBRTsgNv/twvW364Zq2Kk4qyNZh/VB/j+RWvT+S4AmvTxJRN8doyydtUT27D3KB cnvIxU64VB8eI8Gfiv+HcfdDBTiMb1An/tmwOnX9t6Pq1PWhoNpZykHnzko+1nqAIX655VDZ9N9b jeWej1mM5Z6PW4t534/lsL+V5V5mkP8rXVZA2nXXbJGupYaQq/NB4myQmBwPiXGXj0Ew2rfwjMQQ GBqev0OtZk0t8vQjZFsHS5mX3XIcOtzwBK4vXVT9H7qU5PiTjfHQ/i88ntf/rvN1//ezXFDOiIa0 e+ntr0VzU1bvyIskqQT4F6TqRZ3zBjI1cvz6xeUzkgoOORIWguRyqeZKSpn9n6RldcOrBLhkvV4j 9h3wQ1sLLV9FpsBCW26cQvf8jlTg0oLsgXFEUxNAAefflC2Epkr8s4WErMZOQ+WYdQnQDjLQrBA1 VOWjYDu+VwQjosAUVTJGBwezeU42dzJF3e9ligrdihLSR2iDjQGpx+edOqD7cbYWcjpjKXC7vn2m NABF4dOz8+EeoJSpPuuOHNcrGLjLB4ciwsKi4uR7Yg1FFLaAKHmK8Q4qRY/5UFNZ93d8CLYqb/vq M232+N8pjPClrfDr9aWuAvwMMp+Tqvh03wDez//UDvz5938UCvSv/P85rrfAdpL9JD+uVjIzBaNg qx+BbbOiI//++hlSZKjXiXL9hF844Ye3Iq27W1dA8xhKspS8ut0D660SkfI2b9R+6r5Lf+vq54u4 /whEJTMDNBsi2Wwl2QyZbLryrHj3lKqo5Orl9NnSPkAev5q+QRuvhVtXvyxgyHEhxVxNgp9Sqsih AGhy2HbQzwWtvJvLwuQtllhsEzORMBs+dnL89rdBH44qkGR3RI40KGeEsi3mcRalzPOZy3Wofkog jqtC+b4K5Y5QvsVCFgnmUMZjYoDy7AmK+E6oQnmTVMxhNGRBxBJBjFCWCmXbKlQwQnkWc1kQoHSR bYS6Z4K2PUlFmRuwIGVpYpIq8haXzhkwuMWoi+u2YRtuEsf1lZlRGmhQrqLvCKQJGaXMSRehSBQo +raBKlUo2is8ZCAUgMXMsVjqGqRyvUiFCiMNKhik2kjzTAOWsjBahiKhpUJZrqZvz9Kh+IZFEdi7 QVdStaNUgSZVMELFIJLUfOyzJDFBhYra/YhqUKMVdCtIORMp88NHSEUiz9GgogFKgE3B8kGyFjF3 Y1jBSDWGyNcmGI4TdNAyucOCmHGjXTnKBG2bamoPqQYVJah+IUxQrup8dqSZaDhaOzhfwpkXSBM1 sIsXqrpyQ01X4WjtVOrKC0HnzPaWdeXoxuBpPhh6ilQu44IFIBQxTZDSCQpvaFD+ANXRJ2dhwvyN Ue2KtZOA6lCj4yC70IC5HusZZ4ldgkA1Bp0+w1BXe+gyB0KEY1C7pbuzZgzRqKvOB4WNjuMHy2qP fI+o7qyRTDTTFYSajc9skzt7qtqjmVSjribHCZjssTRBNWrhnxpUr6ue+sKAbehhLJ0CoLqCrq/Z VRRpUDGYVsQklSwzgxaWdUK2LWsOFXTMtwQVWPeo3baCXlcAxFNGHfwQLJPMLJYGkR4AraiHAuqL I+aBUcEKmiaokYzlu3ospQdQHttEJqmUCZLI1ifYB0IFKmGeMe9wVbsKqaNDeT0UhAk3lTGeM9ck la2GVEvPO2x6OEHIPdwZVOfgtu44tkt1KF+XymNpCp8NUlE1sYrCWfoxQMkUxpXsbkxhXDXi4F6C DhX2UJJF0WsES1KT2i1F7ZCE6sbgDHbVmagTodo3yyQDPqg6jhXoJuo5wwQlyVBIZn0WLYcJMAZV V26or2AwrCCQzAZijc38hDlGKM2unEiHchagPKO1q9zu+LqJBu4BFER6E/VFWtYX6CsYDhOEvNgH fbMgYamBr6hlaSFVLyPscLArzP1jyGhRPHdu7Utx0LbCmVQDX/UTpAwqHEMCCRNU1R7o+ZUdDnbl QsLgsrAzedMKhirJhDNdRTO1A4vCvwapAkcLXroxUGuA6tTOmS2YbXKcQHUc4kSODhVqUAHG+cBI fZHmg6GWqlFbd5yIiZCFphJgqkvJIV9ROqwgkkwsMMOyjSQzy0Vn1QQdJtjVOBDoXXNI9dQaB4xB IxnqDBPs8vbIZYnPZBW6aFdqsh24lg6lraADybbNjKlaqBGyZyl8Za+HnYieRUOZt3uGBBKcUIs4 XqhCzUt5CPQuVEzCoPZxl0RKFQQq1FTKDxMELzSmH56rc7sGNZXykYVZLZRLEFU9Q7nkhlr97Vgq lL8olW+SSksgA7WasJVdARXKZO2eq2XIgQYVTmoHawcu3qQsMVUThEZaPehruopmKxiFqC7fVC4F Wj1oRSqUPdaDvVSxDZHVIBXoSi14IZ3UoKZtD8WuElM14SvBC/IpW4MaS0vV2k2lpacmRWj8GtRY Wk5SeZBoLUP5dJighjHWlJOSbG5Ukp5lU1eDGuskufkFCV8UscToMaqZk0A3KHuqk/ocLWK+Z5Qq 0jJHS5Nq2kGBzDGBWsIH0nNNUGGgpXuRpqtglEouncC0KgmNUvlahA802wyCOVTY7xMuUoIeaiyq QY07KA5mVDbUuhFzjAblavTpalKFisc4mDcKAd5nkApiukZUrubH4egxXT5ry33HwJTPamUEUKDu MWpixeKApR6j5glqduXpfjyG5W4nNGIpOI5J7b6lJqF+pFs7VXL/hGP4iwSLl7cegai06s2dUUI0 QUmpBEs3Jqk8V8vRXN2dPXtcQcg7PBb6rCecRSitjKC6rjwtNXZCJBfPtCvgOdpmjDtjhqGmhMyR RigU1IKm/UIv1HYFqK4rz1+Qihql0gpBZwY15mhgoi6WEZuYOQb69KhG6iHVoQZjkPuFkBk7kCKb 1O5GmjHozGD71lxXPk7StIJqAAwDX4cajKHLHCHpC4AjTHWS7jgztfu6MQA1OCwxVSS+rUJFszDh D0lo5zgUSmaonU2bMa62Dx1qJtrlgqPj2CGLNsw3ZkOWChVFVIcapOp1BbV8tzH34HckJKQzKG+C kumLl7KNka+0FMaPHB2qsyva15ShAGqwjbtNWnS2Q1eHGgvB3nEijwlDlk1t7aupUDdRqrMolDa4 H2rcaNeMwdVZlFJtB4VzVFeXSCzqSiOZINShNBaF6jsCucgyFNEdJwh0qcY6qaspN2hasWmCoa1K FarcTpXvKTGkJimGL8/IDJarpcZqSKVKnYTcDhlRmoIXmqB8Xwup6n4hVeukESo0fblIqadKBYW9 CuUqUDBBcBtwHmMhqElFfFXtVKlIpOM4IBlLjRP09G8SrFBTu6VA4ReDwO1eV8svbnsYv0mgB98x AjOANQSG3N/3tB1f29egxgRS2hUyH8QLE1/5nlbcqPs6dO2Nub/UFRIDJA0mx9G306JAW0FvzNu7 VC1K5W6MSVc6IQeaifbBmXgU95os3D+BkOqZvt/QtohcS5/gmCH3X3b5zE1YaAwTKsmQQIcaM+TB BzesM/YFKEjb1eg8M1F/rN4gmOLWAnPtbhNzsdLVttNmK2hbQyYTAloik1FgUpNdaZsx1NLUrm+0 4+YJMDujpn0dVyviLJ2vPC3ZBluAOs4x5Ve+p38XpEsV6IEeCi/HgazGAKXVg9o+NEINYaJLiiCg ckizlqEInf2CIVzpp6y7Acdj2OO1+AMW/IAnmWY/jh5+/1V/sd9/2XZw8PtfajvON19///UZribe s9URheRt+NFtLYpmdXSE6W3CGz7eP4aoDjX65q7Bc5RHR9bssdU/wmNU+LvhXdY0IpENKwGgCf6Q P2sy3uA52jvy++UVSbI6LvHYAQ5oOwSwTsoiv1MHjUgicn4nkm7Qq7c/E7WJvHmTFUl5gz9u3Yil B+0+4Y3+JC6Lpirz6R71g3HYSsQiey+lhyoHxQJR8NfIoIPQ0nTQ7vMsRnBsJG/J1ti4LVCXUk3w gALQNC07itxJYd1ooJ+TGn/mXMSil3G3z0WDP4yexjlQuGyKh+oO2sgnQ3t5eK8udwLbrbvFGzDw 1qDgsm1OyvSkrBJRGQY7XPMy7QB5ikdBOq0frMxDSzLXfo8W52Xd6QPNhYNciVTvhick3grQdrur Dc+3guM0yjStRUPSTOTJvOlGdL9M70YnTVmSeltW4APSSAr8BXlZjL8/Xx3Z6m0ex2Iv20pxlAdg /bs9trf685QEAFpB0N7TvLyZIwE430DLLch0nBVx3uLP5/sBUPGqOHWnFa0lTKoq9/0SqU07VYN0 PEbwt5eX+Dv1Sa0PtH3Pq4yDST66U103W3D5rdLBImK3qe7KQh5fnXqixHv0M9sNgHmud+AwE17V NOQYTAsfDvqUipgohjTZToDJ1gdC9dDdj/xvlaYIsBdVDYvyqN6zttgdT4xxeTZdA5hud/Y+cKkR euzQrW6FxxXIi5e/Dna7r0SSdd1ARVCfDW0U6l1q2ybI6lD8WpAjYdvriu9UWrM6OgDj6SmmRxmf oDXLQXJRXMPf0nW0p4PrjTfxTTfjPX+cZgI235T4tC5RXukrw2t1Tndt3mTyBTuTmPf1nD1L2zzv n5JNm6awVNiqKBtJAVsu3WkfbzptODKYgAoqaXNwByrxaWBYyD0scCZDohNBxgVjNDxfiAuWSi8K C/W6qLN/CVLveJ7D42bLC7KD4LdTtCWVK5t9pyp6Wpr9oPrvyY7f4t/9emOnsVkvQd/0uwlWH2h8 rrXX1rPc93am2EZnbPg6BmSoot1tOhNJK967qqqR6e6wSscQVwisAx7UAz+uYQbi2XLTjutVFx11 zusa2COHRuU7uWqOTbUzQs02q8m2rKGf/qAt3hXlTXEKkbjd46EXNIb+lQPqGP1xJZRYuYlWOT55 prbv7QufyKNCS8FLGZ9MVn5dle2+o7DudNJAEjgtL9KysOEY5jg5S38slynlm0oG/QRNZPLizpbH Doc+Be5SPyeiiddLzcfwOHWQZ7OUtpPfDKs5N4MY1q6/OTWWZ0djju8ZgGRN79q9hwqD2SCI0jrF l4BACaPDjfbbH7jC06K9FvCwL0MqisEP5cExvPOHqKpSqkh+6BbzWhSikkr8Nm7/JbOpHYDxa0Fu 8E0J0G919KabN6xHU+LggH2UKKck2ullCIz4OEKPoUgZl4kY8xClwXcDQSiuOUtwluCmxpOJiXhb TsflsuuirDrtTk3QzSDd2O0X2p0Vj58kVaTCLH8PBALijdoENDxjPiyNfCfY1IxXAg0NoZJVdi0X S5mkSi0HNzsVYLKWipsuC72n3Txe7QQyWb0Fj4HpV9nBaMbHAze+h7CddAt53OUkSqdKINcYMeeP /xSm5BfJJtKyb7ZZvCU3+LKcvCyuDZ0l1WT7WsRS1cPZysHZgBpjPMcIKVwb4ycMr3dLLd9nZc57 NsWGgBy3Vdbg0UKoQRb7DEnCxQvC3/MsH5hzmPis/RJECt0mTsqA1fHdBRmSIcy2rBbH7Ttdi0ae dLo4P7unFVj4i19QX1BydiZzf+NXF+cPtobkD8+RVhjl2mYL0mbx/ahjM+lzPec+dq0Omj5msQ46 PbRa8w6LII9aL+PQXcDZp+/EHZhrNHGVjH74HohaVDkvwL8cj/aV7OGzkcow4x7IqrnbC6S2Slxj cVYx4sJfad7WW0Zs+Hj7Rw1VSJJIkuv+SlqgqOnh1HjOzIOO5rnzcqshvXqgmSr5QlutbtUROlXL d5h1BiXXBY9xHzSdthDELZSsdW99yxKNTaRM5nY1f6DBEB+UMeerLVOhaU1D31XXe/b0s654U2Ia CDl3cZ2LsVLxDxrwsVKRlf8oVvd0kAr9uRwd6rHr+Of3//b1u0/56l95PfD+B/zWY7b/a3m++3X/ 93Nc+Fa29+7pe396icFKec3ZkU0d1/M9f/WUXF28evvHT//14+sVTyBZ/c9roIn17i4p8SVf6xjf jzY1lu3Uh0cT1Jee89druioelyUuUJF+sjEeev+r5QYH73+xvvr/Z7mekr/8+uL3V4wohrDOiufv CXh/iEdF7FMrPLV9YsnfVruQATblP9oCz/aTv+D7Vp7sebN9AtVlLSt6yIVjua0OBYp84SBkJW2O NzBCJ2vo8d9lK18XhVvhN5CIir58uYP7iYA6XyTPyaZtlN5YpOMufZ9Kopgthtz1Ckcn3S64IE9O 27o6xfiYy3d/drN6Qv5j9XRsUkEYBeZCCHwg30DDKxhe7rSkkLHK2mpfiT/qLdSoyR/4qk0ZgXEr vGxrcvYjvn6zH3vWcFmE0z7Q9iP+T3vX+tu2DcQ/W38FRxvYCjiO7Tz6cP2hTZzOWNsYc9th6ApV tWVbq2V5ktLEKPK/735H6hk5j25th4GHDrH4OB15p+MdeTuqQkJKRsEyCD7yG5HWxpsp84vJ8FQ2 GbVRREt/EzlpVDaZXNvdfD9tNZEtvVkG5PV6mceoyc23LtOKOk2hXAZzKaK1O6HGZIHQ4xzu09L9 5C5bQgxj4J4FSWLcjXA9pEMXkljlzTayKeTU/XA2l0iBE+qHrmxZSIjIDz0tPVMcX0jN+UidUa0d Mt/cmM9uhG5Cb4Xk5CQiDs6Yb27kYnTcyvps1XznAnsptjbAu+1erS50YYJNW+ctqxaS0Rj42IoN ZrNejZqqdEEiq0jbRnHoTWKbfT3VPG2tqpQbSC3dC5K3iCbejslKS9texMT7WCyxDROs6JWT2I1b 1qWleEtujz4typIX0TwnfKDvoiA6qiny2HH6z9RTy+VrS9d1mnlujgmqe5Hz0V+LR4864u39drv9 rpcVkh5udfcftjoI6d0Xbw90NS/73Lz7jqeJCwhn6IDOHyOVVwjnGv4aUQU0C3U9YZqKnqBukFGP vWEaQpY7KVEg7AzqGRmrcWtzF6eMOpVI8iViJytsWfyHB4b0T6QnyLEgTQElQxhVktwpTnKE+vpp nqckMrUJvQtCdsDjSSQkDjcQEK5UKYlBUI3nlBDTBMGFzstUWhUH+rSb2uPgiH6JDiPn/FK8g65E Wrvx9OjoF4B6Hghrg3PHU5lZgvQcWGDnTawXDsS9xn87Yk8Ro5+7onOgnmn+9FidVbDa+DRbPEFJ zmDbDzh3Fil7Zz4HD4iHPZbbXH1W1URTqp8GnuAtJJt+0XPkxWeKPd4Uexbxxsb5fA/D8Te2KiTR DRNWU59iORw3e/bXdCXkFstSYnguTefdu9Vz+s5m3/kC/5e89DdK2dGPdeh9kqCX5mlCuhwffOeQ +i69mQuGMFdEB1u0YDqNvUk/m6SHQkgFghqWNgIK8GUHmCR93GD73vpQlazDYB1EaKdUxwd3A1z4 20xUB9aApeP5VtZcEMtq7moSbvh4xnaW84BWzIUv9qYuprKGM65cMa1EHRQXt5Bs0qWLYFpeq9Bw urB5G1F08XiZkxtWDg+gHL614PyP5OM7szKioc6CogpYzyLdrnNlEKk22UooUJcoyhosfGdia7qh tVgECi1IgWMzUvTy1On9n257DyFyrY6O80Zy1so6skyRY/kfjeVWQ/GnB180Enw6ODQ6vFpyE9WH N3KgKXCI0+k+ICOZrK+ZFy3E/j493Zo7zXR04nbD+95uioGvBOHk6/r+gBv8/y4i78r7f937xv// FgB7OfF6V8E5h0WSKovEn7DGOV0/OemhB9XCu+zsJ2orPNrV4kOW+mjpkvmpbhmAXa9sAT6bTP1q MnF1Tz7aCfsyn5ZBWohyWJHb15ez8+xSjZbkrK5n4QpHY8PRyfD5q8GvTSbu6fg4TayahA04c9fy 1vQ+eoOtfLO+/H0wllTqk4qrKFLXZsmd4+jTCmUrJy42IwKO+J68s1DlsE38j9TPilp8NweyUHvq QhKuWjnLiiTaSIqLm0uU4/x65V1gWwSpxtO+nHk28+I4DsJBuIhD/8RcZ2JU0S/I003ThWu3kL8X t6QgaFzjCvT9PCVk8Cpdch6JgIxauKIai50NrS8xLMYJGhFGLoXl6asDbVT05XXXwGVx691WW2Y9 CZvuePUWtkKse64PkZL0SXI3Mn90HmPePUD+3aVH8khrZS5deZaDt+Q9s1dOvSKrXhiVzViqBkd+ cRWh9J+sxNGpwNF5eDcc3So67ohjrwrHg+04dD5lYnkmPz9F9xLZGo7GgyMdtiPItj8j0z7Lba+s /cKHVCdMBcliYeJiTSsKioqBBKmYjUkae+TfAsW6VrT4iu+4Yf3fax+Uz/9wAZxZ/78F1H/Y/eCt dqOFVbeOn7+xT36zh6O+zB0ByqR89Pop15W/RV39cvAq3w+5eqV19OT5+M3weHCaIk70fKmuCvne QamRekUurbm0ng1P2okSod9Hpy9Phs/6al87wshSxSKtXDVXZTU/n45fvXzyYtB/z7OR2CHvLXrj iyfjX/qytBpZHGQn/1iNSXp4m451ndaEWN6VzcABkImmpHqlInemLm5caiJogJZjbUSJ8wBhjlNc n6GiR6NWuuypW6hUQKVlTWBqNRKqSTNb+JDIaMrvbtyzRA4ayehFA3OW6OxGgbmiUcGUa9HwYtJI JaeEAAV6CgtYMvZEbozdi52T0U0NbqifiMePxeC02EwFdKT0ESklAlGCXYadEccoMxMLGNxovaum arfxOR3m5U7jc2mgl7t6W7tXScGVt+Zp0hTgRoPrCSi/cydPU0YApqFe43niOVK3KiiL/BpSiNXc qddLxCmzwe+pqm1SVCE2JdGq7q/E54rM5OQpEZ/aVrnZVrOtIpWU2l0ZlIlI7UtZU3jnbcQyFYqr r7ylOF4vDVtpyEmDGzkTc62OAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQP/ OfgbdFN/3QCgAAA= ------=_NextPart_001_0011_01C166B1.5C2B7140-- ------=_NextPart_000_0010_01C166B1.5C2B7140 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFyDCCAogw ggHxoAMCAQICAwXIijANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMTAwMzIzMDgzMloXDTAyMTAwMzIzMDgzMlowSTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEmMCQGCSqGSIb3DQEJARYXbm9ydmVsbGVAYWcuYXJpem9uYS5lZHUw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOXc+7KAKquX5DNHA2xK1S6hRG5HQlIzxE0ia8Hi iD/9iu6A1E1qax4tllHTKnevvTqT/PxfdM1pBHPDqpgRzPGpRxhNJbbJOmmTfkP+jFqECJUQf9Lh TThr3sBztkK8H7H1S0GPvwYenFW8t3h85OcUrgyqDQGE6ONxHQ07RMefAgMBAAGjNDAyMCIGA1Ud EQQbMBmBF25vcnZlbGxlQGFnLmFyaXpvbmEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEC BQADgYEAIpU93jcqTfB1PvEZV2juvqTNXeKN14Qw7Puh9jPtUNvQZPemuv9i7BX6xKYnRtA9Gc6t 1Y11PHz1WPBbM4QlCn7cpLAcbcj/zVFKxPTJ9Gmr9rmEh8tl3sO+lLfe9AULKLZNtQC1fG9QOWoT CdCFKcuILOZmWX2p25YSkAQ531swggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAw ODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENl cnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNE KYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5 ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB /wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNi gSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWyw GmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggLIMIIC xAIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2Vz MSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFyIowCQYFKw4DAhoF AKCCAYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTA2MTc1 NDA4WjAjBgkqhkiG9w0BCQQxFgQUAfCu1uCR4GBUrHPHSAxwS5FXqj0wdgYJKoZIhvcNAQkPMWkw ZzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowBwYFKw4DAhowCgYIKoZIhvcNAgUwCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFyIowDQYJKoZI hvcNAQEBBQAEgYAd3s/qcdGRtCNUdgBAqq8sjmq/e/u85hx23C7VFOSR33oYxgdJARoxEuzEtNx0 ugzt9CRhUDGQ5oIwQigZZSLDQGnhs7ClyRXnHyqrHZ13BTYsmOzJBoN3uJA1jloDyJb05iuEu03T 8TYYdAqut+Ysl6eURLMwwEMNDwx/m6rhiQAAAAAAAA== ------=_NextPart_000_0010_01C166B1.5C2B7140-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 10: 0:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CBF5137B41B for ; Tue, 6 Nov 2001 10:00:23 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA66645; Tue, 6 Nov 2001 09:44:15 -0800 (PST) Date: Tue, 6 Nov 2001 09:44:13 -0800 (PST) From: Julian Elischer To: Pekka Nikander Cc: freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available In-Reply-To: <3BE80A2C.5020809@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'll look at it today.. do you have a pointer to EAPOL specs? On Tue, 6 Nov 2001, Pekka Nikander wrote: > Hi, > > My IEEE 802.1x EAPOL implementation is now minimally > functional and tested. It doesn't include any EAP modules, > but the EAPOL state machines seem to work fine. > > I'd appreciate if someone with more experience with netgraph > would read the code and send comments how it should > be improved so that it could be included into -CURRENT > at some later date. I'm especially worried about memory > leaks, I've tried to check the paths to make sure that > mbufs are always freed correctly, but most probably > I have missed a case or two. > > The code is available at > > http://www.tml.hut.fi/~pnr/eapol/ > > Right now I have only tested it under 4.4-STABLE, > but it shouldn't be too hard to modify it for -CURRENT. > My problem is that I haven't got any test machines > running -CURRENT available. > > Yours, > > --Pekka Nikander > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 12:50: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 6589D37B405 for ; Tue, 6 Nov 2001 12:50:01 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id VAA24042; Tue, 6 Nov 2001 21:49:53 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fA6KSdE66699; Tue, 6 Nov 2001 21:28:39 +0100 (MET) (envelope-from j) Date: Tue, 6 Nov 2001 21:28:39 +0100 From: Joerg Wunsch To: Roman Kurakin Cc: freebsd-net@FreeBSD.ORG, vak@cronyx.ru Subject: Re: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 Message-ID: <20011106212839.K43204@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011103182927.F43204@uriah.heep.sax.de> <3BE7E1E5.4040500@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3BE7E1E5.4040500@cronyx.ru>; from rik@cronyx.ru on Tue, Nov 06, 2001 at 04:13:09PM +0300 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Roman Kurakin wrote: > >Probably. At least it was me who wrote larger parts of the current > >sppp implementation. > Original version was written by Serge Vakulenko ( vak@cronyx.ru > ), Sure. I didn't want to neglect Sergej's part. When i was in need of a PPP implementation for the ISDN project, i picked Sergej's sppp because it looked promising, and i thought it was basically the way i would have gone myself. OTOH, it needed a large overhaul to implement the basic concepts of the PPP RFCs (which you have not much been in need for when using it on hardware HDLC devices). This approximately doubled the size of the source code... that's why the comment above about my part in the current implementation. > and we together keep on > development and fixing current version. Much appreciated! > (we have numerous fixes in PPP and CISCO code and we could offer new > Frame Relay code). Well, to be honest, both should IMHO be broken out into separate files. if_spppsubr.c is overly large already anyway, and both Cisco framing and FR don't have much in comming with SyncPPP except that they incidentally are all three applicable to the hardware HDLC devices Cronyx is producing. ;-) But technically, a user will almost certainly only run one of those framing technologies on his hardware (be it hardware HDLC or ISDN), and it would keep interfaces cleaner to break them out. What do you think? >> The downside of all this is that it takes a FreeBSD committer to do >> it (i expect some two dozens of committs approximately), and >> someone who's got quite a bit of time at hand. > I thought all FreeBSD developers have access to FreeBSD tree? Yes, they have -- but you aren't one, thus i can't simply ask you to do it alltogether. ;-) Unfortunately, with a day job, a small kid, and a couple of other interesting hobbies, my time is fairly limited... I wish i had all of this and much more already done, honestly. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 13: 1:13 2001 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 E171337B417 for ; Tue, 6 Nov 2001 13:01:09 -0800 (PST) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fA6L18O28430; Tue, 6 Nov 2001 13:01:08 -0800 (PST) Message-ID: <3BE84F94.1060304@isi.edu> Date: Tue, 06 Nov 2001 13:01:08 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.4) Gecko/20010924 X-Accept-Language: en, de MIME-Version: 1.0 To: Erik Norvelle Cc: freebsd-net@FreeBSD.ORG Subject: Re: 4.4-CURRENT problems getting IPSec to function References: 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 Erik Norvelle wrote: > My setup is as follows: > > Network #1 (192.168.1.0/24) > | > | > Gateway #1 (inner interface [xl0] = 192.168.1.1) > (outer interface [fxp0] = xxx.yyy.40.122) > | > | > (internet) > | > | > Gateway #2 (outer interface [fxp0] = xxx.yyy.40.135) > (inner interface [xl0] = 10.20.0.1) > | > | > Network #2 (10.20.0.0/24) > > The result of my setup is that I get the gif0 interface created and > configured properly (in tunnel mode, using ESP), and I setup my policy > database using setkey. You want to use *either* IPIP tunnels (i.e. gif interfaces) and IPsec transport mode *or* IPsec tunnel mode. Don't mix them. I'd recommend using the former. If you use IPIP + IPsec transport, you will need to set up routes so that traffic for the remote network is routed into the tunnel. If you use IPsec tunnel mode, the SAs will do the encapsulation for you. Also see http://www.isi.edu/~touch/pubs/draft-touch-ipsec-vpn-01.txt (expired, -02 is in preparation for the next IETF). > netstat -sn reveals that there is some UDP key exchange traffic going on > (at least, once I start racoon). However, there is *no* ESP traffic -- > all the counters are zero. If you use racoon, you should read the KAME IMPLEMENTATION file on how to use IKE with IPIP tunnels and IPsec. > * Installed and setup IPFILTER and IPNAT. These are working great on > their own, however there may be conflicts with IPSec that are caused by > how I have filtering/NAT setup. IPFILTER is set up to allow ISAKMP > traffic, I'd recommend doing this step by step. The first step would be to get IPsec working between your gateways. Once that works, I'd go on and set up NAT. Doing both at the same time means you have many variables in your setup. 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 Tue Nov 6 13: 3:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4D7E837B405 for ; Tue, 6 Nov 2001 13:03:23 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fA6L3II11868; Tue, 6 Nov 2001 16:03:18 -0500 (EST) (envelope-from wollman) Date: Tue, 6 Nov 2001 16:03:18 -0500 (EST) From: Garrett Wollman Message-Id: <200111062103.fA6L3II11868@khavrinen.lcs.mit.edu> To: Ian West Cc: freebsd-net@FreeBSD.ORG Subject: Re: Results from RTM_GET on route socket ? In-Reply-To: <20011106115119.L34308@rose.niw.com.au> References: <20011106075451.E34308@rose.niw.com.au> <200111052156.fA5Lutl92439@khavrinen.lcs.mit.edu> <20011106115119.L34308@rose.niw.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Thanks for that, makes sense :-) More questions though, the following is > a response to a request for 192.168.20.1. The response is a general > subnet route, how should I interpret the mask field ? (It is actually > class C) I can't find a reference to a AF_ type for -1 or 255, but the > field is a bit small for a sockaddr_in. Netmasks are literally that: bit masks which indicate which bits (after the length) in an address are significant. All of the bits in the address family are significant, so the corresponding bits in the netmask are all ones. Your code must pad the mask out with an appropriate quantity of zero bits for the type of address being masked. Generally speaking, if `cp' points to the beginning of the mask, and `sa' points to the address which was just read: struct sockaddr *mask; socklen_t len = max(sa->sa_len, *cp); mask = malloc(len); assert(mask); memset(mask, '\0', len); memcpy(mask, cp, *cp); mask->sa_len = len; mask->sa_family = sa->sa_family; ...is the most general way, although a particular address family might have more specific requirements. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 14: 2:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id DF72E37B8B4 for ; Tue, 6 Nov 2001 13:57:50 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id fA6LvWl99029; Tue, 6 Nov 2001 15:57:32 -0600 (CST) (envelope-from jlemon) Date: Tue, 6 Nov 2001 15:57:32 -0600 (CST) From: Jonathan Lemon Message-Id: <200111062157.fA6LvWl99029@prism.flugsvamp.com> To: wollman@khavrinen.lcs.mit.edu, net@freebsd.org Subject: Re: Results from RTM_GET on route socket ? X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: >< said: > >> Thanks for that, makes sense :-) More questions though, the following is >> a response to a request for 192.168.20.1. The response is a general >> subnet route, how should I interpret the mask field ? (It is actually >> class C) I can't find a reference to a AF_ type for -1 or 255, but the >> field is a bit small for a sockaddr_in. > >Netmasks are literally that: bit masks which indicate which bits >(after the length) in an address are significant. All of the bits in >the address family are significant, so the corresponding bits in the >netmask are all ones. Your code must pad the mask out with an >appropriate quantity of zero bits for the type of address being >masked. Generally speaking, if `cp' points to the beginning of the >mask, and `sa' points to the address which was just read: > > struct sockaddr *mask; > socklen_t len = max(sa->sa_len, *cp); > mask = malloc(len); > assert(mask); > memset(mask, '\0', len); > memcpy(mask, cp, *cp); > mask->sa_len = len; > mask->sa_family = sa->sa_family; > >...is the most general way, although a particular address family might >have more specific requirements. On a related tangent, are there any address families that still use discontiguous netmasks, or have these gone the way of the dodo and ethernet trailer encapsulation? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 15: 9:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from halcyon.rmci.net (halcyon.rmci.net [205.162.184.63]) by hub.freebsd.org (Postfix) with SMTP id 26BD837B405 for ; Tue, 6 Nov 2001 15:09:37 -0800 (PST) Received: (qmail 21659 invoked from network); 6 Nov 2001 23:09:35 -0000 Received: from exchange.rmci.net (216.222.31.3) by mx20.rmci.net with SMTP; 6 Nov 2001 23:09:35 -0000 Received: by exchange.rmci.net with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 16:09:35 -0700 Message-ID: From: Derek Denk To: "'freebsd-net@freebsd.org'" Subject: Bridging bug (I think) Date: Tue, 6 Nov 2001 16:09:35 -0700 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 All, I have a FreeBSD 4.2-Release machine with three network cards (fxp0,fxp1,fxp2). I have fxp1 & fxp2 bridged together and all is fine except that when I start up a tcpdump on a machine connected via a crossover cable on fxp0 I see ARP requests from the subnet on the bridge. Regards, Derek Denk Senior Systems Engineer Velocitus An IdaCorp Company http://www.velocitus.net/ Tel: 208-336-9200 Fax: 208-381-0044 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 21:25:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from gw.one.com.au (gw.one.com.au [203.18.85.1]) by hub.freebsd.org (Postfix) with ESMTP id 9D7F537B405 for ; Tue, 6 Nov 2001 21:25:52 -0800 (PST) Received: from one.com.au (pmo.local [10.18.85.2]) by gw.one.com.au (8.9.2/8.9.2) with SMTP id PAA43842 for freebsd-net@freebsd.org; Wed, 7 Nov 2001 15:25:44 +1000 (EST) (envelope-from raymond@one.com.au) Date: Wed, 7 Nov 2001 15:25:44 +1000 (EST) From: User Raymond Message-Id: <200111070525.PAA43842@gw.one.com.au> Subject: frame relay and Australian Telstra VPN Subj: frame relay and Australian Telstra VPN To: 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 We are using a WANic card and netgraph with FreeBSD 4.4-RELEASE to attempt to talk to a VPN provided by Australian Telstra. We have connected and setup netgraph with a tee between the frame relay dlci16 and the rfc1490 downstream. For some strange reason, the other end (Telstra) is sending out an ARP packet at about one second intervals. The rfc1490 node is throwing these away (rightly I would say). The packet looks like: 0000: 03 00 80 00 00 00 08 06 00 0f 08 00 02 04 00 01 0010: 00 00 0a 00 02 fd 00 00 0a 00 02 fe ^^^^^^^^^^^ ^^^^^^^^^^^ his address my address Anyone got any idea what I can send down this wire to make it work? Ray Newman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 6 22: 1:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A5BE837B418 for ; Tue, 6 Nov 2001 22:01:36 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA69267; Tue, 6 Nov 2001 21:58:30 -0800 (PST) Date: Tue, 6 Nov 2001 21:58:28 -0800 (PST) From: Julian Elischer To: User Raymond Cc: freebsd-net@freebsd.org Subject: Re: frame relay and Australian Telstra VPN In-Reply-To: <200111070525.PAA43842@gw.one.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well have you asked telstra why they are doing that? On Wed, 7 Nov 2001, User Raymond wrote: > > We are using a WANic card and netgraph with FreeBSD 4.4-RELEASE to > attempt to talk to a VPN provided by Australian Telstra. We have > connected and setup netgraph with a tee between the frame relay > dlci16 and the rfc1490 downstream. > > For some strange reason, the other end (Telstra) is sending out > an ARP packet at about one second intervals. The rfc1490 node > is throwing these away (rightly I would say). The packet looks like: > 0000: 03 00 80 00 00 00 08 06 00 0f 08 00 02 04 00 01 > 0010: 00 00 0a 00 02 fd 00 00 0a 00 02 fe > ^^^^^^^^^^^ ^^^^^^^^^^^ > his address my address They are not sending anything else? WHat are you using for Link management? I suggest the 'auto' method.. can you show the entire setup script you are using? > > Anyone got any idea what I can send down this wire to make it work? > > > Ray Newman > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 1:39:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B100137B418 for ; Wed, 7 Nov 2001 01:39:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA79ZKi91511; Wed, 7 Nov 2001 01:35:20 -0800 (PST) (envelope-from rizzo) Date: Wed, 7 Nov 2001 01:35:20 -0800 From: Luigi Rizzo To: Derek Denk Cc: "'freebsd-net@freebsd.org'" Subject: Re: Bridging bug (I think) Message-ID: <20011107013520.A91322@iguana.aciri.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 bridging in FreeBSD 4.2 had all sort of bugs, that were fixed in 4.3 cheers luigi On Tue, Nov 06, 2001 at 04:09:35PM -0700, Derek Denk wrote: > All, > > I have a FreeBSD 4.2-Release machine with three network cards > (fxp0,fxp1,fxp2). I have fxp1 & fxp2 bridged together and all is fine > except that when I start up a tcpdump on a machine connected via a crossover > cable on fxp0 I see ARP requests from the subnet on the bridge. > > Regards, > > Derek Denk > Senior Systems Engineer > Velocitus > An IdaCorp Company > http://www.velocitus.net/ > Tel: 208-336-9200 > Fax: 208-381-0044 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 2:34: 4 2001 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 E3FFD37B416 for ; Wed, 7 Nov 2001 02:34:00 -0800 (PST) Received: from dialup-209.247.138.98.dial1.sanjose1.level3.net ([209.247.138.98] helo=blossom.cjclark.org) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 161Q1m-00070e-00 for freebsd-net@freebsd.org; Wed, 07 Nov 2001 02:33:51 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA7ACfd00802 for freebsd-net@freebsd.org; Wed, 7 Nov 2001 02:12:41 -0800 (PST) (envelope-from cjc) Date: Wed, 7 Nov 2001 02:12:41 -0800 From: "Crist J. Clark" To: freebsd-net@freebsd.org Subject: Fixing ipfw(8)'s 'tee' Message-ID: <20011107021241.D307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 The 'tee' action in ipfw(8) is presently broken (see PR kern/31130). All incoming packets are accepted by the firewall machine. That is, one copy is sent to the divert socket and another copy is passed up the stack of the firewall machine. The copy is not routed to the final destination on the IP packet. The manual is slightly ambiguous, tee port Send a copy of packets matching this rule to the divert(4) socket bound to port port. The search termi- nates and the original packet is accepted (but see sec- tion BUGS below). About 'accepted,' but I don't believe this is the intended behavior. For outgoing packets, one copy is sent to the divert port and the other is routed to the destination on the packet. The following simple patch to ip_input.c appears to fix the problem, but I wanted to make sure that this really is the intended behavior. Packets that match the 'tee' rule have one copy sent to the divert port and a second copy is accepted by the firewall rules. That is, accepted as if it hit a 'pass' rule, and not accepted by the firewall host and passed up the stack. In addition, I want to state a little more clearly that 'tee' and 'divert' rules cause fragmented datagrams to be reassembled before they are further processed. I think someone using 'tee' might be fooled into believing the copies that stay in the stack have not been reassembled like the ones going to the divert socket. They have been. I'm not really sure if I understand what 'tee' is needed for. Why not just have whatever is listening on the 'tee' divert socket write packets back in? This also works around the issue that 'tee' packets are immediately accepted by the firewall. But if we want to keep 'tee,' it probably should work. Index: src/sys/netinet/ip_input.c =================================================================== RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.183 diff -u -r1.183 ip_input.c --- src/sys/netinet/ip_input.c 2001/10/25 06:27:51 1.183 +++ src/sys/netinet/ip_input.c 2001/11/07 09:51:09 @@ -794,6 +794,9 @@ return; m = clone; ip = mtod(m, struct ip *); + ip->ip_len += hlen; + divert_info = 0; + goto pass; } #endif Index: ipfw.8 =================================================================== RCS file: /export/ncvs/src/sbin/ipfw/ipfw.8,v retrieving revision 1.93 diff -u -r1.93 ipfw.8 --- ipfw.8 2001/10/14 22:46:05 1.93 +++ ipfw.8 2001/11/07 10:06:11 @@ -1359,7 +1359,11 @@ .Cm divert or .Cm tee -are reassembled before delivery to the socket. +are reassembled before delivery to the socket. The packet copied by +.Cm tee +back into the network stack has also been reassembled. Note that +reassembly of forwarded packets technically violates the Internet +Standards for routers. .Pp Packets that match a .Cm tee -- 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 Wed Nov 7 9:31:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.truenet.com.br (truenet.com.br [200.249.253.1]) by hub.freebsd.org (Postfix) with ESMTP id E914237B418 for ; Wed, 7 Nov 2001 09:31:49 -0800 (PST) Received: from spoc.dotx.com.br ([200.249.253.230]) by odin.truenet.com.br (8.11.6/8.11.3) with ESMTP id fA7IUS808578 for ; Wed, 7 Nov 2001 14:30:28 -0400 (AST) Subject: routing based on source. From: =?ISO-8859-1?Q?Jo=E3o?= Alfredo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution/0.16 (Preview Release) Date: 07 Nov 2001 15:28:00 -0200 Message-Id: <1005154083.22363.25.camel@spoc> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello people, Is it possible to do routing based on the source address in FreeBSD?? I'd like to have one default gateway for a sub-net and another default gateway for another sub-net. Thanks in advance. --=20 Jo=E3o Alfredo G. Batista ou * dotX Consultoria, Servi=E7os e Conectividade * http://www.dotx.com.br * Departamento de Desenvolvimento To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 9:37:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 35BAD37B418 for ; Wed, 7 Nov 2001 09:37:47 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA7HY4996389; Wed, 7 Nov 2001 09:34:04 -0800 (PST) (envelope-from rizzo) Date: Wed, 7 Nov 2001 09:34:04 -0800 From: Luigi Rizzo To: cjclark@alum.mit.edu Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011107093404.B96033@iguana.aciri.org> References: <20011107021241.D307@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011107021241.D307@blossom.cjclark.org> 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 Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: ... > About 'accepted,' but I don't believe this is the intended > behavior. For outgoing packets, one copy is sent to the divert port > and the other is routed to the destination on the packet. ... > I'm not really sure if I understand what 'tee' is needed for. Why > not just have whatever is listening on the 'tee' divert socket write > packets back in? This also works around the issue that 'tee' packets > are immediately accepted by the firewall. But if we want to keep > 'tee,' it probably should work. for sure we can replace tee with divert as you say, but then you would depend on the userland app to do its work (and you could have drops on the divert socket, whereas forwarding within the kernel is much faster). There is not an issue of accept vs. deny a "tee" packet, if you want to deny it you just use a "divert" rule instead. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 9:43:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id A560937B405 for ; Wed, 7 Nov 2001 09:43:51 -0800 (PST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id fA7Fppc25909 for ; Wed, 7 Nov 2001 21:23:11 +0530 (IST) Received: from pcka225.sasi.com (IDENT:madhavis@pcka225.sasi.com [10.0.82.225]) by sunk2.sasi.com (8.9.3/8.9.3) with ESMTP id VAA22850 for ; Wed, 7 Nov 2001 21:21:50 +0530 (IST) Date: Wed, 7 Nov 2001 21:21:49 +0530 (IST) From: Madhavi Suram X-Sender: madhavis@pcka225.sasi.com To: freebsd-net@FreeBSD.ORG Subject: bremfree() panic problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi This is a slightly big mail. But, the problem is so vague that I needed to explain it as clearly as possible. Please bear with this. I am doing some sort of hacking in the file if_ethersubr.c. I have added an extra file, say "file2" also in /usr/src/sys/net directory. The new code in if_ethersubr.c is controlled by a flag value. This won't get executed as long as the flag is 0. I install a module from userland and during initialization, this flag value will get changed to 1. When I compile and boot on this new kernel, I am able to install my module and all intended operations are working fine. But, when I give a find command that involves lot of file/inode accesses, the kernel panics and gives a panic message as follows: panic: bremfree() removing a buffer not in a queue This panic comes even when I do a 'find' immediately after rebooting the kernel(without my module installed). This problem wasn't there with the standard configurations. I have replaced the if_ethersubr.c with standard if_ethersubr.c and compiled the kernel with my configurations. This kernel was also giving the same panic problem. I changed the location of my "file2" from net to netinet directory (changed /usr/src/sys/conf/files accordingly) and compiled the kernel with standard if_ethersubr.c, file2 and my configurations. When I rebooted, 'find' wasn't giving any problem on this kernel. I have seen in FreeBSD bug reports that this problem was there earlier. Can someone tell me why this problem is coming. thanks & regards Madhavi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 11:20:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CAD2F37B405 for ; Wed, 7 Nov 2001 11:20:17 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA72134; Wed, 7 Nov 2001 11:00:19 -0800 (PST) Date: Wed, 7 Nov 2001 11:00:11 -0800 (PST) From: Julian Elischer To: =?ISO-8859-1?Q?Jo=E3o?= Alfredo Cc: freebsd-net@freebsd.org Subject: Re: routing based on source. In-Reply-To: <1005154083.22363.25.camel@spoc> 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 you can use the 'fwd' keyword in ipfw to force a packet to be sent out a particular interface.... (without altering it) On 7 Nov 2001, [ISO-8859-1] Jo=E3o Alfredo wrote: > Hello people, >=20 > Is it possible to do routing based on the source address in FreeBSD?? > I'd like to have one default gateway for a sub-net and another default > gateway for another sub-net. >=20 > Thanks in advance. >=20 > --=20 > Jo=E3o Alfredo G. Batista ou > * dotX Consultoria, Servi=E7os e Conectividade > * http://www.dotx.com.br > * Departamento de Desenvolvimento >=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 Wed Nov 7 13:20:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8188337B627 for ; Wed, 7 Nov 2001 13:20:23 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA72640; Wed, 7 Nov 2001 13:06:10 -0800 (PST) Date: Wed, 7 Nov 2001 13:06:09 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: cjclark@alum.mit.edu, freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' In-Reply-To: <20011107093404.B96033@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think that TEE should not accept the packet but, rather, allow processing to continue after the copy has been diverted.. starting at the next rule.. If you want to accept it, then add a rule next that does that.. On Wed, 7 Nov 2001, Luigi Rizzo wrote: > On Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: > ... > > About 'accepted,' but I don't believe this is the intended > > behavior. For outgoing packets, one copy is sent to the divert port > > and the other is routed to the destination on the packet. > ... > > I'm not really sure if I understand what 'tee' is needed for. Why > > not just have whatever is listening on the 'tee' divert socket write > > packets back in? This also works around the issue that 'tee' packets > > are immediately accepted by the firewall. But if we want to keep > > 'tee,' it probably should work. > > for sure we can replace tee with divert as you say, but then > you would depend on the userland app to do its work (and you > could have drops on the divert socket, whereas forwarding within > the kernel is much faster). > > There is not an issue of accept vs. deny a "tee" packet, if > you want to deny it you just use a "divert" rule instead. > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 15:46:36 2001 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 0017537B417 for ; Wed, 7 Nov 2001 15:46:33 -0800 (PST) Received: from dialup-209.247.136.232.dial1.sanjose1.level3.net ([209.247.136.232] helo=blossom.cjclark.org) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 161cOp-00030a-00; Wed, 07 Nov 2001 15:46:28 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA7Nk1x01189; Wed, 7 Nov 2001 15:46:01 -0800 (PST) (envelope-from cjc) Date: Wed, 7 Nov 2001 15:46:01 -0800 From: "Crist J. Clark" To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011107154601.A301@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011107021241.D307@blossom.cjclark.org> <20011107093404.B96033@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011107093404.B96033@iguana.aciri.org>; from rizzo@aciri.org on Wed, Nov 07, 2001 at 09:34:04AM -0800 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, Nov 07, 2001 at 09:34:04AM -0800, Luigi Rizzo wrote: > On Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: > ... > > About 'accepted,' but I don't believe this is the intended > > behavior. For outgoing packets, one copy is sent to the divert port > > and the other is routed to the destination on the packet. > ... > > I'm not really sure if I understand what 'tee' is needed for. Why > > not just have whatever is listening on the 'tee' divert socket write > > packets back in? This also works around the issue that 'tee' packets > > are immediately accepted by the firewall. But if we want to keep > > 'tee,' it probably should work. > > for sure we can replace tee with divert as you say, but then > you would depend on the userland app to do its work (and you > could have drops on the divert socket, whereas forwarding within > the kernel is much faster). > > There is not an issue of accept vs. deny a "tee" packet, if > you want to deny it you just use a "divert" rule instead. The issue may be that you wish to make a decision on the packet in later rules. For example, someone might wish to 'tee' all traffic to and from a certain machine to some unspecified traffic monitoring program listening on the divert socket. However, all of the traffic too and from that IP address may or may not be allowed by the security policy. With 'tee' as it exists, one cannot catch _all_ of the traffic (whether or not allowed by policy) and still apply policy. But does everyone agree the current behavior of 'tee' is broken? The firewall should not be passing packets not destined for itself up the stack; it should be forwarding them, right? -- 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 Wed Nov 7 16:20:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0D72637B417 for ; Wed, 7 Nov 2001 16:20:20 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA73218; Wed, 7 Nov 2001 16:15:09 -0800 (PST) Date: Wed, 7 Nov 2001 16:15:09 -0800 (PST) From: Julian Elischer To: cjclark@alum.mit.edu Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' In-Reply-To: <20011107154601.A301@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 7 Nov 2001, Crist J. Clark wrote: > On Wed, Nov 07, 2001 at 09:34:04AM -0800, Luigi Rizzo wrote: > > On Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: > > ... > > > About 'accepted,' but I don't believe this is the intended > > > behavior. For outgoing packets, one copy is sent to the divert port > > > and the other is routed to the destination on the packet. > > ... > > > I'm not really sure if I understand what 'tee' is needed for. Why > > > not just have whatever is listening on the 'tee' divert socket write > > > packets back in? This also works around the issue that 'tee' packets > > > are immediately accepted by the firewall. But if we want to keep > > > 'tee,' it probably should work. > > > > for sure we can replace tee with divert as you say, but then > > you would depend on the userland app to do its work (and you > > could have drops on the divert socket, whereas forwarding within > > the kernel is much faster). > > > > There is not an issue of accept vs. deny a "tee" packet, if > > you want to deny it you just use a "divert" rule instead. > > The issue may be that you wish to make a decision on the packet in > later rules. For example, someone might wish to 'tee' all traffic to > and from a certain machine to some unspecified traffic monitoring > program listening on the divert socket. However, all of the traffic > too and from that IP address may or may not be allowed by the security > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > (whether or not allowed by policy) and still apply policy. > > But does everyone agree the current behavior of 'tee' is broken? The > firewall should not be passing packets not destined for itself up the > stack; it should be forwarding them, right? Forwarding is achieved by passing it to the stack. It's the stack that decides to forward.. > -- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 7 16:49:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from raven.mail.pas.earthlink.net (raven.mail.pas.earthlink.net [207.217.120.39]) by hub.freebsd.org (Postfix) with ESMTP id 121FD37B419 for ; Wed, 7 Nov 2001 16:49:27 -0800 (PST) Received: from dialup-209.247.136.232.dial1.sanjose1.level3.net ([209.247.136.232] helo=blossom.cjclark.org) by raven.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 161dNg-0006jh-00; Wed, 07 Nov 2001 16:49:21 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA80mt801347; Wed, 7 Nov 2001 16:48:55 -0800 (PST) (envelope-from cjc) Date: Wed, 7 Nov 2001 16:48:54 -0800 From: "Crist J. Clark" To: Julian Elischer Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011107164854.D301@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011107154601.A301@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Nov 07, 2001 at 04:15:09PM -0800 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, Nov 07, 2001 at 04:15:09PM -0800, Julian Elischer wrote: > > > On Wed, 7 Nov 2001, Crist J. Clark wrote: > > > On Wed, Nov 07, 2001 at 09:34:04AM -0800, Luigi Rizzo wrote: > > > On Wed, Nov 07, 2001 at 02:12:41AM -0800, Crist J. Clark wrote: > > > ... > > > > About 'accepted,' but I don't believe this is the intended > > > > behavior. For outgoing packets, one copy is sent to the divert port > > > > and the other is routed to the destination on the packet. > > > ... > > > > I'm not really sure if I understand what 'tee' is needed for. Why > > > > not just have whatever is listening on the 'tee' divert socket write > > > > packets back in? This also works around the issue that 'tee' packets > > > > are immediately accepted by the firewall. But if we want to keep > > > > 'tee,' it probably should work. > > > > > > for sure we can replace tee with divert as you say, but then > > > you would depend on the userland app to do its work (and you > > > could have drops on the divert socket, whereas forwarding within > > > the kernel is much faster). > > > > > > There is not an issue of accept vs. deny a "tee" packet, if > > > you want to deny it you just use a "divert" rule instead. > > > > The issue may be that you wish to make a decision on the packet in > > later rules. For example, someone might wish to 'tee' all traffic to > > and from a certain machine to some unspecified traffic monitoring > > program listening on the divert socket. However, all of the traffic > > too and from that IP address may or may not be allowed by the security > > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > > (whether or not allowed by policy) and still apply policy. > > > > But does everyone agree the current behavior of 'tee' is broken? The > > firewall should not be passing packets not destined for itself up the > > stack; it should be forwarding them, right? > > Forwarding is achieved by passing it to the stack. > It's the stack that decides to forward.. Sorry about the terminology. I said 'passing _up_ the stack' meaning that the firewall machine treats all 'tee'ed packets as destined for itself and the packets get sent to ICMP or transport layer processing. The patch in the original message starts 'tee' packets over again farther back in the stack's network layer processing. Perhaps if I put it this way, the rule, tee 8668 ip from any to any in via if0 Is currently equivalent to, divert 8668 ip from any to any via if0 fwd 127.0.0.1 ip from any to any via if0 If the 'divert' rule above fed all packets back into the firewall untouched. Whereas I _think_ it is supposed to be functionally equivalent to, divert 8668 ip from any to any via if0 pass ip from any to any via if0 Where the 'divert' rule writes everything back unchanged. -- 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 Nov 8 5:33:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from free.wgops.com (dsl092-002-178.sfo1.dsl.speakeasy.net [66.92.2.178]) by hub.freebsd.org (Postfix) with ESMTP id 6E2B637B41E for ; Thu, 8 Nov 2001 05:33:41 -0800 (PST) Received: from wgops.com (dsl092-002-177.sfo1.dsl.speakeasy.net [66.92.2.177]) by free.wgops.com (8.11.3/8.11.3) with ESMTP id fA8DXdN38946 for ; Thu, 8 Nov 2001 05:33:39 -0800 (PST) (envelope-from mloftis@wgops.com) Message-ID: <3BEA89B3.B88C5048@wgops.com> Date: Thu, 08 Nov 2001 05:33:39 -0800 From: Michael Loftis X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: natd behaviour. 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 I'm running natd and I need to change it's behaviour slightly. it seems that if it doesn't find a redirect_address match it'll drop connection requests for that address, so putting it in a simplest-case divert from any to any type of ipfw rulle severly breaks things. What I need it to do is pass those through unmodified. Can I get it to do this or am I going to have to get specific with my ipfw rules? Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 8 7:17:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 9B94B37B41B for ; Thu, 8 Nov 2001 07:17:16 -0800 (PST) Received: by hanoi.cronyx.ru id SAA07460 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Thu, 8 Nov 2001 18:13:56 +0300 (MSK) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id SAA07440; (8.9.3/vak/2.1) Thu, 8 Nov 2001 18:12:36 +0300 (MSK) Message-ID: <3BEAA112.6080001@cronyx.ru> Date: Thu, 08 Nov 2001 18:13:22 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-net@FreeBSD.ORG, vak@cronyx.ru Subject: Re: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011103182927.F43204@uriah.heep.sax.de> <3BE7E1E5.4040500@cronyx.ru> <20011106212839.K43204@uriah.heep.sax.de> 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 Hi, Joerg Wunsch wrote: >As Roman Kurakin wrote: > >>>Probably. At least it was me who wrote larger parts of the current >>>sppp implementation. >>> >>Original version was written by Serge Vakulenko ( vak@cronyx.ru >> ), >> >Sure. I didn't want to neglect Sergej's part. When i was in need of >a PPP implementation for the ISDN project, i picked Sergej's sppp >because it looked promising, and i thought it was basically the way i >would have gone myself. OTOH, it needed a large overhaul to implement >the basic concepts of the PPP RFCs (which you have not much been in >need for when using it on hardware HDLC devices). This approximately >doubled the size of the source code... that's why the comment above >about my part in the current implementation. > I didn't want to neglect your's part, I just want to say that we (me and Serge) also feel responsibility for this code and we keep on development of it. >>and we together keep on >>development and fixing current version. >> >Much appreciated! > >>(we have numerous fixes in PPP and CISCO code and we could offer new >>Frame Relay code). >> >Well, to be honest, both should IMHO be broken out into separate >files. if_spppsubr.c is overly large already anyway, and both Cisco >framing and FR don't have much in comming with SyncPPP except that >they incidentally are all three applicable to the hardware HDLC >devices Cronyx is producing. ;-) But technically, a user will > Our cards and most others implemet only HDLC in hardware and need software implementation of next protocol layers such as sppp implementation. >almost certainly only run one of those framing technologies on his > >hardware (be it hardware HDLC or ISDN), and it would keep interfaces >cleaner to break them out. > >What do you think? > I don't think that they should be broken out completely. Physicaly, yes it will be better to split them into separate files (core, ppp, fr, cisco). From my point of view (Serge's as well ) logically it should be a single whole. It can be called "sppp" from the historical reasons, but I think now it is "sp" - "Synchronous Protocols". spppcontrol should became spcontrol, interact with sp-core, allow to switch between protocols and set their parameters. Best regards, Kurakin Roman >>>The downside of all this is that it takes a FreeBSD committer to do >>>it (i expect some two dozens of committs approximately), and >>>someone who's got quite a bit of time at hand. >>> >>I thought all FreeBSD developers have access to FreeBSD tree? >> >Yes, they have -- but you aren't one, thus i can't simply ask you to >do it alltogether. ;-) Unfortunately, with a day job, a small kid, and >a couple of other interesting hobbies, my time is fairly limited... >I wish i had all of this and much more already done, honestly. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 8 12:41: 4 2001 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 E517437B41A for ; Thu, 8 Nov 2001 12:41:02 -0800 (PST) Received: from dialup-209.245.128.79.dial1.sanjose1.level3.net ([209.245.128.79] helo=blossom.cjclark.org) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 161vya-0002TN-00; Thu, 08 Nov 2001 12:40:59 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA8KdLs10831; Thu, 8 Nov 2001 12:39:21 -0800 (PST) (envelope-from cjc) Date: Thu, 8 Nov 2001 12:39:17 -0800 From: "Crist J. Clark" To: Michael Loftis Cc: freebsd-net@FreeBSD.ORG Subject: Re: natd behaviour. Message-ID: <20011108123917.F51134@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3BEA89B3.B88C5048@wgops.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEA89B3.B88C5048@wgops.com>; from mloftis@wgops.com on Thu, Nov 08, 2001 at 05:33:39AM -0800 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, Nov 08, 2001 at 05:33:39AM -0800, Michael Loftis wrote: > I'm running natd and I need to change it's behaviour slightly. it seems > that if it doesn't find a redirect_address match it'll drop connection > requests for that address, so putting it in a simplest-case divert from > any to any type of ipfw rulle severly breaks things. What I need it to > do is pass those through unmodified. > > Can I get it to do this or am I going to have to get specific with my > ipfw rules? If I understand what you are saying, it should be doing this already. That is, natd(8) passes through anything it does not modify untouched. It does not drop (any normal) packets. But if you are still having problems, you will need to be more specific about your natd(8) configuration, your ipfw(8) rules, your network topology, and what exactly is not working. -- 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 Nov 8 13:39:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from free.wgops.com (dsl092-002-178.sfo1.dsl.speakeasy.net [66.92.2.178]) by hub.freebsd.org (Postfix) with ESMTP id 398DF37B416 for ; Thu, 8 Nov 2001 13:39:44 -0800 (PST) Received: from activemessage.com (dsl092-002-177.sfo1.dsl.speakeasy.net [66.92.2.177]) by free.wgops.com (8.11.3/8.11.3) with ESMTP id fA8LdgN41064; Thu, 8 Nov 2001 13:39:42 -0800 (PST) (envelope-from mike@activemessage.com) Message-ID: <3BEAFB9D.87AB5EA8@activemessage.com> Date: Thu, 08 Nov 2001 13:39:41 -0800 From: Michael Loftis X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: Michael Loftis , freebsd-net@FreeBSD.ORG Subject: Re: natd behaviour. References: <3BEA89B3.B88C5048@wgops.com> <20011108123917.F51134@blossom.cjclark.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 "Crist J. Clark" wrote: > On Thu, Nov 08, 2001 at 05:33:39AM -0800, Michael Loftis wrote: > > I'm running natd and I need to change it's behaviour slightly. it seems > > that if it doesn't find a redirect_address match it'll drop connection > > requests for that address, so putting it in a simplest-case divert from > > any to any type of ipfw rulle severly breaks things. What I need it to > > do is pass those through unmodified. > > > > Can I get it to do this or am I going to have to get specific with my > > ipfw rules? > > If I understand what you are saying, it should be doing this > already. That is, natd(8) passes through anything it does not modify > untouched. It does not drop (any normal) packets. already established sesions transit fine, but new sessions (specifically what I'm inerested in are new sessions to the local machine) to anything other than the configured redirect_* stanzas get dropped. ipfw is not the culprit, natd in verbose mode makes note of the fact that it is dropping these packets. ipfw is simply setup to redirect any packets going via the external interface into the natd divert port. natd has a default setup with the exception that the dynamic flag is set and it's pointing ot hte same interface as in ipfw. The machine running nat has to be able to accept connections on multiple addresses so the behavior that is given by target_address is *not* workable as I need to preserve the normal incoming IP. BAsically the only problem I'm having is with setup (SYN set apparently) packets sent through natd, if they don't match up witha redirect rule they get silently dropped. Don't say thats not it's behavior, because that is precisely what it is doing. my natd config is as follows... unregistered_only same_ports dynamic interface vlan5 redirect_address 192.168.0.2 64.71.178.211 the only active ipfw rule is as follows add divert natd all from any to any via vlan5 Topology is simple, external on vlan5 interface (physically fxp0) and internal on vlan0 interface (physically fxp1) -- traffic transits fine the upstream swithc fully supports vlans via 802.1Q and I have not yet identified any problems there (traffic passes to and from the host and itnerfaces just as configured). So the vlan ifaces are acting just like a normal ethernet dev. It's natd thats being funkified. > But if you are still having problems, you will need to be more > specific about your natd(8) configuration, your ipfw(8) rules, your > network topology, and what exactly is not working. > -- > 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 Nov 8 14: 5:38 2001 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 D22D037B41A for ; Thu, 8 Nov 2001 14:05:33 -0800 (PST) Received: from dialup-209.245.128.79.dial1.sanjose1.level3.net ([209.245.128.79] helo=blossom.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 161xIc-0001K2-00; Thu, 08 Nov 2001 14:05:29 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA8M3s511667; Thu, 8 Nov 2001 14:03:54 -0800 (PST) (envelope-from cjc) Date: Thu, 8 Nov 2001 14:03:54 -0800 From: "Crist J. Clark" To: Michael Loftis Cc: Michael Loftis , freebsd-net@FreeBSD.ORG Subject: Re: natd behaviour. Message-ID: <20011108140354.I51134@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3BEA89B3.B88C5048@wgops.com> <20011108123917.F51134@blossom.cjclark.org> <3BEAFB9D.87AB5EA8@activemessage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEAFB9D.87AB5EA8@activemessage.com>; from mike@activemessage.com on Thu, Nov 08, 2001 at 01:39:41PM -0800 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, Nov 08, 2001 at 01:39:41PM -0800, Michael Loftis wrote: > "Crist J. Clark" wrote: > > On Thu, Nov 08, 2001 at 05:33:39AM -0800, Michael Loftis wrote: > > > I'm running natd and I need to change it's behaviour slightly. it seems > > > that if it doesn't find a redirect_address match it'll drop connection > > > requests for that address, so putting it in a simplest-case divert from > > > any to any type of ipfw rulle severly breaks things. What I need it to > > > do is pass those through unmodified. > > > > > > Can I get it to do this or am I going to have to get specific with my > > > ipfw rules? > > > > If I understand what you are saying, it should be doing this > > already. That is, natd(8) passes through anything it does not modify > > untouched. It does not drop (any normal) packets. > > already established sesions transit fine, but new sessions (specifically what > I'm inerested in are new sessions to the local machine) to anything other than > the configured redirect_* stanzas get dropped. ipfw is not the culprit, natd > in verbose mode makes note of the fact that it is dropping these packets. Could we see this? > BAsically the only problem I'm having is with setup (SYN set apparently) > packets sent through natd, if they don't match up witha redirect rule they > get silently dropped. I thought you just said it was saying it was doing this in verbose mode? > Don't say thats not it's behavior, because that is precisely what it is doing. > > my natd config is as follows... > > unregistered_only > same_ports > dynamic > interface vlan5 > > redirect_address 192.168.0.2 64.71.178.211 > > the only active ipfw rule is as follows > add divert natd all from any to any via vlan5 > > Topology is simple, external on vlan5 interface (physically fxp0) and internal > on vlan0 interface (physically fxp1) -- traffic transits fine the upstream > swithc fully supports vlans via 802.1Q and I have not yet identified any > problems there (traffic passes to and from the host and itnerfaces just as > configured). So the vlan ifaces are acting just like a normal ethernet dev. > It's natd thats being funkified. Might be some weird vlan(4)-natd(8) interaction, but I can't say. -- 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 Nov 8 14: 9:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from free.wgops.com (dsl092-002-178.sfo1.dsl.speakeasy.net [66.92.2.178]) by hub.freebsd.org (Postfix) with ESMTP id 1193237B405 for ; Thu, 8 Nov 2001 14:09:53 -0800 (PST) Received: from activemessage.com (dsl092-002-177.sfo1.dsl.speakeasy.net [66.92.2.177]) by free.wgops.com (8.11.3/8.11.3) with ESMTP id fA8M9pN41234; Thu, 8 Nov 2001 14:09:51 -0800 (PST) (envelope-from mike@activemessage.com) Message-ID: <3BEB02AF.C4E8B114@activemessage.com> Date: Thu, 08 Nov 2001 14:09:51 -0800 From: Michael Loftis X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: Michael Loftis , freebsd-net@FreeBSD.ORG Subject: Re: natd behaviour. References: <3BEA89B3.B88C5048@wgops.com> <20011108123917.F51134@blossom.cjclark.org> <3BEAFB9D.87AB5EA8@activemessage.com> <20011108140354.I51134@blossom.cjclark.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 "Crist J. Clark" wrote: > On Thu, Nov 08, 2001 at 01:39:41PM -0800, Michael Loftis wrote: > > "Crist J. Clark" wrote: > > > On Thu, Nov 08, 2001 at 05:33:39AM -0800, Michael Loftis wrote: > > > > I'm running natd and I need to change it's behaviour slightly. it seems > > > > that if it doesn't find a redirect_address match it'll drop connection > > > > requests for that address, so putting it in a simplest-case divert from > > > > any to any type of ipfw rulle severly breaks things. What I need it to > > > > do is pass those through unmodified. > > > > > > > > Can I get it to do this or am I going to have to get specific with my > > > > ipfw rules? > > > > > > If I understand what you are saying, it should be doing this > > > already. That is, natd(8) passes through anything it does not modify > > > untouched. It does not drop (any normal) packets. > > > > already established sesions transit fine, but new sessions (specifically what > > I'm inerested in are new sessions to the local machine) to anything other than > > the configured redirect_* stanzas get dropped. ipfw is not the culprit, natd > > in verbose mode makes note of the fact that it is dropping these packets. > > Could we see this? > > > BAsically the only problem I'm having is with setup (SYN set apparently) > > packets sent through natd, if they don't match up witha redirect rule they > > get silently dropped. > > I thought you just said it was saying it was doing this in verbose > mode? Sorry, by silently I mean it never makes it back to ipfw for further processing and it just ends up in the garbage. > Might be some weird vlan(4)-natd(8) interaction, but I can't say. I'd doubt that, it all works just fine except for the case where it shouldn't touch the packet at all, it seems to ignore that and still touches the packet once in a while. > -- > 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 Nov 8 14:20:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 8110937B418 for ; Thu, 8 Nov 2001 14:20:04 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id XAA03066; Thu, 8 Nov 2001 23:20:01 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id fA8M4nt75538; Thu, 8 Nov 2001 23:04:49 +0100 (MET) (envelope-from j) Date: Thu, 8 Nov 2001 23:04:49 +0100 From: Joerg Wunsch To: Roman Kurakin Cc: freebsd-net@FreeBSD.ORG, vak@cronyx.ru Subject: Re: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 Message-ID: <20011108230449.B75044@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011103182927.F43204@uriah.heep.sax.de> <3BE7E1E5.4040500@cronyx.ru> <20011106212839.K43204@uriah.heep.sax.de> <3BEAA112.6080001@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3BEAA112.6080001@cronyx.ru>; from rik@cronyx.ru on Thu, Nov 08, 2001 at 06:13:22PM +0300 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Roman Kurakin wrote: > I didn't want to neglect your's part, I just want to say that we (me > and Serge) also feel responsibility for this code and we keep on > development of it. That's nice! > >What do you think? > I don't think that they should be broken out completely. Physicaly, > yes it will be better to split them into separate files (core, ppp, > fr, cisco). From my point of view (Serge's as well ) logically it > should be a single whole. It can be called "sppp" from the > historical reasons, but I think now it is "sp" - "Synchronous > Protocols". Hmm, well, i don't fully agree with that. For example for ISDN, it doesn't make any sense to have the FR and Cisco framing code in the kernel at all, just PPP is needed. I also don't see much benefit from sharing a single frontend, except perhaps to share the same interface name, regardless of the underlying framing protocol. > spppcontrol should became spcontrol, interact with sp-core, allow to > switch between protocols and set their parameters. Right now, spppcontrol is only needed for PPP anyway (and it's basically an extension to the ifconfig command, but i wouldn't bloat ifconfig for that very specific purpose). Do FR and Cisco really need any additional parameters that cannot be passed via a simple ifconfig? But i don't care much, either version is OK for me. Even the version with a shared fronted (i. e., interface name) could keep the actual framing implementations optional -- after all, IP, IPv6, IPX etc. are also options that would all affect that code. The remainder can easily handled by some #ifdefs. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 8 15:45:12 2001 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 7F9D737B41C for ; Thu, 8 Nov 2001 15:45:09 -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 PAA24975; Thu, 8 Nov 2001 15:38:11 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fA8NcBK41060; Thu, 8 Nov 2001 15:38:11 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111082338.fA8NcBK41060@arch20m.dellroad.org> Subject: Re: Fixing ipfw(8)'s 'tee' In-Reply-To: <20011107154601.A301@blossom.cjclark.org> "from Crist J. Clark at Nov 7, 2001 03:46:01 pm" To: cjclark@alum.mit.edu Date: Thu, 8 Nov 2001 15:38:11 -0800 (PST) Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Crist J. Clark writes: > The issue may be that you wish to make a decision on the packet in > later rules. For example, someone might wish to 'tee' all traffic to > and from a certain machine to some unspecified traffic monitoring > program listening on the divert socket. However, all of the traffic > too and from that IP address may or may not be allowed by the security > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > (whether or not allowed by policy) and still apply policy. Yes, this is how 'tee' should work. It was really hard to do at the time for some reason that I can't recall... I think because the interface between ip_input.c and ip_fw.c doesn't handle one packet splitting into two packets like that.. but maybe things have gotten better since then. -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 Nov 8 17: 0:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 3ECB937B421 for ; Thu, 8 Nov 2001 17:00:17 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA77841; Thu, 8 Nov 2001 16:42:09 -0800 (PST) Date: Thu, 8 Nov 2001 16:42:08 -0800 (PST) From: Julian Elischer To: Archie Cobbs Cc: cjclark@alum.mit.edu, Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' In-Reply-To: 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 dang! that wasn;t supposed to be a CC to all.. On Thu, 8 Nov 2001, Julian Elischer wrote: [private note to Archie] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 8 17: 0:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id AA52937B427 for ; Thu, 8 Nov 2001 17:00:22 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA77839; Thu, 8 Nov 2001 16:40:33 -0800 (PST) Date: Thu, 8 Nov 2001 16:40:32 -0800 (PST) From: Julian Elischer To: Archie Cobbs Cc: cjclark@alum.mit.edu, Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' In-Reply-To: <200111082338.fA8NcBK41060@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Got Margaret's invitation to dinner. I'm not sure if Dalma has responded yet, but we'd be delighted.. have to let Dalma look in her diary though.. On Thu, 8 Nov 2001, Archie Cobbs wrote: > Crist J. Clark writes: > > The issue may be that you wish to make a decision on the packet in > > later rules. For example, someone might wish to 'tee' all traffic to > > and from a certain machine to some unspecified traffic monitoring > > program listening on the divert socket. However, all of the traffic > > too and from that IP address may or may not be allowed by the security > > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > > (whether or not allowed by policy) and still apply policy. > > Yes, this is how 'tee' should work. It was really hard to do at the > time for some reason that I can't recall... I think because the > interface between ip_input.c and ip_fw.c doesn't handle one packet > splitting into two packets like that.. but maybe things have > gotten better since then. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 8 23:11:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from host2.rila.bg (host2.rila.bg [194.141.1.21]) by hub.freebsd.org (Postfix) with ESMTP id B1CC037B41A; Thu, 8 Nov 2001 23:11:42 -0800 (PST) Received: from earth.rila.bg ([192.168.201.31]) by host2.rila.bg with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 09:11:40 +0200 Received: from earth.rila.bg (mitko@localhost.rila.bg [127.0.0.1]) by earth.rila.bg (8.11.6/8.11.6) with ESMTP id fA97CnU01104; Fri, 9 Nov 2001 09:12:54 +0200 (EET) (envelope-from mitko@earth.rila.bg) Message-Id: <200111090712.fA97CnU01104@earth.rila.bg> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: net@freebsd.org Cc: hackers@freebsd.org Reply-To: mitko@rila.bg From: "Dimitar Peikov" Subject: IPFW module Content-type: text/plain; charset=windows-1251 Date: Fri, 09 Nov 2001 09:12:49 +0200 X-OriginalArrivalTime: 09 Nov 2001 07:11:40.0884 (UTC) FILETIME=[C7A10140:01C168ED] 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 morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my kernel configuration file. After installing all I try to 'kldload ipfw' which complains that ipfw module is already in kernel, but kldstat reports that module is being loaded! Then I've decided to kldunload it.... Kernel panic .... reboot! It is regular to kernel crash if ipfw is loaded as module, but why when it was build into kernel? In that case it would be good kldload/kldunload to exit! Why kldload loads module in case that it is compiled in kernel? -- Dimitar Peikov Programmer Analyst Globalization Group "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 0:14:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.fc.kiev.ua (indust.fc.kiev.ua [212.26.129.65]) by hub.freebsd.org (Postfix) with ESMTP id 41B1D37B41A for ; Fri, 9 Nov 2001 00:14:31 -0800 (PST) Received: (from root@localhost) by proxy.fc.kiev.ua (8.11.6/8.11.4) id fA98EPC68906 for freebsd-net@freebsd.org.AVP; Fri, 9 Nov 2001 10:14:25 +0200 (EET) (envelope-from gnut@fc.kiev.ua) Received: from blend.fc.kiev.ua (blend [192.168.5.17]) by proxy.fc.kiev.ua (8.11.6/8.11.4) with ESMTP id fA98EOQ68898 for ; Fri, 9 Nov 2001 10:14:25 +0200 (EET) (envelope-from gnut@fc.kiev.ua) Received: from localhost (localhost.fc.kiev.ua [127.0.0.1]) by blend.fc.kiev.ua (8.9.3/8.9.3) with ESMTP id KAA50333 for ; Fri, 9 Nov 2001 10:14:25 +0200 (EET) (envelope-from gnut@fc.kiev.ua) Date: Fri, 9 Nov 2001 10:15:16 +0300 From: "Oles' Hnatkevych" X-Mailer: The Bat! (v1.53bis) Reply-To: "Oles' Hnatkevych" Organization: Finance & Credit Banking Corporation X-Priority: 3 (Normal) Message-ID: <1154549961.20011109101516@fc.kiev.ua> Disposition-Notification-To: gnut@fc.kiev.ua To: freebsd-net@freebsd.org Subject: ipsec: tunneling with compression MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello freebsd-net, Having read mans and papers and web still can not figure out HOW can I setup IPSEC tunneling WITH compression so far all I do is manual SA setup that looks like add 192.168.1.128 192.168.1.129 esp 10010 -E 3des-cbc "101010101010101010101010"; add 192.168.1.129 192.168.1.128 esp 10011 -E 3des-cbc "010101010101010101010101"; add 192.168.1.128 192.168.1.129 ipcomp 10005 -C deflate; add 192.168.1.129 192.168.1.128 ipcomp 10006 -C deflate; and SP looks like (1.128-1.129 is a gif0 tunnel) spdadd 192.168.5.22 192.168.100.17 any -P out ipsec ipcomp/transport//require esp/tunnel/192.168.1.128-192.168.1.129/require; spdadd 192.168.100.17 192.168.5.22 any -P in ipsec ipcomp/transport//require esp/tunnel/192.168.1.129-192.168.1.128/require; so the questions is: 1. Is it possible in FreeBSD to do tunneling with ESP and IPCOMP? 2. should I use ipcomp/transport//require or ipcomp/tunnel/..../require? 3. what __request__ order should be used - and does it matter at all? 4. if I use ESP, why may I want to use it with AH? With best wishes, Oles' Hnatkevych, http://gnut.kiev.ua, gnut@fc.kiev.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 1:22: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5204F37B41C; Fri, 9 Nov 2001 01:21:55 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fA99LgK77208; Fri, 9 Nov 2001 04:21:43 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Fri, 9 Nov 2001 04:21:41 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Dimitar Peikov Cc: net@FreeBSD.org, hackers@FreeBSD.org Subject: Re: IPFW module In-Reply-To: <200111090712.fA97CnU01104@earth.rila.bg> 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 Yes, there is an open pr regarding this. In -current all this is fixed, but I know ipfw and, iirc, nfs modules have these problems in 4.4. Andrew On Fri, 9 Nov 2001, Dimitar Peikov wrote: : :This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my :kernel configuration file. After installing all I try to 'kldload ipfw' which :complains that ipfw module is already in kernel, but kldstat reports that :module is being loaded! Then I've decided to kldunload it.... Kernel panic :.... reboot! : :It is regular to kernel crash if ipfw is loaded as module, but why when it was :build into kernel? In that case it would be good kldload/kldunload to exit! :Why kldload loads module in case that it is compiled in kernel? : :-- :Dimitar Peikov :Programmer Analyst :Globalization Group :"We Build e-Business" : :RILA Solutions :27 Building, Acad.G.Bonchev Str. :1113 Sofia, Bulgaria : :phone: (+359 2) 9797320 :phone: (+359 2) 9797300 :fax: (+359 2) 9733355 :http://www.rila.com : : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-net" in the body of the message : -- Andrew R. Reiter arr@watson.org arr@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 Nov 9 2: 6:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by hub.freebsd.org (Postfix) with ESMTP id 71B7B37B405 for ; Fri, 9 Nov 2001 02:06:04 -0800 (PST) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id LAA22996; Fri, 9 Nov 2001 11:06:02 +0100 (MET) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id fA9A5Vo09707; Fri, 9 Nov 2001 11:05:31 +0100 Message-Id: <200111091005.fA9A5Vo09707@KOM.tu-darmstadt.de> Subject: Re: NEW CODE: polling support for device drivers. In-Reply-To: <20011027005905.A72758@iguana.aciri.org> from Luigi Rizzo at "Oct 27, 2001 00:59:05 am" To: Luigi Rizzo Date: Fri, 9 Nov 2001 11:05:31 +0100 (CET) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks, this is fantastic! On all FreeBSD 4.x versions, the performance of end systems receiving large amounts of small packets used to be much worse than on FreeBSD 3.4. I'm not a driver expert, but as you described, the vanilla systems seem to spend too much time in the interrupt context, such that both the IP interrupt and the UDP socket queues are not served fast enough. Enabling your polling code reduces this kind of loss quite impressively and by tuning the net.xorp.poll_burst_max parameter, it seems possible to further avoid end system losses. This is quite important to me for certain experiments. Would you mind explaining the other sysctl xorp parameters? Thanks again, Martin > Maybe this can be of some interest to some of you using BSD boxes > as routers, and who are concerned with performance and robustness > to attacks. I would be grateful if some of you could have a look > at this and possibly provide feedback. > > The patches attached here (for 4.4, i386 non-SMP) implement > polling-mode operation for (a couple at the moment) network device > drivers. > > This mode of operation gives huge performance and stability benefits > under heavy load, at the price of a very modest (in many cases not > noticeable) increase in latency. > > On our test box (Pentium 750 MHz, 21143 with "dc" driver), a stock > FreeBSD 4.4 was barely able to forward a single stream of 130kpps > through a 100Mbit interfac (well ok, that is not too bad!), but > the system was very unresponsive, and livelock as soon as you start > a second stream on a second interface. > > With polling enabled, the same box could forward 180Kpps and be > completely responsive even when bombed with 4 full speed 100Mbit > stream (about 590Kpps). Your mileage might vary, depending on the > number of PCI buses, card type, etc. > > Note, this is really a minimal set of diffs, providing the basic > mechanism for polling in the kernel, and very basic patches for a > couple of device driver ("dc" and "fxp"). Next in the works is a > system that limits to a programmable value the fraction of CPU time > spent in a driver context -- right now the tuning is semi-manual. > > Instruction follow. > > cheers > luigi > > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > INSTALLATION AND USE > > + make sure you have a device supported by the "dc" or "fxp" driver > (the latter is not tested 100%, but should work) > > + (cd /sys ; patch < polling.patches ) > + add the following two lines to the kernel config: > options HZ=1000 > options XORP_ETHER_POLLING > + build and install the kernel > + at runtime use the following sysctl variables to control polling: > > sysctl net.xorp.polling=1 # 1 to enable polling, 0 to disable > sysctl net.xorp.poll_burst_min=10 # controls cpu allocation > > CPU permitting, the system will forward a minimum of ( > poll_burst_min*HZ ) packets per second per interface, and more > if there are any CPU cycles available. > > This parameter is only important if you expect to have CPU > intensive tasks running on the router box -- otherwise, you can > leave it set to a low value (5...20), and the system will use > all the spare CPU cycles for forwarding. > > If you expect the system to be loaded, check the max forwarding > speed setting the parameter to a low value when the system is > unloaded, and then set the parameter to a suitable value to > "reserve" the desired amount of CPU to forwarding. > > The additional latency introduced by polling can be as large as > 1/HZ seconds, which is why i suggest using HZ=1000 (corresponding > to 1ms additional latency in the worst case). > > Just for reference, the files touched by this diff are: > > sys/conf/options.i386 > option definition > > sys/i386/include/asnames.h > sys/net/if.h > sys/net/netisr.h > sys/sys/systm.h > constants, variable and prototypes (mostly one-line changes) > > sys/i386/i386/swtch.s > sys/i386/i386/trap.c > calls to ether_poll from the idle loop and traps > > sys/kern/kern_clock.c > main polling routines > > sys/dev/fxp/if_fxp.c > sys/pci/if_dc.c > sys/pci/if_dcreg.h > device driver changes > > Supporting polling for other devices should be reasonably simple, > following the example of the other two drivers. > --------------------------------------------------------------------- [Attachment, skipping...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 2:21:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 3FE9837B418 for ; Fri, 9 Nov 2001 02:21:32 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA9AHl011186; Fri, 9 Nov 2001 02:17:47 -0800 (PST) (envelope-from rizzo) Date: Fri, 9 Nov 2001 02:17:47 -0800 From: Luigi Rizzo To: Archie Cobbs Cc: cjclark@alum.mit.edu, freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011109021747.A11137@iguana.aciri.org> References: <20011107154601.A301@blossom.cjclark.org> <200111082338.fA8NcBK41060@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111082338.fA8NcBK41060@arch20m.dellroad.org> 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, Nov 08, 2001 at 03:38:11PM -0800, Archie Cobbs wrote: > Crist J. Clark writes: > > The issue may be that you wish to make a decision on the packet in > > later rules. For example, someone might wish to 'tee' all traffic to > > and from a certain machine to some unspecified traffic monitoring > > program listening on the divert socket. However, all of the traffic > > too and from that IP address may or may not be allowed by the security > > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > > (whether or not allowed by policy) and still apply policy. You can implement the above by replacing all terminal actions (accept or deny) with "tee" and "divert" statements, respectively. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 3:40:12 2001 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 4AA2A37B421 for ; Fri, 9 Nov 2001 03:40:07 -0800 (PST) Received: from dialup-209.245.136.224.dial1.sanjose1.level3.net ([209.245.136.224] helo=blossom.cjclark.org) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 162A0o-0005oG-00; Fri, 09 Nov 2001 03:39:59 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA9BbrC17597; Fri, 9 Nov 2001 03:37:53 -0800 (PST) (envelope-from cjc) Date: Fri, 9 Nov 2001 03:37:53 -0800 From: "Crist J. Clark" To: Luigi Rizzo Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011109033753.T51134@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011107154601.A301@blossom.cjclark.org> <200111082338.fA8NcBK41060@arch20m.dellroad.org> <20011109021747.A11137@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011109021747.A11137@iguana.aciri.org>; from rizzo@aciri.org on Fri, Nov 09, 2001 at 02:17:47AM -0800 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, Nov 09, 2001 at 02:17:47AM -0800, Luigi Rizzo wrote: > On Thu, Nov 08, 2001 at 03:38:11PM -0800, Archie Cobbs wrote: > > Crist J. Clark writes: > > > The issue may be that you wish to make a decision on the packet in > > > later rules. For example, someone might wish to 'tee' all traffic to > > > and from a certain machine to some unspecified traffic monitoring > > > program listening on the divert socket. However, all of the traffic > > > too and from that IP address may or may not be allowed by the security > > > policy. With 'tee' as it exists, one cannot catch _all_ of the traffic > > > (whether or not allowed by policy) and still apply policy. > > You can implement the above by replacing all terminal actions > (accept or deny) with "tee" and "divert" statements, respectively. Ouch. I think that you can get any behavior you want in that manner, but that could be one long and ugly rule set. Still, it'd be nice if 'tee' worked at all. I'm going to commit the patch. -- 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 Nov 9 6:35:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id A618437B405 for ; Fri, 9 Nov 2001 06:35:28 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA9EVhl12536; Fri, 9 Nov 2001 06:31:43 -0800 (PST) (envelope-from rizzo) Date: Fri, 9 Nov 2001 06:31:43 -0800 From: Luigi Rizzo To: cjclark@alum.mit.edu Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011109063143.A12504@iguana.aciri.org> References: <20011107154601.A301@blossom.cjclark.org> <200111082338.fA8NcBK41060@arch20m.dellroad.org> <20011109021747.A11137@iguana.aciri.org> <20011109033753.T51134@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011109033753.T51134@blossom.cjclark.org> 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 > > You can implement the above by replacing all terminal actions > > (accept or deny) with "tee" and "divert" statements, respectively. > > Ouch. I think that you can get any behavior you want in that manner, > but that could be one long and ugly rule set. why do you think it is "long" ? it is a one-by-one replacement. > Still, it'd be nice if 'tee' worked at all. I'm going to commit the > patch. yes, go ahead. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 7:48:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id 3585637B428 for ; Fri, 9 Nov 2001 07:48:11 -0800 (PST) Received: by hanoi.cronyx.ru id SAA06247 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Fri, 9 Nov 2001 18:44:59 +0300 (MSK) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id SAA06233; (8.9.3/vak/2.1) Fri, 9 Nov 2001 18:44:01 +0300 (MSK) Message-ID: <3BEBF9EE.4030102@cronyx.ru> Date: Fri, 09 Nov 2001 18:44:46 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-net@FreeBSD.ORG, vak@cronyx.ru Subject: Re: kern/11238, kern/14848, kern/21771, sppp patch's patch_id #1 References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011103182927.F43204@uriah.heep.sax.de> <3BE7E1E5.4040500@cronyx.ru> <20011106212839.K43204@uriah.heep.sax.de> <3BEAA112.6080001@cronyx.ru> <20011108230449.B75044@uriah.heep.sax.de> 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 Hi, Joerg Wunsch wrote: >As Roman Kurakin wrote: > >... > >>I don't think that they should be broken out completely. Physicaly, >>yes it will be better to split them into separate files (core, ppp, >>fr, cisco). From my point of view (Serge's as well ) logically it >>should be a single whole. It can be called "sppp" from the >>historical reasons, but I think now it is "sp" - "Synchronous >>Protocols". >> > >Hmm, well, i don't fully agree with that. For example for ISDN, it >doesn't make any sense to have the FR and Cisco framing code in the >kernel at all, just PPP is needed. I also don't see much benefit from > The range of application of sppp far from only ISDN. But you are right that if you need only PPP, FR or CISCO code would be just a waste of kernel memory. Probably I should think more seriously about spliting sppp into separate loadable parts that could be dynamically attached to the sp-core. What you think about this idea? >sharing a single frontend, except perhaps to share the same interface >name, regardless of the underlying framing protocol. > Those protocols have the same main idea - Point-to-Point Serial Protocols. >>spppcontrol should became spcontrol, interact with sp-core, allow to >>switch between protocols and set their parameters. >> >Right now, spppcontrol is only needed for PPP anyway (and it's >basically an extension to the ifconfig command, but i wouldn't bloat >ifconfig for that very specific purpose). Do FR and Cisco really need >any additional parameters that cannot be passed via a simple ifconfig? > Current CISCO implementation don't, but there are extension that could be emplemented later. For FR some mechanism for switching between FR and PPP is necessary. We also plan to implement support for multi-PVC links (we implement it only in Linux, cause FreeBSD didn't has support for dynamic interfaces at that time) Best regards, Kurakin Roman >But i don't care much, either version is OK for me. Even the version >with a shared fronted (i. e., interface name) could keep the actual >framing implementations optional -- after all, IP, IPv6, IPX etc. are >also options that would all affect that code. The remainder can >easily handled by some #ifdefs. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 9:32:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 9D4FA37B428; Fri, 9 Nov 2001 09:32:14 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fA9HSRu15034; Fri, 9 Nov 2001 09:28:27 -0800 (PST) (envelope-from rizzo) Date: Fri, 9 Nov 2001 09:28:26 -0800 From: Luigi Rizzo To: Dimitar Peikov Cc: net@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: IPFW module Message-ID: <20011109092826.E14886@iguana.aciri.org> References: <200111090712.fA97CnU01104@earth.rila.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111090712.fA97CnU01104@earth.rila.bg> 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, Nov 09, 2001 at 09:12:49AM +0200, Dimitar Peikov wrote: > > This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my > kernel configuration file. After installing all I try to 'kldload ipfw' which > complains that ipfw module is already in kernel, but kldstat reports that > module is being loaded! Then I've decided to kldunload it.... Kernel panic > .... reboot! i posted a patch some days ago on -stable (i think). Hope to get permission to commit it. luigi > It is regular to kernel crash if ipfw is loaded as module, but why when it was > build into kernel? In that case it would be good kldload/kldunload to exit! > Why kldload loads module in case that it is compiled in kernel? > > -- > Dimitar Peikov > Programmer Analyst > Globalization Group > "We Build e-Business" > > RILA Solutions > 27 Building, Acad.G.Bonchev Str. > 1113 Sofia, Bulgaria > > phone: (+359 2) 9797320 > phone: (+359 2) 9797300 > fax: (+359 2) 9733355 > http://www.rila.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 11:29:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from c7.campus.utcluj.ro (c7.campus.utcluj.ro [193.226.6.226]) by hub.freebsd.org (Postfix) with SMTP id 8568237B417 for ; Fri, 9 Nov 2001 11:29:00 -0800 (PST) Received: (qmail 413 invoked from network); 9 Nov 2001 10:29:01 -0000 Received: from veedee.c7.campus.utcluj.ro (HELO veedee) (172.27.0.3) by gateway.c7.campus.utcluj.ro with SMTP; 9 Nov 2001 10:29:01 -0000 From: "veedee" To: "freebsd-net@FreeBSD.ORG" Date: Fri, 09 Nov 2001 12:28:46 +0200 Reply-To: "veedee" X-Mailer: PMMail 2000 Professional (2.20.2360) For Windows 2000 (5.1.2600) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: IPFW module Message-Id: <20011109192900.8568237B417@hub.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 Tested on 4.3.... ----- [(ttyv0)#~] kldstat Id Refs Address Size Name 1 3 0xc0100000 1a7108 kernel 2 1 0xc0acf000 3000 daemon_saver.ko 3 1 0xc0ad8000 12000 linux.ko [(ttyv0)#~] kldload ipfw module_register: module ipfw already exists! linker_file_sysinit "ipfw.ko" failed to register! 17 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, unlimited logging [(ttyv0)#~] kldstat Id Refs Address Size Name 1 4 0xc0100000 1a7108 kernel 2 1 0xc0acf000 3000 daemon_saver.ko 3 1 0xc0ad8000 12000 linux.ko 4 1 0xc0bf0000 6000 ipfw.ko [(ttyv0)#~] kldunload ipfw Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc013c63b stack pointer = 0x10:0xc6a6ded8 frame pointer = 0x10:0xc6a6ded8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 procesor eflags = interrupt enabled, reseume, iopl=0 current process = 378 (kldunload) interrupt mask = none trap number = 12 panic : page fault syncing disks... 15 15 11 2 done uptime 6m6s Automatic reboot in 15 seconds - press a key on the console to abort ----- :(((((( Cheers, Radu Bogdan Rusu (aka veedee) C7 Campus Network System Administrator On Fri, 9 Nov 2001 04:21:41 -0500 (EST), Andrew R. Reiter wrote: >Yes, there is an open pr regarding this. In -current all this is fixed, >but I know ipfw and, iirc, nfs modules have these problems in 4.4. >Andrew >On Fri, 9 Nov 2001, Dimitar Peikov wrote: >: >:This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my >:kernel configuration file. After installing all I try to 'kldload ipfw' which >:complains that ipfw module is already in kernel, but kldstat reports that >:module is being loaded! Then I've decided to kldunload it.... Kernel panic >:.... reboot! >: >:It is regular to kernel crash if ipfw is loaded as module, but why when it was >:build into kernel? In that case it would be good kldload/kldunload to exit! >:Why kldload loads module in case that it is compiled in kernel? >: >:-- >:Dimitar Peikov >:Programmer Analyst >:Globalization Group >:"We Build e-Business" >: >:RILA Solutions >:27 Building, Acad.G.Bonchev Str. >:1113 Sofia, Bulgaria >: >:phone: (+359 2) 9797320 >:phone: (+359 2) 9797300 >:fax: (+359 2) 9733355 >:http://www.rila.com >: >: >: >:To Unsubscribe: send mail to majordomo@FreeBSD.org >:with "unsubscribe freebsd-net" in the body of the message >: >-- >Andrew R. Reiter >arr@watson.org >arr@FreeBSD.org >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 13:17:43 2001 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 C7C1237B41C for ; Fri, 9 Nov 2001 13:17:38 -0800 (PST) Received: from dialup-209.245.133.43.dial1.sanjose1.level3.net ([209.245.133.43] helo=blossom.cjclark.org) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 162J1r-0007mg-00; Fri, 09 Nov 2001 13:17:36 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fA9LERd18692; Fri, 9 Nov 2001 13:14:27 -0800 (PST) (envelope-from cjc) Date: Fri, 9 Nov 2001 13:14:27 -0800 From: "Crist J. Clark" To: Luigi Rizzo Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG Subject: Re: Fixing ipfw(8)'s 'tee' Message-ID: <20011109131427.X51134@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011107154601.A301@blossom.cjclark.org> <200111082338.fA8NcBK41060@arch20m.dellroad.org> <20011109021747.A11137@iguana.aciri.org> <20011109033753.T51134@blossom.cjclark.org> <20011109063143.A12504@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011109063143.A12504@iguana.aciri.org>; from rizzo@aciri.org on Fri, Nov 09, 2001 at 06:31:43AM -0800 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, Nov 09, 2001 at 06:31:43AM -0800, Luigi Rizzo wrote: > > > You can implement the above by replacing all terminal actions > > > (accept or deny) with "tee" and "divert" statements, respectively. > > > > Ouch. I think that you can get any behavior you want in that manner, > > but that could be one long and ugly rule set. > > why do you think it is "long" ? it is a one-by-one replacement. Almost, it can be more like adding one or two extra rules for every existing rule. For example, if I want to watch all traffic going to specific 'host' with one monitoring daemon and all traffic going to a certain 'subnet' on another (both of which are only subsets of the total traffic going through the gateway), 1000 tee 8668 ip from any to 1050 tee 8668 ip from to any 1100 tee 8669 ip from any to 1150 tee 8669 ip from to host # Allowed outgoing TCP 2000 pass tcp from any to any 80,8080,110, out via setup keep-state # Allowed outgoing UDP 2100 pass udp from any to any 53,123, out via keep-state # Pass everything on inner interface 3000 pass ip from any to any via # Pass incoming HTTP 4000 pass tcp from any to any 80 in via 4100 pass tcp from any 80 to any out via . . . # Default deny and log 65000 deny log ip from any to any Would work if 'tee' fell through. But in reality, the above rules do not work that way. The method you mention works, but the rules become, # Allowed outgoing TCP 2000 tee 8668 tcp from any to 80,8080,110, out via setup keep-state 2100 tee 8669 tcp from any to 80,8080,110, out via setup keep-state 2200 pass tcp from any to any 80,8080,110, out via setup keep-state # Allowed outgoing UDP 2300 tee 8668 udp from any to 53,123, out via keep-state 2400 tee 8669 udp from any to 53,123, out via keep-state 2500 pass udp from any to any 53,123, out via keep-state # Pass everything on inner interface 3100 tee 8668 ip from any to via 3100 tee 8668 ip from to any via 3200 tee 8669 ip from any to via 3200 tee 8669 ip from to any via 3300 pass ip from any to any via # Pass incoming HTTP 4000 tee 8668 tcp from any to 80 in via 4100 tee 8668 tcp from 80 to any out via 4200 tee 8669 tcp from any to 80 in via 4300 tee 8669 tcp from 80 to any out via 4400 pass tcp from any to any 80 in via 4500 pass tcp from any 80 to any out via . . . # Default deny and log 61000 divert 8668 log ip from any to 62000 divert 8668 log ip from to any 63000 divert 8669 log ip from any to 64000 divert 8669 log ip from to any 65000 deny log ip from any to any Which seems a bit unweildy. Each single 'pass' or 'deny' rule from the first example has become several rules. Then again, I may be overlooking a much easier way to write these. -- 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 Nov 9 13:42:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id CFBB237B422 for ; Fri, 9 Nov 2001 13:42:31 -0800 (PST) Received: (qmail 23853 invoked from network); 9 Nov 2001 21:41:11 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.110]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2001 21:41:11 -0000 Message-ID: <3BEC4D4C.EDFC47D0@pipeline.ch> Date: Fri, 09 Nov 2001 22:40:28 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander Cc: freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available 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 Pekka Nikander wrote: > Hi, > > My IEEE 802.1x EAPOL implementation is now minimally > functional and tested. It doesn't include any EAP modules, > but the EAPOL state machines seem to work fine. > > I'd appreciate if someone with more experience with netgraph > would read the code and send comments how it should > be improved so that it could be included into -CURRENT > at some later date. I'm especially worried about memory > leaks, I've tried to check the paths to make sure that > mbufs are always freed correctly, but most probably > I have missed a case or two. > > The code is available at > > http://www.tml.hut.fi/~pnr/eapol/ I think it would be far cleaner to implement only the 802.1x packet capturing/sending as a netgraph node, do some sanity checks and then pass it off trough a socket to a userland daemon. The userland daemon would then implement the various 802.1x authen- tication methods required/possible. It could do this for example by using already existing authentication methods available in libraries like openssl. Also by doing this in a userland daemon you would gain the possibility to handle more interfaces in an easy way with configuration files. This would also allow to specify more than one authentication key for a given interface (think travelling users with different work places and keys). These keys could be tried one after the other until you get access. It could also better interact with other userland services like login or PAM. Think with logging in, it will authenticate you to the (physical) network and the (ethernet) switch will put you into the right VLAN for example. Or it could prompt for secure-id. Probably it should even be recognized by the TrustedBSD components, talk to for that. -- Andre > Right now I have only tested it under 4.4-STABLE, > but it shouldn't be too hard to modify it for -CURRENT. > My problem is that I haven't got any test machines > running -CURRENT available. > > Yours, > > --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 13:54:40 2001 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 ECC6137B405 for ; Fri, 9 Nov 2001 13:54:37 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fA9Ls6S31365; Fri, 9 Nov 2001 13:54:06 -0800 Date: Fri, 9 Nov 2001 13:54:06 -0800 From: Brooks Davis To: Andre Oppermann Cc: Pekka Nikander , freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available Message-ID: <20011109135406.A30773@Odin.AC.HMC.Edu> References: <3BEC4D4C.EDFC47D0@pipeline.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEC4D4C.EDFC47D0@pipeline.ch>; from oppermann@pipeline.ch on Fri, Nov 09, 2001 at 10:40:28PM +0100 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 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2001 at 10:40:28PM +0100, Andre Oppermann wrote: > It could also better interact with other userland services like login > or PAM. Think with logging in, it will authenticate you to the > (physical) network and the (ethernet) switch will put you into the > right VLAN for example. Or it could prompt for secure-id. This one is pretty critical. If you can't support SecurID passwords (60sec lifetime) then there are lots of sites that won't be able to work with the system at all. We've already seen this problem with the Cisco LEAP stuff. -- 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 --d6Gm4EdcadzBjdND 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 iD8DBQE77FB9XY6L6fI4GtQRAoPOAKCqQNbdMbr1kgdQobuA0DRRYJg3VwCeM6bb oa4VJJTfSASlxs279DsCDbw= =JtyV -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 15:20:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7A8CF37B405 for ; Fri, 9 Nov 2001 15:20:25 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA82164; Fri, 9 Nov 2001 15:07:23 -0800 (PST) Date: Fri, 9 Nov 2001 15:07:21 -0800 (PST) From: Julian Elischer To: Brooks Davis Cc: Andre Oppermann , Pekka Nikander , freebsd-net , Marco Molteni Subject: Re:SecureID (was 802.1x) In-Reply-To: <20011109135406.A30773@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 9 Nov 2001, Brooks Davis wrote: > On Fri, Nov 09, 2001 at 10:40:28PM +0100, Andre Oppermann wrote: > > It could also better interact with other userland services like login > > or PAM. Think with logging in, it will authenticate you to the > > (physical) network and the (ethernet) switch will put you into the > > right VLAN for example. Or it could prompt for secure-id. > > This one is pretty critical. If you can't support SecurID passwords > (60sec lifetime) then there are lots of sites that won't be able to work > with the system at all. We've already seen this problem with the Cisco > LEAP stuff. Does anyone else have secureID fobs running in FreeBSD based systems? (if so I'd like to chat) > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 15:47:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail2.uniserve.com (mail2.uniserve.com [204.244.156.10]) by hub.freebsd.org (Postfix) with ESMTP id DCAC237B41E for ; Fri, 9 Nov 2001 15:47:53 -0800 (PST) Received: from landons.vpp-office.uniserve.ca ([216.113.198.10] helo=pirahna.uniserve.com) by mail2.uniserve.com with esmtp (Exim 3.13 #1) id 162LNC-000Cn1-00; Fri, 09 Nov 2001 15:47:47 -0800 Message-Id: <5.1.0.14.0.20011109154610.02aeee50@pop.uniserve.com> X-Sender: landons@pop.uniserve.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Nov 2001 15:47:44 -0800 To: Brooks Davis From: Landon Stewart Subject: Re:SecureID (was 802.1x) Cc: freebsd-net In-Reply-To: References: <20011109135406.A30773@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_715057808==_.ALT" 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 --=====================_715057808==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed It might be better to post your entire situation to the list so that not only one person can have an opportunity to help you out. Generally you catch more people that way I think. >Does anyone else have secureID fobs running in FreeBSD based systems? >(if so I'd like to chat) > > > > > -- Brooks --- Landon Stewart System Administrator landons@uniserve.com --=====================_715057808==_.ALT Content-Type: text/html; charset="us-ascii" It might be better to post your entire situation to the list so that not only one person can have an opportunity to help you out.  Generally you catch more people that way I think.

Does anyone else have secureID fobs running in FreeBSD based systems?
(if so I'd like to chat)

>
> -- Brooks

---
Landon Stewart
System Administrator
landons@uniserve.com
 --=====================_715057808==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 16: 0:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id A11B237B422 for ; Fri, 9 Nov 2001 16:00:19 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA82306; Fri, 9 Nov 2001 15:49:27 -0800 (PST) Date: Fri, 9 Nov 2001 15:49:26 -0800 (PST) From: Julian Elischer To: Landon Stewart Cc: Brooks Davis , freebsd-net Subject: Re:SecureID (was 802.1x) In-Reply-To: <5.1.0.14.0.20011109154610.02aeee50@pop.uniserve.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 well it went to -net :-) On Fri, 9 Nov 2001, Landon Stewart wrote: > It might be better to post your entire situation to the list so that not > only one person can have an opportunity to help you out. Generally you > catch more people that way I think. > > >Does anyone else have secureID fobs running in FreeBSD based systems? > >(if so I'd like to chat) > > > > > > > > -- Brooks > > --- > Landon Stewart > System Administrator > landons@uniserve.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 16:13:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from angui.sh (angui.sh [216.27.181.149]) by hub.freebsd.org (Postfix) with ESMTP id 8D74F37B416 for ; Fri, 9 Nov 2001 16:13:52 -0800 (PST) Received: from localhost (wfroning@localhost) by angui.sh (8.11.6/8.11.4) with ESMTP id fAA0E8x52907; Fri, 9 Nov 2001 16:14:08 -0800 (PST) (envelope-from wfroning@angui.sh) Date: Fri, 9 Nov 2001 16:14:08 -0800 (PST) From: Will Froning To: Cc: Subject: IPSec w/SonicWall IKE Message-ID: <20011109135801.X25048-100000@angui.sh> 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 OS: FreeBSD4.3 Software: Racoon-20010322 I'm attempting to connect a FBSD4.3 box to a SonicWall VPN solution. I think I have everything configured correctly, but I keep getting this error mesg and I'm unable to reach the IPs on the other end: 2001-11-09 13:56:51: INFO: isakmp.c:1618:isakmp_post_acquire(): request for establishing IPsec-SA was queued due to no phase1 found. 2001-11-09 13:56:54: DEBUG: isakmp.c:1370:isakmp_ph1resend(): resend phase1 packet 1b770e442d645209:0000000000000000 I can never seem to get the session working correctly. If I'm not giving the correct data, or not enough, please ask. Please cc me on the reply as I'm not on the list. Thanks, Will Here is my config file for racoon. /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; log debug; remote anonymous { proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 12 hour; lifetime byte 50 MB; encryption_algorithm 3des,des,cast128,blowfish ; authentication_algorithm hmac_sha1,hmac_md5 ; compression_algorithm deflate ; } wfroning# setkey -DP 192.168.1.0/24[any] XXX.XXX.XXX.158[any] any in ipsec esp/tunnel/XXX.XXX.XXX.131-XXX.XXX.XXX.158/require spid=2 seq=1 pid=561 refcnt=1 XXX.XXX.XXX.158[any] 192.168.1.0/24[any] any out ipsec esp/tunnel/XXX.XXX.XXX.158-XXX.XXX.XXX.131/require spid=1 seq=0 pid=561 refcnt=1 -- Will Froning Unix Sys. Admin. wfroning@angui.sh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 21:14: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by hub.freebsd.org (Postfix) with ESMTP id 2325437B425 for ; Fri, 9 Nov 2001 21:13:58 -0800 (PST) Received: (from redjade@localhost) by ada.snu.ac.kr (8.11.6/8.11.3) id fAA5Dug60511 for freebsd-net@freebsd.org; Sat, 10 Nov 2001 14:13:56 +0900 (KST) (envelope-from redjade) Date: Sat, 10 Nov 2001 14:13:56 +0900 From: Kyunghwan Kim To: freebsd-net@freebsd.org Subject: Intel nics (fxp, wx, gx) questions Message-ID: <20011110141356.A60420@ada.snu.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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, Some questions related to intel nic drivers: 1. fxp microcode Marko has summited fxp interrupt bundling patch before. Is there any reference to write fxp microcode? 2. wx and new gx Reading FreeBSD September status report, I was surprised new gx driver is added. I remember that there was no HEADUP and no UPDATING change about this. I've read Matthew's log about removing if_wx* in cvsweb, but reasons which his conclusion is based on is not enough for me. Would someone tell me in detail? Thanks in advance. Regards, Kyunghwan Kim redjade@ada.snu.ac.kr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 9 22:40:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by hub.freebsd.org (Postfix) with ESMTP id 7F37D37B42A for ; Fri, 9 Nov 2001 22:40:19 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 33BF974403; Sat, 10 Nov 2001 08:43:28 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 02260BA21; Sat, 10 Nov 2001 08:40:15 +0200 (EET) Message-ID: <3BECCBCF.60903@nomadiclab.com> Date: Sat, 10 Nov 2001 08:40:15 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: Andre Oppermann Cc: freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available References: <3BEC4D4C.EDFC47D0@pipeline.ch> 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 Thanks for your comments. This is exactly what I need so that we get an architecturally beautiful but still flexible enough implementation. > I think it would be far cleaner to implement only the 802.1x packet > capturing/sending as a netgraph node, do some sanity checks and then > pass it off trough a socket to a userland daemon. I more or less agree, and that's what I've more or less tried to do. Actually, in my very first version I just had the capture/sending functionality, but it become rather quickly clear that there are benefits from including the 802.1x state machines into the module as well. Furthermore, you can implement the basic packet capture and sanity checking with the ng_bpf module. On that level, there is no point of having a separate 802.1x module. Thus, I went and implemented the 802.1x state machines, too. I agree that the implementation at my web site was far from clean, and based on Julian's comments I am refactoring the code right now. I should get the refactoring ready in a few days. An interim snapshot of the code under refactoring is now at the website http://www.tml.hut.fi/~pnr/EAPOL. What are my goals with the netgraph node, then? First, the kernel space state machine functionality allows you to separate the authenticator (server) and supplicant (client) functionality. Separating them at the user level would not be that easy. If you just forwarded all packets to the userland, and then separated them, you would need some kind of user land IPC, and that would unnecessarily complicate the user land modules since we have muxing/demuxing already at the netgraph level. I consider separation quite important since the client and server are potentially very different. The client could be a KDE or Gnome program, asking the user for password or other info, while the server is typically a daemon. Still further, I want to make it easy to support different kinds of authenticator daemons as well, e.g. one could do authentication locally, other pass all packets to an back end RADIUS server. My second goal is to work towards a solution where one could share one set of userland clients and servers with PPP/EAP. I'm far from that (I haven't looked at the ng_ppp code at all yet), but at least I'm paying attention to the architectural issues involved. Being compatible with PPP requires, then, that the userland doesn't need to care about EAPOL pecularities such as packet retransmissions, timers etc. That's why I've implemented at the netgraph node. My third goal is to make it possible to optionally implement the EAP modules at the kernel space. This might be useful sometimes, e.g., to have a "standard" MD5-Challenge module in the kernel to that it can be easily used in single user mode. > The userland daemon would then implement the various 802.1x authen- > tication methods required/possible. It could do this for example by > using already existing authentication methods available in libraries > like openssl. Right. That's the goal. Furthermore, I'd like to see the possibility of having several parallel userland daemons, each basically implementing just one authentication method. That would make the userland part much easier. And that would give flexibility. For example, you could have MD5-Challenge authenticator using local user accounts and at the same time allow TLS authentication through RADIUS. The architecture is not quite there yet -- I will need some more intelligence somewhere. Right now there are just separate hooks for separate EAP protocols. On the client side, the ng_eapol node responds to the Request/Identity, but after that the subsequent Request/Authentication packets are sent to separate EAP hooks. On the authenticator side, the Response/Identity packet is broadcast to all connected EAP hooks, but after that all Response/Authentication packets are directed only to the relevant hook. Both clien and authenticator need more options, and I am considering them. > Also by doing this in a userland daemon you would gain the possibility > to handle more interfaces in an easy way with configuration files. That's one of the tricky parts with the current architecture. I have to somehow tag the packets going to the userland with both the interface and MAC address. The code is planned to do that, but I still don't know what's the cleanest way of passing this info to the userland. meta doesn't seem to be a possibility since it cannot be passed to the userland side; I'm reluctant of putting this info on the mbuf proper since it would result in quite ugly code. Suggestions? > This would also allow to specify more than one authentication key > for a given interface (think travelling users with different work > places and keys). These keys could be tried one after the other until > you get access. That's completely up to the userland part. > It could also better interact with other userland services like login > or PAM. Think with logging in, it will authenticate you to the > (physical) network and the (ethernet) switch will put you into the > right VLAN for example. Or it could prompt for secure-id. Ditto. > Probably it should even be recognized by the TrustedBSD components, > talk to for that. I didn't get this one. What are TrustedBSD components, and why I should talk about that? --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 10 12:52: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id EE15037B41A for ; Sat, 10 Nov 2001 12:51:59 -0800 (PST) Received: from tel.fer.hr (zg05-164.dialin.iskon.hr [213.191.138.165]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id fAAKpcu17578; Sat, 10 Nov 2001 21:51:39 +0100 (MET) Message-ID: <3BED9357.D4C48191@tel.fer.hr> Date: Sat, 10 Nov 2001 21:51:35 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kyunghwan Kim Cc: freebsd-net@freebsd.org Subject: Re: Intel nics (fxp, wx, gx) questions References: <20011110141356.A60420@ada.snu.ac.kr> 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 Kyunghwan Kim wrote: > Some questions related to intel nic drivers: > > 1. fxp microcode > Marko has summited fxp interrupt bundling patch before. > Is there any reference to write fxp microcode? No that I am aware of, as I just used the microcode supplied with Intel's Linux driver in binary form. After conducting a few TCP throughput tests with interrupt coalescing microcode, I found that depending of the specific environment, quite serious TCP perfomance degradation can follow as a result of additional delay introduced by this method. In my strong opinion, the proper way to go in reducing the interrupt overhead was directed by Luigi Rizzo's polling patch, as it does not suffer from TCP perf. degradation problems, yet still completely removes the interrupt overhead, and introduces some adittional goodies. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 10 18: 5:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by hub.freebsd.org (Postfix) with ESMTP id DC4F637B41A for ; Sat, 10 Nov 2001 18:05:38 -0800 (PST) Received: from smtp-relay01.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id fAB1wZsD023450 for ; Sat, 10 Nov 2001 17:58:35 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GMM5TE00.GFL for ; Sat, 10 Nov 2001 18:05:38 -0800 Received: from cannondale.0.168.192.in-addr.arpa ([144.137.193.240]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GMM5TA00.5BP for ; Sat, 10 Nov 2001 18:05:34 -0800 Date: Sun, 11 Nov 2001 12:35:19 +1030 Mime-Version: 1.0 (Apple Message framework v472) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Limiting bandwidth abuse to/from internet From: Wincent Colaiuta To: freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <8E809F08-D648-11D5-B151-003065C60B4C@mac.com> X-Mailer: Apple Mail (2.472) 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 We have a local-subnet here 192.168.0.0/24 sharing a small PPPoE connection (512KBit/s) to the net. I'm trying to use dummynet to prevent one user in particular from saturating the connection and destroying the net connection for all others. I've successfully used a set of ipfw/dummynet rules such as these on the gateway machine that is connected to the internet: pipe 1 ip from any to 192.168.0.2 pipe 2 ip from 192.168.0.2 to any pipe 1 config bw 10KBytes/s pipe 2 config bw 5KBytes/s The problem with these rules is that they cap that user's abuse of the net connection, but they ALSO slow down the speed with which that user can access files shared locally to the LAN from the gateway machine. I want to restrict it so that only connections to/from the internet are limited, but I don't want connections merely with the LAN to be slow. So the following lines don't work (trying to limit only PPP traffic (which goes via the tun0 interface on the gateway)... pipe 1 ip from any to 192.168.0.2 via tun0 pipe 2 ip from 192.168.0.2 to any via tun0 Any tips? I suspect I should be using masks but I am not really sure how... Thanks for any advice that you can give. Cheers Wincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 11 0: 0:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id BD88C37B41B for ; Sun, 11 Nov 2001 00:00:35 -0800 (PST) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA87927; Sat, 10 Nov 2001 23:44:12 -0800 (PST) Date: Sat, 10 Nov 2001 23:44:10 -0800 (PST) From: Julian Elischer To: Pekka Nikander Cc: Andre Oppermann , freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available In-Reply-To: <3BECCBCF.60903@nomadiclab.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 Sat, 10 Nov 2001, Pekka Nikander wrote: > > > That's one of the tricky parts with the current architecture. > I have to somehow tag the packets going to the userland with > both the interface and MAC address. The code is planned to > do that, but I still don't know what's the cleanest way of > passing this info to the userland. meta doesn't seem to be > a possibility since it cannot be passed to the userland side; > I'm reluctant of putting this info on the mbuf proper since > it would result in quite ugly code. Suggestions? > metadata can theoretically be sent to the userland side of things using the 'recvmsg()' system call if we defined the correct way of passing the control information back and forth. I have not done this yet because I didn't have a good example of how it should be useful but this example you show is such a case. > > > > Probably it should even be recognized by the TrustedBSD components, > > talk to for that. > > > I didn't get this one. What are TrustedBSD components, and why > I should talk about that? > > --Pekka Nikander > > > 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