astlinux-devel Mailing List for AstLinux

Update,

I performed more testing and things look good with the x86_64 images.

First, an almost perfect test whether x86_64 is supported is if the 'lm' ("Long Mode" CPUID flag) is set, if there is output with this command, x86_64 should be supported.
--
grep '^flags.* lm ' /proc/cpuinfo
--
If there is no output, x86_64 is not supported.
Tip added to: http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64

Here is a list of boxes I have AstLinux x86_64 images running, and one not x86_64.

## x86_64 ##

Lanner FW-7541D
Jetway JBC373F38W
Intel(R) Atom(TM) CPU D525   @ 1.80GHz

OEM Production 2550L2D-MxPC (MINIX)
Intel(R) Atom(TM) CPU D2550   @ 1.86GHz

Lanner NCA-1010B
Intel(R) Atom(TM) CPU  E3825  @ 1.33GHz

Jetway NF9HG-2930
Intel(R) Celeron(R) CPU  N2930  @ 1.83GHz

Lanner FW-7525B
Intel(R) Atom(TM) CPU  C2358  @ 1.74GHz

## NOT x86_64 ##

Lanner LEC-7220-N4
Intel(R) Atom(TM) CPU N2800   @ 1.86GHz

##

Note that the Atom N2800 (Cedarview Series):  http://ark.intel.com/products/codename/37505/Cedarview#@All
is hit-and-miss if 64-bit is enabled. There was in issue with the HD video driver support with 64-bit enabled, as such some OEM's decided to limit those boards to 32-bit only.

Though my Synology Diskstation 713+ is x86_64 and a Cedarview Series (and the 'lm' flag is set)
Intel(R) Atom(TM) CPU D2701   @ 2.13GHz

So far, checking whether the 'lm' ("Long Mode" CPUID flag) is set is a great indication that x86_64 is supported.

Lonnie

On Nov 28, 2015, at 7:54 PM, Lonnie Abelbeck <li...@lo...> wrote:

> 
> On Nov 28, 2015, at 5:30 PM, Lonnie Abelbeck <li...@lo...> wrote:
> 
>> Update,
>> 
>> ipsec-tools (racoon) segfaults with x86_64
>> 
>> Looking for a solution...
>> 
>> Lonnie
> 
> I narrowed down the problem to the function call "plog", this patch makes IPsec work for x86_64...
> 
> --- ipsec-tools-0.8.2/src/racoon/plog.c.orig	2015-11-28 19:23:45.000000000 -0600
> +++ ipsec-tools-0.8.2/src/racoon/plog.c	2015-11-28 19:24:07.000000000 -0600
> @@ -167,6 +167,7 @@
> void
> _plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...)
> {
> +return;
> 	va_list ap;
> 
> 	va_start(ap, fmt);
> 
> --
> But also disables all logging... :-(
> 
> So far I have not been able to isolate this further, possibly others here can beat me to a solution.
> 
> Sadly ipsec-tools does not seem to be actively developed.
> 
> Lonnie

Fixed in r7358
ipsec-tools, build with 'ac_cv_va_copy=yes' so the generic workaround (fails on x86_64) is not used.

The configure script tries to determine if the C-compiler supports the "va_copy()" call, but can't while cross-compiling so it defaults to a generic workaround in that case.  That workaround does not work with x86_64.

The solution is to build with 'ac_cv_va_copy=yes' since we have va_copy().

Lonnie

On Nov 28, 2015, at 5:30 PM, Lonnie Abelbeck <li...@lo...> wrote:

> Update,
> 
> ipsec-tools (racoon) segfaults with x86_64
> 
> Looking for a solution...
> 
> Lonnie

I narrowed down the problem to the function call "plog", this patch makes IPsec work for x86_64...

--- ipsec-tools-0.8.2/src/racoon/plog.c.orig	2015-11-28 19:23:45.000000000 -0600
+++ ipsec-tools-0.8.2/src/racoon/plog.c	2015-11-28 19:24:07.000000000 -0600
@@ -167,6 +167,7 @@
 void
 _plog(int pri, const char *func, struct sockaddr *sa, const char *fmt, ...)
 {
+return;
 	va_list ap;
 
 	va_start(ap, fmt);

--
But also disables all logging... :-(

So far I have not been able to isolate this further, possibly others here can beat me to a solution.

Sadly ipsec-tools does not seem to be actively developed.

Lonnie

Update,

ipsec-tools (racoon) segfaults with x86_64

Looking for a solution...

Lonnie

Hi David,

Yes, your APU1 is x86_64, but you would be the first to try it as far as I know.

I totally understand not testing on your production system :-)

But, if you are so inclined...

If you want, as a safety net, save your current initrd.img before upgrading to x86_64...
--
mount -o rw,remount /oldroot/cdrom
cp /oldroot/cdrom/os/initrd.img /oldroot/cdrom/os/initrd.img.i586
mount -o ro,remount /oldroot/cdrom
--

Then export any LDAP data if needed per:  http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64

Then do the upgrade-run-image stuff...
--
upgrade-run-image 
Usage: upgrade-run-image check|upgrade|show|revert firmware_repository_url [32|64]

upgrade-run-image upgrade http://bla-bla.tld/beta-firmware-1.x 64
--

reboot

If, something goes wrong, attach a serial console cable and type "shell" at the RUNNIX prompt...
--
## Restore the i586 initrd image
cp /mnt/base/os/initrd.img.i586 /mnt/base/os/initrd.img
## Revert to your previous i586 run image
cp /mnt/base/os/ver /mnt/base/os/ver.save
cp /mnt/base/os/Xver /mnt/base/os/ver
mv /mnt/base/os/ver.save /mnt/base/os/Xver
sync
## exit to reboot
exit
--
You should be back running your previous i586 image.

Finally, if you are building your own custom images, be very sure to keep the ".config" you are using properly associated with the geni586-serial build and a genx86_64-serial build and file those away in your private repository.

Note: The initrd.img file will be automatically [re-]generated by looking at the architecture in your ".config", so the initrd and run image will always track with the same architecture.

Lonnie


On Nov 27, 2015, at 9:30 PM, David Kerr <Da...@Ke...> wrote:

> So, before I try anything silly.... is my PC Engines APU board 64-bit?  I think so... it says AMD G series T40E APU, 1GHz dual core with 64 bit support. at the PC Engines web page.  Have you tried it on the APU board or will I be in uncharted territory?  (If things go bad I loose internet/phone at my home!!!)
> 
> David 
> 
> On Fri, Nov 27, 2015 at 11:59 AM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi Devs,
> 
> I personally "upgraded" my main AstLinux box to x86_64, it is a Lanner FW-7541D Atom D525.  So far at "1 day, 16 hours" and 9.5 GB of internet network traffic, no issues.
> 
> You can build your own custom image, or the Custom Build Engine http://build.astlinux.org for SVN builds has a new "Architecture: [ x86_64 multi-core ]" option.
> 
> For those of you with your own custom builds, no need to rebuild crosstool-ng, just go into your existing ctng-1.20.0-3.2 directory and jump to "## Build x86_64 64-bit toolchain ##" in the crosstool-ng-src/README.
> 
> 
> Over the next month or two, before we release AstLinux 1.2.5, we all should think about how to guide users which architecture to use.  Possibly...
> 
> 1) New installs with 64-bit CPU and 2+ GB RAM use x86_64 ?
> 
> 2) Virtual machines, since all VM hosts are x86_64, would a x86_64 image run more efficiently ?  or does the somewhat lower memory usage of i586 the deciding factor ?
> 
> 3) Leave existing installs alone (except for testing)
> 
> 
> For those who want to test x86_64, we put together a WiKi entry for switching an existing i586 system to x86_64...
> 
> Switching Images between i586 and x86_64
> http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64
> 
> 
> Attached is a comparison of 2GB RAM AstLinux i586, 2GB RAM AstLinux x86_64 and for reference 1GB RAM Synology Diskstation (x86_64 synology_cedarview_713+) systems.
> 
> Most interesting is how the RAM is used.
> 
> Lonnie
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

