> PS. Why do you need to stop Asterisk first? In this case you can take advantage of the delay in the pppoe-restart script.
I like symmetry, stop services while the network is active ... restart the network ... start the services. You may want to restart more than just Asterisk, but that is a good start, and easy to test with it all in a custom script. Lonnie > On Aug 6, 2018, at 4:15 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> > wrote: > > Thanks Lonnie. Great to know. > > PS. Why do you need to stop Asterisk first? > > Regards > Michael Knill > > On 6/8/18, 11:31 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: > > Hi Michael, > > In case you were not aware, we have a PPPoE restart script > /usr/sbin/pppoe-restart designed to be called via cron in the the early > morning 0300, weekend, or such. > > The pppoe-restart script will restart with only a short delay (2 seconds) > by default but that can be changed with a user.conf variable > -- > PPPOE_RESTART_DELAY="180" > -- > which would make the delay 180 seconds. > > So, you could call your own custom cron script > > -- restart-pppoe-network-cron.sh -- > #!/bin/sh > > export PPPOE_RESTART_DELAY="180" > > service asterisk stop > > pppoe-restart > > service asterisk init > -- > Note: if you have a user.conf PPPOE_RESTART_DELAY defined it will override > the script's exported PPPOE_RESTART_DELAY value. > > And call that script via cron once a day or once a week when users won't > be bothered. > > Lonnie > > > >> On Aug 5, 2018, at 6:47 PM, Michael Knill >> <michael.kn...@ipcsolutions.com.au> wrote: >> >> Probably about 2 minutes. >> I am still thinking however that this is an upstream problem as you have >> mentioned and that I actually need to drop and re-establish the PPPoE >> connection for it to resolve. That's why a reboot fixes it. >> >> Regards >> Michael Knill >> >> On 6/8/18, 9:41 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: >> >> For the record, how long did you stop Asterisk ? >> >> Lonnie >> >> >>> On Aug 5, 2018, at 5:48 PM, Michael Knill >>> <michael.kn...@ipcsolutions.com.au> wrote: >>> >>> Hi All >>> >>> Thanks Lonnie for your idea however this problem occurred again and >>> stopping Asterisk for a while did not fix it. >>> I had to reboot again as the only thing that fixes it ☹ >>> >>> There are some network issues at the site but I cant see why it causes this! >>> I have changed out the DSL modem so that's not it. >>> >>> Any more ideas? >>> >>> Regards >>> Michael Knill >>> >>> On 5/7/18, 9:44 am, "Michael Knill" <michael.kn...@ipcsolutions.com.au> >>> wrote: >>> >>> Thanks Lonnie. Good call. That will be my next test. >>> PS IP Address stays the same. >>> >>> Regards >>> Michael Knill >>> >>> On 5/7/18, 9:14 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: >>> >>> Michael, >>> >>> My theory has always been your problem is with an upstream firewall. >>> >>> Stopping asterisk for a period of time may allow upstream firewall >>> states to expire. >>> >>> By rebooting AstLinux you will do the same (stop/start Asterisk) and >>> if you have PPPoE you may pull a different IP address which will bypass any >>> upstream states. >>> >>> From all you have described, this looks to me to be an upstream issue >>> relative to AstLinux. >>> >>> Lonnie >>> >>> >>> >>>> On Jul 4, 2018, at 4:56 PM, Michael Knill >>>> <michael.kn...@ipcsolutions.com.au> wrote: >>>> >>>> And yes good test. Of course a firewall restart does not clear >>>> translations. >>>> Am I able to clear firewall translations without waiting for them to time >>>> out which is what I assume you are doing here? >>>> It would have to be dome from a remote session as well e.g. through the >>>> firewall. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> On 4/7/18, 10:41 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: >>>> >>>>> So my questions are: >>>>> • Is tcpdump BEFORE the firewall? >>>> >>>> For incoming packets tcpdump is before the firewall, for outgoing packets >>>> tcpdump is after the firewall, ie. >>>> -- >>>> wire -> NIC -> tcpdump -> netfilter/firewall >>>> >>>> netfilter/firewall -> tcpdump -> NIC -> wire >>>> -- >>>> so tcpdump does not see outbound packets blocked by the firewall. >>>> >>>> >>>>> • What tests should I do next? >>>> >>>> Have you ever tried ... >>>> -- >>>> service asterisk stop >>>> sleep 90 >>>> service asterisk init >>>> -- >>>> >>>> >>>> Lonnie >>>> >>>> >>>> >>>> >>>> >>>>> On Jul 3, 2018, at 10:19 PM, Michael Knill >>>>> <michael.kn...@ipcsolutions.com.au> wrote: >>>>> >>>>> Back to the ongoing saga of SIP Options ping not working. This one is a >>>>> bit different though. Here is the scenario: >>>>> >>>>> • Can SSH into box fine and network connectivity is fine >>>>> • Find IP Address based SIP Trunk is UNREACHABLE. Can ping provider >>>>> from the box >>>>> • Asterisk SIP Debug shows SIP Options sent but none received. This is >>>>> also the case using tcpdump on the ppp0 interface >>>>> • Asterisk reload and Firewall restart did not fix the problem. The >>>>> system needed a full reboot for the trunk to be REACHABLE >>>>> >>>>> So my questions are: >>>>> • Is tcpdump BEFORE the firewall? >>>>> • Can you think of what the issue could be? >>>>> • What tests should I do next? >>>>> >>>>> Unfortunately (or fortunately) this happens very infrequently so the fix >>>>> will be a long confirmation period. >>>>> >>>>> Thanks all! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> ------------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > 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. ------------------------------------------------------------------------------ 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.
