This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04..Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04..Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug: -------------------------------------
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs: ---------------------------------------------- rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
1. Check with Grandstream to see if your firmware is the latest/stable version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
2. If UA is behind NAT, please make sure that grandstream is configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug: -------------------------------------
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs: ---------------------------------------------- rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I think the reason why this is happening is a broken ADSL router or simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change the port on your sipserver to 5062 or something simular.. if you do that I bet it will work.
-Atle
* Alex Vishnev avishnev@optonline.net [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
- Check with Grandstream to see if your firmware is the latest/stable
version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
- If UA is behind NAT, please make sure that grandstream is configured for
NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs:
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Good observation! Grandstream (at least) firmware 10.5.16 has an error in symmetric NAT handling with STUN. GS should NOT try to replace IP:port with the public one, because it will be wrong. nat_uac_test("16") will catch this through checking the Contact port with the received port. g-)
Atle Samuelsen wrote:
I think the reason why this is happening is a broken ADSL router or simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change the port on your sipserver to 5062 or something simular.. if you do that I bet it will work.
-Atle
- Alex Vishnev avishnev@optonline.net [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
- Check with Grandstream to see if your firmware is the
latest/stable version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
- If UA is behind NAT, please make sure that grandstream is
configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs:
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks for the reply. it's something strange , because i use the same ser.cfg file on other server and the same ATA286 (which using stun) working perfect.
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04..Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1".... Ok i see there is the difference in ports where the register sending back . it's coming from port 26012 and the 401 Unauthorized sending back to port 22115 how i can fix it: if it possible to give complete example.
and what else i need to install in order to perform the fix.
thanks for any help.
On 4/16/05, Greger V. Teigre greger@teigre.com wrote:
Good observation! Grandstream (at least) firmware 10.5.16 has an error in symmetric NAT handling with STUN. GS should NOT try to replace IP:port with the public one, because it will be wrong. nat_uac_test("16") will catch this through checking the Contact port with the received port. g-)
Atle Samuelsen wrote:
I think the reason why this is happening is a broken ADSL router or simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change the port on your sipserver to 5062 or something simular.. if you do that I bet it will work.
-Atle
- Alex Vishnev avishnev@optonline.net [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
- Check with Grandstream to see if your firmware is the
latest/stable version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
- If UA is behind NAT, please make sure that grandstream is
configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs:
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
You tried the ATA286 behind the same NAT for both servers?
First, verify that the problem really is related to STUN: Turn off STUN in GS. Your ser.cfg should then detect that the GS is NATed and store the correct public IP:port as the user location. It it works, replace your nat_uac_test("3") tests with nat_uac_test("19") (adding the 16 test). You can see an example of this in the rtpproxy.cfg at http://onsip.org/ g-)
----- Original Message ----- From: "Alex" alexandergav@gmail.com To: "Greger V. Teigre" greger@teigre.com Cc: serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Sent: Sunday, April 17, 2005 08:41 AM Subject: Re: [Serusers] Can't solve the problem. Need help.
Thanks for the reply. it's something strange , because i use the same ser.cfg file on other server and the same ATA286 (which using stun) working perfect.
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04..Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1".... Ok i see there is the difference in ports where the register sending back . it's coming from port 26012 and the 401 Unauthorized sending back to port 22115 how i can fix it: if it possible to give complete example.
and what else i need to install in order to perform the fix.
thanks for any help.
On 4/16/05, Greger V. Teigre greger@teigre.com wrote:
Good observation! Grandstream (at least) firmware 10.5.16 has an error in symmetric NAT handling with STUN. GS should NOT try to replace IP:port with the public one, because it will be wrong. nat_uac_test("16") will catch this through checking the Contact port with the received port. g-)
Atle Samuelsen wrote:
I think the reason why this is happening is a broken ADSL router or simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change the port on your sipserver to 5062 or something simular.. if you do that I bet it will work.
-Atle
- Alex Vishnev avishnev@optonline.net [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
- Check with Grandstream to see if your firmware is the
latest/stable version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
- If UA is behind NAT, please make sure that grandstream is
configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs:
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD = 1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804 modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Alex,
First of all sending port and receiving port does not have to be the same. So it is ok if UAC sends out a message on port 26012 and receives on some other port. However, it is still unclear to me what is replacing the port numbers. What is more confusing is that you are now indicating that you tested the same device with 2 different servers, if I understood you correctly. It works with one of them, and does not work with another server. Is that correct? Assuming that exactly the same equipment is being used for both cases, I can only guess that there may be rules in the router/ALG that does something based on first address and not the second. I suggest capturing the local traffic with ethereal or similar tools to see what is actually originating out of your phones. Capture the output with both servers and then compare the results to see what is the difference.
Alex
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Greger V. Teigre Sent: Sunday, April 17, 2005 4:23 AM To: Alex Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Can't solve the problem. Need help.
You tried the ATA286 behind the same NAT for both servers?
First, verify that the problem really is related to STUN: Turn off STUN in GS. Your ser.cfg should then detect that the GS is NATed and store the correct public IP:port as the user location. It it works, replace your nat_uac_test("3") tests with nat_uac_test("19") (adding the 16 test). You can see an example of this in the rtpproxy.cfg at http://onsip.org/ g-)
----- Original Message ----- From: "Alex" alexandergav@gmail.com To: "Greger V. Teigre" greger@teigre.com Cc: serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Sent: Sunday, April 17, 2005 08:41 AM Subject: Re: [Serusers] Can't solve the problem. Need help.
Thanks for the reply. it's something strange , because i use the same ser.cfg file on other server and the same ATA286 (which using stun) working perfect.
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length: 0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To:
sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04. .Call-I
D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1".... Ok i see there is the difference in ports where the register sending back . it's coming from port 26012 and the 401 Unauthorized sending back to port 22115 how i can fix it: if it possible to give complete example.
and what else i need to install in order to perform the fix.
thanks for any help.
On 4/16/05, Greger V. Teigre greger@teigre.com wrote:
Good observation! Grandstream (at least) firmware 10.5.16 has an error in symmetric NAT handling with STUN. GS should NOT try to replace IP:port with the public one, because it will be wrong. nat_uac_test("16") will catch this through checking the Contact port with the received port. g-)
Atle Samuelsen wrote:
I think the reason why this is happening is a broken ADSL router or simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change the port on your sipserver to 5062 or something simular.. if you do that I bet it will work.
-Atle
- Alex Vishnev avishnev@optonline.net [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing your problem. Normally, when register is issued the Via header indicates where UAS/proxy should respond. In your first packet, here is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0.. Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115. Now, SER sends the response to that port, but it does not look like UA is listening there, as UA just re-originates REGISTER. The question I have is why do you have a strange port number, instead of 5060? So it looks to me the reason why you never getting another REGISTER with credentials is because 401 Unauthorized never makes it to your Grandstream UA.
So I would do the following:
- Check with Grandstream to see if your firmware is the
latest/stable version. I use Grandstream Bt100 and have not problems. I know grandstream is pretty good in resolving problems.
- If UA is behind NAT, please make sure that grandstream is
configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Alex Sent: Saturday, April 16, 2005 12:13 PM To: aland@ox.org; freeradius-users@lists.freeradius.org; serusers@lists.iptel.org; amack@fhm.edu; daniel@voice-system.ro Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list : The second REGISTER (the block 3) must contains the response to the authentication challenge carried by 401 reply (block 2). That means that the block 3 must contain an Authorization header with authentication credentials computed according to HTTP-Digest authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx; tag=94a44507e03df901..To:
sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
.Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4 46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21363 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
# U sourceip:26012 -> xxx.xxx.xxx.xxx:5060 REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To: sip:phonenumber@xxx.xxx.xxx.xxx..Contact: sip:phonenumber@sourceip:22115..Call-ID: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires: 3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F orwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0.... # U xxx.xxx.xxx.xxx:5060 -> sourceip:22115 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex " sip:phonenumber@xxx.xxx.xxx.xxx;tag=94a44507e03df901..To:
sip:phonenumber@xxx.xxx.xxx.xxx;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
.Call-I D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef 0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 " Noisy feedback tells: pid=21360 req_src_ip=sourceip req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
12(21360) SIP Request: 12(21360) method: <REGISTER> 12(21360) uri: sip:xxx.xxx.xxx.xxx 12(21360) version: <SIP/2.0> 12(21360) parse_headers: flags=1 12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>; state=16 12(21360) end of header reached, state=5 12(21360) parse_headers: Via found, flags=1 12(21360) parse_headers: this is the first via 12(21360) After parse_msg... 12(21360) preparing to run routing scripts... 12(21360) REGISTER message received 12(21360) REGISTER: Authenticating user 12(21360) parse_headers: flags=4 12(21360) end of header reached, state=9 12(21360) DEBUG: get_hdr_field: <To> [34]; uri=[sip:phonenumber@xxx.xxx.xxx.xxx] 12(21360) DEBUG: to body [sip:phonenumber@xxx.xxx.xxx.xxx ] 12(21360) parse_headers: flags=4096 12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER> 12(21360) DEBUG: get_hdr_body : content_length=0 12(21360) found end of header 12(21360) pre_auth(): Credentials with given realm not found 12(21360) REGISTER: challenging user 12(21360) build_auth_hf(): 'WWW-Authenticate: Digest realm="xxx.xxx.xxx.xxx", nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9" ' 12(21360) parse_headers: flags=-1 12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1) 12(21360) DEBUG:destroy_avp_list: destroing list (nil) 12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on the radius logs. it's looks like my granstream ATA286 not going through authectication process. when i change the ip of the sip server to different one (2-server) it's working perfect. The grandstream ATA286 sending same packets, on the 2 server it's working, on 1- one nothing happens. on the problematic server i have clean installation of freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the : radclient -f digest localhost auth testing123 Received response ID 134, code 2, length = 45 Reply-Message = "Hello, test with digest"
radius logs:
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134, length=140 User-Name = "test" Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7" Digest-Attributes = "\001\013testrealm" Digest-Attributes = "\002\n1234abcd" Digest-Attributes = "\003\010INVITE" Digest-Attributes = "\004\034sip:5555551212@example.com" Digest-Attributes = "\006\005MD5" Digest-Attributes = "\n\006test" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_digest: Converting Digest-Attributes to something sane... Digest-Realm = "testrealm" Digest-Nonce = "1234abcd" Digest-Method = "INVITE" Digest-URI = "sip:5555551212@example.com" Digest-Algorithm = "MD5" Digest-User-Name = "test" rlm_digest: Adding Auth-Type = DIGEST modcall[authorize]: module "digest" returns ok for request 0 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry test at line 215 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 A1 = test:testrealm:test A2 = INVITE:sip:5555551212@example.com KD =
1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804
modcall[authenticate]: module "digest" returns ok for request 0 modcall: group authenticate returns ok for request 0 radius_xlat: 'Hello, test with digest' Sending Access-Accept of id 134 to 127.0.0.1:32844 Reply-Message = "Hello, test with digest" Finished request 0
I need some help to figure out that's the problem with this server. And what can be a reason what i don't see any authentication process in the radius , when the packets coming from ATA286 to authenticate the the user.
Thanks for any help.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Alex -
Alex Vishnev -
Atle Samuelsen -
Greger V. Teigre