Re: [PATCH 2/6] stk-api.txt. Introduce the new API ConfirmOpenChannel

[Denis Kenzior]

Hi Marcel,

On 04/08/2011 11:36 AM, Marcel Holtmann wrote:
> Hi Philippe,
> 
>>  doc/stk-api.txt |7 +++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/stk-api.txt b/doc/stk-api.txt
>> index 0bcc6b5..aaa9fba 100644
>> --- a/doc/stk-api.txt
>> +++ b/doc/stk-api.txt
>> @@ -278,6 +278,13 @@ Methods byte RequestSelection(string title, 
>> byte icon_id,
>>  
>>  Possible Errors: [service].Error.SimToolkit.EndSession
>>  
>> +boolean ConfirmOpenChannel(string information, byte icon_id)
>> +
>> +Asks the agent to request user to confirm the channel
>> +set-up.
>> +
>> +Possible Errors: [service].Error.SimToolkit.EndSession
>> +
> 
> we need to talk a bit about these boolean return parameters for
> confirmation. Since essentially a positive D-Bus reply can be considered
> as TRUE and a D-Bus error as FALSE. So this essentially implicit.
> 
> You can not return FALSE and an error. That is not how D-Bus works.

Actually I'm fine with this.  The error has a different intent.

There are three potential outcomes of this operation:

- User accepts (True)
- User Rejects (False)
- User decides to end the session, which in addition to rejecting the
command as above, also reboots the STK session.

Unless you want to introduce org.ofono.Error.SimToolkit.UserRejected,
which to me looks ugly.

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH 2/6] stk-api.txt. Introduce the new API ConfirmOpenChannel

[Marcel Holtmann]

Hi Philippe,

>  doc/stk-api.txt |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/stk-api.txt b/doc/stk-api.txt
> index 0bcc6b5..aaa9fba 100644
> --- a/doc/stk-api.txt
> +++ b/doc/stk-api.txt
> @@ -278,6 +278,13 @@ Methods  byte RequestSelection(string title, 
> byte icon_id,
>  
>   Possible Errors: [service].Error.SimToolkit.EndSession
>  
> + boolean ConfirmOpenChannel(string information, byte icon_id)
> +
> + Asks the agent to request user to confirm the channel
> + set-up.
> +
> + Possible Errors: [service].Error.SimToolkit.EndSession
> +

we need to talk a bit about these boolean return parameters for
confirmation. Since essentially a positive D-Bus reply can be considered
as TRUE and a D-Bus error as FALSE. So this essentially implicit.

You can not return FALSE and an error. That is not how D-Bus works.

Regards

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 6/6] stk: Introduce BIP command handlers

[Philippe Nunes]

---
 src/stk.c |  506 ++---
 1 files changed, 484 insertions(+), 22 deletions(-)

