l2tp-develop — L2TP Project Development Mailing List

[L2tp-develop] FASD project: Online survey launched

[Benno L. <ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I
kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The
questionnaire consists of 53 questions and you will need about 15 minutes to
complete it.

With the FASD project (Fun and Software Development) we want to define the
motivational significance of fun when software developers decide to engage
in Open Source projects. What is special about our research project is that
a similar survey is planned with software developers in commercial firms.
This procedure allows the immediate comparison between the involved
individuals and the conditions of production of these two development
models. Thus we hope to obtain substantial new insights to the phenomenon of
Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under
http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please
see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this
mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[L2tp-develop] Re: L2TP

[Bill B. <bba...@sp...>]

Excellent job with the channel stuff!


What happens when LNS negotiates LCP?  It may or may not use the LCP hints
sent by LAC during session creation.  Or iIt can optionally send a SLI
message to the LAC to inform of new physical paramters.  The client will
of course change, can we be sure that ppp will still operate if the LAC
doesn't change to match?  MTU could cause real problems.

Even if the SLI message could be counted on, the LNS could quite
legitimately negotiate something that the LAC could not handle.  
Basically ppp options set appropriate for the hardware setup on the LAC
can be ignored on the LNS.

I think the LAC's LCP sniffing, while a painful exercise, adds quality to
the system.  

To avoid the LCP's scenic tours on the LAC, perhaps a bit of the LCP code
could be embedded in the channel driver...  As I recall the code is pretty
straight forward.

Bill



On Thu, 7 Feb 2002, Simon Hughes wrote:

> Hi there
> 
> Here are some more thoughts
> 
> >
> >
> >On Tue, 22 Jan 2002, Simon Hughes wrote:
> >
> >> >2)  LCP is considered data as far as L2TP is concerned.  In passthrough
> >> >mode, client sourced LCP traverses LAC pppd and is examined for
> >> >acceptability.  If ok, it is forwarded via pipe to l2tpd and from there
> >> >transmitted to the LNS using the APP_DATA_XMTR_tx_data interface.  So
> >> >unfortunately, it is required!
> >> >
> >> >I hope this doesn't shoot too big a hole in things!
> >>
> >> In the new implementation, all LCP packets are considered data and
> therefore
> >> received on a session.
> >>
> >> If there is no cut through then the packet will be passed to pppd at
> >> ppp_generic.c::ppp_input, which will determine that the packet is lcp and
> >> indicate it up to PPPD. It is then up to PPPD to processes it as it sees
> >> fits. Your ppp/pppd/l2tp.c code will need to be repackaged for this case.
> >>
> >> If there is a cut through configured then the skb is forwarded directly
> to
> >> the output device using dev_queue_xmit(), which passes the skb to
> >> dev->hard_start_xmit.
> >
> >Sounds fine, except it sounds as if both client LCP and LNS LCP will go
> >through the same path during passthrough mode.  Either there needs to be a
> >distinct path, or the frame somehow marked so that pppd can determine if
> >client or LNS sent the message.
> 
> I hacked lac_pppd to interwork with my_lacd so I could test that
> my_l2tp_driver support of tunnels and sessions. my_lacd returns the
> ppp_channel_index of the new l2tp session to my_lac_pppd in the open_rsp
> msg. Then
> 
> my_lac_pppd opens file descriptor ppp_chan_fd=open(a new /dev/ppp),
> ioctl(ppp_chan_fd, PPPIOCATTACHCHAN on the ppp_channel
> read(ppp_chan_fd)
> 
> instead of reading lcp packets from the lacd<->lac_pppd message pipe. Thus
> there are still 2 distinct paths.
> 
> >
> >The same problem exists in reverse, when pppd forwards LCP to client or to
> >LNS, some differentiation must occur so that the kernel can know to
> >forward it appropriately.
> >
> >We could use a different protocol.  Twiddle a higher order bit in the
> >protocol field to mark it to/from LNS.  That would work until someone
> >comes along and uses that protocol value for something else.  Perhaps
> >making the protocol value assignable by pppd would work.  An option could
> >overide the default in case is gets used for something.  Anyway just a
> >thought.
> 
> 
> 
> Your basic premise here is that lac_pppd has to play 'pig in the middle'
> monitoring lcp packets between the client and the lns. You say that this has
> to be done to guard against a badly configured LNS. I dont think this is a
> good enough reason for such a tortuous path for lcp packets. If the LNS is
> poorly configured then appropriate status should be logged and the
> connection not come up.
> 
> I have a basic problem with this approach of monitoring end-to-end packets.
> There should be no 'pig in the middle'. Once the ppp packets are being sent
> on the l2tp session ppp_channel, a new round of LCP should optionally take
> place and then lac_pppd should get out of the way. The end to end connection
> has then been established.
> 
> 
> Maybe there is something I dont understand ?
> 
> Simon
> 
> 
> 
> 
> 
> 
> 

[L2tp-develop] Re: L2TP

[Simon H. <sd...@ab...>]

Hi there

Here are some more thoughts

>
>
>On Tue, 22 Jan 2002, Simon Hughes wrote:
>
>> >2)  LCP is considered data as far as L2TP is concerned.  In passthrough
>> >mode, client sourced LCP traverses LAC pppd and is examined for
>> >acceptability.  If ok, it is forwarded via pipe to l2tpd and from there
>> >transmitted to the LNS using the APP_DATA_XMTR_tx_data interface.  So
>> >unfortunately, it is required!
>> >
>> >I hope this doesn't shoot too big a hole in things!
>>
>> In the new implementation, all LCP packets are considered data and
therefore
>> received on a session.
>>
>> If there is no cut through then the packet will be passed to pppd at
>> ppp_generic.c::ppp_input, which will determine that the packet is lcp and
>> indicate it up to PPPD. It is then up to PPPD to processes it as it sees
>> fits. Your ppp/pppd/l2tp.c code will need to be repackaged for this case.
>>
>> If there is a cut through configured then the skb is forwarded directly
to
>> the output device using dev_queue_xmit(), which passes the skb to
>> dev->hard_start_xmit.
>
>Sounds fine, except it sounds as if both client LCP and LNS LCP will go
>through the same path during passthrough mode.  Either there needs to be a
>distinct path, or the frame somehow marked so that pppd can determine if
>client or LNS sent the message.

