jamal writes:
> The advantage of method 2 is that it maintains the goodies that pppd
> provides already (such as dial on demand etc)
> I prefer this method.
Me too.
I take it that you meant to apply your "channelname" proposal to this?
This would mean that pppoxd is some module inside pppd that does the
negotiation.
>
> The main decision to make is what interface should PPPd be
> talking to? For 2.2, the only viable solution is the tty one.
> There is no question that for 2.3 onwards the channel
> interface is the way to go.
>
> So what should be the device that pppd talks to? Is it a new socket
> family, tty device, a new char device etc.?
I think that for PPPoE at least sockets (of some form) are the way to
go, because with a sockets approach we have code that maintains
consistent semantics. What that means is that the code looks like
network code all the way through (with no need to translate to tty
semantics and vice-versa), and that's why I think it is a very "clean"
solution (from a high-level perspective). Although this probably
requires more code (infrastructure code to support a sockets
interface) it's as efficient as anything else on a per-packet basis
(using PPP-channels).
I think that pretty well summarizes why I went with sockets in the
first place...
>
> End Goal:
> ---------
>
> -speed (a given with the channel stuff). However, we need some
> quick way of way to shunt the data to the correct transporter
> within the kernel (eg to UDP sockets for L2TP).
> -flexibility (IMO) make it easy in the future to just add encap/decap
> extensions. i.e i should be able to add todays_flavor_of_pppox
> by simple regiatration APIs, write a user space discovery, bind it to
> pppd and voila, it works (magic!).
>
>
> Note that we currently have a limitation in pppd in that it is very
> friendly to ttys. A small change will be required in the pppd daemon.
> No changes in the kernel PPP.
> I propose addition of a new syntax to the pppd options:
> "channelname <channelname>" eg "channelname l2tp"
> The pppd code should check for this syntax (which is mutually
> exclusive with the devicename option). When this option is passed,
> any assumptions that pppd is talking to a tty device are nullified.
> This syntax could also be used to do other things in the future
> (i,e currently the name above eg l2tp is a meaningless artifact).
I totally agree with this in general. I have a few concerns about
some of the semantics though: I think that the "channelname" option
should register a back-end channel module. This module would then
provide a function which would try to interpret the "devicename"
option. pppd would try the "devicename" recognizers for all
registered channel modules --- the one that accepts is the channel
that is used. By default a "tty" module is used; this module
encapsulates existing tty control functionality. The reason for this
is that you can then specify "channelname pppoe", and this works for
PPPoE connections over eth0, eth1, etc. (the exact device being
specified by the "devicename" options).
> I suggest that the current pppd "connect"/"disconnect" features be used
> for connection setup teardown. Some enhancement might be needed (although
> i dont see it myself).
Perhaps each channel module would provide it's own methods for
"connect"/"disconnect". The "connect"/"disconnect" options as they
are now would have to be recognized as options belonging to the "tty"
module, though each module could support equivalents.
This does raise the issue of how options are treated wrt modules; we
could allow modules to register their own option namespace (e.g.:
allow for channel specific options such as "pppoe.ac_name").
Thus we would allow for each channel module to register an options
namespace and functions for connect, disconnect, and "devicename"
recognition. With such an approach you could have one options file
which would support PPPoE, tty and xxxx sessions simultaneously.
>
> We should merge also the PPP over ATM already implemented using Michals
> idea.
>
I'd appreciate it if somebody would send me pointers to relevant
code so I can see what things are like in PPPoATM land (and how they
relate to PPPoE).
Michal Ostrowski
mostrows@xxxxxxxxxxxxxxxxx
|