[SR-Users] auth apis & radius (was: auth_radius - Segmentation fault)

[Andrei Pelinescu-Onciul]

[cc'ed sr-dev]

On Jun 13, 2010 at 11:10, Juha Heinanen <jh at 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.html#nonce_count
 + 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.html#auth.auth_checks
 + 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