Hi!

It seems you're right.

Glad that I'm not just plain stupid :-)

The 1.1.0 source has in rlm_preprocess:

static int hints_setup(PAIR_LIST *hints, REQUEST *request) { char *name; VALUE_PAIR *add; VALUE_PAIR *tmp; PAIR_LIST *i; VALUE_PAIR *request_pairs;

request_pairs = request->packet->vps;

if (hints == NULL || request_pairs == NULL) return RLM_MODULE_NOOP;

i.e. if there's no username, which there isn't in an Acct-On/Off, skip processing.

Well, the accounting packet does contain several value pairs, so I would be surprised that the request_pairs == NULL condition is fulfilled. I mean, if you look at that packet I sent, it contains NAS-Identifier and lots of others, and these _are_ VPs, no?

This makes sense of course, because the "hints" file refers to hint strings in the USERNAME, such as "username.ppp" meaning to start PPP.

That's not how I read the comments in hints: # The hints file. This file is used to match # a request, and then add attributes to it. There's some mention of some special rules "Prefix" and "Suffix", and _these_ can only work on the User-Name. Anything else should be doable anyway.

Sadly you can't use an ordinary "users" file, because you want to add the RESTENA-Service-Type to the INPUT AVPs. You could add it to the config AVPs then do this:

detailfile = path/%{config:RESTENA-Service-Type}-service/detail

...but sadly the "users" file can't add arbitrary things to config items; just AVPs it "knows" are server AVPs.

You could use a "passwd" module instance like this:

modules { passwd accttype { filename = /path/to/file # lookup on *ed field; ~ed are added to request; unprefixed # are added to configure; =ed are added to reply format = "*Client-IP-Address:~RESTENA-Service-Type:Acct-Type" hashsize = 100 } } authorize { preprocess accttype # other stuff

Thanks for those workarounds. But, I'm not sure I like them. hints would have made this wonderfully easy... and the way I see the hints file described, I tend to think it should work. Maybe this can be considered a bug? If yes, I might look into the code and submit a patch. Just give me a go-ahead... Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu     Tel.:    +352 424409-1 http://www.restena.lu               Fax:      +352 422473

...

That's not how I read the comments in hints:

# The hints file. This file is used to match # a request, and then add attributes to it.

There's some mention of some special rules "Prefix" and "Suffix", and _these_ can only work on the User-Name. Anything else should be doable anyway.

That's definitely what that file does. The "hints" the filename refer to are hints that the USER submits in their authentication request, by

Well, I am probably not long enough in the RADIUS business to remember the historical reasons for the hints file. For me, hints is the only means to manipulate input avp items in a packet. And a very flexible solution too, since it does "users" style mangling. And the comments in the file don't say "but whatever you put in here will be ignored if there is no attribute User-Name in the request".

prefixing, suffixing or otherwise formatting their username (the only value the user has total, sensible control over). It's an old method that the ancestors of FreeRadius used extensively. The examples in the default hints file make it pretty clear how it was originally intended to be used.

Yeah, but what if I want to go beyond the examples? This file is so flexible, it would be a shame to arbitrarily limit it by requiring User-Name to be present.

Certainly that's not what hints used to do. It may make sense to update the function of hints, since it is indeed a wonderfully flexible and easy way to alter / add to the incoming request. But it's definitely not a "bug" per se.

Fine for me, let's call it a feature request.

The patch looks relatively trivial. Simply delete the check for null usernames. In *fact*, I don't think the left hand side of the "users" entries in that file is used at all.

I just submitted bug #335 http://bugs.freeradius.org/show_bug.cgi?id=335 with the (really trivial) patch to the bug database. Actually, it will make packet processing in the server faster: almost all packets have User-Name anyway, so for each of these packets, the if condition checking is saved. And only for those packets without, Accounting-On/Off, processing time will get slightly larger by running through hints (but given he seldom these packets usually come, this is negligible). Greetings, Stefan Winter -- Stefan WINTER RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu     Tel.:     +352 424409-1 http://www.restena.lu               Fax:      +352 422473

Stefan Winter wrote:

...

...

That's not how I read the comments in hints:

# The hints file. This file is used to match # a request, and then add attributes to it.

There's some mention of some special rules "Prefix" and "Suffix", and _these_ can only work on the User-Name. Anything else should be doable anyway.

That's definitely what that file does. The "hints" the filename refer to are hints that the USER submits in their authentication request, by

Well, I am probably not long enough in the RADIUS business to remember the historical reasons for the hints file. For me, hints is the only means to manipulate input avp items in a packet. And a very flexible solution too, since it does "users" style mangling. And the comments in the file don't say "but whatever you put in here will be ignored if there is no attribute User-Name in the request".

...

prefixing, suffixing or otherwise formatting their username (the only value the user has total, sensible control over). It's an old method that the ancestors of FreeRadius used extensively. The examples in the default hints file make it pretty clear how it was originally intended to be used.

Yeah, but what if I want to go beyond the examples? This file is so flexible, it would be a shame to arbitrarily limit it by requiring User-Name to be present. You don't have to have a User-Name in the request to use that file. If it isn't there and you need it for further processing you can add it.

-- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602-8044 Off. 325-691-3301 Cell 325-439-0533 fax 325-695-6841

On Wed, 2006-22-02 at 07:34 +0100, Stefan Winter wrote:

Hi,

...

You don't have to have a User-Name in the request to use that file. If it isn't there and you need it for further processing you can add it.

Well, no. That's exactly the point: the hints file is *skipped* if there is no User-Name in the request.

Greetings,

Stefan Winter The hints file was originally designed to classify users and determine what methods of connection were allowed, by using an uppercase character or other pattern. It provided a similar function to what groups are now used for, before groups were implemented. The letter or pattern could be removed before authentication if desired.

Examples : Uacct01 = UUCP user acct01 Pacct02 = PAP user acct02 Cacct03 = CHAP user acct03 etc. The Accounting-On is a status messages from the NAS indicating that no users are currently logged on and that accounting will start. The Accounting-Off is a status messages from the NAS indicating that all users logged in are being logged off and that accounting will stop. There is no relationship to any specific account, so hints is not supposed to be used. If you are using hints to do some other kind of processing, you are likely using it for something it was not intended for. If you are using an SQL backend for accounting the Accounting-On / Accounting-Off packets are handled by the sql configuration to mark all active as stopped for the NAS that sent the packet.