From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 11:55:29 2004 Return-Path: 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 4990A16A4CE; Sun, 20 Jun 2004 11:55:29 +0000 (GMT) Received: from mx3.mra.co.id (mx3.mra.co.id [202.138.254.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id F137B43D49; Sun, 20 Jun 2004 11:55:26 +0000 (GMT) (envelope-from reza@mra.co.id) Received: from localhost (unknown [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id 974EF2E086; Sun, 20 Jun 2004 14:28:39 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00936-28; Sun, 20 Jun 2004 14:27:24 +0700 (WIT) Received: from mail.mra.co.id (unknown [172.16.0.25]) by mx3.mra.co.id (Postfix) with ESMTP id 486892E088; Sun, 20 Jun 2004 14:27:24 +0700 (WIT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Sun, 20 Jun 2004 14:06:33 +0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multi Provider Connection to Internet Thread-Index: AcRWlR5s2VubflwjSNSYP9zNJ8Bjbw== From: "Mohammad Reza" To: X-Virus-Scanned: by amavisd-new at mra.co.id cc: freebsd-question@freebsd.org Subject: Multi Provider Connection to Internet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 11:55:29 -0000 RGVhciBBbGwsDQogDQpDYW4gRnJlZUJTRCBtYWNoaW5lIGFjdCBhcyBhIGdhdGV3YXkgZm9yIG11 bHRwbGUgcHJvdmlkZXIgdG8gaW50ZXJuZXQgPw0KSnVzdCBsaWtlIGh0dHA6Ly9sYXJ0Yy5vcmcv aG93dG8vbGFydGMucnBkYi5tdWx0aXBsZS1saW5rcy5odG1sIG9yICBodHRwOi8vd3d3LnNzaS5i Zy9+amEvI3JvdXRlcyA/DQpJJ3RzIHZlcnkgZGlmZmljdWx0IGZvciBtZSB0byBzZXQgdXAgc3Vj aCBhIGdhdGV3YXkgdy8gZnJlZUJTRC4gDQpJcyB0aGVyZSBhbnlvbmUgcnVubmluZyBvbmUgPyBw bGVhc2UgaGVscCBtZS4uLg0KIA0KcmVnYXJkcw0KcmV6YQ0K From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 16:05:21 2004 Return-Path: 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 407E316A4CF for ; Sun, 20 Jun 2004 16:05:21 +0000 (GMT) Received: from web60802.mail.yahoo.com (web60802.mail.yahoo.com [216.155.196.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 9801A43D53 for ; Sun, 20 Jun 2004 16:05:20 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040620160519.17208.qmail@web60802.mail.yahoo.com> Received: from [61.11.80.24] by web60802.mail.yahoo.com via HTTP; Sun, 20 Jun 2004 09:05:19 PDT Date: Sun, 20 Jun 2004 09:05:19 -0700 (PDT) From: Yohan To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 16:05:21 -0000 Im using PPPoE / FreeBSD 4.9 with a DSL line provided by my ISP. The same modem / line works fine / connects to the internet on a Windows 2000 machine. But when i use it with my FreeBSD machine using ppp i get the following message in my ppp.log "-> Waiting for carrier" - "Last message repeated n times". I have followed the FreeBSD handbook instructions for setting up PPPoE. Have also tried various other articles related to PPPoE setup on FreeBSD. I have tried various other options like disabling carrier and others but i am unable to get past the "no carrier" problem. Any help will be greatly apreciated. Thanks in advance and regards Yohan --------------------------------- Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 17:43:37 2004 Return-Path: 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 D53D816A4CE; Sun, 20 Jun 2004 17:43:37 +0000 (GMT) Received: from genius.tao.org.uk (pcp08929796pcs.anapol01.md.comcast.net [68.50.236.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DCFD43D49; Sun, 20 Jun 2004 17:43:36 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id 9823F4412; Sun, 20 Jun 2004 14:54:34 +0100 (BST) Date: Sun, 20 Jun 2004 14:54:34 +0100 From: Josef Karthauser To: current@freebsd.org, net@freebsd.org Message-ID: <20040620135433.GA769@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , current@freebsd.org, net@freebsd.org References: <20040620133936.GA791@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20040620133936.GA791@genius.tao.org.uk> User-Agent: Mutt/1.5.6i Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 17:43:38 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 20, 2004 at 02:39:36PM +0100, Josef Karthauser wrote: > Dear wireless geeks, >=20 > The ath manual pages says that we support the Netgear WG311 and the > WG511T, but do we also support the WG311T? (Is the T significant?). >=20 > Many thanks if you know the answer to this question. I should have said that the atheros web site states that the 511T and the 311T use the same chipset, which is the AR5002G, but that the FreeBSD manual page states that the 511T uses the AR5212 chipset and doesn't mention the AR5002G by name at all. Addionally the atheros web site doesn't mention a WG311 card at at all, only a HA311, WAG311 and WG311T. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iEYEARECAAYFAkDVlw8ACgkQXVIcjOaxUBbjAgCeNz5jrceFgemdsZtrMFMFZ8qu p5kAniJ/t0K1LL5KNwJgrfsDnPDGEHb4 =SrRX -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 17:43:53 2004 Return-Path: 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 0C84C16A4F2; Sun, 20 Jun 2004 17:43:50 +0000 (GMT) Received: from genius.tao.org.uk (pcp08929796pcs.anapol01.md.comcast.net [68.50.236.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3B7743D49; Sun, 20 Jun 2004 17:43:50 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id B9CD04393; Sun, 20 Jun 2004 14:39:36 +0100 (BST) Date: Sun, 20 Jun 2004 14:39:36 +0100 From: Josef Karthauser To: current@freebsd.org, net@freebsd.org Message-ID: <20040620133936.GA791@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , current@freebsd.org, net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 17:43:53 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear wireless geeks, The ath manual pages says that we support the Netgear WG311 and the WG511T, but do we also support the WG311T? (Is the T significant?). Many thanks if you know the answer to this question. Regards, Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iEYEARECAAYFAkDVk5cACgkQXVIcjOaxUBaC4wCgyA8Ct7onnFh9yASxsMZ2ncXo d90AniA4UOr5JRierBibjZm7nlSHQEq/ =2L7g -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 17:52:07 2004 Return-Path: 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 A725316A4CF; Sun, 20 Jun 2004 17:52:07 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 891E143D55; Sun, 20 Jun 2004 17:52:06 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Jun 2004 18:52:05 +0100 (BST) Date: Sun, 20 Jun 2004 18:52:05 +0100 From: David Malone To: Josef Karthauser , current@freebsd.org, net@freebsd.org Message-ID: <20040620175205.GA13235@walton.maths.tcd.ie> References: <20040620133936.GA791@genius.tao.org.uk> <20040620135433.GA769@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040620135433.GA769@genius.tao.org.uk> User-Agent: Mutt/1.5.3i Sender: dwmalone@maths.tcd.ie Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 17:52:07 -0000 On Sun, Jun 20, 2004 at 02:54:34PM +0100, Josef Karthauser wrote: > I should have said that the atheros web site states that the 511T and > the 311T use the same chipset, which is the AR5002G, but that the I know someone with a 511T, and it works with the ath driver, I believe. I also have a WAG511, which also works with the ath driver. The WG511 and WG311 a non-Atheros chipset and so you'd have to try project evil. > FreeBSD manual page states that the 511T uses the AR5212 chipset and > doesn't mention the AR5002G by name at all. Addionally the atheros web > site doesn't mention a WG311 card at at all, only a HA311, WAG311 and > WG311T. I think that's 'cos they are a different chipset all together. David. From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 18:30:08 2004 Return-Path: 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 6E46116A4CE; Sun, 20 Jun 2004 18:30:08 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09E6443D48; Sun, 20 Jun 2004 18:30:08 +0000 (GMT) (envelope-from se@freebsd.org) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Bc74x-0008Ec-00; Sun, 20 Jun 2004 20:30:07 +0200 Received: from [80.132.227.141] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1Bc74x-0005cp-00; Sun, 20 Jun 2004 20:30:07 +0200 Received: from StefanEsser.FreeBSD.org (StefanEsser [192.168.0.10]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 34F735F24; Sun, 20 Jun 2004 20:30:05 +0200 (CEST) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id A4B642304; Sun, 20 Jun 2004 20:30:04 +0200 (CEST) Date: Sun, 20 Jun 2004 20:30:04 +0200 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Josef Karthauser , current@freebsd.org, net@freebsd.org Message-ID: <20040620183004.GB94851@StefanEsser.FreeBSD.org> Mail-Followup-To: Stefan =?iso-8859-1?Q?E=DFer?= , Josef Karthauser , current@freebsd.org, net@freebsd.org References: <20040620133936.GA791@genius.tao.org.uk> <20040620135433.GA769@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040620135433.GA769@genius.tao.org.uk> User-Agent: Mutt/1.5.6i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 18:30:08 -0000 On 2004-06-20 14:54 +0100, Josef Karthauser wrote: > On Sun, Jun 20, 2004 at 02:39:36PM +0100, Josef Karthauser wrote: > > The ath manual pages says that we support the Netgear WG311 and the > > WG511T, but do we also support the WG311T? (Is the T significant?). AFAIK, the WG311T and WG511T use an enhanced Atheros chip with improved S/N ratio. (The Netgear web site talks about improved antenna technology, but I don't see what's special about that antenna at all. There used to be a more specific technical data sheet, which talked about the improved sensitivity and S/N of the new radio, and I guess that's what actually makes the difference. I also seem to remember some article on "www.smallnetbuilder.com" that talked about a new Atheros chip set with increased range back in September 2003. Hmmm, might have been: http://www.smallnetbuilder.com/News_story_328.php Since the chips are covered by a shield on the Mini-PCI (a second one, the PCI card has another shield around the Mini-PCI card), I can't tell what chips are actually used. > I should have said that the atheros web site states that the 511T and > the 311T use the same chipset, which is the AR5002G, but that the > FreeBSD manual page states that the 511T uses the AR5212 chipset and > doesn't mention the AR5002G by name at all. Addionally the atheros web > site doesn't mention a WG311 card at at all, only a HA311, WAG311 and > WG311T. See: http://www.netgear.com/products/prod_details.php?prodID=236 The WG311T definitely works, both with the Atheros driver and with the NDIS wrapper. I've unsoldered the Mini-PCI from the PCI carrier and have used it to replace the Centrino WLAN card in my Dell D800. I can provide boot messages (with either driver), if there is any interest ... Regards, STefan From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 18:49:23 2004 Return-Path: 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 54DBD16A4CE for ; Sun, 20 Jun 2004 18:49:23 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9393243D31 for ; Sun, 20 Jun 2004 18:49:22 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i5KImxu1068073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jun 2004 22:48:59 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i5KImwp0068072; Sun, 20 Jun 2004 22:48:58 +0400 (MSD) Date: Sun, 20 Jun 2004 22:48:58 +0400 From: Gleb Smirnoff To: Yohan Message-ID: <20040620184858.GA68020@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yohan , freebsd-net@freebsd.org References: <20040620160519.17208.qmail@web60802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040620160519.17208.qmail@web60802.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 18:49:23 -0000 On Sun, Jun 20, 2004 at 09:05:19AM -0700, Yohan wrote: Y> Im using PPPoE / FreeBSD 4.9 with a DSL line provided by my ISP. The same modem / line works fine / connects to the internet on a Windows 2000 machine. But when i use it with my FreeBSD machine using ppp i get the following message in my ppp.log "-> Waiting for carrier" - "Last message repeated n times". I have followed the FreeBSD handbook instructions for setting up PPPoE. Have also tried various other articles related to PPPoE setup on FreeBSD. I have tried various other options like disabling carrier and others but i am unable to get past the "no carrier" problem. Any help will be greatly apreciated. Please show full ppp.log starting from the moment when you started dailing. Please also show your ppp.conf -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 19:47:11 2004 Return-Path: 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 B4E9216A4CE; Sun, 20 Jun 2004 19:47:11 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E0943D46; Sun, 20 Jun 2004 19:47:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i5KJlAYW093005; Sun, 20 Jun 2004 21:47:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, net@freebsd.org From: Poul-Henning Kamp Date: Sun, 20 Jun 2004 21:47:10 +0200 Message-ID: <93004.1087760830@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [TEST] natd multipath patches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 19:47:11 -0000 I have worked a bit more on my natd multipath patches and they are now known to "basically work". If you have multiple xDSL lines or two modems to different ISPs or cable and xDSL etc. then grab: http://phk.freebsd.org/misc/natd And try it out on your FreeBSD -current firewall. Please test and report success/failures/ideas/patches. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 19:55:20 2004 Return-Path: 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 3497316A4CE; Sun, 20 Jun 2004 19:55:20 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F5D43D39; Sun, 20 Jun 2004 19:55:19 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 1C026119CA; Sun, 20 Jun 2004 21:55:12 +0200 (CEST) Date: Sun, 20 Jun 2004 21:55:12 +0200 From: "Simon L. Nielsen" To: Poul-Henning Kamp Message-ID: <20040620195512.GG826@zaphod.nitro.dk> References: <93004.1087760830@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGu/vTNewDGZ7tmp" Content-Disposition: inline In-Reply-To: <93004.1087760830@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: net@freebsd.org Subject: Re: [TEST] natd multipath patches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 19:55:20 -0000 --MGu/vTNewDGZ7tmp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.06.20 21:47:10 +0200, Poul-Henning Kamp wrote: > If you have multiple xDSL lines or two modems to different ISPs or > cable and xDSL etc. then grab: > > http://phk.freebsd.org/misc/natd I think http://phk.freebsd.dk/misc/natd/ will work better :-). --=20 Simon L. Nielsen FreeBSD Documentation Team --MGu/vTNewDGZ7tmp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA1eugh9pcDSc1mlERAj5gAKCs+TSU9H620obRFClRNTxCudUU+ACcCSHF kfdRU5m0/etvRjJm5dBT6kQ= =07nI -----END PGP SIGNATURE----- --MGu/vTNewDGZ7tmp-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 19:58:09 2004 Return-Path: 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 68FA816A4CE; Sun, 20 Jun 2004 19:58:09 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE01343D2D; Sun, 20 Jun 2004 19:58:08 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i5KJw7US093264; Sun, 20 Jun 2004 21:58:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Simon L. Nielsen" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 20 Jun 2004 21:55:12 +0200." <20040620195512.GG826@zaphod.nitro.dk> Date: Sun, 20 Jun 2004 21:58:07 +0200 Message-ID: <93263.1087761487@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: [TEST] natd multipath patches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 19:58:09 -0000 In message <20040620195512.GG826@zaphod.nitro.dk>, "Simon L. Nielsen" writes: > >--MGu/vTNewDGZ7tmp >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On 2004.06.20 21:47:10 +0200, Poul-Henning Kamp wrote: > >> If you have multiple xDSL lines or two modems to different ISPs or >> cable and xDSL etc. then grab: >> >> http://phk.freebsd.org/misc/natd > >I think http://phk.freebsd.dk/misc/natd/ will work better :-). yeah, of course... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 21:30:26 2004 Return-Path: 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 A34EC16A520 for ; Sun, 20 Jun 2004 21:30:26 +0000 (GMT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED0F343D5A for ; Sun, 20 Jun 2004 21:30:09 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id XAA12725; Sun, 20 Jun 2004 23:30:08 +0200 (CEST) Received: from uriah.heep.sax.de (localhost.heep.sax.de [127.0.0.1]) by uriah.heep.sax.de (8.12.10/8.12.10) with ESMTP id i5KLTafK030691; Sun, 20 Jun 2004 23:29:36 +0200 (MET DST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.12.10/8.12.10/Submit) id i5KLTaJg030690; Sun, 20 Jun 2004 23:29:36 +0200 (MET DST) (envelope-from j) Date: Sun, 20 Jun 2004 23:29:36 +0200 From: Joerg Wunsch To: Roman Kurakin Message-ID: <20040620232936.D13428@uriah.heep.sax.de> References: <40D4C79B.2050400@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40D4C79B.2050400@cronyx.ru>; from rik@cronyx.ru on Sun, Jun 20, 2004 at 03:09:15AM +0400 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GnuPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 X-Spam-Status: No, hits=-29.3 required=7.5 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) cc: net@freebsd.org Subject: Re: if_sppp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 21:30:26 -0000 As Roman Kurakin wrote: > Problem: > If we have max_failure < MAXALIVECNT*5 we will > send conf-rej for magic. > Solution: > Loopback could be treated as a special case and > thus we may not count it as a failure. Can you explain a little more, please? The patch is simple enough, yes, but offhand I don't know what's the actual problem resulting out of the above situation. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 21:38:56 2004 Return-Path: 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 9675016A4CE; Sun, 20 Jun 2004 21:38:56 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C7ED43D45; Sun, 20 Jun 2004 21:38:56 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i5KLctWi035489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 20 Jun 2004 14:38:55 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <20040620183004.GB94851@StefanEsser.FreeBSD.org> References: <20040620133936.GA791@genius.tao.org.uk> <20040620135433.GA769@genius.tao.org.uk> <20040620183004.GB94851@StefanEsser.FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3999C554-C302-11D8-B23F-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit From: Sam Leffler Date: Sun, 20 Jun 2004 14:38:53 -0700 To: =?ISO-8859-1?Q?Stefan_E=DFer?= X-Mailer: Apple Mail (2.618) cc: Josef Karthauser cc: current@freebsd.org cc: net@freebsd.org Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 21:38:56 -0000 All Atheros h/w is supported by the current ath driver or works with the patches in http://www.freebsd.org/~sam. When I put out the original patches I got zero feedback so didn't commit the changes. Now I've got no time and they changes are so out of date that there's little point in committing them as newer, much improved, code is almost ready. My hope is that when the new code is ready I'll have some time to commit it to FreeBSD. Otherwise someone else is welcome to step up and help. Sam From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 22:08:15 2004 Return-Path: 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 3C27B16A4CE for ; Sun, 20 Jun 2004 22:08:15 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 627F843D4C for ; Sun, 20 Jun 2004 22:08:14 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i5KM22CW056596 for net@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 21 Jun 2004 02:02:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i5KM0USr056542; (8.12.8/vak/2.1) Mon, 21 Jun 2004 02:00:31 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40D60791.8080200@cronyx.ru> Date: Mon, 21 Jun 2004 01:54:25 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Joerg Wunsch References: <40D4C79B.2050400@cronyx.ru> <20040620232936.D13428@uriah.heep.sax.de> In-Reply-To: <20040620232936.D13428@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: if_sppp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 22:08:15 -0000 Joerg Wunsch: >As Roman Kurakin wrote: > > > >>Problem: >> If we have max_failure < MAXALIVECNT*5 we will >>send conf-rej for magic. >> >> >>Solution: >> Loopback could be treated as a special case and >>thus we may not count it as a failure. >> >> > >Can you explain a little more, please? The patch is simple enough, >yes, but offhand I don't know what's the actual problem resulting out >of the above situation. > > Ok. If we have loopback, we will continue to try with some new value of magic. In every try we will increase both fail_count and loopback count. After every try we will check both counters if they exceed appropriate max value and will take some action if one of them does. But since max_failue is 10 and max for loopback counter is 15 we will have only special action after axceed of fail_counter. This in turn means that we will reject magic and since we are loopbacked we will recieve it and turn off magic. After next attempt we will take any magic (since we turn it off) and will move from lcp to ipcp or whatever else. I used to use this for driver testings, since state machine becomes crazy and I get very good traffic. ;-) But this definitely should be fixed. I think the best way to fix this is to treate loopack in different way from other failures. And since loopbacks have its own counter they should be counted as failures. rik From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 22:50:31 2004 Return-Path: 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 D987216A4D3 for ; Sun, 20 Jun 2004 22:50:31 +0000 (GMT) Received: from 153-bem-1.acn.waw.pl (153-bem-1.acn.waw.pl [62.121.80.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 1D91443D60 for ; Sun, 20 Jun 2004 22:50:29 +0000 (GMT) (envelope-from lukasz.stelmach@k.telmark.waw.pl) Received: (qmail 40136 invoked by uid 1000); 20 Jun 2004 22:50:25 -0000 Date: Mon, 21 Jun 2004 00:50:25 +0200 From: Lukasz Stelmach To: Hajimu UMEMOTO Message-ID: <20040620225025.GA38473@tygrys.k.telmark.waw.pl> References: <20040511160734.GA66419@tygrys.k.telmark.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Mail-Editor: nvi X-GPG-Fingerprint: 68B8 6D4F 0C5E 291F C4E0 BBF4 35DC D8F2 C9BD 2BDC X-GPG-Key: http://www.ee.pw.edu.pl/~stelmacl/gpg_key.txt cc: freebsd-net@freebsd.org Subject: Re: if_stf bug/feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lukasz Stelmach List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 22:50:32 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday, 12 May 2004 at 02:53:02, Hajimu UMETO wrote: Lukasz>> I will *try* to look at it if you don't mind. [...] HU> A friend of mine tested this patch on his 4-STABLE box. It's been some time but i have looked at this and... "There is always one more bug." I have one ethernet card in my machine but it has two IPs. One to comunicate on the LAN and the VPN and another that is defined on my router as a DMZ address. I really don't want to change it for it Works Just Fine. But stf driver chooses the primary (LAN) address instead of secondary (DMZ) and so it happens that packets sent to the outside world don't fit in the nat on router :-( Neither incoming packets, nated to DMZ, are received properly. Trzymaj si=EA ciep=B3o Hajimu... PS. I'll try to work it around with ipnat but that is not The Proper Way. --=20 |/ |_, _ .- --, Ju=BF z ka=BFdej strony pe=B3zn=B1, potworne =BF= =B1dze |__ |_|. | \ |_|. ._' /_. B=EAd=EA uprawia=B3 nierz=B1d, za pieni= =B1ze --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA1hSxNdzY8sm9K9wRAn1qAJ9X9SeV0lNPsnoXMLvrTT7p3xyRrgCbB0cr +OgRAMYLwnPXDnbqbUgqs6Y= =5DUY -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 08:44:10 2004 Return-Path: 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 4B69416A4CE for ; Mon, 21 Jun 2004 08:44:10 +0000 (GMT) Received: from web60807.mail.yahoo.com (web60807.mail.yahoo.com [216.155.196.70]) by mx1.FreeBSD.org (Postfix) with SMTP id C33F543D55 for ; Mon, 21 Jun 2004 08:44:09 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621084409.1142.qmail@web60807.mail.yahoo.com> Received: from [220.226.41.229] by web60807.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 01:44:09 PDT Date: Mon, 21 Jun 2004 01:44:09 -0700 (PDT) From: Yohan To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20040620184858.GA68020@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 08:44:10 -0000 Gleb, Thanks for the reply. i have attached my ppp.conf and ppp.log as requested. I have tried setting carrier / ctsrts on/off and various other permutations / combinations. The best i proceeded till is ... Jun 19 13:00:26 chennai ppp[178]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 19 13:00:26 chennai ppp[178]: tun0: Debug: Waiting for carrier Jun 19 13:00:27 chennai ppp[178]: tun0: Timer: Select returns -1 Jun 19 13:00:27 chennai ppp[178]: tun0: Timer: ---- Begin of Timer Service List--- Jun 19 13:00:27 chennai ppp[178]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 19 13:00:27 chennai ppp[178]: tun0: Timer: ---- End of Timer Service List --- Jun 19 13:00:27 chennai ppp[178]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 19 13:00:27 chennai ppp[178]: tun0: Debug: Waiting for carrier regards Yohan ppp.conf default: set log all # Phase Chat LCP IPCP CCP tun command Debug nat enable yes nat same_ports yes nat use_sockets yes set redial 15 28800 set reconnect 15 28800 bsnl: set device PPPoE:rl0 set mru 1492 set mtu 1492 set speed sync enable lqr # set lqrperiod 5 set cd off # set cd 5! # set cd 600 set dial set login set timeout 0 set authname ******* set authkey ******* set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 delete all add default HISADDR enable dns set ctsrts off # set ctsrts on ppp.log Jun 21 12:17:44 chennai ppp[180]: Phase: Using interface: tun0 Jun 21 12:17:44 chennai ppp[180]: Phase: deflink: Created in closed state Jun 21 12:17:44 chennai ppp[180]: tun0: Command: default: nat enable yes Jun 21 12:17:44 chennai ppp[180]: tun0: Command: default: nat same_ports yes Jun 21 12:17:44 chennai ppp[180]: tun0: Command: default: nat use_sockets yes Jun 21 12:17:44 chennai ppp[180]: tun0: Command: default: set redial 15 28800 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: default: set reconnect 15 28800 Jun 21 12:17:44 chennai ppp[180]: tun0: ID0: 0x282948a0 = fopen("/etc/ppp/ppp.conf", "r") Jun 21 12:17:44 chennai ppp[180]: tun0: Debug: ReadSystem: Checking bsnl (/etc/ppp/ppp.conf). Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set device PPPoE:rl0 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set mru 1492 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set mtu 1492 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set speed sync Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: enable lqr Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set cd off Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set dial Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set login Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set timeout 0 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set authname hddias33 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set authkey ******** Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: delete all Jun 21 12:17:44 chennai ppp[180]: tun0: Debug: route_IfDelete (8) Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: add default HISADDR Jun 21 12:17:44 chennai ppp[180]: tun0: ID0: 9 = socket(17, 3, 0) Jun 21 12:17:44 chennai ppp[180]: tun0: ID0: 140 = write(9, data, 140) Jun 21 12:17:44 chennai ppp[180]: tun0: Debug: wrote 140: cmd = Add, dst = 0.0.0.0/0, gateway = 10.0.0.2 Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: enable dns Jun 21 12:17:44 chennai ppp[180]: tun0: Command: bsnl: set ctsrts off Jun 21 12:17:44 chennai ppp[181]: tun0: ID0: 0x282948a0 = fopen("/var/run/tun0.pid", "w") Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: PPP Started (ddial mode). Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: bundle: Establish Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: deflink: closed -> opening Jun 21 12:17:44 chennai ppp[181]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: List of netgraph node ``rl0:'' (id 1) hooks: Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Creating PPPoE netgraph node [1]:orphans -> ethernet Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Connecting netgraph socket .:tun0 -> rl0:orphans:tun0 Jun 21 12:17:44 chennai ppp[181]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 12:17:44 chennai ppp[181]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 12:17:44 chennai ppp[181]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 12:17:44 chennai ppp[181]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Found the following interfaces: Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 1, name "rl0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 2, name "rl1" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 3, name "lp0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 4, name "lo0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 5, name "ppp0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 6, name "sl0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 7, name "faith0" Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Index 8, name "tun0" Jun 21 12:17:44 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: deflink: Connected! Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: deflink: opening -> dial Jun 21 12:17:44 chennai ppp[181]: tun0: Phase: deflink: dial -> carrier Jun 21 12:17:44 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:17:45 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:17:45 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:17:45 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:17:45 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:17:45 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:45 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:17:46 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:17:46 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:17:46 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:17:46 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:17:46 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:46 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:17:47 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:17:47 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:17:47 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:17:47 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:17:47 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:47 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:17:48 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:17:48 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:17:48 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:17:48 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:17:48 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:48 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: Disconnected! Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: carrier -> hangup Jun 21 12:17:49 chennai ppp[181]: tun0: Debug: deflink: Close Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 12:17:44 2004 Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: hangup -> opening Jun 21 12:17:49 chennai ppp[181]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 12:17:49 chennai ppp[181]: tun0: Phase: deflink: Enter pause (15) for redialing. Jun 21 12:18:04 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:04 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:04 chennai ppp[181]: tun0: Timer: dial timer[0x80b7d44]: freq = 15.00s, next = 0.00s, state = running Jun 21 12:18:04 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:18:04 chennai ppp[181]: tun0: Chat: deflink: Redial timer expired. Jun 21 12:18:04 chennai ppp[181]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 12:18:04 chennai ppp[181]: tun0: Debug: List of netgraph node ``rl0:'' (id 1) hooks: Jun 21 12:18:04 chennai ppp[181]: tun0: Debug: Found orphans -> ethernet Jun 21 12:18:04 chennai ppp[181]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 12:18:04 chennai ppp[181]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 12:18:04 chennai ppp[181]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 12:18:04 chennai ppp[181]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 12:18:04 chennai ppp[181]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 12:18:04 chennai ppp[181]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 12:18:04 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:18:04 chennai ppp[181]: tun0: Phase: deflink: Connected! Jun 21 12:18:04 chennai ppp[181]: tun0: Phase: deflink: opening -> dial Jun 21 12:18:04 chennai ppp[181]: tun0: Phase: deflink: dial -> carrier Jun 21 12:18:04 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:18:05 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:05 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:05 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:18:05 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:18:05 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:18:05 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:18:06 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:06 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:06 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:18:06 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:18:06 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:18:06 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:18:07 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:07 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:07 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:18:07 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:18:07 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:18:07 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:18:08 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:08 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:08 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 12:18:08 chennai ppp[181]: tun0: Timer: ---- End of Timer Service List --- Jun 21 12:18:08 chennai ppp[181]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 12:18:08 chennai ppp[181]: tun0: Debug: Waiting for carrier Jun 21 12:18:09 chennai ppp[181]: tun0: Timer: Select returns -1 Jun 21 12:18:09 chennai ppp[181]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 12:18:09 chennai ppp[181]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running --- Gleb Smirnoff wrote: > On Sun, Jun 20, 2004 at 09:05:19AM -0700, Yohan > wrote: > Y> Im using PPPoE / FreeBSD 4.9 with a DSL line > provided by my ISP. The same modem / line works fine > / connects to the internet on a Windows 2000 > machine. But when i use it with my FreeBSD machine > using ppp i get the following message in my ppp.log > "-> Waiting for carrier" - "Last message repeated n > times". I have followed the FreeBSD handbook > instructions for setting up PPPoE. Have also tried > various other articles related to PPPoE setup on > FreeBSD. I have tried various other options like > disabling carrier and others but i am unable to get > past the "no carrier" problem. Any help will be > greatly apreciated. > > Please show full ppp.log starting from the moment > when you started dailing. > Please also show your ppp.conf > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 09:11:13 2004 Return-Path: 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 EE10116A4D1 for ; Mon, 21 Jun 2004 09:11:13 +0000 (GMT) Received: from web60810.mail.yahoo.com (web60810.mail.yahoo.com [216.155.196.73]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B8BD43D31 for ; Mon, 21 Jun 2004 09:11:13 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621091112.87515.qmail@web60810.mail.yahoo.com> Received: from [220.226.41.229] by web60810.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 02:11:12 PDT Date: Mon, 21 Jun 2004 02:11:12 -0700 (PDT) From: Yohan To: freebsd-net@freebsd.org In-Reply-To: <20040620184858.GA68020@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 09:11:14 -0000 Gleb, I have enclosed another copy of ppp.log with slightly different results. Thanks for the help. regards Yohann ppp.log Jun 21 14:00:53 chennai ppp[353]: Phase: Using interface: tun0 Jun 21 14:00:53 chennai ppp[353]: Phase: deflink: Created in closed state Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: ident user-ppp VERSION (built COMPILATIONDATE) Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set device PPPoE:rl1 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set mru 1492 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set mtu 1492 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set speed sync Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: enable lqr Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set cd off Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set dial Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set login Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set timeout 0 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set authname hddias33 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set authkey ******** Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: delete all Jun 21 14:00:53 chennai ppp[353]: tun0: Debug: route_IfDelete (8) Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: add default HISADDR Jun 21 14:00:53 chennai ppp[353]: tun0: ID0: 9 = socket(17, 3, 0) Jun 21 14:00:53 chennai ppp[353]: tun0: ID0: 140 = write(9, data, 140) Jun 21 14:00:53 chennai ppp[353]: tun0: Debug: wrote 140: cmd = Add, dst = 0.0.0.0/0, gateway = 10.0.0.2 Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: enable dns Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0x282948a0 = fopen("/var/run/tun0.pid", "w") Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: PPP Started (ddial mode). Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: bundle: Establish Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: deflink: closed -> opening Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Creating PPPoE netgraph node [2]:orphans -> ethernet Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> rl1:orphans:tun0 Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:00:53 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Found the following interfaces: Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 1, name "rl0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 2, name "rl1" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 3, name "lp0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 4, name "lo0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 5, name "ppp0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 6, name "sl0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 7, name "faith0" Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index 8, name "tun0" Jun 21 14:00:53 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:54 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:00:54 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:55 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:56 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:57 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:00:58 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:00:53 2004 Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: dial timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = running Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:28 chennai ppp[354]: tun0: Chat: deflink: Redial timer expired. Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Found orphans -> ethernet Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:01:28 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:29 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:01:29 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:30 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:31 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:32 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:01:33 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:01:28 2004 Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: dial timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = running Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:03 chennai ppp[354]: tun0: Chat: deflink: Redial timer expired. Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Found orphans -> ethernet Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:02:03 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:04 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:02:04 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:05 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:06 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:07 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:02:08 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:02:03 2004 Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: dial timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = running Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:38 chennai ppp[354]: tun0: Chat: deflink: Redial timer expired. Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Found orphans -> ethernet Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:02:38 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:39 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:02:39 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:40 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:41 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:42 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:02:43 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:02:38 2004 Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: dial timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = running Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:13 chennai ppp[354]: tun0: Chat: deflink: Redial timer expired. Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Found orphans -> ethernet Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:03:13 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:14 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:03:14 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:15 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:16 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:17 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:03:18 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:03:13 2004 Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: dial timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = running Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:48 chennai ppp[354]: tun0: Chat: deflink: Redial timer expired. Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Found orphans -> ethernet Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 14:03:48 chennai ppp[354]: tun0: Warning: deflink: Carrier must be set, using ``set cd 5!'' Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: deflink: Connected! Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: deflink: opening -> dial Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: deflink: dial -> carrier Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:49 chennai ppp[354]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 14:03:49 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:50 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:51 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:52 chennai ppp[354]: tun0: Debug: Waiting for carrier Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: Select returns -1 Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: ---- End of Timer Service List --- Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: Disconnected! Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: carrier -> hangup Jun 21 14:03:53 chennai ppp[354]: tun0: Debug: deflink: Close Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:03:48 2004 Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: hangup -> opening Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: deflink: Enter pause (30) for redialing. --- Gleb Smirnoff wrote: > On Sun, Jun 20, 2004 at 09:05:19AM -0700, Yohan > wrote: > Y> Im using PPPoE / FreeBSD 4.9 with a DSL line > provided by my ISP. The same modem / line works fine > / connects to the internet on a Windows 2000 > machine. But when i use it with my FreeBSD machine > using ppp i get the following message in my ppp.log > "-> Waiting for carrier" - "Last message repeated n > times". I have followed the FreeBSD handbook > instructions for setting up PPPoE. Have also tried > various other articles related to PPPoE setup on > FreeBSD. I have tried various other options like > disabling carrier and others but i am unable to get > past the "no carrier" problem. Any help will be > greatly apreciated. > > Please show full ppp.log starting from the moment > when you started dailing. > Please also show your ppp.conf > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 11:02:08 2004 Return-Path: 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 A414716A4CE for ; Mon, 21 Jun 2004 11:02:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864A543D5A for ; Mon, 21 Jun 2004 11:02:08 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i5LB1vlh064658 for ; Mon, 21 Jun 2004 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5LB1u64064652 for freebsd-net@freebsd.org; Mon, 21 Jun 2004 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Jun 2004 11:01:56 GMT Message-Id: <200406211101.i5LB1u64064652@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 11:02:08 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 11:21:19 2004 Return-Path: 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 381B116A4CE for ; Mon, 21 Jun 2004 11:21:19 +0000 (GMT) Received: from Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8166C43D54 for ; Mon, 21 Jun 2004 11:21:18 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by Awfulhak.org (8.12.11/8.12.11) with SMTP id i5LBMBuq008816; Mon, 21 Jun 2004 12:22:11 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 21 Jun 2004 12:22:11 +0100 From: Brian Somers To: Yohan Message-Id: <20040621122211.30f48082@dev.lan.Awfulhak.org> In-Reply-To: <20040621084409.1142.qmail@web60807.mail.yahoo.com> References: <20040620184858.GA68020@cell.sick.ru> <20040621084409.1142.qmail@web60807.mail.yahoo.com> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 11:21:19 -0000 On Mon, 21 Jun 2004 01:44:09 -0700 (PDT), Yohan wrote: > Gleb, > > Thanks for the reply. i have attached my ppp.conf and > ppp.log as requested. I have tried setting carrier / > ctsrts on/off and various other permutations / > combinations. The best i proceeded till is ... > Jun 19 13:00:26 chennai ppp[178]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") This seems to be the only message that the pppoe node is passing back to ppp. ppp is waiting for NGM_PPPOE_{SUCCESS,FAIL,CLOSE}. > Jun 19 13:00:26 chennai ppp[178]: tun0: Debug: Waiting > for carrier [.....] And until it gets NGM_PPPOE_{SUCCESS,FAIL,CLOSE}, ppp will stay waiting for carrier. I'd suggest you have a look at what traffic is being passed back and forth on the wire - it might indicate what's going on. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 12:05:51 2004 Return-Path: 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 12EBD16A4CE for ; Mon, 21 Jun 2004 12:05:51 +0000 (GMT) Received: from web60801.mail.yahoo.com (web60801.mail.yahoo.com [216.155.196.64]) by mx1.FreeBSD.org (Postfix) with SMTP id 7EBF543D41 for ; Mon, 21 Jun 2004 12:05:50 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621120536.45437.qmail@web60801.mail.yahoo.com> Received: from [220.226.53.49] by web60801.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 05:05:36 PDT Date: Mon, 21 Jun 2004 05:05:36 -0700 (PDT) From: Yohan To: freebsd-net@freebsd.org In-Reply-To: <20040621091859.GA72783@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 12:05:51 -0000 Gleb, Thanks once again for the prompt reply. i have tried out the config u sent me and have attached the ppp.log below. what's perplexing me is that it works on any windows machine i connect with but not thru my freebsd box. It seems to be waiting for a carrier endlessly. I have tried out numerous permutations and combinations with the ppp.conf, the latest being i have disabled ipv6 too. But my efforts seem to be going nowhere. Are there any other ideas i could try out ..?? regards Yohann Jun 21 17:22:47 chennai ppp[639]: Phase: Using interface: tun0 Jun 21 17:22:47 chennai ppp[639]: Phase: deflink: Created in closed state Jun 21 17:22:47 chennai ppp[639]: tun0: Command: bsnl: disable deflate pred1 acfcomp protocomp pap Jun 21 17:22:47 chennai ppp[639]: tun0: Command: bsnl: deny deflate pred1 acfcomp pap Jun 21 17:22:47 chennai ppp[639]: tun0: Command: bsnl: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 Jun 21 17:22:47 chennai ppp[639]: tun0: Command: bsnl: disable ipv6 Jun 21 17:22:47 chennai ppp[640]: tun0: ID0: 0x282948a0 = fopen("/var/run/tun0.pid", "w") Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: PPP Started (ddial mode). Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: bundle: Establish Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: deflink: closed -> opening Jun 21 17:22:47 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Creating PPPoE netgraph node [2]:orphans -> ethernet Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> rl1:orphans:tun0 Jun 21 17:22:47 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:22:47 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:22:47 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Found the following interfaces: Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 1, name "rl0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 2, name "rl1" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 3, name "lp0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 4, name "lo0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 5, name "ppp0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 6, name "sl0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 7, name "faith0" Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Index 8, name "tun0" Jun 21 17:22:47 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:22:47 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:22:47 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:48 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:48 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:48 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:48 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:48 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:48 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:22:48 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:49 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:49 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:49 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:49 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:49 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:49 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:50 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:50 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:50 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:50 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:50 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:50 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:51 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:51 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:51 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:51 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:51 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:51 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:22:52 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:22:47 2004 Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:22:52 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:22:52 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:22:53 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:53 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:53 chennai ppp[640]: tun0: Timer: dial timer[0x80b7d44]: freq = 0.10s, next = 0.00s, state = running Jun 21 17:22:53 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:53 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:22:53 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:22:53 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:22:53 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:22:53 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:22:53 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:22:53 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:22:53 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:22:53 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:22:53 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:53 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:22:53 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:22:53 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:22:53 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:54 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:54 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:54 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:54 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:54 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:54 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:22:54 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:55 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:55 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:55 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:55 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:55 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:55 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:56 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:56 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:56 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:56 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:56 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:56 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:57 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:57 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:57 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:57 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:57 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:57 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:22:53 2004 Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:58 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:22:58 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:22:58 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:22:58 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:22:58 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:22:58 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:22:58 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:22:58 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:22:59 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:22:59 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:22:59 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:22:59 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:22:59 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:22:59 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:22:59 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:00 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:00 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:00 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:00 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:00 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:00 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:01 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:01 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:01 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:01 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:01 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:01 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:02 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:02 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:02 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:02 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:02 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:02 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:22:58 2004 Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:03 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:03 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:03 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:03 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:03 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:03 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:03 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:03 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:04 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:04 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:04 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:04 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:04 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:04 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:04 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:05 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:05 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:05 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:05 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:05 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:05 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:06 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:06 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:06 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:06 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:06 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:06 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:07 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:07 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:07 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:07 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:07 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:07 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:03 2004 Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:08 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:08 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:08 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:08 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:08 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:08 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:08 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:08 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:09 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:09 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:09 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:09 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:09 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:09 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:09 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:10 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:10 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:10 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:10 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:10 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:10 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:11 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:11 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:11 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:11 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:11 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:11 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:12 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:12 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:12 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:12 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:12 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:12 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:08 2004 Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:13 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:13 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:13 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:13 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:13 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:13 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:13 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:13 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:14 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:14 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:14 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:14 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:14 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:14 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:14 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:15 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:15 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:15 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:15 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:15 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:15 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:16 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:16 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:16 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:16 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:16 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:16 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:17 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:17 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:17 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:17 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:17 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:17 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:13 2004 Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:18 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:18 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:18 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:18 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:18 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:18 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:18 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:18 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:19 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:19 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:19 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:19 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:19 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:19 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:19 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:20 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:20 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:20 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:20 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:20 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:20 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:21 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:21 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:21 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:21 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:21 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:21 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:22 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:22 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:22 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:22 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:22 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:22 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:23 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:18 2004 Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:23 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:23 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:24 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:24 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:24 chennai ppp[640]: tun0: Timer: dial timer[0x80b7d44]: freq = 0.10s, next = 0.00s, state = running Jun 21 17:23:24 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:24 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:24 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:24 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:24 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:24 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:24 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:24 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:24 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:24 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:24 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:24 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:24 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:24 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:24 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:25 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:25 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:25 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:25 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:25 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:25 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:25 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:26 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:26 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:26 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:26 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:26 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:26 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:27 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:27 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:27 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:27 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:27 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:27 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:28 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:28 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:28 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:28 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:28 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:28 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:24 2004 Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:29 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:29 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:29 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:29 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:29 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:29 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:29 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:29 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:30 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:30 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:30 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:30 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:30 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:30 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:30 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:31 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:31 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:31 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:31 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:31 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:31 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:32 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:32 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:32 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:32 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:32 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:32 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:33 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:33 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:33 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:33 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:33 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:33 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:29 2004 Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:34 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:34 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:34 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:34 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:34 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:34 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:34 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:34 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:35 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:35 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:35 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:35 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:35 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:35 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:35 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:36 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:36 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:36 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:36 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:36 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:36 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:37 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:37 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:37 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:37 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:37 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:37 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:38 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:38 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:38 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:38 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:38 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:38 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:34 2004 Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:39 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:39 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:39 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:39 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:39 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:39 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:39 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:39 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:40 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:40 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:40 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:40 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:40 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:40 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:40 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:41 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:41 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:41 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:41 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:41 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:41 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:42 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:42 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:42 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:42 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:42 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:42 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:43 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:43 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:43 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:43 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:43 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:43 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:39 2004 Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:44 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:44 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:44 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:44 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:44 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:44 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:44 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:44 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:45 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:45 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:45 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:45 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:45 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:45 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:45 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:46 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:46 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:46 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:46 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:46 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:46 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:47 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:47 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:47 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:47 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:47 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:47 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:48 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:48 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:48 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:48 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:48 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:48 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:44 2004 Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:49 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:49 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:49 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:49 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:49 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:49 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:49 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:49 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:50 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:50 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:50 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:50 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:50 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:50 chennai ppp[640]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "BANYAN") Jun 21 17:23:50 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:51 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:51 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:51 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:51 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:51 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:51 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:52 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:52 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:52 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:52 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:52 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:52 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:53 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:53 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:53 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:53 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:53 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:53 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: physical throughput timer[0x80ba068]: freq = 1.00s, next = 0.00s, state = running Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: carrier -> hangup Jun 21 17:23:54 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:49 2004 Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: hangup -> opening Jun 21 17:23:54 chennai ppp[640]: tun0: Timer: timer_Start: Inserting dial timer[0x80b7d44] Jun 21 17:23:54 chennai ppp[640]: tun0: Phase: deflink: Enter pause (0) for redialing. Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: ---- Begin of Timer Service List--- Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: dial timer[0x80b7d44]: freq = 0.10s, next = 0.00s, state = running Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: ---- End of Timer Service List --- Jun 21 17:23:55 chennai ppp[640]: tun0: Chat: deflink: Redial timer expired. Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = NgMkSockNode("", &cs, &ds) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: List of netgraph node ``rl1:'' (id 2) hooks: Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Found orphans -> ethernet Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Connecting netgraph socket .:tun0 -> [4]::tun0 Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 2 = socket(2, 2, 0) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 3223349521, 0xbfbfed50) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(2, 2149607696, 0xbfbfed50) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: timer_Start: Inserting physical throughput timer[0x80ba068] Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: Connected! Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: opening -> dial Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: dial -> carrier Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Waiting for carrier Jun 21 17:23:55 chennai ppp[640]: tun0: Timer: Select returns -1 Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: Signal 15, terminate. Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: carrier -> logout Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: logout -> hangup Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: Disconnected! Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: deflink: Close Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: Connect time: 0 secs: 0 octets in, 0 octets out Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: 0 packets in, 0 packets out Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 17:23:55 2004 Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: deflink: hangup -> closed Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: route_IfDelete (8) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Found ff02:8::/32 fe80:8::208:a1ff:fe4e:f4dc Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: route_IfDelete: Skip it (pass 0) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Found ff02:8::/32 fe80:8::208:a1ff:fe4e:f4dc Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = socket(17, 3, 0) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 148 = write(0, data, 148) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: wrote 148: cmd = Delete, dst = ff02:8::/32, gateway = Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = socket(2, 2, 0) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbff8a0) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbff8a0) Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: bundle: Dead Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: DoLoop done. Jun 21 17:23:55 chennai ppp[640]: tun0: Phase: PPP Terminated (normal). Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: route_IfDelete (8) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = socket(2, 2, 0) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(0, 3223349521, 0xbfbff970) Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = ioctl(0, 2149607696, 0xbfbff970) Jun 21 17:23:55 chennai ppp[640]: tun0: Debug: Radius: radius_Destroy Jun 21 17:23:55 chennai ppp[640]: tun0: ID0: 0 = unlink("/var/run/tun0.pid") --- Gleb Smirnoff wrote: > Please try out this ppp.conf and report results: > > pppoe: > set device PPPoE:rl0 > add default HISADDR > set authname > set authkey > set speed sync > set ctsrts off > enable lqr > set cd 5 > set dial > set login > set redial 0 0 > set reconnect 10 0 > set log Phase Chat LCP IPCP CCP tun command > disable deflate pred1 acfcomp protocomp pap > deny deflate pred1 acfcomp pap > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 > 0.0.0.0 > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sun Jun 20 15:48:56 2004 Return-Path: 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 E324016A4CE for ; Sun, 20 Jun 2004 15:48:56 +0000 (GMT) Received: from web60801.mail.yahoo.com (web60801.mail.yahoo.com [216.155.196.64]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D6AC43D49 for ; Sun, 20 Jun 2004 15:48:56 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040620154855.79819.qmail@web60801.mail.yahoo.com> Received: from [61.11.80.24] by web60801.mail.yahoo.com via HTTP; Sun, 20 Jun 2004 08:48:55 PDT Date: Sun, 20 Jun 2004 08:48:55 -0700 (PDT) From: Yohan To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 21 Jun 2004 12:07:14 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re; PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 15:48:57 -0000 where do i post questions regarding PPPoE on FreeBSD Thanks and regards Yohan --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 11:21:46 2004 Return-Path: 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 5649116A4CE for ; Mon, 21 Jun 2004 11:21:46 +0000 (GMT) Received: from hotmail.com (bay13-dav4.bay13.hotmail.com [64.4.31.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C6843D4C for ; Mon, 21 Jun 2004 11:21:46 +0000 (GMT) (envelope-from abahnihy@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 21 Jun 2004 04:22:17 -0700 Received: from 82.201.154.208 by bay13-dav4.bay13.hotmail.com with DAV; Mon, 21 Jun 2004 11:22:17 +0000 X-Originating-IP: [82.201.154.208] X-Originating-Email: [abahnihy@hotmail.com] X-Sender: abahnihy@hotmail.com From: "Ahmed Hamada" To: Date: Mon, 21 Jun 2004 13:54:52 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 21 Jun 2004 11:22:17.0624 (UTC) FILETIME=[02B8B180:01C45782] X-Mailman-Approved-At: Mon, 21 Jun 2004 12:07:14 +0000 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: need help in OPNET!!!!!!!!!! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 11:21:46 -0000 Hi=20 I have the opnet modeler 8.1 only without the library, so when run the = simulation of the NIST models for Ad Hoc, the modeler tell me that there = are some files "C files ( .h)" missed. I think these files must be in = "include" folder that exist in my opnet folder.These files like = "oms_auto_addr_support.h , oms_tan.h , oms_pr.h". So, I need these files (the include folder as all) or the OPNET library = for this modeler 8.1. I think the size of include folder is not large, so please at least = anyone send it to me on abahnihy@gawab.com. Thank you very much. Regads A. H. Bahnihy From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 12:19:53 2004 Return-Path: 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 973AA16A4D0 for ; Mon, 21 Jun 2004 12:19:53 +0000 (GMT) Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C7943D2F for ; Mon, 21 Jun 2004 12:19:53 +0000 (GMT) (envelope-from le@cs.unc.edu) Received: from quartet.cs.unc.edu (quartet.cs.unc.edu [152.2.133.252]) by wren.cs.unc.edu (8.12.10/8.12.10) with ESMTP id i5LCJjbk014633; Mon, 21 Jun 2004 08:19:46 -0400 (EDT) Received: from quartet.cs.unc.edu (localhost.localdomain [127.0.0.1]) by quartet.cs.unc.edu (8.12.11/8.12.11) with ESMTP id i5LCJj7A018626; Mon, 21 Jun 2004 08:19:45 -0400 Received: (from le@localhost) by quartet.cs.unc.edu (8.12.11/8.12.11/Submit) id i5LCJjnd018624; Mon, 21 Jun 2004 08:19:45 -0400 Date: Mon, 21 Jun 2004 08:19:45 -0400 From: Long Le To: freebsd-net@freebsd.org Message-ID: <20040621121945.GB18534@quartet.cs.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Blasting UDP packets on a 1-Gbps link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 12:19:53 -0000 Hi all, I've been trying to get iperf to blast UDP packets for 10 minutes on a 1-Gbps link. However, iperf stops after a few seconds and complains that it can't write to the socket because no buffer space is available. 'netstat -m' shows that there are lots of mbufs available. I modified iperf source code to set the socket's send buffer to 200000 bytes (*) but it didn't really help much. In another attempt, I modified iperf source code such that it would not quit after failing to write to the socket. However, this caused iperf to hang. I use iperf 1.7.0 and FreeBSD 4.5. The machine I am using has a 1-GHz CPU and 1 Gbytes of memory. I could try to write my own program to blast UDP packets but would prefer to use available software if possible. Has anyone successfully blasted UDP packets on a 1-Gbps link for a sustained period and can anyone give me some useful hints? Thanks, Long (*) Apparently, iperf doesn't have an option to set the socket buffer for UDP sockets. And there seems to be a limit that doesn't allow to set a larger buffer size than around 200000 bytes (this is not related to iperf but FreeBSD in general). From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 13:04:41 2004 Return-Path: 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 C1C3116A4CE for ; Mon, 21 Jun 2004 13:04:41 +0000 (GMT) Received: from web60802.mail.yahoo.com (web60802.mail.yahoo.com [216.155.196.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 2947543D45 for ; Mon, 21 Jun 2004 13:04:41 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621130432.91505.qmail@web60802.mail.yahoo.com> Received: from [220.226.14.59] by web60802.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 06:04:32 PDT Date: Mon, 21 Jun 2004 06:04:32 -0700 (PDT) From: Yohan To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20040621120725.GA73889@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 13:04:41 -0000 Gleb, I sort of anticipated you would require the tcpdump output. Its attached below. The Windows driver README is the furthest below. The windows connection works flawlessly but i wouldnt want to use windows unless its the last resort. The instructions by the isp for linux are as follows ... FOR LINUX ---------- For redhat 7.2 or higher Installing using RPM Copy RPM rp-pppoe-3.5-1.i386.rpm in the root directory. Execute the command rpm -Uvh rp-pppoe-3.5-1.i386.rpm To configure /usr/sbin/adsl-setup To connect /usr/sbin/adsl-start To stop/disconnect /usr/sbin/adsl-stop To install GUI based PPPoE rpm -Uvh rp-pppoe-3.5-1.i386.rpm rp-pppoe-gui-3.5-1.i386.rpm To connect GUI based PPPoE /usr/bin/tkpppoe Thanks and Regards Yohann Output of tcpdump -e -i rl1 17:47:58.383405 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.22 tell 172.16.40.17 17:48:04.718691 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:04.732330 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:04.732347 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:06.724827 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:09.603009 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.23 tell 172.16.40.17 17:48:09.875429 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:09.889090 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:09.889105 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:11.884908 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:15.035656 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:15.049217 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:15.049232 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:17.044982 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:20.195576 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:20.209343 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:20.209357 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:20.822597 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.23 tell 172.16.40.17 17:48:22.205063 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:25.355677 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:25.369222 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:25.369237 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:27.365137 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:30.515748 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:30.529471 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:30.529486 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:32.042197 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.23 tell 172.16.40.17 17:48:32.525219 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:35.675836 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:35.689479 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:35.689494 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:37.685297 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:40.847982 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:40.861730 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:40.861764 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:42.855374 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:43.261813 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.24 tell 172.16.40.17 17:48:46.006119 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:46.019730 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:46.019745 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:48.015450 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:51.166074 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:51.179734 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:51.179750 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:53.175528 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:54.481397 0:4:e6:2:44:12 Broadcast arp 64: arp who-has 172.16.40.24 tell 172.16.40.17 17:48:56.326122 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:48:56.339611 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:48:56.339626 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:48:58.335606 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:49:01.486231 0:8:a1:5f:b5:4b Broadcast 8863 60: PPPoE PADI [Host-Uniq UTF8] 17:49:01.499862 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] 17:49:01.499878 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] 17:49:03.495683 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] RASPPPOE PPP over Ethernet Protocol for Windows 2000/XP/.NET (If you are using Windows 95/98/98SE/ME, please click here) (If you are using Windows NT 4.0, please click here) written by Robert Schlabbach Licensed to Banyan Networks. Version 0.98, October 3rd, 2002 Contents 1. Introduction 2. Installing the PPP over Ethernet Protocol 3. Creating PPP over Ethernet Dial-Up Connections 4. Removing the PPP over Ethernet Protocol 5. Advanced Protocol Features 6. Troubleshooting 7. Known Issues 8. Revision History 1. Introduction Welcome to RASPPPOE, a PPP over Ethernet (short: PPPoE) implementation for Windows 95, 98, 98SE, ME, NT 4.0, 2000, XP and .NET. PPPoE as a method for establishing PPP connections through Ethernet adapters is described in RFC 2516 and is used by your broadband service provider to allow authentication and maintain the familiar "dial-up experience" when connecting to the Internet through a broadband modem. Although there are other PPPoE implementations for Windows, this one still has its unmatched strong points: * Seamless integration into the operating system. This protocol makes Ethernet network adapters appear as "modems", allowing PPPoE to be easily used within the standard Dial-Up Networking framework. * Compatibility: This protocol supports Internet Connection Sharing (including on-demand dialing), power management (Standby and Hibernate) as well as multiprocessor systems. * Completeness: This protocol can not only act as a PPPoE Host (client), but also as an Access Concentrator (server), fully implementing RFC 2516. * Compactness: The complete protocol is less than 250 KB. Yet no concessions were made in the implementation. To install this protocol, please follow the installation instructions carefully. If you have problems using it, see Troubleshooting for help. If you are successfully using this protocol, you can check if you find any of the advanced features useful. You may also want to know about the known issues. Users upgrading from a previous version of this protocol should check the Revision History to find out what changed. License This driver, installation files and documentation is all Copyright (C) 2000-2002 by Robert Schlabbach. All rights reserved. This version of RASPPPOE is licensed to: Banyan Networks, India Redistribution to third parties is strictly prohibited, unless you have a license agreement which permits the limited distribution of this software to end users. 2. Installing the PPP over Ethernet Protocol To install RASPPPOE, simply open the media on which you received this software in Explorer and double-click the file PPPOE098.EXE (or PPPOE098_IA64.EXE if you are using an Intel Itanium 64-bit system) to run the automated installer, which guides you through the installation process to your first broadband connection. Only if the automated installer should fail to work properly on your machine, you need to do a manual installation. To install the protocol manually, follow these steps: * WARNING: You are about to install a driver. Since any driver installation poses a non-zero risk of crashing your operating system, you are advised to save your work and close all running applications before proceeding. * Since you are about to install a driver, you will need administrative privileges to perform the installation. If you are logged on to a user account, log off and log on to an account with administrative privileges before proceeding. * If there is already a different PPPoE implementation installed on your machine, it might get confused by the PPPoE traffic generated by this protocol. This protocol was written to peacefully coexist with other PPPoE implementations on the same machine, but other programmers may not have been as thoughtful. Thus, it is recommended (but not required!) that you uninstall any other PPPoE implementations and reboot your machine before proceeding. * If you already have a previous version of this PPP over Ethernet Protocol installed, you must first remove the old version. See Removing the PPP over Ethernet Protocol for details. * Create a temporary folder on your hard disk and copy the file PPPOE098.EXE (or PPPOE098_IA64.EXE if you are using an Intel Itanium 64-bit system) to it. * Click the Start button on the taskbar and select Run... to bring up the Run dialog box. * Click the Browse... button, browse to the temporary folder you create, select PPPOE098.EXE (or PPPOE098_IA64.EXE if you are using an Intel Itanium 64-bit system) and click Open. * Back at the Run dialog box, edit the name of the program to run and append a space character followed by /X to the name. * Click OK. This will extract the installation files to your temporary folder. You should check in Explorer if the following required files (among others, which are not used on Windows 2000/XP/.NET) were correctly extracted: NETPPPOE.INF, RASPPPOE.INF, RASPPPOE.DLL, RASPPPOE.EXE and RMSPPPOE.SYS. NOTE: Explorer may be configured to hide DLL and SYS files, so it may not display these files. * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Go to the menu and select View then Details to get a detailed view of the network connections on your machine. * You should find one or more Local Area Connection objects. Locate the one for the network adapter connected to your broadband modem (you should be able to tell by the name in the Device Name column), right-click it and select Properties. * In the properties dialog box, click the Install... button. * In the Select Network Component Type window, select Protocol and click the Add... button. (Note: It could take a few seconds for the following window to come up.) * In the Select Network Protocol window, click the Have Disk... button. * In the Install From Disk window, either type the name of your temporary installation directory or click the Browse... button to navigate to it (it does not matter which of the INF files you select, Windows will automatically pick the right one later). Then click the OK button. A new window opens, offering the PPP over Ethernet Protocol for installation. Click OK to start installing the protocol. * During installation, a window titled Digital Signature Not Found (Windows 2000) or Hardware Installation (Windows XP/.NET) may come up several times (typically four times per installed network adapter), warning you that the driver has no digital signature or Windows Logo. Make sure you click "Yes" (Windows 2000) or "Continue Anyway" (Windows XP/.NET) every time you are prompted to allow successful installation of the protocol. * Back at the Local Area Connection Properties window, click Close to close the window. Note: If you have a network adapter dedicated to your broadband modem, it is recommended that you first clear the checkboxes for all other components listed and leave only PPP over Ethernet Protocol checked. * If you have more than one network adapter in your system, you may want to disable the PPP over Ethernet Protocol for all adapters but the one your broadband modem is actually connected to. To do this, bring up the properties of each network adapter you want to disable the protocol for and clear the checkbox next to PPP over Ethernet Protocol in the listed components. BEWARE: If you accidentally disable the protocol for the network adapter you want to connect through, simply re-checking the checkbox, even if you do so immediately, may not be enough to make the protocol functional on that network adapter again. See Known Issues for a more detailed explanation and possible workarounds. * The protocol is now fully functional, but you still need to create a dial-up connection to use it. See the next section for details. 3. Creating PPP over Ethernet Dial-Up Connections If you installed the protocol with the automated installer, it already created a dial-up connection for you. If you installed the protocol manually, you can create a PPP over Ethernet dial-up connection with the Dial-Up Connection Setup application provided with the protocol, which creates dial-up connections with all the correct settings at the click of a button. * Click the Start button on the taskbar and select Run... to bring up the Run dialog box. * Type RASPPPOE in the edit field and click the OK button to run the Dial-Up Connection Setup application. * If the application quits with an error message, follow the advice it gives. * A dialog box comes up with a combo box labeled Query available PPP over Ethernet Services through Adapter: at the top. Select the network adapter your broadband modem is connected to from the list. If the protocol is only operating on one network adapter, the box will be grayed out as there is no choice to make. * Generally, it is recommended that you create a connection for an adapter, not for a specific service, so that it continues to work even if your service provider changes the server or service name. To do this, simply click the Create a Dial-Up Connection for the selected Adapter button now. Shortly afterwards, a shortcut to the new dial-up connection named Connection through Adapter Name should show up on your desktop. * If you want to create a connection for a specific service, click the Query Available Services button. The application will send out a query for offered services and display the result in the list view below. If an error message is displayed, see Troubleshooting for help. Otherwise, select the desired service and the button below will change to Create a Dial-Up Connection for the selected Service. Click the button to create a connection for this service. Shortly afterwards, a shortcut to the new dial-up connection named Connection to Service Name at Access Concentrator or Connection to Access Concentrator (if the connection is for the default service) should show up on your desktop. * After you have created the connection(s) you need, click the Exit button to quit the application. * Double-click the desktop icon for the dial-up connection you created. * In the Connect Connection Name window, enter your user name and password if your service provider requires authentication. * Click on the Dial button. If all goes well, you should be connected to the Internet almost instantly. If not, see Troubleshooting. 4. Removing the PPP over Ethernet Protocol If the protocol was installed with the automated installer, it was added to the list of installed programs and can be conveniently removed through Control Panel: Click on the Start button, select Settings then Control Panel to open the Control Panel window. In that window, double-click Add/Remove Programs. In the upcoming dialog, locate the entry PPP over Ethernet Protocol 0.98, select it and click Change/Remove. The automated installer will guide you through the removal process. If the protocol was installed manually or you cannot find the protocol in the list of installed programs, you need to remove the protocol manually. To do this, follow these steps: * WARNING: You are about to remove a driver. Since any driver removal poses a non-zero risk of crashing your operating system, you are advised to save your work and close all running applications before proceeding. * Since you are about to remove a driver, you will need administrative privileges to perform the removal. If you are logged on to a user account, log off and log on to an account with administrative privileges before proceeding. * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * First, you may want to remove all dial-up connections you created for connecting through this protocol. To do so, right-click each of the dial-up connections you created for this protocol and select Delete. If you had created any shortcuts to these dial-up connections on your desktop, right-click them and select Delete as well. * If you are running Windows 2000, you must first unbind the protocol from all network adapters to ensure that it is unloaded from memory. This step is not necessary if you are running Windows XP/.NET. BEWARE: Do NOT do this if you currently have a RASPPPOE version prior to 0.95 installed as these versions may CRASH the operating system when unbinding the protocol from the last network adapter. In that case, skip the next step and reboot after uninstalling the protocol to remove it from memory. * To unbind the protocol from all network adapters, right click each Local Area Connection, select Properties and clear the checkbox next to PPP over Ethernet Protocol and close the properties dialog with the OK button. After clearing the last checkbox, the protocol is unloaded from memory * Right-click any Local Area Connection and select Properties. * In the list of components, select PPP over Ethernet Protocol and click Uninstall. * A dialog box comes up asking you to confirm the removal. Make sure that you are really about to uninstall the PPP over Ethernet Protocol and click Yes. * Back at the Local Area Connection Properties window, click Close to close the window. Note: The protocol is not completely removed from your machine at this point due to shortcomings of Windows, which prohibit a complete removal. The pieces that are left behind are not harmful in any way, but if you want to get rid of every little bit of this protocol, here is what's left behind: * If you are running Windows 2000, the protocol's Notify Object, named RASPPPOE.DLL, is left behind in your \WINNT\SYSTEM32 directory. You can safely delete it at this point. Automatic deletion fails due to a bug in Windows 2000 (see Known Issues). In Windows XP/.NET, this file is automatically deleted. * In your \WINNT\INF directory, the protocol's INF file and its precompiled version is left behind, named oem#.inf and oem#.PNF, respectively. "#" stands for a number that varies with the number of third party drivers you installed on your machine. This means that you will have to identify the INF by loading each of your oem#.inf files into a text editor, e.g. NOTEPAD. The PPP over Ethernet Protocol INF identifies itself as such right in the second line of the file. Once you have identified the INF, delete it and the corresponding PNF file as well. This is not a bug, but Microsoft's design. These files cannot be removed automatically due to the varying name. * Even if the protocol has been completely removed from hard disk and memory, the dial-up devices that were exposed by it will be shown in the properties of any dial-up connection until you reboot. This is a bug in Windows (see Known Issues). 5. Advanced Protocol Features This section covers the advanced features of the protocol. Average users should be perfectly happy with the default settings, although specifying the link speed to display may be of interest. Users having problems with VPN software might try if overriding the MTU reported by the protocol helps. Users with flat rate Internet access may be interested in making the connection "always on". If you are interested in using the protocol's server capability, please see Enabling the protocol to act as a PPPoE Access Concentrator. To bring up the protocol settings for an adapter: * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Locate the Local Area Connection (Note well: not your dial-up connection entry!) of the adapter the protocol settings of which you wish to modify, right-click it and select Properties. * In the list of components used by this connection, select PPP over Ethernet Protocol (BEWARE: You must not click on the checkbox, as this will disable the protocol for this adapter! Make sure you click on the protocol name) then click the Properties button to bring up the protocol's settings for this adapter. * Changes to the protocol settings take effect when you close the PPP over Ethernet Protocol Properties window with the OK button unless noted otherwise. The General tab offers the following settings: 5.1 Limit TCP MSS Maximum Segment Size (MSS) Option When using Internet Connection Sharing, the client machines are completely unaware of the packet size restrictions imposed by the nature of PPP over Ethernet (in contrast to e.g. modem or ISDN connections, which allow passing arbitrarily sized packets). Typically, a client assumes that packets of up to 1500 bytes can be passed and thus indicates a Maximum Segment Size of 1460 bytes (1500 bytes minus 40 bytes for the TCP and IP headers) when opening a TCP session, resulting in either side of the connection sending packets up to 1500 bytes in size, too large to pass through a PPP over Ethernet connection, which can only pass packets up to 1492 bytes in size. These oversized packets are then often silently dropped at either side of the PPP over Ethernet connection, leading to delays or hangs when accessing the Internet from a client. To work around this problem, this option makes the protocol scan all network packets it sends and receives for the TCP Maximum Segment Size (MSS) option and, if a value greater than either the default (1492) or the overridden MTU minus 40 for the IP and TCP headers (i.e. 1452 in case of the default MTU) is found, change it to this value, recalculate the TCP checksum and pass the modified packet. This option is enabled by default. If you are not using Internet Connection Sharing, you can disable this option to save a little (very little) CPU power, although leaving it enabled has no negative side effects. 5.2 Override Maximum Transfer Unit By default, the protocol will report an MTU of 1492 bytes, the maximum possible for PPP over Ethernet. However, you can use this option to override the MTU initially reported by the protocol. Making the protocol initially report a lower MTU was found to help with certain VPN software packages which "blindly" add their own overhead without paying any respect to the MTU reported by the driver, making the network packets too large to pass through a PPP over Ethernet connection. Check the Override Maximum Transfer Unit checkbox and type the MTU the protocol should report in the Maximum Transfer Unit (MTU) edit box. The valid range is 576 through 1492 bytes. Reducing the MTU by 32 bytes to 1460 should generally suffice to make misbehaved VPN software work. Note: Regardless of this setting, the protocol will always send and receive packets of up to 1492 bytes. Only the MTU initially reported by the protocol (the MaxFrameSize value in response to the OID_WAN_GET_INFO request) and, if enabled, the TCP MSS option limit are affected by this setting. For any changes to this setting to take effect, you need to disable and re-enable the Local Area Connection for the corresponding network adapter once, or reboot. NOTE: This option will only "stick" if you enter an MTU other than 1492. If you only check the checkbox, but leave the MTU at 1492, the protocol will recognize the default value and clear the checkbox the next time you open the properties dialog, because the MTU was not actually overridden. 5.3 Number of lines (WAN endpoints) The protocol is capable of running several simultaneous PPP over Ethernet sessions through one adapter. This feature will probably be very rarely - if ever - needed. To allow this, you can configure the number of WAN endpoints (dial-up devices) the protocol exposes for a network adapter. The default is 1, and up to 10 WAN endpoints can be configured. This setting requires a reboot to take effect. The Advanced tab offers the following settings: 5.4 Specify Link Speed By default, the protocol will report the speed of the network adapter you are connecting through as the speed of a dial-up connection you make through it, as it cannot find out the actual speed of your broadband modem. However, you can specify the connection speed the protocol should report for connections through a specific adapter. To do this, check the Specify Link Speed checkbox and type the link speed the protocol should report in the Link Speed (kbps) edit box, in kilobits per second. If you want to revert to displaying the adapter's link speed, clear the Specify Link Speed checkbox. Note: This setting has absolutely no effect on the network traffic through this adapter; it is purely a cosmetic setting. This setting takes effect the next time you establish a PPP over Ethernet connection. 5.5 Event Logging options The protocol can inform you about informational events, warnings and errors during operation by logging events to the System event log. By default, the protocol logs all types of events, which should result in no log entries during flawless operation. If you find the event log flooded with repeated entries despite flawless operation, you can disable logging that type of event by clearing the corresponding checkbox. Clearing all checkboxes prevents the protocol from logging any events. * Log Informational Events will log any vendor-specific information received. * Log Warnings will log non-fatal warnings that do not necessarily prevent successful operation. * Log Errors will log fatal errors that prevent correct function of the protocol. You use Event Viewer to view any events logged by this protocol: * Right-click the My Computer icon on your desktop and select Manage to bring up the Computer Management window. * In the tree on the left-hand side, expand the Event Viewer branch, select the System sub branch and press F5 to refresh the view on the right-hand side. Look for log entries from source RMSPPPOE there. * To get a detailed description of a logged event, double click the event in the view on the right-hand side. NOTE: If you are using another PPP over Ethernet software on the same machine, you will find the event log flooded with Warnings from source RMSPPPOE that it received a PPPoE packet for an unknown session. To fix this, either use solely this protocol on the machine, or disable the Log Warnings option as described above. Beyond these settings, the protocol offers the following possibilities: 5.6 Making a dial-up connection "always on" Users who enjoy flat rate Internet access may find it desirable to turn their connection into an "always on" connection that is established once when the machine boots (before any user logs in) and kept until the machine is shut down. To make your dial-up connection "always on", follow these steps: * If your service provider requires authentication, make sure you have saved the password by checking the Save Password checkbox in the Connect Connection Name window and connecting at least once. * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Locate the Dial-Up connection you created for PPP over Ethernet, right-click it and select Properties. * Select the Options tab and clear all checkboxes under Dialing options. * Under Redialing options, set Idle time before hanging up: to never and check the Redial if line is dropped checkbox. * Click OK to save the changes. * Now click the Start button, select Settings then Control Panel to open the Control Panel window. * In the Control Panel window, double-click Scheduled Tasks. * In the Scheduled Tasks window, double-click Add Scheduled Task. * On the welcome screen of the Scheduled Task Wizard, click Next. * At the program selection step, click Browse... and browse to your WINNT\System32 directory (Windows 2000) or to your Windows\System32 directory (Windows XP/.NET). * Type RASPHONE.EXE (note the spelling!) in the File name: edit box or locate it in the directory and select it and click Open. * Make up a name for this task and under Perform this task: select When my computer starts. Click Next. * Enter your password. Note: The task must be run under the same account which the dial-up entry was created under. * At the final step, make sure that Open advanced properties for this task when I click finish is checked and click Finish. * In the advanced properties, edit the Run: edit box and append the command-line parameters " -d "Connection Name"". * Go to the Settings tab and clear all checkboxes on that page. * Click OK to close the task's properties. * Finally, you need to make a little registry change to prevent Windows from disconnecting when a user logs on and off again: Run REGEDIT and navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Then right-click the right-hand pane, select New -> String Value, name the value KeepRasConnections and set it to 1. * Reboot. Windows will establish the connection automatically and keep it until you shut the machine down. * NOTE: The connection will not be properly terminated when shutting the machine down or rebooting. This can cause problems with service providers who take very long to detect such a dropped connection and limit the number of concurrent connections. See Known Issues for further details. 5.7 Addressing a specific Service and/or Access Concentrator In most cases, there is no need to address a specific Service or Access Concentrator. But should you have a need to do so, you can use the phone number field of your dial-up connection to specify a Service, Access Concentrator or both. The following phone number formats are possible: 1. Blank or "0": The protocol will connect to the default Service of the first Access Concentrator that replies to the connection request. 2. "Service-Name": The protocol will connect to the first Access Concentrator that replies offering the requested Service. 3. "Access-Concentrator\": The protocol will connect to the default Service of the named Access Concentrator. 4. "Access-Concentrator\Service-Name": The protocol will connect to the requested Service of the named Access Concentrator. The RASPPPOE application uses format A for the phone number if you create a connection for an adapter and format C or D if you create a connection for a specific service. 5.8 Enabling the protocol to act as a PPPoE Access Concentrator The protocol is able to act as a PPPoE Access Concentrator (server). This feature can be used for testing purposes, but also offers a future potential for advanced provider services like instant messaging or instant e-mail even for users who are offline at the time a message is received. The server capability is fully integrated with the operating system's Incoming connections component. No PPPoE-specific configuration is needed. The protocol uses the current Computer Name as the Access Concentrator Name and offers any Service Name requested by a client. Note that the protocol will not offer any services until you explicitly enable its dial-up devices to accept incoming connections. To do this, follow these steps: * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Double-click Make New Connection and click Next. * Select Accept incoming connections and click Next. * The list of Connection devices should contain the names of the network adapters in your system. Check all network adapters through which you want to accept incoming connections and click Next. * Choose whether you want to allow virtual private connections and click Next. * Select the user accounts which should be allowed to connect to your machine and click Next. * Select the networking components you want to enable for the incoming connections. Note that PPP over Ethernet Protocol will also be shown in this list, but its checkbox will be grayed out. * If you enable the Internet Protocol (TCP/IP) for incoming connections, you may also want to click on the Properties button to define the IP addresses to use for the incoming connections. * Click Next and then click Finish to finish the wizard and enable the server. The Network and Dial-up Connections window will now contain an additional item named Incoming Connections. * If you want to disable the server only for a specific network adapter, right-click the Incoming Connections item, select Properties, clear the checkbox next to the name of that network adapter and click OK to stop the protocol from offering services on that network adapter. * If you want to disable accepting any connection on your machine (not only through this protocol, but through all dial-up devices installed on your machine), right-click the Incoming Connections item, select Delete and confirm to stop the protocol from offering any services. For further help on using Incoming Connections, please refer to the operating system's documentation on this topic. 6. Troubleshooting This section helps you with possible problems you might encounter during the installation and use of the protocol. 6.1 Right after installation of the protocol, the Local Area Connection properties window lists no components This happens when the protocol could not be properly installed and appears to be a bug in Windows. Clicking the OK button at this point gives an error message that no components are installed. Click the Cancel button to close the properties dialog and then re-open it again to get the list of components back. Select PPP over Ethernet Protocol in the list, click the Uninstall button and confirm to remove the bad installation. Before you make another installation attempt, make sure that Windows is not set to block the installation of unsigned drivers: * Right-click the My Computer icon on your desktop and select Properties. * Select the Hardware tab and click the Driver Signing... button. * Make sure that File signature verification is not set to Block - Prevent installation of unsigned files. * Change the setting if required and click OK to put the change into effect. If File Signature verification is set to Warn - Display a message before installing an unsigned file, make sure you click "Yes" (Windows 2000) or "Continue Anyway" (Windows XP/.NET) every time in the warning dialog box that comes up during the protocol installation. Clicking any other button even just once will prevent proper installation and result in the same problem. If you still cannot install the protocol properly, do the following: Locate the file SETUPAPI.LOG in your Windows directory and delete it. Make another installation attempt (which will probably fail as well). Then check your Windows directory again for the file SETUPAPI.LOG and load it into a text editor, e.g. NOTEPAD. The contents of this file should give you some hints abut the cause of the installation failure. 6.2 RASPPPOE application does not list the desired adapter First, be aware that you can use this protocol only on Ethernet adapters. As PPP over Ethernet only works over Ethernet, the protocol will only bind itself to Ethernet adapters (NdisMedium802_3). Adapters that do not support this medium type (e.g. internal or USB broadband modems that do not expose a standard Ethernet interface through their driver) are not supported by this protocol. You should make sure that the Local Area Connection for the adapter in question is enabled: * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Go to the menu and select View then Details to get a detailed view of the network connections on your machine. * You should find one or more Local Area Connection objects. Locate the one for the network adapter in question, and check the Status column. * If the Status is disabled, right-click the Local Area Connection and select Enable. * If enabling fails, check in Device Manager for possible problems with this adapter. * If you successfully enabled the adapter, re-run the RASPPPOE application and check whether the adapter is listed now. If the adapter still does not show up, make sure that the protocol is enabled for the adapter in question: * Right-click the Local Area Connection of the adapter in question and select Properties. * In the properties dialog box, check the list of installed components. Make sure that the checkbox next to PPP over Ethernet Protocol is checked. * If the checkbox is clear, check it. You may be prompted about the digital signature again. Make sure you click "Yes" (Windows 2000) or "Continue Anyway" (Windows XP/.NET) every time you are prompted. * If the Local Area Connection properties dialog box lists no components now, see above. * Click OK to close the Local Area Connection properties dialog box. * Right-click the Local Area Connection in the Network Connections window and select Disable. * Right-click the Local Area Connection again and select Enable. * Re-run the RASPPPOE application and check if the adapter is listed now. If the adapter still does not show up, try the following: * Right-click the Local Area Connection in the Network Connections window and select Disable. * Right-click the Local Area Connection again and select Enable. * The RASPPPOE application should list the desired adapter now. 6.3 RASPPPOE application reports "RASPPPOE - No Service Offers Received" when querying available services This error message means that the protocol did not receive any response from your service provider. You should check the following things in order: 1. Check if your broadband modem has successfully established a link with its counterpart. Most DSL modems have a Sync LED on them which indicates this status. If your modem has such an LED and it indicates that the link is down, contact your service provider for assistance. 2. Check in Device Manager if the network adapter your broadband modem is connected to is enabled and working properly. 3. Check if your network adapter is correctly configured: Bring up Device Manager, select the network adapter your broadband modem is connected to and click Properties. In the Properties window, select the Advanced tab, look through the options and make sure that the correct Line Speed and duplex mode is selected (most DSL modems only support 10Mbps half duplex mode). If your network adapter has several connectors at the back, make sure the correct connector is selected, which is most likely Twisted Pair (TP). 4. Check that the cable connecting your broadband modem to your network adapter is properly attached and of the correct type. Note that broadband modems typically have a "crossed" connector on them, so you will need a straight cable to connect it directly to a network adapter, while you need to use a crossed cable or use an uplink port to connect it to a hub or switch. 5. Check with your service provider whether they currently have a service outage. 6.4 Connection attempt fails with "Error 797: The connection failed because the modem (or other connecting device) was not found." This can be the result of unbinding the protocol from an adapter and then re-binding it, which may not have taken effect (see Known Issues). Follow these steps to put the change into effect: * If you are running Windows 2000, right-click the My Network Places icon on your desktop and select Properties to bring up the Network and Dial-up Connections window. * If you are running Windows XP/.NET, click the Start button, select Control Panel, then click Network and Internet Connections and then click the Network Connections control panel icon to bring up the Network Connections window. * Go to the menu and select View then Details to get a detailed view of the network connections on your machine. * You should find one or more Local Area Connection objects. Locate the one for the network adapter in question, right-click it and select Disable. * Right-click the Local Area Connection again and select Enable. * Make another connection attempt and see if it works. If that did not help, the dial-up connection you created may be configured to connect through a "ghost" dial-up device that no longer exists. Do the following to remedy this: * Right-click the dial-up connection that failed to connect and select Properties. * In the Connect using: list view, take a close look at the name of the dial-up device that is checked. A "ghost" dial-up device has the name format ISDN channel - Adapter Name (xx), while a correct entry is of the format ISDN channel - Adapter Name, i.e. the extra (xx) identifies a "ghost" device. * If the checked device is indeed a "ghost" device, clear it, look through the list for the correct dial-up device and check that one instead. * Make another connection attempt. 6.5 Connection attempt fails with "Error 678: There was no answer." First, you should check whether you can get any reply from your service provider with the Dial-Up Connection Setup application provided with the protocol: * Click the Start button on the taskbar and select Run... to bring up the Run dialog box. * Type RASPPPOE in the edit field and click the OK button to run the Dial-Up Connection Setup application. * If the application quits with an error message, follow the advice it gives. * A dialog box comes up with a combo box labeled Query available PPP over Ethernet Services through Adapter: at the top. Select the network adapter your broadband modem is connected to from the list. If the protocol is only operating on one network adapter, the box will be grayed out as there is no choice to make. * Click the Query Available Services button. If an error message is displayed, continue here for further help. * If the list view shows one or more offered services and you had tried to connect to a specific Service and/or Access Concentrator, make sure the one you had tried to connect to is listed. If you find your service provider has changed the Service Name and/or the Access Concentrator name, simply create a new connection with the new name(s) or edit the Phone number field in your existing dial-up connection accordingly. * Click the Exit button to quit the application. If you do not want to connect to a specific Service and/or Access Concentrator, make sure the Phone number field of your dial-up connection is really completely blank. 6.6 Connection attempt fails with "Error 651: The Modem (or other connecting device) has reported an error." If you have not rebooted since the installation of the protocol and the machine was in Standby mode since, this is a known issue. Simply click the Redial button. The second connection attempt will proceed without this error. You'll get it once each time after waking the machine from Standby until you reboot the machine. Then the protocol will work flawlessly even right after waking the machine. 6.7 Connection is successfully established, but some (or all) Internet websites do not load properly This is usually a sign of an MTU problem. You should determine the Path MTU to the problem site(s) (Note: The method described here does not work with all servers. If you get no reply at all from a server or a number below 548, you cannot determine the Path MTU to this server): Connect, open a Command Prompt and run ping -f -l xxxx Address Where Address is the name or IP address of the server you have problems accessing. For xxxx, start with 1464 and lower the number until you get a reply. Then add 28 to the highest number at which you get a reply. The result is the Path MTU. Example: You start getting replies at ping -f -l 1372 Address. The Path MTU is 1372 + 28 = 1400 bytes in this case. Normally, the Path MTU to all servers should be 1492. However, some service providers appear to have a configuration problem which reduces the Path MTU. If you determine a Path MTU lower than 1492 to several (or all) servers on the Internet, you should enable the MTU override option and set it to the Path MTU you determined. After that setting has taken effect, all sites with a Path MTU greater than or equal to the value you set should load properly. 6.8 Cannot get the Routing and Remote Access Service (RRAS) to work with the PPPoE connection A common cause of this is that RRAS was incorrectly set up to use a network adapter for Internet access, which bypasses the PPP over Ethernet Protocol. When setting up RRAS with the configuration wizard, you are first presented with a list of network adapters in your system. Do not select any of these entries. Instead, look for an option to create an on-demand dial connection below and select that. A few steps later, an on-demand dial wizard should come up, which offers a list of dial-up devices, in which you should find an ISDN channel with the name of your network card. Select this device to make RRAS work with your PPPoE connection. If the list of dial-up devices does not contain the mentioned device, you may first have to enable it for use with RRAS. Look through the RRAS Management Console for a list of ports. This list should contain the mentioned dial-up device. You can right-click the device in this list and find an option to enable it for use with RRAS. 6.9 The "Override Maximum Transfer Unit" option does not remain checked This option will only "stick" if you enter an MTU other than 1492. If you only check the checkbox, but leave the MTU at 1492, the protocol will recognize the default value and clear the checkbox the next time you open the properties dialog, because the MTU was not actually overridden. 6.10 The System Event Log contains "Received a PPPoE Session packet for an unknown session" warnings This warning merely means that the protocol received a PPPoE packet it could not attribute to any of its connections and is usually not a sign of any malfunction. One possible cause of this is your service provider sending one more packets after the connection has been terminated. This can also be caused by using another PPPoE implementation on the same machine. In that case, the System Event Log may end up being flooded with these warnings. You can prevent this by disabling the Log Warnings checkbox in the protocol's Event Logging options. 7. Known Issues This section documents known issues with the protocol. 7.1 Binding/unbinding the protocol to/from a network adapter takes effect immediately and cannot be canceled When you bring up the Properties of a Local Area Connection and toggle the checkbox next to PPP over Ethernet Protocol, the binding change takes effect immediately, i.e. it is not deferred until you click OK or Cancel, and you cannot cancel the change. This is merely annoying when accidentally checking the checkbox, as you can clear it again with no harm done. However, if you accidentally clear the checkbox, simply re-checking the checkbox may not be sufficient to make the protocol work on that adapter again, due to this known issue. Background: This protocol is implemented as an NDIS intermediate driver with a different upper edge (ndiswan) than lower edge (ndis4, ndis5). As such, it does not qualify as a filter driver and thus requires its own Notify Object (implemented in RASPPPOE.DLL) to install and remove miniport instances for the bound adapters and to communicate the names of the installed device instances to the protocol portion of the driver via the registry. When the user brings up the connection properties dialog box, the only way for the Notify Object to tell whether the user clicked OK or Cancel is that its ApplyRegistryChanges() and ApplyPnpChanges() member functions are only called in the former case, but not in the latter. So the right thing to do would be install and remove the miniport instance(s) in one of these functions - but that does not work, because a reentrancy check in the Windows network configuration library blocks all calls to INetCfgClassSetup::Install() and INetCfgClassSetup::DeInstall() at that point for fear the developer might have overlooked the possibility that these calls could lead to another invocation of the Notify Object's member functions that requested the installation or removal, which could lead to endless installation loops if the writer of the Notify Object was not smart enough to set a flag to prevent this. This makes it impossible to install and remove miniport instances from these Notify Object member functions. To work around this problem, the PPP over Ethernet Protocol does all installation and removal in the Notify Object's NotifyBindingPath() member function, which is unfortunately called immediately when the user toggles the checkbox. Thus, the change takes effect immediately and cannot be canceled. 7.2 After initial installation, binding the protocol to a network adapter may not take effect If you unbound the protocol from a network adapter by clearing the checkbox next to the PPP over Ethernet Protocol in the Properties of a Local Area Connection, binding the protocol to the network adapter by checking the checkbox again may not take effect, although you get no notification of this. If you unbound the protocol from all network adapters, the first binding you re-enable will take effect, but subsequent ones will not. There are three possible solutions in this situation: 1. Locate the Local Area Connection of the adapter in question, right-click it and select Disable. Then, right-click it again and select Enable. This will make the protocol work again. Note, though, that this temporarily disrupts any other network traffic you might run through this adapter. 2. Click the Uninstall button to remove the protocol completely and then click the Install button to re-install it. After re-installation, you will be able to use the protocol over that adapter immediately without a reboot, but you will see "ghost" dial-up devices in your dial-up connection properties. These will go away when you reboot. See this known issue. 3. Reboot. After the reboot, the protocol will work on this adapter again. Background: After the initial installation, the protocol driver is already running in memory. When the user checks the checkbox next to PPP over Ethernet Protocol, the Notify Object receives notification of a new adapter to bind to and calls INetCfgClassSetup::Install() to install a corresponding miniport device instance - and the Windows network configuration library makes the bad mistake of invoking the protocol driver's ProtocolBindAdapter() function before returning control to the Notify Object. This creates a semi-deadlock situation: ProtocolBindAdapter() needs the name of the installed miniport device instance before exiting, but only the Notify Object can provide that information, and the Notify Object cannot find out the name before the INetCfgClassSetup::Install() function returns control - and that will not return control until ProtocolBindAdapter() exits. Thus, the ProtocolBindAdapter() function fails to initialize the miniport device instance and the protocol will not work on the adapter. The Notify Object will still create the required registry values afterwards, and when re-initializing the adapter by disabling and re-enabling its Local Area Connection or upon the next reboot, ProtocolBindAdapter() will successfully initialize the miniport device instance and the protocol will work on the adapter. 7.3 The protocol's dial-up devices show up as ISDN channels and a meaningless ISDN Configuration is offered When you open the properties of a dial-up connection, you will find the protocol's dial-up devices listed as "ISDN channel - Adapter Name". Selecting a dial-up device and clicking the Configure... button brings up an ISDN Configuration window with settings that are meaningless to PPP over Ethernet. The reason for this is that the dial-up devices are declared as ISDN devices to the system to make on-demand dialing for Internet Connection Sharing work. While the incorrect display can be confusing, it does no harm. Background: It was found that the Remote Access Auto Connection Manager service will only use modems, ISDN and X.25 devices for on-demand dialing, but not "generic" devices, as this protocol's dial-up devices were formerly declared. This is apparently a bug in Windows 2000. 7.4 After uninstalling the protocol or unbinding it from a network adapter, its dial-up devices are still shown until you reboot When you unbind the protocol from an adapter or even completely uninstall the protocol, the dial-up devices it created are still shown in a dial-up connection's Properties box and will not go away until you reboot. When you re-bind to an adapter or re-install the protocol without rebooting, you will see double entries per adapter, with one having an additional number in brackets in the name. This is a bug in Windows; even WAN miniports shipping with the operating system exhibit this behavior. While the additional entries do no harm, they can be confusing. They will be gone after a reboot. Background: This issue is known to Microsoft and currently intended behavior. They found that TAPI is leaking memory when a line device is removed and thus temporarily "fixed" this by simply blocking line device removal. Microsoft is supposedly working on a fix. 7.5 Uninstalling the protocol leaves files behind and the driver may not be unloaded from memory If you are running Windows 2000, when you uninstall the protocol, the protocol's Notify Object, RASPPPOE.DLL is left behind in your \WINNT\SYSTEM32 directory and the driver may remain loaded in memory until you reboot. The DLL left behind can be safely deleted after uninstalling the protocol. The latter issue poses a problem should you upgrade to a newer version of this protocol. Although the installation will put the new driver file on the hard disk, Windows 2000 will continue to use the old driver version still resident in memory instead of loading the new version from hard disk. To unload the driver from memory, you must first unbind the protocol from all network adapters by clearing the checkbox next to PPP over Ethernet Protocol in each Local Area Connection on your machine. Then click the Uninstall button to remove the protocol. If you uninstalled the protocol without unbinding it from all network adapters first, you will have to reboot for any new driver version to be actually loaded. Background: Although there is a DelFiles directive in the protocol's INF file to delete RASPPPOE.DLL, the DLL is still locked in memory at the time the directive is supposed to be carried out. Microsoft has already acknowledged that this is a bug in the Windows 2000 binding engine which they need to fix. The driver unloading issue occurs with Microsoft's PASSTHRU DDK sample as well and has been acknowledged by Microsoft. Both issues are fixed in Windows XP/.NET. 7.6 If there was no reboot since installation, the first connection attempt after waking the machine from Standby fails with error 651 When the machine has not been rebooted since installation and is woken from Standby, the first connection attempt through this protocol fails with "Error 651: The Modem (or other connecting device) has reported an error." Any further connection attempts proceed without this problem. If the machine is rebooted, the problem goes away entirely. Background: The cause of this problem is unknown. In this situation, the protocol receives the same TAPI OIDs as for any other (successful) connection attempt and handles them just the same, but just at the point where the OID_TAPI_MAKE_CALL request would have to come, this error message comes up instead. The protocol did not show any extraordinary failures, so the error must occur within NDISTAPI itself. This is probably a bug in Windows 2000. 7.7 When a dial-up connection is made "always on", it is not properly terminated when shutting the machine down or rebooting When you configure a PPP over Ethernet dial-up connection to be "always on", the connection will not be properly terminated when shutting the machine down or rebooting. This causes problems with service providers who take very long to detect such a dropped connection and limit the number of concurrent connections - after several reboots, you may find yourself to log on to your service provider for some time. To work around this problem, always disconnect your "always on" connection manually before rebooting. Background: Investigation revealed that the protocol receives no indication that the system is going down. Neither the MiniportHalt(), nor the ProtocolUnbindAdapter(), nor the ProtocolPnPEvent(), nor the ProtocolStatus() handler and not even a handler registered with the NdisMRegisterAdapterShutdownHandler() are called to indicate the shutdown. Thus, it is not possible for the protocol to terminate its open connections prior to the shutdown. This is apparently a shortcoming of Windows 2000/XP/.NET. 8. Revision History * Version 0.98, October 3rd, 2002 * First release with Windows 95 and Windows NT 4.0 support! The Windows 95 version uses a different driver binary, while Windows NT 4.0 runs the same binary as Windows 98/98SE/ME/2000/XP/.NET. * Added: Windows 95 support. Requires Microsoft Dial-Up Networking Upgrade 1.2 or later on the original Windows 95 release (4.00.950). Figured out how to make the fragments of NDIS Intermediate driver support in NDIS.VXD version 4.00.1111 work and how to install the driver. Created two new INF files for installation and added installation support to WINPPPOE.DLL to install and remove virtual miniport instances as needed. Wrote function replacements for NDIS functions not available in Windows 95. Changed the functions NdisMIndicateStatus(), NdisMIndicateStatusComplete(), NdisMResetComplete(), NdisMWanIndicateReceive(), NdisMWanIndicateReceiveComplete() and NdisMWanSendComplete() from macros back to imports. Added NdisRecalculatePacketCounts() and NdisQueryPacket() macro invocations for compatible packet initialization. Added #ifdefs to the driver source so that the Windows 95 driver binary can be compiled from the same source. * Added: Windows NT 4.0 support. Requires Service Pack 4 or later. Also requires a reboot after installation since Windows NT cannot start NDIS miniports dynamically. Wrote a completely new OEMSETNT.INF installation script from scratch which installs and removes virtual miniports on demand and automatically initializes the RAS TAPI devices exposed by the driver without having to go through the RAS configuration panel. Added a standalone, exported WindowsNTControlPanel function to RASPPPOE.DLL which is invoked from OEMSETNT.INF for configuration of the protocol properties. Changed and expanded the TAPI provider portion of the driver for compatibility with Windows NT 4.0. * Fixed: In Windows 2000/XP/.NET, the protocol properties dialog could not retrieve the current protocol configuration if more than one line per adapter was configured. Fixed this by stripping the "line X" suffix from the TAPI line name before the string comparison. * Fixed: In Windows 98/98SE/ME, the protocol properties did not allow specifying values greater than 3276 kbps for the Link Speed option due to improper 16/32-bit handling. Fixed this by cleaning up the string-to-integer conversion calls. Now link speeds up to 65535 kbps can be entered in Windows 95/98/98SE/ME. * Fixed: The MiniportQueryInformation() handler made a call to NdisUnicodeStringToAnsiString(), which is not allowed at the IRQL the handler may be invoked at. Fixed this by moving the call to the ProtocolBindAdapter() handler. * Changed: RASPPPOE.EXE now uses TAPI version 1.3 to communicate with the running protocol for compatibility with Windows 95. * Changed: RASPPPOE.EXE now changes the characters [ and ] to ( and ), respectively, and strips trailing space characters from the connection name when creating a dial-up connection for compatibility with Windows NT 4.0. * Version 0.97, August 23rd, 2001 * Added: An application manifest for RASPPPOE.EXE to enable the Windows XP visual style in its user interface. * Changed: The self-deleting code in RASPPPOE.EXE (fully licensed version only) was changed from an x86 assembly routine to a CPU independent method that is also compatible with Windows XP. * Fixed: The IA64 version caused STOP errors due to data misalignment. Fixed this by padding data structures where possible and by using the UNALIGNED compiler macro where misalignment cannot be avoided. * Version 0.96, May 29th, 2001 * First release with Intel Itanium 64-bit CPU support! The IA64 version is distributed in a separate archive for now. * Fixed: Some code paths in the ProtocolReceivePacket() handler returned a non-zero value, which would not return the received packet to the network adapter driver, eventually causing it to run out of packets, making unable to operate. Fixed this by ensuring all code paths return zero. * Changed: The watchdog timer that checks every ten seconds whether any packets have been received will now send up to three LCP Echo-Requests before terminating the connection. Thus, a connection loss will now be detected within 40 to 50 seconds. This should cure the disconnection problems a number of users have been suffering from due to the watchdog timer being a bit too sensitive for some service providers. * Changed: When connecting to the unnamed default service, the protocol will now connect to the first offered service, even if it is not unnamed. This enhances compatibility with service providers who are not fully RFC 2516 compliant. * Version 0.95, December 29th, 2000 * Added: A no-reboot installer (fully licensed version only) that installs, repairs or upgrades the protocol from a single, self-extracting executable, typically without requiring a reboot on any of the supported platforms. Additionally, it creates a dial-up connection and then prompts the user to connect to allow an "instant success" experience. The protocol will be added to the list of installed programs in Add/Remove Programs in Control Panel for convenient and complete uninstallation. Optional command-line switches allow silent installation, upgrade and removal for licensees who wish to provide their own installer front-end. * Added: Server capability. If one of the dial-up devices exposed by the protocol is configured to accept incoming connections, the protocol will offer the unnamed default service on the corresponding adapter and use the computer name set in the networking configuration as the Access Concentrator name. If the connection is accepted, the protocol will do a left-to-right (big-endian) comparison of the adapter's MAC address with the one of the connecting host, and generate an even (LSB 0) session identifier is the adapter's MAC address is lower, or an odd (LSB 1) one if it is higher, to ensure that two machines connecting to each other simultaneously do not generate identical session identifiers. The server is not industry-strength. There is no limit on the connections per MAC address, nor is any encryption being used in the Access Concentrator Cookies generated by the protocol, so a malicious user on the same Ethernet segment could occupy all incoming lines with a denial-of-service attack, but do no harm beyond that. Great care has been taken to minimize the load on the system if such an attack is made. * Added: Timers. The protocol now times out connection requests and resends requests two times, once after one second, then after two seconds, and three seconds after that indicates no answer. Incoming connections are offered for five seconds before being rejected. When a connection is established, a watchdog timer checks every ten seconds whether any packets been received, and generates and sends an LCP Echo-Request to the peer if no packet has been received since the last check. If at the next check still no packet has been received, the connection is terminated with no answer. Thus, a connection that was dropped by the other end without proper termination will be detected as lost within 20 to 30 seconds. * Added: In Windows 98/98SE/ME, RASPPPOE.EXE now checks whether Dial-Up Networking is installed and gives an error message if it is not. Additionally, it checks if NDIS.VXD version 4.10.2222 is installed, and warns the user to install fix Q243199 if it is. * Added: In Windows 98/98SE/ME, WINPPPOE.DLL now adds a new value to the Packet Size setting of the Dial-Up Adapter called PPP over Ethernet, which sets the packet size to either the default (1492) or the overridden MTU. * Fixed: RASPPPOE.EXE would show erroneous query results if more than one Access Concentrator offered services, because the driver was returning an incorrect query result length. Fixed this by correcting the length calculation in the driver. * Fixed: In Windows 98/98SE/ME, RASPPPOE.EXE was unable to properly retrieve the names of network adapters which were 58 characters or more long, which led to it displaying a blank adapter name and being unable to create a dial-up connection for the adapter. Fixed this by increasing the size of the retrieval buffer and limiting the size of the passed name. * Fixed: Windows 98/98SE/ME was unable to tell apart the dial-up devices exposed for two network adapters of the same name. Fixed this by appending a "#X" suffix to the dial-up device name if the protocol is already bound to a network adapter of the same name. * Fixed: In Windows 98SE/ME, NDIS.VXD versions 4.10.2224 (from fix Q243199 for Windows 98SE) and 4.90.3000 (included in Windows ME) randomly dropped packets received from the NE2000 or the Realtek RTL8029(AS) driver without indicating them to the protocol for an unknown reason. Worked around this problem by adding NDIS_PACKET_TYPE_ALL_LOCAL to the packet filter if Windows 98/98SE/ME and one of these two drivers is detected, which makes NDIS.VXD work reliable again. * Fixed: If TAPI requested to drop a call, the protocol would not transition to the idle call state, because I had misunderstood a paragraph in the DDK documentation. This might also have been the cause of TAPISRV.EXE causing crashes in RPCRT4.DLL in Windows ME. Fixed this by reviewing all TAPI call state transitions and making sure the behavior is compliant with the DDK documentation. * Fixed: When running a repair or upgrade install on Windows 2000, the protocol could crash the operating system with a blue screen indicating that RASPPPOE.SYS was unloaded without canceling pending operations. Investigation revealed that Windows 2000 was trying to call the protocol's ProtocolPnPEventHandler() function after it had been unloaded, because the protocol had not been deregistered. Further investigation revealed that the ProtocolUnload() handler is never called in Windows 2000, which is not documented in the Windows 2000 DDK documentation. Fixed this by providing a DriverUnload() handler again to deregister the protocol, and by putting the pointer to this function directly into the driver object in DriverEntry() to omit the NdisMRegisterUnloadHandler() call, which is not available in Windows 98. The ProtocolUnload() handler is still provided for Windows 98/98SE/ME. * Changed: RASPPPOE.EXE now displays a different error message if the user tried to query available services through an adapter which line is already in use by an active PPPoE session, explaining that the user needs to disconnect that session to be able to query services. * Changed: If more than one WAN Endpoint is configured for a network adapter, "Line X" suffixes will now be appended in Windows 2000 as well. Previously, they were only appended in Windows 98/98SE/ME. * Changed: In Windows 2000, the protocol no longer logs query results to the event log. RASPPPOE.EXE made this function obsolete. * Changed: Removed the NCF_NOT_USER_REMOVEABLE flag from the WAN miniport (PPP over Ethernet Protocol) INF file for Windows 2000, allowing manual removal of any miniport instances left behind in Device Manager. * Changed: Replaced the previously imported strncmp() and _strnicmp() kernel functions with inline functions. Removed the need for the _snwprintf() kernel function by generating the "Line X" suffixes directly in the code. * Changed: During protocol initialization and shutdown, the MiniportQueryInformation(), MiniportSetInformation(), MiniportReset() and MiniportWanSend() handlers now return NDIS_STATUS_ADAPTER NOT_READY instead of NDIS_STATUS_FAILURE. * Changed: The protocol service name and the driver binary name were changed to RMSPPPOE and RMSPPPOE.SYS, respectively, to enhance compatibility with future Windows versions. * Version 0.94, May 17th, 2000 * First release with Windows 98/98SE/ME support! No thanks to Microsoft's complete lack of documentation on NDIS intermediate drivers in Windows 98/98SE/ME. * Added: Windows 98/98SE/ME support. Figured out the INF format for NDIS intermediate drivers in Windows 98/98SE/ME and where WAN.TSP expects an NDIS intermediate driver's TAPI registry subkey to be located in the registry. Added a 16-bit Windows DLL (WINPPPOE.DLL) with an NDI procedure to create that registry subkey upon installation, set the Dial-Up Adapter's IPMTU registry parameter to the MTU for PPP over Ethernet (Windows 98/98SE/ME was found to ignore the maximum frame size returned by the driver) and offer the protocol properties GUI. Changed the driver unload function to ProtocolUnload(), since NdisMRegisterUnloadHandler() is not supported in Windows 98/98SE/ME. Removed the NdisIMAssociateMiniport() call from the DriverEntry() function, since that call is not supported in Windows 98. * Added: RASPPPOE.EXE user-mode application for easy dial-up connection setup. * Added: Limit TCP MSS Option to make MTU changes on Internet Connection Sharing client machines unnecessary. A new function scans all incoming and outgoing packets for the TCP Maximum Segment Size (MSS) option and, if necessary, limits it to either the default (1492) or the overridden MTU (see below) minus 40 for the IP and TCP headers (i.e. 1452 in case of the default MTU) and recalculates the TCP checksum. * Added: MTU Override option to override the MTU initially reported by the driver. If an override value is specified, it will be reported as the MaxFrameSize in response to the OID_WAN_GET_INFO request. In Windows 98/98SE/ME, the Dial-Up Adapter's IPMTU registry parameter is also set to the override value. It will furthermore be taken into account when limiting the TCP MSS option. Making the protocol initially report a lower MTU was found to help with certain VPN software packages which "blindly" add their own overhead without paying any respect to the MTU reported by the driver. * Added: WAN Endpoints GUI option to easily change the number of dial-up devices exposed for a network adapter. * Fixed: Dial on demand in Windows 2000 never triggered a connection. Windows 2000 apparently only dials modems, ISDN and X.25 devices on demand. Changed the device type of the dial-up devices exposed by the protocol to ISDN to work around this bug. * Fixed: The protocol could lose one of its internal packets each time an NdisTransferData() call failed, until it would eventually be unable to receive any data. It appears that never actually happened to anyone, though. * Fixed: The PPPoE version and type fields were reversed in the declaration. As the current PPPoE version and type are both 1, this bug went unnoticed. * Changed: The protocol will now no longer log a warning to the event log if it receives a PADT packet for a session that does not exist (or no longer does). * Changed: The Event Logging Options now default to logging all types of events. This should now produce no log entries during flawless operation. * Version 0.92, February 6th, 2000 * Fixed: No data transfer possible after successfully establishing a connection. The protocol was corrupting data packets it had to retrieve through NdisTransferData(). I had made the incorrect assumption that NdisTransferData() would use the ByteOffset parameter on the destination buffer as well, but instead it just starts at offset zero in the first buffer chained to the passed packet. Fixed this by chaining an additional buffer descriptor pointing to the desired destination location to the front of the packet before calling NdisTransferData(). * Fixed: Connection Error "Opening port... Error 797: The connection failed because the modem (or other connecting device) was not found." after waking the machine from Standby. There were no OID_PNP_XXX handlers in the protocol. Additionally, it turned out that TAPI requests OID_TAPI_PROVIDER_INITIALIZE after returning from Standby, although it never shuts the provider down with OID_TAPI_PROVIDER_SHUTDOWN. The protocol did not allow re-initialization without shutdown. Fixed this by adding the missing OID_PNP_XXX handlers and allowing TAPI provider re-initialization without a prior shutdown. * Version 0.90, January 30th, 2000 * First release that actually works! A wholehearted Thank You! to Jerome Whelan who invested so much time to provide me with the comprehensive feedback that I needed to make this protocol functional. * Fixed: Installation Error "Could not add the requested component. The error is: Invalid access to memory location." on some machines. On those, the loader crashed when loading RASPPPOE.DLL, because I had linked it with the /align:16 linker switch. Removed the switch from the build settings. * Fixed: Connection Error "Disconnected. Error 619: The specified port is not connected." on all connection attempts. NDISWAN failed to recognize the PPP frames within the complete received Ethernet frames the protocol passed to it, although I had specified the HeaderPadding correctly as outlined in the DDK documentation. Fixed this by setting the HeaderPadding to zero and only passing the portion of the buffer with the actual PPP frame to NDISWAN. * Fixed: Ping Timeouts with certain packet sizes. NDISWAN passes up to four bytes more to a WAN miniport's send handler than the WAN miniport indicated as its MaxFrameSize. Apparently a WAN miniport driver writer is expected to make assumptions about the PPP HDLC overhead NDISWAN adds before passing a packet to the miniport - four bytes of simple PPP HDLC framing (Address and Control fields and Protocol Identifier). Fixed this by adjusting the maximum frame and total sizes accordingly and changing the size limit comparisons. * Version 0.80, January 15th, 2000 * Initial public release *EOF* __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 13:13:54 2004 Return-Path: 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 99D9516A4CE for ; Mon, 21 Jun 2004 13:13:54 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 188D743D39 for ; Mon, 21 Jun 2004 13:13:53 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i5LDDlcA074358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2004 17:13:48 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i5LDDkEc074357; Mon, 21 Jun 2004 17:13:46 +0400 (MSD) Date: Mon, 21 Jun 2004 17:13:46 +0400 From: Gleb Smirnoff To: Yohan Message-ID: <20040621131346.GA74289@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yohan , freebsd-net@freebsd.org References: <20040621120725.GA73889@cell.sick.ru> <20040621130432.91505.qmail@web60802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040621130432.91505.qmail@web60802.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 13:13:54 -0000 On Mon, Jun 21, 2004 at 06:04:32AM -0700, Yohan wrote: Y> 17:48:04.718691 0:8:a1:5f:b5:4b Broadcast 8863 60: Y> PPPoE PADI [Host-Uniq UTF8] Y> 17:48:04.732330 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: Y> PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] Y> [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq Y> UTF8] Y> 17:48:04.732347 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: Y> PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name Y> "BANYAN"] Y> 17:48:06.724827 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: Y> PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name Y> "BANYAN"] Seems like PPPoE server does not request to your PADR requests. I have one suspicion. Please check the value of PTT_RELAY_SID in your /usr/include/netgraph/ng_pppoe.h Also post output of `ident ng_pppoe.ko`, the module you load before dialing PPPoE. It lives in /modules in STABLE or in /boot/kernel/ in CURRENT. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 13:44:27 2004 Return-Path: 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 528CA16A4CE for ; Mon, 21 Jun 2004 13:44:27 +0000 (GMT) Received: from web60802.mail.yahoo.com (web60802.mail.yahoo.com [216.155.196.65]) by mx1.FreeBSD.org (Postfix) with SMTP id E165143D1F for ; Mon, 21 Jun 2004 13:44:26 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621134426.99228.qmail@web60802.mail.yahoo.com> Received: from [220.226.14.59] by web60802.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 06:44:26 PDT Date: Mon, 21 Jun 2004 06:44:26 -0700 (PDT) From: Yohan To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20040621131346.GA74289@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 13:44:27 -0000 Gleb, I compiled the following into the kernel .. options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_SOCKET because i thought the loadable module was creating the problem. Anyways the value of PTT_RELAY_SID in my /usr/include/netgraph/ng_pppoe.h in the Tag Identifiers section is (0x0106). Output of `ident ng_pppoe.ko` .. ng_pppoe.ko: ident warning: no id keywords in ng_pppoe.ko regards Yo --- Gleb Smirnoff wrote: > On Mon, Jun 21, 2004 at 06:04:32AM -0700, Yohan > wrote: > Y> 17:48:04.718691 0:8:a1:5f:b5:4b Broadcast 8863 > 60: > Y> PPPoE PADI [Host-Uniq UTF8] > Y> 17:48:04.732330 0:4:e6:4:41:1 0:8:a1:5f:b5:4b > 8863 76: > Y> PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] > Y> [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq > Y> UTF8] > Y> 17:48:04.732347 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 > 8863 60: > Y> PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] > [AC-Name > Y> "BANYAN"] > Y> 17:48:06.724827 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 > 8863 60: > Y> PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] > [AC-Name > Y> "BANYAN"] > > Seems like PPPoE server does not request to your > PADR requests. I have one > suspicion. Please check the value of PTT_RELAY_SID > in your > /usr/include/netgraph/ng_pppoe.h > > Also post output of `ident ng_pppoe.ko`, the module > you load before > dialing PPPoE. It lives in /modules in STABLE or in > /boot/kernel/ in CURRENT. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 13:48:27 2004 Return-Path: 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 695BA16A4CE for ; Mon, 21 Jun 2004 13:48:27 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D6143D5D for ; Mon, 21 Jun 2004 13:48:26 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i5LDmMcA074537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2004 17:48:23 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i5LDmMLd074536; Mon, 21 Jun 2004 17:48:22 +0400 (MSD) Date: Mon, 21 Jun 2004 17:48:22 +0400 From: Gleb Smirnoff To: Yohan Message-ID: <20040621134822.GA74513@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yohan , freebsd-net@freebsd.org References: <20040621131346.GA74289@cell.sick.ru> <20040621134426.99228.qmail@web60802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040621134426.99228.qmail@web60802.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 13:48:27 -0000 On Mon, Jun 21, 2004 at 06:44:26AM -0700, Yohan wrote: Y> Anyways the value of PTT_RELAY_SID in my Y> /usr/include/netgraph/ng_pppoe.h in the Tag Y> Identifiers section is (0x0106). May be this is causing problem. This value is incorrect and it is already fixed in recent CURRENT or STABLE. Try to upgrade your FreeBSD and try again. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 13:58:28 2004 Return-Path: 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 CCAAC16A4CE for ; Mon, 21 Jun 2004 13:58:28 +0000 (GMT) Received: from web60802.mail.yahoo.com (web60802.mail.yahoo.com [216.155.196.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 65F3143D45 for ; Mon, 21 Jun 2004 13:58:28 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040621135801.2150.qmail@web60802.mail.yahoo.com> Received: from [220.226.14.59] by web60802.mail.yahoo.com via HTTP; Mon, 21 Jun 2004 06:58:01 PDT Date: Mon, 21 Jun 2004 06:58:01 -0700 (PDT) From: Yohan To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20040621134822.GA74513@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 13:58:28 -0000 Gleb, Thanks for keeping my hopes alive. I have a question .. do i upgrade or downgrade and will it work. because upgrading a production machine for me is slightly time consuming. If thats the way to go .. i will. will take ur advice for it. i have freebsd 4.9 presently. i also do have 4.8 cd;s only .. should i download 4.10 / 5.2 and upgrade or use 4.8. If i could make changes to the present and recompile kernel or whatever kindly let me know whats required. Thanks Yo --- Gleb Smirnoff wrote: > On Mon, Jun 21, 2004 at 06:44:26AM -0700, Yohan > wrote: > Y> Anyways the value of PTT_RELAY_SID in my > Y> /usr/include/netgraph/ng_pppoe.h in the Tag > Y> Identifiers section is (0x0106). > > May be this is causing problem. This value is > incorrect and it is already > fixed in recent CURRENT or STABLE. > Try to upgrade your FreeBSD and try again. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 14:15:21 2004 Return-Path: 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 4B8A716A4D0 for ; Mon, 21 Jun 2004 14:15:16 +0000 (GMT) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEAF343D4C for ; Mon, 21 Jun 2004 14:15:15 +0000 (GMT) (envelope-from fming@borderware.com) Message-ID: <40D6ECE6.6040106@borderware.com> Date: Mon, 21 Jun 2004 10:12:54 -0400 From: ming fu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: PPPoE address change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 14:15:21 -0000 Hi, I was using Bell sympatico pppoe. The PPP tunnel address changes every few hours. Is there a way to let ppp to call some program so that servers and ipfw rules can be changed to adjust to the new IP. I know I can run a cron job checking the routing state every few seconds, but I want my ipfw rule to change write way when the tunnel address changes. Thanks, Ming From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 15:52:47 2004 Return-Path: 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 17C6216A4EC for ; Mon, 21 Jun 2004 15:52:47 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1657743D1D for ; Mon, 21 Jun 2004 15:52:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5LFoqhc033280; Mon, 21 Jun 2004 11:50:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5LFoq1w033277; Mon, 21 Jun 2004 11:50:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 21 Jun 2004 11:50:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Long Le In-Reply-To: <20040621121945.GB18534@quartet.cs.unc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Blasting UDP packets on a 1-Gbps link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 15:52:47 -0000 On Mon, 21 Jun 2004, Long Le wrote: > I've been trying to get iperf to blast UDP packets for 10 minutes on a > 1-Gbps link. However, iperf stops after a few seconds and complains that > it can't write to the socket because no buffer space is available. > > 'netstat -m' shows that there are lots of mbufs available. I modified > iperf source code to set the socket's send buffer to 200000 bytes (*) > but it didn't really help much. In another attempt, I modified iperf > source code such that it would not quit after failing to write to the > socket. However, this caused iperf to hang. I use iperf 1.7.0 and > FreeBSD 4.5. The machine I am using has a 1-GHz CPU and 1 Gbytes of > memory. I could try to write my own program to blast UDP packets but > would prefer to use available software if possible. > > Has anyone successfully blasted UDP packets on a 1-Gbps link for a > sustained period and can anyone give me some useful hints? The ENOBUFS you're getting is likely generated by IFQ_ENQUEUE() when the outgoing interface queue fills, as lossy datagram protocols will generally attempt to deliver straight to the interface and drop if there's no room. I believe this happens regardless of socket buffer size, hence your '*' below. What you probably want to do is use an interval timer to schedule sending packets at the rate you want to accomplish. Or, if you really just want to send as fast as you can, you can spin and ignore ENOBUFS. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research > > Thanks, > Long > > (*) Apparently, iperf doesn't have an option to set the socket buffer for > UDP sockets. And there seems to be a limit that doesn't allow to set a > larger buffer size than around 200000 bytes (this is not related to iperf > but FreeBSD in general). > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:06:15 2004 Return-Path: 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 84D5716A4CE for ; Mon, 21 Jun 2004 16:06:15 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FEA143D5C for ; Mon, 21 Jun 2004 16:06:13 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004062116060101500t01dle>; Mon, 21 Jun 2004 16:06:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA36516; Mon, 21 Jun 2004 09:05:59 -0700 (PDT) Date: Mon, 21 Jun 2004 09:05:58 -0700 (PDT) From: Julian Elischer To: Yohan In-Reply-To: <20040621091112.87515.qmail@web60810.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 16:06:15 -0000 a tcpdump of the ethernet interface can be useful too.. On Mon, 21 Jun 2004, Yohan wrote: > Gleb, > > I have enclosed another copy of ppp.log with slightly > different results. Thanks for the help. > > regards > > Yohann > > ppp.log > > Jun 21 14:00:53 chennai ppp[353]: Phase: Using > interface: tun0 > Jun 21 14:00:53 chennai ppp[353]: Phase: deflink: > Created in closed state > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > ident user-ppp VERSION (built COMPILATIONDATE) > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set device PPPoE:rl1 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set mru 1492 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set mtu 1492 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set speed sync > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > enable lqr > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set cd off > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set dial > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set login > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set timeout 0 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set authname hddias33 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set authkey ******** > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 > > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > delete all > Jun 21 14:00:53 chennai ppp[353]: tun0: Debug: > route_IfDelete (8) > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > add default HISADDR > Jun 21 14:00:53 chennai ppp[353]: tun0: ID0: 9 = > socket(17, 3, 0) > Jun 21 14:00:53 chennai ppp[353]: tun0: ID0: 140 = > write(9, data, 140) > Jun 21 14:00:53 chennai ppp[353]: tun0: Debug: wrote > 140: cmd = Add, dst = 0.0.0.0/0, gateway = 10.0.0.2 > Jun 21 14:00:53 chennai ppp[353]: tun0: Command: bsnl: > enable dns > Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: > 0x282948a0 = fopen("/var/run/tun0.pid", "w") > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: PPP > Started (ddial mode). > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: bundle: > Establish > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: > deflink: closed -> opening > Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: > Creating PPPoE netgraph node [2]:orphans -> ethernet > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> rl1:orphans:tun0 > Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:00:53 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:00:53 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Found > the following interfaces: > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 1, name "rl0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 2, name "rl1" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 3, name "lp0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 4, name "lo0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 5, name "ppp0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 6, name "sl0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 7, name "faith0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Index > 8, name "tun0" > Jun 21 14:00:53 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:00:53 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:00:53 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:00:54 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:54 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:00:54 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:00:55 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:55 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:00:56 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:56 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:00:57 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:57 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:00:58 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:00:53 > 2004 > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:00:58 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:00:58 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: dial > timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = > running > Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:28 chennai ppp[354]: tun0: Chat: deflink: > Redial timer expired. > Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Found > orphans -> ethernet > Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> [4]::tun0 > Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:01:28 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:01:28 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:01:28 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:01:28 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:01:28 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:29 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:29 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:01:29 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:30 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:30 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:31 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:31 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:32 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:32 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:01:33 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:01:28 > 2004 > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:01:33 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:01:33 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: dial > timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = > running > Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:03 chennai ppp[354]: tun0: Chat: deflink: > Redial timer expired. > Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Found > orphans -> ethernet > Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> [4]::tun0 > Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:02:03 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:02:03 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:02:03 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:02:03 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:02:03 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:04 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:04 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:02:04 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:05 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:05 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:06 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:06 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:07 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:07 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:02:08 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:02:03 > 2004 > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:02:08 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:02:08 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: dial > timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = > running > Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:38 chennai ppp[354]: tun0: Chat: deflink: > Redial timer expired. > Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Found > orphans -> ethernet > Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> [4]::tun0 > Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:02:38 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:02:38 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:02:38 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:02:38 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:02:38 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:39 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:39 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:02:39 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:40 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:40 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:41 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:41 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:42 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:42 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:02:43 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:02:38 > 2004 > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:02:43 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:02:43 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: dial > timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = > running > Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:13 chennai ppp[354]: tun0: Chat: deflink: > Redial timer expired. > Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Found > orphans -> ethernet > Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> [4]::tun0 > Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:03:13 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:03:13 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:03:13 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:03:13 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:03:13 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:14 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:14 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:03:14 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:15 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:15 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:16 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:16 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:17 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:17 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:03:18 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:03:13 > 2004 > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:03:18 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:03:18 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: dial > timer[0x80b7d44]: freq = 30.00s, next = 0.00s, state = > running > Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:48 chennai ppp[354]: tun0: Chat: deflink: > Redial timer expired. > Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = > NgMkSockNode("", &cs, &ds) > Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: List of > netgraph node ``rl1:'' (id 2) hooks: > Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Found > orphans -> ethernet > Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: > Connecting netgraph socket .:tun0 -> [4]::tun0 > Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 2 = > socket(2, 2, 0) > Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 3223349521, 0xbfbfed50) > Jun 21 14:03:48 chennai ppp[354]: tun0: ID0: 0 = > ioctl(2, 2149607696, 0xbfbfed50) > Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Sending > PPPOE_CONNECT to .:tun0 > Jun 21 14:03:48 chennai ppp[354]: tun0: Warning: > deflink: Carrier must be set, using ``set cd 5!'' > Jun 21 14:03:48 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: > deflink: Connected! > Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: > deflink: opening -> dial > Jun 21 14:03:48 chennai ppp[354]: tun0: Phase: > deflink: dial -> carrier > Jun 21 14:03:48 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:49 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:49 chennai ppp[354]: tun0: Phase: > Received NGM_PPPOE_ACNAME (hook "BANYAN") > Jun 21 14:03:49 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:50 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:50 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:51 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:51 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:52 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:52 chennai ppp[354]: tun0: Debug: Waiting > for carrier > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: Select > returns -1 > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: ---- > Begin of Timer Service List--- > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: > physical throughput timer[0x80ba068]: freq = 1.00s, > next = 0.00s, state = running > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: ---- > End of Timer Service List --- > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting physical throughput > timer[0x80ba068] > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: Disconnected! > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: carrier -> hangup > Jun 21 14:03:53 chennai ppp[354]: tun0: Debug: > deflink: Close > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: Connect time: 5 secs: 0 octets in, 0 octets > out > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: 0 packets in, 0 packets out > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: total > 0 bytes/sec, peak 0 bytes/sec on Mon Jun 21 14:03:48 > 2004 > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: hangup -> opening > Jun 21 14:03:53 chennai ppp[354]: tun0: Timer: > timer_Start: Inserting dial timer[0x80b7d44] > Jun 21 14:03:53 chennai ppp[354]: tun0: Phase: > deflink: Enter pause (30) for redialing. > > --- Gleb Smirnoff wrote: > > On Sun, Jun 20, 2004 at 09:05:19AM -0700, Yohan > > wrote: > > Y> Im using PPPoE / FreeBSD 4.9 with a DSL line > > provided by my ISP. The same modem / line works fine > > / connects to the internet on a Windows 2000 > > machine. But when i use it with my FreeBSD machine > > using ppp i get the following message in my ppp.log > > "-> Waiting for carrier" - "Last message repeated n > > times". I have followed the FreeBSD handbook > > instructions for setting up PPPoE. Have also tried > > various other articles related to PPPoE setup on > > FreeBSD. I have tried various other options like > > disabling carrier and others but i am unable to get > > past the "no carrier" problem. Any help will be > > greatly apreciated. > > > > Please show full ppp.log starting from the moment > > when you started dailing. > > Please also show your ppp.conf > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:13:17 2004 Return-Path: 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 63D6716A4CE for ; Mon, 21 Jun 2004 16:13:17 +0000 (GMT) Received: from Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78B743D1F for ; Mon, 21 Jun 2004 16:13:16 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by Awfulhak.org (8.12.11/8.12.11) with SMTP id i5LGC84B000721; Mon, 21 Jun 2004 17:12:08 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 21 Jun 2004 17:12:08 +0100 From: Brian Somers To: Yohan , freebsd-net@freebsd.org Message-Id: <20040621171208.675354ae@dev.lan.Awfulhak.org> In-Reply-To: <20040621125541.20360.qmail@web60810.mail.yahoo.com> References: <20040621122211.30f48082@dev.lan.Awfulhak.org> <20040621125541.20360.qmail@web60810.mail.yahoo.com> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gw.lan.Awfulhak.org cc: Julian Elischer Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 16:13:17 -0000 On Mon, 21 Jun 2004 05:55:41 -0700 (PDT), Yohan wrote: > 17:48:15.035656 0:8:a1:5f:b5:4b Broadcast 8863 60: > PPPoE PADI [Host-Uniq UTF8] > 17:48:15.049217 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76: > PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] > [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq > UTF8] > 17:48:15.049232 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60: > PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name > "BANYAN"] And the missing bit is the PADS packet (which we're expecting from the PPPoE server). Here, the netgraph node is resending the PADR after 2 seconds of inactivity, then dropping back to sending a PADI all over again. Interestingly enough, the PADR doesn't seem to have the Service-Name or Relay-Session-ID tags that the PADO has - perhaps that's what's causing the problem... certainly the PADO handling code that sends the PADS calls scan_tags() which is supposed to copy tags not already handled from the PADO into the PADR. Julian, have you any comments on this ? Cheers. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:23:39 2004 Return-Path: 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 8398316A4CE for ; Mon, 21 Jun 2004 16:23:39 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40A9D43D1D for ; Mon, 21 Jun 2004 16:23:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004062116233701200hpd6me>; Mon, 21 Jun 2004 16:23:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA36795; Mon, 21 Jun 2004 09:23:36 -0700 (PDT) Date: Mon, 21 Jun 2004 09:23:34 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040621134822.GA74513@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Yohan cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 16:23:39 -0000 Or just add the new value in /usr/src/sys/netgraph/ng_pppoe.[ch] the new value is (ummmm 0x0110 I think) On Mon, 21 Jun 2004, Gleb Smirnoff wrote: > On Mon, Jun 21, 2004 at 06:44:26AM -0700, Yohan wrote: > Y> Anyways the value of PTT_RELAY_SID in my > Y> /usr/include/netgraph/ng_pppoe.h in the Tag > Y> Identifiers section is (0x0106). > > May be this is causing problem. This value is incorrect and it is already > fixed in recent CURRENT or STABLE. > Try to upgrade your FreeBSD and try again. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 16:37:23 2004 Return-Path: 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 E148116A4CE for ; Mon, 21 Jun 2004 16:37:23 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE10543D48 for ; Mon, 21 Jun 2004 16:37:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <200406211637230140021cq7e>; Mon, 21 Jun 2004 16:37:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA36910; Mon, 21 Jun 2004 09:37:21 -0700 (PDT) Date: Mon, 21 Jun 2004 09:37:19 -0700 (PDT) From: Julian Elischer To: Brian Somers In-Reply-To: <20040621171208.675354ae@dev.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Yohan cc: freebsd-net@freebsd.org Subject: Re: PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 16:37:24 -0000 On Mon, 21 Jun 2004, Brian Somers wrote: > On Mon, 21 Jun 2004 05:55:41 -0700 (PDT), Yohan wrote: > > PPPoE PADI [Host-Uniq UTF8] > > PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8] [Service-Name] [Relay-Session-ID UTF8] [Host-Uniq UTF8] > > PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name "BANYAN"] > > And the missing bit is the PADS packet (which we're expecting from the > PPPoE server). Here, the netgraph node is resending the PADR after 2 > seconds of inactivity, then dropping back to sending a PADI all over > again. > > Interestingly enough, the PADR doesn't seem to have the Service-Name > or Relay-Session-ID tags that the PADO has - perhaps that's what's > causing the problem... certainly the PADO handling code that sends > the PADS calls scan_tags() which is supposed to copy tags not already > handled from the PADO into the PADR. One of the #defines in ng_pppoe is wrong and has been corrected.. he's going to retry for us with the new version. however without going to look at the code again I couldn't say why the PADR didn't copy the service name Good to see you back Brian.. we've missed you (especially with ppp questions :-) > > Julian, have you any comments on this ? > > Cheers. > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 21:36:27 2004 Return-Path: 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 D4F4916A4CF for ; Mon, 21 Jun 2004 21:36:27 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 185AE43D39 for ; Mon, 21 Jun 2004 21:36:27 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 54840 invoked from network); 21 Jun 2004 21:36:26 -0000 Received: from unknown (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 21 Jun 2004 21:36:26 -0000 Message-ID: <40D754D5.1070805@freebsd.org> Date: Mon, 21 Jun 2004 23:36:21 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 21:36:28 -0000 Here is the next preview patch for the ipfw to pfil_hooks conversion: http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff This patch significantly cleans up ip_input.c and ip_output.c. The following is included in this patch: o Remove all ipfw related cruft from ip_input() and ip_output() o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic o ipfw firewalling, divert and dummynet works fine o ipfw forward is not yet implemented again (comes next) o ipfw layer2 is not yet implemented again (comes next) o ip_reass() is a self-contained function now (external code only relocated) o All IP Options related functions of ip_input/ip_output are moved into their own ip_options.[ch] file to have them together in one place o Some other small work in progress Consider this a FYI. It is very much a WIP at the moment. I want to get this into the tree in before 5.3 code freeze. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 21 23:35:12 2004 Return-Path: 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 3E70516A4CE for ; Mon, 21 Jun 2004 23:35:12 +0000 (GMT) Received: from multivac.fatburen.org (multivac.fatburen.org [212.247.27.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C96843D48 for ; Mon, 21 Jun 2004 23:35:11 +0000 (GMT) (envelope-from staffan@ulfberg.se) Received: from multivac.fatburen.org (localhost [127.0.0.1]) i5LNYqDE071299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2004 01:34:52 +0200 (CEST) (envelope-from staffan@ulfberg.se) Received: (from staffanu@localhost) by multivac.fatburen.org (8.12.9p2/8.12.11/Submit) id i5LNYpxa071296; Tue, 22 Jun 2004 01:34:51 +0200 (CEST) (envelope-from staffan@ulfberg.se) Sender: staffan@ulfberg.se To: freebsd-net@freebsd.org References: <200406161646.49893.rneese@adelphia.net> <87zn73kmv9.fsf@multivac.fatburen.org> <20040617185902.GA24198@scylla.towardex.com> From: Staffan Ulfberg Date: 22 Jun 2004 01:34:51 +0200 In-Reply-To: <20040617185902.GA24198@scylla.towardex.com> Message-ID: <87oencjxic.fsf@multivac.fatburen.org> Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on multivac.fatburen.org cc: James Subject: Re: IPFW questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 23:35:12 -0000 I've played around a bit more with my 300 MHz firewall now. Actually, even if I completely disable natd, and use only a single pass-all firewall rule, I can't get over about 30 MBps, at 2500 packets per second, through the machine. (I used netstat -i -b to measure traffic.) I tried the link0 option for both interfaces (fxp), which helped only slightly. (If anyone remembers the original post, I'm testing by transferring files from fxp1 to fxp3.) I also tried compiling a kernel with DEVICE_POLLING. At 500 Hz, routing performance is about the same as with normal interrupts, but with slightly better overall system response. Over that (tried 1000, 2000 Hz) and the system is very unresponsive and I believed it had hanged several times (but it hadn't). BTW, can anyone tell me why the system clock gets slowed down a factor of two or more when using DEVICE_POLLING? (And, of course, if there's a fix...) Is this machine simply too slow to use even as a simple router for 100 Mbps traffic? I must say I'm a bit surprised. Or any tuning suggestions? Staffan From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 07:02:09 2004 Return-Path: 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 A237E16A4CE for ; Tue, 22 Jun 2004 07:02:09 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 6FB6A43D6A for ; Tue, 22 Jun 2004 07:02:09 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.231.39 with login) by smtp003.bizmail.yahoo.com with SMTP; 22 Jun 2004 07:02:08 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 16EF26185 for ; Tue, 22 Jun 2004 02:02:08 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01960-07 for ; Tue, 22 Jun 2004 02:02:06 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 888226183 for ; Tue, 22 Jun 2004 02:02:06 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.12.11/8.12.11) with ESMTP id i5M726lQ093277 for ; Tue, 22 Jun 2004 02:02:06 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <40D7D96E.5060109@alumni.rice.edu> Date: Tue, 22 Jun 2004 02:02:06 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.6 (X11/20040531) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org Subject: kern/68110 (rfc 3522) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 07:02:09 -0000 Has anyone looked at kern/68110? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110 Jon Noack From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 08:15:41 2004 Return-Path: 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 447CE16A4CE; Tue, 22 Jun 2004 08:15:41 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53BFE43D45; Tue, 22 Jun 2004 08:15:40 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (6gw3q78u@mp2.macomnet.net [195.128.64.6]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i5M8FLu517281632; Tue, 22 Jun 2004 12:15:21 +0400 (MSD) Date: Tue, 22 Jun 2004 12:15:21 +0400 (MSD) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <40D754D5.1070805@freebsd.org> Message-ID: <20040622115532.W5744@mp2.macomnet.net> References: <40D754D5.1070805@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 08:15:41 -0000 Hi Andre, On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote: > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > This patch significantly cleans up ip_input.c and ip_output.c. > > The following is included in this patch: > > o Remove all ipfw related cruft from ip_input() and ip_output() > o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic > > o ipfw firewalling, divert and dummynet works fine > > o ipfw forward is not yet implemented again (comes next) > o ipfw layer2 is not yet implemented again (comes next) > > o ip_reass() is a self-contained function now (external code only relocated) > > o All IP Options related functions of ip_input/ip_output are moved into > their > own ip_options.[ch] file to have them together in one place > > o Some other small work in progress Is it possible to split that ~100KB patch in a logic chunks? One for phil_hook, one for ip_pcbopt, one for ip_reass etc. Much easier to review and commit them later. > Consider this a FYI. It is very much a WIP at the moment. I want > to get this into the tree in before 5.3 code freeze. In fact, our real world tests shown the current -CURRENT comparing to RELENG_5_2 is in a very bad shape. Is it really worth to commit that mostly cleanup code before say 6-CURRENT with a chance to destabilizate -CURRENT a bit more? -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 08:29:17 2004 Return-Path: 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 A8F8716A4CE; Tue, 22 Jun 2004 08:29:17 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECDC743D41; Tue, 22 Jun 2004 08:29:16 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1BcgeP-000DXq-00; Tue, 22 Jun 2004 10:29:05 +0200 To: Andre Oppermann From: Ian FREISLICH In-reply-to: Your message of "Mon, 21 Jun 2004 23:36:21 +0200." <40D754D5.1070805@freebsd.org> X-Attribution: BOFH Date: Tue, 22 Jun 2004 10:29:05 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 08:29:17 -0000 Andre Oppermann wrote: > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > This patch significantly cleans up ip_input.c and ip_output.c. That would be a very a nice thing, but it looks like this breaks the patch that I submitted (kern/64240) which fixes the acknowledged problem with 'ipfw tee' accepting packets instead of copying them to the divert port and then processing the packet according to the rest of the rule set. There have been about 5 PRs (most with patches) in the past years which all claim to fix this problem indicating that here is a need for a fix. We rely on the fix in kern/64240 to collect traffic accounting information for billing and statistical purposes. There hasn't been much interest from the committers in having a look at this even though the work has already been done. Now that you're actively working on that part of the source, would it be possible to take a look? I would also be happy to create a new patch to fix this problem against ipfw with pfilhooks if that's what it's going to take to get a fix committed. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:06:30 2004 Return-Path: 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 A657F16A4CE; Tue, 22 Jun 2004 09:06:30 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4550843D55; Tue, 22 Jun 2004 09:06:30 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i5M96Kgd017409; Tue, 22 Jun 2004 02:06:20 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i5M96KoH017408; Tue, 22 Jun 2004 02:06:20 -0700 (PDT) (envelope-from rizzo) Date: Tue, 22 Jun 2004 02:06:20 -0700 From: Luigi Rizzo To: Maxim Konovalov Message-ID: <20040622020620.A16578@xorpc.icir.org> References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040622115532.W5744@mp2.macomnet.net>; from maxim@macomnet.ru on Tue, Jun 22, 2004 at 12:15:21PM +0400 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:06:30 -0000 On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote: ... > > Consider this a FYI. It is very much a WIP at the moment. I want > > to get this into the tree in before 5.3 code freeze. > > In fact, our real world tests shown the current -CURRENT comparing to > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > mostly cleanup code before say 6-CURRENT with a chance to of course it is! i also do not follow the reasoning -- given that it is cleaning up code, it is only welcome at any stage except perhaps in code freeze. plus, is the 'bad shape' related at all to what andre posted ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:23:55 2004 Return-Path: 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 7211616A4CE; Tue, 22 Jun 2004 09:23:55 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A37E43D5E; Tue, 22 Jun 2004 09:23:55 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 4738F530D; Tue, 22 Jun 2004 11:23:54 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 97E34530A; Tue, 22 Jun 2004 11:23:47 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 651A5B86C; Tue, 22 Jun 2004 11:23:47 +0200 (CEST) To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 22 Jun 2004 11:23:47 +0200 In-Reply-To: <20040622115532.W5744@mp2.macomnet.net> (Maxim Konovalov's message of "Tue, 22 Jun 2004 12:15:21 +0400 (MSD)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:23:55 -0000 Maxim Konovalov writes: > In fact, our real world tests shown the current -CURRENT comparing to > RELENG_5_2 is in a very bad shape. You'll have to substantiate that. All *my* real world tests show that -CURRENT is a lot more stable and functional than RELENG_5_2. > Is it really worth to commit that > mostly cleanup code before say 6-CURRENT with a chance to > destabilizate -CURRENT a bit more? It is not simply cleanup, it is very important and long-expected cleanup. Delaying it until after the branch will only make matters worse, by accelerating code drift between HEAD and 5-STABLE. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:30:09 2004 Return-Path: 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 822F416A4CE; Tue, 22 Jun 2004 09:30:09 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96EEB43D41; Tue, 22 Jun 2004 09:30:08 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (pm69ft3t@mp2.macomnet.net [195.128.64.6]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i5M9Tqu517334944; Tue, 22 Jun 2004 13:29:52 +0400 (MSD) Date: Tue, 22 Jun 2004 13:29:52 +0400 (MSD) From: Maxim Konovalov To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: <20040622132451.K6489@mp2.macomnet.net> References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:30:09 -0000 On Tue, 22 Jun 2004, 11:23+0200, Dag-Erling Sm?rgrav wrote: > Maxim Konovalov writes: > > In fact, our real world tests shown the current -CURRENT comparing to > > RELENG_5_2 is in a very bad shape. > > You'll have to substantiate that. All *my* real world tests show that > -CURRENT is a lot more stable and functional than RELENG_5_2. Yesterday -CURRENT leaks kernel memory very quickly and panics after 10 - 15 mins up. Machine is 2x3GHz Xeon, 4GB RAM, ~5000 httpd/ftpd tcp sessions, 300-400Mbps output, ~50TB output in a day. The same config (kernel, sysctl's, loader tunables, hardware) works well with RELENG_5_2. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:35:54 2004 Return-Path: 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 55B6316A4CE; Tue, 22 Jun 2004 09:35:54 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A37C243D1D; Tue, 22 Jun 2004 09:35:53 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (q4n26rvr@mp2.macomnet.net [195.128.64.6]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i5M9ZIu517026503; Tue, 22 Jun 2004 13:35:18 +0400 (MSD) Date: Tue, 22 Jun 2004 13:35:18 +0400 (MSD) From: Maxim Konovalov To: Luigi Rizzo In-Reply-To: <20040622020620.A16578@xorpc.icir.org> Message-ID: <20040622133000.T6489@mp2.macomnet.net> References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622020620.A16578@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:35:54 -0000 On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote: > On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote: > ... > > > Consider this a FYI. It is very much a WIP at the moment. I want > > > to get this into the tree in before 5.3 code freeze. > > > > In fact, our real world tests shown the current -CURRENT comparing to > > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > > mostly cleanup code before say 6-CURRENT with a chance to > > of course it is! i also do not follow the reasoning -- given that it is > cleaning up code, it is only welcome at any stage except perhaps > in code freeze. My concern is bugs. Especially in cleanup code, especially in ip_pcbopt and ip_reass. > plus, is the 'bad shape' related at all to what andre posted ? 'bad shape' is related to 5-CURRENT we are trying to make -STABLE. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:49:48 2004 Return-Path: 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 38F9F16A4CE; Tue, 22 Jun 2004 09:49:48 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 005C643D1F; Tue, 22 Jun 2004 09:49:48 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3DFAA530D; Tue, 22 Jun 2004 11:49:25 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 997F35309; Tue, 22 Jun 2004 11:49:18 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 4E7A7B86C; Tue, 22 Jun 2004 11:49:18 +0200 (CEST) To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622132451.K6489@mp2.macomnet.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 22 Jun 2004 11:49:18 +0200 In-Reply-To: <20040622132451.K6489@mp2.macomnet.net> (Maxim Konovalov's message of "Tue, 22 Jun 2004 13:29:52 +0400 (MSD)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:49:48 -0000 Maxim Konovalov writes: > Yesterday -CURRENT leaks kernel memory very quickly and panics after > 10 - 15 mins up. Nope. That bug was introduced on June 9th, almost two weeks ago, and it was fixed less than twelve hours later. I have several machines already running yesterday's -CURRENT, and none of them show signs of any kind of leak. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:51:08 2004 Return-Path: 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 E21AA16A4CE; Tue, 22 Jun 2004 09:51:08 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B3843D1F; Tue, 22 Jun 2004 09:51:08 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i5M9osgd020244; Tue, 22 Jun 2004 02:50:54 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i5M9oseu020243; Tue, 22 Jun 2004 02:50:54 -0700 (PDT) (envelope-from rizzo) Date: Tue, 22 Jun 2004 02:50:54 -0700 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20040622025054.B18617@xorpc.icir.org> References: <40D754D5.1070805@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40D754D5.1070805@freebsd.org>; from andre@freebsd.org on Mon, Jun 21, 2004 at 11:36:21PM +0200 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:51:09 -0000 On Mon, Jun 21, 2004 at 11:36:21PM +0200, Andre Oppermann wrote: > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > This patch significantly cleans up ip_input.c and ip_output.c. > assorted comments: - understood that this is WIP, but as someone else suggested it would be a lot better to split the patch in logical chunks and apply them one at a time. Especially because they seem to have different importance, e.g. (as far as i can tell): + ipfw pfil stuff i surely consider this extremely useful and welcome, but would prefer to put the hooks in ip_fw2.c instead of using a separate file -- both to keep ipfw stuff confined, and to use stricter compiler checks (e.g. define stuff static as much as possible, avoid exporting internal APIs, etc.) The only motivation against it would be if we plan to backport this stuff to 4.x where we still have the option of using ipfw1. + ip_reass replacement + ip options processing on this particular one i am a bit unsure -- what is the point for just moving stuff to a separate file instead of leaving it where it is (ip_input/ip_output) so that many functions that are only used there can be declared static as they are now ? I'd rather just apply bugfixes. generally, i have become a big fan of very strict compiler checks -- lately they have saved me a huge amount of time in identifying dead code, inconsistent interfaces and other bugs, so when in doubt between two alternatives i tend to privilege the one that gives more chances to the compiler to check things. > o ipfw forward is not yet implemented again (comes next) > o ipfw layer2 is not yet implemented again (comes next) of course it is fundamental to preserve the entire existing functionality before the commit cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 09:54:13 2004 Return-Path: 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 1083E16A4CE; Tue, 22 Jun 2004 09:54:13 +0000 (GMT) Received: from mailbox.rainbownet.com (mailbox.rainbownet.com [213.174.191.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B7F43D4C; Tue, 22 Jun 2004 09:54:11 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from nbangx ([151.38.10.253]) (authenticated user aturetta@rainbownet.com) by rainbownet.com (rainbownet.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 24-md50000000667.tmp; Tue, 22 Jun 2004 11:53:58 +0200 Message-ID: <006901c4583e$b651fe60$5a2ba8c0@lan> From: "Angelo Turetta" To: References: <40D754D5.1070805@freebsd.org> Date: Tue, 22 Jun 2004 11:52:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: aturetta@rainbownet.com X-Spam-Processed: rainbownet.com, Tue, 22 Jun 2004 11:53:58 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 151.38.10.253 X-Return-Path: aturetta@commit.it cc: freebsd-net@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 09:54:13 -0000 ----- Original Message ----- From: "Andre Oppermann" Sent: Monday, June 21, 2004 11:36 PM > This patch significantly cleans up ip_input.c and ip_output.c. > > The following is included in this patch: > > o Remove all ipfw related cruft from ip_input() and ip_output() > o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic IIRC, I had once a problem with a mixed setup where I used IPFILTER NAT & IPFW DUMMYNET. Basically, there was an asymmetry in the order the two filters were called, because the code in ip_input.c called IPFILTER before entering the IPFW code, and ip_output.c did the same, while it should have called first IPFW then IPFILTER. (beware, it might have been the opposite WRT what was first in which function, I don't remember exactly). Does your new code take this ordering issue into account? I suppose it would be nice to be able to control the order filters are processed: I may like IPFW to be 'wrapping' IPFILTER (that is, called before it during input, and after it during output), while others might prefer the opposite. And anyway, am I right the filter list should be traversed in opposite directions during input versus output (maybe it's already so). Ciao, Angelo. From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 10:01:07 2004 Return-Path: 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 246A216A4CE; Tue, 22 Jun 2004 10:01:07 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5533B43D5A; Tue, 22 Jun 2004 10:01:06 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (zgibwn32@mp2.macomnet.net [195.128.64.6]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i5MA12u517184571; Tue, 22 Jun 2004 14:01:02 +0400 (MSD) Date: Tue, 22 Jun 2004 14:01:02 +0400 (MSD) From: Maxim Konovalov To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: <20040622140022.C6641@mp2.macomnet.net> References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622132451.K6489@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 10:01:07 -0000 On Tue, 22 Jun 2004, 11:49+0200, Dag-Erling Sm?rgrav wrote: > Maxim Konovalov writes: > > Yesterday -CURRENT leaks kernel memory very quickly and panics after > > 10 - 15 mins up. > > Nope. That bug was introduced on June 9th, almost two weeks ago, and Nope :-) $ ident /usr/src-5-current/sys/kern/uipc_syscalls.c /usr/src-5-current/sys/kern/uipc_syscalls.c: $FreeBSD: src/sys/kern/uipc_syscalls.c,v 1.194 2004/06/19 03:23:14 rwatson Exp $ We have a fixed version. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 10:20:07 2004 Return-Path: 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 62CE316A4CE; Tue, 22 Jun 2004 10:20:07 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1D1343D55; Tue, 22 Jun 2004 10:20:06 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 7E636530D; Tue, 22 Jun 2004 12:20:05 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 5D8355309; Tue, 22 Jun 2004 12:19:57 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 43E2EB86C; Tue, 22 Jun 2004 12:19:57 +0200 (CEST) To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622132451.K6489@mp2.macomnet.net> <20040622140022.C6641@mp2.macomnet.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 22 Jun 2004 12:19:57 +0200 In-Reply-To: <20040622140022.C6641@mp2.macomnet.net> (Maxim Konovalov's message of "Tue, 22 Jun 2004 14:01:02 +0400 (MSD)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 10:20:07 -0000 Maxim Konovalov writes: > $ ident /usr/src-5-current/sys/kern/uipc_syscalls.c Wrong file - but this is pointless, anyway. You are generalizing from a single data point. I can show you a room full of servers that can't run 5.2.1 due to bugs in the ACPI support code and in two different RAID controller drivers (aac and twe). They all run -CURRENT just fine. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:35:07 2004 Return-Path: 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 294B616A4CE for ; Tue, 22 Jun 2004 11:35:07 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A46043D46 for ; Tue, 22 Jun 2004 11:35:06 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 68394 invoked from network); 22 Jun 2004 11:35:03 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:35:03 -0000 Message-ID: <40D8196C.BCC22323@freebsd.org> Date: Tue, 22 Jun 2004 13:35:08 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: noackjr@alumni.rice.edu References: <40D7D96E.5060109@alumni.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/68110 (rfc 3522) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:35:07 -0000 Jon Noack wrote: > > Has anyone looked at kern/68110? > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110 The situation is a little bit complicated. I agree that having RFC3522 is a good thing. However there is a political problem with the author of the rfc3522 of DFBSD. He is also still a FreeBSD committer, but for political reasons he has very much refrained from doing any FreeBSD work for about a year now. About six or seven month ago I had a port of rfc3522 ready in my tree and wanted to commit it. He vetoed me and said he would do it by himself. Yet for those political reasons he wont do any work on FreeBSD including this. The only way to solve this is that either someone simply committs it (this is BSD licensed code after all) and pisses him off, or someone convinces him to do it himself (which I don't think he will). Deadlock... -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:38:56 2004 Return-Path: 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 40FF316A4CE for ; Tue, 22 Jun 2004 11:38:56 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71E7543D5D for ; Tue, 22 Jun 2004 11:38:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 69162 invoked from network); 22 Jun 2004 11:38:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:38:54 -0000 Message-ID: <40D81A53.FD490D89@freebsd.org> Date: Tue, 22 Jun 2004 13:38:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:38:56 -0000 Maxim Konovalov wrote: > > Hi Andre, > > On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote: > > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > Is it possible to split that ~100KB patch in a logic chunks? One for > phil_hook, one for ip_pcbopt, one for ip_reass etc. Much easier to > review and commit them later. Of course it will be split up. I haven't done this because this is only a preview patch of work in progress. > > Consider this a FYI. It is very much a WIP at the moment. I want > > to get this into the tree in before 5.3 code freeze. > > In fact, our real world tests shown the current -CURRENT comparing to > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > mostly cleanup code before say 6-CURRENT with a chance to > destabilizate -CURRENT a bit more? This will not destabilize -CURRENT anymore. Any errors in the code are seen immediatly. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:41:33 2004 Return-Path: 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 EBF2816A4CE for ; Tue, 22 Jun 2004 11:41:33 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BC6D43D5D for ; Tue, 22 Jun 2004 11:41:33 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 69680 invoked from network); 22 Jun 2004 11:41:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:41:30 -0000 Message-ID: <40D81AEF.20579AAC@freebsd.org> Date: Tue, 22 Jun 2004 13:41:35 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian FREISLICH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:41:34 -0000 Ian FREISLICH wrote: > > Andre Oppermann wrote: > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > That would be a very a nice thing, but it looks like this breaks > the patch that I submitted (kern/64240) which fixes the acknowledged > problem with 'ipfw tee' accepting packets instead of copying them > to the divert port and then processing the packet according to the > rest of the rule set. Hmmm... I'll have a look at kern/64240. I guess while I'm rewriting this stuff anyway I can fix this too in one go. > There have been about 5 PRs (most with patches) in the past years > which all claim to fix this problem indicating that here is a need > for a fix. We rely on the fix in kern/64240 to collect traffic > accounting information for billing and statistical purposes. There > hasn't been much interest from the committers in having a look at > this even though the work has already been done. Could you give me all PR numbers? That'll make it easier for me get the code in. > Now that you're actively working on that part of the source, would > it be possible to take a look? I would also be happy to create a > new patch to fix this problem against ipfw with pfilhooks if that's > what it's going to take to get a fix committed. It's ok, I don't need new patches against the converted pfil_hooks code. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:45:37 2004 Return-Path: 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 0D1AA16A4CE for ; Tue, 22 Jun 2004 11:45:37 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D28543D1F for ; Tue, 22 Jun 2004 11:45:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 70532 invoked from network); 22 Jun 2004 11:45:35 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:45:35 -0000 Message-ID: <40D81BE4.B82F01A3@freebsd.org> Date: Tue, 22 Jun 2004 13:45:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Konovalov References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <20040622133000.T6489@mp2.macomnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:45:37 -0000 Maxim Konovalov wrote: > > On Tue, 22 Jun 2004, 02:06-0700, Luigi Rizzo wrote: > > > On Tue, Jun 22, 2004 at 12:15:21PM +0400, Maxim Konovalov wrote: > > ... > > > > Consider this a FYI. It is very much a WIP at the moment. I want > > > > to get this into the tree in before 5.3 code freeze. > > > > > > In fact, our real world tests shown the current -CURRENT comparing to > > > RELENG_5_2 is in a very bad shape. Is it really worth to commit that > > > mostly cleanup code before say 6-CURRENT with a chance to > > > > of course it is! i also do not follow the reasoning -- given that it is > > cleaning up code, it is only welcome at any stage except perhaps > > in code freeze. > > My concern is bugs. Especially in cleanup code, especially in > ip_pcbopt and ip_reass. I do not modify ip_pcbopt in any way. All the IP Options stuff is simply a 1:1 code move to get them all in one single place. For ip_reass() I've taken a very conservative approach and just moved the external code into the function itself. In terms of coding style it looks a bit ugly but is a pure 1:1 adaption of the existing code. Thus I'm sure that I haven't changed the behaviour of the ip reassembly code in any way (except one). I agree that a rewrite of ip_reass() is a very delicate thing because of possible bugs, but that is not what I have done. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:49:00 2004 Return-Path: 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 CC73A16A4CE for ; Tue, 22 Jun 2004 11:49:00 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8E643D1F for ; Tue, 22 Jun 2004 11:49:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 71377 invoked from network); 22 Jun 2004 11:48:48 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 11:48:48 -0000 Message-ID: <40D81CA5.599AA4DB@freebsd.org> Date: Tue, 22 Jun 2004 13:48:53 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Angelo Turetta References: <40D754D5.1070805@freebsd.org> <006901c4583e$b651fe60$5a2ba8c0@lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:49:00 -0000 Angelo Turetta wrote: > > ----- Original Message ----- > From: "Andre Oppermann" > Sent: Monday, June 21, 2004 11:36 PM > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > The following is included in this patch: > > > > o Remove all ipfw related cruft from ip_input() and ip_output() > > o New ip_fw_pfil.c file which contains all ipfw/pfil_hooks logic > > IIRC, I had once a problem with a mixed setup where I used IPFILTER NAT & > IPFW DUMMYNET. Basically, there was an asymmetry in the order the two > filters were called, because the code in ip_input.c called IPFILTER before > entering the IPFW code, and ip_output.c did the same, while it should have > called first IPFW then IPFILTER. (beware, it might have been the opposite > WRT what was first in which function, I don't remember exactly). The new code fixes this. With ipfw using pfil_hooks the ordering will be preserved for input and output (reversed). > Does your new code take this ordering issue into account? I suppose it would > be nice to be able to control the order filters are processed: I may like > IPFW to be 'wrapping' IPFILTER (that is, called before it during input, and > after it during output), while others might prefer the opposite. And anyway, > am I right the filter list should be traversed in opposite directions during > input versus output (maybe it's already so). When you load the packet filters as kld's you can specify the order of processing yourself. For compiled in it depends which initialization function is called first. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 11:54:10 2004 Return-Path: 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 16E3116A4CE; Tue, 22 Jun 2004 11:54:10 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A105843D2D; Tue, 22 Jun 2004 11:54:09 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1Bcjqf-000ERQ-00; Tue, 22 Jun 2004 13:53:57 +0200 To: Andre Oppermann From: Ian FREISLICH In-Reply-To: Message from Andre Oppermann of "Tue, 22 Jun 2004 13:41:35 +0200." <40D81AEF.20579AAC@freebsd.org> Date: Tue, 22 Jun 2004 13:53:57 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 11:54:10 -0000 Andre Oppermann wrote: > > There have been about 5 PRs (most with patches) in the past years > > which all claim to fix this problem indicating that here is a need > > for a fix. We rely on the fix in kern/64240 to collect traffic > > accounting information for billing and statistical purposes. There > > hasn't been much interest from the committers in having a look at > > this even though the work has already been done. > > Could you give me all PR numbers? That'll make it easier for me > get the code in. They all do basically the same thing in varying ways. I think that all except for kern/64240 are against -STABLE. Here's what I can find quickly. There may be more lurking. kern/64240 kern/61259 kern/60377 kern/49959 > > Now that you're actively working on that part of the source, would > > it be possible to take a look? I would also be happy to create a > > new patch to fix this problem against ipfw with pfilhooks if that's > > what it's going to take to get a fix committed. > > It's ok, I don't need new patches against the converted pfil_hooks > code. Cool, thanks. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 12:00:51 2004 Return-Path: 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 329A716A4DC for ; Tue, 22 Jun 2004 12:00:51 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6196743D55 for ; Tue, 22 Jun 2004 12:00:50 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 74307 invoked from network); 22 Jun 2004 12:00:49 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 22 Jun 2004 12:00:49 -0000 Message-ID: <40D81F76.296C2A4@freebsd.org> Date: Tue, 22 Jun 2004 14:00:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <40D754D5.1070805@freebsd.org> <20040622025054.B18617@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 12:00:51 -0000 Luigi Rizzo wrote: > > On Mon, Jun 21, 2004 at 11:36:21PM +0200, Andre Oppermann wrote: > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > assorted comments: > - understood that this is WIP, but as someone else suggested it would > be a lot better to split the patch in logical chunks and apply them > one at a time. Especially because they seem to have different importance, > e.g. (as far as i can tell): Sure thing that I will split it up. It's just more convinient for me to diff up one big patch at the moment. > + ipfw pfil stuff > i surely consider this extremely useful and welcome, but would > prefer to put the hooks in ip_fw2.c instead of using a > separate file -- both to keep ipfw stuff confined, and to > use stricter compiler checks (e.g. define stuff static as > much as possible, avoid exporting internal APIs, etc.) > The only motivation against it would be if we plan to > backport this stuff to 4.x where we still have the option > of using ipfw1. I don't have any plans to backport it to 4.x. I chose to work with an external file at the moment for convinience. This way I don't have to scroll through thousands of lines each time. > + ip_reass replacement > > + ip options processing > on this particular one i am a bit unsure -- what is the point > for just moving stuff to a separate file instead of leaving > it where it is (ip_input/ip_output) so that many functions > that are only used there can be declared static as they are now ? > I'd rather just apply bugfixes. There are no bugs except one static variable which is used for packets in transit. I'll convert that to an m_tag before it goes in. Generally the ip_input.c and ip_output.c files have become very large and moving the ip options related functions out to their own file is makes it a lot more readable and sorted/ordered. IP options are only rarely used these days. Most of the functions either take an mbuf or a socket so there is not much to break. > generally, i have become a big fan of very strict compiler checks -- lately > they have saved me a huge amount of time in identifying dead code, > inconsistent interfaces and other bugs, so when in doubt between two > alternatives i tend to privilege the one that gives more chances to > the compiler to check things. Yea, on the hand we don't want to have everything in one file because that would make the checks as useful as not doing it. Normally in my coding style I prefer the safe variants, like bzero'ing entire structs instead of doing it piece-meal throughout the code that follows. Because one day someone will change the order of some code parts and *poof* things break in subtile and hard to debug ways. > > o ipfw forward is not yet implemented again (comes next) > > o ipfw layer2 is not yet implemented again (comes next) > > of course it is fundamental to preserve the entire existing > functionality before the commit Sure. As I said, this is WIP. And when I reach the point of current functionality == new functionality then I'll go and commit it. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 12:29:07 2004 Return-Path: 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 BF90816A4CE; Tue, 22 Jun 2004 12:29:07 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC86C43D54; Tue, 22 Jun 2004 12:29:04 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (remyxi0k@mp2.macomnet.net [195.128.64.6]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i5MCT1u517292108; Tue, 22 Jun 2004 16:29:01 +0400 (MSD) Date: Tue, 22 Jun 2004 16:29:01 +0400 (MSD) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <40D81A53.FD490D89@freebsd.org> Message-ID: <20040622162616.O7191@mp2.macomnet.net> References: <40D754D5.1070805@freebsd.org> <20040622115532.W5744@mp2.macomnet.net> <40D81A53.FD490D89@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 12:29:07 -0000 On Tue, 22 Jun 2004, 13:38+0200, Andre Oppermann wrote: > Maxim Konovalov wrote: > > > > Hi Andre, > > > > On Mon, 21 Jun 2004, 23:36+0200, Andre Oppermann wrote: > > > > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > Is it possible to split that ~100KB patch in a logic chunks? One for > > phil_hook, one for ip_pcbopt, one for ip_reass etc. Much easier to > > review and commit them later. > > Of course it will be split up. I haven't done this because this is > only a preview patch of work in progress. Please HEADSUP us before commit or drop me a note, I am willing to review reass/ip options code as I spent a lot of hours parsing it. As a side note, what is "#define MAX_IPOPTLEN 40" in ip_options.h for? There is one in ip_var.h. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 12:38:54 2004 Return-Path: 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 9B2B816A4CE for ; Tue, 22 Jun 2004 12:38:54 +0000 (GMT) Received: from web60808.mail.yahoo.com (web60808.mail.yahoo.com [216.155.196.71]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E29343D5F for ; Tue, 22 Jun 2004 12:38:54 +0000 (GMT) (envelope-from yohanphilip@yahoo.com) Message-ID: <20040622123825.91569.qmail@web60808.mail.yahoo.com> Received: from [61.3.97.7] by web60808.mail.yahoo.com via HTTP; Tue, 22 Jun 2004 05:38:25 PDT Date: Tue, 22 Jun 2004 05:38:25 -0700 (PDT) From: Yohan To: Gleb Smirnoff , freebsd-net@freebsd.org In-Reply-To: <20040621183911.GB75785@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: PPPoE RESOLVED X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 12:38:54 -0000 I tried the ng_pppoe.c, ng_pppoe.h from latest STABLE. But got compile errors. Instead of tracing the source i just downloaded the 4.10 STABLE and ITS WORKING. Seems the problem was exactly as pointed out. Gleb thanks a TON for keeping my hopes alive with your prompt replies. I dont have to get back to W2K. Thanks to the other too for your help. regards Yohann --- Gleb Smirnoff wrote: > On Mon, Jun 21, 2004 at 06:56:39AM -0700, Yohan > wrote: > Y> Thanks for keeping my hopes alive. I have a > question > Y> .. do i upgrade or downgrade and will it work. > because > Y> upgrading a production machine for me is > slightly > Y> time consuming. If thats the way to go .. i will. > will > Y> take ur advice for it. i have freebsd 4.9 > presently. i > Y> also do have 4.8 cd;s only .. should i download > 4.10 / > Y> 5.2 and upgrade or use 4.8. If i could make > changes to > Y> the present and recompile kernel or whatever > kindly > Y> let me know whats required. > > Just grab ng_pppoe.c, ng_pppoe.h from latest STABLE > from > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph > > and recompile your kernel (or ng_pppoe.ko). > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:32:26 2004 Return-Path: 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 0881116A4CE; Tue, 22 Jun 2004 15:32:26 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C8C243D2D; Tue, 22 Jun 2004 15:32:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4815165218; Tue, 22 Jun 2004 16:32:15 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67609-02-12; Tue, 22 Jun 2004 16:32:15 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 9138A65216; Tue, 22 Jun 2004 16:32:09 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id AD8476150; Tue, 22 Jun 2004 16:32:07 +0100 (BST) Date: Tue, 22 Jun 2004 16:32:07 +0100 From: Bruce M Simpson To: freebsd-net@FreeBSD.org Message-ID: <20040622153207.GB1961@empiric.dek.spc.org> Mail-Followup-To: freebsd-net@FreeBSD.org, dwmalone@FreeBSD.org, fenner@FreeBSD.org, wietse@porcupine.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: fenner@FreeBSD.org cc: dwmalone@FreeBSD.org cc: wietse@porcupine.org Subject: tcp_wrappers: accumulated change-request PRs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 15:32:26 -0000 Hi all, Whilst scanning GNATS, I found a number of PRs relating to requests for tcp_wrappers functionality and some outright bugfixes. Rather than commit these as-is, I think we should push the changes back to Wietse, as we maintain tcp_wrappers on a vendor branch. The PRs in question are: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/31034 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32808 http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/36556 http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/42336 What does everyone else think? Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:42:48 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC5516A4CE; Tue, 22 Jun 2004 15:42:48 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1E8843D45; Tue, 22 Jun 2004 15:42:47 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) i5MFgjNn072392; Tue, 22 Jun 2004 15:42:45 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5MFgjhC072388; Tue, 22 Jun 2004 15:42:45 GMT (envelope-from bms) Date: Tue, 22 Jun 2004 15:42:45 GMT From: Bruce M Simpson Message-Id: <200406221542.i5MFgjhC072388@freefall.freebsd.org> To: bms@FreeBSD.org, jlemon@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/15095: TCP's advertised window is not scaled immediately upon discovering use of Window scale option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 15:42:48 -0000 Synopsis: TCP's advertised window is not scaled immediately upon discovering use of Window scale option Responsible-Changed-From-To: jlemon->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Tue Jun 22 15:42:10 GMT 2004 Responsible-Changed-Why: Throw this one over to the -net list. http://www.freebsd.org/cgi/query-pr.cgi?pr=15095 From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 15:49:26 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38A3216A4CE; Tue, 22 Jun 2004 15:49:26 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B6BF43D39; Tue, 22 Jun 2004 15:49:26 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) i5MFn9TM072575; Tue, 22 Jun 2004 15:49:09 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5MFn9hx072571; Tue, 22 Jun 2004 15:49:09 GMT (envelope-from bms) Date: Tue, 22 Jun 2004 15:49:09 GMT From: Bruce M Simpson Message-Id: <200406221549.i5MFn9hx072571@freefall.freebsd.org> To: bms@FreeBSD.org, jesper@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/24959: proper TCP_NOPUSH/TCP_CORK compatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 15:49:26 -0000 Synopsis: proper TCP_NOPUSH/TCP_CORK compatibility Responsible-Changed-From-To: jesper->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Tue Jun 22 15:48:52 GMT 2004 Responsible-Changed-Why: Throw this one open to the -net list http://www.freebsd.org/cgi/query-pr.cgi?pr=24959 From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 16:12:36 2004 Return-Path: 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 98A1916A4CE; Tue, 22 Jun 2004 16:12:36 +0000 (GMT) Received: from cheer.mahoroba.org (flets20-147.kamome.or.jp [218.45.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE8043D2D; Tue, 22 Jun 2004 16:12:35 +0000 (GMT) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:U7n2maFWK06t2YbLEiZTLpcKLNXsVDAYopZeDOJU/Yfm3xDhc9rSh2z+H5iiyVpj@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i5MGC99T031476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jun 2004 01:12:10 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Wed, 23 Jun 2004 01:12:09 +0900 Message-ID: From: Hajimu UMEMOTO To: Bruce M Simpson In-Reply-To: <20040622153207.GB1961@empiric.dek.spc.org> References: <20040622153207.GB1961@empiric.dek.spc.org> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.2-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cheer.mahoroba.org cc: freebsd-net@FreeBSD.org cc: dwmalone@FreeBSD.org cc: wietse@porcupine.org cc: fenner@FreeBSD.org Subject: Re: tcp_wrappers: accumulated change-request PRs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 16:12:36 -0000 Hi, >>>>> On Tue, 22 Jun 2004 16:32:07 +0100 >>>>> Bruce M Simpson said: bms> Whilst scanning GNATS, I found a number of PRs relating to requests bms> for tcp_wrappers functionality and some outright bugfixes. Rather than bms> commit these as-is, I think we should push the changes back to Wietse, bms> as we maintain tcp_wrappers on a vendor branch. bms> The PRs in question are: bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/31034 bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32808 bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/36556 bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/42336 bms> What does everyone else think? Many part of our code is already off a vender branch since IPv6 support, and it seems Wietse doesn't maintain tcp_wrappers actively. So, I think it is better to integrate tcp_wrappers into our tree rather than maintaining it in contrib like NetBSD does. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 16:49:09 2004 Return-Path: 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 3589016A4CE; Tue, 22 Jun 2004 16:49:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14BD743D45; Tue, 22 Jun 2004 16:49:09 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) i5MGmdW1079860; Tue, 22 Jun 2004 16:48:39 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5MGmdPq079856; Tue, 22 Jun 2004 16:48:39 GMT (envelope-from bms) Date: Tue, 22 Jun 2004 16:48:39 GMT From: Bruce M Simpson Message-Id: <200406221648.i5MGmdPq079856@freefall.freebsd.org> To: bms@FreeBSD.org, guido@FreeBSD.org, net@FreeBSD.org Subject: Re: kern/23400: IPsec transport mode precludes filtering on underlying transport header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 16:49:09 -0000 Synopsis: IPsec transport mode precludes filtering on underlying transport header Responsible-Changed-From-To: guido->net Responsible-Changed-By: bms Responsible-Changed-When: Tue Jun 22 16:48:10 GMT 2004 Responsible-Changed-Why: Seems relevant to current work being done by andre@ and others in the area of layering/pfil_hooks http://www.freebsd.org/cgi/query-pr.cgi?pr=23400 From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 17:20:20 2004 Return-Path: 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 0275C16A4CE; Tue, 22 Jun 2004 17:20:20 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0BD843D55; Tue, 22 Jun 2004 17:20:19 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 5FD761FFDC1; Tue, 22 Jun 2004 19:20:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 61C7E1FF931; Tue, 22 Jun 2004 19:20:07 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id E2D641559A; Tue, 22 Jun 2004 17:18:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id D7D83154E5; Tue, 22 Jun 2004 17:18:24 +0000 (UTC) Date: Tue, 22 Jun 2004 17:18:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: References: <20040622153207.GB1961@empiric.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: wietse@porcupine.org cc: freebsd-net@FreeBSD.org Subject: Re: tcp_wrappers: accumulated change-request PRs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 17:20:20 -0000 On Wed, 23 Jun 2004, Hajimu UMEMOTO wrote: > >>>>> On Tue, 22 Jun 2004 16:32:07 +0100 > >>>>> Bruce M Simpson said: > > bms> Whilst scanning GNATS, I found a number of PRs relating to requests > bms> for tcp_wrappers functionality and some outright bugfixes. Rather than > bms> commit these as-is, I think we should push the changes back to Wietse, > bms> as we maintain tcp_wrappers on a vendor branch. > > bms> The PRs in question are: > bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/31034 > bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32808 > bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/36556 > bms> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/42336 > > bms> What does everyone else think? > > Many part of our code is already off a vender branch since IPv6 > support, and it seems Wietse doesn't maintain tcp_wrappers actively. Post from Wietse (who is on Cc: as I see) about this from yesterday ... http://marc.theaimsgroup.com/?l=postfix-users&m=108784059323250&w=2 /me remebers to have sent some patches to Wietse in 2002 that luckily didn't get comitted though CIDR notation is pretty nice ;-) -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 18:01:24 2004 Return-Path: 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 A7BEA16A4CE for ; Tue, 22 Jun 2004 18:01:24 +0000 (GMT) Received: from web60206.mail.yahoo.com (web60206.mail.yahoo.com [216.109.118.101]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A44143D2F for ; Tue, 22 Jun 2004 18:01:24 +0000 (GMT) (envelope-from freebsder51@yahoo.com) Message-ID: <20040622180120.10499.qmail@web60206.mail.yahoo.com> Received: from [67.69.62.157] by web60206.mail.yahoo.com via HTTP; Tue, 22 Jun 2004 11:01:20 PDT Date: Tue, 22 Jun 2004 11:01:20 -0700 (PDT) From: freebsder To: freebsd-newbies@freebsd.org, freebsd-isp@freebsd.org, freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: FreeBSD 5.1 DSL:Bellnet HS Network Connection Set-up Problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 18:01:24 -0000 <><><><>NETWORK CONFIG/SETUP: <><><><> +++ISP -> DSL(high-speed) -> Modem> FreeBSD51 server machine in at Gateway "vr0" (192.168.0.1) +++Freebsd machine LAN Interface at "ed0" (192.168.0.3) -> HUB +++HUB> 1) 192.168.0.2 - WinXP #1 machine 2) 192.168.0.3 - Freebsd machine in at "ed0" 3) 192.168.0.4 - Winxp #2 machine At the moment, I've just got the HUB connected to the freebsdmachine at "ed0" and will connect the others as soon as I get the server online. <><><><><>The PROBLEM:<><><><> I cannot get my server connected to the internet through the gateway. What am I doing wrong? <><><><><>RC.CONF:<><><><><><> font8x14="NO" font8x16="swiss-8x16" font8x8="swiss-8x8" inetd_enable="YES" linux_enable="YES" moused_enable="YES" moused_port="/dev/psm0" moused_type="auto" nfs_client_enable="YES" nfs_server_enable="YES" rpcbind_enable="YES" saver="rain" scrnmap="NO" usbd_enable="YES" ifconfig_vr0="DHCP" ifconfig_ed0="DHCP" ##initialise NIC network_interfaces="vr0 ed0 lo0 tun0" ifconfig tun0 ifconfig vr0= "media 10baseT/UTP up" ifconfig_ed0="inet 192.168.0.3 netmask 255.255.0.0" #ifconfig_vr0="inet 192.168.0.1 netmask 255.255.0.0" #sendmail_enable="YES" hostname="myhostname" ##User ppp configuration ppp_enable="YES" ppp_mode="ddial" ppp_nat="NO" ppp_profile="bellnet" #ppp_user="root" ## Firewall gateway_enable="YES" firewall_enable="YES" firewall_type="SIMPLE" #firewall_quiet="NO" firewall_script="/etc/rc/firewall" natd_enable="YES" natd_interface="vr0" natd_flags="redirect_port tcp 192.168.0.3:80 80" rpc_statd_enable="YES" tcp_extensions="YES" <><><><><><>PPP.CONF:<><><><><><> default: # PPP over Ethernet set device PPPoE:vr0:bellnet set speed sync set mru 1492 set mtu 1492 set crtscts off # Monitor Line Quality disable lqr set log phase tun #ident user-ppp VERSION (built COMPILATIONDATE) #set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255 0.0.0.0 #set ifaddr 10.0.0.1/0 10.0.0.2/0 #set accmap on #enable lqr #set timeout 0 #set redial 0 0 #NAT #nat enable yes #nat log yes #nat same_ports yes #nat unregistered_only yes #enable dns bellnet: set device PPPoE:vr0 set authname myauthname set authkey myauthkey set dial set login set mtu 1492 disable lqr set socket /tmp/ppp.sock 1234 add default HISADDR <><><><><>SHELL DIALOGS: <><><><><> <>1<> # ppp -ddial -quiet bellnet Warning: Local: bind: Address already in use Warning: set socket: Failed 2 <>2<> #ifconfig ed0: flags=8843 mtu 1500 inet 192.168.0.3 netmask 0xffff0000 broadcast 192.168.255.255 inet6 fe80::280:c8ff:fede:c937%ed0 prefixlen 64 scopeid 0x1 ether 00:80:c8:de:c9:37 vr0: flags=8843 mtu 1500 inet6 fe80::20e:a6ff:fe9c:c81d%vr0 prefixlen 64 scopeid 0x2 ether 00:0e:a6:9c:c8:1d media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8051 mtu 1492 inet 65.92.***.*** --> 64.230.***.*** netmask 0xffffffff Opened by PID 250 tun1: flags=8051 mtu 1500 Opened by PID 741 ppp0: flags=8010 mtu 1500 tun2: flags=8051 mtu 1500 Opened by PID 807 tun3: flags=8051 mtu 1500 Opened by PID 954 <>3<> # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 64.230.***.*** UGSc 2 27 tun0 64.230.***.*** 65.92.***.*** UH 3 15 tun0 127.0.0.1 127.0.0.1 UH 0 135 lo0 192.168.0/16 link#1 UC 0 0 ed0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%ed0/64 link#1 UC ed0 fe80::280:c8ff:fede:c937%ed0 00:80:c8:de:c9:37 UHL lo0 fe80::%vr0/64 link#2 UC vr0 fe80::20e:a6ff:fe9c:c81d%vr0 00:0e:a6:9c:c8:1d UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#4 UHL lo0 ff01::/32 ::1 U lo0 ff02::%ed0/32 link#1 UC ed0 ff02::%vr0/32 link#2 UC vr0 ff02::%lo0/32 ::1 UC lo0 ff02::%tun0/32 fe80::280:c8ff:fede:c937%tun0 UC tun0 ff02::%tun1/32 fe80::280:c8ff:fede:c937%tun1 UC tun1 ff02::%tun2/32 fe80::280:c8ff:fede:c937%tun2 UC tun2 ff02::%tun3/32 fe80::280:c8ff:fede:c937%tun3 UGS tun3 <>4<> # ppp Working in interactive mode Using interface: tun4 ppp ON thor> show physical Name: deflink State: closed Device: N/A Link Type: interactive Connect Count: 0 Queued Packets: 0 Phone Number: N/A Defaults: Device List: "PPPoE:vr0:bellnet" Characteristics: sync, cs8, no parity, CTS/RTS off CD check delay: device specific Connect time: 0:00:00 0 octets in, 0 octets out 0 packets in, 0 packets out Overall 0 bytes/sec ppp ON thor> dial ppp ON thor> Warning: Sending empty PAP authname! Ppp ON thor> Warning: Sending empty PAP authname! Warning: Sending empty PAP authname! ppp ON thor> dial bellnet Warning: Local: bind: Address already in use Warning: set socket: Failed 2 ppp ON thor> Ppp ON thor> PPp ON thor> Warning: iface add: ioctl(SIOCAIFADDR, 67.70.89.*** -> 64.230.254.***): File exists Error: ipcp_InterfaceUp: unable to set ip address <><><><><><> OTHER TWEAKS <><><><><>: <>1<> Some one who was trying to help me earlier mentioned that for a network setup I need the following: in /usr/local/etc/rc.d/natd.sh !#/bin/sh sbin/natd -u -m -s -n tun0 -redirect_address 192.168.x.x public_address in order for someone to get to my boxes from outside my local network. So I have a file called natd.sh in my system but I have not put in values for -redirect_address or public_address yet as I am not sure what they are suppose to mean. <>2<> Someone told me to change rc.firewall but I don't think the set-up it correct. I'm not sure if I should be using "tun0" or "vr0" and I think that my onet and inet are not configured properly ... how should this be configured given my topology? ############ # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. ############ # set these to your outside interface network and netmask and ip #oif="ed0" #onet="192.0.2.0" #omask="255.255.255.240" #oip="192.0.2.1" #THE ABOVE FOUR LINES ARE THE ORIGINAL #THE FOUR LINES BELOW ARE NEW oif="tun0" onet="192.168.0.3" omask="255.255.255.x" oip="" # set these to your inside interface network and netmask and ip #iif="ed1" #inet="192.0.2.16" #imask="255.255.255.240" #iip="192.0.2.17" #THE ABOVE FOUR LINES ARE THE ORIGINAL #THE FOUR LINES BELOW ARE NEW iif="ed0" inet="192.168.0.0" imask="255.255.255.0" iip="192.168.0.1" setup_loopback <><><><><> Help! Thanks in advance. <><><><><> --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 21:27:32 2004 Return-Path: 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 87EFA16A4CE; Tue, 22 Jun 2004 21:27:32 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43EFE43D39; Tue, 22 Jun 2004 21:27:32 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3926C6520E; Tue, 22 Jun 2004 22:27:24 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71682-01-11; Tue, 22 Jun 2004 22:27:23 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D5622651EB; Tue, 22 Jun 2004 22:27:23 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 3313A614B; Tue, 22 Jun 2004 22:27:23 +0100 (BST) Date: Tue, 22 Jun 2004 22:27:23 +0100 From: Bruce M Simpson To: freebsd-net@FreeBSD.org Message-ID: <20040622212723.GB762@empiric.dek.spc.org> Mail-Followup-To: freebsd-net@FreeBSD.org, ncvs@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: ncvs@FreeBSD.org Subject: src/sbin/routed doesn't store code in src/contrib/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 21:27:32 -0000 Hi, Historically the Rhyolite routed has resided in src/sbin/routed. However, this code is maintained on a vendor branch, and as such, should really reside in src/contrib/routed and be referenced by the Makefile in src/sbin/routed accordingly. Would we be able to move it with a repocopy? Or would this break things? Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:27:18 2004 Return-Path: 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 30F0816A4DB; Tue, 22 Jun 2004 22:27:18 +0000 (GMT) Received: from transwarp.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0734943D53; Tue, 22 Jun 2004 22:27:17 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (pcp08929796pcs.anapol01.md.comcast.net [68.50.236.43]) by transwarp.tao.org.uk (Postfix) with ESMTP id 99C15EA9D; Tue, 22 Jun 2004 23:27:07 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 1B27C43D4; Mon, 21 Jun 2004 03:39:29 +0100 (BST) Resent-From: joe@genius.tao.org.uk Resent-Date: Mon, 21 Jun 2004 03:39:29 +0100 Resent-Message-ID: <20040621023929.GC757@genius.tao.org.uk> Resent-To: current@freebsd.org, net@freebsd.org Date: Mon, 21 Jun 2004 03:39:15 +0100 From: Josef Karthauser To: David Malone Message-ID: <20040621023915.GB757@genius.tao.org.uk> References: <20040620133936.GA791@genius.tao.org.uk> <20040620135433.GA769@genius.tao.org.uk> <20040620175205.GA13235@walton.maths.tcd.ie> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <20040620175205.GA13235@walton.maths.tcd.ie> User-Agent: Mutt/1.5.6i X-taoresearch-MailScanner-Information: Please contact Tao Research for more information X-taoresearch-MailScanner: Found to be clean X-MailScanner-From: joe@tao.org.uk Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:27:18 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 20, 2004 at 06:52:05PM +0100, David Malone wrote: > On Sun, Jun 20, 2004 at 02:54:34PM +0100, Josef Karthauser wrote: > > I should have said that the atheros web site states that the 511T and > > the 311T use the same chipset, which is the AR5002G, but that the >=20 > I know someone with a 511T, and it works with the ath driver, I > believe. I also have a WAG511, which also works with the ath driver. > The WG511 and WG311 a non-Atheros chipset and so you'd have to try > project evil. >=20 Is there a bug in the ath manual page then? Netgear WAG311 AR5212 PCI a/b/g Netgear WAB501 AR5211 CardBus a/b Netgear WAG511 AR5212 CardBus a/b/g Netgear WG311 AR5212 PCI b/g Netgear WG511T AR5212 CardBus b/g It clearly says that the WG311 is an atheros chipset. > > FreeBSD manual page states that the 511T uses the AR5212 chipset and > > doesn't mention the AR5002G by name at all. Addionally the atheros web > > site doesn't mention a WG311 card at at all, only a HA311, WAG311 and > > WG311T. >=20 > I think that's 'cos they are a different chipset all together. Hmm, it looks like someone in the know could do with reviewing the ath manual page. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iEYEARECAAYFAkDWSlIACgkQXVIcjOaxUBb4LACeNtGAHWEm4O6EKdDIwbHQXjpy TywAn2pK1fTonKUnNy78NSgLEO3TX2zN =Pauo -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 22:50:57 2004 Return-Path: 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 20FFA16A4CE; Tue, 22 Jun 2004 22:50:57 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E40043D1D; Tue, 22 Jun 2004 22:50:56 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 939A06520F; Tue, 22 Jun 2004 23:50:24 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 72717-01; Tue, 22 Jun 2004 23:50:24 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E3F076520C; Tue, 22 Jun 2004 23:50:23 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id EF924614B; Tue, 22 Jun 2004 23:50:21 +0100 (BST) Date: Tue, 22 Jun 2004 23:50:21 +0100 From: Bruce M Simpson To: freebsd-net@freebsd.org Message-ID: <20040622225021.GH762@empiric.dek.spc.org> Mail-Followup-To: freebsd-net@freebsd.org, Jayanth Vijayaraghavan , freebsd-gnats-submit@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:50:57 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I applied the attached patch to -CURRENT from around April which is currently running on my local CVS server. Basic tests with sshd and ftp didn't result in any unexpected behaviour. I suspect I really need to be running an application similar to the one Jayanth is running to unravel things further. Can anyone more familiar with the socket layer than I think of any problems with applying it? Can anyone think of an application (e.g. in ports) which takes the same order of operations as that described in the PR? Regards, BMS --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="accept-sostate.patch" Index: uipc_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.181 diff -u -r1.181 uipc_syscalls.c --- uipc_syscalls.c 8 Apr 2004 07:14:34 -0000 1.181 +++ uipc_syscalls.c 22 Jun 2004 22:23:16 -0000 @@ -320,6 +320,7 @@ /* connection has been removed from the listen queue */ KNOTE(&head->so_rcv.sb_sel.si_note, 0); + so->so_state |= head->so_state; so->so_state &= ~SS_COMP; so->so_head = NULL; pgid = fgetown(&head->so_sigio); --KN5l+BnMqAQyZLvT-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 22 23:13:14 2004 Return-Path: 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 7480B16A4CE; Tue, 22 Jun 2004 23:13:14 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13D3143D5D; Tue, 22 Jun 2004 23:13:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5MNBLc3061539; Tue, 22 Jun 2004 19:11:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5MNBJlf061536; Tue, 22 Jun 2004 19:11:19 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 22 Jun 2004 19:11:19 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce M Simpson In-Reply-To: <20040622225021.GH762@empiric.dek.spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: bms@empiric.dek.spc.org cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 23:13:14 -0000 On Tue, 22 Jun 2004, Bruce M Simpson wrote: > I applied the attached patch to -CURRENT from around April which is > currently running on my local CVS server. Basic tests with sshd and ftp > didn't result in any unexpected behaviour. I suspect I really need to be > running an application similar to the one Jayanth is running to unravel > things further. > > Can anyone more familiar with the socket layer than I think of any > problems with applying it? > > Can anyone think of an application (e.g. in ports) which takes the same > order of operations as that described in the PR? Interesting problem. :-) Comments on the patch below. > Index: uipc_syscalls.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v > retrieving revision 1.181 > diff -u -r1.181 uipc_syscalls.c > --- uipc_syscalls.c 8 Apr 2004 07:14:34 -0000 1.181 > +++ uipc_syscalls.c 22 Jun 2004 22:23:16 -0000 > @@ -320,6 +320,7 @@ > /* connection has been removed from the listen queue */ > KNOTE(&head->so_rcv.sb_sel.si_note, 0); > > + so->so_state |= head->so_state; > so->so_state &= ~SS_COMP; > so->so_head = NULL; > pgid = fgetown(&head->so_sigio); Hmm. Maybe we should just copy SS_NBIO? The other SS_ flags seem inappropriate to copy. I looked at SS_ASYNC, but we fail to also propagate the socket buffer flags and it's not clear it's as meaningful, so I think just SS_NBIO. So perhaps: so->so_state |= (head->so_state & SS_NBIO); Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 00:20:34 2004 Return-Path: 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 E87B316A4CE; Wed, 23 Jun 2004 00:20:34 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C86E43D58; Wed, 23 Jun 2004 00:20:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040623002032016005q8s5e>; Wed, 23 Jun 2004 00:20:33 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA59240; Tue, 22 Jun 2004 17:20:30 -0700 (PDT) Date: Tue, 22 Jun 2004 17:20:28 -0700 (PDT) From: Julian Elischer To: Ian FREISLICH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 00:20:35 -0000 On Tue, 22 Jun 2004, Ian FREISLICH wrote: > Andre Oppermann wrote: > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > That would be a very a nice thing, but it looks like this breaks > the patch that I submitted (kern/64240) which fixes the acknowledged > problem with 'ipfw tee' accepting packets instead of copying them > to the divert port and then processing the packet according to the > rest of the rule set. > > There have been about 5 PRs (most with patches) in the past years > which all claim to fix this problem indicating that here is a need > for a fix. We rely on the fix in kern/64240 to collect traffic > accounting information for billing and statistical purposes. There > hasn't been much interest from the committers in having a look at > this even though the work has already been done. > > Now that you're actively working on that part of the source, would > it be possible to take a look? I would also be happy to create a > new patch to fix this problem against ipfw with pfilhooks if that's > what it's going to take to get a fix committed. > > Ian > > -- > Ian Freislich hmmm I guess the pathc should be pointed out to luigi or an ipfw person.. it's probably not that you're being ignored it's probably that no-one who has his fingers in ipfw noticed it.. julian From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 00:57:06 2004 Return-Path: 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 209F616A4CE; Wed, 23 Jun 2004 00:57:06 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E51D43D41; Wed, 23 Jun 2004 00:57:05 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 92A3965292; Wed, 23 Jun 2004 01:57:03 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73765-05-3; Wed, 23 Jun 2004 01:57:03 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 3AB2465216; Wed, 23 Jun 2004 01:57:03 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 8F908614B; Wed, 23 Jun 2004 01:57:02 +0100 (BST) Date: Wed, 23 Jun 2004 01:57:02 +0100 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20040623005702.GN762@empiric.dek.spc.org> Mail-Followup-To: Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <40D754D5.1070805@freebsd.org> <006901c4583e$b651fe60$5a2ba8c0@lan> <40D81CA5.599AA4DB@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D81CA5.599AA4DB@freebsd.org> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 00:57:06 -0000 Just to note that I've posted you feedback on this patch off-list. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 00:58:08 2004 Return-Path: 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 CE5A416A4CE; Wed, 23 Jun 2004 00:58:08 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DE843D5A; Wed, 23 Jun 2004 00:58:08 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E7BF0653E8; Wed, 23 Jun 2004 01:58:03 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73765-05-7; Wed, 23 Jun 2004 01:58:03 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7991065292; Wed, 23 Jun 2004 01:58:03 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id CC130614B; Wed, 23 Jun 2004 01:58:02 +0100 (BST) Date: Wed, 23 Jun 2004 01:58:02 +0100 From: Bruce M Simpson To: Robert Watson Message-ID: <20040623005802.GO762@empiric.dek.spc.org> Mail-Followup-To: Robert Watson , freebsd-net@freebsd.org, Jayanth Vijayaraghavan References: <20040622225021.GH762@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-net@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 00:58:09 -0000 On Tue, Jun 22, 2004 at 07:11:19PM -0400, Robert Watson wrote: > so->so_state |= (head->so_state & SS_NBIO); In the end this is what it boils down to. I've committed this and an appropriate manual page update. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 01:06:15 2004 Return-Path: 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 279CD16A4CE for ; Wed, 23 Jun 2004 01:06:15 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D6043D5A for ; Wed, 23 Jun 2004 01:06:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5N14ZVc063326; Tue, 22 Jun 2004 21:04:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5N14ZdQ063323; Tue, 22 Jun 2004 21:04:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 22 Jun 2004 21:04:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce M Simpson In-Reply-To: <20040623005802.GO762@empiric.dek.spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 01:06:15 -0000 On Wed, 23 Jun 2004, Bruce M Simpson wrote: > On Tue, Jun 22, 2004 at 07:11:19PM -0400, Robert Watson wrote: > > so->so_state |= (head->so_state & SS_NBIO); > > In the end this is what it boils down to. I've committed this and an > appropriate manual page update. Since you're looking at the propagation of head so_state to new socket so_state, you might want to look at the similar statement in sonewconn(), which copies so_state from head to the new socket, and adds the SS_NOFDREF flag. Should we only be propagating SS_NBIO here as well? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 01:23:58 2004 Return-Path: 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 4195116A4CE; Wed, 23 Jun 2004 01:23:58 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 064CE43D54; Wed, 23 Jun 2004 01:23:58 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 8C43965216; Wed, 23 Jun 2004 02:23:56 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74369-02-3; Wed, 23 Jun 2004 02:23:55 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 79AA86520F; Wed, 23 Jun 2004 02:23:55 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id E0A95614B; Wed, 23 Jun 2004 02:23:54 +0100 (BST) Date: Wed, 23 Jun 2004 02:23:54 +0100 From: Bruce M Simpson To: Robert Watson Message-ID: <20040623012354.GQ762@empiric.dek.spc.org> Mail-Followup-To: Robert Watson , freebsd-net@freebsd.org, Jayanth Vijayaraghavan References: <20040623005802.GO762@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-net@freebsd.org Subject: Re: kern/45733: file descriptor flags and socket flags out of sync X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 01:23:58 -0000 On Tue, Jun 22, 2004 at 09:04:35PM -0400, Robert Watson wrote: > Since you're looking at the propagation of head so_state to new socket > so_state, you might want to look at the similar statement in sonewconn(), > which copies so_state from head to the new socket, and adds the SS_NOFDREF > flag. Should we only be propagating SS_NBIO here as well? Verdict: not proven. SS_NOFDREF implies that no file descriptor references the socket, so similar inconsistencies between the FD and the SO wouldn't apply here. The state of the socket 'head' is likely to be consistent with regards to the other SS_* flags as 'head' is a listening socket, and such sockets don't generally appear to be used for straight I/O from userland (in the PF_INET, SOCK_STREAM case, listening sockets are effectively just endpoints for servicing SYNs - all userland I/O happens through connected sockets derived from such listening sockets). It is also possible that the fix we applied for the accept1() case is incomplete; it's also possible that we should in fact have applied it here. If you could remind me of the URL of that dotfile you graphed with the socket layer call graph, that would be most useful. ;-) There are however a bunch of bits which probably shouldn't be applied to the new socket, but as above, it looks like these shouldn't be in effect for the listening socket. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 02:02:59 2004 Return-Path: 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 4752F16A4CE; Wed, 23 Jun 2004 02:02:59 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221DA43D5C; Wed, 23 Jun 2004 02:02:59 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 92D712A8DA; Tue, 22 Jun 2004 18:41:50 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 30F59E27E; Tue, 22 Jun 2004 18:41:50 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i5N1fnkY003682; Tue, 22 Jun 2004 18:41:49 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i5N1fnZL003681; Tue, 22 Jun 2004 18:41:49 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: Bruce M Simpson Date: Tue, 22 Jun 2004 18:41:49 -0700 User-Agent: KMail/1.6.1 References: <20040622212723.GB762@empiric.dek.spc.org> In-Reply-To: <20040622212723.GB762@empiric.dek.spc.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406221841.49271.peter@wemm.org> cc: freebsd-net@FreeBSD.org cc: ncvs@FreeBSD.org Subject: Re: src/sbin/routed doesn't store code in src/contrib/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 02:02:59 -0000 On Tuesday 22 June 2004 02:27 pm, Bruce M Simpson wrote: > Hi, > > Historically the Rhyolite routed has resided in src/sbin/routed. > > However, this code is maintained on a vendor branch, and as such, > should really reside in src/contrib/routed and be referenced by > the Makefile in src/sbin/routed accordingly. > > Would we be able to move it with a repocopy? Or would this break > things? The traditional reason for putting stuff in src/contrib was to avoid changing the vendor's file layout - eg: if things had bin, libexec, lib etc components and that their own Makefiles etc, then we had to use the PATH mechanism to avoid mangling the vendor's tree.. However, if it fits happily in src/sbin/routed, then IMHO leave it there. Just like zlib fits happily in src/lib/libz. BTW2: if I had a chance to do it all over again, I'd have argued for any name but "contrib". eg: src/dist (netbsd-style) or src/vendor. And have src/gnu/{contrib,dist,vendor} etc as a seperate tree just like we have src/sys/contrib. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 03:40:22 2004 Return-Path: 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 09E1216A4CE for ; Wed, 23 Jun 2004 03:40:22 +0000 (GMT) Received: from utopia.in.force-elite.com (force-elite.com [216.255.199.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 919F743D41 for ; Wed, 23 Jun 2004 03:40:21 +0000 (GMT) (envelope-from chip@force-elite.com) X-AuthUser: chip@force-elite.com Received: from [10.0.0.22] (10.0.0.22:35286)Server] ; Wed, 23 Jun 2004 03:39:48 -0000 From: Paul Querna To: freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 22 Jun 2004 20:39:48 -0700 Message-Id: <1087961988.32333.48.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.2 Content-Transfer-Encoding: 7bit Subject: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 03:40:22 -0000 Hello, I am looking at methods to rate limit a single socket to a specific pipe or rate with FreeBSD. I would like to make an Apache module that could do its outgoing rate limit *in* kernel, making the module very simple, and more accurate by using the kernel todo the rate limiting. I have been looking at Dummynet and pfil_hooks, but these seem to operate only on an entire interface. I would like to have these operate only on a socket fd that I designate. Ie a special setsockopt() would put socket x into pipe a. This pipe 'a' was setup ahead of time to only allow 512 kb/s. Is this possible with FreeBSD? Do you have any suggestions on the best way to proceed? Thank you, -Paul Querna From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 03:55:53 2004 Return-Path: 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 25B5C16A4CE for ; Wed, 23 Jun 2004 03:55:53 +0000 (GMT) Received: from speedbuggy.telerama.com (speedbuggy.telerama.com [205.201.1.216]) by mx1.FreeBSD.org (Postfix) with SMTP id A22AB43D1D for ; Wed, 23 Jun 2004 03:55:52 +0000 (GMT) (envelope-from taka@cs.pitt.edu) Received: (qmail 14803 invoked from network); 23 Jun 2004 03:55:46 -0000 Received: from unknown (HELO cs.pitt.edu) (205.201.14.34) by speedbuggy.telerama.com with SMTP; 23 Jun 2004 03:55:46 -0000 Message-ID: <40D8FF41.6392C8F7@cs.pitt.edu> Date: Tue, 22 Jun 2004 23:55:45 -0400 From: Takashi Okumura Organization: University of Pittsburgh X-Mailer: Mozilla 4.06 [ja] (WinNT; I) MIME-Version: 1.0 To: Paul Querna Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 03:55:53 -0000 hi, please take a look at mod_netnice. it uses netnice, another in-kernel traffic control primitive on the platform. since you can control each socket with netnice, i think it's easy to extend the module to meet your needs. http://www.netnice.org/app_modnetnice.html thanks, -- taka > Hello, > I am looking at methods to rate limit a single socket to a specific > pipe or rate with FreeBSD. I would like to make an Apache module that > could do its outgoing rate limit *in* kernel, making the module very > simple, and more accurate by using the kernel todo the rate limiting. > > I have been looking at Dummynet and pfil_hooks, but these seem to > operate only on an entire interface. I would like to have these operate > only on a socket fd that I designate. Ie a special setsockopt() would > put socket x into pipe a. This pipe 'a' was setup ahead of time to only > allow 512 kb/s. > > Is this possible with FreeBSD? Do you have any suggestions on the best > way to proceed? > > Thank you, > -Paul Querna > From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 04:38:55 2004 Return-Path: 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 0119016A4CE; Wed, 23 Jun 2004 04:38:55 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3651F43D49; Wed, 23 Jun 2004 04:38:54 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4A776651EE; Wed, 23 Jun 2004 05:38:52 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 76340-05-3; Wed, 23 Jun 2004 05:38:51 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 3BB86651EB; Wed, 23 Jun 2004 05:38:51 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 59C4E614B; Wed, 23 Jun 2004 05:38:50 +0100 (BST) Date: Wed, 23 Jun 2004 05:38:50 +0100 From: Bruce M Simpson To: Barney Wolff Message-ID: <20040623043850.GA3838@empiric.dek.spc.org> Mail-Followup-To: Barney Wolff , Alfred Perlstein , Jonathan Lennox , freebsd-net@freebsd.org References: <20040618114929.GE58783@empiric.dek.spc.org> <20040618175121.GZ61448@elvis.mu.org> <20040618210840.GA53218@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618210840.GA53218@pit.databus.com> cc: Jonathan Lennox cc: freebsd-net@freebsd.org cc: Alfred Perlstein Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 04:38:55 -0000 On Fri, Jun 18, 2004 at 05:08:40PM -0400, Barney Wolff wrote: > Pardon an ignorant question, but what happens to unfortunate people who > have to talk to both Linux and non-quirky servers at the same time? Is > there a way to detect what flavor of server you're talking to and adjust > accordingly? That would be far better than a sysctl. I've been researching this. This is actually far, far more involved. The problem is that rpc.lockd sits in userland, and has no easy idea of getting NFS-specific mount options back from the kernel for a current NFS client mountpoint. The reason for this is to do with the way the old mount(2) API works. nmount(2) helps to address some of the problem, by providing for an iovec to be passed in instead; vfs_getopt() is used by nmount() clients to obtain the options passed in to userland for the mount. None of the nfs code uses nmount() yet. Also, there is no system call yet which could be used to retrieve the options with which a filesystem has been mounted, but this is still a step in the right direction. So the short answer is, we can't do a mount option right now, but a sysctl is easily implemented. In any event, the bug is now fixed in the Linux kernel, those unfortunate souls out there who have the luck to work with Linux in this way will have to wait for the userland binaries to catch up in all the distro. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 04:45:12 2004 Return-Path: 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 0CFE216A4CE; Wed, 23 Jun 2004 04:45:12 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5AF943D54; Wed, 23 Jun 2004 04:45:11 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E2F37651EE; Wed, 23 Jun 2004 05:44:58 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 76096-08; Wed, 23 Jun 2004 05:44:58 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C8DA4651EB; Wed, 23 Jun 2004 05:44:57 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 1568D614B; Wed, 23 Jun 2004 05:44:57 +0100 (BST) Date: Wed, 23 Jun 2004 05:44:57 +0100 From: Bruce M Simpson To: Dan Nelson Message-ID: <20040623044457.GB3838@empiric.dek.spc.org> Mail-Followup-To: Dan Nelson , freebsd-net@FreeBSD.org, alfred@FreeBSD.org, kris@FreeBSD.org, Jonathan Lennox References: <20040618114929.GE58783@empiric.dek.spc.org> <20040618223507.GA74627@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618223507.GA74627@dan.emsphone.com> cc: Jonathan Lennox cc: freebsd-net@FreeBSD.org cc: kris@FreeBSD.org cc: alfred@FreeBSD.org Subject: Re: kern/56461: FreeBSD client rpc.lockd incompatible with Linux server rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 04:45:12 -0000 On Fri, Jun 18, 2004 at 05:35:07PM -0500, Dan Nelson wrote: > Linux kernels 2.4.26 and above have fixed this particular bug, so the > need for a compatibility hack on our end is not as great anymore. Agreed. I have abandoned work on this for now. If anyone is in desperate need for this, I can re-jig the patch to work as a sysctl; but this of course has the caveat that it affects *all* nfs client mounts. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 06:05:02 2004 Return-Path: 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 418F316A4CE for ; Wed, 23 Jun 2004 06:05:02 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BCCE43D55 for ; Wed, 23 Jun 2004 06:05:00 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id i5N64HGO054579 for ; Tue, 22 Jun 2004 23:04:17 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i5N648Tm080012 for ; Tue, 22 Jun 2004 23:04:09 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 23 Jun 2004 15:04:05 +0900 Message-ID: From: "George V. Neville-Neil" To: freebsd-net@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: Re: kern/68110 (rfc 3522) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 06:05:02 -0000 Andre Oppermann said: > Jon Noack wrote: > > > > Has anyone looked at kern/68110? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110 > The situation is a little bit complicated. I agree that having RFC3522 > is a good thing. > However there is a political problem with the author of the rfc3522 of > DFBSD. He is also still a FreeBSD committer, but for political reasons > he has very much refrained from doing any FreeBSD work for about a year > now. About six or seven month ago I had a port of rfc3522 ready in my > tree and wanted to commit it. He vetoed me and said he would do it by > himself. Yet for those political reasons he wont do any work on FreeBSD > including this. The only way to solve this is that either someone simply > committs it (this is BSD licensed code after all) and pisses him off, or > someone convinces him to do it himself (which I don't think he will). > Deadlock... I believe that this deadlock can be broken, if you still have code/patch for this, by your proposing of that patch. I'm sure a single committer will not block new work going forward. I'll review what you've got, at the very least. Let's get this in there. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 06:52:19 2004 Return-Path: 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 1B68016A4CF for ; Wed, 23 Jun 2004 06:52:19 +0000 (GMT) Received: from utopia.in.force-elite.com (force-elite.com [216.255.199.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868FB43D5A for ; Wed, 23 Jun 2004 06:52:18 +0000 (GMT) (envelope-from chip@force-elite.com) X-AuthUser: chip@force-elite.com Received: from [10.0.0.22] (10.0.0.22:35396)Server] ; Wed, 23 Jun 2004 06:52:17 -0000 From: Paul Querna To: Takashi Okumura In-Reply-To: <40D8FF41.6392C8F7@cs.pitt.edu> References: <40D8FF41.6392C8F7@cs.pitt.edu> Content-Type: text/plain Date: Tue, 22 Jun 2004 23:52:17 -0700 Message-Id: <1087973537.32330.58.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.2 Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 06:52:19 -0000 On Tue, 2004-06-22 at 23:55 -0400, Takashi Okumura wrote: > hi, > > please take a look at mod_netnice. it uses netnice, another in-kernel > traffic control primitive on the platform. since you can control each > socket with netnice, i think it's easy to extend the module to meet > your needs. > > http://www.netnice.org/app_modnetnice.html > Wow, that is a very neat project! Is there any chance of netnice being added to mainstream FreeBSD, perhaps in the 5.x tree? It would be very cool if it could be added a port initially, like pf was. I downloaded it, but it looks like you only have patches against the 4.x tree? Thanks, -Paul Querna From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:20:39 2004 Return-Path: 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 2124A16A4CE for ; Wed, 23 Jun 2004 07:20:39 +0000 (GMT) Received: from mb2i1.ns.pitt.edu (mb2i1.ns.pitt.edu [136.142.185.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id F394743D45 for ; Wed, 23 Jun 2004 07:20:38 +0000 (GMT) (envelope-from taka@cs.pitt.edu) Received: from CONVERSION-DAEMON by pitt.edu (PMDF V5.2-32 #41462) id <01LBMED52RXS0036CE@mb2i1.ns.pitt.edu> for freebsd-net@freebsd.org; Wed, 23 Jun 2004 03:20:21 EDT Received: from cs.pitt.edu ([130.49.223.184]) by pitt.edu (PMDF V5.2-32 #41462) with ESMTP id <01LBMED4EOI2003D6Z@mb2i1.ns.pitt.edu>; Wed, 23 Jun 2004 03:20:21 -0400 (EDT) Date: Wed, 23 Jun 2004 03:20:19 -0400 From: Takashi Okumura To: Paul Querna Message-id: <40D92F33.7B54B5C4@cs.pitt.edu> Organization: University of Pittsburgh MIME-version: 1.0 X-Mailer: Mozilla 4.06 [ja] (WinNT; I) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit References: <40D8FF41.6392C8F7@cs.pitt.edu> <1087973537.32330.58.camel@localhost> cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 07:20:39 -0000 hi, Paul Querna wrote: > > On Tue, 2004-06-22 at 23:55 -0400, Takashi Okumura wrote: > > hi, > > > > please take a look at mod_netnice. it uses netnice, another in-kernel > > traffic control primitive on the platform. since you can control each > > socket with netnice, i think it's easy to extend the module to meet > > your needs. > > > > http://www.netnice.org/app_modnetnice.html > > > > Wow, that is a very neat project! > > Is there any chance of netnice being added to mainstream FreeBSD, > perhaps in the 5.x tree? we are currently preparing to port the module to Linux, NetBSD, MacOS X, and OpenBSD, as well as to 5.x. but, since the workforce is quite limited, it will take several months to finish the porting to 5.x. it should be easy, but, i realized that somebody has totally changed its procfs implementation, which the API of netnice relies upon. so, it will take a bit longer than it should be. if some of you might help us, that would be great. regarding the contribution to the mainstream FreeBSD, yes, we would love to. but, i'm a bit pessimistic about that option, simply because it looks too radical, at this point. maybe after we finish the porting to the major platforms, and the communities realize its scope and advantage, of having a multi-platform primitive for end-host oriented network control, we may start pursuing the option. but, that will be a future story. we still need to translate many documents for developers, and need to provide many netnice applications. so... > It would be very cool if it could be added a port initially, like pf > was. I downloaded it, but it looks like you only have patches against > the 4.x tree? yes, it currently supports just FB4.9, and it requires kernel patch, plus makeworld :-( since it is not a quick'n easy process, we have been asked to provide better (and easier) testing environment. so, we have just released a LiveCD version of Netnice/FreeBSD :-) http://www.netnice.org/download.html i'm planning to release a bit better FreeSBIE-based LiveCD with X + XFCE. if you want to see working apache + mod_netnice on the CD, i'll try to include it in the next release. please let me know if you have any request in that regard. thanks, -- taka From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 07:36:50 2004 Return-Path: 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 8A2AC16A4CE for ; Wed, 23 Jun 2004 07:36:50 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B1E743D48 for ; Wed, 23 Jun 2004 07:36:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i5N7acgd051199; Wed, 23 Jun 2004 00:36:38 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i5N7aclL051198; Wed, 23 Jun 2004 00:36:38 -0700 (PDT) (envelope-from rizzo) Date: Wed, 23 Jun 2004 00:36:38 -0700 From: Luigi Rizzo To: Paul Querna Message-ID: <20040623003638.A50907@xorpc.icir.org> References: <1087961988.32333.48.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1087961988.32333.48.camel@localhost>; from chip@force-elite.com on Tue, Jun 22, 2004 at 08:39:48PM -0700 cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 07:36:50 -0000 On Tue, Jun 22, 2004 at 08:39:48PM -0700, Paul Querna wrote: > Hello, > I am looking at methods to rate limit a single socket to a specific > pipe or rate with FreeBSD. I would like to make an Apache module that > could do its outgoing rate limit *in* kernel, making the module very > simple, and more accurate by using the kernel todo the rate limiting. > > I have been looking at Dummynet and pfil_hooks, but these seem to > operate only on an entire interface. I would like to have these operate this is not true -- you can do what you want trivially with dummynet, which lets you limit the bandwidth per-flow by using masks on pipes, and you can aggregate flow as you need using masks appropriately on addresses and ports. Read the ipfw manpage. What you might not like is that you need root privs to configure ipfw/dummynet, but that's another story... cheers luigi > only on a socket fd that I designate. Ie a special setsockopt() would > put socket x into pipe a. This pipe 'a' was setup ahead of time to only > allow 512 kb/s. > > Is this possible with FreeBSD? Do you have any suggestions on the best > way to proceed? > > Thank you, > -Paul Querna > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 08:07:24 2004 Return-Path: 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 982B816A4CE; Wed, 23 Jun 2004 08:07:24 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A24143D1D; Wed, 23 Jun 2004 08:07:24 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1Bd2mD-000I0a-00; Wed, 23 Jun 2004 10:06:37 +0200 To: Julian Elischer From: Ian FREISLICH In-Reply-To: Message from Julian Elischer Date: Wed, 23 Jun 2004 10:06:37 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 08:07:24 -0000 Julian Elischer wrote: > On Tue, 22 Jun 2004, Ian FREISLICH wrote: > > Andre Oppermann wrote: > > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > Now that you're actively working on that part of the source, would > > it be possible to take a look? I would also be happy to create a > > new patch to fix this problem against ipfw with pfilhooks if that's > > what it's going to take to get a fix committed. > > > > hmmm I guess the pathc should be pointed out to luigi or an ipfw > person.. > it's probably not that you're being ignored it's probably that no-one > who has his fingers in ipfw noticed it.. I've mailed Luigi. I've mailed the patch to current (once) and ipfw (twice). I submitted the PR on Max Laier's request 'so it wouldn't get lost'. I then drew ipfw's attention to the PR at least twice with a couple of weeks break in between. It's been mailed to ipfw weekly since 2004/03/14 in the 'Current problem reports assigned to you' from the FreeBSD bugmaster. I even mentioned this to my friend Mark Murray who said that he'll mention it to Luigi over beer. Still nothing until now (I don't know if the beer happened though) and I suspect that it might make Andre's life a little harder because I don't know how neatly it will fit in with what he's doing. I guess I don't really mind if the patch isn't used, but some feedback would be nice: 'It can't be used because your coding style sucks' or 'the packet should be reinjected into the firewall in such and such a way'. I know this is a volunteer project. It's a great project that I want to contribute back to. I know that keeping private patches will prevent me from tracking CURRENT or STABLE at some stage. I know this is a bit emotional: it's just been a bit of a frustrating experience because the committers keep on say 'we don't always have the time to fix every little nit, but help us out and send some patches'. Well, here are some patches. I know that patches and other contributions have just been ignored in the past (just look at the PR database as an example - its full of untapped patches and fixes) and its a real turn-off. My thanks go to Andre for picking up the ball. I'm not sure responses to this should be cross-posted to freebsd-net. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 10:56:44 2004 Return-Path: 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 77BC416A4CE for ; Wed, 23 Jun 2004 10:56:44 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B317E43D55 for ; Wed, 23 Jun 2004 10:56:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 67646 invoked from network); 23 Jun 2004 10:56:37 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 23 Jun 2004 10:56:37 -0000 Message-ID: <40D961E5.92A2F554@freebsd.org> Date: Wed, 23 Jun 2004 12:56:37 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian FREISLICH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer Subject: Re: New preview patch for ipfw to pfil_hooks conversion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 10:56:44 -0000 Ian FREISLICH wrote: > > Julian Elischer wrote: > > On Tue, 22 Jun 2004, Ian FREISLICH wrote: > > > Andre Oppermann wrote: > > > > Here is the next preview patch for the ipfw to pfil_hooks conversion: > > > > > > > > http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff > > > > > > > > This patch significantly cleans up ip_input.c and ip_output.c. > > > > > > Now that you're actively working on that part of the source, would > > > it be possible to take a look? I would also be happy to create a > > > new patch to fix this problem against ipfw with pfilhooks if that's > > > what it's going to take to get a fix committed. > > > > > > > hmmm I guess the pathc should be pointed out to luigi or an ipfw > > person.. > > it's probably not that you're being ignored it's probably that no-one > > who has his fingers in ipfw noticed it.. > > I've mailed Luigi. I've mailed the patch to current (once) and > ipfw (twice). I submitted the PR on Max Laier's request 'so it > wouldn't get lost'. I then drew ipfw's attention to the PR at least > twice with a couple of weeks break in between. It's been mailed > to ipfw weekly since 2004/03/14 in the 'Current problem reports > assigned to you' from the FreeBSD bugmaster. I even mentioned this > to my friend Mark Murray who said that he'll mention it to Luigi > over beer. Still nothing until now (I don't know if the beer > happened though) and I suspect that it might make Andre's life a > little harder because I don't know how neatly it will fit in with > what he's doing. > > I guess I don't really mind if the patch isn't used, but some > feedback would be nice: 'It can't be used because your coding style > sucks' or 'the packet should be reinjected into the firewall in > such and such a way'. > > I know this is a volunteer project. It's a great project that I > want to contribute back to. I know that keeping private patches > will prevent me from tracking CURRENT or STABLE at some stage. > I know this is a bit emotional: it's just been a bit of a frustrating > experience because the committers keep on say 'we don't always have > the time to fix every little nit, but help us out and send some > patches'. Well, here are some patches. I know that patches and > other contributions have just been ignored in the past (just look > at the PR database as an example - its full of untapped patches and > fixes) and its a real turn-off. > > My thanks go to Andre for picking up the ball. Since I am rewriting that part of ipfw anyway for the conversion to pfil_hooks I am including a proper working 'tee' right away. -- Andre > I'm not sure responses to this should be cross-posted to freebsd-net. > > Ian > > -- > Ian Freislich > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 14:56:58 2004 Return-Path: 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 780D616A4CE; Wed, 23 Jun 2004 14:56:58 +0000 (GMT) Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9BFB43D46; Wed, 23 Jun 2004 14:56:57 +0000 (GMT) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 95D3ABC07B; Wed, 23 Jun 2004 10:56:56 -0400 (EDT) In-Reply-To: <20040622153207.GB1961@empiric.dek.spc.org> "from Bruce M Simpson at Jun 22, 2004 04:32:07 pm" To: Bruce M Simpson Date: Wed, 23 Jun 2004 10:56:56 -0400 (EDT) X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20040623145656.95D3ABC07B@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) cc: freebsd-net@FreeBSD.org cc: dwmalone@FreeBSD.org cc: wietse@porcupine.org cc: fenner@FreeBSD.org Subject: Re: tcp_wrappers: accumulated change-request PRs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 14:56:58 -0000 Bruce M Simpson: > Hi all, > > Whilst scanning GNATS, I found a number of PRs relating to requests > for tcp_wrappers functionality and some outright bugfixes. Rather than > commit these as-is, I think we should push the changes back to Wietse, > as we maintain tcp_wrappers on a vendor branch. > > The PRs in question are: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/31034 > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32808 > http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/36556 > http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/42336 > > What does everyone else think? The currently maintained version is tcp wrappers version 7.6 with IPv6 support from Casper Dik. As mentioned elsewhere, maintenance of this code means coping with changing language/system/network environments; it does not mean adding new features. If there is a problem in the maintained version then I will certainly fix it (as you can see from the progression of file modification times). Requests or even contributions for new features receive less enthousiastic response as some may have experienced. Improving warning/error messages is not a big problem for me, however I would be cautious feeding more and more text into syslog() for safety reasons. Even if syslog() itself was fixed years ago, software that processes logfile records does not necessarily handle it well. How much does the maintained version differ from the FreeBSD contrib source code? I haven't looked into this for a long time, having used FreeBSD since early 1993. I would not include regexp support into the maintained version, for several reasons. First, it's complex code, and it's is bound to have bugs. If I work really hard at it, my code still has one bug every 1000 lines. Second, it's unsafe. Most people don't know how to use regular expressions properly, as frequently experienced on the postfix-users list. Even the less sophisticated shell-style globbing is fraught with peril, with good programmers like Rich Salz having to release multiple wild_match() versions because of bugs. Wietse From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 15:10:03 2004 Return-Path: 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 819DE16A4CE for ; Wed, 23 Jun 2004 15:10:03 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A3F43D4C for ; Wed, 23 Jun 2004 15:10:03 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i5NF9uOF015797; Wed, 23 Jun 2004 08:09:56 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i5NF9u71015796; Wed, 23 Jun 2004 08:09:56 -0700 Date: Wed, 23 Jun 2004 08:09:56 -0700 From: Brooks Davis To: Takashi Okumura Message-ID: <20040623150955.GA15320@Odin.AC.HMC.Edu> References: <40D8FF41.6392C8F7@cs.pitt.edu> <1087973537.32330.58.camel@localhost> <40D92F33.7B54B5C4@cs.pitt.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <40D92F33.7B54B5C4@cs.pitt.edu> User-Agent: Mutt/1.5.4i cc: Paul Querna cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 15:10:03 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2004 at 03:20:19AM -0400, Takashi Okumura wrote: > hi, >=20 >=20 > Paul Querna wrote: > >=20 > > On Tue, 2004-06-22 at 23:55 -0400, Takashi Okumura wrote: > > > hi, > > > > > > please take a look at mod_netnice. it uses netnice, another in-kernel > > > traffic control primitive on the platform. since you can control each > > > socket with netnice, i think it's easy to extend the module to meet > > > your needs. > > > > > > http://www.netnice.org/app_modnetnice.html > > > > >=20 > > Wow, that is a very neat project! > >=20 > > Is there any chance of netnice being added to mainstream FreeBSD, > > perhaps in the 5.x tree? >=20 > we are currently preparing to port the module to Linux, NetBSD, MacOS X, > and OpenBSD, as well as to 5.x. but, since the workforce is quite limited, > it will take several months to finish the porting to 5.x. it should be > easy, but, i realized that somebody has totally changed its procfs > implementation, which the API of netnice relies upon. so, it will take > a bit longer than it should be. if some of you might help us, that would > be great. >=20 > regarding the contribution to the mainstream FreeBSD, yes, we would love = to. > but, i'm a bit pessimistic about that option, simply because it looks too > radical, at this point. maybe after we finish the porting to the major > platforms, and the communities realize its scope and advantage, of having > a multi-platform primitive for end-host oriented network control, we may > start pursuing the option. but, that will be a future story. we still > need to translate many documents for developers, and need to provide > many netnice applications. so... I think netnice looks really neat. Use of /proc would definaly limit the utility of integrating the code. We don't enable procfs by default because it's too hard to get procfs code right as the list of procfs security advisories demonstrates (not just on FreeBSD, but Linux, Solaris, etc.). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA2Z1DXY6L6fI4GtQRAr5QAJ4+Zah42pbdvjYJSMNguxxGHZRIfQCdFduy Ndef6ydqXoUrMxIZU1SWO+4= =VwRA -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 21:30:38 2004 Return-Path: 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 5A66B16A4CE for ; Wed, 23 Jun 2004 21:30:38 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 068D843D1F for ; Wed, 23 Jun 2004 21:30:38 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5NLS6Xo082080; Wed, 23 Jun 2004 17:28:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5NLS6q9082077; Wed, 23 Jun 2004 17:28:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 23 Jun 2004 17:28:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Paul Querna In-Reply-To: <1087961988.32333.48.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 21:30:38 -0000 On Tue, 22 Jun 2004, Paul Querna wrote: > I am looking at methods to rate limit a single socket to a > specific pipe or rate with FreeBSD. I would like to make an Apache > module that could do its outgoing rate limit *in* kernel, making the > module very simple, and more accurate by using the kernel todo the rate > limiting. > > I have been looking at Dummynet and pfil_hooks, but these seem to > operate only on an entire interface. I would like to have these operate > only on a socket fd that I designate. Ie a special setsockopt() would > put socket x into pipe a. This pipe 'a' was setup ahead of time to only > allow 512 kb/s. > > Is this possible with FreeBSD? Do you have any suggestions on the best > way to proceed? You might well be interested in Trickle, which is a user space traffic shaper that works via a library preload to rate limit arbitrary (dynamically linked) applications. http://monkey.org/~marius/pages/?page=trickle I've never tried it, Marius told me about it at the last USENIX Security (or maybe at LSM). It sounds pretty neat. Note that this is all in user space, but if it works well perhaps that's OK. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Wed Jun 23 22:37:22 2004 Return-Path: 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 C9D9F16A4CE; Wed, 23 Jun 2004 22:37:22 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71A9143D45; Wed, 23 Jun 2004 22:37:22 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) i5NMb99D006543; Wed, 23 Jun 2004 18:37:09 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: freebsd-net@freebsd.org Content-Type: text/plain Date: Wed, 23 Jun 2004 18:36:04 -0400 Message-Id: <1088030164.29367.57.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 cc: freebsd-hackers@freebsd.org Subject: using netgraph to connect 2 physical interfaces into one virtual interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 22:37:23 -0000 I am having a lot of trouble trying to make the following work (after some exhaustive googling etc) Goal: 2 interfaces (em0 and em1) to be "combined" or bonded into one virtual interface so as to provide both increased throughput and failover. Both physical ports connected to either the same or different switches with a virtual gateway (the configuration for which is being haandled separately). What I have tried (using netgraph) and the results: 1) (from the ng_one2many manpage): ifconfig em0 up ifconfig em1 up ngctl mkpeer em0: one2many upper one ngctl connect em0: em0:upper lower many0 ngctl connect em1: em0:upper lower many1 ...etc setting promisc and autosrc per the manpage the em0 is then ifconfig'd with the ip address etc as long as em0 link is up all seems good. When the link goes down (i.e. disconnect the ethernet cable), then 50% packet loss occurs as it tries to roundrobin and fail on the down side. Not a workable solution. 2) adapted from freebsd-security (derkweiler) http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2004-01/0084.html thread : ifconfig em0 promisc -arp up ifconfig em1 promisc -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many upper one ngctl connect em0: ngeth0:upper lower many0 ngctl connect em1: ngeth0:upper lower many1 ngctl msg em0: setautosrc 0 ngctl msg em1: setautosrc 0 ifconfig ngeth0 lladdr [mac addie other than 00:00:00:00:00:00] ifconfig ngeth0 up now if I ifconfig -arp the ngeth0 interface and add the default route, etc, I get nowhere ... no ping responses no traffic if I ifconfig the ngeth0 and enable arp then I can ping but get duplicates (actually for each reply I end up with 3 (DUP!) replies. also, the traffic throughput is miserable. Using scp from another machine on the LAN I muster around 300KB/s to this machine, 10MB/s to another on the same lan. So my question is, without trying to get into ng_fec (which I understand will also need hardware support on the other end -- blades, etc), how can I connect the 2 physical interfaces together into a virtual interface that proves a) respectable throughput b) "normal" traffic patterns via icmp, etc and c) failover in the event one or the other link goes down? From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 00:46:54 2004 Return-Path: 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 04D3A16A4CE for ; Thu, 24 Jun 2004 00:46:54 +0000 (GMT) Received: from speedbuggy.telerama.com (speedbuggy.telerama.com [205.201.1.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A8B843D55 for ; Thu, 24 Jun 2004 00:46:53 +0000 (GMT) (envelope-from taka@cs.pitt.edu) Received: (qmail 51441 invoked from network); 24 Jun 2004 00:46:52 -0000 Received: from unknown (HELO cs.pitt.edu) (205.201.14.20) by speedbuggy.telerama.com with SMTP; 24 Jun 2004 00:46:52 -0000 Message-ID: <40DA247A.BE7213FB@cs.pitt.edu> Date: Wed, 23 Jun 2004 20:46:50 -0400 From: Takashi Okumura Organization: University of Pittsburgh X-Mailer: Mozilla 4.06 [ja] (WinNT; I) MIME-Version: 1.0 To: Brooks Davis References: <40D8FF41.6392C8F7@cs.pitt.edu> <1087973537.32330.58.camel@localhost> <40D92F33.7B54B5C4@cs.pitt.edu> <20040623150955.GA15320@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit cc: Paul Querna cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 00:46:54 -0000 hi, Brooks Davis wrote: > > I think netnice looks really neat. > > Use of /proc would definaly limit the utility of integrating the code. > We don't enable procfs by default because it's too hard to get procfs > code right as the list of procfs security advisories demonstrates (not > just on FreeBSD, but Linux, Solaris, etc.). > thanks for the comment. yes, it seems that it is a bit hard to keep the original procfs interface intact, when we port the mechanism on to other platforms. probably, we'll need a library, libnetnice, which absorbs the details of the low-level API... *** *** *** btw, honestly speaking, we are feeling that there are two types of responses when we present the new model for end-host network control. one is that it is simply useful. this is true, particularly for applications and for end-users, because the VIF model realizes flexible granularity and many advanced features for user applications, while providing resource protection and access control between users on an end-host. the other type of response is that it is simply useless. this is because we already have dummynet, ALTQ, PF, BPF, and other useful implementations. i understand this response, since their control model (based on packet classification) has been used for years by network administrators and is intuitive. further, they have many years battle-proof, which what we lack. actually, my first netnice implementation greatly owes to Luigi's work, and personally, i'm quite thankful to him. but, basically, these existing mechanisms are protected by privileged syscalls, and does not possess mechanism for resource protection nor access control, which is needed to release API to users on end hosts. so, probably they are for administration purpose of router-like host, not for use by user applications. so, my point is that we are addressing different problems, and what i'm pursuing is "coexistence" of the implementations, targeting towards different situations. but, my current concern is that we have not provided enough information about our project; why we needed such a new model, its advantage and disadvantage, how to develop netnice applications (easy guide of the API for application programming), catalog of various VIF types, etc. this is because, although i've been writing papers in english, these useful information is available mostly just in Japanese... so, if you know any japanese friend, or if there are japanese-speaking subscriber in the mailing list, we would really appreciate your help. (we may even support the activities financially, this year). that way, we would be able to provide the community much more information about our efforts. if the topic is beyond scope of the ML, i sincerely apologize for the inappropriateness, and may move to our sf.net BBS, or to netnice developer's ML. http://sourceforge.net/projects/netnice/ i would appreciate any suggestions, comments, feedback, etc. thanks! -- taka From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 04:35:48 2004 Return-Path: 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 6E3F416A4CE for ; Thu, 24 Jun 2004 04:35:48 +0000 (GMT) Received: from gecea.ist.utl.pt (gecea.ist.utl.pt [193.136.140.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD8943D55 for ; Thu, 24 Jun 2004 04:35:47 +0000 (GMT) (envelope-from brunomiguel@dequim.ist.utl.pt) Received: from [10.10.59.250] (unknown [81.84.198.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gecea.ist.utl.pt (Postfix) with ESMTP id 35B7A40BB; Thu, 24 Jun 2004 05:35:34 +0100 (WEST) Message-ID: <40DA5A12.6080106@dequim.ist.utl.pt> Date: Thu, 24 Jun 2004 05:35:30 +0100 From: Bruno Afonso User-Agent: Mozilla Thunderbird 0.7 (X11/20040619) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: spe@bsdfr.org Subject: FreeVRRPD problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 04:35:48 -0000 Hello, I'm trying to have failover with a couple boxes and they're basically doing NAT and firewalling. 1 box has a couple fxp and the other a couple rls. Is this supposed to be a problem for freevrrpd? Only fxp box actually can use the fail-over ips. The backup box cannot use them if we start freevrrp deamon without starting on the master first and it's impossible to have network access to. Further more, if we have master and start backup, it all goes ok. If master goes down, backup never takes over and backup is from now one impossible to access. Main box: 5.2.1-p5 backup box: 5.0 Config for the fxp box: [VRID] serverid = 2 interface = fxp0 priority = 255 addr = 10.10.0.1/32 password = passie useVMAC = yes carriertimeout = 10 spanningtreelatency = 40 #sendgratuitousarp = yes #masterscript = "/usr/local/bin/master_script.sh" #backupscript = "/usr/local/bin/backup_script.sh" vridsdep = 1 [VRID] serverid = 1 interface = fxp1 priority = 255 addr = x.x.x.253/32 password = passie useVMAC = yes carriertimeout = 10 spanningtreelatency = 40 #sendgratuitousarp = yes #masterscript = "/usr/local/bin/master_script.sh" #backupscript = "/usr/local/bin/backup_script.sh" vridsdep = 2 backup box: [VRID] serverid = 2 interface = rl0 priority = 250 addr = 10.10.0.1/32 password = passie useVMAC = yes carriertimeout = 10 spanningtreelatency = 40 #sendgratuitousarp = yes #masterscript = "/usr/local/bin/master_script.sh" #backupscript = "/usr/local/bin/backup_script.sh" vridsdep = 1 [VRID] serverid = 1 interface = rl1 priority = 250 addr = x.x.x.253/32 password = passie useVMAC = yes carriertimeout = 10 spanningtreelatency = 40 #sendgratuitousarp = yes #masterscript = "/usr/local/bin/master_script.sh" #backupscript = "/usr/local/bin/backup_script.sh" vridsdep = 2 I'm using freevrrpd from CVS. On both machines, I get in /var/log/messages, gazillions of "all errors are cleared on interface xxx" There's not any particular information in backup box saying something went wrong... Any ideas ? BA -- Bruno Miguel Afonso Biological Eng. student D.E.Q. @ I.S.T. - Portugal GnuPG Public key: http://dequim.ist.utl.pt/~bruno/gpg From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 14:34:13 2004 Return-Path: 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 0093B16A4CE; Thu, 24 Jun 2004 14:34:13 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91C0E43D2F; Thu, 24 Jun 2004 14:34:12 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i5OEXiTH072022; Thu, 24 Jun 2004 09:33:44 -0500 (CDT) (envelope-from dan) Date: Thu, 24 Jun 2004 09:33:43 -0500 From: Dan Nelson To: Sven Willenberger Message-ID: <20040624143343.GA56406@dan.emsphone.com> References: <1088030164.29367.57.camel@lanshark.dmv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1088030164.29367.57.camel@lanshark.dmv.com> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: using netgraph to connect 2 physical interfaces into one virtual interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 14:34:13 -0000 In the last episode (Jun 23), Sven Willenberger said: > I am having a lot of trouble trying to make the following work (after > some exhaustive googling etc) > > Goal: 2 interfaces (em0 and em1) to be "combined" or bonded into one > virtual interface so as to provide both increased throughput and > failover. Both physical ports connected to either the same or different > switches with a virtual gateway (the configuration for which is being > haandled separately). > > What I have tried (using netgraph) and the results: > > 1) (from the ng_one2many manpage): > 2) adapted from freebsd-security (derkweiler) http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2004-01/0084.html thread : > > So my question is, without trying to get into ng_fec (which I understand > will also need hardware support on the other end -- blades, etc), how ng_fec needs just as much hardware support as one2many: the system at the other end must be able to handle port aggregation, and must be able to be manually configured. Both nodes do the same thing, in slightly different ways. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 15:09:58 2004 Return-Path: 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 20BA316A4CF; Thu, 24 Jun 2004 15:09:58 +0000 (GMT) Received: from transwarp.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AD843D5A; Thu, 24 Jun 2004 15:09:56 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by transwarp.tao.org.uk (Postfix) with ESMTP id BC3F0EA2C; Thu, 24 Jun 2004 16:09:28 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 67A914251; Thu, 24 Jun 2004 16:09:28 +0100 (BST) Date: Thu, 24 Jun 2004 16:09:28 +0100 From: Josef Karthauser To: Stefan E?er , Josef Karthauser , current@freebsd.org, net@freebsd.org Message-ID: <20040624150928.GA61325@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Stefan E?er , Josef Karthauser , current@freebsd.org, net@freebsd.org References: <20040620133936.GA791@genius.tao.org.uk> <20040620135433.GA769@genius.tao.org.uk> <20040620183004.GB94851@StefanEsser.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20040620183004.GB94851@StefanEsser.FreeBSD.org> User-Agent: Mutt/1.5.6i X-taoresearch-MailScanner-Information: Please contact Tao Research for more information X-taoresearch-MailScanner: Found to be clean X-MailScanner-From: joe@tao.org.uk Subject: Re: Wireless support for the Netgear WG311T? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 15:09:58 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 20, 2004 at 08:30:04PM +0200, Stefan E?er wrote: > On 2004-06-20 14:54 +0100, Josef Karthauser wrote: > > On Sun, Jun 20, 2004 at 02:39:36PM +0100, Josef Karthauser wrote: > > > The ath manual pages says that we support the Netgear WG311 and the > > > WG511T, but do we also support the WG311T? (Is the T significant?). >=20 > AFAIK, the WG311T and WG511T use an enhanced Atheros chip with=20 > improved S/N ratio. (The Netgear web site talks about improved > antenna technology, but I don't see what's special about that > antenna at all. There used to be a more specific technical data > sheet, which talked about the improved sensitivity and S/N of the > new radio, and I guess that's what actually makes the difference. > I also seem to remember some article on "www.smallnetbuilder.com" > that talked about a new Atheros chip set with increased range back > in September 2003. Hmmm, might have been: In the end I decided to purchase both a WG311T and WG511T to start my wireless network. Hopefully it will work out fine. Thanks to everyone who contributed to enabling me to come to a decision. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iEYEARECAAYFAkDa7qcACgkQXVIcjOaxUBbHawCfRaMvZsCFJOXJlcF1OT9UvU8x VEIAn3kebEkPqteDcr46EwIvMBEYAD0R =qiMp -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 15:18:46 2004 Return-Path: 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 6B79516A4CE; Thu, 24 Jun 2004 15:18:46 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AE3143D1F; Thu, 24 Jun 2004 15:18:46 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) i5OFIW9D035441; Thu, 24 Jun 2004 11:18:32 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: Dan Nelson In-Reply-To: <20040624143343.GA56406@dan.emsphone.com> References: <1088030164.29367.57.camel@lanshark.dmv.com> <20040624143343.GA56406@dan.emsphone.com> Content-Type: text/plain Date: Thu, 24 Jun 2004 11:17:27 -0400 Message-Id: <1088090247.8744.7.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 cc: freebsd-net@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: using netgraph to connect 2 physical interfaces into one virtual interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 15:18:46 -0000 On Thu, 2004-06-24 at 09:33 -0500, Dan Nelson wrote: > In the last episode (Jun 23), Sven Willenberger said: > > I am having a lot of trouble trying to make the following work (after > > some exhaustive googling etc) > > > > Goal: 2 interfaces (em0 and em1) to be "combined" or bonded into one > > virtual interface so as to provide both increased throughput and > > failover. Both physical ports connected to either the same or different > > switches with a virtual gateway (the configuration for which is being > > haandled separately). > > > > What I have tried (using netgraph) and the results: > > > > 1) (from the ng_one2many manpage): > > 2) adapted from freebsd-security (derkweiler) http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2004-01/0084.html thread : > > > > So my question is, without trying to get into ng_fec (which I understand > > will also need hardware support on the other end -- blades, etc), how > > ng_fec needs just as much hardware support as one2many: the system at > the other end must be able to handle port aggregation, and must be able > to be manually configured. Both nodes do the same thing, in slightly > different ways. > Actually I was wondering if one2many needed the same support that ng_fec needs - and you answered that question, albeit inversely. I did get ng_fec to run (using only three lines) and I don't have that issue of (DUP!) in my packets or any performance hit as long as fec0 is ifconfig'd with arp and the two physical interfaces are on the same or connected switch(es). ngctl mkpeer fec dummy fec (which spits out an error about not being able to name the fec0 node) ngctl msg fec0: add_iface '"em0"' ngctl msg fec0: add_iface '"em1"' ifconfig fec0 up So what would the equivalent be using ng_one2many and how do I get the same throughput and lack of DUP packets that I can achieve with ng_fec. My understanding was that ng_fec was being deprecated in favor of ng_one2many ? Sven From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 15:28:08 2004 Return-Path: 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 0D74E16A4CE for ; Thu, 24 Jun 2004 15:28:08 +0000 (GMT) Received: from mail.tomse.dk (ip20.ds1-oebr.adsl.cybercity.dk [212.242.108.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D74443D46 for ; Thu, 24 Jun 2004 15:28:06 +0000 (GMT) (envelope-from tomse@tomse.dk) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jun 2004 17:27:38 +0200 Message-ID: <62E0A1DC043BEF4CAF9AAFD8398773781CCE@krynn.tomse.dk> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux drivers on freebsd (Wireless net/Texas chipset) Thread-Index: AcRZ4w6LOOiaITgASkeYTkwFMNWfqAAGuzRQ From: "Carsten Jensen" To: Subject: Linux drivers on freebsd (Wireless net/Texas chipset) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 15:28:08 -0000 Hi, I've got this problem that i'd like to install the drivers to my SMC 2435W pc-card, but I only found the drivers for linux (http://acx100.sourceforge.net)=20 Does anyone know of a driver for FreeBSD (since it isn't in the=20 Hardwarelist) ?? or how to implement the linux driver on FreeBSD ?? I'm using FreeBSD 4.10-Release with almost GENERIC kernel I'd be very happy if I didn't need to go and buy a new card Thanks in advance :-) Best regards Carsten Jensen From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 19:55:09 2004 Return-Path: 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 484F116A4D7 for ; Thu, 24 Jun 2004 19:55:09 +0000 (GMT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEF8943D55 for ; Thu, 24 Jun 2004 19:55:08 +0000 (GMT) (envelope-from msch@snafu.de) Received: from dial-76-030.de.inter.net ([213.73.76.30] helo=current.best-eng.de) by smart.eusc.inter.net with esmtp (Exim 3.36 #4) id 1BdaJ3-00049Z-00 for freebsd-net@freebsd.org; Thu, 24 Jun 2004 21:54:45 +0200 Received: from current.best-eng.de (localhost.best-eng.de [127.0.0.1]) by current.best-eng.de (8.12.11/8.12.11) with ESMTP id i5OJsiso001426 for ; Thu, 24 Jun 2004 21:54:45 +0200 (CEST) (envelope-from matthias@current.best-eng.de) Received: from localhost (localhost [[UNIX: localhost]]) by current.best-eng.de (8.12.11/8.12.11/Submit) id i5OJsNj5001411 for freebsd-net@freebsd.org; Thu, 24 Jun 2004 21:54:23 +0200 (CEST) (envelope-from matthias) From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: freebsd-net@freebsd.org Date: Thu, 24 Jun 2004 21:54:23 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200406242154.23537.msch@snafu.de> Subject: NFS with HP-UX Clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 19:55:09 -0000 Hello, I had severe problems with HP-UX 10.20 Clients on my FreeBSD 5.2.1-RELEASE-p8 NFS-Servers. Transfer of larger Files (approx 6 MB) was horribly slow until I reduced the wsize/rsize of the Clients to 4096. (With a HP-UX 11.11 Client it worked up to 8192). Are such adjustments of the mount-options common work for NFS-Admins? I'm not very experienced concerning NFS and I remember that HP had "NFS/NIS Patches" for 10.20 nearly every 3 Month. But honestly: Is this more a problem of the client or more a problem of the server? Don't misunderstand me - I really don't want to blame FreeBSD, these server(s) are my first FreeBSD-Servers in production use at work - I personally am working with FreeBSD since Version 2.0 and I'm really convinced. But you know the managers: They know Bill Gates, eventually they know Linux but "what the hell is FreeBSD!!??" :-) So everybody is quite sensitive in the moment... -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 20:58:33 2004 Return-Path: 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 5F66916A4CE for ; Thu, 24 Jun 2004 20:58:33 +0000 (GMT) Received: from mars.webnext.com (mars.webnext.com [213.161.193.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C5343D49 for ; Thu, 24 Jun 2004 20:58:32 +0000 (GMT) (envelope-from apignard@frontier.fr) Received: from portarn.frontier.fr (alfortville-6-82-66-251-138.fbx.proxad.net [82.66.251.138]) by mars.webnext.com (Postfix) with ESMTP id 6ACC59BE25; Thu, 24 Jun 2004 22:56:56 +0200 (CEST) Message-Id: <6.1.1.1.2.20040624225728.05cbb7d8@213.161.193.184> X-Sender: arnaud@213.161.193.184 X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 24 Jun 2004 22:57:38 +0200 To: "Carsten Jensen" , From: Arnaud Pignard In-Reply-To: <62E0A1DC043BEF4CAF9AAFD8398773781CCE@krynn.tomse.dk> References: <62E0A1DC043BEF4CAF9AAFD8398773781CCE@krynn.tomse.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Linux drivers on freebsd (Wireless net/Texas chipset) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 20:58:33 -0000 Try here : http://wlan.kewl.org/modules/mantis/main_page.php Need FreeBSD 5. At 17:27 24/06/2004, Carsten Jensen wrote: >Hi, > >I've got this problem that i'd like to install the drivers >to my SMC 2435W pc-card, but I only found the drivers for linux >(http://acx100.sourceforge.net) >Does anyone know of a driver for FreeBSD (since it isn't in the >Hardwarelist) ?? or how to implement the linux driver on FreeBSD ?? > >I'm using FreeBSD 4.10-Release with almost GENERIC kernel > >I'd be very happy if I didn't need to go and buy a new card >Thanks in advance :-) > >Best regards >Carsten Jensen >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 22:36:25 2004 Return-Path: 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 364FB16A4CE for ; Thu, 24 Jun 2004 22:36:25 +0000 (GMT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49CF543D58 for ; Thu, 24 Jun 2004 22:36:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 64919 invoked from network); 24 Jun 2004 22:35:36 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Jun 2004 22:35:36 -0000 Message-ID: <40DB5737.36CBB21E@freebsd.org> Date: Fri, 25 Jun 2004 00:35:35 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Takashi Okumura References: <40D8FF41.6392C8F7@cs.pitt.edu> <40D92F33.7B54B5C4@cs.pitt.edu><40DA247A.BE7213FB@cs.pitt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Paul Querna cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2004 22:36:25 -0000 Takashi Okumura wrote: > > so, if you know any japanese friend, or if there are japanese-speaking > subscriber in the mailing list, we would really appreciate your help. > (we may even support the activities financially, this year). that way, > we would be able to provide the community much more information about our > efforts. if the topic is beyond scope of the ML, i sincerely apologize for > the inappropriateness, and may move to our sf.net BBS, or to netnice > developer's ML. > > http://sourceforge.net/projects/netnice/ > > i would appreciate any suggestions, comments, feedback, etc. I haven't looked at the code. Although my question is why do you use the proc interface? Can't you make netnice use the socket options interface to configure the bandwidth limiting? Honestly I think this would be much more natural for the task at hand (limiting connections from the application). -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 00:05:25 2004 Return-Path: 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 4B0E716A4CE; Fri, 25 Jun 2004 00:05:25 +0000 (GMT) Received: from mb2i1.ns.pitt.edu (mb2i1.ns.pitt.edu [136.142.185.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB28143D2F; Fri, 25 Jun 2004 00:05:24 +0000 (GMT) (envelope-from taka@cs.pitt.edu) Received: from CONVERSION-DAEMON by pitt.edu (PMDF V5.2-32 #41462) id <01LBORMULC8G003F0A@mb2i1.ns.pitt.edu>; Thu, 24 Jun 2004 20:02:24 EDT Received: from cs.pitt.edu ([130.49.223.184]) by pitt.edu (PMDF V5.2-32 #41462) with ESMTP id <01LBORMSHPC0003T4R@mb2i1.ns.pitt.edu>; Thu, 24 Jun 2004 20:02:21 -0400 (EDT) Date: Thu, 24 Jun 2004 20:02:14 -0400 From: Takashi Okumura To: Andre Oppermann Message-id: <40DB6B86.EFB4611E@cs.pitt.edu> Organization: University of Pittsburgh MIME-version: 1.0 X-Mailer: Mozilla 4.06 [ja] (WinNT; I) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7bit References: <40D8FF41.6392C8F7@cs.pitt.edu> <1087973537.32330.58.camel@localhost> <40D92F33.7B54B5C4@cs.pitt.edu> <20040623150955.GA15320@Odin.AC.HMC.Edu> <40DA247A.BE7213FB@cs.pitt.edu> <40DB5737.36CBB21E@freebsd.org> cc: Paul Querna cc: freebsd-net@freebsd.org Subject: Re: Rate Limiting Per-Socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 00:05:25 -0000 hello, Andre Oppermann wrote: > > > i would appreciate any suggestions, comments, feedback, etc. > > I haven't looked at the code. Although my question is why do you use > the proc interface? Can't you make netnice use the socket options > interface to configure the bandwidth limiting? Honestly I think this > would be much more natural for the task at hand (limiting connections > from the application). your question is natural, and i understand your position. for simple bandwidth limiting control, library-based approach would be the best solution, because of its portability, simpler API, and easy implementation :-) but, this approach is fairly restrictive, and limiting the way we control the network I/O. that is our position, and i state why. First, what we need is not just a bandwidth limitter. For example, we may have a server process (or processes), which accommodates several connections, one for control and others for data transfer. it is quite reasonable to give higher priority to the control traffic, while providing fair queuing to the connections for data transfer. And, then, we might also need to limit the bandwidth of the entire activity (this is how mod_netnice works, actually). Implication of the case is that application programs, and end-users, need a variety of options for the control of their network I/O. We call this as a need for "control freedom" by applications. Second, as the case suggests, granularity of the control needs to be flexible. it is definitely reasonable to have a control primitive that works on a flow. but, we also need a mechanism with which we can control a set of flows. for example, we may want to give 4Mbps to 4 connections. the extension of socket interface cannot provide this flexibility in the granularity. this is also required for work-conserving scheduling, such as weighted fair queuing and priority queuing. OS service for network control needs to posses flexible granularity in its control. Third, we may use a library for bandwidth limiting for programming, but, if we are satisfied with the library-based approach, utilization of network control is limited just to trusted applications. for example, applications from outside world, such as applet, will not be able to control its network I/O. it may consume the entire bandwidth available, or, may behave gracefully. we can't tell what happens. So, we believe that OS service needs to provide "resource protection" so that applications can have a full control of the resource, conforming to the limit granted. In this case, by providing resource protection feature, we can give, say, 4Mbps, to a program, and the program can utilize the resource for any kind of control, not limited just to control of bandwidth, as i described above. Lastly, such a mechanism for resource management needs access control feature. otherwise, an user on a system may preempt some resource granted to another user, or application. To realize such freedom in network control, we proposed "hierarchical virtual network interface; VIF" model, as a service for network control by end-host operating systems. And, (here is my conclusion, of the long story. sorry!) we used the file system abstraction, to represent the hierarchical nature of the VIFs. This interface also provides intuitive semantics for access control between users; my VIF is accessible only by me, or by root. so, the scope of the interface is a bit broader than just the bandwidth limiting in our proposal. if you are interested in a bit more detail, this (http://www.cs.pitt.edu/~taka/tc.pdf) might be helpful. it's the only document currently available that describes the entire concept, in english. i should have provided such information, hopefully on the web. but, due to the problem i mentioned in the last message, we're currently overloaded, so... anyway. sorry for the long message, again. i just wanted to avoid flaming due to mutual misunderstanding, since it is based on a bit different concept from other implementations. again, i appreciate the current control model, which is definitely useful. i also appreciate the library based approach, which can be much smarter solution, depending on the goal of the control. thanks! -- taka From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 03:49:33 2004 Return-Path: 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 9447916A4CE for ; Fri, 25 Jun 2004 03:49:33 +0000 (GMT) Received: from mail.FreeBSD.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39B5F43D3F for ; Fri, 25 Jun 2004 03:49:32 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 83299 invoked by uid 0); 25 Jun 2004 03:41:37 -0000 Received: from unknown (HELO beastie.frontfree.net) (218.107.145.7) by mail.FreeBSD.org.cn with AES256-SHA encrypted SMTP; 25 Jun 2004 03:41:37 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 03F471188A; Fri, 25 Jun 2004 11:37:20 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02221-06; Fri, 25 Jun 2004 11:37:19 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 920A5114E9; Fri, 25 Jun 2004 11:37:18 +0800 (CST) Date: Fri, 25 Jun 2004 11:37:18 +0800 From: Xin LI To: freebsd-net@FreeBSD.org, hackers@FreeBSD.org Message-ID: <20040625033718.GA1691@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.2-delphij FreeBSD 5.2-delphij #80: Thu Jun 24 17:30:33 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Subject: Preliminary sys/netinet style patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 03:49:33 -0000 --SkvwRMAIpAhPCcCJ Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, I have a patchset to remove tailing spaces, convert leading spaces to tabs, and removes spaces before tabs. The patchset is generated with the following shell command sequence: sed -i '' -E s/\ \ /\ /g *.c *.h sed -i '' -E s/^\ \ \ \ \ \ \ \ /\ /g *.c *.h sed -i '' -E s/\ \ \ \ \ \ \ \ \ /\ \ /g *.c *.h sed -i '' -E s/\ +\$//g *.c *.h Because the patchset may cause many conflicit with developers working on netinet/, is this valuable to apply the patchset right now? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --9jxsPFA5p3P2qPhR Content-Type: application/octet-stream Content-Disposition: attachment; filename="patch-netinet.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWT94+g0Aanl/gH/+9kR///////////////9grx7wXjEXryOj6aA0r2ZToChS 713u56bqx3qIvU3Xe++auX3V2u3csC9xWmYzIOmLh7vXV28fR76AMazylT6B68E723vc9Bnm 8VW20wEgWwBSvod02mKqBoJZmenKAXZ3A0b7073vnlPd865lvowAAB56AFPNiOAUAcADudBO Ihun2M+led29Rxi6+dlK2Zxh0DonYUBfeAAAXgIKBbA72dYgcPZpoPR1S7AD3vt88+gD573n bt4F7DyO+g+PYvNe9z7zob7eUs97uvbvXhVdTsddPc03ju++4Ps8OCzYmvu1IBp3aHWHs4eh IUAW2xYMM9qo42O9570QIPYNNNk9zfWI9q1WTy4q7m11bVvnO3a9eveZFXbIm7nHe9nCeOa7 7t7JqmSdwAzsShWkwb7d9vufAcmq2wNq8V3ZsJON1rhkAAy9x94HkLvuuvXr6B3VfbdjvkUn u7vI0OacAA6H3byvu177J9W9Qq40ko2J2dKUl3bvT7mh6ZhhnhKaQIAIAmQAJk0ATI0BJ6T0 yNFPU9Kf6Kan5IQBhN6pgEpoEEIQJGjU9Gqn4k1Niah5Go081E0NAANAAAAAASm0oogaQo0P UNPUemhDyh6nqB6nqaeoaA9QGhoAaAADQASaSIhBMgJpimNU9NGmgp+qbKT1P1T1N6SG9KB4 obUAaaAPU0MjIESRAjQBAICZE9GkxMQNGpgmmqbyGgKaemU8U/SnlA9TTR6QSEhAgCAI0VT/ Rkamqe09Epp5J+iniTR+qe1RtQD1ADIAAGTtV+JBIgJEE2qwgn+EfXcVKIEhjAokRlYURGAy DBVQSLGKgiQRkBEFhFgpAiKrGMCLIsBQFCMBCKSEFAGRIxIKoCMILILCKMZFkkWBFjGEUkiM jCIsJBQVGRIyIyKIxBUfZSPwxKqh/wbW+ouH/9/zDSjJMzhwQGBgzLoRNauK4i4DCKCInv5l KOKgC8xQSjkCSZJmSRVkRkkjMv8p7NDczok8AePwprQPq/x1mdhDp32S2ypa2EKwjbKkjbKk I21BtgFtSHkUERin/0Niz/hduF2y4KXMJ6nBDVNMxlRagZ40oKa0OSYW0tsjYVjjCSEBqK2S FtshLEa4rmLItY22ZC2mWSQtoWGQmVwHBkySYCUFh6xM1rSv6/9J+96q8+pvSiiIjOUwcghb GxGdPOfw98xY598fqr9T0T+tff9/71fTXZEcVLySIj6R2H+uYFdujv68mw01NxH/V4b1pS0u 5hiowO/VVATGL5RjNH6fpBmYP0/P/0/n/Vl2SiUuzixCbmTpf64NUv4efyzdMh50n3eNH6MD qUQRNx1Yh9onXmFrTGKk1R+eGIyGtUMiX9X69aeN0zhpMtalijEH/1acNEHw3yqqiall0Y5l xy0RWMUVBZcoY5lDDLVRtvm3TLJANRKsgrAxmXfHRP8ERNhwkQRjw1rWNGjC2Eb1DPzmSh5F 6OKwYLKrKzoyyc9cPu5LmjcMGLE4LQeOcE9njhxwFnKDZQqSidClhlUH4cLbxVPh9eSWbOEC +QvRq+kFNT3NTIoYKmcuZhGMxOMMyxFRj/8vpyac4oVhxZQQVPwQxwEiIe5sbxxgHkew6c9N xgQkRZCEOPGq4WGHSmrhNOezpU6c+GHGDYK8fDWjA/dazErAWLGy89LjztVwhbSorkttwxi2 ZFUVzLMJmXFkQRGIKKzMzBFRiKqKIqwHMwxFRYIqMctWKNo5cUVVYisWAhmZMcyzGYZbbkzM gYKxZBYiRiMQYrIsgkMEVQZZQFBIYzwDP7q333MbceN1dEFRVMq/0Pva7fpyH0dru9i4FMdu FDGHJ7mbzxMyPrMcTJJrP9GB5ZOvv0EyeQiyIIsY0EKhQYiqj5EX2Qr/dowU93pD8bSLSI+T I0tGZtX8/a3+L68F8EGn+RmxS+I5tacuOPm6zT36xp+z+9h5HF4T9VDJk8mEMhhJo8IiOHhQ rhdEQiRudTXNHj8OYMJjLX5mg03GbdSbZ2uSI1hBsTrG7b6cc2cOBJwhkakPse35Pxz3SHXy hvySYmhQIoQgEQkVU1vQmH6nPx/HfqgQ2fqQy/ysc8NcZL2785DkSLFgqqiIsRGKKCI2vVo4 SB/A8/jFtREBlUzSppxk+NI+hrdu6bg9E/PTjoJVVLZ6iioyJiUMQDhg3X7MMIs69VocwONs DmGjgmr77Vdpaesp30Z0rISbjlhhx6HQVBhjXFQ2mt2QrtKxFQSKkFFhC3Q5J4XeP4AGTAWB wWIjaWwbVjBLaDEikRhebiDmXEMVrEWDPHNahoFYZlmLmYZFFiPQaciWzm4dGSkVgiGvAprp rauj5f4qaQd27LVXO2ViW4IpzaSsiM6zCMoZgUm1SFYuWvZaVhdcLrRq0U0yrEYskB04c+sk EIfFFM5/IyoceMlFaQtTA2frxbjUqNYG6ojNhh6tGDqNSgOaMkRYMzVhmzWs0OioN78y7Ni5 Nu2hdauAadas7dr3H7vu+3Xt7cOHcVZYoKMQUWVDu7l8LVXenMsMmZgWWIMJCMiKhJiuzXV2 k59mOdpQVOanKJem7e2ThNMlgFsVFKCUFiNZKxQqIoMFZqlkR/6Pn6weMz/mP3Znyno8XXr+ GfA6fAczQnBt+G9y/hvXeBxknNd8vfO6eSvDRrDy/FXDF97CJRTqNFmdH/2s4zCucyL768dc vt+k+xSkq+/5SqrWt71yZNBGSjASNehxJSeUnaCQ6Z3dUOdEtc3FOT7TSxURBfuiVlVTuh8Y xSPobspy4InBrWqJqiC9b6/Z0qUq1VPKE04L2Em63dvtjt7aaMRxDfUjb7Z4Ovu/9+N8qqRw /vPwVKrOCj0Lp1Ue31RhKhp0af7f1haJg6NsLeQ5eiPxX1HxTTKHUTCp4cSWJKmaRJ73kj7Y hiEsvsSzxqa1Gbij5Kv1jloSvcS+SxyykknE50FLQXenQiISHNDZAhNZwZbrW+qPV44rdmjA sVh69ahrktM6Z1aZISDtsZNaaoa+xi4xIll7BPD4ia+6SatCcgg0RFylBKB1wqsJWVQkUQUb oOfywe2abIbfr31bJxs5K4Pzee/83t055+z/SUUVuAplONvZpRjYqG+Oq6aGIl1IdtK4eaka kWy5oUhpuiQKXcMIpB0O3IJISYjyyw2M8F3ey0HIz1uvXPg6r0JewYate9rZ4tCTEuW9R6Yn CTEmEuHOvCuAVacecU8uRKE8PC2KXXyr5WxxGHsdSs/lIn6k5/rwYZIh5wiMuSqOC25qmolk JmEw9uYhAkUnokc1Lcmk5XV1Fea8LakmlwcmmIyBIGMtvRyLnoPOVHATTSV5xuNQyCVVZkYj kkyzLkIVMagwI819TXqTchr6mc83Y+fG8GlKm96cOzsy6uOQMQus3rxcXj/451jDxYXo0Ti0 awr78qPW3RW91lxtpaWgp6cPKHZUixR8uPGThk6yZdphIJwWWYJJDRxtG01qTQo6LbK6sYcr qXSyxlc2xyQ2UdIjDSIzbq6dXGEKFlMs3iTbaSsazFiltotW1TTiLj1Vjefo2/QQ/woHb29F OiG5+d/RsCJVZU1+LsHMMhnx7csiCx6o9eU4aE1+tn0YmqHkajwG3L4fVxoeqTvxlQKqcLOJ oO8a7iI9T6bbV/eksB/vsjXRKz0qwu2qkPCmEq/NGe/whssP66maguuMOyJFNBNei7q5RqkC TJOnX0d/n9w0b4DkhFMY+qjC995cNu9T09PWO5I8L9cSpwo+3tCUVEfdqVCVYcePzxMP+r10 Vj8W85TSfs7pSMZhmiCgxOE+l3fS8G98PTHszjzu8iHQ0wqXq9/Wmx6JMZlKoHC0qMtLFK/7 0E+nWsYvCmSu2ucsNtjbjr8p+r6Owxp5aHHQqVFJG5b2MjarNRk/j8d4+aO2HCW8qC0836er wFb5c9AhHzQDnVyySQvuvHxk7irg/z3/LXZ9Bpe3bcWfVmW0XocOdNBUXX9coMVmgRRiGMbm 0Dxmk6cVDIzh2OUGHMSU7diD7pdS3TrDDm7PItqnlD4Q9QsVU+iH/ytXmc0MtOL334QuSPBO xVW80QKDPyZe+mG+zazwUWhbpIGicYywRNntqUoMFNZKGWnhbncGKjTmEBZAqBQ79a2M9Sdu vIu9CCJFkvgjvRuTQxD7fZ5HZYzaydnWIbnhpFnkPTVL5cSIGVP4f2/X98+787k/o2iWmfyL 9ETVzNPcXNQXURnoA9Uk3KPnRsUEJRfq6OOiimUgOctJG0l/WqjITeXly8UuHlCdMFctDjj9 4x+CabsutaR5WmdfW7NqQ8iy7LdCd9E7Kx9qqC+958zQpowx7YeNtq8y2qHdsvjp1aoJzRFz WWsVmhSmRKrFBYxlXW+/fmnAmC/OcPR6nkcIzlfzlem9jh+JbAhIhLp2wJ0pp0layVFVQUlS KErFDXsZqrxOEjbUYvjx3c78lloVoSEY9ZriYkL1EoeUhNPn57+breNrIjSIEbVZ5x69HqLW a3Efkzs322FL6rLQDV7u/hZspsg37Im2RmKicbVa30R0IdaxQWIkTzf5/xP4qqKIqkURkVFy HrAWAr93PqdHfT+H6Oh1VUURVIohMySEu7LJyta98JWyFbrkaMn3vywa2p6pp7NVUY8CilD/ J56faqJxl5VVJFC4WE3xnO5NL3rsq+nniJJxn3xddInD/Jc9nwh/LcWi0k2PSIXWsGl52W9f bU1bvn+CIXjLwLHE+saVkqkcYpEp1KRB3jzntWuM4HZXKr6bv3u5+8+MaTPm9NEv5xSoo7J2 8vb5pPbPug9V5zPXrxfS5xGJL6hYld/9L7lzUKHUUiEkazU+nlm6KVpJ9vC8+nfxU0vtf8uC lvdfKFt897Aw+5enY4/rv9frJ+uM6njIkqqDzJvR3kiFq//UE7BEBf6wX97BQ5kQQ7YB8cH7 6ED+lkigCwICwkh+XeYqD97CU8qT2HcttT1P8+B/vbJWHKBFn78v45mEk0x+uwNas0hIq5lq Em0m0k0CBNX8bA4xU4QAvJBAwq9lPotT8sFMSIEYKRRQIqhBZCO5QFXon4IH9Sb8dj0v1VHl fNhiYWg7NeJtDLih2gy1rmgFOw4lJg0+3JSFZ68sDA/bTaGMKwUDufBCiiLzzYBghVQDh8mB 6Bgc5uSSrJIK+aL+4xpEIRNkzsUI6RW2eZa0C8ENkWjCMpEQg858x+GUe/Ph8n3vN78yxcir jG216Zed4fBOqNvs2VysuXryZQpV1ekn9cj5uOzZeJQyukMnpR1XfLDExKgdYObmIW0d8ZM1 8G7L9KzzjqoQf/Clfj8L7gk4wb7eeF3CyqkuUaCrf7cYsUmOAqk4TudXf3dMzyOJIHBCASe5 X/0Z7g+dWojNIp/WhgnnO64wNnvph6ie489KQgC4/s1/2y3EMTEK3Rt8MX14JQo/o2ae7NxG JvqkJSAHo+y5IH801woaqhH4oto2iH7RMykNoInsFjA1rnICMN2xYoCm0GJJjYJvaCC220oq 2Gn+MNaRFylGMVbC3eBmUJ49/1eENc+8kKCzodBbJ4fRQUNhA4PhSTEMEjaACwKMO9gApUkm IHbLjJIoTrrsV63bMB8duzePtwxpGJ4dk5255p2V6c/HytkGv4cB2J+U3UZ7DsGGSKjGPLUF IsjBU3TzuXuU1j5XWezk0a+Yp7c4ebT9Y0RhIASEkivkZ2d6E2kj6pVQyfsPyH0n0lp+TRDz p26+QdpgxNeG+1K2OJEMEED8fjgWXsrwsgUlTxjYO+B7gsnnIr5x1Gn3EH0B6FbBICIfNIHd ycn9P5edaRKUoqv3sLwQak3RE+p8ki1OGhEuwZcDYaX+Hl6nuiq3OE3vKoeaN5h3GDN8br/z 958G2DcRFTJmC1cqGggxP1j1/j84oRRApqsiN8pA/BTbr/7DnFQYADa64cT6SZ//6dSlyvwr uV+ZzXctin+GJYARQ1wK9BiYiLLvsgRkf835MzfRpfl+EP5P68p8atdyw5gq7UZycyvwGndc sXrYHn6F8uey3EfKeFMkQIMYRvvQx3PPHTeEa2fJMWhsoNyIr+gHFDITNlIHdxS9+K/Z6Nh8 oUaa5ykyiS9Dc8+AVOkHtTfDRnUYJtaNSNQm9Eq/P88vXg7WYHhBj50VnAc1IsTXl3L5F12Q 49hXeXpMSJoYBQSAmwhvtHgIDkW8RFRoRIEto4YlMSDNUgKI4IKZqzZ98F2Mo5KokatCyaOT 46YVBJfQ0XOOJnLu74bH9hPq5esx5dn/Y+paesKIU1KJws2bWc/m4sOOIbYqwMR4UFTbY5AY OkLDMEwwg5mQz/XrWaFIpMzCYRRio5i4YiqQFhmZiKgZl5Q061QzULXWFrlwtVkq3LAhDIQJ J3A1rQGkWOZme8aKEQY8VSob3ZiKq+wZRNvBlWCIoisWCJxxS254UqC/3x3umhBSCjme/RNO tLkydF0JCSQzRjCF/RXxEuI4Oy+ZbdCS2SM9U+qEzsgrzukQLDdHJIRK29UmvF8tgxJKue/y /d8rEyqf3VuPfbN0u2Q2lQQU0f9I/GrC5tEPxr7V9NwEkC/i98ouhSI6rLpUuhfu1T24XkN9 HrRZn/DR/OvOoPsqrJPF65wN1pSk47vXq98ZUatoe9WY50/5WcYPYezCHfbPRdV3wglTQ18a QqqOfLVPR96GmhiTv9mWjArgYDtRMr8Cvmqqhl0RnAu6PK22sM2NSqI4w1QelurOCqUcnIIK RwqjjB55T0PCwsJhCAYumhlcY3tkqdb1XyfNA/hLG+177anKu+mP+yV9CcNS7a/j0RuQYdz+ 1t/Ij6lM3VW4ec8Cbe2xgs6oW7i81wJqlhMrCBfKuJNuakqUcOTEMMm8Tuj5jlw+LKtu9Bou bSgriibPBtz+uGBQ7P4b/9Tsuayj/YZcQqT+L/SrJv2Xg3TacJNIsXhNM4Qumn8qcJiFZbSb Z0ZjMeMrunrRdvTfGHNs53zmdbriiw2zm04tlXWZNamFDkKqca0EouHMoLSzOdFZVq1SMqFF hFhpNJOjxuurUqdeLJtL0oHsPZ+X0sb0JKMYucISFnsK7oHhGzconn+QcwiVtw8W87x4xo3E yLSPDTlt2Q0tuUVJSk6SIHJKKm8oLkeCkqeGOSCez2n9igMigj5ebkdlrT/keJ5Hz6f8IJ50 E1+w85u2Hb7P5ETNfaVXFsQf2ESk0jUsQeTSl+xgYwICG7veP9Wr9NvVUaKA3/LIdnTAUQ8X snEagyDAIxQO+ZMC57eHsAHzx34EgsGAn6odCPCabPxfVwMPzs2KP7YL2fPC5vcX0gvo2Dqa HiLXSzeOJBYoGWL4MUfMFzZVsqfhiWOFrNlIhu150CeqbofLhvk/k+9Vszta53ZQFfom0WI2 cYMpZ7CLar61h/z6mX/HnP2/37Pil0fYfH4kRQq0/n+/BoFN8Y6bTh4HwPsGWvlqg3QRqs/f d92LdhkW7OqVKtIe+XPdofz7VqfsCA95+cqaG/iP8e6DsWKc0Ia4eCh8FKSdKv4uVedPpnth fzXPAtyMPE7dJeGgqFpd49R6NGiUum3SWWv9x16cGiyrcjhqhqW+22wi5SljYE+mpBNBa/Ux HRN9hZtazEkyZndvTRsNRjOEwkFEztq+00mkmtZR1Rj3ydF/mk2YK1d2vkEcm7ps69e/pcyk bIbcA5nYiGzTBLZimqHwtzUtvN10iIVbsn18eyFwFirhsqk+WVTStQOauV2NVb3QtoR5TlhA ORPOPnJMJUlKNAvwPYqeI+BUqDx4PcQ2jaQxIRMiidnPA59sSrnqsbQj2uwSFsL90KK42lDk qicIdPJ9Awfn/PD+GU9Kp/B/ghp/MhOGaZpkU+56N6WdEH8lIZlHeOaYcqzfFOEOdYuFyy2q HVldO7TqlS7651VHiw5R6XaQ0h1VN8WcCZum3rHlHdHVx4SDqmmLKzomM4ejjwwWKGnpmsqG aOsB1BVQclN3nuPaI5AcfdsNZqfjEmeR1why+5vSm+gcc6/9JwontE34+g9jQY/xcbjtZiOo R85a1LWf7/rhVUVytZlVb9yhbiad68DkMgdvznDPN3Jsbg2AHb4BE0nQNQyDX5qz1+nMdhDa arhVLjuud/2lB0TxldHRH/H0lDu6aNajehu9dF7bIM6332kRj6xAPs7wezLI1gdEjVY7tTsZ kzMxtXaUrJdy165aWR+kJuwfsD9hsB37thuueohLaMKT6KOBkRjS1ERYIk/QhRHgpPh6ye2B Dx3dHT3+YTs0Sts8uBu8t3H1FRz+09JVvWw503aX2ygRwQc7JQJwvXqElxxMmqTHbA277PDb Jj7UZrO9NmmPZEE3KkFtD+M+A8s8w+DZYowno2KOPt2NTICLdhvmRmRSSVqIdoVeENzaP1N+ oiSr8YZnF+bxJEG9J2mYQNhZFhG3fqNpsNQ0LEV1User/obYjX3uaVkKxcvlG6OrAMEdnBzg aNOkP8T2MECfv/P+GsyMhzToIGkjoIniWsaBIrJ+KiGlBqY8SZ+DBfuOn0QBuCZoI79GUAuv F0C/aTshMo+nqa/Hwqt85ZWc7E+s9Eh97DEx0C+2mcLZ9XuGqqgoIiROcwDmIafMz+XmTs+S sPbKWKCUoxskR/Vhb7OtFzPzi9Gd1uQhmS64wHEhag3mo2OKRuLdvnxGKzAPb92Pef2+KPo+ kqoSD/VBB0blCAiBA5uN62f006zdHoW/0pyMCRFrWeyEBHvkiIIc6yxpF/CILJsT3FG7rqo2 OLNxdOkxnMPYSZ4zrCl24tINt5nB8ZsPkbwQbx1GhZMv0JE74rfDf4ueV10Z5M820BJqeeim aCnNMKQqXugcHdjsSazMVXg/95EMM6g2BcFmMSY9uBl8C5d8CEeAxgVn80d0vQpqx7vXh2oi 6m+aLoOb6rIRd0n+tz07MO+dDnLbPokYYkjlM69VBSgLl3kn4SRx9B/R2ZNb9c6/uEv7X1+r eW9ieGV99kkLt++Xo+5Xq9HkWNi/tZqYB/ZobHo9Luc0w1hUdDO990wp5VvVztIxTQLND61O RbBTD85Px69Oliu7RbVmxzfVweC32WOWIzEuPB7C+S7yc63+b1VB65N3s31y51Rtmbh15cxm q6Yk6Htsag0MtHLlD0EykW5nA9lrZgfG3mBFDx5n44r0W16ixyPccPzH0Lxgn8x39Jc2Hjzc kyM6O9Yk3jRbHRZJmnKG04L3baUrOrAa9MSRo04RPtzl/d/OKr7OQ/piG02F+bVG6HjVwNGT XK4u546bJNqpeob8SnvhEkaT+PWPbHC6F8tMXrqRHJ3d1Xnw9Od/zaKyPzQlS86PM+Atmnuu rikfaQvJlRAu+RJ6iwh5aKyVSF2anY28+gLrSQdyIcmiJWa5OJi8SN5nyFkSbai7bL1Inesj 6BOREifNrhimRsNN+zBEr6teiFjS3wfC3kJuIyEaXe3dcbiJZhvoRNCL8jEsvDofk0784zrk aK4GszhelPGi7mm917xOeJ/TXOP5WR/OcQApZ+zn1/tw103pTP4pqODw+7aoY3A/z/ZxqWMd MmMaNONw5sUE4aAvGsRE6BMQEEmCpFVjeqfJa22W6zOMTCbFWOuLYmM4C2C+DAZD5msa37CR d8Byh+JoZzKN56jP0mqWae50e1FlvskXESUBJhzQVjlL83vcpE7OyP+hdrCFdw5f+zMpCO7q 2mGakJUh5hdI1cjuHDCSa7Zq7TnvFDuas8DGJZV9jAxbrtG1FWXCZYdZiDmbJE0flYn7iX+4 JFnfdB07YVFBn1LVDIi/xUFVGDKjnlR8omMHsHATOvB2rNY6pZ3ospGfqmenc/cNGXym7cLP V1oZbhSQ7v60sraabiqLEKPpNYq/efs/GbWqlWX7QdttnD2cZ51KwWfRfeQtkPAd8/LxlwvL cTqH3EbrkdhKAmF12Q1vpkQh3ysOMoGFRaT9kiw92VTXBWyroayFpBk5btHITtqiFE1XqQkg jHZ+v0ifOO0rpYXGNn+nJVJtGUKgtPkQjfsPn6Uaqzuy7dJhjy8SOrKxpFoDOHzEGWl/TLdb ZyZ/twsCXye8uKqvuq0z85w33YE3Z+06fMRxpo5SBmtnQe/K9q2s/CBVocHJyMEXEY2InVH5 vi+WW3b9uLw5IQh9sPs5doY3QPpdmn1a6HtoOFt2mqtmkVI3FUDWPxhxxq361s8iTol96Lgg cKRgcRYNC6DNy2UIsP8IXoiykPPNVlpr18NbwhCrW1pTihL5fOXKW8ykyJdzbb59tFne/7b3 S13AxhfHLEZ9lYXAZ5w1dqqixPYYEIFDae6w2/zV9NZZ9X8rboh86hRmO2vy9Gyu4kaP124x 5g9qExrd0JkJkhJhNofEqR04L9Hf8DflpqQ1KrxXXSFIt40cs8tMhoQ50QuzfiGPAmwTkqyw IhMoJhJN6zo+wjFjeu7y7eg2a3veuO9/B3bb03WtW+lW+jbfjVurb4rx+fhKdc8SMbYvDGGW UZd8o1fcFD9V2EphuEC+HN9O+M5RflPP9nY/OVDqagI6CFBHK7OSQ79ah01SJ1VE/WdpVQ7O 4thoTlVlFAIMJyjuQbkmaO+rpqKVM7uUQP+o2Qgrl8DUYVz4rvvjYivQcU1BQZOTHhg5sfJ2 ltdJxYKNO/7O94k4j9vMnnrdoOm1iPRBbKjhMnghCe2+Z2X6Z3VMfiehRReicR9r/VvIdR25 bXc5Vh5N6Iv0loiMy2Q0ZzzbWO35XJBAhX3ygQhYkSNRvwbgu7wITHp5MzoS+Z3wnSH1Izlq TXVGq8z2QLiwRmelsKVOVmIjRCUio4rqriMjbHB2XT34Xd0wdatqX1Cl8Mkg3nNwg+zS17VR MXMTzeGnBuO/fowb7Hvzi7s17crGp0iArJTxCKIZR9H8fhvJ3nMcjw0iEWoefM5CSWTGDMZY yNMDnBwe0G+TP64M27Nmm17+ox9T4Pqc+BjJ0heOFltiObdtYYdd6vrvr2zP5MScGXX19vlB SBHJ+NtnHa2Oj9ENLc9tjYQTIerQP3iIJHEUpIlEQ5Ya4n3ptflKcdm5L7U1xFNVurhIqkTj vvJYYpOdBdo/nBXPNvX7Q4+Xe/miN+pcE32Z+T7ztszIuW+wuQhEBMWCstyhMSn4kCxNwoXk wr5Pc/t1iDXVMcaP7sUZ7UfiMOfr4P4sSqn8rLJ1JZIzjQeSjGwdnMsIEyMvD3EBpEdp+uLR 7NdVCR6L/hl95D0hd+sywmQP291K7bNNphOXvYzOA6cz+OJxgent+r4cfjiGNTfQXkMloITP M2x1DrVWyyo6jgROhLukZMZXtOtnc9bnkduejrqMFT+jO5eDo8dPN4zN01aQIKxf2EGfFOzo lj3SlLsqMYbYPbLskXtusvrFydJjdqqox76mhDkcmyWewcK+QxHriUzxt5InHn0NUUo/IdgR iQ7UX8ul6fC0obVc+WPK+ZgX19U9KOaxxpTgfoNrY3TdmhSDqs0++v4lxZfblthejFvmJwyp bvlVZjuK4U7b6gMCbQLmtlyWy285Ak2F1Q3y5jXoaLL7vwc0nHR2GkxwIkiHzQ0qqL1zi7fK oidhgrX6vN6NPJtWCEZQuyjkyuJ0pEfqHKbHOMpSxPlZy5leu7ArTPE2hwrhAe3NVxJk6zmB 6IekrHqHNFm26Ip2BlapH0Chcl+BhpsldT1j+svHt1EIyN48oQM5y52ZlHHNtIZvg1tf25r+ KrjaNthul1ZGH7bFFbdBRnAt2G/ryMgjFOGReY1XOKMiR5PfCQjQvqqaqB2+A9zIIxWjZ+/7 iiyhc3Bjc+CWq5ZMTZRUr0ODNUWjMjmfZL8rwLadJvRw8m1L17Seq4EoKFhsHuM+oc7My/j/ k1DcexzWEjVVCv75ERmnB8wo68MzsLdl8qszizQuTndfnyIapZDXUm1Iu0egz8jnytnvJwGb ZmZBdcxk2NIywKyttDttsa+Td0o1XzLFB+T7H+o+n40PtHSX+roxl2DDYobq8GuptzFu3V2l Lfb+7wHra8dQoyfegWKKoxQV1axLvMA9Vx0K6zlLCLYhMypzppC4M7EoSOUcjr6H5nLJc8rs 00CEYQhhsZ0lTaU3fqeYUKmJm9Fin09v46NxP8MzkPhnzjedfytfH287v6L03PHn7nDf4d78 92TP45mZ9J7TP7s79ardPER5ePFX91xHnGmYIniZbhv6O49hM/81Q35H7yLHyrcQJIOSvlEf CEEuc9pA6uI7XTH5UOm76cwbmIWD68cz91VFRUxCfLWZomSZxCnzrWZK8wfWcQlyIqykuHNf ps3Gs5KNmsQOEP934YNNyc6F5tSghXxrO+CNtP2LW33FngeUS0JS5qirOYOe2eimwWGcPgpa s6nOTjBsxnazSrH4iC5rgcwuIIjjtzCYw+wzyZrRLW+KwXbZwYj+QiNUskvb00ScxK4ofh9p Hbqi9XkND57Gz2P4v3nnlMc6IHaNdQefdu1nQUK5K0Sjsu2Dafh9iJPvif38aMMejIjk5jZG uPoJaes+nWovqKVSEvrHjEtgPWgdp7TEJEcJmAgOLfXZ17oNGfczp+UenHbplVHpL5xa52Gu BYjvxl6JaG1HqfyZsKFTOtoIS9/LwbF7j93moBC53eZOmvFtwY1UsoR+m/qK7VccaaelPx03 xI7+Z7fAnyFyU9OGHEgnvk5DIiH7yln55YhSrGL34Yj6rA2CjHAg8yqQYM8L2xGxqurKHZHX PbBqed6oEJC38VGDCvvcYuEGmno8LYR/fGso2JfYBHRZjfSjk5e+DZGrlhJ61uLIQ3UKIRE3 Jboc70vpZ9kSFkiFhdi2i8wjJlg7OM/Y0KQ4TnVN6KGFx+z8DAw+VmiDp8y0rgEApA2FCETM fsXTPEVLd9Y0jiQv3nOJiT/Eu5za7H6X8wuHYdpMiZroRXLhPw3Gun32aIc1R0k+80dv3NT5 cpx0HiCJJXJuU8T9p/Gu5crVzhfVoviPEu4EHMcf2HV09hvyLrLc7DB4Ca8wNVKVCfx2ejb8 LtTL+dZZHG6EC6RflLguaGhoNP91RG8fRXd7iRgWtfhC+Mhw5SVT2xiSwIGhBCDSwidw3WKo tn4W05uDTl/52TTCIgjAUIpFfzV/O+141Z8klJjETdOJ6bY3cf0zu4VcNI1CosIUhOGf7f3r 3QnzYPb8ceR+9gtf0mTG/2DiVSM0PWfbRb7aJc6fEX8N5v02jOiDCAaAf0UpUOo9hofuT5gE 9MH/WIlH+F6Llf9bFEjgQI+rtz079p7/iP1w7DplaNGxisLLE7/SjtXrRDW465lXR1dJywUb bVi6F+fAWShdv4pklCc1b0SUQnKd37H88gR+07yf9qLFn0pAq+4LB+ihiTBEQ/3z9zhvQY5k IEMmYeLyuAKqrJJI4siAqKq5iuLI4KgskiKmLJJRVUBVUC/TEkRD+qIn8aISAwAgkRCRVgkY QVNIg/dgG2BbTxkhcsMlXA/Tqmya5SkpmiYHDETIJVC1zcUUUxY2QhK/Fds4UH4Pvnb57fiP 5O/xzD4fspuH3MH5pqRlYelA+8fjzLv8Pu0/jiHdHsfvjWR+gMgrQsD+ZBvyv+PxTNuP1ew9 hUDyJZYBzMdLcpngbq+oZGNScdih9iKYJpJPzH2fHPX9Q/qPcTm2joh/di9Novar6XjLnmaD N8S3VAKBtti5HKGliCJrDgMsMrp2oVf0d59uM7i1+/zXXbgL2+ql6iH2wJFDy9e+j9BiZ+Uo 2VThwoOrCzfaiBs0d1/fSP5RrCWR6Ffq9RLMbNWpJi9VkTOGR2g5VabO0NCkfyTYdf4wCoTG y38EobBHz9ghF/XdJuRKx6UsgdlLobbWjBpyG6crtdDoqY4Mb29y7eZtxTSIZQKYvvl/c95v p1+H5TgbAwta91rRdIhj24VLPOVH/zInfB9pA9JrQHthq5xyVGHagtqYNOjK6N6xTX/5U1R5 K07hi9wIzLT2ffF1yh1f9QfRNv3LgcV39YHljxIovB1zoXmTCcn4LwucEZcbiq9CvcWfnhpI zyWsmu/xRg0ySbGdzO/YD/FtCO/8z8yvT18jVfDzZupAwfC8Rmw2Pna6DwGVxeK1p0MazSH9 PoypX2cCKzyNkuqDuIiy75LtjSwvhEal7FFXJXPji91y9Q7WH1VRaIefa5VUP2lOjvLXu5uP 6X8/u/W/Njynn+bmz/Hxy7YnNJ+jK4hdB+yb6/XKBtUoY3/bnM1otUk2WPCn56Zl3+Iv5eNV vyklRkhbNH5xPVLxfh6KdfWtivzxvdcOBfNMschWLBFVW3DCnhRK/mdp9B5cmMSWzXfw+eXT HOmqrbwqN5r6YVO4+zuNvQS2H8e85UR60bjV4ppmpo7d4/tFNlDPlqPieZvgFWk7Nfr92XMd xcQM5yh3Lz3P/ZS8I05d5tTazmP0RyJQDw5SkemoDWcLeP+0+fwOWq7l058FQ6zHTt2XWKQi HsWw6KF+3ZY34+qst7NpWOOdUNijFCc8CMUlBP3Shu8ITj2Kn0y9CIcJI4x8vb9UKf2quqlB 92ZRoR39Gru/Dr23eHWeu/dnyYwi5oVfh7c98pzpY949gp3/569UIxlzYzub2JDJj2d/p+iR KXe8BFl2Xv9T9xV7oQx9Oqfvuj3+ax/88OQgYVcuFkPUtkuGGj1145Z+72ngWGxAWENmvT1d GmPVVHdwJERdVe+/uvP4VP2Tz+Q4veT746MK5dcX293v0x1YKkaUp3+b3rZSrsnDgUh4+Jtq rrZjubSNbLrCDw99T9e7oy+idWne/Xwe+/wO/f7IS3dXF4V2Fy7sfTPwUtS7EKyzpS0XSMyj bpak2equUC86z19Wo7T2ZairkXyve9G2vXt5XNfcbe3a5st5v6cOrr8Wxpdrw1RXmv68htEG ZhJJ+hWwKiHIi1U5oavHz0OjJHThanqvpnh2e2TSplzwdFbvJ366sLdqda76TPgVlhszZyu/ OWG5Ttndguu7dfZtlDju5tOxGotMssh+XTdJak26anXGuCSw1a+N+yW6y67AlC54Rqv7I443 UT8sLK5127F255q3nr114PjSd0mwH4WXRKvDkgdHLLkTVMy4SHZxMOjoGG+5kn/cAjFikWSC k/oTGpMisYqqisQ/MkBQlRQFWRxLEVVG8GlqmgIoMGImpRRCLCH+v/5QcapaUQ4MMwRYMq0o IoICggtZLabtLu/50huLI6aqixIjsq20sipxmGuKbYapsbg2gLGIzLKyQVDBLIkW2jGCKbTW USLBJm6bSYmpEIkZFEEYIgqKqIqMRgiIxERYoh/42UYCoxYiMjBBiHNhRkVGO2UiMGKx3YBR IKQFEVVixEQRQxKsiIWwowSRgjCKqojFEGIVIVASCDIrDSGMJLSH8v/a38hAFhF3QBPwxA5R DdE/ZiEqSGMBakPSwNJAWdxaVhNYXP8//X/Vo1s4wKwDGB5Mh3MkNJFwTyTvQ0MY0gdBwg5X K4irNfRZ/X/u2bkYtECYbKbSaUxCDTuBaYZ1vUVe7K3s1LHt87sxKAUU47YVUqo//NrwdkTf FP8j/UO/6vb/wYvuIfjKaKPdSMQsLJYwEiMlbSh8BzusogLCKesE2h7QkCCgQBhjKSAhP6yD AGQUkQFBhERCwJT2+5CkE+33YIJ3eHvc/qy9N33w+9MZ77GOG/k6p/n+26gO2KCPFUiD9QYo FvmqodKKkU+gP4ifP+D5T/L7bmC7oCv+aH3z8txTqh+8ywD4/14mX0nLwX7ocf40oprn6OSU pXV6yN3erJf4RcbtVjFF9exnryvhbtm38v3+rH7erjU2SrCSZsIL9TsxgybLz16DoAtrhU7+ zTZMaMzdfVGY0m2/ryJ1+hKupcarLFIb72CFW/PnjFD5X8LuUpy8KByYG/QOhC1Jm0qO3Ihi 1tQ1ghjQyC9CSon06O0Xb2HSQCC/d44YxBCRdkH7tlTdWqPbUbq2rLebl2xcnuJ/j/se/91p BWvws2ckGUZTqRdGr1M4hOOKPSVHKQKikqnssy1dJ7iBYUK3E97eHdKKXdcQKRpSkCCkUg5Z izVL4enJtxoKbw6uxYGzu7KcNe/G2uvqB3r0hIMIEjZ1Pqsgdny5ByCx7wMDI/bbmeUvE0j8 6czZdnLszn5EKHT6ONl5uLDIqkVLUbaXlejVpIyvRDaIndfFp09a3VnGs0yj+U3uWF3ScZGO kNM9IVsIj1fQaTH65qeg9HsG9mFNDHPSHoJV3aGa6bVv00K284UNDUqSm8e89xHhGhsqawgc ut8qHTY15GPP6TdV0lVVXpy9J6TPRfqNZu5+b88iWJjn0HkbtXJqz6w9qDiXHSXGlYRddddy omIArxDxRRDY8NfK2TV+nyDXwa7mtzt7Zm3TVW4SJ5t0mNOXYeOh7u2vdAtabbM93RpgstmU HTs5H9w+Qh65YFztTVWjk8oHeVG8cgzz3mjRZMMrt3jOFwp7u6nnP4f5eDkoyhKB/+EJwIyi J5kItX5FH7H8mlpPh1eM1Skd6tVMqs5yEQ+pqyXlybuI1gd4i5eNDkJoUEutS8PGMTjWSIia wQ9Du+ROQYHLJIMUVomlFvOZLq4iX0taMxjCrWJm7Ws1iM3l7qNXnSLVyTWpxUvE3nWI1qzO MPrFXeVTvUYHhTjNuaoyQiSq1rImqrmk+VL4utXkzOVRl8qc0pVXh3wSou5fJms5e3l7mcWR GVcvLy5LuZWqzmlEVd4nSnEarD1K0s6rWbzp6y6JujFmHnVmDDlZeyqxnGM6nWXyow4+bl4Z PV6zWBQtFyrwZKy2ot3Jw84znWtVURi3Mvp3aFecmaT1OH1ipuai1SerxRmCrHHzOZsunNQ2 HfCcw92WsKXREvFa0VeZzmIl7qou6x9n5vP8L+J93vQhJJJAqsVEQURD98CBP8qEkk/yDJPv iKFqViDCRYjFhCkGFIJSCZd36P2XTFET4Np5WBBt8lKo+YgIO0gP6hN3GQ3czB81HyUmbwik 5aIddvbtUY7jEIMmQEk9lj4TmPvMcA8YyBSBsirtiIVnsdDR4QkUmtFSERhBSbCIZphi57i+ dobNLXuaxp3/c+UhBjCXNVTYY8EOBqZ3AOCGhjnHOErC1UI7IK0G1lCLZIBrEt0SoCYPGwjZ Yh1vh3Kd6B9Pm+U50afHjpxv+IqlqbXrqNb1d1MtZSwNLAxeRiNwFDO6bAxErR3j95LA2XcJ v51CGK0eT1cZ4+VcyN1j0hsvroe+FEemYv9v6Y/PxecR+BPZ5R7TfUt6N6U85/MtiqX49I3/ s1EYf1jND1U8y79rk5/O18Sk+eVGl5KKNW99q5eTFqqeaj6SpOjH3dY2YCHOODy2OWjicn6/ t57b7bX1WyMyV+Zu5RcjkpiqIM5AgfQGt26bNOn9J5TJmyrARkXGjXs5rfGtUHtx1XKComNO 5ddvMDMzazcfb3e8MBq2bLyzzdRNilBPSAOiDz3vGqdTw3V1kKXFKFI0liN5L3rMTCh3N5hb NvveDW87iYUO5vMLZEPc3E7nDXJmdbs0sVgZA3r+6o8n4htPevyb+q/2KxVxhvnd708RKmSU al8zrM1rGcasdWtRrU1rWsasdCSuFMyi9PnWtft3pu6ZJhtjaY8u53TcDkEXBa4WYNGTpcbG AhpiNiON0Nop82dDXjkN6Het5rZmYigw06/Wek+WpyOQDtdoReX5A8DhJ+JRPNAURkImBD6Q f4iIv1pUQs/pgxl/3Rf6catAwlRkMcP98TOO2GbYsKiY/JBYwM1JCrhpcLEFhWMTBkUObZgr oszJDFQbSrGZlkwYREEYjARkRkGOmEoJMZQRGawvIkJqJIiEimr0JaWgXipZ+T5/n9l+tv8+ p93x52QTJBMgKghbx9oer2wRL5h6TKj14IJp6RErAA4giPl14DUYvf1+H4sDq1sWKKuKkK4x QI+T8NDBcIkiXP4Od7BhnjYAfyLOOqfz2GlJFGDGRILEIEGQYrPPSLp+cmhB0P1levnHwilf oxHV6tfF5JgpNjo46tJCKGhExNPWIJcsWUEzP4Y2kw+uqduJN1yQzK3BoIFpyLSf+xocbDGM YpKQZiABipOqXSE9UOXgCDtYnCE1GxxyMnJIbJfa4XhadnkepsomqY4MhxdSBWH5EUSjTdH8 iCjoKyH2z+Z226GFmVC15bpeX/NgyHiSr6ICEHSGE8cDa+j6MNaZmx/hv5p3b8Uc2eMp4Kcr ah53YO322NvUaklO2dTNqPZOs4kLE5JRTyRFZvHfBic5e3mqp84fNXWtYqnVXW05HV53LvKq qqoiKqqqqqqqqqqqqoiKqqo4iqqqqqqqqqIiqqvaPdnT7GAbmAa6OjyG+R8fH8Dr0nZnj69B b0tRF1LVX1lqr8jifScB6AgJydJ4HsLTt2stVVVVVVVVXC1V6cnQgOw3tVVVVV9Wo78EGA5A QVHJpd0naW3t3HPsG/lnITOm0RGQd0qztg4BMHJkxhLJ2IhJJLZgBYJlJJJJKyWiEksDulvt /3s0Dcs9HqefQt7w7jM7y1fInkZirotVbtcxeC1cOs+0DjuOA7F+Q/I2g1rq3RJRI23yPIqt 5I2q+qBDt3k59h19h3tt8Dt22W+MtVexaqqSScwA0g8U3sTBzh0xgf9tGX+u9yCDKG++8g8Y yyP9/QF+VYWpi2ajhFglcXc0b4zOqv0H5RbWmzFd84aPnEak+nv6zE0uz5odVTTFzOMY70LY ftMao+BpLs4DqZuEIeHs0eiuy1VVVXZJ0+L1OOR55XC1VVVVdFvIHxOo+g6Hd5qlrzlJJLmJ OG2AnQb6ScM55HdJJJLJ0JwHmb2qqqqqr1lvbA8TkhCngdvEenRVVaW9OelgQ9lzuOevobev VV8S3Rakk4745OF5GDHYWcpZd0ksM7pRPdGheC7VVVV416bspvaqqqvjDz5U6zz8Kg3DgcxB hhG7ViUsw1ar1N3lGUMyqXpoDrJNFEkR8CoBJMGdaxT+XOVzoNaS40lEJbJDdPdPfuqvFRlq dyCXiKzD4zCSbZIJtyZux39fXgtVVVV559p7vc30h4GzodDwtXsWqvbfU4px3jTnlVWhLV/b /mOf3n55PfCHU6dFVepI23FvOoznUbwGMN33nb2djczLpaLTRSaK5cZa2RJjFEkOohGDUhXm u7tPNOzO/ZtkMzB2LCCMNECWGkirWQPUX4XZC+L6TeUcdzAaMePN3fk8o7T54fCnGMrJhFO6 jiMRT1CkwsanGc6xot5i4dRlxOHfu2NYSQUcGCiTihbILO3mlB5HfRBVXxlO+TQGCDGEq1vK VVgd3He4Fb0IcGhdyS7r57BZLLu+C8uJSm6d1fddeQZsDBNWtJ931JMkJJAk0Tzdu3u8ewu/ pl++E5WKfBi8B6514eWlOMMLetCnW333OLpxO9CDRwTMYufKldYrcvsSe4nFQ6qMXBOc6i8Y tL48nsLk5Pb29rF12SwP1lO/BJB4JN7Sc2diZsHeTg7m1gT5MYSswZzTvUJJKiSkdxNVOO6V YJKMc6SfOUkkrM+Hkd5MEvog4JlLB1x2xDxF2lcZ324jT/pBJu8I5hk9eBtO7eEIa92zEFnn k/iY0463+2Hx0QGBHBDfSjt0l0+0n9jRJyRN17R7GLqoq3Ve2rzh4xZOIWcZqbu8Zd0/nwMe 49FTbz7j3QonsKpeiIgo7CDdVTu/REJabsdijucGML2OoT6vkd08zQc8qviZ19DbSyLFERgr varS2ne6G99ZDx8M833SE/wSYHxBJP1NFBC4FQM9e25G/WhKNAhGx24vQWBgCkMAWDe6K/JB BCwndzuIySaPQ8TdivFek59byFmiS9RUzi8oyXcOz3rWrHJSWD19UksEER7NRMzLcmwoqkpu ZomKqncgtCFwRe+NPExOtJJcaSiEoLIhyC8pQVVme83VxdNchWaSe+iKUhE0MYxYm2za3K+/ iueeMkYxNXinsxCbXbt4B38M79DulyDul0bJOw8cvHMCmZl+jY1lmtJaMkjmC7VunyK5l3d9 ikwVUkMDFK+fr+Zhu3bIeYZQhMadxkmSPMduxR2MHnRGb8+0wvLF5RGMZNYlF1RkuczlZvU6 nGnqMvmiHjBog8vJKh3slAoijzbRQ6ELQjhtvmHzOqUOtFBlrrge6JdyzWhM5xZbqCyYScMS LBHFp7hRGf4etfj/2dlnVT6/m/jPHzTvM/uLVVSw6Mr0/vzL+szQIh/jCPxT4/2Zfq+rQ0w/ GewtH64O+C/n54NuORSu8/m/pOzpBdvAZdkY9XOSYEh2BiMHn1sDHZ1VVSeaGoZD1UUWYeYS jGbCsLK1zmrk5g5uJEhw3P+X8b5nGrnqj99zeWo/lMmYNF4fuBYoyUkTF7/pxqklXWKm+f8s dDYn52V2Y5+P5t5Ynjscro0apcCyuU34ZelB8tDl6llZKcpfq/y9EdVnd8vRSf1rFdAmSHRa uzTzQOxTQkfxWeGMBpeHdCOfDqy47qQ5k4VI/RXL6RHCrVFaZMxypqJuVVLoUtdUG+HTVZjv wp60D53kJ9nL179s9yW92qTYLsudjkSmOT2SVvp5JmtMSrjvshHwWqlppfctyS1dpb0Vdcwt XMtWKV3JHFc2KnWn6qUpGUuapVT5MpQK0B3ZO1iPOhHFOwwquTBr6vKlawwUOmJDzXQ5022D 9aJm1ytXJj/dzv4qe2i1ZSibXCMH4N7rDptzn5vQ9Fa07i+Gcr+sQ+nUU0R2puFer/jZI3Lg IpFxiKCmT78t0B0mWD5wrz/O7rrmDpizRzaIsc6aNO2Bcu3ucMtNgkQryv4x/kWudyXjsj1V XXRLdv/e2KNPzvuh07ow8NfNH0Xudv1aIHaqkuVz71zcu/rizcob+Tui3MUchdv5I8Uzp+Hq h6Pm69dy0Q3ZdNMt1pXZ0QyXWujpcqXepnlF1hv03UG0KdJXR088nh2qsRqXeuAdjJLhHuqj NuhHioIOSLq/0y8tc4XuOTH931PxXGflAu1vHnueBbr8cPhK5HnXgvFBCv90DdS6GKOCDjn0 EBXeHqj2Vr482sriSedcdzRnLCCUtxEhph7VEhJ8iErcZEjRGL+Qj08prWOBY3YugRMQezou NNpnb6uSO7Kn/lIJEixZBDlE/KReUX+iT+FWg2/0Gn6dLYGMFNJRdoK2lVEY/3WFGDFVRUOr qT/lQko/2ULCKnSFk4gr06UpaTav9NN5RRU3hjBixVWIwQRBVDCxhpD/I60ibyHPdbtMTJtk 3KsDYlwowOm7K9zJzs4wkNJ1EkOhbKUpOOi0iKw5QLos6DNDCc2hgw6ZwZ0jgMKgUYTOlwSO JVDWVIYxvBvFsQTOXiH9Y4mN257oIj/hEOT/0QTAQT2FylE+3P5z1Wo+U/cfecijMzWCTmFE CEgB3/VQFkUUPd5rZoJavp9drL/uCihBRQ5iih9ZQf1EA+ufkWv4wYn9j9hcIv6kYuL88fYE D9/yZhhIh/Xlmx0UGudSb3sNbkMw/sn+U7esNHKhFtvGi4WaPpWs0cR2v+H91k5MUTMx/t3Y L+ZajYHol0gYhsp4EEubQiHZRiG0u0uBkGiEIBtv2W0A2DvwXhDRd5qQSm31OQ7nfP5TgcHM kM0OjspRy3aIbFXgbigwTmSg2ih6upuhG2431uyCFcQhR+kQl+lF3IKD8tqdideYh/WXwV7T /aj57fhMG5YgSj2CenuETcrPp7jA99EliwLsaKKDtQ7BEEa89qo7iQhHBgiw04VG0NjnGsKA bw93BSgOAUf9yWPFIFMGg7nmPN85Dm9AcV6RzSCZEC4RhtpQ3qsUYBH/FglLBIhglcw3ZwnM OyKO7ngffKMTtU41tXgiJlACm3JBLjwub7C/hgD4lUh4zVdqCRhBxNEczpwOr1LpRasLLMW3 W4cz06pmcKUrM6oUM7OzaeJBKJb/yN9kQvczdssN0nRxlDqtQt0su5UGYJdShDLDkkLpg+CZ obY9185sRFMTQaV7bJgksZ99g0pvv9SSEYMYRMDhQ2hduhqR3B1GhyUe4MeIeszuQi707SSG ka/VXTTjyt+UBDJyEBV6pjo7OBiRTUWAVaipym8E8bil5Qtqja07BDcpYepglLcvX/WFLvKu EKh9IgiETE56HTCDoOm+0jDbHYOUr/a7HzoNDXRkQgPAaluWDuJm93IUG03pYQNmTIg/B55g 9jkOeEDUbNnmTwx3bEJlh3SZIJLg7AYLpUNyHDduQ5vYGprh7QmwCQ7NyeQXXV1mJBKMN1WA qLsN/LV52202yzORFH0g5onbbdsOY5XGmihviEO3G+8m1vcq3PzGb059KXsWwMezC18wys73 K2Evibyw+S9Xwi29HbXh6Fvp9FsDc59EId80z7BkDKkDEGkOeeVXKjDdu0LFxeKiXGjECAZR KQfLiHkjZC8C6QeQQOcMFI0ZYFiJheLzYCjQLCqSVne/ZwSX/zfprmRlFIhE20NHKERN4B7i 6mzsgqkhsPCret3BheaJaMi5mTsUkIsFVuUOByAINkwoFHqLazEO9hgkRyJWw2GUhZPtPcfP gnacGscDDIHAIkAgsxHfXR7O3xMkyDMgJP+hRqh058ceij1U9IZwIxT0NFJnjZej5B5V4IJ0 EckBcgjiWDuZmmaMNA6FBQwLCx00KIRSsTxDqkCsHYhi6HqNIyPrjYgamCq8FmH2uNW3mG0P UcHXjuV2aUJGAj9HiEsYMYVk/Ecgj4O1+5OWZBPdBxskQiRKoO4JUF2dnJvQdQwWL4IRLnM7 k5EfSFUd76bJTC2XcM2mandq8YgPzIJEPIzoADE9P6SD/LBUtJBhHfH8MU9UXynVIJZTGkxt 1O5vRYpC5BTazmG4OlB6LWLW6UPW9IGEUai4RA1IPWhiKQiQO4bxmGsMSRaT2iEHUOxIrw4c b2as0HjYW6mKceYtByUSBc4hMzAK4EDxqHty5cEMIpaAsIIOP6/ThZmANBs9vdKkKi2CDIwD cb6zRjx7F7jd2Lmc+4zV4DDURDwu6WGDMoIRExDOnNHvL3YwjYOZ2mp23hCsYH75YiT4QKKY cANqSjBlqFg90XfQIgh4TR4pYY6K7UG8gFtPHwXQwwTINyPmDM3m+g72QImJSJY5o0UQjcTD w0TI7Snx1DgWAoI6o8jPhbi18rfXdFkXitAlWYvAGlW/hGn+83Sim2ZkyCk+U0WH0JpGb0YY NFELbRMIpUCUbAaHo6FBgBjFNKHFMw7IWbxjiTQOva9cUsYgbCIGNVBO3719EvgIGgGo1IJB STRMQTdK343v3H3EpmfwYUA6IVtxucitqWWRBI476Mb0wHcEMxR7IBsCK/HahbribWEhtiW0 CBUeluIeWriwqkxNA7Yj4Q7tS+b1LdsPWWLURR0osHqDeHglhmAXVdgEWIQo3FwzG6uoLmL5 +Z4A+zXNDvHebsePTeT5gyxnpCrmpdTXi5g67uGOw5GeWAOhv02UHxEIkXbl7ekOaWwEpDMz W+1Y4szVSFBW+dTU3ksEO5TNgDQvF/NyCNiHDzR4VoYkTCSVKWQ0MCQYkWFF2CUBtrgcuFJt vsvv8wo4QyJqsNRzhQtGGLjHnvCZoLKXDSOf1KWRTI4U7fNPJosU4LsYoGHHfUe4SZsB6t3F 2wUNbbIVWMuMdZbBdDYJ+OjGZIIkY9PfMPi0sL2QB29e3aM6G43guUgZDF0wrbC5noXJVKmt 9gQ6KpvX2IeKEKMhDDcG0HWF+uCWbnbiFlCdvOZpuSkvYRsFVZDyTIaGJppYcMoalzeTYd0h r48EmiGw4YhQhz6m9LA5jAZBcYb5sIUG4gb42kIEgmlWCPXy4hcvtQ7D5EEpHXPILGpSV5ZP OYJ0Qw+YkdR3ZXTo76uHW9gjB1IIHOHW40GRx1sWEyA6UHpDEd1ylU5HHEzxx9OjbDmRIavJ zCgIxIQ0DASyWH4phcp+WPYYl3pmNUk8ptweLm/XGgsgmaGIYxezBDkEQhZTcFilIRDMT9wR PZrS5OmM617q+9u5M6lcEEmWaQnn8rWJPG97QmFVUrA3dFIEhAi7/SonlmctnVTWM1XGdjNy iEC6fBTd0WD6KDCMbNIc3EJDgcAxosgtwb9aLGxCZsiegiOz2jPeIuBM1k2DAmzyH3HzHMa0 23F7kHLMV3LvxAhBQjKFERLAb0G8zeEZpLIJcEXoWJcKDaMCnR95OTAnUIciJwUKrD/MDC8t h5MhUQ/m+hVy1Vtq222qqqq0trcAOUv2meD90BRhToQwHJnN2nSkh7NJDdR7aqTMGh7S2DNs MgkmDIaXbJZaJRAi00LHPTiSjLa1gbpB04xJiaOFXGQsOcMLtIBpTYrsLdOJIE1ZpNQsGJk2 CTINnGbEGLwaY0xesWE2E40/4wLAGZE0gyfspaRkExDiaMNatqprGPCCVF9eESFjTRk+Liso +/8ilEgQkIGCxIhDI7dvYbD27shNIaSiBwIeyVdy8A7DZjQm+jZ08Ty7GKJeIgc31RNQTfc7 M9FHYOSGWljMR1gZRAzsQzuljIekkls06hWtipDFF0K0XlAy2mNQG7gkkkklDBqw2NqYLFgW kBNIMMos0MuM+QmINg8ocULYcKahmGSew+fEMBJgJyeJECQFh5BGnzxCRvNpW3uTSPwO7bmd PYmADWBsEBw69oUB7Edw7QfBNF+n/itv0tK4xDE7SkcyWPbg0cDUwfE3u16OT8sDkowupmnb o5Jj0bQOwMZUnw29SPftIOLbIlnmGBeiDvDyo7QT1MdgUG2pqg5IERYPg4NOkEDmDwehLnCI 7qgm1e4FgSIQAhvdqpkLtIsMWEmVFSBIjZEuKfLLD3akgnUsTW9PJEDuRnmCQibeYullE4js MzvO0TiEgZn3zlH938XzWPGCh9f3H4fziEUEKbnj+z8z8S8nYSqQFbVBy+9UC+AWJcBysKFo Tvp3uHlOuHOdj2ip88+57HmPJ5jf5c04ftXCD+zxOQP6YSgCKnvPwRpTdwX4f2++tLojqoHI MH+0/z/yhb4e0KeY7vb7SZ96GOmoKHEj62BFR6ggHxY7yr6Gb5j6JsHwZhoWWbxQ0VlGIWNg SX0hZRJEIanEJxsAsoRhB9HxMiJkN8LzSYNryVtQj40CGjOYa8j8gLB7AxIlcKgWrSZ3zIaA naVBhBhvcx7D+wgk2b9SwrHK8MWmYPUtffs9SRzZ3yykEzcBzOwj0Xsbrk8sVLD8hTMdz1JY K9jpm2MMIZuuX4s0pbKcgTBVv9/7nwOxP7Woz0N9Mawcr+IQMge4fAcQ8S1aLgeOSNPHrS1R qR15bQYhexNTti4QczLBzdkIKsm07Lcg3kgZNe0KV3mgru1F+6lG1Ai0ys2b2bMw1DT1FTjU MSpg0sNWV5UrNDXWVWuirbgPfJDzYGwzjq3zZQGZsaN5wK5IEalDMzEqbq5HXsWo8ju0Mt5s Oju5GL1Cci9r4cl6ZdbOnUjomIUZNw7HhidCkxDqllgG3jibjpCbr45tdaY5tSLqxUmbjpgS bF7aGUQxNgXKwxaQyaFxQuDX7D/1I/Cv3SPyo/3fSge0SQEgkUhP75RJBYnrpNvn5ltN2yeE JDylOP3thwOnwYcxhyNBQauSQ2H6D+YCRhmW4g5s7YPvhh0c8cBf+NKwVtNAMTHhn/Wu1nWL YznUT+AOWFlbGCMGYoUneezL3gi0bINKZmmVg2AtZmUYQkGYf5wA8vTSpoYJGQESbPcF9fBe ohsZ5o6ktBIvI2hUVxHJ7BPrwO0cUvY4hWjAz4hxhLr3mFdyPA0UzahtcKuLwTszu3YDpzMO FX6ThJNweMQztk0A+RigR56zkLpcIxJwAwTLvJhgtzkaGMG4Bp3jYLKcghLg7OfAxEhVg0TY hrjmBE03JyDFLobyIuGV62zUmRnkG27od45xZGynEh2B1FTuMtdQ2jkGSeFb4G8YwwCxwC5M YcniHAnkeIbnd6XMUStBf8RStXr4oxN4CI8kYRzKC5mXdkJKi19lXXw6mEx4a45mCETdNAKO 86oulu+ZZGZETcGDedCZINWDsJsiTYlWX4swxMGoriwyHdBMLrGpge0tLzN66OydwFhRjYgr mjLFnZYs1eARnVQaQTowD9Wuu7U1XzcEOFsdDgscN5hvMDmiFRPa5UJrYsQm7NMim2FqbDM2 owLJW3XVl+Akqm2tKupwikkigHCprmKNvSSSpiFAm2RbyNovLU2ywG4I5BmbzY80zNeTTmUH ES+1WFolmGSOIeEhvZW5Th61pkeBC6zjNSr0Su3gi5168Sg2ISMG1ITQ571uySLGYY8EX9W7 M2qNCCx84Nh6D2AbR6DeCmoCWNI5hO6Xswk9/yP3oM8vXU0lLozJgIyY4pJXAPQRw4UnZhvO D2mtlHqc8DoViThxMWeWYy07a0EX1QjPAt5UKWZfqXVhrYhGzHhLDYrProY8Tjkb+SMN26hN crOquu7USwSSCTJDLC21MX2BGEYVpKl5rLuAFrKJiZmTQfW69F/k7oBh8UhkIGtCCMQp1lnY YhNKMCLKkv+PfibPbJh9bMO8vkdepQTTs4sJeCj2kLaLdJ29zSNYoC9e4G6Iz7kG2HwGF7Iv hwaFxNpe5tuxTVCa4QLtS1nmW95l6yCQixhvDuiwIhCAbo0EDWdyGwIHeojxDDPSalBwtbhG qpbhgBGyVhqWALMQudDK0NwB92KJiXYwk0/0mI4DP2dS2Q9u/dsz4lqf964KdLuCbjlKndSZ kKQTwLLvYFLOX6BkpIeKHznYRKtETaQMIGCQh2+0xuuUOEQ/SwDOLoPV4EoWHIxPHWCMZwMn qQw4ZYfXcQPAHFUsOAQI11eYjzmtznYooIlAthECcS9C3nNHGxJHCxVwqEFsYq/ncvdTEchF JBXkeJmflhGBdMOPezxjYlzwQdcF42bfREEsJy5aXQGR7huugga+y5c+Vj6irPQtQ889jx74 Rl/dVHCjvVD+DuoMo3giB2sVkkliqS4pqdKDxIDphe8XTepiP4yfWWMsvENXRvHdjZkhybW/ 5EbkbFXAjYtLYUBZbtKuFND0ILkEw5dDkwwwyRpY7xP5vGxhmZQ61T5y5cqCWdVMMTeIal5i p60AviliJbMg5MPCwmkkk+Kq5WPxeko0BhSGzA2YGAdTaXbhoMVeqq6OBoXWEM7Wi5vPwiND BACPAUbGQMwCj9pArEDywUNYs8xE1SAP9A/yb+K7cT27eQw1ofKA7sighnAoCAYsagQtyFvI uDKqLh1DceLQSwQ7OPma7wyt8SbeBcxa2QN++E8fQanYQ8gsolLErQo1VKstYKIzzD6RkPAQ 2DGE+CEPeJ+6KDhyPGK0m9e0h8sW0k1HaWYwh6YhWNFEiBulGIoo6JYSiaIdTz93TNIVgMRm f24GIiCCiTRSw2LAD7NQMkMyENe1aSDqEZnVKULFU3cmjgScnEIeMA+FFpEXYFfAzVOgLIGq 4yoyQxDaGxSjI3l5o2qYGMWL4p9cuneuv9GiA6RFDrV3ZFXDfRDF9ZyfAY/B6tYj5itobXpk vOvBQaCaLiZx+07UHHe4/nrF9ZDxyKOCaivlIwUkPob6KH1CjC1B2mEyT3uB4EDxNP2+sORR Jn2vRHxwDsevx59EmR1chXBDkLP3algFSNLIihdYP4HAg0vEGeQPWIiT7Ddn7+52mSCbImyI BlA3Kx8RTH4CxsfXkG4xXGSBIJ9z/L5Pz5mEdpt4c337kHGDILtnxQW0R4MH8GjtY2OU+YB5 honnx7sSoxYMLp3eeHIkCMC51NAoN7uz1W6Hiu9Rr8HW3qlxgcgaQv0Gt5ANxFidksS1SlRA 9cxEpcJnBDBo4kngzoQCAs0wvr7zr1g/UAE69s9bOtEHZlTY2HKUQLOEAbLDSxUPpRZZXvbI ycQmwuVKWiBQwXQWWk/q3DCEmwjQ5S4W84HJ8iF3BMicOTqGoFiYWOgVBFisTKFllGSywupS xwU3QxNk9EZ2VUottt/oaKKqIqqqqxWKqqrIeQnYiYJZsHaFmJvVo1gbB9glEIh/USAc/6sz wLf6T/eNiW/1tbQDSCa9zZXhuKo3nFIQWqpfLAwHQJAgljy8TRWFhoqMQLlGxNChqm0ZtROp FTWKVAghegsB2i+oqEoJ6z2iFkND6AsptJIeePONFosEaS0MbGEwb8qneACAaAzdzK7SwNIs t6WRIwyajkZqqVUpJn1l9xAuw4oOvhFcX1SC9rC1QbMJJIgLXI9VYEEk0MQNoECl7aDipg6H 0tuSRMOJEuUCoxqUVjbjAKAwMYAWQBo1ts8lpCgtJSgoViISiCDBGyoUqSIiITJQbWj/Fhjg wbyMlBRGR1LEke6ioXXae3i/COJvYQPKfDHiB7IpOy3w/CvF+SIjywdppVvXe0liEDkSuh1F eZIHCwNEG0rr2P+GyJ5NyEqAlDAH43Q7Jr/bgmPyVRuKjCOlNki+lHk0AfFjv/GxYGkx9o+M kjpsCTBafWj796gS5khN5C+kBIG/ud4EhIpPaAxWEkWQB+H0Y8bTXI/ABXs4t8Lh8Fnap8oO SuLJxEIKEAWBAFDigHikOGGb2WKCMYstSWp9pACx05Z96VZ5G5GjHRhmFC8l10fVs2Ehwfxb E5gsTegkCr7xWJOxKho8nxpRMGseEuA22a/IaMZ4su9pMmMs1VBzMDLdFppiIgqqSsqqDEEj 43kfq4KbFMlHKYJphcZDhlS5eSCUUQFBo6yiY2FtOf/Y50HHBZOJyJWDBQ8E3Ew3sL05slNl stIsdwocGmmoJsLxlEFmFsmxODixZp5/NhgCKmy83CZ2pKpmswUFkiy2imWnbMU6ppZOoI77 HaDPi4khkQDKNOGMZrxDskWvmRgqnUwnCHOqRGk7sMHmhQSLCcJOAv7VFVNHehucNh0XmZiY iNW458us4w6Za1EgYwNOBBFa4KSVAxRoV3qx80uhOFr7JgDgpGDzzYmB2N9uYHZmU90IRTqw AkrJJ3dNGZMiIZgmCYlixQwNEiaHAo378ujTYrhcLBbtEazU/SgrA4R0RkSeuDUBkfWfG0cI Z7aTPkpugEvRuKMPYXeaGnUwD3ThE4EDqQDUAfPZjJOCGd0H+5BMQ2BJrwMKoo3TOcLrReFE c+MAa7idZXixwPY0oI8hB5qGNnIYIY5jIO/SJg4QIHIxzJB1ghFpA2WDWIGh5IfD1YMDl0ZA MYMLFklDMXO/id1pAMkdB3Hf+ZBYisgMjBUIgLICwFBVBEIkRGKjJIgokSEEICxRBkgZ9JZI GSJ2GIpjLByDIA9CDt02Ghq73FFsUONWW+xddpsw7fhpxYDhA2IaB4C32gQcBNItIb08MhMS wN+8xMHvJ3fD07+32mDbFFN3i+NZ2eFrv1VPvnrD0vuHi27W8grL/EdjLdWzTh9IfPUV7n+7 auMcogjOvFSU/jxMtz2VwuDkPHdq7QEihhHSuR9qaYgwpxF9o0eXfBW3xVijOftmNKjnJog6 5OO9ZO7LlaT9btTRxEklBrZFZqHbsAnyepdbrHFVtqtEWWshaKrQSLDEREIhsEHKooWVSlm7 mwkOZGcDpzet8WxQSmeDg7NyaJbSMy5FhllWYIDRbIgSaCc7RnvK51t9F+bZQlomDWggwtNy PY7Y3BPF0EUJmrYdHNBozpZzlymQ19SQItk4kLgfOQztyqkGsXT9BgbGi5dlw0kEtiECwwoO fXrK5D6Zx5aUTpDcdGbrohvZqxVcZypbz33CZRjro50Q0O1ltwJtoa0yBbSMHmo8OeQLaH9c QcbrrkOuAi3GR5j+N8nBJlMxnLsocMFOsOSm8/Vz0RjWexLJdSUQB0LxgwLh4ceXaJ8u3mS1 eUX5DnfMyZbTHKmITQpWB0ZvRoXIa05QDAc4jg6xypF1aLLbfZWjd7Eo1BsTRTOECRW2yxIZ EM6wLGqjRmSJhkvG4DUZVjwO3jhw1nhcHCoPJG7zhxOJDJP2Tme54rcTQyoduDxmdUdkQRJo 5L5cEK3EtIMu2NNRHfi4yYEOc9ruh9LbqDwaFTJ4lCjMGKOOF2UM9nlnJ0LtwZObKZtgJFIV KDwy1xERzAQWusHOxoYMkDnoa3rNWK3YMbbFs1+dd9UyQVL0jvkchVhW1DvFFRIvCH1LwHcm DVP53ws85Eh+TRBwuDgy43Fts5IupOM4jeGDtzh64T8Zwa8cVh6yMtzuZzrcqaY9NDLdqlqz RtwkJIORB4ehdLIu/YRBMzmcboJbHnCzyKy5N4VIY3eZlOREXavB6eWhqQV2OR158sDyUc2S ILEf7d8MktDp0xlfRQyLqaVqdEoLkcsKmGG2DUAaxtYgP64Ibot3ZA3FUWAg6j9kNbq7vENn 6i/AHaBUA/msH57nmHCkMCIm8+c1Hn3TmPRVyNk0JsT81K0H66M5NRoY9pYetrDKICGQjSV+ IvJ0vZbePKeF9LXyod34moYt40fufNsNmamBHI+87sk/AKY5NGtFwE31UmPPrnfbr8EmqOBN zg4p66HyYOe1fWudNzilRrgfPT4uxPk2PSB6B3h3eeVQ9zfjs0m6yYdoWQt2OJKJOwtK4y7b NcwZnjiMcz0WVycvwclRCOuB/HZuSewOzPixvpaYA9eoZCQ6moTAOVjSFWgfolmLJ1Lqdo8I HH97ADQHDoo8oeMZEtBFai7LOa801My9KWws8iKXOERLk+DPoX4WfWTv59IobW+QGw4Al+NC dy2Lp5XHCHU5GPcF17OJc15cQIZHBfFL5DOC+w/HRGqfycSXBLVHI1PHlJPUBxF2Pn7HiDUH oEp/UIvAzze2eoxJBsTXBcInDgifLeHAhiG46HYOPBq01mDiYTOF4LtiXgZkVJGi1vkBN4nF hRGHxO3a8/h59kPqigwYg9AcySYr5vrgO4qIXaWoGrO/IPzbWQOKnUucA8gimw9gvabmeM/J HT7GTEnKrNCWmBSsULFggFIcA6eWgamhi4mWU0sLkEBOQkrFciSCw33ND2CptDEyO8SQNrMS JssrYm4A1BMY2jECDFNhRXGCHTA7jafR3iCCHdvxJqhJjpFCoR9awd3V+zxOG0Znz+ocJpxz vmAIPYNdNNIoXbqzSaWdzYUagyUyjOOWtwhNBEXIhEIiuuTmm5Rlm57suF1ouvDZvSbvP8Tu 2Iqqw0CDLC1DSkoIJQZO4NYmIhvgmpgbcyt6UCFAZsoZVfJi/0mAYGAxIHgxgx712ncBwE7j XToWX1H5o+z1lXPmiQ+sqHoKdDgPZNd467KGMsFBfqkxeQNL76qgl0FIPm8QOkmITHBbKbOc 6HgrCUHeRAZRHEFZL3HGIoGM2YV3ninBHynZ5Y5vbYSr9ZJv0A7qO/xFz26x0QENjmG7kefG /lmsYKgS+yBkeQMkAx0yG+J74WT2JDs+m0EyiplKF9cnzQwNCkAhwIfOGuV99VvKra6C8y4X Q0swsEO6ezqVaKi/ryq4WGjE41DQbdmlLIqWxYJqy++g6wLWuVIjxsp5OjJZQi8NyCKDSx5o YpAP0oSHIyRLMTBgFRF2B+XcWR2CXJluADPgHpUs+nNRN+RlqESwbC/dBDMYgmOEHKFQGgyE iXQxiqw9PAvDATmKZZI6AbAOB6y40aJ8JR5IJdFLgO0M7A9o3V0OkFTMcAGHP5qcbe+3mtV1 NsEKU0O1OPQ7XiFQ6eik9EQvKZV7WEwCKilQSGQRhHAkGQwWFsdgGRP7bDWSUqmfXxmkVGJq 0VxKjMQpKyMpFlL2uRGYkUQRNMuJeOmY6QtsEQS0R6JRxSxllqUpREtYiziWSxMlgsWWZT1k yQh+oMJrgbGMlRBoYMdctqMJZ6nz0YYgppA0MYmSIHYoSIbqpM6OpOR1AhGBKUoC8eULofiK ocDMTvR0BgFmQgMSEYECIsQk9CCQR6GQebiObAkMI8lpBIhxCghZ5OeAmALeKZrO4aOMETfE PykKdqABKUIjPNCxHwLo+dkgxJKUFBlhHLD9D9GSUvuLJ8k0DGDWZbUjO7h3LkTD0CWp+Lmu YCWF3ayUCBjtXRxMjzYjbxoOpFMEFzZRjakhBn0SAcYkFxV4kGVkDSoOZzQRLehnrISB3+AE FyMDzlFEQkO/VNsSDt4J5toHMHbFAkR7TcbeIYuHWbzQokgU5mmhge9AmCzpZCaYGMKgCM4S ECjIqsQiFpWWZkwwGTR4sJDJGttoiGubZHEZFIglCu/fz5mjHdhgzbepqRU/FiKHPmmsZ6up 0FDk3tOTmbgcETw6iiedBFO4ZCcykmw5DB6aCIyIiMQ2QN6KhAURg7HOCahkN519/k4yQ3M7 gTWNIG4eKUfZBPRI7hOWKikivXvaKFiNhbGLVXOTzeufeIE+SNCBk2C0ZInCrPB0mFFinDjh UuYZgmJYVrFgW5QVwhcEUXKiZXGM6iM401oICIZAMJkCcyPGE4M43hM4llIYyxjRIRIQNCxg HebilLFOA+yh+XBoIIygguIczshYGB1kj+bc7JzMSgtH1wTzmBcH2kfsjUUMkHsnI7N2hD66 a31jIFHGCC+76qdD7QuR0gbFyrBO8JkGBEu6c9RDZA/WxPbCySVgshJVIkrJQZKwDGxkAURg GIKFSBGNIIwCMg0EghB78e/qvLP6dCwXkL3Qj2w/Jz2oB1iRitzNO2Q7pSxk4SoWoLtJKpao UQKHRRBkRAMGEoi/bgKE3wOwuAU6ezQuhk5BDFCKaEISESDBREFEFVEBiICwWH2cHrPVHalu 4Ls1sFBkYkNE5lG1SEsLidqmJUv6IELmyh/I4pycwsnqdHxEiJEZoD5yBinnMQsFlHQg8SwB 2CQmA+qBzYLuaf87hnkdTFj6oOG1rFmyrfxOrwhZnuPCGXMUMFT5kNZo+G4bdCJG6X9PzGdT M2NT2HqfPtR4ykPlaskfYYPVxHPA4xBjBdhwaBMm7JvbTQAuWFy/vnRCB6fOFD0ZAfKBD3jm /UzhT0PKYBaxoZssBtgwJqJ9qDyCHgVRGhmM9CkWntbWvyE104hSLVObRDrvYO5jhgQniUvH eamMoop4ymCJqPcpIEU+yTv/D9nsk0wRkmMrbTFYV+lIUdOJiYgG0xhoZLaC1IJWirColq1l YsgsCpRk1/juJre96k2Lt5nSB9j01Mtiw+7hZ8+YUKEJeCaFsoBpFL+JRB+ZMD8iDaFbBfAQ 0h2A/GzcOSS8EowQPfENy2gh2bUUuC+1pPCi2KVzPUrxdzw3ExYqU0REJVfgcSUywcXiQjB4 QXXECARDtaAFY3DK5u9Jc1Dy8n7ajSzRdma8NyY7kYsTHAkWtkYkS2YEA6iabrkGSYuglF0i XFwvPzedtiRCcUOkOm2ejvsNU2yjvflygEWkBynX5eC6tHyaTYBGCUYgF0NojXl3fBs2SekP uWDQGi2qF3xHeJ7hP2d+8+loKQ4Q0wwyw3GBiG1Q70HsC9JR+JjlpcwQL6U6kuHngTa0PCnQ 68ZXbzQBQO4QqwfcIdWaEdFl7e0hQx/y3USwwGxBsAwlKaG88jtMkbApBx2WZwCjWk9EIENr 6pl7WKOzaek50+o1MHbC4BcQJZPzbYu8r9lrIqMhaPNZI4g3USkLdxRyYi87nmQnXvlW7aMY Hl6IcOgNLAozTA9vjt+wStMr9h0yZg3sfnc+5/LPv97Rxt3Nn3LZ9XLRTcHU4EEaJfxxn3qW l8mdZ5qr+yJYGLMQ7nAXntRvyw6nnTB3Y5crW8z3LS/F3CtF189vcMqw1uPOHck1wEEMMPA9 /moIeX2142873vYZhh6z5kW3RGrQXUQfSMsECO6KEGIHFWwfVY+PIouBpET6oWgFodJDVM+O qrGJkSdyEQk7JvjBZQpshoIpQOGE/YxTC0JyfI45B6sh8RgVFeBDKMhkMYEWxO3Jw8lLlDj5 XRGBBFgIyKCyRSLBiCigiACQkzM4dAZmFGB8cky10loQcgILLHLFI98GrDrSsPoaOk+vO9Yh jlKMXfiyFAMwXcwdZSOiMXaORcPiw3c8eZYnQUocOLr4EmBpBYPahUFByShUEItMPuQbJI0o FLQTI0uBmh2GPCogZEoM1D90DPIlzP599vbCnIjkFk+4G/sXDQPTOpiuQ9l0m3A8F+A8Deak Asj6WoFifOQ+/5n0nmagS+idmCgIiMkRFBBIIgrFiKoIEQWCwgokFjIkEkiJGIQJHpR+fW0T 1T4QNx8Pa07AU010hDGnj5tjYuJiaHOBIRIm8iHxCzVM7nUp+6Gnu2E2VNxd3XpiQgSKQkBT 1PY51kZ62X70oCd81gFBxEqWVAk7ijDqBkRUyud9naESwF8zdwC5tTXVDpHz5P1UoL0IemXC hRF70RkMLjDJMbG1ZHVS6Y9keGYqWSxiXLi6YNtRJUIbSgDYEFSx5b5/Cu8kPom9sc4G4ieu E7Ha+WPwwwSYw8E0hd02xkwLRlZDZug5ZDR0ArFhoShDUE5PqftwAdziMhlFojYyg4+YA2GJ kr3OA5hkqDMttjRIDkpHFgVHGBaDeI6YU0wkBfJRYsUsu4JlfhL2jwrCxKbFvIbC++Jt0MjD 0GFqTGRF6WVBYDIsYIstLNgygIZWmZrCibOTZhwtkjMdgkBMxlbIHo87RuG/1wlrGQTvSzOc SySjo21Zm/Ls8qX4EVRRqWyxgjsaxbTNsqxv2+3LN1NAdowdvTSB4KK9A44HU/pIURTE7+FP oA24NCSjcxDlgl9u5ewxJmLRVIKwnkymUTyk0bTeAbGuJ8mpiIPcPcmIia0UxLNeneppmtli M08Yc5qmZIjVVEdlSzZuBDpONUSUMODbilsQXSNhftyzIGw7Uoqpegs1yPhkcQ1kQyYSO9cE gq0qADiJa1LX2QJLsRI2SCDTrKxLGdAvj91/DJR9uqZHItjK9lnlJn2xpSknXCq1tqWvdTYs kd/eWPM87HEO0nm7Ks0d4ubLOM4o+83UsK4YAwggVD1JMgFHQ6ErmM8uqquEMPqHXcHXrR1w CMFhuTt4TDQc0o/C0Set+U2HfIyiefTMFDGD5yzCKxWMGDP3ocaskvp4mY2DwgjHsG84ZFES AVYowhuJBGT0XzPSM/Zyulw3NA9lKFw7BlC6jDsa+tPL1+g/XI56R1Y9fvMm7QgpIfkfcYEC h3QCMydc7ecsclwwD4fdMQOjSPVV9A9qYGTho1WOARsbKS0m0DfmUhgHebwPKOYSR1HJpsnm lyqoYhcRMDBgeZ2jEIF1oyQgrbgCYjGGrRTVyzPYf0ykY4y4bHGipv6KJJRFwziaHe/reBok vyo8xWYyTFPMCx+ISI1nRDaPdn83MjI5yV8rFOfn9VCHS7/jguZMzooZfoRqMT890q+yGwoB x2MhUx9MagcJSSh039iSdHwvy70b3uApcFcwDEFXwSd+7py9jO73eyvClsjIbyp6Euxy1Ia1 jh6AWlOPTceCNmiWorcW+F64OZ+fEy70mi4HX1KixHAvPmTnk4JHYJRYQO84mBWamRCU5B/g XHRWAd7hH0JYPjhb0UVFh97wt2EPNGmmHTTpYw0jbQgUMGAxs7wZOcRtQWqIbCRLwYqRUO3t KUZSGUow6pHmikBrFcvoCdpEuRu2Jh7TGdDiBp2+RaglJBgQhCQJAaQSKm7Q2kebgY3Lh3P0 /WE8UF7rYNRiUTUslPsGjEZ3yKabMVLC7EW7e56OaYoWDGE6VVV1nncZSJumVqJ5llUdFLbf aKvGg2hw9IGwo2qQMvNT4dSYuMG/uNKPJMk2e+BZqElRIBRBpgSmiUleC4bjfse1AxXYYoeX b4DQWLAfiKmpFouRYKwE5m9iuQYDRDYiPBGYRAr3cIDEqhcP1sosR4AsYjSaO+4mZsV2u3hS dqHwQknh9Zt27j+/2FVfkO4NxH2FBBpan0TcTf6vVZMSZj18lfMDQ8zQ6ZgrhHG833dNSkls XRD3MLCGHtTMG5JHqQGkDpl2S1URttfIZGVCUWQJIbA2lLTJcGMEIwchQMuA4EHkADjU2ond SgCw6sMYciFdwT48dCT+25usnLscME08YFCrq63u73gs2RBzKUjMHetGge1CrN0ujeVbqYTW qURmw0bNTYmxgLGaKMq7Mlj9ZqWMN6mUy5RFOBOmrpbTeFlsN9Kb0WUZmFMZm9anc4IbA0ph hIx4sugYWf6pI/N/TruUTSTgDY/aOZP5GYhpltLA8fLAzEok4BpxhZ+H9HbhEN8vgiwxnIyh BxUSplKylHpaqsQY5a1GwStKM08upCCIdyBwkLxJRhmMuNBWcBWMRIvVuhcLgHJA2jAv3pSC DTnchugfPxF7zbydcDBE0kb4CxUd2ohCJrcpjrVpuxMFC0QoBDIGpNsHxTODWgbYFrOUoaZx lOLRERGQMThkxjNXbBODRkGbpRIbYUc2WcCaYa1l1oDWoZE2PVOIkLmVzIMHCEJZEJAdPMUK YaYEzXtQSyDsgOChG4BFtLEXGkKsF0UgRhAEERiAwQWcMhYysp0PqACl9JzomdFGCucCsYkD JxKcJAcX6FjwcjubJZHzg0qNQOYoRIkEH3ChrA96WSy/qIh7IpiLL+9stn9NFeUpvj706Dmo ncdbIhYZIMSDBWRGQBYMQYyChJGRgAxigsGFItJDopT2w6GBcul+xIRxccCWO98jMyQzZoMF /nR4mxV2gHAFxCiqEiMAIigpKcnibhh8MaiSIRSO+HvIaRd9ZBbaBFsQ9ceZF5QBMRgdTET7 g2fwU5FBSVw5pIDa5AIX7oXOy4gWgHRLnXUciR0KIwGKhlDpWtQA2I4btft35YyG84XohksW BMkcsOjCTTFAUFJu/sZgLGCGDQRRURRptlyIrGMTiSyizdXQwMBEqxLjQQkEqIrJRBNGyBkD K7jgJTvoEUAUbYBvsduNMmwaKcyFgNneB2Nv0ELrg4rFlQR9sQdpaoSiAFA58/5yMKgaZbQk SrTBIYgIbs7jv7n3JO68nLlFlEN2pTM9pQ0qn70l+NDXWgHgwowPvQP2NUMQX+jOhahtBaMI ymBlUAveTKOieEXEskmNoJ/pOwT8mtwhueCSCkwURKBywVBkRsolMEpg0LgHayXhvNEcyTc1 KOuxTd2UilGOaFyBeIzBYeLIaXsGXKDEfIpRrIZYYvR6LVCuFD7YUFJkSPqyAfx/cdbGv4bF Leex6ISZSQ1SykUCEBYk2jq7kjnt3wpvRbBHluUzooMpE2C6AbU8ICEgqxIxEMwhVzc+ProL p4kE1V4v6iIJsNx1sbjUwQ+hF7p8Hv3Zbvvqb+2zsO3yKHcEcATiNlwecykiH3KOyyhsdoHm HwMrro74OsKhGBF9MR3faYm1BIWlygcWJ88ZGBDPeeckGPAp88FGzObTS2IpUTZEpimFUKTz aTVNDhJjQe4hmE8hCbFXCmdg/vL0lwOi9P+ACrWGCVGCYCUSNOG8xHyFGkiMSnhbY3NwDoH2 RWxkiGALgEjEcwzu4QVxgkxfLwTpgo2jSyxEckcEXLF71fpF1ximBh0fG1n7d48Nopk+Yw1y AxLJiF2G2KHUl8/u8zzBkuu6YRkkHE8BxBQRR/khlH9/+GIsvsaHFGz3GfYb8OacoI+sqGFF BIGdSI/qKLMi9Qsu2A/GnDIa+9LPcaqJg/pjLMrSwOjSNHoyyTxovozSJglF9p/dmpYbYzuR kfVC5LlUYd+J+Tc+A8yUeRgeoPmQ1OgblpIalzF9b2HcD0g0QaJUHCOYDicoPWJ6jp4FVRt3 Y6H7dHV5xF25bYryihCC1CKWAxGz86TQOJpYIEIszIMUDarSHuoeWsnOFQplBFot/Lo0TpLu 4it12iYQeghE+g80Ibh+O9ybIGqR3lqfDqjAghqEDBMT4IZlnkILhiMNkSF8fX0PinRBfoNp M+eERmMUU1Rd9wbHHx6slIl3Y1NTFRMUiKWNqwNk9+8Jomw7aBkKYwdl3ePA8um7w+21qsZo zL6x34/neZvdkqa5bzUnPvNd+muvTtxT6y2G7BBPI35sjzegV0sBUdLrPMMmMR+MnrHarxMR BYPGkVB5QUOOObZwkbAfz9vH6BzCtNLb+o4qe46y5LEyeMUzY6XbDK9BRdip1IbIL+BRw1zV 0bxrk3CBAtAhmQZNkkOm0LTTGFBNsIolqR6+rAHNQxUA0TZjkyAG6Kq3gjlQGvkdOO6VVUdl otttLZNh6ZSeua4KWjuWMJISQu6AcExSGss05GyB9crHVXqnlTHmXAanT5hyFXmLg9DkyyCQ cwQONhaClpAkYQgDqxaooSETg2piAMhyaymFYiKj/aZAwMQzQYE5KjosMKnYGSUh0vsOJcdR UVVAp0mGId4NGBTVJ0QY04hsgZBN0ISkWM0iqrRrutbbalvTzkPDmiwikiu5aM9C5zD2nzNn G7VD9YacLj7YLhy4W48mbngK2DAl4SESOFUQYBkiFhhMDz8L0nkHY7E6H2zSMEQRVGM21Yqh 4yfH6SGwEDeu+Tt72cHDHz2eCXLBTL6QLqmDGL9+EUa7duNHQ/oHBDB8Dm04QkINsYNB+k6H EKDVaGy0Po27/CKzP7HjXv4GXSyZ0192woLtOBy6i66h2KNkU2ZVtTC/apn0MUc2EQSKeRc8 Ha2gQLw8TosIOMmW5Mj3gE2F8HYKYb6Q5fjLdIOTr011feew9ba5tuac2FpTe3YVQ7Agf2G9 Dgh6Ik0J3gqUcL0UvvBdtu7gOM7T0XUt5UU3QHYG5oyL/TJCy43pNKqTz/VQrjDmaYjZYgaB Fr3nmhs48i+Eh5ogqSMnPSBzDU1IhOgHHeka6d6Is+A4VLBxKiVJJPsGB0/kKG49YHQ3Plwj 3DUWKsYkgkQRUVVVEROpBNycyBkmhXzDLnNBqlRIyuP6eVgbRk7jH9MnGZjTGl4GpTBn67CL 4qltYRYPRm2RZkMbDhPfEOHYMgysh0+0xM0B7CIj8iiAhfNY4hfc2OtEQYX2ZkLMDwMh9WQX eQWJxZlJMmSsQSoFvishq6LpL7c0YaUmHtcTDR10YnGykwSJvO2VYNFKGpkogxCllMLU0IFR dWFUBlClQWWlgtlAUqn+7asYMYxiiMSIJspWIoolbQ2WGRRFIiKgoOFJvBC0taNC0SmMuDWM sqeeZPRqzKLKk4TrMl9dLJsVkREYdBMtWNwyS1oIMjEWJ0GBRMKeJh+AxRRTAnWFRYoLBSgS ecCDJjMQK1DnlpNI8iFA9FmQ4NQMIXEopth3v2CbNl4CJnPP0DoUie0LH8RA5mGw6ER7F/5w 1IfjD7TaCz+g+gbGCbDIa6lrkTmXD3c+iCG+GGYhYzv5w2J7hCGHkRDOIQkgqid9C9UxLpDV wzB0IlmKkKOjWtEgzCmg1mTQomvsC6s0SaIacvaMobGSpJawTfVrTqi4zAw756/UGn2s9gL1 iCB0WITE4/h4LALhfcMJiAmg7GZlKANNnE7WkUeNoAzToXDEOushYIMuPAcoBxblWsQGCteT sdLOA/IINpYWXORC+vkrVBwKEk/l1MQPUQfXIHurJE4+HFLg7k62bbYtC+YRo+4Qtx2WD2AP A5Ng6dkaNsTlFf7EEwfdPfH3w+hItRcZCWhSQEvCk2oGkaQTd4A8VD4cA4IBjcgQjSniC/NO YWglUMxO9HGIDejuQLmPeWIFkcCPwcE8i18Q72niNkoga0Gu1DA8tLdlQnAlIegPx9HmfnWS I7DzgMSSIySKCByUqHjvOE+18suIl0fcBwCdkQMSFg5L6UCzwOgnpOhht6oORtlKEJpoCHoL q20TsfgXTfFkiQ9QnUoKJHuoS+g1i5MYRYnfHDZ3UhIWMTBIFbL9z2olrXGCn64gWYgQj1MU oNxDUSBhmiCDJPs6iYcB0ZEcTlMS2NOfJqxiJXqJ+0Y3aT8rS31agf6SEtRkjLSNF+gQeAIE DR/TeETrDPnDFlMJiWmkx6TffJWmPhlZhlQBxz7Q2QhiU1OwQAPdPxQNlxzsIsQZZg6AZAVc otMNyXzsl6FBGM+mw1qk0wWCkKtMda+kT9P4/GJiMCIR5X8JNVjJn4R/CNL3dkqi9Ytld4ma ihzjaj6EMw6GaQgYNb42Ub/CwkRzlCBo6csccenLa1Nu8RH1y6z4mTxi4Y7jnE92USQiq7p8 AUTxPDPttgzgzQ1OhYJS+Wdig7mXdMY3DtV1ZjDQIUEiHMMdhavybCf7ETT37unK0O3lOi9I dU1yhmoXikwecK5XPCV6tOcQQPVEDQqxz6bakUOyRg8T2CSkY/i5JPEmItVoRD80+D9LtFMY FlDZTAVl3KTS8HgmF+zMdajwyafpOD0JbkVGHaUkNEDjpK67Co4pPHOxvGjHIjJTUZgQLsU4 ktZcpJMGGTe/EqpYgTfejvIPLJhAI7r6STmOC+IM7lUPIYiIB07VEBFe3l3pvFvrPPgmUk3z 3fDzaGmgxc88TluoGRZXiM0b6rhfcnbhzSntmTsRdzkNs4XzINhlPoJpj1mxmXxpJ3kZPKir Jw57rqtk2hMUU7o5INuKoY6pULS+OBlyOYoYo6tvhZpnClKh4wxbGUwWLFx7bxHRDD1JCPuQ InzdghGIb7bC5YJF5AfUYy2T3OOdU44NGpQhOI7HM2bdkbxrMt6XLgqcQkIi4moGRRTJnFDA RZ3NK6BRkqXMZmHeSJo+cJdFgsuDIiNb5j0eHE7zQxoLKlsMGJAExwUPkjwER30gyDLa7EDw K/A3JluLNL8cDhn+C5Owk0j92BQxjqiGyKWhy76W32a1hMfgLkjgtbm7jwW/hbuS2Z7vjEEa VUejsxHT9tFqRhYsGBthPUpQw6KEuClXUSdFYOJ8fUNSB4KdBsjOu0ZF2RqHW4aRjY+1Sypk yEMYpRGQ9DCjD7hLBQZygfBDIJRIU6B4w2f3zUOuk6jw+bn19Ob9rTFEWKUotbIwMLhSnITZ x5CEzdrISakQhBoYkg5HAowwhQbeBSdQiZi5huxALiFuevEwWmBbx8QbUQMHcEDc1pa4S6CM 6XvwohhZMks0WF1ONdhP0KVjZFCg+Rg0+mAbq9X4brci+gh+OJYjwEO0K29gaASxuIHXnyUe xiU3M3sRoiQgEiEoJJWFlPkCsBGeED6jDA+vVOAeKV9sLDwBTSFIFYRIm/yTDO1pJp5oQwEe dx2KamqUGMVdaNfAtRWIa/svHNBjuNYDizFn+L0HBxvtqzVx801nZLYO4Z7C7hI0xGth5Il4 CXPRw397oieW1e6JRWyzUFjFGKMyINo+JhTA1bJMg1U80yEBQhAQNPFpiT81emBT0TA6IWoJ 3ZcNDW9Qw4MqBQXIQTbSSxSJphwjVPVxrg0cppxlkyakRG0CzU1owJpKJxTQVm0narHk7DgH iCTVP5rDcX0kNTxJQnzDNBuRZ2SB+1FDoMLbJVqJ3cMAXruMN5vH7hOMIWg3cqFsATyWQ3v9 1MZOnY34mihsPvpvJfpBR8vLIYii8e9RlplUEz4FM/2Ka2G9xkRMps0VAdb55utxEpGiFY/6 +ChjUujnoGwdzcSu0rkYxKlwQuWjFgmlYFmiSJSEbIrBYtZ1Zb2JcltvBqB4+Vw9XMUDqMPI DQ+QXG0DBg0fYCwTzQZBuiaodo9+CckwcNiUr5UfIQYQYQFQfMPxGFJ/u9BCIBrzPfzy6c+c oHKpNU10yL0ru6GxqIGIhAZIduXXpnm8u/6K1p2DiFuGpHFtUuRIjhxpHnh44obBgafdMEMb lznL/KiWhyTo5lssgy2k1HGTsXs2bNXM2ROQxRQWDu1S98HGMUb6zmm1uTJbHKyhk87/YdtF WbkjNEkpG++KxrBDY7ZDASyZKSD9nqwJ2eNaMtzuSApyIwrdNllTdQYrprHNcmZ3ZY07Oswo OctnJ2waqX66kbNF3BcmV3o3oZNpll4ZmzGicUwBaYFB2gGeNEMNpDQYCENablNM2KCNMdcQ PbDtsFBhdyyOiZjXLMGTbsGqdtGjjCsH8LIsmnO85EULBRIhFujLtNON3rrk1ixRf2v1ejHC TIeKO4hu+pNkhZnIs9W/XlrTFJgHNNGrkgc0Wzdu94UhvI4wybUEoECDiXIQKHSHEbpwvynA mEQBp7NOFrXafI4KEofhyNhjx2JJbtmmE2TnxBEY7ro2RvLnOjGAUydbMGdYlU1gx4Q1no51 oRCcdL6qnI/Zac8wj8OXK8A6Fwpw9DUTMP9UZJ3tNkhZQd0SYeVDjRB7KW4GYnvvvdM7Jqaq k8cS1jkmMCHPIQiTuxfsW2JqERoRME8PfAd0198nWGB2AE0hH1a7ycIuUkjMd1Ddn4SvI47N mJq9M1MGLEFcyK4B1gGwUBQEwSLgZncQEHHGRRi0WM4bTmZdx0Z2lay0p4ncTMvDx2e/a+Iz BwRpvItgc5ZOYap7iEXI44GJvDSrl8V50Z4XUoYBIhA1OA7wsJnzSwoYhek2bW264FJGmDrn DcBQG5NMclrIeEfEsZrZiGDRrjjYbNMk0Npmo5uwbmWyYE1ZJuQ7CAEYwqgYBpBD4n2kIpGt BJry0tYnra+8bkjMvkMFI7g1yOBAFxGAJTAESwGp1iPX2Qqu+z3nPg6AtzT1IaQh43q25OAM hDwTAxMlCcDr7AU0BhUmgwfyXHICi7ZdtORHBpe9Hem4bbC5Jioo4Fg60whQ1+OtScu4bdIW 5wOm5WBiWhpB/5OmOv15/RPg6sfi+ig0YM22owNPM9QUUX5lIq8SMqiXMFnCmM2YpgzhRO4+ cPK54XPRL2oySPmPgAm6BiIxPOOp+nWWXFSajNUlVy40WKIiLCVL1pSJw9IWmKQ4ceUYhm0x ln+P4Czg+xvjealEfKphJCLTCg40Ib8abFiTsk8p4h4hzoHfzy4MFO+E/LVcSYwzXYokw74J QQOOW1dJDkKEinBqQuWMDBBgW26kyCiMGSeYUg5ZNBISMg5FDYC8iYY0J9Zx308zqZ/JsMlq SIxENM6DStujPueGtEmva9agTUZrjv94jiJuIiHuRCCGREQGQIRPbFB2RV3HGvXEDl0gc5RA MaBuBZ/QEoTNYYOF7AL18TAMCxSXPE2hCNJ8CETrOEZ2ZEkjEm03iJ4glZu9IGZsTLpWJo1m QK/B5b9H9T8LJc6V13Id5LloN2Z3cZc/KRaSQIKe2BISgogpPVq9pGaqJwSHYXi7OFq6Yxg7 Hc0ukd+M2MhIBGlAjZYkWjBQoc5c54mjWaOZmpmjmamppJUUojGSrUvbrJsp12xhxFgskZ2k oD2QrIzd7w67Eh6BMSKHBwHfYOQwg7CoaC7Lzjods2kfKvNYzDiUhvibUFJ9AyQ6iQpEYDBB CCgKKJFGR1ZCiQ0iwCv2jep1+JkNanccezadhR5ySyWdQNB96PYG0uvIxLATzvsVbPmueDvM hoaYUYXA215rGwL9ideB0XMgh6ltUXZZY6n4WcaJZhfuhrZ/h//P/3XSckXgpblB3mTHQkRm RETkuTTIFLIFBRdbX80s4F2BUVN5rqdqdFGHflfkI/m6f4Nw5ikVZEYntn5WfWzpNktm0MgQ ygY2AAFpIsgjAGmHzLdJ2yw+zQzZoPgTUEN0OjV0U1l4YWfBqDydmszK9DxFa+LmaDgukFQ1 xSgjJcd57jeZPLyQzT2XMtVT1jyLpxCiMfWGrwhMMN7ovsJUkbQaG/Aiuac2uhyzcM8+900E 3ZlSNPJEDKMjDhnOnETdQ7QxJ1Id9pYu/GJa9TBEbcwOk+ZrY9VUZIs4yN/OgRx8WWHd8dDi HoPDCBoQsvWEsXJuxEU2yCakzDQmCR7KkamkcA/JJISRE8uyTSUSrBk5IXKM3Y/hJ4R4R4WR 8YTF+0iO7ar8UUQgEAUISMF876QTZ2iY9hxKAIh+tg80w3yqqMPBPgM7u6huGoFnnNKVjybI BvRH3FyjmnTXcw6zv9a1dnTHXuL7gNT1EhCET0FeG9R5r2RhAIkTw9B2wj0lPx7fYB3J3ATG R5trCURqSysIcwOHBufbAMORo8ECxVz/YAD9vYbYpDgh0EroQ/CE/dD1pdlDX14gll+OUkhA r1kfsuDPOS97FgpFSCIlHzhMnkdIByHEoQ1HnEhDJNtVCIRMP54FIJ+mChm5p8Bq+yxsI7bj 5MnGgqSSdkV4eBQfF1P3jkHseoIkYe75AMDf1bEGeUpVlGgwoxoFGQBiEFQgJ5FkoCqSEg/f gPAimDKuWbXgjnwef4EEnMcvQV9Q4H6w1YmKqOJ1wvrgz4lLCqxKh8UHvaxyivSP1T6NsD5H ItyQQIEGT6BN+oQHoyAzRIWNTI4Plqa4dCB5QkqwFJGUXY4rHRZpDDERCVEHlG6MAUI9YFwo IOQCOKIg45iQuQswOqHPBmoYyd4JvkaseYcTkMhZ3sj2GlSCRKWAh6fMdJWtET8D9Is0VEpC b0OfOE289BycFRbXD2QG5RB6CJmYrQwJzjpl4EsgmOJ30GWD96J7ZsWXl73G/Z7g2Q8iwg7T sraJjIR19jeXC7AkzlMYxZFJuGWDaRIIfOD4jaw+WtTgOJhsmqZouZvN+l1mRlYGnDTL89A0 p5gHAHzwsIYmA7g0S6oGxxpoZEgm2B+Qh4kBPLysWTVCK5ldLCGibwOYFhXS4ph0EOZGoaJi EIJgEHirag+WOKYJ1M4O2w8HsFlfwesQPMN8JmA5wDtP0qpaMqKltg+kzqoVCFz+vgEU2IJf TCcKNSLASYFjEOtxLhGkoEyO31WDA2Q/RYWlYh6YowRVEWQ6AyDIdHy9d92cuA/C3TRiJEiz 6Eqm2fdC8h+kdHR7j4lNcdMFyLbxDmXgoQkWik2TJcDiNohHwceTJCggQogRZJDEObMMzstT ZNoSZzA7ElDosttwS1Ah1bkQt3DYGjk1LaEUYSEmYxmY2yEhKcS9kYindjBzZGjCdm6buOec 95jmb3fIEEA7EDgbdpwAdhpkokCAaiOw2tfhv5noBFVJ6sKNS5SFRYgvbADxii1P7YCUBA+w 9RQB/ogyDGQYKffpX6Q/YhY+goIEIH4nAQMowHrPxahGIRZDIKMO9stqwVDvyp/1U4P6LLEU 5jJzxA1hmtFwRBYKFmZZumgMP/i7kinChIH7x9Bo --9jxsPFA5p3P2qPhR-- --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA253uOfuToMruuMARAi+QAJwO4PDJu5IdaPWncVFEyHSkCQyS9gCdEqgq TkSkeXbgBD8OJP3J+2mZHX8= =Wrwt -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 03:51:13 2004 Return-Path: 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 3A0B216A4CE; Fri, 25 Jun 2004 03:51:13 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D23FB43D3F; Fri, 25 Jun 2004 03:51:12 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5P3p8kv027563; Thu, 24 Jun 2004 23:51:08 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5P3p8Y3027560; Thu, 24 Jun 2004 23:51:08 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 24 Jun 2004 23:51:08 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Xin LI In-Reply-To: <20040625033718.GA1691@frontfree.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@FreeBSD.org cc: hackers@FreeBSD.org Subject: Re: Preliminary sys/netinet style patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 03:51:13 -0000 On Fri, 25 Jun 2004, Xin LI wrote: > I have a patchset to remove tailing spaces, convert leading spaces to > tabs, and removes spaces before tabs. The patchset is generated with the > following shell command sequence: > > sed -i '' -E s/\ \ /\ /g *.c *.h > sed -i '' -E s/^\ \ \ \ \ \ \ \ /\ /g *.c *.h > sed -i '' -E s/\ \ \ \ \ \ \ \ \ /\ \ /g *.c *.h > sed -i '' -E s/\ +\$//g *.c *.h > > Because the patchset may cause many conflicit with developers working on > netinet/, is this valuable to apply the patchset right now? I think it would make sense to defer this until merging of the netperf, ipfw, and arp-related changes is completed. However, I'm happy to get these and related cleanups into the code just before 5.3. If a month passes and it hasn't happened, please ping me. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 10:49:54 2004 Return-Path: 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 84DCD16A4CE for ; Fri, 25 Jun 2004 10:49:54 +0000 (GMT) Received: from web13004.mail.yahoo.com (web13004.mail.yahoo.com [216.136.174.14]) by mx1.FreeBSD.org (Postfix) with SMTP id 6733843D49 for ; Fri, 25 Jun 2004 10:49:54 +0000 (GMT) (envelope-from rosey_kc@yahoo.com) Message-ID: <20040625104911.69479.qmail@web13004.mail.yahoo.com> Received: from [202.51.78.5] by web13004.mail.yahoo.com via HTTP; Fri, 25 Jun 2004 03:49:11 PDT Date: Fri, 25 Jun 2004 03:49:11 -0700 (PDT) From: kamal kc To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: newbie: ethernet, ip header proble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 10:49:54 -0000 Hi i am new to this mailing list. I have written a program to capture packets using pcap library routines. I have a FreeBSD 5.1. The problem I faced was I successfully captured packets and parsed to ethernet header and ip header. i present a section of code how i did it. -- char *ptr; ptr=pcap_next(.....); struct ether_header *eth; struct ip *ip; eth=(struct ether_header *)ptr; // datalink type DLT_EN10MB ptr+=14; // the size of the ether_header being 14 bytes; ip=(struct ip *)ptr; printf("\n %s %s", ether_ntoa(eth->ether_dhost), ether_ntoa(eth->ether_shost)); printf("\n %s %s", inet_ntoa(ip->ip_src), inet_ntoa(ip->ip_dst)); ---------------- Now the problem is that the ethernet destination and sender host is printed the same. it is equal to that of the sender MAC address(linux) when ICMP packets (by ping utility) is sent to the host(FreeBSD) running the program. Also that the ip adresses printed is the same as the sender ip address(ie linux). The program is run on host with FreeBSD. The ip address of the computers are: 192.168.1.10 has Linux 192.168.1.11 has FreeBSD I couldn't think of a solution as i guess the coding was alright. Anybody could help Kamal --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 11:40:33 2004 Return-Path: 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 1481116A4F9 for ; Fri, 25 Jun 2004 11:40:32 +0000 (GMT) Received: from hermes.xtec.es (hermes.xtec.es [193.145.88.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C2943D45 for ; Fri, 25 Jun 2004 11:40:28 +0000 (GMT) (envelope-from tonign@pie.xtec.es) Received: from gregal.xtec.es (gregal.xtec.es [193.145.88.16]) by hermes.xtec.es (8.12.10/8.12.10) with ESMTP id i5PB82uj012746 for ; Fri, 25 Jun 2004 13:08:02 +0200 (CEST) Received: from [213.176.162.47] (sis47.xtec.es [213.176.162.47]) (authenticated bits=0) by gregal.xtec.es (8.12.11/8.12.11) with ESMTP id i5PB8SpO008662 for ; Fri, 25 Jun 2004 13:08:29 +0200 (MEST) From: toni To: freebsd-net@freebsd.org Content-Type: text/plain Message-Id: <1088161693.25699.196.camel@sis47.xtec.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 25 Jun 2004 13:08:13 +0200 Content-Transfer-Encoding: 7bit X-XTECg-MailScanner-Information: X-XTECg-MailScanner: Found to be clean X-XTECg-MailScanner-SpamCheck: no es spam (whitelisted), SpamAssassin (puntuacio=-5, requerit 5, ORIGEN__XTEC2 -5.00) Subject: problems with arp kernel messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 11:40:33 -0000 hi, i have a problem in a server, from some time ago, the console shows this strange message (strange means i can't imagine what's its scope): arp: ***.***.161.65 moved from 00:50:0b:6c:a4:1a to 00:00:0c:07:ac:1f on fxp1 arp: ***.***.161.65 moved from 00:00:0c:07:ac:1f to 00:50:0b:6c:a4:1a on fxp1 the server IP address is ***.***.161.107 (netmask /25) and ***.***.161.65 is tha IP address of the gateway (a Cisco Catalyst 6500) it's doing so every 30 minutes, but varies, it can be one or two hours between MAC changes... this machine has not been updated from two months, it was working normally, IPv6 services are working (it routes packets between interfaces) but networking on the IPv4 address doesn't work (neither sshd nor pinging other hosts) any ideas??? thanks in advance, toni From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 12:02:19 2004 Return-Path: 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 B96A516A4CE for ; Fri, 25 Jun 2004 12:02:19 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF84943D5C for ; Fri, 25 Jun 2004 12:02:18 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i5PC7iiM076123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jun 2004 15:07:46 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i5PC1rvs037085; Fri, 25 Jun 2004 15:01:53 +0300 (EEST) (envelope-from ru) Date: Fri, 25 Jun 2004 15:01:53 +0300 From: Ruslan Ermilov To: kamal kc Message-ID: <20040625120153.GA37003@ip.net.ua> References: <20040625104911.69479.qmail@web13004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20040625104911.69479.qmail@web13004.mail.yahoo.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: newbie: ethernet, ip header proble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 12:02:19 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 25, 2004 at 03:49:11AM -0700, kamal kc wrote: > Hi i am new to this mailing list. > =20 > I have written a program to capture packets using pcap library routines. = I have a FreeBSD 5.1. The problem I faced was I successfully captured packe= ts and parsed to ethernet header and ip header. > =20 > i present a section of code how i did it. > =20 > -- > char *ptr; > ptr=3Dpcap_next(.....); > =20 > struct ether_header *eth; > struct ip *ip; > =20 > eth=3D(struct ether_header *)ptr; // datalink type DLT_EN10MB > ptr+=3D14; // the size of the ether_header being 14 bytes;=20 > =20 > ip=3D(struct ip *)ptr; > =20 > printf("\n %s %s", ether_ntoa(eth->ether_dhost), ether_ntoa(eth->ether_sh= ost)); > printf("\n %s %s", inet_ntoa(ip->ip_src), inet_ntoa(ip->ip_dst)); > =20 > ---------------- > =20 > Now the problem is that the ethernet destination and sender host is print= ed the same. > it is equal to that of the sender MAC address(linux) when ICMP packets (b= y ping utility) > is sent to the host(FreeBSD) running the program. > =20 > Also that the ip adresses printed is the same as the sender ip address(ie= linux). > =20 > The program is run on host with FreeBSD. > =20 > The ip address of the computers are:=20 > 192.168.1.10 has Linux > 192.168.1.11 has FreeBSD > =20 > I couldn't think of a solution as i guess the coding was alright. > =20 > Anybody could help > =20 Sure, carefully read the BUGS sections of both ether_ntoa(3) and inet_ntoa(= 3) manpages. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA3BQwqRfpzJluFF4RAnZkAKCbIdz5laNFp8EFa2xpJg8V12IccwCfcSiP Q7fXrsR7FYqnXQEc3dATXFY= =KkzS -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 12:32:57 2004 Return-Path: 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 9DCA516A4CF for ; Fri, 25 Jun 2004 12:32:57 +0000 (GMT) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 5377E43D4C for ; Fri, 25 Jun 2004 12:32:54 +0000 (GMT) (envelope-from murat@enderunix.org) Received: (qmail 61429 invoked by uid 1002); 25 Jun 2004 12:31:43 -0000 Date: Fri, 25 Jun 2004 15:31:43 +0300 From: Murat Balaban To: kamal kc Message-ID: <20040625123143.GA60543@enderunix.org> References: <20040625104911.69479.qmail@web13004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625104911.69479.qmail@web13004.mail.yahoo.com> cc: freebsd-net@freebsd.org Subject: Re: newbie: ethernet, ip header proble X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 12:32:57 -0000 On Fri, Jun 25, 2004 at 03:49:11AM -0700, kamal kc wrote: > Hi i am new to this mailing list. > > I have written a program to capture packets using pcap library routines. I have a FreeBSD 5.1. The problem I faced was I successfully captured packets and parsed to ethernet header and ip header. > > i present a section of code how i did it. > > -- > char *ptr; > ptr=pcap_next(.....); > > struct ether_header *eth; > struct ip *ip; > > eth=(struct ether_header *)ptr; // datalink type DLT_EN10MB > ptr+=14; // the size of the ether_header being 14 bytes; > > ip=(struct ip *)ptr; > > printf("\n %s %s", ether_ntoa(eth->ether_dhost), ether_ntoa(eth->ether_shost)); > printf("\n %s %s", inet_ntoa(ip->ip_src), inet_ntoa(ip->ip_dst)); > > ---------------- > > Now the problem is that the ethernet destination and sender host is printed the same. > it is equal to that of the sender MAC address(linux) when ICMP packets (by ping utility) > is sent to the host(FreeBSD) running the program. > > Also that the ip adresses printed is the same as the sender ip address(ie linux). > > The program is run on host with FreeBSD. > > The ip address of the computers are: > 192.168.1.10 has Linux > 192.168.1.11 has FreeBSD > > I couldn't think of a solution as i guess the coding was alright. ether_ntoa returns a pointer to a static buffer, which means you'll need to save the string returned by call to first ether_ntoa [ether_ntoa(eth->ether_dhost)] to a temporary space. Same thing applies to inet_ntoa. read the manual pages. From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 17:11:50 2004 Return-Path: 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 2DE7616A4CE for ; Fri, 25 Jun 2004 17:11:50 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838B943D1F for ; Fri, 25 Jun 2004 17:11:49 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 0F49315533; Fri, 25 Jun 2004 19:10:51 +0200 (CEST) Date: Fri, 25 Jun 2004 19:10:50 +0200 From: Andrea Campi To: net@freebsd.org Message-ID: <20040625171050.GA83855@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: PPPoE on Atheros in hostap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrea Campi List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 17:11:50 -0000 [please keep me Cc'd as I'm not currently subscribed] Hi, I'm setting up a firewall/access point based on -CURRENT. I'm trying to set things up so that wireless clients can access the internal network via PPPoE. I admit to being a novice in this area, but I could set it up quite nicely for clients coming in from one of the wired interfaces. However, the same client coming over the wireless interface doesn't work - it looks like pppoed doesn't even see a connection attempt. Compare this: gw0# /usr/libexec/pppoed -dF -P /var/run/pppoed.pid -a webcom.it -l default sis1 Sending NGM_LISTHOOKS to sis1: Got reply from id [3]: Type ether with 1 hooks Got [3]:orphans -> [17]:ethernet Sending PPPOE_LISTEN to .:pppoe-687, provider pppoed[687]: Listening Jun 25 16:56:01 gw0 pppoed[687]: Listening gw0# Jun 25 16:53:20 gw0 pppoed[669]: Got 60 bytes of data: ffffffffffff003065a8eefc88631109000000100101000001020000010300040240c00455 5555555555555555555555555555555555555555555555 Jun 25 16:53:20 gw0 pppoed[671]: Creating a new socket node Jun 25 16:53:20 gw0 pppoed[669]: Listening Jun 25 16:53:20 gw0 pppoed[671]: Sending CONNECT from .:exec-671 -> sis1:orphans.exec-671 Jun 25 16:53:20 gw0 pppoed[671]: Sending NGM_SOCK_CMD_NOLINGER to socket Jun 25 16:53:20 gw0 pppoed[671]: Offering to .:exec-671 as access concentrator webcom.it Jun 25 16:53:20 gw0 pppoed[671]: adding to .:exec-671 as offered service webcom.it ... to this: gw0# /usr/libexec/pppoed -dF -P /var/run/pppoed.pid -a webcom.it -l default ath0 Sending NGM_LISTHOOKS to ath0: Got reply from id [1]: Type ether with 1 hooks Got [1]:orphans -> [15]:ethernet Sending PPPOE_LISTEN to .:pppoe-683, provider pppoed[683]: Listening Jun 25 16:55:21 gw0 pppoed[683]: Listening [nothing happens] Then I started looking around the netgraph stuff: gw0# ngctl list There are 7 total nodes: Name: ngctl694 Type: socket ID: 00000025 Num hooks: 0 Name: Type: pppoe ID: 00000017 Num hooks: 1 Name: Type: pppoe ID: 00000015 Num hooks: 1 Name: sis2 Type: ether ID: 00000004 Num hooks: 0 Name: sis1 Type: ether ID: 00000003 Num hooks: 1 Name: sis0 Type: ether ID: 00000002 Num hooks: 0 Name: ath0 Type: ether ID: 00000001 Num hooks: 1 gw0# ngctl show ath0: Name: ath0 Type: ether ID: 00000001 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- orphans pppoe 00000015 ethernet gw0# ngctl show ath0:orphans Name: Type: pppoe ID: 00000015 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- ethernet ath0 ether 00000001 orphans gw0# ngctl show sis1: Name: sis1 Type: ether ID: 00000003 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- orphans pppoe 00000017 ethernet gw0# ngctl show sis1:orphans Name: Type: pppoe ID: 00000017 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- ethernet sis1 ether 00000003 orphans Uhm, looks ok to me. But then: gw0# nghook -a sis1: orphans 0000: ff ff ff ff ff ff 00 30 65 a8 ee fc 88 63 11 09 .......0e....c.. 0010: 00 00 00 10 01 01 00 00 01 02 00 00 01 03 00 04 ................ 0020: 02 17 b8 04 55 55 55 55 55 55 55 55 55 55 55 55 ....UUUUUUUUUUUU 0030: 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUU 0000: ff ff ff ff ff ff 00 30 65 a8 ee fc 88 63 11 09 .......0e....c.. 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 02 17 b8 04 ................ 0020: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU 0030: 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUU whereas for ath0: gw0# nghook -a ath0: orphans 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 09 ................ 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 01 81 98 04 ................ 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 09 ................ 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 01 81 98 04 ................ So, questions: am I doing anything wrong? Is this supposed to work? Is ath0 somehow mangling the data it sends to netgraph? I'd be willing to put some effort in this if it's something fixable, I just need pointers. Bye, Andrea -- To boldly go where I surely don't belong. From owner-freebsd-net@FreeBSD.ORG Fri Jun 25 18:01:00 2004 Return-Path: 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 6384916A4CE for ; Fri, 25 Jun 2004 18:01:00 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C50E43D53 for ; Fri, 25 Jun 2004 18:01:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040625180020016005rde0e>; Fri, 25 Jun 2004 18:00:20 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA01890; Fri, 25 Jun 2004 11:00:18 -0700 (PDT) Date: Fri, 25 Jun 2004 11:00:16 -0700 (PDT) From: Julian Elischer To: Andrea Campi In-Reply-To: <20040625171050.GA83855@webcom.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: PPPoE on Atheros in hostap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 18:01:00 -0000 On Fri, 25 Jun 2004, Andrea Campi wrote: > [please keep me Cc'd as I'm not currently subscribed] > > Hi, [...] > > > Uhm, looks ok to me. But then: > > gw0# nghook -a sis1: orphans > 0000: ff ff ff ff ff ff 00 30 65 a8 ee fc 88 63 11 09 .......0e....c.. > 0010: 00 00 00 10 01 01 00 00 01 02 00 00 01 03 00 04 ................ > 0020: 02 17 b8 04 55 55 55 55 55 55 55 55 55 55 55 55 ....UUUUUUUUUUUU > 0030: 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUU > > 0000: ff ff ff ff ff ff 00 30 65 a8 ee fc 88 63 11 09 .......0e....c.. > 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 02 17 b8 04 ................ > 0020: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU > 0030: 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUU > > whereas for ath0: > > gw0# nghook -a ath0: orphans > 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 09 ................ > 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 01 81 98 04 ................ > > 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 09 ................ > 0010: 00 00 00 0c 01 01 00 00 01 03 00 04 01 81 98 04 ................ > > > So, questions: am I doing anything wrong? Is this supposed to work? Is > ath0 somehow mangling the data it sends to netgraph? > I'd be willing to put some effort in this if it's something fixable, I > just need pointers. It looks like the atheros driver is not returning any ethernet header information. The MAC address is important for PPPoE. BTW. tcpdump is the best way to look at the transfer as it can decode the packets. From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 11:42:16 2004 Return-Path: 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 6440516A4CE for ; Sat, 26 Jun 2004 11:42:16 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1112843D41 for ; Sat, 26 Jun 2004 11:42:16 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 489A215534; Sat, 26 Jun 2004 13:41:57 +0200 (CEST) Date: Sat, 26 Jun 2004 13:41:57 +0200 From: Andrea Campi To: Julian Elischer Message-ID: <20040626114156.GA88328@webcom.it> References: <20040625171050.GA83855@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: PPPoE on Atheros in hostap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2004 11:42:16 -0000 [please keep me Cc'd as I'm not currently subscribed] On Fri, Jun 25, 2004 at 11:00:16AM -0700, Julian Elischer wrote: > > So, questions: am I doing anything wrong? Is this supposed to work? Is > > ath0 somehow mangling the data it sends to netgraph? > > I'd be willing to put some effort in this if it's something fixable, I > > just need pointers. > > It looks like the atheros driver is not returning > any ethernet header information. > > The MAC address is important for PPPoE. Any pointer on how to go about fixing it: what to look for, or even a driver to take as a model? I haven't had time yet to give the code more than a quick glance. From what I gathered looking around it seems someone is using PPPoE over at least wi, so this issue is probably in ath only, not in the generic 802.11 layer, right? > BTW. > tcpdump is the best way to look at the transfer as it can decode the > packets. Yes, and that was the first tool I used; however, I wanted to give the minimum amount of information sufficient to plainly see there IS some issue. Bye, Andrea -- I believe the technical term is "Oops!" From owner-freebsd-net@FreeBSD.ORG Sat Jun 26 21:58:32 2004 Return-Path: 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 D654E16A4CE for ; Sat, 26 Jun 2004 21:58:32 +0000 (GMT) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id 0119943D1D for ; Sat, 26 Jun 2004 21:58:32 +0000 (GMT) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004062414575705518 ; Thu, 24 Jun 2004 14:57:57 +0200 Received: from rocco (rocco.epita.fr [10.42.14.9]) by epita.fr id i5OD3CR01409 Thu, 24 Jun 2004 15:03:12 +0200 (CEST) Date: Thu, 24 Jun 2004 15:03:11 +0200 From: Jeremie Le Hen To: Bruno Afonso Message-ID: <20040624130311.GA13289@rocco.epita.fr> References: <40DA5A12.6080106@dequim.ist.utl.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40DA5A12.6080106@dequim.ist.utl.pt> User-Agent: Mutt/1.4i cc: spe@bsdfr.org cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPD problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2004 21:58:33 -0000 Hi, You may also want to look at CARP from OpenBSD. Check http://kerneltrap.org/node/view/1021 for more informations. Also, http://pf4freebsd.love2party.net/carp.html is a FreeBSD port of CARP, but the DNS entry does not seem to exist any longer Regards, -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!