tcpdump mailing list archives
Re: Questions about pcap_read() function
From: "Varuna De Silva" <varunax () gmail com>
Date: Sat, 29 Sep 2007 14:55:05 +0530
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.
Current thread:
- Questions about pcap_read() function Varuna De Silva (Sep 25)
- Questions about pcap_read() function Varuna De Silva (Sep 26)
- Re: Questions about pcap_read() function Guy Harris (Sep 28)
- <Possible follow-ups>
- Re: Questions about pcap_read() function Varuna De Silva (Sep 29)
- Re: Questions about pcap_read() function Guy Harris (Sep 29)