Finally I managed to find it :) Google thinks that rp-l2tp still lives on the Roaring Penguin site.
Yeah, David set up a sourceforge project for it. I had to go find it myself...
My colleague and I spent a few hours last night getting l2tpd 0.69 to work for us on three Linux 2.4.21 boxen - mainly involving setting a couple of file handles to non-blocking.
That really shouldn't be necessary. The theory of operation for l2tpd is that it doesn't read a file handle unless it *knows* that there's data to be read...ie, it should never, in normal operation, block. If it blocks, something is broken and needs to be fixed.
The "game plan" for us here at my office is as follows: 1) Make it work as a LNS to a Cisco LAC
I know some interoperability has been tested with a couple of different pieces of Cisco gear. Both IOS and the Altiga derived stuff (VPN 3000 type gear).
2) Tidy up the code so we can read it
Always a perennial task. You should go back and try to read the pre 0.65 code...talk about a mess!
3) Clarify the configuration file[1]
I, honestly, think the config file needs to be scrapped and a new file format and parser created.
4) Make it work reliably (24x365) 5) Make it work large-scale (2000 PPP connections on one server)
I've seen l2tpd run for really long periods of time without any sort of hiccups...the number of connections, however, will be considerably limited from that...and not necessarily because of l2tpd. Obviously, because we use a lot of file handles, we're going to run out of them fairly soon...but, with stock Linux kernels, you're going to run out of PPP interfaces (kernel hard coded limit of 100 IIRC) before you run out of file handles in l2tpd.
To achieve these ends, we'll be concentrating on reliability and efficiency - not bells and whistles. I'm not too concerned about exploitable vulnerabilities just yet - the environment is a controlled network, so we can (for the meantime) trust the other machines on the network to behave in benevolent rather than malevolent manners ;)
2) The flow of the code is a little hard to follow right now. I'd like to move portions of the code into sensible groups, along with splitting/merging some functions to make more "sense".
Wise idea.
At the same time, I'd like to leave L2TPD with only the "file", "nodetach" and "debug" options to pass to PPPD. Everything else can be configured through PPP options files. The less confusion the better!
I'm with you on this. l2tpd shouldn't be trying to tell pppd how to be configured, in general. I see the options in l2tpd that essentially stick stuff on the pppd command line as conveniences, by and large. Architecturally, it shouldn't do that.
3) With an extra distinction (eg: "remote" and "local"), it will be easier to maintain a group of machines - set up one config file and one secrets file, then copy these files around en masse. Thus given a bunch of machines:
[local lac server1] ...
I'm not sure what I think of this...I'll have to think that through. Though, if the config file is scrapped and re-written, this becomes moot.
The config file parser should also validate the config file, so parameters that don't belong in a particular section should be flagged (either through a warning in the log, or with the server aborting with an error).
Agreed.
I really need to get my head around the distinctions between L2TPD options and PPP options, and which PPP options in the L2TPD config override or are overridden by the options in the various PPP options files.
That's all up to pppd, honestly. The only thing l2tpd is able to do to try to control pppd is to stick stuff on the command line (well, exec()'s equivalent)...so, if you grok how pppd handles options in config files versus command line, then the interaction with l2tpd makes sense.
4) We've had problems here where calls would end up looped back at random - I suspected timing issues, but we've used cfmakeraw to combat the symptoms. Running under strace removed any occurrence of loopbacks, so there is definitely a race condition in there somewhere. Many other issues will arise that affect the robustness of the code.
I don't think its a timing issue. I think it has to do with tty configuration. Its never been quite right...and since l2tpd and pppd speak to each other over a tty/pty pair, if you get the tty/pty echo'ing the frames, it'll get treated as a loopback condition.
5) Based on casual observation, we expect that it should be possible to support 2000 simultaneous ADSL users on one of our servers. We need to drastically reduce the number of context switches though. Perhaps the future involves integrating L2TPD with the userspace component of PPPD, producing a kernelspace L2TPD component, or more magic stuff...
I've given some thought to this...but never really put any code together to do it.
I've recently given a bit more thought to it. My thought is that an initial kernel L2TP implementation would operate as a PPP channel in the Linux kernel. That would only allow for LNS and LAC Client operation, not operation as a tradition LAC, but it would eliminate context switches, which is the big win, here.
Ideally, I think the PPP channel mechanism will need a bit of work, so that you can another module, which would be an L2TP protocol module that would use the existing PPP channels to communicate. That's not going to be an easy change, however, because all of the sudden you're going from having a one-to-many relationship (one PPP module, many channels) to a many-to-many relationship (many protocol modules, PPP, L2TP, possibly others; and all of the various channels...any channel would then be able to communicate with any of the protocol modules...challenging)
Then you have the issue of control. You need a user-space component...probably to handle all of the control channel operations over the network...and to coordinate what tunnels and sessions are established in the kernel structures. So, how do you communicate between kernel and user code? Not hard...but you/we need to decide how to do it.
Oh, here's one. The payload data channel would be handled entirely in-kernel, so first you need to tell the kernel not to send stuff on udp port 1701 out to a user-space program. This is actually a tad bit tricky from what I've been able to find...though I suspect it may be something easy that I just haven't run across how to do, yet. This also complicates the communication to the user-space component for the control channel....the user-space portion can't really just listen on udp port 1701 anymore, because the in-kernel portion is fulfilling that function.
Oh, and I just switched to using Mozilla Mail...so if the formatting on this message is totally hosed...that's probably why. I'm still figuring out some of it. :)
-- Jeff McAdams "He who laughs last, thinks slowest." -- anonymous
pgp00000.pgp
Description: PGP signature
