Calling-Station-Id

[Michel Bulgado]

Bjørn Mork wrote:
> Michel Bulgado <michel at casa.co.cu> writes:
>
>   
>> Try this way, remember the operator.
>>
>> |312|test at internet.quimefa.cu|Calling-Station-Id | += | "72061490"
>> |298|test at internet.quimefa.cu|MD5-Password       | := | password
>> |313|test at internet.quimefa.cu|Calling-Station-Id | += | "72061490"
>>     
>
>
> Please read the manual.  In this case, that's users(5):
>
>        Attribute += Value
>             Always matches as a check item, and adds the current attribute with value to the list of configuration items.
>             As a reply item, it has an identical meaning, but the attribute is added to the reply items.
>
>
> This means that the 3 lines
>
>  |312|test at internet.quimefa.cu|Calling-Station-Id | += | "72061490"
>  |298|test at internet.quimefa.cu|MD5-Password       | := | password
>  |313|test at internet.quimefa.cu|Calling-Station-Id | += | "72061490"
>
> are identical to the single line
>
>  |298|test at internet.quimefa.cu|MD5-Password       | := | password
>
> and the user will be accepted regardless of Calling-Station-Id.
>
>
>   
>> suffix] Looking up realm "internet.quimefa.cu" for User-Name = "test at internet.quimefa.cu"
>> [suffix] No such realm "internet.quimefa.cu"
>>     
>
> This is normal, and no problem.  You may define a realm using LOCAL
> authentication to avoid it, but it won't change anything except remove
> the debug message.
>
>   
>> sql] User test at internet.quimefa.cu not found
>> ++[sql] returns notfound
>>     
>
> The sql module returns notfound if the check items don't match.  This is
> expected in this case as I explained:  Two different equality tests on a
> single attribute will never match.
>
>
>   
>> But in the end because it connects the user's which is declared in the file "users". apparently
>> you have stated that locate the user in the database and also in this
>> file, you must define where you will store your users and then put the
>> phone number.
>>     
>
> The debug output showed that the user matched a DEFAULT entry in users.
> That's a perfectly normal configuration.   
>
> In fact, there is no problem defining the same user in both "users" and
> sql (and possibly other modules as well).  The control and reply lists
> of the matching entries just add up, and the final result is then
> evaluated. 
>
> But I agree that for simplicity it's probably best to define the
> specific user entries in one place.  And that's what Osmany has done.
> The DEFAULT entry is probably just adding something generic, which is
> common for all users.
>
>
>
> Bjørn
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Thanks for the class, as we say in our country: "Every day you learn 
something new."

There are no problems is to define a user, in fact he did on both sides, 
in the file "users" and database "sql". I would do it in one place, so 
you do not go crazy when you add a user or update any information of it, 
for example the phone number where you will be connected.

Although the problem persists, the user can connect from any other phone 
number and may not be a problem of operator, but this by specifying the 
number in a single place, and not in the sql file "users".

Assuming this well held on both sides and again I'm wrong, maybe in the 
section "authorize" I miss you to use the module "checkval.

Even so if you could post your configuration, would be useful.

Don't you think?