> > 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.
> For a tty you could make a line discipline which would shunt the packets
> down the l2tp socket. Alternatively you could have a kernel thread doing
> reads and writes on the device and your l2tp socket. That might actually
> turn out cleaner.
We definately want whatever the next PPP rewrite looks like to include some
mechanism for this (which is probably best described as PPP bridging).
I don't think we need a kernel thread to do it, either- you just need
to wire ppp_input() on one channel to ops->start_xmit() on the other,
perhaps with a small skb queue in the middle.
This capability has many uses... for instance some companies sell devices
that turn PPP-over-async and PPP-over-DS1 sessions into PPP-over-ATM
so you can backhaul those customers accross your ATM network and terminate
the PPP session on your big-iron router. We could give linux the
capability to do this quite easily.
If implemented intellegently this could also be used as a basis for
implementing multi-chassis MPPP (i.e. supporting bonding multiple
incoming calls into one bundle even if the calls landed on different
machines) To do this, you need a way to get the PPP frames that
landed on the slave box(es) back to the master box (which is actually
handling the routing for the channel). One easy way to do this
would be to just have the slaves bridge the PPP packets over
some other transport (L2TP for instance) and have the master put
that transport in the bundle with the others. Note that the "master"
actually can be bundling nothing but channels from slaves - it could
be a box that only handles routing for PPP bundles bridged over from a
set of slave boxes... Cisco's large-scale dialin solution is
architected that way.