The BTS is not added to the hashtable during allocation, because the
default LAC value is 0, which is GSM_LAC_RESERVED_DETACHED
(reserved by GSM 04.08), so it's also detached from the hashtable
(cannot be found based on a reserved value).
Related: SYS#7062
Change-Id: Id523027b49e0f58cd2c8c9b4dee619de415dbd15
According to TS23.003, CI should be unique in a LAC.
Previous commit wrongly introduced a while ago a new "bts 2" with same
LAC and CI as "bts 1" in config file.
This makes current tests fails once a hashtable is added to lookup bts
by lac, since the hashtable code does prepend new bts instead of
appending them. As a result, bts 2 is returned instead of bts 1 being
previously returned.
Also change the ARFCN+BSIC since it was also duplicated. It makes not much
sense to have 2 neighbor BTS with same ARFCN+BSIC.
Fixes: 97ed3c8d97
Change-Id: I7d1ebd529e050ecb4c14b9d3523637e4c8c87e1d
gsm_bts_num() is mostly used to lookup bts object from its nr in VTY and
CTRL interfaces.
However, it's also used in hotter paths like pcu_rx().
It is also used during local neighbor resolution, mostly at startup or
when the VTY is re-applied from CTRL interface.
Related: SYS#7062
Change-Id: I7312da7d9aa80c6d0f2e92e9c7d20d32ce453ad1
In set_bts_loc():
* Comment stating the entry was appended to the list was wrong.
* location_equal() could be called with lastloc containing poisoned
pointers (INIT_LLIST_HEAD), which is not that nice.
Change-Id: I5b706dfd3a96f5e9b61907a727ef5887338e66c6
Since the "struct gsm_pcu_if"->bts_nr is still uint8_t, that means
only the first 256 configured BTS can properly make use of the
PCUIF interface and hence have gprs support.
This is not a major problem as long as the BTS connected to osmo-bsc
are of type osmo-bts, since usually those use a BTS co-located
osmo-pcu, hence on each one bts_nr=0.
But if we wanted to run them with osmo-bsc PCU co-located,
(eg rbs2000), then we'd need to extend the PCUIF interface.
Related: OS#6565
Related: SYS#7062
Change-Id: If5a8cd94195422989de3daa04be7ffc858c0a8eb
Some users actually want to deploy osmo-bsc connected to more than 256
BTSs. Allow them to do so.
This is about increasing the integer size / maximum value of the
internal "bts->nr" ID usef eg. during VTY configuration.
The ipaccess OML bts_nr is still kept as uint8_t so nothing changes over
the wire. That's because in ipaccess OML, in general each BTS is
bts_nr=0 (bts->bts_nr) under its own ipa connection.
NOTE: This patch doesn't add support to handle >256 BTS over PCUIF,
which still keeps its (struct gsm_pcu_if)->bts_nr as uint8_t.
This is not much of a problem yet though, since the requirement to run
>256BTS is needed in a network where osmo-bts is used, and hence PCUIF
is handled at each BTS.
Related: SYS#7062
Change-Id: I607a68efeb5f4a50cce107d11d3c5126b7d8f81a
The size of bts->nr is implicitly or explicitly used or taken into
account in several places in the code.
Add a new type to make it easier to define its size and range in one
place.
This also helps in identifying fields contains an BSC-implementation
"bts_nr" vs theip.access Abis OML "bts_nr" sent over the wire, which is
always a uint8_t according to spec.
Related: SYS#7062
Change-Id: Ic0db2873fa9795024aba4399da495a0d8f7504b0
The amount of dependencies on each BTS is usually zero or a small
number, hence the computation cost is mostly similar regardless of using
a llist or a bitmask buffer.
Right now, even if the dependency chains are (almost) empty, the
previous code allocated (N * 256/8) bytes, where N is the amount of bts
configured.
Since we are now planning to increase the amount of bts (N) from uint8_t to
uint16_t, that means with this change we will then avoid:
* Increasing memory use to O(N * 65536/8).
* Having to adapt code operating on bitmask (size)
Related: SYS#7062
Change-Id: I59e37d6baa020aeafdffc2c3538e988effd37620
This is where one would usually expect it, so that private model
functions can be declared static easily, and next to the function
registering it with the core.
Change-Id: I4006d4a0df4c7e477a6c731fc55badc782448866
osmo_io segmentation will already parse the ipaccess_header and set
msg->data to the payload of the control command.
Depends: Id91cddf9948ca49abf092850fae3a8f17e445b45 (libosmo-netif.git)
Related: OS#6422
Change-Id: I300bbab3c0215d52bc5f6232ace5c37a6613feb7
There is no reason to allow the 5.90k mode alone. Allow them all
and let codec negotiation figure out the AMR rates to use.
Change-Id: I33e297a28bcaf8fd9ccddb20ce9ce092ab57d2e0
It's safer to deny emergency calls by default, and thus require
osmo-bsc users to allow them manually iff such calls can actually
be routed to their local emergency services.
This reduces the risk of a situation, when a person having a real-life
emergency would be trying, for instance, to call an ambulance via a
test network, which does allow emergency calls but cannot route them.
Change-Id: I5296b3031c14a896caa33b16bf04db762b9f30bf
Themyscira Wireless Technical Specification TW-TS-003 defines
a mechanism whereby the CN can ask the BSS (via an extension to
BSSMAP Assignment procedure) to use enhanced RTP payload formats
that are contrary to the stipulations of 3GPP TS 48.103.
However, these RTP extensions need to originate at the BTS,
hence if the BSC receives a request from the CN to use them,
it needs to validate that request against BTS capabilities,
and then actually pass it to the BTS via an Osmocom-defined
RSL IE that replicates TW-TS-003 in Abis. Implement this logic.
Intra-BSC handovers: if ThemWi RTP extensions are used in a GSM
network that allows handovers, all deployed BTSes must have
the same capabilities with regard to these extensions, practically
meaning same or close-enough version of OsmoBTS. OsmoBSC checks
CN-requested RTP extensions against BTS capabilities on the
initial assignment, but not on subsequent handovers.
Inter-BSC handovers: support for RTP extensions in this deployment
configuration (networks that allow such handovers) remains to be
implemented.
OsmoMGW considerations: if all deployed BTSes are native IP
OsmoBTS, as opposed to E1-based, OsmoMGW does not need to know
anything at all about ThemWi RTP extensions. However, future
support for these RTP extensions with E1-based BTSes will require
adding a mechanism for communicating the necessary non-standard
request to OsmoMGW.
LCLS considerations: enabling ThemWi RTP extensions affects only
the uplink RTP output path in OsmoBTS and not the path from RTP
input to downlink Tx. The latter path accepts both basic and
extended RTP formats; any ThemWi extensions in the incoming RTP
stream are harmlessly ignored. Therefore, activation of ThemWi
RTP extensions will have no impact on LCLS operation.
Related: OS#6448
Depends: I0eccfe5ddcf44f8f20440acb01e2d4870ec0cd91 (libosmocore)
Change-Id: I2a742afff160a9a8286633bf5ae0dd4a828c7a42
We ignore the N-STATE prim, so don't error about it.
While at it, improve the "unhandled" error message (according to code
review).
Related: SYS#6952
Change-Id: Ic353840a7b2e32c54c2732f58836776a5eddb220
It doesn't build up a generic physconf. It only build up an arfcn white list
based on a list of rxlev
Change-Id: I6e2d27c10dc9075f06070bb784369bbd1d75f88e
Do not attempt to change permissions/ownership if the package gets
upgraded from a version higher than the next release.
Do not fail if the user deleted the config file.
Be verbose when changing permissions.
Related: OS#4107
Change-Id: I853097a13e27b2ebd0b940117c8f5f4b3ea49b9a
* Explicitly chown /var/lib/osmocom to osmocom:osmocom, instead of
relying on systemd to do it when the service starts up. This does not
work with the systemd versions in debian 10 and almalinux 8.
* deb: Use "useradd" instead of the interactive "adduser" perl script
from Debian. This makes it consistent with how we do it in rpm, and
avoids the dependency on "adduser".
* deb: Consistently use tabs through the file, instead of mixing tabs
and spaces.
* deb: Remove support for the "dpkg-statoverride --list" logic. This
seems to be a rather obscure feature to override permissions for
certain files or directories, for which it does not seem to be a good
idea to make the postinst script less maintainable. Something similar
can be achieved by using your own Osmocom config file in a different
path with different permissions.
Related: OS#4107
Change-Id: Ie34e7aa65e576cf1742a33530a6f44d2344c39d0
Create osmocom user & group during package installation.
Fix the configuration dir/files permission to match.
Related: OS#4107
Tweaked-By: Oliver Smith <osmith@sysmocom.de>
Change-Id: Ic64bcd8a8124fcc8c6d7ffe31d32f51b288afdcb
libosmo-netif (not yet released) stream_{cli,srv} osmo_io read_cb API was
updated to provide read result status. Hence, now API users
can account for lower layer errors and act properly, like it used to
do with the previous ofd backend.
This commit partially reverts some error code paths removed in
85687bf176 when converting code to use
osmo_io osmo_stream backend.
Change-Id: I4cce5cb6ca98bc28a67dd6e927e9cdfd2312851a
Depends: libosmo-netif.git Change-Id I395c75ff1e9904757ce1d767a9ac2f779593c4c8
This new commands show information about logical channels:
net.btsN.trxM.tsI.show-lchan.full
net.btsN.trxM.show-lchan.full
net.btsN.show-lchan.full
net.show-lchan.full
Change-Id: I23c1a7e6f6679e3964e359fb202ffe6781a07e8a
This new command shows information about a logical channel using
net.btsN.trxM.tsI.lchanL.show.full
Change-Id: I5432800eae452b6df71a151a7649f228704ed0da
I guess it must have been a mistake when introducing this file.
The entire project is under AGPLv3, it doesn't make sense to have
one single file under GPLv2.
As th entire git commit history only contains sysmocom employees,
I have the authority to re-license it even if GPLv2 was done
intentionally at the time. Let's change it.
Change-Id: I5e5385f7630b41f1c4ad9534dbb4551e597ad596
IF we say "... under the terms of the GNU Affero General Public License"
then we cannot say "see the GNU General Public license" later on, that's
misleading and likely a copy+paste error somewhere.
The project license has always been AGPLv3-or-later.
Change-Id: I6b8ad5147ca76052213809e67856dcb80bff2b93
This new command allows to control MS power level for a specific
logical channel using net.btsN.trxM.tsI.lchanL.ms-power
This patch also adds a lchan node to the ctrl interface.
Depends: libosmocore.git Ibf2786f668ee7e4f5b6a9ef43f2141cd2d79b4e2
Change-Id: I6f556b66011be6126d6bac31a14101ba37f81cc4
Besides from making the ts ctrl interface follow the convention
of being in its own file, it will be used in the next patch to add
a ctrl interface for lchan.
Change-Id: I9840bddd4eae409bc8373912d54b6bbfc9fc1c1a
clang warns us about 'len' being set, but not used: And this is
abis_nm.c:2172:10: warning: variable 'len' set but not used [-Wunused-but-set-variable]
uint8_t len = attr_len;
^
This is actually a bug, because in the case of NACK we append 2 more
bytes {NM_ATT_NACK_CAUSES, NM_NACK_OBJCLASS_NOTSUPP}, and we need to
pass the final length to fill_om_fom_hdr(), including those optional
two bytes. Passing 'attr_len' (length of 'attr') is wrong.
Change-Id: I3ca8e761fdf99dd498a979ccc9d53c6c3e03e2cc
