astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[The C. K. <eld...@ya...>]

 I didnt count lightning strikes..  I have had 2 lost in lightning strikes..  MAJOR strikes..   since we often have systems connected via T1 / PRI. by way of an Adtran TA900, the point of lightning failure (even with SNEAK) tends to be the T1's get popped..  either the can or the pole depending on the location... other times the station cabling is hit.. (majority of our sites have a few IP sets and many analogs on gateways).  in the 2 cases of loss of APUs the core switches, adtrans, at least one GXW-4224 were destroyed...  both APU boards were completely INOP. however their flashes were still good when placed into new boards..  

I dont count lightning failures unless a board seems to be the only thing damaged over and over..  and we havent seen that..  we havent had hardly any failiures of standard Jetway boards in the iDotPC 1u enclosures ..  NF99 (cant remember the rest of the number) D525 boards are our most common Jetway product in the field..  at least 100 of them and they are solid... all of those are WD black 2.5" spindles. 

-Christopher


    On Sunday, July 22, 2018, 4:24:41 PM EDT, Michael Knill <mic...@ip...> wrote:  
 
 
I don't use this particular box but also to concur that I have never lost a PC Engines box except for the one that was hit by lightning, and that was only the eth0 port.
 
  
 
Regards
 
Michael Knill
 
  
 
From: AstLinux List <ast...@li...>
Reply-To: AstLinux List <ast...@li...>
Date: Sunday, 22 July 2018 at 11:40 pm
To: AstLinux List <ast...@li...>
Cc: The Cadillac Kid <eld...@ya...>
Subject: Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance
 
  
 
same experience on my end..  i had 3 in the field.. 2 were lost when the phone room temp went consistently above 80 degrees for the summer months.  the other is still in service, however in a very controlled IT environment. 
 
  
 
we havent yet lost any APU or APU2 boards and have 100s out in the field, some in pretty crappy environments..  all are PC-engines mini cases mounted to UTR-1 vented rack-shelves for additional passive cooling
 
  
 
our Soekris NET5501 boxes are slowly losing their CF cards after 7-8 years in the field now..  boards are still just fine..
 
  
 
-Christopher
 
  
 
On Sunday, July 22, 2018, 9:32:48 AM EDT, Lonnie Abelbeck <li...@lo...> wrote:
 
  
 
  
 
Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
 
https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w
 
  
 
We have had multiple reports that after 3-5 years of use, this appliance fails.
 
  
 
Presumably heat related.
 
  
 
If you have this appliance in production, consider replacing it.
 
  
 
AstLinux Team
 
  
 
  
 
------------------------------------------------------------------------------
 
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 top...@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....  

[Astlinux-users] WAN Failover static routes primary

[Michael K. <mic...@ip...>]

Hi Group

Is there any way to configure a static route for the primary interface e.g. a route which will not fail over to the secondary?
I basically do not want to access my VoIP Provider on the secondary interface e.g. it needs to be unreachable so it fails over to my backup trunk for outgoing calls.
I could put the SIP address in the Target IPv4 Hosts section but that would be my last resort.

Thanks

Regards
Michael Knill

Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[Michael K. <mic...@ip...>]

I don't use this particular box but also to concur that I have never lost a PC Engines box except for the one that was hit by lightning, and that was only the eth0 port.

Regards
Michael Knill

From: AstLinux List <ast...@li...>
Reply-To: AstLinux List <ast...@li...>
Date: Sunday, 22 July 2018 at 11:40 pm
To: AstLinux List <ast...@li...>
Cc: The Cadillac Kid <eld...@ya...>
Subject: Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

same experience on my end..  i had 3 in the field.. 2 were lost when the phone room temp went consistently above 80 degrees for the summer months.  the other is still in service, however in a very controlled IT environment.

we havent yet lost any APU or APU2 boards and have 100s out in the field, some in pretty crappy environments..  all are PC-engines mini cases mounted to UTR-1 vented rack-shelves for additional passive cooling

our Soekris NET5501 boxes are slowly losing their CF cards after 7-8 years in the field now..  boards are still just fine..

-Christopher

On Sunday, July 22, 2018, 9:32:48 AM EDT, Lonnie Abelbeck <li...@lo...> wrote:


Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w

We have had multiple reports that after 3-5 years of use, this appliance fails.

Presumably heat related.

If you have this appliance in production, consider replacing it.

AstLinux Team


------------------------------------------------------------------------------
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...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....<mailto:pa...@kr....>

Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[Michael K. <li...@mk...>]

> Am 22.07.2018 um 15:39 schrieb The Cadillac Kid via Astlinux-users <ast...@li...>:
> 
> same experience on my end..  i had 3 in the field.. 2 were lost when the phone room temp went consistently above 80 degrees for the summer months.  the other is still in service, however in a very controlled IT environment. 
> 
> we havent yet lost any APU or APU2 boards and have 100s out in the field, some in pretty crappy environments..  all are PC-engines mini cases mounted to UTR-1 vented rack-shelves for additional passive cooling

Hi Christopher,

do you have link for the above "UTR-1 vented rack-shelves"?

> our Soekris NET5501 boxes are slowly losing their CF cards after 7-8 years in the field now..  boards are still just fine..
> 
> -Christopher
> 
> On Sunday, July 22, 2018, 9:32:48 AM EDT, Lonnie Abelbeck <li...@lo...> wrote:
> 
> 
> Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
> https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w
> 
> We have had multiple reports that after 3-5 years of use, this appliance fails.
> 
> Presumably heat related.
> 
> If you have this appliance in production, consider replacing it.
> 
> AstLinux Team

Michael

http://www.mksolutions.info

Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[John N. <jn...@co...>]

Though slightly off topic, as many on the list don't use the HP Thin Clients due to a singe NIC:
I have had some of the older HP 55xx series fail after more than 10 years in service. ( And they were used when first put into service with AstLinux! )
Seems the quite familiar "dome top electrolytic" failure found in many desktop motherboards shows up in the TC as well.
Just had to replace one using astlinux .5 with Asterisk 1.2!
So far no long term failures with the 57xx series though.
No failures with the Flash yet. I used to use a CF card in an adapter, as these have a 44 pin IDE male connector on the MB, but long since moved to a larger flash that is a direct replacement.

John Novack



The Cadillac Kid via Astlinux-users wrote:
> same experience on my end..  i had 3 in the field.. 2 were lost when the phone room temp went consistently above 80 degrees for the summer months.  the other is still in service, however in a very controlled IT environment.
>
> we havent yet lost any APU or APU2 boards and have 100s out in the field, some in pretty crappy environments..  all are PC-engines mini cases mounted to UTR-1 vented rack-shelves for additional passive cooling
>
> our Soekris NET5501 boxes are slowly losing their CF cards after 7-8 years in the field now..  boards are still just fine..
>
> -Christopher
>
> On Sunday, July 22, 2018, 9:32:48 AM EDT, Lonnie Abelbeck <li...@lo...> wrote:
>
>
> Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
> https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w
>
> We have had multiple reports that after 3-5 years of use, this appliance fails.
>
> Presumably heat related.
>
> If you have this appliance in production, consider replacing it.
>
> AstLinux Team
>
>
> ------------------------------------------------------------------------------
> 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... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... <mailto: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....

-- 

Dog is my Co-pilot

Re: [Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[The C. K. <eld...@ya...>]

 same experience on my end..  i had 3 in the field.. 2 were lost when the phone room temp went consistently above 80 degrees for the summer months.  the other is still in service, however in a very controlled IT environment. 

we havent yet lost any APU or APU2 boards and have 100s out in the field, some in pretty crappy environments..  all are PC-engines mini cases mounted to UTR-1 vented rack-shelves for additional passive cooling

our Soekris NET5501 boxes are slowly losing their CF cards after 7-8 years in the field now..  boards are still just fine..
-Christopher
    On Sunday, July 22, 2018, 9:32:48 AM EDT, Lonnie Abelbeck <li...@lo...> wrote:  
 
 Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w

We have had multiple reports that after 3-5 years of use, this appliance fails.

Presumably heat related.

If you have this appliance in production, consider replacing it.

AstLinux Team


------------------------------------------------------------------------------
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....
  

[Astlinux-users] Jetway JBC373F38W Atom D525 Fanless Appliance

[Lonnie A. <li...@lo...>]

Concerning the Jetway JBC373F38W Atom D525 Fanless Appliance
https://doc.astlinux-project.org/userdoc:board_jetway_jbc373f38w

We have had multiple reports that after 3-5 years of use, this appliance fails.

Presumably heat related.

If you have this appliance in production, consider replacing it.

AstLinux Team

Re: [Astlinux-users] Astlinux hot standby

[Michael K. <li...@mk...>]

> Am 22.07.2018 um 09:35 schrieb Michael Knill <mic...@ip...>:
> 
> Thanks Lonnie
> 
> Yes I agree totally. But there is also another factor which is restoration time and a broken Astlinux box have a much longer restoration time than all the others.

Yes, that's a valid point.
It seems it is much depending where in the world you live: Lonnie's order of a Qotom box was delivered after a few days, mine took 11 days.
The Jetway boxes are also often not in stock.
So it might be good to good to have some spare hardware.

> I have actually had a couple of storage issues and a lightning strike so it certainly happens and I don't know the longevity of the new Qotom boxes so I need insurance! 
> 
> Regards
> Michael Knill
> 
> On 22/7/18, 3:06 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>    Hi Michael,
> 
>    I don't have any experience to comment on your hot standby solution, but just some birds-eye-view thoughts ...
> 
>    1) Make sure your High Availability solution doesn't create more problems than it solves.
> 
>    2) Solve possible availability issues in order of likelihood.
> 
>    For example, consider the following table of "Availability Normalized Probability" (of my own creation) ...
> 
>    Availability Normalized Probability
>    ===================================
>    99) Power outage
> 
>    95) Upstream network issue
> 
>    80) Upstream SIP provider issue
> 
>    10) Software misconfiguration (human) error
> 
>    04) Local network issue (switch, cable, etc.)
> 
>    03) AstLinux hardware issue (failed storage, power supply, etc.)
> 
>    <1) Astroid strike
>    ==
> 
>    Note: The above table is a work in progress.
> 
>    For example, it makes little sense to provide redundant network switches if there is no Uninterruptible Power Supply or WAN failover.
> 
>    My 2 cents.
> 
>    Lonnie
> 
> 
>> On Jul 20, 2018, at 8:11 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Hi Group
>> 
>> I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
>> This is what I am planning to do:
>> 	• The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
>> 	• The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
>> 	• Both servers are remotely accessible
>> 
>> In the event that the primary server fails, the following is performed to failover to the HS server:
>> 	• Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
>> 	• Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
>> 	• Register the SIP Trunk on the HS server
>> 
>> My initial testing seems to work well and I cant find any issues.
>> 
>> Obviously there are some caveats:
>> 	• Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
>> 	• The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
>> 	• Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
>> 	• Devstate will not be maintained
>> 
>> Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.
>> 
>> What do you think? Can you see any other issues?
>> 
>> Regards
>> Michael Knill

