l2tpd-devel — L2TPd developement discussion

[L2tpd-devel] type mismatch for tunnelid, sessionid?

[Deja U. <ci...@my...>]

Hi,

Why do we have tunnelid (tid, ourtid in tunnel structure) and sessionid (cid, ourcid) defined as int while the control_hdr and payload_hdr have these as _u16?

citl

------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

Re: [L2tpd-devel] 0.63 released

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

Also sprach Scott Balmos
>In keeping with our tradition of a release once-a-month, along with our
>pile of fixes and additions, release 0.63 was posted a few moments ago
>(ooo...  exactly 3:45pm ET. Cool). As soon as I can figure out
>Freshmeat's system, heh, I'll post up an announcement there also.

Got the freshmeat thing covered.  If you'd like, we can see about
switching ownership of the record to you if you want to do it.  I'm fine
with posting the releases there if you'd like me to continue taking care
of it.

>I almost feel comfortable enough to actually show my head on the L2TP
>Working Group mailing list, and maybe even Mark Spencer's. Up until
>now, I've only been lurking and taking notes.

Heh...I've managed to go ahead and make some presense known there, but I
certainly welcome your presence as well.  :)

>Oh well... we'll see. Next up: Figuring out that damn little-endian
>problem.  ::collective groans from the crowd::

You have fun with that one.  :)  I have no great desire to tackle it.
:)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] 0.63 released

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

In keeping with our tradition of a release once-a-month, along with our pile
of fixes and additions, release 0.63 was posted a few moments ago (ooo...
exactly 3:45pm ET. Cool). As soon as I can figure out Freshmeat's system,
heh, I'll post up an announcement there also.

I almost feel comfortable enough to actually show my head on the L2TP
Working Group mailing list, and maybe even Mark Spencer's. Up until now,
I've only been lurking and taking notes.

Oh well... we'll see. Next up: Figuring out that damn little-endian problem.
::collective groans from the crowd::

Enjoy.

--Scott
sb...@us...

Re: [L2tpd-devel] L2tpd-devel digest, Vol 1 #19 - 2 msgs

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

Also sprach Ehreth Imre
>I am not a lawyer, I don't know how much should we free the SIC library
>according to the GPL.

That same disclaimer to not being a lawyer also applies to me, however,
based on my understanding of the GPL, not distributing the SIC library
is indeed a violation of the GPL.  I was assuming that the SIC library
was a library that was linked to external utilities and that the code
included within l2tpd provided some sort of API for the library to talk
to.  Looking at the code, I find this not to be the case (from what I
can tell).  It seems that the SIC library (libSIC?) is actually linked
into l2tpd itself, this would (as best I understand) constitute a GPL
violation assuming that this software is "distributed".  As with all GPL
code, you could use it "in house" without redistributing it and put
whatever proprietary additions to it that you like into it.  If the
software is redistributed, however, you are then bound by the terms of
the GPL, which states that "complete source code" must be made
available.  This includes any "modules" (read: libraries) that are
included with it.

Please note that I am not trying to be hostile in any way here...but I
am concerned with Siemens' use of the code.  Although, since it was
based on 0.60, this is before I had anything to do with the code base,
so I would have no legal ground really on which to challenge Siemens
with this.  This would be up to Mark Spencer to address legally.
Hopefully, Siemens will see what the "Right Thing" to do here is.  :)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] L2tpd-devel digest, Vol 1 #19 - 2 msgs

[Ehreth I. <imr...@sy...>]

Hi

  I feel your mail is a bit arrogant.

l2t...@li... writes:
 > Message: 1
 > Subject: Re: [L2tpd-devel] [imr...@sy...: Changes made by
 > 	Siemens on l2tpd]
 > From: 
 > To: l2t...@li...
 > Date: 20 Apr 2001 16:28:12 -0400
 > Reply-To: l2t...@li...
 > 
 > I must agree with denial of CVS access. If he wishes to add some
 > patches, that is the reason there is the patch-submission system in the
 > Feature Request tracker. The whole idea of Siemens SIC material in there
 > VEHEMENTLY goes against my blood. This is a vendor-agnostic package,
 > supported by no one save but ourselves. If Siemens wants to use our code
 > and add in SIC patch support just for themselves, fine. But they'd
 > better be darn well ready to give credit to where it belongs, as I will
 > hawk the GPL and anyone that tries to forgo it.
 > 
CVS access was only a suggestion for a form of giving the sources.

I wanted to give back the sources of the l2tpd as it is:
Firstly because I hope it may be usable for the community and secondly
because GPL requires that. The SIC is only an internal communication library.
Nobody have asked you to include the support for it. I just wanted to
give a whole description about the changes. I am not a lawyer, I don't
know how much should we free the SIC library according to the GPL.
You can simple remove the SIC code. Everything is inside #ifdefs what
is SIC related.
 
( And note that I didn't asked CVS access for Siemens. I just asked it
for me. )
 > Furthermore, 3/4 of the material he describes I am already implementing
 > in one form or another in my new version. Mind you, that version is
 > still about another month or so off (I write parts up as I read them in
 > the books I have), but it will be there.
 >
 
You can do whit it what you want, it is up to you. Mainly I was talking with
Mark Spencer about what form should we give back the sources and Jeff
Mcadams was asking us to send the sources to you also.
I didn't that there are people working on l2tpd I have not seen any
activity on l2tpd. Obvously we have seen the same problems but we have
solved them in a different way.

 > For those parts that are applicable to our current devel tree, I am
 > willing to consider a backport and commit after review of just what
 > exactly has gone on in the code. Discussion in email is one thing,
 > seeing what has been hacked and chopped in the code itself is another.
 > 
Yes sometimes I had to hack it because l2tpd is not well documented and
it was not easy to put a little bit changes into it.

 > --Scott
 > 

Best regards
   Imre Ehreth

[L2tpd-devel] Re: Changes made by Siemens on l2tpd

[Ehreth I. <imr...@sy...>]

Hi

Jeff Mcadams writes:
 > Also sprach Ehreth Imre
 > >  Here is a detailed description of the changes that was made by
 > >Siemens (mostly by me) on the l2tpd. Our changes are based on the
 > >0.60.0 version of l2tpd. 
 > 
 > >  We have not tested the AVP hiding yet, but I will do it soon. So
 > >there is a chance that there will be some changes. Besides that I don't
 > >know how much time I will have to further develop l2tpd.
 > 
 > >  I will import the sources soon into the CVS repository on
 > >sourceforge.
 > 
 > >To Jeff Mcadams:
 > 
 > >  Would you mind to add me to the members of the l2tpd group on
 > >sourceforge. My username is gothi on sourceforge .
 > 
 > Unfortunately, I don't have access to add you, only project admins can
 > do that and I'm "merely" a developer.  :)
 > 

I have seen your letter in l2tpd-devel mailing lists:
> I really don't think its a great idea for us to include their SIC stuff
> in our tree unless they open it all up.  I don't particularly want to
> maintain hooks to a proprietary config tool in the main tree.  If they
> want to keep their config tool private, they can deal with patching the
> ongoing main trees with their hooks.  Its largely for this reason that I
> think we should refrain from giving this person cvs commit access as
> they would almost assuredly add that in there.  :/

I just wanted to perform a cvs import command. It is up to you, what
you do with the SIC stuff. I just wanted to give back to the community 
the sources of the l2tpd as it is.
Obviosly you don't need most of the SIC stuff. But there is one
thing that the SIC version adds: support for getting ppp packets from
an external source instead from getting packets from a locally run
pppd.

 > I've looked through the list of changes that you've put below.  Some of
 > the things we've already done in our sourceforge project, some are great
 > that I'd really like to see added to our tree, and some that I really
 > would like to keep out of our tree, honestly.
 > 
 > While I'm not the final arbiter on this (again, I'm not an admin on the
 > project and don't want to be for a variety of reasons!) I would not be
 > particularly keen on including the SIC stuff in the main tree.  I
 > understand your position, but if Siemens doesn't want to contribute
 > their private library, I don't think we should be maintaining hooks in
 > the main tree for it.  :/
 > 
 > We've talked about doing pretty much the same type of functionality, but
 > I feel fairly strongly that it should be publically available
 > capabilities, which it sounds like the SIC stuff wouldn't be.
 > 

When I begin to implement some functionality in l2tpd I didn't know
that there is a group of people working on it. I have seen that there
were no activity for a year.  I know there are some changes you don't
need. You can do with the sources what you want, but I would like that
the copyright message stays in the source.

 > While I can't add you into the project to give CVS access, I'd be more
 > than happy to do the merge for you.  I probably would not merge the SIC
 > capabilities into it (but might when I see how its done), but a lot of
 > the other stuff I'd love to merge in.  Some of the stuff we've already
 > done, and some of the stuff (like the call->rws stuff) is going to
 > conflict with changes that we've made, so that would need to be worked
 > out.
 > 
 > If you want to send a diff, either from Mark's 0.60, or from our tree,
 > or some other known point; or if you'd like to send the tarball, I'd be
 > happy to do the work of the merge.

