2009/317 Solaris PPP/PPPoE Updates

[Jonathan Adams]

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