[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