On Aug 29, 2008, at 11:23 PM, Alan DeKok wrote:
Jeffrey Sewell wrote:
I've got a FreeRADIUS server that takes in Accounting data that is
proxied to it from another server. In the Accounting packets I see
AVPs
that are tagged "Unknown-Attribute."
Hm... unknown attributes should be printed as Vendor-123-Attr-456.
I'm going off the raw tcpdump view, maybe they get translated at a
higher level. I'll re-check.
I assume that's because either the
originating server or the FreeRADIUS server is missing a dictionary
file/entry to identify the Attribute.
The proxying server is missing the dictionary entries.
First question: is that assumption correct?
Yes.
Cool, at least I know where to start.
If so, who sets that Attribute, the originator or the target?
The originator sets the *number* of the attribute. The proxy uses
that number to look up a name in the dictionaries.
And more generally: as these are written to the MySQL DB I see that
they
are pulled off the packet and stored as variables that are
accessible in
the sql.conf file for example:
AcctSessionTime = '%{Acct-Session-Time}'
Is that variable pulled directly from the packet? So that whatever
attribute is in the packet, it will be named %{whatever} ?
It will look up the name in the dictionary, get the number, and then
look up the relevant numbered attribute from the packet.
So could I pull in any dictionary entry based on number? What's the
syntax for that?
I've got other data coming in that I need to store in the SQL DB and
suppose that I'll need to modify the sql.conf and the radacct table
in
order to get them in there.
Yes.
You may want to take a look at
raddb/sites-available/robust-proxy-accounting. It documents a
method of
proxying transparently when the home server is up, and writing to
local
disk when it's not. When the home server comes back up, the packets
written to disk are forwarded automagically.
You may also want to look at raddb/sites-available/buffered-sql for
the "write to SQL" portion. Some people have seen significant
performance improvements by using this method. i.e. writing all
packets
directly to SQL can often thrash the SQL server.
Definitely good advice. Thank you!
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
