summaryrefslogtreecommitdiffstats
path: root/src/host/layer23/src/mobile
AgeCommit message (Collapse)AuthorFilesLines
2019-10-17Fix common misspellings and typosMartin Hauke12-81/+81
Change-Id: I962b42871693f33b1054d43d195817e9cd84bb64
2019-08-05Remove undefined param passed to logging_vty_add_cmdsPau Espin Pedrol1-1/+1
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
2019-07-21gsm411_sms.c: Handle negative return of gsm340_gen_oa()Harald Welte1-0/+3
Change-Id: I36f56e1fbd72d9b31350dc2f8a53e763f79f4c08 Closes: CID#198533
2019-07-21mobile/gsm480_ss.c: gsm480_tx_release_compl(): fix cause IE encodingVadim Yanitskiy1-2/+7
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
2019-07-21mobile: Fix encoding of cause in gsm480_tx_release_compl()Harald Welte1-4/+4
Change-Id: Iba2ace7d82be5677d28b25f60ab0312fed76f5e5 Closes: CID#198577, CID#198576, CID#198575
2019-07-21gsm322: Fix resource leak in gsm322_init() while reading BAHarald Welte1-1/+3
Change-Id: Id42102ab8581e247f495fb7e05dc62a6743d28c5 Closes: CID#198546
2019-05-28layer23: fix tons of compiler warnings, mostly OSMO_DEPRECATED relatedHarald Welte5-19/+21
Change-Id: I03918bd864c711b377a795186123c85bb6f4dc4a
2019-05-03mobile/gsm48_mm.c: use proper types for gsm48_rr_hdrVadim Yanitskiy1-5/+5
Change-Id: I29ed122b8956260b9f847cc0e3e81a28d6762632
2019-05-03mobile/gsm322.c: fix heap-use-after-free in gsm322_unselect_cell()Vadim Yanitskiy1-0/+2
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
2019-04-27lua: Add a sentinel for the fd function tableHolger Hans Peter Freyther1-0/+1
Change-Id: I4fe2fd6584a453a951361e1b67fb986583b176be
2019-02-02mobile/gsm322.c: fix: properly print stored BA list entitiesVadim Yanitskiy1-6/+6
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
2019-01-23mobile/gsm480_ss.c: fix build: apply msgb_wrap_with_TL() renameVadim Yanitskiy1-1/+1
In If1e851ac605c8d2fde3da565b0bd674ea6350c2e, msgb_wrap_with_TL() was renamed to msgb_push_tl(). Let's use the new symbol name. Change-Id: Ief37424e0ca3cd696054518a0ffb07b7ef17a462
2019-01-15layer23/sap_interface.c: reimplement (BT)SAP interfaceVadim Yanitskiy2-0/+52
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: avoid using 'osmo' prefixVadim Yanitskiy1-1/+1
The 'osmo' prefix is usually used by libosmo-* symbols. Change-Id: Id37d8553c2f2c20012fb1b729967b92a9a03f612
2018-12-26layer23/sap_interface.c: remove redundant socket_path argumentVadim Yanitskiy1-1/+1
Change-Id: I408b3e1fa40e9b5daf88fa6ed5f3930b83dffe6f
2018-12-26mobile/subscriber.c: consider GSM_SIM_TYPE_SAP tooVadim Yanitskiy1-5/+4
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
2018-12-26host/layer23: rename GSM_SIM_TYPE_READER to GSM_SIM_TYPE_L1PHYVadim Yanitskiy4-9/+9
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
2018-12-23mobile: Use new VTY telnet API to allow binding to random portHolger Hans Peter Freyther1-2/+1
Change-Id: I5a6214aec2dcb92495038ea8311c0df22fa8d07b
2018-12-19layer23/mobile: drop dead SAP initialization codeVadim Yanitskiy1-10/+0
SAP connection can be initialized upon request. Change-Id: Ic89089c4850ab2c9252bfd43a05d5271e2e3a160
2018-11-21mobile: use VTY bind addr from config, deprecate cmd line optionsVadim Yanitskiy2-19/+18
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
2018-11-21mobile: abort in case of argv handling errorsVadim Yanitskiy1-3/+10
The process should be aborted if a non-existing command line option or an incorrect parameter value is passed. Change-Id: Ib656ad12f12429ed15dc2a1554901ffa51148ff6
2018-11-21mobile/app_mobile.c: use LOGP() instead of printf()/fprintf()Vadim Yanitskiy1-9/+8
Change-Id: I6af76afbaa34dde5ddfc31a65700030862442dba
2018-11-21mobile/app_mobile.c: drop redundant printf() callVadim Yanitskiy1-1/+0
The VTY requisites are always being printed by libosmovty, there is no need to duplicate this information. Change-Id: I688f66175ea67d4c6a46819bee7d300ad9ce7cc7
2018-11-21Revert "mobile: fix vty bind ip override"Vadim Yanitskiy1-4/+3
This reverts commit c8de8cb1e126a18c0269571fba38310589dd9273 (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
2018-11-19mobile: fix vty bind ip overrideMax1-3/+4
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
2018-11-19Fix build with latest libosmocoreMax1-10/+0
Remove locally defined function which conflicts with the one in libosmocore. Change-Id: I1be1d39f7c93c959ca33f6296ecda71996865cca
2018-11-19mobile: log socket path on errorMax1-1/+1
Change-Id: I18eb46743e4c0e4e8f8032883f39fec355f03c78
2018-11-16mobile: use proper type for boolean flagsMax1-8/+8
This makes reading code easier and simplifies further modifications. Change-Id: I7eff2a61495ff167dc19fc9a41882a7a11fbf32d
2018-11-16mobile: add header for MS' MNCC functionsMax2-9/+2
This simplifies adding new functions and re-using them from other parts of the code. Change-Id: Ibad400a99afe052f011f54fc706836b6bf89f4b9
2018-09-16lua: Expose API to trigger a network reselectionHolger Hans Peter Freyther2-0/+26
Same as the "network search" VTY command but implemented as primitive and exposed to LUA. Change-Id: I096233a2ca9dd7daa358cebed0523cb8c0dbf593
2018-09-06layer23: Use osmo_sock_unix_init_ofd() from libosmocoreHarald Welte1-60/+3
We don't need to hand-code unix domain socket initialization but can simply use our library function for it. As an added benefit, the library code already contains corner case handling for non-NUL terminated unix domain socket path. Change-Id: I57c724c78dbbbce0546ebe914e370f32c8c89703
2018-08-24Allow lua code to register a fd for reading with the runtimeHolger Hans Peter Freyther1-0/+103
To have bi-directional communication we can pass credentials to the registry server and now we can register a callback when the registry is sending data to us. The callback needs to return if the fd should continue to be selected as I found no way to push the userdata as parameter on the stack. Lua code will look like: local host, port = "www.osmocom.org", 80 local tcp = socket.tcp() tcp:connect(host, port); tcp:send("GET / HTTP/1.0\r\n\r\n"); local cb = function() local s, status, partial = tcp:receive() print(s) if status == 'closed' then tcp:close() return 0 end return 1 end local foo = osmo.register_fd(tcp:getfd(), cb) Change-Id: I8254bdda1df2f8fe0a5eac894b931e7de5b426df
2018-08-24Forget about the callback after use and cancellationHolger Hans Peter Freyther1-0/+5
Don't try to unref something else after we have given up our spot in the table. Change-Id: I4e8db297e816d3d07a46147d5d3bdc0e8fae6c9a
2018-08-11layer23: Replace all instances of strncpy() by osmo_strlcpyHarald Welte5-18/+12
This gives us working/safe zero termination without overflowing the destination string size. Change-Id: Ica6098ceba2bd01ce3b216085442cc5eed0ca507
2018-08-11layer23: Fix possible buffer overflow writing NUL beyond end of stringHarald Welte1-1/+1
settings.c: In function ‘gsm_random_imei’: settings.c:188:26: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] sprintf(rand + 8, "%07ld", random() % 10000000); ^ settings.c:188:2: note: ‘sprintf’ output between 8 and 9 bytes into a destination of size 8 sprintf(rand + 8, "%07ld", random() % 10000000); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: Id949487111235cd4af5ff068f1dce2f4b0801480
2018-08-11layer23: Use osmo_strlcpy() to avoid non-terminated stringsHarald Welte3-3/+3
settings.c:191:2: warning: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 15 -Wstringop-truncation] strncpy(set->imeisv, set->imei, 15); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC subscriber.o CC support.o CC transaction.o CC vty_interface.o CC voice.o CC mncc_sock.o CC primitives.o mncc_sock.c: In function ‘osmo_unixsock_listen’: mncc_sock.c:318:2: warning: ‘strncpy’ specified bound 108 equals destination size [-Wstringop-truncation] strncpy(local.sun_path, path, sizeof(local.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC script_lua.o vty_interface.c: In function ‘cfg_gps_device’: vty_interface.c:1144:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] strncpy(g.device, argv[0], sizeof(g.device)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AR libmobile.a Change-Id: Id52978f3bf7a8abea62237d7c32f8f87e1bb34a1
2018-08-11layer23: Fix compiler warnings about string operation truncationHarald Welte1-4/+4
This fixes the below warnings: gsm322.c: In function ‘gsm322_cs_ba_range’: gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(lower_text, gsm_print_arfcn(index2arfcn(lower)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3480:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] gsm322.c:3481:3: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(higher_text, gsm_print_arfcn(index2arfcn(higher)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c: In function ‘gsm322_cs_powerscan’: gsm322.c:2862:2: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(s_text, gsm_print_arfcn(index2arfcn(s)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gsm322.c:2863:2: warning: ‘strncpy’ specified bound 10 equals destination size [-Wstringop-truncation] strncpy(e_text, gsm_print_arfcn(index2arfcn(e)), ARFCN_TEXT_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I08f938cfb2589574e90d5831a00c0140f71d5bfe
2018-08-11layer23: Fix compiler warning about snprintf buffer too smallHarald Welte1-1/+1
gsm322.c:366:22: warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=] sprintf(string, "-%d", 110 - rxlev); ^ gsm322.c:366:2: note: ‘sprintf’ output between 3 and 6 bytes into a destination of size 5 sprintf(string, "-%d", 110 - rxlev); Change-Id: I7b19fef89ba0cb0c1edbdd62c46ad8395e44145b
2018-07-23Move from libc random() to osmo_get_rand_id (2nd attempt)Holger Hans Peter Freyther4-6/+9
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
2018-07-17mobile: use osmo_init_logging2 with proper talloc contextVadim Yanitskiy1-13/+5
Change-Id: I231ac9987ff3c13fafcd272b7d9aae3938ab5972
2018-07-17Revert "Move from libc random() to osmo_get_rand_id"Vadim Yanitskiy4-18/+5
It was decided to migrate to osmo_get_rand_id() and use random() as a fall-back. But there is a critical difference between both functions: osmo_get_rand_id() fills an input buffer with random bytes (0x00 - 0xff), while *random() returns a value in range between 0 and RAND_MAX. osmo_get_rand_id() was used in a wrong way, so in some cases we could get a negative value (how about IMEI starting from '-'?), what isn't expected in many cases and could lead to unexpected behaviour and segmentation faults... This reverts commit 6d49b049ee304f1ea0e4801df61e69713b01f0f8. Change-Id: I7b2a8a5c63cf64360a824926a2219fd7e419b1bb
2018-07-11Move from libc random() to osmo_get_rand_idHolger Hans Peter Freyther4-5/+18
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(). Change-Id: Ie0cc64663cd4b90c027b79545dc5d3ac9d87b9dd
2018-06-17lua: Add API to enable passing credentialsHolger Hans Peter Freyther1-1/+22
This can be useful to have bidirectional communication between the mobile lua script an external control script. Change-Id: Ib4a5eef611f524f5d21cb6a7f4eace22b8ba60d0
2018-06-04mobile/sms: Make it optional to store the SMS on diskHolger Hans Peter Freyther3-4/+36
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
2018-06-02mobile/sms: Simplify the string format routinesHolger Hans Peter Freyther1-4/+1
It seems the original code didn't allocate \0 for the string. Just use talloc_asprintf and get a new string... Change-Id: I8ffb50b04d2d6196caf0231711f3467abc8c5ea5
2018-06-02mobile/sms: Fix memory leak in case the storage can not be openedHolger Hans Peter Freyther1-1/+3
Before jumping to the failure handling code free the sms_file. Change-Id: Ifce2bc130fe3a5bd49ad457ee61002952dd496ba
2018-06-01mobile: Make time spent in c7 configurableHolger Hans Peter Freyther3-1/+21
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
2018-03-14L1CTL/L1CTL_CRYPTO_REQ: add key length and channel infoVadim Yanitskiy1-4/+8
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
2018-02-23mobile: Fix memory leak when not using a LUA scriptHolger Hans Peter Freyther2-2/+1
The primitives are still allocated and dispatched but there was no script handler to delete them. Change the ownership to delete it at the end of the dispatch. Change-Id: I510af13bcbb46f73a0a289f26a4921cc90bd986a Fixes: OS#2925
2018-02-10mobile/primitives.c: fix format string compiler warningVadim Yanitskiy1-3/+7
The recent LUA integration code introduced the following compiler warnings (on GCC 4.8.5): primitives.c: In function ‘create_timer’: primitives.c:90:2: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 7 has type ‘uint64_t’ [-Wformat=] primitives.c: In function ‘cancel_timer’: primitives.c:166:3: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 7 has type ‘uint64_t’ [-Wformat=] The recommended and portable way of printing an 'uint64_t' is to use the corresponding macros 'PRIu64'. Change-Id: Ic7f54063a35a89ad54dfa63868f43009cbe469bb
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 16:06:04 +0000