Re: [SR-Users] Kamailio auth_radius: duplicate User-Name attribute
You need to check the dictionaries on your kamailio server.
Mos likely something is miss configured there.
Check what value do you have for "User-Name" and see if you have any
duplicates for that value.
Regards,
Ovidiu Sas
On Sat, Mar 5, 2011 at 2:32 AM, Kosilov Fedor wrote:
> Again for testing, I pointed Kamailio directly to my billing radius,
> bypassing Freeradius. The situation is the same, so the problem is
> definitely not with the Freeradius server.
>
> 2011/3/5 Kosilov Fedor
>>
>> Hello, Daniel, thank you for your attention to my problem.
>>
>> I actually don't need accounting support, I just want to implement an
>> authorization using radius.
>> But for testing purposes, I loaded the acc module and set "radius_extra"
>> param. Nothing has changed.
>>
>> Here is a part of my config:
>>
>>
>> ...
>> modparam("acc", "radius_config", "/etc/radiusclient-ng/radiusclient.conf")
>> modparam("acc", "radius_extra", "User-Name=$Au")
>> ...
>> modparam("auth_radius", "radius_config",
>> "/etc/radiusclient-ng/radiusclient.conf")
>> modparam("auth_radius", "auth_extra", "NAS-Identifier=$var(ident)")
>> ...
>> route {
>> #Definitions
>> $var(ident) = "kamserv.example.com";
>> ...
>> route(3); #Auth
>> ...
>> }
>>
>> ...
>>
>> route[3] {
>> if (is_method("REGISTER"))
>> {
>> if (is_from_local()) {
>> if (!radius_www_authorize("$td"))
>> {
>> www_challenge("$sel(to.uri.host)", "1");
>> exit;
>> } else {
>>
>> avp_db_delete("$sel(to.uri)","$avp(s:ip)");
>>
>> avp_db_delete("$sel(to.uri)","$avp(s:dpid)");
>>
>> avp_db_delete("$sel(to.uri)","$avp(s:fr_timer)");
>>
>> avp_db_delete("$sel(to.uri)","$avp(s:calls_limit)");
>>
>> avp_db_store("$sel(to.uri)","$avp(s:ip)");
>>
>> avp_db_store("$sel(to.uri)","$avp(s:dpid)");
>>
>> avp_db_store("$sel(to.uri)","$avp(s:fr_timer)");
>>
>> avp_db_store("$sel(to.uri)","$avp(s:calls_limit)");
>>
>> if
>> ($au!=$sel(to.uri.user))||($au!=$sel(from.uri.user)) {
>> sl_send_reply("403","Forbidden
>> auth ID");
>> exit;
>> } else {
>> if ($avp(s:ip)!='any' &&
>> $sel(src.ip)!=$avp(s:ip)) {
>>
>> sl_send_reply("403","Forbidden");
>> exit;
>> }
>> }
>> }
>>
>> } else {
>> sl_send_reply("403","Forbidden");
>> exit;
>> }
>> } else {
>> if ($sel(src.ip)=="192.168.0.2") {
>> return;
>> } else if (is_from_local()) {
>> if
>> (!radius_proxy_authorize("$sel(from.uri.host)","$sel(from.uri.user)")) {
>> proxy_challenge("$sel(from.uri.host)",
>> "1");
>> exit;
>> }
>> if ($avp(s:ip)!='any' && $sel(src.ip)!=$avp(s:ip))
>> {
>> sl_send_reply("403","Forbidden");
>> exit;
>> }
>>
>> if (is_method("PUBLISH"))
>> {
>> if ($au!=$sel(to.uri.user)) {
>> sl_send_reply("403","Forbidden
>> auth ID");
>> exit;
>> }
>> } else if ($au!=$sel(from.uri.user)) {
>> sl_send_reply("403","Forbidden auth ID");
>> exit;
>> }
>> consume_credentials();
>> } else {
>> sl_send_reply("403","Forbidden");
>> exit;
>> }
>> }
>> }
>> ...
>>
>> And again a part of the freeradius log:
>>
>> rad_recv: Access-Request packet from host 127.0.0.1 port 58933, id=135,
>> length=298
>> User-Name = "2219...@example.com"
>> Digest-Attributes = 0x0a0932323139303031
>> Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
>> Digest-Attributes =
>> 0x0222545848676630317833314f7076767759512b6b73674c63554d51784f6c347634
>> Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
>> Digest-Attributes = 0x030a5245474953544552
>> Digest-Attributes = 0x050661757468
>> Digest-Attributes = 0x090a3030303030303031
>> Digest-Attributes = 0x080c39636238383130616531
>> Digest-Response = "efdcf92b58f694b97928856614057436"
>> Service-Type = Sip-Session
>> Sip-Uri-User = "2219001"
>> User-Name = "call-id=zomdnic
Re: [SR-Users] problem unreferencing dialog in dialog module
Ok, I updated the code in the server. I'm testing the changes on Tuesday and I'll send feedback to the list. We found dialog module very useful because of the information and functionality it provides. For example, we are using its exported function dlg_end_dlg to cleanly end all the active calls when stopping Kamailio is required for maintenance reasons. We are also using the dlg_bridge function to implement click-to-dial applications and it works fine. On the other hand, in the logs of the server we detected the unreference problem, we got the logs showed below quite often. I don 't know if it can be related to the unreference problem. Since it has a CRITICAL log level I'm not sure if this is so because it can mean a real problem or Kamailio can safety deal with it: Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: CRITICAL: dialog [dlg_hash.c:615]: bogus event 5 in state 4 for dlg *0x7f2d0a3d30e0*[306:1818049706] with clid ' 92515995-3508071667-342...@usmiap1etx02.mydomain.com' and tags '3508071667-342428' '7A242CC-0' Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:770]: dialog *0x7f2d0a3d30e0* changed from state 4 to state 4, due event 5 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=4077 , global msg id=4076 , T on entrance=(nil) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=356, isACK=0 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:470]: DEBUG: RFC3261 transaction matched, tid=3178c7ec929daf0e4ade2b303de82a20 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:728]: DEBUG: t_lookup_request: transaction found (T=0x7f2d0a82bca0) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_reply.c:1430]: DEBUG: reply retransmitted. buf=0x7f2d2eff4160: SIP/2.0 5..., shmem=0x7f2d0a72cb90: SIP/2.0 5 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:599]: unref dlg *0x7f2d0a3d30e0* with 1 -> 3 Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: [usr_avp.c:646]: >From dlg_hash.h ... DLG_STATE_CONFIRMED4 /*!< confirmed dialog */ ... DLG_EVENT_REQPRACK 5 /*!< PRACK request */ ... I understand it means we are receiving a PRACK in a confirmed dialog (ACK received), doesn't it? I guess it can be due either to an error of the SIP stack of the caller side or this PRACK is a rtx due to networking issues (not probable, I think). Thanks a lot, regards Antón 2011/3/4 Daniel-Constantin Mierla > Hello, > > > On 3/3/11 10:19 AM, Anton Roman wrote: > > Hello, > > thanks for your quick reply, my answer is inline. > > 2011/3/2 Daniel-Constantin Mierla > >> Hello, >> >> looks like related to the callbacks for dialog module. Are you loading >> other modules that require dialog module? >> > > we are using some features of dialog module such as ending dialogs after a > timeout period, and we are using engage_mediaproxy() function, as well. It's > an old configuration we had to put in production with no time enough to > test. Do you recommend not to use dialog module if not strictly required? > > > usage of dialog module was always safe and working great for me. But I use > it mostly alone, never with mediaproxy module, just with pua_dialoginfo > module in some cases. From the logs, the crash was related to the callback > system exported by dialog module for the other modules willing to hook into > dialog, it is why I asked about the other modules to be sure there is at > list one binding to dialog. > > So, like with other modules, if there is a problem discovered there, it is > important that we fix it - this is a module used a lot by many. Therefore > usage is encouraged when needed :-) > > Cheers, > Daniel > > > -- > Daniel-Constantin Mierlahttp://www.asipto.com > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
