Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 May 2007 00:51:18 -0700
From:      Brian Somers <brian@Awfulhak.org>
To:        Roman Bogorodskiy <novel@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/usr.sbin/ppp command.c ppp.8.m4 radius.c radius.h
Message-ID:  <20070529005118.63a62eb4@dev.lan.Awfulhak.org>
In-Reply-To: <20070528045306.GA987@underworld.novel.ru>
References:  <200705251345.l4PDjoEW059652@repoman.freebsd.org> <20070527233522.E13311@maildrop.int.zabbadoz.net> <20070528045306.GA987@underworld.novel.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 May 2007 08:53:06 +0400 Roman Bogorodskiy <novel@FreeBSD.org> wrote:
>   Bjoern A. Zeeb wrote:
> 
> > On Fri, 25 May 2007, Roman Bogorodskiy wrote:
> > 
> > >novel       2007-05-25 13:45:49 UTC
> > >
> > > FreeBSD src repository (ports committer)
> > >
> > > Modified files:
> > >   usr.sbin/ppp         command.c ppp.8.m4 radius.c radius.h
> > > Log:
> > > Add a new option for ppp.conf: rad_port_id. It allows to
> > > change the way of what ppp submits to the RADIUS server
> > > as NAS-Port-Id. Possible options are: the PID of the process
> > > owning the corresponding interface, tun(4) interface number,
> > > interface index (as it would get returned by if_nametoindex(3)),
> > > or it's possible to keep the default behavior. Check the ppp(8)
> > > manual page for details.
> > >
> > > PR:             bin/112764
> > > Submitted by:   novel (myself)
> > > Reviewed by:    flz
> > > Approved by:    flz
> > > MFC after:      1 month
> > >
> > > Revision  Changes    Path
> > > 1.307     +27 -1     src/usr.sbin/ppp/command.c
> > 
> > @@ -144,6 +144,7 @@
> >  #define        VAR_IPV6CPRETRY 37
> >  #define        VAR_RAD_ALIVE   38
> >  #define        VAR_PPPOE       39
> > +#define        VAR_PORT_ID     40
> > 
> > Was there some reason the VAR_ and the NEG_ defines were in
> > different ranges? If so there is a conflict now and maybe we
> > should move the NEG_ defines to 128+?
> 
> I cannot see any conflicts, however it doesn't mean it could not exist.
> Anyway, it seems to be a good idea to move NEG_ to 128+ to avoid
> possible confusing and have a room for other 'set' we would want to add
> in the future.
> 
> A simple patch attached.
>  
> > > 1.326     +20 -1     src/usr.sbin/ppp/ppp.8.m4
> > > 1.54      +27 -10    src/usr.sbin/ppp/radius.c
> > > 1.22      +6 -0      src/usr.sbin/ppp/radius.h
> > >
> > 
> > -- 
> > Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
> > _______________________________________________
> > cvs-all@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/cvs-all
> > To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
> 
> Roman Bogorodskiy

The only reason these "look" like the same namespace was to
debug stuff when I first developed it.  The namespace is
different for each function that the values are passed to,
so VAR_* is only used by SetVariable() and NEG_* is only
used by NegotiateSet().

These defines should probably be enums with no value
assignments.

-- 
Brian Somers                                          <brian@Awfulhak.org>
Don't _EVER_ lose your sense of humour !               <brian@FreeBSD.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070529005118.63a62eb4>