chan_ss7, pcap files and 64bit machines
April 28th, 2008UPDATE: April 29th 2008
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:
