Wireshark-bugs: [Wireshark-bugs] [Bug 9427] Dissector for T1-channels-over-raw-Ethernet protocol

Date: Fri, 22 Nov 2013 00:23:40 +0000

Comment # 30 on bug 9427 from
(In reply to comment #27)
> Next is to check the format of IETF Frame-Relay.

Frame Relay is specified by ITU-T Recommendations, not by the IETF.  See ITU-T
Recommendation Q.922:

    http://www.itu.int/rec/T-REC-Q.922-199202-I/en

What the IETF specifies is a way to transmit IP packets, and packets for other
protools, *over* Frame Relay:

    https://tools.ietf.org/html/rfc1490

See

    https://en.wikipedia.org/wiki/Frame_Relay#Protocol_data_unit

for some information about Frame Relay packets.  That section starts with:

    Each Frame Relay Protocol data unit (PDU) consists of the following fields:

      1. Flag Field. The flag is used to perform high-level data link
synchronization which indicates the beginning and end of the frame with the
unique pattern 01111110. To ensure that the 01111110 pattern does not appear
somewhere inside the frame, bit stuffing and destuffing procedures are used.

"bit stuffing and destuffing" links to

    https://en.wikipedia.org/wiki/Bit_stuffing

which gives more details.

That's what I'm referring to when I speak of "HDLC bit-stuffing or
byte-stuffing".  It actually dates back to SDLC:

    https://en.wikipedia.org/wiki/Synchronous_Data_Link_Control

which was the basis for HDLC:

    https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

which was the basis for several link-layer protocols, such as X.25's layer 2
protocol, LAPB:

    https://en.wikipedia.org/wiki/LAPB

and ISDN's LAPD layer-2 protocol for the D channel:

    https://en.wikipedia.org/wiki/Link_Access_Procedures,_D_channel

and also influenced the IEEE 802.2 protocol:

    https://en.wikipedia.org/wiki/IEEE_802.2

and PPP:

    https://en.wikipedia.org/wiki/Point-to-point_protocol

PPP separates the "framing" part of HDLC from the "packet header" part; PPP
specifies a header that looks similar to the address field/control field HDLC
header, and also specifies "PPP in HDLC-like framing", which uses HDLC's
framing, doing either bit-stuffing or byte-stuffing, to delimit PPP packets in
a bit or byte stream.

Frame Relay *also* uses HDLC's framing, but doesn't use HDLC's header; instead,
it uses headers that include an address field but *not* a control field.

> However, may I suggest the next development step be to simply decode to the
> Frame-Relay level by following the boundaries of the T1 slots/channels
> Guisyus indicated.

You may suggest it, but, when Frame Relay is carried over a bit stream like a
T1, the Frame Relay frame boundaries are, as far as I know, denoted by
HDLC-like framing; they have, as far as I know, *nothing* to do with
fixed-length T1 frames, in which case you cannot, in fact, decode Frame Relay
packets by following the boundaries of T1 frames.

You must, instead, take those frames, and process the bits in them, detecting
framing flags (a bit sequence of 01111110), removing the 0 bits stuffed into
the bits of the Frame Relay frame (in order to allow a Frame Relay frame to
contain an octet with the value 0x7E, every time there are 5 1's in the bit
sequence of a frame, a 0 bit is inserted), and taking the data between two
framing flags, once the extra 0 bits are removed, and hand them to the Frame
Relay dissector.


You are receiving this mail because:
  • You are watching all bug changes.