aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-05-24osmo-bts-lc15: Change LED behaviour to be the same as oc2gdaniel/oc2g-ledDaniel Willmann2-14/+31
It looks like the status LED on the sysmobts2100 never worked correctly since lc15bts-mgr expects osmo-bts-lc15 to create and manage /var/run/osmo-bts/state, but there is nothing to do so in osmo-bts. This patch copies the functions from oc2g to manage the state file in lc15. Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed Related: SYS#4493
2019-05-24osmo-bts-oc2g: Fix status LED responsibilitiesDaniel Willmann2-14/+3
osmo-bts-oc2g no longer modifies the status LED and instead leaves that to the bts manager. The service file now also creates a directory in /var/run needed for osmo-bts to communicate with oc2gbts-mgr. This status file is used by oc2gbts-mgr to figure out when the bts is operational. Related: SYS#4493 Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
2019-05-23cbch: Improve verbosity and extend logging; Always indicate BASIC/EXTD CBCHHarald Welte1-19/+35
Change-Id: I6c8f9fc6215b616371e46c1f4ca4e44b8c7ac096
2019-05-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte7-2/+137
This adds the final missing part to full CBCH support: * keep a tab on the current queue length for basic + extended CBCH * keep rate counters about the number of sent / transmitted SMSCB * send CBCH LOAD information via RSL to the BSC Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
2019-05-22sysmo: Fix "nominal power" / BS power display in VTYHarald Welte1-1/+1
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm, "milli-dBm", while trx->nominal_power is only whole dBm. We were missing the required divider of 1000 ever since Change-Id Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017. The good news is that this really only affected the VTY output and not any actual operational aspect of the system. Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68 Closes: SYS#4570
2019-05-21README.md: Mention LimeSDR as SDR deviceHarald Welte1-1/+1
Change-Id: I0ab5b5721861d7e29c66e849d9e0f4eec2e047e6
2019-05-21manual: SMSCB BROADCAST COMMAND has no limitations anymoreHarald Welte1-13/+1
We meanwhile support the SMSCB Channel Indicator IE and hence can send SMSCB on both BASIC as well as EXTENDED CBCH Change-Id: I63cc9c8c4c8c80440a61a0687e1f0cb97cc723b7
2019-05-21manual: We now support RSL CBCH LOAD INDICATIONHarald Welte1-1/+1
Change-Id: Iad7c364863b4de34bcded9f3c1e737ae0ed8e407
2019-05-21cbch: Keep SMSCB queue length counterHarald Welte3-14/+6
This avoids having to iterate the list to count the number of elements. Change-Id: I72c47affeb87c9b898bc2290dc7ed113945f1805
2019-05-21cbch: Support Extended CBCHHarald Welte6-37/+69
The logic for Extended CBCH are the same as for the Basic CBCH, we just need to * duplicate our related state * parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE * start to send data on the Extended CBCH (TB=4..7) Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429 Closes: OS#3535
2019-05-21cbch: Fix memory leak and send error message on invalid SMSCB commandHarald Welte2-3/+10
Change-Id: I411d1fb3693a2f7cf7bba3d38b1aaf276a4137ba Related: OS#4011
2019-05-21cbch: Implement support for DEFAULT messageHarald Welte2-13/+38
The BSC can not only send us each to-be-sent message separately, but it can also configure a DEFAULT message, which is then to be sent instead of the NULL message. Let's add support for this Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba Closes: OS#4013
2019-05-21cbch: Log every RSL SMSCB COMMAND with type and number of blocksHarald Welte1-3/+15
Change-Id: I20efe0aa5a67f011d6b6bead57236366c2f45ecf
2019-05-21cbch: Refactor get_smscb_block() / remove smscb_msg.next_segHarald Welte1-19/+25
There's no need to keep around a pointer to the next segment in a SMSCB message. The way how the multiframe structure is laid out (and how the tb number works), we can use the result of a modulo-division on the frame number to determine which of the segments/blocks inside a SMSCB message (page) we have to transmit. This also acts as a simplification in preparation of support for the SMSCB DEFAULT type. Change-Id: I48faa19fec4a0852e6112ca2faa98960c678d4c5 Related: OS#4013
2019-05-21cbch: Implement handling of "Schedule" messageHarald Welte1-2/+10
The first block of "schedule" messages must be advertised with a special sequence number coding, see Table 1 of 3GPP TS 44.012. Change-Id: I473edf698eba7ff5008f2fd1ec1776f0aa013858 Closes: OS#4012
2019-05-21RSL: Fix off-by-one error when parsing SACCH INFO IE in RSL CHAN ACTHarald Welte1-1/+1
This off-by-one error in length verification caused all SACCH INFO IE to be deemed invalid and hence any RSL CHAN ACT with that IE to be rejected. Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e Related: OS#3750
2019-05-21RSL: Reject RLL messages for lchans that are not active yetHarald Welte1-0/+8
The Radio Link Layer (RLL) messages only make sense when a given logical channel is active. If it isn't active, let's reject the messages with an RSL ERROR REPORT with cause "Message sequence error", wich according to spec means: "A message with an existing message type which is not possible according to the specification and to the state of the BTS is erroneous." Related: OS#3750 Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
2019-05-20rsl: Include Channel Nr and Link ID in Error reports whenever possibleHarald Welte1-13/+27
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we still should include it whenever possible to help error analysis. Related: OS#3750 Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
2019-05-20rsl: Send RSL Error Report in case of unknown/unsupported msg_typeHarald Welte1-1/+14
Send an RSL Error Report in case of unknown/unsupported msg_type, as describedi in section 7.3 of 3GPP TS 48.058. Related: OS#3750 Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
2019-05-20Revert "debian: create -doc subpackage with pdf manuals"Oliver Smith4-18/+2
This reverts commit ad7b8bee71e78e5a046b65898e181b8c48be3974. Unfortunately the osmo-gsm-manuals-dev package isn't working properly yet, therefore osmo-bts fails to build on nightly OBS now. My apologies for not testing enough in my own OBS namespace, before merging. I'll do that in the future. I'm reverting the patch now, so osmo-bts isn't missing from the nightly repository until I've fixed the osmo-gsm-manuals package. Change-Id: I89c2b92c8ae6331d6fff95a378fb58d82059af13
2019-05-20debian: create -doc subpackage with pdf manualsOliver Smith4-2/+18
Related: OS#3899 Depends: I7edb5093e5b58eb3b0f7af2376476db4026db735 (osmo-gsm-manuals.git) Depends: Ideeae4f7846fa5626fe2c1f5a77e07a3c6e626fe (osmo-ci.git) Change-Id: I4c184c62804c0b805a0a2425a5bd0312e94e49ab
2019-05-10README.md: remove OS#1865 from 'Known limitations'Vadim Yanitskiy1-1/+0
Neither the bug has been reproduced, nor the bug reporter did respond to request for configuration files. Change-Id: Ibc9db360be1380abaa9eef4bdf6e9a6d251670da
2019-05-10Remove 11-bit RACH support from 'Known Limitations'Alexander Huemer1-1/+0
Support for extended (11-bit) RACH has been implemented: - in libosmocoding: I85a34a82d5cd39a594ee89d91a2338226066ab5d, - and OsmoBTS: Ia28741603636406744e5e22ffff1fb7a9689955a. We also have a TTCN-3 test case called TC_pcu_ext_rach_content, see I8fe156aeac9de3dc1e71a4950821d4942ba9a253. Change-Id: I091f4fbd52c29c7d56ca392b8a1b872609829d81
2019-05-10osmo-bts-sysmo: fix: indicate BTS_FEAT_CBCH support on OMLVadim Yanitskiy1-0/+1
It seems osmo-bts-sysmo does support CBCH (Cell Broadcast), but for some reason it doesn't report BTS_FEAT_CBCH to the BSC. Change-Id: I42dd3f84c44c210d9255e17153372bf252f897a1
2019-05-09osmo-bts-trx: distinguish 11-bit Access Bursts by synch. sequenceVadim Yanitskiy1-43/+124
Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases, it was discovered that there are possible collisions when trying to decode a regular 8-bit Access Burst as an 11-bit one. This is exactly what we are doing in rx_rach_fn(): - calling gsm0503_rach_ext_decode_ber() first, - if it failed, falling-back to gsm0503_rach_decode_ber(). With default BSIC=63, the following 8-bit RA values are being misinterpreted as 11-bit Access Bursts: Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f According to 3GPP TS 05.02, section 5.2.7, there are two alternative synch. (training) sequences for Access Bursts: TS1 & TS2. By default, TS0 synch. sequence is used, unless explicitly stated otherwise (see 3GPP TS 04.60). According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability can be indicated by the MS using one of the alternative training sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme. In other words, knowing the synch. sequence of a received Access Burst would allow to decide whether it's extended (11-bit) or a regular (8-bit) one. As a result, we would avoid possible collisions and save some CPU power. Unfortunately, due to the limitations of the current TRXD protocol, there is no easy way to expose such information from the transceiver. A proper solution would be to extend the TRX protocol, but for now, let's do the synch. sequence detection in rx_rach_fn(). As soon as the TRX protocol is extended with info about the synch. sequence, this code would serve for the backwards-compatibility. This change makes the both TC_rach_content and TC_rach_count happy, as well as the new TC_pcu_ext_rach_content() test case aimed to verify extended (11-bit) Access Burst decoding. Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253 Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284 Related: OS#1854
2019-05-08handle NULL return from rate_ctr_group_alloc()Harald Welte1-0/+4
Change-Id: I2170e400e47369e9171af4c7361aa2177fea1174 Related: OS#3701
2019-05-07common/oml.c: fix: properly encode NM_ATT_SW_CONFIGVadim Yanitskiy1-6/+33
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
2019-05-07common/oml.c: refactor Get Attribute Response message generationVadim Yanitskiy1-67/+53
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
2019-05-05common/oml.c: fix broken debug print in down_mom()Vadim Yanitskiy1-2/+2
Change-Id: Ideac59946d50c6e06052a9590e02cfcfbf23d003
2019-05-05common/oml.c: use proper format specifier for uint16_tVadim Yanitskiy1-2/+1
Change-Id: I8f372a689b3c1cc2cf925654b2db44a0f4ee7603
2019-05-05common/oml.c: introduce and use both LOGPFOH and DEBUGPFOHVadim Yanitskiy1-51/+44
Change-Id: I9e9d6ccb88c9c9d35b2ce5778fa2580382704089
2019-04-24common/paging.c: fix unaligned pointer accessVadim Yanitskiy1-6/+22
Passing a pointer to a packed structure to tmsi_mi_to_uint() may result in unaligned pointer value. Found with clang-8. Change-Id: Ief69854973a098e6da7c05f4417dc11988edd777
2019-04-24common/rsl.c: fix unaligned pointers in rsl_add_rtp_stats()Vadim Yanitskiy1-24/+24
Found using clang-8: rsl.c:1646:7: warning: taking address of packed member 'packets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1646:28: warning: taking address of packed member 'octets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:7: warning: taking address of packed member 'packets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:28: warning: taking address of packed member 'octets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:7: warning: taking address of packed member 'packets_lost' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter' of class or structure 'ipa_stats' may result in an unaligned pointer value Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
2019-04-23common/rsl.c: fix size argument in memcmp() callVadim Yanitskiy1-1/+1
Found using clang-8: rsl.c:1607:93: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison] rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead? It looks more logical to compare the result of memcmp() against zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size. Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
2019-04-21common/l1sap.c: fix: add missing new line to a debug messageVadim Yanitskiy1-1/+1
Change-Id: I7c0dab255289a5847d1a0af009e8962e4410e5ca
2019-04-19common/oml.c: fix total length calculation in cleanup_attr_msg()Vadim Yanitskiy1-1/+1
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
2019-04-19common/oml.c: use proper OML object for Get Attribute ResponseVadim Yanitskiy1-11/+20
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
2019-04-19common/oml.c: use proper NACK reason in oml_tx_attr_resp()Vadim Yanitskiy1-1/+1
Change-Id: I482caa0747f81da2979bfbdbd22bd6962af728cd
2019-04-19common/oml.c: constify argument 'trx' of handle_attrs_trx()Vadim Yanitskiy2-3/+3
Change-Id: Id476d492b3c1d0c728fca9eb0fb2254512bdef72
2019-04-16pcu_sock: use %zu conversion specifier for printing sizeof() resultPhilipp Maier1-1/+1
When using %lu and sizeof() for printing the compiler may throw a warning. Lets prevent this by using %zu instead of %lu as conversion specifier. Change-Id: If5cb656537b1b73b9361a132801ab47ab7f8a709
2019-04-15oc2gbts_mgr: use osmo_init_logging2() instead of osmo_init_logging()Philipp Maier1-3/+3
The function osmo_init_logging() is deprecated, lets use osmo_init_logging2() as suggested. Change-Id: Iebc80cd1f77f10a879d4536d788377f522dd853f
2019-04-12common/pcu_sock.c: fix possible memleaks in pcu_sock_read()Vadim Yanitskiy1-1/+4
Change-Id: I58352e5f2b5715361c7089d0e134a42975171022
2019-04-08oc2gbts_mgr_calib: do not return NULL on integer functionPhilipp Maier1-2/+2
The functions oc2gbts_par_get_uptime() and oc2gbts_par_set_uptime() try to return with NULL, but both functions are declared as int. Lets return -EINVAL instead. Change-Id: I63b61be2940c59b221089d3d1501371b0116d89a
2019-04-08oc2gbts_mgr_calib: don't use fsync() on *FILE pointerPhilipp Maier1-1/+1
fsync() takes an integer file descriptor but we have a *FILE pointer here. Lets use fileno() first to convert the integer file descriptor to a FILE pointer. Change-Id: I46ffd8c680ba0b445cbbd133d5ce92b79e3d8d87
2019-04-08l1_if: add include for missing header filePhilipp Maier1-0/+1
the function bts_cbch_get() is used in l1_if.c. The function is declared in cbch.h. Lets include this header file in order to be complete. Change-Id: I95d7e89eed969dd5b3ccff0eebcc6c568196a97d
2019-04-01common/oml.c: fix: properly push abis_nm_ipa_magicVadim Yanitskiy1-3/+3
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
2019-03-27Forward GPRS SUSPEND REQ from DCCH to PCU socketHarald Welte4-9/+73
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15, a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if it wants to suspend GPRS services. The BSS is now responsible to somehow forward this to the SGSN. As the Gs interface between BSC and SGSN is both optional and doesn't have any provision to forward this message, we have to send it over to the PCU so it can use regular BSSGP signaling to inform the SGSN of the SUSPEND REQUEST. This patch requires libosmocore Change-Id I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of struct gsm48_gprs_susp_req. Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f Closes: OS#2249
2019-03-27oml: use oml_tx_failure_event_rep() instead of signals to SS_FAILPhilipp Maier4-17/+10
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
2019-03-27oml: use oml_tx_failure_event_rep() instead of oml_fail_rep()Philipp Maier6-34/+26
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
2019-03-27main: remove wrong call to oml_fail_rep() on SIGUSR1/2 and SIGABRTPhilipp Maier1-3/+0
SIGUSR1/2 and SIGABRT should not trigger a failure event report on OML since we only use it to get an intermediate talloc report. (In case of SIGUSR1/2 without leaving the process.) Change-Id: I99e637496afff2530425b89c6e9befc76db24906
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 06:37:39 +0000