Reg: Memory capacity exceeded

Reg: Memory capacity exceeded

[linux mobile]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

Hi,

If  device memory capacity is over there is a way to set HLR about memory
capacity exceeded.
But in Ofono I didn't find any indication regarding memory capacity exceeded
for class 1 messages.

Is this feature is going to be added in future? please let me know.


Thanks
Rams

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 325 bytes --]

Re: Reg: Memory capacity exceeded

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Hi Rams,

> If  device memory capacity is over there is a way to set HLR about
> memory
> capacity exceeded.
> But in Ofono I didn't find any indication regarding memory capacity
> exceeded
> for class 1 messages.
> 
> Is this feature is going to be added in future? please let me know.

when you reached that state with oFono, then you have different
problems ;)

oFono is not using the SIM storage at all. Everything happens on the
host storage.

Regards

Marcel

RE: Reg: Memory capacity exceeded

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

Hi Marcel,
 
> If  device memory capacity is over there is a way to set HLR about 
> memory capacity exceeded.
> But in Ofono I didn't find any indication regarding memory capacity 
> exceeded for class 1 messages.
> 
> Is this feature is going to be added in future? please let me know.

> when you reached that state with oFono, then you have different
problems ;)

> oFono is not using the SIM storage at all. Everything happens on the
host storage.

I think Rams question applies to both ME and SIM storage. 

Class 2 Messages are stored in the SIM whereas Class 1 Messages are
stored in the device storage which can be host storage or SIM storage.

When the storage is full, then the ME can inform the network that the
memory capacity is full. This is to make sure network is not forwarding
the messages to 
ME. 

When the storage is available, then the ME can inform the network that
it has space for receiving messages.

Incase of SIM storage, there is a SIM file which has the memory capacity
exceeded flag information.

Regards,
jeevaka 

RE: Reg: Memory capacity exceeded

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

Hi,

On Mon, 2010-09-20 at 13:09 +0200, ext Jeevaka.Badrappan(a)elektrobit.com
wrote:
> Class 2 Messages are stored in the SIM whereas Class 1 Messages are
> stored in the device storage which can be host storage or SIM storage.

Right now, oFono doesn't store class 2 messages at all, which is a good
thing. There is quite a trivial DoS attack possibility caused by the
limited storage capacity on the SIM card and the fact that oFono doesn't
provide access to that storage for clean up purposes.

And since exceeding capacity for class 2 messages effectively causes a
HOL block for class 1 messages, the whole thing is really broken by
design.

> When the storage is full, then the ME can inform the network that the
> memory capacity is full. This is to make sure network is not forwarding
> the messages to 
> ME. 
> 
> When the storage is available, then the ME can inform the network that
> it has space for receiving messages.

We could provide this in oFono using the message agent API, or possibly
also via the history API. That is, have the agent/plugin return an error
when it has exceeded its storage capacity, and then have a corresponding
addition the SMS driver API to communicate this to the network.

Of course, one can argue whether this feature really has some real world
relevance or is purely theoretical.

I wonder if it is a type approval requirement to support?

Cheers,
Aki

Re: Reg: Memory capacity exceeded

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

Hi all,

> Of course, one can argue whether this feature really has some real world
> relevance or is purely theoretical.
>
> I wonder if it is a type approval requirement to support?

I'm afraid there is a PICS case for this thing. I cannot recall how we
got N900 through this particular hoop, but probably we just waived
this particular test case irrelevant.

-- 
Pekka.Pessi mail at nokia.com

RE: Reg: Memory capacity exceeded

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Hi,

> Of course, one can argue whether this feature really has some real 
> world relevance or is purely theoretical.
>
> I wonder if it is a type approval requirement to support?

> I'm afraid there is a PICS case for this thing. I cannot recall how we
got N900 through this particular hoop, but probably we just waived this
particular test case irrelevant.

correct. There is a USIM conformance case on this message capacitiy
exceeded information. As per the 3GPP 31.121 specification section 8.2:

