l2tpd-devel Mailing List for L2TP client / daemon

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi All,

I am absolute Newbie to L2TP.

=A0=A0 Please guide me with an url where I
can find any sort of documents as how to use l2tpd
as LAC and LNS on linux machine.

Thanx in ADV
Cheers,
Achal.

It's much more informative, and has a better chance of getting an
answer, if you post to the development list. I can't answer everything.

This has been forwarded to the list to see what the members have to say.

-----Original Message-----
From: jack xiao [mailto:jac...@ho...] 
Sent: Monday, January 21, 2002 6:34 PM
To: Scott Balmos
Subject: Re: further report about L2TP

Hi,

Sorry to disturb you for a little while. :) I have got l2tpd from
sourceforge.net working under FreeBSD now. We allocate each user a
static ip address and use /etc/chap-secrets for authentication. I am
thinking about to talk to remote radius server for authenticating in the
future. But I know, under Linux, people using some patches with radius
functions for pppd while I have not found anything under FreeBSD.:( Can
I use ppp to replace pppd since ppp can support radius function very
well? Do you think it's possible?

Thanks in advance!

Jack

Also sprach Jeremy Lunn
>On Fri, Jan 18, 2002 at 07:54:29PM +0100, Huiban Yoann wrote:
>> I think you lost a little time implementing this patch.  See the
>> message "L2tpd Howto : increasing the number of sessions" in the
>> mailing list...

>Oh well... it was still a good exercise :-)

>Any ideaw hy the code from the howto wasn't implemented?

To be quite honest?  Because it was basically over my head at the
time...its still sitting in my in-box waiting for me to come up with
enough of the round tuits to figure out for sure what's going on with
it.  I got a few of those tuits today, but not enough to feel quite
comfortable with committing it yet.

I really don't want to commit code to this beast that makes it even more
cluttered, or limited as to the platforms that it works on than it
already is, so I want to be sure that we come up with a solution that
works (assuming everything else in the code base would work, which is
laughable at best at this point) on a variety of platforms.  The getpt(),
which I seem to remember seeing in Huiban's code, is, if I understand it
correctly, Linux specific, but I could be wrong, and if so I'll gladly
eat humble pie on this.  :)

For a similar reason, I haven't yet committed your patch like I said I
was going to earlier...since it spewed out several warnings, I wanted to
make sure that I knew for sure what was going on with it before I
committed it.  I've never worked with Unix98 PTY's, so I have a little
bit of learning to do here.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

On Fri, Jan 18, 2002 at 12:29:24PM -0500, Jeff Mcadams wrote:
> Hrmm...my Debian woody box doesn't seem to have any man pages about
> grantpt() and related, so I haven't been able to check if this is
> reasonable...I'll go ahead and commit it though (it can always be backed
> out).

There is very basic documentation in /usr/share/stdlib.h.  There is more
detailed documentation at:
http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_17.html#SEC375

It probably isn't necessary since l2tpd is running as root.  If l2tpd
could be hacked to run as non-root for most of it's functions then it
would be a good idea to leave it.

If getpt() would return a Unix98 PTY then it might be better to use that
except it's a GNU extension.  On the other hand openpty() as declared by
pty.h would be more portable if it does the same thing.

> Also...for small patches like this, its probably not really very helpful
> to gzip them...makes it rather more difficult to review them before
> applying them.  :)

Whoops I don't know why I did that!

> Cool...that will be nice for figuring out what pty or tty code we will
> need at the very least.

And detecting the operating system.

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

On Fri, Jan 18, 2002 at 07:54:29PM +0100, Huiban Yoann wrote:
> I think you lost a little time implementing this patch.
> See the message "L2tpd Howto : increasing the number of sessions" in the mailing list...

Oh well... it was still a good exercise :-)

Any ideaw hy the code from the howto wasn't implemented?

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

Hi,

I think you lost a little time implementing this patch.
See the message "L2tpd Howto : increasing the number of sessions" in the mailing list...

Regards,
Yoann

> -----Original Message-----
> From:	je...@au... 
> Sent:	Friday, January 18, 2002 5:01 PM
> To:	l2t...@li...
> Subject:	[L2tpd-devel] Unix98 PTY patch
> 
> Here is a very simple patch to use Unix98 PTYs instead of the old BSD
> style ones.  As a sidenote if /dev/ptmx is not available but
> /usr/include/pty.h is then it should probably be used instead of the
> current code but I don't know enough about this yet.
> 
> Also would be nice to move all source files into a src directory.
> 
> And I might have a play around with autoconf later today (eeer it's 3am
> and I need some sleep!).
> 
> -- 
> Jeremy Lunn
> Melbourne, Australia
> http://www.jabber.org/ - the next generation of Instant Messaging. << File: l2tpd-unix98.patch.gz >> 

Also sprach Jeremy Lunn
>Here is a very simple patch to use Unix98 PTYs instead of the old BSD
>style ones.  As a sidenote if /dev/ptmx is not available but
>/usr/include/pty.h is then it should probably be used instead of the
>current code but I don't know enough about this yet.

Hrmm...did this compile cleanly for you?  Gave me several warning about
implicit declarations of grantpt(), unlockpt(), and ptsname().  I think
it works with these, but I just want to be sure I know what's going on
with this.

Keep in mind that I may just not have my system set up to handle Unix98
pty's a this point.  :)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Also sprach Jeremy Lunn
>Here is a very simple patch to use Unix98 PTYs instead of the old BSD
>style ones.  As a sidenote if /dev/ptmx is not available but
>/usr/include/pty.h is then it should probably be used instead of the
>current code but I don't know enough about this yet.

Hrmm...my Debian woody box doesn't seem to have any man pages about
grantpt() and related, so I haven't been able to check if this is
reasonable...I'll go ahead and commit it though (it can always be backed
out).

Also...for small patches like this, its probably not really very helpful
to gzip them...makes it rather more difficult to review them before
applying them.  :)

>Also would be nice to move all source files into a src directory.

Aha...good thought.  In conjunction with running *.c and *.h through
indent to programatically clean up the code...this will work well.

The only reason I hadn't run indent on this stuff already was because it
would make diffs be this huge mess of crap once it was committed.
Starting with a new directory, though, should prevent that from being a
significant problem.  It will still be hard to compare code before this
point and after it, but at least it won't look so ugly.  :)

>And I might have a play around with autoconf later today (eeer it's 3am
>and I need some sleep!).

Cool...that will be nice for figuring out what pty or tty code we will
need at the very least.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

On Sat, Jan 19, 2002 at 03:00:51AM +1100, Jeremy Lunn wrote:
> Here is a very simple patch to use Unix98 PTYs instead of the old BSD

I should mention that it is against CVS.

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

Here is a very simple patch to use Unix98 PTYs instead of the old BSD
style ones.  As a sidenote if /dev/ptmx is not available but
/usr/include/pty.h is then it should probably be used instead of the
current code but I don't know enough about this yet.

Also would be nice to move all source files into a src directory.

And I might have a play around with autoconf later today (eeer it's 3am
and I need some sleep!).

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

On Fri, Jan 11, 2002 at 11:03:37AM -0500, Jeff Mcadams wrote:
> >* Add Process ID# in startup output.
> 
> Cool...do we write the pid out to a pid file anywhere?  Should be
> trivial to add if we don't and could be useful.

Probably not really necessary considering that you can create a pid file
from the script that you use to invoke l2tpd anyway (I did it from
start-stop-daemon with the -m option).

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

On Fri, Jan 11, 2002 at 11:14:26AM -0500, Jeff Mcadams wrote:
> >Now I just have to get portslave working and see how well I can get
> >this working with with RequestDSL.  It would be a good idea to ensure
> >that portslave and l2tpd work together and I'm sure it can't be too
> >difficult.  I'll probably write a howto when I've finished.
> 
> I am rather completely unfamiliar with portslave, so I don't know that I
> can be much help in this part...but certainly let us know your success
> and keep involved.

I now have l2tpd working with portslave.  Basically you have to load the
libspr.so plugin that comes with portslave and set the following
environment variables which I set from the script that I started l2tpd
with:
export PORTSLAVELOGNAME=l2tpd
export PORTSLAVE_SESSION=$RANDOM$RANDOM
export PORTSLAVE_START_TIME=`date +%s`

