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.
