Re: [OpenSIPS-Users] dispatcher problem

2012-02-03 Thread Vlad Paiu

Hi Matt,

If you want good distribution, why don't you use instead the round-robin 
or the random dispatcher algorithms?


[1] http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id293072

Regards,

--
Vlad Paiu
OpenSIPS Developer
http://opensips-solutions.org/


Pe 2/3/2012 2:59 AM, Matt Hamilton a scris:

Hi Ra(zvan,

I don't assign any weights, and I use the dispatcher.list file:
1 sip:x.x.x.11:5060
1 sip:x.x.x.12:5060
1 sip:x.x.x.13:5060


When there are only 2 servers in that file, I always get:
DBG:dispatcher:ds_select_dst: alg hash [1], id [1] and dispatcher selects the 
2nd entry.

When there are 3 servers - when the dispatcher distributes to all 3 
servers, I get



DBG:dispatcher:ds_select_dst: alg hash [0], id [0]  before it 
dispatches to server1 (x.x.x.11)

DBG:dispatcher:ds_select_dst: alg hash [1], id [1] for x.x.x.12
DBG:dispatcher:ds_select_dst: alg hash [2], id [2] for x.x.x.13



Anyway I did some more tests, and it turns out that the hash algorithm 
is very sensitive to the PV.


1. when the input hash_pvar is from this set (my original set that 
gave me problems): 061002  061003  061005  061006  61007  
061008

Dispatcher splits them:
Server1: 0
server2: 6

2. if I add a 1 in front of my hash PV - so that the new values are 
1061002, etc.  (indentation mark is part of the string)

Server1: 2
Server2: 4

3. If I add another character, so that PVs look like x1061002
Server1: 3
Server2: 3

3-3 or 2-4 split is OK of course, but the 0-6 split threw me off. Is 
there a safe PV (integers, certain combinations, etc.) that I can 
use that will give me the best distribution? I can use a lookup table 
(like dialplan) to get those.


Thanks,
Matt









Date: Fri, 3 Feb 2012 00:36:37 +0200
From: razvancrai...@opensips.org
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dispatcher problem

Hi, Matt!

So for different hashed strings like:
DBG:dispatcher:ds_hash_pvar: Hashing 061002!
you always get the same output:
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]

Also, are you assigning different weights for any of the Asterisk?

