summaryrefslogtreecommitdiffstats
path: root/src/host/layer23/include/osmocom/bb/common
AgeCommit message (Collapse)AuthorFilesLines
2023-04-26layer23: Use GSM23003_IMEI(SV)_NUM_DIGITS from libosmocorePau Espin Pedrol1-2/+2
Change-Id: I12a96043947c0f5366f550944a4df5edd2fd2c9d
2023-04-26layer23: Use OSMO_IMSI_BUF_SIZE from libosmocorePau Espin Pedrol2-5/+6
Note: GSM_IMSI_LENGTH was 16 octets, and OSMO_IMSI_BUF_SIZE is 17 octets. Probably a bug in old osmocom-bb code since that code predates the one in libosmocore. Change-Id: I295444bb3b75ed236ea4af5563d9a9c9e590cab7
2023-04-26layer23: Use GSM_RESERVED_TMSI from libosmocore everywherePau Espin Pedrol1-1/+1
Change-Id: Ib9483b8ae4067994aef523291733ae706ffabe7a
2023-04-25layer23: Decouple SIM events from MMR eventsPau Espin Pedrol1-0/+12
let the specific app handle the events generated from the subscriber/SIM. All the MMR specific code can for now stay in mobile/ while SIM support can be in common/ without violating layers (common/ calling functions in mobile/). Change-Id: I473887e0fd9338d76a69a9774145a04575f14b64
2023-04-25layer23: Move testsim node to common/Pau Espin Pedrol1-0/+2
Change-Id: Ife34403a715809b43e7a4cd5ce4dec8616fc08af
2023-04-24layer23: Use libosmocore API to validate IMSI stringPau Espin Pedrol1-1/+0
Change-Id: I2d4737dabcfb83a7b675c35ad973029a36658d5b
2023-04-24layer23: Move vty_notify() to common/Pau Espin Pedrol1-0/+2
Change-Id: Ic0a98e66adffa9fefeee6e69a4b5c691e0e9c789
2023-03-30modem: initial SM layer support through libosmo-gprs-smPau Espin Pedrol1-0/+1
Depends: libosmo-gprs.git Change-Id I9b4a9a6364f7799540475e7e1d10ab2310768281 Related: OS#5501 Change-Id: I9476d93954c7dc348e6f97ca89eaa651f802f9a0
2023-03-17layer23: implement Rx/Tx API for GPRS related messagesVadim Yanitskiy2-0/+13
Change-Id: I87950e893ef96ff8328f43f1548111aa9f66439b Related: OS#5500
2023-03-16layer23/{mobile,modem}: fix segfault on VTY connectionVadim Yanitskiy1-1/+1
It was a mistake to call vty_init(), passing it a pointer to the vty_app_info structure allocated on the stack, because it gets overwritten when the calling function _vty_init() returns. Change-Id: I75843a964254243c70bedcf8ff97d854107ee21a Fixes: 9feb5057 "layer23: refactor the application API concept"
2023-03-15layer23: modem: Depend on libosmo-gprs-gmmPau Espin Pedrol1-0/+1
Related: OS#5501 Change-Id: I82a2b9c043eae42435ca781689fc3381e7a31bea
2023-03-13layer23: refactor the application API conceptVadim Yanitskiy1-3/+4
With this set of changes we have a cleaner l23 app architecture: * struct vty_app_info: all l23 applications must define this struct; * struct vty_app_info: *cfg_supported() becomes a mask of L23_OPT_*; * struct vty_app_info: explicitly set L23_OPT_* in all l23 apps; * drop l23_app_info(), there can be only one vty_app_info per an app; It's no more needed to obtain the vty_app_info by calling a function and checking the returned value against NULL everywhere. This kind of information is rather static (not dynamically composed) and needs not to be encapsulated into functions. Change-Id: I89004cd5308927305f79b102f7b695709148df6d
2023-03-08mobile: allow configuring local GSMTAP addressMax1-0/+1
Change-Id: Ia1555db653cf0bb20af74617f33aad31c971bfdb
2023-02-20Run struct_endianness.pyOliver Smith1-0/+30
Ensure there is no diff to prepare to run this in CI. Related: OS#5884 Change-Id: I617c967c5f34c0be2cf6fd43ceb1af17897f2bf1
2023-02-02layer23: Support configuring GSMTAP through VTY in l23 apps.Pau Espin Pedrol2-0/+29
This allow all l23 apps supporting L23_OPT_VTY and L23_OPT_TAP to dynamically configure gsmtap through a "gsmtap" VTY node: gsmtap remote-host 127.0.0.1 lchan sacch lchan lsacch lchan sacch/4 lchan sacch/8 lchan sacch/f lchan sacch/h lchan unknown lchan bcch lchan ccch lchan rach lchan agch lchan pch lchan sdcch lchan sdcch/4 lchan sdcch/8 lchan facch/f lchan facch/h lchan pacch lchan cbch lchan pdch lchan pttch lchan cbch lchan tch/f lchan tch/h category gprs dl-unknown category gprs dl-dummy category gprs dl-ctrl category gprs dl-data-gprs category gprs dl-data-egprs category gprs ul-unknown category gprs ul-dummy category gprs ul-ctrl category gprs ul-data-gprs category gprs ul-data-egprs VTY cmd "lchan" enables/disables tapping on general channel types, while "category" allows fine-grained selection of messages being tapped within the enabled lchan which would tap those messages. Change-Id: I2582a1633d37d350a7f4c2bb5e03793bdf46e839
2023-01-30modem: Initial integration of libosmo-gprs-rlcmacPau Espin Pedrol1-0/+1
This commit places code to forward unitdata LLC<->RLCMAC. Depends: libosmo-gprs.git Change-Id I1870fa6a264612c5a669bfb832e6e8c0a892cb74 Related: OS#5500 Change-Id: I0e628d9ddaa5ad6a205f07746d4176d1b8df7eb0
2023-01-30modem: Initial integration of libosmo-gprs-{llc,sndcp}Pau Espin Pedrol2-0/+18
Change-Id: I820328009ccdd1f8112aeb163efa064ec1465d2a
2023-01-19layer23: Initial integration of tun devicePau Espin Pedrol3-0/+12
Use the new tundev API from libosmocore to create tun devices for each configured (and enbled) APN. No address nor routes are yet set on the tun devices because we still lack GMM/SNDCP/LLC/RLCMAC layers to negotiate them. A follow up patch will add some code to interact with the SNDCP layer. Depends: libosmocore.git Change-Id I3463271666df1e85746fb7b06ec45a17024b8c53 Change-Id: I86cac406843157aa2e51727cf8ccac9804d7961d
2023-01-19layer23: Introduce APN VTY nodePau Espin Pedrol4-0/+69
This commit adds an initial set of VTY commands to manage APN configuration and set up, which is used by the modem app. The sample modem.cfg file is updated to showcase how to configure APNs. The app doesn't do anything with them yet. A follow up patch will add code to create tun devices for each configured APN. Change-Id: I7b4eaa0de428b418bb1d89bd544694e89beb3e6e
2023-01-17layer23: Use shift operand to define bitmask valuesPau Espin Pedrol1-5/+5
Change-Id: I22e2f543c077a4df4623c5e3bd44f8f068596baf
2023-01-17layer23: ms.h: Use enum type in ms->shutdownPau Espin Pedrol1-2/+2
Change-Id: I5456f7a8675e6ab620bc93b56e2c4ad22d3900e8
2023-01-17layer23: Let each app allocate its ms obj and start layer2 when neededPau Espin Pedrol2-4/+6
This allows apps to allocate the objects as they please: simple apps can statically allocate it at startup. Others may want to allocate them through VTY. Some apps may also want to dynamically start and stop layer2. Change-Id: I32f99df76a5513eff9df5489d28d60aedf96dec3
2023-01-17layer23: Move layer2-socket VTY command to common/Pau Espin Pedrol3-0/+7
This allows configuring layer2-socket for other apps than mobile, like the "modem" one. Change-Id: If7419f8fc54a54eed68a076968d93dba5ac977b7
2023-01-17layer23: Move '(no) shutdown' VTY code to common/vty.cPau Espin Pedrol2-2/+26
Change-Id: Ib5c9b6f3efa255d67980945db9f98dd8a112af0e
2023-01-16layer23: Move settings.{c,h} under common/Pau Espin Pedrol3-2/+186
Some of those can be reused by other apps (like modem). Change-Id: I0a741b2384195d512fdc49eda6762241f385b1f1
2023-01-16layer23: Move subscriber.{c,h} under common/Pau Espin Pedrol3-1/+121
Some of those can be reused by other apps (like modem). Change-Id: I3727e40bcc9a4ee93aaf2c4ced070cc789653e80
2023-01-16layer23: Move support.{c,h} under common/Pau Espin Pedrol3-1/+124
Some of those can be reused by other apps (like modem). Change-Id: I3c5af4db8e603aa004d0b6410b09b5143173b874
2023-01-16layer23: Initial VTY framework to share VTY code between appsPau Espin Pedrol2-0/+26
A small layer23 framework is added which allows apps to easily share/reuse VTY commands while giving some flexiblity to add new per-app specific configs/cmds, since not all commands may be relevant for all apps. Some of the mobile app code is moved to common, and sample infra is added to modem app. Future commits will most probably keep moving more stuff mobile->common and then reusing those in modem app, as found needed. Change-Id: Iabfb3129199488d790b89884bc1e424f2aca696f
2023-01-16layer23: Initialize osmocom_ms further in common codePau Espin Pedrol1-1/+1
Change-Id: Ic629cf229167ddd4c533a2abf1b82ad78d1144a9
2023-01-16layer23: Move osmocom_ms to a separate filePau Espin Pedrol3-102/+105
This way we can extend its API and contents more easily, and keep most of it together in one place. Change-Id: Icb4891cc1e4a0ecb5f09cb8a84b0ebe1b91a46b8
2023-01-16layer23: Add missing header dependencies to several filesPau Espin Pedrol3-0/+5
Change-Id: I9819b12d1c24f6ee197daa887452b09418d689e8
2023-01-16layer23: common/sim.h: Fix missing pragma oncePau Espin Pedrol1-0/+1
Change-Id: Icebe803c7896347915ed72b80d5504d15d717ef3
2023-01-13cosmetic: layer23/include/common/Makefile.am: Set one item per linePau Espin Pedrol1-3/+15
Change-Id: I2e385d403bd37ad9491fd421509fe7e4104225f9
2023-01-13layer23: Add initial VTY support for l23_appsPau Espin Pedrol1-1/+3
Initial VTY "boilerplate" code for modem app is already added in this commit as a showcase what's needed by an app to have the VTY config file read and VTY interface initialized. Change-Id: Ife3a3373e5a9c0c8e5959ac714e140e72d6c363a
2023-01-13layer23: Move extern declaration of l23_ctx to l23_app.hPau Espin Pedrol1-0/+2
This way all apps can access it. Change-Id: I570d31cc4014b54b47b11a3a52791f62c999cad8
2023-01-13layer23: Introduce l23_app_start() API stepPau Espin Pedrol1-2/+6
This commit is a preparation towards having shared VTY infrastructure for layer23 apps. Having 2 steps (first init(), then start()) allows the apps easily struct allocation & initialization, and then start doing work after VTY config has been read. Change-Id: I1d232809764962f82fee86159bc61cdbc3eb3c48
2023-01-12cosmetic: layer23: Drop unnecessary space before function pointer argumentsPau Espin Pedrol1-2/+2
As requested by linter. Change-Id: I87e1857722b9181d0187bdeabe3fa1f4e63463d0
2023-01-07layer23/sysinfo: implement decoding of SI13 Rest OctetsVadim Yanitskiy1-4/+45
Change-Id: Ia6ff7d4e37816c6321b54c1f7f8d7110e557f8c5 Related: SYS#5500
2023-01-02layer23/sysinfo: update coding style, make pointers constVadim Yanitskiy1-24/+24
Change-Id: Ia518251eae1b45ad573d076d97cba83ed25ea9ea Depends: libosmocore.git Ide9110b984d3302aec6b439c563eb10e2dcdec9e
2022-12-01mobile: integrate GAPK based audio (voice) I/O supportVadim Yanitskiy2-0/+5
This change introduces a new feature to the mobile application - audio I/O support, which allows the user to speak right from the host side running mobile through its ordinary mic and speakers. The audio I/O is based on libosmogapk [1][2], which in its turn uses the ALSA sound system for the playback and capture. This is a new optional dependency of mobile, which is automatically picked up if available during the build configuration. Whether to depend on it or not can be controlled using '--with-gapk-io'. The API offered by libosmogapk implies to use the processing chains, which generally consist of a source block, several processing blocks, and a sink block. The mobile app implements the following chains: - 'pq_audio_source' (voice capture -> frame encoding), - 'pq_audio_sink' (frame decoding -> voice playback). both taking/storing TCH frames from/to the following two buffers: - 'tch_fb_ul' - a buffer for to be played DL TCH frames, - 'tch_fb_dl' - a buffer for encoded UL TCH frames. The buffers are served by a new function gapk_io_dequeue(). [1] https://gitea.osmocom.org/osmocom/gapk/ [1] https://osmocom.org/projects/gapk Change-Id: Ib86b0746606c191573cc773f01172afbb52f33a9 Related: OS#5599
2022-08-21layer23: explicitly set chan_nr / link_id in L1CTL_RACH_REQVadim Yanitskiy1-2/+3
The underlying L1 implementation uses both chan_nr and link_id to determine a logical channel for sending an Access Burst. If not set (both 0x00), RSL_CHAN_RACH is assumed. Indicate it implicitly. Change-Id: Ia40f67920bd712e572b8ea5219eb83064106bd5d
2021-12-14treewide: remove FSF addressOliver Smith2-8/+0
Remove the paragraph about writing to the Free Software Foundation's mailing address. The FSF has changed addresses in the past, and may do so again. In 2021 this is not useful, let's rather have a bit less boilerplate at the start of source files. Change-Id: I73be012c01c0108fb6951dbff91d50eb19b40c51
2020-07-31layer23/mobile: implement handling of TCH test loop commandsVadim Yanitskiy1-1/+1
For more information, see 3GPP TS 44.014, sections: - 5.1 "Single-slot TCH loops", and - 8 "Message definitions and contents". This feature has nothing to do with the Mobility Management, so let's handle GSM48_PDISC_TEST messages in the Radio Resources layer implementation (gsm48_mm.c -> gsm48_rr.c). Change-Id: If8efc57c7017aa8ea47b37c472d1bbb1914389ca
2019-10-17Fix common misspellings and typosMartin Hauke1-1/+1
Change-Id: I962b42871693f33b1054d43d195817e9cd84bb64
2019-05-22layer23: Fix 'make distcheck'Harald Welte1-1/+1
Change-Id: Ic48e240ee1484aaa793af23c62a24d2949900b86
2019-02-02common/osmocom_data.h: use proper type for SAP card statusVadim Yanitskiy1-1/+4
Change-Id: I7388ec60ca2dff59c0a0e3fdacf5a3af0c244c73
2019-01-15layer23/sap_interface.c: reimplement (BT)SAP interfaceVadim Yanitskiy5-24/+96
The (BT)SAP (Bluetooth SIM Access Profile) is a part of Bluetooth specifications, that defines the protocol and procedures that shall be used to access a smart card (usually GSM SIM) via a Bluetooth link. The profile defines two roles: - Server - the side that has direct access to a smart card. It acts as a SIM card reader, which assists the Client in accessing and controlling the smart card. - Client - the side that accesses and controls the smart card inside the Server through the connection with Server. Typical examples of a Server are a simple SIM card holder or a portable phone in the car environment. A typical example of a Client is a car phone, which uses a subscription module in the Server for a connection to the cellular network. OsmocomBB implements the Client role providing abstract SAP interface API to the higher layers. Instead of Bluetooth, a UNIX socket is used to communicate with a Server. The previous implementation of (BT)SAP interface was incomplete and hard to maintain. This change (re)implements it almost from scratch on top of the Osmocom FSM framework. Besides that, the most significant changes are: - The implementation is separated into three parts: - sap_interface.{c|h} - public SAP interface API, - sap_proto.{c|h} - SAP protocol definition, - sap_fsm.{c|h} - SAP FSM implementation. - Both 'sap_message' and 'sap_param' structures follow the SAP message format definition according to 5.1 and 5.2. - The message parsing is done more carefully in order to prevent buffer overflow and NULL-pointer dereference. - Introduced public API for getting / adding message parameters, and checking the ResultCode. - Introduced public API for opening / closing a connection with the server, powering on / off and resetting the SIM card, sending ATR and APDU. - Introduced a call-back for handling the response message. - Card reader state is also a part of the public API. The new implementation was tested against softsim [1]. The only limitation is Server-initiated Release, that allows the Server to 'ask' a Client to release connection as soon as communication with the smart card is finished. This is not implemented (yet), and leads to immediate release. [1] https://git.osmocom.org/softsim/ Change-Id: I77bb108615bb2c94c441568f195b04e0a5421643
2019-01-07layer23/sap_interface.c: separate protocol definitionVadim Yanitskiy3-84/+95
Change-Id: Iad9b3d88b02cc7ec4cf64483bbc85e3a61c9ad10
2019-01-07layer23/include/Makefile.am: add missing headerVadim Yanitskiy1-1/+2
Change-Id: I0a379718eeb7db63696cabd5689e0625fb85d85e
2019-01-07layer23/sap_interface.c: avoid using 'osmo' prefixVadim Yanitskiy2-8/+8
The 'osmo' prefix is usually used by libosmo-* symbols. Change-Id: Id37d8553c2f2c20012fb1b729967b92a9a03f612
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 00:22:39 +0000