Re: Questions about pcap_read() function

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

Varuna De Silva wrote:

> And when we use this FT_Read(), we wait and read in 3968 bytes at a time

So, presumably, if the device has more than 3968 bytes available, only the
first 3968 bytes are read?

What if it has fewer than 3968 bytes available?  Does the read return only
what's available?

If no bytes are available, does FT_Read() just block waiting for data to
be available?

> 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.

So the device un-does the bit stuffing, but, in order to preserve frame
boundaries, the data it hands to the host is byte-stuffed?

> > 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,

So what you'd do in the xxx_read() routine would be to call FT_Read(), and
then scan through the buffer, do the filtering, and, for each SS7 frame
you extract through the buffer, call the callback routine.

>  * caplen -  would be the same as packetlen

If there's a snapshot length specified (it'd be in the snapshot field of
the pcap_t structure), you might want to make caplen be the minimum of
packetlen and the snapshot length; your device will still copy the entire
packet to the host, but, at least, the application will save only the
bytes it asked for.

> > 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()

Packet data isn't guaranteed to remain available if the xxx_read() routine
is called (once the callback routine returns, the application cannot
assume that the packet data is still available - if it wants to use it
after the callback routine returns, or after another call to pcap_next()
or pcap_next_ex(), it has to make a copy of it), so that's not necessary.

> 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.

Yes.  If the cnt argument is non-zero, you should call the callback
routine no more than cnt times; any frames that are still in your buffer
should be left there, and processed by any subsequent xxx_read() call
*before* reading another bufferful of frames from the device..  If cnt is
zero, keep processing frames and calling the callback routine until you
run out of frames in the buffer.

> > 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?

I guess that works, but it's not really necessary - adding it to the
pcap_md structure will work, too, and means you don't have to modify any
of the packet.dll code (and also means that if there's a driver for your
device for some form of UN*X, you might be able to use the same code).

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