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.
Hmm... the code I'm looking at just goes into the "network_thread", hits a "read" on the fd that is connected to pppd, reads the ppp packet, sends it out in UDP, then comes back to read the pppd fd - without bothering to check the incoming network traffic.
Then when PPP disappears, l2tpd breaks out of the loop, and suddenly starts reading the packets that are still in the buffers...
Always a perennial task. You should go back and try to read the pre 0.65 code...talk about a mess!
*shivers*
Or not :)
I, honestly, think the config file needs to be scrapped and a new file format and parser created.
I'm a fan of the INI style config files - I've even contributed to the Config::Inifiles Perl module!
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.
There's always that userspace stuff that some guy wrote, that combines PPP (with RADIUS auth!) into the L2TP daemon, in order to handle hundreds of clients: http://l2tpd.graffl.net/msg00642.html
I've emailed him about it. Hopefully the email address still goes to someone.
Alex
