Age | Commit message (Collapse) | Author | Files | Lines |
|
Add libiu to contain the parts used by both Iu-CS (in osmo-cscn) and Iu-PS (in
gprs) into libiu. It's rather thin and may make sense to move to osmo-iuh
altogether, eventually.
iu.c is half moved to libiu/, and half to osmo-cscn/iu_cs.c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rename conn_ctx_list -> ue_conn_ctx_list.
Indicate Iu-CS 'siblings' for a couple of functions.
Tweak/add comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
That code seems to be usable for the CS side, as well. A more general name
is applicable. todo: move out of gprs even.
|
|
It was a uint16_t*, but is passed as a uint16_t, and never used anyway, yet.
|
|
|
|
|
|
|
|
|
|
The comment says so and it was moved above sgsn_mm_ctx_free in a commit
marked as ugly hack.
|
|
|
|
|
|
this means we no longer try to link to hard-coded files outside of the
openbsc.git repository.
|
|
|
|
|
|
|
|
In case the GMM message did not arrive over a Gb interface, there is no
LLME (and thus the associated pointer is NULL). Don't try to perform
operations on a NULL LLME.
|
|
Soem of the operations we perform in the GMM layer are specific to the
GPRS/EDGE radio access network and its Gb interface. Let's make them
conditional to that in preparation of supporting an Iu interface.
|
|
There was a comment in the code that certain GMM messages require a
valid mmctx pointer. However, nothing actually checked if that pointer
was in fact non-NULL. We plainly crashed if a MS would send us the
wrong message in the wrong state.
|
|
This is the entry point for GMM from Gb. We will create a new one
for Iu, so let's be explicit rather than implicit.
|
|
Let's explicitly mark those sgsn_mm_ctx members that apply for Gb mode
and (upcoming) Iu mode, respectively.
|
|
Add ctrl_vty_init() calls and feed the ctrl_vty_get_bind_addr() return value to
ctrl_interface_setup() in the following programs:
osmo-bsc
osmo-bsc_nat
osmo-nitb
osmo-sgsn
For osmo-sgsn, move the control interface setup invocation below the config
parsing, so that the ctrl_vty_get_bind_addr() can return the configured
address.
|
|
Following the 'line vty'/'bind A.B.C.D' command added in libosmocore, use the
configured address to set the telnet bind for the VTY line. It is now possible
to publish the VTY on a specific local interface (including 0.0.0.0 aka "any").
Implement in all of:
osmo-gbproxy
osmo-gtphub
osmo-sgsn
osmo-bsc
osmo-bsc_nat
osmo-bsc_mgcp
osmo-nitb
In some of these main programs, move the telnet initialization below the
configuration parsing.
Historically, this was not a good idea for programs using bsc_init.c (aka
bsc_bootstrap_network()), since they expected a gsm_network struct pointer in
((struct telnet_connection*)vty->priv)->priv, so that telnet had to be either
initialized or replaced by a dummy struct. In the meantime, the gsm_network
struct is not actually looked up in a priv pointer but in the static bsc_vty.c
scope (bsc_gsmnet), so this limitation is mere legacy (even though said legacy
is still there in an "#if 0" chunk).
In the other binaries I have briefly looked at the init sequence dependencies
and found no reason to initialize telnet above the config file parsing. In any
case, I have tested every single one of abovementioned binaries to verify that
they still parse the example config successfully and launch, allowing VTY
connections on the configured address(es). I hope this suffices.
In all of the above, log VTY address and port. LOGL_INFO is disabled by default
in some of the logging scopes, and since it is a single log message right at
program launch, I decided for the slightly more aggressive LOGL_NOTICE.
|
|
|
|
|
|
If an MM context cannot be found based on BBSGP info and a RA UPDATE
REQUEST is received, try to find an MM context with an P-TMSI from
which the TLLI could have been derived. This also checks, whether the
routing area matches.
This is similar to the old behaviour removed by the commits
"sgsn: Only look at TLLIs in sgsn_mm_ctx_by_tlli" and
"sgsn: Remove tlli_foreign2local", except that this will only
be done for RA UPDATE REQUESTs now.
Sponsored-by: On-Waves ehf
|
|
Currently the MM context is just overwritten by a call to
sgsn_mm_ctx_by_tlli(msgb_tlli(msg), &old_ra_id) even if it
has already been found by using the BSSGP info. With the changes
made to sgsn_mm_ctx_by_tlli this will never find a MM context if
the routing area has changed. If the routing area has not changed,
the mmctx has already been found if it exists.
This commit splits searching for an MM context (if it hasn't been
found already) from checking, whether a found one can really be
used. The actual search is removed, so that the MS will be forced to
restart the attach procedure, which is less efficient but safe.
Sponsored-by: On-Waves ehf
|
|
Currently the code also matches the TLLI against LOCAL and FOREIGN
mappings of the P-TMSI, thus eventually finding MM contexts not
consistent with the TLLI (both tlli and tlli_new differ). On
the other hand, tlli_new is not checked at all.
This commit changes the function to only look at mmctx->tlli,
mmctx->tlli_new, and the routing area.
Sponsored-by: On-Waves ehf
|
|
The function is moved to gprs_utils.c, renamed, and made non-static
to be usable in other modules, too.
Sponsored-by: On-Waves ehf
|
|
Currently foreign TLLI are sometimes mapped to local TLLI in the
hope that they will match. This seems to sometimes introduce
inconsisties, possibly leading to a failing assertion in
_bssgp_tx_dl_ud.
This mapping should probably reduce the allocation of additional
LLME during routing area changes.
This commit removes tlli_foreign2local.
Sponsored-by: On-Waves ehf
|
|
At Rhizomatica we see that some GSM 04.08 messages are leaked and
have no other indication if that is Call Control, SMS or something
else.
|
|
|
|
Even if fclose fails the stream is inaccessible and the second fclose
might cause memory violation.
Linux manpage says:
Upon successful completion 0 is returned. Otherwise, EOF is returned
and errno is set to indicate the error. In either case any further
access (including another call to fclose()) to the stream results in
undefined behavior.
Fixes: CID#57958
|
|
Same as with the previous gtphub commit. Make these static to deal
with the new semantic of inline in gcc5.
|
|
The semantic of inline has changed and we need to make it static
to not end up with undefined references.
|
|
|