[RFC] BlueZ D-Bus Sim Access Profile Server API description

[RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi,

Below is the Sim Access Profile server role API discription.
Please let me know your comments.

Regards
Suraj
---
 Makefile.am     |    2 +-
 doc/sap-api.txt |  216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 217 insertions(+), 1 deletions(-)
 create mode 100644 doc/sap-api.txt

diff --git a/Makefile.am b/Makefile.am
index a8829d9..52537bc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -350,7 +350,7 @@ EXTRA_DIST += doc/manager-api.txt \
 		doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
 		doc/serial-api.txt doc/network-api.txt \
 		doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
-		doc/hfp-api.txt doc/assigned-numbers.txt
+		doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
 
 AM_YFLAGS = -d
 
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..9a684fa
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,216 @@
+BlueZ D-Bus Sim Access Profile API description
+**********************************************
+
+Copyright (C) 2009-2010  Atheros Communication Ltd
+
+
+Sim Access Server hierarchy
+===========================
+
+Service	org.bluez
+Interface	org.bluez.SAPServer
+Object path	[variable prefix]/{hci0,hci1,...}
+
+This interface is available for devices which can function as the
+Server role of the Sim Access profiles.
+It is intended to be used with external stacks / handlers of the Sim Access
+protocol.
+
+
+Methods	void RegisterAgent(object agent)
+
+			This registers the Sim Access server agent.
+			This also registers the profile with the service
+			databse and start waiting for an RFCOMM connection
+			on the SAP server channel.
+
+			The object path defines the path the of the agent.
+
+			If an application disconnects from the bus all
+			of its registered agents will be removed.
+
+			Possible errors: org.bluez.Error.InvalidArguments
+					 org.bluez.Error.AlreadyExists
+					 org.bluez.Error.Failed
+
+		void UnregisterAgent(object agent)
+
+			This unregisters the agent that has been previously
+			registered. The object path parameter must match the
+			same value that has been used on registration.
+
+			Possible errors: org.bluez.Error.DoesNotExist
+					 org.bluez.Error.InvalidArguments
+					 org.bluez.Error.Failed
+
+		void Response(string command, string result, object response)
+
+			This sends a SAP response packet to a SAP sequest.
+
+			The command parameter specifies the SAP command for
+			which response is being sent.
+
+			The result parameter specifies the ResultCode for the
+			operation.
+
+			The object response specifies the response packet to
+			be sent if any.
+
+			Below mentioned are the parameters and possible value.
+
+			command     	  result	    	response
+			----------------------------------------------------
+
+			Connect		  OkSuccess		NA
+					  ConnectFailed
+				  	  OkOngoingCall
+
+			APDU		  OkSuccess		array{uint8}
+					  NoReason
+					  CardNotAccessible
+					  CardPoweredOff
+					  CardRemoved
+
+			APDU7816	  OkSuccess		array{uint8}
+					  NoReason
+					  CardNotAccessible
+					  CardPoweredOff
+					  CardRemoved
+
+			ATR		  OkSuccess		array{uint8}
+					  NoReason
+					  CardPoweredOff
+					  CardRemoved
+					  DataNotAvailable
+
+			SimPowerOn	  OkSuccess		NA
+					  NoReason
+					  CardNotAccessible
+					  CardRemoved
+					  CardPoweredOn
+
+			SimPowerOff	  OkSuccess		NA
+					  NoReason
+					  CardPoweredOff
+					  CardRemoved
+
+			Reset		  OkSuccess		NA
+					  NoReason
+					  CardNotAccessible
+					  CardPoweredOff
+					  CardRemoved
+
+			CardReaderStatus  OkSuccess		uint8
+					  NoReason
+					  DataNotAvailable
+
+			TransportProtocol OkSuccess		NA
+					  NotSupported
+
+			Disconnect	  NA	 		NA
+
+			Possible errors: org.bluez.Error.InvalidArguments
+					 org.bluez.Error.Failed
+
+		void Disconnect(string type)
+
+			This initiates a SAP disconnection from SAP server.
+
+			The type parameter specifies the type of disconnection.
+
+			"Graceful"  -> lets the SAP client initiate a
+			garceful disconnection.
+
+			"Immediate" -> disconnects the connection
+			immediately from the server.
+
+		void SetProperty(string name, variant value)
+
+			Changes the value of the specified property. Only
+			properties that are listed a read-write are changeable.
+			On success this will emit a PropertyChanged signal.
+
+			Possible Errors: org.bluez.Error.DoesNotExist
+					 org.bluez.Error.InvalidArguments
+
+		dict GetProperties()
+
+			Returns all properties for the interface. See the
+			properties section for available properties.
+
+			Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals		PropertyChanged(string name, variant value)
+
+			This signal indicates a changed value of the given
+			property.
+
+Properties	string SimStatus [readwrite]
+
+			Specifies the availability of the SIM.
+
+			The possible value are
+
+			"UnknownError"
+			"CardReset"
+			"CardNotAccesible"
+			"CardRemoved"
+			"CardInsterted"
+			"CardRecovered"
+
+		uint16 MaxMessageSize [readwrite]
+
+			The maximum possible message size supported by
+			SAP server.
+
+		uint16 MinMessageSize [readwrite]
+
+			The minimum possible message size supported by
+			SAP server.
+
+		uint16 MessageSize [readonly]
+
+			The negotiated message size for the current connection.
+			This is valid only when there is an active
+			SAP connection.
+
+Sim Access Server Agent hierarchy
+=================================
+
+Service         unique name
+Interface       org.bluez.SAPServerAgent
+Object path     freely definable
+
+Methods		Request(string command, object param)
+
+			This method gets called whenever a SAP request is received
+			from SAP client. This will help deliver the
+			SAP request to the Agent.
+
+			The command parameter specifies the SAP request type
+			received.
+
+			The param parameter specifies the command parameter
+			packet received from SAP client.
+
+			Below mentioned is the parameters and possible value.
+
+			command     	  	parameter
+			----------------------------------------------------
+
+			Connect		  	NA
+			APDU		  	array{uint8}
+			APDU7816	  	array{uint8}
+			ATR		  	NA
+			SimPowerOn	  	NA
+			SimPowerOff	  	NA
+			Reset		  	NA
+			CardReaderStatus  	NA
+			TransportProtocol 	uint8
+			Disconnect		NA
+
+		void Release()
+
+			This method gets called whenever the service daemon
+			unregisters the agent or whenever the Adapter where
+			the SimAccessServerAgent registers itself is removed.
-- 
1.7.0.4

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Johan Hedberg]

