Re: [PATCH] sim: showing lock state with call meter
Hi Jussi,
On 02/23/2011 09:24 AM, Jussi Kangas wrote:
> Hi,
>
> On Wed, 2011-02-23 at 08:15 +0200, Denis Kenzior wrote:
>>>
>>> - if (pin_type != OFONO_SIM_PASSWORD_NONE &&
>>> - sim->state == OFONO_SIM_STATE_READY) {
>>> + if ((pin_type != OFONO_SIM_PASSWORD_NONE &&
>>> + sim->state == OFONO_SIM_STATE_READY) &&
>>> + (pin_type != OFONO_SIM_PASSWORD_SIM_PIN2)) {
>>
>> I don't see how this can work. You need to check for pin_type != NONE,
>> PIN2 and PUK2 AND state == READY here. This also only covers the case
>> of the PIN2 or PUK2 being triggered when call-meter is active. You do
>> not take care of the case where PIN2 or PUK2 are already required during
>> sim initialization.
>
> Hmm. It seems to work here. If I try reset call meter with wrong
> password I get pin_type OFONO_SIM_PASSWORD_SIM_PIN2 and
> OFONO_SIM_STATE_READY. APIs stay up and SIM manager shows pin2 locked
> and pin2 required. (Which is kinda wrong I admit, u cannot unlock the
> pin2, pin2 should always be visible in LockedPins or not at all, I would
> prefer the later. However it is showed as it is showed and it was
> working that way already before this patch). If I run same case three
> times I get same values but API shows that puk2 is required and all
> API:s stay up. If I run the case with correct password it does not come
> to this code at all all.
What I'm saying here is that it would be safer to do it like this:
switch (pin_type) {
case OFONO_SIM_PASSWORD_NONE:
case OFONO_SIM_PASSWORD_SIM_PIN2:
case OFONO_SIM_PASSWORD_SIM_PUK2:
break;
default:
if (sim->state == OFONO_SIM_STATE_READY)
...
}
We have to check for the PUK2 case above since we might be in PUK2
required state already. If we fail to unlock the PUK2, then
pin_type = puk2pin(pin_type);
will never be executed.
And I'm fine with your suggestion of blacklisting PIN2 from LockedPins,
but lets handle this separately.
>
> PIN2 cannot be required in startup. It is only required if u do
> something with certain features like fdn or call meter. PUK2 can be
> blocked in startup all right but it does not matter from startup point
> of view. If I start the oFono with PIN2 blocked I get pin_type
> OFONO_SIM_PASSWORD_SIM_PIN2 and OFONO_SIM_STATE_INSERTED states and API
> shows pin2 locked and puk2 required as required. (does not seem work if
> I boot up the modem and not just oFono though. Looks like modem bug
> where it does not read voluntarily PIN2 state.)
>
Again, my point here is that you have this code at the bottom of the
function:
if (pin_type == OFONO_SIM_PASSWORD_NONE)
sim_initialize_after_pin(sim);
If you want the SIM initialization to proceed then you need to add a
check for SIM PIN2/PUK2.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 0/2] add support of void parameters in CMER
Hi Frédéric, On 02/24/2011 11:16 AM, Frédéric Danis wrote: > following commands are supported : > AT+CMER=3,0,0,1,0 > > OK > AT+CMER=3,0,0,1 > > OK > AT+CMER=3,,,1 > > OK > AT+CMER=3,,,1, > > OK > AT+CMER=,,0,1, > > OK > AT+CMER=3, ,,1 > > OK > AT+CMER=3,a,0,1 > > ERROR > AT+CMER=3,"a",0,1 > > ERROR > AT+CMER=3, > > OK > AT+CMER=3 > > OK > > Frédéric Danis (2): > gatchat: add g_at_result_iter_next_number_default API > emulator: add support of void parameters in CMER > > gatchat/gatresult.c | 30 ++ > gatchat/gatresult.h |2 ++ > src/emulator.c | 24 > 3 files changed, 44 insertions(+), 12 deletions(-) > Both patches have been applied, thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: ofono crash (setting offline while connected)
Hi Amit, On 02/23/2011 11:07 PM, Amit Mendapara wrote: > Hi, > > While testing the Linktop driver I observed that ofono is crashing if I > try to set modem offline while it is connected (using > test/offline-modem.py script). After some debugging, I found that > `linktop_disconnect` function is being called twice (see the attached > debug log). > > What could be the reason here? I have seen some hack in mbm driver (in > mbm_disconnect) having `reopen_callback`. I have tried this but then > having another crash (this time when creating gprs context). Anyone, > please clarify how to deal with the issue properly? Some of these modems HUP the tty for x seconds. So if you try to open them too fast, they will be HUPed again, leading to various issues. When posting backtraces, please give them directly from gdb, or use the backtrace script to 'prettify' them. e.g.: test/backtrace src/ofonod your_log Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] gatchat: add g_at_result_iter_next_number_default API
---
gatchat/gatresult.c | 30 ++
gatchat/gatresult.h |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/gatchat/gatresult.c b/gatchat/gatresult.c
index 8a6dfae..f992486 100644
--- a/gatchat/gatresult.c
+++ b/gatchat/gatresult.c
@@ -292,6 +292,36 @@ gboolean g_at_result_iter_next_number(GAtResultIter *iter,
gint *number)
return TRUE;
}
+gboolean g_at_result_iter_next_number_default(GAtResultIter *iter, gint dflt,
+ gint *number)
+{
+ unsigned int pos;
+ int len;
+ char *line;
+
+ if (iter == NULL)
+ return FALSE;
+
+ if (iter->l == NULL)
+ return FALSE;
+
+ line = iter->l->data;
+ len = strlen(line);
+
+ pos = skip_to_next_field(line, iter->line_pos, len);
+
+ if (pos != iter->line_pos) {
+ iter->line_pos = pos;
+
+ if (number)
+ *number = dflt;
+
+ return TRUE;
+ }
+
+ return g_at_result_iter_next_number(iter, number);
+}
+
gboolean g_at_result_iter_next_range(GAtResultIter *iter, gint *min, gint *max)
{
int pos;
diff --git a/gatchat/gatresult.h b/gatchat/gatresult.h
index a74741f..f498c86 100644
--- a/gatchat/gatresult.h
+++ b/gatchat/gatresult.h
@@ -58,6 +58,8 @@ gboolean g_at_result_iter_next_string(GAtResultIter *iter,
const char **str);
gboolean g_at_result_iter_next_unquoted_string(GAtResultIter *iter,
const char **str);
gboolean g_at_result_iter_next_number(GAtResultIter *iter, gint *number);
+gboolean g_at_result_iter_next_number_default(GAtResultIter *iter, gint dflt,
+ gint *number);
gboolean g_at_result_iter_next_hexstring(GAtResultIter *iter,
const guint8 **str, gint *length);
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH v2 0/2] add support of void parameters in CMER
following commands are supported : AT+CMER=3,0,0,1,0 OK AT+CMER=3,0,0,1 OK AT+CMER=3,,,1 OK AT+CMER=3,,,1, OK AT+CMER=,,0,1, OK AT+CMER=3, ,,1 OK AT+CMER=3,a,0,1 ERROR AT+CMER=3,"a",0,1 ERROR AT+CMER=3, OK AT+CMER=3 OK Frédéric Danis (2): gatchat: add g_at_result_iter_next_number_default API emulator: add support of void parameters in CMER gatchat/gatresult.c | 30 ++ gatchat/gatresult.h |2 ++ src/emulator.c | 24 3 files changed, 44 insertions(+), 12 deletions(-) ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] emulator: add support of void parameters in CMER
---
src/emulator.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/emulator.c b/src/emulator.c
index 9cd3252..20a575f 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -312,7 +312,7 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
case G_AT_SERVER_REQUEST_TYPE_SET:
{
GAtResultIter iter;
- int mode;
+ int mode = em->events_mode;
int ind = em->events_ind;
int val;
@@ -320,15 +320,15 @@ static void cmer_cb(GAtServer *server,
GAtServerRequestType type,
g_at_result_iter_next(&iter, "");
/* mode */
- if (g_at_result_iter_next_number(&iter, &mode) == FALSE)
+ if (!g_at_result_iter_next_number_default(&iter, mode, &mode))
goto fail;
if (mode != 0 && mode != 3)
goto fail;
/* keyp */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_default(&iter, 0, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -337,8 +337,8 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* disp */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_default(&iter, 0, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -347,18 +347,18 @@ static void cmer_cb(GAtServer *server,
GAtServerRequestType type,
goto fail;
/* ind */
- if (g_at_result_iter_next_number(&iter, &ind) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_default(&iter, ind, &ind)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
- if ((ind != 0) && (ind != 1))
+ if (ind != 0 && ind != 1)
goto fail;
/* bfr */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_default(&iter, 0, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -367,7 +367,7 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* check that bfr is last parameter */
- if (g_at_result_iter_skip_next(&iter) == TRUE)
+ if (g_at_result_iter_skip_next(&iter))
goto fail;
done:
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi Denis, On 02/24/2011 06:14 PM, ext Denis Kenzior wrote: Hi Andras, The call SS notification handling patches hasn't been (fully) applied, I think we need to do something about it. I'd still like a version with the SSN atom removed. OK, I am going to remove the SSN atom, not a big deal, but do you have any other issues at this point? Not right now. Your API proposal is already upstream, I just didn't like the ssn atom being kept around. OK, I'll prepare the patches with the SSN atom removed. Regards, -Denis Regards, Andras ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi Andras, >>> The call SS notification handling patches hasn't been (fully) applied, I >>> think we need to do something about it. >>> >> I'd still like a version with the SSN atom removed. > OK, I am going to remove the SSN atom, not a big deal, but do you have > any other issues at this point? Not right now. Your API proposal is already upstream, I just didn't like the ssn atom being kept around. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem
Hi Arun, On 02/24/2011 04:34 AM, Arun Ravindran wrote: > Hi Denis, -Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Denis Kenzior Sent: Wednesday, February 23, 2011 5:50 PM To: ofono@ofono.org Cc: tomasz.grego...@gmail.com Subject: Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem > After discussing internally with Fred Joly I would like to come back on the 4 properties : > - Suspended is applicable in LTE in case of CS Voice Call using CSFB My understanding was that CS Fallback physically switches technologies. It is not 'suspending' LTE like it does with GPRS. Am I wrong on this one? >>> I would say yes. :) >>> In case you are obliged to fallback from 4G to 2G without support of >>> DTM, exaclty like in GPRS. >> From what I understood you physically lose the EPS network registration >> and fall back to 3G / 2G. How is this the same as the suspended >> property where your attached status does not change? >>> > For CSFB there are two settings. First one is that the UE should be > voice centric. > A voice centric UE will always try to make voice service available > either using IMS or by CSFB. > And if it cannot avail voice service using the above mechanisms, then it > should leave E-UTRA and re connect to GERAN/UTRA. A data centric UE in > turn will not leave E-UTRA if it cannot make a voice service available. > (23.221, section 7.2a) > > The second is that the voice call mode (domain), this can be set to CS, > CS preferred, PS or PS preferred. A UE with CS or CS preferred will > always try to make voice service through CS (CSFB or by re connecting to > GERAN/UTRA). 24.167 and also 23.221 describes these setting. I think the > AT commands for these in 27.007 are AT+CEMODE and +VCMOD > > A UE indicates its CSFB capability in attach and location/routing area > updates. The network in turn also indicates whether these are supported > in network. > 23.272 section 6.2 details a CSFB for MO call, where PS handover is > supported. 6.3 where PS handover is not supported and 6.5 where how to > return to E-UTRA when PS is suspended. > So everyone keeps talking of suspensions. However, I still see no CGEV that supports this event. It still looks like a 2G holdover that is being implemented by vendor specific extensions. Or is this just an oversight on 3GPP's part and suspensions can happen in LTE as well? > My understanding is that the context behaves the same way as in GPRS, > where it can be suspended, deactivated or handed over while doing CSFB > and the attach status will not change because when you are doing CSFB > you have done a combined attach (EPS/IMSI). > Attach status fair enough. However, does the reported technology change as well? There are important implications here, e.g. being able to deactivate the last context, etc. Overall I think we need detailed traces for all such scenarios and consider all possibilities. Currently I'm not convinced sharing LTE and GPRS logic is the right way to go. Perhaps, but again we have no control of the attach procedure with LTE. So the implementation has to rely on vendor specific radio settings. Same arguments about shoehorning logic apply here. >>> I'm a bit puzzled by this statement. It is not specific to LTE, but >>> related to +CFUN proprietary implementation against +COPS or +CGATT >>> usage, isn't it? >>> >> The current GPRS logic is controlled with the equivalent of CGATT. This >> is a well-defined command by 3GPP, but it is not applicable to EPS >> domain. It is applicable only to PS domain, correct? > 27.007 release 10, section 10, lists all commands applicable to EPS and > CGATT is one of them. > My fault, I mis-interpreted that section. You're of course correct that CGATT is indeed applicable. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi, On 02/24/2011 05:43 PM, ext Denis Kenzior wrote: Hi Andras, Please no top posting on this mailing list. You should know this by now. I am terribly sorry, I know I should have not done that. On 02/24/2011 05:43 AM, Andras Domokos wrote: Hi Denis and Sankar, The call SS notification handling patches hasn't been (fully) applied, I think we need to do something about it. I'd still like a version with the SSN atom removed. OK, I am going to remove the SSN atom, not a big deal, but do you have any other issues at this point? Regards, -Denis Regards, Andras ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] gatchat: add g_at_result_iter_next_number_or_void API
Hi Fred,
> gatchat/gatresult.c | 25 +
> gatchat/gatresult.h |2 ++
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/gatchat/gatresult.c b/gatchat/gatresult.c
> index 8a6dfae..0003f0b 100644
> --- a/gatchat/gatresult.c
> +++ b/gatchat/gatresult.c
> @@ -292,6 +292,31 @@ gboolean g_at_result_iter_next_number(GAtResultIter
> *iter, gint *number)
> return TRUE;
> }
>
> +gboolean g_at_result_iter_next_number_or_void(GAtResultIter *iter, gint
> *number)
> +{
> + unsigned int pos;
> + int len;
> + char *line;
> +
> + if (iter == NULL)
> + return FALSE;
> +
> + if (iter->l == NULL)
> + return FALSE;
> +
> + line = iter->l->data;
> + len = strlen(line);
> +
> + pos = skip_to_next_field(line, iter->line_pos, len);
> +
> + if (pos != iter->line_pos) {
> + iter->line_pos = pos;
> + return TRUE;
> + }
a general assumption is that if you return TRUE, you can assume that the
*number value is filled in properly. This is not the case anymore. So
you might need to give a default value in case it is void.
And that might mean we better do g_at_result_iter_next_number_default()
or something alike.
Or just having a peek function to check for an empty entry ahead before
calling g_at_result_iter_next_number() might be sufficient.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] common: '+' is not valid phone number anymore
Hi Paavo, On 02/24/2011 02:33 AM, Paavo Leinonen wrote: > Reject phone number if it contains only plus sign. > --- > Hi, > > Originally this issue was found while testing Call Forwarding. If > user would set call fowarding to number '+', oFono actually erased > existing CF settings. Fix was made to common.c as I don't think plus > should be considered as a valid phone number in any case. > > BR, > Paavo > > src/common.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > Patch has been applied, thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] gatchat: add g_at_result_iter_next_number_or_void API
---
gatchat/gatresult.c | 25 +
gatchat/gatresult.h |2 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/gatchat/gatresult.c b/gatchat/gatresult.c
index 8a6dfae..0003f0b 100644
--- a/gatchat/gatresult.c
+++ b/gatchat/gatresult.c
@@ -292,6 +292,31 @@ gboolean g_at_result_iter_next_number(GAtResultIter *iter,
gint *number)
return TRUE;
}
+gboolean g_at_result_iter_next_number_or_void(GAtResultIter *iter, gint
*number)
+{
+ unsigned int pos;
+ int len;
+ char *line;
+
+ if (iter == NULL)
+ return FALSE;
+
+ if (iter->l == NULL)
+ return FALSE;
+
+ line = iter->l->data;
+ len = strlen(line);
+
+ pos = skip_to_next_field(line, iter->line_pos, len);
+
+ if (pos != iter->line_pos) {
+ iter->line_pos = pos;
+ return TRUE;
+ }
+
+ return g_at_result_iter_next_number(iter, number);
+}
+
gboolean g_at_result_iter_next_range(GAtResultIter *iter, gint *min, gint *max)
{
int pos;
diff --git a/gatchat/gatresult.h b/gatchat/gatresult.h
index a74741f..7803ca1 100644
--- a/gatchat/gatresult.h
+++ b/gatchat/gatresult.h
@@ -58,6 +58,8 @@ gboolean g_at_result_iter_next_string(GAtResultIter *iter,
const char **str);
gboolean g_at_result_iter_next_unquoted_string(GAtResultIter *iter,
const char **str);
gboolean g_at_result_iter_next_number(GAtResultIter *iter, gint *number);
+gboolean g_at_result_iter_next_number_or_void(GAtResultIter *iter,
+ gint *number);
gboolean g_at_result_iter_next_hexstring(GAtResultIter *iter,
const guint8 **str, gint *length);
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] emulator: add support of void parameters in CMER
---
src/emulator.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/emulator.c b/src/emulator.c
index 4896ae1..c4bc505 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -312,23 +312,23 @@ static void cmer_cb(GAtServer *server,
GAtServerRequestType type,
case G_AT_SERVER_REQUEST_TYPE_SET:
{
GAtResultIter iter;
- int mode;
+ int mode = em->events_mode;
int ind = em->events_ind;
- int val;
+ int val = 0;
g_at_result_iter_init(&iter, result);
g_at_result_iter_next(&iter, "");
/* mode */
- if (g_at_result_iter_next_number(&iter, &mode) == FALSE)
+ if (!g_at_result_iter_next_number_or_void(&iter, &mode))
goto fail;
if ((mode != 0) && (mode != 3))
goto fail;
/* keyp */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_or_void(&iter, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -337,8 +337,8 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* disp */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_or_void(&iter, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -347,8 +347,8 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* ind */
- if (g_at_result_iter_next_number(&iter, &ind) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_or_void(&iter, &ind)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -357,8 +357,8 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* bfr */
- if (g_at_result_iter_next_number(&iter, &val) == FALSE) {
- if (g_at_result_iter_skip_next(&iter) == FALSE)
+ if (!g_at_result_iter_next_number_or_void(&iter, &val)) {
+ if (!g_at_result_iter_skip_next(&iter))
goto done;
goto fail;
}
@@ -367,7 +367,7 @@ static void cmer_cb(GAtServer *server, GAtServerRequestType
type,
goto fail;
/* check that bfr is last parameter */
- if (g_at_result_iter_skip_next(&iter) == TRUE)
+ if (g_at_result_iter_skip_next(&iter))
goto fail;
done:
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 0/2] add support of void parameters in CMER
following commands are supported : AT+CMER=3,0,0,1,0 OK AT+CMER=3,0,0,1 OK AT+CMER=3,,,1 OK AT+CMER=3,,,1, OK AT+CMER=,,0,1, OK AT+CMER=3, ,,1 OK AT+CMER=3,a,0,1 ERROR AT+CMER=3,"a",0,1 ERROR AT+CMER=3, OK AT+CMER=3 OK Frédéric Danis (2): gatchat: add g_at_result_iter_next_number_or_void API emulator: add support of void parameters in CMER gatchat/gatresult.c | 25 + gatchat/gatresult.h |2 ++ src/emulator.c | 24 3 files changed, 39 insertions(+), 12 deletions(-) ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi Andras, Please no top posting on this mailing list. You should know this by now. On 02/24/2011 05:43 AM, Andras Domokos wrote: > Hi Denis and Sankar, > > The call SS notification handling patches hasn't been (fully) applied, I > think we need to do something about it. > I'd still like a version with the SSN atom removed. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi Denis and Sankar,
The call SS notification handling patches hasn't been (fully) applied, I
think we need to do something about it.
Regards,
Andras
On 02/22/2011 02:07 PM, ext Sankar wrote:
Hi Denis/Andras,
Is this patch applied and available in the GIT?
Regards,
Sankar.
On Thu, Feb 10, 2011 at 2:42 PM, Andras Domokos
mailto:andras.domo...@nokia.com>> wrote:
Hi Denis,
On 02/10/2011 05:08 AM, ext Denis Kenzior wrote:
Hi Andras,
diff --git a/include/ssn.h b/include/ssn.h
index d640cad..ba3701b 100644
--- a/include/ssn.h
+++ b/include/ssn.h
@@ -37,9 +37,10 @@ struct ofono_ssn_driver {
};
/* SSN notifications (CSSI and CSSU). */
-void ofono_ssn_cssi_notify(struct ofono_ssn *ssn, int
code, int index);
-void ofono_ssn_cssu_notify(struct ofono_ssn *ssn, int
code, int index,
- const struct
ofono_phone_number *number);
+void ofono_ssn_cssi_notify(struct ofono_ssn *ssn,
unsigned int id,
+ int code1, int index);
+void ofono_ssn_cssu_notify(struct ofono_ssn *ssn,
unsigned int id, int code2,
+ int index, const struct
ofono_phone_number *number);
int ofono_ssn_driver_register(const struct
ofono_ssn_driver *d);
void ofono_ssn_driver_unregister(const struct
ofono_ssn_driver *d);
Right now I'm not seeing any users (or even potential ones) of
the SSN
atom besides voicecall. What do you think of removing the SSN
atom and
moving these to the voicecall atom?
Yes, we talked about removing the SSN atom, but I thought I would
keep it for now, it can be removed any time later, anyways, doesn't
save much removing it.
The only one I'm not sure about is from 27.007:
6 forward check SS message received (can be received
whenever)
Any idea what this one is about?
Never encountered this message, and I am not sure what is it for.
A patch for handling this message can be submitted later, if a real
life case is found for it.
Regards,
-Denis
Regards,
Andras
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] emulator: add CMER support
Hi Denis
Le 23/02/2011 21:13, Denis Kenzior a écrit :
Hi Frédéric,
On 02/23/2011 01:00 PM, Frédéric Danis wrote:
---
src/emulator.c | 107 ++-
1 files changed, 105 insertions(+), 2 deletions(-)
I applied this patch, but one comment below:
diff --git a/src/emulator.c b/src/emulator.c
index f0ca8c8..ca36c0e 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -43,6 +43,8 @@ struct ofono_emulator {
GAtServer *server;
GAtPPP *ppp;
guint source;
+ int events_mode;
+ gboolean events_ind;
GSList *indicators;
};
@@ -251,6 +253,103 @@ fail:
}
}
+static void cmer_cb(GAtServer *server, GAtServerRequestType type,
+ GAtResult *result, gpointer user_data)
+{
+ struct ofono_emulator *em = user_data;
+ char buf[32];
+
+ switch (type) {
+ case G_AT_SERVER_REQUEST_TYPE_QUERY:
+ sprintf(buf, "+CMER: %d,0,0,%d,0", em->events_mode,
+ em->events_ind);
+ g_at_server_send_info(em->server, buf, TRUE);
+ g_at_server_send_final(server, G_AT_SERVER_RESULT_OK);
+ break;
+
+ case G_AT_SERVER_REQUEST_TYPE_SUPPORT:
+ sprintf(buf, "+CMER: (0,3),(0),(0),(0,1),(0)");
+ g_at_server_send_info(em->server, buf, TRUE);
+ g_at_server_send_final(server, G_AT_SERVER_RESULT_OK);
+ break;
+
+ case G_AT_SERVER_REQUEST_TYPE_SET:
+ {
+ GAtResultIter iter;
+ int mode;
+ int ind = em->events_ind;
+ int val;
+
+ g_at_result_iter_init(&iter, result);
+ g_at_result_iter_next(&iter, "");
+
+ /* mode */
+ if (g_at_result_iter_next_number(&iter,&mode) == FALSE)
+ goto fail;
+
+ if ((mode != 0)&& (mode != 3))
+ goto fail;
+
+ /* keyp */
+ if (g_at_result_iter_next_number(&iter,&val) == FALSE) {
+ if (g_at_result_iter_skip_next(&iter) == FALSE)
+ goto done;
+ goto fail;
+ }
From what I understand you're trying to enable something like:
+CMER=3,,1 right?
So this code does accomplish this, but it also allows silliness like this:
+CMER=3,"foobar",,1
You might want to make a special version of next_number that would
actually check that either the number is given, or the field is empty.
The current version check that the parameter is a number or the end
(skip_next returns false) :
AT+CMER=3,0,0,1,0 or AT+CMER=3,0 are supported.
Currently void parameter are not supported (AT+CMER=3,,,1).
I will send a patch to support number or void parameter.
Regards
Fred
--
Frederic DanisOpen Source Technology Centre
frederic.da...@intel.com Intel Corporation
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem
Hi Denis, -Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Denis Kenzior Sent: Wednesday, February 23, 2011 5:50 PM To: ofono@ofono.org Cc: tomasz.grego...@gmail.com Subject: Re: [PATCH] atmodem: CEREG support for LTE network status reporting in AT modem After discussing internally with Fred Joly I would like to come back on the 4 properties : - Suspended is applicable in LTE in case of CS Voice Call using CSFB My understanding was that CS Fallback physically switches technologies. It is not 'suspending' LTE like it does with GPRS. Am I wrong on this one? I would say yes. :) In case you are obliged to fallback from 4G to 2G without support of DTM, exaclty like in GPRS. From what I understood you physically lose the EPS network registration and fall back to 3G / 2G. How is this the same as the suspended property where your attached status does not change? For CSFB there are two settings. First one is that the UE should be voice centric. A voice centric UE will always try to make voice service available either using IMS or by CSFB. And if it cannot avail voice service using the above mechanisms, then it should leave E-UTRA and re connect to GERAN/UTRA. A data centric UE in turn will not leave E-UTRA if it cannot make a voice service available. (23.221, section 7.2a) The second is that the voice call mode (domain), this can be set to CS, CS preferred, PS or PS preferred. A UE with CS or CS preferred will always try to make voice service through CS (CSFB or by re connecting to GERAN/UTRA). 24.167 and also 23.221 describes these setting. I think the AT commands for these in 27.007 are AT+CEMODE and +VCMOD A UE indicates its CSFB capability in attach and location/routing area updates. The network in turn also indicates whether these are supported in network. 23.272 section 6.2 details a CSFB for MO call, where PS handover is supported. 6.3 where PS handover is not supported and 6.5 where how to return to E-UTRA when PS is suspended. My understanding is that the context behaves the same way as in GPRS, where it can be suspended, deactivated or handed over while doing CSFB and the attach status will not change because when you are doing CSFB you have done a combined attach (EPS/IMSI). Perhaps, but again we have no control of the attach procedure with LTE. So the implementation has to rely on vendor specific radio settings. Same arguments about shoehorning logic apply here. I'm a bit puzzled by this statement. It is not specific to LTE, but related to +CFUN proprietary implementation against +COPS or +CGATT usage, isn't it? The current GPRS logic is controlled with the equivalent of CGATT. This is a well-defined command by 3GPP, but it is not applicable to EPS domain. It is applicable only to PS domain, correct? 27.007 release 10, section 10, lists all commands applicable to EPS and CGATT is one of them. If so, then the powered property does not map to LTE at all. Your proprietary CFUN/COPS map to the TechnologyPreference setting in RadioSettings. Regards, Arun ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] common: '+' is not valid phone number anymore
Reject phone number if it contains only plus sign. --- Hi, Originally this issue was found while testing Call Forwarding. If user would set call fowarding to number '+', oFono actually erased existing CF settings. Fix was made to common.c as I don't think plus should be considered as a valid phone number in any case. BR, Paavo src/common.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/common.c b/src/common.c index 247fff0..520360c 100644 --- a/src/common.c +++ b/src/common.c @@ -246,6 +246,9 @@ gboolean valid_number_format(const char *number, int length) if (number[0] == '+') begin = 1; + if (begin == len) + return FALSE; + if ((len - begin) > length) return FALSE; -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
