sr-users September 2003

sr-users@lists.kamailio.org

86 participants
209 discussions

[Serusers] MSN compliance with SIMPLE standards
by jaime.gil＠orange.co.uk 24 Sep '03

24 Sep '03

Hello, We have been trying SER with MSN clients for some time now. We are now using other clients, like Kphone 3.12 for internal chat and presence. The server has been working perfectly, without disruption and very work to set it up. We want to start deploying new services on top of SER and, among one of the enablers, we have thought about a Presence Server. We have been trying the 2 possible ways to implement this: - Via a Presence server (using the pa module). - Using proxy mode (merely relaying SIP messages between clients, capturing relevant messages between clients). The first option does not seem to work. Presence seems to appear "Away", no matter if the presentity is online or not. So we tried the 2nd option. We want to store the presence information of all the users on the server. To do that, we record-route SUBSCRIBEs and NOTIFYs, and that way we are able to get the presence information out of the message body in NOTIFYs. However, we have noticed that when an MSN Messenger client (acting as a presentity) notifies a watcher, it does so in a strange way that we believe is not standard (at least with v 4.6). The Request URI on the NOTIFY has the following format: >From the presentity: NOTIFY sip:<presentity-id>@<server-ip> (MSN Messenger's behaviour) While according to the SIMPLE specs should be: >From the presentity: NOTIFY sip:<watcher-id>@<domain/server-ip> (Kphone's behaviour) Is this correct according to the SIMPLE standards? Was it solved in later releases of MSN Messenger? All this may be solved when the PA module becomes ready... Regards, Jaime ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

1 0

[Serusers] Compiling problems
by Andrea Girardi 24 Sep '03

24 Sep '03

Hi, i have problems with mangler.so module. there are some modules not included in make clean (ex. mangler), why? I've compiled with make include_modules="mangler" modules; when i use make prefix=/usr/local install why mangler.so not appear in /usr/local/lib/ser/modules? bye

4 5

[Serusers] Кто контролирует организацию?
by Обучение 24 Sep '03

24 Sep '03

26 сентября: «Особенности взаимоотношений с контролирующими органами» Программа семинара: 1. кто контролирует организацию. каково действующее законодательство в этой области. 2. налоговые органы 3. таможенные органы 4. государственные внебюджетные фонды 5. инспекция по труду 6. защита прав юридических лиц и индивидуальных предпринимателей при проведении прочих видов государственного контроля (надзора) 7. возмещение убытков, понесенных организацией в связи с неправомерными действиями контролирующих органов 8. как отстоять свою правоту в суде 9. ответственность организации и ее должностных лиц, ответственность индивидуального предпринимателя 10. ответственность контролирующих органов и их должностных лиц Стоимость семинара - 3900 рублей, с учетом НДС. Форма оплаты любая (наличная или безналичная). В стоимость входит: участие в работе семинара, раздаточный материал, кофе-пауза, обед в ресторане. КОНТАКТНЫЕ ТЕЛЕФОНЫ: (095) 2O7-26-21, 789-81-9O. remove(a)mebgamma.ru - отписка.

1 0

[Serusers] PSTN GW
by manu v 24 Sep '03

24 Sep '03

Dear all, Could any one help me routing SIP calls through my PSTN gateway. i am herewith attaching ser.cfg file for ur suggession. do i need load any other modules for pstn routing? please check and the syntax of ser.cfg. regards manu. ___________________________________________________ Art meets Anesthesia; Shefali Weds Dr. Raman. Rediff Matchmaker strikes another interesting match !! Visit http://matchmaker.rediff.com?1

2 1

[Serusers] JUST WANT TO USE CISCO GATEWAY (1760)
by Akinsola Oyelakin 24 Sep '03

24 Sep '03

