Thanks Lonnie
It went down again and this fixed it. Yay!
Im going to put it in Monit now to do it automatically. Now that we know the
issues, anything else you can think of?
Regards
Michael Knill
On 15/8/18, 7:10 am, "Michael Knill" wrote:
Awesome thanks Lonnie. I will try this when it g
Awesome thanks Lonnie. I will try this when it goes down next.
If it fixes the problem, I will try to get Monit to do it automatically e.g. if
pppoe is up and SIP is UNREACHABLE for a number of cycles.
Regards
Michael Knill
On 15/8/18, 6:49 am, "Lonnie Abelbeck" wrote:
> I tried a pppoe-r
> I tried a pppoe-restart on one of the sites and that did not fix the problem.
Michael, how long did you wait ? ie. PPPOE_RESTART_DELAY value
So, it seems cycling the PPPOEIF interface link in your
restart-pppoe-network-cron.sh script might be worth a try
Take a look at /usr/sbin/pppoe-restar
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
> 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
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" 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
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 use
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" wro
For the record, how long did you stop Asterisk ?
Lonnie
> On Aug 5, 2018, at 5:48 PM, Michael Knill
> 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 fixe
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
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" wrote:
Michael,
My theory has always been your problem is with an upstream firewall.
Stopping asterisk for a period of time may a
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 wi
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
Thanks Lonnie. Great info to know.
Its still a bit of a mystery though as I was seeing the outbound packet with
tcpdump so it had passed the firewall, but did not see the return packet!
Regards
Michael Knill
On 4/7/18, 10:41 pm, "Lonnie Abelbeck" wrote:
> So my questions are:
> • Is t
> 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
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 SI
16 matches
Mail list logo