I send you a tarball of the sources and the eventDumper is also
included. I hope I will further develop l2tpd, but I don't think that
I can use your code base.

Please feel free to ask me if you have questions regarding the changes.

Best regards
   Imre Ehreth

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

Re: [L2tpd-devel] [imre.ehreth@sysdata.siemens.hu: Changes made by Siemens on l2tpd]

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

I must agree with denial of CVS access. If he wishes to add some
patches, that is the reason there is the patch-submission system in the
Feature Request tracker. The whole idea of Siemens SIC material in there
VEHEMENTLY goes against my blood. This is a vendor-agnostic package,
supported by no one save but ourselves. If Siemens wants to use our code
and add in SIC patch support just for themselves, fine. But they'd
better be darn well ready to give credit to where it belongs, as I will
hawk the GPL and anyone that tries to forgo it.

Furthermore, 3/4 of the material he describes I am already implementing
in one form or another in my new version. Mind you, that version is
still about another month or so off (I write parts up as I read them in
the books I have), but it will be there.

For those parts that are applicable to our current devel tree, I am
willing to consider a backport and commit after review of just what
exactly has gone on in the code. Discussion in email is one thing,
seeing what has been hacked and chopped in the code itself is another.

--Scott


On 20 Apr 2001 10:28:56 -0400, Jeff Mcadams wrote:
> This came across the marko.net l2tpd list, as well being sent directly
> to me and Mark Spencer...
> 
> Sounds like they've made some good improvements, some improvements that
> we've already done in our tree, and some that I'm not too keen on
> supporting.
> 
> My plan currently is to respond back that I don't have access to add
> people to the cvs tree since I'm not an admin of the project (fine with
> me, let's me be truthful and still hold this person off a bit), but that
> I'd be happy to get a copy of their tree and/or a patch of their tree
> against Mark's 0.60, or our latest release and do the merge and commit
> the changes to ours.
> 
> I really don't think its a great idea for us to include their SIC stuff
> in our tree unless they open it all up.  I don't particularly want to
> maintain hooks to a proprietary config tool in the main tree.  If they
> want to keep their config tool private, they can deal with patching the
> ongoing main trees with their hooks.  Its largely for this reason that I
> think we should refrain from giving this person cvs commit access as
> they would almost assuredly add that in there.  :/
> 
> ----- Forwarded message from Ehreth Imre <imr...@sy...> -----
> 
> Envelope-to: je...@ig...
> From: Ehreth Imre <imr...@sy...>
> To: Mark Spencer <mar...@ma...>, Jeff Mcadams <je...@ig...>
> Cc: l2...@ma...
> Date: Fri, 20 Apr 2001 12:30:18 +0200
> Subject: Changes made by Siemens on l2tpd
> In-Reply-To: <Pin...@ma...>
> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
> 
> Content-Description: message body text
> Hi
> 
>   Here is a detailed description of the changes that was made by
> Siemens (mostly by me) on the l2tpd. Our changes are based on the
> 0.60.0 version of l2tpd. 
> 
>   We have not tested the AVP hiding yet, but I will do it soon. So
> there is a chance that there will be some changes. Besides that I
> don't know how much time I will have to further develop l2tpd.
> 
>   I will import the sources soon into the CVS repository on
> sourceforge.
> 
> To Jeff Mcadams:
>   Would you mind to add me to the members of the l2tpd group on
> sourceforge. My username is gothi on sourceforge .
> 
> Best regards
>    Imre
> 
> 
> 
> Content-Description: l2tpd changes
>                      Changes made by Siemens on l2tpd
>                      --------------------------------
> 
> 
> Packet handling
> ===============
> 
>   The handling of packets has been changed and rewritten from scratch.
> 
> Payload sequencing
> ------------------
> 
>   The sequencing behaviour of payload packets has been changed and
> now it conforms to the standard. The so called magic R bit has been
> removed and no flow control is used on payload packets. There is no
> payload ZLB sent, no explicit payload packet acknowledgement is used.
> (Also call throttle and dethrottle has been removed ).
> 
>   The Nr field of a payload packet is still set for compatibility
> reason to the sequence number of the sequence number of the last in
> order packet received but it is ignored on receipt.
> 
>   The call structure has now a new state variable controling wether
> payload sequencing are needed. The behaviour is different depending on
> which role is l2tpd playing (lac or lns) according to the standard.
> Wether l2tpd wants to use sequence numbers is decided from the receive
> window size of the call (see call rws bellow in the configuration
> section). If it is not zero l2tpd wants to use it. 
>   If l2tpd plays the lac role and wants to use sequencing it will send
> the sequencing required AVP during the establishment of the call. This
> will enfore to use sequencing during the lifetime of the call.
>   If l2tpd plays the lac role but don't want to use sequencing it
> won't sent the AVP and thus the control of the sequencing is put to
> the lns. So if the peer sends a payload packet with the sequence bit
> set, l2tpd will use sequencing in further packets untill the peer send a
> payload packet without the sequence bit set.
>   If l2tpd plays the lns role and the peer (lac) does not requested
> sequencing but l2tpd wants to use it, it will request by setting the
> sequence bit of the first payload packet to be sent.
>   l2tpd does not strictly enforce the presence of the sequnce numbers
> in the packet. Thus no packet is dropped because of the absence or
> presence of the sequence bit.
> 
> Payload queueing
> ----------------
> 
>   Every call has three queues where payload packets are queued.
>  * transmit queue contains the PPP packets read from the file
> descriptor (device) associated with the call and not already sent.
>  * receive queue contains the PPP packets received but not yet written to
> the device.
>  * pending queue contains out of order PPP packets received. Its
> main purpose is to give a chance to order reordered packets.
> 
>   Bytes read from the device are immediatelly put into a buffer
> (called rbuf). l2tpd makes async -> sync conversion if needed, breaks
> into PPP packets and queues whole ppp packets into the transmit
> queue. The rest is leaved in the read buffer of the call (rbuf).
> ( The original l2tpd used one static buffer for all the calls and
> droped PPP packets not fully read. This migth be not a problem when
> using local pppd, but this is not the case when the other endpoint of
> the ppp connection is terminated on a remote site).
>   The rbuf always contains an already async->sync converted ppp packet
> after the byte reader function finished. The function tries to prevent
> copying when possible. (Unfortunatelly this made it less readable.)
>   Handling of multiple adjacent PPP flag ( packet separator) characters
> has been fixed. There is a quick hack to handle CLIENT messages
> sent by the w*ndows ppp client. If it is received a CLIENTSERVER
> message is immediatelly sent back.
>   Although the new version of the l2tpd does not use flow control this
> queue makes is simpler to implement some kind of it when needed (some
> kind of vendor specific extension). The ppp packets are immediatelly
> sent to the peer.
> 
>   Normal in-order or unsequenced payload packets received from the
> peer are queued into the end of the receive queue. Although l2tpd
> never sends a payload packet with the priority bit set, the new l2tpd now
> handles this issue when it receives a packet with this bit. Such
> packets are queued into the front of the receive queue if it is not
> considered as already seen. The order of priority packets in the queue
> is preserved.
>   If a packet is received with sequence numbers and the sequence
> number of the packet is not exactly the same as the expected it is
> considered as an out of order packet. If it has a smaller sequence
> number than the expected one, it is considered already seen and are
> discarded. (Note: The comparison of the sequence numbers is not
> compliant to the RFC1661. I have to fix it.)
>   Out of order packets not already seen are queued into the pending
> queue. This packets have "pending timeout" microseconds for l2tpd to
> receive its predecessor packets. If a predecessor packet arrives the
> timer is reset, but successor packets does not cause the timer to
> reset. 
>   If the timer expires l2tpd will requeue some of the pending
> packets into the receive queue (not to wait forever to a lost
> packet). The next expected sequince number is set to the
> sequence number of the last requeued packet incremented by one. This
> means if the missed packets arrives later they will be considered
> already seen and so they will be discarded.
>   If l2tpd receives an out of order packet that is outside of the
> receive window of the call, that is its sequence number is greater
> than the sum of the size of the receive window and the sequence number
> of the next expected packet, l2tpd will adjust the receive window by
> making this packet the last packet of the receive window. Pending packets
> that gets outside of the receive window are requeued into the receive
> queue. 
>   The size of the receive window is controlled by the receive window
> size of the call ( see "call rws" option below). The size of the
> receive window limits the maximum number of packets that may by queued
> in the pending window. If the receive window size has the value 0 or 1
> out of order packets is not queued at all. The 0 value tells also
> to not require sequence numbering.
> 
>   The packets queued into the receive queue are written out to the
> devices corresponding to the call and doing on-the-fly sync -> async
> conversion. Before the l2tpd begins to process a new packet from the
> queue it is dequeued and wbuf member of the call structure will point
> to this buffer. The new version of l2tpd only tries to write to the
> device if select tells this.
>  
>   Now more then CONFIG_MAX_PKTS_QUEUED (10) packets are queued in the
> receive queue. This is to prevent allocating too much system resource
> in case the peer fills our queue and underlying device doesn't have
> this speed (or simply there is a bug in the dev handling). If there
> are CONFIG_MAX_PKTS_QUEUED number of packets in the receive queue the
> next incomming packet will be discarded.
> 
> Control packet retransmission
> -----------------------------
> 
>   According to the l2tp standard control messages has to be
> transmitted in reliable manner. Received packets must be acknowledged
> and lost packets has to be retransmitted. The packet resending
> mechanism has been reimplemented in much cleaner way and l2tpd now
> supports the exponential backoff mechanism described by the
> standard. The optional feature called slow start and congestion
> avoidance window adjustment procedure is not implemented and it is
> neither planed to implement. 
> 
>   I have implemented a buffer scheduler called rexmit_queue that gives
> the lower part of the retransmission system. The buffer scheduler has
> a queue of buffers (packets). Each of the buffer has a timeout. It the
> given time has ellapsed a callback function associated with the buffer
> scheduler is called. The callback can reschedule the buffer or leave it
> unscheduled. The buffer scheduler has also an iterator function. This
> made possible to drop buffers right after they are acknowledged and to
> simple drop ecvery packets in the queue when the call is closed
> without the need to hack the internal data structures of the main
> scheduler. The buffer scheduler made possible to use exponential
> backoff intervals.
>   The buffer scheduler uses the main scheduler of the l2tpd. I have
> changed the interface of the main scheduler to simplify the giving of
> timeout parameter. Now the timeout is measured in microseconds instead
> of giving a struct timeval parameter to it. It has one drawback that
> it cannot handle timeout more than approximatelly 72 minutes. But
> there is currently no task in l2tpd requiring such a long timeout.
> 
>   The higher part of the retransmission system uses the buffer
> scheduler of the tunnel called transmit_queue. If a control message is
> not acknowledged before a given time expires the message is to be
> retransmitted. The timeout is initially set to
> CONFIG_INITIAL_RETRANS_TO and is multiplied bt two in the next
> turn. But it may not exceed the maximu specified by
> CONFIG_MAX_RETRANS_TO. If the packet is to be resent more than
> CONFIG_MAX_RETRIES, the tunnel will be marked for closing. ZLB packets
> (used for explicitly acknowledge a control packets) does not
> participate in the resending mechanism.
> 
>   A trigger can be put on each outgoing control packet. This trigger
> is called if the control packet has been acknowleded by the peer. This
> enabled a much cleaner way of checking wether the closing message of
> the call has been acknowledged, instead of having to check each call
> in the incoming packet handling code. This trigger can be used 
> for other purposes too. (For example to start only pppd if the
> ICCN message has been acknowledged).
> 
>   Also the retransmission system takes care not to send more packet to
> the peer that is outside of its receive window. If a non ZLB packet is
> to be sent but outside of the peer's receive window it will be queued
> intro the transmit queue with a zero timeout (thus not scheduled for
> retransmit), but not set. When a packet in the tramsim queue is
> acknowledged it will be checked whether it may be sent instead of
> putting the responsiblity to the higher part of the program. 
> 
>   The retransmission system is responsible to reset the condition
> indicating the need of explicit ackownledgment.
> 
> Incoming control packet handling. 
> ---------------------------------
> 
>   If a control packet is received from the peer it is first checked
> wether it acknowledged some ot our packets sent. The acknowledged
> packets are dropped from the retransmit queue.
>   If an already seen packet is received an explicit ZLB is sent to
> acknowledge the packets already seen.
>   If an out of order packet is received and it is inside the receive
> window of the tunnel, the packet is queued into the receive queue of
> the tunnel. If it is outside of the receive window of the tunnel, the
> message is simply discarded and a ZLB is sent to the peer to indicate
> what packets have we received yet thus requiring the peer to resend the
> message. If an in-order packet is received the receive queue will be
> checked for messages that are in-order now.
>   The size of the receive window is controlled by the "tunnel rws"
> option and by the CONFIG_TUNNEL_RWS (now it is set to 4, the value
> recommended by the rfc). It must be greater than zero. If it is 1,
> every out of order packet are dropped thus the peer is required to
> resend them.
> 
>   After the right order of the packets has been found the message
> header is discarded so handle_avp does not need to calculate the
> length of the header. After handle_avp finished, control_finish is
> called. It the explicit acknowledgement was not cancelled (no packets
> was sent to the peer during processing) a ZLB packet is sent to the
> peer.
> 
> 
> Other packet handling changes
> -----------------------------
> 
>   The packet handling code has been rewritten from scratch. Now
> incoming packets are received by network_thread and handled by the
> handle_packet function. Now the header of a packet is extracted to a
> separate structure by the extract_header function instead of getting
> the information directly from the raw header. The distinction
> between payload and control packet header has been eliminated and now
> the naming convention of the l2tp standard is used in some identifier
> (e.g. PBIT macro is associated with the piece of the header called
> pbit by the standard).
> 
>   The handle_packet functions handles now the lower level of the
> packet processing such as out of order packets, incoming packet
> queuing and flushing. The packets are stored in a structure called
> buffer. The tunnel and peer address has been dissociated from this
> buffer and now the payload packet (udp_xmit) and control packet
> (control_xmit) sending functions gets a tunnel parameter from where
> they get the peer address.
> 
>   l2tp header to the outgoind message is added by control_xmit
> function instead of requiring to call the header adder function
> (add_control_hdr) in each place where messages are sent. The
> control_xmit function now incremenets the next sequence number to used
> in the tunnel instead of the add_control_hdr function. (There is an
> execption ZLB packets don't increment the sequence number).
> 
> 
> Asynchronous and synchronous framing
> ====================================  
> 
> L2tpd supports both asynchronous and synchronous framing type. If the
> peer also supports both, the new l2tpd now chooses asynchronous framing,
> because that needs less processing since the PPP packets read from the
> device are always asynchronous packets.
> 
> 
> Tunnel, call setup and close
> ============================
> 
> Idle tunnels are now closed after a while. (E.g. it has no call)
> 
> Serial number is sent upon call establishment. Sequencing required AVP
> is optionally sent and handled now.
> 
> Eventlog
> ========
> 
>   This is a new feature I have added. It aims to help debugging. If
> enabled some events will produce an entry in the event log
> file. Every entry contains an entry type and a time stamp. Other
> contents of the entry depends on the entry type. The following events
> are logged:
>   * log messages produce an entry containing the message, the log
>  level and some information identifying from where it was issued (the
>  name of the file and function and the line number). 
>   * packets received or sent produce an entry containing the remote
>  address (ip address and port) and the contents of the packet.
>   * read or write of the file descriptor associated with the call
>  produce an entry containing the bytes read or sent and the number of
>  bytes that l2tpd wanted to read or write.
> 
> The entries will be written to a new temporary file will, made by
> mkstemp with the /tmp/l2tpd_events_XXXXXX template.
> There is a small utility called eventDumper that process the event log
> file and makes a human readable form from it.
> 
> Configuration changes
> ======================
> 
>   Compile time configuration has been moved to config.h  (e.g. some #define).
> This is also the place of the various debug flags used.
> 
>   Struct global has been renamed to struct ConfigParams, that hold the global
> configuration parameters.Some new configuration parameter has been added and
> some have been added.
> 
> New options:
> * "pending timeout" controls how long may we keep packets to wait their 
>   predecessor. During this time l2tpd assumes that some packets have
>   been reorderd. It should be given in microseconds.
>   The default of this option is CONFIG_PENDING_TIMEOUT, which is
>   defined to 0.5 second in config.h.
> * "idle tunnel timeout" controls how long an idle tunnel should be
>   kept. A tunnel is considered to be idle if it has no active
>   call. After the timeout expires the tunnel will be closed. This
>   parameter is measured in seconds and must be smaller than 4200.
>   The default of this option is CONFIG_IDLE_TUNNEL_TIMEOUT, which is
>   defined to 30 seconds in config.h
> * "pppd path" option can be used to specify an alternative path for
>   the pppd executable. If not specified the default (CONFIG_PPPD_PATH)
>   of /usr/sbin/pppd will be used.
> * "pppd log" option controls whether the log messages of pppd is to be
>   redirected to the stderr of l2tpd or it is to be suppressed. If not
>   enabled the log is still written to syslog, but not to the stderr
>   (it is achieved by redirecting the stdout of pppd to the same pseudo
>   terminal as the stdin used). If it is enabled the output of l2tpd is
>   intermixed with the log of pppd. The default is to supress log.
> * "mtu" and "mru" numeric options can be given in lac and lns
>   sections. If some of them is given a non zero value, an 
>   mtu <mtu value> or mru <mru value> (respectively) option is
>   specified to the pppd.
> * "old pty" global option specifies whether to use the old method for
>   pseudo terminal allocation. The new method is to use the getpt,
>   grantpt, ... functions exported by libc. The default is to use the
>   new method.
> 
> Options removed:
> * "force userspace" option has been removed. It can be still given but
>   it is ignored from now on.
>   Also the USE_KERNEL option is not specified by default. 
>   I have removed some code between #ifdef USE_KERNEL and #endif (or
>   #else) since there is no kernel support written and it is not likely
>   to happen. Ok, maybe it was not a wise thing to do, but it made the
>   code more readable.
> 
> Options, which meaning has changed:
> * "tunnel rws" now control the receive window size of control
>  messages. For further explanation see above the handling of incomming
>  control packets. The default of this option CONFIG_TUNNEL_RWS which is
>  set to 4.
> * "call rws" lac and lns option now controls the receive window size
>  of the call, which controls how pending packets are handled. For
>  further explanation see above. The default of this option is
>  CONFIG_CALL_RWSIZE, which is set to 4.
> * "port" global option has now the default value of
>  CONFIG_SERVER_PORT. Which is defined to L2TP_UDP_PORT (1701).
> 
> There are several new debug flags.
> * If DEBUG_NTH_PAYLOAD (10) is defined only receipt of
> DEBUG_NTH_PAYLOAD th packet are logged. It has only effect if the
> DEBUG_PAYLOAD is also specified.
> * If DEBUG_WRITE_PACKET is defined the number of bytes written and the number
> of bytes wanted to write are logged when writting to some device
> associated with a call.
>  
> Other changes
> ===============
> 
>   Many bugfixes.
> 
>   Some log message fixing.
> 
>   Removed the checking for duplicate tunnel during tunnel setup. (It
> is not needed and has caused problems).
> 
>   Two small fixes at configuration file parsing (but it has caused a
> segmentation fault if some configuration parameter was mistyped). Some
> configuration parameter gets its default value from the macros defined
> in config.h.
> 
>   The log function has been converted into a macro. It has the
> advantage that the __FILE__, __FUNCTION__ and __LINE__ macros are
> accessible. So there is no need to specify the __FUNCTION__ by the
> caller. I have removed from several place, and I will remove it from
> all as I have time for it. The log macro uses the logError function.
> 
>   If GNU C compiler is used the format gcc attribute is specified in 
> the declaration of logError and add_opt functions. Also the -Wformat
> switch is specified for gcc in the Makefile. This results in a better
> error checking of the format specifiers of the log messages ( and can
> prevent many core dumps).
> 
>   srand() is now called upon startup to initialise the random number
> generator. (Randon number are used for new call and tunnel ids.)
> 
>   Some function have been replaced to a more appropriate (at least
> for me) .c file.
> 
>   Some unused members of the struct tunnel, struct call and struct
> ConfigParams has been removed.
> 
>   The way how pppd is started has been changed. stropt[*] are not
> allocated. There is a new way in allocating pseudo terminals. And
> there is the possibility to redirect the output of pppd to the output
> of l2tpd.
> 
>   The "passive" option is not specified to pppd.
> 
>   The version of the l2tpd is get from the l2tpd_version.h which is
> generated from a file named VERSION.
> 
>   There is now a tunnel_add_call and tunnel_remove_call functions
> responsible for adding and removing, respectivelly calls to a tunnel. 
> 
>   Removed recevie window size AVP sending on call establishment
> 
> Makefile
> ========
> 
>   The make now generates files into a subdirectory depending on the
> architecture. We are using an internal communication library called
> SIC (see below), which is enabled by default but it can be disabled.
> There is three architecture defined now:
> noSIC   will produce an i*86 code without using the SIC library.
> x86     will produce an i*86 code but with using the SIC library.
> ppc     will produce an powerpc code but with using the SIC library,
>         using a crosscompiler.
> 
> The architecture can be controlled by the ARCH variable. The
> executable is generated to a subdirectory with the same name as the
> ARCH variable. (So you will find it usually in the noSIC directory ).
> 
> Added object file dependency from headers. 
> Removed the debug flags from the Makefile to config.h.
> 
> SIC
> ===
> 
>   We are using an internal library for controling l2tpd. This is
> called SIC. This library has a small registry like database. The
> change of a variable optionally produce a notification message. There
> is also a messaging and logging facility in SIC. The variables and
> notifications are used to control l2tpd.
>   Siemens won't like to give this internal library to the community.
> 
>   The usage of the SIC library is controlled by the USESIC macro.
> 
>   If the USESIC macro the behaviour of l2tpd changed in several other
> ways.
> * Configuration file is not parsed. The configuration of the l2tpd is
>   achieved by SIC variables and static configuration by macros defined
>   in config.h .
> * l2tpd is only able to work as a LAC. A new tunnel and call cannot be
>   established by the peer.
> * SIC is used for logging.
> * statistic information is put into SIC variables.
> * The control pipe is not read, instead SIC is used to control l2tpd
>   (making calls, closing calls)
> * There is no redial support.
> * SIGUSR1 and SIGCHLD are not handled. 
> * pppd is not started by l2tpd. Instead it gets a device name from SIC,
>   opens this file. PPP packets is read from this file and written to
>   this file. 
>   If USESERIAL macro is defined some serial line setting will be
>   done. IF SERIAL_SPEED is also defined too, the speed of the serial line
>   will be also set.
> 
> 
> 
> ----- End forwarded message -----
> 
> -- 
> 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] [imre.ehreth@sysdata.siemens.hu: Changes made by Siemens on l2tpd]

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

This came across the marko.net l2tpd list, as well being sent directly
to me and Mark Spencer...

Sounds like they've made some good improvements, some improvements that
we've already done in our tree, and some that I'm not too keen on
supporting.

My plan currently is to respond back that I don't have access to add
people to the cvs tree since I'm not an admin of the project (fine with
me, let's me be truthful and still hold this person off a bit), but that
I'd be happy to get a copy of their tree and/or a patch of their tree
against Mark's 0.60, or our latest release and do the merge and commit
the changes to ours.

I really don't think its a great idea for us to include their SIC stuff
in our tree unless they open it all up.  I don't particularly want to
maintain hooks to a proprietary config tool in the main tree.  If they
want to keep their config tool private, they can deal with patching the
ongoing main trees with their hooks.  Its largely for this reason that I
think we should refrain from giving this person cvs commit access as
they would almost assuredly add that in there.  :/

----- Forwarded message from Ehreth Imre <imr...@sy...> -----

Envelope-to: je...@ig...
From: Ehreth Imre <imr...@sy...>
To: Mark Spencer <mar...@ma...>, Jeff Mcadams <je...@ig...>
Cc: l2...@ma...
Date: Fri, 20 Apr 2001 12:30:18 +0200
Subject: Changes made by Siemens on l2tpd
In-Reply-To: <Pin...@ma...>
X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid

Content-Description: message body text
Hi

  Here is a detailed description of the changes that was made by
Siemens (mostly by me) on the l2tpd. Our changes are based on the
0.60.0 version of l2tpd. 

  We have not tested the AVP hiding yet, but I will do it soon. So
there is a chance that there will be some changes. Besides that I
don't know how much time I will have to further develop l2tpd.

  I will import the sources soon into the CVS repository on
sourceforge.

To Jeff Mcadams:
  Would you mind to add me to the members of the l2tpd group on
sourceforge. My username is gothi on sourceforge .

Best regards
   Imre



Content-Description: l2tpd changes
                     Changes made by Siemens on l2tpd
                     --------------------------------


Packet handling
===============

  The handling of packets has been changed and rewritten from scratch.

Payload sequencing
------------------

  The sequencing behaviour of payload packets has been changed and
now it conforms to the standard. The so called magic R bit has been
removed and no flow control is used on payload packets. There is no
payload ZLB sent, no explicit payload packet acknowledgement is used.
(Also call throttle and dethrottle has been removed ).

  The Nr field of a payload packet is still set for compatibility
reason to the sequence number of the sequence number of the last in
order packet received but it is ignored on receipt.

  The call structure has now a new state variable controling wether
payload sequencing are needed. The behaviour is different depending on
which role is l2tpd playing (lac or lns) according to the standard.
Wether l2tpd wants to use sequence numbers is decided from the receive
window size of the call (see call rws bellow in the configuration
section). If it is not zero l2tpd wants to use it. 
  If l2tpd plays the lac role and wants to use sequencing it will send
the sequencing required AVP during the establishment of the call. This
will enfore to use sequencing during the lifetime of the call.
  If l2tpd plays the lac role but don't want to use sequencing it
won't sent the AVP and thus the control of the sequencing is put to
the lns. So if the peer sends a payload packet with the sequence bit
set, l2tpd will use sequencing in further packets untill the peer send a
payload packet without the sequence bit set.
  If l2tpd plays the lns role and the peer (lac) does not requested
sequencing but l2tpd wants to use it, it will request by setting the
sequence bit of the first payload packet to be sent.
  l2tpd does not strictly enforce the presence of the sequnce numbers
in the packet. Thus no packet is dropped because of the absence or
presence of the sequence bit.

Payload queueing
----------------

  Every call has three queues where payload packets are queued.
 * transmit queue contains the PPP packets read from the file
descriptor (device) associated with the call and not already sent.
 * receive queue contains the PPP packets received but not yet written to
the device.
 * pending queue contains out of order PPP packets received. Its
main purpose is to give a chance to order reordered packets.

  Bytes read from the device are immediatelly put into a buffer
(called rbuf). l2tpd makes async -> sync conversion if needed, breaks
into PPP packets and queues whole ppp packets into the transmit
queue. The rest is leaved in the read buffer of the call (rbuf).
( The original l2tpd used one static buffer for all the calls and
droped PPP packets not fully read. This migth be not a problem when
using local pppd, but this is not the case when the other endpoint of
the ppp connection is terminated on a remote site).
  The rbuf always contains an already async->sync converted ppp packet
after the byte reader function finished. The function tries to prevent
copying when possible. (Unfortunatelly this made it less readable.)
  Handling of multiple adjacent PPP flag ( packet separator) characters
has been fixed. There is a quick hack to handle CLIENT messages
sent by the w*ndows ppp client. If it is received a CLIENTSERVER
message is immediatelly sent back.
  Although the new version of the l2tpd does not use flow control this
queue makes is simpler to implement some kind of it when needed (some
kind of vendor specific extension). The ppp packets are immediatelly
sent to the peer.

  Normal in-order or unsequenced payload packets received from the
peer are queued into the end of the receive queue. Although l2tpd
never sends a payload packet with the priority bit set, the new l2tpd now
handles this issue when it receives a packet with this bit. Such
packets are queued into the front of the receive queue if it is not
considered as already seen. The order of priority packets in the queue
is preserved.
  If a packet is received with sequence numbers and the sequence
number of the packet is not exactly the same as the expected it is
considered as an out of order packet. If it has a smaller sequence
number than the expected one, it is considered already seen and are
discarded. (Note: The comparison of the sequence numbers is not
compliant to the RFC1661. I have to fix it.)
  Out of order packets not already seen are queued into the pending
queue. This packets have "pending timeout" microseconds for l2tpd to
receive its predecessor packets. If a predecessor packet arrives the
timer is reset, but successor packets does not cause the timer to
reset. 
  If the timer expires l2tpd will requeue some of the pending
packets into the receive queue (not to wait forever to a lost
packet). The next expected sequince number is set to the
sequence number of the last requeued packet incremented by one. This
means if the missed packets arrives later they will be considered
already seen and so they will be discarded.
  If l2tpd receives an out of order packet that is outside of the
receive window of the call, that is its sequence number is greater
than the sum of the size of the receive window and the sequence number
of the next expected packet, l2tpd will adjust the receive window by
making this packet the last packet of the receive window. Pending packets
that gets outside of the receive window are requeued into the receive
queue. 
  The size of the receive window is controlled by the receive window
size of the call ( see "call rws" option below). The size of the
receive window limits the maximum number of packets that may by queued
in the pending window. If the receive window size has the value 0 or 1
out of order packets is not queued at all. The 0 value tells also
to not require sequence numbering.

  The packets queued into the receive queue are written out to the
devices corresponding to the call and doing on-the-fly sync -> async
conversion. Before the l2tpd begins to process a new packet from the
queue it is dequeued and wbuf member of the call structure will point
to this buffer. The new version of l2tpd only tries to write to the
device if select tells this.
 
  Now more then CONFIG_MAX_PKTS_QUEUED (10) packets are queued in the
receive queue. This is to prevent allocating too much system resource
in case the peer fills our queue and underlying device doesn't have
this speed (or simply there is a bug in the dev handling). If there
are CONFIG_MAX_PKTS_QUEUED number of packets in the receive queue the
next incomming packet will be discarded.

Control packet retransmission
-----------------------------

  According to the l2tp standard control messages has to be
transmitted in reliable manner. Received packets must be acknowledged
and lost packets has to be retransmitted. The packet resending
mechanism has been reimplemented in much cleaner way and l2tpd now
supports the exponential backoff mechanism described by the
standard. The optional feature called slow start and congestion
avoidance window adjustment procedure is not implemented and it is
neither planed to implement. 

  I have implemented a buffer scheduler called rexmit_queue that gives
the lower part of the retransmission system. The buffer scheduler has
a queue of buffers (packets). Each of the buffer has a timeout. It the
given time has ellapsed a callback function associated with the buffer
scheduler is called. The callback can reschedule the buffer or leave it
unscheduled. The buffer scheduler has also an iterator function. This
made possible to drop buffers right after they are acknowledged and to
simple drop ecvery packets in the queue when the call is closed
without the need to hack the internal data structures of the main
scheduler. The buffer scheduler made possible to use exponential
backoff intervals.
  The buffer scheduler uses the main scheduler of the l2tpd. I have
changed the interface of the main scheduler to simplify the giving of
timeout parameter. Now the timeout is measured in microseconds instead
of giving a struct timeval parameter to it. It has one drawback that
it cannot handle timeout more than approximatelly 72 minutes. But
there is currently no task in l2tpd requiring such a long timeout.

  The higher part of the retransmission system uses the buffer
scheduler of the tunnel called transmit_queue. If a control message is
not acknowledged before a given time expires the message is to be
retransmitted. The timeout is initially set to
CONFIG_INITIAL_RETRANS_TO and is multiplied bt two in the next
turn. But it may not exceed the maximu specified by
CONFIG_MAX_RETRANS_TO. If the packet is to be resent more than
CONFIG_MAX_RETRIES, the tunnel will be marked for closing. ZLB packets
(used for explicitly acknowledge a control packets) does not
participate in the resending mechanism.

  A trigger can be put on each outgoing control packet. This trigger
is called if the control packet has been acknowleded by the peer. This
enabled a much cleaner way of checking wether the closing message of
the call has been acknowledged, instead of having to check each call
in the incoming packet handling code. This trigger can be used 
for other purposes too. (For example to start only pppd if the
ICCN message has been acknowledged).

  Also the retransmission system takes care not to send more packet to
the peer that is outside of its receive window. If a non ZLB packet is
to be sent but outside of the peer's receive window it will be queued
intro the transmit queue with a zero timeout (thus not scheduled for
retransmit), but not set. When a packet in the tramsim queue is
acknowledged it will be checked whether it may be sent instead of
putting the responsiblity to the higher part of the program. 

  The retransmission system is responsible to reset the condition
indicating the need of explicit ackownledgment.

Incoming control packet handling. 
---------------------------------

  If a control packet is received from the peer it is first checked
wether it acknowledged some ot our packets sent. The acknowledged
packets are dropped from the retransmit queue.
  If an already seen packet is received an explicit ZLB is sent to
acknowledge the packets already seen.
  If an out of order packet is received and it is inside the receive
window of the tunnel, the packet is queued into the receive queue of
the tunnel. If it is outside of the receive window of the tunnel, the
message is simply discarded and a ZLB is sent to the peer to indicate
what packets have we received yet thus requiring the peer to resend the
message. If an in-order packet is received the receive queue will be
checked for messages that are in-order now.
  The size of the receive window is controlled by the "tunnel rws"
option and by the CONFIG_TUNNEL_RWS (now it is set to 4, the value
recommended by the rfc). It must be greater than zero. If it is 1,
every out of order packet are dropped thus the peer is required to
resend them.

  After the right order of the packets has been found the message
header is discarded so handle_avp does not need to calculate the
length of the header. After handle_avp finished, control_finish is
called. It the explicit acknowledgement was not cancelled (no packets
was sent to the peer during processing) a ZLB packet is sent to the
peer.


Other packet handling changes
-----------------------------

  The packet handling code has been rewritten from scratch. Now
incoming packets are received by network_thread and handled by the
handle_packet function. Now the header of a packet is extracted to a
separate structure by the extract_header function instead of getting
the information directly from the raw header. The distinction
between payload and control packet header has been eliminated and now
the naming convention of the l2tp standard is used in some identifier
(e.g. PBIT macro is associated with the piece of the header called
pbit by the standard).

  The handle_packet functions handles now the lower level of the
packet processing such as out of order packets, incoming packet
queuing and flushing. The packets are stored in a structure called
buffer. The tunnel and peer address has been dissociated from this
buffer and now the payload packet (udp_xmit) and control packet
(control_xmit) sending functions gets a tunnel parameter from where
they get the peer address.

  l2tp header to the outgoind message is added by control_xmit
function instead of requiring to call the header adder function
(add_control_hdr) in each place where messages are sent. The
control_xmit function now incremenets the next sequence number to used
in the tunnel instead of the add_control_hdr function. (There is an
execption ZLB packets don't increment the sequence number).


Asynchronous and synchronous framing
====================================  

L2tpd supports both asynchronous and synchronous framing type. If the
peer also supports both, the new l2tpd now chooses asynchronous framing,
because that needs less processing since the PPP packets read from the
device are always asynchronous packets.


Tunnel, call setup and close
============================

Idle tunnels are now closed after a while. (E.g. it has no call)

Serial number is sent upon call establishment. Sequencing required AVP
is optionally sent and handled now.

Eventlog
========

  This is a new feature I have added. It aims to help debugging. If
enabled some events will produce an entry in the event log
file. Every entry contains an entry type and a time stamp. Other
contents of the entry depends on the entry type. The following events
are logged:
  * log messages produce an entry containing the message, the log
 level and some information identifying from where it was issued (the
 name of the file and function and the line number). 
  * packets received or sent produce an entry containing the remote
 address (ip address and port) and the contents of the packet.
  * read or write of the file descriptor associated with the call
 produce an entry containing the bytes read or sent and the number of
 bytes that l2tpd wanted to read or write.

The entries will be written to a new temporary file will, made by
mkstemp with the /tmp/l2tpd_events_XXXXXX template.
There is a small utility called eventDumper that process the event log
file and makes a human readable form from it.

Configuration changes
======================

  Compile time configuration has been moved to config.h  (e.g. some #define).
This is also the place of the various debug flags used.

  Struct global has been renamed to struct ConfigParams, that hold the global
configuration parameters.Some new configuration parameter has been added and
some have been added.

New options:
* "pending timeout" controls how long may we keep packets to wait their 
  predecessor. During this time l2tpd assumes that some packets have
  been reorderd. It should be given in microseconds.
  The default of this option is CONFIG_PENDING_TIMEOUT, which is
  defined to 0.5 second in config.h.
* "idle tunnel timeout" controls how long an idle tunnel should be
  kept. A tunnel is considered to be idle if it has no active
  call. After the timeout expires the tunnel will be closed. This
  parameter is measured in seconds and must be smaller than 4200.
  The default of this option is CONFIG_IDLE_TUNNEL_TIMEOUT, which is
  defined to 30 seconds in config.h
* "pppd path" option can be used to specify an alternative path for
  the pppd executable. If not specified the default (CONFIG_PPPD_PATH)
  of /usr/sbin/pppd will be used.
* "pppd log" option controls whether the log messages of pppd is to be
  redirected to the stderr of l2tpd or it is to be suppressed. If not
  enabled the log is still written to syslog, but not to the stderr
  (it is achieved by redirecting the stdout of pppd to the same pseudo
  terminal as the stdin used). If it is enabled the output of l2tpd is
  intermixed with the log of pppd. The default is to supress log.
* "mtu" and "mru" numeric options can be given in lac and lns
  sections. If some of them is given a non zero value, an 
  mtu <mtu value> or mru <mru value> (respectively) option is
  specified to the pppd.
* "old pty" global option specifies whether to use the old method for
  pseudo terminal allocation. The new method is to use the getpt,
  grantpt, ... functions exported by libc. The default is to use the
  new method.

Options removed:
* "force userspace" option has been removed. It can be still given but
  it is ignored from now on.
  Also the USE_KERNEL option is not specified by default. 
  I have removed some code between #ifdef USE_KERNEL and #endif (or
  #else) since there is no kernel support written and it is not likely
  to happen. Ok, maybe it was not a wise thing to do, but it made the
  code more readable.

Options, which meaning has changed:
* "tunnel rws" now control the receive window size of control
 messages. For further explanation see above the handling of incomming
 control packets. The default of this option CONFIG_TUNNEL_RWS which is
 set to 4.
* "call rws" lac and lns option now controls the receive window size
 of the call, which controls how pending packets are handled. For
 further explanation see above. The default of this option is
 CONFIG_CALL_RWSIZE, which is set to 4.
* "port" global option has now the default value of
 CONFIG_SERVER_PORT. Which is defined to L2TP_UDP_PORT (1701).

There are several new debug flags.
* If DEBUG_NTH_PAYLOAD (10) is defined only receipt of
DEBUG_NTH_PAYLOAD th packet are logged. It has only effect if the
DEBUG_PAYLOAD is also specified.
* If DEBUG_WRITE_PACKET is defined the number of bytes written and the number
of bytes wanted to write are logged when writting to some device
associated with a call.
 
Other changes
===============

  Many bugfixes.

  Some log message fixing.

  Removed the checking for duplicate tunnel during tunnel setup. (It
is not needed and has caused problems).

  Two small fixes at configuration file parsing (but it has caused a
segmentation fault if some configuration parameter was mistyped). Some
configuration parameter gets its default value from the macros defined
in config.h.

  The log function has been converted into a macro. It has the
advantage that the __FILE__, __FUNCTION__ and __LINE__ macros are
accessible. So there is no need to specify the __FUNCTION__ by the
caller. I have removed from several place, and I will remove it from
all as I have time for it. The log macro uses the logError function.

  If GNU C compiler is used the format gcc attribute is specified in 
the declaration of logError and add_opt functions. Also the -Wformat
switch is specified for gcc in the Makefile. This results in a better
error checking of the format specifiers of the log messages ( and can
prevent many core dumps).

  srand() is now called upon startup to initialise the random number
generator. (Randon number are used for new call and tunnel ids.)

  Some function have been replaced to a more appropriate (at least
for me) .c file.

  Some unused members of the struct tunnel, struct call and struct
ConfigParams has been removed.

  The way how pppd is started has been changed. stropt[*] are not
allocated. There is a new way in allocating pseudo terminals. And
there is the possibility to redirect the output of pppd to the output
of l2tpd.

  The "passive" option is not specified to pppd.

  The version of the l2tpd is get from the l2tpd_version.h which is
generated from a file named VERSION.

  There is now a tunnel_add_call and tunnel_remove_call functions
responsible for adding and removing, respectivelly calls to a tunnel. 

  Removed recevie window size AVP sending on call establishment

Makefile
========

  The make now generates files into a subdirectory depending on the
architecture. We are using an internal communication library called
SIC (see below), which is enabled by default but it can be disabled.
There is three architecture defined now:
noSIC   will produce an i*86 code without using the SIC library.
x86     will produce an i*86 code but with using the SIC library.
ppc     will produce an powerpc code but with using the SIC library,
        using a crosscompiler.

The architecture can be controlled by the ARCH variable. The
executable is generated to a subdirectory with the same name as the
ARCH variable. (So you will find it usually in the noSIC directory ).

Added object file dependency from headers. 
Removed the debug flags from the Makefile to config.h.

SIC
===

  We are using an internal library for controling l2tpd. This is
called SIC. This library has a small registry like database. The
change of a variable optionally produce a notification message. There
is also a messaging and logging facility in SIC. The variables and
notifications are used to control l2tpd.
  Siemens won't like to give this internal library to the community.

  The usage of the SIC library is controlled by the USESIC macro.

  If the USESIC macro the behaviour of l2tpd changed in several other
ways.
* Configuration file is not parsed. The configuration of the l2tpd is
  achieved by SIC variables and static configuration by macros defined
  in config.h .
* l2tpd is only able to work as a LAC. A new tunnel and call cannot be
  established by the peer.
* SIC is used for logging.
* statistic information is put into SIC variables.
* The control pipe is not read, instead SIC is used to control l2tpd
  (making calls, closing calls)
* There is no redial support.
* SIGUSR1 and SIGCHLD are not handled. 
* pppd is not started by l2tpd. Instead it gets a device name from SIC,
  opens this file. PPP packets is read from this file and written to
  this file. 
  If USESERIAL macro is defined some serial line setting will be
  done. IF SERIAL_SPEED is also defined too, the speed of the serial line
  will be also set.



----- End forwarded message -----

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

[L2tpd-devel] 0.63 yet?

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

Well...its been about a month and we've had some fairly significant
updates to 0.62 added.  Think its about time for a 0.63?

Things that I see have changed in cvs since 0.62:

* added syslog support
* remove checking for call/session serial number in ICRQ
* made data sequencing and flow control serial number checks more robust
* removed checking for obsolete R-bit entirely
* ppp frames in the tunnel always use sync framing
* one or two other really minor fixes

The sync framing allows us to interoperate with Cisco IOS 12.1 (more
confirmation of this would be nice), so that's another platform that we
have interoperability with (as far as I know...again...more confirmation
would be nice).  The call/session serial number check being removed
should allow interoperability as an LNS with w2k (open support request
currently on this issue)

On a tangential note...I added an L2TP project on freshmeat.net so we
can put our releases up there.  If someone else wants to maintain that
(pretty minor only updates when releases come out really), speak up and
I'll gladly hand that over.  If noone steps forward for that, I'll keep
doing it unless there are other objections.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Re: [L2tpd-devel] Autentication transfer to "l2tpd" via "pppd"

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

Also sprach mza...@te...
>We need configuration examples of l2tpd passing the user code and
>password to the Cable Net Network
>By example:
>user :     "oo37788"
>passwword: "oo37788"

>in any part of the documentation yours talk about of pseudo tty via
>pppd (please teachme how can  I do that) the other think the driver is
>ready and connected to the Cable Public Network, but I dont know how
>can transfer the authentication via ppp o what else !!!

Is this PPP authentication that you're using?  Like CHAP or PAP?  If so,
L2TP has nothing to do with that.  L2TP just creates a virtual point to
point link that PPP can then use to send its traffic back and forth.
PPP authentication traffic looks just like any other PPP traffic to
L2TP.

There is plenty of documentation out there for PPP configuration, search
for the PPP-HOWTO for a good starting point.

If you're using L2TP authentication, let me know and I can work with you
on it.  Since we've just been working with this code for a couple of
months, we're not intimately familiar with the code yet, but I'd be
happy to work with you and figure out what's going on and how something
needs to work.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

[L2tpd-devel] Autentication transfer to "l2tpd" via "pppd"

[<mza...@te...>]

Date: Tue, 17 Apr 2001 22:55:13 -0500
From: mza...@te...
Reply-To: mza...@te...
Subject: Autentication transfer to "l2tpd" via "pppd"
To: l2t...@ma...

Hi,
We need
configuration examples of l2tpd
passing the user code and password
to the Cable Net Network
By example:
user :     "oo37788"
passwword: "oo37788"

in any part of the documentation yours talk about of
pseudo tty via pppd (please teachme how can  I do that)
the other think
the driver is ready and connected to the Cable Public
Network, but I dont know how can transfer the
authentication via ppp o what else !!!

Thans !!
Mario

Re: [L2tpd-devel] Fw: l2tp for DSL services with Bell Nexxia

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

Also sprach David K. Stipp
>Anyone know what might be going wrong? It might be time for me to start
>testing the code on my alpha at my house.

Yeah...its gonna be needed, that's for sure.  Not only does going to
Alpha go to a 64-bit processor, but I think its also big-endian rather
than x86's little-endian, so there may be (indeed, I'm pretty sure there
are) endian issues in the code as well.

FWIW, I compiled it on linux/sparc (Debian/Sparc) and it compiled
without complaint, but promptly puked out when I tried to run it.  This
was not an ultra sparc, so still 32-bit, but big-endian as well, so I
believe there are endian issues there.

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

[L2tpd-devel] Fw: l2tp for DSL services with Bell Nexxia

[David K. S. <ds...@on...>]

Anyone know what might be going wrong? It might be time for me to start
testing the code on my alpha at my house.

David

----- Original Message -----
From: "alvin starr" <al...@ip...>
To: <ds...@on...>
Sent: Wednesday, April 11, 2001 1:48 PM
Subject: l2tp for DSL services with Bell Nexxia


> I am trying to connect with the local DSL provider here(that
> being a devision of Bell Canada). and getting some strange
> results.
>
> I have started with version 0.61 but have just compiled 0.62
> and hope to have more luck.
>
> I am running here on an Alpha cpu this adds the extra
> interesging feature that the processor is a 64 bit cpu.
> I have a feeling that this may be the source of my problems.
>
> Can you think of any place off hand that would be 64 bit
> sensitive in the code so that I can have a place to start
> looking.
>
> Alvin.
>
>

[L2tpd-devel] Cisco IOS interop.

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

OK...

With the assistance of W. Mark Townsley, I believe I've achieved
interoperability with Cisco IOS (version 12.1(7) tested).  I was not
able to ping across the tunnel connection that was established, but I
believe that is a result of higher level config problems that I really
didn't feel like fighting through (if you've ever dealt with IOS
virtual-template interfaces, you know what I'm fighting here...ick).

In any case, a tunnel was setup, PPP negotiated, and values were
consistent on each side of the connection, so at least *some*
communication occured on the data channel.

FWIW, the obstacle here was the incorrect handling of framing over the
tunnel.  With 12.0(7)T (initially tested) it wasn't much of a problem
because it advertised sync framing capabilities...12.1(7) didn't
advertise either sync or async framing capabilities, which caused no end
of problems with l2tpd, since it ended up sending PPP packets over the
tunnel connection escaped or bit-stuffed, which it shouldn't do.

The fix is incredibly hideous...basically forced the calls to
read_packet() and write_packet() to be SYNC_FRAMING, rather than the
bitwise AND it was doing with...uh...call->frame I believe it was.
Since the data going over the tunnel should *always* be in sync framing,
this forces it to always convert to and from sync framing.  This means
there's a considerable amount of code at this point that is unused that
was in there to deal with async framing over the tunnel.  I've put
removing all of that code on my mental to-do list.

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

[L2tpd-devel] [townsley@cisco.com: Re: l2tpd for Linux...]

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

Hey guys...just for kicks, I dropped an email to Mark Townsley, employee
of Cisco, and also head of the L2TP working group of the IETF.  Just
figured I'd let him know that we were doing some work with l2tpd.
Basically told him to feel free to do whatever with the info...delete
it, whatever...since I know he gets bombarded with random stuff in email
all the time I'm sure.

Anyway...his response was very positive.  I've included it below.  :)

I did some basic testing of l2tpd with IOS, since he asked.  Although
I've never worked with the vpdn stuff in IOS before, I *think* I have it
basically configured correctly for at least basic functionality.  It
does seem to bring up the tunnel and negotiate LCP and IPCP within PPP,
but then my router promptly crashes (though not l2tpd!).  Not sure
what's going on, but it does look like there's at least basic
interoperability there.

I did respond back to Mark to let him know about my basic
testing...included config snippets on the Cisco and stuff...we'll see
what he says...I could be totally off base on my vpdn config stuff.
*shrug*

----- Forwarded message from "W. Mark Townsley" <tow...@ci...> -----

Envelope-to: je...@ig...
Date: Mon, 09 Apr 2001 10:39:32 -0400
From: "W. Mark Townsley" <tow...@ci...>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
To: Jeff Mcadams <je...@ig...>
Subject: Re: l2tpd for Linux...


Thanks for the heads up. I'm quite happy to see public (or at least GPL)
code being actively developed for L2TP. I only wish I had the time to
contribute directly as well. If you get bored, I'd like to see you test
with Cisco IOS as well. The L2TP in the VPN 3000 is a completely
different implementation from that in our routers. I, personally, work
most directly with the implementation in IOS. 

Thanks again, and please don't hesitate to keep me informed.

- Mark

Jeff Mcadams wrote:
> 
> Hi,
> 
> I suspect you get many queries concerning L2TP support for specific
> platforms given your prominent position in the L2TP process.
> 
> I just wanted to give you a heads up...do with this as you like.  :)
> 
> I and a couple of other guys have taken Mark Spencer's l2tpd code base
> and have started doing some more active development work with it.  Our
> effort is being hosted at Sourceforge,
> http://www.sourceforge.net/projects/l2tpd
> 
> We have made several significant improvements to the operations
> (including bringing it up to date wrt session flow control...l2tpd was
> still operating on a pre-draft-13 mode of operation there) at this
> point, and are planning on continuing improvements.  There has also been
> some thought to starting a new code base from scratch to hopefully
> provide greater flexibility, but that is still some time off in the
> future.
> 
> We have also confirmed interoperability as a LAC with RedBack SMS's and
> Cisco 3000 VPN Concentrators.
> 
> Anyway...like I said, I just wanted to get this on your radar screen,
> feel free to delete it, or whatever you wish.  :)
> --
> Jeff McAdams                            Email: je...@ig...
> Head Network Administrator              Voice: (502) 966-3848
> IgLou Internet Services                        (800) 436-4456

