Re: converting pcapng to pcap

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

On Sep 28, 2012, at 2:01 PM, albert <alo () advancedio com> 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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe