Unknown AVPs

[Jeffrey Sewell]

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