No that's not actually the issue as PPPoE always comes up fine. I'm starting to think it's when there is a power failure and PPPoE takes ages to come up, especially the new VDSL services we have here.
Let's see how it goes. Regards Michael Knill Sent from my iPhone so please excuse my brevity. > On 8 Jun 2017, at 10:17 pm, Michael Keuter <li...@mksolutions.info> wrote: > > >> 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. ------------------------------------------------------------------------------ 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.
