Re: Reading Memory as a Device

[Guy Harris <guy () alum mit edu>]

On Sep 4, 2007, at 2:49 AM, Varuna De Silva wrote:

> We as a project try to build an SS7 analyzer which will port data  
> through
> the USB bus.
> For this purpose, We have used an USB IC from FTDI which do this job  
> with
> their custom
> driver. What the driver does is, it will write the data in to the  
> memory.
>
> Now we want to read this raw data and convert it to pcap format after
> removing the
> frame delimiters. How should we start about modifying libpcap if we  
> are to
> read the
> memory from where data has been stored. Can we read data as an when  
> it is
> stored in
> the buffer by this driver which the manufacturer supplies.

I have no idea, as I know nothing about how the driver works or  
transfers data to memory.  That's something you'll have to figure out;  
all I can help you with is how to plug in *your* code for reading  
packet data into libpcap.

> The Tutorial by Carston and Harris deals with network interface cards

If you mean "the tutorial by Carstens and Harris":

        http://www.tcpdump.org/pcap.htm

it doesn't deal *at all* with out to modify libpcap; it deals with how  
to *use* libpcap.  There is no tutorial for how to modify libpcap.

What you would do is:

	1) pick a name or set of names for the device or devices, which will  
be handed to pcap_open_live() to open your SS7 interface rather than a  
regular network interface;

	2) modify the pcap_open_live() routine for the OS on which you're  
doing this - as you later say "linux Char Device", I assume that'll be  
pcap_open_live() in pcap-linux.c - so that it checks for name  
corresponding to one of your devices and, if it matches, call your own  
open routine;

	3) have a separate pcap-???.c file, with a ???_open_live() routine,  
which will open whatever device needs to be opened in order to read  
the raw data;

	4) have that routine allocate a pcap_t structure, clear it, and fill  
it in as appropriate, and return it;

	5) have some of the "as appropriate" involve setting all the "_op"  
pointers in the pcap_t structure:

		read_op should point to a routine that takes, as an argument, a  
pointer to a pcap_t, a count, a pointer to a callback routine, and a  
"u_char *" pointer, and that waits a buffer full of packets to arrive  
and, when it arrives, calls the callback routine for each packet,  
passing it, as arguments, the "u_char *", a pointer to a header giving  
the arrival time of the packet, the packet's length, and the amount of  
packet data captured;

		inject_op should point to a routine that fills in the "errbuf"  
member of the pcap_t with a error message and returns -1, unless you  
plan to support *sending* packets (which I suspect you don't);

		setfilter_op should point to a routine that makes a private copy of  
the filter program passed to it, so that it can later be used by the  
read_op routine to check whether to call the callback routine with the  
packet or just discard the packet;

                setdirection_op can be set to NULL;

                set_datalink_op can be set to NULL;

		set_nonblock_op should be set to a routine that arranges that the  
read_op routine not block waiting for a buffer full of packets to  
arrive, but just return 0 if a buffer full of packets isn't  
immediately available (or, if just setting a file descriptor on a  
device is sufficient, use pcap_setnonblock_fd as the routine);

		get_nonblock_op should be set to a routine that returns an  
indication of whether "non-blocking mode", as described in the  
previous paragraph, is in effect or not (if you used  
pcap_setnonblock_fd, you can just use pcap_getnonblock_fd);

		stats_op should be set to a routine that returns some counts of  
packets received and dropped;

		close_op should be set to a routine that does whatever is necessary  
to close the device.

Also, set "selectable_fd" to some file descriptor on which you can do  
a select() to wait for a buffer full of packets to arrive, set  
"snapshot" to the snapshot length passed in as an argument, and set  
"linktype" to DLT_MTP2.

> Can we treat this set of data stored as a linux Char Device and read  
> it with
> a simple
> char device driver?

Possibly.  How does your device driver work?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.