Michael

http://www.mksolutions.info

Re: [Astlinux-users] Astlinux hot standby

[Michael K. <mic...@ip...>]

Thanks Lonnie

Yes I agree totally. But there is also another factor which is restoration time and a broken Astlinux box have a much longer restoration time than all the others.
I have actually had a couple of storage issues and a lightning strike so it certainly happens and I don't know the longevity of the new Qotom boxes so I need insurance! 

Regards
Michael Knill

On 22/7/18, 3:06 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,
    
    I don't have any experience to comment on your hot standby solution, but just some birds-eye-view thoughts ...
    
    1) Make sure your High Availability solution doesn't create more problems than it solves.
    
    2) Solve possible availability issues in order of likelihood.
    
    For example, consider the following table of "Availability Normalized Probability" (of my own creation) ...
    
    Availability Normalized Probability
    ===================================
    99) Power outage
    
    95) Upstream network issue
    
    80) Upstream SIP provider issue
    
    10) Software misconfiguration (human) error
    
    04) Local network issue (switch, cable, etc.)
    
    03) AstLinux hardware issue (failed storage, power supply, etc.)
    
    <1) Astroid strike
    ==
    
    Note: The above table is a work in progress.
    
    For example, it makes little sense to provide redundant network switches if there is no Uninterruptible Power Supply or WAN failover.
    
    My 2 cents.
    
    Lonnie
    
    
    
    
    > On Jul 20, 2018, at 8:11 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Group
    >  
    > I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
    > This is what I am planning to do:
    > 	• The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
    > 	• The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
    > 	• Both servers are remotely accessible
    >  
    > In the event that the primary server fails, the following is performed to failover to the HS server:
    > 	• Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
    > 	• Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
    > 	• Register the SIP Trunk on the HS server
    >  
    > My initial testing seems to work well and I cant find any issues.
    >  
    > Obviously there are some caveats:
    > 	• Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
    > 	• The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
    > 	• Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
    > 	• Devstate will not be maintained
    >  
    > Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.
    >  
    > What do you think? Can you see any other issues?
    >  
    > 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....

Re: [Astlinux-users] Astlinux hot standby

[Michael K. <mic...@ip...>]

Thanks Michael. 

In my testing the phones reregistered quite quickly actually e.g. a couple of seconds. The arping would have sorted out the ARP table on the phone.
I actually don't want auto failover at this time. Lots of testing required as it could actually break a working system e.g. duplicate Virtual IP Address

Regards
Michael Knill

On 21/7/18, 9:15 pm, "Michael Keuter" <li...@mk...> wrote:

    
    > Am 21.07.2018 um 03:11 schrieb Michael Knill <mic...@ip...>:
    > 
    > Hi Group
    >  
    > I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
    > This is what I am planning to do:
    > 	• The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
    > 	• The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
    > 	• Both servers are remotely accessible
    >  
    > In the event that the primary server fails, the following is performed to failover to the HS server:
    > 	• Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
    > 	• Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
    > 	• Register the SIP Trunk on the HS server
    >  
    > My initial testing seems to work well and I cant find any issues.
    >  
    > Obviously there are some caveats:
    > 	• Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
    > 	• The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
    > 	• Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
    > 	• Devstate will not be maintained
    >  
    > Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.
    >  
    > What do you think? Can you see any other issues?
    >  
    > Regards
    > Michael Knill
    
    Hi Michael,
    
    some thoughts:
    * It could take some time until all IP-phones re-register on the Real/Virtual server IP (depending on their config up to 10 minutes).
    * If you have a central PoE-switch you could simply reboot that switch to reboot all phones at once to re-register.
    * Think about that the provisioning then also switches. 
    * Some phones (e.g. Yealink) also have the ability to register to a 2nd SIP-server and do a failover on their own…
    
    For automatic switching of the "Virtual IP" there are existing solutions (not in AstLinux yet):
    * ucarp (domain "ucarp.org" seems to be gone) => https://github.com/jedisct1/UCarp/commits/master (not very up to date :-( )
    * keepalived (an older version is in Buildroot) => http://www.keepalived.org
    
    https://blog.itanddevelopment.com/simple-automatic-failover-for-asterisk-and-freepbx/
    
    http://blog.unicsolution.com/2015/01/kamailio-high-availability-with.html
    
    Only my 2 ct.
    
    Michael
    
    http://www.mksolutions.info
    
    
    
    
    ------------------------------------------------------------------------------
    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....

Re: [Astlinux-users] Astlinux hot standby

[Lonnie A. <li...@lo...>]

Hi Michael,

I don't have any experience to comment on your hot standby solution, but just some birds-eye-view thoughts ...

1) Make sure your High Availability solution doesn't create more problems than it solves.

2) Solve possible availability issues in order of likelihood.

For example, consider the following table of "Availability Normalized Probability" (of my own creation) ...

Availability Normalized Probability
===================================
99) Power outage

95) Upstream network issue

80) Upstream SIP provider issue

10) Software misconfiguration (human) error

04) Local network issue (switch, cable, etc.)

03) AstLinux hardware issue (failed storage, power supply, etc.)

<1) Astroid strike
==

Note: The above table is a work in progress.

For example, it makes little sense to provide redundant network switches if there is no Uninterruptible Power Supply or WAN failover.

My 2 cents.

Lonnie




> On Jul 20, 2018, at 8:11 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
>  
> I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
> This is what I am planning to do:
> 	• The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
> 	• The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
> 	• Both servers are remotely accessible
>  
> In the event that the primary server fails, the following is performed to failover to the HS server:
> 	• Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
> 	• Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
> 	• Register the SIP Trunk on the HS server
>  
> My initial testing seems to work well and I cant find any issues.
>  
> Obviously there are some caveats:
> 	• Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
> 	• The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
> 	• Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
> 	• Devstate will not be maintained
>  
> Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.
>  
> What do you think? Can you see any other issues?
>  
> 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....

Re: [Astlinux-users] Astlinux hot standby

[Michael K. <li...@mk...>]

> Am 21.07.2018 um 03:11 schrieb Michael Knill <mic...@ip...>:
> 
> Hi Group
>  
> I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
> This is what I am planning to do:
> 	• The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
> 	• The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
> 	• Both servers are remotely accessible
>  
> In the event that the primary server fails, the following is performed to failover to the HS server:
> 	• Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
> 	• Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
> 	• Register the SIP Trunk on the HS server
>  
> My initial testing seems to work well and I cant find any issues.
>  
> Obviously there are some caveats:
> 	• Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
> 	• The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
> 	• Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
> 	• Devstate will not be maintained
>  
> Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.
>  
> What do you think? Can you see any other issues?
>  
> Regards
> Michael Knill

Hi Michael,

some thoughts:
* It could take some time until all IP-phones re-register on the Real/Virtual server IP (depending on their config up to 10 minutes).
* If you have a central PoE-switch you could simply reboot that switch to reboot all phones at once to re-register.
* Think about that the provisioning then also switches. 
* Some phones (e.g. Yealink) also have the ability to register to a 2nd SIP-server and do a failover on their own…

For automatic switching of the "Virtual IP" there are existing solutions (not in AstLinux yet):
* ucarp (domain "ucarp.org" seems to be gone) => https://github.com/jedisct1/UCarp/commits/master (not very up to date :-( )
* keepalived (an older version is in Buildroot) => http://www.keepalived.org

https://blog.itanddevelopment.com/simple-automatic-failover-for-asterisk-and-freepbx/

