aboutsummaryrefslogtreecommitdiffstats
path: root/src/common/vty.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-31vty info: MS power levels in dBm are not negativeHEADmasterKeith1-2/+2
Change-Id: Ib928a1378bc00b8ccb0365e5536f010e1f8a3d43
2024-02-17Fix license headers.Harald Welte1-1/+1
We have licensed the code under GNU Afffero Public License, and state that in the first paragraph as well as in the link to the license. However, a paragraph in the middle stated "see the GNU General Public License", which is somewhat misleading. Let's fix that. Change-Id: I37e503b195fe43e1da42c080900504ca8e682e76
2023-12-21gsmtap-rlp: Add support for skipping generating NULL framesHarald Welte1-4/+13
If there's nothing to transmit over a CSD NT channel, both ends generate NULL frames. Let's add an option to suppress GSMTAP output for those, creating pcap files with less noise. Change-Id: I85a2159cfaa01bfb4205c1462e3a9dbda68e4bad Depends: libosmocore.git I2d9bd8eb4f0cd0f72c436996767b199429596917
2023-12-21Add GSMTAP encapsulation of RLP frames in CSD NT modeHarald Welte1-0/+22
In CSD (Circuit Switched Data) NT (Non-Transparent) mode, there are RLP (Radio Link Protocol) frames inside the modified V.110. wireshark alrady has a dissector for this, and we've introduced a GSMTAP type for RLP some time ago. So with this patch, we now generate such GSMTAP RLP frames. Change-Id: I6a258458822bcb3fe7290a9b9b3d104beecda219
2023-10-05Drop use of deprectated vty callback is_config_nodePau Espin Pedrol1-15/+0
While compiling: vty.c:169:3: warning: 'is_config_node' is deprecated: Implicit parent node tracking has replaced the use of this callback. This callback is no longer called, ever, and can be left NULL. [-Wdeprecated-declarations] .is_config_node = bts_vty_is_config_node, ^ Change-Id: I54c5aa5911611b181f80e76556b150f25dd5b60c
2023-09-19Move trx->rsl_link to trx->bb_transc.rsl.linkPau Espin Pedrol1-1/+1
The RSL link is configured/set up by the BBTRANSC NM object, hence move it to the appropiate substruct. Related: OS#5253 Change-Id: I62937cbd81c27274b9f5f70d454d5319a6898c7b
2023-09-19oml: Store RSL connect related fields in bb_transcPau Espin Pedrol1-1/+1
This is a preparation commit towards delaying connection of RSL tcp socket until the BBTRANSC object is OPSTARTed, as it is the case already in nanoBTS. Related: OS#5253 Change-Id: Ia571ec19e9e8f8a6d7c2554642aab0afe1b4b917
2023-07-12common: Make socket queue max. length configurablearehbein1-2/+19
Title refers to the maximum length of the osmo_wqueue used for the PCU socket connection. Related: OS#5774 Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
2023-06-28ECU in UL path: make it optional per vty configMychaela N. Falconia1-0/+26
Current osmo-bts-trx includes a provision for invoking ECUs from libosmocodec in the UL path from the channel decoder to the RTP output. This pre-existing implementation is counter to the spirit of 3GPP specs (a BTS should merely mark BFI conditions in its UL output, as opposed to actively modifying the frame stream with an ECU), inconsistent between different osmo-bts models (only in -trx and no others), and inconsistent even within osmo-bts-trx itself, where the link quality check in l1sap will sometimes suppress the output of the ECU - a quirk which the designers of the current mechanism most certainly did not intend. The solution decided upon in OsmoDevCall on 2023-06-21 is to make this ECU optional per vty config, and move it from the trx model to the common layer to resolve the inconsistencies. Implement the first part: make the ECU application optional per vty config. For backward compatibility with existing deployments, the new "rtp internal-uplink-ecu" setting is enabled by default on osmo-bts-trx but not on any other models. Related: OS#6040 Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
2023-05-27all models, HR1 codec: select RTP output format via vty optionMychaela N. Falconia1-0/+15
The new vty option "rtp hr-format (rfc5993|ts101318)" selects the RTP output format to be used for HR1 codec, consistently across all models. The default is set to match legacy behavior: ts101318 on osmo-bts-{lc15,oc2g,sysmo} and rfc5993 on osmo-bts-trx. On models where no legacy behavior is applicable, the default is set to rfc5993 as a forward-looking measure - see OS#6036. Closes: OS#5688 Change-Id: I168191874a062429a57904511a1e89e3f588732e
2023-04-21flags: group BTS_INTERNAL_FLAG_* into an enumVadim Yanitskiy1-3/+3
Change-Id: I4c7d9f6dce61f7690b86c3973b13ddb63cdace04
2023-04-18vty.c: Use already available tpp pointerPau Espin Pedrol1-1/+1
Change-Id: I54b4b995c3296d8a38ee72604dedbde77c5d0722
2023-04-11Move GPRS NSE under BTS SiteMgrPau Espin Pedrol1-1/+1
As per ipaccess expectancies and following TS 12.21. Change-Id: If44d8f256cab7b2660900cedfb0ed9fe67eb3420
2023-04-11Merge gsm_network into gsm_bts_sm and place gsm_bts under itPau Espin Pedrol1-56/+34
This way the data model in TS 12.21 (Figure 1) is followed, where there's a BTS Site Manager containing one or more BTS. In our case we only support 1 BTS (cell) so far. Change-Id: Ideb0d458ec631008223f861cf8b46d09524a1a21 Related: OS#5994
2023-04-06Move NSVC structs to be part of NSEPau Espin Pedrol1-4/+5
The NSVCs exist inside an NSE. Rearrange data model to have proper relations. Change-Id: I1cfe9366594836c622673d461ab8b2edd1a2b58a
2023-03-29common: implement rtp continuous-streaming modeMychaela N. Falconia1-0/+26
In some environments it is highly desirable for the RTP stream coming from each GSM call UL on a BTS to be fully continuous, without any gaps, with _some_ RTP packet emitted every 20 ms, even if there is no speech or SID frame to be sent in that frame time window. The present change adds an rtp continuous-streaming vty option which, when enabled, causes the BTS to emit RTP packets with a zero-length payload, instead of producing gaps in the RTP stream, when it has nothing else to send. Related: OS#5975 Change-Id: Ic0e2edf2ed90ba0ac6bee5e7d9629bf0255e256d
2023-03-28common/vty: Print AMR MultiRate Configuration in "show lchan"Harald Welte1-0/+14
It can be useful to introspect the current active AMR mode set. Related: OS#5944 Change-Id: I630af8c3835c2fcbea325c07db269d25e4e18f62
2023-03-28cosmetic: Replace %i with %dHarald Welte1-2/+2
Our linter will fail on %i, so let's replace any legacy occurrences with %d Change-Id: Ic302915bd5576d3e1f77668918f005d651daf21a
2023-03-07GSMTAP: print 'gsmtap-local-host' if not NULLVadim Yanitskiy1-0/+4
Change-Id: If4f5a419b5af3f185219a879dcb2abb4eea45f1c Fixes: f19f5331 "GSMTAP: allow configuring local address"
2023-03-04GSMTAP: allow configuring local addressMax1-0/+36
Change-Id: If047cbaf95b343ee115690bf7a724a8edc5df735
2023-01-30vty: Fix typo in symbol namePau Espin Pedrol1-1/+1
Change-Id: Ib33ffba348d6e9414eb904bfb7a2bd7ba2f55344
2023-01-03vty: Fix typo in write-config: osmux / local-portPau Espin Pedrol1-1/+1
The VTY command is "local-port", but write-config would write "port" instead, which would fail when re-reading the config file. Realted: SYS#6237 Change-Id: Id08530b626b0e69c3b3bb9d8bb9e16080a73e74d
2022-11-11update outdated vty copyright statementHarald Welte1-1/+2
Change-Id: Ia12a012c229f883286e96a90132adcc5e8c0c5da
2022-09-22vty: Print Osmux CID on lchans using OsmuxPau Espin Pedrol1-6/+12
Related: SYS#5987 Change-Id: Ide6edefda828e9ce04fbb60cf547857f322d5f40
2022-09-22vty: Fix SPEECH_MODE printed with hex prefix but dec valuePau Espin Pedrol1-1/+1
Change-Id: I597ff582f47b00d895611eae8a810fe3ebfe8339
2022-09-13Introduce Osmux supportPau Espin Pedrol1-0/+128
Related: SYS#5987 Requires: libosmo-netif.git Change-Id I632654221826340423e1e97b0f8ed9a2baf6c6c3 Change-Id: Ib80be434c06d07b3611bd18ae25dff8b14a7aad9
2022-03-09VTY: fix ambiguity in BTS specific command definitionsVadim Yanitskiy1-1/+1
Most of the BTS specific VTY commands restrict BTS number to '<0-0>', while bts_c0_power_red_cmd has '<0-255>'. This confuses libosmovty: OsmoBTS# bts ? <0-0> BTS number <0-255> BTS Number OsmoBTS# bts 0 ? % Ambiguous command. OsmoBTS# bts 0 c0-power-red 0 % Ambiguous command. Let's stick to '<0-0>', we don't support multiple BTS anyway. Change-Id: I937ac421143678b97627c1bc4fe573831ce097f6
2021-10-25[overpower] lchan_dump_full_vty(): print overpower stateVadim Yanitskiy1-0/+31
Change-Id: I052f1d68b27b2dc7203835b4a93d40c94b0c8d82 Depends: Ia28293a12de0af71f55e701fb65c46e905dae217 Related: SYS#5319
2021-10-22struct gsm_lchan: group ACCH repetition state fieldsVadim Yanitskiy1-3/+3
Change-Id: I2680c88f2a51b64f085a92233bc125338622babf Related: SYS#5114
2021-10-22cosmetic: s/repeated_acch_capability/rep_acch_cap/gVadim Yanitskiy1-6/+6
Shorter symbol names are easier to read. Change-Id: Ib1d51f91139b4c2fe794e37fc8543b2d7a9b9c07 Related: SYS#5114
2021-10-08vty: show interference level / band in 'show lchan'Vadim Yanitskiy1-0/+8
Change-Id: Ide45a0f7836bf35ffbe88070fa8367022311ca44 Related: SYS#5313
2021-09-14Support configuring TA loop SACCH block ratePau Espin Pedrol1-0/+16
Similar to what is already provided for power control loops. However, there's no existing way to communicate TA control parameters from the BSC to the BTS, so implement them locally in BTS vty. Related: SYS#5371 Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
2021-09-03MS Power Control Loop: Take C/I into accountPau Espin Pedrol1-5/+25
This commit extends existing MS Power Control Loop algorithm to take into account computed C/I values on the UL, received from MS. The related C/I parameters used by the algorithm are configured at and provided by the BSC, which transmits them to the BTS similar to already existing parameters. Using C/I instead of existing RxQual is preferred due to extended granularity of C/I (bigger range than RxQual's 0-7). Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance" Table 10.3) provides detailed information about expected target values, even different values for different channel types. Hence, it was decided to support setting different MS Power Parameters for different channel types. These MS Power Parameters are Osmocom specific, ie. supported only by newish versions of osmo-bts. Older versions of osmo-bts should ignore the new IEs added just fine. The new IEs containing the MS POwer Parameters are not send for non osmo-bts BTSs, hence this commit is secure with regards to running osmo-bsc against an ip.access BTS such as nanoBTS. Related: SYS#4917 Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca Change-Id: I5dfd8ff9ab6b499646498b507624758dcc160fb6
2021-08-18add osmo_tdef groups, exposing T timers on VTY configNeels Hofmeyr1-0/+5
We have two osmocom specific timers used in the BTS, X1 and X2. Expose those on the VTY configuration, as timer group 'bts'. This prepares for a subsequent patch, where I would like to add another configurable timer. This provides the basic infrastructure for that. Related: SYS#5559 Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
2021-07-19allow to configure multiple oml remote-ip addressesPhilipp Maier1-5/+48
At the moment we can only configure a single BSC in the BTS configuration. This also means that if this single BSC fails for some reason the BTS has no alternate BSC to connect to. Lets extend the remote-ip parameter so that it can be used multiple times so that an operater can configure any number of BSCs that are tried one after another during BTS startup. Change-Id: I205f68a3a7f35fee4c38a7cfba2b014237df2727 Related: SYS#4971
2021-07-15Make gcc 11.1.0 false positivies happyPau Espin Pedrol1-3/+3
Make gcc 11.1.0 false positivies happy After my system's gcc was upgraded, I get false positivies in a couple places. Let's initialize those to make gcc happy. """ //git/osmo-bts/src/common/vty.c: In function ‘lchan_summary’: //git/osmo-bts/src/common/vty.c:1881:23: error: ‘ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1881 | lchan = &ts->lchan[lchan_nr]; | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~ //git/osmo-bts/src/common/vty.c:1869:20: error: ‘trx’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1869 | ts = &trx->ts[ts_nr]; | ~~~^~~~~~~~~~~~~~~~~ //git/osmo-bts/src/common/vty.c:1852:34: error: ‘bts’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1852 | if (trx_nr >= bts->num_trx) { """ Change-Id: I93477142a5a4b3f3829b7398d6e564c127263596
2021-07-05Rename osmo dyn ts enums to contain SDCCH8Pau Espin Pedrol1-2/+2
They will gain support to be activated as SDCCH/8 soon too. Related: SYS#5309 Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68 Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
2021-07-01osmo-bts-trx: implement BCCH carrier power reduction modeVadim Yanitskiy1-0/+38
The BCCH carrier (sometimes called C0) of a BTS shall maintain discontinuous Downlink transmission at full power in order to stay 'visible' to the mobile stations. Because of that, early versions of 3GPP TS 45.008 prohibited BS power reduction on C0. However, in the recent 3GPP TS 45.008 there is a feature called 'BCCH carrier power reduction operation'. This is a special mode of operation, where the variation of RF level for some timeslots is relaxed for the purpose of energy saving. In BCCH carrier power reduction operation, for timeslots on the C0 carrier, except timeslots carrying BCCH/CCCH, the output power may be lower than the output power used for timeslots carrying BCCH/CCCH. In this case the maximum allowed difference in output power actually transmitted by the BTS is 6 dB. The power reduction operation can be controlled by the BSC by sending BS POWER CONTROL on the A-bis/RSL with the Channel Number IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the transmission power on inactive timeslots of the BCCH carrier. This is a non-standard, Osmocom specific extension, so indicate support of this feature to the BSC in the feature vector. Also add a VTY command to allow enabling/disabling the power reduction locally. Add some signalling notes to the A-bis/RSL manual. For more details, see 3GPP TS 45.008, section 7.1. Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98 Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716 Related: SYS#4919
2021-06-10vty: ensure all warning messages are prefixed with '%%'Vadim Yanitskiy1-13/+13
Change-Id: I23fc1cd8aa5725de06651f061c9fce6a022adfa8
2021-06-10common/vty: facilitate finding duplicate PHY/TRX associationsVadim Yanitskiy1-2/+7
In cfg_trx_phy_cmd(), use phy_instance_link_to_trx() and ensure that a PHY instance can be bound to a transceiver only once. Change-Id: I132e08fc496abef278b94254cebfac7a4285a7c2
2021-06-05[VAMOS] Implement the concept of 'shadow' timeslotsVadim Yanitskiy1-5/+16
Change-Id: I48b44b4df9ffb1cca105aebbd868c29b21f3b1d6 Depends: Ia0bd8695a3f12331b696fe69117189cdd48b584d Related: SYS#4895, OS#4941
2021-06-04[VAMOS] osmo-bts-trx: rework handling of Training SequenceVadim Yanitskiy1-1/+1
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts' is always initialized in oml_rx_set_chan_attr() during the OML bootstrapping, so there is no need for gsm_ts_tsc() - remove it. Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can apply a different TSC value during the RSL CHANnel ACTIVation. Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'. These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS' field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros. Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b Related: SYS#4895, OS#4941
2021-05-11[VAMOS] Merge bts_trx_init() into gsm_bts_trx_alloc()Vadim Yanitskiy1-1/+1
gsm_bts_trx_alloc() already does initialize some fields of the allocated 'struct gsm_bts_trx' instance, and having an additional function for initializing the other fields makes no sense. Note that I intentionally didn't merge a call to bts_model_trx_init() into gsm_bts_trx_alloc(), because this would break some assumptions regarding the order of initialization and cause regressions. This also allows us to not call bts_model_trx_init() from tests. Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
2021-05-09[VAMOS] struct gsm_bts_trx: fix the PHY instance pointerVadim Yanitskiy1-1/+1
First of all, there is no reason to use a void pointer because it's always 'struct phy_instance'. Also, no need to encapsulate this pointer into 'role_bts' because there are no other roles in osmo-bts (we used to have shared headers years ago). This commit also fixes a bug in test_sysmobts_auto_band(), where a pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst. Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
2021-04-30vty: fix the use of deprecated osmo_bts_feature_name()Vadim Yanitskiy1-1/+1
Change-Id: I67863da286b0fd1ec42088bce12d3c76e4be30ba Depends: I9dfdb5e81037b6000effbd340af4e5db0dcfd69c
2021-04-30Introduce ability to set socket priority of RTP socketsHarald Welte1-0/+18
This significantly simplifies setups in which not only the IP DSCP but also the IEEE 802.1Q PCP is to be set for RTP packets. Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e Related: SYS#5427
2021-03-01l1sap: add logging and VTY introspection for ACCH repetitionPhilipp Maier1-0/+58
At the moment osmo-bts is not looging much ACCH repetition related information. This makes testing ACCH repetition difficult. Lets add some debug output that informs the user when ACCH repetition is turned on or off. Lets also add an ACCH repetition status display to the show lchan VTY command. Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e Related: SYS#5114
2021-02-16GSMTAP: make remote host for Um logging configurable via VTYNeels Hofmeyr1-0/+40
So far, the only way to configure GSMTAP Um logging is to use the cmdline argument '-i'. Let's deprecate it, and add a VTY command to allow setting the remote host from configuration file. The legacy '-i' option, if provided, overrides the configuration file option, and will also appear in 'write file'. Change-Id: I17676a21c4e0c9cbc88f2c5c53a39c6c6c473ca1 Tweaked by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
2021-02-15vty: dont put a colon after vty_out in cfg_out macroPhilipp Maier1-1/+1
The cfg_out macro is used like a function in the code below its definition. This means a colon will follow after it is used. When the vty_out call in the macro already has a colon the final result will be vty_out(...);;. This works fine as long the macro is not used in one line if/else if/else constructs without curly braces {}. The compiler will interpret the double colon as two lines of code and run into an error then. Lets fix this by removing the colon from the vty_cout in the macro. Change-Id: I2c23c38ce892067add0f95f3e504a9c559e24519
2021-02-13GSMTAP: move 'struct gsmtap_inst' and masks to 'struct gsm_bts'Vadim Yanitskiy1-10/+14
Change-Id: I1c5cb8561dfdcbfd1b23ab28cf95aea7a18c7481
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 22:55:47 +0000