Calling-Station-Id

[Bjørn Mork]

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