Hi Everyone, I am a newbie to SIP and I have a a network of voice routers (cisco 1760) I normally use full mesh H323. now I want to use SIP and let every voice router get in touch with the SIP server to know the IP address of the destination pattern (number). So the SIP server will be playing the role of a soft PBX. PLEASE help out with what I am suppose to do on the SER and each router. (I have the SER up and running.) Regards, Akin -----Original Message----- From: serusers-request(a)iptel.org [mailto:serusers-request@lists.iptel.org] Sent: Tuesday, September 23, 2003 12:38 PM To: serusers(a)lists.iptel.org Subject: Serusers Digest, Vol 5, Issue 50 Send Serusers mailing list submissions to serusers(a)lists.iptel.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.iptel.org/mailman/listinfo/serusers or, via email, send a message with subject or body 'help' to serusers-request(a)lists.iptel.org You can reach the person managing the list at serusers-owner(a)lists.iptel.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Serusers digest..." Today's Topics: 1. RE: Troubles setting up radius authentication (Steve Dolloff) 2. RE: Troubles setting up radius authentication (Steve Dolloff) 3. Re: Troubles setting up radius authentication (Jan Janak) 4. RE: Troubles setting up radius authentication (Steve Dolloff) 5. Re: Troubles setting up radius authentication (Jan Janak) 6. Re: Troubles setting up radius authentication (Jan Janak) ---------------------------------------------------------------------- Message: 1 Date: Tue, 23 Sep 2003 11:24:11 -0500 From: "Steve Dolloff" <sdolloff(a)noc.dls.net> Subject: RE: [Serusers] Troubles setting up radius authentication To: "Jan Janak" <jan(a)iptel.org> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <ADCFA6B7CA0C754EB837B423E5A521D2543512(a)mailbox.noc.dls.net> Content-Type: text/plain; charset="us-ascii" Yes, I have added the SIP definitions to the radiusclient library. It is the dictionary file defined in the radiusclient.conf file as /etc/sip_dictionary. It was created using the dictionary file from radiusclient and adding the information from the link that you refered to. ----------------------- Hello, if there is no radius traffic then radiusclient library has some problems when buiding the request. Did you extend your radius dictionary as described in http://iptel.org/ser/ser_radius.html ? Jan. On 23-09 10:38, Steve Dolloff wrote: > I am trying to switch from database authentication to radius > authentication. > > I have compiled and installed the module. > > I have added the following to my ser.cfg > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > modparam("auth_radius", "service_type",15) > > if (method=="REGISTER") { > log(1,"authenticating"); > if (!radius_www_authorize("test.net")) { > log(1,"radius auth failure"); > www_challenge("test.net", "0"); > break; > }; > > I have configured the following in /etc/ser/radiusclient.conf > authserver radius1.test.net:1812 > authserver radius2.test.net:1812 > servers /etc/servers > dictionary /etc/sip_dictionary > > I have configured the following in /etc/servers > > Radius1.test.net secret > Radius2.test.net secret2 > > I get the following in my messages log. > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 10:39:30 > voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 10:39:30 voip2 > /usr/sbin/ser[25949]: authenticating Sep 23 10:39:30 voip2 > /usr/sbin/ser[25949]: radius auth failure Sep 23 10:39:34 voip2 > /usr/sbin/ser[25948]: authenticating Sep 23 10:39:34 voip2 > /usr/sbin/ser[25948]: radius auth failure Sep 23 10:39:34 voip2 > /usr/sbin/ser[25945]: authenticating Sep 23 10:39:34 voip2 > /usr/sbin/ser[25945]: radius auth failure > > And ngrep port 1812 shows no traffic at all. Where are these auth > request going? How can I get more debug info? > > Thanks for your help. > > Stephen > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ Message: 2 Date: Tue, 23 Sep 2003 11:30:07 -0500 From: "Steve Dolloff" <sdolloff(a)noc.dls.net> Subject: RE: [Serusers] Troubles setting up radius authentication To: "Jan Janak" <jan(a)iptel.org> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <ADCFA6B7CA0C754EB837B423E5A521D2543513(a)mailbox.noc.dls.net> Content-Type: text/plain; charset="us-ascii" Here is a copy of the stderr if I run from console. 8(27147) qm_free(0x80bf800, 0x80cbc6c), called from parser/parse_via.c: free_via_list(1973) 8(27147) qm_free: freeing frag. 0x80cbc54 alloc'ed from parser/msg_parser.c: get_hdr_field(109) 8(27147) qm_free(0x80bf800, 0x80cbd10), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbcf8 alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbc1c), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbc04 alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbdb0), called from parser/parse_to.c: free_to(778) 8(27147) qm_free: freeing frag. 0x80cbd98 alloc'ed from parser/msg_parser.c: get_hdr_field(149) 8(27147) qm_free(0x80bf800, 0x80cbe04), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbdec alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbd60), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbd48 alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80c9da8), called from parser/parse_cseq.c: free_cseq(102) 8(27147) qm_free: freeing frag. 0x80c9d90 alloc'ed from parser/msg_parser.c: get_hdr_field(128) 8(27147) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbe3c alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cc0d8), called from parser/parse_param.c: do_free_params(420) 8(27147) qm_free: freeing frag. 0x80cc0c0 alloc'ed from parser/parse_param.c: parse_params(337) 8(27147) qm_free(0x80bf800, 0x80cc084), called from parser/contact/contact.c: free_contacts(293) 8(27147) qm_free: freeing frag. 0x80cc06c alloc'ed from parser/contact/contact.c: parse_contacts(194) 8(27147) qm_free(0x80bf800, 0x80ca3cc), called from parser/contact/parse_contact.c: free_contact(109) 8(27147) qm_free: freeing frag. 0x80ca3b4 alloc'ed from parser/contact/parse_contact.c: parse_contact(81) 8(27147) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbe8c alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbedc alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbf2c alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: free_hdr_field_lst(170) 8(27147) qm_free: freeing frag. 0x80cbf7c alloc'ed from parser/msg_parser.c: parse_headers(276) 8(27147) qm_free(0x80bf800, 0x80c8934), called from data_lump.c: free_lump(321) 8(27147) qm_free: freeing frag. 0x80c891c alloc'ed from mf_funcs.c: add_maxfwd_header(131) 8(27147) qm_free(0x80bf800, 0x80cbfe4), called from data_lump.c: free_lump_list(346) 8(27147) qm_free: freeing frag. 0x80cbfcc alloc'ed from data_lump.c: insert_new_lump_before(136) 8(27147) qm_free(0x80bf800, 0x80cc034), called from data_lump.c: free_lump_list(357) 8(27147) qm_free: freeing frag. 0x80cc01c alloc'ed from data_lump.c: anchor_lump(292) 8(27147) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: free_lump(321) 8(27147) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: fix_nated_contact_f(204) 8(27147) qm_free(0x80bf800, 0x80cc124), called from data_lump.c: free_lump_list(352) 8(27147) qm_free: freeing frag. 0x80cc10c alloc'ed from data_lump.c: insert_new_lump_after(111) 8(27147) qm_free(0x80bf800, 0x80cc1dc), called from data_lump.c: free_lump_list(357) 8(27147) qm_free: freeing frag. 0x80cc1c4 alloc'ed from data_lump.c: del_lump(262) 8(27147) qm_free(0x80bf800, 0x80cc35c), called from data_lump_rpl.c: free_lump_rpl(84) 8(27147) qm_free: freeing frag. 0x80cc344 alloc'ed from data_lump_rpl.c: build_lump_rpl(47) 8(27147) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: free_lump_rpl(85) 8(27147) qm_free: freeing frag. 0x80c9cd8 alloc'ed from data_lump_rpl.c: build_lump_rpl(40) 8(27147) qm_free(0x80bf800, 0x80cb918), called from receive.c: receive_msg(187) 8(27147) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: receive_msg(78) -----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: Tuesday, September 23, 2003 10:45 AM To: Steve Dolloff Cc: Serusers Subject: Re: [Serusers] Troubles setting up radius authentication Hello, if there is no radius traffic then radiusclient library has some problems when buiding the request. Did you extend your radius dictionary as described in http://iptel.org/ser/ser_radius.html ? Jan. On 23-09 10:38, Steve Dolloff wrote: > I am trying to switch from database authentication to radius > authentication. > > I have compiled and installed the module. > > I have added the following to my ser.cfg > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > modparam("auth_radius", "service_type",15) > > if (method=="REGISTER") { > log(1,"authenticating"); > if (!radius_www_authorize("test.net")) { > log(1,"radius auth failure"); > www_challenge("test.net", "0"); > break; > }; > > I have configured the following in /etc/ser/radiusclient.conf > authserver radius1.test.net:1812 > authserver radius2.test.net:1812 > servers /etc/servers > dictionary /etc/sip_dictionary > > I have configured the following in /etc/servers > > Radius1.test.net secret > Radius2.test.net secret2 > > I get the following in my messages log. > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 10:39:30 > voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 10:39:30 voip2 > /usr/sbin/ser[25949]: authenticating Sep 23 10:39:30 voip2 > /usr/sbin/ser[25949]: radius auth failure Sep 23 10:39:34 voip2 > /usr/sbin/ser[25948]: authenticating Sep 23 10:39:34 voip2 > /usr/sbin/ser[25948]: radius auth failure Sep 23 10:39:34 voip2 > /usr/sbin/ser[25945]: authenticating Sep 23 10:39:34 voip2 > /usr/sbin/ser[25945]: radius auth failure > > And ngrep port 1812 shows no traffic at all. Where are these auth > request going? How can I get more debug info? > > Thanks for your help. > > Stephen > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ Message: 3 Date: Tue, 23 Sep 2003 18:30:35 +0200 From: Jan Janak <jan(a)iptel.org> Subject: Re: [Serusers] Troubles setting up radius authentication To: Steve Dolloff <sdolloff(a)noc.dls.net> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <20030923163035.GJ766(a)localhost.localdomain> Content-Type: text/plain; charset=iso-8859-2 Hello, >From the information below I can't say where the problem is, but I >would say some attribute definitions are missing. Unfortunatelly the stable version of auth_radius module doesn't print much debugging messages when something goes wrong. Did you compile your server from sources or do you use binary packages ? You can try unstable version branch from the CVS, that should tell you where the problem is, or I can send you a patch to stable version if you can apply it and compile from sources. Jan. On 23-09 11:24, Steve Dolloff wrote: > Yes, I have added the SIP definitions to the radiusclient library. It > is the dictionary file defined in the radiusclient.conf file as > /etc/sip_dictionary. It was created using the dictionary file from > radiusclient and adding the information from the link that you refered > to. > > ----------------------- > > Hello, > > if there is no radius traffic then radiusclient library has some > problems when buiding the request. Did you extend your radius > dictionary as described in http://iptel.org/ser/ser_radius.html ? > > Jan. > > On 23-09 10:38, Steve Dolloff wrote: > > I am trying to switch from database authentication to radius > > authentication. > > > > I have compiled and installed the module. > > > > I have added the following to my ser.cfg > > > > modparam("auth_radius", "radius_config", > > "/etc/ser/radiusclient.conf") modparam("auth_radius", > > "service_type",15) > > > > if (method=="REGISTER") { > > log(1,"authenticating"); > > if > > (!radius_www_authorize("test.net")) > { > > log(1,"radius auth failure"); > > www_challenge("test.net", > "0"); > > break; > > }; > > > > I have configured the following in /etc/ser/radiusclient.conf > > authserver radius1.test.net:1812 > > authserver radius2.test.net:1812 > > servers /etc/servers > > dictionary /etc/sip_dictionary > > > > I have configured the following in /etc/servers > > > > Radius1.test.net secret > > Radius2.test.net secret2 > > > > I get the following in my messages log. > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 10:39:30 > > voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 10:39:30 > > voip2 /usr/sbin/ser[25949]: authenticating Sep 23 10:39:30 voip2 > > /usr/sbin/ser[25949]: radius auth failure Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25948]: authenticating Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25948]: radius auth failure Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25945]: authenticating Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25945]: radius auth failure > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > request going? How can I get more debug info? > > > > Thanks for your help. > > > > Stephen > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ Message: 4 Date: Tue, 23 Sep 2003 11:39:53 -0500 From: "Steve Dolloff" <sdolloff(a)noc.dls.net> Subject: RE: [Serusers] Troubles setting up radius authentication To: "Jan Janak" <jan(a)iptel.org> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <ADCFA6B7CA0C754EB837B423E5A521D2543514(a)mailbox.noc.dls.net> Content-Type: text/plain; charset="us-ascii" This is my current info. ser -V version: ser 0.8.12dev-t16 (i386/linux) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 this was built from source off of CVS. If there is a newer version that would give more info, I will recompile. Stephen Hello, >From the information below I can't say where the problem is, but I >would say some attribute definitions are missing. Unfortunatelly the stable version of auth_radius module doesn't print much debugging messages when something goes wrong. Did you compile your server from sources or do you use binary packages ? You can try unstable version branch from the CVS, that should tell you where the problem is, or I can send you a patch to stable version if you can apply it and compile from sources. Jan. On 23-09 11:24, Steve Dolloff wrote: > Yes, I have added the SIP definitions to the radiusclient library. It > is the dictionary file defined in the radiusclient.conf file as > /etc/sip_dictionary. It was created using the dictionary file from > radiusclient and adding the information from the link that you refered > to. > > ----------------------- > > Hello, > > if there is no radius traffic then radiusclient library has some > problems when buiding the request. Did you extend your radius dictionary > as described in http://iptel.org/ser/ser_radius.html ? > > Jan. > > On 23-09 10:38, Steve Dolloff wrote: > > I am trying to switch from database authentication to radius > > authentication. > > > > I have compiled and installed the module. > > > > I have added the following to my ser.cfg > > > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > > modparam("auth_radius", "service_type",15) > > > > if (method=="REGISTER") { > > log(1,"authenticating"); > > if (!radius_www_authorize("test.net")) > { > > log(1,"radius auth failure"); > > www_challenge("test.net", > "0"); > > break; > > }; > > > > I have configured the following in /etc/ser/radiusclient.conf > > authserver radius1.test.net:1812 > > authserver radius2.test.net:1812 > > servers /etc/servers > > dictionary /etc/sip_dictionary > > > > I have configured the following in /etc/servers > > > > Radius1.test.net secret > > Radius2.test.net secret2 > > > > I get the following in my messages log. > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 10:39:30 > > voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 10:39:30 > > voip2 /usr/sbin/ser[25949]: authenticating Sep 23 10:39:30 voip2 > > /usr/sbin/ser[25949]: radius auth failure Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25948]: authenticating Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25948]: radius auth failure Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25945]: authenticating Sep 23 10:39:34 voip2 > > /usr/sbin/ser[25945]: radius auth failure > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > request going? How can I get more debug info? > > > > Thanks for your help. > > > > Stephen > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ Message: 5 Date: Tue, 23 Sep 2003 18:40:34 +0200 From: Jan Janak <jan(a)iptel.org> Subject: Re: [Serusers] Troubles setting up radius authentication To: Steve Dolloff <sdolloff(a)noc.dls.net> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <20030923164034.GK766(a)localhost.localdomain> Content-Type: text/plain; charset=iso-8859-2 Hello, this should be recent enough. Try to look for messages like this: sterman(): Unable to add PW_DIGEST_REALM attribute (see sip_router/modules/auth_radius/sterman.c for more details). The file contains functions that build and send radius messages. Jan. On 23-09 11:39, Steve Dolloff wrote: > This is my current info. > > ser -V > version: ser 0.8.12dev-t16 (i386/linux) > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ main.c > compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > this was built from source off of CVS. If there is a newer version > that would give more info, I will recompile. > > Stephen > > > Hello, > > >From the information below I can't say where the problem is, but I > >would > say some attribute definitions are missing. > > Unfortunatelly the stable version of auth_radius module doesn't print > much debugging messages when something goes wrong. > > Did you compile your server from sources or do you use binary packages > ? You can try unstable version branch from the CVS, that should tell > you where the problem is, or I can send you a patch to stable version > if you can apply it and compile from sources. > > Jan. > > On 23-09 11:24, Steve Dolloff wrote: > > Yes, I have added the SIP definitions to the radiusclient library. > > It is the dictionary file defined in the radiusclient.conf file as > > /etc/sip_dictionary. It was created using the dictionary file from > > radiusclient and adding the information from the link that you > > refered to. > > > > ----------------------- > > > > Hello, > > > > if there is no radius traffic then radiusclient library has some > > problems when buiding the request. Did you extend your radius > dictionary > > as described in http://iptel.org/ser/ser_radius.html ? > > > > Jan. > > > > On 23-09 10:38, Steve Dolloff wrote: > > > I am trying to switch from database authentication to radius > > > authentication. > > > > > > I have compiled and installed the module. > > > > > > I have added the following to my ser.cfg > > > > > > modparam("auth_radius", "radius_config", > "/etc/ser/radiusclient.conf") > > > modparam("auth_radius", "service_type",15) > > > > > > if (method=="REGISTER") { > > > log(1,"authenticating"); > > > if > (!radius_www_authorize("test.net")) > > { > > > log(1,"radius auth > failure"); > > > www_challenge("test.net", > > "0"); > > > break; > > > }; > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > authserver radius1.test.net:1812 > > > authserver radius2.test.net:1812 > > > servers /etc/servers > > > dictionary /etc/sip_dictionary > > > > > > I have configured the following in /etc/servers > > > > > > Radius1.test.net secret > > > Radius2.test.net secret2 > > > > > > I get the following in my messages log. > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > request going? How can I get more debug info? > > > > > > Thanks for your help. > > > > > > Stephen > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ Message: 6 Date: Tue, 23 Sep 2003 18:46:27 +0200 From: Jan Janak <jan(a)iptel.org> Subject: Re: [Serusers] Troubles setting up radius authentication To: Steve Dolloff <sdolloff(a)noc.dls.net> Cc: Serusers <serusers(a)lists.iptel.org> Message-ID: <20030923164627.GL766(a)localhost.localdomain> Content-Type: text/plain; charset=iso-8859-2 Looking at modification time of sterman.c I realized that your sources are not recent enough. The file was last modified on September 12 and you built your server on September 11, so please try to update from the cvs, at least auth_radius module. Jan. On 23-09 11:39, Steve Dolloff wrote: > This is my current info. > > ser -V > version: ser 0.8.12dev-t16 (i386/linux) > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ main.c > compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > this was built from source off of CVS. If there is a newer version > that would give more info, I will recompile. > > Stephen > > > Hello, > > >From the information below I can't say where the problem is, but I > >would > say some attribute definitions are missing. > > Unfortunatelly the stable version of auth_radius module doesn't print > much debugging messages when something goes wrong. > > Did you compile your server from sources or do you use binary packages > ? You can try unstable version branch from the CVS, that should tell > you where the problem is, or I can send you a patch to stable version > if you can apply it and compile from sources. > > Jan. > > On 23-09 11:24, Steve Dolloff wrote: > > Yes, I have added the SIP definitions to the radiusclient library. > > It is the dictionary file defined in the radiusclient.conf file as > > /etc/sip_dictionary. It was created using the dictionary file from > > radiusclient and adding the information from the link that you > > refered to. > > > > ----------------------- > > > > Hello, > > > > if there is no radius traffic then radiusclient library has some > > problems when buiding the request. Did you extend your radius > dictionary > > as described in http://iptel.org/ser/ser_radius.html ? > > > > Jan. > > > > On 23-09 10:38, Steve Dolloff wrote: > > > I am trying to switch from database authentication to radius > > > authentication. > > > > > > I have compiled and installed the module. > > > > > > I have added the following to my ser.cfg > > > > > > modparam("auth_radius", "radius_config", > "/etc/ser/radiusclient.conf") > > > modparam("auth_radius", "service_type",15) > > > > > > if (method=="REGISTER") { > > > log(1,"authenticating"); > > > if > (!radius_www_authorize("test.net")) > > { > > > log(1,"radius auth > failure"); > > > www_challenge("test.net", > > "0"); > > > break; > > > }; > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > authserver radius1.test.net:1812 > > > authserver radius2.test.net:1812 > > > servers /etc/servers > > > dictionary /etc/sip_dictionary > > > > > > I have configured the following in /etc/servers > > > > > > Radius1.test.net secret > > > Radius2.test.net secret2 > > > > > > I get the following in my messages log. > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > > 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating Sep 23 > > > 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating Sep 23 > > > 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > request going? How can I get more debug info? > > > > > > Thanks for your help. > > > > > > Stephen > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ------------------------------ _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers End of Serusers Digest, Vol 5, Issue 50 ***************************************

