[OpenSIPS-Users] [test] testing exim and mailman - IGNORE

[Bogdan-Andrei Iancu]

--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro


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

Re: [OpenSIPS-Users] OpenSIPS core dumps

[thrillerbee]

Bogdan,

It seems the issue is with 'opensipsctl fifo' - it's very sensitive to
simultaneous calls.  Basically, I've combined all my scripts to prevent
'opensipsctl fifo' from being called too frequently and that seems (so far)
to have mitigated the issue.  Is there anything one should know about how
(not) to use *opensipsctl*?

Thanks.

On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu
wrote:

> Hi,
>
> strange if you do not have any errors :(
>
> I just made a fix on both trunk and 1.6 to extend some checks in
> flatstore and prevent crashing (even if the DB op will not be executed).
>
> Could you update from SVN and see if stops crashing ?
>
> Regards,
> Bogdan
>
>
> thrillerbee wrote:
> > Bogdan,
> >
> > I am not seeing any other errors in the logs.  Is there anything else
> > I can look at?  Both proxies are crashing everyday.
> >
> > Thanks.
> >
> > On Wed, Nov 3, 2010 at 4:21 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>> wrote:
> >
> > I got some clue about what is happening - as you are using
> > flatstore for
> > acc, the acc module does not check the success of the "use_table" DB
> > operation - in 90% of the cases (for mysql, postgres, etc) this
> > function
> > cannot fail, but it seams that for flatstore can. And if it fails,
> the
> > h->tail is set to NULL, leading to crash.
> >
> > Now, before the crash itself, do you see any other ERROR messages
> > (even
> > long before the crash) related to flatstore module ? Try:
> >grep "ERROR" opensips_log_file | grep "flatstore"
> >
> > Regards,
> > Bogdan
> >
> > thrillerbee wrote:
> > > Bogdan,
> > >
> > > One more detail that may help - I added another OpenSIPS proxy in
> > > parallel with this one (& load balancing between the two) and
> > now both
> > > OpenSIPS proxies crash at the same time (within a couple seconds).
> > >
> > > I can provide more core dumps if it will help.
> > >
> > > Thanks.
> > >
> > >
> > > On Tue, Nov 2, 2010 at 9:02 AM, thrillerbee
> > mailto:thriller...@gmail.com>
> > > >>
> > wrote:
> > >
> > > Bogdan,
> > >
> > > Below is the info requested:
> > > (gdb) frame 0
> > > #0  0x7f51999f221f in flat_db_insert (h=0x7f0978,
> > > k=0x7f5198732a60, v=0x7f5198732d20, n=19) at flatstore.c:165
> > > 165 f = CON_FILE(h);
> > > (gdb) print h
> > > $1 = (const db_con_t *) 0x7f0978
> > > (gdb) print h->tail
> > > $2 = 0
> > > (gdb) print ((struct flat_con*)(h->tail))->file
> > > Cannot access memory at address 0x10
> > >
> > > Before each of the crashes yesterday, I saw these in the logs:
> > > Nov  1 14:17:40 core1 kernel: [4287745.452111] opensips[22141]:
> > > segfault at 10 ip 7f51999f221f sp 7fffbcd8d510 error 4 in
> > > db_flatstore.so[7f51999ef000+5000]
> > > Nov  1 23:52:58 core1 kernel: [4348562.990735] opensips[26978]:
> > > segfault at 10 ip 7f726cb9b21f sp 7083f6f0 error 4 in
> > > db_flatstore.so[7f726cb98000+5000]
> > >
> > > Are there any compiler flags I should use for debugging?
> > > (gdb) info locals
> > > f = 
> > > i = 
> > > l = 
> > > p = 
> > > __FUNCTION__ = "flat_db_insert"
> > >
> > > Thanks again.
> > >
> > >
> > > On Tue, Nov 2, 2010 at 4:18 AM, Bogdan-Andrei Iancu
> > > mailto:bog...@voice-system.ro>
> > >>
> > wrote:
> > >
> > > Hi,
> > >
> > > in frame 0, could you print:
> > >h
> > >h->tail
> > >((struct flat_con*)(h->tail))->file
> > >
> > > Also, before crash, do you see in the logs any errors
> > from the
> > > db_flatstore module ?
> > >
> > > Regards,
> > > Bogdan
> > >
> > > thrillerbee wrote:
> > > > Bogdan,
> > > >
> > > > It crashed again tonight.  I've attached the backtrace.
> > > >
> > > > Thanks.
> > > >
> > > > On Mon, Nov 1, 2010 at 9:32 AM, thrillerbee
> > > mailto:thriller...@gmail.com>
> > >
> > > >  > 
> > >  >  > > >
> > > > Bogdan,
> > > >
> > > > Yes,  I've attached 2 to my response - one was a
> crash
> > > from 10/29.
> > > >  The other occurred a few minutes ago.
> > > 

Re: [OpenSIPS-Users] about imc invite