----- End forwarded message -----

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

Re: [L2tpd-devel] FW: I-D ACTION:draft-ietf-l2tpext-ppp-discinfo-03.txt

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

Also sprach Scott Balmos
>Should prove very useful if I can write it into the new version. :D

>Too bad it's not up on the IETF server right now, for whatever reason.

Its up now...got a chance to look at it.

This isn't terribly useful in the current code base since with the
current code base we only support having the PPP endpoint be on the same
machine as the L2TP endpoint, so any information that would be conveyed
by this AVP would already be known at the PPP level.

I do definitely agree that it would be very useful to have support for
it in the case where the L2TP and PPP endpoints are not the same system
(hopefully this capability will be available in the new code base ;)

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

[L2tpd-devel] FW: I-D ACTION:draft-ietf-l2tpext-ppp-discinfo-03.txt

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

Should prove very useful if I can write it into the new version. :D

Too bad it's not up on the IETF server right now, for whatever reason.

--Scott

-----Original Message-----
From: own...@di... [mailto:own...@di...]On Behalf
Of Int...@ie...
Sent: Friday, April 06, 2001 9:51 AM
To: IETF-Announce:
Cc: l2...@l2...
Subject: I-D ACTION:draft-ietf-l2tpext-ppp-discinfo-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Layer Two Tunneling Protocol Extensions
Working Group of the IETF.

	Title		: L2TP Disconnect Cause Information
	Author(s)	: R. Verma, M. Verma, J. Carlson
	Filename	: draft-ietf-l2tpext-ppp-discinfo-03.txt
	Pages		: 9
	Date		: 05-Apr-01

