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
