From sacadmin Thu May 21 14:25:03 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4LLP3XO023852; Thu, 21 May 2009 14:25:03 -0700 (PDT) Received: (from carlsonj@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n4LLP3E5023844; Thu, 21 May 2009 14:25:03 -0700 (PDT) Date: Thu, 21 May 2009 14:25:03 -0700 (PDT) From: James Carlson Message-Id: <200905212125.n4LLP3E5023844@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Solaris PPP/PPPoE Updates [PSARC/2009/317 FastTrack] Status: RO Content-Length: 558 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Solaris PPP/PPPoE Updates 1.2. Name of Document Author/Supplier: Author: James Carlson 1.3 Date of This Document: 21 May, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Fri May 22 07:15:00 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MEF04O029768 for ; Fri, 22 May 2009 07:15:00 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MEExZ0008424 for ; Fri, 22 May 2009 10:14:59 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MEE1ts009894 for ; Fri, 22 May 2009 10:14:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MEE1wL009891; Fri, 22 May 2009 10:14:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18966.45865.82910.746790@gargle.gargle.HOWL> Date: Fri, 22 May 2009 10:14:01 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com Subject: 2009/317 Solaris PPP/PPPoE Updates X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2695 I'm sponsoring this fast-track request for myself. The timer is set to 05/29/2009. This project will add two minor features to Solaris PPP ("Vector" PSARC 2000/003) and PPPoE ("Vector PPPoE" PSARC 2000/485). All of the interfaces described are "Committed" and are being given "Patch/Micro" release binding, although no actual backport is expected at this time. The first feature allows PPP and PPPoE to be used inside exclusive IP stack non-global zones. Currently, the sppp and sppptun drivers use PRIV_SYS_NET_CONFIG for administrative access. This privilege, which encompasses many different low-level networking features, is intentionally excluded from non-global zones. PPP and PPPoE aren't necessarily IP features, so PRIV_SYS_IP_CONFIG (which is otherwise suitable) doesn't seem right for them. They're datalink layer features. But unlike the existing PRIV_SYS_DL_CONFIG, non-global zones *should* be able to use them by default. Thus, we will introduce a new PRIV_SYS_PPP_CONFIG. This is a subset of PRIV_SYS_NET_CONFIG, so processes holding that privilege can still use PPP and PPPoE administrative interfaces. The new privilege will be documented as: Allows a process to create and destroy PPP (sppp) interfaces. Allows a process to configure PPP tunnels (sppptun). The second feature in this project allows for interoperability with some peculiar PPPoE access devices that use Ethertype values other than those documented in RFC 2516. These devices appear to be popular in some non-US locations. (See CR 4695172 for details.) The additions for this feature are a new "-s" option for the sppptun(1M) command: sppptun plumb [-s ] [ ] This allows the user to specify a particular SAP (Ethertype) value in hexadecimal to be used for each plumbed stream. The more common way to configure PPPoE, though, is through the /etc/ppp/pppoe.if file, which is used to run sppptun at boot time. This file currently takes one interface name per line. It will be updated to use this syntax: if-name [session-SAP [discovery-SAP]] where session-SAP and discovery-SAP are used to set the SAP values for sppptun. The problem described in the original bug report could now be handled by using: e1000g0 3c13 3c12 The defaults (per RFC 2516) are 8864 and 8863, respectively. The sppptun(1M) man page, which describes both the sppptun command line and the /etc/ppp/pppoe.if file, will be updated to describe the new interfaces. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jonathan.adams@sun.com Fri May 22 09:26:40 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MGQesx029491 for ; Fri, 22 May 2009 09:26:40 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MGQeaP191092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 09:26:40 -0700 (PDT) Received: (from jwadams@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MGQeBT191091; Fri, 22 May 2009 09:26:40 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: jwadams set sender to jonathan.adams@sun.com using -f Date: Fri, 22 May 2009 09:26:39 -0700 From: Jonathan Adams To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/317 Solaris PPP/PPPoE Updates Message-ID: <20090522162639.GB189551@eng.sun.com> References: <18966.45865.82910.746790@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18966.45865.82910.746790@gargle.gargle.HOWL> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 894 On Fri, May 22, 2009 at 10:14:01AM -0400, James Carlson wrote: > > The additions for this feature are a new "-s" option for the > sppptun(1M) command: > > sppptun plumb [-s ] [ ] > > This allows the user to specify a particular SAP (Ethertype) value in > hexadecimal to be used for each plumbed stream. The more common way > to configure PPPoE, though, is through the /etc/ppp/pppoe.if file, > which is used to run sppptun at boot time. This file currently takes > one interface name per line. It will be updated to use this syntax: > > if-name [session-SAP [discovery-SAP]] > > where session-SAP and discovery-SAP are used to set the SAP values for > sppptun. The problem described in the original bug report could now > be handled by using: > > e1000g0 3c13 3c12 Why are there two SAPs here, but only one on the sppptun command line? Cheers, - jonathan From carlsonj@phorcys.east.sun.com Fri May 22 09:54:02 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MGs1is029753 for ; Fri, 22 May 2009 09:54:02 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MGs0hP031301; Fri, 22 May 2009 12:54:00 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MGr25P010250; Fri, 22 May 2009 12:53:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MGr2hQ010247; Fri, 22 May 2009 12:53:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18966.55406.293984.242907@gargle.gargle.HOWL> Date: Fri, 22 May 2009 12:53:02 -0400 From: James Carlson To: Jonathan Adams Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/317 Solaris PPP/PPPoE Updates In-Reply-To: <20090522162639.GB189551@eng.sun.com> References: <18966.45865.82910.746790@gargle.gargle.HOWL> <20090522162639.GB189551@eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1942 Jonathan Adams writes: > On Fri, May 22, 2009 at 10:14:01AM -0400, James Carlson wrote: > > where session-SAP and discovery-SAP are used to set the SAP values for > > sppptun. The problem described in the original bug report could now > > be handled by using: > > > > e1000g0 3c13 3c12 > > Why are there two SAPs here, but only one on the sppptun command line? sppptun plumbs one stream at a time. PPPoE uses two Ethertypes -- one for the 'discovery' traffic, and one for the 'session' traffic. The boot-time /etc/init.d/pppd script invokes sppptun twice for each entry in /etc/ppp/pppoe.if -- it plumbs both the 'pppoe' (session) and 'pppoed' discovery protocols. The packet headers on both types of traffic are exactly the same, and the message types used on each are distinct, so they could easily share a single Ethertype -- and indeed the kernel module shovels them through a single dispatch function -- but since RFC 2516 was developed outside the IETF standards process, and was dropped in as an "Informational" track document, there are _many_ such oddities with it. Doing just one stream at a time is for simplicity of design for sppptun, which is rarely used directly by users, and which (at least in theory) could be used in some cases for plumbing only one type of message. For example, you could just plumb the 'pppoed' discovery stream, if you wanted to use /usr/lib/inet/pppoec -i to check for servers without actually running any traffic. (An NWAM-like automatic configuration mechanism might do this.) At the time I designed it, sppptun was going to serve for more than just PPPoE, but those follow-on projects were never funded. Doing one plumb at a time is part of that modular design. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From jonathan.adams@sun.com Fri May 22 10:41:09 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MHf9LZ001104 for ; Fri, 22 May 2009 10:41:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MHf7kd203870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 10:41:08 -0700 (PDT) Received: (from jwadams@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MHf73p203869; Fri, 22 May 2009 10:41:07 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: jwadams set sender to jonathan.adams@sun.com using -f Date: Fri, 22 May 2009 10:41:07 -0700 From: Jonathan Adams To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/317 Solaris PPP/PPPoE Updates Message-ID: <20090522174104.GC189551@eng.sun.com> References: <18966.45865.82910.746790@gargle.gargle.HOWL> <20090522162639.GB189551@eng.sun.com> <18966.55406.293984.242907@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18966.55406.293984.242907@gargle.gargle.HOWL> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 1895 On Fri, May 22, 2009 at 12:53:02PM -0400, James Carlson wrote: > Jonathan Adams writes: > > On Fri, May 22, 2009 at 10:14:01AM -0400, James Carlson wrote: > > > where session-SAP and discovery-SAP are used to set the SAP values for > > > sppptun. The problem described in the original bug report could now > > > be handled by using: > > > > > > e1000g0 3c13 3c12 > > > > Why are there two SAPs here, but only one on the sppptun command line? > > sppptun plumbs one stream at a time. PPPoE uses two Ethertypes -- one > for the 'discovery' traffic, and one for the 'session' traffic. The > boot-time /etc/init.d/pppd script invokes sppptun twice for each entry > in /etc/ppp/pppoe.if -- it plumbs both the 'pppoe' (session) and > 'pppoed' discovery protocols. > > The packet headers on both types of traffic are exactly the same, and > the message types used on each are distinct, so they could easily > share a single Ethertype -- and indeed the kernel module shovels them > through a single dispatch function -- but since RFC 2516 was developed > outside the IETF standards process, and was dropped in as an > "Informational" track document, there are _many_ such oddities with > it. > > Doing just one stream at a time is for simplicity of design for > sppptun, which is rarely used directly by users, and which (at least > in theory) could be used in some cases for plumbing only one type of > message. For example, you could just plumb the 'pppoed' discovery > stream, if you wanted to use /usr/lib/inet/pppoec -i to check for > servers without actually running any traffic. (An NWAM-like automatic > configuration mechanism might do this.) > > At the time I designed it, sppptun was going to serve for more than > just PPPoE, but those follow-on projects were never funded. Doing one > plumb at a time is part of that modular design. Makes sense. Thanks. Cheers, - jonathan From Sebastien.Roy@Sun.COM Fri May 22 12:20:39 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MJKdB8001818 for ; Fri, 22 May 2009 12:20:39 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MJKcgU058426 for ; Fri, 22 May 2009 12:20:38 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4MJKcHn017093 for ; Fri, 22 May 2009 19:20:38 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK200D0083TE000@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Fri, 22 May 2009 13:20:38 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK2003MZ8EDP050@mail-amer.sun.com> for psarc-ext@sac.sfbay.sun.com; Fri, 22 May 2009 13:20:38 -0600 (MDT) Date: Fri, 22 May 2009 15:19:46 -0400 From: Sebastien Roy Subject: Re: 2009/317 Solaris PPP/PPPoE Updates In-reply-to: <18966.45865.82910.746790@gargle.gargle.HOWL> Sender: Sebastien.Roy@Sun.COM To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Message-id: <1243019986.8879.29.camel@strat> Organization: Sun Microsystems X-Mailer: Evolution 2.24.2 References: <18966.45865.82910.746790@gargle.gargle.HOWL> Status: RO Content-Length: 10 +1 -Seb From Darren.Reed@Sun.COM Fri May 22 13:13:42 2009 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MKDfrf002975 for ; Fri, 22 May 2009 13:13:41 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MKDeYF023579 for ; Fri, 22 May 2009 13:13:40 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4MKDZKO021596 for ; Fri, 22 May 2009 20:13:35 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK200H00AIE3G00@fe-emea-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Fri, 22 May 2009 21:13:35 +0100 (BST) Received: from [192.168.2.104] ([unknown] [88.100.101.51]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK2008XDAUMO1D0@fe-emea-09.sun.com> for psarc-ext@sac.sfbay.sun.com; Fri, 22 May 2009 21:13:34 +0100 (BST) Date: Fri, 22 May 2009 22:12:51 +0200 From: Darren Reed Subject: Re: 2009/317 Solaris PPP/PPPoE Updates In-reply-to: <18966.45865.82910.746790@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: James Carlson Cc: psarc-ext@sac.sfbay.sun.com Message-id: <4A170743.6090807@Sun.COM> References: <18966.45865.82910.746790@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1560 James Carlson wrote: > ... > The second feature in this project allows for interoperability with > some peculiar PPPoE access devices that use Ethertype values other > than those documented in RFC 2516. These devices appear to be popular > in some non-US locations. (See CR 4695172 for details.) > > The additions for this feature are a new "-s" option for the > sppptun(1M) command: > > sppptun plumb [-s ] [ ] > > This allows the user to specify a particular SAP (Ethertype) value in > hexadecimal to be used for each plumbed stream. The more common way > to configure PPPoE, though, is through the /etc/ppp/pppoe.if file, > which is used to run sppptun at boot time. This file currently takes > one interface name per line. It will be updated to use this syntax: > > if-name [session-SAP [discovery-SAP]] > > where session-SAP and discovery-SAP are used to set the SAP values for > sppptun. The problem described in the original bug report could now > be handled by using: > > e1000g0 3c13 3c12 > > The defaults (per RFC 2516) are 8864 and 8863, respectively. The > sppptun(1M) man page, which describes both the sppptun command line > and the /etc/ppp/pppoe.if file, will be updated to describe the new > interfaces. What use do you forsee for these new configuration options? ... why would I ever want to change it? To me, it looks like I never would, so I'm wondering if these new interfaces are even necessary? A non architectural question... What happens if they're configured in reverse or to be the same#? Darren From carlsonj@phorcys.east.sun.com Fri May 22 13:22:48 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4MKMlgI003012 for ; Fri, 22 May 2009 13:22:47 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4MKMkIa011975; Fri, 22 May 2009 16:22:46 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4MKLkn2011294; Fri, 22 May 2009 16:21:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4MKLkHQ011291; Fri, 22 May 2009 16:21:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18967.2394.638450.594243@gargle.gargle.HOWL> Date: Fri, 22 May 2009 16:21:46 -0400 From: James Carlson To: Darren Reed Cc: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/317 Solaris PPP/PPPoE Updates In-Reply-To: <4A170743.6090807@Sun.COM> References: <18966.45865.82910.746790@gargle.gargle.HOWL> <4A170743.6090807@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2029 Darren Reed writes: > James Carlson wrote: > > where session-SAP and discovery-SAP are used to set the SAP values for > > sppptun. The problem described in the original bug report could now > > be handled by using: > > > > e1000g0 3c13 3c12 > > What use do you forsee for these new configuration options? > ... why would I ever want to change it? As cited in the original materials, CR 4695172 documents an interoperability issue with 3COM servers. Those servers (for reasons that are substantially unclear, but probably relate to changes in the documentation before publication) use a different set of Ethertypes. > To me, it looks like I never would, so I'm wondering if these > new interfaces are even necessary? Roaring Penguin (the Linux PPPoE) includes a very similar feature for exactly the same reason. You use "-f disc:sess" to set the Ethertypes when you launch the daemon. In fact, I believe they added this for exactly the same reason: to interoperate with those 3COM servers. > A non architectural question... > What happens if they're configured in reverse or to be the same#? If they're reversed, then the user likely won't be able to connect. We'll send out the discovery packets using the session Ethertype and vice-versa. If they're the same, then we'll send all of the packets with the same Ethertype. (If the peer happens to be a Solaris server, both of these cases would actually work, because our kernel design happens to use a single function for dispatching the inbound packets, and we just don't care which Ethertype is used.) Knowing the right numbers to set is important if you want to use this feature at all. Don't forget that these are optional. The following entry in /etc/ppp/pppoe.if will still work and will still give you the RFC 2516 default: e1000g0 -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Wed May 27 10:24:13 2009 Received: from dm-east-02.east.sun.com (dm-east-02.East.Sun.COM [129.148.13.5]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4RHODMH005023 for ; Wed, 27 May 2009 10:24:13 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RHOCu5058929 for ; Wed, 27 May 2009 13:24:13 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4RHNAXw020793 for ; Wed, 27 May 2009 13:23:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4RHNAHE020790; Wed, 27 May 2009 13:23:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18973.30462.821333.446069@gargle.gargle.HOWL> Date: Wed, 27 May 2009 13:23:10 -0400 From: James Carlson To: psarc-ext@sac.sfbay.sun.com Subject: Re: 2009/317 Solaris PPP/PPPoE Updates In-Reply-To: <18966.45865.82910.746790@gargle.gargle.HOWL> References: <18966.45865.82910.746790@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 296 This fast-track request was approved during ARC business on 05/27/2009. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677