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