"If all SMS data field are full and furthermore all memory capacity
reserved for SMS inside the ME is filled up to maximum and a SM(Short
Message) was rejected, then this shall be indicated in the SMS Status
file.(EFsmss)"

For more information on this, refer 3GPP TS 31.121 section 8.2

There is also test cases related to SMS read from USIM. 

Regards,
jeevaka

Re: Reg: Memory capacity exceeded

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

Hi Jeevaka,

On 09/20/2010 07:39 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> Hi,
> 
>> Of course, one can argue whether this feature really has some real 
>> world relevance or is purely theoretical.
>>
>> I wonder if it is a type approval requirement to support?
> 
>> I'm afraid there is a PICS case for this thing. I cannot recall how we
> got N900 through this particular hoop, but probably we just waived this
> particular test case irrelevant.
> 
> correct. There is a USIM conformance case on this message capacitiy
> exceeded information. As per the 3GPP 31.121 specification section 8.2:
> 
> "If all SMS data field are full and furthermore all memory capacity
> reserved for SMS inside the ME is filled up to maximum and a SM(Short
> Message) was rejected, then this shall be indicated in the SMS Status
> file.(EFsmss)"

The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
storage).  And even if direct delivery does not work (e.g. crappy modem
or Class 2 / Class 3 messages) oFono still removes the SMS as soon as it
is delivered.  We should never hit a sim/me memory full conditions.

So I don't see how this test case even applies.

Regards,
-Denis

Re: Reg: Memory capacity exceeded

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Mon, 2010-09-20 at 14:29 +0200, ext Pekka Pessi wrote:
> I'm afraid there is a PICS case for this thing. I cannot recall how we
> got N900 through this particular hoop, but probably we just waived
> this particular test case irrelevant.

I know we have the machinery in place in N900 to report memory exceeded
to the network. And I even remember it getting tested at some point,
basically flooding /var/spool/sms is enough to trigger it.

If this can be waived, though, good riddance.

Cheers,
Aki

RE: Reg: Memory capacity exceeded

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

 
Hi Denis,

> The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
storage).  And even if direct delivery does not work (e.g. crappy modem
or Class 2 / Class 3 messages) oFono still removes the SMS 
> as soon as it is delivered.  We should never hit a sim/me memory full
conditions.

> So I don't see how this test case even applies.

Little bit lost now. Are we speaking about the sending or receiving of
SMS?

Memory capacity exceeded applies to incoming SMS. Incoming SMS can be
stored in SIM or in ME storage. If the SMS storage for incoming SMS is
full, then the ME can inform the network that it can't handle any more
class 1/class 2 incoming SMS due to maximum memory capacity reached.
Once the user frees some memory by deleting some messages, then ME can
inform network that it is ready now to receive messages. So, I believe
this test case applies but as Pessi Pekka said we can waive this test
case.

Regards,
jeevaka

Re: Reg: Memory capacity exceeded

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Hi Jeevaka,

On 09/20/2010 09:08 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
>  
> Hi Denis,
> 
>> The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
> storage).  And even if direct delivery does not work (e.g. crappy modem
> or Class 2 / Class 3 messages) oFono still removes the SMS 
>> as soon as it is delivered.  We should never hit a sim/me memory full
> conditions.
> 
>> So I don't see how this test case even applies.
> 
> Little bit lost now. Are we speaking about the sending or receiving of
> SMS?
> 
> Memory capacity exceeded applies to incoming SMS. Incoming SMS can be
> stored in SIM or in ME storage. If the SMS storage for incoming SMS is
> full, then the ME can inform the network that it can't handle any more
> class 1/class 2 incoming SMS due to maximum memory capacity reached.
> Once the user frees some memory by deleting some messages, then ME can
> inform network that it is ready now to receive messages. So, I believe
> this test case applies but as Pessi Pekka said we can waive this test
> case.

I know exactly the case you're talking about, but as I mentioned before,
oFono does not configure the modem to store on SIM or ME.  The messages
are routed directly to oFono.  See drivers/atmodem/sms.c for more
details.  The only messages that *might* get routed to SM/ME are Class 2
/ 3 messages.  These are automatically deleted on reception by the sms
driver.

