l2tpd-devel — L2TPd developement discussion

Re: [L2tpd-devel] Call/Session flow control commit

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

Also sprach Jeff Mcadams
>So...summary is that it touched six files (yikes!)

OK, so I lied...it was actually seven files...the rest of the message
was all correct.  :)

-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] Call/Session flow control commit

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

OK...confirmed interoperability with both the Cisco 3000 VPN
Concentrator and our RedBack SMS 500 with the changes for taking flow
control out on the call/sessions.

So...summary is that it touched six files (yikes!), but seems to work
with at least the above two pieces of equipment.  I *think* based on my
reading of the code that its conceptually correct too, at least this
specific aspect of it.  There are, no doubt, other bugs still there,
even relating to handling of sequence numbers and such on
calls/sessions, but at least this is one thing cleaned up.

Anyway...the commit has been done, so let me know if you see anything
wiggy with it.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] Try this out...

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

OK...did some research...

Early drafts of L2TP had flow control for the actual data channel...at
draft-13, they ripped that out and put it in its own draft that, to the
best I can tell, just died, so now the L2TP spec doesn't call for flow
control on the data channel which is why RWS AVPs don't belong in ICCN's
and similar message types.

The Cisco 3000 Altiga thingy, is really anal about L2TP protocol
processing, and is very up to date on the L2TP protocol.  The Redback
apparently is rather more lenient...or perhaps recognizes the RWS AVP in
an ICCN and falls back into a backward compatibility mode from what I
can tell so it can interoperate with pre-draft-13 l2tp implementations.

I've gone through, and assuming I got everything right (I'll be
impressed if I did), I *think* I pretty much ripped out all of the flow
control processing on the data channels, which *should* bring l2tpd up
to date with the current L2TP spec regarding this issue.

I've attached a tarball of this...I don't want to commit it to CVS until
I have some idea that it at least basically works with both the Cisco
3000, and the RedBack as it involves some rather significant edits to
quite a few files.

If you all could give this a try and see if it works, I'd appreciate it.

Thanks!
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Re: [L2tpd-devel] CVS commits today

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

Also sprach Scott Balmos
>Unfortunately commenting out the RWS handler creates major hell when
>connecting with Redbank routers (ahem...). Notice that the RWS reported
>for such a connection is -1. ;) The call completes and PPPd fires up.
>But final PPP negotiations can never be completed because every
>received packet is treated as an invalid payload.

Uhm...now I'm confused...the only thing I changed was to comment out the
call to add the rws avp to the ICCN, which...the spec says that rws
shouldn't be negotiated on sessions/calls *at all*, its only included in
the control connection.  Besides...it doesn't change the rws set for a
call/session...indeed, there *isn't* or *shouldn't* be an rws on a
call/session at all.

>I'll put this on one of the more critical areas to try and patch up.
>Until then, I think we may have to revert back to the old diff for a
>little bit.  :/

OK...I'm gonna play with it a bit and see what the RedBack barfs
about...
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

RE: [L2tpd-devel] CVS commits today

[Scott B. <sb...@ig...>]

Unfortunately commenting out the RWS handler creates major hell when
connecting with Redbank routers (ahem...). Notice that the RWS reported for
such a connection is -1. ;) The call completes and PPPd fires up. But final
PPP negotiations can never be completed because every received packet is
treated as an invalid payload.

I'll put this on one of the more critical areas to try and patch up. Until
then, I think we may have to revert back to the old diff for a little bit.
:/

--Scott

-----Original Message-----
From: l2t...@li...
[mailto:l2t...@li...]On Behalf Of Jeff
Mcadams
Sent: Tuesday, March 06, 2001 5:51 PM
To: l2t...@li...
Subject: [L2tpd-devel] CVS commits today


Did some CVS commits today...

Was working with an acquaintance on getting l2tpd connecting to a Cisco
3000 (formerly Altiga I believe) VPN concentrator.  The 3000 is fairly
anal about its protocol processing which revealed some errors in our
handling of the l2tp protocol...mainly sending avps in control messages
where they are invalid.

I *think* we've found all the ones that cause interoperability problems
with the Cisco 3000...but I'm pretty sure there are more out there, so I
added one or two things to the TODO file referencing the need to find
and fix other similar problems.

I'll do an audit at some point of what AVPs we send at various times in
various control packets and make sure, at least, that they're all valid.
I'd also like to confirm that the values that we send make sense in
them, but that's rather a more significant thing to audit.
--
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

_______________________________________________
L2tpd-devel mailing list
L2t...@li...
http://lists.sourceforge.net/lists/listinfo/l2tpd-devel

[L2tpd-devel] CVS commits today

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

Did some CVS commits today...

Was working with an acquaintance on getting l2tpd connecting to a Cisco
3000 (formerly Altiga I believe) VPN concentrator.  The 3000 is fairly
anal about its protocol processing which revealed some errors in our
handling of the l2tp protocol...mainly sending avps in control messages
where they are invalid.

