Rename osmo_*_cbc -> cbc_*_mgr:
Now they only hold TCP/SCTP server related conns, but will also hold
TCP/SCTP client conns in the near future.
Rename osmo_cbc_*_client -> cbc_*_link:
The term "client" is confusing, since it doesn't exist in CBSP/SBcAP,
and will later support connecting to server at TCP/SCTP level.
Let's use "link" instead, similar to what's used in osmo-bsc which
already supports both TCP client and server modes.
Change-Id: Ia9d26dc1593c8ee08dce348fe9f5f4c9398ea2a5
Let's create missing header files and move stuff around to have a clear
view of who implements what.
Change-Id: Ib32091d716b33bca58e2d3acf8840b52824c0bd3
log macro needs to be changed since it uses cbsp_cbc_client_name() which
accesses client->conn which is NULL in there.
Change-Id: Ic444c749476bb1626df5494c00021c5e1a9f24b9
There's no need to pass the specific params. Let's simply get whatever
need from the global config in the function.
This makes it easier to extend it to more params if needed.
Also, when we add SBc-AP support, the params that have to be passed to
the counter part function are different, so let's simplify param
passing here.
While at it, rename also the callback function to contain "cbsp" on it,
since it is cbsp specific.
Change-Id: Ia2362757275e7cbce82b64c7c2a0798276d964c3
The VTY code should write/save only those peers that were configured
using the VTY.
Closes: OS#4929
Change-Id: If02694be4e4cb9cb27e7d9d07e533bfed4a999a9
Using this state we can actually successfully add mesasges via
the REST interface and see them being sent via CBSP to the BSCs,
who then transmit to BTSs who send it to MSs and the MSs show them...
Change-Id: If29bd4bbbf88a0ca58de9ff29ad524b0a7262a8e
If we know the peer of a client, and that peer has a name, log lines
shall use that name as context, rather than the somewhat difficult
to read osmo_sock_get_name2() result.
Change-Id: I183cbfa4b541fa4e2b96a00635cb17d91a34ae83
Pau Espin
Harald Welte