Since TS 12.21 implements only SET ATTRIBUTE for some object classes,
ip.access had to extend it to be able to set attributes on arbitrary
objects. We now introduce a function implementing that message.
Supporting GPRS means we have a number of additional OML objects to
deal with. We need to extend our gsm_bts structure to at least
include the nm_state for each of those objects.
Add support for 1900 nanoBTS by using unified bts_type
GSM_BTS_TYPE_NANOBTS for 900, 1800 and 1900 versions.
Reduce the nanoBTS enum values to one and derive the
version from the user supplied band. In the future we
might want to do auto band detection.
The configuration file needs to be changed to refer
to nanobts instead of nanobts900/nanobts1800.
Signed-off-by: Mike Haben <michael.haben@btinternet.com>
Signed-off-by: Holger Hans Peter Freyther <zecke@selfish.org>
Addresses a FIXME in abis_nm.c, parsing the parameters
passed by a Software Activate request. I've tested this
on three different IpAccess BTSs (including one which
didn't work with the original code), would be good if
someone could check it on a BS11.
Signed-off-by: Mike Haben <michael.haben@btinternet.com>
Tested-by: Holger Hans Peter Freyther <zecke@selfish.org>
the various constructors get called in a non-obvious, linker determined
order, which makes certain objects disappear from the talloc report.
This change moves the talloc context creation into a new talloc_ctx.c file
This helps us to detect the frequency error of BS-11 if it is located
next to the nanoBTS 900.
If 'ipaccess-config -l' is called, it will produce a report like
<0020> ipaccess-config.c:85 TEST REPORT: test_no=0x42 test_res=0
<0020> ipaccess-config.c:108 ==> ARFCN 220, Frequency Error 22
<0020> ipaccess-config.c:108 ==> ARFCN 1, Frequency Error -37
<0020> ipaccess-config.c:108 ==> ARFCN 10, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 20, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 53, Frequency Error 5
<0020> ipaccess-config.c:108 ==> ARFCN 63, Frequency Error -4
<0020> ipaccess-config.c:108 ==> ARFCN 84, Frequency Error 11
<0020> ipaccess-config.c:108 ==> ARFCN 101, Frequency Error 0
<0020> ipaccess-config.c:108 ==> ARFCN 123, Frequency Error -52
where in this case the ARFCN 123 is the BS-11 with a frequency error
larger than all the other (regular) BTS in the vicinity.
Fix two bugs in OML software download code where we allocate data structures
using talloc, but free() them using the system memory allocator. Spotted by
dexter.
Currently we send the attribute changes in a send and forget
fashion. But sometimes the nanoBTS is sending us a NACK, e.g
with a invalid unit id. Start handling the NACK and provide
an error message to the user. The error message is not yet
describing the cause of the error but this is a slight progress
to the previous silent failure.
When trying to operate a nanoBTS900 on channels for 1800
or the other way around the "SET BTS ATTRIBUTES" message
will be nacked. Dispatch all nacked messages from abis_nm
via signals. Handle this in bsc_hack.c, print a small hint
and exit the application as this is considered a fatal
unrecoverable error (the exit is in the app, so a library
can be more robust).
Harald Welte
Holger Hans Peter Freyther