Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-04 Thread Tony Mountifield
In article <20180404133024.kpidrkuiyjoqd...@xorcom.com>,
Tzafrir Cohen  wrote:
> On Wed, Apr 04, 2018 at 11:28:33AM +, Tony Mountifield wrote:
> > In article 
> > ,
> > Richard Mudgett  wrote:
> > > 
> > > The libpri makefile doesn't install things for 64 bit systems in the right
> > > place [1] without your help.  You'll need to specify where to install the
> > > library on the command line for your system:
> > > 
> > > sudo make install libdir=/usr/lib64
> > > 
> > > 
> > > Richard
> > > 
> > > [1] https://issues.asterisk.org/jira/browse/PRI-100
> > 
> > Ah, thanks. I did in fact discover the following 64-bit libraries were
> > installed into /usr/lib instead of /usr/lib64:
> > 
> > 1. From DAHDI, libtonezone.so
> 
> dahdi-tools 2.11 now uses autoconf. It still installs to /usr/lib or is
> it an older version?

I compiled dahdi-linux-complete-2.11.1+2.11.1, by doing:

make
make install
make config
make -C tools install-config

In fact I did all the above with a DESTDIR=$DESTDIR appended to each line,
as I was building a binary bundle for system building.

Before doing so I also did:

mkdir -p $DESTDIR/etc/udev/rules.d $DESTDIR/etc/rc.d/init.d 
$DESTDIR/etc/sysconfig/network-scripts

Maybe that defeated autoconf, and made it default to /usr/lib?
If I had also done a mkdir $DESTDIR/usr/lib64 before building, maybe
autoconf would have found it?

But in any case, running ldconfig made everything get found:

