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 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
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
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
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
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
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
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
The aim is to add configurable audio loopback to mobile. An existing patch on a
branch from fixeria [1] adds the audio config section. Add a reduced version of
this audio config to be compatible with the future merge.
Add the audio loopback setting, so far without functionality.
Subsequent patch adds the actual loopback.
[1] osmocom-bb branch fixeria/audio,
patch "mobile/vty_interface.c: add new 'audio' section"
Change-id I62cd5ef22ca2290fcafe65c78537ddbcb39fb8c6
Change-Id: Ie03e4a6c6f81ea3925266dd22e87506d722a6e1a
In several code paths we put / push structures from 'gsm48_mm.h' into
the message buffers, so then they're unpacked by the message receivers.
The AddressSanitizer complains about unaligned pointer access and
potentially unexpected behaviour. Let's fix this by explicitly
marking those structures as 'packed'.
Change-Id: I6af7475c609b3293af708540d569fe1616fab43f
In both gsm48_mm.c and gsm48_rr.c we put / push 'gsm48_rr_hdr'
structure into the message buffers, so then it's retrieved by
the message receivers. The AddressSanitizer complains about
unaligned pointer access and potentially unexpected behaviour.
Change-Id: I8aa2c0074b405afd0e76044ef076b6819fe1083b
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
There are several SIM card interfaces, two of which:
- GSM_SIM_TYPE_L1PHY (using built-in SIM reader of the L1 PHY),
- GSM_SIM_TYPE_SAP (using remote reader via (BT)SAP protocol),
can actually deal with a physical SIM card. But, for some reason,
only GSM_SIM_TYPE_L1PHY was considered as such. Let's also get
along with GSM_SIM_TYPE_SAP for the following procedures:
- PIN management and verification,
- FPLMN / LOCI updating,
- A3 authentication.
Change-Id: I4b3080fa7a5332467a449a314ba3cc3a07a9b7df
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
L1CTL implementation (i.e. l1ctl.c) is not a good place for the
SIM specific stuff. Let's move it to the proper place (i.e. sim.c).
As a bonus, this change fixes a possible problem of loosing the
cached APDUs if two or more L2&3 applications are using a single
LAPDm connection. The APDU buffer is dedicated per MS now.
Change-Id: I564c610e45aa3b630ca5d1ec6bc1cace0dc9c566
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
It was discovered that l1ctl_tx_param_req() is using an unsigned
'uint8_t' type for Timing Advance value, while other code and
L1CTL protocol is using signed 'int8_t'. This may result in
distortion of negative values, so let's fix this!
Change-Id: I6ee42b5fa2ca9ebe187f0b933465c49f840a55c2
When starting multiple mobile in the same second, the libc random number
generator will be seeded to exactly the same value.
The random bits inside the RACH request(s) will be exactly the same
across multiple mobile and when the channel fails they all pick the same
randomized back-off timing.
Use stronger random numbers and replace all calls to random(2) with
osmo_get_rand_id. Add a fallback to try random().
[v2: Add helper to make sure the result is int and between 0 and
RAND_MAX]
Change-Id: Icdd4be88c62bba1e9d954568e48f0c12a67ac182
Disable storing the SMS on disk. This is useful when scripting mobile.
Keep the default of attempting to store it to disk.
Change-Id: I6353447343d98ebaa5e12ab63f995750f81c8500
When no cell was found during the PLMN search the camp on any cell
state will be entered. LUs are prevented in this state and it will be
left after the start_any_timer has timedout. Even if camping on the
home network the state will not be left before the expiry of the timer.
For systematic tests this is producing a too high upper bound. Make it
configurable so we can succeed with a UL more quickly.
Change-Id: I25bc985cd4360d5e37d05a7b16b39eefb75ce20f
Previously, the L1CTL_CRYPTO_REQ message contained only a ciphering
algorithm and actual Kc key to be used. The key length was
calculated manually using the MSGB API.
Let's avoid manual calculations here, as it may cause unexpected
behavior if the message structure is changed. Also, let's fill
the UL header with minimal information about a channel, which
is going to be encrypted.
Change-Id: I5fab079907c5276322d3ec2b46cab81f10c7ed09
Make this symmetric and send the SMS through the primitive
interface. Construct and copy the sms into the prim, store
the SCA in the prim as well. In 04.11 we see we can store
2*10 digits in the destination address and a NUL.
Change-Id: I91d7537f4f6ce5ba00218c58f3456947ec7bc662
Make the MS the script is associated with accessible to lua. Provide
access to IMSI and IMEI. The IMSI might not be available at the given
time and just return an empty string.
Example lua usage:
print(osmo.ms():imsi());
print(osmo.ms():imei());
print(osmo.ms():shutdown_state())
print(osmo.ms():started())
function ms_started_cb(started)
print("MS started", started)
end
function ms_shutdown_cb(old_state, new_state)
print("MS shutdown", old_state, "->", new_state)
end
function sms_cb(sms, cause, valid)
print("SMS data cb", sms, cause, valid)
for i, v in pairs(sms) do
print(i, v)
end
end
function mm_cb(new_state, new_substate, old_substate)
if new_state == 19 and new_substate == 1 then
osmo.ms():sms_send_simple("1234", "21321324", "fooooooo", 23)
end
end
local cbs = {
Started=ms_started_cb,
Shutdown=ms_shutdown_cb,
Sms=sms_cb,
Mm=mm_cb
}
timer = osmo.timeout(20, function()
print("Timeout occurred after 20s")
end)
osmo.ms():register(cbs)
# Can fail. Best to wait for state changes...
print(osmo.ms().start())
print(osmo.ms().stop(true))
Change-Id: Ia3ace33d6ba4e904b1ff8e271a02d67777334a58
Right now the script will be executed once it is loaded. Make sure
to write it into the config file last. Expose various log commands
for logging. Jump through some hoops and get the filename and line
number from lua.
Change-Id: I456f6b6b5e1a14ed6c8cb0dcc5140093d3c61ef6
Pau Espin
Vadim Yanitskiy
Vadim Yanitskiy
Oliver Smith
Martin Hauke
Harald Welte