[Schumann Sebastian]

Hi

Check whether it really sends this as text in the body of the message or if 
HTML is around. I had this problem some time ago using eyebeam and the reason 
was the the very first character was not '#' but '<' from the HTML opening tag.

Sebastian


From: users-boun...@lists.opensips.org [users-boun...@lists.opensips.org] On 
Behalf Of york liu [besti...@gmail.com]
Sent: Monday, November 01, 2010 10:18
To: users@lists.opensips.org
Subject: [OpenSIPS-Users] about imc invite

hi all

i was try to use imc module yestoday.everything work fine excluding invite 
function.

no matter sending #invite sip:j...@opensips.org 
sip:chat-...@opensips.org  or  #invite 
j...@opensips.org sent to 
sip:chat-...@opensips.org
to chat-manager.

so any sugestion to me?



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

Re: [OpenSIPS-Users] Register attack!

[Flavio Goncalves]

Hi Saul,

I did like your solution. My only concern about Pike was to block
legitimate traffic. A SIP dialer can easily get to the pike threshold,
but doing pike_check_req() just for register, options and bye requests
seems to avoid this.

The only "but" is,  the attack can also be done using INVITE and using
Pike with INVITE can make you drop legitimate traffic, my initial
concern. I think, that detecting authentication requests with wrong
passwords or inexistent users is still the most generic solution. Just
an opinion.

Best regards,

Flavio E. Goncalves
CEO - V.Office
OpenSIPS Bootcamp (New Jersey, NY  Nov. 15-19)




2010/11/3 Saúl Ibarra Corretgé :
> On 11/03/2010 04:00 PM, Hung Nguyen wrote:
>> Hi all, thanks for reply.
>>
>> I have tested with pike module. It is very simple.
>>
>> --
>> modparam("pike", "sampling_time_unit", 3)
>> modparam("pike", "reqs_density_per_unit", 20)
>>
>> if (method = 'REGISTER | OPTION | BYE') {
>>        if (!pike_check_req()) {
>>            #TODO: do anything if you want
>>            drop();
>>            exit;
>>        }
>> }
>> --
>>
>> I tested with sipvicious, about 5 second pike detect flood =>  drop
>> packet or send 200 OK for register (svcrash.py will stop).
>> You can be blook flooding with any method.
>>
>
> Take into account that with pike module you are dropping the packets at
> the application level, but they still enter the system. As the pike
> module also generates syslog messages, you may want to use them in
> combination with some other tool in order to block the traffic with
> iptables, for example.
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
> ___
> 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] memory cache: redis

[Mike O'Connor]

Hi Bogdan

Yes its new but has a lot of testing and seems to be very stable.

Its a memory cache with the possibility of a disk backend, I think it
could be used by the 'Dialog' and 'Usrloc' modules (and maybe more) as a
method of clustering OpenSIPS.

The disk cache means that a restart does not mean the loss of the data.

It can also be used  with complex data sets not just hash/value, one
feature which could be useful is atomic increments.

I really think it could be the thing which can make OpenSIPS full
cluster aware.

Cheers
Mike



On 4/11/10 7:25 PM, Bogdan-Andrei Iancu wrote:
> Hi Mike,
>
> That is completely new for me and checking on wikipedia, I see it is 
> really new stuff - initial release in 2009
>
> As I understand this is more suitable for a new caching backend (along 
> localcache and memcached), right ?
>
> Regards,
> Bogdan
>
> Mike O'Connor wrote:
>> Hi Guys
>>
>> Have the developers of OpenSIPS ever looked at 'redis' as an option for
>> consistency of data across a cluster ?
>>
>> It seems to me that it has a good number of advantages over memcache or
>> a mysql master/master system.
>>
>> It can store complex data, has a system of subscribing to messages (a
>> little like an irc channel), can be have data persistence and would seem
>> to do a master/slave very well.
>>
>> The 'subscribe' feature would be great for telling OpenSIPS servers with
>> in the cluster about changes in status.
>>
>> Its disadvantage at this time is that it does not have a master/master
>> capability and there is no support for multiply 'redis' masters.
>>
>> For your thoughts
>> Mike O'Connor
>>
>> ___
>> 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] b2bua core dump & db truncate

[thrillerbee]

Anca,

I am seeing a crash about every 13-14 days.  I've attached the backtrace
from this morning.
The other problem is that OpenSIPS immediately crashes when monit tries to
restart it. I have to manually truncate the b2b_entities & b2b_logic tables
to get it to start w/o crashing.  I'm attaching this backtrace as well
(called *restart*).

Thanks.

On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee  wrote:

