packet-gsm_a_rr.c:3867:101: error: parameter 'len' set but not used [-Werror=unused-but-set-parameter]
packet-gsm_a_rr.c:6837:46: warning: variable 'bit_offset_sav2' set but not used [-Wunused-but-set-variable]
packet-gsm_a_rr.c:7458:18: warning: variable 'curr_offset' set but not used [-Wunused-but-set-variab
svn path=/trunk/; revision=40453
This is largely a cosmetic update of the gsm_a_rr dissector:
• TBF starting time is now fully decoded.
• “Double indenting” of IE groups (where an IE dissector adds a subtree just
after the generic dissector adds a subtree) has been eliminated.
• “Null” break points in CSN.1 IEs have been added where they were
previously missing (this could have caused some correct PDUs to be reported as
malformed).
• The calculation of CSN.1 IE lengths has been corrected: ((a – b)>>3)+1 is
not the same as (a>>3)-(b>>3)+1 .
• The handling of CSN.1 padding bits is slightly improved.
• The handling of CSN.1 “truncated” bits is slightly improved.
• Eliminated superfluous checks for len==0 at the beginning of some
rest-octet dissectors (the generic dissector won’t call the CSN.1 dissector if
len is 0).
• A few minor corrections to text strings and formatting.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6728
svn path=/trunk/; revision=40447
packet-gsm_a_rr.c: In function 'de_rr_p2_rest_oct':
packet-gsm_a_rr.c:4033:105: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
svn path=/trunk/; revision=40386
GSM ENHANCED MEASUREMENT REPORT PDUs were not
dissected when present as L3_INFO in RSL MEAS_RES PDUs.
It seems that the RSL L3_INFO needs to be handled by a different dissector
depending on whether it contains a DTAP, SACCH or CCCH PDU, which fortunately
can be deduced from the RSL PDU type. packet-rsl.c is updated to implement
this.
In packet-gsm_a_rr.c the dissection of PDUs with RR Short PD format is
improved, and also some items are renamed to make clearer the difference
between SACCH PDUs (which cna be normal or Short PD format) and RR Short PD
format PDUs (which can occur on SACCH, CCCH, or DCH).
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6699
svn path=/trunk/; revision=40357
eliminates the global variable for tracking which nibble is
to be decoded by taking advantage of the fact that half octet IEs always occur
in pairs, and thus a pair can be grouped together for decoding.
There was probably also some confusion caused by the macros UPPER_NIBBLE and
LOWER_NIBBLE because the GSM bit numbering is opposite to Wireshark internal
numbering, so I have changed these to be LEFT_NIBBLE and RIGHT_NIBBLE, which
corresponds to the display format in Wireshark.
The dissection order of half octet IEs has been adjusted where necessary to
align with the ordering shown in the GSM specifications.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6658
svn path=/trunk/; revision=40157
The offset in "Cell Selection Indicator after Release of all TCH and SDCCH" was not correct because the length was element was decoded twice. So I removed the second decoding of the length.
svn path=/trunk/; revision=40088
added the display of intermediate value used to decode ARFCN in
range 1024/256 format.
So now the W(n) values can be displayed and localised in the tvb buffer.
The code was reworked a little to use the get_bit functions.
svn path=/trunk/; revision=39976
Fix bug wherein an item was apparently added to the wrong subtree: Coverity 910;
Remove unneeded #includes;
Do whitespace and indentation cleanup.
svn path=/trunk/; revision=36530
- added documentation in packet-csn1.h
- fixed a bug in packet-csn1.c
- fixed a BSIC description in packet-gsm_a_rr.c
- removed the "_v" suffix in packet-gsm_rlcmac element description
svn path=/trunk/; revision=36284
Incorrect decoding of List of ARFCN in BCCH frequency list.
When the range 1024 is selected, it can happen that 2 bytes need to be read for
W1, and also for W2. In the current version, when W1 ends on a byte boundary,
W2 will get an incorrect value, since it will be truncated by 1 bit.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5214
svn path=/trunk/; revision=34113
In some cases the usage may have been benign since it can be seen by code inspection that the maximum value of the end variable can't exceed the maximum value of the loop variable.
However, on general principles, all the usages have been fixed.
svn path=/trunk/; revision=33692
Anders Broman