hi i would like to request a new DLT_SEPTEL for Intel/Septel cards used in ss7 messages transfer .....
DLT_SEPTEL, or DLT_MTP2/DLT_MTP3/whatever?
Unless there's some extra header on the packet that includes information from the Septel cards, the DLT_ name probably shouldn't mention Septel - if, for example, the packet data starts with an MTP2 header, it should be DLT_MTP2.
i think it's one of 139 140 140 142 .... as it is mentioned in the bpf.h header file ....so plz tell me which one i choose ...
That depends on the header that appears in the packets.
If the packets all start with MTP2 headers, 140, for LINKTYHPE_RAWSS7_MTP2, would be the right choice, and it'd be DLT_MTP2.
If the packets don't have MTP2 headers, and all start with MTP3 headers, 141, for LINKTYPE_RAWSS7_MTP3, would be the right choice, and it'd be DLT_MTP3.
If the packets have neither MTP2 nor MTP3 headers, and all start with SCCP headers, 142, for LINKTYPE_RAWSS7_SCCP, would be the right choice, and it'd be DLT_SCCP.
If the packets don't all have the same headers - for example, if some have MTP2 headers, some have no MTP2 headers but have MTP3 headers, and some have neither MTP2 nor MTP3 headers but have SCCP headers - 139, for LINKTYPE_RAWSS7, would be the right choice, and the header would have to include an indication of what type of headers follow.
Next i would like to know how to impement it ...it means what changes to the source codes of pcap i have to do so that it works ...
To quote my ethereal-dev reply:
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.
And one note I forgot in my ethereal-dev reply:
You'd also want to modify the "pcap_platform_finddevs()" routine to, if you were building with support for the Septel cards, call a routine in "pcap-septel.c" to supply a list of names for the Septel devices, so they show up when interfaces are enumerated (e.g., when Ethereal shows its drop-down list of interfaces, or when Tethereal - or tcpdump, if you add SS7 decoding support to it - are run with the "-D" flag). "pcap_add_if()" is the routine it'd call to add an interface to the list; see, for example, "dag_platform_finddevs()" in "pcap-dag.c".
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
