Wireshark-dev: Re: [Wireshark-dev] Custom link layer type for logging additional data
Date: Thu, 27 Nov 2014 13:04:07 +0530
Guy,

Thanks for your reply. I will follow the procedure when I have to checkin the code (I have not done that as of now).

My question is more about, 'is it right to use another link type to log additional information about the packet ?' . The additional information is not 'really'  another link layer header.

-anil

On Thu, Nov 27, 2014 at 12:51 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Nov 26, 2014, at 8:18 PM, Anil <anilkumar911@xxxxxxxxx> wrote:

> Hi,
>
> During packet capture, I want to log additional data other than what's in the ethernet packet and the per packet pcap header. So, I have created a custom header and am logging additional information into this.
>
> I have modified  pcap_to_wtap_map[] to add another mapping to add another link type.

And you registered the LINKTYPE_ value that you're using as an index into that array with tcpdump-workers@xxxxxxxxxxxxxxxxx, right?  As the comment before that array says:

/*
 * Map link-layer header types (LINKTYPE_ values) to Wiretap encapsulations.
 *
 * Either LBL NRG wasn't an adequate central registry (e.g., because of
 * the slow rate of releases from them), or nobody bothered using them
 * as a central registry, as many different groups have patched libpcap
 * (and BPF, on the BSDs) to add new encapsulation types, and have ended
 * up using the same DLT_ values for different encapsulation types.
 *
 * The Tcpdump Group now maintains the list of link-layer header types;
 * they introduced a separate namespace of LINKTYPE_ values for the
 * values to be used in capture files, and have libpcap map between
 * those values in capture file headers and the DLT_ values that the
 * pcap_datalink() and pcap_open_dead() APIs use.  See
 * http://www.tcpdump.org/linktypes.html for a list of LINKTYPE_ values.
 *
 * In most cases, the corresponding LINKTYPE_ and DLT_ values are the
 * same.  In the cases where the same link-layer header type was given
 * different values in different OSes, a new LINKTYPE_ value was defined,
 * different from all of the existing DLT_ values.
 *
 * This table maps LINKTYPE_ values to the corresponding Wiretap
 * encapsulation.  For cases where multiple DLT_ values were in use,
 * it also checks what <pcap.h> defineds to determine how to interpret
 * them, so that if a file was written by a version of libpcap prior
 * to the introduction of the LINKTYPE_ values, and has a DLT_ value
 * from the OS on which it was written rather than a LINKTYPE_ value
 * as its linktype value in the file header, we map the numerical
 * DLT_ value, as interpreted by the libpcap with which we're building
 * Wireshark/Wiretap interprets them (which, if it doesn't support
 * them at all, means we don't support them either - any capture files
 * using them are foreign, and we don't hazard a guess as to which
 * platform they came from; we could, I guess, choose the most likely
 * platform), to the corresponding Wiretap encapsulation.
 *
 * Note: if you need a new encapsulation type for libpcap files, do
 * *N*O*T* use *ANY* of the values listed here!  I.e., do *NOT*
 * add a new encapsulation type by changing an existing entry;
 * leave the existing entries alone.
 *
 * Instead, send mail to tcpdump-workers@xxxxxxxxxxxxxxxxx, asking for
 * a new LINKTYPE_/DLT_ value, and specifying the purpose of the new
 * value.  When you get the new LINKTYPE_/DLT_ value, use that numerical
 * value in the "linktype_value" field of "pcap_to_wtap_map[]".
 */

If you do not request a value from tcpdum-workers@xxxxxxxxxxxxxxxxx, but instead choose your own value, none of your changes to Wireshark adding that value will ever be accepted.  You ***MUST*** first get an official value.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe