Hi
I have build SIP-Router and modules from sources from GIT repository (development branch). auth_radius module results in a "Segmentation fault: 11" when I try to register (radius_www_authorize).
sercmd> core.version Server: ser (3.0.99-dev1 (i386/freebsd)) eabca5
Any help for solving the problem would be appreciated. Thanks.
Dmitry Kirillov writes:
I have build SIP-Router and modules from sources from GIT repository (development branch). auth_radius module results in a "Segmentation fault: 11" when I try to register (radius_www_authorize).
sercmd> core.version Server: ser (3.0.99-dev1 (i386/freebsd)) eabca5
Any help for solving the problem would be appreciated. Thanks.
find out with gdb where the crash occurs:
gdb binary core where
-- juha
Juha Heinanen ?????:
Dmitry Kirillov writes:
have build SIP-Router and modules from sources from GIT repository (development branch). auth_radius module results in a "Segmentation fault: 11" when I try to register (radius_www_authorize).
find out with gdb where the crash occurs:
gdb binary core where
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 #3 0x080596b6 in do_action (h=0xbfbfe890, a=0x82f0e38, msg=0x8343b58) at action.c:906 #4 0x0805b9ec in run_actions (h=0xbfbfe890, a=0x82f0e38, msg=0x8343b58) at action.c:1339 #5 0x080ccb19 in rval_get_int (h=0xbfbfe890, msg=0x8343b58, i=0xbfbfdad4, rv=0x82f0f90, cache=0x0) at rvalue.c:904 #6 0x080cdf25 in rval_expr_eval_int (h=0xbfbfe890, msg=0x8343b58, res=0xbfbfdad4, rve=0x82f0f8c) at rvalue.c:1844 #7 0x080ce0c6 in rval_expr_eval_int (h=0xbfbfe890, msg=0x8343b58, res=0xbfbfdd9c, rve=0x82f1340) at rvalue.c:1851 #8 0x08059437 in do_action (h=0xbfbfe890, a=0x82f1a4c, msg=0x8343b58) at action.c:880 #9 0x0805b9ec in run_actions (h=0xbfbfe890, a=0x82f0ce4, msg=0x8343b58) at action.c:1339 #10 0x08057e11 in do_action (h=0xbfbfe890, a=0x82dc10c, msg=0x8343b58) at action.c:522 #11 0x0805b9ec in run_actions (h=0xbfbfe890, a=0x82dbe58, msg=0x8343b58) at action.c:1339 #12 0x0805a4a3 in do_action (h=0xbfbfe890, a=0x82dcc44, msg=0x8343b58) at action.c:1138 #13 0x0805b9ec in run_actions (h=0xbfbfe890, a=0x82d87f8, msg=0x8343b58) at action.c:1339 #14 0x08057e11 in do_action (h=0xbfbfe890, a=0x82aacc4, msg=0x8343b58) at action.c:522 #15 0x0805b9ec in run_actions (h=0xbfbfe890, a=0x82a9f7c, msg=0x8343b58) at action.c:1339 #16 0x0805bc63 in run_top_route (a=0x82a9f7c, msg=0x8343b58, c=0x0) at action.c:1387 #17 0x080b4f34 in receive_msg ( buf=0x82511c0 "INVITE sip:*89528817554@neotelecom.ru SIP/2.0\r\nVia: SIP/2.0/UDP 78.140.59.45:55474;branch=z9hG4bK-d8754z-4a01ae4eb2219a10-1---d8754z-;rport\r\nMax-Forwards: 16\r\nContact: sip:100@78.140.59.45:55474\r\nTo"..., len=1067, rcv_info=0xbfbfe98c) at receive.c:205 #18 0x08121c27 in udp_rcv_loop () at udp_server.c:527 #19 0x0808d4c1 in main_loop () at main.c:1337 #20 0x0809028d in main (argc=1, argv=0xbfbfec6c) at main.c:2315
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)
anyway, i only have experience with kamailio_3.0 radius auth, which has worked fine. perhaps you can try with that too.
-- juha
[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
On Jun 13, 2010 at 14:40, Dmitry Kirillov spinaker@neotelecom.ru wrote:
Juha Heinanen ?????:
Dmitry Kirillov writes:
have build SIP-Router and modules from sources from GIT repository (development branch). auth_radius module results in a "Segmentation fault: 11" when I try to register (radius_www_authorize).
find out with gdb where the crash occurs:
gdb binary core where
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
It should be fixed now. There are 2 solutions. You either update (latest sr_3.0 or master/developement or one of the tarballs: http://sip-router.org/tarballs/sr/sr_3.0/ser-3.0.2_src_2010-06-14_457b2d.tar... http://sip-router.org/tarballs/sr/unstable/ser-3.0.99-dev1_src_2010-06-14_a7... ) or you switch to modules_k/auth/auth.so instead of auth. However assuming that you have a config based on one of the sip-router*.cfg or on a ser 2.* cfg, if you take the modules_k/auth approach, you might run into some other incompatibilities (I guess nobody tried to mix auth modules so far).
If you choose to update and you are using git, make sure that your modules/auth_radius and modules/misc_radius do not exist after the update (git will remove only the tracked files, meaning all the *.[ch] and the Makefile, it will not remove any compiled stuff that might be around). If they do exist, just delete them (or run make proper _before_ updating).
Andrei
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Dmitry Kirillov -
Henning Westerholt -
Juha Heinanen -
Klaus Darilion