The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for
tunneling Point-to-Point Protocol (PPP) sessions.  This protocol
lacks a mechanism for an L2TP host to provide PPP-related disconnect
cause information to another host.  This information, provided by the
extension described in this document, can be useful for accounting
and debugging purposes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-ppp-discinfo-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-l2tpext-ppp-discinfo-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mai...@ie....
In the body type:
	"FILE /internet-drafts/draft-ietf-l2tpext-ppp-discinfo-03.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [L2tpd-devel] SYSLOG SUPPORT ADDED!!!

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

Also sprach David K. Stipp
>> FYI to those who want a clean screen... If you want it to only log to
>> syslog and not to stderr also, you can just delete out the lines
>> below in log() from misc.c and recompile.

>> vfprintf(stderr,fmt, args);
>> fflush(stderr);

>Did somebody say compile / run time option? =)

Would be easy to make it compile time...just through some #ifdefs around
it...run time takes a bit more doing of course.  :)
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Re: [L2tpd-devel] SYSLOG SUPPORT ADDED!!!

[David K. S. <ds...@on...>]

----- Original Message -----
From: "Scott Balmos" <sb...@ig...>
To: <l2t...@li...>
Sent: Monday, April 02, 2001 12:23 AM
Subject: [L2tpd-devel] SYSLOG SUPPORT ADDED!!!


