[Serusers] Can't solve the problem. Need help.
Greger V. Teigre
greger at teigre.com
Sun Apr 17 10:22:37 CEST 2005
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 at gmail.com>
To: "Greger V. Teigre" <greger at teigre.com>
Cc: <serusers at lists.iptel.org>; <amack at fhm.edu>; <daniel at 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 at xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
> <sip:phonenumber at xxx.xxx.xxx.xxx>..Contact:
> <sip:phonenumber at sourceip:22115>..Call-ID:
> c9f64c0c2ef27cd1 at 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 at xxx.xxx.xxx.xxx>;
> tag=94a44507e03df901..To:
> <sip:phonenumber at xxx.xxx.xxx.xxx>;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04..Call-I
> D: c9f64c0c2ef27cd1 at 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 at 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 at 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:
>> >>
>> >> 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 at iptel.org [mailto:serusers-bounces at lists.iptel.org]
>> >> On Behalf Of Alex
>> >> Sent: Saturday, April 16, 2005 12:13 PM
>> >> To: aland at ox.org; freeradius-users at lists.freeradius.org;
>> >> serusers at lists.iptel.org; amack at fhm.edu; daniel at 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 at xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
>> >> <sip:phonenumber at xxx.xxx.xxx.xxx>..Contact:
>> >> <sip:phonenumber at sourceip:22115>..Call-ID:
>> >> c9f64c0c2ef27cd1 at 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 at xxx.xxx.xxx.xxx>;
>> >> tag=94a44507e03df901..To:
>> >> <sip:phonenumber at xxx.xxx.xxx.xxx>;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
>> >> .Call-I
>> >> D: c9f64c0c2ef27cd1 at 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 at xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
>> >> <sip:phonenumber at xxx.xxx.xxx.xxx>..Contact:
>> >> <sip:phonenumber at sourceip:22115>..Call-ID:
>> >> c9f64c0c2ef27cd1 at 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 at xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
>> >> <sip:phonenumber at xxx.xxx.xxx.xxx>;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
>> >> .Call-I
>> >> D: c9f64c0c2ef27cd1 at 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 at xxx.xxx.xxx.xxx]
>> >> 12(21360) DEBUG: to body [<sip:phonenumber at 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 at 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 at 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 at 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 at lists.iptel.org
>> >> http://lists.iptel.org/mailman/listinfo/serusers
>> >>
>> >>
>> >> _______________________________________________
>> >> Serusers mailing list
>> >> serusers at lists.iptel.org
>> >> http://lists.iptel.org/mailman/listinfo/serusers
>> >>
>> >
>> > _______________________________________________
>> > Serusers mailing list
>> > serusers at lists.iptel.org
>> > http://lists.iptel.org/mailman/listinfo/serusers
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
More information about the sr-users
mailing list