Age | Commit message (Collapse) | Author | Files | Lines |
|
Make sure some RSL cause is set.
Change-Id: I372ade9fc58919fbf858ce14caab8a0a22dbb083
|
|
Change-Id: I20a7b160321cf86179cdcece71c8158e76ba4a1b
|
|
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
|
|
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sachh = false did so for no good reason.
Drop the do_deact_sachh flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sachh flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
|
|
In the case where there is a release in error and we skip immediately to the RF
Release state, send all of Deact SACCH, RR Release messages and also signal the
lchan_rtp_fsm as appropriate.
Move that code to static lchan_do_release() and call from both
lchan_fsm_wait_rll_rtp_released_onenter() in the normal case, as well as
lchan_release() when skipping that.
When releasing in error, but we're already in LCHAN_ST_WAIT_RLL_RTP_RELEASED,
those messages have already been sent and we can skip them.
Change-Id: I648a9826ce56b611359f81462ca03e4ab4c736aa
|
|
Change-Id: I8a1542e92373d2773699744e7b64a08667a4b0f5
|
|
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
|
|
When reading the log of OS#3686, I wished for explicit logging of when exactly
an lchan disassociates from a conn. Here is the debug logging I would have
liked to see.
I'm not sure whether we really need to merge this patch...
Change-Id: I97558b899e7f2578ba98287e7352dc072d02ce44
|
|
lchan_fsm_wait_rf_release_ack_onenter() calls gscon_forget_lchan(). At the
point where the conn has no lchan, the lchan must not have a conn. Make sure
that conn is NULL after gscon_forget_lchan().
I hope this fixes OS#3686, it is the only situation I could find where the
disassociation is potentially one-sided.
I get the feeling that this should be hardcoded in gscon_forget_lchan(), but I
dimly remember other situations that are less trivial, where it doesn't
necessarily make sense to forget reciprocically. So only fixing this one now.
Related: OS#3686
Change-Id: If0c6e495e419b9dbb44443c3fc3f54dd4b714aa5
|
|
Right below this call, we invoke lchan_reset(), and the first thing it does is
gscon_forget_lchan(). Drop this redundant invocation.
Change-Id: I503efceb6d34c8df0cdfef3dfc83fa1e61271c47
|
|
See following specs for related information:
* 3GPP TS 52.021 §8.11.3 Get Attribute Response
* 3GPP TS 52.021 §9.4.64 Get Attribute Response Info
Related: OS#3624
Change-Id: Ie61d70bc28427d5d879638516a36f590ce98bdc7
|
|
Spec compliant format is defined in:
* 3GPP TS 52.021 §8.11.3 "Get Attribute Response"
* 3GPP TS 52.021 §9.4.64 "Get Attribute Response Info".
On nanoBTS, however, reported attribute list is provided directly inside/after
the foh header instead of being enveloped inside the Get Attributes Response Info.
Furthermore, The Get Attributes Response Info can still appear and be at any position
in the reported attribute list, and it only contains the unreported
attribute ID list inside.
Change-Id: I81a613d53bddf432a79fa5cb0bf9d847b4bdee37
|
|
Change-Id: Ia05e0b8fe3e28aaf2b2253d018f0614e83e23caa
|
|
nanoBTS actually supports regular formatting. There are a few differences
with spec though:
* The attributes are listed directly in the message instead of being inside
the Get Attributes Response Info after the unsupported attribute ID list.
* The Get Attributes Response Info can be at any position in the
attribute list, and it only contains the unsupported attribute ID list.
As a result, parsing is currently split into 3 main parts or functions:
* Parsing regular (per spec) Get Attributes Response Info attr and get a
pointer to the list of attributes.
* A function that parses the list of attributes, called directly in case
of nanoBTS, and called by the former parser of Get Attributes Response
Info for regular (per spec) OML endpoints.
* A function to parse the unsupported attribute ID list, also used in the
first function to get a pointer to the list of attributes.
Related: OS#3624
Change-Id: I52e9f177c14fec1ec3f5c4ddb244594409008357
|
|
* Allow sending Get Attributes message in abis_nm_get_attr.
* Don't try to decode Get Attribute Response Info for nanoBTS, since it
uses a different formatting than the one defined in specs.
Related: OS#3624
Change-Id: I53d01e73791cf5450aa34b1ac8f051730e3a70f9
|
|
its own func
nanoBTS uses same format for the attribute list from Attribute Response
Info, but without using the later as an evelope. By splitting we can
later reuse the code handling the Attribute list.
While at it, take the chance to remove functions parse_attr_resp_info_*
which expect TLVs following an specific order, which is not mandatory.
Related: OS#3624
Change-Id: Iec7a6e4d27639d0e5adc0d9a01cd3c3e7a46f558
|
|
In future commits, nanoBTS support will be added, which implements its
own format not exactly equal to specs Attribute Response Info.
Related: OS#3624
Change-Id: I346dacc58faac70e6d224ca49484f9211cb8a046
|
|
This function will be merged into another using a "len" variable. This
change makes diffs easier to follow in future patches.
Change-Id: I1be03e31901ccf284e31237a04bb7448d1f22c07
|
|
The function cgi_for_msc() provides an easy way to get a cell global id
for an msc/bts combination. This function is currently statically
defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly
available.
Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d
Related: OS#3645
|
|
Coverity points out that conditional checks in set_net_timezone()
depend on each other: The value of 'override' depends on 'hourstr'
being non-NULL. Nest these conditional checks such that this
dependency becomes obvious.
No functional change.
Change-Id: I10dece1e1d9e039fb9f03be89b3a202cb077b026
Related: CID#148208
|
|
Change-Id: I56b57936ae82984e84896228da5a83115a78bbd7
Related: OS#3659
|
|
Change-Id: Ib34c8e3fb51d067581aefa1c80f8be1f6db9512e
|
|
Change-Id: I4bc157bf296e28678de6d9c9823f91810132a58c
|
|
Move code using MDCX via MGCP into separate function to make adding
alternative MDCX variants easier.
Change-Id: I5fafa3b12a39c83bdf64e16e192dd2454d069cf4
Related: OS#3659
|
|
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
|
|
Change-Id: I3a708c3ba2271d9968daa264736411c9326fc404
|
|
In 'show bts' command only display details of GPRS MO if GPRS is
configured for this BTS.
Change-Id: I082a9fecfa337dff5342b79cca8144b0ceaab15d
|
|
Fixes: coverity scan CID#189459
Change-Id: Ib9c5e374b9c5c8f79eecf95c439a25b0f438e4e5
|
|
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
|
|
The commit acd29192deed0e1a243b35278b030bde7b1662b5
Change-Id Ifb9212fede2333ad68db94188b5cda4fcabe02f8
introduced a bad change to neighbor_ident.vty. Revert that bit.
Change-Id: I8b80be6daef73f5864ba9f294bf2134c8a76ddb5
|
|
The chan mode is figured out per-BTS, but may remain uninitialized. Rather log
info about the channel request, like further above.
Change-Id: I07b89b6101879fb7c070c87be9bd38cc05ffa0b1
|
|
Change-Id: I41c04cfedaae4da69a2bc7d50b1f7fe0e467e0fa
|
|
Separate the cause value passed to further functions from the log string.
The code tried to be nice by composing the RSL cause string and returning the
RSL cause at the same time, which falls on its face when the string composition
happens only within conditional logging.
Change-Id: Ibadd06102f162bca9182c39b77b0651568d3e6f8
|
|
bssmap_handle_cipher_mode() had code paths doing "goto reject" without
setting a meaningful cause value.
Related: OS#3186
Change-Id: Ia608fa34a6a2d3035a66d05fbc38553ac5186804
|
|
Change-Id: I359caf1dd30f033c0b606040ccf27aa4c5a9d2c6
|
|
During the generation of the multirate configuration IE in the channel
activation message that is sent over RSL, all AMR rates except the
highest one are trimmed. This was to ensure that the multirate
configuration IE only contains one codec rate per active set. Lets fix
that and generate a proper IE with threshold and hysteresis values.
- extend lchan_mr_config so that it can generate a full multirate
configuration IE
Change-Id: I7f9f8e8d9e2724cbe3ce2f3599bc0e5185fd8453
Related: OS#3529
|
|
The vty already has a well working interface to configure the AMR
mode, threshold and hysteresis parameters. However there are no checks
yet to prevent against misconfiguration.
- Use gsm48_multirate_config() to perform a global check of the overall
configuration
- Add check AMR modes during input (order, duplicates)
Change-Id: I8b9f69b89a39bbf4800d9790f7abe43ce66aeb71
Related: OS#3529
|
|
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
|
|
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
|
|
The function gsm_bts_alloc() does set default values for the amr rates
for a newly allocated bts, but it does not populate the ms_mode and
bts_mode flags which contain hysteresis and threshold. Those values are
currently set to 0 by default, which does not make much sense. Lets
popluate some appropriate default values.
- Make sure that .mode .hysteresis and .threshold are populated for
MS and BTS in full and halfrate
Change-Id: If14843feeeea6584e5991d5c0abb765611dfaa57
Related: OS#3529
|
|
Implement basic support for inter-BSC HO from handover_decision_2: do inter-BSC
handover only when rxlev / rxqual / ta drop below the minimum requirements.
I considered adding a vty config flag to disable/enable remote-BSS handover,
but to avoid inter-BSC HO the user can simply refrain from configuring
neighbors for a particular cell.
In collect_assignment_candidate(), it is important to clear out any new
candidate entry. Hence adopt the same pattern as below: first compose a new
(cleared) candidate, then write the entry into the list.
Related: OS#3638
Change-Id: Id78ac1b2016998a2931a23d62ec7a3f37bb764c6
|
|
a) Prepare for triggering handover for any candidate, remote or local.
b) drop redundant arguments.
Change-Id: I5ba8b556703010c8e232b516285a837c999f87ef
|
|
Change-Id: I56ec149979572486b904fc1409cf3cd096b6eb34
Fixes: Coverity CID#188867
|
|
Change-Id: I653ae9ede578370b4d7b1a150e9ec3c0702bbb31
Fixes: Coverity CID#188862
|
|
Change-Id: Id0eca3dd729d2e4c8c6ff83f05efde00b42c16f1
Fixes: Coverity CID#188860
|
|
We can only send a reject response if we have a valid conn.
Change-Id: I0ea535f494173ad4996c70dc82d7f69455e4e15e
Fixes: Coverity CID#188824
|
|
open() returning 0 is valid, but negative values indicate errors.
Change-Id: Id7e62116bfee550ef9906e78a0fce6f28af27a97
Fixes: Coverity CID#57865
|
|
When COMPLETE LAYER 3 INFORMATION is generated, it may include a speech
codec list that contains 0 elements (which is legal). The specification
requires the speech to be include if the network supports an IP based
user plane interface. It could be argumented that if no codecs are
available, the ip based user plane interface is not supported and
therefore the spec does not require the speech codec list IE to be
included for those cases. Lets check if the speech codec list has 0
elements and if its zero length, lets omit it completely.
- check for zero length speech codec list.
- omit speech codec list if it has zero elements
Change-Id: I07339322a71376e986a2d75b7bc1f552eafd02b5
Related: OS#3657
|
|
This only afffects a log statement, so not really an issue.
Change-Id: I8e5b164194855f78a266c1a4441730cc6c378d11
Fixes: Coverity CID#188829
|
|
Change-Id: I5bbb10af8b8e8ebc22bf79f5468e71a41b5e74b3
Fixes: Coverity CID#182710
|