> Am 08.06.2017 um 13:33 schrieb Michael Knill > <michael.kn...@ipcsolutions.com.au>: > > Hmm I think I will set this for PPPoE as it might solve some of my issues. > Funny I have never found it. > I thought 60 was a bit long but maybe better to be safe than sorry. > > ## Sometimes it takes a while for the WAN interface to come up... > ## This can happen with frame relay and PPPoE, for example. > ## Set this variable in seconds, and I will sleep on startup before > ## I attempt to bring up the WAN interface. > WANDELAY=60 > > Regards > Michael Knill
IMHO this is only for if you boot up or restart the computer, so the PPPoE service will wait <WANDELAY> secs before it starts. I think this might be better suited: ## The PPPoE restart delay (in seconds) between pppoe-stop and pppoe-start for a pppoe-restart. ## Defaults to 2 seconds when not defined, some ISP's may require a much longer delay. #PPPOE_RESTART_DELAY=2 > -----Original Message----- > From: Michael Knill <michael.kn...@ipcsolutions.com.au> > Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> > Date: Thursday, 8 June 2017 at 9:01 pm > To: AstLinux List <astlinux-users@lists.sourceforge.net> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > Could Monit do it? I am playing with it now! > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mksolutions.info> > Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> > Date: Thursday, 8 June 2017 at 8:58 pm > To: AstLinux List <astlinux-users@lists.sourceforge.net> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > >> Am 08.06.2017 um 10:28 schrieb Michael Knill >> <michael.kn...@ipcsolutions.com.au>: >> >> Ah so have you had similar problems to me then where Asterisk has still lost >> connectivity when PPPoE comes back? >> Do you know why it does this? >> >> Regards >> Michael Knill > > No not really, I just let the cron script run so that the ISP disconnect does > not occur during office time. > > It would be nice if this could be monitored somehow and then action could be > taken automatically (like with DynDNS). > >> -----Original Message----- >> From: Michael Keuter <li...@mksolutions.info> >> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Date: Thursday, 8 June 2017 at 6:24 pm >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> >>> Am 08.06.2017 um 09:51 schrieb Michael Knill >>> <michael.kn...@ipcsolutions.com.au>: >>> >>> Slightly different but this happened again today. It was a registered trunk >>> but I had to reload before it worked. >>> >>> Im beginning to think it's something to do with PPPoE/firewall. I have >>> never had this problem at non PPPoE sites. >>> >>> Regards >>> Michael Knill >> >> What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an >> amount of time (20-180 seconds, needs to be tested) and then restarts DNS >> and reloads Asterisk (whatever you need). >> Usually the ISPs disconnect the DSL lines every 24 hours (at least here in >> Germany). >> >>> From: Michael Knill <michael.kn...@ipcsolutions.com.au> >>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> Date: Wednesday, 7 June 2017 at 11:30 am >>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >>> >>> And its happened again at another site. Astlinux rebooted this time which I >>> hope was a power failure. >>> It just seems like Asterisk doesn't know that its up. Any ideas on how I >>> should test this when it happens again? DNS issue maybe? >>> I might also try sip qualify peer from the cli to see if this brings it up. >>> >>> Regards >>> Michael Knill >>> >>> From: Michael Knill <michael.kn...@ipcsolutions.com.au> >>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> Date: Monday, 5 June 2017 at 11:26 am >>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> Subject: [Astlinux-users] Problems with losing SIP Trunk >>> >>> Hi group >>> >>> I have actually reported this problem before but it was using a different >>> network connection. >>> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via >>> a firewall so it is using NAT but I don't think it should matter. >>> It appears that when there is a particular event that there is a temporary >>> loss of connectivity, but not a link down event, qualify or SIP OPTIONS >>> pings do not make it to the trunk provider (or back again as I have not >>> been able to test). Performing an Asterisk reload fixes the problem >>> immediately. >>> >>> Before reload: >>> I managed to check the reload before and after firewall states: >>> Source Port (#'s) Destination Port Protocol >>> Packets Bytes TTL >>> 192.168.2.5 5060 192.168.2.38 5060 UDP >>> 28535 16835829 2:59 >>> 192.168.2.5 5060 192.168.2.39 5060 UDP >>> 17450 10280235 2:58 >>> 192.168.2.5 5060 192.168.2.35 5060 UDP >>> 16930 9948145 2:59 >>> 192.168.2.5 5060 192.168.2.42 5060 UDP >>> 12961 7604592 2:54 >>> 192.168.2.5 5060 192.168.2.37 5060 UDP >>> 3561 2019123 2:57 >>> 192.168.2.5 5060 192.168.2.36 5060 UDP >>> 3454 1952748 2:53 >>> 124.171.212.155 50133 172.30.10.2 7123 TCP >>> 222 56430 7199:59 >>> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 >>> 45600 0:55 >>> 192.168.2.22 17500 255.255.255.255 17500 UDP >>> 100 22800 0:55 >>> 192.168.2.30 138 192.168.2.255 138 UDP 1 >>> 229 0:58 >>> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP >>> 2 211 0:59 >>> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP >>> 2 120 1:11 >>> 48 Total Firewall States >>> >>> After reload: >>> Source Port (#'s) Destination Port Protocol >>> Packets Bytes TTL >>> 192.168.2.5 5060 192.168.2.38 5060 UDP >>> 28773 16975982 2:57 >>> 192.168.2.5 5060 192.168.2.35 5060 UDP >>> 17821 10475864 2:59 >>> 192.168.2.5 5060 192.168.2.39 5060 UDP >>> 17596 10365993 2:58 >>> 192.168.2.5 5060 192.168.2.42 5060 UDP >>> 13069 7667552 2:50 >>> 192.168.2.5 5060 192.168.2.37 5060 UDP >>> 3591 2035954 2:50 >>> 192.168.2.5 5060 192.168.2.36 5060 UDP >>> 3484 1969553 2:58 >>> 124.171.212.155 50133 172.30.10.2 7123 TCP >>> 548 132258 7199:59 >>> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 >>> 48792 0:43 >>> 192.168.2.22 17500 255.255.255.255 17500 UDP >>> 107 24396 0:43 >>> 172.30.10.2 5060 125.213.162.112 5060 >>> UDP 2 1042 0:50 >>> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP >>> 2 211 0:59 >>> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP >>> 2 120 1:39 >>> 28 Total Firewall States >>> >>> My provider 125.213.162.112 is now there so I assume that the problem is >>> not in the firewall that Astlinux traverses but the Astlinux firewall >>> itself. >>> I am sending OPTIONS pings every 30 seconds. Why would this not just set up >>> the firewall state again? Maybe its an Asterisk problem? >>> >>> Any ideas? What should I check when it happens again? >>> >>> Regards >>> Michael Knill >> >> Michael > > Michael Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