So, before I try anything silly.... is my PC Engines APU board 64-bit?  I
think so... it says *AMD G series T40E APU, 1GHz dual core with 64 bit
support.* at the PC Engines web page.  Have you tried it on the APU board
or will I be in uncharted territory?  (If things go bad I loose
internet/phone at my home!!!)

David

On Fri, Nov 27, 2015 at 11:59 AM, Lonnie Abelbeck <li...@lo...
> wrote:

> Hi Devs,
>
> I personally "upgraded" my main AstLinux box to x86_64, it is a Lanner
> FW-7541D Atom D525.  So far at "1 day, 16 hours" and 9.5 GB of internet
> network traffic, no issues.
>
> You can build your own custom image, or the Custom Build Engine
> http://build.astlinux.org for SVN builds has a new "Architecture: [
> x86_64 multi-core ]" option.
>
> For those of you with your own custom builds, no need to rebuild
> crosstool-ng, just go into your existing ctng-1.20.0-3.2 directory and jump
> to "## Build x86_64 64-bit toolchain ##" in the crosstool-ng-src/README.
>
>
> Over the next month or two, before we release AstLinux 1.2.5, we all
> should think about how to guide users which architecture to use.
> Possibly...
>
> 1) New installs with 64-bit CPU and 2+ GB RAM use x86_64 ?
>
> 2) Virtual machines, since all VM hosts are x86_64, would a x86_64 image
> run more efficiently ?  or does the somewhat lower memory usage of i586 the
> deciding factor ?
>
> 3) Leave existing installs alone (except for testing)
>
>
> For those who want to test x86_64, we put together a WiKi entry for
> switching an existing i586 system to x86_64...
>
> Switching Images between i586 and x86_64
> http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64
>
>
> Attached is a comparison of 2GB RAM AstLinux i586, 2GB RAM AstLinux x86_64
> and for reference 1GB RAM Synology Diskstation (x86_64
> synology_cedarview_713+) systems.
>
> Most interesting is how the RAM is used.
>
> Lonnie
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

On Nov 27, 2015, at 10:59 AM, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Over the next month or two, before we release AstLinux 1.2.5, we all should think about how to guide users which architecture to use.  Possibly...
> 
> 2) Virtual machines, since all VM hosts are x86_64, would a x86_64 image run more efficiently ?  or does the somewhat lower memory usage of i586 the deciding factor ?

In an attempt to answer that question, I used VMware Fusion 7 on a Mac Pro, created identical VM's... 512 GB RAM, 2-cores, but one with the latest i586 build and the other with x86_64.

Data below, but quick summary:
PHP test was 16% faster with x86_64, Asterisk transcoding 20-40% faster with x86_64, but openssl AES test was nearly identical (not shown).

Lonnie

--------------------------------------
VMware Fusion 7 on Mac Pro

==== i586 build ====
503 MB, Free 365 MB

pbx-vmware ~ # /mnt/kd/scripts/php-benchmark 
--------------------------------------
|        PHP BENCHMARK SCRIPT        |
--------------------------------------
Start : 2015-11-27 16:29:28
CPU : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
PHP version : 5.5.30
Platform : Linux i586
--------------------------------------
test_math                 : 1.189 sec.
test_stringmanipulation   : 1.303 sec.
test_loops                : 0.691 sec.
test_ifelse               : 0.587 sec.
--------------------------------------
Total time:               : 3.77 sec.

(Asterisk 1.8.32.3)
# asterisk -rx "core show translation recalc 10"   
              
           g723   gsm  ulaw  alaw g726aal2 adpcm  slin lpc10  g729 speex  ilbc  g726  g722 siren7 siren14 slin16  g719 speex16 testlaw
     g723     -     -     -     -        -     -     -     -     -     -     -     -     -      -       -      -     -       -       -
      gsm     -     -   300   300     1998   399   299  1498     -     -  4898  1998   599      -       -   1198     -       -     300
     ulaw     -   900     -     1     1700   101     1  1200     -     -  4600  1700   301      -       -    900     -       -       2
     ilbc     -  1698   800   800     2498   899   799  1998     -     -     -  2498  1099      -       -   1698     -       -     800


==== x86_64 build ====
497 MB, Free 323 MB

pbx-vmware ~ # /mnt/kd/scripts/php-benchmark 
--------------------------------------
|        PHP BENCHMARK SCRIPT        |
--------------------------------------
Start : 2015-11-27 16:59:33
CPU : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
PHP version : 5.5.30
Platform : Linux x86_64
--------------------------------------
test_math                 : 0.981 sec.
test_stringmanipulation   : 1.083 sec.
test_loops                : 0.650 sec.
test_ifelse               : 0.523 sec.
--------------------------------------
Total time:               : 3.237 sec.

(Asterisk 1.8.32.3)
# asterisk -rx "core show translation recalc 10"
         Recalculating Codec Translation (number of sample seconds: 10)

         Translation times between formats (in microseconds) for one second of data
          Source Format (Rows) Destination Format (Columns)

           g723   gsm  ulaw  alaw g726aal2 adpcm  slin lpc10  g729 speex  ilbc  g726  g722 siren7 siren14 slin16  g719 speex16 testlaw
     g723     -     -     -     -        -     -     -     -     -     -     -     -     -      -       -      -     -       -       -
      gsm     -     -   201   201     1699   300   200   999     -     -  4199  1499   399      -       -    699     -       -     201
     ulaw     -   699     -     1     1599   200   100   899     -     -  4099  1399   299      -       -    599     -       -     101
     ilbc     -  1198   600   600     2098   699   599  1398     -     -     -  1898   798      -       -   1098     -       -     600

--

Hi Devs,

I personally "upgraded" my main AstLinux box to x86_64, it is a Lanner FW-7541D Atom D525.  So far at "1 day, 16 hours" and 9.5 GB of internet network traffic, no issues.

You can build your own custom image, or the Custom Build Engine http://build.astlinux.org for SVN builds has a new "Architecture: [ x86_64 multi-core ]" option.

For those of you with your own custom builds, no need to rebuild crosstool-ng, just go into your existing ctng-1.20.0-3.2 directory and jump to "## Build x86_64 64-bit toolchain ##" in the crosstool-ng-src/README.


Over the next month or two, before we release AstLinux 1.2.5, we all should think about how to guide users which architecture to use.  Possibly...

1) New installs with 64-bit CPU and 2+ GB RAM use x86_64 ?

2) Virtual machines, since all VM hosts are x86_64, would a x86_64 image run more efficiently ?  or does the somewhat lower memory usage of i586 the deciding factor ?

3) Leave existing installs alone (except for testing) 


For those who want to test x86_64, we put together a WiKi entry for switching an existing i586 system to x86_64...

Switching Images between i586 and x86_64
http://doc.astlinux.org/devdoc:devdoc_switch_i586_x86_64


Attached is a comparison of 2GB RAM AstLinux i586, 2GB RAM AstLinux x86_64 and for reference 1GB RAM Synology Diskstation (x86_64 synology_cedarview_713+) systems.

Most interesting is how the RAM is used.

Lonnie

Yes, I agree we should drop support for Asterisk 1.8. If it's EOL, 1.2.4.1 should probably be the last AstLinux release with Asterisk 1.8.

> -----Original Message-----
> From: Michael Knill [mailto:mic...@ip...]
> Sent: Sunday, November 22, 2015 8:38 PM
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Add x86_64 support ?
> 
> Maybe we should drop 1.8 for x86_64 as its EoL. Im transitioning out my
> customers.
> 
> Regards
> Michael Knill
> 
> 
> 
> 
> On 23 Nov 2015, at 6:35 am, Darrick Hartman <dha...@dj...>
> wrote:
> 
> A majority of our systems have less than 4 GB of ram, but many of the
> systems are 64 bit Atom processors. It's probably worth the effort, but it
> does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.
> 
> > -----Original Message-----
> > From: Michael Keuter [mailto:li...@mk...]
> > Sent: Sunday, November 22, 2015 4:45 AM
> > To: AstLinux Developers Mailing List
> > <ast...@li...>
> > Subject: Re: [Astlinux-devel] Add x86_64 support ?
> >
> >
> > Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
> > <li...@lo...>:
> >
> >> Hi Devs,
> >>
> >> What are the thoughts here about adding x86_64 support ?
> >>
> >> You may ask why would we think about x86_64 support when 2 GB RAM is
> > more than plenty for AstLinux.
> >>
> >> While x86_64 will be slightly faster in most all cases, it will use more RAM.
> > Though a 2 GB RAM system should still be plenty.
> >>
> >> Now for the intangibles, modern kernel modules and drivers are
> >> usually
> > tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
> >>
> >> So, is it worth the effort for the AstLinux team to consider adding
> >> x86_64
> > support ?
> >>
> >> Of course, the RUNNIX bootloader, alix and net5501 boards will still
> >> require
> > 32-bit images.  The geni586 and geni586-serial images will continue to
> > be 32- bit.
> >>
> >>
> >> If the answer is "why not" to the above question, how would it be
> > implemented...
> >>
> >> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
> > config for x86_64 support generating an additional toolchain.
> > ("crosstool-ng-
> > src/ct-ng-1.20.0-3.2-x86_64.config")
> >>
> >> We would need an additional "project/astlinux/geni586/linux-smp.config"
> > config for an x86_64 kernel.
> > ("project/astlinux/genx86_64/linux-smp.config")
> >>
> >> Add two new board types: genx86_64 and genx86_64-serial
> >>
> >> Since both the toolchain and kernel config is specified in the
> >> Buildroot
> > .config file, editing the .config file is all that is needed for an
> > x86_64 custom image.  Darrick will need a slightly altered
> > master-build script to also generate
> > x86_64 images.
> >>
> >> Also binary blobs, like SILK CODECs and the FOP2 interface would need
> >> 32
> > and 64 bit versions.
> >>
> >> Also the things we didn't think of :-)
> >>
> >>
> >> Thoughts ?
> >>
> >> Lonnie
> >
> > Hi Lonnie,
> >
> > I personally like the idea of adding x86_64 support.
> > I would see this as an investment in the future of AstLinux, in times
> > where even iOS or Android devices are switching to 64 bit.
> >
> > And even if we get it "only" 10% faster, this is a lot for embedded
> > devices on the same hardware.
> >
> > Michael
> >
> > http://www.mksolutions.info
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> > pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users
> amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....

Am 23.11.2015 um 13:40 schrieb Lonnie Abelbeck <li...@lo...>:

> Update,
> 
> In my preliminary testing the x86_64 build seems to work well.
> 
> I built the x86_64 image using existing i586 data, all configs and databases (including Fossil) continue to work with x86_64 using previous i586 data, *except* LDAP (slapd) where the slapd database ( "/mnt/kd/ldap/data/data.mdb" ) is not valid with a 32bit to 64bit binary change, this is a known issue with OpenLDAP.
> 
> Lonnie

That sounds promising.
A few issues should be expectable with such a switch.

For OpenLDAP one could try to export the 32bit database as LDIF beforehand and then import it again in the 64bit version.

> On Nov 22, 2015, at 5:47 PM, Lonnie Abelbeck <li...@lo...> wrote:
> 
>> Look what I built :-)
>> --
>> pbx3 ~ # uname -a
>> Linux pbx3 3.2.66-astlinux #1 SMP PREEMPT Sun Nov 22 12:15:33 CST 2015 x86_64 GNU/Linux
>> --
>> 
>> Seems to work, PHP benchmark runs 6% faster, but (my custom) compressed image grew from 36.2 MB to 38.9 MB
>> 
>> Lonnie
>> 
>> 
>> On Nov 22, 2015, at 1:35 PM, Darrick Hartman <dha...@dj...> wrote:
>> 
>>> A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.
>>> 
>>>> -----Original Message-----
>>>> From: Michael Keuter [mailto:li...@mk...]
>>>> Sent: Sunday, November 22, 2015 4:45 AM
>>>> To: AstLinux Developers Mailing List <ast...@li...>
>>>> Subject: Re: [Astlinux-devel] Add x86_64 support ?
>>>> 
>>>> 
>>>> Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
>>>> <li...@lo...>:
>>>> 
>>>>> Hi Devs,
>>>>> 
>>>>> What are the thoughts here about adding x86_64 support ?
>>>>> 
>>>>> You may ask why would we think about x86_64 support when 2 GB RAM is
>>>> more than plenty for AstLinux.
>>>>> 
>>>>> While x86_64 will be slightly faster in most all cases, it will use more RAM.
>>>> Though a 2 GB RAM system should still be plenty.
>>>>> 
>>>>> Now for the intangibles, modern kernel modules and drivers are usually
>>>> tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
>>>>> 
>>>>> So, is it worth the effort for the AstLinux team to consider adding x86_64
>>>> support ?
>>>>> 
>>>>> Of course, the RUNNIX bootloader, alix and net5501 boards will still require
>>>> 32-bit images.  The geni586 and geni586-serial images will continue to be 32-
>>>> bit.
>>>>> 
>>>>> 
>>>>> If the answer is "why not" to the above question, how would it be
>>>> implemented...
>>>>> 
>>>>> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
>>>> config for x86_64 support generating an additional toolchain. ("crosstool-ng-
>>>> src/ct-ng-1.20.0-3.2-x86_64.config")
>>>>> 
>>>>> We would need an additional "project/astlinux/geni586/linux-smp.config"
>>>> config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
>>>>> 
>>>>> Add two new board types: genx86_64 and genx86_64-serial
>>>>> 
>>>>> Since both the toolchain and kernel config is specified in the Buildroot
>>>> .config file, editing the .config file is all that is needed for an x86_64 custom
>>>> image.  Darrick will need a slightly altered master-build script to also generate
>>>> x86_64 images.
>>>>> 
>>>>> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32
>>>> and 64 bit versions.
>>>>> 
>>>>> Also the things we didn't think of :-)
>>>>> 
>>>>> 
>>>>> Thoughts ?
>>>>> 
>>>>> Lonnie
>>>> 
>>>> Hi Lonnie,
>>>> 
>>>> I personally like the idea of adding x86_64 support.
>>>> I would see this as an investment in the future of AstLinux, in times where
>>>> even iOS or Android devices are switching to 64 bit.
>>>> 
>>>> And even if we get it "only" 10% faster, this is a lot for embedded devices on
>>>> the same hardware.
>>>> 
>>>> Michael
>>>> 
>>>> http://www.mksolutions.info

Michael

http://www.mksolutions.info

Update,

In my preliminary testing the x86_64 build seems to work well.

I built the x86_64 image using existing i586 data, all configs and databases (including Fossil) continue to work with x86_64 using previous i586 data, *except* LDAP (slapd) where the slapd database ( "/mnt/kd/ldap/data/data.mdb" ) is not valid with a 32bit to 64bit binary change, this is a known issue with OpenLDAP.

Lonnie



On Nov 22, 2015, at 5:47 PM, Lonnie Abelbeck <li...@lo...> wrote:

> Look what I built :-)
> --
> pbx3 ~ # uname -a
> Linux pbx3 3.2.66-astlinux #1 SMP PREEMPT Sun Nov 22 12:15:33 CST 2015 x86_64 GNU/Linux
> --
> 
> Seems to work, PHP benchmark runs 6% faster, but (my custom) compressed image grew from 36.2 MB to 38.9 MB
> 
> Lonnie
> 
> 
> On Nov 22, 2015, at 1:35 PM, Darrick Hartman <dha...@dj...> wrote:
> 
>> A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.
>> 
>>> -----Original Message-----
>>> From: Michael Keuter [mailto:li...@mk...]
>>> Sent: Sunday, November 22, 2015 4:45 AM
>>> To: AstLinux Developers Mailing List <ast...@li...>
>>> Subject: Re: [Astlinux-devel] Add x86_64 support ?
>>> 
>>> 
>>> Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
>>> <li...@lo...>:
>>> 
>>>> Hi Devs,
>>>> 
>>>> What are the thoughts here about adding x86_64 support ?
>>>> 
>>>> You may ask why would we think about x86_64 support when 2 GB RAM is
>>> more than plenty for AstLinux.
>>>> 
>>>> While x86_64 will be slightly faster in most all cases, it will use more RAM.
>>> Though a 2 GB RAM system should still be plenty.
>>>> 
>>>> Now for the intangibles, modern kernel modules and drivers are usually
>>> tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
>>>> 
>>>> So, is it worth the effort for the AstLinux team to consider adding x86_64
>>> support ?
>>>> 
>>>> Of course, the RUNNIX bootloader, alix and net5501 boards will still require
>>> 32-bit images.  The geni586 and geni586-serial images will continue to be 32-
>>> bit.
>>>> 
>>>> 
>>>> If the answer is "why not" to the above question, how would it be
>>> implemented...
>>>> 
>>>> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
>>> config for x86_64 support generating an additional toolchain. ("crosstool-ng-
>>> src/ct-ng-1.20.0-3.2-x86_64.config")
>>>> 
>>>> We would need an additional "project/astlinux/geni586/linux-smp.config"
>>> config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
>>>> 
>>>> Add two new board types: genx86_64 and genx86_64-serial
>>>> 
>>>> Since both the toolchain and kernel config is specified in the Buildroot
>>> .config file, editing the .config file is all that is needed for an x86_64 custom
>>> image.  Darrick will need a slightly altered master-build script to also generate
>>> x86_64 images.
>>>> 
>>>> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32
>>> and 64 bit versions.
>>>> 
>>>> Also the things we didn't think of :-)
>>>> 
>>>> 
>>>> Thoughts ?
>>>> 
>>>> Lonnie
>>> 
>>> Hi Lonnie,
>>> 
>>> I personally like the idea of adding x86_64 support.
>>> I would see this as an investment in the future of AstLinux, in times where
>>> even iOS or Android devices are switching to 64 bit.
>>> 
>>> And even if we get it "only" 10% faster, this is a lot for embedded devices on
>>> the same hardware.
>>> 
>>> Michael
>>> 
>>> http://www.mksolutions.info
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to
>>> pa...@kr....
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 

Am 23.11.2015 um 03:38 schrieb Michael Knill <mic...@ip...>:

> Maybe we should drop 1.8 for x86_64 as its EoL. Im transitioning out my customers.
> 
> Regards
> Michael Knill

+1

> On 23 Nov 2015, at 6:35 am, Darrick Hartman <dha...@dj...> wrote:
> 
>> A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.

Michael

http://www.mksolutions.info

Maybe we should drop 1.8 for x86_64 as its EoL. Im transitioning out my customers.

Regards
Michael Knill




On 23 Nov 2015, at 6:35 am, Darrick Hartman <dha...@dj...> wrote:

A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.

> -----Original Message-----
> From: Michael Keuter [mailto:li...@mk...]
> Sent: Sunday, November 22, 2015 4:45 AM
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Add x86_64 support ?
> 
> 
> Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
> <li...@lo...>:
> 
>> Hi Devs,
>> 
>> What are the thoughts here about adding x86_64 support ?
>> 
>> You may ask why would we think about x86_64 support when 2 GB RAM is
> more than plenty for AstLinux.
>> 
>> While x86_64 will be slightly faster in most all cases, it will use more RAM.
> Though a 2 GB RAM system should still be plenty.
>> 
>> Now for the intangibles, modern kernel modules and drivers are usually
> tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
>> 
>> So, is it worth the effort for the AstLinux team to consider adding x86_64
> support ?
>> 
>> Of course, the RUNNIX bootloader, alix and net5501 boards will still require
> 32-bit images.  The geni586 and geni586-serial images will continue to be 32-
> bit.
>> 
>> 
>> If the answer is "why not" to the above question, how would it be
> implemented...
>> 
>> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
> config for x86_64 support generating an additional toolchain. ("crosstool-ng-
> src/ct-ng-1.20.0-3.2-x86_64.config")
>> 
>> We would need an additional "project/astlinux/geni586/linux-smp.config"
> config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
>> 
>> Add two new board types: genx86_64 and genx86_64-serial
>> 
>> Since both the toolchain and kernel config is specified in the Buildroot
> .config file, editing the .config file is all that is needed for an x86_64 custom
> image.  Darrick will need a slightly altered master-build script to also generate
> x86_64 images.
>> 
>> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32
> and 64 bit versions.
>> 
>> Also the things we didn't think of :-)
>> 
>> 
>> Thoughts ?
>> 
>> Lonnie
> 
> Hi Lonnie,
> 
> I personally like the idea of adding x86_64 support.
> I would see this as an investment in the future of AstLinux, in times where
> even iOS or Android devices are switching to 64 bit.
> 
> And even if we get it "only" 10% faster, this is a lot for embedded devices on
> the same hardware.
> 
> Michael
> 
> http://www.mksolutions.info
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....

------------------------------------------------------------------------------
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Look what I built :-)
--
pbx3 ~ # uname -a
Linux pbx3 3.2.66-astlinux #1 SMP PREEMPT Sun Nov 22 12:15:33 CST 2015 x86_64 GNU/Linux
--

Seems to work, PHP benchmark runs 6% faster, but (my custom) compressed image grew from 36.2 MB to 38.9 MB

Lonnie


On Nov 22, 2015, at 1:35 PM, Darrick Hartman <dha...@dj...> wrote:

> A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.
> 
>> -----Original Message-----
>> From: Michael Keuter [mailto:li...@mk...]
>> Sent: Sunday, November 22, 2015 4:45 AM
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] Add x86_64 support ?
>> 
>> 
>> Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
>> <li...@lo...>:
>> 
>>> Hi Devs,
>>> 
>>> What are the thoughts here about adding x86_64 support ?
>>> 
>>> You may ask why would we think about x86_64 support when 2 GB RAM is
>> more than plenty for AstLinux.
>>> 
>>> While x86_64 will be slightly faster in most all cases, it will use more RAM.
>> Though a 2 GB RAM system should still be plenty.
>>> 
>>> Now for the intangibles, modern kernel modules and drivers are usually
>> tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
>>> 
>>> So, is it worth the effort for the AstLinux team to consider adding x86_64
>> support ?
>>> 
>>> Of course, the RUNNIX bootloader, alix and net5501 boards will still require
>> 32-bit images.  The geni586 and geni586-serial images will continue to be 32-
>> bit.
>>> 
>>> 
>>> If the answer is "why not" to the above question, how would it be
>> implemented...
>>> 
>>> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
>> config for x86_64 support generating an additional toolchain. ("crosstool-ng-
>> src/ct-ng-1.20.0-3.2-x86_64.config")
>>> 
>>> We would need an additional "project/astlinux/geni586/linux-smp.config"
>> config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
>>> 
>>> Add two new board types: genx86_64 and genx86_64-serial
>>> 
>>> Since both the toolchain and kernel config is specified in the Buildroot
>> .config file, editing the .config file is all that is needed for an x86_64 custom
>> image.  Darrick will need a slightly altered master-build script to also generate
>> x86_64 images.
>>> 
>>> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32
>> and 64 bit versions.
>>> 
>>> Also the things we didn't think of :-)
>>> 
>>> 
>>> Thoughts ?
>>> 
>>> Lonnie
>> 
>> Hi Lonnie,
>> 
>> I personally like the idea of adding x86_64 support.
>> I would see this as an investment in the future of AstLinux, in times where
>> even iOS or Android devices are switching to 64 bit.
>> 
>> And even if we get it "only" 10% faster, this is a lot for embedded devices on
>> the same hardware.
>> 
>> Michael
>> 
>> http://www.mksolutions.info
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 

A majority of our systems have less than 4 GB of ram, but many of the systems are 64 bit Atom processors. It's probably worth the effort, but it does add 6 new images if we are going to maintain Asterisk 1.8, 11 and 13.

> -----Original Message-----
> From: Michael Keuter [mailto:li...@mk...]
> Sent: Sunday, November 22, 2015 4:45 AM
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Add x86_64 support ?
> 
> 
> Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck
> <li...@lo...>:
> 
> > Hi Devs,
> >
> > What are the thoughts here about adding x86_64 support ?
> >
> > You may ask why would we think about x86_64 support when 2 GB RAM is
> more than plenty for AstLinux.
> >
> > While x86_64 will be slightly faster in most all cases, it will use more RAM.
> Though a 2 GB RAM system should still be plenty.
> >
> > Now for the intangibles, modern kernel modules and drivers are usually
> tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
> >
> > So, is it worth the effort for the AstLinux team to consider adding x86_64
> support ?
> >
> > Of course, the RUNNIX bootloader, alix and net5501 boards will still require
> 32-bit images.  The geni586 and geni586-serial images will continue to be 32-
> bit.
> >
> >
> > If the answer is "why not" to the above question, how would it be
> implemented...
> >
> > We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config"
> config for x86_64 support generating an additional toolchain. ("crosstool-ng-
> src/ct-ng-1.20.0-3.2-x86_64.config")
> >
> > We would need an additional "project/astlinux/geni586/linux-smp.config"
> config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
> >
> > Add two new board types: genx86_64 and genx86_64-serial
> >
> > Since both the toolchain and kernel config is specified in the Buildroot
> .config file, editing the .config file is all that is needed for an x86_64 custom
> image.  Darrick will need a slightly altered master-build script to also generate
> x86_64 images.
> >
> > Also binary blobs, like SILK CODECs and the FOP2 interface would need 32
> and 64 bit versions.
> >
> > Also the things we didn't think of :-)
> >
> >
> > Thoughts ?
> >
> > Lonnie
> 
> Hi Lonnie,
> 
> I personally like the idea of adding x86_64 support.
> I would see this as an investment in the future of AstLinux, in times where
> even iOS or Android devices are switching to 64 bit.
> 
> And even if we get it "only" 10% faster, this is a lot for embedded devices on
> the same hardware.
> 
> Michael
> 
> http://www.mksolutions.info
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....

Am 21.11.2015 um 23:41 schrieb Lonnie Abelbeck <li...@lo...>:

> Hi Devs,
> 
> What are the thoughts here about adding x86_64 support ?
> 
> You may ask why would we think about x86_64 support when 2 GB RAM is more than plenty for AstLinux.
> 
> While x86_64 will be slightly faster in most all cases, it will use more RAM.  Though a 2 GB RAM system should still be plenty.
> 
> Now for the intangibles, modern kernel modules and drivers are usually tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
> 
> So, is it worth the effort for the AstLinux team to consider adding x86_64 support ?
> 
> Of course, the RUNNIX bootloader, alix and net5501 boards will still require 32-bit images.  The geni586 and geni586-serial images will continue to be 32-bit.
> 
> 
> If the answer is "why not" to the above question, how would it be implemented...
> 
> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config" config for x86_64 support generating an additional toolchain. ("crosstool-ng-src/ct-ng-1.20.0-3.2-x86_64.config") 
> 
> We would need an additional "project/astlinux/geni586/linux-smp.config" config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
> 
> Add two new board types: genx86_64 and genx86_64-serial
> 
> Since both the toolchain and kernel config is specified in the Buildroot .config file, editing the .config file is all that is needed for an x86_64 custom image.  Darrick will need a slightly altered master-build script to also generate x86_64 images.
> 
> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32 and 64 bit versions.
> 
> Also the things we didn't think of :-)
> 
> 
> Thoughts ?
> 
> Lonnie

Hi Lonnie,

I personally like the idea of adding x86_64 support.
I would see this as an investment in the future of AstLinux, in times where even iOS or Android devices are switching to 64 bit.

And even if we get it "only" 10% faster, this is a lot for embedded devices on the same hardware.

Michael

http://www.mksolutions.info

Thanks

In that case then I can’t really see much advantage in me using it.

Regards
Michael Knill




On 22 Nov 2015, at 3:41 pm, Lonnie Abelbeck <li...@lo...> wrote:

Hi Michael,

A x86_64 image should run a few percent faster from what I have researched.  There is a very special case where 32-bit can be ever-so-slightly faster, but using todays compilers and the extra registers in the x86_64, it seems x86_64 is almost always faster but not more than 10% faster.

I would expect OpenSSL would perform noticeably better with x86_64.

Also cases when interfacing with drivers, I have noticed that the Intel i211 ethernet driver on a (Jetway NF9HG-2930) Intel N2930  CPU @ 1.83GHz maxes-out iperf tests in the low 800's Mbps, I would expect it should be in the low 900's... I'm not sure if x86_64 would improve that or not, but it would not surprise me if it helped.

Lonnie


On Nov 21, 2015, at 9:05 PM, Michael Knill <mic...@ip...> wrote:

> So other than better testing of modules and drivers, are there any other advantages?
> 
> Regards
> Michael Knill
> 
> 
> 
> 
> On 22 Nov 2015, at 9:41 am, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Hi Devs,
> 
> What are the thoughts here about adding x86_64 support ?
> 
> You may ask why would we think about x86_64 support when 2 GB RAM is more than plenty for AstLinux.
> 
> While x86_64 will be slightly faster in most all cases, it will use more RAM.  Though a 2 GB RAM system should still be plenty.
> 
> Now for the intangibles, modern kernel modules and drivers are usually tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
> 
> So, is it worth the effort for the AstLinux team to consider adding x86_64 support ?
> 
> Of course, the RUNNIX bootloader, alix and net5501 boards will still require 32-bit images.  The geni586 and geni586-serial images will continue to be 32-bit.
> 
> 
> If the answer is "why not" to the above question, how would it be implemented...
> 
> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config" config for x86_64 support generating an additional toolchain. ("crosstool-ng-src/ct-ng-1.20.0-3.2-x86_64.config") 
> 
> We would need an additional "project/astlinux/geni586/linux-smp.config" config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
> 
> Add two new board types: genx86_64 and genx86_64-serial
> 
> Since both the toolchain and kernel config is specified in the Buildroot .config file, editing the .config file is all that is needed for an x86_64 custom image.  Darrick will need a slightly altered master-build script to also generate x86_64 images.
> 
> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32 and 64 bit versions.
> 
> Also the things we didn't think of :-)
> 
> 
> Thoughts ?
> 
> Lonnie
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 


------------------------------------------------------------------------------
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Hi Michael,

A x86_64 image should run a few percent faster from what I have researched.  There is a very special case where 32-bit can be ever-so-slightly faster, but using todays compilers and the extra registers in the x86_64, it seems x86_64 is almost always faster but not more than 10% faster.

I would expect OpenSSL would perform noticeably better with x86_64.

Also cases when interfacing with drivers, I have noticed that the Intel i211 ethernet driver on a (Jetway NF9HG-2930) Intel N2930  CPU @ 1.83GHz maxes-out iperf tests in the low 800's Mbps, I would expect it should be in the low 900's... I'm not sure if x86_64 would improve that or not, but it would not surprise me if it helped.

Lonnie


On Nov 21, 2015, at 9:05 PM, Michael Knill <mic...@ip...> wrote:

> So other than better testing of modules and drivers, are there any other advantages?
> 
> Regards
> Michael Knill
> 
> 
> 
> 
> On 22 Nov 2015, at 9:41 am, Lonnie Abelbeck <li...@lo...> wrote:
> 
> Hi Devs,
> 
> What are the thoughts here about adding x86_64 support ?
> 
> You may ask why would we think about x86_64 support when 2 GB RAM is more than plenty for AstLinux.
> 
> While x86_64 will be slightly faster in most all cases, it will use more RAM.  Though a 2 GB RAM system should still be plenty.
> 
> Now for the intangibles, modern kernel modules and drivers are usually tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.
> 
> So, is it worth the effort for the AstLinux team to consider adding x86_64 support ?
> 
> Of course, the RUNNIX bootloader, alix and net5501 boards will still require 32-bit images.  The geni586 and geni586-serial images will continue to be 32-bit.
> 
> 
> If the answer is "why not" to the above question, how would it be implemented...
> 
> We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config" config for x86_64 support generating an additional toolchain. ("crosstool-ng-src/ct-ng-1.20.0-3.2-x86_64.config") 
> 
> We would need an additional "project/astlinux/geni586/linux-smp.config" config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")
> 
> Add two new board types: genx86_64 and genx86_64-serial
> 
> Since both the toolchain and kernel config is specified in the Buildroot .config file, editing the .config file is all that is needed for an x86_64 custom image.  Darrick will need a slightly altered master-build script to also generate x86_64 images.
> 
> Also binary blobs, like SILK CODECs and the FOP2 interface would need 32 and 64 bit versions.
> 
> Also the things we didn't think of :-)
> 
> 
> Thoughts ?
> 
> Lonnie
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 

So other than better testing of modules and drivers, are there any other advantages?

Regards
Michael Knill




On 22 Nov 2015, at 9:41 am, Lonnie Abelbeck <li...@lo...> wrote:

Hi Devs,

What are the thoughts here about adding x86_64 support ?

You may ask why would we think about x86_64 support when 2 GB RAM is more than plenty for AstLinux.

While x86_64 will be slightly faster in most all cases, it will use more RAM.  Though a 2 GB RAM system should still be plenty.

Now for the intangibles, modern kernel modules and drivers are usually tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.

So, is it worth the effort for the AstLinux team to consider adding x86_64 support ?

Of course, the RUNNIX bootloader, alix and net5501 boards will still require 32-bit images.  The geni586 and geni586-serial images will continue to be 32-bit.


If the answer is "why not" to the above question, how would it be implemented...

We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config" config for x86_64 support generating an additional toolchain. ("crosstool-ng-src/ct-ng-1.20.0-3.2-x86_64.config") 

We would need an additional "project/astlinux/geni586/linux-smp.config" config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")

Add two new board types: genx86_64 and genx86_64-serial

Since both the toolchain and kernel config is specified in the Buildroot .config file, editing the .config file is all that is needed for an x86_64 custom image.  Darrick will need a slightly altered master-build script to also generate x86_64 images.

Also binary blobs, like SILK CODECs and the FOP2 interface would need 32 and 64 bit versions.

Also the things we didn't think of :-)


Thoughts ?

Lonnie


------------------------------------------------------------------------------
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Hi Devs,

What are the thoughts here about adding x86_64 support ?

You may ask why would we think about x86_64 support when 2 GB RAM is more than plenty for AstLinux.

While x86_64 will be slightly faster in most all cases, it will use more RAM.  Though a 2 GB RAM system should still be plenty.

Now for the intangibles, modern kernel modules and drivers are usually tested on x86_64 and not on i586, so x86_64 will be better tested ongoing.

So, is it worth the effort for the AstLinux team to consider adding x86_64 support ?

Of course, the RUNNIX bootloader, alix and net5501 boards will still require 32-bit images.  The geni586 and geni586-serial images will continue to be 32-bit.


If the answer is "why not" to the above question, how would it be implemented...

We would need an additional "crosstool-ng-src/ct-ng-1.20.0-3.2.config" config for x86_64 support generating an additional toolchain. ("crosstool-ng-src/ct-ng-1.20.0-3.2-x86_64.config") 

We would need an additional "project/astlinux/geni586/linux-smp.config" config for an x86_64 kernel. ("project/astlinux/genx86_64/linux-smp.config")

Add two new board types: genx86_64 and genx86_64-serial

Since both the toolchain and kernel config is specified in the Buildroot .config file, editing the .config file is all that is needed for an x86_64 custom image.  Darrick will need a slightly altered master-build script to also generate x86_64 images.

Also binary blobs, like SILK CODECs and the FOP2 interface would need 32 and 64 bit versions.

Also the things we didn't think of :-)


Thoughts ?

Lonnie

Am 07.11.2015 um 18:03 schrieb Lonnie Abelbeck <li...@lo...>:

> Hi Devs,
> 
> Currently all our self-signed certificates have a SHA-1 signature digest algorithm.
> 
> Should we move to create all "new" certificates with SHA-256 ?
> 
> Ref: Microsoft considers blocking SHA-1 certificates after cost of collisions slashed
> http://arstechnica.com/security/2015/11/microsoft-considers-blocking-sha-1-certificates-after-cost-of-collisions-slashed/
> 
> This change would not effect current certificates, only newly created certificates for services:
> * HTTPS web server cert
> * SIP-TLS cert (shared with other packages as well)
> * OpenVPN server cert
> * IPSec server cert
> 
> As far as compatibility, here is a good reference...
> 
> SHA-2 Compatibility (SHA-256 Migration)
> https://www.digicert.com/sha-2-compatibility.htm
> 
> It seems like a good point in time to begin the SHA-256 Migration.
> 
> Comments ?
> 
> Lonnie

Yes, that's a good idea.
 
Michael

http://www.mksolutions.info

Hi Devs,

Currently all our self-signed certificates have a SHA-1 signature digest algorithm.

Should we move to create all "new" certificates with SHA-256 ?

Ref: Microsoft considers blocking SHA-1 certificates after cost of collisions slashed
http://arstechnica.com/security/2015/11/microsoft-considers-blocking-sha-1-certificates-after-cost-of-collisions-slashed/

This change would not effect current certificates, only newly created certificates for services:
* HTTPS web server cert
* SIP-TLS cert (shared with other packages as well)
* OpenVPN server cert
* IPSec server cert

As far as compatibility, here is a good reference...

SHA-2 Compatibility (SHA-256 Migration)
https://www.digicert.com/sha-2-compatibility.htm

It seems like a good point in time to begin the SHA-256 Migration.

Comments ?

Lonnie

Yup, I found the code example you provided to loop on the contents of
$INT_IF so all is well now with my custom rules.

Thanks
David

On Tue, Nov 3, 2015 at 10:26 PM, David Kerr <da...@ke...> wrote:

> Okay, embarrassing.  I had allow OpenVPN Client to tunnel, I did not have
> allow OpenVPN Server to tunnel.  So I had the wrong one.  That has fixed
> OpenVPN.  I'm not going to chase the ipsec certificate problem, too much
> effort.  I tried PPTP only because I couldn't get either of the others to
> work.  However it does appear that the only VPN currently working with
> astlinux is OpenVPN.
>
> Thanks for the tip to restart firewall from the command line.  I traced
> the warning to a custom rule I added... it uses $INT_IF and when OpenVPN is
> enabled this is "br1 tun0" it fails on tun0.
>
> /usr/sbin/iptables -t nat -A PREROUTING -m mac --mac-source
> 70:56:81:xx:yy:zz -m time --timestart 20:00 --timestop 03:30 -i br1 tun0 -p
> tcp --dport 80 -j REDIRECT --to-ports 8888
> ERROR (2): Bad argument `tun0'
>
> I seem to remember some discussion on this when I first enquired about
> that particular rule, you pointed out that it would fail if more than one
> interface was defined to INT_IF.  I think you had a work-around for that, I
> need to search back in the list history...
>
> Thanks
> David.
>
> On Tue, Nov 3, 2015 at 5:11 PM, Lonnie Abelbeck <li...@lo...
> > wrote:
>
>> Hi David,
>>
>> For OpenVPN, do you have (or similar) checked...
>>
>> Network -> Firewall Configuration -> Firewall Options: _x_ Allow OpenVPN
>> Server tunnel to the [ 1st ] LAN Interface(s)
>>
>> If not, that is your problem. Done.
>>
>> >From the CLI, the command "arno-iptables-firewall restart" will show how
>> things are being built.
>>
>> As far as IPSec, clearly there is a certificate issue, could well be a OS
>> X issue with trusting the cert.
>>
>> Don't even think about PPTP :-)
>>
>> Focus on OpenVPN.
>>
>> Lonnie
>>
>>
>> On Nov 3, 2015, at 1:47 PM, David Kerr <Da...@Ke...> wrote:
>>
>> > How can I enable more detail on firewall logging... at the time the
>> iptables rules are built.
>> >
>> > I'm having real trouble getting VPN working again.  I don't know what I
>> did, but I have not used VPN in a long time.
>> >
>> > If I enable OpenVPN I get a message that one firewall rule failed to
>> apply.  The client (Tunnelblick) connects okay, but I can only ping the
>> gateway (e.g. 192.168.xx.1) but if I ping anything inside my network I get
>> no response... packet dropped message, suggesting firewall config not
>> right...
>> > AIF:Dropped FORWARD packet: IN=tun0 OUT=br1 MAC= SRC=10.8.0.2
>> DST=192.168.xx.6 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=5266 PROTO=ICMP TYPE=8
>> CODE=0 ID=3177 SEQ=0
>> >
>> > Meanwhile trying ipsec, I get a message from my client side (Apple
>> built-in VPN) that it failed to verify certificate...
>> > 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
>> > 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
>> > 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error
>> strings: ---------------.
>> > 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error
>> strings: ---------------.
>> > 11/3/15 2:35:13.294 PM racoon[27040]:
>> -----------------------------------------------------.
>> > 11/3/15 2:35:13.294 PM racoon[27040]:
>> -----------------------------------------------------.
>> > 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not
>> verified.
>> > 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not
>> verified.
>> > I've googled, but not found anything that helps (I have moved the
>> certificated into system keychain and set "always trust".
>> >
>> > And with PPTP I get a message that the remote end terminated the
>> connection...
>> > 11/3/15 2:35:54.854 PM pppd[27056]: PPTP connection established.
>> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading socket :
>> Connection reset by peer
>> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading header :
>> read -1, expected 12 bytes
>> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP hangup
>> > 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnecting...
>> > 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnected
>> > Nov  3 14:35:54 pbx daemon.info
>> >  pptpd[30592]: CTRL: Starting call (launching pppd, opening GRE)
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: pty_fd = 7
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: tty_fd = 8
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: I wrote 32 bytes
>> to the client.
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Sent packet to
>> client
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
>> program binary = /usr/sbin/pppd
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
>> local address = 192.168.xx.240
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
>> remote address = 192.168.xx.232
>> >
>> > Nov  3 14:35:54 pbx daemon.err pptpd[30592]: GRE:
>> read(fd=7,buffer=8058640,len=8196) from PTY failed: status = -1 error =
>> Input/output error, usually caused by unexpected termination of pppd, check
>> option syntax and pppd logs
>> > Nov  3 14:35:54 pbx daemon.err pptpd[30592]: CTRL: PTY read or GRE
>> write failed (pty,gre)=(7,8)
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Reaping child
>> PPP[30593]
>> > Nov  3 14:35:54 pbx
>> > daemon.info
>> >  pptpd[30592]: CTRL: Client 157.130.31.226 control connection finished
>> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Exiting now
>> >
>> >
>> > So, right now I'm not able to connect by OVPN, IPSEC or PPTP.
>> >
>> > Help !
>> >
>> > Thanks
>> > David
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Astlinux-devel mailing list
>> > Ast...@li...
>> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> >
>> > Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
>>
>
>

Okay, embarrassing.  I had allow OpenVPN Client to tunnel, I did not have
allow OpenVPN Server to tunnel.  So I had the wrong one.  That has fixed
OpenVPN.  I'm not going to chase the ipsec certificate problem, too much
effort.  I tried PPTP only because I couldn't get either of the others to
work.  However it does appear that the only VPN currently working with
astlinux is OpenVPN.

Thanks for the tip to restart firewall from the command line.  I traced the
warning to a custom rule I added... it uses $INT_IF and when OpenVPN is
enabled this is "br1 tun0" it fails on tun0.

/usr/sbin/iptables -t nat -A PREROUTING -m mac --mac-source
70:56:81:xx:yy:zz -m time --timestart 20:00 --timestop 03:30 -i br1 tun0 -p
tcp --dport 80 -j REDIRECT --to-ports 8888
ERROR (2): Bad argument `tun0'

I seem to remember some discussion on this when I first enquired about that
particular rule, you pointed out that it would fail if more than one
interface was defined to INT_IF.  I think you had a work-around for that, I
need to search back in the list history...

Thanks
David.

On Tue, Nov 3, 2015 at 5:11 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi David,
>
> For OpenVPN, do you have (or similar) checked...
>
> Network -> Firewall Configuration -> Firewall Options: _x_ Allow OpenVPN
> Server tunnel to the [ 1st ] LAN Interface(s)
>
> If not, that is your problem. Done.
>
> >From the CLI, the command "arno-iptables-firewall restart" will show how
> things are being built.
>
> As far as IPSec, clearly there is a certificate issue, could well be a OS
> X issue with trusting the cert.
>
> Don't even think about PPTP :-)
>
> Focus on OpenVPN.
>
> Lonnie
>
>
> On Nov 3, 2015, at 1:47 PM, David Kerr <Da...@Ke...> wrote:
>
> > How can I enable more detail on firewall logging... at the time the
> iptables rules are built.
> >
> > I'm having real trouble getting VPN working again.  I don't know what I
> did, but I have not used VPN in a long time.
> >
> > If I enable OpenVPN I get a message that one firewall rule failed to
> apply.  The client (Tunnelblick) connects okay, but I can only ping the
> gateway (e.g. 192.168.xx.1) but if I ping anything inside my network I get
> no response... packet dropped message, suggesting firewall config not
> right...
> > AIF:Dropped FORWARD packet: IN=tun0 OUT=br1 MAC= SRC=10.8.0.2
> DST=192.168.xx.6 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=5266 PROTO=ICMP TYPE=8
> CODE=0 ID=3177 SEQ=0
> >
> > Meanwhile trying ipsec, I get a message from my client side (Apple
> built-in VPN) that it failed to verify certificate...
> > 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
> > 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
> > 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error
> strings: ---------------.
> > 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error
> strings: ---------------.
> > 11/3/15 2:35:13.294 PM racoon[27040]:
> -----------------------------------------------------.
> > 11/3/15 2:35:13.294 PM racoon[27040]:
> -----------------------------------------------------.
> > 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not
> verified.
> > 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not
> verified.
> > I've googled, but not found anything that helps (I have moved the
> certificated into system keychain and set "always trust".
> >
> > And with PPTP I get a message that the remote end terminated the
> connection...
> > 11/3/15 2:35:54.854 PM pppd[27056]: PPTP connection established.
> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading socket :
> Connection reset by peer
> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading header :
> read -1, expected 12 bytes
> > 11/3/15 2:35:54.919 PM pppd[27056]: PPTP hangup
> > 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnecting...
> > 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnected
> > Nov  3 14:35:54 pbx daemon.info
> >  pptpd[30592]: CTRL: Starting call (launching pppd, opening GRE)
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: pty_fd = 7
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: tty_fd = 8
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: I wrote 32 bytes to
> the client.
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Sent packet to
> client
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
> program binary = /usr/sbin/pppd
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
> local address = 192.168.xx.240
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher):
> remote address = 192.168.xx.232
> >
> > Nov  3 14:35:54 pbx daemon.err pptpd[30592]: GRE:
> read(fd=7,buffer=8058640,len=8196) from PTY failed: status = -1 error =
> Input/output error, usually caused by unexpected termination of pppd, check
> option syntax and pppd logs
> > Nov  3 14:35:54 pbx daemon.err pptpd[30592]: CTRL: PTY read or GRE write
> failed (pty,gre)=(7,8)
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Reaping child
> PPP[30593]
> > Nov  3 14:35:54 pbx
> > daemon.info
> >  pptpd[30592]: CTRL: Client 157.130.31.226 control connection finished
> > Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Exiting now
> >
> >
> > So, right now I'm not able to connect by OVPN, IPSEC or PPTP.
> >
> > Help !
> >
> > Thanks
> > David
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>

Am 03.11.2015 um 23:11 schrieb Lonnie Abelbeck <li...@lo...>:

> Hi David,
> 
> For OpenVPN, do you have (or similar) checked...
> 
> Network -> Firewall Configuration -> Firewall Options: _x_ Allow OpenVPN Server tunnel to the [ 1st ] LAN Interface(s)
> 
> If not, that is your problem. Done.
> 
>> From the CLI, the command "arno-iptables-firewall restart" will show how things are being built.
> 
> As far as IPSec, clearly there is a certificate issue, could well be a OS X issue with trusting the cert.
> 
> Don't even think about PPTP :-)
> 
> Focus on OpenVPN.
> 
> Lonnie

And use Fossil to document your changes :-), makes it a lot easier to track what you have done.