Then you have to configure /etc/portslave/pslave.conf with all the usual
options including to specify all the pseudo terminals.  One thing I'm
not sure is how a pseudo terminal is allocated as /dev/ptyp0 in pty.c
but according to pppd/portslave it's /dev/ttyp0, any ideas?

> Again, I'm totally unfamiliar with portslave, so that doesn't mean much
> to me....I will agree that our conf file sucks swamp water through
> straws though.  I've been pondering other possible formats, haven't
> really had any bright ideas though.

Well to set all ppp options in portslave it has:
all.autoppp     proxyarp %d asyncmap 0 %i: \
                noipx noccp login auth require-pap refuse-chap \
                mtu %t mru %t \
                ms-dns 192.168.1.1 ms-dns 192.168.1.2 \
                plugin /usr/lib/libpsr.so
(which starts pppd in the same way as above when portslave is answering
calls on a serial port).

> >-  Perhaps when l2tp is completely kernel space it would an idea to only
> >   have to configure portslave in userspace and adopt portslave to answer
> >   r l2tp calls.  Although I'm sure some people won't want to use RADIUS
> >   authentication and/or accounting.
> 
> *shrug*  Sounds cool...what little meaning that carried without knowing
> how portslave works.  :)

Well the binary just listens on a serial port and the plugin does most
of the work if autoppp is used.  If the system login method is used then
a bit more has to be done by the portslave binary.

-- 
Jeremy Lunn
Melbourne, Australia
http://www.jabber.org/ - the next generation of Instant Messaging.

confirm 825815

> Yeah...I've used ethereal with my work in debugging problems with l2tpd.
> It is an excellent package.  I can't say that I had anything to do with
I'm yet to play with it actually (too many cool packages and not enough
time or processing power for all of them ;-) ... but it looks very groovy ..
actually I'm going to see if the bastard runs on Winblows XP ... they're site
says that I'd be mad to do it, so I'm gunna give it a shot :))

> the L2TP protocol support in it though.  But thanks for thinking that
> I'm actually capable of it!  ;)
hehehe ... sure you could ... 

> I appreciate it...though I certainly was only part of getting the
> project revived.  I started out just maintaining my own tree with fixes
> that we needed here at IgLou.  Scott really takes the honor of being the
> driving force of putting the new project together to revive it as a
> whole.
Well definitely a thanks to everyone involved ... when I was first looking for
L2TP on linux, the only info was for a package that had been 
relocated, then discontinued .. then two weeks later you guys started 
playing around with it .. good stuff.