Hi Suraj,

On Mon, Sep 13, 2010, Suraj Sumangala wrote:
> +		void Response(string command, string result, object response)

This method should be removed. Instead, you should use the methor return
messages for the commands to relay the response information.

> +Sim Access Server Agent hierarchy
> +=================================
> +
> +Service         unique name
> +Interface       org.bluez.SAPServerAgent
> +Object path     freely definable
> +
> +Methods		Request(string command, object param)

Since the set of SAP commands is fixed and rather short it'd be much
simpler if you have a separate D-Bus method for each command
(particularly from the method and method return signature perspective).
You also seem to have some confusion about what an "object" type
parameter is. It seems you're using it for some sort of variant type
when it will only ever represent a simple object path.

Johan

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Johan,

On 9/13/2010 4:29 PM, Johan Hedberg wrote:
> Hi Suraj,
>
> On Mon, Sep 13, 2010, Suraj Sumangala wrote:
>> +		void Response(string command, string result, object response)
>
> This method should be removed. Instead, you should use the methor return
> messages for the commands to relay the response information.

Ok,

Should we have the method like,
	struct RequestATR(string command, variant param)
	
	where, struct = { string, array{uint8} )
>
>> +Sim Access Server Agent hierarchy
>> +=================================
>> +
>> +Service         unique name
>> +Interface       org.bluez.SAPServerAgent
>> +Object path     freely definable
>> +
>> +Methods		Request(string command, object param)
>
> Since the set of SAP commands is fixed and rather short it'd be much
> simpler if you have a separate D-Bus method for each command
> (particularly from the method and method return signature perspective).
> You also seem to have some confusion about what an "object" type
> parameter is. It seems you're using it for some sort of variant type
> when it will only ever represent a simple object path.