> On Nov 3, 2015, at 1:47 PM, David Kerr <Da...@Ke...> wrote:
> 
>> How can I enable more detail on firewall logging... at the time the iptables rules are built.  
>> 
>> I'm having real trouble getting VPN working again.  I don't know what I did, but I have not used VPN in a long time.
>> 
>> If I enable OpenVPN I get a message that one firewall rule failed to apply.  The client (Tunnelblick) connects okay, but I can only ping the gateway (e.g. 192.168.xx.1) but if I ping anything inside my network I get no response... packet dropped message, suggesting firewall config not right...
>> AIF:Dropped FORWARD packet: IN=tun0 OUT=br1 MAC= SRC=10.8.0.2 DST=192.168.xx.6 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=5266 PROTO=ICMP TYPE=8 CODE=0 ID=3177 SEQ=0
>> 
>> Meanwhile trying ipsec, I get a message from my client side (Apple built-in VPN) that it failed to verify certificate...
>> 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
>> 11/3/15 2:35:13.292 PM racoon[27040]: Error evaluating certificate.
>> 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error strings: ---------------.
>> 11/3/15 2:35:13.294 PM racoon[27040]: ---------------Returned error strings: ---------------.
>> 11/3/15 2:35:13.294 PM racoon[27040]: -----------------------------------------------------.
>> 11/3/15 2:35:13.294 PM racoon[27040]: -----------------------------------------------------.
>> 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not verified.
>> 11/3/15 2:35:13.294 PM racoon[27040]: the peer's certificate is not verified.
>> I've googled, but not found anything that helps (I have moved the certificated into system keychain and set "always trust".
>> 
>> And with PPTP I get a message that the remote end terminated the connection...
>> 11/3/15 2:35:54.854 PM pppd[27056]: PPTP connection established.
>> 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading socket : Connection reset by peer
>> 11/3/15 2:35:54.919 PM pppd[27056]: PPTP error when reading header : read -1, expected 12 bytes
>> 11/3/15 2:35:54.919 PM pppd[27056]: PPTP hangup
>> 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnecting...
>> 11/3/15 2:35:54.920 PM pppd[27056]: PPTP disconnected
>> Nov  3 14:35:54 pbx daemon.info
>> pptpd[30592]: CTRL: Starting call (launching pppd, opening GRE)
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: pty_fd = 7
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: tty_fd = 8
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: I wrote 32 bytes to the client.
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Sent packet to client
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher): local address = 192.168.xx.240
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30593]: CTRL (PPPD Launcher): remote address = 192.168.xx.232
>> 
>> Nov  3 14:35:54 pbx daemon.err pptpd[30592]: GRE: read(fd=7,buffer=8058640,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
>> Nov  3 14:35:54 pbx daemon.err pptpd[30592]: CTRL: PTY read or GRE write failed (pty,gre)=(7,8)
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Reaping child PPP[30593]
>> Nov  3 14:35:54 pbx 
>> daemon.info
>> pptpd[30592]: CTRL: Client 157.130.31.226 control connection finished
>> Nov  3 14:35:54 pbx daemon.debug pptpd[30592]: CTRL: Exiting now
>> 
>> 
>> So, right now I'm not able to connect by OVPN, IPSEC or PPTP.  
>> 
>> Help !
>> 
>> Thanks
>> David

Michael

http://www.mksolutions.info