I need a clarification regarding Libpcap
library. What I am doing is instead
of writing the packets on to ethernet interface, I am writing on to the Unix
socket.
I am using Libnet
library for building and injecting the packets. I have modified the
Libnet library for supporting Unix sockets.
For capturing the packets on unix sockets I
am thinking of using Libpcap library.
The idea is some what like this,
The application is a kind of client and
server concept, both running on the same machine and the communication between
them will be happening through Unix sockets. I will build the packet and write
it on to the Unix socket. Simultaneously I will redirect the output to some
File. Yes, I know at a same time two process can not write to the same file. So
for this I will be using Semaphores(or some locking mechanism). Now I have my
data in the File(which is nothing but the raw
packet).
Basically when using libpcap what we do is
call "pcap_open_live()" to obtain a packet descriptor to look at packets on the
network. It takes an argument "device", it is a string that specifies the
network device to open. And then a call to "pcap_dump_open(pcap_t *p, const char
*fname)"is made to open a "savefile" for writing, where "p" is the pcap struct
returned by the "pcap_open_live()" , fname specifies the name of the file to
open.
But in my case(ie unix socket), I am
already having the file which is in the "tcpdump" format. And Instead of using
"pcap_open_live()", I will use "pcap_open_offline(const char *fname, char
*errbuf)", which will give me the pcap handle as the return value. This pcap
handle I will for further processing.
The thing is, basically pcap also uses
tcpdump format only. Pcap can interpret tcpdump format. And the file to which I
will be redirecting the output will have the data as the raw packet which won't
be a problem for pcap to interpret. This is what is my
understanding.
I want your comments on this. Is it ok or
there is any problem. If there is then what it can be or what it is. Please give
me your valuable inputs.
Regards,
Santosh