Thanks, My mistake. I was referring to a variant type there.
>
> Johan

Regards
Suraj

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Waldemar.Rymarkiewicz]

Hi Suraj, 

>+		void Disconnect(string type)
>+
>+			This initiates a SAP disconnection from 
>SAP server.
>+
>+			The type parameter specifies the type 
>of disconnection.
>+
>+			"Graceful"  -> lets the SAP client initiate a
>+			garceful disconnection.
>+
>+			"Immediate" -> disconnects the connection
>+			immediately from the server.

How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?

>+Signals		PropertyChanged(string name, variant value)
>+
>+			This signal indicates a changed value 
>of the given
>+			property.

Is the signal really needed?  Who is interested in keeping track on properties?


Thanks,
/Waldek

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Waldek,

On 9/13/2010 5:41 PM, Waldemar.Rymarkiewicz@tieto.com wrote:
> Hi Suraj,
>
>> +		void Disconnect(string type)
>> +
>> +			This initiates a SAP disconnection from
>> SAP server.
>> +
>> +			The type parameter specifies the type
>> of disconnection.
>> +
>> +			"Graceful"  ->  lets the SAP client initiate a
>> +			garceful disconnection.
>> +
>> +			"Immediate" ->  disconnects the connection
>> +			immediately from the server.
>
> How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?

The agent will be in a better position to take this decision as it will 
be interfacing between actual card reader and SAP server.

For example, if the agent is connected to an external card reader and 
it has lost connection with the reader. It can ask for an Immediate 
disconnection.
If disconnection was triggered by a user action, it can decide to call 
this API with Graceful as the parameter.

>
>> +Signals		PropertyChanged(string name, variant value)
>> +
>> +			This signal indicates a changed value
>> of the given
>> +			property.
>
> Is the signal really needed?  Who is interested in keeping track on properties?

One candidate would be when the MessageSize is changed.
Another one will be with the "SimStatus" property. It makes sense to 
raise his signal after the server sends the STATUS IND response 
successfully.

But, it is a fact that most of the Properties are set by the Agent 
itself. So agent will know that they have changed.

>
> Thanks,
> /Waldek

Regards
Suraj

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Waldemar.Rymarkiewicz]

 Hi Suraj,

>The agent will be in a better position to take this decision 
>as it will be interfacing between actual card reader and SAP server.
>
>For example, if the agent is connected to an external card 
>reader and it has lost connection with the reader. It can ask 
>for an Immediate disconnection.

What will happen when dbus connection will be lost?  SAP server will start immediate disconnection. Right?

>If disconnection was triggered by a user action, it can decide 
>to call this API with Graceful as the parameter.

What exactly do you mean "triggerd by a user" ? Does agent interact with the user somehow?  In which way, any API for that? 

>One candidate would be when the MessageSize is changed.
>Another one will be with the "SimStatus" property. It makes 
>sense to raise his signal after the server sends the STATUS 
>IND response successfully.
>
>But, it is a fact that most of the Properties are set by the 
>Agent itself. So agent will know that they have changed.

Exactly.

Thanks,
/Waldek

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Johan Hedberg]

Hi,

> Should we have the method like,
> 	struct RequestATR(string command, variant param)

ATR doesn't take any parameters so it'd be just RequestATR()

> 	where, struct = { string, array{uint8} )

What do you need the string for? Wouldn't an array{uint8} suffice? A
D-Bus error return could be used when the ResultCode in the response
indicates failure.

Johan

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi,

On 9/13/2010 6:50 PM, Johan Hedberg wrote:
> Hi,
>
>> Should we have the method like,
>> 	struct RequestATR(string command, variant param)
>
> ATR doesn't take any parameters so it'd be just RequestATR()
>
>> 	where, struct = { string, array{uint8} )
Yep,
>
> What do you need the string for? Wouldn't an array{uint8} suffice? A
> D-Bus error return could be used when the ResultCode in the response
> indicates failure.

The "array{uint8}" is just the ATR response from the card reader. it is 
not a complete Bluetoth SAP response packet. We need to encapsulate ATR 
packet to form a Bluetooth SAP response packet. The packet will be roughly.

