Age | Commit message (Collapse) | Author | Files | Lines |
|
There are some vital configuration bits such as ARFCN, BSIC, channel
config, .. for which there are no reasonable defaults. As a result,
the BSC must set those attributes before issuing OPSTART.
Prior to this patch we would blindly accept OPSTART and then transmit
on ARFCN 0, which is definitely not the intended behavior.
Closes: OS#3789
Change-Id: I3a818f8eceb6abef1b20d2b3892a749dbc9e4b05
|
|
For some strange historical reason, the baseband transceiver MO was
brought up in state "UNLOCKED".
The object should come up in "locked" state until it's explicitly
unlocked by the BSC.
See Section 6.8.2 of TS 12.21: "If there is yet no administrative state
value explicitly set by the BSC (e.g., at an initialization time), the
object shall be presumed to be administratively locked by default"
Change-Id: Id505594b9f224567566caac84dae2e2ae4477fae
Closes: OS#3790
|
|
For the TS 12.21 standard OML attributes, we store a copy of the
most-recently set value for each attribute in "mo->nm_attr". This
somehow was missed when adding support for the IPA specific MOs like
those relevant for GPRS.
Change-Id: I75ebda46da9c1fcecc484311bf3833f31c536ee1
|
|
Change-Id: Id2b16b9acd15d0c80085fac0fdc2a57173ebb0a0
|
|
Change-Id: I4d0a476f84bc9e92e02f94c3990daddeeaa3c5d5
|
|
Change-Id: I6738adb6b0ae50905351c67c259d7a77cb250624
|
|
Similar fix was done for lc15 in a8041edb.
Change-Id: Idcd9dc48ea2e1f80bfdf5cf8b6bf55d8150fe0d2
|
|
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Similar to commit fixing same issue in lc15 in 080302f8.
Change-Id: Ie393a21bc3a725520343c70941cb4f591b313420
|
|
Remove unused variables, wrong return type values, etc.
Change-Id: I5565b904c72a9ac1775818416f05c64722d366b2
|
|
it's used in oc2g/main.c and it needs to be in a header file.
Similar as previously done for lc15 in 19795c5a.
Change-Id: Ic6826d8c8ff5c648158493454a80704bb956b51d
|
|
Change-Id: Ib27b31825744ea397b5b4eb258da78f5f834895c
|
|
Change-Id: I9112d9fd527cdc29d89868df40c6845a751c4865
|
|
When the ph-data indications for the PDTCH are passed up to l1sap,
then a forumla is used to calculate the frame number of the beginning of
the block that is just passed up. This is not necessary since the start
frame number of the block is stored in *first_fn when the block arrives.
We should use this frame number instead. (For the measurement indication
it is already done this way).
Change-Id: I6c01987be78203acfa689c6decb2c806f8fff3d6
Related: OS#2977
|
|
Change-Id: Iadb464e7040dd11e4a8cabfc96d6d90f32594109
|
|
Attempt to decode incoming RACH burst as 11-bit first
and fallback to 8-bit if unsuccessful.
Change-Id: Ia28741603636406744e5e22ffff1fb7a9689955a
Related: OS#1854
|
|
OsmoBSC used to have a bug in encoding the "GET ATTRIBUTES" OML message,
resulting in the actual message length being three bytes longer than the
encoded length value.
As in Ib98f0d7c2cff9172714ed18667c02564540d65d7 we have introduced
proper consistency checks on length values, all "GET ATTRIBUTES" from
OsmoBSC version suntil today will fail. This patch introduces a
work-around to remain compatible with old OsmoBSC while still keeping
the consistency checks for all other messages.
Change-Id: Ifa24e9e2c71feb2c597557807d675438c2825b2d
Related: OS#3799
|
|
For OML, what matters is the length indicated in the OML message header.
If we don't have sufficient bytes, reject the message and send a failure
event report.
If we have more bytes, truncate the message at the number of bytes
indicated in the OML length header.
Change-Id: Ib98f0d7c2cff9172714ed18667c02564540d65d7
|
|
TS 12.21 describes segmenting of OML messages using placement
fist/middle/last and the "sequence' number of the OML header. We don't
implement this and hence must ignore or reject any related messages.
Before this patch however, we simply treated such segments as if they
were a complete OML message. Let's fix that.
Change-Id: Idd42cf4edc1bf9ab366853bd9b0f7afd9c060910
Closes: OS#3795
|
|
Try to constrain the code a bit further by making all read-only
accesses use 'const *'.
Change-Id: I5a61e6d1b4e5e083bb24017166186dc87d035cd0
|
|
Change-Id: I65b57d3fc714814db3ae3fd34398f307413fece8
|
|
Simply use a "mo" variable on the stack rather than having duplicate
but otherwise identical calls to oml_tx_failure_event_rep()
Change-Id: Ibe6c79e95405b13d041047549d2ffa39aa355eb2
|
|
Change-Id: I5b19b82a4874617c7c584cf3eac55eb9c756710a
|
|
When we send an OML failure event report using
oml_tx_failure_event_rep(), the function itself will not only send
the report to the BSC but also log it. So there's no need to both
have an explicit LOGP() and a call to oml_tx_failure_event_rep().
Change-Id: Ib3fd06b3266d896aebeed4ebe42ac71ff173bb5c
|
|
In Change-Id Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e we introduced
several additional calls to oml_tx_failure_event_rep() during OML
messaeg processing. However, for some reason, we *overwrite* the
bts_nt/trx_nr/ts_nr of the TRX MO. This is clearly wrong. The
"address" of a managed object doesn't change at runtime!
Change-Id: Idfb80ccd6dd485d52dc006867fae3dde3fb005f3
|
|
When osmo-bts connects to the BSC, it sends a ton of "State Change Event
Report" messages indicating the Operational State (NULL), Availability
status (power off) and [as an osmocom extension] also the Administrative
State. However, the value of the administrative state is "0", which is
not defined in TS 12.21 Section 9.4.4
Change-Id: I03f8a4b08b266cd40036076c76f9dc7e8bf08da2
Closes: OS#3785
|
|
As per 3GPP TS 12.21 Section 8.2 "ACK messages shall return all the
attributes in the original message". OsmoBTS fails to do so but simply
sends no attributes at all in the ACK.
TS 12.21 is a bit vague whether or not the attributes shall also be
achoed in the NACK. Let's do it and append the CAUSE in this case.
Closes: OS#3788
Change-Id: Ifb305fe75f8305bb04872f26492b8b1bb8c27f49
|
|
Change-Id: I5f30f6c556968fab60283ff1948966af28dc6e83
|
|
Commit acefd0586e5d463b2e7a6a039131994bc12573fc introduced the "toa256"
resolution change.
Before the change, _sched_compose_ph_data_ind() used quarter-bits as
units, so multiplying the old "toa" value by four made sense.
However, after said change, the value is in 1/256th of bits, and hence
we need to report the toa256 value without any multiply-by-four.
Change-Id: I9f980236ea1cd635cb229290e187747cc8c86d8d
Related: OS#2977
|
|
A comma is needed to separate a command definition from its
description, not the parts of description. Let's fix this.
Before this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no PHY Instance number
OsmoBTS(phy)# no ?
instance
osmotrx OsmoTRX Transceiver configuration
After this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no Negate a command or set its defaults
OsmoBTS(phy)# no ?
instance Select a PHY instance to remove
osmotrx OsmoTRX Transceiver configuration
Change-Id: If10d85abc6506118ba08c37e8101f423d6f838ea
|
|
Use the 'else' construct where applicable to avoid too many return paths
from functions
Change-Id: I819f0c80e90855e8b3252795c837f8e3053b6e87
Related: OS#1622, OS#1851
|
|
The loops.c code dates back to ancient times when we printed the TRX
number and the raw channel number to identify a logical channel. We
meanwhile have gsm_lchan_name() and should use it to log messages
related to this lchan in a common format.
This commit introduces the LOGPLCHAN() helper macro [similar to
osmo-bsc], and uses it from loops.c.
As a result, some functions don't need a chan_nr argument anymore,
while some need to add a new lchan argument.
Change-Id: I6976dd7444c26b1f52741bc367b0311ebbef1718
Related: OS#1622, OS#1851
|
|
The concept of a return value only makes sense if there's actually ever
something non-constant to return, and if the caller actually processes
that return value. If we always "return 0" and ignore it on the caller
side, functions should be of "void" type.
Change-Id: I3575a2cef75f3fd4c3f95eddb40719d28a055b54
Related: OS#1622, OS#1851
|
|
The loops.c code is not very easily understood, so let's add some
comments to it.
As can be seen, there are functions of integer type which always return
0, and whose callers don't check for the return value. This will be
adressed in subsequent patches.
Change-Id: Iafea07eb751ed85d29b214576bb0d31ea919cd72
Related: OS#1622, OS#1851
|
|
Fix recent commit which broke TTCN3 BTS_tests
TC_dyn_ipa_pdch_tchf_act_pdch_act_nack.
Prior to the breaking commit, logic was still not good, because
1- It didn't return after sending the NACK
2- It sent a NACK in all cases, while for PDCH DEACT we want to force
its deactivation. Going through tests it can be seen that indeed it
can deactivate it in that case:
rsl.c:2206 (bts=0,trx=0,ts=3,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still in state ACTIVE
...
rsl.c:2103 (bts=0,trx=0,ts=3,ss=0) Tx PDCH DEACT ACK
Fixes: 133a3d96dc07ebda4dfc7899dab9c0d0c80c9fea ("rsl: Avoid sending ipa PDCH DEACT NACK followed by ACK")
Change-Id: I6d6d12aec10c801fe55012ca6e58d0bc8755b15d
|
|
This allows running sysmobts-mgr on systems with old gpsd releases
(which may have other software depending on such old release).
GPSD_API_MAJOR_VERSION define was first added in gpsd 2.39, before that
it didn't exist (but this code is known to work against 2.38).
GPSD_API_MAJOR_VERSION == 5 was set in version 2.96.
Related gpsd commits:
3771dba081bd1175adab6096d7b6270d3822aaa1
e69bcb6b01af6b25c6a525fb1961b92ac04f5213
Related: SYS#4290
Change-Id: If3c35021a020a61d5fa3cde5eebcd09908db822b
|
|
API prior to that version allocates the pointer internally. Let's change
current code to always use a pointer and in current supported code (gpsd
>= 2.96) point it to a user-allocated struct.
Follow-up patch will introduce necessary ifdefs to support older gpsd.
Change-Id: Iaeb5ac527cc3e58168027021d0f60afa93d1fb6f
|
|
Before this patch, PDCH DEACT was (n)acked to the BSC without taking
into account if TRX succeeded or failed to set the TS:
20181123044720655 DRLL rsl.c:2523 (bts=0,trx=0,ts=0,ss=0) Rx RLL DATA_REQ Abis -> LAPDm
20181123044720700 DRSL rsl.c:2805 (bts=0,trx=0,ts=6,pchan=TCH/F_PDCH as PDCH) ss=0 Rx RSL IPAC_PDCH_DEACT
20181123044720700 DRSL rsl.c:2205 (bts=0,trx=0,ts=6,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still active
20181123044720700 DRSL rsl.c:2131 (bts=0,trx=0,ts=6,ss=0) Tx PDCH DEACT NACK (cause = 0x0f)
20181123044720700 DPCU pcu_sock.c:124 Sending info
20181123044720700 DPCU pcu_sock.c:139 BTS is up
20181123044720700 DPCU pcu_sock.c:232 trx=0 ts=7: available (tsc=7 arfcn=868)
20181123044720703 DPCU pcu_sock.c:608 Deactivate request received: TRX=0 TX=6
20181123044720703 DL1C l1sap.c:1519 deactivating channel chan_nr=TCH/F on TS6 trx=0
20181123044720703 DTRX trx_if.c:242 Enqueuing TRX control command 'CMD NOHANDOVER 6 0'
20181123044720703 DL1C l1sap.c:648 deactivate confirm chan_nr=TCH/F on TS6 trx=0
20181123044720703 DRSL rsl.c:714 (bts=0,trx=0,ts=6,ss=0) not sending REL ACK
20181123044720703 DRSL rsl.c:2264 (bts=0,trx=0,ts=6,ss=0) PDCH DEACT operation: channel disconnected, will reconnect as TCH
20181123044720703 DL1C scheduler.c:593 Configuring multiframe with TCH/F+SACCH trx=0 ts=6
20181123044720703 DTRX trx_if.c:242 Enqueuing TRX control command 'CMD SETSLOT 6 1'
20181123044720703 DL1C l1_if.c:780 (bts=0,trx=0,ts=6) bts_model_ts_connect(as_pchan=TCH/F) success, calling cb_ts_connected()
20181123044720703 DRSL rsl.c:2339 (bts=0,trx=0,ts=6,ss=0) PDCH DEACT operation: timeslot connected as TCH/F
20181123044720703 DRSL rsl.c:2440 (bts=0,trx=0,ts=6,ss=0) TCH/F_PDCH switched to TCH/F mode (ts->flags == 0)
20181123044720703 DRSL rsl.c:2103 (bts=0,trx=0,ts=6,ss=0) Tx PDCH DEACT ACK
20181123044720704 DTRX trx_if.c:492 Response message: 'RSP NOHANDOVER 0 6'
20181123044720705 DTRX trx_if.c:492 Response message: 'RSP SETSLOT 0 6 1'
Change-Id: I888de761b65c3ea8bfe623fcf009f3b2b57c926c
|
|
Change-Id: I2e4aad190c44fea047b4aefcf55335789fa4c571
|
|
This commit doesn't change internal logic of any model, only the API to
be able to return result of connect TS asyncrhonously since some models
(like osmo-bts-trx) require some time to process the result. This way
PDCH ACT/DEACT (N)ACK can be sent once the result of this long process
is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK
before getting the result from SETSLOT on the TRX iface.
With this new API, bts_model_ts_connect doesn't return any value
synchronously. Instead, it is expected to always end up calling
cb_ts_connected with the return code from the TS activation process. 0
is considered a successs, while any other value is considered an error.
Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
|
|
Change-Id: Iaa4552844db33fe69da5ed7028dbfa0100c33900
|
|
Later on it's expected to add more rsp parsing, so let's return here and
not depend on generic return further down.
Change-Id: I8ddee46374ab329c47dc68e720e236f13d393f66
|
|
It was spotted during osmo-gsm-tester test
dynts:trx-sysmocell5000+mod-bts0-dynts67-ipa+cfg-codec-fr-any that
osmo-bts-trx was answering to PDCH DEACT from BSC first with a NACK
followed immediatelly after by an ACK. That happens after the test does
a GPRS pdp ctx act successfuly and then deactivates the ctx and the 2 MS
try to place a call between them (and thus channels need to be moved to
TCH/F).
Most probably the if condition where the lines for this commit are
modified need to be fine-grained. Patch before this one should help to
understand the steates/situation in this scenario, and then a follow-up
patch can be created to improve the logic.
Change-Id: I91c65da6b6b7094f32187d3b083153a87c3219fd
|
|
Change-Id: Iee5ac0550afda71fce67b0340749c111b364bb4f
|
|
Change-Id: Ib1ecc6dcb243da27976ca0e90a83aefa18a65b76
|
|
llist_count() return unsigned value, let's use it for counter as well.
Change-Id: I81097a64ef694bec046afcc23cf995dc539a706b
|
|
Change-Id: I45aae70f4bc3f4f85d267dafb757debdef1bb7d7
|
|
Change-Id: I4f78bc13908c2d9dfbe24195ae6e35fae8575c59
|
|
TRX0 is allocated in a different place than other TRX.
Commit that introduced the bug added an initialization step
(bts_trx_init) applied in VTY cmd "trx <0-254>", where TRX are allocated
since same commit, but doesn't initialize TRX0 for reasons explained in
first paragraph.
As a result, some parameters were not applied to TRX0, like
power ramping increment step, which prevented MS from finding the network in
osmo-gsm-tester tests.
Fixes: eebb6a4216f136132400831ca35ed70e7502e92a ("bts: Allocate TRX for BTS dynamically, deprecate -t")
Change-Id: I5afd66548634ff53e2af24dc7055d408ca8ca4e3
|
|
If POWERON fails, announce to BSC that the TRX is not available, and
announce it as available as soon as POWERON success is received.
Related: OS#3692
Change-Id: Iaa8f497381038fd7f9f779a8211ebc6453837c65
|
|
Related: OS#3692
Change-Id: I1ba32c162a8a98ed0fdd4190227de66270679e5a
|