To the perosn who suggested subversion, I'm going to have to read more on itThe command line client is very cvs like, so you can probably switch over to it without a great deal of grief.
since it didn't appear "obvious" to me.
The 3 line tutorial on switching:
Eliminate the login step, svn will prompt you for it if necessary. Access to repositories is via URL's (file:///, http://, ssh+svn://, etc.). Add svn mv, svn cp, and similar that do what you would expect. Keep in mind that svn tracks directories, thus the svn mv and similar commands that let you manipulate files and maintain history that you would normally lose in cvs.
(OK, it was four lines, so sue me ;)
l2tpd currently keeps track of the pppd's by the file descriptors that it uses to talk to them...well...sorta. It has a structure for each call/session which holds the descriptor and other information, but the descriptor is the real link to pppd. But I guess the descriptor is going away, now, so there will have to be another way to keep track of it. pppd would still be a child of l2tpd in the model you envision, so we can still keep track of them via pids if you like.Next step is to modify the L2TP daemon source to use this code. The most obvious thing missing for me is a way for the server to select tunnels/session to terminate. At the moment it's fire-and-forget.
Let me know what I can do to help with the l2tpd code. I'm fairly adept at finding my way around it, so if you have questions, hopefully I can answer them. Oh, and I hope you roll your sanity saving throws well. ;)
The L2TPYes, and we still need to be able to have l2tpd kill the sessions for control at that layer. I guess the user could kill the pppd when necessary, but they may not have the information about which pppd goes with which call/session, so that might get tricky.
can ignore a session once it has started. But since you want to have the PPP
daemons eventually killed off (not just by LCP timeout) I figure an ioctl is
necessary.
>Code at the usual place:
http://svana.org/kleptog/kl2tp/kl2tp-0.2.tar.gzFor anyone wanting to use it...I've synced up http://jeffm.jeffm.iglou.com/svn/kl2tp with this release. Apologies for the delay...I'll try to stay more on top of this in the future.
Thanks for all the help so far.Any idea why they're sending multiple Conf-Req's? 1701 sends two, never gets a response to the first one at all, which is slightly concerning given that its all on localhost...1702 sends one, gets an ACK, then sends another with the exact same parameters?
23:57:26.633583 127.0.0.1.1701 > 127.0.0.1.1702: l2tp:[O](3/4) {Conf-Req(1), MRU=1400, ACCM=00000000, Magic-Num=bb873c04, PFC, ACFC} (DF) [ttl 0]
23:57:26.687146 127.0.0.1.1702 > 127.0.0.1.1701: l2tp:[O](1/2) {Conf-Req(1), MRU=1400, ACCM=00000000, Magic-Num=5ef3b6bc, PFC, ACFC} (DF) [ttl 0]
23:57:26.712170 127.0.0.1.1701 > 127.0.0.1.1702: l2tp:[O](3/4) {Conf-Ack(1), MRU=1400, ACCM=00000000, Magic-Num=5ef3b6bc, PFC, ACFC} (DF) [ttl 0]
23:57:29.772066 127.0.0.1.1701 > 127.0.0.1.1702: l2tp:[O](3/4) {Conf-Req(1), MRU=1400, ACCM=00000000, Magic-Num=bb873c04, PFC, ACFC} (DF) [ttl 0]
23:57:29.795795 127.0.0.1.1702 > 127.0.0.1.1701: l2tp:[O](1/2) {Conf-Req(1), MRU=1400, ACCM=00000000, Magic-Num=5ef3b6bc, PFC, ACFC} (DF) [ttl 0]
23:57:29.821622 127.0.0.1.1701 > 127.0.0.1.1702: l2tp:[O](3/4) {Conf-Ack(1), MRU=1400, ACCM=00000000, Magic-Num=5ef3b6bc, PFC, ACFC} (DF) [ttl 0]
23:57:29.846329 127.0.0.1.1702 > 127.0.0.1.1701: l2tp:[O](1/2) {Conf-Ack(1), MRU=1400, ACCM=00000000, Magic-Num=bb873c04, PFC, ACFC} (DF) [ttl 0]
-- Jeff McAdams "He who laughs last, thinks slowest." -- anonymous
Attachment:
pgp00132.pgp
Description: PGP signature