|Response code|Param1|Param data ( ResultCode )|param2|param data (ATR)|

The ResultCode will have to be mapped as 1 byte result code in the SAP 
response packet sent to the client.

How do we map the D-Bus error return to the ResultCode?

>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards
Suraj

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Waldek,

On 9/13/2010 6:17 PM, Waldemar.Rymarkiewicz@tieto.com wrote:
>   Hi Suraj,
>
>> The agent will be in a better position to take this decision
>> as it will be interfacing between actual card reader and SAP server.
>>
>> For example, if the agent is connected to an external card
>> reader and it has lost connection with the reader. It can ask
>> for an Immediate disconnection.
>
> What will happen when dbus connection will be lost?  SAP server will start immediate disconnection. Right?
Yes,
>
>> If disconnection was triggered by a user action, it can decide
>> to call this API with Graceful as the parameter.
>
> What exactly do you mean "triggerd by a user" ? Does agent interact with the user somehow?  In which way, any API for that?
Here we only specifies the interface required by the Agent using SAP 
server. The agent implementation will depend on the actual system which 
uses SAP server.

For example, if we have use ofono. The agent will be implemented as part 
of ofono's implementation. This will be similar to the way Handsfree 
Gateway is implemented.

>
>> One candidate would be when the MessageSize is changed.
>> Another one will be with the "SimStatus" property. It makes
>> sense to raise his signal after the server sends the STATUS
>> IND response successfully.
>>
>> But, it is a fact that most of the Properties are set by the
>> Agent itself. So agent will know that they have changed.
>
> Exactly.
>
> Thanks,
> /Waldek

Regards
Suraj

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Johan Hedberg]

Hi,

On Mon, Sep 13, 2010, Suraj Sumangala wrote:
> The "array{uint8}" is just the ATR response from the card reader. it
> is not a complete Bluetoth SAP response packet. We need to
> encapsulate ATR packet to form a Bluetooth SAP response packet. The
> packet will be roughly.
> 
> |Response code|Param1|Param data ( ResultCode )|param2|param data (ATR)|
> 
> The ResultCode will have to be mapped as 1 byte result code in the
> SAP response packet sent to the client.

Why would you want to expose these extra SAP profile details to the
Agent? The bluetoothd side should take care of all details like this
whenever possible. The only relevant data that needs to be transmitted
from the Agent to bluetoothd in this case is the ATR and bluetoothd can
then proceed with creating a proper SAP response packet based on that.

> How do we map the D-Bus error return to the ResultCode?

You'd need to define some sort of mapping table yourself. The list of
possible result codes is quite short (8 in SAP 1.1) so this shouldn't be
too hard. E.g. "Error, card not accessible" (0x02) could map to the
D-Bus error org.bluez.SapError.CardNotAccessible.

Johan

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi,
On 9/13/2010 10:17 PM, Johan Hedberg wrote:

> Why would you want to expose these extra SAP profile details to the
> Agent? The bluetoothd side should take care of all details like this
> whenever possible. The only relevant data that needs to be transmitted
> from the Agent to bluetoothd in this case is the ATR and bluetoothd can
> then proceed with creating a proper SAP response packet based on that.
>
>> How do we map the D-Bus error return to the ResultCode?
>
> You'd need to define some sort of mapping table yourself. The list of
> possible result codes is quite short (8 in SAP 1.1) so this shouldn't be
> too hard. E.g. "Error, card not accessible" (0x02) could map to the
> D-Bus error org.bluez.SapError.CardNotAccessible.

The idea was to return the ResultCode as a string from the agent and map 
it to the corresponding code in the server.

If we can define error codes for each result, that would be fine.
>
> Johan

Regards
Suraj

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Marcel Holtmann]

Hi Suraj,

> Below is the Sim Access Profile server role API discription.
> Please let me know your comments.

my obvious question is why do we wanna do this over D-Bus and not
connect it directly to the hardware via a plugin?

Remember that SIM transaction are timing critical and just relaying them
over D-Bus doesn't sound the right approach right now. While of course
even bluetoothd can't guarantee and response time, it is clearly better
than over D-Bus.

Regards

Marcel

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Marcel,