> 'morning everyone!
>

--snip--

> FYI to those who want a clean screen... If you want it to only log to
syslog
> and not to stderr also, you can just delete out the lines below in log()
> from misc.c and recompile.
>
> vfprintf(stderr,fmt, args);
> fflush(stderr);

Did somebody say compile / run time option? =)

David

[L2tpd-devel] SYSLOG SUPPORT ADDED!!!

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

'morning everyone!

Oh what fun we can have on very early Monday mornings, especially when we're
on Spring Break now. Lo and behold, I strapped on my plumber's toolbelt and
dived into the log() function in misc.c that the whole thing uses for
managing its logging to stderr.

After realigning l2tpd's locally-defined integer levels for the logging
levels in misc.h (LOG_CRIT, etc) to what syslog really uses, I bastardized
the syslog string formatter in an old PPTP implementation.

In the end, about two or three lines later in the actual log() function, and
kaboom we have a true daemon error logging system.

FYI to those who want a clean screen... If you want it to only log to syslog
and not to stderr also, you can just delete out the lines below in log()
from misc.c and recompile.

vfprintf(stderr,fmt, args);
fflush(stderr);

Enjoy!!!

--
Scott (sb...@us...)

[L2tpd-devel] [markster@marko.net: new l2tpd version (fwd)]

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

