Thanks, I knew where the dictionaries are and read that file. Is there a vendor number that I would use that FreeRADIUS would know not to send in the access-accept message? This is the bit I can't find. thanks, On Fri, May 18, 2012 at 10:57 AM, Alan DeKok <aland@deployingradius.com>wrote:

niall el-assaad wrote:

...

I remember reading somewhere I could define a RADIUS dictionary with certain numbers that FreeRADIUS would not send externally, but after looking for an hour I can't find it.

raddb/dictionary

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

Thanks Alan, All clear now. I was looking at the source and viewing /share/dictionary, not /raddb/dictionary.in A quick grep of what you sent and I'm good. Thanks again, On Mon, May 21, 2012 at 1:46 PM, Alan DeKok <aland@deployingradius.com>wrote:

niall el-assaad wrote:

...

Thanks, I knew where the dictionaries are and read that file.

Well... read it again. It's pretty clear.

...

Is there a vendor number that I would use that FreeRADIUS would know not to send in the access-accept message?

Uh... no. Because the attributes in raddb/dictionary are for that purpose.

...

This is the bit I can't find.

Because it makes no sense.

What part of these comments are unclear?

# If you want to add entries to the dictionary file, # which are NOT going to be placed in a RADIUS packet, # add them here.

Your requirement is to have attributes NOT sent in an Acccess-Accept. So... use the numbers as documented in that file.

Using vendor-specific attributes for that is pointless, wrong, inconsistent, incorrect, broken, and generally a bad idea.

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