* OM2K_DEI_FREQ_SPEC_RX:
(hop << 15) | (rx_addr << 10) | arfcn
. hop Hopping marker
. rx_addr is not really the TRX number, it's just a sequential number
different for all TRX, doesn't need to be 'in-order' of TRX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_SPEC_TX:
(hop << 15) | (tx_id << 10) | arfcn
tx_id Pretty much same as rx_id except here we know that the order
doesn't have to match TRX order. It seems to even vary from one
reboot to another on some real-world capture we got.
. hop Hopping marker
. tx_addr Same as 'rx_addr' above but for TX
. arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency')
* OM2K_DEI_FREQ_LIST:
Groups of 3 bytes (24 bits), 1 per frequency used.
(tx_addr << 20) | (rx_addr << 16) | (is_c0 << 10) | arfcn
. tx_addr See above
. rx_addr See above
. is_c0 Must be 1 if that ARFCN hosts the C0. (first TRX of a MCTR)
. arfcn The ARFCN number
(Note MAIO must also be set properly on the different TRX/TS sharing
a frequency ... )
The way we generate theses here is what we gathered from real-world
traces:
- Each 'TX' of each TRX is set to the ARFCN set in that TRX config
- Each 'RX' of each TRX is configures as 'hopping'
(which I assume means it will just pick the appropriate freq ?)
- For each TS, we use :
. tx_addr of the TRX that has the ARFCN we want to TX on
. rx_addr of the TRX where the TS we're configuring is
. arfcn The actual ARFCN we want to add to the list
This is incomplete but will work for the 1 MCTR case.
Config for multiple MCTR or multiple virtual-bts still need to be
handled but it's not yet known exactly how those need to be
configured.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie39a857543adaa11d1822346d8563ce3718412c8
During the configuration of the TS object through OML we must use
pchan_from_config since it's too early to use anything else.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iecdc911a79b66d8f3d746347710ad697cb288174
The existing Nokia *Site code destroyed the LAPD SAP instance for OML
while processing an OML message. Once the stack frame returned back
to the LAPD code, the LAPD SAP was gone -> segfault.
Let's work around this by moving deletion of the LAPD SAP out-of-line
by starting a timer 0ms in the future. Not particularly nice, but
effective.
Change-Id: I6270c7210f600e53f845561898245d2fd30a368d
Closes: OS#1761
This is probably a fault report of some kind, but didn't get any
confirmation or naming from anywhere for it yet.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8333093d09f27f61094c7f5854573aa16e4bf28c
Thoses messages IDs are 16 bits and the upper 8 bits are sort of
important :D
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ifcc1a01fdbf66a0f6f44cf8fed60dc19e72dd56a
* In superchannel mode, those 3 are required.
* In normal mode, "Config Type" is optional and the two others are
forbidden.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: If02d02c067ae8af8ce693ddfb8747212f3f4e441
slashes are invalid so we can't use om2k_mo_name() directly, so we just
build it manually with dashes.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3cfc19670e6d7bb607d796cabcee5e86a15d1985
Make various internally used timers negative, to indicate that they are
Osmocom specific. A follow-up patch will make them configurable.
Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
/usr/bin/ld: bsc_subscr_conn_fsm.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: multiple definition of `mr'; abis_rsl.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: first defined here
See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000649.html
Change-Id: Ic21af84f2a6de48d220940f30dad02a0e7683ce8
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE
contains two parameters related to 11 bit Access Burst support:
- ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be
used in the PACKET CHANNEL REQUEST message, the PTCCH/U block,
PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS
messages on the PRACH (if present).
- EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall
use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF
establishment on the RACH or on the PRACH (if present).
The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls
the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may
be hard to understand this from its name and description.
This patch is actually a group of tightly related changes:
- deprecate 'gprs 11bit_rach_support_for_egprs (0|1)':
- update its description to avoid any possible confusion,
- print a warning if it's used in non-EGPRS mode,
- print a warning if it's still used;
- introduce '[no] gprs egprs-packet-channel-request':
- ensure that it can only set / printed in the EGPRS mode;
- take a chance to clean-up / rename the related struct members:
- 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request',
- remove 'supports_egprs_11bit_rach' from 'gprs_cell_options'
because we already have 'ext_info.use_egprs_p_ch_req' there.
Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: If71654d87b375b4b882ab527e89353cd035f695b
This logging category has been removed in [1], what caused test
case execution failures on our Jenkins (since build #930). The
problem is that configuration files may still contain this
category in 'logging' section (see [2], [3], [4]), and
osmo-bsc would refuse to start because of that.
[1] Id965295dfe04f8bd5ce831db70c86f67b8dc290b
[2] Ie2afacfc15589c26238214cddc00baaf80e993c1
[3] I266d6f6ed54d1457b1ca63b87fc1c29f6dd40caf
[4] If02272c08ba2df37d1295d09c104d11f96abbe1e
Change-Id: I111362d19aba325889bada5a46eea62343c30033
This dates back to a time where osmo-bsc_nat was in the same repository,
which is a long time ago.
Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
Link to the osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain
the 'cs7' client configuration.
Related: OS#2767
Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals)
Change-Id: I5b4973901f02046322b852fd9862517982d21bd9
If, as before this patch we call initCDKScreen() before
attempting to bind the socket, then the socket bind fails,
we exit and the terminal needs a reset.
Attempt to open the socket before initCDKScreen()
so we don't end up with a messed up terminal if the socket
call fails.
Change-Id: Ia5148d9ef386df314bc2837b3cb672150250bd2a
The measurement tools use libosmocore socket functions that will
use logging if the socket cannot be opened, but the tools did
not initialise logging, resulting in
Assert failed osmo_log_info logging.c:235
backtrace() returned 9 addresses
[.....]
Initialise logging so that we get a nicer and more informative
message, such as:
unable to bind socket:(null):8888: Address already in use
no suitable addr found for: (null):8888
Change-Id: Ib3b3558723682defcee22e7ea2d8bf5c2cff1278
Save OML failure reports from each BTS. Add a VTY command to display them
conveniently and optionally clear the list.
OsmoBSC> show bts 0 fail-rep
[2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
[2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY
Related: OS#1605
Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
Separate raw input parsing from handling the failure report. A follow-up
patch will use the new parsing function to print saved failure reports
to the VTY.
While at it, put struct tlv_parsed inside struct nm_fail_rep_signal_data
instead of a pointer, so we don't need an additional alloc. Also add
error handling to the abis_nm_tlv_parse() call.
Related: OS#1605
Change-Id: Ia51004faf620aa4d40435d58c70d758c9d0054d8
Use the extra bts pointer instead of mb->trx->bts, which does not point
to an allocated bts.
Related: OS#1605
Change-Id: Ie61512f5690763fa380bdf0e7fb4763dbda019d2
Refuse to start with mutually exclusive codec settings, unless
allow-unusable-timeslots is set in the network section of the config.
The checks were already implemented and fill the error log if the config
is invalid.
Related: OS#3739
Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
All timeslots are configured for full rate, so the codec list must also
have a full rate codec. Fix this error on startup:
"Configuration contains mutually exclusive codec settings -- check configuration!"
All other example configs don't have mutually exclusive codec settings.
Related: OS#3739
Change-Id: Iddac13c7d644ed57b6d9e6a57d23d88c01bd8b8e
OM2000 is not only used for the venerable RBS2000 family, but also
for the more modern RBS6000 family, specifically the DUG 20 GSM
baseband unit.
In RBS6000, there are some protocol extensions which are not yet fully
understood. However, we are understanding some bits around the MCTR
(multi carrier transceiver?), a new MO that appears to be present for
every physical RUS (Radio Unit) attached to the DUG 20.
Let's add what we have learned so far.
Thanks to Sylvain Munaut for his help with this.
Change-Id: Ib868358eca12b94c4fcca58e94ec8ab1a4edfda2
Calling osmo_tdef_vty_write() twice: with and without the 'timer '
prefix definitely looks like a bug. After setting any timer to a
custom (non-default) value, config_write_net() would generate an
incorrect configuration file:
$ osmo-bsc -c /tmp/osmo-bsc.cfg
There is no such command.
Error occurred during reading the below line:
T10 10
Change-Id: I5cc893fb2077bb21f1f661e30a7ab2af1b9bd561
The loglevels of DNM, DFILTER and DPCU are set to low, lets set them all
to NOTICE
Change-Id: I03a5426b341e9908ffc89240f97d6d3ea791b4a8
Related: OS#2577
Let's not just pass around the raw msgb, but also all other metadata,
such as the decoded parts of the TS 12.21 message.
As there's no current consumer of that signal, this creates no
compatibility issues.
Change-Id: I5d4d9d422b4e23348ffbe69c6e87a31d5574f90d
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I438ca0c4b8e7957d0f347a5b2f5c4cb93f9325e6
gsm_04_80_utils.c: In function ‘bsc_send_ussd_release_complete’:
gsm_04_80_utils.c:37:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations]
37 | struct msgb *msg = gsm0480_create_ussd_release_complete();
| ^~~~
CC gsm_data.o
In file included from gsm_04_80_utils.c:22:
/usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here
120 | struct msgb *gsm0480_create_ussd_release_complete(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The commit is not changing the existing logic/assumption: TID 0 should
not be in use by anything else at the point the USSD is generated.
Change-Id: I739158dec62cd5f0c2080fbb426af9c024baef87
Sylvain Munaut
Harald Welte
Oliver Smith
Vadim Yanitskiy
Eric Wild
Keith Whyte
Pau Espin
Philipp Maier