[cc'ed sr-dev]
On Jun 13, 2010 at 11:10, Juha Heinanen jh@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.h... + 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.h... + 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
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
On Jun 14, 2010 at 13:00, Juha Heinanen jh@tutpro.com wrote:
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?
I'm plannig to revert:
commit 456c3c137e9abcf687413f9675fe0f1761ce820d Author: Juha Heinanen jh@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
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_radiusThis 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
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
On Jun 14, 2010 at 14:56, Henning Westerholt henning.westerholt@1und1.de wrote:
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.
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
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
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.
Regards,
Henning
On Jun 14, 2010 at 15:19, Henning Westerholt henning.westerholt@1und1.de wrote:
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
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.
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
On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2010 at 15:19, Henning Westerholthenning.westerholt@1und1.de wrote:
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
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.
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.
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
On Jun 14, 2010 at 15:35, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 6/14/10 3:23 PM, Andrei Pelinescu-Onciul wrote:
On Jun 14, 2010 at 15:19, Henning Westerholthenning.westerholt@1und1.de wrote:
On Monday 14 June 2010, Andrei Pelinescu-Onciul wrote:
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.
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.
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.
Since K3.0 doesn't package modules_s, it doesn't have to pick up the change. I was sepaking of sr_3.0.
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
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 Heinanenjh@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.h...
- 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.h...
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
On Jun 14, 2010 at 15:16, Klaus Darilion klaus.mailinglists@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 Heinanenjh@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.h...
- 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.h...
- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen -
Klaus Darilion