On 9/14/2010 11:12 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Below is the Sim Access Profile server role API discription.
>> Please let me know your comments.
>
> my obvious question is why do we wanna do this over D-Bus and not
> connect it directly to the hardware via a plugin?

You meant creating something like a tty device and let the hardware 
connect directly to this?

The initial plan was to use a D-Bus file descriptor and transfer the SAP 
packets to the agent over it.

The problem was the SAP packet format is specified by the Bluetooth SAP 
spec. I could not relate it to any generic packet format ( Like HF, HS, 
DUN can be mapped to an AT parser).

I am not sure if any existing card reader implementation could parse it 
to extract SIM card related data (APDU) without additional support for it.

Another reason I thought about D-Bus was because, most of the SAP 
operations are Request/Response type like Reset, SimOn etc.

It mapped better with a Method/Signal communication than packet transfer.

Some of the card reader implementation I checked had proprietary packet 
format. So not sure how we could interface with them.
>
> Remember that SIM transaction are timing critical and just relaying them
> over D-Bus doesn't sound the right approach right now. While of course
> even bluetoothd can't guarantee and response time, it is clearly better
> than over D-Bus.
>

I would really appreciate if you can give me any idea about working 
around the above mentioned issues.

> Regards
>
> Marcel
>
>

Regards
Suraj

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Marcel Holtmann]

Hi Suraj,

> >> Below is the Sim Access Profile server role API discription.
> >> Please let me know your comments.
> >
> > my obvious question is why do we wanna do this over D-Bus and not
> > connect it directly to the hardware via a plugin?
> 
> You meant creating something like a tty device and let the hardware 
> connect directly to this?
> 
> The initial plan was to use a D-Bus file descriptor and transfer the SAP 
> packets to the agent over it.
> 
> The problem was the SAP packet format is specified by the Bluetooth SAP 
> spec. I could not relate it to any generic packet format ( Like HF, HS, 
> DUN can be mapped to an AT parser).
> 
> I am not sure if any existing card reader implementation could parse it 
> to extract SIM card related data (APDU) without additional support for it.
> 
> Another reason I thought about D-Bus was because, most of the SAP 
> operations are Request/Response type like Reset, SimOn etc.
> 
> It mapped better with a Method/Signal communication than packet transfer.
> 
> Some of the card reader implementation I checked had proprietary packet 
> format. So not sure how we could interface with them.
> >
> > Remember that SIM transaction are timing critical and just relaying them
> > over D-Bus doesn't sound the right approach right now. While of course
> > even bluetoothd can't guarantee and response time, it is clearly better
> > than over D-Bus.
> >
> 
> I would really appreciate if you can give me any idea about working 
> around the above mentioned issues.

if we talk about the SAP server role found in a mobile phone, then that
support clearly needs to interact with the telephony stack. Since when
SAP is active the telephony stack needs to be suspended and all SIM
transaction being forwarded.

Currently I would be thinking that the SAP implementation should be done
inside oFono actually. Since then you have direct access to the
hardware. The D-Bus approach just doesn't sound correct to me. I could
be of course wrong, but I can't wrap my mind around on how you can make
this work.

Even with file descriptor passing this doesn't look like the right
approach. If we need a hardware abstraction than we either use oFono or
we have to create some SAP hardware access abstraction.

The SAP client role found a carkit is obviously a different story.

Regards

Marcel

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Marcel,

On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>
>> I would really appreciate if you can give me any idea about working
>> around the above mentioned issues.
>
> if we talk about the SAP server role found in a mobile phone, then that
> support clearly needs to interact with the telephony stack. Since when
> SAP is active the telephony stack needs to be suspended and all SIM
> transaction being forwarded.
>
> Currently I would be thinking that the SAP implementation should be done
> inside oFono actually. Since then you have direct access to the
> hardware. The D-Bus approach just doesn't sound correct to me. I could
> be of course wrong, but I can't wrap my mind around on how you can make
> this work.
>
> Even with file descriptor passing this doesn't look like the right
> approach. If we need a hardware abstraction than we either use oFono or
> we have to create some SAP hardware access abstraction.

