Wireshark-dev: Re: [Wireshark-dev] Option to allow processing of unrecognisedData-link level PC

From: "Douglas Pratley" <Douglas.pratley@xxxxxxxxxx>
Date: Tue, 6 Feb 2007 09:14:41 -0000
Thanks for the suggestion from yourself and Anders. It looks like
(together with editing the file's DLT) this will do nicely.

I hadn't noticed the DLT User dissector functionality before - I've
managed to get it working, but is there any documentation on it? I can't
find any in the user guide or on the Wiki.

Cheers

Doug

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Luis Ontanon
Sent: 05 February 2007 16:53
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Option to allow processing of
unrecognisedData-link level PCAP file

If the DLT is to be a "stadard" one why not register it?

If it is a private one why not use DLTS USER0..USER15. There's the DLT
User A-D "dissector" in preferences that allow you to specify any
given dissector to be used against pcap files with those
encapsulations (I often do).

Luis


On 2/5/07, Douglas Pratley <Douglas.pratley@xxxxxxxxxx> wrote:
> Hi guys
> At the moment, if Wireshark comes across an unexpected data-link level
type
> in the global header when reading a PCAP file, it completely rejects
the
> file. This doesn't allow the user to apply any intelligence, e.g. by
> manipulating the "wtap_encap" dissector table using Lua.
>
>
>
> A quick hack prototype suggests that it is possible to read unknown or
> mis-labelled data; the frame dissector just hands it off to the data
> dissector.
>
>
>
> a) Would adding an option allowing unrecognised data to be read in
from a
> PCAP file cause any side-effects that I haven't spotted? The only
changes
> other than setting up the option would be in libpcap.c:libpcap_open,
so that
> it would continue processing an unrecognised type.
>
>
>
> b) What would the best way be of adding this option? My first thought
was to
> make it a preference, but the wiretap library has no dependencies on
the
> epan module where the preferences are. It looks like it would take
some
> careful wiring to add in the option without introducing a dependency
(which
> I think would break some of the apps). Setting up a new (non-protocol)
> preference might also have to be duplicated across tshark and
wireshark,
> which is ugly.
>
>
>
> Cheers
>
>
>
> Doug
>
> __________________________________________
>  Douglas Pratley
>  t +44 845 050 7640 | f +44 845 644 5436
>  a Detica | PO Box 383 | Horley | Surrey | RH6 7WX | UK
>  ______________________________________________
>  www.detica.com
>
>
>
>
>  This message should be regarded as confidential. If you have received
this
> email in error please notify the sender and destroy it immediately.
>  Statements of intent shall only become binding when confirmed in hard
copy
> by an authorised signatory. The contents of this email may relate to
> dealings with other companies within the Detica Group plc group of
> companies.
>
>  Detica Limited is registered in England under No: 1337451.
>
>  Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP,
> England.
>
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>


-- 
This information is top security. When you have read it, destroy
yourself.
-- Marshall McLuhan
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev