[asterisk-bugs] [Asterisk 0016382]: SIP OPTIONS qualify message forever
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Feb 16 10:56:34 CST 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16382
======================================================================
Reported By: lftsy
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 16382
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: SVN
JIRA: SWP-478
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-12-03 10:04 CST
Last Modified: 2010-02-16 10:56 CST
======================================================================
Summary: SIP OPTIONS qualify message forever
Description:
Hello, I have a trouble with different Asterisk versions (1.4.26, 1.4.27,
1.4.27.1). When I use the steps below, Asterisk starts to send SIP OPTIONS
to the previous IP/port used by a SIP realtime peer (that has been pruned)
and will keep trying to send SIP OPTIONS pings forever, event if the peer
is connected with a new IP/port address.
I have just checked with my old Asterisk 1.2.27 with the same sip.conf and
I do not have the problem, the SIP OPTIONS stops once register timer has
expired.
During my experience to reproduce the bug, I have been able to have 10
IP/port currently pinged by the Asterisk server for one single peer.
And the only way to stop it is to restart Asterisk...
Thank you for your attention!
Marc Leurent
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
duplicate of 0016764 Sip Channels Colapse
related to 0015716 [patch] chan_sip fails to destroy chann...
related to 0015627 [patch] Asterisk runs out of sockets
======================================================================
----------------------------------------------------------------------
(0118102) zerohalo (reporter) - 2010-02-16 10:56
https://issues.asterisk.org/view.php?id=16382#c118102
----------------------------------------------------------------------
@iftsy - the behavior was observed on 1.4.20rc2, nor 30. As soon as I can
capture it again, I will post.
In the meantime, I just had another 1.4.29 DoS of one of our peers.
Relevant BT thread and 'core show locks' below - the rest of the backtrace
is uninteresting. This caused an immediate mysql starvation and OPTIONS DoS
of around 4MB traffic. Attached is the munin graph showing the mysql
throughput.
=======================================================================
=== Currently Held Locks ==============================================
=======================================================================
===
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: -1208628320 (do_devstate_changes started at [ 363]
devicestate.c ast_device_state_engine_init())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (res_config_mysql.c):
MUTEX 115 realtime_mysql
&mysql_lock 0x973600 (1)
=== -------------------------------------------------------------------
===
=== Thread ID: 8866720 (do_monitor started at [17064] chan_sip.c
restart_monitor())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (chan_sip.c): MUTEX
17010 do_monitor &monlock 0xa662c0
(1)
=== -------------------------------------------------------------------
===
=======================================================================
Thread 42 (process 19188):
https://issues.asterisk.org/view.php?id=0 0x0810a99c in schedule
(con=0x9c248f0, s=0xb0ccda00) at sched.c:179
https://issues.asterisk.org/view.php?id=1 0x0810ac30 in ast_sched_add_variable
(con=0x9c248f0, when=1000,
callback=0x9faf60 <retrans_pkt>, data=0xaed39280, variable=1) at
sched.c:231
https://issues.asterisk.org/view.php?id=2 0x009fc770 in __sip_reliable_xmit
(p=0xaed37a00, seqno=102, resp=0,
data=0x8730bc "OPTIONS sip:99.246.179.162 SIP/2.0\r\nVia: SIP/2.0/UDP
70.XX.XX.XX:5060;branch=z9hG4bK28204ebb;rport\r\nFrom: \"unknown\"
<sip:unknown at 70.XX.XX.XX>;tag=as58a737ba\r\nTo:
<sip:99.XX.XX.XX>\r\nContact: <sip:"..., len=495, fatal=1, sipmethod=3) at
chan_sip.c:2130
https://issues.asterisk.org/view.php?id=3 0x009fe435 in send_request
(p=0xaed37a00, req=0x872ea0,
reliable=XMIT_CRITICAL, seqno=102) at chan_sip.c:2428
https://issues.asterisk.org/view.php?id=4 0x00a1605e in transmit_invite
(p=0xaed37a00, sipmethod=3, sdp=0,
init=2) at chan_sip.c:7688
https://issues.asterisk.org/view.php?id=5 0x00a47be2 in sip_poke_peer
(peer=0xb1e52900) at chan_sip.c:17167
https://issues.asterisk.org/view.php?id=6 0x00a1b39d in sip_poke_peer_s
(data=0xb1e52900) at chan_sip.c:8481
https://issues.asterisk.org/view.php?id=7 0x0810b15f in ast_sched_runq
(con=0x9c248f0) at sched.c:363
https://issues.asterisk.org/view.php?id=8 0x00a4680f in do_monitor (data=0x0)
at chan_sip.c:17011
https://issues.asterisk.org/view.php?id=9 0x0811c3d5 in dummy_start
(data=0x9c2a6e0) at utils.c:856
https://issues.asterisk.org/view.php?id=10 0x006ed5cc in start_thread () from
/lib/tls/libpthread.so.0
https://issues.asterisk.org/view.php?id=11 0x00657f0e in clone () from
/lib/tls/libc.so.6
Issue History
Date Modified Username Field Change
======================================================================
2010-02-16 10:56 zerohalo Note Added: 0118102
======================================================================
More information about the asterisk-bugs
mailing list