"Also sprach Jason Lixfeld:"
> Pardon my possible stupidity, but in looking at how to solve my own
> problems, I came across this from man 5 users:
Hi.
I don't presently know where all this stuff should go, since I have
only been using the server for 30 mins, and am pleased to be able to
get it to work and respond! (I tried gnu-radius and gave up in horror).
> DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
> Service-Type = Framed-User,
> Framed-Protocol = PPP,
> Fall-Through = Yes
And where does one put that? Users? I haven't touched that file yet,
so it may be so.
Aren't these lists of things to say on a per user basis? OK - but how am
I supposed to figure out what FOO to send back? It's sent in the
request ...
> If the request packet contains the attributes Service-Type and
> Framed-Protocol, with the given values,
WHAT "given values"? Only one of them has a "given value" in the
example above. Framed-Protocol. That's just bad writing! The other
has "Framed-User" as the value, and I imagine that's a variable
value, taking the value supplied in the field of that name. So
it's not "given".
Yecch. I hate bad writing. It's annoying.
> then include those
> attributes in the reply.
Well, more bad writing. They mean that the DEFAULT line specifies the
conditions that have to be met, and the following lines specify
additions to the outgoing attributes.
OK. I'm game for anything. SO I just have to add:
ptb User-Name == ptb
ARAP-Security-Data = Login-LAT-Node
> That is, give the user what they ask for. This entry also shows
> how to specify multiple reply items.
>
> So something like this may work (but don't hold your breath because I'm
> only guessing!)
>
> joeuser Login-LAT-Node == FOO
> ARAP-Security-Data = FOO
Uh - well, unless I miss MY guess, you also are confused by the poor
writing in the text. The FOO doesn't capture the value like a variable.
The man page is a little better:
Each entry of the file begins with a username, followed by a
(possibly empty) list of check items, all on one line. The next
line begins with a tab, and a (possibly empty) list of reply
items. Each item in the check or reply item list is an attribute
of the form name = value. Multiple items may be placed on one
line, in which case they must be seperated by commas. The reply
items may be specified over multiple lines, in which case each
line must end with a comma, and the last line of the reply items
must not end with a comma.
But they fail to define the terms that may appear on the rhs of == or Æ
signs (and fail to say that == signes may be used ...). However, that's
remedied lower down, where they list the "operators".
Attribute == Value
As a check item, it matches if the named attribute is
present in the request, AND has the given value. Not
allowed as a reply item.
Etc. Unfortunately, failure to define Value ... the only hint that one
may use field names as Values is in the examples section.
DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
Service-Type = Framed-User,
Framed-Protocol = PPP,
Fall-Through = Yes
If the request packet contains the attributes Service-Type and
Framed-Protocol, with the given values, then include those
attributes in the reply.
Which is as you quoted, with defective text as I commented ...
OK. Let's see ...
No, I got the sęme response, but I really have no indication of what
reply is going out or if my new users entry matched anything. How does
one turn on some sort of debugging of the OUTGOING data?
Peter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
