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
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
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
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
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
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
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
Commit acefd0586e 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: 133a3d96dc ("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
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of jenkins_bts_model.sh. Change the top description line to look
like all the other contrib/jenkins.sh files (from other repositories),
so it is clear that this is the entry point of Jenkins (and not the
other contrib/jenkins_*.sh scripts).
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: If51194cc595bd8cf1081b35ab0e1a5ddcd448860
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I332c94502cce0f3f11fe3f4d9f6c9918ff0c0263
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I728ebb56ade6dda079a0744c4e592284e1bea4f6
Surrounding with '@' didn't seem to yield the intended result, the
charactars appeared in the compiled document.
Change-Id: I66e7949fa4a6c2164bf9572a2beaf8ace169fa1c
Harald Welte
Pau Espin
Max
Philipp Maier
Daniel Willmann
Oliver Smith