The advantage I thought d-bus has would be the generic interface it 
could provide. But, if we have a system with direct access to the Sim 
access hardware, D-bus could possibly become a bottleneck.

I would really appreciate if others who have worked with Sim Access and 
OFono can give their comments.

Also, please share some information on regarding the SIM reader 
implementation in linux based systems.

>
> The SAP client role found a carkit is obviously a different story.
>
> Regards
>
> Marcel
>
>
Regards
Suraj

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Nicolas GUILBAUD]

Hello Marcel and Suraj,

-----Message d'origine-----
De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth-owner@vger.kernel.org] De la part de Suraj =
Sumangala
Envoy=E9=A0: mercredi 15 septembre 2010 08:14
=C0=A0: Marcel Holtmann
Cc=A0: Suraj Sumangala; linux-bluetooth@vger.kernel.org; Jothikumar =
Mothilal
Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description

>Hi Marcel,
>
>On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
>> Hi Suraj,
>>
>>>
>>> I would really appreciate if you can give me any idea about working
>>> around the above mentioned issues.
>>
>> if we talk about the SAP server role found in a mobile phone, then =
that
>> support clearly needs to interact with the telephony stack. Since =
when
>> SAP is active the telephony stack needs to be suspended and all SIM
>> transaction being forwarded.
>>
>> Currently I would be thinking that the SAP implementation should be =
done
>> inside oFono actually. Since then you have direct access to the
>> hardware. The D-Bus approach just doesn't sound correct to me. I =
could
>> be of course wrong, but I can't wrap my mind around on how you can =
make
>> this work.
>>
>> Even with file descriptor passing this doesn't look like the right
>> approach. If we need a hardware abstraction than we either use oFono =
or
>> we have to create some SAP hardware access abstraction.
>
>The advantage I thought d-bus has would be the generic interface it=20
>could provide. But, if we have a system with direct access to the Sim=20
>access hardware, D-bus could possibly become a bottleneck.
>
>I would really appreciate if others who have worked with Sim Access and =

>OFono can give their comments.
>
>Also, please share some information on regarding the SIM reader=20
>implementation in linux based systems.
>
>>
>> The SAP client role found a carkit is obviously a different story.
>>
>> Regards
>>
>> Marcel
>>
>>
>Regards
>Suraj

I agree with Marcel, because in standard Mobile phone implementation, =
the SIM card is directly connected to the Modem. To access the SIM card, =
AT command (or proprietary commands) are needed, oFono implements both =
of them to access SIM card in Modem side, but in my understanding there =
is no possibilities to disconnect modem (in oFono) due to SIM SAP.

In the case where SIM card is connected to the Application processor =
(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any SIM implementation in Linux, may be we have to specify it.=20


Best Regards,

Nicolas.

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi Nicolas,

On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
> Hello Marcel and Suraj,
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.
>
> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it.
>
Other than transferring APDUs, SAP profile also specifies operations on 
the SIM cards like SIM Reset, SIM power on/off, Getting Card reader 
status etc.

How do we do these operations case of mobile phones?

>
> Best Regards,
>
> Nicolas.

Regards
Suraj

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Nicolas GUILBAUD]

>-----Message d'origine-----
>De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth->owner@vger.kernel.org] De la part de Suraj =
Sumangala
>Envoy=E9=A0: mercredi 15 septembre 2010 10:25
>=C0=A0: Nicolas GUILBAUD
>Cc=A0: Suraj Sumangala; Marcel Holtmann; =
linux-bluetooth@vger.kernel.org; >Jothikumar Mothilal
>Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>
>Hi Nicolas,
>
>On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
>> Hello Marcel and Suraj,
>>
>> I agree with Marcel, because in standard Mobile phone implementation, =
the >SIM card is directly connected to the Modem. To access the SIM =
card, AT >command (or proprietary commands) are needed, oFono implements =
both of them >to access SIM card in Modem side, but in my understanding =
there is no >possibilities to disconnect modem (in oFono) due to SIM =
SAP.
>>
>> In the case where SIM card is connected to the Application processor =
>(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any >SIM implementation in Linux, may be we have to specify it.
>>
>Other than transferring APDUs, SAP profile also specifies operations on =

>the SIM cards like SIM Reset, SIM power on/off, Getting Card reader=20
>status etc.
>
>How do we do these operations case of mobile phones?

There are specific interfaces, you can find example of interface in =
Nokia Wireless Open API (uicc_fp.pdf) in =
http://www.wirelessmodemapi.com/, register is free.

SIM reset is an OFF command following by ON command (ATR comes with ON), =
card status is a local information...=20


Best Regards,
Nicolas.

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Waldemar.Rymarkiewicz]

