2986a318b1
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
|
||
|---|---|---|
| .. | ||
| include | ||
| src | ||
| .gitignore | ||
| COPYING | ||
| Makefile.am | ||
| README | ||
| configure.ac | ||
README
= OsmocomBB layer23 architecture = layer23 is an (incomplete) MS-side implementation of the L2 and L3 GSM protocols as described in GSM TS 04.06, 04.08 and others. == Interfaces == L1 (on the phone) uses the L1CTL protocol to talk with layer23 (on the PC). L2 (inside layer23) uses the RSLms protocol to talk with the L3 (inside layer23) === RSLms === RSLms is modeled after the GSM TS 08.58 Radio Subsystem Link protocol. Despite being designed for the network side, RSL seems a good match for the L2/L3 interface inside a MS, too. At least the RLL (Radio Link Layer) part of RSL is 100% as applicable to the MS side as it is for the ntwork side. ==== Lower interface (L2 to RSLms) ==== Layer2 calls rslms_sendmsg() with a msgb that has the msgb->l2h pointing to a RSL header (struct abis_rsl_common_hdr). ==== Upper interface (L3 to RSLms) ==== Layer3 calls rslms_recvmsg() with a msgb that has the msgb->l2h pointing to a RSL header (struct abis_rsl_common_hdr). There are utility functions like rslms_tx_rll_req() and rslms_tx_rsll_req_l3() for creating msgb's with the apropriate RSL/RLL headers. === LAPDm === LAPDm is the GSM TS 04.06 protocol The lower interface (to L1) is using L1CTL The upper interface (to L3) is using RSLms