From: Lonnie A. <li...@lo...> - 2018-08-06 21:26:09
|
> 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 <mic...@ip...> 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...@lo...> 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 <mic...@ip...> 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...@lo...> wrote: >> >> For the record, how long did you stop Asterisk ? >> >> Lonnie >> >> >>> On Aug 5, 2018, at 5:48 PM, Michael Knill <mic...@ip...> 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" <mic...@ip...> 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...@lo...> 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 <mic...@ip...> 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...@lo...> 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 <mic...@ip...> 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 > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > ------------------------------------------------------------------------------ > 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 > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |