Re: [L2tpd-devel] The road to 0.7

[Jeff M. <je...@ig...>]

Also sprach Scott Balmos
>I'd love to know, now, what unhandled attribute 47 or whatever it is
>when a tunnel is created to Iglou. LOL

I believe you're referring to attribute 46, which is a vendor specific
attribute from RedBack for Framing Capabilities...basically, its used by
the RedBack to indicate that it can do ethernet over L2TP as well as
regular PPP over L2TP (at least I *think* that's the case as there isn't
a great deal of docs on this specific capability on RedBack's site)

>Afterwards, once the docs are at least a little bit better shored up,
>we can release this as 0.7. Looking towards 0.8 and maybe even 1.0, we
>might be heading to the point to where it'd be more beneficial to us to
>start ripping codeblocks and rewriting. :/ That's going to be a pain.

Might want to go ahead and release this as is, as 0.62...as much as
anything to let people know that development of it has been picked up
again, and possibly recruit some more volunteers for more work!  ;)

>Eventually, I think what we need is for 1.0 to be a completely
>daemonizing server system in the background, and then instead of having
>echo streams passed to the control pipe, either try and eliminate the
>pipe if we can or write a separate command line client to handle pipe
>commands. Something a little bit easier or straightforward than echo
>"blah blah blah". Also, by 1.0, there needs to be at least initial
>support for some type of encryption (hint IPSec)... unless we want to
>try and confuse the general Windoze public with even more Registry
>screwups... err... fixes. :)

Whew...IPSec by 1.0 is rather ambitious, but I'm game on the concept.

>Even further forward, the 1.x tree towards 2.0 is where we really
>confuse ourselves and try to see about separating the code into a
>kernel module. But we won't go there yet. That's just scary...

And you think IPSec *isn't* scary?  You're weird.  :)

>Anyway, as for Jeff's comments about how to more cleanly shut down the
>higher-layer controls, such as PPPd... I think we might want to take a
>look at the source of getty, or whatever program controls a modem
>during a normal PPP dialup session. That's all L2TP really is is just a
>glorified dialup modem session in a way. It's been my position for a
>while now just to look at how things are handled already by modem
>sessions, and then go from there.

The only trickiness that I see is that there's almost two levels of
stuff going on in l2tpd.  You've got the tunnel itself, and then the
call/session within the tunnel.  In cvs, if you want to kill the
call/session, it works fine, 'cause all it has to do is send a SIGTERM to
pppd and wait for it to exit, then clean up the call with the CDN and
all that.  When you want to kill a tunnel though, you have to go in,
send a SIGTERM to *all* of the pppd's on all of the calls/sessions
within the tunnel, wait for *all* of them to exit and clean up the
calls/sessions, and then also clean up the tunnel as a whole, so its not
just a matter of whacking the child process and letting it die and
cleaning up the "serial line", but you also have to worry about juggling
what calls are active and waiting before cleaning up...the really tricky
thing is that you have to keep sending and receiving stuff on the
tunnels and calls while you're doing this to allow pppd to clean up so
you can't just plain recurse.  :/

>Comments anyone on placing this roadmap up on the docs area, and
>placing some of these tasks up in the to-do list?

I'd definitely put the info up...can't have too much info up there.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456