Bug#433779: asterisk doesn't retry SIP registrations if DNS is not available

2010-06-12 Thread Petter Reinholdtsen

tags 433779 + patch
thanks

[Robert Edmonds]
 if i'm not mistaken, on systems with parallel booting enabled this
 means it would be possible for asterisk to start before the network
 is up or name resolution is available.  i believe that $named and
 $network should be added to Should-Start.

For the common setup, network would always be enabled earlier, but
this might change in the future, so it is smart to list $network as an
explicit dependency.

But a local DNS server can be started after asterisk, yes, unless
$named is listed as a init.d script dependency, and reading this bug
report make me suspect asterisk should almost always start after a
local DNS server.

Also, the asterisk service seem to log to syslog (found in
main/logger.c), so it should start after the syslog collector is
started too and depend on $syslog.

Based on this, I suggest to change the init.d script dependencies like
this:

diff -ru asterisk-1.6.2.7/debian/asterisk.init 
asterisk-1.6.2.7-pere/debian/asterisk.init
--- asterisk-1.6.2.7/debian/asterisk.init   2010-02-07 14:15:13.0 
+0100
+++ asterisk-1.6.2.7-pere/debian/asterisk.init  2010-06-12 22:16:56.0 
+0200
@@ -14,8 +14,8 @@
 # Provides:  asterisk
 # Required-Start:$remote_fs
 # Required-Stop: $remote_fs
-# Should-Start:  dahdi mysql postgresql
-# Should-Stop:   mysql postgresql
+# Should-Start:  $syslog $network $named mysql postgresql dahdi
+# Should-Stop:   $syslog $network $named mysql postgresql
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: Asterisk PBX

Happy hacking,
-- 
Petter Reinholdtsen



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#433779: asterisk doesn't retry SIP registrations if DNS is not available

2010-06-01 Thread Sudhakara alva
help

On 6/1/10, Robert Edmonds edmo...@debian.org wrote:
 found 433779 asterisk/1:1.6.2.7-1
 user initscripts-ng-de...@lists.alioth.debian.org
 usertag 433779 + missing-dependency
 thanks

 hi,

 it appears that asterisk is incorrectly treating DNS resolution failure
 during SIP registration as a 404 not found SIP response.

 when my system boots, asterisk is started after my recursive DNS server,
 and i see this in /var/log/asterisk/messages:

 [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup
 'inbound23.vitelity.net'
 [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup
 'outbound.vitelity.net'
 [May 31 17:36:41] WARNING[1704] acl.c: Unable to lookup
 'inbound23.vitelity.net'
 [May 31 17:36:41] NOTICE[1704] chan_sip.c: Registration from
 'sip:edmond...@inbound23.vitelity.net' failed for '127.0.0.1' - No
 matching peer found
 [May 31 17:36:41] WARNING[1704] chan_sip.c: Got 404 Not found on SIP
 register to service edmond...@inbound23.vitelity.net, giving up

 it seems to be impossible for asterisk to have received a 404 not
 found response from the SIP peer if DNS is not available, and indeed i
 verified with a packet sniffer that no SIP packets were sent or
 received.

 it looks like there are two bugs here:

 1) asterisk should treat DNS resolution failures as transient network
 failures, not SIP failures, and be subject to retrying the registration.
 asterisk made no attempt to retry the registration after the initial DNS
 failure.

 2) /etc/init.d/asterisk contains the following LSB header:

 ### BEGIN INIT INFO
 # Provides:  asterisk
 # Required-Start:$remote_fs
 # Required-Stop: $remote_fs
 # Should-Start:  dahdi mysql postgresql
 # Should-Stop:   mysql postgresql
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: Asterisk PBX
 # Description:   Controls the Asterisk PBX
 ### END INIT INFO

 if i'm not mistaken, on systems with parallel booting enabled this means
 it would be possible for asterisk to start before the network is up or
 name resolution is available.  i believe that $named and $network should
 be added to Should-Start.

 --
 Robert Edmonds
 edmo...@debian.org




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#433779: asterisk doesn't retry SIP registrations if DNS is not available

2010-05-31 Thread Robert Edmonds
found 433779 asterisk/1:1.6.2.7-1
user initscripts-ng-de...@lists.alioth.debian.org
usertag 433779 + missing-dependency
thanks

hi,

it appears that asterisk is incorrectly treating DNS resolution failure
during SIP registration as a 404 not found SIP response.

when my system boots, asterisk is started after my recursive DNS server,
and i see this in /var/log/asterisk/messages:

[May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'inbound23.vitelity.net'
[May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'outbound.vitelity.net'
[May 31 17:36:41] WARNING[1704] acl.c: Unable to lookup 'inbound23.vitelity.net'
[May 31 17:36:41] NOTICE[1704] chan_sip.c: Registration from 
'sip:edmond...@inbound23.vitelity.net' failed for '127.0.0.1' - No matching 
peer found
[May 31 17:36:41] WARNING[1704] chan_sip.c: Got 404 Not found on SIP register 
to service edmond...@inbound23.vitelity.net, giving up

it seems to be impossible for asterisk to have received a 404 not
found response from the SIP peer if DNS is not available, and indeed i
verified with a packet sniffer that no SIP packets were sent or
received.

it looks like there are two bugs here:

1) asterisk should treat DNS resolution failures as transient network
failures, not SIP failures, and be subject to retrying the registration.
asterisk made no attempt to retry the registration after the initial DNS
failure.

2) /etc/init.d/asterisk contains the following LSB header:

### BEGIN INIT INFO
# Provides:  asterisk
# Required-Start:$remote_fs
# Required-Stop: $remote_fs
# Should-Start:  dahdi mysql postgresql
# Should-Stop:   mysql postgresql
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Asterisk PBX
# Description:   Controls the Asterisk PBX
### END INIT INFO

if i'm not mistaken, on systems with parallel booting enabled this means
it would be possible for asterisk to start before the network is up or
name resolution is available.  i believe that $named and $network should
be added to Should-Start.

-- 
Robert Edmonds
edmo...@debian.org


signature.asc
Description: Digital signature