Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5828] ip.access nanoBTS vendor-specific RSL message types

Date: Sat, 10 Dec 2011 00:57:13 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5828

--- Comment #9 from Harald Welte <laforge@xxxxxxxxxxxx> 2011-12-10 00:57:08 PST ---
Regarding your qestion "1":  This has been introduced as a bug in more recent
versions of the patch, it is indeed a bug.  I will attach a new version which
re-introduces the definitions that fix this behavior.

Regarding question '2':
 ?       case RSL_IE_IPAC_RTP_PAYLOAD:
 ?       case RSL_IE_IPAC_RTP_CSD_FMT:
have indeed been missing from the tlvdef, I have added them.

Furthermore, the question
> Why all the definitions in rsl_att_tlvdef.def which don't appear to be used 
> in dissct_rsl_ipaccess_msg() ?

Those are basically missing, i.e. if ip.access sometimes uses such
standard-compliant elements in vendor-specific messages, then the
dissct_rsl_ipaccess_msg() will not display/decode them, but at least skip over
them gracefully as it knows the type of the element and thus its length.

ip.access has never released any documentation regarding the detailed syntax of
all of their RSL extensions, so it is a bit difficult for us to know which kind
of standard elements we can encounter in vendor-specific messages.

On the other hand, if we wanted to decode all the standard information
elements, too, we'd basically have to reimplement the entire RSL dissector.

I will add a comment to the code indicating this fact.

Let's hope we can finally get this one merged now...

-- 
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.