Discussion:
converting pcapng to pcap
Albert Lo
2012-09-28 17:39:01 UTC
Permalink
I would like to know where I can find the source files for editcap.
What libpcap API's are being called to convert .pcapng to .pcap with the following cmd?
editcap -F libpcap -T ether file.pcapng file.pcap
Thx.
Cheers,
Albert
Jakub Zawadzki
2012-09-28 17:54:09 UTC
Permalink
Hi,
Post by Albert Lo
What libpcap API's are being called to convert .pcapng to .pcap with the following cmd?
We use our own library (wiretap) to read and write capture files.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2012-09-28 18:11:14 UTC
Permalink
Post by Albert Lo
I would like to know where I can find the source files for editcap.
What libpcap API's are being called to convert .pcapng to .pcap with the following cmd?
editcap -F libpcap -T ether file.pcapng file.pcap
As Jakub noted, we don't use libpcap to read or write capture files.

However, if you convert pcap-ng to pcap with the command

tcpdump -r file.pcapng -w file.pcap

on a system with libpcap 1.1.0 or later, the APIs used are

pcap_open_offline(), to open the input file;

pcap_loop(), to read the packets;

pcap_close(), to close the input file;

pcap_dump_open(), to open the output file;

pcap_dump(), to write to the output file;

pcap_dump_close(), to close the output file.

That will, of course, only work if the file can actually be converted to pcap without damaging it, i.e. if all the interfaces in the pcap-ng file have the same link-layer type. If they don't, the file cannot be represented in a pcap file in any form that will actually give the write answer if you try to read it (so "-T ether" isn't going to fix that problem with editcap).
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
albert
2012-09-28 18:43:29 UTC
Permalink
Post by Guy Harris
However, if you convert pcap-ng to pcap with the command
tcpdump -r file.pcapng -w file.pcap
on a system with libpcap 1.1.0 or later, the APIs used are
pcap_open_offline(), to open the input file;
pcap_loop(), to read the packets;
pcap_close(), to close the input file;
pcap_dump_open(), to open the output file;
pcap_dump(), to write to the output file;
pcap_dump_close(), to close the output file.
Thank you for the prompt response.
If you could tolerate a couple more newbie questions.....

I'm assuming that the meat of the .pcapng to .pcap conversion is done in the
pcap_handler callback for pcap_offline_read(). Is this correct ?

If so, how/where does the callback function for pcap_offline_read() get pre-
assigned?

Much appreciated for your time in this matter.


Cheers,
Albert


___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2012-09-28 19:13:45 UTC
Permalink
Post by albert
I'm assuming that the meat of the .pcapng to .pcap conversion is done in the
pcap_handler callback for pcap_offline_read(). Is this correct ?
No.

It's done in several places.

In a libpcap/WinPcap-based application:

When reading a packet:

the internal file-read routine is called (from pcap_loop(), pcap_dispatch(), pcap_next(), or pcap_next_ex()) and, in 1.1 and later, that calls the appropriate next_packet_op routine for the file type in question (pcap or pcap-ng);

the next_packet_op routine gets the next packet (first packet, if no packet has been read yet), constructs a struct pcap_pkthdr containing the time stamp, on-the-network packet length, and captured data length for the packet, and calls the callback routine, handing it a pointer to the struct pcap_pkthdr, a pointer to the packet data, and the "user data" pointer;

the callback processes the packet, with no knowledge of whether it came from a pcap or pcap-ng file (or, possibly, other file types in the future).

When writing a packet:

pcap_dump() is called, and, using the struct pcap_pkthdr and raw packet data, writes a pcap packet.

Half of the work is done in the next_packet_op, which converts the packet data in the file, in whatever form it might be in that particular file format, to a struct pcap_pkthdr and a lump of raw packet data, and the other half of the work is done in pcap_dump(), which takes a struct pcap_pkthdr and a lump of raw packet data and writes it out in pcap format.

So:

if the callback *is* pcap_dump() (whose API was designed to allow it to act as a callback for pcap_loop() or pcap_dispatch()), only half of the format-conversion work is done in the callback;

if the callback isn't pcap_dump(), just some routine that calls pcap_dump(), none of the format-conversion work is done in the callback.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
albert
2012-09-28 21:01:23 UTC
Permalink
Post by Guy Harris
if the callback *is* pcap_dump() (whose API was designed to allow it to
act as a callback for pcap_loop() or
Post by Guy Harris
pcap_dispatch()), only half of the format-conversion work is done in the
callback;
Post by Guy Harris
if the callback isn't pcap_dump(), just some routine that calls
pcap_dump(), none of the
Post by Guy Harris
format-conversion work is done in the callback.
Thanks again for your response.
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 ?
Is this a function that the user must supply ?


thx.
Cheers,
Albert


___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Guy Harris
2012-09-28 21:46:20 UTC
Permalink
Post by albert
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.
Post by albert
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-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
sandra
2013-04-03 09:27:24 UTC
Permalink
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
Post by albert
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.
Post by albert
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.)
___________________________________________________________________________
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Loading...