Regards,
--
Ra(zvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/


On 02/03/2012 12:16 AM, Matt Hamilton wrote:

Hi Ra(zvan,

Yes, I'm using the same hashing values - the values I assign to the PV are 
also
passed to the ds_select_dst correctly as far as I can see. Here is a typical
debug output:

DBG:dispatcher:ds_hash_pvar: Hashing 061002!
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
DBG:dispatcher:ds_select_dst: selected [7-1/1]sip:x.x.x.13:5060
DBG:dispatcher:ds_select_dst: using entry [1/0]


I ran some test with 3 Asterisk servers with interesting results:

With 3 Asterisk servers specified in dispatcher.list, here is the 
distribution:

Server1: 061003
Server2: 061002, 061007, 061008
Server3: 061005, 061006

With only Server1 and Server2 specified in dispatcher.list:

Server1:
Server2: 061002, 061003, 061005, 061006, 61007, 061008


Likewise, with Server1 and Server3, Server3 gets everything.
   with Server2 and Server3, Server3 gets everything.

Is there anything I can do to fix this (somehow trick the function assuming 
the way I do is the correct way)?

Thanks,
Matt









Date: Thu, 2 Feb 2012 22:51:46 +0200
From: razvancrai...@opensips.org mailto:razvancrai...@opensips.org
To: users@lists.opensips.org mailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dispatcher problem

Hi, Matt!

Are you sure you are not using the same hashing value all the time?
If yes, can you increase your debugging level to 6 and provide
more information? I would be looking in the opensips log for lines
that contain the following strings: ds_hash_pvar: Hashing  and
ds_select_dst: alg hash .

Regards,

-- 
Ra(zvan Crainea

OpenSIPS Developer
http://opensips-solutions.org/



On 02/02/2012 10:15 PM, Matt Hamilton wrote:

Hi,

I'm using Opensips to dispatch to 2 servers - serverA,
serverB. When one of the servers is down, Opensips is
dispatching to the active one correctly. However, when both of
them are Active, it's picking only one of them and ignoring
the other; e.g.,

when serverB is down, dispatches to serverA
when serverA is down, dispatches to serverB
when both up, dispatches to serverB
while dispatching to serverA when serverB is down, if I
activate serverB, all requests dispatched to serverB


Here is my code:

modparam(dispatcher, hash_pvar, $avp(75))


in the script, I'm setting $avp(75) to one of the following
061002, 061003, 061004, 061005, 061006 just before
calling ds_select_dst.


[OpenSIPS-Users] Query on external source ( execel or DB )

2012-02-03 Thread spady
Hi folk,
I need to know if with OpenSIPS i am able to have the following scenario:

INITIAL SCENARIO:

Incoming external call goes into SIP PBX , this one routes call toward
another SIP PBX.

WANTED SCENARIO:

Incoming external call goes into SIP PBX,this one routes call toward
OpeSIPS ( OpenSIPS have to check into outside source, for example a execl
file or access file if calling number is present. If true It has to modify
TO: header in a certain manner; if false, it has to modify TO Header with
another way ). After modification, OpenSIPS routes call into final SIP
PBX.

Is that passible? I know OpenSIPS can easly modify Sip headers but what I
don't know is if OpenSIPS can use a execl or acces external file as source
to get the condition ( true or false ).

Thanks


--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250453.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Query on external source ( execel or DB )

2012-02-03 Thread Vlad Paiu

Hello,

Can't you use a regular database, instead of an excel or acces file ?
If not, you can use the exec [1]  module to execute an external script 
that processes info from your files, or even write a perl app that you 
can call via the perl [2] module.


[1] http://www.opensips.org/html/docs/modules/devel/exec.html
[2] http://www.opensips.org/html/docs/modules/devel/perl.html

Regards,

--
Vlad Paiu
OpenSIPS Developer
http://opensips-solutions.org/



Pe 2/3/2012 1:28 PM, spady a scris:

Hi folk,
I need to know if with OpenSIPS i am able to have the following scenario:

INITIAL SCENARIO:

Incoming external call goes into SIP PBX , this one routes call toward
another SIP PBX.

WANTED SCENARIO:

Incoming external call goes into SIP PBX,this one routes call toward
OpeSIPS ( OpenSIPS have to check into outside source, for example a execl
file or access file if calling number is present. If true It has to modify
TO: header in a certain manner; if false, it has to modify TO Header with
another way ). After modification, OpenSIPS routes call into final SIP
PBX.

Is that passible? I know OpenSIPS can easly modify Sip headers but what I
don't know is if OpenSIPS can use a execl or acces external file as source
to get the condition ( true or false ).

Thanks


--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250453.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Query on external source ( execel or DB )

2012-02-03 Thread spady
Thanks Vlad for your reply.
Query has to be done into AS400's db. I think is not a standard db. So I
thought about excel or access file ( I can export data from AS400 ).
If there is not another solution, I will have a try as you suggested me.
Thnaks a lot.


--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Query-on-external-source-execel-or-DB-tp7250453p7250764.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] dispatcher problem

2012-02-03 Thread Matt Hamilton

Hi Vlad,

We have many locations with 5-10 phones each. We use applications that require 
us to keep track of device states continuously for each location. We would 
prefer to have each location handled by the same Asterisk server both for 
incoming and outbound calls including registrations and subscriptions. It's 
more scalable and cleaner this way. If that server goes down, the whole 
location traffic as a whole moves to the next available server. That's why I 
need more control over dispatching.

Anyway, instead of using 061002, 061003, 061005, 061006, 061007, 
061008, if I use 1, 2, 3, 4, 5, 6, I get a much reasonable 
distribution (at least for 6 locations I use for testing). For 50+ locations, 
the results might be different of course.

Thanks,
Matt




Date: Fri, 3 Feb 2012 12:50:25 +0200
From: vladp...@opensips.org
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] dispatcher problem


  



  
  
Hi Matt,



If you want good distribution, why don't you use instead the
round-robin or the random dispatcher algorithms? 



[1] http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id293072



Regards,

-- 
Vlad Paiu
OpenSIPS Developer
http://opensips-solutions.org/


Pe 2/3/2012 2:59 AM, Matt Hamilton a scris:

  
  
Hi Răzvan,

I don't assign any weights, and I use the dispatcher.list file:

1 sip:x.x.x.11:5060

1 sip:x.x.x.12:5060

1 sip:x.x.x.13:5060





  When there are only 2 servers in that file, I always get:


DBG:dispatcher:ds_select_dst: alg hash [1], id [1] and dispatcher 
selects the 2nd entry.


When there are 3 servers - when the dispatcher distributes to
all 3 servers, I get





DBG:dispatcher:ds_select_dst:
  alg hash [0], id [0] 
  before it dispatches to server1 (x.x.x.11)

DBG:dispatcher:ds_select_dst: alg hash [1], id [1] for x.x.x.12
DBG:dispatcher:ds_select_dst: alg
  hash [2], id [2] for x.x.x.13







Anyway I did some more tests, and it turns out that the hash
algorithm is very sensitive to the PV. 



1. when the input hash_pvar is from this set (my original set
that gave me problems): 061002  061003  061005  061006 
61007  061008

Dispatcher splits them:

Server1: 0

server2: 6



2. if I add a 1 in front of my hash PV - so that the new values
are 1061002, etc.  (indentation mark is part of the string)

Server1: 2

Server2: 4



3. If I add another character, so that PVs look like x1061002

Server1: 3

Server2: 3



3-3 or 2-4 split is OK of course, but the 0-6 split threw me
off. Is there a safe PV (integers, certain combinations, etc.)
that I can use that will give me the best distribution? I can
use a lookup table (like dialplan) to get those.



Thanks,

Matt


















  Date: Fri, 3 Feb 2012 00:36:37 +0200

  From: razvancrai...@opensips.org

  To: users@lists.opensips.org

  Subject: Re: [OpenSIPS-Users] dispatcher problem

  

  
  
  Hi, Matt!

  

  So for different hashed strings like:

  DBG:dispatcher:ds_hash_pvar: Hashing 061002!
  you always get the same output:

  DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
  

  Also, are you assigning different weights for any of the
  Asterisk?

  

  Regards,

  -- 
Răzvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/
  

  

  On 02/03/2012 12:16 AM, Matt Hamilton wrote:
  


  Hi Răzvan,

Yes, I'm using the same hashing values - the values I assign to the PV are also 
passed to the ds_select_dst correctly as far as I can see. Here is a typical
debug output:

DBG:dispatcher:ds_hash_pvar: Hashing 061002!
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
DBG:dispatcher:ds_select_dst: selected [7-1/1] sip:x.x.x.13:5060
DBG:dispatcher:ds_select_dst: using entry [1/0]


I ran some test with 3 Asterisk servers with interesting results:

With 3 Asterisk servers specified in dispatcher.list, here is the distribution:

Server1: 061003
Server2: 061002, 061007, 061008
Server3: 061005, 061006

With only Server1 and Server2 specified in dispatcher.list:

Server1: 
Server2: 061002, 061003, 061005, 061006, 61007, 061008


Likewise, with Server1 and Server3, Server3 gets everything.
  with Server2 and Server3, Server3 gets everything.

Is there anything I can do to fix this (somehow trick the function assuming the 
way I do is the correct 

[OpenSIPS-Users] Problems compiling OpenSIPS 1.7 on OpenBSD 5.0 (error: expected specifier-qualifier-list, etc)

2012-02-03 Thread Taisto Qvist

Hi Folks,

I am trying to compile OpenSIPS 1.7(latest svn src) on OpenBSD 5.0,
but I stumble fairly quickly on the below errors.

Anyone who can explain what simple things I've messed up?

Any help appreciated!

Regards
Taisto Qvist
IP-Solutions.se

*[root@sip] /usr/source/opensips_1_7 # gmake*
Compiling evi/evi_core.c
In file included from evi/evi_transport.h:30,
 from evi/event_interface.h:29,
 from evi/evi_modules.h:30,
 from evi/evi_core.c:26:
/usr/include/sys/socket.h:166: error: expected specifier-qualifier-list before 
'u_int8_t'
/usr/include/sys/socket.h:184: error: expected specifier-qualifier-list before 
'u_int8_t'
/usr/include/sys/socket.h:254: error: expected specifier-qualifier-list before 
'uid_t'
/usr/include/sys/socket.h:400: error: expected specifier-qualifier-list before 
'socklen_t'
/usr/include/sys/socket.h:426: error: expected specifier-qualifier-list before 
'socklen_t'

/usr/include/sys/socket.h:482: error: expected specifier-qualifier-list before 
'caddr_t'
In file included from evi/evi_transport.h:30,
 from evi/event_interface.h:29,
 from evi/evi_modules.h:30,
 from evi/evi_core.c:26:
/usr/include/sys/socket.h:497: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:498: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:499: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 
'uid_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers or '...' before 
'gid_t'
/usr/include/sys/socket.h:501: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:502: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:503: error: expected declaration specifiers or '...' before 
'socklen_t'
/usr/include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recv'
/usr/include/sys/socket.h:506: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvfrom'
/usr/include/sys/socket.h:507: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvmsg'
/usr/include/sys/socket.h:508: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'send'
/usr/include/sys/socket.h:509: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendto'
/usr/include/sys/socket.h:511: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendmsg'
/usr/include/sys/socket.h:512: error: expected declaration specifiers or '...' before 
'socklen_t'

In file included from evi/evi_transport.h:33,
 from evi/event_interface.h:29,
 from evi/evi_modules.h:30,
 from evi/evi_core.c:26:
evi/../ip_addr.h: In function 'sockaddr2ip_addr':
evi/../ip_addr.h:220: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'su_cmp':
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:251: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'su_getport':
evi/../ip_addr.h:275: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'su_setport':
evi/../ip_addr.h:291: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'su2ip_addr':
evi/../ip_addr.h:308: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'init_su':
evi/../ip_addr.h:338: error: 'struct sockaddr' has no member named 'sa_family'
evi/../ip_addr.h: In function 'hostent2su':
evi/../ip_addr.h:375: error: 'struct sockaddr' has no member named 'sa_family'
In file included from evi/../fastlock.h:54,
 from evi/../lock_ops.h:70,
 from evi/../locking.h:67,
 from evi/event_interface.h:31,
 from evi/evi_modules.h:30,
 from evi/evi_core.c:26:

Re: [OpenSIPS-Users] Problems compiling OpenSIPS 1.7 on OpenBSD 5.0 (error: expected specifier-qualifier-list, etc)

2012-02-03 Thread Razvan Crainea

Hi, Taisto!

It is a fix that was not ported to 1.7 until now. I have just backported it.
Please update your svn sources and let me know if this doens't solve 
your problem.


Regards,

--
Răzvan Crainea
OpenSIPS Developer
http://opensips-solutions.org/



On 02/03/2012 05:24 PM, Taisto Qvist wrote:

Hi Folks,

I am trying to compile OpenSIPS 1.7(latest svn src) on OpenBSD 5.0,
but I stumble fairly quickly on the below errors.

Anyone who can explain what simple things I've messed up?

Any help appreciated!

Regards
Taisto Qvist
IP-Solutions.se

*[root@sip] /usr/source/opensips_1_7 # gmake*
Compiling evi/evi_core.c
In file included from evi/evi_transport.h:30,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
/usr/include/sys/socket.h:166: error: expected 
specifier-qualifier-list before 'u_int8_t'
/usr/include/sys/socket.h:184: error: expected 
specifier-qualifier-list before 'u_int8_t'
/usr/include/sys/socket.h:254: error: expected 
specifier-qualifier-list before 'uid_t'
/usr/include/sys/socket.h:400: error: expected 
specifier-qualifier-list before 'socklen_t'
/usr/include/sys/socket.h:426: error: expected 
specifier-qualifier-list before 'socklen_t'
/usr/include/sys/socket.h:482: error: expected 
specifier-qualifier-list before 'caddr_t'

In file included from evi/evi_transport.h:30,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
/usr/include/sys/socket.h:497: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:498: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:499: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers 
or '...' before 'uid_t'
/usr/include/sys/socket.h:500: error: expected declaration specifiers 
or '...' before 'gid_t'
/usr/include/sys/socket.h:501: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:502: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:503: error: expected declaration specifiers 
or '...' before 'socklen_t'
/usr/include/sys/socket.h:505: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recv'
/usr/include/sys/socket.h:506: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvfrom'
/usr/include/sys/socket.h:507: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'recvmsg'
/usr/include/sys/socket.h:508: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'send'
/usr/include/sys/socket.h:509: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendto'
/usr/include/sys/socket.h:511: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'sendmsg'
/usr/include/sys/socket.h:512: error: expected declaration specifiers 
or '...' before 'socklen_t'

In file included from evi/evi_transport.h:33,
from evi/event_interface.h:29,
from evi/evi_modules.h:30,
from evi/evi_core.c:26:
evi/../ip_addr.h: In function 'sockaddr2ip_addr':
evi/../ip_addr.h:220: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:234: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_cmp':
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:250: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:251: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:261: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_getport':
evi/../ip_addr.h:275: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:283: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su_setport':
evi/../ip_addr.h:291: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:301: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'su2ip_addr':
evi/../ip_addr.h:308: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 
'sa_family'
evi/../ip_addr.h:322: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'init_su':
evi/../ip_addr.h:338: error: 'struct sockaddr' has no member named 
'sa_family'

evi/../ip_addr.h: In function 'hostent2su':
evi/../ip_addr.h:375: error: 'struct sockaddr' has no member named 
'sa_family'

In file included from evi/../fastlock.h:54,
from evi/../lock_ops.h:70,
from evi/../locking.h:67,
from 

Re: [OpenSIPS-Users] check_source_address not working with upgrade

2012-02-03 Thread Duane Larson
Răzvan has fixed this issue with the latest trunk.  I have tested and all
is good now.

Thanks Razvan and Ovidiu.




On Thu, Feb 2, 2012 at 1:03 PM, duane.lar...@gmail.com wrote:

 I talked a little with Ovidiu offline so I went ahead and opened a bug
 ticket.


 Ticket is
 3483337 check_source_address broken in latest trunk Open 2012-02-02 nobody
 duanelarson123 None 5

 Thanks for the help Ovidiu.





 On , Duane Larson duane.lar...@gmail.com wrote:
  Yeah.  It is the first one in the list (Number 15 in the dump).  Like I
 said this worked before I upgraded.
 
  On Thu, Feb 2, 2012 at 10:56 AM, Ovidiu Sas o...@voipembedded.com
 wrote:
 
  The subnet is empty because you don't have any subnets (the mask is
 
  set to 32 and therefore you have full IP matching).  Is the message
 
  source IP in the address_dump?
 
 
 
  Regards,
 
  Ovidiu Sas
 
 
 
  --
 
  VoIP Embedded, Inc.
 
  http://www.voipembedded.com
 
 
 
 
  On Thu, Feb 2, 2012 at 11:52 AM, Duane Larson duane.lar...@gmail.com
 wrote:
 
   This is what I see
 
  
 
   Proxy01:/var/log# opensipsctl fifo address_dump
 
 15
 
 20
 
 34
 
 50
 
 63
 
 85
 
   Proxy01:/var/log#
 
   Proxy01:/var/log#
 
   Proxy01:/var/log#
 
   Proxy01:/var/log#
 
   Proxy01:/var/log# opensipsctl fifo subnet_dump
 
  
 
  
 
   So the subnet_dump is empty.
 
  
 
  
 
  
 
  
 
   On Thu, Feb 2, 2012 at 10:48 AM, Ovidiu Sas o...@voipembedded.com
 wrote:
 
  
 
   Check the in memory cache:
 
  
 http://www.opensips.org/html/docs/modules/devel/permissions.html#id293903
 
   See address_dump and subnet_dump.
 
  
 
   At start up, opensips will cache everything in memory.
 
  
 
   Regards,
 
   Ovidiu Sas
 
  
 
   --
 
   VoIP Embedded, Inc.
 
   http://www.voipembedded.com
 
  
 
  
 
   On Thu, Feb 2, 2012 at 11:38 AM,  duane.lar...@gmail.com wrote:
 
I just upgraded my b2bua opensips server to the latest trunk
 version and
 
now
 
my if statements using check_source_address from the permissions
 
module
 
isn't working. I have the following set up
 
   
 
loadmodule permissions.so
 
   
 
   
 modparam(permissions,db_url,mysql://adfasdf:dfasdf...@108.xxx.xxx.xxx
 /opensips)
 
   
 
   
 
if (check_source_address(2) || check_source_address(3) ||
 
check_source_address(4)) {
 
   
 
The INVITE comes from my SIP Proxy and worked before the upgrade
 without
 
issue
 
   
 
   
 
   
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:check_src_addr_3: Looking for :
5060,
 
1 in tables
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:hash_match: specified group does not exist in hash
 table
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:match_subnet_table: subnet table is empty
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:check_src_addr_3: Looking for :
5060,
 
1 in tables
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:hash_match: specified group does not exist in hash
 table
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:match_subnet_table: subnet table is empty
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:check_src_addr_3: Looking for :
5060,
 
1 in tables
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:hash_match: specified group does not exist in hash
 table
 
Feb 1 22:41:01 proxy01 /usr/local/sbin/opensips[30163]:
 
DBG:permissions:match_subnet_table: subnet table is empty
 
   
 
   
 
   
 
   
 
This is what I have in the database
 
Proxy01:/var/log# opensipsctl db show address
 
   
 
   
 +-+-++--+--+---+-+--+
 
| id | grp | ip | mask | port | proto | pattern | context_info |
 
   
 
   
 +-+-++--+--+---+-+--+
 
| 3 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL |
 
| 258 | 4 | 64.XXX.XXX.15 | 32 | 5060 | any | NULL | NULL |
 
| 1 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
 
| 2 | 10 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
 
| 257 | 3 | 173.XXX.XXX.XXX | 32 | 5060 | any | NULL | NULL |
 
| 4 | 2 | 216.XXX.XXX.202 | 32 | 5060 | any | NULL | NULL |
 
   
 
   
 +-+-++--+--+---+-+--+
 
   
 
   
 
   
 
I am not sure if OpenSIPS is really querying the mysql database
 because
 
I
 
don't really see any connections from the server when a call is
 made.
 
How
 
could this be possible? When I start OpenSIPS I see that it talks
 to the
 
database.
 
___
 
Users mailing list
 
Users@lists.opensips.org
 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
   
 
  
 

[OpenSIPS-Users] route all parking related calls to one FS server

2012-02-03 Thread Vik Killa
Hi, I have opensips running nicely, followed this tutorial:
http://wiki.freeswitch.org/wiki/OpenSIPS_configuration_for_2_or_more_FreeSWITCH_installs

Problems happen when using call parking. Because a call can be parked
on any FS server, you can't know where to pick up the parked call. A
simple solution would be to direct all parking related calls to a
single FS server. I've been able to direct parking calls to single FS
server by matching $ru to parking extension and then setting $rd to
the single FS server but it does not work when you transfer a call to
that FS server. Could anyone tell me how to REFER calls to the correct
parking server? I'd be happy to provide SIP traces if needed, thanks.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] SIP Authentication Attacks

2012-02-03 Thread James Lamanna
Hi,
I know the phones are not on public IPs.
Here is a opensips log of an attacker successfully registering
(hashes have been scrubbed)


Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_newtran: transaction on entrance=(nil)
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:parse_headers: flags=
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:parse_headers: flags=78
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction
matching
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: no transaction found
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id
0 entered
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_nonce: comparing
[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and
[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b]
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:has_stmt_ctx: ctx found for subscriber
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728)
MC=0x7ee3b0
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement
run
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254;
is_null=0
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1
columns in result
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_allocate_columns: allocate 28 bytes for result columns at
0x7f55a8
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password]
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_allocate_rows: allocate 48 bytes for result rows and
values at 0x7fa080
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_str2val: converting STRING []
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: our result = 7f340e'
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: their response = '.7f340e,
algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires:
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: authorization is OK
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:post_auth: nonce index= 3171
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_columns: freeing result columns at 0x7f55a8
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_rows: freeing 1 rows
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_row: freeing row values at 0x7fa090
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_rows: freeing rows at 0x7fa080
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_result: freeing result set at 0x7f2200
Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth
attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1

-- James

On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote:
 James,


 We have found with out users that some of them put the phones on public
 IP’s. If the default password is not changed, no matter how hard the
 password is they will get in. Also try using characters like “@:^#” in your
 passwords.


 Regards,



 Dovid



 

 From: users-boun...@lists.opensips.org
 [mailto:users-boun...@lists.opensips.org] On Behalf Of aws j
 Sent: Thursday, February 02, 2012 06:08
 To: OpenSIPS users mailling list
 Subject: Re: [OpenSIPS-Users] SIP Authentication Attacks



 Dear Mr James
 Can you attached to me your suspect file to make VoIP forensic on it .
 thanks
 Aws
 Msc VoIP security

 2012/2/1 James Lamanna jlama...@gmail.com

 Hi,
 I've noticed lately that a server of mine is getting repeatedly hit by
 an attacker trying 

Re: [OpenSIPS-Users] SIP Authentication Attacks

2012-02-03 Thread duane . larson
What does your whole REGISTER route look like? Maybe you are missing  
something in there and it is allowing someone to register even thought the  
password is wrong.




On , James Lamanna jlama...@gmail.com wrote:

Hi,



I know the phones are not on public IPs.



Here is a opensips log of an attacker successfully registering



(hashes have been scrubbed)







Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:tm:t_newtran: transaction on entrance=(nil)



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:parse_headers: flags=



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:parse_headers: flags=78



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction



matching



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:tm:t_lookup_request: no transaction found



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id



0 entered



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth:check_nonce: comparing



[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and



[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b]



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:has_stmt_ctx: ctx found for subscriber



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728)



MC=0x7ee3b0



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement



run



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254;



is_null=0



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1



columns in result



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_allocate_columns: allocate 28 bytes for result columns at



0x7f55a8



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password]



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_allocate_rows: allocate 48 bytes for result rows and



