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 <james.d.carlson at sun.com> 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
