The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
Related: OS#3750
Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.
Related: OS#3750
Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
Send an RSL Error Report in case of unknown/unsupported msg_type,
as describedi in section 7.3 of 3GPP TS 48.058.
Related: OS#3750
Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
This reverts commit ad7b8bee71.
Unfortunately the osmo-gsm-manuals-dev package isn't working properly
yet, therefore osmo-bts fails to build on nightly OBS now. My apologies
for not testing enough in my own OBS namespace, before merging. I'll do
that in the future. I'm reverting the patch now, so osmo-bts isn't
missing from the nightly repository until I've fixed the
osmo-gsm-manuals package.
Change-Id: I89c2b92c8ae6331d6fff95a378fb58d82059af13
Neither the bug has been reproduced, nor the bug reporter
did respond to request for configuration files.
Change-Id: Ibc9db360be1380abaa9eef4bdf6e9a6d251670da
Support for extended (11-bit) RACH has been implemented:
- in libosmocoding: I85a34a82d5cd39a594ee89d91a2338226066ab5d,
- and OsmoBTS: Ia28741603636406744e5e22ffff1fb7a9689955a.
We also have a TTCN-3 test case called TC_pcu_ext_rach_content,
see I8fe156aeac9de3dc1e71a4950821d4942ba9a253.
Change-Id: I091f4fbd52c29c7d56ca392b8a1b872609829d81
It seems osmo-bts-sysmo does support CBCH (Cell Broadcast), but
for some reason it doesn't report BTS_FEAT_CBCH to the BSC.
Change-Id: I42dd3f84c44c210d9255e17153372bf252f897a1
Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases,
it was discovered that there are possible collisions when trying
to decode a regular 8-bit Access Burst as an 11-bit one. This is
exactly what we are doing in rx_rach_fn():
- calling gsm0503_rach_ext_decode_ber() first,
- if it failed, falling-back to gsm0503_rach_decode_ber().
With default BSIC=63, the following 8-bit RA values are being
misinterpreted as 11-bit Access Bursts:
Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f
Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f
Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f
According to 3GPP TS 05.02, section 5.2.7, there are two alternative
synch. (training) sequences for Access Bursts: TS1 & TS2. By default,
TS0 synch. sequence is used, unless explicitly stated otherwise
(see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using one of the alternative training
sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
In other words, knowing the synch. sequence of a received Access
Burst would allow to decide whether it's extended (11-bit)
or a regular (8-bit) one. As a result, we would avoid possible
collisions and save some CPU power.
Unfortunately, due to the limitations of the current TRXD protocol,
there is no easy way to expose such information from the transceiver.
A proper solution would be to extend the TRX protocol, but for now,
let's do the synch. sequence detection in rx_rach_fn(). As soon as
the TRX protocol is extended with info about the synch. sequence,
this code would serve for the backwards-compatibility.
This change makes the both TC_rach_content and TC_rach_count happy,
as well as the new TC_pcu_ext_rach_content() test case aimed to
verify extended (11-bit) Access Burst decoding.
Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253
Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284
Related: OS#1854
According to 3GPP TS 52.021, sections 9.4.61-62, 'SW Configuration'
shall contain a list of 'SW Descriptions' related to the MO. In
other words, all 'NM_ATT_SW_DESCR' blobs shall be encapsulated
into a single NM_ATT_SW_CONFIG attribute.
For some reason, they were not encapsulated properly, so
OsmoBSC were unable to parse the 'SW Descriptions'.
However, unlike OsmoBSC the old OpenBSC does not expect this
encapsulation, thus after this change it will be unable to
parse the 'SW Descriptions'.
Change-Id: Id26104719891944f3e2151df362bd45bb057a9c5
Related: OS#3938
Instead of allocating two transitional buffers (one static,
another dynamic), we can use the existing message buffer.
Both handle_attrs_bts() and handle_attrs_trx() can put (append)
the reported attributes, and push (prepend) non-reported ones
as per 3GPP TS 52.021, 9.4.64 "Get Attribute Response Info".
Change-Id: I349447a43bce360f59e0c6b435906c65167d158b
Passing a pointer to a packed structure to tmsi_mi_to_uint() may
result in unaligned pointer value. Found with clang-8.
Change-Id: Ief69854973a098e6da7c05f4417dc11988edd777
Found using clang-8:
rsl.c:1646:7: warning: taking address of packed member 'packets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1646:28: warning: taking address of packed member 'octets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:7: warning: taking address of packed member 'packets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:28: warning: taking address of packed member 'octets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:7: warning: taking address of packed member 'packets_lost'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
Found using clang-8:
rsl.c:1607:93: warning: size argument in 'memcmp' call
is a comparison [-Wmemsize-comparison]
rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead?
It looks more logical to compare the result of memcmp() against
zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size.
Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
Both callers of cleanup_attr_msg(), i.e. handle_attrs_trx() and
handle_attrs_bts(), always pass out_offset >= 1, so the length
of the unsupported attributes counter is already accounted.
Otherwise, both callers would copy an additional garbage byte
from uninitialized memory. Discovered using Valgrind:
DOML DEBUG oml.c:539 OC=BTS(01) INST=(ff,ff,ff) Rx GET ATTR
DOML INFO oml.c:265 BTS Tx Get Attribute Response
==25467== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==25467== at 0x623E0BD: send (send.c:27)
==25467== by 0x5685846: __handle_ts1_write (ipaccess.c:358)
==25467== by 0x5683F8B: ipa_client_write (ipa.c:79)
==25467== by 0x5683F8B: ipa_client_fd_cb (ipa.c:140)
==25467== by 0x5F1DC23: osmo_fd_disp_fds (select.c:223)
==25467== by 0x5F1DC23: osmo_select_main (select.c:263)
==25467== by 0x42980B: bts_main (main.c:354)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Address 0x7d83895 is 23,669 bytes inside a block of size 102,528 alloc'd
==25467== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25467== by 0x589A6B4: talloc_pool (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.5)
==25467== by 0x5F1E28B: msgb_talloc_ctx_init (msgb.c:316)
==25467== by 0x4293D0: bts_main (main.c:234)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Uninitialised value was created by a stack allocation
==25467== at 0x415FE5: oml_tx_attr_resp (oml.c:259)
==25467== by 0x415FE5: oml_rx_get_attr (oml.c:561)
==25467==
Change-Id: Ic7c2c4e54e9f99b60aaf70604044933978be945c
Related: OS#3938
It was noticed that the Get Attribute Response message always
indicates BTS(00,ff,ff) as the addressed OML entity, even if
e.g. Baseband Transceiver(00,00,ff) was requested by the BSC.
Despite neither OsmoBSC nor OpenBSC does complain about this,
such behaviour violates 3GPP TS 52.021. Let's fix this.
Change-Id: Icb1ee75d4bf680deb6365288d8c2053816a12217
Related: OS#3938
When using %lu and sizeof() for printing the compiler may throw a
warning. Lets prevent this by using %zu instead of %lu as conversion
specifier.
Change-Id: If5cb656537b1b73b9361a132801ab47ab7f8a709
The functions oc2gbts_par_get_uptime() and oc2gbts_par_set_uptime() try
to return with NULL, but both functions are declared as int. Lets return
-EINVAL instead.
Change-Id: I63b61be2940c59b221089d3d1501371b0116d89a
fsync() takes an integer file descriptor but we have a *FILE pointer
here. Lets use fileno() first to convert the integer file descriptor to
a FILE pointer.
Change-Id: I46ffd8c680ba0b445cbbd133d5ce92b79e3d8d87
the function bts_cbch_get() is used in l1_if.c. The function is
declared in cbch.h. Lets include this header file in order to be
complete.
Change-Id: I95d7e89eed969dd5b3ccff0eebcc6c568196a97d
In oml_send_msg() we optionally push the A-bis IPA magic string
("com.ipaccess") to a given message buffer as LV (Length Value),
including the terminating null byte ('\0').
There was a mix of both sizeof() and strlen() calls, and worse
luck, memcpy() has been used in a wrong way, skipping the '\0':
memcpy(dest, src, strlen(src));
In general, this is not critical because the headroom of a given
message buffer would most likely be zero-initialized, so the '\0'
is already there. However, msgb_push() gives no such guarantee.
Let's use the libosmocore's TLV API (in particular, lv_put()),
and stick to sizeof(), so the null byte will always be included.
Change-Id: I0c7f8776d0caec40f9ed992db541f43b732e47ae
Closes: OS#3022
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15,
a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if
it wants to suspend GPRS services. The BSS is now responsible to
somehow forward this to the SGSN. As the Gs interface between BSC and
SGSN is both optional and doesn't have any provision to forward this
message, we have to send it over to the PCU so it can use regular BSSGP
signaling to inform the SGSN of the SUSPEND REQUEST.
This patch requires libosmocore Change-Id
I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of
struct gsm48_gprs_susp_req.
Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f
Closes: OS#2249
At some locations in the code a signal to SS_FAIL is dispatched in order
to trigger the sending of an OML failure event report in oml.c. This is
a bit overcomplicated for the task. Lets use oml_tx_failure_event_rep()
to send the failure event reports and lets remove the signal handler for
SS_FAIL.
Change-Id: Ie4fce1273a19cc14f37ff6fc7582b2945c7e7c47
Related: OS#3843
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets
use only oml_tx_failure_event_rep() and remove oml_fail_rep()
Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6
Related: OS#3843
SIGUSR1/2 and SIGABRT should not trigger a failure event report on
OML since we only use it to get an intermediate talloc report. (In
case of SIGUSR1/2 without leaving the process.)
Change-Id: I99e637496afff2530425b89c6e9befc76db24906
The function gsmnet_from_vty() is used in oc2gbts_vty.c, but it is not
declared in vty.h. Lets add the declaration to vty.h, so that
gsmnet_from_vty() can be used properly by other modules.
Change-Id: I8cf63c6fabdb1f2dc67ca8193704ce4d1d4882d9
Nowadays only known users (OE images) use systemd and don't require this
kind of screen setup.
In any case, this kind of file belongs to scpeific setup and are not
needed here.
Change-Id: I65b0eee44336e4627620443861092b8988f2e01d
This fixes the below compile error:
rsl.c:900:43: error: ‘gsm0808_chosen_enc_alg_names’ undeclared (first use in this function)
Change-Id: I4aed0242737602e61b785862e3c37c963bf48455
The log level of the messages that notify calibration file loading
problems is NOTICE, but since it is a severe problem when calibration
can not be loaded lets change it to FATAL
Change-Id: I32aed25ca7925f1c776f00b37f404a58a85ddbc7
Related: OS#3823
When the TX/RX calibration files can not be loaded a failure event
report should be sent to the BSC. Lets send a failure event report when
calbration data is either bad or can not be loaded (see also remvoed TODOs).
Change-Id: I3318470518b34807a443f7cb78c7091b4a3d4481
Related OS#3823
On links with high latency it can happen that RADIO CARRIER OPSTART is
carried out to early, even before SET BTS ATTRIBUTES is carried out.
This means that important parameters for the initalization are not yet
set and the TRX initalization failed. Lets delay the TRX initalization a
bit in order to be sure that all BTS attributes are set before the
initalization is carried out.
Change-Id: Id3bdc88d28417e422d2c0c33b03be06f1a4706c2
Related: OS#3782
The function vty_install_default() is deprecated and throws a compiler
warning that suggests to remove it, so lets remove it.
Change-Id: I1a4afb6e352bed9a5af794b39b984a7ddef36e08
The static function oml_tx_failure_event_rep() is a lot easier to use
than the currently implemented signal scheme. Lets make it public so
that we can quickly generate failure event reports.
Change-Id: I9c4601840a06119f35cfe4da453fff3b293fe615
Related: OS#3823
According to the OC-2G product specifiacation, the maximum output power
is 25 dBm. This should be reflected in the code, there's no point in
claiming to be able to trnasmit 40 dBm - which just creates confusion on
all levels (such as the logs, where Tx power is claimed to be ramped up
to 40 dBm right now).
Closes: OS#3823
Change-Id: Ia6b3476ab2f9279f8905b8c7cfd07ef7b0a939ed
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
Harald Welte
Oliver Smith
Vadim Yanitskiy
Alexander Huemer
Philipp Maier
Pau Espin