Bug #1696
closedstatic OML attribute tables
100%
Description
In bts_ipaccess_nanobts.c we have a NM attribute table, which is an ugly reminder at the early history of OpenBSC. So rather than constructiong the NM/OML TLVs at runtime, we have a global, static table that we patch with the actual values as configured.
This works fine if the attributes don't differ between BTSs, or between TRXs of BTSs.
Related issues
Updated by laforge almost 8 years ago
- Related to Bug #1697: max_power_red of C0 is used on non-0 TRX added
Updated by laforge almost 8 years ago
- Assignee set to dexter
- Priority changed from Normal to Low
Updated by dexter almost 8 years ago
Had a look at it, seems to me that nanobts_attr_bts mostly consists of fixed length fields, except for the last one (NM_ATT_IPACC_CGI), which seems to be a TL16V field. nanobts_attr_radio is similar, one TL16V field at the end. nanobts_attr_nse, nanobts_attr_cell, nanobts_attr_nsvc0 entirely consists of TL16V fields. This is simple to fix. Will continue this when there is some spare time.
Updated by laforge almost 8 years ago
On Fri, Jul 15, 2016 at 01:50:19PM +0000, dexter [REDMINE] wrote:
Had a look at it, seems to me that nanobts_attr_bts mostly consists of
fixed length fields, except for the last one (NM_ATT_IPACC_CGI), which
seems to be a TL16V field. nanobts_attr_radio is similar, one TL16V
field at the end. nanobts_attr_nse, nanobts_attr_cell,
nanobts_attr_nsvc0 entirely consists of TL16V fields. This is simple
to fix. Will continue this when there is some spare time.
It doesn't really matter if it's fixed or variable length field. The
point is to simply construct a msgb at runtime using msgb_tlv_put() or
msgb_tl16v_put() or related functions, using the content of our
gsm_network/gsm_bts/gsm_bts_trx/gsm_bts_trx_ts data structures for the
source of the configuration data.
The old static tables should simply disappear at that point.
It might also be a good point to generate / capture some OML messages
with the old code, add some autotest cases for that, and then
introduce the new code. This way we make sure that the changed code
will still generate the exact same messages in the end.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by dexter over 7 years ago
- % Done changed from 0 to 90
Replaced the static OML tables with dynamically constructed ones. Used msgb_tlv_put(), msgb_tl16v_put() ect... as suggested. The patch is now in the gerrit for review.
Updated by dexter over 7 years ago
Added unit-test to ensure that the new code generates exactly the same output as the old code.
Updated by laforge over 7 years ago
please make sure to keep ticket status up to date. This doesn't include a reference to the gerrit code yet, and I belive the gerrit change was already merged and hence this is at 100% and closed?
Updated by dexter over 7 years ago
- Status changed from In Progress to Resolved
Yes, has been merged. The gerrit reference is: https://gerrit.osmocom.org/#/c/973/