FWIW...I'm gonna check it out here in a bit.

----- Forwarded message from Mark Spencer <mar...@ma...> -----

Envelope-to: je...@ig...
X-Authentication-Warning: marko.marko.net: majordomo set sender to own...@ma... using -f
Date: Mon, 26 Mar 2001 08:30:44 -0600 (EST)
From: Mark Spencer <mar...@ma...>
To: l2...@ma...
Subject: new l2tpd version (fwd)
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by marko.marko.net id IAA20232
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by marko.marko.net id IAA20234

I recently got this messsage, but have not heard any more details from the
people who created it. 

Anybody want to take a peek at it?

Mark


-------------------------------------------------------------------------
Mark Spencer, President                 Free and Commercial Linux Support
Linux Support Services, Inc.            On the web or on the phone
6700 Odyssey Drive Suite 101-ABF
Huntsville, AL  35806                   http://www.linux-support.net
(256) 428-6000                          st...@li...
                                        Toll free:  (877) LINUX-ME

---------- Forwarded message ----------
Date: Thu, 22 Mar 2001 17:04:49 +0100
From: "[iso-8859-1] Fejes Péter" <pet...@sy...>
To: "'mar...@ma...'" <mar...@ma...>
Subject: new l2tpd version

Hi Mark Spencer!

