Thanks Bogdan.

I spent a lot of time yesterday to troubleshoot my own problem. Its much better now. Here is the latest.

I found out that the routing script has a section which was causing all this.

# check if user is suspended if(is_method("REGISTER|INVITE|MESSAGE|OPTIONS|SUBSCRIBE")) { if (radius_is_user_in("From", "suspended")) { sl_send_reply("403", "Forbidden - suspended"); exit; }; };

I confirmed that is_method function works fine but when the call hits radius_is_user_in, it does not go through and I see "credentials received are not properly filled in" on openser. When I commented out this and other radius_is_user_in and re-ran, all is well.

Any clue on whats missing here ?

I am thinking of creating a how-to doc on openser wiki after completing my tests.

Thanks, Neeraj Sun Microsystems

Bogdan-Andrei Iancu wrote:

Hi Neeraj,

The "pre_auth(): credentials received are not filled properly" is generated in multiple cases, like missing username/realm/nonce, etc. Check your register request to see if it has all the required info in the auth hdr.

Logs in debug=6 are also useful.

regards, bogdan

Neeraj Gupta wrote:

...

Hi,

I switched to OpenSER 1.2.1 last week, from ser 0.9.6. And this is first time I am trying to use FreeRADIUS 1.1.6 with OpenSER 1.2.1 I followed instructions on web based on 1.0.1 and made some changes by hand to adapt to 1.2.1 model. This was my reference: www.*openser*.org/docs/*openser*-radius-1.0.x.html

I can start OpenSER, no issues but I am not able to use SiPP UA. Openser does not respond back to UA (no incoming message in ethereal/wireshark). Openser reports that "pre_auth(): credentials received are not filled properly". I tried to comment out the avp sections in openser.cfg.. but Its not helping. Please see my logs and configs below. If someone can send me a working config file, I will be very thankful. If more info needed, let me know.

_*# openser -V*_ version: openser 1.2.1-tls (sparc64/solaris) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, select, /dev/poll. svnrevision: unknown @(#) $Id: main.c 1827 2007-03-12 15:22:53Z bogdan_iancu $ main.c compiled on 23:04:19 Jun 26 2007 with gcc 3.4.6

_*Radius users file*_

# from website examples ### --- avps --- 101@192.168.4.128 Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs" Sip-Avp += "#3#1", Sip-Avp += "#4:08:00", Sip-Avp += "#5:16:00", Sip-Avp += "#6:Mon,Wed,Thu,Fri"

102@192.168.4.128 Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs" Sip-Avp += "#3#1", Sip-Avp += "#4:08:00", Sip-Avp += "#5:16:00", Sip-Avp += "#6:Mon,Wed,Thu,Fri"

DEFAULT Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs"

### --- group checking --- ### --- user 101 --- 101@192.168.4.128 Auth-Type := Accept, Sip-Group == "voip", Service-Type == "Group-Check" Reply-Message = "Authorized"

101@192.168.4.128 Auth-Type := Accept, Sip-Group == "pstn", Service-Type == "Group-Check" Reply-Message = "Authorized"

### --- user 102 --- 102@192.168.4.128 Auth-Type := Accept, Sip-Group == "voip", Service-Type == "Group-Check" Reply-Message = "Authorized"

DEFAULT Auth-Type := Reject, Service-Type == "Group-Check"

### --- user authentication --- 101@192.168.4.128 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated", Sip-Avp += "rpid:101", Sip-Avp += "#2:192.168.4.101", Sip-Avp += "#2:192.168.4.100"

102@192.168.4.128 Auth-Type := Digest, User-Password == "102" Reply-Message = "Authenticated", Sip-Avp += "rpid:102", Sip-Avp += "#2:192.168.4.101"

# test user test Auth-Type := Digest, User-Password == "test" Reply-Message = "Hello, test with digest"

_*SiPP xml file:*_

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE scenario SYSTEM "sipp.dtd">

<scenario name="registration">

<send retrans="500"> <![CDATA[ REGISTER sip:192.168.4.128 SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 20 From: "[field1]" <sip:[field1]@[field0]>;tag=[call_number] To: "101" <sip:[field1]@[field0]> Call-ID: [call_id] CSeq: 1 REGISTER Contact: <sip:[field1]@[local_ip]:[local_port]> Expires: 1800 Content-Length: 0 User-Agent: Sipp/Ubuntu Authorization: Digest username="[field1]@[field0]", realm="[field0]" Supported: path ]]> </send>

<recv response="401" auth="true" rtd="true"> </recv>

<send retrans="500"> <![CDATA[ REGISTER sip:192.168.4.128 SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 20 From: "[field1]" <sip:[field1]@[field0]>;tag=[call_number] To: "101" <sip:[field1]@[field0]> Call-ID: [call_id] CSeq: 2 REGISTER Contact: <sip:[field1]@[local_ip]:[local_port]> Expires: 300 Content-Length: 0 User-Agent: Sipp/Ubuntu [authentication username=[field1]@[field0] password=[field2]] Supported: path ]]> </send>

<recv response="200"> </recv>

<ResponseTimeRepartition value="10, 20"/> <CallLengthRepartition value="10"/>

/scenario>

Thanks, Neeraj Gupta Sun Microsystems

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

No, there is no radius request generated under this scenario. But the problem goes away when I comment out the radius_is_user_in section.

I found another email thread on this same topic. http://osdir.com/ml/voip.openser.user/2005-10/msg00230.html But in my case, I dont see radius request in radiusd -X output.

-Neeraj

Bogdan-Andrei Iancu wrote:

Hi Neeraj,

that is quite odd as the "credentials received are not filled properly" is generated by the authentication API (auth module) and has nothing to do with radius_is_user_in().

when hitting radius_is_user_in(), does the process get blocked or it just go through without doing anything? Can you check with ngrep/tcpdump if any radius request is sent by radius_is_user_in()?

regards, bogdan

Neeraj Gupta wrote:

...

Thanks Bogdan.

I spent a lot of time yesterday to troubleshoot my own problem. Its much better now. Here is the latest.

I found out that the routing script has a section which was causing all this.

# check if user is suspended if(is_method("REGISTER|INVITE|MESSAGE|OPTIONS|SUBSCRIBE")) { if (radius_is_user_in("From", "suspended")) { sl_send_reply("403", "Forbidden - suspended"); exit; }; };

I confirmed that is_method function works fine but when the call hits radius_is_user_in, it does not go through and I see "credentials received are not properly filled in" on openser. When I commented out this and other radius_is_user_in and re-ran, all is well.

Any clue on whats missing here ?

I am thinking of creating a how-to doc on openser wiki after completing my tests.

Thanks, Neeraj Sun Microsystems

Bogdan-Andrei Iancu wrote:

...

Hi Neeraj,

The "pre_auth(): credentials received are not filled properly" is generated in multiple cases, like missing username/realm/nonce, etc. Check your register request to see if it has all the required info in the auth hdr.

Logs in debug=6 are also useful.

regards, bogdan

Neeraj Gupta wrote:

...

Hi,

I switched to OpenSER 1.2.1 last week, from ser 0.9.6. And this is first time I am trying to use FreeRADIUS 1.1.6 with OpenSER 1.2.1 I followed instructions on web based on 1.0.1 and made some changes by hand to adapt to 1.2.1 model. This was my reference: www.*openser*.org/docs/*openser*-radius-1.0.x.html

I can start OpenSER, no issues but I am not able to use SiPP UA. Openser does not respond back to UA (no incoming message in ethereal/wireshark). Openser reports that "pre_auth(): credentials received are not filled properly". I tried to comment out the avp sections in openser.cfg.. but Its not helping. Please see my logs and configs below. If someone can send me a working config file, I will be very thankful. If more info needed, let me know.

_*# openser -V*_ version: openser 1.2.1-tls (sparc64/solaris) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, select, /dev/poll. svnrevision: unknown @(#) $Id: main.c 1827 2007-03-12 15:22:53Z bogdan_iancu $ main.c compiled on 23:04:19 Jun 26 2007 with gcc 3.4.6

_*Radius users file*_

# from website examples ### --- avps --- 101@192.168.4.128 Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs" Sip-Avp += "#3#1", Sip-Avp += "#4:08:00", Sip-Avp += "#5:16:00", Sip-Avp += "#6:Mon,Wed,Thu,Fri"

102@192.168.4.128 Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs" Sip-Avp += "#3#1", Sip-Avp += "#4:08:00", Sip-Avp += "#5:16:00", Sip-Avp += "#6:Mon,Wed,Thu,Fri"

DEFAULT Auth-Type := Accept, Service-Type == "SIP-Callee-AVPs"

### --- group checking --- ### --- user 101 --- 101@192.168.4.128 Auth-Type := Accept, Sip-Group == "voip", Service-Type == "Group-Check" Reply-Message = "Authorized"

101@192.168.4.128 Auth-Type := Accept, Sip-Group == "pstn", Service-Type == "Group-Check" Reply-Message = "Authorized"

### --- user 102 --- 102@192.168.4.128 Auth-Type := Accept, Sip-Group == "voip", Service-Type == "Group-Check" Reply-Message = "Authorized"

DEFAULT Auth-Type := Reject, Service-Type == "Group-Check"

### --- user authentication --- 101@192.168.4.128 Auth-Type := Digest, User-Password == "101" Reply-Message = "Authenticated", Sip-Avp += "rpid:101", Sip-Avp += "#2:192.168.4.101", Sip-Avp += "#2:192.168.4.100"

102@192.168.4.128 Auth-Type := Digest, User-Password == "102" Reply-Message = "Authenticated", Sip-Avp += "rpid:102", Sip-Avp += "#2:192.168.4.101"

# test user test Auth-Type := Digest, User-Password == "test" Reply-Message = "Hello, test with digest"

_*SiPP xml file:*_

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE scenario SYSTEM "sipp.dtd">

<scenario name="registration">

<send retrans="500"> <![CDATA[ REGISTER sip:192.168.4.128 SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 20 From: "[field1]" <sip:[field1]@[field0]>;tag=[call_number] To: "101" <sip:[field1]@[field0]> Call-ID: [call_id] CSeq: 1 REGISTER Contact: <sip:[field1]@[local_ip]:[local_port]> Expires: 1800 Content-Length: 0 User-Agent: Sipp/Ubuntu Authorization: Digest username="[field1]@[field0]", realm="[field0]" Supported: path ]]> </send>

<recv response="401" auth="true" rtd="true"> </recv>

<send retrans="500"> <![CDATA[ REGISTER sip:192.168.4.128 SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] Max-Forwards: 20 From: "[field1]" <sip:[field1]@[field0]>;tag=[call_number] To: "101" <sip:[field1]@[field0]> Call-ID: [call_id] CSeq: 2 REGISTER Contact: <sip:[field1]@[local_ip]:[local_port]> Expires: 300 Content-Length: 0 User-Agent: Sipp/Ubuntu [authentication username=[field1]@[field0] password=[field2]] Supported: path ]]> </send>

<recv response="200"> </recv>

<ResponseTimeRepartition value="10, 20"/> <CallLengthRepartition value="10"/>

/scenario>

Thanks, Neeraj Gupta Sun Microsystems

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users