values at 0x7fa080



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:db_mysql:db_mysql_str2val: converting STRING []



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth:check_response: our result = 7f340e'



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth:check_response: their response = '.7f340e,



algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires:



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth:check_response: authorization is OK



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:auth:post_auth: nonce index= 3171



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_free_columns: freeing result columns at 0x7f55a8



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_free_rows: freeing 1 rows



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_free_row: freeing row values at 0x7fa090



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_free_rows: freeing rows at 0x7fa080



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:



DBG:core:db_free_result: freeing result set at 0x7f2200



Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth



attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1





-- James





On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote:



 James,











 We have found with out users that some of them put the phones on public



 IP's. If the default password is not changed, no matter how hard the


 password is they will get in. Also try using characters like “@:^#” in  
your



 passwords.











 Regards,















 Dovid















 







 From: 

Re: [OpenSIPS-Users] Trying to get Snom Contact List to work with OpenSIPS RLS

2012-02-03 Thread osiris123d
My main.c file has the following at the top
 
/*
 * $Id: main.c 8506 2011-10-21 10:21:10Z vladut-paiu $



So do you think there is any point to installing the latest trunk version
and seeing if it works or do you think the bug will still be in the latest
version?  Should I open a ticket on sourceforge?

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Trying-to-get-Snom-Contact-List-to-work-with-OpenSIPS-RLS-tp7228906p7252536.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] SIP Authentication Attacks

2012-02-03 Thread dotnetdub
On 3 February 2012 22:41, duane.lar...@gmail.com wrote:

 What does your whole REGISTER route look like? Maybe you are missing
 something in there and it is allowing someone to register even thought the
 password is wrong.



Definitely an issue with your script. Somewhere in there you are rejecting
credentials but carrying on anyway...










 On , James Lamanna jlama...@gmail.com wrote:
  Hi,
 
  I know the phones are not on public IPs.
 
  Here is a opensips log of an attacker successfully registering
 
  (hashes have been scrubbed)
 
 
 
 
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_newtran: transaction on entrance=(nil)
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:parse_headers: flags=
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:parse_headers: flags=78
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction
 
  matching
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: no transaction found
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id
 
  0 entered
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_nonce: comparing
 
  [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and
 
  [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b]
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:has_stmt_ctx: ctx found for subscriber
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728)
 
  MC=0x7ee3b0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement
 
  run
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254;
 
  is_null=0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1
 
  columns in result
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_allocate_columns: allocate 28 bytes for result columns at
 
  0x7f55a8
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password]
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_allocate_rows: allocate 48 bytes for result rows and
 
  values at 0x7fa080
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_str2val: converting STRING []
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: our result = 7f340e'
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: their response = '.7f340e,
 
  algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires:
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: authorization is OK
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:post_auth: nonce index= 3171
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_columns: freeing result columns at 0x7f55a8
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_rows: freeing 1 rows
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_row: freeing row values at 0x7fa090
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_rows: freeing rows at 0x7fa080
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_result: freeing result set at 0x7f2200
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth
 
  attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1
 
 
 
  -- James
 
 
 
  On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote:
 
   James,
 
  
 
  
 
   We have found with out users that some of 

Re: [OpenSIPS-Users] SIP Authentication Attacks

2012-02-03 Thread James Lamanna
Why do you say the credentials are wrong?
I guess I'm missing something from the log...?
www_authorize is returning 1

Here's the register handling:

 if (!t_newtran()) {
xlog(L_ERR, Could not make new transation REGISTER - M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
sl_reply_error();
exit;
}

$var(auth_code) = www_authorize(asterisk, subscriber);
xlog(L_INFO,Auth attempt for $fU@$fd from $si on port $Rp ret
$var(auth_code));
if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) {
xlog(L_INFO,Auth error for $fU@$fd from $si cause $var(auth_code));
}

if ( $var(auth_code)  0 ) {
www_challenge(asterisk, 0);
exit;
}

-- James


On Fri, Feb 3, 2012 at 3:23 PM, dotnetdub dotnet...@gmail.com wrote:


 On 3 February 2012 22:41, duane.lar...@gmail.com wrote:

 What does your whole REGISTER route look like? Maybe you are missing
 something in there and it is allowing someone to register even thought the
 password is wrong.






 Definitely an issue with your script. Somewhere in there you are rejecting
 credentials but carrying on anyway...










 On , James Lamanna jlama...@gmail.com wrote:
  Hi,
 
  I know the phones are not on public IPs.
 
  Here is a opensips log of an attacker successfully registering
 
  (hashes have been scrubbed)
 
 
 
 
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_newtran: transaction on entrance=(nil)
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:parse_headers: flags=
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:parse_headers: flags=78
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction
 
  matching
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:t_lookup_request: no transaction found
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id
 
  0 entered
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_nonce: comparing
 
  [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and
 
  [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b]
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:has_stmt_ctx: ctx found for subscriber
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728)
 
  MC=0x7ee3b0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement
 
  run
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254;
 
  is_null=0
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1
 
  columns in result
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_allocate_columns: allocate 28 bytes for result columns at
 
  0x7f55a8
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password]
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_allocate_rows: allocate 48 bytes for result rows and
 
  values at 0x7fa080
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:db_mysql:db_mysql_str2val: converting STRING []
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: our result = 7f340e'
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: their response = '.7f340e,
 
  algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires:
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:check_response: authorization is OK
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:auth:post_auth: nonce index= 3171
 
  Feb  3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
 
  DBG:core:db_free_columns: freeing result