From owner-freebsd-jail@FreeBSD.ORG Wed Sep 19 21:38:30 2007 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB84416A419; Wed, 19 Sep 2007 21:38:30 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id AA70513C458; Wed, 19 Sep 2007 21:38:30 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id l8JLcTup029458; Wed, 19 Sep 2007 16:38:29 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id l8JLcTxR029457; Wed, 19 Sep 2007 16:38:29 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Wed, 19 Sep 2007 16:38:29 -0500 From: Scott Lambert To: "Bjoern A. Zeeb" Message-ID: <20070919213829.GA39059@sysmon.tcworks.net> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-stable@freebsd.org References: <20070918192933.GC71361@sysmon.tcworks.net> <20070919202625.Y58095@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070919202625.Y58095@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.2i Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Problems with FreeRADIUS in a jail X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 21:38:31 -0000 On Wed, Sep 19, 2007 at 09:05:38PM +0000, Bjoern A. Zeeb wrote: > 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. Yeah, I dug in and tried to prove myself right yesterday. I was completely wrong. I don't know how that ended up working on all of my test cases. > > 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). That's my impression. > 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... I wish my wild guesses were a tenth that good. Last night, I found a place where they unconditionally set reply->dst_ipaddr = client_ipaddr. I think that is exactly what you are postulating above. It looks like they had reasons for setting that, but I can't tell what circumstances would necessitate it. I posted another message to the thread about that but Alan hasn't responded to that post just yet so either he didn't have time to mess with me today, or he may be checking into the validity of that unconditional assignment. I'm hoping for the latter because I would like to get this resolved and move on with putting it in production. :-) Thanks for the help! -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org