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.
For further evaluation/analysis, this patch stores the classmark 1, 2 and 3
values of every equipment in the SQL database. We can use this non-volatile
data to determine the supported features for each handset that we've ever
seen on our network.
As Dieter has pointed out, we currently send incorrect information
in the rest octets, particularly about our GPRS capability. Since
the format of the rest octets is highly complex, and we don't
actually need any of those features yet, we might just fill them
with padding.
If we receive one of those strange BS-11 "Cause 22" errors, we don't need
to check if the lchan use counter is > 0. If it was 0, the lchan gets
released anyway.
This was proposed by Andreas Eversberg. I made it conditional on the T200
timer expired cause, as I'm not sure if we really should give up that quickly
on other errors such as just simply receiving an unsolicited response.
* when paging callback is called, we need to consider a failed paging
operation (i.e. lchan == NULL)
* we have to zero-initialize every transaction that is allocated
after passing the mncc structure (contained in msgb) to the mncc layer,
we have to release its memory. This leak was discovered as a direct result of
using talloc.
* add bts->band field plus corresponding VTY and commandline argument
* add trx->nominal_power and trx->max_power_red fields
* add rsl_chan_bs_power_ctrl() to control TRX RF power for a given TS
* add rsl_chan_ms_power_ctrl() to control MS RF power for a given lchan.
