[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#600465: unblock: freeradius 2.1.10+dfsg-1



[For Alan: I requested for FreeRADIUS 2.1.10 to replace 2.1.9 in the future
Debian 6.0 release; the former came too late in our process to be accepted
automatically.]

On Sun, Oct 24, 2010 at 05:10:58PM +0100, Adam D. Barratt wrote:
> On Sun, 2010-10-17 at 13:45 +0200, Josip Rodin wrote:
> > People keep coming to the upstream freeradius-users mailing list asking for
> > help with 2.0.4, and they increasingly get funny looks because it's a
> > randomly ancient version, by the upstream people's standards.
> > 
> > Right now we have 2.1.8 in squeeze, and I sense the same scenario will
> > unfold, hence this request. This time at least we have roughly the last
> > upstream point release before the cutoff date, but at the same time:
> [...]
> > So hopefully God won't kill any kittens if you just let this one through :)
> 
> For a point release, that's not a small diff. :-/  I've tried reviewing
> it and while some of it makes a fair amount of sense, I don't know the
> product well enough to know whether the rest is fixing important bugs,
> or just tinkering.
> 
> This, from main/events.c, looks obviously wrong, however:
> 
> +       home->zombie_period_start.tv_sec = home->last_packet;
> +       home->zombie_period_start.tv_sec = USEC / 2;
> 
> Presumably the second tv_sec should be tv_usec.

Yeah, that sounds like it to me, too. That change came in this commit
http://github.com/alandekok/freeradius-server/commit/f8bcc0fe
which actually probably fixed a fatal crash (the assert call removed
because "Don't check home->ev due to race conditions."), so that's still
probably better than one randomized zombie period start (which can
get reset and/or ignored soon enough anyway) which is why nobody else
noticed.

Alan, is this correct?

-- 
     2. That which causes joy or happiness.



Reply to: