aboutsummaryrefslogtreecommitdiffstats
path: root/tests/misc/misc_test.c
AgeCommit message (Collapse)AuthorFilesLines
2020-06-11Do not mix public and private BTS features, use libosmocore's APIVadim Yanitskiy1-4/+4
It was a very bad idea to mix "public" BTS features, that are reported to the BSC via OML, and those features, that are used locally (and exclusively) in osmo-bts. Why? At least because we already have the BTS feature manipulation API in libosmocore, that is used by osmo-bsc, but for some reason not by osmo-bts. New features added to libosmocore would clash with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP. So what this change does can be described as follows: - remove duplicate definition of the "public" features, - use libosmocore's API for the "public" features, - separate both "internal" and "public" features: - the "public" features continue to live in bitvec, - the "internal" features become flags, - s/BTS_FEAT/BTS_INTERNAL_FLAG/g. Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
2018-04-04use osmo_init_logging2() with proper talloc ctxNeels Hofmeyr1-2/+7
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all callers of bts_log_init() passed NULL as category string, so all it ever did was call osmo_init_logging(). The bts_log_info is already declared in the .h. Here and there also define a proper talloc root context instead of using NULL. Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
2018-02-22bts: use feature list instead of speech codec tablePhilipp Maier1-15/+15
osmo-bts has a table of pchan/channel mode combinations for every bts. This table models the codec capabilitys of the BTS hardware. However, having the speech codec apabilities modeled inside the BTS feature list would be much more comfortable and since the feature list is communicated back to the BSC we would get the codec capabilities inside the BSC domain as well. - remove the pchan/channel mode tables - set speech codec variants for each BTS type - fix bts_supports_cm so that it queries the feature list Change-Id: I977dc729ba856631245aedf76afd48eac92166f7
2018-02-19rsl: do not allow MODE MODIFY request with unsupp. codec/ratePhilipp Maier1-0/+26
When the BSC sends a MODE MODIFY request with an unsupported codec, the BTS must respond with a negative acknowledge. Currently the codec parameter is not checked at all, which may lead into malfunction or crash of the BTS. - Introduce a mechanism to check the codec/rate against a table that is set up in the phy specific code. - Add tables with supported codec/rate combinations for octphy, sysmobts, and trx. Change-Id: Id9b222b7ab19ece90591718bc562b3a8c5e02023 Related: SYS#3212
2017-05-09Prepare for extended SI2quater supportMax1-1/+1
SI2quater support as per 3GPP TS 44.018 will require chnages to the way System Information is stored because it uses 1:n instead of 1:1 mapping between SI type and generated SI content. This should not affect other SI types though. To facilitate this transition: * convert the code to always use GSM_LCHAN_SI helper instead of accessing buffer directly * move duplicated code to inline function * add logging for buffer truncation and corresponding length values Requires I74e4e3cb86364cec869a1472a41b4a95af0d50dd in OpenBSC. Change-Id: Ie97be6ead6ce6d2d425fbfac8429bb90afb95acc Related: RT#8792
2015-01-10misc: Fix up testcase after 5a03e129a633637d0a6b57b3b5aa6d6596b938feHolger Hans Peter Freyther1-1/+1
In 5a03e129a633637d0a6b57b3b5aa6d6596b938fe we generalized the structural parser so we need to update the expected behavior of that routine.
2014-07-31sysmobts: Add testcase for ETSI/12.21 messageHolger Hans Peter Freyther1-0/+15
2014-07-31sysmobts: Extend the testcase for a Osmo message as wellHolger Hans Peter Freyther1-16/+36
2014-07-31sysmobts: Verify the structure of IPA and OML messagesHolger Hans Peter Freyther1-0/+75
Extend the router to verify that the message received is properly encoded. The code can deal with the basic structure of ETSI OML and vendor specific messages for ip.access and the osmocom project.
2014-05-22common: Ignore "si.valid" outside of _MAX_SYSINFO_TYPEHolger Hans Peter Freyther1-0/+58
Limit the range from 0 to (_MAX_SYSINFO_TYPE - 1) instead of 0 to 31. This way we will never access the lchan->si.buf[] out of bounds. This is only a theoretical issue though as the code filling the lchan->si.buf for the SACCH will not have valid >= _MAX_SYSINFO_TYPE. Add a small regression test to check we still schedule all SIs. Fixes: CID 1040765