13 Jun
2010
13 Jun
'10
8:05 a.m.
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, System Engineer
KDS-RIPE
Network Operational Center, JSC Neotelecom
Tomsk, Russia
Telephone: +7(3822)710-008, ICQ: 22413725
Web: http://www.neotelecom.ru/ | mailto:noc@neotelecom.ru
Looking Glass: http://lg.neotelecom.ru/
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5192
(20100612) __________
The message was checked by ESET NOD32 Antivirus.
http://www.esetnod32.ru/.ml
13 Jun
13 Jun
8:17 a.m.
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
9:40 a.m.
Juha Heinanen ?????:
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
#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, System Engineer
KDS-RIPE
Network Operational Center, JSC Neotelecom
Tomsk, Russia
Telephone: +7(3822)710-008, ICQ: 22413725
Web: http://www.neotelecom.ru/ | mailto:noc@neotelecom.ru
Looking Glass: http://lg.neotelecom.ru/
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
10:10 a.m.
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
14 Jun
14 Jun
1:58 p.m.
New subject: auth apis & radius (was: auth_radius - Segmentation fault)
[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
noon
New subject: auth apis & radius (was: auth_radius - Segmentation fault)
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
2:40 p.m.
New subject: auth apis & radius (was: auth_radius - Segmentation fault)
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?
12:45 p.m.
New subject: auth apis & radius (was: auth_radius - Segmentation fault)
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
2:56 p.m.
New subject: 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
3:15 p.m.
New subject: 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.
3:19 p.m.
New subject: 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).
3:23 p.m.
New subject: 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). 
3:35 p.m.
New subject: [sr-dev] 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).
4:03 p.m.
New subject: [sr-dev] 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
3:16 p.m.
New subject: [sr-dev] 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
1:53 p.m.
New subject: [sr-dev] 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
3:33 p.m.
New subject: [sr-dev] 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
6:23 p.m.
On Jun 13, 2010 at 14:40, Dmitry Kirillov <spinaker(a)neotelecom.ru> wrote:
Juha Heinanen ?????:
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.ta…
http://sip-router.org/tarballs/sr/unstable/ser-3.0.99-dev1_src_2010-06-14_a…
) 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
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 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
5088
days inactive
5089
days old
17 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Dmitry Kirillov -
Henning Westerholt -
Juha Heinanen -
Klaus Darilion