I hacked lac_pppd to interwork with my_lacd so I could test that
my_l2tp_driver support of tunnels and sessions. my_lacd returns the
ppp_channel_index of the new l2tp session to my_lac_pppd in the open_rsp
msg. Then

my_lac_pppd opens file descriptor ppp_chan_fd=open(a new /dev/ppp),
ioctl(ppp_chan_fd, PPPIOCATTACHCHAN on the ppp_channel
read(ppp_chan_fd)

instead of reading lcp packets from the lacd<->lac_pppd message pipe. Thus
there are still 2 distinct paths.

>
>The same problem exists in reverse, when pppd forwards LCP to client or to
>LNS, some differentiation must occur so that the kernel can know to
>forward it appropriately.
>
>We could use a different protocol.  Twiddle a higher order bit in the
>protocol field to mark it to/from LNS.  That would work until someone
>comes along and uses that protocol value for something else.  Perhaps
>making the protocol value assignable by pppd would work.  An option could
>overide the default in case is gets used for something.  Anyway just a
>thought.



Your basic premise here is that lac_pppd has to play 'pig in the middle'
monitoring lcp packets between the client and the lns. You say that this has
to be done to guard against a badly configured LNS. I dont think this is a
good enough reason for such a tortuous path for lcp packets. If the LNS is
poorly configured then appropriate status should be logged and the
connection not come up.

I have a basic problem with this approach of monitoring end-to-end packets.
There should be no 'pig in the middle'. Once the ppp packets are being sent
on the l2tp session ppp_channel, a new round of LCP should optionally take
place and then lac_pppd should get out of the way. The end to end connection
has then been established.


Maybe there is something I dont understand ?

Simon

[L2tp-develop] (no subject)

[Simon H. <sd...@ab...>]

I found that just commenting out the line of the udp port compare on the lns
makes the problem go away.

Simon

-----Original Message-----
From: Simon Hughes <sd...@ab...>
To: l2t...@li... <l2t...@li...>
Cc: Bill Baumann <bba...@sp...>
Date: Thursday, February 07, 2002 3:01 PM
Subject: Re: [L2tp-develop] lns only likes 1 peer udp port


>Hi Bill
>
>Regarding this point:
>
>>
>>
>>
>>>There is a problem however.  Peer's UDP port is derived solely from the
>>>configuration file.  It should be fixed only when explicitedly specified
>>>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>>>message should used.  This is an easy fix.
>>>
>>
>>Thanks for this. I'll try it today.
>>
>
>
>Sorry. I misunderstood your mail. I thought that if I set peer_udp = 0 in
>lacd.conf for the peer "lns" then this would sort the problem. When I tried
>this it didn't make any difference. There was a message in the lns
>/var/log/lacd.log to the effect:
>
>Error: Invalid value, must be between 1 and 65536
>Error: Occurred with the category 'peer' named venus.cam.xstreamis.co.uk
>Error: Last line read '  our_udp = 0'
>
>Simon
>
>
>_______________________________________________
>L2tp-develop mailing list
>L2t...@li...
>https://lists.sourceforge.net/lists/listinfo/l2tp-develop

Re: [L2tp-develop] lns only likes 1 peer udp port

[Simon H. <sd...@ab...>]

Hi Bill

Regarding this point:

>
>
>
>>There is a problem however.  Peer's UDP port is derived solely from the
>>configuration file.  It should be fixed only when explicitedly specified
>>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>>message should used.  This is an easy fix.
>>
>
>Thanks for this. I'll try it today.
>


Sorry. I misunderstood your mail. I thought that if I set peer_udp = 0 in
lacd.conf for the peer "lns" then this would sort the problem. When I tried
this it didn't make any difference. There was a message in the lns
/var/log/lacd.log to the effect:

Error: Invalid value, must be between 1 and 65536
Error: Occurred with the category 'peer' named venus.cam.xstreamis.co.uk
Error: Last line read '  our_udp = 0'

Simon

Re: [L2tp-develop] lns only likes 1 peer udp port

[Simon H. <sd...@ab...>]

>QUESTION TO THE GROUP:  Is having multiple tunnels per peers an important
>feature?


Yes.

Redback have the capability to switch tunnels at their box to produce
something like the switching of traffic from 1 ingress tunnel onto a
different egress tunnel. A corporate could aggregate traffic onto two
different tunnels both destined for the 'tunnel switch' so that  the traffic
from each tunnel would be treated differently at the switch. The Redback
site is a good source of information in this.


>The idea is actually quite reasonable.  There really aren't any good
>reasons to have multiple tunnels between peers.  The session creation

I disagree with your comment here.


> Is having RADIUS controlled quality of service
>important?

Yes.

I see RADIUS as the service selection mechanism. If you look at the
freeRADIUS project, there is a range of Redback defined TLVs for
implementing this kind functionality. I'd like to see a range of TLVs
defined within the freeRadius project which can be passed to the L2TP LAC to
determine tunnel characteristics. Some are already in place.



When it comes to the use of udp ports, the guiding principle should be the
rfc:

RFC 2661 (L2TP) Remarks on L2Tp over UDP

8.1 L2TP over UDP/IP

L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet,
including payload and L2TP header, is sent within a UDP datagram. The
initiator of an L2TP tunnel picks an available source UDP port (which may or
may not be 1701), and sends to the desired destination address at port 1701.
The recipient picks a free port on its own system (which may or may not be
1701), and sends its reply to the initiator's UDP port and address, setting
its own source port to the free port it found. Once the source and
destination ports and addresses are established, they MUST remain static for
the life of the tunnel.

Thus, each tunnel can have its own socket with its own locally assigned udp
port.

Your implementation operates within the rfc but precludes the flexibility
afforded by allowing the client/servers to choose their own ports, in the
time honoured tradition of sockets programming.



>There is a problem however.  Peer's UDP port is derived solely from the
>configuration file.  It should be fixed only when explicitedly specified
>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>message should used.  This is an easy fix.
>

Thanks for this. I'll try it today.

Simon

-----Original Message-----
From: Bill Baumann <bba...@sp...>
To: l2t...@li... <l2t...@li...>;
Simon Hughes <sd...@ab...>
Date: Wednesday, February 06, 2002 8:54 PM
Subject: Re: [L2tp-develop] lns only likes 1 peer udp port


>
>QUESTION TO THE GROUP:  Is having multiple tunnels per peers an important
>feature?  Also stated; Is having RADIUS controlled quality of service
>important?
>
>Simon's question brings up a limitation in the software.  Currently,
>only a single tunnel is allowed between peers.
>
>The issue goes back to confusion from the RFC.  Currently, the software
>allows only a single tunnel between peers.  The confusion lies in the tie
>breaker mechanism.  Should LAC and LNS both try to create a new tunnel at
>the same time, the tie breaker mechanism arbitrates a single tunnel.  I
>misinterpreted this to indicate that LAC and LNS should have only a single
>tunnel between them always.
>
>The idea is actually quite reasonable.  There really aren't any good
>reasons to have multiple tunnels between peers.  The session creation
>mechanism should handle any quality of service information.
>Unfortunately, the RADIUS spec doesn't work that way...  Quality of
>service differentiation happens at the tunnel level.  If you want every
>session to behave slightly differently, they all need their own tunnels.
>
>The multiple tunnels between peers isn't a hard fix, but it is related to
>the tie breaker mechanism.  We have to make sure we don't introduce bugs
>in the process.
>
>
>Simon, getting back to you're original issue...
>
>This error shows up in the message log?  Its the same code for both 6.2
>and 7.1 and should behave identially on both.
>
>Actually, the comment is wrong (sort of).  The code here is actually
>correct.
>
>The snippet of code occurs for data packets only.  For data, the peer's
>UDP port must match that expressed by the signalling layer during tunnel
>creation.  To do otherwise would leave the system more vulernable to
>spoofing attacks.  This line of code should only execute when receiving a
>frame that matches the Tunnel ID and IP address, but with a UDP port that
>doesn't.
>
>There is a problem however.  Peer's UDP port is derived solely from the
>configuration file.  It should be fixed only when explicitedly specified
>to a non-zero value.  If zero (any port), the source port of the SCCRQ
>message should used.  This is an easy fix.
>
>Bill Baumann
>
>
>
>On Wed, 6 Feb 2002, Simon Hughes wrote:
>
>> Hi Bill
>>
>> I have my driver working but I'm running into problems with the RH 6.2
LNS.
>>
>> My re-write of data_xmtr.c uses sockets, one socket on udp 1701 for
>> listening and then 1 socket per created tunnel. All l2tp data packets are
>> sent on the socket for the appropriate tunnel. This causes a problem for
the
>> RH 6.2 LNS. because of the following in data_xfer.c:
>>
>>
>>       /* I think the peer is allowed to change his UDP address in his
first
>> msg... */
>>       else if ( tun->peer_udp != peer_udp )
>>         {
>>           /* FIXME: some implementations may move source UDP port
>>            * to fix this, an interface needs to be created at data layer
>>            * and signaling layer connectors to allow transport to set the
>>            * udp address.  transport also has to be changed to something
>> like
>>            * in rx_ctrl, if known peer_udp == 0, use new port & tell data
>> layer. */
>>           L2TP_LOG_severe( ( "udp addresses do not match.  This could be
a
>> hack or an implementation problem, see code" ) );
>>           status = L2TP_STATUS_peer_udp_port_incorrect;
>>         }
>>
>>
>> Is this the same situation in the RH7.1 release? Any chance of fixing
this ?
>>
>> I need to come back to you RE the processing of lcp packets in
>> /ppp/pppd/l2tp.c (rej/nak ing certain packets). When I get a moment, I'll
>> respond.
>>
>> Simon
>>
>>
>> _______________________________________________
>> L2tp-develop mailing list
>> L2t...@li...
>> https://lists.sourceforge.net/lists/listinfo/l2tp-develop
>>
>>
>
>

Re: [L2tp-develop] lns only likes 1 peer udp port

[Bill B. <bba...@sp...>]

QUESTION TO THE GROUP:  Is having multiple tunnels per peers an important
feature?  Also stated; Is having RADIUS controlled quality of service
important?

Simon's question brings up a limitation in the software.  Currently,
only a single tunnel is allowed between peers.

The issue goes back to confusion from the RFC.  Currently, the software
allows only a single tunnel between peers.  The confusion lies in the tie
breaker mechanism.  Should LAC and LNS both try to create a new tunnel at
the same time, the tie breaker mechanism arbitrates a single tunnel.  I
misinterpreted this to indicate that LAC and LNS should have only a single
tunnel between them always.  

The idea is actually quite reasonable.  There really aren't any good
reasons to have multiple tunnels between peers.  The session creation
mechanism should handle any quality of service information.  
Unfortunately, the RADIUS spec doesn't work that way...  Quality of
service differentiation happens at the tunnel level.  If you want every
session to behave slightly differently, they all need their own tunnels.

The multiple tunnels between peers isn't a hard fix, but it is related to
the tie breaker mechanism.  We have to make sure we don't introduce bugs
in the process.


Simon, getting back to you're original issue...

This error shows up in the message log?  Its the same code for both 6.2
and 7.1 and should behave identially on both.

Actually, the comment is wrong (sort of).  The code here is actually
correct.

The snippet of code occurs for data packets only.  For data, the peer's
UDP port must match that expressed by the signalling layer during tunnel
creation.  To do otherwise would leave the system more vulernable to
spoofing attacks.  This line of code should only execute when receiving a
frame that matches the Tunnel ID and IP address, but with a UDP port that
doesn't.

There is a problem however.  Peer's UDP port is derived solely from the
configuration file.  It should be fixed only when explicitedly specified
to a non-zero value.  If zero (any port), the source port of the SCCRQ
message should used.  This is an easy fix.

Bill Baumann



On Wed, 6 Feb 2002, Simon Hughes wrote:

> Hi Bill
> 
> I have my driver working but I'm running into problems with the RH 6.2 LNS.
> 
> My re-write of data_xmtr.c uses sockets, one socket on udp 1701 for
> listening and then 1 socket per created tunnel. All l2tp data packets are
> sent on the socket for the appropriate tunnel. This causes a problem for the
> RH 6.2 LNS. because of the following in data_xfer.c:
> 
> 
>       /* I think the peer is allowed to change his UDP address in his first
> msg... */
>       else if ( tun->peer_udp != peer_udp )
>         {
>           /* FIXME: some implementations may move source UDP port
>            * to fix this, an interface needs to be created at data layer
>            * and signaling layer connectors to allow transport to set the
>            * udp address.  transport also has to be changed to something
> like
>            * in rx_ctrl, if known peer_udp == 0, use new port & tell data
> layer. */
>           L2TP_LOG_severe( ( "udp addresses do not match.  This could be a
> hack or an implementation problem, see code" ) );
>           status = L2TP_STATUS_peer_udp_port_incorrect;
>         }
> 
> 
> Is this the same situation in the RH7.1 release? Any chance of fixing this ?
> 
> I need to come back to you RE the processing of lcp packets in
> /ppp/pppd/l2tp.c (rej/nak ing certain packets). When I get a moment, I'll
> respond.
> 
> Simon
> 
> 
> _______________________________________________
> L2tp-develop mailing list
> L2t...@li...
> https://lists.sourceforge.net/lists/listinfo/l2tp-develop
> 
> 

[L2tp-develop] lns only likes 1 peer udp port

[Simon H. <sd...@ab...>]

Hi Bill

I have my driver working but I'm running into problems with the RH 6.2 LNS.

My re-write of data_xmtr.c uses sockets, one socket on udp 1701 for
listening and then 1 socket per created tunnel. All l2tp data packets are
sent on the socket for the appropriate tunnel. This causes a problem for the
RH 6.2 LNS. because of the following in data_xfer.c:


      /* I think the peer is allowed to change his UDP address in his first
msg... */
      else if ( tun->peer_udp != peer_udp )
        {
          /* FIXME: some implementations may move source UDP port
           * to fix this, an interface needs to be created at data layer
           * and signaling layer connectors to allow transport to set the
           * udp address.  transport also has to be changed to something
like
           * in rx_ctrl, if known peer_udp == 0, use new port & tell data
layer. */
          L2TP_LOG_severe( ( "udp addresses do not match.  This could be a
hack or an implementation problem, see code" ) );
          status = L2TP_STATUS_peer_udp_port_incorrect;
        }


Is this the same situation in the RH7.1 release? Any chance of fixing this ?

I need to come back to you RE the processing of lcp packets in
/ppp/pppd/l2tp.c (rej/nak ing certain packets). When I get a moment, I'll
respond.

Simon

[L2tp-develop] Lac working against cisco 3600

[Simon H. <sd...@ab...>]

Hi there

I have the lac and new driver working against a cisco 3600. This is the
trace from the cisco box.


cisco_2>show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name   State  Remote Address  Port  Sessions
18867 1     venus.cam.xst est    170.111.42.140  1024  1

LocID RemID TunID Intf          Username               State  Last Chg
Fastswitch
4     1     18867 Vi1                                  est    00:00:35
enabled

%No active L2F tunnels

%No active PPTP tunnels

%No active PPPoE tunnels
cisco_2>show vpdn


Simon

[L2tp-develop] New release!

[Bill B. <bba...@sp...>]

I have just released a new source tar supporting LNS, 2.4.2-2 and 2.4.7-10
kernels.  It is available at http://sourceforge.net/projects/l2tp.

Performance numbers look good too!

Bill Baumann (bba...@sp...)

[L2tp-develop] Hello

[<fo...@wa...>]

Hello bill,
I'm looking forward for your new l2tp devs
running under 2.4.x kernel series.
Did you develop a new pppox-based architecture
or is the design the same ?
As i had no time since i gave up porting your
project under 2.4.x, i did not follow l2tp
closely. The only information i have is that
simon hughes has a version which seems to work
for rh7.1, 2.4.2 kernel. I did not test his patches.
I know you plan to deliver a version for the end
of the week, would it be possible to get tarballs
of your work so far now ?
I'm looking really forward to see the code.
Thanks in advance.
Fran=E7ois.

[L2tp-develop] Re: Welcome to the "L2tp-develop" mailing list

[Bill B. <bba...@sp...>]

Hello and welcome to the L2TP mailing list.

Just a word on current status.  The latest release is due by the end of
this week and will include support for LNS and 2.4.x operating systems.

Thanks and welcome aboard!
Bill Baumann