So far we only printed it during later modification. Let's print
it also during initial activation of a logical channel.
Change-Id: I6982a52905e4719e2e9c40630252ffef2ff9fbed
When we receive a SID_FIRST_P1 frame from the PHY (during AMR/HR DTXu),
we must generate a SID frame on the RTP side.
The existing code
* ignored that the Amr_SidFirstP1 PHYIF message actually contains the
RTP payload
* manually generated the same content using osmo_amr_rtp_enc()
* forgot to prefix that with the AMR CMR+TOC
* in the end, sent a completely broken (too short) AMR SID frame over RTP
Let's fix this by simply using the 7-byte RTP payload with CMR+TOC that
the PHY is providing to us.
Change-Id: I90479efcc002d497648a71e73847af54e6208358
Related: OS#5944
So far, we've had LOGPLCHAN() and LOGPFN(). This resulted in a number
of log lines containing frame numbers *not* containing the lchan
context, which makes it difficult to deterine which of potentially many
concurrently active lchans is logging.
Let's introduce LOGPLCFN() for a FN-extended version of LOGPLCHAN(),
and convert all callers that have the related context.
Change-Id: I214af0448652a9f321ccbab77977b67663ba28f9
We're printing DEBUG messages for all other DTX frames, but not for
ONSET. This made me think that we never received any ONSET frames
when looking at log output.
Let's add ONSET for completeness.
Related: OS#5944
Change-Id: I9a1511d9929444cef96388492d907e8f3a082311
ph_tch_req() is a recursive function and conditionally calls itself at
the very bottom. The recursive call happens iff all of the following
conditions are met:
* DTXd is enabled,
* AMR codec is in use,
* DTX DL AMR FSM state is recursive.
The problem is that ph_tch_req() may pull sizeof(*lsap) from the given
msgb twice: during the initial and the recursive calls. The second
attempt to pull sizeof(*lsap) causes the process to abort, because
the remaining room is less than it's attempting to pull.
AFAICT, doing msgb_pull() is not really necessary, given that
l1sap_tch_rts_ind() thankfully does set msg->l2h before pushing
the lsap header in front of the actual frame.
Update osmo-bts-sysmo and its copy-pasted siblings, which are likely
affected too, except osmo-bts-octphy which does not do the recursion.
Change-Id: Ib349b74a9e4bd48c902286f872d3b0e9a068256c
Related: OS#5925
This library will be used soon when adding Osmux support to osmo-bts.
Furthermore, it nice to have it available to make use of other general
interfaces to create connections, primitives, RTP and AMR related
functionalities, etc.
Related: SYS#5987
Change-Id: I49db4de715065c083e1249cbeae6298d6868e229
Make them more easy to read and edit by splitting to one element per
line when several elements are present.
Change-Id: I24ecfa1167b806dcb3a5a0c00343299df842a78b
I did not realize with my previous patch that there's a common place
where features available for all backends should be enabled. So move it
there.
Related: SYS#5922, OS#5538
Change-Id: Id688ddae5cd714355fcc5324f33c9397fecae261
According to osmo-bsc I0e80ca5afc06737273b6699bde6e325e454b57f6, the
PAGING_COORDINATION feature should be well supported in osmo-bts. Adjust
the bts_model_init functions to report this to the BSC, so it properly
sets this in SI13 and so we can avoid this notice in the log:
Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ib06829501f4221a7f7b0344ec7991ceba74e7641
Callers of osmo_wqueue_enqueue must always check the return value
and free the message themselves in the error case.
Change-Id: Ic67fbef23e419c0c8a7bcfb16d134e1bf649de72
Related: OS#5329
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
This was colliding with the global "show trx" command introduced a few
years ago, and prevented both command from working.
Change-Id: I57f9515292f7bd906599e2cc277542bfaf3b657b
Related: OS#5080
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
lower layer specific APIs require first to enable the TRX object
(GsmL1_PrimId_MphInitReq, which requires ARFCN received during Set
Radio Carrier Attributes) before enabling the per-TS structure.
Hence, OPSTART must happen in RCARRIER MO before OPSTART can be sent to
the Radio Channel MOs, otherwise the initialization of the TS objet will
fail and OPSTART for the RadioChannel MO will send back a NACK.
In order to avoid this, we need to keep the RadioChannel MO announced as
"Disabled Dependency" until RCARRIER is OPSTARTed.
Related: OS#5157
Change-Id: I8c6e5ff98c32a3cd5006f5e5ed6875bcabb1d85f
New channel mode values have recently been added with change [1]
to 'enum gsm48_chan_mode'. The lack of default branch in
lchan2lch_par() caused build failures on Jenkins:
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V2_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V3_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V5_VAMOS’
not handled in switch [-Werror=switch]
This function is duplicated in osmo-bts-{lc15,oc2g,octphy,sysmo},
so we unfortunately need to apply the same fix to all copy-pasted files.
Change-Id: I557ff8cac6564d22485c101fba9212f5f0e95bb7
Related: [1] Ie0ea592da5610ae70290106d004e549cf3212a89
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
The sapis_for_ho have only one member, so it's silly to iterate. A
subsequent commit will drop sapis_for_ho.
Change-Id: I896fbca9876fd274ff9c426250b18b50faebfa89
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I6ddc04c5815858c7dfab04ffdac52bce2e7940a1
Fixes: OS#4865
The binary is called 'osmo-bts-lc15', while the containing folder
is named 'osmo-bts-litecell15'. This inconsistency complicates
automatic generation of the XML VTY reference - fix it.
Change-Id: I55c073fbd01aee42871101401d76d87e7c91832e
Related: SYS#4937, OS#3036
Harald Welte
Vadim Yanitskiy
arehbein
Pau Espin
Oliver Smith
Eric Wild