From owner-freebsd-net Sun Nov 17 1:17:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A653037B401 for ; Sun, 17 Nov 2002 01:17:16 -0800 (PST) Received: from cygnus.theblackmoor.net (theblackmoor.net [63.170.133.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id B125743E42 for ; Sun, 17 Nov 2002 01:17:15 -0800 (PST) (envelope-from drogoh@necessary-evil.org) Received: from deception.hax0red.us (drogoh@dsl19.wk.net [208.137.160.22]) by cygnus.theblackmoor.net (8.12.1/8.12.1) with SMTP id gAH9H3Wt017963; Sun, 17 Nov 2002 04:17:08 -0500 Date: Sun, 17 Nov 2002 03:17:02 -0600 From: drogoh To: Ronald van der Pol Cc: net@FreeBSD.ORG Subject: Re: ping6 ::1 -> No route to host Message-Id: <20021117031702.24609282.drogoh@necessary-evil.org> In-Reply-To: <20021116203750.GA8450@rvdp.org> References: <20021116122410.17819bfc.drogoh@necessary-evil.org> <20021116203750.GA8450@rvdp.org> X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 On Sat, 16 Nov 2002 21:37:50 +0100 Ronald van der Pol wrote: > > Check firewalling. I think IPv6 ipfilter is blocking by default. > > rvdp > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > I have rules to allow protocol 41 in and out, what else should I have? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 5:29:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD4E037B401; Sun, 17 Nov 2002 05:29:35 -0800 (PST) Received: from majordomo.vol.cz (smtp4.vol.cz [195.250.128.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEF6143E77; Sun, 17 Nov 2002 05:29:33 -0800 (PST) (envelope-from dan@obluda.cz) Received: from obluda.cz (xkulesh.vol.cz [195.250.154.106]) by majordomo.vol.cz (8.12.6/8.12.6) with ESMTP id gAHDTPeG027581; Sun, 17 Nov 2002 14:29:26 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <3DD62BA4.5040702@obluda.cz> Date: Sat, 16 Nov 2002 12:27:32 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021106 X-Accept-Language: en, cs MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: if_ef doesn't work with if_fxp? References: <200211131926.gADJQMFo011478_zibbi.icomtek.csir.co.za@ns.sol.net> <20021114101959.E72890-100000_hub.org@ns.sol.net> In-Reply-To: <200211131926.gADJQMFo011478_zibbi.icomtek.csir.co.za@ns.sol.net> 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 scrappy@hub.org wrote, On 11/14/02 15:26: > I checked with our network/netware guy, and he's told me that we're > running "0 interface with an Ethernet_II frame", so I've got fxp0f0 > configured with our network number, which he's given me as 0x83a2c800 Yust for fun - 0x83a2c800=131.162.200.0, so your try to hide real IP by "xx"ing it has failed. > Our network is a B-Class, with from x.x.128.x up being divided into > subnets of 8 C-classes each ... so subnet 128, 136, 144, etc ... > > our netware server is on subnet 200, which is the 83a2c800 that he's given Well - we must diferentiate what we are speaking about. If you are trying to set up IPX network, then the informations about IP network topology is irelevant. You need to know the IPX network topology, IPX network numbers and so on. I don't know what the 0x83A2C800 number is - it seems to be IP not IPX network number, but I'm not sure. You should ask your Netware server administrator. > me ... the computer I'm working on is a laptop, so will be on several > different subnets, but never on subnet 200 ... is 83a2c800 the netnum The correct IPX network number must be set to the same number as the IPX network number assigned to network avaiable on cable you are connected in. Under Windows seems to be possible set the IPX network to 0x000000 requesting autodetection of the correct value. As you know, there must be a properly configured IPX router between you and server unless your IPX adress is from the same IPX NET as server's (it is similar law as for IP) Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: dan@obluda.cz, dan@freebsd.cz,dan@kolej.mff.cuni.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 5:40:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38D9137B401 for ; Sun, 17 Nov 2002 05:40:41 -0800 (PST) Received: from kirk.rvdp.org (node147c0.a2000.nl [24.132.71.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B7443E88 for ; Sun, 17 Nov 2002 05:40:31 -0800 (PST) (envelope-from rvdp@rvdp.org) Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gAHDeMA13946; Sun, 17 Nov 2002 14:40:22 +0100 (CET) Date: Sun, 17 Nov 2002 14:40:22 +0100 From: Ronald van der Pol To: drogoh Cc: Ronald van der Pol , net@FreeBSD.ORG Subject: Re: ping6 ::1 -> No route to host Message-ID: <20021117134022.GC13793@rvdp.org> References: <20021116122410.17819bfc.drogoh@necessary-evil.org> <20021116203750.GA8450@rvdp.org> <20021117031702.24609282.drogoh@necessary-evil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021117031702.24609282.drogoh@necessary-evil.org> User-Agent: Mutt/1.4i 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 17, 2002 at 03:17:02 -0600, drogoh wrote: > I have rules to allow protocol 41 in and out, what else should I have? I had a similar problem when I upgraded to -current. All IPv6 packets were blocked bij default. Are you sure you are not blocking native IPv6 packets to localhost. You could try if "permit any any" for the IPv6 rules (/etc/ipf6.conf I think) and see if that solves your problem. I had a disk crash and I don't have access to -current at the moment. So I cannot check it, but I think IPv6 firewalling is on by default when you have ipfilter configured and it is blocking all by default. rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 6:53:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC31E37B404; Sun, 17 Nov 2002 06:53:51 -0800 (PST) Received: from hotmail.com (f170.law15.hotmail.com [64.4.23.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id A468243E4A; Sun, 17 Nov 2002 06:53:51 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Nov 2002 06:53:51 -0800 Received: from 195.146.53.186 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 17 Nov 2002 14:53:51 GMT X-Originating-IP: [195.146.53.186] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Qs about snoop TCP Date: Sun, 17 Nov 2002 14:53:51 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2002 14:53:51.0496 (UTC) FILETIME=[24715880:01C28E49] 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 Dear All I want to know what is Snoop TCP , and Is it implemented on FreeBSD or Not ? After I want to know if There is any Performance Enhancing Proxy on the NET _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 8:20:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F0D37B401 for ; Sun, 17 Nov 2002 08:20:23 -0800 (PST) Received: from venus.vincentjardin.net (AVelizy-102-1-1-232.abo.wanadoo.fr [193.253.255.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6E4F43E42 for ; Sun, 17 Nov 2002 08:20:17 -0800 (PST) (envelope-from jardin@venus.vincentjardin.net) Received: by venus.vincentjardin.net (Postfix, from userid 501) id 050C2103398; Sun, 17 Nov 2002 17:37:30 +0100 (CET) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: freebsd-net@freebsd.org Subject: Netgraph support with the Sangoma's boards Date: Sun, 17 Nov 2002 17:37:30 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20021117163730.050C2103398@venus.vincentjardin.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 According to Google, there is not support of Netgraph with the Sangoma's boards. In fact, I am wondering if I could use the Sangoma's boards like the if_sr and if_ar drivers that have a nice Netgraph hook. Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 8:29:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F6F137B401 for ; Sun, 17 Nov 2002 08:29:53 -0800 (PST) Received: from cygnus.theblackmoor.net (theblackmoor.net [63.170.133.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CEBA43E4A for ; Sun, 17 Nov 2002 08:29:52 -0800 (PST) (envelope-from drogoh@necessary-evil.org) Received: from localhost (dsl43.wk.net [208.137.160.46]) by cygnus.theblackmoor.net (8.12.1/8.12.1) with SMTP id gAHGTfWt031599; Sun, 17 Nov 2002 11:29:42 -0500 Date: Sun, 17 Nov 2002 10:29:40 -0600 From: drogoh To: Ronald van der Pol Cc: net@FreeBSD.ORG Subject: Re: ping6 ::1 -> No route to host Message-Id: <20021117102940.755ea0f2.drogoh@necessary-evil.org> In-Reply-To: <20021117134022.GC13793@rvdp.org> References: <20021116122410.17819bfc.drogoh@necessary-evil.org> <20021116203750.GA8450@rvdp.org> <20021117031702.24609282.drogoh@necessary-evil.org> <20021117134022.GC13793@rvdp.org> X-Mailer: Sylpheed version 0.8.6 (GTK+ 1.2.10; i386-portbld-freebsd4.7) 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 On Sun, 17 Nov 2002 14:40:22 +0100 Ronald van der Pol wrote: > On Sun, Nov 17, 2002 at 03:17:02 -0600, drogoh wrote: > > > I have rules to allow protocol 41 in and out, what else should I have? > > I had a similar problem when I upgraded to -current. All IPv6 packets > were blocked bij default. Are you sure you are not blocking native > IPv6 packets to localhost. You could try if "permit any any" for > the IPv6 rules (/etc/ipf6.conf I think) and see if that solves > your problem. > > I had a disk crash and I don't have access to -current at the moment. > So I cannot check it, but I think IPv6 firewalling is on by default > when you have ipfilter configured and it is blocking all by default. > > rvdp > I did a clean install of 4.7-RELEASE this morning and IPv6 works without a hitch. Although I'm still confused about why -CURRENT didn't work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 9:36:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 821F437B401; Sun, 17 Nov 2002 09:36:57 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DE2A43E42; Sun, 17 Nov 2002 09:36:57 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAHHauAh017730; Sun, 17 Nov 2002 09:36:56 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAHHauVo017729; Sun, 17 Nov 2002 09:36:56 -0800 (PST) (envelope-from rizzo) Date: Sun, 17 Nov 2002 09:36:56 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: broken IFF_ALLMULTI handling in many drivers Message-ID: <20021117093656.A17547@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.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 [Bcc to re@ because it would be good to have it fixed before 5.0] Hi, Pavlin Radoslavov recently discovered a problem that affects several network drivers and tends to show up when running multicast routing. The problem is that the multicast routing code calls iff_allmulti() on the interfaces, which should enable them to receive all multicast packets. The device independent code sets the IFF_ALLMULTI flag in the ifp, and then calls the device-specific ioctl handler for SIOCSIFFLAGS. Individual drivers handle this call in the most various ways. Some unconditionally reinitialize the hardware; some try to be smart and only check which IFF_* flags have changed and perform appropriate actions. And here is the problem -- several drivers forget to check for a change in IFF_ALLMULTI, thus causing the change to be ignored until some future action on the interface causes it (or its multicast filter) to be reinitialized. A list of broken which are broken and good is below. The 'broken' list is worrysome as it includes a lot of new/high performance/wireless cards. Broken: dc mn sf sk ste ti tl xl an bge em gem gx ie lge sr aue cue kue wi xe Correct: de rl sis vr wb ar(?) cnw cs ed ep ex fe fxp hme lnc my nge ray sbni sn tx txp vx wl I believe the best way to fix this bug (in the *_ioctl handler, for the SIOCSIFFLAGS case) is to follow the approach used by the cs, ed, fe and vx drivers -- but if others have better suggestions please let me know. So, provided re@ approves, expect to see some commits to the drivers in the 'broken' list related to this problem. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 12:55:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3D0537B401 for ; Sun, 17 Nov 2002 12:55:52 -0800 (PST) Received: from mets.tcimet.net (news.tci.east-lansing.mi.us [198.109.160.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D289143E42 for ; Sun, 17 Nov 2002 12:55:50 -0800 (PST) (envelope-from timmerk@tcimet.net) Received: from tcimet.net ([207.75.255.59]) by mets.tcimet.net (8.10.2/8.10.2) with ESMTP id gAHKwmJ33411 for ; Sun, 17 Nov 2002 15:58:48 -0500 (EST) Date: Sun, 17 Nov 2002 15:55:50 -0500 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Arp and Route Commands From: Karl Timmermann To: freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.548) 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, I'm new to the list and was hoping maybe someone could help me. These commands work in Linux (and in this order), but not in FreeBSD/Mac OS X as the arp and route commands are different: arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 route add default gw 10.10.10.0 dev eth1 anyone know how i would change these commands to work with the FreeBSD versions of arp and route? Thanks! Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 14: 0: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1222737B404 for ; Sun, 17 Nov 2002 13:59:59 -0800 (PST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3041243E42 for ; Sun, 17 Nov 2002 13:59:57 -0800 (PST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAHLxtY71657; Sun, 17 Nov 2002 22:59:56 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAHLxckh025095; Sun, 17 Nov 2002 21:59:51 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DD8110D.7020904@ccrle.nec.de> Date: Sun, 17 Nov 2002 22:58:37 +0100 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karl Timmermann Cc: freebsd-net@FreeBSD.ORG Subject: Re: Arp and Route Commands 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 Karl, try man arp man route on your FreeBSD system. Martin Karl Timmermann wrote: > Hello, > > I'm new to the list and was hoping maybe someone could help me. These > commands work in Linux (and in this order), but not in FreeBSD/Mac OS X > as the arp and route commands are different: > > arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 > route add default gw 10.10.10.0 dev eth1 > > anyone know how i would change these commands to work with the FreeBSD > versions of arp and route? > > > Thanks! > > Karl > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 14:20:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43F4337B404 for ; Sun, 17 Nov 2002 14:20:38 -0800 (PST) Received: from mets.tcimet.net (news.tci.east-lansing.mi.us [198.109.160.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF4C43E91 for ; Sun, 17 Nov 2002 14:20:37 -0800 (PST) (envelope-from timmerk@tcimet.net) Received: from tcimet.net ([207.75.255.59]) by mets.tcimet.net (8.10.2/8.10.2) with ESMTP id gAHMNWJ38086; Sun, 17 Nov 2002 17:23:32 -0500 (EST) Date: Sun, 17 Nov 2002 17:20:33 -0500 Subject: Re: Arp and Route Commands [sorry] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: freebsd-net@freebsd.org To: "Martin J. Muench" From: Karl Timmermann In-Reply-To: <20021117225844.D280-100000@codito.mine.nu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 Sorry, I should have tried this out before sending the other email. Your new route comand works, but the arp command says: set: can only proxy for 10.10.10.0 Any ideas? Thanks again, Karl set: can only proxy for 10.10.10.0 On Sunday, November 17, 2002, at 04:59 PM, Martin J. Muench wrote: >> I'm new to the list and was hoping maybe someone could help me. These >> commands work in Linux (and in this order), but not in FreeBSD/Mac OS >> X >> as the arp and route commands are different: >> >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 >> route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 >> route add default gw 10.10.10.0 dev eth1 >> >> anyone know how i would change these commands to work with the FreeBSD >> versions of arp and route? > > arp -s 10.10.10.0 00:00:ca:13:4b:54 > route add -net 0.0.0.0 10.10.10.0 255.255.255.0 > > These should work just fine. > > Btw: reading the manpages arp(8) and route(8) might be a good idea. > > - mjm > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 14:21:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83DAA37B404 for ; Sun, 17 Nov 2002 14:21:38 -0800 (PST) Received: from mets.tcimet.net (news.tci.east-lansing.mi.us [198.109.160.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE12D43E3B for ; Sun, 17 Nov 2002 14:21:37 -0800 (PST) (envelope-from timmerk@tcimet.net) Received: from tcimet.net ([207.75.255.59]) by mets.tcimet.net (8.10.2/8.10.2) with ESMTP id gAHMOaJ38128; Sun, 17 Nov 2002 17:24:36 -0500 (EST) Date: Sun, 17 Nov 2002 17:21:37 -0500 Subject: Re: Arp and Route Commands Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: freebsd-net@FreeBSD.ORG To: Martin Stiemerling From: Karl Timmermann In-Reply-To: <3DD8110D.7020904@ccrle.nec.de> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 tried that, but I'm just a dumb high school kid who even after reading it, didn't understand the syntax, nor how to make it work. Sorry Karl On Sunday, November 17, 2002, at 04:58 PM, Martin Stiemerling wrote: > Karl, > > try > man arp > man route > > on your FreeBSD system. > > Martin > > Karl Timmermann wrote: >> Hello, >> I'm new to the list and was hoping maybe someone could help me. These >> commands work in Linux (and in this order), but not in FreeBSD/Mac OS >> X as the arp and route commands are different: >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 >> route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 >> route add default gw 10.10.10.0 dev eth1 >> anyone know how i would change these commands to work with the >> FreeBSD versions of arp and route? >> Thanks! >> Karl >> 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 Sun Nov 17 17:12:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1150037B401 for ; Sun, 17 Nov 2002 17:12:26 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C9ED43E3B for ; Sun, 17 Nov 2002 17:12:25 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id gAI1ENDh032840; Mon, 18 Nov 2002 04:14:23 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id gAI1ENnM032839; Mon, 18 Nov 2002 04:14:23 +0300 (MSK) Message-Id: <200211180114.gAI1ENnM032839@aaz.links.ru> Subject: Re: Arp and Route Commands X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: To: Karl Timmermann Date: Mon, 18 Nov 2002 04:14:23 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hi, > > I tried that, but I'm just a dumb high school kid who even after > reading it, didn't understand the syntax, nor how to make it work. This is like translations between human languages - hard in common case but possible every patucular case. What is yours circumstances? > Sorry > > Karl > >> I'm new to the list and was hoping maybe someone could help me. These > >> commands work in Linux (and in this order), but not in FreeBSD/Mac OS > >> X as the arp and route commands are different: > >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > >> arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > >> route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 > >> route add default gw 10.10.10.0 dev eth1 > >> anyone know how i would change these commands to work with the > >> FreeBSD versions of arp and route? > >> Thanks! > >> Karl -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 17:31:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D90237B401 for ; Sun, 17 Nov 2002 17:31:26 -0800 (PST) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB3E743E88 for ; Sun, 17 Nov 2002 17:31:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0277.cvx40-bradley.dialup.earthlink.net ([216.244.43.22] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18Dal0-0006TQ-00; Sun, 17 Nov 2002 17:31:23 -0800 Message-ID: <3DD84291.8041C327@mindspring.com> Date: Sun, 17 Nov 2002 17:29:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Qs about snoop TCP 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 soheil soheil wrote: > Dear All > > I want to know what is Snoop TCP , and Is it implemented on FreeBSD or Not ? Snoop TCP is a mechansim for performing impedence matching between a network with very little loss attached at the border of a network with much more loss. It operates as a pseudo-application proxy, and (effecitvely) implements retransmit queue caching at the border of the lossy network, so that retransmission requests do not go all the way back across the network. Think of it as a receive queue caching border router. If you had a wireless computer which connected through a "Snoop TCP" base station to Yahoo (for example), and you were downloading content from Yahoo, and the wireless link was espcially lossy, then your client would lose packets from the Yahoo server. When this happened, it would hit its timeout and ACK the previous packet all the way back to Yahoo, forcing the Yahoo server to retransmit its content all the way across the reliable link between the Yahoo server and the base station. The purpose of "Snoop TCP" is to prevent this. Once data has made it to the base station, the packets are cached. Effectively, the base station becomes a TCP transmit queue proxy cache for all TCP packets, rather than doing simple IP forwarding, and when the retransmit request comes, it serves the request locally. It also ACKs the data to the sender, when it arrives at the base station. Basically, this means that it *must* be possible for the wireless client to accept the packets that the server sent, and that the ACK must not provide information to the server which would have changed the content, length, or other attributes of the packet to more suit the client (once the base station accepts the packet on behalf of the client, the server discards it, and it can not be recovered). In general, this also requires a modification of the client to shorten the 2MSL timer, and on the client side of the base station, to shorten the 2MSL timer; this assumes a local link, and is potentially a bad thing to do, since the 2MSL timer is intended to deal with link latency, and the wired side of the base station is likely to be at least 10 times the data rate of the wireless side, if not 100 times (Gigabit <-> 11Mbit). In addition, the base station will suppress duplicate ACKs from the wireless client to Yahoo (this is a side effect), since it can service them from locally cached packet data. A consequence of the base station ACKing packets not yet ACKed by the wireless client is that it is then impossible to perform a cell hand-off between base stations, without complicated state replication protocols: the data, once ACK'ed, exists only in the transmit cache in the base station. If the wireless link timer is short enough *on BOTH the base station and the wireless client side*, then the base station should delay acknowledging packets to the Yahoo server; in fact, this is generally not the case, and the base station must treat the link as asymmetric, and eat the inability to hand-off. This is because in most cases, there is insufficient control of the client 2MSL timer to make the implementation practical (the 2MSL timer value is not a negotiated parameter between the base station and the mobile client computer, at the time the wireless link is established, which is what would be necessary). Another not-so-obvious consequence of this is that the number of connections is significantly limited. Specifically, you may have to handle the retransmit for two fill negotiated bidirectional window sizes worth of data per TCP connection per client, so the number of clients you could expect to handle with a "Snoop TCP" base station is significantly smaller than the number of clients you could handle otherwise, because the RAM requirements can be up to 64k per TCP connection. So the primary value in this is for base station firmware implementations for 802.11[ab] networks, and for proxy gateways, which already have application layer proxy caches, for telephone carriers. I rather expect that if you were AT&T Cable Internet, and were selling off your Cable Internet business at the first of the year (as AT&T is trying to do, which is why it's running the specials it has been running for the last three months, which all cut off at the first of the year: to push it's full cost subscriber base up to raise the selling price of the business unit), then you would be very interested in a cable-modem with a built-in wireless that permitted you, by virtue of being in your box, to limit the number of simultaneous clients, enforce security on to keep people from "wardriving", and to provide "Snoop TCP" to take retransmission load off your cable plant infrastructure. Currently, FreeBSD does not implement "Snoop TCP" or anything similar. It's actually pretty trivial to implement, if you need to do it; I rather expect that it would take about a month of work, given my experience with something similar taking about the same amount of time. It's unlikely, unless you intended to use FreeBSD as the firmware for your base stations, that adding "Snoop TCP" to FreeBSD would be a worthwhile project. Base station support in FreeBSD is limited to licensed base station hardware drivers for two cards, at this time. > After I want to know if There is any Performance Enhancing Proxy on the NET There are tons of them. You would need to be more specific for the performance of the situation, as it stands, and the specific situation itself, for someone to be able to pick a proxy. With no other information available about your application, I'd say the odds are 30% that you want "SQUID", from /usr/ports/www. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 17:32:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAAD737B401 for ; Sun, 17 Nov 2002 17:31:58 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECA5743E3B for ; Sun, 17 Nov 2002 17:31:56 -0800 (PST) (envelope-from chunan.li@nokia.com) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAI1VOO02666 for ; Mon, 18 Nov 2002 03:31:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 03:30:08 +0200 Received: from beebh002.NOE.Nokia.com ([172.28.19.40]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 03:30:06 +0200 Received: from beebe001.NOE.Nokia.com ([172.28.19.42]) by beebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 09:29:38 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C28EA1.F56944FC" Subject: RE: Qs about snoop TCP Date: Mon, 18 Nov 2002 09:29:37 +0800 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD790347@beebe001.china.nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Qs about snoop TCP Thread-Index: AcKOSTDtFd6yaTkURyWdukF4UCferAAWFE2g From: To: , X-OriginalArrivalTime: 18 Nov 2002 01:29:38.0409 (UTC) FILETIME=[F5C65590:01C28EA1] 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_001_01C28EA1.F56944FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Maybe the attached is what you want. Br. ChunAn Li -----Original Message----- From: ext soheil soheil [mailto:soheil_hh@hotmail.com] Sent: Sunday, November 17, 2002 10:54 PM To: freebsd-net@FreeBSD.ORG Subject: Qs about snoop TCP=20 Dear All I want to know what is Snoop TCP , and Is it implemented on FreeBSD or = Not ? After I want to know if There is any Performance Enhancing Proxy on the = NET _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE*=20 http://join.msn.com/?page=3Dfeatures/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message ------_=_NextPart_001_01C28EA1.F56944FC Content-Type: application/x-zip-compressed; name="TCP-snoop.zip" Content-Transfer-Encoding: base64 Content-Description: TCP-snoop.zip Content-Disposition: attachment; filename="TCP-snoop.zip" UEsDBBQAAAAIABdPFS0H314jahIBAOYmAQANAAAAVENQLXNub29wLnBkZrT8Y5guwZYmDJdtu2qX bdu2bdvGLtu2bdu27apdtl317XOmp9/uOX19M+9c/eafjFwZEWvFWhGZed9PrIdEXliUhoGWEZbk 4HB2ERaKiYOAnsDO0BKWm5sAlk7awtbEwNHC08SYgOHvpRwB8z9O4gRaBKzMjASMbCwEOv+oRcDG wszB/LckQsDCxMT4tyBLwED/96RMwMbMwsFKAMvLSwBrYmv8j44J/u8Pd0cTU9i/FjL8VUH/bwcD K8E/zwS2sFD/JmJhZ/sXGQfDv8gY6NkY/kXGSP+v9Zj+6vtfZcwMHP8iY2H8l7Ysf8X/ImOgZ/oX +/7hz/9Vxs7xH8bm7GhgYW3i+DcusHRKfyNCwMIASydha2pHwMT+N2SKf72taGfnTMBM/29X8o4m rv9wP/tf99NJCGtxMzCwsbExMTCwMxsY0bPTGzGxmBibMjH+dY2RMZuBoSnv/76Gzt9Awjo5Gzg6 /zMU9LAkJCJyov8jpLD/1PzvU0fZw96EgE7IwNnA2s7sH+YYmJk4ETCx/Q/r/sN8YP4PM45OiYCB mZWATtTC2tnE8e/Z2sDZRNjEyM74b1/SJrZmzuYELP9jgP/owcnZ0cTABhZKPNxQX1/fVF/fEig+ KwXmEwaib7ZvoA9qCAf6N06PlyKyNYYlrqvcKTfnSRvXCxNYyBzcpLJZHkps5CEikUruGHJIBGf8 aFIqMzSZd6LEfY7CWrmRw1B7abZ/tb9AgMA6TaCABE1gO2AZ8FiDvr45gsVenyE1whg9/cQUyAIO PzUEmoPBnoGMvQGUvNn5k5HinqGlvEFG3uBM3nCTv78bkDweQR8A4hHF7T/G/G9G/9voWf6n0xhY Of4flzD8qyf/4b9/utHRxNb53/1Ip2jiZOfiaPTXtf+YQP8UCdnZOv+t81fC+m8SGRNjCwNBO/e/ 6/Yf6lj/zmc2DsZ/rl0hRzv7//qOop3zX+f/Ff6nYDH+R8vkHe2MlEyc/zam+/sYIaBTNnF3/mdb 0b8mEPwjnqIMBMz/w1Q6UUYCZqZ/KzIRMDP/W5GZgJnl3wNKJ+LuLKb0T73/aC2m9Lc5+7/f/Y92 MP2rh/6p9O/icDF0/uf1P6T/eFyJ2P6dPxa2ZgR0aha2ArZOFv8ugKUTNHAy+Wc7OmULGxMnGkE7 a+P/rIj5/0aRjIGRop2Nge3/H03/vP+fVbH8f6RK4u8atDD6z7pY/8Oi+7eFxcTEwfFfL73/vNac 1SYTNkWRuh6o3psArWEsuF+3eCTuN35xdK1sRN0aFAkhmyfY7Deb86N85faca7FWdgAys28EMjMR y+voJCeno0ZOHnTi+0UOD1Mb5g8TIsWvjYSv4SLNVwx73L23vV6HCg8duOvuOb3j8R3IdG0UG2JX D9cPSaF/cpk+7togdnGm1yRroOP99HWWe7E13IgaNqJl+jRIKnm6YFYTQgWsxtjtQNsEDbUHp5QK QgqXSyu1ZptvdFQ2diDo6JVrOzebK3vVbCpuKStA6MxrxKuPVArj9OoJVxIf580CGv7pWHQhgVYo v0bDC+j4MhamcCJ5F10yUziFwt9ydkMVwSW1sEcm26ZR2Vyxeb17tXX45CIc6cyOXpuQTU9+ZQON JMKO1us5n1RpXuwMyPVGKpmtEcSa17Eq7Pp91g/2J9UOa1V1pM3aODmygddCGdDOJexeYxX04Ncd ZVRrfzbjTY1uF7GMNbeFtB6rs5nb9KJOXpsBDll/4pixnbMLYjvUoYy9gIe8vMrRZI3uQSi6XWvr nXa5SXJ5srvWvnJTefwru7ZYmLsShGmDai6KibDfqZSIWlqAiBYc2mkDhXJ5hayirzM4BYwf+3Oa IjXUOaPtKIImFwSuqtYS9QGcE7PSsgtTIKZ9Mz4eJpwPHPlzQqIG6Til5DORIuknIOXz4zUll3/S RgbUY/q3UggUeZcggKPSJCU8FFVvvxb2q3u2bWjN8XtlRncT9R/cPoan9DsKrfOGmohOftIFaPPB 7CKFgTYoJPkMVcxlX1J1gtslKdkNcuKtM5g4nnf7cMJQM07JU22J0DIKlSbMxJTxKN6kdTICcvns /KrT9l+xxakGDfsj0uXtDDSWzKiJ00Q6lkYY2YxWVkbsa/LS56SCCnpbLhYEqgcv9viglFFADskG SO09c7tERdTGIIGGHSAkjCK5NTd5/pBXsu5MQrwbzsyY5IObq3yFmuyvPKgqxwVxMmpspiBPEBNB tN0PAuVmv5ucmAEW4Po9e48O5gOlQNTFMjEJwK8deVjFa6g/JM0WjsU41j9axcW7DsZ5v6/MI/8k l8YtS34utArOU+nNRWnU4gAwo85COIG+2fD7ugJwWvLBNnxnAPIDGGkAp9n4QCUSn8qI0QNYzuVE 8p2kTKUvvlsW3Yt5HnKx8HMmeogoqSBo/5y9xz6yYovFnotM+otXk2t8ID51V39MNp9xGWAV3+NV C2L334TlCBcM4pYeb7btuAdW0GA/B1t7WNIjNVdvhlwcWw6t3psZH83dCv7Kd6RA9A5PNCyYroE9 3LbEX/LIVVDbjtxNGEVJq7sXN8qoawho1ubxVcF0FIDllDF80nBzk1wtB01uNkube50mjzgdz/1h AQUb2+joQEEhIguiMAKkjyzVpJJo67DFN2NxhByRneVuMnwFcwmWFsIHUIuWIGEX9ISag1rCzeZ8 0dml/J4ZJU9cunxOYTWabD6YviR3dmZzfQR0AHByTTaWOgYn1qoJ+EYmD5BF61gSJibbei55uH4f aqAV96yUTsx62E0UwLjFMgijQIrsoUmhNNA19kJvZ91LlTRxzbLxsQiSjRArM9KXyTe0hU37vjYm zP+IyWvcN1lEuT4OcdE4XjnjXgf/0hqph32dTrXoOghk001Lp8ITfPE6jRAByp/61WcXGykVu3pC vw5m5tbNOUnPl+YEBYivOEv2urVSPDbWGT+gDj/K96HhpO2eMWFXSWORoWDoyru1lzEz4O9iENuk eh81uUeB/oNYNtQi6Q3R4VU47t+2YTSkXtDPBtwG9XEZGle7Px+BG5iEWVdDGvznFR9IfTPDFNLm xlYSdiCpF2OZRGBfb3TYD10/0D03zFjGm4YA7c+EHzqq7IdDfJjbXhQfyJohlS2hjoCaL9osPlE8 neEn3g2hgiPEpyK1r9Zn6OWnf/oxvzCyXctK74O5f4n4I31VTdfrUZ3moNzAAOufwauorvcnH3fx ALW0nojoHvfWz/2nzaNfOiOZS4wHQ2YU9Tt4lQMjrZ8zmLBk+Ul9/lWWfdA1jCGVxnXR1eTEkLIi wL69+5hHy7dVZXet4J6jXQ0+9buJNToflGLNGpiSt/GsUErpXJMjm4M7Z84N6fNw7C8/NcSmjy9F 2LM3Vo2xuUN22ZxVuXgtCYAErP2r1Vv4vD1zLcg6EzUc9rIHw9+MVTiLQEzaWdBc1yhBlRap9gTE jAc+hkfYmkRVbkOpXbIcDo5EObz09HpuKVD0v5wwiBVxlbeY8jiox7ZN+8Ac4X9OZ93Oj7FpEYok KsODMd4d/RmERmgV0u5QVAJkWGz5mpKcO2ZH7M7c3W+bcb/r0SJaai/tkJeb7wsgoJ3lKSC3MOQm upejp7dqrRM6riJYmUBxJ6uB5xccaX1ipsQiNzkQSwqvZ3gH+wPOv1jiiOC9tJ7LG9BgNmeDYcDL 0UyBBJhA6/WUDqzuuYjRCaaYPFCeWW3vGkL4Z9gf5/noMRl+FrjKxM4HFHlUDz50FZDPuFCwUgtv cG4M4Kwc/djkfkRZmwfAYXdmmdnd1NcZVeVLC+yX1xRZtC8sTsbP0dCDF7OYKOEJbppWqHPMnzEp l7jhKQ6bYJU+AbZ/u6mZrJJs7G/1DAbMpCImujci59MqYtuP3RukqCl0NO+ZaJwcIxCIJQpMCouK TUWPIR+2q7iHnJ5ha3LaaBo5wKzfYbMUXENP2GinO0prtZU07h9AMP7kiT2gdU5AV4KXypl5YmMI 8rMNJq3N9wHl15mxvjkhOIlCNk9yy3yNGLtkXLA8/fYNzgUJ5v8YZHagrHKSeKJFrVCyAB54Qyhb Nnn6c9S2s44DK2AtBenyBzZ3d9y69wfCP69G/oSzIsRjjcQDShP/+XoCPyDXWOsL1XahL0xtuNiW gbPY/fvsyze0LNC/TxgbQx7KyvOVQeai0i5P25WnnZ05MQxluVXV1xyC5bXWvnNUotAPhf4w+Hsx IWg3YQiMuF9pyB2gyYRyp31m/xjBXLPLvKJaa+bIPu3QhraiRpc+7xBZMhyPCIGVxWK8iUSBYXtp 9wqAfu9Ksf7uzxjjq7RW4AmbHfxFLN2JjTqA+wy/TrQ1GEsvIld61XKarpSKswyXhYkSeUAN092J REyoQiQ+S1iFcG005ZSkXpwEFz0JVSbgsu3Nckxw2Ghv5m/r8piNmRWAP1N9zUgKEHD7V79b5J4D BtHIfc98btdVACzOE8hx2n9pia/tMNBkWmedUxTvKhJPZLVvgcJzbdZh3OK91+3PmdWlDvEvBysq 79O+CjIH7XqUFkfQ4F+d64uNwP2247RCAtP2+zowHlXyOdG4is+76tCe8Q4zYbJN58rrxyFANtQQ wXSKEPJ9MDl+se/UwpUnC4oArupQi54RpVK9XvoI6dzz+B0uIhb0m37tdpkDdpkXoxWPzPFZdubP JJfyhdDtM8/ryNLJtUmz96FkQbCmAsruWWxWAFEvXKk/Buw15Vgyiu8AvOoDB4FCITb8EHaihSPe REBQD6UlxiE4EjNdun4TGk2RsXI0Issf9QksYThNY/lDwZVgazJ0Q12CTTfkZhbzJAqqoLYyyeaF KyjXlrHu34OiqhaD06SvepvLDZmsCCIv3sPUMiJgsfhrOyxxwuUVwmUILvHWIfoBqHyEMMISybOX P49ZmMhcc7AD9IdcLzM8sVThQHshAA+cABcrJfFBTwJIuor215H+FFV0hkYEDd+llqNMrBjgwaW4 J6KLb0fzW+csG9vNQHXMK6BLIHsS5WvJ8Wb1nddt4rwXXTWy1A/djQXZQ5lzRMyWudrBOTyEb1mr /PvVaI9qXHBcxr7ZuT7zUUXzDlvJ+b+BipIx8YS/tAb5n5CKyrltiHVB+aepsoXRy6v7C67W1P2G D4Jt7vRFkh5yEcefEo2CZmnibavrOSEAFoPliPNy875vstysIJTg8tUgY0GHhBhNy1GV7OwpAQQC z2uiEBDKu13IU2bcjL86KDUdxvPNSXCrbGCbSv3jPb6OukqHlOhghFFACYOEOB8Is3pa31ewZ70G K/kJjiuYxhwpzMfh6mmfXStDH+R+ueQr8Ujmywc4zVAlYhO3fGVGSqjUqKuMr3SU03cVvVb/Rtr8 ZUBhKyCU9xcXsGv7e3mewg/ZiJSslw4DJUsLrk+sdFXfWi3WQaP17lynMFc/031VsPnwOabcs9vw tViQ2bLZ9EpwtViMEoaTqCEzsNoQWw1JB+vv+RDRDuIrMVxJYnDVgP658d2b6OPYCx9/9njKvQ9Z 9o8eo8vnSoDAeOt5hClE5xGbt4Wp7Tr2nqhRXcv7Q44YfzGhMJT8MtO8Y2xY5fQFg95Dy1LSiPkK i/NHsvAy71qz8fCc5adr6s5e1xjbCbn39o60pvi1vPXm2H6QyqQQTPEtfnZEuZ6R3/6778YssAOv jyw5EPbF1zt36g/7NjfROpuHh4OZ3A6zMrkP3XNP16Ar0ASz1xQMto7xR1TQTLSZ9I3VnNdJzdRz nSqkpLbTOcAeKees/DfjYhFciFkHBlEURQLRydUcwA9A2i4CENS/EAH/hMn/rYhWyM7F0eIvlPtP uI/9X7X8P5j7ryoBAlMDa6d/FmUI6Gnp/0HmKf/F6RLGJrbOFs4e/6m3/xua4l9YCqb/dpLi/y1H 8b8hJuhEWQgY/x8W4v+Yo/gPFMW/Q2w2eob/E4gdpDbZsNmGuL1b25cgreMgrFhUtF5kLUfavi49 oWpJ6cIDHRZEPISSD5BncuR3r/WdkgXGj5jEMy4Kj2T9fPh4tsjBxft1ewLPwZVRmiXx3GQspXoC qmUHXTK8uH92dX0WmiuV0ri9T1HaKRVSazm8YpKTTLKZfTd1Z5FOc7dUk48vMuy6WroqHBmjNd9g lVGLVMzH4HWQcteyPIBhcKuG5TpvuRvuNKLr+SzArFqR8/c5S7mw6+oXfCaS038tZ+zWXILeRVpN H53iBQgc0DzguI458pHS3JqTa2KUxtnmVWejUtgR9ZVxPGlyYHP9vde1zYuhFGh67+1PV9C69SbA Oj6j0Xwft1IpzHoNpq3mTMSoZtvFUQ1Gxcx0rl9rkW1Pg2FISuRlC8LU35AVoBNd266FvZgWa8Es ZKYjL1okkuwt+0CJmOHmHL6FZqFLpkcrKHW/PbRSefndGFNIh2+5XPYAOoNlZjeF3SnpJUhtxmCq vC/EtPNrBC++SMvRNHiIFhk5Ez65A+ZDNgOZHiD19E32QMIWnKaMNHOBZ1zTIqP/1Q0frGOSFveG Is5DcWzVOMrsCmm1rOcsRNVdj4Np8G3qiWamn1TK7QckIvL3wUBhGwHK6nACwWcGCuaHBIbH5Tp2 RIziJeFUqoaEABAPnvENcIWfzGplFaE2F37vLvFTQoZxeicroORKYxMZXcjVzhesKWYvwRk6jYGn JJ89GaerPFZ/fvocSxW6q8B8EHetd07tH3xuBj/i1hbeSq95iT0T1FvB1CKTBQDEBrvfljulHulb Y8fmvz9PRZPEQHVC0BFzXiwUiAMvqYVsqzsQ/r5KM042/6wXn1J2xkAZmfBBnKM2qQEABCBG2sX1 3BMwC9rHCfT1NbqlZihaTHpJpdyKVTLvTgUARULAToaVITKY63f4AnhmjVPdSmlAg2q/AdU02ogg AJ7NOXgJShFVaeX5V/gWAYZEqhD2hq1garoDIzocvQXtJDKuuHOD9aFo5IS+iPiaWos9kkffdPZ0 MoiRs7WM1iZay96a0XEZ9jWNJc42APLPj/B2QtuxOBpiet5zP878fIs/dZYWJn6RccOTY/XPOpcX kjbQ98jEZNhLtL/K8iX46cNxOQ5JyV0SVF1wiu1lzgdfCTHsRIIFLW8vZOQJXbaUDKzkbO+lO7vX YRnzE6g7f5KS+jLWsGlLeXNRV4Su3ILcIdyEl4rgGljQCcsd003kDevt9mzX5ODPSyYGZo1On6d3 e/UjPsPjfEbv9XXOODVdGLMFoXij+HTWWfrXAix7wVOT4+7khdI1sD+CNNfe/l775Tyz/dBofmTv +nmWnspuhzhbwHFsoDbpx2UWFeZ4cgmkRzpH7HItkv8nCkAOmOJ2CqP1JaE1l4L/kYgPTBLEr7Py 6YsyACGLgHKO14Z7a1GkfoPYBe3lVJudWO0eqWcAGS7uwmEM2tALS2mhTyeWNaN8GpJpc6rrybVs 744b2invfQaHvPUizzThZ6p0OHvmwqWlpiDwhQMd0DNU0AcgUPNZ9slH/BIbK37vhVmPDErj7c5A X5lcAxViz5ZUR9klp+uRZmJnDRSx6uLC/j3mca+PUf509E/wjK90KcWBwhRETS9DAXfM++NL/LdK oYsDu6h8vUcYFT8YAH7UbV176grSYU3KaQFQ9oqHAIC6AhbOtD2rJ34VOKllCcqVwMiSZ1YbCid0 2fdBRoMLALS02JZEFshKd0mm8DQn8iLwXF5N5mXGTUTt8MCwXHdw4Tw7bulWoVrO4cXRFN3JVBmC 0Yct2IjhmAdbeena+VSthO1O4TThScDA42DmTL5Dshp/4SB5ZAElSHCYM+HcMCSTp3HsfO1qEMRt +mVe7612LX8RBFVSWkIhkMDceFT3iXMKBhagL1O/1CzzUtW54RFm0OLMuKsBbUG8XiZkmuupA4Qx Bugbe0089cLinXcpJqgAA3uI65BUIxInNkoQ3APK4ymBDF8DOv9NH6bZzBmdITWbvT/W1ogeJqSt 0LmitqlPAl+bFEBSThbAH+4zAAwRrEtJbtxHSogFXMLgIhU21gOj8IIMpe81gcrGFxpuAPEVImKr gCJ0x2J0R/dVCfmekS+DkkjvAr3EQkUa+bVWtfUE3xZADZ9IzcAypmf0m580CD5HZpZPpuE/gMId cc9BdkeArNTT470XOWy5A5YhxLGQoRNOQHjC+x6IwA7NNdcNv8aBrcBdUoRWl3Ko6yEBENGgd2OZ BJonJqaPacvu6VvTiERRnpRqzZV1GORifPUKtNPn0YYPcO9cDWUQpZ8mRJF9lhaT2vooFPgM2ajq MgWUpZA4lUBZC09d5HE0aGaRRR5Qhtbj+tCOPZzbI3TgMriw3ovZ3PotWqvVa4/bVhwH6oQMtI3Q bCCWVItmu61/ca0RWz/GXIXdj8AhcLLxQ6Oi6BYkqAYNo6Fje8TfMkJTjFr9kTYVQaATzwvkEB/i oh7JxkOgOzQI6PMJINuBU3EIurnTlHGvxruN2Af3MZC9xc/9ttZUY0gzs36di64x7JonaIgPEtvq a5Qvd9GmGKMuplhkzVHjjWby/QWOp7RnoqhgMtzRV4OlWfC6nQLBn+awkGlRbDQmlANRkOjVu71p mqny5Lrlpf6YZOB5+lFHH0frvL0fOwotiocWZa6eq30hd/emI88FrziqIVvU3txvUJzoNe2yReYh D71UdBfkeAiiFeA3U4b4PLUVhWr2u/fCtIhtVz1DwEoxTZ2cSyDZMb9jiNZb8AZG+bvWmQ6fZA/c pU6tZhFJOtyiS4YX2gepy2eMNWXIxXf2OZe78TzzppNlWKCfc9yliEapct+94ybVnXnmc6XU3Djv Iyi4wfyTHCCbH2IR0DaOakNW010N7bAHNbbZpKt24EnjVZ36woVgD3jpKcrzwboL3SRIAP43cdal 4Cr3VBqW54DukXMgczx80xTrESdcE4T/iKSVKcoWEXE+zbn36XhUXauTUSlTBL8Cp7ItWTcnZKGo jnwz9n73UYqfmmABpVnyTByP4zHnwRQxPUY9kSo64xv9r7AnCUy457DlC3aKfG5zhajfU5014tsg JmIqv3IIuwnERcYH26hc7t0D+opmT9qiA5IwVEJSjRAoMoVZa4jeejJXhBivUVLsPFYcjHoXJWSx vmdUVY4vYB4aKyZ/WjWSSeyVhMnQETcTmj7WbbJGaHegKz3sZtLS7E4zNitYbSsNa29080DxUys5 N1VNfl/QouH1LH5dIRpGSkzctywnbdFvRWEKY3Q0IroEjxRUP3I/Mm4Q34sZsN/TNWE8AfGpk83K AdRxFh1xchhf3nxpNCsn2BDGe5SqXmbbn0TQS9thdbwXWKwlZlafvsJOnVC29srQ9T1yydtktvdQ r/qyOVRtEQp+RoCcjw6xmxxyM+w4kfELVCtVBWOzh3u1KsnFAycyWBctVdHqbTEA0eOTUDu3WPYp zXFrNgFnmRRB1yAxxNV0MwZ2D6zPuxEAlPLYoTHZd3CC+RyR3k/IGbOjnhVGfQUw/hYRTPhdGphv aEiozlYs3ySBN720qb7qB9vwBkLyyBCuqr6fHXz1w6hLyyULLICy/YCqS0rYcu94QC32G2SBOk4/ 0FSd3UHOcDy2zIZsavaeZqvi3LU1GwYrHPXu8dB1udppvVepat1ApiJXSS2/Js78wRCBeAXtkWSJ ZVaJoRUICAwgSUKSjcSheSBH84+Lxd3zewi4B4xWDfKyAUnRPQSIBRuiWf8tROXilYzhaS0vByUg 4wsSBsVIxa1dbRtU0KriNvlH/iqJ4QnyualT016YXAfhskfm4VMu2YhvUF6dKncuOMnSL/ibVQlq 970K5crB9B1xbu90UuNfOx43bUb4wHdOvkW95u3HDr8+AQKpJVzlYfept79noIUf0tSQzyR0KgCK N5lLJ/uAZF0AU84murcoLkCakzrnuVlPEPO03/gtREPScyHSRZ1XOtvtsO889bHVCemkkhHB6EeU Gj26wTrtu59NLThIdDTpXYQWHhtvakPgSKiVERT3NRRiemBpxGw9eI7A8wd0sQdXoOlAJfSYi4Q/ uI/U8LJQUQUSnL61Jb+7wnOVK6wtOIppzOc/eoCBrOClGsBH5jQ5xSx0LvbsJVmQEAVljZwAvszB rwDed5noU8cPsoEXfSCvWjrjw2LXKKnZ/XTX7iLy8HPdoQ/eS28Wp13vb8fMpN2fiNVvWuYtQ4eN OtsyX/BDm1bxyXPoCm28b/gTdbi7hJvCkJliGaq+jo4VAhp35w5bI3Kl4+zrhWC2t0ZiepzMgO+A FzbfAHNmn/is9tLnRS1LyAgYbBLl5evUgI6UzZ7XrUAg/Ns2KWw2ol8Z/hDt4ao6cYkPxS1cCv6E PqbhLf9ALb5QaKCjLzQPbo3U0TFo6/65qmyjFQoHhG9q5lR6UAOWY2M1knwGMVeGUVZmQ5JeVWZT TSR/pRxUbq8fi4IdTGMw+rje3GIPNeF0zMhgbVMFhENtcSn7zJ+RO7x6L7xizAA37pLqrNXgRtEw 18Cgyq1hnGjn6m1mnioMXCmHFzFiCmCEZZAJFpPm8DWNcO4vm4Agx4GdATJRpMCUcDLrkTozz6FM i3OBxJ+NRRXYBcOJ0YTI4fV7b9b6igkAhxHh517Oj4VKSdqLNC515+hYa1+xIR/S3/Q1mLTx9sho DmwjQxkz7kORH3SUsE0icITaIBehHyaJF77oDyZiLh21L8mYYQaAYx6mMJ2+hfvkWTXAt3xBScUa GJLW3jbNN5iII3Bm6Sa+gpkh1l1HplO3bbMXJOdk6QhQtVBSA/6aejxoexiIxqHk7Md/bTUsKQ1x +9oDYeUyurPfOyc/BVYZunBGJrKKUBCpvMrwpmTgbcZcRfWGFdcR3DwzhU3Hqi131gSZ3i+SpPB0 LpLK8CqQRrltJ33ayHj5uH8Y5AMEAxiqqVT4LwiJ/wtwz/K/gvv//h0I/+lH8v8OcM9KwMjxb0U2 Aib6fyuyEzAx/B9C/r+jtbZzVLI3MPoft4WcWAiYGP8rRuC/+tGdnZX9/4QR8FbbjNlkR/K5qd0r bKpD1aFe95U2ncvcFkADbvL3EIdHaxLe3FoZFpJ06Pppr32g8YooMp64hokr4mpRruJ0OV8yGIiR w//+Tqgr9JVMM5ZjiNSIL7LulklHkgstlesshZ/FlFq7vk2aa2UYjPUeXtFAMsHcZHE/eUURc2gx 7UzwlXBq6eT2gTV2UtVJQ+lvpR8HRhwBvJALyA7mdK7Yt6FQd9PvzPU1aTBBLxemaTKtPqV79C7d cUb57vkgO6BLJDfpzKVwz5qn0Auc1Uk77heZ61XyRq050N+HK0isvRwaZO6ZzEvIUNsdaIJw33wo nKtC6lB2pKMcedGdQPyg2Rpyj19Y+4JN37skaQAQLBkKRGARvM+R+Jy/3LKgeWnW9xFjOKo3yQIM 7qHqzOBd0omek/hNJvvYdf48SeGJsiukHgk29lhqe0rhFL2FCiUZMJmT2hd6JR+D1EFGDNuGc+sJ iAysRr9SavNF2ggqFGj/GwCs+/LWb0fVbRvS7Sf9PIaimB/+aLySooCMl7s0hqCcRFwShEKVynB0 laDRoqdJx820t4J+XVhDX48tvWe2lnC6v5adAQa4k9VtzvtM3oWDPPgT14KREPbwxIlGSimhpVvh IBbwcWBW09F5dJSs3vkc1c6FaL67xgTYHoxmvpSavp0KUHpogCV9T2nLJT2VDBLJVjSifU44gd21 v1Og3mjUyjIBO4J4A2zX2EtYnGcQp5A/VklAGYbF7028d8CQv4lcrotHkRjBF9U7taP0J608o1lN yfz8O3cXkkIe14z6yxu3FNBYmn+jxsXGx8RkNasTLf5xjAn4dWXPB7HqTzXXN7UkffMDYs/J45fw fUU8zYKqOJM0001mg5VXcPsZucFHvaE2ZGJ/TqGUZxXs0tNMlFpNpXvN2TNSNac/bVrqCb1MPAvT Fy8Bznm5++y6gAusuw9EJGEc+ydXOQB/wYt0bvethuWgVz46iNDgrnQCe2NCKL1YUXwomGhQfhTK Rgje2xsaq/66SsDddz7vIhTPsM72wURLVWgEp3yO9y+KLGkk9BA0zXlX4QUpmgqiCkLPtIbu+FKx i5o/zeikbuEU+/BhrOMq5BEIyAaqIOji+CWyWDRHLMOE5z1KhZPFde3MIcq1/v4/NTq1+RK1qdEA huY7pZXodC48eMy4qrCup4C7VarY+H2TUL3jg6hQGj2IKiKxls3PmxnY1V2hgdvosyzGWZarqkMU MM4GS5JJHdsbW5TzRnjCzXUb3NeAsONlVJXDmk2o5uzLPzRbgljuYf7SAURq/I8On2q2n1fUspXI dUaWP/MFosuTjmXtUI02dXXWqcRJms+D4uPAcEQESfBWjr3+1rXiQBn5Ll1GfjCnDn7NX4gI4MPL yc+Uoi0i44zaJHOt3+8zS3MAucbBvlsVLeRBbyOnNPTDstjnO+ZoV5SGXxnqu89PQi3wsoe+kelE I1Pm89FUKk7WIlGfYPknlFYdp9YwYX1aUN64Rr82TXZp7oDTD1F+V2en+rsjHZgq1j5SMni0oDJi p4jOTXWSTQYnHikEYCZFpKh+HIP0pIHs2HD4HTce1LiVzMLJP9rRaW12b2JJ7gpZA5ZA8d1OzGtA s/DwOnhU5LbZY5xvWEPjBHGQRkwZ698j6uXfhjmrRS8yc2HCgjOago7x2EQZTGU/HzYV2cI5HOIY crpB9YtRlqZgmA8qXEwgjDCZJmZpxIJW75lmmc0wMZCDiKv8HkB9uroYlaPrtX7YJXomxI7aZFZv dEi1IUnN4azKXhOqrhjn1h1wARCgeFtnhzajUrRCmgq7DUHDTxm9cwZza6fTsW0KWbEJY46TPULE 9Y1gVjY6j7lltKb7KJaPaAtGadKi/VY+YsWh/H2qANTqUFWUyrbyvWUsr8daR+LyRKBpYfjRg270 8L54BFLdyiukBeBjGd8PQAz8FHLhQCH5hW55lBeae0qS5JWD0wGyUC1G5n8jQYb/fhTqxnUMBG4e jaaYPrbwmyQQyXUY4SM8LWCLwxohCLvwUfzz9zEgbC/TTLhLDyTHLsp1nXrsDofBpdnGUqd9tkim /iMN+OspC2uwA83sPZfiOzfl9EcI57rpYfA0EKvQjI7zXkeVg0Idz2G1gezJYOxVInx2IXHBUWG+ pkzIOYv7d9STbM/E7uvrZ+Tb1gKOXgztqUL2NBwzUmgrb3dXSIpYjw1Wdsqiho3ym5zlL1Y1lTcm j1JM0cTTu/wQnAGQpZD7AVYblgJsklMl68d+3ZjTCKNcB1zxQpWUNjFbfbrLV2Zc9w0KmQleXYIk J3J10Jb0SeLo+yvTEmFRASDkw6lm1lXOyDXvxXhRyFvY6Ap9pCmzRqQFZkmGKyNIIrFCDViHJFmT nsOT9d6qbT3CNcvE93DT52eLNaBYgNHh2rHhJiFY42LfPZf1oKLV+yEa4020RnzPTxEUI7/gzT60 XprbxT9U75mT7t+XdIalYmAiP7IL37Ed841UOAe6fcXsYuly15iP+fZ6vJ3bEXxxAel049dqDqMV cIRiIUGO3A6Jz/qtomlH38FjOa09HOpWNRTD679mFPCjpMiDu3SEqMyclAR/GfZml8GwR9JvJ6iw 7ZIY+7crJsQ01J5BUjlJawqvmw42yCTFTrMFhO3rrMHNY1ho6v2p87p616dFJaIL5oATm/e8wmut KBy70jU+81+WzxFVMzxs+iN3flY/OJeyA4HuyiOXM+owBstw2Hy9lolgJnOg0oMJDtB4EOJpWovL dOzTyshHlkSmgzyGtuWOszv/VC3GZXMNZd2Fyd+59ZtTcRsrIFChmoESvhX7YMQRrde+ZgKxhAmw vbO/jWrJqi1PV+YlfedAM/FeVugQmTp9zOpt5o8/UNZrdX0dzWn1mZdIHbznHf3CNw39tmzifkGv 5nrQ5aHqnsKIdtAWzXSuAWXVlaemuJnvn+4b5cNP16tucJq72iBSCRIEqONbVydz2EawhdmjzhIV K8Z4+bXCOVGDaIFhVWuQN+BybHPbNkKa/ibXmQXejiVjzb7gwH3/ejCTe/7s9jUFpygOShHQ1Xx0 22V02SI7IZdFB+Sb3aY8vcBVe9Jzj6b1EtUlH9+Fyxlgsnk0nk6etnr4jbmtsAVskdDOjFxWN0KL pCMtP7UMSXEi8moTKPFP3NSiSi5QEgUG5kXbIcbC2zVAZ7eqKpp6apYWR91gudjXGiDnnyuGQ+4J tfXBY1OlDaLKlR7uLjD8QWpo33eRwJk2cH8ZV7YN8we07esA5M547mWNeLA/ieSbv3JGVK2cptN0 CxS80gDpTuZh2xlywtHqrxFqEvJGjv3rqgKg3aVr1OFlBpM/azv9XsFRngmV8blArwI4gb2kaENd EYcvrgIZ3hERW5EZuLPw3dMOJpciz5ToPxSA1W5AQpJXS2Ncj4pd4KywUW8TY4GFBYGcfIo8oFMt 8MDTz+Qsv4vFC0VCKBCaddAM4sHjpY76d8zor9TLLdC4IuXg+CSpCS/qFU/GAjaFp22hPZpklU7G gJi8mB7tavy4o0vsnL9rvOj4rsX9z7R+UB+uPo9Mv0nR8AYI8aJ9GbC+wqZiQNdFn9h+Viye3CWI xIqsNBAPadssXJfWoBfT3kQxnjuaXbS4f8i6NV03O/xPd/T6i7WVq9zfrknDolvM/YlFsmQInPPF JSs0EzalymseGt+SczATXn5VwvODWf9OfYx74HSS5UwGTSZyJYzWkIBfHa4J1JHW9d6sPzamc8zM txJLVEnG+/pK2ywjqg63LxXJVaKZC6Wj3+qzx4U8op10o1H1awCwDD2s8BBFZis/SSXLqjEJB75u y+f3ceec87ZZjdShm7ZcRLn4Be4OuzR1Uqlp9AzZkLAw6DgIKH7BF0OsPvzd9lFnW+uTJn7nqD+F 0rCOaF3Cbg9TB/3qbwXjDwGOeIAqs0D9pf/Zttv3/lzOzjqBueHuzcKTkACmfK8REpMj219y1fTW NQINLxTInRu2Wthjd00pwvPLZ8odjd7L046wRi+uCsvKEBVSSINkOJOnFyKGDYw6WFHKuFjka4vo IpwVHCck7K5HvnP/zUq7AEBCaIElsjBjr9LuOgTk1Grmoe3wF9PgD/iWOxj6x/MIzZQhIytnmu2M 4SEUpqiLH0gs0KF3UYQ6d7HdaB1s1b2uOhkwpNgxgobwFNnNfi+QyoTM5zbX2hdgL9++TS8kST8z XnBKf7ia4fekdFVNUyhK8wAmSTQqV5W/lQD7VXGrYWRzvH6yid/m1apLx9rAaG1I7sFckFKC7JbO dhc2YV3rgsa+SlxjVN/6S244Ee3vlHT++dyqEQQkZtjGHxd0jCuH9BOzhWRRC8+YQsKIT8mq5rr5 ORJ1K99Moeuq/nc13yK1gVnB50xqdjLtOkUVvno5WRAl6td+X867CcoMKtpbCneW3C7dRPi5lJdQ 9Kf1EYJ1d1dz8o62ZXtOHXqC3LqNK6+lfXud58VhtDi6QqLojfvyNl52xwR6YMbfCHHDjHl6jeZH 1FNFsGPFJUgz6S+wAVjFDMXuAdUfm7a9NX9bSb4ly9maF1CgWkflQ7ylF0YoMHmjKeESx1Xp8Dmt uFsU2M9L2ECwUyRKRtzUsqzpf4g7mc3XQEy8M4rM43nyLDLHbHjyWhS5d8pWrTJqkWD7GWjCzza8 p0N8UuPH6F/DtCj1pQYDAErERB8g812XouboOc+rKVIZKFwU37RBWl+bRyQXr6V82fTqrZwZQuN8 3Y8rf45dmM8083agzp0QmYDlf4mdZmKFt4ZbECXH4E44ktpK3H16ffqg//DaxCy6urunkMX4qAKQ 1Iyoh8nrT0ZJCgD+6ssvkSE251Bj8GfFCSuG1Onu0jTe6gAv1m8hUQCl+FqlknLYxp8Yg/Aw9nbK rFInjZdw0lTci8NuOJQE3X6OiqE7oAQi/RWrxO9fW+rKlaWewDsxE+BiVKZ9NuJA0ibexU7Y658J MucwYzIIOADTCHp5nfb+xDITYc39YnqArEzDj9ohWAjA3Fs2mMC4w8jZ34YFkOUKc4W5d+4L2tZx /eteEBqUUOWFQog4v+ycQLEfW4ZpChK6eGkPH+BTnEMdkBAMG0KDzg0sEKhJDxLZB5WAnjm3rqhD Vf82YA5sQKKckBvUKQIcxYMLjpxfUERNeDZtZwxpqRccoAplvuxfiYv/YiPF/5a4+J8pNP9OXHD8 txMX/2nnxX/rroT/xGH8f0Jc/McUnf9JXHCwMP6fEBdRajpOhy2oPi+1fUTr9Ri+50a7Wdvr16yJ 4zNVnD51TLgZQdZLKPkB8qg/cz3PrY9b0HFAJCRX0khm1rcHvlleMwKkute+rw8v0l0wbunyB7So 5eqm7eo2jgZ/tq+vR6+24XOh48OvrmkLe0uA+FKC1VE1FFEMO0fZ6F7dNuf8ZN0UUoY2/fYKF/yS jNeR9Gz4toslNP84HzN4InRHNVJyhgttD3lgdQ9rYElQKdNdVqJ0s350IG/G7g4R/Hgk+RDxDfXa /iARN0pOuOwD8YkaflSA+fvdMuRqvfbSNRC7uaGrHF3bPvrWes0vBXahl6qtR2Y0jEulTk9Lsx8/ yykPTKTmvY+Mecp/TSYVlEUroJzqKWfiCNtwjMTuIt8lD/wS6HCdQEJEh0hPpjV25+K11VqHquQY mrPy6RuF/e691qpfPEYxM1HG5gxyrIJzpF6lJfB5e0gV/qTRJbLMEi1YLhuLCGQOqxMjh7qndcfo 1VCKFMU/kHmUNTnLNrfSyj00TeMa5emukCVEyy6oGMA+t507mFtegjNY1oVr2cEnF9meJBjt6qDE 0oD8MwfvZUIzwVnes+wgS9/PzCzJsgQvrPyxMbORRuoxPC4iiv/hahDNeXulDNq8XxR1+Yc+TPbJ DvI24LO4WoVtD+RXSoA9QNZIGBgVfJp/vpGQ0RLTvQDSrokRqiUF5hF0qO2nOvJYwWdsnZyS7cAE vvziPO2jLQNgWGt+Vkt/D5BA7RNBTjHxEKtDS7hufHjVdICUHHBQ6dl7V0h2wnHgpOlWmnHzVIn1 CHHJdDloq1kL7uzSJ9GcuAYOXAO+u8FniEPX7XtEjV+UZqFDi8tkkzBu0DtRP94D//CiLkzDqPhh Q0QdPpoafiersPj+AUPB1tdhDxxaZys+YoTNKec0tnRYVThbAHsa4KjDarhOV8x5f8Au90qIP+m5 K1vhNk3gtk8NJgyLDA9kQIcun2juEu2M2rws1rqWAhMnjq31l+hdnB1VvOck1TAqQc1+N2Tkk4Tj ImsOkK588bCGzZb9b/BRSVzU34ndMY0qzufGH4SbGuOZBFuU+7+B/SGqt5ZJa6A+acP7eTWIe64/ 2bmhPg6/MVtzkNMIleRNq6bF6Vchj6RS53KwBN12kH0RYLJBsaa4VBEAxMw63ETd15atoyIfAJma Kq5+cM0uwkbAkFBi1s3hIU4d6sOv09EVcjphHlva+lnJoNgTSOVbO83uhZmnlQR4rr6qbYOmddp3 DlJ2syXrOdn2dUGObonrFgxs18OcllZ6Ok3YGuIjkub361FnbwyLHsAviAJ+X32R1KYcnrL8/qri NNkdptA13GnSC5PF2ajIF8CeSf9Fda5X+DEcvVxfwcfJSx4GX3UCk4AURjTiWeC/chO4iUnPnP3L pU8l4+x55DrOt+ADYxklHjN21GAp8nwfEO/AEtfnExLEdnst1JMPugWr1StG1xTZOUPRdYzI5WDH FeutWcwWBMo3frDquN5YVxWpAx2tw8zZIulwVk99nkxiYxh6QEVoe2Rg6jnYkVrU5C6LTLeouYfv cfPYPI0vzJx0XNCyOzFTITfvcjg4jB/HdcsrAE8gIGTHQHUq4FDSNiDZmvk6AzXrAw6vyYgiF2Xw 7RdtypIvaez4LD3bmC5W0aauaqaDZTx4lROt1zbe/HjpKbeoD/MfxI2VOSTEV7iNtXQUp4pUi6/P IwrXTtnlLHBHqbhIPqQ/3D98oB4eNGNBnxJJD1nCb5qxjedVoznlxwnaxEcNHQl/pCpP04kKQXD8 YAUpS6hE78UDqiZojeOEdenzCjF3MLdyXscwm+37noumsSWmzdlnyiY/B1oasL9o2MN5hXohamwR P4d8yM0axkwbUoJ+Pwz0rMZJIAXCWgh0VfEfYLRaK28LYC/ZaDhuOgQCBrDyiFDGs3lk8aqlpJi2 RyX9IiQAv/u0PVLyLnYqdztOAyObVIbvKWZdV+qKcM5TBGB4Go4+1bmM2sl9OQ0oostns2hkejoY uSeeqbjzsce5L5l6UwVhZLOJRhZnVfrY6GIgaRnCHIq/5ZlyWOjsbLTkLICzeUvLdLJTwST5tmh5 1EohS/dLL67puFEe2f2SuqG4j85ZyZNk9fC4kjbADG2U0TS+IK6eQNgoJqNdRp5YK1BoBy/ELkEZ 9TlL/wADMFLO5LDS6RHhZ1j8JGjn3d1CF2flRH31925Qiaeef+aph3V0gtZtT/Q4WPWy9KfiI/aH Bd8Mq6JMpIY5abe6tDynlXlbqJCMCJDNhw3Gf18yUR/A1tElPbvvGKf/mLA8hFxzkeXEfPlmdPty oteyT4o7lOyd7OmGd0gXogNjjntLV3G6p71Ge3klFlJH4S9fGN3X9HvyXwrefpziUyL48I3DOe9a pF1PsF49kIz7RJMjl3d9VJM6aIDyzV2H8o78ZJrYrbRc3V8Gl76bQb7DgDSosXEHDy0hp6OncXzt 85tQk+jRjSyQVF0qHyUP3KTt44D3pTwKi6sa21bHK8wZzDp2mkywdMLTPrP6ZbBDMA+/CDyjEXL2 JKopFUtyQ/z5em8M2Q6Pb8Ob44Y1RSGNN/E7oJhhA4GL2lWZvTnLWWyBQR0XWmI0BSsv7HSoGYnV 6pj2U8mf8wfFK7VG1/MJ39N4f6DnF35YnA+Ba7tXHft5z+0OmSkxnt7RjbWYleBzGvZBai9MVCzQ AirMJP1qrHezK0Om7ApPoTV6HB3It4rn+eVI3QW2XY2jiwThNa54tlU2BpbP5WYwyzlB1YaUgGAX 2eiJuIUqORlqPPsDUaHSF7ZL9tuHu/m4e3uBxSPE8QWeENhBthyWaE0xCfmizwKVx7Bdw9n2OC0f SWqtF8Fv2QX0zxeWStk8BI1jr9HYhsRzLRkhDgfobOO+2POd6GxgwWUvmq6CIH4NGh75LbIiKfBL nglj4zxV/Fxd7FsoyLe3q7Ja2HTh5wkB4RwI9BjEOMfxEl6kJXWuZV/nSefAxkbcXnXina7IC7hr VKx9HQmbqFL4pcjZsIB3RLxJAJelvnfR7nXTiIkKrC7XbSNLDAUHX2hQOHC/DjBYhxOKJavrIvfP s03PJytCXqW4efNsTN+Ua2kMCjTbdlfk3G5i3derUfIfnhQpMbhBpsNT8p8ByFSzvxiWLMGIlTdx 6wrvISSOzUkiWSJ9luf2fMBWpuVSlL7FkO1zFbS0XxG5hILsNp3H80OAnUXdi2B7H33iPnl/pSJ/ nzQnl/3wsO+B8qx2OfoaYtodD++XFJsuS+xj1Ru+JuM5ufVPvlI0WVDe9sXlBvSrrRAH79eTVheF xJTS5wFFDixAb/UpxipnRyOjxgmTUdw7W6DlvLJxX6ZKofDZFinCbzwPvFkyPPDVPAOePNvb5fpK GW0E7eRu5SdEYt33EKwgTfj9yeREdDOr7nBLezDqSrLYyVDVU+9V9DCHhc9M2BeUKoZuWtLWsWqp 0ZXo2GF7CR+j17fTC7rSd7LKpDA62d4/GsfsXmPfPCZ85ijcOLk6UM8bAjJJvFEbnCbQk7nVX0wx httTR3htJYMPM8q8nFNZhdJISxmTuuhK69T0RZB/P93sbbqi3NsD2EUYemheV5YxAa8lOI4zwvSy XgSTDB8xhJdcDrf2Ly3Sv1MfLddt/oAFuPmAxv59wA2ypU8Srk+DjRkhXnKG9o0ZEMXakKxMzI0h 3Au8VXtLVWT+sWfWBRZwvjUq4ZBxbezsqHDn8f0zx9fdh7tvax014bScdJLzQnYoaLMwvbjfx+5Q FHumD4Kkp+DnwuipSt7S0My4+C3aG2IrsXiOv5Cl7fABqw0boLFRjs4kKbSasJjhLEGl+9VXemHM TuSgGa0uQ7NC2dRUdtoqvOn+vaqYFoct38Wa0iFoVGbfTq1OXVKCqmKpqTCV/Ivr/dkyf2h7IM7w YcDf0DLRmMDdnv0hX2/Lt/712JKwTNTGSDtpz501uMJur0y6oHWzsxR42YaOOWR9MCeA2+baH8Xc Vv815+NQO3IhrzlZD94JV7NEPWGHOD9/JWCSqnfGynyq1v78KOXEm2/plfMO17cn9JAvKMH8LBGg xPMuse27GpkNurKKeUCLLhqpM7hZEouOu0VcgBulUaqJAU8mSLNumlveVVOx6poeLziUnzm+eL+T ZxY0mpPeMHrfImLC/eGRXNK79lwj2m1BzN3NGZeLmyrdcEdm8Xo5pkFy8cQQn/b598VIW4Kld/Pk r9CWP4MeY6do4VT5uN0ZQVH27G6aICZ5deytGZIjZMTlJarQN4HO3i2nJBt1GWblLBJKsjyyRhaZ F0edOQ1unikikWlz2LyiFm+SPkllaPcXr5LjMVIBQkG6OZE8dt7l4MbznlTbrxVDOa/rRScaxE4E TIrJ5F0sG/2mQZ/NYgbAKiMJLZKFHDp/vDaOuAtEC1NYHXTjR+Wv4Kd1c0KlcOXdr5JzO/hz217T b5sS4CqJWOD1dqAFQFHL6kVDAf2czc0on0NN4ZsR6ZznAqD4hbhcDJhryV52XBjfTB9Ys9rpnue/ Xrm1z/OyZ7lEfBa05YEpLAmazOUHsKm66eM/a5rjR5DiZjdVtcI9lfpYtsujdocEd42vua70tzIL NPH65wHfmy33wr4MzffYM26outh3TUDI7YWpkqxuD7PIaJk9aJ/3DeFh5yYqEedGSB6m8ipRq071 cqzSTIVB+N30UMlXIRoSd5jczO3VFm68gQa/7d5KdQjdhrjvIAaXyiB+K3LZ1R9FRcXSmPz8bAZo JWrfRef6wHv+phMkBBDWEZZmqYK8Y2LQtPJgqJlah7IklZGHhfEgZyYwxbo9uugPnyZA4cJkjZNE SwX/vGJUOaT06d696kMKzzJZD54E6hDcBFE7vgAPW5WGyNM7j9rrNmdI6IFTXupCSxxypsb8DhLe hk//SlAj4Kvh5MxG/4Yg9CAQ1MRFk0l+o3bXDdU9Sm79g0gc24U4O7l5iD4/fJjkvZ4HiR2YHwUm 99q7El7SH+T7xvFFqZffxPB7eayX/kloWUjEpRv8TmvY5NiXpiMmppKSRqYQ4ddGCrwnClmcgkNv d6ffTFN9S0nrJ883S2wFEbupLipOoqQaNEmoCx5s9TWAWAuYU7eyY/MKK/VuTVXo5+nwzZBFri1H +5cBIVlSRmh1PjLQElFEldb3vbsQ0t7XxOkRKu0eJTrQaZ6lhTllAX7MJi7vWLNLjyQlUkYSdeNA b1fgymQu/MdorNvjNHRObaoyCJT0U1uo4LvzIj6WwX4JFIGJeelY76r5fJzX+S4gQHLi6K9/JUMY /os/5fjfsiEMDP8rHcLwP9M2/vv4EIb/lD3yf0mI/L9KyGD4D4kh/05jsDD8H+2/iFKTatgcQ9zq VXpEso9D4f2kZUkwGUdmUlV/tMxBl8mTGBgIXYSFE9kdRW8Y3OSIbKzA5gcuGoULDvA8EMqnpPp7 oJWmsvm9IkUmeoSL/NIlRAx3yQqbpkXU7MbR69ns7XqLi1C/jKVj8MGG9L4krJc4FMmI8Ak2k33t nNU9nieMSDX083qjMJ+VxFA5kQytVKlDyI0J+L4gbKw1wAGvQA1GdAmMzegdM3ZVZVJoKlClZNvX e/ETnvPoEh/6/pJqCku1Qm9DBA/eQuhCFdtW/nwNjWVyUHinphMdM6pkPgg5Y30lkS7Ie9NcIotp +8EVJJGaiVeqUimJin+nbSjhpVhEk5H5sXZRipA0MdNALxGcYt36mebFE7v7oXWQQt0ZYIcqQkxe 0hvUyXP0xzd+ke6CPtZVtALPUq1OaS6PaBkGRquFmDfF+fzS4w3tJHbHLunc235Bo+qPc89v0aqR Y1OD8rejEXwtltaNPsB/ueGFXiTk/Cpaltdp2A+l0lii+cZ6r1YND2QOW14zXV49BwjLLByrTW0Y u4X2+W2evCaI0Gk7YIy6JZmcS9k0Ke/FgkA3YBy+MlTJj+nAVbnhO48KFxdiWWBscggrTz2U48jL ihXFwXyVniCoU2Jem8BpjnB5YpXfvsSbBLtI1BYFISBWCqkM7QvhvUM81F98tOd44fkYa59jW6A/ CwKg5TiHfmPXcFmhI1BimxHJXt6TRqs6emL+xJ3baA0Z3aVQ8u2GYRegWkavC7ZLS2lFIQS+NwGI IeoPgFQoiS61OUxhjtH+7CvQO3FPS0+FrtLpXH6p12zBs1X4tAhSvLKzKfNiO7mEi7wMRxDmy4Px CJh9M9AgyP3YuAiwaElChSKuqf/a6/s6Nu1qJ2ORo+ZPLcATe0OlRs0TmmrKvIAchKfnSnWO86gN ztavxECo0yXrF0hDpkJFE06vc2dipPkRAyv0Vf5sWK1dJWp0SSFMYkObqCF4bMbg+yuBkdfVtkk6 GC4hTRtL2ZN82TohuHIprD4Dpt8dA2hRP6/4DI/1UbhGE0HmyJzIHZZR0oFWNo3NYV6kMPKZ11yk NLAhJMmK+Kh7m31AYawk5PeWSCkFEUvMIi3MpAkRfxqVS2GzBeqTmsIE146cvhJlVppPrtjq9sr8 hAmH7BHy+dRDwJDBsalSSgli0SuqpgU3Z/GmwC7VW3VZzTLTMLKR/0MT90ZHjNb8YfzM73iSu3cD e8B4GVbM46X+Y9BonQf4psoaF2gUMhCsgLbUHRQJAsS+WdtD5SoiULkLpm/6JGH1hD85ErrUUoT6 HQSy0keOXwQp5Cp885L8D3IiaXUj5Z96cqBOmZ98nszYdpQe5uJCd0cbhNdY53d06xxP9sp1AYGc sL+2JjO2j6ebp/KzmrpCaSeQEpJ3fa6csdzkye24A4namw/xvlINEbhekHQ6errBmAFQCqTa3bD8 1Do8YPtvRxYmFJy/+OeJdTZZ5Ggj2lTTpAVzHfGSI1M0tIxlVUXfXgZznT/6iabU238lNxWIiDRZ VnFQxlc/+2/IBiLciKjtuenV6UvA7CGcw+z345Tu/qaG3QEsuCGD3qnJknapJSs3ruMO4Zm4RHE/ AVCsw8DZ0oQTJYZd15cM4IOfczbej/4RZhlOfiMeVsBiTezpjC4gAf2m0L9DFnGZjz5cy0ihrrqK B4mdKNgjl7CI3i9iMaY2gl+THLVHBk9ThUeSbd1s3wI9GAaly7Oh6Pz+VLwlzD81EXq+HMmUPAJd upFvcvLNpROztX6HqTKXcJz1gdZe7faYvy+qGopUXC59th4r/3gmOJt+I+AoYnguD3bf3KCZIzMR SFvnLAN96I9CmmbaFVH0GmNxG5k9ea46xOXfvwCJuVdGH7VvhiZ4C4w+q80eii6aqmbo9xTyYGVO 6T5xcvKqdKeS19+/evdpRcCnuXwIB8U2u2GHUjQvuK66WEX7KvijMyjahpAk1hHIzw3eXUGSYYN3 Hr64yysYxZI3hLMTM50PYDYDwu0BuUPEXDk6Lq0p7YHLwtJFhgk0YwyGNpY1b865Ues5tsEU9Xbm 3d4SuU9wacqQE/AQvNoxrbwPJwzJbocDGkqjwXrbi2zLs5OJyGGeIa45vyBYZ+rmRcCop8Ur4DGP pGLtvMQPFfUOLsVdWvrZXm8wqgvg5CTojmDEbnGVDhEpX9BvgbJV5c1/h1qD2m+Be8YYR7TZs7GO HgWNw0GwOQR+BHWYpPkpDtXq7hTs5e/FwgvsYX6NnuPaas+6M8/2IIc8xuQGGW2bWUVRDe10b1qi g9gOryiDh3T0gZwwYiRAau59Ui5dEglcBmJMtQFW19pA/hEJvPkbwMIyIcq4W7xVq16XA8neHO6j vCMpomL/QbELTG8rcHI1rns2Ez6cn3I0lR0N8XuPKJoNWnhTOHMYS7tC3iui76DbungtNNO5HrZs jYhFY7CYOg8MNeM9MLsiNvriIhO+PBJ3fU0B3at7m2YhyRB+4C385a15hl59Y4Ofo8+HaoPp91ik HhPtMH+8I1vSvQNNPF6UaRQ/UWCw1rSgQE/KdRfahtqtzlkJ+x0MkjmTXSYHb9my7w95TSZj53bf r+qJgD/hpDSwNUdq8cjG1cCTMESGTyf+ddlMBjpAq9gJ+KoUi0pqGk/Lemb2xiAvwccaPwvtlp/s +NUkZsoNARFqqMmZmJJuP9dOYh/FYh/Br/xPRtLVd3HCv9gbGfwOn2rE0m7y9oAgmCAuh+S4AeSU 2PAODC5EykVQ4VWcd5cplUbEfcR+DHDPS4pBg5NRjWLjmBRGrSTaFcBfZZrMIN6OX8NsGeX7H3yd +RJiLDrW1xgLETohyb6QdPS4dW65I/RIuDJ9sQePRvy7OivL4U+CkAC5rjwcWTgkjqlSnSeUuF/f oJNs2LFsQckh+i7vJHCpo7HqXTs8bVknKVrtqRuwf5NwxquVBvTQjwlnjJNXqU8EnAieMgKzgp7E doszFUdC0wXlP0GCn81u4FEVyWtNZzz9Xpcx9BtVmD6c23AMixV8eV8F0IUAQ06dtGL3D083iUdZ RgXzr+b98K/HvloXMnJAP5ZmW3bufRjjcHoqrST9FYpKVJmWkBiUbjHh6wKlNIDQ0lPD4ckwo5GY WOujfXd3Hd7hgWNSy4HLfRocMC6+bhzFPVLIJY0Xi41mzCoIYy0QKI1+rhMVM1Qwc7WNVqPWHxUr PfUBSY3rQBpDeg9oNI8E3G9dlYjMCIf8jl6neSAUPEYFx9ldYAc2LOjlB7OI8fOCRn4IHIq4YY25 hMF2RQX14G7gHLrlf2u/p0UealMFU0PXSVz1J06BMcK4jAtO0myPBx6Hz+F2YTTW+SIoJToGNFK/ 4x5xiK5FTSy2EafTwxr6mFZGDRpKz0P4de63USifwKQ7n4XnSXwyRBGK63339azOjHdES4Ydju3O rJrGAu4pDMUd5tGGZJXlr3lQEqhp4I3T4Q0++eXEQ+jELUWoZnlQOg6JHA2Dkomtxq6tNliiUMSV S0aADfN+jrzqgc7boIpCwvoTMNassxQvYpRdkMs1MisodwffNujkkkkzy+DumQmoihVG/jjSrom5 66hAO3RymZmd4Cw6WOkAf8DJN9mj87SkLosudOoPljWnuxeWP300HtCOl/7ShgGdSJXxrIN+pzUp uKX+BO4nVN5TkhJDnDMjOJABgwGOgOHAneCjhyJEXS13awE3IHd8ynwjeF57bfCzj8puKmrJwBV0 au/BgNZbYzyrzTCoxDkStuNDd9wC6H++Nq5qTnXqNGrSwrYpib/qwAqB8l2JDHHSt6Fhb5WzXb4r lsSI6cNDTk5DyeAkQjWErhaGChpOvS1xa/vnPYgeEUFTO9W5G8W5gStlEbpiCgDeTLdch2zSiloO GftIkc7oXk64/bZCh9SsxkDrYkBDfwbtbRIdL/tb/f+AYrjqbMLvvNERKlYghl/rBBy0FEznee9m 1BeFP7c7p4J/DZcqQPnPScUYEEk1cNDp7Oz1Wr4CLMSgUNKwAmoB8vZ/7QSQGwSX47zubwcvwkRT UoD6AbcX2Zme9UcFAPu37O2i/ZLw2KsVwh86WEBOt2OOYfS1pko9BupuoKWW3TbRIWjWH/+tsrSS FBq2PziucwHCfekHjOmBd9EPZCncgcZpNXDvKEKnnlh1oesJBNu7EF14K7s5fTiYCXpMvKnOAFBv w1Pf7bu2lTtbq9g13pRsRAUjpBobEgcCnFNhCNCJ6dyiZWIoo0JsKWTm58y1vie4EsfA6owHCysY TXh3T3gQcpJ1KqYBmjWyO6gwtqKbiJRqYz7DPHBfIhjmf6KIwRgg4MyAzh46pL74mf8Gm56Hsggl q+nPvcNiszk97kDsFsuLD6/Irm3jvysyEpo3/9Ta8LErpuULzIHPaoVJJI7SsnxZXZ2MtYUQE250 eoYThsQKlJFva3sDAeaBbraNZPT29DNeXytPfYWT/HpLYu1ce3lRGeJEKd9f4fuQ01eQ11xHF6rS XWaRq61ZzT8gLuTjjxqizzBderGMlyCnajkZBVyXi8eBvGkl22MrN9ixBrZwk5c2y/Ym5Y/vxSNT jut2/1AU2bEEDcAPFajWCE2SKbFonzDMIa0DlRLUGoJkXfhYYU6SoEiU5zHSlN+Z7mbFXb5qDVo8 n/4qhCPHP4O9305Z1/yliJyfwtv99XhQCwAMoKRYSPNfgOL/4t8D//egmPlfQPH/THf4bwTF/ynr 4r85vYGDgInpv31rAMN/SMj4n6Cagf3v8X+W1aCTuCGK5pOrNy+ntYBmHgcCc6mFk8ome9DgJqOC N+JrXgTmKXZOajme9pU+jr/hZNca93tc9SgQ8Oz5i/0la7F8jY/7+8GJ8vn6F6om99SQNPWiNHc1 03xZ6PZg5vTgYad2kWGjl/jZanrfD5pTvXsGyXri2pK7WawfG+jXySPC8gKK5Fq2ObbFliyL7CWW VuRznrBNa4figb5O5lDmD4EzmmApr/NE/smksUR8Iff4348DurNnat+Ekqqm9Q82PRlKrScJkkbr YYn9wQAkr5hTn87IRpEmJ0Fsg07RtkYrFRrjwiFVThUoK+FtlWraIqvhB63ilbNV4u+ON8wjmUVi 5MxWnERDPjF8eUhLm+R0eX8H1sgZnCk1zmXRVs2WsMjGYBooHA9O8kF4pbnpXQrN88LoDSLJKyjs 0spTrSxawvOCPzDBViaV8UcSreDeJxsjGd2CJJ52xixQGcFlVwL3HkChbBMEeoVId9gmv4Z/PRpj XgW5pr3dZDsm3Tx7ZxK1PlCKbeZRN0niH91OqKRsoRokWbeYYWlBJH9MjcgV9Exo1KsoX+MtWijn O2dNF9phtLNPHJDImsVbZpPH57Oy24eC1CQWKew6MyJmBpacJkc/lJ7+OUXti5+dUOS1wjbzWDqr KCrsIOLJz3RYa4a/iGoWUxg7yNNmx82vhfuAFJIqTCRMM3B+EB9uLAt/cGHuB1dwhc0WuIk+mBXc EFs211q4q7nJeDXCLhW3FavuY92/4ht2OYSyiLIBJWPDU0/jqyOEHQZgjEQ3OqSOlE2mfGHp2wsi Eu/qyD8gYvXYCu4CT+rYMwXdoq+yKJyL3whE3nYxU8L5LfOlNxxvtziZEkVmSyoQ+9Dn1YowgN7Q PQ170okn95Vy4jvptWEBELcScsaFo6i0wu3za9KO2eG32vWyPUAIUalPhFLGJPdQETe/xWDP1FfP 584ZWjqe9WIE3bwqaoNToSOPMvv6fN0Dtu4GZdVB/TwLIxgGR7uGMPM7ienOnvtE0prjlCYKmpQZ 5882ya5/QG7hZvSvmjodKvf2HuSJJIrT/A4quLVSyZzDI0Ksuy3K263LM9L13YPlKIboCiAejyho HXwqkTRFXiONK5vAQKteynwnK+YYywV3W8/ZSg5kqya7NAXnCwtb89P6+moa6+QwuegK5+po65kC 1QUX2AMd8hIy81gHG0kET2zR7Vl6ElyCvy+54hmUkg1kGWDHgNBrLex82ObO+ZopKnlRqCSa1HHP mQMWuaGPHpKoP70r1da8C9Vc3trNOBpeIu7VR6s8hDSJBaBatndc8k7RqGCvC/j7zArnOfTf39Pg G5gP9xSyqfHUIiSx1TwdUkJ4u9NCkNA7cZixMZ2FtZLEgXX3fPBmIg/L9yG9GTO3f0og0qobGHCO IwWGmHIr8rl3vX0/Xu8axxLSS2k/v3wFnaq4hBKPNSEyxqE2JD7ZLvHffbZ38fvWLJreNkXzFjWI LT56FO7WoIVAgM7jd122lwv2AbPkf1PIdYAwj59qS8jPHnGzVI1xTkHXhzH8SUFj+KjzcQaKXMMO 1i1fol/0jwDr7RdGce7ihF7Fjc3DEwNije04NzHu4C9uMtvC8xvDBecRc6aWc4U4srRSUFNP4B5N eB2CcQ00HmJlH8GzMXk5URsfRfyV8J0Nc7fO1T1qO7JozRCY35mfhkh/CjMA4oJ9SaBx8Os33hIK qigVtwAmMqrhDcs7AAm47zXshvlYHXKf5qYzKA202zCqPuatnh9YYIiqKfiTrtFEjqBSwZzDTUqP W5IQwlJpfN67afRZLvWAPCKxeExhdWArubOSc7I1vVSfK64LgydwRID8Pl1UUp4o5i/sgI4ztxTD QvDHShLVo/VdQEaYUSlBI2VUV48zNxYp1calG0pxJ6m6K1da7sSXWe4jg83QnogTPb7P+9rl90qx +OAJIN4mp5n1AS89VzC86UWRhrHFu7yFnHIxy1oZBZc6D2nLHtMw3CoKHRppNTtUnGXGDH4CAGj2 KEjw2RSJHs3wI26NubidGNxfH/K+iZwq64KqdWldtM2uMWHmAyT6n3dKWCqOsUTxE3W7aq8d6i3Q okPhnlTbCC247Ya1u3eM0QTQopfJCtFVXXwlUCMjNNSlpSkAhIXKZ11WoERscwrs6CbWrXxzrU01 yW54QypsNQAMgYm/kLDRYX2Gcx4aHLGyturjQa27M8ISD0jF70YFbuDVdsihEX2WaRTSrXW/UVZg NH4C+TQDyF4spm2F0YI5PbXde93M9uheoZ7lr8l5M21G2nor5uRIoNm3oqEPZP2QBgM6Qz7AuAwQ 1MY15QNYMyQPmdbOgConWcoLMvGvxV8l/L/5kDJC1d+8uV+m0IOY/G+R77qGfpncGI3GNL/oa4mo rc03CfHXNMH4ov48mio6NTfbqGPxzyd8dvS+QWghlh2rBzsM1SnotwK3wgZjiuh+CcOXrmUiNoJK o+Znns6g+pLVKnQt9hhdks2SV1cEzbKuLaGZog139CzeHai4eVw4876sknbcGQrobCZjMfP3kOG/ 4a2kkpxBz2aFoKYcQWzajaNmPPuaLZbOWarydNW/3SGzpN5FTEKOeMDRliVVo8zyfX/ezFY+CX/e W2T7yYzh/ZnHqM7yW9L6FvUvxpQKvoo6MVXJ+9hYTsLYtQdoR5/ttU4G+orJR/CEQQqB94gO0jMy UPS6YblNWC6m+x2h+ZHR5LEsYgeX/UCU8z6W6vo0hFijoh+wANVhZviMq0XJXuTUpghAP7BQSt8Z mHCkDrg27BSpJGtGLVf5BApazkelPTpCizjN15d6qAn+Z/Gozw73GuD1LVNNGjSjHCAKJVfuLqEn wx2xmzB956Nkv6mfdheNP6cwpe/ZmXKsOz0grxnfBp6rY8Hu0x14EVsfnntnEYDFCFN00fPoLnNG uAGGW9DYUm/aF+3yNswQ6U5ozA2B0y71N9TrhuikTfCIT7hygxwpesOHn9si9rKJbJEWhecurlSG TVoUcQTg4GMKeSBJRs9BRoCMYJDoIpxXYTTtzmzW0eiDpexXHtg2m3HbxVWYCfPrPteuhNRspzUq Fcno60vhb8YbLBFn7ntMo9LUWs+e3/uuYpFaxDxWH2IOw8FQySfyTh33rLeE70Y6D8r7pUc0hBfS wZEp5vzoR002j/HhSnsjJVYZ2HsIHVvQc2EE1NHBNQh++Sd39yoz2cHBITPA7RuZtFykX4AHTGhh irjJdDzmXHX03QarZ2NG1oETLSdED478Q4bGCQ7a+Y/8z0d/UrJr6hrv/S0kTI6oVWC1l65X+sPv gShBWLhD8oS3Ho6/4ZgHOLkgW5hSnMzC817Gyft+M28jpoMTXmkYOWI+HnZ65J0yjzfyz+/fI86i I8JzyNPwMSiWZNnICSPcdiCs4Rlp0V2v5ThFlHKQh314Z/Yxplc/VILM0UMAbmPULBPLNTzqynh7 J1iDncNyz8P2Ei+igE4tcI2PYRggVjuuCx0DneUtfqeE79rV/5A4ymz6hv+MujdfjiRvyRtf1J4W /3Gnte2uRNNghwcRRyDgT1DBgWGublmSkGJcSsie8Zv5+YOT4IK/LZg1rO7Uca5aPyZ0PwfBNxua iJdzL4p1XxYBkPw2eTEpy3JwUX/CTDl+SCM1On01nZoKup8yzCkn4fIU4PvVJjb+UWc5i0GuiR8T c+uNU6ur6/t0NvGlf229nf1rNkaM36+e0xTHkTqxNVtlSG715tehb5IT7szX0ftU2PjUTy0T9sTS W/rNfEGu32WKrzo4D9wvk68/EVfis1Y6em23K8gDn0EPFymcQYsBzYIN3CkNJaFLkJvccLw+fWNr Zj2puF79uJ1TX99MljzqVNF7YQFf4vFQxS6VWVlHLyJE6mmNfPgj9NP7RSKR51en38evr0y1pfxi R3XvKGbzHl68iha/ug15Xlt2sZ7GDNLzndf4DXguHVrj7o79G+rQk6cRVZ6OvOvUMWKhGrdxkyfM RMQ5D6+QaWjr1iyz4CDNLVJ9XiJ0Po/sFwz2wPzm5q4FuN6eB0Oc52Gx+mRw8OUZ+QoEPukz1a3p TaQJmGRX23XDKcR3Ozt5812sjC8vErEvO2gPl789frEN1bmAproaXKHSeXiy223gO8/oh+ooQ/BV Ui+jSjt9BiIKwnX5fDmu2Wn4Uj86wHXLaC+oucaOqrEfG3JqUXDApaNw2X9tG/i1hpZoQtTIqdXG xnKBXR+/gRQ7r+TTqpg3HrQUVxxrky3ZcmbcNXghP/u8nhUA/0yMubKa98zfq5zpSuxc5qyDRimg sXV9T8mSQoWOZlN2j2ZWz+nzyGRHbpmkhuo4RcjKLAqSG7bq/Z5aTPLKQmHWvFuJePoGJRrRPV5L h+M0ckSYo6bRaY78+STfMlFO9ZfO7vRuE/4oo9UVtRMrf7uh66SJHLb7eT65OK7h1S0M+z6OFSsZ 9nOdlUP/xfysQYVmaU98YODAeakIcsctW5PQnJBqNe6ugFB059MFB7sShmB29QlTsfUbbaN2HD4o HZhi12MrTeHjZJi5pcvI2s44f0Z10yxskEbxFPup++jP/pl70/qFr58b32oI7cCHvcNHxyFwsamP aBaFKmJWKBksKu7tGday3w95cWLjYDgymrrPls7QlSVuCaqKnfw6ftnUZfVsZy4amQxYhylIXtDa T6T/Du7zi5xcq04iuQHVaEdn9oT+0njpaqcXO1a8p24MXu8HFRxsJtfc3svrDfxp+M+W/spjpl0m /VLX2+LxzQ8GW+uNd00gXSbOSL413s7bXEgSwCL9yDRgW0EdlG0we2q+4zbsOvCPcMH2/gn7EDnf x4SRI5bhis27BpYkclQc5bNtog92wF7YxZsPhiFjVhhR6xmL0KFIPeyOHWOTziV6/9zlnRhvUD7v RL9MXWxg4NenUrgOJoF4Az6Fw5F+7uCcfRFdV6QY2hvvcCsM9GvPmJBkK9V8zfcHuzLPENz0++8n ErtcpaH4yRu0m0Bz12P2ft+ynQPEhq7dYZKapkP75zQmoj93cVoKz0T0nrmvlXAeUEmr/MG+vT1O Sx9EuDKXhQaPBgcYU368kT+aKW5s3/AONiFOyNowpHT07IPxqx6OrsE6mg+CV7KYQPE35Aqfmfq2 voGtJ105wOHw2DCSBE1Zia+3WQHdZGyk8SWTBtk8dluOpqC2DoZV2Fhr8NglBJ3UI2OV7hIjno4p QfXic4n4C1mwkujFTJ+IJD6T5Pu/2YY0+0Au7rrR6VDgHWhqLTzrRJlIIvGoI6J0j82OiynbLDU9 JTbVn9rdxfyZ4hJVEqgkkzCDiDehu0hLR813ACxON1Q7W4dc+YIJwry4E9NH0faJ6SMhbatNUfAF Cje0RHP5KAvCQIpFeeGfrOGzT071OGubpD4gnJCq1oOuaMdcd7N1LExbFMNXYwUC8Wm756nI8FKD ofKWA4M4pYpGLaX3NpHAMt/96I2mqwY7Z8fsUX6gVWstPi5ezDy+80C7IfG8viQ1HDRJK1Y5P9An BxVsI88hVwwdLqGkJJIXYgTvVKR8EC6dHURLI1XoaE1YKO5t5lj9z+PZrJwVVy0Z/J3CXgMIkpXY l5nbbBp9Wkfy4ogZor4peVNKOcFso2UbsJYRDfUxm7gNGh4JrBc02c5xpS4TvQ2cB1gIRF0c7Q/P kbKNXaK6G9wVVSupP/mVGwiSHLcaB3iX8dYJZ8djtAlL+qmcF5aLvpgmLRVy9sRyDSpYHEa9VNNg yiXLSf/iesks92mk7B31p3d29MvNGjxnF9HSB5UlxlLZYILXd7BVU2fNP75JUfEEZJNcsJUmKrEO zQ1kxI+N5r9jKz2bK+AQiwd7NJj1YCK1OaQ/MBPnYsXPtUflHsM2lgI3NKeH5s8hn9l2KfLbYUfA r3IoNqgsMxsToiJVVnTqgHRQUvPE0i75o6klFqVnwlMKDgbXlOhRBBxNjEN3LF1YilNMVAoQNQJM pl9M7bwidW+MWSw7Eha6RGQCd53tILeVCXWsO1wYXSspRygO9x+ta5RnV8iJZSdo/8AoyC8Q2mut W24ZaQA4vpusdF/i/BE497JSaxcu8aCJp8b0buoWUXsimDwu0zKzaoVGTBTpls9dprVdlwtPpcxo i6yv8qwxHqzS7ms32oC2fqcLd78jxJLuWg4mB61RuF1zUGDYaG18AygxTBsCYLXBIGEoV/n4PhXO XKmBFfEiWyHRgi+Ybo5/+KR254ydhlmbQY7P9fGDloEece6ogbxeEDyONMSMMrHLyWTmZ0iNXRR1 8VBJfdSKEO1zQ27wXHtyiZFyd7y4WCpNHE3wJIDnwRNQE0JfFeh1XeyAY6oeXR36Ih4Z18m1xji7 k1U1No9GD23u4asElmIrJZfNllMBpl9fZAZwxYPReue7sEZ9p04DD26mi6QTxJdp2EHryJpQjPQ5 XUFx8UkTRZ3Q69ex84C1uEDizeDw2da9+HjRcDi94Hwrx5gWEaIYNlJ0e1wm3g6EU7SJNsJvqkjg cLOKSGi3o8uA1rSQoWZc8vFamCv9dp9MHscUOOk6qxfdO+uaV2z+6Ak2oTSzIP1jo9e6kFeQVq9I WNqDt4XVyZ0acRRWL50dymHdHNo9NtYf7rC/wphYQCFilCuXbRokd+EmWTAD6+lxOfgSOz2xVTPs EQ3WqCTEjGDv1tJPgdGx/aLPCiuqqL0MmhykRN1/mlno8u7bCGW2+lXvjN6pgqIQl92YEUib7ZCN rQELh4xXDQboCIIbqYHu4owbmaygZrxtAt2ttLsnFxOyzvL6gNRi8J5hh0lms1haRznd1057UFnE VrX0+BmzXC5RPXB3bqTPUeM8EIsCs66SufD7qG3D57poDViLxvnANM0GcUUBgF1m2p+BKZp13xh4 cuIsVGRxeIv9mJYX/xi+kUVgjLbCdbU8NCKe5W6Uxah+r2mP3UE9QZHQwd5O47E7kmCFWEW0Mlc5 /7esR4iEHNJo+t4QPynk1TSfAGO6OpmQuP45lf4Vibxcltbv5veeO+o7WcSGOyy7Qm0UdleTy8S1 MpGVEGr93XrysPkdCG0S82WaFMwh81jDZcE5lurACC9vXVgwtl1eN4ch+spkhSXvOE5+GBlJBks9 g7D8kCjL/NNVgqsQUgLYttSIMGriiQOiDGTj2iX+fWo17BN2QmYoQle6LKKCmLWLSQ+LZfkIDG3M Th3jrfvm9zCFw1oP/CS5vnauwUkGWg2D/ux1xxKJupktiSo0KzhDP4XM0i02O9JmVaaAJYUD0Dt5 OEtjlKQl0tramAHOJyA+GCxdslm4euzSGRhL6iV8nj8ulW0tE3n8OWP0ADhL6fGjaMvZEGW7VdXb tBL5iZA0V9/MLxUWyOw6NSRSXQPxSG2U41pbWUQXMYLj1a81n6m3jOPVJqP+p5+1glTu8rvW+SXN QdCf8Tw+v930CInSykf4p72zOpBIEgSQdMPbHiRlkkXL7kEZCwk7Mjf0h/YAgQxDZhuRcwMRq+km +tgtPv15eBnEPRYRt2Sia/UBeQYehKmMY9/926etVKXhGFt1QKZHuMk7H9k0Zc/Dpq2ttBrUt89O PjNIgEBMB35E1tSgP7J9b1Ed2PG1USj6wsJ2eaGWC3yXaWekSCte9xGhavBoDLzsyUCZRwUE9wpL e2Z2+gtz58pR0W/itkbM1sl/FXhu6/BVdFKU73xM7VlFHKQhFzFCo4Y4j9IJubAdNdU+nW1blA4s 9H/Ono4uP2dyr6BZPlK5cH1p661W/XSuvJmCLlaykzbJjG1lMlZ54FXST8aPcv0iDiFxibVDyh7a WGTaPoqEnJYBVAZfbVgYSMUmXtGf/IlScrRnYxiWUSXfBcTqUhpu2WFWf9Q3HfhdhaMcvzZ/gKDn kIgrTzCBXD+2nLUly3exyp7jnuKYICDuYecWP8D80FYg6oxyD+LnmfI0Qi8DywEvgs6QOLGU942C B6I3XyI0JWYz5s7Px3qu/dGApHkxxqi4F46yJZMMSutIBKISfg10qQGM7voKU2JHD6GaTi42rIOA v31ykTd04ZWVFDnMu5LyzKpGhng5z/WwpEMPBUhRdKgSV3JWwhbJZzdZgFXV3RgTSRc5Dc489QsT 8HT/M+TatJQggiQQOQsJwW9jLhfliTdRscjYQrQMKCdpPgUVUkFURs12PFv5rrTbRbEqbidbWDOn 2LqmbVwCtqWKkDhFzU2pD5oeveN5ORGa8TbP3IhsFexopBb+r6PnP6Qz5N7Rv7yV2dwf1al+1QxT Td83OnbxEBgBWBXg3YaP8ja3JwY8ayHxBxsozJG4Bw1L8fX6+ATc3DAiSgLZC87tj2uvzHOpUWBK uvubDoLgsI9NZy+xEImAy7yx9/MTuwHw8Oa/w7kJSHVuKMURdrUqBYDxKCASmDS3JWawRExfq3ws ouoIS1jPBt2Sr9ENhWxP0JIFBbhvjEvmrff9YvmF63rARVz5yc58x0jnzMxGuecNeoms0cMWoY6d s9Uny9mvLdzK/VFw7oJym+3deJ204ggxrON67hMd/Gx21gKPUTWPpsdNYmd2jTLaw+rshlTozt+p F7l1VwpbP5sU9KvFjVjGL8F0unaW76enUE/o55REb+4CdGi9z7pZSXaF/hpRc0sG2EHl8Prh0pY8 hUEr5vXa9j6NQdTLSFZbexs0SzREZSLhKrUXoZMjMjpjJ4w73C5umilqNQR9Y5zNSkkhOW0fl+ZH shJ/ScD/2iAhWfYlqTXbZqVAkS9tXG4pxBivbVxs07WxyvgFen+gJSlbKea6qOVCQD3XJlA9dQXL 4GNiQvb59XkLprIvhieN6bl1w7BL000DO1LKN0lVrPbZUmV+yqtQQQueBwF3VNZG3WxWNemLrmMi 25ItuH8jggMg9Bus/JrKyJFtPkC/E8713fy32gKr6LKheuqmNI/t/WexC9whaimy/SSKG7SjA5lK tEB7STBS5cMmN5+8NcLAQIu35k+NuONm7MOYPfqfugqBZQgUUZBLFPuBMW0pE7zhbWEXzxZYu7ta uZoCJ79AhHmKeo0K59WFEFCbUSs0xAoGSezPZkdFmIIaT30i+KKE1huUlvW638CDtJRe2HxGRKPW Pit/GK37MuGAC++giK9isKMzcfpwdz3SCbHegp9rHE7L1lxXmOBwT8lH7dlYYNBoLo3EZq6Jo3Cn B34wmT2dyXiMwKWemMyHbC7DJtcUqj95A0f4tbqRaD+HUMmiZ8h3wpxGleLZLWGeDbBN0r5ViTFQ NF7YLHUo+HwwzGC9dcojbc//GPCID3FUdyY2SawC9l/+Bd+Nw7KoX5KJ5Mdc9uyX1yXCjJgDdPHE 0KcIopojqScXsjlg/FCMGx7VzGwiMPTjIdk16gGdBEwoL+XiH5XZGLrbpsNlwVSnt8/Q+XZSs5rm djXXpKTmsGgHY0Wq2zKorMy0JlxlV/0SWymKOLe+uC8744WHl0j54uLeUdefHzL3s4xbyVXzOCKN ZvepxAeKRqnfj1IcaF+X+YRvcgOWyIjbxPl0c3o+tTBHjTqkq3quPs3ixIq+a8Skwg6F2gbfNcI5 tDFRikp1MoFXPZus4c+nobQU71+2leMPLjgPH6KWMsKrWyRsdTK4742Wm+RWuU9PP7Hrdkxy4dd8 sj/ZT2rr11lPYpgipP0CnF4+Xw96nDMXciQexwdn2293WhrCvJIGXwtFEO4nRTdswK5zch0vUcUA vbdcIN450dAiS0llBwArx/KoIm3hwME8K2rCs9J+7GVj8M0BqJ1SSzfFtwJNghV1BQcSHrmbIJX2 wB/AmU2HASzx0Dv4q+mj4RtQ8I4hb+MDNYP4DnFSgXx3PHm91i1+cxxHsEax4ZUMHA0xTO/e+lNd Yej7IRcu66Jthrxn1K8aqCoFsq2zGki63cjj9f1elrYxmt77IPTZ0fZTuqBiaeoszNzelaPm5r9V Uv94LYwmE6YiSMbjoNyxSkAX29umWAVSbO4Fhd0+3WOdN2pUu2V8L2Gb42bsIVI7jQYezzICEZlj xq1Isl9UeckvScbo+TKPxQUtqN/UZVQQkv9asp9jlk6qNJKIx+GxIMiqUH8XaGLk7OQqg4GhVWn5 Oe3BCxG38pzz9qia3viakq3eF2R6ldO8OkKlbCiol0qmriduI1BWwsIpYrL0x+RC7apgncdP3gmY nDx1kxewqg7xZr7hvDdfmUtUtfLw/wTXUFEePH6feJreFu4/i1Yl2ZjfkoCU8Umu0VoRpfE/QPIY y0ZSjPaZHYqXPpXTrCr+aoQxpgLe9ZQfYZqE8JJ/B/aPdpUPFGw+lY1wta5t0gOumkTOQrGHqEYq LljwuDuSrWxv60dpeD/9bv3OetLUaVFCqF/dqCinKIBUeHjtUPpjxJKhorD5aQ8ennZg8tjSLsTF IIXTlPGxRSBYgSmM91a64D2nnXlXR3RXFlIo4glnGXuzbJDIAySycRupTltwlUnwg8QGXv18DyVT UfdZWRk3gx9ku3xYFHJ5+ax5Lu0TjwmL7sH9IE/2x5AL1GMykfNZ5CJdhbJJWMRtwZKuVr4qfamF 6gKh6CKSq9w8F7fazXQV8890Kl+jRupt0Tgeg9TYZdKvCk1ePk3eZi9srBZwmpCFR5BsTBgCihHy EixGLpIzs8ciwUrzYpT2QEKovA6dFbBHnIfloZjsA3znVmfLICYwQtPSZe0dAvW3G01wRtL0MpYX 0tlCsGrJQW+PBDF0LmtPrJbEGSns6eZwGoiu8+bCBFIQPTXNq2HUY9MHERMBedwMvrh3Kr6x65K+ F/pGjCyGzsSOGPdERrBm069v76/E90VBtWuuUIirxLob2druroDzgs9Kc6H4DhqJNW8y0yEM5sqD 4koufTR7dnglXZEwiUw/ATHk1TYjUaXSwL8hKmbusWSfkC9vYauOaMCbbVJU6Z2UMUcEtpw4khCp TVcO4uMsukWBzcuOOC/ACG4WOdHClC7gsqhPeSaTukezwRlwR0ngKufnDpnCaxO4fB4hQ3U+DmRk djsXj/PHrkqib4Qpn811O8ZKwCT7R6BEQkRMj1szhu2t2+4lYUWM14zO9AsMYmq5BNbETmyoLuBt OxUZPKz8eW+/4gMjdZ08Ak2NpqxH7ANDTija+iVhLSwlM5pgHP60WxCEK+gu8rfjGs7K5CyTOOwu VVlwWDS/zOdHhVg4kzKkghDPSA6G9DCar9A3bwk8Qh9VaFGU7ftZp3I14HbDBj34oWr7R8jFSWe3 TZSn5vWFX38rIZ+O4MDFEJ51momzvgJg9czGN3yQrwRU/dQn5OzcLrwrB0S883FHu26gSMRDLZwW EF0Nz4rJQ9pW0DqgrPA8N6oq7So7MJzOJ0FzZ+6M8LfulOIsNi1NGI7IPVJ6z4fY6OrGUCjtqufV kPTNyJqHnA5OLXSFi/g1+M812KWR+PSL0QCfkq8e2NYUOqW3QcWTxtgrRxzIamZ7J/ZFyT1r4kNT JhBCKm4tAfl7gH7NSwPaNsPwx2UGBUtX5+fr34ICBdI/8fAjkUBZH8hEfsFzzsXWrvLeR1JilZIp PkgGfDyVaFE/0dk5Efgd3GXfKP1Wum1HbCvH1jA7x/0oiTYSc3yZkawi8FHwF0yL6dlfD00O509V Z03WsMv+jrloRMxD7eMfnAoTaZyLN1h9LP3o9Wyxdp+XlY1ayPoRwdwduIfFGjBIYZ0jSVpYv4Pz ceBj3YiZ4HYritjcx7229Y2Ix9pgNIDEw02RpYYEt7Qsc4ZUHxy0wUjNINw2LO89lFNd8bNmJ2qq eZKxlp9RVB52U5aMYLY/A4MdnUs1+3DNsQyKIolLnBW/+CUbxyXSMazYe0r3Xmrb/gCDsdeIGw8S a00vAuPPh2lKD0RDXM3k79MRPxjKWSzuraRjl+wrFbldfQDWccQIdEFalJG8ADEzAQvs+U4Klyqj wa3r8m2XULW6OTPDqgpl67MqiPXLSKsS1F50oyTTAPpRcRIA7V0Kfg+GHCOPZiRzxr65uLlhn92o 1ACboi+ouqYu0hW5YzrRg44WidvgAtljswUc5Ux1EgDM1sPsGT9Ac606AgzLPeMkmHWiodvKPcru vEK2XIZX5qrUmUr1vSRYKqiDcY7itHjgsONsZRIhBr++17ox/+Rj5UtStEDsNKM+Pgxtlg2U/BZL xkvNWJQroUbtPtM9fw+GZXkvHv3PWiZtfZLe5zHrQ14GxRvPw7HIcGHo9pPg0hMcyHldkc4DLdXt /Sq6xcVORsW0BZflShzKWcokFPfXJwiL9X6O+khEk0NhyDVOSkW0xxPstibZpEQmYB3WVTKhjDuO k3zv9KI1SNOelm3HMuNv/08e5uavtdvw6C17QzaZWqLYRn/UsbUVaFJXSWYr/qTungc5KPq6gXjA xg2HtxCt9Uzb6thQ3TIZZ3udTA1sADevRXuugR3husmCdoqFV9DKvYLTHGJQc3WBtbq7FvNlz68X xbdHOuwnu843Pe77FEKWbt+WsSIcSR0K/sFA5B3TK9O9ywnJ+Ajb9uG1dVSTNnhnS7pXc5+O0ehD Xgqwq9WDl1MgO8rrgfiS2Ci4wCjas4CABM9rTGzBjvPH9x8Nb9ZAa2RWT8t5GMQzNMkr6ukOI3Nv jyCyYJGN2Cu6nYICCuQgj/m3lOyxc+UjHljlbeb9oy5sy4BMnuofSOdxEwBgCTdLk4/6+SyaWBQL Qx0rkrwK11N1ioWliOIgrxV1oOlTYay6k0TZWhfYzZjrrTX+Vt2QuU8I0FB9inGwSxQLAj1p3XOi ovzAZr1d5jjs1BloDdxfNBLxWKyW9bKtEdE5KVTA256YAxQ+iy/XoyHwcGsUig+LL9MVkwj9unN1 41qwoCwsh5qKRQHWPacSmiPDrTmMCzTPFoAt3+VlzGv4lZHrE5J54cjUvVs9ZwMqibq/E3lTEWkw 3bo8Gu2VhM6qHzdQA6A129m2NfFvCFjb2lzqiI3KKRUDk6vPo35V9E2h/bUFaddop4K3cLSm++wV MPO5Hg6Ya14qwrncBFC/o8wbcGdfsxatvK2sVK0ZxACdXdGVqlXfl1VzylbuMxLK28rPG4x1YuIr 07Y79q1cva3tjQIHIPOeNGNiv4EUG6ejLhKtY0xp/XKxNPn8lt5uwhyiitkCtfZxJ4Fw2xH/RWnr ZeDTPpdrajYTTQ2pImAEsNfJ353ePdUnby4j9a0EJnS3q0mtCyHpGZq2PPal/NbVY+5jD4+uLQm9 qvJrqR2k8jqb0OXyRj/XXhXQ0g0tX//rzLTQv3kfytnKBwehykSPmf/Tu5Tut/vS8kyTQTrvwp0M mNH8Av911hk0fYXqiktW2nOHXZsy70rpgdtj94nTbkhGj4VTtoTAqTma9TIo5qpU0/FPSH9AYuUZ NJR2G4zqI5hbiQTLXPWTA99lxUbeF8VlA7HP4oivrGVGnQuq70nJU2ROj4JyCFVyBqHMDUqO44zQ BcXfoDHwqXhv6vvO8Yl7/vi9Z4BGkHIKO+XHD31RZsQ1joQYjCf0lDcJe4Vryv5UR8vlaV0YeTOy Vshi5cK0WtrSIPEWu2BfC0hCzTmgIEM+VNXvaYpB9VWc+5bWHfobtJ+lSBxhHmsvIXyl/exH49Jj sC3rLbrBBIC588/LPKH/ydfOVkHLSmiBs+PsMWuErLPYT+jK9ViUujJyn5E0sZIqAUUPdVL/siYQ eNVY/YK1U46e1RU1FKQTt+mYYlzaegoJMcvyC+++GzRZy+gsFk9VnxhNMFm8NsddjbVIobUkz03f dC5hpNJkZhK2NIeM1CqsgKa0csMu20tGcRd3IlEvLQWIXRq96JNyPGGKshrR7S0vs9QBmX0WP1VX bjTOA1LT2UYzSfupSGWdi6ffIwiWNTOclxl0mC9+ZuDcYrr8fvN19uZTKqpun0DDQjHBbLbMRDr1 1tq/F3X6UYme3Yxh3tYoPOOhDSRbVfqtdXXoxCkig4W72W7ohRfG0eo52xmHUXGcJr44uD55lSpp 2+FctJ+CFt7YiEm+8gu044kxyHr2EEbs/Qy2vMoyg60zMNLAjF5/sXIF+zUb9kTt7iKIzdIedJvS +M7SErkfphnykPkxxCJ97bW60d6k7SQca0Hf/qrJtnkqdztaT/Qbx5ZcTS4eBH2BFXRY6ri0olcC D1y5SxpGWT4pL7ODN2sUXt2BXxhV4qdEi06orK1WZ/c0Fha9jWiaxL9DFUhrworSpQolr/NEPdIl vHgI6S1z7aFj0EoabwVftGOZ8LcSEcjgLB0fK84TRytK3h4irG4+03oeaCWFYr8H9zEZEeBmIYzy +hlE5TCFTYBL0zy0c6UJwGJopseiRL4GsloeZLTrZr3i6FZhkbgW09zReMMoWVkxejllRvGwxz5P U6H3IMnKn9xs8R+mSj9OSg47446n1RVFmrqi3jhgTxiexdlYT6cO3E7EXppP1kM1p09/b58WSAx2 t3dSH2SMEDv0Zmhq7qYJXwWX1liXKhpqzmDF0aawQpZcV2w1j4QEUkThdHxBbdDFlIgyjgYMFWrF nJwqjp/gW5uj0uyw52qjjZYosIIW70c6nokrsfArAdE5DnDBEXo858G3qKMhiU/epbseePxv4OP+ mgtR6yzLwKmrO0eRH+fXaHe5yBNl0o7oquTn0ba2Ky5o9EfQUTXcQnBetwHpgjNNVZdIUGG0wwd4 dZu3/auqp0IU2JPYdcK/r6zOEQv4orOQrYtP71vudc/qzNjF10iYaKovsi+l4YqU5XbBVcPBlJUV qoxy1INZvp9mpq8XzNVuC5pIUQ29GN+du+35tNnU9RTMU3cWA9kOLp3n2zemgi1+eE2ZOt+ZvOly yO8ldqHhOOsTPnnpZDaNGyGmxXfp/GaxnyFMMDHnmNO5tL++f7hPNxBQQ2crx1BgF8xjULsXTvqC HBRs4ls3KSCx9f0cvCy+cxZN6/YpMVdvppHNvzJujPerGwJxcxTJ+mIK5FfDzjLQH9rAydeVMyM3 lp77wwSsvL9SdhF6zsLOv+jXeAUkZy3tVVDmq+tSrzGOc6Bg7qkkinK8f/lxddPXECnNXvWzqHMl mXLJSr1by34H26JpR+FyuuS3p2VCxlXvt0sIUF5+nW4OVyISVkAed8n64gMIb2itw+VuYLw7xz/D RmLewG4w10/LULB9keKjl8cfudEOk7ZrhBi9iZiDephuN3Adc9HDXZMLXuYdrIM7iUXTuT0ZSy7a 26JR1SuQDjHRypoN59cDfvt0o/fzBj10kXbrO6jIu0vgkXaktLD6+IYYfL0qi7+9Gl0g2+he2MOJ L7ukUO78eyC6AY4/bfQENihFqmt2CsMXWNAZGnsjmAzAROkj7wvrPfgGoGvLl+1LyhfaFO9BOJvA IrUm9u6BqKNDb7Pq5xUMsaqOzccZL2ssK/kjulP+F2RJXQ4fh5cLnEQwarNW+jegtq+BENkTSGrW geC37mZH7q21B5RJEzr9KbXDqP29YDjBeGLR3w6BLUv2bW0a7x9gCdWb7stSZmMhbKLg8n7I1ySL hzBy+cU36aOJhF6A5Pu8DBo5TkCT9lSgg6+r8fXb6qj8ReM2JX9dWOmV7TaAlMV2JdrNoXVGT965 /AoQoYqNeNgLH5mx33BFo30zczzyq4FJlXRj5g8ZPAFfYu7dasPRC046EekCsXo5JDOl47TuT6rw 3cbA+hQN7wkmtVPUWb75W09mmx1fD/2A4/4gWW797VaYZ1uM3MDmyeXwagx4fLyg2lId6wM4AKOz eTH+sFI+PjFSjdfkZBD5ictmDlRBtdd2q9q4VwFet7qTBNz+4/N33vbfsc5fYQu3LvztcPxvh9PJ pBcwQvX83tttGWlfv3QGUBa4cSwfrPaIYLJIcWQ/cxiaZyyIXWMZ6t5Kaos1OM6tNRkJ1wnf5bAF 6fmYZ5xJykFz1jQPwtfBj6N4e/6wBJl0VVjMGv0JiokR2Wp1dsovfmTGWXuVeNw6xRaTHHln7ll/ 3fXayv6B3CqDeYrpG1Z8h7+lFg7RQqsBxQNvaUHv+GV10XA7DIHa8jiorAj+Cy88BvfZIhqkzeED 72D9Dyuz9eVS2lKK/uWIuLVSEsdAUpnq+eVH87HGXJ5HRiVxxWKWqIBo/pZo5WonW/kzIWwp5VYb 5KB18C6A0CrGRAVXA/KY0VGVy5zrXjAXfNzFACx7DfCd08a23wKsqSg1+Lb+0fLoqwdhU3gYLV4x LZFGsR+RyZZmhL2ZagKZZdchTnMLhcbiiViRr8uhgzdqhUs3aw2N9EFfLZlklOmUZmWX9NGD6K8a eUMaf1SQn8R2eWmisbFQhNc7AI0K+dTcqbv+bbyw1mU1bWi7opZZ7DPTyeff0unozgWRL1kPC5sN IHvRxhQ2OTRi2q/Rf+Z1sR+mnQs6GgzlIMNby+OPhf1TMv7cgjjc33oUysZqLmyI/nCBb9nNn/pe dZXPYt+2LPuhLEF03jx6FFhSnDoajIsu3J4KwHkPW9lHXij0KshChze91oIfzLbNKN9w+xBWRwtZ JT56e/cIOJOBVEcbdbfiy7dUzm1c250KtxLm51SuTTFSjwspVPoHqFdBNhagXi7UhVqmJVitNrXR RYnoxHZUuGumTwYuU5Rbq1qe5o2YetXZ60OcXJ47xPPQ5po0DmsN2ETO8vH1Gu5hQ1Zi0HArs8E0 4ue7gk8phkAzeF2Fe6Hk2A5N7twGIXYYXo3XsR7qkeugu8pahCywwiF8QNJsm+YuIQ6gxME8cE1a RZCPIqe6/MZSGDw2DW+tY7iYGSo/eYLvE3bGpf/Vb4djFrgXXb2ztZUlS0qrinwzq8qQXb93jKar RWfE4frB0xhFth7zYKyKvCUw4RF3zy7OAc8Y4/TnAeftVXMGI0ksbAKz39vd5eOzVaf5ie6n+UCX 7+fjs4G2f2fBGuyyRbQeRijW4IULCrQ4Q1xubV52JgfKxrYNSPLPpa0SmKzSq2W1qMfglDH86hTq 4DhWuQTrGj9sT7KC2rwwKexYtfJNbDskjZW3+UNtNJOqOQ7WB2oztM64d6aeXa1sKb6ZZ85r1Chi 9erIsQ44jikXPJbN4ZiYBrYP5Uc584C5bgsQBys7X4tGyx6hsREcJKkVMmst0k4QCG5kAEadVsNW G0UCahn6Id/3wUUujpMsy4h+w2JGtMlvesFDC1EMUqwMcnvhm2Q2IDF9JO1gnBURLTjl0XhpUb2k TRrp6rwhiRPqTUAG4ulaokEICxY38j9rFbBwdiAxI9pDKs2ypcgfl8Px7k7wE1cr/Lqo0Eertb4M nOxH/EjpUsGXwizssbbAWEzU5CKLOxsUTmS7zxIOfGspTIn5J8No8U0sSjtev4NUpy0TvU+xEt1G sf2J6Pm744VeQgIa2ROeNOkmrpCflsmvdjwFP1oe9QVtyMmoVgkZWtR2QlCSLbjFEc+MnVEWy9n2 nyGFhmTU6YGUo6D9Li/2VtPG9No+MsJPk9iAwFtF8iJIOvL3MJGeDgXasiukyKtPXWULWB6qXaWT nmuG8QerdTdJ7ISgdNWqi8xRgJvgI4nSDbvIW5WiMZOrD+Qm6msqB8pqi6AcHUFnpJYMQOBIUJ1t HMnLaWfjq067yVu1jPhEC3HQO6wDSVfRC3PXT6dgKWMRviY7bSRJRGJraHXMY0qs4cUMWIaQwXKV G52ouU2ZB8prdOoxkbR0QhyaskvE22nkd8Jwph4RxhCJrCScceIF3/K2bPMFUlrLEJL7IUMfa4Dy hatjsRptxvooHQ20YIqORZ5R5g0fDbdkVZyjqCHK4ONPcJ7kd3DaApFKcOrvRf9gfIyQihSrUXBG YLaz5VfSq7xvquOiZO50f5Mm9480x747Zsb5yz4Kg3WliOtooFDZgxdS0XHsRCntUc1GpewQs7EL XIttaUe3R4/187OQ3zZfw693sRc0h9BNfH0DfUQR1wuKXo8Y+i4rxL2rrm7ojGlX/60qwEdO4y8W qapuFyOO6y5v2/pM1AidxZlTgJxhzIN+j4aFJSNF9cF0ksxGCN5NmY5zihFQPDadv8ZDrtOsoBvf QB1MZLIuudgM3A3D2whH5Hg6L9GFvH0+6CA8sTx+OhHNWFmmTi7REBE8wDc26+iKa7L+dxSdBYNp CB4sPh2YATJlcj3ZF6kk7ZT9/z/W/jI4rqDZFkRtiy1mZmZmtixmZrWYmVmWZDFZzMzMzMzMzIwt Zo3s75145747P87Mu3+6I3pH1a6qXLlyZXZEVuKxWdZKxA83yTxRsgVfvUYiizXoW5E907VElKGm X8YGjKCKRejZik799gLRtZwQRQU819dyI4fg7Zvf2tM/D1DOkIrTsiSZwT0yq+Ikz7EETlwnrt8a T6IWNPLYd4XPRWA/6uxnetmmyBZGuIzFXvCtwTy97e/Np/EjQ9475WiC4fhE+fn7UwrXGQf/MvJz o20GIgj/fro2xrhuRBp42Y5zRXbPG9gG7JRBS9AtVbTaBhIunPwBbF8ht99jyTjrbB1xyDuQZVXk ubN32xjSsm5HNG6zwwsktvVvGQ83N2x5W8hCnIzxUbYl6KKIjhP+08Xui+Vs98uqnZLdSuzp0PWF AGrtQPh5PdBIASMJX5zkbPNuOwp7eInCk3FGYxn3aGSh9/K0+DCrs8MLEi/NqYzo4ABQjvl+byNG 3T/uSNZBFIDoiI2TUqfe9GWJhrEEhjTtDT3Bb/vVXFsCUVc76IP9dJeCx8+3fxZXn38YVBSiFfXH qzb2aRcrtEvhimwJ7LrK+5CL5uIPO2h5isKP7C+gKF+sEmQkKtMLUFaADkCerkWG2IsVshOCpHeJ GaSMy2lH7tR4uCFdBKGr9BTxGdKVIK1yXaQmtYonwTNeseXpSqg6bafLXGVH7yiMuiBYJ86UQLBW 85CQuw6/76AR2E+XPMKllDKsBsKssdIfv88xeXv4SRL3Dx+OhF3zabbqnXM9LaOg4Ur059/0h/cS 2/wAx/NHLSYInC1Es47c3xk+CpWkjay2U9YV5cieCEBztJ5yhX1LMmxD5Ijjlx/BPQY3QbeXWupN nZlP3KMcdDeXz/cV1QOzdCbO4ohZW/6T/Z55RSUeQ8vp+8LVD7CQR7uxhVsXMCrYUKpw8vLl7rti 0lxx9Jl0d0UA5ehCt9+fuPrmECJvujfCvRvjv7UvFhDySlXCJmRyTrb2XFAo2bk62vBVWJq7UvQK nRpCuF84I3y0uG8BgXV9Gqsm5CNrTsMMXczk9qEs6r7m00HJU5b3uL7lHETkyijOpF6b0s86VjjU NVSS7TdctWm5daW11kQeey63eeYstgHJBOgVNlCwmq8nXOuSMl61p4nIHL5VVphLJi7bh9IljQ7n jlsS26s5p+qfGhMzjI1n60y4jOQfetWLtpsZWFOFK631derHWI0f5jh0tFqKCbK3hDnnYNspHvkv sA/szz1a6xSo2dTLzuuVBhZRKfZgidSSJRzP3j2ZpUOsE7LebvMc6aW1i3A1D6xOw3fOYcVSxbAz JoblR+RrmKwY2u/X1R5QBFmBhGLZiWTmYfDE5EbawWhOWY8YaEaQjfsPp7n9MNFgeY+Gpmdbj2cR 5aTBZkBJW7HcOAmXD4fo3Zp6J3DMNJ4jsSo3jfLyGv9dgq42b8o0UcNOdMac1Ys+UvjiuPQz96jK 1xsqQNqQQj33T4cWfY/HVgmdXVJ8C+xX1/JsKqjqOgULI9mvg231EV2MDRPQoSZ09aiPwImmNHM1 KCquIUkvGqklLrM59Z2v1SLoLp+bNhMKhWIvGS/g2lyw7hcO1fM/FW7y1Ggc2xfKa7H5YoXHsGLH Fr0i8cw3T3ZReWYObZ+MIafn9tPwJTythPn5uq+tVop8p0l0/Ti2Et5b4enPTIlPF8b3t3J38qLQ ASmmPlYapS43vgejn3BkhvZG+khC6enEFmCd8hXLxFVOyvG1i1gHVHeNBqi/NX0YPMALgE0HdbOB KGV1HOLy2O2hEKINIUcFPCmgXG7Tu4CTlyzs5dxeF1+RkDx2tB2e0TsmIog3MTS4NlX9BQ7R5/cu 1zKiAHaDMgYKolc83MBO+uxFi4aXr41QmK5wQqieIBaphOUDrle0USULbExKTySWId3jbcJ6bC6O HRJgUovGHil/fgX9kGSFK8t3ZvrZkJh65dpipqywnJarbXd2UKb6Oyx9MvPi/J7pGwR/6MIPahft cEMZRM56foxE1WtjRH50V2VGOVaxx8p3pz8gxFUSXNs8g8ujkDhazfYk/Xlp97FEcuJ44aOlB+7+ 3Z3qQmJs1Cx1Hps0mk6krWQfo8E4jtDnyhxSOKfDiEWBn8yjspWCUtehAwFzfzbP9RtWKRoZ23FK b04JLSlJLtpLJS0jwIXOM0T9jr6I8s50ZSGpGmNC6uO6HUPnk3QasnZlPUL6+qc4Y07WsPex4FNY TZmczxK+z+fZ/ZkYY+CkWy2zfXZM+vNrsUvye6/ugS61Izg+Kl3PvvwBXGLxnTs1VzSNTLXNU0ra bRzw+5zZLReRv0aaCjKi/S5KdHQnVKJifEuaMr5OE/qTwSHrbgy9nk24B3/YEROhv9O0eKDhODce znTGdYGWDGmHz8yIj9kWeCUYEA2DAp3vKLpaJ3fdTOi78WtSni5svpucmHg7Ml3md5f1YCeZngV1 sF4miqs6Q/UNyNHlM3pi+zHtFofzMJh2O1A6XPgRA0i8NvGoNuMtZwjGBV+2c4mM7nzieG6lVUic tIbSfOlijz2W75mHeOGiBavj5rvCVq3UCfkhQucs5EHD423+9Z+0gxhXy3kA6WSBg4NqsYe9bx8G IvZtUysW7cTtyomZVK6Et+aXV2mubCEipxq33ABnUUlIb4sDCdyvT6MoLk6D4Lh2bY8E2Wm9mzMp luFILpfUrnFFdOkV+y2Q4MQ+jf1kihx6+hB0KzIBosEAPx0SVmNnAZEIuRGhQLJEhth+KVy28LEl iFdkm71FsehROYOMWQqexcK3u2FUqISlv+KBOyJB6Vh/uUHpWMHdHub7gb+9FdOsS3bkuXm3rouv 5rpCjnmyfnUERNqaRH5S0zhqqf/jIX3ZlxP7+cG+UPNeXsUJ3eqncee4kjBql7jVNgg4VyszmKxy Gnh7xkXhe3pYqQOToUAMy6AinK/6kAvm1LssXH9coNoHhN/cuV27GTZswPgLYgTqIebO9insMWNI WQYC9rHVEVFAQ34TY7x7Yp4RoV3XWC8FoTGLP13ib0gdnQVhpKgkaXI5bgS4nTAVSBa28gM+EqiH iz98VURexACmpkQugyfmbAMRfXMV0dtSce2D532KT/NiUGd4LQVXEBwt0rhYl348jsszuaPrmZU+ GqF9werSPpMgnApT43sCezEkGTIrWJxeM77p0p33z1r0NAZ+7n7OZD42y9uVQoTHiPDs1PiSYmMx W6L5zapBJ2NSntcqKJIbrBmKRrqzh3IXjplpZ0XBud/9uSdjXwm4QyCMNmqHP+zk+OGfD2VWcVyQ JHtkyYA/i3xZuV4NYjAXEGF8OnBOXH8tBhFO3JEMdG7ria9Xt6gNMGlNmaIfZFtLBsmYJPcoiIp+ N0HlzbsaW2dkBvs9Y4ozbNcG+gdBmc+0INepAgW8StNw0NaBbhRMvJVg0lHx2YEzDEKPJRS2Mp/j lVf3z5E5hCru2VA55ytAlTXXJsOxAB7sIHoxtsbegT6nWHnva0Q1paDQhhmrcN0K23fN2G26Y7CA usvWNe6mK3ifg4u7oyek7OUu7RE2A+b+w5hTJFn6ISq8EIiZO/eklBt6yJC6dzz/Bqmsr0pKFDkX Gs+08whRpQwJ/PjyuwTVHf1v9wD2GULnOJtEJtwciIV27JBaDU9QfgCvPieR57c4db0ASCVCTGXS M2QE/tP3qqCKS2f/vOM5/yHcSJmUX9+FsblaUv2Ah6GHUS6ix2gjubLr0D+o8MmrebqPSpK/G7Nu h+jGxDX9As/fQYC2MmPwJ/ASkDaZquucrxNKbIr+3h6YD5PBl0q+B9YnjesG6X3LZ8fVJrjwQWWg YnSWTLnhOPEB6vhd/LSXTlvi9xY43kDmurwc1R+/LlA8lRi1P3LgZaGw8igU1J5rBjtNIlTj90lt Imp3j1MltE+UIAndLmIqj5qZLGsQEIvz7KUXTZ02XkrIB8979RoWu0NPR3Uf/ll6qcugvtiZvSPS Fogo0i5IloXVELRpzdPrEJ55W7tD8i3kJ/LPHAryXKgI70ROv67YoKVbSWlWOQt30nYO2/C8373h nJe7N8Rze9AE53JkmY0AW2bBCl/Dx8F3otl0zN03xCpGvYR0FZDUcZkik4Y5pmDC4IggyLXc+UGE Za9Nyy029iIQIiL4qfuuPAdV1oURiO7F3OKjLc8gZFYEzme8HuHJPmAlONh/s9b320oCJ9kCh3BM 4o0BDzET/FHumNhaa10vplj0gw2bK2VAyW56M1qWXkYeVjZubn44Zi3yVcVqjylmBpBkk0N8kw4a WDr9La+L/dn7JTLwtunXAanpOmMAtug4wCs3tFWSdMJOdzzmtJg6aqKkUWJW+RolVYoOJ1ZP2bP7 zteEeTtNamNGtu3EKH3xRgfJZmUxxIB3XUyns1HTQy8ekWR3AVGooftiI5nnTtPBCDxl2awmAGwa e2UHYMKy+qj7SKLj9HF1aHMuRU+uI6nHuXmkYuVU8Mdx7KWYn6vRL/dZh+BhSQAmVN067lt6+9x8 xF4qw+SQWAfss1/+vG4jW0n5kIzpJckDVCHbRaUORN0d4mmE50q5cDl1GWQ6WeXHbt8F5spZslBp IibecMq7Llyg505e+d7Vx/sfZm6/GKcDvZuQvlxMPvgV9QffImd9uJfu0l+KIxBRacbpHyEHHUud 78CGgOCkI1vt1HfZEUhiu9KQ2J/hMb/sBZzKxY9bpb0v/MHt5X2SZyF1M1uXTa4DjDKf7hoW2Wg6 w3ucJDTF+m2tQON/u6agdJ6/shYptUuWKlZOYNx+XzPUa47GYSOXy3OE/90MN15Pbt7yUbeCarc9 5qj9+9QGAesFaHWg5pX7UaND22qFI3g1UbmUaypwPXHGU+lsCQEeE+YKbW8LKiFPFAI+3DW8WVja YuKSwBaD8+0rirkH3jrvW5Fx/lf9UiK9bN+cZTCxvGV784OeHqBIxc/cJ7YRCtD1ldDte6Q7OOKI +95BvVlMRNakthY63SdShQQwpXHIDn2B9paftdbIz++pqm/K+WWVEnZNP2+Ui8sqR3rBkuglqrX7 rH/SS6vIDYqdCRItFP2RgaoJAu5lRoOMkM64xEQUKCgtowRKoiCUyIUqErdFxfVL7m8jod4quGHO 6siMFABKNfsQo0P2IJEIKry+pCmlnfg1JceZLk9UdJ0XVT/7YkMyYcQTrnpJukhJwd0YbptCaFm9 6qGECMsjW38vcKjOM0clPOaUoMaBUCx7KM9j4S3V3h/KqCKtL8G6g8wfpzMvUKHl4unJNtDo46dX DmwuDGCkciyXSWxYk7k66Shr/87dJqKQ0lhGSB1GA4jgt/K8zZhjydXqeYIdrSbWaBbNliCK4r0q obvtXqOMPR5CIn6e+5LrK974btc5WP4bWR5UeVhpLqoA/ZEFplh90gmSSDcqp2lLQUDWF3oxEQo+ opYXug4mXwHpl1P77dEXnuWf2Z7Iag/sOHeUCWj7uFFDdOYYXQbXBctRpuKyzAOKMzSasvBZRVAO cVSTbyRtWVrI1UzjXDmUtE0cTWgcMgXNee4JVGX2Zh3DyKUHMyck9tmy5s9DP7YwpPG5O6OZydPa e5KHh4zZDsl2x5z3lzgct8NDRTOO2npmaJMeuBHIXGd0JLjifwwGpf+Bq83FBNHjhGZEYv3l6HXZ UX/Z2WB0vlr4sdl4QNHNWOZ1SCZNUOgPU2WC2tUG3dyYNrED199WzSBQawxuaz2dW1GOXAJdpU5Q 30W/NIqdT7fURfLN7q691/OmYttMPRNkv37FLnpqo6In1I27Llk/iPQUpaQ1lVHHxqVZV2C8TPwk FAdqXiW9uwZ6fPVgJMug75h/f6Wz//6q27VPFb6+IyJ9p5c9IUS6wLHqD4E1cHmmnYj9p/Bg6FfU Ap00J63kfoVE1XkiX0hn+yjj9WHijPZY7vRFY7cpnbW93AjjWk+NUnIrBeKOKnFxi3Y7S/N6Bh55 3ltx5Gfo/YmSePp2Hv88gQnvvUHEtfzYxFTx/uW+/oedEX0wt7w1wjST6j3qEo4+z49o0I5Y7ohB PxMfY7vor9mxp+5A73KySuP1uZ3mIq15AwZH++xQKhmU2grHHcgESbcsHsZ3QpMK1WvukScOg4sA TO30H/HZj84m6BsBXZRxse8u198VRJpPVLoTjDl5cGmuilJ3H5eHcRXZd3mVtBTo7wl+xCmeLcGh M0JD9qnvv5PRNHRHycsePh4w/jrQwVPfI4Qnqyx9Uwi81a4xR8eoH7rRd+IrsVtWVwpaGYWG8+OZ bo4UmlUgn3Kc4xptCf9yejI0VLAntqxcoYeIXSxurqOvxlUzpIwp8cwmUZLHIaVSgJDQ2EPqOBb/ CD4rnMTUDCmobz7t9IPjSrktiWShnZYoTWCbJcDeX6wxB8LPjX3PEc/U9mfMUkePp3UQVYuBvu8q W7GoRl0E7HIx7El8w/Sc+vH3mkpDnEx/74M00kUSOYs3Ad70DAojz8B0VJn4aM+UB7SGEuc6ImbD sz7PZDcH/3RKt+amc9Z6FQ2De9e3exKQdTNb/7bCvsr3jAulq3u0b0+tXq2EhV/XRVIRHsQM0pLY +Zi/oFjIy4GZ6xMc229rEqprSaTRuxIJSVLmtGJIgonjlp+Kc8PAsBxrKBM77iwRzHc3By6/rsVp +E6Tho7btfTl4qwk2lT+CUk8i5g0z+okycf+w0kdrPZVJEtNVffiV6GhIRSG4zemN7eBYYvQWm1+ mkx/5avAWjhtHTJCt8H77lGM4y2GYogZH5OhdZdUTMkbeITGcbyn9dKsUiOZ2BSuMOqjsZrlLc+G bWenVcvQO/fJ5J5Jcf7aGAFi0GzvrA7ngibXQJyBMZxZU8femuVc10kT5GTOUYgTzdZx8MNa2MbS VWPFskXs5mvjRrc3nZPeqtbEIwOdIf5DYswc0ISfMxfqZRvr24ejB4WlLoeAh8Hz+ihV+peb+8P1 wXFWkVQeLckGMcCSF3mYs+bh+rydZiVfe1oG/qTJsl8+hi5p/tTP5uuT8cJZ7yZeHy5+PJ2G1k02 jK8ntrgkDmR0j9tXo7uz3o/vtlxC79bka0A9YiD5Mh71U4RaKJJtxFM23ODbwXs81gE97OjZhDxV MMKXlTuCkQ4fz8fdJqd9c34p9t6ol5vEcuxKuMHNoJvtm+3jq6tF205UD/hBvY/Dwzcg0O3Dnm99 imD68PLrlxz4Fo3/m/5a/+2i6/95f63/+un/21/rv27l+j/YX+t/uRzs/3V/rf/WVIuRkYD5f9qL +v9BV63/dlvYf3XVYuH4PLX/UVMt6djVFsS2U9UtsQ4NO6grIUNlOhvkVdRCrX37uBG9cxBSfdKO fDFevzrnG36H9c0YvC8kguVp/otIYBNfmNd5YSfgSl9kP/bOslTSlC1Ra/7ka1VJ06mRq8qWBp2f vBv0cazylXO8YTG9JvbRwLELolSfQ13iXNm0FvInxruYuyjTLlcre23ZfHSd9nTQjZ366UTV/Nnw uo355XUnjAEp6yzbIXaVfS4jXJv4HnV+CCCJUuAjg/9R4QCRLUbxkftgww/NexyEx01M4jccQ3l8 E/Ewewg1g8Laq3rRvvVwQpKqUy05j6/uEyfFauVhfFhxvuqleUr723IcpLvBZ3YYaeSgHtYiCK7S qSZBolqnxDuIR1ixxsuDCx23Q65NpiT7ovRAl722IMbSJ1fOeDcqg69suXsqbaXG/Tp2rhRB92Wx con84dtBGhRitRF5k/45spdygT6Zq6G/JFeNw1RJ94xENsFLh3nqr7f26WwptTOQ6pSE9LC3Wvqp WO9Qs9IxYsX9FmWJEu6362LXYpleqMxWZw6cSaHJ0LfqmA4MC52adWrqIwEK2dmht5Vli6QDRejm EBkPg/JJ4T+KvyE/hmUOUyR0VMeZW1FCUVvRoNz+1NC3lqg+UOlqUslMj16vXzgg+6zZqU7d01kG DWiXINEy1LfJ+NO6ipEWoEzc22xdOEeN5NCrbaJGuPfoZbTc/45pa3/keWD5mRozsdSSbYUObaw+ P9xe9kpRZyRcE9mFJLdAK/hL2zCI7OI5xxzBUQ6Ud0WU+CWMnujP6TKtlz5SFqXA+kApHMiJSL/q 4EJUk4sZJBP+cfPtItFE21DconUiV4l7FhjrN53vlj85gc28XRVyS7A9M882NWaXAqgq6RP1JFop cW/VR8lYE4cNQqdLyFaNcu2t60u/T/PodosVvtNTsaVpguzmnFIBbONE+/BcK1qXxYdHtrVUPQS+ DXlaa2g4FC+yUxGO+huHcu4HxzJP6Zyb9wgrfkvEZMgt+RADlzjto9h6xrL8gaHLEmjxO+ePXNzA GT585R8YWnQ6X0fWeqVj6SMUGaXvbODbdlh+SsFIY1Tx6vHfbwLI3AncVjEdq2NpUFLM1GxAa6r6 CkVHM/5o0N7JunRhO97YHXVYnGrEHLEaCdsIINEhNREzGgI0HSHjKannXeatCUQmntkpXShoaAXp yFrhWAPgRjRO8eA5vuL6LAuyKcy6w41bmv6CpwbXNjkJ+f2F9rm6YNymgMUitmA2mGCaD22827xB pTh3jZ+6ri9BGJpIHm5mARC9Wc5STlqFTHlrTHXTIW4C/0s2/8zIZQZnvmoQq5CpuDtHJkVRpsqu iDDni/1ixqSSr7yOGEIXjyhCzlorseCSuNIPoVs/CmHVH9Ba1gcJabNPbEonGY7scE2RYvDWRxXx v3ZAl9LylWFMgbAHiVYGavpMBB36m7ySPZAkOFAP6+wxRU9b7sHUKgHOPz0FgtTZ//A9MULlQLY3 4A1KC8psQ1dbqmj1ssF0Rgul84yaSQSzBNeEC+vry2Npc4bp/DBiEENVzkQYMEYBixUT+TPu6vhV wuU+PYIB9z7NFyoN1ZntxHxipL2OZIWCQ058AA+tM/RrNq6XcFx4h/7O0zOupMgy05eO2XEhJ0WC InMIJ2nzEm7EVFr1/FtQ369NLAbguGsrEGcVuk4euuaAuZmtEHDerQWhQgvNZe1p9UmiZez4xZ8R hJ0G2iZmoPspSAwQzbok7Znx3flGVUYSTC0Cg+VrcnIxoYAmCdL87bIFzMMusZ9zyUgk9Dxz0cxW 2sxoJvIIUGjC02c6YK9Xe+mL2Cdnlk67PHP0wWvVrYvcIOn3tgYxfelwVI4TrJugRJHoK+WFfg9G QXYqei1LyU81A7eY0iTcjv1PkHQbDL1ojsQyP8KQuX9OXZ1MKdm85ByfqgbLbp4SyV55pOKUX12I +Ce586MrPqbYY3VF8oJYtibY6oeWFe7FFtxkGKIGbSlBIH4DNVFDUb0emPL0y1I5NTvAwDJQIcrK +uXC/lTo89u1DvxZ0j8GcO7ThjBXg28D+ofmWLSY96vjDcVxyJQMO5itjnpYgArjsbhNrE4yNaK6 A2mxxK4uwaJU9I58s4UrRflK0phojHIvOP8NnJC2KfRhxi/ZSNu46Bqq1A+FCA+MeJM2UeJY9ysJ ZU6Bva2Ed1aubxYgU6EuXl44xcDvJxZWTSV8EYGda1vSaaB2PT/rks0QRFI/elNBrXX90YkeAkoX PB/qlQm5FpU3cxk0iJqD1AkHXw6xXKIw7vvmL1xpPHyia5oDEE+ei5rNjtb2QS/sO2OHndag6Cx6 fpaV10kLT8+C5EC431eazAgzjGpxhKiyaEgDu7pdVNOBVEZp9rKPzBfKUxEmGzurHIgoLw5FDAwm hvTtE63f9eGNrAbjYp4Nn5GdEhVd0ic2lrHO96qrIMGQGMTRCwjZA7pU5L55xZuteLfISoNosRnq oa4rZd8lvcuVzzyXG6tDRsAPHoLH5o+j1S5xLlxe4Q/BhKko7VnJP2aIRCmLeflBflfC7K6+36zZ fyuLOs8mCDfcQtEbeDvbqGQwQJJWdA1zWL8/MR9bhrLSLN3LBCGMZ+01I+d2Yj0RiWY5Tx/L008I +N6bdhZOTblTgsayC2nMVnOreAk2X3bAHRNDpiMPfzS08/x04b4vXRHYYvvBGKBhk6ki/+cQMUny jonO3YcuaHaZJnSMSG2GpiHs4I3X+ylNlH/snC1/lNZ9UQkDjEt2dcE9KnAEk0WP2eXgJOFgCfpK aLkhJqQ0zg5RdR+vf3KsEn4V1SRIGalWOq4alKg60tVPpSzDO7fQDimlkKcWHr+BI40hKDWfWtwv TghItv9jqp6WwEpRKIAuK6bfsSEyiS1F7AaENTOWeAD/2qhyMSPljDoPiqtwEDrJqB27/UKM8XX5 R1AuD7Ru6C4HDFMr50lCE9KmXJLyLuLCjZGsT/i51aRr5+X70XsNgcs5PlwgRC5U3sCUX9hxPqQ/ KDjo+J4Dc/kW7t25RY2fZ40fs+DGoviLoJf3IvJKxbUS6HZg/y/Z39DfuswPetaGnx5//PwKiWXz o9A/agME9FzIpGW+2qboKqeOSJJADEjWQO9m0VFWMiSMUCijZvXKkdpqLGMOd1Piv+nThzD12LNO Ngnj1oYuRB3GMzfNI8qT9YVLemHt2fC7Ms4UUSMGdrbvGJjVzytHOr+NI41LN5A8yy/Gc0SZYVfn LQfwpshWq0mtl1cFD+bJtDD292akSyagb/5AgrGlAGHBhBr6MyCE5QZVt8wfkgk7L6NCVAhLppdy Hd4/lt49vTxLJJ06sbZxTu9eiAr0U4bSlcMjvRHGFhmgJGIHSTpiYHjRBkjk3+rQFI1f5qV5y6ua 10mhPffdCBReccAEduOYENhjyKbGHGXMO+hiIqkH8iZiNMX1SokuSCJsSMa73i3/lwfMRRG2MQWX sQU4XFf8A6UFg/ZYkBuHqm3MSIQyloMdTEHxAgR9tkIOX2B3rsdytAnf+ebxG1ZlNmiC5mU6nV1I ZZSb07GLAtHqyuXkWve+sVQ02T3Nd1i0/FoHAg5jA0EsteX1xmO+qiSjMO4UTJC4+GIi25XrSXDo LqCiztI0u89joG8iVgajOGhFypDAQoy15OinkKomLdMvY05BE+EidC2E5GWDWVGjzNE1f+ElwOzE nooW24Ec9pbL/XhG4F5emWeWBjDTWbc+OSaVR7y/bNLq5x3gyvdGDvE7/oTFJ/yRMi0bbC0JQjKG dSgwaGkHMg/AMg/D77Iu1byGaQ3g6Bmo2po6qmK9qLqWDCoHEi9tHYVFVul2fwkDQs9qB1nZ+X8O sPwccGGxZaC3tocPPhWMvOa30OQ/Qo9bNxAlsD2sB74OLhelR4JFV9/ke0IPW9cPL/AWSuwMfkdM YZxjKWixJrifCKexK5qVhMaAG5Vl9sUo/xK3rv+A5BCAZRqG73sQj+MC+gYkHjfH5/eqmBqAk9nJ XDfBwhOhdksGLM+yYMIP0QDXHq4XB6N8qGkmuGC4ZTEcKbEZFbelq6Ioad+L7IQhEZEFmUO/tEV8 Ue62Gw17QAmry5m0P6I63PXNPOZR4hoIlw+DixiJm6en9nULv4eAm+xdVT30hRGHKbZml00BCtuV 4Lqp8x7ywtqeD2u+E5hknEp7XxQ+JRbaZPAHrd5AgzOvTCea8MSUXktMZ8BmPApEhUffHkVZ6ujF Ly1MVqpNVEqp+pdbi0+/LScgGNYmeN6+xexJJHCqwnFrDljdR45rdwpWb5KIZ9Dm+OSmbDphBz0/ pSbMsm8Al1orcSgSkF8nPGDsh6hFNbzjBQ3KMjmVZXBWga9bQfZVjjIi7rTbphOBuazwwDzFt7Fj +51HcE8si58g500hX5HL93aRHBbFZqU0FLjmJ1OoyCOsugaN5FmXZOabDDrVYhGuvDEiVMZ3kOoz T0ykE2MHtPeAQrxZmj9ytLMcc1Yta4NTBnCOZOYfpuVk3nd+pd9f8J0IE5CQI68rkCxHmOfWGlHx LieFGM8nDFLdDdxFlIgSJkCsGMwniOf7N4x4aEhsmIvXs5vntxXCetfGJoBfJA5qmZTHxbKJ0CUG raFeJDIvQlgnBGmh0CUiu4jWxAed6VsnIKPT+o4QDyAsj4xV0GM+JFLeeeuo+Y2bxqkrchMlWyK5 1Iw/6ZQZ7i3JnfyRXdmJj/QSEo+EJT30LF18zXbWoAyUrcMcydc+q1RQ2ZFZ5tw8jZ/BwZYw1o/M JuHrMqYcr86+TbO5SzlMknkTWbFiWhMzyCb0KmOHI32Lu7yLSVz6456Ia5kHVycvgoKDLS/1pEPv FsJ9fINUlv+jplsi0IA4mXNzhHXSLrFfsHXJEbFmTE1ZAclF+nNRFSm7jzzd1tHhNAPxhqLIZ5M+ r0+Tb42yjYAMnxKHs3OQwAUpALvf6U4XV5+ElJWPk2uYI0jilweqbuxAgGgZk1MD/GJ7RZtM4F6L dZkid/DdTwLOUVK90iXuA9vOJmJENjAbBLLfiARSsi/aBXi4q2GHOFPH1SHYVbqIJoht57muW/6i 7KK2j9jaYmREu+U6ie6q/oH435zhMrnJExq1COQbQ1+tMp+ds9g34ERHSkFtaHb9nx/NiRtsBok9 vjATGV/S2KNz5lpXOk+91DVK3rpzIAFIBfCREAMffu2LWxU+sLq6euOQIqrmGqi+6FZDUHXKelHh wQmZuzDg+bGjuSXUkszztX9OdtMlj29fZIxw3FwUKbtVLdvvP3OUO/JC6GowLbSuN7nXYHRicXX1 evVURc43WzRmN68xubqRf26ct86zd47QVg0lhz5GWZ3RWm4BQWxBWNnF1Fg6TwKXjG2QWACa8/01 OkBAWqsgnVjcSjz1tgAcZsG3PMtpotZpiat5g3SmKDeC8ryFnPFBUDSNkWOIx5GiGxvwcu9VduoV znTrDrX9k+/RvOx0gC+00Y+Zep0KsH+ZLV2j3VQqPGvdGhnhtF6RyL960J44m2hmZakJXZiqnCnR G2i82nZjXR5mHX3s/pXNh3IdxF2s7ryCp2/uMPVwcvv+1d7BU66NZ/XJDPeAEm95vI110LzB4C3x kFt2siPM6zp1AUO0Gk5vqVKxaVSNV2VzObzWADox2Tz40mlA/wanAsoaqpdVP9zpTcunkXmTUYta ZXmLzcGNiZLZH8zthS13vHrRol/OxriHAGASfmkF7n/MxR0bQEGmZdKgOHZ6+MxHTHQgZBl+6URE POukmTl1tNJ1UI68xnlw5+DVeiCX1sjHaO5ZiYy1bMK2mLalGh0r41iotjB5Z+VHgs0/Vi+265G6 3EJvcWauY9ymWJbAvdAYEmNdPn+g6WrDjLPUyMU8q2e8E9I+4VmYtPg5qudnklYmA2lavBZdnEW8 l7OfYMr+j1CVEhM9eAlq9JGaEW5qJyWZZrlQ5ZmAa3DSOMkDF6O0eBamVi2GZaa3H5ggiqNgzLQO k1L4yap0SQkFIfr6F1359t24o+XM6J17p4G8lJFnz4Cng7XoAu3dvVQut/xFlXSdY9ZDzfYDTraJ 9DqdnSTMgasog95JRpuT+Ezxq/nkKNTAZuxCGd8LvfRMJBdvGTfFSbeIVuZeQX2WibP28PD4TiSX 94l//mzGIncZsYSRGIFeqAy+P2Ibwt1b2FZ82Daw7gH8yad2ue8RLf9lUIRQsWOx9AfHhc4peKX2 PKCEb0FrNieKc3M01XuutDT5gMOV2iNXHt6jVH4xbfE6YbLm5eKe/N3LVcNmcx0HtuhjI+MV0VT/ 4eqnqX3v5NM9q6n3Gt8b8PZcVe3lq8VMza4CRKa625dy1iAtrSqYB7pvs2xGVNGkZsSrN5xDqHo0 06QIXcYtMKQtJDFJHonZPxMNr01m+xOGYs5MZ9i0a3gqjn8kdq23sRSzRNmwvCoVVLTtdX79QsTY vv1/U3HkJPh/XnFkYvj/rTgy/dfFd//nKo5M/8sFfP//Vxz/T1YZmf7bFXz/VWVkYmBiYvqflBkd VUdjdtmQ2k6pbfPaaOG+8jndjlW078IG4eoJn2XzQtRBit9eZZMORa9+HH8s03whEax/nqIVBKWG VlZXB5uYSIXnfx9YVrfhKF0i00ccbdJ90qnSsZJJjQoaD8LXH1jertu+ZdF/FENOuKIJN3A2vZrA 9AnaJfueS2EStEo2pbxYU2IUg9vaoDzou5BbscKMTRd63HBacbbiIuRyZk62ar/RvIr3/qseFx6M +zVWamCiTmz41mFrGWu1gLp0li3MTyL+7OpY1fnEfem5vrTuYkVb/Ti7UqchB3LgK7dOid7L/tXs wRWueh+nHpecV1SiOyfFQroazsXHHqKbfNIsWvigeJOsWlsmfLiq4m485xld7rqkrWvMb55B7+1z dJfCR94/e7C1W+bUP6+sRhU5bkZ+plR/bGUbcxSvXVu61zFPXN5XJb4Q7pCJTPrylG42Er5cNgSD 1Ed8K4j/0bV/RXESUbby1QcL2KJ0CJ3fDS3TUy6dJ0wcWkJK7MWeQb9oB7lMX169vA2YpHO9g/Jc HnjZ4lmoKVQaaxiamHATF8WnnJSwWFa9o1arkSbCkfspCJHYae2GQiFtyUFtZR9RKQQftP0kH28Q VYj1dbSwaGjFYXUAncSsCjaVfGS7lGXhj74GfRvM8raCmXN7UYNF3HYmK+q5FajGSM9diWGUnNnN vVlqaJaIVkhLSTNcpaM7nR8zzAmmwdk2kYIduka0Rm9+DkiahzqVhTMUw+x8czmMlFPcuVyndS0J 5DL8LTgkM0aiEb+SaOgDtgI/xNsSH2butSfZ5vVW2/g3oifotmblfVu9xu8feHK7ImmxQ4E6pNFa h2xB1/n+sWlvMCneU7JnzsXm/V2H2PuySA7Rmq3U3+10W6fjyN1iQQ/TTVan9HdgD3kgx4VyQQKI n7AJH9eYeNkizhCxEZd6/XAMeNVwTP2ZlHkdE7Yks4mjr/QDq5xYkmXLnppxlD3OujKYi+pIdIu1 LeAZB8hJRRpoSMEIT2N/B/PA5cIEaI+lmMURA6iDhh706Kpo1eMM7IPWy3q5CXtQUtuuG3/eEQkZ 0Yv/irqSoFbQj9KgF4PBoHEliAKB+9IQqfo9JjipGDtT+kUcDKsK9nuoVRx/5YR6cUUJbfEUF/X3 06XfGZx9XUmpOUeiU0coDGrrVgZ4awW6SPPS9kDIvMpSvS/zYve7JBzSOUdr4+VeeTDWRdsFcU7H Je5yOdG33BMWTzL9q6XCVa5KoLIWA62uOi3lYv6pqMjkhbjp3dF7OYbDkfZzcwY66W4cqyvfK0sd 7hRaxTwfBZucqSw3wOoVM/bjrg4JoJfJkc8kYuOSkN76i84eNKN/u9m232vq/A7O5NHRqsFrNM1A gY7KcRRGKsEjJlopIZBI+jlt+BRNQnBZuyGLxAnVisAmNWsMWTkjeqv9E2TuZZzI0oVoGYIIZvnB SXpAYGwfVu6eWqDgKNV7u67AvMoKiu2O9cqK3ZHbs4wpbIpdWZN1HhB71mhwk/McP9/OyRf9pRJ5 WMBtKM7ZEcN9+QR8F4TSbQiBTD0hHjZ62tQS4P5bLVFHoAWElkfnIgUGhr1gUYV0iFqWBHXmdvzC 8Zvi6x8NqyytudDABOM5Co2AQG0qc4GWaEiCDi1uVyid6kPZzIfhxD/hkDCUwt361UfG7oVwmxYL Wem9pS+vhjhP1YMkNurLBs8ClB1Du4vFxccW54FF83FotLs9joa3YxkcEgFVMITBIFVRBeIx7l2O q/IeLfOt7MRChrklI8xulkqpXqVcjjrKKWtJywIn28ftUIOnh+IdE/G43ke8UTLUH0eYT0045tUD yB66AKOpSsYQvywfhSAhxxAF6Ycf7cAZM5wvMFatvunKkuUhalSrqj4n9irFtb0agReA4RUwKMWz 8gx9xBof7HvLXQoOM2og5C2K42QBNpzHXWe1fb+VGNx5ntCI2cKQPrcFw7IjMV/RT3AkWxbe8EKW 9Cd/ESWO8vySV0UkzcylQ9z+0x2e3e5hZ5T7iANWxxP1OOGElKMrklDPry6wOdM2qyM7KpQQZrLh aS6DlcZDPyLkZLG3D0LmsAZvuNUNibAxiBpGnGsSSZHmVmW8Fr+Ek5GYIqenm4Z71WgfZyjz2N88 7Q56PQeQDbHvObTkFerq5vxIGbKHCm+UcsFa0fUURJMDXmtjgg3vMLBtY+tULmkzF6LNj1zzQCgu S/mKWmShy4NEwB2OJiCGpY9SPQHF8VClV+oebsy6KPaVAqXHpxZu3UmzaURxmmbGQUJsbz5QQOLC klGDPOZJu7+oMjYfA8XYA2bVFEH/5AIhfzyudaA3KsxfK29SlmWDfB9oCW0VariNyajAl51TorgR Ac7E7yi/vSHgNEefRXTpXVBy5692Tmf5d//KvR7/4y9TcYLVPqkQ4nq9I0vXA0pepOxAnlggGuH+ +6BzBVIqEYzeEAPZMz/s+qWoieT4hF7/W7DZ4zo2GNd0/74gltyDgewE29L7XmLMrHtLQHJFWrJm UvRIqKvYN6NQCJQLBNizb4oDp/WnQaK23gQFmoszPvhmr1LMoMuBQgmbYvlZgOuy1y46I5/FGBvU FYpiRsOuOiMHM4xil1xzsu+08hHr9VY7cb9ajkMP4JjNkoofGxbgQL7Wsi/Pega7lWtFQzEjBzes C7WPrSu4zLGf+7Z1CMZ1kQA6VoAvRVSfCaMzTs/9AH5tgOI0QIO9OvlIINLKkaa63Xgb2bVFULnc ZsoIJ7dZzG81EsvWg2TZK12ShswrF6FB26LlF96Wg8GE8JqPvgRg/uLcE1cuDKSZclKZ25l4nNyI lBzEhUpYeydyA34vkUwTxo9lhdjYad57fT70hy50Zwd5q90pIAjW5BBW5JCHTi2Ua7O/qebW3IEo yGcN8h654JQfAz47lh0tSHjA23gSQKRi7ZoS4NYT44V3oe5vhHQB3VjGjt+5msfzPdZ144/9V7Pb DB8e3cjJi0PXjLzsLC91sVkEbdxJ7yui0EiHteY/A2ZJrnxN9Zd9bf3u25e/sPG4rFM58Qb12Pwh frwRj+B1zZAuBtWfop7V9Xe7c+N1H5jiDcOk8gSO63JRo6k13usd0qItbAK/sIWFVgWHGMJxeEBg LFJvg6zefXdd2fnVjhv1KxaG3q2rn7tLGAutGcJykXrLLAzk3pnnGx0ScRxcAgibD3RqGIdUDdhC udeSW1jAnUuZnhvSAGbGDcONrRAQfBl12lvYtNLUGPBIRXJJXFhw8p1Enx/khZUkJxzUODBtkTnv xejz61IgFLJa/JJxFtU0xeD+QaDw7pu5j/rnl0dWloZ31DAxPgv4ZLY181FbhuA6/eeXNzxKwTX7 9H5p7sAx316PUPoCdMmbkWD6wmXWgBnKQT9viVo661f+ZvQtN97cFoDxnNsbnDmSPH8LhDYu67Dr kAO8owZ91n0imKNGJ8T3+/fMC3vxhvT6bFv+3CFInJvAe9ye9EBn6pvK0AyCPf5yxbRJCzNsaPEx pNyEU+XyShrAViUbiSjz0zegD3FDYqpWuOvGbObQJRD64iEKqvDpsvP95rDzfNPnXR8678jnQzfq csn4SZDXb1nVV3xZhC/CJ/dqlB1Vu9CnrzF911FnGu/jdakDZUMeh+PXqJ7MwPYV8PZ9mhvvja1S FtmHhrinVCnLbDtBj8N1pjLY/ura9GHlRrGmxmk/dzfIu5hEsk0nwt9u4xw4ze39oo0DEtspA/FY j1Z5OONqWoYTHtvhube1P219QzLpsmzl3ng7V1J9wDJksXx4L+9HRZ8qjSVNf5SS9+GSAmHWHiii vs6BE8nNk4vTxrNC6tF2ZY/SH2JbMCmDwd3NABfUOVkif2Fbt5o2G3DmoJqBvujbaNHEEt673dS/ m+vC82xVcRwUT0s9eJvrymvWlhDRu50sklDU+Xh+6CpzlrnfCyeBg3Nv1pHgaoER1FsbV6V56XpL XagxR+PEQkkfshuy7jnDBAOBzl2u4w1ctb6RUQ4+u1HYwKrA3o/ryxXU4sDR2ftme4ob5Z1qUTF7 CpkR36scwVbjoZ5/MWhd3dt9eoayOdLkjqQTJwhbWNmH3+DQqwIXpMpNriN7HqiJU5/8Zlq3EXUR 2fdCTld7mivsHRAH/orajBnUm4qLX/m5zManuNtzx5LfN3YYGm+MePjsB7autbu7d5GinePkYAWs KvDbjo29rrnmbRmfe0tn4z+h937hfA/tlHk8VY/LVLyB3h03xIEbLABGc+Oc40yevV/rnVfiLBTT fln0fCxEA9nthauN9U8UbW18Gs+QTR15MqC1AuW42Dda8xoTBLGa+7R6+O6NV41Pycjq1h0VViXb ri1HRvjztP+iaKfh5OTYKV8ccUGr7qKtFRZ4b93ybi7fI9tqXMee4U0aqmJOfp7XF395faigcXnA jajP4+CkXQq4Le/ZYVk/cGXK1QEraBwAh3wX5POKU9jj+67ld0T2KyQMpBbnZkwRQZEDpVM0VD/I P1E+Q8iUkjSopsqBIhnAiIaqsG3rOoPkfPy5WasJA+SnxPy26UnKuScSPKNqWw4eXkBz7/QEUDWD vY1Eo9GUmTLQ3yoz/TEncTH7NSdA4+TSUqsepYdMJ7w1oj+CDr99d9rGgbOjSUfRjRJHdgRsIHf6 JwdOB/vK6d/5M5o8cn0kR44P2VI4SHDqmbqr7KY1l/P5OJKsUpowsp64UaL6LKRzruuMPs+5HQ+f 19XrdvU13klVqjF4jjbkO0ACo7f7Lll+bNcXuOU8x8KU6xbDJk8yXAXBBjtg1o8DZ+NO3Hq7dTct 63aA+W2RmHIyTpSjhbGChfFz2au1M6IXrnWrWh17WR/vMhpSEt5QqmwuZrN3Mgf7cKKt40AhOp2o /DZ4uMWEwNyvyhw4fHz68P7LB8+E1YLG+2loo8YTI7M1tolsQiYTkp/gdkjr3MvbuOZOrtY0jKcx uWAyOXH0+XuOnBOZ9scsRcXR1ekM1gNaK1LpNPTlu92ntm9/wozfNyegw1lJRlOfyi9ujHmfz9ve dxI3twPo0Y8AqfYtMnuGIXNHA6U4bIXt1vhv2/j8g9V1WZ0/eFZRLM3L1JO69RqGNQ+XrPQrW5eq xR1MlZ40JtzXjz2f43u36duN5v5RC49Hzgd3vKqO+YEjnjZY78DwgHMleCGcscQ+xnaLan/Eo7Vn eiDHvq1rDj3CP/xTJ369lRXixPXQqswGFgVCBvXaVQ6Kwuvgv7EVChI4WKBE5jcYbZCEFHqvcMWb pK62bwCPDl1PPt3e1JEOunm5Pd8BEwEuCB177e+TRjdiwvIgoAKnDjKfKZECXNDl2737YC6AN98v yjrXEnnj+I1bu5NER/uTDktgp0ZxI51HPjJgrR1lX9PhF2izwQFpv1vhW9jXTv8dJvaa2cx7Ojwb TTY4fHXPOoSVs/zt53SZu8KvCSj+gg9aMIX1/i9h+ktNq6zTpbwdY2z9vTxLbXT9axAHsYXguXwE OHCXbF0ef7F5Q9evNyMsz4HuL65JATRnhAuCT91px2vje26/f90xwg6FOF+vWWHMZ5NqFaXCZ+vj /ot+u4ulJVJMyaL86AMl0NCC8QsZcM0D2rPqntKKI3Ex6AaeAkmuxZoQgatl9UJnjiZcOuyQi2Kq Qnh/C+m0fjOyNa8m4X7Ck+7TXECJtYXdeqL9MxOp+g7Nxbee9cTa87trf37nSEV54RcSEwSXymuN MIJn413bRwuTudO/Y2oOjThDd6T42S188CuXYVfXed6s/y6LLh1JkBX5vF6Yhq4bDGKmYnuEBS6I 3IJT5xOaqzix4YnM1AVt/bYxkhgVTru2rg1CJ3voHec4hdD4K4kFad5S81I9pgZYgRHM+7JK+Dhj OPmCcItpIkfS7fgGsLD1MQocdUduTithOioS58gqXGidsYhL9yRCMSRK85RjrtUFh5/A4d91zGCq THxLG9nOu4LNwEXtHWgaPM29f2RiDpWFd0tUQXXZ0bbo32JU5cSJbNXid8f7ehZyZArn7Mk9/3M7 NtHBtKsDpndgPCVD1V8RolY6NslJRvVZQckcPGIYKZwOrmfbtiPg5z+7qVJRs0XkpR3YaY0WDikd BvRka3uM54NXRloPZ+DXXGhzJgYW53/rtaPU/YRb+V+4bR7QA26n+Gn3a4Huy6fTTRQ4cPiyb0Pd o7nrB9dsuZQ6t1aJRkQLadafv9+K+69tm6JzZs5vNlRW5itkh6t6B1TefIa9RzcdV858cJQLIEaF 5MGwkSqHpU6TC9hTAH1rLzMAZ6qDZt9RvmgBhBFngWm/itPq/vkI/uPRKrK4azQetXF4W2TG1smB 4zVfj3qI3nPVKvKB3y2VK86A2xzVY2vKFuPzYN4VbkL/wZnlQPWFMW4BY8zZXsXYFkPlzBEat007 zvA+a+PVQBbrR6kT35hagK3uDPcmqTNPipWO6RbZjQvlZMSiog7kZVM/B07GnYLr8SdmNi0m2YGn ym75Uf4+JQO59yrlHliT7vutt399HRqwPcVPnYEkE6ayq0T8PSjhMBesElZFBFAdMwy/OKdlnutN E2386RnouCT0n2c/CVRYAlBL5dJY1CtGIl4qfSl1kulVLryX/CRTxXdVZ2egj/EMualS/y8uSecU zk8ekjYZlvQBrk7atWBk+UQbLD1lyENESPZBbCr+/nxY6Zn4lz0eU93aUegjyRZjCBcxCqrMfBTi 3I8i4CSv0ZSxprf0amW4yJCCwFU/o1Mj3dk/kmqdWxGvrb+acaXN9JJo1oWBgKdW14HTwTvX8ciw Bm2qkHQjfquxZzx2oQzqfWD7/7h7of40BMJEoeVxBOju9B/iz7iyOPGfuMIzeiMts793vVR1A5XI HW67hLN7XHznPui/ue0/ivncqc0ZL6plwdmXOsYAlzrr/RD1H5bwjHWSHbHrMqONjuijXuew9L5f Pf1rcb6i9xwvrNDU35ravdNbhK8+lomaDYal33961A1el583rVc9f3hA4YXuPZXYT4YTKCLaAt6X 052uz/en6WBdWurYwvdMl2NCMmolbE7kylDrI8FLJTsHJpopRcjNwHwSxI5wex72h41dKj+lGGdG v43YnY5pY/BiwYBm72MHjzr2X0rc3I7dJIo45Nt+5EIdlnQd6RW/4uNYPbuYR4eoFSLvFMKS1fOb FqVIypvaM5TroKd3Nmp/364ENJOCwCNe04cCy8zOJ3OqsY864ti4hP9qLgWsw+o0bUadRpQS9ghW 2Muw0nVlep9Hi0OOxdDA1teoc87hlgV3jUp9T4A19tuRG0mV7M/Bg5IAjoqStNmyXcYAyFcx5DZ6 a1M7+ferxQkOL7xx37NU/dsUtroHOZY2BYzLsFQddXJnFldK4fwkyzfU/vIbDfvgH/PmnoAN4ETo 8/nd9CW3W53reoH9GJuVvmGMaznmZqLLUM6/ACRxlnmmu7hzJ4FlA7f7cp1tdTVtUxnlHWTy5Hlo XxJSXYczYy/dy24D3vFTCYAzBvfmakj4qaVms+vezdqT1DteZhAF3XZzUO8iIfh37aWbjqcJWd5A UyiELaWJ9SGRO+AHrV1G+5/weR616VhDXyUVZABN5OW6yYeW2asUIZrPiPg47Z+TauU70YZGm6JQ rxoTVf++7KXUoOd/Hv3UYYM39eTnqMjQXFUl3QdMTagZ0vcS/lHjhFA2eGWFe7IDYSB6LL5NYdSb ieRebrzPQZ3eQeTWQXuVnZy5H3f6mmrvMyxt8DIN/jpedgyjLh9yFKbtLTtU3SxO3+FUnjp4TnNP p/lf77h57LJP1/ADckfuzZ8UmyqcTzMHmAeKiz6BgpvRdBj9YeIRIViqCZ/n6vV5drPGUfhvnyz1 wGsiyRtTXQDOa5QYKCRpdMZUOLQ7GoYLqyPCbE5dpqgYniN6Skqu6vbzdIEnQnUusGjzUw7EoOZT eXtRDSbNc5tH942OP3a07cCJfLrapW2LTvKbgzLcyyxhqRLtwMtWIB/2P9wxz3w9ZUSZFfDTLbdg cMJ23k1ml5qW/6ufXkfPADX2luM/hWNsDbA2IFy8QPhOwvyTc5tv3Ef4VJVEQWdP5sesVjjJns43 X/9ttY1gcbuSWTf+RPRcttcuUhabChU+daN9DWjq4tpdoVsOVngNktgTUQG8Zuqgz3wG9byF93mD o39Mv6oMpZTBfu2Ktm2n2oAwqM1VI/u6X5mq6FOjJcwI2wDJZkkPBEXtgC90ouJ/DuL3zlAM8/WJ z+3HLoS1BiDBCaVsWSXNeb0VwUcab9KiK4915mEc/jylPFx5siN8zSA+dnj/B73MffnSNmshTqzZ IRU4bnau7ZfryYqyxU9VBlf5Wkf8ERdvEJ5zN4IFvy/36bXbIch3q590XYyZho1p0+9Dzg7+oBjC HgNM5V66fM/95+l9/KPeLpaOsy5aolBIDfSjzibtC8AjJ9fdBYam0O+ipZjz33e2kEg8ARnn6Ud/ ebIXGx5sLzPCoAhDibJ0oHT9seP1rP7fChbb92s+LjOUa7Vy+OrCW2tpXMGE/5ruKlAf/EMhTvYM 0KiFRcEw8rBv0vkfhfeZCykoNocQ61xi2ZB+eljgNerd3wO9XBMaAngMdLEsDlR5puws0uLHszs+ /UPcBqOHQXvgdQJHxkKkmfdpmknMGx7/P2i7eING+yiGs88nFbkiwTFz7noxhuQsTW85UXJBqvsE NkuMdS6zoGRIfPIcCLPQ3H88WV2x5yM21u+jpwqiI4+JYTMR/rXg33v4XENJPpTiDZYwC4npimlG deJGCnlh2709vG4lF4AQUTG3iRl3yI4qt2fl6iAl2QVEBmeNyi2lHY+srY5XahIHZlQDGBIW48Tv Wddej+tWlX/RDVfo9/vuj0fNz0yS5AUTfHzxXtn1s1viztfBCWDcEp8Dpho+bc0CzPdAecktlcds a9H87sEByIlcoDuNb5quq7H9t/I+KNJPU3j34YEz794+kR0I2wW4dAvJ6Ov91GujX1i/0xf1T1RI e93bZ1njCooZy5arx9pMNPHwcnvrBfDvcrT0vxtRFc4sXTknYVWy777Yrx6I/nUVHqA9aX+SFqMi KSx7ENDLbRr8aB/e+xyHPv6cetGiZlJpktFPwt1InP3g5TpHturvGO60oCMyevbt/Bt344hBt35P gI7ef+BmsupLJXuaEGeQIZA6Z4shC3oZNmnt0bz7qXTDDZKYmoL1X74HYSNVXoUpf/q3GaL3PyeS XcswIkKPvI/UqWHBGwD7RPY9u/feZ+LUe9xj3PARej0iydvWA6/V/bJlbXI4v1rsv2ySeaG/UKDf kTh7ARVV9okrbfL+f0vjGeZNF3PdNrjWsJHoHir0BPDJLef8NR13ms3C73LbjmRJaN7+3TA+pxkW vqvDov/EPACdhOBbj/3wtAqey2fkOARE6GeAVfA0LdNW6LOl6CtBxS2UdNuzfdK2TuNnJtp9ae++ EuIjH/5TyH/WlOXs+3pQznEeRQeHu1ehblZ0Lp1SPwbMH0thgztLT8D78cs/MnXQ8gmJmw0NDK0P F6wr+KDYTPR5iNn76Op0HoFeBMmzV4l8icKNcbDSkvl9ORq7rl7p83iaaN29NT6Owfa+HrtTQgr8 49yzLk6mtf4PphWtqeXYJ2aotEGwzEVyLgnL1mWq/K9ODq+xAMVWeyVIyx+Ltkevn5Bfdi/966Q4 g32yp6TzqakEO8cwotq9Vx1Nr/v4d/6ARntoEb2bBZTcb1P8121q6achV15u1dSn/yxAHRX8iKTI Gfjj2UQGVhXmMowaSyHOhj7KOdPLOxhAP8Id6YelN23r9Mn/qq0NfzMEi0bLsZH3Ymr85MVSizZr V4BUKq/33uqnON6+tniWC18cxWLLc7Lm/VyZSW36pzg+5OBiXZZEzMrt2QhGfWOkXE10WlslcOLg wLRayzbjbNHnuzXjZLF1/8sesX/Zw4XjHGL1MB8DZFAjQcgfAuYTMHq9cbF/aycfe4umhVmV6Zxa lVjWWBvoshY8Op/6QObp45Fe/dsQBPiI7seRVzUL3gH0wCrDbYOL6NnRrpPZITk2raq8FlMQln3V DT32RmC1zL7ou63NIYfsblWlotsgvaQKDYUejE1v2/SNaEclzwruhnyB3gfpvtJ9dYZ4r/wK5ac5 mzDlO9v5PkPj3o10BXH+F9eBUbGdcmNPwMTl1H9MVihspVBdVpAHBYDIfpm6Vc1x5D62MOwsCZW1 kYB2jgB8RQrCi/zcZ93o+T80a7nUEwy/rytSJfyE7hdo5u63fJs8bVz8pGJm+tY17/UGc/E6hiNK nwblxuXhz2Q3SFYLc+mwJA0+R7x+KMbz74k1/juxpveVUOknF5dKcThCnfGBzHXtm38v8NTv+e1D OVLtMfdRE2gxe8WXFPj7OreDIwmXC0hanaENPMMJZ4bqFmHtoLfB+JPzqekydz/IW9diLCUFCbhy Q881B6dnryY+GsXxQtMqv+ufS51QEF0/7XFf47/cuOHM0CNUWn8KLsvgh78istl/Oh+xooSDXoY9 T+kRmPX5xCrQ5Rri0wXcyPcXWfpRxyVsBA2phYEdTR8RFJ/iDareKs/aOM5CX6JXoGAlojUFk62d ++n+2vRBvUGdw1rxqQtK81pBqOUTZjyWzg/2g7np17P0aIHu27V2Y+fQx49IBp/ReqGjDW/3l0Nw 5CChdKTb95/gJZcZfG7pBDrjj3w4p7zet5EQnaP8MJ1Xk+puZB9xV1JfJ48+SWU7r3Jf1OcpanMb f0CsL5dSFDrPs9yMr45n+8W2zPVjGvC+6/IYVB7kIz5i9n4kfiGUZ7F+1ZFUk4f/yXgXV/Dxvkmt MglA0GP3Rc+/AomcJazo06kPXSfOAGgOrxUZoVKJkItMn0LMp3NH0n8xGyodBmgeOm1Pkehc1YMr 9RnHJSE8/obFuA/ywlKHQI3bsMj2/NMq04GEiMvRWh4IwD99xKkZUim5fYQWZyM1/hnivZ7Urf6S xyHHpUz/5OPgOzL1UlkSVajaU0fbkMDHCW6Ud+ThxHvmrV9ogb+ah2hvtmoHfeHdZyz9q4lrL0v7 tBnxz99VWbEDiQteZp7ZcxemdY3qxBSzRmdsaXEsioGhVJuJ7Mn7gL9qL7GF/jedA6FrrwgMJnN0 5V+1TGZwUPoP7tic73y7WhizB2OBoaoX3wffOlUvH/9w3kQ4GSAP9rMlQFvtbMZ4nqiWISy4L16e 4B5aPAKC1y9keHA/1mfUVMRwP5rsVblM2v9B2HWfM3FHPc7AusBzheMZwNhGzzd6vg/vcw5X2WSp B2ixj9N8t2xumXuusUeJ3Mfj/5tv7XMIQaqqhHOT31gSH68wfIowtUF3cp8rAxe3/jGol5U4g7PJ 4VAoxfwdL4aFlrch+o9qBxwQmYTTxhsWoeaCAn36l+QxPuyjqKnuxX53MI8tVGKERMOJa5lhFkmy 3pedSWtBepdPMpApTV7SiWKb79lxlZEOepL4tNwyyeV/QuImfIiHcuRXMofWeE+M4L/cPn6j80+k Sp5lBl43c+gI3UTofYZ2q6wH9+TvkUKOPHDiO4TUMtrwH9PNYBD8Z59jasdv/47hbruBDnp1UJ1A nToTZ2as+Awi6KlH//HwCtt+25vLC7Ve/GHVUrvGXJP+//yOVxIYijwBUaMpLN0x9jlVaQde+1/W fVzkyJDmJNOXWLTiNPnUtPyj53+hhjO4JP4ufBE6bGCJpyIj+dqCmndtLCtW+U8ZXdUJ8CRe13AA MlPo4T8tXbum83G1eGnLqwviEnMVuclcTkv37yVm7TdR/5i6nD7IguLAm3Gb6PiZ4d9L9v6qiw+q VfZ+6P6f7Nlkqd8fAnovBAudONS0R1abbJVfW42qy8IT4jgdVNlmZcoX/6lfr6jo+J2GuFzqeNnR YJ2izU9bTs6KUH0u6zOD0vZ/VVSOjA7dUWYFsLXBD/xoxP/LEYWeOR5EeKHctj1GpMspM14UpJry HmZ1TFxP0iITzRQD2GWGPE4kyC2JV15PJjY//uW/MkK4O92D+C9KnIBaL83+T4lby579N3yGzz7o 0yeCNUAZKdSFK+zUIHfQy7pmgf6t4t1MAPd64V9Gjrnwi/tGSzwBFyovJ/jvz5QfUajKTHEFAJQy wPyPnHCM84DLUWaRHdy/1ZJefkuUnXyMROZ87JRypfyXGb9DGQT+RyDTc7ZTVwtav9aCNHWIvd7f 99BzqfP+q+O4/oz+UI2v7AbWeZ4t3sYbtJ3gfBz9CweMxwo0uEGvQAeuCnLxxoJtL9v597siejjj IDJL/DFFlTTqwWsRcTCBTwo4lvvPGEOnsOKWKwpSHEV3TPcyCoD1wMO+dOHzf+LOg73pYvVKFnaZ Kd89draze1HE0Of7xTsuZyC+y27HyRqrhB5+YqYw2+D16JNPgk4v81cVGOnx73SWN6icu6ydzOpz XT3srmrS+x0lt01Dm/lpTtGV6agOXuy9WX7+Yy2N5f53Nyqb28kF+CjIYdVUoBeHivv7ES68d6LD 6U+eUvs1m7hK9PHFhM8H/YC3TwkFvOEZvqSsWYs/TEopI1XpuPzMiKs3nv5D0TUdKJPZOC/CTy1K Or1pRI/Wh9rWfwsKLq7bZn5npfowm6wWjKwZ9ckXkvytsOlL21tGSpEoAaXUA2vSxXV/sCZCr73c etoQ/uMDyUQfVLj1wHntMFSFXgI6V0CaXKT8hWsdd9s1ieC9u2ZdJwvnAtdJklrcp0VlbOZGDW1x cnZdElpt11BVX4XmL/BbguMuJIuf/3FnnIpKmqL8Gudca6GDDVobPJ3zneud84luwtkpabUOCuzp okWt83TzNPSnO3vB8v2zdci52RBSuGSrc52NOHvrpzCfH8xK/Pf3UMAuYWF1bhiB9mmKNe2nE5ZU dv9HlU/YmPhYsaVXPnGdpeAr7K2nRF0HngT/q97UJOP6L3RqYjpCs0kHhUk1laZZ97bF8j/Wc2up uugav7mwW2jQRnTKR7SO581X8P9bgfhrQd0vQlrdvw+MPuMrg4rIUy+gtZc7gy4eP8OvWZAGW7VQ i2bsU2RU/9VxLq5BcECskWYhGmrSZ4bPeCfLkv833rm4im4G+VCPHH+7PK9tYLTzpdoMivWO+4+O 5tIIeeus8LTnaC04nb1iC++/4D85n+s+m5rjsL5eJe800+wxizGc44q/7L3U8Hjb5/cOgncUfSTv 56hHMSe0G4bcQJ+VEAXe72zFr1EpLqXqnymMYlyTKLN6sgMrahK58c5nrDCODgwzC+wdLwdkqcXZ az7PsoZ76j8yKrZPGc0dGG3JwgwzPmj05xwzj0cd4urv9q8/9tRoh//cQdcNqQAJOfeiCj0+daYl +p9/Ce/hjb/rks/vIMT9WIUczxP2M/TbPdW1v/8x7jdEUHYWUgwUW0mPUPoowCtLypt1b2H0wUFU SvJDmaiGd6cpiNPK08G8fwrgebjyxb+pQZpqw7GVHne/Nt5TzNyP2dVe1/rVwb+zDRx78IxhDah0 Y9xSpo+VxsH58+56VdPVofPfAhVSmuC7P5kiaWx1CitHqfwz3WP38HP7V1ilt2sruO4/Hphz/Ff+ 4K2NWtkdHJO3Lgfh38ZP9VmaL16E6/fsCbqIAUbKE538c+EZhUG8EbfUAhX5CQzY+FYrnBU7vH/1 nOUHK/u12uvQep0VegpA8SdPgAQR/xvjw2MQ7WM+AiTJc2UdX/zMDsyaV6M8PdzqJO95RdhCRRUi EctnfcqX56xJ6lOvNytuiV14ltwy+vhGL4w7XLltavaEZBE+syrzRfx/pp21lom8yzMcwx8qJK+0 lUX8DNie7a9H9B+Z5/bN+qQBvkfeOa6Ijyw+arKQ9LBpH84kylCmPNyJ9KQplX2ybf37JPB9Nnsx SeYRHakxRj5XzU+9i0ujPlfcGzuCpyTR6/yFcKcVz1cSDnzsgFmvJcAjrjVQt5ISKpOquSA2xZNZ PKZk4vDAt7I68WPLpc3/1ELitstawplZ3GdN+l6MNDNVtGNAx7sUzjnMpQ/V9zRZDfD4PkSjmRuP uDf4Hh1izv/uvwlEa5zVYk4+r3818/dSLzvDLkxl7PCEcIcAPkWgMbr8SNdxu3F21k2lfTkAkSlr 17mIqNSF8EKwhNnxnUhxWQi7aXZ7/w3c9QF+LqDQEAh9MW354F2e+TueJtjE0zqjvqv9DaJzl3Yi V4lX1rB8Svlh4J1G5y5WpoPs5XZy1mdQk11YqC1lqB6ubPxGproFydNa57Us4+/ChuzYzk5s3Ptz AjbecpLdynAIM1NV+csLfTLePw9IAz/UuGKo6YU7TPm4EuLQ4abEpn3179F1382TAZOpQ3WQ6+Gk MUdKe5v1drnPjPgecS3tuNFLuKvXX4Rk0+72t1ts8E7fGjLOcIfNGmbkvhX+pJl3s4oC+M5LSF41 N8nYPwPxX0Mb3Rogso4uMnPh+Y6j8AHnX6H40BfF8fjf0X36uZsnLGpLzsOEzWPekLhjVX53+MW0 3ETFXuEaR+vDg0yDiFZrrPyxxmIzr5XE97Smc1jzfqV/j2zkSJDbuSnpNjaVp5a9NQHgvZ4Q+tz+ 3PxnjMFuq27JiRJyqZdR37f8bU/rd1coj2d470HNNA8i85WPCt7pmMWic0XcS9rawpc6/Fc4F9t2 iBRShKto6YfuC3dHPvZEJV7v15vbz8mielkUrWeDFK2WG2N5cEs+TTUH6vryb7LZVKdWrwd7o00Z 7TDBawPOcqSmt79j/GwAvy1C1PAZyh8jps+7v/Gxy7qv6tyDbG6jVeL/jIpXk5xQcYKbTi2Qvmp2 W4hqOoPo6MVdi6zJR7O9VQHxsFgHajUVHTtnPqKeZTGqX/12u8jMOq26BjSaY3xa1rGv8S9S+2lV iy8CtKiRjiv1N2FLTbsODyxKZPmp/OZ3cO2ETVUqJeE5/1i8bXKFKbWGhhwOWDTIvnRf2kIsxsjc Du1pIEm4rEn0Skh9rmA25eW+8/HT6MQ7JmsOvXiZ4wfyru5n1VB87Dbe8P9ghHbJUbQeFdrmXs6N w3NMd/9ge/Ni0eixS73EqbruZ1BB2jTh5FPlSKl7DF6YoXam1TLrfUW9tjPjnfVWtNdy+7adTv9W v+NJR5fiMnPsA1Rtiz1djn5cvrANqTTJh9h4gqKX/4TL42qU126mbRj//UnMlSzhYjz6upVVDM/P T/94yg3oPc8s/Ih8cH0xr3HUL8fw2JMmWM/vPzyA39QvfOtyaerHlxxC4iOxl+7KsduVdJkHrnF4 KrxXT856B2lq3VQfaQyzftz3UfNva3/nY4f3DGl//fQpXB7hsChPCiBhc/wVA1gGdGUz3/qNLaDb r5EOI2y2jOOFLyZNmos93q2jHaL9hxUWjS1Nnru3OxD2dyPW49pr0u4V/yOcyxVkhBTF9p1x7AUC LD3rVnP1K673Gf07XKPrnIJkb6GUtYWc27SkT8rxp5HUya/u8V8jG5usUOe9/qxKKNHSTQEiPyno +ttTdecV99pOyxYWrtmPKjRS7RHfoQ0aLaMVW2vlZyP+K9zI18o3Zr83Ztv3G4g3YAPFcwNxBrRq ucLhPh+QeknQv5/Od44tBgXN10tdh+ETxClMa39RB1dBGvHbh+FeHyzc1DovNGJGfYuTv8D95fC4 c5fXwixLkpC+hTHQJq9EHMPVeo3laf3e/3PQO4HO5B7Iuh25mh0MD/vFScv5545crgynk8ksIeaA V+nReVzWE4c7+ja7DfiP3xvdqoWotoXIFoUoU9QLvXJ2m68yTmb5ZF9wJ1wphG36eFIin6g1XLD2 WSi5qaMqmk9anYRmnl8mbw6fkN9f31TlZm9ypGvr69R/zwm0kLmJwZohlGSXKZRK1TfUpwoCZ7V7 eUqaLcjZ14EssEZHE3IZCB3Ha4rUic/lb5RRMFhrdc+SeZ07p+6Fmx3rLK/rZ/XTkQuyhZonNv3F SPzrrGvX9ftQGjBe2qWdGJVRByBWm+v4tRZ9iZMqPmCF3o6b3fgpwD1greRSrrdMH5zac7eZgkfN gf9BDKXexPRYxEa4LJTvRhrMYR15gjutlFvMQvxmeflYYGfWG4aFMeViS1G70wp1EJPpZbfr/aRH jcVjkHfGnnBms+9kOZ8DMYZPzqSl3Xi8bye2i1WvPF3yvG3NZKk8AHMuNPbi8hqFd3uznPQSdkW0 7v4eQRGvxMIWW6Zb0/h4rFYzjE8vXtOtwpvypngbnktb+ePdOp0/4h6j/OlqcrSf9YwytZ11RfF+ uysz1G70xwl9L+urOnqj1+upNNoeS73mTUEr/n2GVu+G3zHeEbt2dN7c5lTH49kyo0WRc53X4uR5 kXVCxRBXNlv5Th1vkM2sSHmbeXGpN1xmi91jROk+MBWnaVvDbW5Q0g18Mt3ig8+t2/ix/IWsN1tB jRW3qHlppvnCccEUAaJjGVcG1iE2OjAIHa6+byBgtqxv+n7cn3+a9e+9K8gGWhxx5RbKpRxs+u2y WYjalbkIjg7eiQlHHHE78KZRQvNlRLmB/MntIiux0+TT6Qi801rFHPnP+xr9Po2eTYT9mrX1OrsX 46yH+UnpIIXe90OazBOojeUSsD6L7zGVHE5b0qt/IH/cRrO3DxZx1o6/4nA53VbDj7uMxPoAJCq2 o555MaOq8okloO9qvR7iKcdZX92//h77uctFOP1aD8mWiylcPy5nP465gBfm/Lq+IvKbfgpaawV+ RTTrd2tqM1zKNNsUV4o8XIY/NZ+rjMy+0SmXw9VbdRnNuWgOv/DilWjtbkU+TZt5v9VqxXMXZ9UJ yGEfCz6H03ZX/+R975sGs0CvDfKymklzRVHt3GYOUOuosdwQy7t97cegpNNxiSSUz+UA/gdfOWFW RGpVcu0mGwLYV4+2m4R5N8oKRI6joJWFZ+v12xFffpVdWU7ygVvGapD+hxk2hMdz5z9hU4v5aItX o1FI+Aneczs2Id7tHPlvV74Ww1/GQ1g9oOt2Lb4l0K6MU2GM0k37SYImasnrT8XdamucaTlpAbFw mS00UzXc6kEwQOhxzN84uBGIlzIWH9k4FepPM4LAF3nxchfANsvxL0IRrRjzvAp5WSWanCj7I3B2 uaZKliV0HW3soCrJWk1Ve10s1GmvDFVL62yc448SQRch+bcayTdmBBvrry1XZVy/72kgCxF3XGwm sZ65nA6FeqtF5J1Xl/dltlg8OmmGdho/S5NbSwLJe4f5ZUv1TZecVAd6YE65gAXo3KsPPzuNtUwf LVh9pG9VPSdijxe5NFyx+Hi7WV+lC0fpuReT4/eLkiJzoM7CtlEWR6ALap9vFUeFYSLD1Dn4KjW0 LZGURreW/hhroxWoeyUQcsyMCfh+ecOfNYoxFP8OMo1dD5a7heMUEfpio8lH4V3OlEmZBv+NRNQe ozCudBzFBgP8mLtX52UgbIGG87sLv2nGZZRLeTo4zOaoMgBQU1XaUZY8NViXgaOWe5u6rW4hSooq GSmxVnnpaadLTQp/bETt5hvFa+QdzpS2YyvneZt1zNAaZud8lWEcj57ymjgGXILexMdn7X6ncFJd jWRQdKk/x8ArxopqaG/CX2/hx/mCRti51d4LKZahRkygnvu2yNM156l6cynrNVEe9CpUrPcUBKjB fyGFfjJO4oZnVaBPwCnG0+b+sLtXKY0SOcwXwpiXLeMwlxgxq+SzrlF905P94RmHN0lZfctQY6C7 9DAoXY7wXAGU/SDn7L2/GKUF+F5GteqkTuWKGLXtVcH8LESrTU6QkbZiujy2bylosKvgogEQ9ggR yyodPgziQsV6Mo2xgdy9q10H8NCTnLwBu45jPK28ZW++vVHG4RTQ75dqdtRPrNKqNuUU4f0Mofe2 4BZJ6jTqBYvIhwt0pVfCSLCxVB+IKnz1ttnYOr+ZS1io98LevghW1dPjQ6Y9uLjQuJ0pcS5fYSc3 nzd+kT5qbucM0uOF51Z35+iys+XawLeZz6YLCrg00IS/JEzAWyC9aznt13TBfR5lANhB5uqFog6k 2mq17/DBte9wpeXeyvfW1uEkYmGKHS3WdVg0u6hvsnrzx69p0/CWPHoaMoQ6vLqVHSLeY6M9r4fl A+IqDZ5ynnVKq2dnK6KHtfs30qTuLWvQ+9Vgd9UkvM/yAWyyjH7wqZeWOi2c/RruKTh57idQ0Jxa y3PYaIDeAOl2Pf5bbDR9aSkwFb4lmjtLpUsjzubixh98ELtU1VUl8jRvPZOwmGFRqZVKhzlXb+kL oiiS8MSxz0X1sa0p1LfZQBNavA5ZGl7P3bSTCnwXJ9Wjy72HxplYZFbqd8sTN/PvEPeI274sRDyp u2kyqHEb9Zfend5nD9S3mpubRrzPD2n19drHavWeN2X78M9d4fRBdsXBCsToTNrCaiFxFF6YnlTf JclUcMho1McrXYvTDC0uS7yf+kuaI1TKEK9Ati9MtNwHBcdfMOhEbVcK1czXNg1ZO3ciIuK8T15Q 45NVzsbI8NYCHnrLgxQSZUUfi/uAajjLTgfK17U08OMFlzZ3hAEaYNezoazfxnrbLlD7t92/Waxh 2Mza6ejX7KyNnIbJSzGHPuaoJy0egDyZ9c/kotN2soRV5+jxjv0Y0LSCXwlZetLe03RnWFB8LgYa 8f3Jlj+DOfRUKU0llGkfg86gCgOifeyJvj6MXu6AXLwxZqbNGIgy0T3dfsTsIJVHYnbwT+SruaH3 0onHquqUPSIbuu3sGMuuLU8gRsknH/dP0KjwyYlv4jdSmdXBBz+8yxr3fRgm0C984pqf+G3mATE+ Wf1sDO5EdTxz7I4Ab2SvLH0TDCutOcUW9TJKFLdV0uIeO+1wOfxR7w3QbGyV2kwGccr3gftB1TxL B04fLd2uJWc3Dn/wzNAhAZ9KsPDYdZ5jkEbHVXwguFz1WyE3ODgfL9VTgo8lVcd9uP1xlIooAYdO NwAd0GYOPHN/3JjPSOym4TVXOzECDWXfqA2Gd84Ml43YdBwcDnZJ3/Onunt3zTUh6ngiGL6Epx9I yk+0wi+hLN4MTb1ZN+D0lAg8rEkj9aPhlBypP6eHW3M83ka9fpktE6VHl4Sn/+MeH7ezm8DguWCd 71JLEsrKJ3Hi/afiYXfOw8OPlr5TVRx7rFTdrg1FobLWZMJV8ZXhDTNTj3eGPAHveGUcbSn8DudU noOpIuzcMzhfNFuMLwGetpB9VJ7du9dmAbZ6rwi5dXUbzWeW27HuqT0Dv3jywNjZnfzOvqtfGp6c 43CgCgsr7Y0m8HUntIJXayoM+5nrFnni6+aoWQFYqny4a0KS8JvK2ti+GD/drn1Kja3xsTzaw+1u KQd/LY4LI//iuiTnc5Ca/do+73ldaFDaAn4kwvMPFWS8OxQLUJ7ge3tteryGFAan19cFeAb+WSu9 ku5CLat81xWEPIceEMrd2kD89qWnfvfGcmNgHWFSS8RT+wrWdW1Y/qCVTPuKBNBe8zfz7KPQLj0f SV+wTTn5ax+ljvdOHh44eeemHm8Us7q7Yw5uh3Y/NKzYczZwsAYvUJiG99DDsiiUHQ9nZnL4snL/ BSPfmG3C527XYlGfREXJhL//SF+/GMTDzooytNcY4bzKwhGuc+DBQsuDjWLivKUaJejB2A4v2KUC d7dcv4/9UoWnofYABxBBeMf7+JaxUKlCw3uhcuJUN17MH4rf8iW88smMT38ASrQ7N5mR2RQ8Jdm8 xD1endiAdNpWYiNKkZ4/ayfSlX/Bh4ITy1VpnNr7StR+rutVhxai3AlFMgoLiwLpEr6UyARojqWD C9tbr983i08Ctwpl4MC/ps2/sT4xrzaGld7J9vqLyppOPBUOATihPQy03e0LLvXru0WuaGol2L/v 1uy/qjgtSUGEv8/d0vPwWZtGR+ikie4eLNh5QLPwzAgtMe3vZWe6E90M6s2w5hiZfzrW4JiqZcY5 24E8ldiuWNcffiHcNPBaNJyDU9i885rbW6BIyNBUr1zcoRosDlINOzeP7L/TJyevzqgcoBpoDsqe NjKyzVCtFuH3t3933b6u7kOc2lrcZgtFNa4YGUSdjSLYMFMiciyhRs2WwfDUL+ewzus3g6A5oOTw xiuiSCI9pORylu/fDtKbQiCoyB/MVfQyP5Zu3HE/HijKd0kogGmMGaRKwLHif2I7bSxgb7lztTX0 pD+1ob6f2LtMHwzaSHve5Yu6uQRwxK9T3B/QRCKgdmZk13QelcLBI+zERmi+JqYpe6UfGOvLeFF0 NKdi2qzbaXlUDwyaiTmDj8ka6e56E1WIhFHbheaLMnOsRzQ82uXCxoeEn64U4rFp0fButA7bK/SP s/E0Xp94YHKOkYeiDlLvwXTqh6ZG6HpjwJxeHbZdUIgk1WOX9QLSBidOciddXB5D9IebPWbZSpKY joFbY00nE75vrFThD4fJn1vtldmydL5gXp+8xscRZdwJS+f/GBJGhX/odahzG03nGdw9iEZUJedn IbiMKkzvsmJ5wsxMec+HQiV+n+o7qDop7J+1iZsb1NOyiQvvDQjN7+xT3B6dVkap5JufYQ5coF+Y YoAlb7vd2c/fLC62ySxddYpqWN3GPVsvVuWmPaCGA0r7hwDdGComvZqI14SFQigtvPXH4IFArfTd P+LYslduVCKvR3g4yXVRjSc9prFk9LssW7lOHLLMO/4BcYX3/gKL0a4nBg3UwQ+0CRjW7I0OsKfD 2c5gvJ6qAy/1eOcSNF6257JvnqaUMNa4O9Sx9+V75iYimk0glDrfkRWlwtg0qvw2Chfat0XHsHBR H1UQbK3LNcUHGZW0xNGJK0gO1dVDuY/RU5OA71eegLWZxF7WWPBB6PPn/he7BW/zVLIV23vUi1Y1 g10BbfSRKG2K7MvQh8/QVKjm7rrIU3hrgs8eB9nnZg/klZw/ct8ORQTUsRRnannY9S4Q4X0wa9OJ 15RxIKQ/6M/4Zf5yarNaW/uo28cXXig6Sdo1JBAQ83xWoH/6LV+7uy21twLdusKa1GwBMlnpqOVY fbZWX/wTyDRJeluKn8knz7m53D8V5W1DJd3J40kwuAMmlk47iOEfogDjdX2/lv98uu+bGY+/TORE RvXY/Jz/MwAoZjk86Lwzl/0ahWz51vVd9teJShlUU1ZXgZcPTzrczOSv36E+R0Nr+sc82tlSb9cK BXi7cRXruCcu/VONMqsLw3RaVLm6h9vQaz+W3R57GpkGb6qqt5/ek8QVvjY1Tb76niNyh95B+wI4 Tsp14HhJDdwhGk7SGCFu7pxmuQ8MvWX4T9MShZwmksxhGflBWOaxQrML5Tsrv6DZQNiy7n05gr7s VjvB6JvBD+80Fe3gP2DKdjDh4Gd3pTUWBPIzUfneih6zU+FNNbJdcfHSzMvrj2dCEGVAvDzTBvKP ZIIROzYgXB1Os49mqqJ6trwVjV44uatrUdyq31xqlj3dBO2YBS82Lp2K8z4KYUzew97sB6Vsd3JQ XZ2CovJzCRKvjjfNQSzir8Ez33r6IXGXdF6GwW9QNk/umKZv6hIaJbyAn7vHhqau/EFERsdtqZA9 8UKzeA+sxPSOD029lH1OHaDmB1tFq30NB0d/erP7iPOCGXFY7shRuw/Zl/acfxjUtoJ8VdxdNuzq hDYCBDnPE/ULGVGcCbopX01QJHgRc0DjP70BbVkR20KnMl/Ym0aHW9lMtvNf3l253Ao/TNt06EAb 5e7DKsvnVHjebPvnN8o1Xhc+P96mdYTLN9rM79BNvreE+t1O/ljm9qZjzljv24/Rv3kbuCqNMrEw Wzh7mKmIyeOY84k4g/eYvU3jP9xdiMlmx43IfT/fvzqwbBvCqKhLmK2Xp0levN7K/nwtN60xdz28 U/65ZSePjhk35izAxGrXWeFHLelD9QgOyNxaug4Zymx1lKajclsvh0t12lPbTw+lMAx5IvbV/fsU 9Ayk2rUnlO5z1rDqYDOPATguSY/HG8Ok/UkL1HLCXG/AwQ9DeNjFSGqyHsDP2XIlxVeO+bOX6DIJ 0xtfpg9i4ktWsqrLKHxVhWWi613sGYeT5anr3dTN7jOGJ+D6pSnQ34DcB/SO8bwzoObGAuJ6+TNj mdzySduakpvl76Xg7kSD7X4IknFYTmMN5ToJ+kgirE0LPUNPcXQQjYbjPVm9/Y2brlxd0FknWutZ fPL15+FPZQeITFGivgg8Uo38qp3sBLIww7QbNu1Vk14Gd8bbQ+KHPEscmffEeF5Do8vekQ0adlmP phr6jIqzWX60QWrfbKvW/uvd+zxAuSHwVes4/aklwJy/rmy0aDn6/K4MjabT48idtb4G/fu9Ckw6 mHdKOneY+vhIJ5YTLW4mU9g+/O+Skoadq97E9ynX9Ptb4tXQ/U3BThkPYMOT3Ky00CFL2P7+dtma Spt2dAFuMtfgZdWGR7Wj4fNtqT7NhutbFn0Hc3mM1nNzefweHeBGAH/p7PK5Y/58UHL2opDPxyl3 jclju68gCxRZyfyEpPqPSlmI/Eqx3ltHeKDDkg/dIPeRRnAS17hkZj4pZbMhaxN3f8EfSzxWRkeV TV3UkH54uMfOD2kl/2ubUeLwlPSvo54CdyqvrgvGaAaSNeYsnmN0C3tDv8OHoaUhvHJqNHHGvsHG bkc6sxcxS9J6j0yh+jQfR/byczRjSXmP0Sbgu9TIxh/SH2Zaf8w9ep2ZkAxf7+7kZ7q87lcQQXhr pfHFa26LSpMm4KNX0u8vJAaNQD5Ga74ovXx7O+6/Bqzk7pXO/15XZcJHHcI0rnXUisBzV9bJcFc+ 6I2LAj7Y2C4evq+nFrUzVkY1WFcvyDTjj8IIH2UY2IdvuMtBJ27Mhvyg5XCnrjqdhSYlvin0MNs+ yF/jqqVo8m9puMuyQJHwul1VBVhP3II3P/1pZvsd/pM28D2L7jLosJ3Ccw24Y1MiVf5HHjzM6IC2 o2Wf3qad6sMO3PtlmncwuCHsDvp1pRTn5nrBKrNInuxu+ly0B2k0SjdcNN+CcYH57BJnouHLPWeY 0SBx6v1SA3yET+R50w//yvxX+pFIbI60sNDqlCreUaFwftRO5P7Iyxz+grc9UWWSV1dzhcazD6N+ ataW70OJmbJvTHgp0+bbkYqlAdQVZg894+VofLbnWZN6Pp391wb4g3LvPsnU0Z0W76tnmYVq3lqd jJ40Ya0aaI/k++qrWPSjkUHmUoU9OxXe1mxs1hiVW66sQom8QJmWxvnSYc1aTHqJEZ0XgfDxGfwy p/mV8dyFie/wuzZvz0f917kHUp3XtsDXOgufxdfaDpt6/SeIA/g7RXrZs/zXIu6gVOVHA/TRTrS3 1ldD9tKrSmkv1hfZ7DPfTMXa552S3zWuwmxE7+RNq2ZtzsYviBRwrP5V+BEuP2xth33YDouq3Tn5 nu8FnjLNS4ekckFWQ2qwHkyWVvxPSqzUA5h2oTDQfTr4N+KHv5kgPytCCyGTOCuRL0OzZ2q4UkSi iy5BY/fDSdFZ8RWRddAXfojxNzFS8ksId2MTB7a5CcVEOdrJbPbej6lP5S77fDeCtzUiIkSbPRtA lFSPsmmxyV7T9Aw63xu0cVmZRsqrWGS/M0EfjZLOwIU/eRiMurzRM2NI9ifJZUGQFD2R6pgZh+WG fNvZE9q8c6tFHY06VsPxAezp72WE2dv46BO/Iy+HNN687FKNyq1ZvFYs2ecOX9usLNZ5WdCOWr+v vM4VEl9OPhXTBx0l1MrhkpeF75TxOCYd9s00Q4/e6QLl8IYXeU/1DVtwskMRoo/7U75i0EFGaA3z t8hPHhwp2mk3Lvmu172IpaCPiDxi26jZw582ys3mrkm10hkCHbGUvcC0WzPi9enjwqksrZWQNvHp 95jLMz4z0VsL/pgINWSC9rHdnCoOLdQcVxycyp0sWVqbVg4Bo9YjVTu5Nm2cPB/LE4NV/ICa3f70 xcQcV+5MJ/Jg/1myl+VPAKCJ+yx13LHK1mrXegChSbOWu8e3yg4bXW1XNvsBTw9v2GmnliVLdI0Z qObiqUF09fLYsR9JuKquqZI/HGTKY6qINw0eKbmvq9Sc94B1g1XpWqyYoatZfBtdKCORq21cJ+Wf tK9FtLzfsW5tyFd9RjE5W9FS1NRM92Ndxq3i+ynNfcWWQRD0/U6gjJJzXlD/2XZThf6g80xnfmoz 1tFIWqmGUlq3Og1/g530g3j//E6Og+lc5jPfnkz1g/Gfds6D7UAhJ95bZY8wcOGzI/2Ofeds16zZ ePzLOQ1rNa5Nyuxcj6HCs72QVKpWQ1Zz1PR9+84c7KaiTXxZJWDNrrhsO+spRUr/zPRrme20Vtva mSFgev+h/EoeZlGEEw9T32pRpF+yHjGlIGvt5EYnDhtK/5wL27hCxFkJplj0fDxSfxBtmoMuNSz3 OlmnxMm71MRxwuYuZrP/1GKjnpg3H0fFDWHyMIKG7fpdRWZD40nOJYapcILMLIWgpF5dVVlv+6O5 ImGfLRLD9VD1LFoifi993U3nfCloL6bGNcyhCnVERYIEWV7i+kkwFzuOOr4k2Epq8hszRpaeSWLf HQrODJ6IyAsZGS6llonyDz1Xtr5B0uT0GdM7xJg/jnMQvcRhF3f6Ylh6eXbMh3Xzo3EMx0XwrGYq CHTeGnlCMqm8TsvTvSHDQeAMPH78GONY5OxNGXeQhbHfZiP1taze7Wu3yhjhmRXtmcEgcyh99QBv vNgXddDkI+jhLCzs1R6oJM2EDazWIhzyqBXvZ7oHSYGaJASNu0vMdX3bqBYd7U5cM7MY0o5zAnrW UYM23HL4oDpF8NcS7XK1htsjlH+SPLuIlCkwQOgCJS82fk5o/9FqMySmttcbb6QWRWamFz5L+Xaq YiupXPtjK1yKtNP2RfKIN8s6n/sNyS3fIXEoNTWxCU2JV38m28YilgVSa0ewunAeQ3Y8Q0MX19KO z8hsC8OGkcq4sRakNx0P4/6kplokHVprvlvVptr4gAbpos510rK4vhQMvEJMb4ZXXFtqNuNbDNy2 YrsArk51vH21fNPYGlqy/HWImeh6qRAsg+0sg5+8i9ML0oabMQfZpn1WA6bRlm13eOBrwOnyrwjA t5jIMSYuj19Vy8ud0lqa6v7ptAMDKOUmUd1ySri1K1DYmbzgO2mvZFwr9UI10GmyNGx+IsbV3brT a2MQNpYkaIzHzgH1tObvviaesZ4oMJqy0qGYFqBk+Kw9j/lhm5hrGDu7B+MyQL17lD+Oa46a8x/f yM3QU2lsnRo6hF2nHvrWNioncvna9KldMhqT3SyddWjXMH2b+etiti8uia7sa6c22ntT0m9EjM0R +bnud6+oudr0uY2e2eVGdA+7fAUpIA7e8QAqpVBtJfO2Cr7tKkAHgZnpRM3oW9iz7T8dLcn7bLXf EWLhMDdLTqx0beTyPK5RWCiuPQRmeFXNQenTUD2BmvfnvI3flb8xnoWEaN9VfEPfJ4uTOHzP4J76 LanbiG0aSouTn++xWR1PYzKg5a57Ed5htJcgTlbhHjMAWEvzv4hklUZB0a13uovpUl78lt53lxtG D1CPCLMB9T7d4bYuCfoTNn5OGgb/VUjKu1uwFe9zA/BBryfGZLzzBQzHVnZjefBrybeNHYLEuQPD QkCEU+MzaK/IVMIGXDWk0kSFskLrfFsUcB8ChavirN/jEyFwPYx2H2R8dL+SPCkSM+Qo4dFhPlIe m37h4Qe5nwGNKCbx7miqvOR+VrRTdgsTE5Ot75wkLBE1BvvtXYhM2BmnL3btRe41QazazeCYaBBO XzgiS2Mo4fScUJXfK9Oy2OYsNcoAmlpcklchx8anWcNlxnFcfbd+rbdinpVCWI/bWPvi4wqBPJT9 wHWVz26IYW7KCMBCZQErwCVaepQ67grTMVS8SiYPA48GG77XhTaJd+aE3giNTjwodSs+Evk6rBNU u5z7rfJEnoJi/hzFhPalHs2sViUJWdmd1zaBrbYss5m3PtmqscJXz4YnlMoKjaMUC2NzUZXUwaCe gAx/PpudcrZLeKTuyaJxn/bIC1aKS6dxWhJ13a47IHk90tfYZzhB1g31tx0waDU1Tn1rJK8Og2Ei JRn22/HCNweboqANZTEQ1btCxtZT6fVKl5aNnnpB1dYf0GtzvBEbKo2Kj8vwsj0VeXV3uOSsJHzf 2EOcd1tbhd4mvfN+5QmF/yIt7a244ETafJjqXoE/YtO/gFs38VGB10ma/hNVYPAx1sakDyfG5Y7m iZNDfzswe+1849wofvP742yyJmln0NrZeX5tE5fNZiN91NElI6aSc9OqoXFw9niydB0fm3w7E63U 31ll8V5+9Hg9KvV88G0xcXBSdvZinV7taYOPyWt9KVf4paG5So2xVQaXP/M+9QV/ayAVPsyqsfVj IvPiZP5Ow5e51ur69L63dzGxsHSu8aV4TarxpVPnfrD1zdGT03OZP73wpTTfUlZ29mb2cPfJ24Zf Znb7dn/bjt+LOz2zcFY5pdFn18e49eX+yXWNX+aDh8cnVerqNfWgdNOZ36qldYocX2bcCpnWUc9D G3G6NIqTPHhblbwxs+F4XL/x4SYx6PCmsPT4/CWKfTP9Rw3Z7xO95caUmWYZul26wat1q/DQmbjS j+bfnUJH8EFvt2YeG5vpkZ2r7Gsm5/wqez6alvCbT+7VoM2Wl9wAcm99ESAlgnv1273PIGXnB/YX nIwEhf+9/yAT0/+b/oPM/1v/QZb/8/0Hmf+P9B9kIWBh/R/2H/zvL2f53xsMMrMyM/zPrjEZjVll Q1t/UNVlFZapXyK6My02RiXfTe7bDy0to6I/oyFAjGGQ/vZdsKHstfDDZKL9C2VwebJwWsJPnbXB 5kOcvZ2rq9vKyWaOpiAtUyADqmL1GDSwje5nLt49/CUbvOylCRF66puQTKcM2HtjUtihesa4sb7i bjrIZ56ARzZrmULff/B6xVpt1iGmc4w/H3xf1KfOXqIwESKRik5e191Yg6q5ihewiqtcnsZRbGyT ikXeGMFiHfNe/QSbTe6mEjxODw8J4JkVvB3syVS0OKxjhbRwqSmhy6n31LJqbFHYMdVODfEhTnWz VzHr5hxHjpeJJUuXjRV97Z7kNjgPmVx9XVcV6n9klomwOp9Q+cFdXVqmyGFs0qqYL8FlfXNTyDIZ ticvpvjdRNhMPqzaCjCJkEC8UUAPe3fkFzM6ETdTt6P5Q08GzcnqKes5T8MKbnOmg95r3G4NDOw9 xVPSsQCvHy+fj9zELqY1EaW4eAFqucjiV4PwxdpLh43j0f2P9uBevpcqmWQkh7WS9LM0JGd6DW3q 1foLzZQQ2WMa2ZxYkcJw/2cyGEFM8Bozx6QJv0LiI8nqeI7x+hrhZq1fZVikko7C35hIwayVFgZl 2ESljihkycEE5jB4maziMa8PBF8U3+C9MujWXwsnrfdruUfMo2AmVuLYaI2Hn0Rb1Ehk0mY9U5bA 04XQJZYl+J1Y2o6AdNQXU/LbYhldzPWk1qczmYiqfdDZnnrJj/OQq6w/8p+YnuAwslcLnASSXPMr lRwQKwbWcrJqEVBkL6+qeIrk0Z5WdnUXnb135m7UM50wpR/gqp71AqpfYLCfv0MepmcohUZevShH VIcKhzhowzZf92QqK/MySU2thTGM2CyotC831oocirp+p8S7+2orFmb2oxjlRk6N9PlN+COOuzj9 4JqVFaKb8esZTQbhY8dJTEPeTCzH6he15nJI/vHSDUpgyX7TgNTrb7kovHgY1S4iQEDCFzT5sR3r ibBGzpc3ivInwWyNtCeTQuxMEvI+yjPlrNoiWj2XRpR2C6FqPChFkR+09B2P50mYJxXmdyF+BhuM 9mHLK6L1B7SlJn7och7XzOZB+IYO4odhlrDOjitnnt+AbLc98qA1uElf4siplp9FviV6wviOC/fm a/d2qLoP4mzzQGweBfHviVAbjg4/FEWsyJjIX2ePkuIHm1jIMslehhEEBCT2+OXZvreR4L6m8Jjs eC06w5LFjyORduRN3liCNbhC2WwizzztcEIekzDQ7T+TakuDIBLlay+yLB2bZ0F1+bdIYutQH7cE tgjnryKLFHz0DGJ8H40+s4Xs9IgJ3AnpCdv6wjsNHOlE8jbMtTpk+GE7uDd+ds0aIK3RCYpdgAPT eiLxQ6yYrEhQPwCWYRqc7Uu8MNYbBmRStJwty8EC3lqSp8HpNLcWg5ATuTY3YTWF4EdB2k9HnXAJ iFbUUcMonumd1xV9nd/M3V92c6y/bbfmWgokZgHMKRpNSyNj9i6UVw8SKAsduCh9sZuK4+zbZlf1 Io/iMwUymQ9HcQVmS8TzH1wx9X+5zabVCfIdQbbHT3OfRal04+/fyDdnmaknpIDFlUcPRKZNC4hz 2cdrBlsKpfrIqMqDOI63cexa4bQy0iWGZsVcZh0TN8j1dkC62JWXiLeZexrJJhw5Jckh1mXFD+z+ pvyOJaqpJq7gfx8+OUSFEB4VhLQmoMQoXI1DAsKMe06ZFXSIzh3K+N1MDYgBGaEYZRX2TVBkDFeT B1ytURQveO0HQvWoIlAPmhzYx/Sl5hxOtBJUvjh3GzTkl3JrjXrxw61wUhXI1kotUemP+Afdb46L IVJhbeR0ZqYlduh+XZaEyBx6qBEpYAFOdQvgFBW06c1aZLwhG92n5cz3y5lOwkyXDN/8HLpG9K+Q GUkcKQQwY4pV19WEIsla9c0Frszn8uhvRfilBr7Noeja8k7c/2zWIaOCtfNfvX74MrQir6d5Jrje LCFlEo6cG7w0QbP8/WAUxNfCIWWL9AnqJwn7Dnrq+rBTmZsAQ5T1tuiiTv60jWWor15GVMcbSXsv 2Yve1LZNMmtRDilJ9FewJqmqgBqygAMy1/l4DL9ky+EQ5xYqs6DkXRLGxy9xU73HBJIfQsSQFgRW aTPNUNWuV3A308Z+uAiUc/00IwWH3K9OxxdrpHV2KJaSRHgztzmCuv7ZxbzjjClD6QqYqoHNQCNC IqEzeZalXh1wcTCBYmYp/6pDLizLLr9MDvsoA1r/ymNuf8F1PR/DAJsBFpiCtt3WCiKC99/bC+ek 2hPPkvouXNtw3Rd+qUN53M0ZR1lmdu7CkFRmoSY9SIR8THwbZFszCpQOV2ew17q6nF4MAmRW03Do Yx6lnjkGQAth804xw3lK4J2/5eIN/3smcBjq6U6oZqTvsKJi+FSP8mI17Y7LnlNnxyDRIVxAIrOd YaZguNRUvxBkdMzm0dLSeGcgAIwI9Bj7LOhijUNtsiqaiIOeE+hqksuLWQOt6Oi4ayTTflvVTLUE agEiu2/7ljfoFupN1M+UWq6i3zyU4N8SOCp9uaR/fs0xk6XY0pXt1HCNS3hDm0QHCXeQ1bbM1BeW KJBsM8wwKap8HmLJsvLCW8XpIlQ0chp/OKqr76kYppONuhRxm/U7wYK9oyxAk2rdAbPgJViFR7XH Ca7jRSV9VbDHAO2qo3TR0VxSAGSTgCbb3RMzvnWAK3Nl3kWm8Ingudap0o79ARvjmfWCiapfiNOf rXDSsTusY+HnWL0ovcPNF8SRKET0S2c+ERR8yMppa8QvLDvBcJ6V3l4P0V/MdPjkBw1DsGeKSf2F JvrpT9boAfKGT+6+d9hdfXwim5ZHLNQLbq4FsiTJlQm3U6CIV4cRhpHrRuFi5CkTGCM364eADO8P mlDL0LPTFmYpBaUv6pe6TlPBRAPCW5tRG0IhmVX5p4Y3jbAPniSfQefQZUxNMUoPIirBm9cD7Htj 7sIAbQYaL7kq6HBXcFiySV/oPapt4OtUgmNkjgCF3jqBdVBFDCw1Qg7I7Pz5OhUAdJuA6RhmK4dU iaYgdks+wBxrFWEAExShqC6J9NCnb4D2lh3+DbeWiFbaEYDrVqZpfjv+1bgFmVGAEbUJsyRp5GA3 //J8Ne3AgMJaOID/7TnkAXggsgAYIqipzaA4gOImJtw0l7KvHfJ+IwHACQvRCIfo33aI+pU7H2Q/ i7gaPzmAF2jRFJKQA2JZeaYv+pcc032TqJTxmm6r4Gzqiny8MoT+mO6flgI6qtPbWRDRdPogtG2U QYo8CdjLlSRxXiuOpx6jrh8p+BoxxrhS5gfXJ5HgCBZyfgE3+iVBdr+QuxQP//liVYfr3WHScZ2D LCPM7W839QOo+xLQma+8iNv12B4GoQvfJI/YxcuRAGJ79KorCQ7tFvNLkctHpoYRj/LVSnHp6Gni tcAC+BIFW15cj8GY71Wja6/zZK02vLF6100e3XZueZiZyCN+0sUgNpkyYO6iJ85ccl2/DTUd3dbP q1MeJAh+HCQ28U1yMjh/OgPkCvUnEllJ9RL1fqKTXGiCUwhLiOU576zjXNAHkg5YqxmI/NVG5VIu 7TaqRWXEOjYCVVbeT45h0uNuMHK1X+lYM2xPI96Cnfk3zosDZILRRIjlQDob5402zJWt4rFQhWbu TS6LBJjjPEdWE+HEWuFQtppj3/ycDYjf8daLHBTPLDfHFfzBnSLvLqt2YHTWfcCozfrn1jKS3kU9 g1omsYZh8A77dEWl8PmSqh3HTpm6RLlCCLnXwK1WZWaaMTqDia3vgOxOeMPND1pmCa68CNhtyuXG wFGujYhDVWbUT4nkxDwjMUHm5vH7ax7F91vXltoKuWgbVMmJgX49PO5Gq7ZvF4GCvBcEHLisfb/S sVucpBdI9cOCiQAhYbmn/XksIDJYGZuw4FUdDbviV+0AoSbCVvAYGFNhkV8BsDHKyfvDehGZl1+C J4v04zkvsymJHcxI9X2/RXDtK5zuLCVJtx5qHNtLEzus/pIRc0AsHoFF711q1uFQu6jqv9mOntsh mzySGcM9gyXmhj34Fvd0LScwAPnNDdyP+Ns7BKRufkSXWiEd5EIvp4RbNieB9zL+DK59LyMUoj0q WxJnw5eAjZofD270c6s46oiFVRLUzv5Lf970gKMXIbH2GJ6a9v9XbVceD3W3xluElgnZijAi+zK/ +c1qS3ZZIyo1xhhDU2OGMRQt3mQnkV6iovBKJjVky569QigvN7xUkixZEiXqzvDebs30+dz7ee97 f3/M+Zzn98x5zvM855z5fj/n85lnm4l+WOPt9rcPHzx8K7rNjhV4ADp9UaLoXqwJ2qJVu9BJDlfd xfdUaHRDV6PXNqWwnCnNRNiOXypdS95pH64OjTTET2+tDk9HhD6ue/RURPKMQWZrJSv1g5RxvflW +ocd1zardxwZaZ69niH92arB+cumA60qV6FJV/ckNJ0WeVYkvfnt6IfMp6PGLUMNyfKy5X+UY07s bbj3wuS4i+BSjttWJav6jZrNoIJTYoRx/p7dAhP0QUfrsiB8qbUCvogur9hdeu9Y73vNLUGmVUzR 6pGLbaP5hU5nWuNzsvmlX2fhqwsKmsXnFjXNP2xO7DhSn+07MGfvLO388Bz1QKZaxcnH1SW6lIWr N89/EQs5XqfEuCPn3G4jmf8yfiwzNWaDXlu4z+0rm8sbaowF3r4mF2icGX9YaK3+QS1A2uHtpSxp d5EDXgK7u8HCvEbLTf61zOrde39/Mp1MwQs7ChK3oFZFny2m6ZCWvvQ1P9WxcVa+bCm74OT64K3r 2mqUlbaozgLQITk8Mv9806nWmcL+Kj3hjMbnhpuSOpPNutO/bIStsh7O1f8JV0b+Fa6M4uHK/1L6 G7nyD3VL/wuu/L8T5O/qkf77H/gBzH9DkGP3Pw54hZLoG1N/d/Fq5JEQWput9vHeJEqDg51duq0E bJ1VrKrDCwWZN7u89KvhkkIOO/IMEsM0o/hWZ1D7c9eELY3UNUHCTiMz4mub+aXXjBpu1bWf6Xh8 pEzmdKnv2do5kkkDTnqqbh7KUPXF9chOp+h/8U5MsKHohk7Md6Bf9Z6aQwYEIzWVC3FEo6kYmrRf leUF07YmVud+Tz7PiHCZxpoZGb1opqvinTNI1d/M6qI+jc1RxYS118RsESj2O6w0pVfUMmcv0frF 5+jRA+9nflO5oGGHEdNmIXEDKgddr0UXFA8p9gYPZtqK3TJPHj+fzNKKKbOIvh1Sm1U1HfExIrn6 siyy86JXRa4bNjBHsG+YflEInbbGuCXb0yU5+420qdEg0VnvfRamNth9/4Xf203rzUy8pxcatw7r vWjyOhzRmG/VMkFTiAmqF5JhbTfqkvUeLbGnyzqGdvpTnvQcGZTg83pBSp20/FqZY9yHeWaVl3rb VtS5a2ofArk5HCHA7+cMWmmNJV4Ol2wu2yfpg9+g0iMyj3sPf/NhPuPUxKSqYgKzW55l0HLDYEot r5F162BcUc9D8aEc6mrkpzd6yGubJ9TyBlpq5AaNuqo0nBY2S+zagNA4rhG1Y3XMZHhjtfVofXgj /6TYE6cEhZLoU0+YOpo+3UrnfU2bUNEM5YMhseVGWkB5glggTiLltg41Y223gixkNg1dIud1gSlu kiCVsXfaUowRlob4zP/gpq/YW7iA4uy5mCV7Xeo86NS7fmlkIcAjRu+hRNT5vG1BmBqUm0uBzJMI jciocyBzvqftd9bHe8P3c7FwRcZLapMEvbVjaZ+8g7jbhFtUM0EfPsd/DIyFOMvlnvl0y6aWxfz6 tJWy6YIl7S7dUO7A9vBuY/PzW58lBdlGNCAC+LYGWN89BzhbDP4qv2XPnuGFd6E1hSp5cuJSH0Jm 1cYtfPO7NgbGnbmx+QFomN65tNtQdJvDiWcbkoIW+6XWT/rymXcY0NXrt1lONqdL+MtobgRGG9cZ Ua93jfXqM4l20KHw4g6j6ahVrl9jajyabJGOFeYw5wa/VEIyYR6f6Bgx6p0x/o9r4/3DDnavFa+U 5A43HbWAS1pmq061luI0JAQtPBSgUhD960ICEhdIPSlNxMRMVNQnpqwOcCN/oEh4qeF69WXi2bib ga8TobO6+1TyKyUu+YupmQrGFiGEIS366uJbwH6DY7eoJFx2uX4TalfaHtKqnIRu6IzL0Yy4YV2r +1ZBDqhEWayGPUlYw3V92OmXBx+lgWeKZbQ7vf94/9u9pYp5yfG0Hv9wF9G5+A2RzLMO7XHiBvJl V59WVvhK3JgK6r1vG5E+S4kawAn0XzGxXcqWuj86H04S7JurWXeiVNK7orsm86xWu3HCodqTwqgs yw5FAYKloFFIqChermjndkyvk9dsTqapXH6D86IPM+bzZoTYQM7rV/9IOjTb/muYQsXlZ8hmwxaV acqbr8T7BGyf26eLhXuigRalkYBFxotXayne5UXM16Nf3qiYMcihMr3PP8qc3Rks4vkR7xr9Ttc8 8+Qa5tAfWWkd+8gzQVW+ymXbrxRK4Um5d2UWDyPyty/2QfsDVdfRLBDKRz/bPPOL06pKnuh8VFoa TJYs3ie/dmP6tMKTok630Vq+VbK+hLKUujcRvcF1rywjV9tmltX8msLfaiJ2KOpRjd7p5+L2zT1a pvdZVRZOt1g34mXU1AUrg42SBk028Fvp61pIqWu0nxuldKya/mD/wl+pokz3uOGhTCc4MVDr/ZpF qJdgj8+TyTH5jgwd5Udtlq420VduvVBqZcl+DV2v5/N0OnYSppovfzTtmc3D35pO3YkX23rotnoe a+iN4K8P3N5te7TLlu7ktCa5ipagnX1BRynDNRmnqT9nnRfXko7euPdwh9XHkK3VpT6luwf9jUpw Alf4Pnum0R8MV767opuEfq78bLDKhjUzYe4d5u9yJZ9onTTjWxGtLoLf8lEZ2B58fejAQioMgxvo kTTf8uR4+Uu1wVTKphgUEHlr4IDr+D3P2D3iZd6VtJbI3Kx8j2PygcTS7tyPliKPd8pnV298fQ9X NDUODXm4dL8IPY71CtR5F1aGlZXv1LFK2Ju4eNjPlyEcb51b8ioh02sny/r9fmZwaEJsys3Ps320 6EAzzcUkr4OJ+XS3isktWi4oyKt5PhHy4Piou0X1YXeXrLiBY15C1/p0dQO3f8bBNxndZd70D3x+ UNJJ0U6XKnxcCdGw1uzs0QRI0UZS7+RIBXKpRmVdUzv+AnlnbSqUfL5ccJOJBc28FtkerIfcG3Tr 61DqF6JpJkowsqc4sKxLQHG9srFU3ok08Qw546wpZlbQfksssGDan0bfkbsGnxMYl69v5gs58vjw aHEp5eidNenx2dohmVJXlBUdT8vzfyq/PBzfPAa7OLe+pDk819mrInWy0ainfW/MbeyM845+N3vi c/U7I3dQyp8XNL8We9SFwZgf6hnnXpfVoy+NsZBddx3DoiLKacZT+58Z9rq9zJqPMAzrumtxssNT qKw1W6D4q9ali13BCgv+ym3r+KvLWFNrf4e/l/MfFknh84m7rt/h2lyUl5AgcvVYwZSLFv7S3e5z 6XJY78pZvx6zguGPkV237g0Qs0WZJ06r2P5S0S3kjk9L3Vie54Kf/IjBXitgYvuUi4MNHrUFdhY4 J5PyZZZoq+T9UnJ+ApwwUB7gtIxFINqO/u6M5T5HCnAACJWNGMhUL6i2DYHoQPMmUL9JINpGBD/S 8hfZaMqfTibRNY1oFI8fgclPCir9Z1v7ydTdVD/yT01ZkCgBJAaZSPjBDgj7v9nhdQoE/n/G7Nwp ZF9/0o/2/nUrdIiDRQkUB3OjZTy4/wiZQbKnkakccAnTwiJhSCgABbRgGCwbYGqbE7y9Cew3cC04 +wF4Wg4GtSEw6ORlYKuFADjXLFpwgANftWAAFmQ3IBLN6aEBJKc0lhYAsHEvu8GwLbF10Jz7qhW7 uGVUCcF9mzP4F2IEIv/E4v+OjGOgtzuNwhmC5kQlL8NX8E8M/32EEH93RvaRvUl+y6m3ZBAoZOKP 5n5CPb4bxYTs6UliMxAO4TjEzog2geJzhMCJ9/djfEcSforSv+F4AOBC7PvigQvnYJvCjp8Ja3JG h84617cHEEZwTu+oQlG7EyJFU2BTk9o3Cp0iDhTgDSq9Yhz9qM1mwvvnyhoEK3fWYT6lII0izu2M F4A5N+UdYgao/WLhU24tgjOujMhVq9eMchxaFzDxUmfXmUsnhQco8ZoQ1ueE6mBye5t87Ej8jkv2 3W4s7fq3GbXJ9MtDENwbOjjLf/M6oiBj9Q010mlti2HcSWFcMA2PZ868VxnbISKkWReYeLMkLcXx tn8/cm+b2/p0yfUGHo8Xo4NX86+yuEy24z2iQDRvgDnczo/dsyJ7cMKKWKmxtvK5wp5WmBywUo4N WLl9BFYWC7BS9Qy+Ur8M/uc6W+Z2NH92voEfGRz4wxFpzJ4ag0yjmnCImIqJDhwGg8MwcACGRaIQ oOoyxfPwJ7ITqLKbSKe5ExhQE7Ifg0yhsEUILfbu8KTRoezV5kE77sdWt6F5/HwodRhGGQZTVv1+ KifoJE8IDApioRDYtweKQiLZi9ATsmGljwQw7EAsv6F+k4Gcc4NLhkChuWVYOIJHDwtydj+XDMlj AwCRcG49AEShETwyDIrbBoDGYDDcMgyMZy5sz5AoLhkcQCOwPDIsjHsucHZsueeMAGAchs0lA7Dc 4yE4jnDLUHA0jx47b9x2ESgkhlsPhcJguMdDoWEI7vmh0ACK2180DI3m1kOzE8ftBxqAgdx20SDA sw7QIBwB45GBCO68oUEEkts3NIhE8dgF0TwxRYMYJK8My+sbAgby2EWAAI8fCATiu/gx6AQye3ux Nyj7iCcHsX8VsBBtS5NDegCARrN9BjAIAhGGgRFBJMnDE4TDsADRA01w9zT4zxo49v5jH7cEOmN5 8wFoELJzp6mdGeSfUEsBAhQAFAAAAAgAF08VLQffXiNqEgEA5iYBAA0AAAAAAAAAAAAgALaBAAAA AFRDUC1zbm9vcC5wZGZQSwUGAAAAAAEAAQA7AAAAlRIBAAAA ------_=_NextPart_001_01C28EA1.F56944FC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 17 20:20:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 329B837B401 for ; Sun, 17 Nov 2002 20:20:11 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 494CE43E42 for ; Sun, 17 Nov 2002 20:20:08 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gAI4HsAf058300; Mon, 18 Nov 2002 09:17:54 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gAI4Cg115181; Mon, 18 Nov 2002 09:12:42 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gAI4HpDx076969; Mon, 18 Nov 2002 09:17:51 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <006901c28eba$43829dd0$02010101@wall> From: "Dmitry A. Bondareff" To: "Karl Timmermann" , References: Subject: Re: Arp and Route Commands Date: Mon, 18 Nov 2002 09:23:36 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! If you need route throw router with MAC 00:00:ca:13:4b:54 do like this: route add -net 10.10.10.0 -interface eth1 route add default 10.10.10.1 If the network 10.10.10.0 routing by your FreeBSD box: you must add route on the central router to network 10.10.10.0 throw your FreeBSD. For Cisco ex: ip route 10.10.10.0 255.255.255.0 x.x.x.x where x.x.x.x - IP address of FreeBSD box. Regards, Dimasic. ----- Original Message ----- From: "Karl Timmermann" To: Sent: Monday, November 18, 2002 1:55 AM Subject: Arp and Route Commands > Hello, > > I'm new to the list and was hoping maybe someone could help me. These > commands work in Linux (and in this order), but not in FreeBSD/Mac OS X > as the arp and route commands are different: > > arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > arp -s 10.10.10.0 00:00:ca:13:4b:54 -i eth1 > route add -net 10.10.10.0 netmask 255.255.255.0 dev eth1 > route add default gw 10.10.10.0 dev eth1 > > anyone know how i would change these commands to work with the FreeBSD > versions of arp and route? > > > Thanks! > > Karl > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 14:57:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCA8737B401; Mon, 18 Nov 2002 14:57:38 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13EF543E3B; Mon, 18 Nov 2002 14:57:38 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0031.cvx22-bradley.dialup.earthlink.net ([209.179.198.31] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 18Duot-0002QT-00; Mon, 18 Nov 2002 14:56:44 -0800 Message-ID: <3DD96FC0.B77331A1@mindspring.com> Date: Mon, 18 Nov 2002 14:54:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert , dolemite@wuli.nu, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Small initial LRP processing patch vs. -current References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> 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 > Well... I have all those stats, but I wasn't wanting to type that > much. IIRC, we normally test with 80 byte packets ... they can be UDP > or TCP ... we're testing the routing. The box has two interfaces and > we measure the number of PPS that get to the box on the other side. > > Without polling patches, the single processor box definately > experiences live lock. Interestingly, the degree of livelock is > fairly motherboard dependant. We have tested many cards and so far > fxp's are our best performers. Please try the attached patch, with and without DEVICE_POLLING. The patch gets rid of the NETISR calls to ipintr(), by calling the ip_input() routine directly from the ether_input() called at input interrupt time by the ethernet controller. The effect of this should be that the input processing will run to completion at interrupt time, and therefore avoid input livelock, all the way up to the top of the TCP stack, but not past the bottom of the sockets layer (I have patches to take it all the way to the system call layer). What this will basically do is get rid of the latency in the NETISR delay for processing input IP packets via ipintr, and it should avoid locking out IP and TCP processing, if the interrupt load is very high. I've tested this locally, with no ill effects (so far). This should drastically increase your packets per second number for performance under load. It will also increase your connections per second number on the peak before falloff, by about a factor of 1.5 (I have been unable to load it sufficiently in the DEVICE_POLLING case to guess a number in the non-falloff case). The connections per second number will be better when connection requests run to completion from the TCP stack, up through the sockets layer (I will provide patches for this, after you have tested this one). The basic theory here is that ipintr processing can be delayed indefinitely, if interrupt load is high enough, and there will be a maximum latency of 10ms for IP processing after ether_input(), in the normal stack case, without the patches. Let me know how this works. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 14:58:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E6ED37B401; Mon, 18 Nov 2002 14:58:38 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA7CB43ED8; Mon, 18 Nov 2002 14:58:19 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0031.cvx22-bradley.dialup.earthlink.net ([209.179.198.31] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 18DuqO-0004uV-00; Mon, 18 Nov 2002 14:58:16 -0800 Message-ID: <3DD9701B.45721397@mindspring.com> Date: Mon, 18 Nov 2002 14:56:27 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert , dolemite@wuli.nu, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Small initial LRP processing patch vs. -current References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> Content-Type: multipart/mixed; boundary="------------1D72D59BF6FA248F67ED8B8A" 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. --------------1D72D59BF6FA248F67ED8B8A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Probably help if I attach the patch. 8-). -- Terry Terry Lambert wrote: > > > Well... I have all those stats, but I wasn't wanting to type that > > much. IIRC, we normally test with 80 byte packets ... they can be UDP > > or TCP ... we're testing the routing. The box has two interfaces and > > we measure the number of PPS that get to the box on the other side. > > > > Without polling patches, the single processor box definately > > experiences live lock. Interestingly, the degree of livelock is > > fairly motherboard dependant. We have tested many cards and so far > > fxp's are our best performers. > > Please try the attached patch, with and without DEVICE_POLLING. > > The patch gets rid of the NETISR calls to ipintr(), by calling > the ip_input() routine directly from the ether_input() called > at input interrupt time by the ethernet controller. > > The effect of this should be that the input processing will run > to completion at interrupt time, and therefore avoid input > livelock, all the way up to the top of the TCP stack, but not > past the bottom of the sockets layer (I have patches to take it > all the way to the system call layer). > > What this will basically do is get rid of the latency in the > NETISR delay for processing input IP packets via ipintr, and it > should avoid locking out IP and TCP processing, if the interrupt > load is very high. > > I've tested this locally, with no ill effects (so far). > > This should drastically increase your packets per second number > for performance under load. It will also increase your connections > per second number on the peak before falloff, by about a factor of > 1.5 (I have been unable to load it sufficiently in the DEVICE_POLLING > case to guess a number in the non-falloff case). > > The connections per second number will be better when connection > requests run to completion from the TCP stack, up through the > sockets layer (I will provide patches for this, after you have > tested this one). > > The basic theory here is that ipintr processing can be delayed > indefinitely, if interrupt load is high enough, and there will > be a maximum latency of 10ms for IP processing after ether_input(), > in the normal stack case, without the patches. > > Let me know how this works. > > -- Terry --------------1D72D59BF6FA248F67ED8B8A Content-Type: text/plain; charset=us-ascii; name="lrp1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lrp1.diff" Index: net/if_ethersubr.c =================================================================== RCS file: /cvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.125 diff -c -r1.125 if_ethersubr.c *** net/if_ethersubr.c 28 Sep 2002 17:15:22 -0000 1.125 --- net/if_ethersubr.c 18 Nov 2002 18:03:15 -0000 *************** *** 34,39 **** --- 34,43 ---- * $FreeBSD: src/sys/net/if_ethersubr.c,v 1.125 2002/09/28 17:15:22 phk Exp $ */ + #define TERRY_LRP + /* + */ + #include "opt_atalk.h" #include "opt_inet.h" #include "opt_inet6.h" *************** *** 720,728 **** --- 724,738 ---- case ETHERTYPE_IP: if (ipflow_fastforward(m)) return; + #ifndef TERRY_LRP schednetisr(NETISR_IP); inq = &ipintrq; break; + #else /* !TERRY_LRP */ + /* call ip_input directly, without queueing */ + ip_input(m); + return; + #endif /* !TERRY_LRP */ case ETHERTYPE_ARP: if (ifp->if_flags & IFF_NOARP) { Index: netinet/ip_input.c =================================================================== RCS file: /cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.210 diff -c -r1.210 ip_input.c *** netinet/ip_input.c 28 Sep 2002 17:15:25 -0000 1.210 --- netinet/ip_input.c 18 Nov 2002 18:03:20 -0000 *************** *** 35,40 **** --- 35,43 ---- */ #define _IP_VHL + #define TERRY_LRP + /* + */ #include "opt_bootp.h" #include "opt_ipfw.h" *************** *** 221,227 **** --- 224,232 ---- static void ip_freef(struct ipqhead *, struct ipq *); static struct mbuf *ip_reass(struct mbuf *, struct ipqhead *, struct ipq *, u_int32_t *, u_int16_t *); + #ifndef TERRY_LRP static void ipintr(void); + #endif /* !TERRY_LRP*/ /* * IP initialization: fill in IP protocol switch table. *************** *** 259,265 **** --- 264,272 ---- mtx_init(&ipintrq.ifq_mtx, "ip_inq", NULL, MTX_DEF); ipintrq_present = 1; + #ifndef TERRY_LRP register_netisr(NETISR_IP, ipintr); + #endif /* !TERRY_LRP*/ } /* *************** *** 848,853 **** --- 855,861 ---- m_freem(m); } + #ifndef TERRY_LRP /* * IP software interrupt routine - to go away sometime soon */ *************** *** 863,868 **** --- 871,877 ---- ip_input(m); } } + #endif /* !TERRY_LRP */ /* * Take incoming datagram fragment and try to reassemble it into --------------1D72D59BF6FA248F67ED8B8A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 15:11:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D84137B401; Mon, 18 Nov 2002 15:11:11 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E74F43E8A; Mon, 18 Nov 2002 15:11:10 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAINBAAh022558; Mon, 18 Nov 2002 15:11:10 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAINB9Hv022557; Mon, 18 Nov 2002 15:11:09 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Nov 2002 15:11:09 -0800 From: Luigi Rizzo To: Terry Lambert Cc: David Gilbert , dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current Message-ID: <20021118151109.B19767@xorpc.icir.org> References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DD96FC0.B77331A1@mindspring.com>; from tlambert2@mindspring.com on Mon, Nov 18, 2002 at 02:54:56PM -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 Strictly speaking it is not necessary to get rid of the ipintr() code, it will just remain unused, so the relevant part of the patch is the direct call of ip_input() instead of schednetisr(). This patch will not make any difference if you have device_polling enabled, because polling already does this -- queues a small number of packets (default is max 5 per card) and calls ip_input on them right away. The increase on the peak performance will be, i guess, largely dependent on the load and on caching effects -- one expects that processing packets right away will cause the cache to be warm and thus the overall processing be faster. I do not understand this claim: > The basic theory here is that ipintr processing can be delayed > indefinitely, if interrupt load is high enough, and there will > be a maximum latency of 10ms for IP processing after ether_input(), > in the normal stack case, without the patches. because netisr are not timer driven to the best of my knowledge -- they just fire right after the cards' interrupts are complete. cheers luigi On Mon, Nov 18, 2002 at 02:54:56PM -0800, Terry Lambert wrote: ... > Please try the attached patch, with and without DEVICE_POLLING. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 17:16: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5F2E37B401; Mon, 18 Nov 2002 17:16:05 -0800 (PST) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57FA843E4A; Mon, 18 Nov 2002 17:16:05 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0159.cvx22-bradley.dialup.earthlink.net ([209.179.198.159] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18DwzW-0002LX-00; Mon, 18 Nov 2002 17:15:50 -0800 Message-ID: <3DD99018.73B703A@mindspring.com> Date: Mon, 18 Nov 2002 17:12:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: David Gilbert , dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> <20021118151109.B19767@xorpc.icir.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 Luigi Rizzo wrote: > Strictly speaking it is not necessary to get rid of the ipintr() > code, it will just remain unused, so the relevant part of the patch is > the direct call of ip_input() instead of schednetisr(). > > This patch will not make any difference if you have device_polling > enabled, because polling already does this -- queues a small number > of packets (default is max 5 per card) and calls ip_input on them > right away. The problem with this is that it introduces a livelock point at the queue. I understand that this is tunable, but it is still a problem. > The increase on the peak performance will be, i guess, largely > dependent on the load and on caching effects -- one expects that > processing packets right away will cause the cache to be warm > and thus the overall processing be faster. Actually, the increase in peak performance should be the result of immediately calling the ip_input routine with interrupts disabled, and then calling it again, while there are packets pending. As the name of this patch implies, there is more to a complete implementation than the patch I have posted, which only gets rid of the NETISR latency. The polling code runs at hard clock, etc., when ether_poll() is called, and so it still suffers the latency in the DEVICE_POLLING case. > I do not understand this claim: > > > The basic theory here is that ipintr processing can be delayed > > indefinitely, if interrupt load is high enough, and there will > > be a maximum latency of 10ms for IP processing after ether_input(), > > in the normal stack case, without the patches. > > because netisr are not timer driven to the best of my knowledge -- > they just fire right after the cards' interrupts are complete. That's almost right. The soft interrupt handlers run when you splx() out of a raised priority level. In fact, this happens at the end of clockintr, so NETISR *is* timer driven, until you hit an interrupt saturation point, where no soft interrupts run. If your interrupt load is high enough that you receive another interrupt before you are done processing the previous interrupt, then you never get a chance to run soft interrupts, at least until you run out of mbufs. That's why the normal packet processing throughput curve looks like: | | ... <- Receiver livelock point | . . | . . | . . | . . | . . |. . |. . |. ......................... +-------------------------------------------- Polling changes this somewhat. The top end is reduced, in exchange for not dropping off as badly | | ... <- Receiver livelock point | * +++* | * .++ ++++ ++++ ++++ ++++ +++ | * . + + + + + | * . | * . |* . |* . |* ......................... +-------------------------------------------- The reason the top end is depressed is that the polling is not load adaptive. Instead, it is fixed overhead relative (e.g. the use of the hardclock to effect calls to ether_poll(), which then calls into all drivers, whether they have data available or not, to fetch state across the PCI bus to ask the cards if there is data available. In the LRP case (or at least the case of the patch I posted), there is the same disabling of the interrupts so that the stack can run, and the poll occurs under high load, but (1) only the cards that have data are polled (through hardware interrupt handlers plus soft interrupt coelescing). The net effect is that you gain a better efficiency under extreme load, because it switches from interrupt to polling, and then back again, based on the load. The assumption here is that network processing is as important as the interrupts which result in network processing. There's also a cache line win, as long as your stack code that you end up running plus the driver all fits into L1. The thing that polling buys you that this patch does not is the ability to run to completion up to the socket layer. As I've already pointed out, I have patches for that, too, I just want a measured performanc delta with running the IP stack at hardware interrupt vs. NETISR. Basically, this means that LRP will have two less latency barriers, and one less stall barrier than polling. Since the overall measure of networking equipment is how many packets you can pump through the thing in time "T", anything you do to increase that number is good. In any case, I'd like to see someone who can load to livelock try: 1) Unmodified FreeBSD-current without polling 2) "" with polling 3) "" without polling, plus this patch 4) "" with polling, plus this patch FWIW, I expect to still hit livelock at the high end, since the processing up through the socket layer still happens at NETISR (the patch only affects IP stack operation). But I expect the removal of the latency in processing to push up the high end before the livelock occurs. With polling enabled, I expect only a minor change. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 17:31:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8036637B401; Mon, 18 Nov 2002 17:31:56 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E6F43E8A; Mon, 18 Nov 2002 17:31:55 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAJ1VtAh037083; Mon, 18 Nov 2002 17:31:55 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAJ1Vtnu037082; Mon, 18 Nov 2002 17:31:55 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Nov 2002 17:31:55 -0800 From: Luigi Rizzo To: Terry Lambert Cc: David Gilbert , dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current Message-ID: <20021118173155.C29018@xorpc.icir.org> References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> <20021118151109.B19767@xorpc.icir.org> <3DD99018.73B703A@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DD99018.73B703A@mindspring.com>; from tlambert2@mindspring.com on Mon, Nov 18, 2002 at 05:12:56PM -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 On Mon, Nov 18, 2002 at 05:12:56PM -0800, Terry Lambert wrote: > Luigi Rizzo wrote: ... > > This patch will not make any difference if you have device_polling > > enabled, because polling already does this -- queues a small number > > of packets (default is max 5 per card) and calls ip_input on them > > right away. > > The problem with this is that it introduces a livelock point at no it doesn't because new packets are not grabbed off the card until the queue is empty. > > I do not understand this claim: > > > > > The basic theory here is that ipintr processing can be delayed > > > indefinitely, if interrupt load is high enough, and there will > > > be a maximum latency of 10ms for IP processing after ether_input(), > > > in the normal stack case, without the patches. > > > > because netisr are not timer driven to the best of my knowledge -- > > they just fire right after the cards' interrupts are complete. > > That's almost right. The soft interrupt handlers run when you > splx() out of a raised priority level. In fact, this happens at > the end of clockintr, so NETISR *is* timer driven, until you hit i think it happens at the end of the device interrupt! > .... > Polling changes this somewhat. The top end is reduced, in exchange > for not dropping off as badly actually, this is not true in general, and not in the case of FreeBSD's DEVICE_POLLING. Polling-enabled drivers fetch the cards' state from in-memory descriptors, not from the interrupt status register across the PCI bus. Also, they to look for exceptions (which require going through the PCI bus) only every so often. So the claim that the top end is reduced is not true in general -- it depends on how the interrupt vs. polling code are written and optimised. > | > | ... <- Receiver livelock point > | * +++* > | * .++ ++++ ++++ ++++ ++++ +++ > | * . + + + + + > | * . > | * . > |* . > |* . > |* ......................... > +-------------------------------------------- > > The reason the top end is depressed is that the polling is not load > adaptive. Instead, it is fixed overhead relative (e.g. the use of > the hardclock to effect calls to ether_poll(), which then calls into > all drivers, whether they have data available or not, to fetch state > across the PCI bus to ask the cards if there is data available. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 17:52:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 428DA37B401; Mon, 18 Nov 2002 17:52:48 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B55A543E8A; Mon, 18 Nov 2002 17:52:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0159.cvx22-bradley.dialup.earthlink.net ([209.179.198.159] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 18DxYn-0007Xb-00; Mon, 18 Nov 2002 17:52:18 -0800 Message-ID: <3DD99877.2F7C6D12@mindspring.com> Date: Mon, 18 Nov 2002 17:48:39 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: David Gilbert , dolemite@wuli.nu, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Small initial LRP processing patch vs. -current References: <20021109180321.GA559@unknown.nycap.rr.com> <3DCD8761.5763AAB2@mindspring.com> <15823.51640.68022.555852@canoe.velocet.net> <3DD1865E.B9C72DF5@mindspring.com> <15826.24074.605709.966155@canoe.velocet.net> <3DD2F33E.BE136568@mindspring.com> <3DD96FC0.B77331A1@mindspring.com> <20021118151109.B19767@xorpc.icir.org> <3DD99018.73B703A@mindspring.com> <20021118173155.C29018@xorpc.icir.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 Luigi Rizzo wrote: > > > This patch will not make any difference if you have device_polling > > > enabled, because polling already does this -- queues a small number > > > of packets (default is max 5 per card) and calls ip_input on them > > > right away. > > > > The problem with this is that it introduces a livelock point at > > no it doesn't because new packets are not grabbed off the card until > the queue is empty. It's still possible to run out of mbufs. > > > I do not understand this claim: > > > > > > > The basic theory here is that ipintr processing can be delayed > > > > indefinitely, if interrupt load is high enough, and there will > > > > be a maximum latency of 10ms for IP processing after ether_input(), > > > > in the normal stack case, without the patches. > > > > > > because netisr are not timer driven to the best of my knowledge -- > > > they just fire right after the cards' interrupts are complete. > > > > That's almost right. The soft interrupt handlers run when you > > splx() out of a raised priority level. In fact, this happens at > > the end of clockintr, so NETISR *is* timer driven, until you hit > > i think it happens at the end of the device interrupt! It happens at splx(). THis happens at the end of a device interrupt, but... acking the interrupt can result in another interrupt before processing is complete to the point that soft interrupts will run. See the Jeffrey Mogul paper on receiver livelock, and the Rice University paper on LRP. > > Polling changes this somewhat. The top end is reduced, in exchange > > for not dropping off as badly > > actually, this is not true in general, and not in the case of > FreeBSD's DEVICE_POLLING. > > Polling-enabled drivers fetch the cards' state from in-memory > descriptors, not from the interrupt status register across the > PCI bus. Also, they to look for exceptions (which require going > through the PCI bus) only every so often. So the claim that the top > end is reduced is not true in general -- it depends on how the > interrupt vs. polling code are written and optimised. No. That's more of a side-issue, and it's dictated by the hardware and firmware implementation, more than anything else, I think. The actual problem is that the balance between system time spent polling in the kernel vs. running the application in user space is based on reserving a fixed amount of time, rather than a load-dependent amount of time for processing. I understand that DEVICE_POLLING is your baby; I'm not attacking your implementation. It does what it was supposed to do. Things are better with polling than without; all I am saying is that they could be better still. The reason I asked for the second set of numbers (polling with/without with the ip_input code path change) is actually to support the idea that polling and/or additional patches are still required. You really want to achieve the highest possible throughput, without ever dropping a packet. If you drop a packet anywhere between the network card and the application, then you are not handling the highest load the hardware is capable of handling. Polling only deals with this up to the top of the TCP stack, at a cost of increased latency over interrupt in exchange for reduced interrupt processing overhead (you get to wait until the ether_poll() runs, instead of handling the packet immediately, which introduces an unavoidable hardclock/2 latency). You avoid interrupt livelock, while still risking a deadly embrace waiting for applications to service the sockets (hence the need for scheduler hacks, as well). When it comes down to it, latency := pool retention time, and the smaller your pool retention time, the more connections you can handle simultaneously with a given pool size. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 18 18:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9500037B401 for ; Mon, 18 Nov 2002 18:45:03 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0FEE43EA9 for ; Mon, 18 Nov 2002 18:45:02 -0800 (PST) (envelope-from archie@dellroad.org) 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 SAA61829 for ; Mon, 18 Nov 2002 18:36:35 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAJ2aZOS053951 for ; Mon, 18 Nov 2002 18:36:35 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAJ2aZNV053950 for freebsd-net@freebsd.org; Mon, 18 Nov 2002 18:36:35 -0800 (PST) From: Archie Cobbs Message-Id: <200211190236.gAJ2aZNV053950@arch20m.dellroad.org> Subject: MPD/PPTP hang problem: try this patch To: freebsd-net@freebsd.org Date: Mon, 18 Nov 2002 18:36:35 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1037673395-53853-0_ 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 --ELM1037673395-53853-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII For any users of MPD doing PPTP with MPPE encryption who are experiencing random hangs and/or seeing the "insane jump" message from the kernel, please try the attached patch and let me know if it helps. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --ELM1037673395-53853-0_ Content-Transfer-Encoding: 7bit Content-Type: text/x-patch Content-Disposition: attachment; filename=ng_mppc.patch Content-Description: --- sys/netgraph/ng_mppc.c.orig Mon Nov 18 11:53:06 2002 +++ sys/netgraph/ng_mppc.c Mon Nov 18 12:02:13 2002 @@ -95,6 +95,10 @@ #define MPPC_FLAG_ENCRYPTED 0x1000 /* packet is encrypted */ #define MPPC_CCOUNT_MASK 0x0fff /* sequence number mask */ +#define MPPC_CCOUNT_EXTEND(x) (((x) & 0x0800) != 0 ? \ + ((x) | ~MPPC_CCOUNT_MASK) : \ + ((x) & MPPC_CCOUNT_MASK)) + #define MPPE_UPDATE_MASK 0xff /* coherency count when we're */ #define MPPE_UPDATE_FLAG 0xff /* supposed to update key */ @@ -105,7 +109,7 @@ struct ng_mppc_dir { struct ng_mppc_config cfg; /* configuration */ hook_p hook; /* netgraph hook */ - u_int16_t cc:12; /* coherency count */ + int16_t cc; /* coherency count */ u_char flushed; /* clean history (xmit only) */ #ifdef NETGRAPH_MPPC_COMPRESSION u_char *history; /* compression history */ @@ -466,7 +470,7 @@ /* Initialize */ *resultp = NULL; - header = d->cc; + header = (d->cc & MPPC_CCOUNT_MASK); if (d->flushed) { header |= MPPC_FLAG_FLUSHED; d->flushed = 0; @@ -556,7 +560,7 @@ #endif /* Update sequence number */ - d->cc++; + d->cc = MPPC_CCOUNT_EXTEND(d->cc + 1); /* Install header */ *((u_int16_t *)outbuf) = htons(header); @@ -576,8 +580,9 @@ { const priv_p priv = node->private; struct ng_mppc_dir *const d = &priv->recv; - u_int16_t header, cc, numLost; + u_int16_t header, numLost; u_char *buf; + int16_t cc; int len; /* Pull off header */ @@ -585,7 +590,7 @@ return (EINVAL); m_copydata(m, 0, MPPC_HDRLEN, (caddr_t)&header); NTOHS(header); - cc = (header & MPPC_CCOUNT_MASK); + cc = MPPC_CCOUNT_EXTEND(header & MPPC_CCOUNT_MASK); /* Copy payload into a contiguous region of memory */ len = m->m_pkthdr.len - MPPC_HDRLEN; @@ -595,7 +600,7 @@ m_copydata(m, MPPC_HDRLEN, len, (caddr_t)buf); /* Check for insane jumps in sequence numbering (D.O.S. attack) */ - numLost = ((cc - d->cc) & MPPC_CCOUNT_MASK); + numLost = MPPC_CCOUNT_EXTEND(cc - d->cc); if (numLost >= MPPC_INSANE_JUMP) { log(LOG_ERR, "%s: insane jump %d", __FUNCTION__, numLost); priv->recv.cfg.enable = 0; @@ -619,7 +624,7 @@ ng_mppc_updatekey(d->cfg.bits, d->cfg.startkey, d->key, &d->rc4); } - d->cc++; + d->cc = MPPC_CCOUNT_EXTEND(d->cc + 1); } /* Reset key (except in stateless mode, see below) */ @@ -666,8 +671,8 @@ } } - /* Update coherency count for next time (12 bit arithmetic) */ - d->cc++; + /* Update coherency count for next time */ + d->cc = MPPC_CCOUNT_EXTEND(d->cc + 1); /* Check for unexpected compressed packet */ if ((header & MPPC_FLAG_COMPRESSED) != 0 --ELM1037673395-53853-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 2:41:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3745737B401 for ; Tue, 19 Nov 2002 02:41:12 -0800 (PST) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0810A43E88 for ; Tue, 19 Nov 2002 02:41:10 -0800 (PST) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0.1) with PIPE id 2400010; Tue, 19 Nov 2002 13:40:57 +0300 Date: Tue, 19 Nov 2002 13:40:47 +0300 From: Nikolai Saoukh To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: MPD/PPTP hang problem: try this patch Message-ID: <20021119104047.GA262@otdel1.org> Mail-Followup-To: Archie Cobbs , freebsd-net@freebsd.org References: <200211190236.gAJ2aZNV053950@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211190236.gAJ2aZNV053950@arch20m.dellroad.org> User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer 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 any users of MPD doing PPTP with MPPE encryption who are | experiencing random hangs and/or seeing the "insane jump" | message from the kernel, please try the attached patch and | let me know if it helps. Been there and seen that (in my case at least). The problem still present even without mppc stuff at all. IMHO, we see the bug with critical path not covered by spl*(). In -stable, at least. The next suspect in my list is ng_iface. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 3:12:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C1E37B401 for ; Tue, 19 Nov 2002 03:12:25 -0800 (PST) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D41FE43E8A for ; Tue, 19 Nov 2002 03:12:23 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18E6Ik-0000at-00; Tue, 19 Nov 2002 14:12:18 +0300 Subject: Re: IN-KERNEL Proxy From: "Vladimir B. " Grebenschikov To: Darcy Buskermolen Cc: soheil soheil , freebsd-net@freebsd.org In-Reply-To: <200211040846.49228.darcy@wavefire.com> References: <200211040846.49228.darcy@wavefire.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Inc. Message-Id: <1037704335.1859.7.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 19 Nov 2002 14:12:17 +0300 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 =F7 Mon, 04.11.2002, =D7 19:46, Darcy Buskermolen =CE=C1=D0=C9=D3=C1=CC: > If you mean in terms of transparently forward/redirecting packets then ye= s,=20 > see ipfw's fwd feature. But if you have mean NAT functionality, see ipfilter (ipf(4), ipf(8)) > On Monday 04 November 2002 04:35, soheil soheil wrote: > > Hi list > > i want to know if there is any in-kernel made proxy on BSD ??? > > THANX > > > > > > _________________________________________________________________ > > Broadband? Dial-up? Get reliable MSN Internet Access. > > http://resourcecenter.msn.com/access/plans/default.asp > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message >=20 > --=20 > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --=20 Vladimir B. Grebenschikov SWsoft Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 4:13:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB64D37B401; Tue, 19 Nov 2002 04:13:09 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A24243E75; Tue, 19 Nov 2002 04:13:08 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gAJCCuuO098122; Tue, 19 Nov 2002 14:12:57 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> From: "Petri Helenius" To: Cc: Subject: panic: kmem_map too small Date: Tue, 19 Nov 2002 14:12:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 seem to get kmem_map too small panics when using large buffers with bpf. Is there a tunable I should be increasing? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 7:21:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF8A737B401; Tue, 19 Nov 2002 07:21:16 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2645243E77; Tue, 19 Nov 2002 07:21:16 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gAJFLFtX002395; Tue, 19 Nov 2002 07:21:15 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gAJFLERj002394; Tue, 19 Nov 2002 07:21:14 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Tue, 19 Nov 2002 07:21:14 -0800 From: David Schultz To: Petri Helenius Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small Message-ID: <20021119152114.GA2228@HAL9000.homeunix.com> Mail-Followup-To: Petri Helenius , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> 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 Thus spake Petri Helenius : > I seem to get kmem_map too small panics when using large buffers with > bpf. Is there a tunable I should be increasing? Yes, increase KVA_PAGES in your kernel config. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 11: 0:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E159C37B401; Tue, 19 Nov 2002 11:00:44 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B3E43E4A; Tue, 19 Nov 2002 11:00:44 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 11:00:44 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 11:00:43 -0800 Message-ID: <3DDA8A5A.1199C0A6@exodus.net> Date: Tue, 19 Nov 2002 11:00:42 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Subject: Bluetooth stack for FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2002 19:00:43.0751 (UTC) FILETIME=[F60F9770:01C28FFD] 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 Dear Hackers, The next snapshot is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20021119.tar.gz Below is a quick summary of changes o Minor fixes for various man pages o Due to copyright issues firmware file has been removed from BT3C driver. Users must obtain firmware from 3COM Windows driver and use BT3CFW utility. o BT3CFW firmware download utility has been added o Couple new HCI socket ioctl() that allows to control default packet type and link modes for the device. o HCI security daemon that manages link keys and PIN codes has been added. Now it is possible to pair Bluetooth devices and setup authenticated and encrypted connections. Tested with 3COM card/stack and Ericsson T68 cell phone. o Link key format in hccontrol(8) tool has been changed. It now matches link key format in hcsecd(8), i.e. hex string of up to 16 bytes. Please give a try and let me know if it works for you. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 12:47:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C369637B404 for ; Tue, 19 Nov 2002 12:47:43 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-173-135.hispeed.ch [217.162.173.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF1343E9C for ; Tue, 19 Nov 2002 12:47:41 -0800 (PST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from MAIL.NetScum.DynDNS.dK (ipv6.NetScum.dyndns.dk [2002:d9a2:ad87:0:200:c0ff:fefc:19aa]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id gAJKlan00551 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 19 Nov 2002 21:47:39 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by MAIL.NetScum.DynDNS.dK (8.11.6/SMI-4.1-R00T0WNED) id gAJKlaQ00550; Tue, 19 Nov 2002 21:47:36 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Tue, 19 Nov 2002 21:47:36 +0100 (CET) Message-Id: <200211192047.gAJKlaQ00550@MAIL.NetScum.DynDNS.dK> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave To: freebsd-net@freebsd.org Subject: Question about rt_llinfo panic in netinet6 X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: CABAL MODEM (all hail CABAL) X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No 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 [IPv6-only address above; strip the obvious for IPv4-only mail] Howdy, I'm able to readily reproduce a panic with -stable that seems to be caused by my IPv6 script interacting with dhclient, that normally happens after the IPv4 address granted by the dhcp server expires. An infrequent occurrence, but I can simulate it pretty easily. The panic is in a sanity check in the src/sys/netinet6/nd6.c file: 456 /* sanity check */ [...] 459 if (rt->rt_llinfo && (struct llinfo_nd6 *)rt->rt_llinfo 459 != ln) 460 panic("rt_llinfo(%p) is not equal to ln(%p)\n", 461 rt->rt_llinfo, ln); I'm unclear, just what is this check, and in what cases is it likely to happen and induce this panic? I haven't figured out exactly what my stf(4)-based IPv6 script that also plays with faith and aliases might be doing to result in this panic, but I'll keep poking at it. What happens when the dhcp lease expires is that my interface IP address is set to 0. Then when I get connectivity to the dhcp server again and re-obtain the old IP address (or, apparently, a new one as well), that is enough to invoke this panic. Thus I can manually set the interface IP to 0.0.0.0 and restart dhclient and get the same panic. The intent of my script is to assign initial IPv6 addresses, or update them in the event the IPv4 address changes out from under me, but my initial debuggery makes it seem the panic happens later, when I try to get the info about the change to update my DNS zone files, or something. thanks, barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 15:37:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0118137B401; Tue, 19 Nov 2002 15:37:25 -0800 (PST) Received: from hotmail.com (f116.law3.hotmail.com [209.185.241.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEAB043E8A; Tue, 19 Nov 2002 15:37:24 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Nov 2002 15:37:24 -0800 Received: from 66.38.210.190 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 19 Nov 2002 23:37:24 GMT X-Originating-IP: [66.38.210.190] From: "Vincent Goupil" To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Tue, 19 Nov 2002 23:37:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Nov 2002 23:37:24.0579 (UTC) FILETIME=[9CECEB30:01C29024] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter v3.4.27. This system act as a firewall for an enterprise. They need high availability. I have 5 network card, all 3C905 (3*3c905B-TX and 2*905C-TX). I made this setup in july and it run fine until 3 weeks ago. The first and second card are for the internet link (primary and backup). The third is for DMZ and the fourth is for local network. The fifth is unused (marked as down). Each card as is own IRQ (except the fifth that is shared with the first). The high availability is provided by the two internet link, if one goes down, the second take the load (change default route, ipf rules, ipnat rules and DNS records). This is done by a script running by cron. We can also do that manually. We have two /29 network for the first link and one /28 network for the second (we use alias on internet interfaces). There is only 3 services that run on the firewall: SSH (but only accessible from 3 subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one subnet) We begin to have problem 3 weeks ago. The firewall begin to have a slow response. I begin to have this arp message error (many times): arplookup 255.255.255.0 failed: host is not on local network arpresolve: can't allocate llinfo for 255.255.255.0rt We reboot the server and the network fast as earlier. I finally find something: when we use alias, we need to have at least one regular netmask (instead of 255.255.255.255) for each network/subnetwork. My error was on the first link, my second sub-network was not configured properly. I changed it and it stop to have these errors about arp but the problem wasn't resolved. The network continue to be slow until we reboot the server. This happen during the day. Now, it happen everytime. What I've done: - I changed the netmask (as said earlier) - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. - I look for IRQ conflict - I configure all interface with media and mediaopt. They not using autodetect anymore. - I chkrootkit and nothing found What I suspect: - I read in a forum that the driver (xl) of 3C905 is not the best for FreeBSD. I don't know if this apply to 4.6.2. - Ethernet cables (I need to change it) - We run SSL (with a lot of users) in one of our web servers in the dmz. As I know, SSL run on top of TCP, it should not be a problem. - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not promisc" and "xl1 is not promisc". I have 5 interfaces, what about the others ? Can someone have an idea ? _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 15:55:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9BA937B401; Tue, 19 Nov 2002 15:55:32 -0800 (PST) Received: from hotmail.com (f147.law3.hotmail.com [209.185.241.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 831A843E77; Tue, 19 Nov 2002 15:55:32 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Nov 2002 15:55:32 -0800 Received: from 66.38.210.190 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 19 Nov 2002 23:55:32 GMT X-Originating-IP: [66.38.210.190] From: "Vincent Goupil" To: freebsd-isp@freebsd.org, freebsd-net@freebsd.org Subject: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Tue, 19 Nov 2002 23:55:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Nov 2002 23:55:32.0468 (UTC) FILETIME=[255B9B40:01C29027] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter v3.4.27. This system act as a firewall for an enterprise. They need high availability. I have 5 network card, all 3C905 (3*3c905B-TX and 2*905C-TX). I made this setup in july and it run fine until 3 weeks ago. The first and second card are for the internet link (primary and backup). The third is for DMZ and the fourth is for local network. The fifth is unused (marked as down). Each card as is own IRQ (except the fifth that is shared with the first). The high availability is provided by the two internet link, if one goes down, the second take the load (change default route, ipf rules, ipnat rules and DNS records). This is done by a script running by cron. We can also do that manually. We have two /29 network for the first link and one /28 network for the second (we use alias on internet interfaces). There is only 3 services that run on the firewall: SSH (but only accessible from 3 subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one subnet) We begin to have problem 3 weeks ago. The firewall begin to have a slow response. I begin to have this arp message error (many times): arplookup 255.255.255.0 failed: host is not on local network arpresolve: can't allocate llinfo for 255.255.255.0rt We reboot the server and the network fast as earlier. I finally find something: when we use alias, we need to have at least one regular netmask (instead of 255.255.255.255) for each network/subnetwork. My error was on the first link, my second sub-network was not configured properly. I changed it and it stop to have these errors about arp but the problem wasn't resolved. The network continue to be slow until we reboot the server. This happen during the day. Now, it happen everytime. What I've done: - I changed the netmask (as said earlier) - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. - I look for IRQ conflict - I configure all interface with media and mediaopt. They not using autodetect anymore. - I chkrootkit and nothing found What I suspect: - I read in a forum that the driver (xl) of 3C905 is not the best for FreeBSD. I don't know if this apply to 4.6.2. - Ethernet cables (I need to change it) - We run SSL (with a lot of users) in one of our web servers in the dmz. As I know, SSL run on top of TCP, it should not be a problem. - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not promisc" and "xl1 is not promisc". I have 5 interfaces, what about the others ? Can someone have an idea ? _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 19 19: 8:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62FED37B401; Tue, 19 Nov 2002 19:08:35 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 583DF43E77; Tue, 19 Nov 2002 19:08:34 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id gAK3AfDh006526; Wed, 20 Nov 2002 06:10:41 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id gAK3AeSv006525; Wed, 20 Nov 2002 06:10:40 +0300 (MSK) Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: To: Vincent Goupil Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter v3.4.27. > This system act as a firewall for an enterprise. They need high > availability. I have 5 network card, all 3C905 (3*3c905B-TX and 2*905C-TX). > I made this setup in july and it run fine until 3 weeks ago. The first > and second card are for the internet link (primary and backup). The third > is for DMZ and the fourth is for local network. The fifth is unused (marked > as down). Each card as is own IRQ (except the fifth that is shared with the > first). The high availability is provided by the two internet link, if one > goes down, the second take the load (change default route, ipf rules, ipnat > rules and DNS records). This is done by a script running by cron. We can > also do that manually. We have two /29 network for the first link and one > /28 network for the second (we use alias on internet interfaces). There is > only 3 services that run on the firewall: SSH (but only accessible from 3 > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one subnet) > > We begin to have problem 3 weeks ago. The firewall begin to have a slow > response. I begin to have this arp message error (many times): > arplookup 255.255.255.0 failed: host is not on local network > arpresolve: can't allocate llinfo for 255.255.255.0rt > We reboot the server and the network fast as earlier. I finally find > something: when we use alias, we need to have at least one regular netmask > (instead of 255.255.255.255) for each network/subnetwork. My error was on > the first link, my second sub-network was not configured properly. I > changed it and it stop to have these errors about arp but the problem wasn't > resolved. The network continue to be slow until we reboot the server. This > happen during the day. Now, it happen everytime. > > What I've done: > - I changed the netmask (as said earlier) > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > - I look for IRQ conflict > - I configure all interface with media and mediaopt. They not using > autodetect anymore. > - I chkrootkit and nothing found > > What I suspect: > - I read in a forum that the driver (xl) of 3C905 is not the best for > FreeBSD. I don't know if this apply to 4.6.2. > - Ethernet cables (I need to change it) > - We run SSL (with a lot of users) in one of our web servers in the dmz. As > I know, SSL run on top of TCP, it should not be a problem. > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not promisc" > and "xl1 is not promisc". I have 5 interfaces, what about the others ? > > Can someone have an idea ? What you mean when say "Slow network response"? If that mean that packets trawel long from some host to host under question as reported by tcpdump, does ifconfig xlN down and then ifconfig xlN up repare situation for some time? What tcpdump -npi xlN ether broadcast and not ip say when slowdown hapens? -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 3:12: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7D6137B401 for ; Wed, 20 Nov 2002 03:12:03 -0800 (PST) Received: from hotmail.com (f71.law15.hotmail.com [64.4.23.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 923A743E3B for ; Wed, 20 Nov 2002 03:12:03 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 03:12:03 -0800 Received: from 217.218.77.5 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 20 Nov 2002 11:12:02 GMT X-Originating-IP: [217.218.77.5] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Q. about sockets Date: Wed, 20 Nov 2002 11:12:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2002 11:12:03.0432 (UTC) FILETIME=[A7752E80:01C29085] 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 Dear all Can i use raw socket for get all of the TCP/IP packet travels through my PC like this ? in -------->MyGW MyGW------> out | | -----> MySocket ----- _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 4:25:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F31A537B404 for ; Wed, 20 Nov 2002 04:25:21 -0800 (PST) Received: from web41201.mail.yahoo.com (web41201.mail.yahoo.com [66.218.93.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 925D043E75 for ; Wed, 20 Nov 2002 04:25:21 -0800 (PST) (envelope-from shubha_mr@yahoo.com) Message-ID: <20021120122521.45873.qmail@web41201.mail.yahoo.com> Received: from [12.151.32.25] by web41201.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 12:25:21 GMT Date: Wed, 20 Nov 2002 12:25:21 +0000 (GMT) From: =?iso-8859-1?q?shubha=20mr?= Subject: duplicate packets in ping? To: freebsd-questions@FreeBSD.ORG Cc: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ping on my device driver (for my NIC )gives duplicate packets.does anyone know why they occur and how to eliminate them? thanks shubha __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.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 20 4:34: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDA7737B401; Wed, 20 Nov 2002 04:34:02 -0800 (PST) Received: from stewart.chicago.il.us (adsl-67-38-193-238.dsl.chcgil.ameritech.net [67.38.193.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343F543E8A; Wed, 20 Nov 2002 04:34:02 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.6/8.12.3) with ESMTP id gAKCXtLM004094; Wed, 20 Nov 2002 06:33:55 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3DDB8133.4030205@stewart.chicago.il.us> Date: Wed, 20 Nov 2002 06:33:55 -0600 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shubha mr Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: duplicate packets in ping? References: <20021120122521.45873.qmail@web41201.mail.yahoo.com> 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 shubha mr wrote: > Ping on my device driver (for my NIC )gives duplicate > packets.does anyone know why they occur and how to > eliminate them? > thanks > shubha > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > I have noticed a similar occurance in some of my SCTP testing with all of the BSD's. In particular the linksys pcmcia cards seem to do this. In my testing and analysis this always seems to occur when the card is busy and what happens is you lose some packet and another appears to be duplicated... I traced this out with ethereal a while ago and then just stopped using that card when I figured out it was some sort of circular buffer issue.. I did not dig in and find out if it was the card or driver... I rather suspect it is the card (since it is a low end one).. but one never knows... R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 4:45:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0810937B408; Wed, 20 Nov 2002 04:45:12 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E7C43E75; Wed, 20 Nov 2002 04:45:10 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) content-class: urn:content-classes:message Subject: RE: duplicate packets in ping? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Nov 2002 13:45:26 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07D1C5@exchange.wan.no> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: duplicate packets in ping? Thread-Index: AcKQkYrXWz5ncS2SRZ2fBE2TpgIaBwAAHi6Q From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Randall Stewart" , "shubha mr" 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 I've had similar issue with Intel Ethernet controllers (i82562ET and = i82801BA/BAM). It was practically no load, and on the wire there was no duplicates but = ping got duplicates anyway. - It only happens sporadically and it = happens to about 10 boxes with the same FreeBSD version (exact same). Havent had the chance to dig into it though.... Same with you? -----Original Message----- From: Randall Stewart [mailto:randall@stewart.chicago.il.us]=20 Sent: 20. november 2002 13:34 To: shubha mr Cc: freebsd-questions@FreeBSD.ORG; freebsd-net@FreeBSD.ORG Subject: Re: duplicate packets in ping? shubha mr wrote: > Ping on my device driver (for my NIC )gives duplicate packets.does=20 > anyone know why they occur and how to eliminate them? > thanks > shubha >=20 > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts http://uk.my.yahoo.com >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 >=20 I have noticed a similar occurance in some of my SCTP testing with all = of the BSD's. In particular the linksys pcmcia cards seem to do this. In = my testing and analysis this always seems to occur when the card is busy = and what happens is you lose some packet and another appears to be = duplicated... I traced this out with ethereal a while ago and then just = stopped using that card when I figured out it was some sort of circular = buffer issue.. I did not dig in and find out if it was the card or = driver... I rather suspect it is the card (since it is a low end one).. = but one never knows... R --=20 Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 5: 0:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB05937B4A2; Wed, 20 Nov 2002 05:00:27 -0800 (PST) Received: from hotmail.com (f98.law3.hotmail.com [209.185.241.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E9D843E88; Wed, 20 Nov 2002 05:00:27 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 05:00:27 -0800 Received: from 207.183.39.135 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 20 Nov 2002 13:00:27 GMT X-Originating-IP: [207.183.39.135] From: "Vincent Goupil" To: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Wed, 20 Nov 2002 13:00:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2002 13:00:27.0252 (UTC) FILETIME=[CC095B40:01C29094] 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 My network is composed with Windows 2000 servers and pro. 192.168.20.2 <- w2k srv 192.168.20.3 <- w2k srv 192.168.20.7 <- w2k srv 192.168.20.8 <- w2k srv 192.168.20.9 <- w2k srv 192.168.20.10 <- another freebsd box 192.168.20.210 <- the firewall 23:58:43.356569 arp who-has 192.168.20.99 tell 192.168.20.8 23:58:46.471284 arp who-has 192.168.20.127 tell 192.168.20.3 23:58:46.472257 arp who-has 192.168.20.127 tell 192.168.20.8 23:59:04.543497 arp who-has 192.168.20.2 tell 192.168.20.3 23:59:10.352106 arp who-has 192.168.20.7 tell 192.168.20.200 23:59:15.827551 arp who-has 192.168.20.251 tell 192.168.20.7 23:59:17.082626 arp who-has 192.168.20.201 tell 192.168.20.8 23:59:20.245406 arp who-has 192.168.20.201 tell 192.168.20.112 23:59:22.723713 arp who-has 192.168.20.104 tell 192.168.20.3 23:59:26.517132 arp who-has 192.168.20.6 tell 192.168.20.8 23:59:28.824120 arp who-has 192.168.20.7 tell 192.168.20.99 23:59:29.801078 arp who-has 192.168.20.6 tell 192.168.20.7 23:59:48.762973 arp who-has 192.168.20.165 tell 192.168.20.8 23:59:55.203905 arp who-has 192.168.20.75 tell 192.168.20.3 23:59:55.688710 arp who-has 192.168.20.114 tell 192.168.20.8 23:59:55.861042 arp who-has 192.168.20.77 tell 192.168.20.8 00:00:00.192659 arp who-has 192.168.20.106 tell 192.168.20.201 00:00:04.337994 arp who-has 192.168.20.10 tell 192.168.20.8 00:00:04.538035 arp who-has 192.168.20.10 tell 192.168.20.2 00:00:04.775959 arp who-has 192.168.20.10 tell 192.168.20.3 00:00:05.022385 arp who-has 192.168.20.10 tell 192.168.20.9 00:00:05.066194 arp who-has 192.168.20.10 tell 192.168.20.7 00:00:05.209935 arp who-has 192.168.20.10 tell 192.168.20.6 00:00:20.085908 arp who-has 192.168.20.9 tell 192.168.20.3 00:00:20.116177 arp who-has 192.168.20.9 tell 192.168.20.8 00:00:22.235535 arp who-has 192.168.20.101 tell 192.168.20.8 00:00:22.236614 arp who-has 192.168.20.101 tell 192.168.20.3 00:00:23.118443 arp who-has 192.168.20.54 tell 192.168.20.3 00:00:25.075679 arp who-has 192.168.20.7 tell 192.168.20.201 00:00:29.815522 arp who-has 192.168.20.166 tell 192.168.20.7 00:00:30.587208 arp who-has 192.168.20.157 (2f:69:70:63:68:65) tell 192.168.20.201 00:00:31.810270 arp who-has 192.168.20.166 tell 192.168.20.7 00:00:45.473558 arp who-has 192.168.20.177 tell 192.168.20.201 >From: "."@babolo.ru >To: Vincent Goupil >CC: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG >Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter >Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) >MIME-Version: 1.0 >Received: from aaz.links.ru ([193.125.152.37]) by mc6-f36.law1.hotmail.com >with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 19:08:36 -0800 >Received: from aaz.links.ru (aaz.links.ru [193.125.152.37])by aaz.links.ru >(8.12.6/8.12.6) with ESMTP id gAK3AfDh006526;Wed, 20 Nov 2002 06:10:41 >+0300 (MSK)(envelope-from babolo@aaz.links.ru) >Received: (from babolo@localhost)by aaz.links.ru (8.12.6/8.12.6/Submit) id >gAK3AeSv006525;Wed, 20 Nov 2002 06:10:40 +0300 (MSK) >Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> >X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 >In-Reply-To: >X-Mailer: ELM [version 2.4ME+ PL99b (25)] >Return-Path: babolo@aaz.links.ru >X-OriginalArrivalTime: 20 Nov 2002 03:08:36.0969 (UTC) >FILETIME=[1E422D90:01C29042] > > > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter >v3.4.27. > > This system act as a firewall for an enterprise. They need high > > availability. I have 5 network card, all 3C905 (3*3c905B-TX and >2*905C-TX). > > I made this setup in july and it run fine until 3 weeks ago. The >first > > and second card are for the internet link (primary and backup). The >third > > is for DMZ and the fourth is for local network. The fifth is unused >(marked > > as down). Each card as is own IRQ (except the fifth that is shared with >the > > first). The high availability is provided by the two internet link, if >one > > goes down, the second take the load (change default route, ipf rules, >ipnat > > rules and DNS records). This is done by a script running by cron. We >can > > also do that manually. We have two /29 network for the first link and >one > > /28 network for the second (we use alias on internet interfaces). There >is > > only 3 services that run on the firewall: SSH (but only accessible from >3 > > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one >subnet) > > > > We begin to have problem 3 weeks ago. The firewall begin to have a slow > > response. I begin to have this arp message error (many times): > > arplookup 255.255.255.0 failed: host is not on local network > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > We reboot the server and the network fast as earlier. I finally find > > something: when we use alias, we need to have at least one regular >netmask > > (instead of 255.255.255.255) for each network/subnetwork. My error was >on > > the first link, my second sub-network was not configured properly. I > > changed it and it stop to have these errors about arp but the problem >wasn't > > resolved. The network continue to be slow until we reboot the server. >This > > happen during the day. Now, it happen everytime. > > > > What I've done: > > - I changed the netmask (as said earlier) > > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > > - I look for IRQ conflict > > - I configure all interface with media and mediaopt. They not using > > autodetect anymore. > > - I chkrootkit and nothing found > > > > What I suspect: > > - I read in a forum that the driver (xl) of 3C905 is not the best for > > FreeBSD. I don't know if this apply to 4.6.2. > > - Ethernet cables (I need to change it) > > - We run SSL (with a lot of users) in one of our web servers in the dmz. >As > > I know, SSL run on top of TCP, it should not be a problem. > > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not >promisc" > > and "xl1 is not promisc". I have 5 interfaces, what about the others ? > > > > Can someone have an idea ? >What you mean when say "Slow network response"? >If that mean that packets trawel long >from some host to host under question >as reported by tcpdump, does ifconfig xlN down >and then ifconfig xlN up repare situation >for some time? >What tcpdump -npi xlN ether broadcast and not ip >say when slowdown hapens? > >-- >@BABOLO http://links.ru/ _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 8:27:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EF637B401 for ; Wed, 20 Nov 2002 08:27:52 -0800 (PST) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AF343E3B for ; Wed, 20 Nov 2002 08:27:50 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18EXhb-0001Co-00 for net@freebsd.org; Wed, 20 Nov 2002 19:27:47 +0300 Subject: mpd pptp freebsd <-> linux setup From: "Vladimir B. " Grebenschikov To: net@freebsd.org Content-Type: multipart/mixed; boundary="=-3Hqn2bOFSkpz2Fcxn0MO" Organization: TSB "Russian Express" Message-Id: <1037809666.1318.28.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 20 Nov 2002 19:27:47 +0300 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 --=-3Hqn2bOFSkpz2Fcxn0MO Content-Type: text/plain Content-Transfer-Encoding: 7bit hi ppl can anyone help me setup mpd pptp link (as client) to Linux pptp server ? mpd build from fresh ports on 5.0-CURRENT Server works, I can connect to it from M$Win (I guess poptop package) it configured to allow mpe 40 and mpe 128, MSChapV2 Transcript of mpd session in attach mpd config files in attach too As I understand it fails LCP negotiation, why ? pptpclient (from ports on 4.7) with ppp successful negotiates: Nov 20 20:52:01 gw18 ppp[59502]: Phase: Using interface: tun0 Nov 20 20:52:01 gw18 ppp[59502]: Phase: deflink: Created in closed state Nov 20 20:52:01 gw18 ppp[59502]: Phase: PPP Started (direct mode). Nov 20 20:52:01 gw18 ppp[59502]: Phase: bundle: Establish Nov 20 20:52:01 gw18 ppp[59502]: Phase: deflink: closed -> opening Nov 20 20:52:01 gw18 ppp[59502]: Phase: deflink: Connected! Nov 20 20:52:01 gw18 ppp[59502]: Phase: deflink: opening -> carrier Nov 20 20:52:02 gw18 ppp[59502]: Phase: deflink: carrier -> lcp Nov 20 20:52:06 gw18 ppp[59502]: Phase: bundle: Authenticate Nov 20 20:52:06 gw18 ppp[59502]: Phase: deflink: his = CHAP 0x81, mine = none Nov 20 20:52:06 gw18 ppp[59502]: Phase: Chap Input: CHALLENGE (16 bytes from SERVER) Nov 20 20:52:06 gw18 ppp[59502]: Phase: Chap Output: RESPONSE (vova) Nov 20 20:52:06 gw18 ppp[59502]: Phase: Chap Input: SUCCESS (S=xxxx...xxx) Nov 20 20:52:06 gw18 ppp[59502]: Phase: deflink: lcp -> open Nov 20 20:52:06 gw18 ppp[59502]: Phase: bundle: Network And setup connection but I can get packets from linux side via this connection but linux can't. Any suggestions/ideas very appreciated. -- Vladimir B. Grebenschikov TSB "Russian Express" --=-3Hqn2bOFSkpz2Fcxn0MO Content-Disposition: attachment; filename=transcript Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=transcript; charset=KOI8-R Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 4597, version 3.10 (root@vbook.express.ru 14:47 19-Nov-2002) [pptp] ppp node is "mpd4597-pptp" [pptp] using interface ng0 mpd: warning: line too long, truncated [pptp] IFACE: Open event [pptp] IPCP: Open event [pptp] IPCP: state change Initial --> Starting [pptp] IPCP: LayerStart [pptp:pptp] [pptp] bundle: OPEN event in state CLOSED [pptp] opening link "pptp"... [pptp] link: OPEN event [pptp] LCP: Open event [pptp] LCP: state change Initial --> Starting [pptp] LCP: LayerStart [pptp] device: OPEN event in state DOWN pptp0: connecting to 192.168.1.1:1723 [pptp] device is now in state OPENING pptp0: connected to 192.168.1.1:1723 pptp0: attached to connection with 192.168.1.1:1723 pptp0-0: outgoing call connected at 64000 bps [pptp] PPTP call successful [pptp] device: UP event in state OPENING [pptp] device is now in state UP [pptp] link: UP event [pptp] link: origination is local [pptp] LCP: Up event [pptp] LCP: state change Starting --> Req-Sent [pptp] LCP: phase shift DEAD --> ESTABLISH [pptp] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 08 00 46 04 31 b3 [pptp] LCP: rec'd Configure Request #1 link 0 (Req-Sent) MRU 1400 ACCMAP 0x00000000 AUTHPROTO CHAP MSOFTv2 MAGICNUM d4461f6d PROTOCOMP ACFCOMP [pptp] LCP: SendConfigAck #1 MRU 1400 ACCMAP 0x00000000 AUTHPROTO CHAP MSOFTv2 MAGICNUM d4461f6d PROTOCOMP ACFCOMP [pptp] LCP: state change Req-Sent --> Ack-Sent [pptp] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 08 00 46 04 31 b3 [pptp] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 08 00 46 04 31 b3 [pptp] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #3 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #4 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #4 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #5 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #5 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #6 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #6 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #7 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #7 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #8 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #8 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #9 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #9 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #10 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 526d2cdf AUTHPROTO CHAP MSOFTv2 [pptp] LCP: rec'd Configure Reject #10 link 0 (Ack-Sent) AUTHPROTO CHAP MSOFTv2 [pptp] LCP: not converging [pptp] LCP: parameter negotiation failed [pptp] LCP: state change Ack-Sent --> Stopped [pptp] LCP: LayerFinish [pptp] device: CLOSE event in state UP pptp0-0: clearing call [pptp] device is now in state CLOSING [pptp] device: DOWN event in state CLOSING [pptp] device is now in state DOWN [pptp] link: DOWN event [pptp] LCP: Down event [pptp] LCP: state change Stopped --> Starting [pptp] LCP: phase shift ESTABLISH --> DEAD [pptp] LCP: LayerStart [pptp] device: OPEN event in state DOWN [pptp] pausing 9 seconds before open [pptp] device is now in state DOWN [pptp] device: OPEN event in state DOWN [pptp] device is now in state DOWN pptp0-0: peer call disconnected res=3Ddisconnect request err=3Dnone pptp0-0: killing channel pptp0: closing connection with 192.168.1.1:1723 pptp0: ctrl connection closed by peer pptp0: killing connection with 192.168.1.1:1723 mpd: caught fatal signal int mpd: fatal error, exiting [pptp] IPCP: Down event [pptp] IFACE: Close event [pptp] IPCP: Close event [pptp] IPCP: state change Starting --> Initial [pptp] IPCP: LayerFinish mpd: process 4597 terminated --=-3Hqn2bOFSkpz2Fcxn0MO Content-Disposition: attachment; filename=mpd.conf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=mpd.conf; charset=KOI8-R default: load pptp pptp: new -i ng0 pptp pptp set iface disable on-demand set iface disable proxy-arp log +auth +lcp +ccp # log +auth +bund +ccp3 +lcp +link +pptp3 set iface idle 1800 # set bundle disable multilink set link yes acfcomp protocomp set link no pap set link yes chap # set link keep-alive 10 120 # set link mru 1400 # set link mtu 1400 # set link no magicnum set link ident VBook set ipcp yes vjcomp # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # # encription required # set bundle enable crypt-reqd set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle authname "vova" open --=-3Hqn2bOFSkpz2Fcxn0MO Content-Disposition: attachment; filename=mpd.links Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=mpd.links; charset=KOI8-R pptp: set link type pptp set pptp peer my.server.com set pptp disable incoming set pptp enable originate --=-3Hqn2bOFSkpz2Fcxn0MO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 10: 5:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 309EA37B401 for ; Wed, 20 Nov 2002 10:05:46 -0800 (PST) Received: from hotmail.com (f90.law3.hotmail.com [209.185.241.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD2143E8A for ; Wed, 20 Nov 2002 10:05:45 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 10:05:45 -0800 Received: from 66.38.210.190 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 20 Nov 2002 18:05:45 GMT X-Originating-IP: [66.38.210.190] From: "Vincent Goupil" To: freebsd-net@freebsd.org Subject: Network performance Date: Wed, 20 Nov 2002 18:05:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2002 18:05:45.0882 (UTC) FILETIME=[72CA77A0:01C290BF] 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 currently running FreeBSD 4.6.2 with ipfilter 3.4.27. I have network slowdown but I can't find where it came from. When I reboot it, all came back to normal. When I experiencing slowdown, more packets tend to be denied. I suspect that something slowdown the ipfilter process or ip forwarding. The CPU is idle or almost (PIII 500). Is there a utility or a way to measure throughput, timeout or can help me to find related problem. Thanks _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 11: 6:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D72A937B401 for ; Wed, 20 Nov 2002 11:06:47 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C8FE43E8A for ; Wed, 20 Nov 2002 11:06:47 -0800 (PST) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) by mrout3.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id gAKJ6W918954 for ; Wed, 20 Nov 2002 11:06:32 -0800 (PST) Received: (from root@localhost) by milk.yahoo.com (8.11.0/8.11.0) id gAKJ6Wt63573 for freebsd-net@freebsd.org; Wed, 20 Nov 2002 11:06:32 -0800 (PST) (envelope-from jayanth) Date: Wed, 20 Nov 2002 11:06:32 -0800 From: jayanth To: freebsd-net@freebsd.org Subject: file descriptor flags and socket flags out of sync ? Message-ID: <20021120110632.A62938@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Some developers here have encountered a scenario where the file descriptor flags and the socket flags seem to be out of sync. if an application does: listen(listenfd) while (!done) { select() <-------------------- new connection arrives before fcntl() fcntl(listenfd,O_NONBLOCK) newfd = accept(listenfd,...) fnctl(listenfd,0) /* make socket blocking */ if (newfd & O_NONBLOCK) /* fd is O_NONBLOCK, but socket is blocking */ } At this point socket is blocking because the state of the new socket = state of the listen socket only during the connection setup phase, not during the accept phase. However, the filedescriptor flags are copied during the accept phase. So at this point the filedescriptor flags are nonblocking but the socket is actually blocking. Agreed, that the solution is to have the application set NONBLOCK before the listen() call, but it seems incorrect to have the newfd's flags and socket state be out of sync. Copying the state of the socket during the accept might lead to a slightly different behaviour, but will solve this particular problem. thanks, jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 11:10:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD77E37B41B; Wed, 20 Nov 2002 11:10:39 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B08E43E42; Wed, 20 Nov 2002 11:10:38 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gAKJAZuO041995; Wed, 20 Nov 2002 21:10:36 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DDBDE2B.6050407@he.iki.fi> Date: Wed, 20 Nov 2002 21:10:35 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: David Schultz Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; 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 David Schultz wrote: >Thus spake Petri Helenius : > > >>I seem to get kmem_map too small panics when using large buffers with >>bpf. Is there a tunable I should be increasing? >> >> > >Yes, increase KVA_PAGES in your kernel config. > > I put in KVA_PAGES=1024 with following results on next boot: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 06000000 fault virtual address = 0x1 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01efc88 stack pointer = 0x10:0xdf0ccbcc frame pointer = 0x10:0xdf0ccbf0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (swi1: net) trap number lastlog: Permission denied Removing the option and recompiling kernel from the same sources makes it work fine. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 11:55:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E94F37B401 for ; Wed, 20 Nov 2002 11:55:29 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F7F143E91 for ; Wed, 20 Nov 2002 11:55:28 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAKJtJBF054649; Wed, 20 Nov 2002 14:55:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 20 Nov 2002 14:55:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Q. about sockets 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 On Wed, 20 Nov 2002, soheil soheil wrote: > Can i use raw socket for get all of the TCP/IP packet travels through my > PC like this ? > > in -------->MyGW MyGW------> out > | | > -----> MySocket ----- Generally, no -- there are a number of approaches you can take addressing the problem you're talking about, but it depends a lot on what you need the solution to do. If you definitely want a userland solution, one place to start looking is at DIVERT sockets. This is used by the userland nat daemon (natd(8)) to intercept packets along a route or going in/out an interface. Take a look at divert(4) for more general information on the divert notion. I've used IPDIVERT in a number of situations to write filtering applications at the IP level. I've also used BPF to write userland applications to perform filtering at the link layer by writing a simple bridging application. Depending on what you're trying to accomplish, you might also be interested in the ipfw "fwd" command, which allows you to intercept TCP connections, which you can then hook up to a new TCP connection created by a proxy application. ipfw(8) contains some information about connection "fwd"s. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 11:57:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 090F437B401; Wed, 20 Nov 2002 11:57:41 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B2943E9C; Wed, 20 Nov 2002 11:57:39 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAKJvbBF054682; Wed, 20 Nov 2002 14:57:37 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 20 Nov 2002 14:57:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Petri Helenius Cc: David Schultz , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small In-Reply-To: <3DDBDE2B.6050407@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 20 Nov 2002, Petri Helenius wrote: > David Schultz wrote: > > >Thus spake Petri Helenius : > > > > > >>I seem to get kmem_map too small panics when using large buffers with > >>bpf. Is there a tunable I should be increasing? > >> > >> > > > >Yes, increase KVA_PAGES in your kernel config. > > > > > I put in KVA_PAGES=1024 > with following results on next boot: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; lapic.id = 06000000 > fault virtual address = 0x1 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc01efc88 > stack pointer = 0x10:0xdf0ccbcc > frame pointer = 0x10:0xdf0ccbf0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 15 (swi1: net) > trap number lastlog: Permission denied > > Removing the option and recompiling kernel from the same sources makes > it work fine. Looks like some network stack code is responding poorly to malloc() failing (which it can). Any chance you can generate a stack trace for this by compiling DDB into your kernel, then using the trace command to generate the trace? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 11:59:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E9E237B417; Wed, 20 Nov 2002 11:59:31 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B92D43E3B; Wed, 20 Nov 2002 11:59:30 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gAKJxKm9001196; Wed, 20 Nov 2002 11:59:20 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gAKJxJ3f001195; Wed, 20 Nov 2002 11:59:19 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 20 Nov 2002 11:59:19 -0800 From: David Schultz To: Petri Helenius Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small Message-ID: <20021120195919.GA679@HAL9000.homeunix.com> Mail-Followup-To: Petri Helenius , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDBDE2B.6050407@he.iki.fi> 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 Thus spake Petri Helenius : > >>I seem to get kmem_map too small panics when using large buffers with > >>bpf. Is there a tunable I should be increasing? > >> > >> > > > >Yes, increase KVA_PAGES in your kernel config. > > > > > I put in KVA_PAGES=1024 > with following results on next boot: > > Fatal trap 12: page fault while in kernel mode Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, because then your kernel would take up the entire 4 GB virtual address space. Since the kernel must fit into 4 GB alongside every user process, that leaves you no room for programs. Try a more reasonable value like 512 (2 GB). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 15: 5:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F2A037B401 for ; Wed, 20 Nov 2002 15:05:49 -0800 (PST) Received: from hotmail.com (f41.law3.hotmail.com [209.185.241.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id B086943E3B for ; Wed, 20 Nov 2002 15:05:48 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 15:05:48 -0800 Received: from 66.38.210.190 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 20 Nov 2002 23:05:48 GMT X-Originating-IP: [66.38.210.190] From: "Vincent Goupil" To: freebsd-net@freebsd.org Subject: network slowdown measured with netstat Date: Wed, 20 Nov 2002 23:05:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2002 23:05:48.0589 (UTC) FILETIME=[5D3D8DD0:01C290E9] 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 currently experience network problem. I run FreeBSD 4.6.2 with ipfilter 3.4.27 with 5 ethernet interfaces (all 3C905). I think we have a problem with a card xl0. It have 43698 inputs packets with 2424 input errors packets. I think this is problem with ethernet packets (probably checksum errors) ? I plan to change the card tonight. Does anybody experience this kind of problems ? Another question, does the total of packets () should match the total packets of each ip alias ? If it's not the case, the difference of packets aren't for IP protocol ? Thanks [root@wally ~] netstat -ibdt Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Time Drop xl0 1500 00:10:5a:0d:55:f6 43698 2424 15851835 47285 0 17391650 0 0 0 xl0 1500 h204-72-240-9 wally-gt 195 - 73289 508 - 95110 - - - xl0 1500 h61-37-210-18 185-gt 71 - 3120 0 - 0 - - - xl0 1500 h61-37-210-18 186-gt 0 - 0 0 - 0 - - - xl0 1500 h61-37-210-18 187-gt 0 - 0 0 - 0 - - - xl0 1500 h61-37-210-18 188-gt 2109 - 101044 0 - 0 - - - xl0 1500 h61-37-210-18 189-gt 0 - 0 0 - 0 - - - xl0 1500 h61-37-210-19 190-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 121-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 122-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 123-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 124-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 125-gt 0 - 0 0 - 0 - - - xl0 1500 h210-75-24-1 126-gt 0 - 0 0 - 0 - - - xl1 1500 00:10:4b:6a:ed:6e 380 0 44597 13 0 546 0 0 0 xl1 1500 198.146.98.20 wally-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 211-bell 106 - 5088 0 - 0 - - - xl1 1500 198.146.98.21 212-bell 2478 - 118944 0 - 0 - - - xl1 1500 198.146.98.21 213-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 214-bell 109 - 5232 0 - 0 - - - xl1 1500 198.146.98.21 215-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 216-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 217-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 218-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.21 219-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.22 220-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.22 221-bell 0 - 0 0 - 0 - - - xl1 1500 198.146.98.22 222-bell 0 - 0 0 - 0 - - - xl2 1500 00:10:5a:1d:e9:c4 69627 3 30006861 63467 0 21074188 0 0 0 xl2 1500 192.168.5 xl2-wally 12 - 480 12 - 720 - - - xl3 1500 00:04:75:96:cb:82 47695 0 11789710 48948 0 18818358 0 0 0 xl3 1500 192.168.212 wally 10048 - 982443 14240 - 1289921 - - - xl4* 1500 00:04:75:9b:df:a3 0 0 0 0 0 0 0 0 0 lo0 16384 122 0 12456 122 0 12456 0 0 0 lo0 16384 your-net localhost 122 - 12456 122 - 12456 - - - [root@wally ~] _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 15:24:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4699137B401; Wed, 20 Nov 2002 15:24:29 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id F36E143E9C; Wed, 20 Nov 2002 15:24:27 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gAKNOJuO043498; Thu, 21 Nov 2002 01:24:20 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <11fd01c290eb$f48311e0$862a40c1@PHE> From: "Petri Helenius" To: "David Schultz" Cc: , References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> Subject: Re: panic: kmem_map too small Date: Thu, 21 Nov 2002 01:24:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 > > Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, > because then your kernel would take up the entire 4 GB virtual > address space. Since the kernel must fit into 4 GB alongside > every user process, that leaves you no room for programs. Try a > more reasonable value like 512 (2 GB). > Am I correct assuming that the default is 256? I´m not coming near this utilization when the system panics. With about 150M in use and KVA_PAGES undefined in config (default), both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 16:45: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC3AF37B401 for ; Wed, 20 Nov 2002 16:45:07 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F30843E3B for ; Wed, 20 Nov 2002 16:45:07 -0800 (PST) (envelope-from archie@dellroad.org) 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 QAA77188; Wed, 20 Nov 2002 16:30:05 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAL0U5OS063036; Wed, 20 Nov 2002 16:30:05 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAL0U4WV063035; Wed, 20 Nov 2002 16:30:04 -0800 (PST) From: Archie Cobbs Message-Id: <200211210030.gAL0U4WV063035@arch20m.dellroad.org> Subject: Re: mpd pptp freebsd <-> linux setup In-Reply-To: <1037809666.1318.28.camel@vbook> To: "Vladimir B. Grebenschikov" Date: Wed, 20 Nov 2002 16:30:04 -0800 (PST) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (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 Vladimir B. Grebenschikov wrote: > can anyone help me setup mpd pptp link (as client) > to Linux pptp server ? The mpd log shows that you are requiring the peer to authenticate but the peer doesn't want to. That's why LCP is failing to converge. Try adding "set link disable chap" to mpd.conf. -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 20 18:25:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C7C37B401; Wed, 20 Nov 2002 18:25:26 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A2E643E97; Wed, 20 Nov 2002 18:25:25 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gAL2POm9002339; Wed, 20 Nov 2002 18:25:24 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gAL2PO6t002338; Wed, 20 Nov 2002 18:25:24 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 20 Nov 2002 18:25:24 -0800 From: David Schultz To: Petri Helenius Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small Message-ID: <20021121022524.GA2300@HAL9000.homeunix.com> Mail-Followup-To: Petri Helenius , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> <11fd01c290eb$f48311e0$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii:iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <11fd01c290eb$f48311e0$862a40c1@PHE> 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 Thus spake Petri Helenius : > > Read LINT (or NOTES) carefully. You can't set KVA_PAGES to 1024, > > because then your kernel would take up the entire 4 GB virtual > > address space. Since the kernel must fit into 4 GB alongside > > every user process, that leaves you no room for programs. Try a > > more reasonable value like 512 (2 GB). > > > Am I correct assuming that the default is 256? I´m not coming near this > utilization when the system panics. > > With about 150M in use and KVA_PAGES undefined in config (default), > both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, and you have only 1 GB of physical memory to back it. I take it this is a very busy machine. Short of getting more memory, you can decrease memory utilization by the network, e.g. by decreasing TCP window sizes, or you can limit memory usage by the network so you don't get panics. I forget the details here, so perhaps someone else can fill them in. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 19:30:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFDD437B401; Wed, 20 Nov 2002 19:30:14 -0800 (PST) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC5C043E42; Wed, 20 Nov 2002 19:30:13 -0800 (PST) (envelope-from babolo@aaz.links.ru) Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by aaz.links.ru (8.12.6/8.12.6) with ESMTP id gAL3WODh043684; Thu, 21 Nov 2002 06:32:24 +0300 (MSK) (envelope-from babolo@aaz.links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.12.6/8.12.6/Submit) id gAL3WO9N043683; Thu, 21 Nov 2002 06:32:24 +0300 (MSK) Message-Id: <200211210332.gAL3WO9N043683@aaz.links.ru> Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: To: Vincent Goupil Date: Thu, 21 Nov 2002 06:32:24 +0300 (MSK) From: "."@babolo.ru Cc: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org other questions was: - what is "Slow network response"? - does ifconfig down/up helps? tcpdump buffers output so usful bits are some time after trouble. In my case slowdown triggered by arp scans > My network is composed with Windows 2000 servers and pro. > 192.168.20.2 <- w2k srv > 192.168.20.3 <- w2k srv > 192.168.20.7 <- w2k srv > 192.168.20.8 <- w2k srv > 192.168.20.9 <- w2k srv > 192.168.20.10 <- another freebsd box > 192.168.20.210 <- the firewall > > 23:58:43.356569 arp who-has 192.168.20.99 tell 192.168.20.8 > 23:58:46.471284 arp who-has 192.168.20.127 tell 192.168.20.3 > 23:58:46.472257 arp who-has 192.168.20.127 tell 192.168.20.8 > 23:59:04.543497 arp who-has 192.168.20.2 tell 192.168.20.3 > 23:59:10.352106 arp who-has 192.168.20.7 tell 192.168.20.200 > 23:59:15.827551 arp who-has 192.168.20.251 tell 192.168.20.7 > 23:59:17.082626 arp who-has 192.168.20.201 tell 192.168.20.8 > 23:59:20.245406 arp who-has 192.168.20.201 tell 192.168.20.112 > 23:59:22.723713 arp who-has 192.168.20.104 tell 192.168.20.3 > 23:59:26.517132 arp who-has 192.168.20.6 tell 192.168.20.8 > 23:59:28.824120 arp who-has 192.168.20.7 tell 192.168.20.99 > 23:59:29.801078 arp who-has 192.168.20.6 tell 192.168.20.7 > 23:59:48.762973 arp who-has 192.168.20.165 tell 192.168.20.8 > 23:59:55.203905 arp who-has 192.168.20.75 tell 192.168.20.3 > 23:59:55.688710 arp who-has 192.168.20.114 tell 192.168.20.8 > 23:59:55.861042 arp who-has 192.168.20.77 tell 192.168.20.8 > 00:00:00.192659 arp who-has 192.168.20.106 tell 192.168.20.201 > 00:00:04.337994 arp who-has 192.168.20.10 tell 192.168.20.8 > 00:00:04.538035 arp who-has 192.168.20.10 tell 192.168.20.2 > 00:00:04.775959 arp who-has 192.168.20.10 tell 192.168.20.3 > 00:00:05.022385 arp who-has 192.168.20.10 tell 192.168.20.9 > 00:00:05.066194 arp who-has 192.168.20.10 tell 192.168.20.7 > 00:00:05.209935 arp who-has 192.168.20.10 tell 192.168.20.6 > 00:00:20.085908 arp who-has 192.168.20.9 tell 192.168.20.3 > 00:00:20.116177 arp who-has 192.168.20.9 tell 192.168.20.8 > 00:00:22.235535 arp who-has 192.168.20.101 tell 192.168.20.8 > 00:00:22.236614 arp who-has 192.168.20.101 tell 192.168.20.3 > 00:00:23.118443 arp who-has 192.168.20.54 tell 192.168.20.3 > 00:00:25.075679 arp who-has 192.168.20.7 tell 192.168.20.201 > 00:00:29.815522 arp who-has 192.168.20.166 tell 192.168.20.7 > 00:00:30.587208 arp who-has 192.168.20.157 (2f:69:70:63:68:65) tell > 192.168.20.201 > 00:00:31.810270 arp who-has 192.168.20.166 tell 192.168.20.7 > 00:00:45.473558 arp who-has 192.168.20.177 tell 192.168.20.201 > > > >From: "."@babolo.ru > >To: Vincent Goupil > >CC: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG > >Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter > >Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > >MIME-Version: 1.0 > >Received: from aaz.links.ru ([193.125.152.37]) by mc6-f36.law1.hotmail.com > >with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 19:08:36 -0800 > >Received: from aaz.links.ru (aaz.links.ru [193.125.152.37])by aaz.links.ru > >(8.12.6/8.12.6) with ESMTP id gAK3AfDh006526;Wed, 20 Nov 2002 06:10:41 > >+0300 (MSK)(envelope-from babolo@aaz.links.ru) > >Received: (from babolo@localhost)by aaz.links.ru (8.12.6/8.12.6/Submit) id > >gAK3AeSv006525;Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > >Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> > >X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 > >In-Reply-To: > >X-Mailer: ELM [version 2.4ME+ PL99b (25)] > >Return-Path: babolo@aaz.links.ru > >X-OriginalArrivalTime: 20 Nov 2002 03:08:36.0969 (UTC) > >FILETIME=[1E422D90:01C29042] > > > > > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter > >v3.4.27. > > > This system act as a firewall for an enterprise. They need high > > > availability. I have 5 network card, all 3C905 (3*3c905B-TX and > >2*905C-TX). > > > I made this setup in july and it run fine until 3 weeks ago. The > >first > > > and second card are for the internet link (primary and backup). The > >third > > > is for DMZ and the fourth is for local network. The fifth is unused > >(marked > > > as down). Each card as is own IRQ (except the fifth that is shared with > >the > > > first). The high availability is provided by the two internet link, if > >one > > > goes down, the second take the load (change default route, ipf rules, > >ipnat > > > rules and DNS records). This is done by a script running by cron. We > >can > > > also do that manually. We have two /29 network for the first link and > >one > > > /28 network for the second (we use alias on internet interfaces). There > >is > > > only 3 services that run on the firewall: SSH (but only accessible from > >3 > > > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one > >subnet) > > > > > > We begin to have problem 3 weeks ago. The firewall begin to have a slow > > > response. I begin to have this arp message error (many times): > > > arplookup 255.255.255.0 failed: host is not on local network > > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > > We reboot the server and the network fast as earlier. I finally find > > > something: when we use alias, we need to have at least one regular > >netmask > > > (instead of 255.255.255.255) for each network/subnetwork. My error was > >on > > > the first link, my second sub-network was not configured properly. I > > > changed it and it stop to have these errors about arp but the problem > >wasn't > > > resolved. The network continue to be slow until we reboot the server. > >This > > > happen during the day. Now, it happen everytime. > > > > > > What I've done: > > > - I changed the netmask (as said earlier) > > > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > > > - I look for IRQ conflict > > > - I configure all interface with media and mediaopt. They not using > > > autodetect anymore. > > > - I chkrootkit and nothing found > > > > > > What I suspect: > > > - I read in a forum that the driver (xl) of 3C905 is not the best for > > > FreeBSD. I don't know if this apply to 4.6.2. > > > - Ethernet cables (I need to change it) > > > - We run SSL (with a lot of users) in one of our web servers in the dmz. > >As > > > I know, SSL run on top of TCP, it should not be a problem. > > > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not > >promisc" > > > and "xl1 is not promisc". I have 5 interfaces, what about the others ? > > > > > > Can someone have an idea ? > >What you mean when say "Slow network response"? > >If that mean that packets trawel long > >from some host to host under question > >as reported by tcpdump, does ifconfig xlN down > >and then ifconfig xlN up repare situation > >for some time? > >What tcpdump -npi xlN ether broadcast and not ip > >say when slowdown hapens? > > > >-- > >@BABOLO http://links.ru/ > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 21:54:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956D537B401 for ; Wed, 20 Nov 2002 21:54:43 -0800 (PST) Received: from hotmail.com (f146.law15.hotmail.com [64.4.23.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6156E43E42 for ; Wed, 20 Nov 2002 21:54:43 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Nov 2002 21:54:43 -0800 Received: from 195.219.129.205 by lw15fd.law15.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 05:54:43 GMT X-Originating-IP: [195.219.129.205] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Pcap Date: Thu, 21 Nov 2002 05:54:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 05:54:43.0328 (UTC) FILETIME=[7D15A000:01C29122] 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 can i use pcap to access all of the packets travel through my gateway THANX _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 23: 5:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF43E37B401; Wed, 20 Nov 2002 23:05:30 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD6A43E3B; Wed, 20 Nov 2002 23:05:29 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gAL75DuO045715; Thu, 21 Nov 2002 09:05:21 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <126801c2912c$5be3cec0$862a40c1@PHE> From: "Petri Helenius" To: "David Schultz" Cc: , References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> <11fd01c290eb$f48311e0$862a40c1@PHE> <20021121022524.GA2300@HAL9000.homeunix.com> Subject: Re: panic: kmem_map too small Date: Thu, 21 Nov 2002 09:05:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 > > With about 150M in use and KVA_PAGES undefined in config (default), > > both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). > > Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, > and you have only 1 GB of physical memory to back it. I take it > this is a very busy machine. Short of getting more memory, you > can decrease memory utilization by the network, e.g. by decreasing > TCP window sizes, or you can limit memory usage by the network so > you don't get panics. I forget the details here, so perhaps > someone else can fill them in. > The thing I´m concerned about that if with 150M kernel memory usage and >200M free and >300M inact memory the system panics, how much "extra" memory is needed to keep it running? And the swap is never touched. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 20 23:24: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A15137B401 for ; Wed, 20 Nov 2002 23:24:00 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C72243E6E for ; Wed, 20 Nov 2002 23:23:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA26297; Thu, 21 Nov 2002 18:23:53 +1100 Date: Thu, 21 Nov 2002 18:36:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: jayanth Cc: freebsd-net@FreeBSD.ORG Subject: Re: file descriptor flags and socket flags out of sync ? In-Reply-To: <20021120110632.A62938@yahoo-inc.com> Message-ID: <20021121171101.K37954-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 20 Nov 2002, jayanth wrote: > Some developers here have encountered a scenario where the file > descriptor flags and the socket flags seem to be out of sync. > > if an application does: > > listen(listenfd) > while (!done) { > select() > <-------------------- new connection arrives before fcntl() > fcntl(listenfd,O_NONBLOCK) > newfd = accept(listenfd,...) > fnctl(listenfd,0) /* make socket blocking */ > if (newfd & O_NONBLOCK) Better delete the last line. newfd doesn't contain any file flags. > /* fd is O_NONBLOCK, but socket is blocking */ > } > > At this point socket is blocking because the state > of the new socket = state of the listen socket only during the connection > setup phase, not during the accept phase. However, the filedescriptor > flags are copied during the accept phase. So at this point > the filedescriptor flags are nonblocking but the socket is actually blocking. This is related to my pet peeve of keeping the O_NONBLOCK flag in several places (one of them inadequate) and using the wrong copies. For sockets, the per-socket flag is adequate since open() doesn't work on sockets so there only needs to be one flag per socket, and using the per-socket flag mostly works right. For devices that can be opened more than once, a per-device flag is inadequate since file flags are supposed to be per-open. Non-broken device drivers use the copy of the file flags passed to their read/write/ioctl/close/etc functions, but making a copy causes synchronization problems. However, accessing the per-file flag from the device layer or the socket layer would be a layering violation. > Agreed, that the solution is to have the application set NONBLOCK before > the listen() call, but it seems incorrect to have the newfd's flags and socket > state be out of sync. You could also use "fnctl(newfd, 0)" to sync things for newfd. > Copying the state of the socket during the accept might lead to a slightly > different behaviour, but will solve this particular problem. I think this is the correct fix. The states are supposed to be consistent. This is enforced by fcntl() if the file flag state using it. I think you can still make a mess by changing the state using ioctl(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 5:28:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3103B37B404; Thu, 21 Nov 2002 05:28:41 -0800 (PST) Received: from hotmail.com (f156.law15.hotmail.com [64.4.23.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB3A743E42; Thu, 21 Nov 2002 05:28:40 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 05:28:40 -0800 Received: from 195.219.129.206 by lw15fd.law15.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 13:28:40 GMT X-Originating-IP: [195.219.129.206] From: "soheil soheil" To: vlm@netli.com Cc: freebsd-net@freebsd.org Subject: Re: Pcap Date: Thu, 21 Nov 2002 13:28:40 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 13:28:40.0803 (UTC) FILETIME=[E7E27B30:01C29161] 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 Have You any sample ? and i want to know how the packet is writen on pcap buffer and how they will forward ? if they are forwarded after the saving or they will never be forwarded ? i mean that is this scenario true ? or not packet ----> ip_input -copy of packet---> writen to pcap |------> ip_forward >From: Lev Walkin >To: soheil soheil >Subject: Re: Pcap >Date: Wed, 20 Nov 2002 22:05:44 -0800 > >soheil soheil wrote: >>Hi >>can i use pcap to access all of the packets travel through my gateway >>THANX > >yes, you can. > > >-- >Lev Walkin >vlm@netli.com _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 8:47:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2106237B404 for ; Thu, 21 Nov 2002 08:47:44 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2168843E8A for ; Thu, 21 Nov 2002 08:47:31 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 77AD7431CC; Thu, 21 Nov 2002 17:47:26 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp02.uc3m.es (Postfix) with ESMTP id 1357499F34; Thu, 21 Nov 2002 17:47:24 +0100 (CET) Message-ID: <3DDD0E1B.80C8C4AA@it.uc3m.es> Date: Thu, 21 Nov 2002 17:47:23 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Cc: snap-users@kame.net Subject: Interrupt levels and concurrency 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 (again :) I'm doing my best, but I'm in a mess trying to understand the interrup levels and if I should take it into account to implement what I want to implement :) As I'm working with KAME source code, I will CC this question. (KAME people always help me a lot :) I have the following situation: I've got an array, which is filled in using received packets, but it can also be filled in using the function "getaddrinfo()". Finally, this array is searched inside ip_output() function. So I was thinking of implementing the interaction between "getaddrinfo" and this kernel-array using "sysctl" interface, but I was wondering if I need to low the interrup level to fill in this array inside the sysctl_function(), because it could happen that at the same time a new packet arrived at and it can try to access the same structure. I've implemented some other code with sysctls calls and I've never worried about the interrups levels, but now I've got a doubt... does "sysctl" takes into account the likehood of concurrent system calls ? I hope so.... Returning to my implementation, Would I have to worry about the case when "getaddrinfo" is calling to sysctl to add a new entry and then the function ip_output() begins to search the share structure also ? I can see that my array can be accesed from (at least) the following points: 1. User layer (getaddrinfo) 2. IP layer (ip_input, ip_output) I was thinking of calling directly to the sysctl_function() inside ip_input() and also inside ip_output(). I hope there's no problem with this. Could you suggest me anything ? You have a lot of experience with these topics, and any guideline or explanation that you give me will be very very thanksfully thanked (sorry for my awful English :) Thanks! -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 8:48:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE48737B401; Thu, 21 Nov 2002 08:48:47 -0800 (PST) Received: from hotmail.com (f7.law3.hotmail.com [209.185.241.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65F9D43E88; Thu, 21 Nov 2002 08:48:47 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 08:48:47 -0800 Received: from 199.84.165.3 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 16:48:46 GMT X-Originating-IP: [199.84.165.3] From: "Vincent Goupil" To: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Thu, 21 Nov 2002 16:48:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 16:48:47.0297 (UTC) FILETIME=[DC501310:01C2917D] 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 slow network response is that clients inside my firewall begin to have timeout when accessing web and mail and I begin to have problem reaching the box with ssh. I'll try the ifconfig down/up this afternoon. >other questions was: > - what is "Slow network response"? > - does ifconfig down/up helps? >tcpdump buffers output so >usful bits are some time after trouble. >In my case slowdown triggered by >arp scans > > > My network is composed with Windows 2000 servers and pro. > > 192.168.20.2 <- w2k srv > > 192.168.20.3 <- w2k srv > > 192.168.20.7 <- w2k srv > > 192.168.20.8 <- w2k srv > > 192.168.20.9 <- w2k srv > > 192.168.20.10 <- another freebsd box > > 192.168.20.210 <- the firewall > > > > 23:58:43.356569 arp who-has 192.168.20.99 tell 192.168.20.8 > > 23:58:46.471284 arp who-has 192.168.20.127 tell 192.168.20.3 > > 23:58:46.472257 arp who-has 192.168.20.127 tell 192.168.20.8 > > 23:59:04.543497 arp who-has 192.168.20.2 tell 192.168.20.3 > > 23:59:10.352106 arp who-has 192.168.20.7 tell 192.168.20.200 > > 23:59:15.827551 arp who-has 192.168.20.251 tell 192.168.20.7 > > 23:59:17.082626 arp who-has 192.168.20.201 tell 192.168.20.8 > > 23:59:20.245406 arp who-has 192.168.20.201 tell 192.168.20.112 > > 23:59:22.723713 arp who-has 192.168.20.104 tell 192.168.20.3 > > 23:59:26.517132 arp who-has 192.168.20.6 tell 192.168.20.8 > > 23:59:28.824120 arp who-has 192.168.20.7 tell 192.168.20.99 > > 23:59:29.801078 arp who-has 192.168.20.6 tell 192.168.20.7 > > 23:59:48.762973 arp who-has 192.168.20.165 tell 192.168.20.8 > > 23:59:55.203905 arp who-has 192.168.20.75 tell 192.168.20.3 > > 23:59:55.688710 arp who-has 192.168.20.114 tell 192.168.20.8 > > 23:59:55.861042 arp who-has 192.168.20.77 tell 192.168.20.8 > > 00:00:00.192659 arp who-has 192.168.20.106 tell 192.168.20.201 > > 00:00:04.337994 arp who-has 192.168.20.10 tell 192.168.20.8 > > 00:00:04.538035 arp who-has 192.168.20.10 tell 192.168.20.2 > > 00:00:04.775959 arp who-has 192.168.20.10 tell 192.168.20.3 > > 00:00:05.022385 arp who-has 192.168.20.10 tell 192.168.20.9 > > 00:00:05.066194 arp who-has 192.168.20.10 tell 192.168.20.7 > > 00:00:05.209935 arp who-has 192.168.20.10 tell 192.168.20.6 > > 00:00:20.085908 arp who-has 192.168.20.9 tell 192.168.20.3 > > 00:00:20.116177 arp who-has 192.168.20.9 tell 192.168.20.8 > > 00:00:22.235535 arp who-has 192.168.20.101 tell 192.168.20.8 > > 00:00:22.236614 arp who-has 192.168.20.101 tell 192.168.20.3 > > 00:00:23.118443 arp who-has 192.168.20.54 tell 192.168.20.3 > > 00:00:25.075679 arp who-has 192.168.20.7 tell 192.168.20.201 > > 00:00:29.815522 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:30.587208 arp who-has 192.168.20.157 (2f:69:70:63:68:65) tell > > 192.168.20.201 > > 00:00:31.810270 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:45.473558 arp who-has 192.168.20.177 tell 192.168.20.201 > > > > > > >From: "."@babolo.ru > > >To: Vincent Goupil > > >CC: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG > > >Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter > > >Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >MIME-Version: 1.0 > > >Received: from aaz.links.ru ([193.125.152.37]) by >mc6-f36.law1.hotmail.com > > >with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 19:08:36 -0800 > > >Received: from aaz.links.ru (aaz.links.ru [193.125.152.37])by >aaz.links.ru > > >(8.12.6/8.12.6) with ESMTP id gAK3AfDh006526;Wed, 20 Nov 2002 06:10:41 > > >+0300 (MSK)(envelope-from babolo@aaz.links.ru) > > >Received: (from babolo@localhost)by aaz.links.ru (8.12.6/8.12.6/Submit) >id > > >gAK3AeSv006525;Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> > > >X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; >no-hdr-encoding=1 > > >In-Reply-To: > > >X-Mailer: ELM [version 2.4ME+ PL99b (25)] > > >Return-Path: babolo@aaz.links.ru > > >X-OriginalArrivalTime: 20 Nov 2002 03:08:36.0969 (UTC) > > >FILETIME=[1E422D90:01C29042] > > > > > > > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter > > >v3.4.27. > > > > This system act as a firewall for an enterprise. They need high > > > > availability. I have 5 network card, all 3C905 (3*3c905B-TX and > > >2*905C-TX). > > > > I made this setup in july and it run fine until 3 weeks ago. The > > >first > > > > and second card are for the internet link (primary and backup). The > > >third > > > > is for DMZ and the fourth is for local network. The fifth is unused > > >(marked > > > > as down). Each card as is own IRQ (except the fifth that is shared >with > > >the > > > > first). The high availability is provided by the two internet link, >if > > >one > > > > goes down, the second take the load (change default route, ipf >rules, > > >ipnat > > > > rules and DNS records). This is done by a script running by cron. >We > > >can > > > > also do that manually. We have two /29 network for the first link >and > > >one > > > > /28 network for the second (we use alias on internet interfaces). >There > > >is > > > > only 3 services that run on the firewall: SSH (but only accessible >from > > >3 > > > > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one > > >subnet) > > > > > > > > We begin to have problem 3 weeks ago. The firewall begin to have a >slow > > > > response. I begin to have this arp message error (many times): > > > > arplookup 255.255.255.0 failed: host is not on local network > > > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > > > We reboot the server and the network fast as earlier. I finally >find > > > > something: when we use alias, we need to have at least one regular > > >netmask > > > > (instead of 255.255.255.255) for each network/subnetwork. My error >was > > >on > > > > the first link, my second sub-network was not configured properly. >I > > > > changed it and it stop to have these errors about arp but the >problem > > >wasn't > > > > resolved. The network continue to be slow until we reboot the >server. > > >This > > > > happen during the day. Now, it happen everytime. > > > > > > > > What I've done: > > > > - I changed the netmask (as said earlier) > > > > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > > > > - I look for IRQ conflict > > > > - I configure all interface with media and mediaopt. They not using > > > > autodetect anymore. > > > > - I chkrootkit and nothing found > > > > > > > > What I suspect: > > > > - I read in a forum that the driver (xl) of 3C905 is not the best >for > > > > FreeBSD. I don't know if this apply to 4.6.2. > > > > - Ethernet cables (I need to change it) > > > > - We run SSL (with a lot of users) in one of our web servers in the >dmz. > > >As > > > > I know, SSL run on top of TCP, it should not be a problem. > > > > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not > > >promisc" > > > > and "xl1 is not promisc". I have 5 interfaces, what about the >others ? > > > > > > > > Can someone have an idea ? > > >What you mean when say "Slow network response"? > > >If that mean that packets trawel long > > >from some host to host under question > > >as reported by tcpdump, does ifconfig xlN down > > >and then ifconfig xlN up repare situation > > >for some time? > > >What tcpdump -npi xlN ether broadcast and not ip > > >say when slowdown hapens? > > > > > >-- > > >@BABOLO http://links.ru/ > > > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > >-- >@BABOLO http://links.ru/ > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-isp" in the body of the message _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 9:53:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F182F37B401 for ; Thu, 21 Nov 2002 09:53:33 -0800 (PST) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 088B343E8A for ; Thu, 21 Nov 2002 09:53:33 -0800 (PST) (envelope-from rik@cronyx.ru) Received: by hanoi.cronyx.ru id UAA54979 for freebsd-net@FreeBSD.org.checked; (8.9.3/vak/2.1) Thu, 21 Nov 2002 20:50:03 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id UAA54891; (8.9.3/vak/2.1) Thu, 21 Nov 2002 20:48:05 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <3DDD1D67.4050905@cronyx.ru> Date: Thu, 21 Nov 2002 20:52:39 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Wunsch , freebsd-net@FreeBSD.org Subject: sppp patch's References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011231165245.B73897@uriah.heep.sax.de> Content-Type: multipart/mixed; boundary="------------080103090805090608070207" 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. --------------080103090805090608070207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Sppp still have a quantity of bugs. Here is one of them: --- if_spppsubr.c.orig Wed Oct 16 18:41:16 2002 +++ if_spppsubr.c Thu Nov 21 20:13:16 2002 @@ -1672,12 +1672,12 @@ case STATE_ACK_SENT: break; case STATE_CLOSING: - sppp_cp_change_state(cp, sp, STATE_CLOSED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_CLOSED); break; case STATE_STOPPING: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; case STATE_ACK_RCVD: sppp_cp_change_state(cp, sp, STATE_REQ_SENT); @@ -1991,8 +1991,8 @@ case STATE_CLOSING: break; case STATE_STARTING: - sppp_cp_change_state(cp, sp, STATE_INITIAL); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_INITIAL); break; case STATE_STOPPED: sppp_cp_change_state(cp, sp, STATE_CLOSED); @@ -2031,18 +2031,18 @@ /* TO- event */ switch (sp->state[cp->protoidx]) { case STATE_CLOSING: - sppp_cp_change_state(cp, sp, STATE_CLOSED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_CLOSED); break; case STATE_STOPPING: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; case STATE_REQ_SENT: case STATE_ACK_RCVD: case STATE_ACK_SENT: - sppp_cp_change_state(cp, sp, STATE_STOPPED); (cp->tlf)(sp); + sppp_cp_change_state(cp, sp, STATE_STOPPED); break; } else In all cases we have the same problem: at first we should call tlf that will changes state and then we should set proper state. If we set some state and then call tlf we will get wrong final state. Best regards, Roman Kurakin --------------080103090805090608070207 Content-Type: application/x-java-applet;version=1.1.1; name="pch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="pch" LS0tIGlmX3NwcHBzdWJyLmMub3JpZwlXZWQgT2N0IDE2IDE4OjQxOjE2IDIwMDIKKysrIGlm X3NwcHBzdWJyLmMJVGh1IE5vdiAyMSAyMDoxMzoxNiAyMDAyCkBAIC0xNjcyLDEyICsxNjcy LDEyIEBACiAJCWNhc2UgU1RBVEVfQUNLX1NFTlQ6CiAJCQlicmVhazsKIAkJY2FzZSBTVEFU RV9DTE9TSU5HOgotCQkJc3BwcF9jcF9jaGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9DTE9T RUQpOwogCQkJKGNwLT50bGYpKHNwKTsKKwkJCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBz cCwgU1RBVEVfQ0xPU0VEKTsKIAkJCWJyZWFrOwogCQljYXNlIFNUQVRFX1NUT1BQSU5HOgot CQkJc3BwcF9jcF9jaGFuZ2Vfc3RhdGUoY3AsIHNwLCBTVEFURV9TVE9QUEVEKTsKIAkJCShj cC0+dGxmKShzcCk7CisJCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX1NU T1BQRUQpOwogCQkJYnJlYWs7CiAJCWNhc2UgU1RBVEVfQUNLX1JDVkQ6CiAJCQlzcHBwX2Nw X2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX1JFUV9TRU5UKTsKQEAgLTE5OTEsOCArMTk5 MSw4IEBACiAJY2FzZSBTVEFURV9DTE9TSU5HOgogCQlicmVhazsKIAljYXNlIFNUQVRFX1NU QVJUSU5HOgotCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX0lOSVRJQUwp OwogCQkoY3AtPnRsZikoc3ApOworCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNU QVRFX0lOSVRJQUwpOwogCQlicmVhazsKIAljYXNlIFNUQVRFX1NUT1BQRUQ6CiAJCXNwcHBf Y3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfQ0xPU0VEKTsKQEAgLTIwMzEsMTggKzIw MzEsMTggQEAKIAkJLyogVE8tIGV2ZW50ICovCiAJCXN3aXRjaCAoc3AtPnN0YXRlW2NwLT5w cm90b2lkeF0pIHsKIAkJY2FzZSBTVEFURV9DTE9TSU5HOgotCQkJc3BwcF9jcF9jaGFuZ2Vf c3RhdGUoY3AsIHNwLCBTVEFURV9DTE9TRUQpOwogCQkJKGNwLT50bGYpKHNwKTsKKwkJCXNw cHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwgU1RBVEVfQ0xPU0VEKTsKIAkJCWJyZWFrOwog CQljYXNlIFNUQVRFX1NUT1BQSU5HOgotCQkJc3BwcF9jcF9jaGFuZ2Vfc3RhdGUoY3AsIHNw LCBTVEFURV9TVE9QUEVEKTsKIAkJCShjcC0+dGxmKShzcCk7CisJCQlzcHBwX2NwX2NoYW5n ZV9zdGF0ZShjcCwgc3AsIFNUQVRFX1NUT1BQRUQpOwogCQkJYnJlYWs7CiAJCWNhc2UgU1RB VEVfUkVRX1NFTlQ6CiAJCWNhc2UgU1RBVEVfQUNLX1JDVkQ6CiAJCWNhc2UgU1RBVEVfQUNL X1NFTlQ6Ci0JCQlzcHBwX2NwX2NoYW5nZV9zdGF0ZShjcCwgc3AsIFNUQVRFX1NUT1BQRUQp OwogCQkJKGNwLT50bGYpKHNwKTsKKwkJCXNwcHBfY3BfY2hhbmdlX3N0YXRlKGNwLCBzcCwg U1RBVEVfU1RPUFBFRCk7CiAJCQlicmVhazsKIAkJfQogCWVsc2UK --------------080103090805090608070207-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 10:53:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A9637B401 for ; Thu, 21 Nov 2002 10:53:16 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFBDD43E4A for ; Thu, 21 Nov 2002 10:53:15 -0800 (PST) (envelope-from sloach@SANDVINE.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 13:53:14 -0500 Message-ID: From: Scot Loach To: "'freebsd-net@freebsd.org'" Subject: Using ipfw to forward udp Date: Thu, 21 Nov 2002 13:53:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to implement a type of transparent proxy for UDP. My idea was to use ipfw to redirect all incoming UDP packets to my server, for example: ipfw add fwd 127.0.0.1,9000 udp from any to any recv em0 However this doesn't seem to work: my server only receives UDP packets that are addressed to port 9000. Can anyone suggest what I might be doing wrong? thanks scot. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 11: 3:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CCD437B404 for ; Thu, 21 Nov 2002 11:03:49 -0800 (PST) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9596543E88 for ; Thu, 21 Nov 2002 11:03:42 -0800 (PST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gALJ3SY46134; Thu, 21 Nov 2002 20:03:29 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.68]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gALJ3Ukh045956; Thu, 21 Nov 2002 19:03:31 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDD2DF6.90005@ccrle.nec.de> Date: Thu, 21 Nov 2002 20:03:18 +0100 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scot Loach Cc: "'freebsd-net@freebsd.org'" Subject: Re: Using ipfw to forward udp 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 man ipfw says to fwd: fwd | forward ipaddr[,port] Change the next-hop on matching packets to ipaddr, which can be an IP address in dotted quad or a host name. The search termi- nates if this rule matches. If ipaddr is a local address, then matching packets will be for- warded to port (or the port number in the packet if one is not specified in the rule) on the local machine. If ipaddr is not a local address, then the port number (if speci- fied) is ignored, and the packet will be forwarded to the remote [...] This is exactly the behaviour you're describing. May be the divert is more appropriate for your needs. Martin Scot Loach wrote: > I'm trying to implement a type of transparent proxy for UDP. My idea was to > use ipfw to redirect all incoming UDP packets to my server, for example: > > ipfw add fwd 127.0.0.1,9000 udp from any to any recv em0 > > However this doesn't seem to work: my server only receives UDP packets that > are addressed to port 9000. > > Can anyone suggest what I might be doing wrong? > > thanks > > scot. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 11: 7:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CDDE37B401 for ; Thu, 21 Nov 2002 11:07:51 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABC9643E42 for ; Thu, 21 Nov 2002 11:07:50 -0800 (PST) (envelope-from sloach@SANDVINE.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 14:07:46 -0500 Message-ID: From: Scot Loach To: 'Martin Stiemerling' , Scot Loach Cc: "'freebsd-net@freebsd.org'" Subject: RE: Using ipfw to forward udp Date: Thu, 21 Nov 2002 14:07:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org According to the manual text quoted below, in my example the ipaddr is localhost and the port is 9000. So all UDP packets (matching packets) should be forwarded to 9000 (port) on the local machine. What I'm seeing is that no packets are forwarded to port 9000, and I only receive packets that were originally sent with a destination port of 9000. scot. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Thursday, November 21, 2002 2:03 PM To: Scot Loach Cc: 'freebsd-net@freebsd.org' Subject: Re: Using ipfw to forward udp man ipfw says to fwd: fwd | forward ipaddr[,port] Change the next-hop on matching packets to ipaddr, which can be an IP address in dotted quad or a host name. The search termi- nates if this rule matches. If ipaddr is a local address, then matching packets will be for- warded to port (or the port number in the packet if one is not specified in the rule) on the local machine. If ipaddr is not a local address, then the port number (if speci- fied) is ignored, and the packet will be forwarded to the remote [...] This is exactly the behaviour you're describing. May be the divert is more appropriate for your needs. Martin Scot Loach wrote: > I'm trying to implement a type of transparent proxy for UDP. My idea was to > use ipfw to redirect all incoming UDP packets to my server, for example: > > ipfw add fwd 127.0.0.1,9000 udp from any to any recv em0 > > However this doesn't seem to work: my server only receives UDP packets that > are addressed to port 9000. > > Can anyone suggest what I might be doing wrong? > > thanks > > scot. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 11:10:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3809937B401 for ; Thu, 21 Nov 2002 11:10:13 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75D1243E4A for ; Thu, 21 Nov 2002 11:10:12 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <20021121191010001009l14pe>; Thu, 21 Nov 2002 19:10:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA04311; Thu, 21 Nov 2002 11:10:04 -0800 (PST) Date: Thu, 21 Nov 2002 11:10:00 -0800 (PST) From: Julian Elischer To: Scot Loach Cc: "'freebsd-net@freebsd.org'" Subject: Re: Using ipfw to forward udp 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 the local fwd command is only implemented for TCP On Thu, 21 Nov 2002, Scot Loach wrote: > I'm trying to implement a type of transparent proxy for UDP. My idea was to > use ipfw to redirect all incoming UDP packets to my server, for example: > > ipfw add fwd 127.0.0.1,9000 udp from any to any recv em0 > > However this doesn't seem to work: my server only receives UDP packets that > are addressed to port 9000. > > Can anyone suggest what I might be doing wrong? > > thanks > > scot. > > 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 21 11:15:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37BBC37B401 for ; Thu, 21 Nov 2002 11:15:55 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCB4143E8A for ; Thu, 21 Nov 2002 11:15:54 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.168.4]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021121191508.BODK1052.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 21 Nov 2002 19:15:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA04338; Thu, 21 Nov 2002 11:12:06 -0800 (PST) Date: Thu, 21 Nov 2002 11:12:06 -0800 (PST) From: Julian Elischer To: Scot Loach Cc: "'freebsd-net@freebsd.org'" Subject: Re: Using ipfw to forward udp 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 On Thu, 21 Nov 2002, Julian Elischer wrote: > the local fwd command is only implemented for TCP > (patches accepted :-) > > On Thu, 21 Nov 2002, Scot Loach wrote: > > > I'm trying to implement a type of transparent proxy for UDP. My idea was to > > use ipfw to redirect all incoming UDP packets to my server, for example: > > > > ipfw add fwd 127.0.0.1,9000 udp from any to any recv em0 > > > > However this doesn't seem to work: my server only receives UDP packets that > > are addressed to port 9000. > > > > Can anyone suggest what I might be doing wrong? > > > > thanks > > > > scot. > > > > 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 Thu Nov 21 11:17:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED56137B401; Thu, 21 Nov 2002 11:17:18 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F34B43E88; Thu, 21 Nov 2002 11:17:18 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gALJH9Ah023578; Thu, 21 Nov 2002 11:17:09 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gALJH9q7023577; Thu, 21 Nov 2002 11:17:09 -0800 (PST) (envelope-from rizzo) Date: Thu, 21 Nov 2002 11:17:09 -0800 From: Luigi Rizzo To: current@freebsd.org Subject: mbuf header bloat ? Message-ID: <20021121111709.A23435@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.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 [Bcc to -net because it is relevant there. This email has been triggered by a private discussion i was having with other committers (who will easily recognise themselves :) which suggested the possibility of adding more fields to mbuf headers] Just recently came up to my attention that we have the following code in #define MAC_MAX_POLICIES 4 struct label { int l_flags; union { void *l_ptr; long l_long; } l_perpolicy[MAC_MAX_POLICIES]; }; (what are l_perpolicy[], ints ? Could this be written a bit better ?) and then in struct pkthdr { struct ifnet *rcvif; /* rcv interface */ int len; /* total packet length */ /* variables for ip and tcp reassembly */ void *header; /* pointer to packet header */ /* variables for hardware checksum */ int csum_flags; /* flags regarding checksum */ int csum_data; /* data field used by csum routines */ SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ struct label label; /* MAC label of data in packet */ }; The label is 5 ints, the pkthdr a total of 11 ints (and m_hdr takes another 6, for a total of 136 bytes of header info on 64-bit architectures). Of the pkthdr, only 3 fields (rcvif, len, tags) are of really general use, the rest being used only in certain cases and for very specific purposes (e.g. reassembly of fragments, or hw capabilities, or MAC). Now that Sam has done the excellent work of integrating packet tags to carry annotations around, i really believe that we should try to move out of the pkthdr all non-general fields, and move them to m_tags so we only pay the cost when needed and not in all cases. Also this pays a lot in terms of ABI compatibility and extensibility. I understand that for 5.0 it is a bit late to act, but i do hope that we can reconsider this issue for 5.1 and pull out of the pkthdr at least the MAC label, and possibly also the csum_* fields, much in the same way it has been done for VLAN labels. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 11:49:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 906B437B401 for ; Thu, 21 Nov 2002 11:49:19 -0800 (PST) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEABF43ECD for ; Thu, 21 Nov 2002 11:49:15 -0800 (PST) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0.1) with PIPE id 2440011; Thu, 21 Nov 2002 22:48:56 +0300 Date: Thu, 21 Nov 2002 22:48:47 +0300 From: Nikolai Saoukh To: freebsd-net@freebsd.org Subject: ports/l2tpd -- any success stories? Message-ID: <20021121194847.GA1741@otdel1.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If one was successful to run this beast, could you share with us your configs? 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 21 12:24:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3379137B401 for ; Thu, 21 Nov 2002 12:24:29 -0800 (PST) Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A789A43E42 for ; Thu, 21 Nov 2002 12:24:26 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18Exru-0000Gq-00; Thu, 21 Nov 2002 23:24:10 +0300 Subject: Re: mpd pptp freebsd <-> linux setup From: "Vladimir B. " Grebenschikov To: Archie Cobbs Cc: "net@freebsd.org" In-Reply-To: <200211210030.gAL0U4WV063035@arch20m.dellroad.org> References: <200211210030.gAL0U4WV063035@arch20m.dellroad.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: TSB "Russian Express" Message-Id: <1037910248.914.8.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 21 Nov 2002 23:24:10 +0300 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 =F7 Thu, 21.11.2002, =D7 03:30, Archie Cobbs =CE=C1=D0=C9=D3=C1=CC: > Vladimir B. Grebenschikov wrote: > > can anyone help me setup mpd pptp link (as client) > > to Linux pptp server ? >=20 > The mpd log shows that you are requiring the peer to authenticate > but the peer doesn't want to. That's why LCP is failing to converge. >=20 > Try adding "set link disable chap" to mpd.conf. Thanx, it helps, now I can get session established, but unfortunately it does not work :( [pptp] CCP: SendConfigReq #2 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp] CCP: rec'd Configure Request #2 link 0 (Req-Sent) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp] CCP: SendConfigAck #2 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp] CCP: state change Req-Sent --> Ack-Sent [pptp] IPCP: rec'd Configure Ack #2 link 0 (Ack-Sent) IPADDR 192.168.1.121 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp] IPCP: state change Ack-Sent --> Opened [pptp] IPCP: LayerUp 192.168.1.121 -> 192.168.1.1 [pptp] IFACE: Up event [pptp] exec: /sbin/ifconfig pptp0 192.168.1.121 192.168.1.1 netmask 0xffffffff -link0 [pptp] IFACE: Up event [pptp] CCP: rec'd Configure Ack #2 link 0 (Ack-Sent) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp] CCP: state change Ack-Sent --> Opened [pptp] CCP: LayerUp Compress using: MPPE, 128 bit, stateless Decompress using: MPPE, 128 bit, stateless Session established, but then I am trying to ping other end I get: [pptp] LCP: rec'd Protocol Reject #2 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #3 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: no reply to 1 echo request(s) [pptp] LCP: rec'd Protocol Reject #4 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #5 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #6 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #7 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #8 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #9 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected one reject per ping, what I am doing wrong ? (I have try to change compression/encryption options but without luck) > -Archie --=20 Vladimir B. Grebenschikov TSB "Russian Express" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 12:30:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 022F537B404 for ; Thu, 21 Nov 2002 12:30:36 -0800 (PST) Received: from web21412.mail.yahoo.com (web21412.mail.yahoo.com [216.136.232.81]) by mx1.FreeBSD.org (Postfix) with SMTP id 79C8F43E9C for ; Thu, 21 Nov 2002 12:30:35 -0800 (PST) (envelope-from zopewiz@yahoo.com) Message-ID: <20021121203035.60556.qmail@web21412.mail.yahoo.com> Received: from [63.170.174.190] by web21412.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 12:30:35 PST Date: Thu, 21 Nov 2002 12:30:35 -0800 (PST) From: Carlos Carnero Subject: Is there such a thing like a TCP proxy|relay? To: FreeBSD Network Cc: FreeBSD Questions 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, ok, this is another wacky question. I have connected two subnetworks to my FreeBSD router to the internet. By design they shouln't be able to communicate between them--which I have done with IP Filter. What I'd like to do now is to make a TCP proxy/relay on my firewall/router. For instance, opening port 3389 on the firewall (from the inside, machine A) would open port 3389 of machine B that sits on the other network. Is there a port that can handle that? I don't need encryption, so (I think) that SSH tunnels are way too much for me. Best regards, Carlos. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 12:43:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACD4737B401; Thu, 21 Nov 2002 12:43:31 -0800 (PST) Received: from mail2.uits.uconn.edu (mail2.uits.uconn.edu [137.99.25.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1930F43E91; Thu, 21 Nov 2002 12:43:27 -0800 (PST) (envelope-from matt@forsetti.com) Received: from [137.99.80.149] (d80h149.public.uconn.edu [137.99.80.149]) by mail2.uits.uconn.edu (8.11.6/8.11.6) with ESMTP id gALKh0f29110; Thu, 21 Nov 2002 15:43:00 -0500 Subject: Re: Is there such a thing like a TCP proxy|relay? From: Matt Smith To: Carlos Carnero Cc: FreeBSD Network , FreeBSD Questions In-Reply-To: <20021121203035.60556.qmail@web21412.mail.yahoo.com> References: <20021121203035.60556.qmail@web21412.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Message-Id: <1037911380.17384.8.camel@d80h149.public.uconn.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 21 Nov 2002 15:43:00 -0500 Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.9, required 6, AWL, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think you want NAT: man ipnat man natd -Matt On Thu, 2002-11-21 at 15:30, Carlos Carnero wrote: > Hi, > > ok, this is another wacky question. I have connected > two subnetworks to my FreeBSD router to the internet. > By design they shouln't be able to communicate between > them--which I have done with IP Filter. > > What I'd like to do now is to make a TCP proxy/relay > on my firewall/router. For instance, opening port 3389 > on the firewall (from the inside, machine A) would > open port 3389 of machine B that sits on the other > network. > > Is there a port that can handle that? > > I don't need encryption, so (I think) that SSH tunnels > are way too much for me. > > Best regards, > Carlos. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- Matt Smith To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 12:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41DC337B401 for ; Thu, 21 Nov 2002 12:45:05 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C7C343E9E for ; Thu, 21 Nov 2002 12:45:04 -0800 (PST) (envelope-from archie@dellroad.org) 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 MAA84142; Thu, 21 Nov 2002 12:41:43 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gALKfgOS067024; Thu, 21 Nov 2002 12:41:43 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gALKfgJe067023; Thu, 21 Nov 2002 12:41:42 -0800 (PST) From: Archie Cobbs Message-Id: <200211212041.gALKfgJe067023@arch20m.dellroad.org> Subject: Re: mpd pptp freebsd <-> linux setup In-Reply-To: <1037910248.914.8.camel@vbook> To: "Vladimir B. Grebenschikov" Date: Thu, 21 Nov 2002 12:41:42 -0800 (PST) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Vladimir B. Grebenschikov wrote: > Session established, but then I am trying to ping other end I get: > > [pptp] LCP: rec'd Protocol Reject #2 link 0 (Opened) > [pptp] LCP: protocol 0x2145 was rejected > [pptp] LCP: rec'd Protocol Reject #3 link 0 (Opened) > [pptp] LCP: protocol 0x2145 was rejected Looks like the other side is semi-broken. It's interpreting 0x21 0x45 as a two byte protocol ID, whereas really it's a one byte compressed protocol ID (0x0021) followed by the first byte of an IP packet (0x45). That's clearly broken, because only the last byte of a protocol ID can be odd. Perhaps it's not expecting the 0x0021 to be protocol-compressed... the MPPE RFC (3078) is silent on whether or not that's allowed. Try the patch below and see if that helps. You might also report the bug to whoever maintains the Linux PPP daemon. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- sys/netgraph/ng_ppp.c.orig Thu Nov 21 12:39:06 2002 +++ sys/netgraph/ng_ppp.c Thu Nov 21 12:39:26 2002 @@ -744,7 +744,7 @@ case HOOK_INDEX_VJC_VJIP: if (priv->conf.enableCompression && priv->hooks[HOOK_INDEX_COMPRESS] != NULL) { - if ((m = ng_ppp_addproto(m, proto, 1)) == NULL) { + if ((m = ng_ppp_addproto(m, proto, 0)) == NULL) { NG_FREE_META(meta); return (ENOBUFS); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 12:55:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E1E37B401; Thu, 21 Nov 2002 12:55:18 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EFCB43E88; Thu, 21 Nov 2002 12:55:17 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gALKtGm9005830; Thu, 21 Nov 2002 12:55:16 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gALKtG54005829; Thu, 21 Nov 2002 12:55:16 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Thu, 21 Nov 2002 12:55:15 -0800 From: David Schultz To: Petri Helenius Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small Message-ID: <20021121205515.GA5716@HAL9000.homeunix.com> Mail-Followup-To: Petri Helenius , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> <11fd01c290eb$f48311e0$862a40c1@PHE> <20021121022524.GA2300@HAL9000.homeunix.com> <126801c2912c$5be3cec0$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii:iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <126801c2912c$5be3cec0$862a40c1@PHE> 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 Thus spake Petri Helenius : > > > With about 150M in use and KVA_PAGES undefined in config (default), > > > both 4.7-STABLE and 5.0-CURRENT panic (1G installed memory). > > > > Yes, the default is 256, IIRC. That corresponds to 1 GB of KVA, > > and you have only 1 GB of physical memory to back it. I take it > > this is a very busy machine. Short of getting more memory, you > > can decrease memory utilization by the network, e.g. by decreasing > > TCP window sizes, or you can limit memory usage by the network so > > you don't get panics. I forget the details here, so perhaps > > someone else can fill them in. > > > The thing I´m concerned about that if with 150M kernel memory usage and > >200M free and >300M inact memory the system panics, how much "extra" > memory is needed to keep it running? And the swap is never touched. Most kernel memory is not pageable, so swap probably won't help you. Your `kmem_map too small' error message should report to you the size of the attempted allocation and the size of kmem_map. If the map really isn't full, I'm not sure why you would get this panic, unless you're somehow running into excessive fragmentation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 12:59:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADDAC37B40A; Thu, 21 Nov 2002 12:59:42 -0800 (PST) Received: from cypress.adhesivemedia.com (cypress.adhesivemedia.com [207.202.159.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D14043E88; Thu, 21 Nov 2002 12:59:42 -0800 (PST) (envelope-from philip@adhesivemedia.com) Received: from cypress.adhesivemedia.com (localhost [127.0.0.1]) by cypress.adhesivemedia.com (8.12.3/8.12.3) with ESMTP id gALKxSFk070265; Thu, 21 Nov 2002 12:59:28 -0800 (PST) (envelope-from philip@adhesivemedia.com) Received: from localhost (philip@localhost) by cypress.adhesivemedia.com (8.12.3/8.12.3/Submit) with ESMTP id gALKxStX070262; Thu, 21 Nov 2002 12:59:28 -0800 (PST) X-Authentication-Warning: cypress.adhesivemedia.com: philip owned process doing -bs Date: Thu, 21 Nov 2002 12:59:28 -0800 (PST) From: Philip Hallstrom To: Carlos Carnero Cc: FreeBSD Network , FreeBSD Questions Subject: Re: Is there such a thing like a TCP proxy|relay? In-Reply-To: <20021121203035.60556.qmail@web21412.mail.yahoo.com> Message-ID: <20021121125925.L66511-100000@cypress.adhesivemedia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org http://www.freebsd.org/cgi/ports.cgi?query=3Dtcp%20proxy&stype=3Dall On Thu, 21 Nov 2002, Carlos Carnero wrote: > Hi, > > ok, this is another wacky question. I have connected > two subnetworks to my FreeBSD router to the internet. > By design they shouln't be able to communicate between > them--which I have done with IP Filter. > > What I'd like to do now is to make a TCP proxy/relay > on my firewall/router. For instance, opening port 3389 > on the firewall (from the inside, machine A) would > open port 3389 of machine B that sits on the other > network. > > Is there a port that can handle that? > > I don't need encryption, so (I think) that SSH tunnels > are way too much for me. > > Best regards, > Carlos. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus =96 Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 21 13: 3:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7C2B37B696; Thu, 21 Nov 2002 13:03:26 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3E443E88; Thu, 21 Nov 2002 13:03:25 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gALL3HuO049959; Thu, 21 Nov 2002 23:03:19 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DDD4A15.4030209@he.iki.fi> Date: Thu, 21 Nov 2002 23:03:17 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: David Schultz Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> <11fd01c290eb$f48311e0$862a40c1@PHE> <20021121022524.GA2300@HAL9000.homeunix.com> <126801c2912c$5be3cec0$862a40c1@PHE> <20021121205515.GA5716@HAL9000.homeunix.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org David Schultz wrote: >Most kernel memory is not pageable, so swap probably won't help >you. Your `kmem_map too small' error message should report to you >the size of the attempted allocation and the size of kmem_map. >If the map really isn't full, I'm not sure why you would get this >panic, unless you're somehow running into excessive fragmentation. > > Nov 3 21:44:52 giga /kernel: panic: kmem_malloc(71000064): kmem_map too small: 183193600 total allocated Nov 3 22:10:30 giga /kernel: panic: kmem_malloc(71000064): kmem_map too small: 175476736 total allocated This is what I'm seeing. Most of the kernel allocated memory was free at the time the panic occurred, but fragmented though. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:16: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34E5337B401 for ; Thu, 21 Nov 2002 13:16:07 -0800 (PST) Received: from softweyr.com (softweyr.com [209.63.227.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91F0943E6E for ; Thu, 21 Nov 2002 13:16:06 -0800 (PST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 18Eyg4-0002uM-00; Thu, 21 Nov 2002 14:16:00 -0700 Message-ID: <3DDD4D11.15376311@softweyr.com> Date: Thu, 21 Nov 2002 13:16:01 -0800 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: Sockets and changing IP addresses References: <200211122316.gACNGqWC017440@arch20m.dellroad.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 Archie Cobbs wrote: > > I'm curious what -net's opinion is on PR kern/38544: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 > > In summary: if you have a connected socket whose local IP address > is X, and then change the interface IP address from X to Y, then > packets written out by the socket will continue to be transmitted > with source IP address X. > > Do people agree that this is a bug and should be fixed? Yes. The other end can't possibly reply to address X, so the connection is broken at this point. > Do people agree that my suggestion of returning ENETDOWN is reasonable? Wow. There are other possibilities, EADDRNOTAVAIL or ECONNABORTED. It doesn't matter so long as it the errno is unique to this situation across all syscalls that might encounter it; ENETDOWN seems to meet this criteria. > If so, what would be the most efficient way to implement this? > Obviously we'd like to avoid searching the entire IP address list > for every outgoing packet. Would it work to only do that search if > the socket's cached route is invalid? Etc. My initial reaction is this should take care of the problem, but I haven't backed that up with any testing. SIOCSIFADDR on an interface does remove all routes for the interface and then rebuild routes for all now-existing addresses, so any cached routes on that interface will now be invalid. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:18:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8208E37B401; Thu, 21 Nov 2002 13:18:40 -0800 (PST) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id B296343E3B; Thu, 21 Nov 2002 13:18:33 -0800 (PST) (envelope-from ian.watkinson@ehsbrann.com) Received: from subtlety ([80.3.50.15]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021121211827.WNHK18167.mta06-svc.ntlworld.com@subtlety>; Thu, 21 Nov 2002 21:18:27 +0000 Reply-To: From: "Ian Watkinson" To: , , Subject: VPN Date: Thu, 21 Nov 2002 21:18:27 -0000 Organization: EHSBrann Message-ID: <062a01c291a3$8b63b760$6502010a@subtlety> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <3DDBDE2B.6050407@he.iki.fi> Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Been looking at a number of how-to's on the web for connecting Win2k clients to Freebsd as a VPN. However, despite carefully following them, I can't get any of them to work. Could someone on the list who has managed this, either point me in the direction of a how-to that works, or share their config That works with the list? Many thanks in advance. -- Ian Watkinson ================== ICQ 2781385 Internet Pager 2781385@pager.icq.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:20:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 816BC37B401 for ; Thu, 21 Nov 2002 13:20:18 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A17343E91 for ; Thu, 21 Nov 2002 13:20:11 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id WAA05176; Thu, 21 Nov 2002 22:20:04 +0100 (CET) Received: from uriah.heep.sax.de (localhost.heep.sax.de [127.0.0.1]) by uriah.heep.sax.de (8.12.5/8.12.5) with ESMTP id gALLIXWc084881; Thu, 21 Nov 2002 22:18:33 +0100 (MET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.12.5/8.12.5/Submit) id gALLIXto084880; Thu, 21 Nov 2002 22:18:33 +0100 (MET) (envelope-from j) Date: Thu, 21 Nov 2002 22:18:33 +0100 From: Joerg Wunsch To: Roman Kurakin Cc: freebsd-net@FreeBSD.org Subject: Re: sppp patch's Message-ID: <20021121221833.A70987@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011231165245.B73897@uriah.heep.sax.de> <3DDD1D67.4050905@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DDD1D67.4050905@cronyx.ru>; from rik@cronyx.ru on Thu, Nov 21, 2002 at 08:52:39PM +0300 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Roman Kurakin wrote: > Sppp still have a quantity of bugs. Here is one of them: > > --- if_spppsubr.c.orig Wed Oct 16 18:41:16 2002 > +++ if_spppsubr.c Thu Nov 21 20:13:16 2002 > @@ -1672,12 +1672,12 @@ > case STATE_ACK_SENT: > break; > case STATE_CLOSING: > - sppp_cp_change_state(cp, sp, STATE_CLOSED); > (cp->tlf)(sp); > + sppp_cp_change_state(cp, sp, STATE_CLOSED); > break; [...] > In all cases we have the same problem: at first we should call tlf > that will changes state and then we should set proper state. If we > set some state and then call tlf we will get wrong final state. Can you please explain more, e. g. with a ifconfig debug trace? The RFC doesn't mandate a particular order between the actions and the actual state change, and IIRC (without digging down into the code right now), reverting the order has other unwanted side effects. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:24:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE4D37B404 for ; Thu, 21 Nov 2002 13:24:21 -0800 (PST) Received: from web21407.mail.yahoo.com (web21407.mail.yahoo.com [216.136.232.77]) by mx1.FreeBSD.org (Postfix) with SMTP id A779743E91 for ; Thu, 21 Nov 2002 13:24:20 -0800 (PST) (envelope-from zopewiz@yahoo.com) Message-ID: <20021121212420.10413.qmail@web21407.mail.yahoo.com> Received: from [63.170.174.190] by web21407.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 13:24:20 PST Date: Thu, 21 Nov 2002 13:24:20 -0800 (PST) From: Carlos Carnero Subject: Re: Is there such a thing like a TCP proxy|relay? To: Matt Smith Cc: FreeBSD Network , FreeBSD Questions In-Reply-To: <1037911380.17384.8.camel@d80h149.public.uconn.edu> 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 think you want NAT: Umm, not really. Following Mr. Hallstrom suggestion I tried balance and it works beautifully for my needs. Thanks a lot :) Carlos. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:28:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D61DD37B401; Thu, 21 Nov 2002 13:28:07 -0800 (PST) Received: from cypress.adhesivemedia.com (cypress.adhesivemedia.com [207.202.159.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9521D43EA9; Thu, 21 Nov 2002 13:28:06 -0800 (PST) (envelope-from philip@adhesivemedia.com) Received: from cypress.adhesivemedia.com (localhost [127.0.0.1]) by cypress.adhesivemedia.com (8.12.3/8.12.3) with ESMTP id gALLRxFk071056; Thu, 21 Nov 2002 13:27:59 -0800 (PST) (envelope-from philip@adhesivemedia.com) Received: from localhost (philip@localhost) by cypress.adhesivemedia.com (8.12.3/8.12.3/Submit) with ESMTP id gALLRxA0071052; Thu, 21 Nov 2002 13:27:59 -0800 (PST) X-Authentication-Warning: cypress.adhesivemedia.com: philip owned process doing -bs Date: Thu, 21 Nov 2002 13:27:59 -0800 (PST) From: Philip Hallstrom To: Ian Watkinson Cc: freebsd-questions@FreeBSD.ORG, , Subject: Re: VPN In-Reply-To: <062a01c291a3$8b63b760$6502010a@subtlety> Message-ID: <20021121132753.I66511-100000@cypress.adhesivemedia.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 this worked for me the last time I did it. http://stuff.adhesivemedia.com/freebsd/mpd.php On Thu, 21 Nov 2002, Ian Watkinson wrote: > Been looking at a number of how-to's on the web for connecting Win2k > clients to Freebsd as a VPN. > > However, despite carefully following them, I can't get any of them to > work. > > Could someone on the list who has managed this, either point me in the > direction of a how-to that works, or share their config > That works with the list? > > Many thanks in advance. > > -- > > Ian Watkinson > ================== > > ICQ 2781385 > Internet Pager 2781385@pager.icq.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" 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 21 13:33:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC12037B401 for ; Thu, 21 Nov 2002 13:33:27 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26D7843EAC for ; Thu, 21 Nov 2002 13:33:27 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 16:33:22 -0500 Message-ID: From: Don Bowman To: 'Wes Peters' , Archie Cobbs Cc: freebsd-net@freebsd.org Subject: RE: Sockets and changing IP addresses Date: Thu, 21 Nov 2002 16:33:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Wes Peters [mailto:wes@softweyr.com] > Archie Cobbs wrote: > > > > I'm curious what -net's opinion is on PR kern/38544: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 > > > > In summary: if you have a connected socket whose local IP address > > is X, and then change the interface IP address from X to Y, then > > packets written out by the socket will continue to be transmitted > > with source IP address X. > > > > Do people agree that this is a bug and should be fixed? > > Yes. The other end can't possibly reply to address X, so the > connection > is broken at this point. > I think the current behaviour is correct. Since the IP->MAC lookup will remain cached, the communication will continue to work to the old IP. Changing the IP on the connected socket will make the connection drop. The best case is the the way it works. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:34:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE9A37B401 for ; Thu, 21 Nov 2002 13:34:47 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E7843E91 for ; Thu, 21 Nov 2002 13:34:47 -0800 (PST) (envelope-from justin@mac.com) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gALLYlau013722 for ; Thu, 21 Nov 2002 13:34:47 -0800 (PST) Received: from grinch ([12.234.224.67]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H5Y3XY00.83Y for ; Thu, 21 Nov 2002 13:34:46 -0800 Date: Thu, 21 Nov 2002 13:34:45 -0800 Subject: Re: Sockets and changing IP addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: "Justin C. Walker" To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <3DDD4D11.15376311@softweyr.com> Message-Id: <0DC02941-FD99-11D6-81FD-00306544D642@mac.com> X-Mailer: Apple Mail (2.482) 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 Thursday, November 21, 2002, at 01:16 PM, Wes Peters wrote: > Archie Cobbs wrote: >> >> I'm curious what -net's opinion is on PR kern/38544: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 >> >> In summary: if you have a connected socket whose local IP address >> is X, and then change the interface IP address from X to Y, then >> packets written out by the socket will continue to be transmitted >> with source IP address X. >> >> Do people agree that this is a bug and should be fixed? > > Yes. The other end can't possibly reply to address X, so the connection > is broken at this point. > >> Do people agree that my suggestion of returning ENETDOWN is reasonable? > > Wow. There are other possibilities, EADDRNOTAVAIL or ECONNABORTED. > It doesn't matter so long as it the errno is unique to this situation > across all syscalls that might encounter it; ENETDOWN seems to meet > this criteria. A thought: An attempt to reconnect will succeed, given the scenario above, and ENETDOWN implies that the network is unavailable, so I don't think this is a good response. ECONNABORTED might be better (and EADDRNOTAVAIL isn't really germane). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:36:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7A4237B404; Thu, 21 Nov 2002 13:36:33 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0219343E42; Thu, 21 Nov 2002 13:36:33 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gALLaWm9006043; Thu, 21 Nov 2002 13:36:32 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gALLaVEU006042; Thu, 21 Nov 2002 13:36:31 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Thu, 21 Nov 2002 13:36:31 -0800 From: David Schultz To: Petri Helenius Cc: freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small Message-ID: <20021121213631.GA5987@HAL9000.homeunix.com> Mail-Followup-To: Petri Helenius , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0e3b01c28fc4$ff9a4ee0$862a40c1@PHE> <20021119152114.GA2228@HAL9000.homeunix.com> <3DDBDE2B.6050407@he.iki.fi> <20021120195919.GA679@HAL9000.homeunix.com> <11fd01c290eb$f48311e0$862a40c1@PHE> <20021121022524.GA2300@HAL9000.homeunix.com> <126801c2912c$5be3cec0$862a40c1@PHE> <20021121205515.GA5716@HAL9000.homeunix.com> <3DDD4A15.4030209@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDD4A15.4030209@he.iki.fi> 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 Thus spake Petri Helenius : > >Most kernel memory is not pageable, so swap probably won't help > >you. Your `kmem_map too small' error message should report to you > >the size of the attempted allocation and the size of kmem_map. > >If the map really isn't full, I'm not sure why you would get this > >panic, unless you're somehow running into excessive fragmentation. > > > > > > Nov 3 21:44:52 giga /kernel: panic: kmem_malloc(71000064): kmem_map too > small: 183193600 total allocated > Nov 3 22:10:30 giga /kernel: panic: kmem_malloc(71000064): kmem_map too > small: 175476736 total allocated > > This is what I'm seeing. Most of the kernel allocated memory was free at > the time the panic occurred, but > fragmented though. 71 MB of contiguous wired memory is a huge amount to expect in the kernel at runtime. What exactly are you trying to do? Can you post a backtrace? I'm not a networking guru, so I probably won't be able to tell you what you might not be able to do differently, although you might have better luck if you tried to grab the memory earlier on, when KVA is relatively unfragmented. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 13:49:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35EBA37B401 for ; Thu, 21 Nov 2002 13:49:13 -0800 (PST) Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C1E43E97 for ; Thu, 21 Nov 2002 13:49:12 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18EzC6-0000aC-00; Fri, 22 Nov 2002 00:49:06 +0300 Subject: Re: mpd pptp freebsd <-> linux setup From: "Vladimir B. " Grebenschikov To: Archie Cobbs Cc: "net@freebsd.org" In-Reply-To: <200211212041.gALKfgJe067023@arch20m.dellroad.org> References: <200211212041.gALKfgJe067023@arch20m.dellroad.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: TSB "Russian Express" Message-Id: <1037915344.914.18.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 22 Nov 2002 00:49:05 +0300 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 =F7 Thu, 21.11.2002, =D7 23:41, Archie Cobbs =CE=C1=D0=C9=D3=C1=CC: > Vladimir B. Grebenschikov wrote: > > Session established, but then I am trying to ping other end I get: > >=20 > > [pptp] LCP: rec'd Protocol Reject #2 link 0 (Opened) > > [pptp] LCP: protocol 0x2145 was rejected > > [pptp] LCP: rec'd Protocol Reject #3 link 0 (Opened) > > [pptp] LCP: protocol 0x2145 was rejected >=20 > Looks like the other side is semi-broken. It's interpreting 0x21 0x45 > as a two byte protocol ID, whereas really it's a one byte compressed > protocol ID (0x0021) followed by the first byte of an IP packet (0x45). > That's clearly broken, because only the last byte of a protocol ID can > be odd. >=20 > Perhaps it's not expecting the 0x0021 to be protocol-compressed... > the MPPE RFC (3078) is silent on whether or not that's allowed. >=20 > Try the patch below and see if that helps. You might also report > the bug to whoever maintains the Linux PPP daemon. Yes, patch hepls ! Thank you very mutch. > -Archie >=20 > _________________________________________________________________________= _ > Archie Cobbs * Packet Design * http://www.packetdesign.co= m >=20 > --- sys/netgraph/ng_ppp.c.orig Thu Nov 21 12:39:06 2002 > +++ sys/netgraph/ng_ppp.c Thu Nov 21 12:39:26 2002 > @@ -744,7 +744,7 @@ > case HOOK_INDEX_VJC_VJIP: > if (priv->conf.enableCompression > && priv->hooks[HOOK_INDEX_COMPRESS] !=3D NULL) { > - if ((m =3D ng_ppp_addproto(m, proto, 1)) =3D=3D NULL) { > + if ((m =3D ng_ppp_addproto(m, proto, 0)) =3D=3D NULL) { > NG_FREE_META(meta); > return (ENOBUFS); > } --=20 Vladimir B. Grebenschikov TSB "Russian Express" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 14: 0:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CC3037B401 for ; Thu, 21 Nov 2002 14:00:13 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B01A43EA3 for ; Thu, 21 Nov 2002 14:00:11 -0800 (PST) (envelope-from archie@dellroad.org) 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 NAA84649; Thu, 21 Nov 2002 13:53:42 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gALLrfOS067353; Thu, 21 Nov 2002 13:53:41 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gALLreeX067352; Thu, 21 Nov 2002 13:53:40 -0800 (PST) From: Archie Cobbs Message-Id: <200211212153.gALLreeX067352@arch20m.dellroad.org> Subject: Re: Sockets and changing IP addresses In-Reply-To: To: Don Bowman Date: Thu, 21 Nov 2002 13:53:40 -0800 (PST) Cc: "'Wes Peters'" , Archie Cobbs , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Don Bowman wrote: > > > I'm curious what -net's opinion is on PR kern/38544: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 > > > > > > In summary: if you have a connected socket whose local IP address > > > is X, and then change the interface IP address from X to Y, then > > > packets written out by the socket will continue to be transmitted > > > with source IP address X. > > > > > > Do people agree that this is a bug and should be fixed? > > > > Yes. The other end can't possibly reply to address X, so the > > connection is broken at this point. > > I think the current behaviour is correct. Since the IP->MAC lookup > will remain cached, the communication will continue to work to the old > IP. Changing the IP on the connected socket will make the connection > drop. The best case is the the way it works. What you're saying doesn't make sense to me. First of all, this has nothing to do with ARP tables (although you are right that the router's ARP entry for the old IP address will remain valid). Secondly, the communiation will NOT work because the host will drop packets sent to it with the (now) wrong IP address. The current behavior is bad because the application does not ever receive any notification that the socket it's using is no longer valid. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 14: 3:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD6A637B401 for ; Thu, 21 Nov 2002 14:03:41 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F80143E3B for ; Thu, 21 Nov 2002 14:03:41 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 17:03:40 -0500 Message-ID: From: Don Bowman To: 'Archie Cobbs' , Don Bowman Cc: 'Wes Peters' , freebsd-net@freebsd.org Subject: RE: Sockets and changing IP addresses Date: Thu, 21 Nov 2002 17:03:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Archie Cobbs [mailto:archie@dellroad.org] > Sent: November 21, 2002 16:54 > To: Don Bowman > Cc: 'Wes Peters'; Archie Cobbs; freebsd-net@freebsd.org > Subject: Re: Sockets and changing IP addresses > > > Don Bowman wrote: > > > > I'm curious what -net's opinion is on PR kern/38544: > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 > > > > > > > > In summary: if you have a connected socket whose local > IP address > > > > is X, and then change the interface IP address from X to Y, then > > > > packets written out by the socket will continue to be > transmitted > > > > with source IP address X. > > > > > > > > Do people agree that this is a bug and should be fixed? > > > > > > Yes. The other end can't possibly reply to address X, so the > > > connection is broken at this point. > > > > I think the current behaviour is correct. Since the IP->MAC lookup > > will remain cached, the communication will continue to work > to the old > > IP. Changing the IP on the connected socket will make the connection > > drop. The best case is the the way it works. > > What you're saying doesn't make sense to me. First of all, this has > nothing to do with ARP tables (although you are right that > the router's > ARP entry for the old IP address will remain valid). Secondly, the > communiation will NOT work because the host will drop packets sent > to it with the (now) wrong IP address. > > The current behavior is bad because the application does not ever > receive any notification that the socket it's using is no longer > valid. I guess I was thinking of the transparent proxy case (e.g. Squid) where I have a ipfw fwd rule, and the socket is terminated locally. Changing the IP address of the interface shouldn't drop my proxied connection. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 14:14:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FEA537B401; Thu, 21 Nov 2002 14:14:18 -0800 (PST) Received: from hotmail.com (f119.law3.hotmail.com [209.185.241.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id F144743EA3; Thu, 21 Nov 2002 14:14:17 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 14:14:17 -0800 Received: from 199.84.165.3 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 22:14:17 GMT X-Originating-IP: [199.84.165.3] From: "Vincent Goupil" To: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Thu, 21 Nov 2002 22:14:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 22:14:17.0781 (UTC) FILETIME=[55636E50:01C291AB] 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 Nothing better when I use ifconfig down/up. >other questions was: > - what is "Slow network response"? > - does ifconfig down/up helps? >tcpdump buffers output so >usful bits are some time after trouble. >In my case slowdown triggered by >arp scans > > > My network is composed with Windows 2000 servers and pro. > > 192.168.20.2 <- w2k srv > > 192.168.20.3 <- w2k srv > > 192.168.20.7 <- w2k srv > > 192.168.20.8 <- w2k srv > > 192.168.20.9 <- w2k srv > > 192.168.20.10 <- another freebsd box > > 192.168.20.210 <- the firewall > > > > 23:58:43.356569 arp who-has 192.168.20.99 tell 192.168.20.8 > > 23:58:46.471284 arp who-has 192.168.20.127 tell 192.168.20.3 > > 23:58:46.472257 arp who-has 192.168.20.127 tell 192.168.20.8 > > 23:59:04.543497 arp who-has 192.168.20.2 tell 192.168.20.3 > > 23:59:10.352106 arp who-has 192.168.20.7 tell 192.168.20.200 > > 23:59:15.827551 arp who-has 192.168.20.251 tell 192.168.20.7 > > 23:59:17.082626 arp who-has 192.168.20.201 tell 192.168.20.8 > > 23:59:20.245406 arp who-has 192.168.20.201 tell 192.168.20.112 > > 23:59:22.723713 arp who-has 192.168.20.104 tell 192.168.20.3 > > 23:59:26.517132 arp who-has 192.168.20.6 tell 192.168.20.8 > > 23:59:28.824120 arp who-has 192.168.20.7 tell 192.168.20.99 > > 23:59:29.801078 arp who-has 192.168.20.6 tell 192.168.20.7 > > 23:59:48.762973 arp who-has 192.168.20.165 tell 192.168.20.8 > > 23:59:55.203905 arp who-has 192.168.20.75 tell 192.168.20.3 > > 23:59:55.688710 arp who-has 192.168.20.114 tell 192.168.20.8 > > 23:59:55.861042 arp who-has 192.168.20.77 tell 192.168.20.8 > > 00:00:00.192659 arp who-has 192.168.20.106 tell 192.168.20.201 > > 00:00:04.337994 arp who-has 192.168.20.10 tell 192.168.20.8 > > 00:00:04.538035 arp who-has 192.168.20.10 tell 192.168.20.2 > > 00:00:04.775959 arp who-has 192.168.20.10 tell 192.168.20.3 > > 00:00:05.022385 arp who-has 192.168.20.10 tell 192.168.20.9 > > 00:00:05.066194 arp who-has 192.168.20.10 tell 192.168.20.7 > > 00:00:05.209935 arp who-has 192.168.20.10 tell 192.168.20.6 > > 00:00:20.085908 arp who-has 192.168.20.9 tell 192.168.20.3 > > 00:00:20.116177 arp who-has 192.168.20.9 tell 192.168.20.8 > > 00:00:22.235535 arp who-has 192.168.20.101 tell 192.168.20.8 > > 00:00:22.236614 arp who-has 192.168.20.101 tell 192.168.20.3 > > 00:00:23.118443 arp who-has 192.168.20.54 tell 192.168.20.3 > > 00:00:25.075679 arp who-has 192.168.20.7 tell 192.168.20.201 > > 00:00:29.815522 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:30.587208 arp who-has 192.168.20.157 (2f:69:70:63:68:65) tell > > 192.168.20.201 > > 00:00:31.810270 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:45.473558 arp who-has 192.168.20.177 tell 192.168.20.201 > > > > > > >From: "."@babolo.ru > > >To: Vincent Goupil > > >CC: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG > > >Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter > > >Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >MIME-Version: 1.0 > > >Received: from aaz.links.ru ([193.125.152.37]) by >mc6-f36.law1.hotmail.com > > >with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 19:08:36 -0800 > > >Received: from aaz.links.ru (aaz.links.ru [193.125.152.37])by >aaz.links.ru > > >(8.12.6/8.12.6) with ESMTP id gAK3AfDh006526;Wed, 20 Nov 2002 06:10:41 > > >+0300 (MSK)(envelope-from babolo@aaz.links.ru) > > >Received: (from babolo@localhost)by aaz.links.ru (8.12.6/8.12.6/Submit) >id > > >gAK3AeSv006525;Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> > > >X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; >no-hdr-encoding=1 > > >In-Reply-To: > > >X-Mailer: ELM [version 2.4ME+ PL99b (25)] > > >Return-Path: babolo@aaz.links.ru > > >X-OriginalArrivalTime: 20 Nov 2002 03:08:36.0969 (UTC) > > >FILETIME=[1E422D90:01C29042] > > > > > > > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter > > >v3.4.27. > > > > This system act as a firewall for an enterprise. They need high > > > > availability. I have 5 network card, all 3C905 (3*3c905B-TX and > > >2*905C-TX). > > > > I made this setup in july and it run fine until 3 weeks ago. The > > >first > > > > and second card are for the internet link (primary and backup). The > > >third > > > > is for DMZ and the fourth is for local network. The fifth is unused > > >(marked > > > > as down). Each card as is own IRQ (except the fifth that is shared >with > > >the > > > > first). The high availability is provided by the two internet link, >if > > >one > > > > goes down, the second take the load (change default route, ipf >rules, > > >ipnat > > > > rules and DNS records). This is done by a script running by cron. >We > > >can > > > > also do that manually. We have two /29 network for the first link >and > > >one > > > > /28 network for the second (we use alias on internet interfaces). >There > > >is > > > > only 3 services that run on the firewall: SSH (but only accessible >from > > >3 > > > > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one > > >subnet) > > > > > > > > We begin to have problem 3 weeks ago. The firewall begin to have a >slow > > > > response. I begin to have this arp message error (many times): > > > > arplookup 255.255.255.0 failed: host is not on local network > > > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > > > We reboot the server and the network fast as earlier. I finally >find > > > > something: when we use alias, we need to have at least one regular > > >netmask > > > > (instead of 255.255.255.255) for each network/subnetwork. My error >was > > >on > > > > the first link, my second sub-network was not configured properly. >I > > > > changed it and it stop to have these errors about arp but the >problem > > >wasn't > > > > resolved. The network continue to be slow until we reboot the >server. > > >This > > > > happen during the day. Now, it happen everytime. > > > > > > > > What I've done: > > > > - I changed the netmask (as said earlier) > > > > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > > > > - I look for IRQ conflict > > > > - I configure all interface with media and mediaopt. They not using > > > > autodetect anymore. > > > > - I chkrootkit and nothing found > > > > > > > > What I suspect: > > > > - I read in a forum that the driver (xl) of 3C905 is not the best >for > > > > FreeBSD. I don't know if this apply to 4.6.2. > > > > - Ethernet cables (I need to change it) > > > > - We run SSL (with a lot of users) in one of our web servers in the >dmz. > > >As > > > > I know, SSL run on top of TCP, it should not be a problem. > > > > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not > > >promisc" > > > > and "xl1 is not promisc". I have 5 interfaces, what about the >others ? > > > > > > > > Can someone have an idea ? > > >What you mean when say "Slow network response"? > > >If that mean that packets trawel long > > >from some host to host under question > > >as reported by tcpdump, does ifconfig xlN down > > >and then ifconfig xlN up repare situation > > >for some time? > > >What tcpdump -npi xlN ether broadcast and not ip > > >say when slowdown hapens? > > > > > >-- > > >@BABOLO http://links.ru/ > > > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > >-- >@BABOLO http://links.ru/ _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 14:15:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55DC137B440 for ; Thu, 21 Nov 2002 14:15:09 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0961A43EB1 for ; Thu, 21 Nov 2002 14:15:08 -0800 (PST) (envelope-from archie@dellroad.org) 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 OAA84783; Thu, 21 Nov 2002 14:04:25 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gALM4QOS067572; Thu, 21 Nov 2002 14:04:26 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gALM4QDX067571; Thu, 21 Nov 2002 14:04:26 -0800 (PST) From: Archie Cobbs Message-Id: <200211212204.gALM4QDX067571@arch20m.dellroad.org> Subject: Re: Sockets and changing IP addresses In-Reply-To: <0DC02941-FD99-11D6-81FD-00306544D642@mac.com> To: "Justin C. Walker" Date: Thu, 21 Nov 2002 14:04:26 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (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 Justin C. Walker wrote: > >> Do people agree that my suggestion of returning ENETDOWN is reasonable? > > > > Wow. There are other possibilities, EADDRNOTAVAIL or ECONNABORTED. > > It doesn't matter so long as it the errno is unique to this situation > > across all syscalls that might encounter it; ENETDOWN seems to meet > > this criteria. > > A thought: An attempt to reconnect will succeed, given the scenario > above, and ENETDOWN implies that the network is unavailable, so I don't > think this is a good response. ECONNABORTED might be better (and > EADDRNOTAVAIL isn't really germane). Good point... ECONNABORTED is probably better. The particular error code can be determined later however... more interesting is the question, how should this be efficiently implemented? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 17: 5:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2C2C37B408 for ; Thu, 21 Nov 2002 17:05:38 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CE1943EA9 for ; Thu, 21 Nov 2002 17:05:37 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 22 Nov 2002 01:05:36 +0000 (GMT) To: Julian Elischer Cc: Scot Loach , "'freebsd-net@freebsd.org'" Subject: Re: Using ipfw to forward udp In-Reply-To: Your message of "Thu, 21 Nov 2002 11:10:00 PST." Date: Fri, 22 Nov 2002 01:05:32 +0000 From: Ian Dowse Message-ID: <200211220105.aa75973@salmon.maths.tcd.ie> 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 message , Jul ian Elischer writes: >the local fwd command is only implemented for TCP Here is a patch against -stable that I did a while ago, but I never got around to doing a -current version - the code there is quite different. Ian Index: udp_usrreq.c =================================================================== RCS file: /home/iedowse/CVS/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.64.2.16 diff -u -r1.64.2.16 udp_usrreq.c --- udp_usrreq.c 7 Aug 2002 16:14:47 -0000 1.64.2.16 +++ udp_usrreq.c 22 Nov 2002 01:02:14 -0000 @@ -34,6 +34,7 @@ * $FreeBSD: src/sys/netinet/udp_usrreq.c,v 1.64.2.16 2002/08/07 16:14:47 luigi Exp $ */ +#include "opt_ipfw.h" #include "opt_ipsec.h" #include "opt_inet6.h" @@ -339,6 +340,22 @@ /* * Locate pcb for datagram. */ +#ifdef IPFIREWALL_FORWARD + if (ip_fw_fwd_addr != NULL) { + /* Diverted. Use the divert addr/port in the lookup. */ + if (!ip_fw_fwd_addr->sin_port) { + inp = in_pcblookup_hash(&udbinfo, ip->ip_src, + uh->uh_sport, ip_fw_fwd_addr->sin_addr, + uh->uh_dport, 1, m->m_pkthdr.rcvif); + } else { + inp = in_pcblookup_hash(&udbinfo, ip->ip_src, + uh->uh_sport, ip_fw_fwd_addr->sin_addr, + ntohs(ip_fw_fwd_addr->sin_port), 1, + m->m_pkthdr.rcvif); + } + ip_fw_fwd_addr = NULL; + } else +#endif /* IPFIREWALL_FORWARD */ inp = in_pcblookup_hash(&udbinfo, ip->ip_src, uh->uh_sport, ip->ip_dst, uh->uh_dport, 1, m->m_pkthdr.rcvif); if (inp == NULL) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 17:40:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93BB137B401; Thu, 21 Nov 2002 17:40:28 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C2A43E9C; Thu, 21 Nov 2002 17:40:27 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 20:40:26 -0500 Message-ID: From: Don Bowman To: "'freebsd-stable@freebsd.org'" , "'freebsd-net@freebsd.org'" Cc: "'mp@FreeBSD.org'" , "'jdp@polstra.com'" , "'m.barthelow@F5.com'" Subject: bge bug w/ out of bounds return receiver, staying in rxeof all th e time, patch Date: Thu, 21 Nov 2002 20:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org (apologies if you got this more than once, but after 6 hours it hadn't shown up on the mailing list) There is a bug in the STABLE (and current) if_bge which causes the driver to loop forever in interrupt context (in bge_rxeof()). This is caused by the return ring length being 1024 in the driver, and erroneously decided to be 2048 in the chip, which causes it to return an index off the end off the ring. You will know you are running into this if your kernel locks up, ^T still works, and the debugger shows you in bge_rxeof() or a routine called from it. This situation can occur regardless of traffic. It seems to either work or not work from the get-go, so if you are going to run into it, it will be boolean from the machine startup. The patch attached solves this problem by changing the 16-bit writes into the chip's memory window to 32-bit writes. The patch also enables the PCI-VPD (See PCI 2.2) output (to help diagnose which version of the chip you have, whose board, how fast the PCI clock is etc). I would recommend a committer look this over and commit it. If you wish, I can make the patch *just* be the change (changing the 16-bit to 32-bit writes, without the VPD stuff), but the other changes seemed generally useful. Index: if_bge.c =================================================================== RCS file: /cvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.3.2.18 diff -U3 -r1.3.2.18 if_bge.c --- if_bge.c 2 Nov 2002 18:22:23 -0000 1.3.2.18 +++ if_bge.c 21 Nov 2002 20:13:23 -0000 @@ -114,6 +114,7 @@ #include #define BGE_CSUM_FEATURES (CSUM_IP | CSUM_TCP | CSUM_UDP) +#define BGE_VPD /* "controller miibus0" required. See GENERIC if you get errors here. */ #include "miibus_if.h" @@ -178,6 +179,7 @@ static u_int8_t bge_eeprom_getbyte __P((struct bge_softc *, int, u_int8_t *)); static int bge_read_eeprom __P((struct bge_softc *, caddr_t, int, int)); +static void dump_manufacturing_information __P((struct bge_softc *)); static u_int32_t bge_crc __P((caddr_t)); static void bge_setmulti __P((struct bge_softc *)); @@ -200,11 +202,12 @@ static int bge_chipinit __P((struct bge_softc *)); static int bge_blockinit __P((struct bge_softc *)); -#ifdef notdef +#ifdef BGE_VPD +static void bge_vpd_crack __P((struct bge_softc *sc)); static u_int8_t bge_vpd_readbyte __P((struct bge_softc *, int)); static void bge_vpd_read_res __P((struct bge_softc *, struct vpd_res *, int)); -static void bge_vpd_read __P((struct bge_softc *)); +static void bge_vpd_read __P((struct bge_softc *, const char *)); #endif static u_int32_t bge_readmem_ind @@ -311,7 +314,7 @@ return; } -#ifdef notdef +#ifdef BGE_VPD static u_int8_t bge_vpd_readbyte(sc, addr) struct bge_softc *sc; @@ -355,9 +358,54 @@ return; } +/* + * Take the read-only (VPD-R) info and crack it into the other fields +*/ +static void +bge_vpd_crack(sc) + struct bge_softc *sc; +{ + int pos = 0; + int len = strlen(sc->bge_vpd_readonly); + sc->bge_vpd_pn = "unknown"; + sc->bge_vpd_ec = "unknown"; + sc->bge_vpd_mn = "unknown"; + sc->bge_vpd_sn = "unknown"; + sc->bge_vpd_rv = "unknown"; + while (pos < len) { + if (!strncmp(sc->bge_vpd_readonly+pos, VPD_PN, 2)) { + sc->bge_vpd_pn = (sc->bge_vpd_readonly+pos+3); + } else if (!strncmp(sc->bge_vpd_readonly+pos, VPD_EC, 2)) { + sc->bge_vpd_ec = (sc->bge_vpd_readonly+pos+3); + } else if (!strncmp(sc->bge_vpd_readonly+pos, VPD_MN, 2)) { + sc->bge_vpd_mn = (sc->bge_vpd_readonly+pos+3); + } else if (!strncmp(sc->bge_vpd_readonly+pos, VPD_SN, 2)) { + sc->bge_vpd_sn = (sc->bge_vpd_readonly+pos+3); + } else if (!strncmp(sc->bge_vpd_readonly+pos, VPD_RV, 2)) { + sc->bge_vpd_rv = (sc->bge_vpd_readonly+pos+3); + } + sc->bge_vpd_readonly[pos] = '\0'; + pos += 2; + pos += sc->bge_vpd_readonly[pos]; + pos++; + } + pos = 0; + len = strlen(sc->bge_vpd_readwrite); + while (pos < len) { + if (!strncmp(sc->bge_vpd_readwrite+pos, VPD_YA, 2)) { + sc->bge_vpd_asset_tag = (sc->bge_vpd_readwrite+pos+3); + } + sc->bge_vpd_readwrite[pos] = '\0'; + pos += 2; + pos += sc->bge_vpd_readwrite[pos]; + pos++; + } +} + static void -bge_vpd_read(sc) +bge_vpd_read(sc, defname) struct bge_softc *sc; + const char *defname; { int pos = 0, i; struct vpd_res res; @@ -366,14 +414,20 @@ free(sc->bge_vpd_prodname, M_DEVBUF); if (sc->bge_vpd_readonly != NULL) free(sc->bge_vpd_readonly, M_DEVBUF); + if (sc->bge_vpd_readwrite != NULL) + free(sc->bge_vpd_readwrite, M_DEVBUF); sc->bge_vpd_prodname = NULL; sc->bge_vpd_readonly = NULL; + sc->bge_vpd_readwrite = NULL; bge_vpd_read_res(sc, &res, pos); if (res.vr_id != VPD_RES_ID) { - printf("bge%d: bad VPD resource id: expected %x got %x\n", + printf("bge%d: bad VPD-ID resource id: expected %x got %x\n", sc->bge_unit, VPD_RES_ID, res.vr_id); + sc->bge_vpd_prodname = malloc(strlen(defname) + 1, + M_DEVBUF, M_NOWAIT); + strcpy(sc->bge_vpd_prodname, defname); return; } @@ -387,7 +441,7 @@ bge_vpd_read_res(sc, &res, pos); if (res.vr_id != VPD_RES_READ) { - printf("bge%d: bad VPD resource id: expected %x got %x\n", + printf("bge%d: bad VPD-R resource id: expected %x got %x\n", sc->bge_unit, VPD_RES_READ, res.vr_id); return; } @@ -396,6 +450,22 @@ sc->bge_vpd_readonly = malloc(res.vr_len, M_DEVBUF, M_NOWAIT); for (i = 0; i < res.vr_len + 1; i++) sc->bge_vpd_readonly[i] = bge_vpd_readbyte(sc, i + pos); + pos += i-1; + + bge_vpd_read_res(sc, &res, pos); + + if (res.vr_id != VPD_RES_WRITE) { + printf("bge%d: bad VPD-W resource id: expected %x got %x\n", + sc->bge_unit, VPD_RES_WRITE, res.vr_id); + return; + } + + pos += sizeof(res); + sc->bge_vpd_readwrite = malloc(res.vr_len, M_DEVBUF, M_NOWAIT); + for (i = 0; i < res.vr_len + 1; i++) + sc->bge_vpd_readwrite[i] = bge_vpd_readbyte(sc, i + pos); + + bge_vpd_crack(sc); return; } @@ -451,6 +521,32 @@ } /* + * Dump the information from the manufacturing info area of the eeprom + * which includes the rev, the types of phy, etc. +*/ +static void +dump_manufacturing_information(struct bge_softc *sc) +{ + char ee[140]; + if (!bge_read_eeprom(sc, ee, 0x74, 140)) { + printf("bge%d: %s(%c%c), mfg format: REV%c, mfg on: %u asicrev: %08x\n", + sc->bge_unit, + &ee[0x10], + ee[0x20],ee[0x21], + ee[0], + (unsigned int)htonl(*(unsigned int *)(&ee[0x24])), + sc->bge_asicrev); + printf("bge%d: phy-id: 0x%x BCM devid: 0x%04x, PCI sub-devid 0x%04x PCI PCI sub-vid 0x%04x\n", + sc->bge_unit, + (unsigned int )htonl(*(unsigned int *)(&ee[4])), + htons(*(unsigned short *)(&ee[0x2e])), + htons(*(unsigned short *)(&ee[0x30])), + htons(*(unsigned short *)(&ee[0x32]))); + printf("bge%d: clock-speed: %dMHz\n", sc->bge_unit,htons(*(unsigned short *)(&ee[0x34]))); + } +} + +/* * Read a sequence of bytes from the EEPROM. */ static int @@ -901,7 +997,8 @@ sc->bge_cdata.bge_rx_std_chain[i] = NULL; } bzero((char *)&sc->bge_rdata->bge_rx_std_ring[i], - sizeof(struct bge_rx_bd)); + sizeof(struct bge_rx_bd)); + } return; @@ -913,7 +1010,7 @@ { int i; struct bge_rcb *rcb; - struct bge_rcb_opaque *rcbo; + bge_max_len_flags len_flags; for (i = 0; i < BGE_JUMBO_RX_RING_CNT; i++) { if (bge_newbuf_jumbo(sc, i, NULL) == ENOBUFS) @@ -923,9 +1020,9 @@ sc->bge_jumbo = i - 1; rcb = &sc->bge_rdata->bge_info.bge_jumbo_rx_rcb; - rcbo = (struct bge_rcb_opaque *)rcb; - rcb->bge_flags = 0; - CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, rcbo->bge_reg2); + len_flags.bge_len_flags = rcb->bge_len_flags.bge_len_flags; + len_flags.s.bge_flags = 0; + CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, len_flags.bge_len_flags); CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); @@ -1047,6 +1144,25 @@ struct bge_softc *sc; { int i; + static int clock_speeds_l[] = { + 28, + 34, + 41, + 56, + 67, + 86, + 98 + }; + static int clock_speeds_h[] = { + 39, + 45, + 52, + 61, + 72, + 90, + 103, + 198 + }; /* Set endianness before we access any non-PCI registers. */ #if BYTE_ORDER == BIG_ENDIAN @@ -1083,16 +1199,29 @@ BGE_MEMWIN_WRITE(sc, i, 0); /* Set up the PCI DMA control register. */ - if (pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & - BGE_PCISTATE_PCI_BUSMODE) { + i = pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4); + if (i & BGE_PCISTATE_PCI_BUSMODE) { /* Conventional PCI bus */ pci_write_config(sc->bge_dev, BGE_PCI_DMA_RW_CTL, BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD|0x3F000F, 4); + printf("bge%d: Conventional PCI Mode %dMHz, %d bits\n", + sc->bge_unit, + (i&BGE_PCISTATE_PCI_BUSSPEED) ? 33 : 66, + (i&BGE_PCISTATE_32BIT_BUS) ? 32 : 64); } else { /* PCI-X bus */ pci_write_config(sc->bge_dev, BGE_PCI_DMA_RW_CTL, BGE_PCI_READ_CMD|BGE_PCI_WRITE_CMD|0x1B000F, 4); - } + printf("bge%d: PCI-X Mode %dMHz, %d bits\n", + sc->bge_unit, + (i&BGE_PCISTATE_PCI_BUSSPEED) ? 66 : 133, + (i&BGE_PCISTATE_32BIT_BUS) ? 32 : 64); + } + i = pci_read_config(sc->bge_dev, BGE_PCI_CLKCTL, 4); + printf("bge%d: PCI Clock Measured: %d - %d MHz\n", + sc->bge_unit, + clock_speeds_l[i & BGE_PCICLOCKCTL_DETECTED_SPEED], + clock_speeds_h[i & BGE_PCICLOCKCTL_DETECTED_SPEED]); /* * Set up general mode register. @@ -1133,6 +1262,7 @@ struct bge_rcb *rcb; struct bge_rcb_opaque *rcbo; int i; + bge_max_len_flags len_flags; /* * Initialize the memory window pointer register so that @@ -1202,12 +1332,13 @@ rcb = &sc->bge_rdata->bge_info.bge_std_rx_rcb; BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_std_ring); - rcb->bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; if (sc->bge_extram) rcb->bge_nicaddr = BGE_EXT_STD_RX_RINGS; else rcb->bge_nicaddr = BGE_STD_RX_RINGS; - rcb->bge_flags = 0; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_STD_RCB_HADDR_HI, rcbo->bge_reg0); CSR_WRITE_4(sc, BGE_RX_STD_RCB_HADDR_LO, rcbo->bge_reg1); @@ -1224,12 +1355,13 @@ rcb = &sc->bge_rdata->bge_info.bge_jumbo_rx_rcb; BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_jumbo_ring); - rcb->bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; if (sc->bge_extram) rcb->bge_nicaddr = BGE_EXT_JUMBO_RX_RINGS; else rcb->bge_nicaddr = BGE_JUMBO_RX_RINGS; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_HADDR_HI, rcbo->bge_reg0); @@ -1239,7 +1371,9 @@ /* Set up dummy disabled mini ring RCB */ rcb = &sc->bge_rdata->bge_info.bge_mini_rx_rcb; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; + len_flags.s.bge_max_len = 0; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_MINI_RCB_MAXLEN_FLAGS, rcbo->bge_reg2); @@ -1259,8 +1393,9 @@ rcb = (struct bge_rcb *)(sc->bge_vhandle + BGE_MEMWIN_START + BGE_SEND_RING_RCB); for (i = 0; i < BGE_TX_RINGS_EXTSSRAM_MAX; i++) { - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; - rcb->bge_max_len = 0; + len_flags.s.bge_max_len = 0; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcb->bge_nicaddr = 0; rcb++; } @@ -1272,17 +1407,20 @@ BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_tx_ring); rcb->bge_nicaddr = BGE_NIC_TXRING_ADDR(0, BGE_TX_RING_CNT); - rcb->bge_max_len = BGE_TX_RING_CNT; - rcb->bge_flags = 0; + len_flags.s.bge_max_len = BGE_TX_RING_CNT; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; /* Disable all unused RX return rings */ rcb = (struct bge_rcb *)(sc->bge_vhandle + BGE_MEMWIN_START + BGE_RX_RETURN_RING_RCB); - for (i = 0; i < BGE_RX_RINGS_MAX; i++) { + rcb++; + for (i = 1; i < BGE_RX_RINGS_MAX; i++) { rcb->bge_hostaddr.bge_addr_hi = 0; rcb->bge_hostaddr.bge_addr_lo = 0; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; - rcb->bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcb->bge_nicaddr = 0; CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(u_int64_t))), 0); @@ -1306,8 +1444,9 @@ BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_return_ring); rcb->bge_nicaddr = 0x00000000; - rcb->bge_max_len = BGE_RETURN_RING_CNT; - rcb->bge_flags = 0; + len_flags.s.bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; /* Set random backoff seed for TX */ CSR_WRITE_4(sc, BGE_TX_RANDOM_BACKOFF, @@ -1363,13 +1502,11 @@ CSR_WRITE_4(sc, BGE_HCC_STATS_TICKS, sc->bge_stat_ticks); /* Set up address of statistics block */ - CSR_WRITE_4(sc, BGE_HCC_STATS_BASEADDR, BGE_STATS_BLOCK); CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_HI, 0); CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_LO, vtophys(&sc->bge_rdata->bge_info.bge_stats)); /* Set up address of status block */ - CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_BASEADDR, BGE_STATUS_BLOCK); CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_ADDR_HI, 0); CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_ADDR_LO, vtophys(&sc->bge_rdata->bge_status_block)); @@ -1498,11 +1635,12 @@ while(t->bge_name != NULL) { if ((pci_get_vendor(dev) == t->bge_vid) && (pci_get_device(dev) == t->bge_did)) { -#ifdef notdef - bge_vpd_read(sc); +#ifdef BGE_VPD + bge_vpd_read(sc, t->bge_name); device_set_desc(dev, sc->bge_vpd_prodname); -#endif +#else device_set_desc(dev, t->bge_name); +#endif return(0); } t++; @@ -1632,6 +1770,18 @@ */ printf("bge%d: Ethernet address: %6D\n", unit, sc->arpcom.ac_enaddr, ":"); + if (sc->bge_vpd_readonly) + printf("bge%d: PN: <%s> SN: <%s> EC: <%s> MN: <%s> RV: <%s>\n", + unit, + sc->bge_vpd_pn, + sc->bge_vpd_sn, + sc->bge_vpd_ec, + sc->bge_vpd_mn, + sc->bge_vpd_rv); + if (sc->bge_vpd_asset_tag) + printf("bge%d: asset-tag: %s\n", unit, sc->bge_vpd_asset_tag); + + dump_manufacturing_information(sc); /* Allocate the general information block and ring buffers. */ sc->bge_rdata = contigmalloc(sizeof(struct bge_ring_data), M_DEVBUF, @@ -1656,10 +1806,34 @@ } /* Set default tuneable values. */ + /* How often should we update the statistics in host memory? */ sc->bge_stat_ticks = BGE_TICKS_PER_SEC; - sc->bge_rx_coal_ticks = 150; - sc->bge_tx_coal_ticks = 150; - sc->bge_rx_max_coal_bds = 64; + /* The coalescing works as follows: for each of Rx|Tx, there + * are two tunables: ticks, and packets. The first one to trip + * will cause an interrupt. For exampple, if the ticks is set to + * 1us, an interrupt will be generated no more than 1us after + * a packet has come in. If the bds is set to 10, then the + * interrupt would be after 10 packets had been received. + * If ticks=1 and bds=10, then the interrupt will come in + * min(1us, 10packets time), likely 1us. + * Tuning these to larger values reduces interrupts at the + * expense of latency to interactive applications. If you + * are serving files, make these large. If you are running + * telnet sessions, make them small. + * + * The settings below, 500us means a max interrupt rate + * of 2000/s due to the ticks elapsing, and 120 means + * a peak interrupt rate of ~2000/s due to avg packets (512) arriving + * (for min sized packets this would be 870, for max + * sized packets it would be 41: 1Gps / ((8*size)+96)) + */ + /* RX Interrupt no more than every 500 us */ + sc->bge_rx_coal_ticks = 512; + /* TX Interrupt no more than every 500 us */ + sc->bge_tx_coal_ticks = 512; + /* RX Interrupt no more than every 120 packets */ + sc->bge_rx_max_coal_bds = 128; + /* TX Interrupt no more than every 120 packets */ sc->bge_tx_max_coal_bds = 128; /* Set up ifnet structure */ @@ -1806,6 +1980,9 @@ if (sc->bge_vpd_readonly != NULL) free(sc->bge_vpd_readonly, M_DEVBUF); + if (sc->bge_vpd_readwrite != NULL) + free(sc->bge_vpd_readwrite, M_DEVBUF); + if (sc->bge_intrhand != NULL) bus_teardown_intr(dev, sc->bge_irq, sc->bge_intrhand); @@ -2082,63 +2259,74 @@ #ifdef notdef /* Avoid this for now -- checking this register is expensive. */ /* Make sure this is really our interrupt. */ - if (!(CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE)) + if ((CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE)) { return; + } #endif - /* Ack interrupt and stop others from occuring. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); + while (sc->bge_rdata->bge_status_block.bge_status & + BGE_STATFLAG_UPDATED) { - /* - * Process link state changes. - * Grrr. The link status word in the status block does - * not work correctly on the BCM5700 rev AX and BX chips, - * according to all avaibable information. Hence, we have - * to enable MII interrupts in order to properly obtain - * async link changes. Unfortunately, this also means that - * we have to read the MAC status register to detect link - * changes, thereby adding an additional register access to - * the interrupt handler. - */ - - if (sc->bge_asicrev == BGE_ASICREV_BCM5700) { - u_int32_t status; - - status = CSR_READ_4(sc, BGE_MAC_STS); - if (status & BGE_MACSTAT_MI_INTERRUPT) { - sc->bge_link = 0; - untimeout(bge_tick, sc, sc->bge_stat_ch); - bge_tick(sc); - /* Clear the interrupt */ - CSR_WRITE_4(sc, BGE_MAC_EVT_ENB, - BGE_EVTENB_MI_INTERRUPT); - bge_miibus_readreg(sc->bge_dev, 1, BRGPHY_MII_ISR); - bge_miibus_writereg(sc->bge_dev, 1, BRGPHY_MII_IMR, - BRGPHY_INTRS); - } - } else { - if (sc->bge_rdata->bge_status_block.bge_status & - BGE_STATFLAG_LINKSTATE_CHANGED) { - sc->bge_link = 0; - untimeout(bge_tick, sc, sc->bge_stat_ch); - bge_tick(sc); - /* Clear the interrupt */ - CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| - BGE_MACSTAT_CFG_CHANGED); - } - } + /* Ack interrupt and stop others from occuring. */ + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); - if (ifp->if_flags & IFF_RUNNING) { - /* Check RX return ring producer/consumer */ - bge_rxeof(sc); + /* Now clear the 'updated' bit */ + sc->bge_rdata->bge_status_block.bge_status &= ~BGE_STATFLAG_UPDATED; - /* Check TX ring producer/consumer */ - bge_txeof(sc); + /* + * Process link state changes. + * Grrr. The link status word in the status block does + * not work correctly on the BCM5700 rev AX and BX chips, + * according to all avaibable information. Hence, we have + * to enable MII interrupts in order to properly obtain + * async link changes. Unfortunately, this also means that + * we have to read the MAC status register to detect link + * changes, thereby adding an additional register access to + * the interrupt handler. + */ + + if (sc->bge_asicrev == BGE_ASICREV_BCM5700) { + u_int32_t status; + + status = CSR_READ_4(sc, BGE_MAC_STS); + if (status & BGE_MACSTAT_MI_INTERRUPT) { + sc->bge_link = 0; + untimeout(bge_tick, sc, sc->bge_stat_ch); + bge_tick(sc); + /* Clear the interrupt */ + CSR_WRITE_4(sc, BGE_MAC_EVT_ENB, + BGE_EVTENB_MI_INTERRUPT); + bge_miibus_readreg(sc->bge_dev, 1, BRGPHY_MII_ISR); + bge_miibus_writereg(sc->bge_dev, 1, BRGPHY_MII_IMR, + BRGPHY_INTRS); + } + } else { + if (sc->bge_rdata->bge_status_block.bge_status & + BGE_STATFLAG_LINKSTATE_CHANGED) { + sc->bge_link = 0; + untimeout(bge_tick, sc, sc->bge_stat_ch); + bge_tick(sc); + /* Clear the interrupt */ + CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| + BGE_MACSTAT_CFG_CHANGED); + } + } + + + if (ifp->if_flags & IFF_RUNNING) { + /* Check RX return ring producer/consumer */ + bge_rxeof(sc); + + /* Check TX ring producer/consumer */ + bge_txeof(sc); + } + + bge_handle_events(sc); + + /* Re-enable interrupts. */ + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + /* Force posted writes to complete */ + CSR_READ_4(sc, BGE_MBX_IRQ0_LO); } - - bge_handle_events(sc); - - /* Re-enable interrupts. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); if (ifp->if_flags & IFF_RUNNING && ifp->if_snd.ifq_head != NULL) bge_start(ifp); Index: if_bgereg.h =================================================================== RCS file: /cvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.1.2.7 diff -U3 -r1.1.2.7 if_bgereg.h --- if_bgereg.h 2 Nov 2002 18:17:55 -0000 1.1.2.7 +++ if_bgereg.h 21 Nov 2002 20:20:37 -0000 @@ -278,7 +278,26 @@ * unless the CLOCKCTL_RW bit of the PCI Misc. Host Control * register is set. */ -#define BGE_PCICLOCKCTL_DETECTED_SPEED 0x0000000F +#define BGE_PCICLOCKCTL_DETECTED_SPEED 0x00000007 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_28_1 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_34_3 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_40_6 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_46_8 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_56_2 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_67_1 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_85_9 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_L_98_4 + +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_39_1 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_45_3 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_51_6 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_60_9 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_71_9 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_90_5 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_103 +#define BGE_PCICLOCKCTL_DETECTED_SPEED_H_198 + + #define BGE_PCICLOCKCTL_M66EN 0x00000080 #define BGE_PCICLOCKCTL_LOWPWR_CLKMODE 0x00000200 #define BGE_PCICLOCKCTL_RXCPU_CLK_DIS 0x00000400 @@ -1083,6 +1102,8 @@ #define BGE_HCCMODE_COAL_NOW 0x00000008 #define BGE_HCCMODE_MSI_BITS 0x0x000070 #define BGE_HCCMODE_STATBLK_SIZE 0x00000180 +#define BGE_HCCMODE_CLEAR_TX (1<<10) +#define BGE_HCCMODE_CLEAR_RX (1<<9) #define BGE_STATBLKSZ_FULL 0x00000000 #define BGE_STATBLKSZ_64BYTE 0x00000080 @@ -1678,11 +1699,23 @@ } bge_hostaddr; #define BGE_HOSTADDR(x) x.bge_addr_lo +typedef union { + struct { +#if BYTE_ORDER == BIG_ENDIAN + u_int16_t bge_max_len; + u_int16_t bge_flags; +#else + u_int16_t bge_flags; + u_int16_t bge_max_len; +#endif + } s; + u_int32_t bge_len_flags; +} bge_max_len_flags; + /* Ring control block structure */ struct bge_rcb { bge_hostaddr bge_hostaddr; - u_int16_t bge_flags; - u_int16_t bge_max_len; + bge_max_len_flags bge_len_flags; u_int32_t bge_nicaddr; }; @@ -2026,10 +2059,43 @@ u_int8_t vk_len; }; +/* + * VPD (PCI 2.2) is a standard to allow describing a product. + * + * Here is an example VPD (from a 3COM 3C996) + * 82 18 00 33 43 6f 6d 20 - 47 69 67 61 62 69 74 20--...3Com Gigabit + * 53 65 72 76 65 72 20 4e - 49 43 00 90 62 00 50 4e--Server NIC..b.PN + * 08 33 43 39 39 36 42 2d - 54 45 43 09 30 31 2d 30--.3C996B-TEC.01-0 + * 32 37 38 72 36 53 4e 0a - 48 52 54 52 45 46 30 38--278r6SN.HRTREF08 + * 37 43 4d 4e 04 31 30 42 - 37 52 56 34 42 00 00 00--7CMN.10B7RV4B... + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 91 7c 00 59 41 0b 58 59 - 5a 30 31 32 33 34 35 36--.|.YA.XYZ0123456 + * 37 52 57 6b 00 00 00 00 - 00 00 00 00 00 00 00 00--7RWk............ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00--................ + * 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 78--...............x + */ #define VPD_RES_ID 0x82 /* ID string */ #define VPD_RES_READ 0x90 /* start of read only area */ -#define VPD_RES_WRITE 0x81 /* start of read/write area */ +#define VPD_RES_WRITE 0x91 /* start of read/write area */ #define VPD_RES_END 0x78 /* end tag */ +/* + * Within the VPD-R, we have subtags as , the tags + * are two-char, the len is 1-char +*/ +#define VPD_PN "PN" /* Adapter Part Number */ +#define VPD_EC "EC" /* Adapter Engineering Level */ +#define VPD_MN "MN" /* Manufacture ID */ +#define VPD_SN "SN" /* Serial Number */ +#define VPD_CP "CP" /* Extended Capability */ +#define VPD_RV "RV" /* Checksum and Reserved */ +#define VPD_YA "YA" /* Asset Tag Identifier */ +#define VPD_RW "RW" /* Remaining Read / Write Area */ /* @@ -2059,9 +2125,9 @@ * allocated for the standard, mini and jumbo receive rings. */ -#define BGE_SSLOTS 256 -#define BGE_MSLOTS 256 -#define BGE_JSLOTS 384 +#define BGE_SSLOTS 512 +#define BGE_MSLOTS 0 /* Not used in this driver, only avail on bcm5700*/ +#define BGE_JSLOTS 32 #define BGE_JRAWLEN (BGE_JUMBO_FRAMELEN + ETHER_ALIGN + sizeof(u_int64_t)) #define BGE_JLEN (BGE_JRAWLEN + (sizeof(u_int64_t) - \ @@ -2165,6 +2231,13 @@ struct callout_handle bge_stat_ch; char *bge_vpd_prodname; char *bge_vpd_readonly; + char *bge_vpd_pn; /* pointer within the readonly*/ + char *bge_vpd_sn; /* pointer within the readonly*/ + char *bge_vpd_ec; /* pointer within the readonly*/ + char *bge_vpd_mn; /* pointer within the readonly*/ + char *bge_vpd_rv; /* pointer within the readonly*/ + char *bge_vpd_readwrite; + char *bge_vpd_asset_tag; /* pointer within the rw*/ }; #ifdef __alpha__ --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 17:47:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8CFB37B401; Thu, 21 Nov 2002 17:47:15 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D88943E6E; Thu, 21 Nov 2002 17:47:15 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gAM1lB9i082339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Nov 2002 17:47:12 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <184f01c291c9$147e7100$52557f42@errno.com> From: "Sam Leffler" To: "Don Bowman" , "'freebsd-stable@freebsd.org'" , "'freebsd-net@freebsd.org'" Cc: "'mp@FreeBSD.org'" , , References: Subject: Re: bge bug w/ out of bounds return receiver, staying in rxeof all the time, patch Date: Thu, 21 Nov 2002 17:47:11 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 would recommend a committer look this over and > commit it. If you wish, I can make the patch *just* > be the change (changing the 16-bit to 32-bit writes, > without the VPD stuff), but the other changes seemed > generally useful. Please whittle the patch down to just the bug fix; 5.0 is in code freeze. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 17:57:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D25437B404 for ; Thu, 21 Nov 2002 17:57:15 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 537CE43E97 for ; Thu, 21 Nov 2002 17:57:14 -0800 (PST) (envelope-from archie@dellroad.org) 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 RAA86207; Thu, 21 Nov 2002 17:57:09 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAM1v9OS068554; Thu, 21 Nov 2002 17:57:09 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAM1v2Ls068553; Thu, 21 Nov 2002 17:57:02 -0800 (PST) From: Archie Cobbs Message-Id: <200211220157.gAM1v2Ls068553@arch20m.dellroad.org> Subject: Re: Sockets and changing IP addresses In-Reply-To: <3DDD4D11.15376311@softweyr.com> To: Wes Peters Date: Thu, 21 Nov 2002 17:57:02 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (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 Wes Peters wrote: > > I'm curious what -net's opinion is on PR kern/38544: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38554 > > > > In summary: if you have a connected socket whose local IP address > > is X, and then change the interface IP address from X to Y, then > > packets written out by the socket will continue to be transmitted > > with source IP address X. > > > > Do people agree that this is a bug and should be fixed? > > Yes. The other end can't possibly reply to address X, so the connection > is broken at this point. Now I've got a patch that fixes this problem for review, it's attached to the PR (please review at the above URL if interested). I chose EADDRNOTAVAIL as the error code because: (a) The phrase "Can't assign requested address" seems most appropriate (b) It's consistent with what happens when you try to use an IP address that never existed in the first place, e.g., with IP_SENDSRCADDR. (c) You don't normally get this error from a send/write, which is when you'll get it The implementation simply keeps a pointer in the inet PCB to the 'struct in_ifaddr' associated with the local IP address (if any). When this address is removed from the interface, we set the RTF_REJECT flag on it, and this is detected by the TCP and UDP layers. So the per-packet cost is the testing of one flag bit. Note that 'struct in_ifaddr' structures are reference counted, so they continue to exist even after being removed from the interface. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 18:19: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3815237B401; Thu, 21 Nov 2002 18:18:58 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4135343E9C; Thu, 21 Nov 2002 18:18:57 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 21:18:53 -0500 Message-ID: From: Don Bowman To: 'Sam Leffler' , Don Bowman , "'freebsd-stable@freebsd.org'" , "'freebsd-net@freebsd.org'" Cc: "'mp@FreeBSD.org'" , jdp@polstra.com, m.barthelow@F5.com Subject: RE: bge bug w/ out of bounds return receiver, staying in rxeof al l the time, patch Date: Thu, 21 Nov 2002 21:18:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Sam Leffler [mailto:sam@errno.com] > > I would recommend a committer look this over and > > commit it. If you wish, I can make the patch *just* > > be the change (changing the 16-bit to 32-bit writes, > > without the VPD stuff), but the other changes seemed > > generally useful. > > Please whittle the patch down to just the bug fix; 5.0 is in > code freeze. > > Sam > Sigh, I was afraid someone would say that. Will do. The patch is against RELENG_4, but is fairly trivial. It is below, just the bug fix is there (changing the writing to the receiver control block to be 32-bits all the time). Patch follows: Index: if_bge.c =================================================================== RCS file: /cvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.3.2.18 diff -U3 -r1.3.2.18 if_bge.c --- if_bge.c 2 Nov 2002 18:22:23 -0000 1.3.2.18 +++ if_bge.c 22 Nov 2002 02:01:48 -0000 @@ -913,7 +913,7 @@ { int i; struct bge_rcb *rcb; - struct bge_rcb_opaque *rcbo; + bge_max_len_flags len_flags; for (i = 0; i < BGE_JUMBO_RX_RING_CNT; i++) { if (bge_newbuf_jumbo(sc, i, NULL) == ENOBUFS) @@ -923,9 +923,9 @@ sc->bge_jumbo = i - 1; rcb = &sc->bge_rdata->bge_info.bge_jumbo_rx_rcb; - rcbo = (struct bge_rcb_opaque *)rcb; - rcb->bge_flags = 0; - CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, rcbo->bge_reg2); + len_flags.bge_len_flags = rcb->bge_len_flags.bge_len_flags; + len_flags.s.bge_flags = 0; + CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_MAXLEN_FLAGS, len_flags.bge_len_flags); CSR_WRITE_4(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); @@ -1133,6 +1133,7 @@ struct bge_rcb *rcb; struct bge_rcb_opaque *rcbo; int i; + bge_max_len_flags len_flags; /* * Initialize the memory window pointer register so that @@ -1202,12 +1203,13 @@ rcb = &sc->bge_rdata->bge_info.bge_std_rx_rcb; BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_std_ring); - rcb->bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; if (sc->bge_extram) rcb->bge_nicaddr = BGE_EXT_STD_RX_RINGS; else rcb->bge_nicaddr = BGE_STD_RX_RINGS; - rcb->bge_flags = 0; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_STD_RCB_HADDR_HI, rcbo->bge_reg0); CSR_WRITE_4(sc, BGE_RX_STD_RCB_HADDR_LO, rcbo->bge_reg1); @@ -1224,12 +1226,13 @@ rcb = &sc->bge_rdata->bge_info.bge_jumbo_rx_rcb; BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_jumbo_ring); - rcb->bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_max_len = BGE_MAX_FRAMELEN; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; if (sc->bge_extram) rcb->bge_nicaddr = BGE_EXT_JUMBO_RX_RINGS; else rcb->bge_nicaddr = BGE_JUMBO_RX_RINGS; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_JUMBO_RCB_HADDR_HI, rcbo->bge_reg0); @@ -1239,7 +1242,9 @@ /* Set up dummy disabled mini ring RCB */ rcb = &sc->bge_rdata->bge_info.bge_mini_rx_rcb; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; + len_flags.s.bge_max_len = 0; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcbo = (struct bge_rcb_opaque *)rcb; CSR_WRITE_4(sc, BGE_RX_MINI_RCB_MAXLEN_FLAGS, rcbo->bge_reg2); @@ -1259,8 +1264,9 @@ rcb = (struct bge_rcb *)(sc->bge_vhandle + BGE_MEMWIN_START + BGE_SEND_RING_RCB); for (i = 0; i < BGE_TX_RINGS_EXTSSRAM_MAX; i++) { - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; - rcb->bge_max_len = 0; + len_flags.s.bge_max_len = 0; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcb->bge_nicaddr = 0; rcb++; } @@ -1272,17 +1278,20 @@ BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_tx_ring); rcb->bge_nicaddr = BGE_NIC_TXRING_ADDR(0, BGE_TX_RING_CNT); - rcb->bge_max_len = BGE_TX_RING_CNT; - rcb->bge_flags = 0; + len_flags.s.bge_max_len = BGE_TX_RING_CNT; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; /* Disable all unused RX return rings */ rcb = (struct bge_rcb *)(sc->bge_vhandle + BGE_MEMWIN_START + BGE_RX_RETURN_RING_RCB); - for (i = 0; i < BGE_RX_RINGS_MAX; i++) { + rcb++; + for (i = 1; i < BGE_RX_RINGS_MAX; i++) { rcb->bge_hostaddr.bge_addr_hi = 0; rcb->bge_hostaddr.bge_addr_lo = 0; - rcb->bge_flags = BGE_RCB_FLAG_RING_DISABLED; - rcb->bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_flags = BGE_RCB_FLAG_RING_DISABLED; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; rcb->bge_nicaddr = 0; CSR_WRITE_4(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(u_int64_t))), 0); @@ -1306,8 +1315,9 @@ BGE_HOSTADDR(rcb->bge_hostaddr) = vtophys(&sc->bge_rdata->bge_rx_return_ring); rcb->bge_nicaddr = 0x00000000; - rcb->bge_max_len = BGE_RETURN_RING_CNT; - rcb->bge_flags = 0; + len_flags.s.bge_max_len = BGE_RETURN_RING_CNT; + len_flags.s.bge_flags = 0; + rcb->bge_len_flags.bge_len_flags = len_flags.bge_len_flags; /* Set random backoff seed for TX */ CSR_WRITE_4(sc, BGE_TX_RANDOM_BACKOFF, @@ -1363,13 +1373,11 @@ CSR_WRITE_4(sc, BGE_HCC_STATS_TICKS, sc->bge_stat_ticks); /* Set up address of statistics block */ - CSR_WRITE_4(sc, BGE_HCC_STATS_BASEADDR, BGE_STATS_BLOCK); CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_HI, 0); CSR_WRITE_4(sc, BGE_HCC_STATS_ADDR_LO, vtophys(&sc->bge_rdata->bge_info.bge_stats)); /* Set up address of status block */ - CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_BASEADDR, BGE_STATUS_BLOCK); CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_ADDR_HI, 0); CSR_WRITE_4(sc, BGE_HCC_STATUSBLK_ADDR_LO, vtophys(&sc->bge_rdata->bge_status_block)); @@ -2082,7 +2090,7 @@ #ifdef notdef /* Avoid this for now -- checking this register is expensive. */ /* Make sure this is really our interrupt. */ - if (!(CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE)) + if ((CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE)) return; #endif /* Ack interrupt and stop others from occuring. */ Index: if_bgereg.h =================================================================== RCS file: /cvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.1.2.7 diff -U3 -r1.1.2.7 if_bgereg.h --- if_bgereg.h 2 Nov 2002 18:17:55 -0000 1.1.2.7 +++ if_bgereg.h 22 Nov 2002 01:58:45 -0000 @@ -1678,11 +1678,23 @@ } bge_hostaddr; #define BGE_HOSTADDR(x) x.bge_addr_lo +typedef union { + struct { +#if BYTE_ORDER == BIG_ENDIAN + u_int16_t bge_max_len; + u_int16_t bge_flags; +#else + u_int16_t bge_flags; + u_int16_t bge_max_len; +#endif + } s; + u_int32_t bge_len_flags; +} bge_max_len_flags; + /* Ring control block structure */ struct bge_rcb { bge_hostaddr bge_hostaddr; - u_int16_t bge_flags; - u_int16_t bge_max_len; + bge_max_len_flags bge_len_flags; u_int32_t bge_nicaddr; }; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 20:35:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E50C37B401 for ; Thu, 21 Nov 2002 20:35:50 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9211743E4A for ; Thu, 21 Nov 2002 20:35:49 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id gAM4ZhdK034597; Thu, 21 Nov 2002 20:35:43 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id gAM4ZgWe081306; Thu, 21 Nov 2002 20:35:42 -0800 (PST) (envelope-from jdp) Date: Thu, 21 Nov 2002 20:35:42 -0800 (PST) Message-Id: <200211220435.gAM4ZgWe081306@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: sam@errno.com, Don Bowman Subject: Re: bge bug w/ out of bounds return receiver, staying in rxeof all the time, patch In-Reply-To: <184f01c291c9$147e7100$52557f42@errno.com> References: <184f01c291c9$147e7100$52557f42@errno.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <184f01c291c9$147e7100$52557f42@errno.com>, Sam Leffler wrote: > > I would recommend a committer look this over and > > commit it. If you wish, I can make the patch *just* > > be the change (changing the 16-bit to 32-bit writes, > > without the VPD stuff), but the other changes seemed > > generally useful. > > Please whittle the patch down to just the bug fix; 5.0 is in code freeze. Don't worry, Sam. I'm planning to shepherd this stuff into the tree, but I don't see it happening for 5.0. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 21:38:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B03E37B401 for ; Thu, 21 Nov 2002 21:38:09 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5EC43E4A for ; Thu, 21 Nov 2002 21:38:09 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gAM5c89i083117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 21 Nov 2002 21:38:08 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <196301c291e9$56d25e70$52557f42@errno.com> From: "Sam Leffler" To: Subject: CFR: MFC of mtags Date: Thu, 21 Nov 2002 21:38:08 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 want to commit the mbuf packet tag changes to stable. These changes replace the aux mbuf pointer in the mbuf with a list of "packet tags". This does not change the size of the mbuf structure but does affect any software that uses them (presently only KAME ipsec which has been patched to use packet tags instead). Included in the patch is a change to the calling convention of ip_output to add a struct inpcb * instead of passing this pointer via an aux mbuf. This was done to eliminate the main use of aux mbufs but would affect any software that directly calls ip_output (currently only ipfilter which has been patched appropriately). All these changes have been in current for a while. They were originally developed in stable and have been in use, in one form or another (in stable), for ~9 months. If you have issues with these changes please contact me directly. I'll wait a week before applying them. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 21 21:40: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D22F237B404 for ; Thu, 21 Nov 2002 21:40:05 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 260DC43E91 for ; Thu, 21 Nov 2002 21:40:05 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gAM5e49i083129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 21 Nov 2002 21:40:05 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <196b01c291e9$9c0361b0$52557f42@errno.com> From: "Sam Leffler" To: References: <196301c291e9$56d25e70$52557f42@errno.com> Subject: Re: MFC of mtags Date: Thu, 21 Nov 2002 21:40:04 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 want to commit the mbuf packet tag changes to stable. These changes > replace the aux mbuf pointer in the mbuf with a list of "packet tags". This > does not change the size of the mbuf structure but does affect any software > that uses them (presently only KAME ipsec which has been patched to use > packet tags instead). > > Included in the patch is a change to the calling convention of ip_output to > add a struct inpcb * instead of passing this pointer via an aux mbuf. This > was done to eliminate the main use of aux mbufs but would affect any > software that directly calls ip_output (currently only ipfilter which has > been patched appropriately). > > All these changes have been in current for a while. They were originally > developed in stable and have been in use, in one form or another (in > stable), for ~9 months. > > If you have issues with these changes please contact me directly. I'll wait > a week before applying them. > Sigh, the patch is found at http://www.freebsd.org/~sam/mtag-stable.patch. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 0: 2:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDB0237B401 for ; Fri, 22 Nov 2002 00:02:43 -0800 (PST) Received: from softweyr.com (softweyr.com [209.63.227.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 185CC43E3B for ; Fri, 22 Nov 2002 00:02:43 -0800 (PST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 18F8li-0003VI-00; Fri, 22 Nov 2002 01:02:30 -0700 Message-ID: <3DDDE495.9AFF760E@softweyr.com> Date: Fri, 22 Nov 2002 00:02:29 -0800 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler Cc: net@freebsd.org Subject: Re: CFR: MFC of mtags References: <196301c291e9$56d25e70$52557f42@errno.com> 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 Sam Leffler wrote: > > All these changes have been in current for a while. They were originally > developed in stable and have been in use, in one form or another (in > stable), for ~9 months. > > If you have issues with these changes please contact me directly. I'll wait > a week before applying them. Wanna post a patch for the stalwarts to test? If we had RELENG_4 in P4 you could just branch. Sigh. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 0:10:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EC5B37B401 for ; Fri, 22 Nov 2002 00:10:10 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E989343E97 for ; Fri, 22 Nov 2002 00:10:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.168.4]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021122081009.EUAI26148.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 22 Nov 2002 08:10:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA10059; Fri, 22 Nov 2002 00:08:28 -0800 (PST) Date: Fri, 22 Nov 2002 00:08:28 -0800 (PST) From: Julian Elischer To: Sam Leffler Cc: net@freebsd.org Subject: Re: CFR: MFC of mtags In-Reply-To: <196301c291e9$56d25e70$52557f42@errno.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 ok by me.. On Thu, 21 Nov 2002, Sam Leffler wrote: > I want to commit the mbuf packet tag changes to stable. These changes > replace the aux mbuf pointer in the mbuf with a list of "packet tags". This > does not change the size of the mbuf structure but does affect any software > that uses them (presently only KAME ipsec which has been patched to use > packet tags instead). > > Included in the patch is a change to the calling convention of ip_output to > add a struct inpcb * instead of passing this pointer via an aux mbuf. This > was done to eliminate the main use of aux mbufs but would affect any > software that directly calls ip_output (currently only ipfilter which has > been patched appropriately). > > All these changes have been in current for a while. They were originally > developed in stable and have been in use, in one form or another (in > stable), for ~9 months. > > If you have issues with these changes please contact me directly. I'll wait > a week before applying them. > > Sam > > > 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 22 0:12:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E473537B401; Fri, 22 Nov 2002 00:12:27 -0800 (PST) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5FEC43E8A; Fri, 22 Nov 2002 00:12:20 -0800 (PST) (envelope-from ian.watkinson@ehsbrann.com) Received: from subtlety ([80.3.50.15]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021122081219.WANE15173.mta01-svc.ntlworld.com@subtlety>; Fri, 22 Nov 2002 08:12:19 +0000 Reply-To: From: "Ian Watkinson" To: "'Nikolay Petrov'" , Cc: , , Subject: RE: VPN Date: Fri, 22 Nov 2002 08:12:18 -0000 Organization: EHSBrann Message-ID: <082c01c291fe$e0735250$6502010a@subtlety> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <111773281.20021122091821@hq.panda.bg> Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Nikolay Petrov [mailto:nik@hq.panda.bg]=20 > Sent: 22 November 2002 07:18 > To: owner-freebsd-security@FreeBSD.ORG; Ian Watkinson > Cc: freebsd-questions@FreeBSD.ORG; freebsd-net@FreeBSD.ORG;=20 > freebsd-security@freebsd.org > Subject: Re: VPN >=20 >=20 > Hello Ian, >=20 > Thursday, November 21, 2002, 11:18:27 PM, you wrote: >=20 > IW> Been looking at a number of how-to's on the web for=20 > connecting Win2k=20 > IW> clients to Freebsd as a VPN. >=20 > IW> However, despite carefully following them, I can't get=20 > any of them=20 > IW> to work. >=20 > IW> Could someone on the list who has managed this, either=20 > point me in=20 > IW> the direction of a how-to that works, or share their config That=20 > IW> works with the list? >=20 > IW> Many thanks in advance. >=20 >=20 > You can use net/mpd port, ho have good documentation >=20 My fault for not being more specific, I was hoping to use IPSEC, however I can't seem to get beyond windows "Negotiating Security" --=20 Ian Watkinson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ICQ 2781385 Internet Pager 2781385@pager.icq.com =20 =20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 0:30:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7215737B401; Fri, 22 Nov 2002 00:30:36 -0800 (PST) Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5215343E4A; Fri, 22 Nov 2002 00:30:35 -0800 (PST) (envelope-from vova@sw.ru) Received: from vova by vbook.express.ru with local (Exim 4.10) id 18F9Cp-0000H4-00; Fri, 22 Nov 2002 11:30:31 +0300 Subject: Re: Bluetooth questions From: "Vladimir B. " Grebenschikov To: Maksim Yevmenkin Cc: mobile@freebsd.org, net@freebsd.org In-Reply-To: <3DDD57A6.7712B1C5@exodus.net> References: <20021121184941.94838.qmail@web11408.mail.yahoo.com> <3DDD33C6.FE66E568@exodus.net> <1037910658.914.15.camel@vbook> <3DDD57A6.7712B1C5@exodus.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Inc. Message-Id: <1037953830.705.27.camel@vbook> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 22 Nov 2002 11:30:31 +0300 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 =F7 Fri, 22.11.2002, =D7 01:01, Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=CC: > > Is Nokia 6310(i) cell phone supported by FreeBSD bluetooth stack ? > > (of course most interesting as cell modem) >=20 > You have got to try it for yourself :) I have received > successful reports about Nokia 7650, so there is a > pretty good chance you can make it work :) You most=20 > likely can use your Bluetooth enabled cell phone as > a wireless modem. You need to download and install > rfcommd from ports/. Ok, will try when will get phone. > > What bluetooth adapters (USB/PCMCI/CF) known as work well with FreeBSD. >=20 > USB dongles: 3COM, EPoX, Mitsumi, MSI and TDK. also > if your USB dongle has CSR chip in it then it pretty > much guaranteed to be supported. >=20 > PCCARD: 3COM and Xircom(*). Xircom card is a 16550A > UART based card and may not work very well because of > "sio" driver issues. The same is true for any 16550A > UART based card. However if you can convince your > system give separate IRQ for PCCARD and "sio" driver > uses fast interrupts then this card might work well > for you. I managed to do so on my not so -current > and OLDCARD. If I right understand you I have more chanses with USB adapter Frankly speaking PCMCI do not works well under -CURRENT on my=20 SONY VAIO PCG-z505s Insert/Edject card freeze machine 100% guarntee, so only option to boot with card inserted - in this case it works. This happens both NEWCARD and OLDCARD, -STABLE and -CURRENT My cbb is cbb0: Days ago (times of 4.3/4.4) it works well both under current and=20 under stable.=20 May be you have some ideas ? > max --=20 Vladimir B. Grebenschikov SWsoft Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 2:25:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D244F37B401 for ; Fri, 22 Nov 2002 02:25:07 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFEE43EA3 for ; Fri, 22 Nov 2002 02:25:05 -0800 (PST) (envelope-from mattias.pettersson@era.ericsson.se) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAMAOtKV009878; Fri, 22 Nov 2002 11:24:55 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLJ4JS1; Fri, 22 Nov 2002 11:24:54 +0100 Message-ID: <3DDE045F.5CC8F5B5@era.ericsson.se> Date: Fri, 22 Nov 2002 11:18:07 +0100 X-Sybari-Trust: e8f45b93 ca231590 698a2c29 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snap-users@kame.net Cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 7197) Interrupt levels and concurrency References: <3DDD0E1B.80C8C4AA@it.uc3m.es> 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 Hi, Giving it a try: Juan Francisco Rodriguez Hervella wrote: > > Hello (again :) > > I'm doing my best, but I'm in a mess trying to understand > the interrup levels and if I should take it into account > to implement what I want to implement :) > > As I'm working with KAME source code, I will CC this question. > (KAME people always help me a lot :) > > I have the following situation: I've got an array, which > is filled in using received packets, but it can also be filled in > using the function "getaddrinfo()". Finally, this array > is searched inside ip_output() function. > > So I was thinking of implementing the interaction between "getaddrinfo" > and this kernel-array using "sysctl" interface, but I was wondering > if I need to low the interrup level to fill in this array inside the > sysctl_function(), because it could happen that at the same time > a new packet arrived at and it can try to access the same structure. Yes, I think you should protect that piece of code with "spl(net)... " inside sysctl, in case ip_input is pre-empting it. Doing that you can be sure that no other code running at "net" level will mess with the array. > > I've implemented some other code with sysctls calls and I've never > worried about the interrups levels, but now I've got a doubt... > does "sysctl" takes into account the likehood of concurrent system calls > ? > I hope so.... > > Returning to my implementation, Would I have to worry about the case > when "getaddrinfo" is calling to sysctl to add a new entry and then the > function ip_output() begins to search the share structure also ? > No. ip_output() I think runs at spl(net) too, so as long as sysctl is running at net it should work fine. In addition, user space does not really have any priority over kernel. > I can see that my array can be accesed from (at least) the following > points: > > 1. User layer (getaddrinfo) > 2. IP layer (ip_input, ip_output) > > I was thinking of calling directly to the sysctl_function() inside > ip_input() and also inside ip_output(). I hope there's no problem with > this. Not sure.Subject: Re: (KAME-snap 7197) Interrupt levels and concurrency Date: Fri, 22 Nov 2002 09:57:57 +0100 From: Mattias Pettersson Organization: Ericsson Research To: jrh@it.uc3m.es References: 1 Hi, I send this to you privately, because I don't want to embarass myself on the lists if I'm saying something stupid... ;) Juan Francisco Rodriguez Hervella wrote: > > Hello (again :) > > I'm doing my best, but I'm in a mess trying to understand > the interrup levels and if I should take it into account > to implement what I want to implement :) > > As I'm working with KAME source code, I will CC this question. > (KAME people always help me a lot :) > > I have the following situation: I've got an array, which > is filled in using received packets, but it can also be filled in > using the function "getaddrinfo()". Finally, this array > is searched inside ip_output() function. > > So I was thinking of implementing the interaction between "getaddrinfo" > and this kernel-array using "sysctl" interface, but I was wondering > if I need to low the interrup level to fill in this array inside the > sysctl_function(), because it could happen that at the same time > a new packet arrived at and it can try to access the same structure. Yes, I think you should protect that piece of code with "spl(net)... " inside sysctl, in case ip_input is pre-empting it. Doing that you can be sure that no other code running at "net" level will mess with the array. > > I've implemented some other code with sysctls calls and I've never > worried about the interrups levels, but now I've got a doubt... > does "sysctl" takes into account the likehood of concurrent system calls > ? > I hope so.... > > Returning to my implementation, Would I have to worry about the case > when "getaddrinfo" is calling to sysctl to add a new entry and then the > function ip_output() begins to search the share structure also ? > No. ip_output() I think runs at spl(net) too, so as long as sysctl is running at net it should work fine. In addition, user space does not really have any priority over kernel. > I can see that my array can be accesed from (at least) the following > points: > > 1. User layer (getaddrinfo) > 2. IP layer (ip_input, ip_output) > > I was thinking of calling directly to the sysctl_function() inside > ip_input() and also inside ip_output(). I hope there's no problem with > this. Not sure. I once tried to reuse in6_control() in the kernel to achieve something like an "ifconfig", but KAME didn't like that. Hope it helps. /Mattias > > Could you suggest me anything ? You have a lot of experience > with these topics, and any guideline or explanation that you give > me will be very very thanksfully thanked (sorry for my awful English :) > > Thanks! > > -- > JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 2:47:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E8E837B401 for ; Fri, 22 Nov 2002 02:47:55 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A8B43E91 for ; Fri, 22 Nov 2002 02:47:53 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gAMAlmuO054129; Fri, 22 Nov 2002 12:47:50 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DDE0B54.70207@he.iki.fi> Date: Fri, 22 Nov 2002 12:47:48 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021117 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: broken IFF_ALLMULTI handling in many drivers References: <20021117093656.A17547@xorpc.icir.org> 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 I think the same applies for promiscuous mode, if the interface undergoes configuration changes while it's in promiscuous mode and the hardware gets reinitialized it "forgets" about being in that mode. This happens at least with em. Pete Luigi Rizzo wrote: >[Bcc to re@ because it would be good to have it fixed before 5.0] > >Hi, >Pavlin Radoslavov recently discovered a problem that affects several >network drivers and tends to show up when running multicast routing. > >The problem is that the multicast routing code calls iff_allmulti() >on the interfaces, which should enable them to receive all multicast >packets. The device independent code sets the IFF_ALLMULTI flag in >the ifp, and then calls the device-specific ioctl handler for >SIOCSIFFLAGS. > >Individual drivers handle this call in the most various ways. Some >unconditionally reinitialize the hardware; some try to be smart and >only check which IFF_* flags have changed and perform appropriate >actions. And here is the problem -- several drivers forget to check >for a change in IFF_ALLMULTI, thus causing the change to be ignored >until some future action on the interface causes it (or its multicast >filter) to be reinitialized. > >A list of broken which are broken and good is below. The 'broken' >list is worrysome as it includes a lot of new/high performance/wireless >cards. > > Broken: dc mn sf sk ste ti tl xl an bge em gem gx ie lge sr > aue cue kue wi xe > > Correct: de rl sis vr wb ar(?) cnw cs ed ep ex fe fxp > hme lnc my nge ray sbni sn tx txp vx wl > >I believe the best way to fix this bug (in the *_ioctl handler, >for the SIOCSIFFLAGS case) is to follow the approach used by the >cs, ed, fe and vx drivers -- but if others have better suggestions >please let me know. > >So, provided re@ approves, expect to see some commits to the drivers >in the 'broken' list related to this problem. > > cheers > luigi >----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2988 >----------------------------------+----------------------------------------- > > >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 22 3:44:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A853237B404 for ; Fri, 22 Nov 2002 03:44:32 -0800 (PST) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B55143EA3 for ; Fri, 22 Nov 2002 03:44:31 -0800 (PST) (envelope-from rik@cronyx.ru) Received: by hanoi.cronyx.ru id OAA33267 for freebsd-net@FreeBSD.org.checked; (8.9.3/vak/2.1) Fri, 22 Nov 2002 14:41:04 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id OAA33114; (8.9.3/vak/2.1) Fri, 22 Nov 2002 14:38:24 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <3DDE183D.6040206@cronyx.ru> Date: Fri, 22 Nov 2002 14:42:53 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-net@FreeBSD.org Subject: Re: sppp patch's References: <000901c1134b$827a69a0$48b5ce90@crox> <3BDABF7B.4060808@cronyx.ru> <3BE24EE4.2020506@cronyx.ru> <20011102192916.A43204@uriah.heep.sax.de> <3BE3ED17.3060603@cronyx.ru> <20011231165245.B73897@uriah.heep.sax.de> <3DDD1D67.4050905@cronyx.ru> <20021121221833.A70987@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Joerg Wunsch wrote: >As Roman Kurakin wrote: > > > >> Sppp still have a quantity of bugs. Here is one of them: >> >>--- if_spppsubr.c.orig Wed Oct 16 18:41:16 2002 >>+++ if_spppsubr.c Thu Nov 21 20:13:16 2002 >>@@ -1672,12 +1672,12 @@ >> case STATE_ACK_SENT: >> break; >> case STATE_CLOSING: >>- sppp_cp_change_state(cp, sp, STATE_CLOSED); >> (cp->tlf)(sp); >>+ sppp_cp_change_state(cp, sp, STATE_CLOSED); >> break >> > >[...] > > >>In all cases we have the same problem: at first we should call tlf >>that will changes state and then we should set proper state. If we >>set some state and then call tlf we will get wrong final state. >> >> > >Can you please explain more, e. g. with a ifconfig debug trace? The > I couldn't make debug trace right now, because this fix was made long time ago and I don't remember how to reproduce all those problems. >RFC doesn't mandate a particular order between the actions and the >actual state change, and IIRC (without digging down into the code >right now), reverting the order has other unwanted side effects. > But RFC imply which final state should be at the and of all operations in particular case. If we call tlf and then change state we will get proper final state. If we choose the other way we will get wrong final state. Current sppp has some fixes that cure a problem in place it become apparent, but don't fix it in place where it occurs. So, probably many of the problems are solved, but they are solved incorrectly, and maybe this one is solved too. Best regards, Roman Kurakin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 6:58:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C0737B401 for ; Fri, 22 Nov 2002 06:58:10 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 399CE43EE8 for ; Fri, 22 Nov 2002 06:58:10 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Nov 2002 09:58:05 -0500 Message-ID: From: Don Bowman To: 'John Polstra' , net@freebsd.org Cc: sam@errno.com, Don Bowman Subject: RE: bge bug w/ out of bounds return receiver, staying in rxeof al l the time, patch Date: Fri, 22 Nov 2002 09:58:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: John Polstra [mailto:jdp@polstra.com] > In article <184f01c291c9$147e7100$52557f42@errno.com>, > Sam Leffler wrote: > > > I would recommend a committer look this over and > > > commit it. If you wish, I can make the patch *just* > > > be the change (changing the 16-bit to 32-bit writes, > > > without the VPD stuff), but the other changes seemed > > > generally useful. > > > > Please whittle the patch down to just the bug fix; 5.0 is > in code freeze. > > Don't worry, Sam. I'm planning to shepherd this stuff into the > tree, but I don't see it happening for 5.0. > Be aware that the bge driver is not too useful (and quite dangerous) without this change. Personally I'd like to see it go in 4.8. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 7:20:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3AE637B401 for ; Fri, 22 Nov 2002 07:20:30 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BA0443E88 for ; Fri, 22 Nov 2002 07:20:27 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A0B54431AC; Fri, 22 Nov 2002 16:20:23 +0100 (CET) Received: from it.uc3m.es (zangano.it.uc3m.es [163.117.140.41]) by smtp02.uc3m.es (Postfix) with ESMTP id 5CCF999F36; Fri, 22 Nov 2002 16:20:19 +0100 (CET) Message-ID: <3DDE4B32.107DD140@it.uc3m.es> Date: Fri, 22 Nov 2002 16:20:18 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson Cc: snap-users@kame.net, freebsd-net@FreeBSD.ORG Subject: Re: (KAME-snap 7197) Interrupt levels and concurrency References: <3DDD0E1B.80C8C4AA@it.uc3m.es> <3DDE045F.5CC8F5B5@era.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Mattias, Mattias Pettersson escribió: > > Hi, > > Giving it a try: > > Juan Francisco Rodriguez Hervella wrote: > > > > Hello (again :) > > > > I'm doing my best, but I'm in a mess trying to understand > > the interrup levels and if I should take it into account > > to implement what I want to implement :) > > > > As I'm working with KAME source code, I will CC this question. > > (KAME people always help me a lot :) > > > > I have the following situation: I've got an array, which > > is filled in using received packets, but it can also be filled in > > using the function "getaddrinfo()". Finally, this array > > is searched inside ip_output() function. > > > > So I was thinking of implementing the interaction between "getaddrinfo" > > and this kernel-array using "sysctl" interface, but I was wondering > > if I need to low the interrup level to fill in this array inside the > > sysctl_function(), because it could happen that at the same time > > a new packet arrived at and it can try to access the same structure. > > Yes, I think you should protect that piece of code with "spl(net)... " > inside sysctl, in case ip_input is pre-empting it. > > Doing that you can be sure that no other code running at "net" level > will mess with the array. > > > > I've implemented some other code with sysctls calls and I've never > > worried about the interrups levels, but now I've got a doubt... > > does "sysctl" takes into account the likehood of concurrent system calls > > ? > > I hope so.... > > > > Returning to my implementation, Would I have to worry about the case > > when "getaddrinfo" is calling to sysctl to add a new entry and then the > > function ip_output() begins to search the share structure also ? > > > > No. ip_output() I think runs at spl(net) too, so as long as sysctl is > running at net it should work fine. > > In addition, user space does not really have any priority over kernel. > > > I can see that my array can be accesed from (at least) the following > > points: > > > > 1. User layer (getaddrinfo) > > 2. IP layer (ip_input, ip_output) > > > > I was thinking of calling directly to the sysctl_function() inside > > ip_input() and also inside ip_output(). I hope there's no problem with > > this. > > Not sure. >I once tried to reuse in6_control() in the kernel to >achieve >something like an "ifconfig", but KAME didn't like that. > >Hope it helps. > > /Mattias Thanks for your fast reply... After thinking of it, I think you're right, with splnet inside sysctl function should be enough. Forget about my last paragraph, when I was talking about calling directly to sysctl_function from the ip_input(), I wanted to make that because the code for adding a new element in the array was implemented there.... forget it and thank you very much :) -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 7:21:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D83AE37B401 for ; Fri, 22 Nov 2002 07:21:12 -0800 (PST) Received: from hotmail.com (f48.law3.hotmail.com [209.185.241.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7F443E88 for ; Fri, 22 Nov 2002 07:21:12 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 07:21:12 -0800 Received: from 199.84.165.3 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 22 Nov 2002 15:21:12 GMT X-Originating-IP: [199.84.165.3] From: "Vincent Goupil" To: freebsd-net@FreeBSD.ORG Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter Date: Fri, 22 Nov 2002 15:21:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2002 15:21:12.0377 (UTC) FILETIME=[CA8CAA90:01C2923A] 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 also notice that when I experiencing network slowdown, it also reject some (half) ping icmp. I just need to reboot and all came back to normal. >other questions was: > - what is "Slow network response"? > - does ifconfig down/up helps? >tcpdump buffers output so >usful bits are some time after trouble. >In my case slowdown triggered by >arp scans > > > My network is composed with Windows 2000 servers and pro. > > 192.168.20.2 <- w2k srv > > 192.168.20.3 <- w2k srv > > 192.168.20.7 <- w2k srv > > 192.168.20.8 <- w2k srv > > 192.168.20.9 <- w2k srv > > 192.168.20.10 <- another freebsd box > > 192.168.20.210 <- the firewall > > > > 23:58:43.356569 arp who-has 192.168.20.99 tell 192.168.20.8 > > 23:58:46.471284 arp who-has 192.168.20.127 tell 192.168.20.3 > > 23:58:46.472257 arp who-has 192.168.20.127 tell 192.168.20.8 > > 23:59:04.543497 arp who-has 192.168.20.2 tell 192.168.20.3 > > 23:59:10.352106 arp who-has 192.168.20.7 tell 192.168.20.200 > > 23:59:15.827551 arp who-has 192.168.20.251 tell 192.168.20.7 > > 23:59:17.082626 arp who-has 192.168.20.201 tell 192.168.20.8 > > 23:59:20.245406 arp who-has 192.168.20.201 tell 192.168.20.112 > > 23:59:22.723713 arp who-has 192.168.20.104 tell 192.168.20.3 > > 23:59:26.517132 arp who-has 192.168.20.6 tell 192.168.20.8 > > 23:59:28.824120 arp who-has 192.168.20.7 tell 192.168.20.99 > > 23:59:29.801078 arp who-has 192.168.20.6 tell 192.168.20.7 > > 23:59:48.762973 arp who-has 192.168.20.165 tell 192.168.20.8 > > 23:59:55.203905 arp who-has 192.168.20.75 tell 192.168.20.3 > > 23:59:55.688710 arp who-has 192.168.20.114 tell 192.168.20.8 > > 23:59:55.861042 arp who-has 192.168.20.77 tell 192.168.20.8 > > 00:00:00.192659 arp who-has 192.168.20.106 tell 192.168.20.201 > > 00:00:04.337994 arp who-has 192.168.20.10 tell 192.168.20.8 > > 00:00:04.538035 arp who-has 192.168.20.10 tell 192.168.20.2 > > 00:00:04.775959 arp who-has 192.168.20.10 tell 192.168.20.3 > > 00:00:05.022385 arp who-has 192.168.20.10 tell 192.168.20.9 > > 00:00:05.066194 arp who-has 192.168.20.10 tell 192.168.20.7 > > 00:00:05.209935 arp who-has 192.168.20.10 tell 192.168.20.6 > > 00:00:20.085908 arp who-has 192.168.20.9 tell 192.168.20.3 > > 00:00:20.116177 arp who-has 192.168.20.9 tell 192.168.20.8 > > 00:00:22.235535 arp who-has 192.168.20.101 tell 192.168.20.8 > > 00:00:22.236614 arp who-has 192.168.20.101 tell 192.168.20.3 > > 00:00:23.118443 arp who-has 192.168.20.54 tell 192.168.20.3 > > 00:00:25.075679 arp who-has 192.168.20.7 tell 192.168.20.201 > > 00:00:29.815522 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:30.587208 arp who-has 192.168.20.157 (2f:69:70:63:68:65) tell > > 192.168.20.201 > > 00:00:31.810270 arp who-has 192.168.20.166 tell 192.168.20.7 > > 00:00:45.473558 arp who-has 192.168.20.177 tell 192.168.20.201 > > > > > > >From: "."@babolo.ru > > >To: Vincent Goupil > > >CC: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG > > >Subject: Re: Slow network response with FreeBSD 4.6.2 and ipfilter > > >Date: Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >MIME-Version: 1.0 > > >Received: from aaz.links.ru ([193.125.152.37]) by >mc6-f36.law1.hotmail.com > > >with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 19:08:36 -0800 > > >Received: from aaz.links.ru (aaz.links.ru [193.125.152.37])by >aaz.links.ru > > >(8.12.6/8.12.6) with ESMTP id gAK3AfDh006526;Wed, 20 Nov 2002 06:10:41 > > >+0300 (MSK)(envelope-from babolo@aaz.links.ru) > > >Received: (from babolo@localhost)by aaz.links.ru (8.12.6/8.12.6/Submit) >id > > >gAK3AeSv006525;Wed, 20 Nov 2002 06:10:40 +0300 (MSK) > > >Message-Id: <200211200310.gAK3AeSv006525@aaz.links.ru> > > >X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; >no-hdr-encoding=1 > > >In-Reply-To: > > >X-Mailer: ELM [version 2.4ME+ PL99b (25)] > > >Return-Path: babolo@aaz.links.ru > > >X-OriginalArrivalTime: 20 Nov 2002 03:08:36.0969 (UTC) > > >FILETIME=[1E422D90:01C29042] > > > > > > > I have a system running FreeBSD 4.6.2-RELEASE-p5 #0 with ipfilter > > >v3.4.27. > > > > This system act as a firewall for an enterprise. They need high > > > > availability. I have 5 network card, all 3C905 (3*3c905B-TX and > > >2*905C-TX). > > > > I made this setup in july and it run fine until 3 weeks ago. The > > >first > > > > and second card are for the internet link (primary and backup). The > > >third > > > > is for DMZ and the fourth is for local network. The fifth is unused > > >(marked > > > > as down). Each card as is own IRQ (except the fifth that is shared >with > > >the > > > > first). The high availability is provided by the two internet link, >if > > >one > > > > goes down, the second take the load (change default route, ipf >rules, > > >ipnat > > > > rules and DNS records). This is done by a script running by cron. >We > > >can > > > > also do that manually. We have two /29 network for the first link >and > > >one > > > > /28 network for the second (we use alias on internet interfaces). >There > > >is > > > > only 3 services that run on the firewall: SSH (but only accessible >from > > >3 > > > > subnets), ftpproxy (jftpgw 0.13.1) and snmp (only accessible by one > > >subnet) > > > > > > > > We begin to have problem 3 weeks ago. The firewall begin to have a >slow > > > > response. I begin to have this arp message error (many times): > > > > arplookup 255.255.255.0 failed: host is not on local network > > > > arpresolve: can't allocate llinfo for 255.255.255.0rt > > > > We reboot the server and the network fast as earlier. I finally >find > > > > something: when we use alias, we need to have at least one regular > > >netmask > > > > (instead of 255.255.255.255) for each network/subnetwork. My error >was > > >on > > > > the first link, my second sub-network was not configured properly. >I > > > > changed it and it stop to have these errors about arp but the >problem > > >wasn't > > > > resolved. The network continue to be slow until we reboot the >server. > > >This > > > > happen during the day. Now, it happen everytime. > > > > > > > > What I've done: > > > > - I changed the netmask (as said earlier) > > > > - I upgraded from 4.6-RELEASE #0 to 4.6.2-RELEASE-p5 #0. > > > > - I look for IRQ conflict > > > > - I configure all interface with media and mediaopt. They not using > > > > autodetect anymore. > > > > - I chkrootkit and nothing found > > > > > > > > What I suspect: > > > > - I read in a forum that the driver (xl) of 3C905 is not the best >for > > > > FreeBSD. I don't know if this apply to 4.6.2. > > > > - Ethernet cables (I need to change it) > > > > - We run SSL (with a lot of users) in one of our web servers in the >dmz. > > >As > > > > I know, SSL run on top of TCP, it should not be a problem. > > > > - When i run ifpromisc (in chkrootkit), it tell me that "xl0 is not > > >promisc" > > > > and "xl1 is not promisc". I have 5 interfaces, what about the >others ? > > > > > > > > Can someone have an idea ? > > >What you mean when say "Slow network response"? > > >If that mean that packets trawel long > > >from some host to host under question > > >as reported by tcpdump, does ifconfig xlN down > > >and then ifconfig xlN up repare situation > > >for some time? > > >What tcpdump -npi xlN ether broadcast and not ip > > >say when slowdown hapens? > > > > > >-- > > >@BABOLO http://links.ru/ > > > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > >-- >@BABOLO http://links.ru/ > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-isp" in the body of the message _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 7:52:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA0F37B401 for ; Fri, 22 Nov 2002 07:52:38 -0800 (PST) Received: from cluttered.com (w024.z064002058.sjc-ca.dsl.cnc.net [64.2.58.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F5E43E91 for ; Fri, 22 Nov 2002 07:52:38 -0800 (PST) (envelope-from jsd@cluttered.com) Received: from boombox.cluttered.com (dhcp26 [10.10.10.26]) by cluttered.com (Postfix) with ESMTP id 5E7D51D104 for ; Fri, 22 Nov 2002 07:52:39 -0800 (PST) Message-Id: <5.1.0.14.2.20021122074425.00baf340@mail.cluttered.com> X-Sender: jsd@mail.cluttered.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Nov 2002 07:52:35 -0800 To: freebsd-net@freebsd.org From: Jon Drukman Subject: mpd - vpn to windows server - very slow Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i'm using mpd to connect to my work's VPN, running some form of windows vpn server. unfortunately performance is really miserable. it seems to work fine for tiny transmissions (1K or less) but anything over that stutters, and if it's a big data dump (like scp'ing a 30K file or receiving email with a 15K attachment) it just stalls completely. here is my mpd.conf: default: load work work: new -i ng0 ms-pptp work set log +pptp +pptp2 +pptp3 +lcp +auth set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ipcp yes vjcomp set link disable chap pap set link accept chap set link yes acfcomp protocomp set iface idle 0 set bundle disable multilink set link enable no-orig-auth set link keep-alive 10 75 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp no mpp-stateless set iface route 10.16.0.0/16 set iface route 10.17.0.0/16 set iface route 10.20.0.0/16 set bundle authname "cnet\\jdrukman" set bundle password "xxx set iface disable on-demand set link max-redial 1 open iface and mpd.links: work: set link type pptp set pptp self 64.2.58.24 set pptp peer client-vpn-sf.cnet.com set pptp enable originate outcall here is the output from "# mpd work" pptp0: connected to 206.16.4.253:1723 pptp0: attached to connection with 206.16.4.253:1723 pptp0-0: outgoing call connected at 64000 bps [work] PPTP call successful [work] device: UP event in state OPENING [work] device is now in state UP [work] link: UP event [work] link: origination is local [work] LCP: Up event [work] LCP: state change Starting --> Req-Sent [work] LCP: phase shift DEAD --> ESTABLISH [work] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM dd3c81c0 [work] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM dd3c81c0 [work] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM dd3c81c0 [work] LCP: state change Req-Sent --> Ack-Rcvd [work] LCP: rec'd Configure Request #212 link 0 (Ack-Rcvd) MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFTv2 MAGICNUM 24ac06cc PROTOCOMP ACFCOMP [work] LCP: SendConfigAck #212 MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFTv2 MAGICNUM 24ac06cc PROTOCOMP ACFCOMP [work] LCP: state change Ack-Rcvd --> Opened [work] LCP: phase shift ESTABLISH --> AUTHENTICATE [work] LCP: auth: peer wants CHAP, I want nothing [work] LCP: LayerUp [work] CHAP: rec'd CHALLENGE #2 Name: "10.16.102.5" Using authname "cnet\jdrukman" [work] CHAP: sending RESPONSE [work] LCP: rec'd Configure Request #197 link 0 (Opened) MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFT MAGICNUM 29138139 PROTOCOMP ACFCOMP [work] LCP: LayerDown [work] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM dd3c81c0 [work] LCP: SendConfigAck #197 MRU 1500 ACCMAP 0x000a0000 AUTHPROTO CHAP MSOFT MAGICNUM 29138139 PROTOCOMP ACFCOMP [work] LCP: state change Opened --> Ack-Sent [work] LCP: phase shift AUTHENTICATE --> ESTABLISH [work] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM dd3c81c0 [work] LCP: state change Ack-Sent --> Opened [work] LCP: phase shift ESTABLISH --> AUTHENTICATE [work] LCP: auth: peer wants CHAP, I want nothing [work] LCP: LayerUp [work] CHAP: rec'd CHALLENGE #2 Name: "10.16.102.5" Using authname "cnet\jdrukman" [work] CHAP: sending RESPONSE [work] CHAP: rec'd SUCCESS #2 MESG: CHAP authentication success, unit 80936072 [work] LCP: authorization successful [work] LCP: phase shift AUTHENTICATE --> NETWORK [ms-pptp] up: 1 link, total bandwidth 64000 bps [ms-pptp] IPCP: Up event [ms-pptp] IPCP: state change Starting --> Req-Sent [ms-pptp] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [ms-pptp] CCP: Open event [ms-pptp] CCP: state change Initial --> Starting [ms-pptp] CCP: LayerStart [ms-pptp] CCP: Up event [ms-pptp] CCP: state change Starting --> Req-Sent [ms-pptp] CCP: SendConfigReq #1 MPPC 0x00000020: MPPE, 40 bit [ms-pptp] IPCP: rec'd Configure Request #189 link 0 (Req-Sent) IPADDR 10.16.102.5 10.16.102.5 is OK COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [ms-pptp] IPCP: SendConfigAck #189 IPADDR 10.16.102.5 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [ms-pptp] IPCP: state change Req-Sent --> Ack-Sent [ms-pptp] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) IPADDR 10.16.102.72 10.16.102.72 is OK COMPPROTO VJCOMP, 8 comp. channels, no comp-cid Adjusting # compression channels [ms-pptp] IPCP: SendConfigReq #2 IPADDR 10.16.102.72 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [ms-pptp] CCP: rec'd Configure Request #10 link 0 (Req-Sent) MPPC 0x00000020: MPPE, 40 bit [ms-pptp] CCP: SendConfigAck #10 MPPC 0x00000020: MPPE, 40 bit [ms-pptp] CCP: state change Req-Sent --> Ack-Sent [ms-pptp] CCP: rec'd Configure Ack #1 link 0 (Ack-Sent) MPPC 0x00000020: MPPE, 40 bit [ms-pptp] CCP: state change Ack-Sent --> Opened [ms-pptp] CCP: LayerUp Compress using: MPPE, 40 bit Decompress using: MPPE, 40 bit [ms-pptp] IPCP: rec'd Configure Ack #2 link 0 (Ack-Sent) IPADDR 10.16.102.72 COMPPROTO VJCOMP, 8 comp. channels, no comp-cid [ms-pptp] IPCP: state change Ack-Sent --> Opened [ms-pptp] IPCP: LayerUp 10.16.102.72 -> 10.16.102.5 [ms-pptp] IFACE: Up event [ms-pptp] exec: /sbin/ifconfig ng0 10.16.102.72 10.16.102.5 netmask 0xffffffff -link0 [ms-pptp] exec: /sbin/route add 10.16.0.0 10.16.102.5 -netmask 0xffff0000 [ms-pptp] exec: /sbin/route add 10.17.0.0 10.16.102.5 -netmask 0xffff0000 [ms-pptp] exec: /sbin/route add 10.20.0.0 10.16.102.5 -netmask 0xffff0000 [ms-pptp] IFACE: Up event one thing i find interesting is it says "total bandwidth 64000" - i'm on dsl and i have way more than that (384Kbps up, 1.5Mbps down). is this something that is being negotiated between the vpn server & mpd? can i ask it to override that setting? the depressing thing is it works totally fine from a stock windows XP box so the people who run the vpn server are not interested in helping me figure this out. -jsd- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 8:10:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 663FA37B401; Fri, 22 Nov 2002 08:10:12 -0800 (PST) Received: from testmail.wolves.k12.mo.us (testmail.wolves.k12.mo.us [207.160.214.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBAEB43E88; Fri, 22 Nov 2002 08:10:11 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: by testmail.wolves.k12.mo.us (Postfix, from userid 1001) id 06AEC1A951; Fri, 22 Nov 2002 10:10:04 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by testmail.wolves.k12.mo.us (Postfix) with ESMTP id F39AD1A947; Fri, 22 Nov 2002 10:10:04 -0600 (CST) Date: Fri, 22 Nov 2002 10:10:04 -0600 (CST) From: Chris Dillon To: Carlos Carnero Cc: FreeBSD Network , FreeBSD Questions Subject: Re: Is there such a thing like a TCP proxy|relay? In-Reply-To: <20021121203035.60556.qmail@web21412.mail.yahoo.com> Message-ID: <20021122100705.P27486-100000@duey.wolves.k12.mo.us> 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, 21 Nov 2002, Carlos Carnero wrote: > ok, this is another wacky question. I have connected two subnetworks > to my FreeBSD router to the internet. By design they shouln't be > able to communicate between them--which I have done with IP Filter. > > What I'd like to do now is to make a TCP proxy/relay on my > firewall/router. For instance, opening port 3389 on the firewall > (from the inside, machine A) would open port 3389 of machine B that > sits on the other network. > > Is there a port that can handle that? Yes. ports/net/bsdproxy. I like it because it uses kqueue()/kevent() to do its thing rather than poll()/select(). -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 8:45:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD26737B401 for ; Fri, 22 Nov 2002 08:45:24 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA78D43E3B for ; Fri, 22 Nov 2002 08:45:23 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.12.3/8.12.3) with ESMTP id gAMGjKdK037828; Fri, 22 Nov 2002 08:45:20 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id gAMGjKPH082267; Fri, 22 Nov 2002 08:45:20 -0800 (PST) (envelope-from jdp) Date: Fri, 22 Nov 2002 08:45:20 -0800 (PST) Message-Id: <200211221645.gAMGjKPH082267@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: sam@errno.com Subject: Re: CFR: MFC of mtags In-Reply-To: <196301c291e9$56d25e70$52557f42@errno.com> References: <196301c291e9$56d25e70$52557f42@errno.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <196301c291e9$56d25e70$52557f42@errno.com>, Sam Leffler wrote: > I want to commit the mbuf packet tag changes to stable. These > changes replace the aux mbuf pointer in the mbuf with a list of > "packet tags". This does not change the size of the mbuf structure > but does affect any software that uses them (presently only KAME > ipsec which has been patched to use packet tags instead). I would strongly prefer that you not put this into the 4.x branch. The project has a policy against incompatible ABI changes within the -stable branch. If you do this MFC then those of us who rely on third-party binary-only network drivers (such as the ET Inc. drivers, upon which I and many others rely for network connectivity) will be SOL. Changing the ABI within the branch is unfair to the vendors who try to maintain drivers for FreeBSD, and it only discourages them from trying to support our operating system. Let's just let the 4.x branch live out the rest of its life span in a compatible way. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 9:18:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C80B237B401 for ; Fri, 22 Nov 2002 09:18:54 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D0543EA3 for ; Fri, 22 Nov 2002 09:18:54 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gAMHIoAh081717; Fri, 22 Nov 2002 09:18:50 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gAMHIomL081716; Fri, 22 Nov 2002 09:18:50 -0800 (PST) (envelope-from rizzo) Date: Fri, 22 Nov 2002 09:18:50 -0800 From: Luigi Rizzo To: John Polstra Cc: net@FreeBSD.ORG, sam@errno.com Subject: Re: CFR: MFC of mtags Message-ID: <20021122091850.A81622@xorpc.icir.org> References: <196301c291e9$56d25e70$52557f42@errno.com> <200211221645.gAMGjKPH082267@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200211221645.gAMGjKPH082267@vashon.polstra.com>; from jdp@polstra.com on Fri, Nov 22, 2002 at 08:45:20AM -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 i am pretty sure that this change does not affect low level drivers; the "any software that uses them" comment almost surely refers to the m_aux field, not to the entire struct mbuf. This said, fair behaviour cannot be requested to one side only. Sam posted patches, so those who have the hw/sw for which they suspect incompatibilities have all the resources to try the new code and find out whether their suspicions are founded or not. I am surely willing to listen to objections based on convincing evidence of breakage, whereas pure speculation is a much weaker argument. cheers luigi On Fri, Nov 22, 2002 at 08:45:20AM -0800, John Polstra wrote: > In article <196301c291e9$56d25e70$52557f42@errno.com>, Sam Leffler > wrote: > > I want to commit the mbuf packet tag changes to stable. These > > changes replace the aux mbuf pointer in the mbuf with a list of > > "packet tags". This does not change the size of the mbuf structure > > but does affect any software that uses them (presently only KAME > > ipsec which has been patched to use packet tags instead). > > I would strongly prefer that you not put this into the 4.x branch. > The project has a policy against incompatible ABI changes within the > -stable branch. If you do this MFC then those of us who rely on > third-party binary-only network drivers (such as the ET Inc. drivers, > upon which I and many others rely for network connectivity) will be > SOL. Changing the ABI within the branch is unfair to the vendors who > try to maintain drivers for FreeBSD, and it only discourages them from > trying to support our operating system. Let's just let the 4.x branch > live out the rest of its life span in a compatible way. > > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 9:26: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 251EB37B401 for ; Fri, 22 Nov 2002 09:26:06 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49F1A43EAF for ; Fri, 22 Nov 2002 09:26:05 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gAMHQ49i085404 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Nov 2002 09:26:04 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <1afc01c2924c$3c811ee0$52557f42@errno.com> From: "Sam Leffler" To: "Luigi Rizzo" , "John Polstra" Cc: References: <196301c291e9$56d25e70$52557f42@errno.com> <200211221645.gAMGjKPH082267@vashon.polstra.com> <20021122091850.A81622@xorpc.icir.org> Subject: Re: CFR: MFC of mtags Date: Fri, 22 Nov 2002 09:26:04 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > i am pretty sure that this change does not affect low level drivers; > the "any software that uses them" comment almost surely refers to the > m_aux field, not to the entire struct mbuf. > > This said, fair behaviour cannot be requested to one side only. > > Sam posted patches, so those who have the hw/sw for which they > suspect incompatibilities have all the resources to try the new > code and find out whether their suspicions are founded or not. > I am surely willing to listen to objections based on convincing > evidence of breakage, whereas pure speculation is a much weaker > argument. > John and I have been talking and there was some confusion on what might break. To try to clarify again: this should only affect existing software if it: 1. Calls ip_output directly. 2. Uses aux mbufs; e.g. calls m_aux*. Network interface drivers should never do #1. If they do #2 then I'd be very surprised, but that's what I'm searching for. John sent me an nm of the ET driver and it does not appear to do either. I understand that folks in this situation may have trouble verifying whether or not this patch would break their binary drivers as they may not be running a version of the system where this patch would apply cleanly. Regardless, I'm waiting a week to hear from everyone and then I'll decide if it's safe to commit the mods or not. Sam > > On Fri, Nov 22, 2002 at 08:45:20AM -0800, John Polstra wrote: > > In article <196301c291e9$56d25e70$52557f42@errno.com>, Sam Leffler > > wrote: > > > I want to commit the mbuf packet tag changes to stable. These > > > changes replace the aux mbuf pointer in the mbuf with a list of > > > "packet tags". This does not change the size of the mbuf structure > > > but does affect any software that uses them (presently only KAME > > > ipsec which has been patched to use packet tags instead). > > > > I would strongly prefer that you not put this into the 4.x branch. > > The project has a policy against incompatible ABI changes within the > > -stable branch. If you do this MFC then those of us who rely on > > third-party binary-only network drivers (such as the ET Inc. drivers, > > upon which I and many others rely for network connectivity) will be > > SOL. Changing the ABI within the branch is unfair to the vendors who > > try to maintain drivers for FreeBSD, and it only discourages them from > > trying to support our operating system. Let's just let the 4.x branch > > live out the rest of its life span in a compatible way. > > > > John > > -- > > John Polstra > > John D. Polstra & Co., Inc. Seattle, Washington USA > > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 9:55:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 846B737B401; Fri, 22 Nov 2002 09:55:17 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FE643EC2; Fri, 22 Nov 2002 09:55:17 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 09:55:17 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 09:55:16 -0800 Message-ID: <3DDE6F84.8A85F643@exodus.net> Date: Fri, 22 Nov 2002 09:55:16 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir B. Grebenschikov" Cc: mobile@freebsd.org, net@freebsd.org Subject: Re: Bluetooth questions References: <20021121184941.94838.qmail@web11408.mail.yahoo.com> <3DDD33C6.FE66E568@exodus.net> <1037910658.914.15.camel@vbook> <3DDD57A6.7712B1C5@exodus.net> <1037953830.705.27.camel@vbook> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Nov 2002 17:55:16.0798 (UTC) FILETIME=[50A75DE0:01C29250] 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 "Vladimir B. Grebenschikov" wrote: > > ÷ Fri, 22.11.2002, × 01:01, Maksim Yevmenkin ÎÁÐÉÓÁÌ: > > > Is Nokia 6310(i) cell phone supported by FreeBSD bluetooth stack ? > > > (of course most interesting as cell modem) > > > > You have got to try it for yourself :) I have received > > successful reports about Nokia 7650, so there is a > > pretty good chance you can make it work :) You most > > likely can use your Bluetooth enabled cell phone as > > a wireless modem. You need to download and install > > rfcommd from ports/. > > Ok, will try when will get phone. > > > > What bluetooth adapters (USB/PCMCI/CF) known as work well with FreeBSD. > > > > USB dongles: 3COM, EPoX, Mitsumi, MSI and TDK. also > > if your USB dongle has CSR chip in it then it pretty > > much guaranteed to be supported. > > > > PCCARD: 3COM and Xircom(*). Xircom card is a 16550A > > UART based card and may not work very well because of > > "sio" driver issues. The same is true for any 16550A > > UART based card. However if you can convince your > > system give separate IRQ for PCCARD and "sio" driver > > uses fast interrupts then this card might work well > > for you. I managed to do so on my not so -current > > and OLDCARD. > > If I right understand you I have more chanses with USB adapter > Frankly speaking PCMCI do not works well under -CURRENT on my > SONY VAIO PCG-z505s yes. USB devices have better chances. part of the problem is that Bluetooth spec does not define transport layer for PCCARDs, so every manufacturer does whatever he wants. > Insert/Edject card freeze machine 100% guarntee, so only option > to boot with card inserted - in this case it works. > > This happens both NEWCARD and OLDCARD, -STABLE and -CURRENT > My cbb is cbb0: > > Days ago (times of 4.3/4.4) it works well both under current and > under stable. > > May be you have some ideas ? no, sorry :( max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 11:24:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A34B237B401; Fri, 22 Nov 2002 11:24:27 -0800 (PST) Received: from hotmail.com (f159.law15.hotmail.com [64.4.23.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ACAE43EA9; Fri, 22 Nov 2002 11:24:27 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 11:24:27 -0800 Received: from 217.218.77.40 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 22 Nov 2002 19:24:27 GMT X-Originating-IP: [217.218.77.40] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Packet Capturing on GWs but don't let them go out. Date: Fri, 22 Nov 2002 19:24:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2002 19:24:27.0285 (UTC) FILETIME=[C5CAE450:01C2925C] 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 want to do packet capturing but as you know the pcap let the packet go out and just put a copy on the buffer . I just want to do a copy and don't let them go out . just i want that all of the packet from the sockets that are created by me travels through my server Packet ----- /* i don't want it to be forwarded */ |------> out |----> buffer ---> my process --------send-- THANX _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 11:24:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 865A037B401; Fri, 22 Nov 2002 11:24:56 -0800 (PST) Received: from hotmail.com (f90.law15.hotmail.com [64.4.23.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BC5D43EA3; Fri, 22 Nov 2002 11:24:56 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 11:24:55 -0800 Received: from 217.218.77.40 by lw15fd.law15.hotmail.msn.com with HTTP; Fri, 22 Nov 2002 19:24:54 GMT X-Originating-IP: [217.218.77.40] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: Packet Capturing on GWs but don't let them go out. Date: Fri, 22 Nov 2002 19:24:54 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2002 19:24:55.0085 (UTC) FILETIME=[D65CD5D0:01C2925C] 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 want to do packet capturing but as you know the pcap let the packet go out and just put a copy on the buffer . I just want to do a copy and don't let them go out . just i want that all of the packet from the sockets that are created by me travels through my server Packet ----- /* i don't want it to be forwarded */ |------> out |----> buffer ---> my process --------send-- I want to do a transparent third party traffic THANX _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 11:38:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED9737B401 for ; Fri, 22 Nov 2002 11:38:17 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC8443E88 for ; Fri, 22 Nov 2002 11:38:16 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (wireless251.east.isi.edu [65.123.202.251]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id gAMJcEC18442; Fri, 22 Nov 2002 11:38:14 -0800 (PST) Message-ID: <3DDE87A2.20908@isi.edu> Date: Fri, 22 Nov 2002 14:38:10 -0500 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Packet Capturing on GWs but don't let them go out. References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070003010600080508030303" 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. --------------ms070003010600080508030303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit soheil soheil wrote: > I want to do packet capturing but as you know the pcap let the packet go > out and just put a copy on the buffer . > I just want to do a copy and don't let them go out . Sounds like you should be using a divert socket, and not a bpf. Lars -- Lars Eggert USC Information Sciences Institute --------------ms070003010600080508030303 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTEyMjE5MzgxMFowIwYJKoZIhvcNAQkEMRYEFCBJ4RzEPqUp1b9zjQoW 56iBSnIlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCCVBMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMIJUEwDQYJKoZIhvcNAQEBBQAEggEAPma5+DbM1IMZ7Iro5GL00w+TSbTxFpTUVYtO /yWfbuJMJXs2EEEV+0QIfP/C2E2hDIwZVKFLNp5EVNrgwIMLr3qHgvjIafQsVvsYxoLfJuvu 1hP7HlU+8ANp0zx5OxlxZM3ha82iAewk21Hs0tFnY60UztyBzHIH5K39TMOyE9xxFNro4+Mo pqNFAvkG96gUBkRLkBy9B71fQB7guzMlZeZE4dVUdNsW8I3qUKFmUfgVFUWRD2Xb9env4r1O Bd/wr4wyVah36IT1nrSEznKbrooIGOJrExsXJRMqADi3LwiAIQ7AWL2F+aP8lDQevtRUUwLY LQB1WK0if+ogayc5cwAAAAAAAA== --------------ms070003010600080508030303-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 11:46: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9612F37B401 for ; Fri, 22 Nov 2002 11:46:02 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id D136C43E3B for ; Fri, 22 Nov 2002 11:46:01 -0800 (PST) (envelope-from Balaji.Prasad@nokia.com) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAMJk0j08425 for ; Fri, 22 Nov 2002 13:46:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Nov 2002 13:45:58 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 13:45:27 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: support for DWL-650 Date: Fri, 22 Nov 2002 11:45:26 -0800 Message-ID: <59A36C4D2F9E7243BEB522274F72C3031FF202@mvebe001.americas.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: support for DWL-650 Thread-Index: AcKSX7R3DUPCyE4nQiiMG7KA5zfFiQ== From: To: X-OriginalArrivalTime: 22 Nov 2002 19:45:27.0553 (UTC) FILETIME=[B4F88710:01C2925F] 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 Can somebody give me a pointer about FreeBSD support for the DWL-650 = PCMCIA card? Is it available in the latest stable release? Thanks, Balaji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 12:16:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7DAF37B401 for ; Fri, 22 Nov 2002 12:16:57 -0800 (PST) Received: from softweyr.com (softweyr.com [209.63.227.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32AA243EAF for ; Fri, 22 Nov 2002 12:16:57 -0800 (PST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 18FKEF-0004AZ-00; Fri, 22 Nov 2002 13:16:43 -0700 Message-ID: <3DDE90A8.1852C745@softweyr.com> Date: Fri, 22 Nov 2002 12:16:40 -0800 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Balaji.Prasad@nokia.com Cc: freebsd-net@freebsd.org Subject: Re: support for DWL-650 References: <59A36C4D2F9E7243BEB522274F72C3031FF202@mvebe001.americas.nokia.com> 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 Balaji.Prasad@nokia.com wrote: > > Can somebody give me a pointer about FreeBSD support for the DWL-650 PCMCIA > card? Is it available in the latest stable release? From /etc/defaults/pccard.conf: # D Link DWL-650 11Mbps WLAN Card card "D" "Link DWL-650 11Mbps WLAN Card" config auto "wi" ? 0x10000 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop wes@homer$ uname -a FreeBSD homer 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Oct 20 14:27:10 PDT 2002 root@homer:/usr/obj/usr/src/sys/HOMER i386 IIRC it's been in for more than a year. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 12:20:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E4A37B401 for ; Fri, 22 Nov 2002 12:20:23 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE0F43E4A for ; Fri, 22 Nov 2002 12:20:17 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <20021122202010001004p5jke>; Fri, 22 Nov 2002 20:20:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA15092; Fri, 22 Nov 2002 12:16:25 -0800 (PST) Date: Fri, 22 Nov 2002 12:16:23 -0800 (PST) From: Julian Elischer To: John Polstra Cc: net@freebsd.org, sam@errno.com Subject: Re: CFR: MFC of mtags In-Reply-To: <200211221645.gAMGjKPH082267@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org He does have a point I have binary 3rd party drivers I rely on. On Fri, 22 Nov 2002, John Polstra wrote: > In article <196301c291e9$56d25e70$52557f42@errno.com>, Sam Leffler > wrote: > > I want to commit the mbuf packet tag changes to stable. These > > changes replace the aux mbuf pointer in the mbuf with a list of > > "packet tags". This does not change the size of the mbuf structure > > but does affect any software that uses them (presently only KAME > > ipsec which has been patched to use packet tags instead). >=20 > I would strongly prefer that you not put this into the 4.x branch. > The project has a policy against incompatible ABI changes within the > -stable branch. If you do this MFC then those of us who rely on > third-party binary-only network drivers (such as the ET Inc. drivers, > upon which I and many others rely for network connectivity) will be > SOL. Changing the ABI within the branch is unfair to the vendors who > try to maintain drivers for FreeBSD, and it only discourages them from > trying to support our operating system. Let's just let the 4.x branch > live out the rest of its life span in a compatible way. >=20 > John > --=20 > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington = USA > "Disappointment is a good sign of basic intelligence." -- Ch=F6gyam Tr= ungpa >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 12:25:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29BB237B401 for ; Fri, 22 Nov 2002 12:25:15 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D46443E88 for ; Fri, 22 Nov 2002 12:25:14 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2002112220250900200t5mj0e>; Fri, 22 Nov 2002 20:25:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA15137; Fri, 22 Nov 2002 12:23:11 -0800 (PST) Date: Fri, 22 Nov 2002 12:23:10 -0800 (PST) From: Julian Elischer To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Packet Capturing on GWs but don't let them go out. 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 that is what divert(4) is for. On Fri, 22 Nov 2002, soheil soheil wrote: > Hi > I want to do packet capturing but as you know the pcap let the packet go out > and just put a copy on the buffer . > I just want to do a copy and don't let them go out . > just i want that all of the packet from the sockets that are created by me > travels through my server > > Packet ----- /* i don't want it to be forwarded */ |------> out > |----> buffer ---> my process --------send-- > THANX > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > 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 22 12:25:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4C9B37B401 for ; Fri, 22 Nov 2002 12:25:16 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427B743E3B for ; Fri, 22 Nov 2002 12:25:16 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2002112220251000200t5mj1e>; Fri, 22 Nov 2002 20:25:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA15139; Fri, 22 Nov 2002 12:24:09 -0800 (PST) Date: Fri, 22 Nov 2002 12:24:09 -0800 (PST) From: Julian Elischer To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Packet Capturing on GWs but don't let them go out. 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 ipfw "divert" or ipfw "fwd" could help you depending on what you want to do. On Fri, 22 Nov 2002, soheil soheil wrote: > Hi > I want to do packet capturing but as you know the pcap let the packet go out > and just put a copy on the buffer . > I just want to do a copy and don't let them go out . > just i want that all of the packet from the sockets that are created by me > travels through my server > > Packet ----- /* i don't want it to be forwarded */ |------> out > |----> buffer ---> my process --------send-- > > I want to do a transparent third party traffic > > THANX > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 22 13:22: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D833A37B401 for ; Fri, 22 Nov 2002 13:22:00 -0800 (PST) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id C559643EAA for ; Fri, 22 Nov 2002 13:21:56 -0800 (PST) (envelope-from misho@interbgc.com) Received: (qmail 37426 invoked by uid 1005); 22 Nov 2002 21:21:40 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.1.60/v4234. Clear:. Processed in 0.850673 secs); 22 Nov 2002 21:21:40 -0000 Received: from unknown (HELO misho) (217.9.231.229) by mail.interbgc.com with SMTP; 22 Nov 2002 21:21:39 -0000 Message-ID: <000f01c2926d$250d14a0$e5e709d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: Subject: ip_forward() and ipforward_rt Date: Fri, 22 Nov 2002 23:21:38 +0200 Organization: Inter-Bg-Com Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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 Hello, In -stable ip_input.c in_forward() we cache last used route in ipforward_rt. sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; if ((rt = ipforward_rt.ro_rt) == 0 || 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 = pkt_dst; rtalloc_ign(&ipforward_rt, RTF_PRCLONING); if (ipforward_rt.ro_rt == 0) { icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, dest, 0); return; } rt = ipforward_rt.ro_rt; } In my opinion, we should verify that ipforward_rt is not last reference to route and route is UP: sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; if ((rt = ipforward_rt.ro_rt) == 0 || pkt_dst.s_addr != sin->sin_addr.s_addr || rt->rt_refcnt <= 1 || (rt->rt_flags & RTF_UP) == 0) { .... } regards, Mihail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 13:30: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A7E437B401 for ; Fri, 22 Nov 2002 13:30:08 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F64143E9C for ; Fri, 22 Nov 2002 13:30:07 -0800 (PST) (envelope-from archie@dellroad.org) 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 NAA92811; Fri, 22 Nov 2002 13:22:06 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAMLM5OS072770; Fri, 22 Nov 2002 13:22:05 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAMLM5tj072769; Fri, 22 Nov 2002 13:22:05 -0800 (PST) From: Archie Cobbs Message-Id: <200211222122.gAMLM5tj072769@arch20m.dellroad.org> Subject: Re: mpd - vpn to windows server - very slow In-Reply-To: <5.1.0.14.2.20021122074425.00baf340@mail.cluttered.com> To: Jon Drukman Date: Fri, 22 Nov 2002 13:22:04 -0800 (PST) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Jon Drukman wrote: > i'm using mpd to connect to my work's VPN, running some form of windows vpn > server. unfortunately performance is really miserable. it seems to work > fine for tiny transmissions (1K or less) but anything over that stutters, > and if it's a big data dump (like scp'ing a 30K file or receiving email > with a 15K attachment) it just stalls completely. > > here is my mpd.conf: Try adding these lines to mpd.conf and see if they help: set iface mtu 1440 set ccp yes mpp-stateless > one thing i find interesting is it says "total bandwidth 64000" - i'm on You can ignore that, it doesn't mean anything in your case. -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 Fri Nov 22 13:45:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5413637B401 for ; Fri, 22 Nov 2002 13:45:12 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9839143EA3 for ; Fri, 22 Nov 2002 13:45:11 -0800 (PST) (envelope-from archie@dellroad.org) 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 NAA92877; Fri, 22 Nov 2002 13:30:07 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAMLU7OS072876; Fri, 22 Nov 2002 13:30:07 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAMLU7qn072875; Fri, 22 Nov 2002 13:30:07 -0800 (PST) From: Archie Cobbs Message-Id: <200211222130.gAMLU7qn072875@arch20m.dellroad.org> Subject: Re: ip_forward() and ipforward_rt In-Reply-To: <000f01c2926d$250d14a0$e5e709d9@interbgc.com> To: Mihail Balikov Date: Fri, 22 Nov 2002 13:30:07 -0800 (PST) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Mihail Balikov wrote: > In -stable ip_input.c in_forward() we cache last used route in ipforward_rt. > > sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; > if ((rt = ipforward_rt.ro_rt) == 0 || > 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 = pkt_dst; > > rtalloc_ign(&ipforward_rt, RTF_PRCLONING); > if (ipforward_rt.ro_rt == 0) { > icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, dest, > 0); > return; > } > rt = ipforward_rt.ro_rt; > } > > In my opinion, we should verify that ipforward_rt is not last reference to > route and route is UP: > > sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; > if ((rt = ipforward_rt.ro_rt) == 0 || > pkt_dst.s_addr != sin->sin_addr.s_addr || > rt->rt_refcnt <= 1 || > (rt->rt_flags & RTF_UP) == 0) { > .... > } Sounds like kern/10778... ? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/10778 -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 Fri Nov 22 14:11: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 479CC37B401 for ; Fri, 22 Nov 2002 14:11:01 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D2F543E6E for ; Fri, 22 Nov 2002 14:11:00 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gAMMAsvg031083 for ; Fri, 22 Nov 2002 17:10:54 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gAMMAsTn031082 for freebsd-net@freebsd.org; Fri, 22 Nov 2002 17:10:54 -0500 (EST) Date: Fri, 22 Nov 2002 17:10:54 -0500 From: Barney Wolff To: freebsd-net@freebsd.org Subject: [bugtraq-partner@seculution.de: [OpenBSD] [syslogd] false src-IP when logging to remote syslogd] Message-ID: <20021122221054.GA31045@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.25 (www . roaringpenguin . com / mimedefang) 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 Sounds familiar :) The question is whether any of the error codes discussed here would cause syslogd to rebind to the new address. ----- Forwarded message from Torsten Valentin ----- Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com X-Authentication-Warning: emax.hamcom.de: Host adsl-dyn3-226.heliweb.de [212.37.53.226] claimed to be server1.seculution.de From: "Torsten Valentin" To: Subject: [OpenBSD] [syslogd] false src-IP when logging to remote syslogd Date: Wed, 20 Nov 2002 16:36:43 +0100 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Scanned-By: MIMEDefang 2.25 (www . roaringpenguin . com / mimedefang) X-MIME-Autoconverted: from quoted-printable to 8bit by tp.databus.com id gAMM36vg031018 OpenBSD's syslogd (Tested on OpenBSD 2.9 - 3.2, i386 only) seems to have a bug that might lead to false information on a remote syslog-server. The problem can be reproduced by changing the machines IP using ifconfig and NOT rebooting the whole machine. Though the machine should not use the old IP anymore, packets from syslogd to the remote syslog-server (514/UDP) originate with the OLD source IP, the OpenBSD machine had before ifconfig. Though this is not a severe security issue which leads into a compromise of the system itself, it is an issue that leads into false information on the remote syslogd server, because the packets seem to originate from an address they are not really coming from. This might for example result in ID-systems reporting alarms from the wrong server or even worse not report alarms at all, depending on the configuration. The people at OpenBSD have been informed about this today via sendbug(1), but the Bug Tracking System seems to be disabled at the moment. T. ------------------------------ Torsten Valentin General Manager SecuLution GmbH Friedenstr. 3b 59199 B?nen Germany E-Mail: info@4ss.de http://www.4ss.de ----- End forwarded message ----- -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 15: 0:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D11337B401 for ; Fri, 22 Nov 2002 15:00:51 -0800 (PST) Received: from cluttered.com (w024.z064002058.sjc-ca.dsl.cnc.net [64.2.58.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D738F43EA3 for ; Fri, 22 Nov 2002 15:00:50 -0800 (PST) (envelope-from jsd@cluttered.com) Received: from orgasmotron.cluttered.com (jsd [10.10.10.3]) by cluttered.com (Postfix) with ESMTP id 9C96A1D104; Fri, 22 Nov 2002 15:00:53 -0800 (PST) Message-Id: <5.1.0.14.2.20021122145350.0154b008@10.10.10.1> X-Sender: jsd@10.10.10.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Nov 2002 15:00:51 -0800 To: Archie Cobbs From: Jon Drukman Subject: Re: mpd - vpn to windows server - very slow Cc: freebsd-net@FreeBSD.org In-Reply-To: <200211222122.gAMLM5tj072769@arch20m.dellroad.org> References: <5.1.0.14.2.20021122074425.00baf340@mail.cluttered.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 01:22 PM 11/22/2002, Archie Cobbs wrote: >Try adding these lines to mpd.conf and see if they help: > > set iface mtu 1440 > set ccp yes mpp-stateless i already had the second one in there, but i added the first and it has totally fixed the problem. thanks archie! -jsd- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 15:11:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A87F37B401 for ; Fri, 22 Nov 2002 15:11:30 -0800 (PST) Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3540143E3B for ; Fri, 22 Nov 2002 15:11:29 -0800 (PST) (envelope-from andrew@ugh.net.au) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 3902CA804; Sat, 23 Nov 2002 10:11:22 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 0EB81542D; Sat, 23 Nov 2002 10:11:22 +1100 (EST) Date: Sat, 23 Nov 2002 10:11:21 +1100 (EST) From: Andrew To: soheil soheil Cc: freebsd-net@freebsd.org Subject: Re: Packet Capturing on GWs but don't let them go out. In-Reply-To: Message-ID: <20021123101056.F30972-100000@starbug.ugh.net.au> X-WonK: *wibble* 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, 22 Nov 2002, soheil soheil wrote: > just i want that all of the packet from the sockets that are created by me > travels through my server Have you looked at ipfw divert? Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 15:12: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47FE237B401 for ; Fri, 22 Nov 2002 15:12:05 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D3A543EAF for ; Fri, 22 Nov 2002 15:11:58 -0800 (PST) (envelope-from archie@dellroad.org) 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 PAA93467; Fri, 22 Nov 2002 15:11:46 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gAMNBjOS073397; Fri, 22 Nov 2002 15:11:46 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gAMNBjIh073396; Fri, 22 Nov 2002 15:11:45 -0800 (PST) From: Archie Cobbs Message-Id: <200211222311.gAMNBjIh073396@arch20m.dellroad.org> Subject: Re: mpd - vpn to windows server - very slow In-Reply-To: <5.1.0.14.2.20021122145350.0154b008@10.10.10.1> To: Jon Drukman Date: Fri, 22 Nov 2002 15:11:45 -0800 (PST) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL99b (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 Jon Drukman wrote: > > set iface mtu 1440 > > set ccp yes mpp-stateless > > i already had the second one in there, but i added the first and it has > totally fixed the problem. thanks archie! The log trace you sent showed MPPE being negotiated *without* stateless mode. So, not sure what happened, but glad it's working now... -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 Fri Nov 22 16:28:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF42137B401 for ; Fri, 22 Nov 2002 16:28:11 -0800 (PST) Received: from hotmail.com (f7.law3.hotmail.com [209.185.241.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6C2243EAA for ; Fri, 22 Nov 2002 16:28:11 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 16:28:11 -0800 Received: from 207.183.39.145 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 23 Nov 2002 00:28:11 GMT X-Originating-IP: [207.183.39.145] From: "Vincent Goupil" To: freebsd-net@freebsd.org Subject: Packets dropped by FreeBSD Date: Sat, 23 Nov 2002 00:28:11 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2002 00:28:11.0609 (UTC) FILETIME=[34560C90:01C29287] 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 run FreeBSD 4.6.2 as a Firewall with ipfilter 3.4.27. I have 4 3C905. I currently have "network slowdown" during peak hours: packets are being dropped by the firewall, I get timeouts with mail and web, I ping interfaces but I get just some icmp replys. The cpu run idle. The firewall run sshd, jftpgw and snmpd. If I reboot, all go back to normal operation. During off hours, we don't have this problem. Any help ? _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 16:35:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C05B37B4C0 for ; Fri, 22 Nov 2002 16:35:43 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA46B43E88 for ; Fri, 22 Nov 2002 16:35:38 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b192.otenet.gr [212.205.244.200]) by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id gAN0ZRU6014564; Sat, 23 Nov 2002 02:35:28 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.6/8.12.6) with ESMTP id gAN0ZRA5063514; Sat, 23 Nov 2002 02:35:27 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by gothmog.gr (8.12.6/8.12.6/Submit) id gAN0ZR12063513; Sat, 23 Nov 2002 02:35:27 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 23 Nov 2002 02:35:27 +0200 From: Giorgos Keramidas To: Vincent Goupil Cc: freebsd-net@FreeBSD.ORG Subject: Re: Packets dropped by FreeBSD Message-ID: <20021123003527.GB60388@gothmog.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-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 On 2002-11-23 00:28, Vincent Goupil wrote: > I run FreeBSD 4.6.2 as a Firewall with ipfilter 3.4.27. > I have 4 3C905. I currently have "network slowdown" during peak hours: > packets are being dropped by the firewall, I get timeouts with mail and > web, I ping interfaces but I get just some icmp replys. The cpu run idle. > > The firewall run sshd, jftpgw and snmpd. > > If I reboot, all go back to normal operation. > During off hours, we don't have this problem. Any hints about mbuf exchaustion in the output of "netstat -m" ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 22 19:46:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B7C37B401; Fri, 22 Nov 2002 19:46:30 -0800 (PST) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BBDA43EAF; Fri, 22 Nov 2002 19:46:30 -0800 (PST) (envelope-from brunner@nic-naa.net) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id gAN3lBjU001226; Fri, 22 Nov 2002 22:47:11 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200211230347.gAN3lBjU001226@nic-naa.net> To: freebsd-net@FreeBSD.ORG Cc: freebsd-isp@FreeBSD.ORG Subject: dial-in recommendations please MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1224.1038023231.1@nic-naa.net> Date: Fri, 22 Nov 2002 22:47:11 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm looking at the isp-in-my-basement problem. The dial-in problem is one I haven't solved-for in over ten years. I'd like to pick the brains of anyone who's started a small isp recently. Thanks in advance, Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 23 6: 4:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02EE237B401; Sat, 23 Nov 2002 06:04:26 -0800 (PST) Received: from kira.epconline.net (kira.epconline.net [207.206.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E86F43E91; Sat, 23 Nov 2002 06:04:25 -0800 (PST) (envelope-from carock@epcusa.com) Received: from localhost (carock@localhost) by kira.epconline.net (8.11.4/8.11.4) with ESMTP id gANE4Cq49926; Sat, 23 Nov 2002 08:04:12 -0600 (CST) Date: Sat, 23 Nov 2002 08:04:12 -0600 (CST) From: Chuck Rock X-Sender: carock@kira.epconline.net To: Eric Brunner-Williams in Portland Maine Cc: freebsd-net@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: dial-in recommendations please In-Reply-To: <200211230347.gAN3lBjU001226@nic-naa.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 I just set up a rural dial-up pool in the basement of one of our employees. I will try to help you if I can. Chuck On Fri, 22 Nov 2002, Eric Brunner-Williams in Portland Maine wrote: > Hi, > > I'm looking at the isp-in-my-basement problem. > > The dial-in problem is one I haven't solved-for in over ten years. > > I'd like to pick the brains of anyone who's started a small isp > recently. > > Thanks in advance, > Eric > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" 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 23 11:31:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4302037B401 for ; Sat, 23 Nov 2002 11:31:25 -0800 (PST) Received: from hotmail.com (f126.law3.hotmail.com [209.185.241.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 036E243E91 for ; Sat, 23 Nov 2002 11:31:25 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Nov 2002 11:31:24 -0800 Received: from 206.172.187.22 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 23 Nov 2002 19:31:24 GMT X-Originating-IP: [206.172.187.22] From: "Vincent Goupil" To: freebsd-net@FreeBSD.ORG Cc: keramida@ceid.upatras.gr Subject: Re: Packets dropped by FreeBSD Date: Sat, 23 Nov 2002 19:31:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Nov 2002 19:31:24.0927 (UTC) FILETIME=[E923C0F0:01C29326] 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 Currently, this is the output. I don't have one when it happen. I will try to provide one. [root@wally ~] netstat -m 514/608/6016 mbufs in use (current/peak/max): 514 mbufs allocated to data 512/584/1504 mbuf clusters in use (current/peak/max) 1320 Kbytes allocated to network (29% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines [root@wally ~] Is this the mb_map ? >On 2002-11-23 00:28, Vincent Goupil wrote: > > I run FreeBSD 4.6.2 as a Firewall with ipfilter 3.4.27. > > I have 4 3C905. I currently have "network slowdown" during peak hours: > > packets are being dropped by the firewall, I get timeouts with mail and > > web, I ping interfaces but I get just some icmp replys. The cpu run >idle. > > > > The firewall run sshd, jftpgw and snmpd. > > > > If I reboot, all go back to normal operation. > > During off hours, we don't have this problem. > >Any hints about mbuf exchaustion in the output of "netstat -m" ? > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 23 12:17:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6ECD37B401 for ; Sat, 23 Nov 2002 12:17:55 -0800 (PST) Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6964843E88 for ; Sat, 23 Nov 2002 12:17:54 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto3.wanadoo.fr (6.5.007) id 3DDA12BC00320796 for freebsd-net@freebsd.org; Sat, 23 Nov 2002 21:17:53 +0100 Received: from there (80.11.204.20) by mel-rta7.wanadoo.fr (6.5.007) id 3DD3B25600551D5F for freebsd-net@freebsd.org; Sat, 23 Nov 2002 21:17:53 +0100 Message-ID: <3DD3B25600551D5F@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: freebsd-net@freebsd.org Subject: a ng_pppoe bug ? Date: Sat, 23 Nov 2002 21:35:24 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am wondering if it is a bug of ng_pppoe. The objects that have the structure sess_neg hold a pointer on the last sent packet. struct sess_neg { struct mbuf *m; /* holds cluster with last sent packet */ union packet *pkt; /* points within the above cluster */ (...) Then when a packet is made, the same mbuf is always reused. However, m_data might have been changed by another node or a driver (for example, there are some pieces of code that translate m_data: m_data += n). It means that the second time a pppoe packet is sent during the negocation, a part of the ethernet header is missing. It think that the problem is related to m_copypacket that is used within ng_ppppoe in order to keep always the same mbuf. Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 23 13:47:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F20537B404 for ; Sat, 23 Nov 2002 13:47:58 -0800 (PST) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A93B43E9C for ; Sat, 23 Nov 2002 13:47:55 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b184.otenet.gr [212.205.244.192]) by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id gANLlqU6018584; Sat, 23 Nov 2002 23:47:53 +0200 (EET) Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.6/8.12.6) with ESMTP id gANLlq8s082889; Sat, 23 Nov 2002 23:47:52 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by gothmog.gr (8.12.6/8.12.6/Submit) id gANLlq6t082880; Sat, 23 Nov 2002 23:47:52 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 23 Nov 2002 23:47:52 +0200 From: Giorgos Keramidas To: Vincent Goupil Cc: freebsd-net@FreeBSD.ORG Subject: Re: Packets dropped by FreeBSD Message-ID: <20021123214752.GA72985@gothmog.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-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 On 2002-11-23 19:31, Vincent Goupil wrote: > Currently, this is the output. I don't have one when it happen. I will > try to provide one. > > [root@wally ~] netstat -m > 514/608/6016 mbufs in use (current/peak/max): > 514 mbufs allocated to data > 512/584/1504 mbuf clusters in use (current/peak/max) > 1320 Kbytes allocated to network (29% of mb_map in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > [root@wally ~] > > Is this the mb_map ? > > > > >Any hints about mbuf exchaustion in the output of "netstat -m" ? > > It looks ok :/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 23 20:29:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4349A37B401 for ; Sat, 23 Nov 2002 20:29:39 -0800 (PST) Received: from hotmail.com (f137.law3.hotmail.com [209.185.241.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C174B43E6E for ; Sat, 23 Nov 2002 20:29:38 -0800 (PST) (envelope-from spoug@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Nov 2002 20:29:38 -0800 Received: from 207.183.39.145 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 24 Nov 2002 04:29:38 GMT X-Originating-IP: [207.183.39.145] From: "Vincent Goupil" To: freebsd-net@FreeBSD.ORG Subject: Re: Packets dropped by FreeBSD Date: Sun, 24 Nov 2002 04:29:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Nov 2002 04:29:38.0738 (UTC) FILETIME=[19C04120:01C29372] 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 could be wrong ? Output before the reboot tcp: 3358 packets sent 1859 data packets (330166 bytes) 16 data packets (20280 bytes) retransmitted 0 resends initiated by MTU discovery 1476 ack-only packets (351 delayed) 0 URG only packets 0 window probe packets 1 window update packet 6 control packets 3329 packets received 1425 acks (for 325868 bytes) 110 duplicate acks 0 acks for unsent data 2827 packets (127264 bytes) received in-sequence 3 completely duplicate packets (1672 bytes) 0 old duplicate packets 4 packets with some dup. data (1320 bytes duped) 219 out-of-order packets (20032 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 2 connection requests 4 connection accepts 3 bad connection attempts 0 listen queue overflows 6 connections established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 1024 segments updated rtt (of 1035 attempts) 1 retransmit timeout 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 2 correct ACK header predictions 1489 correct data packet header predictions 4 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 4 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received udp: 7090 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 132 dropped due to no socket 3511 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 3447 delivered 1999 datagrams output ip: 422282 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 11227 packets for this host 0 packets for unknown/unsupported protocol 408471 packets forwarded (0 packets fast forwarded) 108 packets not forwardable 0 packets received for unknown multicast group 478 redirects sent 6971 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 240 calls to icmp_error 0 errors not generated 'cuz old message was icmp Output histogram: echo reply: 1 destination unreachable: 240 routing redirect: 478 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 806 echo: 1 1 message response generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 membership reports sent 599/656/6016 mbufs in use (current/peak/max): 599 mbufs allocated to data 512/654/1504 mbuf clusters in use (current/peak/max) 1472 Kbytes allocated to network (32% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines [root@wally ~] I increased default values to theses ones: kern.ipc.somaxconn=1024 (sysctl) kern.maxusers=128 (loader.conf) kern.ipc.nmbclusters=8192 (loader.conf) tcp: 1963 packets sent 1135 data packets (111983 bytes) 15 data packets (21344 bytes) retransmitted 0 resends initiated by MTU discovery 813 ack-only packets (170 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 1860 packets received 750 acks (for 107768 bytes) 110 duplicate acks 0 acks for unsent data 1522 packets (68055 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 118 out-of-order packets (8800 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 1 connection established (including accepts) 0 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 489 segments updated rtt (of 491 attempts) 3 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 883 correct data packet header predictions 1 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received udp: 140 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 50 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 90 delivered 68 datagrams output ip: 2329 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 2069 packets for this host 0 packets for unknown/unsupported protocol 241 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 2172 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated 'cuz old message was icmp Output histogram: echo reply: 58 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 10 echo: 58 58 message responses generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 membership reports sent 600/672/6016 mbufs in use (current/peak/max): 600 mbufs allocated to data 512/564/1504 mbuf clusters in use (current/peak/max) 1296 Kbytes allocated to network (28% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines [root@wally /usr/src/sys/i386/conf] Could it help ? > > Currently, this is the output. I don't have one when it happen. I will > > try to provide one. > > > > [root@wally ~] netstat -m > > 514/608/6016 mbufs in use (current/peak/max): > > 514 mbufs allocated to data > > 512/584/1504 mbuf clusters in use (current/peak/max) > > 1320 Kbytes allocated to network (29% of mb_map in use) > > 0 requests for memory denied > > 0 requests for memory delayed > > 0 calls to protocol drain routines > > [root@wally ~] > > > > Is this the mb_map ? > > > > > > > >Any hints about mbuf exchaustion in the output of "netstat -m" ? > > > > >It looks ok :/ > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message