Cant help without config (did u do record_route() before relying INVITE?)
________________________________
From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Ramin Nikaeen Sent: Thursday, March 09, 2006 2:17 PM To: Serusers Subject: [Serusers] loose_route's bug?
Hi Everyone,
I am really stuck here. I really need help!
I receive the following ACK request in SER from a Linksys/PAP user agent
that SER should forward to the destination User Agent: 2010000002.
ACK sip:2010000002@10.1.10.65:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport
From: 2224440133 sip:2224440133@host.domain.com;tag=692c5bafde7b5655o0
To: sip:2224449999@host.domain.com;tag=3b968d2d
Call-ID: c813c237-8673e16d@172.16.15.51
CSeq: 101 ACK
Max-Forwards: 70
Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr, sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr
Contact: 2224440133 sip:2224440133@172.16.15.51:5060
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
But SER's loose_route incorrectly modifies this ACK as follows:
ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060
From: 2224440133 sip:2224440133@host.domain.com;tag=692c5bafde7b5655o0
To: sip:2224449999@host.domain.com;tag=3b968d2d
Call-ID: c813c237-8673e16d@172.16.15.51
CSeq: 101 ACK
Max-Forwards: 16
Route:
Contact: 2224440133 sip:2224440133@172.16.15.51:5060
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
Which causes the ACK to keep looping through SER:
ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060
From: 2224440133 sip:2224440133@host.domain.com;tag=692c5bafde7b5655o0
To: sip:2224449999@host.domain.com;tag=3b968d2d
Call-ID: c813c237-8673e16d@172.16.15.51
CSeq: 101 ACK
Max-Forwards: 15
Route:
Contact: 2224440133 sip:2224440133@172.16.15.51:5060
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
ACK sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr SIP/2.0
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Record-Route: sip:10.1.10.65;ftag=692c5bafde7b5655o0;lr=on
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5fb5b16;rport=5060
From: 2224440133 sip:2224440133@host.domain.com;tag=692c5bafde7b5655o0
To: sip:2224449999@host.domain.com;tag=3b968d2d
Call-ID: c813c237-8673e16d@172.16.15.51
CSeq: 101 ACK
Max-Forwards: 14
Route:
Contact: 2224440133 sip:2224440133@172.16.15.51:5060
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
I am really stuck.
Can anyone tell me what is happening?!
Thanks
ramin
I'm facing some really weird problem. Let's try to explain, but first my config (basically):
OpenSUSE 10.0 FreeRadius 1.0.4-4 RadiusClient-NG 0.5.2 SER 0.9.6 MySQL 5.0.18
THE GOALs: upgrade from SER 0.8.4 to 0.9.6; MySQL from 4.0 to 5.0.
THE SCENE: FreeRadius, using MySQL as back-end, as SER. SER configured to consult Radius and make account on both places (Radius and MySQL). I have this same configuration running and OK, but on an old version of SER (0.8.4) + MySQL 4.0 + RadiusClient-NG 0.5.0. MySQL is running OK and responding to all queries, as expected.
THE PROBLEM: with the upgrade the RadiusClient-NG is reporting that the digest (MD5) returned by the Radius server isn't correct. If I tweak the code of sendserver.c (radiusclient-ng-0.5.2/lib/sendserver.c) to compile it with DEBUG displays, it shows me that different digests. One that comes from FreeRadius and another calculated.
So now I stuck... I can not go on with the upgrade 'til I find a solution to this issue. Not using Radius is not a possibility.
Did anybody cross this problem and find a solution?
Edson.
Do you have the same shared secret configured in the client library and server ?
Jan.
Edson wrote:
I'm facing some really weird problem. Let's try to explain, but first my config (basically):
OpenSUSE 10.0 FreeRadius 1.0.4-4 RadiusClient-NG 0.5.2 SER 0.9.6 MySQL 5.0.18
THE GOALs: upgrade from SER 0.8.4 to 0.9.6; MySQL from 4.0 to 5.0.
THE SCENE: FreeRadius, using MySQL as back-end, as SER. SER configured to consult Radius and make account on both places (Radius and MySQL). I have this same configuration running and OK, but on an old version of SER (0.8.4)
- MySQL 4.0 + RadiusClient-NG 0.5.0. MySQL is running OK and responding to
all queries, as expected.
THE PROBLEM: with the upgrade the RadiusClient-NG is reporting that the digest (MD5) returned by the Radius server isn't correct. If I tweak the code of sendserver.c (radiusclient-ng-0.5.2/lib/sendserver.c) to compile it with DEBUG displays, it shows me that different digests. One that comes from FreeRadius and another calculated.
So now I stuck... I can not go on with the upgrade 'til I find a solution to this issue. Not using Radius is not a possibility.
Did anybody cross this problem and find a solution?
Edson.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Yes. I, included, after finding this thread http://lists.cistron.nl/pipermail/freeradius-users/2003-February/015851.html , changed the password to something very simple/stupid one ("aaa" in this case). See below the relevants parts of the config and files...
Edson.
===================================================== /etc/raddb/radius.conf: ... client 127.0.0.1 { secret = aaa shortname = localhost nastype = other } ...
===================================================== /etc/radiuscliente-ng/servers: localhost aaa
===================================================== Diff from what I applied on "sendserver.c": 23a24,25
#define DIGEST_DEBUG 1
404a407,410
#ifdef DIGEST_DEBUG unsigned char *ptr=NULL; #endif
445c451 < rc_log(LOG_ERR, " %s", buf); ---
rc_log(LOG_ERR, " %s\n [%s]", buf,secret);
===================================================== The output on /var/log/messages: tail -n 0 -f /var/log/messages Mar 9 23:23:13 sip ser[20132]: Calculating digest on: Mar 9 23:23:13 sip ser[20132]: 025A002371F7F4A7B1705852E4373463E3D54E5B120F41757468656E74696361 [aaa] Mar 9 23:23:13 sip ser[20132]: 746564616161 [aaa] Mar 9 23:23:13 sip ser[20132]: Digest is: Mar 9 23:23:13 sip ser[20132]: BCE8E8A1E492F1D113363703A29DB10A Mar 9 23:23:13 sip ser[20132]: rc_check_reply: received invalid reply digest from RADIUS server
===================================================== The output from "radiusd -sfxxyz -l stdout": ... Exec-Program output: Exec-Program: returned: 0 radius_xlat: 'Authenticated' Login OK: [8201@208.48.149.39] (from client localhost port 3134307025) ...
===================================================== The output from "ser -TDdd": ... 0(20132) check_nonce(): comparing [4410e43c01d90d951a81556b5efe46e179c00764] and [4410e43c01d90d951a81556b5efe46e179c00764] reply_digest: 8a c7 33 ab 82 3f 86 88 83 38 ea 9f 9e e2 a8 71 calc_digest: bc e8 e8 a1 e4 92 f1 d1 13 36 37 03 a2 9d b1 0a 0(20132) res: -2 0(20132) radius_authorize_sterman(): Failure ...
=====================================================
-----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: quinta-feira, 9 de março de 2006 19:36 To: Edson Cc: serusers@lists.iptel.org Subject: Re: [Serusers] FreeRadius MD5 Problem
Do you have the same shared secret configured in the client library and server ?
Jan.
Edson wrote:
I'm facing some really weird problem. Let's try to explain, but first my config (basically):
OpenSUSE 10.0 FreeRadius 1.0.4-4 RadiusClient-NG 0.5.2 SER 0.9.6 MySQL 5.0.18
THE GOALs: upgrade from SER 0.8.4 to 0.9.6; MySQL from 4.0 to 5.0.
THE SCENE: FreeRadius, using MySQL as back-end, as SER. SER configured
to
consult Radius and make account on both places (Radius and MySQL). I
have
this same configuration running and OK, but on an old version of SER
(0.8.4)
- MySQL 4.0 + RadiusClient-NG 0.5.0. MySQL is running OK and responding
to
all queries, as expected.
THE PROBLEM: with the upgrade the RadiusClient-NG is reporting that the digest (MD5) returned by the Radius server isn't correct. If I tweak the code of sendserver.c (radiusclient-ng-0.5.2/lib/sendserver.c) to compile
it
with DEBUG displays, it shows me that different digests. One that comes
from
FreeRadius and another calculated.
So now I stuck... I can not go on with the upgrade 'til I find a
solution to
this issue. Not using Radius is not a possibility.
Did anybody cross this problem and find a solution?
Edson.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I had exactly the same problem with SER 0.9.6 and radiusclient-ng 0.5.2 on FreeBSD/Sparc64. I read all the problem reports I found on Google - they all led to the suggestion that my shared secrets between radiusclient and FreeRadius mismatch. However, I double- checked the entries - I also set them to some very simple values, all to no avail.
So I cloned the Sparc64 setup to an i386 machine using the exact same releases of FreeBSD, SER and radiusclient-ng. I scp'ed all the config files from the Spacr box to the i386...
and presto, it works like a charm. So maybe it really is a problem with calculation of MD5 on 64bit architectures.
cheers Heimo
(sorry, I don't know how to debug the source myself, but if I can be of any help leading to a fix, please let me know!)
Am 09.03.2006 um 23:36 schrieb Jan Janak:
Do you have the same shared secret configured in the client library and server ?
Jan.
Edson wrote:
I'm facing some really weird problem. Let's try to explain, but first my config (basically):
OpenSUSE 10.0 FreeRadius 1.0.4-4 RadiusClient-NG 0.5.2 SER 0.9.6 MySQL 5.0.18
THE GOALs: upgrade from SER 0.8.4 to 0.9.6; MySQL from 4.0 to 5.0.
THE SCENE: FreeRadius, using MySQL as back-end, as SER. SER configured to consult Radius and make account on both places (Radius and MySQL). I have this same configuration running and OK, but on an old version of SER (0.8.4)
- MySQL 4.0 + RadiusClient-NG 0.5.0. MySQL is running OK and
responding to all queries, as expected.
THE PROBLEM: with the upgrade the RadiusClient-NG is reporting that the digest (MD5) returned by the Radius server isn't correct. If I tweak the code of sendserver.c (radiusclient-ng-0.5.2/lib/sendserver.c) to compile it with DEBUG displays, it shows me that different digests. One that comes from FreeRadius and another calculated.
So now I stuck... I can not go on with the upgrade 'til I find a solution to this issue. Not using Radius is not a possibility.
Did anybody cross this problem and find a solution?
Edson.
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
From I have seen in my lab mediaproxy (1.42) seems not working with udptl
streams. Isn't It?
I am not a deep expert in streaming analisys so should a mediaproxy developer answare my queston?
My configuration is UA(nat)-----SER-----PSTN gateway supporting t.38.
Regards Rosario
-
Edson -
Heimo Hetl -
Jan Janak -
Rosario Pingaro -
Vitaly Nikolaev