Hi Neale -
On Wednesday 30 May 2001 23:24, Neale Banks wrote:
> G'day Hugh,
>
> > I would like to see some packet dumps from this proxy, as rewriting the
> > NAS-IP-Address is completely bogus.
>
> Packet dumps coming separately. I agree that rewriting the NAS-IP-Address
> is just "not Cricket" - and rewriting them all to the same value isn't
> even Ice Hockey ;-)
>
> > In any case, as you rightly point out, the standard Radiator behaviour is
> > based on a unique NAS-IP-Address/NAS-Port tuple, and if this is not
> > unique then you will have problems.
>
> Yes. Looking a bit further under the hood at the Radiator (yes, pun
> intended ;-) I see that it's actually "$nas_id:$nas_port" that must be
> unique and that Radius.pm first tries NAS-IP-Address then NAS-Identifer
> when determining $nas_id - fine but for this bit of Radius.pm:
>
> # Theres no Nas-IP-Address, so try for NAS-Identifier
> my $nas_id = $self->getAttrByNum
> ($Radius::Radius::NAS_IDENTIFIER);
> if ($nas_id =~ /(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/)
> {
> $self->{CachedAttrs}{NasId} = $1;
> }
>
> Not being a perl programmer, I struggle - but that does look mightily like
> as if NAS-Identifier will only get into $nas_id if NAS-Identifier looks
> like an IP Address in dotted-quad format. But RFC2865 defines
> NAS-Identifer as a string, so it can legitimately take almost any form.
> What have I missed?
>
> > You basically have two options. The first is to find something in the
> > packet that is unique and use that. And the second is to do some
> > manipulation of the contents of one or more attributes to generate
> > something unique.
>
> Agreed. And as I can't find anything unique-to-NAS in the packet, that
> leaves manipulation.
>
> > In either case, I would use an SQL session database and set up your own
> > queries in the SessionDatabase SQL clause, which avoids having to mess
> > around with the standard Radiator code.
>
> What a fiendishly clever idea! Unfortunately there's no convenient SQL
> repository right now - but I'll definitely keep that one in mind.
>
> > One note on your hack-around below - by definition the Access-Request's
> > will not contain an Acct-Session-Id (at least I would be surprised if
> > they did), so I doubt that you will be able to do what you describe.
>
> No, the Access-Request does include Acct-Session-Id (according to the
> RFC2866 it MAY do this: "An Access-Request packet MAY have an
> Acct-Session-Id; if it does, then the NAS MUST use the same
> Acct-Session-Id in the Accounting- Request packets for that session" -
> hopefully it's only an oversight that that last MUST is not currently
> being complied with).
>
Quite right - I've just never seen it before.
> I think this whole problem would go away if:
>
> * the proxy did NOT send NAS-IP-Address at all (or we strip it out), and
> * the proxy sent NAS-Identifier (with a suitable per-NAS value, or we
> construct this Attribute with a suitable value), and
> * Radiator was happy with the format of the NAS-Identifier.
>
You can easily strip out or modify the NAS-IP-Address in a PreClientHook (see
the file "goodies/hooks.txt").
Radaitor will be happy with a string format.
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
