Wireshark-bugs: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types
Date: Thu, 17 Nov 2011 12:30:27 -0800 (PST)
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.
- Prev by Date: [Wireshark-bugs] [Bug 6348] wireshark tries to decode ciphered NAS message
- Next by Date: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types
- Previous by thread: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types
- Next by thread: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types
- Index(es):
- Get Wireshark
- Download
- Code of Conduct