Wireshark-bugs: [Wireshark-bugs] [Bug 7615] Enhancemnt to GSM RLCMAC dissection adding dissectio
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7615
--- Comment #23 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2012-09-04 13:31:19 PDT ---
(In reply to comment #22)
> Why should we leave out the de facto standard format for these traces? Can you
> please elaborate a bit more?
The spec seems to group the MCS according to header type
3GPP TS 44.060 10.3a.3.1 Header type 1: header for MCS-7, MCS-8 and MCS-9
:
10.3a.3.2 Header type 2: header for MCS-6, MCS-5, DAS-5, DAS-6 and DAS-7
We have a proprietarry transport protocol where the "wrapping information"
states the header type not the MCS type and the MCS can be retrived from the
egprs data I think. So using header type seems more in line with the standard.
Also if you look at the actual code in rlcmac
case RLCMAC_MCS1:
case RLCMAC_MCS2:
case RLCMAC_MCS3:
case RLCMAC_MCS4:
csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type3_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
break;
case RLCMAC_MCS5:
case RLCMAC_MCS6:
csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type2_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
break;
case RLCMAC_MCS7:
case RLCMAC_MCS8:
case RLCMAC_MCS9:
csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type1_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
break;
The function calls are based on headertype not MCS so providing the header type
seems more corect here too.
Best regards
Andrs
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.