Hi,
Please find the Git tree for the Sim access profile server role
implementation I have been working on at
git://gitorious.org/sap-server/sap-server.git
Not sure it could be directly used with Bluez. Nevertheless, it has the
parser implementation of Bluetooth SAP packet. Someone could possibly
reuse it in their implementation.
Regards
Suraj
Hi Waldek,
On 10/6/2010 3:02 PM, [email protected] wrote:
>
> Hi Marcel,
>
>>>
>>> Can you share that code with us. And also hardware if you. We
>> are still
>>> having hard time to find proper hardware to test this on.
>>
>> Will send a patch soon. I use
>> http://www.stericsson.com/platforms/U8500.jsp hw, but need to
>> check if I can share one with you.
>>
>
> Here you are the patch. Just note that it is based on an old bluez 4.4x
> If you consider to accept the design I will update the patch upon the latest release.
>
> Will appreciate any comments.
>
> Thanks,
> /Waldek
Which part of this is the driver and which is the agent here?
If I am not mistaken, you are sending the responses directly from code
here, how can we extend this to another hardware/agent without source
code change?
I don't see D-bus being used other than for set/get property.
Correct me if my understanding is wrong.
Regards
Suraj
Hi Marcel,=20
>in general I am fine if we do this similar to what we do with=20
>the different telephony backend. So yes, go ahead with this.
>
>However, please clean this up. The patch needs a lot of work=20
>before it would be ready upstream. And of course it requires a=20
>dummy SAP plugin as well. Same as we do have for telephony.
>
Then, I will prepare it for upstream.=20
Regards,
/Waldek
Hi Waldemar,
> >>Can you share that code with us. And also hardware if you. We
> >are still
> >>having hard time to find proper hardware to test this on.
> >
> >Will send a patch soon. I use
> >http://www.stericsson.com/platforms/U8500.jsp hw, but need to
> >check if I can share one with you.
> >
>
> Here you are the patch. Just note that it is based on an old bluez 4.4x
> If you consider to accept the design I will update the patch upon the latest release.
in general I am fine if we do this similar to what we do with the
different telephony backend. So yes, go ahead with this.
However, please clean this up. The patch needs a lot of work before it
would be ready upstream. And of course it requires a dummy SAP plugin as
well. Same as we do have for telephony.
Regards
Marcel
Hi Suraj,
=20
>
>So basically your implementation does not use d-bus for basic=20
>SAP operations and the SIM access driver is compiled as part=20
>of bluetoothd right?
>
>>
>>> Correct me if my understanding is wrong.
>>>
Exactly.
Regards,
/Waldek
Hi Waldek,
On 10/6/2010 3:43 PM, [email protected] wrote:
> Hi suraj,
>
>> Which part of this is the driver and which is the agent here?
>
> sap-ste.c is a driver for u8500 platform. The agent is not involved in this design.
>
>> If I am not mistaken, you are sending the responses directly
>>from code here, how can we extend this to another
>> hardware/agent without source code change?
>
> You are right. You can add a new driver that implements interfaces in sap.h then configure with ./configure --enable-sap=yes --with-sap=DRIVER
> You don't have to modify the code, but you have to rebuild with your driver. Usually, there will be one driver per platform so it shoudl not be a problem.
>
>> I don't see D-bus being used other than for set/get property.
>
> We use D-bus only for enable/disable sap server. Data flow to sim is done over unix sockets (for u8500) as I have doubts to dbus reliability. However, it's good option to do tests with dbus oriented design as discussed before.
So basically your implementation does not use d-bus for basic SAP
operations and the SIM access driver is compiled as part of bluetoothd
right?
>
>> Correct me if my understanding is wrong.
>>
>
> Regards,
> /Waldek
Regards
Suraj
Hi suraj,=20
>Which part of this is the driver and which is the agent here?
sap-ste.c is a driver for u8500 platform. The agent is not involved in this=
design.
>If I am not mistaken, you are sending the responses directly=20
>from code here, how can we extend this to another=20
>hardware/agent without source code change?
You are right. You can add a new driver that implements interfaces in sap.h=
then configure with ./configure --enable-sap=3Dyes --with-sap=3DDRIVER
You don't have to modify the code, but you have to rebuild with your driver=
. Usually, there will be one driver per platform so it shoudl not be a prob=
lem.
>I don't see D-bus being used other than for set/get property.
We use D-bus only for enable/disable sap server. Data flow to sim is done o=
ver unix sockets (for u8500) as I have doubts to dbus reliability. However,=
it's good option to do tests with dbus oriented design as discussed before=
.
>Correct me if my understanding is wrong.
>
Regards,
/Waldek=
Hi Waldek,
On 10/6/2010 3:02 PM, [email protected] wrote:
>
> Hi Marcel,
>
>>>
>>> Can you share that code with us. And also hardware if you. We
>> are still
>>> having hard time to find proper hardware to test this on.
>>
>> Will send a patch soon. I use
>> http://www.stericsson.com/platforms/U8500.jsp hw, but need to
>> check if I can share one with you.
>>
>
> Here you are the patch. Just note that it is based on an old bluez 4.4x
> If you consider to accept the design I will update the patch upon the latest release.
>
> Will appreciate any comments.
>
> Thanks,
> /Waldek
Which part of this is the driver and which is the agent here?
If I am not mistaken, you are sending the responses directly from code
here, how can we extend this to another hardware/agent without source
code change?
I don't see D-bus being used other than for set/get property.
Correct me if my understanding is wrong.
Regards
Suraj
Hi Marcel,
>>
>>Can you share that code with us. And also hardware if you. We
>are still
>>having hard time to find proper hardware to test this on.
>
>Will send a patch soon. I use
>http://www.stericsson.com/platforms/U8500.jsp hw, but need to
>check if I can share one with you.
>
Here you are the patch. Just note that it is based on an old bluez 4.4x
If you consider to accept the design I will update the patch upon the latest release.
Will appreciate any comments.
Thanks,
/Waldek
Marcel,
>
>please no top posting on this mailing list.
>
Sorry, didn't know that. Thanks for pointing this out.
>> I understand you concerns about dbus reliability and I agree=20
>with you , but I guess we should find a compromise solution as=20
>ofono is not used widely in Linux mobile platforms nowadays.
>>=20
>> I my view, combination of a bluez plugin for sap and a=20
>platform dependend sim driver is a reliable and most available=20
>solution so far. The SAP plugin implements BT SAP spec and=20
>require simple API (connect, disconnect, apdu, atr, status)=20
>which is implemented in SIM driver for a certain platform.=20
>This way it's relatively easy to support SAP in different=20
>platforms. Ofono can have its own driver as well.
>>=20
>> What's you view on such design?
>> Can we also have a double solution one in ofono for ofono=20
>aware platforms and the second as a plugin for others?=20
>
>I am fine with starting this in BlueZ and see how far we get.=20
>And yes, plugin based is a must from my point of view. It is=20
>most likely similar to our different telephony drivers for=20
>Handsfree support.
It's nice to here that.
>We will move strongly in the direction of oFono being the main=20
>telephony stack. So I do care mostly that this work in=20
>conjunction with oFono.
>Everything else is just a nice benefit if it doesn't clutter=20
>the overhaul implementation and requires pointless abstraction=20
>everywhere.
>> BTW, I already have this implemented and tested with real hardware=20
>> (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
>
>Can you share that code with us. And also hardware if you. We=20
>are still having hard time to find proper hardware to test this on.
Will send a patch soon. I use http://www.stericsson.com/platforms/U8500.jsp=
hw, but need to check if I can share one with you.
Regards,
/Waldek=
Hi Waldemar,
On 10/5/2010 5:42 PM, Marcel Holtmann wrote:
> Hi Waldemar,
>
> please no top posting on this mailing list.
>
>> I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
>>
>> I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
>>
>> What's you view on such design?
>> Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
>
> I am fine with starting this in BlueZ and see how far we get. And yes,
> plugin based is a must from my point of view. It is most likely similar
> to our different telephony drivers for Handsfree support.
>
> We will move strongly in the direction of oFono being the main telephony
> stack. So I do care mostly that this work in conjunction with oFono.
> Everything else is just a nice benefit if it doesn't clutter the
> overhaul implementation and requires pointless abstraction everywhere.
>
>> BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
>
> Can you share that code with us. And also hardware if you. We are still
> having hard time to find proper hardware to test this on.
>
> Regards
>
> Marcel
>
>
Do let me know if you had to make some changes in the SAP implementation
for it to work.
It will be great if you can share the code in that case. I can update my
implementation accordingly.
Regards
Suraj
Hi Waldemar,
please no top posting on this mailing list.
> I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
>
> I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
>
> What's you view on such design?
> Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
I am fine with starting this in BlueZ and see how far we get. And yes,
plugin based is a must from my point of view. It is most likely similar
to our different telephony drivers for Handsfree support.
We will move strongly in the direction of oFono being the main telephony
stack. So I do care mostly that this work in conjunction with oFono.
Everything else is just a nice benefit if it doesn't clutter the
overhaul implementation and requires pointless abstraction everywhere.
> BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
Can you share that code with us. And also hardware if you. We are still
having hard time to find proper hardware to test this on.
Regards
Marcel
Hi Marcel,
I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
What's you view on such design?
Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
Regards,
/Waldek
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of
>Marcel Holtmann
>Sent: Tuesday, October 05, 2010 10:02 AM
>To: suraj
>Cc: [email protected]; Jothikumar Mothilal
>Subject: Re: Sim Access profile server implementation
>
>Hi Suraj,
>
>> Please find the Git tree for the Sim access profile server role
>> implementation I have been working on at
>>
>> git://gitorious.org/sap-server/sap-server.git
>>
>> Not sure it could be directly used with Bluez. Nevertheless, it has
>> the parser implementation of Bluetooth SAP packet. Someone could
>> possibly reuse it in their implementation.
>
>have you actually tested this with real SAP server capable
>hardware? I am still not convinced at all to push APDU over
>D-Bus. First, there is potential security issue here and
>second the latency that D-Bus introduces seems not be
>acceptable. So what I am getting it, can this be actually used
>in a product that seriously wants to support SAP server?
>
>Regards
>
>Marcel
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-bluetooth" in the body of a message to
>[email protected] More majordomo info at
>http://vger.kernel.org/majordomo-info.html
>
Hi Marcel,
On 10/5/2010 1:32 PM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Please find the Git tree for the Sim access profile server role
>> implementation I have been working on at
>>
>> git://gitorious.org/sap-server/sap-server.git
>>
>> Not sure it could be directly used with Bluez. Nevertheless, it has the
>> parser implementation of Bluetooth SAP packet. Someone could possibly
>> reuse it in their implementation.
>
> have you actually tested this with real SAP server capable hardware? I
> am still not convinced at all to push APDU over D-Bus. First, there is
> potential security issue here and second the latency that D-Bus
> introduces seems not be acceptable. So what I am getting it, can this be
> actually used in a product that seriously wants to support SAP server?
No, This was tested with a dummy Agent and PTS. I am yet to get hold of
a hardware.
The reason for sharing the source code was because any later SAP server
implementation can re-use the SAP packet parser implementation I have
already done.
I think we should be able to change the interface later depending on the
actual hardware/system requirement. But, I believe the internal
implementation could stay the same.
>
> Regards
>
> Marcel
>
>
Regards
Suraj
Hi Suraj,
> Please find the Git tree for the Sim access profile server role
> implementation I have been working on at
>
> git://gitorious.org/sap-server/sap-server.git
>
> Not sure it could be directly used with Bluez. Nevertheless, it has the
> parser implementation of Bluetooth SAP packet. Someone could possibly
> reuse it in their implementation.
have you actually tested this with real SAP server capable hardware? I
am still not convinced at all to push APDU over D-Bus. First, there is
potential security issue here and second the latency that D-Bus
introduces seems not be acceptable. So what I am getting it, can this be
actually used in a product that seriously wants to support SAP server?
Regards
Marcel