Also sprach Ian
>  I've been on the list for about 12months, but have never attempted to
>run your software (the thing I wanted to use it for has gone away again
>:-) I just wanted to let you know that yesterday in my travels I found
>that EtheReal (http://www.ethereal.com/) has L2TP
>recognition/understanding ..  I don't know how sophisticated their code
>is (or if you wrote it for them ;) but I thought I'd point it out ..
>maybe some friends over there ..

Yeah...I've used ethereal with my work in debugging problems with l2tpd.
It is an excellent package.  I can't say that I had anything to do with
the L2TP protocol support in it though.  But thanks for thinking that
I'm actually capable of it!  ;)

>Thanks for reiving this project ... I only recently started my own
>project on sourceforge ... and as a "hobby" it really is hard to keep
>up the development ...

I appreciate it...though I certainly was only part of getting the
project revived.  I started out just maintaining my own tree with fixes
that we needed here at IgLou.  Scott really takes the honor of being the
driving force of putting the new project together to revive it as a
whole.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

G'day Jeff,

  I've been on the list for about 12months, but have never attempted to run
your software (the thing I wanted to use it for has gone away again :-)
I just wanted to let you know that yesterday in my travels I found that 
EtheReal (http://www.ethereal.com/) has L2TP recognition/understanding ..
I don't know how sophisticated their code is (or if you wrote it for them ;)
but I thought I'd point it out .. maybe some friends over there ..

Thanks for reiving this project ... I only recently started my own project
on sourceforge ... and as a "hobby" it really is hard to keep up the
development ...

  ----- Original Message -----
>From: "Jeff Mcadams" <je...@ig...>
>To: "Scott Balmos" <sco...@ut...>
>Subject:  Re: [L2tpd-devel] 0.64 released, et al
>Date: Tue, 15 Jan 2002 18:35:27 -0500
>
> Also sprach Scott Balmos
> >http://prdownloads.sourceforge.net/l2tpd/l2tpd-0.64.tar.gz (apparently
> >the file release area says the release exists, but no files are
> >added...  It's there, believe me)
> 
> Yup, confirmed...the files are there.  May have just taken the
> sourceforge pages some time to update behind the scenes or something
> *shrug*
> 
> >I would *really* love to take this thing farther, and I know it'll
> >continue to do so... But should I be the project maintainer if I can't
> >even really follow the code?
> 
> There's more to being a project maintainer than just coding on the
> software...though that's really not an answer to your question.
> 
> >Does anyone else out there want to become a project manager? At the
> >moment, Jeff is our Alan Cox, as I like to call him. He deals with the
> >bugfixes and all that fun. But really I think there needs to be a
> >complete rewrite, audit, whatever you want to call it, that puts us
> >into the kernelspace. This CVS tree has been set up for a long while,
> >as l2tpd-devel, and was to be the 0.7 tree (devel releases would be
> >like 0.701, and 0.71 through 0.75 would be matching the functionality
> >of the existing 0.6 tree). That, unfortunately, is completely out of my
> >realm (reentrant kernel code scares me. :D), and as Jeff said, he only
> >has about the first 20 lines of the kernel module template.
> 
> >We need a project manager that can spearhead the bleeding edge 0.7
> >rewrite... Anyone??? :)
> 
> If noone else steps up to the plate...I could probably take on a more
> active role.  It'd be nice to have someone that has a little more time
> to put into it than I have as well...though I realize that there just
> plain may not be someone that has the time and inclination to do that
> out there.
> 
> 
> Funny anecdote...tangentially related to the topic at best...
> 
> Was working with RedBack today (our SMS 500 decided to reboot with
> *alarming* regularity) and at one point, dude at RedBack asked me if we
> had anyone connecting with l2tpd as the LAC to our SMS as the LNS.  I
> kinda chuckled and said, "yeah...a few."  He said that some of the
> versions of AOS on the RedBack's had trouble with some things that l2tpd
> did.  I chuckled again and said, "Can you get me details?  You see..."
> and then I promptly when on to explain the situation as it exists wrt to
> l2tpd.  Dude laughed and said he'd put me in touch with one of their
> developers about it ASAP.  Turns out that it was purely a bug in AOS,
> and was not anything l2tpd was doing wrong (which kinda surprised me!),
> but that the developer would certainly keep my name and email on hand
> for any other issues that come up.  :)
> -- 
> Jeff McAdams                            Email: je...@ig...
> Head Network Administrator              Voice: (502) 966-3848
> IgLou Internet Services                        (800) 436-4456
> 
> _______________________________________________
> L2tpd-devel mailing list
> L2t...@li...
> https://lists.sourceforge.net/lists/listinfo/l2tpd-devel
> 

Also sprach Scott Balmos
>http://prdownloads.sourceforge.net/l2tpd/l2tpd-0.64.tar.gz (apparently
>the file release area says the release exists, but no files are
>added...  It's there, believe me)

Yup, confirmed...the files are there.  May have just taken the
sourceforge pages some time to update behind the scenes or something
*shrug*

>I would *really* love to take this thing farther, and I know it'll
>continue to do so... But should I be the project maintainer if I can't
>even really follow the code?

There's more to being a project maintainer than just coding on the
software...though that's really not an answer to your question.

>Does anyone else out there want to become a project manager? At the
>moment, Jeff is our Alan Cox, as I like to call him. He deals with the
>bugfixes and all that fun. But really I think there needs to be a
>complete rewrite, audit, whatever you want to call it, that puts us
>into the kernelspace. This CVS tree has been set up for a long while,
>as l2tpd-devel, and was to be the 0.7 tree (devel releases would be
>like 0.701, and 0.71 through 0.75 would be matching the functionality
>of the existing 0.6 tree). That, unfortunately, is completely out of my
>realm (reentrant kernel code scares me. :D), and as Jeff said, he only
>has about the first 20 lines of the kernel module template.

