Re: Request for new DLT value for Wireshark

["Schemmel, Hans-Christoph" <hans-christoph.schemmel () cinterion com>]

Guy Harris <guy <at> alum.mit.edu> writes:

> Not yet - I've been somewhat busy the past week and a half, and I have to
condense all the e-mail on this thread
> into a complete and precise description of the data format, to put into the
pcap/bpf.h and pcap-common.c
> files.  If somebody else were to do so, that would probably speed the process
up significantly....-
>

Hello Guy,

this is the detailed description of the data format.


LINKTYPE_MUX27010

Packet structure:

    1             2            3             4     
Header_Size     |  Msg_ID   |   Freg_ID   | Start_Pos | ...
 (1 Octet)  |(2 Octets) | (2 Octets)  | (1 Octet) | ...
 
        5          6           7             
...  End_pos  |   Flag   | Direction | ...
... (1 Octet) | (1 Octet)| (1 Octet) | ...
 
 
        8            9           10           11         
...  Flag_Mux  |  Address  |  Control  |     Length      | ...
... (1 Octet)  | (1 Octet) | (1 Octet) | (1 or 2 Octets) | ...
 
        12            13         14      
... Information |    FCS    |  Flag_Mux
...  (n Octets) | (1 Octet) | (1 Octet)   



Description:
Parts of the packets (Octets 8 - 14) of this link type frames are based on the
standard 3G TS 27.010, but they are slight deviations to meet the actual
implementation of Cinterion and Siemens modules, e.g. no I frame support, but an
additional UIH_E frame.
Besides this the original MUX_Frame (Octets 8 - 14) is extended by some extra
fields for PPP chunks and direction indication (Octets 1-7). 


Description for Octets 1-7:
If there are PPP chunks in the Mux_Frame Information_Field (12) they will be
indicated by the {Msg_ID (2), Freg_ID (3), Start_Pos (4), End_Pos (5), Flag 
(6)} quintuplets, there will be one quintuplet for every chunk.
Header_Size (1) and Direction (7) are always present. Msg_ID (2), Freg_ID (3),
Start_Pos (4), End_Pos (5) and Flag  (6) are optional and not always present.
The Header_Size field indicates whether the octects 2-6 are present or not and
how often they are present: If a frame contains N PPP chunks, the Header_Size
field has the value 7N, otherwise the frame is invalid.

Start_Pos is the 1-origin index (from the beginning of MUX_Frame, Flag_Mux (8))
of the first byte of the chunk, and End_Pos is the 1-origin index (from the
beginning of MUX_Frame, Flag_Mux (8)) of the last byte of the chunk.

All the chunks of a given PPP packet have the same Msg_ID (2) value. Freq_ID (3)
is a sequence number for the PPP chunks. The first chunk has a Freq_ID of 0 and
the Freq_ID of the next chunk will be incremented.
The last chunk of a given PPP packet has a Flag (6) value of 1; the others have
a Flag value of 0.

The Direction field (7) indicates the direction of the Mux frame: "0" means from
GSM Modem to the Host; "1" means from Host to GSM Modem.



Description for Octets 8-14:
The Mux_Frames are based on the standard 27.010, but they are deviations. 
The multiplexer protocol doesn´t distinguish between Basic and Advanced Option
and every packet begins with the 0xF9 flag. 
The protocol for this Mux_Frames implements the Basic Option with the additional
feature of the Error Recovery Mode, which is a subset of the GSM 07.10 Advanced
Option. The control type of the UIH_E frame is coded as I frame, so they could
be a collision with TS 27.010.

A MUX27010 MUX_Frame (Octets 8 - 14) starts with a MUX_Frame header (which is a
TS 27.010-like header), followed by zero or more bytes of data.

It is possible that a valid Mux_frame - with PPP_frames as payload - has parts
that don´t correspond to a PPP packet described by Start_Pos (4) and End_Pos (5). 
These parts (AT commands or responses) are called "other data" and will be
uninterpreted and displayed as raw text in the Wireshark subtree. So the payload
can be a mixture of chunks of uninterpreted data and PPP chunks.


Kind regards,
Christoph Schemmel-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.