Age | Commit message (Collapse) | Author | Files | Lines |
|
There's no real need to allocate it using talloc. Allocating it on the
stack simplifies the code, avoids mem leaks and makes it faster.
Change-Id: I66c44890952339f15131081e2f629a2824b6d3ba
|
|
In bsc_nat_parse(), parsed is allocated this way:
"""parsed = talloc_zero(msg, struct bsc_nat_parsed);"""
So parsed is a child of msg, and so it's freed when msg is freed.
Since libosmocore c7f52c4c84d6a8898048738c4db9266289c40b45,
osmo_wqueue_enqueue() correctly detects queue full and returns an error,
and then queue_for_msc() calls msgb_free(). Code in osmo-bsc-nat was
probably written before that change in behavior, so that's why probably
the bug was not hit before.
The "if (parsed)" condition is removed since it's actually fine to
talloc_free(NULL).
Related: SYS#4548
Change-Id: I209d3e2d809a67915ec43c874e68f7f746a565f0
|
|
Might be useful in the future for its callers, since sometimes actions
need to be taken place based on whether enqueuing failed (and msg was
freed).
Change-Id: I9f172f9c9ca9db18f6adcf9267db23c73e9d5bc6
|
|
ipa_ccm_idtag_parse_off is broken, and can only be used with
len_offset=1 on ID Request messages, otherwise won't work correctly.
Modify ipa_ccm_idtag_parse to at least parse those correctly, and
document the limitations.
Those two functions are already deprecated and only used in openbsc by 3
callers:
* ipa_ccm_idtag_parse in ussd_read_cb(): Broken, that function can only
work for Requests and it's used to parse a Response.
* ipa_ccm_idtag_parse_off in forward_sccp_to_msc (NAT): Broken, it can
only be used to parse Requests and it's used to parse a Response.
Furthermore, len_offset=2 is passed which makes no sense and most
probably it fails always, or can even make the program crash.
* ipa_ccm_idtag_parse_off in (answer_challenge): This one is fine and
could actually be replaced with ipa_ccm_id_get_parse after libosmocore
commit (see below) is merged.
See libosmocore I6efc852dfc041192f554e41a58290a0f63298021 for more information.
As a consequence of the fixes, osmo-bsc-nat now parses messages sent
from VTY test correctly and thus it goes into processing them instead of
silently dropping them. As a result, some VTY tests fail because they
are sending incorrect format (missing NULL char in unit id strings) and
osmo-bsc-nat closses its connection (due to bad auth).
Change-Id: I3b995f8ef0b48c0a5b3375e42926641934359cd2
|
|
bsc_msc_lost will close the current fd (without freeing it), so let's
skip possible writes to an already closed fd
bsc_msc_lost will close the current fd (without freeing it), so let's
skip possible writes to an already closed fd..
Change-Id: I55c1a88f6524e897c70abf8ba18f1bb2b1f650aa
|
|
PONG is being sent a as an answer to PING a few lines above in same
function.
Change-Id: I88ca95d46f4ace1da4025d12302422dbfa578354
|
|
Code is already doing stuff with the connection (fd).
Change-Id: Ieeaa0e024b9542d1a22a8e3ab4c3229a6f8a0b49
|
|
Change-Id: Ib36b8937d1210488784ebae6917cb1b4c871c9d4
|
|
Currently the force_realloc feature is turnd on and of in a
hardcoded way. This patch makes the option available via VTY.
Backport from osmo-mgw.git.
Change-Id: Ic8740512c5ea0766ff6ceb1c28b9c2b3fe46e75f
|
|
This command controls forward/drop of BSS paging messages from MSC to
all BSCs connected to BSC-NAT.
In situations in which MS don't generally roam from one BSC to another
under the BSC-NAT, it may be beneficial (bandwidth wise) to drop these
global paging commands, which are usually issued by the MSC if the
location of the MS isn't known and LAC paging has failed.
Change-Id: I737774543e0a8734d79b072e66e3c09e82b001d3
|
|
Previous to this commit, an error message was printed and the paging
message was dropped:
openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c:618 Could not parse paging message: -3
Related: OS#3325
Change-Id: I3125ba0e67d2965c0be3089748dd113b1bf615af
|
|
Change-Id: I4dbf97905749aa9379bc6b6b448953d8b1825545
|
|
Change-Id: I6a6fc3574630c0893797388bbbdeabe14572f988
|
|
Previous to this patch, if ipaccess_auth_bsc() failed finding the
requested auth token, it would call bsc_close_connection() on it.
However, it would not report callers that the bsc conn was closed.
Since ipaccess_auth_bsc is called in the following path:
[osmo_wqueue_bfd_cb->ipaccess_bsc_read_cb->forward_sccp_to_msc->ipaccess_auth_bsc]
It needs to notify the lower layers (wqueue) that the conn/osmo_fd has been
freed an it should avoid keep using/forwarding it again.
This patch fixes this issue by moving the conn closing one layer down
the stack (from ipaccess_auth_bsc to forward_sccp_to_msc), and in there
we now close the conn and provide required information to the callers.
Fixes following Asan report:
Unit_Name='foobar' <0015> openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c:1061 No bsc found for token 'foobar' len 6 on fd: 11.
=================================================================
==18946==ERROR: AddressSanitizer: heap-use-after-free on address 0x616001f8b81c at pc 0x7ffff6067540 bp 0x7fffffffe170 sp 0x7fffffffe168
READ of size 4 at 0x616001f8b81c thread T0
#0 0x7ffff606753f in osmo_wqueue_bfd_cb libosmocore/src/write_queue.c:65
#1 0x7ffff605206b in osmo_fd_disp_fds libosmocore/src/select.c:217
#2 0x7ffff6052305 in osmo_select_main libosmocore/src/select.c:257
#3 0x421c8e in main openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c:1714
#4 0x7ffff47ffb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#5 0x406438 (/bin/osmo-bsc_nat+0x406438)
Fixes: SYS#4250
Change-Id: Ifb39a045b98bc2043a98a9787fc61cbcddc368e0
|
|
This commit changes behaviour to a (imho) better logic and is a
preparation for follow-up commits to avoid heap-use-after-free error
when closing the bsc connection.
Previously, authentication would still not be accepted but the
connection would be staying alive for a while until id_timeout timer
triggers. Let's close the connection immediately instead, this way BSC
side can see quickly something is wrong with what it is sending.
Furthermore, this way the logic of the function is simplified: If auth
goes well, conn is alive. If auth goes wrong, conn is closed.
Change-Id: I972961b8967076c56c607f98c2360054144951e4
|
|
variable "parsed" was not being freed in this case. By calling exit2 we
make sure it is freed.
Change-Id: Ifd0c145ff733fdfb2f6fcb32065de99ee951d106
|
|
exit3 is the same as exit2 with the addition of calling
bsc_send_con_refuse(). Since exit3 path is only followed once, it's
easier to call bsc_send_con_refuse() on that code path and remove exit3
entirely in order to simplify the function.
Change-Id: I2ba0aeca1ee0fffd75019bfba37907f0b8015066
|
|
Change-Id: I1e98ef1dd410aa3e534666356a74590dac87b918
|
|
Fixes: 38a77d0098b21e14a42a91fd83bc8179b2978555
Change-Id: Iedf45a787d5e684b2f199e8e947da434fe75cf05
|
|
When ipaccess_bsc_read_cb calls bsc_close_connection, the osmo_fd
struct is freed, so we need to indicate to osmo_wqueue_bfd_cb that it
should not continue using the fd pointer after we return.
Fixes following AdressSanitizer report:
<0015> openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c:1317 The connection to the BSC Nr: -1 was lost. Cleaning it
=================================================================
==27028==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000c521c at pc 0x7ffff606b056 bp 0x7fffffffe170 sp 0x7fffffffe168
READ of size 4 at 0x6160000c521c thread T0
#0 0x7ffff606b055 in osmo_wqueue_bfd_cb libosmocore/src/write_queue.c:65
#1 0x7ffff6055c3b in osmo_fd_disp_fds libosmocore/src/select.c:217
#2 0x7ffff6055ed5 in osmo_select_main libosmocore/src/select.c:257
#3 0x421c82 in main openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c:1713
#4 0x7ffff4803b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#5 0x406438 (/bin/osmo-bsc_nat+0x406438)
Fixes: OS#3300
Change-Id: I120f646601bd4275b9088d0d73000ce04564bc6b
|
|
Change-Id: Ic2e4ca7d8eb4e8f71dc773b3f2c0f09709d90a94
|
|
Drop OpenSSL/libcrypto dependency, use osmo_get_rand_id() instead.
Backport
osmo-msc 753c15de2f00e24f76ac9b01a20e1e2ff0f86ce2
= I71cd631704a4dc155c6c752fee2a42cd6e2fa336
"
Migrate from OpenSSL to osmo_get_rand_id()
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
"
Apply similar changes in bsc-nat, mm_auth_test etc.
Tested manually with osmo-nitb and sysmoBTS, and verified that Authentication
Requests send heterogenous RAND tokens.
Related: OS#1694
Change-Id: I81ebd55c7c90a436c5f2090e6790d78b773d2c92
|
|
Use new function available in libosmocore to set up timers. Compile
tested only.
Change-Id: Ibcfd915688e97d370a888888a83a7c95cbe16819
|
|
Since ce9fec3e896571835ac5bfd2980d6836f2b29f0d libosmocore ignores
parameters to log_vty_command_* functions. Hence parameter of
logging_vty_add_cmds() is ignored too. As we depend on much later
libosmocore version anyway, we can simplify code somewhat by removing
parameters which will be ignored anyway.
Change-Id: I62f752fd88f1d8fefa563648f9864c7c31f87991
|
|
Drop extern definitions of talloc_msgb_ctx and use msgb_talloc_ctx_init()
instead.
In sgsn_test.c, use a local variable msgb_ctx to do the talloc report
from the return value of msgb_talloc_ctx_init().
Change-Id: I2f9ace855f0ecbdc9adf5d75bcb1a3d666570de4
|
|
After libosmocore 38d232ee5d2ceb045d9ad6d3a23afcb4972523f7 which outputs
'CTRL at <ip> <port>' from ctrl_interface_setup_dynip(), there's no need to log
the CTRL bind here anymore.
Change-Id: I1a874efe365a1ecf8ec37b058215b95b9a635ec2
|
|
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: I97a730b28759df1d549a5049f47a3da1c16a3447
|
|
This needs the corresponding commit in libosmocore which imports
the related functions
|
|
|
|
Introduce new configuration option bscs-config-file which includes BSC
configuration from the given file. Both absolute and relative (to the
main config file) paths are supported.
Add 'show bscs-config' command to display current BSC configuration.
Note: it is still possible to have BSC configuration in the main
file (provided proper index number is used) and in runtime but BSC
configuration is no longer saved automatically. The management of
included configuration file is left to external tools.
Update configuration examples.
Fixes: OS#1669
Sponsored-by: On-Waves ehf
|
|
|
|
Replace hardcoded protocol discriminator and message type bitmasks with
function calls recently introduced in libosmocore.
Note that the release 98 bitmasks slightly differ from the release 99 bitmasks.
This patch uses the "default" gsm48_hdr_msg_type invocation, thus it depends on
libosmocore whether 98 or 99 bitmasks are used.
In some places, use of the bitmask was erratic. Fix these implicitly by
employing the bitmask functions:
* silent_call.c: silent_call_reroute(): add missing bitmask for MM.
* bsc_msg_filter.c: bsc_msg_filter_initial(): RR vs. MM messages.
* osmo_bsc_filter.c: bsc_find_msc() and bsc_scan_bts_msg(): RR vs. MM
messages.
* bsc_nat_rewrite.c: bsc_nat_rewrite_msg(): SMS vs. CC messages.
* bsc_ussd.c: no bitmask is applicable for the message types used here.
* gb_proxy.c: gbproxy_imsi_acquisition(): missing bit mask for pdisc.
In gprs_gb_parse.c: gprs_gb_parse_dtap(), add a log notice for unexpected
message types.
|
|
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.
|
|
|
|
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"
|
|
This commit initialises and enables the stats subsystem for the given
binaries.
Sponsored-by: On-Waves ehf
|
|
Add new kitchen sink openbsc/utils.h and libcommon/utils.c to make three so far
static functions public (so I can use them in the upcoming OAP code).
A place to put them could have been the gprs_utils.h, but all general functions
in there have a gprs_ prefix, and todo markings to move them away. All other
libcommon headers are too specific, so I opened up this kitchen sink header.
Replace the implementation of encode_big_endian() with a call to
osmo_store64be_ext(). See comments.
Apply the change in Makefiles and C files.
|
|
clang complained that different enums are mixed with the
return type and we actually want this to be an int now.
|
|
|
|
We don't need to consume all the entropy of the kernel but can
use libcrypto (OpenSSL) to generate random data. It is not clear
if we need to call RAND_load_file but I think we can assume that
our Unices have a /dev/urandom.
This takes less CPU time, provides good enough entropy (in theory)
and leaves some in the kernel entropy pool.
|
|
We are using the token to find the right bsc_config and
then we can use the last_rand of the bsc_connection to
calculate the expected result and try to compare it with
a time constant(???) memcmp.
|
|
Check if the NAT has sent 16 bytes of RAND and if a key
has been configured in the system and then generate a
result using milenage. The milenage res will be sent and
noth the four byte GSM SRES derivation.
|
|
Generate 16 byte of random data to be used for A3A8 by
the BSC in the response. We can't know which BSC it is
at this point and I don't want to send another message
once the token has been received so always send the data
with an undefined code. The old BSCs don't parse the
message and will happily ignore the RAND.
/dev/urandom can give short reads on Linux so loop
around it until the bytes have been read from the kernel.
|
|
Instead of doing open/read/close all the time, open the
FD in the beginning and keep it open. To scare me even
more I have seen /dev/urandom actually providing a short
read and then blocking but it seems to be the best way
to get the random byes we need for authentication.
So one should/could run the cheap random generator on
the system (e.g. haveged) or deal with the NAT process
to block.
|
|
Unfortunately the basic structure of the response is broken.
There is a two byte length followed by data. The concept of
a 'tag' happens to be the first byte of the data.
This means we want to write strlen of the token, then we
want to write the NUL and then we need to account for the
tag in front.
Introduce a flag if the new or old format should be used.
This will allow to have new BSCs talk to old NATs without
an additional change. In the long run we can clean that up.
|
|
In case the token was not correct, just close the connection.
It is not clear that forcing a new TCP connection is going to
give us any extra security here. But with the upcoming auth
handling it does make sense to have both case look similar.
|
|
In the upcoming authentication improvements it is nice to
separate the finding of the config from the post-allow
handling of it.
|
|
The msgb will always have these bytes but it is better practice
to verify that the message really has space for the two bytes.
|
|
|