With this patch, during VTY config the SIM type is selected, and the app
calls a generic gsm_subscriber_insert() API which will take of
internally initializing and starting whatever specific-backend setup is
needed.
Change-Id: I5aa34ae297ec0114e1d2355d59fdd77b43b35464
This way the gsm_subscr_testcard() API looks similar to that of other
backends (sim, sap). Furthermore, the callers of the API don't need to
pass tons of params. This is important since in the future there will be
more params (eg. gprs related ones), so it makes no sense to keep
increasing the param list in there.
Change-Id: I07fc5a6ed59e65d6b96c0a2f87b1f496d39ad76d
This way it becomes clear those fields are related only to test_sim
module, and not some general "test" feature.
Change-Id: I56830c6b905bcbce7e19adbfe5427fd826d15e8c
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
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"
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
Several functions and data structures in mobile app are refactored to
follow more closely the l23_app API and structures. These movements
allow starting to use already some shared infrastructure defined under
layer23/common.
This is not a full migration to l23_app, since mobile still keeps a
separate main() with a few extra code. This commit is rather a step
towards an eventual merge of mobile's main.cpp into
layer23/common/main.c
This is a preparation commit to later one adding gsmtap VTY configuration
to all l23 apps.
Change-Id: I3141b6cb4a0482970f434180ef8dda3af1d4aa0c
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
Follow-up commits will add some extra checks we want to have in config.h
Include config.h in files using PACKAGE_VERSION.
Change-Id: Ic779a3168012780feef8d173371387d09d383bfd
The only caller of gsm_settings_exit() is in app_mobile so far, which is
the only app supporting/using lua scripting so far.
Change-Id: I634a4514ead9d064e7509c3fbbb3a2c89c7f3a56
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
This way we can extend its API and contents more easily,
and keep most of it together in one place.
Change-Id: Icb4891cc1e4a0ecb5f09cb8a84b0ebe1b91a46b8
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
Since the mobile application is potentially able to maintain
multiple MS instances, it's better to have a possibility to
choose an MNCC (Call Control) handler per each MS separately.
This change removes the command-line option '-m', which was used
for enabling the external MNCC. Now it's possible configure the
MNCC handler for each MS via the VTY interface and settings.
The following MNCC-handlers are available:
- internal - built-in MNCC-handler (default);
- external - external MNCC-handler via UNIX-socket (e.g. LCR);
- dummy - dummy handler without CC support.
Change-Id: I2df91c7a79ba5c39bc6ceae900ef649129dd0346
Related: OS#3400
Previously the MNCC socket path was generated automatically,
using concatenation of the '/tmp/ms_mncc_' prefix and MS name.
Let's allow the user to specify this manually, keeping the same
naming generation method for default value.
Change-Id: I643356ac579bc5e765f668265ec803b22a73739c
Related: OS#3400
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
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: I25baaa30b097dad2fae507c5321778f43e863611
Related: OS#4138
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
Since we have two ways to interact with a physical SIM:
- using built-in SIM reader of the L1 PHY (via L1CTL),
- using remote reader via (BT)SAP protocol,
name 'GSM_SIM_TYPE_READER' looks quite confusing. Let's rename it
in order to explicitly indicate the role of L1 PHY.
Change-Id: I0f83f365ed50cfd658fdd3a9d6866ed76c8c4009
This change revives the main idea of:
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
to stop ignoring the VTY bind address from the config file.
Furthermore, it deprecates (and disables) both 'u' and 'v'
command line options, because they are redundant.
Change-Id: I99e0ec1717edd29b3be231be86616cc7effe5d95
The VTY requisites are always being printed by libosmovty,
there is no need to duplicate this information.
Change-Id: I688f66175ea67d4c6a46819bee7d300ad9ce7cc7
If we fail to initialize the VTY, print an error mesage instead of
failing silently. For example:
"Cannot init VTY on 127.0.0.1 port 4247: Address already in use"
Change-Id: I24161f53fa621ae1c8b1916bd0c8055c494b531e
Forward started/shutdown changes to the primitive layer which will
turn them into indications. The other option might be to use the
signals but it seems primitives are a superset of the signals.
The notify will be done per MS and then the right primitive
instance will be searched and the indication be sent. The approach
will be applied to other systems as well.
The signal framework might be seen as
a subset of the primitives A signal mostly being a different form
of an indication.
Change-Id: I5df20a4ab79c06b515780675b6df2929aa976f0d
Move the check if within the mobile app there is no other active
MS using the same L1 socket. This way we can call this function
from the primitive code as well.
Change-Id: Ib4aa5ff212fa6bead8f620abaecc6a0b51a99fec
Instead of changing the field all over the place, do the state
change in a function. This will allow us to emit a notification
when things change. It is similar to the lchan_state.
Change-Id: I6a0591bb2785232681b23e41368323f16d3c960c
The enum was created to understand the different states during
the shutdown and find places where it is used. The normal
transitions are like.
Idle -> Imsi Detach -> L1 Reset -> Done
Idle -> L1 Reset -> Done
The shutdown can get stuck in case:
* Out of memory situation while handling IMSI detach (timeout)
* Never receiving l1 reset acknnowledgment.
The code could benefit from the move to osmo fsm to deal with
proper timeouts.
Change-Id: Iee1140e4848923c7270495c381bf87b7e3fddee1
The state handling is complicated and maybe it gets better by
moving started to bool and then the rest to an enum.
Change-Id: I6aef22e7bf954a8a4ecda980c2c558eb8c9180b7
Add a mobile application logging category and replace printf with
a LOGP. The code is sadly still using exit in the middle of handling.
Change-Id: I71e7f6e6375a485b45bad76ada2be17b0901577d
So far logging_vty_add_cmds wasn't called. The main.c might be
shared with other apps so place it into the routine that is
setting up the VTY.
Change-Id: I3db9cf288bce12f51e36caad44e9bc34094638f4
As we use talloc, it's absurdly not to use the main feature of
the library - hierarchical memory management. This change sets
talloc context of all sub-allocated objects to related osmocom_ms
instance. So, as soon as osmocom_ms instance is destroyed, all
sub-allocated chunks are getting destroyed too.
Change-Id: I6e3467ff739f3e6dc8dd60cc6d1fcd3f8e490ce9
This change registers the command, which is now implemented in
libosmocore since the 463deef8c209dd7eb023ac70bf41fa9893ad35ed
and allows to introspect mobile application's talloc context
directly from the VTY interface.
Change-Id: I979d64ae63d385f4fd082a4e3f981cbf5ab28338
Vadim Yanitskiy
Andreas Eversberg
Pau Espin
Oliver Smith
Martin Hauke