Let's decrease the logging since it's fine simply discarding the message
if the link is down. This way all code sending messages doesn't need to
care about the link state.
Change-Id: I64356ec6a7b3a4e11a0e66b17efab2788b1ca5cc
This way we separate all the VTY boilerplate from the actual logic, as
we usually do in all other subsystems.
Change-Id: Ifc7d1693d745dd2a3c31e3ee9610d8c634b50812
In commit [1], I replaced the way the CBSP link is configured in the VTY. But
that configuration was already part of a release, hence I should only have
deprecated the old commands. Re-add the legacy config as deprecated.
Try to make the legacy commands take a similar effect as they previously would
be intended for, i.e. switching to server/client/disabled modes, and take
effect immediately when commands are read from telnet.
[1] 641f7f0845
Icaa2775cc20a99227dabe38a775ff808b374cf98
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
Related: OS#4702
Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b
Restart the CBSP link from the VTY only from telnet sessions, not when reading
in the config file. When reading the config file, link startup might happen too
early and twice -- rather rely only on the CBSP startup invoked from main().
This is fixing a bug introduced recently in
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"
commit 641f7f0845
Change-Id Icaa2775cc20a99227dabe38a775ff808b374cf98
Change-Id: Ia0bb507c8468048789a446df09185ad8565c5ad8
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc
to be configured as CBC client *and* CBC server at the same time.
cbsp_link.c expects at most one CBSP link to be established, and, upon sending
CBSP messages, probes whether to send the message to a CBSP server or client
link. When both listen-port and remote-ip are configured (regardless of an
actual CBSP connection), osmo-bsc gets confused about where to send CBSP
messages.
One solution would be more accurate probing for an actual established TCP
connection. But the simpler and less confusing solution is to force the user to
configure only server or only client mode, never both.
Introduce 'cbc' / 'mode (server|client|disabled)'.
Secondly, clarify the 'cbc' config structure into distinct 'server' and
'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP
addresses for server and client mode can remain configured when the CBSP link
is switched between server/client/disabled modes.
To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str
for address configuration.
Related: OS#4702
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
The separate struct osmo_bsc_data is like another separate struct gsm_network
for no reason. It is labeled "per-BSC data". These days, all of this is a
single BSC and there will not be different sets of osmo_bsc_data.
Drop struct osmo_bsc_data, move its members directly into gsm_network.
Some places tested 'if (net->bsc_data)', which is always true. Modify those
cases to rather do checks like 'if (net->rf_ctrl)', which are also always true
AFAICT, to keep as much unmodified logic as possible in this patch.
Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7
Pau Espin
Neels Hofmeyr
Harald Welte