> Anca,
>
> I had not altered the code.  It core dumped pretty quickly so I was force
> to revert to revision 7317.
> I will try to schedule some time to retest the newest revision and see if
> it core dumps again.
>
> Thanks again.
>
> On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu  wrote:
>
>>  Hi,
>>
>> The lines in your gdb backtrace don't match at all. Have you altered the
>> code or is the core corrupted?
>>
>>
>> Regards,
>>
>> --
>> Anca Vamanuwww.voice-system.ro
>>
>>
>>
>> On 11/01/2010 04:35 PM, thrillerbee wrote:
>>
>> Anca,
>>
>>  I am still seeing core dumps.  bt attached.
>>
>>  Thanks .
>>
>> On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee wrote:
>>
>>> Anca,
>>>
>>>  Thanks for the info.  I'll let you know if I have issues after the
>>> upgrade.
>>>
>>>  Thanks.
>>>
>>>
>>> On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu  wrote:
>>>
 Hi,

 At startup, the b2b_tables are copied into memory and are truncated,
 then the data is updated in the database at an interval controlled by
 the update_period parameter ( by default 100 seconds).

 As for the core dump, if you are using trunk, can you please update your
 code? I just committed a lot of changes in those modules.

 Regards,

 --
 Anca Vamanu
 www.voice-system.ro




 On 10/26/2010 06:58 AM, thrillerbee wrote:
 > I'm waiting for my b2bua box to core dump again so I can get the
 > backtrace, but is it expected behavior that OpenSIPS cannot restart
 > w/o first truncating the b2b_entities & b2b_logic tables?  That makes
 > for a messy recovery...
 >
 > Thanks.

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

>>>
>>>
>>
>> ___
>> Users mailing 
>> listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 12409]
#0  t_unref_cell (c=0x0) at t_lookup.c:1169
1169UNREF(c);
(gdb) bt full
#0  t_unref_cell (c=0x0) at t_lookup.c:1169
__FUNCTION__ = "t_unref_cell"
#1  0x7fe9774ec9e1 in b2b_prescript_f (msg=0x799e88, uparam=) at dlg.c:488
reason = {s = 0x7fe9774f58c0 "OK", len = 2}
b2b_key = {s = 0x799e88 "s len = 1}
dlg = 
hash_index = 
local_index = 
b2b_cback = 
param = {s = 0x0, len = 0}
table = 
method_value = 
TO = {error = 7741452, body = {s = 0xa , len 
= 0}, uri = {s = 0x7fe90006 "", len = 0}, display = {
s = 0x762066 "38794...@68.68.124.33>;tag=gK0b7076d4\r\nTo: 
;tag=B2B.2482.3343\r\nCall-ID: 
772517652_72287...@68.68.124.33\r\ncseq: 12225 PRACK\r\nMax-Forwards: 
68\r\nRAck: 113 12224 INVITE\r\nConte"..., len = 70}, tag_value = {s = 
0x56b00497f81 , len = 0}, parsed_uri = 
{user = {
  s = 0x761fac "121.80.39;branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;t"..., len = 98}, host = {s = 0x4d5ba9 
"H\211D$XH\205##\017#T$0D\213\\$(\017\204###", len = 59}, port = {
  s = 0x4cc929 "h\21...@h\205##\213t$\030l\213\\$\020\017\204###", len = 
7741335}, params = {s = 0x7fffc7331f78 "###", len = 7741337}, headers = {s = 
0x0, 
  len = 1963685894}, port_no = 27160, proto = 124, type = ERROR_URI_T, 
transport = {s = 0x76213e "", len = 7741341}, ttl = {
  s = 0x761fb6 "branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;t"..., len = 8005424}, user_param = {
  s = 0x761fc1 "4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP 
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP 
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom: 
;tag=gK0b7076"..., len = 7741724}, maddr = {s = 
0x3 , len = 4957221}, method = {s = 0x799e88 "s 
len = 510}, 
lr = {s = 0x7cb518 "\001", len = 7741341}, r2 = {s = 0x7c6a18 "\001", len = 
7741758}, transport_val = {
  s = 0x761f9d "SIP/2.0/UDP 
24.121.80.39;branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP

[OpenSIPS-Users] Dispatcher radius messages are not valid

[Maciej Bylica]

Hello,

I am working on opensips 1.6.3 $Revision: 4448 together with
media-dispatcher 2.4.3, media-relay 2.4.3, python 2.5.2-3, freeradius
2.1.8, radiusclient-ng 0.5.6
Freeradius should gather radius messages directly from opensips and
dispatcher. Both are installed on the same server and use the same
radiusclient.conf file.

The problem is that radius messages generated from dispatcher are not
taken into account while i have no problem with opensips radius
messages (secred for dispatcher and opensips is the same)
Here is an output from radius server

Waking up in 0.10 seconds.
Thread 9 got semaphore
Thread 9 handling request 121, (13 handled so far)
[] Received Accounting-Request packet from client 10.1.1.229
with invalid signature!  (Shared secret is incorrect.) Dropping packet
without response.

I've already tested freeradius-xs from debian pkg with same effect.
I am running 32bit os linux debian lenny.

Has anybody similiar problem. Could you guys pls point me what should i check?

Thx in advance,
Maciej

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