Commit Graph

4 Commits

Author SHA1 Message Date
Oliver Smith 1741372556 treewide: remove FSF address
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
2021-12-14 12:52:04 +00:00
Martin Hauke 1f7a2ab5d3 Fix common misspellings and typos
Change-Id: I962b42871693f33b1054d43d195817e9cd84bb64
2019-10-17 08:07:39 +00:00
Vadim Yanitskiy 2986a318b1 layer23/sap_interface.c: reimplement (BT)SAP interface
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-15 04:26:46 +07:00
Vadim Yanitskiy d2004ae4f6 layer23/sap_interface.c: separate protocol definition
Change-Id: Iad9b3d88b02cc7ec4cf64483bbc85e3a61c9ad10
2019-01-07 15:39:52 +00:00