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
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
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
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
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
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
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
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
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
The actual L1CTL header is pointed by 'msg->l1h', not 'l2h'!
Since msg->l2h is NULL (because nobody set it), the result of
msgb_l2len() would always be bigger than size of L1CTL header,
as it is calculated in the following way:
return msgb->tail - (uint8_t *)msgb_l2(msgb);
So, in case if 'msg->l2h' is NULL, it turns into:
return msgb->tail - 0;
Change-Id: I7fe2e00bb45ba07c9bb7438445eededfa09c96f3
In l1ctl_recv() we actually expect to 'see' the L1CTL header
instead of the DL info header. Let's fix this.
Change-Id: Ic7d017bef04f3c186565d5dade36959df1019bd8
There is no need to keep the L1CTL header in messages being sent
towards the upper layers, but the L1 info header can be used by
L2&3 to obtain some information, e.g. TDMA frame number.
Change-Id: Id64249f1b7a1c2be578263ba62aa195c452ab7e8
Oliver Smith
Philipp Maier
Harald Welte
Vadim Yanitskiy
Vadim Yanitskiy
Pau Espin
Martin Hauke