On Sun, 6 Feb 2000, Mark Spencer wrote:
> > Is there a good reason as to why you did it this way (other than probably
> > the code being smaller)?
>
> It fit in well with the current pppd model.
>
Ok.
> > In particular with the Multi-PPP, how does it provide an advantage?
>
> I put some mechanisms in the kernel to use the two parameters provided by
> the MPPP spec to decide which should bundle, and provided an override
> capability for pppd, if so desired. I really don't think that the
> userspace programs should have to confer with one another to decide who
> should go in an MP bundle.
>
> My method allowed any pppd to know whether it was a master or a slave
> channel and the kernel could dynamically add and drop channels to/from a
> bundle.
>
I think Paul is the best person to respond to this; my knowledge of MPPP
is rather basic.
> > Mind to comment please (and whether moving to the socket interface
> > will screw this grand scheme of things)
>
> I really just don't see the socket advantage. What's missing here is a
> clear description for just what it is we're looking to accomplish, and a
> good model for designing such a system. For example, consider L2TP... As
> an LNS, I want to read PPP frames from a network socket (with l2tp
> encapsulation) and then send them to the network layer or a pppd. The
> most likely scenario I can see for that is to create a socket, then call
> some ioctl()'s to make the kernel aware of new connections and such. Then
> I need a way to apply those to PPP channels, and launch a pppd to handle
> the negotiations. We want the datapath within the kernel to be fast (no
> copies).
It can be done in the kernel.
The control should be downloadble via the PPPOX interface (whether sockets
or character devices) e.g. mapping of the ppp channels etc.
You should be able to add a local_in netfilter hook to grab
incoming UDP packets and filter them for L2TP headers; massage them for
the next output interface (eg remove L2TP headers and stash PPP headers or
FR headers etc ) and then shove them out that interface.
> Now, if I'm a LAC, I want to copy PPP frames from a device (say, a tty or
> ISDN driver, or even another pppd) to my L2TP socket... Can this also be
> done with a kernel datapath? My API didn't really have a mechanism for
> doing so, but it would be nice if the new one did.
Yes. Assuming of course that the devices you are reading from are network
devices. Otherwise it becomes a little more complex.
Currently the add_pack API is for layer 2 protocols only eg PPPOE fits
fine there for incoming packets since it reads from ethernet
L2TP over PPP, FR, ATM etc i believe should work the same way. If not via
add_pack then maybe over something else similar for ATM or FR etc.
You will have to write the data-shunting interface to UDP; i.e open and
close sockets from within the kernel and then bind them to a channel
(Michal had a good example os the sock->bind() interface established
during the "call connect").
So in essence via the generic interface (pppox) you should be able to
send control information to select LNS vs LAC and what API to register
for receive and transmit which also do the encode/decode; and all these
could be modules.
> Mark
>
> p.s. Would you like me to setup a mailing list for this? I've got
> majordomo and it wouldn't take me but a few minutes to do so.
>
I dont know what others think. If people in netdev are getting upset maybe
we should move.
cheers,
jamal
|