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
Do not send a dummy authentication response with the test sim.
Fixes: 39dc9c46 ("mobile/subscriber.c: consider GSM_SIM_TYPE_SAP too")
Change-Id: I0ee910c171d383fb2cdcaf5eb54eafe18da3430b
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
Some logging categories use LOGL_INFO or even LOGL_DEBUG. Lets set those
to LOGL_NOTICE to have a less crowded default log output.
Change-Id: I3faefccae2218b17bd942bc2afac7d8e515897b7
Related: OS#2577
It's not clear why do we get frames with unexpected length, but
we definitely should not crash. Just log and ignore them.
Change-Id: I85392becbffdb3ba7365decfd8f3769abe3c02c7
Related: OS#5171
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ied0f47378a5d348b857424adb5c874c1c093b485
Fixes: OS#4865
I was quite confused why I constantly see a bit error rate reported
by gsm48_rr, while at the same time the actual L1CTL_DATA_IND did
all state num_biterr == 0.
So the log statement was broken ...
Change-Id: I09bb6c606a8437b213bb444949c78a7c8a10542c
This way the layer1 can activate proper CBCH task and send us
CBCH block with proper RSL channel number, so they do not end
up being routed to LAPDm and rejected there.
Change-Id: Ib1d5c99587202a9d94aeb7b63de7ae8c4fb15af0
We cannot blindly assume that CBCH is present on TS0/SDCCH4 before
decoding CBCH Channel Description in System Information Type 4.
Change-Id: Ie8ce572df292d0b03c0f743bcf26184619176321
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
L1CTL handling code should not be involved in such high level checks, so
while at it, move the check into a separate function in gsm48_rr.c and
add a length check. gsm48_rr_tx_voice() is the only caller of
l1ctl_tx_traffic_req().
Related: SYS#4924
Change-Id: Iba84f5d60ff5b1a2db8fb6af5131e185965df7c9
Use newly added audio / loopback config vty node to provide audio
loopback from mobile app. Only FR is supported for now.
Change-Id: Icd0b8d00c855db1a6ff5e35e10c8ff67b7ad5c83
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
GPRS (PDCH) and CBCH related frames have nothing to do with LAPDm.
The former uses LLC for the user-plane data, while CBCH involves
its own segmentation described in 3GPP TS 23.041 and TS 44.012.
There is currently no code for handling these kinds of frames, so
let's just send them to GSMTAP and release the memory (msgb).
Change-Id: I59b4acbe22217f8989f73b79b128a43e8bcdfa2f
Related: OS#4439
In Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2 we
introduced a new member to the ccch_mode enum: CCCH_MODE_COMBINED_CBCH,
which is to be used to tell the PHY if a CBCH is present on the combined
CCCH+SDCCH/4+CBCH or not (CCCH+SDCCH4).
This was implemented in trxcon + calypso firmware, but cbch_sniff has
not been updated accordingly.
Related: OS#4439
Change-Id: I429d45cfb181da4a2e767e92f1213ccd08c6d440
That function encapsulates the RTP payload in an MNCC header, but the l1ctl dl
header has to be removed first to get only the RTP payload in the MNCC
structure.
Change-Id: Id6ddc9b1da43e88c5b9468d4397a39953bdf533a
This pointer cs->si stores an address to the System Information of
a currently selected cell. When we release System Information,
ensure that it does not point to free()d memory.
Change-Id: Ife2ddf7274a48447a9ded9035f9dd01befaf2e6c
Some applications (e.g. ccch_scan) may not initialize ms->cellsel.si,
some (e.g. mobile) may need some time to initialize it. Let's assume
that 'bs_ag_blks_res' is 1 if System Information is not available.
Change-Id: Ie695d9700c01ee1e6778950a2f3c8610b69d2143
During 3.19->3.20 dev cycle, some fields were transformed from
timestamp_t or double to timespec_t. See for instance gpsd.git
f7c230fceb6d64483757f8c32afb98e6a2cb9413.
Change-Id: Ie8ba19d030b6f46f2d8afc270a732ce8c26c438f
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 some cases (e.g. at start up) ms->rrlayer may not be initialized.
Let's access ms->settings directly since we already have a pointer
to struct osmocom_ms.
Change-Id: Ia9720132fcda960dcecefab9ae48398946503dc4
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
According to GSM TS 04.08, section 10.5.4.11, location and coding
standard are encoded before the cause value, not vice-versa!
Also, coding standards other than "1 1 - Standard defined for the
GSM PLMNs" shall not be used if the cause can be represented with
the GSM standardized coding.
Change-Id: Ic6abcfb9a9589f5b0c9c40def863f15ae04d0bdd
sap_fsm.c: In function ‘sap_negotiate_msg_size’: sap_fsm.c:103:15:
warning: passing argument 1 of ‘__bswap_16’ makes integer from pointer
without a cast [-Wint-conversion]:
size = ntohs((uint16_t *) param->value);
^~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Ie58af6162c67ae377809b42daa897ca3f3d72af1
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
In gsm322_l1_signal(), if S_L1CTL_FBSB_ERR is received, we free
stored System Information of the current cell, but cs->si may
still point to it. Let's set it to NULL.
Found with AddressSanitizer:
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:2995 Channel sync error, try again
DCS INFO gsm322.c:467 Sync to ARFCN=860(DCS) rxlev=-106
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:3008 Channel sync error.
DCS DEBUG gsm322.c:3013 free sysinfo ARFCN=860(DCS)
DCS INFO gsm322.c:3020 Unselect cell due to sync error!
DCS INFO gsm322.c:509 Unselecting serving cell.
=================================================================
==6014==ERROR: AddressSanitizer: heap-use-after-free on address
0x61b0000000e6 at pc 0x00000050d6dd
bp 0x7fff7f84aa60 sp 0x7fff7f84aa58
Change-Id: I9cc526c18d69695d810de98703579818408de011
This change fixes the following compiler warning:
sim.c: In function ‘gsm_sim_reply’:
sim.c:149:11: warning: variable ‘payload’ set but not used
[-Wunused-but-set-variable]
uint8_t *payload;
Change-Id: I3767b23bb1b28d3f4bb515d399bce160ba2eee09
As we do iterate over all entities in the BA list, it makes more
sense to print each one separately instead of printing the last
one. Moreover, as soon as the iteration is finished, *ba points
to some zero-initialized part of memory:
gsm322.c:5170 Write stored BA list (mcc=000 mnc=000 Marshall Islands, 000)
After this patch:
gsm322.c:5162 Write stored BA list (mcc=250 mnc=99 Russian Federation, Beeline)
gsm322.c:5162 Write stored BA list (mcc=250 mnc=01 Russian Federation, MegaFon)
gsm322.c:5162 Write stored BA list (mcc=250 mnc=02 Russian Federation, MTS)
gsm322.c:5162 Write stored BA list (mcc=544 mnc=31 Serbia, Telenor)
Change-Id: I5160492e6125401c6a1765f54d129b1f1cd503fc
In If1e851ac605c8d2fde3da565b0bd674ea6350c2e, msgb_wrap_with_TL()
was renamed to msgb_push_tl(). Let's use the new symbol name.
Change-Id: Ief37424e0ca3cd696054518a0ffb07b7ef17a462
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
Passing NULL to sap_msg_free() is not only meaningless, but also
would result in NULL pointer dereference. We should call it in
successful case only, so let's fix this.
Change-Id: Icf868c4299e292a17c4b7aad1f9e728ea3653494
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
Almost all layer23 applications, excluding mobile, have nothing
to do with SAP interface. Moreover, the current implementation
does initialize SAP connection automatically, as soon as the
first message is sent.
Change-Id: I62cc69c06fa15468a55bb0a9d408267d0745174c
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 process should be aborted if a non-existing command line
option or an incorrect parameter value is passed.
Change-Id: Ib656ad12f12429ed15dc2a1554901ffa51148ff6
The VTY requisites are always being printed by libosmovty,
there is no need to duplicate this information.
Change-Id: I688f66175ea67d4c6a46819bee7d300ad9ce7cc7
This reverts commit c8de8cb1e1
(Change-Id I32517567847fd5c54b1742f18bf409ff81e316fa by Max),
because several problems were introduced, in particular:
a) Help message of mobile application is broken:
"The VTY IP to telnet to. (default (null))",
"The VTY port number to telnet to. (default 127.0.0.1)".
b) Default VTY bind addres != parsed from the config file.
c) The (vty_ip == NULL) is resolved only when an external
MNCC handler is used, otherwise NULL is passed to
l23_app_init().
Change-Id: Ic63a4eb828ff32d3744886b4f5f6f5019c798620
Previously the vty bind config parameter was always ignored. Fix this by using proper
default value from the config unless it's explicitly set via command-line parameter.
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
Log via LOGP() like the rest of the file instead of fprintf() for
consistency. While at it, also print error cause.
Change-Id: Id205bcd9bdb7c3e4b96493d50be8381a6fa80ac6
Fixes following ASan warning:
git/osmocom-bb/src/host/layer23/src/misc/../common/main.c:146:2: runtime error: null pointer passed as argument 2, which is declared to never be null
The warning however is harmless since in that case, app_len = 0 and thus
size to copy is 0.
Change-Id: I009a5b53f1e5be72ce347d64d3a7cb1d95d37ea3
Unlike the DATA messages, traffic frames may have different length.
Instead of having fixed payload (i.e. TCH frame) length, let's
introduce a flexible array member. This would allow one to
calculate the frame length using the MSGB API.
Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
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
Almost all handlers for received L1CTL messages are also affected
by the bug fixed in I7fe2e00bb45ba07c9bb7438445eededfa09c96f3. In
short, they do verify the length of 'msg->l2h' or 'msg->l3h', but
not the 'msg->l1h'. Let's fix this, and also add missing checks.
Change-Id: I866bb5d97a1cc1b6cb887877bb444b9e3dca977a
As we assign the payload following L1CTL header to 'msg->l1h',
it makes sense to avoid possible naming confusion.
Change-Id: I5d21ca8664b3445f472d3ffde90d0e11805dcb16
Pau Espin
Max
Vadim Yanitskiy
Oliver Smith
Eric Wild
Philipp Maier
Harald Welte
Martin Hauke