Hopefully, I can get back into the swing of things again. Using this software myself will help, ...
Its the rp-l2tp project on sourceforge. Its just a whole lot cleaner code, in a lot of ways, than l2tpd is.
Finally I managed to find it :) Google thinks that rp-l2tp still lives on the Roaring Penguin site.
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. Now we're working on slicing out the excessive debug statements we introduced.
The "game plan" for us here at my office is as follows: 1) Make it work as a LNS to a Cisco LAC 2) Tidy up the code so we can read it 3) Clarify the configuration file[1] 4) Make it work reliably (24x365) 5) Make it work large-scale (2000 PPP connections on one server)
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 ;)
1) This is the most important goal - I've been reading through the list and I expect that it should be achievable very quickly.
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". 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!
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:
Cisco1 (LAC) \ Server1 (LNS) \ / Cisco2 (LAC) -->--< / \ Cisco3 (LAC) / Server2 (LNS)
We can configure both machines as:
[local lac server1] ...
[local lac server2] ...
[remote lac cisco1] ...
[remote lac cisco2] ...
[remote lac cisco3] ...
[local lns server1] ...
[local lns server2] ...
[remote lns server1] ...
[remote lns server2] ...
Then server1 and server2 can bring up links between themselves if required (eg: for testing), and the config file can be used on all the servers.
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).
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.
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.
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...
