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.
