This allows using well tested standarized API to print, compare, etc. usual
identifiers like PLMN, LAI, etc.
It also simplifies code by avoiding passing lots of parameters and
making it easier to identify which fields go packed together.
This is specially important since in the future more of those
identifiers will be added for GPRS.
Change-Id: I07a9289825c09ed748e53d36a746ea164c8a5d7f
This way we end up with the generic section on top, followed by each
backend section clearly delimited. As a result, it is now much clearer
the separation between the generic code and each backend specific
implementation.
Change-Id: Ice8ada52f227ee4da90ba37ec6b3eb8070621f85
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
This allows further control on the state of the APNs, as well as
a step further towards administering them through VTY.
Change-Id: I2cc732dfb020d31ab89025e7e22276b819dcb24a
There seems to be some bug when using virtphy where sometimes the
received T2 and/or T3 in the ImmASs is not matching what we sent.
This helps in showing the problem and not failing silently.
Change-Id: Iaecd2616733d84f35a825916fe888142800b426b
Wait until SIM is ready, network system information ws obtained and
it announced the MS is able to use GPRS against it.
Change-Id: I5029d9e8a47b8544b3b803c4db6352269bac3c0e
Those modules are aready in common/, so they can be added to the shared
VTY interface to introspect MS objects.
Change-Id: Ie4d85bbb1d0af8894683589d8b936f9884f79be9
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
It's just a good practice to delete all resources allocated during startup.
The main aim here is to keep resemblance to what the mobile app is doing,
so that they can slowly be merged and some functionalities from the mobile app can be
added to the modem app, like shutting down the MS without killing the process eventually.
Change-Id: I5a641fa3dadb6ea7346b25a20215896ab32eb805
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
Recent work on libosmo-gprs-gmm already allows triggering GPRS Attach
procedure. Let's add some code to use it so we can already test the
entire stack GMM->LLC->RLCMAC (SM layer still missing).
Depends: libosmo-gprs.git Change-Id I212053b3a3f27ef7d63503c3d5ef08453b2d2056
Related: OS#5501
Change-Id: Iba0663075468670a29aceafe5196cae3cab050eb
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"
Do not call grr_tx_chan_req() unconditionally from grr_rx_bcch().
Add a special (hidden, expert mode) VTY command for that.
Change-Id: I049a8d7f58ae9703d06dff235973ba376702c873
Related: OS#5500
After the recent refactoring, parsing of the command line options is
broken for some arguments. Specifically, the value of '-a'/'--arfcn'
is ignored and hard-coded ARFCN=871 is used instead.
The problem is that l23_app_init(), which allocates an MS state and
sets the initial ARFCN, is called *before* handle_options(). So the
cfg_test_arfcn is used before it gets overwritten from the argv[].
The usual approach in osmo-* apps is to parse the command line
arguments first, and only then execute code which depends on
configurable parameters. Let's follow this approach too.
Change-Id: I77ca11c14561fa3fcb9add60ccea5b0b847a20c4
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
header file name gprs_rlcmac.h was renamed to csn1-defs.h during recent
libosmo-gprs-rlcmac development. Use the new names everywhere.
Depends: libosmo-gprs.git Change-Id I84ea63ed0b804699fd995a2e0c07ced17b3ad4c8
Change-Id: I205536907d9062b78453ce9bc404db1633e9a616
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
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
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
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
Found by clang:
l1ctl.c:397:52: warning: implicit conversion from 'int' to 'int8_t'
(aka 'signed char') changes value from 255 to -1
[-Wconstant-conversion]
Change-Id: I23e9ea5ad59099c24db60057c8e7da1e6a0d2293
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
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
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
There was no need for this check because the channel establishment
logic was at the end of handle_si13(), so I overlooked this.
Change-Id: I829948de325461ab5d7e950493497a7537ba06ac
Fixes: 8a506dcd4e
Related: OS#5500
Sending CHANNEL REQUEST from handle_si13() was a bad idea because
this function returns early if SI13 was received before SI1.
Change-Id: I21f1d68cb9b1d20b356697ba1efe28c3d87fa004
Fixes: 49d993e4ab
Related: OS#5500
Triggered with gcc 12.2.0:
/osmocom-bb/src/host/layer23/src/common/sysinfo.c: In function ‘gsm48_sysinfo_dump’:
/osmocom-bb/src/host/layer23/src/common/sysinfo.c:198:42: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
198 | sprintf(buffer + 69, " %d", i + 63);
| ^
/osmocom-bb/src/host/layer23/src/common/sysinfo.c:198:17: note: ‘sprintf’ output between 3 and 13 bytes into a destination of size 12
198 | sprintf(buffer + 69, " %d", i + 63);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I29a64fbb7aca0d1b469b6d278d4a24ddc6f57b3a
Use the existing application skeleton from '$(top_srcdir)/src/common/'.
Use the LAPDm glue from '$(top_srcdir)/src/misc/rslms.c'.
This is what the misc applications like ccch_scan are using.
Change-Id: I8566a3cdc9f818bed7e28ea4b1957dce735c298b
Related: SYS#5500
What I find weird is that the gsmmap is using files from layer23,
and vice-versa cell_log from layer23 is using files from this
utility. And somehow they are separate sub-projects.
I see no reason why gsmmap must be in its own sub-project.
Change-Id: I2bc9c8897f3c7ccf207be0146f7b55fc733a6abb
This will be needed for the modem application, and is also used
in a follow-up commit adding support for parsing SI13 Rest Octets.
Change-Id: I8e0f826c9b2a886f94624176e34e7d197e93d25f
Related: OS#5500
Sometimes I am seeing error messages like this:
DCS ERROR Failed to write BA list
The problem is that there can be several BA entries which need to
be written, and for each of them we're calling fwrite() twice.
This function returns number of items written, so the final sum
of returned values would be: len(BA list) * 2. Thus expecting
it to be 2 regardless of len(BA list) is wrong.
Fix this by checking the sum in each iteration, not at the end.
Take a chance to refactor the code and move to a function.
Change-Id: Id8bc216c146127d9c9995379c9e56450d328f46d
The mobile app crashes when using a Calypso phone and specifically
when using its built-in SIM reader. The problem is that msg->l2h
is NULL in rx_l1_sim_conf(), so msg->l1h must be used instead.
Assert failed msgb->l2h /usr/local/include/osmocom/core/msgb.h:162
Change-Id: I7c68a3ad393be5fd0413e00e119a06db59672357
This is a partial revert of 8f04fa9758.
The GAPK based audio I/O implementation of the mobile app is now capable
of handling TI's specific TCH frame format, which can be configured via
the VTY interface ('io-tch-format ti'). TCH frames in this format are
different from the ones in RTP format and may have different length and
different bit ordering. Remove voice_frame_verify().
Change-Id: I6113ba443e65ddaae091b643af54c873b7da4de8
Related: OS#3400
Do not assert() in gsm_recv_voice(), because channel release does
not happen immediately and the PHY may be still sending TCH frames.
Change-Id: I8943ee9bd46afc96e6d7cfd52c95c34fd311ce11
Related: OS#3400
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
This way we can avoid allocating another msgb and enqueue the given
msgb directly to the write queue of the MNCC socket.
Change-Id: I29305866e61a0bc3bd082108af6a9ba8ff86bcf2
Related: OS#5599
Do not send voice frames to the external MNCC unconditionally.
Add a new I/O handler type for the external MNCC application.
Change-Id: I406b169963e6654110329d741728fa12c8c8eeec
Related: OS#5599
This is needed to avoid sending voice frames to the L1PHY without
having to use MNCC specific struct gsm_data_frame.
Change-Id: I37241555cd648a8e2b57fa072c708f93cd1ba5a9
Related: OS#5599
The idea behind checking the ch_type in gsm48_rr_tx_voice() was likely
to prevent sending of the (LCR originated) Uplink TCH frames before
the actual traffic channel is established/modified.
The problem is that this check allows TCH/F frames, but not TCH/H.
Most likely, TCH/H was forgotten or never tested. Fix this.
Change-Id: I06e84ad47bafd4676af0e136b825e77471587b23
Related: OS#5599
According to 3GPP TS 04.08, section 3.4.6.1.3 "Abnormal cases"
of "channel mode modify procedure", if the MS doesn't support
the indicated channel mode, it shall retain the old mode and
return the associated channel mode information in the
ACKNOWLEDGE message.
Previously, if an indicated mode is not supported, we used to
indicate the 'CHAN_MODE_UNACCT' RR case without sending the
ACKNOWLEDGE message. Also, the result of gsm48_rr_set_mode()
was ignored. Let's fix this!
Change-Id: I952436ec796273e56341f9d3492b4a3b3a5dc410
Related: OS#5599
Some L1PHY targets (e.g. Calypso based Mot C1xx phones) have built in
microphone and speaker. Some targets do not have them. Currently we
unconditionally instruct the L1PHY to handle TCH frames internally.
Make this behavior configurable via the VTY interface.
Change-Id: I131f213ef7c2736f7310f0183b83f3bc3064cd98
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
Similar to rsl_dec_chan_nr(), this function may also fail, leaving
the given struct tlv_parsed uninitialized.
Change-Id: I13f2a97eeff78ca8ed7d0a2844e4fca430ec7768
Related: OS#5599
The rsl_dec_chan_nr() may fail to decode RSL channel number, so
variables ch_type/chan_ss/chan_ts would remain uninitialized.
Change-Id: I9ab18bdaf41a29fcd32a7060668ef9db07b8cf7e
Related: OS#5599
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
This app will allow setting up a tun device to transmit/receive data
as a GPRS MS against a GSM network.
This is just the initial skeleton so that people can work on it further
in follow-up commits.
Related: OS#5503
Change-Id: I8a1121b3287da7d7330c30e3118affa8fd1da61b
This reverts commit 1a8a80aeae.
We currently get ALL SI messages wrong - the protocol disseminator is
accidentally being used as SI msg type, and
6=radio resources management - but 6 is also type=si5ter.. so all SI we
receive end up being parsed as SI5, what a coincidence!
Change-Id: I3822f74295920680a935f3031c642ba00162d09d
This allows TTCN3 L1CTL module (used in BTS_Tests) to transmit and
receive AMR payloads towards osmo-bts-trx.
Related: SYS#5987
Change-Id: Ia20bc96e39726a919a556c83c8be48cb31af7331
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
Pau Espin
Vadim Yanitskiy
Max
Oliver Smith
Eric Wild