1 0

[Serusers] Registration failes
by Teppo Lunnas 23 Sep '03

23 Sep '03

I have installed SER 0.8.11 on Mandrake 9.1 with its native MySQL and php and made MySQL-database with ser_mysql. The SER itself works fine with Messenger 4.7. Then I installed serweb and made all changes to its config.php and other files. Again it works ok but when I try to register a new user and answer to the e-mail that I get then there comes the following message: 400 Table 'aliases' not found in memory, use save("aliases") or lookup("aliases") in the configuration script first. We regret but your iptel.org confirmation attempt failed. Please contact info(a)iptel.org for further assistance. Back to login form. My registration details can yet be found in ser database from tables subscriber and pending at the same time. What goes wrong and what does that error message mean?

2 1

RE: [Serusers] Troubles setting up radius authentication
by Steve Dolloff 23 Sep '03

23 Sep '03

OK. I am no longer getting the mismatch error. I'm still not seeing any traffic from ngrep though. Here is the current stderr. 6(30439) lookup(): '' Not found in usrloc 6(30439) check_self - checking if host==us: 13==9 && [proxy.test.com] == [127.0.0.1] 6(30439) check_self - checking if port 5060 matches port 5060 6(30439) check_self - checking if host==us: 13==14 && [proxy.test.com] == [209.100.100.100] 6(30439) check_self - checking if port 5060 matches port 5060 6(30439) authenticating 6(30439) qm_malloc(0x80bf800, 112) called from parser/digest/digest.c: new_credentials(45) 6(30439) qm_malloc(0x80bf800, 112) returns address 0x80cc510 frag. 0x80cc4f8 (size=112) on 1 -th hit 6(30439) check_nonce(): comparing [3f70a48e8e18058bf396dd2fc71c2108e8dec351] and [3f70a48e8e18058bf396dd2fc71c2108e8dec351] 6(30439) qm_malloc(0x80bf800, 8) called from authorize.c: authorize(124) 6(30439) qm_malloc(0x80bf800, 8) returns address 0x80c9d00 frag. 0x80c9ce8 (size=12) on 1 -th hit 6(30439) qm_malloc(0x80bf800, 22) called from sterman.c: radius_authorize_sterman(81) 6(30439) qm_malloc(0x80bf800, 24) returns address 0x80cc404 frag. 0x80cc3ec (size=60) on 1 -th hit 6(30439) qm_free(0x80bf800, 0x80cc404), called from sterman.c: radius_authorize_sterman(94) 6(30439) qm_free: freeing frag. 0x80cc3ec alloc'ed from sterman.c: radius_authorize_sterman(81) 6(30439) radius_authorize_sterman(): Failure 6(30439) qm_free(0x80bf800, 0x80c9d00), called from authorize.c: authorize(131) 6(30439) qm_free: freeing frag. 0x80c9ce8 alloc'ed from authorize.c: authorize(124) 6(30439) radius auth failure 6(30439) qm_malloc(0x80bf800, 99) called from challenge.c: build_auth_hf(95) 6(30439) qm_malloc(0x80bf800, 100) returns address 0x80cc2dc frag. 0x80cc2c4 (size=100) on 1 -th hit 6(30439) build_auth_hf(): 'WWW-Authenticate: Digest realm="proxy.test.com", nonce="3f70a48e8e18058bf396dd2fc71c2108e8dec351" It is the first parameter of www_authenticate and www_challenge. The proxy puts this value into digest realm parameter and expects the same value in From/To header fields when a reply containing digest response comes back. Jan. On 23-09 14:32, Steve Dolloff wrote: > Where are these realm settings? The ATA that I am using doesn't have a > realm setting. Only a UID and Proxy. If I try to set > username(a)domain.com for the UID, the request comes in as > username@domain.com@proxyhost.domain.com. > > The request is currently coming in as follows.. > > 7(30152) DEBUG: get_hdr_field: <To> [28]; > uri=[sip:username@proxy.test.com] > 7(30152) DEBUG: to body [sip:username@proxy.test.com > > Then I see this. > > 7(30152) check_self - checking if host==us: 13==9 && [proxy.test.com] > == [127.0.0.1] > 7(30152) check_self - checking if port 5060 matches port 5060 > 7(30152) check_self - checking if host==us: 13==14 && [proxy.test.com] > == [209.100.100.100] > 7(30152) check_self - checking if port 5060 matches port 5060 > > I have these aliases set in my ser.cfg file. I'm not sure where else I > should change things at. > > alias="test.com" > alias="proxy.test.com" > alias="209.100.100.100" > > Thanks for your help. > > ----------------------------------------------------------------------- > > Yes, that is the problem. Realm in credentials and To host (in case of > REGISTER) or From host (for other SIP messages) must match. > > Jan. > > On 23-09 12:27, Steve Dolloff wrote: > > Jan, > > > > I rebuilt the server with the new module code. Here is the stderr > > output with a debug level of 10. > > > > Here is a snippet that might be related... > > > > 8(29501) authorize(): Credentials realm and URI host do not match > > 8(29501) radius auth failure 8(29501) qm_malloc(0x80bf800, 93) called > > from challenge.c: build_auth_hf(95) > > > > > > Here is everything... > > > > ) > > 6(29499) qm_malloc(0x80bf800, 604) returns address 0x80cce24 frag. > > 0x80cce0c (size=608) on 1 -th hit > > 6(29499) qm_free(0x80bf800, 0x80c8fa8), called from msg_translator.c: > > build_res_buf_with_body_from_sip_req(1818) > > 6(29499) qm_free: freeing frag. 0x80c8f90 alloc'ed from > > msg_translator.c: rport_builder(330) > > 6(29499) qm_free(0x80bf800, 0x80cce24), called from sl_funcs.c: > > sl_send_reply(178) > > 6(29499) qm_free: freeing frag. 0x80cce0c alloc'ed from > > msg_translator.c: build_res_buf_with_body_from_sip_req(1665) > > 6(29499) qm_free(0x80bf800, 0x80cc2c8), called from challenge.c: > > challenge(174) > > 6(29499) qm_free: freeing frag. 0x80cc2b0 alloc'ed from challenge.c: > > build_auth_hf(95) > > 6(29499) receive_msg: cleaning up > > 6(29499) qm_free(0x80bf800, 0x80cbc6c), called from > parser/parse_via.c: > > free_via_list(1973) > > 6(29499) qm_free: freeing frag. 0x80cbc54 alloc'ed from > > parser/msg_parser.c: get_hdr_field(109) > > 6(29499) qm_free(0x80bf800, 0x80cbfe4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbfcc alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cc1d8), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cc1c0 alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cc084), called from > parser/parse_to.c: > > free_to(778) > > 6(29499) qm_free: freeing frag. 0x80cc06c alloc'ed from > > parser/msg_parser.c: get_hdr_field(149) > > 6(29499) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbf7c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cc034), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cc01c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80c8934), called from > > parser/parse_cseq.c: free_cseq(102) > > 6(29499) qm_free: freeing frag. 0x80c891c alloc'ed from > > parser/msg_parser.c: get_hdr_field(128) > > 6(29499) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbf2c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cc0d8), called from > > parser/parse_param.c: do_free_params(420) > > 6(29499) qm_free: freeing frag. 0x80cc0c0 alloc'ed from > > parser/parse_param.c: parse_params(337) > > 6(29499) qm_free(0x80bf800, 0x80cbdb0), called from > > parser/contact/contact.c: free_contacts(293) > > 6(29499) qm_free: freeing frag. 0x80cbd98 alloc'ed from > > parser/contact/contact.c: parse_contacts(194) > > 6(29499) qm_free(0x80bf800, 0x80ca3cc), called from > > parser/contact/parse_contact.c: free_contact(109) > > 6(29499) qm_free: freeing frag. 0x80ca3b4 alloc'ed from > > parser/contact/parse_contact.c: parse_contact(81) > > 6(29499) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbedc alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbe8c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbe3c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80cbd60), called from parser/hf.c: > > free_hdr_field_lst(170) > > 6(29499) qm_free: freeing frag. 0x80cbd48 alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 6(29499) qm_free(0x80bf800, 0x80c9da8), called from data_lump.c: > > free_lump(321) > > 6(29499) qm_free: freeing frag. 0x80c9d90 alloc'ed from mf_funcs.c: > > add_maxfwd_header(131) > > 6(29499) qm_free(0x80bf800, 0x80cbc1c), called from data_lump.c: > > free_lump_list(346) > > 6(29499) qm_free: freeing frag. 0x80cbc04 alloc'ed from data_lump.c: > > insert_new_lump_before(136) > > 6(29499) qm_free(0x80bf800, 0x80cbe04), called from data_lump.c: > > free_lump_list(357) > > 6(29499) qm_free: freeing frag. 0x80cbdec alloc'ed from data_lump.c: > > anchor_lump(292) > > 6(29499) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: > > free_lump(321) > > 6(29499) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: > > fix_nated_contact_f(204) > > 6(29499) qm_free(0x80bf800, 0x80cc124), called from data_lump.c: > > free_lump_list(352) > > 6(29499) qm_free: freeing frag. 0x80cc10c alloc'ed from data_lump.c: > > insert_new_lump_after(111) > > 6(29499) qm_free(0x80bf800, 0x80cbd10), called from data_lump.c: > > free_lump_list(357) > > 6(29499) qm_free: freeing frag. 0x80cbcf8 alloc'ed from data_lump.c: > > del_lump(262) > > 6(29499) qm_free(0x80bf800, 0x80cc358), called from data_lump_rpl.c: > > free_lump_rpl(84) > > 6(29499) qm_free: freeing frag. 0x80cc340 alloc'ed from > > data_lump_rpl.c: build_lump_rpl(47) > > 6(29499) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: > > free_lump_rpl(85) > > 6(29499) qm_free: freeing frag. 0x80c9cd8 alloc'ed from > > data_lump_rpl.c: build_lump_rpl(40) > > 6(29499) qm_free(0x80bf800, 0x80cb918), called from receive.c: > > receive_msg(187) > > 6(29499) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: > > receive_msg(78) > > 8(29501) qm_malloc(0x80bf800, 724) called from receive.c: > > receive_msg(78) > > 8(29501) qm_malloc(0x80bf800, 724) returns address 0x80cb918 frag. > > 0x80cb900 (size=724) on 1 -th hit > > 8(29501) SIP Request: > > 8(29501) method: <REGISTER> > > 8(29501) uri: <sip:209.111.111.111> > > 8(29501) version: <SIP/2.0> > > 8(29501) parse_headers: flags=1 > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc1d8 frag. > > 0x80cc1c0 (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 116) called from parser/msg_parser.c: > > get_hdr_field(109) > > 8(29501) qm_malloc(0x80bf800, 116) returns address 0x80cbc6c frag. > > 0x80cbc54 (size=116) on 1 -th hit > > 8(29501) end of header reached, state=5 > > 8(29501) parse_headers: Via found, flags=1 > > 8(29501) parse_headers: this is the first via > > 8(29501) After parse_msg... > > 8(29501) preparing to run routing scripts... > > 8(29501) DEBUG : is_maxfwd_present: searching for max_forwards header > > 8(29501) parse_headers: flags=128 > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc124 frag. > > 0x80cc10c (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc034 frag. > > 0x80cc01c (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 36) called from parser/msg_parser.c: > > get_hdr_field(149) > > 8(29501) qm_malloc(0x80bf800, 36) returns address 0x80cc084 frag. > > 0x80cc06c (size=36) on 1 -th hit > > 8(29501) end of header reached, state=8 > > 8(29501) DEBUG: get_hdr_field: <To> [29]; > > uri=[sip:testuser@209.111.111.111] > > 8(29501) DEBUG: to body [sip:testuser@209.111.111.111 > > ] > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbfe4 frag. > > 0x80cbfcc (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbf94 frag. > > 0x80cbf7c (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 20) called from parser/msg_parser.c: > > get_hdr_field(128) > > 8(29501) qm_malloc(0x80bf800, 20) returns address 0x80c8934 frag. > > 0x80c891c (size=20) on 1 -th hit > > 8(29501) get_hdr_field: cseq <CSeq>: <4> <REGISTER> > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbf44 frag. > > 0x80cbf2c (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbef4 frag. > > 0x80cbedc (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbea4 frag. > > 0x80cbe8c (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbe54 frag. > > 0x80cbe3c (size=32) on 1 -th hit > > 8(29501) DEBUG: get_hdr_body : content_length=0 > > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > > parse_headers(276) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd60 frag. > > 0x80cbd48 (size=32) on 1 -th hit > > 8(29501) found end of header > > 8(29501) qm_free(0x80bf800, 0x80cbd60), called from > > parser/msg_parser.c: parse_headers(292) > > 8(29501) qm_free: freeing frag. 0x80cbd48 alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) DEBUG: is_maxfwd_present: max_forwards header not found! > > 8(29501) qm_malloc(0x80bf800, 19) called from mf_funcs.c: > > add_maxfwd_header(131) > > 8(29501) qm_malloc(0x80bf800, 20) returns address 0x80c9da8 frag. > > 0x80c9d90 (size=20) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > > anchor_lump(292) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd60 frag. > > 0x80cbd48 (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > > insert_new_lump_before(136) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbe04 frag. > > 0x80cbdec (size=32) on 1 -th hit > > 8(29501) parse_headers: flags=256 > > 8(29501) find_first_route(): No Route headers found > > 8(29501) loose_route(): There is no Route HF > > 8(29501) parse_headers: flags=64 > > 8(29501) qm_malloc(0x80bf800, 8) called from > > parser/contact/parse_contact.c: parse_contact(81) > > 8(29501) qm_malloc(0x80bf800, 8) returns address 0x80ca3cc frag. > > 0x80ca3b4 (size=8) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 36) called from > parser/contact/contact.c: > > parse_contacts(194) > > 8(29501) qm_malloc(0x80bf800, 36) returns address 0x80cbdb0 frag. > > 0x80cbd98 (size=36) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 28) called from parser/parse_param.c: > > parse_params(337) > > 8(29501) qm_malloc(0x80bf800, 28) returns address 0x80cc0d8 frag. > > 0x80cc0c0 (size=28) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > > del_lump(262) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbc1c frag. > > 0x80cbc04 (size=32) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 50) called from nathelper.c: > > fix_nated_contact_f(204) > > 8(29501) qm_malloc(0x80bf800, 52) returns address 0x80cc174 frag. > > 0x80cc15c (size=52) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > > insert_new_lump_after(111) > > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd10 frag. > > 0x80cbcf8 (size=32) on 1 -th hit > > 8(29501) lookup(): '' Not found in usrloc > > 8(29501) check_self - checking if host==us: 14==9 && > [209.111.111.111] > > == [127.0.0.1] > > 8(29501) check_self - checking if port 5060 matches port 5060 > > 8(29501) check_self - checking if host==us: 14==14 && > > [209.111.111.111] == [209.111.111.111] > > 8(29501) check_self - checking if port 5060 matches port 5060 > > 8(29501) authenticating 8(29501) qm_malloc(0x80bf800, 112) called > from > > parser/digest/digest.c: new_credentials(45) > > 8(29501) qm_malloc(0x80bf800, 112) returns address 0x80cccd4 frag. > > 0x80cccbc (size=112) on 1 -th hit > > 8(29501) check_nonce(): comparing > > [3f7082586fcd71add3ccdd5231b328c4ff00c536] and > > [3f7082586fcd71add3ccdd5231b328c4ff00c536] > > 8(29501) authorize(): Credentials realm and URI host do not match > > 8(29501) radius auth failure 8(29501) qm_malloc(0x80bf800, 93) called > > from challenge.c: build_auth_hf(95) > > 8(29501) qm_malloc(0x80bf800, 96) returns address 0x80cc2c8 frag. > > 0x80cc2b0 (size=96) on 1 -th hit > > 8(29501) build_auth_hf(): 'WWW-Authenticate: Digest realm="dls.net", > > nonce="3f7082586fcd71add3ccdd5231b328c4ff00c536" > > ' > > 8(29501) qm_malloc(0x80bf800, 12) called from data_lump_rpl.c: > > build_lump_rpl(40) > > 8(29501) qm_malloc(0x80bf800, 12) returns address 0x80c9cf0 frag. > > 0x80c9cd8 (size=12) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 92) called from data_lump_rpl.c: > > build_lump_rpl(47) > > 8(29501) qm_malloc(0x80bf800, 92) returns address 0x80cc358 frag. > > 0x80cc340 (size=92) on 1 -th hit > > 8(29501) parse_headers: flags=-1 > > 8(29501) check_via_address(209.111.111.100, 209.111.111.100, 0) > > 8(29501) qm_malloc(0x80bf800, 12) called from msg_translator.c: > > rport_builder(330) > > 8(29501) qm_malloc(0x80bf800, 12) returns address 0x80c8fa8 frag. > > 0x80c8f90 (size=16) on 1 -th hit > > 8(29501) qm_malloc(0x80bf800, 604) called from msg_translator.c: > > build_res_buf_with_body_from_sip_req(1665) > > 8(29501) qm_malloc(0x80bf800, 604) returns address 0x80cce24 frag. > > 0x80cce0c (size=608) on 1 -th hit > > 8(29501) qm_free(0x80bf800, 0x80c8fa8), called from msg_translator.c: > > build_res_buf_with_body_from_sip_req(1818) > > 8(29501) qm_free: freeing frag. 0x80c8f90 alloc'ed from > > msg_translator.c: rport_builder(330) > > 8(29501) qm_free(0x80bf800, 0x80cce24), called from sl_funcs.c: > > sl_send_reply(178) > > 8(29501) qm_free: freeing frag. 0x80cce0c alloc'ed from > > msg_translator.c: build_res_buf_with_body_from_sip_req(1665) > > 8(29501) qm_free(0x80bf800, 0x80cc2c8), called from challenge.c: > > challenge(174) > > 8(29501) qm_free: freeing frag. 0x80cc2b0 alloc'ed from challenge.c: > > build_auth_hf(95) > > 8(29501) receive_msg: cleaning up > > 8(29501) qm_free(0x80bf800, 0x80cbc6c), called from > parser/parse_via.c: > > free_via_list(1973) > > 8(29501) qm_free: freeing frag. 0x80cbc54 alloc'ed from > > parser/msg_parser.c: get_hdr_field(109) > > 8(29501) qm_free(0x80bf800, 0x80cc1d8), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cc1c0 alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cc124), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cc10c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cc084), called from > parser/parse_to.c: > > free_to(778) > > 8(29501) qm_free: freeing frag. 0x80cc06c alloc'ed from > > parser/msg_parser.c: get_hdr_field(149) > > 8(29501) qm_free(0x80bf800, 0x80cc034), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cc01c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cbfe4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbfcc alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80c8934), called from > > parser/parse_cseq.c: free_cseq(102) > > 8(29501) qm_free: freeing frag. 0x80c891c alloc'ed from > > parser/msg_parser.c: get_hdr_field(128) > > 8(29501) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbf7c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cc0d8), called from > > parser/parse_param.c: do_free_params(420) > > 8(29501) qm_free: freeing frag. 0x80cc0c0 alloc'ed from > > parser/parse_param.c: parse_params(337) > > 8(29501) qm_free(0x80bf800, 0x80cbdb0), called from > > parser/contact/contact.c: free_contacts(293) > > 8(29501) qm_free: freeing frag. 0x80cbd98 alloc'ed from > > parser/contact/contact.c: parse_contacts(194) > > 8(29501) qm_free(0x80bf800, 0x80ca3cc), called from > > parser/contact/parse_contact.c: free_contact(109) > > 8(29501) qm_free: freeing frag. 0x80ca3b4 alloc'ed from > > parser/contact/parse_contact.c: parse_contact(81) > > 8(29501) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbf2c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbedc alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbe8c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: > > free_hdr_field_lst(170) > > 8(29501) qm_free: freeing frag. 0x80cbe3c alloc'ed from > > parser/msg_parser.c: parse_headers(276) > > 8(29501) qm_free(0x80bf800, 0x80c9da8), called from data_lump.c: > > free_lump(321) > > 8(29501) qm_free: freeing frag. 0x80c9d90 alloc'ed from mf_funcs.c: > > add_maxfwd_header(131) > > 8(29501) qm_free(0x80bf800, 0x80cbe04), called from data_lump.c: > > free_lump_list(346) > > 8(29501) qm_free: freeing frag. 0x80cbdec alloc'ed from data_lump.c: > > insert_new_lump_before(136) > > 8(29501) qm_free(0x80bf800, 0x80cbd60), called from data_lump.c: > > free_lump_list(357) > > 8(29501) qm_free: freeing frag. 0x80cbd48 alloc'ed from data_lump.c: > > anchor_lump(292) > > 8(29501) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: > > free_lump(321) > > 8(29501) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: > > fix_nated_contact_f(204) > > 8(29501) qm_free(0x80bf800, 0x80cbd10), called from data_lump.c: > > free_lump_list(352) > > 8(29501) qm_free: freeing frag. 0x80cbcf8 alloc'ed from data_lump.c: > > insert_new_lump_after(111) > > 8(29501) qm_free(0x80bf800, 0x80cbc1c), called from data_lump.c: > > free_lump_list(357) > > 8(29501) qm_free: freeing frag. 0x80cbc04 alloc'ed from data_lump.c: > > del_lump(262) > > 8(29501) qm_free(0x80bf800, 0x80cc358), called from data_lump_rpl.c: > > free_lump_rpl(84) > > 8(29501) qm_free: freeing frag. 0x80cc340 alloc'ed from > > data_lump_rpl.c: build_lump_rpl(47) > > 8(29501) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: > > free_lump_rpl(85) > > 8(29501) qm_free: freeing frag. 0x80c9cd8 alloc'ed from > > data_lump_rpl.c: build_lump_rpl(40) > > 8(29501) qm_free(0x80bf800, 0x80cb918), called from receive.c: > > receive_msg(187) > > 8(29501) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: > > receive_msg(78) > > 10(29527) qm_malloc(0x80bf800, 160) called from nathelper.c: > timer(689) > > 10(29527) qm_malloc(0x80bf800, 160) returns address 0x80cb918 frag. > > 0x80cb900 (size=160) on 1 -th hit > > 10(29527) qm_free(0x80bf800, 0x80cb918), called from nathelper.c: > > timer(743) > > 10(29527) qm_free: freeing frag. 0x80cb900 alloc'ed from nathelper.c: > > timer(689) > > 10(29527) qm_malloc(0x80bf800, 160) called from nathelper.c: > timer(689) > > 10(29527) qm_malloc(0x80bf800, 160) returns address 0x80cb918 frag. > > 0x80cb900 (size=160) on 1 -th hit > > 10(29527) qm_free(0x80bf800, 0x80cb918), called from nathelper.c: > > timer(743) > > 10(29527) qm_free: freeing frag. 0x80cb900 alloc'ed from nathelper.c: > > timer(689) > > > > > > > > -----Original Message----- > > From: Jan Janak [mailto:jan@iptel.org] > > Sent: Tuesday, September 23, 2003 11:46 AM > > To: Steve Dolloff > > Cc: Serusers > > Subject: Re: [Serusers] Troubles setting up radius authentication > > > > Looking at modification time of sterman.c I realized that your > > sources are not recent enough. The file was last modified on September > > 12 and you built your server on September 11, so please try to update > > from the cvs, at least auth_radius module. > > > > Jan. > > > > On 23-09 11:39, Steve Dolloff wrote: > > > This is my current info. > > > > > > ser -V > > > version: ser 0.8.12dev-t16 (i386/linux) > > > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > > > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, > FAST_LOCK-ADAPTIVE_WAIT > > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN > 16, > > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ > > > main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > > > > > this was built from source off of CVS. If there is a newer version > > that > > > would give more info, I will recompile. > > > > > > Stephen > > > > > > > > > Hello, > > > > > > >From the information below I can't say where the problem is, but I > > would > > > say some attribute definitions are missing. > > > > > > Unfortunatelly the stable version of auth_radius module doesn't > print > > > much debugging messages when something goes wrong. > > > > > > Did you compile your server from sources or do you use binary > packages > > ? > > > You can try unstable version branch from the CVS, that should tell > you > > > where the problem is, or I can send you a patch to stable version if > > you > > > can apply it and compile from sources. > > > > > > Jan. > > > > > > On 23-09 11:24, Steve Dolloff wrote: > > > > Yes, I have added the SIP definitions to the radiusclient library. > > It > > > > is the dictionary file defined in the radiusclient.conf file as > > > > /etc/sip_dictionary. It was created using the dictionary file > from > > > > radiusclient and adding the information from the link that you > > refered > > > > to. > > > > > > > > ----------------------- > > > > > > > > Hello, > > > > > > > > if there is no radius traffic then radiusclient library has some > > > > problems when buiding the request. Did you extend your radius > > > dictionary > > > > as described in http://iptel.org/ser/ser_radius.html ? > > > > > > > > Jan. > > > > > > > > On 23-09 10:38, Steve Dolloff wrote: > > > > > I am trying to switch from database authentication to radius > > > > > authentication. > > > > > > > > > > I have compiled and installed the module. > > > > > > > > > > I have added the following to my ser.cfg > > > > > > > > > > modparam("auth_radius", "radius_config", > > > "/etc/ser/radiusclient.conf") > > > > > modparam("auth_radius", "service_type",15) > > > > > > > > > > if (method=="REGISTER") { > > > > > log(1,"authenticating"); > > > > > if > > > (!radius_www_authorize("test.net")) > > > > { > > > > > log(1,"radius auth > > > failure"); > > > > > > www_challenge("test.net", > > > > "0"); > > > > > break; > > > > > }; > > > > > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > > > authserver radius1.test.net:1812 > > > > > authserver radius2.test.net:1812 > > > > > servers /etc/servers > > > > > dictionary /etc/sip_dictionary > > > > > > > > > > I have configured the following in /etc/servers > > > > > > > > > > Radius1.test.net secret > > > > > Radius2.test.net secret2 > > > > > > > > > > I get the following in my messages log. > > > > > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > > > > > And ngrep port 1812 shows no traffic at all. Where are these > auth > > > > > request going? How can I get more debug info? > > > > > > > > > > Thanks for your help. > > > > > > > > > > Stephen > > > > > > > > > > > > > > > _______________________________________________ > > > > > Serusers mailing list > > > > > serusers(a)lists.iptel.org > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers

1 0

RE: [Serusers] Troubles setting up radius authentication
by Steve Dolloff 23 Sep '03

23 Sep '03

Where are these realm settings? The ATA that I am using doesn't have a realm setting. Only a UID and Proxy. If I try to set username(a)domain.com for the UID, the request comes in as username@domain.com@proxyhost.domain.com. The request is currently coming in as follows.. 7(30152) DEBUG: get_hdr_field: <To> [28]; uri=[sip:username@proxy.test.com] 7(30152) DEBUG: to body [sip:username@proxy.test.com Then I see this. 7(30152) check_self - checking if host==us: 13==9 && [proxy.test.com] == [127.0.0.1] 7(30152) check_self - checking if port 5060 matches port 5060 7(30152) check_self - checking if host==us: 13==14 && [proxy.test.com] == [209.100.100.100] 7(30152) check_self - checking if port 5060 matches port 5060 I have these aliases set in my ser.cfg file. I'm not sure where else I should change things at. alias="test.com" alias="proxy.test.com" alias="209.100.100.100" Thanks for your help. ----------------------------------------------------------------------- Yes, that is the problem. Realm in credentials and To host (in case of REGISTER) or From host (for other SIP messages) must match. Jan. On 23-09 12:27, Steve Dolloff wrote: > Jan, > > I rebuilt the server with the new module code. Here is the stderr > output with a debug level of 10. > > Here is a snippet that might be related... > > 8(29501) authorize(): Credentials realm and URI host do not match > 8(29501) radius auth failure 8(29501) qm_malloc(0x80bf800, 93) called > from challenge.c: build_auth_hf(95) > > > Here is everything... > > ) > 6(29499) qm_malloc(0x80bf800, 604) returns address 0x80cce24 frag. > 0x80cce0c (size=608) on 1 -th hit > 6(29499) qm_free(0x80bf800, 0x80c8fa8), called from msg_translator.c: > build_res_buf_with_body_from_sip_req(1818) > 6(29499) qm_free: freeing frag. 0x80c8f90 alloc'ed from > msg_translator.c: rport_builder(330) > 6(29499) qm_free(0x80bf800, 0x80cce24), called from sl_funcs.c: > sl_send_reply(178) > 6(29499) qm_free: freeing frag. 0x80cce0c alloc'ed from > msg_translator.c: build_res_buf_with_body_from_sip_req(1665) > 6(29499) qm_free(0x80bf800, 0x80cc2c8), called from challenge.c: > challenge(174) > 6(29499) qm_free: freeing frag. 0x80cc2b0 alloc'ed from challenge.c: > build_auth_hf(95) > 6(29499) receive_msg: cleaning up > 6(29499) qm_free(0x80bf800, 0x80cbc6c), called from parser/parse_via.c: > free_via_list(1973) > 6(29499) qm_free: freeing frag. 0x80cbc54 alloc'ed from > parser/msg_parser.c: get_hdr_field(109) > 6(29499) qm_free(0x80bf800, 0x80cbfe4), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbfcc alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cc1d8), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cc1c0 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cc084), called from parser/parse_to.c: > free_to(778) > 6(29499) qm_free: freeing frag. 0x80cc06c alloc'ed from > parser/msg_parser.c: get_hdr_field(149) > 6(29499) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbf7c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cc034), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cc01c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80c8934), called from > parser/parse_cseq.c: free_cseq(102) > 6(29499) qm_free: freeing frag. 0x80c891c alloc'ed from > parser/msg_parser.c: get_hdr_field(128) > 6(29499) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbf2c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cc0d8), called from > parser/parse_param.c: do_free_params(420) > 6(29499) qm_free: freeing frag. 0x80cc0c0 alloc'ed from > parser/parse_param.c: parse_params(337) > 6(29499) qm_free(0x80bf800, 0x80cbdb0), called from > parser/contact/contact.c: free_contacts(293) > 6(29499) qm_free: freeing frag. 0x80cbd98 alloc'ed from > parser/contact/contact.c: parse_contacts(194) > 6(29499) qm_free(0x80bf800, 0x80ca3cc), called from > parser/contact/parse_contact.c: free_contact(109) > 6(29499) qm_free: freeing frag. 0x80ca3b4 alloc'ed from > parser/contact/parse_contact.c: parse_contact(81) > 6(29499) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbedc alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbe8c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbe3c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80cbd60), called from parser/hf.c: > free_hdr_field_lst(170) > 6(29499) qm_free: freeing frag. 0x80cbd48 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 6(29499) qm_free(0x80bf800, 0x80c9da8), called from data_lump.c: > free_lump(321) > 6(29499) qm_free: freeing frag. 0x80c9d90 alloc'ed from mf_funcs.c: > add_maxfwd_header(131) > 6(29499) qm_free(0x80bf800, 0x80cbc1c), called from data_lump.c: > free_lump_list(346) > 6(29499) qm_free: freeing frag. 0x80cbc04 alloc'ed from data_lump.c: > insert_new_lump_before(136) > 6(29499) qm_free(0x80bf800, 0x80cbe04), called from data_lump.c: > free_lump_list(357) > 6(29499) qm_free: freeing frag. 0x80cbdec alloc'ed from data_lump.c: > anchor_lump(292) > 6(29499) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: > free_lump(321) > 6(29499) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: > fix_nated_contact_f(204) > 6(29499) qm_free(0x80bf800, 0x80cc124), called from data_lump.c: > free_lump_list(352) > 6(29499) qm_free: freeing frag. 0x80cc10c alloc'ed from data_lump.c: > insert_new_lump_after(111) > 6(29499) qm_free(0x80bf800, 0x80cbd10), called from data_lump.c: > free_lump_list(357) > 6(29499) qm_free: freeing frag. 0x80cbcf8 alloc'ed from data_lump.c: > del_lump(262) > 6(29499) qm_free(0x80bf800, 0x80cc358), called from data_lump_rpl.c: > free_lump_rpl(84) > 6(29499) qm_free: freeing frag. 0x80cc340 alloc'ed from > data_lump_rpl.c: build_lump_rpl(47) > 6(29499) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: > free_lump_rpl(85) > 6(29499) qm_free: freeing frag. 0x80c9cd8 alloc'ed from > data_lump_rpl.c: build_lump_rpl(40) > 6(29499) qm_free(0x80bf800, 0x80cb918), called from receive.c: > receive_msg(187) > 6(29499) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: > receive_msg(78) > 8(29501) qm_malloc(0x80bf800, 724) called from receive.c: > receive_msg(78) > 8(29501) qm_malloc(0x80bf800, 724) returns address 0x80cb918 frag. > 0x80cb900 (size=724) on 1 -th hit > 8(29501) SIP Request: > 8(29501) method: <REGISTER> > 8(29501) uri: <sip:209.111.111.111> > 8(29501) version: <SIP/2.0> > 8(29501) parse_headers: flags=1 > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc1d8 frag. > 0x80cc1c0 (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 116) called from parser/msg_parser.c: > get_hdr_field(109) > 8(29501) qm_malloc(0x80bf800, 116) returns address 0x80cbc6c frag. > 0x80cbc54 (size=116) on 1 -th hit > 8(29501) end of header reached, state=5 > 8(29501) parse_headers: Via found, flags=1 > 8(29501) parse_headers: this is the first via > 8(29501) After parse_msg... > 8(29501) preparing to run routing scripts... > 8(29501) DEBUG : is_maxfwd_present: searching for max_forwards header > 8(29501) parse_headers: flags=128 > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc124 frag. > 0x80cc10c (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cc034 frag. > 0x80cc01c (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 36) called from parser/msg_parser.c: > get_hdr_field(149) > 8(29501) qm_malloc(0x80bf800, 36) returns address 0x80cc084 frag. > 0x80cc06c (size=36) on 1 -th hit > 8(29501) end of header reached, state=8 > 8(29501) DEBUG: get_hdr_field: <To> [29]; > uri=[sip:testuser@209.111.111.111] > 8(29501) DEBUG: to body [sip:testuser@209.111.111.111 > ] > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbfe4 frag. > 0x80cbfcc (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbf94 frag. > 0x80cbf7c (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 20) called from parser/msg_parser.c: > get_hdr_field(128) > 8(29501) qm_malloc(0x80bf800, 20) returns address 0x80c8934 frag. > 0x80c891c (size=20) on 1 -th hit > 8(29501) get_hdr_field: cseq <CSeq>: <4> <REGISTER> > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbf44 frag. > 0x80cbf2c (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbef4 frag. > 0x80cbedc (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbea4 frag. > 0x80cbe8c (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbe54 frag. > 0x80cbe3c (size=32) on 1 -th hit > 8(29501) DEBUG: get_hdr_body : content_length=0 > 8(29501) qm_malloc(0x80bf800, 32) called from parser/msg_parser.c: > parse_headers(276) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd60 frag. > 0x80cbd48 (size=32) on 1 -th hit > 8(29501) found end of header > 8(29501) qm_free(0x80bf800, 0x80cbd60), called from > parser/msg_parser.c: parse_headers(292) > 8(29501) qm_free: freeing frag. 0x80cbd48 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) DEBUG: is_maxfwd_present: max_forwards header not found! > 8(29501) qm_malloc(0x80bf800, 19) called from mf_funcs.c: > add_maxfwd_header(131) > 8(29501) qm_malloc(0x80bf800, 20) returns address 0x80c9da8 frag. > 0x80c9d90 (size=20) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > anchor_lump(292) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd60 frag. > 0x80cbd48 (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > insert_new_lump_before(136) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbe04 frag. > 0x80cbdec (size=32) on 1 -th hit > 8(29501) parse_headers: flags=256 > 8(29501) find_first_route(): No Route headers found > 8(29501) loose_route(): There is no Route HF > 8(29501) parse_headers: flags=64 > 8(29501) qm_malloc(0x80bf800, 8) called from > parser/contact/parse_contact.c: parse_contact(81) > 8(29501) qm_malloc(0x80bf800, 8) returns address 0x80ca3cc frag. > 0x80ca3b4 (size=8) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 36) called from parser/contact/contact.c: > parse_contacts(194) > 8(29501) qm_malloc(0x80bf800, 36) returns address 0x80cbdb0 frag. > 0x80cbd98 (size=36) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 28) called from parser/parse_param.c: > parse_params(337) > 8(29501) qm_malloc(0x80bf800, 28) returns address 0x80cc0d8 frag. > 0x80cc0c0 (size=28) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > del_lump(262) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbc1c frag. > 0x80cbc04 (size=32) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 50) called from nathelper.c: > fix_nated_contact_f(204) > 8(29501) qm_malloc(0x80bf800, 52) returns address 0x80cc174 frag. > 0x80cc15c (size=52) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 32) called from data_lump.c: > insert_new_lump_after(111) > 8(29501) qm_malloc(0x80bf800, 32) returns address 0x80cbd10 frag. > 0x80cbcf8 (size=32) on 1 -th hit > 8(29501) lookup(): '' Not found in usrloc > 8(29501) check_self - checking if host==us: 14==9 && [209.111.111.111] > == [127.0.0.1] > 8(29501) check_self - checking if port 5060 matches port 5060 > 8(29501) check_self - checking if host==us: 14==14 && > [209.111.111.111] == [209.111.111.111] > 8(29501) check_self - checking if port 5060 matches port 5060 > 8(29501) authenticating 8(29501) qm_malloc(0x80bf800, 112) called from > parser/digest/digest.c: new_credentials(45) > 8(29501) qm_malloc(0x80bf800, 112) returns address 0x80cccd4 frag. > 0x80cccbc (size=112) on 1 -th hit > 8(29501) check_nonce(): comparing > [3f7082586fcd71add3ccdd5231b328c4ff00c536] and > [3f7082586fcd71add3ccdd5231b328c4ff00c536] > 8(29501) authorize(): Credentials realm and URI host do not match > 8(29501) radius auth failure 8(29501) qm_malloc(0x80bf800, 93) called > from challenge.c: build_auth_hf(95) > 8(29501) qm_malloc(0x80bf800, 96) returns address 0x80cc2c8 frag. > 0x80cc2b0 (size=96) on 1 -th hit > 8(29501) build_auth_hf(): 'WWW-Authenticate: Digest realm="dls.net", > nonce="3f7082586fcd71add3ccdd5231b328c4ff00c536" > ' > 8(29501) qm_malloc(0x80bf800, 12) called from data_lump_rpl.c: > build_lump_rpl(40) > 8(29501) qm_malloc(0x80bf800, 12) returns address 0x80c9cf0 frag. > 0x80c9cd8 (size=12) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 92) called from data_lump_rpl.c: > build_lump_rpl(47) > 8(29501) qm_malloc(0x80bf800, 92) returns address 0x80cc358 frag. > 0x80cc340 (size=92) on 1 -th hit > 8(29501) parse_headers: flags=-1 > 8(29501) check_via_address(209.111.111.100, 209.111.111.100, 0) > 8(29501) qm_malloc(0x80bf800, 12) called from msg_translator.c: > rport_builder(330) > 8(29501) qm_malloc(0x80bf800, 12) returns address 0x80c8fa8 frag. > 0x80c8f90 (size=16) on 1 -th hit > 8(29501) qm_malloc(0x80bf800, 604) called from msg_translator.c: > build_res_buf_with_body_from_sip_req(1665) > 8(29501) qm_malloc(0x80bf800, 604) returns address 0x80cce24 frag. > 0x80cce0c (size=608) on 1 -th hit > 8(29501) qm_free(0x80bf800, 0x80c8fa8), called from msg_translator.c: > build_res_buf_with_body_from_sip_req(1818) > 8(29501) qm_free: freeing frag. 0x80c8f90 alloc'ed from > msg_translator.c: rport_builder(330) > 8(29501) qm_free(0x80bf800, 0x80cce24), called from sl_funcs.c: > sl_send_reply(178) > 8(29501) qm_free: freeing frag. 0x80cce0c alloc'ed from > msg_translator.c: build_res_buf_with_body_from_sip_req(1665) > 8(29501) qm_free(0x80bf800, 0x80cc2c8), called from challenge.c: > challenge(174) > 8(29501) qm_free: freeing frag. 0x80cc2b0 alloc'ed from challenge.c: > build_auth_hf(95) > 8(29501) receive_msg: cleaning up > 8(29501) qm_free(0x80bf800, 0x80cbc6c), called from parser/parse_via.c: > free_via_list(1973) > 8(29501) qm_free: freeing frag. 0x80cbc54 alloc'ed from > parser/msg_parser.c: get_hdr_field(109) > 8(29501) qm_free(0x80bf800, 0x80cc1d8), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cc1c0 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cc124), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cc10c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cc084), called from parser/parse_to.c: > free_to(778) > 8(29501) qm_free: freeing frag. 0x80cc06c alloc'ed from > parser/msg_parser.c: get_hdr_field(149) > 8(29501) qm_free(0x80bf800, 0x80cc034), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cc01c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cbfe4), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbfcc alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80c8934), called from > parser/parse_cseq.c: free_cseq(102) > 8(29501) qm_free: freeing frag. 0x80c891c alloc'ed from > parser/msg_parser.c: get_hdr_field(128) > 8(29501) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbf7c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cc0d8), called from > parser/parse_param.c: do_free_params(420) > 8(29501) qm_free: freeing frag. 0x80cc0c0 alloc'ed from > parser/parse_param.c: parse_params(337) > 8(29501) qm_free(0x80bf800, 0x80cbdb0), called from > parser/contact/contact.c: free_contacts(293) > 8(29501) qm_free: freeing frag. 0x80cbd98 alloc'ed from > parser/contact/contact.c: parse_contacts(194) > 8(29501) qm_free(0x80bf800, 0x80ca3cc), called from > parser/contact/parse_contact.c: free_contact(109) > 8(29501) qm_free: freeing frag. 0x80ca3b4 alloc'ed from > parser/contact/parse_contact.c: parse_contact(81) > 8(29501) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbf2c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbedc alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbe8c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: > free_hdr_field_lst(170) > 8(29501) qm_free: freeing frag. 0x80cbe3c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(29501) qm_free(0x80bf800, 0x80c9da8), called from data_lump.c: > free_lump(321) > 8(29501) qm_free: freeing frag. 0x80c9d90 alloc'ed from mf_funcs.c: > add_maxfwd_header(131) > 8(29501) qm_free(0x80bf800, 0x80cbe04), called from data_lump.c: > free_lump_list(346) > 8(29501) qm_free: freeing frag. 0x80cbdec alloc'ed from data_lump.c: > insert_new_lump_before(136) > 8(29501) qm_free(0x80bf800, 0x80cbd60), called from data_lump.c: > free_lump_list(357) > 8(29501) qm_free: freeing frag. 0x80cbd48 alloc'ed from data_lump.c: > anchor_lump(292) > 8(29501) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: > free_lump(321) > 8(29501) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: > fix_nated_contact_f(204) > 8(29501) qm_free(0x80bf800, 0x80cbd10), called from data_lump.c: > free_lump_list(352) > 8(29501) qm_free: freeing frag. 0x80cbcf8 alloc'ed from data_lump.c: > insert_new_lump_after(111) > 8(29501) qm_free(0x80bf800, 0x80cbc1c), called from data_lump.c: > free_lump_list(357) > 8(29501) qm_free: freeing frag. 0x80cbc04 alloc'ed from data_lump.c: > del_lump(262) > 8(29501) qm_free(0x80bf800, 0x80cc358), called from data_lump_rpl.c: > free_lump_rpl(84) > 8(29501) qm_free: freeing frag. 0x80cc340 alloc'ed from > data_lump_rpl.c: build_lump_rpl(47) > 8(29501) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: > free_lump_rpl(85) > 8(29501) qm_free: freeing frag. 0x80c9cd8 alloc'ed from > data_lump_rpl.c: build_lump_rpl(40) > 8(29501) qm_free(0x80bf800, 0x80cb918), called from receive.c: > receive_msg(187) > 8(29501) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: > receive_msg(78) > 10(29527) qm_malloc(0x80bf800, 160) called from nathelper.c: timer(689) > 10(29527) qm_malloc(0x80bf800, 160) returns address 0x80cb918 frag. > 0x80cb900 (size=160) on 1 -th hit > 10(29527) qm_free(0x80bf800, 0x80cb918), called from nathelper.c: > timer(743) > 10(29527) qm_free: freeing frag. 0x80cb900 alloc'ed from nathelper.c: > timer(689) > 10(29527) qm_malloc(0x80bf800, 160) called from nathelper.c: timer(689) > 10(29527) qm_malloc(0x80bf800, 160) returns address 0x80cb918 frag. > 0x80cb900 (size=160) on 1 -th hit > 10(29527) qm_free(0x80bf800, 0x80cb918), called from nathelper.c: > timer(743) > 10(29527) qm_free: freeing frag. 0x80cb900 alloc'ed from nathelper.c: > timer(689) > > > > -----Original Message----- > From: Jan Janak [mailto:jan@iptel.org] > Sent: Tuesday, September 23, 2003 11:46 AM > To: Steve Dolloff > Cc: Serusers > Subject: Re: [Serusers] Troubles setting up radius authentication > > Looking at modification time of sterman.c I realized that your > sources are not recent enough. The file was last modified on September > 12 and you built your server on September 11, so please try to update > from the cvs, at least auth_radius module. > > Jan. > > On 23-09 11:39, Steve Dolloff wrote: > > This is my current info. > > > > ser -V > > version: ser 0.8.12dev-t16 (i386/linux) > > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ > > main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > > > this was built from source off of CVS. If there is a newer version > that > > would give more info, I will recompile. > > > > Stephen > > > > > > Hello, > > > > >From the information below I can't say where the problem is, but I > would > > say some attribute definitions are missing. > > > > Unfortunatelly the stable version of auth_radius module doesn't print > > much debugging messages when something goes wrong. > > > > Did you compile your server from sources or do you use binary packages > ? > > You can try unstable version branch from the CVS, that should tell you > > where the problem is, or I can send you a patch to stable version if > you > > can apply it and compile from sources. > > > > Jan. > > > > On 23-09 11:24, Steve Dolloff wrote: > > > Yes, I have added the SIP definitions to the radiusclient library. > It > > > is the dictionary file defined in the radiusclient.conf file as > > > /etc/sip_dictionary. It was created using the dictionary file from > > > radiusclient and adding the information from the link that you > refered > > > to. > > > > > > ----------------------- > > > > > > Hello, > > > > > > if there is no radius traffic then radiusclient library has some > > > problems when buiding the request. Did you extend your radius > > dictionary > > > as described in http://iptel.org/ser/ser_radius.html ? > > > > > > Jan. > > > > > > On 23-09 10:38, Steve Dolloff wrote: > > > > I am trying to switch from database authentication to radius > > > > authentication. > > > > > > > > I have compiled and installed the module. > > > > > > > > I have added the following to my ser.cfg > > > > > > > > modparam("auth_radius", "radius_config", > > "/etc/ser/radiusclient.conf") > > > > modparam("auth_radius", "service_type",15) > > > > > > > > if (method=="REGISTER") { > > > > log(1,"authenticating"); > > > > if > > (!radius_www_authorize("test.net")) > > > { > > > > log(1,"radius auth > > failure"); > > > > www_challenge("test.net", > > > "0"); > > > > break; > > > > }; > > > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > > authserver radius1.test.net:1812 > > > > authserver radius2.test.net:1812 > > > > servers /etc/servers > > > > dictionary /etc/sip_dictionary > > > > > > > > I have configured the following in /etc/servers > > > > > > > > Radius1.test.net secret > > > > Radius2.test.net secret2 > > > > > > > > I get the following in my messages log. > > > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > > request going? How can I get more debug info? > > > > > > > > Thanks for your help. > > > > > > > > Stephen > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers

2 1

[Serusers] test
by Jan Janak 23 Sep '03

23 Sep '03

ignore

1 0

[Serusers] Seruser - Radius authentication
by Steven R. Bunin 23 Sep '03

23 Sep '03

I am also using Ser with Radius and finally got the Radiusclient, Radius and Ser to all talk together. The only issue I have is that the radius server is not sending back what the radiusclient it looking for in order to tell Ser to authenticate the user (I hope that isn't too confusing). The lines affecting radius in my ser.cfg are modparam("auth_radius","radius_config","/usr/local/etc/radiusclient/radiusclient.conf") route{ log(1,"logging so message came in"); if (uri=~"solaas.com") { log(1,"sip_2 ip came through"); if (method=="REGISTER") { log(1,"register go through"); # Uncomment this if you want to use digest authentication if (!radius_www_authorize("")) { www_challenge("","0"); log(1,"request came in"); break; }; save("location"); break; }; } I can add my radiusclient.conf file if it will help you.. my users file for the radius server looks like this: xxxxxxxxxx(a)sip.server.com Auth-Type := Digest, User-Password == "1234" Reply-Message = "Authenticated" Hope that helps and also let me know if anyone sees anything wrong with my radius setup so I can finally authenticate. Steve > > Message: 1 > Date: Tue, 23 Sep 2003 11:24:11 -0500 > From: "Steve Dolloff" <sdolloff(a)noc.dls.net> > Subject: RE: [Serusers] Troubles setting up radius authentication > To: "Jan Janak" <jan(a)iptel.org> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: > <ADCFA6B7CA0C754EB837B423E5A521D2543512(a)mailbox.noc.dls.net> > Content-Type: text/plain; charset="us-ascii" > > Yes, I have added the SIP definitions to the radiusclient library. It > is the dictionary file defined in the radiusclient.conf file as > /etc/sip_dictionary. It was created using the dictionary file from > radiusclient and adding the information from the link that you refered > to. > > ----------------------- > > Hello, > > if there is no radius traffic then radiusclient library has some > problems when buiding the request. Did you extend your radius dictionary > as described in http://iptel.org/ser/ser_radius.html ? > > Jan. > > On 23-09 10:38, Steve Dolloff wrote: > > I am trying to switch from database authentication to radius > > authentication. > > > > I have compiled and installed the module. > > > > I have added the following to my ser.cfg > > > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > > modparam("auth_radius", "service_type",15) > > > > if (method=="REGISTER") { > > log(1,"authenticating"); > > if (!radius_www_authorize("test.net")) > { > > log(1,"radius auth failure"); > > www_challenge("test.net", > "0"); > > break; > > }; > > > > I have configured the following in /etc/ser/radiusclient.conf > > authserver radius1.test.net:1812 > > authserver radius2.test.net:1812 > > servers /etc/servers > > dictionary /etc/sip_dictionary > > > > I have configured the following in /etc/servers > > > > Radius1.test.net secret > > Radius2.test.net secret2 > > > > I get the following in my messages log. > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > request going? How can I get more debug info? > > > > Thanks for your help. > > > > Stephen > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > Message: 2 > Date: Tue, 23 Sep 2003 11:30:07 -0500 > From: "Steve Dolloff" <sdolloff(a)noc.dls.net> > Subject: RE: [Serusers] Troubles setting up radius authentication > To: "Jan Janak" <jan(a)iptel.org> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: > <ADCFA6B7CA0C754EB837B423E5A521D2543513(a)mailbox.noc.dls.net> > Content-Type: text/plain; charset="us-ascii" > > Here is a copy of the stderr if I run from console. > > 8(27147) qm_free(0x80bf800, 0x80cbc6c), called from parser/parse_via.c: > free_via_list(1973) > 8(27147) qm_free: freeing frag. 0x80cbc54 alloc'ed from > parser/msg_parser.c: get_hdr_field(109) > 8(27147) qm_free(0x80bf800, 0x80cbd10), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbcf8 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbc1c), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbc04 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbdb0), called from parser/parse_to.c: > free_to(778) > 8(27147) qm_free: freeing frag. 0x80cbd98 alloc'ed from > parser/msg_parser.c: get_hdr_field(149) > 8(27147) qm_free(0x80bf800, 0x80cbe04), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbdec alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbd60), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbd48 alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80c9da8), called from > parser/parse_cseq.c: free_cseq(102) > 8(27147) qm_free: freeing frag. 0x80c9d90 alloc'ed from > parser/msg_parser.c: get_hdr_field(128) > 8(27147) qm_free(0x80bf800, 0x80cbe54), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbe3c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cc0d8), called from > parser/parse_param.c: do_free_params(420) > 8(27147) qm_free: freeing frag. 0x80cc0c0 alloc'ed from > parser/parse_param.c: parse_params(337) > 8(27147) qm_free(0x80bf800, 0x80cc084), called from > parser/contact/contact.c: free_contacts(293) > 8(27147) qm_free: freeing frag. 0x80cc06c alloc'ed from > parser/contact/contact.c: parse_contacts(194) > 8(27147) qm_free(0x80bf800, 0x80ca3cc), called from > parser/contact/parse_contact.c: free_contact(109) > 8(27147) qm_free: freeing frag. 0x80ca3b4 alloc'ed from > parser/contact/parse_contact.c: parse_contact(81) > 8(27147) qm_free(0x80bf800, 0x80cbea4), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbe8c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbef4), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbedc alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbf44), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbf2c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80cbf94), called from parser/hf.c: > free_hdr_field_lst(170) > 8(27147) qm_free: freeing frag. 0x80cbf7c alloc'ed from > parser/msg_parser.c: parse_headers(276) > 8(27147) qm_free(0x80bf800, 0x80c8934), called from data_lump.c: > free_lump(321) > 8(27147) qm_free: freeing frag. 0x80c891c alloc'ed from mf_funcs.c: > add_maxfwd_header(131) > 8(27147) qm_free(0x80bf800, 0x80cbfe4), called from data_lump.c: > free_lump_list(346) > 8(27147) qm_free: freeing frag. 0x80cbfcc alloc'ed from data_lump.c: > insert_new_lump_before(136) > 8(27147) qm_free(0x80bf800, 0x80cc034), called from data_lump.c: > free_lump_list(357) > 8(27147) qm_free: freeing frag. 0x80cc01c alloc'ed from data_lump.c: > anchor_lump(292) > 8(27147) qm_free(0x80bf800, 0x80cc174), called from data_lump.c: > free_lump(321) > 8(27147) qm_free: freeing frag. 0x80cc15c alloc'ed from nathelper.c: > fix_nated_contact_f(204) > 8(27147) qm_free(0x80bf800, 0x80cc124), called from data_lump.c: > free_lump_list(352) > 8(27147) qm_free: freeing frag. 0x80cc10c alloc'ed from data_lump.c: > insert_new_lump_after(111) > 8(27147) qm_free(0x80bf800, 0x80cc1dc), called from data_lump.c: > free_lump_list(357) > 8(27147) qm_free: freeing frag. 0x80cc1c4 alloc'ed from data_lump.c: > del_lump(262) > 8(27147) qm_free(0x80bf800, 0x80cc35c), called from data_lump_rpl.c: > free_lump_rpl(84) > 8(27147) qm_free: freeing frag. 0x80cc344 alloc'ed from > data_lump_rpl.c: build_lump_rpl(47) > 8(27147) qm_free(0x80bf800, 0x80c9cf0), called from data_lump_rpl.c: > free_lump_rpl(85) > 8(27147) qm_free: freeing frag. 0x80c9cd8 alloc'ed from > data_lump_rpl.c: build_lump_rpl(40) > 8(27147) qm_free(0x80bf800, 0x80cb918), called from receive.c: > receive_msg(187) > 8(27147) qm_free: freeing frag. 0x80cb900 alloc'ed from receive.c: > receive_msg(78) > > -----Original Message----- > From: Jan Janak [mailto:jan@iptel.org] > Sent: Tuesday, September 23, 2003 10:45 AM > To: Steve Dolloff > Cc: Serusers > Subject: Re: [Serusers] Troubles setting up radius authentication > > Hello, > > if there is no radius traffic then radiusclient library has some > problems when buiding the request. Did you extend your radius dictionary > as described in http://iptel.org/ser/ser_radius.html ? > > Jan. > > On 23-09 10:38, Steve Dolloff wrote: > > I am trying to switch from database authentication to radius > > authentication. > > > > I have compiled and installed the module. > > > > I have added the following to my ser.cfg > > > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > > modparam("auth_radius", "service_type",15) > > > > if (method=="REGISTER") { > > log(1,"authenticating"); > > if (!radius_www_authorize("test.net")) > { > > log(1,"radius auth failure"); > > www_challenge("test.net", > "0"); > > break; > > }; > > > > I have configured the following in /etc/ser/radiusclient.conf > > authserver radius1.test.net:1812 > > authserver radius2.test.net:1812 > > servers /etc/servers > > dictionary /etc/sip_dictionary > > > > I have configured the following in /etc/servers > > > > Radius1.test.net secret > > Radius2.test.net secret2 > > > > I get the following in my messages log. > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > request going? How can I get more debug info? > > > > Thanks for your help. > > > > Stephen > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > Message: 3 > Date: Tue, 23 Sep 2003 18:30:35 +0200 > From: Jan Janak <jan(a)iptel.org> > Subject: Re: [Serusers] Troubles setting up radius authentication > To: Steve Dolloff <sdolloff(a)noc.dls.net> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: <20030923163035.GJ766(a)localhost.localdomain> > Content-Type: text/plain; charset=iso-8859-2 > > Hello, > > >From the information below I can't say where the problem is, but I would > say some attribute definitions are missing. > > Unfortunatelly the stable version of auth_radius module doesn't print > much debugging messages when something goes wrong. > > Did you compile your server from sources or do you use binary packages ? > You can try unstable version branch from the CVS, that should tell you > where the problem is, or I can send you a patch to stable version if you > can apply it and compile from sources. > > Jan. > > On 23-09 11:24, Steve Dolloff wrote: > > Yes, I have added the SIP definitions to the radiusclient library. It > > is the dictionary file defined in the radiusclient.conf file as > > /etc/sip_dictionary. It was created using the dictionary file from > > radiusclient and adding the information from the link that you refered > > to. > > > > ----------------------- > > > > Hello, > > > > if there is no radius traffic then radiusclient library has some > > problems when buiding the request. Did you extend your radius dictionary > > as described in http://iptel.org/ser/ser_radius.html ? > > > > Jan. > > > > On 23-09 10:38, Steve Dolloff wrote: > > > I am trying to switch from database authentication to radius > > > authentication. > > > > > > I have compiled and installed the module. > > > > > > I have added the following to my ser.cfg > > > > > > modparam("auth_radius", "radius_config", "/etc/ser/radiusclient.conf") > > > modparam("auth_radius", "service_type",15) > > > > > > if (method=="REGISTER") { > > > log(1,"authenticating"); > > > if (!radius_www_authorize("test.net")) > > { > > > log(1,"radius auth failure"); > > > www_challenge("test.net", > > "0"); > > > break; > > > }; > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > authserver radius1.test.net:1812 > > > authserver radius2.test.net:1812 > > > servers /etc/servers > > > dictionary /etc/sip_dictionary > > > > > > I have configured the following in /etc/servers > > > > > > Radius1.test.net secret > > > Radius2.test.net secret2 > > > > > > I get the following in my messages log. > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > request going? How can I get more debug info? > > > > > > Thanks for your help. > > > > > > Stephen > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > Message: 4 > Date: Tue, 23 Sep 2003 11:39:53 -0500 > From: "Steve Dolloff" <sdolloff(a)noc.dls.net> > Subject: RE: [Serusers] Troubles setting up radius authentication > To: "Jan Janak" <jan(a)iptel.org> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: > <ADCFA6B7CA0C754EB837B423E5A521D2543514(a)mailbox.noc.dls.net> > Content-Type: text/plain; charset="us-ascii" > > This is my current info. > > ser -V > version: ser 0.8.12dev-t16 (i386/linux) > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ > main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > this was built from source off of CVS. If there is a newer version that > would give more info, I will recompile. > > Stephen > > Hello, > > >From the information below I can't say where the problem is, but I would > say some attribute definitions are missing. > > Unfortunatelly the stable version of auth_radius module doesn't print > much debugging messages when something goes wrong. > > Did you compile your server from sources or do you use binary packages ? > You can try unstable version branch from the CVS, that should tell you > where the problem is, or I can send you a patch to stable version if you > can apply it and compile from sources. > > Jan. > > On 23-09 11:24, Steve Dolloff wrote: > > Yes, I have added the SIP definitions to the radiusclient library. It > > is the dictionary file defined in the radiusclient.conf file as > > /etc/sip_dictionary. It was created using the dictionary file from > > radiusclient and adding the information from the link that you refered > > to. > > > > ----------------------- > > > > Hello, > > > > if there is no radius traffic then radiusclient library has some > > problems when buiding the request. Did you extend your radius > dictionary > > as described in http://iptel.org/ser/ser_radius.html ? > > > > Jan. > > > > On 23-09 10:38, Steve Dolloff wrote: > > > I am trying to switch from database authentication to radius > > > authentication. > > > > > > I have compiled and installed the module. > > > > > > I have added the following to my ser.cfg > > > > > > modparam("auth_radius", "radius_config", > "/etc/ser/radiusclient.conf") > > > modparam("auth_radius", "service_type",15) > > > > > > if (method=="REGISTER") { > > > log(1,"authenticating"); > > > if > (!radius_www_authorize("test.net")) > > { > > > log(1,"radius auth > failure"); > > > www_challenge("test.net", > > "0"); > > > break; > > > }; > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > authserver radius1.test.net:1812 > > > authserver radius2.test.net:1812 > > > servers /etc/servers > > > dictionary /etc/sip_dictionary > > > > > > I have configured the following in /etc/servers > > > > > > Radius1.test.net secret > > > Radius2.test.net secret2 > > > > > > I get the following in my messages log. > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > request going? How can I get more debug info? > > > > > > Thanks for your help. > > > > > > Stephen > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > Message: 5 > Date: Tue, 23 Sep 2003 18:40:34 +0200 > From: Jan Janak <jan(a)iptel.org> > Subject: Re: [Serusers] Troubles setting up radius authentication > To: Steve Dolloff <sdolloff(a)noc.dls.net> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: <20030923164034.GK766(a)localhost.localdomain> > Content-Type: text/plain; charset=iso-8859-2 > > Hello, > > this should be recent enough. Try to look for messages like this: > > sterman(): Unable to add PW_DIGEST_REALM attribute > > (see sip_router/modules/auth_radius/sterman.c for more details). > > The file contains functions that build and send radius messages. > > Jan. > > On 23-09 11:39, Steve Dolloff wrote: > > This is my current info. > > > > ser -V > > version: ser 0.8.12dev-t16 (i386/linux) > > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ > > main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > > > this was built from source off of CVS. If there is a newer version that > > would give more info, I will recompile. > > > > Stephen > > > > > > Hello, > > > > >From the information below I can't say where the problem is, but I would > > say some attribute definitions are missing. > > > > Unfortunatelly the stable version of auth_radius module doesn't print > > much debugging messages when something goes wrong. > > > > Did you compile your server from sources or do you use binary packages ? > > You can try unstable version branch from the CVS, that should tell you > > where the problem is, or I can send you a patch to stable version if you > > can apply it and compile from sources. > > > > Jan. > > > > On 23-09 11:24, Steve Dolloff wrote: > > > Yes, I have added the SIP definitions to the radiusclient library. It > > > is the dictionary file defined in the radiusclient.conf file as > > > /etc/sip_dictionary. It was created using the dictionary file from > > > radiusclient and adding the information from the link that you refered > > > to. > > > > > > ----------------------- > > > > > > Hello, > > > > > > if there is no radius traffic then radiusclient library has some > > > problems when buiding the request. Did you extend your radius > > dictionary > > > as described in http://iptel.org/ser/ser_radius.html ? > > > > > > Jan. > > > > > > On 23-09 10:38, Steve Dolloff wrote: > > > > I am trying to switch from database authentication to radius > > > > authentication. > > > > > > > > I have compiled and installed the module. > > > > > > > > I have added the following to my ser.cfg > > > > > > > > modparam("auth_radius", "radius_config", > > "/etc/ser/radiusclient.conf") > > > > modparam("auth_radius", "service_type",15) > > > > > > > > if (method=="REGISTER") { > > > > log(1,"authenticating"); > > > > if > > (!radius_www_authorize("test.net")) > > > { > > > > log(1,"radius auth > > failure"); > > > > www_challenge("test.net", > > > "0"); > > > > break; > > > > }; > > > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > > authserver radius1.test.net:1812 > > > > authserver radius2.test.net:1812 > > > > servers /etc/servers > > > > dictionary /etc/sip_dictionary > > > > > > > > I have configured the following in /etc/servers > > > > > > > > Radius1.test.net secret > > > > Radius2.test.net secret2 > > > > > > > > I get the following in my messages log. > > > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > > request going? How can I get more debug info? > > > > > > > > Thanks for your help. > > > > > > > > Stephen > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > Message: 6 > Date: Tue, 23 Sep 2003 18:46:27 +0200 > From: Jan Janak <jan(a)iptel.org> > Subject: Re: [Serusers] Troubles setting up radius authentication > To: Steve Dolloff <sdolloff(a)noc.dls.net> > Cc: Serusers <serusers(a)lists.iptel.org> > Message-ID: <20030923164627.GL766(a)localhost.localdomain> > Content-Type: text/plain; charset=iso-8859-2 > > Looking at modification time of sterman.c I realized that your > sources are not recent enough. The file was last modified on September > 12 and you built your server on September 11, so please try to update > from the cvs, at least auth_radius module. > > Jan. > > On 23-09 11:39, Steve Dolloff wrote: > > This is my current info. > > > > ser -V > > version: ser 0.8.12dev-t16 (i386/linux) > > flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, > > SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > @(#) $Id: main.c,v 1.167 2003/07/07 14:08:26 jiri Exp $ > > main.c compiled on 10:02:36 Sep 11 2003 with gcc 3.2 > > > > this was built from source off of CVS. If there is a newer version that > > would give more info, I will recompile. > > > > Stephen > > > > > > Hello, > > > > >From the information below I can't say where the problem is, but I would > > say some attribute definitions are missing. > > > > Unfortunatelly the stable version of auth_radius module doesn't print > > much debugging messages when something goes wrong. > > > > Did you compile your server from sources or do you use binary packages ? > > You can try unstable version branch from the CVS, that should tell you > > where the problem is, or I can send you a patch to stable version if you > > can apply it and compile from sources. > > > > Jan. > > > > On 23-09 11:24, Steve Dolloff wrote: > > > Yes, I have added the SIP definitions to the radiusclient library. It > > > is the dictionary file defined in the radiusclient.conf file as > > > /etc/sip_dictionary. It was created using the dictionary file from > > > radiusclient and adding the information from the link that you refered > > > to. > > > > > > ----------------------- > > > > > > Hello, > > > > > > if there is no radius traffic then radiusclient library has some > > > problems when buiding the request. Did you extend your radius > > dictionary > > > as described in http://iptel.org/ser/ser_radius.html ? > > > > > > Jan. > > > > > > On 23-09 10:38, Steve Dolloff wrote: > > > > I am trying to switch from database authentication to radius > > > > authentication. > > > > > > > > I have compiled and installed the module. > > > > > > > > I have added the following to my ser.cfg > > > > > > > > modparam("auth_radius", "radius_config", > > "/etc/ser/radiusclient.conf") > > > > modparam("auth_radius", "service_type",15) > > > > > > > > if (method=="REGISTER") { > > > > log(1,"authenticating"); > > > > if > > (!radius_www_authorize("test.net")) > > > { > > > > log(1,"radius auth > > failure"); > > > > www_challenge("test.net", > > > "0"); > > > > break; > > > > }; > > > > > > > > I have configured the following in /etc/ser/radiusclient.conf > > > > authserver radius1.test.net:1812 > > > > authserver radius2.test.net:1812 > > > > servers /etc/servers > > > > dictionary /etc/sip_dictionary > > > > > > > > I have configured the following in /etc/servers > > > > > > > > Radius1.test.net secret > > > > Radius2.test.net secret2 > > > > > > > > I get the following in my messages log. > > > > > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:03 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25947]: radius auth failure > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: authenticating > > > > Sep 23 10:39:30 voip2 /usr/sbin/ser[25949]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25948]: radius auth failure > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: authenticating > > > > Sep 23 10:39:34 voip2 /usr/sbin/ser[25945]: radius auth failure > > > > > > > > And ngrep port 1812 shows no traffic at all. Where are these auth > > > > request going? How can I get more debug info? > > > > > > > > Thanks for your help. > > > > > > > > Stephen > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > ------------------------------ > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > End of Serusers Digest, Vol 5, Issue 50 > *************************************** -- Steven R. Bunin - Managing Partner SOLAAS LLC 10 East 39th Street Suite 1125 New York, NY 10016 (+001) 212-532-6700 Cellular: 646-739-7000 Fax (+001) 212-532-6776 http://www.solaas.com -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 9

← Newer
1
2
3
4
5
6
7
8
9
...
21
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users September 2003