Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which
tells an MS requesting a channel to wait for a specified amount of
time before trying to request a channel again, i.e. the wait indicator
controls the T3122 timeout value in the MS.
Previously, the wait indicator was fixed to 10 seconds.
This is not sufficient if there are a lot of MS requesting channels
because the MS will retry too soon. Instead of using a fixed value,
maintain a dynamic wait indicator value based on average channel load.
The load (used vs. available channels on a BTS) is sampled once per
second, and once 8 samples have been collected we update a BTS-specific
T3122 wait indicator based on the measured load.
While the wait indicator could go up to 255 seconds, this initial
implementation keeps it in the range from 10 to 128 seconds.
Further experimentation and testing will show whether higher wait
indicator values are desirable, if the sampling rate needs to change,
or if the function mapping the load measurement to a wait indicator
value should change (currently we map the load average linearly into
the range [10, 128] inclusive).
Port of osmo-bsc commit 6cee893a0f2c4e53155a2631aff12a5f615b973d
Change-Id: Id9df0e790ece8108212b2ddf718cf2953f5b9bd4
Related: OS#2592
|
|
Fixes a regression in the code generating SI5* and SI6 on SACCH,
where the L2 pseudo-length is not part of the 'struct' definition
we have in gsm_04_08.h and hence has to be encoded manually into
the first byte of the SI buffer.
We were doing this correctly until April 2017, when the following
patch was merged:
> commit 6f0e50c8337355eb59033903ede9ab6528890835
> Author: Max <msuraev@sysmocom.de>
> Date: Wed Apr 12 15:30:54 2017 +0200
>
> Prepare for extended SI2quater support
This patch cacidentially overwrote the l2_plen that was just enoded,
as the 'struct' was no longer pointing to 'output' (si_buf+1), but
now directly to the start of the si_buf.
NOTE: The Wireshark RSL dissector (and more recently also LAPDm)
contain a similar bug, so the SACCH will not be decoded correctly
after applying this patch. Nevertheless, it's correct.
back-port of OsmoBSC Change-Id: Ie8c907b1317566670aeb68f933ceefd552c17565
Closes: #3059
Related: #2963
Change-Id: Iaf5feefc1bb3194dd491955fee418795c61787f7
|
|
After recent libosmocore commit "implement support for 3-digit MNC with leading
zeros" c4fce1425e19d604c199c895e227dc2519110456
Id2240f7f518494c9df6c8bda52c0d5092f90f221, struct gprs_ra_id has a new member,
namely mnc_3_digits. In gprs_ra_id_by_bts(), this new member is now not
initialized and may end up having an arbitrary value, which then may amount to
mnc_3_digits == true. Hence the resulting BCD representation of the MCC-MNC may
inadvertently and randomly indicate a leading zero on the MNC.
Use a struct assignment so that all members are guaranteed to be set, and so
that mnc_3_digits will be zero in all cases.
Since above libosmocore commit, nanobts_omlattr_test fails "randomly", fixed by
this patch.
Change-Id: I5ae899f3c236b3b4feb5c8cf762e2f2d964dbc65
|
|
Otherwise we get Osmux stats during a session using RTP, which is
confusing.
Change-Id: I814b2051edc85ad5cbd04c96b785c208f6606683
|
|
There is no any significant reason to define static function
'send_own_number' after the code that calls it.
Change-Id: I8d804398cfa460eaa5a5f84f0ed90909488d0bdd
|
|
This change adds support for both comp128v2 and comp128v3 GSM
A3/A8 algorithms. Since they already implemented in libosmocore,
the corresponding it's API is used.
Change-Id: Ic761be0220397d100c9e6345d4d01af4889dc7c1
|
|
Apparently, since libdbi 0.9.0 aka 0.9.0-5 on debian-testing, osmo-msc barfs
numerous libdbi warnings whenever a query rightfully returns no rows.
Trivially query whether there are any rows first by adding an inline wrap
function next_row().
Silenced:
DDB <000d> ../../../../src/osmo-msc/src/libmsc/db.c:188 DBI: -6: An invalid or out-of-range index was passed to l
DDB <000d> ../../../src/libosmocore/src/backtrace.c:47 backtrace() returned 11 addresses
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xfb81) [0x555555563b81]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/lib/x86_64-linux-gnu/libdbi.so.1(_error_handle
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/lib/x86_64-linux-gnu/libdbi.so.1(dbi_result_ne
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x11172) [0x555555565172]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1e6bc) [0x5555555726bc]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1e7f6) [0x5555555727f6]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1f1d2) [0x5555555731d2]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xbb86) [0x55555555fb86]
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0
DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xbfba) [0x55555555ffba]
Related: OS#2737 OS#2667
Change-Id: I43cf4eed22425554826d59857eded5b4cc0d2c52
|
|
In state prior to this patch, "3G Early Classmark Sending Restriction"
bit in SI3 rest octets was always set to H, which is a sane default as
the policy to send the information is then controlled by "Early
Classmark Sending Control" bit in the same octet.
However, it seems Quortus SoftCore can have some issues decoding the
option, so let's add a vty cmd to be able to disable it for those
having any issues.
Related: SYS#4021
Change-Id: Ic1afe071038a3bb5871d7ff40f665c8644f801ec
|
|
Change-Id: Ic0981fca96f4927717ca335be1dab00a5d17fd6c
|
|
In osmo-bsc-sccplite we so far didn't implement the inbound RESET
procedure. We instead ignored any RESET message from the MSC. This
commit adds support for RESET: We will destrpy any SCCP connections
and acknowledge the RESET to the MSC.
As osmo-msc is requiring the BSC to handle an inbound RESET procedure,
this commit allows osmo-msc to properly initialize the A interface
towards osmo-bsc-sccplite via a translating/routing osmo-stp. While
we don't anticipate any new deployments of osmo-bsc-sccplite, making
it interoperate with osmo-msc enables us to do more testing of
osmo-bsc-sccplite.
Change-Id: Iceb8278deb36d6103662a704f489ba0d685e04d3
|
|
When we receive unimplemented/unhandled message types, we shouldn't
simply silently discard them, but print a log message for the
benefit of the user.
Change-Id: I8ecb1d2134f9c6a96f29e145fa0430880e971168
|
|
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I4951982fc78ae167d8e16a672d7af44d703721a9
|
|
This is to avoid naming conflicts with the new osmo-bsc, which resides
in its own git repository (osmo-bsc.git) and which uses libosmo-sigtran
and implements (primarily) 3GPP AoIP.
Change-Id: If10d1599b62d010726336134091a4e855c380d93
|
|
The GPRS related programs osmo-sgsn, osmo-gtphub and osmo-gbproxy
have been split off into the separate osmo-sgsn repository, which
can be found at
git://git.osmocom.org/osmo-sgsn.git
http://git.osmocom.org/osmo-sgsn/
This is technically unrelated but conceptually part of the larger
NITB-split activities.
I did a brief log of all changes in src/gprs and couldn't find any
commits that we might have applied here but which are missing from
osmo-sgsn.git.
Change-Id: If60e28b23f5cfb2c4eb354951363a2bb63f3e0de
|
|
The library code for rate counter initialization, which is called
from the descendants of bsc_network_alloc() might already want to
log something (particularly after Change-Id
Ifc6ac824f5dae9a848bb4a5d067c64a69eb40b56 in libosmocore), so the
logging framework must be initialized before.
Change-Id: I1e893c97e023e63489fe8c46539b5e507d3cec8f
|
|
* log administrative state transitions
* log what's caused it
* while at it, mark boolean variable as such
Cherry-picked from osmo-bsc be356ed32fbd28dc8d1460371d9e47511b20ac63
Change-Id: I3e25a19fac4d0b4886d825c9876771b1f66efe58
Related: SYS#3864
|
|
unsigned long can be 32 bits on some arch/OS, while "current" field is
always 64 bit because it's a uint64_t.
Change-Id: I9719c69ef661bb46d8bb43cf8d6537c3e8d47826
|
|
Related: OW#3893
Program terminated with signal SIGSEGV, Segmentation fault.
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
(gdb) bt
0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342
1 0x0805ab80 in lchan_release (lchan=0x0, sacch_deact=sacch_deact@entry=0, mode=mode@entry=RSL_REL_LOCAL_END)
at chan_alloc.c:410
2 0x0805c1dd in handle_ass_fail (msg=0x94142b8, conn=0x9251048) at bsc_api.c:459
3 dispatch_dtap (msg=0x94142b8, link_id=0 '\000', conn=0x9251048) at bsc_api.c:598
4 gsm0408_rcvmsg (msg=msg@entry=0x94142b8, link_id=0 '\000') at bsc_api.c:658
5 0x08058ca2 in abis_rsl_rx_rll (msg=0x94142b8) at abis_rsl.c:1686
6 abis_rsl_rcvmsg (msg=0x94142b8) at abis_rsl.c:2097
7 0xb7e8cf9a in handle_ts1_read (bfd=0x94e8e08) at input/ipaccess.c:271
8 ipaccess_fd_cb (bfd=0x94e8e08, what=1) at input/ipaccess.c:386
9 0xb7ee8434 in osmo_select_main (polling=polling@entry=0) at select.c:158
10 0x0804bd7c in main (argc=6, argv=0xbfc27144) at osmo_bsc_main.c:272
(gdb) print lchan
$2 = (const struct gsm_lchan *) 0x0
Possible scenario in which this crash can appear:
1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN
ACTIVATE msg and arms T10 timer.
2- ACTIVATE ACK is received (handle_chan_ack), which calls
gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't
disable/modify T10 timer.
3- T10 timeout is triggered (assignment_t10_timeout()), which sets
conn->secondary_lchan = NULL
4- Immediately after, the ASSIGNMENT FAILURE message (which might have been
already queued) is processed in handle_ass_fail, and then the crash occurs.
This race condition is not an issue for handle_ass_compl() path because there's
this check there which would trigger most probably if secondary_lchan is NULL:
"if (conn->secondary_lchan != msg->lchan)"
Change-Id: Ied5bd90b9c06f27135a2e3c46e40d49d27d9a387
|
|
In masurement reports sent by the MS, this can then be used to correlate
if a given measurement report was in response to a BCCH/neighbor list
received on BCCH (SI2xxx) or on dowlink SACCH (SI5xxx).
Closes: OS#2525
Change-Id: I1cd0dc51026dcd0e508e63eea4e333e6b184787a
|
|
Change-Id: I5afc6e6a5a1d6b6a8ee73fdb60cc28074cf8585b
|
|
Save the time when OML link to BTS was established and show it in
vty. That's useful when troubleshooting issues like periodic/sporadic
BTS restart.
Related: SYS#3889
Change-Id: I9e4e8504afe8ca467b68d41826f61654e24d9600
|
|
Remove trivial functions by using more specific defines for CTRL
commands.
Change-Id: I719b75b6ca1e9372ea11e7e9ff7896021f357035
|
|
This patch just makes the log match chronologically what
is happening. We receive the deliver_sm_resp before we send
the RP ACK to the MS.
Change-Id: I29270652957f58093be8bf7f2e898b0b4933bd93
|
|
If smpp_first is set off and there is a local receiver for this sms,
then return 0. Without this patch, we return 'rc' which is uninitialized
in the scenario that I'm describing above.
Change-Id: I0c0bcd919cc3275d491995d17c6a32bb61c6afe1
|
|
Fix four instances of VTY tests working because it used to include implicit
'exit' commands to the parent node.
Since libosmocore change-id Id73cba2dd34676bad8a130e9c45e67a272f19588 = commit
d64b6aed235f6e4d84a2cb8e84b32c3179260254, we no longer do this implicit-exit in
interactive VTY shells.
*) the nitb node lacked the default command set (including 'end' and 'exit'),
so it was impossible to leave the nitb node. This hit in
testSubscriberCreateDelete. Add vty_install_default(NITB_NODE).
*) in testPingPongConfiguration, the intention is to enter the /msc 0 node.
Drop prior entry of the 'network' node, which looks like an oversight. So
far the 'msc 0' caused an implicit 'exit' and thus worked, now fails.
*) Two instances following comments "# Check searching for outer node's
commands", which look like they are intended to check for this implicit-exit
behavior. This is obsolete, drop those parts of the tests.
Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab
|
|
Annotate this esme route, so we can use it to return -EINPROGRESS to
skip sending premature RP-ACK to the mobile station, in case we're
handling sms routes through SMPP.
Now that we have this information in place, we use it wherever possible
to avoid kludgy checks on sms->receiver.
sms_free() already releases references to this object, so we should be
fine with this.
Fixes: 4e5b90a594f9 ("libmsc: remove 'deferred' parameter in sms_route_mt_sms()")
Change-Id: Ib8a8fd9bbb0d3b6aff7931e4bacbea99d000e484
|
|
Handover attempt for power budget case should be performed every N SACCH frames,
where N = Power Budget Interval.
First measurement report with mr->nr = 0 was used for the first handover attempt
in this case, which is not correct, because first usable report should have
mr->nr = net->handover.pwr_interval-1.
Moreover using the first measurement report with mr->nr = 0 for handover attempt
could lead to unnecessary handover, because usually av_rxlev for first measurement report
from MS is worse than for following reports.
Change-Id: If7f54a4cb179eaa9e5eb147b9477633ac618e69e
|
|
According to 3GPP TS 44.018 §1.8 the "network shall never enable PBCCH
and PCCCH".
Change-Id: I319e71a4b0c682361529e9c21377398a826b934b
Related: OS#2400
|
|
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the NITB on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: Iea6804325a6575ceab5edfd28dd20249462f143b
|
|
This option was present in very early versions of the NITB, but
at least since 2011 it is no longer supported. It's still listed
in --help output, which is wrong.
Change-Id: I1d2cceb588ec5fb34ec5e2c05a7d8c93310bee88
|
|
Set the time on the status report to the time the message was delivered, as
this may not be the same as the time when we are delivering the report to the
originating MS.
Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
|
|
Change-Id: I6ed923f5c60a8d64305f4b8e90d1362d6510e1c5
|
|
Change-Id: Ibe3c8bd353b3a178e26b0936f25b2e1959f9990c
|
|
libsmpp34 already converts received TLV integer values to native
endianess in libsmpp34_(un)pack.
Converting them again at receive time swaps the 2 bytes of
user_message_reference, then using a wrong value. As GSM03.40 spec
uses only 1 byte for the id, then only the high byte of the initial
value is used and eventually sent back to the ESME. Again, at that time,
htons() is not needed because libsmpp34 already handles that part.
See OS-#2429 for more details.
Change-Id: If748548a4a223e529a1110c89e483b599b406e8b
|
|
I already stumbled into 2 compilation environments which had Werror
enabled for -Wmaybe-uninitialized and the build failed, so let's
workaround this warning.
| smpp_openbsc.c: In function 'handle_smpp_submit':
| smpp_openbsc.c:216:9: error: 'sms_msg_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
| memcpy(sms->user_data, sms_msg, sms_msg_len);
| ^
| smpp_openbsc.c:100:15: note: 'sms_msg_len' was declared here
| unsigned int sms_msg_len;
| ^
| cc1: some warnings being treated as errors
Change-Id: I0901ddadb5f72e1585cb1797ac22c8ab95e83146
|
|
gsm_04_11.c sms_report_alloc()
Use the sms->text, not the sms->user_data to construct the report body.
This also prevents the potential output of non printable characters to
the log and or vty.
Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
|
|
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu()
When we construct the status report PDU, use sms->src
instead of sms->dst as the destination address
This way we tell the MS that the message was delivered
to the destination and not to itself.
This is relevant for phones that display a textual
representation of the delivery report.
Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
|
|
Use new definitions in libsmpp34 to set the registered_delivery field
accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c.
Moreover, do not set this header field to zero if status reports are
off, the deliver_t structure has been already zeroed so this not
required.
Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
|
|
In 2015, Jacob moved/copied related functions to libosmocore, but
for some reason didn't remove the copies here. Let's follow-up on
that and remove duplicated code.
The libosmocore commit introducing osmo_apn_to_str() was
8114294bf29ac6e44822c0ae43d4b0819f11b022
Change-Id: I7315ffcbed8a54cca2056f313bb7783ad82d0ee9
|
|
We can only print libgtp pdp information if a library context is
attached to this pdp context. This is not always the case,
particuarly during some teardown scenarios.
Change-Id: Ia3184877f9709db65f5f93a98403f2ef5b04a8ca
|
|
When converting from GSM_PCHAN_PDCH, we should generate
a RSL channel number IE with the osmocom extension
RSL_CHAN_OSMO_PDCH rather than claiming it is a regular
TCH/F channel.
This is important as this function is used by
osmo-bts, too - and it decides which channel number IE is
put in the GSMTAP header for both GSMTAP tracing as well
as the GSMTAP based osmo-bts-virtual.
In order to avoid any unintended effect on libbsc,
we make sure to modify rsl_ipacc_pdch_activate() to
always use GSM_PCHAN_TCH_F in related RSL message.
Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
|
|
In the PDP Context Create from SGSN to GGSN, we include information
about the RAN type (GERAN/UTRAN) and the Cell of the MS. This was
all hard-coded to GERAN, and wasn't updated when we added UTRAN
support to the SGSN.
Change-Id: I6c79e42c5e08b28fe8182555302a5505fbbaa313
|
|
Commit 575420637981828b64c1292ada015d7170b89390 introduced
OSMUX_STATE_NEGOTIATING to fix a race condition present in osmo-bsc_nat.
However, after this change osmo-bsc_mgcp cannot switch to
OSMUX_STATE_ACTIVATING anymore, which means during osmux_send_dummy time
it won't call osmux_enable_endpoint(), which in turn won't set endp type
to MGCP_OSMUX_BSC.
If MGCP_OSMUX_BSC is not set, uplink streams are sent using regular RTP
instead of Osmux not matter it is enabled in config or not.
Change-Id: Ibcb59aa1ca25408f82cc88c2d5b81177b5f276dc
|
|
moving this connection to another bts
In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another,
so connection link to bts should be replaced by link to bts, which owns new_lchan.
This bug was detected, because conn->bts->nr is used in call control log messages
and wrong number of bts was observed in these messages after handover.
Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
|
|
Change-Id: Icb1e7cb15fe04642578f5292124ebc1eac9c9aa3
|
|
Fixes regression probably introduced in c696cc28.
For bts>0 logging doesn't show bts number correctly when printing lchan
identification string - it will always show it as "bts=0". The reason for
this is that the identification string is cached before bts->nr value is
set to a proper value.
This patch sets bts->nr as part of the first step of the bts structure
initialization, before caching happens thus making sure the cached
identification string is cached with the correct values.
Change-Id: I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
|