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.
Abort upon unknown options and missing option arguments. This came to my
attention while rewiring the -m and -M options: passing -M without argument
would launch nitb with wrong configuration. So, rather exit immediately.
If there are legacy options that should be ignored, they deserve an own 'case:'
in the option switch. There are none that I'm aware of though.
Strictly speaking, the unix domain socket location is not a name but a path.
The MNCC socket is called path, so it is confusing to call the ctrl socket
a 'name'.
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.
Remove unused talloc.h from bsc_vty.c.
In bsc_nat.c, use OSMO_CTRL_PORT_BSC_NAT instead of hardcoding port number, and
include ctrl/ports.h for that.
Fix comment typo "COMAMND"
Remove the assert in the llme by avoiding the usage of foreign to local
mappings of TLLIs. The asserts had been hit at 32C3 and the fixes were
created by Jacob and had been tested at the convention.
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 BSSGP cell identifier is used to get the RA for the TLLI lookup.
The send_0408_message function used in the tests does not set this,
so the RA identifier is always 0-0-0-0.
This commit adds a parameters to pass the RAID and adds missing
dummy RAIDs.
Note that the CI can still not be set and thus is always 0.
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
This patch lets the build script for openbsc find the libsmpp34 installation
with the help of pkg-config instead of assuming the header files are in
/usr/include.
In 'show running-config', timeslot appears as a sub-element of rsl, but it is a
direct child of trx. Fix the timeslot section in vty_out by removing one space
of idention.
Adjust various config examples.
Rationale: it's not relevant for function, but confuses human operators. Fixing
it will save the next hacker some time.
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
memcpy has both the source and destination marked as non-null and
we were still passing NULL (with a zero size) to it. While this
makes sense it violates the constraints of the function. Add the
check to see if these values are NULL or not.
+db.c:583:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40d7f7 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40d7f7)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
+
+db.c:590:2: runtime error: null pointer passed as argument 2, which is declared to never be null
+ #0 0x40da23 in get_equipment_by_subscr (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40da23)
+ #1 0x40f6d2 in db_get_subscriber (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40f6d2)
+ #2 0x40bfaa in sms_from_result_v3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40bfaa)
+ #3 0x40c847 in update_db_revision_3 (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40c847)
+ #4 0x40cbc3 in check_db_revision (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cbc3)
+ #5 0x40cf85 in db_prepare (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x40cf85)
+ #6 0x406f18 in main /home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test.c:179
+ #7 0x7fd625638a3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
+ #8 0x405598 in _start (/home/builder/jenkins/workspace/Osmocom_Sanitizer/source/openbsc/openbsc/tests/db/db_test+0x405598)
When a MNCC handler wants to issue the MNCC_BRIDGE primitive
overt the MNCC interface, this was not possible so far via the
MNCC socket. This primitive was so far only available from the
internal MNCC handler, more or less by accident I suppose. The reason
for this is in the way the array of two call references had been passed
into mncc_tx_to_cc().
The debug log prints the received/sent bytes in hex. When this data surpasses
the buffer size available for the log string (4096), the log is truncated
and lacks a newline character. Limit the amount of dumped bytes to 1000.
Sponsored-by: On-Waves ehi
Handle peer restart earlier, so that all the tunnels are deleted by the restart
code path, instead of the first one being deleted due to reused TEI. That
caused confusing logging messages.
Also, when receiving Delete confirmations from the peer that didn't restart,
don't complain about unknown peer, but acknowledge and remove the half
invalidated tunnel. This means that the pending delete entry from the restart
code path is not needed / not used, so don't bother to add pending delete
entries upon peer restart.
The test test_peer_restarted_reusing_tei() hits the situation where a tunnel is
removed because of a reused TEI rather than the restart counter. Adjust the
test to expect the "out-of-band" delete request earlier on, and to still see
the half invalidated tunnel around. Enhance the test by adding the delete
response from the peer that didn't restart, and add a final tunnels_are()
verification.
Sponsored-by: On-Waves ehi