[root@bridge05 ~]# ldconfig -p | fgrep -v lib64
552 libs found in cache `/etc/ld.so.cache'
libtonezone.so.2 (libc6,x86-64) => /usr/lib/libtonezone.so.2
libtonezone.so (libc6,x86-64) => /usr/lib/libtonezone.so
libpri.so.1.4 (libc6,x86-64) => /usr/lib/libpri.so.1.4
libpri.so (libc6,x86-64) => /usr/lib/libpri.so
libasteriskssl.so.1 (libc6,x86-64) => /usr/lib/libasteriskssl.so.1
libasteriskssl.so (libc6,x86-64) => /usr/lib/libasteriskssl.so
[root@bridge05 ~]#

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-04 Thread Tzafrir Cohen
On Wed, Apr 04, 2018 at 11:28:33AM +, Tony Mountifield wrote:
> In article 
> ,
> Richard Mudgett  wrote:
> > 
> > The libpri makefile doesn't install things for 64 bit systems in the right
> > place [1] without your help.  You'll need to specify where to install the
> > library on the command line for your system:
> > 
> > sudo make install libdir=/usr/lib64
> > 
> > 
> > Richard
> > 
> > [1] https://issues.asterisk.org/jira/browse/PRI-100
> 
> Ah, thanks. I did in fact discover the following 64-bit libraries were
> installed into /usr/lib instead of /usr/lib64:
> 
> 1. From DAHDI, libtonezone.so

dahdi-tools 2.11 now uses autoconf. It still installs to /usr/lib or is
it an older version?

> 
> 2. From LibPRI, libpri.so
> 
> 3. From Asterisk, libasteriskssl.so
> 
> I found that running "ldconfig" caused them all to be discovered:
> 
> [root@bridge05 ~]# ldd /usr/sbin/asterisk
> linux-vdso.so.1 =>  (0x7ffc77ff9000)
> libasteriskssl.so.1 => /usr/lib/libasteriskssl.so.1 
> (0x7efeae1d4000)
> libc.so.6 => /lib64/libc.so.6 (0x7efeade4)
> libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7efeadaed000)
> libz.so.1 => /lib64/libz.so.1 (0x7efead8d7000)
> libm.so.6 => /lib64/libm.so.6 (0x7efead653000)
> libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x7efead3c4000)
> libssl.so.10 => /usr/lib64/libssl.so.10 (0x7efead158000)
> libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x7efeacd73000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7efeacb6f000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7efeac952000)
> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7efeac731000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x7efeac517000)
> /lib64/ld-linux-x86-64.so.2 (0x7efeae3d6000)
> libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7efeac2d3000)
> libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7efeabfec000)
> libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7efeabde8000)
> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7efeabbbc000)
> libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7efeab9b1000)
> libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7efeab7ae000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x7efeab58f000)
> [root@bridge05 ~]# ldd /usr/sbin/dahdi_cfg
> linux-vdso.so.1 =>  (0x7fff6cbaa000)
> libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x7f862f74a000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f862f52d000)
> libm.so.6 => /lib64/libm.so.6 (0x7f862f2a9000)
> libc.so.6 => /lib64/libc.so.6 (0x7f862ef15000)
> /lib64/ld-linux-x86-64.so.2 (0x7f862f97e000)
> [root@bridge05 ~]# ldd /usr/lib/asterisk/modules/chan_dahdi.so
> linux-vdso.so.1 =>  (0x7ffe8b1df000)
> libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x7f54adde4000)
> libpri.so.1.4 => /usr/lib/libpri.so.1.4 (0x7f54adb68000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f54ad94b000)
> libc.so.6 => /lib64/libc.so.6 (0x7f54ad5b7000)
> libm.so.6 => /lib64/libm.so.6 (0x7f54ad333000)
> /lib64/ld-linux-x86-64.so.2 (0x7f54ae2d3000)
> [root@bridge05 ~]#
> 
> So I assumed that all should be ok, otherwise the executables would fail to 
> run
> (I initially discovered this when dahdi_cfg couldn't find libtonezone).
> 
> Would there be any subtle issues with the 64-bit libraries being loaded
> from /usr/lib instead of /usr/lib64?
> 
> Should Asterisk and DAHDI builds also be updated to use /usr/lib64 when
> building on a 64-bit OS? Or the build instructions?

dahdi-tools: not AFAIK.

-- 
   Tzafrir Cohen
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-04 Thread Tony Mountifield
In article ,
Tony Mountifield  wrote:
> In article 
> 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-04 Thread Tony Mountifield
In article ,
Richard Mudgett  wrote:
> 
> The libpri makefile doesn't install things for 64 bit systems in the right
> place [1] without your help.  You'll need to specify where to install the
> library on the command line for your system:
> 
> sudo make install libdir=/usr/lib64
> 
> 
> Richard
> 
> [1] https://issues.asterisk.org/jira/browse/PRI-100

Ah, thanks. I did in fact discover the following 64-bit libraries were
installed into /usr/lib instead of /usr/lib64:

1. From DAHDI, libtonezone.so

2. From LibPRI, libpri.so

3. From Asterisk, libasteriskssl.so

I found that running "ldconfig" caused them all to be discovered:

[root@bridge05 ~]# ldd /usr/sbin/asterisk
linux-vdso.so.1 =>  (0x7ffc77ff9000)
libasteriskssl.so.1 => /usr/lib/libasteriskssl.so.1 (0x7efeae1d4000)
libc.so.6 => /lib64/libc.so.6 (0x7efeade4)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7efeadaed000)
libz.so.1 => /lib64/libz.so.1 (0x7efead8d7000)
libm.so.6 => /lib64/libm.so.6 (0x7efead653000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x7efead3c4000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x7efead158000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x7efeacd73000)
libdl.so.2 => /lib64/libdl.so.2 (0x7efeacb6f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7efeac952000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7efeac731000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7efeac517000)
/lib64/ld-linux-x86-64.so.2 (0x7efeae3d6000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7efeac2d3000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7efeabfec000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7efeabde8000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7efeabbbc000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7efeab9b1000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7efeab7ae000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x7efeab58f000)
[root@bridge05 ~]# ldd /usr/sbin/dahdi_cfg
linux-vdso.so.1 =>  (0x7fff6cbaa000)
libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x7f862f74a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f862f52d000)
libm.so.6 => /lib64/libm.so.6 (0x7f862f2a9000)
libc.so.6 => /lib64/libc.so.6 (0x7f862ef15000)
/lib64/ld-linux-x86-64.so.2 (0x7f862f97e000)
[root@bridge05 ~]# ldd /usr/lib/asterisk/modules/chan_dahdi.so
linux-vdso.so.1 =>  (0x7ffe8b1df000)
libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x7f54adde4000)
libpri.so.1.4 => /usr/lib/libpri.so.1.4 (0x7f54adb68000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f54ad94b000)
libc.so.6 => /lib64/libc.so.6 (0x7f54ad5b7000)
libm.so.6 => /lib64/libm.so.6 (0x7f54ad333000)
/lib64/ld-linux-x86-64.so.2 (0x7f54ae2d3000)
[root@bridge05 ~]#

So I assumed that all should be ok, otherwise the executables would fail to run
(I initially discovered this when dahdi_cfg couldn't find libtonezone).

Would there be any subtle issues with the 64-bit libraries being loaded
from /usr/lib instead of /usr/lib64?

Should Asterisk and DAHDI builds also be updated to use /usr/lib64 when
building on a 64-bit OS? Or the build instructions?

Regards
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-04 Thread Tony Mountifield
In article 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Antony Stone
On Wednesday 04 April 2018 at 00:30:00, Richard Mudgett wrote:

> On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson  wrote:
> > On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield 
> > > Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9
> > > from online repositories using a kickstart build.
> 
> The libpri makefile doesn't install things for 64 bit systems in the right
> place [1] without your help.  You'll need to specify where to install the
> library on the command line for your system:
> 
> sudo make install libdir=/usr/lib64
> 
> [1] https://issues.asterisk.org/jira/browse/PRI-100

Isn't this handled by the CentOS package manager?


Antony.

-- 
I know I always wanted to be somebody, but I guess I should have been more 
specific.

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Richard Mudgett
On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson  wrote:

> On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield 
> wrote:
> > In article 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Matt Fredrickson
On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield  wrote:
> In article 
> 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Tony Mountifield
In article 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Matt Fredrickson
On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield  wrote:
> I have some more investigation to do on this, but I wanted to see if anyone
> here had any insight into the issue I've run into.
>
> The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one
> of several systems that have been running without issue since 2010/2011. They
> have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen
> 5 card), libpri 1.2.8 and asterisk 1.2.32.
>
> Having taken this particular system out of production, I updated it to CentOS
> 6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version
> of Asterisk is required at the moment due to custom modifications).
> This appears to work fine.
>
> In order to reduce the number of different versions we support, I reinstalled
> the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using
> the same versions as above.
>
> However, for reasons I don't understand, the 64-bit version was logging
> frequent PRI errors every few minutes:
>
> [Apr  1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
>
> This left the PRIs in strange states - trying to make a call failed with 
> cause 101.
>
> So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs
> were no longer present, and the system operated normally again.
>
> So my question is: does anyone have any clues why there would be a difference
> in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into
> anything similar?


That does seem quite odd.  If I remember right, those messages would
come up if it looked like the other end hadn't received a message when
it thought it should have.  I can't think of anything that would
particularly impact 64 bit systems versus 32 bit systems in that
domain (ISDN real time message timing, etc).  Are you sure there's
nothing else different (kernel version or something else like that)?
Maybe also run a patlooptest on the spans in question to make sure
that they're running cleanly.

Matthew Fredrickson

>
> Cheers
> Tony
> --
> Tony Mountifield
> Work: t...@softins.co.uk - http://www.softins.co.uk
> Play: t...@mountifield.org - http://tony.mountifield.org
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users



-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


[asterisk-users] Strange problem with PRI on 64-bit?

2018-04-03 Thread Tony Mountifield
I have some more investigation to do on this, but I wanted to see if anyone
here had any insight into the issue I've run into.

The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one
of several systems that have been running without issue since 2010/2011. They
have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen
5 card), libpri 1.2.8 and asterisk 1.2.32.

Having taken this particular system out of production, I updated it to CentOS
6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version
of Asterisk is required at the moment due to custom modifications).
This appears to work fine.

In order to reduce the number of different versions we support, I reinstalled
the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using
the same versions as above.

However, for reasons I don't understand, the 64-bit version was logging
frequent PRI errors every few minutes:

[Apr  1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)

This left the PRIs in strange states - trying to make a call failed with cause 
101.

So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs
were no longer present, and the system operated normally again.

So my question is: does anyone have any clues why there would be a difference
in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into
anything similar?

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users