Bug #4702

CBSP: when a client connects, osmo-bsc should possibly send a CBSP RESTART to the client

Added by neels 8 months ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


The BSC_Tests_CBSP.ttcn expect a CBSP RESTART to come from osmo-bsc when a client connects.
osmo-bsc however doesn't send any.

To get the CBSP tests running at all at first, I changed the ttcn to not expect a CBSP RESTART for a client connect,
but we should clarify expected behavior and apply that, soon.


Associated revisions

Revision c276d736 (diff)
Added by Neels Hofmeyr 8 months ago

bsc CBSP: apply new cbc config

Adjust osmo-bsc.cfg to work with osmo-bsc
Icaa2775cc20a99227dabe38a775ff808b374cf98 and osmo-ttcn3-hacks

Related: Icaa2775cc20a99227dabe38a775ff808b374cf98 (osmo-bsc)
Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks)
Related: OS#4702
Change-Id: I9e9760121265b3661f1c179610e975cf7a0873f1

Revision 641f7f08 (diff)
Added by Neels Hofmeyr 8 months ago

CBSP: rewrite the CBSP link setup and 'cbc' VTY section

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

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

Revision ca979b78 (diff)
Added by Neels Hofmeyr 7 months ago

CBSP: adjust manual to reflect new 'cbc' VTY config

Related: OS#4702
Change-Id: I101144dc4ebf151fa23d05743398aeea4a26834b

Revision 7e9ac64b (diff)
Added by Neels Hofmeyr 7 months ago

CBSP VTY: re-add legacy cbc config for backwards compat

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] 641f7f08450f2d0c4b8e8a9f6a36b0a6b2788816
"CBSP: rewrite the CBSP link setup and 'cbc' VTY section"

Related: OS#4702
Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b


#1 Updated by laforge 8 months ago

  • Assignee set to neels
  • Priority changed from Normal to High

#2 Updated by neels 8 months ago

  • % Done changed from 0 to 90

osmo-bsc already had the code to send a CBSP RESTART, but in the ttcn3 tests it gets mixed up because osmo-bsc is configured as both CBSP server and CBSP client.

#3 Updated by neels 8 months ago

instead of above patches, I re-implemented the 'cbc' config section.
and related patches

#4 Updated by neels 8 months ago

  • Status changed from New to Resolved
  • % Done changed from 90 to 100

#5 Updated by neels 8 months ago

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)