We implemented some new feature in the l2tpd:
* Configuration changes (adding new config structure).
* Packet handling changed (adding queueing and resending functions).
* Others (Some bug fixed and differents with RFC2661 corrected).
* Adding our control mechanism (You can use without this.).

For more details please contact Peter Fejes
(pet...@sy...) or 
Imre Ehreth (imr...@sy...).

Best regards,
Peter Fejes 


----- End forwarded message -----

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

[L2tpd-devel] 0.62 released

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

'evening everyone,

L2TPd 0.62 was released a few hours ago on our main projects page. It
includes all of the changes that Jeff has been hacking at. In the coming
week or so, as soon as I can figure out how to make CVS branch tags, I will
be starting a separate CVS tree for 0.7. This will be our tree for the
complete rewrite from spec. In this manner we can develop the rewrite while
continuing bugfixes on the stable branch (0.6). If this smells like the
Linux kernel development, I thought so myself. Odd-numbered versions for
development, and even for stable releases.

Anyway... Here's looking forward to 0.63 and 0.7.0.1... whenever either of
them come out. ;)

--Scott

Re: [L2tpd-devel] 0.62 release?

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

Also sprach Scott Balmos
>Okay let me see if I have the Changelog correct...

Pretty much covers what I've done I believe...
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

RE: [L2tpd-devel] 0.62 release?

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

