On Tue, Nov 18, 2003 at 10:58:44AM -0500, Jeff McAdams wrote: > I was under the impression that, even with the PPPoE setup, there was > still a pty allocated, albeit from the pppd side, rather than from the > other side of the connection. Note, there are two ways to setup pppoe. The common one is as you say, pppd spawns a process with a pty which sets up the pppoe connection. The version i was thinking of is the pppoe plugin that comes with PPP 2.4.2. When done that way, pppd is spawned like: pppd plugin pppoe.so <I forget the other options> Then the plugin creates a PPPoX socket, sets it up in the kernel and then passes the fd back to pppd. > Here's a question. What do you see as the model for starting up pppd? > Currently l2tpd sets up the ptys and such (poorly, but it does it), then > forks and execs pppd to communicate over that pty, as I'm sure you're > aware. From what I've seen of pppoe setups, pppd starts up, then, using > the pty option, runs a script that sets up the channel...so we have > rather significantly different theories of operation, here. In l2tpd, > the channel is created, then pppd is fired up to run on the channel...in > pppoe, and in the pppox model in general, from what I can tell, pppd is > fired up and it then fires off a child script to create the channel. Well, the way I'm currently setting it up is that the l2tp server creates the PPPoX socket and connects it and then forks pppd as follows: pppd plugin pppox.so pppox_fd <fd no> <other options> Where the fd is passed by inheritance. No other parameters required. All you really need is for pppd to skip the test for a character device. Doing it as a plugin provides some more flexibility. I'm thinking you could have pppd use getsockname() to retrieve the tunnel endpoint and pass it on or print. I'm not sure how useful that info is though. > I can see doing it either way, but due to the requirements of L2TP, > you'll have to have an l2tpd running stand-alone regardless. So, either > that l2tpd can fire off the pppd connections with the channel already > created, the current model, but that doesn't fit in all that well with > what you've already done because you have to be able to tell pppd how to [snip] > limits in l2tpd, which has always been a problem. We do still run into > kernel limits on the number of ppp network interfaces that can be > configured (I believe its hard coded to 100 currently)...that will need > to be over-come eventually. Like i said, pass the file descriptor. There's no need for the l2tp server to keep the PPPoX socket open after the pppd process has been started. So file descriptors are no issue. The current setup of this module is that you have to attach the PPPoL2TP socket to a file *descriptor*. In other words, if you don't have access to the file descriptor, you can't create attached sockets. Which is good since it solves your problem of controlling access. And when you say IPC, I still think the best approach is the simplest IPC there is, file descriptor inheritance. > Oh, and this model still doesn't address the scenario of using a Linux > machine as a traditional LAC (ie, serial connection coming into the > linux box with PPP frames coming in on the serial connection and, rather > than being handled by pppd, being encapsulated by l2tpd to be sent to > another system). I'd really like to see that capability > exist...unfortunately, I think its going to virtually require some > rather significant surgery to Linux's PPP support...both in-kernel and > user-space. :/ That's easy. This current module, if the PPPoX socket is not bound to a PPP device, it will simply respond to sendmsg/recvmsg and encapsulate them. So yes, that will require a trip through userspace (unless ofcourse someone wants to fiddle the module to accept ordinary character devices to bind to and trap all the traffic through them, I don't know how to do that, they don't use skb's). What you really need is some generic chunk-of-data transport within the kernel so that you can more easily move data between different sections of the kernel. Hope this helps, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > "All that is needed for the forces of evil to triumph is for enough good > men to do nothing." - Edmond Burke > "The penalty good people pay for not being interested in politics is to be > governed by people worse than themselves." - Plato
Attachment:
pgp00126.pgp
Description: PGP signature