>We need a project manager that can spearhead the bleeding edge 0.7
>rewrite... Anyone??? :)

If noone else steps up to the plate...I could probably take on a more
active role.  It'd be nice to have someone that has a little more time
to put into it than I have as well...though I realize that there just
plain may not be someone that has the time and inclination to do that
out there.

Funny anecdote...tangentially related to the topic at best...

Was working with RedBack today (our SMS 500 decided to reboot with
*alarming* regularity) and at one point, dude at RedBack asked me if we
had anyone connecting with l2tpd as the LAC to our SMS as the LNS.  I
kinda chuckled and said, "yeah...a few."  He said that some of the
versions of AOS on the RedBack's had trouble with some things that l2tpd
did.  I chuckled again and said, "Can you get me details?  You see..."
and then I promptly when on to explain the situation as it exists wrt to
l2tpd.  Dude laughed and said he'd put me in touch with one of their
developers about it ASAP.  Turns out that it was purely a bug in AOS,
and was not anything l2tpd was doing wrong (which kinda surprised me!),
but that the developer would certainly keep my name and email on hand
for any other issues that come up.  :)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

On Tue, 15 Jan 2002, Jeff Mcadams wrote:

[ good points about the ip-up scripts and ppp-options etc snipped ]

> Ah!  I remember part of the problem if I remember it correctly.  W2k
> doesn't expect a transport mode SA.  It uses L2TP over *tunnel* mode
> IPSec if I remember correctly!  Why?  I haven't a clue...why does MS do
> half of the stuff they do?

Nah, it's definitely transport mode.

If it was tunnel mode you could NAT it without a problem.. which you can't.

-- 
  Eric Sorenson - Systems / Network Administrator - Transmeta Corporation

Also sprach Eric Sorenson
>On Tue, 15 Jan 2002, Jeff Mcadams wrote: It's also not necessary.
>Luckily Unix is pretty reasonable and makes this sort of stuff easy by
>following its own rules. The routing table gets consulted at each stage
>of the encapsulation and it's OK if the destination is another
>pseudo-device on the same machine.

OK...I knew l2tpd basically abided by this, but I wasn't sure about
IPSec processing as I know sometimes implementations will grovel around
in the IP code of the OS so I didn't know how hairy it was
there...sounds like FreeS/WAN is reasonable about that, so we should be
able to take some steps to be able to "productize" it eventually, like
you said.  :)  (good word, "productize" :)

>l2tpd/pppd:
>- explore making the username/password entry 'interactive'

I think this is doable from l2tpd...not sure about password, but we
should be able to "prompt" (in some fashion) for the userid at least.
It doesn't look like pppd can take a password on the command line (which
is not unreasonable), so we would need to think of a different way of
handling that.

>- make configurable the route that gets added, the only option
>  i found in pppd now is the defaultgateway / nodefaultgateway,
>  which isn't quite right.

That's doable with the scripts that are run (/etc/ppp/ip-up and
/etc/ppp/ip-down I believe is what pppd runs) when the PPP session comes
up and down.  Not quite as configurable (actually....it might end up
being easier depending on how the config tool works....debian's setup
with ip-up.d and ip-down.d is a nice setup for this) but it should be
able to be done.

>freeswan:
>- had to patch freeswan to use x.509 certs from www.strongsec.com
>- had to patch freeswan not to crap out on last QM phase2 message
>  (this is xedia-specific strangeness I think) changed FALSE to TRUE
>  in freeswan-1.94/pluto/ipsec_doi.c:1835 check_net_id() routine
>- fix _updown shell script to add the proper route for transport mode
>  connections (should be to 'right's IP through /dev/ipsec0, not to
>  'rightsubnet' through 'right')

*watches this sale over his head due to lack of knowledge about
FreeS/WAN and IPSec*

