Wireshark-bugs: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5828
Bill Meier <wmeier@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #7 from Bill Meier <wmeier@xxxxxxxxxxx> 2011-11-17 15:30:25 EST ---
My general conclusion: the patch needs more work. :)
Some Comments:
1. When an RSL IPACCESS message is dissected (for global_rsl_use_nano_bts
TRUE), the discriminator, message type and IP Access IE types show as
'unknown'.
IMO, actual names and not "unknown" should be shown.
IPA protocol ip.access, type: RSL
DataLen: 6
Protocol: RSL (0x00)
Radio Signalling Link (RSL)
0111 111. = Message discriminator: Unknown (63)
.... ...0 = T bit: Not considered transparent by BTS
.111 0000 = Message type: Unknown (0x70)
Element identifier: Channel Number (0x01)
Channel number IE
Element identifier: L1 Information (0x0a)
1111 0... = C-bits: Unknown (30)
.... .100 = Time slot number (TN): 4
Element identifier: Unknown (0xf4)
.... 0001 = ip.access Speech Mode S: GSM EFR codec (GSM type 2, FS)
(0x01)
0001 .... = ip.access Speech Mode M: Receive Only (0x01)
2. I'm a bit puzzled about the matchup between the the rsl_att_tlvdef.def array
entries which are initialized and the related values which appear to be
actually handled in dissect_rsl_ipaccess_msg().
Specifically:
? case RSL_IE_IPAC_RTP_PAYLOAD:
? case RSL_IE_IPAC_RTP_CSD_FMT:
are cases under the switch statement in dissect_rsl_ipaccess_msg()
but the corresponding entries in the
rsl_att_tlvdef.def array are not initialized.
Unless I'm missing something encountering one of these will cause
problems when traversing thru the IEs.
--
For the non RSL_IE_IPAC cases 49 are initialized in the
rsl_att_tlvdef.def array but only 3 of those are cases under the switch
statement in dissect_rsl_ipaccess_msg().
Why all the definitions in rsl_att_tlvdef.def which don't appear to be used
in dissect_rsl_ipaccess_msg() ?
3. if the preference global_rsl_use_nano_bts is FALSE, there's code to skip
dissection when the discriminator has the value RSL_MSGDISC_IPACCESS.
However, it appears that dissect_rsl_ip_access_msg(0 will still be called
when
/* the following messages are ip.access specific but sent without
* ip.access message discriminator */
The intended effect of the preference if set is apparently to just not show
any dissection for ip.access specific messages.
What's the intent of having this preference ?
It's my feeling is that *something* should be
shown ("unknown" ??? not dissected ???) even if the message
isn't actually dissected.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