I *think* we've found all the ones that cause interoperability problems
with the Cisco 3000...but I'm pretty sure there are more out there, so I
added one or two things to the TODO file referencing the need to find
and fix other similar problems.

I'll do an audit at some point of what AVPs we send at various times in
various control packets and make sure, at least, that they're all valid.
I'd also like to confirm that the values that we send make sense in
them, but that's rather a more significant thing to audit.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Re: [L2tpd-devel] Odd tunnel behavior

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

Also sprach Scott Balmos
>One thing to possibly begin looking into, and I think this might be a
>problem with some control packets somewhere... A few times, including
>today, I have noticed that L2TPd is connected to the LNS, PPPd is
>running fine in the background, and a default route over the tunnel to
>the LNS has been activated in the routing table. However, no data ever
>gets passed through the tunnel. Even pinging the IP address of the
>other end of the tunnel producees a timeout.

>Any ideas here before I start rummaging around in the code?

Maybe snag a tcpdump of the l2tp traffic.  Should be able to run tcpdump
on the ethernet interface specifying only traffic to/from the LNS IP
address.  If you wanna tell tcpdump to write the traffic out to a file,
you can then pull it up in ethereal and be able to look at just about
everything with the traffic and see what's going on.  That'll at least
give us an idea of what its putting out on the wire, which might give us
and idea of what's going on without digging into the code too much.  :)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] Odd tunnel behavior

[Scott B. <sb...@ig...>]

Hi everyone out there,

One thing to possibly begin looking into, and I think this might be a
problem with some control packets somewhere... A few times, including today,
I have noticed that L2TPd is connected to the LNS, PPPd is running fine in
the background, and a default route over the tunnel to the LNS has been
activated in the routing table. However, no data ever gets passed through
the tunnel. Even pinging the IP address of the other end of the tunnel
producees a timeout.

Any ideas here before I start rummaging around in the code?

--Scott

[L2tpd-devel] 0.61 package released

[Scott B. <sb...@ig...>]

'afternoon all,

Since I had the day off, I decided to commit a few housekeeping changes to
CVS and then release a tarball of the current code as 0.61.

If you're too lazy to actually see it on our project main page, I suggest
going to your nearest neighborhood refrigerator and quickly guzzling down a
rather bubbly bottle of Coke.

::sighs:: From here on out, we're live and free game for everyone. So much
for the little secret of us being active again. ;)

--Scott

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

[L2tpd-devel] The road to 0.7

[Scott B. <sb...@ig...>]

Good evening all,

Sorry this is coming out roughly a week after Jeff's last code commits. I've
been dealing with starting statistics for state basketball Sectional
Tournaments, getting ready for a DC trip, blah blah blah... excuses excuses.
BTW, anyone happen to want a new retail-pacakged ATI All-In-Wonder Radeon
for about $200? I bought one on eBay, only to find a connection with a
friend who can get it for $150. LOL

Anyway... The PPPd shutdown code is nasty, I know, but we'll live with it
for now. Overall, pretty much every showstopper has been found and fixed.
I'd love to know, now, what unhandled attribute 47 or whatever it is when a
tunnel is created to Iglou. LOL

At this point, I think there needs to be a temporary reemphasis on
documenting the program's use and FAQ, etc. I noticed David started on it
already, and I'll start whacking on some of it myself.

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.

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. :)

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...

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.

And I'm STILL trying to figure out why our project summary page shows the
CVS as being empty. Oh well. Comments anyone on placing this roadmap up on
the docs area, and placing some of these tasks up in the to-do list?

Comments at all, or is it just me and I'm too dead at this hour to think
after homework? :)

--Scott

[L2tpd-devel] l2tpd in CVS needed?

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

Any need for the l2tpd (the compiled binary) file in CVS?  Seems
reasonable to remove that file, though not a big deal one way or the
other.

I've been looking more at the call/session/tunnel shutdown code.  All I
can say is "ugh."  I think, eventually, it'll need to be ripped out and
completely replaced with something cleaner that takes into account the
upper layers.  Shutting down an individual call/session is not hard
(that's working now, with the couple of ugly hacks that I did), but
shutting down the calls/sessions by doing a disconnect on the whole
tunnel doesn't work cleanly.  Any thoughts on a procedure to handle this
cleanly?  I'm lazy, so I don't want to re-write any more than I have to,
so leveraging functions and structures that are already in the code is
good.  :)

Another thing I'd like to see done eventually...and this is not a big
deal...would be to see the terminology, comments, variable names, etc.
updated to match the RFC defining L2TP.  An example of that being the
call/session stuff.  The RFC calls them "sessions", l2tpd calls them
"calls."  Like I said...not a big deal, but might help in discussions
about what needs to be done to have a consistent terminology.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456