>I'll work on pulling the requisite changes together in a patch/RPM as I
>set up more systems, to make this easier on others. Dunno about using
>it against a W2K server, but I suspect the IPSEC transport-mode
>negotiation wouldn't succeed; w2k expects a more specific SA than
>freeswan can currently negotiate (transport mode, any protocol, port
>1701).  I will try to set a w2k server up to test this.

Ah!  I remember part of the problem if I remember it correctly.  W2k
doesn't expect a transport mode SA.  It uses L2TP over *tunnel* mode
IPSec if I remember correctly!  Why?  I haven't a clue...why does MS do
half of the stuff they do?

Unfortunately, I'm like you in that I don't have a setup where I can
test this in any way.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

On Tue, 15 Jan 2002, Jeff Mcadams wrote:

> Also sprach Eric Sorenson
> [FreeS/WAN with l2tpd]
>
> >It works pretty well with freeswan, I got it working in "Win2K
> >Emulation Mode" last month.
>
> Wow...how did I miss that message on the list?  Amazing.

It was sort of buried.. I was suprised that nobody commented though :-)

> Anyway...that's good to know that it works.  Have you run across anyone
> that has this type of setup interoperating with w2k itself?  That'd be
> nice to confirm.  :)

From groveling through both this list and freeswan-users archives, I
don't think anybody else has gotten that far.

> Kinda my thinking as well...but I really didn't know enough about IPSec
> to comment intelligently on it.  I didn't know if there were FreeS/WAN
> libs or something that we could build into l2tpd to leverage their work
> in ours.
>
> Something like that would be cool, but I fear that its not terribly
> practical given the nature of the things that we're dealing with here.

It's also not necessary. Luckily Unix is pretty reasonable and makes
this sort of stuff easy by following its own rules. The routing table
gets consulted at each stage of the encapsulation and it's OK if the
destination is another pseudo-device on the same machine.

packet destined through tunnel -> 'ip ro add 10/8 dev ppp0' -> l2tpd ->
l2tpd encap. to other endpoint -> 'ip ro add end.poi.n.t/32 dev ipsec0' ->
freeswan SA match for end.poi.n.t/32 proto0/port0 -> crypto via klips ->
ipsec encap. to other endpoint -> 'ip ro add default via gat.ew.a.y dev eth0'

> It may ultimately just be best to have good documentation on the
> integration of the two components, work with distro vendors so that
> their tools can support configuration of FreeS/WAN and l2tpd better, and
> maybe working with the two packages to make the integration easier to
> begin with.  I'm all ears for suggestions on the latter for the l2tpd
> side of things.

It's pretty far from being "productized" at this point. I'm working on
making a little easier to set up though, because there are more people
who want to use it internally here, and it's kind of painful to setup a
a new person up now. No particular order, but here are some todos/q's:

l2tpd/pppd:
- explore making the username/password entry 'interactive'
- make configurable the route that gets added, the only option
  i found in pppd now is the defaultgateway / nodefaultgateway,
  which isn't quite right.

freeswan:
- had to patch freeswan to use x.509 certs from www.strongsec.com
- had to patch freeswan not to crap out on last QM phase2 message
  (this is xedia-specific strangeness I think) changed FALSE to TRUE
  in freeswan-1.94/pluto/ipsec_doi.c:1835 check_net_id() routine
- fix _updown shell script to add the proper route for transport mode
  connections (should be to 'right's IP through /dev/ipsec0, not to
  'rightsubnet' through 'right')

I'll work on pulling the requisite changes together in a patch/RPM
as I set up more systems, to make this easier on others. Dunno about
using it against a W2K server, but I suspect the IPSEC transport-mode
negotiation wouldn't succeed; w2k expects a more specific SA than
freeswan can currently negotiate (transport mode, any protocol, port 1701).
I will try to set a w2k server up to test this.

-=Eric

Also sprach Eric Sorenson
[FreeS/WAN with l2tpd]

>It works pretty well with freeswan, I got it working in "Win2K
>Emulation Mode" last month.

Wow...how did I miss that message on the list?  Amazing.

Anyway...that's good to know that it works.  Have you run across anyone
that has this type of setup interoperating with w2k itself?  That'd be
nice to confirm.  :)

