Some NM attributes are defined differently depending on
the BTS type. Having one big nm_att_tlvdef[] table for
all BTS types is no longer sufficient. This patch
* introduces 'struct gsm_bts_model' to describe a BTS model
* adds definitions of gsm_bts_model for BS-11 and nanoBTS
* changes the abis_nm_tlv_parse() function: include a bts pointer
Currently starting with the opencfg.cfg.nanobts and writing it out
and then trying to start again will not work. The network reject_cause
is initialized to 0 which is not a valid reject reason and when writing
this to the config file and trying to parse it will fail.
Pick roaming not allowed as a harmless option to those phones
accidently trying to connect to the BTS.
These commands let you change the PLL set and work values. Many thanks
to Dieter Spaar for figuring out how to do this!
Now you can just reset your PLL work value if it drifts away due to your
E1 card.
Use it like this: bs11_config pll-workvalue 1000
Whether this function changes the set or the work value depends on your
type of login. In FACTORY login it changes the set value, in FIELD login
it changes the work value (which is what is used by the BS11 to tune the
frequency).
This is useful information to know and actually fixes a segfault
in rllp.c where lchan is accessed even tough it could be NULL in
case of failure.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
At least some nanoBTS 139 send the last even (going online) as
'enabled' 'unlocked' but no avail status IE (which I guess mean an empty
set, the doc 12.21 isn't that clear about that).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Follow up on 424c4f0e29. As pointed out
by Sylvain on the mailinglist I need to remove this here as well.
Do not call db.c code from code that is located in libbsc.a
vty_interface.c is part of libbsc.a but it started to use code
which is found in db.c recently. Fork the subscriber dumping and
provide more information on the layer3+ (MSC) commands. This
is restoring the separation again.
Theses will be useful to know if we can reuse the tuples or if
we should renew. The 'issued' is currently purely informative.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This returns true if the gsm_nm_state can be considered 'running'.
Note that we also accept availability==0xff (which is a code for
no value) because according to 12.21 it is perfectly valid.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The exact sequence the states the BTS goes through is slightly
different for one of the nanoBTS 139 I have and it needs this
to start.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Thise two functions are interfacing with the 04.08 layer 3 to
determine if a particular message should be handled inside
the OpenBSC layer 3, or if it should be handled in the silent call
handler.
* On start the vty code will call the abis_nm method and this
will set the administrative state to unlock/lock
* During startup the BTS will report its state as well and would
possible overwrite the set administrative. We are only going
to update the administrative if it was 0 before. This appears
to work on all of my tests. In case this will not be the case
for others we will have to split the administrative into two
sets one for the BTS and one for the BSC.
* This is used in sw_load_init and sw_load_end and both needs
to be touche for every BTS. Move it into a common method.
* This was only verified on the nanoBTS.
* Do not issue the restart right aways if we have OML IP or
software load in the queue (hint, we need a real queue of operations
to carry out... with one big state machine)
* Change the signal_data of ipacc ACK/NACK to contain the msg type
and the bts pointer.
* Issue a restart for software load and OML and use the BTS pointer
we got out of the new signal data.
We are filling sw_load1 with the information found with type
0x1000 and sw_load2 with type 0x2001. It appears from the protocol
traces that these information is not extracted from them. We also
need to include the \0 from the string.
With this firmware flashing seems to work.