Re: [Wireshark-dev] Fun with Cisco DLT-value usage
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@tcpdump.org, 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@tcpdump.org, 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@tcpdump.org 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@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Fun with Cisco DLT-value usage
Hello List, I'm trying to enable some people to read some captures in libpcap format directly without having to change the binary capture packet first. The packet was captureed using Cisco's ERSPAN feature. In their infinite wisdom, the engineers who implemented that feature chose a dlt-value of 0x71. What is the best way to handle that situation? Doesn someone else use pcap version 2.4 or could that be a way to find out whether it's some Cisco specific stuff oder the regular WTAP_ENCAP_SLL? I'll attach the packet and what I've found out about the packet format so far. ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. msfc-capture.pcap Description: application/cap [EMAIL PROTECTED]:~/work/wireshark/infos/cisco/msfc-capture xxd msfc-capture.pcap 000: d4c3 b2a1 0200 0400 -- pcap header 010: 010: 7100 -- 0x71 (DLT_TYPE) = linux_cooked_capture (of course not) 010: 7507 f845 11d1 0500 -- pcap record header 020: 7a00 7a00 020: 030a 030: 030: 88be -- GRE header 030: 1002 0001 0380 -- ERSPAN header (01: erspan-id) 040: 00d0 b7a7 7480 0015 c721 75c0 0800 4500 -- Ethernet packet 050: 0054 4000 ff01 67a5 0aff ff03 0aff 060: ff01 3c44 0810 0078 7507 f845 17cf 070: 0500 dead babe dead babe dead babe dead 080: babe dead babe dead babe dead babe dead 090: babe dead babe dead babe dead babe dead 0a0: babe rfc2784: 2.1. GRE Header The GRE packet header has the form: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ http://www.cisco.com/en/US/products/hw/routers/ps368/products_configuration_guide_chapter09186a008069952a.html For ERSPAN packets, the âprotocol typeâ field value in the GRE header is 0x88BE. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Fun with Cisco DLT-value usage
Joerg Mayer wrote: Hello List, I'm trying to enable some people to read some captures in libpcap format directly without having to change the binary capture packet first. The packet was captureed using Cisco's ERSPAN feature. In their infinite wisdom, the engineers who implemented that feature chose a dlt-value of 0x71. What is the best way to handle that situation? Doesn someone else Shoot the responsible engineer(s)? ;-) use pcap version 2.4 or could that be a way to find out whether it's some Cisco specific stuff oder the regular WTAP_ENCAP_SLL? I suppose you'll need heuristics like those described in the (long) comments in wiretap/libpcap.c. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Fun with Cisco DLT-value usage
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@tcpdump.org, 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@tcpdump.org, 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@tcpdump.org 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@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