http://blog.unicsolution.com/2015/01/kamailio-high-availability-with.html

Only my 2 ct.

Michael

http://www.mksolutions.info

[Astlinux-users] Astlinux hot standby

[Michael K. <mic...@ip...>]

Hi Group

I have won a reasonable size customer (90 extensions) and Im currently testing Astlinux hot standby.
This is what I am planning to do:

  1.  The Astlinux HS is in parallel to the primary Astlinux server with different IP Addresses on the internal and external interface but same subnet. Its likely that these systems will be behind a firewall using NAT. The SIP Trunk will be registered and not IP Address based.
  2.  The primary server periodically synchronises its config and database to the HS server. I can basically use my standard backup and restore script to do this
  3.  Both servers are remotely accessible

In the event that the primary server fails, the following is performed to failover to the HS server:

  1.  Add primary server IP as virtual IP on HS server e.g. ifconfig eth1.100:1 172.30.30.1 netmask 255.255.255.0
  2.  Update ARP table e.g. arping -q -U -c 3 -I eth1.100 172.30.30.1
  3.  Register the SIP Trunk on the HS server

My initial testing seems to work well and I cant find any issues.

Obviously there are some caveats:

  1.  Don't sync gui.network.conf and Asterisk SIP Trunk config files as they are different on the HS server
  2.  The virtual IP is not permanent. If the outage is long term, the HS server should be converted into the primary (only a couple of files are different)
  3.  Unless converted into the primary, any config changes (including dynamic ones) will need to be synced to the primary server when failed back
  4.  Devstate will not be maintained

Although this solution is not perfect, the ability to run up a new server in minutes remotely is certainly a big plus.

What do you think? Can you see any other issues?

Regards
Michael Knill

Re: [Astlinux-users] Monit unable to read file system

[Michael K. <mic...@ip...>]

Well there you go. That is my problem!
This is an old build where I shared Unionfs and /mnt/kd. I will need to watch that one.
Interesting that it worked fine for ages and it wasn't a problem until it was rebooted.

Thanks Lonnie.

Regards
Michael Knill

On 17/7/18, 10:07 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,
    
    Is '/mnt/kd' mounted on the system ? Any output with this command ?
    --
    mount | grep '/mnt/kd'
    --
    
    Keep in mind that /mnt/kd is only mounted when you choose (during installation setup)
    o Separate Unionfs and /mnt/kd/ partitions
    
    If this command returns an "unable to resolve" error
    --
    findfs LABEL=ASTKD
    --
    then Monit should not be monitoring /mnt/kd since there isn't such a filesystem.
    If that is the case, disable monitoring /mnt/kd by commenting it out ...
    
    -- /mnt/kd/monit/monit.d/services.conf snippet --
    #check filesystem kd
    #  path /mnt/kd
    #  if space usage > 80% then alert
    --
    
    Lonnie
    
    
    
    > On Jul 16, 2018, at 10:23 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi All
    >  
    > Im getting these errors:
    > Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: Filesystem '/mnt/kd' not mounted
    > Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: 'kd' unable to read filesystem '/mnt/kd' state
    > Jul 17 13:15:12 3011-SageWC-CM1 daemon.info monit[1000]: 'kd' trying to restart
    >  
    > But the system seems to be running fine. Is this a storage error but not bad enough to be causing a problem?
    > What should I do to troubleshoot?
    >  
    > 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....
    

Re: [Astlinux-users] Monit unable to read file system

[Lonnie A. <li...@lo...>]

Hi Michael,

Is '/mnt/kd' mounted on the system ? Any output with this command ?
--
mount | grep '/mnt/kd'
--

Keep in mind that /mnt/kd is only mounted when you choose (during installation setup)
o Separate Unionfs and /mnt/kd/ partitions

If this command returns an "unable to resolve" error
--
findfs LABEL=ASTKD
--
then Monit should not be monitoring /mnt/kd since there isn't such a filesystem.
If that is the case, disable monitoring /mnt/kd by commenting it out ...

-- /mnt/kd/monit/monit.d/services.conf snippet --
#check filesystem kd
#  path /mnt/kd
#  if space usage > 80% then alert
--

Lonnie



> On Jul 16, 2018, at 10:23 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi All
>  
> Im getting these errors:
> Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: Filesystem '/mnt/kd' not mounted
> Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: 'kd' unable to read filesystem '/mnt/kd' state
> Jul 17 13:15:12 3011-SageWC-CM1 daemon.info monit[1000]: 'kd' trying to restart
>  
> But the system seems to be running fine. Is this a storage error but not bad enough to be causing a problem?
> What should I do to troubleshoot?
>  
> Thanks all.
>  
> Regards
> Michael Knill

Re: [Astlinux-users] PubSub on Astlinux

[Michael K. <mic...@ip...>]

Its working now. Yay!

serverhost=localhost - did not work

Thanks for your help.

Regards
Michael Knill

On 17/7/18, 5:41 pm, "Michael Keuter" <li...@mk...> wrote:

    
    > Am 17.07.2018 um 08:48 schrieb Michael Knill <mic...@ip...>:
    > 
    > Has anyone set this up as I am unable to get it to work.
    > I have both clients connected but no change of hints.
    > 
    > Clients have connected:
    > Prosody Version: 0.9.12
    > This server has been running for 0 days, 0 hours and 1 minute (since Tue Jul 17 16:40:05 2018)
    > 20070.ibcaccess.net
    >   cm...@20.../asterisk-xmpp - available(1)
    >   cm...@20.../asterisk-xmpp - available(1)
    > Total: 2 clients
    > 
    > CM1:
    > 2007-AQ_Super-CM1*CLI> xmpp show buddies
    > XMPP buddy lists
    > Client: asterisk
    > 	Buddy:	cm...@20...
    > 		Resource: asterisk-xmpp
    > 			node: http://www.asterisk.org/xmpp/client/caps
    > 			version: asterisk-xmpp
    > 			Google Talk capable: no
    > 			Jingle capable: no
    > 2007-AQ_Super-CM1*CLI> xmpp show connections
    > Jabber Users and their status:
    >       [asterisk] cm...@20...     - Connected
    > ----
    >   Number of clients: 1
    > 
    > CM2:
    > 2007-New_Super-CM2*CLI> xmpp show buddies
    > XMPP buddy lists
    > Client: asterisk
    > 	Buddy:	cm...@20...
    > 		Resource: asterisk-xmpp
    > 			node: http://www.asterisk.org/xmpp/client/caps
    > 			version: asterisk-xmpp
    > 			Google Talk capable: no
    > 			Jingle capable: yes
    > 2007-New_Super-CM2*CLI> xmpp show connections
    > Jabber Users and their status:
    >       [asterisk] cm...@20...     - Connected
    > ----
    >   Number of clients: 1
    > 
    > Any ideas?
    > 
    > Regards
    > Michael Knill
    
    Yes, I did that years ago.
    
    It is documented here:
    https://doc.astlinux.org/userdoc:tt_distribute_events_xmpp_pubsub
    
    Important are the PubSub Admins.
    
    Michael
    
    http://www.mksolutions.info
    
    
    
    
    ------------------------------------------------------------------------------
    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....
    

Re: [Astlinux-users] PubSub on Astlinux

[Michael K. <li...@mk...>]

> Am 17.07.2018 um 08:48 schrieb Michael Knill <mic...@ip...>:
> 
> Has anyone set this up as I am unable to get it to work.
> I have both clients connected but no change of hints.
> 
> Clients have connected:
> Prosody Version: 0.9.12
> This server has been running for 0 days, 0 hours and 1 minute (since Tue Jul 17 16:40:05 2018)
> 20070.ibcaccess.net
>   cm...@20.../asterisk-xmpp - available(1)
>   cm...@20.../asterisk-xmpp - available(1)
> Total: 2 clients
> 
> CM1:
> 2007-AQ_Super-CM1*CLI> xmpp show buddies
> XMPP buddy lists
> Client: asterisk
> 	Buddy:	cm...@20...
> 		Resource: asterisk-xmpp
> 			node: http://www.asterisk.org/xmpp/client/caps
> 			version: asterisk-xmpp
> 			Google Talk capable: no
> 			Jingle capable: no
> 2007-AQ_Super-CM1*CLI> xmpp show connections
> Jabber Users and their status:
>       [asterisk] cm...@20...     - Connected
> ----
>   Number of clients: 1
> 
> CM2:
> 2007-New_Super-CM2*CLI> xmpp show buddies
> XMPP buddy lists
> Client: asterisk
> 	Buddy:	cm...@20...
> 		Resource: asterisk-xmpp
> 			node: http://www.asterisk.org/xmpp/client/caps
> 			version: asterisk-xmpp
> 			Google Talk capable: no
> 			Jingle capable: yes
> 2007-New_Super-CM2*CLI> xmpp show connections
> Jabber Users and their status:
>       [asterisk] cm...@20...     - Connected
> ----
>   Number of clients: 1
> 
> Any ideas?
> 
> Regards
> Michael Knill

Yes, I did that years ago.

It is documented here:
https://doc.astlinux.org/userdoc:tt_distribute_events_xmpp_pubsub

Important are the PubSub Admins.

Michael

