ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] WTAP_ENCAP_FRELAY

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Guy Harris" <gharris@xxxxxxxxx>
Date: Tue, 22 Jun 2004 12:35:08 -0700 (PDT)
Marc Carbones said:
> I'm trying to open Sniffer Pro cap files captured with a Wan Book, the
> only thing I can see are the Frame Relay headers of the packets that the
> Wan Book captures.

I.e., it displays the Frame Relay headers, but just shows the Frame Relay
payload as data?

> I've been searching on the Internet and see documents about
> WTAP_ENCAP_FRELAY and it seems this is a plugin or something else to
> succesfully read the IP packets inside the FR header.

I did a Google search on WTAP_ENCAP_FRELAY, and found nothing saying it
was a plugin - which is good, because it's *NOT* a plugin. 
WTAP_ENCAP_FRELAY is a constant inside the Ethereal code, supplied by
Ethereal's Wiretap capture-file-reading library to programs such as
Ethereal and Tethereal that use it, indicating that the packets in the
file start with a Frame Relay link-layer header (the WTAP_ENCAP_ values
indicate the type of link-layer header, etc.).

If Ethereal sees a packet of type WTAP_ENCAP_FRELAY, it'll have the Frame
Relay dissector analyze it, putting the Frame Relay headers into the
display.  Then:

    if the encapsulation type preference for Frame Relay is "FRF 3.2/Cisco
HDLC", it will:

        take ordinary "unnumbered information" frames (frames starting
with 0x03), assume that after the 0x03 they either have an OSI
network layer PID value or a padding byte of 0 followed by an OSI
network layer PID value, and use the network layer PID value to
determine what dissector to hand the packet to;

        take other frames and:

            if the DLCI is 0, treat them as LAPF;

            otherwise, if the frame is an XID frame (frames starting with
0xAF), treat them as XID frames;

            otherwise, assume the frame starts with a Cisco HDLC type value;

    otherwise, if the encapsulation type preference is "GPRS Network
Service", hand the payload to the GPRS Network Service dissector;

    otherwise, if the encapsulation type preference is "Raw Ethernet",
treat the payload as an Ethernet frame.

This will, for *some* encapsulations, detect IP data and hand it to the IP
dissector.

What encapsulation are the frames in question using?