Wireshark · Ethereal-dev: Re: [Ethereal-dev] new media support(Intel/Septel cards)

[Guy Harris <gharris@xxxxxxxxx>]

gilbert HOYEK wrote:
> hi i would like to  be able to capture online traffic using Ethereal  on 
> Intel/Septel cards used in ss7 messages transfer .....

These are really tcpdump-workers@xxxxxxxxxxx questions, but I'll answer 
them here.  (I'd CC tcpdump-workers, but the e-mail address I'm 
subscribed to on this list is different from the one on tcpdump-workers, 
and both lists check the from address, so I can't send a single message 
to both lists.)

> for this reasoni must first assign a new DLT in libpcap . as it is 
> mentioned in the savefile.c of libpcap it should be one of these :
>
> #define LINKTYPE_RAWSS7         139                  /* see rawss7.h for */
> #define LINKTYPE_RAWSS7_MTP2    140           /* information  on these */
> #define LINKTYPE_RAWSS7_MTP3    141             /* definitions */
> #define LINKTYPE_RAWSS7_SCCP    142
>
> i think i should choose 139 or 140 for the simple reason that my ss7 
> packets includes MTP2 protocols

"Includes" meaning "some of the packets are MTP2", or "includes" meaning 
"all packets are MTP2 packets with MTP2 headers"?

> so plz tell me which one i choose ...

If all the packets are MTP2 packets, LINKTYPE_RAWSS7_MTP2 is the right 
answer, so the DLT_ value would be 140.

If only some packets are MTP2 packets, it might be that *none* of those 
are appropriate, or that we'd have to use LINKTYPE_RAWSS7 (which was 
recently un-reserved) and have some header that indicates the packet type.

> Next i would like to know how to impement it ...it means what changes to 
> source codes of libpcap i have to do so that it works ...

You'd have to modify pcap-linux.c if this is on Linux, pcap-bpf.c if 
this is on some form of BSD, pcap-dlpi.c if this is Solaris, 
pcap-win32.c if this is on Windows, etc..

I'll give examples for Linux here.

For pcap-linux.c, in the current CVS version of libpcap (or maybe the 
0.8.3 version), look for the code that's in HAVE_DAG_API #ifdefs.  You 
will have to pick a name or names for the Septel devices that are 
different from regular Linux interface names, so that, for example, 
anything beginning with "eth" followed by a number would be a bad choice.

In "pcap_open_live()", there's code that checks for names that contain 
"dag":

#ifdef HAVE_DAG_API
        if (strstr(device, "dag")) {
                return dag_open_live(device, snaplen, promisc, to_ms, 
ebuf);
        }
#endif /* HAVE_DAG_API */

You would add similar code, such as

#ifdef HAVE_SEPTEL_API
        if (strstr(device, "septel")) {
                return septel_open_live(device, snaplen, promisc, 
to_ms, ebuf);
        }
#endif /* HAVE_SEPTEL_API */

It appears from one of the Intel manuals for their driver that the 
"/dev" nodes for the Septel cards on Linux have names of the form 
"/dev/septelN", so calling the devices on which you capture "septelN", 
for example "septel0", matching the names of the "/dev" entries, would 
probably be the right answer.

Those are all the changes you'd need to pcap-linux.c.

You'd then write a "pcap-septel.c" file, which would contain 
"septel_open_live()".  It'd use the "device" argument to determine what 
device to use.

As I understand it, SS7 links are point-to-point links, so the "promisc" 
argument would be ignored.

Similarly, you can ignore the "to_ms" argument, unless there's a way to 
arrange that the driver supply multiple packets at a time, with a 
timeout so it doesn't wait forever to supply the packets - you'd use the 
timeout in that case.

"snaplen" would be used to, if possible, arrange that the device and the 
driver supply no more than a specified number of bytes of packet data 
for captured packets.  If the board and its firmware don't support that, 
the libpcap code you write would have to stop copying at the snaplen value.

You would have to write:

	a "read" routine, to read packets from the device and supply them;

	a "stats" routine, to supply packet counts;

	a "close" routine, to close the device.

You could optionally supply an "inject" routine (with the current CVS 
version of libpcap), to send packets.  If you don't, just have it return 
-1 and put an error message into the "errbuf" member of the "pcap_t" 
structure supplied to it.

You'd have to set the various "_op" members of the "pcap_t" structure to 
point to those routines.  Set the "set_datalink_op" member to NULL.

I don't know how reading packets from the device works, so I don't know 
how non-blocking mode would be implemented, so I don't know whether 
you'd be able to use the standard setnonblock and getnonblock routines 
or not.

You'd also modify the "init_linktype()" routine in "gencode.c" to, for 
the new DLT_ value, set "off_linktype", "off_nl", and "off_nl_nosnap" to 
-1.  That would mean that you wouldn't be able to do any filtering 
except by matching 1-byte, 2-byte, or 4-byte quantities in the packet.