Both NM_ATT_IPACC_DST_IP and NM_ATT_IPACC_DST_IP_PORT are defined
as TLV_TYPE_FIXED, and NM_ATT_IPACC_STREAM_ID is TLV_TYPE_TV, so
the TLV parser already does check the length for us.
Change-Id: I1e493e552bb22bb42bb196ce71214e28d23fd19e
Otherwise, some objects are announced at startup of osmo-bts towards BSC
during State Changed Report as being "NULL".
According to TS 12.21:
"NULL(Operat. state not supported) FF"
Which doesn't make much sense in startup situation. They are in known
state Disabled until they are OPSTARTed.
Change-Id: I5ba6756ea069d0f995f453ee4b27e6839c914eb1
This is another regresion introduced by [1]. Both local and remote
port numbers recived in the network order, and must be stored as-is.
Change-Id: I3c21a2c27dcbf6de728ce2c7ccbae9e2f517c450
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
The address_family is 8 bit and have a padding byte afterwards.
By using osmo_load16be it's encoding it wrong and result in an
empty/invalid NSVC configuration.
Change-Id: Ie070b5745124d48e74a6dedd8903b74bfb3ce9d2
With PCU interface version 10 it supports IPv6 NSVC. The new OML IE
NM_ATT_OSMO_NS_LINK_CFG allows to configure IPv6 NSVC.
Change-Id: I310699fabbfec4255f0474f31717f215c1201eca
There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
An additional octet is only needed if total number of features
cannot be devided by 8 without the remainder. Fix this.
Change-Id: Ie501e5a635493830e0597f7b2fa287b6448e660d
This redundant call to msgb_put() appends five '00'O octets to the
"Software Activated Report" message, so they look like an unknown
attribute(s). I accidentally noticed this in Wireshark.
Change-Id: I7377575135f4a154572891d1b5b39ff814b97f38
The timers are unfortunately completely broken, so let's go back to the
long default timeout values from 1ff0a2addd
See related issues OS#4066 and OS#4074
Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
By using new libosmocore LAPDm API we can specify the GSM channel type
and hence enable the LAPDm code to use a per-channel-type specific N200
value.
At the same time, this new API also allows us to specify T200 values
when initializing the LAPDm channel, so we don't have to fiddle with
low-level lapdm data structures in what used to be oml_set_lchan_t200().
Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48
Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c
Closes: OS#4037
As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances
in the BTS are configured via OML from the BSC. While OsmoBSC
is sending them and OsmoBTS is parsing them, OsmoBTS stopped to
make use of them from commit 3ca59512d2
(January 2016) onwards.
The cause for this has been documented and discovered in May 2017
in https://osmocom.org/issues/2294 and it is quite obvious: LAPDm
timers are supposed to start when a given frame is actually transmitted
on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be
used over a synchronous interface in some deeply embedded processor.
With OsmoBTS however, we have an asynchronous L1/L2 interface between
a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx)
and we receive PH-RTS.ind quite some time ahead. So if we start T200
at that point, then it will start running way before it has been sent
or before the MS has had a chance to receive the message.
The "correct" way to handle this is to actually measure the difference
between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind
(downlink) or PH-TIME.ind, and then add that amount to the actual
timeout value. This ensures that the timers will time-out the
user-specified amount of time after the actual transmit.
Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4
Closes: OS#2294
Closes: OS#3906
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
Rather than open-coding "Tx foobar..." in various functions (and
forgetting it in half of them), let's add a generic message into
oml_mo_send_msg().
Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
Some of our OML log lines were missing any context. Try making more
sense by printing any context information about the given managed
object, TRX, ... as we have it.
Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
There's no point in open-coding what LOGPLCHAN was created to do:
Log some event while stating the name of the logical channel.
Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
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
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
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
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
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
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
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
Vadim Yanitskiy
Pau Espin
Alexander Couzens
Harald Welte
Eric Wild
Philipp Maier