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
- Prev by Date: Re: [Wireshark-dev] [REPOST][PATCH] update USB dissector
- Next by Date: Re: [Wireshark-dev] protocol decoding module
- Previous by thread: Re: [Wireshark-dev] [REPOST][PATCH] update USB dissector
- Next by thread: [Wireshark-dev] [PATCH] Revised pop-up menus for Copy and Export
- Index(es):