On Fri, 17 Sep 2010, Hugh Irvine wrote:
> Hello Heikki, Hello Jethro -
>
> Yes correct - if you want the decoded values you should use a ClientHook
> instead of a PreClientHook.
In my case, the messages are being generated in an AuthLog referenced from
a Handler. There does happen to be a PreClientHook statement associated
with that Handler but I don't what that's got to do with the Handler
logging. E.g.:
<Handler Realm=/^($|strath\.ac\.uk$)/>
Identifier strathrealm
...
AuthLog authlog
<AuthLog FILE>
Identifier authlog
Filename %L/auth
LogSuccess 1
LogFailure 1
SuccessFormat %l OK \
client=%C \
clientip=%c \
clientident=%{Client:Identifier} \
# nasip=%N \
nasip=%{NAS-IP-Address} \
...
nasip=%{NAS-IP-Address} works, nasip=%N doesn't.
Jethro.
Jethro.
>
> regards
>
> Hugh
>
>
> On 17 Sep 2010, at 10:02, Heikki Vatiainen wrote:
>
> > On 09/17/2010 05:43 PM, Jethro R Binks wrote:
> >
> >> With reference to the problem I observed when upgrading to 4.6, where
> >> special character %N (ref: "The NAS-IP-Address in the current request (if
> >> any)") is printed "raw"
> >>
> >>> Mon Apr 26 00:03:26 2010 OK client=tambala.net.strath.ac.uk
> >>> clientip=130.159.17.137 clientident=SquidProxy nasip=<82><9F>^Q<89>
> >> nasid=
> >>> naspttype= requser=abc replyuser= outeruser=abc eapidentity=,
> >>> calling-st-id= called-st-id= fr amed-ip-addr= handler=strathrealm
> >>> rmessage=
> >> ...
> >>> So note "nasip=<82><9F>^Q<89>". This is actually my terminal's
> >>> representation of the hi-bit characters, and it turns out they are the
> >> hex
> >>> equivalent of the IP address: 0x82h == 130, 0x9f == 159, etc. Before
> >> 4.6
> >>> (3.17.1 previously) this was seamlessly translated to a printable IP
> >>> address, but it now appears this is being printed "raw".
> >
> > The messages from Apr 26, are they from a hook?
> >
> > If I remember correctly there have been changes to packet processing
> > that affected the moment of decoding and translation of packet contents.
> >
> > So if the messages are for example, from a PreClientHook the following
> > note from the manual may apply.
> >
> > 5.4.27 PreClientHook
> > ...
> > Caution: At the time this hook is run, integer attributes have not yet
> > been unpacked and decoded, and encrypted attributes have not yet been
> > decrypted. If you need unpacked, decrypted versions of these attributes,
> > consider using a per-client ClientHook instead.
> > ...
> >
> > --
> > Heikki Vatiainen, Arch Red Oy
> > +358 44 087 6547
> > _______________________________________________
> > radiator mailing list
> > radiator@open.com.au
> > http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
>
>
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Computing Officer
Information Services, The University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
