Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Sep 2007 21:05:38 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Scott Lambert <lambert@lambertfam.org>
Cc:        freebsd-jail@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: Problems with FreeRADIUS in a jail
Message-ID:  <20070919202625.Y58095@maildrop.int.zabbadoz.net>
In-Reply-To: <20070918192933.GC71361@sysmon.tcworks.net>
References:  <20070918192933.GC71361@sysmon.tcworks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Sep 2007, Scott Lambert wrote:

Hi,

> I've been trying to get FreeRADIUS 2.0 working inside a FreeBSD
> 6.2-STABLE jail.
>
> The work I've been doing with the Alan DeKok of FreeRADIUS starts with
> this message:
>
> https://lists.freeradius.org/pipermail/freeradius-users/2007-September/065883.html
>
> Here is the thread index :
>
> https://lists.freeradius.org/pipermail/freeradius-users/2007-September/thread.html#65883
>
> I am way out of my depth at this point.  I thought I had the problem
> found yesterday in FreeRADIUS but Alan says what I did to "fix" it
> shouldn't work at all.

if you mean the == INADDR_ANY => != change, Alan should be right from
the code you pasted into the mails.


>  He seems to think it is a jail problem.

I haven't read their code but from what I got in the thread it sounds
like they seem to be overly clever doing assumtions that are just
wrong (no matter if it's a jail or not).

So it seems

C: bind(INADDR_ANY)
C: getsockname returns an address inside the jail
C: packet gets out to dstaddr

S: the packets gets proccessed
S: a reply is send to the IP address from the dstaddr (as used by the client)
    and it should always be that way (no matter if the C: is in jail or not)

C: packets is recved
C: ip address is checked and to whatever it would be checked should
    match - in case they have the IP address it would match, in case they
    bound to inaddr_any all addresses should match.

They might have problems matching up their internal state or
overwriting something somewhere.

I would assume what could happen is that bind to INADDR_ANY,
getsockname returns != INADDR_ANY thus inaddr_any = 0;
On recv. they fill in the match from the Client = * definition
which would be INADDR_ANY but inaddr_any is set to 0 and thus the
check on the ip address does not match because they would need both
INADDR_ANY and inaddr_any = 1 for that (for whatever reason they need
to duplicate that information).

But that's just a wild guess...

-- 
Bjoern A. Zeeb                                 bzeeb at Zabbadoz dot NeT
Software is harder than hardware  so better get it right the first time.



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