Re: Questions about pcap_read() function

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

On Sep 25, 2007, at 6:19 AM, Varuna De Silva wrote:

> Hello,
>
> I am trying to add support for my device in libpcap(/winpcap) and I  
> have
> some
> doubts regarding the xxx_read() function in the pcap-xxx.c file. This
> function is there
> for the packets to be read in, as I understand. For a previous reply  
> I got
> the following.
>
> > .................. routine that takes, as an argument, apointer 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
>
> What is this buffer full of packets, Shouldnot I worry about this?

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, when it arrives, calls the callback routine for each  
> > packet,passing
> it, as arguments, the
> > "u_char *", a pointer to a header givingthe arrival time of the  
> > packet,
> the packet's length, and
> > the amount of packet data captured;
> What is the difference between packets length and and amount of  
> packet data
> captured?

The native capture mechanisms on most OSes supported by libpcap, and  
the WinPcap driver on Windows, allow a capture device to have a  
"snapshot length".  If a packet longer than the snapshot length is  
captured, the data supplied to libpcap/WinPcap is cut off at the  
snapshot length, so, for example, with a snapshot length of 128, a  
packet 128 bytes or less will be supplied in its entirety, while a  
packet longer than 128 bytes will have only the first 128 bytes  
supported.

This is for use when, for example, you're only interested in TCP's  
behavior, so you only need enough of the packet to include the TCP  
header; specifying a snapshot length sufficient to capture the TCP  
header means that:

	less data is copied into any buffers used by the capture mechanism,  
so less CPU time is used, and the buffers are less likely to overflow  
if there's a high rate of network traffic;

	less data is copied from those buffers to userland, so, again, less  
CPU time is used;

	less data is written to the capture file, so less disk/memory  
bandwidth is used, and less disk space is used.

If a packet is cut short by the snapshot length, the length of the  
packet as received by the host is the packet's length, and the amount  
of that data that's supplied to libpcap is the amount of packet data  
captured.

That's what the "-s" flag in tcpdump, Wireshark, and TShark specifies;  
it can also be specified in the "capture options" dialog box in  
Wireshark.

> I am capturing SS7message frames to be sent to WireShark. does this  
> "packet"
> mean the SS7 frame in my case ?

Yes.

> If So can I capture part of my packet as is depicted by "amount of  
> packet
> data captured"

You could have your code discard any data beyond the snapshot length.

> Now I have given a handle to my device after opening in at  
> xxx_open_live().
> So I have to use
> that handle here to read the data from the device at xxx_read() right!
> please correct me?

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.

> Next we have to remove the frame delimiters(HDLC), to get raw SS7  
> messages.

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

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

> These data will be stored in an
> ring buffer ( implemented
> simply as an array)
> Next is when we access frame by frame with a pointer.
>
> My question is that can all these things go in xxx_read() or only the
> message by message
> access is possible here, and filtering part do we have to do it in  
> another
> thread.

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.

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

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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.