http://www.mksolutions.info

[Astlinux-users] PubSub on Astlinux

[Michael K. <mic...@ip...>]

Has anyone set this up as I am unable to get it to work.
I have both clients connected but no change of hints.

Clients have connected:
Prosody Version: 0.9.12
This server has been running for 0 days, 0 hours and 1 minute (since Tue Jul 17 16:40:05 2018)
20070.ibcaccess.net
   cm...@20.../asterisk-xmpp - available(1)
   cm...@20.../asterisk-xmpp - available(1)
Total: 2 clients

CM1:
2007-AQ_Super-CM1*CLI> xmpp show buddies
XMPP buddy lists
Client: asterisk
	Buddy:	cm...@20...
		Resource: asterisk-xmpp
			node: http://www.asterisk.org/xmpp/client/caps
			version: asterisk-xmpp
			Google Talk capable: no
			Jingle capable: no
2007-AQ_Super-CM1*CLI> xmpp show connections
Jabber Users and their status:
       [asterisk] cm...@20...     - Connected
----
   Number of clients: 1

CM2:
2007-New_Super-CM2*CLI> xmpp show buddies
XMPP buddy lists
Client: asterisk
	Buddy:	cm...@20...
		Resource: asterisk-xmpp
			node: http://www.asterisk.org/xmpp/client/caps
			version: asterisk-xmpp
			Google Talk capable: no
			Jingle capable: yes
2007-New_Super-CM2*CLI> xmpp show connections
Jabber Users and their status:
       [asterisk] cm...@20...     - Connected
----
   Number of clients: 1

Any ideas?

Regards
Michael Knill

[Astlinux-users] Monit unable to read file system

[Michael K. <mic...@ip...>]

Hi All

Im getting these errors:
Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: Filesystem '/mnt/kd' not mounted
Jul 17 13:15:12 3011-SageWC-CM1 daemon.err monit[1000]: 'kd' unable to read filesystem '/mnt/kd' state
Jul 17 13:15:12 3011-SageWC-CM1 daemon.info monit[1000]: 'kd' trying to restart

But the system seems to be running fine. Is this a storage error but not bad enough to be causing a problem?
What should I do to troubleshoot?

Thanks all.

Regards
Michael Knill

Re: [Astlinux-users] WAN Failover using Netgear LB1121 4G/LTE Modem

[Michael K. <mic...@ip...>]

Hi Group

I just have to say that in testing the WAN Failover solution it seems to be working excellently. 
My setup is a little different in that I have configured the DR server as a backup voice transit node with SIP Trunks to all backed up sites. When failed over, incoming calls use a dedicated backup DID for each site and outgoing calls transit the DR server via the trunk. 
The Wireguard VPN is up all the time on whichever WAN Link is active which is handy for fallback to the Primary as the call stays up and you don't even notice the WAN and VPN fallback while holding a conversation (cool thanks Wireguard).

The Netgear LB2120 (all that's available in Australia) seems to be working well. 
What a great solution!

Regards
Michael Knill

On 11/7/18, 10:16 pm, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi Michael,
    
    > Im just wondering whether there was any advantage in forcing the VPN to be across the 4G connection all the time?
    
    I started out with the WireGuard (WG) VPN over 4G connection all the time ... the LTE IP address was less dynamic, usually stayed with the same address, and if your LTE was iffy you could monitor the WG VPN and report if it was down.  If using "Bridge Mode" on the LTE modem this method offers a stable DHCP client address.
    
    But, I now (David Kerr and I discussed this) dynamically switch the WG VPN from using the PRIMARY (default, wired) route to the SECONDARY route.  One advantage here is my SECONDARY endpoint (Linode KVM) can be reached over a wired path when not on failover so it does not count on my LTE bill.  This is what I use:
    
    -- /mnt/kd/wan-failover.script snippet --
    SECONDARY)
      ## Switched to Failover using secondary WAN link
      ip route add "$linode_ip" dev $EXT2IF
      fping -q -t 1000 "$secondary_gw"
    
      asterisk -rx "sip reload" >/dev/null
      ;;
    
    PRIMARY)
      ## Switched back to normal using primary WAN link
      ip route del "$linode_ip" dev $EXT2IF
      fping -q -t 1000 "$secondary_gw"
    
      asterisk -rx "sip reload" >/dev/null
      ;;
    --
    Note, this requires a static "$linode_ip" which is what I have.
    
    I also have my LB1121 LTE modem set to router mode, using the WireGuard VPN it does not care if there is one or many levels of NAT involved.
    
    I have been very pleased with this LTE failover solution, and the base cost is $11 per month (no failover data) including the cost of the Linode KVM instance, which I expect I will use for other things as well.  Running AstLinux on Linode is quite cool.
    
    Lonnie
    
    
    
    > On Jul 11, 2018, at 5:08 AM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Lonnie
    > 
    > Im just wondering whether there was any advantage in forcing the VPN to be across the 4G connection all the time?
    > I set it up so it uses the Primary WAN under normal circumstances and it then re-establishes when it fails over to the 4G connection. It takes about a second or less to re-establish!
    > 
    > Pretty cool setup actually. Im looking forward to testing it out in production.
    > 
    > Regards
    > Michael Knill
    > 
    > On 6/6/18, 2:03 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    > 
    >    I have now more completely tested my WAN Failover using 4G/LTE over WireGuard ...and now works perfectly with Asterisk with a configuration change.
    > 
    >    My 4G/LTE over WireGuard tunnel endpoint is with AstLinux on a Linode KVM (as documented previously).  The AstLinux on the Linode KVM instance is not running Asterisk.
    > 
    >    Previously my local Asterisk was configured with nat=no and since I have a static IPv4 address my SIP provider has an option to authenticate using the static address (no registration).  If I added the static IPv4 of my Linode KVM instance it mostly worked for outbound calls during failover but would require failover call configuration at the SIP provided end to handle inbound calls.
    > 
    >    Instead, I switched my SIP provider configuration to require registration and removed my static IPv4 authentication.  In order to force a quick registration update on the switch I use the wan-failover.script to reload sip:
    > 
    >    -- /mnt/kd/wan-failover.script snippet --
    >      SECONDARY)
    >        ## Switched to Failover using secondary WAN link
    >        asterisk -rx "sip reload" >/dev/null
    >        ;;
    > 
    >      PRIMARY)
    >        ## Switched back to normal using primary WAN link
    >        asterisk -rx "sip reload" >/dev/null
    >        ;;
    >    --
    > 
    >    Almost there, but when failover occurs the registration is NAT'ed at the AstLinux on Linode KVM end, so for my SIP provider all it took was to configure my SIP account to support NAT.  Even though my Asterisk is still configured with nat=no, the registration via the failover tunnel now works.
    > 
    >    Inbound and outbound SIP calls work perfectly over the 4G/LTE failover.
    > 
    >    Most interestingly, the calls keep working during the failover switch and back again ... I was not expecting that, and I am still scratching my head over that.  The active calls do not miss a beat as I see data over my 4G/LTE and then no data over 4G/LTE, the call continues perfectly.  I even have directmedia=no in my provider peer's sip.conf.
    > 
    >    Lonnie
    > 
    > 
    > 
    >> On May 28, 2018, at 8:30 PM, Michael Knill <mic...@ip...> wrote:
    >> 
    >> I decided today the architecture I want to test.
    >> I will be setting up a DR Astlinux box running Asterisk and having a SIP Trunk with a 100 Block number range on it for indial.
    >> All Astklinux boxes configured for failover will establish a VPN to this box and a SIP Trunk to the DR server will be second choice for outgoing calls. I can set the Caller ID to be anything I want for DR outgoing so no issues there. Billing should be fine also as long as the Originating Caller ID is correct.
    >> All my providers allow the setting of a call forward on busy (and unreachable) to forward to one of the numbers in the 100 block which is redirected to the associated Astlinux box. So incoming calls are sorted also. If it's the same provider, then all forwarded calls are free.
    >> 
    >> I think it should work with no manual intervention required.
    >> 
    >> Regards
    >> Michael Knill
    >> 
    >> On 29/5/18, 10:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >> 
    >>   Hey Michael,
    >> 
    >>   Currently my "cloud" AstLinux Linode KVM (4G/LTE over VPN endpoint) has Asterisk disabled, ASTERISK_DAHDI_DISABLE="yes" so when my main AstLinux box goes to failover the SIP packets originate from my "home" WireGuard private 10.0.0.0/24 address and are NAT'ed at the Linode end.  Normally there is no NAT and SIP packets originate with my public IP.
    >> 
    >>   Surprisingly outbound calls work without any changes, though a remote hangup BYE is not received.  Inbound failover could be handled on my SIP provider's platform.
    >> 
    >>   I could enable Asterisk at the Linode end and use it as a proxy of sorts.
    >> 
    >>   Possibly better, per what you suggested, is to implement an outbound call failover in the "main" Asterisk regardless of the WAN Failover status ... if the standard outbound call fails it tries the call over the 4G/LTE VPN path.
    >> 
    >>   I'm still pondering my options.  The exact solution is somewhat dependent on the user's SIP provider.
    >> 
    >>   Lonnie
    >> 
    >> 
    >> 
    >> 
    >>> On May 28, 2018, at 5:08 PM, Michael Knill <mic...@ip...> wrote:
    >>> 
    >>> Hi Lonnie
    >>> 
    >>> So what are you trying to solve with Asterisk failover?
    >>> 
    >>> Regards
    >>> Michael Knill
    >>> 
    >>> On 28/5/18, 10:00 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
    >>> 
    >>>  Hi Michael,
    >>> 
    >>>  Yes, you can use OpenVPN and WireGuard at the same time, no problem.  I do.
    >>> 
    >>>  WireGuard is much faster / more efficient than OpenVPN, mostly since it resides in the kernel and can use multiple cores.  Here are some benchmarks I posted to the WireGuard mailing list:
    >>> 
    >>>  https://lists.zx2c4.com/pipermail/wireguard/2017-December/002204.html
    >>> 
    >>>  There are user-space implementations of WireGuard, written in Golang, starting to appear for testing, but for non-Linux endpoints I would stick with OpenVPN for now.
    >>> 
    >>>  BTW, I currently have WAN Failover on my production AstLinux box using the Netgear LB1121 4G/LTE over WireGuard VPN to a Linode KVM running AstLinux.  Working is dual stack IPv4/IPv6 failover for the AstLinux box itself and any internal network of my choosing.  I have outbound Asterisk failover working, but that is still a work in progress, not sure the best method yet.
    >>> 
    >>>  Lonnie
    >>> 
    >>> 
    >>> 
    >>> 
    >>>> On May 28, 2018, at 5:03 AM, Michael Knill <mic...@ip...> wrote:
    >>>> 
    >>>> Hi group
    >>>> 
    >>>> Im ready to do some testing.
    >>>> I have a number of sites that are set up as OpenVPN Servers. Should there be any issues using Wireguard as well?
    >>>> PS I just looked up Wireguard and I cant believe the difference in benchmarks to Open VPN. That's crazy!
    >>>> 
    >>>> Regards
    >>>> Michael Knill
    >>>> 
    >>>> On 24/5/18, 9:23 am, "Michael Knill" <mic...@ip...> wrote:
    >>>> 
    >>>> Thanks Lonnie. I don't have a specific scenario yet but handy to know its possible.
    >>>> 
    >>>> Regards
    >>>> Michael Knill
    >>>> 
    >>>> On 24/5/18, 8:54 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >>>> 
    >>>>     Michael,
    >>>> 
    >>>>> So are you saying that you can configure a second external interface and the associated routing to it with the Failover Tab but just leave Failover disabled?
    >>>> 
    >>>>     Yes, "External Failover Destination Routes:" automatically defines static routes, automatically removed and added for DHCP changes.
    >>>> 
    >>>> 
    >>>>> If so, I assume it uses the same EXT firewall rules?
    >>>> 
    >>>>     Yes.  There is a way to treat EXTIF and EXT2IF firewall rules differently, but the same is usually OK.
    >>>> 
    >>>>     Lonnie
    >>>> 
    >>>> 
    >>>> 
    >>>>> On May 23, 2018, at 5:17 PM, Michael Knill <mic...@ip...> wrote:
    >>>>> 
    >>>>> Hi Lonnie
    >>>>> 
    >>>>> So are you saying that you can configure a second external interface and the associated routing to it with the Failover Tab but just leave Failover disabled?
    >>>>> If so, I assume it uses the same EXT firewall rules?
    >>>>> 
    >>>>> Regards
    >>>>> Michael Knill
    >>>>> 
    >>>>> On 22/5/18, 8:59 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >>>>> 
    >>>>> Hi Michael,
    >>>>> 
    >>>>>> I noticed you also pass the VPN traffic to the site LAN
    >>>>> 
    >>>>> Yes, I tried to implement the general case, easy to remove stuff.
    >>>>> 
    >>>>>> the VPN would normally just be used for voice traffic and management only.
    >>>>> 
    >>>>> In that case "External Failover Destination Routes: IPv4 Routes:" could define all the destination routes you need without "Failover" enabled ... and let Asterisk dynamically choose the SIP route.  Handling inbound calls over the 4G/LTE VPN would also be possible.
    >>>>> 
    >>>>> 
    >>>>> All seems to work well, the only fundamental issue may be the latency of 4G/LTE for SIP traffic ... though clearly much better than no traffic.
    >>>>> 
    >>>>> Lonnie
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>>> On May 21, 2018, at 5:36 PM, Michael Knill <mic...@ip...> wrote:
    >>>>>> 
    >>>>>> Thanks Lonnie you beat me to it.
    >>>>>> Interestingly one of my partners is using Asterisk as their Softswitch and they were thinking of setting up a single VPN Tunnel to the SoftSwitch for voice traffic and so everything still works on both the primary and failover links. There should be no failover scripts required!
    >>>>>> 
    >>>>>> I noticed you also pass the VPN traffic to the site LAN but this would not actually be required in practice as the VPN would normally just be used for voice traffic and management only. On all VPN connections that run voice traffic I set directmedia=no in sip.conf. PS I actually now use a directmedia ACL on the VPN subnet so I don't need to configure anything. E.g.
    >>>>>> 
    >>>>>> directmedia=yes
    >>>>>> directmediapermit=0.0.0.0/0
    >>>>>> directmediadeny=<VPN Subnet>
    >>>>>> 
    >>>>>> Thanks again Lonnie for testing. Im looking forward to implementing it.
    >>>>>> 
    >>>>>> Regards
    >>>>>> Michael Knill
    >>>>>> 
    >>>>>> On 22/5/18, 6:59 am, "Lonnie Abelbeck" <li...@lo...> wrote:
    >>>>>> 
    >>>>>> Followup, Enabling Failover using a Netgear LB1121-100NAS (review below):
    >>>>>> 
    >>>>>> The basic failover configuration is documented here:
    >>>>>> 
    >>>>>> WAN Failover
    >>>>>> https://doc.astlinux-project.org/userdoc:tt_wan_failover
    >>>>>> 
    >>>>>> Since most 4G/LTE providers only support outbound-only (NAT'ed), IPv4-only, dynamic IPv4 address networks, any basic failover configuration over 4G/LTE must deal with those constraints.
    >>>>>> 
    >>>>>> But, there is another way ...
    >>>>>> 
    >>>>>> Enhanced WAN Failover using WireGuard:
    >>>>>> 
    >>>>>> If you are able to run a second AstLinux instance (or most any distro with WireGuard) on a static IPv4 address you can establish an always-up WireGuard VPN over the 4G/LTE connection.  When idle the VPN consumes less than 0.5 MB/day of data.
    >>>>>> 
    >>>>>> With this setup, both IPv4 and IPv6 can be supported as well as allowing inbound traffic to the failover.  When failover occurs, all the IPv4/IPv6 traffic is sent over the WireGuard VPN to the "Static" WireGuard endpoint.
    >>>>>> 
    >>>>>> To be clear, while the WireGuard VPN is established over IPv4-only, the tunnel can simultaneously transport IPv4 and IPv6.
    >>>>>> 
    >>>>>> Example:
    >>>>>> 
    >>>>>> AstLinux "4G/LTE": Cable/DSL Modem on external interface and 4G/LTE Modem on failover interface.
    >>>>>> --
    >>>>>> Internal 1st LAN IPv4: 192.168.101.1/255.255.255.0
    >>>>>> Internal 1st LAN IPv6: fda6:a6:a6:d2::1/64
    >>>>>> WireGuard IPv4: 10.4.1.10/255.255.255.0
    >>>>>> WireGuard IPv6: fda6:a6:a6:ff::10/64
    >>>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
    >>>>>> 
    >>>>>> AstLinux "Static": Static IPv4 (or IPv4/IPv6) on external interface.
    >>>>>> --
    >>>>>> Routable Public IPv4: 1.2.3.4
    >>>>>> WireGuard IPv4: 10.4.1.1/255.255.255.0
    >>>>>> WireGuard IPv6: fda6:a6:a6:ff::1/64
    >>>>>> IPv6 ULA/NPTv6: fda6:a6:a6::/56
    >>>>>> 
    >>>>>> 
    >>>>>> == AstLinux "4G/LTE" Endpoint Configuration
    >>>>>> 
    >>>>>> Network tab -> WireGuard Configuration:
    >>>>>> Tunnel Options:
    >>>>>>   IPv4 Address: 10.4.1.10
    >>>>>>   IPv4 NetMask: 255.255.255.0
    >>>>>>   IPv6/nn Address: fda6:a6:a6:ff::10/64
    >>>>>> 
    >>>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
    >>>>>> [Peer]
    >>>>>> ## 4G/LTE Endpoint
    >>>>>> PublicKey = <For Static Endpoint>
    >>>>>> Endpoint = 1.2.3.4:51820
    >>>>>> AllowedIPs = 0.0.0.0/0, ::/0
    >>>>>> PersistentKeepalive = 25
    >>>>>> --
    >>>>>> 
    >>>>>> Network tab -> WAN Failover Configuration:
    >>>>>> WAN Failover:
    >>>>>>   Failover: [enabled]
    >>>>>>   Secondary Gateway IPv4: 10.4.1.1
    >>>>>>   Secondary Gateway IPv6: fda6:a6:a6:ff::1
    >>>>>> 
    >>>>>> External Failover Interface:
    >>>>>>   Connection Type: [DHCP]
    >>>>>> 
    >>>>>> External Failover Destination Routes: 
    >>>>>>   IPv4 Routes: 192.168.5.0/24 1.2.3.4
    >>>>>> 
    >>>>>> 
    >>>>>> Network tab -> Firewall Configuration:
    >>>>>> Firewall Options:
    >>>>>>   _x_ Allow WireGuard VPN tunnel to the [1st] LAN Interface(s)
    >>>>>> 
    >>>>>> 
    >>>>>> == AstLinux "Static" Endpoint Configuration
    >>>>>> 
    >>>>>> Network tab -> WireGuard Configuration:
    >>>>>> Tunnel Options:
    >>>>>>   IPv4 Address: 10.4.1.1
    >>>>>>   IPv4 NetMask: 255.255.255.0
    >>>>>>   IPv6/nn Address: fda6:a6:a6:ff::1/64
    >>>>>> 
    >>>>>> 
    >>>>>> -- /mnt/kd/wireguard/peer/wg0.peer snippet --
    >>>>>> [Peer]
    >>>>>> ## Static Endpoint
    >>>>>> PublicKey = <For 4G/LTE Endpoint>
    >>>>>> AllowedIPs = 10.4.1.10/32, 192.168.101.0/24, fda6:a6:a6:ff::10/128, fda6:a6:a6:d2::/64
    >>>>>> --
    >>>>>> 
    >>>>>> -- /mnt/kd/rc.conf.d/user.conf snippet --
    >>>>>> NAT_FOREIGN_NETWORK="192.168.101.0/24"
    >>>>>> --
    >>>>>> 
    >>>>>> ==
    >>>>>> 
    >>>>>> I personally tested this scenario and it worked as expected.
    >>>>>> 
    >>>>>> Note that one AstLinux "Static" server can support many remote failover AstLinux "4G/LTE" boxes.
    >>>>>> 
    >>>>>> Tip: if you have shell access to AstLinux "Static", 'ssh root@10.4.1.10' will access AstLinux "4G/LTE" over the VPN connection, regardless if failover is active.
    >>>>>> 
    >>>>>> Lonnie
    >>>>>> 
    >>>>>> 
    >>>>>> 
    >>>>>> 
    >>>>>> 
    >>>>>> ==================================
    >>>>>> Per a post by Michael Knill "4G backup" I purchased a Netgear LB1121-100NAS (North America) supporting PoE and includes a power adapter.
    >>>>>> 
    >>>>>> LTE Modem LB1120 and LB1121 User Manual
    >>>>>> https://www.downloads.netgear.com/files/GDC/LB1120/LB112x_UM_EN.pdf
    >>>>>> 
    >>>>>> Overall, I'm pleased with the LB1121, the PoE is good to have, makes easy positioning for good reception.
    >>>>>> 
    >>>>>> I also tested the Netgear 6000450 MIMO Antenna, it can add 1-bar, but with no antenna and 4 out of 5 bars sitting on the lab bench I was able to get 90/20 Mbps (down/up) on a speed test.
    >>>>>> 
    >>>>>> If a person were to mount the modem on a wall next to a window, the antenna would be useful to reach over and place on the glass.
    >>>>>> 
    >>>>>> I tested with "Ting" a MVNO (Mobile Virtual Network Operator) for T-Mobile's GSM network.  I ordered a GSM SIM card from Ting, the Netgear LB1121 comes with an empty SIM slot.
    >>>>>> 
    >>>>>> I connected the Netgear LB1121 to a spare ethernet interface, Network tab -> Failover Interface: [eth2] and also ...
    >>>>>> -- Network tab -> WAN Failover Configuration: --
    >>>>>> External Failover Interface:
    >>>>>> Connection Type: [DHCP]
    >>>>>> 
    >>>>>> External Failover Destination Routes:
    >>>>>> IPv4 Routes: 192.168.5.0/24
    >>>>>> --
    >>>>>> If you change the LB1121's IPv4 address, also change the above IPv4 Routes: as this is required when the LB1121 is set to "Bridge Mode".
    >>>>>> Note: WAN Failover is disabled at this point in time.  We are now simply defining a 2nd external interface.
    >>>>>> 
    >>>>>> With Ting I needed to edit the APN ...
    >>>>>> --
    >>>>>> Ting (GSM) T-Mobile
    >>>>>> APN: wholesale
    >>>>>> --
    >>>>>> and the LB1121 easily allows for that via the web interface, which defaults to http://192.168.5.1
    >>>>>> 
    >>>>>> Firmware updates are via the web interface, but you must have a SIM card activated and installed to perform an upgrade over the GSM network.
    >>>>>> 
    >>>>>> Web interface password changes don't ask for a match, so a typo requires a reset to factory defaults to fix it.  But overall, the web interface is nicely done.
    >>>>>> 
    >>>>>> After I got the LB1121 configured as desired, working, and firmware upgraded, I then switched to "Bridge Mode", depending on your 4G/LTE carrier your DHCP will acquire a publicly routable IPv4 address or an address that looks public but is actually behind NAT.
    >>>>>> BTW: Ting/T-Mobile uses odd "private" address ranges like 25.0.0.0/8 (UK Ministry of Defense) and 100.128.0.0/9 (T-Mobile), they look publicly routable, but they are NAT'ed to a different public address :-(
    >>>>>> 
    >>>>>> On a PoE 802.3af switch, the LB1121 draws 1.1 Watts, cool to the touch.
    >>>>>> 
    >>>>>> The main issues are the 4G/LTE networks, the Ting MVNO for T-Mobile is IPv4 only, and NAT'ed even when in bridge mode.  So a true failover is difficult to do, but by limiting your failover requirements this can still be useful.  Below is one such technique using WireGuard VPN.
    >>>>>> 
    >>>>>> I have a test AstLinux box talking to my main AstLinux box over WireGuard over 4G/LTE ... works nicely.  Though "PersistentKeepalive = 25" is required to deal with the NAT and dynamic addressing.
    >>>>>> 
    >>>>>> FYI: Interestingly, the WireGuard overhead even with a keepalive every 25 seconds results in 454 KB/day of data, which at $10/GB is only 0.00454 $/day.
    >>>>>> 
    >>>>>> == Dynamic 4G/LTE Modem Endpoint
    >>>>>> 
    >>>>>> -- WireGuard IPv4 10.4.1.10/255.255.255.0 --
    >>>>>> [Peer]
    >>>>>> ## 4G/LTE Endpoint
    >>>>>> PublicKey = <For Static Endpoint>
    >>>>>> Endpoint = 1.2.3.4:51820
    >>>>>> AllowedIPs = 10.4.1.1/32
    >>>>>> PersistentKeepalive = 25
    >>>>>> --
    >>>>>> 
    >>>>>> -- Network tab -> WAN Failover Configuration: --
    >>>>>> External Failover Interface:
    >>>>>> Connection Type: [DHCP]
    >>>>>> 
    >>>>>> External Failover Destination Routes:
    >>>>>> IPv4 Routes: 192.168.5.0/24 1.2.3.4
    >>>>>> --
    >>>>>> 
    >>>>>> == Static IPv4 1.2.3.4 Endpoint
    >>>>>> 
    >>>>>> -- WireGuard IPv4 10.4.1.1/255.255.255.0 --
    >>>>>> [Peer]
    >>>>>> ## Static Endpoint
    >>>>>> PublicKey = <For 4G/LTE Endpoint>
    >>>>>> AllowedIPs = 10.4.1.10/32
    >>>>>> --
    >>>>>> 
    >>>>>> iperf3 test across the VPN ...
    >>>>>> 
    >>>>>> 4G/LTE ~ # iperf3 -s
    >>>>>> 
    >>>>>> Static ~ # iperf3 -c 10.4.1.10 -u
    >>>>>> Connecting to host 10.4.1.10, port 5201
    >>>>>> [  5] local 10.4.1.1 port 37415 connected to 10.4.1.10 port 5201
    >>>>>> [ ID] Interval           Transfer     Bitrate         Total Datagrams
    >>>>>> [  5]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec  96  
    >>>>>> ...
    >>>>>> [  5]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  96  
    >>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
    >>>>>> [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
    >>>>>> [  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/959 (0%)  sender
    >>>>>> [  5]   0.00-10.16  sec  1.25 MBytes  1.03 Mbits/sec  2.543 ms  0/959 (0%)  receiver
    >>>>>> 
    >>>>>> 
    >>>>>> Typical ping times: 100-400 ms
    >>>>>> 
    >>>>>> Note that without the VPN there would be no way to reach "4G/LTE" from "Static" with the network NAT issues described above.
    >>>>>> 
    >>>>>> So with a Netgear LB1121 4G/LTE Modem, by using this WireGuard VPN technique on the "Failover Interface" (2nd External) your public server on 1.2.3.4 will be able to access a remote AstLinux box via 4G/LTE.
    >>>>>> 
    >>>>>> 
    >>>>>> Lonnie
    >>>>>> 
    >>>>>> 
    >>>>>> ------------------------------------------------------------------------------
    >>>>>> 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....
    >>>>> 
    >>>>> 
    >>>>> ------------------------------------------------------------------------------
    >>>>> 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....
    >>>> 
    >>>> 
    >>>>     ------------------------------------------------------------------------------
    >>>>     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....
    >>>> 
    >>>> ------------------------------------------------------------------------------
    >>>> 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....
    >>> 
    >>> ------------------------------------------------------------------------------
    >>> 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....
    >> 
    >> ------------------------------------------------------------------------------
    >> 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....
    > 
    > ------------------------------------------------------------------------------
    > 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....

Re: [Astlinux-users] Astlinux SMTP Relay Issue With Gmail

[Cody A. <ald...@gm...>]

Lonnie,

Found it. I must have originally misread that as referring to a subject
line instead of an email address though it plainly says email address. I
think my mindset was that there would not be a "from" email address and
only a "to" since it was originating from Astlinux. Now I am not
understanding how I was getting emails or had a successful TEST SMTP Mail
relay work before with that invalid line in Safe Asterisk and Sip
Monitoring. I would have never noticed it if it were not for changing the
password and testing again. I actually learned a long time ago to read
EVERY word, space, punctuation and symbol on the screen when there was a
problem and failed follow what I had already learned. Thank you all for
your help. I did learn how to integrate two-factor authentication instead
of leaving the less secure app options on in Google. So, this was not a
waste of time.

Thank you,

Cody

On Thu, Jul 12, 2018 at 5:45 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi Cody,
>
> The "From Email (Optional)" field defaults to the Network tab settings ...
> SAFE_ASTERISK_NOTIFY_FROM, or if not defined then UPS_NOTIFY_FROM .
>
> BTW, If the email address field is of the form: name <fo...@ex...>
> Then the resulting email address is stripped to be just:
> fo...@ex...
>
> So, look at your ...
>
> Network tab -> Safe Asterisk & SIP Monitoring: -> Notify Email Address
> From:
> -- or --
> Network tab -> UPS Monitoring & Shutdown: -> Notify Email Address From:
>
> it looks like you have an invalid "From" email address defined.
>
> Lonnie
>
>

Re: [Astlinux-users] Astlinux SMTP Relay Issue With Gmail

[Lonnie A. <li...@lo...>]

Hi Cody,

The "From Email (Optional)" field defaults to the Network tab settings ... SAFE_ASTERISK_NOTIFY_FROM, or if not defined then UPS_NOTIFY_FROM .

BTW, If the email address field is of the form: name <fo...@ex...>
Then the resulting email address is stripped to be just: fo...@ex...

So, look at your ...

Network tab -> Safe Asterisk & SIP Monitoring: -> Notify Email Address From:
-- or --
Network tab -> UPS Monitoring & Shutdown: -> Notify Email Address From:

it looks like you have an invalid "From" email address defined.

Lonnie



> On Jul 12, 2018, at 4:04 PM, Cody Alderson <ald...@gm...> wrote:
> 
> Part my error . . . I guess.
> 
> Did the second field of the Test SMTP Mail Relay used to be a subject line and not a "From Email (Optional)" field? Mine is defaulting to fill in "AstLinux On HP Thin Client" that I would have put in as a subject line not as a "from" email address. Note that I had no issues until I changed my email address password and updated it in Astlinux and tested. I remember testing when I first set it up and did not have a problem. The second field in the Test SMTP Mail Relay is expecting an email address. Since I saw my email subject line, I ignored reading what the title of the field actually was. I used to get email notifications for things, and I remember setting a subject line somewhere. Now I cannot get the "AstLinux On HP Thin Client" to not repopulate in the "From Email (Optional)" field. How do I get this field to be blank now? It defaults back to Astlinux On HP Thin Client after I clear it and hit send or return to the Test SMTP Mail relay screen again.
> 
> Thank you for your patience.
> 
> Cody
> 
> On Thu, Jul 12, 2018 at 9:22 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi Cody,
> 
> I tried this myself ...
> 
> Assume:
> --
> Google username: foobar
> Google password: SuperSecret
> GMail address: fo...@gm...
> Google Account -> Sign-in & Security -> Apps with account access -> Allow less secure apps: ON
> --
> Ref: https://support.google.com/a/answer/176600?hl=en
> 
> Note: user.conf SMTP_FROM is *not* defined.
> 
> Network tab -> Outbound SMTP Mail Relay:
> --
> SMTP Server: smtp.gmail.com
> SMTP Domain: gmail.com
> SMTP Authentication: [plain]
> SMTP Port: 587
> SMTP Encryption: TLS/STARTTLS - [Check Cert]
> SMTP Cert File: 
> SMTP Username: foobar
> SMTP Password: SuperSecret
> --
> 
> No rebooting or restarting required to test, simply click:
> Network tab -> Outbound SMTP Mail Relay: {Test SMTP mail Relay}
> 
> The above worked perfectly for me.
> 
> If you continue to have issues, you could try the latest AstLinux pre-prelease [1] which contains a newer "msmtp" version.
> 
> Lonnie
> 
> [1] https://www.astlinux-project.org/dev.html
> 

Re: [Astlinux-users] Astlinux SMTP Relay Issue With Gmail

[Cody A. <ald...@gm...>]

Part my error . . . I guess.

Did the second field of the Test SMTP Mail Relay used to be a subject line
and not a "From Email *(Optional)*" field? Mine is defaulting to fill in
"AstLinux On HP Thin Client" that I would have put in as a subject line not
as a "from" email address. Note that I had no issues until I changed my
email address password and updated it in Astlinux and tested. I remember
testing when I first set it up and did not have a problem. The second field
in the Test SMTP Mail Relay is expecting an email address. Since I saw my
email subject line, I ignored reading what the title of the field actually
was. I used to get email notifications for things, and I remember setting a
subject line somewhere. Now I cannot get the "AstLinux On HP Thin Client"
to not repopulate in the "From Email *(Optional)*" field. How do I get this
field to be blank now? It defaults back to Astlinux On HP Thin Client after
I clear it and hit send or return to the Test SMTP Mail relay screen again.

Thank you for your patience.

Cody

On Thu, Jul 12, 2018 at 9:22 AM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi Cody,
>
> I tried this myself ...
>
> Assume:
> --
> Google username: foobar
> Google password: SuperSecret
> GMail address: fo...@gm...
> Google Account -> Sign-in & Security -> Apps with account access -> Allow
> less secure apps: ON
> --
> Ref: https://support.google.com/a/answer/176600?hl=en
>
> Note: user.conf SMTP_FROM is *not* defined.
>
> Network tab -> Outbound SMTP Mail Relay:
> --
> SMTP Server: smtp.gmail.com
> SMTP Domain: gmail.com
> SMTP Authentication: [plain]
> SMTP Port: 587
> SMTP Encryption: TLS/STARTTLS - [Check Cert]
> SMTP Cert File:
> SMTP Username: foobar
> SMTP Password: SuperSecret
> --
>
> No rebooting or restarting required to test, simply click:
> Network tab -> Outbound SMTP Mail Relay: {Test SMTP mail Relay}
>
> The above worked perfectly for me.
>
> If you continue to have issues, you could try the latest AstLinux
> pre-prelease [1] which contains a newer "msmtp" version.
>
> Lonnie
>
> [1] https://www.astlinux-project.org/dev.html
>
>
>
> > On Jul 11, 2018, at 11:11 PM, Cody Alderson <ald...@gm...>
> wrote:
> >
> > Lonnie,
> >
> > Everything I have been reading indicates to use the full address, but I
> tried it without as you indicates. Note that I saved the settings and
> rebooted. Still same message when attempting to test the SMTP relay. Maybe
> Gmail has changed something other than need to turn on allow access to less
> secure apps? I'll try another email server in the morning. So far nothing
> is working to get it functional again.
> >
> > Thanks all for your help.
> >
> > Cody
> >
> > On Wed, Jul 11, 2018 at 7:37 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> >
> > > On Jul 11, 2018, at 3:28 AM, Michael Keuter <li...@mk...>
> wrote:
> > >
> > >
> > >> Am 11.07.2018 um 07:14 schrieb Cody Alderson <ald...@gm...
> >:
> > >>
> > >> Hi,
> > >>
> > >> I changed my Gmail password and updated it using the Network tab and
> Outbound SMTP Mail Relay in Astlinux. I did not change anything else in
> Astlinux except the updating to the correct password, saving the settings
> and rebooting.
> > >>
> > >> These are my settings. For purposes of this email, I put "nothing
> entered in this field" where the field is blank, and I only explain what is
> in the username/password fields for security reasons.
> > >>
> > >> SMTP Server: smtp.gmail.com
> > >> SMTP Domain: nothing entered in this field
> > >> SMTP Authentication: login
> > >> SMTP Port: 465
> > >> SMTP Encryption: SSL/SMTP – Ignore Cert
> > >> SMTP Cert File: nothing entered in this field
> > >> SMTP Username: my full gmail email address
> > >> SMTP Password: my password
> > >>
> > >> When I press Test SMTP Mail Relay and then Send Test Email, I get
> "invalid email address."
> > >>
> > >> Any suggestions as to the cause? Could it have anything to do with
> Gmail's "access to less secure apps" setting?
> > >>
> > >> Thank you,
> > >>
> > >> Cody
> > >
> > > Hi Cody,
> > >
> > > try using in your user.conf:
> > >
> > > SMTP_FROM="your-gmail-address"
> > >
> > > also:
> > > SMTP Domain: gmail.com
> > >
> > > You could also try TLS on port 587 (and check the cert).
> > > Yes, I guess the "access to less secure apps" setting may need to be
> enabled.
> > >
> > > https://www.lifewire.com/what-are-the-gmail-smtp-settings-1170854
> > >
> > > Michael
> >
> > Here is another reference, look for "Gmail SMTP server"
> > https://support.google.com/a/answer/176600?hl=en
> >
> > My hunch is for "SMTP Username" you are using your full fo...@gm...
> address, but it only wants "foobar"
> >
> > Lonnie
> > ------------------------------------------------------------
> ------------------
>
>
> ------------------------------------------------------------
> ------------------
> 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....
>

Re: [Astlinux-users] Astlinux SMTP Relay Issue With Gmail

[Bart T. <bar...@gm...>]

Hi,

I have had the same issue. In my case I can confirm that the settings
Lonnie provided work fine, BUT, because I have 2FA enabled on my Gmail
account I need to generate and use an App password (also under the same
account settings area as directed by Lonnie), NOT my Google password. As
soon as I did that it just worked. :-)

Hope this helps.

Kind regards,
Bart.




On Fri, 13 Jul 2018, 01:23 Lonnie Abelbeck, <li...@lo...>
wrote:

> Hi Cody,
>
> I tried this myself ...
>
> Assume:
> --
> Google username: foobar
> Google password: SuperSecret
> GMail address: fo...@gm...
> Google Account -> Sign-in & Security -> Apps with account access -> Allow
> less secure apps: ON
> --
> Ref: https://support.google.com/a/answer/176600?hl=en
>
> Note: user.conf SMTP_FROM is *not* defined.
>
> Network tab -> Outbound SMTP Mail Relay:
> --
> SMTP Server: smtp.gmail.com
> SMTP Domain: gmail.com
> SMTP Authentication: [plain]
> SMTP Port: 587
> SMTP Encryption: TLS/STARTTLS - [Check Cert]
> SMTP Cert File:
> SMTP Username: foobar
> SMTP Password: SuperSecret
> --
>
> No rebooting or restarting required to test, simply click:
> Network tab -> Outbound SMTP Mail Relay: {Test SMTP mail Relay}
>
> The above worked perfectly for me.
>
> If you continue to have issues, you could try the latest AstLinux
> pre-prelease [1] which contains a newer "msmtp" version.
>
> Lonnie
>
> [1] https://www.astlinux-project.org/dev.html
>
>
>
> > On Jul 11, 2018, at 11:11 PM, Cody Alderson <ald...@gm...>
> wrote:
> >
> > Lonnie,
> >
> > Everything I have been reading indicates to use the full address, but I
> tried it without as you indicates. Note that I saved the settings and
> rebooted. Still same message when attempting to test the SMTP relay. Maybe
> Gmail has changed something other than need to turn on allow access to less
> secure apps? I'll try another email server in the morning. So far nothing
> is working to get it functional again.
> >
> > Thanks all for your help.
> >
> > Cody
> >
> > On Wed, Jul 11, 2018 at 7:37 AM, Lonnie Abelbeck <
> li...@lo...> wrote:
> >
> > > On Jul 11, 2018, at 3:28 AM, Michael Keuter <li...@mk...>
> wrote:
> > >
> > >
> > >> Am 11.07.2018 um 07:14 schrieb Cody Alderson <ald...@gm...
> >:
> > >>
> > >> Hi,
> > >>
> > >> I changed my Gmail password and updated it using the Network tab and
> Outbound SMTP Mail Relay in Astlinux. I did not change anything else in
> Astlinux except the updating to the correct password, saving the settings
> and rebooting.
> > >>
> > >> These are my settings. For purposes of this email, I put "nothing
> entered in this field" where the field is blank, and I only explain what is
> in the username/password fields for security reasons.
> > >>
> > >> SMTP Server: smtp.gmail.com
> > >> SMTP Domain: nothing entered in this field
> > >> SMTP Authentication: login
> > >> SMTP Port: 465
> > >> SMTP Encryption: SSL/SMTP – Ignore Cert
> > >> SMTP Cert File: nothing entered in this field
> > >> SMTP Username: my full gmail email address
> > >> SMTP Password: my password
> > >>
> > >> When I press Test SMTP Mail Relay and then Send Test Email, I get
> "invalid email address."
> > >>
> > >> Any suggestions as to the cause? Could it have anything to do with
> Gmail's "access to less secure apps" setting?
> > >>
> > >> Thank you,
> > >>
> > >> Cody
> > >
> > > Hi Cody,
> > >
> > > try using in your user.conf:
> > >
> > > SMTP_FROM="your-gmail-address"
> > >
> > > also:
> > > SMTP Domain: gmail.com
> > >
> > > You could also try TLS on port 587 (and check the cert).
> > > Yes, I guess the "access to less secure apps" setting may need to be
> enabled.
> > >
> > > https://www.lifewire.com/what-are-the-gmail-smtp-settings-1170854
> > >
> > > Michael
> >
> > Here is another reference, look for "Gmail SMTP server"
> > https://support.google.com/a/answer/176600?hl=en
> >
> > My hunch is for "SMTP Username" you are using your full fo...@gm...
> address, but it only wants "foobar"
> >
> > Lonnie
> >
> ------------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> 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....

Re: [Astlinux-users] Astlinux SMTP Relay Issue With Gmail

[Lonnie A. <li...@lo...>]

Hi Cody,

I tried this myself ...

Assume:
--
Google username: foobar
Google password: SuperSecret
GMail address: fo...@gm...
Google Account -> Sign-in & Security -> Apps with account access -> Allow less secure apps: ON
--
Ref: https://support.google.com/a/answer/176600?hl=en

Note: user.conf SMTP_FROM is *not* defined.

Network tab -> Outbound SMTP Mail Relay:
--
SMTP Server: smtp.gmail.com
SMTP Domain: gmail.com
SMTP Authentication: [plain]
SMTP Port: 587
SMTP Encryption: TLS/STARTTLS - [Check Cert]
SMTP Cert File: 
SMTP Username: foobar
SMTP Password: SuperSecret
--

No rebooting or restarting required to test, simply click:
Network tab -> Outbound SMTP Mail Relay: {Test SMTP mail Relay}

The above worked perfectly for me.

If you continue to have issues, you could try the latest AstLinux pre-prelease [1] which contains a newer "msmtp" version.

Lonnie

[1] https://www.astlinux-project.org/dev.html



> On Jul 11, 2018, at 11:11 PM, Cody Alderson <ald...@gm...> wrote:
> 
> Lonnie,
> 
> Everything I have been reading indicates to use the full address, but I tried it without as you indicates. Note that I saved the settings and rebooted. Still same message when attempting to test the SMTP relay. Maybe Gmail has changed something other than need to turn on allow access to less secure apps? I'll try another email server in the morning. So far nothing is working to get it functional again.
> 
> Thanks all for your help.
> 
> Cody
> 
> On Wed, Jul 11, 2018 at 7:37 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> > On Jul 11, 2018, at 3:28 AM, Michael Keuter <li...@mk...> wrote:
> > 
> > 
> >> Am 11.07.2018 um 07:14 schrieb Cody Alderson <ald...@gm...>:
> >> 
> >> Hi,
> >> 
> >> I changed my Gmail password and updated it using the Network tab and Outbound SMTP Mail Relay in Astlinux. I did not change anything else in Astlinux except the updating to the correct password, saving the settings and rebooting.
> >> 
> >> These are my settings. For purposes of this email, I put "nothing entered in this field" where the field is blank, and I only explain what is in the username/password fields for security reasons.
> >> 
> >> SMTP Server: smtp.gmail.com
> >> SMTP Domain: nothing entered in this field
> >> SMTP Authentication: login
> >> SMTP Port: 465
> >> SMTP Encryption: SSL/SMTP – Ignore Cert
> >> SMTP Cert File: nothing entered in this field
> >> SMTP Username: my full gmail email address
> >> SMTP Password: my password
> >> 
> >> When I press Test SMTP Mail Relay and then Send Test Email, I get "invalid email address."
> >> 
> >> Any suggestions as to the cause? Could it have anything to do with Gmail's "access to less secure apps" setting?
> >> 
> >> Thank you,
> >> 
> >> Cody
> > 
> > Hi Cody,
> > 
> > try using in your user.conf:
> > 
> > SMTP_FROM="your-gmail-address"
> > 
> > also:
> > SMTP Domain: gmail.com
> > 
> > You could also try TLS on port 587 (and check the cert).
> > Yes, I guess the "access to less secure apps" setting may need to be enabled.
> > 
> > https://www.lifewire.com/what-are-the-gmail-smtp-settings-1170854
> > 
> > Michael
> 
> Here is another reference, look for "Gmail SMTP server"
> https://support.google.com/a/answer/176600?hl=en
> 
> My hunch is for "SMTP Username" you are using your full fo...@gm... address, but it only wants "foobar"
> 
> Lonnie
> ------------------------------------------------------------------------------