>Putting IPSEC-related code into l2tpd itself would be pointless and
>disastrous IMO. It's really hard to do well and is totally orthogonal
>to the l2tpd functionality.

Kinda my thinking as well...but I really didn't know enough about IPSec
to comment intelligently on it.  I didn't know if there were FreeS/WAN
libs or something that we could build into l2tpd to leverage their work
in ours.

Something like that would be cool, but I fear that its not terribly
practical given the nature of the things that we're dealing with here.

It may ultimately just be best to have good documentation on the
integration of the two components, work with distro vendors so that
their tools can support configuration of FreeS/WAN and l2tpd better, and
maybe working with the two packages to make the integration easier to
begin with.  I'm all ears for suggestions on the latter for the l2tpd
side of things.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

On Fri, 11 Jan 2002, Jeff Mcadams wrote:

> >* Add comments speculating where L2TP/IPSEC support might be included.
>
> Yeah...this is gonna be a major project coming down the pike...not sure
> it will be productive to put IPSec into l2tpd itself...although it may
> come to that eventually.  It'd be nice to not have to re-invent the
> wheel and just make it play nice with FreeS/WAN or something like that.

It works pretty well with freeswan, I got it working in "Win2K Emulation
Mode" last month. Putting IPSEC-related code into l2tpd itself would
be pointless and disastrous IMO. It's really hard to do well and is totally
orthogonal to the l2tpd functionality.

http://www.geocrawler.com/archives/3/10075/2001/12/0/7326069/

-=Eric

-- 
  Eric Sorenson - Systems / Network Administrator - Transmeta Corporation

http://prdownloads.sourceforge.net/l2tpd/l2tpd-0.64.tar.gz (apparently
the file release area says the release exists, but no files are added...
It's there, believe me)

I admit it... I finally broke down. :)

I guess we can consider this the first birthday release. Thanks to
everyone "out there" who've brought us this far. To be honest, I really
unfortunately haven't done much. At least Jeff has industry experience.
I'm really just a student who follows the discussion and matches it
against the chapters in about four L2TP reference books.

I would *really* love to take this thing farther, and I know it'll
continue to do so... But should I be the project maintainer if I can't
even really follow the code?

Does anyone else out there want to become a project manager? At the
moment, Jeff is our Alan Cox, as I like to call him. He deals with the
bugfixes and all that fun. But really I think there needs to be a
complete rewrite, audit, whatever you want to call it, that puts us into
the kernelspace. This CVS tree has been set up for a long while, as
l2tpd-devel, and was to be the 0.7 tree (devel releases would be like
0.701, and 0.71 through 0.75 would be matching the functionality of the
existing 0.6 tree). That, unfortunately, is completely out of my realm
(reentrant kernel code scares me. :D), and as Jeff said, he only has
about the first 20 lines of the kernel module template.

We need a project manager that can spearhead the bleeding edge 0.7
rewrite... Anyone??? :)

--
Scott Balmos
L2TPd maintainer / the ghosty shadow in the dark corner
sb...@us...

Hey folks...

When we do a release, we need to make sure that we increment the
FIRMWARE_REV in l2tp.h

I'm trying to debug some L2TP interaction issues right now, and I'm
seriously regretting that we haven't done that.  :/
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Also sprach Jeremy Lunn
>On Tue, Jan 08, 2002 at 12:49:57PM -0500, Jeff Mcadams wrote:
>> I really would like to get this code base into shape and useable, but
>> I'm just not a particularly impressive programmer on my own. 

>I'm not particularly an impressive programmer at all!  I hope to
>improve my programming skills but it's hard to find the time to learn
>more about it when I have to work, study for school, research other
>interesting topics etc.  It's all a matter of priorities though and
>I'll get there sooner or later.

Yeah, I know the feeling...I'm rather limited in the time that I have to
work on it as well.

>> Hah...yeah...why re-invent the wheel.  I've been toying with writing
>> a kernel module for L2TP support in Linux...I have all of about 20
>> lines

>Yeah I think that would be the most elegant solution.  This seems to be
>a similar goal to http://sourceforge.net/projects/l2tp.

Yeah...I think we're looking at it differently though.

I'm looking at writing what amounts to a PPP channel interface...at
least for the interface between l2tpd and pppd.  I'd also like, at some
point, to support a truer LAC type of functionality....ie, we take PPP
frames in off a serial port or modem and rather than feeding them
through the PPP channel interface to PPP, take them in through the PPP
channel interface to l2tpd.  Of course, we don't have this functionality
right now...so its no real loss to do a kernel implementation without
it, but I want to keep that in mind when designing the kernel interface.

>The only problem with doing a kernel implementation is making it build
>with different kernel versions (that may have various patches applied).
>Once code is actually accepted into the kernel source tree then it
>becomes far more useful and easier to use.

Yeah, and that hassle can be managed...you just have to stay on top of
it.

>Now I just have to get portslave working and see how well I can get
>this working with with RequestDSL.  It would be a good idea to ensure
>that portslave and l2tpd work together and I'm sure it can't be too
>difficult.  I'll probably write a howto when I've finished.

I am rather completely unfamiliar with portslave, so I don't know that I
can be much help in this part...but certainly let us know your success
and keep involved.

>And a few more thoughts on l2tpd:
>-  It would be nice to have a conffile more like portslave (but maybe
>   I just think that because I'm used to portslave).  In particular I
>   like the way how you configure pppd options in portslave although I
>   think the way how I have used the pppd 'file' option is quite a neat
>   work around.  In particular I don't like having boolean options for
>   setting pppd options.

Again, I'm totally unfamiliar with portslave, so that doesn't mean much
to me....I will agree that our conf file sucks swamp water through
straws though.  I've been pondering other possible formats, haven't
really had any bright ideas though.

>-  Perhaps when l2tp is completely kernel space it would an idea to only
>   have to configure portslave in userspace and adopt portslave to answer
>   r l2tp calls.  Although I'm sure some people won't want to use RADIUS
>   authentication and/or accounting.

*shrug*  Sounds cool...what little meaning that carried without knowing
how portslave works.  :)

>-  I have created a very basic l2tpd Debian package which is intended
>   for my own use but anyone is welcome to use it if they wish.
>   Eventually I'd like to put it into Debian.

Oh, *PLEASE* do this!  :)  I think one of the main things holding us
back right now is lack of exposure...

Neale's patch that I just committed are a perfect example of why more
exposure in a project like this is "A Good Thing(tm)".  The more
eyeballs, the quicker development happens.

I would *much* rather be more of a manager of patches rather than
crunching code all the time (again...considering that I'm not all that
fantastic of a coder), but it really hasn't been very practical to do
that up to this point.

>Thanks for those who have helped,

Thank *you*, and I look forward to more input from you and hopefully an
l2tpd package in sid!
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

2001	Jan	Feb (4)	Mar (13)	Apr (33)	May (10)	Jun (25)	Jul (30)	Aug (9)	Sep (9)	Oct (37)	Nov (11)	Dec (6)
2002	Jan (41)	Feb (7)	Mar (2)	Apr	May (1)	Jun (3)	Jul (1)	Aug	Sep (1)	Oct	Nov	Dec (1)
2003	Jan (1)	Feb (1)	Mar	Apr	May	Jun (1)	Jul (2)	Aug	Sep	Oct (1)	Nov	Dec (20)
2004	Jan	Feb (4)	Mar (1)	Apr (2)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec (1)
2005	Jan	Feb (4)	Mar (3)	Apr	May (2)	Jun (2)	Jul	Aug	Sep (5)	Oct	Nov	Dec
2006	Jan	Feb (3)	Mar	Apr	May (3)	Jun	Jul	Aug	Sep	Oct	Nov (5)	Dec

S	M	T	W	T	F	S
		1 (1)	2	3	4	5
6	7 (3)	8 (4)	9 (5)	10	11 (4)	12
13	14 (1)	15 (7)	16 (4)	17	18 (8)	19 (2)
20	21 (1)	22	23	24	25 (1)	26
27	28	29	30	31

l2tpd-devel Mailing List for L2TP client / daemon

l2tpd-devel — L2TPd developement discussion