From owner-freebsd-net Sun Nov 11 13:23:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from procyon.mine.nu (h119n2fls33o883.telia.com [217.208.62.119]) by hub.freebsd.org (Postfix) with ESMTP id 13F7937B418 for ; Sun, 11 Nov 2001 13:23:44 -0800 (PST) Received: (from eip@localhost) by procyon.mine.nu (8.11.3/8.11.3) id fABLPR600960 for freebsd-net@freebsd.org; Sun, 11 Nov 2001 22:25:27 +0100 (CET) (envelope-from eip) Date: Sun, 11 Nov 2001 22:25:26 +0100 From: Jerry Eriksson To: freebsd-net@freebsd.org Subject: ftp(1) patch Message-ID: <20011111222526.A895@coredump.cx> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.3.22.1i 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 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's a quick patch for ftp(1) to show the transfer rate while downloading files. / Jerry --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ftp.diff" --- /usr/src/usr.bin/ftp/util.c Fri Apr 6 13:34:03 2001 +++ ftp/util.c Fri Nov 9 18:07:49 2001 @@ -602,9 +602,9 @@ progressmeter(flag) static struct timeval lastupdate; static off_t lastsize; struct timeval now, td, wait; - off_t cursize, abbrevsize; + off_t cursize, abbrevsize, bs; double elapsed; - int ratio, barlength, i, len; + int ratio, barlength, i, len, meg; off_t remaining; char buf[256]; @@ -625,7 +625,7 @@ progressmeter(flag) ratio = MIN(ratio, 100); len += snprintf(buf + len, sizeof(buf) - len, "\r%3d%% ", ratio); - barlength = ttywidth - 30; + barlength = ttywidth - 43; if (barlength > 0) { i = barlength * ratio / 100; len += snprintf(buf + len, sizeof(buf) - len, @@ -668,6 +668,12 @@ progressmeter(flag) } else { remaining = ((filesize - restart_point) / (bytes / elapsed) - elapsed); + bs = bytes / (elapsed == 0.0 ? 1 : elapsed); + meg = 0; + if (bs > (1024 * 1024)) + meg = 1; + len += snprintf(buf + len, sizeof(buf) - len, + " (%.2f %sB/s)", bs / (1024.0 * (meg ? 1024.0 : 1.0)), meg ? "M" : "K"); if (remaining >= 100 * SECSPERHOUR) len += snprintf(buf + len, sizeof(buf) - len, " --:-- ETA"); --PNTmBPCT7hxwcZjr-- 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 16:43:56 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 C438437B41B for ; Sun, 11 Nov 2001 16:43:49 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 8EE3C81D05; Sun, 11 Nov 2001 18:43:44 -0600 (CST) Date: Sun, 11 Nov 2001 18:43:44 -0600 From: Bill Fumerola To: Wincent Colaiuta Cc: freebsd-net@freebsd.org Subject: Re: Limiting bandwidth abuse to/from internet Message-ID: <20011111184344.A51024@elvis.mu.org> Reply-To: Bill Fumerola References: <8E809F08-D648-11D5-B151-003065C60B4C@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8E809F08-D648-11D5-B151-003065C60B4C@mac.com>; from wincentcolaiuta@mac.com on Sun, Nov 11, 2001 at 12:35:19PM +1030 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 11, 2001 at 12:35:19PM +1030, Wincent Colaiuta wrote: > 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. just make your ipfw pipe rules say what you really want: pipe 1 ip from not 192.168.0.0/24 to 192.168.0.2 pipe 2 ip from 192.168.0.2 to not 192.168.0.0/24 these types of posts are more appropriate for . -- - 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 Sun Nov 11 17: 8:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail3.home.nl (mail3.home.nl [213.51.129.227]) by hub.freebsd.org (Postfix) with ESMTP id 9AA7337B416 for ; Sun, 11 Nov 2001 17:08:16 -0800 (PST) Received: from testuser ([213.51.195.75]) by mail3.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011112010744.KQKQ10132.mail3.home.nl@testuser> for ; Mon, 12 Nov 2001 02:07:44 +0100 Message-ID: <01eb01c16b16$84610d50$0200a8c0@testuser> From: "Marcel Dijk" To: Subject: strange kernel message Date: Mon, 12 Nov 2001 02:08:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E8_01C16B1E.E5296210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Marcel Dijk" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_01E8_01C16B1E.E5296210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Since I installed Freebsd I get this kernel message (and I get it A = LOT): arp: 192.168.0.1 is on lo0 but got reply from 00:50:da:29:56:ce on ed0 But my LAN is working fine. Marcel ------=_NextPart_000_01E8_01C16B1E.E5296210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Since I installed Freebsd I get this = kernel message=20 (and I get it A LOT):
 
arp: 192.168.0.1 is on lo0 but got reply from 00:50:da:29:56:ce on=20 ed0
 
But my LAN is working = fine.
 
Marcel
------=_NextPart_000_01E8_01C16B1E.E5296210-- 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 19:11:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.noos.fr (aragon.noos.net [212.198.2.75]) by hub.freebsd.org (Postfix) with ESMTP id 58E2537B417 for ; Sun, 11 Nov 2001 19:11:53 -0800 (PST) Received: (qmail 52598295 invoked by uid 0); 12 Nov 2001 03:10:03 -0000 Received: from unknown (HELO gits.dyndns.org) ([212.198.229.145]) (envelope-sender ) by 212.198.2.75 (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Nov 2001 03:10:03 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.6/8.11.6) id fAC3A2729661; Mon, 12 Nov 2001 04:10:02 +0100 (CET) (envelope-from root) Message-Id: <200111120310.fAC3A2729661@gits.dyndns.org> Subject: Re: ftp(1) patch In-Reply-To: <20011111222526.A895@coredump.cx> To: Jerry Eriksson Date: Mon, 12 Nov 2001 04:10:01 +0100 (CET) Cc: freebsd-net@freebsd.org Reply-To: clefevre@citeweb.net From: Cyrille Lefevre Organization: ACME X-Face: X-Mailer: ELM [version 2.4ME+ PL95a (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 Jerry Eriksson wrote: > Here's a quick patch for ftp(1) to show > the transfer rate while downloading files. @@ -668,6 +668,12 @@ progressmeter(flag) } else { remaining = ((filesize - restart_point) / (bytes / elapsed) - elapsed); + bs = bytes / (elapsed == 0.0 ? 1 : elapsed); + meg = 0; + if (bs > (1024 * 1024)) ^^^^^^^^^^^ (1<<10) well, this one would be converted to a constant by the compiler. + meg = 1; + len += snprintf(buf + len, sizeof(buf) - len, + " (%.2f %sB/s)", bs / (1024.0 * (meg ? 1024.0 : 1.0)), meg ? "M" : "K"); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1 << (meg ? 10 : 0) but not this one. if (remaining >= 100 * SECSPERHOUR) len += snprintf(buf + len, sizeof(buf) - len, " --:-- ETA"); Cyrille. -- Cyrille Lefevre mailto:clefevre@citeweb.net 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 20:44: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from cessium.prosolve.com (gw.prosolve.com [63.225.188.140]) by hub.freebsd.org (Postfix) with ESMTP id ECAC637B405 for ; Sun, 11 Nov 2001 20:43:57 -0800 (PST) Received: from fs01.prosolve.com (fs01.prosolve.com [172.16.128.50]) by cessium.prosolve.com (8.11.4/8.11.4) with ESMTP id fAC1crf42878; Sun, 11 Nov 2001 17:38:53 -0800 (PST) Received: by fs01.prosolve.com with Internet Mail Service (5.5.2655.55) id ; Sun, 11 Nov 2001 17:38:52 -0800 Message-ID: From: Sean Mathias To: "'Marcel Dijk'" , net@FreeBSD.ORG Subject: RE: strange kernel message Date: Sun, 11 Nov 2001 17:38:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16B1A.C7ECC830" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16B1A.C7ECC830 Content-Type: text/plain; charset="iso-8859-1" Every time I have seen this, it has been on a multihomed system and if I loko hard enough, I find someone, somewhere has a system multihomed without permission or the network operations staff knowing ot it. Though you are seeing the loopback address, maybe someone else happens to be using that address on another system on the network, maybe a rogue DHCP server? SM -----Original Message----- From: Marcel Dijk [mailto:nascar24@home.nl] Sent: Sunday, November 11, 2001 5:08 PM To: net@FreeBSD.ORG Subject: strange kernel message Hello, Since I installed Freebsd I get this kernel message (and I get it A LOT): arp: 192.168.0.1 is on lo0 but got reply from 00:50:da:29:56:ce on ed0 But my LAN is working fine. Marcel ------_=_NextPart_001_01C16B1A.C7ECC830 Content-Type: text/html; charset="iso-8859-1"
Every time I have seen this, it has been on a multihomed system and if I loko hard enough, I find someone, somewhere has a system multihomed without permission or the network operations staff knowing ot it.  Though you are seeing the loopback address, maybe someone else happens to be using that address on another system on the network, maybe a rogue DHCP server?
 
SM

 -----Original Message-----
From: Marcel Dijk [mailto:nascar24@home.nl]
Sent: Sunday, November 11, 2001 5:08 PM
To: net@FreeBSD.ORG
Subject: strange kernel message

Hello,
 
Since I installed Freebsd I get this kernel message (and I get it A LOT):
 
arp: 192.168.0.1 is on lo0 but got reply from 00:50:da:29:56:ce on ed0
 
But my LAN is working fine.
 
Marcel
------_=_NextPart_001_01C16B1A.C7ECC830-- 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 23:49:55 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 DB0F437B405 for ; Sun, 11 Nov 2001 23:49:49 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAC7jtn39053; Sun, 11 Nov 2001 23:45:55 -0800 (PST) (envelope-from rizzo) Date: Sun, 11 Nov 2001 23:45:55 -0800 From: Luigi Rizzo To: Martin Karsten Cc: net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011111234555.B38855@iguana.aciri.org> References: <20011027005905.A72758@iguana.aciri.org> <200111091005.fA9A5Vo09707@KOM.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200111091005.fA9A5Vo09707@KOM.tu-darmstadt.de> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 09, 2001 at 11:05:31AM +0100, Martin Karsten wrote: > 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? most of them are for statistical purposes, and furthermore I am revising some of them to make them simpler to use and (to some degree) autoconfiguring. For the time being, take the code I posted just as a proof of concept, a cleaned up version should come out soon. In that version you will mostly have knobs to enable/disable polling, and set the max number of packets you will grab from the interface at each clock tick (this is currently poll_burst_max) and whenever a process issues a system call. As i complete some other part of the work, you might have an additional parameter which tells you what is the maximum fraction of the CPU reserved to process "interrupts" (or the equivalent in terms of polling). cheers luigi > 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 Mon Nov 12 1:58: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from keep.scn.ru (SCN-SibInet.sibinet.ru [213.24.217.138]) by hub.freebsd.org (Postfix) with ESMTP id 81DFC37B41A for ; Mon, 12 Nov 2001 01:57:50 -0800 (PST) Received: from scn.ru (alx.sc.ten [10.0.7.13]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id QAA01727; Mon, 12 Nov 2001 16:58:18 +0700 (KRAT) (envelope-from alx@scn.ru) Message-ID: <3BEF9BBD.69BFA678@scn.ru> Date: Mon, 12 Nov 2001 16:51:57 +0700 From: "Alex N. Zhuravlev" X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, archie@whistle.com, julian@whistle.com Subject: Netgraph question Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEC81A469A1CBBD8C99CE5FD2" 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 cryptographically signed message in MIME format. --------------msEC81A469A1CBBD8C99CE5FD2 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi all ! Previously I used a trivial scheme of using netgraph Frame-Relay: FreeBSD router with Cronyx-Tau-E1 |||||| VDAS-300 from RADWIZ Ltd | | | | Ipair1 Ipair2 .... Ipair6 VDAS and Ipairs connected with each other via Frame-relay. Ipairs and FreeBSD are connected via IP over Frame-relay. Here is an example of nodes to connect FreeBSD to Ipairs: --------------------------------------------------------------------- # create a frame_relay type node and attach it to the sync port. /usr/sbin/ngctl mkpeer ${PORT0}: frame_relay rawdata downstream # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. /usr/sbin/ngctl mkpeer ${PORT0}:rawdata rfc1490 dlci${DLCI0} downstream For each Ipair it's own DLCI obviously. And at last to IP # Create ng0 interface /usr/sbin/ngctl mkpeer ${PORT0}:rawdata.dlci${DLCI0} iface inet inet ---------------------------------------------------------------------- After that via ifconfig I can use ng* interfaces as a PPP interfaces to connect to Ipairs - everything works fine !!! And now I've got a little bit complex task. I want everything coming from Ipair1 DLCI 101 comes directly to Ipair6 DLCI 106, not using IP, just via Frame-Relay. Is that possible and if yes how ? Answer please directly - I am currently out of list. Alex N. Zhuravlev --------------msEC81A469A1CBBD8C99CE5FD2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHzAYJKoZIhvcNAQcCoIIHvTCCB7kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BZ8wggJuMIIB16ADAgECAgMFeCEwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA4MjAwNjMzNTJaFw0wMjA4MjAwNjMzNTJa MDwxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxGTAXBgkqhkiG9w0BCQEWCmFs eEBzY24ucnUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMpGvXJwf0+w6VIgTYPDOkXr TzYdsprbfSCCDeb+whSxr+gK/3YCOpJ4fiQpkOjtj7t5IMufUk4IUxjfmv15ipkkNhJo7Z96 CTDdRn0DPx+cuMM6dO/YXBJJA8NCui1TES8JfiKZhdL92QoINU3icwqHFf7ElUppRFaYE1jJ y8hPAgMBAAGjJzAlMBUGA1UdEQQOMAyBCmFseEBzY24ucnUwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQIFAAOBgQDR7ytUJeY6RZLNP/i6BJUYEHw2jtmiyvUg8/1CPdLNH8cK18i2ZayU UEJHMO+ytiJ5vpJ04JMnAgPzEDnGIoVrN8tsUTjA+rU3jUMkYn8DpUSvuGvS6mXf8E6HCDa/ ldQO4EQYw0qT8mbKimutk5q+qHu8SNfdzdpBuqYIYzg71TCCAykwggKSoAMCAQICAQwwDQYJ KoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh d3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjx w0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0 m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjAN BgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23 zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bV iJu3ooga7TlbOX00/LaWGCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGS MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAm BgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwV4ITAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMTExMjA5 NTE1OFowIwYJKoZIhvcNAQkEMRYEFBoYWKAmW23tA17pI4p3j+F4/BNiMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAYxqae6ha+LOMSiRfuEe2nTBO zjH2KbK8JN8QAzKzSHOI9vRj9vend5lWGKP/d5eZ6I6pw1Wu+H2BEo7f5FnIGs1f4sGHzEIq XzhLyindPcXH8X9KP5D01ZMu6uiXseKPZGMr1tEqKevYFMJBwLMWFamtOpa2nAibt5WR9eJ7 rtE= --------------msEC81A469A1CBBD8C99CE5FD2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 12 4:46:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id E245637B417 for ; Mon, 12 Nov 2001 04:46:23 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id fACCk0X89991; Mon, 12 Nov 2001 07:46:00 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: zec@tel.fer.hr (Marko Zec) Cc: freebsd-net@freebsd.org Subject: Re: Intel nics (fxp, wx, gx) questions Date: Mon, 12 Nov 2001 07:45:59 -0500 Message-ID: References: <20011110141356.A60420@ada.snu.ac.kr> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 10 Nov 2001 20:52:09 +0000 (UTC), in sentex.lists.freebsd.net you wrote: >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 Hi, Can you give some more details as to where this introduces performance problems, and if so, how is the best way to work around it? ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 12 13:12:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from noralf.uib.no (noralf.uib.no [129.177.30.12]) by hub.freebsd.org (Postfix) with ESMTP id E8B4837B416 for ; Mon, 12 Nov 2001 13:12:32 -0800 (PST) Received: from tunnel-45-24.vpn.uib.no (ii.uib.no) [129.177.45.24] by noralf.uib.no with esmtp (Exim 3.16) id 163OMq-0005nF-00; Mon, 12 Nov 2001 22:11:44 +0100 Message-ID: <3BF03C0F.9080704@ii.uib.no> Date: Mon, 12 Nov 2001 22:15:59 +0100 From: Trond Davidsen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010909 X-Accept-Language: en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Mpd with a large number, 200+ , of bundles References: <200111031831.fA3IVl424031@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *163OMq-0005nF-00*iPud8HHug7k* http://tjinfo.uib.no/virus.html 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, just an update. I've been debugging a little more and found that mpd hangs hard,top shows mpd's state as 'piperd', when it got over 128 sockets open. This sounds like some kind of system limit to me, any ideas anyone? I've enbled the '#define DEBUG_EVENT' in the file 'event.c' in the mpd source, and got the following in the log: After mpd has set up all the (200) bundles: Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: ACTIVE EVENTS: Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079500 Read(13) REF 150095121 @ 0x80794f0 Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079780 Read(23) REF 150095126 @ 0x8079770 Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079980 Read(31) REF 150095131 @ 0x8079970 [snip] Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: DOING ACTIONS: Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: Doing action for Read(13) REF 150095121 @ 0x80794f0 After a little debugging with gdb, I found that these events are registered at line 299 and 301 in the function NgFuncInit in the file ngfunc.c. Does this give any clue as to where the fault or limit might be located? Trond To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 12 18:44:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns2.its-sby.edu (mail.its-sby.edu [203.130.251.19]) by hub.freebsd.org (Postfix) with SMTP id 1430937B419 for ; Mon, 12 Nov 2001 18:40:35 -0800 (PST) Received: (qmail 9595 invoked from network); 13 Nov 2001 02:44:26 -0000 Received: from unknown (HELO 203.130.251.19) (10.126.11.200) by ns2.its-sby.edu with SMTP; 13 Nov 2001 02:44:26 -0000 From: Royyana Muslim SUBJECT: VISUAL BASIC DOSEN : ROYYANA MUSLIM X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004A_0140B4B0.56B4B0B0" Content-Transfer-Encoding: 7bit Message-Id: <20011113024035.1430937B419@hub.freebsd.org> Date: Mon, 12 Nov 2001 18:40:35 -0800 (PST) To: undisclosed-recipients:; 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_004A_0140B4B0.56B4B0B0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pilihan berikut ini yang BUKAN merupakan penulisan variable yang benar cmdButton NilaiAngka Nilai_huruf Jmlah__Huruf Uang-Muka . ------=_NextPart_000_004A_0140B4B0.56B4B0B0 Content-Type: image/gif; name="JAVAREG.EXE" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="JAVAREG.EXE" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEGAAKs/DEAAAAAAAAAAOAADgELAQQUAF4AAAA8AAAAAAAAoD8A AAAQAAAAcAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAOxCAQAABAAAGAgBAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAACQAAB4AAAAAKAAAIALAAAAAAAAAAAAAAAAAAAA AAAAALAAANwGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAIAAIAA AAC4kQAAQAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA+FwAAAAQAAAAXgAAAAQA AAAAAAAAAAAAAADX1SAAAGAucmRhdGEAAEALAAAAcAAAAAwAAABiAAAAAAAAAAAAAAAAAABAAABA LmRhdGEAAABoDwAAAIAAAAAKAAAAbgAAAAAAAAAAAAAAAAAAQAAAwC5pZGF0YQAANAgAAACQAAAA CgAAAHgAAAAAAAAAAAAAAAAAAEAAAEAucnNyYwAAAIALAAAAoAAAAAwAAACCAAAAAAAAAAAAAAAA AABAAABALnJlbG9jAADskgAAALAAAABuAAAAjgAAAAAAAAAAAAAAAAAAQAAAwqvr9zE4AAEAPsfz MUUAAAA0V/kxTwAAADca+TFaAAAANVf5MWcAAADyZjcycQAAAAAAAAAAAAAAS0VSTkVMMzIuZGxs AE5URExMLkRMTABVU0VSMzIuZGxsAEFEVkFQSTMyLmRsbABvbGUzMi5kbGwAT0xFQVVUMzIuZGxs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOkL AAAAzMzMzMzMzMzMzMzDzMzMzMzMzMzMzMzMzMzMZKEAAAAAVYvsav9olxBAAFBkiSUAAAAAg+wE U1ZXM/85fQh1aWoI6DQrAACJRfCDxASL8Il9/IX2dBPHBohwQACJfgSL/scGcHBAAOsCM/+LRRCL TQzHRfz/////UIsfUVf/E4vYhdt0CVfo4CcAAIPEBIvD6yW4cHhAAOmvKAAAi0XwUOjGJwAAg8QE w4tFEMcAAAAAALgQAQSAi030X2SJDQAAAABeW4vlXcIMAMxkoQAAAABVi+xq/2jvEkAAUGSJJQAA AACLRRSD7AzHAAAAAACDPaSMQAAAU1ZXdCyDPXCIQAAAdCNQi00QUYsVcIhAAFKLAv8Qi030X2SJ DQAAAABeW4vlXcIQAIt1DDPbhfYPhZYAAABqDOhAKgAAiUXwg8QEi/CJXfyF9nQ9aICMQADHBuBw QADGRfwBiV4ExwbQcEAAiV4IxwawcEAA/xUEkkAAi87ocxkAAIhd/Ive6wqLTfDpdBkAADPbi0UU i00Qx0X8/////1CLO1FT/xeL+IX/D4QdAQAAhdsPhBUBAACLA2oBi8v/UAzpBwEAAItF8FDopSYA AIPEBMNqFLsCAAAA6KUpAACJReyDxASL+Ild/DPAhf90ZsZF/APHB/BwQACJRwTHRwjgcEAAxkX8 BGiAjEAAiUcMx0cI0HBAAIlHEMdHCMBwQACJdwzHB6BwQAD/FQSSQACNTwjovBgAAIhd/Il98Osd i03sg8EI6bkYAACLTeyDwQjp7gMAAMdF8AAAAACLRRSLTRBQi1Xwx0X8/////1GLAlL/EIlF6IXA dE+DffAAdEmLRfBogIxAAMdF/AUAAADHAKBwQAD/FRSSQACFwHUSagChoIxAAGoAahJQ/xWskkAA x0X8/////+gqAAAAi0XwUOitJQAAg8QEi33ogz2kjEAAAHQLi0UUiwiJDXCIQACLx+k1/v//i03w g8EI6VEDAAC4mHhAAOlXJgAAi0XsUOhuJQAAg8QEw8zMzMzMzMzMzMxWi/Ho6BcAAPZEJAgBdAlW 6EslAACDxASLxl7CBADMzItEJASDwARQ/xUEkkAAwgQAzMzMzMzMzMzMzMzMzMzMVleLdCQMvwAA AACNRgSDOAB0CVD/FRSSQACL+IX/dQ2F9nQJagGLBovO/1AMi8dfXsIEAMzMzMzMzMzMzMzMzFNW i3QkEFeLfCQYVYtsJBRXVmgAcUAAVeiTFwAAPQJAAIB1M41dCIM7AHUeiw0EcUAAA810FFNouHFA AGoBUWiojEAA/xXskkAAiwuFyXQHV4sBVlH/EF1fXlvCDADMzItEJASDwARQ/xUEkkAAwgQAzMzM zMzMzMzMzMzMzMzMZKEAAAAAVYvsav9oqhRAAFBkiSUAAAAAi0UIg+wEg8AEVoM4AHUEM8DrXlCL NRSSQAD/1olF8IXAdUuDfQgAdEWLRQhogIxAAMdF/AAAAADHAKBwQAD/1oXAdRJqAKGgjEAAagBq ElD/FaySQADHRfz/////6CoAAACLRQhQ6N0jAACDxASLRfCLTfReZIkNAAAAAIvlXcIEALjoeEAA 6ZwkAACLTQiDwQjpgQEAAMxTobhxQABWV4t0JBRVOQZ1N6G8cUAAOUYEdS2hwHFAADlGCHUjocRx QAA5Rgx1GYtcJBSLfCQcU4kfiwP/UAQzwF1fXlvCDACLXCQUi3wkHFdWjWsIaABxQABV6CAWAAA9 AkAAgHUzg8MQgzsAdR6LDQRxQAADzXQUU2i4cUAAagFRaKiMQAD/FeySQACLC4XJdAdXiwFWUf8Q XV9eW8IMAMzMzMzMzMzMzMzMzMzMzItEJASLQARQiwD/UATCBACLRCQEi0AEUIsA/1AIwgQAi0Qk BItUJAxSi0gEi0QkDFBRiwH/EMIMAMzMzMzMzMxkoQAAAABVi+xq/2gtFkAAxwGwcEAAUGSJJQAA AACD7ATHRfwAAAAAaICMQACJTfD/FRSSQACFwHUSagChoIxAAGoAahJQ/xWskkAAx0X8/////+gv AAAA9kUIAXQMi0XwUOhZIgAAg8QEi0Xwi030ZIkNAAAAAIvlXcIEALgQeUAA6RkjAACLTfDpwRQA AMxkoQAAAABVi+xq/2h3FkAAUGSJJQAAAACD7ATHRfz/////iU3w6BcAAACLRfSL5WSjAAAAAF3D uDh5QADpzyIAAItN8Ol3FAAAzMzMzMzMzGShAAAAAFWL7Gr/aN8WQABQZIklAAAAAIPsBMdF/P// //+JTfDoLwAAAPZFCAF0DItF8FDopyEAAIPEBItF8ItN9GSJDQAAAACL5V3CBAC4YHlAAOlnIgAA i03w6Q8UAADMzMzMzMzMzMzMzMzMzMyLRCQEg8AEUP8VBJJAAMIEAMzMzMzMzMzMzMzMzMzMzFZX i3wkDL4AAAAAjUcEgzgAdAlQ/xUUkkAAi/CF9nUJV+gqIQAAg8QEi8ZfXsIEAItEJAyLTCQIi1Qk BFBRaBhxQABS6NcTAADCDADMzMzMg+wEaKiAQAD/FQiSQABomIBAAFD/FQySQACJRCQAhcB1H4N8 JAwCdAm4VwAHgIPEBMOLRCQIUP8V6JJAAIPEBMOLRCQMi0wkCFBR/1QkCIPEBMPMzMzMzMzMzMzM zMzMZKEAAAAAVYvsav9o7xtAAFBkiSUAAAAAgexkAgAAjYWQ/f//i00IU1ZXaAQBAABQvyyBQABR /xX8kUAAuf////8rwPKu99Er+YvRi/e5/////429kP3//yvA8q5Pi8rB6QLzpYvKg+ED86SLfQy5 /////yvA8q730Sv5i9GL97n/////jb2Q/f//K8Dyrk+LysHpAvOli8qD4QPzpIM9pIxAAAF1NL8o gUAAuf////8rwPKu99Er+YvRi/e5/////429kP3//yvA8q5Pi8rB6QLzpYvKg+ED86SDPVCAQAAB dTS/HIFAALn/////K8DyrvfRK/mL0Yv3uf////+NvZD9//8rwPKuT4vKwekC86WLyoPhA/Oki0UU jY3U/v//UDPbaAyBQABR/xWwkkAAg8QMi0UQOBh0YlOJXeBTiV38aD8ADwCNTeBTU1BoAAAAgOja GwAAjYXU/v//UP8V+JFAAECNjdT+//9Qi1XgUWoBU1NS/xXAkUAAU4tNDFGJReRoBIFAAI1N4Ohh HAAAx0X8/////+iRAAAAaD8ADwCNTezHRewAAAAAx0X8AQAAAGgEgUAAaAAAAIDo4BsAAGoAi0UM agCLTexoPwAPAGoAagBQUY1N7OhTGwAAjY3U/v//Uf8V+JFAAECNjdT+//9Qi1XsUWoBagBqAFL/ FcCRQACLdRiJRfCF9nQni0UMUP8V+JFAAECLTQxQi1XsUWoBagBo/IBAAFLrbI1N4OkMAgAAuLiM QAC/AAAAAIXAdD9ouIxAAOikIQAAg8QEjRxFAgAAAI0ERQUAAACD4PzoWyEAAIv8agDGBwBqAFNX av9ouIxAAGoAagD/FQCSQABX/xX4kUAAQItN7FBXagFqAGj8gEAAUf8VwJFAAIlF8ItFEIA4AHQQ agCNTexQaPSAQADoNxsAAIM9UIBAAAB0GGoAjYWQ/f//UI1N7GjkgEAA6BgbAADrDWjkgEAAjU3s 6LkbAABqAI1N7GjYgEAAaGBwQADo9RoAAGjIgEAAjU3saMCAQABoYHBAAOjeGgAAaLSAQACLRRRQ jU3saGBwQADoyBoAAI1N7OjgGQAAhfZ0ZWg/AA8AjU3saPyAQABoAAAAgOhVGgAAagCLRQxqAItN 7Gg/AA8AagBqAFBRjU3s6MgZAACNjdT+//9R/xX4kUAAQI2N1P7//1CLVexRagFqAGoAUv8VwJFA AI1N7IlF8Oh3GQAAx0XoAAAAAI1F6FBoQHBAAGoBagBoMHBAAP8V7JJAAIXAfEGhUHBAAIsdVHBA AIs1WHBAALlQcEAAjVXYUmoBaKiMQACJAolaBItBDIlyCItN6FGJQgyLAf9QFItN6FGLAf9QCMdF /P/////oIAAAAItF9I2lhP3//2SjAAAAAF9eW4vlXcO4iHlAAOlXHQAAjU3s6Q8AAADMzMzMzMzM zMzMzMzMzMzpyxgAAMzMzMzMzMzMzMzMZKEAAAAAVYvsav9oSR1AAFBkiSUAAAAAgewgAQAAU1Yz 9mg/AA8AaASBQACNTexoAAAAgIl17Il1/MZF/AGJdeToChkAAGg/AA8Ai0UMUItN7FGNTeTo9RgA AI1N2I2V1P7//1GLReRSiXXYaPSAQABQ/xW4kUAAhcB1Mmg/AA8AjU3cVol13MZF/AJoAAAAgOi6 GAAAjYXU/v//jU3cUOirGQAAxkX8AehrAAAAjU3k6AoYAACLRQyNTexQ6I4ZAACNTezo9hcAAGg/ AA8AjU3saPyAQABoAAAAgOhvGAAAi0UMjU3sUOhjGQAAjU3s6MsXAADGRfwA6CMAAADHRfz///// 6CkAAACLRfReZKMAAAAAW4vlXcONTdzpz/7//41N5OnH/v//uLh5QADp/RsAAI1N7Om1/v//zMzM zMxkoQAAAABVi+xq/2h4KkAAUGSJJQAAAAC48CUAAOgOHgAAU1ZXM9tqQImdKP7//8eFCOz//wEA AABouIxAAGggcEAA/xXckkAAi0UIuXiMQABQiV3saFiAQADogQ4AAP8V4JFAAGgABAAAi00IaHiI QACjoIxAAKEEgkAAagdRiUXw/xW4kkAAjU3wi1UQUVLoyx4AAIPECIvwiZ0M9f//iJ0Q9f//iZ0M 8f//iJ0M7P//iJ0s/v//hfYPhKICAABoAIJAAFboVR8AAIPECIXAD4RXDAAAhfYPhIQCAABo9IFA AFboNx8AAIPECIXAD4RPAgAAaOiBQABW6CEfAACDxAiFwA+EOQIAAGjcgUAAVugLHwAAg8QIhcAP hBcCAABo0IFAAFbo9R4AAIPECIXAD4QBAgAAaMiBQABW6N8eAACDxAiFwA+ErgEAAGjAgUAAVujJ HgAAg8QIhcAPhFsBAABouIFAAFbosx4AAIPECIXAD4S+AAAAaKyBQABW6J0eAACDxAiFwHUPx4UI 7P//AAAAAOm0AQAAaKCBQABW6HweAACDxAiFwHR8aJyBQABW6GoeAACDxAiFwHRqaJSBQABW6Fge AACDxAiFwHRJaJCBQABW6EYeAACDxAiFwHQ3aIiBQABW6DQeAACDxAiFwHQWaISBQABW6CIeAACD xAiFwA+FRAEAAMeFKP7//wEAAADpNQEAAMcFpIxAAAEAAADpJgEAAMcFUIBAAAEAAADpFwEAAI1F 8FBqAOgfHQAAg8QIhcAPhOEKAACL+Ln/////K8DyrvfRK/mLwcHpAov3jb0s/v//86WLyIPhA/Ok jY0s/v//Uf8V+JFAAI14AY0ERQUAAACD4PzooBsAAIv0ZscGAACNhSz+//9XVmr/UGoAagD/FeSR QABoqIxAAFb/FeCSQADpkAAAAI1F8FBqAOiYHAAAg8QIhcAPhFoKAACL+Ln/////K8DyrvfRK/mL wcHpAov3jb0M7P//86WLyIPhA/Ok61ONRfBQagDoWxwAAIPECIv4hf8PhBsKAAC5/////yvA8q73 0Sv5i8HB6QKL9429EPX///Oli8iD4QPzpOsWx4UM9f//AQAAAOsKx4UM8f//AQAAAI1F8FBqAOgI HAAAg8QIi/DpdP3//4O9DPH//wAPhQACAACDvQz1//8AD4XzAQAAgL0Q9f//AHUXvqiMQAC/2HFA ALkQAAAA86YPhJEJAACDvSj+//8AdAb/FeiRQACAvSz+//8AD4StAAAAM9uNhSz+//9QjY0Y9/// aECBQABR/xWwkkAAg8QMjY0o/v//jYUY9///UVBoAAAAgP8VxJFAAIXAdWWNhQz1//+NjdDw///H hQz1//9AAAAAUIuVKP7//1FTU2jIgEAAUv8VzJFAAIXAdTVowIBAAI2F0PD//1DoTBoAAIPECIXA dBhoOIFAAI2F0PD//1DoNBoAAIPECIXAdQW7AQAAAIuFKP7//1D/FbyRQACD+wF1BGoA6wJqAmoA 6Jn1//+DxAgzwDiFLP7//3RyiYUo/v//iUX8OYUo/v//dAyLhSj+//9Qixj/UwjHhSj+//8AAAAA jYUo/v//UGi4cUAAagD/FVyAQACFwHwajUXsi40o/v//UGoCagRRaKiMQAD/FfCSQADHRfz///// 6AIAAADrGY2NKP7//+mKCAAAagK5eIxAAGoE6AwKAABqAI2FWP///2oAizXAkkAAagBQ/9aFwHQi iz28kkAAjYVY////UP/XagCNhVj///9qAGoAUP/WhcB15IN97AB0DItF7FD/FdiSQADrE4C9LP7/ /wB1Crl4jEAA6NwJAAD/FeSSQADp7AcAAGoCagDomPT//4PECIO9DPX//wAPhH0CAABoAAEAAI2F GPj//1CLTQhqAVH/FbiSQABoPwAPAI1NvMdFvAAAAADHRfwBAAAAaPyAQABoAAAAgOhLEgAAhcB1 H2oAagBoPwAPAI1NvGoAagBo/IBAAGgAAACA6LgRAAC4uIxAAL8AAAAAhcB0P2i4jEAA6GAYAACD xASNNEUCAAAAjQRFBQAAAIPg/OgXGAAAi/xqAMYHAGoAVldq/2i4jEAAagBqAP8VAJJAAGoAi0W8 agCNTbxoPwAPAGoAagBXUOhREQAAjYUY+P//UP8V+JFAAECNjRj4//9Qi1W8UYs1wJFAAGoBagBq AFL/1moBuXiMQACJRcDo6g0AAGg/AA8AjU28aASBQAC7AAAAAGgAAACA6G4RAAC5uIxAAIXJdD9o uIxAAOirFwAAg8QEjTxFAgAAAI0ERQUAAACD4PzoYhcAAIvcagDGAwBqAFdTav9ouIxAAGoAagD/ FQCSQABqAItFvGoAjU28aD8ADwBqAGoAvwAAAABTUOiXEAAAuLiMQACFwHQ/aLiMQADoRBcAAIPE BI0cRQIAAACNBEUFAAAAg+D86PsWAACL/GoAxgcAagBTV2r/aLiMQABqAGoA/xUAkkAAV/8V+JFA AECLTbxQV2oBagBo/IBAAFH/1o2NKP7//4lFwMeFKP7//wAAAABRaEBwQABqAWoAaDBwQAD/FeyS QACFwHxjjZUY+f//oVBwQAC5UHBAAIkCi1kEaGiBQACJWgSLcQiJcgiLQQyNjSz5//9RiUIMx4Uo +f//CQQAAOhbFwAAg8QIjY0Y+f//i5Uo/v//UYsCagFS/1AMi40o/v//UYsB/1AIx0X8/////+hQ AQAAM9s4nRD1//8PhJgDAACNhSj+//+IXcTHhRT5//8IAgAAUGgEgUAAaAAAAID/FcSRQADHhQzx //8oAAAAjYUk+v//UFNTU42NDPH//42VMP///1GLhSj+//9SU1D/FciRQAA96gAAAHQIhcAPhfwA AACNvTD///+5/////yvA8q730Sv5i8HB6QKL9429GPf///Oli8iD4QPzpL9YgUAAuf////8rwPKu 99Er+YvRi/e5/////429GPf//yvA8q5Pi8rB6QLzpYvKg+ED86SNRcCNjRj3//9Qi5Uo/v//UVL/ FcSRQACFwHVJjYUU+f//jY0E5v//UItVwFFqAGoAaLSAQABS/xXMkUAAhcB1Go2FEPX//42NBOb/ /1BR6FkVAACDxAiFwHQvi0XAUP8VvJFAAEONhST6///HhQzx//8oAAAAUGoAagBqAOn2/v//jU28 6VP1//+NhTD///+NTcRQizXskUAAUf/W6waLNeyRQACLhSj+//9Q/xW8kUAAg70M9f//AA+EkAEA AIC9LP7//wAPhYMAAACAfcQAdXCNhQD1//9Q/xXMkkAAaiiNjXT///9RjYUA9f//UP8V3JJAAI2N dP///1HojBQAAIPEBI0cRQIAAACNBEUFAAAAg+D86EMUAACL/I2FdP///2oAagDGBwBTV2r/UGoA agD/FQCSQABXjYUs/v//UOsLjUXEjY0s/v//UFH/1oB9xAB0JY2FLP7//41NxFBR/xX0kUAAhcB0 EI1FxItNCFBR6Hb0//+DxAiNhSz+//9Q/xX4kUAAjXABjQRFBQAAAIPg/OjEEwAAi/xmxwcAAI2F LP7//1ZXav9QagBqAP8V5JFAAGiojEAAV/8V4JJAAIXAD4yRAgAAi4UI7P//jY0Q9f//UI2VDOz/ /1GNhSz+//9Si00IUFHor+///4PEFI2NBNr//4tVCGgABAAAUWoCUv8VuJJAAI2NLP7//42VEPX/ /1GNhQTa//9SjY0E3v//UFH/FbCSQACDxBCNjQTe//9qQGh4iEAAUWoA/xW0kkAA/xXkkkAA6TkC AACAfcQAdFmNRcSLTQhQUeiL8///g8QIjY0M6P//i1UIaAAEAABRagNS/xW4kkAAjU3EjZUQ9f// UY2FDOj//1KNjRDx//9QUf8VsJJAAIPEEI2NEPH//2pAaHiIQADrjWgABAAAjYUQ8f//UItNCGoE Uf8VuJJAAGoQjY0Q8f//aHiIQADpY////4O9DPH//wAPhF////+AvSz+//8AdGiNhSz+//+LTQhQ Uejv8v//g8QIjY0M6P//i1UIaAAEAABRagVS/xW4kkAAjY0s/v//jZUM6P//UY2FLPr//1KLNbCS QABQ/9aDxAyNjSz6//+LPbSSQABqQGh4iEAAUWoA/9fpnwAAADP/aD8ADwBo/IBAAI2NJP7//2gA AACAib0k/v//x0X8AgAAAOi+CwAAuLiMQAA7x3Q/aLiMQADo+xEAAIPEBI00RQIAAACNBEUFAAAA g+D86LIRAACL/GoAxgcAagBWV2r/aLiMQABqAGoA/xUAkkAAV42NJP7//+hqDAAAuXiMQADoAAgA AMdF/P/////oZgAAAIs1sJJAAIs9tJJAAGgABAAAjYUQ7f//UItNCGoDUf8VuJJAAI2NLP7//42V EPX//1GNhRDt//9SjY0Q8f//UFH/1oPEEI2NEPH//2pAaHiIQABRagD/1+n//f//uPB5QADpzg4A AI2NJP7//+mD8f//aAAEAACNhQTi//9Qi00IagZR/xW4kkAAakCNjQTi//9oeIhAAFFqAP8VtJJA ADPAi030ZIkNAAAAAI2l+Nn//19eW4vlXcIQAMzMzMzMzMzMzMyLAYXAdAZQiwD/UAjDzMzMw8zM zMzMzMzMzMzMzMzMzFaLQQjHAdBwQACL8YXAdBdQiwD/UAjHRggAAAAAxwVwiEAAAAAAAF7DzMzM zMzMzIsBhcB0BlCLAP9QCMPMzMyLTCQQU1aFyVdVdQy4A0AAgF1fXlvCEACLVCQcxwEAAAAAizI5 NbhxQAB1PKG8cUAAOUIEdTKhwHFAADlCCHUoocRxQAA5Qgx1HotcJBiLQwQDRCQUiQF0BlCLAP9Q BDPAXV9eW8IQAItcJBiDOwB0RYt8JBSLAzkwdTOLagQ5aAR1K4tqCDloCHUji2oMOWgMdRuLQwiF wHQog/gBdDuD+AJ1CotDBAPHgzgAdTmDwwyDOwB1v7gCQACAXV9eW8IQAItDBAPHiQF0BlCLAP9Q BDPAXV9eW8IQAFFSV/9TBF1fXlvCEACLAFGLGFJQ/xNdX15bwhAAzMzMzMzMzMzMi0QkBItUJAho iIxAAIlBBDPAiRGJQQiJQQz/FRCSQADCCADMzMzMzMzMzMzMzMzMUzPAVotZBFc5A3Qdi3QkEIt8 JBSFwHURV4vLVoPDIOhMAAAAgzsAdetfXlvCCADMVjPAV4txBDkGdCOLPdiSQACFwHUZi0YchcB0 BVD/1+sFuFcAB4CDxiCDPgB1419ew8zMzMzMzMzMzMzMzMzMzGShAAAAAFWL7Gr/aGwtQABQZIkl AAAAADPAg+wIiUXwiUX8VovxOUXwdAmLRfBQiwD/UAjHRfAAAAAAjUXwUGi4cUAAagD/VgSJReyF wHwcjUYci00MUItVCFGLRfBSiw5QUf8V8JJAAIlF7MdF/P/////oHgAAAItF7ItN9GSJDQAAAABe i+VdwggAuCh6QADp2gsAAI1N8Oli/f//zMyLVCQQVoXSdQm4A0AAgF7CEACLdCQMxwIAAAAAhfZ0 NKG4cUAAi0wkEDkBdR6hvHFAADlBBHUUocBxQAA5QQh1CqHEcUAAOUEMdA24EAEEgF7CEACLTCQQ i0QkCFJRVlCLMP9WFF7CEADMzMzMzMzMg3wkCABogIxAAHQL/xUEkkAAM8DCCAD/FRSSQACFwHUS agChoIxAAGoAahJQ/xWskkAAM8DCCADMzMzMzMzMzGShAAAAAFWL7Gr/aB0wQABQZIklAAAAAIHs EAIAAI2F6P7//1NWV4vxaAABAABQi1UMi04QUVL/FbiSQABoBAEAAI2N5P3//1GLVQhS/xX8kUAA jU3oixZRuwAAAABS/xXQkkAAg33oAHQ9i0XoUOgcDQAAg8QEjTxFAgAAAI0ERQUAAACD4Pzo0wwA AIvci0XoagBqAMYDAFdTav9QagBqAP8VAJJAAI2F6P7//4tOCFBRU+hHAQAAjY3o/v//i1YMUTP/ UlPoNAEAAGg/AA8AjU3saFhxQACJfexoAAAAgIl9/OhXBgAAV4tF7FeNTexoPwAPAFdXU1Do0QUA AI2F6P7//1D/FfiRQABAjY3o/v//UItV7FFqAVdXUv8VwJFAAFeLTghRiUXwaDBxQACNTezoWAYA AFeLTgxRaDhxQACNTezoRgYAADl9CHQnV/8VCJJAADtFCHQb9kYUBLiQcUAAdQaNheT9//9qAFBo cHFAAOsOagCNheT9//9QaGBxQACNTezoBAYAAItGFIPgA4P4AXUMaIBxQABooHFAAOsPg/gCdRdo gHFAAGiwcUAAaHBxQACNTezo0QUAAItF6FD/FdSSQADHRfz/////6CIAAACLRfSNpdj9//9kowAA AABfXluL5V3CCAC4UHpAAOkpCQAAjU3s6eHr///MZKEAAAAAVYvsav9oyTBAAFBkiSUAAAAAg+wI x0XsAAAAAMdF/AAAAABWV2oAi0UMagCNTexoPwAPAGoAagBQaAAAAIDohwQAAIt9EFf/FfiRQABA i03sUFdqAWoAagBR/xXAkUAAagCLTQhRiUXwaFhxQACNTezoFAUAAMdF/P/////oGwAAAItF9F9k owAAAABei+VdwgwAuHh6QADpfQgAAI1N7Ok16///zMzMzMxkoQAAAABVi+xq/2i5MUAAUGSJJQAA AACD7AxWV4v5M/aNTeiJdfzHRegAAACAi0cIUOhZBQAAi0cMjU3oUOhNBQAAjUXwiw9QUf8V0JJA ADl18HQ9i0XwUOiCCgAAg8QEjTxFAgAAAI0ERQUAAACD4PzoOQoAAIv0i0XwagBqAMYGAFdWav9Q agBqAP8VAJJAAGg/AA8Ai0XoaFhxQACNTehQ6OgDAABWjU3o6N8EAACLRfBQ/xXUkkAAx0X8//// /+gcAAAAi0X0jWXgZKMAAAAAX16L5V3DuKB6QADpjQcAAI1N6OlF6v//zMzMzMxWV4txBIv5gz4A dBOLB4vOUIPGIFDoRvz//4M+AHXtM8A5RCQMdAeLz+gyAAAAX17CBADMzMzMzMzMzMzMzMzMVotx BIM+AHQPi86DxiDovf7//4M+AHXxM8Bew8zMzMxkoQAAAABVi+xq/2hpNEAAUGSJJQAAAACB7BQC AACNheT+//+LCVNWV2gEAQAAUFH/FfyRQACNheT+//+LNfiRQADHRfAAAAAAx0X8AAAAAFD/1o1Y AY0ERQUAAACD4Pzo+wgAAIv8ZscHAACNheT+//9TV2r/UGoAagD/FeSRQACDffAAdAmLRfBQixj/ UwjHRfAAAAAAjUXwUFf/FaSSQACFwA+NoAAAAI2F5P7//1D/1oC95P7//wCNvAXk/v//jYXk/v// dBWLHcSSQACAOC51Aov4UP/TgDgAdfFoCIJAAFf/FeyRQACNheT+//9Q/9aNWAGNBEUFAAAAg+D8 6FsIAACL/GbHBwAAjYXk/v//U1dq/1BqAGoA/xXkkUAAg33wAHQJi0XwUIsY/1MIx0XwAAAAAI1F 8FBX/xWkkkAAhcAPjNwAAACNheT+//9Q/9aL+GoAagCNheT+//9Q6OsAAAAr+I2N4P3//42F5P7/ /1BR/xXskUAAxoQ94P3//wCNjeD9//9R/9aNWAGNBEUFAAAAg+D86MIHAACL/GbHBwAAjYXg/f// U1dq/1BqAGoA/xXkkUAAjYXk/v//UP/WjVgBjQRFBQAAAIPg/OiLBwAAi/RmxwYAAI2F5P7//1NW av9QagBqAP8V5JFAAFeLRfBWUP8VoJJAAIlF7MdF/P/////oNwAAAItF7ItN9I2l1P3//2SJDQAA AABfXluL5V3Dx0X8/////+gRAAAAuAEAAADr1rjIekAA6d0EAACNTfDptfb//8zMzMzMU1ZXi3wk EIvfgD8AdCOLNcSSQACKAzxcdAg8L3QEPDp1BVP/1ov4U//WgDgAi9h144tEJBSFwHUOV/8V+JFA AEBfXlvCDACLTCQYUVdQ/xXwkUAAM8BfXlvCDADMzMzMVosBi/GFwHQQUP8VvJFAAIlGBMcGAAAA AF7DzMzMzMyD7AiNRCQAVovxUI1MJAyLVCQoi0QkJFGLTCQkUotUJCRQi0QkJFGLTCQkUmoAUFH/ FdiRQACJRgSLRCQohcB0BotMJASJCIvO6JL///+DfgQBi0QkCIkGXhvAg8QI99jCHADMzMzMzMzM zMzMzMzMg+wEjUQkAFaL8VCLTCQYi1QkFItEJBBRx0QkDAAAAABqAFJQ/xXQkUAAi86JRgToPP// /4N+BAEbwItMJAT32IkOXoPEBMIMAMzMzMzMzMxkoQAAAABVi+xq/2heNkAAUGSJJQAAAAAzwIPs DIlF6IlF/FZQUGg/AA8AiwlQUItFCFBRjU3o6AT///+FwHUfx0X8/////+hcAAAAM8CLTfReZIkN AAAAAIvlXcIMAIt1DFb/FfiRQABAi00QUItV6FZqAWoAUVL/FcCRQACLTfCJRezHRfz/////g/gB GU3w913w6A8AAACLRfDrsLjwekAA6egCAACNTejpoOX//2ShAAAAAFWL7Gr/aFA3QABQZIklAAAA ADPAgewUAQAAiUXoiUX8U1aLRQhXi/FoPwAPAFCLDlGNTejowf7//4XAdR7HRfz/////6JsAAACL RfRfZKMAAAAAXluL5V3CBAC/AAEAAI1F4FCNTfBqAI2V4P7//2oAi0XoagCLHciRQABRiX3wUmoA UP/ThcB1M42F4P7//41N6FDoYf///41F4I1N8FCNleD+//9qAItF6GoAiX3wagBRUmoAUP/ThcB0 zY1N6Oil/f//i0UIiw5QUf8V1JFAAIlGBOlj////uBh7QADp9gEAAI1N6Omu5P//zMzMzMzMzMzM zMzMzMxqGei5CQAAg8QEw8xVi+xTVldVagBqAGiUN0AA/3UI6F41AABdX15bi+Vdw4tMJAT3QQQG AAAAuAEAAAB0D4tEJAiLVCQQiQK4AwAAAMNTVleLRCQQUGr+aJw3QABk/zUAAAAAZIklAAAAAItE JCCLWAiLcAyD/v90Ljt0JCR0KI00dosMs4lMJAiJSAyDfLMEAHUSaAEBAACLRLMI6EAAAAD/VLMI 68NkjwUAAAAAg8QMX15bwzPAZIsNAAAAAIF5BJw3QAB1EItRDItSDDlRCHUFuAEAAADDU1G7EIJA AOsKU1G7EIJAAItNCIlLCIlDBIlrDFlbwgQAzMzMzMzMi0QkBFDo5ggAAIPEBMPMzFWLRCQMi+yD wAyD7ASJRfxTZIsdAAAAAIsDZKMAAAAAi0UIi10Mi2P8i238/+Bbi+VdwggAzMzMzMzMzMzMzMxY WYcEJP/gzMzMzMzMzMzMWFmHBCT/4MzMzMzMzMzMzFhZhwQk/+DMzMzMzMzMzMxVi+yD7AhTVldk oQAAAACJRfjHRfwcOUAAagCLRQxQi0X8UItFCFDo1jMAAItFDINgBP1koQAAAACLXfiJA2SJHQAA AADpAAAAAF9eW8nCCADMzMzMzMzMzMzMzMzMzMxVi+yD7AhTVlf8iUX4agCLRfhqAItNFGoAi1UQ UFFSi0UMUItNCFHoBAgAAIPEIIlF/F9eW4tF/IvlXcPMzMzMi0QkCItMJASD7BSJRCQIiUwkDMdE JAAAAAAAx0QkBAA6QACLRCQkQIlEJBBkoQAAAACJRCQAjUQkAGSjAAAAAItEJChQUYtMJChR6AAS AACLyItEJABkowAAAACLwYPEFMPMzMzMzMzMzMzMzMzMzPyLTCQIagBRi0EQUItRCItEJBhSagCL SQyLVCQYUFFS6FsHAACDxCDDzMzMzMzMzFWL7IPsNFNWV8dF2AAAAADHRdwQO0AAi0UYiUXgi0UM iUXki0UciUXoi0UgiUXsx0XwAAAAAMdF9AAAAADHRfgAAAAAx0X8AAAAAMdF8Mc6QACJZfSJbfhk oQAAAACJRdiNRdhkowAAAADHRcwBAAAAi0UIiUXQi0UQiUXUjUXQUItFCIsAUP8VQIJAAIPECMdF zAAAAACDffwAD4QaAAAAZIsdAAAAAIsDi13YiQNkiR0AAAAA6QkAAACLRdhkowAAAACLRczpAAAA AF9eW8nDzMzMzMzMzMzMzMzMzMzMVYvsU1b8i3UI9kYEZnQTi0UMXltdx0AkAQAAALgBAAAAw2oB i0UMi0gUi1AQUVKLSAiLVRBRagBSi0gMUVboLQYAAIPEIItNDIN5JAB1B1ZR6Ir9//+LXQyLYxyL ayD/Yxi4AQAAAF5bXcPMzMzMzItEJARqAVDotAMAAIPECMNRPQAQAACNTCQIchSB6QAQAAAtABAA AIUBPQAQAABz7CvIi8SFAYvhiwiLQARQw8yLTCQEi8GL0IPAAmaDOgB19SvBwfgBSMPMzMzMzMzM zItEJARTgz1Ug0AAAFaLdCQQdSmKCDoOdRsKyXQSikgBOk4BdQ+DwAKDxgIKyXXkM8BeW8MbwF6D 2P9bw0AzyWYPtlD/isr2gVGCQAAEdBeKCITJdQVmM9LrDGbB4ghAZg+2yWYL0UYz22YPtk7/itn2 g1GCQAAEdBeKHoTbdQVmM8nrDGbB4QhGZg+222YLy2Y7ynUKZoXSdaIzwF5bwxvAXoPgAltIw8zM zMzMzMzMi0QkBFZXi9CLTCQQZosxi/pmiTeDwgKDwQJmhfZ17V9ew8zMzMzMzMzMzMzMzMzMgz1U g0AAAFZXdRWLfCQQi0QkDFdQ6HYUAACDxAhfXsOLRCQMhcB0I6M4jUAAi3wkEKE4jUAAV1DooxMA AIPECIvwhfZ1EzPAX17Dgz04jUAAAHXZM8BfXsOKBoTAdFUzyYrI9oFRgkAABHQGgH4BAHRCV1bo xxIAAIPECIXAdCWKCITJdB8z0orR9oJRgkAABHQExgAAQMYAAEBfoziNQACLxl7Di8ZfxwU4jUAA AAAAAF7DM8BfXsPMzMzMzMzMgz1Ug0AAAFNWdRWLdCQQi0QkDFZQ6JYUAACDxAheW8OLRCQMi3Qk EEAzyWYPtlD/isr2gVGCQAAEdE2KCITJdQVmM9LrUmbB4ghAZg+2yWYL0WY7FWCDQAByEmY7FWKD QAB3CWYDFWSDQADrK2Y7FWaDQAByImY7FWiDQAB3GWYDFWqDQADrEGaD+kFyCmaD+lp3BGaDwiBG M9tmD7ZO/4rZ9oNRgkAABHRNih6E23UFZjPJ61JmweEIRmYPtttmC8tmOw1gg0AAchJmOw1ig0AA dwlmAw1kg0AA6ytmOw1mg0AAciJmOw1og0AAdxlmAw1qg0AA6xBmg/lBcgpmg/ladwRmg8EgZjvK dQ5mhdIPhRL///8zwF5bwxvAXoPgAltIw8zMzMzMzMzMzMzMzFNWi3QkDFeLfCQUhfZ1DVfoWwAA AIPEBF9eW8OF/3UPVuiKAgAAg8QEM8BfXlvDix2AkkAAoWCPQACD/+B2BDPA6wdXVmoAUP/ThcB1 HYM9dIRAAAB0FFfo0xMAAIPEBIXAoWCPQAB10TPAX15bw8yhdIRAAItMJARQUegQAAAAg8QIw8zM zMzMzMzMzMzMzFZXi3QkDIP+4HYFM8BfXsOF9nUFvgEAAACLfCQQVugdAAAAg8QEhcB1E4X/dA9W 6GwTAACDxASFwHXiM8BfXsOLRCQEiw1gj0AAUGoAUf8VhJJAAMPMzMzMzMzMzMzMzFLoCgAAAAPD 6QYAAAAxHZj8w0Do9////1roggAAAOgKAAAA6QoAAAAxKsHgVUgbx8OQM8boCgAAABPE6QgAAAAx FvyQw8HIS4PwV+jy////VovyDzGLxovWXugPAAAA1gPA6Q4AAAAxKg0tQqUCg8A0wzPAkPgTwugP AAAAK8LW6Q0AAAAxFrh2SqUCwfh/w4vGwcic6O3/////FWSQQAAjw0BkZ/82AABkZ4kmAAAzwIEQ 6FGlAgCKBjwidAw8IHY1RoA+IHf66y1GgD4idCaKXdiKHoTbdBgzwIrDUOhNFQAAg8QEhcB0AUZG gD4ideKAPiJ1AUaAPgB0C4A+IHcGRoA+AHX1x0W8AAAAAI1FkFD/FRiSQAD2RbwBuAoAAAB0CItF wCX//wAAUFZqAGoA/xUIkkAAUOiD3P//UOhNEgAA6yeLReyLAIsAiUXgi0XsUItF4FDoRBMAAIPE CMOLZeiLReBQ6EQSAACDxATHRfz/////i0XwX2SjAAAAAF5bi+Vdw8zMzMzMzMzMzMyDPSyCQAAB dQXoshwAAItEJARQ6OgcAACDxARo/wAAAP8VKIJAAIPEBMPMzMzMzMyLRCQEhcB0D1BqAKFgj0AA UP8VkJJAAMPMzMzMzMzMzFaLdCQYgT4gBZMZdAXoHgsAAItMJAj2QQRmdCmDfgQAdByDfCQcAHUV i0QkFGr/i0wkEFZQUeilBAAAg8QQuAEAAABew4N+DAB0aoE5Y3Nt4HU6gXkUIAWTGXYxi0Eci1AI hdJ0J4tEJCRQi0QkJFCLRCQkUFaLdCQki0QkIFZQi3QkJFZR/9KDxCBew4tEJCCLVCQcUFKLRCQs i1QkGFBWi3QkJItEJBxWUlBR6A4AAACDxCC4AQAAAF7DzMzMzItEJAiD7BhTi0gIiUwkCFZXg/n/ VXwJi0QkPDlIBH8F6EsKAACLVCQsgTpjc23gdW+DehADdWmBehQgBZMZdWCDehwAdVqDPTiCQAAA D4Q5AgAAixU4gkAAoTyCQACJVCQsagGJRCQ4UugSHgAAg8QIhcB1Bej2CQAAi1QkLIE6Y3Nt4HUa g3oQA3UUgXoUIAWTGXULg3ocAHUF6NAJAACLVCQsgTpjc23gD4WYAQAAg3oQAw+FjgEAAIF6FCAF kxkPhYEBAACNRCQgjUwkHItUJBRQi0QkSFGLTCREUlBR6JsCAACLTCQ0iUQkJIPEFDlMJBwPgzAB AACLTCQUi1QkEDkKD48JAQAAOUoED4wAAQAAi0IQi0oMiUwkGIXJD4TuAAAAi1QkLItKHItJDI1p BIsJhckPhI4AAACLVCQsi3UAi3gEi1ociVwkJIX/dGSNVwiAOgB0XDl+BHQvi34Eg8cIiho6H3Ua Ctt0EopaATpfAXUOg8ICg8cCCtt15DPS6wUb0oPa/4XSdST2BgJ0BfYACHQai1QkJIsS9sIBdAX2 AAF0CvbCAnQJ9gACdQQz0usFugEAAACF0nUgSYPFBIXJD4Vy////g8AQ/0wkGIN8JBgAD4VJ//// 6zWLTCRIi1QkRItcJBBRUotNAItUJEBTUVCLRCRQi0wkSFBSi0QkTFGLVCRMUFLoAAMAAIPEKItE JCD/RCQcg0QkEBQ5RCQcD4LQ/v//gHwkQAB0W4tUJCxqAVLoswYAAIPECF1fXluDxBjDgHwkQAB1 OItMJEiLRCREi1QkFFGLTCRAUItEJEBSi1QkQFGLTCRAUItEJEBSUVDoJAAAAIPEIF1fXluDxBjD 6GQHAABdX15bg8QYw8zMzMzMzMzMzMzMzIPsCIM9QIJAAABTVldVdDWLRCQ4i3QkNIt8JCxQi0Qk LFaLTCQsV4tUJCxQi0QkLFFSUOgY9f//g8QchcAPhYoAAADrCIt0JDSLfCQsjUQkFI1MJBCLXCQw UFFTVlfofQAAAIPEFIvoi0QkEDlEJBR2WzldAH9FOV0EfECLTQzB4QQDTRCLQfSFwHQGgHgIAHUq i0QkOIPpEItUJChQi0QkKFZVagBRV4tMJDhSi1QkOFBRUui3AQAAg8Qog8UU/0QkEItEJBA5RCQU d6VdX15bg8QIw8zMzMzMzMzMzMzMi0QkBIPsDFOLSBCJTCQMVleLcAyLfCQgVYl0JBCJdCQUhf98 Q40MtQAAAACLRCQYi2wkKI0UiY1cAgSD/v91BeirBgAAg+sUTjkrfQU5awR9BYP+/3UNT4tMJBSJ TCQQiXQkFIX/fdNGi0QkLItUJDCLTCQQiTCLRCQgiQo5SAxyBDvOcwXoZQYAAMHmAotEJBhdX40M tl4DwVuDxAzDzGShAAAAAFWL7Gr/aOh0QABoDF1AAFCLRQhkiSUAAAAAg8AIg+wUiwiJReCJTeRT OU0UVleJZeh0cIN95P9+C4tFEItN5DlIBH8F6AEGAADHRfwAAAAAi0UQi0AIi03ki0TIBIlF3IXA dCRoAwEAAItFCFCLRdxQ6AQFAADrEItF7FDoSQAAAIPEBMOLZejHRfz/////i0UQi03ki1AIiwTK iUXkOUUUdZCLReQ5RRR0BeiaBQAAi0Xki03gX15biQGLRfCL5WSjAAAAAF3DzMyLRCQEiwiBOWNz beB1BejtBAAAM8DDzMzMzMzMzMzMzItEJBxTVoXAV1V0Got8JBhQi0QkLIt0JBhQV1bovwEAAIPE EOsIi3QkFIt8JBiLRCQ4VoXAdQNX6wFQ6GDx//+LbCQwi1wkJItMJCCLRQBQU1FX6Lj+//+LTCRE g8QQi0UEaAABAABAUYtUJDCLTCQkiUcIi0IMUFNRV1boHwAAAIPEHIXAdAdXUOih8P//XV9eW8PM zMzMzMzMzMzMzMxkoQAAAABVi+xq/2j4dEAAaAxdQABQi1UYZIklAAAAAIPsIItNDIlV5FNWV41B /Ill6IlF4IswoTiCQACJddSJRdiLNTyCQACLRQiJddyjOIJAAIt1EIk1PIJAADP2x0X8AQAAAItF IFCLRRxQUotFFFBR6Cjx//+DxBSJReTHRfz/////6DsAAACLReSLTfBfZIkNAAAAAF5bi+Vdw4tF 7FDoaQAAAIPEBMOLZegz9ol15Gr/jUXwUOgQ7///g8QIi8bryItF1ItN4IkBi0XYoziCQACLRdyj PIJAAItFCIE4Y3Nt4HUng3gQA3UhgXgUIAWTGXUYg33kAHQS6DTv//9Qi0UIUOg0AgAAg8QIw4tE JASLAIE4Y3Nt4HUbg3gQA3UVgXgUIAWTGXUMg3gcAHUGuAEAAADDM8DDzMzMzGShAAAAAFWL7Gr/ aBB1QABoDF1AAFCLVRBkiSUAAAAAi0IEg+wIhcBTVleJZegPhLoBAACAeAgAD4SwAQAAi0oIhckP hKUBAACLRQyNdAEMx0X8AAAAAPYCCHRIi10IagGLQxhQ6CYXAACDxAiFwA+EXQEAAGoBVugzFwAA g8QIhcAPhEoBAACLQxiJBot9FIPHCFdQ6OYBAACDxAiJBulDAQAAi30U9gcBdGWLXQhqAYtDGFDo 1hYAAIPECIXAD4QNAQAAagFW6OMWAACDxAiFwA+E+gAAAItHFFCLQxhQVugKFwAAg8QMg38UBA+F 9AAAAIsGhcAPhOoAAACDxwhXUOh5AQAAg8QIiQbp1gAAAIN/GACLXQhqAYtDGFB1RuhrFgAAg8QI hcAPhKIAAABqAVboeBYAAIPECIXAD4SPAAAAi0cUUIPHCFeLQxhQ6CwBAACDxAhQVuiSFgAAg8QM 6YEAAADoJRYAAIPECIXAdGBqAVboNhYAAIPECIXAdFGLRxhQ6EYWAACDxASFwHRB9gcEdB9qAY1H CFCLQxhQ6NsAAACDxAhQi0cYUFbo/e3//+syjUcIUItDGFDovgAAAIPECFCLRxhQVujQ7f//6xXo qQEAAOsOuAEAAADDi2Xo6BkBAADHRfz/////i0XwX2SjAAAAAF5bi+Vdw8zMZKEAAAAAVYvsav9o IHVAAGgMXUAAUItNCGSJJQAAAACD7AiFyVNWV4ll6HQ0i0Eci0AEhcB0KsdF/AAAAABQi0EYUOhI 7f//6xCAfQwBG8BAw4tl6OimAAAAx0X8/////4tF8F9kowAAAABeW4vlXcPMzMzMzMzMzMzMzMzM zMyLVCQIVotMJAiLAgPBi3IEhfZ8C4sMMYtSCAMEEQPGXsPMzMzMzMzMzMzMzMzMzMxVi+yD7ART UYtFDIPADIlF/ItFCFX/dRCLTRCLbfzoRuz////Qi91di00QVYvrgfkAAQAAdQW5AgAAAFHoKOz/ /11ZW8nCDADMzMzMzMzMzGShAAAAAFWL7Gr/aDB1QABoDF1AAFBkiSUAAAAAg+wIU1ZXiWXox0X8 AAAAAKFEgkAAhcB0G8dF/AEAAAD/0OsJuAEAAADDi2Xox0X8AAAAAMdF/P/////oEAAAAItF8F9k owAAAABeW4vlXcPpzhUAAMPMzMzMzMzMzMzMzMzMZKEAAAAAVYvsav9oSHVAAGgMXUAAUGSJJQAA AACD7AhTVleJZejHRfwAAAAAoUyCQACFwHQbx0X8AQAAAP/Q6wm4AQAAAMOLZejHRfwAAAAAx0X8 /////+gQAAAAi0XwX2SjAAAAAF5bi+Vdw+kO////w8zMzMzMzMzMzMzMzMyLRCQEg+wYU1ZXVVDo zwEAAIPEBIvoOy1Ug0AAdQozwF1fXluDxBjDhe11D+hfAgAAM8BdX15bg8QYw8dEJBAAAAAAuHiD QAA5KA+EmwAAAIPAMP9EJBA9aIRAAHLqjUQkFFBV/xWUkkAAg/gBD4VDAQAAv1CCQAAzwLlAAAAA 86uqg3wkFAEPhgYBAACNdCQaOEQkGnQsikYBhMB0JTPJM9KKDorQO9FyEYCJUYJAAARBM8CKRgE7 wXPvg8YCgD4AddS4AQAAAICIUYJAAAhAPf8AAABy8VWJLVSDQADoTQEAAIPEBOmvAAAAv1CCQAAz wLlAAAAA86uqi0wkEI0USY08VQAAAACNDAeNNM2Ig0AAgD4AdDGKTgGEyXQqM9Iz24oWitk72nIW iohwg0AACIpRgkAAQjPbil4BO9pz8IPGAoA+AHXPQIP4BHK6VYktVINAAOjWAAAAo1iDQACLRCQU weAEi5xAgINAAIPEBLpgg0AAjYxAfINAAF1fXosBi0kIiQIzwIlaBFuJSgiDxBjDM8CjVINAALlg g0AAXV+jWINAADPAXluJAYlBBIlBCIPEGMODPWyDQAAAdA/ozAAAADPAXV9eW4PEGMO4/////11f XluDxBjDzMzMzMzHBWyDQAAAAAAAi0QkBIP4/nUQxwVsg0AAAQAAAP8liJJAAIP4/XUQxwVsg0AA AQAAAP8lmJJAAIP4/HUPxwVsg0AAAQAAAKEYhkAAw8zMzItEJAQtpAMAAIP4EncPM8mKiKxPQAD/ JI2YT0AAM8DDuBEEAADDuAQIAADDuBIEAADDuAQEAADDgE9AAIZPQACMT0AAkk9AAH1PQAAABAQE AQQEBAQEBAQEBAQEBAIDzFczwL9QgkAAuUAAAADzq6qjYINAALlgg0AAX6NUg0AAo1iDQACJQQSJ QQjDzMzMzGr96Dn9//+DxATDzMzMzMyDPVSDQAAAU1ZXVXUXi2wkGIt0JBRVVuh0EgAAg8QIXV9e W8OLdCQUgD4AdF+LbCQYugQAAACKTQCL/YTJdDCKBzPbitiEk1GCQAB0GDgGdQiKRwE4RgF0Fo1H AYA4AHQOi/jrBDgGdAZHgD8AddCAPwB1GDPAigaEkFGCQAB0BkaAPgB0BkaAPgB1rbgAAAAAXV+A PgGD0P8jxl5bw8zMgz1Ug0AAAFNWV1V1J4tsJBiLdCQUVVboFBIAAIPECI0MBrgAAAAAXV+AOQGD 0P9eI8Fbw4t0JBSAPgB0X4tsJBi5BAAAAIpdAIv9hNt0MIoHM9KK0ISKUYJAAHQYOAZ1CIpHAThG AXQWjUcBgDgAdA6L+OsEOAZ0BkeAPwB10IA/AHQYM8CKBoSIUYJAAHQGRoA+AHQGRoA+AHWtuAAA AABdX4A+AYPQ/yPGXlvDzMyD7CAzwLkIAAAAU1ZXi3QkNI18JAzzq4oGM9KKyLMBwOkDRorRisiA 4QfS4whcFAyEwHXji1QkMIXSdQaLFTyNQACKCjPAitmA4QfA6wOKwzPbilwEDLgBAAAA0+CF2HQm gDoAdCGKSgFCitkzwMDrA4DhB4rDM9uKXAQMuAEAAADT4IXYddqL8oA6AHQrigoz24rBvwEAAADA 6AOA4QeK2DPA0+eKRBwMhcd1CEKAOgB12+sExgIAQrgAAAAAX4kVPI1AACvWg/oBg9D/I8ZeW4PE IMPMzMzMzMzMzMzMzFWL7FdWU4t1DIt9CI0FAIZAAIN4CAB1O7D/i8AKwHQuigZGiidHOMR08ixB PBoayYDhIALBBEGG4CxBPBoayYDhIALBBEE44HTSGsAc/w++wOs0uP8AAAAz24vACsB0J4oGRoof RzjYdPJQU+hvEAAAi9iDxAToZRAAAIPEBDjDdNobwIPY/1teX8nDzMzMzGoAaAAQAABqAf8VcJJA AKNgj0AAw8zMzMzMzMzMzMzMoUCNQACFwHQUi0wkBFH/0IPEBIXAdAa4AQAAAMMzwMOhXI9AAIXA dAL/0GgYgEAAaBCAQADoBgEAAIPECGgMgEAAaACAQADo9AAAAIPECMOLRCQEagBqAFDoMgAAAIPE DMPMzMzMzMzMzMzMzMzMzItEJARqAGoBUOgSAAAAg8QMw8zMzMzMzMzMzMzMzMzMgz3AhEAAAVNW i3QkDFd1Dlb/FWSSQABQ/xVgkkAAxwW8hEAAAQAAAIN8JBQAi1wkGIgduIRAAHU/gz1Yj0AAAHQk iz1Uj0AAg+8EOT1Yj0AAdxOLB4XAdAL/0IPvBDk9WI9AAHbtaCCAQABoHIBAAOg7AAAAg8QIaCiA QABoJIBAAOgpAAAAg8QIhdt1EccFwIRAAAEAAABW/xV4kkAAX15bw8zMzMzMzMzMzMzMzMxWV4t8 JBCLdCQMO/52D4sGhcB0Av/Qg8YEO/538V9ew4tEJARWV1DoVAEAAIPEBIXAD4Q6AQAAi1AIhdIP hC8BAACD+gV1D8dACAAAAAC4AQAAAF9ew4P6AXUIuP////9fXsOLNVCFQACLTCQQiQ1QhUAAg3gE CA+F1gAAAIsNRIVAAAMNQIVAADsNQIVAAH4iiw1AhUAAjQxJjTyN0IRAAIsNRIVAAMcHAAAAAIPH DEl19Is9TIVAAIsAPY4AAMB1DMcFTIVAAIMAAADrcD2QAADAdQzHBUyFQACBAAAA6109kQAAwHUM xwVMhUAAhAAAAOtKPZMAAMB1DMcFTIVAAIUAAADrNz2NAADAdQzHBUyFQACCAAAA6yQ9jwAAwHUM xwVMhUAAhgAAAOsRPZIAAMB1CscFTIVAAIoAAAChTIVAAFBqCP/Sg8QIiT1MhUAA6xDHQAgAAAAA i0AEUP/Sg8QEuP////9fiTVQhUAAXsOLTCQQUf8VbJJAAF9ew8y6yIRAAItMJAQ5CnQWg8IMoUiF QACNBECNBIXIhEAAO8J35osCK8GD+AEbwCPCw8yLRCQEagRqAFDoEgAAAIPEDMPMzMzMzMzMzMzM zMzMzDPSM8mKVCQEiopRgkAAhUwkDHUgi0QkCLkAAAAAhcB0DDPJZosMVSqGQAAjyIXJdQMzwMO4 AQAAAMPMzMzMzMyD7ASLFSCCQABTVlcz9lWAOgB0GoA6PXQBRov6uf////8rwPKu99ED0YA6AHXm jQS1BAAAAFDotej//6OghEAAg8QEi9iF23UKagnosOr//4PEBIstIIJAAIvFgH0AAHRei/25//// /yvA8q730YlMJBCAfQA9dD1R6HLo//+DxASJA4XAdQpqCehy6v//g8QEi/25/////yvA8q730Sv5 i8HB6QKL94s7g8ME86WLyIPhA/OkA2wkEIB9AAB1oqEggkAAUOhm6v//g8QExwMAAAAAXV9eW4PE BMPMzMzMzIPsCFZXaAQBAAC+SI1AAFZqAP8V/JFAAKFkj0AAiTWwhEAAgDgAdAaLNWSPQACNRCQM jUwkCFBRagBqAFboXgAAAItEJByDxBTB4AIDRCQMUOi65///g8QEi/iF/3UKagjouun//4PEBI1E JAyNTCQIi1QkCFBRjQSXUFdW6B4AAACLRCQcg8QUSIk9mIRAAF+jlIRAAF6DxAjDzMzMzMyLTCQU U4tUJBRWi3QkDFeLRCQYVYN8JBgAxwEAAAAAxwIBAAAAdAuLVCQYg0QkGASJAoA+InRG/wGFwHQF ihaIEECKFkYz24ra9oNRgkAABHQM/wGFwHQFih6IGEBGgPogdAmE0nQJgPoJdcuE0nUDTutQhcB0 TMZA/wDrRkaAPiJ0MIoehNt0KjPSitP2glGCQAAEdAz/AYXAdAaKFkaIEED/AYXAdAWKFogQQEaA PiJ10P8BhcB0BMYAAECAPiJ1AUYz/4A+AA+E6AAAAIoWgPogdAWA+gl1A0br8YA+AA+E0AAAAIN8 JBgAdAuLVCQYg0QkGASJAotUJCD/ArsBAAAAM+2APlx1B0ZFgD5cdPmAPiJ1JPfFAQAAAHUZhf90 DI1WAYA6InUEi/LrAjPbg/8BG//338HtAYvVTYXSdBGFwHQExgBcQIvV/wFNhdJ174oWhNJ0T4X/ dQqA+iB0RoD6CXRBhdt0N4XAdCEz24ra9oNRgkAABHQGiBBGQP8BihZARohQ//8B6W////8z24ra 9oNRgkAABHQDRv8B/wFG6Vf///+FwHQExgAAQP8B6Q////+DfCQYAHQKi1QkGMcCAAAAAItUJCBd X15b/wLDzMzMzMzMzMzMzMzMzMyD7ASDPViFQAAAU1ZXizUwkkAAVXU2/9aL+IX/dAzHBViFQAAB AAAA6yb/FTiSQACL2IXbdAzHBViFQAACAAAA6xIzwF1fXluDxATDi3wkEItcJBCDPViFQAABD4Wi AAAAhf91Ev/Wi/iF/3UKM8BdX15bg8QEw2aDPwCL93QSg8YCZoM+AHX3g8YCZoM+AHXuK/dqAMH+ AWoARmoAagBWV2oAagD/FQCSQACL6IXtdEFV6Nnk//+DxASL2IXbdDJqAGoAVVNWV2oAagD/FQCS QACFwHULU+j05v//g8QEM9tX/xU0kkAAi8NdX15bg8QEw1f/FTSSQAAzwF1fXluDxATDgz1YhUAA AnV7hdt1Fv8VOJJAAIvYhdt1CjPAXV9eW4PEBMOL64A7AHQORYB9AAB1+UWAfQAAdfIr60VV6Ezk //+JRCQUg8QEhcB1EVP/FWiSQAAzwF1fXluDxATDi3wkEIvzi83B6QLzpYvNU4PhA/Ok/xVokkAA i0QkEF1fXluDxATDM8BdX15bg8QEw8zMzMzMzMzMzMzMzMzMzIPsRFNWV1VoAAEAAOjf4///g8QE i/CF9nUKahvo3+X//4PEBI2GAAEAAIk1UI5AAMcFUI9AACAAAAA7xnYlM8m6CgAAAIhOBIPGCMdG +P////+IVv2hUI5AAAUAAQAAO8Z34o1EJBBQ/xUYkkAAZoN8JEIAD4TOAAAAg3wkRAAPhMMAAACL RCREizCNeASB/gAIAACNHDd8Bb4ACAAAOzVQj0AAfl29VI5AAGgAAQAA6Dvj//+DxASFwHRBjYgA AQAAiUUAgwVQj0AAIDvIdiAzyYhIBIPACMdA+P/////GQP0Ki1UAgcIAAQAAO9B34oPFBDs1UI9A AH+w6waLNVCPQAAz7YX2fj+LA4P4/3Qv9gcBdCpQ/xUokkAAhcB0H4vFi82D4OeD4R/B+AOLkFCO QACLA40MyokBiheIUQRFR4PDBDvufMEz/4s1JJJAAI0c/QAAAAADHVCOQACDO/91U7j2////hf/G QwSBdA6NR/+D+AG49f///4PQ/1D/1oP4/4vodChV/xUokkAAhcB0HSX/AAAAiSuD+AJ1BoBLBEDr FYP4A3UQgEsECOsKgEsEQOsEgEsEgEeD/wN8kaFQj0AAUP8VLJJAAF1fXluDxETDzFZDMjBYQzAw VYvsg+wIU1ZXVfyLXQyLRQj3QAQGAAAAD4WCAAAAiUX4i0UQiUX8jUX4iUP8i3MMi3sIg/7/dGGN DHaDfI8EAHRFVlWNaxD/VI8EXV6LXQwLwHQzeDyLewhT6BHa//+DxASNaxBWU+hG2v//g8QIjQx2 agGLRI8I6Mna//+LBI+JQwz/VI8Ii3sIjQx2izSP66G4AAAAAOscuAEAAADrFVWNaxBq/1PoBtr/ /4PECF24AQAAAF1fXluL5V3DVYtMJAiLKYtBHFCLQRhQ6OHZ//+DxAhdwgQAzMzMzMzMzMzMzMzM oSyCQACD+AF0DYXAdS6DPTCCQAABdSVo/AAAAOgfAAAAg8QEofCFQACFwHQC/9Bo/wAAAOgHAAAA g8QEw8zMzIHsqAEAADPJuGiFQABTi5QksAEAAFZXVTkQdAuDwAhBPfCFQABy8TkUzWiFQACNHM0A AAAAD4WnAQAAgz0sgkAAAQ+EXwEAAIM9LIJAAAB1DYM9MIJAAAEPhEkBAACB+vwAAAAPhHgBAACN hCS0AAAAaAQBAABQiy38kUAAagD/1YXAdRa+EHhAAI28JLQAAAC5BQAAAPOlZqWkjawktAAAAI28 JLQAAAC5/////yvA8q730YP5PHYmjbwktAAAALn/////K8BqA/Ku99GNbAx8aAx4QABV6JQFAACD xAy+8HdAAI18JBS5BgAAAPOlZqWL/bn/////K8DyrvfRK/mL0Yv3uf////+NfCQUK8Dyrk+LysHp AvOli8qD4QPzpL/sd0AAuf////8rwPKu99Er+YvRi/e5/////418JBQrwPKuT4vKwekC86WLyoPh A/Oki7tshUAAuf////8rwPKu99Er+Yv3i9GNfCQUuf////8rwPKuT4vKwekC86WLymgQIAEAg+ED aMR3QADzpI1EJBxQ6DcEAACDxAxdX15bgcSoAQAAw6FQjkAAi3AQg/7/dQpq9P8VJJJAAIvwi5Ns hUAAagCNRCQUi/pQuf////8rwPKu99FJUVJW/xV0kkAAXV9eW4HEqAEAAMPMzMzpCwAAAMzMzMzM zMzMzMzMaLBgQADo5gUAAIPEBGhQYEAA/xUgkkAAo0yOQADDzMxWi3QkCIsGgThjc23gdR2DeBAD dReBeBQgBZMZdQ7ovev//7gBAAAAXsIEAIM9TI5AAAB0HaFMjkAAUOhwAAAAg8QEhcB0C1b/FUyO QABewgQAM8BewgQAzMzMzMzMzMyhTI5AAFD/FSCSQADDzMzMi0QkCFa+AQAAAFCLTCQMUf8VXJJA AIXAdAIz9ovGXsOLRCQIVr4BAAAAUItMJAxR/xVYkkAAhcB0AjP2i8Zew4tEJARWvgEAAABQ/xVU kkAAhcB0AjP2i8Zew8zMzMzMVYvsV1aLdQyLfQiLTRA7/nYMi8YDwTv4D4KOAAAA98cDAAAAdVKL 0YPiA8HpAvOl/ySVWGFAAJCQYUAAjGFAAHxhQABoYUAAZosGZokHikYCiEcCi0UIXl/Jw5BmiwZm iQeLRQheX8nDLovAigaIB4tFCF5fycOQg/kMdiOL1/fag+IDK8qLwYvK86SLyIPgA8HpAvOl/ySF WGFAAC6LwPOki0UIXl/Jwy6LwP0D8QP598cDAAAAdV+L0YPiA4PuBIPvBMHpAvOl/ySV8GFAAC5i QAAoYkAAGGJAAABiQABmi0YCZolHAopGAYhHAfyLRQheX8nDi8Bmi0YCZolHAvyLRQheX8nDikYD iEcD/ItFCF5fycOLwE5Pg/kMdiX32oPiAyvKi8GLyvOki8iD4AOD7gOD7wPB6QLzpf8khfBhQACQ 86T8i0UIXl/Jw8zMagroufv//4PEBGoW6P8DAACDxARqA+jF8P//g8QEw8xVi+xWM8BQUFBQUFBQ UItVDC6LwIoCCsB0B0IPqwQk6/OLdQiKBgrAdApGD6MEJHPzjUb/g8QgXsnDzMzMzMzMVYvsVjPA UFBQUFBQUFCLVQwui8CKAgrAdAdCD6sEJOvzi3UIg8n/kEGKBgrAdAdGD6MEJHLyi8GDxCBeycPM zIPsCIM9CIZAAABTi1wkEHUUg/tBfAiD+1p/A4PDIIvDW4PECMOB+wABAAB9MIM9XIhAAAF+DWoB U+hiBwAAg8QI6w+LDSCGQAAzwGaLBFmD4AGFwHUHi8Nbg8QIw4rPM9KK0aEghkAA9kRQAYB0FLgC AAAAiEwkCMZEJAoAiFwkCesOuAEAAACIXCQIxkQkCQCNTCQEagBqA4sVCIZAAFFQjUQkGFBoAAEA AFLojwQAAIPEHIXAdQeLw1uDxAjDg/gBdQszwIpEJARbg8QIwzPAM8mKRCQFikwkBMHgCFsLwYPE CMPMzMzMzMzMzMzMzFNWVzP2OTUsiEAAdUJoWHhAAP8VTJJAAIvYhdt0bmhMeEAAiz0MkkAAU//X oyyIQACFwHRXaDx4QABT/9doKHhAAKMwiEAAU//XozSIQAChMIhAAIXAdAT/0IvwhfZ0EoM9NIhA AAB0CVb/FTSIQACL8ItEJBiLTCQUi1QkEFBRUlb/FSyIQABfXlvDM8BfXlvDzMzMzMzMzMzMzMzM zMyLTCQMV4XJdHpWU4vZi3QkFPfGAwAAAIt8JBB1B8HpAnVv6yGKBkaIB0dJdCWEwHQp98YDAAAA deuL2cHpAnVRg+MDdA2KBkaIB0eEwHQvS3Xzi0QkEFteX8P3xwMAAAB0EogHR0kPhIoAAAD3xwMA AAB17ovZwekCdWyIB0dLdfpbXotEJAhfw4kXg8cESXSvuv/+/n6LBgPQg/D/M8KLFoPGBKkAAQGB dN6E0nQshPZ0HvfCAAD/AHQM98IAAAD/dcaJF+sYgeL//wAAiRfrDoHi/wAAAIkX6wQz0okXg8cE M8BJdAozwIkHg8cESXX4g+MDdYWLRCQQW15fw8zMoViPQABQ6KUFAACDxASLDVSPQAArDViPQACD wQQ7wXNEoViPQABQ6IQFAACDxASDwBCLDViPQABQUejR2P//g8QIhcB1AzPAw4sNVI9AACsNWI9A AIPh/KNYj0AAA8iJDVSPQACLDVSPQACLRCQEiQGDBVSPQAAEw8zMzMzMzMyLRCQEUOh2////g8QE g/gBG8DDzMzMzMzMzMzMzMzMzGiAAAAA6NbY//+DxASjWI9AAIXAdQpqGOjT2v//g8QEoViPQADH AAAAAAChWI9AAKNUj0AAw8zMzMzMzMzMzMyD7ARTVldVi3wkGI1H/oP4FHcPM8mKiPRnQAD/JI3U Z0AAuP////9dX15bg8QEw71AiEAAizVAiEAA6zZX6E4BAACDxASNaAiLdQDrJb1MiEAAizVMiEAA 6xi9RIhAAIs1RIhAAOsLvUiIQACLNUiIQACD/gF1CjPAXV9eW4PEBMOF9nUKagPoROz//4PEBIP/ CHQKg/8LdAWD/wR1KosdUIVAAIP/CMcFUIVAAAAAAAB1U6FMhUAAxwVMhUAAjAAAAIlEJBDrBItc JBCD/wh1NaFEhUAAAwVAhUAAOQVAhUAAfSmhQIVAAI0UQKFEhUAAjQyV0IRAAMcBAAAAAIPBDEh1 9OsHx0UAAAAAAIP/CHUPoUyFQABQagj/1oPECOsGV//Wg8QEg/8IdAqD/wt0BYP/BHUUiR1QhUAA g/8IdQmLRCQQo0yFQAAzwF1fXluDxATDr2ZAALxmQAC8ZkAAvGZAAM1mQADaZkAA52ZAAKJmQAAA BwEHBwcCBwcDBwcHBAcHBwcHBQbMzMzMzMzMusiEQACLTCQEOUoEdBaDwgyhSIVAAI0EQI0EhciE QAA7wnfli0IEK8GD+AEbwCPCw8zMzMzMzMzMzMzMzMzMzFOhWIhAAFaFwFdVdU9qAIs9SJJAAGoA agFoZHhAAGgAAQAAagD/14XAdAe4AgAAAOswagBqAGoBaGh4QABoAAEAAGoA/xVEkkAAhcB0B7gB AAAA6w0zwF1fXlvDiz1IkkAAi3QkIKNYiEAAhfZ+FYtEJBxWUOi2AQAAg8QIi/ChWIhAAKNYiEAA g/gCdSGLRCQoi0wkJItUJBxQi0QkHFGLTCQcVlJQUf/XXV9eW8OjWIhAAIP4AQ+F0gAAADP/OXwk LHUJoRiGQACJRCQsi0QkHGoAi0wkMGoAVlBqCVH/FeSRQACL6IXtdQczwF1fXlvDjQRtAAAAAFDo 0dX//4PEBIvYhdt1BzPAXV9eW8OLRCQcVYtMJDBTVlBqAVH/FeSRQACFwHRTi0QkGGoAi0wkGGoA VVNQUf8VRJJAAIvwhfZ0N/ZEJBkEdEmLRCQohcAPhLsAAAA7xnwgi0wkGFCLRCQoi1QkGFBVU1FS /xVEkkAAhcAPhZcAAABT6I/X//+DxARX6IbX//+DxAQzwF1fXlvDjQR1AAAAAFDoL9X//4PEBIv4 hf900YtEJBhWi0wkGFdVU1BR/xVEkkAAhcB0uYtEJChqAGoAhcB1IItEJDRqAGoAiy0AkkAAVldo IAIAAFD/1YvwhfZ1JuuNi0wkNFCLRCQwiy0AkkAAUFZXaCACAABR/9WL8IX2D4Rp////U+j41v// g8QEV+jv1v//g8QEi8ZdX15bw8zMzMzMi0wkBFZXi/GLRCQQhcCNUP90DYA+AHQNRov6SoX/dfOA PgB1BCvxi8ZfXsPMzMzMi0wkBIPsCFONQQE9AAEAAHcVixUghkAAM8BmiwRKI0QkFFuDxAjDitUz 24raoSCGQAD2RFgBgHQUuAIAAACIVCQIxkQkCgCITCQJ6w64AQAAAIhMJAjGRCQJAI1MJAZqAGoA UVCNRCQYUGoB6E8AAACDxBiFwHUHM8Bbg8QIw4tEJAYl//8AACNEJBRbg8QIw8zMzMzMzMzMzMzM zMzMzItEJASLDWCPQABQagBR/xVAkkAAw8zMzMzMzMzMzMzMg+wEoWyIQACFwFNWV1V1TI1EJBKL NTySQABQagFoZHhAAGoBagD/1oXAdAe4AgAAAOsvjUQkElBqAWhoeEAAagH/FVCSQACFwHQHuAEA AADrEDPAXV9eW4PEBMOLNTySQACjbIhAAIP4AnUti1QkLIXSdQaLFQiGQACLTCQki0QkIItcJBxR i0wkHFBTUVL/1l1fXluDxATDo2yIQACD+AF1eDPbM/aLfCQoO/t1Bos9GIZAAItEJCBqAItMJCBq AFBRaglX/xXkkUAAi+iF7XQ+VWoC6FYAAACDxAiL8IX2dC2LRCQgVYtMJCBWUFFqAVf/FeSRQACF wHQUi0wkJFFQi0QkIFZQ/xVQkkAAi9hW6NrU//+DxASLw11fXluDxATDzMzMzMzMzMzMzMzMzFZX i3wkEA+vfCQMhf91Bb8BAAAAizWEkkAAoWCPQACD/+B2BDPA6wZXaghQ/9aFwHUdgz10hEAAAHQU V+j/5f//g8QEhcChYI9AAHXSM8BfXsP/JXySQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABZ52VbDrvPEaVvCAA28SUCWOdlWw67zxGlbwgANvElAl3nZVsOu88RpW8IADbxJQIF 4AIAAAAAAMAAAAAAAABGEuACAAAAAADAAAAAAAAARvB1Cb7du88Rl98AqgAfc8FJbnByb2NTZXJ2 ZXIzMgAAUBdAAAAXQAAgF0AAgC1AAPAtQADQEEAAcDdAAHA3QABwN0AAcDdAAHA3QAAAAAAAwBRA APATQAAQFEAAAAAAAJATQAAwE0AAUBNAALAVQACQFUAAcBVAAIAVQACQFkAAcDdAAHA3QABwN0AA EBNAAHA3QABwN0AAcDdAAAAAAABwN0AAcDdAAHA3QAAAAAAAAHBAAAAAAAAAAAAAAAAAAAAAAAAA AAAAyHFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUHJvZ0lEAABWZXJzaW9uSW5kZXBlbmRlbnRQcm9n SUQAAAAAAAAAAENMU0lEAAAATG9jYWxTZXJ2ZXIzMgAAAElucHJvY1NlcnZlcjMyAABUaHJlYWRp bmdNb2RlbAAAQVVUUFJYMzIuRExMAAAAAEFwYXJ0bWVudAAAAAAAAABib3RoAAAAAAAAAAAAAAAA wAAAAAAAAEYBAAAAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAwAAAAAAAAEYF AAAAAAAAAMAAAAAAAABGBgAAAAAAAADAAAAAAAAARgcAAAAAAAAAwAAAAAAAAEYIAAAAAAAAAMAA AAAAAABGCQAAAAAAAADAAAAAAAAARhEAAAAAAAAAwAAAAAAAAEYTAAAAAAAAAMAAAAAAAABGFAAA AAAAAADAAAAAAAAARhUAAAAAAAAAwAAAAAAAAEYXAAAAAAAAAMAAAAAAAABGJgAAAAAAAADAAAAA AAAARicAAAAAAAAAwAAAAAAAAEYGAQAAAAAAAMAAAAAAAABGBwEAAAAAAADAAAAAAAAARggBAAAA AAAAwAAAAAAAAEYfAQAAAAAAAMAAAAAAAABGIAEAAAAAAADAAAAAAAAARiMBAAAAAAAAwAAAAAAA AEYkAQAAAAAAAMAAAAAAAABGDAMAAAAAAADAAAAAAAAARg0DAAAAAAAAwAAAAAAAAEYOAwAAAAAA AMAAAAAAAABGDwMAAAAAAADAAAAAAAAARhADAAAAAAAAwAAAAAAAAEYRAwAAAAAAAMAAAAAAAABG EgMAAAAAAADAAAAAAAAARhMDAAAAAAAAwAAAAAAAAEYVAwAAAAAAAMAAAAAAAABGFgMAAAAAAADA AAAAAAAARhsAAAAAAAAAwAAAAAAAAEYcAAAAAAAAAMAAAAAAAABGFQMAAAAAAADAAAAAAAAARhkD AAAAAAAAwAAAAAAAAEYWAwAAAAAAAMAAAAAAAABGAA0CAAAAAADAAAAAAAAARgMNAgAAAAAAwAAA AAAAAEYFBAIAAAAAAMAAAAAAAABGBgQCAAAAAADAAAAAAAAARgAEAgAAAAAAwAAAAAAAAEYEBAIA AAAAAMAAAAAAAABGAwQCAAAAAADAAAAAAAAARgEEAgAAAAAAwAAAAAAAAEYCBAIAAAAAAMAAAAAA AABGILHyHH1UGxCOZQgAKyvRGUAz8CJ9VBsQjmUIACsr0RlgPQvfj1QbEI5lCAArK9EZ/////+VA QAAAQUAAAAAAAP/////eRkAA60ZAAAAAAAD/////AAAAALVIQAAAAAAAjkhAAJtIQAD/////CUtA AA9LQAAAAAAA/////3pLQACCS0AAAAAAAP////8AAAAAnUxAAAAAAABxTEAAd0xAAP////8AAAAA HU1AAAAAAADxTEAA90xAAHJ1bnRpbWUgZXJyb3IgAAANCgAAVExPU1MgZXJyb3INCgAAAFNJTkcg ZXJyb3INCgAAAABET01BSU4gZXJyb3INCgAAUjYwMjcNCi0gbm90IGVub3VnaCBzcGFjZSBmb3Ig bG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBz dGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQotIHB1cmUgdmlydHVhbCBmdW5jdGlvbiBj YWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNwYWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJs ZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBvcGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgN Ci0gdW5leHBlY3RlZCBoZWFwIGVycm9yDQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRo cmVhZCBsb2NrIGVycm9yDQoAAAAAUjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFk IGRhdGENCgANCmFibm9ybWFsIHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3Qg ZW5vdWdoIHNwYWNlIGZvciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2Ug Zm9yIGFyZ3VtZW50cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAA AE1pY3Jvc29mdCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJv ciEKClByb2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AABHZXRMYXN0QWN0aXZl UG9wdXAAAEdldEFjdGl2ZVdpbmRvdwBNZXNzYWdlQm94QQB1c2VyMzIuZGxsAAAAAAAAAAAAAAAA AAAgBZMZAQAAAJB4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////+hEEAAIAWTGQYAAAC4eEAAAAAA AAAAAAAAAAAAAAAAAAAAAAD/////whFAAAAAAACEEUAA//////kSQAACAAAAPBJAAAIAAABHEkAA /////+QSQAAgBZMZAQAAAAh5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////+0FEAAIAWTGQEAAAAw eUAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////NxZAACAFkxkBAAAAWHlAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/////4EWQAAgBZMZAQAAAIB5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////pFkAAIAWT GQIAAACoeUAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////BlAAP/////5G0AAIAWTGQMAAADYeUAA AAAAAAAAAAAAAAAAAAAAAAAAAAD/////Ux1AAAAAAABBHUAAAQAAADkdQAAgBZMZAwAAABB6QAAA AAAAAAAAAAAAAAAAAAAAAAAAAP////9LIkAA/////7UmQAD/////gipAACAFkxkBAAAASHpAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/////3YtQAAgBZMZAQAAAHB6QAAAAAAAAAAAAAAAAAAAAAAAAAAA AP////8nMEAAIAWTGQEAAACYekAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////0zBAACAFkxkBAAAA wHpAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////8MxQAAgBZMZAQAAAOh6QAAAAAAAAAAAAAAAAAAA AAAAAAAAAP////9zNEAAIAWTGQEAAAAQe0AAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////aDZAACAF kxkBAAAAOHtAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////1o3QAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIGBAAAAQQAAAAAAAAAAAAEBmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABNaWNyb3Nv ZnQuSmF2YUNPTVN1cnJvZ2F0ZS4xAAAAAAAAAAAAAAAAIHBAACAQQAAwgEAAMIBAAAEAAAACAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENvSW5pdGlhbGl6ZUV4AABP TEUzMi5ETEwAAABKYXZhQ2xhc3MAAABCb3RoAAAAAFRocmVhZGluZ01vZGVsAABNU0pBVkEuRExM AABMb2NhbFNlcnZlcjMyAAAAUHJvZ0lEAABBcHBJRAAAAENMU0lEAAAASmF2YSBDbGFzczogJXMA ACAvc3Vycm9nYXRlACAvcwAgL2Nsc2lkOgAAAABGcmVlAAAAAENMU0lEXCVzXElucHJvY1NlcnZl cjMyAFxJbnByb2NTZXJ2ZXIzMgBKAGEAdgBhACAAQwBsAGEAcwBzAGUAcwAAAAAAYwAAAGNvbnNv bGUAcwAAAHNpbmdsZQAAc3VyAHN1cnJvZ2F0ZQAAAGRlZmFwcGlkAAAAAGNsc2lkAAAAcHJvZ2lk AABjbGFzcwAAAHJlZ2lzdGVyAAAAAFJlZ1NlcnZlcgAAAHVucmVnaXN0ZXIAAFVucmVnU2VydmVy AD8AAAAvOiAALnRsYgAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAAAAABQU0AAAAAAAAIAAABQYEAA AAAAAAAAAAAAAAAAAAAAADBMQAAwTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA Qf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAAQH6h/gAAAABR BQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAAAAAAAAAAAAAAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAADACwAAAAAAAAAdAADABAAAAAAAAACWAADA BAAAAAAAAACNAADACAAAAAAAAACOAADACAAAAAAAAACPAADACAAAAAAAAACQAADACAAAAAAAAACR AADACAAAAAAAAACSAADACAAAAAAAAACTAADACAAAAAAAAAADAAAABwAAAAoAAACMAAAAAAAAAAAA AAAAAAAAAAAAAP////8ACgAAAgAAAJx3QAAIAAAAcHdAAAkAAABEd0AACgAAACB3QAAQAAAA9HZA ABEAAADEdkAAEgAAAKB2QAATAAAAdHZAABgAAAA8dkAAGQAAABR2QAAaAAAA3HVAABsAAACkdUAA eAAAAJR1QAB5AAAAhHVAAHoAAAB0dUAA/AAAAHB1QAD/AAAAYHVAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqGQAAqhkAAAAAgACAAIAAgACAAIAAgACAA IAAoACgAKAAoACgAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASAAQABAAEAAQ ABAAEAAQABAAEAAQABAAEAAQABAAEACEAIQAhACEAIQAhACEAIQAhACEABAAEAAQABAAEAAQABAA gQCBAIEAgQCBAIEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABABAAEAAQ ABAAEAAQAIIAggCCAIIAggCCAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIA AgAQABAAEAAQACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAC4AAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoJAA AP//////////ApQAAOCRAABskQAA//////////98lAAArJIAAHiQAAD//////////x6VAAC4kQAA jJEAAP//////////5pUAAMySAABgkQAA///////////wlQAAoJIAAAC6QAAAAAAAAAAAAAAAAAAA AAAAmpQAAKyUAACIlAAAzpQAANyUAAC6lAAA/pQAAA6VAADslAAAAAAAAMSTAACGkwAAtJMAAKiT AAD2kwAAnJMAAE6TAABwkwAAWpMAABCTAAA6kwAAKJMAANqTAAD4kgAAJJYAADaWAACGlwAAapcA AFyXAABKlwAAMJcAABaXAAD+lgAAEJgAAASYAAD0lwAA5JcAANSXAAAimAAAxJcAALSXAACklwAA oJYAALSWAADklgAAyJYAAISWAAB6lwAAkpYAAP6VAAAKlgAAGJYAAHiWAABIlgAAVpYAAGKWAABu lgAAAAAAAKMAAIChAACAAAAAABCUAAAmlAAAMpQAAECUAABOlAAAYpQAAHCUAAAAAAAAhpUAANSV AADElQAAlpUAAHSVAABilQAAUJUAAECVAAAslQAArJUAAAAAAACSud13RZXddwvC3Xdqmd13H6Hd dy673XeLmt13857dd5iW3XcAAAAABcnxd8g883dtdvJ3+CPxd3ck8XeGI/F3jiXxdwA68XffQ/N3 YFHwd7s68XcePPF33rvxd3RR8HcTl/F3zJnxdyLK8Xe5HPB39M/wd8ja8Hf+mfF32Jnxdw6a8XdS vPJ3vi/4d7cQ83essPJ3KDTxd7fC8nfjqfF3Lqnxd3io8Xf7lfF3kqPxd+CZ8XcGy/F3qijxdxrT 8HdplfF3/Ir4d2Ai+HeuRfZ3aTvzd5w88XeWS/Z3bzvzd2M783cAAAAAm2M1ZaozNWUAAAAA+1/o d9ig53dpm+h38Kjnd/Ue53cTJ+d3gdvndwAAAADcKLd3CIS0d1AxsndcPrR3+02zd4eCtHdgL7R3 gXW1d3iwsnd8V7R3AAAAAGUBSW50ZXJsb2NrZWREZWNyZW1lbnQAAGcBSW50ZXJsb2NrZWRJbmNy ZW1lbnQAAAMBR2V0UHJvY0FkZHJlc3MAAOsAR2V0TW9kdWxlSGFuZGxlQQAAdQJsc3RybGVuQQAA QgJXaWRlQ2hhclRvTXVsdGlCeXRlAOkAR2V0TW9kdWxlRmlsZU5hbWVBAACTAU11bHRpQnl0ZVRv V2lkZUNoYXIAbAJsc3RyY21waUEAbwJsc3RyY3B5QQAABABBbGxvY0NvbnNvbGUAAMcAR2V0Q3Vy cmVudFRocmVhZElkAABkAUluaXRpYWxpemVDcml0aWNhbFNlY3Rpb24AcgJsc3RyY3B5bkEAS0VS TkVMMzIuZGxsAACmAVBvc3RUaHJlYWRNZXNzYWdlQQAASQJ3c3ByaW50ZkEAiAFNZXNzYWdlQm94 QQB3AUxvYWRTdHJpbmdBAIwARGlzcGF0Y2hNZXNzYWdlQQAADQFHZXRNZXNzYWdlQQAeAENoYXJO ZXh0QQBVU0VSMzIuZGxsAADsAFJlZ1NldFZhbHVlRXhBAADgAFJlZ1F1ZXJ5VmFsdWVBAADCAFJl Z0Nsb3NlS2V5AOEAUmVnUXVlcnlWYWx1ZUV4QQAA2ABSZWdPcGVuS2V5QQDOAFJlZ0VudW1LZXlF eEEAxgBSZWdDcmVhdGVLZXlFeEEA2QBSZWdPcGVuS2V5RXhBAMkAUmVnRGVsZXRlS2V5QQBBRFZB UEkzMi5kbGwAAAYAQ29DcmVhdGVJbnN0YW5jZQAAGQBDb0luaXRpYWxpemUAAC4AQ29VbmluaXRp YWxpemUAAAIAQ0xTSURGcm9tU3RyaW5nAJcAU3RyaW5nRnJvbUdVSUQyAAUAQ29DcmVhdGVHdWlk AAAnAENvUmV2b2tlQ2xhc3NPYmplY3QAIwBDb1JlZ2lzdGVyQ2xhc3NPYmplY3QAKwBDb1Rhc2tN ZW1GcmVlAJYAU3RyaW5nRnJvbUNMU0lEAG9sZTMyLmRsbABPTEVBVVQzMi5kbGwAAMcBUnRsVW53 aW5kAFwBSGVhcFJlQWxsb2MAUwFIZWFwQWxsb2MAFAFHZXRTdGFydHVwSW5mb0EAnwBHZXRDb21t YW5kTGluZUEANwFHZXRWZXJzaW9uAABZAUhlYXBGcmVlAACYAEdldENQSW5mbwCSAEdldEFDUAAA 9gBHZXRPRU1DUAAAVQFIZWFwQ3JlYXRlAABiAEV4aXRQcm9jZXNzAB0CVGVybWluYXRlUHJvY2Vz cwAAxABHZXRDdXJyZW50UHJvY2VzcwAmAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAiwBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQDQAEdldEVudmlyb25tZW50U3RyaW5ncwCMAEZyZWVFbnZpcm9u bWVudFN0cmluZ3NXANIAR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAA+gFTZXRIYW5kbGVDb3VudAAA 3ABHZXRGaWxlVHlwZQAWAUdldFN0ZEhhbmRsZQAATwJXcml0ZUZpbGUAEQJTZXRVbmhhbmRsZWRF eGNlcHRpb25GaWx0ZXIAbAFJc0JhZFJlYWRQdHIAAG8BSXNCYWRXcml0ZVB0cgBpAUlzQmFkQ29k ZVB0cgAAeAFMb2FkTGlicmFyeUEAAHUBTENNYXBTdHJpbmdBAAB2AUxDTWFwU3RyaW5nVwAAXQFI ZWFwU2l6ZQAAFwFHZXRTdHJpbmdUeXBlQQAAGgFHZXRTdHJpbmdUeXBlVwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrPwx AAAAAAAAAgAGAAAAIAAAgBAAAAA4AACAAAAAAAGs/DEAAAAAAAABAAEAAABQAACAAAAAAAGs/DEA AAAAAAABAAEAAABoAACAAAAAAAGs/DEAAAAAAAABAAkEAACAAAAAAAAAAAGs/DEAAAAAAAABAAkE AACQAAAAfKMAAAQIAAAAAAAAAAAAAKCgAADcAgAAAAAAAAAAAADcAjQAAABWAFMAXwBWAEUAUgBT AEkATwBOAF8ASQBOAEYATwAAAAAAvQTv/gAAAQAAAAEAAQAAAAAAAQABAAAAPwAAAAAAAAAEAAAA AgAAAAAAAAAAAAAAAAAAADoCAAABAFMAdAByAGkAbgBnAEYAaQBsAGUASQBuAGYAbwAAABYCAAAB ADAANAAwADkAMAA0AGIAMAAAAEwAFgABAEMAbwBtAHAAYQBuAHkATgBhAG0AZQAAAAAATQBpAGMA cgBvAHMAbwBmAHQAIABDAG8AcgBwAG8AcgBhAHQAaQBvAG4AAABGAA8AAQBGAGkAbABlAEQAZQBz AGMAcgBpAHAAdABpAG8AbgAAAAAASgBhAHYAYQBSAGUAZwAgAE0AbwBkAHUAbABlAAAAAAA2AAsA AQBGAGkAbABlAFYAZQByAHMAaQBvAG4AAAAAADEALAAgADAALAAgADAALAAgADEAAAAAADAACAAB AEkAbgB0AGUAcgBuAGEAbABOAGEAbQBlAAAASgBBAFYAQQBTAFUAUgAAAEYAEQABAEwAZQBnAGEA bABDAG8AcAB5AHIAaQBnAGgAdAAAAEMAbwBwAHkAcgBpAGcAaAB0ACAAqQAgADEAOQA5ADUAAAAA AEAADAABAE8AcgBpAGcAaQBuAGEAbABGAGkAbABlAG4AYQBtAGUAAABKAGEAdgBhAFIAZQBnAC4A RABMAEwAAAA+AA8AAQBQAHIAbwBkAHUAYwB0AE4AYQBtAGUAAAAAAEoAYQB2AGEAUgBlAGcAIABN AG8AZAB1AGwAZQAAAAAAOgALAAEAUAByAG8AZAB1AGMAdABWAGUAcgBzAGkAbwBuAAAAMQAsACAA MAAsACAAMAAsACAAMQAAAAAARAAAAAEAVgBhAHIARgBpAGwAZQBJAG4AZgBvAAAAAAAkAAQAAABU AHIAYQBuAHMAbABhAHQAaQBvAG4AAAAAAAkEsAQAAB8ASgBhAHYAYQAvAEMATwBNACAATABvAGMA YQBsACAAUwBlAHIAdgBlAHIAIABTAHUAcgByAG8AZwBhAHQAZQA2AFMAdQBjAGMAZQBzAHMAZgB1 AGwAbAB5ACAAcgBlAGcAaQBzAHQAZQByAGUAZAAgAEoAYQB2AGEAIABjAGwAYQBzAHMAIAAiACUA cwAiACAAYQBzACAAQwBMAFMASQBEACAAIgAlAHMALgAiADgAUwB1AGMAYwBlAHMAcwBmAHUAbABs AHkAIAB1AG4AcgBlAGcAaQBzAHQAZQByAGUAZAAgAEoAYQB2AGEAIABjAGwAYQBzAHMAIAAiACUA cwAiACAAYQBzACAAQwBMAFMASQBEACAAIgAlAHMALgAiADcAVQBuAGEAYgBsAGUAIAB0AG8AIABm AGkAbgBkACAAcgBlAGcAaQBzAHQAcgB5ACAAZQBuAHQAcgB5ACAAZgBvAHIAIABzAHAAZQBjAGkA ZgBpAGUAZAAgAEoAYQB2AGEAIABjAGwAYQBzAHMALgAlAFMAdQBjAGMAZQBzAHMAZgB1AGwAbAB5 ACAAdQBuAHIAZQBnAGkAcwB0AGUAcgBlAGQAIABDAEwAUwBJAEQAIAAiACUAcwAuACIA7AJUAGgA ZQAgAGMAbwBtAG0AYQBuAGQAIABsAGkAbgBlACAAcwB5AG4AdABhAHgAIABpAHMAOgAKAAoASgBh AHYAYQBSAGUAZwAgAFsALwA/AF0AIABbAC8AcgBlAGcAaQBzAHQAZQByAHwALwB1AG4AcgBlAGcA aQBzAHQAZQByAF0AIABbAC8AYwBsAGEAcwBzADoAPABKAGEAdgBhAEMAbABhAHMAcwA+ACAAWwAv AGMAbABzAGkAZAA6ADwAYwBsAHMAaQBkAD4AXQAgAFsALwBwAHIAbwBnAGkAZAA6ADwAUAByAG8A ZwBJAEQAPgBdACAAWwBvAHAAdABpAG8AbgBzAF0AXQAKAAkALwA/ACAALQAgAEgAZQBsAHAALgAK AAkALwByAGUAZwBpAHMAdABlAHIAIAAtACAAUgBlAGcAaQBzAHQAZQByAHMAIAB0AGgAZQAgAHMA cABlAGMAaQBmAGkAZQBkACAASgBhAHYAYQAgAGMAbABhAHMAcwAuAAoACQAvAHUAbgByAGUAZwBp AHMAdABlAHIAIAAtACAAVQBuAHIAZQBnAGkAcwB0AGUAcgBzACAAdABoAGUAIABzAHAAZQBjAGkA ZgBpAGUAZAAgAEoAYQB2AGEAIABjAGwAYQBzAHMALgAKAAkALwBzAHUAcgByAG8AZwBhAHQAZQAg AC0AIABSAHUAbgBzACAAbwByACAAcgBlAGcAaQBzAHQAZQByAHMAIABhAHMAIABMAG8AYwBhAGwA UwBlAHIAdgBlAHIAIAB3AHIAYQBwAHAAZQByACAAZgBvAHIAIABKAGEAdgBhACAAYwBsAGEAcwBz AC4ACgAJAC8AYwBsAGEAcwBzACAALQAgAFMAcABlAGMAaQBmAGUAcwAgAHQAaABlACAASgBhAHYA YQBDAGwAYQBzAHMAIAB0AG8AIAByAGUAZwBpAHMAdABlAHIALwB1AG4AcgBlAGcAaQBzAHQAZQBy AC4ACgAJAC8AYwBsAHMAaQBkACAALQAgAFMAcABlAGMAaQBmAGUAcwAgAHQAaABlACAAQwBMAFMA SQBEACAAdABvACAAdQBzAGUAIABmAG8AcgAgAHQAaABlACAASgBhAHYAYQAgAGMAbABhAHMAcwAg ACgAbwBwAHQAaQBvAG4AYQBsACkALgAKAAkALwBwAHIAbwBnAGkAZAAgAC0AIABTAHAAZQBjAGkA ZgBlAHMAIAB0AGgAZQAgAFAAcgBvAGcASQBEACAAdABvACAAdQBzAGUAIABmAG8AcgAgAHQAaABl ACAASgBhAHYAYQAgAGMAbABhAHMAcwAgACgAbwBwAHQAaQBvAG4AYQBsACkALgAKAAkALwBkAGUA ZgBhAHAAcABpAGQAIAAtACAASQBuAGQAaQBjAGEAdABlAHMAIAB0AGgAYQB0ACAAdABoAGUAIABD AEwAUwBJAEQAIABzAGgAbwB1AGwAZAAgAGIAZQAgAHUAcwBlAGQAIABhAHMAIAB0AGgAZQAgAEEA cABwAEkARAAgACgAbwBwAHQAaQBvAG4AYQBsACkALgAKAAkALwBzAGkAbgBnAGwAZQAgAC0AIABG AG8AcgBjAGUAcwAgAHQAaABlACAAcwBhAG0AZQAgAG8AYgBqAGUAYwB0ACAAaQBuAHMAdABhAG4A YwBlACAAdABvACAAYgBlACAAcgBlAHQAdQByAG4AZQBkACAAKABvAHAAdABpAG8AbgBhAGwAKQAu AAoACQAvAGMAbwBuAHMAbwBsAGUAIAAtACAAQwByAGUAYQB0AGUAcwAgAGEAIABjAG8AbgBzAG8A bABlACAAdwBpAG4AZABvAHcAIAB0AG8AIABjAGEAcAB0AHUAcgBlACAAcwB0AGQAbwB1AHQAIAAo AGEAbgBkACAAUwB5AHMAdABlAG0ALgBvAHUAdAApACAAKABmAG8AcgAgAGQAZQBiAHUAZwBnAGkA bgBnACkALgAKAB0ASgBhAHYAYQAvAEMATwBNACAAUgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4AIABV AHQAaQBsAGkAdAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA8AQAALDBdMGgw mDDcMPYwAjEQMVAxVjFjMWwxcjHyMfwxBTIPMhkyIjIoMoEyjjKUMp8yqjLLMtky8DI6M2YzozO+ M8gz0DPWM/ozHDQ+NFU0YjRvNHo0qzTCNNI03DTmNBY1MTU7NUM1STW8NcI12TXiNe01+DUuNkw2 eDacNuA2Cjc2N183dDd6N383hjepN9w3ATgIOG84dzisOLQ49Dj7OC85RjlTOYI5tjnPOeM59TkF OhM6QzpNOlQ6YzpqOoA6izqfOqs6vTrCOsw61DrZOuM67zoNO0E7Wjt1O347hDuNO5M7mTueO6k7 8DssPEg8jTyUPPM8Sj1sPZo9nz2lPa09tj3BPc490z3YPeQ9IT4/PlU+az6BPpc+rT7DPtk++j4M Px4/MD9CP1Q/ej+JP9o/AAAAIAAAIAEAAAgwDTAUMOYw6zAHMSgxLzFLMXQxezGEMZwxwTETMhsy MzI5MlkycDJ/MqsyuzLGMvwyFzM6M0kzVzOHM5EzuDPKM9oz7zMDNAw0PDRGNGo0czSjNK00tDTD NN806DTuNP00AjUMNYg1kzXDNQA2RzZlNmw2lDbJNtQ24TYONyQ3ZzeVN7Y35DfpN/A3ODhaOGo4 czh5OKw4yzjbOPU4AjlIOWI5dDl7OZE5szm8Oew59jkHOh46JDo8Omo6eTqhOq46tzoGOx87Zjtt O3c7gTtJPFw8rTzsPCA9RT1tPaE9rj24PcI99j3+PQk+FD4fPjw+aT5/PpE+1D4FPzg/Tz9cP24/ gj+QP6A/sD/IP80/2T/eP+M/9T8AMAAAyAAAAB4wPDB/MJIwoDDKMOwwLDFuMXsxlzG6MTwyYjJu Mq0yzjL7Mg8zFjNNM24zpzPmMx00KTRqNJA0vDTQNOw0MjWWNcw1JTY6Nl82fDbuNkQ3UTeIN8k3 MjhMOFU4BTmvOUM6fjq5Ouc7KDxSPMI86TzyPA09JT1MPV09aj2CPbQ91T3ePec98D35PQI+JD5F Pk4+Vz5gPmk+cj7hPuY+AD8TPyE/hj+QP6w/sT/IP80/1D/ZP94/5D/vP/g//T8AAABAAACgAAAA GTAeMCgwMjBUMLQw0zAyMVIxbDFzMYgylTKaMuU0bDZxNvw3ATgoODQ4PzhIOME4yTg8OUE5PDtB Ozw8QTxePLw8wTzePEg9dD2IPZY9pD3cPfo9Cj4cPj4+XD5iPoE+iz6ZPqE+qD7GPss+0j7oPhI/ JT8vPzo/RD9PP1g/cj95P5g/nD+gP6Q/qD/EP9E/1j/cP+E/AAAAUAAA/AAAAAIwRzB6MKIw9zAq MY4xETI+Mssy0DLhMgEzDDMRMx4zIzNyM4MzijOQM6MzqzO0M70z0DPXM9wz6TPuMwA0CzSFNI80 nzSlNKs0szS9NMM01TTkNPc0CjUdNTA1QzVWNV81bTWLNZg1oTWxNbs1+jUXNjU2bDaFNvA2Gzck Nyk3Lzc6N5w3ojf7Nz84JDlFOZU5nzmwObw5yDnmOTc6Xjp0OoU6lTqiOuI6BztcO2I7hjuaO9A7 1zv3OyU8LzxIPF88fDyJPLo88Dz3PPE9AD4VPjk+UT5aPm0+ej6DPqk+tj4CPxA/UT+EP7k/2D/o P/A/AAAAYAAAFAEAAA4wMTA+MEQwSTB+MIYwmjCxMLgw0jDyMA0xUzFYMVwxYDFkMbkx7DHwMfQx +DH8MV8yFTM/M1UzdDOrMwc0DjQUNB80JTQtNDY0PjRDNEs0UDRiNGw0hDShNbA1tjXCNdQ16zXx Nfk1ATYHNhM2TjZhNmw2cTaXNp42sDa2Ns421DbbNuE26DbuNiA3KTc0Nzo3UjdYN143ZTdtN3Q3 kze4N8Y31DfYN9w34DfkN+g37DfwNxE4IjgsOFI4YThqOIk4ljiuOLc40DjVOAA5FjkxOXA5ijm/ OQo6KDpJOsQ63jpWO2A7dDuGO447qzuzO8470zvmOwo8ITw4PGQ8ejy2PLs81DznPPQ8AAAAcAAA xAAAAHAwdDB4MHwwgDCEMIgwjDCQMJQwmDCgMKQwqDCwMLQwuDC8MMAwxDDIMMww0DDUMNgw3DDg MOQw6DDwMPQw+DAAMRgx3DTgNOw08DQANQg1DDUUNRg1JDUoNTg1QDVENVA1WDVcNXg4lDigOLw4 xDjMONQ43DjkOPA4DDkYOTQ5QDlcOWg5hDmQOaw5tDnAOdw55DnsOfg5FDocOiQ6MDpMOlg6dDqA Opw6qDrEOtA67Dr4OhQ7IDs8OwAAAIAAAEQAAAAEMAgwFDBYMFwwYDBkMCgyNDJIMkwybDV0NXw1 hDWMNZQ1nDWkNaw1tDW8NcQ1zDXUNdw15DXsNSA2JDYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4u+icAugMAAAA6QoAAAAxFqnY 7ZwCwyPEg8hE6A0AAADByN/pBwAAADEX/DPCw5gbwUjo8////+gsYQAA8cl0AkHyOfncYD6GKuNj Sgpb/XlFRz2fAFsuNt+pe/z3hoQX3FFUEwwlLow30wsfIi0VVGgxBbQ4EUYDz3jIub4d51hVqojJ tH9ZzguQuCc6cmmz/x09OUnhZEpDXjaDOCEUQYlQB/y5Rx7Wn9PszCxKiEuVNZLxVZvIMlsoEu6U UHxWIKenLqQTdlvQsmZQ+pYg8MmYx23Q+ApnGBZuQmLrI+A80rIt/FTY8iGX+vkHtuU1xUCxLh+D 0fHOSh89jjyO7cbuqH2hPirFV15XWoTaf3VoSwLNIAAMBwfGVh8bcYDU6cGQlSxy3j7i7ssX8mSg n91dBKJo2hRm9RA+8UHc8dtBQ/1sMS6FPxelOU9ySjzWeoNU1yJHiRJVXCG8W66KqVkN6za0e8XD n3RnamY4Qti1YkNbVIICyDt0nUEQFQA421ryYxKQ5FUqX/eb+io49T28PiCPMWvmw65+Pe65kuhJ 9V2K4umgjLv2JJVh/meUMIb7HatbQPhS/fvtXnLxYOMdVwBMdrQC5xQiQU81m2AKNflawixbaJ02 xVfeNkYSebx6b99unP9vdjkaz6SfC8UaI3felRAiYQ3HICQGINhuahRYlPiI7Bh2nyta6zbBYnEE RqDdyoEj15Q24nw1PKlCCPhpmOABL7zgqky1pcN1ocbf/Kffwr73Cg5+F6xR0dO22Pw0RdBHhgP8 derHKY14JeTwbcjjTGpkY1HhfxCZXZ5o6+i23iw0mG0v9AcCpUL64To8rx9rX06HO1ybOvFniflx JSOAP5NFbC5TXQhgrmvHQMGUooL/M96WB0X5e7JtF4zkjoOL5KcaqfnJL8qxoZzh3H6fmyEDpt7C PWRUpsU39CWhVhJAG+zqWLnVX+HJkrDvsl1WkAO3CTlOLXmGwimeDpq+QM3dUEJyfsy6/sO0yGQO xk+N6MsOHwFLv8Rl0RnUCEGXQpjVPj782A5lZk7eXHbe6OfcZIcicOPin7937BORbSGeB+tGHHR9 5W/TDw0WibP7Di93TKtX80GRKRO93pH9+GKEkQrQoQLl8WwF0D2QWmH8oloPViiEHFxIT9ws5PSN 4Rac/2wnV6V6GBvojARZKIaKktuyQWKx9Vm6gjFhzxtC/in/pJSohF44L4uPWLQHPDI0bgMtN8nH bDaIOEg8T7xjzOBug8xQdUwEGMmMZFsa34mRlxxL4Qwdy9J0cVHqevw/6viCTs/xB9zw5CCJc+RB 1zMnrCD5W8Zit5AYMRdJtWjCT+d9kPzvO7cgfgLLriKzwSNtdRGh6HeVcwKYkW92dUocqmmEhteC MdL/W/MSEeDeda6K1v4Z/yxk40/bKhUCYsarEMfE/5f13F0R+0Kr9H47lp/MgKU3xC6G9Diym9VK IQFqOUA3PACD6SQjZOWwFgbzCbNsWrfLqEgMLWUUvN1+C8wl5A05pKgBVHtGWJCjZbqvMcm7wLTC nya9uTzRv3WHp20+5kZQ/pps9TXw26263U4ZymEThW+BCmd52xkLgHR24zheFE1/ia0bgpfyXmS4 RvTekvVdUm/4J9uRDf4JqXZuwYY8GALhAjOwQAry8RwIuaw/X39gVw78kSyMQhfBkQUOxg4KBstP REjqTw24BBgl8aEfnztvqZVd8ySa3ZDY3NYV3aWpMWxjyU8v5ratoXkrGcOpzKV3b67DOTLTUaxl MG3JveMZAXvTN0S++PXWkRbhwsEajQyHUy4TSTFIKQL7dcPA53o4A81sVkbGLMtA05t2vukfNZ5C k4vudTBmfL5ICetuamgueoQu7iMhhqVaQfrxHUs1t4HOXO1FGMJT/7R9aFhQgMN0Lo2Cy4qFSWmd 3Q+dxQEM0+KNEtBGi1XJnHrCwzmVXnvZEx+0c5rqK0Ue5KcmAhE0CqIpWbcdeZOEpz052z6zhVaf N39bKrl3fGK8cZU3Qj+x90JkwD1IXWy8Q9MPKktQpQL3Q0PEkc9Vk1d7fSERNBrM15PiTd0n2WRV RrHTy6OO1maW64HcBVhLfJXmHjsUolh2+J7jOERuZbjqU20xcTXrfR5CBg/Wr/CBEDiL11l5ZQFH 03uNuxh+NqKA/QvaVJAGN2qBGaR835UfJp0fk1rSLzlvhqWFXXosFaxClM23ge5xHYKTGD8asaRo L+fNKY8xlduX89qzJPlNkCeDqrYqxjtP7H0t97/cvo+32VHhNFGYqDEVGttNqfhyrAuc6qqAd/JB eAD7qvC467kyE/kJ6gONSy3kw05w3aPhnYdFV/fPmaSXkB2g/wXQCug7TwV+sp3x1T4qRFfgpZeU +RfOoh5BH1oDjv4Ev3ub3xXI46J+9XVdu8Av8fySemgqzCp3Mjl/3K+Sw6ypNtOdD0DRC0apjOXS 6h2L+0jKOGbjw7OTUB7BJ7nGknB0L/WOaJ21hp/tzQw7m99x+TSDbwuUlqdiaclJiPspVfurO4Tn s2LdrLT7Xbcb4g+T7btZEyyQCncVWbO9wfTXLrFSyZ+ues2Uo78YqML6JTEexlMf/RYcmET6V/eE XhVAiffv/yMtjqxbFR4McYj0JiTby1Xmnlfw6OFKH+wkSdU+OITA8Mv4jPPtNAF3HAoJ7zMnZngL 68+9+RkAKayDgpNU3iKAw44MCFWtvYfNKpJNi6FwQjF/8WBR5LQRVN35L5XWlkVxDG6aMe24P9/A bd02oXhl5jkSs0/uRKfxKZdsr0j0C/KZnvI6Fw03eIy9PZ+F8rRLvul8QfWxpfIxyamrTmZEj6R3 bd3NMNkbjtVf00/aDX4sFDoKN3kZ/UvBM7tyJzVHLrOzEjqIXiGl4xOrGU/W+XUfZvyRXh70BXFG 0/416/qM+ODtYf/4GAIfdgPk+h4llDU94LqGLb6g9OVsvXjnUppSvYi7VwFdfobKG8aVjF6noxUb LIuStGb9e1bTBXBiqKKaRSJ1nfCWba8zeJE3aHEW5TyqvCMXYVCq143PrIK+nbfFT2c3yEZAbElC YV+ZF/65OVm1vBRGWFVXJypUgFIyxO7Z5y0iE6xJ3lPCjKYE6Uor/oLRxKcd1G90Z6O/eslJZWAM wkrNA07rRvZk60SN4wEiYHbUUsFs0jDk68tyxIuG7t7wwDfrG8OjGPZugbX4GRPvoNfM7/3rkRyQ cu6pvn7zhgVpBWSYO/qQyg5hpIjJ0noQBndHgiffg5D62FEYNUKuGvUq241TpGiiU6XFIkhTBbUc sC/P5Q5cKlJn4rzFnAbHTxIzMpuKwKSOaPxfARsJOlt/vE6n48CCZ16gQW2ibtQgX4qBdq08CTbD xNzpUzdMvLR51P89a1RDp8hWiiXmWciZ6ic8k5/VteY4iQeK2WOcC1z2h+iDlmn6c+q9lbJu4KVv EKgdh3KOWBt2qYlEGGcIXntvzfgISKsIECXysNRzbdKC0+VsiH6jsYJKWamNcCDWANecbieelcCV QENZGVD4UeBJ8VZ1T8jzn5mXhjKMTb0m0tZa56LOD8oPyARSvdjT72tMu7I+9Nuw8a14wi83hSrn SBO4upnMMv0CrMFE5EkQgoXZUtwMg8n+/WBcDHH/zo9q7/NC86dE/YPo1lgWBc8L355MXcWrTmFC Somk7+TjWKGYlKotnlTRqPzrvOyVIsc9ZmBmghJOxYNw9tavZ1LL6vlrkmjuQn/xo2joAEADNHbH d07dwvOuKejjbc+0DT+zURAaQVPq0vuLcdLzuIhzPUbhJ9U7jfkwb54RZRNi71716f752LflFePC A34QLRO26C8+8rEw81x3pFTzD7JO1mE6+1RIzQmrLzZA2GjR+1bVRFa7jxgSdM9IqT/83I+3irRh Uq/BNYnTvJMS4FZDjNRabvqPRsO+treMCqyeV3Iccy4VGEDPoypmt9njZPSaQGyJeFVVz0ELOoeC O577u9h4EXBl8pGJAvdMg7vhmCvJCejZ6QAh5o0YtByz25gQzv/qfrU5+Hf6bYXr4dVzlaGWxCPR ZUzSGN08qZ6uDQ+oyMK30M93AuIqzdHx6otk4ziIX/mv0kfdatmVGTrXGVYygJltuh3kxIhgBSc6 Y4sSUnZnMANt1SE4kxUlIppz51y6vJ8/ti1KpG5f3kQrQ24qcYGIUAe1rlmEJILeTutNWByn/OPA HXdp0JnFTbJ67d8WjBEtOQiQHxM+qpX0dD/EsuF0aAMBQffOSFX8jV9zeA/GyJPhKd5WsDGcmGfR vzjoXYV1cKT5gFCkSjcfzKiF1rCHXK0F3RrMEvNJKxh24zKFCUcevlAkret9t4thAa8TYWctKGbF pKTcp7dFXb40aySRpz1Y/r+SSpU8MzbPavX0D88M0sQE/E6iUD+gDlqCmYMQjPxUKnri2CVr1j8g +heZMaJ3yrHZZjFc2v+b3dpj5uSQ30hkmVelZuOngUmmSJ9kbeZ8biy7pBPkdLZyxk/D5mW2feU5 q817vBoufr4SSgVMhySDrAoBhoe78+mom1/KeIW46TmLGJDJaJzeVZyufaj2S5gcwGwIn8iFHV+j qeAlusu++CTMNVQYtCSupmk/59JzrbIcsiT3kmxbs3T1Sr04wjzAfkXOzedxLJa2+77CKhvCjGO4 rsvR4MaZFvKfP0vlzBXNIdKbQZkuq3bllGHLlg3WbaAy9batTO2ll10tGXfhsBL/wWObIRmDSM2p eQF/Pc63h4b+8CRxvX8fgcXjNlbH3PsHnszqu06u9p77iLoA5MFva0N5DAYwtFadn98GC+tml22z MBCA7xxrZemSUkCpi1eYktJ/WnJ+5BYl576wPvWcqXtqaOL7bo5owUiiKgSQunXMD9wvTc1wuY1B FjUQO3SyxVsQOpYt7Twx95U/HEgnwl8ZrkRdpxcxpQsB3C5320wKPbryJpOUUXxFfyd06rdXdeOr qh5TzYTjleXRxRKcIYNHmvKpgbzj5LTdwju09ugyO/wu0qdFZYUwXePF+K1yv5IHed4zbq/ZOr6u 78MGnud3ePzWmByGLWq1iHBjOMvbXO2N9t4JTScPKZD5kNjVvxGcDfxKQJvA9OmAGL2qMEaTX8ZO IP8YjAdRqJevdrSXC/KtGAXoXPlj5Qqg92G15lCBtyZpn74NhHe6rNwWe+uF8cKIz8+ks00MTPjB CCLBiKbMtWzCBKGN4NFJExxeR6BMv+qZt9lyB2qukIt0HhwBOeFWfqAsFMqdZZxwMkQSSiLsYuoa vy4cPFq3BI4Mvg0Etm7L6/roNMxrZKrdfopjYUB6JPIhLba0lsel0IMDGV4LhhI9iJGA2BAMlaWD p3fPFZIcPohFYM2eT2HoHVsLBN5hIyRl49X04h9STaMnyM0zOlHGvWwHoqRwtPMIL61ZPCY2WqcR 1V46PBm5avTSoTa2mq7SlRW7LAjieEd04g84jnDTz/huyoYgQXzBB8zxSErFtsf0BDymn6A8baNB dqUgv83qaTQ3jLvQK5lpoxHish8ODfZ5Q2d4Ekj63y/tmr8AgnZyLHqGtpMyWQF1BPVK6vVGyLkZ w5DcojPHRYyI/gxGi1mICQqFxaOQlzPN3VT03Rzw/wzYqC+SzZ3ftBZepWrTUZ1tYbeLi6YHD9Yp BC6Aqn145x7DcP/JiCyK1O9hOboN+dW3zDPaui87GS3C2D1WA0JKwr6xcgaVdISh3+eiW8enwdwp 0S+Kt4loQQwrwsTZMKJHYJROH8v+a9wQdnbDdD7RyGx50nRZ2on69sPseVVFf2127XsgP9vDYR5R lsqHmPn/hCS6abyxV2sKJtmpVt8BCS8crgBjkv2D+gCYCOhtUQgsfplJR/4qzawwTJiyXWCQ4H3G GPAbH5I7M7ZdAYjYTjII+iKHQZeuXZo0KA2/JquW1W4tkym8d9BXw/IxGrW+mjlnYelLf7Nnbmp9 JcXuMx36xdI7YHkC/mAKKUejLMEizEKWtINyxm+sdRI9Q/ZYgxK0wiykmlnukXNcSVKhCfrmsZ5a ZT8kEmZeNCPSiJYNaVQs2wR/OZU+X3YUKGzjNOBmw6kfdnnV9jEKLVz9y6TFTYF+8/cEdkgR0ZGx 9oi8uW+NU30ivjQmKwAVtqadIxplBZvnlMcQeC/NxvRZv6ZEaSXX8YHRWPeiYxiqtOjg6TQFDeN5 JOOSYPCpPT227M7ZMFW+rbf5VOTM9bqib4ytVC+rPVoSDLBuVFEPXUJaEnjKRhlY1BvLciTvFJ9C 1vvyXxN3SVwTCpCZ2WoGxI0jIFTSOsuhor0d5+VOZm+lDR+pa8q0oth6zgaFHWvxP+0HcKEnpfYz mhCPvRg3fW4SfPVDBJ22xwS2ioyoJEZMfJc0jAhkJdHpKYeQvbBQWFzeTRCVABertg2IsVixrjK3 lx2kDx5WqrOaZTkkK0cG5kuj9ZNhrxmGxS1uGdyAUiE0t30KHDUPXtkXZdyk+iIvuLixH5A/hSxR quReCkWRuYNH18USQjGKmUbN0e7foXwTU6RjORoCLVVX6aeUfVPgcLPc2KXYkhLJYfyMwmS4BOui +f2f6YOptyyB8a0nVHnm4YxWRQIK3LPD56MNeVuI+niWsvE+VkprvXHuw4PcOhiWGkHfiGIv3oOm 2Tm1r8igl7sC/wPnzFwX/6CpmPT9x/0TiBxilfA9/TYpHaJ1fio108zWFZ7EtKrJTpOte0W+IN/R rQhf9IO6RaOV3pO4YDQbJlk8VJxN1eLwrcckEpMFEy4jVzqU2z1sOxTMMPfBu35gtkImj0qC5Qlw R6xMm1Ap93HbUl6nuYyfxLbDfBOSy7oNWpjF6+maGD6aFKZuY+3pwvEpPEB3oFTOtmCLLdIzFGZr ZQLL/l1WoJH84EBE9znng/PpRwlloxFO8xVB8Q4YqFD+uO7VMwEY0AFmPljHMq2uXFuvHbKzdlHQ H9aWgW6GJemHgVkZC/+e0nLdLSBo20Fi9ymHYWAzNSVcBKir4vvFuwI7fXHmNVs7zN4jNJZz/DXB vkeVs1tKwDicaAtGqd/WNgGA7WD9MEW6CtYx31MveBs2zAUPhdwYQWthGLH2JCZz3OzhZbSvbyJQ SfiDDpFXEMJCnzoH5GDXWEXhJep7LLvsfLkyn5xXoPWz9sXTO4IfgTkuDIMZmKqwi6N8poQelHqj A5kJkU5hec+UoZPOzWLYGaui+s2jHKsrU9aBIdCO0S6fv20drrdLq+x8sCAPTTfw9ftbtjimf+SI OkXn5pm+OcaWtEQb1aXob5aQwsoic26g9/Q6JHb3WgP57yeNO2JED9eL1C8V2+dE4y5cEkSgWFMB sjSPKk/f6rgVCeEnieQK5HiTZ49TeSdbW3EEY73uSi0KYRCU3CUSHlhDDIQw+UoDPjzqRCFLzZEH AdM85gCleIKDGrheCRiViNlONqlWSnD20f5w8vv2rC8WoVZBpeX7KRsJmAQe82IHQfXry9T4QiUl vH3xfvNdQT/J9WkzxWl68svnuERLXAJxaklJ+/HFUrrUR2K24MA5O1s6nKr1DjlF75uZQY4dsT57 j4DdOW+j33yB2tHpL2yMkO4HkbF+zn5VHbTMq2DRh/0v88zqOr+3B0lnEQfVRZsJCH/VwscIb0F4 oHFTuhTZE3OqfUk87On+U/Jzzw8mIPsblZUHcxu1uBsd2DIP1AIrktnL8XXhViowATpc3Mjl+mI4 ZXbeAIYAVXZrCJCZI5gx76DhbUyjTNHiNR+jQez2MNxU6tmhbjiU4MbtWPo/axGH9SGyf6BkBDld pf1tNK7SFqHukM3HmChGxbNnIbLmS+5aqbOjqd2oE3e/x1XSqavxPOO4j9cNc1nAWzxZTL7zzLnp FO+EP3Bv49eR1S4Si9pZAC7O7aB9FAdodrHxlpjkd65tYkvKRcj5B/At/DLswv51TrdxuEf862dI mQZYgskc55hYyG+np4WCQCpRSjR6mt3kr5TXEeTelmGmW1YE9g+Y/brIuvdXI59NngIi6ZBcrnK+ u3hoy8UE0WgwBMaVoyFXSib2wD9evD6ZBlPzeVsWxhaoAqSzQui0bGEP5MlbqFJMyTgIJx8lhyyk k31h2UHzfnNYcJiCpLtimRJFlVxRfDJf8HJPYtccBuFjMl33fdB2gTE9g2wViy9e0IdWeWm1ypzM GPd2z0I+unJxm/nMftru2JT7aVb7B4SoTqu3d1uqgcR5TmNb5XuOarqyUvWmtJNgTaqW1zFsYOS0 fRKsjgHebAOWoiqYS+PyD7Atny/Fov2sEuu7UReuVA+9xVUUgSMUGxa69hDgUIN26LqmYRUtAIpc x9NbD0m85YzP3HrRh5ztJpLdxQflYjp6DGIzbdLCL+LK6iWnUu5qV0rhiHFRAQBXn/ezHeI6BCgX 2T7XH8KC0HmTYB5fRgEi7IniDnSm/CX0Dli34HuOn0CWxzz8SDN9PZYPbCges6oPoaywlhcBi4xN uKoLalvtCkVUJBHwDwFmIBTOhubwTj2QNpii+m81Hq+aduMBmm5W68uctpjVFEJsDkYq+lVzvUHQ MzD8mB8zV/U/X71sVzlQkN8TYB8oPmMYLtBVtQjBEQgdVryUldjiSI9j8vaHSvXv29/LTbvfztc8 Fb5itVcB1d+p4AhpNqCHiV8JpEGdO7rDAK+DBAAyrP3qOqETaD37UOZ6mNQVFrElEIUFCHclD28d D95IfCp2ZFZvfwOZzmngjIpiQo7dU7GC+lT2CMVK53oDvzXlLIOfnDcJuK8dFw/thbw0C1/SNboa jYRiURgb9Mmaz/AzFrCoHuxErWH9sB1MXABxjC8sGKEr7mKaOGFo4rH/Uk0rY0KzDk01605DF5CA c6//Ubw3vUw+QxiXZ43ICNQNoJxXMLZwwtGRkQa3PIxbca+E+Fc+1i37lZ0+SQjtzuQjVWmTkejR WKKzI+3sVAFfS+RYDkIj9P5W66rX+vodkznbCAOB03Q+tS4ekZSPm/qsHViWGqGao0fJqLz7ri/m +RW8FZb2MCvY73UqGZ3lk4cKkhqi2/x6T2RmiqINLJMzxeCMHihqGzESCsNpt/otn6KWMLov7Fn8 dtXKv2fr+PaIm6tWGhi2ozTFSo+9IkElxlvvYjf3T4X5KcCbZg7nK9pZ/zZWU/h55cVLYEfKZVio U1vqObReh4O5Vbfs/mG55nHvBfZYZjkYn6X3z1pivQpPOLI1RvuAPUh3gjGPHc0HXofxFtq8JY1s 7gRLpYCj/6YUil7vhCn14BkwUDGPl4A6HrYje5Ud7HQDPDVpLO+eHnHTmrubnt/IDihiQKD7g3oL PH0vTb7mXDgs8WurB4GnrkpiSIAdy9BbX1bdtfv6eLhWrAsrCdBcF945UShmM+7CiT4bVTXNs8ro Hi2mKRhiJZgQ/89Z/J7S9LNYf9+l1td6RrFw5cTIKthg6Ptfg4qIjjMeGTYrBid4OxzuOzZ+hpEo shIqRnIxbKAEZMs8DfbqvF5pcQ7bz8+dmG/3IY6rGpJIxy1D3Azz17+JiX1twwbXtM1TW5O6/4p8 En9bZO7DVCrxh0/HG6FfZh6L8ICLfsmc5Lvw07Kr0ycSVFGCF99q4RTabEC6mJoAF6dg7N2c/nnH rD1WDPxmL62T7igNYnhp0gng4inoS6PYh9ffznPNbU3xfwiXLqqnuolEu6o5e0q/6FOBpRtk8s7T nrjvfjI/YrGkD5tjG7ymdDN0aOXXIeqaiZn+QxeT4nvYGN5EYtVgjKQl0uTk/NZHVR64+oeyK83B 5DQoOywsWxhJYhe8tRzarx1mz+GgblTwt2yt7vOWfe/KZicoGzBKFWmeXvZUSox/OTNUaewW5+Ak AqmICnRFAuNRD5bQsNt6q0yJkMd0KFFPRwNNvxDXoDRCff3Dli1uBMMIxmDBS3miNnF14M+ldEMO YI4sFyOZiRPuhNo9Z5YVSyIIiTIdp9giI5Swm3nd8XIQRoqk/9ALd+Gz5QKCzCoTY5zzRREm56lC 4VNxwWxQZ9SBdsWGfpZsWpOwT83/eavCXbGOku/2xWYYePipKtvh7GMm5y+8wINJR8IQfSz+hvhQ +1pSJdxx7Vpj4s5TneEAiCWzJw5uJ46nf7itAbAp9LS5vlMTdqAEuMlgw6voMnKQYmN/Y5CLCmAS /ZVY3vAZ/qGD2YgE1/XQ+/DL0kP6p5M1Ve334pAphldAbCVclgCVU+czFVPwhhSZz9K6QF156Isz dRNjYRicpI8jFLyVTSiVY5ty7f+moeWNbo1eOysyq8dXxTQg8GoklyHTLpdiSTd+pmwRpPY1kheV n+uXfAesHBOTrbDiGuYBBQC5JBB+cTyLd6YIzifoWirjNyauCCRJCaA+XAGE9Rbm50uwEoZYa1Dq hS88iRKyGJglON7F50ig2hkooN/sC629Uy0q0GmSlPXiSPonvkYb+DzK3OcINYhqULmYeL1AbVGb ePBQzWVL1sVyfi6ng+BsFQrHAnBv1hOTx0IihbYnd1oTpFqwsSvWRlzdPTkvI1CMlNzyxpIMM4ld wat2O4aelfxwb/X7swLT6UybjvvSUZ6X7D6h4RG3t/OHh+qKhECCEbQ4a1FboiyGMi4tXsG1Zouo GpyaUhcwISYUuR3Nmvq2nAUIrXv8oysa8U+t3e/dMETgejPvcV/gciMswYmKOzNQrBTCBMV75P0o yrx+Ri4IVCLyoEKs/0qhc3RvjZ45kRBWNpPbUJuUhkvomUEAbdkU/5rex/UH3IrsdOFdkFOcmz/U dsNGoZWRPzhusr0xy55G2n3NvzDwuk2Z3X7aAHoALC1/UA5YdLU909+jHpV39e7lhL+u3YF66q1z KvgwJNseh5Fb75KRi8Xam9TEzaR6sQt0qS1hYak9n8vtLhxazz/eZYw8Ipn2ssWoER61UcMgKcRp DhYjUhSehjXRwL07g80rGxMSZDGDaJJCJ4Qr/jh6kn+kkDcl0eJhlpQDRr+8E9CjTQpoGLmAjQKH 6wDn7uZxJMi+dwzUDG/2j3hAhuHSbmg8FRAlgzBhuKFbBRX9XhD0PDJRzYXJZN1/5w8gAL5RWCaa LJUZTHYOKLJaxjIFNO+GJcQiwMIJBQlupkCQB/EUIEn5NV7J60pcp+F0V3MTNTqEIB7raU8v0HTo ifc1EMNFWop0rpTkA4Ix/XppPv/kPSToIVkCowXdSQP4xaq56PiExZBM4Q1pAXAPkfq3kdD0hs6o 37pYy5zWEanT1MyOdCcQdgPupQaJkcVsZbfbgg22GoLoFVNVcW7P4L2PYks/MPUeXT1FwsZy41Dk EwyU2SHaEtQJclA2YAJgpWvqaJ4g/2bitOx5AMqUYRpnEeRbGTHwF3GHeMhQ+3hv0u17aAgfNadN OQVbQj8T3yGkR7/SHAPN7sN5RiYOwKm4RR63VtWWK93OGCQqqaOLWdnfF+FulhyRIbWaWfdMH8RJ VAO2exFg1slx7+4L8p7uwEh0RbG62iulsFEkt8DNovOCtJldllDMUHHDjs8cIgZFJ2QC2BL1L0/r 7C3dHVcFZJiTp+L1pdR18Q5kRts8froY4KGfam8xaiEQFfLaY5jwft/Dj3ZUfAXsj7u8vMOm8Hst AAJCsCVA/XI9jBCmZz1zZXe1Xh4UD6LXQrvbpwUenEnnnWqONSHlvCTvRJNKXSuJ16RSkLsjEfiY Juxc1U+mUeRTMs0FLt/HZjMHKg9Be7nFzoG9Z4TDq4Cyge1lfkf0qs0Poy8DzcAL8Fjy0UisFoQ5 1nxOjdbw6FIcb29TN2igVaLsug1mGtwK1+ExJStN6fUcNPNidP9f4Wo77Wf0ynVlPn4lbf3MIl9A HomwnRf+NEPQ74GEt235DANeowJJnRmS9eagF++rCe1JN8ebCfKL3to6gSvUHyTvPlS8pMZZHxEy Q2RL+ZNxjbMwnAOXZxU5Kd+gRt4HTJGWpKbVlakC9HUh4zGE6z4Y7ObwysWLGbZiWLZRw2RLfI6O u9eyG6kaVEV9UMYjw6BJhGziP51FkzFdi2naBc+sK/8rYpHmtXIeRnd0F0tVDUGXmvvhEtw+A0RY ocDYSUlAWppH7xBhS+iVWrNLiuDa2s9EmCdfMr5aC/WZTV16abAkuh9Rh/1isvBK9dNaAgD4tgQr JlkNbpdagkKjTuSEiysP32vqEXr3npkIPWtXAIekGENoVhkW8UmOIa+D3vPfp6F7JPAmkbOlC9Q/ 6qatru5uW9ozMJ4rTIbDtR42zBL6OGeaLePDUDXW7AjSQL22T9Iz/OOwtvWoxUweLws8AAlNf+Hy 5e2wXFPtNLlVSP6W03guCVvOvx3oncFtYGdyIo+Wq2ejX/OPKB2WSTV9lz7mWHg6hhl2+88gCFV1 bAjp5z/l3/F3U2c8NSgKh2wTLxIrylM8/1Ngh8jIwALERspkicrIcIO8lRoNMpkmkCsO/dbMl2zp 4cNMEWL6DgyAEixqb5TkIo4BsvW8WEH19fWrU+SSri4AqLFx4UdIOW+Z3LfTUFF/zaO7Iy5/vsC/ UHUjKDrDroYXxokmASOm5FEjJp7uzWFXACN90ynT2ARwzHzDYmBffP/aSUad3eTjjP9AKNYKQmBz 5UZGgHhgAwFu8zlNfebWd0VSyy69pPvmsRsuQQh91KRPjVy4/PeLI40LF9kJHoBfw5UtcPjr/PZr lJwosY5lAg810vkRIGOOmd4sZ1emMgXmFizY56F4AHQvxtvJF0DV23gN57d4soyzhFT+clYwYdH+ E461LtfY2w5vislJ9TYlB/eDq8Ds3FSRndW0KZHONwf4s9bMicpIn1o0JoM0n2JCJPFQNq5vrFTA OnJ+qP6wKDILWxVb2DHeRyQUk3KMTVJ0CwD0PW8csWzYBwZdvl+2Aw3Xt9XhE2RWQRAvymL64CwY OpgyGIIkLC3Kjad9gonWJXtbMsJKmfgUYi9NTnPgHqvl8KQDaw1id6f2HNZ/bZDCmVQuUJz/4z/P ECzKXhBnROTINIplazgaqaY/DayRC/xRYRs/8ReycR0oBoE1ZcBGMKQco88fosgu9iA1tJW0AlN8 dy+uLxXMyP+VPEj1CVYxTUrbkDsDqmEMtdxWORENyZR4hktMIcfUGkrAcCbYfXKACs7BTznYF2ne B4pSRlMtpU0BEKBZNQV77XF8qbnNluvAJKvoaQ2OpRk8b2GxiekW7HaUNzX2Dir+sJq7ID7lQiCp qbCa/NizWgSEmd3aE9zWXlHWYTTfsv9MOwkzpSFYmwKdsyTfJiyz+eBVOom89IDhpVmwezHqAgKd qDX4LeBluak4GZmXyskXKalxkNFG3ehEL0Oq1kUmO48B4mi0d0DuLwjYxFBeTd5FI+vo3NCAmTkU vWMJXLafHA/WfUDpqb4tt6LPKnNdEx5YB6UZlk4nGIsAbwMSJc4BEDcmGs82jRKJYl5aXD8hXdVX 3V+OTTHlYkHSwCNY6urvS1vvvHi7ojM3Ef0/ZHf39ynJ+vxPXPtyk/mxMYIT+MCAOp+IIDX9EKFN pG7a6is0ngTp9EGxpl+GwRd4v14xVfT9swDylzLFqzW5CznTMImdqL1clwzBwhX8QNKJdRReD65L WHxokV11HY6R6m/T4WfaZnHitNXq57Gw6lPGVxOzNDWtuJcf9v8KZ+Y6ouV0jA+AfCs0YIHbhmgC aSVglYcjGl8QUPXCZ5mSvGzvjjGxR5Q41aKR884uZ62U/Vv1gWT4n1/3BSep1wzmJX8NKcbIlzc0 6xSuNc1acfHllKDo6lx4HR4fux1Ug/uWWWROFBwnhIketMYJcCzNf50uTXXntGERRzRe8sleVmHK tBTZnjt0/34+3wwXxeJHtUPoogfF6Dhks2aEMsZuK8Ecjds54Oi32x2SYnP9gnP8KBiiigdqj2Ik a7xziHMJ75w5sgfoeRY1KA8JwJatJeLVydNH21M/M89aRht1tqsEiF41KC9n8TK7ovNEP2qkqgf6 FkmF9VEjjrjQQ4p2ieBk64d9j3/GExl/dbfhn/7EB1WPcYEIYQVno2Mun47QdahaDGWkG8Ikplc/ WSzAs3ysILxsurBrdllrMxO05hI0rOQWTfGlnR/FLwkOK0t8ZMF8fj29ePXWPvBj4ln+5ye480+/ yXm3paDYpp1QDciA0TC1zaomylhLAyhyXhG2z8LrBZFW/dv55RhjvmfilvMBIAAAfYpBpk1W/Iry ZfZ/ZHF1tI2GwCr9ihRbj58VKHz6XvMFvT50bK85r5eW1t+JjjpcLn6WBLrOTmYSldUrX1UkYPyd jW2JOd4RoeNudx/qhMyw5ALBURVVhiAXhs9bA5u0r3fjbynOgexUFK8DpOlDK7V7yOgbDWt4jhPA 0j4CRsdGyLHMqB47+dasbKp1s+mk20QG0OT8ZO+Q8Er35okSV1Zr9kEmY3Xazp8Qrl0i4nYerGDA EjlaxYwkUmJoc8mk4bhFnOC+crowfrVD/KZxc8wFKxD4r7CueopdRfmOF+d/nY2FCRMJ5obGAr6H VH4wBlz1ehmbidSPKWp8EaXgJgor2mvXZFcRm67MKCGkRgKfuQplxje4lOJATuYqSMA66UBMaFZ8 Yn0rlxXNsYotdo8MicfCmxL0KUL2lI5yNZ4HWW47QXBoSFNO7eCTohoSQukeLIunpF/N6kWp36n9 htNw/yCGszHAVXOLIps5p0eBR12X4MsZpHOSgFxwJG4u6GMLm3tbdjI0abVEe9y/YrKUD3X21+Bb 955cuPpdFFatoMzycmbE8EImPJFZUvjJB9i+9pp/Oo6YR8PgD56UrYIoG0/xnM93/+uLFBrB9uWM VOve2IJ0YGFKPogkjeqgdq8gwqquBmRsVlOIIQncCaFR0LRTXz84P/Ko4LQwyWp86MIxPCskuPQ/ nqRDToNXNLQP4fx6ivtLhZeOPP37H3eQZQHrQ+4uVgMnvktZcPjLy19ZZQ/To2CSzNaEKzojolyb ZZekR+kKXdEJZ+GqUP2ZPoIyZxA/dNXWJ5BmdTuFfgqgf0BCtjde72F9BvH48WL+RRfvLfdYtmmf HZXKL0hguKgogUzmlEPwGfhRP6tk1f79nZcx21iyK/ehpy2UpGCkGaejFj0NZeE7L8ZZQiq+dqMh P2vRXxpE4hy4W3rGOOfwmEEfSk1av+r/QbVEokesB1tJs2nJhzploA24i1ppTv9YVmTvkxYh+qIU DUdIDBvxarTPETZZcFEf7AeZkeh7ZWApH8XoxgTbFI7uOjvGIFx9cpeSsjq7zwyCs7p9GjeQ+o66 sJYGOOJIcM5Yi0n0NkUPz+qXwo25TrEK5PIn8NnMe1+qh1RwshQkO/oRdGS7iq7tQVhO+wTc/h+X LIKZn+dTXrl29YzZpCy6Hmz8BxEvPzhYw4KxTXSxmXqmmDQKpEoWZDxJlZE+0Y/TxKoEu0PaFy8u 2nu+xIz3kkvIkm9OYyd4WDbwOcMCTNbGvJRm5uIMgBiIGR2ZsRqmn8fHqAK4UXnQwULRaOkTCGtE kHY4BFZoJyKL8ozyhBfHOEI/kOoMJIWMef0smq4VOV7nsgJZZS0Ootntb0jTiYquSUQG68XDz5rn 8AKhKHApMTDal19uKpr6KCYRgMjy34DB5pg0cFT7jX6gG7F9GhmiiSxqiIsfIqcrPfFVj/BMZ5+n 4LFY+bmT1mU/IUydQREU6YHnwZIeWHikQ61FTVkguk4MtwdnMcni57C6duVTAW3Zlv8JmtPSkhxL 7/nD21hkVYoKhGKxHxhqK+OgnG0UrTV7h0NGKh7obw9iOu+SI97+pUm4IPg04Bhve9jE/WljVQy/ DS6StdJ/GUpwB/iZS/WBzwPeTX97z4QdI5OH7h9JFcKnqZMtZEMantRl03gTfU+s2dBT1kX3K123 UCcccHhvQ7H1AIwlr0vhI8jGKw1lNGtiOKc+nw9vpoPL1OP1JsF0AvgylhxRsgISHxrqIUtJ3L4B 3DkmeYgN3CPR8ZRLE4/EUtLsuvpY/JqTW1gxiQkQ6tFpq63+87EN49dglqiBrItFa2HLwlAtgH9w f/nhcLN0MqJ7FnouspAbAoufbyM/5HoLQlPMjcGqZ4WIzkCHN7cks4V4Pgz0CFDPlNWnTQijqMKR XbKTUpL7m6APbCG0g8mfJQ2iHmj7wiQRo9Tn7+yI46J3CTz1XWEk+NnRxZtC4CSuTLDgCoWqucs6 WL0HuGQDHTrBwYWlmsHRo7tGrsrTiVaR+k+cjpLOXDV4Wl+Cyacj6/lGNZ1+2uhtKJgLWkDSbmDS YjxYeuN17y5td0yarDUGXm8jPu7t6UCK8EOwlcoNasXbnXs294iU//pP///8kg+yheyDlgLZ6ns4 VbFcCJFx4wvh7cJJKx7rL0fAoy/YvEZm4lb+FjDMsyxyxfesmOnF7Vcy+Htjxce07zr7zuOiCCqO 2arQRbZiD6uyrFSg/AkUgRKJp9TG1bLXdFIzX23xPh2gCFjrICpBo1nHrx9SZEmp8WLHLEWfQSva O1Hy3j9TNTH16yGhUlm6LCuB/hxMocQfYiCEhANqTEgjXY8PSyhN9NrRkPT5hBDtlnCXnBNzWeLQ ehtxbXjfU7dCqYynUyCdAfSxLnESezbDvKXxG6Yi6er+vTPFHWd1cY86lgQXdARslfsNxBxDgmkZ 43oDnQJzmn+4Bq0yn/cy9FBgdyJVLEo6SMIhJ1hsc69eRerG8a4YJHTcdye3oUMEU6EfvIN0vfyE MglRo4bd8eafQ0cEMfuJ/C9JjmePsF4SZNZQeNRokwjJzZQTlBRJHkkqMMFCx06k4qW3pWvOYHO9 ze6EPDEBn7Bo6zpVgOct46J7ExGq57zW3KI5BI51iGC1CAp+Po4Uk8vzhIuzXTUuqoyDYyYIRKdG AoZZYQ3KUv6PsBsQUlBBTQYDrkWHEbJrkVkxCh1cKkU3niNJol9LbWQlFYyjcw4gKiu16qeuAVwg tfX3MXR0LmM8rTA29WIPOT3g6oHXUkc/wd0g9AbMQcT0klUGjL4PYl8niNySDOLFFapaJd0zf8NL HDEBldYpXhWhVss0GOPjsApAYS8P6/P95KqO6bMol3PbKOB2YBAac8k+4Cytxnp0C+icpUWFeEK7 tBSIN759CzG0spDVBgIsfx3F1B1GoIeGQBrasjoG3QgN5MaRNwKzcMbU7bTgrizk9trs6ZwxL+C3 dHxJxDJKX/gvuMtnOzvFK237KKfswbdlrwR3h+rM6p+1GjOsXlec2bmQKy83E48SyrwYIFFJacLQ HHtpe37/x8mhHzdcdfZRCK041ZFrWGtDPrn3RmHb3oqk1UId8mbknro2579toDmJQKfD5whj47iu EIHrCUTiW7lx+vBwnWWBkgF0SHZw0PhZgQ1rC31afmP/7EAh5XEQ9EkxlWFXZoOqy9qavVWTF+Au hUNMwa7tY34+VTkvLGN1MxmKL3Vd5v1pPGlZcPXw+cj9pQ/BmycOGvRK2rNZkcnqMS9clOb0659U v62x98ZfrWaEKTnCPCYxUK/5riwppDVZRGK1o8NyKsMjiq61ET9czR6RFQBRwZppJsEIIZbLhYak +ARQ3h9xOl7dhxeeRSzGIxNlkRJHSX74CRXPT8DKKG4fLs7g8i6lN4Gr/3XosP27SyHu9hWPPgFO Y4wFNOBvE6cfPQjH1c3IvQJam4s7hI03Z7EAFv3pbVwgKdUM5TjiEskFCgLZxVtQEUTfGEWErVY+ CeXqfzY3caALI6FkluxnqDaPa/Ue44cVOjExhBS3I2L7Ub0BjrygtX/+brGUiTa5ZDt3qHeHBR8L +zqZO5VpByd7gL010e5Q8KUUvlBThjwM2VkN+FBdqp+sbjOzcTNbRfJt1V3mKY/6ia/o/evFgF7s De93gnV07QuHGBpmK/Y4P7p7WQS+ph0UJlJ/AE7OVHtKRTS4eUYWCCkn8wrTA1D+vEzqlW1bihKe HFTOZhYEGCKfSRZlCD6t7EHboK+6d+5qtBR7ch4cJHGGHtViZZlsOlANFwWSJYqQy8I0hSU5vsOI hHmJ3YmxSYROfw/6LPQa2zBEagmnNZiVL4l6+0nczhh0zWKFY/sPao7Et7P/cnZsWFmtjeLLYM9V GhdF0J6JrTPW8TMpZgPRsBt/PsKosAd5QPcE6l45E05dfxcXQL0yhkzgO2BNOjrYfWU4vK6uNwax 7srqtxHMYejuWF/s5uYWEGOpeJDEViJtkFey4ZpbnwhlTzEQTv5JEP5ejd++WCpS/lWlZTCsLTcX DNMvKOe3rOaEBD/AT3WWj34xSykbqNdzdOC+XG2lvp9mQkB3va2BJdy8sHnCiVc7jPLt8kVTzDHV +17kp0qVkyzVKwXWphVdrtm4CFwBi6sRn94G8K7/O0jYZkx0fHZfaoEvFaidKwLus2MtwI+w2zeS HOEmfZxhhTJNsFsc+7E7bN9Y/paFrcM1kyAgQI4Eb+hSveMK9pGjrQ281TBFbx5xggoB8+D7wRuR XYPGWgv90OAwLfKUYe1OyiWv09qckSEfWlJmwZ7bk71ryVVRYz62p59JmjQitYpJrCmZj06r8Tya d0Q/tUMU1L58yETQA7XX7saGbd0FobP7lTguylDN0srmvNnEVJJWIwtckAJrD1yWy5qFGCdOWom3 aCNfxIf2MiCNxW9x+InD+tytqnTm+iqQZzWxjoT990kjdPRhV/E+f/M4vXMIC4Os14UAhuMPQlqP zklZvACP0VOyBc9VZpQE7TiW/46szT6s2JtD2ApOufHSkR5U1V2JkinnFUyuep5FN67ncBpNq0gu SrbZjmZj2CJvYFDh/6aCD7LVH7qp6nxUQT2mQNb4P0x2kRCEDoWlztr3zbqdIPpcR0BNMOVcR8LQ KRRX4JVm2+mOe3IVSPAJh35Kv29KLNiVRNnWS16+101SaKv7G4OtvBAqpHUeTb/OG8yhlxBvoFBm jqIrVRef6FZ2lrlDxWx+TSRzJ26bcexj8nCldBI6LTuLOFQ2ZCmO1ZifXRkbVSsFfhFu5o9uoU/8 jWSQgKXCrOYikydCJb2u4E0C1H9AQ90bRYawt++fVsHkfePxdMpcgbNXlCs6nQdNyWbIZfne3okC nnocqPcnw9ICH5lJ6vuYw+pfdcTpfNbYMzTGEFdJjN/1RuHSvRkiOrV0xZk8Ol5hwik8IAsjmGZI n/F/4RVf7s+FL25BYhoiq7RcDdf6uuPogaJ42mh28CDmHH6j334F/1MWgynS84XsdssD78Qs/qkt Wh2lOtLR+PAEHgb8ItX+Kelw0HAkZTzYGfSrJXMYVojUCYsEGC7Qeuo3Q+MCUNDofiYZZsNpGTzr 8t9ZFXPXrWVx4Ci8+qhEPAcewo48kz6FgnEy2LkkudhXep+wSnocCRvwoKVDgA5U6+/3prL+Xfaw InFoH0mrpJwP7QpbBW0p4ZE3hhEnJ2VjTFkA6V0jqR5eO/lT7TZX8SXEgmP6IMF7GBdjuPBKcBDM Y05GKpWjqzJ0pIakDL8FP0cZXwk6OQ8tMiPy96v2R8AmEBBmaljqLtPH7WoS56JRS4QdcnQpIN1X vq+lNtBlY2CSIyusnKGpImLSmemxb2/q+QDATgm2SB4tdzgENn/rak+sNX6JQUHtoVBE5rascthT R6DYfcwMWc1MAKEuwhbNTBHWemRcGbcBB6MFayffqcTJ0NCYXs6X5fH4UlZAt3FQmRF4+ZxPwemU 4Zj3LrcS4BF30Sr9fWbQw0LRunhvVLdHYSQq7tnbQbziM08TX62bDZeJJchVFbp0ZylJwjA+7wCO kakp7VW5fq2exghqsk0XagF4n4YF0xDsWSGp8+xmHRiCYtzS7WAA3RtdLEKvrO9Cy3dFOrECJVgt IdNsNHCaTrCftQE5GC88WzzCFxF3BtTVX2uXTojucBcJXB+vQjxaWqc+lTICwHz8nUcDJ6VvstLS 9fIY5JTTgQvjkaDKbUJg2iWh+t3gj3f160cwkikPJKSxzSLM8xDb7OPYVQb5lg6jE9QHQP6ZwdKE APl5A0mxhpZ1jD69wmgQC61at4bu2Ir4UdQnE3S/54XnVPFQMzCwbL22EogSxnggCiyDVIai+bAN DE8oxQCJoc+OwGn2m4fsnnEOj7b1YDUiZb033p/+sf/rShYVH5S0LFAwQuoQwcAWSWtH+8cMS7M9 LMn3vQJPtAMZ1CaiPFRCyi9SAhz2VsEPUVyIRnnTPnnNYYeU0xoR+k22l3BraNfsiennmN1utZXR jl8fUmpokXR2JssR8i3KUnaMnWte0pif4VDEqxPlObK7y8fR/I6LzBuuBT8I5QXWkMVsEwOXEVMw SuotmHq1j/9bLKed+GvUMMaYZLsSGH6g3FEbQL9JuKoiMU09Na1iaGs+jrIrz9NKkcGCtbEijzL1 GwM9irLt/3oOSeEtl0pUV4zKbw66EyKKGE8zlqw5wJx2ekGwWpJf0tjNydTRwY5KRuNGNIT7VQuw E6HhNffu4zXDbSepb+mqoj8spdNBcNpquXSzgWcatoeAHjFq4gZ8Do1r7+PHAUd9f0AF5SwSwx8u BPl8W5hewa6OtgZFDlW7JwUcfT9FjWdRqLV9ORiTjU9E/csZHeYb0+cBX2jwGabQevhRrNZ5hYpc dfqI75IMAqY+6RFy/m6CYzef1F7C3n07x9GN/RzIW7SL780U5v3lf1azCQcWwwXayTksf1zqEafW cQmup1XnC/UeoMcrQeWyPd41C6W79Pv6u8Km85N/ZKij2VptCfCu8OVN74BRONv9LRJxrnAHjHa2 fCc/knDBAjrGe/mk1isWYgBpmPJifEVKuUF28VKFKkd0YOiQgR59pUaV+mPazfJnYmiOpYSz8Vai k3fYvh4E3NDg/M6Lq69UBTVry8xXOjVyv4PwbK0+opkgHjJgN3bWA7UUfSO3V46WiAoXikJYiTz/ IPHRy+gz8f8jmAGH6Rc7WrzPWArqB+6PslDp3GXaD1X7SD3Xe9RQJEHJ/VEMu1PfRaRIbscixmky lKrmhpDRnxAOraSZ+HS8oEBeDowYi7NcDCKg6aw0BncfoLsl7K6241VFd+vRQMHtykWNvMlpSHRe WoYKnG1O+v7TELAsV5jAoqN/68xvrUjjbRu2G/hvzIc+owio5sLtz+9TFXPBvXodmyok0F2mXl+Y hYvW8jLyrtrrlgrsVunPS7HgyFh9sL1Wxo1vYM8FwUdGeSJZR4ByWSyQVLEhMnoIYeB0MDu7Zcg1 ZtQkOCPdkCuvjehy1OUeXxffu2E6U8WZ45H1oaTuimkjxC/v26RHLqmzZvRyrwZ0paqfNn0nz3m1 mxo/3Ix7fjuOrql+h7QIOsvbhYC6mpXX4xsbYlkpjs3mubQIXxeYw8hvBRGqd/lJ2ql5wMMtHqYb BPUypoAzZlOJvSlcADj7sndV6j+cFNkUIbB3hL02t3NAJSqQaF8P+ZS6w48VpYOZxy9WdfspKU+Y Va4GJj6splRaQlpPT2ngZM0ttolCCyY9GzcFU9chQO/YZKIH3ycmTlSqlMaUDh70dOC7IZKoEA55 Zh+wr8cV1c58CkiehREJZJLPPx1hyNxptG2c5lvaFm6OPyJAIy5QkwSm1s0Qa94QGymXC7TgNA6g J5FlxoT+g7aNdzJxBtwJPJDViyi9xQUy834gnuCLsyga/AHjN8woPthyl+Vazy3Fvz2gl1RZDkfI b6UdJpPT2z8wqi+XSBfGMkqvGudTWt7hC9WPHiHOLqNKwWarKgxrgaA4deO1wv7lhnCpjMlX9F7A d0MVCczqwUR2LdpD8TwEB33TrZ33ug/dcFm/1/wwBpB/37IR4XkyjuRFKMEAOp7I6cuESGIVQJJ7 lPS+EbRjDMdD8GiGquXGTqn6uosw2D8NzshX0LbPDJZpU4YG//44W1TydI/5KuwWRan4qdgytzNg gVQ1XhfcsZrO/q8hjgs9BxDRqSSGKluvjY1KpygrpFyaU0Vvw7TDaViHfAwHfFeBOGDFe8a5V3U9 Mkp4NveaRLpKvr4o2VVBIs6U8Qr7R1eEz54uElojsvipqwCQT6lavV/8JTrwclnsteJckEN8T05/ KWb8kA6aLtYflFpWZmKHR+3GIQD8cb1di6U/qpFnb5MnJl2L+YJwBZlQBCdPJ5IqzSZ4nDSVfxDp vTki6XtXq+fHji1blZqNOcChA8JqGDPc61VAZaEckr06MkorRv7NLQA2LjPHL4szcJUkvnMi5kx4 iyiqKXxVPfzNGTevlx8qggAsxZMGXZF5s2WJIexTJ45lIhVanjyvYNNJxMdBHFNxz4PKTamyNiDt ssqRx6phZcWHDunCJOeR+Eopb2YqZyIEa/6fj3N0qBelHn/QLeNICC95wjN5d9T8Oe7tZ62HWs5z 6Q0Q6oYAAOIcSTv6ixUjv5cLPfQQ4W8a058uIRIUKMuY2clZC/iLjhsVmeKgY7BqIHEHV3pR/4ZX t1LWbH/7Oe097E+wgG4XdEaGAvUG2M4rpS48eQ93TTaPw/3INi0KUsU1ivQT79THrP3hWo4yZMiJ TnwwWx3N/2zN5V2vtgmXbUaajTs5vN1493RUdmx/ZHTu0+RU088YAL9QFr2u6VGMwUfvyDS3YZut 0TPLG1W2kS97+dTDEGyHsl7eyovCxxhDZEPgDweDEoxpCe+Fy4Dp+YpBEw0A+HATY+z5YDCd9d7t nfVcMxtM2ICO7lpEWz48taO56mxlR7fxJxo/sbtELZOmUKKwPsMLaLsTpR512WYxqIwXQo9LECw9 9PS0Jm4ypqp1jry6NaNlHSUefbcZyOeyyxHCXufaxMJ9B9VIAsNxqKn3KlqDZ0HRzrglX4C3DvIM Gxbhn4R8Z1n9UvQNljZssCMRb5tyf3IYe8ldqqzp9tmyDTmn31ZzekdQ7qwXXYdwyhKVscOXbka+ NIm5C4gAPK9v+644mwGSK9y3QRIJspR9gpnLjf5iToEcniOPKTAE6ddKl3TzpfFzADjN5tSTMM5a 3+zH9yC26DizaUoxXqTTrihWONu6MmeQ2qPQ6sNIhI7ijzPfVa6L13Kon8nKy47NzQcHKCaiP2LS jXoF6EBiCaQAfKZKxl/R3Jneycvc1w0JCkE6dAjJr8BzPBtqKL4KPJKKHu9uPzJErCMY9HkcpY53 m3o0epQvOrqNixb4hmkBxklzCxbpM5ZCx12CTGw2Pt/16o1rVmAfRcckg6JQURZboeaIDtMxH+E8 KEnMpcUgZ3CK4qso/6AkVJO4oIupoMYJXW225d0x+QaRynwGrTUN89moUmJfegPsg63FWKw4y97X fiZOj7ruUjdT3xqnkdwrf03avI06FSb7wvDguHsJmmX9ZhzOImmbvi5nBOzPPw287orGtrvei8P3 6L60TaeNcpMB4Kdn0SXH+hFS9DTH3IRnmhGe9PheqzyQq5qCLMMUQkaz2/Agvz8WDIRwd6xNeRuy i7ohEwWzATid/HOYRM0GvpARzuFpBqeahiEOZ3tAnBqSQDPtTprU0kc3OJPrpN9ZWnE9GYmVqFws i48CwLElwj/FU7A4YirkqP2jiwu8UPQXM8LYmfZVdBZAvTYQMFr6RRO5pOJKX2Ag/TLR7kwW/Zia UqnHDtrXkxwERkwYTxLTFiIGXCoB98mgbJuCfwOKqWPs0CE24Jaa0/FXkbCAdrQJ990GlvBSUdds 82mXwDZiEJHV4W9HvHUqlhvux5kiR8gGh+UBnqhaWjPrU1uDgpwaMZEmlYkwuzKLFzgDN7i4TLCd C0VZJ4WGtgMdcuDeZOOu0PTrvczpGtsPmgUz4mtHzA0Saqj4zm45Wr7gwhGvu641w6FmcKh11Ses hDzeMc2JbXl6hCysJjvQsRPCliCVfMJUvSSLncrKX0cctExYVz+TfGnp2PLMo17K4Sce5QdqYTYU l1soh+qwW55xKwz+LOaDGHc7R10iG0qtlKqi7376Fa0K/KEq97oKVhbS/ANjhY3/GdL03Y7j+cFu sb9SxBoydJQS7kkSV2WuEKG2b3ZiqGsdwdvFoyA5MTb20y9vLMDT6+yfUweFxJsg4rj0NkmukLU0 1qF0/ZFTMD4Np9wCZv0sIADhT/rTDIWKwNo7ZywyXAalVM1T3vEIExyZktnQK9UcDE2N1INl2mQ5 WValtZ++68+xX0s5meQjFKWPsZr7pOprT4SIjU3vUo85DgLGhfRAeczLg3LBSZnBOEQ5VJ1V9KFn /o8H3e8Ary2/E0pvCbBdDAybjIektDWuxvPQHDab138ZHikdGeryvxstFGXe2mw3q2OMUwf5wyRR MmlauOz2V8C6e5S+BtIL8Y/a3NZLtxywxls4OA7KFTu5m0jCa/xAxFK17EJSrE/M2KmtCKAsfi+P 2mD3F5f9T/nbHaxEsOiqEPgqBmXVSu90+U5dymA7z2v0FzvVa3X0EVuiXcMlGPqX2iwrqJwG6kRl g6YvsJ7/Uy+zylujjXmaU3rsTIqXIeCRhQoiDaqYNZZO2AD1eokrfMX4YWIkHiEAzxo+1i5hmVVa VZN71GZCsQZdhavp3kPCny0zEfrjyTikNHrv1kBDTYxUF2Fk2kUKPSCTTMc2WOGntXasWkce+uHP aOkuLff73ibYK/hPaHX5hTC2IxaMqEoKwmP8XWnZgFXWMebS8rlguYI1CC/Y0IJfiFwATRuxJ1ZL 9CaiEScxtLwpjueXhe/uMelXfI0+IMt8Df4NXGYDZpCkOx+FOicGDRHwnSSQEv8xqST1uIVQVIfK zWy734Zj/1G26jPowItErtjzx5r61I+VHFZNjbQZkAtUGlg/bnQSEQsRWXJXlp3gBSa1ZB29ICw/ K26XE6oEULkwYLHd63n68xVxPKP4R55y/LE6NcLF1+rFfKpEQ5BNLAMXRME+WvJOoPtGeMgMinvA n2khpRX+TFWV659aSHQYykw2SqKhKEGbpScYZuXJ/GRT+Qn3+iy21/o+k2z521X/ozidEv3WvvkE z8Q3/MQMk+RyfhpFgUJ/mpf7ZPeGOW9A4mUWBSyGYfpkL4yXmexxGUPq745QcpJN2TMGy9YomeM8 3fGmZoUL71xXodNeqFz6zyPmsnstyDOW1iB4DSlo/lBO8L7/6muKChatmQ1kMQr+s/vKaWjojp5y l7ir1DxstmvCiskWDpyUbYpcu2tZW0rfU1+nNpIlqFVRF6D31xKelNruA/ZYIAaO33SGa+Jfbwjl +o//pz2PGKqAboSsw28nrwYAGkdY3Pb0B2ZQApnETZiaA413prev6hN1x+nC9Zv7npVgjCEhnn2j iqucd6OEpHTldsqS+aJIGnR5m0Y/I1k2GhvBhhTUTDFhLFS/3e+u/7bUZoWHBr0CuNYrUZpzIcpo 0DCR/eS24SVKNkZupTjXHFCr3Zqz1dmSfkCof5b+LwT4RUHPj7cT9UcDrTKPHJpF8K9K5zBejkz2 xavHiN1H2+BaSA81m0JP2rdU4IidADEaWe1bufeAuN6sVy+OjnlD0uQj+0qo4/KQHl+L2hYqv/sp aE2M7GjyY4D+yaDBrmGv3qipSBekRznpIS/TysiJ4++sSXoc9Xt11INdjUw5UdocaCC0mxwsFNcN 2i7xXxba+FWNOCvde1/pmy9dPuQKf654+lnm7yt54ljRIz2qXUwt/yYQuykZaHTHWRpQZtKkRii3 hMV43P82QNF+d1Sj281FVA9AGIpFFY83birx8vBY7GYnmpT+PP9HaHVPl0/XYR3rlGC1b/znhRpd 7XrXMGk+W9PvrCHlMBA9C3FvNyr3ddTErfHg6qj78Aixeu6JUoHNMkr9phhQTsOMMUr0J2KNH2j5 OH5X7uz13qQKmWiTUBBriUzNkJfIvG+XNnQuQGbCSrWeAnSrns97aW64E63DbkuXuyfoMKeqQ9sh wN3JFkQ0xjLNrpXGz3LK2YuT0Flooqjof0rNL6tsGB9hkSuV3fayjVExEFtVIF0aOXlV4UufFbX8 tzBiSuEQO+7xoHgt/CIwJOtq907MZ7Ya4DtozAIFPISfb/LKafGCeI+LsCPnN0iUhvT5JLD5DlLJ /RFX6mkDinh7GvRT55pCKevHw6EJoECVHjO+CPvj2IDFuGHSafmQHdmvlszotJw5DqWPw/Tpv+LL u/p/pnNESSoB6+9UMbHH7sciZj54l5A2jaQNJgBZWlDQGJhEmwGk3hm1Sc5GUcG21TdLVbLVT1j1 CoWhqmwHnHrMTy+7DJ6ScfpJoAYSJCdCPFKaOpT1Vw8k/VoAUh70B1c3bMMBRaeJoEwVM71k7fCp OZ0SNcF3zL+l9LImfWKJU1/615/hbeETM9kbmWRzZwYagQtubwfH3zOcYoMpDLpuY5425MkR090o EOzW3emKhetZgjaCireCtJeN1cBhS9/qS46eiya6ZyB5fqE6vlXoIi6RU/C0QI+cM6kDJL0jf2g5 pnhzhOlxED7r7tjRL2RKQ7JdIMCMx8RIOFAhS0iSNcjL0xtQiLglT891ld4SV6MYyq5bhyyqLF2R +BlrUUP1CtkcQ2Xms7X2HP+D/wmKWW1pN7nAoI7CMmhtdQ06nY38KdmF/1BBh3z9TBHu98JHCTz7 kSu40KrHgJVd1FLndfoBMYIf2alZ1s+o0f1ezOnlFBYWCcWUpBEd9VHe2yGiNDgZuqMH7xI9NR00 z8JU0c0XUm7bj8SOzCECqOMMrt/EdjVpPQS/P7uXopkvvyDAxtKKxlNyy3pApZ3QyICDrFoO/+JI GGkm0K33k0OHe1cN02FMSd3d6QEmU+pMY9AUJuNXIKKpwohgcyqr5y9zDUrj7iXtcyJjfrigX3m+ G220frgdKuAHdvp8mkNs1+9LeuvpTQK+VDqUgPuBgsz1pAmXtpmcScbp1yfV2oAfSSsfMtJlhiO+ MohoNS6X7lNdXq4M7fzsq0YkTAYztueDe6zbnZ0rjiDqvtBv0LQeafMzxxpIppl7GuB3Yeuqz91U NUJGVNDTVf/SGMn/xSZdCgjeuk0dsSVF3eQT78Hnpw4n/DA8xb0a9Mbh0+Zbx4UTzWYVy1ap7y3p v6m6ZjoAZicCQhC3ZO9xbQvhE05AFmtyc0GY5cHZLvLx0wJ6Xr8CXZF1fLnYj4jCoCY2OUOxE4cn b6sZ+YMdDBGRu8/vBLOHom/zBPVFngb48Zzt8nqqDK4P7A4RTf9iFTYSIXZB7qZLTZaIBoLoIFXm FO4TnqfUx+6/ih16fT2coIezjwoGK+sX7p8uzNAGbST8gyt+invz6efIsAQSW2T6cU2K+++Qelxv xS3GKEWA7fVJA0nzro/SH01Z0BpwnKVCIZ7OZWD/tkPo/KR995NaPW7nzsdk3gx3j/CVhGW0dDWW 9rhNcy4s93et6kF6kXVkAnJdfJonll4GjJBrmaxZGLHgU3UPw8/EgZUl/5T1Dp1Xi6bdEF4w1oz6 pXOOxBhD8HePmElLxbonmaJKoiB4f6764NEubf9PoGlkGtlHn1GyckuOefIxqaul2a+3/J/By/s7 v8ZfpVZGQK4O6RVnUEqyCn3dmooB1JAOrBOQh1CI8o4hWNcd7VGbqMk1k+E3YCBfgfNi5I7w869O aCNT1vurz8Hoq1ilb/pHA+P0u5bwfiX8d3mVxBPs5/ZzQ7pugPxzRn+5bKWECYxq7cx6speEP6Rz x34zz5UQHcKQLzfYXyhUyBo408/IMyWctD2A+VUo4YEnI0fFyl60pqBGDM5eT26sJV7u4tBTTueV fKCADRP5A19sUblO+xfrCv9KEn9XTSJ0MuQrqeghxvwFQTeoXOa17Jb4zd04KqU6WaJD84U+eAkU TvLKeeZ0CoQKEIAIBL4dD0/A3xywCpe3KNGiYxituv4EvSdVwSGr1+fYf1XEWmwtuuVdNCJpCQ1S 2blmURB5ZVOiMpp2q/OFybgxlFSATZsfg6rAjM+z4CDMJOdJzibe/8G+3gLZtMeCxnvBMcN7fxag vHm1i8dhfolsZZjJ/Gvwy688TKF6Nr++ITIIvJ0hn93aQb6cFzRUwSA7oN7kIR29iyhwokdWoskJ Fiav0HKDxI1li7JXY1r/NtEphM/jZgUGX2qJZYW69FA7ov1opx8w1XTG+wWgJvEh5euH4ZljVa4E X0v+mDCAuGkn3fWI8F4xj3sn2qyslYxViS02XGUTZkLiLUNRoBgQx75MuqGHJRohc6pxTPdwm3MW Gi8hhkM4VJJeLD5L9yN9oLR9OmQ1BJxUIH7C/217UFptXoDTBna1fAfS/1Zkg1CfeWhoLmQL0bh5 4W1wFyh26mH2dcx35D5RgSvzVdYr+HjZFYbDk1MJbGSJV0pgwiSiGdNt5JIWsC7AFInFEZp4j5jV NmSFErSAvJEaV0xSEMpL/OS0Ns5XkiOkP1mNlCVd7gWywyWM4n3KT/OxvmxSE7MojFjt2lUZ0LWp BKF2oaGnRWQiqOpuOv0nRQ5k4RSYoKEYoVWsIzG7g3/Btnho3Zy71zKE8t69dg+lUWyy/gftTvIP 21cb1z5WtYODGVLFaYft8p4clHV+6S/YEVTkXBOz236UIp8pnmu2pI81c4/kbaIs6aIiRW9+kkZj abgjZiyyG7uhwi8T5MuIFHOB03Y+hWUY4M+VAcaUKDRigUZjDjodG8f0PWj0WmUfODfn/eotoV3e 2bGZCQPe5c453RTGhU7/k/VlffGQ4pKwjh/2m/psFEWL1YcYXY5cHq9sCV47Yx9x2J1t9Mdq4G6r 1wc63NSZ7S0AIU5RXp9zIEwewzvINGmCxmYzL1KmXM0gjxLx6HYK25DVL3oLlIsJp17M4z+5cB4R qGcyllWAYRDAqmKSfR0Aj+vpN69VJjG8Lv+RuoRLz08Rqku9BHQrilfWbPcBhxrUkgP8l5bp6sk0 PQ4BakM1vfcpQOQ58yL589XynJGEqTtx7aAHxBJCxxw8kUaqiWB8EStBUca5qxAsEeH4dRIBiXRd WS6cwDDxpcqTwRfuvKJgkSAeLwa1siLJ6JZHrtlwEeepWaaY070zk1GRl2iZcW0aiQG1gMcGvyc2 xxBdEbw1HDUA2bjDWKU4mnx77wgcxIAz6DsnjNC1hu/dKXUK/0OYewEGMyGdwVNqlku54N8urwqH 2Vq+kkYO3UpWZswjGAhxhPvOv6FdLaT6INGMn+dUJ3lI06QVaIo8DWrdEizhpEwssYMNync2eiV1 Sn+GOCwZJWhv6vs4TuPZf/U0aJk41vtcdM+weKvU38oBYY4DBLtv5p60JDHqL4GUiGcqntOdnxbT mZjp3PjKd+me0qHfQWtMV2gMpwqUvKklmei+aGpom8/swLFkWiGWRVqGlgJ6ETmJaINBEWzXPgMZ WucKaRNJ3amzsh4UxUOKcEqGmRk/TQsWWRBmDT+V1Ts0o3p+jPqu9glbIPGY1uHUqZeipabd56k2 Im9qYOhtz3CvIJhl+OtTd/DA/mjzwb5x9bzZBnO6Zo4FvaBIrdPz5ZXIbZcKmcwfVaYGYPhuLrFH xnf25zD61uPRarsSFCYtn6WwOpxmtlfyIlykHCqMSdxnJDaqatsrzDYmGCc26bHuvdqt08TfZGuO RuiSwRIpNFpXTdMaxq/1RjIz9wE7UPKTzBXDE+rXNpMLwVrZ3JsNONL9o7fTSk4hDOM4GsGEU9eu CdQrtD2cqm6Xlz1qNJG/5LFk8llGbOr4z8SdBCxoEHoc+xE+pq4Ku4+8xb0svhrhCVGX4iRY18+u DhC+SnZYT3ozv0B4w9onX6yiRcyHM2cqyeweMKOuatOPbGRq0yBQ6qadVjrb9lxa1HBL9chSugDT v7q58yy1yuhFv3Di2tDyh4+QEaxHm7vpFIfb4bqMePjXkYL3SvJA/RH4C+/m7ob6r+pFhH7wrow7 3C3o6cpZyafO9YQShRuPPDLTluo43enbcH+Vbj7qjM5ZR9uAHVCfClyhsx8NdKbOHOHF0Exyxh4x FboDfebgky0xlLpC3MstDv2YEhl1l8NmtJuabjywQmaPkB2R/3btvlhxkYK9YkPKPWsTjy1s07iK QWWhNE4Oro14hozkcai0cm4s6PZIH5QLeuDbkFPV9fdKfMVdBx70rUDykjpJj+9jXQTLwlwCfhNb zAOqV58VJnRZCWVTAAzSSuoVPzWcJ4AmSG/KJRwnXSe2YYgqa1oFKzo0vjPoQuk9ulVlVlVFsDkh dQd72nN5MvpKzgNycCQXYK2rMfPX0A2UhkUZKbnwOTzDHx3OtZtSs7HwB1C8QngrhZoqm4UCDo7W aflh+sTv4a0RyoHyiMZY5SDJIfB84+Th6sKy4j+SWfCE+DYR5rfZD1rougO0nGwPEOwGAnHHiBH7 15gwVcBLPdj6Hi4B29Uzd/O5X9vCWVU80SFjjMKzRefJZgBt3TBwp9/9fS+drmKcpQ9G4rQgm129 wIS1udilHqtpmQqCEaXzhOCOAYqpvIKqSLwRvR6UTLfDpdeXg+YWlkHGl4sC++qays9DhfzDm5hR 1giT55JfobDloKV66lqKKhOck+ISBLm4AhRXXSSfSxkqTi+0dusq8HilJw1yekMGMLZfxzMrTdkK zEscBJkiQR0GNIAV4ijbLkMvCBk4DEsihBaIOnIJMzXUKXDQtx6pxCse+N6LBj3aVwF+08QYoeWg APjjGAwpz/4QbPhGc6/wMWrQi5NGztx/SZLFnEujzzlO+fZWURfw81Msvx0F+uqENNfU+DJSDE4q +U3kLqwCDAJqZ/Q9ZDPpAeMuUR+2b/VeH0UqXRgpZh/9M5ZVllMqCnFHiRwVDcwI0EpP74w/+Ppa az/2HjL3irpG3ce2KWfoRI2k4BfNSqOSwAqfvIbK4yeNNbfRpa758vUW6me7cdIvusGL/KgqwrCB 4qMe1uPZNMlI3eSb5LHCkmn3TPd00gjmsO3b6lTPiuGlk2oQF64WHn+jj1CZpJEdRsM2abyjFy+l p7J1Q/FpOtOnLmUst/g12bWoSeW6d1ETtz0NnanbY02Ftm1nh2g3quJSGESozWWViItwU6RRjn/J S4PSjdrfJJSQgJ/BFIDmnAWvTnSHnJtN0PZdMHnlMwWJgvBkst9SeSTgq24i3hB3/YtWe7Hw1H57 /nc6b/CDaJaBihXeiS4iYhGvUAEZKgrzCYtM0EmYDiBpdkAeKLdfx3g7Rpcgf1FcOoR8EiIpWNZU hAQiVuEyIBspSYJl1Si/ejk9I12dOCF94ifgYkE/7SSqJ26fBD4wkmotm9DHMo+MUD9LhuZCaf51 aaHfFUvCw7hoP8JPLRyviDrR1O0fjPImNFvZlBzvwg8PxNiYDkT1+w453Fbt6MrUxbXwIvxgCmvl GxLf+PATO42PDIvrUgbx4QM7etSlEtnjqzsr6UQ6pvMdQcTM8GlEw4ZHuNQ3ejnmOUpiy9Nq1Kxz diLEJmbe0ullFdGqcBjEaZDQuT2SMsqSk4LRpoz4rnuITbBbtauj6ooDrYW8/6xBvPShFLVbqMTb u7bt1BaiWMJjrRHfzL/S7UqMnP+okFn8z4YGzlmnwtbbj1QLPpkxIZmB/hXQiI9pYJZ2IKOaJzkn ne5VW569HcOJSykvdQUEmEOjaBhioF9ve0Fm0nNsbzp5ym2faoZf62Z2fUV7HWi8ct9XEXuKmAFK D5LqUPSVVWepnLVlCrQ7QjmZfF/9h8pfvLs+THOJ6WYXpPJ38NVQUprdtVQi6jhIKMmeS8T61SCY /XolQ/eQRjTlGyTk9mQvkg7bK0l3AD8IHbIhrwoaJXAucz0zMNwoiSYzMLgrnQNqO7AaPTQtFfBU vg22UAIYO0VtA35SznDSelAHgXa4EAdrFw1Kf3p7wnbWGIKYKqBHmMvyBJn76tfpRueSlKvpS9xz reigmOigzvr7eqtD/D/hueLq3RWapcFk/HiNwOozwSKi/PCRyrm45tJJ/mrTY+3SwsKkMMaEXZLE RRvmzW8RSdHbG6HckWIDyVw7a9oVIYOu2G4jq28+tKUwKBWnh0xyvq5a17oNSiS4PFKX8+Nz7rfW bFqweH7luDN+EKqfcI2Jg5G7gE2WVYQNgtWb3o8Ugo2LaoBSpYyfEvU5gdihgPWJsuWeVKJJnu7Z xN2s1Xp0bsjXZz/P8GDi/FQIv+qhaXf3D2Q77HsQ+ePEe7UONjVqH7o3ABMfb9cMfR2PA9R6Sy9z QQIngFHDTudSlCJHT1g1x08WVABO0V0BRo1D60ItSEgX5nCtSal6GVkL8jJNK2bNLuR2PyHUjocz ZNfkOi6CRyXzndpOgZckcUayjToDp+V2zSdDPIK00DpauU06m8pvD8azxhqZwjBGX0+NARx2DILB 9H5OdOBRAyLlIVPr9oCfuX35DTAbCxohAiMJlgoJ7r8Nce71McXrK3XdqM4v+uaKLnfoUKh35R9T 3vyOQzz6h0WY+F1U7ZoFe0rz1Bij6pl4OswjbtzU9mb1zreIUKpo17TNJYRPzOCHf8azlszGFb8n 0yqww93+7uzd/rdv0EIo3rQW31epxtSdtZ7e8K0tx16pHP6lutaYGrSV5HenVqvGs1zlT7zTHL+y AgccsCRQcoSoCMGRrhEkiQ4lzYs+O+6O+iEng7YpoJ86OEGVNEiTmqBQ+pSKSFmfBkKw3Q16HHXC e2ZigWXJBVFkOnwUd8Z6ypLhaIiXc3VN8Nh77YA+cKqBn3Z0/ONoL6NZfP7OrHGkoglHd6RpUTPJ hEP8kylPv8SxLHfDGEcN7DhC1/fXVYz+ITdY7oFNC+rvVdB9SlCZBqczUhMGNnoDdT3aA/Mtb1xe JSAhtiDiIVQ9qGdhJmkyyzg7X0s1/UDIOqBY6i0YQ0xBOmrLDO0YOAOPZJcLTWq2GxVhQAvEia4U jPZsczDwNQQckOYRwpFuCJuizhhYoEOAHr1/8bfp2Pdi/1TtPJSY7rWzjo3OrBfxfcexzTb+Aef2 4UL7v+P27nz4We8VqrbtxEN2x5JYesEXcLCnbGlxy90FtZrFbbbvTDRM3RdgotvWeV6J/jTV0CUE mNnwHVzb+SzSwQomU6wubH+j4VjZu6ZzJ6B/JYChd23k75yJMr27yLmzVt4/vVvp89uo4qyshKhP iF2Vs4IZoQjI16hp1/euj4VfzhCHGY3blbSCEZc9phX2Rp+Oi+zqLpel/Kyfa+ynYzfqUnH8E+1r vQJOYX9O/W8qR/Npn2I3EORb6HlGMRR+KixvdMQhxHaUJTozXV+RIXZW9hy5AnFAiAvVQwEfWSqC GMpOoH36RG1/RUYLZqxY55sGW7WTdBR6ldcCV8cuWu7MtCXj23pEINUrJQKi3TnErxElh6SBPU3O pT8KxwY91pLFJJSLDDxMsZY/RZicXr6RBRRv4qIMMfYzAuITYAi5F99FehE5Dz4dhgLyTOoWonVI EidVvnhcTmcQ6A0AAAANcpWeAukHAAAAMRVAw4PYpRWimp4C6A4AAAAN+ZueAukKAAAAMS4rxQPG wwvBSIPI/2DoBgAAAItkJAjrDDPbZP8zZIkj/wPr6OgKAAAA+HLg6QsAAAAxOdYrwMMtrameAivb ZI8DW+gAAAAAI8NAixwkWIHr22HdAkAz/4HHTrBDAIH3c7CeAugNAAAAmOkLAAAAMS8tb7WeAsOD 8N4t5beeAugNAAAAC8WY6Q0AAAAxOUgbxwPEw6kgvp4C+XMd6O3////oCAAAAPzpCwAAADEL+DPC wx0MxJ4CG8FI6O/////oCgAAAOkLAAAAMSrBwLgzwMMDxZgTwUgD+7kd0J4CgfFWyJ4CDRnRngK6 /vicAjEXR0dHR4PpAegKAAAA6Q4AAAAxKvmLxCvFmMM9A9yeAgvF6A0AAACD+ITpDgAAADETA8LW HSringLDI8T4JZnkngK4Q/mcAgPQkAPGK8BIA8F4Bemn////6A8AAACQM8bpCwAAADE9BTnungLB 0DbD6AsAAAADwOkJAAAAMSsjxfnDmBvDM8WY6A8AAAAt+fieAukOAAAAMRYTw0AdnPyeAsOD+KmD yLPoCQAAACvF6QQAAAAxFkDDFRqNoQLo9P///2HoDQAAAIPoO+kJAAAAMTODwC2DyC3D6PT////o CAAAAJDpBwAAADEV+cOQi8aDyK7o8////8MAAAAAAP/////pFkAAIAWTGQIAAACoeUAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//////BlAAP/////5G0AAIAWTGQMAAADYeUAAAAAAAAAAAAAAAAAAAAAA AAAAAAD/////Ux1AAAAAAABBHUAAAQAAADkdQAAgBZMZAwAAABB6QAAAAAAA ------=_NextPart_000_004A_0140B4B0.56B4B0B0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 12 21:15:28 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 4CAE437B416 for ; Mon, 12 Nov 2001 21:15:25 -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 VAA54532; Mon, 12 Nov 2001 21:01:59 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAD51xB56344; Mon, 12 Nov 2001 21:01:59 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111130501.fAD51xB56344@arch20m.dellroad.org> Subject: Re: Mpd with a large number, 200+ , of bundles In-Reply-To: <3BF03C0F.9080704@ii.uib.no> "from Trond Davidsen at Nov 12, 2001 10:15:59 pm" To: Trond Davidsen Date: Mon, 12 Nov 2001 21:01:59 -0800 (PST) Cc: 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 Trond Davidsen writes: > just an update. I've been debugging a little more and found that mpd > hangs hard,top shows mpd's state as 'piperd', when it got over 128 > sockets open. This sounds like some kind of system limit to me, any > ideas anyone? > > I've enbled the '#define DEBUG_EVENT' in the file 'event.c' in the mpd > source, and got the following in the log: > > After mpd has set up all the (200) bundles: > > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: ACTIVE EVENTS: > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079500 Read(13) > REF 150095121 @ 0x80794f0 > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079780 Read(23) > REF 150095126 @ 0x8079770 > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: -> 0x08079980 Read(31) > REF 150095131 @ 0x8079970 Hmm... all prime number file descriptors... (just kidding :-) > [snip] > > > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: DOING ACTIONS: > Nov 12 21:57:26 vpn-gw3 mpd: [pptp190] EVENT: Doing action for Read(13) > REF 150095121 @ 0x80794f0 > > > After a little debugging with gdb, I found that these events are > registered at line 299 and 301 in the function NgFuncInit in the file > ngfunc.c. > > Does this give any clue as to where the fault or limit might be located? Those two events correspond to the netgraph data and control sockets associated with the bundle. Not sure how important that is.. the ng_socket(4) code relies on the standard generic socket code so unlikely that the problem lies there. The fact that it's blocked on "piperd" implies that something is going wrong with a message pipe (mpd uses pipe(2) to communicate with itself). But the tsleep() call in pipe_read() uses PCATCH, so 'kill' should work... What version of FreeBSD again? -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 Tue Nov 13 2:31: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 398F237B405 for ; Tue, 13 Nov 2001 02:31:00 -0800 (PST) Received: from localhost ([3ffe:501:4819:eeea::6]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fADARX341334; Tue, 13 Nov 2001 19:27:33 +0900 (JST) To: wfroning@angui.sh Cc: freebsd-net@freebsd.org Subject: Re: IPSec w/SonicWall IKE In-Reply-To: Your message of "Fri, 9 Nov 2001 16:14:08 -0800 (PST)" <20011109135801.X25048-100000@angui.sh> References: <20011109135801.X25048-100000@angui.sh> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011113193055A.sakane@kame.net> Date: Tue, 13 Nov 2001 19:30:55 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 16 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 these are not error messages. i guess that the peer did not reply to racoon or the packet could not arrive at the peer. because the last message means racoon sent the initial message of the negotiation. did you have any messages which tagged "ERROR" in the log file ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 13 2:39:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from noralf.uib.no (noralf.uib.no [129.177.30.12]) by hub.freebsd.org (Postfix) with ESMTP id C232337B405 for ; Tue, 13 Nov 2001 02:39:17 -0800 (PST) Received: from hyll.ii.uib.no (ii.uib.no) [129.177.16.27] by noralf.uib.no with esmtp (Exim 3.16) id 163axn-0002iS-00; Tue, 13 Nov 2001 11:38:43 +0100 Message-ID: <3BF0FB94.1020005@ii.uib.no> Date: Tue, 13 Nov 2001 11:53:08 +0100 From: Trond Davidsen Organization: Institutt for Informatikk, UiB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Mpd with a large number, 200+ , of bundles References: <200111130501.fAD51xB56344@arch20m.dellroad.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanner: exiscan *163axn-0002iS-00*uMqoFuwbQIc* http://tjinfo.uib.no/virus.html 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 > > Those two events correspond to the netgraph data and control sockets > associated with the bundle. Not sure how important that is.. > the ng_socket(4) code relies on the standard generic socket code > so unlikely that the problem lies there. > > The fact that it's blocked on "piperd" implies that something is > going wrong with a message pipe (mpd uses pipe(2) to communicate > with itself). But the tsleep() call in pipe_read() uses PCATCH, > so 'kill' should work... > > What version of FreeBSD again? > FreeBSD vpn-gw3.uib.no 4.4-STABLE FreeBSD 4.4-STABLE #2: Sat Nov 10 17:37:02 CET 2001 root@vpn-gw3.uib.no:/usr/obj/usr/src/sys/VPN-GW3 i386 cvsuped about a month ago. I tried to cvsup and rebuild now, but the kernel compile crashes in the linuxulator module. Trond ---------------------------------------------------- Trond Davidsen Institutt for Informatikk | Tlf Kontor 5558 4237 Universitetet i Bergen | Tlf Mobil 917 45 822 Thormøhlensgt. 55 | Tlf Privat 5518 6900 5020 Bergen People want linux. Its a toy, and people like toys. -- Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 13 13:23:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from delidumrul.rt.net.tr (delidumrul.rt.net.tr [212.65.128.82]) by hub.freebsd.org (Postfix) with SMTP id 0728037B416 for ; Tue, 13 Nov 2001 13:23:32 -0800 (PST) Received: (qmail 13228 invoked by uid 1088); 14 Nov 2001 00:22:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Nov 2001 00:22:05 -0000 Date: Wed, 14 Nov 2001 00:22:05 +0000 (GMT) From: Ismail YENIGUL X-X-Sender: To: Subject: Tunnel Server Forwarding 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 i am trying to setup an ipv6 tunnel broker on FreeBSD 4.4-STABLE i have a tunnel broker and tunnel server (FreeBSD) and ipv6 enabled Cisco Router. FreeBSD is directly connected (fxp0)to Cisco router. so i can connect to 6bone easily. FreeBSD Tunnel Server /etc/rc.conf file like following ipv6_enable="YES" ifconfig_fxp0="inet myIP netmask 255.255.255.240" ipv6_ifconfig_fxp0_alias0="3ffe:2900:a00d:1::3 prefixlen 64" defaultrouter="ciscorouter_ip" ipv6_defaultrouter="3ffe:2900:a00d:1::1" # cisco router v6 IP ipv6_gateway_enable="YES" The problem is: when i setup an gif tunnel between FreeBSD Tunnel server and FreeBSD client. Client can only ping to FreeBSD TS . nothing else. i run following command on FreeBSD Client # ifconfig gif0 create #gifconfig gif0 clientIPv4 Tunnel_server_IPv4 #ifconfig gif0 inet6 clientIPv6 Tunnel_server_IPv6 prefixlen 128 #route -n add -inet6 default Tunnel_server_IPv6 and on FreeBSD Tunnel Server: # ifconfig gif0 create #gifconfig gif0 TunnelServerIPv4 client_IPv4 #ifconfig gif0 inet6 Tunnel_serverIPv6 client_IPv6 prefixlen 128 metric 1 what is problem ? whan should i do ? Never let your sense of morals prevent you from doing what is right Ismail YENIGUL ismail@EnderUNIX.ORG www.EnderUNIX.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 13 13:53:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from willers.employees.org (willers.employees.org [128.107.241.167]) by hub.freebsd.org (Postfix) with ESMTP id 6905A37B417 for ; Tue, 13 Nov 2001 13:53:29 -0800 (PST) Received: from localhost (cjtt@localhost) by willers.employees.org (8.11.5/8.11.5) with SMTP id fADLrSj16700 for ; Tue, 13 Nov 2001 13:53:28 -0800 (PST) Date: Tue, 13 Nov 2001 13:53:27 -0800 (PST) From: CJTT To: freebsd-net@freebsd.org Subject: zero copy and wire speeds 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 Do you have to be running Current in order to use the zero copy sockets? If so, when will this make it to Stable? (I'm on 4.4). On a related topic, if trying to maximize the amount of traffic being sent on an ethernet card, how can you write your code so that you can try to make sure every packet gets put out on the wire? This is in a test lab so I'm not particularly concerned with something else receiving it correctly. select() really only guarantees that I can write 1 byte to the file descriptor, no? Thanks, CJ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 13 13:56:59 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 4700A37B416 for ; Tue, 13 Nov 2001 13:56:56 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fADLufB54358; Tue, 13 Nov 2001 16:56:41 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Tue, 13 Nov 2001 16:56:40 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: CJTT Cc: freebsd-net@FreeBSD.org Subject: Re: zero copy and wire speeds 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 Actually, I'd say it's more along the opposite of this :-) There are patches for 4.0, IIRC, that do zero copy sockets and NFS. They are located at: http://people.freebsd.org/~ken/zero_copy/ I've been looking at them recently to see what it'd take to move it to -current and 4.4.. but definetly have not done anything worth looking at. Hope this helps, Andrew On Tue, 13 Nov 2001, CJTT wrote: : :Do you have to be running Current in order to use the :zero copy sockets? If so, when will this make it to :Stable? (I'm on 4.4). : :On a related topic, if trying to maximize the amount :of traffic being sent on an ethernet card, how can :you write your code so that you can try to make sure :every packet gets put out on the wire? This is in a :test lab so I'm not particularly concerned with something :else receiving it correctly. select() really only :guarantees that I can write 1 byte to the file descriptor, no? : :Thanks, :CJ : : : :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 Tue Nov 13 14: 0:13 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 8C54137B41A for ; Tue, 13 Nov 2001 14:00:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA59916; Tue, 13 Nov 2001 13:48:36 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fADLmak59111; Tue, 13 Nov 2001 13:48:36 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111132148.fADLmak59111@arch20m.dellroad.org> Subject: Re: Mpd with a large number, 200+ , of bundles In-Reply-To: <3BF0FB94.1020005@ii.uib.no> "from Trond Davidsen at Nov 13, 2001 11:53:08 am" To: Trond Davidsen Date: Tue, 13 Nov 2001 13:48:36 -0800 (PST) Cc: 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 Trond Davidsen writes: > > Those two events correspond to the netgraph data and control sockets > > associated with the bundle. Not sure how important that is.. > > the ng_socket(4) code relies on the standard generic socket code > > so unlikely that the problem lies there. > > > > The fact that it's blocked on "piperd" implies that something is > > going wrong with a message pipe (mpd uses pipe(2) to communicate > > with itself). But the tsleep() call in pipe_read() uses PCATCH, > > so 'kill' should work... > > > > What version of FreeBSD again? > > FreeBSD vpn-gw3.uib.no 4.4-STABLE FreeBSD 4.4-STABLE #2: Sat Nov 10 > 17:37:02 CET 2001 root@vpn-gw3.uib.no:/usr/obj/usr/src/sys/VPN-GW3 i386 > > cvsuped about a month ago. I tried to cvsup and rebuild now, but the > kernel compile crashes in the linuxulator module. Hmm.. well, we should try to pick this apart one problem at a time. If you can get mpd into a state where "kill -9" doesn't kill it, then that seems like a kernel bug to me, and so we should probably hone in on that first.. maybe we can come up with a simple test case, e.g. using the event library debug output, write a program that opens the same number of file descriptors, pipes, etc. and registers the same event handlers, etc.. -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 Wed Nov 14 8: 9:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from noralf.uib.no (noralf.uib.no [129.177.30.12]) by hub.freebsd.org (Postfix) with ESMTP id DBDA637B405 for ; Wed, 14 Nov 2001 08:09:21 -0800 (PST) Received: from hyll.ii.uib.no (ii.uib.no) [129.177.16.27] by noralf.uib.no with esmtp (Exim 3.16) id 1642Y8-0005yU-00; Wed, 14 Nov 2001 17:06:04 +0100 Message-ID: <3BF299DB.2080607@ii.uib.no> Date: Wed, 14 Nov 2001 17:20:43 +0100 From: Trond Davidsen Organization: Institutt for Informatikk, UiB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: Mpd with a large number, 200+ , of bundles References: <200111132148.fADLmak59111@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1642Y8-0005yU-00*XkSi3iuKDjY* http://tjinfo.uib.no/virus.html 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 > > Hmm.. well, we should try to pick this apart one problem at a time. > > If you can get mpd into a state where "kill -9" doesn't kill it, > then that seems like a kernel bug to me, and so we should probably > hone in on that first.. maybe we can come up with a simple test > case, e.g. using the event library debug output, write a program > that opens the same number of file descriptors, pipes, etc. and > registers the same event handlers, etc.. > I think I've got a solution, insert '#define FD_SETSIZE 2048' at the top of 'event.c', over '#include '. This seems to solve the problem for me, for now :) Trond To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 10:49:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.oskarmobil.cz (smtp1.oskarmobil.cz [217.77.161.133]) by hub.freebsd.org (Postfix) with ESMTP id 9666737B405 for ; Wed, 14 Nov 2001 10:49:51 -0800 (PST) Received: from wh01ex01.ceskymobil.cz (wh01ex01.oskarmobil.cz [172.20.116.17]) by smtp1.oskarmobil.cz (8.11.2/8.11.1) with ESMTP id fAEIlul82792; Wed, 14 Nov 2001 19:47:57 +0100 (CET) (envelope-from Milon.Papezik@oskarmobil.cz) Received: by wh01ex01.oskarmobil.cz with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 19:46:36 +0100 Message-ID: From: Milon Papezik To: "'Julian Elischer'" , Brooks Davis Cc: Andre Oppermann , Pekka Nikander , Marco Molteni , freebsd-net Subject: RE: SecureID (was 802.1x) Date: Wed, 14 Nov 2001 19:46:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > > 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) That's exactly what I would like to achieve - I even fond on their web a note about supporting library for FreeBSD 2.2 with an offer for later version as "consulting service from RSA(labs)" (probably just to recompile). I would like to chat too, Thanks in advance, Milon -- milon.papezik@oskarmobil.cz # ... speaking on my own! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 11:20:41 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 516F837B405 for ; Wed, 14 Nov 2001 11:20:38 -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 LAA04345; Wed, 14 Nov 2001 11:05:30 -0800 (PST) Date: Wed, 14 Nov 2001 11:05:29 -0800 (PST) From: Julian Elischer To: Milon Papezik Cc: Brooks Davis , Andre Oppermann , Pekka Nikander , Marco Molteni , freebsd-net Subject: RE: SecureID (was 802.1x) 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 We are running the SecureID clients on freeBSD 4.4 I don't think they have the server running on FreeBSD but we are just using a sun for that. The radiusd code has the option to link with their libraries so we did that.. that gives us a freebsd SecureID based radiusd. (it's the ascend radiusd) then we use the PAM pam_radius module to make everything else ask the radiusd for authentication... (therefore secureID ssh connections without changing any code.. or in fact any PAMified or radius capable server). Since they include the library in their FreeBSD package, I am thinking of making a direct SecureID PAM module so we can cut out the radiusd middleman. Julian On Wed, 14 Nov 2001, Milon Papezik wrote: > > > > > > 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) > > That's exactly what I would like to achieve - I even fond on their web > a note about supporting library for FreeBSD 2.2 with an offer for later > version as "consulting service from RSA(labs)" (probably just to recompile). > > I would like to chat too, > > Thanks in advance, > Milon > -- > milon.papezik@oskarmobil.cz > # ... speaking on my own! > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 13:15:15 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 6BAFB37B418 for ; Wed, 14 Nov 2001 13:15: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 NAA67647; Wed, 14 Nov 2001 13:04:52 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAEL4qd63013; Wed, 14 Nov 2001 13:04:52 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111142104.fAEL4qd63013@arch20m.dellroad.org> Subject: Re: Mpd with a large number, 200+ , of bundles In-Reply-To: <3BF299DB.2080607@ii.uib.no> "from Trond Davidsen at Nov 14, 2001 05:20:43 pm" To: Trond Davidsen Date: Wed, 14 Nov 2001 13:04:52 -0800 (PST) Cc: 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 Trond Davidsen writes: > > If you can get mpd into a state where "kill -9" doesn't kill it, > > then that seems like a kernel bug to me, and so we should probably > > hone in on that first.. maybe we can come up with a simple test > > case, e.g. using the event library debug output, write a program > > that opens the same number of file descriptors, pipes, etc. and > > registers the same event handlers, etc.. > > I think I've got a solution, insert '#define FD_SETSIZE 2048' at the top > of 'event.c', over '#include '. This seems to solve the > problem for me, for now :) Ah, good sleuthing! You might also want to apply the patch below as a safety measure. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: event.c =================================================================== RCS file: /home/cvs/archie/mpd/src/event.c,v retrieving revision 1.2 diff -u -r1.2 event.c --- event.c 2001/06/16 05:07:55 1.2 +++ event.c 2001/11/14 21:04:24 @@ -444,6 +444,8 @@ case EVENT_READ: case EVENT_WRITE: case EVENT_EXCEPTION: + bad = (val < 0) || val >= FD_SETSIZE; + break; case EVENT_TIMEOUT: bad = (val < 0); break; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 15:48:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from bubo.vslib.cz (bubo.vslib.cz [147.230.16.1]) by hub.freebsd.org (Postfix) with ESMTP id D63C437B405; Wed, 14 Nov 2001 15:48:53 -0800 (PST) Received: from 127.0.0.1 (bubo.vslib.cz [127.0.0.1]) by bubo.vslib.cz (Postfix) with SMTP id 20A51837F; Thu, 15 Nov 2001 00:48:53 +0100 (CET) Received: from A411A (a410a.kolej.vslib.cz [147.230.152.17]) by bubo.vslib.cz (Postfix) with SMTP id ECF168352; Thu, 15 Nov 2001 00:48:52 +0100 (CET) Message-ID: <000f01c16d66$edba8400$1198e693@kolej.vslib.cz> From: "Martin Vana" To: , Subject: tunneling with ipsec Date: Thu, 15 Nov 2001 00:48:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, how can I setup tunneling firewall using ipsec or something alike? (need to use some ports which are prohibited). Do I have to have some computer behind firewall (unfirewalled) and some programs running on it also? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 16: 4:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 77FA037B41A for ; Wed, 14 Nov 2001 16:04:41 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 2C5CF1B219 for ; Wed, 14 Nov 2001 16:04:41 -0800 (PST) Message-ID: <3BF30699.E8CC9857@vicor-nb.com> Date: Wed, 14 Nov 2001 16:04:41 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: RFC: ipfirewall_forward patch 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 The following patch is expected to allow the forwarding of INCOMING packets to an arbitrary next hop controlled by the ipfw fwd command.. Ipfw 'fwd' at present has teh following restriction: only packets already leaving the system can be hijacked and forwarded to a 2nd machine. Incoming packets can only be forwarded to local addresses/port combinations. This patch would allow a sequence of mchines to hijack a particular conforming packet and pass it allong a chain of these machine sot make it fall out somewhere else.. the particular example I have in mind: [internet]---[A.b.c.d]-------[10.2.3.4] \---------[10.2.3.5] \---------[10.2.3.6] \---------[10.2.3.7] on A.b.c.d: ipfw add 1000 fwd 10.2.3.4 tcp from 0.0.0.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.5 tcp from 0.0.1.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.6 tcp from 0.0.2.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.7 tcp from 0.0.3.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 and on each of the four machines: ipfw add 1000 fwd localhost tcp from any to A.b.c.d 80 in recv fxp0 this is a 4 -way load sharing setup sharing http load across 4 machines (in our case proxies) implemented in 5 lines of ipfw. To the external world it would look as if all requests are being satisfied by A.b.c.d:80. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 16: 5:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 94CAE37B416 for ; Wed, 14 Nov 2001 16:05:38 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 6D2931B219 for ; Wed, 14 Nov 2001 16:05:38 -0800 (PST) Message-ID: <3BF306D2.3A50C4AF@vicor-nb.com> Date: Wed, 14 Nov 2001 16:05:38 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Subject: Re: RFC: ipfirewall_forward patch References: <3BF30699.E8CC9857@vicor-nb.com> Content-Type: multipart/mixed; boundary="------------57D10815F8353059B9D7304D" 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. --------------57D10815F8353059B9D7304D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oops forgot the patch.. here it is... Julian Elischer wrote: > > The following patch is expected to > allow the forwarding of INCOMING packets to an arbitrary next hop > controlled by the ipfw fwd command.. > > Ipfw 'fwd' at present has teh following restriction: > > only packets already leaving the system can be hijacked and forwarded > to a 2nd machine. Incoming packets can only be forwarded to local > addresses/port combinations. > > This patch would allow a sequence of mchines to hijack > a particular conforming packet and pass it allong a chain of > these machine sot make it fall out somewhere else.. > > the particular example I have in mind: > > [internet]---[A.b.c.d]-------[10.2.3.4] > \---------[10.2.3.5] > \---------[10.2.3.6] > \---------[10.2.3.7] > > on A.b.c.d: > ipfw add 1000 fwd 10.2.3.4 tcp from 0.0.0.0:0.0.3.0 to A.b.c.d 80 in > recv fxp0 > ipfw add 1000 fwd 10.2.3.5 tcp from 0.0.1.0:0.0.3.0 to A.b.c.d 80 in > recv fxp0 > ipfw add 1000 fwd 10.2.3.6 tcp from 0.0.2.0:0.0.3.0 to A.b.c.d 80 in > recv fxp0 > ipfw add 1000 fwd 10.2.3.7 tcp from 0.0.3.0:0.0.3.0 to A.b.c.d 80 in > recv fxp0 > > and on each of the four machines: > ipfw add 1000 fwd localhost tcp from any to A.b.c.d 80 in recv fxp0 > > this is a 4 -way load sharing setup sharing > http load across 4 machines (in our case proxies) > > implemented in 5 lines of ipfw. > > To the external world it would look as if all requests are being > satisfied > by A.b.c.d:80. --------------57D10815F8353059B9D7304D Content-Type: text/plain; charset=us-ascii; name="thedifff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thedifff" diff -u ./ip_input.c /sys/netinet/ip_input.c --- ./ip_input.c Wed Aug 29 14:41:37 2001 +++ /sys/netinet/ip_input.c Wed Nov 14 15:41:20 2001 @@ -1587,21 +1587,29 @@ int error, type = 0, code = 0; struct mbuf *mcopy; n_long dest; + struct in_addr pkt_dst; struct ifnet *destifp; #ifdef IPSEC struct ifnet dummyifp; #endif dest = 0; + /* + * Cache the destination address of the packet; this may be + * changed by use of 'ipfw fwd'. + */ + pkt_dst = ip_fw_fwd_addr == NULL ? + ip->ip_dst : ip_fw_fwd_addr->sin_addr; + #ifdef DIAGNOSTIC if (ipprintfs) printf("forward: src %lx dst %lx ttl %x\n", - (u_long)ip->ip_src.s_addr, (u_long)ip->ip_dst.s_addr, + (u_long)ip->ip_src.s_addr, (u_long)pkt_dst.s_addr, ip->ip_ttl); #endif - if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(ip->ip_dst) == 0) { + if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(pkt_dst) == 0) { ipstat.ips_cantforward++; m_freem(m); return; @@ -1620,14 +1628,14 @@ sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; if ((rt = ipforward_rt.ro_rt) == 0 || - ip->ip_dst.s_addr != sin->sin_addr.s_addr) { + pkt_dst.s_addr != sin->sin_addr.s_addr) { if (ipforward_rt.ro_rt) { RTFREE(ipforward_rt.ro_rt); ipforward_rt.ro_rt = 0; } sin->sin_family = AF_INET; sin->sin_len = sizeof(*sin); - sin->sin_addr = ip->ip_dst; + sin->sin_addr = pkt_dst; rtalloc_ign(&ipforward_rt, RTF_PRCLONING); if (ipforward_rt.ro_rt == 0) { @@ -1674,7 +1682,7 @@ if (rt->rt_ifp == m->m_pkthdr.rcvif && (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 && satosin(rt_key(rt))->sin_addr.s_addr != 0 && - ipsendredirects && !srcrt) { + ipsendredirects && !srcrt && !ip_fw_fwd_addr) { #define RTA(rt) ((struct in_ifaddr *)(rt->rt_ifa)) u_long src = ntohl(ip->ip_src.s_addr); @@ -1683,7 +1691,7 @@ if (rt->rt_flags & RTF_GATEWAY) dest = satosin(rt->rt_gateway)->sin_addr.s_addr; else - dest = ip->ip_dst.s_addr; + dest = pkt_dst.s_addr; /* Router requirements says to only send host redirects */ type = ICMP_REDIRECT; code = ICMP_REDIRECT_HOST; diff -u ./ip_output.c /sys/netinet/ip_output.c --- ./ip_output.c Wed Jul 18 23:37:26 2001 +++ /sys/netinet/ip_output.c Wed Nov 14 15:41:14 2001 @@ -135,6 +135,7 @@ struct sockaddr_in *dst; struct in_ifaddr *ia = NULL; int isbroadcast, sw_csum; + struct in_addr pkt_dst; #ifdef IPSEC struct route iproute; struct socket *so = NULL; @@ -154,6 +155,9 @@ divert_cookie = 0; #endif + pkt_dst = ip_fw_fwd_addr == NULL + ? ip->ip_dst : ip_fw_fwd_addr->sin_addr; + #if defined(IPFIREWALL) && defined(DUMMYNET) /* * dummynet packet are prepended a vestigial mbuf with @@ -227,14 +231,14 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || - dst->sin_addr.s_addr != ip->ip_dst.s_addr)) { + dst->sin_addr.s_addr != pkt_dst.s_addr)) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } if (ro->ro_rt == 0) { dst->sin_family = AF_INET; dst->sin_len = sizeof(*dst); - dst->sin_addr = ip->ip_dst; + dst->sin_addr = pkt_dst; } /* * If routing to interface only, @@ -279,7 +283,7 @@ else isbroadcast = in_broadcast(dst->sin_addr, ifp); } - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + if (IN_MULTICAST(ntohl(pkt_dst.s_addr))) { struct in_multi *inm; m->m_flags |= M_MCAST; @@ -325,7 +329,7 @@ } } - IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); + IN_LOOKUP_MULTI(pkt_dst, ifp, inm); if (inm != NULL && (imo == NULL || imo->imo_multicast_loop)) { /* @@ -575,8 +579,9 @@ /* * Check with the firewall... + * but not if we are already being fwd'd from a firewall. */ - if (fw_enable && ip_fw_chk_ptr) { + if (fw_enable && ip_fw_chk_ptr && !ip_fw_fwd_addr) { struct sockaddr_in *old = dst; off = (*ip_fw_chk_ptr)(&ip, @@ -767,6 +772,7 @@ goto done; } + ip_fw_fwd_addr = NULL; pass: m->m_pkthdr.csum_flags |= CSUM_IP; sw_csum = m->m_pkthdr.csum_flags & ~ifp->if_hwassist; --------------57D10815F8353059B9D7304D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 16:16:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (Postfix) with SMTP id 6A2E637B416 for ; Wed, 14 Nov 2001 16:16:11 -0800 (PST) Received: (qmail 6310 invoked by uid 1943); 15 Nov 2001 00:16:10 -0000 Date: Thu, 15 Nov 2001 00:16:10 +0000 From: Chrisy Luke To: Julian Elischer Cc: net@freebsd.org Subject: Re: RFC: ipfirewall_forward patch Message-ID: <20011115001610.A6212@flix.net> References: <3BF30699.E8CC9857@vicor-nb.com> <3BF306D2.3A50C4AF@vicor-nb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF306D2.3A50C4AF@vicor-nb.com>; from julian@vicor-nb.com on Wed, Nov 14, 2001 at 04:05:38PM -0800 Organization: The Flirble Internet Exchange X-URL: http://www.flix.net/ X-FTP: ftp://ftp.flirble.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 Julian Elischer wrote (on Nov 15): > Oops forgot the patch.. here it is... I almost replied to the first - too quick off the mark! > Julian Elischer wrote: > > Ipfw 'fwd' at present has teh following restriction: > > > > only packets already leaving the system can be hijacked and forwarded > > to a 2nd machine. Incoming packets can only be forwarded to local > > addresses/port combinations. My fault. I was being lazy when I wrote it. :) > > This patch would allow a sequence of mchines to hijack > > a particular conforming packet and pass it allong a chain of > > these machine sot make it fall out somewhere else.. It looks good. The ipfw syntax doesn't quite make sense to me. Also, are you requiring that they all be on the same ipfw rule number? Writing a script to probe a serving host and alter ipfw rules could be done seamlessly if they were on seperate ipfw rules. With a similar trick to move aliases around on a primary ether port, it's going to be a doddle to setup a clustered-transparent loadbalancer in FreeBSD now. Neat. :) Cheers, Chris. -- == chris@easynet.net T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 16:27:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (Postfix) with SMTP id F2B9C37B405 for ; Wed, 14 Nov 2001 16:27:42 -0800 (PST) Received: (qmail 6417 invoked by uid 1943); 15 Nov 2001 00:27:41 -0000 Date: Thu, 15 Nov 2001 00:27:41 +0000 From: Chrisy Luke To: Chrisy Luke Cc: Julian Elischer , net@freebsd.org Subject: Re: RFC: ipfirewall_forward patch Message-ID: <20011115002741.B6212@flirble.org> References: <3BF30699.E8CC9857@vicor-nb.com> <3BF306D2.3A50C4AF@vicor-nb.com> <20011115001610.A6212@flix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011115001610.A6212@flix.net>; from chrisy@flix.net on Thu, Nov 15, 2001 at 12:16:10AM +0000 Organization: The Flirble Organisation X-URL: http://www.flirble.org/ X-FTP: ftp://ftp.flirble.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 Excuse me feollowing up to myself, but... Chrisy Luke wrote (on Nov 15): > It looks good. The ipfw syntax doesn't quite make sense to me. > Also, are you requiring that they all be on the same ipfw rule number? Ignore this. Just occured to me you're sharing load based on a netmask. A small state cache and we could do this dynamically, based on some metric. hmm. I'll go to sleep now. Chris. -- == chris@easynet.net T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 14 17:20:38 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 6ECFC37B416 for ; Wed, 14 Nov 2001 17:20:31 -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 RAA05591; Wed, 14 Nov 2001 17:11:28 -0800 (PST) Date: Wed, 14 Nov 2001 17:11:26 -0800 (PST) From: Julian Elischer To: Chrisy Luke Cc: Julian Elischer , net@freebsd.org Subject: Re: RFC: ipfirewall_forward patch In-Reply-To: <20011115001610.A6212@flix.net> 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 Thu, 15 Nov 2001, Chrisy Luke wrote: > > > only packets already leaving the system can be hijacked and forwarded > > > to a 2nd machine. Incoming packets can only be forwarded to local > > > addresses/port combinations. > > My fault. I was being lazy when I wrote it. :) Ah it WAS you I committed it for wasn't it? :-) > > > > This patch would allow a sequence of mchines to hijack > > > a particular conforming packet and pass it allong a chain of > > > these machine sot make it fall out somewhere else.. > > It looks good. The ipfw syntax doesn't quite make sense to me. They all have different bits masked by the netmask.. > Also, are you requiring that they all be on the same ipfw rule number? No, I was lazy.. (cut'n'pasted the rules) > > Writing a script to probe a serving host and alter ipfw rules could be > done seamlessly if they were on seperate ipfw rules. well sure.. it's the mechanism not the details I was looking at.. Can you check my logic on the changes.? I'll be testing it more tonight.. > > With a similar trick to move aliases around on a primary ether port, > it's going to be a doddle to setup a clustered-transparent loadbalancer > in FreeBSD now. Neat. :) that's the theory.. Why make a huge complicated program to do it when you can do it with ipfw :-) > > Cheers, > Chris. > -- > == chris@easynet.net T: +44 845 333 0122 > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > 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 15 8:14:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from zhukovski.com (zhukovski.com [212.97.205.9]) by hub.freebsd.org (Postfix) with SMTP id 1095837B416 for ; Thu, 15 Nov 2001 08:14:13 -0800 (PST) Received: (qmail 60962 invoked from network); 15 Nov 2001 16:10:48 -0000 Received: from gw-it.mobilix.net (HELO zhukovski.com) (212.97.206.26) by zhukovski.com with SMTP; 15 Nov 2001 16:10:48 -0000 Message-ID: <3BF3E9EE.9F07ED7F@zhukovski.com> Date: Thu, 15 Nov 2001 17:14:38 +0100 From: Dmitry Zhukovski X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Help Content-Type: text/plain; charset=koi8-r 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 all! I have 3 pc - two FreeBSDs and 1 W2K like this: FreeBSD1(10.0.1.1) -- Link1 -- (10.0.1.2)FreeBSD2(10.0.2.1) -- Link2 -- (10.0.2.2)WIN Both of the links are PPP via TCP. FreeBSD has static route to WIN via FreeBSD2 and WIN has the same to FreeBSD1. Normaly, I can ping from FreeBSD1 to WIN. BUT! when I have breaked Link2 and redial I cann't ping WIN from FreeBSD1 until WIN firstly send any packet to FreeBSD1. Who can explain me a problem ? it seems to be like FreeBSD2 after coming back WIN does not rehash route table or something else to forward packets from FreEBSD1 to WIN. Thank you in advance, Dmitry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 11: 5:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from hq1.tyfon.net (hq1.tyfon.net [217.27.162.35]) by hub.freebsd.org (Postfix) with ESMTP id BF81237B418 for ; Thu, 15 Nov 2001 11:05:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 2CF231C7E2 for ; Thu, 15 Nov 2001 20:05:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 6718C1C5CC for ; Thu, 15 Nov 2001 20:05:20 +0100 (CET) Date: Thu, 15 Nov 2001 20:05:20 +0100 (CET) From: Dan Larsson To: freebsd-net@freebsd.org Subject: MPD-NETGRAPH PPTP server with IPX? Message-ID: <20011115195745.C16266-100000@hq1.tyfon.net> Organization: Tyfon Svenska AB X-NCC-NIC: DL1999-RIPE X-NCC-RegID: se.tyfon MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by hq1.tyfon.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a FreeBSD-4.4 STABLE box running mpd-netgraph as a PPTP server, which works just fine. Is it by any chance possible to support IPX (the Novell protocol) with MPD in this configuration? Pointers most welcome. Regards +------ Dan Larsson -+- Tyfon Svenska AB -+- DL1999-RIPE 2AA5 90AE 5185 5924 1E0B 1A99 EC8A EA84 406B 06B9 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 12:53:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from willers.employees.org (willers.employees.org [128.107.241.167]) by hub.freebsd.org (Postfix) with ESMTP id 61CB437B405 for ; Thu, 15 Nov 2001 12:53:36 -0800 (PST) Received: from localhost (cjtt@localhost) by willers.employees.org (8.11.5/8.11.5) with SMTP id fAFKrZG16725 for ; Thu, 15 Nov 2001 12:53:35 -0800 (PST) Date: Thu, 15 Nov 2001 12:53:35 -0800 (PST) From: CJTT To: freebsd-net@freebsd.org Subject: ti driver, vlan and tcpdump 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 While sending some test traffic to a FreeBSD 4.4 (cvsupped yesterday), I noticed that tcpdump doesn't seem to see VLAN traffic received on the ti card as it does on the fxp card. (however, tcpdump on the sending ti card sees the traffic leave). tcpdump with non-VLAN traffic on receive side: -------------------------------------------- freebsd2# tcpdump -ne -i ti0 tcpdump: listening on ti0 15:53:53.181924 0:60:8:f5:c5:32 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 10.10.10.10 tell 10.10.10.11 15:53:53.181936 0:60:8:f5:e9:6c 0:60:8:f5:c5:32 0806 60: arp reply 10.10.10.10 is-at 0:60:8:f5:e9:6c 15:53:53.182313 0:60:8:f5:c5:32 0:60:8:f5:e9:6c 0800 60: 10.10.10.11.8888 > 10.10.10.10.8888: udp 18 15:53:53.281997 0:60:8:f5:c5:32 0:60:8:f5:e9:6c 0800 60: 10.10.10.11.8888 > 10.10.10.10.8888: udp 18 VLAN traffic on sending side (receive side sees nothing): ---------------------------------------------------------- arma# tcpdump -ne -i ti0 tcpdump: listening on ti0 15:42:10.776655 0:60:8:f5:c5:32 0:60:8:f5:e9:6c 8100 64: 802.1Q vlan#1 P0 10.10.10.11.8888 > 10.10.10.10.8888: udp 18 15:42:10.876631 0:60:8:f5:c5:32 0:60:8:f5:e9:6c 8100 64: 802.1Q vlan#1 P0 10.10.10.11.8888 > 10.10.10.10.8888: udp 18 15:42:10.976630 0:60:8:f5:c5:32 0:60:8:f5:e9:6c 8100 64: 802.1Q vlan#1 P0 10.10.10.11.8888 > 10.10.10.10.8888: udp 18 Now if I run the same test with the fxp card, the receiving side sees the traffic just fine: freebsd2# tcpdump -ne -i fxp1 tcpdump: listening on fxp1 16:07:42.697724 0:d0:b7:9e:dd:5b 0:d0:b7:9e:df:a2 8100 64: 802.1Q vlan#1 P0 20.20.20.21.8888 > 20.20.20.20.8888: udp 18 16:07:42.797717 0:d0:b7:9e:dd:5b 0:d0:b7:9e:df:a2 8100 64: 802.1Q vlan#1 P0 20.20.20.21.8888 > 20.20.20.20.8888: udp 18 16:07:42.897712 0:d0:b7:9e:dd:5b 0:d0:b7:9e:df:a2 8100 64: 802.1Q vlan#1 P0 20.20.20.21.8888 > 20.20.20.20.8888: udp 18 16:07:42.997713 0:d0:b7:9e:dd:5b 0:d0:b7:9e:df:a2 8100 64: 802.1Q vlan#1 P0 20.20.20.21.8888 > 20.20.20.20.8888: udp 18 Why do the two cards behave differently with regard to tcpdump (libpcap)? I need to be able to see the VLAN traffic without configuring VLANs (in a test lab). Thanks, CJ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 13:22:32 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 D2B7637B418 for ; Thu, 15 Nov 2001 13:22:24 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fAFLMM721731; Thu, 15 Nov 2001 13:22:22 -0800 Date: Thu, 15 Nov 2001 13:22:22 -0800 From: Brooks Davis To: CJTT Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011115132222.B17252@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cjtt@employees.org on Thu, Nov 15, 2001 at 12:53:35PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2001 at 12:53:35PM -0800, CJTT wrote: >=20 > While sending some test traffic to a > FreeBSD 4.4 (cvsupped yesterday), I noticed > that tcpdump doesn't seem to see VLAN traffic > received on the ti card as it does on the fxp card. > (however, tcpdump on the sending ti card > sees the traffic leave). >=20 [traffic dumps]. >=20 > Why do the two cards behave differently with regard to=20 > tcpdump (libpcap)? I need to be able to see the VLAN traffic > without configuring VLANs (in a test lab).=20 This is caused by the fact that ethernet adaptors provide bpf support via the ether_input() function and on cards like those supported by ti(4) which provide hardware vlan tag extraction, ether_input() is never called. It would be relativly simple to modify vlan_input_tag() to take an ifp argument and have it rebuild a packet to send to bpf. In current you wouldn't even have to change the drivers because the wrapper macro for locking already takes an if pointer. -- 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 --IiVenqGWf+H9Y6IX 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 iD8DBQE79DIOXY6L6fI4GtQRAoB7AKDlkS+OFYPiW6+2lLdghsQEYRzeNgCfSgbd m860WWqJDVbM/S3sVIwqlpk= =XQQC -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 13:36:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp003pub.verizon.net (smtp003pub.verizon.net [206.46.170.182]) by hub.freebsd.org (Postfix) with ESMTP id 870A837B417 for ; Thu, 15 Nov 2001 13:36:29 -0800 (PST) Received: from shaggy.doo.com (dfiatx96-144.dfiatx.dsl.gtei.net [4.3.96.144]) by smtp003pub.verizon.net with SMTP ; id fAFLYr323790 Thu, 15 Nov 2001 15:34:54 -0600 (CST) Content-Type: text/plain; charset="us-ascii" From: Shaun Marko Reply-To: shaun.marko@gte.net To: Brooks Davis , CJTT Subject: Re: ti driver, vlan and tcpdump Date: Thu, 15 Nov 2001 15:41:21 -0600 X-Mailer: KMail [version 1.2] Cc: freebsd-net@FreeBSD.ORG References: <20011115132222.B17252@Odin.AC.HMC.Edu> In-Reply-To: <20011115132222.B17252@Odin.AC.HMC.Edu> MIME-Version: 1.0 Message-Id: <01111515412101.00586@shaggy.doo.com> 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 Could you also get the desired result by using a kernel without VLAN support? The original poster said he didn't want to configure VLAN interfaces anyway. -Shaun On Thursday 15 November 2001 03:22, Brooks Davis wrote: > On Thu, Nov 15, 2001 at 12:53:35PM -0800, CJTT wrote: > > While sending some test traffic to a > > FreeBSD 4.4 (cvsupped yesterday), I noticed > > that tcpdump doesn't seem to see VLAN traffic > > received on the ti card as it does on the fxp card. > > (however, tcpdump on the sending ti card > > sees the traffic leave). > > [traffic dumps]. > > > Why do the two cards behave differently with regard to > > tcpdump (libpcap)? I need to be able to see the VLAN traffic > > without configuring VLANs (in a test lab). > > This is caused by the fact that ethernet adaptors provide bpf support > via the ether_input() function and on cards like those supported by ti(4) > which provide hardware vlan tag extraction, ether_input() is never called. > It would be relativly simple to modify vlan_input_tag() to take an ifp > argument and have it rebuild a packet to send to bpf. In current you > wouldn't even have to change the drivers because the wrapper macro for > locking already takes an if pointer. > > -- Brooks ---------------------------------------- Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 13:42:14 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 4CF5537B418 for ; Thu, 15 Nov 2001 13:42:12 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fAFLg7128483; Thu, 15 Nov 2001 13:42:07 -0800 Date: Thu, 15 Nov 2001 13:42:07 -0800 From: Brooks Davis To: Shaun Marko Cc: Brooks Davis , CJTT , freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011115134207.A26868@Odin.AC.HMC.Edu> References: <20011115132222.B17252@Odin.AC.HMC.Edu> <01111515412101.00586@shaggy.doo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01111515412101.00586@shaggy.doo.com>; from shaun.marko@gte.net on Thu, Nov 15, 2001 at 03:41:21PM -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 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2001 at 03:41:21PM -0600, Shaun Marko wrote: > Could you also get the desired result by using a kernel without VLAN supp= ort?=20 > The original poster said he didn't want to configure VLAN interfaces anyw= ay. For the moment, on stable hosts, that will work. Driver vlan support is no longer optional in current and that change will be MFC'd just as soon as I get it tested. The right answer is probably to modify the VLAN_INPUT_TAG macro to do the bpf 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 --PEIAKu/WMn1b1Hv9 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 iD8DBQE79DavXY6L6fI4GtQRAuN7AKDnO4c7OLQ6gYpksvcClXLhsZ2iHACfaAEg 722sXbYS9GIDRcvxDoztSCI= =XO0/ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 14: 4:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from willers.employees.org (willers.employees.org [128.107.241.167]) by hub.freebsd.org (Postfix) with ESMTP id 7DD7B37B416 for ; Thu, 15 Nov 2001 14:04:09 -0800 (PST) Received: from localhost (cjtt@localhost) by willers.employees.org (8.11.5/8.11.5) with SMTP id fAFM47O29135; Thu, 15 Nov 2001 14:04:07 -0800 (PST) Date: Thu, 15 Nov 2001 14:04:07 -0800 (PST) From: CJTT To: Brooks Davis Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump In-Reply-To: <20011115134207.A26868@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 Thu, 15 Nov 2001, Brooks Davis wrote: > On Thu, Nov 15, 2001 at 03:41:21PM -0600, Shaun Marko wrote: > > Could you also get the desired result by using a kernel without VLAN support? > > The original poster said he didn't want to configure VLAN interfaces anyway. > > For the moment, on stable hosts, that will work. Driver vlan support is > no longer optional in current and that change will be MFC'd just as soon > as I get it tested. The right answer is probably to modify the > VLAN_INPUT_TAG macro to do the bpf stuff. I see what you're talking about in the driver (if_ti.c). But I'm not sure if I understand you correctly (I can't seem to find where the VLAN_INPUT_TAG macro is located). Would a temporary fix in if_ti.c be to just remove the vlan_input_tag() clause and leave ether_input? --- #if NVLAN > 0 /* * If we received a packet with a vlan tag, pass it * to vlan_input() instead of ether_input(). */ if (have_tag) { vlan_input_tag(eh, m, vlan_tag); have_tag = vlan_tag = 0; continue; } #endif ether_input(ifp, eh, m); } ---- Thanks, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 14:14:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from nic.vetx.com (nic.vetx.com [209.123.51.6]) by hub.freebsd.org (Postfix) with ESMTP id 0A89C37B416 for ; Thu, 15 Nov 2001 14:14:07 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: IPSEC / RAPTOR Firewall Interaction X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 15 Nov 2001 17:12:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSEC / RAPTOR Firewall Interaction Thread-Index: AcFuIpDLyWIkBL1USiexs3rQK11uAg== From: "Smith, Rick" To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all; I'm attempting to figure out how to setup an IPv4 IPSEC tunnel between two of our other offices (running Symantec Raptor 6.50 for Windows NT) and my FreeBSD firewall here in my office (4.2-RELEASE) Here's a little network diagram of the situation: x.x.51.24 (my inside) <--> x.x.5.254 (my external address) <--- Internet ---> x.x.42.26 (Their External) <--> 172.16.11.0 (Their Internal) On their firewall (Raptor) they are connecting to me using SHA1 / 3DES with no data compression, also using pre-shared keys. I'd like to do this using gif0 tunnels, but I just can't figure out how to set it all up correctly. =20 I already compiled racoon - here's the conf file: # racoon.conf for use with Checkpoint VPN-1/Firewall-1 # # # Pre-shared key set on the VPN-1 server. # # WARNING: psk.txt must have mode 600 permission. path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; # log debug4; # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 15 sec; } remote anonymous { exchange_mode aggressive,main; # For Firewall-1 Aggressive mode #my_identifier address; #my_identifier user_fqdn ""; #my_identifier address ""; #peers_identifier address ""; #certificate_type x509 "" ""; nonce_size 16; lifetime time 10 min; # sec,min,hour lifetime byte 5 MB; # B,KB,GB initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 10 min; lifetime byte 50000 KB; encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate ; } Any ideas from you seasoned pros would be appreciated. Thanks, Rick Smith Vertex Interactive, Inc. http://www.vertexinteractive.com (973) 777 - 3500 x382 rsmith@vetx.com ------------------------------------------------ rm -rf /bin/laden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 14:50:27 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 F3C7637B41A for ; Thu, 15 Nov 2001 14:50:09 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fAFMo9m10628; Thu, 15 Nov 2001 14:50:09 -0800 Date: Thu, 15 Nov 2001 14:50:09 -0800 From: Brooks Davis To: CJTT Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011115145008.A8037@Odin.AC.HMC.Edu> References: <20011115134207.A26868@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cjtt@employees.org on Thu, Nov 15, 2001 at 02:04:07PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2001 at 02:04:07PM -0800, CJTT wrote: > I see what you're talking about in the driver (if_ti.c). > But I'm not sure if I understand you correctly > (I can't seem to find where the VLAN_INPUT_TAG macro > is located). Would a temporary fix in if_ti.c > be to just remove the vlan_input_tag() clause > and leave ether_input? VLAN_INPUT_TAG is only in current. I think your proposed solution will cause intresting problems unless you make sure to disable the hardware vlan support entierly or actually tack the tag back onto the packet. -- 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 --3V7upXqbjpZ4EhLz 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 iD8DBQE79EaeXY6L6fI4GtQRAgviAJ4vnVeuB4E/UHQ2sVV74u2ahEis9ACg2mZ0 ko6tZVeEqdvdCGCYfAi2wPE= =XCIT -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 17:59:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 1925137B405 for ; Thu, 15 Nov 2001 17:59:49 -0800 (PST) Received: from localhost ([3ffe:501:41c:2000:e89c:3277:c904:dbcf]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAG1t3x11753; Fri, 16 Nov 2001 10:55:03 +0900 (JST) To: rsmith@vetx.com Cc: freebsd-net@freebsd.org Subject: Re: IPSEC / RAPTOR Firewall Interaction In-Reply-To: Your message of "Thu, 15 Nov 2001 17:12:08 -0500" References: X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011116105949D.sakane@kame.net> Date: Fri, 16 Nov 2001 10:59:49 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 20 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 attempting to figure out how to setup an IPv4 IPSEC tunnel between > two of our other offices (running Symantec Raptor 6.50 for Windows NT) > and my FreeBSD firewall here in my office (4.2-RELEASE) > > Here's a little network diagram of the situation: > > x.x.51.24 (my inside) <--> x.x.5.254 (my external address) <--- > Internet ---> x.x.42.26 (Their External) <--> 172.16.11.0 (Their > Internal) > > On their firewall (Raptor) they are connecting to me using SHA1 / 3DES > with no data compression, also using pre-shared keys. > > I'd like to do this using gif0 tunnels, but I just can't figure out how > to set it all up correctly. don't forget that the generic tunnel(gif) is different from the ipsec tunnel. when you use gif, you have to configure the raptor firewall to use ipsec TRANSPORT mode. Or you should use racoon with the ipsec tunnel mode, without gif. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 18:45:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 62AA837B405; Thu, 15 Nov 2001 18:45:30 -0800 (PST) Received: from localhost ([3ffe:501:41c:2000:e89c:3277:c904:dbcf]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAG2eix11886; Fri, 16 Nov 2001 11:40:44 +0900 (JST) To: martin.vana@vslib.cz Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: tunneling with ipsec In-Reply-To: Your message of "Thu, 15 Nov 2001 00:48:58 +0100" <000f01c16d66$edba8400$1198e693@kolej.vslib.cz> References: <000f01c16d66$edba8400$1198e693@kolej.vslib.cz> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011116114529V.sakane@kame.net> Date: Fri, 16 Nov 2001 11:45:29 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 7 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 > how can I setup tunneling firewall using ipsec or something alike? > (need to use some ports which are prohibited). > Do I have to have some computer behind firewall (unfirewalled) and > some programs running on it also? it may help you. http://www.daemonnews.org/200101/ipsec-howto.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 19:52:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from nic.vetx.com (nic.vetx.com [209.123.51.6]) by hub.freebsd.org (Postfix) with ESMTP id 5A35637B418 for ; Thu, 15 Nov 2001 19:52:39 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IPSEC / RAPTOR Firewall Interaction X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 15 Nov 2001 22:50:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSEC / RAPTOR Firewall Interaction Thread-Index: AcFuQhjwS8Wy5kK0RHmHmCDS9yETwwAEABXg From: "Smith, Rick" To: "Shoichi Sakane" 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 What's the difference between tunnel and transport mode configs in racoon ? I'm troubled by the fact that racoon seems to be the ONLY tool for this, and yet there's an extreme lack of documentation that exists for racoon configuration. Anyone have a transport mode config from racoon they could share ? Rick -----Original Message----- From: Shoichi Sakane [mailto:sakane@kame.net] Sent: Thursday, November 15, 2001 9:00 PM To: Smith, Rick Cc: freebsd-net@freebsd.org Subject: Re: IPSEC / RAPTOR Firewall Interaction > I'm attempting to figure out how to setup an IPv4 IPSEC tunnel between > two of our other offices (running Symantec Raptor 6.50 for Windows NT) > and my FreeBSD firewall here in my office (4.2-RELEASE) >=20 > Here's a little network diagram of the situation: >=20 > x.x.51.24 (my inside) <--> x.x.5.254 (my external address) <--- > Internet ---> x.x.42.26 (Their External) <--> 172.16.11.0 (Their > Internal) >=20 > On their firewall (Raptor) they are connecting to me using SHA1 / 3DES > with no data compression, also using pre-shared keys. >=20 > I'd like to do this using gif0 tunnels, but I just can't figure out how > to set it all up correctly. =20 don't forget that the generic tunnel(gif) is different from the ipsec tunnel. when you use gif, you have to configure the raptor firewall to use ipsec TRANSPORT mode. Or you should use racoon with the ipsec tunnel mode, without gif. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 20: 9:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id CDBDD37B418 for ; Thu, 15 Nov 2001 20:09:16 -0800 (PST) Received: from localhost ([3ffe:501:41c:2000:e89c:3277:c904:dbcf]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAG44Zx12196; Fri, 16 Nov 2001 13:04:35 +0900 (JST) To: rsmith@vetx.com Cc: freebsd-net@freebsd.org Subject: RE: IPSEC / RAPTOR Firewall Interaction In-Reply-To: Your message of "Thu, 15 Nov 2001 22:50:41 -0500" References: X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011116130919N.sakane@kame.net> Date: Fri, 16 Nov 2001 13:09:19 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 8 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > What's the difference between tunnel and transport mode configs in > racoon ? > I'm troubled by the fact that racoon seems to be the ONLY tool for this, > and yet there's an extreme lack of documentation that exists for racoon > configuration. how about http://www.daemonnews.org/200101/ipsec-howto.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 20:30: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail8.wi.rr.com (mkc-162-176.kc.rr.com [24.94.162.176]) by hub.freebsd.org (Postfix) with ESMTP id E9B0337B405 for ; Thu, 15 Nov 2001 20:30:01 -0800 (PST) Received: from ASDF ([24.160.240.133]) by mail8.wi.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 15 Nov 2001 22:29:55 -0600 Date: Thu, 15 Nov 2001 22:20:47 -0600 From: icb-bsd X-Mailer: The Bat! (v1.49) UNREG / CD5BF9353B3B7091 Reply-To: icb-bsd Organization: iCB X-Priority: 3 (Normal) Message-ID: <73629279173.20011115222047@wi.rr.com> To: Shoichi Sakane Cc: rsmith@vetx.com, freebsd-net@FreeBSD.ORG Subject: Re[2]: IPSEC / RAPTOR Firewall Interaction In-reply-To: <20011116130919N.sakane@kame.net> References: <20011116130919N.sakane@kame.net> 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 Shoichi, >> I'm troubled by the fact that racoon seems to be the ONLY tool for this, >> and yet there's an extreme lack of documentation that exists for racoon >> configuration. SS> how about http://www.daemonnews.org/200101/ipsec-howto.html What about info in regards to running a FreeBSD IPSEC server (racoon) with DHCP clients (road warriors)? I haven't seen anything about that...is it possible? If so...any links to info? Thanks in advance. icb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 21:11: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 2BD6037B44B for ; Thu, 15 Nov 2001 21:10:47 -0800 (PST) Received: from localhost ([3ffe:501:41c:2000:e89c:3277:c904:dbcf]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAG564x12485; Fri, 16 Nov 2001 14:06:04 +0900 (JST) To: icb-bsd@wi.rr.com Cc: rsmith@vetx.com, freebsd-net@FreeBSD.ORG Subject: Re: Re[2]: IPSEC / RAPTOR Firewall Interaction In-Reply-To: Your message of "Thu, 15 Nov 2001 22:20:47 -0600" <73629279173.20011115222047@wi.rr.com> References: <73629279173.20011115222047@wi.rr.com> X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="NextPart-20011116140450-0056100" Message-Id: <20011116141045I.sakane@kame.net> Date: Fri, 16 Nov 2001 14:10:45 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 148 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 --NextPart-20011116140450-0056100 Content-Type: Text/Plain; charset=us-ascii > What about info in regards to running a FreeBSD IPSEC server (racoon) > with DHCP clients (road warriors)? I haven't seen anything about that...is it > possible? If so...any links to info? Thanks in advance. racoon can exchange SAs in such a scenario by using "generate_policy" directive. but there is no documentation. the only one is probably racoon.conf(5). you know there are some scenario about "road warriors". also, IKE and IPsec have many tweaks. so there are some solutions to solve scenarios. here is one of them. i'm using a laptop PC and the ip address is assigned dynamically. i access to the mail server from my laptop. i only use the ipsec transport mode. i use certificates because this is the way to solve the scenario with IKE main mode. i attach my configuration to this mail. 1. racoon.conf in the laptop. 2. policy parameter in the laptop. 3. racoon.conf in the server. no need server's policy configuration. it hope it help you. regards, --NextPart-20011116140450-0056100 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="racoon-client.conf" # $KAME: racoon.conf.sample,v 1.21 2000/12/17 21:17:53 sakane Exp $ path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; path certificate "/usr/local/etc/certs" ; remote anonymous { exchange_mode main,aggressive,base; my_identifier user_fqdn "sakane@tanu.org"; peers_identifier fqdn "mine.kame.net"; certificate_type x509 "/usr/home/sakane/etc/certs/sigby-ssh.cert" "/usr/home/sakane/etc/certs/privkey" ; lifetime time 60 min ; proposal_check obey; # phase 1 proposal (for ISAKMP SA) proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 2; lifetime time 30 min ; encryption_algorithm aes, 3des, cast128, blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } --NextPart-20011116140450-0056100 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="policy-client.conf" spdflush; spdadd ::/0[53] ::/0 any -P in none; spdadd ::/0 ::/0[53] any -P out none; spdadd ::/0 ::/0 any -P out ipsec esp/transport//use; spdadd ::/0 ::/0 any -P in ipsec esp/transport//use; spdadd 0.0.0.0/0[53] 0.0.0.0/0 any -P in none; spdadd 0.0.0.0/0 0.0.0.0/0[53] any -P out none; spdadd 0.0.0.0/0 0.0.0.0/0 any -P out ipsec esp/transport//use; spdadd 0.0.0.0/0 0.0.0.0/0 any -P in ipsec esp/transport//use; --NextPart-20011116140450-0056100 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="racoon-server.conf" # $KAME: racoon.conf.sample,v 1.21 2000/12/17 21:17:53 sakane Exp $ path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; path certificate "/usr/local/etc/certs" ; remote anonymous { exchange_mode main,aggressive,base; my_identifier fqdn "mine.kame.net"; peers_identifier user_fqdn "sakane@tanu.org"; certificate_type x509 "cert-signed-by-ssh.pem" "privkey.pem" ; lifetime time 15 min ; # sec,min,hour proposal_check obey; generate_policy on; passive on; # phase 1 proposal (for ISAKMP SA) proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 2; lifetime time 5 min ; encryption_algorithm aes, 3des, cast128, blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } --NextPart-20011116140450-0056100-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 15 21:24:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id B84A337B416 for ; Thu, 15 Nov 2001 21:24:50 -0800 (PST) Received: from localhost ([3ffe:501:41c:2000:e89c:3277:c904:dbcf]) by mine.kame.net (8.11.1/3.7W) with ESMTP id fAG5K4x12535; Fri, 16 Nov 2001 14:20:05 +0900 (JST) To: ismail@EnderUNIX.ORG Cc: freebsd-net@freebsd.org Subject: Re: Tunnel Server Forwarding problem. In-Reply-To: Your message of "Wed, 14 Nov 2001 00:22:05 +0000 (GMT)" References: X-Mailer: Cue version 0.6 (011026-1440/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20011116142447W.sakane@kame.net> Date: Fri, 16 Nov 2001 14:24:47 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The problem is: > when i setup an gif tunnel between FreeBSD Tunnel server and FreeBSD > client. Client can only ping to FreeBSD TS . nothing else. > i run following command on FreeBSD Client > and on FreeBSD Tunnel Server: > what is problem ? > whan should i do ? tap all of interfaces of your scenario, client's fxp0 and gif0, server's fxp0 and gif0, also cisco's one you can. then you can get what is wrong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 3:54:21 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 1288637B416 for ; Fri, 16 Nov 2001 03: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 fAGBs8R28424; Fri, 16 Nov 2001 04:54:08 -0700 (MST) From: "Erik Norvelle" To: "Lars Eggert" Cc: Subject: RE: 4.4-CURRENT problems getting IPSec to function Date: Fri, 16 Nov 2001 04:54:07 -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; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_004A_01C16E5A.B86281A0" In-Reply-To: <3BE84F94.1060304@isi.edu> 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_004A_01C16E5A.B86281A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lars (and anyone else who can help): I have attempted to follow your advice, by configuring my machines to use IPSEC tunnel mode only. However, I still can't get ping packets to go between the two internal networks. My /etc/ipsec.conf files on both machines are as follows: --- Begin included file --- flush; spdflush; # Note that the add rules are the same as on Node B! spdadd 10.20.0.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/xxx.yyy.40.122-xxx.yyy.40.135/require; spdadd 192.168.1.0/24 10.20.0.0/24 any -P out ipsec esp/tunnel/xxx.yyy.40.135-xxx.yyy.40.122/require; --- End included file --- For the test situation, I have set up my ipfilter to allow everything to pass, both in and out, on both the internal and external interfaces. Also, I have turned off IPNAT completely. I *have* been able to get transport mode working between the two external interfaces. Racoon successfully exchanged keys, and a perusal of netstat -sn output showed that IPSEC packets were in fact being passed. However, tunnel mode between the two internal networks does not produce any IPSEC packets or key exchange traffic at all. Thanks for your help. -Erik -------------------------------------------- Erik Norvelle Support Systems Analyst, Sr. Distributed Learning Laboratory Educational Communications and Technologies College of Agriculture and Life Sciences The University of Arizona Phone: 520-621-7663 Fax: 520-626-8688 email: norvelle@ag.arizona.edu Address: 224 Forbes Bldg., Tucson, AZ 85721 -------------------------------------------- Credo in Unum Deum -------------------------------------------- -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Lars Eggert Sent: Tuesday, November 06, 2001 2:01 PM To: Erik Norvelle Cc: freebsd-net@FreeBSD.ORG Subject: Re: 4.4-CURRENT problems getting IPSec to function 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 ------=_NextPart_000_004A_01C16E5A.B86281A0 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 AKCCAYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTE2MTE1 NDA2WjAjBgkqhkiG9w0BCQQxFgQUqgtRAzEOWABadIg9DVId87nAyr0wdgYJKoZIhvcNAQkPMWkw ZzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowBwYFKw4DAhowCgYIKoZIhvcNAgUwCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFyIowDQYJKoZI hvcNAQEBBQAEgYAlOgmMUrKLT7GEqs0DgXpy1euAel84TGJN5deSV8V6H6DT8jCJ3Jq8lBRorIdu 9bKZhWS5z6xMIzrnepccALNqAw6ANnddWEoyQ84qEXMm3F3bmcUm5UPunp9UHAYO1f+LjZWEwr4A kSVy9FnWbAVguV71U1tpfPqEbKdolOKlpgAAAAAAAA== ------=_NextPart_000_004A_01C16E5A.B86281A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 6:27:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from willers.employees.org (willers.employees.org [128.107.241.167]) by hub.freebsd.org (Postfix) with ESMTP id 452DE37B417 for ; Fri, 16 Nov 2001 06:27:50 -0800 (PST) Received: from localhost (cjtt@localhost) by willers.employees.org (8.11.5/8.11.5) with SMTP id fAGERQP22022; Fri, 16 Nov 2001 06:27:26 -0800 (PST) Date: Fri, 16 Nov 2001 06:27:25 -0800 (PST) From: CJTT To: Brooks Davis Cc: freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump In-Reply-To: <20011115134207.A26868@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 Thu, 15 Nov 2001, Brooks Davis wrote: > For the moment, on stable hosts, that will work. Driver vlan support is > no longer optional in current and that change will be MFC'd just as soon > as I get it tested. The right answer is probably to modify the > VLAN_INPUT_TAG macro to do the bpf stuff. (I'll temporarily remove the VLAN support from the kernel). But when this is MFC'd, what will I need to do in order to continue seeing all traffic on the main interface (while using libpcap (tcpdump))? Will the VLAN_INPUT_TAG macro just handle it automatically? This is important for our protocol testing. We use IPDIVERT, libpcap, and libnet for lots of our tools. It saves us lot of money. Thanks, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 7: 2:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from thoth.upan.org (thoth.upan.org [204.107.76.16]) by hub.freebsd.org (Postfix) with ESMTP id E38A037B417 for ; Fri, 16 Nov 2001 07:02:08 -0800 (PST) Received: from ocsinternet.com (localhost [127.0.0.1]) by thoth.upan.org (8.11.3/8.11.3) with ESMTP id fAGE8AZ00430; Fri, 16 Nov 2001 09:08:10 -0500 (EST) (envelope-from mikel@ocsinternet.com) Message-ID: <3BF51DC8.A2AC1549@ocsinternet.com> Date: Fri, 16 Nov 2001 09:08:09 -0500 From: Mikel King X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Chrisy Luke , Julian Elischer , net@FreeBSD.ORG Subject: Re: RFC: ipfirewall_forward patch References: 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 Just curious, but what's a doddle? Cheers, mikel Julian Elischer wrote: > On Thu, 15 Nov 2001, Chrisy Luke wrote: > > > > only packets already leaving the system can be hijacked and forwarded > > > > to a 2nd machine. Incoming packets can only be forwarded to local > > > > addresses/port combinations. > > > > My fault. I was being lazy when I wrote it. :) > > Ah it WAS you I committed it for wasn't it? :-) > > > > > > > This patch would allow a sequence of mchines to hijack > > > > a particular conforming packet and pass it allong a chain of > > > > these machine sot make it fall out somewhere else.. > > > > It looks good. The ipfw syntax doesn't quite make sense to me. > > They all have different bits masked by the netmask.. > > > Also, are you requiring that they all be on the same ipfw rule number? > > No, I was lazy.. > (cut'n'pasted the rules) > > > > > Writing a script to probe a serving host and alter ipfw rules could be > > done seamlessly if they were on seperate ipfw rules. > > well sure.. it's the mechanism not the details I was looking at.. > Can you check my logic on the changes.? > I'll be testing it more tonight.. > > > > > With a similar trick to move aliases around on a primary ether port, > > it's going to be a doddle to setup a clustered-transparent loadbalancer > > in FreeBSD now. Neat. :) > > that's the theory.. > > Why make a huge complicated program to do it when > you can do it with ipfw :-) > > > > > Cheers, > > Chris. > > -- > > == chris@easynet.net T: +44 845 333 0122 > > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 7:20:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from vorbis.noc.easynet.net (vorbis.noc.easynet.net [195.40.1.254]) by hub.freebsd.org (Postfix) with SMTP id 8A6A437B417 for ; Fri, 16 Nov 2001 07:20:52 -0800 (PST) Received: (qmail 27289 invoked by uid 1943); 16 Nov 2001 15:20:46 -0000 Date: Fri, 16 Nov 2001 15:20:46 +0000 From: Chrisy Luke To: Mikel King Cc: Julian Elischer , Chrisy Luke , Julian Elischer , net@FreeBSD.ORG Subject: Re: RFC: ipfirewall_forward patch Message-ID: <20011116152046.A27195@flirble.org> References: <3BF51DC8.A2AC1549@ocsinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF51DC8.A2AC1549@ocsinternet.com>; from mikel@ocsinternet.com on Fri, Nov 16, 2001 at 09:08:09AM -0500 Organization: The Flirble Organisation X-URL: http://www.flirble.org/ X-FTP: ftp://ftp.flirble.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 Mikel King wrote (on Nov 16): > Just curious, but what's a doddle? It's like a doodle, but with less o's and more d's. :) It essentially means "this is easy to do". Chris. -- == chris@easynet.net T: +44 845 333 0122 == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 8:27:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from opensrs.saignon.net (216-120-17-31.dsl.cust.tfb.com [216.120.17.31]) by hub.freebsd.org (Postfix) with ESMTP id 97F8837B41A for ; Fri, 16 Nov 2001 08:27:38 -0800 (PST) Received: from tsaignmobl (u2938@prx2.ipivot.com [216.188.41.2]) by opensrs.saignon.net (8.11.4/8.11.3) with ESMTP id fAGGRDH07416 for ; Fri, 16 Nov 2001 08:27:13 -0800 (PST) (envelope-from tony@saign.com) From: Tony Saign Reply-To: To: Subject: Microsoft Terminal Services/Remote Desktop Connection Date: Fri, 16 Nov 2001 08:27:18 -0800 Message-ID: <000001c16ebb$8fb3ceb0$da0b010a@tsaignmobl> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anyone have any ideas on why this program wouldn't work through a FreeBSD 4.4 system using NAT & IPFW?? I can connect to systems outside on the Internet, but not internal systems on the same subnet. INTERNET--- [1] >> <216.120.x.x> [2] >> <192.168.1.1> | | {Can connect to Internet host running TS or RDP} | | {Can connect to Internet host running TS or RDP} Neither of these two can connect to each other for some reason?? Thanks in advance, -Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 9: 6:41 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 4862B37B405 for ; Fri, 16 Nov 2001 09:06:38 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fAGH6aN04812; Fri, 16 Nov 2001 09:06:36 -0800 Date: Fri, 16 Nov 2001 09:06:36 -0800 From: Brooks Davis To: CJTT Cc: Brooks Davis , freebsd-net@FreeBSD.ORG Subject: Re: ti driver, vlan and tcpdump Message-ID: <20011116090635.A31992@Odin.AC.HMC.Edu> References: <20011115134207.A26868@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from cjtt@employees.org on Fri, Nov 16, 2001 at 06:27:25AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 16, 2001 at 06:27:25AM -0800, CJTT wrote: > (I'll temporarily remove the VLAN support from the kernel). > But when this is MFC'd, what will I need to do in order to=20 > continue seeing all traffic on the main interface > (while using libpcap (tcpdump))? =20 >=20 > Will the VLAN_INPUT_TAG macro just handle it automatically? =20 I'll take a look at adding the appropriate code to VLAN_INPUT_TAG, but I can't promise that I will get it done before the MFC. -- 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 --C7zPtVaVf+AK4Oqc 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 iD8DBQE79UebXY6L6fI4GtQRAti7AKDX0Piahk4UPTxfBgZ0HF6JUtVpCgCffeU1 PnCOQMzy02+tIhlILR028es= =IKFM -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 9: 8:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from thoth.upan.org (thoth.upan.org [204.107.76.16]) by hub.freebsd.org (Postfix) with ESMTP id 8670137B418 for ; Fri, 16 Nov 2001 09:08:32 -0800 (PST) Received: from ocsinternet.com (localhost [127.0.0.1]) by thoth.upan.org (8.11.3/8.11.3) with ESMTP id fAGGEfZ00561; Fri, 16 Nov 2001 11:14:42 -0500 (EST) (envelope-from mikel@ocsinternet.com) Message-ID: <3BF53B71.7DAD1AB7@ocsinternet.com> Date: Fri, 16 Nov 2001 11:14:41 -0500 From: Mikel King X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Chrisy Luke Cc: Julian Elischer , Chrisy Luke , Julian Elischer , net@FreeBSD.ORG Subject: Re: RFC: ipfirewall_forward patch References: <3BF51DC8.A2AC1549@ocsinternet.com> <20011116152046.A27195@flirble.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 Chrisy Luke wrote: > Mikel King wrote (on Nov 16): > > Just curious, but what's a doddle? > > It's like a doodle, but with less o's and more d's. :) > > It essentially means "this is easy to do". > > Chris. > -- > == chris@easynet.net T: +44 845 333 0122 > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 Thanks, I thought so but sometimes you jut have to ask...;) On a side note does anyone know of a project to add IP pooling to natd? Or one to incorperate ethfw into ipfw? cheers, mikel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 10:42:35 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 7A61637B405 for ; Fri, 16 Nov 2001 10:42:33 -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 fAGIgVN25436; Fri, 16 Nov 2001 10:42:31 -0800 (PST) Message-ID: <3BF55E17.7000506@isi.edu> Date: Fri, 16 Nov 2001 10:42:31 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011107 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: > --- Begin included file --- flush; spdflush; > > # Note that the add rules are the same as on Node B! spdadd > 10.20.0.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/xxx.yyy.40.122-xxx.yyy.40.135/require; > > spdadd 192.168.1.0/24 10.20.0.0/24 any -P out ipsec esp/tunnel/xxx.yyy.40.135-xxx.yyy.40.122/require; > > --- End included file --- You are adding SPD entries but not SAD entries. See setkey(8). Oh wait, you're using IKE, which should negotiate trhe SAD entries. > For the test situation, I have set up my ipfilter to allow > everything to pass, both in and out, on both the internal and > external interfaces. Also, I have turned off IPNAT completely. Good, this should simplify things. > However, tunnel mode between the two internal networks does not > produce any IPSEC packets or key exchange traffic at all. I'm not sure I understand what you mean here. You are trying to set up tunnel mode between the two gateways, right? (And what goes inside the tunnel are packets between the two end networks.) All in all, it looks like your problem might be IKE-related, maybe a config problem with racoon? I've never used it myself, but you could try asking on snap-users@kame.net... 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 Fri Nov 16 11:32: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from www.brasapen.org (www.brasapen.org [193.78.174.81]) by hub.freebsd.org (Postfix) with ESMTP id B4E4B37B418 for ; Fri, 16 Nov 2001 11:32:02 -0800 (PST) Received: by www.brasapen.org (Postfix, from userid 1000) id 435531E9F; Fri, 16 Nov 2001 20:31:53 +0100 (CET) Date: Fri, 16 Nov 2001 20:31:53 +0100 From: eilko.bos@brasapen.org To: "Smith, Rick" Cc: Shoichi Sakane , freebsd-net@freebsd.org Subject: Re: IPSEC / RAPTOR Firewall Interaction Message-ID: <20011116203153.A23528@www.brasapen.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rsmith@vetx.com on Thu, Nov 15, 2001 at 10:50:41PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From the keyboard of Smith, Rick, written on Thu, Nov 15, 2001 at 10:50:41PM -0500: > > What's the difference between tunnel and transport mode configs in > racoon ? To understand the difference between transport-mode (let's say host-to-host) or tunnel-mode (if one of the machines is a securitygateway, it MUST be tunnel), you can read the RfC. Handy reading can be found on: http://www.networksorcery.com/enp/ it explains a bit, and links to the proper RfC. http://www.networksorcery.com/enp/rfc/rfc2401.txt, section 4, explains about tunnel- and transportmode. > I'm troubled by the fact that racoon seems to be the ONLY tool for this, > and yet there's an extreme lack of documentation that exists for racoon > configuration. You can also use isakmpd from the portstree, which works as well. Regards, -- Eilko Bos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 11:45:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from www.brasapen.org (www.brasapen.org [193.78.174.81]) by hub.freebsd.org (Postfix) with ESMTP id 7824D37B418 for ; Fri, 16 Nov 2001 11:45:31 -0800 (PST) Received: by www.brasapen.org (Postfix, from userid 1000) id EEF741E9F; Fri, 16 Nov 2001 20:45:24 +0100 (CET) Date: Fri, 16 Nov 2001 20:45:24 +0100 From: eilko.bos@brasapen.org To: Erik Norvelle Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: 4.4-CURRENT problems getting IPSec to function Message-ID: <20011116204523.B23528@www.brasapen.org> References: <3BE84F94.1060304@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from norvelle@Ag.arizona.edu on Fri, Nov 16, 2001 at 04:54:07AM -0700 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 From the keyboard of Erik Norvelle, written on Fri, Nov 16, 2001 at 04:54:07AM -0700: > Lars (and anyone else who can help): > > I have attempted to follow your advice, by configuring my machines to use > IPSEC tunnel mode only. However, I still can't get ping packets to go > between the two internal networks. My /etc/ipsec.conf files on both > machines are as follows: > > --- Begin included file --- > flush; > spdflush; > > # Note that the add rules are the same as on Node B! > spdadd 10.20.0.0/24 192.168.1.0/24 any -P in ipsec > esp/tunnel/xxx.yyy.40.122-xxx.yyy.40.135/require; > spdadd 192.168.1.0/24 10.20.0.0/24 any -P out ipsec > esp/tunnel/xxx.yyy.40.135-xxx.yyy.40.122/require; > --- End included file --- > > For the test situation, I have set up my ipfilter to allow everything to > pass, both in and out, on both the internal and external interfaces. > Also, I have turned off IPNAT completely. > > I *have* been able to get transport mode working between the two external > interfaces. Racoon successfully exchanged keys, and a perusal of > netstat -sn output showed that IPSEC packets were in fact being passed. > However, tunnel mode between the two internal networks does not produce > any IPSEC packets or key exchange traffic at all. How did you ping? Image this: net ----------- ipsec host ------- some net ----- ipsec host -- 10.0.0.0/24<->10.0.0.1/172.16.1.1 ---------- 172.16.1.2/10.0.1.1<->10.0.1.0/24 Now, if your tunnel should secure all data from 10.0.0.0/24 to 10.0.1.0/24 vice versa, and you ping from 10.0.0.1/172.16.1.1 to 10.0.1.*, what happens is that you will effectively ping from 172.16.1.1 to 10.0.1.*. This is not covered in an SP. So racoon will just sit and do nothing. In this case, you should use 'ping -I' to force the ping-packet go over the interface having 10.0.0.1. In this case, you will ping from 10.0.0.1 to 10.0.1.*, which is covered by a policy. I don't know if this is the cause of your problem, you did not tell from what host to what host you try to ping. It is, however, something to keep in mind. It tricked me too ;-) Grtz, -- Eilko Bos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 11:52:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from www.brasapen.org (www.brasapen.org [193.78.174.81]) by hub.freebsd.org (Postfix) with ESMTP id F3FA937B417 for ; Fri, 16 Nov 2001 11:52:44 -0800 (PST) Received: by www.brasapen.org (Postfix, from userid 1000) id 7E3C91E9F; Fri, 16 Nov 2001 20:52:38 +0100 (CET) Date: Fri, 16 Nov 2001 20:52:38 +0100 From: eilko.bos@brasapen.org To: Tony Saign Cc: freebsd-net@freebsd.org Subject: Re: Microsoft Terminal Services/Remote Desktop Connection Message-ID: <20011116205238.C23528@www.brasapen.org> References: <000001c16ebb$8fb3ceb0$da0b010a@tsaignmobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c16ebb$8fb3ceb0$da0b010a@tsaignmobl>; from tony@saign.com on Fri, Nov 16, 2001 at 08:27:18AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From the keyboard of Tony Saign, written on Fri, Nov 16, 2001 at 08:27:18AM -0800: > Anyone have any ideas on why this program wouldn't work through a > FreeBSD 4.4 system using NAT & IPFW?? > > {Can connect to > Internet host running TS or RDP} > | > | > {Can connect to > Internet host running TS or RDP} > > Neither of these two can connect to each other for some reason?? I deleted the internet-connection on purpose. If I get your situation right, it goes down to the description above? They are on the same network but can't connect to each other? That does not seem a FreeBSD-problem to me. Because (if your network is configured correctly), the bothe machines should, without interference of the firewall, be able to connect to eachother. If I misunderstood excusez moi. Grtz, -- Eilko Bos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 12: 5:49 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 64DAE37B416 for ; Fri, 16 Nov 2001 12:05:47 -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 LAA14671; Fri, 16 Nov 2001 11:51:33 -0800 (PST) Date: Fri, 16 Nov 2001 11:51:31 -0800 (PST) From: Julian Elischer To: Shoichi Sakane Cc: icb-bsd@wi.rr.com, rsmith@vetx.com, freebsd-net@FreeBSD.ORG Subject: Re: Re[2]: IPSEC / RAPTOR Firewall Interaction In-Reply-To: <20011116141045I.sakane@kame.net> 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 The person who you really have to speak to is Andre Oppermann Unfortunatly he just left his job and so I don't have his new email address on me.. I wrote the basic driver for him and he has the legal side of it.. julian On Fri, 16 Nov 2001, Shoichi Sakane wrote: > > What about info in regards to running a FreeBSD IPSEC server (racoon) > > with DHCP clients (road warriors)? I haven't seen anything about that...is it > > possible? If so...any links to info? Thanks in advance. > > racoon can exchange SAs in such a scenario by using "generate_policy" > directive. but there is no documentation. the only one is probably > racoon.conf(5). you know there are some scenario about "road warriors". > also, IKE and IPsec have many tweaks. so there are some solutions to > solve scenarios. here is one of them. > > i'm using a laptop PC and the ip address is assigned dynamically. > i access to the mail server from my laptop. i only use the ipsec > transport mode. i use certificates because this is the way to solve > the scenario with IKE main mode. i attach my configuration to this mail. > > 1. racoon.conf in the laptop. > 2. policy parameter in the laptop. > 3. racoon.conf in the server. > no need server's policy configuration. > > it hope it help you. > > regards, > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 12: 6:10 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 75CB737B419 for ; Fri, 16 Nov 2001 12:06:02 -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 LAA14695; Fri, 16 Nov 2001 11:59:04 -0800 (PST) Date: Fri, 16 Nov 2001 11:59:03 -0800 (PST) From: Julian Elischer To: Mikel King Cc: Chrisy Luke , Julian Elischer , net@FreeBSD.ORG Subject: Re: RFC: ipfirewall_forward patch In-Reply-To: <3BF51DC8.A2AC1549@ocsinternet.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 A "doddle" is "a task so easy that you could do it in your sleep" (BTW the patch has a small bug.. but the fix is trivial.) On Fri, 16 Nov 2001, Mikel King wrote: > Just curious, but what's a doddle? > > Cheers, > mikel > > Julian Elischer wrote: > > > On Thu, 15 Nov 2001, Chrisy Luke wrote: > > > > > only packets already leaving the system can be hijacked and forwarded > > > > > to a 2nd machine. Incoming packets can only be forwarded to local > > > > > addresses/port combinations. > > > > > > My fault. I was being lazy when I wrote it. :) > > > > Ah it WAS you I committed it for wasn't it? :-) > > > > > > > > > > This patch would allow a sequence of mchines to hijack > > > > > a particular conforming packet and pass it allong a chain of > > > > > these machine sot make it fall out somewhere else.. > > > > > > It looks good. The ipfw syntax doesn't quite make sense to me. > > > > They all have different bits masked by the netmask.. > > > > > Also, are you requiring that they all be on the same ipfw rule number? > > > > No, I was lazy.. > > (cut'n'pasted the rules) > > > > > > > > Writing a script to probe a serving host and alter ipfw rules could be > > > done seamlessly if they were on seperate ipfw rules. > > > > well sure.. it's the mechanism not the details I was looking at.. > > Can you check my logic on the changes.? > > I'll be testing it more tonight.. > > > > > > > > With a similar trick to move aliases around on a primary ether port, > > > it's going to be a doddle to setup a clustered-transparent loadbalancer > > > in FreeBSD now. Neat. :) > > > > that's the theory.. > > > > Why make a huge complicated program to do it when > > you can do it with ipfw :-) > > > > > > > > Cheers, > > > Chris. > > > -- > > > == chris@easynet.net T: +44 845 333 0122 > > > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 12:20:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from thoth.upan.org (thoth.upan.org [204.107.76.16]) by hub.freebsd.org (Postfix) with ESMTP id BC0CC37B405 for ; Fri, 16 Nov 2001 12:20:18 -0800 (PST) Received: from ocsinternet.com (localhost [127.0.0.1]) by thoth.upan.org (8.11.3/8.11.3) with ESMTP id fAGJQVZ00852; Fri, 16 Nov 2001 14:26:35 -0500 (EST) (envelope-from mikel@ocsinternet.com) Message-ID: <3BF56867.C17D4EA7@ocsinternet.com> Date: Fri, 16 Nov 2001 14:26:31 -0500 From: Mikel King X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: tony@saign.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: Microsoft Terminal Services/Remote Desktop Connection References: <000001c16ebb$8fb3ceb0$da0b010a@tsaignmobl> 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 believe there's a regedit that you need to perform to enable the termserver to recognise itself behind the firewall. I can't for the life of me remember exactly what, but I know it's in their knowledge base somewhere... cheers, mikel Tony Saign wrote: > Anyone have any ideas on why this program wouldn't work through a > FreeBSD 4.4 system using NAT & IPFW?? > > I can connect to systems outside on the Internet, but not internal > systems on the same subnet. > > INTERNET--- > [1] >> <216.120.x.x> > [2] >> <192.168.1.1> > | > | > {Can connect to > Internet host running TS or RDP} > | > | > {Can connect to > Internet host running TS or RDP} > > Neither of these two can connect to each other for some reason?? > > Thanks in advance, > > -Tony > > 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 16 12:23: 4 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 1404637B416 for ; Fri, 16 Nov 2001 12:22:59 -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 MAA14810; Fri, 16 Nov 2001 12:10:31 -0800 (PST) Date: Fri, 16 Nov 2001 12:10:29 -0800 (PST) From: Julian Elischer To: Shoichi Sakane Cc: icb-bsd@wi.rr.com, rsmith@vetx.com, freebsd-net@FreeBSD.ORG Subject: Re: Re[2]: IPSEC / RAPTOR Firewall Interaction 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 ignore this mail it was sent in error.. the answer was to a different email On Fri, 16 Nov 2001, Julian Elischer wrote: > The person who you really have to speak to is Andre Oppermann > Unfortunatly he just left his job and so I don't have his new email > address on me.. > I wrote the basic driver for him and he has the legal side of it.. > > julian > > On Fri, 16 Nov 2001, Shoichi Sakane wrote: > > > > What about info in regards to running a FreeBSD IPSEC server (racoon) > > > with DHCP clients (road warriors)? I haven't seen anything about that...is it > > > possible? If so...any links to info? Thanks in advance. > > > > racoon can exchange SAs in such a scenario by using "generate_policy" > > directive. but there is no documentation. the only one is probably > > racoon.conf(5). you know there are some scenario about "road warriors". > > also, IKE and IPsec have many tweaks. so there are some solutions to > > solve scenarios. here is one of them. > > > > i'm using a laptop PC and the ip address is assigned dynamically. > > i access to the mail server from my laptop. i only use the ipsec > > transport mode. i use certificates because this is the way to solve > > the scenario with IKE main mode. i attach my configuration to this mail. > > > > 1. racoon.conf in the laptop. > > 2. policy parameter in the laptop. > > 3. racoon.conf in the server. > > no need server's policy configuration. > > > > it hope it help you. > > > > regards, > > > > > 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 16 12:23:11 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 1377537B41A for ; Fri, 16 Nov 2001 12:23:07 -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 MAA14772; Fri, 16 Nov 2001 12:02:52 -0800 (PST) Date: Fri, 16 Nov 2001 12:02:49 -0800 (PST) From: Julian Elischer To: Mikel King Cc: Chrisy Luke , Chrisy Luke , Julian Elischer , net@FreeBSD.ORG Subject: Re: RFC: ipfirewall_forward patch In-Reply-To: <3BF53B71.7DAD1AB7@ocsinternet.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 ethfw should be implemented as a negraph module... (all teh hooks are already there) On Fri, 16 Nov 2001, Mikel King wrote: > Chrisy Luke wrote: > > > Mikel King wrote (on Nov 16): > > > Just curious, but what's a doddle? > > > > It's like a doodle, but with less o's and more d's. :) > > > > It essentially means "this is easy to do". > > > > Chris. > > -- > > == chris@easynet.net T: +44 845 333 0122 > > == Global IP Network Engineering, Easynet Group PLC F: +44 845 333 0122 > > Thanks, I thought so but sometimes you jut have to ask...;) > > On a side note does anyone know of a project to add IP pooling to natd? Or > one to incorperate ethfw into ipfw? > > cheers, > mikel > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 12:33: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id C252C37B41B for ; Fri, 16 Nov 2001 12:32:56 -0800 (PST) Received: from le-cs.cs.unc.edu (IDENT:le@le-cs.cs.unc.edu [152.2.131.150]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id PAA18651 for ; Fri, 16 Nov 2001 15:32:53 -0500 (EST) Date: Fri, 16 Nov 2001 15:32:53 -0500 (EST) From: Nguyen-Tuong Long Le To: Subject: Periodic task 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 all, I run experiments to measure the stability of router queue length. In my experiment set up, I have 7 clients and 7 servers connected to a router via an ELS-100 switch. The 7 clients and 7 servers establish long-lived TCP connections and saturate the router's 10 Mbit link. All machines run FreeBSD 4.3 with the router having the ALTQ 3.0 patch (http://www.csl.sony.co.jp/person/kjc/programs.html). There seems to be some periodic tasks that occur every 20 minutes and draws the queue length to 0. I run several experiments and consistently observe the same pattern. I don't have any cron job on the machines. I have a graph of the router's queue length at http://www.cs.unc.edu/~le/tmp/qlen.png Does anyone know what the problem is and how to solve it? Please kindly reply to me because I am not on the list. Thanks, Long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 12:46: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id DFCDD37B405 for ; Fri, 16 Nov 2001 12:45:48 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 9C7151B220; Fri, 16 Nov 2001 12:45:48 -0800 (PST) Message-ID: <3BF57AFC.B2082EE8@vicor-nb.com> Date: Fri, 16 Nov 2001 12:45:48 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Cc: Chrisy Luke Subject: RFC: ipfirewall_forward patch #2 References: <3BF30699.E8CC9857@vicor-nb.com> <3BF306D2.3A50C4AF@vicor-nb.com> <20011115001610.A6212@flix.net> <20011115002741.B6212@flirble.org> Content-Type: multipart/mixed; boundary="------------7FD9C58AA4767C8D0B1BF5D8" 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. --------------7FD9C58AA4767C8D0B1BF5D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a fixed version of this patch. last one used an unitialised variable. Note: the whole ipfw/fwd scheme is non re-entrant. to fix it and some other parts of the code will require that we gain teh capability of associating extra state with a packet.. e.g. "this packet has been diverted" or "being forwarded to address 1.2.3.4:99" presently these things are stored in global variables and rely on the fact that only one packet is traversing the IP code at a time. This patch is no more or less re-entrant than that which was already there, but it is a weakness I noted. ------previously mentionned stuff -------------- The following patch allows the forwarding of INCOMING packets to an arbitrary next hop controlled by the ipfw fwd command.. Ipfw 'fwd' at present has the following restriction: Only packets already leaving the system can be hijacked and forwarded to a 2nd machine. Incoming packets can only be forwarded to local addresses/port combinations. This patch would allow a sequence of machines to hijack a particular conforming packet and pass it along a chain of these machines to make it fall out somewhere else.. the particular example I have in mind: Incoming tcp sessions being transparently load shared by 4 machines. [internet]---[A.b.c.d]-------[10.2.3.4] \---------[10.2.3.5] \---------[10.2.3.6] \---------[10.2.3.7] on A.b.c.d: ipfw add 1000 fwd 10.2.3.4 tcp from 0.0.0.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.5 tcp from 0.0.1.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.6 tcp from 0.0.2.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 ipfw add 1000 fwd 10.2.3.7 tcp from 0.0.3.0:0.0.3.0 to A.b.c.d 80 in recv fxp0 and on each of the four machines: ipfw add 1000 fwd localhost tcp from any to A.b.c.d 80 in recv fxp0 This is a 4 -way load sharing setup sharing http load across 4 machines (in our case proxies) implemented in 5 lines of ipfw. To the external world it would look as if all requests are being satisfied by A.b.c.d:80. ----------End previous mail------------------------------ An actual machine testing this has the following firewall ruleset: [NET]------[192.168.105.11#192.168.101.1]------[192.168.101.2] \---[192.168.101.3] 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00700 14781 20110386 allow ip from 192.168.105.11 to any out xmit fxp1 00750 14603 20084922 allow tcp from 192.168.105.11 80 to any in recv fxp0 00990 5541 288132 fwd 192.168.101.3 tcp from 0.0.0.0:0.0.0.1 to 192.168.105.11 80 in recv fxp1 01000 5701 228040 fwd 192.168.101.2 tcp from 0.0.0.1:0.0.0.1 to 192.168.105.11 80 in recv fxp1 02000 193 8288 divert 8668 ip from any to any in recv fxp1 02000 0 0 divert 8668 ip from any to any out xmit fxp1 65000 193 8288 allow ip from any to any This includes efficient rules for divert to natd (efficient means I don't divert packets that could not be nat'd and natd will just leave untouched) It also leaves unforwarded and un-nat'd packets returning from the proxies.. with 2wo proxies runnung flat out, load on the load-shareing machine was about 3% of cpu, shared between interrupt and system time. Notice that the natd is almost inactive. All requests to 192.168.105.11 80 are actually satisfied on 192.168.101.2 and 192.168.101.3 the proxies have the additional ipfw line: 01000 fwd localhost tcp from any to 192.168.105.11 80 in recv fxp1 I would certainly like some people with knowledge of the IP code to check the patch. Also, anyone with ideas on how to make ipfw, divert and ipfw-fwd to be more re-entrant, I'd like to hear from you.. --------------7FD9C58AA4767C8D0B1BF5D8 Content-Type: text/plain; charset=us-ascii; name="thediff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="thediff" Index: ip_input.c =================================================================== RCS file: /usr/home/cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.25 diff -u -r1.130.2.25 ip_input.c --- ip_input.c 2001/08/29 21:41:37 1.130.2.25 +++ ip_input.c 2001/11/14 23:41:20 @@ -1587,21 +1587,29 @@ int error, type = 0, code = 0; struct mbuf *mcopy; n_long dest; + struct in_addr pkt_dst; struct ifnet *destifp; #ifdef IPSEC struct ifnet dummyifp; #endif dest = 0; + /* + * Cache the destination address of the packet; this may be + * changed by use of 'ipfw fwd'. + */ + pkt_dst = ip_fw_fwd_addr == NULL ? + ip->ip_dst : ip_fw_fwd_addr->sin_addr; + #ifdef DIAGNOSTIC if (ipprintfs) printf("forward: src %lx dst %lx ttl %x\n", - (u_long)ip->ip_src.s_addr, (u_long)ip->ip_dst.s_addr, + (u_long)ip->ip_src.s_addr, (u_long)pkt_dst.s_addr, ip->ip_ttl); #endif - if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(ip->ip_dst) == 0) { + if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(pkt_dst) == 0) { ipstat.ips_cantforward++; m_freem(m); return; @@ -1620,14 +1628,14 @@ sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; if ((rt = ipforward_rt.ro_rt) == 0 || - ip->ip_dst.s_addr != sin->sin_addr.s_addr) { + pkt_dst.s_addr != sin->sin_addr.s_addr) { if (ipforward_rt.ro_rt) { RTFREE(ipforward_rt.ro_rt); ipforward_rt.ro_rt = 0; } sin->sin_family = AF_INET; sin->sin_len = sizeof(*sin); - sin->sin_addr = ip->ip_dst; + sin->sin_addr = pkt_dst; rtalloc_ign(&ipforward_rt, RTF_PRCLONING); if (ipforward_rt.ro_rt == 0) { @@ -1674,7 +1682,7 @@ if (rt->rt_ifp == m->m_pkthdr.rcvif && (rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 && satosin(rt_key(rt))->sin_addr.s_addr != 0 && - ipsendredirects && !srcrt) { + ipsendredirects && !srcrt && !ip_fw_fwd_addr) { #define RTA(rt) ((struct in_ifaddr *)(rt->rt_ifa)) u_long src = ntohl(ip->ip_src.s_addr); @@ -1683,7 +1691,7 @@ if (rt->rt_flags & RTF_GATEWAY) dest = satosin(rt->rt_gateway)->sin_addr.s_addr; else - dest = ip->ip_dst.s_addr; + dest = pkt_dst.s_addr; /* Router requirements says to only send host redirects */ type = ICMP_REDIRECT; code = ICMP_REDIRECT_HOST; Index: ip_output.c =================================================================== RCS file: /usr/home/cvs/src/sys/netinet/ip_output.c,v retrieving revision 1.99.2.16 diff -u -r1.99.2.16 ip_output.c --- ip_output.c 2001/07/19 06:37:26 1.99.2.16 +++ ip_output.c 2001/11/15 23:35:53 @@ -135,6 +135,7 @@ struct sockaddr_in *dst; struct in_ifaddr *ia = NULL; int isbroadcast, sw_csum; + struct in_addr pkt_dst; #ifdef IPSEC struct route iproute; struct socket *so = NULL; @@ -204,6 +205,9 @@ hlen = len; } ip = mtod(m, struct ip *); + pkt_dst = ip_fw_fwd_addr == NULL + ? ip->ip_dst : ip_fw_fwd_addr->sin_addr; + /* * Fill in IP header. */ @@ -227,14 +231,14 @@ * and is still up. If not, free it and try again. */ if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 || - dst->sin_addr.s_addr != ip->ip_dst.s_addr)) { + dst->sin_addr.s_addr != pkt_dst.s_addr)) { RTFREE(ro->ro_rt); ro->ro_rt = (struct rtentry *)0; } if (ro->ro_rt == 0) { dst->sin_family = AF_INET; dst->sin_len = sizeof(*dst); - dst->sin_addr = ip->ip_dst; + dst->sin_addr = pkt_dst; } /* * If routing to interface only, @@ -279,7 +283,7 @@ else isbroadcast = in_broadcast(dst->sin_addr, ifp); } - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + if (IN_MULTICAST(ntohl(pkt_dst.s_addr))) { struct in_multi *inm; m->m_flags |= M_MCAST; @@ -325,7 +329,7 @@ } } - IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); + IN_LOOKUP_MULTI(pkt_dst, ifp, inm); if (inm != NULL && (imo == NULL || imo->imo_multicast_loop)) { /* @@ -575,8 +579,9 @@ /* * Check with the firewall... + * but not if we are already being fwd'd from a firewall. */ - if (fw_enable && ip_fw_chk_ptr) { + if (fw_enable && ip_fw_chk_ptr && !ip_fw_fwd_addr) { struct sockaddr_in *old = dst; off = (*ip_fw_chk_ptr)(&ip, @@ -767,6 +772,7 @@ goto done; } + ip_fw_fwd_addr = NULL; pass: m->m_pkthdr.csum_flags |= CSUM_IP; sw_csum = m->m_pkthdr.csum_flags & ~ifp->if_hwassist; --------------7FD9C58AA4767C8D0B1BF5D8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 15:48:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 6AFE337B416; Fri, 16 Nov 2001 15:48:37 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 2A9721B219; Fri, 16 Nov 2001 15:48:37 -0800 (PST) Message-ID: <3BF5A5D5.3D408744@vicor-nb.com> Date: Fri, 16 Nov 2001 15:48:37 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Subject: re-entrancy and the IP stack. 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 For work related erasons I've been in the IP stack (basically just IP actually) recently. It's obvious that there are re-entrancy problems there. Here are two examples.. Routed packets: a packet that is routed, uses a single static 'route' entry... (In ip_input.c) Right next to it is a sockaddr_in that is used by outgoing icmp packets. static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; struct route ipforward_rt; Obviously there cannot be more than one packet being routed at a time, and no more than one ICMP packet being generated at a time. As another example, the ipfw code uses a couple of static variables too, in the 'fwd' code amongst other places.. What is needed is obviously a 'per packet' storage location for those things, defined in a "per protocol family" manner. Luigi has already tried this scheme by defining a dummynet specific mbuf type that can be prepended to the front of packets. What I suggest is to extend this to defining a MT_PROTOSTORAGE. (or similar) mbuf type that generic networking code is educated to ignore, and that protocols can use to pass packet-specific state information from one place to another. The netgraph code already has a simialr mechanism, in that data is always (optionally) accompanied by a metadata structure, the format of which is predefined in such a way that allows extensibility and transparency. What I would like to do is to combine these two methods: i.e. use the extensible format, embedded in a specially marked mbuf, prepended onto the packets (or post-pended?). The format of the data within the mbuf should have the following characteristics: 1/ It should identify the interface that defines that data, (so that modules can identify their own metadata/information) 2/ It should define in a standard way, its size. 3/ Metadata from several modules should be capable of being added to a packet at the same time, either by adding more mbufs or by adding more self-identifying data to an already existing mbuf. 4/ Registered modules should be called to "disarm" their metadata if the packet is deleted.. Metadata should be able to indicate if it needs to be disarmed or can be just freed. An example for data needed in IP packets: [sizeof(struct route)][IP-ID]["Forwarding Route" ID][struct route] [sizeof(struct sockaddr_in)][IP_ID]["Dest-addr" ID][struct sockaddr_in] [sizeof(struct sockaddr_in)][IP_ID]["Fwd-destaddr" ID][struct sockaddr_in] These would be packed in a MT_PROTOSTORAGE mbuf and prepended to packets being routeds or forwarded, (or whatever) so that each packet would carry with it whatever information was needed to be handled correctly. It could also (for example) be handed to a 3rd party module (e.g. a firewall) which could queue the packet (or similar) and not have to worry about losing 'hidden' state being held elsewhere. Any comments? (obviously we'd have to educate code to skip or ignore these packets if they didn't have any use for them.) But we are going to need to do something like this to make some of the code re-entrant eventually! Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 16: 2:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id E465637B405; Fri, 16 Nov 2001 16:02:51 -0800 (PST) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fAH02pM29425; Fri, 16 Nov 2001 16:02:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A13B93811; Fri, 16 Nov 2001 16:02:51 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <3BF5A5D5.3D408744@vicor-nb.com> Date: Fri, 16 Nov 2001 16:02:51 -0800 From: Peter Wemm Message-Id: <20011117000251.A13B93811@overcee.netplex.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 Julian Elischer wrote: [..] > What is needed is obviously a 'per packet' storage location > for those things, defined in a "per protocol family" manner. > > Luigi has already tried this scheme by defining a > dummynet specific mbuf type that can be prepended to the > front of packets. What I suggest is to extend this > to defining a MT_PROTOSTORAGE. (or similar) mbuf type > that generic networking code is educated to ignore, > and that protocols can use to pass packet-specific state > information from one place to another. Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system for this. We went to a lot of trouble (well, Garrett specifically) to rid the stacks of this obscenity. Do *NOT* generalize it and undo it. MT_DUMMYNET must die, not be propagated elsewhere. If you want to have some general storage mechnaism, do *not* use mbufs for it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 16: 7: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 CCB8437B416; Fri, 16 Nov 2001 16:07:45 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAH03c585728; Fri, 16 Nov 2001 16:03:38 -0800 (PST) (envelope-from rizzo) Date: Fri, 16 Nov 2001 16:03:38 -0800 From: Luigi Rizzo To: Julian Elischer Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. Message-ID: <20011116160338.A85435@iguana.aciri.org> References: <3BF5A5D5.3D408744@vicor-nb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF5A5D5.3D408744@vicor-nb.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 struct pkthdr already has a field (struct mbuf *aux) which i think is used to store info per-packet state by ipsec, at least according to the comment (my dummynet hack predated this, i would have used this field if it had been available at the time). So this field could be used to access the metadata. Unfortunately i suspect that making a truly extensible format is going to kill performance, because each module would have to hunt its own metadata in the chain. I'd rather go with specific fields in the pkthdr pointing/storing specific info (if you think of it, this is what the pkthdr is. 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 16 16: 9: 0 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 2D3FF37B419; Fri, 16 Nov 2001 16:08:58 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAH04wd85759; Fri, 16 Nov 2001 16:04:58 -0800 (PST) (envelope-from rizzo) Date: Fri, 16 Nov 2001 16:04:58 -0800 From: Luigi Rizzo To: Peter Wemm Cc: Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. Message-ID: <20011116160458.B85435@iguana.aciri.org> References: <3BF5A5D5.3D408744@vicor-nb.com> <20011117000251.A13B93811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011117000251.A13B93811@overcee.netplex.com.au> 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 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote: > it. MT_DUMMYNET must die, not be propagated elsewhere. i agree! 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 16 16:16:29 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 8325E37B418; Fri, 16 Nov 2001 16:16:23 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 3EE9981D01; Fri, 16 Nov 2001 18:16:18 -0600 (CST) Date: Fri, 16 Nov 2001 18:16:18 -0600 From: Alfred Perlstein To: Peter Wemm Cc: Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. Message-ID: <20011116181618.A13393@elvis.mu.org> References: <3BF5A5D5.3D408744@vicor-nb.com> <20011117000251.A13B93811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011117000251.A13B93811@overcee.netplex.com.au>; from peter@wemm.org on Fri, Nov 16, 2001 at 04:02:51PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Peter Wemm [011116 18:02] wrote: > Julian Elischer wrote: > [..] > > What is needed is obviously a 'per packet' storage location > > for those things, defined in a "per protocol family" manner. > > > > Luigi has already tried this scheme by defining a > > dummynet specific mbuf type that can be prepended to the > > front of packets. What I suggest is to extend this > > to defining a MT_PROTOSTORAGE. (or similar) mbuf type > > that generic networking code is educated to ignore, > > and that protocols can use to pass packet-specific state > > information from one place to another. > > Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system > for this. We went to a lot of trouble (well, Garrett specifically) > to rid the stacks of this obscenity. Do *NOT* generalize it and undo > it. MT_DUMMYNET must die, not be propagated elsewhere. > > If you want to have some general storage mechnaism, do *not* use mbufs > for it. *cough* kthread_setspecific() *cough* kthread_getspecific() *cough* or just fix the code to pass this around as an extra paramter. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 16: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 9CA7C37B419; Fri, 16 Nov 2001 16: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 QAA15655; Fri, 16 Nov 2001 16:13:42 -0800 (PST) Date: Fri, 16 Nov 2001 16:13:41 -0800 (PST) From: Julian Elischer To: Peter Wemm Cc: Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011117000251.A13B93811@overcee.netplex.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 I don't care exactly how we do it but we need to figure out a way of storing such metadata along with packets. and it needs to be queueable along with the packets.. (sounds like an mbuf to me but if you have a better idea.....) (and anyhow Garrett got rid of the 'static' uses of mbufs, not 'travelling' 'per packet' uses..) On Fri, 16 Nov 2001, Peter Wemm wrote: > Julian Elischer wrote: > [..] > > What is needed is obviously a 'per packet' storage location > > for those things, defined in a "per protocol family" manner. > > > > Luigi has already tried this scheme by defining a > > dummynet specific mbuf type that can be prepended to the > > front of packets. What I suggest is to extend this > > to defining a MT_PROTOSTORAGE. (or similar) mbuf type > > that generic networking code is educated to ignore, > > and that protocols can use to pass packet-specific state > > information from one place to another. > > Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system > for this. We went to a lot of trouble (well, Garrett specifically) > to rid the stacks of this obscenity. Do *NOT* generalize it and undo > it. MT_DUMMYNET must die, not be propagated elsewhere. > > If you want to have some general storage mechnaism, do *not* use mbufs > for it. > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > 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 16 16:24:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id B9D3E37B416; Fri, 16 Nov 2001 16:24:34 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 7E1AF1B219; Fri, 16 Nov 2001 16:24:34 -0800 (PST) Message-ID: <3BF5AE42.49D5D83B@vicor-nb.com> Date: Fri, 16 Nov 2001 16:24:34 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Alfred Perlstein Cc: Peter Wemm , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. References: <3BF5A5D5.3D408744@vicor-nb.com> <20011117000251.A13B93811@overcee.netplex.com.au> <20011116181618.A13393@elvis.mu.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 Alfred Perlstein wrote: > > * Peter Wemm [011116 18:02] wrote: > > Julian Elischer wrote: > > [..] > > > What is needed is obviously a 'per packet' storage location > > > for those things, defined in a "per protocol family" manner. > > > > > > Luigi has already tried this scheme by defining a > > > dummynet specific mbuf type that can be prepended to the > > > front of packets. What I suggest is to extend this > > > to defining a MT_PROTOSTORAGE. (or similar) mbuf type > > > that generic networking code is educated to ignore, > > > and that protocols can use to pass packet-specific state > > > information from one place to another. > > > > Uhh.. no thanks. Whatever you do, do *NOT* abuse the mbuf system > > for this. We went to a lot of trouble (well, Garrett specifically) > > to rid the stacks of this obscenity. Do *NOT* generalize it and undo > > it. MT_DUMMYNET must die, not be propagated elsewhere. > > > > If you want to have some general storage mechnaism, do *not* use mbufs > > for it. > > *cough* > kthread_setspecific() > *cough* > kthread_getspecific() > *cough* packets can be re-ordered due to queueing etc. (* we should not be trying to decide at this point what a 3rd part module may or may not want to do). I think it needs to be storage associated with the packet. > > or just fix the code to pass this around as an extra paramter. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 16:40:34 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 CFCD537B41A; Fri, 16 Nov 2001 16:40:27 -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 QAA15761; Fri, 16 Nov 2001 16:33:19 -0800 (PST) Date: Fri, 16 Nov 2001 16:33:17 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011116160458.B85435@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 On Fri, 16 Nov 2001, Luigi Rizzo wrote: > On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote: > > > it. MT_DUMMYNET must die, not be propagated elsewhere. > > i agree! > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > so far there hasn't been a lot of suggestion as to how the goal can be achieved however.. things it should be: 1/ flexible 2/ queueable 3/ transparent to 3rd party code that doesn't know about it. i.e. if I have metadata with a packet that is passed to a packet filter, that decides that it should be queued (like dummynet), I want the dequeued packet to still have that metadata with it. If I give it to an encryption module, and get it back I don't want the encryption module to have deleted the metadata. We do this in netgraph successfully, where we can store packet priority data (for example) to ensure that housekeeping packets overtake data packets in frame relay. (if you don't do this the fram relay exchange will shot down the link when it gets busy and the housekeeping packets are delayed). We also include data to do with throughput limits and clasification after it has passed though a classifier node. You can't do these things unless you have per-packet information. The idea of the (struct mbuf * m_aux) field is fine by me but that is still using an mbuf, which some people seem to be against.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 17: 6:41 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 125B437B418; Fri, 16 Nov 2001 17:06:38 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fAH12FO86173; Fri, 16 Nov 2001 17:02:15 -0800 (PST) (envelope-from rizzo) Date: Fri, 16 Nov 2001 17:02:15 -0800 From: Luigi Rizzo To: Julian Elischer Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. Message-ID: <20011116170214.A86121@iguana.aciri.org> References: <20011116160458.B85435@iguana.aciri.org> 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 > so far there hasn't been a lot of suggestion as to how the goal can be > achieved however.. i actually suggested one i.e. have explicit pointers to metadata area(s) in the pkthdr. I think you forget the most fundamental feature which is performance. This is way more important than flexibility i think. > things it should be: > > 1/ flexible > 2/ queueable > 3/ transparent to 3rd party code that doesn't know about it. 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 16 17: 8:50 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 1B4A237B419; Fri, 16 Nov 2001 17:08:44 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAH18d144195; Fri, 16 Nov 2001 20:08:39 -0500 (EST) (envelope-from wollman) Date: Fri, 16 Nov 2001 20:08:39 -0500 (EST) From: Garrett Wollman Message-Id: <200111170108.fAH18d144195@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: References: <20011117000251.A13B93811@overcee.netplex.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: > (and anyhow Garrett got rid of the 'static' uses > of mbufs, not 'travelling' 'per packet' uses..) Only because I did not have the time or stomach then to introduce `struct packet' everywhere. All of the queueing and metadata crap should be pulled out of mbufs and put into a higher-level object. It's OK if the higher-level object HAS_A(mbuf), but not IS_A(mbuf). This is A Lot Of Work, but would seriously clean up the code in a number of areas. As a general rule, though, reentrancy was not a particular concern of the original design -- that's why there are queues and soft ISRs all over the place -- because you would blow the kernel stack long before that became an issue. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 17:20:34 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 53E2737B41D; Fri, 16 Nov 2001 17:20:16 -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 RAA15938; Fri, 16 Nov 2001 17:11:40 -0800 (PST) Date: Fri, 16 Nov 2001 17:11:39 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011116170214.A86121@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 ok, so how would you envision it? example? Adding fields to the pkthdr? (and flags to say what they are used for). A pointer to route, (maybe the route in ip_forward() can be dynamically allocated on the stack, I'm not sure yet) A pointer to a sockaddr, with a flag to say if it's for 'fwd' use or 'xmit' use. (but they may both be needed together).. can we guarantee that these will be freed correctly when the mbuf is freed? On Fri, 16 Nov 2001, Luigi Rizzo wrote: > > so far there hasn't been a lot of suggestion as to how the goal can be > > achieved however.. > > i actually suggested one i.e. have explicit pointers > to metadata area(s) in the pkthdr. I think you forget the > most fundamental feature which is performance. > This is way more important than flexibility i think. > > > things it should be: > > > > 1/ flexible > > 2/ queueable > > 3/ transparent to 3rd party code that doesn't know about it. > > 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 16 17:40:30 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 4671D37B416; Fri, 16 Nov 2001 17:40:13 -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 RAA16006; Fri, 16 Nov 2001 17:29:25 -0800 (PST) Date: Fri, 16 Nov 2001 17:29:23 -0800 (PST) From: Julian Elischer To: Garrett Wollman Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <200111170108.fAH18d144195@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 Fri, 16 Nov 2001, Garrett Wollman wrote: > < said: > > > (and anyhow Garrett got rid of the 'static' uses > > of mbufs, not 'travelling' 'per packet' uses..) > > Only because I did not have the time or stomach then to introduce > `struct packet' everywhere. All of the queueing and metadata crap > should be pulled out of mbufs and put into a higher-level object. > It's OK if the higher-level object HAS_A(mbuf), but not IS_A(mbuf). In netgraph, (in -current) we have a packet structure that has links for A) mbufs for the data, and B) optinal metadata. I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE, to stash the metadata. > > This is A Lot Of Work, but would seriously clean up the code in a > number of areas. I'm not afraid of the work, but there needs to be a roadmap first. > > As a general rule, though, reentrancy was not a particular concern of > the original design -- that's why there are queues and soft ISRs all > over the place -- because you would blow the kernel stack long before > that became an issue. True, but times change and we have to cross that bridge soon.. > > -GAWollman > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 17:40:35 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 6040437B422; Fri, 16 Nov 2001 17:40: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 RAA15998; Fri, 16 Nov 2001 17:23:22 -0800 (PST) Date: Fri, 16 Nov 2001 17:23:21 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011116170214.A86121@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 On Fri, 16 Nov 2001, Luigi Rizzo wrote: > > so far there hasn't been a lot of suggestion as to how the goal can be > > achieved however.. > > i actually suggested one i.e. have explicit pointers > to metadata area(s) in the pkthdr. I think you forget the > most fundamental feature which is performance. > This is way more important than flexibility i think. Which is the reason that this problem exists.. no-one ever thinks that people will want to do things different to what they want to do at the time they write it.. Flexibility is I think much more important than you suggest. Wouldn't it have made it easier for you if there had been a flexible method to pass such information available? The m_aux field sounds right to me. Alternatively, the ability to define a separate data area in an M_HDR mbuf.. (There's a lot of wasted space there in M_EXT packets.) [normal header][pkthdr][METADATA][normal_data] The metadata would be there regardless of whether the M_EXT flag was set or not. > > > things it should be: > > > > 1/ flexible I.e Don't screw over Luigi's NEXT project, Dummynet2. > > 2/ queueable I want to let dummynet2 do queuing of packets and keep my 'class' information with each packet. > > 3/ transparent to 3rd party code that doesn't know about it. I don't want My module to have to know about the stuff Dummynet2 is storing with the packet, and I don't want dummynet2 to need to know what I have stashed in there.. 4/ Self-descriptive: If I free a packet, I shouldn't produce a leak of some other items somewhere else. (they should describe how they should be freed!) > > 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 16 18:18:51 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 3B92B37B419 for ; Fri, 16 Nov 2001 18:18:49 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAH2IjE45093; Fri, 16 Nov 2001 21:18:45 -0500 (EST) (envelope-from wollman) Date: Fri, 16 Nov 2001 21:18:45 -0500 (EST) From: Garrett Wollman Message-Id: <200111170218.fAH2IjE45093@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: References: <200111170108.fAH18d144195@khavrinen.lcs.mit.edu> 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: > I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE, > to stash the metadata. Mind, you don't put the metadata there; you put that in the packet structure (or rather, in the ip_packet etc. structures). I'd like to get rid of mbufs entirely, but that's a whole 'nother kettle o' fish. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 16 20:23: 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 7301E37B416; Fri, 16 Nov 2001 20:22:53 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAH4MPi30016; Fri, 16 Nov 2001 23:22:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Nov 2001 23:22:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Luigi Rizzo Cc: Julian Elischer , Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <20011116170214.A86121@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 In my MAC tree, I add an additional: struct mbuf *aux; /* extra data buffer; ipsec/others */ + struct mac label; /* label of data in packet */ }; As we move towards more generalized access control, it would similarly be nice to have a place to 'hang' additional labeling information for network transmission objects (packets, control messages, whatever). One of my primary concerns for such as system, and one of the reasons I haven't seriously contemplated implementing it, is how to maintain performance. In a non-SMPng world, it's already an issue, but once you throw in fine-grained locking/etc, you begin to worry about locking and referencing counting for these objects. Ideally, I think such as 'hooking' mechanism would be extremely flexible and transparent, but as you point out, performance is (and will continue to be) a primary concern in this code. It might be interesting to do some experimentation with various schemes for adding this extensibility. I've done a little bit of work to look at run-time vs. compile-time extensibility for the network stack. For example, I'm interested in the idea that the TCP/IP IPv4 implementation be pluggable via a kernel module. Adding such dynamicism would necessarily introduce locking/atomicity concerns during registration and removal. I'd like for it to be the case that if you link the module in at compile time (or before the kernel goes live during the boot), you'd maintain current native speed, but that if you dynamically load it, you accept the additional cost. One way to do this might be to have an optimized dynamically compiled structure (maybe derived from linker sets) either when the kernel is compiled or linked, for "fast path" processing. When there is a fast path miss, then the kernel falls back to a slower dynamic path. E.g., const struct ipproto *ipprotolist[] = {, , , ... NULL}; struct mtx ipprotolist_extensions_lock; struct ipproto *ipprotolist_extensions[]; Fast path hits would not require use of the mutex, but slow path would; dynamically introduced protocols would by definition be on the slow path, but if compiled in, would be attached to the fast path. Likewise, you could imagine mbuf extensibility working the same way: depending on how to consuming feature is loaded, it is provided a lock-free/fast extension capability, and if it is dynamically loaded, the slower alternative is selected. This would allow many locking costs to be avoided in the network code for optimized environment, but still allow the necessarily expensive extensibility. Just a thought. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 16 Nov 2001, Luigi Rizzo wrote: > > so far there hasn't been a lot of suggestion as to how the goal can be > > achieved however.. > > i actually suggested one i.e. have explicit pointers > to metadata area(s) in the pkthdr. I think you forget the > most fundamental feature which is performance. > This is way more important than flexibility i think. > > > things it should be: > > > > 1/ flexible > > 2/ queueable > > 3/ transparent to 3rd party code that doesn't know about it. > > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 8:54:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f178.pav2.hotmail.com [64.4.37.178]) by hub.freebsd.org (Postfix) with ESMTP id 23D2037B41B for ; Sat, 17 Nov 2001 08:54:29 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 17 Nov 2001 08:54:28 -0800 Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 17 Nov 2001 16:54:28 GMT X-Originating-IP: [204.178.20.14] From: "murthy kn" To: net@FreeBSD.ORG Subject: TCP Fast Retransmit Date: Sat, 17 Nov 2001 22:24:28 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2001 16:54:28.0943 (UTC) FILETIME=[85855DF0:01C16F88] 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, 1. Is there any sysctl variable to control the number of duplicate acks after which the sending TCP gets into a fast retransmit mode? 2. If I have a switch that does not support any port aggregation, and it is connected to a BSD machine with 2 ethernet NICs that have identical MAC, will the switch forward *each* packet destined to the BSD machine to both of the NICs. 3. Apart from using tcpdump, are there any other tools/ways to analyze the dynamic behaviour of a BSD stack - like knowing when there have been retransmits, the state of various buffers in the stack etc. Thanks for your time. Murthy _________________________________________________________________ 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 Sat Nov 17 10:21:54 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 0306E37B405 for ; Sat, 17 Nov 2001 10:21:50 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id fAHIKBw94562; Sat, 17 Nov 2001 12:20:11 -0600 (CST) (envelope-from jlemon) Date: Sat, 17 Nov 2001 12:20:11 -0600 (CST) From: Jonathan Lemon Message-Id: <200111171820.fAHIKBw94562@prism.flugsvamp.com> To: knmurthy30@hotmail.com, net@freebsd.org Subject: Re: TCP Fast Retransmit X-Newsgroups: local.mail.freebsd-net In-Reply-To: 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: >Hello, > >1. Is there any sysctl variable to control the number of >duplicate acks after which the sending TCP gets into a fast >retransmit mode? No, but the current limit is in tcp_input.c: static int tcprexmtthresh = 3; so you can easily change this. >2. If I have a switch that does not support any port aggregation, >and it is connected to a BSD machine with 2 ethernet NICs that have >identical MAC, will the switch forward *each* packet destined to the BSD >machine to both of the NICs. Unlikely. The switch will probably allow only one mac->port mapping. >3. Apart from using tcpdump, are there any other tools/ways to analyze the >dynamic behaviour of a BSD stack - like knowing when there have >been retransmits, the state of various buffers in the stack etc. I like tcptrace, but that is an external view. You could try turning on the TCPDEBUG #define, although I'm not sure how useful it would be. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 13:29: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from alf.uib.no (alf.uib.no [129.177.30.3]) by hub.freebsd.org (Postfix) with ESMTP id 118F637B417 for ; Sat, 17 Nov 2001 13:29:03 -0800 (PST) Received: from tunnel-45-12.vpn.uib.no (ii.uib.no) [129.177.45.12] by alf.uib.no with esmtp (Exim 3.16) id 165D0f-0005k4-00; Sat, 17 Nov 2001 22:28:22 +0100 Message-ID: <3BF6D769.9000902@ii.uib.no> Date: Sat, 17 Nov 2001 22:32:25 +0100 From: Trond Davidsen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010909 X-Accept-Language: en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Mpd and pap authentication Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *165D0f-0005k4-00*BwmXBrqaO..* http://tjinfo.uib.no/virus.html 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, there seems to be a bug in mpd in the handling of PAP Authenticate-Ack's. RFC 1334 section 2.2.2 specifies the packet format to look something like the following: | Code | Identifier | Length | Msg-Length | Message | Mpd leaves out the Msg-Length field, which confuses at least one ppp implementation, namely pppd (used in FreeBSD, Linux, MacOSX, ...). Trond To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 14:16:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by hub.freebsd.org (Postfix) with ESMTP id 37DFF37B405; Sat, 17 Nov 2001 14:16:10 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAHMG8c72686; Sat, 17 Nov 2001 14:16:08 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id OAA434145; Sat, 17 Nov 2001 14:15:55 -0800 (PST) Message-Id: <200111172215.OAA434145@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: Alfred Perlstein , Peter Wemm , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: Message from Julian Elischer of "Fri, 16 Nov 2001 16:24:34 PST." <3BF5AE42.49D5D83B@vicor-nb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Nov 2001 14:18:21 -0800 From: "George V. Neville-Neil" 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 Are y'all going to discuss this at BSDCon? I'm probably going there and would like to contribute if I could. Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 14:16:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23]) by hub.freebsd.org (Postfix) with ESMTP id 9A2F937B417; Sat, 17 Nov 2001 14:16:10 -0800 (PST) Received: from meer.meer.net (mail.meer.net [209.157.152.14]) by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAHMGAc72689; Sat, 17 Nov 2001 14:16:10 -0800 (PST) Received: from neville-neil.com ([209.157.133.226]) by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id OAA421007; Sat, 17 Nov 2001 14:15:07 -0800 (PST) Message-Id: <200111172215.OAA421007@meer.meer.net> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: Message from Julian Elischer of "Fri, 16 Nov 2001 16:13:41 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Nov 2001 14:17:32 -0800 From: "George V. Neville-Neil" 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 recommend you all look at The Click Modular router http://www.pdos.lcs.mit.edu/click/ which is a step in the right direction. Of course given the current architecture it may be very hard to adapt it to this kind of model. I led/worked on a project at Wind River Systems to do a multi-instance stack based off of the 4.4 BSD lite code. I can tell you that without quite a bit of rearchitecting what you get is always a hack. There are (were?) over 100 global variables in the 4.4BSD lite code. I've not counted on 4.4 or -CURRENT so I can't say. There are also the issues of the locks though I suspect in -CURRENT (since the kernel is MP) you have handled these in some way. An extensible, multi-threaded TCP/IP would NOT look like the 4.4BSD-Lite code. Is this a goal of FreeBSD now? I am working on some things to make this possible but it is independent of FreeBSD and very very early days as yet. Later, George To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 16: 8:11 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 ED79737B416 for ; Sat, 17 Nov 2001 16:08:08 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id AF46181D06; Sat, 17 Nov 2001 18:08:03 -0600 (CST) Date: Sat, 17 Nov 2001 18:08:03 -0600 From: Alfred Perlstein To: murthy kn Cc: net@FreeBSD.ORG Subject: Re: TCP Fast Retransmit Message-ID: <20011117180803.D13393@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knmurthy30@hotmail.com on Sat, Nov 17, 2001 at 10:24:28PM +0530 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 * murthy kn [011117 10:54] wrote: > Hello, > > 1. Is there any sysctl variable to control the number of > duplicate acks after which the sending TCP gets into a fast > retransmit mode? No, but you can add one like so (i think): Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.141 diff -u -r1.141 tcp_input.c --- tcp_input.c 12 Sep 2001 08:37:54 -0000 1.141 +++ tcp_input.c 18 Nov 2001 00:09:51 -0000 @@ -101,6 +101,9 @@ MALLOC_DEFINE(M_TSEGQ, "tseg_qent", "TCP segment queue entry"); static int tcprexmtthresh = 3; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, + &tcprexmtthresh, 0, "Max duplicate acks before fast rexmit"); + tcp_cc tcp_ccgen; struct tcpstat tcpstat; > 2. If I have a switch that does not support any port aggregation, > and it is connected to a BSD machine with 2 ethernet NICs that have > identical MAC, will the switch forward *each* packet destined to the BSD > machine to both of the NICs. > > 3. Apart from using tcpdump, are there any other tools/ways to analyze the > dynamic behaviour of a BSD stack - like knowing when there have > been retransmits, the state of various buffers in the stack etc. netstat. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 16:14:26 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 AB84537B416; Sat, 17 Nov 2001 16:14:21 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 7EE6C81D01; Sat, 17 Nov 2001 18:14:21 -0600 (CST) Date: Sat, 17 Nov 2001 18:14:21 -0600 From: Alfred Perlstein To: "George V. Neville-Neil" Cc: Julian Elischer , Peter Wemm , Julian Elischer , current@FreeBSD.ORG, net@FreeBSD.ORG, wollman@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. Message-ID: <20011117181421.E13393@elvis.mu.org> References: <200111172215.OAA421007@meer.meer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111172215.OAA421007@meer.meer.net>; from gnn@neville-neil.com on Sat, Nov 17, 2001 at 02:17:32PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * George V. Neville-Neil [011117 16:17] wrote: > I recommend you all look at The Click Modular router > > http://www.pdos.lcs.mit.edu/click/ > > which is a step in the right direction. > > Of course given the current architecture it may be very hard > to adapt it to this kind of model. > > I led/worked on a project at Wind River Systems to do a multi-instance > stack based off of the 4.4 BSD lite code. I can tell you that without > quite a bit of rearchitecting what you get is always a hack. Actually, usually when you rearchitect what you get is a hack to allow multi-instance instead of relying on tried and true algorithms like Van Jacobson. :) > There are (were?) over 100 global variables in the 4.4BSD lite code. I've > not counted on 4.4 or -CURRENT so I can't say. There are also the issues > of the locks though I suspect in -CURRENT (since the kernel is MP) you > have handled these in some way. > > An extensible, multi-threaded TCP/IP would NOT look like the 4.4BSD-Lite code. I really can't agree with this, there isn't all that much that makes the version of the stack in FreeBSD not modular, I usually find that with enough study one quickly learns why things are done versus immediatly screaming "this needs to be rewritten so that _I_ can understand it." > Is this a goal of FreeBSD now? I am working on some things to make this > possible > but it is independent of FreeBSD and very very early days as yet. The goal right now is more MPsafe than extensable, an extensable stack would be an interesting project but I doubt it would be as stable nor as fast as what we already have. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 16:51:10 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 9AA7A37B405; Sat, 17 Nov 2001 16:51:07 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 802C781D01; Sat, 17 Nov 2001 18:51:02 -0600 (CST) Date: Sat, 17 Nov 2001 18:51:02 -0600 From: Alfred Perlstein To: net@freebsd.org Cc: jlemon@freebsd.org Subject: t_dupacks to u_int? Message-ID: <20011117185102.H13393@elvis.mu.org> 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 Any problems with this? Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.141 diff -u -r1.141 tcp_input.c --- tcp_input.c 12 Sep 2001 08:37:54 -0000 1.141 +++ tcp_input.c 18 Nov 2001 00:21:27 -0000 @@ -100,7 +100,10 @@ MALLOC_DEFINE(M_TSEGQ, "tseg_qent", "TCP segment queue entry"); -static int tcprexmtthresh = 3; +static unsigned int tcprexmtthresh = 3; +SYSCTL_UINT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, + &tcprexmtthresh, 0, "Max duplicate acks before fast rexmit"); + tcp_cc tcp_ccgen; struct tcpstat tcpstat; Index: tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.73 diff -u -r1.73 tcp_var.h --- tcp_var.h 5 Oct 2001 21:33:38 -0000 1.73 +++ tcp_var.h 18 Nov 2001 00:21:13 -0000 @@ -65,7 +65,7 @@ */ struct tcpcb { struct tsegqe_head t_segq; - int t_dupacks; /* consecutive dup acks recd */ + u_int t_dupacks; /* consecutive dup acks recd */ struct tcptemp *unused; /* unused */ struct callout *tt_rexmt; /* retransmit timer */ -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 17:19:16 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 D1C6537B416 for ; Sat, 17 Nov 2001 17:19:13 -0800 (PST) Received: (qmail 81311 invoked by uid 1000); 18 Nov 2001 01:19:12 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Nov 2001 01:19:12 -0000 Date: Sat, 17 Nov 2001 19:19:12 -0600 (CST) From: Mike Silbersack To: Alfred Perlstein Cc: , Subject: Re: t_dupacks to u_int? In-Reply-To: <20011117185102.H13393@elvis.mu.org> Message-ID: <20011117191447.D80912-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 Sat, 17 Nov 2001, Alfred Perlstein wrote: > Any problems with this? > > -static int tcprexmtthresh = 3; > +static unsigned int tcprexmtthresh = 3; > +SYSCTL_UINT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, > + &tcprexmtthresh, 0, "Max duplicate acks before fast rexmit"); > + > tcp_cc tcp_ccgen; While this may be useful for those doing testing, I'm wondering if such a sysctl should be implemented. I have this bad feeling about net.inet.tcp.tcprexmtthresh=1 being added to the bogus pile of sysctls that should be changed which is sent to every person who asks how to tune their system. (Just look back through mailing list archives to see how man tweaks people are making that shouldn't be made.) 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 Sat Nov 17 17:24:35 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 27AEC37B417; Sat, 17 Nov 2001 17:24:33 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id fAI1N6N07690; Sat, 17 Nov 2001 19:23:06 -0600 (CST) (envelope-from jlemon) Date: Sat, 17 Nov 2001 19:23:06 -0600 From: Jonathan Lemon To: Alfred Perlstein Cc: net@freebsd.org, jlemon@freebsd.org Subject: Re: t_dupacks to u_int? Message-ID: <20011117192306.A97092@prism.flugsvamp.com> References: <20011117185102.H13393@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20011117185102.H13393@elvis.mu.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 On the surface, I don't see a problem with it, but I wonder why you believe it is needed. Changing the value of rexmttresh is probably not a good idea, and I would definitely prefer not to expose it as a user tunable knob. -- Jonathan On Sat, Nov 17, 2001 at 06:51:02PM -0600, Alfred Perlstein wrote: > Any problems with this? > > -static int tcprexmtthresh = 3; > +static unsigned int tcprexmtthresh = 3; > +SYSCTL_UINT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, > + &tcprexmtthresh, 0, "Max duplicate acks before fast rexmit"); > + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 17:38:53 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 B675837B417 for ; Sat, 17 Nov 2001 17:38:51 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAI1cms60316; Sat, 17 Nov 2001 20:38:48 -0500 (EST) (envelope-from wollman) Date: Sat, 17 Nov 2001 20:38:48 -0500 (EST) From: Garrett Wollman Message-Id: <200111180138.fAI1cms60316@khavrinen.lcs.mit.edu> To: "George V. Neville-Neil" Cc: net@FreeBSD.ORG Subject: Re: re-entrancy and the IP stack. In-Reply-To: <200111172215.OAA434145@meer.meer.net> References: <3BF5AE42.49D5D83B@vicor-nb.com> <200111172215.OAA434145@meer.meer.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Are y'all going to discuss this at BSDCon? I'm probably going there > and would like to contribute if I could. I will not be going to BSDcon absent some sugar daddy paying the freight.[1] I will be at LISA in San Diego (on my employer's dime) and could discuss this with whoever might make it there. -GAWollman [1] Not that I'm looking at the moment; I'll be traveling every other week through the end of the year and am not particularly inclined to fly to California again in February without an exceptionally good reason. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 18: 8:44 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 16B6F37B405 for ; Sat, 17 Nov 2001 18:08:42 -0800 (PST) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAI28Tw45631; Sat, 17 Nov 2001 21:08:29 -0500 (EST) (envelope-from arr@FreeBSD.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sat, 17 Nov 2001 21:08:28 -0500 (EST) From: "Andrew R. Reiter" X-Sender: arr@fledge.watson.org To: Garrett Wollman Cc: "George V. Neville-Neil" , net@FreeBSD.org Subject: Re: re-entrancy and the IP stack. In-Reply-To: <200111180138.fAI1cms60316@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 Sat, 17 Nov 2001, Garrett Wollman wrote: : :I will not be going to BSDcon absent some sugar daddy paying the :freight.[1] I will be at LISA in San Diego (on my employer's dime) and :could discuss this with whoever might make it there. I'm in the SD area and unfortunately I'll not be able to get to LISA, but I am wondering if you and others would be willing to meet perhaps outside of the LISA-paying arena during that period? Dinner? Room or area near LISA? 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 Sat Nov 17 18:30:13 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 14AB237B416 for ; Sat, 17 Nov 2001 18:30: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 SAA93695; Sat, 17 Nov 2001 18:29:18 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAI2THw01360; Sat, 17 Nov 2001 18:29:17 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111180229.fAI2THw01360@arch20m.dellroad.org> Subject: Re: Mpd and pap authentication In-Reply-To: <3BF6D769.9000902@ii.uib.no> "from Trond Davidsen at Nov 17, 2001 10:32:25 pm" To: Trond Davidsen Date: Sat, 17 Nov 2001 18:29:17 -0800 (PST) Cc: 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 Trond Davidsen writes: > there seems to be a bug in mpd in the handling of PAP > Authenticate-Ack's. RFC 1334 section 2.2.2 specifies the packet format > to look something like the following: > > | Code | Identifier | Length | Msg-Length | Message | > > Mpd leaves out the Msg-Length field, which confuses at least one ppp > implementation, namely pppd (used in FreeBSD, Linux, MacOSX, ...). Wacky.. :-) Try the patch below.. and thanks!! -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: pap.c =================================================================== RCS file: /home/cvs/archie/mpd/src/pap.c,v retrieving revision 1.2 diff -u -r1.2 pap.c --- pap.c 2001/04/12 17:03:33 1.2 +++ pap.c 2001/11/18 02:28:21 @@ -29,7 +29,8 @@ */ static void PapSendRequest(PapInfo pap); - static void PapOutput(u_int code, u_int id, const u_char *buf, int len); + static void PapOutput(u_int code, u_int id, + const u_char *buf, int len, int add_len); static void PapTimeout(void *ptr); static char *PapCode(int code); @@ -104,7 +105,7 @@ memcpy(pkt + 1 + name_len + 1, auth.password, pass_len); /* Send it off */ - PapOutput(PAP_REQUEST, pap->next_id++, pkt, 1 + name_len + 1 + pass_len); + PapOutput(PAP_REQUEST, pap->next_id++, pkt, 1 + name_len + 1 + pass_len, 0); Freee(pkt); } @@ -199,14 +200,15 @@ whyFail = AUTH_FAIL_INVALID_LOGIN; badRequest: failMesg = AuthFailMsg(PROTO_PAP, 0, whyFail); - PapOutput(PAP_NAK, php.id, failMesg, strlen(failMesg)); + PapOutput(PAP_NAK, php.id, failMesg, strlen(failMesg), 1); AuthFinish(AUTH_PEER_TO_SELF, FALSE, NULL); break; } /* Login accepted */ Log(LG_AUTH, (" Response is valid")); - PapOutput(PAP_ACK, php.id, AUTH_MSG_WELCOME, strlen(AUTH_MSG_WELCOME)); + PapOutput(PAP_ACK, php.id, + AUTH_MSG_WELCOME, strlen(AUTH_MSG_WELCOME), 1); AuthFinish(AUTH_PEER_TO_SELF, TRUE, &auth); } break; @@ -255,14 +257,15 @@ */ static void -PapOutput(u_int code, u_int id, const u_char *buf, int len) +PapOutput(u_int code, u_int id, const u_char *buf, int len, int add_len) { struct fsmheader lh; Mbuf bp; int plen; /* Setup header */ - plen = sizeof(lh) + len; + add_len = !!add_len; + plen = sizeof(lh) + add_len + len; lh.id = id; lh.code = code; lh.length = htons(plen); @@ -270,7 +273,9 @@ /* Build packet */ bp = mballoc(MB_AUTH, plen); memcpy(MBDATA(bp), &lh, sizeof(lh)); - memcpy(MBDATA(bp) + sizeof(lh), buf, len); + if (add_len) + *(MBDATA(bp) + sizeof(lh)) = (u_char)len; + memcpy(MBDATA(bp) + sizeof(lh) + add_len, buf, len); /* Send it out */ Log(LG_AUTH, ("[%s] PAP: sending %s", lnk->name, PapCode(code))); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 17 19:15: 6 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 B2B8D37B41A for ; Sat, 17 Nov 2001 19:15:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id TAA93988; Sat, 17 Nov 2001 19:05:58 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fAI35vI01501; Sat, 17 Nov 2001 19:05:57 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111180305.fAI35vI01501@arch20m.dellroad.org> Subject: Re: MPD-NETGRAPH PPTP server with IPX? In-Reply-To: <20011115195745.C16266-100000@hq1.tyfon.net> "from Dan Larsson at Nov 15, 2001 08:05:20 pm" To: Dan Larsson Date: Sat, 17 Nov 2001 19:05:57 -0800 (PST) Cc: 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 Dan Larsson writes: > I've got a FreeBSD-4.4 STABLE box running mpd-netgraph > as a PPTP server, which works just fine. > > Is it by any chance possible to support IPX (the Novell > protocol) with MPD in this configuration? Mpd does not support IPX currently, and I don't know of anyone who has modified it to do IPX.. sorry.. -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