Hi Marcel,=20

>if we talk about the SAP server role found in a mobile phone,=20
>then that support clearly needs to interact with the telephony=20
>stack. Since when SAP is active the telephony stack needs to=20
>be suspended and all SIM transaction being forwarded.

I agree, but a telephony stack needs to care about its state when SAP is ac=
tive. Not all linux based mobile platforms use ofono.

>Currently I would be thinking that the SAP implementation=20
>should be done inside oFono actually. Since then you have=20
>direct access to the hardware. The D-Bus approach just doesn't=20
>sound correct to me. I could be of course wrong, but I can't=20
>wrap my mind around on how you can make this work.

I assume that ofono should handle sap transactions (as it's kind of hardwar=
e abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did fo=
r sap transactions in spec (http://www.wirelessmodemapi.com/), and not impl=
ement sap profile itself.  Again, not all use ofono as telephony stack.

Sorry, I don't know ofono well. What's the interface between ofono and blue=
z?=20

>Even with file descriptor passing this doesn't look like the=20
>right approach. If we need a hardware abstraction than we=20
>either use oFono or we have to create some SAP hardware access=20
>abstraction.

I agree with this too. I prefere to have a sap implementation as bluez plug=
in, but we need to define api for sim operations which could be implemented=
 in ofono or other proprietary stacks. I guess dbus was intended to be kind=
 of hw abstraction api.
Some time ago Claudio sent proposal implementation of sap server where he d=
efined api for a driver to sim.

Regards,
/Waldek=

Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Suraj Sumangala]

Hi,

> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.

The main question will be
"where should be SAP profile packet handling be implemented?"

1. If it has to be implemented as part of bluetoothd, there is no other 
option other than using dbus so that we have a consistent interface for 
all modules who would be interested in using it.

2. If it has to be done in the "modem/SIM reader", then it will be part 
of that module, not an independent module.

will all SIM card reader implementation be ready to implement a 
Bluetooth SAP parser as part of it just to support Bluetooth as transport?

>
> Regards,
> /Waldek

Regards
Suraj

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Marcel Holtmann]

Hi Nicolas,

> >>> I would really appreciate if you can give me any idea about working
> >>> around the above mentioned issues.
> >>
> >> if we talk about the SAP server role found in a mobile phone, then that
> >> support clearly needs to interact with the telephony stack. Since when
> >> SAP is active the telephony stack needs to be suspended and all SIM
> >> transaction being forwarded.
> >>
> >> Currently I would be thinking that the SAP implementation should be done
> >> inside oFono actually. Since then you have direct access to the
> >> hardware. The D-Bus approach just doesn't sound correct to me. I could
> >> be of course wrong, but I can't wrap my mind around on how you can make
> >> this work.
> >>
> >> Even with file descriptor passing this doesn't look like the right
> >> approach. If we need a hardware abstraction than we either use oFono or
> >> we have to create some SAP hardware access abstraction.
> >
> >The advantage I thought d-bus has would be the generic interface it 
> >could provide. But, if we have a system with direct access to the Sim 
> >access hardware, D-bus could possibly become a bottleneck.
> >
> >I would really appreciate if others who have worked with Sim Access and 
> >OFono can give their comments.
> >
> >Also, please share some information on regarding the SIM reader 
> >implementation in linux based systems.
> >
> >>
> >> The SAP client role found a carkit is obviously a different story.
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.

that is just because we haven't gotten there yet. Of course if SAP takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.

> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it. 

There is a framework for card services in general, but I think that is
just pure overhead for this.

And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.

However in the end this all depends on the hardware and right now I have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?

Regards

Marcel

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Marcel Holtmann]

Hi Waldemar,

