Age | Commit message (Collapse) | Author | Files | Lines |
|
Back-port from osmo-bsc.git d99182c01037f4dd14fb72b2b06497e0c1bebb49.
Change-Id: I0b951a9c3dbe245c3813fc91ceb9118a0de779b8
|
|
Back-port from osmo-bsc.git a0f1196eda79de0e838b29eb91d9f31839f2f447.
Change-Id: I519fb945a99206dff6c4aeb476d527e632b7e751
|
|
Previous state is harmless because the pointer is stored but not used in
that function. However, it's more clear this way.
Back-port from osmo-bsc.git 9ab47eb52da73d25c4f94869385a4f836032362a.
Change-Id: Ic17c38578587a774da29266302e7b201ecacd3a3
|
|
Other VTY commands already exist which provides each a subset of these
features, but while operating bsc-nat it became interesting to have all
this info easily reachable for a specific BSC.
Change-Id: I47bfd4fb800390505bdeb0f1d0bd1306fb888a59
|
|
Fixes following runtime warning:
libosmocore/src/rate_ctr.c:219 counter group 'nat:filter' already exists for index 0, instead using index 1. This is a software bug that needs fixing.
Change-Id: Ibe615379dc44a3a68cf9037630891ebf9b03a06d
|
|
The '.' is illegal character in counter names, as they are exported
via CTRL interface, where '.' has a special meaning that cannot be
used by strings comprising the variable name.
Change-Id: I55470ae74d350e4020209921fd8a09b51b120a41
|
|
When ussd_read_cb calls bsc_nat_ussd_destroy 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 AddressSanitizer report:
<0015> osmo-bsc_nat/bsc_ussd.c:273 USSD Connection on 13 with IP: 1.2.3.4
<0015> osmo-bsc_nat/bsc_ussd.c:132 USSD Connection was lost.
=================================================================
==18118==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200047c4b4 at pc 0x7ffff6067540 bp 0x7fffffffe170 sp 0x7fffffffe168
READ of size 4 at 0x61200047c4b4 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 0x421dfa in main osmo-bsc_nat/bsc_nat.c:1718
#4 0x7ffff47ffb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#5 0x406438 (/bin/osmo-bsc_nat+0x406438)
Change-Id: I35854c43524714d07f31d71c775ac1cd0a57d22e
|
|
Fixes: OS#3335
Change-Id: I847e84d5cc50619059cbae7a2c6471c60609aec6
|
|
Change-Id: Iad663d36d70196408806de664a39863f4d12238b
|
|
Change-Id: I4dbf97905749aa9379bc6b6b448953d8b1825545
|
|
Change-Id: I6a6fc3574630c0893797388bbbdeabe14572f988
|
|
Got this warning since my upgrade to gcc 8.1.0. Quick check tells me
it's probably a false positive, but let's fix the warning anyway.
openbsc/openbsc/src/libmsc/gsm_04_08.c: In function ‘gsm0408_dispatch’:
openbsc/openbsc/src/libmsc/gsm_04_08.c:1260:5: error: ‘res_len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (res_len != 4) {
^
openbsc/openbsc/src/libmsc/gsm_04_08.c:1223:10: note: ‘res_len’ was declared here
uint8_t res_len;
^~~~~~~
Change-Id: Ifa45f73645c9ab022c18a012abe03214aa21526f
|
|
Fix a really silly bug I introduced recently (same commit in
osmo-bsc.git doesn't contain the issue).
Fixes: d05d05b2773a1dc96a51104034942d504f2b1166
Related: SYS#4254
Change-Id: I7bac2ce001d4a6dcea2a896af30edf84942b68de
|
|
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
|
|
Change-Id: I91b18aeb8bdc2a1b392474318b1df1b4b1fee5a3
|
|
Fixes: 38a77d0098b21e14a42a91fd83bc8179b2978555
Change-Id: Iedf45a787d5e684b2f199e8e947da434fe75cf05
|
|
Change-Id: I2c0db366caef5632d4e04feeda1f83e79a58995f
|
|
Change-Id: I51bb656b5fef3247edc63477f391c954c4b28f56
|
|
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
|
|
Right now, it's impossible to see any ACC Ramping information unless RSL
category is set to DEBUG. Barring and Allowing Access Control Class is
an important event which should be printed in most cases.
Increase log levels of messages printed during some error conditions to
be handled as errors.
Backport of osmo-bsc.git commit
67f20bc356a4908bdb71b5dfc6a1932e6c1fac68.
Change-Id: Iec10c2be7aa5efeadd6b0706916678acc5461111
|
|
Older ones are being deprecated as they may generate interleaved
packets.
Depends on libosmo-netif.git Change-Id I4e05ff141eb4041128ae77812bbcfe84ed4c02de.
Change-Id: I189564fc63139c15314db8975afd423c7153ea32
|
|
Backport from osmo-bsc.git Change-Id I7a5e5d26f250f954853c12cfd4de08fed68c178e.
Change-Id: Id2ed51eed42e9fd9c91d257c245f7bce8d568f3a
|
|
Backport from osmo-msc Change-Id Iaf0d251c8d2912266a087ada4d20905146e08592.
Fixes following error catched by enabling address sanitizer:
==20792==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000122610 at pc 0x7f9c9c3fe063 bp 0x7ffd2e68f600 sp 0x7ffd2e68edb0
READ of size 11 at 0x60b000122610 thread T0
#0 0x7f9c9c3fe062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
#1 0x7f9c9beb8ee4 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6ee4)
#2 0x56096a7cf75b in smpp_smsc_conf src/libmsc/smpp_smsc.c:983
#3 0x56096a7cf9df in smpp_smsc_start src/libmsc/smpp_smsc.c:1015
#4 0x56096a7d4935 in smpp_openbsc_start src/libmsc/smpp_openbsc.c:785
#5 0x56096a755ad0 in main src/osmo-msc/msc_main.c:598
#6 0x7f9c9927b2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#7 0x56096a756979 in _start (/home/jenkins/workspace/osmo-gsm-tester_run-prod/trial-805/inst/osmo-msc/bin/osmo-msc+0xf0979)
Related: OS#3181
Change-Id: Ifce107dc5f0971d7580b7adc09f05e334792bace
|
|
Default usage values are defined in mgcp node, and can be per-BSC
overriden on each bsc node.
Change-Id: Ibf3932adc07442fb5e9c7a06404853f9d0a20959
|
|
Take both the operative and administrative states into account
when deciding whether to start ACC ramping, and examine old/new
state values to avoid triggering ramping for a no-op state change.
This requires a fix to gsm_trx_lock_rf(): This function overwrote
the old administrative state of a trx before enqueuing a state
change request towards the BTS.
The BTS will confirm this request with an ACK, at which time a
signal is generated which the ACC ramp code listens to. We must
not overwrite the old state value until the signal has been handled,
otherwise the signal handler cannot tell what the old state was.
Tested with a virtphy setup, nanobts, and osmo-bts.
This is a port of osmo-bsc commit cda994edb20d24032d6ab4e916d0e9411671cfc0
Change-Id: I235d2c5fa962f2f338e77d0c11502921b37f4c36
Related: OS#2591
|
|
Starting an ACC ramping process while TRX 0 is unusable or locked is
pointless. For instance, after loading a config with 'rf_locked 1'
for trx 0, the ramping process was started as soon as the BTS
established RSL, even though the air interface was still down.
ACC ramping should instead be triggered once TRX 0 is unlocked.
This is a port of osmo-bsc commit 4d3d2436cdf3296ddc110be4022dc2ec13d3eb86
Related: OS#2591
Change-Id: I2cc9c1b8193546ea04ea5beb3751c2206f0215f2
|
|
Trigger ACC ramping not only when an Administrative State Change
ACK is received from a BTS, but also when an administrative state
change is reported for TRX 0 in a State Changed Event Report.
This should allow ACC ramping to work with any BTS which reports
an administrative state change to 'unlock' using either of these
OML messages.
Tested with a sysmobts and a nanobts.
The sysmobts only reports TRX locked/unlock changes in Administrative
State Change ACKs, not via State Changed Event Reports.
The nanobts is known to send both of these OML messages in quick
succession, so do not re-trigger ramping if it's already in progress.
This is a port of osmo-bsc commit b06c7a253752ecb67fd20cdf0b069688b561af0e
Change-Id: I6443635b822b6cd776f6dc8a6ee73ab09e865b04
Related: OS#2591
|
|
The word 'enabled' was used in two contexts: Whether ACC ramp is
enabled as a feature, and whether a particular access control class
is permantly allowed/disallowed via VTY configuration.
Rename some helper functions to avoid the use of the word 'enabled'
in the latter context.
This is a port of osmo-bsc commit 0ad90b39b9e638b5e3d926c9261d26e777ca478c
Change-Id: Ic1e5a1f969823cfbfb9fe9e959db87c1717c3a83
Related: OS#2591
|
|
Make ACC ramping listen to network management signals and trigger
or abort ACC ramping based on the RF locked state of TRX 0.
This is a port of osmo-bsc commit 60ecdeffecf3db4ad044c5ee0185f384d1b16eb3
Change-Id: I4124f1da3dadec003de45c1da8435506ee8f0a34
|
|
There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
This is a port of osmo-bsc commit ea33341cf7b52d432be98f2280b4a5f3129ef667.
Also remove a call to acc_ramp_init() which should have been removed in
openbsc commit ebc1e39d919f5f919cb176ee9c6cbbccc8d620b1
Change-Id: Iadd25016e6478a9dc5da1db42e6192ce0f5cc746
Related: OS2591
|
|
Silence log messages about no-op changes to access granted to access
control classes. For example, these always occur while configuration
files are being loaded.
This is a port of osmo-bsc commit 53d40e078e9df20103b7ed26daa936720c9dec83
Related: OS#2591
Change-Id: I2f892b998eb8119e623c1d87ffe865b48f7d5a87
|
|
Since libosmocore 7c0031fc8063771e604976233fb7b46d2b85c077, the cmd
param passed to handlers in ctrl_handle_msg is always freed afterwards,
thus it is owned by the same function. Avoid keeping it alive and
accessing it later when it has already been freed.
Related: OS#3157
Change-Id: Ib1e1fb79746d4a4f3e30254fdb7a7e851c2cd0e4
|
|
Change-Id: Ic2e4ca7d8eb4e8f71dc773b3f2c0f09709d90a94
|
|
Change-Id: If0dfae40f03db297eeb4e296daf5fe78ba53a11b
|
|
Change-Id: I105be500399259a97ef711f17b4a51e72dc8cc53
|
|
Change-Id: I146c4a561b0cd62779d60da3b55b96e24438bd89
|
|
Change-Id: I507b0eced7d86f8e978012f6c19f728cd481196b
|
|
Remove a redundant call to acc_ramp_init() during bootstrap_bts().
ACC ramping state is already initialized during VTY config parsing,
and bootstrap_bts() accidentally disabled ACC ramping again even
if it was enabled in the configuration.
This bug was introduced in last-minute refactoring during
review of https://gerrit.osmocom.org/#/c/6324/ when the
acc_ramping_enabled flag was moved from struct gsm_bts to
the acc_ramp structure itself.
Also remove an acc_ramp_init() call in bootstrap_rsl().
It is no longer needed as it serves no purpose other than
initializing the bitmasks of barred ACCs. To ensure that
ACC ramping configuration provided to the BTS via system
information stays correct, we move the call to acc_ramp_start(),
which has the same effect on barred ACCs, further up.
Port of osmo-bsc commit f34fb4828249eab44b4515e0e54b3ee0491d0051
Fixes: 8469818e33ef81e9f707a0c4dd13d7b91ecf83f5
Related: OS#2591
Change-Id: I5834fd953e65b8453dee0a7751d5a4cae12be83a
|
|
In a debug log message, an unsigned 64-bit value was printed with
%lu but it should be printed with PRIu64 from inttypes.h instead.
Port of osmo-bsc commit 5b6aa650f1a6df22ec99797bd3635ea791998a88
https://gerrit.osmocom.org/#/c/7687/
Change-Id: Ia29feec023117734e4f50ae3487871e715821fed
|
|
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
|
|
Since eb241aa1d5720a36cf97f29390c2890cf3aecba7 (year 2010) we are
delaying transmission of paging packets 500ms in order to avoid crashing
the nanobts because of sending too many packets.
In consequence, if 2 BSSMAP PAGING messages arrived in less than 500ms,
since the 1st one was already in the queue, when 2nd one was handled then
paging_request_bts would return -EEXIST (negative value) and
paging_request_stop was called which would remove the paging in the
queue. As a result, the paging would be lost unless a new 3rd BSSMAP PAGING
message would arrive after this second one (which of course could be
again removed by a 4th sent less than 500ms afterwards), and so on.
Furthermore, it doesn't make sense to call stop_paging in here, so the
easy fix is to remove it to avoid the issue mentioned above.
Change-Id: I2605367b2735b48bce2b31504c444360b5ca6953
|
|
Detail better in the API documentation what's the expected return value
for paging_request.
Change-Id: I17fa3b549bff297531b2777d658b0e0112a3031f
|
|
Backport the patches with the following change-ids:
osmo-bsc.git:
I5b097dbb6329f284e3b4914a744d5c3ad628f715
I8e722103344186fde118b26d8353db95a4581daa
I78f30aef7aa224b2e9db54c3a844d8f520b3aee0
I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8
osmo-iuh.git:
I29ebcddd45fe3079f8883589a83cc7216a535475
Also apply change of ipac_bcch_info.cgi to struct osmo_cell_global_id in
src/ipaccess/network_listen.c, a change that appears to not have been necessary
in the new split repositories.
Related: OS#3010
Change-Id: Ibf50fd7e1ca5472d0a38fcb87c68227d6de44f42
|
|
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Port of osmo-bsc commit a5c1e8727c391bc56847a00b2ecc08787573b91f
Change-Id: Idd5c4fd7ea2e10086d9b26deee3a71f9469d1280
Related: OS#2591
|
|
In addition to logging the current values of a BTS's channel load
average and T3122 override, maintain stat items for these values.
This allows for plotting these values over time, for instance.
These values show up in the VTY under 'show stats' like this:
base transceiver station:
Channel load average.: 25 %
T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.: 32 s
Port of osmo-bsc commit 4e9d40db2f86bfbd4d9c8bf9e3d9196f5ddf22c6
Change-Id: I766bd51f539dd96236b9c81d661e9d31f5027db4
|
|
For unconnected BTS, the channel load would report a "bogus channel load
sample" every second (on RLL debug). Instead, skip unusable BTS.
This follows up on commit 6cee893a0f2c4e53155a2631aff12a5f615b973d /
I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
'Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.'
Port of omo-bsc commit f802f7fd7aec1d91084231a80bbce6f2ed7bd299
Change-Id: Icd50d101244641a6ffdde17e60d7a89719225c65
|