accounting records per nasid, not ip address

classic Classic list List threaded Threaded
6 messages Options
| Threaded
Open this post in threaded view
|

accounting records per nasid, not ip address

freeradius-2
hi,

this is my first time using freeradius. had a good experience
so far.

i had to coerce the latest cvs version into fedora
core 3 with more hacks than i would have liked, but that's ok,
it's up and running.

one issue i find so far is that my NASs have a dynamic ip.
i managed this externally at great pains, however, for the
purposes of radius accounting, i'd like to see the
accounting records on a per-nasid file in

        /var/log/radius/radacct/<nasid>

rather than what i see now as:

        /var/log/radius/radacct/<ip-address>

i could not find a simple way to do this by looking around, though
i may be missing something. is this doable as-is?
if not, any hint on where to hack this would be greatly appreciated.

while i am on the list, and at the risk of irking someone i would like to
(lazily) ask if anyone knows offhand where can i find a document that i saw a
few months back on "hardening" radiusd.  the process exited on me a couple of
times due to dynamic ip issues, creating multi-hour blackouts that i rather not
see again. looking for freeradius hardening or crashing i cannot seem to find
that most excellent list of things to restart or manage a crashed server.

thanks in advance!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: accounting records per nasid, not ip address

Alan DeKok
[hidden email] wrote:
> i had to coerce the latest cvs version into fedora
> core 3 with more hacks than i would have liked,

  Such as...?

  It's a development version, so not everything works.

> one issue i find so far is that my NASs have a dynamic ip.

  That's evil.  Very evil.

> i managed this externally at great pains, however, for the
> purposes of radius accounting, i'd like to see the
> accounting records on a per-nasid file in
>
> /var/log/radius/radacct/<nasid>
>
> rather than what i see now as:
>
> /var/log/radius/radacct/<ip-address>

  Step 1: Find out which module writes those files
  Step 2: Edit the modules configuration

  See "radiusd.conf".  You're probably looking for th e"detail" module.

> while i am on the list, and at the risk of irking someone i would
> like to (lazily) ask if anyone knows offhand where can i find a
> document that i saw a few months back on "hardening" radiusd.  the
> process exited on me a couple of times due to dynamic ip issues,
> creating multi-hour blackouts that i rather not see again. looking
> for freeradius hardening or crashing i cannot seem to find that most
> excellent list of things to restart or manage a crashed server.

  doc/supervise-radiusd.txt

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

VSA id's higer than 255

Fawaz Qamhawi


We are using freeradius 1.0.4 and having a problem with
VSA id's higher than 255 (more than 8 bit).

ATTRIBUTE       Ascend-Http-Redirect-URL                287     string
Lucent
ATTRIBUTE       Ascend-Http-Redirect-Port               288     integer
Lucent

When one of the attributes above are sent back to the NAS,
it seems that radius is sending it as 8 bit thus interpreted as something
else
on the Lucent NAS.

Any simple solution for that ?


Best Regards
/ Fawaz


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: VSA id's higer than 255

Alan DeKok
Fawaz Qamhawi <[hidden email]> wrote:
> We are using freeradius 1.0.4 and having a problem with
> VSA id's higher than 255 (more than 8 bit).

  Hmm.. those aren't in the standard dictionaries that I can see.

> When one of the attributes above are sent back to the NAS,
> it seems that radius is sending it as 8 bit thus interpreted as something
> else on the Lucent NAS.

  The code in src/lib/radius.c is responsible.  It should be checking
for attributes above 255, and discarding them.

> Any simple solution for that ?

  How are the attributes supposed to be encoded in the packet?  The
normal VSA's use one byte to represent vendor attributes.  Since 287
won't fit into ne byte, something else has to be done here.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: VSA id's higer than 255

Michael Lecuyer
Ascend (as Lucent) has been introducing tags with values higher than 256
in the VSA's for a while (first message I saw where the problem of long
tags was mentioned was from January 2004).  An example from their
dictionary shows:

ATTRIBUTE       Ascend-MOH-Timeout              261     integer

The format for the long tag VSA is the same as the standard
Vendor-Specific attribute (8 bit tag, 8 bit length) but the
sub-attribute tag field has been expanded to 16 bits. The sub-attribute
length field remains 8 bits.

All vendor specific attributes are coded using 16-bit attribute type in
network byte order and Lucent-Vendor-Id (4846) as Vendor-Id.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Attr Type     |   Length      |           Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Vendor-Id (cont)          |         Vendor Type(16-bit)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor Length |  Vendor-value......
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

I believe the support for long Vendor-Specific tags was discussed here
in the past with limited interest in support.

It seems that this is on a NAS by NAS basis and only some of the VSA's
are using the 16 bit tags. The solution seems to be to indicate that
long tags are used by this NAS for particular vendors. Something like:

192.168.1.1 ... VendorLongTags=Ascend
- indicating that Ascend VSA's use long tags and all other VSA's like
Cisco) would be short. Ascend / Lucent VSA's do not always use long tag
VSAs.

This introduction of long tags is a real wart for every RADIUS server.
There are probably other ways to have avoided 16 bit tags. Naturally the
offender is too big to ignore and arbitrarily forced the issue. Remember
that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS
attributes (from 119 to 255) without thinking there might be a problem
with that either.

Alan DeKok wrote:

> Fawaz Qamhawi <[hidden email]> wrote:
>>Any simple solution for that ?
>
>
>   How are the attributes supposed to be encoded in the packet?  The
> normal VSA's use one byte to represent vendor attributes.  Since 287
> won't fit into ne byte, something else has to be done here.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: VSA id's higer than 255

Alan DeKok
Michael Lecuyer <[hidden email]> wrote:
> The format for the long tag VSA is the same as the standard
> Vendor-Specific attribute (8 bit tag, 8 bit length) but the
> sub-attribute tag field has been expanded to 16 bits. The sub-attribute
> length field remains 8 bits.

  That doesn't sound too bad.

> All vendor specific attributes are coded using 16-bit attribute type in
> network byte order and Lucent-Vendor-Id (4846) as Vendor-Id.

  That makes it easier.

> I believe the support for long Vendor-Specific tags was discussed here
> in the past with limited interest in support.

  It's about 40 lines of code to support.  The weirdness that I recall
was Nortel, which mixed normal VSA's, and USR-style VSA's in the same
vendor space.

> 192.168.1.1 ... VendorLongTags=Ascend
> - indicating that Ascend VSA's use long tags and all other VSA's like
> Cisco) would be short. Ascend / Lucent VSA's do not always use long tag
> VSAs.

  If it's always that the Lucent attributes use 16-bit id's, it's OK.

> This introduction of long tags is a real wart for every RADIUS server.
> There are probably other ways to have avoided 16 bit tags. Naturally the
> offender is too big to ignore and arbitrarily forced the issue. Remember
> that in the past Ascend (pre-Lucent) grabbed unassigned RADIUS
> attributes (from 119 to 255) without thinking there might be a problem
> with that either.

  Yup.

  I'll add something to the CVS head.  Grab a snapshot in a few days,
and see if it works.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html