> >if we talk about the SAP server role found in a mobile phone, 
> >then that support clearly needs to interact with the telephony 
> >stack. Since when SAP is active the telephony stack needs to 
> >be suspended and all SIM transaction being forwarded.
> 
> I agree, but a telephony stack needs to care about its state when SAP is active. Not all linux based mobile platforms use ofono.

I think they should use oFono of course since that is the only way to be
modem hardware agnostic in the long run.

> >Currently I would be thinking that the SAP implementation 
> >should be done inside oFono actually. Since then you have 
> >direct access to the hardware. The D-Bus approach just doesn't 
> >sound correct to me. I could be of course wrong, but I can't 
> >wrap my mind around on how you can make this work.
> 
> I assume that ofono should handle sap transactions (as it's kind of hardware abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did for sap transactions in spec (http://www.wirelessmodemapi.com/), and not implement sap profile itself.  Again, not all use ofono as telephony stack.
> 
> Sorry, I don't know ofono well. What's the interface between ofono and bluez? 

In this case there will be no direct interface besides oFono registering
the SDP records for SAP.

> >Even with file descriptor passing this doesn't look like the 
> >right approach. If we need a hardware abstraction than we 
> >either use oFono or we have to create some SAP hardware access 
> >abstraction.
> 
> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.

I still don't see this as a really good idea. We want modem abstraction
inside oFono and not all over the place.

Regards

Marcel

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Nicolas GUILBAUD]

Hi Marcel,

-----Message d'origine-----
De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth-owner@vger.kernel.org] De la part de Marcel =
Holtmann
Envoy=E9=A0: vendredi 17 septembre 2010 01:00
=C0=A0: Nicolas GUILBAUD
Cc=A0: Suraj Sumangala; Suraj Sumangala; =
linux-bluetooth@vger.kernel.org; Jothikumar Mothilal
Objet=A0: RE: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description


>>that is just because we haven't gotten there yet. Of course if SAP =
takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.

Do you have information about the release date of this feature? And =
about the interface to lockdown, is it a D-BUS message?=20


>There is a framework for card services in general, but I think that is
just pure overhead for this.

>And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.

Yes but an APDU interface is needed in the SIM driver of oFono, I don't =
see any interface of this kind in the source code.

Maybe it's not the good place to speak about that.

>However in the end this all depends on the hardware and right now I =
have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?

Yes we have, it's Renesas Modem solution.


Regards

Nicolas


--
To unsubscribe from this list: send the line "unsubscribe =
linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description

[Marcel Holtmann]

Hi Nicolas,

> >>that is just because we haven't gotten there yet. Of course if SAP takes
> over we have to shutdown oFono's handling of the modem. This could be
> done similar to the support for Lockdown we have in the oFono TODO list.
> 
> Do you have information about the release date of this feature? And about the interface to lockdown, is it a D-BUS message? 

good one ;)

We know that we need such or similar feature for firmware updates where
we have to essentially shutdown oFono from driving the modem for a
period of time. The details are not 100% clear. For firmware updates
this has to be a D-Bus method, actually D-Bus property on the modem
interface.

In theory we can even extend this to do this internally as well. So that
an oFono plugin could lock down the modem. Things we clearly have to
figure out at some point.

> >There is a framework for card services in general, but I think that is
> just pure overhead for this.
> 
> >And to be honest, my current thinking is that even for pure SIM card
> readers with APDU mode, we might wanna support them via oFono anyway.
> Having to add SAP support in multiple levels is a bad idea.
> 
> Yes but an APDU interface is needed in the SIM driver of oFono, I don't see any interface of this kind in the source code.

Because we haven't had any hardware that does this so far. You will only
see code in oFono once we had hardware in our hands that is able of
doing this and we know how to drive it.

> Maybe it's not the good place to speak about that.

Essentially the oFono mailing list is a better place for such a
discussion.

> >However in the end this all depends on the hardware and right now I have
> not had access to SAP capable hardware. Or maybe I did and I didn't know
> it yet. Do we have any target hardware in mind?
> 
> Yes we have, it's Renesas Modem solution.

Any chance you guys could add Renesas Modem support to oFono and then us
some samples?

Regards

Marcel