tcpdump mailing list archives
Re: Request for new DLT value for Wireshark
From: "Schemmel, Hans-Christoph" <hans-christoph.schemmel () cinterion com>
Date: Thu, 3 Mar 2011 18:01:31 +0100
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.
Current thread:
- Re: Request for new DLT value for Wireshark Dissector, (continued)
- Re: Request for new DLT value for Wireshark Dissector Guy Harris (Feb 03)
- Re: Request for new DLT value for Wireshark Dissector Schemmel , Hans-Christoph (Feb 04)
- Re: Request for new DLT value for Wireshark Dissector Guy Harris (Feb 06)
- Re: Request for new DLT value for Wireshark Dissector Schemmel , Hans-Christoph (Feb 07)
- Re: Request for new DLT value for Wireshark Dissector Guy Harris (Feb 10)
- Re: Request for new DLT value for Wireshark Dissector Schemmel , Hans-Christoph (Feb 14)
- Re: Request for new DLT value for Wireshark Dissector Guy Harris (Feb 14)
- Re: Request for new DLT value for Wireshark Dissector Schemmel , Hans-Christoph (Feb 15)
- Re: Request for new DLT value for Wireshark Dissector Schemmel , Hans-Christoph (Mar 02)
- Re: Request for new DLT value for Wireshark Dissector Guy Harris (Mar 02)
- Re: Request for new DLT value for Wireshark Schemmel, Hans-Christoph (Mar 03)
- Re: Request for new DLT value for Wireshark Guy Harris (Mar 08)
- Message not available
- Re: Request for new DLT value for Wireshark Schemmel , Hans-Christoph (Mar 09)