this is great, thanks. 

J.

On Wed, Jul 07, 2004 at 04:56:49PM +0200, Matthias Ferdinand wrote:
> Hello,
> 
> I have tried to make sense of our patches and distill a description for 
> them, which you can find below. Since the patch file itself is about 45k, I 
> will just post the URL where you can find it:
>   http://www.14v.de/l2tpd/
> 
> 
> Regards / Mit freundlichen Gruessen
>  Matthias Ferdinand
> -- 
> one4vision GmbH
> Goethestrasse 3-5
> D-66121 Saarbr?cken
> Tel: +49 681 96727 60            [EMAIL PROTECTED]
> Fax: +49 681 96727 69            http://www.one4vision.de
> 
> 
> --------------------------------------------------
> 
> Description of l2tpd-diffs-14v-20040706.txt
> 
> 
> BUGFIXES:
> 
> * network.c:network_thread()
>     re-alloc buf after handle_special() has toss()ed it
> 
>     when receiving a packet on a valid tunnel but on a
>     non-existent call, handle_special() would toss() our
>     buf, but the loop would continue using it, sometimes
>     completely messing up malloc's internal data structures
>     and segfaulting in many interesting places
> 
> * call.c:new_call(struct tunnel *parent)
>    initialize ourcid to 0 if parent->self is not set
>    (value used in log messages and valgrind complained)
> 
> * control.c:control_finish()
>     added missing malloc for challenge data
>     (macro "MALLOC_CHALLENGE")
> 
> * l2tpd.c:destroy_tunnel()
>     use new variable for walking through the list of calls
>     c->next should not be used after c has been free()'d
>     (valgrind complained)
> 
> * l2tpd.c:new_tunnel()
>     initialize "self" to NULL
>     (valgrind complained)
> 
> * l2tpd.c:daemonize()
>     reading previous pid file: fixed typo;
>        use return value from read() instead of from open()
> 
> * control.c:expand_payload()
>    ??? is this correct now ???
>    new_header->Ns compared to c->data_rec_seq_num
>     (before: comparison with c->data_seq_num)
> 
> * scheduler.c:alarm_handler()
>    added decrement cnt before return()ing when
>      re-entrance is detected.
>    seems to happen only when running with valgrind
> 
> * misc.c:log()
>     call openlog() only on first invocation
>     if running as daemon, don't log to stdout; would be
>       received and dismissed by pppd, increasing error counters
>     avoid re-entering call to syslog() (not reentrant);
>       strangely this only shows up when running with valgrind
> 
> * Makefile
>     object files depend on header files, too
> 
> FEATURES/IMPROVEMENTS/WORKAROUNDS:
> 
> * call.c:read_packet()
>     if read() returns EBADF (Bad File Descriptor),
>       don't retry, return immediately (pppd has died)
> 
> * l2tpd.c:daemonize()
>     start up when pid file exists but is empty (pid==0)
> 
> * l2tpd.c:start_pppd()
>     delay parent execution for 300ms after fork()
>     this is workaround for tty echo (?) until pppd is started
>     some remote ppp clients will think they are looped when
>       they see their own packets coming back and will fail
>       even before our local pppd is finished loading
> 
> * l2tp.h/l2tpd.c/Makefile
>     added Macro SPECIAL_VERSION
>     to distinguish between different builds
>     can be an argument to make
>     from our build script:
>        SNAPSHOT=20040504
>        export SPECIAL_VERSION="'\""-$SNAPSHOT"\"'"
>        if ! make ; then ...
> 
>     shell + C escaping is ugly, but can be done somehow...
> 
> * control.c:control_finish()
>    use configured hostname from l2tpd.conf in AVP
>    (add hostname parameter to add_hostname_avp() )
> 
> * l2tpd.h:struct tunnel
>     added char *tunneltag to struct tunnel
>     used in log messages to associate log events with tunnels
>   control.c:get_tunneltag(struct tunnel *t)
>     returns string representation of a tunnel, e.g.
>       80.131.23.17:1701/rt=5/lt=49803
>          host:port/rt=<remote tunnel id>/lt=<local tunnel id>
>   control.c:control_finish(), ... case SCCRP:
>      set tunneltag of current tunnel
>   l2tpd.c:destroy_tunnel()
>      free memory of t->tunneltag
>   l2tpd.c:new_tunnel()
>      initialize tunneltag to NULL
> 
> * set "ipparam" argument for pppd
>  can be used e.g. in ip-up script
> 
>    file.c:struct keywords words[]
>      add keywords "ipparam" (string),
>                   "ipparam_tunneltag" (bool)
>    file.c:set_ipparam()
>    file.c:set_ipparam_tunneltag()
> 
>    control.c:control_finish(), ... case ICCN:
>        if "ipparam" is set in l2tpd.conf, this value is
>        copied verbatim as "ipparam <value>" as argument
>        to pppd.
>        if "ipparam_tunneltag" is set in l2tpd.conf, the
>        string "l2gw=<tunneltag>" is appended to above
>        <value> for the ipparam argument
>        Note: <value> is statically configured,
>              <tunneltag> may vary with every connection
> 
> 
> * configurable output file for l2tpd status reports (SIGUSR1)
> 
>     file.c:struct keywords words[]
>              add keyword "statusfile" (default: /var/run/l2tpd.status)
>            char *l2tpdstatusfile;
>            set_statusfile()
>     l2tpd.c:status_handler()
>            write report to statusfile instead of stdout
>     l2tpd.c:show_status()
>            add info about ptyname, peer, ids, ...
>     l2tpd.c:start_pppd()
>            save ptyname in c->ptyname
>     call.c:new_call()
>            initialize ptyname to NULL
>     call.h:struct call
>            add char ptyname[6]
> 
> * configurable "listenaddr"
>     l2tpd only binds to this address instead of "0.0.0.0"
> 
>     file.c:struct keywords words[]
>              add keyword "listenaddr"
>            set_listenaddr()
>            unsigned int listen_addy moved here from network.c
> 
> 
> 

-- 
--

-> Jean-Francois Dive
--> [EMAIL PROTECTED]

  I think that God in creating Man somewhat overestimated his ability.
    -- Oscar Wilde

Reply via email to