The 'memory capacity reached' can simply never happen assuming sane
hardware.

Regards,
-Denis

Re: Reg: Memory capacity exceeded

[linux mobile]

[-- Attachment #1: Type: text/plain, Size: 19746 bytes --]

Hi,

As my understand

Messaging application will interact with Ofono and from Ofono to  driver
specific functionality specific to h/w.(Eg: isi modem)

Incoming messages will be stored in device. If the storage capacity is over
in the device then there is a way to inform the network that memory capacity
is exceeded.

 As application can't access driver specific functions  directly  this
should be done  through Ofono .

Thanks
Rams



On Mon, Sep 20, 2010 at 10:40 PM, <ofono-request@ofono.org> wrote:

> Send ofono mailing list submissions to
>        ofono(a)ofono.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.ofono.org/listinfo/ofono
> or, via email, send a message with subject or body 'help' to
>        ofono-request(a)ofono.org
>
> You can reach the person managing the list at
>        ofono-owner(a)ofono.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ofono digest..."
>
>
> Today's Topics:
>
>   1. [PATCH v2 2/2] huawei: fix online logic (Kalle Valo)
>   2. Re: Reg: Memory capacity exceeded (Denis Kenzior)
>   3. Re: ofono gprs_primary_context description (Denis Kenzior)
>   4. Re: Reg: Memory capacity exceeded (Aki Niemi)
>   5. RE: Reg: Memory capacity exceeded
>      (Jeevaka.Badrappan(a)elektrobit.com)
>   6. Re: Reg: Memory capacity exceeded (Denis Kenzior)
>   7. Re: [PATCH v2 1/2] huawei: poll sim state (Marcel Holtmann)
>   8. Re: [PATCH v2 2/2] huawei: fix online logic (Marcel Holtmann)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Sep 2010 15:40:33 +0300
> From: Kalle Valo <kalle.valo@canonical.com>
> To: ofono(a)ofono.org
> Subject: [PATCH v2 2/2] huawei: fix online logic
> Message-ID: <20100920124033.12498.3545.stgit@potku.valot.fi>
> Content-Type: text/plain; charset="utf-8"
>
> The recently introduced online support to huawei didn't work with my
> Huawei E1552. The problem was that with command AT+CFUN=1;+CFUN=5
> the modem didn't initialise the sim state properly.
>
> To fix this I changed the logic so that CFUN=5 is called only after the sim
> state has switched to a valid state. Now my Huawei E1552 works with connman
> again.
>
> PIN locked SIMs still won't work. The problem is that it takes some time
> for
> the sim state to go to a valid state:
>
> Sep 20 15:01:57 dell-m520 ofonod[12451]: Pcui:< \r\n+CPIN:
> READY\r\n\r\nOK\r\n
> [...]
> Sep 20 15:02:00 dell-m520 ofonod[12451]: huawei: invalid sim state in post
> online (0)
> [...]
> Sep 20 15:02:01 dell-m520 ofonod[12451]: Pcui:< \r\n^SIMST:1\r\n
>
> I don't know why it takes so long to get a valid state.
>
> There is also another issue, in "cold start" case the phonebook
> initialisation fails:
>
> Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:> AT+CPBS=?\r
> Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:< \r\n+CME ERROR: SIM
> busy\r\n
>
> But in "warm start" it seems to work:
>
> Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:> AT+CPBS=?\r
> Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:< \r\n+CPBS:
> ("SM","EN","ON")\r\n\r\nOK\r\n
>
> I consider this as a minor issue and didn't investigate it at all.
> ---
>  plugins/huawei.c |   77
> +++++++++++++++++++++++++++++++++++++-----------------
>  1 files changed, 53 insertions(+), 24 deletions(-)
>
> diff --git a/plugins/huawei.c b/plugins/huawei.c
> index 2f605ee..27473a8 100644
> --- a/plugins/huawei.c
> +++ b/plugins/huawei.c
> @@ -163,6 +163,22 @@ static void ussdmode_support_cb(gboolean ok, GAtResult
> *result,
>                                        ussdmode_query_cb, data, NULL);
>  }
>
> +static void cfun_offline(gboolean ok, GAtResult *result, gpointer
> user_data)
> +{
> +       struct ofono_modem *modem = user_data;
> +       struct huawei_data *data = ofono_modem_get_data(modem);
> +
> +       if (!ok) {
> +               ofono_modem_set_powered(modem, FALSE);
> +               return;
> +       }
> +
> +       if (data->sim == NULL)
> +               return;
> +
> +       ofono_sim_inserted_notify(data->sim, TRUE);
> +}
> +
>  static gboolean notify_sim_state(struct ofono_modem *modem,
>                                enum huawei_sim_state sim_state)
>  {
> @@ -170,17 +186,33 @@ static gboolean notify_sim_state(struct ofono_modem
> *modem,
>
>        DBG("%d", sim_state);
>
> -       if (sim_state == HUAWEI_SIM_STATE_NOT_EXISTENT) {
> -               ofono_sim_inserted_notify(data->sim, FALSE);
> +       data->sim_state = sim_state;
>
> +       switch (sim_state) {
> +       case HUAWEI_SIM_STATE_NOT_EXISTENT:
>                /* SIM is not ready, try again a bit later */
>                return TRUE;
> +       case HUAWEI_SIM_STATE_INVALID_OR_LOCKED:
> +               ofono_modem_set_powered(modem, TRUE);
> +
> +               return FALSE;
> +       case HUAWEI_SIM_STATE_VALID:
> +       case HUAWEI_SIM_STATE_INVALID_CS:
> +       case HUAWEI_SIM_STATE_INVALID_PS:
> +       case HUAWEI_SIM_STATE_INVALID_PS_AND_CS:
> +               /*
> +                * In the "warm start" case the modem skips
> +                * HUAWEI_SIM_STATE_INVALID_OR_LOCKED altogether, so need
> +                * to set power also here
> +                */
> +               ofono_modem_set_powered(modem, TRUE);
> +
> +               g_at_chat_send(data->pcui, "AT+CFUN=5", none_prefix,
> +                               cfun_offline, modem, NULL);
> +
> +               return FALSE;
>        }
>
> -       ofono_sim_inserted_notify(data->sim, TRUE);
> -
> -       data->sim_state = sim_state;
> -
>        return FALSE;
>  }
>
> @@ -347,24 +379,24 @@ static void cvoice_query_cb(gboolean ok, GAtResult
> *result,
>        gint mode, rate, bits, period;
>
>        if (!ok)
> -               goto done;
> +               return;
>
>        g_at_result_iter_init(&iter, result);
>
>        if (!g_at_result_iter_next(&iter, "^CVOICE:"))
> -               goto done;
> +               return;
>
>        if (!g_at_result_iter_next_number(&iter, &mode))
> -               goto done;
> +               return;
>
>        if (!g_at_result_iter_next_number(&iter, &rate))
> -               goto done;
> +               return;
>
>        if (!g_at_result_iter_next_number(&iter, &bits))
> -               goto done;
> +               return;
>
>        if (!g_at_result_iter_next_number(&iter, &period))
> -               goto done;
> +               return;
>
>        data->voice = TRUE;
>
> @@ -383,9 +415,6 @@ static void cvoice_query_cb(gboolean ok, GAtResult
> *result,
>        /* check available voice ports */
>        g_at_chat_send(data->pcui, "AT^DDSETEX=?", none_prefix,
>                                                NULL, NULL, NULL);
> -
> -done:
> -       ofono_modem_set_powered(modem, TRUE);
>  }
>
>  static void cvoice_support_cb(gboolean ok, GAtResult *result,
> @@ -396,21 +425,16 @@ static void cvoice_support_cb(gboolean ok, GAtResult
> *result,
>        GAtResultIter iter;
>
>        if (!ok)
> -               goto done;
> +               return;
>
>        g_at_result_iter_init(&iter, result);
>
>        if (!g_at_result_iter_next(&iter, "^CVOICE:"))
> -               goto done;
> +               return;
>
>        /* query current voice setting */
>        g_at_chat_send(data->pcui, "AT^CVOICE?", cvoice_prefix,
>                                        cvoice_query_cb, modem, NULL);
> -
> -       return;
> -
> -done:
> -       ofono_modem_set_powered(modem, TRUE);
>  }
>
>  static void cfun_enable(gboolean ok, GAtResult *result, gpointer
> user_data)
> @@ -550,7 +574,7 @@ static int huawei_enable(struct ofono_modem *modem)
>
>        g_at_chat_send(data->pcui, "ATE0", none_prefix, NULL, NULL, NULL);
>
> -       g_at_chat_send(data->pcui, "AT+CFUN=1;+CFUN=5", none_prefix,
> +       g_at_chat_send(data->pcui, "AT+CFUN=1", none_prefix,
>                                        cfun_enable, modem, NULL);
>
>        query_sim_state(modem);
> @@ -667,8 +691,13 @@ static void huawei_post_online(struct ofono_modem
> *modem)
>        struct ofono_netreg *netreg;
>        struct ofono_message_waiting *mw;
>
> -       if (data->sim_state == HUAWEI_SIM_STATE_INVALID_PS_AND_CS)
> +       if (data->sim_state != HUAWEI_SIM_STATE_VALID &&
> +           data->sim_state != HUAWEI_SIM_STATE_INVALID_CS &&
> +           data->sim_state != HUAWEI_SIM_STATE_INVALID_PS) {
> +               ofono_info("huawei: invalid sim state in post online (%d)",
> +                               data->sim_state);
>                return;
> +       }
>
>        netreg = ofono_netreg_create(modem, OFONO_VENDOR_HUAWEI, "atmodem",
>                                                                data->pcui);
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 20 Sep 2010 07:44:45 -0500
> From: Denis Kenzior <denkenz@gmail.com>
> To: ofono(a)ofono.org
> Subject: Re: Reg: Memory capacity exceeded
> Message-ID: <4C97573D.90406@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Jeevaka,
>
> On 09/20/2010 07:39 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> > Hi,
> >
> >> Of course, one can argue whether this feature really has some real
> >> world relevance or is purely theoretical.
> >>
> >> I wonder if it is a type approval requirement to support?
> >
> >> I'm afraid there is a PICS case for this thing. I cannot recall how we
> > got N900 through this particular hoop, but probably we just waived this
> > particular test case irrelevant.
> >
> > correct. There is a USIM conformance case on this message capacitiy
> > exceeded information. As per the 3GPP 31.121 specification section 8.2:
> >
> > "If all SMS data field are full and furthermore all memory capacity
> > reserved for SMS inside the ME is filled up to maximum and a SM(Short
> > Message) was rejected, then this shall be indicated in the SMS Status
> > file.(EFsmss)"
>
> The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
> storage).  And even if direct delivery does not work (e.g. crappy modem
> or Class 2 / Class 3 messages) oFono still removes the SMS as soon as it
> is delivered.  We should never hit a sim/me memory full conditions.
>
> So I don't see how this test case even applies.
>
> Regards,
> -Denis
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 20 Sep 2010 07:49:48 -0500
> From: Denis Kenzior <denkenz@gmail.com>
> To: ofono(a)ofono.org
> Subject: Re: ofono gprs_primary_context description
> Message-ID: <4C97586C.8000801@gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Laurent,
>
> On 09/20/2010 04:20 AM, Laurent THOMAS wrote:
> > Hi,
> >
> >
> >
> > According to the interface org.ofono.ConnectionContext description, the
> > property ?Name? is a free short string used to describe the context.
> >
> > Extract from ?conman-api.txt?
> >
> > /Properties         string Name [readwrite]/
> >
> > / /
> >
> > /                                   The name is a free form string that
> > describes this/
> >
> > /                                   context.  The name should not be
> > empty and limited/
> >
> > /                                   to a short string for display
> purposes./
> >
> >
> >
> > But according to source code (version 0.28), this attribute is now only
> > affected with the context String Type (?internet?, ?wap? or ?mms?)
> >
> >
> >
> > is it really the expected behaviour or did I miss something ?
>
> By default the Name is set to the context type.  E.g. creating an
> "internet" context results in the name being set to "internet."  You can
> still reset the Name later to whatever you wish.
>
> ~/ofono-master$ test/list-contexts
> [ /phonesim ]
>    [ /phonesim/context1 ]
>        Username =
>        Protocol = ip
>        Name = Foobar
>        Settings = { }
>        Active = 0
>        AccessPointName =
>        Password =
>        Type = internet
>
>
> Regards,
> -Denis
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 20 Sep 2010 15:53:13 +0300
> From: Aki Niemi <aki.niemi@nokia.com>
> To: "ofono(a)ofono.org" <ofono@ofono.org>
> Subject: Re: Reg: Memory capacity exceeded
> Message-ID: <1284987193.12393.485.camel@tucson.research.nokia.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 2010-09-20 at 14:29 +0200, ext Pekka Pessi wrote:
> > I'm afraid there is a PICS case for this thing. I cannot recall how we
> > got N900 through this particular hoop, but probably we just waived
> > this particular test case irrelevant.
>
> I know we have the machinery in place in N900 to report memory exceeded
> to the network. And I even remember it getting tested at some point,
> basically flooding /var/spool/sms is enough to trigger it.
>
> If this can be waived, though, good riddance.
>
> Cheers,
> Aki
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 20 Sep 2010 17:08:41 +0300
> From: <Jeevaka.Badrappan@elektrobit.com>
> To: <denkenz@gmail.com>, <ofono@ofono.org>
> Subject: RE: Reg: Memory capacity exceeded
> Message-ID:
>        <
> B668883EB5DD7144ADFC248A72176EA802A51A03(a)fioues07.ebgroup.elektrobit.com>
>
> Content-Type: text/plain;       charset="us-ascii"
>
>
> Hi Denis,
>
> > The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
> storage).  And even if direct delivery does not work (e.g. crappy modem
> or Class 2 / Class 3 messages) oFono still removes the SMS
> > as soon as it is delivered.  We should never hit a sim/me memory full
> conditions.
>
> > So I don't see how this test case even applies.
>
> Little bit lost now. Are we speaking about the sending or receiving of
> SMS?
>
> Memory capacity exceeded applies to incoming SMS. Incoming SMS can be
> stored in SIM or in ME storage. If the SMS storage for incoming SMS is
> full, then the ME can inform the network that it can't handle any more
> class 1/class 2 incoming SMS due to maximum memory capacity reached.
> Once the user frees some memory by deleting some messages, then ME can
> inform network that it is ready now to receive messages. So, I believe
> this test case applies but as Pessi Pekka said we can waive this test
> case.
>
> Regards,
> jeevaka
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 20 Sep 2010 09:11:45 -0500
> From: Denis Kenzior <denkenz@gmail.com>
> To: Jeevaka.Badrappan(a)elektrobit.com
> Cc: ofono(a)ofono.org
> Subject: Re: Reg: Memory capacity exceeded
> Message-ID: <4C976BA1.30600@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Jeevaka,
>
> On 09/20/2010 09:08 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> >
> > Hi Denis,
> >
> >> The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
> > storage).  And even if direct delivery does not work (e.g. crappy modem
> > or Class 2 / Class 3 messages) oFono still removes the SMS
> >> as soon as it is delivered.  We should never hit a sim/me memory full
> > conditions.
> >
> >> So I don't see how this test case even applies.
> >
> > Little bit lost now. Are we speaking about the sending or receiving of
> > SMS?
> >
> > Memory capacity exceeded applies to incoming SMS. Incoming SMS can be
> > stored in SIM or in ME storage. If the SMS storage for incoming SMS is
> > full, then the ME can inform the network that it can't handle any more
> > class 1/class 2 incoming SMS due to maximum memory capacity reached.
> > Once the user frees some memory by deleting some messages, then ME can
> > inform network that it is ready now to receive messages. So, I believe
> > this test case applies but as Pessi Pekka said we can waive this test
> > case.
>
> I know exactly the case you're talking about, but as I mentioned before,
> oFono does not configure the modem to store on SIM or ME.  The messages
> are routed directly to oFono.  See drivers/atmodem/sms.c for more
> details.  The only messages that *might* get routed to SM/ME are Class 2
> / 3 messages.  These are automatically deleted on reception by the sms
> driver.
>
> The 'memory capacity reached' can simply never happen assuming sane
> hardware.
>
> Regards,
> -Denis
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 21 Sep 2010 02:09:36 +0900
> From: Marcel Holtmann <marcel@holtmann.org>
> To: ofono(a)ofono.org
> Subject: Re: [PATCH v2 1/2] huawei: poll sim state
> Message-ID: <1285002576.20811.36.camel@localhost.localdomain>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Kalle,
>
> > On my Huawei E1552 when I plug in the modem (ie. cold start) with PIN
> locked
> > SIM, the sim state is 255 (HUAWEI_SIM_STATE_NOT_EXISTENT). As the modem
> > doesn't send ^SIMST notifications, poll the sim state until it's ready.
> >
> > In theory it might be possible to do this better, for example follow
> > ^BOOT notifications or something, but it's unknown what parameter we
> > should check for.
> > ---
> >  plugins/huawei.c |   66
> +++++++++++++++++++++++++++++++++++++++++++-----------
> >  1 files changed, 53 insertions(+), 13 deletions(-)
>
> patch has been applied.
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 21 Sep 2010 02:09:55 +0900
> From: Marcel Holtmann <marcel@holtmann.org>
> To: ofono(a)ofono.org
> Subject: Re: [PATCH v2 2/2] huawei: fix online logic
> Message-ID: <1285002595.20811.37.camel@localhost.localdomain>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Kalle,
>
> > The recently introduced online support to huawei didn't work with my
> > Huawei E1552. The problem was that with command AT+CFUN=1;+CFUN=5
> > the modem didn't initialise the sim state properly.
> >
> > To fix this I changed the logic so that CFUN=5 is called only after the
> sim
> > state has switched to a valid state. Now my Huawei E1552 works with
> connman
> > again.
> >
> > PIN locked SIMs still won't work. The problem is that it takes some time
> for
> > the sim state to go to a valid state:
> >
> > Sep 20 15:01:57 dell-m520 ofonod[12451]: Pcui:< \r\n+CPIN:
> READY\r\n\r\nOK\r\n
> > [...]
> > Sep 20 15:02:00 dell-m520 ofonod[12451]: huawei: invalid sim state in
> post online (0)
> > [...]
> > Sep 20 15:02:01 dell-m520 ofonod[12451]: Pcui:< \r\n^SIMST:1\r\n
> >
> > I don't know why it takes so long to get a valid state.
> >
> > There is also another issue, in "cold start" case the phonebook
> > initialisation fails:
> >
> > Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:> AT+CPBS=?\r
> > Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:< \r\n+CME ERROR: SIM
> busy\r\n
> >
> > But in "warm start" it seems to work:
> >
> > Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:> AT+CPBS=?\r
> > Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:< \r\n+CPBS:
> ("SM","EN","ON")\r\n\r\nOK\r\n
> >
> > I consider this as a minor issue and didn't investigate it at all.
> > ---
> >  plugins/huawei.c |   77
> +++++++++++++++++++++++++++++++++++++-----------------
> >  1 files changed, 53 insertions(+), 24 deletions(-)
>
> patch has been applied.
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
>
>
> End of ofono Digest, Vol 17, Issue 71
> *************************************
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 23852 bytes --]