On Mon, Nov 17, 2003 at 11:11:39PM -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.
Yeah...no more pty's...that'll be nice. *thinking through it* You may still end up dealing with pty's...I'm hardly an expert on it, but I think pppd is gonna insist on having a char device to use...even if no actual frames pass over it. I think you've already alluded to that being a problem.
Aah, but that's where the PPPoX sockets come in (in theory). They provide a
way to hook into PPP without ptys. This is for example how PPPoE works
without using ptys. That's why I've making this pppox plugin for PPP whose
sole purpose in life is to make pppd accept the socket as a valid connection
point.
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.
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 connect to the channel created, which I'm not sure if that can be done, or how. The other option...one I like, but will involve more work, would be to have the l2tpd running, and start pppd independantly. pppd then runs a child to create the channel...that child then communicates with the already running l2tpd to let the l2tpd do the channel creation and report back to pppd's child. We'd have to work out some IPC (between the pppd child and the standalone l2tpd), but that's not insurmountable. Its a pretty clean solution, once it gets all worked out, and we might even be able to make it happen without totally scrapping the current l2tpd code-base (although that might be adviseable in any case *shrug*). This last model gets around open file descriptor 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.
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 minor, IMO. Even with a copy, we're still going to be significantly more effecient that the current user-space implementations, which typically involve 3 copies in addition to other inefficiencies.Agreed. The only other issue is the single copy that happens when a packet moves from the session socket to the UDP socket. You could probably get around this by hooking straight into the UDP code in the kernel but I'm reluctant to start relying on internal interfaces of core networking code.
Incoming traffic doesn't suffer from this problem (only the data_ready()
hook problem).
But it's close, I can feel it :)Its definitely a good start...and should be solid functionality. I look forward to future enhancements too.
-- Jeff McAdams "He who laughs last, thinks slowest." -- anonymous
Attachment:
pgp00125.pgp
Description: PGP signature
