IF we say "... under the terms of the GNU Affero General Public License"
then we cannot say "see the GNU General Public license" later on, that's
misleading and likely a copy+paste error somewhere.
The project license has always been AGPLv3-or-later.
Change-Id: I6b8ad5147ca76052213809e67856dcb80bff2b93
Even though the Abis/OML message flow looks the way it should look
on the wire, it does not actually reflect the sequence/flow of events
and actions in the NM FSMs. For example (extracted from a PCAP):
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Software Activate Request
GPRS Cell(00,00,ff) Software Activate Request ACK
GPRS Cell(00,00,ff) Activate Software
GPRS Cell(00,00,ff) Activate Software ACK
[a] GPRS Cell(00,00,ff) State Changed Event Report
[b] GPRS Cell(00,00,ff) Software Activated Report
[c] GPRS Cell(00,00,ff) Get Attributes
GPRS Cell(00,00,ff) Get Attributes Response
[d] GPRS Cell(00,00,ff) IPA Set Attributes
GPRS Cell(00,00,ff) IPA Set Attributes ACK
GPRS Cell(00,00,ff) Change Administrative State
GPRS Cell(00,00,ff) Change Administrative State ACK
GPRS Cell(00,00,ff) State Changed Event Report
GPRS Cell(00,00,ff) Opstart
GPRS Cell(00,00,ff) Opstart ACK
A follow-up patch [1] changes the logic generating message [d],
so that the IPA Object Version of the GPRS Cell MO is taken into
account when adding the attributes.
The problem is that both messages [c] and [d] are generated and
queued for transmission on the receipt of message [a], but *before*
message [b] has been processed. So the IPA Object Version is not
known and assumed to be 0 at that point in time.
This patch delays configure_loop() until message [b] is received.
So far only for nanoBTS and only for those MOs, for which Figure 2
in 3GPP TS 52.021 explicitly mentions that the SW downloading and
activation procedures may be required, plus for the ip.access
specific MOs which all seem to support the SW activation.
osmo-bts does send SW Activated Report only for a subset of MOs,
which does not include Baseband Transceiver, Radio Carrier, and
Radio Channel. 3GPP TS 52.021 is not clear on whether this
message shall be sent by all MOs either, so we consider it
optional and delay configure_loop() only for nanoBTS.
Change-Id: I3953a5e41eb27165f9ff203cac7447ee9d311abf
Related: [1] Ie0fb3eaf76e1f70e5a19bb088e1674b7e553d32a
3GPP TS 52.021 does not strictly mandate that the SW Activated Report
can only be received in state DISABLED/OFFLINE. The only requirement
is that the software load procedure (if needed) and activation is to
be performed in this state.
The successful outcome of software activation procedure is indicated
by the BTS using the above-mentioned SW Activated Report message,
which may be received in ST_OP_DISABLED_{DEPENDENCY,OFFLINE} too.
The MO state changes are triggered by the State Changed Event Report
messages, and happen asynchronously with the software activation.
This patch fixes the following warnings seen with a nanoBTS:
NM_BTS_OP(bts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSE_OP(nse2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_CELL_OP(gprs-cell2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSVC_OP(nsvc0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_GPRS_NSVC_OP(nsvc1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_BB_TRANSC_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts1){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts2){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts3){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts4){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts5){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts6){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_CHAN_OP(bts2-trx0-ts7){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
NM_RCARRIER_OP(bts2-trx0){DISABLED_OFFLINE}: Event SW_ACT_REP not permitted
The following warning is still expected to show up though:
NM_BTS_SM_OP(bts_sm){ENABLED}: Event SW_ACT_REP not permitted
but is caused by a different problem, which is to be fixed later.
Change-Id: I00a423adcde5c34977f4c4dad920874687fa493c
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Since b7ef6884f9, the state is updated
before triggering the signal S_NM_STATECHG, so the warning does no
longer hold true.
Change-Id: I7b7dd30b4fcdc92febca42e3e6a75e6f98e184ff
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
This makes sure code accessing those fields is not changing its values,
since it would make no sense to change those. Follow up commit will make
convert those pointers to be full structs instead, as there's no need to
have pointers there.
Change-Id: I9979e62eac861e25bbe2161ab187ddb2b40fd097
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Harald Welte
Vadim Yanitskiy
Alexander Couzens
Pau Espin