Anders Baekgaard of Dicea ApS (current chan_ss7 maintainers) recommends the following alternative patch. Please note that mtp3d.c will also need to be patched in the same way:

--- chan_ss7.c~ 2008-04-03 09:23:56.000000000 +0200
+++ chan_ss7.c  2008-04-29 08:29:20.000000000 +0200
@@ -249,11 +249,12 @@

 static void dump_pcap(FILE *f, struct mtp_event *event)
 {
+  unsigned int sec  = event->dump.stamp.tv_sec;
   unsigned int usec  = event->dump.stamp.tv_usec -
     (event->dump.stamp.tv_usec % 1000) +
     event->dump.slinkno*2 + /* encode link number in usecs */
     event->dump.out /* encode direction in/out */;

-  fwrite(&event->dump.stamp.tv_sec, sizeof(event->dump.stamp.tv_sec), 1, f);
+  fwrite(&sec, sizeof(sec), 1, f);
   fwrite(&usec, sizeof(usec), 1, f);
   fwrite(&event->len, sizeof(event->len), 1, f); /* number of bytes of packet in file */
   fwrite(&event->len, sizeof(event->len), 1, f); /* actual length of packet */

END UPDATE: April 29th 2008

A quickie for the Google trolls:

While trying to debug some SS7 Nature of Address (NAI) indication issues, I needed to use chan_ss7′s ‘dump’ feature from the Asterisk CLI. It worked fine but the resultant pcap files always failed with messages like:

# tshark -r /tmp/now
tshark: "/tmp/now" appears to be damaged or corrupt.
(pcap: File has 409000-byte packet, bigger than maximum of 65535)

After much digging about and head-against-wall banging, I discovered the issue
is with the packet header in the pcap file. It’s defined by its spec to be:

typedef struct pcaprec_hdr_s {
        guint32 ts_sec;         /* timestamp seconds */
        guint32 ts_usec;        /* timestamp microseconds */
        guint32 incl_len;       /* number of octets of packet saved in file */
        guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

chan_ss7 uses the timeval struct defined by system headers to represent ts_sec and ts_usec. But, on 64bit machines (certainly mine), these values are defined as unsigned long rather than unsigned int (presumably as a step to get over the ‘year 2038 bug’). Hence the packet header is all wrong.

An easy solution is the following patch in mtp.h:

77a78,90
> /*
>  * The packet header in the pcap file (used for the CLI command 'dump') is
defined so has to
>  * have the two time components as unsigned ints. However, on 64bit
machines, the system
>  * timeval struct may use unsigned long. As such, we use a custom version
here:
>  */
> struct _32bit_timeval
> {
>   unsigned int tv_sec;            /* Seconds.  */
>   unsigned int tv_usec;      /* Microseconds.  */
> };
>
>
>
125c138
<       struct timeval stamp;        /* Timestamp */
---
>       struct _32bit_timeval stamp;        /* Timestamp */

There may be a better way – but this works.

This relates to chan_ss7-1.0.0 from http://www.dicea.dk/company/downloads and I have let them know also. It’s also a known issue for the Wireshark developers (although I did not investigate in detail to see what their resolution was for the future). See the following thread from 1999:

• http://www.ethereal.com/lists/ethereal-dev/199908/msg00065.html

To this end, I have written a Nagios plugin which queries Asterisk’s manager interface and executes the pri show spans CLI command (this is Asterisk 1.4 by the way). The script then parses the output to ascertain whether a PRI is up or not.

The actual code to connect to the manager interface and execute the query is simply:

if( ( $astsock = fsockopen( $host, $port, $errno, $errstr, $timeout ) ) === false )
{
    echo "Could not connect to Asterisk manager: $errstr";
    exit( STATUS_CRITICAL );
}

fputs( $astsock, "Action: Login\r\n");
fputs( $astsock, "UserName: $username\r\n");
fputs( $astsock, "Secret: $password\r\n\r\n"); 

fputs( $astsock, "Action: Command\r\n");
fputs( $astsock, "Command: pri show spans\r\n\r\n");

fputs( $astsock, "Action: Logoff\r\n\r\n");

while( !feof( $astsock ) )
{
    $asttext .= fread( $astsock, 8192 );
}

fclose( $astsock );

if( strpos( $asttext, "Authentication failed" ) !== false )
{
    echo "Asterisk manager authentication failed.";
    exit( STATUS_CRITICAL );
}

This plugin is hard coded to English and expects to find Provisioned, Up, Active for a good PRI. For example, the Asterisk implementations that support the pri show spans command that I have access to return one of:

• PRI span 1/0: Provisioned, In Alarm, Down, Active
• PRI span 3/0: Provisioned, Up, Active

I’m actually running a slightly older version of Nagios at the moment, version 1.3. To integrate the plugin, first add the following command definition to an appropriate existing or new file under /etc/nagios-plugings/config/:

define command{
        command_name    check_asterisk_pri
        command_line    /usr/lib/nagios/plugins/check_asterisk_pri.php \\
             -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -w $ARG3$ \\
             -c $ARG4$ -n $ARG5$
}

where $ARG1$ is the Asterisk manager username and $ARG2$ is the password. $ARG3$ and $ARG4$ are the warning and critical thresholds respectively whereby if the number of available PRIs reaches one of these values, the appropriate error condition will be set. Lastly, $ARG5$ is the number of PRIs the plugin should expect to find.

NB: the command_line line above is split for readability but it should all be on the one line.

Now create a test for a host in an appropriate file in /etc/nagios/config/:

define service{
        use                             core-service
        host_name                       hostname.domain.ie
        service_description             Asterisk PRIs
        check_command                   check_asterisk_pri!user!pass!2!1!4
}

Ensure that your Nagios server has permissions to access the Asterisk server via TCP on the Asterisk manager port (5038 by default). If on a public network, this should be done via stunnel or a VPN for security reasons.

Lastly, you’ll need a user with the appropriate permissions and host allow statements in your Asterisk configuration (/etc/asterisk/manager.conf):

[username]
secret = password
deny=0.0.0.0/0.0.0.0
permit=1.2.3.4/255.255.255.255
read = command
write = command

The next version may include support for BRI and Zap FXO ports also. I also plan on a Cacti plug in to show the channels on each PRI (up – on a call, down, etc). In any case, updates will be posted here.

The plug in can be download from: http://www.opensolutions.ie/misc/check_asterisk_pri.php.txt

When running Sangoma’s Setup script from their wanpipe-2.3.4-7 release, the following error occurs when it tries to patch the latest zaptel (version 1.4 checked from SVN revision 2399):

Enable TDMV DCHAN Native HDLC Support & Patch Zaptel ? (y/n) y

Did NOT find the seached str:chan->writen\[chan->inwritebuf\] = amnt;
search_and_replace(zaptel-base.c) failed

Applying the following diff to Setup should solve the problem:

1c1
< #!/bin/sh
---
> #!/bin/bash
6128c6128
< ZAPTEL_C_SEARCH_STR="chan->writen\[chan->inwritebuf\] = amnt;"
---
> ZAPTEL_C_SEARCH_STR="chan->writen\[res\] = amnt;"
6134c6134
<                       chan->writen[chan->inwritebuf] = amnt;"
---
>                       chan->writen[res] = amnt;"

The change from sh to bash was to overcome the following error:

./Setup: 1014: Syntax error: Bad substitution

Finally, it looks like Sangoma’s current wanpipe will not work with linux-2.6.20.x:

/usr/src/wanpipe/kdrvtmp/sdla_xilinx.c:636:62: error: macro "INIT_WORK" passed 3 arguments, but takes just 2
/usr/src/wanpipe/kdrvtmp/sdla_xilinx.c: In function ‘wp_xilinx_init’:
/usr/src/wanpipe/kdrvtmp/sdla_xilinx.c:636: error: ‘INIT_WORK’ undeclared (first use in this function)
/usr/src/wanpipe/kdrvtmp/sdla_xilinx.c:636: error: (Each undeclared identifier is reported only once
/usr/src/wanpipe/kdrvtmp/sdla_xilinx.c:636: error: for each function it appears in.)

It works fine with linux-2.6.19.x.

I have let Sangoma’s support team know of these issues so hopefully they’ll be resolved before anyone has to actually use this post.

Hopefully at some point over the next couple of weeks I may expand this to other more interesting information such as average call duration, etc that can be useful to diagnosing issues almost as they happen.

The Cacti XML can be found here and I just posted the same to Cacti’s own forums here.

The CISCO-POP-MGMT-MIB provides the MIBs for this information and the ones I specifically used (for my AS5300 which are all identical with 4 E1/PRI ports) are cpmDS1ActiveDS0s.0.x (or .1.3.6.1.4.1.9.10.19.1.1.9.1.3.0.x). Replace x with the appropriate port number (0-3) as required.

Explore the available information yourself with:

$ snmpwalk -Os -c <community> <host> .1.3.6.1.4.1.9.10.19