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

["gilbert HOYEK" <gil_hoyek@xxxxxxxxxxx>]

ok first of all thanks for the great info u gave me , but still i got some 
questions if you dont mind

1-do i have to make modifications to only these functions in pcap-septel.c 
so that my prog could at less sniff packets from my device :

septel_open_live

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.

because there is a lot more in pcap-dag.c like:

delete_pcap_dag(pcap_t *p)
dag_platform_close(pcap_t *p)
atexit_handler(void)
new_pcap_dag(pcap_t *p)
dag_platform_finddevs(pcap_if_t **devlistp, char *errbuf)

dag_setfilter(pcap_t *p, struct bpf_program *fp)
dag_set_datalink(pcap_t *p, int dlt)
dag_get_datalink(pcap_t *p)

2- i did not get this :

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.


3- do i need the full name of my device from /dev/     i.e. : 
septel0,septel1 ....or does the fact that i am comparing my dev to the 
string septel is enough in :
if (strstr(device, "septel")) {
               return septel_open_live(device, snaplen, promisc, to_ms, 
ebuf);






GILBERT HOYEK


> From: Guy Harris <gharris@xxxxxxxxx>
> Reply-To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
> To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
> Subject: Re: [Ethereal-dev] new media support(Intel/Septel cards)
> Date: Sat, 02 Apr 2005 14:49:25 -0800
>
> 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.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/