14 Jun
2010
14 Jun
'10
7:58 a.m.
[cc'ed sr-dev]
On Jun 13, 2010 at 11:10, Juha Heinanen <jh(a)tutpro.com> wrote:
Dmitry Kirillov writes:
It looks like he uses modules/auth_radius (which seems to be the k
version) and modules_s/auth. Unfortunately the ser auth api is
incompatible with the k one.
OTOH IMHO the ser auth module is superior to the k one, e.g.:
ser auth:
+ nonce-count/qop=auth* support:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
+ lockless in nonce-count or one time nonce mode
+ extra protection even in non qop=auth mode and non-one-time-nonce mode
(the one time nonce mode has potential issues with retransmissions):
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
+ speed optimized (less syscalls, concurrent access)
+ base64 nonces (shorter)
k auth (at first sight) seems to support only on-time-nonces and their
implementation uses locks (and seems to be more "limited").
Program received signal SIGSEGV, Segmentation
fault.
0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
(gdb) bt
#0 0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
#1 0x28816555 in authorize (_msg=0x8343b58, _realm=0x0, _uri_user=0x0,
_hftype=15) at authorize.c:102
#2 0x288163e8 in radius_proxy_authorize_1 (_msg=0x8343b58, _realm=0x0,
_s2=0x0) at authorize.c:157
i'm not sure what is going on. looks like you are using s version of
auth module, but there pre_auth has five params:
auth_result_t pre_auth(struct sip_msg* msg, str* realm, hdr_types_t hftype,
struct hdr_field** hdr, check_auth_hdr_t check_auth_hdr)
whereas the above seems to indicate that k version of auth module is in
use where pre_auth has four params:
auth_result_t pre_auth(struct sip_msg* _m, str* _realm, hdr_types_t _hftype,
struct hdr_field** _h)
anyway, i only have experience with kamailio_3.0 radius auth, which has
worked fine. perhaps you can try with that too.
We need either to quickly merge the auth apis or revive
modules_s/auth_radius (and probably the other modules_s/*radius).
Unfortunately merging the auth api doesn't look like a quick job:
ser auth api:
+ build_challenge()
+ qop
+ calc_response()
k auth api:
+ rpid_avp
+ rpid_avp_type
+ check_response()
so reviving the modules_s/*radius looks like the quick fix (at least
for 3.0).
So anybody against reviving them in 3.0? (or does anybody remember any
problem with the s versions?)
Andrei
14 Jun
14 Jun
6 a.m.
Andrei Pelinescu-Onciul writes:
We need either to quickly merge the auth apis or
revive
modules_s/auth_radius (and probably the other modules_s/*radius).
Unfortunately merging the auth api doesn't look like a quick job:
ser auth api:
+ build_challenge()
+ qop
+ calc_response()
k auth api:
+ rpid_avp
+ rpid_avp_type
+ check_response()
so reviving the modules_s/*radius looks like the quick fix (at least
for 3.0).
So anybody against reviving them in 3.0? (or does anybody remember any
problem with the s versions?)
fine with me. what modules would you then suggest to use for radius
authorization?
-- juha
8:40 a.m.
On Jun 14, 2010 at 13:00, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
I'm plannig to revert:
commit 456c3c137e9abcf687413f9675fe0f1761ce820d
Author: Juha Heinanen <jh(a)tutpro.com>
Date: Mon Apr 20 08:47:28 2009 +0300
* Modules: auth_radius, misc_radius
Moved modules_k/auth_radius and modules_k/misc_radius to modules and
removed modules_s/auth_radius, modules_s/avp_radius, and modules_s/uri_radiu
This means that when using modules_s/auth, one would have to use
modules_s/auth_radius and for modules_k/auth => modules_k/auth_radius.
We can re-revert the commit once we have the auth apis merged.
Another change that I'm considering is renaming bind_auth, bind_auth_t &
auth_api to *_s and *_k , so that in the future we'll get an error in
this cases (it won't be possible for one module to use the wrong auth
api). This would also allow loading both auth modules in the same time.
Andrei
We need either to quickly merge the auth apis or
revive
modules_s/auth_radius (and probably the other modules_s/*radius).
Unfortunately merging the auth api doesn't look like a quick job:
ser auth api:
+ build_challenge()
+ qop
+ calc_response()
k auth api:
+ rpid_avp
+ rpid_avp_type
+ check_response()
so reviving the modules_s/*radius looks like the quick fix (at least
for 3.0).
So anybody against reviving them in 3.0? (or does anybody remember any
problem with the s versions?)
fine with me. what modules would you then suggest to use for radius
authorization?
6:45 a.m.
Andrei Pelinescu-Onciul writes:
Moved modules_k/auth_radius and
modules_k/misc_radius to modules and
removed modules_s/auth_radius, modules_s/avp_radius, and
modules_s/uri_radius
This means that when using modules_s/auth, one would have to use
modules_s/auth_radius and for modules_k/auth =>
modules_k/auth_radius.
ok, if i remember correctly, there was some features in k version of
auth_radius that were missing from s version, so i would need to keep on
using k versions.
-- juha
8:56 a.m.
New subject: [SR-Users] auth apis & radius (was: auth_radius - Segmentation fault)
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
It looks like he uses modules/auth_radius (which seems
to be the k
version) and modules_s/auth. Unfortunately the ser auth api is
incompatible with the k one.
OTOH IMHO the ser auth module is superior to the k one, e.g.:
ser auth:
+ nonce-count/qop=auth* support:
+ extra protection even in non qop=auth mode and non-one-time-nonce mode
(the one time nonce mode has potential issues with retransmissions):
+ base64 nonces (shorter)
k auth (at first sight) seems to support only on-time-nonces and their
implementation uses locks (and seems to be more "limited").
Indeed the ser auth module is superiour in this areas to the kamailio one. I
can't judge about the auth_radius side, as i did not used it so far.
Regards,
Henning
9:15 a.m.
New subject: [SR-Users] auth apis & radius (was: auth_radius - Segmentation fault)
On Jun 14, 2010 at 14:56, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
On Monday 14 June 2010, Andrei Pelinescu-Onciul
wrote:
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius).
Andrei
It looks like he uses modules/auth_radius (which
seems to be the k
version) and modules_s/auth. Unfortunately the ser auth api is
incompatible with the k one.
OTOH IMHO the ser auth module is superior to the k one, e.g.:
ser auth:
+ nonce-count/qop=auth* support:
+ extra protection even in non qop=auth mode and non-one-time-nonce mode
(the one time nonce mode has potential issues with retransmissions):
+ base64 nonces (shorter)
k auth (at first sight) seems to support only on-time-nonces and their
implementation uses locks (and seems to be more "limited").
Indeed the ser auth module is superiour in this areas to the kamailio one. I
can't judge about the auth_radius side, as i did not used it so far.
9:19 a.m.
New subject: [SR-Users] auth apis & radius (was: auth_radius - Segmentation fault)
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
Hi Andrei,
so if i understand correctly the main problem is the name space colision in
the auth api? What about renaming the auth API binding function, as you
suggested in another mail and extending the docs a bit? Then at least it
should work with auth from k, and we don't need to change the paths for this
modules.
Regards,
Henning
Indeed the ser
auth module is superiour in this areas to the kamailio
one. I can't judge about the auth_radius side, as i did not used it so
far.
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius).
9:23 a.m.
New subject: [SR-Users] auth apis & radius (was: auth_radius - Segmentation fault)
On Jun 14, 2010 at 15:19, Henning Westerholt <henning.westerholt(a)1und1.de> wrote:
On Monday 14 June 2010, Andrei Pelinescu-Onciul
wrote:
Hi Andrei,
so if i understand correctly the main problem is the name space colision in
the auth api? What about renaming the auth API binding function, as you
suggested in another mail and extending the docs a bit? Then at least it
should work with auth from k, and we don't need to change the paths for this
modules.
There is still the problem of specifying the path in the cfg.
If one has loadpath "modules:modules_s", and laodmodule "auth_radius"
=> modules/auth_radius is loaded => problems.
OTOH if modules/auth_radius is moved back to modules_k/auth_radius
=> no problem for default cfgs for both ser and kamailio.
Andrei
Indeed
the ser auth module is superiour in this areas to the kamailio
one. I can't judge about the auth_radius side, as i did not used it so
far.
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius). 
9:35 a.m.
New subject: [SR-Users] auth apis & radius
On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2010 at 15:19, Henning
Westerholt<henning.westerholt(a)1und1.de> wrote:
reverting on K 3.0 branch will break packaging now. modules_s are not
packaged by k 3.0 and I would prefer not to break much stable version.
For 3.1 I would go for merging the auth modules. K version has some
functions for using PVs to get username and password, which is handy for
LDAP auth with K ldap module.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Asterisk SIP Router Masterclass
Malaga, Spain - July 5-9, 2010
http://www.asipto.com/
On Monday 14 June 2010, Andrei Pelinescu-Onciul
wrote:
Hi Andrei,
so if i understand correctly the main problem is the name space colision in
the auth api? What about renaming the auth API binding function, as you
suggested in another mail and extending the docs a bit? Then at least it
should work with auth from k, and we don't need to change the paths for this
modules.
There is still the problem of specifying the path in the cfg.
If one has loadpath "modules:modules_s", and laodmodule
"auth_radius"
=> modules/auth_radius is loaded => problems.
OTOH if modules/auth_radius is moved back to modules_k/auth_radius
=> no problem for default cfgs for both ser and kamailio.
Indeed
the ser auth module is superiour in this areas to the kamailio
one. I can't judge about the auth_radius side, as i did not used it so
far.
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius).
10:03 a.m.
New subject: [SR-Users] auth apis & radius
On Jun 14, 2010 at 15:35, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
Since K3.0 doesn't package modules_s, it doesn't have to pick up the
change. I was sepaking of sr_3.0.
On Jun 14, 2010 at 15:19, Henning
Westerholt<henning.westerholt(a)1und1.de> wrote:
reverting on K 3.0
branch will break packaging now. modules_s are
not packaged by k 3.0 and I would prefer not to break much stable
version. On Monday 14 June 2010, Andrei Pelinescu-Onciul
wrote:
There is still the problem of specifying the path in the cfg.
If one has loadpath "modules:modules_s", and laodmodule "auth_radius"
=> modules/auth_radius is loaded => problems.
OTOH if modules/auth_radius is moved back to modules_k/auth_radius
=> no problem for default cfgs for both ser and kamailio. >Indeed the ser auth module is superiour in
this areas to the kamailio
>one. I can't judge about the auth_radius side, as i did not used it so
>far.
I have no idea about the radius part either (Juha knows better). The
problem is that right now if one wants to use auth from module_s and
radius, he/she can't and the quickest way to fix it is to temporarily
revive the modules_s/*radius stuff (which will have the unpleasant
side-effect of some path changes: modules/auth_radius =>
modules_k/auth_radius and modules/misc_radius => modules_k/misc_radius).
Hi
Andrei,
so if i understand correctly the main problem is the name space colision in
the auth api? What about renaming the auth API binding function, as you
suggested in another mail and extending the docs a bit? Then at least it
should work with auth from k, and we don't need to change the paths for this
modules.
For 3.1 I would go for merging the auth modules. K version has some
functions for using PVs to get username and password, which is handy
for LDAP auth with K ldap module.
Sure, but until then we better revert it (I don't have time to
merge the apis right now).
Andrei
9:16 a.m.
New subject: auth apis & radius
Andrei!
Is it possible to use modules_s/auth as a replacement for
modules_k/auth? Are they compatible from user point of view?
regards
Klaus
Am 14.06.2010 13:58, schrieb Andrei Pelinescu-Onciul:
[cc'ed sr-dev]
On Jun 13, 2010 at 11:10, Juha Heinanen<jh(a)tutpro.com> wrote:
Dmitry Kirillov writes:
It looks like he uses modules/auth_radius (which seems to be the k
version) and modules_s/auth. Unfortunately the ser auth api is
incompatible with the k one.
OTOH IMHO the ser auth module is superior to the k one, e.g.:
ser auth:
+ nonce-count/qop=auth* support:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
+ lockless in nonce-count or one time nonce mode
+ extra protection even in non qop=auth mode and non-one-time-nonce mode
(the one time nonce mode has potential issues with retransmissions):
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
+ speed optimized (less syscalls, concurrent access)
+ base64 nonces (shorter)
k auth (at first sight) seems to support only on-time-nonces and their
implementation uses locks (and seems to be more "limited").
Program received signal SIGSEGV, Segmentation
fault.
0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
(gdb) bt
#0 0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
#1 0x28816555 in authorize (_msg=0x8343b58, _realm=0x0, _uri_user=0x0,
_hftype=15) at authorize.c:102
#2 0x288163e8 in radius_proxy_authorize_1 (_msg=0x8343b58, _realm=0x0,
_s2=0x0) at authorize.c:157
i'm not sure what is going on. looks like you are using s version of
auth module, but there pre_auth has five params:
auth_result_t pre_auth(struct sip_msg* msg, str* realm, hdr_types_t hftype,
struct hdr_field** hdr, check_auth_hdr_t check_auth_hdr)
whereas the above seems to indicate that k version of auth module is in
use where pre_auth has four params:
auth_result_t pre_auth(struct sip_msg* _m, str* _realm, hdr_types_t _hftype,
struct hdr_field** _h)
anyway, i only have experience with kamailio_3.0 radius auth, which has
worked fine. perhaps you can try with that too.
We need either to quickly merge the auth apis or revive
modules_s/auth_radius (and probably the other modules_s/*radius).
Unfortunately merging the auth api doesn't look like a quick job:
ser auth api:
+ build_challenge()
+ qop
+ calc_response()
k auth api:
+ rpid_avp
+ rpid_avp_type
+ check_response()
so reviving the modules_s/*radius looks like the quick fix (at least
for 3.0).
So anybody against reviving them in 3.0? (or does anybody remember any
problem with the s versions?)
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
7:53 a.m.
New subject: auth apis & radius
Klaus Darilion writes:
Is it possible to use modules_s/auth as a replacement
for
modules_k/auth? Are they compatible from user point of view?
if i remember correctly, at least this is missing from s version:
1.4.3. auth_extra (string)
Semi-colon separated list of extra RADIUS attribute name=pseudo
variable pairs. When radius_www_authorize() or
radius_proxy_authorize() function is called, listed extra
attributes are included in RADIUS request with current values
of corresponding pseudo variables.
There is no default value, i.e., by default no extra attributes
are included.
Example 1.4. auth_extra parameter usage
modparam("auth_radius", "auth_extra",
"Acct-Session-Id=$ci")
there may be also something else. i could compare if i can find s
version of auth_radius somewhere. any pointers?
-- juha
9:33 a.m.
New subject: auth apis & radius
On Jun 14, 2010 at 15:16, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei!
Is it possible to use modules_s/auth as a replacement for
modules_k/auth? Are they compatible from user point of view?
In ser the auth module is used more like a "library" (other modules use
it via auth_api). It has only 1 script function: consume_credentials().
In kamailio besides the api interface, it exports more script functions
(which seem to be simple wrappers over the already exported api
functions, so they would be easiy to add to auth(s) too).
Andrei
Am 14.06.2010 13:58, schrieb Andrei Pelinescu-Onciul:
>[cc'ed sr-dev]
>
>On Jun 13, 2010 at 11:10, Juha Heinanen<jh(a)tutpro.com> wrote:
>>Dmitry Kirillov writes:
>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
>>>(gdb) bt
>>>#0 0x2880c2c0 in qop () from /usr/local/lib/ser/modules_s/auth.so
>>>#1 0x28816555 in authorize (_msg=0x8343b58, _realm=0x0, _uri_user=0x0,
>>>_hftype=15) at authorize.c:102
>>>#2 0x288163e8 in radius_proxy_authorize_1 (_msg=0x8343b58, _realm=0x0,
>>>_s2=0x0) at authorize.c:157
>>
>>i'm not sure what is going on. looks like you are using s version of
>>auth module, but there pre_auth has five params:
>>
>>auth_result_t pre_auth(struct sip_msg* msg, str* realm, hdr_types_t hftype,
>> struct hdr_field** hdr, check_auth_hdr_t check_auth_hdr)
>>
>>whereas the above seems to indicate that k version of auth module is in
>>use where pre_auth has four params:
>>
>>auth_result_t pre_auth(struct sip_msg* _m, str* _realm, hdr_types_t _hftype,
>> struct hdr_field** _h)
>
>It looks like he uses modules/auth_radius (which seems to be the k
>version) and modules_s/auth. Unfortunately the ser auth api is
>incompatible with the k one.
>OTOH IMHO the ser auth module is superior to the k one, e.g.:
> ser auth:
> + nonce-count/qop=auth* support:
>
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
> + lockless in nonce-count or one time nonce mode
> + extra protection even in non qop=auth mode and non-one-time-nonce mode
> (the one time nonce mode has potential issues with retransmissions):
>
http://sip-router.org/docbook/sip-router/branch/master/modules_s/auth/auth.…
> + speed optimized (less syscalls, concurrent access)
> + base64 nonces (shorter)
>
> k auth (at first sight) seems to support only on-time-nonces and their
> implementation uses locks (and seems to be more "limited").
>>
>>anyway, i only have experience with kamailio_3.0 radius auth, which has
>>worked fine. perhaps you can try with that too.
>
>
>We need either to quickly merge the auth apis or revive
>modules_s/auth_radius (and probably the other modules_s/*radius).
>Unfortunately merging the auth api doesn't look like a quick job:
>ser auth api:
> + build_challenge()
> + qop
> + calc_response()
>k auth api:
> + rpid_avp
> + rpid_avp_type
> + check_response()
>
>so reviving the modules_s/*radius looks like the quick fix (at least
>for 3.0).
>So anybody against reviving them in 3.0? (or does anybody remember any
>problem with the s versions?)
>
>
>Andrei
>
>_______________________________________________
>sr-dev mailing list
>sr-dev(a)lists.sip-router.org
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5098
days inactive
5098
days old
12 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen -
Klaus Darilion