Okay let me see if I have the Changelog correct...

0.62
--
Removed call flow/session control (inapplicable as of RFC spec draft 13)
Corrected invalid Receive Window Size AVP in ICCN
Corrected Bearer Capabilities non-requirement in SCCRQ & SCCRP
Verified operability with Cisco 3000 series products

If this is all correct, I'll type up a changelog file, putter on over to the
Sourceforge shell cluster, update our version numbers, and toss out a
package. Everything okay, then?

--Scott

-----Original Message-----
From: l2t...@li...
[mailto:l2t...@li...]On Behalf Of Jeff
Mcadams
Sent: Monday, March 19, 2001 3:51 PM
To: l2t...@li...
Subject: [L2tpd-devel] 0.62 release?


I'm thinking maybe we need 0.62...I'm running into more problems that
people are having as a result of the flow control stuff on the
call/sessions.

I feel pretty comfortable with the reliability and interoperability of
the code after the removal of the flow control code on the calls, and it
looks like its a signficant enough problem that it might be worth
putting out a 0.62 to address it.
--
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] 0.62 release?

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

I'm thinking maybe we need 0.62...I'm running into more problems that
people are having as a result of the flow control stuff on the
call/sessions.

I feel pretty comfortable with the reliability and interoperability of
the code after the removal of the flow control code on the calls, and it
looks like its a signficant enough problem that it might be worth
putting out a 0.62 to address it.
-- 
Jeff McAdams                            Email: je...@ig...
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456