In osmo-bsc, there's currently 0..1 Lb links and 0..N A links, where N
is the number of MSC, but links can be shared in the underlaying stack
(struct osmo_sccp_instance), hence range 0..N of different
osmo_sccp_instance (identified by PC).
Even more, the Lb and A link can share the same underlaying stack, so
osmo-bsc can end up with only 1 struct osmo_sccp_instance shared by all
the above mentioned links in case all are configured under the same PC.
Total range A+Lb is 0..(1+N).
A struct gsm_subscriber_conn stores 2 struct sccp_instance*, one for
Lb (conn->lcs.lb.*)and one for A (conn->sccp.*).
They can actually point to the same sccp_instance or to different ones,
as explained above, depending on the configured setup. In any case, a
gsm_subscriber_conn needs 2 rb_nodes since it can hold
any of the 2 conn_ids independently (A or Lb).
The previous patch forgot to add that 2nd rb_node as well as some
initialization and release code for the Lb conn. This patch addresses
that.
When the 2nd rb_node, a problem when iterating the rbtree appears: how to
find out the "conn" pointer from the rb_node pointer, since the rb_node pointer
can be any of the 2 rb_nodes inside the struct at a different offsets.
In order to solve that problem, a new struct bscp_sccp_conn_node is
added, which holds all the relevant information used by the rbtree lookup code
in a generic way (rb_node and conn_id), plus a backpointer to the struct
bsc_gsm_subcriber it relates too.
Fixes: 85062ccad3
Change-Id: If42d93adee71d646766929a09bc01ae92b734ef3
The function was currently in osmo_bsc_sigtran.c but was never used
there, and it really doesn't have any relation to that file.
Let's move it to the only place where it's used so far, and mark it as
static.
Change-Id: I8a8cef45aa378421e0ac328d3b29b9d194698a55
It was found that, on a busy osmo-bsc (>1000 concurrent calls spread over
several BTS), the CPU consumption looking up for gsm_subscriber_conn
based on SCCP conn_id can take a considerable amount of time (>5% of
osmo-bsc already taking 70% of the CPU time on the core it is running on).
The huge CPU consumption happens because a linear search is done (llist)
over the entire list of SCCP connections every time an SCCP message is
handled.
In order to optimize this lookup, this patch introduces a new struct
bsc_sccp_inst which becomes associated to the libosmo-sccp
osmo_sccp_instance. Each of this strucs maintains an rbtree of
gsm_subscriber_conn ordered by conn_id.
As a result algorithmic complexity adds O(log(N)) during insert, lookup
and delete of SCCP conns, but gets rid of O(N) previous lookup.
As a plus, finding a new conn_id now takes generally O(log(N)), while
before it used to take O(N).
Related: SYS#6200
Change-Id: I667d3ec1dad0ab7bc0fa4799d9611f3a914d07e5
Function bsc_sccp_inst_next_conn_id() allocating conn_id creates address
spaces based on sccp_instance, aka conn_id values can be reused given
the sccp_instance (MSC) is different.
Hence, when looking up a bsc_conn based on a conn_id, it must also match
the sccp_instance, otherwise a bsc_conn from another MSC could be
returned.
Change-Id: I80a54bdec3973917e88483a62bfc2e968b8c0490
Currently, the conn_id is allocated in a range 0..0xffffff by
bsc_sccp_inst_next_conn_id(), and -1 means it is unset.
This means allocation expects "int" to be at least 32 bits integer,
in order to fit 24 bits for 0..0xffffff plus the -1.
Hence, let's define the variable as uint32_t, as already done in
libosmo-sccp. Use last value 0xFFFFFFFF ((uint32_t)-1) and avoid playing
with the value being unsigned sometimes and signed only for "unset"
value.
The value is actually already handled as unsigned (printed with %u) in
most places.
Change-Id: If019bcbc1e28929fe8d981fef9103835fc6ead2e
These are not needed anymore since we re-introduced libbsc, specially to
avoid all this churn.
Some specific methods are explicitly required to be overwritten by
tests, so we specificially mark those with __attribute__((weak)) in
order to be able to overwrite them.
This is the last step towards fixing interdependency mess of symbols and
stubs, and requires previous patches in order to have tests apssing
fine.
Change-Id: Ic7401b8a6eb903882e30fda1cf091ac99a254ef0
It is not particularly interesting to see a periodic "Sending RESET" to an
unconnected MSC in the logs. De-escalate to LOGL_INFO to make it easier to
configure away these logs.
Sending a RESET ACK is much more interesting, because it indicates that a
connection has been established.
Note that additionally, there will be a log on DMSC LOGL_NOTICE whenever a link
goes up or down, so the RESET logging does not add much crucial information for
operation maintenance, see a_reset_link_up() / a_reset_link_lost().
Change-Id: I86d67d19e20135c4944613c8e99580ef0e22ea8d
So far we would cancel ongoing Paging for a given MSC only after receiving a
RESET message from that BSC. However, the typical operation would be that
OsmoBSC *sends* a RESET and receives a RESET-ACK.
Instead, move the call to within osmo_bsc_sigtran_reset(). This is also called
when OsmoBSC considers the A-interface link to be lost, from the a_reset.c
code, after multiple SCCP connection failures.
Change-Id: Ia14b916be56563d18632c69a833084e71799a468
Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that
it can be re-used on the Lb interface.
Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we
have generally established in our osmo_fsm implementations.
Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c.
A difficulty is setting a proper logging category: the FSM definition allows
only one fixed logging category for FSM state transitions and events. Ideally,
the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log
on DLCS. Since that is not possible, introduce a separate DRESET logging
category. This in fact matches an item on my wishlist, because if a given MSC
is configured but currently not connected, the previous RESET FSM would
continuously "spam" log LOGL_NOTICE messages indicating that it is resending
RESET, and I often want to silence those messages without silencing the entire
DMSC category. This is now easily possible by setting DRESET logging to
LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all
interesting info is still visible on DMSC.
Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
When adding the Lb interface, it is necessary to determine an unused conn id
across *all* SCCP users. Prepare adding Lb by moving conn id creation out of
the gscon code and generalizing.
Change-Id: I12fcb18f6e4380f72929cfe7681bac05330a8c9a
Location Services brings a new scenario to OsmoBSC: the MSC may create an
A-interface conn for a subscriber without an lchan being established (N-CONNECT
from MSC to BSC, so far only for an incoming inter-BSC handover).
If an MS becomes active while an A-interface conn is already established,
associate with an existing conn.
Change-Id: I42290f519a419ed7e8dd02a5ed0a5261b30a51e6
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: Ic93be6c47403e65b7c338604728570f23bc3de12
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
Refactor osmo_bsc_sigtran_init(): invoke osmo_sccp_simple_client_on_ss7_id()
exactly once per cs7 instance.
When introducing MSC pooling to the ttcn3-bsc-tests, it became apparent that
osmo-bsc rapidly huts down and re-creates the SCTP link for each configured
MSC. This manifested in an osmo-stp crash (fixed in libosmo-sccp
I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa). I first tried to fix it by only
restarting an ASP when it wasn't found in the AS yet, but that created obscure
problems described in OS#4635 which in turn completely broke ttcn3-msc-tests.
This solution keeps osmo_sccp_simple_client_on_ss7_id() unchanged and instead
invokes it exactly once per cs7 instance.
Keep the same auto-config logic, but change and improve the mechanisms to
achieve it:
Replace the fail_on_next_invalid_cfg flag with a more accurate check against
remote PC collisions between configured MSCs. Before this patch, the code made
sure that at most one MSC lacks an explicit remote address (and cs7 instance),
so that no two MSCs get the same default remote PC. This patch more accurately
checks that no two MSCs use the same remote PC on the same cs7 instance,
period, whether implicitly or explicitly configured.
Before this patch, the logic amounted to creating cs7 instance 0 implicitly,
but it was not very obvious: If an 'msc' has an msc-addr configured, it is
associated with the cs7 instance that has this addr in its address book. If it
has no msc-addr configured, then msc->a.cs7_instance_valid == false. In that
case, msc->a.cs7_instance is still 0 (from talloc_zero) and hence
osmo_sccp_simple_client_on_ss7_id(ss7_id = 0) created cs7 instance 0. In this
patch, that logic remains unchanged, but is written out more explicitly: if any
msc has no cs7 instance associated, make sure to create cs7 instance 0
beforehand.
Then iterate all osmo_ss7_instances. If at least one MSC uses it, set up the
SCCP client on it and connect all MSCs as appropriate.
Related: OS#4625 OS#4635
Change-Id: I16f4f7f447f69525a2f57c4649ab295112904d6a
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed
that osmo-bsc crashes with the following message:
Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376
The cause of this is a recently merged patch that calls conn_get_bts() during
assignment_fsm rate counter dispatch:
"Count assignment rates per BTS as well"
commit b5ccf09fc4
Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a
The root cause being that the assignment_fsm attempts to count an Assignment
event for a BTS after the lchan has already been released and disassociated
from the conn.
The assertion is found in conn_get_bts(), which is used in various places. In
fact, each caller is a potential DoS risk -- though most are in code paths that
are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the
relatively volatile presence of an lchan is not a good idea for osmo-bsc's
stability and error resilience.
- Change conn_get_bts() to return NULL in the lack of an lchan.
- Adjust all callers of conn_get_bts() to gracefully handle a NULL return val.
- Same for cgi_for_msc() and callers, closely related.
Here is a backtrace:
Program received signal SIGABRT
pwndbg> bt
0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376
0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758
0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325
0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257
0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260
0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291
0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953
0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6
0x0000555555b61bbe in _start ()
In the case of the assignment_fsm counter, we now miss a chance to increase a
BTS counter for a failed Assignment, but this is a separate problem. The main
point of this patch is that osmo-bsc must not crash.
Related: OS#4620, OS#4619
Patch-by: fixeria
Tweaked-by: neels
Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
The "new SIGTRAN connection" message is sent on every new transaction
between an MS and MSC, i.e. A LOT during normal operation. Let's
demote it to INFO and clarify that this is about SCCP connection
instead of a generic SIGTRAN term.
Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
NULL or 0.0.0.0 should actually not be used upon connect() calls.
Whoever, it worked so far because osmo_sock_init2() calls getaddrinfo()
on it which does the 0.0.0.0->127.0.0.1 translation.
osmo-msc already passed 127.0.0.1 as default address, so let's do the
same here.
Change-Id: Ib0d33c66faab78e609742638425cb8a0c382406f
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.
We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket. Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.
Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
Since in SCCPlite the BSC-attached MGW is controlled by the MSC, we
don't need this kind of signalling. It's only needed for AoIP.
Related: OS#2551
Change-Id: I802fc65c593e42aaa7a15cecab7a2f2b77ade3ea
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
In osmo_bsc_sigtran.c, instead of osmocom/mgcp/mgcp_common.h, include the same
file from mgcp_client/. (mgcp_common.h is identically installed both by
libosmo-mgcp and libosmo-mgcp-client, in their respective include dir.)
Trying to include from mgcp/ breaks the debian package builds, since only
libosmo-mgcp-client is installed as per osmo-bsc dependencies. The error was
introduced by:
commit d8f46c0074
"MGCP: add 'X-Osmo-IGN: C' for SCCPlite by default"
change id I257ad574d8060fef19afce9798bd8a5a7f8c99fe
Change-Id: I917b0c08ed91172ecb68c946aecb02c5109fcced
Use libosmo-mgcp-client's new X-Osmo-IGN header to indicate that CallIDs are
allowed to mismatch.
Add VTY commands 'msc' / 'mgw x-osmo-ign call-id' and 'no mgw x-osmo-ign' to
switch this behavior explicitly.
For SCCPlite MSCs, unless a specific config was issued, always send
'X-Osmo-IGN: C' by default, to ignore CallID mismatches.
Depends: Id7ae275ffde8ea9389270cfe3db087ee8db00b51 (osmo-mgw)
Change-Id: I257ad574d8060fef19afce9798bd8a5a7f8c99fe
The API of a_reset.c is currently called with a pointer to struct
reset_ctx. This puts the responsibility of checking the presence of
msc->a.reset_fsm to the caller. It would be much more effective if the
caller would check if msc->a.reset_fsm before dereferencing it.
This also fixes at least one segfault that ocurrs when gscon_timer_cb()
is called but no sccp connection is present yet. Therefore the pointer
to bsc_msc_data would not be populated. This is now detected by
a_reset.c itsself.
- minor code cleanups
- call a_reset.c functions with msc (struct bsc_msc_data)
Change-Id: I0802aaadf0af4e58e41c98999e8c6823838adb61
Related: OS#3447
When no connection is present and had never existed, then
conn->sccp.msc is unpopulated. However, there may be situations where
osmo_bsc_sigtran_send() is executed while no connection is present.
At the moment we assert on conn->sccp.msc, which would cause osmo-bsc
to exit. In order to avoid this, better check conn->sccp.msc and drop
the sccp message when the check is negative.
- Remove assertion, add check.
Change-Id: I4eaa983702224e5995a388ea9890ee04212eb569
Related: OS#3446
The function osmo_bsc_sigtran_send() checks if the MSC is ready by
calling a_reset_conn_ready(). If it is not ready it returns with
-EINVAL. The msg message buffer is not freed, so we leak memory in those
edge cases.
- Make sure msg is freed when MSC is not ready.
- Add a comment that osmo_bsc_sigtran_send() takes ownership of msg
Change-Id: Ib1ff1d20e960a356bcee276b7c1bf9c93283e7af
Add FSMs:
- timeslot_fsm: handle dynamic timeslots and OML+RSL availability.
- lchan_fsm: handle an individual lchan activation, RTP stream and release,
signal the appropriate calling FSMs on success, failure, release.
- mgw_endpoint_fsm: handle one entire endpoint with several CI.
- assignment_fsm: BSSMAP Assignment Request.
- handover_fsm: all of intra, inter-MO and inter-MT handover.
Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing
the maximum amount events (32), and it is more logical to treat assignment,
handover and MGW procedures in separate FSMs.
- Add logging macros for each FSM type:
- LOG_TS()
- LOG_LCHAN()
- LOG_MGWEP(), LOG_CI()
- LOG_ASSIGNMENT()
- LOG_HO()
These log with the osmo_fsm_inst where present.
New style decision: logging without a final newline char is awkward,
especially for gsmtap logging and when other logs interleave LOGPC() calls;
we have various cases where the final \n goes missing, and also this invokes
the log category checking N times instead of once.
So I decided to make these macros *always* append a newline, but only if
there is no final newline yet. I hope that the compiler optimizes the
strlen() of the constant format strings away. Thus I can log with or without
typing "\n" and always get an \n termination anyway.
General:
- replace osmo_timers, state enums and program-wide osmo_signal_dispatch()
with dedicated FSM timeouts, states and events.
- introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def.
These can be used (with some macro magic) to define a state's timeout once,
and not make mistakes for each osmo_fsm_inst_state_chg().
Details:
bsc_subscr_conn_fsm.c:
- move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and
mgw_endpoint_fsm.
- There is exactly one state for an ongoing Assignment, with all details
handled in conn->assignment.fi. The state relies on the assignment_fsm's
timeout.
- There is one state for an ongoing Handover; except for an incoming Handover
from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn
are both established.
- move bssmap_add_lcls_status() to osmo_bsc_lcls.c
abis_rsl.c:
- move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in
abis_rsl.c
- reduce some rsl functions to merely send a message, rename to "_tx_".
- rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the
lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function.
- move all timers and error/release handling away into various FSMs.
- tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an
lchan passed, but just mode,type that they require. Rename to
ipacc_speech_mode*() and ipacc_payload_type().
- add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR
message received during BSSMAP Handover Command.
- move various logging to LOG_LCHAN() in order to log with the lchan FSM instance.
One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging
from DRR to DRSL. It might actually make sense to combine those categories.
- lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance.
- handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's
correct).
- gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during
inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS.
assignment_fsm.c:
- the Chan Mode Modify in case of re-using the same lchan is not implemented
yet, because this was also missing in the previous implementation (OS#3357).
osmo_bsc_api.c:
- simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to
lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv
twice, once by member assignment and then again with a memcpy.)
- During handover, we used to copy the MR config from the old lchan. Since we
may handover between FR and HR, rather set the MR Config anew every time, so
that FR rates are always available on FR lchans, and never on HR lchans.
Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore),
I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore)
Change-Id: I82e3f918295daa83274a4cf803f046979f284366
In Change-Id OSI6b7354f3b23a26bb4eab12213ca3d3b614c8154f we introduced
a function called osmo_ss7_asp_rx_unknown() which was supposed ot
override a weak symbol in libosmo-sigtran. However, the related change
in libosmo-sigtran (I8616f914192000df0ec6547ff4ada80e0f9042a2) was
modified later on to use explicit registration of a call-back function
instead of weak symbol override.
Let's adopt the osmo-bsc code to make use of this explict call-back
registration.
Change-Id: Id5880ec90dfa00b29cbb0ffea8c8dd50e24742bd
Related: OS#2012
It's not a good idea to keep extern declarations copied over
half a dozen C files. Let's move it to a header.
Change-Id: I6f643f1393ba0955d9c0cf1cf78d5c604e7b9451
The bsc_msc_connection dates back to the old pre-libosmo-sigtran
days, and 90% of the field members weren't used at all (even the
new sigtran specific ones!). Let's merge what remains into struct
bsc_msc_data.
As a side effect, the already dysfunctional "dest A.B.C.D" VTY
command has been removed from the MSC node.
There's quite a bit of fall-out in the CTRL interface, which was
the code with strongest ties to bsc_msc_connection. This was
resolved by properly porting CTRL handling over to libosmo-sigtran,
meaning that an IPA/SCCPlite connected MSC can now again send CTRL
GET/SET commands, and can also receive those selective few TRAPs
that old osmo-bsc-sccplite also sent to its MSC[s].
Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f
Related: OS#2012
We used to have hard-coded M3UA. Let's allow the user to configure
this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command.
For SUA this should just work 1:1 without any trouble. For IPA,
this of course only changes the underlying transport without reflecting
the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling,
etc.
Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13
Related: OS#2544
The function a_reset_free() is not used anywhere at the code. The
reason for this is that a BSC instance is never cleared once it
is started up. Also the timer number is not according to the spec.
- Remove a_reset_free()
- Fix timer identification number (T4)
- use fi->priv to hold context info
- Fix sourcecode formatting
Change-Id: I72095d52304c520e383755eee6c889bce492cbd4
Related: OS#3102
In the current implementation of osmo-bsc, the subscriber connection is
not handled (very) statefully. However, there is some state keeping in the
code that handles the mgcp connection, but there are still to much loose ends
which allow odd situations to happen, which then lead severe error situations
(see also closes tags at the end) This commit adds a number of improvements
to fix those problems.
- Use an osmo-fsm to control the gsm_subscriber_connection state and
make sure that certain operations can only take place at certain states
(e.g let connection oriented SCCP traffic only pass when an SCCP connection
actually exists.
Remove the old osmo_bsc_mgcp.c code. Use the recently developed MGCP client
FSM to handle the MGCP connections.
Also make sure that stuff that already works does not break. This in
particular refers to the internal handover capability and the respective
unit-tests.
See also OS#2823, OS#2768 and OS#2898
- Fix logic to permit assignment to a signalling channel. (OS#2762)
- Introduce T993210 to release lchan + subscr_conn if MSC fails to respond
The GSM specs don't have an explicit timer for this, so let's introdcue
a custom timer (hence starting with 99).
This timeout catches the following situation:
* we send a SCCP CR with COMPL_L3_INFO from the MS to the MSC,
* the MSC doesn't respond (e.g. SCCP routing failure, program down, ...)
The MS is supposed to timeout with T3210, 3220 or 3230. But the BSC
shouldn't trust the MS but have some timer on its own.
SCCP would have a timer T(conn est), but that one is specified to be
1-2min and hence rather long.
See also: OS#2775
- Terminate bsc_subscr_conn_fsm on SCCP N-DISC.ind from MSC
If the MSC is disconnecting the SCCP channel, we must terminate the FSM
which in turn will release all lchan's and other state.
This makes TC_chan_rel_hard_rlsd pass, see also OS#2731
As a side-effect, this fixes TC_chan_act_ack_est_ind_refused(),
where the MSC is answering with CREF to our CR/COMPL_L3.
- Release subscriber connection on RLL RELEASE IND of SAPI0 on main DCCH
The subscriber connection isn't really useful for anything after the
SAPI0 main signalling link has been released. We could try to
re-establish, but our best option is probably simply releasing the
subscriber_conn and anything related to it.
This will make TC_chan_rel_rll_rel_ind pass, see also OS#2730
This commit has been tested using the BSC_Tests TTCN3 testsuit and the
following tests were passed:
TC_chan_act_noreply
TC_chan_act_ack_noest
TC_chan_act_ack_est_ind_noreply
TC_chan_act_ack_est_ind_refused
TC_chan_act_nack
TC_chan_exhaustion
TC_ctrl
TC_chan_rel_conn_fail
TC_chan_rel_hard_clear
TC_chan_rel_hard_rlsd
TC_chan_rel_a_reset
TC_rll_est_ind_inact_lchan
TC_rll_est_ind_inval_sapi1
TC_rll_est_ind_inval_sapi3
TC_rll_est_ind_inval_sacch
TC_assignment_cic_only
TC_assignment_csd
TC_assignment_ctm
TC_assignment_fr_a5_0
TC_assignment_fr_a5_1_codec_missing
TC_assignment_fr_a5_1
TC_assignment_fr_a5_3
TC_assignment_fr_a5_4
TC_paging_imsi_nochan
TC_paging_tmsi_nochan
TC_paging_tmsi_any
TC_paging_tmsi_sdcch
TC_paging_tmsi_tch_f
TC_paging_tmsi_tch_hf
TC_paging_imsi_nochan_cgi
TC_paging_imsi_nochan_lac_ci
TC_paging_imsi_nochan_ci
TC_paging_imsi_nochan_lai
TC_paging_imsi_nochan_lac
TC_paging_imsi_nochan_all
TC_paging_imsi_nochan_plmn_lac_rnc
TC_paging_imsi_nochan_rnc
TC_paging_imsi_nochan_lac_rnc
TC_paging_imsi_nochan_lacs
TC_paging_imsi_nochan_lacs_empty
TC_paging_imsi_a_reset
TC_paging_counter
TC_rsl_drop_counter
TC_classmark
TC_unsol_ass_fail
TC_unsol_ass_compl
TC_unsol_ho_fail
TC_err_82_short_msg
TC_ho_int
Authors:
Harald Welte <laforge@gnumonks.org>
Philipp Maier <pmaier@sysmocom.de>
Neels Hofmeyr <neels@hofmeyr.de>
Closes: OS#2730
Closes: OS#2731
Closes: OS#2762
Closes: OS#2768
Closes: OS#2775
Closes: OS#2823
Closes: OS#2898
Closes: OS#2936
Change-Id: I68286d26e2014048b054f39ef29c35fef420cc97
osmo_bsc_sigtran.c uses DRANAP instead of DMSC in two places,
this is not correct.
- change wrong DRANAP to DMSC
Change-Id: I1594d1906cf7d053d00fff52e9dc0ddfd097ed6e
Pau Espin
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy
Martin Hauke
Philipp Maier