diff --git a/src/stk.c b/src/stk.c
index c86cbfb..e033df7 100644
--- a/src/stk.c
+++ b/src/stk.c
@@ -79,6 +79,10 @@ struct ofono_stk {
 
__ofono_sms_sim_download_cb_t sms_pp_cb;
void *sms_pp_userdata;
+   struct stk_channel channel;
+   struct stk_channel_data rx_buffer;
+   struct stk_channel_data tx_buffer;
+   gboolean link_on_demand;
 };
 
 struct envelope_op {
@@ -104,6 +108,13 @@ static void timers_update(struct ofono_stk *stk);
result.additional_len = sizeof(addn_info);  \
result.additional = addn_info;  \
 
+/*
+ * According the structure and coding of the Terminal response defined in
+ * TS 102 223 section 6.8, the maximum number of bytes possible for the channel
+ * data object is 243
+ */
+#define CHANNEL_DATA_OBJECT_MAX_LENGTH 243
+
 static int stk_respond(struct ofono_stk *stk, struct stk_response *rsp,
ofono_stk_generic_cb_t cb)
 {
@@ -112,6 +123,9 @@ static int stk_respond(struct ofono_stk *stk, struct 
stk_response *rsp,
 
DBG("");
 
+   if (stk->pending_cmd == NULL)
+   return 0;
+
if (stk->driver->terminal_response == NULL)
return -ENOSYS;
 
@@ -128,6 +142,7 @@ static int stk_respond(struct ofono_stk *stk, struct 
stk_response *rsp,
stk_command_free(stk->pending_cmd);
stk->pending_cmd = NULL;
stk->cancel_cmd = NULL;
+   stk->respond_on_exit = FALSE;
 
stk->driver->terminal_response(stk, tlv_len, tlv, cb, stk);
 
@@ -473,14 +488,48 @@ static void emit_menu_changed(struct ofono_stk *stk)
g_dbus_send_message(conn, signal);
 }
 
+static void stk_close_channel(struct ofono_stk *stk)
+{
+   /*
+* TODO
+* Deactivate PDP context
+* Send the Terminal Response once the PDP context is deactivated
+*/
+
+   /* Temporary implementation */
+   g_free(stk->rx_buffer.data.array);
+   g_free(stk->tx_buffer.data.array);
+   stk->rx_buffer.data.array = NULL;
+   stk->tx_buffer.data.array = NULL;
+
+   stk->channel.id = 0;
+   stk->channel.status = STK_CHANNEL_PACKET_DATA_SERVICE_NOT_ACTIVATED;
+
+   if (stk->pending_cmd &&
+   stk->pending_cmd->type == STK_COMMAND_TYPE_CLOSE_CHANNEL)
+   send_simple_response(stk, STK_RESULT_TYPE_SUCCESS);
+   else {
+   /*
+* TODO
+* Send Event channel status
+*/
+   }
+}
+
 static void user_termination_cb(enum stk_agent_result result, void *user_data)
 {
struct ofono_stk *stk = user_data;
 
-   if (result == STK_AGENT_RESULT_TERMINATE) {
-   stk->respond_on_exit = FALSE;
+   if (result != STK_AGENT_RESULT_TERMINATE)
+   return;
+
+   if (stk->pending_cmd) {
send_simple_response(stk, STK_RESULT_TYPE_USER_TERMINATED);
+   stk->cancel_cmd(stk);
}
+
+   if (stk->channel.id)
+   stk_close_channel(stk);
 }
 
 static void stk_alpha_id_set(struct ofono_stk *stk,
@@ -511,6 +560,147 @@ static void stk_alpha_id_unset(struct ofono_stk *stk)
stk_agent_request_cancel(stk->current_agent);
 }
 
+
+static void stk_open_channel(struct ofono_stk *stk)
+{
+   const struct stk_command_open_channel *oc;
+   struct stk_response rsp;
+   struct ofono_error failure = { .type = OFONO_ERROR_TYPE_FAILURE };
+
+   if (stk->pending_cmd == NULL ||
+   stk->pending_cmd->type != STK_COMMAND_TYPE_OPEN_CHANNEL)
+   return;
+
+   oc = &stk->pending_cmd->open_channel;
+
+   memset(&rsp, 0, sizeof(rsp));
+   rsp.result.type = STK_RESULT_TYPE_SUCCESS;
+
+   stk->rx_buffer.data.array = g_try_malloc(oc->buf_size);
+   if (stk->rx_buffer.data.array == NULL) {
+   rsp.result.type = STK_RESULT_TYPE_NOT_CAPABLE;
+   goto out;
+   }
+
+   stk->tx_buffer.data.array = g_try_malloc(oc->buf_size);
+   if (stk->tx_buffer.data.array == NULL) {
+   rsp.result.type = STK_RESULT_TYPE_NOT_CAPABLE;
+   goto out;
+   }
+
+   stk->rx_buffer.data.len = oc->buf_size;
+   stk->tx_buffer.data.len = oc->buf_size;
+   stk->link_on_demand = (stk->pending_cmd->qualifier &
+   STK_OPEN_CHANNEL_FLAG_IMMEDIATE) ? FALSE : TRUE;
+
+   /*
+* TODO
+* Setup the channel-> either create a new PDP context or
+* use a default one
+* Send the Terminal Response or wait until the PDP context is activated
+* in case of immediate link establishment not in background.
+*/
+out:
+
+   if (stk_respond(stk, &rsp, stk_command_cb))
+   stk_command_cb(&failure, stk);
+}
+
+static void stk_send_data(struct ofono_stk *stk,
+  

[PATCH 5/6] test-stk-menu: Extend to support ConfirmOpenchannel method

[Philippe Nunes]

---
 test/test-stk-menu |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/test/test-stk-menu b/test/test-stk-menu
index 1fde700..a9f92e8 100755
--- a/test/test-stk-menu
+++ b/test/test-stk-menu
@@ -208,6 +208,20 @@ class StkAgent(dbus.service.Object):
if key == 't':
raise EndSession("User wishes to terminate session")
 
+   @dbus.service.method("org.ofono.SimToolkitAgent",
+   in_signature="sy", out_signature="b")
+   def ConfirmOpenChannel(self, info, icon):
+   print "Open channel confirmation: (%s)" % (info)
+   print "Icon: (%d)" % (icon)
+   key = raw_input("Enter Confirmation (t, y, n):")
+
+   if key == 't':
+   raise EndSession("User wishes to terminate session");
+   elif key == 'y':
+   return True
+   else:
+   return False
+
 def property_changed(name, value):
print "SimToolKit property: %s changed to '%s'" % (name, value)
 
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 4/6] stkutil.c: Send at least the data currently available

[Philippe Nunes]

---
 src/stkutil.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/stkutil.c b/src/stkutil.c
index 7299fb5..ee59841 100644
--- a/src/stkutil.c
+++ b/src/stkutil.c
@@ -5655,7 +5655,8 @@ static gboolean build_receive_data(struct stk_tlv_builder 
*builder,
const struct stk_response_receive_data *receive_data =
&response->receive_data;
 
-   if (response->result.type != STK_RESULT_TYPE_SUCCESS)
+   if (response->result.type != STK_RESULT_TYPE_SUCCESS &&
+   response->result.type != STK_RESULT_TYPE_MISSING_INFO)
return TRUE;
 
if (receive_data->rx_data.len) {
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 3/6] stkutil.h: Enumerate the additional information for Bearer Independent Protocol

[Philippe Nunes]

---
 src/stkutil.h |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/src/stkutil.h b/src/stkutil.h
index dd45bc2..bc795d4 100644
--- a/src/stkutil.h
+++ b/src/stkutil.h
@@ -285,6 +285,23 @@ enum stk_result_addnl_ss_pb {
STK_RESULT_ADDNL_SS_PB_NO_SPECIFIC_CAUSE =  0x00
 };
 
+/* Defined according to TS 31.111 Section 8.12.4 */
+enum stk_result_addnl_bip_pb {
+   STK_RESULT_ADDNL_BIP_PB_NO_SPECIFIC_CAUSE = 0x00,
+   STK_RESULT_ADDNL_BIP_PB_NO_CHANNEL_AVAIL =  0x01,
+   STK_RESULT_ADDNL_BIP_PB_CHANNEL_CLOSED =0x02,
+   STK_RESULT_ADDNL_BIP_PB_CHANNEL_ID_NOT_VALID =  0x03,
+   STK_RESULT_ADDNL_BIP_PB_BUFFER_SIZE_NOT_AVAIL = 0x04,
+   STK_RESULT_ADDNL_BIP_PB_SECURITY_ERROR =0x05,
+   STK_RESULT_ADDNL_BIP_PB_INTERFACE_NOT_AVAIL =   0x06,
+   STK_RESULT_ADDNL_BIP_PB_DEVICE_NOT_REACHABLE =  0x07,
+   STK_RESULT_ADDNL_BIP_PB_SERVICE_ERROR = 0x08,
+   STK_RESULT_ADDNL_BIP_PB_SERVICE_ID_UNKNOWN =0x09,
+   STK_RESULT_ADDNL_BIP_PB_PORT_NOT_AVAIL =0x10,
+   STK_RESULT_ADDNL_BIP_PB_LAUNCH_PARAMETERS_MISSING = 0x11,
+   STK_RESULT_ADDNL_BIP_PB_APPLICATION_LAUNCH_FAILED = 0x12
+};
+
 enum stk_tone_type {
STK_TONE_TYPE_DIAL_TONE =   0x01,
STK_TONE_TYPE_BUSY_TONE =   0x02,
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 2/6] stk-api.txt. Introduce the new API ConfirmOpenChannel

[Philippe Nunes]

---
 doc/stk-api.txt |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/doc/stk-api.txt b/doc/stk-api.txt
index 0bcc6b5..aaa9fba 100644
--- a/doc/stk-api.txt
+++ b/doc/stk-api.txt
@@ -278,6 +278,13 @@ Methodsbyte RequestSelection(string title, 
byte icon_id,
 
Possible Errors: [service].Error.SimToolkit.EndSession
 
+   boolean ConfirmOpenChannel(string information, byte icon_id)
+
+   Asks the agent to request user to confirm the channel
+   set-up.
+
+   Possible Errors: [service].Error.SimToolkit.EndSession
+
void Cancel() [noreply]
 
Asks the agent to cancel any ongoing operation in
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH 1/6] stkagent: Add ConfirmOpenChannel method

[Philippe Nunes]

---
 src/stkagent.c |   67 
 src/stkagent.h |7 ++
 2 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/src/stkagent.c b/src/stkagent.c
index 220812e..1a4bdd8 100644
--- a/src/stkagent.c
+++ b/src/stkagent.c
@@ -1145,3 +1145,70 @@ int stk_agent_display_action(struct stk_agent *agent,
 
return 0;
 }
+
+static void confirm_open_channel_cb(DBusPendingCall *call, void *data)
+{
+   struct stk_agent *agent = data;
+   stk_agent_confirmation_cb cb = agent->user_cb;
+   DBusMessage *reply = dbus_pending_call_steal_reply(call);
+   enum stk_agent_result result;
+   gboolean remove_agent;
+   dbus_bool_t confirm;
+
+   if (check_error(agent, reply,
+   ALLOWED_ERROR_TERMINATE, &result) == -EINVAL) {
+   remove_agent = TRUE;
+   goto error;
+   }
+
+   if (result != STK_AGENT_RESULT_OK) {
+   cb(result, FALSE, agent->user_data);
+   goto done;
+   }
+
+   if (dbus_message_get_args(reply, NULL,
+   DBUS_TYPE_BOOLEAN, &confirm,
+   DBUS_TYPE_INVALID) == FALSE) {
+   ofono_error("Can't parse the reply to ConfirmOpenChannel()");
+   remove_agent = TRUE;
+   goto error;
+   }
+
+   cb(result, confirm, agent->user_data);
+
+   CALLBACK_END();
+}
+
+int stk_agent_confirm_open_channel(struct stk_agent *agent, const char *text,
+   const struct stk_icon_id *icon,
+   stk_agent_confirmation_cb cb,
+   void *user_data,
+   ofono_destroy_func destroy, int timeout)
+{
+   DBusConnection *conn = ofono_dbus_get_connection();
+
+   agent->msg = dbus_message_new_method_call(agent->bus, agent->path,
+   OFONO_SIM_APP_INTERFACE,
+   "ConfirmOpenChannel");
+   if (agent->msg == NULL)
+   return -ENOMEM;
+
+   dbus_message_append_args(agent->msg,
+   DBUS_TYPE_STRING, &text,
+   DBUS_TYPE_BYTE, &icon->id,
+   DBUS_TYPE_INVALID);
+
+   if (dbus_connection_send_with_reply(conn, agent->msg, &agent->call,
+   timeout) == FALSE ||
+   agent->call == NULL)
+   return -EIO;
+
+   agent->user_cb = cb;
+   agent->user_data = user_data;
+   agent->user_destroy = destroy;
+
+   dbus_pending_call_set_notify(agent->call, confirm_open_channel_cb,
+   agent, NULL);
+
+   return 0;
+}
diff --git a/src/stkagent.h b/src/stkagent.h
index 4b5d0a6..5e81485 100644
--- a/src/stkagent.h
+++ b/src/stkagent.h
@@ -156,3 +156,10 @@ int stk_agent_display_action(struct stk_agent *agent, 
const char *text,
stk_agent_display_action_cb cb,
void *user_data,
ofono_destroy_func destroy);
+
+int stk_agent_confirm_open_channel(struct stk_agent *agent, const char *text,
+   const struct stk_icon_id *icon,
+   stk_agent_confirmation_cb cb,
+   void *user_data,
+   ofono_destroy_func destroy,
+   int timeout);
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: Qualcomm Gobi 2000 Modem Issues

[Marcel Holtmann]

Hi Kai,

> >> I ran into two issues trying to setup a data connection with a Gobi 2000 
> >> card.
> >> The first one seems to be an error regarding simcard onlocking. After
> >> enabling the modem test/list-modems shows the following, despite the
> >> simcard is inserted correctly:
> >>
> >> [ /gobi0 ]
> >> Features = sim
> >> Emergency = 0
> >> Powered = 1
> >> Lockdown = 0
> >> Interfaces = org.ofono.SimManager
> >> Online = 0
> >> Model = Qualcomm Gobi 2000
> >> Revision = D1025-STUTABGD-3600  1  [Jan 14 2010 14:00:00]
> >> Serial = 353093033460401
> >> Manufacturer = Qualcomm Incorporated
> >> [ org.ofono.SimManager ]
> >> Present = 0
> >>
> >> Our current workaround is quitting ofono and using minicom to unlock
> >> the sim directly, then restarting ofono.
> >> > at+cpin?
> >> +CPIN: SIM PIN
> >> OK
> >>
> >> > at+cpin="1234"
> >> OK
> >> $QCSIMSTAT: 1 SIM INIT COMPLETED
> >
> > this is weird since the PIN unlocking should just work fine. Have you
> > tried to use the test/enter-pin script?
> 
> Yes, I tried the enter-pin script. Using it without the optional PATH
> this is the error:
> dbus.exceptions.DBusException: org.ofono.Error.InvalidFormat: Argument
> format is not recognized
> 
> Entering 'test/enter-pin /generic pin 1234' resultis in:
> dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.UnknownMethod: Method "EnterPin" with
> signature "ss" on interface "org.ofono.SimManager" doesn't exist
> 
> The problem is ofono not detecting the sim card properly since
> 'list-modems' shows:
> [ org.ofono.SimManager ]
> Present = 0

this is clearly a bug in the Gobi plugin then. It does not detect the
SIM card properly. So you need to dig a bit into plugins/gobi.c and
figure out how to fix it.

> >> The second issue is not being able to activate an internet context:
> >> (Network registration and attachment is alright)
> >>
> >> test/enable-modem
> >> Connecting modem /gobi0...
> >> test/online-modem
> >> Setting modem /gobi0 online...
> >> test/list-contexts
> >> [ /gobi0 ]
> >> [ /gobi0/context1 ]
> >> Username =
> >> Protocol = ip
> >> Name = Internet
> >> Settings = { }
> >> IPv6.Settings = { }
> >> Active = 0
> >> AccessPointName = internet.t-mobile
> >> Password =
> >> Type = internet
> >>
> >> test/activate-context
> >> Error activating /gobi0/context1: org.ofono.Error.NotImplemented:
> >> Implementation not provided
> >>
> >> If you could give me a little assisting on where to look, maybe I
> >> would be able to contribute patches, too.
> >
> > Of course this does not work. Check doc/hardware-support.txt for
> > supported modem and supported capabilities.
> >
> > Until Qualcomm gives us the chance to implement QMI properly, we are a
> > bit out of luck with just one AT command channel. You need at least two
> > AT command channel to run oFono properly.
> >
> 
> I missed reading that document.
> However I don't understand why you would need QMI for setting up a PPP
> connection, since there are infact three AT command channels, not one,
> if I understand the log correctly:
> 
> ofonod[2844]: src/modem.c:ofono_modem_create() name: (null), type: gobi
> ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268 property Path
> ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268
> property Registered
> ofonod[2844]: plugins/udev.c:add_modem()
> /devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.1/ttyUSB3/tty/ttyUSB3
> (gobi)
> ofonod[2844]: plugins/udev.c:add_gobi() modem 0x8dcb268
> ofonod[2844]: src/modem.c:get_modem_property() modem 0x8dcb268 property Path
> ofonod[2844]: plugins/udev.c:add_modem()
> /devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.2/ttyUSB4/tty/ttyUSB4
> (gobi)
> ofonod[2844]: plugins/udev.c:add_gobi() modem 0x8dcb268
> ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268 property Device
> ofonod[2844]: plugins/gobi.c:gobi_probe() 0x8dcb268
> ofonod[2844]: plugins/hfp_ag.c:modem_watch() modem: 0x8dcb268, added: 1
> ofonod[2844]: plugins/dun_gw.c:modem_watch() modem: 0x8dcb268, added: 1
> ofonod[2844]: plugins/smart-messaging.c:modem_watch() modem: 0x8dcb268, 
> added: 1
> ofonod[2844]: plugins/push-notification.c:modem_watch() modem:
> 0x8dcb268, added: 1
> ofonod[2844]: src/modem.c:get_modem_property() modem 0x8dcb268 property Path
> ofonod[2844]: plugins/udev.c:add_modem()
> /devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.3/ttyUSB5/tty/ttyUSB5
> (gobi)

This means that there are 3 TTYs exposed by the Gobi card. This does not
mean that these are all AT modem capable ports. In fact they are not.
Check /proc/bus/usb/devices and see what driver got loaded for what USB
interface. All the qcaux bound interfaces are not really helpful.

But if you by accident have a Gobi firmware that exposes 2 real AT
command ports, I like to hear about it.

Regards

Marcel


___
ofono maili

RE: [RFC PATCH v3] gprs: add function to handle activated context

[Soum, RedouaneX]

Hi Arun,

>>> So the spec says, ME PDN ACT can come even for an implicit context
>>> activation request associated with CGATT, which is the case with EPS.
>>>
>>> For 3G, if this happens (ME PDN ACT) for UE initiated activation of
>>> context, then the cid is already set with CGDCONT.
>>>
>>> For EPS this can happen for default context, where cid is not set with
>>> CGDCONT, but is in the range as returned by CGDCONT.
>>>
>>> Here the cid issue, because cid is managed by ofono and is never
>>> communicated to modem.  Probably to avoid sending too many CGDCONT's
>>> during startup. or is it something else?
>>>
>>> I thought the default context activation will come to TE as NW ACT,
>with
>>> a cid not in range of CGDCONT.
>>>
>> Exactly so the idea to avoid any issue was to call
>ofono_gprs_set_cid_range from the driver with a range which doesn't
>include the CID used for initial EPS context.
>> Normaly we know from the modem vendor which CID will be used for the
>initial EPS context.
>>
>> For instance if +CGDSCONT=? Is returning 1-25 as range then we call
>ofono_gprs_set_cid_range with 2-25 as range assuming that CID 1 will be
>used for the initial EPS context.
>Ok so you are assuming that cid 1 will be always used for default
>context, and so this is work around for the issue.

The modem vendor should know which CID will be used for the initial default 
context.
So the idea was to add a requirement in the implementation of the gprs drivers 
that ofono_gprs_set_cid should be called with a range that's doesn't include 
the CID used for the initial default bearer.

>From what I know there is nothing in the spec saying which CID to use for 
>initial default context.
And there is no standard AT commands to specify settings to use for the initial 
default context (CID, APN, user , password , IPV4/IPV6/ IPV4V6 ...)

>Instead we could also expect it to have a unique id.
>
>I still feel that the default context should be a NW initiated context
>and will have a unique cid.

As Pessi said before the PDN connectivity request is UE initiated.

-- The problem is, the initial EPS context is initiated by mobile, not by the 
network. The mobile sends a piggybacked PDN CONNECTIVITY REQUEST with the 
initial attach request in order to initiate the initial EPS context. --

>Also why can't the context id management be done in modem instead of
>ofono?

What do you mean by context id management be done in the modem ?

Regards,
Redouane.
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [RFC PATCH v3] gprs: add function to handle activated context

[Arun Ravindran]

Hi Redouane,




So the spec says, ME PDN ACT can come even for an implicit context
activation request associated with CGATT, which is the case with EPS.

For 3G, if this happens (ME PDN ACT) for UE initiated activation of
context, then the cid is already set with CGDCONT.

For EPS this can happen for default context, where cid is not set with
CGDCONT, but is in the range as returned by CGDCONT.

Here the cid issue, because cid is managed by ofono and is never
communicated to modem.  Probably to avoid sending too many CGDCONT's
during startup. or is it something else?

I thought the default context activation will come to TE as NW ACT, with
a cid not in range of CGDCONT.


Exactly so the idea to avoid any issue was to call ofono_gprs_set_cid_range 
from the driver with a range which doesn't include the CID used for initial EPS 
context.
Normaly we know from the modem vendor which CID will be used for the initial 
EPS context.

For instance if +CGDSCONT=? Is returning 1-25 as range then we call  
ofono_gprs_set_cid_range with 2-25 as range assuming that CID 1 will be used 
for the initial EPS context.
Ok so you are assuming that cid 1 will be always used for default 
context, and so this is work around for the issue.


Instead we could also expect it to have a unique id.

I still feel that the default context should be a NW initiated context 
and will have a unique cid.


Also why can't the context id management be done in modem instead of ofono?

Regards
Arun


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

RE: Retrieve ofono_sim_password_type

[Jeevaka.Badrappan]

 
Hi Christophe,  

>   Hi,
>
>   I need to map ofono_sim_password_type according to h24 AT
command manual.
>
>   Can somebody check if I mapped correctly enum with documentation
definition.
>
>   OFONO_SIM_PASSWORD_SIM_PIN   : PIN attempts
>
>   OFONO_SIM_PASSWORD_SIM_PUK, : PUK attempts
>
>   OFONO_SIM_PASSWORD_SIM_PIN2,: PIN2 attempts
>
>   OFONO_SIM_PASSWORD_SIM_PUK2,: PUK2 attempts
>
>   OFONO_SIM_PASSWORD_PHNET_PIN,   : NETWORK PERSONALIZATION PIN
attempts
>
>   OFONO_SIM_PASSWORD_PHNET_PUK,   : NETWORK PERSONALIZATION PUK
attempts
>
>   OFONO_SIM_PASSWORD_PHNETSUB_PIN,: NETWORK SUBSET PERSONALIZATION
PIN attempts
>
>   OFONO_SIM_PASSWORD_PHNETSUB_PUK,: NETWORK SUBSET PERSONALIZATION
PUK attempts
>
>   OFONO_SIM_PASSWORD_PHSP_PIN,: SERVICE PROVIDER
PERSONALIZATION PIN attempts
>
>   OFONO_SIM_PASSWORD_PHSP_PUK,: SERVICE PROVIDER
PERSONALIZATION PUK attempts
>
>   OFONO_SIM_PASSWORD_PHCORP_PIN,  : CORPORATE PERSONALIZATION PIN
attempts
>
>   OFONO_SIM_PASSWORD_PHCORP_PUK,  : CORPORATE PERSONALIZATION PUK
attempts
>
>   OFONO_SIM_PASSWORD_PHFSIM_PIN,  : SIM PERSONALIZATION PIN
attempts
>
>   OFONO_SIM_PASSWORD_PHFSIM_PUK,  : SIM PERSONALIZATION PUK
attempts

enum value is based on the 27.007 section 8.3  values. If the h24
values are as per
27.007 specification, then its correct.

Atleast based on the description, mapping seems to be correct.

Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Retrieve ofono_sim_password_type

[Ostermann, Christophe]

Hi,

 

I need to map ofono_sim_password_type according to h24 AT command
manual.

Can somebody check if I mapped correctly enum with documentation
definition.

 

OFONO_SIM_PASSWORD_SIM_PIN   : PIN attempts

OFONO_SIM_PASSWORD_SIM_PUK, : PUK attempts

OFONO_SIM_PASSWORD_SIM_PIN2,: PIN2 attempts

OFONO_SIM_PASSWORD_SIM_PUK2,: PUK2 attempts

OFONO_SIM_PASSWORD_PHNET_PIN,   : NETWORK PERSONALIZATION PIN attempts

OFONO_SIM_PASSWORD_PHNET_PUK,   : NETWORK PERSONALIZATION PUK attempts

OFONO_SIM_PASSWORD_PHNETSUB_PIN,: NETWORK SUBSET PERSONALIZATION PIN
attempts

OFONO_SIM_PASSWORD_PHNETSUB_PUK,: NETWORK SUBSET PERSONALIZATION PUK
attempts

OFONO_SIM_PASSWORD_PHSP_PIN,: SERVICE PROVIDER PERSONALIZATION PIN
attempts

OFONO_SIM_PASSWORD_PHSP_PUK,: SERVICE PROVIDER PERSONALIZATION PUK
attempts

OFONO_SIM_PASSWORD_PHCORP_PIN,  : CORPORATE PERSONALIZATION PIN attempts

OFONO_SIM_PASSWORD_PHCORP_PUK,  : CORPORATE PERSONALIZATION PUK attempts

OFONO_SIM_PASSWORD_PHFSIM_PIN,  : SIM PERSONALIZATION PIN attempts

OFONO_SIM_PASSWORD_PHFSIM_PUK,  : SIM PERSONALIZATION PUK attempts

 

 

BR

Christophe

 

--

Christophe Ostermann 
Software Engineer
Devices Engineering

SICPA Security Solutions SA
Av. de Florissant 41, 1008 Prilly, Switzerland
Tel +41 21 627 59 70  Direct +41 21 627 63 68
Fax +41 21 620 06 22 
christophe.osterm...@sicpa.com
   www.sicpa.com
 

 

 



This message was delivered through encrypted mechanism.


The information in this email and any attachments is confidential
and intended solely for the use of the individual(s) to whom it is
addressed or otherwise directed.
Please note that any views or opinions presented in this email are
solely those of the author and do not necessarily represent those
of the Company.
Finally, the recipient should check this email and any attachments
for the presence of viruses.
The Company accepts no liability for any damage caused by any virus
transmitted by this email.___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: Qualcomm Gobi 2000 Modem Issues

[Kai Scharwies]

2011/4/7 Marcel Holtmann :
> Hi Kai,
>
>> I ran into two issues trying to setup a data connection with a Gobi 2000 
>> card.
>> The first one seems to be an error regarding simcard onlocking. After
>> enabling the modem test/list-modems shows the following, despite the
>> simcard is inserted correctly:
>>
>> [ /gobi0 ]
>>     Features = sim
>>     Emergency = 0
>>     Powered = 1
>>     Lockdown = 0
>>     Interfaces = org.ofono.SimManager
>>     Online = 0
>>     Model = Qualcomm Gobi 2000
>>     Revision = D1025-STUTABGD-3600  1  [Jan 14 2010 14:00:00]
>>     Serial = 353093033460401
>>     Manufacturer = Qualcomm Incorporated
>>     [ org.ofono.SimManager ]
>>         Present = 0
>>
>> Our current workaround is quitting ofono and using minicom to unlock
>> the sim directly, then restarting ofono.
>> > at+cpin?
>> +CPIN: SIM PIN
>> OK
>>
>> > at+cpin="1234"
>> OK
>> $QCSIMSTAT: 1 SIM INIT COMPLETED
>
> this is weird since the PIN unlocking should just work fine. Have you
> tried to use the test/enter-pin script?

Yes, I tried the enter-pin script. Using it without the optional PATH
this is the error:
dbus.exceptions.DBusException: org.ofono.Error.InvalidFormat: Argument
format is not recognized

Entering 'test/enter-pin /generic pin 1234' resultis in:
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.UnknownMethod: Method "EnterPin" with
signature "ss" on interface "org.ofono.SimManager" doesn't exist

The problem is ofono not detecting the sim card properly since
'list-modems' shows:
[ org.ofono.SimManager ]
Present = 0

What it should look like is this (Output after unlocking via AT
commands, described above):
[ org.ofono.SimManager ]
Retries =
MobileCountryCode = 262
FixedDialing = 0
SubscriberNumbers =
PreferredLanguages = de en
BarredDialing = 0
CardIdentifier = 8949020622126220
LockedPins =
MobileNetworkCode = 01
SubscriberIdentity = 262019038101028
Present = 1
PinRequired = none

PinRequired should of course read "pin" before unlocking.
Anymore logs I could deliver to solve this issue?

>
>> The second issue is not being able to activate an internet context:
>> (Network registration and attachment is alright)
>>
>> test/enable-modem
>> Connecting modem /gobi0...
>> test/online-modem
>> Setting modem /gobi0 online...
>> test/list-contexts
>> [ /gobi0 ]
>>     [ /gobi0/context1 ]
>>         Username =
>>         Protocol = ip
>>         Name = Internet
>>         Settings = { }
>>         IPv6.Settings = { }
>>         Active = 0
>>         AccessPointName = internet.t-mobile
>>         Password =
>>         Type = internet
>>
>> test/activate-context
>> Error activating /gobi0/context1: org.ofono.Error.NotImplemented:
>> Implementation not provided
>>
>> If you could give me a little assisting on where to look, maybe I
>> would be able to contribute patches, too.
>
> Of course this does not work. Check doc/hardware-support.txt for
> supported modem and supported capabilities.
>
> Until Qualcomm gives us the chance to implement QMI properly, we are a
> bit out of luck with just one AT command channel. You need at least two
> AT command channel to run oFono properly.
>

I missed reading that document.
However I don't understand why you would need QMI for setting up a PPP
connection, since there are infact three AT command channels, not one,
if I understand the log correctly:

ofonod[2844]: src/modem.c:ofono_modem_create() name: (null), type: gobi
ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268 property Path
ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268
property Registered
ofonod[2844]: plugins/udev.c:add_modem()
/devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.1/ttyUSB3/tty/ttyUSB3
(gobi)
ofonod[2844]: plugins/udev.c:add_gobi() modem 0x8dcb268
ofonod[2844]: src/modem.c:get_modem_property() modem 0x8dcb268 property Path
ofonod[2844]: plugins/udev.c:add_modem()
/devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.2/ttyUSB4/tty/ttyUSB4
(gobi)
ofonod[2844]: plugins/udev.c:add_gobi() modem 0x8dcb268
ofonod[2844]: src/modem.c:set_modem_property() modem 0x8dcb268 property Device
ofonod[2844]: plugins/gobi.c:gobi_probe() 0x8dcb268
ofonod[2844]: plugins/hfp_ag.c:modem_watch() modem: 0x8dcb268, added: 1
ofonod[2844]: plugins/dun_gw.c:modem_watch() modem: 0x8dcb268, added: 1
ofonod[2844]: plugins/smart-messaging.c:modem_watch() modem: 0x8dcb268, added: 1
ofonod[2844]: plugins/push-notification.c:modem_watch() modem:
0x8dcb268, added: 1
ofonod[2844]: src/modem.c:get_modem_property() modem 0x8dcb268 property Path
ofonod[2844]: plugins/udev.c:add_modem()
/devices/pci:00/:00:1a.7/usb1/1-4/1-4:1.3/ttyUSB5/tty/ttyUSB5
(gobi)
ofonod[2844]: plugins/udev.c:add_gobi() modem 0x8dcb268
ofonod[2844]: plugins/gobi.c:gobi_enable() 0x8dcb268
ofonod[2844]: src/modem.c:get_modem_property() modem 0x8dcb268 property Device
ofonod[2844]: plugins/gobi.c:open_device() Device /de

RE: [RFC PATCH v3] gprs: add function to handle activated context

[Joly, Frederic]

Hi,

My 2 cts.

> -Original Message-
> From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On
> Behalf Of Arun Ravindran
> Sent: Wednesday, April 06, 2011 11:30 AM
> To: ofono@ofono.org
> Subject: Re: [RFC PATCH v3] gprs: add function to handle activated
> 27.007 section 10.1.1 says
> 
> Defined values
> : a numeric parameter which specifies a particular PDP context
> definition. The parameter is local to the TE-
> MT interface and is used in other PDP context-related commands. The
> range of permitted values (minimum
> value = 1) is returned by the test form of the command.
> NOTE 1: The s for network-initiated PDP contexts will have values
> outside the ranges indicated for the
>  in the test form of the commands +CGDCONT and +CGDSCONT.
> 
Rigth, but just a general comment.
This is a release 9 clarification. The 27.007 Change request was only adopted 
one year ago (March 2010).
I believe we should keep this is mind to maintain if necessary the backward 
compatibility.
I don't foresee yet an issue, but IMS services seem to get now some traction 
even on 3G.
Of course no evidence that network initiated PDP context are going to be used, 
but their usage fits pretty well with IMS...

Fred
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono