Ok I have had two other sites now which have exhibited the same issue, both
using the same internet provider.
I tried a pppoe-restart on one of the sites and that did not fix the problem.
I did a tcpdump -i ppp0 -Q in -A udp port 5060 and I received no packets e.g.
should have been receiving 200 OK from SIP OPTIONS.
When I got the customer to unplug the cable between the modem and Astlinux box
for about 10 seconds this fixed the problem.
Could this POSSIBLY be an Astlinux issue. It certainly seems not but I have no
idea where to go now.
I wonder if I can use Monit to disable and enable eth0 when its absolutely
broken.
Regards
Michael Knill
On 7/8/18, 7:26 am, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
> 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.
------------------------------------------------------------------------------
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.
