I believe the issue could be reported to Cisco TAC requesting
correction, instead of hacking heuristics. At the other hand,
did they announce somewhere that they are using libpcap format?
I was googling a bit and found indications how to convert the file
http://www.gossamer-threads.com/lists/engine?post=56109;list=cisco
In one post is mentioned also that upcoming SW release is expected to
create pcap files.
Andrej
On Thu, 15.Mar.07 20:30:01 -0700, Guy Harris wrote:
>
> On Mar 15, 2007, at 8:06 PM, Jeff Morriss wrote:
>
> > I suppose you'll need heuristics like those described in the (long)
> > comments in "wiretap/libpcap.c".
>
> Or like the ones in epan/dissectors/packet-null.c.
>
> Now, if only the fine folks at Cisco had seen some other comments in
> that file, such as
>
> /*
> * 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.
> *
> * For those numerical encapsulation type values that everybody uses
> for
> * the same encapsulation type (which inclues those that some platforms
> * specify different DLT_ names for but don't appear to use), we map
> * those values to the appropriate Wiretap values.
> *
> * For those numerical encapsulation type values that different libpcap
> * variants use for different encapsulation types, we check what
> * <pcap.h> defined to determine how to interpret them, so that we
> * interpret them the way 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).
> *
> * 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@xxxxxxxxxxx, asking for a new
> * DLT_ value, and specifying the purpose of the new value. When you
> * get the new DLT_ value, use that numerical value in the "dlt_value"
> * field of "pcap_to_wtap_map[]".
> */
>
> or
>
> /*
> * To repeat:
> *
> * 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@xxxxxxxxxxx, asking
> for
> * a new DLT_ value, and specifying the purpose of the new
> value.
> * When you get the new DLT_ value, use that numerical value in
> * the "dlt_value" field of "pcap_to_wtap_map[]".
> */
>
> or, in the bpf.h that comes with libpcap:
>
> /*
> * Data-link level type codes.
> *
> * Do *NOT* add new values to this list without asking
> * "tcpdump-workers@xxxxxxxxxxx" for a value. Otherwise, you run the
> * risk of using a value that's already being used for some other
> purpose,
> * and of having tools that read libpcap-format captures not being able
> * to handle captures with your new DLT_ value, with no hope that they
> * will ever be changed to do so (as that would destroy their ability
> * to read captures using that value for that other purpose).
> */
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
