Age | Commit message (Collapse) | Author | Files | Lines |
|
I originally assumed that after a complete scan with llist_for_each_entry
the loop counter would be either NULL or a valid entry. That's just not
the case.
Fixes: CID#210256
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Iad647b74771c4ac406a88effd371ed7748c8847e
|
|
There is no bb_transc oject.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I34bb808cd21575ff25d36e6df028b140935a008f
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I1ca4a6ac6ec2f4e40c8421f31871d9c9e5ac5de5
|
|
The OM2K link "per-trx" only comes up after MCTR is setup. So that means
we need to wait for it before trying to boot the TRX itself.
He we simply apply a "dumb" 5 sec timeout as this is the most reliable
way I found to get this working reliably.
Tracking the link state proved difficult and unreliable:
- Multiple TRX can be present with their link coming up in random
order.
- They can already be up at the start (BTS already initialized from
a previous boot) and so the link may actually come up, down, and
up again.
- All of theses transitions might happens before/after we get to the
OM2K_BTS_S_WAIT_TRX state depending on how the LAPD timeout
expire, if the BTS config was actually changed or not and how much
time it takes to apply the new config.
So all in all, what we must do is wait for the link to stabilize ...
hence just waiting 5 second.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I55a06e08b9c52ff6e97e8c72f2d55770809eba51
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I1caafa2e87c6198bf3b1a77f0fa1edc774deeef9
|
|
Currently only supports a single MCTR with fixed configuration
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I776b0016837e018500ef69acb2f30a274008818e
|
|
Starting from G12R13 the MCTR swiches to BSC controlled mode. And
although we think we know how to configure it (via MCTR Conf Req),
something doesn't work right and the timeslot configuration is not
accepted. (TS Conf Result shows "Data not according to request").
So as a workaround for now, we use this version of the protocol where
we don't configure the MCTR (it's in "BTS controlled mode") and with
this protocol, the BTS accepts our timeslot config and we can bring
the system up.
This commit add a generic option to limit either OML or RSL IWD
version to any value. It also keeps track of the actual negotation
version so we can react to it in other places of the code.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65
better version limit
Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ief9093706d6ca20f8162ca541dcc4669c13e2cbc
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I9417f433f759ce21b8b6e0b74cd686df5388f8c5
|
|
* 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
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ic2a84ea406e9a39332313d63b27d73f334d4e0a0
|
|
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
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I4b4389fd2e7bf0b3078b8ff60f6ea109114a4475
|
|
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
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ida92c9ca59a608854737ba9e330a5394cceff0fe
|
|
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
|
|
Change-Id: I5e3eaf3dee97e2edcd80b20c3acf85bd89b40cdc
|
|
Make various internally used timers negative, to indicate that they are
Osmocom specific. A follow-up patch will make them configurable.
Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I5a385614fc670946f83ea79cc176c2d448675672
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Id1171a151773182bb5cdc14c023c3637fb9ad0bc
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3983ba9f06c48d515a7b739b00f05023af632267
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I6d90554a54baa78f454281a486e4b5e95784fdee
|
|
/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
|
|
Change-Id: I491d319f2829902a8c449db515f928cf7e480482
|
|
The VTY command parser would not allow values other than 0 or 1.
Change-Id: Ic29fac12414f1821702759a9f5260e941c9868b5
|
|
Change-Id: I344ea61df8cc910d9b524c9b2f0e03721eefe56c
|
|
Change-Id: Ib21c30041508a9ec9afda56bda95bddf4d665bc8
|
|
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
|
|
Change-Id: I8eddc47353d6afd756865321a9e97f6cee4ce2d7
|
|
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
|
|
Change-Id: I8d807ffc4571f2954e3d1083da673dc1235e7687
|
|
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
|
|
Change-Id: I27bcde8d36dcf8daa9d24b4b581c9526b73cb35e
|
|
Change-Id: I00a183078679db50567286a78c9e4f9afa3466c6
|
|
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
|
|
Related: OS#2767
Change-Id: Ideb137f19d19144d35b05eb036098045bbb18d64
|
|
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
|
|
Fail parsing osmo-bsc.cfg if the AMR modes are not in order or not
unique.
Related: OS#4199
Change-Id: Ic2f3690396fb0425f6b358e1e21a8b8b56eb3ae0
|
|
Do not use 0 as default, as it is reserved for signalling.
Related: OS#4408
Change-Id: I499272f16aadd89f3bdb5d749e3e4f9e07056c15
|