Re: Questions about pcap_read() function

["Varuna De Silva" <varunax () gmail com>]

Hello,

Thank you very much for the detailed reply, With your insights, let me
refine my questions as below.

> > Next we have to remove the frame delimiters(HDLC), to get raw SS7
> > messages.
> > ( We had to do it at software level at least for now)
>
> Is that done in your driver, or in your libpcap/WinPcap code?  I.e.,
> when you read from the device's driver, do you get a raw sequence of
> octets, with bit-stuffing and frame delimiters in place, or do you get
> a sequence of SS7 messages, with bit-stuffing and frame delimiters
> removed?

Our device NOW does the HDLC decoding. and it can send the raw packets of
SS7 as
a serial stream of octets. But our USB IC does not support Isochronous
streaming. So we have to buffer these frames in the device and send them in
bulk. When these data bytes are sent, it is stored in a queue implemented by
the
driver. The device Driver API provides a function FT_Read(), which can read
data
from this queue, to the user space( where we work at the moment and have
control
over).

> The buffer full of packets is whatever you read from your device.
> Your device (and its driver) might supply one packet at a time, or
> might buffer up packets and supply multiple packets in a buffer, with
> a timeout so it doesn't wait forever for a full buffer.

and you also say

> So I assume your device fills in a buffer of some sort with the data
> from which you extract the SS7 messages; that buffer would be the
> "buffer full of packets".

And when we use this FT_Read(), we wait and read in 3968 bytes at a time
(For
data streaming optimization), which include Many SS7 frames. This I
understand
is the Buffer full of packets you mention. And these 3968 bytes are in the
form
of a sequence of octets.


In order to Identify the frames within this "Buffer full of packets" , our
device attaches flag "7E" at the beginning of a frame and some other data
including the time stamp at the end of the frame. A SS7 frame would look
like
below. and there are many frames alike within 3968 bytes. I.E in our "BUFFER
FULL OF PACKETS"
 _______________________________________________________
 |      |                                            |         |
|                      |
 | 7E | .........SS7 FRAME ..............|CRC1 | CRC2 | TIMESTAMP  |
 |___ |_________________________|_____|______|_____________|

In order to avoid repetition of 7E we have used Byte Stuffing mechanism.
(Different from HDLC bit stuffing)

> What do you mean by "filtering part"?  When I think of "filtering" in
> the libpcap/WinPcap context, I think of the filter specified by a
> pcap_setfilter() call; that filtering would be done in your xxx_read()
> routine, discarding any packets that don't match the filter, and not
> supplying them to the callback.

The filtering we mean is
  1. To remove the byte stuffing. (Drop Stuffed 7D and inverting of the
     particular bit in the subsequent byte)
  2. To remove the 2 CRC bytes at the end.
  3. To extract the Timestamp
and extract the SS7 frame.

This is what I hope to do for the data in this buffer full of packets,

> > These data will be stored in an ring buffer ( implemented
> > simply as an array)
> > Next is we access frame by frame with a pointer.

> > Next when I callback, for each packet ( a frame if the answer to a
> > previous question is yes) as below
> >
> > callback(user, &pcap_header, dp);
> >
> > Should this dp ( pointer to the data) point to the starting point of
> > a frame
> > stored in the array mentioned above?


I will go from the start of the array, which has these 3968 x 2 bytes
stored,
searching for "7E", The data between two "7E"s would be the SS7 frame with
byte stuffed and CRC and Time stamp at end.For each frame of SS7

 * I will remove the byte stuffing first of all
 * dp   - would be the address of the very next byte to "7E"
 * packetlen - would be Length between 2 "7E"s minus Length of CRC and
TimeStamp
 * caplen -  would be the same as packetlen

> It should point to something that will remain unmodified until the
> next xxx_read() call; it sounds as if that means that it can point
> into the buffer.  If you're using DLT_MTP2 as your DLT_ type, it
> should point to the first byte of an MTP2 SS7 message.

In order to have dp remaining till the next call to xxx_read()
we will allocate, an array of 3968 x 2 bytes, so that we will be sure
the data is safe for two rounds of xxx_read()

Now Do we need to extract all the frames, when we read in one chunk of 3968
bytes? as I understand in septel_read(....,int cnt,....) function, it
processes only a number of packets specified by cnt.

What I have in mind is to get the entire chunk of 3968 and process all the
frames in it, in a particular call to xxx_read() function. But If I have to
comply with this cnt parameter, my idea collides with it. Because then
in every call to xxx_read(), I cant read in, a buffer full of packets,
ie a chunk of 3968 bytes. Please correct me if I am wrong.


> I assume by "handle to [your] device" you mean an internal handle you
> use to read from your device, not the pcap_t that xxx_open_live()
> returns.
>
> If so, then you'd need to store that handle in a location you can find
> given the pcap_t pointer; the right place to put it is probably in the
> "pcap_md" structure defined in pcap-int.h.  You would use that handle
> in the xxx_read() routine.

I have changed the struct ADAPTER (As I remember in Packet32.h) to include
my
handle. So I can have it through the adapter, in pcap_t. Is this alright?


Thank you

Xavier
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.