From owner-freebsd-net Sun Jan 28 9:37: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by hub.freebsd.org (Postfix) with ESMTP id 1841B37B698 for ; Sun, 28 Jan 2001 09:36:37 -0800 (PST) Received: from fwd01.sul.t-online.com by mailout01.sul.t-online.com with smtp id 14Mvkg-0003zG-07; Sun, 28 Jan 2001 18:36:34 +0100 Received: from ramses.local (320080844193-0001@[217.2.184.125]) by fmrl01.sul.t-online.com with esmtp id 14MvkL-07I4P2C; Sun, 28 Jan 2001 18:36:13 +0100 Received: from haribeau by ramses.local with local (Exim 3.12 #1 (Debian)) id 14MwhC-0000ql-00 for ; Sun, 28 Jan 2001 19:37:02 +0100 Date: Sun, 28 Jan 2001 19:37:02 +0100 From: Clemens Hermann To: BSD NET-List Subject: ip-accounting Message-ID: <20010128193701.A3139@ramses.local> Mail-Followup-To: Clemens Hermann , BSD NET-List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Mailer: Mutt 1.2.5i (Linux 2.2.17 i586) X-Sender: 320080844193-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, are there any recommandationions how to get IP-accounting to work on FreeBSD? I have switched from ipf to ipfw so now I need a new way do keep track of the IP-traffic passing my machine. I have a machine with 30 IP-aliases. The least thing I need is monthly summary of the full amount of IP-Traffic that passed my (one) NIC. If possible it would be great to have it split by the different IPs. Furthermore if some scripts existed that could create HTML reports that would be great but not necessary. The way ipf and ipacct do the job was pretty cool so if anything similar was possible with ipfw or if there existed a tool to do the accounting on its own with the desired results I would appreciate it a lot to know. thanks in advance /ch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 10:17:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from atro.pine.nl (atro.pine.nl [213.156.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 5625937B402 for ; Sun, 28 Jan 2001 10:17:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by atro.pine.nl (8.11.1/8.11.1) with ESMTP id f0SIHZn25756; Sun, 28 Jan 2001 19:17:35 +0100 (MET) Date: Sun, 28 Jan 2001 19:17:35 +0100 (MET) From: Mark Lastdrager To: Clemens Hermann Cc: BSD NET-List Subject: Re: ip-accounting In-Reply-To: <20010128193701.A3139@ramses.local> Message-ID: X-NCC-RegID: nl.pine MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At Sun, 28 Jan 2001, owner-freebsd-net@FreeBSD.ORG wrote: >Hi, > >are there any recommandationions how to get IP-accounting to work on >FreeBSD? I have switched from ipf to ipfw so now I need a new way do >keep track of the IP-traffic passing my machine. >I have a machine with 30 IP-aliases. >The least thing I need is monthly summary of the full amount of >IP-Traffic that passed my (one) NIC. If possible it would be great to >have it split by the different IPs. Furthermore if some scripts existed >that could create HTML reports that would be great but not necessary. >The way ipf and ipacct do the job was pretty cool so if anything similar >was possible with ipfw or if there existed a tool to do the accounting >on its own with the desired results I would appreciate it a lot to know. Have a look at http://www.ipmeter.com/. Seems to be fully supported on FreeBSD. I haven't used it, but the specs look good. Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: YOU HAVE AN I/O ERROR -> Incompetent Operator error To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 18:53: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from anakin.jestec.com (unknown [216.218.200.104]) by hub.freebsd.org (Postfix) with ESMTP id 342B137B400 for ; Sun, 28 Jan 2001 18:52:51 -0800 (PST) Received: from twopimped (cc502667-a.catv1.md.home.com [24.9.158.2]) by anakin.jestec.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Sun, 28 Jan 2001 18:55:21 -0800 From: "G. Jason Middleton" To: "Bosko Milekic" Cc: Subject: RE: no buffer space available (outcome of netstat -m) Date: Sun, 28 Jan 2001 21:55:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000f01c088f9$db5c08d0$1f90c918@jehovah> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The original problem was an still is > ping: sendto: no buffer space avaialble. I was able to reproduce the error today while telneting in to the box. I was ftping through telnet and i did an "ls" and it got halfway through a directory listing and crapped out on my. the box was no where to be found on the network/internet. OK i did the netstat -m and got he following output 298/352/4096 mbufs in use (current/peak/max) 170 mbufs allocated to data 128 mbufs allocated to packets headers 41/160/1024 mbuf clusters in use (current/peak/max) 408 kbytes allocated to network (13% of mb-map in use) 0 requests for mem denied 0 requests for mem delayed 0 calls to protocol drain routines what next? Jason Does this happen regularly? Check `netstat -m' on the machine (you'll probably have to do it from the console) when this is happening. If it happens regularly, does anything specific happen that "helps reproduce it?" What version of FreeBSD are you running? -Bosko G. Jason Middleton wrote: > I have a problem. > I can telnet into my bsd box from the net and after a while it will just not > let me in. It just drops right off the face of the earth. So when i > actually try to ping something from the box after this happens i get an > error as follows: > > ping: sendto: no buffer space avaialble. > > > when i reboot everything works like it should. > > Got any ideas? > > Regards, > > G. Jason Middleton > University of Maryland Baltimore County To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 18:55:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from volatile.chemikals.org (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id C798837B400 for ; Sun, 28 Jan 2001 18:55:13 -0800 (PST) Received: (from morganw@localhost) by volatile.chemikals.org (8.11.1/8.11.1) id f0T2t2G13978; Sun, 28 Jan 2001 21:55:02 -0500 (EST) (envelope-from morganw) Date: Sun, 28 Jan 2001 21:55:02 -0500 (EST) From: Wesley Morgan To: "G. Jason Middleton" Cc: Bosko Milekic , Subject: RE: no buffer space available (outcome of netstat -m) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When this happened to me once before, I ifconfig'd the interface down and back up... Viola, working interface. Never figured out what caused it though :) On Sun, 28 Jan 2001, G. Jason Middleton wrote: > The original problem was an still is > ping: sendto: no buffer space > avaialble. > > I was able to reproduce the error today while telneting in to the box. I > was ftping through telnet and i did an "ls" and it got halfway through a > directory listing and crapped out on my. the box was no where to be found > on the network/internet. > > OK i did the netstat -m and got he following output > > 298/352/4096 mbufs in use (current/peak/max) > 170 mbufs allocated to data > 128 mbufs allocated to packets headers > 41/160/1024 mbuf clusters in use (current/peak/max) > 408 kbytes allocated to network (13% of mb-map in use) > 0 requests for mem denied > 0 requests for mem delayed > 0 calls to protocol drain routines > > > what next? > > Jason > > > Does this happen regularly? Check `netstat -m' on the machine (you'll > probably have to do it from the console) when this is happening. > If it happens regularly, does anything specific happen that "helps > reproduce it?" > What version of FreeBSD are you running? > > -Bosko > > G. Jason Middleton wrote: > > > I have a problem. > > I can telnet into my bsd box from the net and after a while it will > just not > > let me in. It just drops right off the face of the earth. So when i > > actually try to ping something from the box after this happens i get > an > > error as follows: > > > > ping: sendto: no buffer space avaialble. > > > > > > when i reboot everything works like it should. > > > > Got any ideas? > > > > Regards, > > > > G. Jason Middleton > > University of Maryland Baltimore County > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ morganw@chemikals.org _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 20:11:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id F1AB637B699; Sun, 28 Jan 2001 20:11:10 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7WOYL03.4RH; Sun, 28 Jan 2001 23:11:09 -0500 Message-ID: <003e01c089a9$c4287d00$1f90c918@jehovah> From: "Bosko Milekic" To: "Wesley Morgan" , "G. Jason Middleton" , Cc: References: Subject: Re: no buffer space available (outcome of netstat -m) Date: Sun, 28 Jan 2001 23:12:59 -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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What device are you using? What is the interface you ifconfig'd down and back up? Jason, can you also contribute? Boris, if you're reading this, if you see that both these gentlemen have the same interface, perhaps we have a winner? I've been unable to find the problem as of yet (frankly, I've had little time to look too deeply). Regards, Bosko. Wesley Morgan wrote: > When this happened to me once before, I ifconfig'd the interface down and > back up... Viola, working interface. Never figured out what caused it > though :) > > On Sun, 28 Jan 2001, G. Jason Middleton wrote: > > > The original problem was an still is > ping: sendto: no buffer space > > avaialble. > > > > I was able to reproduce the error today while telneting in to the box. I > > was ftping through telnet and i did an "ls" and it got halfway through a > > directory listing and crapped out on my. the box was no where to be found > > on the network/internet. > > > > OK i did the netstat -m and got he following output > > > > 298/352/4096 mbufs in use (current/peak/max) > > 170 mbufs allocated to data > > 128 mbufs allocated to packets headers > > 41/160/1024 mbuf clusters in use (current/peak/max) > > 408 kbytes allocated to network (13% of mb-map in use) > > 0 requests for mem denied > > 0 requests for mem delayed > > 0 calls to protocol drain routines > > > > > > what next? > > > > Jason > > > > > > Does this happen regularly? Check `netstat -m' on the machine (you'll > > probably have to do it from the console) when this is happening. > > If it happens regularly, does anything specific happen that "helps > > reproduce it?" > > What version of FreeBSD are you running? > > > > -Bosko > > > > G. Jason Middleton wrote: > > > > > I have a problem. > > > I can telnet into my bsd box from the net and after a while it will > > just not > > > let me in. It just drops right off the face of the earth. So when i > > > actually try to ping something from the box after this happens i get > > an > > > error as follows: > > > > > > ping: sendto: no buffer space avaialble. > > > > > > > > > when i reboot everything works like it should. > > > > > > Got any ideas? > > > > > > Regards, > > > > > > G. Jason Middleton > > > University of Maryland Baltimore County > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > -- > _ __ ___ ____ ___ ___ ___ > Wesley N Morgan _ __ ___ | _ ) __| \ > morganw@chemikals.org _ __ | _ \._ \ |) | > FreeBSD: The Power To Serve _ |___/___/___/ > 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > > > 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 Jan 28 20:44:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id A5FDD37B400 for ; Sun, 28 Jan 2001 20:44:28 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id C5288286FC; Mon, 29 Jan 2001 10:44:20 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id BB1F0286FB; Mon, 29 Jan 2001 10:44:20 +0600 (ALMT) Date: Mon, 29 Jan 2001 10:44:20 +0600 (ALMT) From: Boris Popov X-Sender: bp@lion.butya.kz To: Bosko Milekic Cc: Wesley Morgan , "G. Jason Middleton" , freebsd-net@FreeBSD.ORG Subject: Re: no buffer space available (outcome of netstat -m) In-Reply-To: <003e01c089a9$c4287d00$1f90c918@jehovah> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 28 Jan 2001, Bosko Milekic wrote: > Boris, if you're reading this, if you see that both these > gentlemen have the same interface, perhaps we have a winner? I've been > unable to find the problem as of yet (frankly, I've had little time to > look too deeply). This a is plain Realtek8029 with ed driver. As I've already mentioned to Bosko - it is enough to ping this box from another machine to initiate buffers cleanup. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 20:55: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from anakin.jestec.com (unknown [216.218.200.104]) by hub.freebsd.org (Postfix) with ESMTP id 0483F37B404 for ; Sun, 28 Jan 2001 20:54:42 -0800 (PST) Received: from twopimped (cc502667-a.catv1.md.home.com [24.9.158.2]) by anakin.jestec.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com for ; Sun, 28 Jan 2001 20:57:12 -0800 From: "G. Jason Middleton" To: "Freebsd-Net" Subject: auto renewing IP while telnetting frmo the internet Date: Sun, 28 Jan 2001 23:56:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have another bsdbox that is getting its IP through a Windows 2000 machine that is running DHCP. I have it set up so i can telnet to the 2000 machines IPand it will let me hit the bsdbox from the internet. For example: boot the bsdbox up and it gets 192.168.0.20. then i telnet to it from the internet through the 2000 box. OK no problems here. However, after about 2 mintues or so the telent connection drops. SO i go to the console on the bsdbox and ifconfig it only to find the damn thing has renewed it's IP! It stil works on the network and everything! Just has a new IP. THis only happens when i telnet to it from the internet. If i telnet to it in the local network it does not renew its IP. Any ideas? or similiar problems? G. Jason Middleton University of Maryland Baltimore County To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jan 28 22:37: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from anakin.jestec.com (unknown [216.218.200.104]) by hub.freebsd.org (Postfix) with ESMTP id 085B137B400 for ; Sun, 28 Jan 2001 22:36:42 -0800 (PST) Received: from twopimped (cc502667-a.catv1.md.home.com [24.9.158.2]) by anakin.jestec.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Sun, 28 Jan 2001 22:39:12 -0800 From: "G. Jason Middleton" To: "Bosko Milekic" Cc: "Freebsd-Net" Subject: RE: no buffer space available (outcome of netstat -m) Date: Mon, 29 Jan 2001 01:38:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <003e01c089a9$c4287d00$1f90c918@jehovah> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have reproduced the problem and ifconfig'd it down then back up and it came back on the network just fine. Where does that leave us? I have yet to add the NMBCLUSTERS to the kernel because i do not know how to recompile the damn thing yet! Jason -----Original Message----- From: Bosko Milekic [mailto:bmilekic@technokratis.com] Sent: Sunday, January 28, 2001 11:13 PM To: Wesley Morgan; G. Jason Middleton; bp@freebsd.org Cc: freebsd-net@FreeBSD.ORG Subject: Re: no buffer space available (outcome of netstat -m) What device are you using? What is the interface you ifconfig'd down and back up? Jason, can you also contribute? Boris, if you're reading this, if you see that both these gentlemen have the same interface, perhaps we have a winner? I've been unable to find the problem as of yet (frankly, I've had little time to look too deeply). Regards, Bosko. Wesley Morgan wrote: > When this happened to me once before, I ifconfig'd the interface down and > back up... Viola, working interface. Never figured out what caused it > though :) > > On Sun, 28 Jan 2001, G. Jason Middleton wrote: > > > The original problem was an still is > ping: sendto: no buffer space > > avaialble. > > > > I was able to reproduce the error today while telneting in to the box. I > > was ftping through telnet and i did an "ls" and it got halfway through a > > directory listing and crapped out on my. the box was no where to be found > > on the network/internet. > > > > OK i did the netstat -m and got he following output > > > > 298/352/4096 mbufs in use (current/peak/max) > > 170 mbufs allocated to data > > 128 mbufs allocated to packets headers > > 41/160/1024 mbuf clusters in use (current/peak/max) > > 408 kbytes allocated to network (13% of mb-map in use) > > 0 requests for mem denied > > 0 requests for mem delayed > > 0 calls to protocol drain routines > > > > > > what next? > > > > Jason > > > > > > Does this happen regularly? Check `netstat -m' on the machine (you'll > > probably have to do it from the console) when this is happening. > > If it happens regularly, does anything specific happen that "helps > > reproduce it?" > > What version of FreeBSD are you running? > > > > -Bosko > > > > G. Jason Middleton wrote: > > > > > I have a problem. > > > I can telnet into my bsd box from the net and after a while it will > > just not > > > let me in. It just drops right off the face of the earth. So when i > > > actually try to ping something from the box after this happens i get > > an > > > error as follows: > > > > > > ping: sendto: no buffer space avaialble. > > > > > > > > > when i reboot everything works like it should. > > > > > > Got any ideas? > > > > > > Regards, > > > > > > G. Jason Middleton > > > University of Maryland Baltimore County > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > -- > _ __ ___ ____ ___ ___ ___ > Wesley N Morgan _ __ ___ | _ ) __| \ > morganw@chemikals.org _ __ | _ \._ \ |) | > FreeBSD: The Power To Serve _ |___/___/___/ > 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 1: 0:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5F39A37B6E3; Mon, 29 Jan 2001 00:59:52 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f0T8xQu33835; Mon, 29 Jan 2001 10:59:26 +0200 (EET) (envelope-from ru) Date: Mon, 29 Jan 2001 10:59:26 +0200 From: Ruslan Ermilov To: Alwyn Goodloe Cc: net@FreeBSD.ORG, Archie Cobbs Subject: Re: ipfw message Message-ID: <20010129105926.B27558@sunbay.com> Mail-Followup-To: Alwyn Goodloe , net@FreeBSD.ORG, Archie Cobbs References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from agoodloe@gradient.cis.upenn.edu on Sat, Jan 27, 2001 at 10:45:26PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Redirected to -net] On Sat, Jan 27, 2001 at 10:45:26PM -0500, Alwyn Goodloe wrote: > > This is my last fragmentation question I swear :-) > > When diverting udp packets which are larger than MTU(1500) ipfw seems to > divert the first and reject the second. > Here is tcpdump of the packets: > > > 23:41:05.670408 192.168.1.3.1128 > 192.168.5.12.3322: udp 1474 (frag 4127:1480@ > 0+) > 23:41:05.670420 192.168.1.3 > 192.168.5.12: (frag 4127:2@1480) > > Below is the log from ipfw. > > Jan 26 23:40:56 richmond /kernel: ipfw: 60000 Divert 4422 UDP 192.168.1.3:1128 192.168.5.12:3322 in via xl0 > Jan 26 23:40:56 richmond /kernel: ipfw: -1 Refuse UDP 192.168.1.3 192.168.5.12 in via xl0 Fragment = 185 > > > > Now i know that ipfw will drop tcp packets of length 1 is something like that > what's going on here? > > Well if anyone can let me in on the meaning of the rejection message it > would be helpful. > Does the problem you experience has something similar with the below? I think I have found a bug here. When the ``divert foo ... udp ...'' rule has no destination port specification, everything works as documented, i.e. all fragments are reassembled and get diverted to the divert(4) to port ``foo''. If I add the destination port specification, only the first (offset zero) fragment gets diverted: 1) ``open'' type firewall with ``divert'' rules without port spec: 00002 divert 2345 log udp from 194.220.45.65 to 194.220.45.115 00002 deny log ip from any to any frag 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 deny ip from any to any Jan 29 10:51:28 perl /kernel: ipfw: 2 Divert 2345 UDP 194.220.45.65:2212 194.220.45.115:2222 in via rl0 Jan 29 10:51:28 perl /kernel: ipfw: 2 Divert 2345 UDP 194.220.45.65 194.220.45.115 in via rl0 Fragment = 185 2) the same as above except with port spec: 00002 divert 2345 log udp from 194.220.45.65 to 194.220.45.115 2222 00002 deny log ip from any to any frag 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 deny ip from any to any Jan 29 10:53:08 perl /kernel: ipfw: 2 Divert 2345 UDP 194.220.45.65:2303 194.220.45.115:2222 in via rl0 Jan 29 10:53:08 perl /kernel: ipfw: 2 Deny UDP 194.220.45.65 194.220.45.115 in via rl0 Fragment = 185 -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 4: 4:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from easynet-gw.netvalue.fr (unknown [212.180.121.161]) by hub.freebsd.org (Postfix) with ESMTP id 3943837B400; Mon, 29 Jan 2001 04:03:54 -0800 (PST) Received: from mail.netvalue.fr (unknown [192.168.1.13]) by easynet-gw.netvalue.fr (Postfix) with ESMTP id 1BBF38C29; Mon, 29 Jan 2001 13:05:58 +0100 (CET) Received: from mail-hk.netvalue.fr ([192.168.100.13]) by mail.netvalue.fr (Netscape Messaging Server 3.6) with ESMTP id AAA6114; Mon, 29 Jan 2001 13:03:43 +0100 Received: from erwan.netvalue.fr ([192.168.100.100]) by mail-hk.netvalue.fr (Netscape Messaging Server 4.15) with ESMTP id G7XATO00.GH8; Mon, 29 Jan 2001 20:03:24 +0800 Received: from netvalue.com (localhost [127.0.0.1]) by erwan.netvalue.fr (Postfix) with ESMTP id 7A10E18D7; Mon, 29 Jan 2001 20:03:47 +0800 (HKT) Message-ID: <3A755C23.AE8D79E1@netvalue.com> Date: Mon, 29 Jan 2001 20:03:47 +0800 From: Erwan Arzur Organization: NetValue Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, fr-FR MIME-Version: 1.0 To: Roman Le Houelleur Cc: freebsd-ipfw , freebsd-net Subject: Re: bandwidth analyser References: <3A6C7FD0.7E2ABD65@IPricot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Roman Le Houelleur wrote: > > hi, > > I use FreeBSD 4.2 stable + bridge + dummynet + ipfw. > I would like to calculate the bandwidth of each > authorized IP source flowing through the bridge from a > user program. > As this bandwidth calculation should be done very often > (10 to 20 times per second) I first tried to use the if_data > structure from sysctl. But it seems the packet counter is > only incremented for packets destinated to the specified > interface, and moreover I wouldn't be able to separate the > incoming flows depending on their source addresses. > > Anybody has an advice on the best way to achieve this > calculation ? what about the counter capabilities of ipfw ? > > Moreover, concerning the bridge, I was wondering if > there is a way not to put a third interface in promiscous > mode. As this third nic exists only for management purposes > I don't want it to participate to the bridge in any way. > > Thanks, > Never did this, but without the 10-20 times/sec requirement (don't do this 10 times/sec !), you could easily hack something like this : * add some rules with actions * write a little perl script that will output the value of the counter for the given rule (exec'ing ipfw show) * associate it with your choice of mrtg or RDDTool and you've got your bandwidth analyser with nice graphs and so forth ... There is something similar done for ipfilter in some mrtg contrib package, if i remember well ... Another solution would be to use /usr/ports/net/snmpd with the contributed ipfw MIB ... Why this 10 times/sec requirement ? Load balancing ? -- Erwan Arzur NetValue ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 4:32:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from news.lucky.net (news.lucky.net [193.193.193.102]) by hub.freebsd.org (Postfix) with ESMTP id B3B1F37B404 for ; Mon, 29 Jan 2001 04:32:17 -0800 (PST) Received: (from mail@localhost) by news.lucky.net (8.Who.Cares/8.Who.Cares) id OMK17037 for freebsd-net@freebsd.org; Mon, 29 Jan 2001 14:32:16 +0200 (envelope-from news@news.ntu-kpi.kiev.ua) From: "Andrey Simonenko" To: freebsd-net@freebsd.org Subject: Re: ip-accounting Date: Mon, 29 Jan 2001 13:32:00 +0300 Organization: NTUU "KPI" Message-ID: <953kce$2q6k$1@igloo.uran.net.ua> References: <20010128193701.A3139@ramses.local> X-Trace: igloo.uran.net.ua 980767950 92372 10.18.54.109 (29 Jan 2001 11:32:29 GMT) X-Complaints-To: newsmaster@news.ntu-kpi.kiev.ua X-Newsreader: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Try to use IP Accountoing Daemon: http://www.simon.org.ua/ipa/ You also can install it from ports, but on its web site version 1.0.3 is availble. Clemens Hermann wrote in message news:20010128193701.A3139@ramses.local... > Hi, > > are there any recommandationions how to get IP-accounting to work on > FreeBSD? I have switched from ipf to ipfw so now I need a new way do > keep track of the IP-traffic passing my machine. > I have a machine with 30 IP-aliases. > The least thing I need is monthly summary of the full amount of > IP-Traffic that passed my (one) NIC. If possible it would be great to > have it split by the different IPs. Furthermore if some scripts existed > that could create HTML reports that would be great but not necessary. > The way ipf and ipacct do the job was pretty cool so if anything similar > was possible with ipfw or if there existed a tool to do the accounting > on its own with the desired results I would appreciate it a lot to know. > > thanks in advance > > /ch > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 8:15:47 2001 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 258A137B69C for ; Mon, 29 Jan 2001 08:15:29 -0800 (PST) Received: from hera.drwilco.net (10dyn120.dh.casema.net [212.64.31.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA8576E2B71 for ; Mon, 29 Jan 2001 08:14:33 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0SIePb02097; Sun, 28 Jan 2001 19:40:26 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010128191033.00b4c930@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 28 Jan 2001 19:18:56 +0100 To: Clemens Hermann , BSD NET-List From: "Rogier R. Mulhuijzen" Subject: Re: ip-accounting In-Reply-To: <20010128193701.A3139@ramses.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >are there any recommandationions how to get IP-accounting to work on >FreeBSD? I have switched from ipf to ipfw so now I need a new way do >keep track of the IP-traffic passing my machine. >I have a machine with 30 IP-aliases. >The least thing I need is monthly summary of the full amount of >IP-Traffic that passed my (one) NIC. If possible it would be great to >have it split by the different IPs. Furthermore if some scripts existed >that could create HTML reports that would be great but not necessary. >The way ipf and ipacct do the job was pretty cool so if anything similar >was possible with ipfw or if there existed a tool to do the accounting >on its own with the desired results I would appreciate it a lot to know. Add 'count' rules at the top of your IPFW rule list. Per count rule (and other rules) IPFW tracks the amount of packets matching the rule and the amount of bytes they total up to. Check the 'ipfw show' output out. These rules: #All traffic on public interface 00001 count ip from any to any via tun0 #incoming traffic on public interface for 1 IP 00002 count ip from any to 212.64.31.128 in recv tun0 #outgoing traffic on public interface from 1 IP 00003 count ip from 212.64.31.128 to any out xmit tun0 Produce: 00001 154 25624 count ip from any to any via tun0 00002 2 72 count ip from any to 212.64.31.128 in recv tun0 00003 5 3112 count ip from 212.64.31.128 to any out xmit tun0 There are also command to reset the counters etc. Check the ipfw(8) manpage. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 8:43:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 97D2B37B69C; Mon, 29 Jan 2001 08:43:12 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA24916; Mon, 29 Jan 2001 17:43:11 +0100 (MET) Date: Mon, 29 Jan 2001 17:43:11 +0100 (CET) From: Harti Brandt To: julian@freebsd.org Cc: freebsd-net@freebsd.org Subject: netgraph: problem in ng_base Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, it seems like there is a problem with node reference counts. I have a test program, that instantiates a chain of nodes like this: ng_atm -----------> ng_sscop --------------> ng_sscf ---------> ng_socket | ^ +--------------------------------------+ the ng_sscf and ng_sscop node's disconnect procedures call ng_rmnode_self() in the case that the hook count drops to zero and the node is still valid. The shutdown methods free private memory and call NG_NODE_UNREF. When destroying the above graph I first send a shutdown to the ng_sscf node and then to the ng_sscop node. The sscf node disappears as expected leaving the sscop node with two hooks. The shutdown of that node first disconnects those two hooks and then calls the shutdown method of ng_sscop. Everything is fine, except that I find the following lines in /var/log/messages: Jan 29 17:26:21 beagle /boot/kernel/kernel: disconnect 0xc2c54980 from 0xc2c94d00 (invalid) refs=3 flags=9 Jan 29 17:26:21 beagle /boot/kernel/kernel: ng_sscop_shutdown: 0xc2c94d00 refs=2 flags=9 Jan 29 17:26:21 beagle /boot/kernel/kernel: Accessing freed node node: ID [7]: type 'sscop', 0 hooks, flags 0x9, 0 refs, : Jan 29 17:26:21 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 735 Jan 29 17:26:21 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 2436 The first two lines come from the sscop node, the other from ng_base. I have put a couple of printf()s into ng_base to understand what happens but could not find the problem. I have the feeling, that the reference count when entering ng_sscop_shutdown should be rather 3 than 2: one held by the item from which the shutdown is executed and which is UNREFed in line 2436. One extra reference from the ng_rmnode function and the reference, that is UNREFed in the ng_sscop_shutdown method. But I may be wrong. So what is the problem? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 9:44:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5237137B402; Mon, 29 Jan 2001 09:44:09 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA88110; Mon, 29 Jan 2001 09:44:08 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id JAA20568; Mon, 29 Jan 2001 09:44:07 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101291744.JAA20568@curve.dellroad.org> Subject: Re: ipfw message In-Reply-To: <20010129105926.B27558@sunbay.com> "from Ruslan Ermilov at Jan 29, 2001 10:59:26 am" To: Ruslan Ermilov Date: Mon, 29 Jan 2001 09:44:07 -0800 (PST) Cc: Alwyn Goodloe , net@FreeBSD.ORG, Archie Cobbs X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ruslan Ermilov writes: > I think I have found a bug here. When the ``divert foo ... udp ...'' rule > has no destination port specification, everything works as documented, i.e. > all fragments are reassembled and get diverted to the divert(4) to port > ``foo''. If I add the destination port specification, only the first > (offset zero) fragment gets diverted: Yep.. diversion happens before reassembly, but diverted packets are only delivered after reassembly. So if not all of the fragments are diverted, the packet is lost because only an incomplete portion of it gets diverted. To "fix" this bug would require reassembling *all* (or a large portion of the) packets passing through the kernel, which is probably not a win. A workaround is to match conservatively (i.e., match all udp packets) and have the userland code just reinject any false positives. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 9:59: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 22B2037B698; Mon, 29 Jan 2001 09:58:32 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f0THw2886968; Mon, 29 Jan 2001 19:58:03 +0200 (EET) (envelope-from ru) Date: Mon, 29 Jan 2001 19:58:02 +0200 From: Ruslan Ermilov To: Archie Cobbs Cc: Alwyn Goodloe , net@FreeBSD.ORG, Archie Cobbs Subject: Re: ipfw message Message-ID: <20010129195802.B83844@sunbay.com> Mail-Followup-To: Archie Cobbs , Alwyn Goodloe , net@FreeBSD.ORG, Archie Cobbs References: <20010129105926.B27558@sunbay.com> <200101291744.JAA20568@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101291744.JAA20568@curve.dellroad.org>; from archie@dellroad.org on Mon, Jan 29, 2001 at 09:44:07AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 29, 2001 at 09:44:07AM -0800, Archie Cobbs wrote: > Ruslan Ermilov writes: > > I think I have found a bug here. When the ``divert foo ... udp ...'' rule > > has no destination port specification, everything works as documented, i.e. > > all fragments are reassembled and get diverted to the divert(4) to port > > ``foo''. If I add the destination port specification, only the first > > (offset zero) fragment gets diverted: > > Yep.. diversion happens before reassembly, but diverted packets > are only delivered after reassembly. > > So if not all of the fragments are diverted, the packet is lost > because only an incomplete portion of it gets diverted. > > To "fix" this bug would require reassembling *all* (or a large > portion of the) packets passing through the kernel, which is probably > not a win. A workaround is to match conservatively (i.e., match > all udp packets) and have the userland code just reinject any > false positives. > Or add ``divert same-port udp from any to any frag''... Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 15:47:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn120.dh.casema.net [212.64.31.120]) by hub.freebsd.org (Postfix) with ESMTP id 745A437B69D; Mon, 29 Jan 2001 15:46:58 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0U092b05863; Tue, 30 Jan 2001 01:09:04 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010130000929.00c80a20@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 00:15:34 +0100 To: Erwan Arzur , Roman Le Houelleur From: "Rogier R. Mulhuijzen" Subject: Re: bandwidth analyser Cc: freebsd-ipfw , freebsd-net In-Reply-To: <3A755C23.AE8D79E1@netvalue.com> References: <3A6C7FD0.7E2ABD65@IPricot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Moreover, concerning the bridge, I was wondering if > > there is a way not to put a third interface in promiscous > > mode. As this third nic exists only for management purposes > > I don't want it to participate to the bridge in any way. Use the ng_bridge node if you want to have precise control over which interfaces are being bridged. There's one downside though. You can get statistics from the bridge node on packets and octects passed through the different parts of the bridge setyup, but it's not IP based. Also using that bridging code there's no bandwidth throttling or IPFW rule matching yet. Vitaly Belekhov wrote BW throttling and ipfw netgraph nodes for 3.X, and I will be porting those to 5.X-CURRENT over the next few weeks. Using those you could get statistics really quickly by using libnetgraph and querying the nodes yourself with some C code instead of shell/perl scripting. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 15:53:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn120.dh.casema.net [212.64.31.120]) by hub.freebsd.org (Postfix) with ESMTP id 60AA037B6A3; Mon, 29 Jan 2001 15:53:17 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0U0Fcb05888; Tue, 30 Jan 2001 01:15:38 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010130001851.00aed910@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 00:21:51 +0100 To: Erwan Arzur , Roman Le Houelleur From: "Rogier R. Mulhuijzen" Subject: Re: bandwidth analyser Cc: freebsd-ipfw , freebsd-net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Use the ng_bridge node if you want to have precise control over which interfaces are being bridged. Another thing, be careful when you enable the netgraph node when you have BRIDGE compiled into your kernel. 2 reasons: 1) if you have the bridging code activated you'll get broadcast loops resulting in links being deactivated and whatnot. 2) when you have the bridging deactivated you'll run into some nice problems due to this problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=24720 (patch included). Nothing earth shattering, but when you alter your setup in anyway some machines suddenly become unreachable until the arp tables age out on them.... DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 16: 0:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 84E1B37B69E; Mon, 29 Jan 2001 16:00:01 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0TNxOU48488; Mon, 29 Jan 2001 15:59:24 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101292359.f0TNxOU48488@iguana.aciri.org> Subject: Re: bandwidth analyser In-Reply-To: <4.3.2.7.0.20010130000929.00c80a20@mail.bsdchicks.com> from "Rogier R. Mulhuijzen" at "Jan 30, 2001 0:15:34 am" To: drwilco@drwilco.nl (Rogier R. Mulhuijzen) Date: Mon, 29 Jan 2001 15:59:14 -0800 (PST) Cc: erwan@netvalue.com, roman@IPricot.com, freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > There's one downside though. You can get statistics from the bridge node on > packets and octects passed through the different parts of the bridge > setyup, but it's not IP based. Also using that bridging code there's no > bandwidth throttling or IPFW rule matching yet. > > Vitaly Belekhov wrote BW throttling and ipfw netgraph nodes for 3.X, and I > will be porting those to 5.X-CURRENT over the next few weeks. > > Using those you could get statistics really quickly by using libnetgraph > and querying the nodes yourself with some C code instead of shell/perl > scripting. the real problem with any approach is that if you have very many flows, you have to fetch all the info every time you want to update your statistics. The ipfw implementation which is in the kernel now really does not help you there, because the stats are spread over lists and hash tables, and on top of this the data structure evolves dynamically as pkts come in, so you need to hold a lock while navigating on it. This is why you do not want to download the stats 10-20 times per second, at least with this architecture. I do not have a good solution in mind other than maybe change the data structures so that the flow descriptors (at least the part with the flow identifier and the stats) are in a contiguous chunk of memory whose only variable part is the size. This way you can either mmap the block, or copyout() it without having to get a lock. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 16: 3:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn120.dh.casema.net [212.64.31.120]) by hub.freebsd.org (Postfix) with ESMTP id 9624937B69E; Mon, 29 Jan 2001 16:03:35 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0U0Q1b05909; Tue, 30 Jan 2001 01:26:01 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010130002432.00b5f100@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 00:31:38 +0100 To: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG From: "Rogier R. Mulhuijzen" Subject: Is anybody working on bridging code & a question for -arch on userland/kernel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 1) Is anyone working on the bridging code? I'm going to extend the ng_bridge node with Spanning Tree Protocol and I wouldn't want to be duplicating work. I checked in -current, but I thought I'd check on -net as well. (And -arch because of my next question) 2) Where does one draw the line at handling stuff in the kernel or userspace. The algorithms that are used in the Spanning Tree Protocol aren't very complicated, and I'm pretty sure I could contain everything in kernel space, but what is the Right Thing to do? Everything in kernelspace, or running a userland daemon that does all the calculating, decision making and time tracking? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 16:11:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E220E37B404; Mon, 29 Jan 2001 16:11:26 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0U0BNx48599; Mon, 29 Jan 2001 16:11:23 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101300011.f0U0BNx48599@iguana.aciri.org> Subject: Re: Is anybody working on bridging code & a question for -arch on userland/kernel In-Reply-To: <4.3.2.7.0.20010130002432.00b5f100@mail.drwilco.net> from "Rogier R. Mulhuijzen" at "Jan 30, 2001 0:31:38 am" To: drwilco@drwilco.net (Rogier R. Mulhuijzen) Date: Mon, 29 Jan 2001 16:11:13 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 1) Is anyone working on the bridging code? I'm going to extend the > ng_bridge node with Spanning Tree Protocol and I wouldn't want to be > duplicating work. I checked in -current, but I thought I'd check on -net as > well. (And -arch because of my next question) i am doing some minor fixes to the non-netgraph version of the bridging code. > 2) Where does one draw the line at handling stuff in the kernel or > userspace. The algorithms that are used in the Spanning Tree Protocol > aren't very complicated, and I'm pretty sure I could contain everything in > kernel space, but what is the Right Thing to do? Everything in kernelspace, > or running a userland daemon that does all the calculating, decision making > and time tracking? i'd rather do as much as possible in userspace, and issue appropriate calls (basically sysctl or similar to enable/disable forwarding on some of the bridged interfaces) when necessary. If you need a specific control interface i will be glad to implement it, and your spanningTreed will be much much easier to implement, test, maintain and reuse for different bridging things (not to mention that a single box can act as multiple independent bridges for which you want multiple spanning trees). let me know if you have some spanning tree code that you want to test/integrate. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 16:56:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from wireless.net (unknown [207.137.156.159]) by hub.freebsd.org (Postfix) with ESMTP id 61ED737B400 for ; Mon, 29 Jan 2001 16:56:21 -0800 (PST) Received: from localhost (bad@localhost) by wireless.net (8.9.3/8.9.3) with SMTP id QAA10214 for ; Mon, 29 Jan 2001 16:56:28 -0800 (PST) Date: Mon, 29 Jan 2001 16:56:28 -0800 (PST) From: Bernie Doehner To: freebsd-net@freebsd.org Subject: existing 802.3AD link aggregation implementation /w FreeBSD 4.2 bridging? In-Reply-To: <200101300011.f0U0BNx48599@iguana.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi: Does anyone know if there currently is a working implementation of 802.3AD link aggregation that works on FreeBSD 4.2 with bridging? Thanks, Bernie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 18:45:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id E5C2B37B400 for ; Mon, 29 Jan 2001 18:45:06 -0800 (PST) Received: (qmail 38389 invoked from network); 30 Jan 2001 02:45:01 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 30 Jan 2001 02:45:01 -0000 Received: (qmail 8895 invoked by uid 500); 30 Jan 2001 02:50:11 -0000 Date: Tue, 30 Jan 2001 10:50:11 +0800 From: Yusuf Goolamabbas To: freebsd-net@freebsd.org Subject: Bridging and dummynet seems to destroy dmesg output Message-ID: <20010130105011.B8847@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I cvsup'ed my traffic shaper box today (RELENG_4) [incorporating Luigi's latest fixes]. So far, I have not been experiencing any stalls. However, the output of dmesg seems to be corrupted. I see only 1 line everytime I invoke it %dmesg >ipfw: 400 Pipe 1 TCP a.b.c.d:port e.f.g.h:port in via %dmesg a.b.c.d:port e.f.g.h:port in via /var/log/messages also seems to have various log messages from ipfw in a segmented manner. Is anybody else seeing this ? Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 20:52: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8610A37B404 for ; Mon, 29 Jan 2001 20:51:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0U4pmj54651; Mon, 29 Jan 2001 20:51:48 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101300451.f0U4pmj54651@iguana.aciri.org> Subject: Re: Bridging and dummynet seems to destroy dmesg output In-Reply-To: <20010130105011.B8847@outblaze.com> from Yusuf Goolamabbas at "Jan 30, 2001 10:50:11 am" To: yusufg@outblaze.com (Yusuf Goolamabbas) Date: Mon, 29 Jan 2001 20:51:48 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org are you sure you made a proper upgrade of header files and binaries ? i have not seen the problem locally, and i have been running a shaping bridge with the new code for most of the week. cheers luigi > Hi, I cvsup'ed my traffic shaper box today (RELENG_4) [incorporating > Luigi's latest fixes]. So far, I have not been experiencing any stalls. > However, the output of dmesg seems to be corrupted. I see only 1 line > everytime I invoke it > > %dmesg > >ipfw: 400 Pipe 1 TCP a.b.c.d:port e.f.g.h:port in via > %dmesg > a.b.c.d:port e.f.g.h:port in via > > /var/log/messages also seems to have various log messages from ipfw in a > segmented manner. Is anybody else seeing this ? > > Regards, Yusuf > -- > Yusuf Goolamabbas > yusufg@outblaze.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jan 29 23:52: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 7BC8437B4E0 for ; Mon, 29 Jan 2001 23:51:43 -0800 (PST) Received: (qmail 9483 invoked by uid 666); 30 Jan 2001 07:59:58 -0000 Received: from reggae-02-108.nv.iinet.net.au (HELO elischer.org) (203.59.91.108) by mail.m.iinet.net.au with SMTP; 30 Jan 2001 07:59:58 -0000 Message-ID: <3A767279.977B96CA@elischer.org> Date: Mon, 29 Jan 2001 23:51:21 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Harti Brandt Cc: julian@freebsd.org, freebsd-net@freebsd.org Subject: Re: netgraph: problem in ng_base References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Firstly, thanks for the report. And thanks for spending the time to look into it. Can you tell me wheher this is a very new -current, or an earlier one.. (i.e. did I f*ck up in my latest changes, or might I already have fixed this :-) what version number of ng_base.c is this? (I just recently made some changes to the reference counting.) Harti Brandt wrote: > > Hello, > > it seems like there is a problem with node reference counts. I have a > test program, that instantiates a chain of nodes like this: > > ng_atm -----------> ng_sscop --------------> ng_sscf ---------> ng_socket > | ^ > +--------------------------------------+ cool :-) > > the ng_sscf and ng_sscop node's disconnect procedures call > ng_rmnode_self() in the case that the hook count drops to zero and the > node is still valid. The shutdown methods free private memory and call > NG_NODE_UNREF. good, that is standard procedure, and I assume you got that from one of the other nodes :-) > > When destroying the above graph I first send a shutdown to the ng_sscf > node and then to the ng_sscop node. The sscf node disappears as expected > leaving the sscop node with two hooks. The shutdown of that node first > disconnects those two hooks and then calls the shutdown method of > ng_sscop. Everything is fine, except that I find the following lines in > /var/log/messages: > > Jan 29 17:26:21 beagle /boot/kernel/kernel: disconnect 0xc2c54980 from 0xc2c94d00 (invalid) refs=3 flags=9 > Jan 29 17:26:21 beagle /boot/kernel/kernel: ng_sscop_shutdown: 0xc2c94d00 refs=2 flags=9 > Jan 29 17:26:21 beagle /boot/kernel/kernel: Accessing freed node node: ID [7]: type 'sscop', 0 hooks, flags 0x9, 0 refs, : > Jan 29 17:26:21 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 735 > Jan 29 17:26:21 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 2436 > > The first two lines come from the sscop node, the other from ng_base. > I have put a couple of printf()s into ng_base to understand what happens but > could not find the problem. I have the feeling, that the reference count > when entering ng_sscop_shutdown should be rather 3 than 2: one held by the > item from which the shutdown is executed and which is UNREFed in line 2436. > One extra reference from the ng_rmnode function and the reference, that > is UNREFed in the ng_sscop_shutdown method. But I may be wrong. > > So what is the problem? well, it looks to me like the removal of the last hook runs ng_rmnode_self(), though this shouldn't happen because the INVALID flag should have been set before the hooks are removed. There is an impbalance in the references as you noticed.. ng_apply_item holds a reference on the node to which is is applying a message item for the period that the node is being called. When this message is a 'shutdown' message, ng_rmnode() also holds a reference on the node (it gets called from other places too) for it's duration of operation. Theoretically, ng_rmnode should release it's reference but the node should still exist because ng_apply_item() is still referencing it. This is not happenning so either we never applied a reference somewhere where we should have, or we are dereferencing it somewhere twice. can you send me a copy of your ng_sccop node so I can try simulate this? in the meanwhile I'll try using the 'hole' node to simulate it. > > harti > -- > harti brandt, > http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 0:43:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 5AC4237B4AB; Tue, 30 Jan 2001 00:43:10 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id JAA17410; Tue, 30 Jan 2001 09:43:05 +0100 (MET) Date: Tue, 30 Jan 2001 09:43:04 +0100 (CET) From: Harti Brandt To: Julian Elischer Cc: julian@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: netgraph: problem in ng_base In-Reply-To: <3A767279.977B96CA@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1912210914-980844184=:5981" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1912210914-980844184=:5981 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 29 Jan 2001, Julian Elischer wrote: JE>Can you tell me wheher this is a very new -current, or an earlier one.. JE>(i.e. did I f*ck up in my latest changes, or might I already have fixed this :-) JE> JE>what version number of ng_base.c is this? (I just recently made some JE>changes to the reference counting.) It's a a current from yesterday. ng_base.c is: * $FreeBSD: src/sys/netgraph/ng_base.c,v 1.42 2001/01/25 19:48:57 julian Exp $ * $Whistle: ng_base.c,v 1.39 1999/01/28 23:54:53 julian Exp $ JE>good, that is standard procedure, and I assume you got that from JE>one of the other nodes :-) yes :-) JE>well, it looks to me like the removal of the last hook runs ng_rmnode_self(), JE>though this shouldn't happen because the INVALID flag should have been set JE>before JE>the hooks are removed. JE>There is an impbalance in the references as you noticed.. During the first disconnect the INVALID flags is not set. This is ok, because the disconnect is called from the sscf shutdown. During the next two disconnects the nodeflag is 0x9 (invalid | closing). Seems, that somebody is not looking at these flags. JE>can you send me a copy of your ng_sccop node so I can try simulate this? JE>in the meanwhile I'll try using the 'hole' node to simulate it. I have attached the sscop node and the test program for it. You may need to adjust include paths. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru --0-1912210914-980844184=:5981 Content-Type: APPLICATION/octet-stream; name="ng_sscop.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="ng_sscop.tar.gz" H4sICKx7djoCA25nX3NzY29wLnRhcgDsPPt72kiS+RX+il7vJAMego3txDP2 OLcYZEcXXiNBMrnHp5WhwVojiZOEE++M//erqm5JLSHwI8nMd7fmm4mhu6q6 3l3VengzKwzH/mLn2bf7sIPdw1ev2DPGGrsHh/h3/3BvF//Gn13GDvf2Xx0c HhwevkKw17uvn7FXz/6AzzKM7ICxZ5cXFxvhxnYUPvv/9/Fi+3ftKz515vwb rNHY3X19cLDe/geNfWH/vcPGIQCyxt5+Y/cZ232y/zf//JV9dxZwfmq2j1gY jHfCm3DH9SfLOQ93PB7NAntxucOjSx4kHlK7Zo16g+3t7u7u7L7e2XvN9vaP DhpHuz8yOxhfOpxpnxfsu3L5XbffPimVYhcrm0bLPGHpQH3M5N9y66zTPDfZ DyellzP2st3WTkfn5U5bGRXk2rpxUooZLJfrjjeeLyecbe0sw2BnrQAx6wi/ lWL9fBFO6lcAXXev3pSf/St+kvhPjfIHx//+wd7haxH/+42DxuE+xv/rw8On +P8jPjvbZbbNWv7iJnBmlxGrjKsU2S/hnwY75TPu+hHMu4tlxAPWDEN/7NgR D+usOZ8zQgpZwEMeXPNJHYnh/wafOGEUOBfLyPE95k9ZdOmELPSn0Sc74Mz2 Jmzij5cu9yKbQHBkGXLmeAC1DMYEg6QuHM8ObtjUD9ywxj450SXzA/rrLyMG wetMnTHRqDEkveCB60QRn7BF4F87E/gSXdoRkoI0BnTmc/+T483Y2PcmDuKF hOfy6Chmv1HPSRCiCJKvsQ+pA1jI8u+CI4EeIhsEwHXsC/+aIy34jBP1en7k jHlNaGMOCyBdlRFvkuMSuBjPbcflASl3b5UzWFDRUcwICD9ZArcJLykXkqsv 4YUJKSWlFUvugHp83DSYC74SOPY8TK1BJkTCqhgk3L5wKntyzYPICXHJFB8X AEAcnHI7WoLPoRXQZ/LuJdkiTcAii7l9k5PEHl95/qc5n4B/A93E8EMkI1QX MblNbHTbCb/mc38BYl3cxOEiImolYgjbgWgBHQu5/SBMIuagDotz5tkuybMh 8lDqPBnQ0w0alF3EwoNewHw+494E5slhQS4gyWP5QmA+cCBq2RQmcgEq40sS Cxd8jGEGqA4GX4AB5olQC8PYfKTAt7rJzP7Z8EPT0Fiz12btfmvU1XrD5lDv 9xjMDoz+e72ttdnpR3aqnWvd/pC1+t3BaKgZrGma/ZbeHGomUkN8fWjCdG9o 6KejYd8w2d//3jSBzvff03Sz95Fpvw4MzTRZ32B6d9DRgTYsbzR7Q10za0hI 77U6o7beO68xoMJ6sGRH7+pDgBz2a8C1VoDJ+mesqxmtt/Czeap39OFHXBLp nenDHq54Bks22aBpDPXWqNM02GBkDPomSA7St3Wz1WnqXa1dZ8ABrMq096AJ Zr5tdjqx7OQtq+KTMHnRAQf4bp52NLEyyA4VkdYa1oC+/CbFBQ0D150aMwca UIQv2q8aiNg0PtaQNtA1tV9GAASTrN3sNs9h0cqqopCeqiswX2tkaGhSVJA5 OjWH+hC4Z+f9fpv4NjXjvd7SzGPW6ZukxpGp1WCRYZPYAxCgAjoECPh+OjJ1 0qbeAx0YowF6SpW97X8AdQGnTcBuk7HBgVBmMFff+Ah0BW/SNjX24a0GUwbq mtTWRMWYoL7WUAWDJUGbQ0VYpNPTzjv6udZraQjQR0IfdFOrgil14O8cqeLi H5qw8ohkR7cB3sRXxe9JSDQ1089Ys/1eR/4lPHiHqUtnIvW13krtYwwh4nf6 5Iil5RiV2/u4KTd24D8otxtQbu8f7e4zqFlkrS0we7LeZaIAxv0AfGj0csh+ qe81GrvMNFv9QbxOcwkhHhyxtzYkW3YaQHqC/f+C/v5t6l8tw/rMndQnvArQ O+W/sqRsxhp7YQe2W798kx+H/6Oi8SseeHxeMOHakJTHRRMXy2nBMA8Czy9e eO7Piib88RWP1k5c20HB3Bi5WuaxXBv6G4/vhNHEDmgtdTZpN8B4Lg9De8Zz +CmE/LJ2fmaBgsMc/lbiFZdb6nAyBoMTaHQ8ztrtNiZrL5pWtp6HR+z55L+8 rRqzrLNRr4XxZVn4qwOBZ1lVEmMKqEx0XksLMJM+zbqezu0ZO2G7n6fwOQZg 2FWcabnchTzWb1lt7QzoVLpWTxueG83BW4scrQYMS4EEoS1lRLR+sGdN+Fb1 uFwWhegANiTY49jEjmzyOqgQcCtOWFlIgN/KpUvfv7IWpdJyAfvQcfobtvjM b9f2wBIwIGkRodI2/Tku38La0Q1s4CD8usW28Yu1SLlE02DWb3YZ4kpOoSIY 464MVUdKicxoid+g1amvkMcQspCAmDiBHRQ+vXOhPosWsPTeWR9W3kgeaRTR BZKgqBd5NnCqJsYLOSGlqKLakNKHisD1R0oc8mhF6KzMsM5jxc4Qv6/kqxzV NkoPVecCeOFfqgCkcw8tQFkz+BJVJMs8WB9ZBoVS1nAwdifUPiRE5MB//rdY Ff5D2bpSuFa//06HPTIzeC4lpuGtmeRiS0CNOh36UuSw5dJt7X5LmJklwswS axxi3VyiHLk622W3qoZQKagk1JAfWKpq0uFjBTq8XEYT/5NnKVk3HlPhgvG1 G85UKDGiwnj8E6U+BUgOqVDYy/mex9EJUsB0NLcqJuTcsjiUigwbRiol1B8W NEZeVBGViBXVEKDGrn1nwrarKVrqRVkPxl9yjnwIQgPqNwvqQRM2rxoNCLP2 +m3NGn4coLlXGaiVdrZZV5RDNMAuob6ZQ0NV8RfYwdnzKoZyqchChNzDdl8Z zEIL9RMg9WP+nMmtHxs06OWgCeZZlNiuhIQnJ6AXbA2nAef4m04ZwiyONCCh TJ0gFCcJ8cEHNowAwRCE8ChiSiUB7U2KxqWZV6RBqwrOxPcsQOofBENM3DDs g5OJnDZFKqD8kVQHek8fVmi+pkRXanL0D9WvgBWLdvkKlguWqBpqTOzK9Afc K+Iu/MA/1eM8sigBHotNBcVjkCP+ObLw9zKU6DFmjY0vbXClGqNSazUgZOEV 2RfKV9qXvuCzI7c1DBnWbfag6cA2Tt3LgJlyUSio4lfLEJCKBoCtkqgEK0Ih sYyh80/uTytUPlVrbLU+hJH+h6Y+/L1r/Ydm9EENJWdKRNjJCeX9arlUCni0 DDym9fpdrYuLAQwBvXwjisgTRUf1hOmKMNWLdK5aTchiTimdGZomWc7zhqzk Fy7dlinvUMaB3cQaGPp76NUrqU+gIWO0XSguC9UaJ4BNOgWZ4pXUVZB+XNav 0IMqfwEJZBqePIdsAiU7fPlMZb9gEP99+cabWAij/CRQFFjR4gRD0b9R1Uyy 3aGy9dohrR8rChz1DO0sESqjtK/j5XQE0O+wrmaaeLix1s1FDs8GuBLTNSY6 CTa3wwi/3t9WpXR7g11hxraxcGDCBQtmaSMvYeaAJhd2mhNUB2pMx/rI6prn FcEQAJLSwk9ONL6swM+Xby65PeFBHbPoGJh0OPo41i9jG2pYLIPOtZ5m6C1Z HR2BgxfgQ8IWiCrmUPt1aJnD5nBkIhrasPsOa1M8RKqgUMRTDfWAsPFUGuEU Txi4QgNqFJZKsbRJoMHnIuD2FX3FqMNYDBcJk9B8z7kHGPkMK6KwhghYUFdE lq0KZNraWAGhKvuBNWgtuSpJDx2hvZxHJHDCod573+yooMifgqcoTS1FH6Ls bEF8VBaikKYymwOVotCbErvrTZIk4epXsgb8gz5cKWJG0TRBKxklrunVlALm qmaViaLeFirE3KCQlQqdbYNljzdBUA2faA9UodpF+tdfThLtwUh1RUGpM+QV BOCKigrYq9JyiZ7+NOut00vekPDdtcMrwATRxPd4PF5RsXVYZOs4KF8QBZqH 3VkSXu8GjwxDBW0VK0aSG7pQfJsSLAHXlF1AZAy5ueH2R2AiA8e7FiHRziX3 F+xzyp/lTi2S0PYiCmS5x7bBu2qyjxazUxe6gHq9TnvLtW1RQ20v5Hbgyapn m7IebAtpWXRM4HgRO6rY4DVACBnD5HgdepIDsbZYlVaySSBA5N6kIn4AeY+9 ISDhS4jEfjihEVSaWBy3pNIt4/OQCygcfXnCBIhE8Ui3mepntRYuKqWFMsBB Yk0hN6gSMYHkyQOlPoR7UWuAGokV/oLEfUHibtEsbeFQH4Vx3yMujj0Pj56H WCFJlwMLv4V8bfWaXS1DXAGgfZ4AEmgYSX4MNM3IoFarhdQ3wIPyUL33Eehn vOaXiPQGRKlmVEOty1rV0OzjVSOIP0o1AvX+qonh71CNKtBdqhE94VrdiOnH K0eSf5R2JO791ZMg3KGfjFBrFFSIKPosDF+O2hCi05VhJenjLF6/rmR3fRrP NBJVteLHmH4pYvprVf6onvv0t/JUJZuPZLFPxy2ZFI2iPaBNQ0+DTXbsLiqI GQfuVjVJ4ErUAx1xQEfmYyuo5NgrqMLd70AVNl/Bla6QQVZaXrlV3t3Mpgc/ FUVzpCdFrUJPqdMTzPFDO17lkAk6XbprAf5WnofX9tyBSnqrJs0mW05JTjct EEZvC3r/trV1tOWQs8d01/bMG7tl0DQdrIFec/tQ1rCy2Yutk8VJEnTWohtx 0syVM6XAIs6SfDPqotZNIbvwAdq3FZisftB0K0cMqeaPWOCSYUM+n+KJQ6Is UcLhcXEKEJvwNlMzQJRCXttmuruY3zAbCqw5x2I/4P+z5CGeFU/pfh2hwbl9 gzcchQIn5QRvN8OhHSFNRulCF+zFC1XNWM/LYZFX78pTiCCaD73d0WSFrSDZ dujMsv2MADe0jtY0NSsWKC596fwVLCDr1dtvceyBd1lsOurAkr6SSXLq+eVX jdsNISLlzp7s1pQD1cIISz1fwVcOd+8kkISbgp8e7+bRc8nwVj2ULj/0UBo1 K5suvLOBbbu5S9IWNo14RYXiA8NDRIHw3TgKWGbXZnibwicsSRaBP+YUEnQb WxYtxOv1eOPc0hvTBYNPznzOJgHs6f4ymvk0B/0YD2uEH9/6J7Z9Ao4cl+MN l7Z3w8Cl7QvoUC7jiA1p2R3lqCo+qFL7Jn2oifHYN/5SccGmIqOyF9DfDt4N 37YN2WgnSQiEu4ouJ4GoUEolwAg4dytu5pA2bu5uiTQRxtbk57iFtquYDiou +CvYZDmfLxcVt5bOKofDBUe/F3j3ZKUytieTwIqqbuRPCDtvv23o01/YKllA di178o/sYsrWujmh2HUYAkXiNzyEWOkyQ9iThB+qzLBtiS+uuMEX7i3dmFFc hhHdrEfW6DK06LxwsdVsIJ29urhvEkiPM4vcfdte7eSyJxpoyzhxo2EKrS9b eYLNYHfBGcGjUPddq93vDfH8BL4PLUyTRCGDJE4aJclS4kTJOVBegGoCJly0 LqBjxGyrDP5taAOt11ZcYYWgyugd/IGn27jYel8EIBs8yZmRBDPxU5xNySYa L6MCR6QOq9/rfIwPQBSDiDBezX4Puqp2d/pzk/z3sCzyfzPU3Q2xXhzkUt33 jnI3DXMK61yoyzAHc8dfx170bSPehVG2zQsNn8sEcU37BamA3D4u4LqaYfQN EHMir5l/m/ywze/OCCW+LmiFfogCz4Yt/sbJE1Ss/A3mgt/wb5plvn0C3Lbv IeDarOQmaSmfl+5Ik7DsAxLjoxi4OxkKn1yXDR9yl0BRMlTLvk+cHklRex1m Rys9ET1QIB43wQaFsKmLqYnaDms1xxv7LtZ3C5tug5WFWm7LjTuj338vP7Yx KkzaarfkeFh+ZjMeAd2uS+6Z5iifDoW+N2fDrI6/dnLLn7NmI29DcrrDz4hY 4mbZO3NJ/PTGXB5c+CGv3OtKQvGFgmtZZq+7LBBX4aL4vk3v/f0qzSreCaQ3 O7pJT4dQ2ypnOr5NLQs9F+bN5S+80Qktl7/rNtPkrt59hjfE0x1o4h6w2EOw FSY14UxYdOk9xPywmHs8qtDlfHEJl4hkLq93+22r02+2j5TTDYPPQPXgFknX hb1oqJ5ZKNEBpsQHaTCy5AlNet1K+1U3h6tXuwS24zkRkZjzinqvSy76sAW0 kpOitJ4oAotPrpLWoggoPqpKYvG44Do46mXUizVzx+W5/qDXH5qjwSB7ia4E BvhcCYsutz17+nyt53/lMwTfYo07nv8/2Gu8oud/D/YOD/df7eLzv43Dvafn f5+e/316/vfp+d+n53+fnv99ev736fnff63nf2U5lr5rJ/fw78HKw7+D5cWc OiHxUCi+7oYeAKY+/dGP/E49ejCSav9LK32+NBmBoSXBxLe7GtrKo6ljSMRF j6zSo7f01KroKZ/K8T+5/sfzh6/fA2yu//car/cPc/X/fmPvqf7/0+r/xk8/ HT7V/0/1/1P9/1T/P9X/T/X/U/3/J9X/ohx7SA8gX1hCtbgo1UUyz77zJ7xn B0D3LBr+BTvDS4isEvgXf7sQianu4+1BokmQLYFoAJSn9EuN5D0a7RGLAhta koBwlh7mzsVkyX4ry/uNkjsrveV8flxOblf4LbkAdgr+Yp2iidp6s1cuSbTF nB2xvdIxPo++sCf4xMgMNhi8xCIhjljjuBQ/bB9QwnP4fKKChCwBkru8Mklv JjhiB7QEiYIDCoCH6HtiPsQ74jwg4C3dCx4IDYmbq+8Hfe9VN/J8D5nXKy7u xxi7BUekd+TkGr/FHKxVX8zz4yEOh/lR5Bwn6Kpdbs4jFC+MXQU04vmiHIFN VhY1VL7FbiMgHuQ4eZ85Yj8K7aDcqiGlZaRpYJkC8xXBrCN8tyY9Ej+WHrZ9 hwJDkfdi5n2RtJLdjDOkLAN1dCTJ9vuh1TVWhV4DtHmBu2VHsig+/o01gEmB 3gRBGqDbmWBIvB3kt3IJAsE6Pe+VSvg2qoZ8hQbdg8oo19lz55+iMkP+BHTz HUHvZaBzFWACDroTxPcJXHnkYOy7LpZwCqSkfJAHXUfcMAXtV/G7P2688WUA RW0oeM4vYZhyhddrENYtdHpuaP9OmIc15W0fiBLwf8Rv6UBIU4r7Y03NRxMF 46WLDU/yLhAS3RBIP0m2xtBfQKjm2R/0Ox2CE28U+Qx9mbg/hdFLj6gRAHvU 6ZwKqFzL2YQ3KBoJ/0Iw58+dsYOdHcByqFwDlVqMNEqwxoS19O6JJxUxkViU kDk1pUFW+q6E5DlIcUGd7JDTlrTiNKuuAuPhO4RkIEA3EIrbgGzoiUJn5kEX VKNelkapwIemQ7zTj7V973u6BcSbiabPD6C8h3+Rltxd4qYZCPkCFHsh6hDj 7gJ6BryTIKyn4SczuzOLY1DIwKl1APm+F++qMfVzjMxa6Y6YFHDNd1nAIkdG SAgyAbgmECVMTO6OGERow6wluWpD+AnQlM37RJ4QDSKvVlofdAhktiUP94g3 ktBIeC4INYTAUBOrfqbTj6Ao0IrijNiBiKmV7hdiCD9KEe4TXYQSS7wusBCo uwpUFFNCI6lp1HDKGIRcNaLzCv554QBMjD60Wi2B3mpJiHQq1SV+W5l+1xST 7zRtwJod/b22AtIzBAh0fPFD/SsweOecgMJv6TQxTbrxAwcClIJShn9qbkgr v0geoTTkHrjREo+8Qr6c+AJaMZdm0L1m0mSJ3uPgS5QKdj21DE1STh/zyHhy MY452Igk3pqXRpZ8QIrWIiOKJ8A2LATNbf+9JhVrLyPfpTu/pPlXlzA/9lqp LKsBnKcv4WM5ihByK4xSndLXFZLdFKBbCDBS7ChI3G3NroLTvSeOoUETDA2p wIp/Jd4mtwc84sz5WW/UVV6HSKdj8J8dv+MM9g06hrKhpqNbUW15J2Y8/7/t fXl7GzfucP+VPwXrvu1Krez4StLGTXYVW0nUWLKjI21320e/sTS21UgjZUZK 4u3mu78AeAw5wzl02HFa+dlN7SF4AARBEAQBGtQ2q03Z1XjYx5qTMaiMdAxE 6xTuPb7rqKBp23rQT+HNF1zipqP+eNsdDrw33SnD/xyGpyFUxZVWzky1fDIe DrsCApXzMe6opLsXUSSqiG2AASkp57OLC9cv6U34LpbwDgbIDHCe9QJh/uJ4 /pPgxUChCRhj4dsRr4KISqKIfV6jKUd4Brs6/CEtd0gxNSHCqizmlbqLkwr9 mRWp4A+TVDQOz/0wZRp3WHZ49IcmWDRXaKCxWaF4RZziHMrxL8k0yooC1VIq rpwlEC007fryuRntHjHkEDF9sLTF0L80pb2Z72PPamPb4JwAW2S41/GpfDft BvrxDTmAyIJHDx5cD4UxExNMVwlG7YmoLvvU2MmAczSSw/7D3bgH3pY69Ad9 6tNsXNTSGqXofh84bvEKIzGakfNhMAL60ItA3DII975tYJO+1gftBBYa9XqH US1GRji0UfSt4HNFNF+vqVCWMyN0hXhTfteXhotEiCsOcTW4BB05JK0FcuRH iNPruRPScE04OXylwuhjN1iK9ulAW+n0AdYYp5iEAP3CCuP5GkzjtKvUAxvw GycEJnWjy9UNGyzOpdY0aS42uEF/yFcM/hLROiSV3jnDmYhAySkEBX+YhJzN tpR+p2DemDBxAMlTEiLceM4vPXy81Id/+LsGP9K/5FljjFiT+NmExRk71IGF aQugybAUAhP+Yt4sjB7qbBq4mJU3rjuBxYYsagUTMw1rTykOVjg1cfgLnsci 5QkTJkD88fksmHogbgnGmY4u7v3wcGtnb/cBC8uAsnDa64UnFV6ZtkXnAtZq F7Y3akAGReWqL5XB+LeMzU6jtS83RDrmwUHD64/fS36i9yh8K+WXX7Rt8bfC dNHHVy7tAB/e8v2udYzqjHpPrO36GJoLOPjD20NlS6D2WHHgTeBQS5dYpNue uyDSXQIpJbQyE810jvWW7LAjAVvPAfsB0D3U5CAnGKcBKwrk9J2FD5Bm8oOQ QeGiIOAEZSNhAL4cgBSfkb7D/jCaIb7z6AY+539hROZ2YqImgojzZB8Xp9p8 sH4PNHa/K6aXGqAo8aoYTm9SX6KtSPAGPV8fjgNjUwU2BFa9plb0d+v4UWf2 QAn0RrHeLCFtaIzNFinBBqQU6Y1i65UV0lDUvp3N0BzJR4CAnU544LRAOm8I FB/aJIHAmT8DBsiSASEoKwE2NGWLLyatGil8nA0K8LvUcZx3kfOjBRphuryO tQqSdOB1lWaIThp8FDKashxcpcJIv79wxH0EvrQpFL51eDy+eHTbb3lgW83w dcyfhshdSPdhExapPzHe7C8v0Qp3sPPDgzL9Kb88uH9/73v+6acYxE8S4oB/ OjoiEP4HGQ6x/CH/+4zsfHv3RW2yee5C20SCf/6Tq/vtGl4RUzO7Ozs7ZfHl ZYXqal8aVP+h9kWYRx/eV1/QEoAN3ScooMnt+X9t990J8OMneP+xu/+A+3/t 79w/2N3bo/cfewdr/6/byf+45Y2DaX/g9djWcfcl8Gn1BH57eXLcrZ8ed06q bKu2Bf/fhv//C/9/r+++o/9ub9+T7pxhthr1Cm97rCexYf+6pyWNEX/RNY/6 q9d3L/Cv3zbEB5AjEkLmXYFNcKD9GS3G+ybH09vApDAD2MDCbkT6GDkEUKe0 BuT49PqYzSYcwHQ8GvS0D73JDJ/3hVjIvDFhG9wGIgGGg3NMhaP+lnlxVLEH XzAap94Ef8eogGTKHPknJcqRf8ym7oew9anP25HjvRyOz0GqaxjwL7jXaR8D 9xJ1xcCsPA30irInRbwgREMm49EoKbLwGH+SA7D84g7xwBBOFD6ylC1YU+sY 31VCnQi0SKODzYTZc9aexgnv/3q3Lv/3d/ce7jyQ+X/3D/Yo/+fe/tr/d+3/ u/b/Xfv/rv1/1/6/a//ftf/v3/L9X28O398jtHlyx1/aoYp65s9S5AFgulMv kz853wlGfYDpEeC9b1mYjRJj15hJRPkLQCi3PQxMejDIHaKTHxKGA6m/hHkv tkqFr1ph3jqKj6PMX4HMTydgaejkznBSa72QsVsxBrcdQIslVk5uhJv+kyFA il8M/FEUIBJBNqk4eQwSIqF9Cj2U0DiVJbfcSavbyagsvDhyQCSRDiQ9emok EoZK05oX1VNbT5wV7jmR3LsoT+tfgKDMPzEB9RyLGq+Okpi1njYT9YyZiEfE sw0A7z6tfVPgr0iTIBa7GLgt+r3WsH5GcNgjE8vEXCS0mFLKK9vLkr5Ti0lV Kse/CuqY0bgMWpHBIkor7hSptSi8H80vZqfSpdH81GxF/45CkOuh+akVbbdp /o0m6EgNUNTMLx3Lp0iz9Vg3NDb9E3rcmUBtS+/oXRf90mhGvwjeMxBBp6jo uIXbW2Rs0snN/rl1FiFz6KkWLSA5FaGecDqzfo023YkPrh7/1LGgVrd8k4LF town/ZlizM3BcOheOkM3fFSys8nvNLyx9o1uN3jzwuk+7E/61ZtfDC5WHvLm J52LpYd7tF2Di7mPeqTdpvm3yUfSc9z80rF8ijRbj3VDY/uoJ7yu1il5pZaw kULJKaXCc4aRmIQiumo0EGXA41BaGnHeucu2xG/lSMmJtGHv0uWpeVx7h6Xl 806uKFzgK7r5Hjk9fxzYHp/VWzyOZBF+KRXo57cNbqFgfxYK8guG3kMI9e03 DDv6tPOMV6ayrSej0mFYKBumsrDgY9gopaxi768GQ7cI+rami756Boez4qty s1EyoItqSNhUfFLp38ciaQD8dSggYQivunD+q1aOXhS7ozIrviopXH7jkQW7 o60n3PPr8WNWhJ4lAJYXRMuiSf6NB9wLG/kYDk3DkqoeRrAu6cjW4FzZbAO6 dRPbyBTcFLpPWLFeEn8IqGVR5snhVORhnWdwaBzh7tMqjrFIWdtgCCU5fHxH VYjWqZxRgFvARAO2MRHn+xY6UDgi8CELVTbpQqt5yU+GjifcaMPDUKVy0iV1 r9gqV8tHJZYyMbCnPT1tYZqh1yA0a89hgJvQwFaLX/h/TQZH7hP3dbBZZlQp TAXEldUEFfP3MhMaJRzNYJLw998Re2iCvqAzAE5eGO4aPsMIsAxdCMpikNhf Qh9lwUHFKlY84rSNU9YkDm67QJv6KilTSKNMRDm/CcJEuiBGK7Mdyj9SSKeJ RpLjcr3cKM1JlfxEIZocJ6JfsBGAZzuI4M+KxyWBYrFBVTPwg6EieqlC6k7h ppLHZKOGsoW4Odo8D5ocax4kkJI1zzANuUNOQOROtzUdb4VPRoQ7GZqyQWsg 4SM8+lEW/df1x8Kzn2sw4r3aYIqO7RgPOSKZKOhzp1N8pknVyByoOLlbT54Z Yl/bsVX5oSqUn2RaJJuMt9EPMxfjgMqdlCGFw9Z2D63HDmgP4T6Df+nD4F8j GktHUyqS5rXTQa5tVE5gchmxY73MztDGy1eonXhEppNqo0gb46gEWyRGGGaK VJhO++yEfw+pK1IZ8EpltoUgkmsLBSUhBC/VnvPVR7DFFq5AJkD5V4MANBEi 4rs2odZGhTRvyUVtTGGUivpeatBxY4McrLrPOo2jYq9XZnAa1T95PvTUND69 ccoMTqP6J3SYLZNrrPEZPXPL9IyrtLK42HBcQVM0Wr3bv55V2Qv47aTWeM4X kC1bPD6eN9O2F3mY67Ilqbz9ICCzfuc4M6h0vtEjgzUt8KEWqJuZCWdzNaAS p4YtxR+DyHHZjjK2EfAMHNHuo3lyysz0ygwPRbEGR5ktjqxNWgkswuXHqJNd k3vaJp7lRAVOUDUX6Gobq2JU0IPM6wfekVuM0iy10shSa5RdLUwvGZ35UuyB Gr1/9vh97dgbXqOn+dhHnwAVi32LNiX5PBlvZxkPoi72L/Gsjd8by0rw/dxl 6OPFL3ypnxl/69J3t1mF/OWxfOBdco8D3PdE9TLBU20fjugBNjfwYGud0n3u +L0n91JULIRqr8bEkz0Awt4Ur4GpkP/dg55PAVs+fujAw1HKC2C9TuC+c31n uCGJqhoIyrCz0z5Nl+ZQnVIqshlUHNIDdAXJM1NwQcE9Pu7xrATxcPQJ3r4U cn/kjoDrivg3KaW2fEgETJkguAojY+Q/jseaOZQwSvipjNTqi4IRo1cQ4m9V LmWbApAfFEQQhQiiEDz5zmN9VaiykVk4Mkv5wlel/E9VKtzoHxtrXR8X+cw/ Nhe2jhkXlo8j4jIcm1id4ejEh7CPCECsXC7UEEJ+EVkON/j7j3GPPxPnjMWA I8b+dVlblPzJI413fEFc+M7xB1p8AusuuGHfBR3rNqj40ZJIBBmvXq3/u3Jy cnpUFLlFYvI4zrclkXqQw8QzTck0nUJhdERCrkP1hYb2mHHPePVVTlx4/6IV 0hM8kZ1bfvJjn4w3G1C0q7WA77fgE7rRH+of/+Aff9JAxXMNlSRDwfZ6HPjo yGhi0uefz46Nz/SekQrQNhsWiUdZUCSc6yNFbxxZ9LISKfJ8WdRoRorosaMo RA0uUkyvq0Qxp60s1p5RGcQ0X0+ZZSOfI1ZvIoG4qkiGY8FFvR7ySPy759u/ v3Hs33EM9hLEh0SnsFFByTdicB/eYpX491lSwSipAF8b2Us+iBIJ+OGt5BbQ 6iOweE5GWEuJepgSy6KmiRJ+YkVvRJe76AX6U3QpX3SBoe1XdpWXr2OUC5yy rfbpmW3u9O/6HOnf9TnVv4sZspSIWd1Q50z+OAmBjS/Om9gn3/0j8g2O/ZEv fhAyxtFJtdK0cYZZMEssGSWWfNCZwywSfCOm3CwzuCFSZLIDyObw9G/JmZd2 TrFIc3nW4PMu5UK3p7ZiJZkOtWIhVqKSRgfBl6Jd/lLUBHzj6GDeWHklROA8 X4cTkioqvDiIkOKaTFff/zC+/6G+6wjyN7qyhOS2LsZViRDdpiwXpb5WIAbO M7xyCRmac0LBSrmsJdj/5BbXPH3aobxHYRVT5tqroXBvVn+J5mhLPXWmsYM6 e05GTsAzm/MP+Ccgxb/zBG6kfIsgTHTwAEFE8xW+TQ+R4d/MVGp6Qlv42mhg u7wHKUDFw1oeqaB35fbekPCj4bp4eAhTvBWp3jeiAzRttY+OKDmmwd4iMbzo RhFSwB8mNUV2EKMxvhjSmhM7r73BlxWzOX3hpDVKaoC9yUbTbNJYZGltkv5g b5PnvNNb5UsyrTmhUlgbRJVLtkfr9wkT7xmTmhNKWlJrP2mt/aFa+ymltZ9S Wgs5hguLJ2zv/v2UtpI5hlRArTGQL08es+Iu+/FHtndQSmmTNMekNulmH1sl 43uxqImob9guT3rP/vc/posu0H3jn/Zk/kOmF3zLDsIZYVvs+7SBCk3WPlTF iyAjdcSh0d3ENpsi0aAUP7GM16FI8OBgiFb5wTQUAVYJEFqrQ11bkwgysa59 xUcqiw3QkAGJDaA9tRBX5i0rPrEJtNIW4kq/bYUntiFFreUAYKzppAbk2jSP TuGGm1DnJ7POH6rOHykdGdMlt2ttq06oBgvNqEZ7ubaPJ1SjtWRUFFu9vs0n 1NYnZiTmZOQngfPdXatinLNoFcvE8Lo6UOIZEpNaFZu/1mzsmGZpWtYK27al Ho3aHTdSLc7hEUI/tohdn5pdzVVB9Zc2nHYrJ6zWOOu0Gb8gAnF1dsYd21VG zbozwef54uH+dCycxcngiF94QTSrZrKpXOhM1rzy0VAGKt20zCpvDyYVJm5+ EqZcV3eppXuxT//Z+b3Es2XqV7W1RvyudgZC9tyRYQ020XBzSYYa7RpRT9Wq xCtmoMxq3LgIprczXwcy3NdmWb8Ohn9+LyNz8ithnSd+L7MR+yfb3GSP2OZ4 Nt0syWNal1uggELCskS+LEaa5wQcZE5zzDorkpci3nrq0gS/d8zMCd3wm7vR ofyLh0GT+eMLBdPxjXOEGUqQiWHHcoMm+cqvqOfWWVbXER/7eL9JXejRCzP6 0D2083cQRmzMaL6zYPt52o464j+y8Jm6eJVNJZOMR2/kPJvWqe7dnx8jFe0x EynD/X8pnMKIkdlYme8GbN3OxeQqoGPu1RU6Aj1KhBGvHh4lrJPkJiKPTR7Z FkFy7U5GefzNyCP7rGYCJCIYe7aRCBJ9tpGLg+JbSkTDEG5+fDsRsZeu6fms dOzbtm/Mo3w78yjcmiM3yKOFtuORZT8e5diQ6ze6I9dzb8n6iO/qllxfTLbX 88j2esaSi3lVLsjmNi5HPZSeGUgNlOOwnWCgt/pBSHtdflYuhDlH4P8i1zvy 75ITKmbSmBtTlPM7MrzOhFIA6k7eTK/6/vbQ9dQKg8Kv2QEdP9AsQR9+ZAd4 jLkc4ytun85RMPLtMP0DXjHhmNrNSu1kf6+IXlq7xKD66gBS49qAZmAh8PvK x1/PYLnRo5CwRXz18TsvJy43Xzp9xaQjWrXR6jSrxaPysxKO/Ut0sWV/sliX z0qHTI2dfZQZJTIakjXCJxdykZgjpfWi3qnq6eRFszuI9FOnH75okUjrrViX iHjuojVG8wEyEOOKFQrFTQGhEVOSLV6Ffad1OhnaW2CTYdhO2ahQStVBMOJ+ 4lqXz3QyMam8XBqVsIklcKm8TEem2jjOwAUglkRFa2FhTDBrQRYi8Wl5HEMl YV5Sus2iIL2uyuQHgFmaIbQ2luAITKaQilDLxhEHyQNrLT+7rYzJ7cw5pM7y Q+pkDKk+55Dqyw+pnjEktLllrACKQTvPAqDMDens0q60LaTY3dNZBGDm6pbS YaR222xlrLlma8kFFzaw8Iw1W1lIZMosBJmLdJRiJV1UNrPkZHM+IdnM6i9b MjfnFczNLCw7NsbEW6oHy/TbsXJm4aNK2s1721C6LKhUoHw9woCn6smYaO8f nX/Q65ONqM89b/3jiszZnTbGRqlR/J/QdI3xq3iuCBGfXbhBnl+zBps4GEsw SDg/WL2hBU7cJu3xc4Pymhv57LvHzNOOLCfRmMT0wJb7+N4zHKo30hyqpeOP N6VWNFcCDH2tvCZkNGR+OKD+nvCr5Zj/3e4hf2DIJCBdQtNxxearR289oC9s q2A8EhYuNLplAuD02w/dJXsj3f2bTvL8LBY+QgdS/Odg5/dlbPzBxAdikbNl mW0+rRxLP+AKMDsTa8I4igIkIiWemmjfTYs8IZ6KarLT+oLI5rCgJKFbXxTf 0RwIJ7vbsyALXR1ZMqqEeHIbSyaKKLeqAsNc+AnbjUJsNcKoXjlqnhqSaMIe 3n+k0hUJT9qY5Bl1BYT0tU28G5zHCS/JpzLFw05JsDMa95nvTtB9HwPKD96Z l31i4BMO0iUQ910sCEE49FSbocXfWFhRkhBOw/hj5BU4PbI2gGIG9B2r8+nN UIonIPsLEerjhkmNIxyentvFQg6OggaTSA809qwc73DIfIkeu0NSFPDVqnQS ltkOZSIm8VKIXwYNzgfDwfSaB5N0VWB7+Xhn24Jyn/fRxT7mnX2x8QfSBsjt jYxwfF6NuFiX4q8IyKiIT2FoNnnsg+9IH1CvKKUiaLuDKfN6o7JWX4gdXavb KPAnlBmj+1K3k3LbqRwTFAUe6RtPO8+Lxc0rfFfMi76elZnnun0u58M6ZaxB nWNb332HaD5We98vreqrxim1SPiTWrMUzjFD9seoNKiFT1L4FqjeoVi4Iny/ 0k33C9GebkRebmCOqdgnJ/LegpJFCR1Q+9SPPPmgPByRtx6YZSn2WORKrX21 jh7AOuKJAsVmYFsEAJC+W0g92/cSFkQg1gBs5MobVl24dRovG6c/NxRvAdCT GFD7tF2hxVHwvVCRphxc8JGnMsay777DvzlP84Z0+n7zDYyR/ah9EzJJ9Bvn QuYrFqRFjLPGw73oEqqMqEdWiRBnzWr99HU1As1VniSuttxW0hkR1gMx946o rbhaNPdRJ8FHruqL1R3Y1jZI3ciY84+H6UMxB/KRSygMv2BvJhYYz9yckSfd KeYNMtPibIeWfnrD6AzhtNu/xreMGGZ4MpGPFbU7VBTh2FTXbCqHc7gU5PwM p/J0YwoZICv8J+2eRkghcVkTagHixdZjFtbH1Niaz2dkEdP7LhP40HrnxunW cqdaSlPLWsZAUOQvRwBpGzhxS7V+1v5V5xdcQYZUM9YX4sEfuzTR56AZed0k VqkVQryI0fF5+Ig1XfR2pbgUNH0YmYLnZ7Nq5IgdSasPF5gMjQDnePez8vc9 EWxa+XFZABM7Qe2FhFFkdNoW+LqJyZfSd76Rn7ntkaHFeCqyKhvS0WnjuIZB hFvRBd/rklCAXXL2No9+Kq0n33zDfcs1RVnc1WoBXwTT6/vHKFAg4oleq3Jk vtErmcs7unpXQA4MB4PC0TjIUkipp8/xu+XmHWPFgDTJc+s+m2kyMLxej8jE qD+o9TYb91HzghY+iptSo8gLtE2esjzahC42ZwpHQzUI3grpCxhI5aI4ksL6 uHOGBYbmHV75F3SrOloLqc5Z5fiAOwdoFgqjVe5k8H1Ss7glcziKD8bv9E28 SEmPgpiUpF1FxQESkzbSl7SYfLyiS5t/3/3j7nAADPbQPsl/70msvEydQ+fN 3ZnCysusVbye38j88rSNPDeECkMyct5QwJL+bDIc9ER4BM2wkcAMQT+XF5U8 rvHzsYUtNuKTMEoyUWSwxySVY1rHFn6hLN4bGxmTuyr6O5giVM2AiN1C5wuM ZsYDVPCM53AgmDj+NIH2s35+D7YYufOvsc7xbZKmvhLSjG6HNPVbJI1QuBIQ hv8nXwwGfi+ncLYIY6m1aqldccn4vRykCiSknXyA0uchiXdWJ3zp+pyz+Anm R5KxkaaY98ZzpjwI1NZu0prHL/aZ3t7epjl953Qp85IzER6pF2W8eE7YiLnZ VEhA2/xDc5jObFp05PpBYkgTlTD2XGBoGafr+JcEhjG+SmgJoxtmbh6CYmRS Z1KKSXs+JR69iv2OfZ8k9+0jyRwBvxREBOOsan6HjxfKV1yf6WhtYXMyUUro ItpDRDnJ09dc0lq8Fk5UifyVsXK1mSaQkg/rN6oRVps3eKrLkCJKiNyaKkeW t+RJQIvMnNOQKQ/mZHO8dsgxg1GKJ00vj/Ww3GTYVvOKNGtTtg8CZTEeyIzt SXp0olgnb6JJkEt3sc1h7hnzcKJyyqO7IetuUdSR33Sq+mU/FN/ASptDFuKo 7+5qIdfDtB3kLpK0mW1wuKv0brYQBTux7bZ+Ln3wlsPrfwrzTrMVpzUfDfun JLofoM3/0YKbvKW14K3Wmtz8jc4e6/QPDvVS6+3Z39nYRN7bUDOJ7e7gGsch r3KN38YiX8GVzhnb3z2kiON45VqpbKlH3FviwShAFTCwKOg1nQ6/VyyOJ9NS 4jNL9AWGes45HEiv8Nlp3ltwKVzIaHiOK242k/5lFOOPR9TnMQzLUEjUsTqM iXNiYrzSc9/0f6FYOKb/S/AWT7DYfuQ2MmxbXW5pdqatJyrGYsKlKIV9lEys ZUzSfRhUAjzj+nR/95GaKnzzxwW7nB3NrZ0/Viyi+ayfPlHJd3MZTgqJwj/p cSmmTz1TTgsRhwUtgh9JNrvfQ6yJQqYLgyktE900xMICDIVTjX5xFZ9dERyz YH/BYEhzdJahwMGlBBQ+Gow4ChI2miROkSkRpaAIUzsYYLb4DYSw+a6HW700 zy2d5ZQ+LIoOHjHJpzmK+QVEQtVmRsMpzYrTl720k14sT9Ki9IFZqlQna5k+ 4oMdKn1+Wms8x0yUGG+xesShMeNvBP0c4PI6LncFE5U8AzIok6NChJYHu5k1 zGk92MtRYS5wfYJygRvD2dcq8LAesSHYQSKkPrACRYhlB4qS9L4VKsILdiCD v+4noBa2c8YewIxTQtJoF5EirZbcaVD2Z20ul97Yd9E9Zt7tJflRmFUiLTA0 UlCSrk7mHFhBtwSE4YOtg20uOlZ/NUO1PMU7kU/x4nGewxsmDrurghPp+O2F +GnLYl4Mk0yWK8Hx+QpxbC3Kb0H/xvCrrBA/TQ7Mi2GKh8jyOB6tEMcFBRpf iTeIY32VfBruK3NzaqJRegU4vlghjp0lkJzdKJa1ZbHcl1iGKs68GCbZ9laA 3k+rRG/htZhkRVoJii9XhuI3ZF16xT//8gspZur4EZbs/wAVGl1LiVDm9DT1 UYjvqW4CQMEbYxDABFJeDGfBVaIXs9VK42FCqNQ3pzohIieuxTaY8Ww6yfBC zGuuyG2eSD21J6fzSD3K5zyii+iCiefziFFKswrgCJK8+k2bWJI9gfT+iNkp NofC3zdztpL9fu/IdKVOSDxcZcqMpBtpMEy4SdP7Jk35+I6OMMHcwL/OXLeS xtNeb4GFq70UItvnEzNvh3g/GxeLp1IsWuRiimBMefEVpzBP08lfNOWiqm7j 07Hi79OyjLSFFCOt+X4zOmVa8F7DRp4xY/JB//yG8dD+TTdzwv6dLYhC43Zk hnZ0cohpXMpkfVxr2czWD6LyY1nTdShhvNuSLxtz2Y8T7MLabdyi8ipjf8m8 rZB2CnMlUAIodhvb08r3J9AxHhq6k36JtS3jM+dZoQOPmEq/uwomN3F55bzJ dXuVdnmVONE55vk2tQfb7AjBuR2/YJzNttPnZhXCk9QSNQF5Lnrm3N1jOMcF Hi4aKeTSMf7rirgcmvI8GgPpJTdxA2bO5UJWXCFY5rbjpllsM+3kkXFrt3ML DD3J1W3O0T/7h9wiFlMI86zDHKT5PrI8l6DMIkfSFAPnAoMPD2OLjH6BI5pl +MdLzqsV6fnFrkmahYz1nC7zm+tTDPOJ6M1jXLrJFZNMwkVtrJyKC1lZU+yp nzEhl6Ljisj44vMn44J3jJyMi9wyptwnflZk/CGixCyjC9zGJVjS2Be7EBGH h5u/EkkZ9hIUv5WrjhRuyfKyQFPlbDbIVCHviC3Y4rIxrx2YBz+Mnhy0N7CL LFLhg6WsaLRv2JOqhfZhjf4p1rL+IFjKJ9fueptkelzEqLF7mMsfN9PukWzo XakzrvJ/M2ZrIX8kOT13Zn0kWpQXXDfZ9sJ5F4qd9IaXnAUk46iUOT13/e7x 7kwGDZDNdZuFNP5Ed1kJUQQNeunR8Ze9jdIUQUucBcudTM4rKuUEG+H6xsIy 6c4aHzUVWxq144ZvlUtxQaonqPfaBKcv00RBmuHvn58h5zV34tOEhHVfyPvM IMJx+1bvlEWZLrj2eneX63JcrRTUw0p10guB/CCZr26Jrea2qN9dHlvQoi25 bKEN3T51SROSYgBf6Ng/99actDgXMhmHy3MBm/HShDu+A4TLdRDudLZEqPgM 7vv8tP3lnaWM583BIjNzoM+MXddMo3t+FVOSPapfPr5ZX6nFXKVWppum71y5 9dDYLKVe+6f5TNGsfbY+U4u5TEWdfo23bgtI7PkNn5+3l1SGIpRuQuLG1lwS T08FnnigXsbbZm5nGxvfLKMkLWJ5Xpx3Eg5ci81ywiFKn7Nbn50HNkd9Eo34 RXdWsxvSaU6ERMzvmuaNYeJpaubh/FQj7h2hWrIfWToJV72f3J19w0qrhX1/ Vn1Q+uQHIit5FnahWfVx6JMfe5K4ZxneubuXfjdw5zc3xR9aKd5cnOA3/1Y8 c/gLGf/Uarqjtj8LQZ6qE97N+sJ+WlfY3PFnMvmitbgcuWvP529HHFupuKgL FNHx7gVa+ISUXNQnj3PknXsm/wkp2VmKlHfwMf7t0PJ7++65hK6+Ym/0TGd0 OwqLuhcKDWYlKNSXQ2ExN8PP3dq2jL9jEh2XYIVFrE9pwRySWCHE4QdpPjMM DSgILFYGmf23CAWzdGOa76KYc/2kBL8ZFxBZWY55AFEtCAOfd+1eAJPOD5VA qj3vUngIBaZdDCTcThtTbSFTuthKp8ytv6GxIZAutNIRWERmLb7oF7V6m1mm DQ8+i6H06PQ19GJkT8203R2FsSgXmoI0S0PGDPwN7lPzOR0nZ6afX0Gxz9ES 62TFzwgTib2Q+rYs5RZj+oW9UrnkXO37vc+NoPd34gRNdD7N2J8/h0gqi3oH JM/E6rxateuh3I4CtvkzMZrPWwDn8Y47C6RMxcpjrwCBd60arbpwzH1zJogr rs8Wp6wfLETY+Z6BhF4sO3EvltSLzYVmJ4Pemfbw9PdTStT/dSzjfwtf17Td bzFHWBtzLXJXpE4tnw1DqagXGucsyhqJoqOgZSBS3xKPTXOdm3IfnCgdQKbW s2fZNenoxLgpIrfOM0/gR8kEAhXnnZtlVsgY8sKuSbTL3/KbWDsCSwz/szIS pkWBvXF/vWwfvBzXmGk7e5Yw1myaEabYx0D5SxrBPokFLDryLNNLuopytyww t2VpmdOaYiH5gtyycjPKjd12zc2Hi1lDbsQU8gmJcmASRfSZ5wx8EwfguxJJ 1EKYhTSIRdWHpa6W4kNfdOB/R8XhFhSEZdSA2HqlQwDTg4+mvn/nq7Y3fpf/ SGbaILMuCCNB2oXe8/GWQ4HG6USvFOawQq3aBJUnUslN2aGWko/JvHjfpHHC uTCFvrd3JowMdRFTxl22Y1jMCZr5ItXKkUNHuB9VnBpLKvBr19u/guttbP2n eualidnVBh28I+53c6+rzsIEXHX0y8+GgvIVSeTGiXSi7dw60cC7I1pRbFc3 RfrtalBx2s63wXOq3t4Wn8ALc78El9zwlz3Zxgm1dNjFtVUuj1UuTnihW/O8 LsmkXZ9DbOeQkLAPbRy9gMVTMfIdsHkm5ICdk+XilFnM7MkpczcMnzdFmcX0 L06Zz1ADuykyLkHFz+8gcFNETH96l65xrTb2+OfMiceL8uEqczJ8NgT8Pq6e LPik5pN4TdiGv/jg11cfd+7q44e4ltdcVMW7XTvul6txSMvjbPGDReFrLH+4 W1ts/xIWWxt3ZJyT8nHH7b4FtoqCFeBx2w+CH+ygBbhy/GvqFWWKB4bTv16x ccB3c4TUukmPeWl4EzbUsPINGQ+MOVgwZSSfiFWbDBebjBxGxVF34rsTx3dJ ug7cd9LCekMWxwe7GokXu3pF+t7Vy1crxTw/yc9bu5jNnuFsD/NwKun64vqW Hco1MZxXRzHYIesyOZkd7qxKkskPGXHdl9Za5hEcdy8harp8WkTtebCny58F fWFJAi1iGc6ejZXbjlMF/EqMBQZJF/Wk5at4AZPyQiQ9/pxImma6SFdCPi/L RaasNCPF3p4QXNFTkOVEWaItJCrRFpdnd+TKNsds3U5UzWUmLL6k97VpIpN+ auYAPinTeQz4mhdKyM6TgI5hQZiJNM7ykz5M1Y5yHEEwTnIFnITHy2r1rFs5 qb2u5sLmjXOHccEpy4XFoD90F8AjRbzdFoqNU+z/7LTRqubNkcZx9hZxhVpo Zz67vZuS1G18mdW9fOwuTvVFQ3elB+fayBecS0fuQEPOcPxis4luFKG5T8dp Hh8wXQjYkBV6h3xW+eEt+xIWhjh4VWonr7rPTmHcRy+KJOt1j7syGw68NyV8 SY+aC24+vvthNJjSp8I5DPYN6hi8ELOvEKth4dPO82JxExYNryDndLPEz9lh U2KVFsLxbW0pXSboa3oR7Hziv4H71huHDdHapm9MRXghKSHGJj4RmHMxhSUG XeMsaTR5jDTBgV+Op2OGoIfwx71v2dYTVsGpKhTQCKEgRs71udsVcBzsKYKR ngV9EndV62ftXzXmKpU0hSwSnybQwtOQgsVnCJpuASXYe1ie4/cB6w3HMNt8 QPEXuyh0M7XEJAxNQwvOJyMsnlfbOg6K7HGKB6ucOK1ZHsnGumCJS6VunDoz ZGmBxVrgq/X+I3YGMOzK8frA5Zf4/d4G06o/Qh7HFobOuTsUjegbDA0LJpET u9aqHClSY32hxxuzDLvSj1oQokmfeC7U0cMJYPaGaYZ5w2nzn8oAWi+WNt44 HCh76HoLkZ4I/0MDN2zxIxA4JG1I20qUtvNs8GkD0OXzw0esNx6NQBmXlj+Q po4/TXYTT/JujmhciXb9bGdl3R050S65tCXfeiB6ENuutE0KxuAO3oGgEXI7 fbsKlj0UFWZAJwD05jkfGUIoapAD1no2+MAmTr8Pi5vYi5rpNM4qx0UplPSD jTqgh81qEtmH2VMSWSoomIln0HeFcOZCWVszfvcqXDJaC3zyhQOcYdTEKmWj Rplt8ShhBb1Vc1xyuWabQaMIPtYb8pW8SoK4kuMP68BQNOjvaBlExxoFQAi7 LopfojF8Cgk7iPjOuNJBXxJyFEWEUOFi7BcPDwUutzsQjXJ8U0NyF7XN9qxa fWnGwCgZelWodFHNwDPoWzL4zec1uCrWOt5uFFsI8LpZbJbYwJOLnPGLQ6Ga EQN7qCPGGgq7TtAOVNi6j1G2g0VT54smYO9d32Wgxky50gFFv/zyC3s2hBXU G3tTfzyklZTNh69qcERrmt1HgutycE5q3RIWW6U6DXO0nb6Aw8bU8k1fEfFF +upZTVNzVO9qjJIncgw2OhGu74/9R3zvC7dCJLldgCx0Qn0lT6iRzdRy9n4Y NfnwrSjldLSAv2Zsw6G/+RTQv9omBIoSqaCiGSBmF3h1NM/eRE3mtgkXqeeS vocZC/kq1SKc4040bYISZshcL0AQ3HR0rFLG/sTc9DYyNi9xsDJhoht6gkgF fj6fDYZ9ZOcpza+QHcWRpHnl5OT0qBhqrgT5LTvApbdnileFMslVTQBiV++v BmjSisjGK6UVDMfAidMrfzy7vIJB+SDg3rvMGRLTwjkDJC1pCMb2w6XtE9su a2MiOipHSnCkHv/O8aUjEjJZmUWb4CKeH5RAe6G/Popx2ERO4CVuP4HHxSpK FUSfy5PxBXPY1XgocE1CwY5AvuHj6RoBT6qN4qh078CM64qzq6tZupAGLgax WAr33QVYRFcmkmcoYYLyIYgT0h8LHCSVmWI/QzKg0PwyYeZKhzczA3iKA+Z5 tJFCYV3A/6AJeNuTERTUeS5fFnoykib4PdSvg7eYTfftHp7lQfz3vOk8gh6a yLchvN3LCbe7VD5OGD5OZtgK22Ja37k2nGnXYf/7H7NKdsPcw9fZ62rzKewt xcbz17jHlFlxk2b5EWugoikPSa/bxUppe3sb/tsqbe3y0sdfz3iB+KWFv2yS um3pvqwPsWyMJLT/gHrTvQi1nUrvjTd+P3T7lyiLh/LsFrBzd/redT3ePXO8 Pg1oa3ebDxv4cnrlMs99TxYjz/0wRZ05QGu113O3Wsdb3mx07voo8hBSaNM+ NTVyHRzuYApyP8B+qRGtb9R2sZ9t1nRHsPHqY9OK2YU/HmHzVF+/MBZa+zar TdFmpfaZcxwJttiHX3vOLHBJJnvUgOv4wwEMMXCHbm+Kun/l6CWi5fBHSOq0 T8YwseMlHk8+8OPJl1w44urW9NofbfxjO2EafKfZjgPEFoghiQKjxA4ZSGYu RIpf94G5v+6XNk2NW28uDPbarNZPX1cTDIdJeTWIgzoT0KxcmuOBtyUZgDk6 Y8GUY3kQmmojFi0nfl8euU3XJIlQbHpXbu9NGRoGlInDiB4wm+LKBKbYd7d0 pgiQbQVjc44xB70Fg1aDvRpcXkErbDbZmo63ABcWvnDts9axYALUUDRxghIg lCcAAz+hsNAhjYmNA+4ZTeYXKoDLLhsjD7/dSxIuonz3yWOE4nVQwuBfKSJH G31Zx3IBuUPUb0oXj6kpemhREx5TOn3sbe0KYottH+tjA+2rkP9xkXvjKS5w WAo4gapxLgrY4AIFznsn4JWlRIA5R2FwLRb5NrRKl2wkoQzJNRA1MQUzv6Qq FJRVS4gBU9fgy0ijWylyNE2ZSIkYTAPidTGeAWPiKg9R2oy0fajuXyS1pfrJ B14jCgB22OC1O5WUiiwTfi9XZpPZFOEBwnd1VL/Ur7o4GuaNlWHl8j+8Fbac fPl8SL/T0KLKSr/TFtCXxlITxx1iLN+djP2pFTWgDX4eOR7QduR6U8FZliPg azgCgr6AY1KXUoxT9tGCx/527mP/Q92LPF0pzDA+r1opRBXWo4MpNwgMXY/0 4F36d6/MVUTbZetNKI4wnHwKIQxTltLJiJewe+zAVPq0Bg0RPYnJaB3yiXE/ dwP2iOY89oh8SmwUnwQbhdpzdKmbsNODSrftbhtSM/hHQNohr+t+mIBm5faN BpA7gKXlZoW1hZKg9mq5WWtBJoLoIGjnlrs2Z9atsKaS4oHrgkIBcgB2irgk t8jjT6Gscznz4tGq2ag1HxutDwgrOSDkOB7wxYhnhJwnhCXOB/HjwUKHA+vR oGSqeOJwEFmp/P5ZadvasUBSLufJYIKlmhzOPDbw8/8Od0zALeEJ25URD0Hf FBvE82rb2GRw8+BuN6jtI6BNJ0+WHbIKCYVQ3Q5lhNw/o5pzqMy9UMqcYR8l LT9p1OGwjXFjFZD69F+LmM+BBz9b+LKJCFraKSKCHqkHcSQjWHI0lYmP7ztq 51FiQpzyApuaJyvAyg3GI7UIyrDohUQJpRrsRVMJL4UArmhPrXa+Xkhz9v4h lWZZRe1I8pjheNejse+WtgXEPfqvtKdazwdAndjBIGUacp4MqFVO4CiFuVFb yBHNzehHi27D0eDCyaYjma5J3AbMTwmRMwIeE2KHBNs5AX5gnYZ/5Dw3SLTk WeG774hffyS+ExfMYtUrdzZpsM+9lj7TxQQb+elLRkYMtMPMesBCF7OhYdKQ uyts4OOpyw0rG5zJ9UUURLdLUIrkHi6WgNg4N9Qi1FdSSywJtb7Dy2ZLsMN8 S+fLyNLJ3LYKBfvWFa4NGyt9+TgPL/G66QfKj2k3dtzp6+SRsi9le0FuxOUj ijnhDhlq1I/U2XhsnIELUe+cnu/21co1vqlLHAuGPyv18qPy1tODWWqN6mMW 2v57GDHsbj0XOHN4LQfvnIMyRpKbV0AmBnE/nrgeKO6g/sXxCdX56Mh3E/Ti X/SYGJk+iynegxrS6e6JiZ6F8QLhl2jtVbo0asm2zrbZw/1HuA/Rra/LvmEd cthpVl91oHb0XY9wI0+wIszogDHHE/Q0B/KZlt45Sap37B7kFqzqi2M1WiVW oxxY1ZOxOrDMVe5kWLOb84UHreB8FlwbF//xKw/dwWmGPtymMOauQBF359DF WXcLy8zebSFWfS5ije4SsUYJxBqthlgTWi71qOdqsvPQqH97Dz3z+JrWo66H EddWjRpZAQKQEp38lJjdMUrYfTA7USdM9ZZgZx4aKSLtA5Ho+RpGjoGBVl9X RQEPjsMD40TKDkRqORmnIw4go6iph6cxEDOPUrQwGoVNL7dbvekZljv/E3Cx JRivuARRxTkmldWW+LknJuF5tVFtVk4YYNdosxeVxvFJrfGcEBUQLZR79wA9 D61WMNQPKOuwpOrhwFE59/E+6/1gesX+DcLQpTNiMHF7g4sBGV7Zq+293d0d fhhGAKffhwLQvDaErTRw3pDVC6h7PhgOpteGQBU0BJoh2QvFby9mXq8UobeN 1CXuQwI1emOvH62BdORyvcsx+w+ndQMPDdXW7//BbbTRqf8OPP0n6cnhOzoY nXoOBFAYA+Tbe4XCn6J3VJIwvAd/ucc+lnXQyksbrPPGAowMGIOlCDs20GjD l97Yd/HtmgW82Yo3jGGULIC28eKjdityGEchYxAI/G+uLYtqLQuWgRXJpoUc vgWQ/FZjoKhRW4DJ3BIfAHCGBbhjh54lgZuozWxY1U2YkR1z2zRgXB4LcLt7 dCSA+ctRC4SkUArIy0pWI41mFoRYLMkgpKYamF0MZ8EVPbm0kh+OJKSDpTVK 4VpQUedQOsVQxAwH0AHo4ik1W2epHchHuqqLRDie3SoNRgZQzwOUMayOpIzG cOLcYeW7KPQoBbqjZkq1nTBH9RjkKAFSbq06rNxPNXD8vxK/uPufccGYJoLH s+mEhyrKJYVD8HyCOE22LimK02HnaTkujkM0ffcPG5vNg2YzP2xcHqdBx0Vs GnRnTvAbk8hpvWoi2ZyJaa/3t5fPGVDzymKTwFpQw7WAXk5AR5AyxLI8sGUo xt48QllB55PJHDq3eqzAra1HpTKHzqkiS+C8SrI3l1Dm0LkUZIFjPhWZA+dW ksUwcqvJHP72FWVJg7WqvDpRbJJW06mDSX4JLZfJWkDfvgat7GeZWnR/EOSW 1xlasa3pvOI6BM8lrm9YiU4bylqHvkUdGidirUFHGHNt4/gLSGj9BiNTSFMI /RuS0tT2HGJawueR0xI8n14dQudUrEPKrM0dn1xU00ysZfWNWTtEGo21Mn07 1o788nngzSWeJXROo8dc4jkEz2f0mEM4K+DcRo+5RDOHzmf04DjmNHoQcH6j Bx9GfqMHwX8Co4egwdro8akkslwPn0Qgm9zKx2E1zfx9tOm8qrRIFpfz0lAm D8unSovkzHk1aZXLOZcizdM+5tSjZYLLvGq0Sp68Wi1aIun/TZVohX+WnDbA PzslWow7n8w2qsho4p9OraaVsmIhbjQu09+t1eyY5M4ptecQ2XPI63mE9RyS Or+YnktG35CAvinpLJOl55LNKj/9XbRvfIYadH5Z/An15znlrl6JQgzkFMJr CZxTi9ad4rPsHXMI5DD/bi5rxzxCWUHns3XkF8xhfviclo55hDMB57NzzCGc CTa/lWMu8czBP4GNI5/q/BkKaDFdd9/EsZCQltXmEdOCJdeCOltQ8yheWRqz SEC78gtDlZcvp96sspLm0Zx5fsgbcOnQUnlmi2iZZCOP9szTPucR0WEs9Xz6 s4y1llODVgF7P1MdOpZgMF1eRzL4pYtuM2lchhCPZdXLqXLLPGJl1tP+yjaE mFnVPpkyHskPv0IziGDltRVEF+gbHw/lE8y2f43RJtwPbm82dZnD+GN/CiQ2 COT3PhtcIDRjWyLm5mA4dC+dIStS/CD40HMwUASvdHHB44kNrxlfpBS5QNbG UB7eGKPV9Qf41DcsCsKPFHHNn7kbKtAnBTrSAHhkW4d6vHCGgcvjm+LzTSrv j10KDXqFKYEAeINCaeJj9oDtbIt26X0oYcwu3WmIb1kvUU1SrqRgMvaCwfnQ RboJppVPTVUywwEGWbs2g1kOvOkGtNjFPuzveUVOisFl2tNefKbK5n6myhKf qW4UsCmMI66/VhXP+unb7/+BIf2+jWDQGDaTAxrBRFAB3r4eGgDDCJ22qhRG 6GnnOYYRAo6g7Gyuj2932dcBxdejwAjw+5ZkJIpAiPGb6NVwQH2VOVxgDqOU nS2eAqjwBDEcKxHcGqNISnJRKMH4qGGRVX+pHuHIOc8gl/FBfx1slo3hiREn D1LNZpgWOj7IhN777tC5Tu08rW8ZDBaD4KgQA8fukIculAtAhJm9hK8e55wN Pf5un8Pjq2uMTzjwKKqkqi2ndYtHtoBK21gXlmZ5g4JoctGDnyuYsFF8wQVn ZNnAIfAWcOkriTUc0tt6UPOQCrzPYJu1+C8ionbP8UQ4ZSXRtHiIQC3K+xpK l4CekgdvBpNJcvpOGRdl4aVslAAs1MYp0We61oC5xnm+HE8lQc21YWM323Sr 8FoDj/r6J9tkW3xOgHCb7BHb3OQsgRuISJJR4rEFA3P5ZuceKwTQ7QAjhcC/ h/QnDxxCoUawh1jcGQDEMKIyTc6XxmgxEgnnI/wriMcYPolyiqAVZ5iZNx0M MUEL8ME/piHvYOwVwTCxOTa6S0oLaJvAMGrO2+4VqB/dKetz5N4KWYz9q2x+ EkWMEMdUqMmj8eSa8OjNfN/1piY+YkEOxz34NPbEihhNptcqELwOj1HAXctq UouFrztoiCfMdAJM3MWz2DhsOAgoJBpJGlg4olZ8ARUiKwjG5GDIVNWC6q/u +pcUGndEIa9cWKE0RdbRk0oxwLjdHEUML4e5wxwQNDBmUDIiI5NhN4nLao1a u/gNZTLV/qYJwW8ibhvOCA8FpgXzojkQIyEUKJYrRpPgjEDfBNVFhC7qwojT xmeeBqA1HWNXbEu1IkLtYMRPapAC7cTi69DCVPqEiAhCHdJ/cVXKEHICPRGk ENc3LdyAB4nTU4SaS7MfLkoRRM6IwM6nEYceYMh5mA/Xp40wyiogrmBr8JAJ whjGGmW32QTj//rvsDKWjf2+62+bZD1rVo1R6RQuaVHVEVkteyhfXRjtUAmL FmdsubvhBhFcjWfDvrFBEGsNLoSg7V1hANogcS+AJm9sQ/hEAhlQ6ndDDgjJ 507FwibS0G4uZxq3zffOgLgA9TjHIB/oAM4Et2pa+yDGNizrHXoj8XaNKrma jkTCh7lQk8nuEQSR2FCjMBYLbq40OlIfaLCkxnxNYbVxd03eUPlXT9endBCM 2Eu/SAqbkkGjb4SXP258sfCPd9mlxu7JX7avvlj1z+7OzoODA/YFY7s7Bw/x v/sP93bwv/Tz8GDvAP7d27+/d/Bwfx9+39178GD/C7bzxS38oCHKZ+yLq/Pz VLieMw2++Ov98DWKe5c/uLyCg1+vxPZ2dna24J9d9tS9dEegSh6NR5MZbvqV IBj3BsjHoAYMh4wq0TkXxDFfdmyD0pv0QVD7g3OumVOIVNiYg/HF9D2FXYJF 3R/3Zhix0lEHdNQPUFcdz/yeK0/h5wPP8a9RPIyA9Sm2E0gK/C8GXx2N+4ML FQUMm564vgjqOvHH7wZ9lx/8pey4GA+H4/e4eiPq+8idPpLD392OYBDwcMo0 rt64j1tOZPwjYCS0GDgirwiF7uTGCqghyQvHikGPbA9ADanoRLQgc5Qwit7Q wfD2RNy9+MigQ41GciCAfH/Wc8OxhKMQo1pmLDIQNG8pNpP3gDxj0sHgyO/6 A5T1ajZoCrFhHQ1Cbp8zldN/h5pBgF2G9bEDAKStAlTAGfAczoLQKQ32EsMi SkAnE1AvIphoMbCxXTXxlP+Gkw6DXfeGs76byrZ9OEsNxxOeRUcsF76iYiuG aguzFcd77AdqxRyQ2s08Z0T4pKw8xDrajJYCSCA/o+C3Y1C2+1BODAt4QZOu xA+P4j5l8haJAvQFKtaXaEyEUOtB1QEuPh8XmMeXGgUdV2i0X9RarHX6rP1z pVlllcYxOz496tSrDdg8a6cNBqVnzdPXtePqMXv6K3tafV6tn7bZ0Wn9rNOu Nlml1To9qmHQM2wN69faLShutJu1p532abPF/u//Ki1o5x//oOJK41dW/QW0 vVaLnTZZrX52UoO2oftmpdGuVVtkNqg1jk46x7UGHI6hFdaALk9q9VobINun ZRh11VKTnT5j9Wrz6AX8WXlaO6m1f8Uusb1ntXYDe3wGXVbYWaXZrh11TipN dtZpnoHCwBD741rr6KRSq1ePtxmMAHoV0e1aL0A/k7gTt8TRJ2SiqEMdGHfl 6UmV9wy4H9ea1aN2GdoXvwl0gcIw6pMya51VoUX4pfpLFVCsNH8tY9vQbguj xwKmlRN2XKlXnkOnxTih6Lys0Qqm76jTrOKUIoFanaetdq0No2fPT0+Padyt avN17ajaOmQnpy0iY6cFmhPauWl4AAKtAA0BAn5/2mnViJq1BtCg2TlDTimx F6c/V9GIf1SB2sc02cBAiDNM12nzV2iXj03MTZn9/KIKRU2kNZGtgoTBwJNH bR0MugRqtjVksZ1G9flJ7Xm1cVRFgFNs6Odaq1qCqazB+J5jq9j5z5VfMewj YoVsA2Pjv2p8T0jiVLPaM1Y5fl3D8Qt44I5WTTATke/ohaC+jGb4/2r9RyxU x8rvYDvaw0159x78b+8B291/dLD/aGefgc7Cqh8m7P+Jmg13euk7kyvcFWfc 5AxCwnNBljUq7TralF3/wum5pKx6Alr2W5nBkvcfsRcOCF/21AdxBfrAOf33 XxfjN7Ng+3LU3+67PLDwV3Da8fruhWqnC2N2pqPuFRTB94HnWoqwGherbJMQ BMjtq82NsE7jeVcEPzw9rnbbv55VBeSmDlMXQEenpy9r1cIP3+/sPry/c3CA p46QDjJpuArfDuN2vdkIj0FhG3BghhVcqeOZt0yXIniUmDg+yGJKtoOnyhC8 JcA5aBAD5dclIpUabkHnPAnItdfT9j5ERNxdCCspUYJTNkoK6q9bazw7ZX9S nPbfNgr8F/qVsT/ZJqXA6fZ6mzCub4DeMKjA7c5gzvf3utPriYvxDk1gvLsE 8JzQb1x30nXQeJu/jjfuijsQqJSzDl5k5ulh5Hx4kwtZAPwjL2BO+gHkpJ8X Eg91+WD9XGAXQ+cyyAPJ7/AUm3xUHIOxb8UBWAoaPBoTH+PaoHMwtlcojJzg TTSlGcEV6N9DZPc4w8o1ovGshWWx7VwYU1cSUhuDAsyDcRLCxKF2rNXfBdf3 x34WsngxvCKMqT8T0gTMgzE/3HUmE1LYhewXlhFtOjEotIE+N/qEfwPAIcq6 8WS6rbJYMZnCymeUu2ILc1egpJx1e1eOXyjgJfZ/dn4nopkdjhJ7jNc0KwJZ 0ocKADRUoh8/qvExSQDM0KcDzLypFNpfobI8uNj44m/0o+w/4RZ0y/af3b2d 3X1h/3m4v3N/n9t/dtf2n09l/9n94YeHa/vP2v6ztv+s7T9r+8/a/rO2/9y+ /SdUx8j+s2ux/xzE7D/HyqhA+xWdTlBMgIrjTbn8UaYKdj4c994EpvEnyGn9 IS+x5vicPRuPYCco+uPzf51zibU99i8jBiKJS/eqG56e9I+aUejH4Dq4h2ec YPvqiTzBVCpb6vgi7443lC1HHGIcvLD+U2YpIR/jk1rrRVfkyqRcDz9usU4H OLvJPT4ikFo+GQTeegLAVkBp0sjRJmZZHvgjs0EJJj2c1RBVe1pbEsg2OuDu 5pEFVvUqILU+KXNOtMO63mE0t45spI7dNfS2OtmNdZJbMylBDtsWJHXkOExI fdGh0Q55aGcQlGAyZlu1FO/MhEihtfSrjo2n2TDaEVDxEdU7NjjcLU50aNUx nmK1NTGKLIp69nzV0+dLQlEGQcuAj06PQdAfNdqhIRQX8GtnCF2Si4dKMrTN GmRAIAWWiypUPPYOzgdTdOrAetwHj3Q8cnty0IPoHTW2odtyxagqv8CW1jgt FB6znQ8X9FOOT0an8bJx+nMDgMxq7Du2W45Bt09hF7XB7pU1BPn4uYdHVDJx 5w41Sny+walKstoZCjeSkLoyrQSHAi3scizOK2jKp2xbwn81rCNinsuGeyiX M6rosXfLRk+o54t7A3s1LeCYWROWy7XXu/JBTw+c5KFG66sB56mvx9CJ9k7v +K4tlcIKWEMByuWdNEz7GFN6qRz/yrtAGxZPMXtBCZsxYSxfE2oLNHI8sd2d iJXMYo2VNn6yYMk/cP2MArcXMXSFJn4NGv9kg1EyfGjkP1SVwm+pXWm2fqgb +5ZaF23+2jDxzwR4tPofEoXht8EIVhm+R+LkxpPw9ZRf85hV/ohU2ZoB8MU4 pQYSWVTZJqEVZtjmgkzeLU3gLImPQWItTPpaC++mxUm/BMczqOpS1nfkHJqO WEWUB4eqpjSzXjB3SIdV5c/ND+2R6v6hIVtEelkTiC4QOBz9KhjTlKbNU9DL 24xk6Q4on7QInOno4t4PD7d29nYfMND64ITtuUGgLQF8Jtes/iKr7ZX5JRmo nvSAziHfYUXPqbFrqb5b1Xa3fXRUCDs3SrClQtiDUfayokoOzJJGU5V8b5ag SJZluztGGQj8l7JoL1b0kyw6iBWFo/8+VnZ2LMp2d2JlKA144V60UI7/IFLA Z4qXfR8p06cDetvhm5Y0dRta+Bfrn7/fj2n/f+f4t+//+eD+zn2y/x/sPXy4 f38H7f8Pdx6u7f9r/8+1/X9t/1/b/9f2/7X9f23//xva/0kdm8P+X/0AkgJf RoXWcpAA3I/0tuz8MOa4nV98lFEkUNJgXhjhBonuqFeuZdC0tcE+AkLc52Ys Li+pAQdleQByjkdWUJuddl7+MBn7qAgE16PzMWwhJOfUi3Soho9hi9OxPC0P /utyMUiDU/EYNJvMOyhRJplCAfYplH4R/zhW+JYCAvBvpSLFYIiGW6CWKN4C ZRIvFL+FnWbqj68tQRcUyKVwWcsI5cAtRyrnOFQM5qqIb9ho6vl7OL0hsijH W4lexKgWhCH6fHbRnSIgtai1N8pucJTWok6dgZcQ5iKxBreOxGuoUYp5JgKe z4LrOKgAjNl7abL4Q0JbFA1iD0bubsAsI7rUGgFoDO/SYRTYBpsEiv3HgPmo cBSSDmifgf4859KNYyjYV9I/PjP2SdaoaHQzQ3fEeXpJ6yTWOsiEHK3HOAKN IgQjQ7wNprRCh+ZDUbFq8d/SX8Nh0Dz/90BjXr0BIP38v7e39zD0/9vf2wOw /d3dtf/f+vy/Pv+vz//r8//6/L8+/6/P/3/H8z9Xx+YwABxBBTipC9eJMY9Y KN0A+3SwVg9LEf5n2BhdDN42COTVNJ3EL/A4Lx9YAieLaIfiOC3iSamDNF7A b7Mq+kTw+InnLvynT6EWQVrIo7ywTZDA9obXyz47VRSKmxvk1w10JCRYrsOj wm/o/qTDc2yPq087z7XHoa+7wJXP9Qto/NaG1dzUb55FTELjzllFYtOvm1UE Gf2eGT+eHXeMC2b8BqvAuFnWovhpl8p4ZU8WH6au9sPXbe/wZl8B0NkmLHP9 83HgFsPDIp6Rtre3S6zbBRHvTS+GgzducbfM9kqH6pgTEitkjZjvJpkQ0Hcz yacz8v0NDM8dWgpwhiyfeYiy+Pce2oNmU0sJ/H9qG9EIa/QiBSOnB7zr3gum fce/JB9U6YSK0Hiy/6/rjzHgkw8brrcl/hrBbg0aGGmJI3RS/S/XFnoOUHgw 3eZKMQVPpBd7sDwvnMEQtJhtk605H27UKYJT97gKO0izWqx3G9X282bl7AV/ c8hPn4Ln69U6xSkrmd/+zYNAnbWb5aNKq11u1f4N0uy3jUI9LGBUwrCozKKd 0JfTnyu19v/q3X9Xm6clo30KHgWNUJvyj3grxqhaMjSVrGeO0xLsqky0HF8U o0WlktmuMRx9eFr/YWisPP1TSC17/2htKZntpvaPIdNsM8bC96Fqxp/BZlis yynYVPnzppvwV42cuUGvJ4cnJV43S4csqQ2M9KXaAcJhM3URehbfbKILZr6G KLjkpqIANiQCZ+oNLM2FSzFfHp5bkOFU85yiv/FgqSnDjHJlbJzYUAZ/Lsic YRc0aZljjXFwfKwAUgptXtKWT6fBYDZB3YCLssimKwSzGBv375tqXpC0pfJA i61yu1QQ8GSDK35TbJW2nky7X30F/LFTitZqtU/PzFqg/0z0WrEqTfTNb0b6 QvtFpLPfKL4hPVCFHfxbXoSDh9J7cHB+A6eGr77qosW5zKA01lGtBeqn2Y1w GDXHF633rNM4KrbLjZKUDFoUu4ISF7JvcbnwDjarkiqUr85JrlAgQYzkNxl6 gGTpUJXowe2obwxuxydok33VZpuo8g0wjHKJav2mBSvFyIVRuzYOoiyC1H/1 VYPHEMeaWHEy/IDxCI0QBJyFpCyinT0wWKhdqZ286sJJo/lrMVyH4ZJ82x0O vDfITmaNF9XKcVjhbZnZK/N4q4fGioXu6mftX4uvSrJ38WcEihhWAYm/IjBw RqtWjl4Uz8oKUPtUxrFHq8DBCqP+vSrXZY3wi7UCKJrVZrv7tIotF5+G9WIF 1uoiiuOrWD38I7HTs2r1JSJf1EkEH0rsn1y9eSTRrTVbbSqJNoFRSl+FLIsL rWjwbVwyd0eMh7E8lDA6m18UvzQnrCRipRAg1dXH9KoUthIhNOuOyozQPoxE VcDfu6PDgjHsj5Hd5lX36KRaaerYUeBYrQ0rcqBtw797h3HcoM/dlOHzQKYI E0Z8DSkETaq6jeov7SL1pNAjmEhEUIAoHWoNYOdyZPTtozY2bQEg0RWQDLAK Uls+ktDCdmatc9zDmBYaOXOdI1SZ2SvH1nkY2/cVqmAJa1gPc/qq3CoVbAuE tQQxI/UkF8rW42JEBevNvwxo0+8GSyyDYJ5lEKQtgyBtGYTxS5/hBqjDRZaC Db9wi9IAOTcZyD0r6Zwew+1ZEm7PLLhZJredTgJCWmNyE3kZfzjE//bQP6kg 9tpqeBtFMzchaIUtRYiYMMxJBRKHwZ6NyaEwgY1DSiFMRBwKMkXFYbAbpUBU HAa7PEB2CFALi7SexcDUqKNrxpAzh4n0iypG4pC2YcQGqz/tPONjqJdoe2Gw 9GETH3UvfNcdwa+HeqNmvePOGVYbdfFOiD9gKcIH1PWPTxttPCJEq5xUG9h8 AeGAGt3Jm+lV398eup6S78K+QRbErekVez/2+zzCTnjH4OLxQVomOWJkGxk8 3tpl7wd4pRi2MkTjyf7e+WBKbZURao9K9qARLKW6lSCYjciJyJliqc+DwHsU Lj0A9JSNRUeo3YTZ2N8r1su1kil+NXNa9304TYJcePDmxIpRgn3HDmA8xRoU HpSLPaffh7NO6Zvue5htaKDRPn1xUqS/Ql5+b5GjYr+c+oOJwJ8ePRpEtKCE pu4zRKmUvJ8sitvWAeLEIkjxqk7/D15r60BHLTe6JhawJWo4LIPEjnXI0UEv NmZpFeQByh1jmqZj5nhkbd5mz7iVj98xi7Q0Nnbkegbx48/G9EVlpY47CJvi z5oAetE+bURHz4lyDos8YWYT5jUqlTi+Zw4iKzMXIaJsNBtOB5MhXVtejGc+ vagj46e2lJ0RRdoCkAl0BIdgukXLSZuzyvFBOkOIMzIPIMa60Md/Dn4H6vyJ PCD+xz4eakfiLq7Xx3FqHOrn5q4HLQHUPttixWKXL/H9EvsG/jkMNS4OBrvN jqbyxwjfJVoTrEZvHKtYSFSUuTw6DSAHcMlZiUmxX4Tfn0DnTF+K8NHcAqJ2 bG0aUXCS8J3443PnfHjNrsbDPmvwx5FWdiWzVCOH5kqXLt+qUxPatGCFvzhu FvGYFW448HubYg8YlB3ZN/ERThqfwZ3D6HdNIKtiLEVKNZBS9RewmxmHpPrR CWri5oi0MxCq1UXeOn8x+Q3AgfZQKv2ptBO+8wKUVq9gnlnpWxisTz9HZR4x w3xL57PLS76C7kWur75icpKkbadeflbC0Zv3QjB8YJJS7EaIPYs0UW02F2mC zN32wSR0oOyKis0AH9BwC4WJ48HKfrahQfz9wvStf9Y/65/1z/pn/bP+Wf+s f9Y/65/1z9I//x/UuftbAIACAA== --0-1912210914-980844184=:5981 Content-Type: APPLICATION/octet-stream; name="sscop_test.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sscop_test.tar.gz" H4sICDl+djoCA3NzY29wX3Rlc3QudGFyAO07aXfa2JL5Cr/iNoltcDAGr2/s 2D0yyLZOs3gQZBk7w5MlATpGEq2FxK9f/vtU3UVotdPzujOn37FOYtCtvW5V 3bpXyPd1dzkJTD/YffVnXeSgeXx8TF4R0moe0M/9470mfoqrScjx3v7hwfFx 87AFaK3W4f4rcvjqB1yhH2geIa/m9/dP4ula4L/697v89fyvvzb0P1RGq9k8 Ojgomv/9ZguAOP8H+83m4fEhoO0ftWD+my/z/6dfu9tlsk3a7vLRs2bzgFT1 GtlrNps78KdFLsyZabsBwO1lGJgekXzf1S0NgqRBpMWCUCKfeKZveivTaCAz /D80DcsPPOs+DCzXIe6UBHPLJ747Db5onkk0xyCGq4e26QQaRcGR0DeJ5QBW 6OkUB1ndW47mPZKp69l+nXyxgjlxPfrphgGxXcOaWjrlUSfIeml6thUEpkGW nruyDPgSzLUAWQVzE/gsFu4Xy5kR3XUMC+l8SmebwYlQv9VIWeCjCVwv3TVM VCGpvw2BBH4INDAA5Wj37spEXnDpkXsdN7B0s868sQAByDeuiGOktAQt9IVm 2aZHnbuX1QwExnwkFAHjjRC0jXRZa8G1+ld0IcxKzikzk7vgHhfgHrEhVjxL W/jr2aBTiIzjZlDj9llQacbK9ALLR5FrehQAiDg4NbUghJjDWcCYSYcXV4t6 AoQsF9pjyhJNf3DcLwvTgPgGvtHEj5ANc10ANuqL0DCfDFvDXJkLdwlm3T+K dGEZlckYSm1BtoCPmd2u50cZc9AA4SZxNJva80TmodVpNuCnR5xQci+MB7/A 9LnEdAyA04AFu4ClKezzQXnPgqwlUwCkEpTnF2fmL00d0wxILUw+DxPMYanm +2L6qAOvFZWog8vRB2koE6nfIZ1Be9yT+yNppAz6BKA3w8F7pSN3yMUnciFf yb3BiLQHvZvxSB4SSVUHbUUaySpyQ3plpAK4PxoqF+PRYKiSv/9dUoHP1hYF S/1PRP54M5RVlQyGROnddBXgDeKHUn+kyGodGSn9dnfcUfpXdQJcSB9EdpWe MgLM0aAOWss5lGRwSXrysH0Nt9KF0lVGn1Ak8rtURn2UeAkiJXIjDUdKe9yV huRmPLwZqGA5WN9R1HZXUnpyp0FAA5BK5PfgCaJeS92usJ1GS9Z8akzadKAB vaWLrswkg+0dZSi3R3Xgz79xc8HDoHW3TtQbGTjCF/mjDCZKw0915A18Vfm/ xoAEQNKRetIVCK1mHYX84r6C6WuPhzJOKTpIHV+oI2UE2pOrwaBD9Vbl4Xul LaunpDtQqRvHqlwHISOJqgcowAV8CBjw/WKsKtSbSh98MBzfYKTUyPXgA7gL NJWAukMnGwIIbYbpGgw/AV+mG5+bOvlwLQNoiL6mbpPQMSq4rz2Ko4FI8OYo Zizy6ctXXeVK7rdlRBggow+KKtdgKhXQ7wq5ovAPEkgeU9sxbEA39jUW99RI nGqiXBKp815B/Tk+RIeq8GCi7mtfc+9jDiHhG8U4IfFmrL6CBamFy3JrF/7t HUGDdHJ4cNI8JNC1EPnrkrzhtM5sQikJUmKizzzNBsBu+bUoZ+SdHxiW25if p8YW1n12UPNmmUEPKmhqMHSglhupQdPznLScqe4EizRHa+Zo6cGV5afRHv3d 4HFp5o1DbXwwgzwCWK3y8B/9hQVtQpqXYwbgseU8OVwRw7vCv415pVz2cQ3Q ASsgOrQmhn8qhvS5huXWnFpfb6H7/RwBwgliT62F6YT2acRi5VoGED1MYFFb wtprVgGtdpoAe6ZmTHTbn1XxNg9oPAW0HFhH8qD+PH8cl9rAy1HECO3lBCa8 Gk6ondv34bTOLXPycG3N+S5cd4IGAIhj1Jkft/ltFt0owvetf5iTIEPns3Hm EJyEqiBIEtbWM0MBc3OxvP1MzsqVealUwrs7p1KumOQ2DHcMLdA+l0qQb9o9 dFHzHc/8NYQ7iiIXobBppjheHMczF6bmmwkmBrnlUPxIgDo0lkpJCFvPEUBx wog8zNCPBX34BAM7YmBnGPQEA/sJBnoJDdOhCfWSpvsRZxh+dPSk89RSfDxG FpA+BUElgvYrQbMkt9hCAUffDHZ1cCY06iCC+NrK5CmJiDDDEBplG9p1jCDY Acx0EQbwfXX7uVb+rVyCYoedoDOzJ/bD0sSG9mF5mhinHRv+SQ5Dd+aY8B0/ QVgJBZAzKueU3q3Y3QqB1rTan/UeVKhifdhdVPvjLizYm1hVNg2/ViOgSgm6 Lc/1qpU4ZgVClXoi9BzSgu/fylQLfflYBU0bWC/rpEJrFsWNwWA3M3fdBwRb s8M0FI3lYOiZTQ/hXFEVesoeZB6qV5lqgd08qdRJ/6o3geVThtV20h4MflFk Ntb75UaWh/VyCRvJTWDNssydohgw7R1pJu1jjmaWJWpiM89Y6Ii/WkEVqxi1 gK4lVVW5gmaizosYVZ3bhjPVwD/CLYdPW0Z9U2xdX+rJwjbGlRuHN3nW4fj3 2sZVxhBqLLVgHql8Ep8tCl5PJlTmwww4Npvhclk8m40nTIWWqk8bTGotRCcw jszFmzxzeRqcRFL/NLthlXnSboBrM/OHG74W+z2WR4pJvm5Z2SSr6Esd9sVW QH7DQDq7o7l7VyGatjg7JCvdOjv8VslTh9N9ryIJjBZ1Gsdonpa/JRqXcrpx IV80K6DlE29s7evUgFoHlpBzaJLIz9AtkRP4ViNvqTxeNbFVW2kLEkBJLE2N CRRw4vkoeQoWnJ4ygy47k/+Wh4PqpudTveFelUfUTakhIzZkmzawq24Gqzpp RnMXrGoUCl73Yd3VgypVlpLB1NMizEsxoJJ3Z8KrSPETs7JUEr5DTiXYIDvB tFp5e06Yq0vT6SL051Voj11WorI25BmRZ4UYa8aGntcd/3LlqbZ4bmA5oSnI fwKuihrjy9CEJbBaUknfmKMiZKEsxV43p8KhEZ6RwTPieOhFsrlJcpWIda41 GpipyIuxw3Cjyzd0mLd/a/3HHjTdJd51YgW47V9NriGpu7Arg7BDKG1CMb4c CM/+bGjqqw60ClRj2qfyMIHvtTplgkqAzk42v4CcUcdXZKoyIziLYkf4VYbd H22Ttjb8LXDyWkKCWqBv4AkTnv4kaZyIjArC2mcvq4mlgMkGtlHjTo3D9rtk LvDINU3HSmmSDpv4iC41DRQBu6yozccb0U0DhagFS9cHVzdR2S9z7L+dnR3m FdABgRukdRTJXdvePPhKCFgLKCJu4th/S2DzxItuN5p7X4GW6vT2bR596zDB QEQ8oLx9G81hRPATVy+JnnIJtpvMJdQhrA97wjsUMMWafostxaQnfRQhOjX4 5PINZfMz6rx119yqxWPFd7hC00QfQu8gfCsbfmND32juG+hHyqnO1eLbUeYb kFOl9dpdmo7gNZh8GA763U//HEzaQ1mCxqp5dHSUt+xt+JkEKJfY9hJPDc0q lihmPw1ABtIXro+ggtAq3GzGWnR2YAINNfTvuNpkh2tAyj2JCcz9s63VknkJ woht+j6s2iRwXdgfu14gQiKemQ7ZOYtxAdaviQF+dUzSqX6skRK77rBt0GFP Rz6eRCPr0PZPcBdwthFSr8AnTevXH+tE2zkHCPUTJaF6n1OHR2xK69QD9Miv ArqOwi1ji3KMoSDGt7VG91BMH2ij/MUK9Dnyg94CfYMGgGFauAhOYqrfawZh 7fYJ2QgrlD1SnMaZEfCFqrYHNxNZHUkXXUW9nvD9Wi0fajkGf55TKyJnrUYB GJa3qeXZCehQ7sqSKudKFrACuQKcxxYPNHN5UkABw3Eh1fgpsqHcHryXh8+B c50zlNVP/XaB9RRUyJUTFjPNd/doqMjvi/zNgYUyORwPxbtJrG+QYqEDsUg6 uYWi8KQpUyjsgkphx0pFigIqHNk2sxR0PL+48IxIFhi2I8BHSN9VZwoSklYU 5rFeKm4wSTPFaS2/gChRfxyxTIqKU1xrUnXGTtUZ3jnGCkJGcx4lv0NtQfH/ orM8HA6GKXdTqT+tVTf5nJemXH1o/yFOYBlmVfMf9CEfXTOxeMb0F1KZCinj M6KRxdnWhr5FdCfgjgAy3KaaO+dUInzqTpCuyv+3el7QgevZDvzo8HD/6HP8 SAwSxYfUsmMJFA0m8y0a1nJxbTZTp1waHhBgc38jja7XzT3fSmNPL3bRdqqh R8JabifPiHIyMXNuwE4nig4OLpS+NPy0J6ltReGnB2sltm3c/4Ixc3Ch6TWg 8EAblqsQl3gS55e7z3jaYL4RLDT4af7rrYhn6iZ9brzh041IdcOorbclJywG 0VjMOW7ddKHNfLIJbrnEleOmRn4mFbGuVMgJ3tCcFrRrUt02IAbqyRE+faxh 3ebJixko+mKhrOTNoMWK9kscM6dhx8cgNIZZS5o6HxLnT8WTrV6PR53Bhz7X n+29m1lB6+cqmG1sZbJmBGvHDHdkeJqZQxbfCicyrav06XbhbeszbHLAU+ud bYktf7+KVNne1paAo61upeEV3WLAHVjJ0wW3qfTZCO7B0xtgskNaeQ0/4hN8 oshXLqp/q5be+goIPWxCtR3YxdDJEltqqNl4DkBhOy2+x3HoXK7HOEW5pC3x +HzFigZ8ZQWEbSohHhAKAN9cVjdp8FTIHV1caxgjLBH4thOdEg8cHHv7FsbO z8hmzFXsVGRdCKnaAGfbMcoyljBiNw4pzZCo4FayE4DNUp0+XMrksljykZIS /5Ys2nxF2ppvxW5+3jp5lvkaW6bY/KEbTHhRmw05s7rF2Gqm1xDGx3yWD83r 59h4uWxSjftzTIxcJvGW4TkOnS2+nEfJwB4Ucqp0VkA8nYvTCvFAskAuOzwp FBzmqj7+PbqP/0Ddx79LeTuufKue1909p3zvX1e+SPAzyusFkZfcUNVjFT2H iV/AJL7xes4F6tM8vkuPQLiRiooqU0Ez6piwivuonaObxAnte/GQJtmGrk8I uQWVUJwPMs6/wpyltm/j/i99WA4pC5I6ZxRcgme5jAYjqRvjEeEBp8ANF4LV JixjddJqRofiuK5FZZ2RFTTjSfNjrQJyZvzW3qDu+JY7Tck9r5inX/PnaZk/ T+wYMjrmEwskPaelmxZxyCdO8HhKsFt2zJdQvbBxX//agtjOTOyUoQcRT8HD UAx6sSNKN95yiIP0nCM4b1ZwCOeylTo6ewcXhGFmUaZFAKmdleVXgVLszsKw RkNmp/XkBov+Rmk9lUB1Wk48qIEpZBFFN538TJrKiTdjdIDZEi3qrDGMHhSA 87CVpUfm2MbSM/c6iY4haniGx1pCB/wV7W29Wa2w118/R4h3U9kJNJ6fQXHI nDeXOJV79Bd0/ejA+fdMJT/ysE0bn7cmJonvZv8qDuU/DCqnfxg0dYQvo/UH nAnfcadGO3fh3/RZ/dRJ1t5MmNIfzuJvmUEa/flI8ugHAjxqoRPn8XgYP+zg YTyuAVmLp04Ol1R7j2fw1CBuSUFbz/TJnNBnmWdQoofFDu5jXr1cf4X3f3ra g4nR+IfLePr9H0IOjtPv/+wdHR28vP/zI67X5dfsB8di9r/rx8avyzfDwRVW 9Sh8yu3LrnSlkrewNisNsvNBWyzIzqzc7azHZ+XOjdTp4Pc3v3WVi748uhpK N9ffAAvHAWUhfmpb7g96Uv+sXO7Jqkp/m47FCycLRMGmsH+pdGXK9k1VoNTK 5YY6vrxUPsrqCWlA61DGP9Bp4csQW7v/83rX2CLv3rwj/ySBR3YMUrlrtvYq cEsbDXL+5j+BRfRr4HvfaOBvqBv2w3m5DIvtSULYv1n+c++ix35s/rf296L8 39vbx4GDVvMl/39I/hNJpBXBjIVux3FM+roVfTRVhgRp3TWb+/C/Gf1vNY/u 9qL7w7vWcSt2j9/3Xlb9v1r+NwwTWkzjj5fxTP63jvaOWf7v7e8d7B/g+n/Y fHn/9wflP67W8beNyrEbN/kiEtkNfW+XL4+7/DUicldOjT/6u7phTn2AJQC2 ps8tx9zVHN/Ko+OvIGVG6TtI6VH2ElKGiXgRKasSf3UoV13YmglwrsZFtAIO aWNpTp7USJ88sZOl61tf02T8tankIH9vKsuGvzuVZR5BipTOJ41MhiasQO0Q f0Fqfg2KSGPwPHL2SlZyPG+MvgGWy0G87ZUvfql5ml1EuX7vKwlcv/iVoYu/ /MVXRcDKeSUMKaNhOgZZ0JjHEuqEcYYwx/96Q0vcRzpoL4vny/VyvVwv18v1 cr1cL9fL9XK9XH/89b+xPLtMAFAAAA== --0-1912210914-980844184=:5981-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 0:59: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 108BB37B69B; Tue, 30 Jan 2001 00:58:48 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id QAA03934; Tue, 30 Jan 2001 16:58:45 +0800 Received: from elischer.org (reggae-02-2.nv.iinet.net.au [203.59.91.2]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id QAA13881; Tue, 30 Jan 2001 16:56:25 +0800 Message-ID: <3A768232.282B28E6@elischer.org> Date: Tue, 30 Jan 2001 00:58:26 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Harti Brandt , julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base References: <3A767279.977B96CA@elischer.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > Firstly, thanks for the report. > And thanks for spending the time to look into it. >[...] > > it seems like there is a problem with node reference counts. I have a > > test program, that instantiates a chain of nodes like this: > > > > ng_atm -----------> ng_sscop --------------> ng_sscf ---------> ng_socket > > | ^ > > +--------------------------------------+ [...] > can you send me a copy of your ng_sccop node so I can try simulate this? > in the meanwhile I'll try using the 'hole' node to simulate it. > using ngctl and 'hole' nodes in this configuration I cannot make this happen. here's the sequence I used: + mkpeer hole aaa aaa + name aaa near + mkpeer hole bbb bbb + name bbb far + connect near: far: ccc ccc + connect lnc0: far: orphans ddd + list There are 4 total nodes: Name: far Type: hole ID: 00000008 Num hooks: 3 Name: near Type: hole ID: 00000007 Num hooks: 2 Name: ngctl192 Type: socket ID: 00000006 Num hooks: 2 Name: lnc0 Type: ether ID: 00000005 Num hooks: 1 + show far: Name: far Type: hole ID: 00000008 Num hooks: 3 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- ddd lnc0 ether 00000005 orphans ccc near hole 00000007 ccc bbb ngctl192 socket 00000006 bbb + shutdown near: + shutdown far: + list There are 2 total nodes: Name: lnc0 Type: ether ID: 00000009 Num hooks: 0 Name: ngctl192 Type: socket ID: 00000006 Num hooks: 0 + no messages were printed on the console... can you repeat this sequence using your nodes and see if you get an error when it is done by hand (slowely?). I'll try it again from a script using ngctl -f [later] no, it still doesn't complain.. can you try this: ( I assume atm is permanent like lnc0: ) cat > tmp/it < X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 1:38: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 55F5037B69B; Tue, 30 Jan 2001 01:37:46 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id KAA22044; Tue, 30 Jan 2001 10:37:42 +0100 (MET) Date: Tue, 30 Jan 2001 10:37:42 +0100 (CET) From: Harti Brandt To: Julian Elischer Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base In-Reply-To: <3A768232.282B28E6@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 Jan 2001, Julian Elischer wrote: JE>using ngctl and 'hole' nodes in this configuration I cannot make this happen. I tried the following two things: ----------------------------------------------------- 500 [root] (beagle) /tmp # ngctl + mkpeer sscfu mine upper + name mine sscf + mkpeer sscf: sscop lower upper + name sscf:lower sscop + connect sscop: fatm0: lower sig + list There are 5 total nodes: Name: sscop Type: sscop ID: 00000011 Num hooks: 2 Name: sscf Type: sscfu ID: 00000010 Num hooks: 2 Name: ngctl12169 Type: socket ID: 0000000f Num hooks: 1 Name: fatm1 Type: atm ID: 00000002 Num hooks: 0 Name: fatm0 Type: atm ID: 00000001 Num hooks: 1 + show sscf: Name: sscf Type: sscfu ID: 00000010 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- lower sscop sscop 00000011 upper upper ngctl12169 socket 0000000f mine + show sscop: Name: sscop Type: sscop ID: 00000011 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- lower fatm0 atm 00000001 sig upper sscf sscfu 00000010 lower + msg fatm0: cpcsinit {name="sig" aal=5 vci=5} Rec'd response "cpcsinit" (4) from "[1]:": Args: {} + Rec'd data packet on hook "mine": 0000: 01 00 00 00 .... + shutdown sscf: + shutdown sscop: + list There are 3 total nodes: Name: ngctl12169 Type: socket ID: 0000000f Num hooks: 0 Name: fatm1 Type: atm ID: 00000002 Num hooks: 0 Name: fatm0 Type: atm ID: 00000001 Num hooks: 0 + ^C The cpcsinit opens the ATM VCI and sends the AAL5 frames out the named hook. The data is an SSCOP begin PDU. In /var/log/messages I have: Jan 30 10:15:00 beagle /boot/kernel/kernel: changing state from SSCOP_OUT_DIS_PEND to SSCOP_IDLE Jan 30 10:15:00 beagle /boot/kernel/kernel: disconnect 0xc2c54840 from 0xc2c94d00 (invalid) refs=3 flags=9 Jan 30 10:15:00 beagle /boot/kernel/kernel: ng_sscop_shutdown: 0xc2c94d00 refs=2 flags=9 Jan 30 10:15:00 beagle /boot/kernel/kernel: Accessing freed node node: ID [11]: type 'sscop', 0 hooks, flags 0x9, 0 refs, : Jan 30 10:15:00 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 735 Jan 30 10:15:00 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 2436 ----------------------------------- The 2nd test is exactly the same, except I do not do the cpcsinit: + mkpeer sscfu mine upper + name mine sscf + mkpeer sscf: sscop lower upper + name sscf:lower sscop + connect sscop: fatm0: lower sig + list There are 5 total nodes: Name: sscop Type: sscop ID: 00000014 Num hooks: 2 Name: sscf Type: sscfu ID: 00000013 Num hooks: 2 Name: ngctl12184 Type: socket ID: 00000012 Num hooks: 1 Name: fatm1 Type: atm ID: 00000002 Num hooks: 0 Name: fatm0 Type: atm ID: 00000001 Num hooks: 1 + show sscf: Name: sscf Type: sscfu ID: 00000013 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- lower sscop sscop 00000014 upper upper ngctl12184 socket 00000012 mine + show sscop: Name: sscop Type: sscop ID: 00000014 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- lower fatm0 atm 00000001 sig upper sscf sscfu 00000013 lower + shutdown sscf: + shutdown sscop: + list There are 3 total nodes: Name: ngctl12184 Type: socket ID: 00000012 Num hooks: 0 Name: fatm1 Type: atm ID: 00000002 Num hooks: 0 Name: fatm0 Type: atm ID: 00000001 Num hooks: 0 + ^D Now everything is ok. In /var/log/messages I have: Jan 30 10:18:42 beagle /boot/kernel/kernel: disconnect 0xc2c54740 from 0xc2c94c00 (valid) refs=4 flags=0 Jan 30 10:19:12 beagle /boot/kernel/kernel: disconnect 0xc2c54940 from 0xc2c94c00 (invalid) refs=4 flags=9 Jan 30 10:19:12 beagle /boot/kernel/kernel: ng_sscop_shutdown: 0xc2c94c00 refs=3 flags=9 Note, that the reference count is now 3 as I expected it (and as I understand your explanation). The same experiment with two holes and the cpcsinit also works whether I do it slowly or fast. NB: the ng_atm node switches the peer hook to queueing. [later] If I use 'xl0: lower' instead of the fatm0 it's also ok. Perhaps it is rather a problem in ng_sscop ??? Can't really understand what happens. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 2:21: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 8D7FD37B6B1; Tue, 30 Jan 2001 02:20:38 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id LAA27031; Tue, 30 Jan 2001 11:20:35 +0100 (MET) Date: Tue, 30 Jan 2001 11:20:34 +0100 (CET) From: Harti Brandt To: Julian Elischer Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base In-Reply-To: <3A768232.282B28E6@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Just a bit more information: I just tried to run my PDP-11 simulator while having loaded ng_ether from the previous tests. The simulator uses the if_tap interface to emulate an ethernet interface to the PDP. Suddenly the system crashed while doing an ifconfig. The crash occured in ng_ether_output, because the node pointer in the interface structure was NULL. It checked the sources of if_tap and ng_ether, but could not find, how this was caused. So I tried to repeat the crash, but no luck. The trace from the crashdump shows: Script started on Tue Jan 30 11:16:48 2001 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... IdlePTD 3457024 initial pcb at 2a8f40 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address=09=3D 0x84 fault code=09=09=3D supervisor read, page not present instruction pointer=09=3D 0x8:0xc311a66a stack pointer=09 =3D 0x10:0xd7ac5d00 frame pointer=09 =3D 0x10:0xd7ac5d0c code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b =09=09=09=3D DPL 0, pres 1, def32 1, gran 1 processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 current process=09=09=3D 12341 (ifconfig) panic: from debugger panic: from debugger Uptime: 17h16m42s dumping to dev da0s1b, offset 1048736 dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 49= 4 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 4= 75 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 = 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438= 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 41= 9 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 4= 00 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 = 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363= 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 34= 4 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 3= 25 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 = 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288= 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 26= 9 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 2= 50 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 = 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213= 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 19= 4 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 1= 75 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 = 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138= 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 11= 9 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 1= 00 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 = 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 = 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 = 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0=20 --- #0 0xc0182102 in dumpsys () (kgdb) bt #0 0xc0182102 in dumpsys () #1 0xc0181eef in boot () #2 0xc01822b9 in panic () #3 0xc012e455 in db_panic () #4 0xc012e3f5 in db_command () #5 0xc012e4ba in db_command_loop () #6 0xc0130687 in db_trap () #7 0xc020fca6 in kdb_trap () #8 0xc021bd08 in trap_fatal () #9 0xc021ba7d in trap_pfault () #10 0xc021b64b in trap () #11 0xc311a66a in ?? () #12 0xc01c57d8 in ether_output () #13 0xc01ca61b in arprequest () #14 0xc01cafff in arp_ifinit () #15 0xc01c5c8d in ether_ioctl () #16 0xc310eb1c in ?? () #17 0xc01cc3dd in in_ifinit () #18 0xc01cbf1d in in_control () #19 0xc01c4753 in ifioctl () #20 0xc0197c72 in soo_ioctl () #21 0xc0195082 in ioctl () #22 0xc021c14c in syscall2 () #23 0xc0210613 in Xint0x80_syscall () ---Type to continue, or q to quit--- #24 0x80486dd in ?? () #25 0x8048135 in ?? () (kgdb)=20 Script done on Tue Jan 30 11:16:53 2001 Frame #11 was ng_ether_output in ddb. But while trying to repeat the crash I suddenly discovered the following in /var/log/messages: Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [= 3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modu= les/netgraph/netgraph/../../../netgraph/ng_base.c, line 2436 Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr= /src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 341 Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [= 3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modu= les/netgraph/ether/../../../netgraph/ng_ether.c, line 341 Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr= /src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 344 Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [= 3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modu= les/netgraph/ether/../../../netgraph/ng_ether.c, line 344 Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr= /src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 345 That looks exactly like my problem, so I assume it is not the sscop code. harti To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 2:50:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 1ABA237B6C9 for ; Tue, 30 Jan 2001 02:50:35 -0800 (PST) Received: (qmail 23896 invoked by uid 666); 30 Jan 2001 10:58:52 -0000 Received: from reggae-02-2.nv.iinet.net.au (HELO elischer.org) (203.59.91.2) by mail.m.iinet.net.au with SMTP; 30 Jan 2001 10:58:52 -0000 Message-ID: <3A769C67.6B69EB06@elischer.org> Date: Tue, 30 Jan 2001 02:50:15 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Harti Brandt Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Harti Brandt wrote: > > do it slowly or fast. > > NB: the ng_atm node switches the peer hook to queueing. try turn this off.. it may give us a clue.. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 3: 5:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id DEC6B37B69E; Tue, 30 Jan 2001 03:04:56 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA03757; Tue, 30 Jan 2001 12:04:48 +0100 (MET) Date: Tue, 30 Jan 2001 12:04:48 +0100 (CET) From: Harti Brandt To: Julian Elischer Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base In-Reply-To: <3A769C67.6B69EB06@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 Jan 2001, Julian Elischer wrote: JE>> NB: the ng_atm node switches the peer hook to queueing. JE> JE> JE>try turn this off.. JE>it may give us a clue.. Oh yes, now everything's ok: Jan 30 11:58:37 beagle /boot/kernel/kernel: disconnect 0xc2ccdcc0 from 0xc2c4ad00 (valid) refs=5 flags=0 Jan 30 11:58:37 beagle /boot/kernel/kernel: disconnect 0xc2ccde00 from 0xc2c4ad00 (invalid) refs=5 flags=9 Jan 30 11:58:38 beagle /boot/kernel/kernel: disconnect 0xc2ccdf80 from 0xc2c4ad00 (invalid) refs=4 flags=9 Jan 30 11:58:38 beagle /boot/kernel/kernel: ng_sscop_shutdown: 0xc2c4ad00 refs=3 flags=9 So the problem is with the queuing. But, as far as I understand, running that hook in queue mode is the correct thing to do, because it is called from a interface input routine (it is called from atm_input). I'm right? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 3: 8:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 059DE37B503; Tue, 30 Jan 2001 03:08:19 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id TAA27123; Tue, 30 Jan 2001 19:08:17 +0800 Received: from elischer.org (reggae-02-2.nv.iinet.net.au [203.59.91.2]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id TAA20722; Tue, 30 Jan 2001 19:05:58 +0800 Message-ID: <3A76A08E.8B5B3896@elischer.org> Date: Tue, 30 Jan 2001 03:07:58 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Harti Brandt Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Harti Brandt wrote: > > Hi, > > Just a bit more information: I just tried to run my PDP-11 simulator > while having loaded ng_ether from the previous tests. The simulator uses > the if_tap interface to emulate an ethernet interface to the PDP. Suddenly > the system crashed while doing an ifconfig. The crash occured in > ng_ether_output, because the node pointer in the interface structure was > NULL. It checked the sources of if_tap and ng_ether, but could not find, > how this was caused. So I tried to repeat the crash, but no luck. The > trace from the crashdump shows: [...] > Frame #11 was ng_ether_output in ddb. > > But while trying to repeat the crash I suddenly discovered the following > in /var/log/messages: > > Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : > Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c, line 2436 > Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 341 > Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : > Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 341 > Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 344 > Jan 30 11:05:56 beagle /boot/kernel/kernel: Accessing freed node node: ID [3]: type 'ether', 0 hooks, flags 0x9, 0 refs, : > Jan 30 11:05:56 beagle /boot/kernel/kernel: Last active @ /usr/src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 344 > Jan 30 11:05:56 beagle /boot/kernel/kernel: problem discovered at file /usr/src/sys/modules/netgraph/ether/../../../netgraph/ng_ether.c, line 345 > > That looks exactly like my problem, so I assume it is not the sscop code. > I think we'll find it's a problem with queueing and dequeueng packets.... I'm looking there now.... (queued packets are supposed to hold a reference to the node they are queued on, and that reference is supposed to be released when the packet is dequeued, but I have a suspicion that I screwed it and am releasing it twice.. Do you use NG_SEND_DATA_ONLY() in the atm node?? > harti -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 3:26:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 11D2237B69F; Tue, 30 Jan 2001 03:26:29 -0800 (PST) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA07304; Tue, 30 Jan 2001 12:26:25 +0100 (MET) Date: Tue, 30 Jan 2001 12:26:25 +0100 (CET) From: Harti Brandt To: Julian Elischer Cc: julian@freebsd.org, freebsd-net@freebsd.org, archie@freebsd.org Subject: Re: netgraph: problem in ng_base In-Reply-To: <3A76A08E.8B5B3896@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 Jan 2001, Julian Elischer wrote: JE>Do you use NG_SEND_DATA_ONLY() in the atm node?? Yes. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org, lhbrandt@mail.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 3:54:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from grif0.newmail.ru (grif0.newmail.ru [212.48.140.145]) by hub.freebsd.org (Postfix) with SMTP id B937437B6B6 for ; Tue, 30 Jan 2001 03:54:05 -0800 (PST) Received: (qmail 9735 invoked by alias); 30 Jan 2001 11:54:05 -0000 Message-ID: <20010130115405.9734.qmail@grif0.newmail.ru> From: "George" To: freebsd-net@freebsd.org Reply-To: Subject: multiple MP PPP from one box - is it possible? Date: Tue, 30 Jan 2001 14:54:05 +0300 MIME-Version: 1.0 X-UID: 12-49590 X-Originating-IP: [195.5.9.9] Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have 2 lines to direction A and 2 lines to direction B, and like to use multilink PPP on both directions from one box simultaneously (my box is FreeBSD 4.0-R, boxes A and B are also F4.0-R) I have tried to use user PPP ver 2.26 but didn"t succeed, is it possible? or I"m doing smth wrong? -- GVF To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 6:45:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from www.aprcity.ru (b.primesite.ru [194.85.132.55]) by hub.freebsd.org (Postfix) with ESMTP id E357837B6E6 for ; Tue, 30 Jan 2001 06:45:25 -0800 (PST) Received: from infodep01 (info-dep-01.aprcity.com [172.16.0.37]) by www.aprcity.ru (8.9.3/8.9.3) with SMTP id RAA68006 for ; Tue, 30 Jan 2001 17:52:34 +0300 (MSK) Message-ID: <028801c08acb$1f4fc6d0$250010ac@aprcity.com> From: "Zaitsev Serg" To: Subject: netstat -inb Date: Tue, 30 Jan 2001 17:44:17 +0300 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I like to use 'netstat -inb' for monthly looking how much bytes in/out on particular network device (xl2, for me). But counters look like a modus of 2^32 (4294967296, unsigned double word). It's so little for my needs. Are there user way to enlarge counters to 64 bits? Thanks, Zaitsev Serg, root@aprcity.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 10:42:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 42ACE37B69C for ; Tue, 30 Jan 2001 10:42:20 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0UIgeE16819; Tue, 30 Jan 2001 18:42:40 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0UIhkp04387; Tue, 30 Jan 2001 18:43:46 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200101301843.f0UIhkp04387@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: gvfnk2@newmail.ru Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: multiple MP PPP from one box - is it possible? In-Reply-To: Message from "George" of "Tue, 30 Jan 2001 14:54:05 +0300." <20010130115405.9734.qmail@grif0.newmail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jan 2001 18:43:46 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have 2 lines to direction A and 2 lines to direction B, > and like to use multilink PPP on both directions > from one box simultaneously > (my box is FreeBSD 4.0-R, boxes A and B are also F4.0-R) > I have tried to use user PPP ver 2.26 > but didn"t succeed, is it possible? or I"m doing smth wrong? An MP endpoint is identified by it's endpoint discriminator and authentication name. If the peers aren't using either you'll get the two confused. You need to either authenticate (``set authname'') as a different user on each of your peers or ``set enddisc something'' on each. ``set enddisc MAC'' at the beginning of the default profile is a good solution if you've got NICs in the boxes. > -- > GVF -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 12: 4:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id 75B7937B4EC for ; Tue, 30 Jan 2001 12:04:07 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f0UK47v01406; Tue, 30 Jan 2001 12:04:07 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Tue, 30 Jan 2001 12:04:06 -0800 (PST) From: Yu-Shun Wang To: Cc: Subject: IPComp question In-Reply-To: <953kce$2q6k$1@igloo.uran.net.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I tried to measure bandwidth with IPComp enabled, but kept getting the error message "no response" from netperf (/usr/ports/benchmark/netperf). For all I could tell from tcpdump, netperf established ctrl channel, and about 5 to 8 packets were sent with IPComp applied, but I never saw any return or ack packets for netperf. Here are the setkey conf files I used. Please let me know if I missed anything. Host1: 10.1.1.102 add 10.1.1.102 10.1.1.75 ipcomp 10001 -C deflate ; add 10.1.1.75 10.1.1.102 ipcomp 10002 -C deflate ; spdadd 10.1.1.102 10.1.1.75 any -P out ipsec ipcomp/transport/10.1.1.102 -10.1.1.75/require ; spdadd 10.1.1.75 10.1.1.102 any -P in ipsec ipcomp/transport/10.1.1.75- 10.1.1.102/require ; Host2: 10.1.1.75 add 10.1.1.102 10.1.1.75 ipcomp 10001 -C deflate ; add 10.1.1.75 10.1.1.102 ipcomp 10002 -C deflate ; spdadd 10.1.1.102 10.1.1.75 any -P in ipsec ipcomp/transport/10.1.1.102 -10.1.1.75/require ; spdadd 10.1.1.75 10.1.1.102 any -P out ipsec ipcomp/transport/10.1.1.75- 10.1.1.102/require ; Thanks, yushun. ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 19:13:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id AC83E37B6A2 for ; Tue, 30 Jan 2001 19:12:55 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA24916; Wed, 31 Jan 2001 12:12:49 +0900 (JST) To: Yu-Shun Wang Cc: freebsd-net@freebsd.org In-reply-to: yushunwa's message of Tue, 30 Jan 2001 12:04:06 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp question From: itojun@iijlab.net Date: Wed, 31 Jan 2001 12:12:49 +0900 Message-ID: <24914.980910769@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi, > I tried to measure bandwidth with IPComp enabled, but kept > getting the error message "no response" from netperf > (/usr/ports/benchmark/netperf). > > For all I could tell from tcpdump, netperf established ctrl > channel, and about 5 to 8 packets were sent with IPComp > applied, but I never saw any return or ack packets for > netperf. are there any strange number increase in netstat -sn on receiver side? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jan 30 23:53:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from lucifer.ninth-circle.org (intotcpcb.sourcewh0re.net [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 3AC1A37B69D; Tue, 30 Jan 2001 23:53:20 -0800 (PST) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.1/8.11.0) id f0V7r6W34228; Wed, 31 Jan 2001 08:53:06 +0100 (CET) (envelope-from asmodai) Date: Wed, 31 Jan 2001 08:53:06 +0100 From: Jeroen Ruigrok van der Werven To: Boris Popov Cc: Bosko Milekic , Wesley Morgan , "G. Jason Middleton" , freebsd-net@FreeBSD.ORG Subject: Re: no buffer space available (outcome of netstat -m) Message-ID: <20010131085306.I33191@lucifer.bart.nl> References: <003e01c089a9$c4287d00$1f90c918@jehovah> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bp@FreeBSD.ORG on Mon, Jan 29, 2001 at 10:44:20AM +0600 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010129 05:45], Boris Popov (bp@FreeBSD.ORG) wrote: >On Sun, 28 Jan 2001, Bosko Milekic wrote: > >> Boris, if you're reading this, if you see that both these >> gentlemen have the same interface, perhaps we have a winner? I've been >> unable to find the problem as of yet (frankly, I've had little time to >> look too deeply). > > This a is plain Realtek8029 with ed driver. As I've already >mentioned to Bosko - it is enough to ping this box from another machine to >initiate buffers cleanup. Same here with ep: ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0 Happens every once in a while [CURRENT] ifconfig down 'n up solves it. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Misery loves company... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 0: 4:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.nk.ukrtel.net (mailhub.nk.ukrtel.net [195.5.9.2]) by hub.freebsd.org (Postfix) with ESMTP id 4520237B69E for ; Wed, 31 Jan 2001 00:03:58 -0800 (PST) Received: by mailhub.nk.ukrtel.net (Postfix, from userid 1002) id B646010786; Wed, 31 Jan 2001 10:01:46 +0200 (EET) Date: Wed, 31 Jan 2001 10:01:46 +0200 From: George Fedorenko To: Brian Somers Cc: freebsd-net@freebsd.org Subject: Re: multiple MP PPP from one box - is it possible? Message-ID: <20010131100146.A49011@mailhub.nk.ukrtel.net> Reply-To: gvf@nk.ukrtel.net References: <200101301843.f0UIhkp04387@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101301843.f0UIhkp04387@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Tue, Jan 30, 2001 at 06:43:46PM +0000 X-Operating-System: FreeBSD 4.1-RELEASE Organization: ND Ukrtelekom Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Brian! On Tue, 30 Jan 2001, Brian Somers wrote: > > I have 2 lines to direction A and 2 lines to direction B, > > and like to use multilink PPP on both directions > > from one box simultaneously > > (my box is FreeBSD 4.0-R, boxes A and B are also F4.0-R) > > I have tried to use user PPP ver 2.26 > > but didn"t succeed, is it possible? or I"m doing smth wrong? > > An MP endpoint is identified by it's endpoint discriminator and > authentication name. If the peers aren't using either you'll get > the two confused. and they did... > > You need to either authenticate (``set authname'') as a different > user on each of your peers or ``set enddisc something'' on each. > ``set enddisc MAC'' at the beginning of the default profile is a > good solution if you've got NICs in the boxes. Thanks alot this solved the problem!!! ;-) And thanks for a good program - user PPP!!! -- ====================================================== George Fedorenko, phone: +380-(512)-470110 ====================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 1:52:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [217.9.2.1]) by hub.freebsd.org (Postfix) with SMTP id 80DB437B65D for ; Wed, 31 Jan 2001 01:52:12 -0800 (PST) Received: (qmail 74144 invoked from network); 31 Jan 2001 09:51:57 -0000 Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown) by unknown with SMTP; 31 Jan 2001 09:51:57 -0000 Received: (qmail 13530 invoked by uid 1001); 31 Jan 2001 09:51:56 -0000 Date: 31 Jan 2001 11:51:56 +0200 Date: Wed, 31 Jan 2001 11:51:56 +0200 From: Adrian Pavlykevych To: Boris Popov Cc: Bosko Milekic , Wesley Morgan , "G. Jason Middleton" , freebsd-net@FreeBSD.ORG Subject: Re: no buffer space available (outcome of netstat -m) Message-ID: <20010131115156.D49315@polynet.lviv.ua> References: <003e01c089a9$c4287d00$1f90c918@jehovah> <20010131085306.I33191@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.11i In-Reply-To: <20010131085306.I33191@lucifer.bart.nl>; from jruigrok@via-net-works.nl on Wed, Jan 31, 2001 at 08:53:06AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 31, 2001 at 08:53:06AM +0100, Jeroen Ruigrok van der Werven wrote: > -On [20010129 05:45], Boris Popov (bp@FreeBSD.ORG) wrote: > >On Sun, 28 Jan 2001, Bosko Milekic wrote: > > > >> Boris, if you're reading this, if you see that both these > >> gentlemen have the same interface, perhaps we have a winner? I've been > >> unable to find the problem as of yet (frankly, I've had little time to > >> look too deeply). > > > > This a is plain Realtek8029 with ed driver. As I've already > >mentioned to Bosko - it is enough to ping this box from another machine to > >initiate buffers cleanup. > > Same here with ep: > > ep0: <3Com 3C509-TP EtherLink III> at port 0x300-0x30f irq 10 on isa0 Similar situation in my case: ep0: <3Com 3C509B-TPO EtherLink III (PnP)> at port 0x210-0x21f irq 5 on isa0 Running 4-Stable. I can only add, that this is dualhomed proxy firewall, and I experience such lockups during heavy activity (i.e downloading/uploading something from inside to host in DMZ - that is doing Ethetnet<->Ethernet transfers.) ifconfig down/up was doing the job, unfortunately, pinging the host didn't help. This behaviour I see from early 3.x days uptil now. -- Adrian Pavlykevych email: System Administrator phone/fax: +380 (322) 742041 State University "Lvivska Polytechnica" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 9:21: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by hub.freebsd.org (Postfix) with ESMTP id E978A37B4EC for ; Wed, 31 Jan 2001 09:20:43 -0800 (PST) Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 31 Jan 2001 17:02:06 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Wed, 31 Jan 2001 17:00:49 -0000 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9409D21C67@mbtlipnt01.btlabs.bt.co.uk> From: parminder.mudhar@bt.com To: freebsd-net@FreeBSD.org Subject: Routes and tunnels Date: Wed, 31 Jan 2001 17:01:51 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I don't know if this is intentional or a bug, but if ifconfig is used to configure a point to point device, such as 'tun' or the newer 'gif' devices, then the kernel insists on installing a route where the destination is the end point of the tunnel, the gateway is the source of the tunnel and the interface is the device itself. I have checked this in version 3.2+KAME, what I a using, and also on version 4.1. The effect of the above is that the packet that uses the tunnel will never appear on the wire. Here is an output the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 the_swamp# netstat -rnf inet Routing tables Internet: Destination Gateway Flags Netif Expire default 132.146.115.1 UGSc 1 0 fxp1 127.0.0.1 127.0.0.1 UH 0 4 lo0 132.145.113.1 132.146.115.164 UH 0 0 gif0 132.146.115/24 link#2 UC 0 0 fxp1 => 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 460 I am also interested in using gated with point to point tunnels, but gated also insists on doing the above for point to point links. I thank you in advance for any advice you may have. Parminder Mudhar __________________________ parminder.mudhar@bt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 10:54:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id ADBFE37B4EC for ; Wed, 31 Jan 2001 10:54:25 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id 3E14C24D2C; Wed, 31 Jan 2001 16:54:23 -0200 (BRST) Message-ID: <3A785F88.652C6B3A@jonny.eng.br> Date: Wed, 31 Jan 2001 16:55:05 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Yusuf Goolamabbas , freebsd-net@FreeBSD.ORG Subject: Re: Bridging and dummynet seems to destroy dmesg output References: <200101300451.f0U4pmj54651@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Luigi, I'm seeing the same problem here, and I do not use bridging. I have DUMMYNET and IPFIREWALL configured. I can send the kernel and firewall config files if you need. BTW: this did not happen with 4.2-RELEASE. For more info, see the message I've posted to freebsd-stable list. Luigi Rizzo wrote: > > are you sure you made a proper upgrade of header files and binaries ? > i have not seen the problem locally, and i have been running a > shaping bridge with the new code for most of the week. > > cheers > luigi > > > Hi, I cvsup'ed my traffic shaper box today (RELENG_4) [incorporating > > Luigi's latest fixes]. So far, I have not been experiencing any stalls. > > However, the output of dmesg seems to be corrupted. I see only 1 line > > everytime I invoke it > > > > %dmesg > > >ipfw: 400 Pipe 1 TCP a.b.c.d:port e.f.g.h:port in via > > %dmesg > > a.b.c.d:port e.f.g.h:port in via > > > > /var/log/messages also seems to have various log messages from ipfw in a > > segmented manner. Is anybody else seeing this ? Yes! Me!!! I'm not alone, then! > > > > Regards, Yusuf > > -- > > Yusuf Goolamabbas > > yusufg@outblaze.com Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 11: 1:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id 95A4037B491 for ; Wed, 31 Jan 2001 11:01:35 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f0VJ0w601374; Wed, 31 Jan 2001 11:00:59 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Wed, 31 Jan 2001 11:00:58 -0800 (PST) From: Yu-Shun Wang To: Cc: Subject: Re: IPComp question In-Reply-To: <24914.980910769@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I tried to measure bandwidth with IPComp enabled, but kept > > getting the error message "no response" from netperf > > (/usr/ports/benchmark/netperf). > > > > For all I could tell from tcpdump, netperf established ctrl > > channel, and about 5 to 8 packets were sent with IPComp > > applied, but I never saw any return or ack packets for > > netperf. > > are there any strange number increase in netstat -sn on receiver side? No, but the problem is that there was no increase (actually, no record at all) under ipsec: IPComp. The number on the sending side seemed right. The increase matched the ones I saw from tcpdump. It looked like the IPComp packets either weren't logged or were dropped for some reason. yushun. > itojun > > > 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 Jan 31 11:17:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id BB23A37B65D for ; Wed, 31 Jan 2001 11:17:33 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0VJGvh07201; Wed, 31 Jan 2001 11:16:57 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101311916.f0VJGvh07201@iguana.aciri.org> Subject: Re: Bridging and dummynet seems to destroy dmesg output In-Reply-To: <3A785F88.652C6B3A@jonny.eng.br> from Joao Carlos Mendes Luis at "Jan 31, 2001 4:55: 5 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Wed, 31 Jan 2001 11:16:57 -0800 (PST) Cc: rizzo@aciri.org, yusufg@outblaze.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi Luigi, > > I'm seeing the same problem here, and I do not use bridging. I have > DUMMYNET and IPFIREWALL configured. I can send the kernel and firewall config > files if you need. yes please -- because the picobsd image i am using does not produce the problem and yusuf could confirm that using the same picobsd image, so there might be something wrong with the way you upgraded your source (or i forgot to commit something). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 12: 9:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id D0FEE37B4EC for ; Wed, 31 Jan 2001 12:09:31 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id 8323C24D2C; Wed, 31 Jan 2001 18:09:30 -0200 (BRST) Message-ID: <3A787124.B307EC20@jonny.eng.br> Date: Wed, 31 Jan 2001 18:10:12 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: yusufg@outblaze.com, freebsd-net@FreeBSD.ORG Subject: Re: Bridging and dummynet seems to destroy dmesg output References: <200101311916.f0VJGvh07201@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I sent these files in private. But I remembered that I have another unusual config in this machine: is is multiprocessed, and has 10 SCSI disks and lots of SYSV shared memory. I could also test a kernel compiled by you, using my config. Just send it to me in private and I'll try. Luigi Rizzo wrote: > > > Hi Luigi, > > > > I'm seeing the same problem here, and I do not use bridging. I have > > DUMMYNET and IPFIREWALL configured. I can send the kernel and firewall config > > files if you need. > > yes please -- because the picobsd image i am using does not > produce the problem and yusuf could confirm that using the > same picobsd image, so there might be something wrong with the > way you upgraded your source (or i forgot to commit something). > > cheers > luigi -- Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 12:12:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6E6FF37B699 for ; Wed, 31 Jan 2001 12:12:29 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0VKCGB07532; Wed, 31 Jan 2001 12:12:16 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101312012.f0VKCGB07532@iguana.aciri.org> Subject: Re: Bridging and dummynet seems to destroy dmesg output In-Reply-To: <3A787124.B307EC20@jonny.eng.br> from Joao Carlos Mendes Luis at "Jan 31, 2001 6:10:12 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Wed, 31 Jan 2001 12:12:16 -0800 (PST) Cc: rizzo@aciri.org, yusufg@outblaze.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi, > > I sent these files in private. But I remembered that I have another > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > and lots of SYSV shared memory. i think SMP might have something to do with it. Yusuf, are you also using an SMP box ? Two things to try (which i also emailed you privately, but others might be interested too): + remove the SMP option and see if you still have the problem. + if you are not using bridging, keep the SMP option and change splimp -> splnet in ip_dummynet.c and see if the problem is still there. cheers luigi > I could also test a kernel compiled by you, using my config. Just send it > to me in private and I'll try. > > Luigi Rizzo wrote: > > > > > Hi Luigi, > > > > > > I'm seeing the same problem here, and I do not use bridging. I have > > > DUMMYNET and IPFIREWALL configured. I can send the kernel and firewall config > > > files if you need. > > > > yes please -- because the picobsd image i am using does not > > produce the problem and yusuf could confirm that using the > > same picobsd image, so there might be something wrong with the > > way you upgraded your source (or i forgot to commit something). > > > > cheers > > luigi > > -- > > Jonny > > -- > João Carlos Mendes Luís jonny@embratel.net.br > Networking Engineer jonny@jonny.eng.br > Internet via Embratel jcml@ieee.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 13: 7: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id CF59837B69B for ; Wed, 31 Jan 2001 13:06:46 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id 0AC6A24D2D; Wed, 31 Jan 2001 19:06:44 -0200 (BRST) Message-ID: <3A787E8D.EBBB4346@jonny.eng.br> Date: Wed, 31 Jan 2001 19:07:25 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: yusufg@outblaze.com, freebsd-net@FreeBSD.ORG Subject: Re: Bridging and dummynet seems to destroy dmesg output References: <200101312012.f0VKCGB07532@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > Hi, > > > > I sent these files in private. But I remembered that I have another > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > and lots of SYSV shared memory. > > i think SMP might have something to do with it. Yusuf, are you also > using an SMP box ? > > Two things to try (which i also emailed you privately, but others might > be interested too): > + remove the SMP option and see if you still have the problem. Very strange! Removing SMP and APIC_IO options from my config, the kernel does not boot. It shows some errors in IDE interrupts, and panics after lots of errors while probing SCSI devices. Very strange, since GENERIC works without problems. Oh! This remembers me! The bug with ipfw and msgbuf also happens in GENERIC -stable! I tried only removing DUMMYNET from config, and the bug continues. Should I try the changes below? > + if you are not using bridging, keep the SMP option and change > splimp -> splnet in ip_dummynet.c > and see if the problem is still there. Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 13:46:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 96B6237B6A3 for ; Wed, 31 Jan 2001 13:46:00 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA68687; Wed, 31 Jan 2001 16:45:03 -0500 (EST) (envelope-from wollman) Date: Wed, 31 Jan 2001 16:45:03 -0500 (EST) From: Garrett Wollman Message-Id: <200101312145.QAA68687@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: net@freebsd.org Subject: Re: cvs commit: src/usr.sbin/arp arp.8 arp.c In-Reply-To: <200101312142.NAA28274@curve.dellroad.org> References: <200101311752.MAA66835@khavrinen.lcs.mit.edu> <200101312142.NAA28274@curve.dellroad.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > This seems a little funny then.. why then would you ever want not > to use "proxy" keyword? That is, why would you expect to be able > delete a real route using the arp command? Because you have a non-proxy (permanent or temporary) ARP cache entry that you want to flush. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 13:52:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0A5B037B69D for ; Wed, 31 Jan 2001 13:52:11 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA04435; Wed, 31 Jan 2001 13:52:10 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id NAA28309; Wed, 31 Jan 2001 13:52:10 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101312152.NAA28309@curve.dellroad.org> Subject: Re: cvs commit: src/usr.sbin/arp arp.8 arp.c In-Reply-To: <200101312145.QAA68687@khavrinen.lcs.mit.edu> "from Garrett Wollman at Jan 31, 2001 04:45:03 pm" To: Garrett Wollman Date: Wed, 31 Jan 2001 13:52:10 -0800 (PST) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > This seems a little funny then.. why then would you ever want not > > to use "proxy" keyword? That is, why would you expect to be able > > delete a real route using the arp command? > > Because you have a non-proxy (permanent or temporary) ARP cache entry > that you want to flush. I apologize for not getting this.. I'll try another question: why doesn't "arp -d x.y.z.w" just delete whatever ARP entry there is for x.y.z.w no matter what kind it is? -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 Jan 31 13:55: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A3BAF37B6A9 for ; Wed, 31 Jan 2001 13:54:50 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA68762; Wed, 31 Jan 2001 16:54:36 -0500 (EST) (envelope-from wollman) Date: Wed, 31 Jan 2001 16:54:36 -0500 (EST) From: Garrett Wollman Message-Id: <200101312154.QAA68762@khavrinen.lcs.mit.edu> To: Archie Cobbs Cc: net@freebsd.org Subject: Re: cvs commit: src/usr.sbin/arp arp.8 arp.c In-Reply-To: <200101312152.NAA28309@curve.dellroad.org> References: <200101312145.QAA68687@khavrinen.lcs.mit.edu> <200101312152.NAA28309@curve.dellroad.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I apologize for not getting this.. I'll try another question: why > doesn't "arp -d x.y.z.w" just delete whatever ARP entry there is > for x.y.z.w no matter what kind it is? Because it doesn't know what kind is there. It could find out, but then you'd have a race condition, and in any case the system administrator is presumed to know what permanent ARP entries there are and of which sort. (In most cases it doesn't matter.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 14:12:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 21AB937B69C for ; Wed, 31 Jan 2001 14:12:37 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0VMCHj08290; Wed, 31 Jan 2001 14:12:17 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101312212.f0VMCHj08290@iguana.aciri.org> Subject: Re: Bridging and dummynet seems to destroy dmesg output In-Reply-To: <3A787E8D.EBBB4346@jonny.eng.br> from Joao Carlos Mendes Luis at "Jan 31, 2001 7: 7:25 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Wed, 31 Jan 2001 14:12:17 -0800 (PST) Cc: rizzo@aciri.org, yusufg@outblaze.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I tried only removing DUMMYNET from config, and the bug continues. Should > I try the changes below? no-they only affect dummynet. But this seems to suggest that the problem is unrelated to my changes... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 15:32:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from gecko.eric.net.au (gecko.eric.net.au [203.102.228.3]) by hub.freebsd.org (Postfix) with ESMTP id 3161237B491 for ; Wed, 31 Jan 2001 15:32:42 -0800 (PST) Received: (from ghcrompton@localhost) by gecko.eric.net.au (8.9.3/8.8.7) id KAA23707 for freebsd-net@freebsd.org; Thu, 1 Feb 2001 10:37:16 +1100 Date: Thu, 1 Feb 2001 10:37:16 +1100 From: "Geoffrey Crompton (RMIT Guest)" To: freebsd-net@freebsd.org Subject: pseudo interface and ioctls Message-ID: <20010201103716.A23667@gecko.eric.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to write a pseudo interface, but I'm confused about my responsibilities for the _ioctl() command. It seems that for the assigning of an address, I simply need to return 0 to indicate that address family is ok, as the higher level functions handle the actuall assignment of addresses. Is this true? Do I need to do anything else, such as installing routes into the routing table (if I don't want the user to have to run route commands for it). Is my interface responsible for any other SIOC's, or can it safely return EINVAL or 0 for SIOC's it doesn't recognize? (Apart from any SIOC's that I custom define of course) Thanks Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 18:17:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 735CC37B698 for ; Wed, 31 Jan 2001 18:17:20 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f112HKv00433; Thu, 1 Feb 2001 02:17:20 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f111sOY05179; Thu, 1 Feb 2001 01:54:24 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102010154.f111sOY05179@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: parminder.mudhar@bt.com Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Routes and tunnels In-Reply-To: Message from parminder.mudhar@bt.com of "Wed, 31 Jan 2001 17:01:51 GMT." <71DA16F18D32D2119A1D0000F8FE9A9409D21C67@mbtlipnt01.btlabs.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 01:54:24 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you mean a packet destined for the source address of the POINTOPOINT link, then yes, this is intentional. If you want to be able to ping the local end you'll need a route on lo. > Hi > > I don't know if this is intentional or a bug, but if ifconfig is used to > configure a point to point device, such as 'tun' or the newer 'gif' devices, > then the kernel insists on installing a route where the destination is the > end point of the tunnel, the gateway is the source of the tunnel and the > interface is the device itself. I have checked this in version 3.2+KAME, > what I a using, and also on version 4.1. The effect of the above is that the > packet that uses the tunnel will never appear on the wire. > > Here is an output > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > the_swamp# netstat -rnf inet > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 132.146.115.1 UGSc 1 0 fxp1 > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > 132.145.113.1 132.146.115.164 UH 0 0 gif0 > 132.146.115/24 link#2 UC 0 0 fxp1 => > 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 460 > > I am also interested in using gated with point to point tunnels, but gated > also insists on doing the above for point to point links. > > I thank you in advance for any advice you may have. > > Parminder Mudhar > __________________________ > parminder.mudhar@bt.com -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 21:25:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 3A42737B491 for ; Wed, 31 Jan 2001 21:24:50 -0800 (PST) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id NAA10460 for ; Thu, 1 Feb 2001 13:19:12 +0800 Date: Thu, 1 Feb 2001 13:31:39 +0800 From: bsddiy X-Mailer: The Bat! (v1.48f) Personal Reply-To: bsddiy X-Priority: 3 (Normal) Message-ID: <1217774688.20010201133139@163.net> To: freebsd-net@freebsd.org Subject: sendfile() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I don't want to bring flame war, but the following Linus' words may be right: ----- The fact I dislike about the HP-UX implementation is that it is so obviously stupid. And I have to say that I absolutely despise the BSD people. They did sendfile() after both Linux and HP-UX had done it, and they must have known about both implementations. And they chose the HP-UX braindamage, and even brag about the fact that they were stupid and didn't understand TCP_CORK (they don't say so in those exact words, of course - they just show that they were stupid and clueless by the things they brag about). Oh, well. Not everybody can be as goodlooking as me. It's a curse. ----- Also note how I said that it is the BSD people I despise. Not the HP-UX implementation. The HP-UX one is not pretty, but it works. But I hold open source people to higher standards. They are supposed to be the people who do programming because it's an art-form, not because it's their job. David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 21:51:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from proxy.outblaze.com (proxy.outblaze.com [202.77.223.120]) by hub.freebsd.org (Postfix) with SMTP id 74D6337B491 for ; Wed, 31 Jan 2001 21:50:58 -0800 (PST) Received: (qmail 61814 invoked from network); 1 Feb 2001 05:50:55 -0000 Received: from unknown (HELO yusufg.portal2.com) (202.77.181.217) by proxy.outblaze.com with SMTP; 1 Feb 2001 05:50:55 -0000 Received: (qmail 13489 invoked by uid 500); 1 Feb 2001 05:55:51 -0000 Date: Thu, 1 Feb 2001 13:55:51 +0800 From: Yusuf Goolamabbas To: Luigi Rizzo Cc: Joao Carlos Mendes Luis , freebsd-net@FreeBSD.ORG Subject: Re: Bridging and dummynet seems to destroy dmesg output Message-ID: <20010201135551.A13446@outblaze.com> References: <3A787124.B307EC20@jonny.eng.br> <200101312012.f0VKCGB07532@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101312012.f0VKCGB07532@iguana.aciri.org>; from rizzo@aciri.org on Wed, Jan 31, 2001 at 12:12:16PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > Hi, > > > > I sent these files in private. But I remembered that I have another > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > and lots of SYSV shared memory. > > i think SMP might have something to do with it. Yusuf, are you also > using an SMP box ? No, I am using a "book-PC" type machine [small Celeron] dmesg attached I reinstalled my shaper box with 4.2 release today and cvsuped to 4.2-stable. The strange thing is that if I turn on verbose logging (via sysctl) but don't turn on verbose_limit, dmesg seems to get corrupted. If I have verbose_limit set to say 10, dmesg works and does not get overridden with log messages from ipfw [which goes to /var/log/security] This is what I have in my /etc/sysctl.conf net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=10 So, it seems some combination of verbose logging and non setting of verbose limit [or the default setting of verbose limit] is causing this problem Hope this helps, Regards, Yusuf --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="shaper.dmesg" Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-STABLE #0: Thu Feb 1 12:41:05 GMT 2001 root@:/usr/obj/usr/src/sys/SHAPER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 567957931 Hz CPU: Pentium III/Pentium III Xeon/Celeron (567.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 67096576 (65524K bytes) avail memory = 62492672 (61028K bytes) Preloaded elf kernel "kernel" at 0xc02a9000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 fxp0: port 0xb800-0xb81f mem 0xe0000000-0xe00fffff,0xe3000000-0xe3000fff irq 10 at device 3.0 on pci0 fxp0: Ethernet address 00:e0:18:01:18:7d isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb400-0xb40f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb000-0xb01f irq 10 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: port 0xe800-0xe80f at device 4.3 on pci0 pci0: (vendor=0x125d, dev=0x1969) at 9.0 irq 5 fxp1: port 0x9000-0x903f mem 0xdf000000-0xdf0fffff,0xdf800000-0xdf800fff irq 11 at device 20.0 on pci0 fxp1: Ethernet address 00:02:b3:07:c2:a1 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port not found. DUMMYNET initialized (010124) IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to accept, logging disabled BRIDGE 990810, have 3 interfaces -- index 1 type 6 phy 0 addrl 6 addr 00.e0.18.01.18.7d -- index 2 type 6 phy 0 addrl 6 addr 00.02.b3.07.c2.a1 ad0: 9768MB [19846/16/63] at ata0-master UDMA33 acd0: CDROM at ata1-slave using PIO4 Mounting root from ufs:/dev/ad0s1a >> now fxp0 promisc ON if_flags 0xffff8943 bdg_flags 0x5 >> now fxp1 promisc ON if_flags 0xffff8943 bdg_flags 0x5 --mP3DRpeJDSE+ciuQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 22: 6:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.sunflower.com (smtp.sunflower.com [24.124.0.137]) by hub.freebsd.org (Postfix) with ESMTP id A165937B684; Wed, 31 Jan 2001 22:06:14 -0800 (PST) Received: from treznor (dv016s59.lawrence.ks.us [24.124.59.16]) by smtp.sunflower.com (8.9.3/8.9.3) with SMTP id AAA15972; Thu, 1 Feb 2001 00:05:08 -0600 Message-ID: <000801c08c14$5c1839e0$103b7c18@palisor.yi.org> From: "Tyler K McGeorge" To: , Subject: rpc.statd Date: Thu, 1 Feb 2001 00:01:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C08BE2.11330540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C08BE2.11330540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After I set up my BIND name daemon, I started getting the following = message: Jan 31 16:12:45 palisor rpc.statd: invalid hostname to sm_stat: (then = a whole bunch of gibberish, I would transcribe it, but it uses strange = characters that aren't available in Windows.) I assume this means that named isn't starting before an important = process... But I didn't change anything in the default rc... I am so = very confused. Please help, Ty ------=_NextPart_000_0005_01C08BE2.11330540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After I set up my BIND name daemon, I = started=20 getting the following message:
 
Jan 31 16:12:45 = palisor   =20 rpc.statd: invalid hostname to sm_stat: (then a whole bunch of = gibberish, I=20 would transcribe it, but it uses strange characters that aren't = available in=20 Windows.)
 
I assume this means that named isn't = starting=20 before an important process... But I didn't change anything in the = default rc...=20 I am so very confused.
 
Please help,
Ty
------=_NextPart_000_0005_01C08BE2.11330540-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 22:44: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.nbrewer.com (unknown [208.42.68.70]) by hub.freebsd.org (Postfix) with ESMTP id 9F86E37B491; Wed, 31 Jan 2001 22:43:50 -0800 (PST) Received: by mail.nbrewer.com (Postfix, from userid 1009) id EC182590; Thu, 1 Feb 2001 00:43:49 -0600 (CST) Date: Thu, 1 Feb 2001 00:43:49 -0600 From: Christopher Farley To: Tyler K McGeorge Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: rpc.statd Message-ID: <20010201004349.C7019@northernbrewer.com> Mail-Followup-To: Christopher Farley , Tyler K McGeorge , freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <000801c08c14$5c1839e0$103b7c18@palisor.yi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000801c08c14$5c1839e0$103b7c18@palisor.yi.org>; from treznor@sunflower.com on Thu, Feb 01, 2001 at 12:01:03AM -0600 Organization: Northern Brewer, St. Paul, MN Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tyler K McGeorge (treznor@sunflower.com) wrote: > After I set up my BIND name daemon, I started getting the following message: > > Jan 31 16:12:45 palisor rpc.statd: invalid hostname to sm_stat: (then a whole bunch of gibberish, I would transcribe it, but it uses strange characters that aren't available in Windows.) > > I assume this means that named isn't starting before an important process... But I didn't change anything in the default rc... I am so very confused. Don't worry, methinks you are merely being probed for Linux-bugs. rpc.statd was flawed in some popular Linux distributions; users of those distributions who failed to install the correct binary patch (what a stupid way to distribute bug fixes!) will eventually find their machines probed and exploited. FreeBSD is not vulnerable. I used to get that message several times a month until I firewalled the portmapper service. See http://www.cert.org/advisories/CA-2000-17.html for more details. -- Christopher Farley www.northernbrewer.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 22:48:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by hub.freebsd.org (Postfix) with ESMTP id 5034737B491; Wed, 31 Jan 2001 22:48:30 -0800 (PST) Received: from home.com ([24.177.141.133]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010201064830.ZOZJ24800.femail12.sdc1.sfba.home.com@home.com>; Wed, 31 Jan 2001 22:48:30 -0800 Message-ID: <3A7906BD.720A5B0B@home.com> Date: Wed, 31 Jan 2001 22:48:29 -0800 From: "Raymundo M. Vega" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.5.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tyler K McGeorge Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: rpc.statd References: <000801c08c14$5c1839e0$103b7c18@palisor.yi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Tyler K McGeorge wrote: > > After I set up my BIND name daemon, I started getting the following message: > > Jan 31 16:12:45 palisor rpc.statd: invalid hostname to sm_stat: (then a > whole bunch of gibberish, I would transcribe it, but it uses strange > characters that aren't available in Windows.) > > I assume this means that named isn't starting before an important process... > But I didn't change anything in the default rc... I am so very confused. > > Please help, > Ty This has been posted several times, somebody is trying to gain access to your computer using a weakness in Linux, it has no effectin FreeBSD, if you want to read more, check this page: http://www.cert.org/advisories/CA-2000-17.html saludos raymundo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 23:26:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (ny-ppp001.iij-us.net [216.98.99.1]) by hub.freebsd.org (Postfix) with ESMTP id D39A437B698 for ; Wed, 31 Jan 2001 23:26:17 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F26147E56; Thu, 1 Feb 2001 14:11:01 +0900 (JST) To: Yu-Shun Wang Cc: freebsd-net@freebsd.org In-reply-to: yushunwa's message of Wed, 31 Jan 2001 11:00:58 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp question From: Jun-ichiro itojun Hagino Date: Thu, 01 Feb 2001 14:11:01 +0900 Message-Id: <20010201051101.F26147E56@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > No, but the problem is that there was no increase (actually, no > record at all) under ipsec: IPComp. The number on the sending > side seemed right. The increase matched the ones I saw from > tcpdump. It looked like the IPComp packets either weren't > logged or were dropped for some reason. send the following items. - full tcpdump output - netstat -sn before, and after the test (on both ends) - full SA configuration on both sides (previous email may have included it) - ifconfig -a output, on both ends - netstat -rn output, on both ends - simple network diagram (like intermediate routers) between both ends itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jan 31 23:50:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 2D60837B491 for ; Wed, 31 Jan 2001 23:50:26 -0800 (PST) Received: (qmail 19616 invoked by uid 666); 1 Feb 2001 07:58:33 -0000 Received: from reggae-18-200.nv.iinet.net.au (HELO elischer.org) (203.59.80.200) by mail.m.iinet.net.au with SMTP; 1 Feb 2001 07:58:33 -0000 Message-ID: <3A791528.BC4593E2@elischer.org> Date: Wed, 31 Jan 2001 23:50:01 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Geoffrey Crompton (RMIT Guest)" Cc: freebsd-net@freebsd.org Subject: Re: pseudo interface and ioctls References: <20010201103716.A23667@gecko.eric.net.au> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Geoffrey Crompton (RMIT Guest)" wrote: why are you doing this? there are already 4 pseudo interfaces in the system of varying types.. netgraph(2 types), divert, tap, tun. what do you need to do? > > I'm trying to write a pseudo interface, but I'm confused about > my responsibilities for the _ioctl() command. > > It seems that for the assigning of an address, I simply need to > return 0 to indicate that address family is ok, as the higher level > functions handle the actuall assignment of addresses. Is this true? > Do I need to do anything else, such as installing routes into the > routing table (if I don't want the user to have to run route commands > for it). > > Is my interface responsible for any other SIOC's, or can it safely > return EINVAL or 0 for SIOC's it doesn't recognize? (Apart from any > SIOC's that I custom define of course) > > Thanks > Geoff > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 2:38:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.org (adsl-64-169-104-72.dsl.lsan03.pacbell.net [64.169.104.72]) by hub.freebsd.org (Postfix) with ESMTP id F1B0B37B503 for ; Thu, 1 Feb 2001 02:37:54 -0800 (PST) Received: by obsecurity.org (Postfix, from userid 1000) id 87168BA0CB; Thu, 1 Feb 2001 02:38:25 -0800 (PST) Date: Thu, 1 Feb 2001 02:38:25 -0800 From: Kris Kennaway To: bsddiy Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201023825.A71975@xor.obsecurity.org> References: <1217774688.20010201133139@163.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1217774688.20010201133139@163.net>; from bsddiy@163.net on Thu, Feb 01, 2001 at 01:31:39PM +0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: > I don't want to bring flame war, but the following Linus' words may > be right: Did you have a point to make here? If so, I missed it. Kris --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6eTyhWry0BWjoQKURAkN7AJ4767uQylcDsUM5Ks8+J7AN26wWIgCggJ0M Mzroi7n33HgosUd0zta4c48= =EdCJ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 3:20:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by hub.freebsd.org (Postfix) with ESMTP id 7F3BE37B491 for ; Thu, 1 Feb 2001 03:20:21 -0800 (PST) Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 1 Feb 2001 11:16:23 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 11:14:47 -0000 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9409D21C68@mbtlipnt01.btlabs.bt.co.uk> From: parminder.mudhar@bt.com To: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels Date: Thu, 1 Feb 2001 11:15:51 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Thanks for the replies. Sorry, I forgot to say that I was using to the tunnel to connect to the remote site with interface address of 132.146.113.1 and I am not using the tunnels to send the packets to the local address, 132.146.115.164. I am trying to use tunnels as point to point links for running routing over them. But the end result is that I do not see a packet destined for the end point of the tunnel, 132.146.113.1 on the wire. Parminder Mudhar __________________________ parminder.mudhar@bt.com > -----Original Message----- > From: Mudhar,PS,Parminder,CEG2 R > Sent: Wednesday, January 31, 2001 5:02 PM > To: 'freebsd-net@FreeBSD.org' > Subject: Routes and tunnels > > Hi > > I don't know if this is intentional or a bug, but if ifconfig is used to > configure a point to point device, such as 'tun' or the newer 'gif' > devices, then the kernel insists on installing a route where the > destination is the end point of the tunnel, the gateway is the source of > the tunnel and the interface is the device itself. I have checked this in > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > the above is that the packet that uses the tunnel will never appear on the > wire. > > Here is an output > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > the_swamp# netstat -rnf inet > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 132.146.115.1 UGSc 1 0 fxp1 > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > 132.145.113.1 132.146.115.164 UH 0 0 gif0 > 132.146.115/24 link#2 UC 0 0 fxp1 => > 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 > 460 > > I am also interested in using gated with point to point tunnels, but gated > also insists on doing the above for point to point links. > > I thank you in advance for any advice you may have. > > Parminder Mudhar > __________________________ > parminder.mudhar@bt.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 4:28: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id 0A34837B684; Thu, 1 Feb 2001 04:27:38 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id 8F54A24D2C; Thu, 1 Feb 2001 10:27:36 -0200 (BRST) Message-ID: <3A795660.687791E6@jonny.eng.br> Date: Thu, 01 Feb 2001 10:28:16 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yusuf Goolamabbas Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG, freebsd-stable@freebsd.org Subject: Re: Bridging and dummynet seems to destroy dmesg output References: <3A787124.B307EC20@jonny.eng.br> <200101312012.f0VKCGB07532@iguana.aciri.org> <20010201135551.A13446@outblaze.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CC: -stable, this seens not to be a -net related problem. Yusuf Goolamabbas wrote: > > > Hi, > > > > > > I sent these files in private. But I remembered that I have another > > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > > and lots of SYSV shared memory. > > > > i think SMP might have something to do with it. Yusuf, are you also > > using an SMP box ? > > No, I am using a "book-PC" type machine [small Celeron] dmesg attached > > I reinstalled my shaper box with 4.2 release today and cvsuped to > 4.2-stable. > > The strange thing is that if I turn on verbose logging (via sysctl) but > don't turn on verbose_limit, dmesg seems to get corrupted. If I have > verbose_limit set to say 10, dmesg works and does not get overridden > with log messages from ipfw [which goes to /var/log/security] > > This is what I have in my /etc/sysctl.conf > > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > net.inet.ip.fw.verbose=1 > net.inet.ip.fw.verbose_limit=10 > > So, it seems some combination of verbose logging and non setting of > verbose limit [or the default setting of verbose limit] is causing this > problem Indeed, the problem does not start at the very first message. It takes some time, after I start the nmap attack, to corrupt the buffer. You observation may just mean that the number of messages needed to corrupt the buffer is greater than 10. Maybe even this is the reason Luigi does not see any problem with picobsd. The fact that GENERIC also shows this problem is banging on my head. Why nobody else has seen this? What kind of kernel messages create this problem? IIRC IPFW does not use any kind of printf, just log(9). What other kernels modules use this function? How could we generate such messages to test? Just in case nobody has yet noticed, this is for sure a case of lost pointer. And if the kernel is not yet crashing is just mere luck! Time to audit changes since -release? I'd love to help more, but I've been far from FreeBSD cvs lists for a long time now. Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 6:12: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id F0ACF37B4EC for ; Thu, 1 Feb 2001 06:11:42 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id HAA47315; Thu, 1 Feb 2001 07:11:39 -0700 (MST) Date: Thu, 1 Feb 2001 07:11:39 -0700 (MST) From: Nick Rogness To: parminder.mudhar@bt.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels In-Reply-To: <71DA16F18D32D2119A1D0000F8FE9A9409D21C68@mbtlipnt01.btlabs.bt.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Feb 2001 parminder.mudhar@bt.com wrote: > Hi > > Thanks for the replies. > > Sorry, I forgot to say that I was using to the tunnel to connect to the > remote site with interface address of 132.146.113.1 and I am not using the > tunnels to send the packets to the local address, 132.146.115.164. I am > trying to use tunnels as point to point links for running routing over them. > > But the end result is that I do not see a packet destined for the end point > of the tunnel, 132.146.113.1 on the wire. WHat do you mean on the wire? THe other side? Is the other side setup to tunnel? How did you configure the outside IP'w with gifconfig ? Need a tad more details to help you out. the behavior you described below about the kernel adding routes is correct as a 'gif' tunnel is a directly connect interface. Most OS's do the same thing with directly connect interfaces. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " > > -----Original Message----- > > From: Mudhar,PS,Parminder,CEG2 R > > Sent: Wednesday, January 31, 2001 5:02 PM > > To: 'freebsd-net@FreeBSD.org' > > Subject: Routes and tunnels > > > > Hi > > > > I don't know if this is intentional or a bug, but if ifconfig is used to > > configure a point to point device, such as 'tun' or the newer 'gif' > > devices, then the kernel insists on installing a route where the > > destination is the end point of the tunnel, the gateway is the source of > > the tunnel and the interface is the device itself. I have checked this in > > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > > the above is that the packet that uses the tunnel will never appear on the > > wire. > > > > Here is an output > > > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > > the_swamp# netstat -rnf inet > > Routing tables > > > > Internet: > > Destination Gateway Flags Netif Expire > > default 132.146.115.1 UGSc 1 0 fxp1 > > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > 132.145.113.1 132.146.115.164 UH 0 0 gif0 > > 132.146.115/24 link#2 UC 0 0 fxp1 => > > 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 > > 460 > > > > I am also interested in using gated with point to point tunnels, but gated > > also insists on doing the above for point to point links. > > > > I thank you in advance for any advice you may have. > > > > Parminder Mudhar > > __________________________ > > parminder.mudhar@bt.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 6:18:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from keyser.soze.com (keyser.soze.com [194.165.93.196]) by hub.freebsd.org (Postfix) with ESMTP id E376537B698; Thu, 1 Feb 2001 06:18:16 -0800 (PST) Received: from erg.verweg.com ([132.229.90.89]) by keyser.soze.com (8.9.1/8.9.1) with ESMTP id PAA18398; Thu, 1 Feb 2001 15:18:14 +0100 (CET) Received: (from ruben@localhost) by erg.verweg.com (8.9.3+3.2W/8.9.3) id PAA01968; Thu, 1 Feb 2001 15:26:56 +0100 (CET) Date: Thu, 1 Feb 2001 15:26:55 +0100 From: Ruben van Staveren To: Joao Carlos Mendes Luis Cc: Yusuf Goolamabbas , Luigi Rizzo , freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Bridging and dummynet seems to destroy dmesg output Message-ID: <20010201152654.A1816@erg.verweg.com> References: <3A787124.B307EC20@jonny.eng.br> <200101312012.f0VKCGB07532@iguana.aciri.org> <20010201135551.A13446@outblaze.com> <3A795660.687791E6@jonny.eng.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A795660.687791E6@jonny.eng.br>; from jonny@jonny.eng.br on Thu, Feb 01, 2001 at 10:28:16AM -0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > > > I sent these files in private. But I remembered that I have another > > > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > > > and lots of SYSV shared memory. > > > > > > i think SMP might have something to do with it. Yusuf, are you also > > > using an SMP box ? > > > > The strange thing is that if I turn on verbose logging (via sysctl) but > > don't turn on verbose_limit, dmesg seems to get corrupted. If I have > > > > So, it seems some combination of verbose logging and non setting of > > verbose limit [or the default setting of verbose limit] is causing this > > problem > > Just in case nobody has yet noticed, this is for sure a case of lost > pointer. And if the kernel is not yet crashing is just mere luck! Time to > audit changes since -release? Eh no. I've experienced panic's at the end of /etc/rc, just before going multiuser. When I disable firewalling in /etc/rc.conf the system boots up fine. (although it isn't that useful anymore, because of the default deny everything policy of ipfw). This was on a SMP box with a Jan 30 cvsup, I'm currently downgrading it to an older 4.2-stable (dated 30 Dec 2000) Regards, Ruben -- ,-_ .------------------------------------------------------------. /() ) | Ruben van Staveren | Linux is for Microsoft Haters,|_o (__ ( | http://ruben.is.verweg.com | BSD is for Unix Lovers | #> =/ () `----------------------------+-------------------------------' 4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 7:16:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 958FB37B4EC for ; Thu, 1 Feb 2001 07:16:19 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id KAA75989; Thu, 1 Feb 2001 10:16:12 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Feb 2001 10:16:12 -0500 (EST) From: Garrett Wollman Message-Id: <200102011516.KAA75989@khavrinen.lcs.mit.edu> To: Matt Dillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-01:18.bind In-Reply-To: <200102010758.f117wlJ26496@earth.backplane.com> References: <20010131140447.E26076@fw.wintelcom.net> <20010131145423.H26076@fw.wintelcom.net> <200101312305.f0VN5vJ19469@earth.backplane.com> <20010131151531.I26076@fw.wintelcom.net> <200101312327.f0VNRPv20077@earth.backplane.com> <20010131233028.S91447@rfx-216-196-73-168.users.reflex> <200102010758.f117wlJ26496@earth.backplane.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > server. If you think specifying multiple recursive servers in > /etc/resolv.conf will save a heavily loaded host, like a mail box, you > will be in for one hellofa surprise when your primary resolver goes down! A ``heavily loaded host'' should only have one nameserver entry in /etc/resolv.conf: 127.0.0.1. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 8: 4:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by hub.freebsd.org (Postfix) with ESMTP id 4BEA737B65D for ; Thu, 1 Feb 2001 08:03:54 -0800 (PST) Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Thu, 1 Feb 2001 15:35:58 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 15:34:38 -0000 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9409D21C69@mbtlipnt01.btlabs.bt.co.uk> From: parminder.mudhar@bt.com To: nick@rapidnet.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels Date: Thu, 1 Feb 2001 15:35:41 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Thanks for taking the time to reply to query. Here is more information that may help you. Having created the tunnel, I create a route to a node that I know is on the other side of the tunnel. When I try to ping this site, or even the tunnel end, I get a 'sendto: Network is down' reply from ping. I then use tcpdump to monitor the packets that should appear on the ethernet, but I don't see any packets that have destination address of the tunnel end. It seems to me that what is happening is the following: I want to send a packet where the destination address is the tunnel end ip_output gets this packet and looks up a route for this destination this route contains the next hop gateway, and the interface to use (gif) ip_output places the packet in the output queue of the interface (gif) which then proceeds to append an outer header to the packet its been given. This outer header will have the source address set to the tunnel source address and the destination set to the address of the tunnel end. The packet gets given to ip_ouput to send it to the destination address, which is the address of the tunnel end, and the route contains a reference to the interface (gif), etc. In other words, since the route entries contain an entry to a destination address which is the address of the end point of the tunnel and the interface to use is the tunnel interface (gif), what you are doing is appending an outer IP packet to your packet all the time, and since the destination address of the outer header has a route that uses the tunnel interface (gif)then you end up in an infinite loop - the packet will never be placed in the queue for transmission. I could be wrong, but if you look at the route entries given below, and go through the motions of packet forwarding, then you may arrive at the above conclusion. the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 the_swamp# netstat -rnf inet Routing tables Internet: Destination Gateway Flags Netif Expire default 132.146.115.1 UGSc 1 0 fxp1 127.0.0.1 127.0.0.1 UH 0 4 lo0 132.145.113.1 132.146.115.164 UH 0 0 gif0 132.146.115/24 link#2 UC 0 0 fxp1 => 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 460 What you say about this being "correct behaviour" is interesting, but it may put a damper on me trying to use this pointopoint tunnels for this purpose. Again, thanks very much for replying to my request for help and I look forward to hearing from you soon. Parminder Mudhar __________________________ parminder.mudhar@bt.com -----Original Message----- From: Nick Rogness [mailto:nick@rapidnet.com] Sent: Thursday, February 01, 2001 2:12 PM To: parminder.mudhar@bt.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels On Thu, 1 Feb 2001 parminder.mudhar@bt.com wrote: > Hi > > Thanks for the replies. > > Sorry, I forgot to say that I was using to the tunnel to connect to the > remote site with interface address of 132.146.113.1 and I am not using the > tunnels to send the packets to the local address, 132.146.115.164. I am > trying to use tunnels as point to point links for running routing over them. > > But the end result is that I do not see a packet destined for the end point > of the tunnel, 132.146.113.1 on the wire. WHat do you mean on the wire? THe other side? Is the other side setup to tunnel? How did you configure the outside IP'w with gifconfig ? Need a tad more details to help you out. the behavior you described below about the kernel adding routes is correct as a 'gif' tunnel is a directly connect interface. Most OS's do the same thing with directly connect interfaces. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " > > -----Original Message----- > > From: Mudhar,PS,Parminder,CEG2 R > > Sent: Wednesday, January 31, 2001 5:02 PM > > To: 'freebsd-net@FreeBSD.org' > > Subject: Routes and tunnels > > > > Hi > > > > I don't know if this is intentional or a bug, but if ifconfig is used to > > configure a point to point device, such as 'tun' or the newer 'gif' > > devices, then the kernel insists on installing a route where the > > destination is the end point of the tunnel, the gateway is the source of > > the tunnel and the interface is the device itself. I have checked this in > > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > > the above is that the packet that uses the tunnel will never appear on the > > wire. > > > > Here is an output > > > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > > the_swamp# netstat -rnf inet > > Routing tables > > > > Internet: > > Destination Gateway Flags Netif Expire > > default 132.146.115.1 UGSc 1 0 fxp1 > > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > 132.145.113.1 132.146.115.164 UH 0 0 gif0 > > 132.146.115/24 link#2 UC 0 0 fxp1 => > > 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 > > 460 > > > > I am also interested in using gated with point to point tunnels, but gated > > also insists on doing the above for point to point links. > > > > I thank you in advance for any advice you may have. > > > > Parminder Mudhar > > __________________________ > > parminder.mudhar@bt.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 10: 1:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C3C3937B4EC for ; Thu, 1 Feb 2001 10:00:54 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OO1i-000AXX-00; Thu, 01 Feb 2001 18:00:10 +0000 Date: Thu, 1 Feb 2001 18:00:10 +0000 From: Tony Finch To: Kris Kennaway Cc: bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201180010.Q70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010201023825.A71975@xor.obsecurity.org> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: >On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: > >> I don't want to bring flame war, but the following Linus' words may >> be right: > >Did you have a point to make here? If so, I missed it. I've been discussing this with a few people recently (fortunately I didn't lose the mail from Linus when my laptop was stolen) after I stumbled across the TCP_NOPUSH option, which is superficially similar to TCP_CORK. Linus's argument against the HP/UX and BSD sendfile() is that, for example, in the presence of pipelined HTTP requests it isn't possible to avoid poor packet boundaries between responses. TCP_NOPUSH does help to solve this problem (it was designed to hack around problems with the interaction between mbuf sizes and sosend and tcp_output) but it introduces a new problem: at the end of a chain of HTTP responses you want the last segment to go out quickly rather than waiting for more data to fill the segment. For this reason turning off TCP_CORK pushes out queued data, but this isn't the case for TCP_NOPUSH. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "And remember my friend, future events such as these will affect you in the future." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 10:15:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from hadar.cwie.net (hadar.cwie.net [64.38.204.100]) by hub.freebsd.org (Postfix) with ESMTP id 3600137B4EC for ; Thu, 1 Feb 2001 10:15:01 -0800 (PST) Received: from win2000befwze1 (L3-phx-t1-hq-i.cwie.net [64.38.194.18]) by hadar.cwie.net (8.9.3/8.9.3) with SMTP id LAA17958 for ; Thu, 1 Feb 2001 11:14:56 -0700 (MST) Message-ID: <009901c08c7b$4f5aca30$5200000a@win2000befwze1> From: "Justin Booth" To: Subject: Socket Code problem. Date: Thu, 1 Feb 2001 11:17:51 -0700 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Freebsd-net, The following code has a problem with it. After 16000 or so connections the my tcp connections run out of buffer space, which does not allow me to make any new TCP connections and the system locks up. an netstat -an revieles that there are about 100 sockets in TIME_WAIT and an lsof -n shows about 54000 TCP connections in TCP no PCB, CANTSENDMORE, CANTRECVMORE for this program. Can someone point me in the right direction for clearing this up. /* code snippet #define DEAMON_PORT 2313 void main(){ sockaddr_in name; int listen_socket; // Create Socket listen_socket = socket(PF_INET, SOCK_STREAM, TCP ); ioctl(listen_socket, SO_REUSEADDR); if (listen_socket== -1 ){ printf("Socket Failed to Create listening socket\n exiting\n"); exit (-1); } else{ printf("Socket Created %d\n",listen_socket); } // Create socket info name.sin_family = PF_INET; name.sin_addr.s_addr = INADDR_ANY; name.sin_port = htons(DEAMON_PORT); //Bind Socket if ( bind(listen_socket, (struct sockaddr *) &name, sizeof(name)) == -1){ printf("Socket could not be bound\n"); exit(-1); } // Listen on socket if (listen(listen_socket, 5) == -1){ printf("Error Listening\n"); exit(-1); } while(1){ sockaddr incomming; int in_sock; int in_length; int pid; in_length = sizeof(incomming); // Accept incomming socket in_sock = accept(listen_socket, &incomming, &in_length); printf("open:%d\n",in_sock); if (in_sock == -1){ internal_log("Error Accepting\n"); exit(-1); } pid = fork(); // Fork a thread if (pid == 0){ //printf("master Thread alive looping to listen\n"); } else { //Close the Socket printf("close %s\n", in_sock); shutdown(in_sock,2); close(in_sock); exit(0); } } } end code snippet */ Greatly Appreciated, Justin Booth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11: 1:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0FFFE37B6AC; Thu, 1 Feb 2001 11:01:35 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f11J1YM60760; Thu, 1 Feb 2001 11:01:34 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102011901.f11J1YM60760@iguana.aciri.org> Subject: a note on ipfw/bridge/dummynet changes To: luigi@aciri.org Date: Thu, 1 Feb 2001 11:01:34 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Bcc to net and ipfw as relevant there -- if you want a reply to go to the lists you need to add them explicitly.] Hi, as some of you have noticed, i am trying to fix some long-standing problems that we have had with bridging and dummynet, so I'd like to comment on what I am doing and how. * i am working and doing testing on STABLE, as some of the problems that we had in the past (races) were peculiar to that version, at least until CURRENT uses Giant to protect critical sections. I am testing/putting the code in CURRENT as well, but i believe we can only have some significant testing on STABLE. So, you will see some quick MFC -- please be tolerant. (The other reason for this is that I do have a CURRENT box but it often dies in cpu_idle. The same hw seems to be more robust when using a PicoBSD floppy with STABLE, so i have no idea if it is bad hardware or what.) * some of the problems peple are experiencing appear to be related to memory corruption, which in turn derives from shared mbuf clusters being modified at different places in the stack. The approach i am following to track and fix them involves some changes to the interfaces of ether_input(), bdg_forward(), and the firewall check functions, so that these modules limit the amount of patching into shared mbufs. This means that some of the patches are rather extensive, and affect several files namely: net/if_ethersubr.c net/bridge.[ch] netinet/ip_dummynet.[ch] netinet/ip_fw.[ch] and to a much lesser degree netinet/ip_input.c netinet/ip_output.c src/sbin/ipfw/ipfw.c In some cases you will be required to update the userland program, ipfw. * check your system before reporting problems. While I can make mistakes, I do check my code before committing. Most of the "problems" reported recently were of the kind "cannot compile the kernel", "ipfw says invalid command", and they were just local error from people not updating the sources or header files properly. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11: 4: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 3C5A837B4EC for ; Thu, 1 Feb 2001 11:03:47 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OP0R-000AmA-00; Thu, 01 Feb 2001 19:02:55 +0000 Date: Thu, 1 Feb 2001 19:02:55 +0000 From: Tony Finch To: Justin Booth Cc: freebsd-net@freebsd.org Subject: Re: Socket Code problem. Message-ID: <20010201190255.S70673@hand.dotat.at> References: <009901c08c7b$4f5aca30$5200000a@win2000befwze1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009901c08c7b$4f5aca30$5200000a@win2000befwze1> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Booth wrote: > > The following code has a problem with it. After 16000 or so connections >the my tcp connections run out of buffer space, which does not allow me to >make any new TCP connections and the system locks up. an netstat -an >revieles that there are about 100 sockets in TIME_WAIT and an lsof -n shows >about 54000 TCP connections in TCP no PCB, CANTSENDMORE, CANTRECVMORE for >this program. Can someone point me in the right direction for clearing this >up. The child process that you fork needs to do something, and most particularly it should exit. You should check for errors from fork() -- they might have clued you into the problem. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Because all you of Earth are idiots!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11: 5:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id EF3D737B503 for ; Thu, 1 Feb 2001 11:04:57 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id KAA24065; Thu, 1 Feb 2001 10:54:10 -0800 (PST) Message-Id: <200102011854.KAA24065@implode.root.com> To: Tony Finch Cc: Kris Kennaway , bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-reply-to: Your message of "Thu, 01 Feb 2001 18:00:10 GMT." <20010201180010.Q70673@hand.dotat.at> From: David Greenman Reply-To: dg@root.com Date: Thu, 01 Feb 2001 10:54:10 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Kris Kennaway wrote: >>On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: >> >>> I don't want to bring flame war, but the following Linus' words may >>> be right: >> >>Did you have a point to make here? If so, I missed it. > >I've been discussing this with a few people recently (fortunately I >didn't lose the mail from Linus when my laptop was stolen) after I >stumbled across the TCP_NOPUSH option, which is superficially similar >to TCP_CORK. > >Linus's argument against the HP/UX and BSD sendfile() is that, for >example, in the presence of pipelined HTTP requests it isn't possible >to avoid poor packet boundaries between responses. TCP_NOPUSH does >help to solve this problem (it was designed to hack around problems >with the interaction between mbuf sizes and sosend and tcp_output) but >it introduces a new problem: at the end of a chain of HTTP responses >you want the last segment to go out quickly rather than waiting for >more data to fill the segment. For this reason turning off TCP_CORK >pushes out queued data, but this isn't the case for TCP_NOPUSH. Thanks for the above - at least now I have something to comment on! If that is really Linus' argument "against" FreeBSD's sendfile(), then that's not an argument against it since any response aggregation should happen in the network stack and not at the sendfile() level. Linus is right about one thing, though: I've never heard of "TCP_CORK" and have very little idea of what it is supposed to do. The Linux sendfile() API was only looked at very superficially and I found it to be sorely lacking at the time. ...but unlike Linus about FreeBSD, I've never publically said that Linus or his team are idiots because of it, despite what I may think sometimes. That should count for something. :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11: 7:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B2BF437B69B for ; Thu, 1 Feb 2001 11:07:17 -0800 (PST) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id KAA23975; Thu, 1 Feb 2001 10:19:29 -0800 (PST) Message-Id: <200102011819.KAA23975@implode.root.com> To: bsddiy Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-reply-to: Your message of "Thu, 01 Feb 2001 13:31:39 +0800." <1217774688.20010201133139@163.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 01 Feb 2001 10:19:28 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I don't want to bring flame war, but the following Linus' words may be >right: The FreeBSD API is the way it is after a collaboration with the Apache folks. The sendfile() implementation in FreeBSD works just fine and I think it has one of the most complete API's of any of them out there. Sounds like typical Linus misinformation. If you have a point to make, then make it. I would be happy to consider any real shortcomings in sendfile(), but right now I don't know about any. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. >----- >The fact I dislike about the HP-UX implementation is that it is so obviously stupid. > >And I have to say that I absolutely despise the BSD people. They did sendfile() >after both Linux and HP-UX had done it, and they must have known about both >implementations. And they chose the HP-UX braindamage, and even brag about > the fact that they were stupid and didn't understand TCP_CORK (they don't > say so in those exact words, of course - they just show that they were stupid > and clueless by the things they brag about). > >Oh, well. Not everybody can be as goodlooking as me. It's a curse. > >----- > >Also note how I said that it is the BSD people I despise. Not the HP-UX implementation. >The HP-UX one is not pretty, but it works. But I hold open source people to higher standards. >They are supposed to be the people who do programming because it's an art-form, not because >it's their job. > > >David Xu > > > > >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 Feb 1 11:20:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id B3D4D37B4EC; Thu, 1 Feb 2001 11:20:04 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id C177A24D35; Thu, 1 Feb 2001 17:19:57 -0200 (BRST) Message-ID: <3A79B707.3DF0B6D@jonny.eng.br> Date: Thu, 01 Feb 2001 17:20:39 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: yusufg@outblaze.com, freebsd-net@FreeBSD.ORG, freebsd-stable@freebsd.org, phk@freebsd.org Subject: Solved: Bridging and dummynet seems to destroy dmesg output References: <200101312212.f0VMCHj08290@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > I tried only removing DUMMYNET from config, and the bug continues. Should > > I try the changes below? > > no-they only affect dummynet. But this seems to suggest that > the problem is unrelated to my changes... > > cheers > luigi Hi, I found the problem! I started searching for the point where ipfw writes to the msgbuf, and like all other kernel modules, it uses the log(9) function. But differently from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, recompiled, reboot, and BINGO! Probably the log(9) function does not expect a facility parameter, as it is assumed to be LOG_KERNEL. Searching the cvsweb tree, I assume the changes that made it fail were made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a longer search should be made to detect if any other call to log(9) uses this approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at 2000.01.16) Hoping this is the final solution and waiting for the cvs commit, thanks to everybody, Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11:22: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DB70E37B4EC for ; Thu, 1 Feb 2001 11:21:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f11JL2323862; Thu, 1 Feb 2001 11:21:02 -0800 (PST) Date: Thu, 1 Feb 2001 11:21:02 -0800 From: Alfred Perlstein To: David Greenman Cc: bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201112102.O26076@fw.wintelcom.net> References: <1217774688.20010201133139@163.net> <200102011819.KAA23975@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102011819.KAA23975@implode.root.com>; from dg@root.com on Thu, Feb 01, 2001 at 10:19:28AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Greenman [010201 11:07] wrote: > >I don't want to bring flame war, but the following Linus' words may be > >right: Really David (Xu), what part do you believe to be correct? > The FreeBSD API is the way it is after a collaboration with the Apache > folks. The sendfile() implementation in FreeBSD works just fine and I think > it has one of the most complete API's of any of them out there. Sounds like > typical Linus misinformation. > If you have a point to make, then make it. I would be happy to consider > any real shortcomings in sendfile(), but right now I don't know about any. David Greenman is right, I don't see how using the TCP_CORK option (more on that later) which basically turns the one-syscall sendfile method into a mess of: setsocktopt/ioctl +TCP_CORK writev (most likely required) linux-sendfile writev (possibly optional) setsocktopt/ioctl -TCP_CORK (or possibly close) Now to give Linux the benifit of the doubt (because everyone has to i guess), if TCP_CORK is inherited from the accept() socket, then you loose one syscall. If TCP_CORK is cleared and socket flushed in a timely manner at close() you ditch another syscall, but it's still at least one additional syscall and pretty obtuse API. Oh, and about TCP_CORK, it's a kewl name, and I commend the Linux camp on thier kewl named additions to the system, but to be honest they aren't really as brilliant (or goodlooking) as they think. TCP_CORK should have been made into a socket level option, not a protocol level option. For some reason I'm shocked Linus would have ranted like this on a public list, my guess is that this is a pretty old message dug up from the archives to stir a bit of flamage on the lists. When I first read it I was wondering what David Xu's point was, and I'm still wondering. > >----- > >The fact I dislike about the HP-UX implementation is that it is so obviously stupid. > > > >And I have to say that I absolutely despise the BSD people. They did sendfile() > >after both Linux and HP-UX had done it, and they must have known about both > >implementations. And they chose the HP-UX braindamage, and even brag about > > the fact that they were stupid and didn't understand TCP_CORK (they don't > > say so in those exact words, of course - they just show that they were stupid > > and clueless by the things they brag about). > > > >Oh, well. Not everybody can be as goodlooking as me. It's a curse. > > > >----- > > > >Also note how I said that it is the BSD people I despise. Not the HP-UX implementation. > >The HP-UX one is not pretty, but it works. But I hold open source people to higher standards. > >They are supposed to be the people who do programming because it's an art-form, not because > >it's their job. > > > > > >David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11:23:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from expert.com.br (soure.expert.com.br [200.242.253.1]) by hub.freebsd.org (Postfix) with SMTP id 3766937B67D for ; Thu, 1 Feb 2001 11:23:38 -0800 (PST) Received: (qmail 46697 invoked from network); 1 Feb 2001 19:28:42 -0000 Received: from unknown (HELO nirvana) (200.242.253.60) by soure.expert.com.br with SMTP; 1 Feb 2001 19:28:42 -0000 Message-ID: <021b01c08c84$a99156a0$3cfdf2c8@nirvana> From: "Roberto Samarone Araujo (RSA)" To: Subject: Date: Thu, 1 Feb 2001 16:24:57 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11:28:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id C335C37B67D for ; Thu, 1 Feb 2001 11:28:12 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 6F0A7E4BB9; Thu, 1 Feb 2001 14:28:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id 52835E4BB8; Thu, 1 Feb 2001 14:28:07 -0500 (EST) Date: Thu, 1 Feb 2001 14:28:07 -0500 (EST) From: "Richard A. Steenbergen" To: David Greenman Cc: bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-Reply-To: <200102011819.KAA23975@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Feb 2001, David Greenman wrote: > >I don't want to bring flame war, but the following Linus' words may be > >right: > > The FreeBSD API is the way it is after a collaboration with the Apache > folks. The sendfile() implementation in FreeBSD works just fine and I think > it has one of the most complete API's of any of them out there. Sounds like > typical Linus misinformation. > If you have a point to make, then make it. I would be happy to consider > any real shortcomings in sendfile(), but right now I don't know about any. The most serious shortcoming I see is that it still requires a storm of syscalls for async operation. Take this for example, a daemon with 1000 open connections transfering data to dialups. The first pass through, sendfile() will fill the socket buffer and move on to the next fd. Then shortly thereafter, with the sockbuf only slightly drained, new write events will come up in whatever polling method you're using, and you get to fire off another 1000 syscalls just to add an extremely small amount of data. You must also either keep 1000 open fds for the source file, or open() and close() on every pass. You could have your event poller check the status of the sockbuf and make some intelligent determination of when to trigger a new write event, perhaps based on some knowledge of the rate at which the connected peer is draining information. This potentially restricts the amount of data in the snd sockbuf and thus the size of the tcp window which can be fast recovered in the event of packet loss, but if done correctly and with a semi accurate guess at the rate of drain it could be useful. kevent filter? If sendfile() was in effect aio_sendfile(), it would be even more useful. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 11:41: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C1AD237B699; Thu, 1 Feb 2001 11:40:28 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f11Je7561000; Thu, 1 Feb 2001 11:40:07 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102011940.f11Je7561000@iguana.aciri.org> Subject: Re: Solved: Bridging and dummynet seems to destroy dmesg output In-Reply-To: <3A79B707.3DF0B6D@jonny.eng.br> from Joao Carlos Mendes Luis at "Feb 1, 2001 5:20:39 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Thu, 1 Feb 2001 11:40:07 -0800 (PST) Cc: rizzo@aciri.org, yusufg@outblaze.com, freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, phk@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org thanks for tracking this problem -- it also explains why i did not see it in my environment, as i have a mostly 4.2-R system with new code in net/ and netinet/ cheers luigi > Hi, > > I found the problem! > > I started searching for the point where ipfw writes to the msgbuf, and > like all other kernel modules, it uses the log(9) function. But differently > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a > facility parameter, as it is assumed to be LOG_KERNEL. > > Searching the cvsweb tree, I assume the changes that made it fail were > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a > longer search should be made to detect if any other call to log(9) uses this > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at > 2000.01.16) > > Hoping this is the final solution and waiting for the cvs commit, thanks > to everybody, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 12:11:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id CCCBA37B491 for ; Thu, 1 Feb 2001 12:11:30 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA79234; Thu, 1 Feb 2001 15:10:36 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Feb 2001 15:10:36 -0500 (EST) From: Garrett Wollman Message-Id: <200102012010.PAA79234@khavrinen.lcs.mit.edu> To: Tony Finch Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-Reply-To: <20010201180010.Q70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > For this reason turning off TCP_CORK pushes out queued data, but > this isn't the case for TCP_NOPUSH. This is a long-standing bug. You are welcome to fix it. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 12:21:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3B24B37B698 for ; Thu, 1 Feb 2001 12:21:07 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA79321; Thu, 1 Feb 2001 15:20:49 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Feb 2001 15:20:49 -0500 (EST) From: Garrett Wollman Message-Id: <200102012020.PAA79321@khavrinen.lcs.mit.edu> To: "Richard A. Steenbergen" Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-Reply-To: References: <200102011819.KAA23975@implode.root.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Then shortly thereafter, with the sockbuf only slightly drained, new > write events will come up in whatever polling method you're using, > and you get to fire off another 1000 syscalls just to add an > extremely small amount of data. SO_SNDLOWAT -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 12:23:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 99A0137B699 for ; Thu, 1 Feb 2001 12:23:12 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA11225; Thu, 1 Feb 2001 12:23:06 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id MAA31492; Thu, 1 Feb 2001 12:23:06 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200102012023.MAA31492@curve.dellroad.org> Subject: Re: cvs commit: src/usr.sbin/arp arp.8 arp.c In-Reply-To: <200101312154.QAA68762@khavrinen.lcs.mit.edu> "from Garrett Wollman at Jan 31, 2001 04:54:36 pm" To: Garrett Wollman Date: Thu, 1 Feb 2001 12:23:05 -0800 (PST) Cc: net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman writes: > > I apologize for not getting this.. I'll try another question: why > > doesn't "arp -d x.y.z.w" just delete whatever ARP entry there is > > for x.y.z.w no matter what kind it is? > > Because it doesn't know what kind is there. It could find out, but > then you'd have a race condition, and in any case the system > administrator is presumed to know what permanent ARP entries there are > and of which sort. (In most cases it doesn't matter.) OK.. could you provide a one sentence description that I can add to the man page? E.g. "... the proxy keyword is required when deleting published ARP entries" or whatever. Thanks, -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 Feb 1 13: 4:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from privatecube.privatelabs.com (unknown [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id E2C6737B491; Thu, 1 Feb 2001 13:03:55 -0800 (PST) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id QAA16681; Thu, 1 Feb 2001 16:24:02 -0500 Received: from virtual-estates.net (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.1/8.9.3) with ESMTP id f11L3nP50702; Thu, 1 Feb 2001 16:03:50 -0500 (EST) (envelope-from mi@virtual-estates.net) Message-Id: <200102012103.f11L3nP50702@misha.privatelabs.com> Date: Thu, 1 Feb 2001 16:03:48 -0500 (EST) From: mi@aldan.algebra.com Subject: transparent proxying through a separate machine To: questions@freebsd.org, net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! We have a single firewall machine and a _separate_ machine running squid proxy (both servers are on the same network wire). How do I catch all of the outgoing http requests and send them through squid? I tried ipfw add fwd squid,3128 tcp from any to any http but it does not seem to work -- squid never gets contacted. All of the recipes out there describe the setups with squid and the firewall being on the same machine. What else do I need to do? Thanks! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 13:13:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by hub.freebsd.org (Postfix) with ESMTP id 4288E37B491 for ; Thu, 1 Feb 2001 13:13:21 -0800 (PST) Received: from multivac.sdsc.edu (multivac.sdsc.edu [132.249.20.57]) by postal.sdsc.edu (8.9.3/8.9.3/SDSCserver-16) with ESMTP id NAA24089 for ; Thu, 1 Feb 2001 13:13:20 -0800 (PST) Received: from localhost by multivac (8.9.3+Sun/1.11-SolarisClient) with ESMTP id NAA18078; Thu, 1 Feb 2001 13:13:20 -0800 (PST) Date: Thu, 1 Feb 2001 13:13:20 -0800 (PST) From: Matthew Luckie To: Subject: protosw kernel module Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there I am wondering if it is at all possible to somehow dynamically append a protocol to the protocol switch (table) mechanism with a kernel module. I am looking at the ipprotosw.h and in_proto.c files and it does not appear to be possible, as the inetsw[] array is declared to be a fixed size at compile time. I have written a protocol into the switch table with the necessary pr_input function and it would be helpful for me to be able to deploy this protocol as a binary .ko amongst many machines instead of distributing a complete kernel. I am willing to do some work to enable the kernel to do this, if it currently cannot, if a committer is interested in adding this feature to the kernel. However, I guess that this type of enhancement might not be wanted. Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 13:13:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 20ED637B4EC for ; Thu, 1 Feb 2001 13:13:20 -0800 (PST) Received: (qmail 1613 invoked by uid 666); 1 Feb 2001 21:21:24 -0000 Received: from reggae-03-33.nv.iinet.net.au (HELO elischer.org) (203.59.78.33) by mail.m.iinet.net.au with SMTP; 1 Feb 2001 21:21:24 -0000 Message-ID: <3A79D157.A18270EB@elischer.org> Date: Thu, 01 Feb 2001 13:12:55 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: questions@freebsd.org, net@freebsd.org Subject: Re: transparent proxying through a separate machine References: <200102012103.f11L3nP50702@misha.privatelabs.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mi@aldan.algebra.com wrote: > > Hello! > > We have a single firewall machine and a _separate_ machine running > squid proxy (both servers are on the same network wire). > > How do I catch all of the outgoing http requests and send them through > squid? > > I tried > > ipfw add fwd squid,3128 tcp from any to any http > > but it does not seem to work -- squid never gets contacted. All of the > recipes out there describe the setups with squid and the firewall being > on the same machine. What else do I need to do? Thanks! I assume squid is the name of the other machine? you need to have the same rule in the ipfw on that machine too. otherwise it will reflect the packet back at it's original destination as it still has headers saying it wants to go there. (It's unaltered). > > -mi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 13:15:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 9C41737B67D for ; Thu, 1 Feb 2001 13:15:28 -0800 (PST) Received: (qmail 17954 invoked by uid 666); 1 Feb 2001 21:22:50 -0000 Received: from reggae-03-33.nv.iinet.net.au (HELO elischer.org) (203.59.78.33) by mail.m.iinet.net.au with SMTP; 1 Feb 2001 21:22:50 -0000 Message-ID: <3A79D1D8.3FC5BF70@elischer.org> Date: Thu, 01 Feb 2001 13:15:04 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: questions@freebsd.org, net@freebsd.org Subject: Re: transparent proxying through a separate machine References: <200102012103.f11L3nP50702@misha.privatelabs.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mi@aldan.algebra.com wrote: > > Hello! > > We have a single firewall machine and a _separate_ machine running > squid proxy (both servers are on the same network wire). > > How do I catch all of the outgoing http requests and send them through > squid? > > I tried > > ipfw add fwd squid,3128 tcp from any to any http > > but it does not seem to work -- squid never gets contacted. All of the > recipes out there describe the setups with squid and the firewall being > on the same machine. What else do I need to do? Thanks! Oh yeah, you need to make you rules only catch the packets from the clients, otherwise you will catch your own cache requests from squid. so you must allow the requests from 'squid' to avoid being forwarded back to squid.. > > -mi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 13:18:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7924837B491 for ; Thu, 1 Feb 2001 13:18:21 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f11LIKn27437; Thu, 1 Feb 2001 13:18:20 -0800 (PST) Date: Thu, 1 Feb 2001 13:18:20 -0800 From: Alfred Perlstein To: Matthew Luckie Cc: net@FreeBSD.ORG Subject: Re: protosw kernel module Message-ID: <20010201131820.P26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjl@SDSC.EDU on Thu, Feb 01, 2001 at 01:13:20PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Luckie [010201 13:13] wrote: > Hi there > > I am willing to do some work to enable the kernel to do this, if it > currently cannot, if a committer is interested in adding this feature to > the kernel. However, I guess that this type of enhancement might not be > wanted. It really depends on how you implement it. :) Give it a shot and submit patches. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 14: 1:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by hub.freebsd.org (Postfix) with ESMTP id 901DE37B491 for ; Thu, 1 Feb 2001 14:01:10 -0800 (PST) Received: from multivac.sdsc.edu (multivac.sdsc.edu [132.249.20.57]) by postal.sdsc.edu (8.9.3/8.9.3/SDSCserver-16) with ESMTP id OAA01958 for ; Thu, 1 Feb 2001 14:01:09 -0800 (PST) Received: from localhost by multivac (8.9.3+Sun/1.11-SolarisClient) with ESMTP id OAA20454; Thu, 1 Feb 2001 14:01:09 -0800 (PST) Date: Thu, 1 Feb 2001 14:01:09 -0800 (PST) From: Matthew Luckie To: Subject: Re: protosw kernel module In-Reply-To: <20010201131820.P26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm just wondering if someone on -net can offer some advice on how to go about implementing something like this. I am looking at the ip_input/ip_init functions now. Assuming that it would be a good idea to maintain the protosw table as it is now (i.e. statically declared), perhaps another way to go about this would be to add a single entry to the protosw table that takes care of protocols that are inserted dynamically. the ip_protox table would then be modified dynamically to switch to this pr_input function instead of the raw ip pr_input function that it would otherwise do. the protosw->pr_input function would then delegate the call to the appropriate pr_input function held in a seperate table u_char kld_ip_protox[IPPROTO_MAX]; struct ipprotosw *kld_inetsw; int ip_kld_input(struct mbuf *m, int off, int proto) { (*kld_inetsw[kld_ip_protox[proto]].pr_input)(m,off,proto); } i am rather ignorant of data structures, so what type of data structure would be suited to this lookup task? Perhaps a pointer to a malloc'd array would be good, and if a new protocol is to be inserted to the kernel, then to re-allocate the necessary tables to accomodate a new protocol. Given that the task of re-allocating tables would not happen very often, I think this might be a good way to approach this task. I appreciate any criticism anyone could offer on this approach to this idea Thanks Matthew On Thu, 1 Feb 2001, Alfred Perlstein wrote: > * Matthew Luckie [010201 13:13] wrote: > > Hi there > > > > I am willing to do some work to enable the kernel to do this, if it > > currently cannot, if a committer is interested in adding this feature to > > the kernel. However, I guess that this type of enhancement might not be > > wanted. > > It really depends on how you implement it. :) Give it a shot > and submit patches. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 14:18:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from gecko.eric.net.au (gecko.eric.net.au [203.102.228.3]) by hub.freebsd.org (Postfix) with ESMTP id AE2C437B491 for ; Thu, 1 Feb 2001 14:18:27 -0800 (PST) Received: (from ghcrompton@localhost) by gecko.eric.net.au (8.9.3/8.8.7) id JAA01037; Fri, 2 Feb 2001 09:22:33 +1100 Date: Fri, 2 Feb 2001 09:22:33 +1100 From: "Geoffrey Crompton (RMIT Guest)" To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: pseudo interface and ioctls Message-ID: <20010202092233.A986@gecko.eric.net.au> References: <20010201103716.A23667@gecko.eric.net.au> <3A791528.BC4593E2@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A791528.BC4593E2@elischer.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 31, 2001 at 11:50:01PM -0800, Julian Elischer wrote: > "Geoffrey Crompton (RMIT Guest)" wrote: > > why are you doing this? > there are already 4 pseudo interfaces in the system of varying types.. > > netgraph(2 types), divert, tap, tun. > > what do you need to do? > I need to do packet translation between different AF_ types. I haven't seen any interfaces that do that. (I haven't got too much experience though) Geoff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 15: 7:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id BA7FD37B491 for ; Thu, 1 Feb 2001 15:07:34 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OSoO-000BWr-00; Thu, 01 Feb 2001 23:06:44 +0000 Date: Thu, 1 Feb 2001 23:06:44 +0000 From: Tony Finch To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201230644.W70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <200102012010.PAA79234@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102012010.PAA79234@khavrinen.lcs.mit.edu> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: >Tony Finch wrote: >> >> For this reason turning off TCP_CORK pushes out queued data, but >> this isn't the case for TCP_NOPUSH. > >This is a long-standing bug. You are welcome to fix it. I've been looking at this and it seems to me to be simply a case of calling tcp_output() from tcp_ctloutput() if TF_NOPUSH is cleared. But I'm not certain I have my head properly around the code... Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.51 diff -u -r1.51 tcp_usrreq.c --- tcp_usrreq.c 2000/01/09 19:17:28 1.51 +++ tcp_usrreq.c 2001/02/01 23:03:35 @@ -896,7 +896,6 @@ switch (sopt->sopt_name) { case TCP_NODELAY: case TCP_NOOPT: - case TCP_NOPUSH: error = sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); if (error) @@ -921,6 +920,20 @@ tp->t_flags |= opt; else tp->t_flags &= ~opt; + break; + + case TCP_NOPUSH: + error = sooptcopyin(sopt, &optval, sizeof optval, + sizeof optval); + if (error) + break; + + if (optval) + tp->t_flags |= opt; + else { + tp->t_flags &= ~opt; + error = tcp_output(tp); + } break; case TCP_MAXSEG: Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Well, as long as they can think we'll have our problems. But those whom we're using cannot think." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 15: 8:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from privatecube.privatelabs.com (unknown [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 1805037B699; Thu, 1 Feb 2001 15:08:01 -0800 (PST) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id SAA18434; Thu, 1 Feb 2001 18:28:02 -0500 Received: from virtual-estates.net (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.1/8.9.3) with ESMTP id f11N7iP51027; Thu, 1 Feb 2001 18:07:46 -0500 (EST) (envelope-from mi@virtual-estates.net) Message-Id: <200102012307.f11N7iP51027@misha.privatelabs.com> Date: Thu, 1 Feb 2001 18:07:43 -0500 (EST) From: mi@aldan.algebra.com Subject: Re: transparent proxying through a separate machine To: Julian Elischer Cc: questions@freebsd.org, net@freebsd.org In-Reply-To: <3A79D157.A18270EB@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1 Feb, Julian Elischer wrote: = > We have a single firewall machine and a _separate_ machine running = > squid proxy (both servers are on the same network wire). = > = > How do I catch all of the outgoing http requests and send them = > through squid? = > = > I tried = > = > ipfw add fwd squid,3128 tcp from any to any http = > = > but it does not seem to work -- squid never gets contacted. All of = > the recipes out there describe the setups with squid and the = > firewall being on the same machine. What else do I need to do? = = I assume squid is the name of the other machine? you need to have the = same rule in the ipfw on that machine too. Yes. Ok. This is what I just added to the squid-machine: ipfw add allow ip from any to any out ipfw add fwd localhost,3128 log tcp from any to any 3128 in = otherwise it will reflect the packet back at it's original destination = as it still has headers saying it wants to go there. (It's unaltered). The firewall machine logs ipfw: 3000 Forward to squid.ip:3128 TCP client.ip:3977 web.server.ip:80 in via dc0 But the client still talks to the web-server directly :( The squid's log is quiet... Anything I'm missing? Perhaps, I need a user-space program of some sort to run on the firewall to do the tunneling? Thanks! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 15:12:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id 6326D37B491 for ; Thu, 1 Feb 2001 15:12:18 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f11NBit01177; Thu, 1 Feb 2001 15:11:45 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Thu, 1 Feb 2001 15:11:44 -0800 (PST) From: Yu-Shun Wang To: Jun-ichiro itojun Hagino Cc: Subject: Re: IPComp question In-Reply-To: <20010201051101.F26147E56@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, It turned out that the problem is in netinet/in_proto.c. (It might have been fixed in -stable long ago, but not in 4.2 release. :-) yushun. --- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001 +++ /usr/src/sys/netinet/in_proto.c.ORIG Thu Feb 1 14:38:25 2001 @@ -72,7 +72,6 @@ #ifdef IPSEC #include #include -#include #ifdef IPSEC_ESP #include #endif @@ -149,12 +148,6 @@ ah4_input, 0, 0, 0, 0, 0, 0, 0, 0, - &nousrreqs -}, -{ SOCK_RAW, &inetdomain, IPPROTO_IPCOMP, PR_ATOMIC|PR_ADDR, - ipcomp4_input,0, 0, 0, - 0, - 0, 0, 0, 0, &nousrreqs }, #ifdef IPSEC_ESP ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California On Thu, 1 Feb 2001, Jun-ichiro itojun Hagino wrote: > > > No, but the problem is that there was no increase (actually, no > > record at all) under ipsec: IPComp. The number on the sending > > side seemed right. The increase matched the ones I saw from > > tcpdump. It looked like the IPComp packets either weren't > > logged or were dropped for some reason. > > send the following items. > - full tcpdump output > - netstat -sn before, and after the test (on both ends) > - full SA configuration on both sides (previous email may have included > it) > - ifconfig -a output, on both ends > - netstat -rn output, on both ends > - simple network diagram (like intermediate routers) between both ends > > itojun > > > 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 Feb 1 15:49:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id F04EC37B491 for ; Thu, 1 Feb 2001 15:49:11 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f11Nmci01294; Thu, 1 Feb 2001 15:48:38 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Thu, 1 Feb 2001 15:48:37 -0800 (PST) From: Yu-Shun Wang To: Jun-ichiro itojun Hagino Cc: Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Another (sort of) related question: I've got the bandwidth measurements for different algorthms using netperf. I was really surprised that IPComp did so bad. Any ideas? TCP UDP(Mbps) Ping(ms) Key(bits) ----------------------------------------------------- Raw IP 79.56 94.59/87.98 0.213 des-cbc 40.60 46.51/36.88 0.389 64 3des-cbc 19.52 22.18/19.37 0.460 192 simple 78.53 93.44/86.93 0.293 64 hmac-md5 72.86 93.86/44.57 0.398 128 blowfish-cbc 23.24 55.18/42.12 1.063 64 rc5-cbc 46.22 65.67/45.29 0.383 64 hmac-sha1 45.30 64.04/49.69 0.440 160 IPComp-deflate 24.05 27.11/27.10 0.242 Setup: 2 identical freebsd 4.2 release boxes (PIII 733MHz, 256MB RDRAM) connected through Ethernet switch. Thanks, yushun. ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California On Thu, 1 Feb 2001, Yu-Shun Wang wrote: > Hi, > > It turned out that the problem is in netinet/in_proto.c. > (It might have been fixed in -stable long ago, but not > in 4.2 release. :-) > > yushun. > > > --- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001 > +++ /usr/src/sys/netinet/in_proto.c.ORIG Thu Feb 1 14:38:25 2001 > @@ -72,7 +72,6 @@ > #ifdef IPSEC > #include > #include > -#include > #ifdef IPSEC_ESP > #include > #endif > @@ -149,12 +148,6 @@ > ah4_input, 0, 0, 0, > 0, > 0, 0, 0, 0, > - &nousrreqs > -}, > -{ SOCK_RAW, &inetdomain, IPPROTO_IPCOMP, PR_ATOMIC|PR_ADDR, > - ipcomp4_input,0, 0, 0, > - 0, > - 0, 0, 0, 0, > &nousrreqs > }, > #ifdef IPSEC_ESP > > > ____________________________________________________________________________ > Yu-Shun Wang Information Sciences Institute > University of Southern California > > On Thu, 1 Feb 2001, Jun-ichiro itojun Hagino wrote: > > > > > > No, but the problem is that there was no increase (actually, no > > > record at all) under ipsec: IPComp. The number on the sending > > > side seemed right. The increase matched the ones I saw from > > > tcpdump. It looked like the IPComp packets either weren't > > > logged or were dropped for some reason. > > > > send the following items. > > - full tcpdump output > > - netstat -sn before, and after the test (on both ends) > > - full SA configuration on both sides (previous email may have included > > it) > > - ifconfig -a output, on both ends > > - netstat -rn output, on both ends > > - simple network diagram (like intermediate routers) between both ends > > > > itojun > > > > > > 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 Feb 1 16:40:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 717EA37B4EC for ; Thu, 1 Feb 2001 16:39:54 -0800 (PST) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with SMTP id IAA14485; Fri, 2 Feb 2001 08:33:53 +0800 Message-ID: <001d01c08cb1$9c445d80$6201a8c0@William> From: "David Xu" To: "Tony Finch" , "Kris Kennaway" Cc: "bsddiy" , References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> Subject: Re: sendfile() Date: Fri, 2 Feb 2001 08:46:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA ZG90YXQuYXQ+DQpUbzogIktyaXMgS2VubmF3YXkiIDxrcmlzQG9ic2VjdXJpdHkub3JnPg0KQ2M6 ICJic2RkaXkiIDxic2RkaXlAMTYzLm5ldD47IDxmcmVlYnNkLW5ldEBGcmVlQlNELk9SRz4NClNl bnQ6IEZyaWRheSwgRmVicnVhcnkgMDIsIDIwMDEgMjowMCBBTQ0KU3ViamVjdDogUmU6IHNlbmRm aWxlKCkNCg0KDQo+IEtyaXMgS2VubmF3YXkgPGtyaXNAb2JzZWN1cml0eS5vcmc+IHdyb3RlOg0K PiBMaW51cydzIGFyZ3VtZW50IGFnYWluc3QgdGhlIEhQL1VYIGFuZCBCU0Qgc2VuZGZpbGUoKSBp cyB0aGF0LCBmb3INCj4gZXhhbXBsZSwgaW4gdGhlIHByZXNlbmNlIG9mIHBpcGVsaW5lZCBIVFRQ IHJlcXVlc3RzIGl0IGlzbid0IHBvc3NpYmxlDQo+IHRvIGF2b2lkIHBvb3IgcGFja2V0IGJvdW5k YXJpZXMgYmV0d2VlbiByZXNwb25zZXMuIFRDUF9OT1BVU0ggZG9lcw0KPiBoZWxwIHRvIHNvbHZl IHRoaXMgcHJvYmxlbSAoaXQgd2FzIGRlc2lnbmVkIHRvIGhhY2sgYXJvdW5kIHByb2JsZW1zDQo+ IHdpdGggdGhlIGludGVyYWN0aW9uIGJldHdlZW4gbWJ1ZiBzaXplcyBhbmQgc29zZW5kIGFuZCB0 Y3Bfb3V0cHV0KSBidXQNCj4gaXQgaW50cm9kdWNlcyBhIG5ldyBwcm9ibGVtOiBhdCB0aGUgZW5k IG9mIGEgY2hhaW4gb2YgSFRUUCByZXNwb25zZXMNCj4geW91IHdhbnQgdGhlIGxhc3Qgc2VnbWVu dCB0byBnbyBvdXQgcXVpY2tseSByYXRoZXIgdGhhbiB3YWl0aW5nIGZvcg0KPiBtb3JlIGRhdGEg dG8gZmlsbCB0aGUgc2VnbWVudC4gRm9yIHRoaXMgcmVhc29uIHR1cm5pbmcgb2ZmIFRDUF9DT1JL DQo+IHB1c2hlcyBvdXQgcXVldWVkIGRhdGEsIGJ1dCB0aGlzIGlzbid0IHRoZSBjYXNlIGZvciBU Q1BfTk9QVVNILg0KPiANCg0KaWYgVENQX05PUFVTSCBjYW4gc2ltdWxhdGUgVENQX0NPUksgd2hl biBUQ1BfTk9QVVNIIGlzDQp0dXJuZWQgb2ZmIGFuZCBsYXN0IGRhdGEgc2VnbWVudCBpcyBzZW50 LCAgSSdsbCBiZSBzYXRpc2ZpZWQuDQpidXQgYXMgSSBrbm93LCBpdCBzZWVtcyBUQ1BfTk9QVVNI IGlzIG1haW5seSB1c2VkIGZvciBUVENQLCByaWdodD8NCg0KdGhlIGlkZWEgYmVoaW5kIFRDUF9D T1JLIGlzIGl0IGJ1ZmZlcnMgYW55IHNtYWxsIGRhdGEgc2VnbWVudCB1c2VyIHByb2dyYW0gDQpz ZW5kaW5nIHVudGlsIHRoZXNlIHNlZ21lbnRzIGZ1bGwgZmlsbHMgYSBtYXggVENQIHBhY2tldCwg dGhlbiB0aGUgcGFja2V0IGlzIHNlbnQsICANCndlYiBzZXJ2ZXJzIGFsd2F5cyBzZW5kIG1hbnkg dmVyeSBzbWFsbCAgSFRUUCBoZWFkZXJzLCBjYXVzZSBsb3RzIG9mIHNtYWxsIHBhY2tldHMNCnNl bnQgb3V0LCAgVENQX0NPUksgIGNhbiBpbmNyZWFzZSBuZXR3b3JrIHBlcmZvcm1hbmNlLg0KDQpS ZWdhcmRzLA0KRGF2aWQgWHUNCg0K To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 16:51:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id BAD2837B4EC for ; Thu, 1 Feb 2001 16:51:30 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA22231; Fri, 2 Feb 2001 09:51:22 +0900 (JST) To: Yu-Shun Wang Cc: freebsd-net@freebsd.org In-reply-to: yushunwa's message of Thu, 01 Feb 2001 15:48:37 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp question From: itojun@iijlab.net Date: Fri, 02 Feb 2001 09:51:22 +0900 Message-ID: <22229.981075082@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Another (sort of) related question: I've got the bandwidth > measurements for different algorthms using netperf. I was > really surprised that IPComp did so bad. Any ideas? thanks for measurements, it's good to see. i guess couple of reasons here. - because we compress short packets with IPComp, we cannot make a good use of compression history/dictionary. we always initialize everything on every packet, and it can consume cpu time. - zlib buffer management - it has ring buffer management on both in/output ends, because we will see data stream with different sizes. - zlib memory management - heavy use of malloc? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 16:51:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id C337437B503 for ; Thu, 1 Feb 2001 16:51:35 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OUQc-000BrS-00; Fri, 02 Feb 2001 00:50:18 +0000 Date: Fri, 2 Feb 2001 00:50:18 +0000 From: Tony Finch To: David Xu Cc: Kris Kennaway , bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010202005018.Y70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001d01c08cb1$9c445d80$6201a8c0@William> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Xu wrote: > >but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right? That's what it was designed for. >the idea behind TCP_CORK is it buffers any small data segment user >program sending until these segments full fills a max TCP packet, >then the packet is sent, TCP_NOPUSH is the same >web servers always send many very small HTTP headers, cause lots of >small packets sent out, TCP_CORK can increase network performance. No, web servers are very careful to reduce the number of packets required for a response. TCP_CORK exists to avoid two bad packet boundaries per request: one between the header and the body, and one between the body and the next response. FreeBSD's sendfile allows you to easily optimise the beginning of the response; optimising the transition from one response to the next is harder. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "If I didn't see it with my own eyes I would never have believed it!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17: 3: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AA38B37B491 for ; Thu, 1 Feb 2001 17:02:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1212EW05308; Thu, 1 Feb 2001 17:02:14 -0800 (PST) Date: Thu, 1 Feb 2001 17:02:14 -0800 From: Alfred Perlstein To: Tony Finch Cc: David Xu , Kris Kennaway , bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201170214.V26076@fw.wintelcom.net> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> <20010202005018.Y70673@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010202005018.Y70673@hand.dotat.at>; from dot@dotat.at on Fri, Feb 02, 2001 at 12:50:18AM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Tony Finch [010201 16:52] wrote: > David Xu wrote: > > > >but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right? > > That's what it was designed for. > > >the idea behind TCP_CORK is it buffers any small data segment user > >program sending until these segments full fills a max TCP packet, > >then the packet is sent, > > TCP_NOPUSH is the same > > >web servers always send many very small HTTP headers, cause lots of > >small packets sent out, TCP_CORK can increase network performance. > > No, web servers are very careful to reduce the number of packets > required for a response. TCP_CORK exists to avoid two bad packet > boundaries per request: one between the header and the body, and one > between the body and the next response. FreeBSD's sendfile allows you > to easily optimise the beginning of the response; optimising the > transition from one response to the next is harder. I was going to say the same thing, but what about the header before a cgi response? Doesn't the webserver need to spit out a couple of short lines before exec'ing the CGI? Wouldn't the socket low water mark address this though as long as it was > size of the http header? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17: 8:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 846DC37B491 for ; Thu, 1 Feb 2001 17:08:15 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OUhC-000Cgv-00; Fri, 02 Feb 2001 01:07:26 +0000 Date: Fri, 2 Feb 2001 01:07:25 +0000 From: Tony Finch To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: proper uncorking for TCP_NOPUSH, was Re: sendfile() Message-ID: <20010202010725.Z70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <200102012010.PAA79234@khavrinen.lcs.mit.edu> <20010201230644.W70673@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010201230644.W70673@hand.dotat.at> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tony Finch wrote: >Garrett Wollman wrote: >>Tony Finch wrote: >>> >>> For this reason turning off TCP_CORK pushes out queued data, but >>> this isn't the case for TCP_NOPUSH. >> >>This is a long-standing bug. You are welcome to fix it. > >I've been looking at this and it seems to me to be simply a case of >calling tcp_output() from tcp_ctloutput() if TF_NOPUSH is cleared. OK, apart from my previous patch containing dumb cut&paste errors it works :-) I have a program (below) which forks; the parent listens for a connection and then reads from it reporting the size of the reads; the child connects to the parent, sets TCP_NOPUSH, writes 10000 single bytes, unsets TCP_NOPUSH, sleeps for 10 seconds, then exits. On an upatched FreeBSD the following happens. Note that the single-byte writes get coalesced nicely. Note also that there is a six second delay between the writer finishing and the readere receiving the data. :; ./a.out 981075049.891658 reader init 981075050.898416 writer init 981075050.899179 reader go 981075050.902703 writer go 981075050.939887 write finished 981075055.898738 read 8192 981075055.899084 read 1808 981075060.948514 writer exit 981075060.949197 read 0 981075060.949237 reader exit On a patched FreeBSD this happens. The reader gets the data as soon as the writer turns off TCP_NOPUSH :-) :; ./a.out 981075103.647630 reader init 981075104.654745 writer init 981075104.655310 reader go 981075104.655433 writer go 981075104.690353 write finished 981075104.690863 read 8192 981075104.691037 read 1808 981075114.695098 writer exit 981075114.695640 read 0 981075114.695761 reader exit Proper patch below. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "Dead! And yet there he stands!" Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.51 diff -u -r1.51 tcp_usrreq.c --- tcp_usrreq.c 2000/01/09 19:17:28 1.51 +++ tcp_usrreq.c 2001/02/02 00:21:01 @@ -896,7 +896,6 @@ switch (sopt->sopt_name) { case TCP_NODELAY: case TCP_NOOPT: - case TCP_NOPUSH: error = sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); if (error) @@ -909,9 +908,6 @@ case TCP_NOOPT: opt = TF_NOOPT; break; - case TCP_NOPUSH: - opt = TF_NOPUSH; - break; default: opt = 0; /* dead code to fool gcc */ break; @@ -921,6 +917,20 @@ tp->t_flags |= opt; else tp->t_flags &= ~opt; + break; + + case TCP_NOPUSH: + error = sooptcopyin(sopt, &optval, sizeof optval, + sizeof optval); + if (error) + break; + + if (optval) + tp->t_flags |= TF_NOPUSH; + else { + tp->t_flags &= ~TF_NOPUSH; + error = tcp_output(tp); + } break; case TCP_MAXSEG: #include #include #include #include #include #include #include #include #include #include #define PORT_FOO 55555 static void report(const char *fmt, ...) { struct timeval tv; va_list ap; char buf[80]; va_start(ap, fmt); if(gettimeofday(&tv, NULL)) err(1, "gettimeofday"); vsnprintf(buf, sizeof(buf), fmt, ap); printf("%ld.%06ld %s\n", tv.tv_sec, tv.tv_usec, buf); va_end(ap); } int main(void) { int i, r, s; struct sockaddr_in addr; char buf[8192]; setbuf(stdout, NULL); bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT_FOO); addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); switch(fork()) { case(-1): err(1, "fork"); case(0): /* child */ sleep(1); report("writer init"); s = socket(PF_INET, SOCK_STREAM, 0); if(s < 0) err(1, "socket"); i = 1; r = setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, &i, sizeof(i)); if(r < 0) err(1, "setsockopt"); r = connect(s, (struct sockaddr *)&addr, sizeof(addr)); if(r < 0) err(1, "connect"); report("writer go"); *buf = 0; for(i = 0; i < 10000; i++) { r = write(s, buf, 1); if(r < 0) err(1, "write"); } report("write finished"); i = 0; r = setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, &i, sizeof(i)); if(r < 0) err(1, "setsockopt"); sleep(10); report("writer exit"); exit(0); default: /* parent */ report("reader init"); s = socket(PF_INET, SOCK_STREAM, 0); if(s < 0) err(1, "socket"); i = 1; r = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i)); if(r < 0) err(1, "setsockopt"); r = bind(s, (struct sockaddr *)&addr, sizeof(addr)); if(r < 0) err(1, "bind"); r = listen(s, SOMAXCONN); if(r < 0) err(1, "listen"); s = accept(s, (struct sockaddr *)&addr, &i); if(s < 0) err(1, "accept"); report("reader go"); do { r = read(s, buf, sizeof(buf)); if(r < 0) err(1, "read"); report("read %d", r); } while(r); report("reader exit"); exit(0); } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17:11:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 3A64337B6A2 for ; Thu, 1 Feb 2001 17:11:32 -0800 (PST) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with SMTP id JAA14648; Fri, 2 Feb 2001 09:05:45 +0800 Message-ID: <003801c08cb6$09f96650$6201a8c0@William> From: "David Xu" To: "Tony Finch" Cc: "Kris Kennaway" , "bsddiy" , References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> <20010202005018.Y70673@hand.dotat.at> Subject: Re: sendfile() Date: Fri, 2 Feb 2001 09:18:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org SSBoYXZlIGxvb2tlZCBpbnRvIHRjcF91c3JyZXEuYyBhbmQgaXQgc2VlbXMgd2hlbiBUQ1BfTk9Q VVNIIGlzIHR1cm5lZCBvZmYsIA0KdGhlIGxhc3QgZGF0YSBzZWdtZW50IGlzIG5vdCBzZW50IGlt bWVkaWF0ZWx5LCAgbmVlZCB0byBhZGQgYSB0Y3Bfb3V0cHV0IGNhbGw/IA0KSSBhbSBub3QgY2Vy dGFpbiwgIGluIHRjcF9jdGxvdXRwdXQoc28sIG9wdCksICBJIHRoaW5rIHRoZSBjb2RlIHNob3Vs ZCBsaWtlIHRoaXM6DQoNCmNhc2UgVENQX05PUFVTSDoNCiAgIC4uLg0KICAgaWYgIChvcHR2YWwp DQogICAgICAgIHRwLT50X2ZsYWdzIHw9IG9wdDsNCiAgZWxzZQ0KICB7DQogICAgICAgIHRwLT50 X2ZsYWdzICY9IH5vcHQ7DQogICAgICAgIGlmICAob3B0ID09IFRGX05PUFVTSCkNCiAgICAgICAg ICAgICAgZXJyb3IgPSB0Y3Bfb3V0cHV0KHRwKTsNCiAgfQ0KDQotLQ0KUmVnYXJkcywNCkRhdmlk IFh1DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVG9ueSBGaW5jaCIg PGRvdEBkb3RhdC5hdD4NClRvOiAiRGF2aWQgWHUiIDxkYXZpZHhAdmlhc29mdC5jb20uY24+DQpD YzogIktyaXMgS2VubmF3YXkiIDxrcmlzQG9ic2VjdXJpdHkub3JnPjsgImJzZGRpeSIgPGJzZGRp eUAxNjMubmV0PjsgPGZyZWVic2QtbmV0QEZyZWVCU0QuT1JHPg0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAwMiwgMjAwMSA4OjUwIEFNDQpTdWJqZWN0OiBSZTogc2VuZGZpbGUoKQ0KDQoNCj4gRGF2 aWQgWHUgPGRhdmlkeEB2aWFzb2Z0LmNvbS5jbj4gd3JvdGU6DQo+ID4NCj4gPmJ1dCBhcyBJIGtu b3csIGl0IHNlZW1zIFRDUF9OT1BVU0ggaXMgbWFpbmx5IHVzZWQgZm9yIFRUQ1AsIHJpZ2h0Pw0K PiANCj4gVGhhdCdzIHdoYXQgaXQgd2FzIGRlc2lnbmVkIGZvci4NCj4gDQo+ID50aGUgaWRlYSBi ZWhpbmQgVENQX0NPUksgaXMgaXQgYnVmZmVycyBhbnkgc21hbGwgZGF0YSBzZWdtZW50IHVzZXIN Cj4gPnByb2dyYW0gc2VuZGluZyB1bnRpbCB0aGVzZSBzZWdtZW50cyBmdWxsIGZpbGxzIGEgbWF4 IFRDUCBwYWNrZXQsDQo+ID50aGVuIHRoZSBwYWNrZXQgaXMgc2VudCwNCj4gDQo+IFRDUF9OT1BV U0ggaXMgdGhlIHNhbWUNCj4gDQo+ID53ZWIgc2VydmVycyBhbHdheXMgc2VuZCBtYW55IHZlcnkg c21hbGwgSFRUUCBoZWFkZXJzLCBjYXVzZSBsb3RzIG9mDQo+ID5zbWFsbCBwYWNrZXRzIHNlbnQg b3V0LCBUQ1BfQ09SSyBjYW4gaW5jcmVhc2UgbmV0d29yayBwZXJmb3JtYW5jZS4NCj4gDQo+IE5v LCB3ZWIgc2VydmVycyBhcmUgdmVyeSBjYXJlZnVsIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHBh Y2tldHMNCj4gcmVxdWlyZWQgZm9yIGEgcmVzcG9uc2UuIFRDUF9DT1JLIGV4aXN0cyB0byBhdm9p ZCB0d28gYmFkIHBhY2tldA0KPiBib3VuZGFyaWVzIHBlciByZXF1ZXN0OiBvbmUgYmV0d2VlbiB0 aGUgaGVhZGVyIGFuZCB0aGUgYm9keSwgYW5kIG9uZQ0KPiBiZXR3ZWVuIHRoZSBib2R5IGFuZCB0 aGUgbmV4dCByZXNwb25zZS4gRnJlZUJTRCdzIHNlbmRmaWxlIGFsbG93cyB5b3UNCj4gdG8gZWFz aWx5IG9wdGltaXNlIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHJlc3BvbnNlOyBvcHRpbWlzaW5nIHRo ZQ0KPiB0cmFuc2l0aW9uIGZyb20gb25lIHJlc3BvbnNlIHRvIHRoZSBuZXh0IGlzIGhhcmRlci4N Cj4gDQo+IFRvbnkuDQo+IC0tIA0KPiBmLmEubi5maW5jaCAgICBmYW5mQGNvdmFsZW50Lm5ldCAg ICBkb3RAZG90YXQuYXQNCj4gIklmIEkgZGlkbid0IHNlZSBpdCB3aXRoIG15IG93biBleWVzIEkg d291bGQgbmV2ZXIgaGF2ZSBiZWxpZXZlZCBpdCEiDQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17:14: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 1093737B491 for ; Thu, 1 Feb 2001 17:13:44 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14OUmL-000Chl-00; Fri, 02 Feb 2001 01:12:45 +0000 Date: Fri, 2 Feb 2001 01:12:45 +0000 From: Tony Finch To: Alfred Perlstein Cc: David Xu , Kris Kennaway , bsddiy , freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010202011245.A70673@hand.dotat.at> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> <20010202005018.Y70673@hand.dotat.at> <20010201170214.V26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010201170214.V26076@fw.wintelcom.net> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > >I was going to say the same thing, but what about the header >before a cgi response? Doesn't the webserver need to spit out >a couple of short lines before exec'ing the CGI? No. The first line of the HTTP response ("HTTP/1.1 200 OK" or whatever) depends on the headers that the CGI returns to the server (e.g. "Status: 500 Database screwed again"). >Wouldn't the socket low water mark address this though as long >as it was > size of the http header? Ideally you want it to be the same as the path MTU. I don't know a good way of finding that out in uerland though. There remains the issue of the last partial packet in a response, though: you want that to go out immediately after the rest of the data. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "You realize there's a government directive stating that there is no such thing as a flying saucer?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17:15:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (unknown [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 7BD6537B4EC for ; Thu, 1 Feb 2001 17:15:02 -0800 (PST) Received: from localhost (rousskov@localhost) by measurement-factory.com (8.9.3/8.9.3) with ESMTP id SAA68480; Thu, 1 Feb 2001 18:14:33 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Date: Thu, 1 Feb 2001 18:14:33 -0700 (MST) From: Alex Rousskov To: Yu-Shun Wang Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Feb 2001, Yu-Shun Wang wrote: > Another (sort of) related question: I've got the bandwidth > measurements for different algorthms using netperf. I was > really surprised that IPComp did so bad. Any ideas? AFAIK, netperf TCP_STREAM test (and may be others) is extremely susceptible to network delays. For example, for a fast Ethernet connection with, say, 30msec packet delay, netperf may show less than 10Mbits/sec bandwidth instead of the usual 90+Mbits/sec. Clearly, bandwidth and response times are orthogonal measurements, but netperf design ties them together. Depending on your test environment and purposes, netperf throughput results may be very misleading. $0.02, Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 17:21: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1626337B4EC for ; Thu, 1 Feb 2001 17:20:43 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA81418; Thu, 1 Feb 2001 20:20:36 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Feb 2001 20:20:36 -0500 (EST) From: Garrett Wollman Message-Id: <200102020120.UAA81418@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() In-Reply-To: <20010201170214.V26076@fw.wintelcom.net> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> <20010202005018.Y70673@hand.dotat.at> <20010201170214.V26076@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Wouldn't the socket low water mark address this though as long > as it was > size of the http header? No. TCP is (supposed to be) oblivious to the send low-water mark. The only code that looks at it is the code which determines whether a process blocked or selecting on the socket should be awakened to frob it. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 1 18:46:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9AFF037B491 for ; Thu, 1 Feb 2001 18:46:04 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f122ju108100; Thu, 1 Feb 2001 18:45:56 -0800 (PST) Date: Thu, 1 Feb 2001 18:45:56 -0800 From: Alfred Perlstein To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: sendfile() Message-ID: <20010201184555.W26076@fw.wintelcom.net> References: <1217774688.20010201133139@163.net> <20010201023825.A71975@xor.obsecurity.org> <20010201180010.Q70673@hand.dotat.at> <001d01c08cb1$9c445d80$6201a8c0@William> <20010202005018.Y70673@hand.dotat.at> <20010201170214.V26076@fw.wintelcom.net> <200102020120.UAA81418@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102020120.UAA81418@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Feb 01, 2001 at 08:20:36PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [010201 17:20] wrote: > < said: > > > Wouldn't the socket low water mark address this though as long > > as it was > size of the http header? > > No. TCP is (supposed to be) oblivious to the send low-water mark. > The only code that looks at it is the code which determines whether a > process blocked or selecting on the socket should be awakened to frob > it. How wonderfully obtuse. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 0:21:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id B465537B491 for ; Fri, 2 Feb 2001 00:21:02 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f128KUH00943; Fri, 2 Feb 2001 00:20:31 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Fri, 2 Feb 2001 00:20:30 -0800 (PST) From: Yu-Shun Wang To: Alex Rousskov Cc: Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, What you pointed out below is true. But I am more interested in the relative performance since the number I measured were under exactly the same setup and traffic condition. I am just curious why IPComp was _relatively_ (and signigicantly) slower than most of the encryption algorithm. So I guess bandwidth is probably not the best pointer since what I end up comparing was really the implementations of different encryption/compression algorithms which are CPU-bound in this case. regards, yushun. > AFAIK, netperf TCP_STREAM test (and may be others) is extremely > susceptible to network delays. For example, for a fast Ethernet > connection with, say, 30msec packet delay, netperf may show less than > 10Mbits/sec bandwidth instead of the usual 90+Mbits/sec. Clearly, > bandwidth and response times are orthogonal measurements, but netperf > design ties them together. > > Depending on your test environment and purposes, netperf throughput > results may be very misleading. > > $0.02, > > Alex. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 0:32:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 47C1337B684 for ; Fri, 2 Feb 2001 00:32:16 -0800 (PST) Received: (qmail 3843 invoked by uid 1000); 2 Feb 2001 08:32:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Feb 2001 08:32:14 -0000 Date: Fri, 2 Feb 2001 02:32:14 -0600 (CST) From: Mike Silbersack To: Yu-Shun Wang Cc: Alex Rousskov , Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Yu-Shun Wang wrote: > Hi, > > What you pointed out below is true. But I am more > interested in the relative performance since the number > I measured were under exactly the same setup and traffic > condition. I am just curious why IPComp was _relatively_ > (and signigicantly) slower than most of the encryption > algorithm. So I guess bandwidth is probably not the best > pointer since what I end up comparing was really the > implementations of different encryption/compression > algorithms which are CPU-bound in this case. > > regards, > > yushun. I don't understand why you're comparing encryption and compression algorithms. Yes, encryption does a lot of bit twiddling, which takes up processor time. However, compression has to do a lot of comparisons, looking back and ahead all the time. It's quite amazing to me that a compression algorithm even comes close to the speed of an encryption algorithm, frankly. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 2:12:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id AA90A37B503 for ; Fri, 2 Feb 2001 02:12:21 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f12ACEn17692 for ; Fri, 2 Feb 2001 19:12:14 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@freebsd.org Subject: packet loss when 'ipfw pipe list' with dummynet and bridge X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010202191214B.ishizuka@onion.ish.org> Date: Fri, 02 Feb 2001 19:12:14 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 19 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I use dummynet and bridge on FreeBSD 4.2-Stable to see traffic statics on Celeron 466MHz with 256 mega bytes ram as follows. ipfw pipe 1 config mask dst-ip 0xffffffff buckets 1024 ipfw pipe 2 config mask src-ip 0xffffffff buckets 1024 ipfw add pipe 1 all from any to any bridged via fxp0 in ipfw add pipe 2 all from any to any bridged via fxp1 in It is collected about 10,000 addresses each pipes. When I typed 'ipfw pipe list', packet loss occur. Packet loss occur only recent 4.2-Stable with splimp() instead of splnet(). When I replaced splimp() of dummynet_get() in ip_dummynet.c with slpnet(), packet loss did not occur, but sometimes panic occur. Is there any way to stop packet loss. Sorry to my terrible English. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 2:24:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id BA12037B503 for ; Fri, 2 Feb 2001 02:24:02 -0800 (PST) Received: (qmail 3992 invoked by uid 666); 2 Feb 2001 10:32:02 -0000 Received: from reggae-13-17.nv.iinet.net.au (HELO elischer.org) (203.59.79.17) by mail.m.iinet.net.au with SMTP; 2 Feb 2001 10:32:02 -0000 Message-ID: <3A7A8AA5.625ADA@elischer.org> Date: Fri, 02 Feb 2001 02:23:34 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Geoffrey Crompton (RMIT Guest)" Cc: freebsd-net@freebsd.org Subject: Re: pseudo interface and ioctls References: <20010201103716.A23667@gecko.eric.net.au> <3A791528.BC4593E2@elischer.org> <20010202092233.A986@gecko.eric.net.au> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Geoffrey Crompton (RMIT Guest)" wrote: > > On Wed, Jan 31, 2001 at 11:50:01PM -0800, Julian Elischer wrote: > > "Geoffrey Crompton (RMIT Guest)" wrote: > > > > why are you doing this? > > there are already 4 pseudo interfaces in the system of varying types.. > > > > netgraph(2 types), divert, tap, tun. > > > > what do you need to do? > > > > I need to do packet translation between different AF_ types. I haven't seen > any interfaces that do that. (I haven't got too much experience though) can you be more specific? > > Geoff > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 4:37:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from eng05.embratel.net.br (eng05.embratel.net.br [200.255.125.133]) by hub.freebsd.org (Postfix) with ESMTP id 4DD7937B401; Fri, 2 Feb 2001 04:37:32 -0800 (PST) Received: from jonny.eng.br (willow [200.255.125.142]) by eng05.embratel.net.br (Postfix) with ESMTP id 86A6624D2D; Fri, 2 Feb 2001 10:37:25 -0200 (BRST) Message-ID: <3A7AAA2F.70CDFDAA@jonny.eng.br> Date: Fri, 02 Feb 2001 10:38:07 -0200 From: Joao Carlos Mendes Luis Organization: Internet via Embratel X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: Julian Elischer , questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: transparent proxying through a separate machine References: <200102012307.f11N7iP51027@misha.privatelabs.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mi@aldan.algebra.com wrote: > > On 1 Feb, Julian Elischer wrote: > = > We have a single firewall machine and a _separate_ machine running > = > squid proxy (both servers are on the same network wire). > = > > = > How do I catch all of the outgoing http requests and send them > = > through squid? > = > > = > I tried > = > > = > ipfw add fwd squid,3128 tcp from any to any http > = > > = > but it does not seem to work -- squid never gets contacted. All of > = > the recipes out there describe the setups with squid and the > = > firewall being on the same machine. What else do I need to do? > = > = I assume squid is the name of the other machine? you need to have the > = same rule in the ipfw on that machine too. > > Yes. Ok. This is what I just added to the squid-machine: > > ipfw add allow ip from any to any out > ipfw add fwd localhost,3128 log tcp from any to any 3128 in Do not change the port in the first machine. Maybe even better, do not change the port at all, and let squid listen on port 80 also! > > = otherwise it will reflect the packet back at it's original destination > = as it still has headers saying it wants to go there. (It's unaltered). > > The firewall machine logs > > ipfw: 3000 Forward to squid.ip:3128 TCP client.ip:3977 web.server.ip:80 in via dc0 > > But the client still talks to the web-server directly :( The squid's log > is quiet... Anything I'm missing? Perhaps, I need a user-space program > of some sort to run on the firewall to do the tunneling? Thanks! IIRC, ipfw fwd to another machine does not change tcp port number, that why I suggested the above. Jonny -- João Carlos Mendes Luís jonny@embratel.net.br Networking Engineer jonny@jonny.eng.br Internet via Embratel jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6: 7:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from virtual2.sysadmin-inc.com (unknown [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id AA9ED37B401 for ; Fri, 2 Feb 2001 06:07:23 -0800 (PST) Received: (qmail 1800 invoked by alias); 2 Feb 2001 14:07:22 -0000 Received: from unknown (HELO wkst) (10.10.1.70) by virtual2.fire.sysadmin-inc.com with SMTP; 2 Feb 2001 14:07:22 -0000 Reply-To: From: "Peter Brezny" To: Subject: kernel arp messages with 2 nics, sysctl cntrl? Date: Fri, 2 Feb 2001 09:06:42 -0500 Message-ID: <000401c08d21$5ed61720$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I thought I rememberd someone mentioning a sysctl control for turning off the kernel arp messages when you have two nics on the same (misconfigured) network, but I couldn't find it in the archives. Anyone know? Thanks. Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6:15:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2112837B491 for ; Fri, 2 Feb 2001 06:15:17 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f12EFBs70349; Fri, 2 Feb 2001 06:15:11 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200102021415.f12EFBs70349@iguana.aciri.org> Subject: Re: packet loss when 'ipfw pipe list' with dummynet and bridge In-Reply-To: <20010202191214B.ishizuka@onion.ish.org> from Masachika ISHIZUKA at "Feb 2, 2001 7:12:14 pm" To: ishizuka@ish.org (Masachika ISHIZUKA) Date: Fri, 2 Feb 2001 06:15:11 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I use dummynet and bridge on FreeBSD 4.2-Stable to see traffic > statics on Celeron 466MHz with 256 mega bytes ram as follows. > > ipfw pipe 1 config mask dst-ip 0xffffffff buckets 1024 > ipfw pipe 2 config mask src-ip 0xffffffff buckets 1024 > ipfw add pipe 1 all from any to any bridged via fxp0 in > ipfw add pipe 2 all from any to any bridged via fxp1 in > > It is collected about 10,000 addresses each pipes. > When I typed 'ipfw pipe list', packet loss occur. > Packet loss occur only recent 4.2-Stable with splimp() > instead of splnet(). When I replaced splimp() of dummynet_get() > in ip_dummynet.c with slpnet(), packet loss did not occur, > but sometimes panic occur. > Is there any way to stop packet loss. unfortunately the "pipe list" has to navigate through a list of pipe/flow/queue descriptors to report its output, and at the moment it does this with interrupts disabled to avoid that the data structure changes while it is working. A better approach would probably be to set a semaphore before starting, and release it at the end, and keep interrupts enabled during the transfer but make sure that no object is created or deleted and no pointer is changed during the process. You can still risk loss (when e.g. you cannot create a new flow descriptor) but better than the current method. cheers luigi > Sorry to my terrible English. > > -- > ishizuka@ish.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6:31:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (ny-ppp022.iij-us.net [216.98.99.22]) by hub.freebsd.org (Postfix) with ESMTP id 98A1837B4EC for ; Fri, 2 Feb 2001 06:31:24 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 61C0F7E2A; Fri, 2 Feb 2001 23:31:09 +0900 (JST) To: Yu-Shun Wang Cc: Alex Rousskov , freebsd-net@FreeBSD.ORG In-reply-to: yushunwa's message of Fri, 02 Feb 2001 00:20:30 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPComp question From: Jun-ichiro itojun Hagino Date: Fri, 02 Feb 2001 23:31:09 +0900 Message-Id: <20010202143109.61C0F7E2A@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What you pointed out below is true. But I am more > interested in the relative performance since the number > I measured were under exactly the same setup and traffic > condition. I am just curious why IPComp was _relatively_ > (and signigicantly) slower than most of the encryption > algorithm. So I guess bandwidth is probably not the best > pointer since what I end up comparing was really the > implementations of different encryption/compression > algorithms which are CPU-bound in this case. did you try running these benchmarks on loopback interface? (i.e. sender and receiver on the same node) itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6:49: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 07ACE37B491; Fri, 2 Feb 2001 06:48:32 -0800 (PST) Received: from elischer.org (reggae-14-13.nv.iinet.net.au [203.59.77.13]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA15307; Fri, 2 Feb 2001 22:48:22 +0800 Message-ID: <3A7AC89D.771FF88B@elischer.org> Date: Fri, 02 Feb 2001 06:47:57 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: questions@freebsd.org, net@freebsd.org Subject: Re: transparent proxying through a separate machine References: <200102012307.f11N7iP51027@misha.privatelabs.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mi@aldan.algebra.com wrote: > > On 1 Feb, Julian Elischer wrote: > = > We have a single firewall machine and a _separate_ machine running > = > squid proxy (both servers are on the same network wire). > = > > = > How do I catch all of the outgoing http requests and send them > = > through squid? > = > > = > I tried > = > > = > ipfw add fwd squid,3128 tcp from any to any http > = > > = > but it does not seem to work -- squid never gets contacted. All of > = > the recipes out there describe the setups with squid and the > = > firewall being on the same machine. What else do I need to do? > = > = I assume squid is the name of the other machine? you need to have the > = same rule in the ipfw on that machine too. > > Yes. Ok. This is what I just added to the squid-machine: > > ipfw add allow ip from any to any out > ipfw add fwd localhost,3128 log tcp from any to any 3128 in > > = otherwise it will reflect the packet back at it's original destination > = as it still has headers saying it wants to go there. (It's unaltered). > > The firewall machine logs > > ipfw: 3000 Forward to squid.ip:3128 TCP client.ip:3977 web.server.ip:80 in via dc0 here's the rules (approx) I just gave someone else: -----------------BEGIN QUOTED MAIL------ > After adding the command: > > ipfw add 100 fwd 192.168.10.1 tcp from any to any 80 in via fxp0 > > I see no packet arrive at host 192.168.10.1. Do forwarded packets > re-enter the firewall for a given outgoing interface? In this case > ed1 ? Or are they somehow skipped and just routed out the interface after > a match is made? The man page says: fwd ipaddr[,port] Change the next-hop on matching packets to ipaddr, which can be an IP address in dotted quad or a host name. If ipaddr is not a directly-reachable address, the route as found in the local routing table for that IP is used in- stead. If ipaddr is a local address, then on a packet entering the system from a remote host it will be divert- ed to port on the local machine, keeping the local ad- dress of the socket set to the original IP address the packet was destined for. This is intended for use with transparent proxy servers. If the IP is not a local ad- dress then the port number (if specified) is ignored and the rule only applies to packets leaving the system. This will also map addresses to local ports when packets are generated locally. The search terminates if this rule matches. If the port number is not given then the port number in the packet is used, so that a packet for an external machine port Y would be forwarded to local port Y. The kernel must have been compiled with the IPFIREWALL_FORWARD option. > > After changing the above ipfw command to 'out via xl0' I start seeing > incoming packets on the 192.168.10.1 host. Do IPFW Forward rules only > apply to outgoing style rules? yes, read the paragraph above: If the IP is not a local ad- dress then the port number (if specified) is ignored and the rule only applies to packets leaving the system. and If ipaddr is a local address, then on a packet entering the system from a remote host it will be divert- ed to port on the local machine, keeping the local ad- dress of the socket set to the original IP address the packet was destined for. In other words, you want a rule with 'fwd 192.168.10.1 tcp from any to any 80 out rcv fxp0 xmit xl0' on the gateway so that it only matches http requests from clients on the local net but NOT requests from your proxy. then on the proxy you must have the rule: 'fwd 127.0.0.1:3187 tcp from 192.168.20.0/24 80 in rcv [interface]' so that the packet are 'captured' on that machine instead of being dumped. ----------------- > > But the client still talks to the web-server directly :( The squid's log > is quiet... Anything I'm missing? Perhaps, I need a user-space program > of some sort to run on the firewall to do the tunneling? Thanks! > > -mi -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6:49: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 5C53937B4EC for ; Fri, 2 Feb 2001 06:48:33 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA15332; Fri, 2 Feb 2001 22:48:31 +0800 Received: from elischer.org (reggae-14-13.nv.iinet.net.au [203.59.77.13]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id WAA02340; Fri, 2 Feb 2001 22:46:07 +0800 Message-ID: <3A7AC8A3.3DC68FCD@elischer.org> Date: Fri, 02 Feb 2001 06:48:03 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Nick Rogness Cc: freebsd-net@freebsd.org Subject: Re: ipfw fwd References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > Couple of comments on ipfw fwd. > > After playing around with the forward feature of ipfw, I ran into a couple > of interesting things. First let me give you my test lab environment > diagram: > > Internet > | > xl0 > | > 192.168.10.1 ----ed1---FreeBSD > | > fxp0 > | > 192.168.20.0/24 > > After adding the command: > > ipfw add 100 fwd 192.168.10.1 tcp from any to any 80 in via fxp0 > > I see no packet arrive at host 192.168.10.1. Do forwarded packets > re-enter the firewall for a given outgoing interface? In this case > ed1 ? Or are they somehow skipped and just routed out the interface after > a match is made? The man page says: fwd ipaddr[,port] Change the next-hop on matching packets to ipaddr, which can be an IP address in dotted quad or a host name. If ipaddr is not a directly-reachable address, the route as found in the local routing table for that IP is used in- stead. If ipaddr is a local address, then on a packet entering the system from a remote host it will be divert- ed to port on the local machine, keeping the local ad- dress of the socket set to the original IP address the packet was destined for. This is intended for use with transparent proxy servers. If the IP is not a local ad- dress then the port number (if specified) is ignored and the rule only applies to packets leaving the system. This will also map addresses to local ports when packets are generated locally. The search terminates if this rule matches. If the port number is not given then the port number in the packet is used, so that a packet for an external machine port Y would be forwarded to local port Y. The kernel must have been compiled with the IPFIREWALL_FORWARD option. > > After changing the above ipfw command to 'out via xl0' I start seeing > incoming packets on the 192.168.10.1 host. Do IPFW Forward rules only > apply to outgoing style rules? yes, read the paragraph above: If the IP is not a local ad- dress then the port number (if specified) is ignored and the rule only applies to packets leaving the system. and If ipaddr is a local address, then on a packet entering the system from a remote host it will be divert- ed to port on the local machine, keeping the local ad- dress of the socket set to the original IP address the packet was destined for. In other words, you want a rule with 'fwd 192.168.10.1 tcp from any to any 80 out rcv fxp0 xmit xl0' on the gateway so that it only matches http requests from clients on the local net but NOT requests from your proxy. then on the proxy you must have the rule: 'fwd 127.0.0.1:3187 tcp from 192.168.20.0/24 80 in rcv [interface]' so that the packet are 'captured' on that machine instead of being dumped. > > Nick Rogness > - Keep on routing in a Free World... > "FreeBSD: The Power to Serve " > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 6:54:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id A68E937B491; Fri, 2 Feb 2001 06:54:27 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id WAA16039; Fri, 2 Feb 2001 22:54:24 +0800 Received: from elischer.org (reggae-14-13.nv.iinet.net.au [203.59.77.13]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id WAA02613; Fri, 2 Feb 2001 22:51:59 +0800 Message-ID: <3A7ACA03.BA4D3F31@elischer.org> Date: Fri, 02 Feb 2001 06:53:55 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Joao Carlos Mendes Luis Cc: mi@aldan.algebra.com, questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: transparent proxying through a separate machine References: <200102012307.f11N7iP51027@misha.privatelabs.com> <3A7AAA2F.70CDFDAA@jonny.eng.br> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joao Carlos Mendes Luis wrote: > > ipfw add allow ip from any to any out the probele is the line above. > > ipfw add fwd localhost,3128 log tcp from any to any 3128 in the above shoudl be 'out'.. FWD is not symetrical.. you can only fwd locally on 'in' and fwd remotly on 'out'. It says this in the man page but it's a bit hard to read. I should fix it.. > > Do not change the port in the first machine. Maybe even better, do not > change the port at all, and let squid listen on port 80 also! you need to have a rule on the squid machine too, so you might as well set it to 3128 so that people can use it directly as well not only as a transparent proxy.. > > > > > = otherwise it will reflect the packet back at it's original destination > > = as it still has headers saying it wants to go there. (It's unaltered). > > > > The firewall machine logs > > > > ipfw: 3000 Forward to squid.ip:3128 TCP client.ip:3977 web.server.ip:80 in via dc0 > > > > But the client still talks to the web-server directly :( The squid's log > > is quiet... Anything I'm missing? Perhaps, I need a user-space program > > of some sort to run on the firewall to do the tunneling? Thanks! > > IIRC, ipfw fwd to another machine does not change tcp port number, that why > I suggested the above. yes the port to use is specified in the rule on the ipfw on the squid machine. (it needs one too because it needs to capture a packet that is destined some completely different place.) > > Jonny > > -- > João Carlos Mendes Luís jonny@embratel.net.br > Networking Engineer jonny@jonny.eng.br > Internet via Embratel jcml@ieee.org -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 7: 8:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 9CD7437B401 for ; Fri, 2 Feb 2001 07:08:23 -0800 (PST) Received: (qmail 16535 invoked by uid 666); 2 Feb 2001 15:15:40 -0000 Received: from reggae-14-13.nv.iinet.net.au (HELO elischer.org) (203.59.77.13) by mail.m.iinet.net.au with SMTP; 2 Feb 2001 15:15:40 -0000 Message-ID: <3A7ACD4B.155B2657@elischer.org> Date: Fri, 02 Feb 2001 07:07:55 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Luigi Rizzo Cc: "Rogier R. Mulhuijzen" , erwan@netvalue.com, roman@IPricot.com, freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: bandwidth analyser References: <200101292359.f0TNxOU48488@iguana.aciri.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Luigi Rizzo wrote: > > > There's one downside though. You can get statistics from the bridge node on > > packets and octects passed through the different parts of the bridge > > setyup, but it's not IP based. Also using that bridging code there's no > > bandwidth throttling or IPFW rule matching yet. > > > > Vitaly Belekhov wrote BW throttling and ipfw netgraph nodes for 3.X, and I > > will be porting those to 5.X-CURRENT over the next few weeks. The new ethernet node netgrpah interface (with 'upper' and 'lower') may influence this. also the ipfw he used is very old now. > > > > Using those you could get statistics really quickly by using libnetgraph > > and querying the nodes yourself with some C code instead of shell/perl > > scripting. > > the real problem with any approach is that if you have very many > flows, you have to fetch all the info every time you want to update > your statistics. The ipfw implementation which is in the kernel > now really does not help you there, because the stats are spread > over lists and hash tables, and on top of this the data structure > evolves dynamically as pkts come in, so you need to hold a lock > while navigating on it. > > This is why you do not want to download the stats 10-20 times per > second, at least with this architecture. > > I do not have a good solution in mind other than maybe > change the data structures so that the flow descriptors > (at least the part with the flow identifier and the stats) > are in a contiguous chunk of memory whose only variable > part is the size. This way you can either mmap the block, > or copyout() it without having to get a lock. > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 7: 9:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (unknown [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id BBE9037B503 for ; Fri, 2 Feb 2001 07:08:52 -0800 (PST) Received: from localhost (rousskov@localhost) by measurement-factory.com (8.9.3/8.9.3) with ESMTP id IAA94276; Fri, 2 Feb 2001 08:08:20 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Date: Fri, 2 Feb 2001 08:08:20 -0700 (MST) From: Alex Rousskov To: Yu-Shun Wang Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Yu-Shun Wang wrote: > What you pointed out below is true. But I am more > interested in the relative performance since the number > I measured were under exactly the same setup and traffic > condition. I believe it is a common pitfall to assume that same conditions allow for relative comparisons even when the measurement tool or methodology is "broken". The relative results may amaze you, but I would not trust them. :) > I am just curious why IPComp was _relatively_ > (and signigicantly) slower than most of the encryption > algorithm. If by "slower" you mean "yields lower throughput" under netperf, then keep in mind that your test probably did not measure throughput correctly. Here is an example. Let's assume that algorithm A delays every packet by 1msec and algorithm B delays every packet by 2msec. For simplicity, let's also assume that packet sizes do not change. Under correct testing conditions, both algorithms should yield the same throughput (X Mbits/sec). With netperf's TCP_STREAM, the throughput of A will be times 2 higher than the throughput of B! > So I guess bandwidth is probably not the best > pointer since what I end up comparing was really the > implementations of different encryption/compression > algorithms which are CPU-bound in this case. I would suggest to define exactly what you want to compare first (i.e., decide what your primary metrics are; why you are running these tests) and only then design the test and choose an appropriate benchmark. Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 7:14:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from cgaylord.async.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id 0F8C837B4EC for ; Fri, 2 Feb 2001 07:14:15 -0800 (PST) Received: by cgaylord.async.vt.edu (Postfix, from userid 1000) id 7756BFD; Fri, 2 Feb 2001 10:14:13 -0500 (EST) To: freebsd-net@freebsd.org Subject: (fwd) Re: FreeBSD ip masq, ip aliasing From: cgaylord@vt.edu Message-Id: <20010202151413.7756BFD@cgaylord.async.vt.edu> Date: Fri, 2 Feb 2001 10:14:13 -0500 (EST) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently posted this to comp.unix.bsd.misc and thought I'd go ahead and air this idea here. I'd appreciate any criticism, constructive or otherwise, this group would care to heap upon me. Thanks. Clark John M Cherko wrote: > I am confused as to how to accomplish ip aliasing/ip masqing (I > believe they are the same) on a FreeBSD system. I currently run Linux 2.2 > now and have stuck with it because I know how to run ip masqing on it. > I have been wanting to switch over to a BSD, mainly FreeBSD because of the The way it works is via BSD's "divert" sockets. You have ipfw (or ipfirewall, if you like) divert traffic to natd. It is all spelled out very nicely in the natd man page. The other firewall config is done via ipfw. You will likely want to hack rc.firewall to suit your needs; this is a very readable script, so mods are pretty straight-forward. The SIMPLE method may work ok for you, though; read the script and see. I am working on a way to do a larger class of firewalls via rc.conf variables, but that still needs some work. man natd man ipfw man divert build kernel with IPFIREWALL vi /etc/rc.conf vi /etc/rc.firewall I can't really compare it to Linux. It works well, the code is readable (if you are interested in that). It is quite flexible. Following, for example, is my ipfw setup (via ipfw list). I've cleaned off my IP address; rl0 is inside; rl1 is outside. My setup is perhaps a bit promiscuous for some people's taste, but I run POP3, IMAP, web, ftp, et al. I also run tcpwrappers (actually this is built into FreeBSD's inetd!) to clean some of this up, and I log pretty gratuitously except as noted below (you'll notice I don't pay attention to probes on tcp113, udp137, or udp138). I use 10.0.1.0/24 for my inside. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 allow ip from 10.0.1.0/24 to any via rl0 00400 allow ip from any to 10.0.1.0/24 via rl0 00500 allow udp from 0.0.0.0 68 to 255.255.255.255 67 via rl0 00600 deny log logamount 100 ip from any to any via rl0 00700 deny ip from 10.0.1.0/24 to any in recv rl1 00800 deny ip from to any in recv rl0 00900 deny ip from any to 10.0.0.0/8 via rl1 01000 deny ip from any to 172.16.0.0/12 via rl1 01100 deny ip from any to 192.168.0.0/16 via rl1 01200 deny ip from any to 0.0.0.0/8 via rl1 01300 deny ip from any to 169.254.0.0/16 via rl1 01400 deny ip from any to 192.0.2.0/24 via rl1 01500 deny ip from any to 224.0.0.0/4 via rl1 01600 deny ip from any to 240.0.0.0/4 via rl1 01700 divert 8668 ip from any to any via rl1 01800 deny ip from 10.0.0.0/8 to any via rl1 01900 deny ip from 172.16.0.0/12 to any via rl1 02000 deny ip from 192.168.0.0/16 to any via rl1 02100 deny ip from 0.0.0.0/8 to any via rl1 02200 deny ip from 169.254.0.0/16 to any via rl1 02300 deny ip from 192.0.2.0/24 to any via rl1 02400 deny ip from 224.0.0.0/4 to any via rl1 02500 deny ip from 240.0.0.0/4 to any via rl1 02600 allow tcp from any to any established 02700 allow ip from any to any frag 02800 allow tcp from any to 9 setup 02900 allow tcp from any to 21 setup 03000 allow tcp from any to 22 setup 03100 allow tcp from any to 23 setup 03200 allow tcp from any to 25 setup 03300 allow tcp from any to 37 setup 03400 allow tcp from any to 79 setup 03500 allow tcp from any to 80 setup 03600 allow tcp from any to 110 setup 03700 allow tcp from any to 143 setup 03800 allow tcp from any to 515 setup 03900 allow tcp from any to 51210 setup 04000 allow udp from any to 37 04100 allow udp from any 37 to 04200 allow udp from any to 53 04300 allow udp from any 53 to 04400 allow udp from any to 123 04500 allow udp from any 123 to 04600 allow udp from any to 161 04700 allow udp from any 161 to 04800 allow udp from any to 51200 04900 allow udp from any 51200 to 05000 allow udp from any to 51201 05100 allow udp from any 51201 to 05200 deny tcp from any to 113 setup 05300 deny udp from any to any 137 via rl1 05400 deny udp from any to any 138 via rl1 05500 deny log logamount 100 tcp from any to via rl1 setup 05600 deny log logamount 100 udp from any to via rl1 65535 allow ip from any to any This was generated by the following diff to rc.firewall (remember, this is for illustration purposes only; I want to clean this up a little more before submitting it ... but I'd be happy to hear comments/criticisms). > [Cc][Uu][Ss][Tt][Oo][Mm]) > # Clark's custom setup. Based loosely on simple. > # Variables to snarf from rc.conf: > # outside_if > # outside_net > # outside_mask > # outside_ip > # inside_if > # inside_net > # inside_mask > # inside_ip > # tcp_allow > # udp_allow > # tcp_deny > # tcp_deny_log > # udp_deny > # udp_deny_log > > # Allow only inside net addresses and DHCP on inside interface > ${fwcmd} add allow all from ${inside_net}:${inside_mask} to any \ > via ${inside_if} > ${fwcmd} add allow all from any to ${inside_net}:${inside_mask} \ > via ${inside_if} > ${fwcmd} add allow udp from 0.0.0.0 68 to 255.255.255.255 67 \ > via ${inside_if} > ${fwcmd} add deny log all from any to any via ${inside_if} > > # Stop spoofing > ${fwcmd} add deny all from ${inside_net}:${inside_mask} to any \ > in via ${outside_if} > ${fwcmd} add deny all from ${outside_net}:${outside_mask} to any \ > in via ${inside_if} > > # RFC1918 > ${fwcmd} add deny all from any to 10.0.0.0/8 via ${outside_if} > ${fwcmd} add deny all from any to 172.16.0.0/12 via ${outside_if} > ${fwcmd} add deny all from any to 192.168.0.0/16 via ${outside_if} > > # manning > ${fwcmd} add deny all from any to 0.0.0.0/8 via ${outside_if} > ${fwcmd} add deny all from any to 169.254.0.0/16 via ${outside_if} > ${fwcmd} add deny all from any to 192.0.2.0/24 via ${outside_if} > ${fwcmd} add deny all from any to 224.0.0.0/4 via ${outside_if} > ${fwcmd} add deny all from any to 240.0.0.0/4 via ${outside_if} > > # NAT > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > ${fwcmd} add divert natd all from any to any \ > via ${natd_interface} > fi > ;; > esac > > # I guess we can allow something > ${fwcmd} add allow tcp from any to any established > ${fwcmd} add allow all from any to any frag > > # need to check for null/unset > for port in ${tcp_allow}; do > ${fwcmd} add allow tcp from any to ${outside_ip} ${port} setup > done > for port in ${udp_allow}; do > ${fwcmd} add allow udp from any to ${outside_ip} ${port} > ${fwcmd} add allow udp from any ${port} to ${outside_ip} > done > > for port in ${tcp_deny_log}; do > ${fwcmd} add deny log tcp from any to ${outside_ip} ${port} setup > done > for port in ${tcp_deny}; do > ${fwcmd} add deny tcp from any to ${outside_ip} ${port} setup > done > > for port in ${udp_deny_log}; do > ${fwcmd} add deny log udp from any to any ${port} via ${outside_if} > done > for port in ${udp_deny}; do > ${fwcmd} add deny udp from any to any ${port} via ${outside_if} > done > > # deny and log all other connection attempts on outside interface > ${fwcmd} add deny log tcp from any to ${outside_ip} setup via ${outside_if} > ${fwcmd} add deny log udp from any to ${outside_ip} via ${outside_if} > ;; > I don't often read this newsgroup, so if you want to respond to the group send me a pointer e-mail or cc: me. ;-) -- Clark K. Gaylord Senior Research Engineer Communications Network Services Virginia Tech, Blacksburg, Virginia 24061-0506 Voice: 540/231-2347 Fax: 540/231-3928 E-mail: cgaylord@cns.vt.edu -- end of forwarded message -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 8: 0:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from ayax.uniandes.edu.co (Ayax.uniandes.edu.co [157.253.50.3]) by hub.freebsd.org (Postfix) with ESMTP id 3C4FE37B65D for ; Fri, 2 Feb 2001 07:59:57 -0800 (PST) Received: from webmail (isis.uniandes.edu.co [157.253.54.5]) by ayax.uniandes.edu.co (8.11.0/8.11.0) with SMTP id f12FxlP29249 for freebsd-net@freebsd.org; Fri, 2 Feb 2001 10:59:50 -0500 (GMT+5) Date: Fri, 2 Feb 2001 10:59:50 -0500 (GMT+5) Message-Id: <200102021559.f12FxlP29249@ayax.uniandes.edu.co> From: y-carden@uniandes.edu.co To: freebsd-net@freebsd.org Subject: File miibus_if.h X-Mailer: Netscape Messenger Express 3.5.2 [Mozilla/4.73 [en] (Win98; I)] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello I need urgently add a PCI card Realtek RTL8029 to my box FreeBSD 4.0. I tried compile the kernel with "device rl" but it no found miibus_if.h file. The file not exist on the system. Can somebody send me a copy ? Thanks. Yonny Cardenas B. y-carden@uniandes.edu.co To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 8: 9:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by hub.freebsd.org (Postfix) with ESMTP id 7128A37B699 for ; Fri, 2 Feb 2001 08:09:06 -0800 (PST) Received: from fwd00.sul.t-online.com by mailout02.sul.t-online.com with smtp id 14Oilf-0006Ba-00; Fri, 02 Feb 2001 17:08:59 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.195.173]) by fmrl00.sul.t-online.com with esmtp id 14OilR-0mXPF2C; Fri, 2 Feb 2001 17:08:45 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id E8A56AB44; Fri, 2 Feb 2001 17:09:13 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BC0E014A5C; Fri, 2 Feb 2001 17:08:50 +0100 (CET) Date: Fri, 2 Feb 2001 17:08:50 +0100 To: y-carden@uniandes.edu.co Cc: freebsd-net@freebsd.org Subject: Re: File miibus_if.h Message-ID: <20010202170850.A60204@cichlids.cichlids.com> References: <200102021559.f12FxlP29249@ayax.uniandes.edu.co> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102021559.f12FxlP29249@ayax.uniandes.edu.co>; from y-carden@uniandes.edu.co on Fri, Feb 02, 2001 at 10:59:50AM -0500 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake y-carden@uniandes.edu.co (y-carden@uniandes.edu.co): > I tried compile the kernel with "device rl" but it no found > miibus_if.h file. The file not exist on the system. Add "device miibus" to your config file. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 8:12:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 935D637B69C for ; Fri, 2 Feb 2001 08:12:06 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 17FCB28688; Fri, 2 Feb 2001 22:12:02 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 076A228670; Fri, 2 Feb 2001 22:12:02 +0600 (ALMT) Date: Fri, 2 Feb 2001 22:12:01 +0600 (ALMT) From: Boris Popov To: y-carden@uniandes.edu.co Cc: freebsd-net@freebsd.org Subject: Re: File miibus_if.h In-Reply-To: <200102021559.f12FxlP29249@ayax.uniandes.edu.co> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001 y-carden@uniandes.edu.co wrote: > I need urgently add a PCI card Realtek RTL8029 to > my box FreeBSD 4.0. > > I tried compile the kernel with "device rl" but it no found > miibus_if.h file. The file not exist on the system. ed driver works just perfect with 8029 chips. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 9:30:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.megacom.com.br (unknown [200.244.138.3]) by hub.freebsd.org (Postfix) with SMTP id 97A9937B6A2 for ; Fri, 2 Feb 2001 09:30:23 -0800 (PST) Received: from estudiosmega.com.br ([200.244.138.118]) by mail.megacom.com.br (AppleShare IP Mail Server 6.2.1) id 56513 via TCP with SMTP; Fri, 02 Feb 2001 15:30:15 -0200 Message-ID: <3A7A6181.95C1EC3A@estudiosmega.com.br> Date: Fri, 02 Feb 2001 15:28:01 +0800 From: Eron Cardoso X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: y-carden@uniandes.edu.co Cc: freebsd-net@freebsd.org Subject: Re: File miibus_if.h References: <200102021559.f12FxlP29249@ayax.uniandes.edu.co> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Try device ed0 My machine: ed0: port 0xcc00-0xcc1f irq 11 at device 17 .0 on pci0 y-carden@uniandes.edu.co wrote: > > Hello > > I need urgently add a PCI card Realtek RTL8029 to > my box FreeBSD 4.0. > > I tried compile the kernel with "device rl" but it no found > miibus_if.h file. The file not exist on the system. > > Can somebody send me a copy ? > > Thanks. > > Yonny Cardenas B. > y-carden@uniandes.edu.co > > 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 Feb 2 9:35:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.eurosoft-uk.com (unknown [194.73.89.1]) by hub.freebsd.org (Postfix) with ESMTP id BCF1D37B6A7 for ; Fri, 2 Feb 2001 09:35:36 -0800 (PST) Received: from ESUK02.Eurosoft-UK.com (esuk02.eurosoft-uk.com [192.168.1.2]) by mailhost.eurosoft-uk.com (8.9.3/8.9.3) with ESMTP id RAA91958; Fri, 2 Feb 2001 17:42:38 GMT (envelope-from DavidR@eurosoft-uk.com) Received: by ESUK02.Eurosoft-UK.com with Internet Mail Service (5.5.2653.19) id <1BZJ21FZ>; Fri, 2 Feb 2001 17:35:50 -0000 Message-ID: <23AF6C4F864B4F42948DA24DDC828AA0145C@ESUK02.Eurosoft-UK.com> From: David Richards To: "'Eron Cardoso'" Cc: "'freebsd-net@freebsd.org'" Subject: RE: File miibus_if.h Date: Fri, 2 Feb 2001 17:35:49 -0000 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 X-Loop: FreeBSD.org isnt that something to do with usb ? i have had that problem before and just comment the usb part out as i dont need it have you tried commenting the network cards out and just putting device ed0 if it is pci, it should detect it david -----Original Message----- From: Eron Cardoso [mailto:eron@estudiosmega.com.br] Sent: 02 February 2001 07:28 To: y-carden@uniandes.edu.co Cc: freebsd-net@FreeBSD.ORG Subject: Re: File miibus_if.h Try device ed0 My machine: ed0: port 0xcc00-0xcc1f irq 11 at device 17 .0 on pci0 y-carden@uniandes.edu.co wrote: > > Hello > > I need urgently add a PCI card Realtek RTL8029 to > my box FreeBSD 4.0. > > I tried compile the kernel with "device rl" but it no found > miibus_if.h file. The file not exist on the system. > > Can somebody send me a copy ? > > Thanks. > > Yonny Cardenas B. > y-carden@uniandes.edu.co > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 9:36:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from virtual2.sysadmin-inc.com (unknown [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id 2BB7C37B6A7 for ; Fri, 2 Feb 2001 09:36:19 -0800 (PST) Received: (qmail 3249 invoked by alias); 2 Feb 2001 17:36:18 -0000 Received: from unknown (HELO wkst) (10.10.1.70) by ssl.sysadmin-inc.com with SMTP; 2 Feb 2001 17:36:18 -0000 Reply-To: From: "Peter Brezny" To: Subject: ipfw and dns Date: Fri, 2 Feb 2001 12:35:29 -0500 Message-ID: <001701c08d3e$892a1860$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is this all i need to allow dns queries from the outside world? $fwcmd add allow tcp from any 53 to $ns1 53 i'm using ipfw and $ns1 just happens to be the same machine as the firewall. it's 4.2-stable (as of two days ago) and now it appears that an outsidemachine can's perform an nslookup using my box as the server to do the queries on. TIA Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 9:41: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from atro.pine.nl (atro.pine.nl [213.156.0.2]) by hub.freebsd.org (Postfix) with ESMTP id E503137B698 for ; Fri, 2 Feb 2001 09:40:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by atro.pine.nl (8.11.1/8.11.1) with ESMTP id f12HelF27937; Fri, 2 Feb 2001 18:40:47 +0100 (MET) Date: Fri, 2 Feb 2001 18:40:47 +0100 (MET) From: Mark Lastdrager To: Peter Brezny Cc: Subject: Re: ipfw and dns In-Reply-To: <001701c08d3e$892a1860$46010a0a@sysadmininc.com> Message-ID: X-NCC-RegID: nl.pine MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At Fri, 2 Feb 2001, owner-freebsd-net@FreeBSD.ORG wrote: >Is this all i need to allow dns queries from the outside world? > > $fwcmd add allow tcp from any 53 to $ns1 53 No, queries use udp and often don't use 53 as source port. And you have to make rules for both incoming and outgoing traffic.. >and now it appears that an outsidemachine can's perform an nslookup using my >box as the server to do the queries on. Look in the log and see what goes wrong ;-) There's an example in /etc/rc.firewall by the way: # Allow access to our DNS ${fwcmd} add pass tcp from any to ${oip} 53 setup ${fwcmd} add pass udp from any to ${oip} 53 ${fwcmd} add pass udp from ${oip} 53 to any Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: telnet: Unable to connect to remote host: Connection refused To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 9:49:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from ayax.uniandes.edu.co (Ayax.uniandes.edu.co [157.253.50.3]) by hub.freebsd.org (Postfix) with ESMTP id 2AF4537B698 for ; Fri, 2 Feb 2001 09:49:35 -0800 (PST) Received: from webmail (isis.uniandes.edu.co [157.253.54.5]) by ayax.uniandes.edu.co (8.11.0/8.11.0) with SMTP id f12HnAP17731; Fri, 2 Feb 2001 12:49:12 -0500 (GMT+5) Date: Fri, 2 Feb 2001 12:49:12 -0500 (GMT+5) Message-Id: <200102021749.f12HnAP17731@ayax.uniandes.edu.co> From: y-carden@uniandes.edu.co To: bp@butya.kz Cc: freebsd-net@freebsd.org Subject: Re: File miibus_if.h X-Mailer: Netscape Messenger Express 3.5.2 [Mozilla/4.73 [en] (Win98; I)] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Boris On Fri, 2 Feb 2001 Boris wrote: >> I need urgently add a PCI card Realtek RTL8029 to >> my box FreeBSD 4.0. >> >> I tried compile the kernel with "device rl" but it no found >> miibus_if.h file. The file not exist on the system. > ed driver works just perfect with 8029 chips. Yes, in boot time the kernel recognize card as ed0 Ethernet PCI 8029. With sysinstall (Networking - interfaces) the interface ed0 not appear. Either ifconfig showed it. I don't know how add and configure it. Thanks for your help. Yonny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 10:19: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 767B937B401 for ; Fri, 2 Feb 2001 10:18:32 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14OkvJ-0000A5-00; Fri, 02 Feb 2001 11:27:05 -0700 Message-ID: <3A7AFBF9.A2C7732F@softweyr.com> Date: Fri, 02 Feb 2001 11:27:05 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: cgaylord@vt.edu Cc: freebsd-net@freebsd.org Subject: Re: (fwd) Re: FreeBSD ip masq, ip aliasing References: <20010202151413.7756BFD@cgaylord.async.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org cgaylord@vt.edu wrote: > > I recently posted this to comp.unix.bsd.misc and thought I'd go > ahead and air this idea here. I'd appreciate any criticism, > constructive or otherwise, this group would care to heap upon me. > > Thanks. > Clark > > John M Cherko wrote: > > I am confused as to how to accomplish ip aliasing/ip masqing (I > > believe they are the same) on a FreeBSD system. I currently run Linux 2.2 > > now and have stuck with it because I know how to run ip masqing on it. > > I have been wanting to switch over to a BSD, mainly FreeBSD because of the > > The way it works is via BSD's "divert" sockets. You have ipfw (or > ipfirewall, if you like) divert traffic to natd. It is all spelled out > very nicely in the natd man page. The other firewall config is done via > ipfw. You will likely want to hack rc.firewall to suit your needs; this > is a very readable script, so mods are pretty straight-forward. The > SIMPLE method may work ok for you, though; read the script and see. I > am working on a way to do a larger class of firewalls via rc.conf > variables, but that still needs some work. > > man natd > man ipfw > man divert Well said. Unfortunately, you didn't include Mr. Cherko's email so I cannot reply to him as well. You can also accomplish this using ipfilter and ipnat. Some of us prefer ipfilter to ipfw, and ipfilter is available on other BSD systems as well. -- "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 Feb 2 11:11:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from secure.webhotel.net (secure.webhotel.net [195.41.202.80]) by hub.freebsd.org (Postfix) with SMTP id B7FE237B491 for ; Fri, 2 Feb 2001 11:10:59 -0800 (PST) Received: (qmail 64454138 invoked from network); 2 Feb 2001 19:13:13 -0000 Received: from mail-gateway.webhotel.net (195.41.202.215) by mail.webhotel.net with SMTP; 2 Feb 2001 19:13:13 -0000 X-Authenticated-Timestamp: 20:13:13(CET) on February 02, 2001 Received: (from hroi@localhost) by chewbacca.netgroup.dk (8.11.1/8.9.3) id f12JAxJ83438; Fri, 2 Feb 2001 20:10:59 +0100 (CET) (envelope-from hroi) Date: Fri, 2 Feb 2001 20:10:59 +0100 From: Hroi Sigurdsson To: "Thomas T. Veldhouse" Cc: freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bridge and IPFW woes ... Message-ID: <20010202201059.A48414@chewbacca.netgroup.dk> References: <006801c08d39$6974f9e0$3028680a@tgt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006801c08d39$6974f9e0$3028680a@tgt.com>; from veldy@veldy.net on Fri, Feb 02, 2001 at 10:58:48AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Feb 02, 2001 at 10:58:48AM -0600, Thomas T. Veldhouse wrote: > If I change the bridging code over to NETGRAPH - this scenario does not > happen. All communication works just fine between all the hosts and the > Internet, however, all firewall rules that would apply to Host B and C seem > to quit working. In other words - all the hosts, except for Host A, are > left completely unprotected. I have tried using IPFILTER with both the in > kernel bridging code and NETGRAPH and have come to the same conclusion. > There is no way to filter the bridged packets. Netgraph doesn't support ipfw. It is in the TODO and look at this from sys/netgraph/ng_bridge.c: /* Run packet through ipfw processing, if enabled */ if (priv->conf.ipfw[linkNum] && fw_enable && ip_fw_chk_ptr != NULL) { /* XXX not implemented yet */ } It would be really nice to have code in there instead of that comment or a seperate ipfw netgraph node altogether :-) I've been reading through some of the netgraph code and it is a beautiful thing to behold. -- Hroi Sigurdsson hroi@netgroup.dk Netgroup A/S http://www.netgroup.dk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 12:32: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5664E37B503 for ; Fri, 2 Feb 2001 12:31:44 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA57437; Fri, 2 Feb 2001 13:31:34 -0700 (MST) Date: Fri, 2 Feb 2001 13:31:29 -0700 (MST) From: Nick Rogness To: parminder.mudhar@bt.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels In-Reply-To: <71DA16F18D32D2119A1D0000F8FE9A9409D21C69@mbtlipnt01.btlabs.bt.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Feb 2001 parminder.mudhar@bt.com wrote: > Nick > > Thanks for taking the time to reply to query. Here is more information that > may help you. No problem. Comments below. Sorry for the late reply. [snip] > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > the_swamp# netstat -rnf inet > Routing tables Are you using gifconfig(8) to configure the outside header of the tunnel? I am running several tunnels using gif and have never had a problem yet. Also check your firewall. Here is an example of one of the tunnels: | | FreeBSD1 | | FreeBSD2 192.168.1.0/24 --- 1.1.1.1 -|- Internet -|- 2.2.2.2 --- 172.16.1.0/24 Gif Tunnel: 10.1.1.1 <--|------------|--> 10.1.1.2 | | | | //On FreeBSD1: # gifconfig gif0 inet 1.1.1.1 2.2.2.2 # ifconfig gif0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 # route add -net 172.16.1.0 10.1.1.2 -netmask 255.255.255.0 //On FreeBSD2 # gifconfig gif0 inet 2.2.2.2 1.1.1.1 # ifconfig gif0 10.1.1.2 10.1.1.1 netmask 255.255.255.252 # route add -net 192.168.1.0 10.1.1.1 -netmask 255.255.255.0 That should be all you need. Like I mentioned earlier, also make sure that your firewall is letting it through. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 13: 1:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 6BBF237B401; Fri, 2 Feb 2001 13:01:04 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id NAA73783; Fri, 2 Feb 2001 13:59:50 -0700 (MST) Date: Fri, 2 Feb 2001 13:59:50 -0700 (MST) From: Nick Rogness To: Julian Elischer Cc: Joao Carlos Mendes Luis , mi@aldan.algebra.com, questions@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: transparent proxying through a separate machine In-Reply-To: <3A7ACA03.BA4D3F31@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Julian Elischer wrote: > Joao Carlos Mendes Luis wrote: > > > > ipfw add allow ip from any to any out > > the probele is the line above. > > > > ipfw add fwd localhost,3128 log tcp from any to any 3128 in > > the above shoudl be 'out'.. FWD is not symetrical.. > you can only fwd locally on 'in' and fwd remotly on 'out'. It says this in the > man page but it's a bit hard to read. I should fix it.. After playing with fwd for a while, I re-read the ipfw man page and picked up that it only applies to packets leaving the system. However, when I was testing this I had fwd setup on incoming packets and added the 'log' keyword so I could see what was going on. It did report via syslog that packets were being forwarded to the address even though they weren't. That was the confusing part. A little rewording on the man page would help. Thanks for the clarification. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 13:24:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from virtual2.sysadmin-inc.com (unknown [209.16.228.145]) by hub.freebsd.org (Postfix) with SMTP id B002637B401 for ; Fri, 2 Feb 2001 13:24:16 -0800 (PST) Received: (qmail 4356 invoked by alias); 2 Feb 2001 21:24:15 -0000 Received: from unknown (HELO wkst) (10.10.1.70) by ssl.sysadmin-inc.com with SMTP; 2 Feb 2001 21:24:15 -0000 Reply-To: From: "Peter Brezny" To: Subject: ipfw not allowing dns traffic Date: Fri, 2 Feb 2001 16:23:22 -0500 Message-ID: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I thought I had everything. # Allow DNS traffic from internet to query your DNS (for reverse # lookups etc). $fwcmd add allow tcp from any 53 to $ns1 53 setup $fwcmd add allow udp from any 53 to $ns1 53 $fwcmd add allow udp from $ns1 53 to any 53 but nslookup's fail from outside the firewall on another machine in nslookup with server set to my firewall machine. What have i missed? Peter Brezny SysAdmin Services Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 13:27:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapier.smartspace.co.za (rapier.smartspace.co.za [66.8.25.34]) by hub.freebsd.org (Postfix) with SMTP id E96E337B67D for ; Fri, 2 Feb 2001 13:27:03 -0800 (PST) Received: (qmail 29800 invoked by uid 1001); 2 Feb 2001 21:26:48 -0000 Date: Fri, 2 Feb 2001 23:26:48 +0200 From: Neil Blakey-Milner To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: ipfw not allowing dns traffic Message-ID: <20010202232648.A29699@rapier.smartspace.co.za> References: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com>; from peter@sysadmin-inc.com on Fri, Feb 02, 2001 at 04:23:22PM -0500 Organization: Building Intelligence X-Operating-System: FreeBSD 4.2-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri 2001-02-02 (16:23), Peter Brezny wrote: > I thought I had everything. > > # Allow DNS traffic from internet to query your DNS (for reverse > # lookups etc). > $fwcmd add allow tcp from any 53 to $ns1 53 setup > $fwcmd add allow udp from any 53 to $ns1 53 > $fwcmd add allow udp from $ns1 53 to any 53 > > but nslookup's fail from outside the firewall on another machine in nslookup > with server set to my firewall machine. > > What have i missed? Not all requests will originate from port 53. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 13:29:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 4572B37B401 for ; Fri, 2 Feb 2001 13:29:27 -0800 (PST) Received: (qmail 5285 invoked by uid 1000); 2 Feb 2001 21:29:26 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Feb 2001 21:29:26 -0000 Date: Fri, 2 Feb 2001 15:29:26 -0600 (CST) From: Mike Silbersack To: Peter Brezny Cc: Subject: Re: ipfw not allowing dns traffic In-Reply-To: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Peter Brezny wrote: > I thought I had everything. > > # Allow DNS traffic from internet to query your DNS (for reverse > # lookups etc). > $fwcmd add allow tcp from any 53 to $ns1 53 setup > $fwcmd add allow udp from any 53 to $ns1 53 > $fwcmd add allow udp from $ns1 53 to any 53 > > but nslookup's fail from outside the firewall on another machine in nslookup > with server set to my firewall machine. > > What have i missed? > > Peter Brezny > SysAdmin Services Inc. Use dig. nslookup does superfluous lookups which will display false failures in many cases. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 14:51:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b044.neo.lrun.com [24.93.181.44]) by hub.freebsd.org (Postfix) with ESMTP id 70CEB37B699 for ; Fri, 2 Feb 2001 14:51:15 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id f12Mf6i25074 for ; Fri, 2 Feb 2001 17:41:06 -0500 Date: Fri, 2 Feb 2001 17:41:06 -0500 (EST) From: Mike Nowlin To: freebsd-net@freebsd.org Subject: PPP - CHAP failure after CHAP success??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On a recently cvsup'd machine (4.2-S as of two days ago), incoming PPP w/CHAP via RADIUS has suddenly broken. Basically, RADIUS OK's the connection, addr info is transferred & approved, everything looks normal, until after the log line listing myaddr and hisaddr - why is it doing CHAP again, and what happened to my RADIUS server? README.changes diffs only mentioned MSCHAPv2 and MPPE changes - disabled both of those, but it doesn't make any difference. --mike Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: bundle: Authenticate Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: deflink: his = none, mine = CHAP 0x05 Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: Chap Output: CHALLENGE Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Input: RESPONSE (16 bytes from argos) Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: Request sent Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: ACCEPT received Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: MTU 1500 Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: VJ enabled Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: IP 10.99.1.6 Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Netmask 255.255.255.252 Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: SUCCESS Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot determine ethernet address for proxy ARP Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: lcp -> open Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: bundle: Network Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: FSM: Using "deflink" as a transport Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Initial --> Closed Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerStart. Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: SendConfigReq(1) state = Closed Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.129.1.2 Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Closed --> Req-Sent Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: RecvConfigReq(3) state = Req-Sent Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: SendConfigAck(3) state = Req-Sent Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Req-Sent --> Ack-Sent Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: RecvConfigAck(1) state = Ack-Sent Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Ack-Sent --> Opened Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerUp. Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: myaddr 10.129.1.2 hisaddr = 10.99.1.6 Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot determine ethernet address for proxy ARP ...new stuff starts here - these lines never showed up before..... Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: radius: No RADIUS servers specified Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: FAILURE Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: open -> lcp Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerDown Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: SendTerminateReq(3) state = Opened Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Opened --> Closing Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: RecvTerminateReq(4) state = Closing Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: SendTerminateAck(4) state = Closing Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: RecvTerminateAck(3) state = Closing Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerFinish Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closing --> Closed Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closed --> Initial Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: deflink: Unable to set physical to speed 0 Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: Disconnected! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 15: 1:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id B166437B401 for ; Fri, 2 Feb 2001 15:01:25 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id QAA48741; Fri, 2 Feb 2001 16:01:23 -0700 (MST) Date: Fri, 2 Feb 2001 16:01:23 -0700 (MST) From: Nick Rogness To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: ipfw not allowing dns traffic In-Reply-To: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Peter Brezny wrote: > I thought I had everything. > > # Allow DNS traffic from internet to query your DNS (for reverse > # lookups etc). > $fwcmd add allow tcp from any 53 to $ns1 53 setup > $fwcmd add allow udp from any 53 to $ns1 53 > $fwcmd add allow udp from $ns1 53 to any 53 > > but nslookup's fail from outside the firewall on another machine in nslookup > with server set to my firewall machine. > > What have i missed? ipfw add 500 allow udp from any to $ns1 53 in via $outside_int ipfw add 501 allow udp from $ns1 53 to any out via $outside_int DNS (source port) requests will not necessarily run on port 53. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 15:22:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 7F36D37B401 for ; Fri, 2 Feb 2001 15:21:56 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f12NM7v22833; Fri, 2 Feb 2001 23:22:07 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f12NNW606872; Fri, 2 Feb 2001 23:23:32 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102022323.f12NNW606872@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Nowlin Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: Message from Mike Nowlin of "Fri, 02 Feb 2001 17:41:06 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 2001 23:23:32 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm, I can't see how this can happen without any previous log lines saying that a chap packet has been received. If this is repeatable, can you try doing a ``show timer'' right after the SUCCESS response has been sent ? If the radius timer wasn't cleared properly this might result, but I can't see how that could happen... > On a recently cvsup'd machine (4.2-S as of two days ago), incoming PPP > w/CHAP via RADIUS has suddenly broken. Basically, RADIUS OK's the > connection, addr info is transferred & approved, everything looks normal, > until after the log line listing myaddr and hisaddr - why is it doing > CHAP again, and what happened to my RADIUS server? README.changes diffs > only mentioned MSCHAPv2 and MPPE changes - disabled both of those, but it > doesn't make any difference. > > --mike > > > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: bundle: Authenticate > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: deflink: his = none, mine = > CHAP 0x05 > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: Chap Output: CHALLENGE > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Input: RESPONSE (16 > bytes from argos) > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: Request sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: ACCEPT received > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: MTU 1500 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: VJ enabled > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: IP 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Netmask > 255.255.255.252 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: SUCCESS > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot > determine ethernet address for proxy ARP > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: lcp -> open > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: bundle: Network > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: FSM: Using "deflink" as a > transport > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Initial > --> Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerStart. > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: SendConfigReq(1) state = Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.129.1.2 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Closed > --> Req-Sent > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: RecvConfigReq(3) state = Req-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: SendConfigAck(3) state = Req-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change > Req-Sent --> Ack-Sent > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: RecvConfigAck(1) state = Ack-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change > Ack-Sent --> Opened > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerUp. > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: myaddr 10.129.1.2 hisaddr = > 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot > determine ethernet address for proxy ARP > > ...new stuff starts here - these lines never showed up before..... > > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: radius: No RADIUS servers > specified > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: FAILURE > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: open -> lcp > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerDown > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: SendTerminateReq(3) state = Opened > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Opened > --> Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: RecvTerminateReq(4) state = Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: SendTerminateAck(4) state = Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: RecvTerminateAck(3) state = Closing > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerFinish > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closing > --> Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closed > --> Initial > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: deflink: Unable to set > physical to speed 0 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: Disconnected! -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 15:47:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from lysimachus.hosting.pacbell.net (lysimachus.hosting.pacbell.net [216.100.98.17]) by hub.freebsd.org (Postfix) with ESMTP id 25D4437B491 for ; Fri, 2 Feb 2001 15:47:25 -0800 (PST) Received: from contractor4 (dnai-216-15-10-194.cust.dnai.com [216.15.10.194]) by lysimachus.hosting.pacbell.net id SAA16320; Fri, 2 Feb 2001 18:47:24 -0500 (EST) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Mark Carlile" To: Subject: FW: VPN question Date: Fri, 2 Feb 2001 15:49:04 -0800 Message-ID: <000001c08d72$b9ec6780$b101a8c0@contractor4> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Any thoughts on my questions below. If it is possible, where can I find information to implement it. Thanks Mark Carlile interKeel, Inc. 3977 E. Bayshore Rd., Suite 100 Palo Alto, CA 94303 mailto:mcarlile@interkeel.com -----Original Message----- From: Justin T. Gibbs [mailto:gibbs@scsiguy.com] Sent: Friday, February 02, 2001 11:19 AM To: mcarlile@interkeel.com Subject: Re: VPN question >Justin, . Hi Mark. Good to hear from you! >I have a question about FreeBSD and I'm hoping you >can steer me in the right direction. We currently have a BSD box that is >acting as our firewall with a NT domain behind it. We want to set up VPN >solution where a client (running NT or Win2K) can access the internal NT >server through the BSD firewall via the Internet. In other words the want >to work from home and access the NT server that sits behind the firewall. > >Can this be done. If so, what software would need to run on the client. >Any direction you could give would be appreciated. FreeBSD 4.2R and above does support IPSec. I know that individuals have used this to implement VPNs between FreeBSD systems. I don't know if there is software available to interoperate with an NT system. Probably the best place to ask about this is freebsd-net@FreeBSD.org. Good Luck! -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 16: 9:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn211.dh.casema.net [212.64.31.211]) by hub.freebsd.org (Postfix) with ESMTP id BC0E737B4EC for ; Fri, 2 Feb 2001 16:08:58 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f130V1b74319; Sat, 3 Feb 2001 01:31:01 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010202204205.00d36900@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Feb 2001 20:46:13 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: bandwidth analyser Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <3A7ACD4B.155B2657@elischer.org> References: <200101292359.f0TNxOU48488@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:07 2-2-01 -0800, you wrote: >Luigi Rizzo wrote: > > > > > There's one downside though. You can get statistics from the bridge > node on > > > packets and octects passed through the different parts of the bridge > > > setyup, but it's not IP based. Also using that bridging code there's no > > > bandwidth throttling or IPFW rule matching yet. > > > > > > Vitaly Belekhov wrote BW throttling and ipfw netgraph nodes for 3.X, > and I > > > will be porting those to 5.X-CURRENT over the next few weeks. > > >The new ethernet node netgrpah interface (with 'upper' and 'lower') >may influence this. >also the ipfw he used is very old now. True, there's no immediate need to use his eiface node, but I see a use for a new ethernet interface. Especially when I'm done with my 802.1Q vlan trunking node (I'm calling it vlanmux. Anyone have a better name?) I still have to look at his ipfw code. I just might take his idea and implement it again using newer IPFW code. I've just been making 12 hour days at work, and my win98 box (I only have one good monitor and I like to play games) keeps locking up for a second every few seconds, so it's hard for me to read mail even. I expect to be back on netgraph coding somewhere the coming week you'll hear more from me on this. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 16:20:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn211.dh.casema.net [212.64.31.211]) by hub.freebsd.org (Postfix) with ESMTP id 2E48937B4EC; Fri, 2 Feb 2001 16:20:29 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f130h2b74340; Sat, 3 Feb 2001 01:43:03 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Feb 2001 20:55:37 +0100 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org From: "Rogier R. Mulhuijzen" Subject: Patch for non-netgraph bridge code worthy of attention for people experimenting with bridging setups (including ng_bridge) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I found this while experimenting with both "legacy" bridge and ng_bridge. The bridging code doesn't check its activation everywhere so when I started using an ng_bridge node I started getting weird errors. Patch is rather simple, can someone submit this? DocWilco >Date: Mon, 29 Jan 2001 08:20:01 -0800 (PST) >To: drwilco@drwilco.net >From: gnats-admin@FreeBSD.org >Subject: Re: kern/24720: Bridging code does not always check activation >(w/patch) >Reply-To: gnats-admin@FreeBSD.org, freebsd-bugs@FreeBSD.org >Sender: gnats@FreeBSD.org > >Thank you very much for your problem report. >It has the internal identification `kern/24720'. >The individual assigned to look at your >report is: freebsd-bugs. > >You can access the state of your problem report at any time >via this link: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=24720 > > >Category: kern > >Responsible: freebsd-bugs > >Synopsis: Bridging code does not always check activation (w/patch) > >Arrival-Date: Mon Jan 29 08:20:01 PST 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 19:26:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from bear.mshindo.net (bear.mshindo.net [202.229.42.121]) by hub.freebsd.org (Postfix) with ESMTP id 091F937B401 for ; Fri, 2 Feb 2001 19:25:52 -0800 (PST) Received: from localhost (IDENT:mshindo@E139210.ppp.dion.ne.jp [210.238.139.210]) by bear.mshindo.net (8.11.1/8.11.1) with ESMTP id f133OSn42765; Sat, 3 Feb 2001 12:24:28 +0900 (JST) (envelope-from mshindo@mshindo.net) Date: Sat, 03 Feb 2001 12:26:41 +0900 (JST) Message-Id: <20010203.122641.74755745.mshindo@mshindo.net> To: mcarlile@interkeel.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: VPN question From: Motonori Shindo In-Reply-To: <000001c08d72$b9ec6780$b101a8c0@contractor4> References: <000001c08d72$b9ec6780$b101a8c0@contractor4> X-Mailer: Mew version 1.95b76 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark, There are two that I know of; one is PPTP implementation and another is L2TP implementation. There is a ports/packages for PPTP called 'pptpclient'. You many need to modify pppd a little bit, depending on how the peering Windows is configured. L2TP implemantation is availabe via an anonymous CVS (password is anoncvs) :pserver:anoncvs@marko.net:/usr/share/cvsroot Regards, From: "Mark Carlile" Subject: FW: VPN question Date: Fri, 2 Feb 2001 15:49:04 -0800 Message-ID: <000001c08d72$b9ec6780$b101a8c0@contractor4> > Any thoughts on my questions below. If it is possible, where can I find > information to implement it. > > Thanks > > Mark Carlile > interKeel, Inc. > 3977 E. Bayshore Rd., Suite 100 > Palo Alto, CA 94303 > mailto:mcarlile@interkeel.com > > -----Original Message----- > From: Justin T. Gibbs [mailto:gibbs@scsiguy.com] > Sent: Friday, February 02, 2001 11:19 AM > To: mcarlile@interkeel.com > Subject: Re: VPN question > > >Justin, > . > > Hi Mark. Good to hear from you! > >I have a question about FreeBSD and I'm hoping you > >can steer me in the right direction. We currently have a BSD box that is > >acting as our firewall with a NT domain behind it. We want to set up VPN > >solution where a client (running NT or Win2K) can access the internal NT > >server through the BSD firewall via the Internet. In other words the want > >to work from home and access the NT server that sits behind the firewall. > > > >Can this be done. If so, what software would need to run on the client. > >Any direction you could give would be appreciated. > > FreeBSD 4.2R and above does support IPSec. I know that individuals have > used this to implement VPNs between FreeBSD systems. I don't know if there > is software available to interoperate with an NT system. Probably the best > place to ask about this is freebsd-net@FreeBSD.org. > Good Luck! > > -- > Justin > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 20:24:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 50D4337B491 for ; Fri, 2 Feb 2001 20:24:15 -0800 (PST) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.11.2/8.11.1/2000-12-01) with ESMTP id f134OCn99262 for ; Sat, 3 Feb 2001 13:24:13 +0900 (JST) (envelope-from ishizuka@ish.org) To: freebsd-net@FreeBSD.ORG Subject: Re: packet loss when 'ipfw pipe list' with dummynet and bridge In-Reply-To: <200102021415.f12EFBs70349@iguana.aciri.org> References: <20010202191214B.ishizuka@onion.ish.org> <200102021415.f12EFBs70349@iguana.aciri.org> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010203132412V.ishizuka@onion.ish.org> Date: Sat, 03 Feb 2001 13:24:12 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 20000414(IM141) Lines: 23 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> When I typed 'ipfw pipe list', packet loss occur. > > unfortunately the "pipe list" has to navigate through a list of > pipe/flow/queue descriptors to report its output, and at the moment > it does this with interrupts disabled to avoid that the data > structure changes while it is working. > > A better approach would probably be to set a semaphore before > starting, and release it at the end, and keep interrupts enabled > during the transfer but make sure that no object is created or > deleted and no pointer is changed during the process. You can > still risk loss (when e.g. you cannot create a new flow descriptor) > but better than the current method. Dear, luigi-san. Thank you for mail. As I set "net.inet.ip.dummynet.expire=0", if it will affect only to ip addresses founded newly when a semaphore is introduced, I'll be happy. -- ishizuka@ish.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 20:56:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from unity.copyleft.no (unity.copyleft.no [212.71.72.23]) by hub.freebsd.org (Postfix) with ESMTP id 465AB37B401 for ; Fri, 2 Feb 2001 20:56:41 -0800 (PST) Received: from martin by unity.copyleft.no with local (Exim 3.12 #1) id 14OukX-0005pH-00; Sat, 03 Feb 2001 05:56:37 +0100 Date: Sat, 3 Feb 2001 05:56:37 +0100 From: Martin Eggen To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: kernel arp messages with 2 nics, sysctl cntrl? Message-ID: <20010203055637.A22365@unity.copyleft.no> References: <000401c08d21$5ed61720$46010a0a@sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000401c08d21$5ed61720$46010a0a@sysadmininc.com>; from peter@sysadmin-inc.com on Fri, Feb 02, 2001 at 09:06:42AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Peter Brezny] > I thought I rememberd someone mentioning a sysctl control for turning off > the kernel arp messages when you have two nics on the same (misconfigured) > network, but I couldn't find it in the archives. > > Anyone know? # sysctl -w net.link.ether.inet.log_arp_wrong_iface=0 -- Martin Eggen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 21:12:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from unity.copyleft.no (unity.copyleft.no [212.71.72.23]) by hub.freebsd.org (Postfix) with ESMTP id B604037B491 for ; Fri, 2 Feb 2001 21:12:24 -0800 (PST) Received: from martin by unity.copyleft.no with local (Exim 3.12 #1) id 14Ouzl-0005qx-00; Sat, 03 Feb 2001 06:12:21 +0100 Date: Sat, 3 Feb 2001 06:12:21 +0100 From: Martin Eggen To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: ipfw not allowing dns traffic Message-ID: <20010203061221.B22365@unity.copyleft.no> References: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000801c08d5e$5f4259c0$46010a0a@sysadmininc.com>; from peter@sysadmin-inc.com on Fri, Feb 02, 2001 at 04:23:22PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Peter Brezny] > I thought I had everything. > > # Allow DNS traffic from internet to query your DNS (for reverse > # lookups etc). > $fwcmd add allow tcp from any 53 to $ns1 53 setup > $fwcmd add allow udp from any 53 to $ns1 53 > $fwcmd add allow udp from $ns1 53 to any 53 > > but nslookup's fail from outside the firewall on another machine in nslookup > with server set to my firewall machine. > > What have i missed? Your nslookup queries may not originate from port 53. (In fact, as they are non-root processes, they use ephemeral ports high above 1023). -- Martin Eggen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 22:56:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b044.neo.rr.com [24.93.181.44]) by hub.freebsd.org (Postfix) with ESMTP id 7DAD337B65D for ; Fri, 2 Feb 2001 22:55:50 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id f136jZc32290; Sat, 3 Feb 2001 01:45:36 -0500 Date: Sat, 3 Feb 2001 01:45:35 -0500 (EST) From: Mike Nowlin To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: <200102022323.f12NNW606872@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I can't see how this can happen without any previous log lines saying > that a chap packet has been received. > > If this is repeatable, can you try doing a ``show timer'' right after > the SUCCESS response has been sent ? If the radius timer wasn't > cleared properly this might result, but I can't see how that could > happen... Hmm... Repeatable every time on the machine in question. (Time passes while I configure the a similar on a completely different set of boxes.) Yup - repeatable on another machine as well. Two machines - core-1 and twikki. Twikki is receiving the call. I don't have the muscle trigger upgrade in my finger yet to be able to hit return right when the SUCCESS rsp comes through (goes by way too fast), but I did turn on timer debugging for these logs -- maybe it'll help. If there's some way to trigger a "show timer" in the source at a certain point, I'd be happy to try that... Thanks - Mike Feb 3 01:37:39 twikki ppp[77098]: Phase: Using interface: tun3 Feb 3 01:37:39 twikki ppp[77098]: Phase: deflink: Created in closed sta te Feb 3 01:37:39 twikki ppp[77098]: tun3: Phase: PPP Started (direct mode ). Feb 3 01:37:39 twikki ppp[77098]: tun3: Phase: bundle: Establish Feb 3 01:37:39 twikki ppp[77098]: tun3: Phase: deflink: closed -> openi ng Feb 3 01:37:40 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting p hysical throughput timer[0x80ad068] Feb 3 01:37:40 twikki ppp[77098]: tun3: Phase: deflink: Connected! Feb 3 01:37:40 twikki ppp[77098]: tun3: Phase: deflink: opening -> carr ier Feb 3 01:37:40 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting t ty CD timer[0x80b1340] before physical throughput timer[0x80ad068], delt a = 10 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: Select returns -1 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: ---- Begin of Timer Serv ice List--- Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: tty CD timer[0x80b1340]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: physical throughput time r[0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: ---- End of Timer Servic e List --- Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting p hysical throughput timer[0x80ad068] Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting t ty CD timer[0x80b1340] before physical throughput timer[0x80ad068], delt a = 10 Feb 3 01:37:41 twikki ppp[77098]: tun3: Phase: deflink: /dev/cuac04: CD detected Feb 3 01:37:41 twikki ppp[77098]: tun3: Phase: deflink: carrier -> lcp Feb 3 01:37:41 twikki ppp[77098]: tun3: LCP: FSM: Using "deflink" as a transport Feb 3 01:37:41 twikki ppp[77098]: tun3: LCP: deflink: State change Init ial --> Closed Feb 3 01:37:41 twikki ppp[77098]: tun3: LCP: deflink: State change Clos ed --> Stopped Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting L CP openmode timer[0x80ad15c] before tty CD timer[0x80b1340], delta = 10 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:41 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns -1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: ---- Begin of Timer Serv ice List--- Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: LCP openmode timer[0x80a d15c]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: tty CD timer[0x80b1340]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: physical throughput time r[0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: ---- End of Timer Servic e List --- Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting p hysical throughput timer[0x80ad068] Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting t ty CD timer[0x80b1340] before physical throughput timer[0x80ad068], delt a = 10 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: LayerStart Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: SendConfigReq(1) state = Stopped Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACFCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: PROTOCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACCMAP[6] 0x00000000 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MRU[4] 1500 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MAGICNUM[6] 0x9b5bae81 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting L CP restart timer[0x80ad13c] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: State change Stop ped --> Req-Sent Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: RecvConfigAck(1) state = Req-Sent Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: State change Req- Sent --> Ack-Rcvd Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: RecvConfigReq(1) state = Ack-Rcvd Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACFCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: PROTOCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACCMAP[6] 0x00000000 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MRU[4] 1500 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MAGICNUM[6] 0x94cc8313 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: SendConfigAck(1) state = Ack-Rcvd Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACFCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: PROTOCOMP[2] Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: ACCMAP[6] 0x00000000 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MRU[4] 1500 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: MAGICNUM[6] 0x94cc8313 Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: State change Ack- Rcvd --> Opened Feb 3 01:37:42 twikki ppp[77098]: tun3: LCP: deflink: LayerUp Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting h dlc timer[0x80afd84] Feb 3 01:37:42 twikki ppp[77098]: tun3: Phase: bundle: Authenticate Feb 3 01:37:42 twikki ppp[77098]: tun3: Phase: deflink: his = none, min e = CHAP 0x05 Feb 3 01:37:42 twikki ppp[77098]: tun3: Phase: Chap Output: CHALLENGE Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting a uth timer[0x80ac034] before hdlc timer[0x80afd84], delta = 29 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:42 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns -1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: ---- Begin of Timer Serv ice List--- Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tty CD timer[0x80b1340]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: physical throughput time r[0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: auth timer[0x80ac034]: f req = 3.00s, next = 2.90s, state = running Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: hdlc timer[0x80afd84]: f req = 60.00s, next = 59.90s, state = running Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: ---- End of Timer Servic e List --- Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting p hysical throughput timer[0x80ad068] before auth timer[0x80ac034], delta = 10 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting t ty CD timer[0x80b1340] before physical throughput timer[0x80ad068], delt a = 10 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Chap Input: RESPONSE (16 bytes from theo) Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Radius: Request sent Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting r adius timer[0x80a43b4] before hdlc timer[0x80afd84], delta = 21 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Radius: fdset(r) 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Radius: ACCEPT received Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: IP 10.96.9.98 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Netmask 255.255. 255.255 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: MTU 1500 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: VJ enabled Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Chap Output: SUCCESS Feb 3 01:37:43 twikki ppp[77098]: tun3: Warning: 10.96.9.98: Cannot det ermine ethernet address for proxy ARP Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting C CP restart timer[0x80adc14] before hdlc timer[0x80afd84], delta = 21 Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: deflink: lcp -> open Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: bundle: Network Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: FSM: Using "deflink" as a transport Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: State change Ini tial --> Closed Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: LayerStart. Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting I PCP throughput timer[0x80a1d98] before CCP restart timer[0x80adc14], del ta = 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: SendConfigReq(1) state = Closed Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: IPADDR[6] 216.233.245.1 02 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: COMPPROTO[6] 16 VJ slot s with slot compression Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting I PCP restart timer[0x8090ae8] before CCP restart timer[0x80adc14], delta = 20 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: State change Clo sed --> Req-Sent Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting i dle timer[0x80a4350] Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 2 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 2 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: IPADDR[6] 0.0.0.0 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: COMPPROTO[6] 16 VJ slot s with slot compression Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: SendConfigNak(1) state = Req-Sent Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: IPADDR[6] 10.96.9.98 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting C CP restart timer[0x80adc14] before hdlc timer[0x80afd84], delta = 2 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: RecvConfigAck(1) state = Req-Sent Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: State change Req -Sent --> Ack-Rcvd Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: RecvConfigReq(2) state = Ack-Rcvd Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: IPADDR[6] 10.96.9.98 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: COMPPROTO[6] 16 VJ slot s with slot compression Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: SendConfigAck(2) state = Ack-Rcvd Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: IPADDR[6] 10.96.9.98 Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: COMPPROTO[6] 16 VJ slot s with slot compression Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: State change Ack -Rcvd --> Opened Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: deflink: LayerUp. Feb 3 01:37:43 twikki ppp[77098]: tun3: IPCP: myaddr 216.233.245.102 hi saddr = 10.96.9.98 Feb 3 01:37:43 twikki ppp[77098]: tun3: Warning: 10.96.9.98: Cannot det ermine ethernet address for proxy ARP Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: radius: No RADIUS server s specified Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: Chap Output: FAILURE Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: deflink: open -> lcp Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: LayerDown Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: SendTerminateReq( 2) state = Opened Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting L CP restart timer[0x80ad13c] before idle timer[0x80a4350], delta = 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: State change Open ed --> Closing Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: timer_Start: Inserting i dle timer[0x80a4350] Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 2 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: RecvTerminateReq( 2) state = Closing Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: SendTerminateAck( 2) state = Closing Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(w) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: tun: fdset(r) 3 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(r) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: deflink: fdset(e) 0 Feb 3 01:37:43 twikki ppp[77098]: tun3: Timer: Select returns 1 Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: RecvTerminateAck( 2) state = Closing Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: LayerFinish Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: State change Clos ing --> Closed Feb 3 01:37:43 twikki ppp[77098]: tun3: LCP: deflink: State change Clos ed --> Initial Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: deflink: Disconnected! Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: deflink: Connect time: 3 secs: 354 octets in, 338 octets out Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: deflink: : 22 packets in , 14 packets out Feb 3 01:37:43 twikki ppp[77098]: tun3: Phase: total 230 bytes/sec, pe ak 75 bytes/sec on Sat Feb 3 01:37:43 2001 Feb 3 01:37:34 core-1 ppp[8605]: Phase: Using interface: tun2 Feb 3 01:37:34 core-1 ppp[8605]: Phase: deflink: Created in closed stat e Feb 3 01:37:34 core-1 ppp[8605]: tun2: Phase: PPP Started (interactive mode). Feb 3 01:37:34 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Phase: bundle: Establish Feb 3 01:37:35 core-1 ppp[8605]: tun2: Phase: deflink: closed -> openin g Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] Feb 3 01:37:35 core-1 ppp[8605]: tun2: Phase: deflink: Connected! Feb 3 01:37:35 core-1 ppp[8605]: tun2: Phase: deflink: opening -> dial Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Phone: 330-315-6459 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: deflink: Dial attempt 1 of 1 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Send: ATE1Q0^M Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Expect(5): OK Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ch at timeout timer[0x80aaab4] Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Received: ATE1Q0^M^M Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Received: OK^M Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ch at pause timer[0x80aaa94] Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:37:35 core-1 ppp[8605]: tun2: Chat: Send: ATDT330-315-6459^M Feb 3 01:37:35 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: chat pause timer[0x80aaa9 4]: freq = 2.00s, next = 1.00s, state = running Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat pause timer[0x80aaa94], d elta = 10 Feb 3 01:37:36 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: chat pause timer[0x80aaa9 4]: freq = 2.00s, next = 0.00s, state = running Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] Feb 3 01:37:37 core-1 ppp[8605]: tun2: Chat: Expect(40): CONNECT Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ch at timeout timer[0x80aaab4] Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:37 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 39.00s, state = running Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:38 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 38.00s, state = running Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:39 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 37.00s, state = running Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:40 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 36.00s, state = running Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:41 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 35.00s, state = running Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:42 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 34.00s, state = running Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:43 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 33.00s, state = running Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:44 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 32.00s, state = running Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:45 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 31.00s, state = running Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:46 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 30.00s, state = running Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:47 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 29.00s, state = running Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:48 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 28.00s, state = running Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:49 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 27.00s, state = running Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:50 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 26.00s, state = running Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:51 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 25.00s, state = running Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:52 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 24.00s, state = running Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:53 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 23.00s, state = running Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:54 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 22.00s, state = running Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:55 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 21.00s, state = running Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:56 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 20.00s, state = running Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:57 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 19.00s, state = running Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:58 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 18.00s, state = running Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:37:59 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 17.00s, state = running Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:00 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 16.00s, state = running Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:01 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 15.00s, state = running Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:02 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 14.00s, state = running Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:03 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 13.00s, state = running Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:04 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 12.00s, state = running Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:05 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: chat timeout timer[0x80aa ab4]: freq = 40.00s, next = 11.00s, state = running Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before chat timeout timer[0x80aaab4], delta = 10 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:06 core-1 ppp[8605]: tun2: Chat: Received: ATDT330-315-6459 ^M^M Feb 3 01:38:06 core-1 ppp[8605]: tun2: Chat: Received: CONNECT 28800 V4 2bis^M Feb 3 01:38:06 core-1 ppp[8605]: tun2: Phase: deflink: dial -> carrier Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] Feb 3 01:38:06 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: tty CD timer[0x80a4140]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] Feb 3 01:38:07 core-1 ppp[8605]: tun2: Phase: deflink: /dev/cuaR3: CD d etected Feb 3 01:38:07 core-1 ppp[8605]: tun2: Phase: deflink: carrier -> login Feb 3 01:38:07 core-1 ppp[8605]: tun2: Phase: deflink: login -> lcp Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting LC P openmode timer[0x80ad15c] before tty CD timer[0x80a4140], delta = 3 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:07 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: LCP openmode timer[0x80ad 15c]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: tty CD timer[0x80a4140]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting LC P restart timer[0x80ad13c] Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:08 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: tty CD timer[0x80a4140]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: LCP restart timer[0x80ad1 3c]: freq = 3.00s, next = 2.30s, state = running Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before LCP restart timer[0x80ad13c], delta = 7 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] before LCP restart timer[0x80ad13c], delta = 3 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:09 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: tty CD timer[0x80a4140]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: LCP restart timer[0x80ad1 3c]: freq = 3.00s, next = 1.30s, state = running Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] before LCP restart timer[0x80ad13c], delta = 7 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] before LCP restart timer[0x80ad13c], delta = 3 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:10 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: ---- Begin of Timer Servi ce List--- Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: physical throughput timer [0x80ad068]: freq = 1.00s, next = 0.00s, state = running Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: tty CD timer[0x80a4140]: freq = 1.00s, next = 0.30s, state = running Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: LCP restart timer[0x80ad1 3c]: freq = 3.00s, next = 0.30s, state = running Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: ---- End of Timer Service List --- Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting ph ysical throughput timer[0x80ad068] Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns -1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting LC P restart timer[0x80ad13c] Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting LC P restart timer[0x80ad13c] Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting tt y CD timer[0x80a4140] before LCP restart timer[0x80ad13c], delta = 3 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:11 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting hd lc timer[0x80afd7c] Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: bundle: Authenticate Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: deflink: his = CHAP 0x05, mine = none Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: Chap Input: CHALLENGE (16 bytes) Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: Chap Output: RESPONSE (th eo) Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: Chap Input: SUCCESS (Welc ome!!) Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting CC P restart timer[0x80adc14] before hdlc timer[0x80afd7c], delta = 24 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: deflink: lcp -> open Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: bundle: Network Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: FSM: Using "deflink" as a transport Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: State change Init ial --> Closed Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: LayerStart. Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting IP CP throughput timer[0x809f654] before CCP restart timer[0x80adc14], delt a = 4 Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: SendConfigReq(1) state = Closed Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: IPADDR[6] 0.0.0.0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: timer_Start: Inserting IP CP restart timer[0x808e3a4] before CCP restart timer[0x80adc14], delta = 20 Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: State change Clos ed --> Req-Sent Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: IPADDR[6] 216.233.245.10 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: SendConfigAck(1) state = Req-Sent Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: IPADDR[6] 216.233.245.10 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Feb 3 01:38:12 core-1 ppp[8605]: tun2: IPCP: deflink: State change Req- Sent --> Ack-Sent Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: tun: fdset(r) 3 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: tun: fdset(r) 3 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: tun: fdset(r) 3 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: tun: fdset(r) 3 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(w) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: tun: fdset(r) 3 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(e) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: prompt /dev/tty: fdset(r) 0 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: Chap Input: FAILURE (Inva lid!!) Feb 3 01:38:12 core-1 ppp[8605]: tun2: Timer: deflink: fdset(r) 2 Feb 3 01:38:12 core-1 ppp[8605]: tun2: Phase: deflink: hangup -> closed Feb 3 01:38:21 core-1 ppp[8605]: tun2: Timer: Select returns 1 Feb 3 01:38:21 core-1 ppp[8605]: tun2: Phase: /dev/tty: Client connecti on closed. Feb 3 01:38:21 core-1 ppp[8605]: tun2: Phase: PPP Terminated (normal). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 23: 5:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 140F737B698 for ; Fri, 2 Feb 2001 23:05:08 -0800 (PST) Received: from elischer.org (reggae-08-177.nv.iinet.net.au [203.59.3.177]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id PAA26413; Sat, 3 Feb 2001 15:04:50 +0800 Message-ID: <3A7BAD76.8969D960@elischer.org> Date: Fri, 02 Feb 2001 23:04:22 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Motonori Shindo Cc: mcarlile@interkeel.com, freebsd-net@FreeBSD.ORG Subject: Re: VPN question References: <000001c08d72$b9ec6780$b101a8c0@contractor4> <20010203.122641.74755745.mshindo@mshindo.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Motonori Shindo wrote: > > Mark, > > There are two that I know of; one is PPTP implementation and another > is L2TP implementation. > > There is a ports/packages for PPTP called 'pptpclient'. You many need > to modify pppd a little bit, depending on how the peering Windows is > configured. mpd in ports/net has a full pptp implementation allowing mutiple pptp links concurrently and acting as both a server and a client. (on copy of mpd running can handle N sessions concurrently) > > L2TP implemantation is availabe via an anonymous CVS (password is > anoncvs) > > :pserver:anoncvs@marko.net:/usr/share/cvsroot > > Regards, > > From: "Mark Carlile" > Subject: FW: VPN question > Date: Fri, 2 Feb 2001 15:49:04 -0800 > Message-ID: <000001c08d72$b9ec6780$b101a8c0@contractor4> > > > Any thoughts on my questions below. If it is possible, where can I find > > information to implement it. > > > > Thanks > > > > Mark Carlile > > interKeel, Inc. > > 3977 E. Bayshore Rd., Suite 100 > > Palo Alto, CA 94303 > > mailto:mcarlile@interkeel.com > > > > -----Original Message----- > > From: Justin T. Gibbs [mailto:gibbs@scsiguy.com] > > Sent: Friday, February 02, 2001 11:19 AM > > To: mcarlile@interkeel.com > > Subject: Re: VPN question > > > > >Justin, > > . > > > > Hi Mark. Good to hear from you! > > >I have a question about FreeBSD and I'm hoping you > > >can steer me in the right direction. We currently have a BSD box that is > > >acting as our firewall with a NT domain behind it. We want to set up VPN > > >solution where a client (running NT or Win2K) can access the internal NT > > >server through the BSD firewall via the Internet. In other words the want > > >to work from home and access the NT server that sits behind the firewall. > > > > > >Can this be done. If so, what software would need to run on the client. > > >Any direction you could give would be appreciated. > > > > FreeBSD 4.2R and above does support IPSec. I know that individuals have > > used this to implement VPNs between FreeBSD systems. I don't know if there > > is software available to interoperate with an NT system. Probably the best > > place to ask about this is freebsd-net@FreeBSD.org. > > Good Luck! > > > > -- > > Justin > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > +----+----+ > |.. .| | Motonori Shindo > |_~__| | > | .. |~~_~| Sr. Systems Engineer > | . | | CoSine Communications Inc. > +----+----+ > C o S i n e e-mail: mshindo@cosinecom.com > Communications > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 2 23:12:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b044.neo.rr.com [24.93.181.44]) by hub.freebsd.org (Postfix) with ESMTP id DCC5D37B699 for ; Fri, 2 Feb 2001 23:12:41 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id f1372UY32518; Sat, 3 Feb 2001 02:02:30 -0500 Date: Sat, 3 Feb 2001 02:02:30 -0500 (EST) From: Mike Nowlin To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hmm... Repeatable every time on the machine in question. (Time passes > while I configure the a similar on a completely different set of > boxes.) Yup - repeatable on another machine as well. Apologies to everyone regarding the LONG response I just sent - I didn't realize that the log sections I chopped out were so big until after I sent the message.... mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 0:49:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 45EFC37B401 for ; Sat, 3 Feb 2001 00:48:47 -0800 (PST) Received: (qmail 27006 invoked by uid 666); 3 Feb 2001 08:55:48 -0000 Received: from reggae-08-177.nv.iinet.net.au (HELO elischer.org) (203.59.3.177) by mail.m.iinet.net.au with SMTP; 3 Feb 2001 08:55:48 -0000 Message-ID: <3A7BC5C4.75247E49@elischer.org> Date: Sat, 03 Feb 2001 00:48:04 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Patch for non-netgraph bridge code worthy of attention forpeople experimenting with bridging setups (including ng_bridge) References: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rogier R. Mulhuijzen" wrote: > > I found this while experimenting with both "legacy" bridge and ng_bridge. > The bridging code doesn't check its activation everywhere so when I started > using an ng_bridge node I started getting weird errors. > > Patch is rather simple, can someone submit this? I'm a litle confused when I look at this patch. I think this is the wrong fix. I see that you are accounting for packets coming in on two interfaces, but the aim of the netgraph bridging is to make it look as if the packets are all coming in off one interface. Theoretically the bridging code should be attached to only one 'upper' part of a driver and all packets should arrive at higher levels, looking as if they have all come in through that one interface. The other interfaces in the bridge will never receive anything because their input has been diverted. To the system it should look as if the entire bridged network is on that one interface. If this is not the case then we need to fix the bridging code so that it is true, rather than clutter up higher level code trying to account for a bug in the lower code. So how can an incoming packet look like it is not coming from that single interface? 1/ ifnet pointer. The function ng_ether_rcv_upper() adjust this, so that's not the problem. 2/ rcv interface MAC address. This is stripped off before arp gets it (also in ng_ether_rcv_upper()). 3/ the tha[] or sha[] fields may contain a MAC address for some other interface. (depending on how the remote mechine fills out those fields), but our outgoing packets should have the MAC address of the interface we have selected as out main interface, independent of which interface it actually goes out of, (unless the hardware over-writes it). so even that should point to the single interface. The other interfaces should (maybe) beb ifconfigged 'UP' but they should not have IP addresses assigned tp them, as they are being slaved from the main interface by the ng_bridging code so everything comes and goes via that one. so I'm slightly confused as to what problem this solves. (I'm not saying there isn't one, just that I con't figure out what it is). Everything should act as if there is just one interface when netgraph bridging is turned on. > > DocWilco > > >Date: Mon, 29 Jan 2001 08:20:01 -0800 (PST) > >To: drwilco@drwilco.net > >From: gnats-admin@FreeBSD.org > >Subject: Re: kern/24720: Bridging code does not always check activation > >(w/patch) > >Reply-To: gnats-admin@FreeBSD.org, freebsd-bugs@FreeBSD.org > >Sender: gnats@FreeBSD.org > > > >Thank you very much for your problem report. > >It has the internal identification `kern/24720'. > >The individual assigned to look at your > >report is: freebsd-bugs. > > > >You can access the state of your problem report at any time > >via this link: > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=24720 > > > > >Category: kern > > >Responsible: freebsd-bugs > > >Synopsis: Bridging code does not always check activation (w/patch) > > >Arrival-Date: Mon Jan 29 08:20:01 PST 2001 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 4:27:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn211.dh.casema.net [212.64.31.211]) by hub.freebsd.org (Postfix) with ESMTP id 7054B37B4EC; Sat, 3 Feb 2001 04:27:12 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f13Cnbb78302; Sat, 3 Feb 2001 13:49:38 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010203122412.00cd4b30@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Feb 2001 13:26:27 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: Patch for non-netgraph bridge code worthy of attention forpeople experimenting with bridging setups (including ng_bridge) Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <3A7BC5C4.75247E49@elischer.org> References: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 00:48 3-2-01 -0800, Julian Elischer wrote: >"Rogier R. Mulhuijzen" wrote: > > > > I found this while experimenting with both "legacy" bridge and ng_bridge. > > The bridging code doesn't check its activation everywhere so when I started > > using an ng_bridge node I started getting weird errors. > > > > Patch is rather simple, can someone submit this? > >I'm a litle confused when I look at this patch. > >I think this is the wrong fix. > >I see that you are accounting for packets coming in on two interfaces, >but the aim of the netgraph bridging is to make it look as if the >packets are all coming in off one interface. Theoretically the >bridging code should be attached to only one 'upper' part of a driver >and all packets should arrive at higher levels, looking as if they have >all come in through that one interface. The other interfaces in the bridge >will never receive anything because their input has been diverted. To the >system it should look as if the entire bridged network is on that one >interface. > >If this is not the case then we need to fix the bridging code so that >it is true, rather than clutter up higher level code trying to >account for a bug in the lower code. I found out this bug while using ng_bridge with BRIDGE in the kernel but turned off with the sysctl. Like I say in the problem report, this could easily be true if you take 2 NICs and wire them both up to the same switch, each using a different IP. (Something we do at QuakeCon for instance. We run a lot of servers per box, so we spread them out over 3 IPs, each with it's own NIC. Worked very well). Netgraph has nothing to do with this. I'm just warning people who are experimenting with the netgraph bridge because they will probably still have BRIDGE in their kernel. Let's run through this example of 2 NICs. Let's say I have BRIDGE in the kernel. I would not want to enable bridging in this case, because I would get a packet storm because of the loop between the machine and the switch. So I turn it off. But the checks for incoming interface are still switched off in the ethernet code. Checks that ARE executed when compiling without BRIDGE. NIC1 has 10.1.1.2 and NIC2 10.1.1.3. An ARP request is sent for 10.1.1.2, and since it's a broadcast it will arrive on both NIC1 and NIC2. Without the checks for what interface a packet came in on, the kernel will send 2 ARP replies, one saying 10.1.1.3 is on NIC1, the other that 10.1.1.3 is on NIC2. The last ARP reply to be sent will be used by the other machines on the network. Now with switches, they will probably handle broadcast packets the same way each time, so the same NIC on our machine will always get the ARP after the other got it. So the same NIC will always win the battle over an IP, resulting in ALL traffic for the machine, no matter what IP it was sent to, to go over a single NIC. That's a BAD(tm) thing. Now if you compare the code that my patch effects from before and after the patch you will see the following changes: original code: blabla(); #ifndef BRIDGE doCheck(); #endif dumDeDum(); my code blabla(); #ifdef BRIDGE if (do_bridge) { /* signifies whether bridging is switched on or off by the sysctl */ #else { #endif doCheck(); } dumDeDum(); This will make the ethernet code behave EXACTLY the same when bridging is switched off with the sysctl and when BRIDGE is NOT compiled into the kernel. Now, on the netgraph stuff. >So how can an incoming packet look like it is not coming from that single >interface? >1/ ifnet pointer. The function ng_ether_rcv_upper() adjust this, so that's >not the problem. >2/ rcv interface MAC address. This is stripped off before arp gets it >(also in ng_ether_rcv_upper()). >3/ the tha[] or sha[] fields may contain a MAC address for >some other interface. (depending on how the remote mechine fills out >those fields), but our outgoing packets should have the MAC address >of the interface we have selected as out main interface, independent of >which interface it actually goes out of, (unless the hardware >over-writes it). so even that should point to the single interface. > >The other interfaces should (maybe) beb ifconfigged 'UP' but they should >not have IP addresses assigned tp them, as they are being slaved from >the main interface by the ng_bridging code so everything comes and >goes via that one. > >so I'm slightly confused as to what problem this solves. >(I'm not saying there isn't one, just that I con't figure out what it is). >Everything should act as if there is just one interface when netgraph >bridging is turned on. Exactly if there's just one interface when netgraph bridging is on. Why? Why just one interface? Now that my kernel is patched to behave like BRIDGE wasn't compiled in when I switch it off I can include the upper's of multiple interfaces in a single netgraph bridge. If you think about it, this should not even be a problem. Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my apologies to everyone who can't look at graphical stuff) What is the difference between figures 1 and 2? Except that one uses a switch, and the other uses just a FreeBSD box. The way packets travel is almost identical. Why wouldn't it be a valid setup? You say that interfaces included in the ng_bridge should not have their upper's included as well, except for one. That's all fine for a static setup, but I'm dealing with a setup where I have a box that's a router between 2 networks, but sometimes needs to be a bridge as well. If I don't include the upper for one of the interfaces, outgoing packets on that interface will not pass my netgraph bridge, resulting in returning packets to be sent to all hooks on the bridge. I could of course hook my upper to a hole node, but then I'd have to move it's IP to the other interface. When I nuke the bridge I'd have to move it back. Why do that if including the upper in the bridge does the trick. Right now my FreeBSD box is routing between 3 networks and sometimes even bridging between all 3 and it works perfectly. I don't see any reason why multiple uppers can't be included. But like I said, my patch has nothing to do with netgraph. When net.link.ether.bridge == 0 the kernel should behave like a kernel that doesn't have BRIDGE compiled in it. That's currently not the case and my patch fixes that. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 4:28:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn211.dh.casema.net [212.64.31.211]) by hub.freebsd.org (Postfix) with ESMTP id BDA1F37B503 for ; Sat, 3 Feb 2001 04:27:55 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f13CoUb78315 for ; Sat, 3 Feb 2001 13:50:30 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010203132652.00acde00@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Feb 2001 13:27:19 +0100 To: freebsd-net@FreeBSD.ORG From: "Rogier R. Mulhuijzen" Subject: Re: FW: VPN question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >I have a question about FreeBSD and I'm hoping you > >can steer me in the right direction. We currently have a BSD box that is > >acting as our firewall with a NT domain behind it. We want to set up VPN > >solution where a client (running NT or Win2K) can access the internal NT > >server through the BSD firewall via the Internet. In other words the want > >to work from home and access the NT server that sits behind the firewall. > > > >Can this be done. If so, what software would need to run on the client. > >Any direction you could give would be appreciated. http://www.freebsd.org/cgi/ports.cgi?query=pptp&stype=all freshmeat.net is also a nice source for opensource software. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 9: 7:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 96CC837B491 for ; Sat, 3 Feb 2001 09:06:49 -0800 (PST) Received: (qmail 27044 invoked by uid 666); 3 Feb 2001 17:14:41 -0000 Received: from reggae-22-22.nv.iinet.net.au (HELO elischer.org) (203.59.87.22) by mail.m.iinet.net.au with SMTP; 3 Feb 2001 17:14:41 -0000 Message-ID: <3A7C3A89.AC30DFDA@elischer.org> Date: Sat, 03 Feb 2001 09:06:17 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Patch for non-netgraph bridge code worthy of attentionforpeople experimenting with bridging setups (including ng_bridge) References: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> <4.3.2.7.0.20010203122412.00cd4b30@mail.drwilco.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rogier R. Mulhuijzen" wrote: > [explanation] ok I understand now... I thought you were saying that the netgraph code was acting differently to how I belive it should act. > > > > > Exactly if there's just one interface when netgraph bridging is on. Why? > Why just one interface? Now that my kernel is patched to behave like BRIDGE > wasn't compiled in when I switch it off I can include the upper's of > multiple interfaces in a single netgraph bridge. sure you can. that isn't a problem. It would be a 'brouter' bridging non IP protocols and routing IP. > > If you think about it, this should not even be a problem. > > Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my > apologies to everyone who can't look at graphical stuff) ok I understan.. my question is: Do you know the girl on http://www.bsdchicks.com/ and is she single? :-) It should be valid.. and I start to see your point. by adding the checks back in (or compiling without BRIDGE) you can have both interfaces.... > > What is the difference between figures 1 and 2? Except that one uses a > switch, and the other uses just a FreeBSD box. yep > > The way packets travel is almost identical. Why wouldn't it be a valid setup? Another possibility would be to make a change to the netgraph bridge code so that it only delivers a broadcast packet to ONE local 'upper' hook. > > You say that interfaces included in the ng_bridge should not have their > upper's included as well, except for one. I didn't mean that they COULDN'T but only that they didn't NEED it > That's all fine for a static > setup, but I'm dealing with a setup where I have a box that's a router > between 2 networks, but sometimes needs to be a bridge as well. If I don't > include the upper for one of the interfaces, outgoing packets on that > interface will not pass my netgraph bridge, resulting in returning packets > to be sent to all hooks on the bridge. I could of course hook my upper to a > hole node, but then I'd have to move it's IP to the other interface. When I > nuke the bridge I'd have to move it back. Why do that if including the > upper in the bridge does the trick. > > Right now my FreeBSD box is routing between 3 networks and sometimes even > bridging between all 3 and it works perfectly. > Using netgraph or the other bridging? I presume Netgraph. > I don't see any reason why multiple uppers can't be included. neither do I, In fact I recommented it to someone yesterday. > > But like I said, my patch has nothing to do with netgraph. When > net.link.ether.bridge == 0 the kernel should behave like a kernel that > doesn't have BRIDGE compiled in it. That's currently not the case and my > patch fixes that. OK I will commit it. > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 9:21:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from hera.drwilco.net (10dyn211.dh.casema.net [212.64.31.211]) by hub.freebsd.org (Postfix) with ESMTP id DE33737B401; Sat, 3 Feb 2001 09:20:48 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f13HhDb23397; Sat, 3 Feb 2001 18:43:15 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010203180653.00afda70@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Feb 2001 18:15:06 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: Patch for non-netgraph bridge code worthy of attentionforpeople experimenting with bridging setups (including ng_bridge) Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-Reply-To: <3A7C3A89.AC30DFDA@elischer.org> References: <4.3.2.7.0.20010202205233.00d51c30@mail.drwilco.net> <4.3.2.7.0.20010203122412.00cd4b30@mail.drwilco.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >ok I understand now... >I thought you were saying that the netgraph code was acting differently >to how I belive it should act. Nope that was the legacy bridge. > > Exactly if there's just one interface when netgraph bridging is on. Why? > > Why just one interface? Now that my kernel is patched to behave like BRIDGE > > wasn't compiled in when I switch it off I can include the upper's of > > multiple interfaces in a single netgraph bridge. > >sure you can. >that isn't a problem. >It would be a 'brouter' bridging non IP protocols and routing IP. > > > > > If you think about it, this should not even be a problem. > > > > Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my > > apologies to everyone who can't look at graphical stuff) > >ok I understan.. my question is: >Do you know the girl on http://www.bsdchicks.com/ >and is she single? :-) Hahahaha, I don't have a clue who she is, and I'd love to know too =) >It should be valid.. and I start to see your point. > >by adding the checks back in (or compiling without BRIDGE) >you can have both interfaces.... Exactly > > What is the difference between figures 1 and 2? Except that one uses a > > switch, and the other uses just a FreeBSD box. > >yep > > > > > The way packets travel is almost identical. Why wouldn't it be a valid > setup? > >Another possibility would be to make a change to the netgraph bridge code >so that it only delivers a broadcast packet to ONE local 'upper' hook. I wouldn't do that. You'd be adding behaviour that people wouldn't expect, and make it a messy unlogical thing. If people want it delivered on one upper hook, they should include just that one hook. Why make "user friendly" logic that makes it complicated and bothersome for people who want to do more than just the standard things. > > You say that interfaces included in the ng_bridge should not have their > > upper's included as well, except for one. > >I didn't mean that they COULDN'T but only that they didn't NEED it Eek. Misunderstood, my apologies. > > Right now my FreeBSD box is routing between 3 networks and sometimes even > > bridging between all 3 and it works perfectly. > > > >Using netgraph or the other bridging? I presume Netgraph. You are correct. Because I also have my uplink to the internet and I don't want packets "leaking" out to there. My provider might want to start wondering what all these subnets are etc. 2 of the three networks are even on the other side of tunnels built with vtun to Linux and other FreeBSD boxes. Those other networks are also linked to more. Among other things we can now play IPX games over the internet without any hassle =) > > But like I said, my patch has nothing to do with netgraph. When > > net.link.ether.bridge == 0 the kernel should behave like a kernel that > > doesn't have BRIDGE compiled in it. That's currently not the case and my > > patch fixes that. > >OK I will commit it. Thanks. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 14:27:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id E42CD37B401; Sat, 3 Feb 2001 14:27:10 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id OAA86919; Sat, 3 Feb 2001 14:26:10 -0800 (PST) (envelope-from richw) Date: Sat, 3 Feb 2001 14:26:10 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: freebsd-net@freebsd.org Cc: freebsd-stable@freebsd.org Subject: BRIDGE breaks ARP? Message-ID: <20010203220223.86591.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the BRIDGE option, bridging between two PCI NICs (rl0 and xl0). I'm having ARP problems. Machines on the "rl0" card are unable to get a hardware address for the bridge. (For whatever reason, I have no problems talking via the "xl0" interface.) I've done "tcpdump" on the bridge, and it's receiving ARP queries on the "rl0" interface, but it doesn't appear to be sending replies. I did a "tcpdump" on the "xl0" interface too, just in case ARP replies were going out over the wrong interface, but no such luck. If I turn off bridging (sysctl -w net.link.ether.bridge=0), the ARP problem quickly resolves itself. So the problem would seem to be related somehow to the bridge code. I can sidestep the problem by using "arp -s" commands on the other machines to tell them the bridge's hardware address -- but I really shouldn't have to do this. Any ideas? Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 15:40:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 02D7E37B4EC; Sat, 3 Feb 2001 15:40:04 -0800 (PST) Received: from rfx-216-196-73-168.users.reflexcom.com ([216.196.73.168]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 3 Feb 2001 15:38:10 -0800 Received: (from cjc@localhost) by rfx-216-196-73-168.users.reflexcom.com (8.11.1/8.11.1) id f13NdHP51042; Sat, 3 Feb 2001 15:39:17 -0800 (PST) (envelope-from cjc) Date: Sat, 3 Feb 2001 15:39:17 -0800 From: "Crist J. Clark" To: Rich Wales Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? Message-ID: <20010203153917.I91447@rfx-216-196-73-168.users.reflex> Reply-To: cjclark@alum.mit.edu References: <20010203220223.86591.richw@wyattearp.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010203220223.86591.richw@wyattearp.stanford.edu>; from richw@webcom.com on Sat, Feb 03, 2001 at 02:26:10PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Feb 03, 2001 at 02:26:10PM -0800, Rich Wales wrote: > I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the > BRIDGE option, bridging between two PCI NICs (rl0 and xl0). > > I'm having ARP problems. Machines on the "rl0" card are unable to > get a hardware address for the bridge. (For whatever reason, I have > no problems talking via the "xl0" interface.) [snip] > I can sidestep the problem by using "arp -s" commands on the other > machines to tell them the bridge's hardware address -- but I really > shouldn't have to do this. > > Any ideas? Not all cards support bridging. The bridge(4) manpage _used to_ have a list of cards that work. Now all it says is, "Interfaces that cannot be put into promiscuous mode or that don't support sending packets with arbitrary Ethernet source addresses are not compati- ble with bridging." And I have not been able to figure out if the rl(4) device satisfies those conditions. I should note that rl(4) was not on the list of working cards prior to the change in the manpage. Maybe someone who knows more about the rl(4) driver can elaborate? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 16: 0:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 781A137B503; Sat, 3 Feb 2001 16:00:11 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id PAA88678; Sat, 3 Feb 2001 15:59:08 -0800 (PST) (envelope-from richw) Date: Sat, 3 Feb 2001 15:59:08 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: cjclark@alum.mit.edu Cc: freebsd-net@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? In-Reply-To: <20010203153917.I91447@rfx-216-196-73-168.users.reflex> Message-ID: <20010203234646.88009.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Crist Clark wrote: > Not all cards support bridging. As far as I can tell, the "rl" device is (or, at least, is supposed to be) supported by the bridge code. "ifconfig rl0" on my bridge shows the interface is running in promis- cuous mode, and bridging works perfectly for me in all respects other than ARP. The "rl0" card in my bridge is identified as an "Accton MPX 5030/5038", and I'm running it in 100baseTX full-duplex mode (connected to another machine via a crossover cable). Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 17:27:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 6966237B4EC for ; Sat, 3 Feb 2001 17:27:10 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.1) with ESMTP id f141R8t01011; Sun, 4 Feb 2001 01:27:08 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f141SkP72451; Sun, 4 Feb 2001 01:28:46 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102040128.f141SkP72451@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Nowlin Cc: Brian Somers , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: Message from Mike Nowlin of "Sat, 03 Feb 2001 01:45:35 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Feb 2001 01:28:46 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > > I can't see how this can happen without any previous log lines saying > > that a chap packet has been received. > > > > If this is repeatable, can you try doing a ``show timer'' right after > > the SUCCESS response has been sent ? If the radius timer wasn't > > cleared properly this might result, but I can't see how that could > > happen... > > Hmm... Repeatable every time on the machine in question. (Time passes > while I configure the a similar on a completely different set of > boxes.) Yup - repeatable on another machine as well. > > Two machines - core-1 and twikki. Twikki is receiving the call. > > I don't have the muscle trigger upgrade in my finger yet to be able to hit > return right when the SUCCESS rsp comes through (goes by way too fast), > but I did turn on timer debugging for these logs -- maybe it'll help. If > there's some way to trigger a "show timer" in the source at a certain > point, I'd be happy to try that... > > Thanks - Mike [.....] Err ok, on reflection that was a rather tricky thing to ask you to do... Sorry :-/ I think I've figured out the problem though... can you try the latest version of ppp - should be available via http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you don't get -current. I think you're just missing an acct line in your radius config file. The bug in ppp is that it treats the accounting failure as something it needs to send an authentication failure about.... -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 22:57:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from wyattearp.stanford.edu (wyattearp.Stanford.EDU [171.64.180.171]) by hub.freebsd.org (Postfix) with ESMTP id 2D18F37B401; Sat, 3 Feb 2001 22:57:11 -0800 (PST) Received: (from richw@localhost) by wyattearp.stanford.edu (8.9.3/8.9.3) id WAA95256; Sat, 3 Feb 2001 22:56:11 -0800 (PST) (envelope-from richw) Date: Sat, 3 Feb 2001 22:56:11 -0800 (PST) From: Rich Wales X-Sender: richw@wyattearp.stanford.edu To: freebsd-net@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <20010203220223.86591.richw@wyattearp.stanford.edu> Message-ID: <20010204062837.94849.richw@wyattearp.stanford.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Earlier, I reported an ARP problem on a 4.2-STABLE bridge system. A few people wrote me privately, advising me to include a firewall rule passing UDP packets on port 2054 to/from the IP address 0.0.0.0. I've tried this, but it doesn't help any. I should mention, though, that I don't think this firewall rule is relevant in any case. First, the "port 2054" kludge doesn't appear to be in the networking code any more. I grep'ed the entire -STABLE base source for any references to UDP port 2054, and I found nothing at all except for the commented-out line in the etc/rc.firewall file. As far as I'm aware, bridging of non-IP packets is now controlled by the kernel's default "ipfw" rule -- and, yes, I do have the options IPFIREWALL and IPFIREWALL_DEFAULT_TO_ACCEPT in my configuration. Second, I'm not talking about bridging of ARP packets anyway. I'm trying to connect directly to the bridge machine -- but the bridge is failing to respond to requests for its own hardware address on its "rl0" interface. Rich Wales richw@webcom.com http://www.webcom.com/richw/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 3 23: 0:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b044.neo.lrun.com [24.93.181.44]) by hub.freebsd.org (Postfix) with ESMTP id D8AFB37B401 for ; Sat, 3 Feb 2001 22:59:53 -0800 (PST) Received: from localhost (mike@localhost) by jason.argos.org (8.10.1/8.10.1) with ESMTP id f146nOR21355; Sun, 4 Feb 2001 01:49:24 -0500 Date: Sun, 4 Feb 2001 01:49:24 -0500 (EST) From: Mike Nowlin To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: <200102040128.f141SkP72451@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I think I've figured out the problem though... can you try the latest > version of ppp - should be available via > http://www.Awfulhak.org/ppp.html RSN (the 010204 archive) if you > don't get -current. > > I think you're just missing an acct line in your radius config file. > The bug in ppp is that it treats the accounting failure as something > it needs to send an authentication failure about.... That seems to have fixed it - I'll be testing things more tonight and tomorrow... Judging by the changes in the logs I see, I'd agree that it's in the accounting section. (New log chunk) Feb 4 01:54:58 rimmer ppp[727]: tun4: IPCP: myaddr 10.129.1.2 hisaddr = 10.99.1.6 Feb 4 01:54:58 rimmer ppp[727]: tun4: Warning: 10.99.1.6: Cannot determine ethernet address for proxy ARP Feb 4 01:54:58 rimmer ppp[727]: tun4: Phase: radius(acct): No RADIUS servers specified ...and it doesn't exit at this point now. Thanks - mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message