[sandra <deepaksoni1959@xxxxxxxxx>]

Guy Harris <guy@...> writes:

> Hi, I was searching for about pcap, so came across this link. I need to make 
my own packet sniffer like tcpdump. I am aware of the list of functions used to 
read ,callback fns etc. I wanted to know the list of APIs been called for 
calling libpcap. Can somebody help
> 
> On Sep 28, 2012, at 2:01 PM, albert <alo@...> wrote:
> 
> > What/where is/are the function(s) that determine(s) whether the callback 
for 
> > next_packet_op is going to be pcap_dump() or some other higher level 
routine  ?
> 
> The next_packet_op is a *read* function, not a *write* function, so it would, 
of course, not be set in
> pcap_dump(), as that's a *write*-path routine.
> 
> It's set in the open-for-reading path, either by pcap_check_header() if it's 
a pcap file or
> pcap_ng_check_header() if it's a pcap-ng file.
> 
> The open-offline routines (pcap_open_offline() and pcap_fopen_offline()) try 
calling each of the
> routines in the check_headers[] array, to check whether the file is a file of 
the routine's type.  If so, the
> routine sets the next_packet_op to the appropriate routine for that file type 
and returns 1 to indicate
> that the correct file type has been found.
> 
> > Is this a function that the user must supply ?
> 
> No.  That's all an internal detail of the current libpcap implementation, so 
that programs do *not* have to
> be changed in order to be able to read pcap-ng files.  (The current libpcap 
API limits what types of files can
> be read - the link-layer header type is per-file, not per-packet or per-
interface, in the API, so it
> doesn't support files with multiple link-layer header types - so *full* 
support of pcap-ng files will
> require an additional set of APIs, which programs *would* have to be changed 
to use.  The new APIs will still
> support pcap, however; requiring programs to know whether they're reading 
pcap or pcap-ng or... files is
> an error.)
> 
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@...?subject=unsubscribe
> 
>